实体关系图。 IS A关系如何转化为表格？

Question

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

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

或者会有2张桌子吗？一个用于学生，一个用于教师，每个实体都具有人+属性的属性？

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

注意：我忘记添加此内容，但ISA关系完全覆盖，因此一个人必须是学生或教师。

Answer 1

假设这种关系是强制性的（如你所说，一个人 是学生或教师）并且脱节（一个人是学生或教师，但不是两者），最佳解决方案是2个表，一个用于学生，一个用于教师。

如果参与是可选的（这不是你的情况，但让我们把它说成是完整的），那么3表选项就是可行的方式，有一个Person（PersonID，Name）表，然后是另外两个表它将引用Person表，例如 学生（PersonID，GPA），PersonID为PK，FK引用Person（PersonID）。

1表选项可能不是这里最好的方法，它会产生几个具有空值的记录（如果一个人是学生，只有教师的属性将为null，反之亦然）。

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

Answer 2

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

选项1

• 人（ SIN ，姓名）
• 学生（的 SIN 下，GPA）
• 教师（的 SIN 下，薪水）

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

• 学生（的 SIN 下，名称，GPA）
• 教师（的 SIN 下，名称，职位）

选项3

• 人（的 SIN 下，名称，GPA，工资，Person_Type）     人类型可以是学生/老师

选项4

• 人（ SIN ，姓名，GPA，薪水，学生，教师）学生和教师是bool类型字段，可以是是或否，是重叠的好选择

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

Answer 3

这个答案本来可以是评论，但我将其放在此处以提高可见度。

我想谈谈选择的答案无法解决的一些问题，也许还要详细说明“两张桌子”设计的后果。

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

要考虑的另一个问题-您要实现的约束类型。如果您的用户有电子邮件，并且您希望在用户范围内维护电子邮件的唯一性约束，那么对于两表设计而言，实现起来会比较棘手-您需要为每个唯一性约束添加一个extra table。

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

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

Answer 4

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

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

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

假设你的ERD使用1到N的关系，你的表结构应该是这样的：

创建表人员 （ 罪恶， 姓名文字， 主要钥匙（罪） ）;

CREATE TABLE学生 （ GPA浮动， fk_sin bigint， FOREIGN KEY（fk_sin）REFERENCES人（罪） ）;

并按照教师表的相同示例进行操作。这种方法大多数时候都会让你达到第三范式。