-1

明日提出する必要のある宿題があります。通常、正規化の概念を知っていますが、いくつかの質問で問題があります。これをBCNFに正規化するにはどうすればよいですか？手順を教えていただけますか？

R(A,B,C,D,E,F,H)

FDセットは

A->D
AE->H
DF->BC
E->C
H->E

この現実のために、私はキーを見つけてBCNFに正規化する必要があります。2NFに正規化すると、3NFに適さないいくつかの関係が失われます。だから私は混乱しています。どんな助けでもありがたいです。

ありがとうございました

4

3 に答える 3

0

データベースを第3正規形にするための2つの基本的な要件があります。

  • すでに1NFと2NFの両方の要件を満たしています
  • 主キーに完全に依存していない列を削除します。

2NFで正規化すると、関係が失われることはなく、別の関係が得られます。さて、宿題をしましょう。

あなたの関係がすでに1NFにあると仮定することから始めましょう。今2NFのために

R1 = AE -> {H}(AE->H)
R2 = DF -> {B, C}(DF->BC)
R3 = A  -> {D}(A->D)
R4 = E -> {C}(E->C)

上記の関係は2NFにあり、非プライム属性のいずれも候補キーに部分的に依存していません。また、3NFでも、関係内に推移的な関係がないためです。

BCNFの場合、H-> E関係がR1で保持され、HがR1の候補キーに属していないため、R1を除くすべての関係がBCNFに従います。

BeeriとBernsteinは、1979年に、たとえば、一連の関数従属性{AB→C、C→B}は、元のテーブルに保持されている依存関係を保持することによってBCNFスキーマで表すことができないことを示しました。詳細については、 wikiをお読みください。

ただし、それをBCNFに変換することはできます。

R1 = A -> {E}
R2 = E -> {H}
R3 = DF -> {B, C}
R4 = A  -> {D}
R5 = E -> {C}

ただし、上記のテーブルは元の関係AE-> Hを保持していないため、一貫性がなく、元のテーブルに保持されていた依存関係を保持することにより、この関係をBCNFで達成できません。

于 2012-12-15T14:18:07.900 に答える
0

質問に答えるために、しかしあなたの説明ではなく、はい、あなたはプロセスの2NFで止まることなく1NFから3NFに正規化することができます。

よくある誤解は、1NFの関係から始めることができるというものです。

  • それらを2NF以上に正規化してから
  • それらを3NF以上に正規化してから
  • それらをBCNFに正規化し、それ以上にしないでください。

それは一般的ですが、それでも誤解です。この誤解の反例は多くの教科書で見ることができますが、それらの例を注意深く見る必要があります。私の知る限り、この誤解を明確に特定している教科書はありませんが、その例を研究すれば明らかになります。

実際には、1つのステップで1NFまたは2NFから5NFまたは6NFに移行するのが一般的です。たとえば、2NFから5NFに移行するということは、推移的な依存関係を削除することを意味します。

  • 左側が候補キー（BCNFに必要）ではない依存関係が残っていないことがわかります。
  • 残りの多値従属性（4NFに必要）が見つからず、
  • 残りの結合依存関係は見つかりません（5NFに必要）。

これは、StackOverflowの例でよく発生します。（2NFから5NFまたは6NF、つまり。）

使用した表記法で表現された宿題の問題では、開始関係が1NFであると想定することが期待されます。あなたの最初の仕事は鍵を特定することです。なんで？部分キーの依存関係を識別できない限り、2NFに正規化することはできず、すべての候補キーを知らない限り、それを行うことはできません。

キーをAEFおよびAFHとして識別するのは正しいです。依存関係の1つがA-​​>Dであるため、関係Rは2NFにありません。DはAのみに依存し、Aは候補キーの一部です。2NFに正規化するには、すべての部分キーの依存関係を特定し、それらを射影によって削除します。

これから始めましょう。

  • R（ABCDEFH）、キー{ AEF、AFH }

部分キーの依存関係A->Dを削除します。

  • R 1（ABCEFH）、キー{ AEF、AFH }
  • R 2（A D）

R2は6NFです。

その部分キーの依存関係をRから削除すると、R1になります。R 1には属性Dが含まれていないため、関数従属性DF->BCはR1には適用されません。ただし、DF->BCは設計全体に適用されます。これがあなたを混乱させたポイントです。

ほとんどの場合、機能依存性は単純なキー制約になります。それが、FDA->DがR2になったときに起こったことです。ただし、射影はDF-> BCの左側を分割するため、その依存関係はデータベースの制約として別の方法で表現する必要があります。（SQLはそれが得意ではありません。CREATEASSERTIONはそれらのベースをカバーすることになっていますが、まだ誰もそれを実装していません。）

于 2012-12-15T16:30:12.410 に答える
0

これから始めましょう。

R（ABCDEFH）、キー{AEF、AFH}
部分キーの依存関係A->DおよびE->Cを削除します。

R1（ABEFH）、キー{AEF、AFH}
R2（A D）
R3（E C）

R1、R2、およびR3は2NFにあります。

その部分キーの依存関係をRから削除すると、R1になります。R1には属性Dが含まれていないため、機能依存性DF-> BCはR1には適用されません。ただし、DF->BCはデザイン全体に適用されます。これがあなたを混乱させたポイントです。

ここで、マイクのコメントを続けます。

R1に属性Dが含まれていない場合でも、R1にはAが含まれていることに注意する必要があります。AF-> DF-> BCとして、依存関係DF->BCはR1に保持されます。

3NFの場合、推移的な依存関係DF->BおよびDF->Cを削除する必要があり、次のようになります。

R1（AEFH）、キー{AEF、AFH}
R2（A D）
R3（E C）
R4（DF BC）

すべての関係は3NFにあります。

于 2013-04-18T12:13:59.393 に答える