Database 究竟什么是2NF和3NF？

标准化的要点是什么

我的意思是，如果标准形式不在2NF中，那是因为部分依赖性，即非键属性依赖于候选键的一部分。 比如说，对于R（a，B，C）与FDs的关系：

AB->C, B->C

显然，AB是候选键，

B->C

是部分依赖项

解决方案：分解关系，使（B，C）形成一个以B为键的新关系

现在，如果一个关系在3NF中是而不是，这是因为一个非关键属性依赖于另一个非关键属性，即 如果关系R（a，B，C）的FD为：

显然，A是键，B->C显示可传递的依赖关系，所以在3NF中不是这样

解决方案：分解关系，使（B，C）形成一个以B为键的新关系

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

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

• 1nf——所有元素都是原子形式的
• X NF——如果有的话 表单

  非\u键->非\u素数属性的依赖关系，
  将关系分解为具有此属性的新关系之一
  特定的“non_key”作为具有这些non_prime_属性的键

• BCNF ：其中对于表单X->Y的所有依赖项，X是一个超级键

---

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

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

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

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

那么，确切的区别是什么

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

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

（3NF通常定义为2NF加上CKs上非素属性的不可传递依赖项，但实际上没有此类FDs意味着CKs上非素属性的部分FDs，因此2NF，因此第一个条件是冗余的。）

为什么不看看，如果存在一个依赖关系，其中一个非素数属性由一个不是候选键的东西决定

为什么这种情况会有帮助？这并不是仅仅描述如何摆脱2NF和3NF的FDs问题——这就是放入3NF的作用

摆脱不由超键确定的非平凡FD会产生BCNF。它意味着2NF&3NF。但这与他们两人都不同。BCNF关系不显示基于FD的更新异常。它总是可以实现的。然而，在“保留FDs”的同时，3NF始终是可以实现的，而BCNF则不是。在某些情况下，为了在视图/查询中强制执行保留在原始文件中的FD（通过组件上的约束提供），我们需要EQD（相等依赖项）约束。也就是说，两个列集具有相同的子代码值集，这比FD更昂贵。要么您有BCNF和EQD，要么您有3NF/EKNF和FD，要么您有某些更新异常

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

---

PS对给定NF的规范化不一定涉及对较低NFs的规范化。

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

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

可能会让你更满意的是BCNF。实际上，BCNF是在4NF之后发现的，因此该名称已经在使用中。但BCNF必须置于3NF和4NF之间，因为它比3NF更具限制性

A->B,B->C