～現場で失敗しないための実践設計ガイド～
■ はじめに
Oracleデータベースの設計において、「正規化」と「非正規化」は必ず検討すべきテーマです。
- 「正規化しすぎてSQLが書きづらい…」
- 「非正規化したらデータが矛盾していた…」
このような失敗を避けるためには、両者の違いを正しく理解し、設計目的に応じて使い分けることが重要です。
この記事では、正規化と非正規化の違い・メリット・デメリット・判断基準をテキスト図でわかりやすく解説します。
リンク
リンク
リンク
■ 正規化とは？
“”正規化（Normalization）””とは、
データの重複を排除し、意味ごとにテーブルを分割することで、整合性と保守性を高める設計手法です。
📘 正規化の前後のイメージ
【正規化前】
members（会員情報）
┌────────┬──────┬──────────────┐
│ member_id │ name │ address │
├────────┼──────┼──────────────┤
│ 1 │ 山田 │ 東京都渋谷区〇〇1-2 │
│ 2 │ 鈴木 │ 東京都渋谷区〇〇1-2 │ ← 重複
└────────┴──────┴──────────────┘
↓
【正規化後】
members（会員情報）
┌────────┬──────┬────────┐
│ member_id │ name │ address_id │
├────────┼──────┼────────┤
│ 1 │ 山田 │ A001 │
│ 2 │ 鈴木 │ A001 │
└────────┴──────┴────────┘
addresses（住所マスタ）
┌────────┬────────────────────┐
│ address_id │ address │
├────────┼────────────────────┤
│ A001 │ 東京都渋谷区〇〇1-2 │
└────────┴────────────────────┘
■ 正規化のメリット
- ✅ データの一貫性が保てる
→ 住所の変更があっても1箇所直すだけでOK。 - ✅ データ構造が明確になる
→ 再利用やマスタ化が容易。 - ✅ 更新時のミスが減る
→ 複数箇所の更新忘れが起こらない。
■ 正規化のデメリット
- ❌ SQLが複雑になる
→ JOINが必須になり、可読性が落ちる。 - ❌ 性能劣化の可能性
→ JOINによるI/O増加、応答速度の低下。 - ❌ 開発・設計が重くなることも
→ データ構造が理解しづらくなり、属人化のリスク。
■ 非正規化とは？
“非正規化（Denormalization）”とは、
あえて正規化のルールを緩めて、読み取り性能や実装の簡素化を重視した設計手法です。
📘 非正規化のイメージ
members（非正規化）
┌────────┬──────┬──────────────┐
│ member_id │ name │ address │
├────────┼──────┼──────────────┤
│ 1 │ 山田 │ 東京都渋谷区〇〇1-2 │
│ 2 │ 鈴木 │ 東京都渋谷区〇〇1-2 │ ← 重複してもOK
└────────┴──────┴──────────────┘
■ 非正規化のメリット
- ✅ SQLがシンプル
→ JOINが不要。直感的で速いクエリが書ける。 - ✅ 読み取り性能が向上
→ 特に検索主体のアプリケーションで効果大。 - ✅ 画面やレポート向けに最適
→ 画面用に加工済みデータを即取得可能。
■ 非正規化のデメリット
- ❌ データの整合性が崩れやすい
→ 同じ情報が複数箇所に存在。更新忘れのリスク。 - ❌ 冗長なデータで容量を圧迫
→ ストレージ非効率。 - ❌ マスタ連携や再利用がしづらい
→ データ構造が固定されている。
■ 正規化と非正規化の使い分け：判断基準
| 観点 | 正規化すべき場合 | 非正規化すべき場合 |
|---|---|---|
| 更新頻度が高い | ✅ 複数箇所の整合性を保ちたい | ❌ 更新漏れが発生しやすい |
| 読み取りが主な用途 | ❌ JOINによるパフォーマンス低下の恐れ | ✅ 高速にデータを取得できる |
| 開発の簡素さ | ❌ SQLが複雑化しがち | ✅ シンプルで開発しやすい |
| データ品質が重要 | ✅ データの一貫性が求められる | ❌ 不整合の発生リスクがある |
| 再利用・マスタ化したい | ✅ 同じ情報を複数テーブルで利用したい | ❌ 重複データのまま使うことになる |
■ Oracle実装の具体例
🔹 正規化モデル（JOINあり）
SELECT m.name, a.address
FROM members m
JOIN addresses a
ON m.address_id = a.address_id;
- 保守性に優れるが、JOINの影響あり。
🔹 非正規化モデル（JOINなし）
SELECT name, address
FROM members
WHERE address LIKE '東京都%';
- SQLはシンプル。データの整合性は別途ロジックで管理が必要。
■ 実務でのベストプラクティス
- ✅ 設計段階では原則として正規化を行う
→ 長期的に保守しやすく、チーム開発でのトラブルを減らせる。 - ✅ 非正規化は“目的を持って”行う
→ パフォーマンス要件や画面仕様が明確なときに限定。 - ✅ ビューやマテリアライズドビューの活用
→ 正規化構造を保ったまま、非正規化ビューで見せる工夫も有効。
■ 補足：テキスト図で振り返る「違いのまとめ」
┌──────────────┬────────────┬────────────┐
│ 比較項目 │ 正規化 │ 非正規化 │
├──────────────┼────────────┼────────────┤
│ データ整合性 │ 高い（更新もれ防止） │ 低い（複数個所修正） │
│ SQLの書きやすさ │ 複雑（JOIN必要） │ 簡単（1テーブル） │
│ 読み取り性能 │ 条件により低下 │ 高速 │
│ データ再利用 │ マスタ管理しやすい │ 再利用しにくい │
│ 保守性 │ 高い（変更に強い） │ 低い（不整合の恐れ） │
└──────────────┴────────────┴────────────┘
■ まとめ
| ポイント | 解説 |
|---|---|
| ✅ 正規化 | 保守性・整合性を重視するなら基本形。JOIN前提で設計する。 |
| ✅ 非正規化 | 高速処理・単純表示が目的なら必要に応じて導入。意図を明確にすること。 |
| ✅ バランスが大事 | 「設計原則」と「現場要件」の両方を踏まえて判断する。 |
| ✅ VIEW活用 | 正規化データに対して非正規化ビューを提供することで、両者の長所を両立できる。 |
[参考]
Oracle Database データベース開発ガイド 19c
コメント