私はデータベースの正規化と結合の依存関係と 5NF を学んでいました。苦労しました。複数値の依存関係ルールの実用的な例を教えてください。
MVD3: (推移性) X ↠ Y かつ Y ↠ Z の場合、X ↠ (Z − Y)。
質問する
638 次
1 に答える
1
機能依存性/正規化理論と BCNF までの正規形は、すべてのデータ属性 (列/型/...) が特定の意味で「アトミック」であるという仮説に基づいて開発されました。その「特定の意味」は今では長い間廃止されてきましたが、本質的には「テーブル内の単一のセル値はそれ自体では複数の値を保持できない」という概念に要約されました。ISBN 番号のテキスト CSV リスト、テーブル内のセルの値として表示されるテーブル (真にネストされたテーブル) などを考えてみてください。
ここで、コース、教授、学習用の本をコース教材として使用する例を想像してみてください。「教授 (P) はコース (C) を教え、本 (B) をコースの教材として使用する」という単一の 3 列のテーブルでモデル化されたこれらすべてを想像してみてください。任意のコース (Cn) に複数の本 (B) が使用され、特定の教授 (Pn) によって複数のコース (C) が教えられ、複数の教授 (P) が教えられている場合任意のコース (Cn) の場合、このテーブルは明らかにオールキーです (キーは属性 {P,C,B} の完全なセットです)。
これは、このテーブルが BCNF を満たしていることを意味します。
しかしここで、「どの教授がそれを教えようと、そのコース (Cn) に使用される本のセットは同じでなければならない」という趣旨の規則があると想像してください。
正規化が現在一般的に知られている形式に発展した時代には、それ自体がテーブル (関係) であるテーブル列 (関係属性) を持つことは許可されていませんでした。(そのような設計は 1NF の違反と見なされたため、現在では疑わしいと見なされている概念です。)
リレーション属性をリレーション型としてモデル化できることを想像してみてください。次に、3 列のテーブル (/relation) を次のようにモデル化できます。属性 SB は、以前のより明白な設計のように ISBN 番号ではなくなりますが、ISBN 番号のセット全体を保持する (おそらく単項の) RELATIONになります。このようにデザインを描くと、「すべての教授が同じコースで同じ本を使用する」というルールを考えると、このルールは (C) から (SB) への FD として表現できることがわかります。 !!! そして、これは私たちの手でより低いNFの違反があることを意味します!!!
4 と 5 の NF は、この種の問題 (単一の属性値 - courseID (C) の出現により、複数の行 (複数 (B) の ISBn 番号) の出現が非常に早期に認識される必要がある場合) から生じました。しかし、現在最良と見なされているソリューション (RVA) がなく、有効なソリューションとして認識されている. したがって、4 と 5 の NF は、「新しい、さらに正規の形式」として作成されました。 BC NF は、RVA が有効な設計アプローチとして認識されていれば、目の前の状況に対処するのに十分でした。
その主張を裏付けるために、FD C->SB を使用した {P,C,SB} 設計で NF 違反を排除するために何をすべきかを見てみましょう。
テーブルを、それぞれキー {P,C} および {C} を持つ 2 つの別個のテーブル {P,C} および {C,SB} に分割します。どちらのテーブルも BCNF を満たしています。
しかし、ISBN 番号のセットを保持するこの SB 属性はまだあります。これに対処するには、「UNGROUPING」などの手法を適用します。これを {C,SB} テーブルに適用すると、{C,B} テーブルが得られます。ここで、B は ISBN 書籍番号 (またはデータベースで使用したい任意の識別子) であり、テーブルのキーは {C 、B}。これは、4/5 NF 違反を排除した場合に得られる設計とまったく同じです!!!
Multivalue Dependency violationも参照してください。
于 2012-05-29T10:25:04.397 に答える