如何在我的数据库设计中包含这些要求？答案

【问题标题】：How to include these requirements in my database design?如何在我的数据库设计中包含这些要求？
【发布时间】：2012-11-26 08:18:27
【问题描述】：

我正在为我的公司开发一个 Intranet 应用程序。公司结构复杂，业务条线多、部门多、事业部多、单位多、集团多。我必须照顾所有这些事情。有些员工在部门级别工作，有些员工在单位级别工作，等等。现在的问题在于数据库设计。我对如何设计数据库感到困惑。一开始，我决定如下设计：

Employees: Username, Name, Title, OrgCode
Departments: OrgCode, Name
Divisions: OrgCode, Name
Units: OrgCode, Name

但是问题正如我之前所说，有些员工在部门下工作，那么如何在所有这些表之间建立关系。是否可以将员工表中的 OrgCode 作为 Departments、Divisions 和 Units 表中的 OrgCode 的外键？

你能推荐我如何设计它吗？

更新： @wizzardz 做了一个不错的数据库设计。我现在需要的是有一个适合这个数据库设计的数据示例这是我在数据库中使用的一组数据：让我们假设我们有 Employee 具有以下信息：用户名：JohnA 姓名：约翰职称：工程师组织代码：AA

假设我们有部门 AA，我将如何将这些数据分配到数据库设计中？

【问题讨论】：

有几个部门？
将OrgCode存储在employees表中意味着每个员工一次只能属于一个部门；一些员工可能属于多个部门，而且您没有存储任何人员从一个部门转移到另一个部门的历史记录。
该员工只能在一个部门工作。但他可以从那个部门转到另一个部门。那么哪种设计更好呢？

标签： sql database-design

【解决方案1】：

你可以做这样的设计

与其为 Departments、Divisions 等使用单独的表，不如尝试将它们存储在一个带有 TypeId 的表中以区分 Departments、Divisions 等。

你能试试这样的设计吗

在级别表中，您需要输入“部门、部门”、组等值（通过将其保存在单独的表中，您可以处理组织未来添加的任何新级别。）

在 OrganisationLevels 表中，您需要存储部门名称、部门名称、组名等。

Employee 表有一个与表组织级别的外键引用，它将存储员工在组织中工作的级别。

如果您想存储特定员工的工作历史/有可能员工可以从一个级别移动到另一个级别，我建议您采用这种设计

设计中的示例数据

等级

 Id  LevelType  
 1    Department
 2    Division
 3    Group

组织级别

Id Name LevelId Parent*(Give a proper name to this column)*
13  AA    1       NULL
.
.
21  B     2        13 (This column refer to the Id of department it belongs to.)

员工

Id UserName Name   Title 
 110  JohnA    John   Engineer

员工工作详情

Id  EmployeeId OrganisationLevelId StartDate  EndDate IsActive
271    110           13            20/09/2011   NULL     true

可以删除员工表中的组织代码，因为我认为这是该组织员工的员工代码。

我希望这会有所帮助。

【讨论】：

感谢您的帮助。您能否通过示例详细说明这一点？请看看我更新的问题。因为我不知道如何将部门和部门分配到您的数据库设计中。
@TechLover ：- 我已经用一些示例数据更新了我的答案。看看有没有帮助。
非常感谢您的解释。是的，它很有帮助。
再问一个问题：如何判断这个部门属于这个部门？ 比如，如何知道B部门属于AA部门？
@TechLover：那么您将不得不在表中添加一个新列 OrganisationLevels 以链接表中的部门和部门，我已经更新了我的答案

【解决方案2】：

Employees: Username, Name, Title, OrgCode
Departments: OrgCode, Name
Divisions: OrgCode, Name
Units: OrgCode, Name

对于上述数据库设计，还有一个名为 Org 的表，其中包含 OrgCode 和另一列作为类型（我们提供关于它是哪种类型的 org 的见解，即 Departments、Divisions 和 Units）

然后你可以让员工表的 OrgCode 来引用 Org 表的 OrgCode（父子关系）。

【讨论】：

您能详细说明一下吗？我不明白你的意思

【解决方案3】：

我建议你了解分析和设计之间的区别。当您设计数据库时，您正在发明将影响数据存储和检索方式的表、列和约束。您关心更新和查询的难易程度，包括您稍后将了解的操作。

当您分析数据需求时，您并没有参与发明事物，而是参与发现事物。你发现的东西是关于主题应该代表的“现实世界”的东西。您将主题分解为“实体”以及这些实体之间的关系。然后，您将存储在数据库中的每个值与属性的实例相关联，并将每个属性与实体或关系的某个方面相关联。这产生了一个概念模型。

就您而言，员工、部门、单位等之间的关系听起来相当复杂。想出一个准确反映这个复杂现实的模型是值得付出相当大的努力的。

一旦您有了一个好的概念模型，您就可以创建充分代表概念模型的 SQL 表、列和约束。这涉及可以学习的设计技能。但是，如果你有一个糟糕的概念模型，那么无论你在设计方面多么出色，你都注定要失败。

【讨论】：