📌 結論から理解する
非正規化＝「性能のためにあえて正規化を崩す設計判断」
正規化されたテーブルは整合性が高い一方、検索時に多数のJOINが必要になりパフォーマンスが低下することがあります。
非正規化とは、意図的に冗長性を導入して検索性能を上げる設計判断です。
非正規化が有効な典型パターン
① 頻繁にJOINするテーブルの統合
注文テーブルに「顧客名」を冗長保持→毎回のJOINを不要にする
代償：顧客名更新時に2箇所修正が必要
代償：顧客名更新時に2箇所修正が必要
② 集計値の事前計算・保存
注文ヘッダに「合計金額」列を追加→毎回SUM計算不要
代償：明細追加・更新時に合計金額の更新処理が必要
代償：明細追加・更新時に合計金額の更新処理が必要
③ 履歴の固定化
注文時点の商品名・単価を注文明細にコピー保存
→ 商品情報が変わっても過去注文の記録が変わらない（これは論理的にも正しい設計）
→ 商品情報が変わっても過去注文の記録が変わらない（これは論理的にも正しい設計）
非正規化のトレードオフ
| 観点 | 正規化 | 非正規化 |
|---|---|---|
| データ整合性 | ✅ 高い | ❌ 管理が複雑 |
| 検索性能 | ⚠️ JOIN多い | ✅ 高速 |
| 更新性能 | ✅ 1箇所のみ | ❌ 複数箇所更新 |
| ストレージ使用量 | ✅ 少ない | ❌ 多い |
| 向いているDB | OLTP（更新重視） | DWH/分析（参照重視） |
試験では「なぜ非正規化するのか」→ 検索性能の向上。「非正規化のデメリット」→ 更新時に複数箇所の整合性維持が必要。DWH（データウェアハウス）はスタースキーマで意図的に非正規化する設計が標準です。
🧠 確認クイズ
Q1. 非正規化の主な目的はどれか？
Q2. 非正規化が特に有効なシステムはどれか？
Q3. 注文テーブルに「顧客名」を冗長に持つ設計のデメリットは何か？