Re: Relation Schemata vs. Relation Variables

From: Brian Selzer <brian_at_selzer-software.com>
Date: Fri, 08 Sep 2006 08:15:29 GMT
Message-ID: <BE9Mg.16676$1f6.5589@newssvr27.news.prodigy.net>

"JOG" <jog_at_cs.nott.ac.uk> wrote in message news:1157647201.833023.298400_at_h48g2000cwc.googlegroups.com...

> Brian Selzer wrote:

>> "JOG" <jog_at_cs.nott.ac.uk> wrote in message
>> news:1157554419.796440.287750_at_e3g2000cwe.googlegroups.com...
>> > Bob Badour wrote:
>> >> JOG wrote:
>> >> > Brian Selzer wrote:
>> >> >
>> >> >>"Jan Hidders" <hidders_at_gmail.com> wrote in message
>> >> >>news:1157532864.768886.10750_at_d34g2000cwd.googlegroups.com...
>> >> >>
>> >> >>>Brian Selzer wrote:
>> >> >>>
>> >> >>>>"Jan Hidders" <hidders_at_gmail.com> wrote in message
>> >> >>>>news:1157457516.222077.154380_at_b28g2000cwb.googlegroups.com...
>> >> >>>>
>> >> >>>>>Sets of facts can and do change, and transitional constraints
>> >> >>>>>restrict
>> >> >>>>>wich transitions from one set of fact to another are allowed. I
>> >> >>>>>don't
>> >> >>>>>see a fundamental problem here. Note btw. that they are a strict
>> >> >>>>>subclass of the restrictions that might be expressed by some kind
>> >> >>>>>of
>> >> >>>>>temporal logic.
>> >> >>>>
>> >> >>>>I don't understand what you mean. Are you saying that transition
>> >> >>>>constraints can be expressed as state constraints?
>> >> >>>
>> >> >>>A transitional constraint is a binary predicate over states. One
>> >> >>>argument is the old state and the other the new state. Or, put in
>> >> >>>another way, a transition constraint constrains the transitions.
>> >> >>>This,
>> >> >>>I would say, is pretty much the definition of the term.
>> >> >>>
>> >> >>>Or did I misunderstand your question and are you asking about
>> >> >>>temporal
>> >> >>>logics?
>> >> >>>
>> >> >>
>> >> >>No. I just wanted to be sure that we're on the same page.
>> >> >>
>> >> >>The point that I was making in the original post is that because
>> >> >>keys
>> >> >>can
>> >> >>change, there isn't enough information given only the old state and
>> >> >>the
>> >> >>new
>> >> >>state to pair up the values in the old state with those in the new
>> >> >>state for
>> >> >>comparison.
>> >> >
>> >> > You cannot pair up values David. You can only compare the sets as a
>> >> > whole.
>> >>
>> >> I think you misspoke. I draw your attention yet again to Date's
>> >> _Principle of Incoherence_: "It is very difficult to respond
>> >> coherently
>> >> to that which is incoherent."
>> >
>> > guilty as charged. Very difficult indeed. I'll rephrase:
>> >
>> > There is no transition between individual tuples in different relation
>> > values Brian, and it is illogical to try and compare them as if there
>> > were. There is only a transition from one set of tuples to another, as
>> > a whole. (This is because, as a variable, a relvar posesses an identity
>> > outside of its current value).
>> >

>>

>> That's interesting. Today I dug out my old copy of Date's "An
>> Introduction
>> to Database Systems, Seventh Edition," and on page 256-257 he describes
>> transition constraints exactly as I understand them, and although he
>> doesn't
>> address the issue of "key updates," he writes about joining S and S' and
>> picking out the tuples that violate a particular constraint. In
>> addition,
>> his description hasn't changed since 2000, because he describes them in
>> exactly the same way in "Database in Depth" on page 130. So, if my
>> understanding of transition constraints is faulty, then so is Date's.

