Re: Relation Schemata vs. Relation Variables

brian_at_selzer-software.com 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?
> >
>
> Because facts are about things, and things /do/ change.

That is honestly completely irrelevant Brian. We are /only/ concerned with statements. You are confusing levels, and this seems to be the key point.

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

> >

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

Then you are trying to rewrite the definition of identity that underlies all logic. This is not a sensible thing to do in light of the thousands of years of thought it took to reach it.

I can only think the reason you cannot see this is because you have vested so much time and become too entrenched . I hope you can give this a rethink given the lack of success you have had convincing this audience. Jim.

> 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