Object Databases in OMG

1
Object Databases in OMG
Michael P. Card michael.card_at_sensis.com (315)
445-5089
2
Why Database?
Databases provide capabilities for developers
that other middleware technologies do not a
single API (service) for transaction semantics,
replication, and persistence of objects
specialized data structures for fast organization
and searching (collections and indices)
3
What is an object database?
An object database is typically a library that is
linked into an application which provides methods
that extend the features of the applications
programming language to include database features
like transaction semantics, persistence, and data
distribution (replication).
4
Couldnt you do that with an O/R mapping?
Yes, but doing so requires conversion between
objects in a relational database (rows in
tables) and objects in the native programming
language. The O/R mapping serves as a software
stile between the two worlds, and this
introduces considerable overhead for some
applications.
5
What was the ODMG?
The Object Data Management Group was a consortium
of object database vendors seeking to develop a
standard set of programming language APIs. The
standard produced was also referred to as ODMG.
This standard included an object model
(Chapter 2) a language-neutral Object
Definition Language (ODL, Chapter 3) a
language-neutral Object Query Language (OQL,
Chapter 4) a C binding (Chapter 5) a
SmallTalk binding (Chapter 6) a Java binding
(Chapter 7)
6
ODMG Features Objects
Database-managed objects in ODMG must inherit
from a root type. Such objects are said to be
persistence-capable and are eligible for
containment in collections, persistence,
transaction semantics etc.
Persistence-capable objects can have 2
lifetimes in ODMG 3.0 transient and
persistent. Support for main-memory databases and
pre-allocation of storage are not included in
ODMG 3.0.
7
ODMG Features Collections
Array subscripted container of references to
user objects
Linked lists ODMG provided 3 kinds the list,
set, and bag, all of which were lists of
references to user objects. All 3 had basic list
navigation capability via iterators, but the set
and bag collections also had union, intersection,
and difference methods.
Dictionary the ODMG dictionary collection was a
set of key-value pairs which could be used as a
substitute for a directly-accessible index. The
only way to query array or linked list
collections in ODMG was via OQL.
8
ODMG Features Relationships
Relationships are used to link objects of
different classes together. In ODMG 3.0,
relationships are declarative. That is,
relationships are declared as attributes in the
class definitions
The cardinality of the relationship depends on
the type of the relation-ship attribute. A
relationship attribute can be a reference to a
single object (cardinality 1) or to a
collection of objects (cardinality many).
9
ODMG Features Transactions
Transactions in ODMG 3.0 allow objects to be
locked using read, write, or upgrade locks. These
lock types were borrowed from the OMG concurrency
service. In addition to the expected database
operations (begin, commit, checkpoint and abort),
ODMG transactions also include join and leave
methods to support C/C concurrent
programming. Unfortunately, the ODMG 3.0 object
model presumes only one open database at a time
as all transactions are bound to the current
open database.
10
Possible New Directions
If the OMG becomes the new custodian for the ODMG
3.0 standard, there are several things that could
be done to bring it up to date
1. Update the object model to include support for
embedded real-time applications and new
database features 2. Include a new Ada95
binding 3. Incorporate new standards (XML Schema,
SOAP/WSDL) into the revision
11
Possible Object Model Changes

• Storage Management Update object factory
  interface to include preallocation of
  storage to support deterministic object creation
  and deletion. Also add support for main-memory
  databases.
• 2. Indexing Add a new index interface that
  provides direct (non-OQL) search capability for
  both spatial and partially-ordered keys. Index
  objects used to order collections, allow
  multiple indices per collection.
• 3. Iterators Iteration needs to be linked to
  transaction scope. Application development
  could also be simplified by incorporating
  iteration methods (first, last, next, prior) in
  the collection, index, and relationship
  interfaces, obviating need to create iterators.

12
Possible Object Model Changes

• Storage Management Update object factory
  interface to include preallocation of
  storage to support deterministic object creation
  and deletion. Also add support for main-memory
  databases.
• 2. Indexing Add a new index interface that
  provides direct (non-OQL) search capability for
  both spatial and partially-ordered keys. Index
  objects used to order collections, allow
  multiple indices per collection.
• 3. Iterators Iteration needs to be linked to
  transaction scope. Application development
  could also be simplified by incorporating
  iteration methods (first, last, next, prior) in
  the collection, index, and relationship
  interfaces, obviating need to create iterators.

13
Possible OM Changes Indices

• Multiple indices allow you to organize a
  collection of objects multiple ways

Car Collection

Car Objects with License and VIN as key
attributes
Lic DVX123 VIN 11242
Lic AB342 VIN 97754
Lic CCE34 VIN 37651
1
2
3
VIN Index
Lic Index
14
Possible OM Changes Spatial Indices

• The R-tree is similar to a B-tree, except the
  keys in its nodes are ranges instead of point
  values

hypercube for key A
B
A
hypercube for key B
15
Possible Object Model Changes

• Storage Management Update object factory
  interface to include preallocation of
  storage to support deterministic object creation
  and deletion. Also add support for main-memory
  databases.
