备注

我已经完全重写了我的原始帖子，以更好地解释我试图理解的问题。我试图尽可能地概括这个问题。

另外，我要感谢回复的原始人。希望这篇文章能让事情更清楚一些。

语境

简而言之，我正在努力理解设计小型数据库来处理(我认为是)多个多对多关系的最佳方法。

想象一下公司组织结构的以下场景:

             Textile Division                    Marketing Division 
                    |                                     | 
          ----------------------               ---------------------- 
          |                    |               |                    | 
       HR Dept           Finance Dept        HR Dept           Finance Dept 
          |                    |               |                    | 
      ----------          ----------       ----------           --------- 
     |          |         |        |       |        |           |       | 
  Payroll     Hiring    Audit     Tax   Payroll   Hiring      Audit  Accounts 
     |          |         |        |       |        |           |       | 
    Emps      Emps       Emps     Emps    Emps     Emps        Emps    Emps     

注意: Emps表示在该领域工作的雇员名单

当我第一次开始处理这个问题时，我制作了四个单独的表格:

Divisions -> 纺织、营销(PK = DivisionID)

Departments -> 人力资源、财务(PK = DeptID)

Functions -> 工资、招聘、审计、税务、账户(PK = FunctionID)

Employees -> 所有员工列表(PK = EmployeeID)

我看到的问题是存在多种多对多关系，即许多部门有许多部门，许多职能有许多部门。

问题

给出上面的数据库结构，假设我想做以下事情:

获取所有在营销部门的薪资职能部门工作的员工

为此，我需要能够区分两个薪资部门，但我不确定如何做到这一点？

我知道我可以在部门和职能之间建立一个“链接/连接”表，以便我可以检索哪些职能在哪些部门中。但是，我仍然需要区分他们所属的部门。

研究工作

正如您所看到的，当涉及到数据库设计时，我是一个初学者。我花了最近两天研究这个问题，遍历嵌套集模型，邻接模型，阅读这个问题已知不是 NP 完全等。我确定有一个简单的解决方案？

请您参考如下方法:

根据更新后的帖子，并根据所使用的名称做出一些(相当明显的)假设，我得出以下结论。有四个实体:

部门

部门

功能

实体

这些实体之间有许多关系。其中很少有层次结构，大多数是简单的关联:

选项 A1:有一个功能主列表。每个部门都可以执行(或做)一个或多个功能，并且一个功能可能由多个部门执行。

选项 A2:职能由部门“拥有”。两个或多个部门不能执行任何功能。 (情况似乎是这样，因为 HR 部门有薪资和招聘部门，而财务部门有审计、税务和会计部门。)

职能由部门(代表)部门执行。 (人力资源部负责纺织和营销部门的薪资和招聘；财务部负责纺织部门的审计和税务——但不负责会计，以及营销部门的审计和会计——但不负责税务。)也许有点更准确地说，各部门为其关联的选定司履行选定的职能，而这种关联是由它们履行该职能决定的。

除了履行职能之外，部门和部门之间似乎没有任何关系。它们之间没有等级关系，因为一个不“拥有”或包含另一个。

这导致了这些粗略的表格:

--  Division  ----- 
DivisionId  (primary key) 
 
--  Department  --- 
DepartmentId  (primary key) 
 
--  Function  -----  (assumes option A2) 
FunctionId   (primary key) 
DepartmentId (foreign key, references Department) 
 
--  DivisionFunctions  ---- 
DivisionId  (First column of compound primary key) 
FunctionId  (Second column of compound primary key) 

(您可以选择包含一个代理键来唯一标识每一行，但 DivisionId + FunctionId 会起作用。)

这里没有足够的 Material 来全面描述“员工”如何融入模型。假设员工做职能的工作:一个员工可以做多个职能的工作，还是只做一项？员工是否在不考虑其所在部门的情况下执行该职能的工作，还是被分配为一个或多个部门工作？这里有两个明显的选择，尽管更复杂的变体是可能的:

选项 B1:员工在部门内完成一项或多项职能的工作，并为需要该部门该职能的所有部门执行这项工作。

选项 B2:分配员工执行特定部门的特定职能。

鉴于这些，表格可能如下所示:

--  Employee  -----  (assumes option B1) 
EmployeeId    (primary key) 
DepartmentId  (foreign key, references Department) 
 
--  EmployeeFunction  -----  (assumes option B1) 
EmployeeId  (First column of compound primary key) 
FunctionId  (Second column of compound primary key) 

... 因此，所有能够执行某项职能的员工都将为所有需要该职能的部门执行该职能。或者，

--  Employee  -----  (assumes option B2) 
EmployeeId  (primary key) 
DepartmentId  (foreign key, references Department) 
 
--  EmployeeAssignment  -----  (assumes option B2) 
EmployeeId  (foreign key, references Employee) 
DivisionId  (first of two-column foreign key referencing DivisionFunctions) 
FunctionId  (second of two-column foreign key referencing DivisionFunctions) 

(或者，代替 DivisionId 和 FunctionId，包括来自 DivisionFunctions 的可选代理键。)……因此，员工被单独分配到部门要为一个部门执行的功能。

但这仍然留下了很多“如果/何时”的问题:员工是否“属于”部门？员工可以属于(工作)多个部门吗？也许员工属于部门？您是否跟踪员工可以执行哪些职能，即使他们目前没有这样做？同样，您是否跟踪员工在哪个部门工作，即使他们目前处于“职能之间”？如果员工可以执行职能 A 和 B，而一个部门需要这两种职能，是否可以指定一名员工只为该部门执行 A 而不是 B？

这里还有更多的需求研究要做，但我认为这是一个好的开始。