Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> comp.databases.theory -> Re: Clean Object Class Design -- What is it?

Re: Clean Object Class Design -- What is it?

From: Jim Melton <>
Date: Sat, 01 Sep 2001 06:53:27 GMT
Message-ID: <>

Bob Badour wrote:

> >The only
> >way to model the associations as value-based would be to create synthetic
> IDs.
> Why? Do the entities you manipulate have no logical identity?

One of the fundamental concepts of object technology is that objects have intrinsic identity independent of any attribute values they may posess at any point in time. This notion of intrinsic identity is reinforced in object databases by our pointers to objects. In a relational database, the paradigm is always to copy the data out of the database, perform some manipulations (as required), then find the appropriate record(s) again and modify whatever values are changed. In the object database, this data copying step is eliminated. The database becomes much less of external entity (conceptually) and data is manipulated (conceptually) directly.

I say conceptually, because obviously as data is moving to and from disk there is copying going on. However, an object reference allows me to manipulate a persistent object directly without regard to this copying.

(By the way, I consider this whole difference in paradigm with regard to explicit copying into/out of the database as one of the key philosophical/architectural differences between object databases and relational/SQL databases)

This whole concept of intrinsic identity is extremely critical in my domain because often we do NOT know what attribute value could be used to uniquely identify an object. Sometimes, all we know is that there is an object observed or inferred through some phenomenology. Over time, we hope to discover more of the attribute values attributable to that object, but in the mean time it must be distinct from all other objects under consideration.

Object databases handle this representation of uniqueness with object references (commonly referred to as OIDs). SQL databases can generate synthetic IDs such as rowID (that are virtually the same as OIDs). However, if there are no attributes that can be used to create a distinct relation, how would a relational database handle this concept of intrinsic identity?

> >> >I find attribute joins
> >> >problematic, especially where they force synthetic IDs into the data
> model
> >>
> >> Do you mean you would prefer not to have any form of logical identifier?
> You
> >> will find such a lack much more problematic.
> >
> >I find that a normalized model does not usually consist of stand-alone
> >entities. For example (again), a contact database should have multiple
> phone
> >numbers for a contact.
> And the user should have some method for identifying each of these phone
> numbers. Home, work, fax, cell, emergency, alternate office on tuesdays and
> thursdays...

But you are incomplete. You need a field (pardon me for not using the right term) to join the phone number with the contact record. Since "logically" the contact is uniquely identified by the sum of the fields (name, address, title, company, etc.), in practice a synthetic ID is created to represent the unique identity of the contact. This synthetic ID is stored in each phone number so that it can be joined back to the contact.

> >Perhaps each number would include a "type" tag (home,
> >cell, etc.). In order to associate this phone information with the contact
> >info, either a synthetic ID must be generated or the primary key values
> must be
> >replicated.
> I am not sure I understand your complaint. Are you complaining about
> redundant information in the logical view of the data? Pointers are as
> redundant, if not more so.

A pointer is a physical implementation of a logical concept. "Home phone: 210 555 1212" has no meaning unless it is associated with the person whose phone it is. I believe that coupling is *logically* very tight and that it is reasonable to implement it as a pointer rather than creating synthetic fields upon which to join.

> I question whether any synthetic ID is required. The contact identifier and
> the phone number suffice.

How else would one join the phone information with the contact information? Or by contact identifier did you mean a synthetic ID for the contact record?

> >I'd rather just store the array of phone numbers with the contact
> >where they belong.
> Nothing prevents you from doing that. The relational model only requires
> that you allow the user to query the phone numbers as if they are
> independent of the contact. To the user, the DBMS must expose the
> association between the phone number and the department explicitly using
> values regardless of how the DBMS physically establishes the association.

The first half I can accomodate. I can query against any object in my object database. The fact that there may be an association (pointer, if you wish) with another object is irrelevant. (To be fair, my particular vendor does NOT supporting queries across relationships so a query of the form "Find all the contacts whose home phone is in area code 808" would be difficult to accomplish).

The second part, "the DBMS must *expose* (emphasis mine) the association ... explicitly using values" I don't understand. If there is no *logical* value that identifies the association, how should this exposure take place. You seem to be mandating that synthetic IDs be created to be used in a logical join that are not necessary in either the logical or the physical level.

> >> Purity is not the issue. Simplicity and comprehensibility are. Users will
> >> not get the answers they want when confronted with a complex,
> >> incomprehensible representation of the data.
> >
> >I find an object database a marvelous tool for managing complexity. To each
> his
> >own.
> Then I must question whether you understand the concept. If every object
> class has a different, unique interface, the user has a huge amount to learn
> before the user can become productive. Relations are simple -- as are
> relational expressions. Objects are complex -- so complex that no such thing
> as an object expression really exists, or ever will.

The English language has only a very few concepts: noun, verb, adjective, adverb, preposition, conjunction (I may have missed one or two). Yet I don't think anyone would argue that mastering it is simple.

Relations may be simple, but that does not mean that their usage may not be exceedingly complex. Cognitive modelling has shown that human beings can only keep a finite number of concepts in active memory. In order to deal with more complex things, we hide complexity behind abstractions. This is one of the core motivations of object technology.

Object classes do not manufacture interfaces for the sake of creating complexity. Object classes have interfaces that reflect the complexity that is already inherent in the data. Sure, you can argue that a user must understand some amount of the object model to become productive, but I don't see how that is any different in any paradigm. If I don't understand the way all the tables are related and what fields join what tables in what context, how productive will I be? Object classes attempt to model what the user already has to figure out anyway.

Object databases use objects naturally to manage complex notions (and relationships). Yes, I understand the concept. I did not ask you to agree with me.

Jim Melton, novice guru             | So far as we know, our
e-mail: | computer has never had
v-mail: (303) 971-3846              | an undetected error.

Received on Sat Sep 01 2001 - 01:53:27 CDT

Original text of this message