我有以下问题，我有多个可能对或错的场景，我已经搜索了一段时间，但我没有找到针对我的问题的具体答案：
医生诊所示例：
我们有医生，病人，治疗，治疗类型
医生：身份证、姓名……
患者：身份证、姓名……
治疗：日期，费用
治疗- 类型：身份证，姓名
Doctor可以做多次治疗，Patient也可以做多次治疗，所以它们与Treatment with(1-N)关系相连。
治疗实体是一个弱实体，因为它不能在没有医生或患者的情况下定义，所以我的问题是，当我们将此 ERD 转换为实际表时，哪种情况是正确的（或最佳实践）？
1 -医生id, 病人id不能唯一定义Treatment 表，所以我们在Treatment表中添加treatment-id字段，PK 为（医生id, 病人id, 治疗id）。
2 - 我们添加了treatment-id字段，PK 是( treatment-id )。
3 - PK 将是（医生 ID、患者 ID、日期）。
我很难找到“日期”是否可以成为 PK 的一部分，并且我也很难为弱实体创建一个唯一 ID
提前致谢。
弱实体集是由父实体集的主键部分标识的实体集。弱实体集必然依赖其父实体集才能存在（我们说它完全参与了它的标识关系），但并非所有具有存在依赖关系的东西都是弱实体集。常规实体集也可以完全参与一个或多个关系。因此，这取决于您如何识别实体集。另请参阅我对问题的回答“可选性（强制、可选）和参与（全部、部分）是否相同？ ”
由自身属性唯一标识的实体集是常规实体集。由父实体集的主键部分标识的实体集是弱实体集。由父实体集的主键完全标识的实体集是子类型。
您还应该注意，根据 Chen 所描述的实体关系模型，弱实体集只能有一个父实体集。由多个父实体集标识将使其成为关系而不是实体集。
在某些模式设计工具中，使用不同的解释，其中表等同于实体集，关系等同于 FK 约束，并且标识关系将是作为表的 PK 一部分的 FK。尽管采用了 ER 的大部分术语，但这种方法比实体关系模型更接近网络数据模型。
让我们看一下您的示例：
在示例 1 中，我们应该考虑treatment-id是单独识别（即代理键）还是仅与doctor-idand组合patient-id（即序数）。如果它是代理键，那么在 PK 中包含doctor-idand将是错误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 列！这很快就会变得不方便，但另一方面，如果关联是由代理键标识的，那么这些列是相关的相关信息，否则需要从连接的表中检索这些信息。
很抱歉，答案很长，但我希望这涵盖了所有要点。如果您有任何问题，请告诉我。