Re: SUPPORT FOR DECLARATIVE TRANSITION CONSTRAINTS

On Sep 28, 5:23 am, Erwin <e.sm..._at_myonline.be> wrote:
> 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.

It must be answerable at the instant of a transition in order to determine whether the transition should be allowed! Once it has been determined that the transition should be allowed, it no longer matters.

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

NO, you don't. See above.

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

irrelevant. And what's more, easily subvertible: what's to prevent a user from deleting the contents of this relvar. That would effectively rewrite history, wouldn't it? In SQL, you could put a trigger on the table, disallowing all deletes--but wait! Isn't that a transition constraint? Isn't it your thesis that there is no case for transition constraints?

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

I described exactly what information is understood to be referenced by every one of those additional relvar names, and even sketched out how that information is to be arrived at in an implementation, given just the text of the multiple assignment. What more do you want? Code?

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

No. It isn't. Only transition constraints can prevent a user from rewriting history. All a user needs to do to subvert any state constraint that involves temporal attributes is to replace the history of the object under consideration. I think I pointed this out--I'm not sure if it was you that I was responding to, however.

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

I've read the book from front to back, from back to front and from side to side. It still doesn't change the fact that only transition constraints can prevent a user from rewriting history. Date, Darwen and Lorentzos state clearly on page 298 that transaction times should not be updatable. How is it possible to prevent updates to transaction times unless there are implicit transition constraints built into their system. I also contend that their solution fails to address the case where keys can be the target of UPDATEs How is it possible to refer to the complete history of something unless there is some form of rigid identification encoded into each tuple. By definition, the identification that a candidate key affords is limited in scope to a single database state. How can updates that target that rigid identification be prevented? Rigid identification need not be a system-generated surrogate: a rigid definite description would suffice, such as the time and the key value at the time that the first tuple that referenced the object was inserted. Still, some means to prevent updates to it would still be necessary, and in DD&L's system, how would one prevent insertion into a historical relvar without a corresponding delete or update to the current relvar?

Introducing temporal attributes is totally unnecessary: transition constraints can be specified declaratively, using set-based operations, spanning multiple relvars, without altering relvar headings and independent of whether updates affect keys. Received on Tue Sep 28 2010 - 16:05:22 CEST