問題タブ [3nf]

R(ABCD) FD付き

AB -> CD BC -> D

この質問を本で見つけましたが、関係は2nfにありますが、3nfにはありません。

些細な依存関係を見つけることができず、非プライム属性が別の非プライム属性に機能的に依存していない場合、なぜ関係が3nfにないのでしょうか?

BC も非素数属性と見なす必要がありますか? 3NFの概念を理解するのを手伝ってください

もう一つ疑問があります

機能依存性が

AB -> CD、C -> A、A -> C

関係は3NFになりますか？それとも、A -> C は、C が完全に機能的に AB に依存していないことを示しているため、2NF に違反しますか?

FDS を使用した次のリレーショナル データベースがあります: R1 (ABCDEFGH) FD: AB --> D、B --> C、B --> E、B --> F、A --> H、H --> G

キーはABだと思います。

これを R1(BCEF) と R2(ABDGH) に分解しました。次に、R2 を R3(AH) と R4(ABDG) に分解しました。

ここで間違いを犯していると思うので、誰かに再確認してもらう必要がありますが、それが何であるかはわかりません. 分解でH→GのFDを失ってしまったようです。

次の形式の FD を使用して 3NF でスキームを設計するにはどうすればよいですか

DBMS で 3NF の定義を読んでいたところ、次のように述べられています。

機能依存 X --> A は、次の場合に許可されます。 1. X がスーパー キーである。2. A は何らかのキーの一部です。

私は2つの疑問があります：

a: 異常を取り除くために 2 番目の条件がどのように役立つかという点がわかりません。なぜ BCNF 形式があるのでしょうか。代わりに、2 番目の条件を持たないように 3NF 形式を定義できます。

推移的な依存関係を削除するポイントがわかりました。Y --> Z および X が主キーの場合。X --> Y --> Z は、Z を知らない限り (X,Y) の値を格納できないことを意味するため、推移的な依存関係があります。

b: 3NF の 2 番目の条件を削除すると、異常が削除されたり、冗長性が制限されたりする仕組みを説明してください。

次の関係がありますが、3NF: FDs の違反についてはわかりません
R={A,B,C,D,E,F,G}
。
{AF-->BCG, B-->DE, CG-->EF, E-->G}

私のキーは{{A,F}},{{A,C,G}},{{A,C,E}},{{A,B,C}}
、Wikiによると次の定義です。

X がスーパーキーである、または
YX のすべての要素 (Y と X の集合の差) が主要な属性である (つまり、AY の各属性がいくつかの候補キーに含まれている)

X がスーパーキーではない場合、右側のすべての要素がキーの一部でなければならないので、唯一の違反はB-->DEandです。あれは正しいですか？CG-->EF

SQL データベースのエンティティ関係図を作成する必要があります。この質問は、私が投稿した以前の質問に関連しています:正規化 - SQL - 3NF

次のエンティティ関係図を作成しましたが、次のように正しいかどうか (テーブル間の関係など) を考えていました。

上記のエンティティ関係図は、3NF の次のデータに基づいています。

TBLCrew (CrewID[PrimaryKey]、CrewType、CrewTitle、名、姓、性別、CAALicenceNum)

TBLFlight (FlightID[PrimaryKey]、FlightNum、IATADep、IATAArr、Date、SchArr、コメント)

TBLAircraft (AircraftId[PimaryKey]、A/CType、A/C Rep、A/C Manuf)

TBLCrewFlight (CreweID[複合/複合キー]、FlightID[複合/複合キー])

AircraftFlight (CraftId、FlightId) [複合キー]

UNF の元のデータは次のとおりです。

エンティティ関係図は、3NF 内の関係に関して正しいですか?