sql - 递归关系的数据库设计

考虑这种情况，当我尝试为公司建立数据库模型时:

实体:Employees，Managers，Departments。

Employee仅可用于1个Department，而Department可能包含许多Employees。

Manager只能管理1个Department，类似地，Department只能管理1个Manager。

Manager监督许多Employees，但是Employee仅受一个Manager监督。

现在，我有2种方法对此建模:
第一个解决方案:
考虑到我将保留经理人唯一的数据(例如奖金和状态)，因此我将Manager实体继承自Employee实体。

因为Department和Employee之间的关系是1:N，所以我将Department Id作为Employee的Works表中的外键
关系。

因为Department和Manager之间的关系是1:1，所以我将Department Id作为Manager的Manages表中的外键
关系。

问题:如何表示Manager和Employee之间的递归关系？

第二种解决方案:
我认为不需要Manager实体，因为其他Employees可能也有Bonus和Status。 (实际上，我添加了这两个属性只是为了看看如何在两种情况下对其建模)

因为Department和Employee之间的关系是1:N，所以我将Department Id作为Employee的Works表中的外键
关系。

因为Employee和Manager之间的关系是1:N，所以我将Employee Id作为Employee的Supervises表中的外键
关系并将其称为Manager Id。

问题:如何表示Manager和Department之间的关系？

问题:

两种设计都存在明显的错误吗？

在两种情况下如何解决每个问题？

是否有比这两个更好的解决方案？

最佳答案

我可能会喜欢这样的东西:

该模型具有以下特征:

经理“继承”员工。

要代表员工，请在EMPLOYEE中插入一行。

要代表经理，请在EMPLOYEE的中插入一行，在MANAGER中的中插入一行。

一个部门可以有多个员工。

每个部门只有一名经理，每个经理管理0或1个部门。

主管可以是普通雇员或经理。

部门不需要“匹配”:

主管可以与受监管员工在不同部门工作。

经理可以管理其工作所在的不同部门。

如果主管是经理，则他所管理的部门，工作的部门以及受监管雇员的部门都可以不同。

注意:如果您的DBMS不支持延迟约束，则需要将DEPARTMENT.MANAGER_ID设为NULL，以打破可能会阻止您插入新数据的循环。

如果要求部门匹配，则可以采用特定于DBMS的技术(例如触发器或“特殊”约束)，也可以将DEPARTMENT_ID传播到员工PK中。这种传播最终使匹配成为可能:

由于EMPLOYEE_ID必须是全局唯一的，因此它不能与DEPARTMENT_ID一起保留在组合键中。因此，我们将其设置为备用键，而在PK中使用替代EMPLOYEE_NO。

此模型可防止您拥有管理一个部门并在另一个部门工作的经理或主管来监督其他部门员工的主管。

如果您不熟悉该符号...

...表示“类别”。在这种情况下，您可以简单地将其解释为EMPLOYEE和MANAGER之间的“1到0或1”关系。

关于sql - 递归关系的数据库设计，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/9967602/