在数据库解决方案中所说的第二版由Thomas Connolly和Carolyn Begg Page 180：
第三正常形式(3NF(
一张已经在1NF和2NF中的桌子，在 所有非主要键中的值都可以从 仅主键列和其他列。
我看到了许多人使用身份列的情况，尽管他们的表中已经有一个主键列。还可以从"身份"列中制定出记录，因此，如果我们使用自动插入身份列以及表中的主键？
更新：如果不是这样，则应将哪个列作为另一个表中的外键引用。主键列或身份列？
no。3NF定义的"官方"措辞通常使用术语" prime属性"或"非prime属性"。如果您的书暗示这意味着"主要钥匙的属性"，则将您的书扔进垃圾箱。这是错误的。" prime属性"是指"密钥的任何的一部分"one_answers"非prime属性"的一部分的"属性"表示"不是键的任何的一部分的属性"。因此，在关系架构中的介绍您的"自动插入属性"(以及所有将使其成为关键的FD的FD的介绍(不可能引入3NF违规，因为它不会引入非prime属性。
您引用的段落是错误的 - 或者至少是如此非正式，以至于没有用作解释。
一个关系r如果是第二个正常形式，则为第三个正常形式 R的每个非质量属性都是非传输依赖的 r。
的每个候选钥匙
Codd E. F.，"数据库关系模型的进一步归一化"
候选密钥很重要。具有超过一个键的表没有错。
该书籍数据库解决方案：构建数据库2nd 2004 Edition的逐步指南是一团糟。不幸的是，它说了错误的话，误导了，而且他们的许多措辞非常差 - 像"锻炼" - 这是非正式的＆amp;从未定义。
第三正常形式(3NF(
一个已经在1NF和2NF中的表，其中所有非主要键列中的值只能从主键列(S(和其他其他列中计算出来。
错误的定义实际上是为了非正式的，而何时只有一个CK(候选密钥(。但是这本书不是 say ，除了间接和以后时，当它给出另一个错误的定义时，键(：
第三正常形式(3NF(的形式定义是第一台 和第二个正常形式，其中没有非主要键列是传输的 取决于主要键。
后来仍然说有多个CK，但仍然给出错误的定义：
因此，对于具有多个候选密钥的表，您可以使用广义 3NF的定义，这是1NF和2NF的表格，在 所有非主要键列中的值可以从 仅候选键列，没有其他列。
错误地说"初级键"，其中 prime列 ie ck列是正确的。
他们的其他书籍数据库系统第4版2005还引入了特殊情况的定义案例，何时只有一个CK而不这么说，然后后来给出了"一般"定义。至少这些获得"主要属性"正确。
第三正常形式(3NF(的一般定义是一种关系，以第一和第二正常形式在 哪些非候选属性属性依赖于任何候选密钥。
具有任何正常形式的多个CK的表没有什么不寻常的。