软考软件设计师下午题数据库设计满分攻略：ER图·关系模式·范式精讲

软考软件设计师的下午题里，第2题数据库设计一直是个“性价比之王”。15分的分值，题型高度固定，考点就集中在ER图、关系模式、主键外键和规范化这几块，几乎年年如此。相比算法题和程序设计题那种不确定性，这道题只要方法得当、练够真题，拿个12分以上是大概率事件，甚至冲满分也完全可行。这篇我就把这道题的完整套路讲透，从ER图怎么画、关系到怎么转、范式怎么判，到哪些地方最容易丢分，一次性理清。

1. 题型特征与复习策略：为什么说这15分最好拿

下午题的120分钟要对付6道大题，前5道必答，最后一道Java和C++二选一。每道题的时间和精力分配直接决定成败。第2题数据库设计通常位于试卷第2个位置，但我的建议是，如果你不是数据库薄弱到完全没概念，这道题完全可以放在最后突击阶段重点攻克，因为它是最容易“被套路”训练出来的题型。

为什么这么说？我对比过近五年的真题。第1题数据流图考的是外部实体、数据存储的辨别，虽然不难但偶尔会出一些隐蔽的加工命名问题。第3题面向对象设计常和UML图结合，有主观成分。第4题算法题是很多人的噩梦，C语言代码分析既考阅读能力又考算法功底。最后一题编程就更不用说了，没有实打实的编码训练很难在考场上快速写对。唯独第2题，考来考去就是那么几个固定动作：补充ER图、填写关系模式、标出主外键、判断规范化程度。

以2022年下半年真题为例，考了一个“书店销售管理”场景。第一问让补充联系和联系类型，第二问让补充关系模式的属性，第三问要求说明主键外键，第四问判断某个关系模式是否满足3NF。2021年考的是“科研项目申报管理”，结构和考点几乎一模一样，只是换了个业务背景。这种出题惯性意味着，你不需要成为数据库专家，只需要把“ER图设计→转关系模式→主键外键识别→范式判断”这一条链路彻底吃透，就能覆盖绝大多数考点。

复习这道题的核心策略是“精做真题、手写为主”。我碰到过很多考生，复习时喜欢在脑内模拟，看答案觉得“哦，原来是这样”，一到考场自己动手就各种漏。画ER图、写关系模式这种事，必须亲自动笔，哪怕你对着真题答案抄，也要完整抄一遍，把每一个框、每一条连线都画出来，把每个属性都写在对应位置。这个动手的过程会暴露出非常多你以为你知道、但实际上你不知道的细节。

配套资料方面，希赛的历年真题解析和软考官方的《软件设计师教程（第5版）》数据库章节就够用了。注意是第5版，里面数据库设计章节的描述和新大纲完全对齐。如果你时间有限，不用啃完整本教程，重点看“数据库设计”和“关系代数与SQL”两个章节，和这道题直接相关的就这些。

2. ER图设计核心方法：实体、属性、联系怎么判定

ER图是整个第2题的基石，后面的关系模式转换、主键外键判断全都建立在ER图正确的基础上。很多人在这一步就错，后面满盘皆输。这一步常见的失分点是实体和属性傻傻分不清、联系类型判断出错、联系属性漏掉，这三类问题几乎覆盖了ER图环节的所有扣分点。

2.1 区分实体与属性：三条硬性标准

实体和属性的辨别，是新手最容易栽跟头的地方。考试题目中给出的描述往往是一大段文字，你要能从里面抽出哪些是实体、哪些是属性。我总结了三条判断标准，按优先级依次排查：

• 是否具备独立存在性。实体是可以独立存在并被记录的对象，而属性是对实体的描述，离开了实体就没有意义。比如“学生”可以独立存在，是实体；“姓名”是描述学生的，离开“学生”这个概念，单独的姓名没有业务意义，是属性。

• 是否被其他对象引用。如果一个概念既可以是某个实体的属性，又可能是另一个对象需要关联的信息，那它往往是实体。举一个真题里的典型例子，在“图书借阅系统”中，“出版社”一开始看起来像是图书的一个属性，但如果你还需要记录出版社的地址、联系电话，甚至要统计每个出版社出版了多少本书，那出版社就必须升级为独立实体。

