Re: Relation Schemata vs. Relation Variables
Date: 24 Aug 2006 05:00:14 -0700
Message-ID: <1156420814.380584.146750_at_b28g2000cwb.googlegroups.com>
JOG wrote:
> brian_at_selzer-software.com wrote:
> > JOG wrote:
> > > JOG wrote:
> > > > Brian Selzer wrote:
> > > > > "JOG" <jog_at_cs.nott.ac.uk> wrote in message
> > > > > news:1156107137.284318.326750_at_m73g2000cwd.googlegroups.com...
> > > > > > Brian Selzer wrote:
> > > > > >> In the context of an update, the predicate of a database along with the
> > > > > >> current database state determines the set of all /possible states/ that
> > > > > >> can
> > > > > >> become current. Integrity rules, which are implicitly or explicity
> > > > > >> specified as part of the database predicate, can be classified as either
> > > > > >> state constraints or transition constraints. State constraints define
> > > > > >> the
> > > > > >> set of all consistent database states; transition constraints determine
> > > > > >> whether or not a state change should be allowed. Given a set of
> > > > > >> consistent
> > > > > >> database states and the current state, one can derive a set of
> > > > > >> transitions,
> > > > > >> each containing what is different on a tuple by tuple basis between the
> > > > > >> current state and a proposed state (any one of the consistent states). A
> > > > > >> transition can be defined as a set of triples (r, t, t') where r is the
> > > > > >> name
> > > > > >> of a relation, t is a tuple from the current state, and t' is a tuple
> > > > > >> from
> > > > > >> the proposed state.
> > > > > >
> > > > > > <argggghhhh/>.Sorry brian, but this still isn't right. It is illogical
> > > > > > to talk about the transition of a tuple from one value to another, as
> > > > > > though they were entities from the real world themselves. Look, say
> > > > > > mathematically you are talking about a relation composed of three
> > > > > > tuples:
> > > > > >
> > > > > > R := {x, y, z}
> > > > > >
> > > > > > x, y and z are not variables! They are aliases for values. I can't
> > > > > > compare x, y an z with their future selves - they only have one value,
> > > > > > today, tomorrow, for evermore.
> > > > > >
> > > > >
> > > > > I think you're confusing attributes with tuples. Even if you're not, I
> > > > > agree: tuples are values. If they *can* correspond, it is in the mind of
> > > > > the designer of the database who defined the transition constraint, and thus
> > > > > the fact that they *do* correspond must be conveyed by the user during the
> > > > > update.
> > > >
> > > > I am not confusing anything. If you agree tuples are not variables,
> > > > then you agree that tuples cannot 'change'. And by that one is saying
> > > > that they /cannot/ have a transition. That's the logic, and its
> > > > unavoidable - how can you argue against it?
> > >
> > > You have still not explained how you intend to go against this logic.
> >
> > I posted a detailed explanation to J M Davitt, but here's the short
> > version.
>
> This is not an explanation of how you are going against the logic. It's
> fluff. If tuples cannot change there can be no transition.
>
I think I was very clear: values do not change, things do. Codd mentioned "key updates" in the context of checking for consistency in the paper that defined the Relational Model. Of course, he was then concerned only with checking for the consistency of individual instantaneous states, but when he later defined what a data model is, he included "changes of state" as a type of integrity rule that can be defined. So it's clear that Codd knew that keys could change when he defined the Relational Model, and it is clear from his definition of a data model that he expected a data model to provide a mechanism for determining allowable state changes. Therefore, If tuples are values, and values cannot change, then either state-change integrity rules are nonsense, or tuples must represent facts about things that can change, and a system conforming to the model must be able to detect those changes and react accordingly--even if a key changes.
> >
> > A candidate key value can only identify a tuple within a single
> > database state.
>
> No. That is only a /necessary/ condition of a candidate key. There are
> further characteristics that seperate choosing a good key from a bad
> one.
>> > database state implies that the value identifes more than just a tuple
> > Using that value to identify a tuple in a different
> > (or fact).
>
> It gives us a clue that the key for a tuple /may/ also be a good
> identifying attribute for an item in the real world. This may not be
> true.
>> > database state represents a fact about something, then the gross
> > So if a tuple from the current database state represents a
> > fact about something, and a tuple with the same key value in a proposed
> > assumption is that both facts are about the same thing.
>
> More than Gross, its an atrocious assumption. Facts are not about
> things, they /concern/ things. In fact the above assumption shows a
> misunderstanding about the nature of the statements we are recording.
> This is the root of your mistake imho.
>> > value so that it doesn't just identify a tuple, but also something in
> > So, you're
> > right, tuples are values and cannot change, but using a candidate key
> > value beyond the scope of its definition injects meaning into that
> > the universe.
>
> An identifying value can be used as a key in a statement, but we cannot
> assume the reverse. It is illogical. I think you are confusing the role
> of identifying an item and identifying a statement of fact.
>> > something in the universe, then it's also possible for that key to
> > Therefore, if it's possible for a key value to identify
> > change and still identify the same thing.
>
> It can be renamed and happily identify the same 'thing' (i.e. a domain
> renaming). However this would require a renaming in old relation values
> too to maintain consistency.
>
> It can also change values (within a domain) and identify a snapshot of
> a 'thing'.
>
> However it no longer identifies a things identity over several
> snapshots of it. If that is what matters it was an error using that
> identifier in the initial propositions. You should have used an
> identifier that represents that 'thing' over that time.
>
> > It's also possible for
> > things to change so that the key value identifies something else.
>
> This sentence makes no sense. Things don't have key values, only
> tuples.
>> > Bottom line: if a transition constraint can be defined, then tuples
> > Hence, a transition constraint prevents database states that are
> > illogical not because values are different, but because the new values
> > represent facts about things that cannot be true given the current
> > state of things reflected in the old values.
> >
> > represent facts about things that can change.
>
> No. Things can change, however to identify something over time in the
> real world we need /some identifying attribute/. How on earth would we
> ever know it was the same thing otherwise! When you meet someone you
> have not known since they were a child, and they have changed their
> name through marriage, you cannot identify them. They have to ascertain
> a consistent identifier for you to recognise them.
>
> All you have done is highlight bad key choices. This is a valid
> problem, but external to the RM.
Received on Thu Aug 24 2006 - 14:00:14 CEST