Re: Relation Schemata vs. Relation Variables
Date: Fri, 08 Sep 2006 08:15:29 GMT
Message-ID: <BE9Mg.16676$1f6.5589_at_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. >
>> 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.
>>>> >> tuples within relations ie. elements within sets.
>> >>
>> >> 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
>> >
> > 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).
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 - 10:15:29 CEST