数据库五大范式是关系数据库设计的核心原则，用于消除数据冗余和异常。第一范式（1NF）要求表中每个字段原子化，无重复组；第二范式（2NF）要求消除非主键的部分依赖；第三范式（3NF）消除传递依赖；BCNF进一步处理多候选键情况；第四范式（4NF）处理多值依赖；第五范式（5NF）处理连接依赖。通过逐步规范化，可以设计出高效、可靠的数据库，避免插入、更新、删除异常。实际应用中，通常到3NF即可，过高范式可能牺牲性能。

第一范式（1NF）

第一范式是关系模型的最基本要求。1NF要求表的每个属性都是原子值，不可再分。也就是说，表中的每个字段只能包含单个不可分割的数据项，不能包含集合、数组或记录。例如，一个学生表不能有“课程”字段存储多个课程值，而应拆分成多行或单独表。违反1NF会导致查询复杂和数据不一致。

第二范式（2NF）

第二范式在1NF基础上，要求表中非主键列完全依赖于整个主键，而非部分主键。消除非主属性对复合主键的部分依赖。例如，订单表中订单ID和产品ID作为复合主键，产品名称只依赖产品ID，应拆分到产品表中。这样避免了当产品信息更新时，需要修改多行订单记录。

第三范式（3NF）

第三范式进一步要求非主键列直接依赖主键，不存在传递依赖。例如，学生表中有学生ID、主修系ID、系名称，主修系ID依赖学生ID，但系名称依赖主修系ID，应将系信息独立到系表。这样防止系名称变更时影响学生记录。

巴斯-科德范式（BCNF）

BCNF是3NF的加强版，要求每个决定因素都是候选键。针对多候选键且存在非平凡依赖的情况。例如，教师表中课程和教师间依赖复杂时，需要进一步拆分。BCNF能更好地消除异常，但可能增加表数量。

第四范式（4NF）

第四范式处理多值依赖，即非主键属性对主键的多值依赖。例如，一个表同时记录教师教的课程和教师的电话，教师-课程和教师-电话间独立，应拆分成两个表。这样避免了不必要的笛卡尔积。

第五范式（5NF）

第五范式也称投影连接范式（PJ/NF），要求表不能通过投影和连接自然恢复原表，除非所有投影本身都是5NF。处理复杂连接依赖，如代理商-产品-城市关系，无法用低范式分解时，用5NF确保无冗余信息丢失。

范式应用问题

在实际数据库设计中，完全追求5NF会增加JOIN操作，降低查询性能。通常到3NF平衡冗余与效率。反范式化有时故意引入冗余提升读性能，如在数据仓库中。选择范式需考虑业务需求、查询模式和硬件资源。

FAQ
Q: 为什么不总是用第五范式？
A: 5NF分解过多，导致表多、JOIN复杂，查询慢，实际多用3NF。
Q: 范式化会丢失数据吗？
A: 正确规范化不会丢失数据，通过JOIN可恢复。
Q: 什么是部分依赖？
A: 非键属性只依赖复合键的部分属性，如订单详情中产品名只依产品ID。
Q: BCNF和3NF区别？
A: BCNF要求所有决定因子是超键，3NF允许非超键决定非主属性。