database - ER 图中的父类(super class)型和子类型关系如何表示为表格？

Question

我正在学习如何将实体关系图解释为 SQL DDL 语句，但我对符号的差异感到困惑。考虑如下图所示的不相交关系:



这是否可以表示为:

Vehicle, 2WD 和 4WD 表(2WD 和 4WD 将指向 Vehicle 的 PK)；或

只有 2WD 和 4WD 表(和 NO Vehicle 表)，这两个表都会复制 Vehicle 具有的任何属性？

我认为这些是书写关系的其他方式:




我正在寻找关于您最终为每个图表生成哪些表格的差异的明确解释。

Answer 1

ER 符号

有几种 ER 符号。我不熟悉您正在使用的那个，但很明显您正在尝试表示一个子类型(又名继承、类别、子类、泛化层次结构......)。这是 OOP 继承的关系表亲。

在进行子类型化时，您通常会关注以下设计决策:

抽象与具体:可以实例化父级吗？在您的示例中:可以是 Vehicle存在但不存在 2WD或 4WD ?1

包容与独占:可以为同一个父级实例化多个子级吗？在您的示例中，可以 Vehicle两者都是2WD和 4WD ?2

完整与不完整:你期待 future 加入更多的 child 吗？在您的示例中，您是否期望 Bike或 Plane (等等...)以后可以添加到数据库模型中吗？

信息工程符号区分包含和排他的子类型关系。另一方面，IDEF1X 符号不(直接)识别这种差异，但它确实区分了完整和不完整的子类型(IE 没有)。

下图来自 ERwin Methods Guide (第 5 章，子类型关系)说明了区别:



IE 和 IDEF1X 都不允许直接指定抽象与具体父级。

物理表现

不幸的是，实际数据库不直接支持继承，因此您需要将此图转换为实际表。这样做通常有3种方法:

将所有类放在同一个表中，并将子字段保留为 NULL。然后，您可以进行 CHECK 以确保非 NULL 字段的正确子集。

优点:没有 JOINing，所以一些查询可以受益。可以强制执行父级 key (例如，如果您想避免具有相同 ID 的不同 2WD 和 4WD 车辆)。可以轻松地强制执行包容性与排他性子级以及抽象与具体父级(只需更改 CHECK)。

缺点:某些查询可能会较慢，因为它们必须过滤掉“无趣”的子项。根据您的 DBMS，特定于 child 的约束可能会出现问题。大量 NULL 会浪费存储空间。不太适合不完整的子类型 - 添加新子项需要更改现有表，这在生产环境中可能会出现问题。

将所有子项放在单独的表中，但没有父项的表(相反，在所有子项中重复父项的字段和约束)。具有 (3) 的大部分特征，同时避免 JOIN，但代价是可维护性较低(由于所有这些字段和约束重复)以及无法强制执行父级键或表示具体的父级。

将 parent 和 child 放在不同的表中。

优点:干净。不需要人为地重复字段/约束。强制执行父级键并轻松添加特定于子级的约束。适用于不完整的子类型(相对容易添加更多子表)。某些查询可以通过只查看“有趣的”子表而受益。

缺点:一些查询可能是 JOIN-heavy 的。可能难以强制执行包含与独占子项以及抽象与具体父项(如果 DBMS 支持循环和延迟外键，则可以声明性地强制执行，但在应用程序级别强制执行它们通常被认为是较小的邪恶)。

如您所见，情况并不理想 - 无论您选择哪种方法，您都需要做出妥协。方法 (3) 可能应该是您的起点，并且仅在有令人信服的理由时才选择其中一种替代方法。

1 我猜这就是图中线条的粗细。

2 我猜这就是您的图表中“不相交”的存在或不存在的含义。