• 是否具有多个属性值。如果一个概念本身还有若干子属性，它就倾向于是一个实体而不是属性。比如“职工”有职工号、姓名、部门，“部门”有部门号、部门名、负责人，那“部门”显然不能塞在“职工”里当一个简单属性。

在实际答题时，还有一个小技巧就是看题干中是否给出这个概念的“描述性字段”。如果题目明说“每个产品有产品编号、名称、价格”，那“产品”就是实体，后续标注字段时直接套用。如果某概念只被提到一次，没有对它展开描述，那大概率是属性。

2.2 联系类型判定：1:1、1:n、m:n的题眼在哪里

联系类型是最典型、最固定的考点。题干给出的文字描述中，几乎每道题都会埋几个关键量词，比如“每个”“最多”“至少”“必须”“若干个”。这些词就是判断联系类型的信号灯。

我举三种题干常见写法，大家感受一下：

• “每个班级有且仅有一名班主任，每名班主任只负责一个班级。”这种“一对一绑定”的描述，直接判定为1:1联系。

• “一个部门可以有多名员工，每名员工只能属于一个部门。”这就是1:n联系，部门是“一”方，员工是“多”方。注意题干的叙述顺序有时候会很狡猾，它会先说“多”方再说“一”方，比如“每名员工属于一个部门，一个部门可以有多名员工”，顺序变了，但联系类型不变。

• “一名学生可以选修多门课程，每门课程可以被多名学生选修。”这个是典型的m:n联系。这里的关键判定是：如果两端都出现了“多”，就是m:n。更长的量词比如“每个供应商可以为多个项目供应多种零件”，涉及三元联系，但软件设计师考试里三元联系极其罕见，大部分是二元联系，大家不用过于担心。

判断联系类型的核心逻辑其实很简单：在一个联系里，看两端实体各自允许出现多少个实例参与该联系。某端有范围限制（比如“一名员工只能属于一个部门”），那这端就是“1”；某端没有限制（“一个部门可以有多名员工”），那这端就是“n”。两端都是“1”就是1:1，一端是“1”一端是“n”就是1:n，两端都是“n”就是m:n。

2.3 联系属性和主键选择：这些小细节决定成败

ER图中，联系有时需要带属性。这个“有时”是最难把握的。判断联系属性的标准是：这个属性是描述“关联关系”本身，还是描述其中某一个实体的？“数量”就是我见过最典型的联系属性。比如“学生选课”这个联系，“成绩”既不属于学生，也不属于课程，而是产生于选课这个动作本身，它就一定是联系的属性。同理，“某员工在某部门任职的起始日期”“某商品在某仓库的库存量”这些也是联系属性。

做题时有一个小技巧：题目里如果出现“在……时”“在……期内”“每次……的……”这类介词短语，后面的名词很有可能是联系属性。比如“记录每个员工被调入每个部门的调入日期”，“调入日期”就是联系属性。

主键的选择在ER图环节一般不会单独成问，但会影响后续关系模式的作答。选择主键的原则第一条是唯一性，能唯一确定一个实例；第二条是最小性，不要用一组冗余字段当主键；第三条要避开空值，比如“电话号码”虽然是唯一的，但可能为空，就不适合当主键。真题里常常会设计一个“实体编号”字段，比如“课程编号”“商品编号”，这些就是命题人主动为你准备的候选主键，大胆使用即可。

3. ER图转关系模式的完整规则与实操演示

ER图转关系模式是整个第2题最核心的环节，近几年的考题第二问几乎必考“将以上ER图转为关系模式，补充完整各关系模式属性”。这一问的作答质量直接决定第三问主键外键和第四问范式判断的得分上限。

3.1 一对一联系：合并关系与独立关系的选择

1:1联系转换为关系模式，标准规则是：可以将联系并入任意一端实体对应的关系模式中，在并入端增加另一端实体的主键作为外键。也可以让联系单独形成一个关系模式。

