問題タブ [3nf]

3NFの次の表は次のとおりです。

アドレスフィールドをこのテーブルに含める必要があるのか​​、それともさらに分解する必要があるのか​​を知りたいと思います。

ID（PK）、タイトル、監督、制作年、制作会社の構造を持つ単純なテーブルがあります

3nfでは、非主キー間に推移的な関係があってはいけませんが、（監督、制作年、制作会社）はタイトルに依存すると思いますが、タイトルは一意ではないため、タイトル自体を別のテーブルで主キーにすることはできません。

私のテーブルは3nfですか？

関係データベースを使用していて、3NF が必要な場合 (英語で 3NF と呼びますか?)、1:1 の関係を 1 つのテーブルにまとめます。しかし、配給が 1:0/1 (/ または意味) の場合はどうなるでしょうか?

次に、テーブルの空白を避けるためにそれらを分離したままにしますか? この場合、それらを離すことは有効な 3NF ですか?

これは正しいですか: エンティティが時間の経過とともに属性の不変性を失うとすぐに (独立して、たとえば、一部の属性のみ、次に 1 つの属性のみ)、正しく正規化する唯一の方法は 6NF を使用することです。

3NF は 6NF の特別な形式です。しかし、時間変動がゲームに入ると、3NF をイメージできません。

正規化のいくつかの例を読んでいますが、理解できないものに出くわしました。

例の Web サイトは次のとおりです: http://cisnet.baruch.cuny.edu/holowczak/classes/3400/normalization/#allinone

わからない部分は「第三正規形」

私の頭の中では、推移的な依存関係がEMPLOYEE_OFFICE_PHONE (Name, Office, Floor, Phone)次のようName->->Office|Floorに見えます。Name->->Office|Phone

著者は、表EMPLOYEE_OFFICE_PHONE (Name, Office, Floor, Phone)をEMPLOYEE_OFFICE (Name, Office, Floor)とに分割します。EMPLOYEE_PHONE (Office, Phone)

最初の私の判断から、私はまだ推移的な依存関係を見ているName->->Office|Floorので、なぜそれが 3NF にあるのかわかりません。に推移的な依存関係があると述べたのは間違っていましたName->->Office|Floorか?

推移性の理由: 機能依存関係のリストは次のとおりです。

1. 名前 -> オフィス
2. 名前 -> フロア
3. 名前 -> 電話番号
4. オフィス -> 電話
5. オフィス -> フロア (これは間違っていますか? また、その理由は?

ありがとうございます。

3NF 正規化データベースの作成に問題があります。誰でも助けてもらえますか？依存関係が見当たりません。不動産サイト用です。テーブルのフィールドは次のとおりです。

ID - タイプ - 場所 - 村 - 目的 - 価格帯 - 写真 1 - 写真 2 - 写真 3 - ステータス - プロパティ - 説明

どんな助けでも大歓迎です。

リレーションRがBCNFと3NFにあるかどうかをどのように判断しますか？

私は教科書を読んでいて、あなたが見ている主な属性は3つあると言っていますが、彼らが言っていることを理解するのに苦労しています。 FDの。

3つの属性：属性Aを持つ関係R、およびRの属性のサブセットであるXが与えられた場合、FのすべてのFDX⟶Aについて、次のステートメントのいずれかが当てはまります。

• A∈X; つまり、それは自明なFDです（∈は「Xにある」を意味します）
• Xはスーパーキーです
• AはRのキーの一部です

上位2つはBCNFに対応し、3NFには3つ目が含まれます。

スキーマの 3NF および BCNF 分解を作成しようとしています。私はアルゴリズムを見てきましたが、これを行う方法が非常に混乱しています。

最小限のカバーを次のように言ってもらいF' = {A->F, A->G, CF->A, BG->C)、その関係の候補キーを 1 つ特定した場合、それが であるとしAます。それから私は正確に何をしますか？

私は例を見てきました.1つは次のとおりです。

最小限のカバー:F′ = {A → B,B → C}

最終結果は次のとおり(AB,A → B), (BC,B → C)です。彼らはどうやってこれにたどり着いたのですか？

私はデータベースの正規化、特に3NFを理解しようとしています。

私はショップデータベースを構築していて、3NFに正規化しようとして、以下の構造を考え出しました。

以下の構造は、

• 製品ごとに複数のカテゴリが存在する場合があります
• 製品ごとに1つのstorage_location＆manufacturerのみが存在します
• 無制限のextra_fieldsがあるかもしれません

私が正しい方向に進んでいるのか、3NFの以下の構造なのか、それとも近いのか、誰か教えてもらえますか？

私が確信していない2つの主なこと：

1. テーブル内の複数の同一のPIDに対応するために、Product_categoriesの複合キーを使用するのは正しいですか？

2. 製造元とstorage_locationのプライマリProductsテーブルに外部キーを追加するだけで正しいですか？これらは製品レコードごとに1回だけ発生するためです。または、特定の製造元とstorage_location IDをプライマリProductsテーブルから削除し、次のように新しいテーブルを作成する必要があります。

   /li>

私は現在、システム分析のクラスに参加しています。正規化の使用法をよりよく理解したいと思っています。学生ID、名前、電話番号、および専攻を含むテーブルで作業していた場合の3NFの場合。学生の名前と電話番号の両方が ID でわかるので、学生 ID と専攻だけを使用する必要があります。私はこれを正しく理解していますか？