回答:
Rのすべての非素数属性がRの各候補キーに非推移的に依存している場合、関係Rは第3正規形になります。
EFCodd、1971年、データベースリレーショナルモデルのさらなる正規化
リレーションの定義では、リレーションに少なくとも1つのキーが必要であることが暗黙に示されています。3NFやその他の正規形については、リレーションにキーが1つだけである必要はありません。
残念ながら、データベースの設計と正規化に関する書籍には、1つのキーのみを使用した関係の例が多数あり、複数のキーを使用した例はかなり少なくなっています。最近、複数のキーが非常に一般的な方法であるように思われることを考えると、これは奇妙に思えます。非学術文献における実用的な例の不足は、データベース設計におけるキーの役割についての混乱の原因の1つであるようです。混乱のもう1つの原因は、人気の高いニーモニック「キー以外の何ものでもない」です。そのフレーズは通常ビルケントに起因しますが、3NFの正確な定義ではありません。
質問はルールの解釈に基づいているため、最初にそのリンクされた情報を確認する必要があります。
- テーブル内のすべての属性は、そのテーブルの候補キーによってのみ決定され、非プライム属性では決定されません。
この混乱は、「候補キー」という用語を誤って解釈した結果だと思います。テーブルには複数の候補キーが存在する可能性があります。これが、このグループの中でさらに指定する修飾語が存在する理由です。プライマリおよび代替。テーブルに1つだけのキーがある場合、「主」キーという用語は誤解を招く可能性があり、代わりに別の名前（多分「親」、「元」、「識別」など）と呼ばれるべきでした。ただし、「プライマリ」は「セカンダリ」キーが存在する可能性があることを意味し、それらは「代替」キーと呼ばれます。
代替キーは、一意の制約または一意のインデックスを通じて物理モデルで示されます。また、両方のタイプの候補キー（主キーと代替キー）は、外部キーから参照できることにも注意してください（非常に正当な理由がなければ、通常はそのようなことをしない/すべきではありません！）。
他の列に一意のキーがあったかどうかによって、答えは異なりますか？もしそうなら、なぜですか？
いいえ、それは物理モデリングと論理モデリングの問題であるためです。IDENTITYフィールドはあるが主キーが定義されていないテーブルを持つことができます。テーブルとそのデータは、物理モデルで強制されていなくても、簡単に3NFにすることができます。この違いは、外部キーが定義されているかどうかに似ています。PK / FKが定義されているかどうかに関係なく、テーブルをJOINでき、孤立したレコードがないことができます。そして、これらの構成要素がなければ、データは100％正確になる可能性があります。しかし、PKとFKを定義することは、参照整合性（論理的）と宣言的参照整合性（物理的）の違いです。物理モデルに制約があると、論理モデルのルールを適用するのに役立ちます。
SSN（その頭字語に慣れていない人のための「社会保障番号」）、および代替キーであり、一意のインデックス/制約があることに関して：
私が推薦する反対（ -現実の世界に出て存在するものSSNは、多くの場合、「ナチュラル」キーと考えられている）、そうするのが一般的であったとしても、SSN代替キーであることと、それにUNIQUE制約またはインデックスを置くことを考慮します。主な理由は2つあります。
精度：ほとんどの場合、これらの値は、紙またはオンラインのいずれかでフォームに入力することによってシステムに入力されます。特にソースが誰か他のだらしない手書き（私のものなど、ほとんど判読できない）を読んでいる人によって入力されている紙のフォームである場合、人々は常にデータ入力をしている間間違いを犯します。
データが別のシステムからのものである場合でも、ソースシステムが情報を検証したことを確信できますか？データのエクスポートにバグがなかったと確信できますか？データのインポートにバグがある場合はどうなりますか？
私が理解しているように、第3正規形（3NF）は基本的に、キーが1つだけであることを意味します。
いいえ。2NF、3NF、およびBoyce Coddの正規形（BCNF）は、機能の依存関係を扱います。2NFのテーブルは、非キー列が複数列キーの適切なサブセットに依存している部分的なキー依存関係がないことを意味します。この例のような表は、各候補キーが単一の列であるため、すでに2NFにあります。3NFのテーブルは、すべての非キー列が他のいくつかの非キー列にも機能的に依存しないことを意味し、推移的な依存関係を作成します。候補キーが1つであっても100であっても問題ありません。実際には、3NFではなくBCNFです。これは、機能の依存性に関する「最終的な」正規形です。これは、重複する複数の候補キーが存在する可能性があるため、テーブルが3NFに存在しても、BCNFには存在しない可能性があるためです。したがって、機能の依存関係に関して「完全に正規化された」という意味で3NFという用語を使用する場合、実際に意味するのはBCNFです。
たとえば、auto-increment id列のあるテーブルに、一意でありnullでないことがわかっている列（社会保障番号など）がある場合、この他の列をキーとして使用できます。
それだけでなく、データベースに格納されたデータが、現実の世界で特定したルールと一貫性を保つようにする必要がある場合にもそうである必要があります。
厳密にスキーマ設計の観点から、実用的/ビジネス上の問題（SSNをキー/ FKとして渡す場合のセキュリティ/プライバシーリスクなど）を無視すると、そのようなテーブルは実質的に2つのキーがあるため3NFに含まれませんか？
上記で説明したように、テーブルが3NF（またはより重要なのはBCNF）であるかどうかは、テーブルに含まれる候補キーの数と直交しています。
他の列に一意のキーがあったかどうかによって、答えは異なりますか？もしそうなら、なぜですか？
いいえ、テーブルが3NFにあるかどうかを決定することは、それが持つ候補キーの数とは関係がないためです。代わりに、すべての非キー列がそれらの候補キーに完全に機能的に依存していることを保証することと関係があります。
しかし、これは興味深い点をもたらします。DBMSで制約として定義された一意のキーは、概念的なビジネスモデルでビジネスルールとして定義された一意の識別子と同じではないことに注意してください。おそらく私たちの世界では、常に個人のSSNを知っているため、個人のSSNが候補キーとして機能し、Person Idと呼ばれる論理スキーマに代理キーを導入することもできます。私たちのビジネスモデルには、SSNが私たちの世界の人の一意の識別子であることを示すルールが含まれています。これは機能的な依存関係を意味しますこのアイデンティティー属性のすべての記述属性の。このルールは、DBMSへの通知を忘れたか、通知しないことを選択したからといって変わりません。これがまさに、制約を宣言することが不可欠である理由です。これにより、DBMSは、格納されたデータがビジネスモデルのルールと一致することを保証できます。SSNにその一意の制約を作成しなかった場合、同じSSNを持つ同じ人物に対して複数の行を誤って作成する可能性があります。各行に異なる個人IDがあります！
これらのトピックの優れた入門書は、この答えが導き出された、Fabian PascalのPractical Database Foundation SeriesとChris DateのDatabase Design and Relational Theoryです。ファビアンの各論文は必読ですが、論文1（概念、論理、および物理レベルの違いを明確に定義）と論文4（さまざまな種類のキーを明確に定義）がこの質問に具体的に対処しています。同様に、Chrisの本全体は必読ですが、パートIIは機能の依存関係に関する正規化に専念するセクションです。