具有子类型的复合主键表

Question

我和一个数据库架构师争论的问题是，如果一个带有子类型的复合主键的表在关系上有意义，并且这是一个好习惯。

假设我们有两个表Employee和Project。我们创建一个复合表Employee_Project，其中一个复合主键返回Employee和Project。

Employee_Project是否有一种有效的方式来获得子类型？或者您能想到复合键表可以具有子类型的任何场景吗？

对我来说，复合键关系是'Is A'关系（Employee_Project是一个Employee和一个Project）。子类型也是'是A'的关系。所以，如果你有一个带有子类型的复合键，它在一个句子中就有两个'是A'的关系，这让我觉得这是一个不好的做法。

Answer 1

员工项目有点困难，但人们可以想象这样的事情 - 虽然我不是化学家。

或类似的东西，这需要不同的法律形式（领域）单人所有权与联合（时间分享）。

或者像这样，提供全时和临时需要的不同形式。

Answer 2

如果候选子类型是

，则员工项目具有子类型

• 没有完全不同，但
• 不完全相同

这意味着

• 每个员工项目都有一些 属性（列）的共同点。所以他们完全不同。
• 有些员工项目有所不同 属性比其他人。所以他们不是完全相似。

决心与共同和不同的属性有关。它与候选键中的列数无关。您是否有完全不同的员工项目，但不完全相同？

最常见的业务超类型/子类型示例涉及组织和个人。他们并没有完全不同。

• 两人都有地址。
• 两人都有电话号码。
• 两者都可以是原告和被告 在法庭上。

但他们并不完全相同。

• 个人可以上大学。
• 组织可以有一名CEO。
• 个人可以结婚。
• 个人可以生孩子。
• 组织（在美国）可以清算。

因此，您可以将个人和组织表达为称为“缔约方”的超类型的子类型。所有子类型的共同属性都与超类型有关。

• 各方有地址。
• 各方都有电话号码。
• 当事人可以是原告和被告 在法庭上。

同样，这与共同拥有的属性和不同的属性有关。它与候选键中的列数无关。

  

对我来说，复合关键关系是   '是A'的关系   （Employee_Project是一个员工和一个   项目）。

数据库设计师不这么认为。我们根据表格的谓词来思考。

Answer 3

如果一个员工可以有很多项目，一个项目可以有很多员工，那么RDBM只能以一种方式轻松表示多对多的联接（就像你上面概述的那样）。你可以在ER中看到下图（员工/部门是经典的多对多示例之一），它没有单独的ER组件。单独的表是RDBMS的漏洞抽象（这可能是你很难对其进行建模的原因）。

http://www.library.cornell.edu/elicensestudy/dlfdeliverables/fallforum2003/ERD_final.doc

  

桥梁实体

     

当实体的实例可能与另一个实体的多个实例相关时，反之亦然，这称为“多对多关系”。在下面的示例中，供应商可能提供许多不同的产品，每个许多供应商可能提供产品类型：

     

虽然这种关系模型完全有效，但它无法直接转换为关系数据库设计。在关系数据库中，关系由表列中的键表示，该列指向相关表中的正确实例。多对多关系不允许使用此关系表达式，因为每个表中的每个记录可能必须指向另一个表中的多个记录。

http://users.csc.calpoly.edu/~jdalbey/205/Lectures/ERD_image004.gif

虽然他们稍后添加（在此步骤中它是一个'纯'ER图），但他们不会在单独的框中打扰事件。它也可以用一个盒子和一个钻石相互叠加来明确表示。