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

Question

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

案例研究的要求是针对 vert 诊所的:

1. 允许宠物预约预约
2. 记录宠物治疗
3. 记录哪位 vert 进行了治疗
4. 记录企业销售的商品，以提供信息，使企业能够生成从供应商处采购的库存 list

不需要:记录所有销售额

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

工作人员:

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

员工地址表:

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

vert 表:

| staff_ID | appointment_ID |

vert 护士:

| staff_ID | appointment_ID |

约会表:

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

初始约会表:

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

谢谢!

Answer 1

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

第三范式是关于没有传递函数依赖的。换句话说，如果 A 决定 B，B 不决定 A，B 决定 C，则存在传递依赖，因此 B 和 C 可以放入它们自己的表中。

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

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

编辑仔细查看并编辑后，我发现了很多要评论的东西，但由于这是一项作业，我会给你时间考虑它，并在几天或更长时间后回来再次检查它，如果你还是很好奇。

编辑 2

我会逐表给你建议，但会尽量将这些限制在正确的方向上。

staff - 没有任何传递依赖关系让我跳出来，里面的一切都由主键决定，这很好。

staff_address - 为什么有 staff_id 列？这不是一个好主意。此外 - 正如我已经提到的，您对地址具有传递依赖性。

vet 和 vet_nurse - 这些表具有完全相同的列，那么为什么有两个表？当然，您可以使用一种方法。

预约表 - 初始预约和跟进具有相同的列。同样，应该有一种方法可以使它们合二为一。我会给你一个约会表的直接建议:将日期和时间作为一列，aptDate，并赋予它 DATETIME 值类型。

patient - customer_ID 值在 patient 表中，那么为什么要在其他表中呢？此外，以前的约会和以前的治疗将很难在数据库中追踪。您应该会在开始输入数据后立即看到它。

product - 目前看来还不错，但有些问题我稍后会讨论。

product_sold - sale_ID 是否唯一？如果是，一次销售可以销售多少产品？这张表肯定没有规范化好。

supplier - 一个供应商可以有多少产品？这是关于如何更改产品表的提示。

suppliers_address - 这里的 postalCode 也有同样的问题。另外，为什么 suppliers_address 指向供应商？

inventory - 您是否已经在产品表中跟踪所有这些字段(价格除外)？

这些是我看到的潜在问题，但出于良心我不能为您的作业提供解决方案。但是，如果这是您对规范化数据库的首次尝试之一，那一点也不差。