Re: RM VERY STRONG SUGGESTION 4: TRANSITION CONSTRAINTS

On Sep 9, 6:30 pm, paul c <toledobythe..._at_oohay.ac> wrote:
> On 09/09/2010 2:37 PM, Brian wrote:
> ...
>
>
>
> > I suggest you read Hugh Darwen's book, /An Introduction to Relational
> > Database Theory/.  It's available for download online.  See the TTM
> > web site.  After you read his book.  Maybe you'll understand how
> > ridiculous this post makes you sound.
>
> > As for having a mental block.  Trying to model database updates using
> > functional programming is like trying to milk a steer.  Good luck with
> > that!
>
> No doubt trying either is just as shaky as your mutant tuples (I'm
> surprised you don't just refer to muples or m-tuples, we'd all save much
> time).

I never mentioned anything about mutant tuples. Tuples are values. Values do not change.

> Obviously implementers shouldn't try, better to implement with
> nothing but replacement in mind, avoiding all notion of sequence which
> is perhaps the obstacle that most programmers waste the most time coping
> with (implementers too!).

Well, your attitude is exactly why commercial database systems aren't truly relational. Limited functionality to define transition constraints has been available in Sql databases for many years. Of course, it's iterative and procedural rather than set-based and declarative, or it requires the introduction of identity (or guid) columns. It's also limited to a single table at a time. In any case it has always been possible to determine what kinds of changes are occurring to a table: insert, update or delete. It has also been possible to determine the scope of a change--that is, whether or not a given row was targeted by a change, regardless of whether it actually did change.

Relvars can change. The problem is that if implementers implement with nothing but replacement in mind, then there can be many different mappings from the initial database state to the terminal database state of a transition. Which mapping is what the user intended? Keys cannot be a universal mechanism for inferring that. Sometimes there is more than one key, sometimes the entire heading is the only key.

What I'm proposing is a mechanism whereby enforcible transition constraints can be defined declaratively using set-based operators without altering the relvar heading and without regard to key stability. (Key stability is in my view orthogonal to enforcing transition constraints.) For a multiple assignment consisting only of deletes, inserts, and updates, it is possible to determine exactly which mapping is the one the user intended using just the information provided by the user in the multiple assignment.

All that is required is that UPDATE be regarded as more than just a shortcut for a generic assignment, :=.

> Darwen, like Codd, uses phrases like "vary from time to time", by way of
> explaining results, nothing wrong with that.  The mistake many, maybe
> most, people make is to read that and think that an implementation is
> somehow destined to mimic every last figure of speech in the description.
>

I refer you to page 14 of the aforementioned text. I'm paraphrasing, you're welcome to look up the exact wording:

  A database is to be interpreted as a true account of an enterprise at a particular point in time. Received on Fri Sep 10 2010 - 05:23:37 CEST