Object-Oriented Versus Object-Relational

Object-Oriented Versus Object-Relational

The object-oriented data model, as typified by ODL, and the object-relational model discussed here, are outstandingly similar. Some of the most important points of comparison follow.

Objects and Tuples

An object's value is actually a struct with components for its attributes and relationships. It is not specified in the ODL standard how relationships are to be represented, but we may suppose that an object is connected to related objects by some collection of pointers. A tuple is similarly a struct,  but in the conventional relational model, it has components for only the attributes. Relationships would be represented by tuples in another relation, as suggested in "From E/R Relationships to Relations". However the object-relational model, by allowing sets of references to be a component of tuples, also allows relationships to be included directly into the tuples that represent an "object" or entity.

Extents and Relations

ODL treats all objects in a class as living in an "extent" for that class. The object-relational model allows numerous different relations with identical schemas, so it might appear that there is more opportunity in the object-relational model to distinguish members of the same class. On the other hand, ODL allows the definition of interfaces, which are basically class declarations without an extent (see the box on "Interfaces" in "Extents"). Then, ODL allows you to define any number of classes that inherit this interface, while each class has a distinct extent. Thus, ODL offers the same opportunity the object-relational approach when it comes to sharing the same declaration among numerous collections.


We did not discuss the use of methods as part of an object-relational schema. However, in practice, the SQL-99 standard and all implementations of object-relational ideas allow the same ability as ODL to declare and define methods linked with any class.

Type Systems

The type systems of the object-oriented and object-relational models are quite similar. Each is based on atomic types and construction of new types by struct- and collection-type-constructors. The selection of collection types may vary, but all variants contain at least sets and bags. Furthermore, the set (or bag) of structs type plays a special role in both models. It is the type of classes in ODL, and the type of relations in the object-relational model.

References and Object-ID's

A pure object-oriented model uses object-ID's that are entirely hidden from the user, and thus cannot be seen or queried. The object-relational model allows references to be part of a type, and therefore it is possible under some circumstances for the user to see their values and even remember them for future use. You may regard this situation as anything from a serious bug to a stroke of genius, depending on your point of view, but in practice it appears to make little difference.

Backwards Compatibility

With little difference in fundamental features of the two models, it is interesting to consider why object-relational systems have dominated the pure object-oriented systems in the marketplace. The reason, we believe, is that there was by the time object-oriented systems were seriously proposed, a huge number of installations running a relational database system. As relational DBMS's evolved into object-relational DBMS's, the vendors were careful to maintain backwards compatibility. That is, newer versions of the system would still run the old code and accept the same schemas, should the user not care to adopt any of the object-oriented features. On the other hand, migration to a pure object-oriented DBMS would require the installations to rewrite and reorganize widely. Therefore, whatever competitive advantage existed was not enough to convert many databases to a pure object-oriented DBMS.