正規化-2NFと3NF
それらの違いを見るのに苦労しています。 2NFは「鍵全体」であり、3NFは「鍵のみ」であると私たちは知っています。
Smasheryによるこの素晴らしい回答の参照： データベース設計における1NF、2NF、3NFとは
3NFに使用される例は、2NFとまったく同じです。これは、1つのキー属性のみに依存するフィールドです。 3NFの例は2NFの例とどのように異なりますか？
ありがとう
ある関係がA-> Bの形式の重要な機能依存関係を満たしていると仮定します。ここで、Bは素数属性です。
Aがスーパーキーではないが候補キーの適切なサブセットである場合、2NFに違反します。
Aがスーパーキーでない場合、3NFに違反します
3NF要件は2NF要件の特別なケース（ただし、それほど特別ではない）であることがわかりました。 2NF自体はそれほど重要ではありません。重要な問題は、Aがたまたま候補キーの一部であるかどうかではなく、Aがスーパーキーであるかどうかです。
既存の質問 の回答について非常に具体的な質問をするので、ここにその説明があります（基本的に、彼の回答ですでに述べたdportasのことを言いますが、もっと詳しく説明します）。
2NFにも3NFにもない設計の例は同じではありません。
はい、どちらの場合も、依存関係は1つのフィールドにあります。
ただし、2NF以外の例：
- 依存関係は主キーの部分にあります
一方、3NF以外の例（2NFにある）：
- 依存関係は、主キーの一部ではないフィールドに依存しています（また、この例では、が満たす2NF;これは、2NFをチェックした場合でも3NFもチェックする必要があることを示すためです）
どちらの場合も正規化するには、更新異常を示さない追加のテーブルを作成します（更新異常の例：2NFの例では、CoursenameをIT101|2009-2に更新し、IT101|2009-1に更新しないとどうなりますか？ =使用できないデータ）。
したがって、キーを記憶する場合、キー全体、および2NFと3NFの両方をカバーするキーのみを覚えておくと、正規化時に実際に機能するはずです。 2NFと3NFの区別はあなたには微妙に見えるかもしれません（追加の依存関係で、データが依存している属性が候補キーの一部であるかどうかの質問）。
2NFプライム以外の属性を機能的に非プライム属性に依存させることができます
だが
NFプライム以外の属性を機能的にスーパーキーのみに依存させる
したがって、テーブルが3NFにある場合、2NFにあり、3NFは2NFよりも厳密です。
お役に立てれば...
キーとそれに依存しない他の列の間に関係がない場合、3番目のNFを達成しました。
私の教授がこのように言ったとは思いませんが、これはそれが何であるかです。
あなたが「現場」にいるなら。定義を忘れてください。 「ベストプラクティス」を探してください。 1つはDRY：自分を繰り返さないでください。
この原則に従えば、NFに必要なものはすべて習得できます。
例を示します。テーブルには次のスキーマがあります。
PERSONS : id, name, age, car make, car model
年齢と名前は人のエントリ（=> id）に関連していますが、モデルは人ではなく車に依存します。
次に、それを2つのテーブルに分割します。
PERSONS : id, name, age, car_models_id (references CAR_MODELS.id)
CAR_MODELS : id, name, car_makes_id (references CAR_MAKES.id)
CAR_MAKES : id, name
2FNでの複製は可能ですが、3FNでの複製はできなくなりました。
正規化とは、すべて非複製、一貫性に関するものであり、別の観点からは外部キーと結合です。
より正規化されたものほど、データには優れていますが、パフォーマンスや、本当に複雑すぎるかどうかの理解には適していません。
2NFは部分的な依存関係に従いますが、3NFは推移的な機能依存関係に従います。 3NFは2NFにあり、推移的な機能依存をサポートする必要があることを理解することが重要です。