データベースにおける推移的な依存関係は、機能的な依存関係を引き起こす同じテーブル内の値間の間接的な関係です。第3正規形（3NF）の正規化基準を達成するには、推移的な依存関係をなくす必要があります。
その性質上、推移的な依存関係は、それらの間に機能的な依存関係を持つ3つ以上の属性（またはデータベース列）を必要とします。つまり、表の列Aは中間列Cを介して列Bに依存します。
これがどのように機能するか見てみましょう。
一過性の依存関係の例
作家
| Author_ID | 著者 | 本 | Author_Nationality |
|---|---|---|---|
| Auth_001 | オルソン・スコットカード | エンダーのゲーム | アメリカ |
| Auth_001 | オルソン・スコットカード | エンダーのゲーム | アメリカ |
| Auth_002 | マーガレットアトウッド | おばあちゃんの物語 | カナダ |
上記のAUTHORSの例では、
- 本 → 著者 : ここで、 本 属性によって 著者 属性。あなたが本の名前を知っているなら、あなたは著者の名前を知ることができます。しかしながら、 著者 決定していない 本 著者は複数の本を書くことができるからです。たとえば、作者の名前Orson Scott Cardを知っているからといって、私たちはまだ本の名前を知らない。
- 著者 → Author_Nationality : 同様に、 著者 属性によって Author_Nationality しかし、それ以外の方法はありません。国籍が私たちが作者を決定できるわけではないということを知っているからです。
しかし、この表には推移的な依存性が導入されています。
- 本 → Author_Nationality： 書籍名がわかっている場合は、著者列で国籍を判断できます。
推移的な依存関係の回避
Third Normal Formを確実にするには、推移的な依存関係を削除しましょう。
まず、AuthorsテーブルからBookカラムを削除し、別の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_ID .
- この表の他の依存関係は存在しないので、大丈夫です。外部キー Author_ID 主キーを使用してこの表をAUTHORS表にリンクします。 Author_ID 。リレーショナルデータベースの重要な設計である推移的な依存関係を避けるために、関係を作成しました。
AUTHORS表:
- Author_ID → 著者： ザ 著者 は、 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 | マーガレットアトウッド | おばあちゃんの物語 | カナダ |
このような設計は、データの異常や矛盾を引き起こす可能性があります。たとえば、
- "Children of the Mind"と "Ender's Game"の2冊の本を削除した場合は、作成者 "Orson Scott Card"とその国籍をデータベースから完全に削除します。
- ブックを追加しない限り、データベースに新しい著者を追加することはできません。著者がまだ出版されていない場合や、著者が著者の書籍の名前を知らない場合はどうなりますか？
- 「Orson Scott Card」が市民権を変更した場合は、彼が現れたすべての記録でそれを変更する必要があります。同じ著者が複数のレコードを持つと、データが不正確になる可能性があります。データ入力者が複数のレコードを認識していない場合に、1つのレコードのみでデータを変更するとどうなりますか？
- 著者を完全に削除することなく、「The Handmaid's Tale」のような本を削除することはできません。
これは、正規化が過渡的な依存関係を回避し、データを保護し、一貫性を保証する理由の一部です。
