正如Thomas Connolly和Carolyn Begg在180页写的“数据库解决方案第二版”一书所述：
第三范式（3NF） 一个已经在1NF和2NF中的表，其中所有非主键列中的值只能从主键列而不是其他列中计算出来。
我见过很多人们使用标识列的情况，尽管他们的表中已经有了主键列。记录也可以从标识列中得出，如果我们在表中使用自动递增的标识列和主键，是不是违反了3NF？
更新：如果不是这样，哪个列应作为另一个表中的外键引用。主键列或标识列？
那本书数据库解决方案：建立数据库的第2版2004年版的分步指南是一个烂摊子。不幸的是，它说的是错误的东西，它会误导，并且很多措辞都非常糟糕 - 比如“锻炼” - 这是非正式的，从未定义过。
第三范式（3NF） 一个已经在1NF和2NF中的表，其中所有非主键列中的值只能从主键列而不是其他列中计算出来。
这个错误的定义实际上是非正式的，当一个表只有一个CK（候选键）时。但是这本书没有说明，除了间接和后来它给出另一个涉及PKs（主键）的错误定义：
第三范式（3NF）的形式定义是以第一和第二范式形式的表，其中没有非主键列过载地依赖于主键。
后来它仍然说可以有多个CK，但它仍然给出了错误的定义：
因此，对于具有多个候选键的表，您可以使用3NF的通用定义，该表是1NF和2NF的表，并且其中所有非主键列中的值只能从中计算出来候选键列，没有其他列。
它错误地说“主键列”，其中主列即CK列是正确的。
他们的另一本书“数据库系统第4版2005”也引入了特殊的定义案例，当时只有一个CK而不说，所以后来给出了“一般”的定义。至少那些得到“主要属性”是正确的。
第三范式（3NF）的一般定义是第一和第二范式中的关系，其中没有非候选关键属性在传递上依赖于任何候选关键字。
对于具有任何正常形式的多个CK的表，没有什么不寻常的。
不可以.3NF定义的“官方”措辞通常使用术语“主要属性”或“非主要属性”。如果你的书暗示这意味着“主键的属性”，那么把你的书扔进垃圾箱。这是错误的。 “主要属性”表示“作为任何键的一部分的属性”，“非主要属性”表示“不属于任何键的属性”。因此，在您的“自动增量属性”（以及将使其成为关键字的所有适用FD）的关系模式中的引入不可能引入3NF违规，因为它不会引入非主要属性。
你引用的段落是错误的 - 或者至少它是如此非正式，以至于作为解释是无用的。
如果关系R处于第二范式并且R的每个非素属性非传递性地依赖于R的每个候选关键字，则关系R是第三范式。
Codd E. F.，“数据库关系模型的进一步规范化”
候选钥匙是重要的。具有多个键的表没有错。