Re: relationship in the database
Date: 25 Sep 2002 19:10:48 +0200
Message-ID: <3d91ee18$1_at_news.uia.ac.be>
In article <61c84197.0209250311.5660da8c_at_posting.google.com>,
Peter Koch Larsen <pkl_at_mailme.dk> wrote:
>hidders_at_hcoss.uia.ac.be (Jan.Hidders) wrote in message
>news:<3d8b67a4$1_at_news.uia.ac.be>...
>>
>> A solution could be that the trigger only fires if on tuple has been
>> removed and another has been added. Of course this is somewhat of a trick
>> because how do you know that the one is replaced by the other and not one
>> has been removed and another added? The answer would be that something
>> like for the latter you would use two assignments. So actually what you
>> are doing is making assumption about the databases is updated, i.e.,
>> assuming certain dynamic constraints.
>
>But the consequence is then, that relational assignment is nothing
>more than a single tuple update.
No, the consequence is that some assignments are recognized as a single tuple update.
>I will repeat myself (from another post): relational assignment sounds
>good at first sight, but not all practical problems can be solved via
>assignment as the transitional aspects are lost. In my mind, the
>consequence is that that what corresponds to an SQL UPDATE can not be
>supported via relational assignment and that some kind of
>update-operator must come into play.
But I have just shown how it can be done! What was wrong with that, except that it is kinda ugly?
>Those favouring relational assignment (and I actually am one of them)
>must define this operation in a formal way, taking into account in
>particular how entities are identified (when there are multiple
>candidate (or using Jan Hidders terminology: super-) keys). They must
>define the meaning of "new" tuples and tuples that disappear, and they
>must determine which triggers are called and when.
I used the term "strong key" (a super-key is already something else). A fancier name is "diachronic key" as it tells you accross time when two tuples represent the same entity. Note that every diachronic key is also a candidate key but not every candidate key is necessarily a diachronic key. However, this notion may not always solve the problem because often it is exactly this key that is updated, and then you still have the problem that one entity has disappeard and another one (with a different diachronic key) has appeared after the assignment.
>Purists may reject this on the grounds, that the purity of the model
>suffer, but the alternative is a model that does not reflect reality,
>and if you must choose between simplicity and reality, the choice
>should not be so difficult.
That's funny, because that is exactly why I suggested that the ER model is often a better data model then the Relational model. There the notion of update of an entity is much more natural.
- Jan Hidders