ER图中的超级和子类型关系如何表示为表格？

Question

ER图中的超级和子类型关系如何表示为表格？

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

“车辆”框连接到“IsA”三角形，标记为“不相交”，它分别连接到“2WD”框和“4WD”框。

这会表示为：

车辆，2WD和4WD表（2WD和4WD将指向车辆的PK）; 要么

只有2WD和4WD表（和没有车辆表），这两个表都会复制车辆所具有的任何属性？

我认为这些是写这种关系的其他方式：

“车辆”框用粗线连接到“IsA”三角形，它与细线分别连接到“2WD”框和“4WD”框。 “车辆”盒连接到“IsA”三角形，它们分别连接到“2WD”盒和“4WD”盒，全部用细线连接。

我正在寻找一个明确的解释，说明每个图表最终会有哪些表格。

Answer 1

ER表示法有几种ER符号。我不熟悉你正在使用的那个，但很明显你试图表示一个子类型（又名继承，类别，子类，泛化层次......）。这是OOP继承的关系表亲。在进行子类型分析时，您通常会关注以下设计决策：摘要与具体：父母可以实例化吗？在你的例子中：可以Vehicle存在而不是存在2WD或4WD？1包容性与排他性：可以为同一个父母实例化多个孩子吗？在你的榜样，可以Vehicle是既 2WD和4WD？2完整与不完整：您希望将来能够添加更多儿童吗？在您的示例中，您是否希望稍后可以将a Bike或Plane（etc ...）添加到数据库模型中？信息工程表示法区分包容性和排他性子类型关系。另一方面，IDEF1X表示法没有（直接）识别这种差异，但它确实区分了完整和不完整的子类型（IE没有）。从下图ERwin的方法指南（第5章，子类型关系）示出的区别：IE和IDEF1X都不能直接指定抽象与具体父级。物理表征遗憾的是，实际数据库不直接支持继承，因此您需要将此图转换为实际表。这样做通常有3种方法：将所有类放在同一个表中，并将子字段保留为NULL。然后，您可以使用CHECK来确保非NULL中的字段的正确子集。优点：没有加入，所以一些查询可以受益。可以强制执行父级别的密钥（例如，如果您想要避免不同的2WD和4WD具有相同ID的车辆）。可以轻松地强制执行包容性与独占子项以及抽象与具体父级（仅通过改变CHECK）。缺点：有些查询可能会变慢，因为它们必须过滤掉“不感兴趣”的孩子。根据您的DBMS，特定于子项的约束可能会有问题。很多NULL都会浪费存储空间。不太适合不完整的子类型 - 添加新子项需要更改现有表，这在生产环境中可能会有问题。将所有子项放在单独的表中，但没有父表的表（而是在所有子项中重复父项的字段和约束）。具有（3）的大多数特征，同时避免JOIN，以较低的可维护性（由于所有这些字段和约束重复）和无法强制执行父级键或代表具体父级的代价。将父项和子项放在单独的表中。优点：清洁。不需要人为地重复字段/约束。实施父级键并轻松添加特定于子级的约束。适合不完整的子类型（相对容易添加更多的子表）。某些查询只能通过查看“有趣的”子表来获益。缺点：有些查询可能很重要。可能难以强制执行包容性与独占子级以及抽象与具体父级（如果DBMS支持循环和延迟外键，则可以声明性地强制执行，但在应用程序级别强制执行它们通常被认为是较小的恶意）。正如您所看到的，情况并不理想 - 无论您选择何种方法，您都需要妥协。方法（3）应该是你的出发点，如果有令人信服的理由，只选择其中一种方案。1我猜这是你的图表中线条的粗细。2我猜这是你的图表中存在或不存在“不相交”的含义。