SQL Server 2005数据库设计 - 与层次结构的多对多关系

Question

注意

我完全重写了我原来的帖子,以便更好地解释我想要了解的问题.我试图尽可能地概括这个问题.

另外,我要感谢回应的原始人.希望这篇文章能让事情变得更加清晰.

上下文

简而言之,我正在努力理解设计小规模数据库以处理(我认为是)多个多对多关系的最佳方法.

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

             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    

NB:Emps表示在该区域工作的雇员名单

当我第一次开始这个问题时,我做了四个单独的表:

1. Divisions - >纺织,营销(PK = DivisionID)
2. Departments - >人力资源,财务(PK = DeptID)
3. Functions - >薪资,招聘,审计,税务,账户(PK = FunctionID)
4. Employees - >所有员工的列表(PK = EmployeeID)

我认为存在的问题是,存在多个多对多关系,即许多部门有许多部门,许多部门都有很多部门.

题

给出上面的数据库结构,假设我想要执行以下操作:

• 获取在市场营销部门的薪资功能中工作的所有员工

要做到这一点,我需要能够区分两个薪资部门,但我不知道如何做到这一点？

我知道我可以在Departments和Functions之间建立一个'Link/Junction'表,这样我就可以检索哪些部门的功能.但是,我仍然需要区分他们所属的部门.

研究工作

正如您所看到的,在数据​​库设计方面,我是一名初学者.我花了最后两天来讨论这个问题,遍历嵌套集模型,邻接模型,读取这个问题已知不是NP完全等等.我确信有一个简单的解决方案？

Answer 1

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

\n\n

\n
• 部门
\n
• 部门
\n
• 功能
\n
• 实体
\n

\n\n

这些实体之间存在多种关系。其中很少有层次结构，大多数都是简单的关联：

\n\n

\n
• 选项 A1：有一个功能主列表。每个部门都可以执行（或执行）一项或多项职能，并且一项职能可能由多个部门执行。
\n

• 选项A2：功能按部门\xe2\x80\x9cowned\xe2\x80\x9d。任何职能不能由两个或多个部门执行。（情况似乎确实如此，因为人力资源部门负责工资和招聘，财务部门负责审计、税务和会计。）

\n

• 职能由部门（代表）部门执行。（人力资源部负责纺织和营销部门的工资和招聘；财务部负责纺织部门的审计和税务，但不负责会计；营销部门负责审计和会计，但不负责税务。）也许有一点更准确地说，部门为与其相关的选定部门履行选定的职能，而这种关联是由其履行该职能来定义的。

\n

• 除了履行职能之外，部门和部门之间似乎没有任何关系。它们之间不存在层级关系，因为其中一个不 \xe2\x80\x9cown\xe2\x80\x9d 或包含另一个。

\n

\n\n

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

\n\n

--  Division  -----\nDivisionId  (primary key)\n\n--  Department  ---\nDepartmentId  (primary key)\n\n--  Function  -----  (assumes option A2)\nFunctionId   (primary key)\nDepartmentId (foreign key, references Department)\n\n--  DivisionFunctions  ----\nDivisionId  (First column of compound primary key)\nFunctionId  (Second column of compound primary key)\n

\n\n

（您可以选择包含代理键来唯一标识每一行，但 DivisionId + FunctionId 也可以。）

\n\n

这里没有足够的材料来完整描述“员工”如何融入模型。鉴于员工承担多项职能的工作：一名员工是否可以承担多项职能的工作，还是只承担一项职能？员工是否执行该职能的工作，而不管该工作是为哪个部门完成的，还是被分配为一个或多个部门执行该工作？这里有两个明显的选择，尽管可能有更复杂的变体：

\n\n

\n
• 选项 B1：员工执行部门内一项或多项职能的工作，并为需要该部门该职能的所有部门执行该工作。
\n
• 选项 B2：员工被分配执行特定部门的特定职能。
\n

\n\n

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

\n\n

--  Employee  -----  (assumes option B1)\nEmployeeId    (primary key)\nDepartmentId  (foreign key, references Department)\n\n--  EmployeeFunction  -----  (assumes option B1)\nEmployeeId  (First column of compound primary key)\nFunctionId  (Second column of compound primary key)\n

\n\n

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

\n\n

--  Employee  -----  (assumes option B2)\nEmployeeId  (primary key)\nDepartmentId  (foreign key, references Department)\n\n--  EmployeeAssignment  -----  (assumes option B2)\nEmployeeId  (foreign key, references Employee)\nDivisionId  (first of two-column foreign key referencing DivisionFunctions)\nFunctionId  (second of two-column foreign key referencing DivisionFunctions)\n

\n\n

（或者，包括 DivisionFunctions 中的可选代理键，而不是 DivisionId 和 FunctionId。） ...因此，员工被单独分配给部门的部门执行的职能。

\n\n

但这仍然留下了很多 \xe2\x80\x9cwhat if/when\xe2\x80\x9d 的问题：员工 \xe2\x80\x9c 是否属于 \xe2\x80\x9d 部门？员工可以属于（为）多个部门工作吗？也许员工属于部门？您是否跟踪员工可以执行哪些职能，即使他们当前没有这样做？同样，您是否跟踪员工在哪个部门工作，即使他们目前位于职能部门 \xe2\x80\x9d 之间？如果一名员工可以执行职能 A 和 B，并且某个部门需要这两种职能，那么该员工是否可以被分配只执行该部门的 A 而不执行 B？

\n\n

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

\n