Re: relationship in the database

From: Paul Vernon <paul.vernon_at_ukk.ibmm.comm>
Date: Thu, 26 Sep 2002 10:57:46 +0100
Message-ID: <amunp0$sai$1_at_sp15at20.hursley.ibm.com>


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

Peter.
That is a messed up vision of what theory is, if you belive what you said above.

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

Agreed. Well sort of. What you need to ask is WHY are 'triggers' invaluable. You need to consider the fundamental issue(s) that the idea of 'tiggers' is/are attempting to address. In other words, try to approch 'triggers' from a theoretical angle :-)

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

OK. In Date & Darewn's RM very strong suggestion #4: Transition constraints; they do introduce the concept of R' as the value of relvar R before an assigment to R.

But the Manifesto does not introduce the concept of "new" and "old" tuples. Therefore it's defintion of (single) relational assigment as

        relvar R := relational expression E is sufficent.

Now they do mention in passing on RM VSS #2:Foreign Keys, that these 'provide a place to attach declarative specifications of referential actions .. if such specifications are considered desirable'. While simultaneously noting that 'multiple assignment ... implies that there is no logical need to be able to specify such actions'.

So, quite simply, Date & Darwen, don't have a case to answer here on the evidence of their own published work. They do not claim to support the particular semantics of SQL UPDATE (RM VSS #9:SQL Migration, not withstanding)

I'll outline my answer to the 'problem' of 'SQL UPDATE not being supported via relational assignment', in a response to a later post in this thread; hopefully today.

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

Again I question your concept of theory. I'd love to see someone of the ilk of Steven Pinker write an analysis on the variety of philosophies of knowledge. As in your earlier comment of 'do not wag the dog', Peter, you betray a certain variety of the philosophy (just possibly shared by Jan, but I'm defn not sure), that you do not, (in C J Date's words) believe that 'theory is practical'.

You suggest we need to choose between 'simplicity and reality'. Humm. I guess I see no such dichotomy. Reality may not always be simple, but (and this is maybe our philosophical difference), I believe that the core of the Universe _is_ simple. Complexity is only ever built upon simplicity. And so it should be with databases: build upon simplicity to be sure, but do not presume to replace simplicity with complexity.

To be expliclty philosophical for a moment: Unless the universe is so simple that in fact, in some fundamental sense, it contains _no information at all_. Then how is it that this is the Universe that we are in rather than some other?

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Thu Sep 26 2002 - 11:57:46 CEST

Original text of this message