問題タブ [3nf]

私は、3NF を証明する方法について頭を悩ませようと懸命に努力しています。私は実際に答えを持っていますが、誰かが私にそれを理解させるのに十分なほど知っているなら、私は非常に感謝しています. わかりました、ここに行きます：

1. R が定義 2 に従って 3NF にある場合、R は定義 1 に従って 3NF になければなりません。R が定義 1 に従って 3NF にある場合、次の 2 つの条件が満たされなければならないことを思い出してください。

i) R の場合、非キー属性と他の非キー属性を介したキーとの間に推移的な関数依存関係はありません。

ii) R の場合、非キー属性とキーの間に部分的な関数依存関係はありません。

R が (i) を満たさないとします。次に、推移的な FD: X → A、A → B が必要です。ここで、X はキー、A と B は非キー属性です。しかし、定義 2 によれば、R にはそのような種類の FD はありません。(つまり、A は基本属性またはスーパー キーでなければなりません。) 矛盾。したがって、R は (i) を満たす必要があります。

R が (ii) を満たさないとします。次に、キー X (S ⊂ X) のサブセット S が必要であり、S → A の非キー属性 A が存在する必要があります。ただし、定義 2 によると、S はスーパーキーでなければなりません。矛盾。したがって、R は (ii) を満たす必要があります。したがって、定義 1 によると、R は 3NF にあります。

2. R が定義 1 に従って 3NF にある場合、R は定義 2 に従って 3NF にある必要があります。

 定義 2 により、R が 3NF にないと仮定します。次に、X がスーパー キーではなく、A が素属性でないような FD: X → A を持たなければなりません。R のキー X' を考えます。X' →X→A でなければなりません。これは、非キー属性 A と X を介したキー X' の間の推移的な FD です。X が非キー属性である場合、R は定義 1 に従って 3NF に含まれません。矛盾。X' に X が表示される場合、部分 FD があります。したがって、R は 2NF ではなく、定義 1 に矛盾します。

宿題の一環として、ケース スタディに基づいて表を作成するように依頼されました。すべての表は 3NF でなければなりません。ただし、3NF を理解しようと試みましたが、コツがつかめず、助けていただければ幸いです。

ケーススタディの要件は、獣医クリニック向けです。

1. ペットの予約を許可する
2. ペットの治療を記録する
3. どの獣医が治療を行ったかを記録する
4. ビジネスが販売したアイテムを記録して、ビジネスがサプライヤから購入するための在庫リストを作成できるようにする情報を提供します

不要: すべての売上を記録する

これまでのところ、次のテーブルがあります。

スタッフ：

スタッフの住所表:

獣医テーブル:

vet_nurse:

予約表：

initial_appointment テーブル:

フォローアップ予定:

忍耐強い：

製品：

product_sold:

サプライヤー：

サプライヤー_アドレス:

在庫：

ありがとう！

4NF と多値依存関係 (MVD) の概念に苦労しています。

現在受講しているコースの補足書を探しています。その一例を以下に示します。

この本では、アスタリスクが一意のキーまたは複合属性キーを参照していると述べています。

与えられたもの: R(A*,B,C*) と集合 {(A,B):R,(B,C):R} は無損失分解特性を満たします。

多値依存関係 B->>C は成立しますか?
B は間違いなく一意のキーですか?
R は 4NF ですか?

可逆分解を理解しています - 上記の 2 つのセットを自然に結合すると、元のデータセット、つまりこの場合は A、B、C が得られます。

しかし、与えられた情報をどのように取り、B->>Cが成立するか、成立しないかを証明/確認する方法を理解できません。

私は私の混乱について教授に電子メールを送りました.

次の列を持つテーブルがあるとします。

• person_id (主キー)
• ファーストネーム
• 苗字
• 誕生日

{first_name, last_name} の組み合わせにも一意の制約があります (同じ名前を持つ人が増えることはわかっていますが、例を単純にしたいと思います)。この表が第 3 正規形かどうかを知りたいです。

私の推論（編集前）：

• すべてのフィールドにはアトミック値のみを含めることができるため、テーブルは第 1 正規形になります。
• 候補キーは、1) person_id、2) [first_name, last_name] です。
• 非プライム属性は誕生日だけです。
• 属性誕生日は、候補キー 1 の一部に機能的に依存していません (候補キー 1 には属性が 1 つしかないため、これはとにかく不可能です)。
• 属性誕生日は、候補キー 2 の一部に機能的に依存していません
• したがって、この表は第 2 正規形です。
• 属性 birthday (is/is not) は候補キー 1 に非推移的に依存します
• 属性 birthday は、候補キー 1 に非推移的に依存しています。

