それらの違いを理解するのに苦労しています。2NFは「鍵全体」であり、3NFは「鍵以外の何物でもない」と私たちは知っています。
Smasheryによるこの素晴らしい答えを参照してください:データベース設計における1NF、2NF、および3NFとは何ですか?
3NFに使用される例は、2NFとまったく同じです。つまり、1つのキー属性のみに依存するフィールドです。3NFの例は2NFの例とどのように異なりますか?
ありがとう
それらの違いを理解するのに苦労しています。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にない設計例は同じではありません。
はい、どちらの場合も依存関係は単一のフィールドにあります。
ただし、非 2NF の例では:
一方、非 3NF の例 (2NF にある):
どちらの場合も、正規化するために、更新の異常を示さない追加のテーブルを作成します (更新の異常の例: 2NF の例では、 を更新し、 を更新Coursename
しIT101|2009-2
ないとIT101|2009-1
どうなりますか? inconsistent=meaningless=unusable data になります)。
したがって、key 、 key 全体、および 2NF と 3NF の両方をカバーする key だけを覚えていれば、正規化するときに実際に機能するはずです。2NF と 3NF の違いは微妙に思えるかもしれません (追加の依存関係で、データが依存している属性が候補キーの一部であるかどうかについて質問します) - そして、まあ、そうです - そのまま受け入れてください。
2NFでは、非プライム属性を機能的に非プライム属性に依存させることができます
しかし
3NFでは、非プライム属性をスーパー キーのみに機能的に依存させることができます。
したがって、テーブルが 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 ではできなくなりました。
正規化とは、非複製、一貫性、そして別の観点から言えば、外部キーと JOIN に関するものです。
より正規化されているほど、データには適していますが、パフォーマンスや、複雑になりすぎた場合の理解には適していません。