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

Jan Hidders wrote:
> Marshall Spight wrote:
> > [coalescing two messages.]
> > Jan Hidders wrote:
> >
> >>Marshall Spight wrote:
> >>
> >>Me personally? It raises all kinds of new and intricate research
> >>questions that seem mathematically challenging. That doesn't mean that I
> >>don't think XML is practically useful, on the contrary, but this is what
> >>primarily fascinates me about it.
> >
> > Hmmm. I detect a hint of "I like it because it's complicated."
> > That concerns me.
>
> Well, you just will have to trust me on that one. :-)

Okay, I trust you.

> > Does that mean it's not statically typed? I don't see how you
> > could statically type whether a string belonged to a regular
> > expression or not, at least not if you wanted to have regular
> > strings be assignable at runtime.
>
> The typing system is essentially a named typing scheme, so the user
> defines the subtype relationship (which can be checked statically).

Okay. So maybe things like constructing string that conform to regular expressions is checked at runtime, but then you have a type for it?

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

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

I want to call them opaque keys. :-)

They have another useful property as well, in that they won't collide with other opaque keys when you move data from one database to another.

> >>I basically have the FDM data model in mind, but modernized a bit.
> >
> > I'd like to read more about this. It seems like there are some acm
> > papers on this; I can try to get some of them. Any favorites?
>
> http://citeseer.ist.psu.edu/calvanese94making.html

Printed it out but haven't had a chance to read it yet. Soon.

Marshall Received on Wed Jun 29 2005 - 19:31:41 CEST