Re: Advanced SQL
From: Brian Selzer <brian_at_selzer-software.com>
Date: Fri, 7 Sep 2007 13:40:58 -0400
Message-ID: <K2gEi.1841$ZA5.602_at_nlpi068.nbdc.sbc.com>
> In that case the declared candidate key is not really a candidate
> key. Under the assumption that the declared candidate keys are indeed
> candidate keys, the claim is correct.
>
> Under the assumption that I just mentioned, that claim is actually
> also correct.
> -- Jan Hidders
>
Received on Fri Sep 07 2007 - 19:40:58 CEST
Date: Fri, 7 Sep 2007 13:40:58 -0400
Message-ID: <K2gEi.1841$ZA5.602_at_nlpi068.nbdc.sbc.com>
"Jan Hidders" <hidders_at_gmail.com> wrote in message
news:1189173585.627344.49900_at_19g2000hsx.googlegroups.com...
> On 7 sep, 15:43, Jon Heggland <jon.heggl..._at_idi.ntnu.no> wrote:
>> Quoth Evan Keel: >> >> > "David Portas" <REMOVE_BEFORE_REPLYING_dpor..._at_acm.org> wrote in >> > message >> >news:pZSdnfih_oRy5H3bRVnyigA_at_giganews.com... >> >> Call me picky but I am not entirely comfortable with that U.Texas >> >> site, >> >> even though it's a commendable effort overall. >> >> >> "The definition of second normal form states that only tables with >> >> composite primary keys can be in 1NF but not in 2NF" >> >> > They have it right here. All non-key attributes must be dependent on >> > the >> > full key. Only applies to tables with keys composed of multiple >> > columns> >> >> No. There may be dependencies where the left side is empty. >
> In that case the declared candidate key is not really a candidate
> key. Under the assumption that the declared candidate keys are indeed
> candidate keys, the claim is correct.
>
That's not true, Jan, consider:
{A, B, C} | A --> B /\ {} --> C
If {} --> C holds, then A --> C also holds. Since A --> B /\ A --> C, then A --> BC.
{{A:1, B:2, C:1} {A:2, B:4, C:1} {A:3, B:4, C:1} {A:4, B:3, C:1}}
Clearly A is the only candidate key, even though the FD {} --> C holds.
>> But it's a >> common mistake. If I remember correctly, one of my database textbooks >> "proves" that any relvar with just two attributes is automatically in >> BCNF. >
> Under the assumption that I just mentioned, that claim is actually
> also correct.
>
> -- Jan Hidders
>
Received on Fri Sep 07 2007 - 19:40:58 CEST