Re: The Fact of relational algebra (was Re: Clean Object Class Design -- What is it?)

Bob, I would strongly argue that you're on very thin ice now.

An object has unique identity, independent of its state (values), location and structure.

That is, we must be able to modify, rename, move, replicate or even change its structure and it should still hold the exact same identity. That's the very fundamental concept of strong object identity!!!

So, the idea is to have global unique OID's (GUID's) that should have absolutely no business meaning and should be absolutely transparent to the user.

Now, a relational database is 'value based' rather than 'object based' and therefore is not able to enforce the concept of such 'strong' or 'immutable' object identity (if you change or restructure the values making up the key the record/domain's identity will break).

Now, this is not a problem if we live in a perfect mathematical dream world. That is, if we only have one ugly "big brother" of a relational database and never cache anything (i.e. key values from cursor result sets) anywhere (in client apps, spread sheets, web-pages/cookies. legacy systems, and so on) and if people (users, developers) are 'perfect people' and never makes mistakes. That is, database modeller always define unique key's according to some well defined naming schema (i.e. a global vehicle identification number, what-so-ever) that will *never change* (which is impossible of course) and users never use stupid keys (such as telephone numbers) and type in wrong keys when they record stuff in the database.

In short, no one must never ever be able to change the values making up the relational key. If they do so, the concept of strong object identity is lost in references cached outside the database. Basically everything will 'break down' and that's exactly what happens in real life (everything screws up) not having any concept of strong object identity (such as system generated GUID's for example).

This is the very nature of 'real life' distributed computer systems. They reflect (whatever mathematicians like it or not) the real world we live in. That is, they evolve and changes all the time. This is also the reason why SQL:1999 now have the concept of OID.

Okay, the actual relational database may not break down (because of constraints enforcing internal integrity of the data), however, all the other systems communicating with it will. I really can't see how anyone
(even the most hardcore relational theorist such as you Bob) can run away
from this fundamental problem.

I'm not saying that relational keys are the root to all evil (only 45% of all maintenance problems ;-)

The fact that programming languages (i.e. java, c++) supports object identity in the form of so-called pointers (i.e. physical object address, what-so-ever, who cares) and therefore can't enforce such strong identity concept either (of course), has nothing to do with that object-databases (or whatever object systems that may implement the concept of 'strong object identity') have a weaker 'relationship concept' that relational databases. I agree on that one (that the traditional oo relationship concept are conceptually weak), but this has absolutely nothing to do with the fact that we need some kind of global transparent unique object identity mechanism.

IMO, that of object identity is a very nice and deep concept from the object world. A story that some relational people seem not to accept or understand
(or maybe the simply refuse to) because they live pretty much in their own
little centralised 'relational world' as opposite to the extreme object people living in their world of crappy 'rules of thumbs' technologies (i.e. xml, ejb, arrays, the traditional class, and so on) lacking conceptual modelling. That is just as equal insane sure, but is really another story
(and sorry about the rant by the way). Nothing is that black or white, I
know that.

Now, IMO, the key to get a real life system running is to have both the concepts of strong and transparent object identity as used in the object world, and also the concept of relations and 'relational keys' as used in relational theory in order for humans to communicate and lookup 'objects' according to some identification relative to some identification context. Yes we need the concept of 'relational keys' too.

The idea is that your object may belong to many such identification contexts, but have only one GUID. Received on Thu Oct 18 2001 - 11:53:14 CEST