Re: relationship in the database

From: Peter Koch Larsen <pkl_at_mailme.dk>
Date: 26 Sep 2002 08:38:22 -0700
Message-ID: <61c84197.0209260738.2960e72a_at_posting.google.com>


Paul Vernon <paul.vernon_at_ukk.ibmm.comm> wrote in message news:<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.

Please note that my above statement was supposed to be in the context of "update" only.

>
> Peter.
> That is a messed up vision of what theory is, if you belive what you said
> above.
I have a feeling that "theory" is a word we should avoid here. The word "model" seems more appropriate. I realise that these two terms overlap.

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

Again, I will refrain from using the "T"-word and use model. In that light I see triggers (in the broader way - i do not like the procedural association the word gives me) as a method to:

  1. Assure/enforce integrity of the system.
  2. Allow a user with incomplete knowledge of the universe to change that universe in areas he knows of.
    >
    >
    > >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.

They do indeed.

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

With severe consequences for the model.

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

There is no logical need if the user is aware of all the updates, that should take place. The implication is, however, that such a model puts an unnecessary burden on its users and thus is not a good model in my opinion.
Perhaps the model is not bad, but just incomplete? My understanding from reading TTM just is that this is not the case. I see no place for UPDATE there, and do so in the basis of a quote on page 165 (second edition): [Relational] "assignments are fundamentally the only means by which a relvar can be updated".

>
> 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)
The problem with SQL migration is not of my concern. I have no doubt that migration would be feasible even if there was no concept of foreign keys at all.
>
>
> 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'.
What I do believe in (without being too philosophical) that a theory must(among other things) be verifiable. In this context, the works of Date and Darwen is a model. The model should be compared with the needs of its users and if it does fullfill their requirements better than another model, their model is better than the other model in that aspect. This is not different from other models.

>
> 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.
I would say that as long as my model solves my problems it should be as simple as possible. In the case where the model encounters practical difficulties, I have to decide if this is a pathetic case or if my model requires a revision. In the latter case, I would revise the model so that it better suits my needs. Naturally, this is alway a subjective choice. As Einstein said: Make it as simple as possible, but not simpler. In the case of update in particular, I do not see this change as a conceptual complexification (if there is such a word!). Rather, the update is a good model of reality.
>
> 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?

I am not sure I do follow you here. But if we are talking about the more philosophical aspects of big-bang theory and the nature of basic physical constants, my answer is that we happen to be here precisely because of this fortunate choice of fundemental values. But I have probably misunderstood you, and this is bound to be off-topic anyway.

>
>
> Regards
> Paul Vernon
> Business Intelligence, IBM Global Services

Kind regards
Peter Koch Larsen Received on Thu Sep 26 2002 - 17:38:22 CEST

Original text of this message