正規化は、3種類の更新異常をどのように修正しますか？
データベースの正規化を理解するために、ConnollyとBeggによる「データベースシステム：設計、実装、管理への実用的なアプローチ」を読んでいます（第14章）。これで、3つのデータベース正規化形式をよく理解できました。
- 第1正規形（1NF）
- 第2正規形（2NF）
- 第3正規形（3NF）
また、3つの更新異常についても理解しています。
- 挿入異常
- 削除異常
- 更新/変更の異常
私が今理解するのに苦労しているのは、この2つをどのようにリンクするかです。たとえば、挿入異常を修正するのに役立つフォームはどれですか？他の異常についても同様です。 2つのグループ間のマッピング関係と、それらのフォームが特定の異常を修正する理由を知りたいのですが。
これが私の最初の質問です。Googleとこのサイトで検索して、最初に答えを見つけようとしましたが、役に立ちませんでした。
ありがとうございました。
1NFは基本的に「1つの列に多くのデータを保持しないでください」なので、2NFと3NFは、3つのデータベースの異常すべての主要な修正であると思います。
挿入異常：「class」と「student」の両方のデータを含む大きな
enrollmentテーブルが1つある場合（どちらも他に存在しない） ）、少なくとも1人の対応する学生がいないと、新しい（空の）コースに入ることができません（テーブルが登録の記録であるため）。したがって、2NFを適用し、classes、studentsに個別のテーブルを作成し、元のenrollmentテーブルをClassIDとStudentIDの両方にリンクします。これで、学生のいない新しいクラス、およびクラスのない新しい学生を入力できます。削除異常：元の
enrollmentテーブルの各行に学生の完全な詳細と完全な詳細が含まれている場合、上記と同じ彼らが登録されているクラス、次にクラスに最後に登録された学生を削除すると、そのクラスに関する最後の情報が削除されます。解決策は同じです。2NFを適用して個別のテーブルを作成し、クラス情報を失うことなく学生を登録または登録解除できるようにします。異常の更新：上記と同じ、単一テーブルの方法を使用して、複数の学生が登録されているクラスの情報（たとえば、部屋番号）を更新すると、一部の行が新しい情報で、他の行が古い情報である状況に。上記のように2NFを適用することも解決策であり、クラスデータは1か所（
classesテーブル）でのみ変更されます。
1NFはまだプロセスでsomeの役割を果たしていることに注意してください。これは、登録済み学生のリスト全体を単一のフィールドに詰め込むことによって問題を解決したり、追加したりできないためです。 student1、student2、student3フィールドまたはそのようなもの。
2NFではなく3NFである同様の例を考え出すことができます。各 "学生"に教員顧問がいる場合（および一部の顧問は複数の学生に割り当てられている場合）、それは私たちの学生テーブルのキーの一部ではない可能性があります、しかしそれは「依存属性」であり、上記と同じ問題のいくつかを引き起こす可能性があります。したがって、教員顧問は独自のテーブルに分割することができます。
参考になったいくつかのリソース：
私が学んだ例を思いつきます。 1Nfはすべて、繰り返しグループを異なるテーブルに分離することであり、そのすべての属性はアトミックである必要があります。
次の属性を含むテーブルがあるとします。 Purchase_order_No、Purchase_date、Emp_code、Supplier_Name、Supplier_No、Part_No Part_description、Part_Quantity
1NF：ここでは、1つの注文書内で複数の部品を注文する場合があるため、関連する同じデータが繰り返されます。そのため、part_no、part_description、part_quantityを分離し、part_no、purchase_order_noを主キーにすることができます。ここに異常があります。
- 異常を挿入：現在2つのテーブルがあるため。購入していない部品は挿入できません。
- 異常の削除：特定のパーツの単一の購入があり、その注文が削除された場合、テーブルにそのパーツはまったくありません。
- 異常の更新：特定の部品の説明を変更するには、購入したすべての場所で更新する必要があります。
2NF：テーブルが2番目の形式になるには、すべての属性がその主キーに完全に依存している必要があります。たとえば、部品番号と発注書を知る必要がある部品の数量を知るために。しかし、部品の説明では、部品番号だけで十分なので、表に分けます。サプライヤー名はdではありません
- 異常を挿入：注文のないサプライヤーを挿入しなければならなかった場合、それは不可能です。
- 異常の削除：サプライヤーの最後の単一注文を削除すると、サプライヤーのデータも失われます。
- 異常の更新：サプライヤを更新するには、サプライヤのすべての注文書で更新する必要があります。
3Nf：テーブルが3NFになるためには、別の非キー属性にも依存する属性があってはなりません。ここには、sup-noにも依存するサプライヤー名があるので、それらを別のテーブルに入れます。ここで、sup_noは主キーです。
これで、テーブルをさらに分解することはできなくなりますが、異常が存在し続ける可能性があります。完全に正規化されたデータテーブルを作成することはできません。これであなたが晴れることを願っています。