データベースにおける推移依存関係とは

正規化を確実にするための推移的依存関係の回避

データベースにおける推移的な依存関係は、 機能的な依存関係を引き起こす同じテーブル内の値間の間接的な関係です。 第3正規形（3NF）の正規化基準を達成するには、推移的な依存関係をなくす必要があります。

その性質上、推移的な依存関係は、それらの間に機能的な依存関係を持つ3つ以上の属性（またはデータベース列）を必要とします。つまり、表の列Aは中間列Cを介して列Bに依存します。

これがどのように機能するか見てみましょう。

一過性の依存関係の例

作家

上記のAUTHORSの例では、

• ブック → 作成者 ：ここでは、 ブック属性によって作成者属性が決定されます。 あなたが本の名前を知っているなら、あなたは著者の名前を知ることができます。 しかし、 作者は複数の本を書くことができるので、著者は本を決定しません。 たとえば、作者の名前Orson Scott Cardを知っているからといって、私たちはまだ本の名前を知らない。
• Author → Author_Nationality ：同様に、 Author属性はAuthor_Nationalityを決定しますが、それ以外の方法は決定しません。 国籍が私たちが作者を決定できるわけではないということを知っているからです。

しかし、この表には推移的な依存性が導入されています。

• Book → Author_Nationality：著者名を知っていれば、著者列で国籍を決定できます。

推移的な依存関係の回避

Third Normal Formを確実にするには、推移的な依存関係を削除しましょう。

まず、AuthorsテーブルからBookカラムを削除し、別のBooksテーブルを作成します。

書籍

作家

これで解決しましたか？ 今、依存関係を調べてみましょう：

BOOKSテーブル ：

• Book_ID → Book： BookはBook_IDに依存する。
• この表の他の依存関係は存在しないので、大丈夫です。 外部キーAuthor_IDは、主キーAuthor_IDを介してこの表をAUTHORS表にリンクすることに注意してください。 リレーショナルデータベースの重要な設計である推移的な依存関係を避けるために、関係を作成しました。

著者表 ：

• Author_ID → Author： AuthorはAuthor_IDに依存する。
• 著者 → 著者 Nationality：国籍は著者によって決定できます。
• Author_ID → Author_Nationality：国籍は、 Author_IDからAuthor属性を通じて決定することができる。 私たちはまだ過渡的な依存関係を持っています。

このデータを正規化するために3番目のテーブルを追加する必要があります。

国

作家

今度はテーブル間をリンクするために外部キーを使用する3つのテーブルがあります：

• BOOKテーブルの外部キーAuthor_IDは、書籍をAUTHORSテーブルの著者にリンクします。
• AUTHORSテーブルの外部キーCountry_IDは、作成者をCOUNTRIESテーブルの国にリンクします。

• COUNTRIES表には、この設計の別の表にリンクする必要がないため、外部キーはありません。

推移的な依存関係が悪いデータベース設計である理由

3NFを確実にするために過渡的な依存関係を避けることの価値は何ですか？ 私たちの最初のテーブルをもう一度考えて、それが作る問題を見てみましょう：

作家

このような設計は、データの異常や矛盾を引き起こす可能性があります。たとえば、

• "Children of the Mind"と "Ender's Game"の2冊の本を削除した場合は、作成者 "Orson Scott Card"とその国籍をデータベースから完全に削除します。

• ブックを追加しない限り、データベースに新しい著者を追加することはできません。 著者がまだ出​​版されていない場合や、著者が著者の書籍の名前を知らない場合はどうなりますか？
• 「Orson Scott Card」が市民権を変更した場合は、彼が現れたすべての記録でそれを変更する必要があります。 同じ著者が複数のレコードを持つと、データが不正確になる可能性があります。データ入力者が複数のレコードを認識していない場合に、1つのレコードのみでデータを変更するとどうなりますか？
• 著者を完全に削除することなく、「The Handmaid's Tale」のような本を削除することはできません。

これは、 正規化が過渡的な依存関係を回避し、データを保護し、一貫性を保証する理由の一部です。