Thomas Connolly と Carolyn Begg によって書かれた Database Solutions Second Edition の本で述べられているように、180 ページ:
第 3 正規形 (3NF)
すでに 1NF および 2NF にあり、すべての非主キー列の値が主キー列のみから計算でき、他の列からは計算できない表。
テーブルに主キー列が既にあるにもかかわらず、ID 列を使用するシナリオを数多く見てきました。ID 列からレコードを計算することもできるので、自動インクリメントされた ID 列をテーブルの主キーと共に使用すると、3NF に違反しませんか?
更新:そうでない場合、どの列を別のテーブルの外部キーとして参照する必要がありますか?主キー列またはID列?
その本 Database Solutions: A Step by Step Guide to Building Databases 2nd 2004 Edition はめちゃくちゃです。残念ながら、それは間違ったことを言い、誤解を招き、多くの言葉遣いは非常に貧弱です-「ワークアウト」のように-非公式で決して定義されていません.
第 3 正規形 (3NF)
すでに 1NF および 2NF にあり、すべての非主キー列の値が主キー列のみから計算でき、他の列からは計算できない表。
その間違った定義は、実際には非公式で、テーブルに CK (候補キー) が 1 つしかない場合を対象としています。しかし、この本では、PK (主キー) を含む別の間違った定義を与える場合を除いて、間接的および後でそれを述べていません。
第 3 正規形 (3NF) の正式な定義は、第 1 および第 2 正規形であり、非主キー列が主キーに推移的に依存しない表です。
後で、複数のCKが存在する可能性があると言われていますが、それでも間違った定義を示しています:
したがって、複数の候補キーを持つテーブルの場合、3NF の一般化された定義を使用できます。これは、1NF と 2NF にあるテーブルであり、主キー以外のすべての列の値は、候補キー列があり、他の列はありません。
プライム列、つまりCK列が正しい「主キー列」と言っているのは間違っています。
彼らの別の本 Database Systems 4th Edition 2005 でも、CK が 1 つしかない場合の定義の特殊なケースが紹介されています。少なくともそれらは「プライム属性」を正しく取得します。
第 3 正規形 (3NF) の一般的な定義は、非候補キー属性が候補キーに推移的に依存しない、第 1 および第 2 正規形の関係です。
テーブルが通常の形式で複数の CK を持つことは異常ではありません。