软考软件设计师的下午题里,第2题数据库设计绝对是最值得“捡分”的一道大题。它不像算法题那样烧脑,也不像设计模式那样需要大量记忆,它的核心套路非常固定:给你一段业务描述,让你补全ER图、转关系模式、写主键外键。只要掌握一套标准流程,这道题拿满分是完全可以做到的。这篇文章我就把ER图到关系模式的转换规则、做题步骤、易错细节一次性讲透,全程结合真题风格示例,帮你把这道题的分数稳稳攥在手里。
1. 下午第2题到底考什么?先摸透题型再谈拿分
很多人一听到“数据库设计”就发怵,觉得要背一大堆理论。其实软考下午第2题是案例分析里最“公式化”的一道,题型和考察点每年都高度相似,摸清出题习惯之后,你会发现它就是“套模板”的活儿。
1.1 十分钟认识这道题的固定套路
软考软件设计师下午考试一共6道题,第1题是结构化分析与设计(数据流图),第2题就是数据库设计。第2题满分通常是15分,给你一段系统需求描述,然后附上残缺的ER图或关系模式,让你答3到4个小问。小问的分布基本是固定的:
- 第1问:补充ER图中的实体、联系或联系类型(如“补充下列实体间的联系类型”),偶尔会问实体的属性或缺漏。
- 第2问:补充关系模式,填写空缺的属性或主键、外键,“(a)”“(b)”这种空。
- 第3问:让你将某个ER图片段转换为关系模式,或补充完整的关系模式集。
- 第4问:有时会涉及增加实体、扩展设计、规范化(如判断是否满足3NF)等衍生问题。
出题场景基本来自典型的管理信息系统:学生选课、图书管理、医院门诊、订单管理、项目申报、车辆管理、产品库存等。这些场景的共同特点是实体之间关系明确,联系类型要么是1:1、1:n,要么是m:n,偶尔会出现三元联系。只要你能准确识别实体、属性和联系,拿到绝大多数分数不成问题。
1.2 从评分规则倒推答题策略
软考下午题的阅卷是按“踩点给分”来的。所谓踩点,就是答案里必须包含阅卷标准里列出的关键内容。比如让你补充“联系类型”,你光写“一个学生可以借多本书”是不够的,必须写出“学生与图书之间是1:n的联系”,最好用标准符号或文字明确写出“1:n”。再比如让你填关系模式的主键,你写对了主键属性,但没说明是“主键”,也可能丢失“标注分”。
针对这个评分特点,答题策略就非常明确了:
- 答案要写“全称”,不要写简写。实体名、属性名尽量与题干保持一致,不要自创同义词。
- 涉及“联系”的问题,一定要写出“实体A与实体B之间是X:Y联系”,不要只写“有关系”。
- 填空里的主键、外键,要按题意标注清楚。题干如果要求用下划线表示主键,那就在空格里把对应属性写在正确位置,并用说明文字标注“主键:xxx”。
说到底,软考不是考你有没有做出来,而是考你的答案里有没有“得分点”。你写得再华丽,离开得分点就没分;写得很朴素,但每个得分点都命中了,就是满分。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. ER图的核心概念:别让基础定义拖了后腿
想拿满分,第一道门槛是读懂ER图。很多考生不是不会转关系模式,而是拿到一张残缺ER图,看不出哪里缺实体、哪里少联系。ER图的三个核心构件——实体、属性、联系——必须研究得明明白白。
2.1 实体、属性、联系的判定标准:看完这几点就不纠结了
先聊一个备考时最常见的问题:一个业务概念到底是实体还是属性?比如“学生”和“班级”,学生显然是实体,班级看起来像一个属性。但如果你细想,班级有班级编号、班级人数、班主任……它自己就有一堆描述信息,那它就应该是实体。判定的核心标准就是:这个概念需不需要被独立记录多条信息。
我总结了一个非常实用的判断顺序:
- 如果这个概念在业务描述中拥有两个或两个以上独有的、需要记录的特征,优先考虑它是实体。比如“班级”有“班级编号”“班主任”“人数”,所以设成实体;“性别”只有男女,没有其他要记录的信息,所以设成属性。
- 如果这个概念是某个实体的固有特征且没有独立的存储需求,就是属性。比如“姓名”“年龄”“颜色”“价格”。
- 如果题干中出现“多个”“若干”“很多”“一个……可以对应多个……”这类描述,通常意味着实体之间有关系,而不是属性归属。
属性的分类也值得留意。复合属性(如“地址”可以拆成“省、市、街道”)在软考真题里不常见,但如果你在转换关系模式时遇到,就把它拆开或整体作为一个字段都可以。多值属性(如“联系电话”可能有两个号码)在ER图转关系模式时通常单独建表,避免数据冗余。派生属性(如“年龄”由“出生日期”推出,“总分”由“各科成绩”算出)在考试里一般不会让你建表存储,知道它是什么即可。
2.2 联系的度与基数:解所有转换题的关键钥匙
联系是ER图里最核心、也最决定关系模式形态的部分。联系分“度”和“基数”两个维度,理解透这两个维度,转换规则才有据可依。
联系度,就是参与联系的实体个数。两个实体参与就是二元联系,三个实体参与就是三元联系。软考真题里,二元联系是绝对主力,三元联系偶尔出现(比如“供应商-项目-零件”三方供应)。在三元联系里,哪个方向是“多”端、哪个是“一”端,决定了转换结果。
联系基数,就是实体之间对应关系的数量约束。它有三种基本形态:
- 1:1:一端实体A的一个实例,最多对应实体B的一个实例,反之亦然。例如“班级”和“班长”——一个班级只有一个班长,一个班长只属于一个班级。
- 1:n:实体A的一个实例,可以对应实体B的多个实例;反过来,实体B的一个实例只能对应A的一个实例。例如“班级”和“学生”——一个班级有多个学生,一个学生只属于一个班级。
- n:m:多对多。例如“学生”和“课程”——一个学生选多门课,一门课被多个学生选。
做ER图题时,你必须先精确定位每一对实体之间的基数。这里有个很容易踩的坑:题干里经常出现“每个图书管理员可以负责多个图书编目,每个图书编目只能由一个管理员负责”,这种描述就是典型的1:n,但题干不会直白地告诉你“这是1:n”,需要你自己从表述里提炼。怎么做?把题干里的“一个”“多个”“每一个”圈出来,像做阅读理解一样标出所有量化词,再逐个实体对配对分析。
3. 转换规则全解:从ER图到关系模式的两大步
你可能会在各种教材里看到很多关于转换规则的表述,但我建议你把它们在脑子里压缩为两句话:每个实体建一张表;每条联系决定“外键放在哪”或“是否独立建表”。做到这一点,转换题就稳了。
3.1 实体转关系模式:所有关系模式的起点
ER图里每一个实体,无脑对应一个关系模式。实体的名称就是关系模式的名称,实体的属性就是关系模式的属性。实体原本的标识属性(通常是编号或ID)作为这个关系模式的主键。这一步几乎不丢分,唯一要小心的是实体属性里有多值属性,多值属性不能在原表中直接存多个值,要单独拆一张表。
比如“图书”实体,属性包括图书编号、书名、作者、价格,那关系模式就是:
code复制图书(图书编号,书名,作者,价格)
主键:图书编号
这里多说一句主键的标注习惯。在答题纸上,如果你是用文字描述关系模式,通常要说明“主键:图书编号”。有些题干会直接给空让你填,你就在空格对应的属性名上写“图书编号(主键)”或者按题目要求在属性下加下划线。看题行事。
3.2 联系转关系模式:三种情况一张表讲透
联系怎么转?这是决定你能否拿高分甚至满分的关键。不废话,直接把规则总结为一张速查表:
| 联系类型 | 转换策略 | 关系模式特征 | 典型例子 |
|---|---|---|---|
| 1:1联系 | 可以把联系并入任意一端实体的关系模式;独立的联系本身可以不再额外建表 | 在选定的那一端关系模式中,加入另一端的主键作为外键;外键上最好加“唯一”约束 | 班级与班长 |
| 1:n联系 | 把联系并入“多”端实体的关系模式 | 在“多”端关系模式中,加入“一”端的主键作为外键;外键的类型必须与“一”端主键一致 | 班级与学生 |
| n:m联系 | 必须为联系单独建立一个关系模式 | 新关系模式的属性是两端实体的主键组合,外加联系自身属性;主键通常是两端主键的联合主键 | 学生与课程(选课) |
先说1:1。两个实体之间一对一,转关系模式时你可以把其中一个实体的主键塞进另一个实体作为外键。这个“塞”的动作,选哪一端都行,逻辑上不违反规则。比如“职工”和“职工工作证”,你可以把“工作证号”加到职工表,也可以把“职工号”加到工作证表。怎么选更优?看业务侧重点。如果查询经常是从职工出发查工作证,就把工作证号加进职工表;如果查询经常是拿工作证号反查职工,就反过来。考试时题干如果给了提示,按提示来;没给提示,选任意一端都算对。
再说1:n。重点是想清楚谁是“一”,谁是“多”。“一”端的主键放到“多”端作外键。比如“学生”和“选课”之间的联系设计中,学生选课记录是“多”端,课程是“一”端,那选课表里要有课程ID,这就是从课程表“透传”过来的外键。
最后说n:m。这种联系必须独立建表。以经典的学生选课为例:
- 学生(学号,姓名,专业)
- 课程(课程号,课程名,学分)
- 选课(学号,课程号,成绩)
选课这个关系模式里,主键是(学号,课程号)的组合主键,“成绩”是联系自带的属性。有一个细节:主键“学号,课程号”同时也是外键,分别引用学生表和课程表的主键。答题时如果题目要求“指出外键”,你要把这两个属性都列出来,别漏掉其中一个。
3.3 特殊情况的处理:弱实体、ISA层次、一实多联
如果只看二元联系的常规转换,这套规则就够用了。但软考偶尔会混入一些小变体,提前搞清楚就不会慌。
弱实体的处理。弱实体就是没有独立主键、必须依赖强实体才能标识的实体。比如“订单”下的“订单明细”,订单明细本身没有全局唯一编号,只能通过“订单编号+商品编号”来标识。转换时,弱实体的关系模式中,主键是强实体的主键加弱实体自身的部分键组合而成;外键指向强实体。这种场景在软考真题里出现过,一旦出现,你要敏锐地察觉“这个实体没有独立编号”这个设定,不要强行给它编一个主键。
ISA层次(继承)的处理。有些业务模型里,实体之间有分类关系,比如“人员”下有“教师”和“学生”。ER图中用ISA三角形表示。转关系模式有两种做法:一是只建父类表,把子类特有属性也一起放进去,用类型字段区分;二是父类、子类各建一张表,子类表用父类主键作为自己的主键兼外键。“合并到父表”查询简单,“分开建表”更规范。考试时,题干如果只要求转换实体关系,按常规规则来;如果题中出现“教师”“学生”这类继承式实体,你优先考虑子类各自建表、以父类主键为主键的做法,因为这样和ER图的对应关系最直观。
一实多联的处理。同一个实体和另一个实体存在多个联系时,不要合并联系。比如“员工”和“部门”之间,既有“员工属于部门”的联系,又有“员工管理某个部门”的联系,那么前者是1:n(多个员工在一个部门),后者是1:1(一个部门一个经理)。转换时,一个联系有一个外键,不能混在一起。有的考生会在员工表里放一个“部门编号”就想同时表达两种联系,结果把“哪个员工在哪个部门”和“哪个员工管哪个部门”弄混。拆开写,外键独立定义,才是规范解法。
4. 真题实战:拿一道题完整走一遍流程
讲了这么多规则,来一道模拟软考风格的例题,把整个做题流程从头到尾过一遍。这题参考了历年“在线课程学习平台”的出题思路,形式和难度贴近真题。
题目背景:某在线课程学习平台,需要设计一个数据库。系统中包含学生、课程、教师、教材、课程类别等概念。业务规则如下:
- 一个学生可以选修多门课程,一门课程可以被多名学生选修,学生选课后会产生“平时成绩”和“考试成绩”。
- 一门课程只能由一名教师负责授课,一名教师可以教授多门课程。
- 每位教师可以编写多本教材,每本教材只能由一名教师编写。
- 一门课程可以选用多本教材,一本教材可以被多门课程选用。
- 每门课程属于且仅属于一个课程类别,一个课程类别下可以有多门课程。
题目要求:
- 根据描述,设计ER图,标出实体、属性与联系类型。
- 给出所有关系模式,并指出主键与外键。
- 对“学生选课”这一操作,在关系模式中体现成绩信息,并说明这样设计是否满足3NF。
4.1 第一步:圈出所有实体和关键量化词
拿到题目,我习惯先用笔画或用草稿纸列出所有名词。这道题里能明显当实体的有:学生、课程、教师、教材、课程类别。属性级的名词有:平时成绩、考试成绩——它们属于“学生选课”这个联系,是选课的联系属性。
接着标量化关系:
- “一个学生可以选修多门课程,一门课程可以被多名学生选修”→学生和课程:n:m。
- “一门课程只能由一名教师负责授课,一名教师可以教授多门课程”→课程和教师:n:1,换一种说法就是“教师和课程:1:n”。
- “一位教师可以编写多本教材,每本教材只能由一名教师编写”→教师和教材:1:n。
- “一门课程可以选用多本教材,一本教材可以被多门课程选用”→课程和教材:n:m。
- “每门课程属于且仅属于一个课程类别,一个课程类别下可以有多门课程”→课程类别和课程:1:n。
这里最隐蔽的就是教材与课程的多对多。很多人脑子里默认教材就是一门课程配套的,但题目明说“一本教材可以被多门课程选用”,这就是n:m,必须单独建一张“课程-教材”关系表。
4.2 第二步:画ER图,补全联系与联系属性
基于上面的分析,ER图的实体和联系就都清楚了。草稿上大致是五张实体矩形框,四个联系菱形:
- 学生—(选修)—课程,联系类型m:n,联系属性:平时成绩、考试成绩。
- 教师—(授课)—课程,联系类型1:n;这个联系方向要写“教师1,课程n”或“课程n,教师1”。
- 教师—(编写)—教材,联系类型1:n。
- 课程—(选用)—教材,联系类型m:n。
- 课程类别—(包含)—课程,联系类型1:n。
还要给每个实体补必备属性。学生有学号(主键)、姓名;课程有课程号(主键)、课程名、学分;教师有教师号(主键)、姓名、职称;教材有教材号(主键)、书名、出版年份;课程类别有类别编号(主键)、类别名。这些属性题干如果没给全,考试时通常会在ER图或题目描述里提供,你按“主键必须有、常用描述性属性必须有”来补。
画图时注意:实体间有多个联系时,每个联系都要单独画菱形,不要合并。比如课程和教师之间是“授课”联系,课程和教材之间是“选用”联系,这是两个完全不同的业务含义,必须分开表达。
4.3 第三步:转换关系模式,主键外键一步到位
实体转表,联系按规则转,结果如下:
- 学生(学号,姓名)— 主键:学号
- 教师(教师号,姓名,职称)— 主键:教师号
- 教材(教材号,书名,出版年份)— 主键:教材号
- 课程类别(类别编号,类别名)— 主键:类别编号
- 课程(课程号,课程名,学分,类别编号,教师号)— 主键:课程号;外键:类别编号 → 课程类别(类别编号),教师号 → 教师(教师号)
课程表的类别编号来自1:n联系,属于“多”端加外键。教师号来自课程与教师的1:n联系,这里课程是“多”端,所以也加到课程表中。有没有发现,课程表里同时含有两个不同来源的外键?这在考试里非常常见,一个“多”端实体可以同时作为多个“1:n”联系的多方,把多个外键收集到一张表里,只要业务逻辑不冲突就行。
学生选课这个n:m联系要单独建表:
- 选课(学号,课程号,平时成绩,考试成绩)— 主键:(学号,课程号);外键:学号 → 学生(学号),课程号 → 课程(课程号)
课程与教材的n:m联系也要单独建表:
- 选用教材(课程号,教材号)— 主键:(课程号,教材号);外键:课程号 → 课程(课程号),教材号 → 教材(教材号)
到这里,五大实体、四个联系全部落地,关系模式一个不缺。检查一遍有没有遗漏:题目里所有量化词对应的联系都已经体现在关系模式中了。这个检查步骤特别关键,很多人丢分就是漏掉了一个联系。
4.4 判断3NF:把规范化理论用在答题里
第三问关于3NF。判断思路很简单:先找主键,再看有没有非主属性对主键部分依赖或传递依赖。选课表的非主属性是平时成绩、考试成绩,它俩只依赖(学号,课程号)这个联合主键,没有只依赖学号或只依赖课程号,所以不存在部分依赖;也不存在成绩依赖某个非主属性的情况,所以不存在传递依赖。结论:满足3NF。
课程表的非主属性是课程名、学分、类别编号、教师号,均完全依赖课程号,无部分依赖。但需要检查有没有传递依赖:课程号→类别编号→类别名?注意类别名不在课程表中,在课程类别表里,所以课程表内部不构成传递依赖,满足3NF。要是你把类别名冗余进了课程表,那课程号→类别编号→类别名就是传递依赖,就不满足3NF了。这个区别要看清。
这类小问考的其实是规范化理论在具体关系模式上的应用,难度不高,关键是你平时要练熟部分依赖和传递依赖的识别。
5. 常见错题与阅卷“潜规则”:这些坑必须提前踩掉
理论知识都掌握了,真题也练过几套,但为什么还是有人拿不到满分?根据我自己的备考经验和对真题答案的观察,问题往往出在一些细节上。这些细节不解决,你和满分的距离可能就差一两分。
5.1 阅卷老师最反感的几种错误答案
第一,分不清关系和联系的用词。有些同学写答案时,把“关系模式”写成“关系表”,把“联系”写成“关系”,这不是完全错,但确实不严谨。软考的标准答案是规范的术语,你可以在平时练习时就坚持用标准术语:实体、属性、联系、关系模式、主键、外键。考试时碰到不会的题,宁可用标准术语描述一个朴素的想法,也好过用通俗语言讲一堆。
第二,漏写外键,尤其是联合主键中的外键。填选课表的主键(学号,课程号)时,容易只写学号或只写课程号。记住规则:联合主键是一个整体,答题时写(学号,课程号),同时注明它们每个都是外键。
第三,n:m联系“并表”进去。有的同学为了省事,把选课信息直接放进学生表或课程表里,成绩字段加了,但造成大量冗余和更新异常。软考改卷时,如果发现该独立建表却没有独立建表,即使加了正确字段,也拿不到全分。转换规则是死的,n:m必须独立建表,没得商量。
第四,三元联系没按规范转。当题目出现三元联系时,通用规则是一个三元联系通常转换成一个独立关系模式,该关系模式包含所有参与联系的实体的主键,外加联系属性;主键通常是各实体主键的组合。不要试图把三元联系拆成两个二元联系。
5.2 题量不大但时间易失控:这题的时间分配建议
下午考试总共150分钟,如果你目标是通过,算一下平均每道题的可用时间。第2题作为数据库设计题,我建议控制在20分钟左右,最多不要超过25分钟。为什么?因为后面还有算法题、设计模式题、C语言程序设计题,那些题写代码更耗时,时间上有硬性需求。
我做这道题时的时间分布是这样的:前3分钟读题和圈关键词;5分钟画ER图或补全给定的ER图;10分钟写关系模式,包括主键外键;最后2分钟检查有没有漏实体、漏联系。如果你的ER图已经由题目给出,时间还可以再压缩一些,把省下的时间留给后面的程序题。
答题纸上作答时,会控制节奏也很重要。关系模式的描述要写清楚、对齐,主键外键用备注形式清晰标注,不要让阅卷老师在一堆字符里找你的主键标注。你写得清楚,对你有好处。
5.3 从实务角度理解数据库设计:对考试和工作都有帮助
如果你已经工作了,你会发现软考这道题其实就是日常数据库设计的一个缩影。MySQL里用工具导出ER图(比如MySQL Workbench的逆向工程),或者用文档记录数据库设计,本质上都是在做“从现实业务到关系模型”的映射。你在备考过程中总结的这套“实体识别—联系分析—关系模式转换”的方法,放到真实项目里同样适用,这就是软考这部分含金量所在。
工作里比考试多一步,就是还要考虑索引设计、查询性能、数据量增长后的水平拆分等问题。但底层的数据建模逻辑,就是这门考试考察的内容。所以很多过来人说软考中级对实际工作有帮助,数据库这道题是代表性的一例。
5.4 备考中怎么练这一题才最高效
备考前中期,不用急着刷整套下午题,可以先只练第2题,一天一道,连续练两周。练的时候注意几点:
- 拿到题目,先自己写一遍答案,再对照官方答案或可靠机构的解析,逐个踩分点核对,找出丢分的地方。
- 分析错因时,把“漏识别实体”“联系基数判断错”“外键放错位置”“该建表没建表”这四类问题分开记录。我当时用一个小本子记了每个错题的错误类型,考前只看本子上的总结,效率极高。
- 如果时间充裕,把近五年的真题第2题全部刷一遍,至少刷两遍。第二遍只做错题和不确定的题,检验是否真的掌握。
这道题对正确率的要求可以定高一点,因为它和其他题不一样,它是最容易通过训练拿到接近满分的一题。给足训练量,形成条件反射般的做题思路,考试时看到任何业务描述都不会慌。
我个人备考时最有成就感的一件事,就是把近十年下午第2题全部做过两遍之后,总结出了一页纸的转换速查表。考试时,我根本没有犹豫,看到“多对多”就直接想到独立建表和联合主键,看到“一对多”就自动把外键放在多端。这种熟练度不是靠背出来的,是靠反复做题形成肌肉记忆。
最后再分享一个小技巧:平时练习时,把你总结的ER图转关系模式规则贴在电脑旁边,每次做题前扫一眼,做完题再回看一遍,看自己有没有违背规则。坚持一段时间,你会发现,下午第2题真的就是一套固定流程,里面的每个决策都有章可循。把这套流程练熟,满分就是水到渠成的事。
