ERD中的弱实体

Question

我有以下问题，我有多个可能是对或错的场景，我已经搜索了一段时间了，但我没有找到具体的解决方案：

医生诊所的例子：

我们有医生，病人，治疗，治疗型。

医生：id，名字..。

病人：id，姓名..。

治疗：日期、费用

Treatment-Type: id，名称

医生可以做多种治疗，病人也可以做多种治疗，因此它们与治疗与(1-N)关系有关。

治疗实体是一个弱实体，因为它不能在没有医生或病人的情况下定义，所以我的问题是，当我们将这个ERD转换成实际的表时，哪个是正确的(还是场景？)

1-医生-id，病人-id不能唯一定义治疗表，所以我们在治疗表中添加了治疗-id字段，并且PK是(医生-id，病人-id，治疗-id)。

我们添加了处理-id字段，并且PK是(处理-id)。

3- PK将是(医生身份，病人身份，日期).

我很难找到“日期”是否可以是PK的一部分，如果我能够为弱实体创建一个唯一的ID，我也很挣扎。

提前谢谢。

Answer 1

弱实体集是由父实体集的主键部分标识的实体集。弱实体集必然依赖于其父实体集的存在(我们说它完全参与了它的标识关系)，但并不是所有具有存在依赖关系的事物都是弱实体集。常规实体集也可以完全参与一个或多个关系。因此，这取决于您如何识别一个实体集。也见我对"is optionality (mandatory, optional) and participation (total, partial) are same?“问题的回答

由自身属性唯一标识的实体集是一个常规实体集。由父实体集的主键部分标识的实体集是弱实体集。由父实体集的主键完全标识的实体集是子类型。

您还应该注意到，弱实体集只能有一个父实体集，根据实体关系模型，正如Chen所描述的那样。由多个父实体集标识将使其成为关系而不是实体集。

在某些模式设计工具中，使用了不同的解释，其中表等同于实体集，关系等同于FK约束，标识关系将是表PK的一部分。这种方法更接近于网络数据模型，而不是实体-关系模型，尽管使用了ER的许多术语。

让我们来看看你的例子：

在示例1中，我们应该考虑treatment-id是单独标识(即代理键)还是只与doctor-id和patient-id (即序号)结合使用。如果它是一个代理键，在PK中包含doctor-id和patient-id将是一个错误，示例2将是正确的处理方法。如果它是序数，那么它基本上与示例3相同--两个外部实体键和一个主键中设置的值。我将在我对示例3的评论中更详细地说明这一点。

在示例2中，treatment-id是一个代理键，这意味着Treatment是一个规则的实体集，它完全参与了它与Patient和Doctor的关系。这将是我推荐的解决方案，因为这是最简单的。

在示例3中，您有一个主键，它由两个外部实体键和一个值集组成。

实体关系模型不包括这种关系--使用单个实体键的关系称为实体关系，与多个实体键的关系称为关系关系。值集仅描述为属性的馀域，而不是域。ER模型无法处理任意关系是实体集与值集以及属性与关系之间人为区分的结果。其他数据建模学科，如关系模型和对象角色建模已经完成，可以处理任何类型的关系。

回到示例3，尽管ER模型存在缺陷，在实际数据库中创建这样的表/关系并不是无效的。然而，想想主要的关键是什么--患者每天只能从同一位医生那里接受一次治疗吗？我认为多个治疗应该是可能的，在这种情况下，您可能需要添加另一个序号，例如(doctor-id, patient-id, date, treatment-id)。在这种情况下，只执行(doctor-id, patient-id, treatment-id)可能更简单。

反对这种复合/自然键的一个论点是，它们加起来--两个关系之间的多到多关联，每个主键中有3列，主键中最多可以有6列！这很快就变得不方便了，但是另一方面，这些列是相关的相关信息，如果关联是由代理键标识的，则需要从连接的表中检索这些信息。

很抱歉给出了很长的答案，但我希望这能涵盖所有的细节。如果你有任何问题，请告诉我。