Oracle FAQ Your Portal to the Oracle Knowledge Grid


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

From: Jim Melton <>
Date: Sun, 02 Sep 2001 07:40:17 GMT
Message-ID: <>

Bob Badour wrote:

> Jim Melton wrote in message <>...
> >
> >Bob Badour wrote:
> >
> >> >The only
> synthetic
> >> IDs.
> >>
> >
> >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.
> Please use well-defined terms. Object variables (instances) have intrinsic
> identity as do all variables. However, this does not help users disambiguate
> similar yet separate variables.

An object is an object. A "thing" under consideration. This concept of object identity is independent of computers and databases. "The red-haired woman whom I saw cross the street last Tuesday" is an object. "The block of data residing in sector 2057, track 32 of disk B" is an object. "The complete financial record of Bob Badour" is an object.

Frequently, users *do* have a hard time disambiguating similar "variables". (Can you tell twins apart?). That's why query by example is a powerful user interface technique. When the user says, "That one" he is using a "pointer".

> >This notion of intrinsic identity is reinforced in object
> >databases by our pointers to objects.
> entities have not logical identity? That users cannot disambiguate similar
> entities?

Often not. Logical identity is independent of the value of temporally changing attributes, yes? But if all I know about something is "The red-haired woman whom I saw cross the street last Tuesday", there is not suffient information to represent logical identity, unless I make up an arbitrary identifier. There is no reason to assume that another red-haired woman crossing the street next Tuesday will necessarily be the same woman.

However, if I want to accumulate evidence in support of a hypothesis, all information, no matter how sketchy can be of value. A way to reference the data that recognizes its intrinsic identity is required.

> >In a relational database, the paradigm is
> values
> >are changed.
> pretentious, nebulous terminology. Instead of calling everything a paradigm,
> try identifying exactly what you want to say. Instead of calling everything

This is why it's really hard to talk to you, Bob. I said exactly what I wanted to say.

From Miriam Webter (
paradigm: 1 : EXAMPLE, PATTERN; especially : an outstandingly clear or typical example or archetype

object: 4 : a thing that forms an element of or constitutes the subject matter of an investigation or science

> manipulates data entirely within the DBMS process.

Really. Can I send a set-oriented command to the RDBMS to find a least-squares path through a series of points? Can I send a set-oriented command to the RDBMS to find a statistical probability that two measurements (including their error distributions) represent the same event? Can I send a set-oriented command to the RDBMS to predict the likely next state of a Markhov model?

Believe it or not, sometimes people want to apply algorithms to the result of a query. In that (extremely common) case, the relational (or SQL if you can prove otherwise) *paradigm* is to copy the data from a result table into a data structure the algorithm can use. Object databases do not require this extra step.

> order to make the data available to the application programming language for
> databases have their own data manipulation language.

You are just creating a different programming environment out of your (theoretical) RDBMS. If all processing occurs in the context of the DBMS, the system cannot scale well and the DBMS becomes a bottleneck. Unless your RDBMS data manipulation language can support all the kinds of algorithms that are coded in other languages, this is (at best) a red herring.

> >The
> >manipulated (conceptually) directly.
> This is simply untrue. Conceptually, one must control persistence, and the
> term persistence, itself, implies a copy of data.

No, persistence merely implies that the data exists outside the scope of program execution. How this is accomplished is a *physical*, implementation detail. Remember bubble memory? It didn't lose state even after power was removed. Persistence without data copy.

> there
> >is copying going on. However, an object reference allows me to manipulate a
> >persistent object directly without regard to this copying.
> programmer must still specify which object variables get copied into and out
> of the application programme's memory. At a conceptual level, the programmer

One certainly can. It is this point exactly that I was making above. Because the ODBMS makes a persistent object reference *look* exactly like any other programming language variable (pointer, if you wish), the application programmer has no concern for the copying of object variables into/out of memory.

Conceptually, the programmer must query the database for objects of interest, but this is not a concept unique to persistent data. Often transient collections of things will be queried to find the subset of interest.

Conceptually, the programmer must be cognizant of transaction boundaries and transaction semantics. I can't think of any way to avoid this unless you give up the concept of ACID transactions (including rollback). That loss would be too great to bear, so the burden for transaction semantics must continue to rest with the programmer.

> >philosophical/architectural differences between object databases and
> >relational/SQL databases)
> especially in an intellectual discipline.

My dictionary had a slightly different definition (see above). Or, if you prefer, try:


Your point?

> The object oriented community have false assumptions, nebulous concepts,
> warped values and arbitrary practices. The relational community have
> explicit assumptions, precisely defined concepts, principled values and
> reasoned practices.

My, you are painting with an awfully broad brush tonight. All of this because you chose to react to my choice of words instead of the point I was making?

> "paradigms".

Let me try to be more precise for you. Physical copying (or even logical copying?) is a fundamental difference between programming with a result-table (or cursor) database and an object database. When I say "SELECT A from FOO" I must bind the returned value(s) for A to application-space variables before I can use them. Furthermore, if my algorithm ends up changing the value of A, I must then issue an explicit "UPDATE FOO values (A = newvalue)" to ensure the change is propagated to persistent memory. Note that before this update step, the changed value of A is available to other processing in application space and my application does not have a coherent view of the data space.

