第三范式 (3NF)

• 当一个关系满足 2NF 并且不包含任何传递部分依赖时，它就满足 3NF。
• 3NF 用于减少数据重复。它还用于实现数据完整性。
• 如果对于非主属性不存在传递依赖，则该关系必须处于第三范式。

如果对于每一个非平凡函数依赖 X → Y，该关系满足以下条件之一，则该关系处于第三范式：

1. X 是超键。
2. Y 是主属性，即 Y 的每个元素是某个候选键的一部分。

为了解释 3NF，我们以下面的 Employee_Detail 关系为例。

示例： EMPLOYEE_DETAIL 表

示例

EMPLOYEE_DETAIL 表

表中的超键

候选键： {EMP_ID}

非主属性： 在给定表中，除了 EMP_ID 之外的所有属性都是非主属性。

这里，EMP_STATE 和 EMP_CITY 依赖于 EMP_ZIP，而 EMP_ZIP 依赖于 EMP_ID。非主属性（EMP_STATE、EMP_CITY）传递依赖于超键（EMP_ID）。这违反了第三范式规则。将 2NF 关系还原到 3NF 包括将 2NF 分割成适当的关系，使得每个非键属性都函数依赖于主键，而不是传递或间接依赖于 respective 关系。

因此，我们需要将 EMP_CITY 和 EMP_STATE 移动到一个新的 <EMPLOYEE_ZIP> 表中，并将 EMP_ZIP 作为主键。

EMPLOYEE 表

EMPLOYEE_ZIP 表

第三范式中的异常

即使关系处于 3NF，它仍然会遇到插入、删除和更新异常。因此，在讨论下一个更高的范式之前，我们将解释这些异常。

为了讨论各种异常，我们将考虑 STAFF 关系，该关系保存有关员工、他们分配的设备以及他们流利的语言的信息。

STAFF (@S_Name + @Equipment + @Language) 其中 @ 符号表示它是主键。

STAFF 关系

在上面的可视化中，它显示这不是一个关系。为了将其表示为 1NF 中的关系，我们需要将其转换为如下表所示的形式。

STAFF 关系

在上述关系中，每个 STAFF 都有两组独立的特征与之相关。

STAFF 关系的主键由 S_Name、Equipment 和 Language 组成。没有传递依赖，因此 STAFF 关系处于 3NF。但它仍然存在插入、删除和更新异常，具体解释如下。

插入异常： 假设一个 Anurag 学习了一门新语言日语，那么我们就必须在 STAFF 关系中插入两条新记录。同样，如果与 staff Anurag 对应的 Equipment 值从 2 变为 5，那么随着新语言日语的引入，我们将不得不插入多条记录到 STAFF 关系中，从而导致冗余。

删除异常： 假设 staff 的名字由于某些原因从 Anurag 更改为 Anuraj，那么就需要更新多条记录，这可能导致数据不一致。

更新异常： 假设 staff Kapil 的设备 PC 被解除分配，那么由于删除这些记录，他的所有语言技能信息都将丢失，这可能导致重要信息的丢失。

所有这些异常都是由于存在多值依赖而遇到的，多值依赖将在第四范式中消除。多值依赖和 4NF 的概念将在后面解释。