web-dev-qa-db-ja.com

3NF分解-この例についてはわかりません

私は例を理解しようとしています 3NF分解 Ullman here で言及されている4ステップアルゴリズムを使用しているが、講師が最後のステップで何をしているか理解していない（または、さらに悪いことに、理解していない）アルゴリズム自体）。

これは初心者向けの質問だと思いますが、すべてグーグルで調べましたが、何も点灯していなかったので、ここに数時間頭を悩ませていました。

さて、

の アルゴリズム 問題は：

  1. Fの正規カバーF_cを見つける
  2. F_cの各FD X-> Yに対して、スキーマXYとの関係を作成します。
  3. スキーマが別のスキーマのサブセットである場合、関係を削除します
  4. これまでに作成されたスキーマのいずれにもキーまたはRが含まれていない場合は、Rのキーを含む関係スキーマを追加します。

今、私の講師が私たちに与えた例は、

 R<A,B,C,D,E,F>
 CE->A, C->D, A->B, D->BE, B->F, AD->CF

Fcは

C->A, C->D, A->B, D->B, D->E, B->F, AD->C

キーはCとADです。

今までは順調です。

次に、アルゴリズムのステップ2を適用します。

我々は持っています：

 
 R_i：A、B | D、B、E | F、B | C、D、A | A、D、C 
 --------- + ---------- + ---------- + -------- --- + ----------- 
 F_i A-> B | D-> B、| B-> F | C-> D | AD-> C 
 | D-> E | | C-> A |

これは醜くなりました。講師は、5番目のR_5はサブセットであると述べています。 （ささいなサブセット、私は言う）の 第4 ...「それらをマージ」に進み、

 
 R_i：A、B | D、B、E | F、B | C、D、A 
 --------- + ---------- + ---------- + -------- --- 
 F_i A-> B | D-> B、| B-> F | C-> D 
 | D-> E | | C-> A 
 | | | AD-> C-----これに注意！

F_4でAD-> Cがポップアップしたことに注意してください。

質問は単純です：なぜ？

なぜ彼は第5列を完全に削除しなかったのですか？

彼はアルゴリズムのステップ3を適用していますか？しかし、それは問題のあるスキーマを排除するように指示するだけであり、他のスキーマに依存関係を追加することについては何も述べていません。

彼はアルゴリズムのステップ4を適用していますか？しかし、スキーマにはそれらのallではなくRのキーが含まれている必要があると記述されています（これは意味のあることです）。

これは単純な間違いですか？とにかく最終結果は正しいですか？

みんなありがとう。

database-designnormalizationrelational-theory
2
Tobia Tesan

理論はすべて上手くいきますが、実際に練習を理解して初めて意味が出てきます。弁護士による最初の3つの正規形のバージョンは次のとおりです。

  1. Key-正規化されるすべての関係に主キーが必要です。
  2. キー全体-主キーの適切なサブセットに属性の機能的な依存関係があってはなりません。
  3. そしてキー以外の何もない-非キー属性の属性の機能的な依存関係があってはなりません。

実際には、リレーションには複数の候補キーがあり、これらのルールはそれらすべてに順番に適用される必要があります。

また、正規化するときは、各リレーションの最小キーを決定し、スーパーキーではなくそれらを使用する必要があります。

講師は5番目の列を完全に削除しませんでした。その列の機能的な依存関係がまだ存在しており、正規化プロセスで説明する必要があるためです。

更新：

FD AD-> Cは、ADCをCDAのサブセットとして認識しても消えません。これは、モデル内にADCとCDAの2つの関係を持つことは賢明ではありません。これは、正規化が排除するように設計されたソートの冗長性であるためです。

2
Pieter Geerkens