Re: Relation Schemata vs. Relation Variables

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.

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

Now if you want to talk about constraints then fair enough, but lets get the other stuff clarified first. All best, Jim. Received on Sun Aug 20 2006 - 22:52:17 CEST