Re: thinking about UPDATE

On Sat, 24 Jul 2004 02:50:53 +0000, Marshall Spight wrote:
>
> Ah, I misunderstood. Although actually, I can think of a use for a
> column with only one possible value in a relation where there is more
> than one tuple.
>
> Let's say you have a relation Base, with one of two possible "subtype"
> relations T1 and T2. You wish to enforce that each row in the base table
> has a corresponding row in either T1 or T2, but not both. Declare an
> enumerated type TT { t1, t2 }. Declare subtypes TT1 = { t1 } and TT2 = {
> t2 }.
> Declare the key of Base to be { id:int, t:TT }. Declare the key of T1 to
> be { id:int, t:TT1 } references Base(id,t) Declare the key of T2 to be {
> id:int, t:TT2 } references Base(id,t)
>
> There is no type error in joining, because TT1 <: TT and TT2 <: TT.

You still haven't modelled that for all tuples in Base there should be a corresponding tuple in either T1 or T2. I agree that this is a nice trick, but it is a trick, and you wouldn't need it if the constraint language of the database was powerful enough.

> PS. Seriously, what does JD stand for?

Join dependencies, the most general of them all and used to define 5NF. They consist of a set of headers and say that the corresponding decomposition is information preserving. So for a relation R(a,b,c) the

  JD({a,b}, {a,c}, {b,c})

says that it always holds that

  R[a,b] [X] R[a,c] [X] R[b,c] = R

where R[a,b] denotes the projection of R on {a,b} and [X] is the natural join.

The usual example is DrinkAt(drinker, bar, beer) with the constraint that if (1) a drinker drinks a certain beer, (2) a bar servers that beer and (3) that drinker visits that bar then it follows that this drinker drinks that beer in that bar.

• Jan Hidders