Re: Relation Schemata vs. Relation Variables

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.

A candidate key value can only identify a tuple within a single database state. Using that value to identify a tuple in a different database state implies that the value identifes more than just a tuple (or fact). 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 database state represents a fact about something, then the gross assumption is that both facts are about the same thing. 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 value so that it doesn't just identify a tuple, but also something in the universe. Therefore, if it's possible for a key value to identify something in the universe, then it's also possible for that key to change and still identify the same thing. It's also possible for things to change so that the key value identifies something else. 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.

Bottom line: if a transition constraint can be defined, then tuples represent facts about things that can change. Received on Wed Aug 23 2006 - 16:47:07 CEST