0

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

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

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

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

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

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

4

3 回答 3

3

你可以做这样的设计

与其为 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

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

我希望这有帮助。

于 2012-12-08T07:23:06.567 回答
0 
Employees: Username, Name, Title, OrgCode
Departments: OrgCode, Name
Divisions: OrgCode, Name
Units: OrgCode, Name

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

那么您可以让员工表的 OrgCode 引用 Org 表的 OrgCode（父子关系）。

于 2012-12-08T06:52:43.727 回答
0

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

When you analyze the data requirements, you aren't engaged in inventing things, you are engaged in discovering things. And the things you are discovering are things about the "real world" the subject matter is supposed to represent. You break the subject matter down into "entities" and relationships among those entities. Then you relate every value stored in the database to an instance of an attribute, and every attribute to some aspect of either an entity or a relationship. This results in a conceptual model.

In your case, the relationships between employees, departments, units, etc. sound quite complex. It's worth quite a bit of effort to come up with a model that reflects this complex reality accurately.

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

于 2012-12-08T14:25:25.573 回答