質問（編集前）：

私が答えられない質問は、誕生日が非推移的に person_id に依存しているかどうかです。機能的には、この ID 番号と誕生日の間にはまったく関係がありません。

1. これは、推移的な依存関係 (誕生日は [first_name, last_name] に依存し、各組み合わせ [first_name, last_name] は ID にマップされる) があり、したがって 3NF ではないことを意味しますか?
2. これは、依存関係がまったくないということであり、したがって 3NF ではないということですか?
3. 私は難しい言葉を誤解していますか? この表は 3NF ですか?

私の推論（編集後）：

• person_id がわかれば、彼の名、姓、誕生日がわかるので、FD には {pe​​rson_id} -> {first_name}、{person_id} -> {last_name}、{person_id} -> {birthday} があります。
• 人の名前と姓がわかれば、その人の person_id と誕生日がわかるので、FD {first_name, last_name} -> {person_id} と {first_name, last_name} -> {birthday} があります。

• 人の誕生日を知っている場合、その人の person_id や名前については何も知らないため、誕生日から別の (セットの) 属性への FD はありません。

• すべてのフィールドにはアトミック値のみを含めることができるため、テーブルは第 1 正規形になります。

• 候補キーは 1) {person_id}、2) {first_name, last_name} です。
• 非プライム属性は {birthday} だけです。
• 属性 {birthday} は、CK 1 の一部の FD ではありません (CK 1 には属性が 1 つしかないため、とにかく不可能です)。
• 属性 {birthday} は CK 2 の一部で FD ではありません

• したがって、この表は第 2 正規形です。

• FD {person_id} -> {birthday} があるため、属性 {birthday} は CK 1 に非推移的に依存します。

• FD {first_name, last_name} -> {birthday} があるため、属性 {birthday} は CK 2 に非推移的に依存します。
• したがって、この表は第 3 正規形です。

依存関係 {person_id} -> {first_name, last_name} -> {birthday} がありますが、直接の依存関係 {person_id} -> {birthday} もあるため、この依存関係は推移的ではありません。

質問（編集後）：

私は本の FD の事前定義されたセットを持っていないので、FD が正しいかどうかわかりません。誰かがこれを確認できますか、または正しく見えない場合は、この実際の例で FD を見つける方法を示してもらえますか?

3 番目の推論 (2 回目の編集):

FD:

• 人物の person_id しか知らない場合は、その人物の名、姓、誕生日がわかります (同じ person_id を持つ人物が複数存在することはありません)。
  • FD: {person_id} -> {first_name}
  • FD: {person_id} -> {last_name}
  • FD: {person_id} -> {誕生日}
• {person_id} を含むスーパーセットを考慮する必要がなくなりました
• 人の名のみを知っている場合、この人の他のフィールドはわかりません (同じ名を持つ人が複数いる可能性があります)。
  • FD ではない: {first_name} -> {person_id}
  • FD ではない: {first_name} -> {last_name}
  • FD ではない: {first_name} -> {birthday}
• 人物の last_name しか知らない場合、この人物の他のフィールドはわかりません (同じ last_name を持つ人物が複数存在する可能性があります)。
  • FD ではない: {last_name} -> {person_id}
  • FD ではない: {last_name} -> {first_name}
  • FD ではない: {last_name} -> {birthday}
• ある人の誕生日しか知らない場合、その人の他のフィールドはわかりません (同じ誕生日の人が複数いる可能性があります)。
  • FD ではない: {birthday} -> {person_id}
  • FD ではない: {誕生日} -> {first_name}
  • FD ではない: {誕生日} -> {姓}
• 人の姓と名がわかれば、その人物の ID と生年月日がわかります (姓名が同じ人が複数存在することはありません)。
  • FD: {first_name, last_name} -> {person_id}
  • FD: {名、姓} -> {誕生日}
• {first_name, last_name} を含むスーパーセットを考慮する必要がなくなりました
• 人の名前と誕生日がわかっている場合、この人の他のフィールドはわかりません (同じ名前と誕生日を持つ人が複数いる可能性があります)。
  • FD ではない: {first_name, birthday} -> {person_id}
  • FD ではない: {first_name, birthday} -> {last_name}
