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

注意

我已经完全重写了我原来的帖子，以便更好地解释我试图理解的问题。我已尽量把这个问题概括起来

同时，我也要感谢最初的回应者。希望这篇文章能让事情变得更清楚一点

上下文

简而言之，我正在努力理解设计一个小规模数据库来处理（我认为是）多对多关系的最佳方法

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

             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    

注：

emp

表示在该地区工作的员工名单

当我第一次开始讨论这个问题时，我制作了四个单独的表格：

部门

->纺织、营销（主键=部门ID）

部门

->人力资源、财务（PK=DeptID）

功能

->工资单、招聘、审计、税务、账户（PK=FunctionID）

员工

->所有员工列表（PK=EmployeeID）

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

问题

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

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

要做到这一点，我需要能够区分这两个工资部门，但我不知道如何才能做到这一点

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

研究工作

---

正如你们所看到的，当涉及到数据库设计时，我是一个初学者。在过去的两天里，我一直在研究这个问题，遍历嵌套集模型、邻接模型，读到这个问题不是NP完全问题等。我相信有一个简单的解决方案？

你不会把它全部放在一个表中。您需要阅读规范化数据和联接的相关内容。（不要在逗号删除列表中存储任何内容。）

没有一个值得拥有的数据库会在处理一百万条记录时有丝毫的问题，这是一个很小的数据库

---

您需要功能表、课程表、位置表、人员表、组织表，可能还需要一些连接表来容纳多对多关系。但这一切都不难，甚至都不超出基本设计。我建议你在做任何事情之前，先从你所选择的数据库中获得一本书，并阅读基础知识

试着给每个实体一个自己的表，例如

//Table Structure
location
    locationId
    name

division
    divisionId
    name
    locationId (fk => location)

department
    deparmentId
    name
    divisionId (fk => division)

function
    functionId
    name
    departmentId(fk => department)

jobrole
    jobroleId
    name
    functionId

course
    courseID
    name

jobrole_course_requirement
    jobroleID
    courseID

employee
     employeeID
     name

employee_jobRole
     employeeID
     jobRoleId

emploeyee_course_attendance
     emploeyee_course_attendanceID
     emploeyeeID
     courseID
     dateAttended

然后选择一些样本

// Get course requirements for an employee
select course.name 
  from course, 
       jobrole_course_requirement, 
       employee_jobRole
  where 
       employee_jobRole.employeeID = 123 and
       jobrole_course_requirement.JobRoleId = employee_jobRole.JobRoleId
       course.courseID = jobrole_course_requirement.courseID

---

通常，当我建立数据库时，我会提出我需要的实体以及它们之间的关系（即多个、一个……）。你似乎已经做了。所以接下来我要弄清楚每个实体需要什么。例如，位置可能有：locationid、address、。。。然后，假设每个部门都有一个用于多个部门的位置，您可以让部门实体有一个部门ID，locationid，每个部门需要的信息。所以基本上，如果它是一个一对多的关系，比如一个位置到多个分区，你可以把位置的id放在分区表中。但是，如果它是一个多-多关系，那么最好使用一个中间表来连接这两个关系，这样就不需要有重复的记录，而只需要更改id

你需要一个简单的明星关系。职位（事实表）只有相关主表（部门、部门等）的ID。这允许使用主表的任何组合

主表可以根据需要在每个主表中构建简单的层次结构。并且可以根据需要相互联系。但这一细节并不影响对位置的查询

对于可选关系，您可以使位于位置的ID为空

您可以添加StartDate和EndDate列来定位，以跟踪随时间的变化

一个简单的例子是：

---

也许（大概）你应该把纺织部门的人力资源部门看作是营销部门人力资源部门的不同部门。

< P>根据最新的职位，并根据所用的名称做出一些（相当明显）的假设，我提出以下几点。有四个实体：

• 分部
• 部门
• 功能
• 实体

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

• 选项A1：有一个功能的主列表。每个部门都可以执行（或执行）一项或多项职能，一项职能可能由多个部门执行
• 选项A2：职能由部门“拥有”。两个或多个部门不能执行任何职能。（这似乎是事实，因为人力资源部有工资和招聘，而财务部有审计、税务和账目。）

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

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

这导致了这些粗略的sketc

--  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)

--  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)

departments_in_divisions
candidate key: department, division

functions_departments_divisions
candidate key: function, department, division
references: (department, division) in departments_divisions

employees_function_department_division
candidate key: employee, function, department, division
references: (function, department, division) in functions_departments_divisions