但在考试实战中，我强烈建议优先采用“并入”而不是“独立成表”，因为独立成表会多出一个关系模式，而在答题卡的横线上通常已经画好了数量固定的几个空位，凭空多写一个容易和题目预期不一致。合并时具体并入哪一端，有一个实用原则：看哪一端的参与度是“强制”的、或者哪一端的实例数量更少。比如“一名员工最多拥有一张门禁卡，每张门禁卡必须属于一名员工”，在这个描述中，门禁卡对员工的依赖是被迫的，所以把员工主键并入门禁卡端更合理。

如果题目没有明确要求，你只需要做到逻辑一致即可，不需要过度纠结。但要注意，考试阅卷是按点给分，合并的选择本身一般不设唯一答案，只要外键位置正确、主键标注准确，就算对。

3.2 一对多联系：外键放在n端是铁律

1:n联系的转换规则是考试中出现频率最高的，几乎每年必考。规则只有一条：在n端（多端）关系模式中加入1端的主键作为外键。

为什么外键必须放在n端？因为在n端加外键不会产生数据冗余，而如果反着放，在1端加外键，1端的每一条记录都需要对应多端的某一条记录，这既不合理，也违背了关系模式设计的基本思想。举一个例子，部门(DEPT)和员工(EMP)是1:n联系，员工属于部门。正确做法是在EMP中加DEPT_ID作为外键，这样一条员工记录对应一个部门ID，没有任何冗余。如果反着来，在DEPT表中加EMP_ID外键，一个部门有50个员工，就需要50条部门记录或者把多个员工ID拼在一起，显然荒谬。

除了加外键，1:n联系中如果联系本身有属性，这个属性也要并入n端关系模式。比如“员工在部门任职的起始日期”，这个日期描述的是员工和部门之间的关系，在转换后应该写在EMP表里，作为DEPT_ID外键旁边的一个普通属性。

3.3 多对多联系：必须独立成表，缺一不可

m:n联系的转换规则更死板，没有任何投机空间：联系必须转换为一个独立的关系模式，该关系模式的主键是两端实体的主键的组合（联合主键），联系自身的属性也要放在这个独立关系模式里。

以最常见的“学生选课”为例。STUDENT表有学号、姓名，COURSE表有课程号、课程名，选课联系是m:n。转换后的SC表结构是：SC(学号, 课程号, 成绩)，其中主键是(学号, 课程号)，学号和课程号同时都是外键，成绩是联系属性。

真题中经常在第二问给一个关系模式的表格，其中某些单元格已经填好，让你补充剩余部分。这个时候你就要根据“属性是否为空”“主键是否标注”来反推关系类型。如果看到某个关系模式的主键是两列的组合，那八成对应的就是m:n联系。这个反向推理能力非常实用，因为不少考场上的同学只会正向推导，一遇到“给关系模式反推ER图”就蒙圈，实际上只要抓住了“联合主键=多对多联系”这个特征，难度就降低了。

3.4 主键外键的规范标注与完整示例

在书写关系模式时，主键用下划线标注，外键在答题卡上通常用英文缩写说明或用虚线样式标注，但手写时最稳妥的方式是在关系模式下方单独列出“外键：XXX”。我见过不少考生，答题时把主键画了横线，但外键既不标注也不说明，结果阅卷老师找不到得分点，白白丢分。

下面我用一个完整的例子把整个转换流程走一遍。假设场景是“图书馆借阅系统”，有两个实体：读者（读者编号、姓名、电话）和图书（图书编号、书名、作者）。读者和图书之间的借阅联系是m:n，联系属性是借书日期和还书日期。

转换后的关系模式为：

• READER(读者编号, 姓名, 电话)，主键：读者编号
• BOOK(图书编号, 书名, 作者)，主键：图书编号
• BORROW(读者编号, 图书编号, 借书日期, 还书日期)，主键：(读者编号, 图书编号)，外键：读者编号、图书编号

注意BORROW表的主键是由两个外键共同组成的。这个点在作答时特别容易出错，有的考生只写一个编号作为主键，或者把借书日期也掺进主键里，这些都是错误的。主键必须是最小唯一标识，(读者编号, 图书编号)已经能唯一标识一次借阅记录了，如果你把日期也加进去，就违背了主键最小性原则。

4. 规范化判断：从函数依赖到第几范式

第二问通常考“关系模式填充”，第四问则是“规范化程度判断”。这一问对很多考生来说有一种“看起来会，做起来错”的魔性。原因在于规范化判断不仅需要看清关系模式里的属性，还需要结合题干文字描述提取函数依赖关系，两者缺一不可。

