Database 2NF和3NF归一化

我在处理规范化问题时似乎有一个奇怪的问题。当我给出与实际姓名的关系时，我可以很容易地找出这些，但当我给出字母时，这似乎要困难得多

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

给定R（A，B，C，D，E，F）

FDs={AB->C，DBE->A，BC->D，BE->F，F->D}

因此，对于2NF，所有右侧属性必须在功能上完全依赖于左侧属性。对于3NF，所有左侧属性必须是超级键，或者右侧属性必须是基本属性

我试着把这个画出来，但我甚至找不到一个候选密钥。有人能帮我确定为什么这不是3NF吗？还有，这里的候选键是什么？因为我看不到任何闭包等于原始关系的属性

我在处理规范化问题时似乎有一个奇怪的问题。 当我给出与实际姓名的关系时，我可以找出这些 很容易，但当我收到信的时候，似乎要困难得多

是的，它对字母没有那么直观。我将告诉您一种简洁的方法，在这种情况下，您可以按照该方法确定候选密钥：

在左（L）、中（M）和右（R）三列中，左列由所有给定函数依赖项中仅出现在左侧的所有属性组成。在我们的例子中，这些属性将是

B

和

E

，因为它们总是位于给定FD的左侧（或者可以说，它们在给定FD中从不位于右侧）。类似地，中间列包含显示在给定FD的左侧和右侧的属性。因此，我们在中栏有了<代码> < <代码> >代码> C <代码> > <代码> d>代码>和<代码> f>代码>。右列包含仅出现在FD右侧的属性（决不出现在任何给定FD的左侧）。因此，我们：

L  |   M   |R
B,E|A,C,D,F|-

现在您有了这个表，请记住以下规则：（这些规则非常直观）

• 左侧（L）列中的属性始终是候选键的一部分
• 右侧（R）列中的属性是候选键的从不部分
• 中间（M）列中的属性可能是也可能不是候选键的一部分

因此，在本例中，我们首先检查

BE

是否是候选键。我们发现BE闭包包含关系

R

的所有属性，因此它是候选键。（注意：如果

BE

不是候选键，那么我们将从中间（M）列中逐个获取属性，并将其与

BE

组合，并检查其闭包，例如

BEA

，

BEC

，

BED

。）

所以现在我们只有1个候选键

BE

。所以我们的素数属性是{B，E}，而非素数属性是{A，C，D，F}

我们知道，如果RHS是非素数属性，而LHS不是候选密钥，则3NF是违反的。给定的FD为：

AB->C

DBE->A

BC->D

BE->F

F->D

---

我们注意到，在所有这些FD中，RHS是一个非素数属性。所以在所有这些LHS中，它应该是3NF中的关键。我们看到（1）、（3）和（5）违反了这一点，因此它不在3NF中。（注意：在（2）中，我们可以看到LHS上的

D

是一个无关属性，因此它的

BE->A

，因此（2）没有违反3NF规则）

候选密钥可能是复合的-当然不能保证它是一个单态属性。安倍不是一个可能的候选人吗？给定AB，你可以找到C；给定BE，您可以找到F，从而找到D，从而覆盖所有属性。BE->F和F->D可传递依赖关系阻止它成为3NF，不是吗？我认为DBE可能是另一个候选键。给定DBE，您可以找到一个；在给定的条件下，你可以找到F；给定AB，你可以找到C；它再次覆盖所有属性。BE是唯一的候选键@JonathanLeffler关于传递依赖性的观点是正确的。@MikeSherrill'CatRecall'：很好的观点：假设你可以得到A或D，那么我的两个可能的候选键都是超级键，而不是最小键，因此不是候选键。啊，我明白了，谢谢你，我将在考虑所有这些的情况下再次尝试这个问题。