In an ODBMS, the same "SELECT from FOO" will return me object reference(s) to FOO objects. If my algorithm needs the A value, it simply uses it [ print obj->a() ]. If it needs to update the value, it does it directly [ obj->a( newvalue ) ]. The data space is consistent within my transaction (a second SELECT statement will automatically see the updated value of A), but not propagated to other transactions until the commit boundary.

Thus, the programmer does not write any code to copy values into or out of application space. The PATTERN (paradigm) of table programming is copying data. The PATTERN (paradigm) of object programming is not.

> >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
> observed
> >or inferred through some phenomenology. Over time, we hope to discover more
> of
> must
> >be distinct from all other objects under consideration.
> consideration?

Different ways in different contexts. QBE is an extremely powerful UI technique.

> >Object databases handle this representation of uniqueness with object
> >references (commonly referred to as OIDs).
> identify unique instances?

See, I don't get your point. An OID is not a pointer. In the database system I use, an OID has a native representation (4 16-bit numbers) and a stringified representation ( #dd-cc-pp-ss ). Neither of these are "pointers" any more than a rowID is a pointer. Yet, because of the operator overloading in OO languages, they can appear as a pointer to the programmer.

Again, though, user interfaces are written to facilitate users doing their jobs. When a user of an on-line ordering system orders a new printer, he does NOT copy the SKU number into an order-entry text field. He clicks on a picture of the product. The user is POINTING to the data of interest. Why can't software do the same thing?

> >SQL databases can generate synthetic
> Except that they are symmetric and do not require navigation.

Pardon me for not being fully cognizant of your vocabulary, but how are they "symmetric" (and how are OIDs not)?

While they do not *require* navigation, they are commonly used for precisely that by the database. But I guess I could argue that OIDs do not *require* navigation. Again, though, they are not of much use without it.

> >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?
> Identity is intrinsic to variables. Relation variables are uniquely
> identified by name. Tuple variables are uniquely identified by relation name
> key value and column name.


> >> >> >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.
> Logically, a contact is identified by some number. The sum of the other
> fields need not be unique and the user must have some method to tell them
> apart. Organizations assign numbers to all kinds of things: employees,
> customers, license holders, benefit recipients, dependents, departments,
> accounts, bins, locations. They were doing that long before computers ever
> came along.

Why? Why is a contact "logically" identified by some number? Do you assign numbers to all the people in your address book? Do you refer to them by number? This is utter nonsense. Arbitrary numbers are implementation artifacts of systems that cannot properly represent intrinsic object identity.

For example, a telephone number is an arbitrary identifier (although more closely related to a pointer) for a specific end-point in the telephone network. In the early days of telephones, an operator was required to physically connect the incoming call with the end-point by plugging a cable into the appropriate hole. Yet, in many rural communities, the end point was not identified by a number, but "Bill Jones' house". As human operators were completely replaced by machines, machine-readable end-point identifiers were required, hence the phone number. But if I had a way to "gesture" to your entry in my "contact database" and pass a direct end-point (pointer) to my telephone (or to my e-mail program, or to my envelope printer), then arbitrary, synthetic IDs would phase out as archaic relics of an unenlightened past.

> >This synthetic ID is stored in each phone number so
> >that it can be joined back to the contact.
> might expose the relationship between contact id and phone number.

If you wish to design your database such that all associations are through a distinct "association table", that's fine. Object modelling has "link classes" that perform the same purpose. But that is a heavyweight solution for simple associations that are commonly modelled by repeating foreign key information in the phone number table.

All you've done is require two distinct identifiers (and allowed phone number to be one) so they can be stored in your association table. Of course, each of these association entries will require a unique identifier...

> contact
> >> must be
> >> >replicated.
> >>
> >> redundant, if not more so.
> >

Since the location of a {thing} is a physical concept, I hope we can agree that a pointer is a physical thing. But you have been (uncharacteristically) sloppy at equating object identifiers with pointers. Since the logical concept I was describing is the association between a contact and his phone number(s), using a pointer to implement this association is a physical implementation. I've already described the nature of OIDs in the database I use and they are not at all dissimilar from rowIDs. Yes, the database can use them to hash directly to a specific object, but they are no more pointers than a phone number is a pointer to your phone.

> >"Home phone: 210
> phone it
> reasonable
> which
> >to join.

Let me be more precise. The phone number above has no *semantic* meaning unless it is associated with the person whose phone it is.

> logical identifer, it is reasonable to expose the relationship to the user
> by combining the identifiers.

And you would expose this to the "user" as "Contact ID A473B has (a) phone 210 555 1212". This is the combination of the (il)logical identifiers.

> >> Nothing prevents you from doing that. The relational model only requires
> >> association between the phone number and the department explicitly using
> >> values regardless of how the DBMS physically establishes the association.
> >
> object
> >database. The fact that there may be an association (pointer, if you wish)
> with
> the
> >accomplish).