4.1 函数依赖的提取：别只看表结构

函数依赖描述的是“一个属性（或属性组）可以唯一决定另一个属性”的关系，表现为“X→Y”。很多考生做题时只盯着第二问填好的关系模式看，试图从表结构里看出函数依赖，这其实是走了弯路。函数依赖的根源在题干文字描述中，而不是在表结构里。

比如真题原文有“一家医院的每名医生只在一个科室工作，每个科室有多名医生”，这意味着 医生工号→科室号。如果原文写“每个订单包含多个订单项，每个订单项对应一种商品”，那么从语义上可以推断 (订单号, 商品号)→数量。所以做规范化判断前，第一件事是回到题干，逐句圈出“唯一决定”“对应”“属于”这类能表达决定性关系的词。

提取函数依赖有个小技巧：凡是出现“每A……唯一B”或“一个A对应一个B”的句式，就构成了B→A或A→B的函数依赖。注意方向别搞反了。“每名医生只在一个科室工作”表达的是医生决定科室，写成 医生工号→科室号，而不是反过来。这步方向错了，后面全错。

4.2 范式判断的答题模板与四步法

判断一个关系模式达到第几范式，我习惯用固定四步，考试时按顺序走一遍基本不会漏：

1. 找出该关系模式的主键。
2. 根据主键判断所有非主属性，看是否存在非主属性对主键的部分函数依赖。
3. 看是否存在非主属性对主键的传递函数依赖。
4. 根据是否出现这些依赖得出结论。

在具体操作时要明确：满足1NF是所有关系模式的前提，考试中给出的关系模式默认都满足1NF。在1NF基础上，消除所有非主属性对主键的部分依赖，就达到了2NF。在2NF基础上，消除非主属性对主键的传递依赖，就达到了3NF。再往上BCNF，要求每个决定因素都包含候选键，这个在软考下午题中出现的频率不高，但偶尔会在选择题中露脸，案例分析题一般到3NF为止。

举个例子，一个关系模式STUDENT_COURSE(学号, 姓名, 课程号, 课程名, 成绩)，主键是(学号, 课程号)。非主属性：姓名、课程名、成绩。姓名只依赖学号，课程名只依赖课程号，它们都对主键产生了部分依赖，所以这个关系模式只能达到1NF，没有达到2NF。这种例子在教材里俯拾皆是，但考场上换一个场景，很多考生就认不出来了。说到底还是没有把“部分依赖”的本质吃透：一个非主属性只依赖联合主键中的一部分，就是部分依赖。

4.3 主属性与非主属性判定技巧

主属性是候选键中的属性，非主属性是不包含在任何一个候选键中的属性。在判断部分依赖之前，必须先分清哪些是主属性、哪些是非主属性，否则判断结果一定错。

判定主属性有一个省力技巧：先找出所有候选键，再看某个属性是否属于任一候选键。凡是不属于任何候选键的属性，就是非主属性。在考试中，关系模式的主键通常已经在第二问标注出来了，但要注意，候选键不一定只有一个，可题目有时候只标了其中一个。比如关系模式R(A, B, C, D)，函数依赖是A→B, B→C, C→D。候选键是A（因为A能推出B、C、D），这时主属性就是A，其余B、C、D是非主属性。但如果函数依赖是AB→C, C→D，那候选键可能是(A, B)也可能是(A, C)?不，这种情况要仔细推敲，但考试一般不会搞这么复杂。稳妥的做法是，把题干中给出的函数依赖全部画成依赖图，把所有能推出全部属性的最小属性组找出来，再判断属性归属。

这里有一个高频扣分点：把非主属性误判为主属性。比如一个关系模式R(学生编号, 课程编号, 成绩, 教师编号, 教师姓名)，可能会有人认为教师编号也是主属性，因为教师编号好像也能决定教师姓名。但如果教师编号并不参与主键，且存在教师编号→教师姓名的函数依赖，那教师姓名是否构成传递依赖，取决于主键和教师编号之间的依赖路径。如果你把所有非主属性都当成主属性，那部分依赖和传递依赖就全乱套了。

