Re: relationship in the database
Date: 20 Sep 2002 20:23:32 +0200
In article <am7odp$14r6$1_at_sp15at20.hursley.ibm.com>,
Paul Vernon <paul.vernon_at_ukk.ibmm.comm> wrote:
>>However, I think the concept is consistent with relational asignment. For
>>example, ON UPDATE CASCADE becomes a trigger that checks if after the
>>assignment a certain candidate key value has disappeard and a new one has
>>If so then it performs an assignment to the referring relation that
>>replaces the tuples that refer to the old cand. key value with tuples that
>>refer to the new cand. key value.
>But exactly how do we know _which_ new tuples correspond to which old
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.
>And it cannot say because UPDATE/INSERT/DELETE/UPSERT/UPDELSERT/.. are
>NOT core concepts of the relational model, and so neither can ON UPDATE
>CASCADE be part of that core.
Agreed. But look at why this is so difficult in the RM. The only thing that has identity there are the relvars. These contain sets of tupels and since these are values you cannot update them. The only thing that can be updated are the relvars. Now look at the ER model. Every entity has identity so the update of an entity is a natural concept there. (But as I already pointed out you cannot do an update of the properties that identify an entity, [unless you want to get involved with object-identifiers, but I think we agree that we don't want those] although the replacement of a certain entity with another entity would be a meaningful concept.) In fact you can model the RM in that respect in the ER by modelling the relvars as entities and their contents as set-valued attributes containing tupels.
I guess that means you could say that the RM is just a thin layer on the ER model. :-)
- Jan Hidders