Question

苦苦寻找他们之间的差异。我知道我们说2NF是“全键”而3NF“只不过是钥匙”。

3NF使用的示例与2NF完全相同 - 它是一个仅依赖于一个键属性的字段。 3NF的示例与2NF的示例有何不同？

由于

Answer 1

假设某种关系满足形式A-> B的非平凡功能依赖性，其中B是非主要属性。

如果A不是超级密钥但是候选密钥的适当子集

，则违反了<2> 2NF 如果A不是超级密钥，

违反了3NF

您已经发现3NF要求只是2NF要求的特殊情况（但并非如此特殊）。 2NF本身并不是很重要。重要的问题是A是否是超级密钥，而不是A恰好恰好是候选密钥的一部分。

Answer 2

因为你问一个关于existing so question的答案的非常具体的问题，这里有一个解释（基本上我会说dportas已经在他的答案中说了什么，但更多的话）。

不在2NF而不在3NF中的设计示例并不相同。

是的，两种情况下的依赖关系都在一个字段上。

但是，在非2NF示例中：

虽然在非3NF示例中（在2NF中）：

在这两种规范化的情况下，你都会创建一个不会出现更新异常的附加表（更新异常的例子：在2NF示例中，如果更新Coursename的{{1}}会发生什么，但不会{ {1}}？你得到不一致=无意义=无法使用的数据。）

所以，如果你记住密钥，整个密钥，除了密钥，其中包括2NF和3NF，它们在规范化时应该对你有用。 2NF和3NF之间的区别对你来说可能看起来很微妙（问题是在附加依赖项中，数据所依赖的属性是否是候选键的一部分） - 而且，它是 - 所以只需接受它。

Answer 3

2NF 允许非素数属性在功能上依赖于非素数属性

但

3NF 允许非素数属性在功能上仅依赖于超级键

因此，当一张表在3NF时，它在2NF，3NF比2NF更严格

希望这会有所帮助......

Answer 4

当密钥和其他不依赖它的列之间没有任何关系时，你已经达到了第3个NF。

不确定我的教授会不会这样说，但这就是它。

如果你是“在外地”。忘记定义。寻找“最佳实践”。一个是干：不要重复自己。

如果您遵循这一原则，您已经掌握了NF所需的一切。

这是一个例子。您的表具有以下架构：

PERSONS : id, name, age, car make, car model

年龄和名称与人员条目（=＆gt; id）相关，但模型取决于汽车而非人。

然后，你将它分成两个表：

PERSONS : id, name, age, car_models_id (references CAR_MODELS.id)
CAR_MODELS : id, name, car_makes_id (references CAR_MAKES.id)
CAR_MAKES : id, name

您可以在2FN中复制，但不能在3FN中复制。

规范化都是关于非复制，一致性，以及从外键和JOIN的另一个角度来看。

标准化程度越高，数据越好，但如果实际上过于复杂，则不能提高性能，也不能理解数据。

Answer 5

2NF遵循部分依赖性，而3NF遵循传递函数依赖性。重要的是要知道3NF必须在2NF并且支持传递函数依赖。