正規化とは？ — 基本の概念
正規化（Normalization／データベース正規化） とは、リレーショナルデータベース（関係データベース）において「データの重複や冗長性を抑え、一貫性と整合性を保ちやすい構造に整理するプロセス」を指します。
正規化を行うことで、更新ミス、矛盾、冗長なデータ保持コスト などの問題を防ぎやすくなります。
正規化は、テーブルを「正規形（normal form）」と呼ばれる形式に従って整理していく作業です。
補足：正規化は、Excel やスプレッドシートで「データを整理する操作（表分割、列分割など）」を行う感覚にも近いです。ただし、データベース設計では理論的なルール（正規形）に基づいて行われます。
正規化の目的・メリット・注意点
正規化を行う目的
主な目的は次の通りです。
- データの冗長性を排除する
同じ情報が複数行・複数テーブルに繰り返し存在しないようにします。 - データの矛盾（不整合）を防ぐ
一方を更新して他方を忘れることで、情報がズレるのを防ぎます。 - 更新の効率化・保守性向上
情報変更時に修正すべき場所を限定できます。 - データ構造の拡張性・柔軟性を高める
新しい属性・テーブルを追加しやすくします。 - 異常（更新・挿入・削除異常）を抑える
特定の操作ができない（登録できない、削除で他のデータが消える等）事態を回避します。
メリット
注意点・デメリット
正規形（normal form）の概要と第一〜第三正規形
正規化にはいくつかの段階（正規形）があり、一般的には第1正規形〜第3正規形を実現できれば十分な設計とされることが多いです。
以下、各正規形の意味とポイントを簡単に解説します。
| 正規形 | 主なルール | 主な目的 / 検証すべき依存関係 | 注意点 |
|---|---|---|---|
| 第1正規形（1NF） | 各列（属性）の値が原子性（分割できない単位）を持つこと。繰り返しの項目を許さない。 | 繰り返し属性・複数値属性を排除 | これを満たしていないと構造が曖昧で扱いにくい |
| 第2正規形（2NF） | 主キーが複合キーの場合、非キー属性が部分的に従属していないこと（部分関数従属性の排除） | 複合主キーを構成する一部キーによって非キー属性が決まる構造を分割 | 主キーが単一属性なら、通常自動的に満たされる |
| 第3正規形（3NF） | 非キー属性間での推移的関数従属性を排除（非キー属性が他の非キー属性を決定しない） | 主キー ← 非キー ← 別の非キー という関係を避ける | 非キー属性間の依存関係に注意 |
| ボイス・コッド正規形（BCNF） | より強い形式。任意の関数従属性 A → B に対して、A が必ず候補キーでなければならない | 2NF/3NF でも解消できないさらなる異常を排除 | 実務では BCNF を採る設計はコストとトレードオフを考慮すること |
| 第4正規形／第5正規形など | 複雑な多値依存、結合従属性などを排除 | 一般的な業務用途ではあまり使われないケースも多い | 高度設計時の選択肢として理解しておくとよい |
具体例での流れ（簡易な例）
以下は簡単な例を通じて、第1 → 第2 → 第3 正規化のイメージを掴む例です。
非正規形（raw / 非正規形状態）
| 受注ID | 顧客名 | 顧客住所 | 商品A | 商品B | 商品C | 単価A | 単価B | 単価C |
|---|---|---|---|---|---|---|---|---|
| 001 | 田中 | 東京都 | 本 | ペン | なし | 1,000 | 200 | — |
| 002 | 鈴木 | 大阪府 | ノート | なし | ボールペン | 500 | — | 150 |
このように「複数の商品列を持つ」「繰り返し項目」が混在すると扱いにくいです。
第1正規形（繰り返し除去）
| 受注ID | 顧客名 | 顧客住所 | 商品 | 単価 |
|---|---|---|---|---|
| 001 | 田中 | 東京都 | 本 | 1,000 |
| 001 | 田中 | 東京都 | ペン | 200 |
| 002 | 鈴木 | 大阪府 | ノート | 500 |
| 002 | 鈴木 | 大阪府 | ボールペン | 150 |
各商品の明細を別行にし、繰り返しを除去します。
第2正規形（部分従属性排除）
上記で、主キーが（受注ID + 商品）であったとすると、「顧客名／住所」は受注ID のみで決まる非キー属性です。
そのため「顧客情報」は別テーブルに分割します。
- 受注テーブル
| 受注ID | 顧客ID | 商品 | 単価 |
|---|---|---|---|
| 001 | C01 | 本 | 1,000 |
| 001 | C01 | ペン | 200 |
| 002 | C02 | ノート | 500 |
| 002 | C02 | ボールペン | 150 |
- 顧客テーブル
| 顧客ID | 顧客名 | 顧客住所 |
|---|---|---|
| C01 | 田中 | 東京都 |
| C02 | 鈴木 | 大阪府 |
これで、顧客情報は重複せず、部分従属性を排除しました。
第3正規形（推移的従属性の排除）
さらに、仮に「顧客住所（非キー属性） → 都道府県コード（非キー属性） → 地域名（非キー属性）」など、非キー属性同士の依存関係があれば、これも切り分けて分割します。
正規化 vs 非正規化
正規化をすべて追求するのが理想ですが、実務では必ずしも正規化だけを採るわけではありません。
非正規化（Denormalization）
意図的に冗長性を持たせ、読み取り性能を重視する設計
→ 特に分析系クエリ・集計処理で JOIN を多用すると遅くなる場合、あえて一部の正規化を犠牲にすることがあります。
→ ただし、非正規化を行う部分は管理・更新の複雑性リスクを理解した上で行う必要があります。
実務では「3NF レベル／BCNF レベルまで整理して、あとは非正規化を織り交ぜて性能を確保する」ようなバランスを取る場合が多いです。
実務での運用と工夫
まとめ
正規化は、データ冗長性・矛盾を抑えて、整合性を保ちつつ扱いやすい構造に整理する手法です。
第1正規形〜第3正規形を意識して設計すれば、多くの業務用途で十分な構造になります。
ただし、パフォーマンスやクエリ特性を考慮して、非正規化を併用する判断も必要です。
正規化は理論だけでなく、実際のアクセス特性・運用コストなども見ながら設計するのが最善です。