I (honestly) point out a real short-coming with the (real) commercial product with which I program. There is no fundamental reason why this should be so, but it is so and I refuse to play "what if" games. As you are so fond of saying, a failure of commercial products is not a failure of the model.

> ...
> The phone number must have a logical identifier, possibly the phone number
> able to easily identify contacts.

Synthetic IDs are evil because they carry no semantic content. How often have you mis-dialed a phone number? How many of your credit card or frequent flier numbers do you have memorized? A "logical" model that forces more of these into the interface is flawed.

Information is identified in context. If I were to go to the Washington, D.C. phone book and look up "Bob Badour", I would find 0 or more matches. There is no reason for me to assume that any of these people is the person with whom I have been having this conversation for these weeks. I identify you "uniquely" as the Bob Badour who has been posting in comp.databases.object. I do not create a number to represent you.

> >You seem
> >to be mandating that synthetic IDs be created to be used in a logical join
> that
> Define synthetic. Unless you advocate a complete lack of logical identity,
> the user will need to have some means to identify contacts and some means to
> identify phone numbers. Use those means.

Logical identity is synonymous with what I called an object's intrinsic identity.

Quite often humans disambiguate by pointing. When you walk through the cafeteria line, you point to the lady with the scoop which jello salad you want, since it is the most precise "identifier". When I call my parents, I hit the speed dialer (I don't remember their phone number). Since users point, it seems that you are advocating pointers :-)

> >The English language has only a very few concepts: noun, verb, adjective,
> >think anyone would argue that mastering it is simple.

Hmmm. If I'm missing all these concepts and ignoring complexity, perhaps it's not so complex after all. Otherwise, shouldn't this complexity be causing me untold grief?

> >Relations may be simple, but that does not mean that their usage may not be
> >exceedingly complex.
> Relations and the relational algebra are much simpler than the english
> language. It is true that one can model real-world systems to arbitrary
> levels of complexity with this simple interface. What I don't understand is
> any insistence on adding further needless complexity.
> >Cognitive modelling has shown that human beings can only
> >keep a finite number of concepts in active memory.
> relational model.

You've missed the point. Why does FedEx assign a tracking number to your package? Because identifying "the package that Bob Badour sent to Jim Melton on Sept 1, 2001" is too complex (although it can easily be represented as a relation). People routinely create concepts that may "add complexity to the interface" in order to sheild themselves from greater complexity.

> >In order to deal with more
> >complex things, we hide complexity behind abstractions.
> Relations are very simple abstractions.

One could represent all data as sequences of name-value pairs. Such data would extremely simple, but exceedingly complex to work with, because the sequence would be devoid of semantic content.

> >Object classes have interfaces that reflect the complexity that is
> >already inherent in the data.
> Unfortunately, object classes often go beyond this and expose the complexity
> inherent in the physical representation of the data as well as that inherent
> in the data itself.

One must question if you understand object technology at all. Since it is completely possible to declare a class that is all interface and no implementation (no data members), it is ludicrous to assert that object classes expose implementation details (physical representation).

> >Sure, you can argue that a user must understand
> that
> >is any different in any paradigm.

Obviously not. Why don't you offer an alternative that won't push your hot button.

> Users understand relations with very little effort because all relations
> have an identical interface using identical operations.

Syntax is never particularly interesting. Knowing *what* I can do is a far cry from knowing *why* I would want to do it (and when I would NOT want to do it).

> >If I don't understand the way all the tables
> productive
> >will I be?
> are related.


We have a diagram that depicts all the tables and relationships between tables in a particular database used by our customer. It is incomprehensible. There is NO hiding of complexity -- it is all out before us with no way to break it down into bite-sized pieces. I can tell exactly how each table is related, but I can't figure out what the tables MEAN, which means I can't use the data productively.

> >out anyway.
> every possible relation, and I must point out that object classes handle the
> job very poorly.

See above.

> >relationships).
> fact, I have found many experienced, skillful application programmers who do
> not find them at all natural.

It all depends in what circles you move, I suppose. Here in comp.databases.object I think your findings would be somewhat different.

> You have yet to exhibit any understanding.

 ... to your satisfaction.

One of the difficulties in discussing things with you is that you cannot agree to disagree. You must be right and I must be wrong. I see your point. I do not agree with it. Statements such as the above exemplify the allegation I made a while ago about you being an intellectual snob (or something like that). It is quite a condescending remark.

I will readily admit that I do not have the "official Date & Pascal" vocabulary for describing purist relational theory internalized. I may not use your words with the precision that you would like. I would not even pretend to debate you on the finer points of relational theory. But I have used databases that are called relational and I have used database that are called object-oriented. I have decades of experience in writing software for large, complex systems. And IN MY EXPERIENCE, complexity is best managed through the use of objects.

Once again, I don't ask you to agree with me.

> One cannot start with a simple interface and make it more simple by adding
> features.

Decomposing the works of Shakespeare into it's component letters and storing each letter with a frequency count would be a simple interface. But I think it could be made simpler by adding features...

e-mail: | computer has never had

Received on Sun Sep 02 2001 - 02:40:17 CDT

Original text of this message