featuresmatrix intro page0. Intended Use
The ODMG Object Model is intended to allow portability of applicationsamong object database products. It provides a common model for these productsby defining extensions to the OMG object model that support object databaserequirements. In particular, the ODMG model extends the OMG core to providefor persistent objects, object properties, more specific object types,queries and transactions.
1. Basic Concepts
The basic concepts are objects, types, operations, properties, identityand subtyping. Objects have state (defined by the values of their properties),behavior (defined by operations) and identity. All objects of the sametype have common behavior and properties.
Types are objects so may have their own properties. A type has an interfaceand one or more implementations. All things are instances of some typeand subtyping organizes these types in a lattice. A type definition candeclare that an extent (set of all instances) be maintained for the type.
2. Objects
Objects are instances of a type, and as such have state, behavior andidentity. All objects are of type Denotable_Object. An object can be mutable(instance of type "object") or immutable (instance of type "literal").The remainder of this note will use the term object to refer to mutableobjects.
Objects and literals can be atomic or structured. The identity of objectsis represented by OIDs; typically literals are identified by their value.Objects may also have meaningful name(s) in addition to identity (propertiesof objects include "has_name?" and "names").
2.1 operations
Operations are defined on types. The interface of a type includes operationsignatures: argument names and types, possible exceptions, result types.The first argument of an operation is distinguished.
Operation names may be overloaded; dispatching is based on the mostspecific type of the first argument of the operation call. Operations mayhave side-effects; an operation with only side-effects can return a nilvalue. The model assumes operations will be executed sequentially.
Implications for optimization are that optimizers must be conservativesince an operation in a query might have side-effects. They suggest a "pragma"distinguishing operations that can safely occur in query expressions.
2.2 requests
See 2.1 Operations.
2.3 messages
See 2.1 operations.
2.4 specification of behavioral semantics
Object behavior is modeled through operations (see 2.1 Operations).An operation signature (part of a type specification) specifies argumenttypes, result types and exceptions that can be raised. "There is noformal specification of the semantics of an operation" (p. 25).
2.5 methods (including multimethods and method combinations)
Operations (declared in the interface) are implemented by methods definedin the type implementation. Each operation is implemented by a method,plus there may be additional methods defined.
2.6 state
State is modeled by the properties of an object. A property can be anattribute or a relationship. The attributes and relationships of an objectare defined as part of the type interface. Attributes take literals astheir values; relationships can only be defined between two nonliteralobject types.
2.7 object lifetime
Object lifetime is orthogonal to type, is specified at object creationand, once specified, cannot be changed (there is some discrepancy betweensection 2.3.2.7 which discusses lifetime and section 2.3.2.6 where thecreate operation is discussed and makes no mention of lifetime). Lifetimecan be "coterminous with procedure" meaning it is declared inthe heading of a procedure, allocated out of the stack and returned tothe free pool when the procedure ends, "coterminous with process"meaning it is allocated by the programming language runtime, or "coterminouswith database" meaning it is managed by the DBMS runtime.
Lifetime is not applicable to literals (immutable objects). Literalsalways exist implicitly. Most queries return literals.
The query language contains expressions for constructing objects, butthere is no mention of lifetime of these objects.
2.8 behavior/state grouping
ODMG specifies a classical object model: each operation has a distinguishedargument. See also 9.1 Relationships.
2.9 communication model
The model assumes operations are executed sequentially, although itdoes not preclude concurrent or parallel operations.
The model supports nested transactions, where the commit of a nestedtransaction is dependent on the containing parent transaction's commit.Type Transaction defines operations to begin, commit, abort and checkpointa transaction. A transaction obtains standard read and write locks withpessimistic concurrency control.
2.10 events
Not applicable.
3. Binding
The model supports run-time binding of methods to objects based on thefirst argument type. (see 2.1 Operations)
4. Polymorphism
The model supports polymorphism implicit in subtyping, as well as parameterizedcollection types.
5. Encapsulation
All objects are instances of a type which specifies the interface foraccessing the object. There is only one interface for a type.
6. Identity, Equality, Copy
All denotable objects have an identity. For literals this identity is"typically the bit pattern that encodes its value". For objects,identity "uniquely distinguishes the object from all other objectswithin the domain in which the object was created" and is independentof any state of the object.
Operation Equal? is defined for type Denotable_Object.
In order to copy objects, copy operations must be defined as part ofthe object's type. For Collection object types, the copy operation is ashallow copy - returning a new collection with the same elements as thecopied collection. For object type Structure, the copy operation is alsoa shallow copy.
Literals are copied by assignment. "Assignment of an object oftype Structured_Literal, or any of its subtypes, to another object willcreate a (logical) copy of the literal" (p.36).
7. Types and Classes
A type is a specification; it can have one or more implementations.All types are instances of type Type. A class is the combination of a typespecification and a specific implementation. The model is strongly typed.
The set of all instances of a type is the 'extent' of the type. 'Abstracttypes' are not instantiable - they specify characteristics that can beinherited by subtypes but do not define any implementations.
Two objects are compatible if they are instances of the same declaredtype or if one is an instance of a subtype of the other. Two structuredliterals have the same type if they have the same structure at every leveland the corresponding atomic types are the same. Subtyping for structuredliterals requires the same structure at each level and the type of eachsubobject of the subtype to be the same as, or a supertype of, the correspondingsubobject of the supertype. No implicit conversions are given for eitherobjects or structured literals. Some explicit conversions are given inthe object query language specification.
8. Inheritance and Delegation
The model defines type inheritance only (i.e., subtyping). If S is asubtype of T, then S inherits all operations and properties of T, and Smay define new operations and properties applicable to its instances. Inother words, objects of type S have all the characteristics (and more)of type T. A subtype can specialize the properties and operations it inherits,but there are no rules given to indicate what kinds of refinement are correct.
A type can inherit from multiple supertypes, but must rename same-namedinherited operations or properties.
Section 2.2.1 notes that new subtypes may only be defined under typeObject. At this point (release 1.1) no subtyping is allowed for characteristictypes - attributes, type, relationships, operations. Type compatibilityfor objects is by name. Two objects have the same type if and only if theyare instances of the same named type. An object of a given type can beassigned to an object of any of its supertypes.
For literals, type compatibility is by structure - structured literals(immutable collections or structures) have the same type only if they havethe same structure at each level and corresponding atomic parts have thesame type. "Subtyping" of structured literals requires that bothhave the same structure at every level, and that the type of each 'subobject'of the supertype is the same or a subtype of the corresponding subobjectof the subtype (section 2.8.2.2 - contravariance).
9. Noteworthy Objects
9.1 relationships
Relationships are a kind of property defined between two mutable objecttypes. Relationships are not objects.
A relationship can be one-to-one, one-to-many or many-to-many. Relationshipsare defined in the interface(s) of the object type(s) involved in the relationshipas a "traversal path" from one type to another. A two-way relationshipwill have a name in each type interface, and an inverse" clause ineach path declaration.
9.2 attributes
Attributes are a kind of property defined on a single object type. Attributestake literals as their values. Attributes are accessed by get_value andset_value operations; they are defined as part of the type interface -there are no implications about the implementation of the object type.Attributes are not first class objects (they cannot have properties orbe subtyped), however the built-in get_ and set_value operations can beoverridden. (Note that because attributes take literals as their values,defining, for example, a Department "attribute" of a Person objecthaving a Department object as its value requires the use of an ODMG relationshipinstead. See 9.1 relationships. )
9.3 literals
Literals are immutable objects - either atomic (integer, float, Boolean,character) or structured. Structured_literals have two subtypes - Immutable_Collection(bit strings, character strings, and enumerations are built-in) and Immutable_Structure(date, time, interval). Additional subtypes can be defined, but operationson the built-in literal types cannot be redefined. The literal types areexpected to directly map to types in the programming language. If the languagedoes not have an analog for one of the literal types, the type must bedefined in a library provided as part of the language binding.
9.4 containment
9.5 aggregates
Structured objects (aggregates) can be of type Structure or type Collection.Structures are records with named slots which can be filled by objectsor literals of different types. Collections are homogeneous (modulo subtyping)groupings of elements that may or may not be ordered.
Built-in collection types are set, bag, list and array. Sets and bagsare unordered collections; lists and arrays are ordered. Arrays are variablelength (although an initial size is specified at creation) and can containnil values.
Collection types are instances of parameterized types. They can be parameterizedby any subtype of Denotable_Object. There are two subtypes of collections:predicate_defined and insertion_defined. A type extent is a predicate_definedcollection.
Mutable collections (subtype of Structured_Object) have intentionalsemantics. Immutable collections (subtype of Structured_Literal) have extensionalsemantics.
Iterators can be defined to traverse collections. Type Collection alsodefines predicate-based select operations. Query operations apply to anycollection (extents, user-defined). The result of a selection is a subcollectionof the same type as the collection queried. Each of the more specific collectiontypes defines appropriate query operations. Of course, the literal collectiontypes do not define update operations (insert, delete, replace).
9.6 other
Type Exception is provided by the object model, and may be subtyped.Operation signatures can indicate exceptions that can be raised. When anexception is raised it is handled by the exception handler in the closestscope and transactions within that scope are aborted.
10. Extensibility
See under 8 Inheritance and Delegation for a discussion of subtypingin the model. New types can be defined as subtypes of existing types.
10.1 Dynamic
Not specified.
10.2 Metaclasses/Metaobject Protocol
Not specified.
10.3 Introspection
Type "Type" is a subtype and an instance of type Atomic_object.The meta-data can be accessed using the interface for type instances, andcan be queried using the standard query language.
11. Object Languages
ODMG specifies an object definition language (ODL) that supports theODMG object model and is compatible with OMG's IDL. The ODL is programminglanguage independent. C++ and Smalltalk ODL bindings are defined in [ODMG,1994].
ODMG also specifies an SQL-like object query language (OQL) that providesdeclarative access to objects. Queries can be posed to any denotable object,starting with an object name or with a language expression yielding theobject. For example, (from [ODMG, 1994])
select distinct x.agefrom x in Personswhere x.name = "Pat"
queries over the set named Persons (in this case, the extent of typePerson).
The nested query in
select distinct struct(name: x.name, hps: (select y from y in x.subordinates where y.salary > 100000)from x in Employees
queries over the result of the query (path) expression x.subordinates.
The full OQL syntax is not currently supported by either the C++ orthe Smalltalk binding.
12. Semantics of Base Classes (+ type constructors)
13. Background and References
The Object Database Management Group (ODMG) was initiated in late 1991to address the belief that lack of standards for object databases has hinderedtheir acceptance. The group wanted to progress quickly, thus they keptthemselves small (originally 5 voting members) and insisted that membersrepresent their companies as individuals; substitute representatives arenot allowed. Release 1.0 of the standard was published a little over ayear later in 1993.
As of February 1994, the group has seven voting member companies anda number of reviewer companies. The voting member companies and most ofthe reviewer member companies have committed to supporting the standardby 1995.
[Cat94] R.G.G. Cattell, editor, The Object Database Standard: ODMG-93,Release 1.1, Morgan Kaufmann Publishers, San Francisco, 1994.
Information about the ODMG can be obtained by mail to info@odmg.org;questions can be addressed to question@odmg.org.