很明显,这两个概念并不总是被认为是等价的,但
与此相同(如果更简洁)?
忽略了我将发动机输入到电机的事实,如果它们不相同,那么上述两个图表有何区别?
编辑:我希望能更详细地阐述IsA图中的'包含'关系;它有效吗?这两个图(粗略地)是否都评估为相同的关系模式?如果做出大胆的假设,即垫圈和引擎不包含任何不相交的属性,那么生成的表似乎只会有一列(枚举的“类型”列)不同。
答案 0 :(得分:3)
第一张图说明了Has-a关系。零件包含其他零件。发动机包含许多零件,其中一些是垫圈。
第二张图说明了Is-a关系。零件可以是发动机,也可以是垫圈,也可以是很多其他东西。
在抽象ER建模的世界中,Is-a关系以Generalization-Specialization的名称命名。我说的是“抽象的ER建模”,因为很多ER图确实描绘了一个关系模型,无论它看起来如何。
当你从ER模型切换到关系模型时,事情开始变得有趣。
Has-a关系很容易在关系术语中建模。这实际上是关系建模101.你在一边引用主键的许多方面放了一个外键,你已经完成了。
Is-a关系不容易在关系术语中建模。在对象建模中,这实际上是对象建模101.您只需使用类和子类(有时称为类型和子类型),对象建模的继承功能为您完成所有繁重工作。
在关系建模中,事情并非如此简单。有一些众所周知的技术来处理这种情况,但这些技术经常在关系建模的教程中跳过。有关这些技术之一的详细信息,我将在此标记下引用您的标记wiki:class-table-inheritance。
你会认为ORM工具会在这个领域大放异彩,但似乎他们没有。
编辑:有一点需要再次强调:ER建模和表格设计不是同一个活动。一个人没有设计构成主题的实体和关系。人们通过研究主题,或者通过采访主题专家来发现实体和关系。然后,设计表作为描述先前发现的实体和关系的所有数据值的便利容器。
在现实生活中,这可能是一个反复的过程。
现在让我们转向两个可能的表格设计来覆盖你的第二个图表。
第一种设计是4-Table设计。将有四个表:零件,电机,垫片和Motor_Gasket。四个主键是PartID,MotorID,GasketID和(MotorID,GasketID)复合主键。
不会通过自动编号填充MotorID。相反,应用程序将提供刚包含新电机时生成的PartID的副本。然后MotorID执行双重任务:它在自己的表中充当PK,并且还充当引用PartID的FK。
GasketID得到了类似的处理方式。电机和垫圈常用的属性位于“零件”表中的列中。其他属性适当地放在Motor表或Gasket表中。
Motor_Gasket表有两列:MotorId和GasketID。这些是引用适当表格的FK。该表的PK是整行。
现在Motor_Gasket表实现了Contains关系。 PartID与MotorID或GasketID之间的值的“继承”实现了“IS-A”关系。
另一种设计是两桌设计。
有两个表:Part和Motor_Gasket。
每个电机和每个垫圈都会在零件表中占据一排。将有一个名为PartType的列指定它是什么类型的部件。描述电机或垫片的所有属性都在Part表中。不适用的空格设置为NULL。
Motor_Gasket表与前面的列完全相同,只是两个列引用了Part表(不同的行)。
这两种设计中哪一种更好?这取决于手头的情况。