例を使用して2NFと3NFを説明する
第2正規形（2NF）に問題があり、Googleを使用して解決することができません。私は教師であり、生徒に間違ったものを教えたくないので、それは私を夢中にさせています。
5つのフィールドを持つテーブルがあるとします。
採点= {StudentName、SubjectCode、SubjectName、#Exam、Grade}
依存関係は次のとおりです。
StudentName、SubjectCode、＃Exam-> Grade
SubjectCode-> SubjectName
SubjectName-> SubjectCode
したがって、候補キー1は{StudentName、SubjectCode、#Exam}であり、候補キー2は{StudentName、SubjectName、#Exam}です。
素数の属性は{StudentName、SubjectCode、SubjectName、#Exam}であり、素数の属性はGradeです。
第2正規形の定義によれば、非素数属性は候補キーの一部に依存できません。唯一の非素数属性（Grade）は候補キーの一部に依存しないため、このテーブルは2NFのようです。
問題は、何かがおかしいと思うことです（そして私は間違っている可能性があります）。被験者は自分のテーブルを持つべきだと思います。
Gradings = {StudentName、Subject Code、#Exam、Grade}
件名= {件名コード、件名}
しかし、2NFはこれを生成しません。 3NFは非素数属性間の依存関係に関するものであるため、これも生成しません。しかし、冗長性がないため、これは正しい結果だと私には思われます。
非素数属性が「候補キーではない属性」として定義されている場合、2NFは望ましい結果を生成すると思います。しかし、私はこれを何度もチェックしましたが、非素数属性は「候補キーに属さない属性」として定義されています。
何が悪いのですか？
あなたが言うように、唯一の非素数属性はGradeであり、これはFDの右側にのみ表示されるため、関係は3NF（2NFだけではありません）にあります。
2つの小さなFDの左側はスーパーキーではないため、この関係はBCNFにはありません。
ただし、関係を（SubjectCode、SubjectName）および（StudentName、SubjectCode、#Exam、Grade）または（ StudentName、SubjectName、＃Exam、Grade）
この分解により、2つのBCNF関係が得られ、すべての機能依存関係が保持されます。これは常に可能であるとは限りません（常に3NFとの関係を分解できますが、必ずしもBCNFとは関係ありません）。
2NF
3NFではなく2NFの例が必要な場合は、関係に推移的な依存関係を含める必要があります。
たとえば、Score列があるとします。同じスコアのすべての試験の成績は同じでなければならないので、直感的にスコア->成績です（それ以外の場合はかなり不公平になります）が、複数のスコアが同じ成績（11％と12％たとえば、「失敗」の可能性があります）。
今あなたの関係は：
採点（StudentName、SubjectCode、SubjectName、＃Exam、Score、Grade）
また、別のGradingsレコードと同じスコアの結果を入力するたびに、対応するGradeを繰り返す必要があるため、新しい形式の冗長性があります。したがって、3NFに到達するには、次のように分解できます。
ScoreGrades（Score、Grade）
Scoreをキーとして、
スコア（StudentName、SubjectCode、SubjectName、＃Exam、Score）
あなたはあなたが言うすべてにおいて正しいです。件名コード、SubjectNameは、必要な依存関係を適用するために、独自のテーブルに移動する必要があります。これは、2NFと3NFが優れたデータベース設計を作成するのに十分でない理由の良い例です。代わりにBoyce Codd正規形（BCNF）が必要です。
2NFと3NFはBCNFに取って代わられました。BCNFは実際にはこれらのNFを廃止します*。 BCNFは、説明と適用がより重要であり、間違いなく単純です。教師として、BCNFに多くの時間を費やし、2NFと3NFにはあまり時間をかけないことをお勧めします。テーブルがBCNFの要件を満たしている場合は、2NFと3NFも満たしています。
* 3NFは、依存関係を維持する最も高い正規形ではありません。 Elementary Key Normal Form（EKNF）です。厳密に言えば、3NFを廃止するのはBCNFではなくEKNFですが、EKNFは不当に無視されており、ほとんどの教科書やコースでは言及されていません。同じことは、BCNFに合わせて設計し、必要なすべての依存関係とその他の整合性ルールを適切に実施できることを確認することです。そうでない場合は、設計を変更します。どのNFもデータの完全性に対する完全なソリューションではありませんが、BCNFは一般的に最も近く、説明と使用が最も簡単です。
唯一の非素数属性（Grade）は候補キーの一部に依存しないため、このテーブルは2NFのようです。
2NFにあります。
問題は、何かがおかしいと思うことです（そして私は間違っている可能性があります）。被験者は自分のテーブルを持つべきだと思います。
サブジェクトに独自のテーブルがあることを期待する理由はありません元のテーブルを2NFに分解する場合。 「すべき」という漠然とした概念を、特定の通常の形式が実際に提供するものと混同しています。
3NFは非素数属性間の依存関係に関するものであるため、これも生成しません。
「3NFは非素数属性間の依存関係に関するもの」は3NFの適切な定義ではないため、「3NFもこれを生成しない」というのは正しい結論ではありません。実際の定義を適用すると、テーブルが3NFにあることが示されますが、学生テーブルは必要ありません。しかし、繰り返しになりますが、そうなると期待する理由はありません。
しかし、冗長性がないため、これは正しい結果だと私には思われます。
繰り返しになりますが、「冗長性」はあいまいに曖昧であるため、「原因」と学生のテーブルの期待は不正確です。さまざまな正規形には、特定の種類のanomaliesがなく、関連する「冗長性」があります。しかし、正規化によって対処されない他の「冗長性」は残る可能性があります。
このテーブルにはCKの外にないFDがあるため、BCNFにはありません。 BCNFごとに分解すると、学生のテーブルが作成されます。 BCNFは、FDに付随するJD（結合依存関係）を処理するための最高の標準形式です。ただし、他のJDは問題が発生する可能性があり（つまり、「CKによって暗示される」ことはない）、5NFへの正規化によって削除する必要があります。
PS元のテーブルは、FD {StudentName、SubjectName、#Exam}-> Gradeも満たしています。
依存関係は次のとおりです。
これはどういう意味ですか？それは明確ではありません。
「これらはすべて、重要なFDです」という意味ですか？いいえ、4番目を意味するためです。 「これは保持するいくつかのFDです」？いいえ、それは推移閉包のFDがホールドすることを意味しますが、他のFDがホールドしているとは言いませんしないでくださいホールドしますが、CKを決定することができました。 「保持しているFDは、これらの推移的閉包にあるものとまったく同じです」？ meantである場合、shownである場合はknowのみとなります。つまり、そのクロージャーを（通常は、最小限/正規のカバー）、次に他のFDがないことを示します。しましたか？とにかく、あなたが書いたことはそれを意味するだけではありません。ですから、FDとCKの状況については、根拠がないと思います。
私が最初にこれをすべて学んでからどのくらい経ったかは言いません。しかし、私には、「機能依存」と「非素数属性」の適切な意味と他のすべての流行語を忠実に教えた後、特定の正常かどうかを確認するための一連の簡単な質問をしてくれた教授がいたことを覚えています形に達しました。ずっと前に覚えているか見てみましょう...
候補キーを特定したので、残りの非素数属性についてこの質問をします。この場合、グレードは1つだけです。
成績を一意に識別するために必要な最低限の情報は何ですか？受講者、科目、受験する試験を知る必要があります。これは候補キーの1つです。
編集： V V V
しかし、答えは学生の名前、科目の名前、試験だったかもしれません。これは2番目の候補キーと一致します。
SubjectCodeとSubjectNameが両方ともSubjectエンティティの候補キーであると仮定すると、これらの両方のフィールドをここに置く必要はありません。サブジェクトテーブルの行への1つの一意の参照で十分です。したがって、モデルの整合性を犠牲にすることなく、SubjectNameフィールドを安全に削除できます。
ただし、元の回答では、別のレベルの正規化を示すために、SubjectNameが候補キーで使用されたことを無視し、それを単なる別の素数属性と見なしました。これは役に立たないフィールドであることが私には明らかだったと思います。誰にとっても同じように明白だと思ったのですが、どちらかの方法でフィールドを削除したので、それは何の問題でしたか？
しかし、答えのその部分を削除する代わりに、比較のために残しておきます。
編集終了： ^ ^ ^
件名を一意に識別するために必要な最低限の情報は何ですか？
SubjectNameは、SubjectCode（候補キーのサブセット）にのみ依存しています。したがって、このタプルは2nfではありません。 SubjectCodeは、SubjectNameテーブルを配置する適切な場所になるように、Subjectテーブルの主キーにする必要があります。このタプルから削除すると、2nfになります。
属性の質問をし、答えが候補キーの全部または一部ではない場合、タプルは3nfにありません。しかし、質問をするフィールドが不足しているため、このタプルは3nf以降にも自明です。 ;）
注：「正規化」とは、論理エンティティに適用されるプロセスを指します。提供されたタプルは「グレード」と呼ばれるエンティティの定義であると思われるため、正規化できます。しかし、ある時点で、「このタプルは2nfにありません」と言っていましたが、「thisentityis not in 2nf。」ご迷惑をおかけして申し訳ございません。
正解です。被験者には独自のテーブルが必要です。候補キーの1つを選択すると、subject_codeまたはsubject_nameが非主候補キーになります。次に、主要ではない主題フィールドを成績表から削除します。
2つの一意の識別子があるサブジェクトに機能的に依存しています。これは、subject_codeとsubject_nameの間の推移的な依存関係によって示されます。これは、これらの2つのフィールドを含むテーブルを作成し、他のすべてのテーブルからこれらのフィールドの1つを削除する必要があることを示しています。この例では、何も表示されていませんが、このテーブルには追加の従属列が含まれている可能性があります。選択した第3正規形。
評点は、新しい評点表の他の3つのフィールド（候補キー）に依存します。上記のように、サブジェクトテーブルの候補フィールドの1つを選択する必要があります。通常、これらはより安定している傾向があるため、利用可能な場合はコード値になります。すべての非キーフィールドが主キーのフィールドに完全に依存しているため、結果のモデルは3nfになります。
問題（要件）をさらに分析すると、マークが適用されるセッションテーブルが生成される可能性があります。現在のモデルは、コースを繰り返す学生をカバーする可能性は低いです。これについては、後のレッスンで説明します。
同じ名前の複数の学生がいる可能性があるため、学生はおそらく別のテーブルになります。これは、合成主キー（学生番号？）を追加することで解決される可能性があります。
subjects ---> sessions ---+--> grades
students -----------------+