【数据库】第三范式

第三范式（Third Normal Form，3NF）是数据库设计中的一种规范，它建立在第一范式（1NF）和第二范式（2NF）的基础之上，旨在进一步减少数据冗余和避免更新异常等问题，下面从定义、相关概念、实例分析、优缺点和应用场景几个方面详细介绍：

定义

若关系模式 R 满足第二范式（2NF），且每一个非主属性既不部分依赖于码也不传递依赖于码，则称 R 满足第三范式，记作 R∈3NF。简单来说，第三范式要求数据库表中的非主属性不能依赖于其他非主属性，所有非主属性都必须直接依赖于候选码。

相关概念

• 主属性与非主属性：包含在任何一个候选码中的属性称为主属性；不包含在任何候选码中的属性称为非主属性。
• 传递依赖：设 X、Y、Z 是关系 R 中互不相同的属性集合，存在 X → Y（Y!→X），Y → Z，则称 Z 传递依赖于 X。

实例分析

不符合第三范式的例子

假设有一个员工信息表 Employees，包含以下字段：

字段名	含义
员工编号	唯一标识员工
部门编号	员工所在部门的编号
部门名称	员工所在部门的名称
员工姓名	员工的姓名

在这个表中，候选码是 “员工编号”，“员工姓名” 直接依赖于 “员工编号”，但 “部门名称” 依赖于 “部门编号”，而 “部门编号” 又依赖于 “员工编号”，即 “部门名称” 通过 “部门编号” 传递依赖于 “员工编号”，所以该表不满足第三范式。
这种设计会带来一些问题：

• 数据冗余：如果一个部门有多个员工，那么该部门的名称会在每个员工记录中重复出现。
• 插入异常：如果要新增一个部门，但还没有员工分配到该部门，由于候选码是 “员工编号”，就无法插入该部门信息。
• 删除异常：如果删除某个部门的所有员工记录，那么该部门的信息也会被删除。
• 更新异常：如果部门名称发生变化，需要更新所有属于该部门的员工记录中的 “部门名称”，容易出现更新不一致的情况。

符合第三范式的设计

将上述表拆分成两个表：

• 员工表 Employees：
  | 字段名 | 含义 |
  | --- | --- |
  | 员工编号 | 唯一标识员工 |
  | 部门编号 | 员工所在部门的编号 |
  | 员工姓名 | 员工的姓名 |

在这个表中，候选码是 “员工编号”，非主属性 “部门编号” 和 “员工姓名” 都直接依赖于 “员工编号”。

• 部门表 Departments：
  | 字段名 | 含义 |
  | --- | --- |
  | 部门编号 | 唯一标识部门 |
  | 部门名称 | 部门的名称 |

在这个表中，候选码是 “部门编号”，非主属性 “部门名称” 直接依赖于 “部门编号”。

通过这样的拆分，消除了传递依赖，满足了第三范式，减少了数据冗余，也避免了插入、删除和更新异常。

优缺点

优点

• 减少数据冗余：消除传递依赖后，避免了数据的重复存储，节省了存储空间。
• 提高数据一致性：由于数据冗余减少，更新数据时只需在一处进行修改，降低了数据不一致的风险。
• 增强数据库可维护性：表结构更加清晰，每个表的职责更加明确，便于数据库的维护和扩展。

缺点

• 增加表连接操作：为了满足第三范式，将原本可能在一个表中的数据拆分到多个表中，在进行查询时可能需要进行更多的表连接操作，从而增加了查询的复杂度和时间成本。

应用场景

• 对数据一致性要求高的系统：如金融系统、医疗系统等，这些系统中数据的准确性和一致性至关重要，第三范式可以有效保证数据质量。
• 数据量较大的系统：当数据库中的数据量非常大时，数据冗余会占用大量的存储空间，使用第三范式可以减少冗余，提高存储效率。