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番目の標準形式の定義によれば、非プライム属性は候補キーの一部に依存できません。唯一の非プライム属性（グレード）は候補キーの一部に依存しないため、この表は2NFにあるように見えます。

問題は、何かがおかしいと思うことです（そして、私は間違っているかもしれません）。被験者は自分のテーブルを持つべきだと思います。

成績= {生徒名、件名コード、＃試験、成績}

サブジェクト= {Subject Code、SubjectName}

しかし、2NFはこれを生成しません。3NFは非プライム属性間の依存関係に関するものであるため、これも生成しません。しかし、冗長性がないため、これは正しい結果であるように思えます。

非プライム属性が「候補キーではない属性」として定義されている場合、2NFが望ましい結果を生成すると思います。しかし、私はこれを何度もチェックしており、非プライム属性は「候補キーに一致しない属性」として定義されています。

私は何を間違えていますか？

リレーションは3NFにあります（2NFに限らず）。あなたが言うように、唯一の非プライム属性はGradeであり、これはFDの右側にのみ表示されます。

2つの小さなFDの左側はスーパーキーではないため、関係はBCNFにはありません。

ただし、（SubjectCode、SubjectName）と（StudentName、SubjectCode、＃Exam、Grade）または（StudentName、SubjectName、＃Exam、Grade）のいずれかの関係を損失なく分解することができます

この分解により、2つのBCNFリレーションが得られ、すべての機能的な依存関係が保持されます。これは常に可能というわけではありません（関係を3NFにいつでも分解できますが、必ずしもBCNFに分解できるわけではありません）。

2NF

3NFではなく2NFの例が必要な場合は、リレーションに推移的な依存関係を含める必要があります。

たとえば、スコア列があるとします。同じスコアのすべての試験は同じグレードを取得する必要があるため、直感的にスコア->グレード（ただし、そうでない場合はかなり不公平になります）が、複数のスコアが同じグレード（11％および12％たとえば、「失敗」になります）。

今、あなたの関係は：

成績（StudentName、SubjectCode、SubjectName、＃Exam、Score、Grade）

また、別のグレーディング記録と同じスコアの結果を入力するたびに、対応するグレードを繰り返す必要があるため、冗長性の新しい形式があります。したがって、3NFに到達するには、次のように分解できます。

ScoreGrades（スコア、グレード）

スコアをキーとして、および

スコア（StudentName、SubjectCode、SubjectName、＃Exam、Score）

あなたは言うことすべてにおいて正しい。Subject Code、SubjectNameは、必要な依存関係を適用するために独自のテーブルに移動する必要があります。これは、2NFと3NFが優れたデータベース設計を作成するには不十分な理由の良い例です。代わりに、Boyce Codd Normal Form（BCNF）が必要です。

2NFと3NFはBCNFに取って代わられ、実質的にはこれらのより低いNFを廃止します*。BCNFは、説明と適用がより重要であり、ほぼ間違いなく簡単です。教師として、BCNFに費やす時間を増やし、2NFと3NFに費やす時間を減らすことをお勧めします。テーブルがBCNFの要件を満たしている場合、2NFと3NFも同様に満たします。

* 3NFは、依存関係を保持する最高の標準形ではありません。基本キー標準形式（EKNF）です。厳密に言えば、3NFを廃止するのはBCNFではなくEKNFですが、EKNFは不当に無視されており、ほとんどの教科書やコースでは言及されていません。同じことは、BCNFに合わせて設計し、必要なすべての依存関係およびその他の整合性ルールを適切に実施できることを確認します。そうでない場合は、設計を変更します。NFはデータの完全性に対する完全なソリューションではありませんが、BCNFは一般的に最も近く、説明と使用が最も簡単です。

このすべてを最初に学んでからどれくらい経ったかは言いません。しかし、私は「機能的依存性」と「非プライム属性」の適切な意味と他のすべての流行語を忠実に教えた後、特定の正常かどうかを確認するための一連の簡単な質問を与えた教授がいたことを覚えていますフォームに到達しました。それをずっと思い出せるか見てみましょう...

候補キーを特定したので、残りの非プライム属性についてこの質問をします。この場合、グレードは1つだけです。

グレードを一意に識別するために必要な絶対最小情報は何ですか？受講者、科目、受験する試験を知る必要があります。これは候補キーの1つです。

編集： VVV

しかし、答えは、学生の名前、科目名、および試験である可能性があります。これは、2番目の候補キーと一致します。

SubjectCodeとSubjectNameが両方ともSubjectエンティティの候補キーであると仮定すると、ここにこれらのフィールドを両方持つ理由はありません。サブジェクトテーブルの行への一意の参照は1つで十分です。したがって、モデルの整合性を犠牲にすることなく、SubjectNameフィールドを完全に削除できます。

ただし、元の回答では、別のレベルの正規化を表示したいという要望で、SubjectNameが候補キーで使用されたことを無視し、それを別の非プライム属性と見なしました。これは役に立たない分野であることが私にはとても明白だったと思いますが、私はそれが誰にとっても同じように明白であると思ったのですが、どちらにしても私たちはこの分野を取り除いたので、それは何の問題でしたか？

しかし、答えのその部分を削除するのではなく、比較のために残しておきます。

編集の終了： ^ ^ ^

サブジェクト名を一意に識別するために最低限必要な情報は何ですか？

SubjectNameは、候補キーのサブセットであるSubjectCodeのみに依存しています。したがって、このタプルは2nfではありません。SubjectCodeは、SubjectNameを配置する適切な場所であるため、Subjectsテーブルの主キーである必要があります。このタプルから削除すると、現在2nfになっています。

