はじめに
「アジャイルデータモデリング」を読み始めたが、そもそもER図や正規形の話をあまり理解していなかった。調査した結果を下記にまとめる。
■ 結論（まとめ）
正規化とは：データの重複や矛盾を防ぎ、安全なデータ更新ができる形に整えること
正規化を行う目的 ：
- データの重複（冗長性）をなくす
- データの矛盾を防ぐ（整合性維持）
- 更新や削除時の不具合を防ぐ
正規化の段階と内容：
- 1NF：カラムに複数の値を入れず、1セル＝1つの値とする
- 2NF：複合キーの一部だけに依存するカラムは切り出す
- 3NF：非キー同士で依存関係があるカラムは切り出す
現場での使い分け(アジャイルデータモデリングの話)：
- ビジネス実行（OLTPなど）：3NFまで整えるのが基本
- ビジネス評価（DW/BIなど）：意図的に「非正規化」するケースもある（スタースキーマ）
■ 正規化の目的
① データの重複（冗長性）の排除
同じ情報があちこちに重複して存在する状態をなくす
- データが無駄に膨れ上がるのを防ぐため
- 同じ情報を「すべて探して更新」する必要を防ぐため
【例】山田さんの住所が何度も入っていて「冗長」
| 注文ID | 顧客名 | 顧客住所 | 商品名 |
|---|---|---|---|
| 001 | 山田 | 東京都千代田区 | リンゴ |
| 002 | 山田 | 東京都千代田区 | バナナ |
② データの整合性（矛盾防止）の確保
矛盾したデータが発生しないようにする
- 1つの情報が複数箇所に存在すると矛盾が起きやすいため
【例】
| 顧客ID | 顧客名 | 顧客住所 |
|---|---|---|
| C01 | 山田 | 東京都千代田区 |
| C01 | 山田 | 東京都港区 ← どっちが正？ |
③ データ操作（更新・削除など）の安全性の向上
更新や削除時に意図しないデータ欠損や不整合が起きないようにする
- 関連データが密結合になっていると、誤って重要な情報まで削除してしまう可能性があるため
【例】「注文002」を削除 → 山田さんの顧客情報も消えてしまう危険
| 注文ID | 顧客名 | 顧客住所 | 商品名 |
|---|---|---|---|
| 001 | 田中 | 東京都渋谷区 | リンゴ |
| 002 | 山田 | 東京都千代田区 | バナナ |
■ 目的まとめ表
| 目的 | 簡単な言い換え |
|---|---|
| ① 重複排除 | データが「スリム」になる |
| ② 整合性確保 | データが「正しく一貫性を持つ」 |
| ③ 操作安全性向上 | データが「壊れにくくなる」 |
■ 正規化の段階（1NF〜3NF）
● 1NF（第1正規形）
カラムに複数の値を入れてはいけない
【NG例】
| 注文ID | 商品名 |
|---|---|
| 001 | リンゴ, バナナ |
【OK例】
| 注文ID | 商品名 |
|---|---|
| 001 | リンゴ |
| 001 | バナナ |
● 2NF（第2正規形）
複合キーの一部だけに依存するカラムは切り出す
【NG例】
| 注文ID（主キー） | 商品ID（主キー） | 商品名 | 注文日 |
|---|---|---|---|
| 001 | A01 | リンゴ | 2024-06-01 |
| 001 | A02 | バナナ | 2024-06-01 |
注文日 は「注文ID」にしか依存しており、商品ID には依存していない
【OK例】
複合キー（注文ID, 商品ID）の一部（注文ID）だけに依存するカラム（注文日） を「注文テーブル」に切り出した
注文テーブル
| 注文ID | 注文日 |
|---|---|
| 001 | 2024-06-01 |
注文詳細テーブル
| 注文ID | 商品ID | 商品名 |
|---|---|---|
| 001 | A01 | リンゴ |
| 001 | A02 | バナナ |
● 3NF（第3正規形）
非キー同士で依存関係があるカラムは切り出す
【NG例】
| 商品ID（主キー） | 商品名 | 商品カテゴリID | 商品カテゴリ名 |
|---|---|---|---|
| A01 | リンゴ | C01 | 果物 |
| A02 | バナナ | C01 | 果物 |
| A03 | キャベツ | C02 | 野菜 |
「商品カテゴリID → 商品カテゴリ名」 という依存関係が埋め込まれている
- 商品カテゴリ名が 商品カテゴリID から決まる情報 にも関わらず、行ごとに保持している
- カテゴリ名を変更したい時、全ての行を更新する必要 が出てしまう
【OK例】
「商品カテゴリID → 商品カテゴリ名」の依存関係 を別テーブルに切り出すことで変更や追加に強いテーブル構造 になる
商品カテゴリテーブル
| 商品カテゴリID | 商品カテゴリ名 |
|---|---|
| C01 | 果物 |
| C02 | 野菜 |
商品テーブル
| 商品ID | 商品名 | 商品カテゴリID |
|---|---|---|
| A01 | リンゴ | C01 |
| A02 | バナナ | C01 |
| A03 | キャベツ | C02 |
■ 正規化はどこまでやるべき？
- ビジネス実行（OLTPなど）は3NFまで整えるのが基本
- DW/BIは逆に「崩す」こともある（クエリのしやすさやパフォーマンス重視）