>
> Rubbish. His views of a transition constraint are totally in line with
> my own. He correctly treats the two relations states (before and after)
> in terms of sets S and S`, which are joined given the specified
> constraint, requiring that the resulting relation is empty. Vitally
> this has nothing /at all/ to do with examining individual tuples as
> though they were variables, and everything to do with the examining the
> sets as a whole.
>

The key word here is "joined." What do you think the join does if it doesn't pair tuples from the two relations for comparison? JOIN takes the cross product of two relations and eliminates any element that has more than one value with the same attribute name, thus producing another relation. This has the effect of pairing up tuples from one relation with those from the other. Why is this so difficult for you to understand?

>> I don't think that pairing up tuples for comparison is illogical at all.

>
> Comparison of tuples is totally illogical if you do it in any manner
> other than comparing the tuples' attributes.
>

How else would you compare them? I don't understand what you're trying to say.

>> What is illogical is expecting R join R' to give consistent results
>> without
>> object identifiers or tuple identifiers.

>
> No matter how many times you repeat this it is still reads as nonsense.
> A tuple is not a variable.
>

Who said that a tuple is a variable. I never said that.

>> What is illogical is discarding
>> information supplied by the user in order to fit what are obviously more
>> expressive modification operations into the mold of relational
>> assignment.
>> What is illogical is assuming that keys won't change.

>>

>> I really don't understand what you mean about a variable having identity.

>
> Well I'm suprised because this is fundamental stuff. A relvar is a
> variable and so can change its value, a proposition is not and so
> cannot change, only created or deleted.
>

Perhaps it was the way you worded it.

>>


>> >>

>> >> One can pair up values any number of ways: least, greatest, lesser,

>> >> greater, least greater, greatest lesser etc.

>> >>

>> >> Cartesian product and restrict have the effect that one can pair up

>> >> tuples within relations ie. elements within sets.
>> >

>
> You are still trying to fight thousands of years of development in
> maths, identity and logic Brian. You've highlighted a vital design
> consideration when it comes to key selections, but no more than that.
>

I have done no such thing. Since a relational database state is a set of named sets of sets of named values instead of a set of named sets of named sets of named values, there is not enough information available to pair up a datum in the current database state with its successor for comparison by using only identification. I am not fighting math, identity and logic. The Guaranteed Access Rule specifies how a datum (atomic value) can be identified within a database state. If a user identifies an atomic value in the current database state and then asserts that a different value will apply in the next, then the mechanism defined in the model for specifying transition constraints must provide a means to pair up atomic values in the current database state with those in the next that does not conflict with that stated intent--even if the attribute associated with that atomic value is prime. Since each datum belongs to one and only one tuple in a database state and since each element of a tuple has a name, if a user identifies a tuple in the current database state and then asserts that different values will apply in the next for one or more of its constituent atomic values, then the mechanism defined in the model for specifying transition constraints must provide a means to pair up tuples in the current database state with those in the next that does not conflict with that stated intent--even if one of the affected attributes is prime. Because keys can be "updated," the key value used to identify a tuple in the current database state may not identify a tuple in the proposed state, or may identify a different tuple than that intended by the user. Consequently, joining R and R' on that key may produce results that conflict with the stated intent of the user, that is, a transition that should be allowed may be rejected, or a transition that should be rejected may be allowed. The problem is that the stated intent of the user is projected away and obscured when an update is transformed into an assignment, and thus R and R' are not sufficient to specify transition constraints (unless what is being constrained involves aggregates, of course).

One solution would be to "name" tuples, that is, to use object identifiers or tuple identifiers or both. (It is not sufficient to use only object identifiers if a key is composite.) If tuples had names, then a datum could *always* be identified by using the name of the relation, the name of the tuple and the name of the attribute. As a result, that datum could *always* be paired with its successor for comparison. But even then, the stated intent of the user is still obscured by transforming an update into an assignment. It cannot be determined by examining R and R' whether or not a particular datum or tuple was targeted by an update, and that may be significant. Consequently, this solution is not only bad from the standpoint that it involves introducing what are for all intents and purposes, pointers, but it also doesn't faithfully capture the stated intent of the user.

The introduction of multiple assignment complicates things further. Should the system check constraints after each component assignment is evaluated, or should it expose the aggregate of all of the component assignments for comparison? Without tuple identifiers, there isn't sufficient information in R and R' to determine whether an update was intended or a delete followed by an insert; so again a constraint specified in terms of only R and R' may conflict with the stated intent of the user.

Design considerations and key stability have no bearing on the limitation I've described, unless you're advocating the use of tuple identifiers. Received on Fri Sep 08 2006 - 03:15:29 CDT