DBMSにおける依存関係の種類を徹底解説!5つの従属性を具体例で理解する
DBMS(データベース管理システム)における依存関係(従属性)とは、2つ以上の属性間に存在する関係のことを指します。データベース設計や正規化を理解するうえで、この依存関係の概念は非常に重要です。
DBMSにおける依存関係には、主に以下の5つの種類があります。
- 関数従属(Functional Dependency)
- 完全関数従属(Fully-Functional Dependency)
- 推移従属(Transitive Dependency)
- 多値従属(Multivalued Dependency)
- 部分従属(Partial Dependency)
それでは、それぞれの依存関係について順番に見ていきましょう。
関数従属(Functional Dependency)とは
テーブルに格納されたある情報が、同じテーブル内の別の情報を一意に決定できる場合、この関係を「関数従属」と呼びます。これは、同じリレーション内の2つの属性間の関連付けと考えることができます。
属性Pが属性Qを関数的に決定する場合、次のように表現します。
P → Q
関数従属の具体例
以下の従業員テーブルを見てください。
<Employee>
| EmpID | EmpName | EmpAge |
| E01 | Amit | 28 |
| E02 | Rohit | 31 |
このテーブルでは、EmpName(従業員名)はEmpID(従業員ID)に関数従属しています。なぜなら、特定のEmpIDの値に対して、EmpNameが取りうる値は必ず1つに定まるからです。
EmpID → EmpName
つまり、従業員IDがわかれば、その従業員の名前は一意に特定できる、という関係が成り立っています。
完全関数従属(Fully-Functional Dependency)とは
ある属性が別の属性に完全関数従属しているとは、その属性全体に関数従属しており、かつその属性のいかなる真部分集合にも従属していない状態を指します。
例えば、属性Qが属性Pに完全関数従属しているのは、QがPに関数従属し、かつPの部分集合のいずれにも従属していない場合です。
完全関数従属の具体例
以下の2つのテーブルを見てください。
<ProjectCost>
| ProjectID | ProjectCost |
| 001 | 1000 |
| 002 | 5000 |
<EmployeeProject>
| EmpID | ProjectID | Days(プロジェクトに費やした日数) |
| E099 | 001 | 320 |
| E056 | 002 | 190 |
このリレーションでは、次の関係が成り立っているように見えます。
EmpID, ProjectID, ProjectCost → Days
しかし、これは完全関数従属ではありません。なぜなら、部分集合{EmpID, ProjectID}だけでも、従業員がそのプロジェクトに費やした日数{Days}を容易に決定できるからです。ProjectCostは不要なのです。
したがって、真の完全関数従属は次のように表されます。
{EmpID, ProjectID} → Days
推移従属(Transitive Dependency)とは
間接的な関係によって関数従属が生じる場合、これを「推移従属」と呼びます。
P → Q かつ Q → R が成り立つ場合、P → R という関係は推移従属となります。つまり、属性Pから直接Rを決定しているのではなく、属性Qを経由して間接的に決定される関係です。
推移従属は第3正規形(3NF)で排除されるべき従属性であり、データの冗長性や更新時の不整合を引き起こす原因となります。
多値従属(Multivalued Dependency)とは
テーブル内のある行(または行の集合)の存在が、同じテーブル内の他の行の存在を必然的に意味する場合に、多値従属が発生します。
テーブルが属性P、Q、Rを持つ場合、QとRはPに対する多値の事実となります。
多値従属は二重矢印(→→)で表現されます。
P →→ Q
Q →→ R
この場合、多値従属が成立するのは、QとRが互いに独立した属性である場合のみである点に注意が必要です。QとRの間に関係性がある場合は、多値従属とはみなされません。
多値従属は、第4正規形(4NF)で解消される対象となります。
部分従属(Partial Dependency)とは
部分従属は、非主属性(プライムでない属性)が、候補キーの一部のみに関数従属している場合に発生します。
部分従属は第2正規形(2NF)によって排除されます。
部分従属の具体例
以下の学生プロジェクトテーブルを見てください。
<StudentProject>
| StudentID | ProjectNo | StudentName | ProjectName |
| S01 | 199 | Katie | Geo Location |
| S02 | 120 | Ollie | Cluster Exploration |
このテーブルには部分従属が存在します。どのように確認するか見ていきましょう。
このテーブルの主キー属性は、StudentIDとProjectNoの複合キーです。
前述のとおり、非主属性であるStudentNameとProjectNameが候補キーの一部のみに関数従属している場合、そのリレーションは部分従属となります。
- StudentNameは、複合キーの一部であるStudentIDだけで決定できるため、部分従属が発生しています。
- 同様に、ProjectNameもProjectNoだけで決定できるため、こちらも部分従属となっています。
このような場合、テーブルを分割して第2正規形(2NF)に正規化することで、データの冗長性を排除し、整合性の高いデータベース設計を実現できます。
まとめ
DBMSの依存関係は、データベースの正規化を行ううえで欠かせない基礎概念です。
- 関数従属:ある属性が別の属性を一意に決定する関係
- 完全関数従属:属性全体に従属し、部分集合には従属しない関係
- 推移従属:間接的な関係を通じて生じる関数従属(3NFで排除)
- 多値従属:ある行の存在が他の行の存在を意味する関係(4NFで排除)
- 部分従属:非主属性が候補キーの一部に従属する関係(2NFで排除)
これらの依存関係を正しく理解することで、冗長性のない効率的なデータベース設計が可能になります。
-
DBMSの機能依存性とは?基本概念から種類・アームストロングの公理まで解説
機能依存性(Functional Dependency)とはDBMSにおける機能依存性とは、その名の通り、テーブル内の属性同士が互いに依存し合う関係を指します。リレーショナルデータベースの提唱者であるE.F.コッド(E. F. Codd)によって導入されたこの概念は、データの冗長性を防ぎ、不良なテーブル設計を発見するための重要な手がかりとなります。概念を正確に理解するために、属性AとBを持つ関係Rを考えてみましょう。機能依存性は「→(矢印)」で表現されます。例えば、次のように記述した場合:A → Bこれは「BはAに関数的に依存している」ことを意味します。つまり、属性Aの値が決まれば、属性Bの値
-
DBMSのデッドロックとは?発生条件と対策手法をわかりやすく解説
デッドロックとはデッドロックとは、2つ以上のプロセスが、それぞれ実行の完了に必要なリソースを相手側が保持しており、互いに待ち続けてしまう状態を指します。上記の図では、プロセス1がリソース1を保持しており、リソース2を必要としています。同様に、プロセス2はリソース2を保持し、リソース1を必要としています。どちらのプロセスも相手の持つリソースがなければ処理を完了できないにもかかわらず、自分のリソースを手放そうとしないため、プロセス1とプロセス2はデッドロック状態に陥ります。コフマン条件(Coffman Conditions)デッドロックが発生するのは、次の4つのコフマン条件がすべて成立している場合