Re: relationship in the database

hidders_at_hcoss.uia.ac.be (Jan.Hidders) wrote in message news:<3d8b67a4$1_at_news.uia.ac.be>...
> 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
> >>been added.
>
> >>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
> >tuples?
>
> 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. From a theoretical view, this might be satisfactory, but from a pragmatic view it is not.

I believe that triggers (defined in the broad manner with e.g. FK-dependencies, not necessarily as stored procedures) are invaluable and a relational assignment must take the existence of triggers into consideration.

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.

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.

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.

Kind regards
Peter Koch Larsen Received on Wed Sep 25 2002 - 13:11:26 CEST