究竟什么是 2NF 和 3NF？答案

【问题标题】：Exactly what is 2NF and 3NF?究竟什么是 2NF 和 3NF？
【发布时间】：2018-03-14 14:23:33
【问题描述】：

规范化的重点是什么？

我的意思是，如果范式不在 2NF 中，那是因为部分依赖，即非键属性依赖于候选键的一部分。因此，假设对于与 FD 的关系 R(A,B,C)：

AB->C, B->C

很明显，AB 是候选键，B->C 是部分依赖。

解决方案：分解关系，使得(B,C)形成一个以B为键的新关系。

现在，如果一个关系在 3NF 中是 not，那是因为一个非关键属性依赖于另一个非关键属性，也就是说如果关系 R(A,B,C) 的 FD 是：

A->B,B->C

显然，A 是关键，B->C 显示传递依赖，因此不在 3NF 中。

解决方案：分解关系，使得(B,C)形成一个以B为键的新关系。

那么，确切的区别是什么？我的意思是，为什么会有如此明显的区别？基本上在这两种情况下，动作是相同的。使用行列式（此处为 B）是否是键的一部分的依赖关系分解关系。为什么有单独的术语，如部分依赖或传递依赖？为什么不直接看看，如果存在一个依赖关系，其中一个非主属性由一个不是候选键的东西确定（无论它是部分键还是另一个非主属性）

为什么我们不能实现这样的方法：

1 NF -- 具有原子形式的所有元素
X NF -- 如果有的话 non_key -> non_prime_attribute(s) 形式的依赖关系，分解与具有此的新关系之一的关系特定的“non_key”作为具有这些 non_prime_attributes 的键。
BCNF : 对于 X->Y 形式的所有依赖项，X 是超键在哪里？

我们可以有这样的NF条件格式吗？它是否结合了所有条件？

【问题讨论】：

嗨。以前你的语言不清楚，现在你添加了更多真正不清楚的内容。但是，正如我在评论中所说的那样，当您将其添加到评论中时，我的扩展答案似乎解决了您的添加。
您关于我们为什么不以这种方式学习的问题也许是问题的核心。我已经 30 多年没有研究这些东西了，我仍然倾向于做出回应，就好像这些概念现在和当时处于完全相同的状态一样。较新的文本或教程可能已经提出了更好的组织和呈现材料的方法。
同时，当我第一次开始在 SO 上发帖时，许多新手甚至从未听说过规范化。如今，很多参与者轻描淡写地把“规范化设计”当作“好设计”的代名词。

标签： database database-design database-normalization

【解决方案1】：

那么，到底有什么区别呢？

2NF 不是 3NF 并且 2NF 的定义不是 3NF 的定义。没有任何特定的语义或句法结构相似性会留下某种“差异”，除了 2NF 关系可能存在违反 3NF 的问题 FD（功能依赖），而 3NF 关系没有。您可以在各处找到定义。您几乎自己在这里正确地给出了它们。但是 NF（范式）是一个条件，而不是一个过程。你是什么意思“行动是一样的”？处于 3NF 意味着处于 2NF，因此自然分解为 3NF 也得到 2NF。但是有些关系在 2NF 中但不在 3NF 中，并且可能存在与 2NF 的关系的分解未达到 3NF。这些分解将涉及删除所有问题部分 FD，但不会导致删除所有问题传递 FD。

（因为 3NF 总是可以实现的，并且与 2NF 相比没有其他缺点，所以 2NF 甚至没有用。它只是最先发现的一个条件，不如 3NF 强。）

(3NF 经常定义为 2NF 加上非主属性对 CK 的传递依赖，但实际上没有这样的 FD 意味着 CK 上没有非主属性的部分 FD，因此是 2NF，所以第一个条件是多余的.)

为什么不直接看看，如果存在一个非主属性由不是候选键的东西确定的依赖关系

为什么这个条件会有帮助？这不是仅仅摆脱 2NF 和 3NF 的问题 FD 的描述——这就是放入 3NF 所做的。

摆脱 non-trivial 不是由 superkeys 确定的 FD 恰好给出了 BCNF。它意味着 2NF 和 3NF。但这两者都不同。 BCNF 关系没有表现出基于 FD 的更新异常。它总是可以实现的。然而，在“保留 FD”的同时，3NF 总是可以实现的，而 BCNF 则不是。在某些情况下，为了使保存在原始文件中的 FD 在视图/查询中强制执行，该视图/查询通过对其组件的约束来提供它，我们需要一个 EQD（平等依赖）约束。也就是说，两个列集具有相同的子行值集，这比 FD 执行起来更昂贵。要么您有 BCNF 和 EQD 且更新异常较少，或者您有 3NF/EKNF 和 FD 以及某些更新异常。

