我和一位数据库架构师正在争论具有复合主键和子类型的表是否在关系上有意义，以及这是否是一种好的做法。
假设我们有两个表 Employee 和 Project。我们创建一个复合表 Employee_Project，其中复合主键返回 Employee 和 Project。
Employee_Project 是否有有效的方法来拥有子类型？或者你能想到复合键表可以有子类型的任何场景吗？
对我来说，复合键关系是“Is A”关系（Employee_Project 是一个员工和一个项目）。子类型也是“Is A”关系。因此，如果您有一个复合键，其子类型在一个句子中有两个“Is A”关系，这让我相信这是一种不好的做法。
【问题讨论】：
标签： sql database database-design relational-database
员工项目有点难，但可以想象这样的事情——尽管我不是一个化学家。
或类似的事情，这将需要不同的法律形式（领域）来进行单人所有权与联合（分时）。
或者像这样，前提是全职和临时需要不同的表格。
【讨论】：
如果候选子类型是，则员工项目具有子类型
这意味着
决定与共同和不同的属性有关。它与候选键中的列数没有任何关系。您有没有完全不同但又不完全相同的员工项目？
最常见的业务超类型/子类型示例涉及组织和个人。它们并没有完全不同。
但它们并不完全相同。
因此，您可以将个人和组织表示为称为“Parties”的超类型的子类型。所有子类型的共同属性都与超类型相关。
同样，这与共有的属性和不同的属性有关。它与候选键中的列数无关。
对我来说，复合键关系是 一个“是一个”的关系 （Employee_Project 是一个 Employee 和一个 项目）。
数据库设计者不这么认为。我们根据表的谓词进行思考。
【讨论】：
如果一个员工可以有很多项目，而一个项目可以有很多员工，那么 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 图），但在这里他们不会打扰一个单独的框。它也可以用相互叠加的方框和菱形来明确表示。
【讨论】：