データベース ⏱ 10分 重要度 ★★★★★ 頻出 ★★★★★

正規化

まず結論

正規化はデータの重複・矛盾を排除してデータベースを整理する手順です。第1→第2→第3正規形と段階的に進め、各段階で「関数従属」の問題を解消します。試験では正規化前後のテーブル変化が頻出です。

正規化の流れ

非正規形
繰り返しあり
繰り返し排除
→
第1正規形
1セル1値
部分従属排除
→
第2正規形
複合主キー注意
推移従属排除
→
第3正規形
完全分離
非正規→1NF→2NF→3NF と段階的に進める。試験では「どの正規形か」を判断させる問題が頻出。

正規化が必要な理由

非正規形の問題例（受注テーブル）
注文ID顧客ID顧客名商品ID商品名
001C01田中P01ペン
001C01田中P02ノート
002C02鈴木P01ペン
問題点：「田中」という名前が複数行に重複→田中を「田中さん」に変更するとき全行を変更必要。更新漏れ＝データの矛盾が発生！

第1正規形（1NF）：繰り返しグループの排除

非正規形（NG）

1つのセルに複数の値が入っている状態。
例：「商品ID：P01,P02,P03」

第1正規形（OK）

各セルに1つの値のみ。繰り返しグループを行に分割。
→ アトミック（原子的）な値のみ

第2正規形（2NF）：部分関数従属の排除

関数従属：AがBを一意に決定する関係（A→B）。例：顧客ID→顧客名（顧客IDが決まれば顧客名が決まる）
第1正規形（問題あり）

主キーが{注文ID, 商品ID}の複合キーのとき、「顧客名」は注文IDだけで決まる（部分関数従属）→ 問題！

第2正規形（解決）

部分関数従属を排除して別テーブルに分離。
・受注テーブル: 注文ID, 顧客ID, 商品ID
・顧客テーブル: 顧客ID, 顧客名

第3正規形（3NF）：推移的関数従属の排除

第2正規形（問題あり）

注文ID→顧客ID→顧客名 という推移的関数従属。顧客名が顧客IDを経由して注文IDに依存→ 問題！

第3正規形（解決）

推移的関数従属を排除。
・受注テーブル: 注文ID, 顧客ID
・顧客テーブル: 顧客ID, 顧客名
（顧客IDで直接顧客名を参照）

正規形排除するもの条件
第1正規形繰り返しグループ全属性がアトミック
第2正規形部分関数従属主キー全体→各属性（複合主キーのとき問題）
第3正規形推移的関数従属主キー以外の属性が他の非キー属性を決定しない

🎯 試験での出方

⚠️ よくある間違い

✍️ 確認クイズ

Q1. 正規化の主な目的はどれか。
✅ 正解は②。正規化の目的は更新異常（挿入異常・削除異常・更新異常）を排除し、データの整合性を保つこと。テーブルは増えるが重複と矛盾がなくなります。
Q2. 複合主キー{受注ID, 商品ID}のテーブルで「顧客名」が受注IDだけで決まる場合、これは何と呼ばれるか。
✅ 正解は②。主キーの一部（受注ID）だけで非キー属性（顧客名）が決まる場合を「部分関数従属」という。これを排除するのが第2正規化。
Q3. 「受注ID→顧客ID→顧客名」という従属関係（顧客名が顧客IDを経由して受注IDに依存）は何と呼ばれるか。
✅ 正解は②。A→B→Cという間接的な依存関係を推移的関数従属という。これを排除するのが第3正規化です。非キー属性が他の非キー属性を決定しないようにします。
Q4. 非正規形のテーブル（注文ID、顧客名、商品ID、商品名）を第3正規形まで正規化すると、通常何テーブルに分割されるか。
✅ 正解は②。（注文ID, 顧客ID, 商品ID）の受注テーブル、（顧客ID, 顧客名）の顧客テーブル、（商品ID, 商品名）の商品テーブルの3つに分割します。各テーブルはそれぞれの主キーで管理し、受注テーブルが顧客IDと商品IDを外部キーとして参照します。
Q5. 正規化を進めると性能が低下することがある。その理由として正しいものはどれか。
✅ 正解は②。正規化でテーブルを分割すると、データ取得時にJOIN（結合）が必要になります。JOINは処理コストが高く、特に大量データでは検索速度が低下することがあります。実務では意図的に非正規化（あえて重複を許容）してJOINを減らし、読み取り性能を優先する設計も行います。
← SQL結合（JOIN） 一覧 インデックス・ビュー →

Sponsor Link