SQL数据库范式是关系型数据库设计的核心规范，用于减少数据冗余、保证数据一致性，其中第一范式、第二范式、第三范式是最常用的基础范式，理解这三个范式是做好数据库表设计的前提。
什么是数据库范式
数据库范式是一系列基于关系模型的规范化规则，每一级范式都建立在前一级范式的基础上，要求更严格。范式等级越高，表结构的冗余度越低，但查询时的关联复杂度可能会上升，实际设计中需要根据业务场景平衡范式和性能的关系。
第一范式（1NF）
第一范式是最基础的范式要求，核心是所有字段都是不可再分的原子值，同一列不能存储多个值，也不能出现重复的列。
违反1NF的案例
下面是一张不符合第一范式的用户表，其中联系方式字段存储了多个值：
-- 不符合第一范式的用户表
CREATE TABLE user_1nf_error (
user_id INT PRIMARY KEY,
user_name VARCHAR(50),
-- 联系方式字段存储了电话和邮箱两个值，可再分，违反1NF
contact_info VARCHAR(200)
);
符合1NF的优化方案
将可再分的字段拆分，每个字段只存储一个原子值：
-- 符合第一范式的用户表
CREATE TABLE user_1nf (
user_id INT PRIMARY KEY,
user_name VARCHAR(50),
phone VARCHAR(20),
email VARCHAR(100)
);
第二范式（2NF）
第二范式建立在第一范式的基础上，要求表中的所有非主键字段必须完全依赖于整个主键，而不能只依赖主键的一部分。第二范式只针对有联合主键的表，单主键的表只要符合1NF就自动符合2NF。
违反2NF的案例
下面是一张订单明细表，使用订单ID和产品ID作为联合主键：
-- 不符合第二范式的订单明细表
CREATE TABLE order_detail_2nf_error (
order_id INT,
product_id INT,
product_name VARCHAR(100),
product_price DECIMAL(10,2),
buy_num INT,
PRIMARY KEY (order_id, product_id)
);
这张表中，product_name和product_price只依赖于联合主键中的product_id，不依赖order_id，属于部分依赖，违反第二范式。这样的设计会导致产品信息重复存储，产品名称修改时需要修改所有相关订单记录。
符合2NF的优化方案
将表拆分为订单明细表和商品表，消除部分依赖：
-- 商品表，存储商品基础信息
CREATE TABLE product (
product_id INT PRIMARY KEY,
product_name VARCHAR(100),
product_price DECIMAL(10,2)
);
-- 订单明细表，只存储和订单、商品关联的信息
CREATE TABLE order_detail (
order_id INT,
product_id INT,
buy_num INT,
PRIMARY KEY (order_id, product_id),
FOREIGN KEY (product_id) REFERENCES product(product_id)
);
第三范式（3NF）
第三范式建立在第二范式的基础上，要求表中的所有非主键字段必须直接依赖于主键，不能存在传递依赖，也就是非主键字段不能依赖于其他非主键字段。
违反3NF的案例
下面是一张员工表，部门名称依赖于部门ID，而部门ID依赖于员工ID，存在传递依赖：
-- 不符合第三范式的员工表
CREATE TABLE employee_3nf_error (
emp_id INT PRIMARY KEY,
emp_name VARCHAR(50),
dept_id INT,
dept_name VARCHAR(50)
);
这张表中，dept_name依赖于dept_id，dept_id依赖于emp_id，因此dept_name传递依赖于emp_id，违反第三范式。当部门名称修改时，需要修改所有该部门的员工记录，容易出现数据不一致。
符合3NF的优化方案
将表拆分为员工表和部门表，消除传递依赖：
-- 部门表，存储部门基础信息
CREATE TABLE department (
dept_id INT PRIMARY KEY,
dept_name VARCHAR(50)
);
-- 员工表，只存储员工直接关联的信息
CREATE TABLE employee (
emp_id INT PRIMARY KEY,
emp_name VARCHAR(50),
dept_id INT,
FOREIGN KEY (dept_id) REFERENCES department(dept_id)
);
三大范式的应用建议
实际数据库设计中，不需要盲目追求高范式，需要根据业务场景调整：
- 核心业务表建议至少符合第三范式，保证数据一致性，减少冗余。
- 频繁查询的表可以适当反范式，增加冗余字段减少关联查询，提升查询性能。
- 临时表、统计表可以根据需求灵活设计，不需要严格遵循范式。
判断表是否符合范式时，可以按照1NF、2NF、3NF的顺序依次检查，先保证字段原子性，再消除部分依赖，最后消除传递依赖，就能逐步得到规范的表结构。