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