数据库三范式（Normalization）是关系型数据库设计的核心原则，旨在减少数据冗余、提高数据一致性，并避免插入、更新和删除异常。以下是三范式的详细说明：
第一范式（1NF）
核心要求：确保表中每列的值是原子性的（不可再分的最小数据单元）。
规则：
- 表中每一列必须是单一值，不能包含重复组、数组或嵌套结构。
- 每个表必须有唯一的主键（唯一标识每一行）。
示例：
假设有一个 用户表，包含字段 用户ID、用户名 和 联系方式，其中 联系方式 存储了多个电话号码（如 "123-456, 789-012"）。
违反1NF：联系方式 不是原子值，包含多个电话号码。
符合1NF的改进：
- 拆分出独立的
用户电话表，通过外键关联用户ID，每个电话号码单独一行。
第二范式（2NF）
核心要求：在满足1NF的基础上，消除部分依赖（非主键字段必须完全依赖主键）。
规则：
- 表中所有非主键字段必须完全依赖于整个主键，而非主键的一部分。
- 通常针对联合主键的表（多个字段共同作为主键）。
示例：
假设有一个 订单明细表，主键为 订单ID + 产品ID，同时包含字段 产品名称、数量、单价。
违反2NF：产品名称 仅依赖于 产品ID（主键的一部分），而非整个主键（订单ID + 产品ID）。
符合2NF的改进：
- 拆分出
产品表（主键为产品ID，包含产品名称、单价）。 订单明细表仅保留订单ID、产品ID和数量。
第三范式（3NF）
核心要求：在满足2NF的基础上，消除传递依赖（非主键字段不能依赖于其他非主键字段）。
规则：
- 所有非主键字段必须直接依赖于主键，不能间接依赖（通过其他非主键字段）。
- 通俗理解：表中不应存在“A依赖B，B依赖主键”的情况。
示例：
假设有一个 员工表，包含字段 员工ID（主键）、姓名、部门编号、部门名称、部门地址。
违反3NF：部门名称 和 部门地址 依赖于 部门编号，而 部门编号 又依赖于主键 员工ID，形成传递依赖。
符合3NF的改进：
- 拆分出
部门表（主键为部门编号，包含部门名称、部门地址）。 员工表仅保留员工ID、姓名、部门编号（作为外键）。
三范式的优缺点
优点：
- 减少数据冗余，节省存储空间。
- 避免数据不一致（如修改一处需同步多处）。
- 防止操作异常（如插入无主键记录、删除关键数据等）。
缺点：
- 过度范式化可能导致多表关联查询，降低性能。
- 实际业务中可能需要权衡范式化与反范式化（如数据仓库常用星型模型）。
实际应用建议
- 优先满足3NF：大多数事务型系统（OLTP）需严格遵循三范式。
- 反范式化优化：分析型系统（OLAP）可通过冗余字段提升查询效率。
- 灵活调整：根据业务需求、性能要求和数据量权衡范式级别。
通过遵循三范式，可以设计出结构清晰、高效且易于维护的数据库。
