データベース（３）

# 正規化

データの整合性を保ち、冗長性や矛盾を防ぐためにテーブルを適切に分割・再構成する操作のこと。

##  用語

###   関数従属性（Functional Dependency, FD）
-   ある列（または列の組）が決まれば、他の列の値も一意に決まる関係。
-   記法：A → B（Aが決まればBが一意に決まる）
-   例）社員IDがわかれば、社員名がわかる「社員ID → 社員名」

###   無損失分解（Lossless Decomposition）
-   テーブルを複数に分解しても、情報を失わずに正確に元に戻せるようにする性質。
-   正規化後の複数テーブルは、主キー／外部キーによって結合可能で、元の情報を無損失で再構成できる。
-   前提: 正規化の過程では必ず無損失分解が行われるべき。
-   例）
    -   テーブル：#学生ID, 名前, 科目, 教員
    -   正規化後：
        -   #学生ID, 名前
        -   #学生ID, 科目, 教員

###   部分関数従属（Partial Dependency）
-   複合主キーの一部の属性にのみ依存している関数従属のこと。
-   つまり、ある列が主キーの一部に対して関数従属があることです。
-   「多対1関係」か「多対多関係」かによって、正規化後のテーブルが異なる。

    | 分類                    | 説明                          | 例                               | 正規化の影響                             |
    | --------------------- | --------------------------- | ------------------------------- | ---------------------------------- |
    | **多対1**（many-to-one）  | 一方（従属側）が他方（主側）にだけ依存している     | 社員 → 会社<br>社員ID, 会社ID, 会社名      | **部分関数従属**が発生しやすく、**2NFで会社名を分離**する |
    | **多対多**（many-to-many） | 両方が複数の関連を持つため、**中間テーブル**が必要 | 学生 ↔ 科目<br>学生ID, 科目ID, 学生名, 科目名 | 中間テーブルの設計で**部分従属が入り込みやすく、注意が必要**   |

-   排除対象：第2正規形（2NF）

-   例１）社員IDは会社内でユニークと仮定する
    -   テーブル：#会社ID, 会社名, #社員ID, 社員名
        -   #会社IDがわかれば、会社名がわかる「#会社ID → 会社名」
        -   #会社IDと#社員IDがわかれば、社員名がわかる「#会社ID, #社員ID → 社員名」
    -   正規化後：
        -   #会社ID, 会社名
        -   #会社ID, #社員ID, 社員名

-   例２）中間テーブルの利用
    -   テーブル：#学生ID, 学生名, #科目ID, 科目名
        -   学生IDがわかれば、学生名がわかる「#学生ID → 学生名」
        -   科目IDがわかれば、科目名がわかる「#科目ID → 科目名」
    -   正規化後：
        -   #学生ID, 学生名
        -   #科目ID, 科目名
        -   #学生ID, 科目ID


###   推移的関数従属（Transitive Dependency）
-   A → B → C のように、主キーを介さずに間接的に依存している関係。
-   排除対象：第3正規形（3NF）
-   例）
    -   テーブル：#社員ID, 部署名, 部署場所
        -   #社員ID がわかれば、部署名 がわかる
        -   部署名 がわかれば、部署場所 がわかる
        -   つまり、間接的に#社員ID がわかれば、 部署場所 がわかる
    -   正規化後：
        -   #社員ID, 部署名
        -   #部署名, 部署場所 


###   多値従属性（Multivalued Dependency, MVD）（≒ 多値依存）
-   主キーに対して、複数の独立した値のセットが存在する関係。
-   排除対象：第4正規形（4NF）
-   記法：A ⇉ B
-   例）著者が複数の電話番号と複数のメールアドレスを持つ
    -   テーブル：#著者ID, 著者名, 電話番号, メールアドレス
        -   1人の著者が複数の電話番号と複数のメールアドレスを持つ。
    -   正規化後：
        -   #著者ID, 著者名
        -   #著者ID, #電話番号
        -   #著者ID, #メールアドレス


