はじめに
前回の記事ではデータベース設計の3フェーズ（概念設計・論理設計・物理設計）について調べました。
今回は、論理設計で行われる正規化の前提となる概念である「関数従属」についてまとめます_φ(･_･
正規化とは
正規化とは、データを特定のテーブル構造に整理するデータベース設計プロセスです。
データの重複をなくし、データが常に正確で一貫した状態を保つことを目的としています。
正規化では「正規形」（第1正規形・第2正規形・第3正規形 など）と呼ばれる一連のルールに従ってテーブルを設計します。
正規形は 第1正規形 → 第2正規形 → 第3正規形 の順に段階的に適用され、各正規形は前の段階を満たした上で成り立ちます。
正規形のルールは、関数従属という概念をもとに定義されています。
（追記）正規化についてまとめました！
関数従属
関数従属とは、ある属性の値が決まると、別の属性の値も一意に決まる関係のことです。属性Aの値が決まれば属性Bの値も決まるとき、「BはAに関数従属する」といいます。
以下は、利用者IDと氏名を例にした関数従属の基本概念を示した図です。
図書館システムでは「利用者IDが決まれば氏名が一意に決まる」という関係があります。これを「氏名は利用者IDに関数従属する」と表現します。
依存関係の種類
IBM のドキュメントでは、属性間の機能的な依存関係の種類として「部分依存関係」「推移的依存関係」「複数値依存関係」「結合依存関係」が挙げられています。この記事では、正規化と特に深く関わる部分関数従属・推移的関数従属の2つを取り上げます。
部分関数従属
複合主キー（2つ以上の属性で構成される主キー）の一部の属性だけで、非キー属性の値が決まる関係です。
以下は、図書館システムの貸出テーブルを例に、部分関数従属と完全関数従属の違いを示した図です。
図書館システムの例として、以下のようなテーブルを考えます。
| 利用者ID | 本ID | 貸出日 | 本タイトル |
|---|---|---|---|
| U001 | B001 | 2024-01-10 | DB入門 |
| U002 | B001 | 2024-02-03 | DB入門 |
貸出日は利用者IDと本IDの両方が揃って初めて決まります。一方、本タイトルは本IDだけで一意に決まります。つまり本タイトルは複合主キーの一部にしか依存していないため、これが部分関数従属です。
第2正規形では、このような部分的な依存を解消する必要があります。
推移的関数従属
A→B かつ B→C という連鎖によって、A→C が間接的に成り立つ関係です。
以下は、貸出テーブルを例に、推移的関数従属の連鎖を示した図です。
図書館システムの例として、以下のようなテーブルを考えます。
| 貸出ID | 利用者ID | 氏名 | 貸出日 |
|---|---|---|---|
| L001 | U001 | 山田太郎 | 2024-01-10 |
| L002 | U002 | 鈴木花子 | 2024-02-03 |
貸出IDが決まると利用者IDが決まり、利用者IDが決まると氏名が決まります。つまり氏名は、主キーである貸出IDから直接ではなく、利用者IDを経由して間接的に決まっています。
このように、非キー属性（氏名）が別の非キー属性（利用者ID）に依存している状態が推移的関数従属です。第3正規形では、このような推移的な依存を解消する必要があります。
正規形との対応
これらの依存関係を解消することが、正規化の目的です。
| 解消すべき依存関係 | 達成される正規形 |
|---|---|
| 部分関数従属 | 第2正規形 |
| 推移的関数従属 | 第3正規形 |
✍️ 補足
第1正規形は「借りた本1」「借りた本2」「借りた本3」のように、同じ種類の情報を複数の列に分けて持っている状態をなくすことを目的としています。今回の記事で扱っている関数従属とは直接関係しません。
まとめ
部分関数従属
- 複合主キーの一部だけで非キー属性が決まる関係
- 第2正規形では、この部分的な依存を解消する必要がある
推移的関数従属
- 主キー → 非キー属性 → 別の非キー属性という連鎖が発生している関係
- 第3正規形では、この間接的な依存を解消する必要がある
参考