5. 高频陷阱与丢分点排查：这些坑我当年都踩过

这一节我专门把近几年真题里反复出现的陷阱集中整理出来。这些不是理论推导，是我自己备考和带人备考过程中真实遇到的错法，很有代表性。

5.1 题干量词陷阱：联系类型的最隐蔽坑

题目描述“每个学生可以选择多门课程，每门课程可以被一位教师负责，且一门课程只能由一位教师负责”，这时候学生和课程是m:n，但课程和教师是n:1，很多人会把整个图都画成m:n，忽略了题干后半段对课程和教师关系的限定。这种“一个实体同时参与多个联系”的情况在真题中非常常见。应对方法很简单：在草稿纸上先把所有实体列出来，逐对分析它们之间的关系，不要一上手就画图。

5.2 联系属性漏并或错并

转换关系模式时，联系属性只能并入联系转换出的关系模式中。如果是1:n联系，联系属性并入n端关系模式；如果是m:n联系，属性留在独立的关系模式里；如果是1:1联系，联系属性并入你选择合并的那一端。很多考生的错误在于，把m:n联系的属性写在了某个实体关系模式里，或者把1:n联系的属性留在了一个根本不存在的“联系关系模式”里。

5.3 主键“能唯一标识”不代表“适合做主键”

有些属性在业务上确实是唯一的，比如身份证号、手机号，但不代表答案里一定要选它做主键。考试命题时通常会在实体属性里设计一个专门的“编号”字段，比如“职工号”“图书编号”，这就是命题人给出的最佳主键。如果你放着“职工号”不用，非要选“身份证号”，虽然理论上没错，但很可能导致和标准答案不一致，错失分数。在答题时，优先选择和题干描述中带“编号”“代码”“ID”字样的属性。

5.4 关系模式重复或多余

部分年份的真题会给出多个空关系模式表格，要求你补充属性。有的空关系模式其实是同一个实体的不同别名（就是同一个表重复写了两遍），有的则是需要你从ER图中推导出的额外联系表。判断是否需要增加关系模式的关键是：联系类型是否为m:n。如果两张表之间是m:n联系，却没有对应的独立关系模式，那就要补上；如果只是1:n，不需要额外建表。

5.5 范式判断时忽略题干补充信息

有些题目的第四问并不会直接给你函数依赖集，而是要求你结合题干第一段文字中的业务规则来判断。比如“一个科室有多名医生，每名医生只能属于一个科室，科室的负责人由一名医生担任”这段描述中，包含“医生→科室”的依赖，如果科室负责人姓名也出现在医生关系模式中，可能构成传递依赖。如果不读题干直接看表结构，会漏掉这条依赖，导致范式判断错误。

5.6 书写格式不规范导致扣分

下午题是人工阅卷，卷面上关系模式的书写格式直接影响得分。我强调几个点：主键必须画下划线；外键必须在关系模式下方标注“外键：XXX”；属性之间要用中文逗号分隔，不要用空格或顿号；关系模式名建议全部大写，属性和表名之间用括号括起来。这些小细节看着琐碎，但在阅卷场上非常加分。尤其是外键标注，很多考生认为实体关系表里已经画了连线就不需要再写，但阅卷是按点给分，你标注了就是得分点，不标注就可能丢分。

6. 实战演练与备考节奏：最后两个月怎么安排

掌握了知识和方法，最后的冲刺阶段拼的就是熟练度。这道题的高分逻辑和上午题完全不同，上午题靠背，下午题靠刷。你至少要完整手写近5年的第2题各3遍以上，才能形成肌肉记忆，考场上看到什么场景都能条件反射式作答。

6.1 精刷真题的“三步法”

我推荐的真题练习方法是“三步法”。第一步，不看答案，完整作答一遍，时间控制在20到25分钟。第二步，对照标准答案逐条标出自己错在哪里、漏了什么、为什么错。第三步，合上答案，从头到尾再把这道题做一遍，要求完全按照标准答案的思路和格式来。这三步下来，一道真题才算真正吃透。如果第三遍还有错，隔三天再做第四遍，直到满分通过为止。

6.2 时间分配与做题顺序建议

