Re: RM VERY STRONG SUGGESTION 4: TRANSITION CONSTRAINTS

On 4 sep, 05:21, Brian <br..._at_selzer-software.com> wrote:
> 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>
>
>
>
> > 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,

So the meaning of t2 does not depend exclusively on the attribute values within it, but also on its history of how it came into existence ?

The fact documented by a tuple t2 in a relvar R is nothing more and nothing less than the instantiation of the relvar's external predicate with the attribute values of t2. You claim to the contrary, that it also includes "something" to do with the history of how t2 came to be. You are free to think as you like. But my position (which is also Date's) allows me to use the CWA, and the CWA alone, to determine whether or not some tuple should or should not appear in some relvar. With your position, that simple decision rule is impossible to follow, because you also need to somehow inspect the history of the currently existing tuples, just in order to decide which particular update you should be issuing.

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

So predictable. Arguing with examples while leaving out the actual business requirement.

Which is of course intended to leave yourself the freedom to invent the business requirements depending on my response, and claim "those were obvious".

But anyway. I'll assume that your business requirement is about keeping track of the color of the hat of the person at the front of the line. That requires a unary relvar with attribute COLOR of some type, and with the external predicate "The person at the front of the line is wearing a §COLOR§ hat.". If that really is your business requirement, then it should be obvious that your example question is unanswerable from that. More to the point, if it is required that such questions must be answerable, THEN YOU SHOULD PROVIDE THE RELVARS TO DO SO. And since the question obviously includes a temporal aspect ("that was up until now at the front of the line"), it might help to design those relvars according to the proposals laid out in "Temporal Data and the Relational Model". (Incidentally, you can use SIRA_PRISE to toy around with temporal data too).

> Date oversimplifies.

If you say so. I say it is oversimplifying to expect the system to be able to answer temporal queries from a single unary relvar.

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

That is not entirely untrue, because of the CWA. A tuple represents a proposition that is believed to be true in the microworld modeled by the database in which the tuple appears. Applying the CWA to determine whether some tuple should or should not appear in the database, cannot possibly be done by the DBMS, and is therefore the exclusive responsibility of the user. So while such a mapping can indeed be perceived to exist, it is by definition of no use to the DBMS and it is therefore a mistake to let the DBMS be bothered with such mapping.

> > > 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'll refresh my memory.

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

If you say so.

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

You are committing the same mistake as all those other, eurhm, people whose "thinking" has gotten too biased by object-oriented mysticism.

That is, to think that the database must somehow keep track of the physical identity(/location/...) of the objects they describe.

They must not. Databases are mere collections of assertions of fact, and there is no legitimate reason to constrain those collections of assertions of fact to "transition" exclusively along exactly the same paths as the reality those facts describe. A DBMS cannot itself observe the microworld to verify that some tuple truly represents a true fact. It cannot itself observe the objects in that microworld, and that is why it shouldn't be bothered with such stuff in any way. Seeing to it that the database accurately describes the reality it is to model, is the user's responisibility.

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

If an identifying value has not changed, then by identifying value. If an identifying value has changed, then it cannot.

Therefore in general, it cannot.

And as I argued before : that shouldn't be a problem because if you accept that databases are merely collections of assertions of fact, then there should never be any need to actually do such matching. Received on Sat Sep 04 2010 - 12:10:25 CEST