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

实体：员工,经理,部门.
>员工只能在1个部门工作,而部门可能有许多员工在工作.
>经理只能管理1个部门,同样一个部门可能只有一个经理.
>经理监督许多员工,但员工仅由一名经理监督.

现在我有两种方法建模：

第一个解决方案：

考虑到我会保留管理员所特有的数据(例如,奖金和状态),我认为经理实体继承于员工实体.

>由于部门和员工之间的关系是1：N,那么我会把
部门Id作为工作人员表中的外键
关系.
>由于部门和经理的关系是1：1,所以我会把
部门ID作为管理员表中的外键
关系.

问题：如何表示经理和员工之间的递归关系？

第二个解决方案：

我认为不需要经理实体,因为其他员工也可能拥有奖金和状态. (实际上,我添加了这两个属性,只是为了看看如何在两种情况下建模)

>由于部门和员工之间的关系是1：N,那么我会把
部门Id作为工作人员表中的外键
关系.
>由于员工和经理之间的关系是1：N,那么我会把它
员工身份证作为监督员工表中的外键
关系并称之为管理员ID.

问题：我如何表示经理和部门之间的关系？

问题：

>两种设计都有明显的错误吗？
>如何解决这两种情况下的每个问题？
>有没有比这两个更好的解决方案？

解决方法

该型号具有以下特点：

>经理“继承”员工.

>要表示员工,请在EMPLOYEE中插入一行.
>要表示一个经理,在EMPLOYEE中插入一行,在MANAGER中插入一行.

>部门可以有多名员工.
>每个部门都有1个经理,每个经理都管理0个或1个部门.
>主管可以是普通员工或经理.
>部门不需要“匹配”：

>主管可以在受监督的员工的不同部门工作.
>经理可以管理不同部门的工作.
>如果主管是经理,那么他管理的部门,他所在的部门和他/她的受监督员工的部门都可以不同.

注意：如果您的DBMS不支持延迟约束,则需要使DEPARTMENT.MANAGER_ID为空,以打破否则将阻止您插入新数据的循环.

如果部门需要匹配,那么您将采用DBMS特定技术(例如触发器或“特殊”约束),或者将DEPARTMENT_ID“传播”到员工的PK中.这种传播最终能够匹配：

由于EMPLOYEE_ID必须是全局唯一的,所以它不能与DEPARTMENT_ID一起保留在组合键中.所以,我们使它成为备用键,而是使用PK中的代理EMPLOYEE_NO.

这种模式阻止您拥有管理一个部门并在另一个部门工作的经理,或监督来自不同部门的员工的主管.

如果你不熟悉符号…

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

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!