Re: Relation Schemata vs. Relation Variables

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?

>
> > 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.

This is a non-sequitur. Nevertheless I repeat there is insufficient information to provide continual identification in these propositions. It is always possible for all keys to 'change' and you are then logically looking at a different 'thing' altogether. If this is not what is desired, then there is a gaping design flaw for the task at hand. The point is the holes that have been picked in that example can be applied to /any/ example that is trying to illustrate what you say.

>
> > 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 Mon Aug 21 2006 - 14:32:49 CEST