第三范式 3NF

本文基于 DAMA 体系资料整理，约 1542 字。

一、核心定义与目标

第三范式 是关系数据库规范化过程中的一个关键阶段。

核心定义：一个关系表满足第二范式，且其所有非主属性都不传递依赖于任何主键。

通俗理解：表中的每一列数据都必须直接描述该表所代表的实体对象，而不能是描述另一个实体对象的。即，“不存在对主键的间接依赖”。

主要目标：

消除数据冗余：确保同一个事实在数据库中只存储一次。

防止数据更新异常：避免在插入、更新或删除数据时出现逻辑不一致。

确保数据结构的清晰性和业务正确性：使数据模型能够真实、直接地反映业务概念。

二、理解3NF需要知道的三个步骤（范式演进）

3NF通常是在第一范式（1NF）和第二范式（2NF）的基础上实现的。这个演进过程可以清晰地展示如下：

第一范式：

规则：表中的每个属性（列）都必须是原子的、不可再分的。

示例：客户地址 字段不能存储“北京市海淀区中关村大街1号”，而应拆分为 所在城市、街道地址 等多个原子字段。

第二范式：

前提：满足1NF。

规则：表必须有一个主键，且所有非主属性必须完全依赖于整个主键，而不能仅依赖于主键的一部分。

示例：一个 (订单ID, 产品ID) 作为联合主键的表中，产品名称 只依赖于 产品ID，而不依赖于整个主键，这就违反了2NF。解决方法是将 产品名称 移到独立的 产品表中。

第三范式：

前提：满足2NF。

规则：所有非主属性必须直接依赖于主键，而不能依赖于其他非主属性。即，不能存在“A依赖于B，B依赖于主键”的传递链。

三、一个经典的3NF违反示例与修正

假设我们有一个 员工部门表：

初始表（违反3NF）:

问题分析（传递依赖）:

员工ID → 部门ID

部门ID → 部门名称, 部门所在地

因此，部门名称 和 部门所在地 传递依赖于 员工ID。

这会导致哪些问题？

数据冗余：部门信息（D01，销售部，北京）在每位该部门的员工记录中重复存储。销售部在北京这个事实，存了两次。

更新异常：如果要把销售部改名为“市场部”，需要更新所有销售部员工的记录，极易出现遗漏和不一致。如果销售部要搬去广州，你必须把表中所有“销售部”员工的记录都找出来改一遍，万一漏了一个，数据就不一致了。

插入异常：如果公司新成立一个“法务部”，但还没有招聘员工，那么这个部门信息将无法存入数据库，因为没有员工ID作为主键。

删除异常：如果删除了某部门的最后一名员工，该部门的信息也会随之丢失。比如：张三离职了，你删掉他的记录，万一他是销售部最后一名员工，那“公司有销售部，并且销售部在北京”这个重要信息就跟着一起被删除了！

遵循3NF的修正方案:

我们将上表拆解为两个表，以消除传递依赖：

员工表:

部门表:

现在：

员工表 中的非主属性（员工姓名, 部门ID）都直接依赖于主键 员工ID。

部门表 中的非主属性（部门名称, 部门所在地）都直接依赖于主键 部门ID。

消除了传递依赖，数据冗余和上述所有异常问题都得到了解决。

这样改完的好处：

现在，“销售部在北京”这个事实在整个数据库里只存了一次。你想修改部门地点，只需要在部门表里修改一次就行了。这就是第三范式要做的事——让每个事实只出现一次。

四、3NF在DAMA体系中的重要性

在DAMA框架下，3NF不仅仅是一个技术规范，它更是：

数据质量的基石：通过消除冗余和不一致，直接从结构上保障了数据的准确性和一致性，这是数据质量管理的核心诉求。

高效数据架构的体现：一个符合3NF的模型是清晰、稳定和灵活的，它能够更好地适应业务变化，是数据架构和数据建模工作追求的优秀成果。

支持数据集成与共享：当不同系统都遵循规范的模型时，数据在不同系统间的流动和集成（数据集成与互操作）会变得更加容易。

业务规则的反映：一个规范化的数据模型能够更真实、更直接地反映业务实体和规则，便于业务人员理解和验证，加强了IT与业务的沟通。