ODMG 3.0 was developed by the Object Data Management Group (ODMG).

The ODMG is a consortium of vendors and

ODMG 3.0 is a portability specification. It is designed to allow for portable applications that could run on more than one
product. ODMG 3.0 uses the Java, C++, and Smalltalk languages as much as possible, to allow for the transparent
integration of object programming languages.

The major components of ODMG 3.0 specification are:

 Object Model. The common data model supported by ODMG implementations is based on the OMG Object
Model. The OMG core model was designed to be a common denominator for object request brokers, object database
systems, object programming languages, and other applications. In keeping with the OMG Architecture, a profile has been
designed for their model, adding components (e.g., relationships) to the OMG core object model to support the ODMG
needs.
 Object Specification Languages. The two specification languages are the Object Definition Language (ODL) and
Object Interchange Format (OIF) languages. ODL is a specification language used to define the object types that conform to
the ODMG Object Model and is based on the OMG IDL. OIF is a specification language used to dump and load from a file
or set of files.
 Object Query Language. This is a declarative (nonprocedural) language for querying and updating objects. SQL-
92 was used as the basis for OQL. 
 C++ Language Binding. This is the binding of ODMG implementations to C++. This is called the C++ OML, or
object manipulation language. The C++ binding also includes a version of the ODL that uses C++ syntax, a mechanism to
invoke OQL, and procedures for operations and transactions. 
 Smalltalk Language Binding. This is the binding of ODMG implementations to Smalltalk. It defines the binding
in terms of the mapping between ODL and Smalltalk, which is based on the OMG Smalltalk binding for IDL. The Smalltalk
binding also includes a mechanism to invoke OQL and procedures for operations on databases and transactions. 
 Java Language Binding. This is the binding between the ODMG Object Model (ODL and OML) and the Java
programming language as defined by the Java 2 Platform. The Java language binding also includes a mechanism to invoke
OQL and procedures for operations and transactions.

It is possible to read and write the same database from C++, Smalltalk, and Java, as long as the programmer stays within the
common subset of supported data types. Note that, unlike SQL in relational systems, the ODMG data manipulation
languages are tailored to specific application programming languages, in order to provide a single, integrated environment
for programming and data manipulation. This is called transparent persistence.

Such transparent persistence is illustrated by the following diagram and contrasts with the database sublanguage of SQL and
its variants. In this diagram, you only see the host programming language and no database sublanguage or call-level interface
as in JDBC.

Overview of the Object Model of ODMG

The ODMG object model is the data model upon which the object definition language (ODL) and object query language
(OQL) are based. It is meant to provide a standard data model for object databases, just as SQL describes a standard data
model for relational databases. It also provides a standard terminology in a field where the same terms were sometimes used
to describe different concepts.

Objects and Literals. Objects and literals are the basic building blocks of the object model. The main difference between the
two is that an object has both an object identifier and a state (or current value), whereas a literal has a value (state) but no
object identifier.22 In either case, the value can have a complex structure. The object state can change over time by
modifying the object value. A literal is basically a constant value, possibly having a complex structure, but it does not
change.
An object has five aspects: identifier, name, lifetime, structure, and creation.
1. The object identifier is a unique system-wide identifier (or Object_id).Every object must have an object identifier.
2. Some objects may optionally be given a unique name within a particular ODMS—this name can be used to locate the
object, and the system should return the object given that name.24 Obviously, not all individual objects
will have unique names. Typically, a few objects, mainly those that hold collections of objects of a particular object type—
such as extents—will have a name. These names are used as entry points to the database; that is, by locating these objects by
their unique name, the user can then locate other objects that are referenced from these objects.
Other important objects in the application may also have unique names, and it is possible to give more than one name to an
object. All names within a particular ODMS must be unique.
The lifetime of an object specifies whether it is a persistent object (that is, a database object) or transient object (that is, an
object in an executing program that disappears after the program terminates). Lifetimes are independent of types—that is,
some objects of a particular type may be transient whereas others may be persistent.

4. The structure of an object specifies how the object is constructed by using the type constructors. The structure specifies
whether an object is atomic or not. An atomic object refers to a single object that follows a user-defined
type, such as Employee or Department. If an object is not atomic, then it will be
composed of other objects. For example, a collection object is not an atomic
object, since its state will be a collection of other objects.25 The term atomic
object is different from how we defined the atom constructor in Section
11.1.3, which referred to all values of built-in data types. In the ODMG
model, an atomic object is any individual user-defined object.All values of the
basic built-in data types are considered to be literals.