Re: RM VERY STRONG SUGGESTION 4: TRANSITION CONSTRAINTS

On 3 sep, 17:35, Brian <br..._at_selzer-software.com> wrote:
> On Sep 3, 9:41 am, Erwin <e.sm..._at_myonline.be> wrote:
>
> > Trying to overcome this, e.g. by introducing some kind of "objectid"
> > in the data which is "eternally, once and for all" linked to the tuple
> > in question has other serious ramifications.  
>
> I'm not suggesting the introduction of an objectid.  I don't think
> it's necessary to do that.
>
> > For example, I suspect
> > that UPDATE can no longer be seen as a shorthand for some particular
> > combination of DELETE-then-INSERT, precisely because of this
> > additional objectid.
>
> UPDATE is not the same as a combination of DELETE-then-INSERT, but not
> because of some objectid.

It is the same. Always. Before some update, relvar R has value {t1}. After that update, relvar R has the value {t2}.

Please explain what the difference is between this update and a multiple assignment consisting of the delete of t1 and the insert of t2.

My claim is furthermore supported by, e.g. (but not limited to) the UPDATE example in The Third Manifesto, page 154, and Date's treatment of view updating in Appendix E, in which he expresses all updates as consisting merely of an insert portion and a delete portion. In the beginning of that Appendix, Date even provides actual proof to what I claim here !

> There is a mapping from every tuple in a database to something in the
> microworld that is being modeled,

There is no mapping. A database is a collection of assertions of fact. Insertions are assertions of fact that were previously not believed to be true, but now do, and deletions are assertions of fact that were indeed believed to be true, but no longer are.

A database records our beliefs of what the real world is like. Why is it that this leads so many into the flawed belief that as a consequence of that, our databases should mimick exactly the same transition path as the world it models ? There is a difference between the world itself that might be constrained in how it transitions from one state to another, and our set of beliefs that had better not at all be constrained in what transitions it can undergo. Well, certainly not in the sense that "transition constraints" usually imply.

> I just don't think the mechanism they suggest is sound.

My recollection of The third Manifesto is that it only says an extremely minimal bit about "transition constraints". I hesitate to call that minimal bit a "proposed mechanism", and certainly do not find the grounds on which to dismiss it as "logically unsound". Maybe you can enlighten me with page references.

> I think the mechanism that Date and Darwen propose is not logically
> sound.  Successive values for a relvar hold during adjacent, but not
> overlapping, intervals in time.  What was the case before an
> assignment can't also be what is the case after (unless it's a null
> assignment, of course).  It is therefore illogical to compare what was
> the case before an assignment to what is the case after.

Depends on what precise meaning you attach here to "compare". Compare for equality (database equality) ? Presumably not.

A database variable has, at any moment in time, a database value D. Database updating is the process of replacing that value D with a new value D'.
The "delta" between D and D' can be modeled as a tuple (called 'S' for Statement) holding all the deletions and all the insertions of all (base) relvars.

The following equivalences hold:

D' = D dbadd S /* dbadd is the operator that "applies S to D" */ D = D' dbundo S /* dbundo is the operator that "undoes an update" : instead of adding the insertions in S and removing the deletions in S, it adds the deletions in S and removes the insertions in S */ S = D' dbdelta D /* should be obvious */

> From a logical standpoint, a database is in essence a statement that
> asserts what has up to now been the case.  A transition is a statement
> that asserts, given what had until now been the case, what is
> different and how it is different--that is, have things come into
> existence, have things ceased to exist, or if things appear different,
> what are the differences?  From what has until now been the case and
> what is now different, one can determine what is now the case.  One
> cannot always determine what is different from what had until now been
> the case and what is now the case, as is illustrated by the example in
> the original post that is the result of a multiple assignment.  Given
> just the before and after values, it can't be determined with
> certainty whether Transition Constraint #4 was violated.

It can. What isn't certain is that it will always produce the outcome you would want to see produced.

What you then need to do is reformulate your transition constraints in such a way that they do.

You can try out SIRA_PRISE if you want. It supports declarative transition constraints (they're baptised differently, though, for reasons I documented in the new implementer's comments on TTM).

> Since a transition is a statement just like a database is a statement,
> it should be possible to represent the transition as a set of
> relations, three for each relation in the database.  One could be
> adorned with a '-' postfix and would contain the result of DELETEs
> that target the corresponding relvar; one could have a '+' postfix and
> would contain the result of INSERTs; one could have a '~' postfix and
> would contain the result of UPDATEs, each tuple containing the before
> and after values for each attribute.

As I indicated with my D',D and S stuff : you have said nothing incorrect here, except that a statement is a set of TWO relations per relvar, not three. Received on Fri Sep 03 2010 - 20:29:56 CEST