Re: thinking about UPDATE

"Jan Hidders" <jan.hidders_at_REMOVETHIS.pandora.be> wrote in message news:pan.2004.07.23.18.49.12.482009_at_REMOVETHIS.pandora.be...
> On Fri, 23 Jul 2004 15:57:34 +0000, Marshall Spight wrote:
> > "Jan Hidders" <jan.hidders_at_REMOVETHIS.pandora.be> wrote in message
> > news:pan.2004.07.23.08.58.40.657256_at_REMOVETHIS.pandora.be...
> >>
> >> Note that in practice you would probably not include such columns
> >> because they are obviously redundant.
> >
> > I'm not sure I agree with that. Part of the value of time-varying
> > relations is the "time-varying" part. That is to say, {} as a key gives
> > us the ability to have a singleton in the relational world, and that is
> > a very powerful pattern. The variable is still useful as a variable,
> > even though the cardinality is limited to 0 or 1.
>
> With "such columns" I meant columns that are restricted to at most
> one value but are in a relation where there can be more than one tuple.

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.

So although the t attribute in Base has one of two possible values, and must be stored somehow, the t attibute in each of T1 and T2 has only one possible value, and does not have to be stored. (But it's still logically part of the relation.)

This constitutes a useful application for an attribute of a type with only one value.

(Note: in my example, each value of Base is necessarily a subtype value, but you can change this by expanding the type T to include a value that indicates "no subtype.")

> You are right that if all columns are restricted that way then there is
> no redundancy. Although some participants of this newsgroup might
> disagree. ;-)

Heh heh.

> > (Are there other tricks we can play to constrain the cardinality of a
> > relation? Can we constrain the cardinality to exactly 1? 1 or more?)
>
> Not with FDs, MVDs or JDs.

I didn't expect there would be, but I'm still disappointed. (Just to make sure I understand you: FD is "functional dependency", MV is "multivalue dependency" and JD is "juris doctor" meaning there's no way to solve this problem by getting a lawyer and suing, right?)

Marshall

PS. Seriously, what does JD stand for? Received on Sat Jul 24 2004 - 04:50:53 CEST