Re: SUPPORT FOR DECLARATIVE TRANSITION CONSTRAINTS

On Sep 27, 5:09 pm, r..._at_raampje.lan (Reinier Post) wrote:
> Brian wrote:
> >Are you assuming that I claim that the system should be able to ensure
> >correctness rather than just consistency?  Let me assure you that I
> >claim no such thing!  The system can't detect lies.  It can't detect
> >mistakes that are consistent with its constraints.  It can only detect
> >inconsistencies.
>
> Certainly: inconsitencies relative to data that you add.
> The question is whether adding such data makes sense.
>
> >No matter how you try to disguise it, the objection boils down to the
> >objection that a child makes when he is forced to show his work rather
> >than just giving the answer: "Why do I have to write down all the
> >steps when I already know the answer?"
>
> Nope.  The objection boils down to the question whether
> it is meaningful to regard a statement of fact as mutable.

Statement of fact are not mutable. I'm not trying to say that they are. But the interval in time during which a given statement that has been judged to be true remains true is not necessarily fixed. The database is in essence a statement that asserts exactly what has up to now been the case. It has been judged to be true at the instant it became current, and it remains true until further notice. The next transition is that notice. A transition is in essence a statement that asserts, given exactly what has until now been the case, exactly what is now different. When it is determined that a transition is consistent with all state and transition constraints, the end point of the interval during which the current database holds true becomes fixed at the instant of the transition, and a new database becomes current, its interval's starting point being the instant of the transition.

> You have this irresistibe urge to regard tuples as mutable,

Not so. Tuples are not mutable, but the referents of the propositions they represent may be.

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

> 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, whether procedurally through the use of triggers, or declaratively using the mechanism I propose.

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

Brian Received on Tue Sep 28 2010 - 01:29:48 CEST