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

From: Alexandr Savinov <>
Date: Fri, 01 Jul 2005 14:48:24 +0200
Message-ID: <42c53ba8$>

Jon Heggland schrieb:
> In article <dSCwe.133254$>,
> says...

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

No, it is completely different idea having a fundamental importance for understanding differences between major directions in data and system analysis. In OO we separate in principled manner two things: 1. how things are represented (by means of references or some other kind of things which we actually never know just because of this separation). 2. how things are described by other things, i.e., fileds, column values etc.

In RM there is not such a separation. Or, if you want, it exists but it is already an additional mechanism or role of some columns. Thus to say that "a person has an identity" in OO is completely different that to say that in RM.

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

With "carful design" we do not even need the relational model and everything can be done in assemply language :-) It is not an argument. Or, following your argument you can well conclude that you do not need the RM. The problem is deeper than you think. There exist such thing as changing the rule how people see what the model. For example, in the time of procedural programming people started thinking differently by associating code with objects. Nowdays, people do not think relationally - that is a problem. In other words, they still use relational tools and databases but the rules of design are already different. And this process has nothing to do with "friendliness", user interface enhancements and other minor issue.

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

Yes, there should be multiple layers where lower layers implement the mechanism of representation and acces for higher levels. But in the RM there is no such a separation we have to keep absolutely different things (object representation/access vs. their semantics) in one box. (The concept-oriented programming is based on such an architecture but we need to change the defintion of classes and the whole paradigm to make it work.)

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

There exist objects that are passed by value. Strictly speaking, they are not objects because they do not have references (and hence concstant location). Think of the following duality:

  • objects: are represented by references; have a constant physical position; stored in collections (sets, containers, logical OR)
  • references: represent themselves (by value); do not have a position, stored in objects (combinations, logical AND)

Any object is defined to store references. Some references represent other objects while other references represent themselves and are referred to as primitive objects.

Received on Fri Jul 01 2005 - 14:48:24 CEST

Original text of this message