我和一个数据库架构师正在讨论一个具有复合主键和子类型的表是否有关系,并且这是一个好习惯 .
假设我们有两个表Employee和Project . 我们创建一个复合表Employee_Project,其中一个复合主键返回Employee和Project .
Employee_Project是否有一种有效的方式来获得子类型?或者您能想到复合键表可以具有子类型的任何场景吗?
对我来说,复合键关系是'Is A'关系(Employee_Project是一个Employee和一个Project) . 子类型也是'是A'的关系 . 因此,如果你有一个带有子类型的复合键,它在一个句子中有两个'是A'关系,这让我相信这是一个不好的做法 .
3 回答
员工项目有点困难,但人们可以想象这样的事情 - 虽然我不是化学家 .
或类似的东西,这需要不同的法律形式(领域)单人所有权与联合(时间分享) .
或者像这样,提供全时和临时需要的不同形式 .
如果候选子类型是,则员工项目具有子类型
并没有完全不同,但是
不完全相同
这意味着
每个员工项目都有一些共同的属性(列) . 所以他们并没有完全不同 .
某些员工项目的属性与其他项目不同 . 所以他们并不完全相同 .
该决定与共同和不同的属性有关 . 它与候选键中的列数无关 . 您是否有完全不同但不完全相同的员工项目?
最常见的业务超类型/子类型示例涉及组织和个人 . 他们并没有完全不同 .
两者都有地址 .
两个都有电话号码 .
两人都可以在法庭上作为原告和被告 .
但他们并不完全相同 .
个人可以上大学 .
组织可以拥有一名CEO .
个人可以结婚 .
个人可以生孩子 .
组织(在美国)可以清算 .
因此,您可以将个人和组织表达为称为“缔约方”的超类型的子类型 . 所有子类型的共同属性都与超类型有关 .
缔约方有地址 .
派对有电话号码 .
当事人可以在法庭上成为原告和被告 .
同样,这与共同拥有的属性和不同的属性有关 . 它与候选键中的列数无关 .
数据库设计者不这么认为 . 我们根据表的谓词来思考 .
如果一个员工可以有很多项目,而一个项目可以有很多员工,那么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图),但他们不会因为单独的框而烦恼 . 它也可以用框和菱形相互叠加来明确表示 .