BCNF分解が機能依存性を保持できないのはいつですか...たとえばR=(V、W、X、Y、Z)でこれを理解しようとしています
4 に答える
データベース設計と関係理論からの引用:
R = (S, J, T)
{S, J} -> {T}
{T} -> {J}
T -> J
保持されT
、キーではないため、これはBCNFにはありません。
それを分解してR1 = (T, J)
、R2 = (T, S)
キー{T}
または{T, S}
キーになります。BCNFにつながります。
ただし、依存関係{S, J} -> {T}
は失われます。
BCNF分解のポイントは、形式ではない機能依存性を排除することです。key -> everything else
したがって、テーブルにFD、たとえばA-> Bがあり、Aがキーではない場合、それはテーブルに冗長データを格納していることを意味します。その結果、Aがキーである列AとBを持つ新しいテーブルを作成し、元のテーブルからBを削除します。
この変更の結果、削除の異常に悩まされることはなくなり、A->Bの関係を変更するためだけに複数の行を更新する必要もなくなります。
したがって、些細で単純な例として、列を持つ従業員テーブルがあるとします。
employeeId name jobTitle salary
jobTitle -> salary
つまり、同じ役職の人は常に同じ給料を稼ぐと仮定します。「開発者」のjobTitleが$90,000の給与に相当するとします。データベースに20人の開発者がいる場合、各行に同じ冗長値$90,000を格納するのはばかげています。したがって、employeesテーブルからsalary列を削除し、次のコマンドを使用して新しい給与テーブルを作成します。
jobTitle_[key] salary
次に、従業員の給与を取得するには、給与テーブルでそれを調べます。
R(abcde)とFD {A-> B、AC-> D、BD->E}。この関係では、ACは候補キーであり、非プライムBはキー(AC)に部分的に依存しているため、この関係は2NFにはありません。この関係をbcnfに変換するには、次の2つの関係に分解します。R1(ab){a-> b} key = a R2(acde){ac-> de} key = aすべての行列式がキーであるため、R1とR2の両方がbcnfにあります。 、ただし、bd-> eが失われるため、依存関係は保持されません。
Schema R=(V,W,X,Y,Z)
Functional dependencies:
V,W -> X
Y,Z -> X
W -> Y
BCNFに分解すると、すべてのFDを1回の分解で保存できないことがわかります。