Re: temporal data constraint

davis.jeffrey_at_gmail.com wrote:
> Let's say I have two relvars like:
>
> RELVAR R { A INTEGER, B INTEGER } KEY { A }
> RELVAR S { A INTEGER, C INTEGER } KEY { A }
> CONSTRAINT ( JOIN { R, S } { A } = S { A } )
>
> That is, every tuple in S has a corresponding tuple in R but the
> reverse is not necessarily true. In SQL, one might represent this by a
> single SQL table with (A, B, C) such that C is NULLable (I'm not
> suggesting that one should do this).

Then why do you mention it? Furthermore, why not simply specify this as a foreign key?

> Now, I'd like to make the relation temporal, in the way that CJ Date
> suggests in "Temporal Data and the Relational Model".
>
> It's already in 6NF. I can create "since" and "during" relations like:
>
> RELVAR R_SINCE { SINCE TIMESTAMP, A INTEGER, B INTEGER } KEY { A }
> RELVAR R_DURING { DURING INTERVAL, A INTEGER, B INTEGER } KEY { A,
> DURING }
> RELVAR S_SINCE { SINCE TIMESTAMP, A INTEGER, C INTEGER } KEY { A }
> RELVAR S_DURING { DURING INTERVAL, A INTEGER, C INTEGER } KEY { A,
> DURING }
>
> That seems like a great solution, but the problem is constraints.
> Every A must have a corresponding B at all times that A itself exists,
> but A may or may not have a C at any given time. I'd like some simple
> constraints to illustrate that in a temporal database the same way I
> represented it in the non-temporal database.

I believe "Temporal Data and the Relational Model" covers such constraints in depth in chapters 11 and 12. Also, they way you "made the relation temporal" is /not/ the way that Date/Darwen/Lorentzos suggest.

-- 
Jon