正規化 — 引っ越し1件で2行直すはめになる前に
売上をExcelの1枚の表で管理していると、同じ顧客の住所が注文の数だけ何行も並びます。その顧客が引っ越したら？——全部の行を直して回ることになり、1行でも直し漏れると「どっちの住所が本当？」という事故（更新異常）が起きます。
原因は同じ情報の重複。表を適切に分けて重複をなくす手続きが正規化です。
更新異常はなぜ起き、第1〜第3正規形は何を順に排除していくのでしょうか。
「1つの事実は1か所に」——表を分けるだけで事故が消えます
解決は単純です——顧客の情報は顧客テーブルに1行だけ持ち、売上テーブルには顧客番号だけ書く。引っ越しは1か所直せば全部に効くようになります。この「1つの事実は1か所に」を段階的に徹底するのが正規化で、設計図の道具がER図——エンティティ（実体・長方形）、リレーションシップ（関係・ひし形）、アトリビュート（属性・楕円）で業務の構造を描きます。関係の多重度（カーディナリティ）は1:1・1:N・M:Nで、M:Nは間に関連テーブルを挟んで表現します。
2NFと3NFの違い——「主キーの一部」か「非キーの間」かです
3段階の中身です。第1正規形＝セルの中の繰り返しグループを排除し、1マス1値にする。第2正規形＝複合主キー（例：注文番号＋商品番号）の一部だけで決まる列（商品番号だけで決まる商品名など）を別表へ——部分関数従属の排除。第3正規形＝主キー以外の列から決まる列（顧客番号→顧客住所のように、非キー経由で芋づる式に決まる列）を別表へ——推移的関数従属の排除です。
従属の「出発点」で区別します——主キーの一部から決まってしまうのが部分関数従属（2NFで排除）、非キーの列を経由して決まるのが推移的関数従属（3NFで排除）。
2NFと3NFの「何を排除するか」の入れ替えが最頻出です
定番の誤り肢は排除対象の入れ替え——「第2正規形では推移的関数従属を排除する」（正しくは部分関数従属。推移的の排除は第3正規形）。順序を崩した「第3正規形にしてから第2正規形にする」も誤り——1NF→2NF→3NFの順は一方通行です。
ER図では記号の帰属（ひし形＝リレーションシップ、楕円＝アトリビュート）と、「M:Nはそのまま実装できる」という誤り（関連テーブルが必要）が的になります。
顧問先の「Excel台帳がぐちゃぐちゃ問題」は、正規化の考え方だけで大半が診断できます——顧客の連絡先が請求台帳にも納品台帳にも書いてあるなら、それは更新異常の予備軍。「マスタ（顧客・商品）と明細（取引）を分けましょう」という一言が、ITツール選定より先に効く処方箋です。販売管理システムの導入相談でも、この分離ができているデータは移行がスムーズに進みます。
冒頭の問いに答えます。更新異常は同じ事実の重複から起き、第1正規形で繰り返しを、第2正規形で部分関数従属（主キーの一部から決まる列）を、第3正規形で推移的関数従属（非キー経由で決まる列）を順に排除して「1つの事実は1か所に」を実現します（ER図＝長方形・ひし形・楕円、M:Nは関連テーブル）。次は、その整えた表に話しかける言葉——SQLとACIDへ。