本文最后更新于7 天前，其中的信息可能已经过时，如有错误请发送邮件到PZ_0828@163.com
数据库范式是一系列设计规则，旨在减少数据冗余、提高数据一致性并消除数据操作异常（插入异常、更新异常、删除异常）。三范式（1NF, 2NF, 3NF）是其中最基础和最重要的几个级别，它们之间存在递进关系，即满足 2NF 必须先满足 1NF，满足 3NF 必须先满足 2NF。
可以把它粗略地理解为一张数据表的表结构所符合的某种设计标准的级别。
第一范式 (1NF – First Normal Form)
- 核心定义： 确保数据库表的每一列都是原子性的，即每一列都只包含不可再分的单一值。
- 违反示例： 表中有一个“联系方式”列，存储了多个值如“电话:138xxxx, 邮箱:abc@mail.com”。
- 满足 1NF 的修正： 将“联系方式”拆分成单独的“电话号码”列和“电子邮箱”列。
第二范式 (2NF – Second Normal Form)
- 核心定义： 消除部分函数依赖。要求表中的非主键属性必须完全依赖于整个主键，而不能只依赖于主键的一部分。
- 核心要求：
- 表必须有主键（单列主键或复合主键）。
- 所有非主键字段都必须完全函数依赖于整个主键。
- 违反场景（常见于复合主键）： 订单明细表订单ID产品ID产品名称单价数量1001P001手机500021001P002耳机30011002P001手机50001主键：
(订单ID, 产品ID)（联合主键）产品名称和单价只依赖产品ID，而不依赖订单ID（部分依赖）。 - 满足 2NF 的修正： 订单表（依赖订单ID + 产品ID）订单ID产品ID数量1001P00121001P00211002P0011产品表（仅依赖产品ID）产品ID产品名称单价P001手机5000P002耳机300
第三范式 (3NF – Third Normal Form)
- 核心定义： 消除传递函数依赖。要求任何非主键属性之间不能存在传递依赖关系，即非主键属性必须直接依赖于主键，而不能依赖于另一个非主键属性。
- 核心要求：
- 所有非主键字段都必须直接函数依赖于主键。
- 非主键字段之间不存在函数依赖关系。
- 违反示例：
| 学号(主键) | 姓名 | 所属学院 | 学院ID | 学院地址 | 学院电话 |
|---|---|---|---|---|---|
| 001 | 王大明 | 计算机学院 | X01 | 科技楼A座 | 1000 |
| 002 | 王二明 | 网络空间安全学院 | X02 | 科技楼B座 | 1001 |
| 003 | 王小明 | 电器工程学院 | X03 | 科技楼C座 | 1002 |
- 满足 3NF 的修正： 将存在传递依赖的属性拆分到单独的表中。例如，创建单独的“学院”表（主键
学院ID或学院名称，包含字段学院ID, 学院名称, 学院地址, 学院电话），然后在“学生”表中只保留所属学院ID（作为外键）。
学生表（仅依赖学生ID）
| 学号(主键) | 姓名 | 学院ID |
|---|---|---|
| 001 | 王大明 | X01 |
| 002 | 王二明 | X02 |
| 003 | 王小明 | X03 |
学院表（仅依赖学院ID）
| 学院ID(主键) | 学院名称 | 学院地址 | 学院电话 |
|---|---|---|---|
| X01 | 计算机学院 | 科技楼A座 | 1000 |
| X02 | 网络空间安全学院 | 科技楼B座 | 1001 |
| X03 | 电器工程学院 | 科技楼C座 | 1002 |
总结
| 范式 | 核心规则 | 解决的问题 |
|---|---|---|
| 1NF | 字段原子性，每行有唯一主键 | 数据不可再分 |
| 2NF | 非主键字段必须完全依赖主键（消除部分依赖） | 联合主键表的冗余问题 |
| 3NF | 非主键字段不能传递依赖主键（消除冗余依赖） | 数据冗余和更新异常 |
三范式是数据库设计的核心规则（1NF保证原子性，2NF消除部分依赖，3NF消除传递依赖），其核心作用是减少冗余、保证数据一致性、避免操作异常。有时也会反范式化（如数据仓库、报表系统），以提高查询效率。
