软件设计师 · 数据库设计 · 范式

第二范式和第三范式为什么容易混？

范式题让人头疼，不是因为概念多，而是因为很多同学没有先找“谁决定谁”。第二范式和第三范式看起来都在消除冗余，但它们盯的依赖关系不一样。把部分依赖和传递依赖分清，范式题会轻松不少。

软件设计师专题软考题库编辑部持续更新

内容整理：软考题库编辑部最近更新：2026-06-13

范式题先找候选键，再看非主属性

做范式题，第一步不是背 1NF、2NF、3NF 的定义，而是找候选键。候选键能唯一标识一条记录，后面判断部分依赖、传递依赖，都要围绕候选键展开。

找到候选键以后，再看非主属性是怎么被决定的。如果非主属性只依赖复合候选键的一部分，就是第二范式要处理的问题；如果非主属性通过另一个非主属性间接依赖候选键，就是第三范式要处理的问题。

第二范式通常出现在复合候选键场景。比如选课关系中，主键可能是“学号 + 课程号”。成绩依赖学号和课程号一起确定，这很正常；但学生姓名只依赖学号，课程名称只依赖课程号，这就是部分依赖的味道。

如果题目给的是单属性候选键，通常就不会出现对复合键一部分的部分依赖。看到复合键时要格外敏感：非主属性到底是依赖整个键，还是只依赖其中一列？这是第二范式题的核心。

关系：选课(学号, 课程号, 姓名, 课程名, 成绩)。

成绩依赖学号和课程号组合，比较合理。

姓名只依赖学号，课程名只依赖课程号，这就是部分依赖风险。

第三范式关注传递依赖。比如学号决定系号，系号又决定系名，那么学号就通过系号间接决定了系名。系名不是直接围绕学号这个实体事实存在，而是跟系号绑定，这就容易带来冗余和更新异常。

老师讲第三范式时常说一句：非主属性不要替候选键继续当老板。也就是说，非主属性不应该再去决定另一个非主属性。只要看到这种“绕了一层”的决定关系，就要警惕传递依赖。

看到数据冗余，不等于一定是第三范式问题。先看是不是属性不原子，再看有没有部分依赖，最后再看传递依赖。范式判断有顺序，跳步很容易把第二范式的问题误判成第三范式。

复习时可以用一句话压住：2NF 管“非主属性别只依赖复合键的一部分”，3NF 管“非主属性别再决定非主属性”。这句话比单纯背定义更适合做选择题和下午题分析。