2NF 和 3NF 归一化

Question

我在做规范化问题时似乎遇到了一个奇怪的问题。当我给出与实际姓名的关系时，我可以很容易地弄清楚这些，但是当我得到字母时，这似乎要困难得多。

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

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

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

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

我试着把它画出来，但我什至找不到候选键。谁能帮我确定为什么这不是 3NF？另外，这里的候选键是什么？因为我没有看到任何具有等于原始关系的闭包的属性。

Answer 1

我在做规范化问题时似乎遇到了一个奇怪的问题。 当我给出与实际姓名的关系时，我可以弄清楚这些 很容易，但是当我收到信件时，它似乎要困难得多。

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

在左（L）、中（M）和右（R）三列中，左列包含所有属性仅出现在所有给定函数依赖项的左侧。在我们的例子中，这些属性将是B 和E，因为它们总是在任何给定 FD 的左侧（或者你可以说它们从不在任何给定 FD 的右侧。）。同样，中间列包含出现在给定 FD 左右两侧的属性。所以我们在中间列有A,C,D 和F。右列包含仅出现在 FD 右侧的属性（从不在任何给定 FD 的 LHS 上）。所以我们有：

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

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

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

所以在我们的例子中，我们首先检查BE 是否是候选键。我们发现 BE-closure 包含关系 R 的所有属性，因此它是候选键。 （注意：如果BE 不是候选键，那么我们将一个接一个地从中间（M）列中获取属性并将其与BE 组合并检查其闭包，例如BEA,@987654333 @,BED ...)

所以现在我们只有 1 个候选键 BE。所以我们的 prime 属性是 {B,E} 而 non-prime 属性是 {A,C,D,F}。

如果 RHS 是非主属性且 LHS 不是候选键，我们知道 3NF 是违反。给定的 FD 是：

1. AB->C
2. DBE->A
3. BC->D
4. BE->F
5. F->D

我们注意到在所有这些 FD 的 RHS 中都是非主要属性。所以在所有这些 LHS 中应该是它进入 3NF 的关键。我们看到 (1)、(3) 和 (5) 违反了这一点，因此它不在 3NF 中。 （注意：在 (2) 中，我们可以看到 LHS 上的 D 是一个无关属性，因此它的 BE->A 和因此 (2) 不违反 3NF 规则）