数据库设计三大范式

1. 数据库范式-简介

数据库范式（Database Normalization）是关系型数据库设计的理论基础，通过一系列约束条件规范表结构，解决数据冗余和操作异常问题。

在实际工程中，通常只需掌握 1NF/2NF/3NF。它们呈递进关系：每一级范式在前一级基础上增加约束，逐步消除特定类型的数据依赖问题。

下面的案例刻意保持简单：1NF 用用户地址说明原子性，2NF 用订单明细说明部分依赖，3NF 再回到地址编码说明传递依赖。

2. 第一范式（1NF）：原子性约束

2.1 定义

1NF是所有范式的基石，要求：

• 字段值不可再分：每个单元格存储单一值，不包含列表或复合结构
• 无重复组：同一行不包含多个语义相同的子列
• 每行唯一：需有主键或唯一标识（部分教材将此归为1NF要求，部分归为表设计基础）

2.2 违规案例

user（用户表） 把完整地址放在一个字段里：

本例假设系统需要按省、市、区检索和统计地址，因此完整地址对当前业务而言不是一个不可再分的值。

问题分析：

• address 同时包含省、市、区和详细门牌，字段值不是原子值
• 按城市筛选、统计或建索引时，只能做字符串匹配
• 省市区格式缺乏结构约束，容易出现写法不一致

2.3 1NF合规设计

实际落表时，把复合地址拆成多个原子字段：

user（用户表）

改进点：

• 地址字段结构化，支持按省市区筛选和统计
• district_code 可以作为行政区划编码，便于和标准地区表关联
• 可在 city、district_code 等字段建立索引优化查询

3. 第二范式（2NF）：消除部分依赖

3.1 定义

在满足1NF基础上，非主属性必须完全依赖于整个候选键，不能只依赖复合候选键的一部分。工程案例通常以主键作为候选键进行分析。

3.2 违规案例

订单明细表混入订单信息和商品信息。简化假设同一订单中同一商品只出现一次，则可用 (order_id, product_id) 作为业务主键：

order_item（订单明细表）

主键：(order_id, product_id)

依赖分析：

• ordered_at 仅依赖 order_id（部分依赖）
• product_name 仅依赖 product_id（部分依赖）
• quantity、price 才依赖完整的 (order_id, product_id)

潜在异常：

• 更新异常：同一订单的下单时间、同一商品的名称在多行中重复，修改时容易漏改
• 插入异常：新建商品但还没有订单时，无法放进订单明细表
• 删除异常：删除某商品最后一条订单明细后，商品基础信息随之丢失

3.3 2NF合规设计

把只依赖 order_id 的字段移到订单表，把只依赖 product_id 的字段移到商品表，订单明细只保留真正依赖整组主键的字段。

order（订单表）

product（商品表）

order_item（订单明细表）

验证：

• order、product 使用单列主键，不存在部分依赖
• order_item 仍使用复合主键，但 quantity、price 都依赖完整的 (order_id, product_id)
• 2NF 关注的是复合候选键场景下的部分依赖，不处理非主属性之间的间接依赖

4. 第三范式（3NF）：消除传递依赖

4.1 定义

在满足2NF基础上，非主属性不能通过其他非主属性传递依赖于候选键。工程上常简化为：非主键字段应直接描述本表主键所代表的实体或关系。

传递依赖链：候选键 → 非主属性A → 非主属性B

4.2 违规案例

回到 1NF 后的 user 表。本例只有单列候选键 user_id，因此满足2NF，但仍然有传递依赖：

user（用户表）

主键：user_id

依赖分析：

• user_id → district_code、address
• district_code → province、city、district
• 因此 province、city、district 不是直接依赖 user_id，而是通过 district_code 间接依赖于 user_id

风险：

• 数据冗余：同一个 district_code 对应的省市区名称会在多位用户记录中重复存储
• 更新异常：地区名称或行政区划调整时，需更新所有相关用户行
• 引用风险：可能出现同一个 district_code 对应不同省市区名称的数据不一致

4.3 3NF合规设计

把地区信息拆成独立地区表，用户表只保留地区编码和详细门牌：

user（用户表）

district（地区表）

优势：

