正如 Thomas Connolly 和 Carolyn Begg 在第 180 页所写的 Database Solutions Second Edition 中所说：
第三范式 (3NF)
已经在 1NF 和 2NF 中的表，其中所有非主键列中的值只能从主键列而不是其他列中计算出来。
我见过很多人们使用标识列的场景，尽管他们的表中已经有一个主键列。记录也可以从标识列中计算出来，那么如果我们在表中使用自动递增标识列和主键，是否违反了 3NF？
更新：如果不是这样，哪个列应该被引用为另一个表中的外键。主键列还是标识列？
不会。3NF 定义的“官方”措辞通常使用术语“主要属性”或“非主要属性”。如果你的书暗示这意味着“主键的属性”，那么就把你的书扔进垃圾箱。这是错误的。“主属性”是指“属于任何键的一部分的属性”，“非主属性”是指“不属于任何键的属性”。因此，在关系模式中引入您的“自动增量属性”（以及所有使其成为密钥的适用 FD）不可能引入 3NF 违规，因为它不会引入非主要属性。
您引用的段落是错误的-或者至少它是如此非正式，以至于无法解释。
如果关系 R 处于第二范式并且 R 的每个非主属性都非传递地依赖于 R 的每个候选键，则关系 R 处于第三范式。
Codd EF，“数据库关系模型的进一步规范化”</p>
候选键很重要。一张有多个钥匙的桌子没什么问题。
那本书 Database Solutions: A Step by Step Guide to Building Databases 2nd 2004 Edition 是一团糟。不幸的是，它说错了话，误导了他们，而且他们的很多措辞都非常糟糕——比如“锻炼”——这是非正式的，从未定义过。
第三范式 (3NF)
已经在 1NF 和 2NF 中的表，其中所有非主键列中的值只能从主键列而不是其他列中计算出来。
这个错误的定义实际上是非正式的，并且当一个表只有一个 CK（候选键）时。但是这本书并没有说，除非间接地和后来它给出了另一个涉及 PK（主键）的错误定义：
第三范式 (3NF) 的正式定义是第一范式和第二范式的表，其中没有非主键列可传递地依赖于主键。
后来它说可以有多个CK，但它仍然给出了错误的定义：
因此，对于具有多个候选键的表，您可以使用 3NF 的广义定义，这是一个位于 1NF 和 2NF 中的表，其中所有非主键列中的值只能从候选键列，没有其他列。
错误地说“主键列”，其中素数列即CK 列是正确的。
他们的另一本书 Database Systems 4th Edition 2005 也介绍了定义的特殊情况，当只有一个 CK 时没有说明，然后给出“一般”定义。至少那些得到“主要属性”是正确的。
第三范式 (3NF) 的一般定义是处于第一和第二范式的关系，其中没有非候选键属性传递依赖于任何候选键。
一张表有多个任何正常形式的 CK 并没有什么不寻常的地方。