問題タブ [third-normal-form]

私は、第 3 および第 4 正規形に入れる必要があるこのデータを持っています。

ノーマルフォームの基本は理解できたのですが、第3、第4ノーマルフォームと混同してネットで調べたのですが未だにわかりません。

システムで使用されているデータベースを作成しています。

最近データベースの勉強を始めましたが、この特定の部分に苦労しています。

それぞれの定義を読みましたが、Normal Formまだ理解できないようです。正しく解決できなかった例を次に示します。

解決：R1(*A*,B,E); R2(*B*,C,D); R3(*A*,*F*)

どうしてR3こうなるのか理解できない

私はたくさんグーグルで検索しましたが、その質問に対する答えは見つかりませんでした.

最初の 3 つの正規形は常識です。一貫性を保ち、異常を避けるために使用されます。しかし、なぜ BCNF と第 4 正規形が必要なのでしょうか?

（5番目は、それが何をするのかさえ理解していないので、あえて尋ねません）

評価の一環として、データベースに依存する PHP でサイトを構築する必要があります。サイトは、必要なものであれば何でもかまいません。このサイトの唯一の制限は、データベースには最低 7 つのテーブルが必要であり、第 3 正規形である必要があり、最低 1 つの多対多テーブルが必要です。

以下は私が持っているスキーマです。第 3 正規形でない場所や、多対多のテーブル (ゲーム) が機能しない場合に、喜んで教えてくれることを願っています。

候補キーが存在しないためには、各項目が主キーに依存している必要があるという点で、第 3 正規形を理解しています。

考え？

誰でもアイテムを売買でき、2 人の登録ユーザーが製品に関して互いにメッセージを送信できる Web サイトがあるとします。私のデータベースの関係の1つは次のとおりです。

もちろん、送信者または受信者のいずれかは、製品の販売者または購入者である必要があります。私の質問は、この関係が第 3 正規形であるかどうかです。もちろん、これは第 2 正規形です。これは、すべての非キー カラムが完全に機能的に主キーに依存しているためです。

userB例:が商品の販売者 (所有者) であり、製品の販売者 (所有者) である#1234とuserAしましょう#1000。次の表があります。

どうやら、idObject上記の表で製品の販売者を決定します。いずれの場合も、販売者は「差出人」列または「受取人」列に記載されている必要があります。ポイントは、上記の例でわかるように、[送信者] または [受信者] が idObject を特定できないことです。したがって、すべての非キー列は機能的に依存しており、主キーにのみ依存しているため、3NF があります。

次の表を想像してください。私の場合、[unique+not null = primary key]であるname必要があるuniqueと完全に確信しています。not nullしたがってname、主キーです。何らかの理由で (おそらく習慣による)、idint 型の主キー列を自然に作成しました。

その他の仮定: 私は絶対にテーブルに保持する必要があり、 (タイプの) が 20 文字を超えないことnameを絶対に確信しています。namevarchar

ここで、私の最初の質問は [おそらくイエスまたはノーが予想される近い質問] です。このようなテーブルを作成した場合、BCNF ボイス-コッド正規形を尊重しますか?

id2 番目のオプションの質問 [おそらく未解決の質問]:この場合、列を作成するのは適切ですか?