弱实体集是由父实体集的主键部分标识的实体集。弱实体集的存在必然依赖其父实体集（我们说它完全参与了它的标识关系），但并非所有具有存在依赖关系的东西都是弱实体集。常规实体集也可以完全参与一个或多个关系。因此，这取决于您如何识别实体集。另请参阅我对“is optionality (mandatory, optional) and participation (total, partial) are same?”问题的回答
由其自身属性唯一标识的实体集是常规实体集。由父实体集的主键部分标识的实体集是弱实体集。由父实体集的主键完全标识的实体集是子类型。
您还应该注意，根据 Chen 所描述的实体关系模型，弱实体集只能有一个父实体集。由多个父实体集标识将使其成为关系而不是实体集。
在某些架构设计工具中，使用了不同的解释，其中表等同于实体集，关系等同于 FK 约束，并且标识关系是作为表 PK 一部分的 FK。尽管采用了 ER 的大部分术语，但这种方法比实体关系模型更接近网络数据模型。
让我们看看你的例子：
在示例 1 中，我们应该考虑 treatment-id 是单独识别（即代理键）还是仅与 doctor-id 和 patient-id 组合识别（即序数）。如果它是代理键，那么在 PK 中包含 doctor-id 和 patient-id 将是错误的，示例 2 将是正确的处理方式。如果它是一个序数，那么它与示例 3 基本相同 - 两个外部实体键和一个在主键中设置的值。我将在示例 3 的 cmets 中对此进行更多说明。
在示例 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 列！这很快就会变得不方便，但另一方面，如果关联是由代理键标识的，那么这些列是相关的相关信息，否则需要从连接的表中检索这些信息。
抱歉，答案很长，但我希望这涵盖了所有要点。如果您有任何问题，请告诉我。