实体关系设计答案

【问题标题】：Entity Relation Design实体关系设计
【发布时间】：2013-11-18 04:24:53
【问题描述】：

我正在尝试为医院 Oracle 数据库系统实现实体关系。

我很困惑是否应该将下表分开或将它们合并为 1。

 - Supply

ItemNo (PK) , Name, ItemDescription, QuantityInStock, BackOrderLevel, CostPerUnit

 - PharmaceuticalSupply

DrugNo (PK) , Dosage, MethodOfAdmin

基本上在我的 ERD 中，我将 PharmaceuticalSupply 指向 Supply 作为一个子集，它继承了该属性但也有其他属性。我这样做有错吗？

【问题讨论】：

我会将它合并到 Supply 中，使用 Type 属性指定为 Pharmaceutical 类型，它将简化您的 sql 和应用程序代码。
确实有道理。非常感谢

标签： oracle entity-relationship oracle-sqldeveloper er-diagrams entity-relationship-model

【解决方案1】：

最终，这是一个没有正确或错误答案的设计决策，但将它们分开可能会有所帮助。例如，有许多类型的用品不是药品。如果合并表格，则可以输入没有实际意义的数据。例如，您不能使用一定剂量的绷带。单独的表格清楚地表明剂量仅适用于药品。

请注意，关于如何管理 PharmaceuticalSupply 中的 PK 和 FK，存在一些变化。它可以同时具有 ItemNo 和 DrugNo，其中 ItemNo 是外键。在这种情况下，任何一个都可以是主键，但如果 DrugNo 是主键，那么 ItemNo 可能需要是唯一索引。但是，除非由于某些自定义格式而需要 DrugNo，否则将 ItemNo 简单地用作 PK 和 FK 并完全消除 DrugNo 可能会很好。这导致了关系数据库世界喜欢提及的“专业化”。

【讨论】：

我搜索了关系数据库的“专业化”，这个概念似乎是我在制作 PharmaceuticalSupply 的子集时所想的，但现在出现了实施问题，因为在现实生活中的实施中，概念更难实现。

【解决方案2】：

这取决于您的人口。它是一个子集，为了减少冗余，向 Supply 添加一个外键。这样您就可以构建一个列出所有数据的联接。

我仍然会引入 DrugNo 键用于索引。一个项目编号可以在 PharmaceuticalSupply 表中出现多次吗？如果你这样做，那么你肯定需要 DrugNo 键。

药品供应

DrugNo (PK) , ItemNo (FK), Dosage, MethodOfAdmin

【讨论】：

嘿，会有手术用品、非手术用品和药物用品。理想情况下，药品供应应该有自己的桌子。