はじめに

「アジャイルデータモデリング」を読み始めたが、そもそも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は逆に「崩す」こともある（クエリのしやすさやパフォーマンス重視）