在我们开始之前,我会先提到每个步骤的规则。为什么这样?因为我不知道你表中的依赖关系。因此,提出规则和我对您的数据的假设将阐明我是如何得出最终解决方案的。
最后,如果您对答案不满意,至少您会失去对标准化工作原理的理解,并且可以继续自己对只有您最了解的数据进行处理。
数据库设计的自然顺序
- 首先指定实体(这些是表格)
- 指定您的实体所需的属性(这些是列)
- 指定实体的唯一属性(表的主键)。如果没有,请自己给一个(也称为合成主键或代理主键)。
- 最后指定这些实体之间的关系(主键-外键关系和1-N、N-N关系等)
---------
现在,基本的设计规则已经到位,很容易看出您的单个表实际上有四个独立的实体融合在一起。它们是:
1.员工 - 有身份证和姓名的人
2。角色 - 可以是工程师、技术支持等
3.部门 - 可以是软件、硬件、部门(虽然可以使用更好的词)、语音等。
4. Salary - 包含 EmpId、DateOfChange 和 Amount。这是因为员工的薪水不同,而且同一员工的薪水也会随着时间而变化。
因此,如上所述,我们将把这张桌子分成四张桌子。在四个表中,Employee 表以 id 作为主键,Role 和 Department 需要合成(甚至可能是自动递增)键,Salary 将 {EmpId, DataOfChange} 一起作为主键。这看起来像:
Table Name Columns
Employee Id, Name, RoleId, DeptId
Role RoleId, RoleType
Department DeptId, DeptName
Salary EmpId, DateOfChange, Amount
上面的所有表格都可以有更多的项目。我正在尝试与您已经给出的那张桌子有极简差异的设计。像 Salary 表一样,也可以有一个像 ReasonOfSalaryChange 这样的字段,它可以有像 NewHiring、Promotion 等这样的值......但我们将更改保持在最小限度。
希望到目前为止一切都好。如果是这样,我们将继续进行您所要求的实际标准化。
常用规范化
我之所以提到常用规则,是因为老实说,我在实践中从来不需要 BCNF、4th 和 5th NF。
规则 -
1NF: 只是声明所有列都必须具有原子值。如果一列需要多个值,请创建另一个表。您的新表通过了该测试。表列中的所有值都是原子的。
2NF: 需要 1NF 限定,并且任何非键字段都应依赖于整个主键。您的所有非键字段(员工中的姓名、角色中的角色类型、部门中的部门名称、工资中的金额)取决于相应表的主键(Id、RoleId、DeptId 和 {EmpId、DateOfChange})。所以这些表符合 2NF 标准。
3NF: 需要 2NF 资格,并且任何非关键字段都不应依赖于任何其他非关键字段。这意味着除了主键之外,表的列之间不应存在依赖关系。 Role、Department 和 Salary 表是默认的 3NF 限定的,因为它们只有一个非键列并且它依赖于 PK。 Employee 表,您可以自己验证,没有依赖于任何其他非关键元素的非关键元素。因此,这些表完全符合目前的 3NF 标准。
现在剩下的就是指出 RoleId、DeptId 和 EmpId 分别是 Role、Department 和 Employee 表中的外键。这将是我最后一次重新设计和规范化的数据库提交给您。