DBMS - July 1997 - Sidebar - The Object Database Management Group

The Object Database Management Group

By Brian Jepson
DBMS, July 1997

What's Inside the ODMG-93 Standard?

If the idea of yet another standard has you running and screaming, hold off a second and check out ODMG-93. Anyone who has built a relational database system using an object-oriented language has probably encountered the "impedance mismatch problem," which is a polite way of referring to the massive difficulties encountered when you try to map complex objects and relationships defined in your runtime system to some sort of tabular representation in your relational database. In practice, programmers generally refer to this problem in less-polite terms. Part of the solution lies within object-oriented database management systems (ODBMSs), but if you're still using some variant of a call-level interface to read and write data from the database, you haven't really done away with the mismatch, have you?

What Is It?

ODMG-93 addresses the boundaries between the ODBMS and certain object-oriented programming languages; when the language and the database support nearly identical semantics, why should there be, as the draft ODMG Java binding puts it, "arbitrary boundaries?" The philosophy guiding the ODMG standard is put quite well in the draft of the Java binding: "The programmer should perceive the binding as a single language for expressing both database and programming operations . . . "

What's That in Its Hands?

The ODMG's specification recognizes two types of objects: transient and persistent. Transient objects are stored in and managed by the runtime system, be it Smalltalk, Java, or C++ (three languages for which ODMG bindings exist or for which drafts are in progress). Transient objects are the things that programmers have been using for years; they go away when your program terminates. Persistent objects are managed by the ODBMS, but the programmer doesn't need to know about this. As long as an object is ultimately referenced by a root object in the ODBMS, it's kept around as a persistent object. From the programmer's perspective, persistence is transparent.

The ODBMS schema is defined by an object definition language (ODL). For each language covered by an ODMG binding, the binding requires you to define your database schema using an ODL, which is implemented as classes in the language (Java, C++, or Smalltalk). Similarly, an object manipulation language (OML) is used to manipulate objects, and it doesn't distinguish between persistent and transient objects. ODMG-93 wouldn't be complete without a query language: The Object Query Language (OQL) follows SQL-92 but offers object-oriented extensions and integration with any of the programming languages that have an ODMG-93 binding. An OQL query can be issued from within the language, and the query can also invoke methods written in the language.

How Does It Do It?

ODMG bindings are described in such a way so as not to inconvenience the programmer. In the case of the Java binding, it can be implemented in one of three ways. The Java source code can be fed into a preprocessor, which would alter the code to support the binding. Similarly, compiled Java bytecode can go through a postprocessor, which would alter the bytecodes to use the binding. Another possible implementation involves a modified Java Virtual Machine (JVM) that is "ODMG-aware" and supports the bindings transparently.

What About Relationships?

The ODMG specification describes relational connections between objects. Like their counterparts in the relational model, ODMG-93 relationships may be one-to-one, one-to-many, or many-to-many. One of the complexities in binding a language such as Java to this model is that Java does not offer a means of explicitly specifying these sorts of relationships between class definitions.

You Bet Your Historical Inevitability!

Like the SQL Call Level Interface, ODMG-93 specifies a binding between programming languages and databases. However, ODMG-93 removes the need for the developer to map objects to a relational model "by hand." ODMG-93 seems to promise that the up-front work in database design will reap tremendous downstream benefits; database design tools that follow this model spit out code for your target application development environment, rather than code for your target database environment. Because all of your schema definition will be done in your application language, there is no need for the developer ever to be exposed to the underlying ODBMS. An ODMG-93 implementation will ease the consolidation of the design and implementation of business objects, taking care of database schema definition and application object definition in one swift stroke.

ODMG-93 is evolving toward a Release 2.0 specification that includes the ODMG Java binding. Release 2.0 is expected to be published in 1997, and drafts of certain individual chapters can be found at the ODMG Web site (www.odmg.org) by following the link for "New items, announcements, additional files, and enhancements."

Brian Jepson researches potential uses of (and implements) computing resources for AS220, a nonprofit center for the arts in Providence, Rhode Island. He is the author of two books, World Wide Web Database Programming for Windows NT and Java Database Programming, both published by Wiley Computer Publishing (1996). You can email Brian at bjepson@ids.net.

Return to Nelson King's Article, "Object DBMSs: Now or Never"

What did you think of this article? Send a letter to the editor.

Please send questions or comments to dbms@mfi.com
Updated Wednesday, June 18, 1997