2NF分解+数据库规范化

Question

如果有人知道 2NF，如果你能告诉我我对它的理解是否正确，我将不胜感激，我的书甚至没有提到它（除了说具有“历史意义”）而且我一直没能找到一个真正的网上的好例子。我正在学习测试，想知道我关于如何完成 2NF 分解的推理是否正确

R = {a, b, c, d, e, f, g} F = {AB --> C, A --> DE, B --> F, F --> GH, D --> IJ }

我做的第一件事是找到很容易看到的超级键 (AB)+ = R，但是我不确定这是否是 2NF 定义在使用术语“键”时的意思

第二，我使用了 AA 并在 F 中组合了一些术语（只是为了使其更易于管理）

F = {AB --> C, A --> DEIJ, B --> FGH}

第三，我删除了部分函数依赖我不太确定（我确实在没有 eval 的情况下查找过它）我认为 PFD 是什么我认为当你有一个 FD 时，在这种情况下，LHS 是超级键的一个适当的子集

A --> DEIJ 和 B --> FGH

第四，我将其分解为从步骤 3 中删除违规的关系

R1 = AB --> C

R2 = A --> DEIJ

R3 = B --> FGH

我真的在找人给我反馈，如果我正确理解这个概念，任何帮助将不胜感激

谢谢

Answer 1

有一句格言是这样的：

. . . 所以帮我科德

在您的示例中，我们可以假设 1NF 开始，因为关系结构并不意味着行内的任何重复组（即没有 D ₁、 D ₂、 D ₃ 等）。

R = {a, b, c, d, e, f, g} F = {AB --> C, A --> DE, B --> F, F --> GH, D --> IJ }

2NF 处理“整个密钥”——如果您有一个复合密钥并且关系的某些成员依赖于该密钥的一部分，那么它们应该被拆分为自己的关系。在你的情况下：

R1 = AB --> C 在 2NF 中，因为“AB”是“整个密钥”
R2 = A --> DEIJ 是 2NF 但不是 3NF 作为 A --> DE，但是 A --> IJ 不是 3NF，因为 I 和 J 的真正依赖是 D --> IJ。D 不是这个关系的键（A --> DEIJ），所以 A --> IJ 违反了 3NF 的“只有键”原则。
R3 = B --> FGH 在 2NF 但不是 3NF，因为 B --> F 是正确的关系，F 依赖于整个密钥“B”。但是，B --> GH 不在 3NF 中，因为正确的关系是 F --> GH。B --> GH 违反了“只有关键”原则，因为 G ahd H 正确地依赖于非关键属性 F。

您对 2NF 的分解是正确的。分解为 3NF 需要将具有自身依赖性的非关键属性放入单独的关系中。

3NF 中的关系如下所示：