软考数据库范式怎么学？从1NF到BCNF层层拆解，函数依赖与候选码一篇讲透

引言

在所有软考中级科目中，数据库范式是一个让考生又爱又恨的知识点。爱的是它逻辑严密、环环相扣，一旦学透就像打通任督二脉；恨的是初学时函数依赖、传递依赖、多值依赖这些概念缠在一起，再加一个 Armstrong 公理系统，很容易在考场上一头雾水。

翻阅近五年的数据库系统工程师和软件设计师真题，范式相关的题目从未缺席。2022 年数据库真题要求判断一个学生关系模式的最高范式并评价分解结果，2023 年软设真题让你计算候选关键字和主属性数量，2024 年又考到了 4NF 与多值依赖的关系。命题人不是简单地让你背"1NF 要原子化、2NF 要消除部分依赖、3NF 要消除传递依赖"这三句话，而是把函数依赖推理、候选码计算、范式判定和模式分解揉在同一个题目里考。

本文的目标是把数据库范式从最底层的函数依赖概念拆起，一路推到 BCNF 和 4NF，把 Armstrong 公理系统和候选码求法讲清楚，最后用三道真题演示命题人的组卷套路。

一、概念定义——范式不是设计模式，是数据冗余的克制工具

数据库范式，英文为 Normal Form，简称 NF，是关系数据库理论中用于评价关系模式优劣的一套标准体系。它由埃德加·科德在 1970 年提出，后来经过博伊斯等人的扩展和完善，形成了从第一范式到第五范式乃至域键范式的完整层级。

范式的核心目标只有一个：减少数据冗余，消除更新异常。什么叫更新异常？一个学生换了系，如果"系名"这个信息在学生表的每一行里都存了一份，那么修改系名时就需要更新所有相关行，漏掉一行就会导致数据不一致。范式的作用就是通过规范化分解，让每个信息只在数据库中存储一次。

需要特别指出，范式等级越高不等于数据库设计越好。在实际工程中，过度规范化会导致表数量激增，每个查询都要做大量的连接操作，严重影响性能。因此业界通常以第三范式或 BCNF 作为实际设计的标准，极少会用到 4NF 以上的范式。但这个原则在考试中不适用——考试考的是"给定一个关系模式，判断它最高满足第几范式"，你不需要考虑性能，只需要按定义严格推导。

二、原理机制——函数依赖是理解范式的唯一钥匙

范式体系的核心基础是数据依赖，数据依赖中最重要的是函数依赖。函数依赖的形式化定义是：设关系模式 R 的属性集为 U，X 和 Y 是 U 的子集。如果对于 R 的任意一个可能的关系实例中的任意两个元组，只要它们在 X 上的取值相等，它们在 Y 上的取值也必然相等，则称 X 函数确定 Y，或称 Y 函数依赖于 X，记作 X 指向 Y。

这个定义表述上有些拗口，但含义很直观：属性 X 的值一旦确定，属性 Y 的值就唯一确定了。典型例子是"学号确定姓名"，给定一个学号，一定能查到唯一的一个姓名。而"学号确定课程号"不成立，因为一个学生可以选多门课。

函数依赖有三个关键子类，必须区分清楚。第一类是平凡函数依赖，即 Y 是 X 的子集，这种依赖永远成立但没有实际意义，比如"学号加姓名确定学号"。第二类是部分函数依赖，指在一个复合候选码中，存在某个真子集就能确定某个非主属性。最经典的例子是选课关系模式中的"学号加课程号确定学分"——实际上"课程号"单独就能确定学分，不需要学号参与，这就是部分函数依赖，是导致第二范式问题的根源。第三类是传递函数依赖，指 X 确定 Y，Y 确定 Z，但 Y 不能确定 X，即依赖关系通过中间属性间接传递。学生关系模式中"学号确定系号，系号确定系名"，所以"系名传递依赖于学号"。

与函数依赖平行存在的是多值依赖，它是 4NF 的理论基础。多值依赖的定义是：设 R 的属性集为 U，X、Y、Z 是 U 的子集且 Z 等于 U 减去 X 并 Y。如果对于 R 的每个关系实例，X 的一个取值对应 Y 的一组取值，且这组取值与 Z 的取值无关，则称 Y 多值依赖于 X。多值依赖的典型场景是"课程确定教材"和"课程确定教师"同时存在但教材和教师之间没有直接关系——一门课可以使用多本教材，也可以由多位教师讲授，教材选择与教师分配相互独立。

Armstrong 公理系统是函数依赖推理的形式化工具，由三条核心公理组成。自反律：如果 Y 是 X 的子集，则 X 确定 Y。增广律：如果 X 确定 Y，则 X 与 Z 联合确定 Y 与 Z 联合。传递律：如果 X 确定 Y 且 Y 确定 Z，则 X 确定 Z。由这三条公理可以推导出三条常用的引理：合并规则，即 X 确定 Y 且 X 确定 Z 则 X 确定 Y 与 Z 的联合；分解规则，即 X 确定 Y 与 Z 的联合则 X 确定 Y 且 X 确定 Z；伪传递规则，即 X 确定 Y 且 Y 与 W 联合确定 Z 则 X 与 W 联合确定 Z。2024 年软设真题第 49 题考的正是 Armstrong 公理系统中哪一项不是公理而是引理——"合并规律"是引理而非公理，需要从三条核心公理推导得出。

三、范式层级——从第一范式到 BCNF 的逐级消除

第一范式是最基本的要求，关系模式中的每个属性都必须是不可再分的原子值。一个典型的违反 1NF 的例子是"联系方式"属性包含了电话号码和邮箱两个子项。1NF 是关系数据库的准入门槛，不满足 1NF 的表甚至不能被称为关系。在考试中，1NF 通常不作为考点，默认所有关系模式都已满足 1NF。

第二范式在 1NF 基础上消除非主属性对候选码的部分函数依赖。这里需要先厘清主属性和非主属性的概念：主属性是包含在任意一个候选码中的属性，非主属性是不属于任何候选码的属性。2NF 要求每个非主属性必须完全函数依赖于候选码，而不能仅仅依赖于候选码的一部分。经典反例是选课关系模式，其候选码为学号与课程号的组合，学分依赖于课程号即候选码的一部分，所以学分不完全依赖于候选码，该模式最高只满足 1NF。解决方法是拆分为学生选课关系和课程关系，学分移到课程关系中去。

第三范式在 2NF 基础上消除非主属性对候选码的传递函数依赖。典型场景是学生关系模式中系名传递依赖于学号（学号确定系号，系号确定系名），该模式只达到 2NF。分解为两个关系，把系号到系名的依赖关系独立出去即可达到 3NF。

本篇完！