第二范式 (2NF)

• 在 2NF 中，关系必须是 1NF。
• 在第二范式中，所有非键属性都完全函数依赖于主键。

示例： 假设一所学校可以存储教师及其所教科目的数据。在一所学校里，一位老师可以教多门科目。

TEACHER 表

在给定的表中，非主属性 TEACHER_AGE 依赖于 TEACHER_ID，而 TEACHER_ID 是候选键的真子集。这就是它违反了 2NF 规则的原因。

为了将给定表转换为 2NF，我们将其分解为两个表

TEACHER_DETAIL 表

TEACHER_SUBJECT 表

第二范式中的异常

即使关系处于 2NF，仍然存在插入、删除和更新异常。因此，在讨论第三范式之前，我们将解释这些异常。

为了讨论各种异常，我们将考虑包含学生和教师信息的 STUDENT 关系。

在上表中，Stu_Id 是主键，充当学生的学号。

由于 STUDENT 关系仅由一个充当主键的属性（Stu_Id）组成，因此它处于 2NF。但它存在插入、删除和更新异常，解释如下。

插入异常： 假设我们要插入一条新记录，其中包含有关一位尚未分配给任何学生的新教师的信息。但此插入记录不允许，因为主键 Stu_Id 包含一个空值，这是不可能的，因为它违反了实体完整性规则。

例如： 假设我们要插入一位新教师“Mayank”的信息，其 Teach_Id = ‘206’ Teach_Qual = ‘MCA‘，他尚未分配任何学生。这是不可能的，因为 Stu_Id 将包含一个空值。

删除异常： 假设一位学号为 1768 的学生决定离开学校，因此我们必须从 STUDENT 关系中删除此元组。

从关系中可以看出，这位特定学生是 Teach_Id = ‘205’ 的老师的最后一个学生。因此，在删除此元组时，关于该老师的信息也会被删除。这可能导致关键信息的丢失。这就是删除异常。

如果决定离开学校的学生不是特定老师的最后一个学生，则不会出现删除问题。

例如： 删除学号为 2523 的学生记录不会导致 Teach_Id = ‘201’ 的老师信息被删除，因为该信息在别处存在。

更新异常： 第二范式也存在更新异常。

例如： Teach_Id = ‘204’ 的老师的学历 Teach_Qual 从 MCA 更新为 Ph.D。这会很麻烦，因为必须在信息重复出现的地方进行元组的更新。尽管此关系中的元组很少，但这会是一个很大的问题，并且可能导致不一致，因为人容易出错。

上述考虑让我们得出结论，2NF 中的关系具有不良的数据操作特性，因此将关系转换为 2NF 并不能终止逻辑数据库设计。需要进一步的转换来消除原始关系中的这类异常。因此，这就引出了我们对第三范式的概念。