DBMSの機能依存性とは？基本概念から種類・アームストロングの公理まで解説

機能依存性（Functional Dependency）とは

DBMSにおける機能依存性とは、その名の通り、テーブル内の属性同士が互いに依存し合う関係を指します。リレーショナルデータベースの提唱者であるE.F.コッド（E. F. Codd）によって導入されたこの概念は、データの冗長性を防ぎ、不良なテーブル設計を発見するための重要な手がかりとなります。

概念を正確に理解するために、属性AとBを持つ関係Rを考えてみましょう。機能依存性は「→（矢印）」で表現されます。

例えば、次のように記述した場合：

これは「BはAに関数的に依存している」ことを意味します。つまり、属性Aの値が決まれば、属性Bの値が一意に定まるという関係です。

具体例で理解する機能依存性

ここで、2つの属性を持つDepartment（部署）テーブルを例に挙げます。

• DeptId：部署ID
• DeptName：部署名

DeptIdは主キーであり、DeptNameの値を一意に識別します。部署名を知りたい場合、まず対応する部署IDが必要になるためです。

このように、DeptIdが決まればDeptNameが自動的に決まるため、両者の間には次のような機能依存性が成立します。

機能依存性の3つの種類

機能依存性には、主に以下の3つの形態があります。

• 自明な機能依存性（Trivial Functional Dependency）
• 非自明な機能依存性（Non-Trivial Functional Dependency）
• 完全非自明な機能依存性（Completely Non-Trivial Functional Dependency）

それぞれ順番に見ていきましょう。

1. 自明な機能依存性（Trivial Functional Dependency）

A → B において、BがAの部分集合である場合に成立する依存関係です。

例：

先ほどのDepartmentテーブルを使うと、DeptIdは {DeptId, DeptName} の部分集合であるため、以下は自明な機能依存性となります。

このような依存関係は常に成立するため、設計上特に新しい情報をもたらしません。

2. 非自明な機能依存性（Non-Trivial Functional Dependency）

A → B において、BがAの部分集合ではない場合に成立する依存関係です。

例：

DeptNameはDeptIdの部分集合ではないため、これは非自明な機能依存性です。実際のデータベース設計で問題となるのは、主にこの非自明な依存関係です。

3. 完全非自明な機能依存性（Completely Non-Trivial Functional Dependency）

A → B において、AとBの共通部分（積集合）が空である場合に成立する依存関係です。AとBがまったく重なり合わない、最も厳密な非自明な依存関係といえます。

アームストロングの公理（Armstrong's Axioms）

アームストロングの公理は、1974年にウィリアム・アームストロング（William Armstrong）によって提唱され、機能依存性について論理的に推論を行うための基本的な規則体系です。

以下の3つの規則が成り立ちます。

• 推移律（Transitivity）
  A → B かつ B → C が成り立つならば、A → C も成り立つ。いわゆる推移的な関係です。
• 反射律（Reflexivity）
  BがAの部分集合であるならば、A → B が成り立つ。
• 拡張律（Augmentation）
  A → B が成り立つならば、AC → BC も成り立つ。つまり、依存関係の両辺に同じ属性を追加しても依存関係は保たれます。

これらの公理を活用することで、既知の機能依存性から新たな機能依存性を導出でき、正規化などのデータベース設計を理論的に支えることができます。