Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]
Date: Wed, 29 Jun 2005 19:44:09 GMT
Message-ID: <dSCwe.133254$g25.7165020_at_phobos.telenet-ops.be>
Marshall Spight wrote:
> 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.
Thank 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?
Yes. You probably already realized this but note that XML Schema is not tied to a programming language, it only specifies the schema so it only has to say how a certain attribute or content is constrained. What it does not do is tell you how expressions in a certain programming or query language that manipulates XML are typed, that is up to the language in question. Only when you start putting the result of the computation into certain parts of document then XML schema really kicks into action and possibly disallows the update. However, XQuery indeed uses the types in XML Schema to do it's typing so some (not all) typing errors are already detected earlier on.
>>>>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.
>>>>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. :-)
Then that is what they are.
> 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.
Exactly.
>>>>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.
There's no rush. The paper gets quite technical at the end and that's probably not the interesting part for this discussion. What I hope it makes clear is (1) how easy it is to define such a data model in a formal, concise and elegant way and (2) how expressive such a data model can be.
- Jan Hidders