实体：员工,经理,部门.
>员工只能在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”关系.