• 人物の姓と誕生日がわかっている場合、この人物の他のフィールドはわかりません (姓と誕生日が同じ人物が複数存在する可能性があります)。
  • FD ではない: {last_name, birthday} -> {person_id}
  • FD ではない: {last_name, birthday} -> {first_name}

通常形:

• すべての属性には単一の値のみを含めることができるため、テーブルは第 1 正規形です。

• FD を見ると、1) {person_id}、2) {first_name, last_name} の 2 つの候補キーがあります。

• 非プライム属性は {birthday} だけです。
• 属性 {birthday} は、CK 1 の一部の FD ではありません (CK 1 には属性が 1 つしかないため、とにかく不可能です)。
• 属性 {birthday} は、CK 2 の一部の FD ではありません (つまり、FD {first_name} -> {birthday} または FD {last_name} -> {birthday} はありません)。

• したがって、この表は第 2 正規形です。

• S -> X かつ X -> T かつ not(X -> S) となるような X が存在する場合、S は推移的に T を決定します。

• S = CK1 = {person_id} および T = {birthday} とします。S -> X および X -> T となる唯一の X は、X = {first_name, last_name} の場合です。ただし、X -> S も成立します。したがって、S は非推移的に T を決定します。
• S = CK2 = {first_name, last_name} および T = {birthday} とします。S -> X および X -> T となる X は、X = {person_id} の場合のみです。ただし、X -> S も成立します。したがって、S は非推移的に T を決定します。
• したがって、この表は第 3 正規形です。

この投稿を見ましたが、使用されている用語がよくわかりません (重要な関数の依存関係、スーパーキー)

私が読んだことから、2番目の正規形は複合キーに関連しているようですが、3番目の正規形は主キーに関連しているようです。

これが正しいかどうかはわかりません。

したがって、第 2 の正規形 - 複合キーがあり、テーブル内のすべてのフィールドが両方の複合キー フィールドに関連付けられている必要があります。何かが関連していない場合は、別のテーブルにリファクタリングする必要があります。

第 3 正規形 - すべてが主キーに依存する必要があるため、複合キーが存在する可能性がある第 2 正規形ではなく、第 3 正規形ではキーが 1 つしかないと推測していますか?

アドバイスをいただければ幸いです。

私は大学の課題を与えられており、質問の 1 つは 3NF の重要性を説明することです。

正規化とは、データの冗長性を排除することだと理解しています。

ヘルプやリソースは非常に役立ちます。

ちょっと私は、与えられたこの関係のどれが 3NF/BCNF にあるかを特定しなければならない問題の例に取り組んでいます。

これらは関係です:

R1(A、B、C、D、E)

F=(CE->ABC、AB->C、C->A)

R2(C、D、E、G)

F=(CD->GE, E->D)

回答によると、R1 は 3NF にあり、R2 は BCNF にあり、どちらの場合も理由がわかりません。

ルールが次のいずれかである場合、R1 はどのようにして 3NF になることができますか。

X -> A の場合、A は X の部分集合です

X はスーパーキーです

A は R のキーの一部です

R1 には C->A = A はキーの一部ではなく、C はスーパーキーではなく、A は明らかにサブセットではありません。

R2 の場合、BCNF のルールは次のとおりです。

X → Y は些細な機能依存 (Y ⊆ X)

X はスキーマ R のスーパーキーです

E->D = E はスーパーキーではなく、D は E のサブセットでもありません。

答えが間違っていますか、それとも何か不足していますか?

どうもありがとう！

関係スキーマ R (ABCD)
関数の依存関係は次のとおりです
。AB -> D
CB -> D
A-> C
C -> A
最高正規形 ???

私の理解 ：

候補キー = ABおよびBC

テーブルの作成中、AB と BC の両方を主キーと見なすことはできません。それでは一つ一つ取り上げていきましょう。

キー AB の場合:
AB -> D ( Fully Functional Dependency , so no problem )
CB -> D ( ??? )
A -> C (partial Functional Dependency , as left side contains only part of key)
C -> A ( Functional Dependency , So no problem )

キーBC用

現在、両方のキーによって、リレーションには部分的な機能依存関係が含まれています。
その場合、2NF であってはなりません。
しかし、答えは 3NF です。
私を修正してください。