Re: Relation Schemata vs. Relation Variables

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.

>

Because facts are about things, and things /do/ change. If you want to limit the set of possible database states to include only facts that reflect alterations that /can/ occur, then you need to know what each thing looked like at the end of the last change and what it looks like in each consistent database state.

> >
> > > Maybe the next state of the relvar will be R := {x, z, j}. Sure I can
> > > compare j and y but saying they somehow correspond to each other in
> > > some other way is nonsensensical logically. And they certainly aren't
> > > 'transitioning'.
> > >
> > >> t would be empty for an inserted tuple, t' would be
> > >> empty for a deleted tuple, and neither would be empty for tuples
> > >> corresponding in an update. From that set of transitions, only those
> > >> that
> > >> satisfy all transition constraints are /possible transitions/. The
> > >> problem
> > >> is that more than one transition can result in the same /possible state/
> > >> but
> > >> that not all of those are /possible transitions/.
> > >>
> > >> For instance, consider the following states for a relation describing
> > >> people's marital status, and a transition constraint that says: Single
> > >> people can't become Divorced:
> > >
> > > I'm glad that you've seen the light with the whole not-hiding
> > > attributes thing (it was a revelation for me when the information
> > > principle finally clicked), but the 'corresponding tuple' conjecture
> > > still needs breaking!
> > >
> > > Brian Selzer wrote:
> > >> For instance, consider the following states for a relation describing
> > >> people's marital status, and a transition constraint that says: Single
> > >> people can't become Divorced:
> > >
> > > Single people can get married and then divorced in between updates.
> >
> > Not without violating the constraint. The constraint ensures that the
> > "marriage" event precedes the "divorce" event.
> >
> > > Anyhows...
> > >
> > >>
> > >> Current Proposed
> > >> Jane Jones Married Jane Jones Married
> > >> Jane Smith Single Jane Smith Divorced
> > >>
> > >> Should the proposed state be rejected? Or did Jane Jones get Divorced
> > >> becoming Jane Smith at the same time that Jane Smith married Bob Jones?
> > >
> > > Brian, this example makes no sense whatsoever. If anything it
> > > highlights what we've all been saying. In fact you explain why
> > > yourself:
> > >
> > >> is impossible to tell: not enough information has been provided.
> > >
> > > Exactly. There is insufficient information to identify the people
> > > concerned. The design is fubar. Nothing else to it.
> > >
> >
> > The design is a simple example of what can happen if a key can change along
> > with another attribute that participates in a transition constraint. I've
> > stated before that key stability is irrelevant, if a key can change, it
> > will, and if it can change, then the attribute participating in a transition
> > constraint can also change at the same time.

>

I disagree. The value of a key does not necessarily mean the same thing in successive database states, unless you impose an immutability constraint on it. Therefore, any conclusion drawn from correlating facts from successive states by using a mutable key is based on a false premise. Consequently, transition constraints that involve joining successive relation values on a mutable key are incorrect, and will allow transitions that should not occur and will prevent transitions that should. You need to tell the database that a key's values mean the same thing in successive database states. You do that by imposing an immutability constraint.

> >
> > > The whole point is that here someone's name is insufficient to identify
> > > them. In fact, forget the database, this would be a problem just in the
> > > company when one of these women tried to explain to a secretary who she
> > > was.
> > >
> >
> > But identity beyond a single database state is in the mind of the database
> > designer, or the user, or both. The fact that that identity exists must
> > therefore be conveyed by the user during updates.
> >
> > > Now if you want to talk about constraints then fair enough, but lets
> > > get the other stuff clarified first. All best, Jim.
> > >
Received on Tue Aug 22 2006 - 14:13:07 CEST