DBMSにおける推移的従属性(Transitive Dependency)とは?第三正規形への正規化をわかりやすく解説
推移的従属性(推移的な依存関係)とは?
間接的なリレーションシップによって引き起こされる関数従属のことを、推移的従属(トランジティブ・ディペンデンシー)と呼びます。
P → Q と Q → R の両方が成り立つ場合、P → R も自動的に成り立ちます。これが推移的従属です。
第三正規形(3NF)を達成するには、この推移的従属を排除する必要があります。
推移的従属が残ったままでは、データの重複や更新時の不整合(更新異常)が発生しやすくなります。そのため、3NFでは主キー以外の属性(非キー属性)同士が互いに依存し合わないよう設計することが重要です。
具体例
次の映画リストテーブル「<MovieListing>」を見てみましょう。
| Movie_ID | Listing_ID | Listing_Type | DVD_Price($) |
| M08 | L09 | Crime | 180 |
| M03 | L05 | Drama | 250 |
| M05 | L09 | Crime | 180 |
このテーブルには、次のような推移的な関数従属が存在するため、第三正規形(3NF)を満たしていません。
| Movie_ID → Listing_ID Listing_ID → Listing_Type |
したがって、以下の推移的な関数従属が導かれます。
Movie_ID → Listing_Type
これは、リレーション「<MovieListing>」が第三正規形(3NF)に違反していることを意味します。
推移的従属の解消方法
この違反を解消するには、テーブルを分割し、推移的な関数従属を取り除きます。
<Movie> テーブル
| Movie_ID | Listing_ID | DVD_Price($) |
| M08 | L09 | 180 |
| M03 | L05 | 250 |
| M05 | L09 | 180 |
<Listing> テーブル
| Listing_ID | Listing_Type |
| L09 | Crime |
| L05 | Drama |
これで、各リレーションは正規化における第三正規形(3NF)を満たすようになりました。テーブルを適切に分割することで、ジャンル名などの重複データが削減され、更新・挿入・削除時に発生しうる不整合のリスクも抑えられます。
-
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つのコフマン条件がすべて成立している場合