3.1 Introduction
The OODBS Manifesto was published by a group of researchers in 1989 [Lar95], in order to produce a consensus on the requirements that an OODBS should meet.
These features include the following:
1. Complex objects. Basic objects can be combined into complex objects.
2. Object identity. Each data object must have a unique identifier.
3. Encapsulation. The data and the implementation of its operations are hidden from users.
4. Classes. The common features of a set of objects with the same characteristics are specified.
5. Inheritance. A subclass will inherit attributes and methods from its superclass.
6. Polymorphism. The implementation of the operation depends on the object to which it is applied.
7. Computationally complete. Any computational function can be expressed in the data-manipulation language.
8. Extensibility. New classes can be added to the system-supplied classes.
9. Data persistence. Data must remain available after the application that created them has terminated.
10. Very large databases. Store data on secondary storage in such way that large databases can be supported.
11. Concurrency. Multiple users can use the database at the same time.
12. Recovery. Recovery mechanisms enable the database to be restored in the event of software or hardware failures.
13. Ad hoc queries. Users may specify requests in a high-level, application independent form.
The Object Management Group (OMG) is an international industrial consortium founded in 1989 [Bur98] to address the issues of object standards. The group has more than 700 member organizations including virtually all platform vendors and major software vendors such as IBM, Sun, DEC, Microsoft, Apple, AT&T/NRC.
The aim for the OMG is to develop de facto standards that will eventually be acceptable to ISO/ANSI. In 1990, the OMG published its Object Management Architecture (OMA) Guide document. This guide specified a single terminology for object-oriented languages, systems, databases, and applications. Four areas of standardization were identified: the Object Model (OM), the Object Request Broker (ORB), the Object Services, and Common Facilities.
3.2 The Object Database Management Group (ODMG)
During the summer of 1991 were the ODMG (Object Database Management Group) formed with several important vendors including GemStone Systems, Object Design, O2 Technology, Versant Object Technology, UniSQL, Poet Software and Objectivity. The participating ODBMS vendors represent over 80 percent of the total marketplace. The ODMG has produced an object model that specifies a standard model for semantics of database objects. The model
determines the built-in semantics that OODBMS uses. The design of class libraries and applications that use these semantics should be portable across the various OODBMSs that support the object model.
The major components of the ODMG architecture for an OODBMS are:
• Object Model (OM).
• Object Definition Language (ODL).
• Object Query Language (OQL).
• C++ language binding.
• Smalltalk language binding.
• Java language binding.
The initial version of the ODMG standard was released in 1993[Cat94] and in September 1997 the ODMG 2.0 was released. The ODMG 2.0 has enhancements that included:
• A new binding for Java programming language.
• Fully revised version of the object mode, with a new metamodel supporting object database semantics across many programming languages.
• A standard external form for data and the data schema, allowing data interchanges between databases.
The latest version is the ODMG 3.0 [Cat00], which includes a number of enhancements to the Java binding. It incorporates improvements to the object model. It also includes various corrections and enhancements, including changes necessary to broaden the standard for use by object-relational mapping systems as well as for the original target of the standard, object DBMSs.
3.2.1 Object Model
ODMG Object Model (ODMG/OM) [Cat00] is a superset of the OMG Object Model (OMG/OM).
The Object Model summarized:
• The basic modeling primitives are the object and the literal. Only objects have a unique identifier.
• Objects and literals can be categorized into types. All elements of a given type have a common range of states and common behavior. A type is itself an object.
• The state of an object is defined by the values it carries for a set of properties.
These properties can be attributes of the object itself or relationships between the object and one or more objects.
• The behavior of an object is defined by the set of operations that can be executed on or by the object.
• An ODMS stores objects, enabling them to be shared by multiple users and applications. An ODMS is based on a schema that is defined in ODL and contains instances of the types defined by its schema.
3.2.2 The Object Definition Language
The Object Definition Language (ODL) is a specification language for defining the specifications of object types for ODMG-compliant systems. Its main objective is to provide portability of schemas between compliant systems while helping to establish interoperability between OODBMSs. ODL is not intended to be a full programming language. DBMSs have traditionally provided facilities that support data definition, using Data Definition Language (DDL), and data manipulation, using Data Manipulation Language (DML). The DDL allows users to define their data types and interfaces. DML allows programs to use instances of those datatypes by creating, deleting, reading, and changing them. The ODL is equivalent to the Data Definition Language of traditional DBMSs.
Several principles have guided the development of the ODL [Cat00], including:
• ODL should support all semantic constructs of the ODMG Object Model
• ODL should not be a full programming language, but rather a definition language for object specifications.
• ODL should be programming language independent.
• ODL should be compatible with the OMG's Interface Definition Language (IDL).
• ODL should be extensible, not only for future functionality, but also for physical optimizations.
• ODL should be practical, proving value to application developers, while being supportable by the ODMG vendors within a relatively short time frame after publication of the specification.
3.2.3 The Object Query Language
The Object Query Language (OQL) provides declarative access to the object database using an SQL-like syntax. It does not provide explicit update operators, but leaves this to the operations defined on object types. OQL can be used as standalone language and as a language embedded in other languages, for which an ODMG binding is defined. The currently supported languages are Smalltalk, C++,
and Java. An OQL query is a function that delivers an object whose type may be inferred from the operator contributing to the query expression.
The design is based on the following principles and assumptions [Cat00]:
• OQL relies on the ODMG Object Model.
• OQL is very close to SQL-92. Extensions concern object-oriented notions like complex objects, object identity, path expression, polymorphism, operation invocation, and late binding.
• OQL provides high-level primitives to deal with sets of objects but is not restricted to this collection construct. It also provides primitives to deal with structures, lists, and arrays and treats such constructs with the same efficiency.
• OQL is a functional language where operators can freely be composed, as long as the operands respect the type system. This is a consequence of the fact that the result of any query has a type that belongs to the ODMG type model and thus can be queried again.
• OQL is not computationally complete. It is a simple-to-use query language.
• Based on the same type system, OQL can be invoked from within
programming languages for which an ODMG binding is defined. Conversely, OQL can invoke operations programmed in these languages.
• OQL does not provide explicit update operators but invokes operations defined on objects for that purpose, and does not breach the semantics of an object model.
• OQL provides declarative access to objects. Queries can be optimized by virtue of this declarative nature.
• The formal semantics of OQL can easily be defined.