database - 需要归一化理论解释

Question

我正在查看与复合主键的关系的具体示例。基于它的功能依赖，我知道它在 1NF 中。在将其规范化为 3NF 时，我遇到了一个我还没有遇到过的情况。我遵循了所有部分依赖和传递依赖的步骤，但是规范化为 3NF 的最后一步要求您创建一个包含主键和依赖于它的所有非主属性的关系。

在我的具体情况下，我有主键，但没有完全的功能依赖。我是否制作一个只包含我的复合主键的表？还是我根本不做？

我没有混淆复合键和主键。请参阅下面的评论，了解为什么我认为我的问题与那个不同

Answer 1

拥有一个由复合键组成且没有其他属性的关系是完全合法的。它不仅在理论上有效，而且在现实世界中也发生过。

在这种情况下，该关系只是断言由复合键标识的东西的存在。并且数据的用户将使用它来测试是否存在，而不是用于与非关键属性的关系通常用于相同类型的查找。

Answer 2

FD（功能依赖）与 1NF 无关，无论您使用“1NF”的各种含义中的哪一个。所以不清楚你想对 1NF 说什么。根据定义，关系对每个元组的每个属性都有一个值。与某个部分的“值列表”之类的关系（例如某个部分的属性（例如元组））不是关系，因此 CK（候选键）和 FD 不适用。如果您将“1NF 关系”定义为没有某些数据类型的关系（因为一些模糊的应用程序相关的关于“原子性”的公认智慧，或者在 Codd 的意义上没有关系值属性) 那么满意度不取决于 FD 是否保留具有该数据类型的设计。（此外，如果这种“非 1NF”“非原子”属性设计的“归一化”“原子”属性版本满足 FD，则原始版本具有一定的约束，但它不是 FD 约束。）

非部分的 FD 已满。在通往 2NF 和 3NF 的过程中，唯一重要的部分 FD 是 CK 上非主要属性的部分 FD。当这些都消失了，你就有了 2NF。（从“遵循所有部分依赖和传递依赖的步骤”听起来你的计划是分解为 2NF，然后分解为 3NF。）在需要 2NF 的 3NF 的定义中没有提到部分 FD。此外，3NF 的定义和将关系放入 3NF 的通用算法只是不使用部分 FD。

还可以有其他部分 FD。他们只是无关紧要。特别是，正确超键上的所有属性 FD 都是部分的。只需遵循确定关系是什么范式的定义，并遵循将关系放入范式的算法。这适用于所有定义和算法。不必担心您注意到的每个属性都可能是“坏的”。

PS您不应该先将关系放入3NF，然后将其放入2NF。这可以排除原始的一些好的 3NF 分解被发现。使用 3NF 算法。（通常的 3NF 实际上会以稍强的 EKNF（基本键范式）生成分解）。