データベース設計に推移的な依存関係があります。上司から、これらはバグを引き起こす可能性があると言われました。これらの依存関係があるとバグがどのように発生するかを教えてくれるリソースを見つけるのは難しいと感じています。彼らはどのような問題を引き起こしますか？
私はその事実に異議を唱えているのではなく、彼らがどのような問題を引き起こす可能性があるのかを知りたがっています。
詳細については編集してください：
ウィキペディアから：
推移的依存性
推移的依存性は、間接的な機能依存性であり、X→YおよびY→ZによってのみX→Zになります。
例を挙げて説明します：
-------------------------------------------------------------------
| Course | Field | Instructor | Instructor Phone |
-------------------------------------------------------------------
| English | Languages | John Doe | 0123456789 |
| French | Languages | John Doe | 0123456789 |
| Drawing | Art | Alan Smith | 9856321158 |
| PHP | Programming | Camella Ford | 2225558887 |
| C++ | Programming | Camella Ford | 2225558887 |
-------------------------------------------------------------------
Course場合は、簡単に取得できInstructorますCourse->Instructor。Instructor、彼を取得することはできません。CourseInstructorあなたは簡単に彼のPhoneそうを手に入れることができますInstructor->Phone.つまり、もしあなたが持っているなら、あなたはその手段を Course得ることができます（つまり、推移的な依存関係）Instructor PhoneCourse->Instructor Phone
問題は次のとおりです。
FrenchとEnglishコースの両方を削除すると、そのインストラクターJohn Doeも削除され、彼の電話番号は永久に失われます。Instructor最初に彼のために追加しない限り、データベースに新しいを追加する方法はありません。または、さらに悪いことCourseにデータを複製することもできます。Instructors tableJohn Doeが電話番号を変更した場合、インストラクターが教えるすべてのコースを新しい情報で更新する必要がありますが、これは非常に間違いが起こりやすい可能性があります。Birth Dateテーブルにフィールドを追加する必要がありCoursesます。これは論理的に聞こえますか？そもそもなぜコース テーブルに講師情報を保持するのでしょうか。3NF を表現する 1 つの方法は次のとおりです。
すべての属性は、キー、キー全体、およびキーのみに依存する必要があります。
推移的な依存関係 X->Y->Z はその原則に違反しており、データの冗長性と潜在的な変更の異常につながります。
これを分解してみましょう：
つまり、Y はキーではなく、Y->Z であるため、3NF に違反しています。
冗長性は変更の異常につながります (たとえば、同じ Y に「接続された」Z のすべてではなく一部を更新すると、どのコピーが正しいかわからなくなるため、本質的にデータが破損します)。これは通常、元のテーブルを 2 つのテーブルに分割することで解決されます。1 つは {X, Y} を含み、もう 1 つは {Y, Z} を含みます。このようにして、Y を 2 番目のテーブルのキーにすることができ、Z は繰り返されません。
一方、X<-Y が成り立つ場合 (つまり、X->Y->Z が推移的でない場合)、X と Y の両方がキーである単一のテーブルを保持できます。このシナリオでは、Z が不必要に繰り返されることはありません。
(FOOTNOTE1) キーは、リレーション内のすべての属性を機能的に決定する (最小限の) 属性のセットです。理論的根拠: K がキーの場合、K の同じ値を持つ複数の行が存在することはできないため、K の特定の値は常に、他のすべての属性の正確に 1 つの値に関連付けられます (1NF と仮定)。定義上 (FOOTNOTE2 を参照)、「正確に 1 つに関連付けられる」ことは、「機能的な依存関係にある」ことと同じことです。
(FOOTNOTE2)定義により、Y->Z は、各 Y 値が正確に 1 つの Z 値に関連付けられている場合に限ります。
例：
各メッセージに正確に 1 人の作成者がいて、各作成者に正確に 1 つのプライマリ電子メールがあると仮定すると、同じテーブルでメッセージとユーザーを表現しようとすると、電子メールが繰り返されることになります。
MESSAGE USER EMAIL
------- ---- -----
Hello. Jon jon@gmail.com
Hi, how are you? Rob rob@gmail.com
Doing fine, thanks for asking. Jon jon@gmail.com
(実際には、これらはMESSAGE_IDs になりますが、ここでは単純にしておきましょう。)
では、Jon が自分の電子メール アドレスを「jon2@gmail.com」などに変更するとどうなるでしょうか。Jon の両方の行を更新する必要があります。1つだけ更新すると、次のような状況になります...
MESSAGE USER EMAIL
------- ---- -----
Hello. Jon jon2@gmail.com
Hi, how are you? Rob rob@gmail.com
Doing fine, thanks for asking. Jon jon@gmail.com
...そして、ジョンの電子メールのどれが正しいのか、もはやわかりません。基本的にデータを失いました！
DBMS に両方の更新を強制するために使用できる宣言的な制約がないため、状況は特に悪いです。クライアント コードにはバグがあり、並行環境で発生する可能性のある複雑な相互作用をあまり考慮せずに記述されている可能性があります。
しかし、テーブルを分割すると...
MESSAGE USER
------- ----
Hello. Jon
Hi, how are you? Rob
Doing fine, thanks for asking. Jon
USER EMAIL
---- -----
Jon jon@gmail.com
Rob rob@gmail.com
...Jon の電子メールについて知っているのは 1 行だけなので、あいまいさはありません。
ところで、これはすべてDRY 原則の別の表現と見なすことができます。
テーブルに推移的な依存関係がある場合、それは 3NF に準拠していません。そのため、テーブルに冗長データが存在する可能性が高くなります。この概念を明確にするために、これをチェックしてください。
このリンクを見てください：
http://en.wikipedia.org/wiki/Transitive_dependency
この例を使用すると、一方の行でジュール ヴェルヌの国籍を更新し、もう一方の行では更新しない場合はどうなるでしょうか? 著者の国籍は、本と著者の組み合わせではなく、著者のみで決定されます。したがって、サンプルのデータ構造を使用して、データベースにジュール ベルヌの国籍を尋ねることができる可能性があります。次のSQLコマンドを実行した場合
SELECT TOP 1 author_nationality FROM books WHERE author='ジュール ヴェルヌ'
データベースが TOP 1 をどのように選択するかによって、異なる答えが得られる可能性があります。