Object-Oriented Database Management Systems extend existing object-oriented programming languages to provide ACID properties. ODBMSs offer a more natural relationship between data and the processing of the data than relational systems. The programming language is transparently integrated with the operations of the DBMS. Also, because objects, not tuples, are the language of the DBMS, the runtime and persistent models remain consistent.
In addition to objects, most ODBMSs offer:
· automatically generated object identifiers,
· inheritance of attributes and operations,
· encapsulation of attributes and behavior,
· schema evolution,
· user defined, extended data types,
· long transactions,
· object migration and distribution between cooperating servers,
· caching of persistent objects on client machines.
Object behavior is maintained close to the data. Some vendor’s products store the binary code for object methods in the database. Others use language specific binary files, linking methods with object data when the objects are accessed.
ANSI SQL and Microsoft’s Open Database Connectivity (ODBC) are supported by most commercial ODBMSs. This is expected to continue to be true as the SQL3 standard emerges. And, it is anticipated that Java Database Connectivity (JDBC) will equally be supported by these vendors.
When these systems were first introduced commercially, their query capabilities and languages varied considerably. However, all ODBMS vendors and other members of the ODMG have now adopted the Object Query Language (OQL).
Most commercial ODBMSs do not have an equivalent to the ER/RDBMS stored-procedure. Therefore, to implement a stored procedure, the behavior must be described in the object model and implemented in the runtime implementation of object model behavior.
Likewise, referential integrity, traditionally supported through triggers or declarative constructs in the relational world, must be described in the object model and implemented in the runtime. The theoretical problem with this is that such things as database rules must be consistently implemented in each application, as opposed to once in the DBMS with most RDBMS and ERDBMS products. If this separation is not managed inconsistencies can arise in the database.
· A single type system is required between the object-oriented programming language and the DBMS.
· Language bindings honor the syntax of the object-oriented language.
· Language bindings are structured as additions to the language.
· Base object-oriented language expressions can be mixed with the DBMSs object manipulation language.
· Any message that can be sent to a transient object can be sent to a persistent object.