我只是想知道，ER 图中的 ISA 关系如何转换为数据库中的表。
会有 3 张桌子吗？一份给个人，一份给学生，一份给老师？
或者会有 2 张桌子吗？一个给学生，一个给老师，每个实体都有人+自己的属性？
或者是否会有一个包含所有 4 个属性的表，并且表中的某些方格为空，具体取决于该行中是学生还是教师？
注意：我忘记添加了，但 ISA 关系已全面涵盖，因此一个人必须是学生或教师。
【问题讨论】：
标签： database entity-relationship
假设关系是强制性的（如您所说，一个人必须是学生或老师）并且不相交（一个人要么是学生要么是老师，但不能同时是两者），那么最好的解决方案是两张桌子，一张给学生，一张给老师。
如果参与是可选的（这不是您的情况，但为了完整起见，让我们把它放在一边），那么 3 个表选项就是要走的路，一个 Person(PersonID, Name) 表，然后是另外两个表这将引用 Person 表，例如 Student(PersonID, GPA)，PersonID 为 PK，FK 引用 Person(PersonID)。
1 table 选项可能不是这里最好的方法，它会产生几条空值的记录（如果一个人是学生，那么teacher-only 属性将为空，反之亦然）。
如果不相交的地方不同，那就另当别论了。
【讨论】：
您可以使用 4 个选项将其映射到 ER，
选项 1
选项2由于这是覆盖关系，所以选项2不是很好的匹配。
选项 3
选项 4
由于子类没有太多属性，所以选项 3 和选项 4 最好将其映射到 ER 中
【讨论】：
这个答案可能是一个评论，但我把它放在这里是为了可见性。
我想解决所选答案未能解决的一些问题 - 并且可能会详细说明“双表”设计的后果。
数据库的设计取决于应用程序的范围以及要执行的关系和查询的类型。例如，如果您有两种类型的用户（学生和教师），并且您有很多所有用户都可以参与的一般关系，无论他们的类型如何，那么两个表设计最终可能会出现很多“重复”关系（就像用户可以订阅不同的时事通讯，而不是在“用户”和时事通讯之间使用一个 M2M 关系表，您需要两个单独的表来表示该关系）。如果您拥有三种不同类型的用户而不是两种，或者您的层次结构中有额外的 IsA 层（兼职学生与全日制学生），则此问题会变得更糟。
另一个需要考虑的问题 - 您要实施的约束类型。如果您的用户有电子邮件，并且您希望在电子邮件上维护用户范围的唯一约束，那么对于两表设计的实现会更加棘手 - 您需要为每个唯一约束添加一个 extra table。
另一个需要考虑的问题通常是重复。如果要向用户添加新的公共字段，则需要多次执行。如果您对该公共字段有唯一约束，那么您也需要一个新表来处理该唯一约束。
所有这些并不是说两个表设计不是正确的解决方案。根据您正在构建的关系、查询和功能的类型，您可能希望选择一种设计而不是另一种，就像大多数设计决策的情况一样。
【讨论】：
这完全取决于关系的性质。
如果 Person 和 Student 之间的关系是 1 到 N（一对多），那么正确的方法是创建外键关系，其中 Student 有一个外键返回到 Person 的 ID Primary Key Column .人与人之间的关系也是如此。
但是，如果关系是 M 到 N（多对多），那么您需要创建一个包含这些关系的单独表。
假设您的 ERD 使用 1 对 N 关系，您的表结构应该如下所示：
创建表人 ( 大罪， 名称文本， 主键（罪） );
创建表学生 ( GPA浮动， fk_sin bigint, 外键 (fk_sin) 参考人 (sin) );
并按照教师表的相同示例进行操作。大多数情况下，这种方法会让你进入第三范式。
【讨论】：
Person到Student的关系中，不会有1到N，也没有M到N，但总是1到0..1