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

Question

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

这会表示为:

1. 车辆,2WD和4WD表(2WD和4WD将指向车辆的PK); 要么
2. 只有2WD和4WD表(和没有车辆表),这两个表都会复制车辆所具有的任何属性？

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

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

Answer 1

ER表示法

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

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

• 摘要与具体:父母可以实例化吗？在你的例子中:可以Vehicle存在而不是存在2WD或4WD？¹
• 包容性与排他性:可以为同一个父母实例化多个孩子吗？在你的榜样,可以Vehicle是既 2WD和4WD？²
• 完整与不完整:您希望将来添加更多儿童吗？在您的示例中,您是否希望稍后可以将a Bike或Plane(etc ...)添加到数据库模型中？

信息工程表示法区分包容性和排他性子类型关系.另一方面,IDEF1X表示法没有(直接)识别这种差异,但它确实区分了完整和不完整的子类型(IE没有).

从下图ERwin的方法指南(第5章,子类型关系)示出的区别:

IE和IDEF1X都不能直接指定抽象与具体父级.

物理表征

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

1. 将所有类放在同一个表中,并将子字段保留为NULL.然后,您可以使用CHECK来确保非NULL中的字段的正确子集.
   • 优点:没有加入,所以一些查询可以受益.可以强制执行父级别的密钥(例如,如果您想要避免不同的2WD和4WD具有相同ID的车辆).可以轻松地强制执行包容性与独占子项以及抽象与具体父级(仅通过改变CHECK).
   • 缺点:有些查询可能会变慢,因为它们必须过滤掉"不感兴趣"的孩子.根据您的DBMS,特定于子项的约束可能会有问题.很多NULL都会浪费存储空间.不太适合不完整的子类型 - 添加新子项需要更改现有表,这在生产环境中可能会有问题.
2. 将所有子项放在单独的表中,但没有父表的表(而是在所有子项中重复父项的字段和约束).具有(3)的大多数特征,同时避免JOIN,以较低的可维护性(由于所有这些字段和约束重复)和无法强制执行父级键或代表具体父级的代价.
3. 将父项和子项放在单独的表中.
   • 优点:清洁.不需要人为地重复字段/约束.实施父级键并轻松添加特定于子级的约束.适合不完整的子类型(相对容易添加更多的子表).某些查询只能通过查看"有趣的"子表来获益.
   • 缺点:有些查询可能很重要.可能难以强制执行包容性与独占子级以及抽象与具体父级(如果DBMS支持循环和延迟外键,则可以声明性地强制执行,但在应用程序级别强制执行它们通常被认为是较小的恶意).

正如您所看到的,情况并不理想 - 无论您选择何种方法,您都需要妥协.方法(3)应该是你的出发点,如果有令人信服的理由,只选择其中一种方案.

¹我猜这是你的图表中线条的粗细.

²我猜这是你的图表中存在或不存在"不相交"的含义.