如何将这些表标准化为 3NF

Question

作为家庭作业的一部分，我被要求根据案例研究创建表格，并且所有表格都必须符合 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 |

兽医护士：

| staff_ID | appointment_ID |

约会表：

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

initial_appointment 表：

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

供应商地址：

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

库存：

| name | product_ID | quantity_Available | price |

谢谢！

Answer 1

我不会给你一个确切的答案有两个原因：1）我懒得过滤所有的文本。在那里，我说了算。 2) 你不会学到任何东西。

第三范式是关于没有传递函数依赖。换句话说，如果 A 确定 B，其中 B 不确定 A，而 B 确定 C，则您具有传递依赖关系，因此 B 和 C 可以放在自己的表中。

您的集合中的一个示例可能是带有城市、州和邮政编码的表格。在现实世界的情况下，邮政编码可用于确定城市和州。也许您可以有一个单独的表，其中 zipcode 作为键，而 city 和 state 是另外两个属性。这可能是一个传递依赖，因为地址 ID -> 邮政编码和邮政编码 -> 城市，正如我所说的那样。

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

编辑 在查看并编辑它之后，我发现了更多要评论的东西，但由于这是一项任务，我会给你时间考虑它并在几天或更长时间后再回来重新审视它，如果你'仍然很好奇。

编辑 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 - 这里的邮政编码问题相同。另外，为什么supplier_address 指向供应商？

inventory - 您不是已经在产品表中跟踪所有这些字段（价格除外）吗？

这些是我看到的潜在问题，但我不能凭良心为您的任务提供解决方案。但是，如果这是您对规范化数据库的第一次尝试，那也不错。