Re: RM VERY STRONG SUGGESTION 4: TRANSITION CONSTRAINTS

On Sep 3, 2:29 pm, Erwin <e.sm..._at_myonline.be> wrote:
> On 3 sep, 17:35, Brian <br..._at_selzer-software.com> wrote:

<snip>

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

In the update, the referent of t1 is the referent of t2, but in the multiple assignment, the referent of t1 ceased to exist and the referent of t2 came into existence. The "meaning" of the fact "t2" is therefore different. For example,

before: The person at the front of the line is wearing a red hat. after: The person at the front of the line is wearing a blue hat.

Did the person who has up to now been at the front of the line don a blue hat, or has the person who has until now been at the front of the line been replaced by someone else?

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

Date oversimplifies. Again, I ask, did the person who has up to now been at the front of the line don a blue hat, or has the person who has until now been at the front of the line been replaced by someone else?

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

There is definitely a mapping. In his book, Codd wrote, "keys in the relational model act as surrogates for the objects being modeled." (Page 25) By definition, every relation has at least one candidate key, so every tuple has at least one key, and therefore every tuple maps to something in the microworld that is being modeled.

<snip>

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

Page 220-221.

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

You are committing the same oversimplification as Date. The objects that are the referents of the facts represented in a database are concrete: they have a location in time if not also space. They are not abstract mathematical objects which are independent of time, and it is a mistake to treat them as such. Concrete objects can come into existence, they can cease to exist, and they can differ in appearance at different times during their lifetime.

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

Please enlighten me: how can it be determined which tuple in the after value matches the tuple in the before value?

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

I'll look into it.

> > 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.- Hide quoted text -
>
> - Show quoted text -
Received on Sat Sep 04 2010 - 05:21:19 CEST