relational-database - ER 到关系模型：当子类有自己的 PK 时会发生什么？

Question

概念模型 | 我无法找到任何具有自己 PK 的子类示例。我知道主键person_id是继承自超类，但不知道它是否与子类的PK，employee_id结合，在子类的关系模型中创建一个复合的PK。

基本上，哪个是正确的？

员工（employee_id，person_id，姓名，薪水）

或者

员工（employee_id，person_id，姓名，薪水）

假设层次结构不是强制性的。

这只是一个帮助我理解过程的简单示例，所以不要担心概念模型的优点。

score 3 · Accepted Answer

首先，正如 Jim L 所指出的，Employee是的子类型Person，而不是相反！

从概念上讲，如果对象类型 B 是 A 的子类型/子类，它会继承其属性、方法和约束，包括其唯一标识符/键，但不一定是其标准 ID（“PK”），因为 PK 是一个强制键，所以它不是一个纯粹的概念/逻辑特征，而是一个用户声明/约定。

作为约束的键是继承的，但不是 PK！

因此，即使子类型Employee继承了强制键person_id，您也不必选择它作为它的 PK。由于Employee碰巧有另一个强制密钥，employee_id您可以选择这个作为 PK（并且，正如 reaanb 所指出的，在此示例中不需要任何复合 PK）。

score 0 · Accepted Answer

复合 PK 是个坏主意 - 它允许记录具有相同 employee_id 和不同 person_id（或相同 person_id 和不同 employee_id）的多行。而是将employee_id 设置为PK 并将person_id 设置为单独的唯一键。

从概念上讲，当子类型有自己的标识时，它可以被视为与父实体集有关系的不同实体集，而不是子类型。我不会在 EER 图中使用子类型符号来表示这些情况。

最后，在讨论数据建模时，请避免使用 OOP 术语（子类化、继承）。OOP 用于在通信状态机方面分解系统，不应与分层、网络、实体关系或关系数据模型混为一谈。

2 回答 2