Re: SUPPORT FOR DECLARATIVE TRANSITION CONSTRAINTS

On 28 sep, 01:29, Brian <br..._at_selzer-software.com> wrote:

> Consider a database in which every tuple has to have as one of its
> components the time of the last transition.  Suppose now that there is
> a database update.  In the update, every tuple is replaced, because
> every tuple has to have as one of its components the time of the last
> transition, which is now the time of the update under consideration.
>
> The employee named paul c at time t1 was being paid $43/hour.
> The employee named paul c at time t2 was being paid $37/hour.
>
> Are "the employee named paul c at time t1" and "the employee named
> paul c at time t2" the same employee at different times, or are they
> different employees at different times.

If that question must be answerable from the database, then there must be some (OTHER) relvar in the database designed explicitly to answer such questions.

If that question must not be answerable from the database, then you should not bring it up in this discussion.

> In other words, did the
> employee named paul c take a cut in pay, or are the employees named
> paul c at t1 and t2 completelyh different employees?

If that question must be answerable from the database, then you must have some relvar that is designed to answer such questions.

A relvar such as the following might do (but numerous alternatives are presumable equally suitable, or even better) :

VAR EMPRENAMES RELATION{NAME char ON date NEWNAME char}

Using the RA allows to reconstruct from this the entire chronological chain of names that any given employee has been identified with over time.

> > to consider it meaningful to construct a mapping between
> > the tuples before an update and the tuples after.
>
> This is essential for transition constraints to be defined,

I agree that it is essential for transition constraints to be defined. That's why the right conclusion is that there is no case for transition constraints.

> whether procedurally through the use of triggers, or declaratively using the
> mechanism I propose.

You have not proposed anything.

Just appending quotes to relvar names does not a proposal make.

> > There are certainly contexts of use in which this is meaningful,
> > but it doesn't always make sense.  It is even sensible
> > to reject this idea altogether.
>
> I don't think it is.  In Sql, triggers have been used to enforce
> transition constraints for years.  I think what I propose is far
> superior to the procedural approach.

And proper database design using proper temporal technology is yet superior. This has already been pointed out to you. But you choose to stay blind.

The very notion of "transition" implies and requires the notion of time. Anyone with half a brain should see how that leads naturally to the only possible conclusion: the DBMS constraining transitions, requires the DBMS to understand time. How it can do so, has been laid out in great detail in "Temporal data and the Relational Model". In such a system, any constraint of the kind you are complaining about, becomes a simple state constraint, and all your problems have simply vanished. This too has already been pointed out to you. Received on Tue Sep 28 2010 - 11:23:48 CEST