对于经验丰富的数据库开发人员来说，这可能是一个简单的问题，但我很难......我在将某个ER图转换为数据库模型时遇到问题，我们对此感到非常感激。
我的设置类似于此演示文稿的幻灯片17： http://www.cbe.wwu.edu/misclasses/mis421s04/presentations/supersubtype.ppt
幻灯片17显示了一个ER图，其中Employee超类型具有Employee Type属性，以及Employee Types本身（Hourly，Salaried和Consultant）的子类型，这与我的设计情况非常相似。
就我而言，假设受薪员工是唯一可以成为其他员工老板的员工，我想以某种方式表明某个受薪员工是否是每小时和/或受薪员工和/或顾问的老板（或者，如何在数据库模型中设计，也可以考虑这些是一对多的关系？
我可以在它们之间建立PK-FK关系，这会导致所有表都有两个FKeys（如顾问有FK_Employee和FK_SalariedEmployee）和SalariedEmployee引用自身，但我一直认为这可能不是最明智的解决方案.. ..尽管我不确定为什么（诚信问题？）。
这是可接受的解决方案还是更好的解决方案？
提前感谢您的帮助！
答案 0 :(得分：1)
您的案例看起来像设计模式的一个实例，称为“泛化专业化”（简称Gen-Spec）。 gen-spec模式对于面向对象的程序员来说很熟悉。在教授有关继承和子类时，它将在教程中介绍。
实现gen-spec模式的SQL表的设计可能有点棘手。数据库设计教程经常掩盖这个主题。但它在实践中一次又一次地出现。
如果您在网上搜索“泛化专业化关系建模”，您会发现一些有用的文章，教您如何执行此操作。在本论坛之前，您还会多次指出这个主题。
文章通常向您展示如何设计单个表来捕获所有通用数据，以及如何为每个子类设计一个专用表，其中包含特定于该子类的所有数据。有趣的部分涉及子类表的主键。您不会使用DBMS的自动编号功能来填充子类主键。相反，您将对应用程序进行编程，以将为通用表获取的主键值传播到适当的子类表。
这在广义数据和专用数据之间创建了双向关联。每个专用子类的简单视图将一起收集通用和专用数据。一旦掌握了它就很容易，并且表现相当不错。
在您的特定情况下，声明FK的“老板”以引用Salaried Employees表中的PK将足以实现这一目的。这将产生您想要的双向关联，并且还可以防止未受薪的员工被引用为老板。