• 2. Indexing Add a new index interface that
  provides direct (non-OQL) search capability for
  both spatial and partially-ordered keys. Index
  objects used to order collections, allow
  multiple indices per collection.
• 3. Iterators Iteration needs to be linked to
  transaction scope. Application development
  could also be simplified by incorporating
  iteration methods (first, last, next, prior) in
  the collection, index, and relationship
  interfaces, obviating need to create iterators.

16
Possible OM Changes (contd)
4. Collections Reduce number of types of
collections to a minimal set, rely on indices
to organize and search data per application
needs. Recommended changes
17
Possible OM Changes (contd)

• Databases add methods to support replication and
  replication quality of service (QoS) to
  database interface, allow multiple databases to
  be open in an application
• Relationships make all relationships 2-way and
  add concept of keyed relationships so users
  can do a direct query to find a subset of related
  objects rather than having only simple iteration
• Transactions modify transaction definition to
  support Bernsteins 4 properties for concurrency
  control correctness instead of ACID, which is
  insufficient to ensure correctness

18
Possible OM Changes Replication

• Replication allows clients to get a read-only
  copy of a database that is automatically kept
  up-to-date with changes at the master

Global Track File Master
19
Possible OM Changes Replication (contd)

• Replication not only supports database
  subscriptions but also can be the basis for
  fault tolerance and capabilities like master
  database relocation

20
Possible OM Changes (contd)

• Databases add methods to support replication and
  replication quality of service (QoS) to
  database interface, allow multiple databases to
  be open in an application
• Relationships make all relationships 2-way and
  add concept of keyed relationships so users
  can do a direct query to find a subset of related
  objects rather than having only simple iteration
• Transactions modify transaction definition to
  support Bernsteins 4 properties for concurrency
  control correctness instead of ACID, which is
  insufficient to ensure correctness

21
Possible OM Changes (contd)

• Databases add methods to support replication and
  replication quality of service (QoS) to
  database interface, allow multiple databases to
  be open in an application
• Relationships make all relationships 2-way and
  add concept of keyed relationships so users
  can do a direct query to find a subset of related
  objects rather than having only simple iteration
• Transactions modify transaction definition to
  support Bernsteins 4 properties for concurrency
  control correctness instead of ACID, which is
  insufficient to ensure correctness

22
Possible OM Changes (contd)
7. Transactions (contd) Also, allow
transactions to operate on objects in
different databases. Remove thread methods
(transaction bound to thread in which it is
created), and add QoS for replication
optimization 8. Triggers Add triggers to
support event or data-driven programming 9.
Miscellaneous - Require referential integrity
in all circumstances - Invalidate programming
language pointers to database objects upon
enclosing transaction commit - Update language
bindings to reflect OM changes
23
Possible OM Changes Transaction QoS

• A QoS for strict data consistency ensures that
  changes are applied to all replicants before a
  commit on the master completes

applications with replicants
application with master database
odb. commit()
master
24
Possible OM Changes Transaction QoS (contd)

• A QoS for semi-strict data consistency ensures
  that all replicants receive the updates before a
  commit on the master completes (guaranteed
  delivery)

application with master database
applications with replicants
odb. commit()
master
25
Possible OM Changes Transaction QoS (contd)

• A QoS for relaxed data consistency ensures that
  all updates are sent before a commit on the
  master completes

application with master database
applications with replicants
odb. commit()
commit ends
master
26
Possible OM Changes (contd)
7. Transactions (contd) Also, allow
transactions to operate on objects in
different databases. Remove thread methods
(transaction bound to thread in which it is
created), and add QoS for replication
optimization 8. Triggers Add triggers to
support event or data-driven programming 9.
Miscellaneous - Require referential integrity
in all circumstances - Invalidate programming
language pointers to database objects upon
enclosing transaction commit - Update language
bindings to reflect OM changes
27
Possible OM Changes Triggers
Here is an example of how triggers could be used
Display application 1- triggers on ADIZ
Tracker/Fusion application
1000
2237
Display application 2- triggers on supersonic
track
Track File master
28
Possible OM Changes (contd)
7. Transactions (contd) Also, allow
transactions to operate on objects in
different databases. Remove thread methods
(transaction bound to thread in which it is
created), and add QoS for replication
optimization 8. Triggers Add triggers to
support event or data-driven programming 9.
Miscellaneous - Require referential integrity
in all circumstances - Invalidate programming
language pointers to database objects upon
enclosing transaction commit - Update language
bindings to reflect OM changes
29
Possible OM Changes UML
NOTE The Spatial_Index class does not
inherit from the Index class because spatial
indices are not partial orderings.
30
Incorporation of new standards
Some of the work done in the ODMG pre-dated
current industry standards. Where appropriate,
the ODMG work should be replaced or augmented by
these newer standards 1. XML Schema Definition
Chapter 3 of the ODMG 3.0 standard should be
rewritten to provide an XML Schema Definition
(ODMG) for conformant object databases in
lieu of ODMG ODL. 2. SOAP/WSDL Chapter 4 of the
ODMG 3.0 standard should be rewritten to
define SOAP/WSDL XML auto-generated from the
schema to support remote (or local) queries.
This could be an augmentation of or a replace-
ment for OQL.