2015-12-13 76 views
0

我在做标准化问题时似乎有一个奇怪的问题。当我用实际的名字给出关系时,我可以很容易地弄清楚这些,但是当我收到信件时,它似乎要困难得多。2NF和3NF标准化

对于下面的问题,我不知道为什么它不是3NF,为什么它是2NF。

鉴于R(A,B,C,d,E,F)

的FD = {AB-> C,DBE-> A,BC-> d,BE->女,F-> d }

因此,对于2NF,所有右侧属性必须完全依赖于左侧属性。对于3NF,所有左侧属性必须是超级键或右手属性必须是主要属性。

我试图画出来,但我甚至找不到候选键。任何人都可以帮我确定为什么这不是3NF?另外,这里的候选关键字是什么?因为我没有看到任何闭合等于原始关系的属性。

+0

的候选键可能是复合 - 当然也不能保证它将是一个单身属性。 ABE不是可能的候选关键?鉴于AB,你可以找到C;给定BE,你可以找到F,因此D包含所有的属性。 BE-> F和F-> D传递依赖可防止它成为3NF,不是吗? –

+0

我认为DBE可能是另一个候选键。鉴于DBE,你可以找到A;给BE,你可以找到F;给AB,你可以找到C;它再次覆盖了所有的属性。 –

+0

BE是唯一的候选键。 @JonathanLeffler对传递依赖关系是正确的。 –

回答

0

我在做归一化问题时似乎有一个奇怪的问题。 当我给出与实际名称的关系时,我可以很容易地计算出这些数字,但是当我收到信件时,它似乎要困难得多。

是的,它不太直观的字母。我会告诉你一个整洁的方法,你可以按照确定在这种情况下的候选键:

让三列左(大号),中间(中号),右([R),其中左边的列由在所有给定函数依赖关系中仅出现在左侧的所有属性组成。在我们的例子中,这些属性将会是BE,因为它们总是在任何给定的FD的左侧(或者你可以说它们从不在任何给定的FD的右侧)。同样,中间栏包含出现在给定FD的左侧和右侧的属性。所以我们在中间的列中有A,C,DF。右列包含仅出现在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的是:

  1. AB->ç
  2. DBE->一个
  3. BC-> d
  4. BE->˚F
  5. F-> d

我们注意到在所有这些FD的RHS中是一个非主要属性。所以在所有这些LHS应该是它在3NF的关键。我们看到(1),(3)和(5)违反了这个规定,因此它不是在3NF中的。 (注:(2)可以看出,D在LHS是外来属性,因此它的BE->A,因此(2)不违反3NF规则