データベース設計において「正規化（Normalization）」とは、
データの重複や不整合を防ぎ、効率的で一貫性のあるデータ構造を作るための手法です。
正規化は段階的に行われ、主に次のような「正規形」に分けられます。
| 正規形 | 目的 | 主なポイント |
|---|---|---|
| 第1正規形（1NF） | 重複や繰り返しを排除 | すべての列が「単一値」になるようにする |
| 第2正規形（2NF） | 部分関数従属の排除 | 主キーの一部に依存する列を分離 |
| 第3正規形（3NF） | 推移的関数従属の排除 | 主キー以外の列に依存する列を分離 |
| 第4正規形（4NF） | 多値従属の排除 | 一つの主キーに複数の独立した値集合がある場合に分離 |
| 第5正規形（5NF） | 結合従属の排除 | 不要な結合を防ぐために細分化 |
第1正規形（1NF）：繰り返しの排除
ルール：
1つのセルには「1つの値」だけを格納する。
同じ種類のデータを複数列・複数行に持たない。
非正規化の例：
| 顧客ID | 顧客名 | 購入商品 |
|---|---|---|
| C001 | 田中太郎 | ノートPC, マウス |
| C002 | 鈴木花子 | スマートフォン |
この表では「購入商品」が**複数値を含む（カンマ区切り）**ため、1NFの条件を満たしていません。
第1正規形の例：
| 顧客ID | 顧客名 | 商品名 |
|---|---|---|
| C001 | 田中太郎 | ノートPC |
| C001 | 田中太郎 | マウス |
| C002 | 鈴木花子 | スマートフォン |
→ 商品を1件ずつ行として分け、**「原子性（atomicity）」**を満たしました。
第2正規形（2NF）：部分関数従属の排除
ルール：
主キーが複数列からなる場合、その一部にだけ依存する列を別テーブルに分ける。
第1正規形の例：
| 顧客ID | 商品ID | 顧客名 | 商品名 | 単価 |
|---|---|---|---|---|
| C001 | P001 | 田中太郎 | ノートPC | 100000 |
| C001 | P002 | 田中太郎 | マウス | 2000 |
この場合、主キーは（顧客ID, 商品ID）ですが、
「顧客名」は顧客IDにだけ依存しており、部分関数従属が存在します。
第2正規形の例（分割後）：
顧客マスタ
| 顧客ID | 顧客名 |
|---|---|
| C001 | 田中太郎 |
| C002 | 鈴木花子 |
商品マスタ
| 商品ID | 商品名 | 単価 |
|---|---|---|
| P001 | ノートPC | 100000 |
| P002 | マウス | 2000 |
購入履歴テーブル
| 顧客ID | 商品ID |
|---|---|
| C001 | P001 |
| C001 | P002 |
| C002 | P002 |
→ 主キーの一部にだけ依存する項目を分離し、データの重複を排除できました。
第3正規形（3NF）：推移的関数従属の排除
ルール：
主キー以外の列が、他の非キー列に依存してはいけない。
第2正規形の例：
| 商品ID | 商品名 | カテゴリID | カテゴリ名 |
|---|---|---|---|
| P001 | ノートPC | C01 | コンピュータ |
| P002 | マウス | C01 | コンピュータ |
| P003 | スマートフォン | C02 | モバイル |
この場合、「カテゴリ名」は「カテゴリID」に依存しており、
「商品ID → カテゴリID → カテゴリ名」という推移的従属が存在します。
第3正規形の例（分割後）：
商品マスタ
| 商品ID | 商品名 | カテゴリID |
|---|---|---|
| P001 | ノートPC | C01 |
| P002 | マウス | C01 |
| P003 | スマートフォン | C02 |
カテゴリマスタ
| カテゴリID | カテゴリ名 |
|---|---|
| C01 | コンピュータ |
| C02 | モバイル |
→ 「カテゴリ名」をカテゴリマスタに分けることで、冗長性を解消しました。
第4正規形（4NF）：多値従属の排除
概要：
1つの主キーに対して複数の独立した繰り返し属性を持つ場合、それらを分離します。
例：
ある顧客が「複数の購入商品」と「複数の連絡先」を持つ場合、
それらを1つのテーブルにまとめると組み合わせが膨大になります。
→ 「購入商品テーブル」と「連絡先テーブル」を分けて保持します。
第5正規形（5NF）：結合従属の排除
概要：
複数のテーブルを結合したときに情報の重複や欠損が起きないように細分化する段階です。
実際の業務システムでは第3正規形までで十分な場合が多く、
第4・5正規形はデータ分析や複雑な多対多関係を扱う設計で考慮されます。
まとめ
| 正規形 | 主な目的 | 設計上の効果 |
|---|---|---|
| 第1正規形 | 重複データの排除 | データを整理しやすくする |
| 第2正規形 | 部分従属の排除 | データの一貫性を高める |
| 第3正規形 | 推移的従属の排除 | 更新時の不整合を防ぐ |
| 第4正規形 | 多値従属の排除 | 無駄な組み合わせデータを防ぐ |
| 第5正規形 | 結合従属の排除 | 結合時の冗長性を防ぐ |
ポイントまとめ
- 実務では第3正規形までの正規化が標準的。
- ただし、過度な正規化はパフォーマンス低下を招く場合があるため、
必要に応じて「非正規化」も検討することが重要です。
Midjourneyプロンプト
Data being inserted into a database, digital data flow, glowing binary streams, futuristic interface, server room environment, precision, focused and technical mood, isometric composition, cool blue lighting, –no text::5 –ar 16:9 –q 2 –s 750
コメント