Re: What makes an OODBMS different from an RDBMS?

Sajai,

Carl Rosenberger has given you a good first pass at the differences.

Here's my $0.02.

SQL is not, strictly speaking a "programming language". Rather, it's an "interface language". Although not originally part of the relational model, it has become the de facto interface language for all relational DBMS systems. So much so, that Joe Celko asks people who pose a question concerning the value of a given database design in the form of "create table" statements that are free from any DBMS product extensions to the standard language. There is value to that stance, my own quibbles notwithstanding.

There is no "standard interface" between OODBMS products, and the corresponding programming environment. In a way, a standard interface would be superfluous, given what Carl said about the tight binding between the programming environment and the data storage environment. There are two consequences to this absence of a standard interface.

The first is that it's a little easier to produce products that do well with regard to performance, for certain kinds of retrievals. Relational products are necessarily so general that they are seldom tuned in what I'll call a "high Q" mode of tuning (borrowing a term from mechanical engineers).

The second is that it's almost impossible to share data stored in an OODBMS in a multiple, heterogeneous application environment. If data stored in a relational database is to be shared between one application written in COBOL and another one written in C++, the problems occasioned by the language differences will be relatively minor, and will all be mediated somehow by the interface between SQL and the programming language run time system. There is no corresponding flexibility in the OODBMS products that I've seen.

There is a third difference, one that I regard as incidental rather than fundamental, although it's closely related to the second difference above. It's about how the object model that drives the logical design gets propagated to all the accessors of the contents of the OODBMS.

In most relational products, a statement like a "create table" really results in two actions on the database. The first is to create the table itself, using data structures that are often internal to the product, and of no interest to SQL users. The second is to catalog the table thus built in a "data dictionary" that is itself a schema of tables stored elsewhere in the same database. This allows data in a relational database to be self describing. This in turn allows reconciliation, at run time between the data model used in the latest revision of the database and the data model used in the compilation of the accessing program.

If there is a skew between the database's data model and the program's data model, this skew can either be mediated by the interface, in some cases, or in other cases an error can be reflected to the accessor. This turns out to be of enormous value in the practical world of application maintenance, in the face of revision and extension of the database itself.

It's possible that there is a parallel construct in the world of OODBMS products. If so, it's escaped my notice. Admittedly, my contact with OODMS products has been from a distance. Anyway, in the absence of a parallel construct to the "data dictionary", preventing harmful skew between programs that access the same database becomes a responsibility of the application designers.

--
Regards,
    David Cressey
    www.dcressey.com