データベースの推移的な依存関係とは
データベース内の推移的な依存関係は、同じテーブル内の値間の間接的な関係であり、 機能従属性. を達成するために 第3正規形（3NF）の正規化標準、推移的な依存関係を排除する必要があります。
その性質上、推移的な依存関係には3つ以上が必要です 属性 （またはデータベース列）それらの間に機能依存性があります。つまり、テーブルの列Aは、中間の列Cを介して列Bに依存しています。 これがどのように機能するか見てみましょう。
推移的な依存関係の例
著者
| Author_ID | 著者 | 本 | Author_Nationality |
|---|---|---|---|
| Auth_001 | オーソンスコットカード | エンダーのゲーム | アメリカ |
| Auth_001 | オーソンスコットカード | 心の子供たち | アメリカ |
| Auth_002 | マーガレット・アトウッド | ハンドメイドの物語 | カナダ |
上記のAUTHORSの例では：
- 本→著者：ここで、 本 属性は 著者 属性。 本の名前を知っていれば、著者の名前を知ることができます。 しかし、 著者 決定しません 本、著者は複数の本を書くことができるからです。 たとえば、作者の名前がわかっているからといって、 オーソンスコットカード、まだ本の名前はわかりません。
- 著者→Author_Nationality：同様に、 著者 属性は Author_Nationality、ただしその逆ではありません。著者の国籍がわかっているからといって、著者を特定できるとは限りません。
しかし、この表は推移的な依存関係を導入しています。
- 本→Author_Nationality：本の名前がわかっている場合は、[著者]列から著者の国籍を確認できます。
推移的な依存関係の回避
第3正規形を確実にするために、推移的な依存関係を削除しましょう。
まず、AuthorsテーブルからBook列を削除し、別のBooksテーブルを作成します。
BOOKS
| Book_ID | 本 | Author_ID |
|---|---|---|
| Book_001 | エンダーのゲーム | Auth_001 |
| Book_001 | 心の子供たち | Auth_001 |
| Book_002 | ハンドメイドの物語 | Auth_002 |
著者
| Author_ID | 著者 | Author_Nationality |
|---|---|---|
| Auth_001 | オーソンスコットカード | アメリカ |
| Auth_002 | マーガレット・アトウッド | カナダ |
これで修正されましたか？ 私たちを調べてみましょう 依存関係 今：
BOOKSテーブル:
- Book_ID→Book：NS 本 に依存します Book_ID.
- このテーブルには他の依存関係は存在しないため、問題ありません。 外部キーに注意してください。 Author_ID、 このテーブルを主キーを介してAUTHORSテーブルにリンクします。 Author_ID. 推移的な依存関係を回避するための関係を作成しました。 リレーショナルデータベース.
AUTHORSテーブル:
- Author_ID→作成者： NS 著者 に依存します Author_ID.
- 著者→Author_Nationality：国籍は作者が判断できます。
- Author_ID→Author_Nationality：国籍は Author_ID を通って 著者 属性。 推移的な依存関係がまだあります。
このデータを正規化するには、3番目のテーブルを追加する必要があります。
国
| Country_ID | 国 |
|---|---|
| Coun_001 | アメリカ |
| Coun_002 | カナダ |
著者
| Author_ID | 著者 | Country_ID |
|---|---|---|
| Auth_001 | オーソンスコットカード | Coun_001 |
| Auth_002 | マーガレット・アトウッド | Coun_002 |
これで、3つのテーブルができました。 外部キー テーブル間をリンクするには：
- BOOKテーブルの外部キー、 Author_ID、本をAUTHORSテーブルの著者にリンクします。
- AUTHORSテーブルの外部キー、 Country_ID、著者をCOUNTRIESテーブルの国にリンクします。
- この設計では別のテーブルにリンクする必要がないため、COUNTRIESテーブルには外部キーがありません。
推移的な依存関係が悪いデータベース設計である理由
3NFを確保するために推移的な依存関係を回避することの価値は何ですか？ 最初のテーブルをもう一度考えて、それが生み出す問題を見てみましょう。
著者
| Author_ID | 著者 | 本 | Author_Nationality |
|---|---|---|---|
| Auth_001 | オーソンスコットカード | エンダーのゲーム | アメリカ |
| Auth_001 | オーソンスコットカード | 心の子供たち | アメリカ |
| Auth_002 | マーガレット・アトウッド | ハンドメイドの物語 | カナダ |
この種の設計は、次のようなデータの異常や不整合の原因となる可能性があります。
- 2冊の本を削除した場合 心の子供たち と エンダーのゲーム、 著者「OrsonScottCard」とその国籍をデータベースから完全に削除します。
- 書籍も追加しない限り、データベースに新しい著者を追加することはできません。 著者がまだ公開されていない場合、または著者が書いた本の名前がわからない場合はどうなりますか？
- 「オーソンスコットカード」が彼の市民権を変更した場合、あなたは彼が登場するすべての記録で彼の市民権を変更する必要があります。 同じ作成者のレコードが複数あると、データが不正確になる可能性があります。 データ入力担当者が誰かのレコードが複数あることに気づかず、1つのレコードのデータのみを変更した場合はどうなりますか？
- 次のような本は削除できません ハンドメイドの物語 著者を完全に削除することもありません。
よくある質問
- データベース管理システムの依存関係の種類は何ですか？ がある 4種類のデータベース依存関係：些細な機能依存性、完全な機能依存性、推移的な依存性、および多値従属性。
- 機能従属性は推移的依存性とどのように異なりますか？ データベース管理では、依存関係は2つ以上の属性（列）間の関係です。 関数従属性は、同じ関係の2つの属性間の関連付けですが、推移的な依存関係は、間接的な関係が関数従属性を引き起こす場合に発生します。