Re: The Practical Benefits of the Relational Model

In article <aklg60$2oeo$1_at_sp15at20.hursley.ibm.com>, Paul Vernon <paul.vernon_at_ukk.ibmm.comm> wrote:
>
>Hi Jan.

Hello Paul,

>By dynamic you mean what Date would call transition constraints, yes?

Exactly.

>On this subject, don't dynamic constraints just become static
>constraints in the case where you keep all history in your database?

Yes, they do.  

>Besides, that is, the need to enforce the 'arrow of time' (i.e. can't
>update the history tuples). So enforcing the 'arrow of time' becomes the
>only required dynamic constraint

That depends a bit on what you mean with "keeping all your history in your database". Given a time-varying predicate P(x) there are two moments to consider:
1. the moment the database was told that P(a) holds and 2. the moment at which P(a) is true (this can also be an interval). These two moments are often assumed to be the same, but in reality almost never are. If you only store moment 2 then it should be possible to update history tupels since you may learn afterwards that P(a) did in fact not hold at moment t. However, if you store moment 1 then indeed you should never update historic records.

But, the transition constraints usually say something about the predicate in function of the moments of type 2.

You see the problem here?

>E.g. with table T and attribute A of type INTEGER
>and dynamic constraint X: A > A' (where A' is the old value of A)
>
>becomes
> with table H and attribute A of type INTEGER and B of type TIMEPOINT
>and static constraint X: H1.A > H2.A FROM H as H1, H as H2 JOIN H1.B
>IS_SUBSEQUENT_TO H2.B
>
>with the dynamic constraint B = CURRENT TIMEPOINT

Yes, although I prefer good old-fashioned tuple-calculus here:

  FORALL H1, H2 IN H : IF H1.B > H2.B THEN H1.A > H2.A and we shouldn't forget that this formulation is easy here because the transition condition happens to be transitive. If it isn't then its formulation becomes a bit more difficult.

• Jan Hidders