数据库范式

从 1NF 到 3NF

第一范式（1NF）：每个字段只存原子值，不能是集合或列表。把「联系方式」字段存成「13800138000,010-12345678」违反 1NF。

第二范式（2NF）：在满足 1NF 的基础上，非主键字段必须完全依赖于整个主键，不能只依赖主键的一部分。经典反例：选课表（学生ID, 课程ID, 学生姓名, 成绩），学生姓名只依赖学生ID，与课程ID无关，应拆分为学生表和选课表。

第三范式（3NF）：非主键字段不能依赖另一个非主键字段（消除传递依赖）。订单表里存了「客户ID、客户城市、省份」，省份依赖城市，城市依赖客户ID，这是传递依赖，应把城市-省份关系放到独立的地区表中。[1]

范式与反范式

严格遵循范式可以消除数据异常，但会产生大量表拆分和 JOIN 操作。在 OLAP 场景下，大量 JOIN 性能极差，数据仓库往往反其道而行——采用反范式设计，把多个表的常用字段冗余到一张宽表（事实表）中，用空间换查询速度。

星型模型（Star Schema）和雪花模型（Snowflake Schema）是数据仓库常用的设计模式，都是在范式和查询性能之间取平衡的工程妥协。现实世界的数据库设计从来不是纯粹按范式推导的学术练习，而是要根据读写比例、数据规模和查询模式做具体权衡。