我在做归一化问题时似乎有一个奇怪的问题。 当我给出与实际名称的关系时,我可以很容易地计算出这些数字,但是当我收到信件时,它似乎要困难得多。
是的,它不太直观的字母。我会告诉你一个整洁的方法,你可以按照确定在这种情况下的候选键:
让三列左(大号),中间(中号),右([R),其中左边的列由在所有给定函数依赖关系中仅出现在左侧的所有属性组成。在我们的例子中,这些属性将会是B
和E
,因为它们总是在任何给定的FD的左侧(或者你可以说它们从不在任何给定的FD的右侧)。同样,中间栏包含出现在给定FD的左侧和右侧的属性。所以我们在中间的列中有A
,C
,D
和F
。右列包含仅出现在FD右侧的属性(从不在任何给定的FD的LHS上)。因此,我们有:
L | M |R
B,E|A,C,D,F|-
现在,你有此表请记住下列规则:(这些都是非常直观)左
- 属性(大号)栏是总是部分候选键
- 右侧属性(R)列为从不候选键的一部分
- 中间的属性(M)列可能或可能不会是候选键的一部分。
所以在我们的案例中,我们从检查BE
是否是候选关键字开始。我们发现BE-closure由关系R
的所有属性组成,因此它是候选关键字。 (注意:如果BE
不是候选关键字,那么我们将从中间(M)列中逐一获取属性,并将其与BE
结合并检查其关闭,例如BEA
,BEC
,BED
...)
所以现在我们只有1个候选键BE
。因此,我们的首要属性是{B,E}和非黄金属性{A,C,d,F}。
我们知道,3NF是违反如果RHS是一个非主属性和LHS是不是候选键。鉴于FD的是:
- AB->ç
- DBE->一个
- BC-> d
- BE->˚F
- F-> d
我们注意到在所有这些FD的RHS中是一个非主要属性。所以在所有这些LHS应该是它在3NF的关键。我们看到(1),(3)和(5)违反了这个规定,因此它不是在3NF中的。 (注:(2)可以看出,D
在LHS是外来属性,因此它的BE->A
,因此(2)不违反3NF规则)
的候选键可能是复合 - 当然也不能保证它将是一个单身属性。 ABE不是可能的候选关键?鉴于AB,你可以找到C;给定BE,你可以找到F,因此D包含所有的属性。 BE-> F和F-> D传递依赖可防止它成为3NF,不是吗? –
我认为DBE可能是另一个候选键。鉴于DBE,你可以找到A;给BE,你可以找到F;给AB,你可以找到C;它再次覆盖了所有的属性。 –
BE是唯一的候选键。 @JonathanLeffler对传递依赖关系是正确的。 –