苦苦挣扎，看看他们之间的差异。我知道我们说2NF是“全键”而3NF“只不过是关键”。
通过Smashery：What are 1NF, 2NF and 3NF in database design?引用这个伟大的答案
用于3NF的示例与2NF完全相同 - 它是一个仅依赖于一个键属性的字段。 3NF的例子与2NF的例子有何不同？
谢谢
假设某种关系满足形式A-> B的非平凡功能依赖性，其中B是非主要属性。
如果A不是超级密钥但是候选密钥的适当子集，则违反2NF
如果A不是超级密钥，则违反3NF
您已经发现3NF要求只是2NF要求的特殊情况（但并非如此特殊）。 2NF本身并不是很重要。重要的问题是A是否是超级密钥，而不是A恰好恰好是候选密钥的某个部分。
既然你问一个关于existing so question答案的非常具体的问题，这里有一个解释（基本上我会说dportas已经在他的答案中说了什么，但更多的话）。
不在2NF而不在3NF中的设计示例不尽相同。
是的，两种情况下的依赖关系都在一个字段上。
但是，在非2NF示例中：
而在非3NF示例中（在2NF中）：
在这两种规范化的情况下，你都会创建一个不会出现更新异常的附加表（更新异常的例子：在2NF示例中，如果你为Coursename更新IT101|2009-2会发生什么，但IT101|2009-1不会更新？你会得到不一致=无意义=无法使用的数据）。
所以，如果你记住密钥，整个密钥，除了覆盖2NF和3NF的密钥外，在规范化时应该对你有用。 2NF和3NF之间的区别对你来说可能看起来很微妙（问题是在附加依赖项中，数据依赖的属性是否是候选键的一部分） - 而且，它是 - 所以只需接受它。
2NF允许非素数属性在功能上依赖于非素数属性
但
3NF允许非素数属性在功能上仅依赖于超级键
因此，当表格在3NF时，它是2NF，3NF比2NF更严格
希望这可以帮助...
当密钥和其他不依赖它的列之间没有关系时，您已达到第3个NF。
不确定我的教授是否会这样说，但这就是它。
如果你是“在外地”。忘记定义。寻找“最佳实践”。一个是干：不要重复自己。
如果你遵循这个原则，你已经掌握了NF所需的一切。
这是一个例子。您的表具有以下架构：
PERSONS : id, name, age, car make, car model
年龄和姓名与人员条目（=> 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的另一个角度来看。
标准化程度越高，数据越好，但如果实际上过于复杂则不能提高性能，也不能理解数据。
2NF遵循部分依赖，而3NF遵循传递函数依赖。重要的是要知道3NF必须在2NF并且支持传递函数依赖性。