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

Hi Jesper,

First, let me state my position - I am strongly on the relational side of the debate. <g>

Whilst I agree with _some_ of what you write, I think there needs to be a fundamental distinction made between "database" (or "model" or even "dbms") and "application". Relational theory, value semantics, and suchlike are applicable to the "database", whilst objects, IDs, OIDs, references and suchlike belong to the "application" domain. The fundamental reason for making such a distinction is so that the "database" can safely and consistently support the execution of _multiple_ applications concurrently. If there is only one application to be supported, then by all means chuck relational theory and suchlike out the door, and use an OO-DBMS (although imo that term is somewhat oxymoronic!)

<snip/>

> 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).

<snip/>

> 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.

Exactly, because the relational key _is_ the "object identity" (sic). Changing the key makes it an entirely _different_ "object".

> 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).

<snip/>

> 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.

Because it's _not_ a "problem" at all. It's a feature - one of the very elegant and advantageous things about the relational model. If systems communicating with the database have been so poorly designed and implemented so as to not undertand that the current state of the database is _always_ authoritative, and that (without explicit locking protocols having been succesfully executed) the data contained therein may change at any time, due to the operations of _other_ client systems of the dbms, then those external systems are entirely at fault, and deserve to break down!

<snip/>

> 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.

Why? Candidate key values are precisely and exactly "global transparent unique tuple identity mechanisms" and all that is required (or indeed supportable) in a relational dbms.

<snip/>

> 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.

Yes, object identity etc. are all well and good for implementing an _application_ ("real life system"), just so long as you don't _ever_ assume that the database itself has to provide support for them. That is entirely analagous to the "horse riding the jockey".

cheers,

gary Received on Fri Oct 19 2001 - 04:15:23 CEST