Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]

In article <dSCwe.133254$g25.7165020_at_phobos.telenet-ops.be>, jan.hidders_at_REMOVETHIS.pandora.be says...
> Marshall Spight wrote:
> > Jan Hidders wrote:
> >>Marshall Spight wrote:
> >>>Jan Hidders wrote:
> >>>>Let me mention two small things. In the RM if you want to add a
> >>>>one-to-many relationship between two entities you have to extend one of
> >>>>the relations with a foreign key. If there are more than one candidate
> >>>>key you have to choose one of them. In an ER model you don't have to
> >>>>make such a choice, you simply indicate that there is a relationship.
> >>>
> >>>Uh, how is that going to work? If I have a user id and an email
> >>>address as keys, and some user-level detail data (specified as
> >>>many-to-one with users) and I don't specify a key, what happens
> >>>when I change the email address key?
> >>
> >>Then you change the email addres of this user. Why do you think that is
> >>a problem?
> >
> > Because you didn't specify how the detail info joins to the master
> > record. And now we've changed the master record in one out of the
> > two ways we have to identify the master. Which one does the detail
> > consider definitive? It seems like it has to be one or the other,
> > unless you are going to introduce the idea that rows have identity
> > as well as value. You're not going to do that, are you? Think of
> > the children!
>
> Who needs rows? We only have objects (or identities) and binary
> relationship between objects and values (attributes, like between a user
> and an e-mail address) and between objects and objects (relationships,
> like between a person and person-details). So if you change the
> relationship between a person and an e-mail address that has nothing to
> do with the relationship between that person and his/her details, even
> if that address happens to be candidate key (yes that term can be given
> a well-defined and formal semantics here) for a person.

So a person has some "identity" that is independent of the values of his/her properties/details. It is the same idea as row ids, even if no "rows" as such are involved.

> >>>>Another small thing is updating primary keys. If a primary key has
> >>>>accidentally been entered wrong and you want to fix that with an update
> >>>>then it is usually not possible to simply update it, and the problem
> >>>>gets even worse if it is also refered to by foreign keys. In an ER model
> >>>>this is a non-problem.
> >>>
> >>>Would these issue be solved with opaque keys?
> >>
> >>Yes, that is at the core of my suggestion: a decent theoretical
> >>foundation for opaque keys, abstract identifiers, or whatever you want
> >>to call them.

A surrogate key (that you don't show anyone) fulfills the same purpose.

It seems to me that your wishes for a better data model is primarily based on user friendliness. With careful design, the issues you raise with the RM are pretty easily solved (without introducing additional concepts, structures and operators), but the RM does give you enough rope to hang yourself with. It's kinda like old Unix vs. old MacOS :).

Or C vs. Java. Which gives me pause, because I am usually in favour of raising the level of abstraction... Hmmm... Perhaps I am skeptical to your proposals because from my point of view, identity separate from value makes thing more complicated, not simpler. And/or because looking at everything as objects/entities and relationships is a too restrictive worldview for me. I guess I would be happier if this was presented as a layer on top of the RM instead of as a replacement.

Anyway, there is one thing that is bugging me when I read articles about object data models like Calvanese/Lenzerini and Van den Bussche / Paredaens. If objects are just identity points, and the properties of objects are other objects, where do actual data values enter into the picture?

-- 
Jon