###   結合従属性（Join Dependency, JD）（≒ 結合依存）
-   リレーションが複数のサブリレーションに分割されても、自然結合で元に戻せる必要があるという制約。
-   すべての結合従属性が候補キーに基づくとは限らない。
-   排除対象：第5正規形（5NF）
-   例）
    -   テーブル：#社員ID, #部署ID, #勤務地
        -   #社員ID, #部署ID
        -   #部署ID, #勤務地
        -   #社員ID, #勤務地
-   5NFは、すべての結合従属性を満たすことが必要。

##  目的
- データの重複を排除する
- 更新時の不整合を防ぐ
- 論理的な構造を持たせて保守しやすくする

##  操作内容
- テーブルの分割（分離）
- 正規化には段階があり、一般に以下のような形で進められる：

| 正規形名                    | 略称   | 内容・目的                                               |
| ----------------------- | ---- | --------------------------------------------------- |
| **第1正規形**               | 1NF  | ・繰り返し（複数値）を排除 <br>・すべての列が単一の値（原子値）で構成される     |
| **第2正規形**               | 2NF  | ・**部分関数従属**の排除（複合キーの一部にのみ依存する列を分離）                  |
| **第3正規形**               | 3NF  | ・**推移的関数従属**の排除（主キー以外の列を介した依存関係を解消）                 |
| **第3.5正規形（ボイス・コッド正規形）** | BCNF | ・主キー以外の決定子（関数従属の原因）も候補キーであることが必要            |
| **第4正規形**               | 4NF  | ・**多値依存**の排除（1つのキーに対して複数の独立した値がある場合を分離）             |
| **第5正規形**               | 5NF  | ・**結合依存**（Join Dependency）の排除（分割されたデータの再構成の正確性） |

- 実務では**第3正規形**まで正規化すれば十分なことが多い。
- **BCNF** 以降は、より複雑なデータ依存性に対処するための高度な正規化。
- 過度な正規化は性能低下や設計の複雑化を招く場合があるため、実用性とのバランスも重要。

##  第1正規形
-   一つのカラムに一つの値のみを持っている状態のこと。
    -   つまり、１つのセルには複数の値を持っていないということ(DBにおいてはセルとは言わないが)。


##  第2正規形



##  第3正規形



##  第3.5正規形



##  第4正規形



##  第5正規形




## 出典
- Microsoft Learn「データベースの正規化の基礎」 第３正規形までを解説している
    - [https://learn.microsoft.com/ja-jp/office/troubleshoot/access/database-normalization-description#normalizing-an-example-table](https://learn.microsoft.com/ja-jp/office/troubleshoot/access/database-normalization-description#normalizing-an-example-table) （アクセス日：2025年5月14日）

- Qiita「本当にあったやらかしDB設計シリーズ一覧」 設計についてのアンチパターン的なもの
    - [https://qiita.com/abcaaa/items/e63e5f7d6f628da11362](https://qiita.com/abcaaa/items/e63e5f7d6f628da11362) （アクセス日：2025年5月14日）

- BBH「【DB】第一正規形～第五正規形までを図解」 第５正規形までを解説している
    - [https://bbh.bz/2019/12/04/db-normalization-illustration/](https://bbh.bz/2019/12/04/db-normalization-illustration/) （アクセス日：2025年5月14日）

- Qiita「今更聞けないデータベースの正規化と正規形の種類についてまとめ」 
  - [https://qiita.com/matsushou/items/6083335c4af29d69c642](https://qiita.com/matsushou/items/6083335c4af29d69c642) （アクセス日：2025年5月14日）

- Qiita「DBを正規化するということ」 第３正規形までを解説している + 正規化と非正規化のトレードオフに関して言及している
  - [https://qiita.com/yukihirasawa1206/items/c2dedcc51c01c1bd8ccc](https://qiita.com/yukihirasawa1206/items/c2dedcc51c01c1bd8ccc) （アクセス日：2025年5月14日）