Re: No exceptions?
From: paul c <toledobythesea_at_oohay.ac>
Date: Fri, 30 Jun 2006 15:57:47 GMT
Message-ID: <%Rbpg.108238$iF6.87560_at_pd7tw2no>
>
> There is some confusion here on both parts, I think. Any relvar can have
> an empty key, regardless of the number of attributes in the relvar. It
> follows that such a relvar can have no other keys. A relvar has a set of
> (candidate, if you will, but I consider that term meaningless) keys, in
> general, but this set cannot be empty---there is always at least one key.
Date: Fri, 30 Jun 2006 15:57:47 GMT
Message-ID: <%Rbpg.108238$iF6.87560_at_pd7tw2no>
Jon Heggland wrote:
> paul c wrote:
>> J M Davitt wrote: >>> ... >>> All the attributes in a relation comprise, at least, a superkey. The >>> set of attributes that qualify as a candidate key must hold unique >>> values and no subset of those attributes must hold unique values. The >>> only relations that could have empty candidate keys are those with >>> empty headings, right? >> [...] I thought a relation with any number of attributes could have >> only one value for them if it had an 'empty' set of candidate keys, eg. >> a relation that has only one tuple?
>
> There is some confusion here on both parts, I think. Any relvar can have
> an empty key, regardless of the number of attributes in the relvar. It
> follows that such a relvar can have no other keys. A relvar has a set of
> (candidate, if you will, but I consider that term meaningless) keys, in
> general, but this set cannot be empty---there is always at least one key.
Thanks for that, Jon, I guess it would clearer to say " ... could have at most one tuple if the empty set of attributes is a key". (The ease of confusing oneself by slip-ups in English reminds me why I agree with people who say establishing requirements is the single biggest cost in projects.)
Let me re-phrase my original question: Is there a logical flaw in substituting TABLE_DUM for x in the expression "x join y" when x is not in the catalogue?
(Assuming that the syntax requires x to be a relation and with the whole expression's value being TABLE_DUM as well and granting that such a result might seem surprising to most people.)
p Received on Fri Jun 30 2006 - 17:57:47 CEST