属性の質問をし、回答が候補キーの全部または一部ではない場合、タプルは3nfにありません。しかし、このタプルは、質問をするためにフィールドを使い果たしたため、3nf以降でも簡単です。;）

注：「正規化」とは、論理エンティティに適用されるプロセスを指します。提供されたタプルは「グレード」と呼ばれるエンティティの定義であると思われるため、正規化できます。しかし、ある時点で「このタプルは2nfにありません」と言いましたが、これはもっと適切に「このエンティティは2nfにありません」でした。これにより混乱が生じた場合は謝罪します。

唯一の非プライム属性（グレード）は候補キーの一部に依存しないため、この表は2NFにあるように見えます。

2NFにあります。

問題は、何かがおかしいと思うことです（そして、私は間違っているかもしれません）。被験者は自分のテーブルを持つべきだと思います。

元のテーブルを2NFに分解するために、サブジェクトが独自のテーブルを持っていることを期待する理由はありません。あなたは、「あるべき」という漠然とした概念を、特定の標準形が実際に与えるものと混同しています。

3NFは非プライム属性間の依存関係に関するものであるため、これも生成しません。

「3NFは非プライム属性間の依存関係に関するもの」は3NFの適切な定義ではないため、「したがって、これも生成しない」というのは正しい結論ではありません。実際の定義を適用すると、テーブルが3NFにあり、学生テーブルは不要であることがわかります。しかし、再び、それがあると期待する理由はありません。

しかし、冗長性がないため、これは正しい結果であるように思えます。

繰り返しますが、「冗長性」は役に立たないあいまいなので、「原因」と学生テーブルの期待は不健全です。異なる通常のフォームには、特定の種類の異常や関連する「冗長性」がなく、影響を受けます。しかし、正規化によって対処されない他の「冗長性」は残る可能性があります。

このテーブルには、CKから外れていないFDがあるため、BCNFにはありません。BCNFごとに分解すると、学生テーブルが作成されます。BCNFは、FDに付随するJD（結合依存関係）を処理するための最高の標準形式です。ただし、他のJDは問題になる可能性があり（つまり、「CKに暗示されない」）、5NFへの正規化によって削除する必要があります。

PS元のテーブルは、FD {StudentName、SubjectName、#Exam}-> Gradeも満たします。

依存関係は次のとおりです。

これはどういう意味ですか？明確ではありません。

「これらはすべて、保持する重要なFDである」という意味ですか？いいえ、彼らは4番目を暗示しているからです。「ここにいくつかのFDがあります」？いいえ、手段が推移閉包保留中のFDが、それは他のものがあることは言っていないということはありません保持し、まだあなたはCKSを決定することができました。「保持するFDは、これらの推移的閉鎖のまさにFDです」。もしそれを意味するなら、あなたはそれを見せた場合にのみそれを知っているでしょう、すなわち、あなたはその閉鎖を見つけ（通常、最小限/標準的なカバーを通して）、そして他のFDがないことを示しなければなりません。あなたは？とにかく、あなたが書いたことはそれを意味するものではありません。ですから、FDとCKの状況についてしっかりと推論していないと思います。

あなたは正しい、被験者は独自のテーブルを必要とします。候補キーの1つを選択すると、いずれかsubject_codeまたはsubject_name非主要候補キーになります。次に、グレーディングテーブルから主要でないサブジェクトフィールドを削除します。

2つの一意の識別子を持つサブジェクトに機能的に依存しています。これはsubject_codeとの間の推移的な依存関係によって示されsubject_nameます。これは、これらの2つのフィールドを含むテーブルを作成し、これらのフィールドのいずれかを他のすべてのテーブルから削除する必要があることを示しています。この表には追加の依存列がありますが、この例には何も表示されません。3番目の標準形式で選択しました。

グレードは、新しいグレーディングテーブルの他の3つのフィールド（候補キー）に依存します。上記のように、サブジェクトテーブルの候補フィールドの1つを選択する必要があります。通常、これらはより安定している傾向があるため、利用可能な場合はコード値になります。すべての非キーフィールドは主キーのフィールドに完全に依存するため、結果のモデルは3nfになります。

問題（要件）をさらに分析すると、マークが適用されるセッションテーブルが得られる可能性があります。現在のモデルでは、コースを繰り返す学生をカバーすることはできません。これについては、後のレッスンで説明します。

また、同じ名前の複数の生徒を持つことができるため、生徒は別のテーブルになる可能性があります。これはおそらく、合成主キー（生徒番号？）を追加することで解決されます。

subjects --->  sessions ---+--> grades
students  -----------------+

間違っていると考えられるため、これを削除する準備をしています

サブジェクト名も非プライム属性であり、主キーサブジェクトコードの一部に依存します（規則を破る-主キーの列の部分的な依存関係があってはなりません）。

これは、第2正規形では禁止されているため、疑いのある独自のテーブルに配置する必要があります。

行き詰まったのは、2組の候補キーを識別することにあると思います。テーブルを作成するとき、1つの候補キーのセットを選択して主キーを作成する必要があります。残りの列は非プライム属性になります。つまり、2番目の候補キーを選択した場合、サブジェクトコードはプライマリキー（サブジェクト名）の一部に依存する非プライム属性になり、独自のテーブルに配置する必要があります。

第1、第2、および第3の正規形を相互に構築しながら順番に教えることが重要です。BCNFは基本的に第3正規形の拡張であるため、下位レベルを強く把握することが不可欠です。

さらに; 多くのルールが直感的になるため、経験豊富な開発者は独立したレベルの正規化を考慮しません。

また、特定の設計および最適化の問題を解決するために、いつ正規化ルールを破るかを知っています。正規化は、厳格なルールではなく、優れたデザインへのガイドとして扱われるべきです。それは、優れた指導ポイントでもあると思います。