問題タブ [3nf]

3NF/BCNF にある関係を区別する方法について、さまざまな情報源を読んできました。そして、私はこれまでのところ、これが私の理解です...

この関係を例として使用します...

R = {A, B, C, D, E}

と

F = {A -> B, B C - > E, E D -> A}.

まず、関係のキーを見つける必要があります。そのためにこの動画を使いました。そして、私は得ました

Keys = {ACD, BCD, CDE}

RがBCNFにあることを確認するには、 のすべての関数依存関係の左側FがKeys. A -> B最初の FD はキーの 1 つであり、キーの 1 つではないため、そうではないことがすぐにわかりAます。したがって、BCNF にはありません。

Rが3NFにあることを確認するには、 のすべての機能依存関係の左側が のFいずれかであるか、 のすべての機能依存関係の右側が の 1 つのサブセットであるKeys ことを確認する必要があります。すべての FD の右側を見ると、、およびです。これらはそれぞれ a のサブセットであるため、これは 3NF にあることを意味します。FKeysBEAKey

したがって、これは(wiki によると) リレーションが に含まれているが含まれていないまれなケースの 1 つです。この方法は正しいですか？信頼できますか？何か不足していますか？3NFBCNF

ここに私のERDがあります：

このERDを正規化しようとしましたが、これまでに行ったことは次のとおりです。

私は第 3 正規形まで正規化しようとしているので、基本的に機能的な依存関係を達成し、移行的な依存関係を取り除こうとしています。私を混乱させるいくつかの質問があります：

1. 飛行機のテーブルで、メーカーとモデルはそのままでいいですか、それとも新しいテーブルに移す必要がありますか?
2. 空港のテーブルで、ICAO と IATA のコード識別子を新しいテーブルに転送する必要がありますか?
3. Airline テーブルの IATA と ICAO についても同様です。
4. また、3NF を考慮して、マネージャー テーブルに何か変更が必要ですか?

よろしく

次のリレーショナル スキーマを検討してください。

(第 3 正規形で) 完全に正規化し、機能の依存関係を特定しようとしています。ただし、無限の研究により、次の方法を回避することはできません。

1. リレーショナル スキーマを完全に正規化する
2. 機能依存関係の特定

これについてどうすればいいですか？

一連の依存関係を持つリレーショナル スキーマ R(A、B、C、D) がある場合:

R を BCNF 関係に分解するにはどうすればよいですか? どのように考えても、唯一のもっともらしい方法は、FDの1つを破棄することです。他に方法はありますか？