需要归一化理论解释答案

【问题标题】：Normalization Theory Explanation needed需要归一化理论解释
【发布时间】：2017-02-10 03:41:07
【问题描述】：

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

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

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

【问题讨论】：

Normal forms - 2nd vs 3rd - is the difference just composite keys? non trivial dependency?的可能重复
我不会说我的问题与那个问题重复。我确实了解 PK 和 CK 之间的区别。当按照课堂上教给我的步骤标准化为 3NF 时，我首先为每个部分依赖和传递依赖创建一个关系模式。我采取的最后一步是创建一个模式，其中包含原始关系的 PK 以及完全依赖于该 PK 的任何属性
另请参阅this、this、this 和我的其他答案，涉及 3NF/第三范式，或完全*部分*功能*依赖*。还有this 和其他关于 atom* 和 1NF / 第一范式的人。
我使用 PK 与 CK 作为您帖子中许多误解的示例。例如，我们不通过 2NF 得到 3NF 或 BCNF，我们直接使用算法。找一个。您的帖子似乎不是指一个，而是先到 2NF，然后再到 3NF。但是为了达到 2NF，我们摆脱了对 CK 的所有部分依赖，因此只剩下完整的依赖。你的整个帖子就是这样奇怪。而且我没有因为PK vs CK而选择重复。我选择它作为答案。请编辑您的答案以说明您（认为您）遵循的算法并显示您的示例步骤。也谷歌'stackoverflow.com 3NF算法'。

标签： database database-design relational-database database-normalization database-theory

【解决方案1】：

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

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

【讨论】：

我忘了提到这种关系的另一种用途。可以作为三路连接的中间关系。

【解决方案2】：

FD（功能依赖）与 1NF 无关，无论您使用的是 the various meanings for "1NF" 中的哪一个。所以不清楚你想对 1NF 说什么。根据定义，关系对每个元组的每个属性都有一个值。事物like 与事物的关系like 某部分的“值列表”like 某部分的属性like em> 元组不是关系，因此 CK（候选键）和 FD 不适用。如果您将“1NF 关系”定义为没有特定数据类型的关系 (because of some fuzzy application-dependent received wisdom about "atomicity", or in Codd's sense of having no relation-valued attributes)，那么满意度不取决于 FD 是否保留具有该数据类型的设计。（此外，如果这种“非 1NF”“非原子”属性设计的“归一化”“原子”属性版本满足 FD，则原件具有一定的约束，但 这不是 FD 约束。）

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

还可以有其他部分 FD。他们只是无关紧要。特别是，正确超键上的所有属性 FD 都是部分的。只需遵循确定关系是什么范式的定义，并遵循将关系放入范式的算法。这适用于所有定义和算法。 There is no point in worrying about every property you notice that it might be "bad".

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

【讨论】：

我不同意。如果表中有一个值在功能上不依赖于键，则该表不在 1NF 中。这在现实生活中很难做到。但是，有很多设计人员面临这样一种情况，即表的主键决定的不是单个值而是值列表。例如，如果密钥是 studentId，并且列表是学生注册的课程列表。有些人希望将课程列表放在一个单独的列中，并使用逗号分隔值。这实际上违反了 1NF，尽管它看起来不是那样。
“FD”是一个技术术语，当您说“确定值列表”时，您正在滥用（即不使用）它。根据定义，关系对每个元组的每个属性都有一个值。对于某些事物（例如元组之类的事物的属性）具有“值列表”的事物不是关系，因此 CK 和 FD 不适用。如果您将“1NF 关系”定义为没有特定数据类型的关系，因为一些关于“原子性”的模糊认知，满意度不取决于 FD 是否坚持具有该数据类型的设计。（请务必定义“1NF”。）（请参阅我编辑的答案。）
PS CK 是 FD 的结果。每个关系都有一个 CK。 “表中的值在功能上不依赖于键”不会发生。无论如何，“键”是关系中的某种东西，FK也是如此。您可能有一个不是关系的设计，因此（根据您为“1NF”选择的任何定义）它不是“1NF 关系”，但问题不是 CK 和 FD，因为 CK 和 FD 是在关系中。您可能会想到 like CK 或 FD 的事物，涉及事物 like 关系（但不是）。这不是关系、CK 或 FD。
@philpxy 我不相信你是正确的。为了澄清 OP 的概念，我们最好将这种分歧脱线。