在正式考试中，第2题建议用时不要超过25分钟。如果做题过程中发现某一问卡住了，先跳过去做后面的，不要恋战。原因很简单，第2题各问之间虽然有联系，但每问是单独按点给分的。你因为第一问的ER图画错了，后面的关系模式、主外键、范式判断就全都跟着错，这种情况非常可惜。我的建议是：即便你对ER图没有十足把握，也要先按照自己的理解把后面的关系模式补充完整，因为阅卷会根据后续作答是否逻辑一致酌情给分，完全空白一定没分。

6.3 一个完整场景的快速演练

我随手编一个场景，大家可以只看题干，在脑子里过一遍全过程。场景：“某生鲜电商平台需要设计数据库。平台有供应商、商品、仓库、采购单四个核心实体。供应商编号唯一标识供应商，供应商有姓名、电话和地址。商品编号唯一标识商品，商品有名称、规格。仓库编号唯一标识仓库，仓库有地址和容量。每名供应商可以供应多种商品，每种商品也可以由多家供应商供应，供应价格作为联系属性记录。每个仓库可以存储多种商品，每种商品也可以存放在多个仓库中，存放数量作为联系属性。每张采购单仅向一家供应商采购，但可以包含多种商品，采购日期和总金额记录在采购单上。”

第一步，提取实体：供应商、商品、仓库、采购单。第二步，识别联系：供应商与商品是m:n（联系属性：供应价格）；仓库与商品是m:n（联系属性：存放数量）；采购单与供应商是n:1；采购单与商品是m:n？不对，这里要小心，题干说“每张采购单可以包含多种商品”，但没说每张采购单上的某一种商品是不是唯一记录。如果一张采购单上的同一种商品只有一条记录，那么采购单与商品是m:n，联系属性可以是采购数量。到这里，关系模式的骨架基本就出来了：

• SUPPLIER(供应商编号, 姓名, 电话, 地址)，主键：供应商编号
• PRODUCT(商品编号, 名称, 规格)，主键：商品编号
• WAREHOUSE(仓库编号, 地址, 容量)，主键：仓库编号
• PURCHASE_ORDER(采购单号, 供应商编号, 采购日期, 总金额)，主键：采购单号，外键：供应商编号
• SUPPLY(供应商编号, 商品编号, 供应价格)，主键：(供应商编号, 商品编号)，外键：供应商编号、商品编号
• STOCK(仓库编号, 商品编号, 存放数量)，主键：(仓库编号, 商品编号)，外键：仓库编号、商品编号
• PURCHASE_ITEM(采购单号, 商品编号, 采购数量)，主键：(采购单号, 商品编号)，外键：采购单号、商品编号

这个例子里有两个容易踩的坑。第一，采购单和商品之间的m:n联系很容易被忽略，很多考生会直接把“采购数量”写在商品表里，这就不对了。第二，供应商和商品的m:n联系是“供应”，但采购单里也有供应商，这两个是不同联系，不能混在一起。如果把SUPPLY表和PURCHASE_ORDER表合并成一张表，逻辑上就乱套了。通过这些细节训练，你就能逐步培养出和命题人同步的“拆解数据关系”的视角。

6.4 考场作答的几条铁律

最后分享几条我在考场实战中总结的铁律。第一，画ER图用铅笔和尺子，矩形画实体、椭圆画属性、菱形画联系，连线要直，标注要清楚，字迹潦草扣分太冤。第二，关系模式里的属性顺序最好和ER图中实体属性顺序一致，不要随意调整，方便阅卷老师对照。第三，主键下划线加粗画，外键用“外键”字样显式标注，不要只画一条线就完事。第四，范式判断的答案格式建议写“该关系模式满足2NF，但不满足3NF，原因是存在非主属性对主键的传递依赖X→Y→Z”，一定要写明“原因”，只有结论没有理由会扣分。第五，检查环节重点复查“联系是否有属性”“外键是否标全”“主键是否唯一”，这三个是最后阶段最容易被发现问题的点。

数据库设计这道题，本质上不是智力题，而是熟练工。你只要把ER图设计、关系模式转换、范式判断这三个环节的规则背熟并练透，它就是你下午卷最稳定的一根支柱。哪怕其他题目发挥失常，这道题的分数也能保住你过线的底气。