• 地区信息统一维护，district_code 成为省市区名称的单一事实来源
• 用户表中的 address 表示详细门牌，直接依赖 user_id
• 可通过外键约束确保 district_code 有效性

5. 反范式化：性能与一致性的权衡

5.1 为什么需要反范式化

范式化不是越彻底越好。是否引入冗余，通常来自三类需求：

• 查询性能：高并发读取需要减少频繁的多表关联，但应先通过执行计划和压测确认瓶颈
• 系统边界：微服务或分库场景无法直接跨服务JOIN，需要构建本地查询投影
• 历史语义：订单必须保留下单时的收件信息和商品名称，而不是读取主数据的当前值

5.2 反范式化案例：订单系统优化

5.2.1 只引用当前主数据的范式化设计

user（用户表）

order（订单表）

order_item（订单明细）

product（商品表）

product.price 表示当前报价，只用于新交易；order_item.price 表示成交价，用于还原历史订单。字段含义由所在表的业务上下文确定。

查询SQL：

SELECT
    o.order_id,
    u.name AS username,
    p.name AS product_name,
    oi.price,
    oi.quantity,
    oi.price * oi.quantity AS amount
FROM `order` o
JOIN user u ON o.user_id = u.user_id
JOIN order_item oi ON o.order_id = oi.order_id
JOIN product p ON oi.product_id = p.product_id
WHERE o.order_id = 'T202602260001';

问题：

• 该查询需要关联4张表；索引合理时未必慢，但在高并发、跨库或跨服务场景下成本会明显增加
• 用户名、商品名来自当前主数据，后续修改后，历史订单会显示当前名称而不是下单时名称
• order_item.price 是订单明细自身的交易事实，必须在下单时写入；不能使用 product.price 回算历史订单

5.2.2 反范式化设计（快照模式）

快照模式在交易发生时复制必要的展示信息，并将其作为不可变的历史事实保存。它的目标首先是历史可追溯，其次才是减少查询时的主数据关联。

order（订单表）

order_item（订单明细表）

优化点：

• 订单详情只需关联 order 与 order_item，不再关联当前用户表和商品表
• 收件信息和 order_item.name 记录下单时状态，不受后续用户、商品信息变更影响
• price 是成交价；amount 可保存优惠、舍入等规则计算后的最终明细金额
• user_id、product_id 仍然保留，用于追踪来源、售后处理和数据分析

查询SQL：

SELECT
    o.order_id,
    o.receiver_name,
    o.receiver_phone,
    o.receiver_address,
    o.create_at,
    oi.product_id,
    oi.name AS product_name,
    oi.price,
    oi.quantity,
    oi.amount
FROM `order` o
JOIN order_item oi ON o.order_id = oi.order_id
WHERE o.order_id = 'T202602260001';

5.3 反范式化的实施策略

反范式化字段必须先区分语义：历史快照允许有意保留旧值，查询冗余才需要跟随主数据同步。二者不能使用同一套一致性策略。

5.4 收益与代价分析

收益：

• 查询性能提升：减少主数据JOIN，查询可使用更少的表和更直接的索引
• 系统吞吐量增加：降低数据库CPU和IO压力
• 服务稳定性：避免慢查询引发的级联故障
• 业务准确性：快照字段保障历史数据可追溯

代价：

• 存储成本增加：冗余字段占用额外磁盘空间
• 写入延迟增加：单次操作需更新多行或多表
• 一致性语义更复杂：必须区分不可变快照与需要持续同步的查询冗余
• 代码复杂度上升：写入逻辑需处理快照复制、查询投影同步和失败补偿

6. 实际项目设计思路

三范式是数据库设计的基础。项目开始时，应先按照三范式整理表结构，保证数据关系清晰，避免不必要的重复。

完成基础设计后，再向 项目经理 或 产品经理 确认后续需求：

• 查询需求：是否存在频繁使用、响应速度要求较高的查询
• 分析需求：是否需要报表、统计或后续的数据分析

如果需求明确，再根据实际场景进行二次设计；如果暂时没有这些需求，保持 三范式设计 即可。

数据库设计通常不是一次完成的。前期应了解后续方向并预留扩展空间，但不必在需求尚未明确时提前增加复杂结构。

7. 总结

7.1 范式核心要点