4

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

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

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

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

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

スタッフ：

| staff_ID | firstName | lastName | gender | address_ID | contactNumber | partTimeOrFullTime | salary |

スタッフの住所表:

| address_ID | staff_ID | number | street | city | county | postalCode |

獣医テーブル:

| staff_ID | appointment_ID |

vet_nurse:

| staff_ID | appointment_ID |

予約表：

| appointment_ID | customer_ID | staff_ID | patient_ID | date | time |

initial_appointment テーブル:

| appointment_ID | customer_ID | patient_ID | diagnosis | treatment |

フォローアップ予定:

| appointment_ID | customer_ID | patient_ID | diagnosis | treatment |

忍耐強い：

| patient_ID | customer_ID | animal_type | gender | weight | height | previous_Appointments | previous_Treatment |

製品：

| product_ID | name | product_Category | animal | price | quantity_Available | reOrder_Level |

product_sold:

| sale_ID | product_ID | sale_Date |

サプライヤー：

| supplier_ID | product_ID | contactNumber | email |

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

| supplierAddress_ID | supplier_ID | doorNumber | street | city | town | postalCode |

在庫：

| name | product_ID | quantity_Available | price |

ありがとう！

4

1 に答える 1

1

2 つの理由から、正確な回答は差し控えさせていただきます。そこで、言いました。2) 何も学べない。

第 3 正規形とは、推移的な機能依存関係がないことです。つまり、A が B を決定し、B が A を決定せず、B が C を決定する場合、推移的な依存関係があるため、B と C をそれぞれのテーブルに入れることができます。

セットの例として、都市、州、および郵便番号を含むテーブルが考えられます。実際の状況では、郵便番号を使用して市と州を判別できます。おそらく、zipcode をキーとし、city と state が他の 2 つの属性である別のテーブルを持つことができます。私が言ったように、住所 ID -> 郵便番号および郵便番号 -> 都市、州であるため、これは推移的な依存関係になる可能性があります。

覚えておくべきもう 1 つの重要な点: 事実が 2 回出現する場合は、さらに正規化できます。たとえば、[city A, State B, ZipCode C] は複数回表示される可能性があります。同じ地域に複数の人がいると確信しているからです。

編集 これを見て編集した後、コメントすべきことがたくさん見つかりましたが、これは課題であるため、考える時間を与えて、数日またはそれ以上後に戻ってきて、もう一度やり直してください。あなたはまだ興味があります。

編集2

表ごとに提案をしますが、これらを正しい方向に押し進めるだけに制限しようとします.

staff-私に飛び出す推移的な依存関係はありません。そこにあるものはすべて主キーによって決定されます。これは良いことです。

staff_address- なぜ staff_id 列があるのですか? これは良い考えではありません。さらに、すでに述べたように、アドレスには推移的な依存関係があります。

vet and vet_nurse- これらのテーブルにはまったく同じ列があるのに、なぜ 2 つのテーブルがあるのですか? 確かに使い道はあります。

appointment tables- 初回予約とフォローアップの列は同じです。繰り返しますが、それらを 1 つにする方法があるはずです。アポイントメント テーブルについて 1 つの直接的な提案をします。日付と時刻を 1 つの列 aptDate として配置し、それに DATETIME 値型を指定します。

patient- customer_ID 値は患者テーブルにあるのに、なぜ他のテーブルにある必要があるのでしょうか? また、以前の予定と以前の治療をデータベース内で追跡することは非常に困難になります。データの入力を開始するとすぐに表示されるはずです。

product- 今のままでは悪くないように見えますが、後で説明する問題があります。

product_sold- sale_ID は一意ですか? ある場合、1回の販売で何個の製品を販売できますか? このテーブルは明らかに正規化されていません。

supplier- サプライヤーはいくつの製品を持つことができますか? これは、製品テーブルを変更する方法のヒントです。

suppliers_address- ここの郵便番号と同じ問題。また、suppliers_address がサプライヤーを指すのはなぜですか?

inventory- 製品テーブルのこれらすべてのフィールド (価格を除く) を既に追跡していませんか?

これらは潜在的な問題だと思いますが、あなたの課題に対する解決策を良心的に教えることはできません。ただし、これが正規化されたデータベースでの最初の試みの 1 つである場合は、まったく悪くありません。

于 2014-11-06T14:46:07.657 に答える