我有以下问题，我有多个可能是对或错的情况，我已经搜索了一段时间，我没有找到我的问题的具体答案：
医生诊所示例：
我们有医生，患者，治疗，治疗型
医生：id，name ....
患者：id，name ...
治疗：日期，费用
治疗 -Type：id，name
医生可以做多种治疗，患者也可以进行多种治疗，因此它们与治疗有关（1-N）。
治疗实体是一个弱实体，因为它不能在没有医生或患者的情况下定义，所以我的问题是，当我们将这个ERD转换为实际表格时，这是正确（或最佳实践）方案？
1 - doctor-id，patient-id 无法唯一定义治疗表，因此我们将治疗表添加到治疗表中字段，PK是（ doctor-id，patient-id，treatment-id ）。
2 - 我们添加 treatment-id 字段，PK为（ treatment-id ）。
3 - PK将是（ doctor-id，患者身份，日期）。
我很难找到'date'是否可以成为PK的一部分，而且如果我可以为弱实体创建一个唯一的ID，我也很挣扎
提前致谢。
答案 0 :(得分：1)
弱实体集是由父实体集的主键部分标识的实体集。弱实体集必然依赖于其存在的父实体集（我们说它完全参与其识别关系），但并非具有存在依赖性的所有东西都是弱实体集。常规实体集也可以完全参与一个或多个关系。因此，这取决于您如何识别实体集。另请参阅我对问题的回答＆＃34; is optionality (mandatory, optional) and participation (total, partial) are same?＆＃34;
由其自己的属性唯一标识的实体集是常规实体集。由父实体集的主键部分地标识的实体集是弱实体集。由父实体集的主键完全标识的实体集是子类型。
您还应该注意，弱实体集只能根据Chen描述的实体关系模型设置一个父实体。由多个父实体集标识将使其成为关系而不是实体集。
在一些模式设计工具中，使用不同的解释，其中表等同于实体集，并且关系等同于FK约束，并且标识关系将是作为表的PK的一部分的FK。尽管采用了大量的ER术语，这种方法比实体关系模型更接近网络数据模型。
让我们来看看你的例子：
在示例1中，我们应该考虑treatment-id是自己识别（即代理键）还是仅与doctor-id和patient-id（即序数）组合。如果它是代理密钥，那么在PK中包含doctor-id和patient-id将是错误的，示例2将是处理它的正确方法。如果它是序数，那么它与例3基本相同 - 两个外国实体键和一个主键中设置的值。我将在对示例3的评论中对此进行更多说明。
在示例2中，treatment-id是代理键，这意味着Treatment是一个常规实体集，完全参与其与Patient和Doctor的关系。这是我推荐的解决方案，因为它是最简单的。
在示例3中，您有一个主键，包含两个外部实体键和一个值集。
实体 - 关系模型并不涵盖这种关系 - 与单个实体键的关系称为实体关系，与多个实体键的关系称为关系关系。值集仅被描述为属性的codomains，而不是域。 ER模型无法处理任意关系是实体集与值集之间以及属性与关系之间的人为区分的结果。其他数据建模规则如关系模型和对象角色建模是完整的，可以处理任何类型的关系。
回到示例3，尽管存在ER模型的缺点，但在实际数据库中创建这样的表/关系并不是无效的。但是，想一想主要关键是什么 - 患者每天只能从同一位医生那里接受一次治疗吗？我认为应该可以进行多种处理，在这种情况下，您可能需要添加另一个序数，例如(doctor-id, patient-id, date, treatment-id)。在这种情况下，执行(doctor-id, patient-id, treatment-id)可能更简单。
反对这种复合/自然键的一个论点是它们加起来 - 两个关系之间的多对多关联，每个关系在主键中有3列，在其主键中最多可以有6列！这很快就会变得不方便，但另一方面，这些列是相关的相关信息，如果通过代理键识别关联，则需要从连接表中检索这些信息。
很抱歉答案很长，但我希望这涵盖了所有的优点。如果您有任何问题，请告诉我。