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

Marshall Spight wrote:

> [coalescing two messages.]
> Jan Hidders wrote:
> 

> 
> 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. :-) Unnecessary complications are the enemy of the theorist. They make his/her work less pleasant and the chances of finding something interesting and useful much smaller.

>>Oh yes. Everything you mention above is in there, including key
>>constraints. The typing system is also very elaborate, it even allows
>>you to define certains sets of strings described by regular expression
>>as strings, and is user-extensible.

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

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

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

• Jan Hidders