Re: RM VERY STRONG SUGGESTION 4: TRANSITION CONSTRAINTS

On Sep 10, 3:45 am, Erwin <e.sm..._at_myonline.be> wrote:
> On 10 sep, 05:23, Brian <br..._at_selzer-software.com> wrote:
>
> > I never mentioned anything about mutant tuples.  Tuples are values.
> > Values do not change.
>
> No, but you argue that the dbms should be aware of "which particular
> tuple in an update gets replaced by which particular tuple in the
> resulting database value".
>
> It might be interesting to observe that exactly the same criticism was
> already expressed by Maurice Gittens a few years ago (he formulated it
> as "TTM does not allow tuple-level audit trails of updates".  That is
> the very same thing you are complaining about).  It has already been
> rebutted in a separate paper, and that rebuttal is now also a chapter
> in D&D's new book "Database Explorations".
>
> The "mapping" you talk about does indeed exist.
>
> It is that very mapping that the user applies when he decides which
> updates to apply to the database.  That mapping involves real-world
> things.  The DBMS cannot possibly observe those real-world things, and
> therefore, as far as the DBMS is concerned, it doesn't matter at all
> whether that mapping exists or not.  The DBMS can't read that mapping
> anyway, so it must by definition rely on the user to apply that
> mapping correctly, and not be told lies by said user.

The DBMS is being told by the user exactly which mapping from the initial state to the terminal state is intended. Whether that's a lie or not is irrelevant. A DBMS cannot determine whether a given update is correct; it can only determine if it is consistent. If the mapping supplied by the user is consistent with all state and transition constraints, then the update should succeed. The mechanism for the user to supply the intended mapping already exists in the form of a single or multiple assignment that is a combination of just DELETE, INSERT and UPDATE.

All I'm proposing is that we take advantage of information that is already being supplied by the user to identify the intended mapping!

Every database constraint is semantic in nature, not just transition constraints. I quote, from the note on page 334 of Date's /An Introduction to Database Systems, Eighth Edition/

    FDs are a matter of semantics (what the data means), not a fluke arising

    from the particular values that happen to appear in the database at some

    particular point in time.

Should FDs, and by extension, keys not be enforced because the DBMS is not able to observe the real-world dependency?

>
> And you still maintain that you do not have a mental firewall
> smoewhere that is preventing this from entering your conscience ?

I don't. You are assuming again.

> > What I'm proposing is a mechanism
>
> Nowhere along the line in any of the two discussion threads have you
> ever "proposed" anything that was specified into sufficient detail to
> be worth being labeled a "mechanism".

What I've written in both threads is a lot more detailed than the little blurb that Date and Darwen wrote in TTM. I grant that it is spread across several posts and could be a bit more clear. I'll try to put together a complete specification, including a more complete description of how the additional relvars are to be populated given an arbitray multiple assignment consisting of only DELETEs, INSERTs, and UPDATEs so that the constraints can be enforced. I'll also provide additional examples of how a multiple assignment consisting of just DELETEs, INSERTs and UPDATEs identifies one and only one mapping from the initial state to the terminal state while a single <relvar target> := <relation exp> does not.

Incidentally, the transition constraints defined on pages 220-221 of TTM are not enforceable since they implicitly assume that each value for S# permanently identifies a supplier. What if the supplier number for a given supplier changes?

I really don't understand why you're fighting this so vehemently, seeing as how you are on record that you don't think := should be supported anyway. Received on Fri Sep 10 2010 - 14:29:18 CEST