database - 实体关系图。IS A 关系如何转换为表格？

Question

我只是想知道，ER 图中的 ISA 关系如何转换为数据库中的表。

会有3张桌子吗？一份给人，一份给学生，一份给老师？

或者会有2张桌子？一个给学生，一个给老师，每个实体都有人+自己的属性？

或者是否会有一个包含所有 4 个属性的表，并且表中的某些方块为空，具体取决于该行中是学生还是教师？

注意：我忘了添加这个，但是 ISA 关系有完整的覆盖范围，所以一个人必须是学生或教师。

Answer 1

假设关系是强制性的（如您所说，一个人必须是学生或老师）并且不相交（一个人是学生或老师，但不能两者兼而有之），最好的解决方案是两张桌子，一张给学生和一个教师。

如果参与是可选的（这不是您的情况，但为了完整起见，让我们把它放在一起），那么 3 个表选项就是要走的路，一个 Person(PersonID, Name) 表，然后是另外两个将引用的表Person 表，例如 Student(PersonID, GPA)，其中 PersonID 为 PK，FK 引用 Person(PersonID)。

1 table 选项在这里可能不是最好的方法，它会产生几条空值的记录（如果一个人是学生，那么teacher-only 属性将为空，反之亦然）。

如果不相交是不同的，那么这是一个不同的故事。

Answer 2

您可以使用 4 个选项将其映射到 ER，

选项1

• 人（SIN，姓名）
• 学生（SIN，GPA）
• 老师( SIN ,Salary)

选项 2由于这是覆盖关系，因此选项 2 不是很好的匹配。

• 学生（SIN，姓名，GPA）
• 老师（SIN，姓名，薪水）

选项 3

• Person( SIN ,Name,GPA,Salary,Person_Type) 人员类型可以是学生/教师

选项 4

• Person( SIN ,Name,GPA,Salary,Student,Teacher) Student 和 Teacher 是布尔类型的字段，可以是或否，重叠的好选择

由于子类没有太多属性，因此选项 3 和选项 4 最好将其映射到 ER

Answer 3

这个答案可能是一个评论，但我把它放在这里是为了能见度。

我想解决一些选择的答案未能解决的问题 - 并可能详细说明“双表”设计的后果。

数据库的设计取决于应用程序的范围以及要执行的关系和查询的类型。例如，如果您有两种类型的用户（学生和教师），并且您有很多所有用户都可以参与的一般关系，无论他们的类型如何，那么两个表的设计最终可能会出现很多“重复”关系（就像用户可以订阅不同的时事通讯，而不是在“用户”和时事通讯之间使用一个 M2M 关系表，您需要两个单独的表来表示该关系）。如果您有三种不同类型的用户而不是两种，或者您的层次结构中有额外的 IsA 层（兼职学生与全日制学生），则此问题会变得更糟。

另一个需要考虑的问题——你想要实现的约束类型。如果您的用户有电子邮件，并且您希望在电子邮件上维护用户范围的唯一约束，那么对于两表设计的实现会更加棘手——您需要为每个唯一约束添加一个额外的表。

另一个要考虑的问题通常只是重复。如果要向用户添加新的公共字段，则需要多次执行。如果您对该公共字段有唯一约束，那么您也需要为该唯一约束创建一个新表。

所有这一切并不是说两个表设计不是正确的解决方案。根据您正在构建的关系、查询和功能的类型，您可能希望选择一种设计而不是另一种设计，就像大多数设计决策的情况一样。

Answer 4

这完全取决于关系的性质。

如果 Person 和 Student 之间的关系是 1 到 N（一对多），那么正确的方法是创建外键关系，其中 Student 有一个外键返回到 Person 的 ID 主键列。人与人之间的关系也是如此。

但是，如果关系是 M 到 N（多对多），那么您需要创建一个包含这些关系的单独表。

假设您的 ERD 使用 1 对 N 关系，您的表结构应该如下所示：

CREATE TABLE Person ( sin bigint, name text, PRIMARY KEY (sin) );

CREATE TABLE Student ( GPA float, fk_sin bigint, FOREIGN KEY (fk_sin) REFERENCES Person(sin) );

并按照教师表的相同示例。大多数情况下，这种方法将使您进入第三范式。