真正重要的 NF 是 5NF，这意味着 BCNF，没有更新异常并具有其他好处。（然后我们可能会出于性能原因决定去规范化。）

对给定 NF 的 PS 归一化不一定涉及对较低 NF 的归一化。

【讨论】：

关于“我们为什么不这样学习？”我的答案是如何教授更高 NF 的标准化。但是除了 3NF 之外还有更多。所以我不明白你的句子。您的其余评论尚不清楚。你可以问另一个问题，但你需要用足够多的句子来清楚地表达你的意思。但是请参阅我的新答案部分关于 BCNF。我在看到您的评论之前附加了它，但也许它回答了它。 PS一个数据库教学问题是there is no single notion of "1NF" & "atomic" is nonsense with nothing to do with normalization to higher NFs.
NF 是根据其前身定义的。如果一个表不在 2NF 中并且希望将其放入 3NF，则第一步是将其放入 2NF。作为定义的结果，它是这样教的。如果有一种简单易学的方法可以在 1NF 中取一张桌子并将其放入 BCNF，那可能比现在所教的要好。那仍然没有解决 4NF 和 5NF。
@WalterMitty 没有必要按照前辈来定义 NF，2NF 和 3NF 有很多不需要，而这里的 BCNF 定义也没有。首先归一化到比最终想要的更低的 NF 可以防止进一步归一化找到好的设计。正如许多教科书一样，有一些算法可以直接进入 3NF（实际上是 EKNF）或 BCNF。 Why aren't all the normal forms used?Skipping steps in Normalization?
1) 我喜欢过去 2NF 被发现但 3NF 尚未被发现的日子的想法：) 2) 从未听说过为什么 3NF 可能比 BCNF 更受青睐的实际原因，不胜感激.. 3) 你可以提到 5NF 总是可以实现的。

【解决方案2】：

这听起来好像你想知道为什么他们用不同的名字来称呼这两种范式，而不是发明一种涵盖这两种情况的形式。如果不是这种情况，请忽略此答案。

部分答案是这些表单不是同时被发现的。部分答案是，导致 2NF 的 1NF 问题与导致 3NF 的 2NF 问题不同，尽管它们都表现出有害的冗余。

BCNF 可能会让你更满意一点。 BCNF 实际上是在 4NF 之后被发现的，所以这个名字已经在使用了。但是 BCNF 必须放在 3NF 和 4NF 之间，因为它比 3NF 限制更多，但比 4NF 限制更少。所以它被发现是“乱序的”，可以这么说。

在 BCNF 中，每个（非平凡的）行列式都是候选键。这似乎是你正在寻找的。我猜想任何在 1NF 中并且每个行列式都是候选键的关系，都可以被证明在 2NF 和 3NF 中。但我无法证明这一点。

【讨论】：

告诉人们错误的事情会阻碍他们把事情做对。它也不是微不足道的决定因素，它是微不足道的 FD，我的评论应该是，BCNF 是如果 non-trivial FD 的每个决定因素都是 superkey。（根据您的回答，对于 (a,b,c) 上的 R 带有覆盖 {a->bc} - CK 设置 {a} 并且在 BCNF 中 - 它不在 BCNF 中，因为有非 CK 行列式因为 b->b 成立（平凡的 FD）或因为 ab->c 成立（非 CK 超密钥行列式）。）

【解决方案3】：

2NF 和 3NF 本质上是历史概念，您的问题是合理的。没有真正的理由将它们应用到实际的数据库设计中，因为现在有更好的工具。

在教学方面，提到 2NF 和 3NF 可能是有道理的。这样做可以让学生探索所涉及的概念（就像你所做的那样），同时也教他们一些关于设计理论的起源和基本原理的知识。在学校的数学课上，我学会了从第一原理开始的长除法和微分。没有人在实践中使用这些技术，它们只是教具。

【讨论】：

您很好地说明了良好的教学实践和当前的良好实践之间的区别。当我在 1980 年代了解这些东西时，标准化仍然是一个新概念。在我工作的地方，使用 CODASYL 模型的数据库比使用关系模型的数据库多。

【解决方案4】：

在检查 2NF 之前，关系应该是 1NF。简单来说，2NF 只有完全依赖关系，没有部分依赖关系。完全依赖意味着如果 x 给出 y，那么通过删除 x 中的任何元素，则 y 没有任何关系。如果通过删除 x，您与 y 有关系，那么它是部分依赖。对于 3NF，我们必须检查 2NF，在 3NF 中，我们不应该有任何传递关系，比如如果 x 给 z，那么就没有像 x 给 y 和 y 给 z 这样的关系。

2NF的解决方案为部分依赖创建一个表，并在新关系中添加外键，这是前一个关系的主键。

3NF 的解决方案为 x 给 y 和 y 给 z 创建一个关系。为关系添加键。

【讨论】：