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

From: Marshall Spight <>
Date: 1 Jul 2005 10:05:46 -0700
Message-ID: <>

Jon Heggland wrote:
> says...
> > Marshall Spight wrote:
> > > Jan Hidders wrote:
> > >>Marshall Spight wrote:
> > >>>
> > >>>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.

Right. This is something that really bugs me about some of what Jan is talking about.

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

I'm not sure I know what you mean, but I don't think that's right. If the key has a concrete value, then it might collide with a key with the same value when you don't want it to. If the keys are opaque then they won't collide when you move from table to table. Hmm. It's kind of like identity. :-(

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

Right. I think that's the part of what Jan's saying that I'm attracted to; that we might raise the level of abstraction. It would be nice to just declare the relationships and their cardinality, and not have to teach everyone the way foreign key relationships work. I know that sounds like of lame when you say it but it's a very real world consideration.

However, if doing so means we have to reintroduce the concepts of identity or rowids back, then I'd say it wasn't worth it.

> Perhaps I am skeptical to
> your proposals because from my point of view, identity separate from
> value makes thing more complicated, not simpler.

Exactly my feeling.

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

This might be the way to go.  

Marshall Received on Fri Jul 01 2005 - 19:05:46 CEST

Original text of this message