sql - 您将如何建模以下数据库关系？

Question

有部门和经理。一个部门有多个经理，但只有一位经理是该部门的首席经理。一个部门必须只有一名首席经理。节假日期间，一个部门的负责人可以临时担任另一个部门的负责人。你会如何建模？

请解释你的选择。

Answer 1

假设一个“普通”经理最多可以管理一个部门，你的数据模型应该看起来像这样：

CHIEF_MANAGER_ID 可以“指向”：

• 到同一部门的经理（即其 MANAGER.DEPARTMENT_ID 与包含此 CHIEF_MANAGER_ID 的行的 DEPARTMENT.DEPARTMENT_ID 匹配），在这种情况下，它是“主要”首席经理
• 或来自不同部门的经理，在这种情况下，它是“替代”首席经理。

如果您想确保同一个人不能以首席经理的身份管理多个部门（同时仍然能够以普通经理的身份管理多个部门），请在 CHIEF_MANAGER_ID 上添加一个 UNIQUE 约束。

如果您需要同时记住主要和替代首席经理，请使用两个字段而不仅仅是 CHIEF_MANAGER_ID（在这种情况下，您还必须以非声明方式强制执行部门匹配）。

在上面的模型中，DEPARTMENT.CHIEF_MANAGER_ID 可以为 NULL。这样做是为了打破外键的循环，因此实际上可以将数据插入数据库而无需延迟外键。如果您的 DBMS 支持可延迟约束，您可以将此字段设为 NOT NULL 并延迟其中一个 FK，以便在事务结束时检查它（在插入两行之后）。

---

我刚刚意识到还有一个额外的要求：不是每个经理都可以替代。只有酋长可以。你可以做这样的事情来建模它：

SUBSTITUTE_DEPARTMENT_ID 指向我们正在“借用”首席经理替代品的部门。由于我们指向的是一个部门，而不是直接的经理，我们知道我们必须让首席经理了解它。

Answer 2

部门一表（含总经理ID）

经理一桌（每人）

一个部门/经理关系表（部门 ID 和经理 ID）

例子：

Answer 3

你可以使用这个模型

部门（IdDepartment，其他属性...）

经理（Idmanager，其他属性...）

部门经理（IdDepartment、IdManager、IsTemporary）

在你的物理模型中

DepartmentTable
IdDepartment 作为主键

ManagerTable
IdManager 作为主键

DepartmentManagerTable (IdDepartment + IdManager) 作为主键 IsTemporaryChef 作为属性

Answer 4

这里的主要思想是将组织结构图的层次结构与员工分开（经理是员工）。就像总统（职位）和担任职务的人之间的区别。

为简单起见，这里的层次结构是用 levelled-adjacency-list 建模的；对于 SQL 层次结构来说不是最有效的，但对此已经足够了。

请注意，部门主管的职位不向该部门的任何人报告。整个组织的 CEO 都有ReportsTo = NULL，对于其他人来说，它指向了老板的位置。

随着时间的推移，每个员工都可以履行任何角色。

有关更有效的层次结构模型，请参阅 Celko 的书或只是 google 'SQL hierarchies'。

Answer 5

部门一桌，经理一桌，总经理一桌。

经理与部门的关系表，首席经理与部门的关系表，首席经理与他们被允许监督的其他部门的关系表（或者相反，如果它导致较小的数据集，该表应该是关系表首席经理到他们不允许监督的部门）。