如何将这些表规范化为3NF

时间:2014-11-06 14:29:57

标签: mysql database normalization normalize 3nf

作为家庭作业的一部分,我被要求根据案例研究创建表格,所有表格必须为3NF。然而,我已经尝试过并试图了解3NF,但我只是没有掌握它,并希望得到一些帮助。

案例研究的要求适用于兽医诊所:

  1. 允许宠物预约约会
  2. 记录宠物治疗
  3. 记录哪位兽医进行了治疗
  4. 记录商家出售的商品,以提供允许商家生产供从供应商处购买的库存清单的信息
  5. 有需要:记录所有销售额

    到目前为止,我有以下表格:

    人员:

    | 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 table:

    | appointment_ID | customer_ID | patient_ID | diagnosis | treatment |
    

    followUp_appointment:

    | 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 |
    

    suppliers_address:

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

    清单:

    | name | product_ID | quantity_Available | price |
    

    谢谢!

1 个答案:

答案 0 :(得分:1)

由于以下两个原因,我不会给你一个确切的答案:1)我懒得过滤所有文字。在那里,我说了。 2)你不会学到任何东西。

第三种正常形式是关于没有传递函数依赖性。换句话说,如果A确定B,其中B不确定A,而B确定C,则您具有传递依赖性,因此B和C可以放入它们自己的表中。

您的集合中的示例可以是包含城市,州和邮政编码的表格。在现实世界中,zipcode可用于确定城市和州。也许你可以有一个单独的表,其中包含zipcode,而city和state是另外两个属性。这可以是传递依赖,因为地址ID - >邮政编码和邮编 - >我所说的城市。

要记住的另一个重要事项:如果任何事实出现两次,您可以更正常化。例如,[city A,State B,ZipCode C]可能会出现多次,因为我确定你有多个来自同一地区的人。

修改 看完这个并编辑后我发现了更多要评论的内容,但由于这是一项任务,我会给你时间思考它,并在几天或更长时间内回来重新审视它,如果你和#39;仍然很好奇。

编辑2

我会逐桌给你建议,但会尝试限制这些建议只是朝着正确的方向推进。

staff - 没有可传递的依赖关系跳到我这里,其中的所有内容都由主键确定,这很好。

staff_address - 为什么你有一个staff_id专栏?这不是一个好主意。另外 - 你已经提到了地址的传递依赖性。

vet and vet_nurse - 这些表具有完全相同的列,为什么有两个表?当然有一种方法可以使用。

appointment tables - 初始约会和跟进具有相同的列。同样,应该有一种方法可以让它们成为一体。我将给你一个关于约会表的直接建议:把日期和时间作为一列aptDate,并给它DATETIME值类型。

patient - customer_ID值在患者表中,那么为什么它应该在其他人中呢?此外,以前的约会和以前的治疗将很难在数据库内跟踪。一旦开始输入数据,您应该会看到它。

product - 就像现在一样,它看起来并不太糟糕,但我稍后会讨论一些问题。

product_sold - sale_ID是否与众不同?如果是,一次销售中可以销售多少产品?这张表肯定没有正常化。

supplier - 供应商可以生产多少种产品?这是您如何更改产品表的提示。

suppliers_address - 与postalCode相同的问题。另外,为什么suppliers_address指向供应商?

inventory - 你还在跟踪产品表中的所有这些字段(价格除外)吗?

这些是我看到的潜在问题,但我不能凭良心为您提供解决方案。但是,如果这是您在标准化数据库中的第一次尝试,那就完全不错了。