范式化设计
范式:
范式来自英文Normal Form 简称NF
- 定义:范式是数据库设计中的规则或准则,遵守这些规则可以将数据库设计成具有更高数据一致性、更少冗余和更易维护的结构。
- 核心目标:使数据存储尽量避免以下问题:
- 数据冗余:同一数据重复存储在多个地方。
- 插入异常:某些字段无法插入(例如依赖其他字段的存在)。
- 更新异常:更新数据时需要修改多处,容易导致数据不一致。
- 删除异常:删除一条记录时意外删除其他重要数据。
六种范式:
第一范式,第二范式,第三范式,巴斯-科德范式(BCNF),第四范式,第五范式(完美范式)
1.第一范式(1NF):
定义:属于第一范式关系的所以属性都不可再分,数据项不可再分
理解:第一范式强调数据项的原子性,其他范式的基础。
例如:
非第一范式
| id | name-age |
|---|---|
| 1 | 小王-10 |
| 2 | 小明-12 |
第一范式
| id | name | age |
|---|---|---|
| 1 | 小王 | 10 |
| 2 | 小明 | 12 |
注:关系型数据库管理系统(RDBMS),mysql ,sqlserver,Oracle中创建数据表时候,1NF是所有关系型数据设计 最基本要求。
第一范式要求:
1.每一列属性都是不可再分,确保每一列的原子性。
2.两列的属性相近或者相似或者一样,尽量合并属性一样的列,确保不产生冗余数据。
3.单一属性的列基本数据类型构成。
4.设计出来的表都是简单二维表。
2.第二范式(2NF)
- 满足第一范式(1NF):所有字段的数据必须是原子性的(不可分割)。
- 消除部分依赖:每个非主键字段必须完全依赖于主键,而不能依赖于主键的一部分(即不存在“部分依赖”)。
- 例如:

依赖的定义:
- 完全依赖:一个非主键字段依赖于整个主键。
- 部分依赖:一个非主键字段仅依赖于复合主键中的一部分。
- 传递依赖:非主键字段通过其他非主键字段间接依赖于主键。
第二范式(2NF,Second Normal Form) 是关系数据库设计中的一种规范化标准,用来减少数据冗余和消除数据的不一致性。在数据库设计中,第二范式的重点是消除“部分依赖”
2NF 的关键问题
- 当一个表的主键是复合主键(由多个字段组成)时,非主键字段只依赖于主键的一部分,这就是部分依赖,需要消除。
2NF 的规则
如果表中存在复合主键,确保:
- 非主键字段必须依赖于整个主键,而不是其中的某一部分。
2NF 的优点
- 减少数据冗余:如商品名称不再重复存储。
- 避免数据不一致:修改商品名称时,只需更新
Products表。 - 提高可维护性:更容易进行插入、更新和删除操作。
3. 第三范式(3NF)
满足第二范式是前提
第三范式的核心概念:消除传递依赖。
第三范式要求一个数据库表中不包含已在其它表中包含的非主关键字信息。即:数据不能存在传递关系。
订单表:
| 订单ID | 订单时间 | 产品ID | 产品名称 |
|---|---|---|---|
| 1 | 2025-01-10 | 1 | 电脑 |
| 2 | 2025-01-10 | 2 | 耳机 |
产品表:
| 产品ID | 产品名称 |
|---|---|
| 1 | 电脑 |
| 2 | 耳机 |
存在的问题:
产品名称是通过产品ID可以唯一确定的,但它同时也被存储在订单表中。- 这是一个 传递依赖:
- 订单ID → 产品ID → 产品名称。
- 产品名称 不直接依赖于主键 订单ID,而是通过 产品ID 间接依赖。
如果你想确保数据库设计符合第三范式:
- 每个字段的信息都应尽量只出现在一张表中。
- 通过外键实现表之间的关联,避免重复存储信息。
- 消除数据的传递依赖,让表的结构清晰简洁。
676



被折叠的 条评论
为什么被折叠?



