Re: oodb <-> rdb

Dulan.Weerasinha_at_brunel.ac.uk (Dulan Weerasinha) writes:

> I am in the process of looking into the possibility of translating
> Object-Oriented concepts to Relational concepts.

I have a couple of simple observations I would like to add to this discussion. First of all, OODB is a much less well defined notion than RDB. I will speak about objects and relations using intuitive semantics from natural language. When I mean RELATION as in RDB, I will capitalize it.

Observation 1. RELATIONS model both objects and relations.

When modelling there seem to be two uses of RELATION in an RDB. One use of a RELATION is for recording the existence of ojects. The other use is for recording relations among objects. For example, a CUSTOMER RELATION has one row per customer. I.e., one row per customer object. A PARTS RESLATION has one row per stocked part, say. A SALES RELATION records the *relation* of a customer buying a part on a certain date for a certain price, say.

Note, the primary use of the SALES RELATION is to record a relation between objects such as customers, parts, dates, and prices. If the sale itself needs to be referred to by other relations, the notion of a sale will be reified into an object, a kind of event object, having some sort of id, say a SALEID, by which it may be referred to as an object. However, many systems will have RELATIONs which are not reified as objects and remain just relations.

The CUSTOMER and PARTS RELATIONs have one row per object they model. They would have key fields identifying the object. (The key field might be a natural one, such as a name, or an artificial one, such as an ID number.) However, these RELATIONs would also model various binary relations which are not modelled via a seperate RELATION, as the relation is single valued, such as a customer primary address or sales rep, or a part bin number or lead time or current inventory count.

The key ideas here are that RELATIONS used to model objects have key fields to identify the objects and, usually, other fields to record single or optional valued relations to other objects. RELATIONS used to model relations may often have no primary key other than the entire set of fields of the relation.

Observation 2. RDBs model objects either as RELATIONS or as values.

The above examples show how some real world objects are modelled as rows of a relation. Another (the other) way an RDB models an object is simply to use field values. For example dates, names, and phone numbers are rarely given their own row in a defining relation, but simply appear as field values of a specified format.

Observation3. RDBs do not support type hierarchies very well.

The OOP concepts of class, involving the notions of inheritence, encapsulation, and polymorphism are nice additions to our programming bag of concepts. They are most clearly what will seperate OODB systems from RDB systems, as DB programming languages take foot. But since they are not supported in any explicit manner in the flat RDB model, they can be put into it in about as many ways as they can be put into standard programming language data models. Keep this in mind.

As an example, suppose a customer can be subcategorized as a preferred customer that receives special credit privledges (say, any customer of a defunct S&L). In an RDB this could be done by just adding a flag field to the CUSTOMER RELATION, or a seperate RELATION PREFCUST could be defined which has one row per preferred customer along with some value fields indicating various properties of the customer. One can also imagine other less perspicuous ways to represent the subtyping. In either case, the notion of subtyping here would be entirely unknown to the RDBMS.

Dennis Allard
allard_at_isi.edu Received on Sat Oct 31 1992 - 02:14:44 CET