EER 图继承答案

【问题标题】：EER diagram inheritanceEER 图继承
【发布时间】：2016-07-16 12:14:13
【问题描述】：

在下面这样的场景中

assignee 和assigner 是developer 和tester 的key。如何将emp_id映射为外键而不重复？

【问题讨论】：

您自己有没有想出任何设计/模型？可以在这里分享一下吗？
我认为唯一能做的就是为每个测试人员和开发人员自己声明主键。
你能举一个你试图避免的重复的例子吗？我认为设计没有问题 - assigner 和 assignee 应该包含相关的 emp_ids。
是的，我也同意你的看法。将受让人和分配者作为引用 emp_id 的外键将解决我认为的问题。我对吗？@reaanb

【解决方案1】：

这些主要是员工的角色 - 开发人员、测试人员、业务分析师等。一种方法是为每种角色类型设置多个表 - 这样您最终就会拥有像 Developer、Tester 等这样的表。您将有一个EmployeeID 字段作为foreign key 到Employee 表。

另一种方法是（我会推荐它）有一个名为EmployeeRole 的表，您可以在其中记录Employee 可以拥有的每个角色。这样您就不必在每次提出新角色时都创建新表。这只是在EmployeeRole 表中添加新记录的情况。这也适用于Employee 在不同问题上扮演多个角色的场景——开发者和测试者。

【讨论】：

但我需要有两个外键到问题表，其中employeeId 参考一个用于测试人员，一个用于开发人员我如何才能实现这仍然是一个问题
您必须引用EmployeeRole 表（EmployeeRoleID 列），而不是直接引用 Employee 表，而后者又将引用 Employee 表。因此，要获取有关问题的Employee 详细信息，您的查询将如下所示：SELECT Emp.* FROM Issue I JOIN EmployeeRole ER ON I.TesterID = ER.EmployeeRoleID JOIN Employee EMP ON ER.EmployeeID = EMP.EmployeeID
您的“解决方案”不允许强制执行参照完整性，并滥用代理键来创建预定的访问路径，这将对查询施加额外的连接和复杂性。
@reaanb Issue 和Employee 之间的引用完整性是通过EmployeeRole 表实现的。但是，我意识到我对这个问题的回答过于复杂。它确实有一个用例，我很乐意在这个问题之外讨论它，但对于这个特定场景，我们只需要assigner 和assignee 在Employee 表中引用emp_id。 @Gayan 很抱歉让您感到困难！
没关系，你的回答引起了我的注意。谢谢

【解决方案2】：

看看shared-primary-key。使用这种技术，您可以使用 emp-id 作为 tester 和 developer 表中的主键，也可以作为引用员工表的外键。这是实现 IS-A 关系时的常见做法。

【讨论】：