备考数据库这一章的时候，我见过太多人把E-R图的矩形、椭圆、菱形背得滚瓜烂熟，一到做题还是卡壳。问题不在于记性，而在于很多人把这两套模型当成两套独立的图形符号去背，没搞清楚它们之间是什么关系、考试为什么非要把它们放在一起考。数据模型这一块在软考里属于典型的“分值不大但丢不起”的内容：上午题里数据库系统部分通常只有几分，E-R模型和关系模型相关的题能占到其中一半；下午题如果碰上数据库设计大题，E-R图补全加关系模式转换几乎是标配。这篇内容我打算把E-R模型和关系模型拆开讲透，再讲清楚两者之间的转换链路，以及范式和关系代数这两块延伸考点。适合刚接触软考数据库部分、看教材觉得术语太多抓不住重点的人，也适合考过一次发现这块总是丢分、想回头系统补一遍的人。文中涉及的判定方法和答题套路，都是我自己反复做题、整理错题之后总结出来的，能直接拿去用。

1. 数据库章节里，数据模型这块分值不重但丢不起

软考数据库部分的考法有个很明显的特征：知识点铺得很宽，但真正反复出题的核心就那么几块，数据模型是其中之一。很多人复习时会做一道算术题——数据库在上午题里才几分，E-R模型和关系模型又只占其中一部分，投入产出比不高，于是草草翻过。我一开始也是这么想的，直到在下午题上栽了跟头才明白，这块内容的真正价值不在上午那几道选择题，而在于它是数据库设计大题的入口。E-R图看不懂、关系模式转不出来，后面那些范式判断、SQL语句填空基本连锁崩盘。

1.1 上午题和下午题对两类模型的不同考法

上午题考数据模型，基本都是概念辨析和快速判定。常见问法有几种：给出一个场景描述，问两个实体之间是什么联系类型；给出一个关系模式，问哪个属性组是候选键；给出几个函数依赖，问这个关系最高满足第几范式；给出一个E-R图片段，问转换成关系模式后有几个关系、主键是什么。这类题的特点是单题耗时短、答案唯一、没有过程分，会就是会，不会就只能猜。

下午题的考法完全是另一个路数。典型形式是给一段业务说明加一张不完整的E-R图，要求补充缺失的实体、联系或属性，然后转换成关系模式，标出每个关系的主键和外键，有时候还会追问某个关系是否满足3NF、怎么分解。这类题有过程分，即使最终答案不完美，把实体和联系补对、把转换规则走对，也能拿到大部分分数。所以我在复习这块的时候，上午题和下午题是分开练的：上午题练速度和概念辨析，下午题练流程完整性和书写规范。

1.2 为什么建议先啃模型再看SQL和范式

教材的编排顺序通常是先讲数据模型，再讲关系数据库标准语言，最后讲数据库设计与规范化。很多人觉得SQL更实用、更直观，会跳过去先学SQL。我试过一次这样的顺序，结果学SQL的时候对“主键”“外键”“参照完整性”这些词只有模糊印象，写建表语句时约束部分全靠背模板，遇到稍微绕一点的题就不知道为什么要加这个约束。

把顺序倒回来之后情况完全不一样。先把E-R模型里的实体、属性、联系搞清楚，再把关系模型里的键和完整性约束搞明白，回头看SQL的建表语句，每一条约束都能对应到一个具体来源：主键约束对应实体完整性，外键约束对应参照完整性，检查约束对应用户定义完整性。范式的部分也一样，不理解函数依赖，2NF、3NF的定义就是两句话，理解了函数依赖，范式判断就变成了一个机械的推导过程。所以我的建议是，数据模型这块不要跳，哪怕SQL看起来更“有用”，也要先把模型的地基打稳。

1.3 这一块复习的投入节奏怎么安排

我的实际安排是三轮。第一轮跟着教材过一遍概念，重点是把术语和符号对应上，不求做题正确率；第二轮集中刷近五年的上午题，把涉及数据模型的题目全部挑出来，按知识点分类整理，看看自己到底在哪一类上反复出错；第三轮专门练下午题的数据库设计，手写完整流程，重点练画图和转换的规范性。三轮下来大概需要十来个小时，比起其他章节不算多，但效果很扎实。第一轮最容易犯的错误是急着做题，概念还没理清就开始刷，错一片之后打击信心；第二轮最容易犯的错误是只看错题不看解析，知道答案错了但不知道为什么错，下次遇到同类题还是错。

2. E-R模型：图形只是外壳，判定联系类型才是真功夫

E-R模型这块，画图的符号其实几分钟就能记住：矩形是实体，椭圆是属性，菱形是联系，连线表示归属。真正拉开差距的是判定——给你一段业务描述，你能不能准确切分出哪些是实体、哪些是属性、哪些应该抽象成联系，以及两个实体之间到底是一对一、一对多还是多对多。这部分靠的不是背符号，是靠对业务语义的理解。我见过不少人符号记得比谁都清楚，一到判定联系类型就开始凭感觉，结果一对多判成多对多，整个转换步骤全错。

2.1 实体、属性、联系三层结构怎么切分

判断一个概念是实体还是属性，我用的标准是看它有没有独立的生命周期、需不需要被单独描述。拿一个常见的图书借阅场景举例：读者、图书、借阅这三个概念里，读者和图书都是实体，因为它们各自有一堆属性需要描述，读者有编号、姓名、联系方式，图书有书号、书名、出版社。而“借阅”这个动作本身没有独立存在的意义，它必须依附于读者和图书，所以它是一个联系，联系的属性是借阅日期、归还日期。

属性这块有一个容易忽略的点：属性必须是不可再分的。教材里叫原子性。如果某个概念本身还能拆出多个子属性，比如“地址”可以拆成省、市、街道，那它在E-R图里要么作为复合属性处理，要么直接拆成几个独立属性。考试里如果给出的是“地址”这样一个笼统的属性名，一般不会为难你，但如果题目明确说明地址要拆开存储，那就得拆。这个细节在转换关系模式的时候会直接影响结果，因为关系模型要求每个字段都是原子的。

还有一个判断技巧：如果某个概念在多处被引用，而且它自己有属性，那基本可以确定是实体。比如“部门”这个概念，员工属于部门，项目也属于部门，部门自己有名称、负责人、成立时间，那它必须是实体，不能作为员工的属性草草了事。我在做题时如果拿不准，就用这个标准反向验证：把它当属性处理，会不会导致信息重复存储、会不会出现修改一处要改多处的麻烦，如果会，那就是实体。

2.2 一对一、一对多、多对多的判定不靠直觉靠语义

联系类型的判定是这一章的核心考点。判定方法是固定的一套：先明确两个实体，然后分别从两个方向去问“一个A能对应几个B”“一个B能对应几个A”，两个答案组合起来就是联系类型。一个对一个是一对一，一个对多个、多个对一个是一对多，多个对多个是多对多。

听起来简单，实际操作时坑很多。第一个坑是方向搞反。一对多联系里，哪一端是“一”、哪一端是“多”，必须看清楚。比如“部门”和“员工”，一个部门可以有多个员工，一个员工只能属于一个部门，所以部门是“一”端，员工是“多”端。如果题目问“部门与员工之间的联系类型”，答案是一对多；如果问“员工与部门之间的联系方式”，从员工角度看是多对一。这两种问法在选择题里都出现过，读题时要盯住主语。

第二个坑是业务规则隐含在一句话里。题目经常这么写：“每个仓库可以存放多种商品，每种商品只能存放在一个仓库中。”前半句说的是仓库到商品是一对多，后半句说的是商品到仓库是一对一，合起来就是一对多联系。如果题目只写了前半句，那默认按后半句的约束理解，也就是一对多，不必想太多。但如果题目写的是“每个仓库可以存放多种商品，每种商品可以存放在多个仓库中”，那就是多对多。这两句话只差几个字，结论完全不同，读题时要把“只能”和“可以”这种限定词圈出来。

第三个坑是多对多联系在转换时的特殊性。这是后面章节要展开的内容，这里先提一句：多对多联系必须单独转换成一个关系模式，而一对一和一对多联系可以合并到实体对应的关系模式里。判定错一个，后面的关系模式数量就会错，整个题的分就没了。

2.3 弱实体、多值属性、派生属性这些冷门但会考的点

弱实体是E-R模型里相对边缘的概念，但软考确实考过。弱实体指的是不能独立存在、必须依附于另一个实体才能被标识的实体。典型例子是“员工家属”，家属信息只有在员工存在的前提下才有意义，家属编号通常也是相对员工编号而言的。弱实体在图里用双矩形表示，它和依附实体之间的联系用双菱形表示。转换关系模式时，弱实体的码由依附实体的码加上自身的部分码组成。

多值属性指的是同一个实体在同一个属性上可以取多个值，比如一个员工有多个联系电话。教材里用双椭圆表示。这个点在转换关系模式时很关键：多值属性不能直接塞进实体对应的关系模式里，必须单独建一个关系模式，属性包括实体码和这个多值属性本身。如果不单独建，就会违反第一范式，因为一个字段里存了多个值。

派生属性指的是可以由其他属性计算出来的属性，比如由出生日期算出年龄，由单价和数量算出总价。图里用虚线椭圆表示。派生属性通常不存储，也不参与转换，知道这个概念、认得符号就够。软考里这块的考法基本停留在概念层面，问你哪个是派生属性、哪个是多值属性，不太会让你把派生属性写进关系模式里。

2.4 画图时最容易犯的几个错误

第一个错误是连线的归属搞错。属性椭圆必须连在它所属的实体或联系上，不能连在别的实体上。联系菱形必须同时连两个实体，不能只连一边。这个听起来像废话，但手写下午题的时候紧张起来真的会连错，连错了阅卷人按图给分，直接丢分。

第二个错误是漏写联系的属性。有些联系本身带属性，比如“借阅”联系带借阅日期、归还日期，“选修”联系带成绩。这些属性既不属于读者也不属于图书，只属于联系本身，必须画在菱形上。漏掉的话，转换关系模式时这部分信息就丢了，题目如果要求补全属性，这一分就没了。

第三个错误是主键没标注。E-R图里实体的主键要在属性名下面加下划线，这是规范要求。有些人觉得下划线可有可无，实际上下午题评分标准里经常明确要求标注主键，没标就扣分。我现在的习惯是每画一个实体，第一件事就是把主键属性划出来，画完再检查一遍。

第四个错误是实体命名不规范。实体名应该用名词，联系名应该用动词或动名词。比如“借阅”“选修”“属于”是合格的联系名，“借阅记录”“选课情况”这种名词化的写法虽然意思没错，但不符合规范，遇到严格的评分标准会被扣分。这个细节属于平时练习就要养成的习惯，考场上临时改反而容易乱。

3. 关系模型：术语对照表背后藏着出题人的偏好

关系模型这一块，教材上的术语密度非常高：关系、元组、属性、域、分量、关系模式、关系实例、超键、候选键、主键、外键，一口气十几个名词。很多人背完就忘，忘了再背，循环往复。我后来发现一个规律：这些术语其实是一张二维表的不同说法，只要把表格画出来，每个术语都能在表上找到位置，就不容易混了。更关键的是，考试出题人有明显的偏好——键的判定和完整性约束是绝对的高频点，术语辨析属于低频但偶尔出现，复习时要把精力压在刀刃上。

3.1 关系、元组、属性、域——一套术语两种说法

关系模型把数据组织成二维表的形式。一个关系就是一张表，表名就是关系名。表中的一行叫一个元组，对应现实世界中的一个实体或一条联系记录。表中的一列叫一个属性，列名就是属性名。某个属性所有可能取值的集合叫域，比如“性别”这个属性的域就是男和女两个值。行和列的交叉点叫分量，也就是一个具体的数据值。

这张表我建议直接记住，考试里但凡出现“元组”“分量”这类词，脑子里立刻切换到“行”“单元格”，理解速度会快很多。软考的选择题有时候故意用学术术语描述，比如“关系中的元组个数称为关系的基数”“关系中属性的个数称为关系的元数”，这种题如果术语不熟，读题就卡住了。基数就是行数，元数就是列数，转换一下就不难。

3.2 从超键到外键，四条判定链路一次理清

键这个概念是关系模型里最重要的考点，四个层次依次递进：超键、候选键、主键、外键。

超键指的是能唯一标识一个元组的属性集合。注意，是属性集合，可以是单个属性，也可以是多个属性的组合。关键在于“唯一标识”——给定一个超键的值，最多只能找到一行数据。比如学生表里“学号”是超键，因为学号唯一；而“学号和姓名”的组合也是超键，虽然姓名本身不唯一，但加上学号之后整体就唯一了。超键允许包含多余属性，这是它和候选键的区别。

候选键指的是不含多余属性的超键，也就是最小超键。还是学生表的例子，“学号”是候选键，“学号和姓名”就不是候选键，因为把姓名去掉之后“学号”仍然能唯一标识，说明姓名是多余的。一个关系可以有多个候选键，比如学生表里如果身份证号也唯一，那学号和身份证号都是候选键。

主键是从候选键里挑出来的一个，用来实际做唯一标识。挑哪个一般看业务习惯，通常挑长度短、含义稳定、不常变动的那个。学号比身份证号更适合作主键，就是因为学号短、不会因为户籍变更而变动。

外键指的是本关系中的某个属性组，它不是本关系的候选键，但它是另一个关系的主键。外键是关系之间建立联系的桥梁。比如选课表里的“学号”就是外键，它引用学生表的主键“学号”；“课程号”也是外键，引用课程表的主键。外键的价值在于把两个关系关联起来，同时也带来了参照完整性的约束。

3.3 三类完整性约束为什么必须背下来

关系模型有三类完整性约束，这块必须背熟，因为上午题和下午题都会考。

实体完整性要求关系的主属性不能取空值。主属性指的是包含在任何一个候选键中的属性。用大白话说，主键的组成字段不能为空。这条约束的逻辑很明白：主键是用来唯一标识元组的，如果允许为空，就无法区分这个元组代表哪个实体，标识功能就失效了。

参照完整性要求外键的取值要么为空，要么等于被参照关系中某个元组的主键值。这条约束保证的是关系之间关联的一致性。比如选课表里的学号，要么是空值（表示这门课还没人报），要么必须是学生表里真实存在的学号。不能出现一个学号在选课表里有记录、在学生表里查无此人的情况。

用户定义完整性是具体业务场景下的约束，比如性别只能取“男”或“女”，成绩必须在0到100之间，年龄不能是负数。这类约束由具体应用决定，不是关系模型本身的规则。

这三条完整性在SQL里都能找到对应：实体完整性对应主键约束，参照完整性对应外键约束，用户定义完整性对应检查约束或断言。把这三条搞清楚，回头看SQL的约束语句，就知道每一条是在干什么，而不是死记语法。

3.4 关系模式与关系实例的区别，很多人栽在这

关系模式是表的结构定义，形如“学生（学号，姓名，专业）”，描述的是有哪些属性、每个属性来自哪个域、满足哪些约束。关系实例是某一时刻表中实际存储的数据，也就是一张填满数据的表。两者的关系类似于类与对象：模式是模板，实例是按模板填进去的内容。模式相对稳定，很少变动；实例频繁变化，每插入删除一条记录，实例就变了。

这个区别在考试里的直接体现是：问“关系模式”的时候，答案里不应该出现具体的数据值；问“关系实例”的时候，才涉及具体的行。有些题的选项会拿两者混淆，比如给出一张带数据的表，问这是什么，正确答案是关系实例而不是关系模式。这个点不难，但读题不仔细很容易选错。

另外有一个延伸点：关系模式的形式化定义是R(U, D, DOM, F)，其中U是属性集，D是域集，DOM是属性到域的映射，F是函数依赖集。软考里基本不会考这么细，但如果你在题目里看到“关系模式”后面跟着函数依赖集，不要意外，那是完整定义的一部分，平时简写成R(U)只是省略了。

4. E-R图转关系模式：三步走和三个转换分支

转换这部分是数据模型里最像流水线的内容，规则很明确，但分支多、细节多，一步走错后面全错。我的做法是把转换拆成三个固定步骤：先转实体，再转联系，最后做合并优化。每次做题都按这个顺序走，不跳步，宁可慢一点也要保证每一步都写清楚，因为下午题是按步骤给分的。

4.1 第一步：实体无条件先转

每个实体型转换成对应的一个关系模式，实体的属性就是关系的属性，实体的码就是关系的码。这一步没有例外，有几个实体就转几个关系模式，先全部列出来。

在处理属性的时候有几个细节要留意。复合属性要拆成简单属性，比如“地址”如果由省、市、街道组成，转换时就拆成省、市、街道三个字段，而不是保留一个“地址”字段。多值属性不能放进实体对应的关系模式里，要单独建一个关系模式，属性包括实体的码和这个多值属性，比如员工有多个电话号码，就单独建一个“员工电话（员工号，电话）”关系，主键是员工号和电话的组合。派生属性一般不转换，因为它是计算出来的，存储它会带来数据不一致的风险。

4.2 第二步：三种联系走三条不同的路

联系类型的转换规则不一样，这是整道题最容易出错的地方。

一对一联系有两种处理方式：一是转成一个独立的关系模式，属性包括两端实体的码和联系自身的属性，主键可以选任意一端的码；二是合并到任意一端对应的关系模式里，在那一端加入另一端的码和联系的属性。实际做题时，如果联系本身没有属性，通常选合并，因为独立建表会产生冗余；如果联系有属性，合并到哪一端要看业务，一般合并到参与度更高的那一端。

一对多联系同样有两种处理方式：独立转成一个关系模式，或者合并到“多”端对应的关系模式里。合并的做法是在多端加入“一”端的码作为外键，同时加入联系自身的属性。为什么合并到多端？因为多端的每条记录只对应一个“一”端的记录，加一个外键字段不会产生冗余；反过来如果合并到“一”端，一个部门要存多个员工号，就违反第一范式了。这个理由必须理解，不然考试问你为什么这么合并，答不上来。

多对多联系只有一种处理方式：必须单独转成一个关系模式。属性包括两端实体的码加上联系自身的属性，主键是两端实体码的组合。不能合并到任何一端，因为无论合并到哪一端，都会导致一端存多个值，违反第一范式。

4.3 第三步：合并同类项和消除冗余

所有实体和联系都转换完之后，要检查有没有可以合并的关系模式。合并的条件是：两个关系模式具有相同的码，并且合并之后不会丢失信息、不会引入冗余。典型场景是一对一联系合并之后，两个关系模式的码相同，可以进一步合并成一个。

合并的时候要特别小心，因为合并会改变关系模式的数量，而下午题经常直接问“转换后共有几个关系模式”。如果该合并的没合并，数量就多了；如果强行把不该合并的合并了，数量就少了。判断标准很明确：码相同的才能合并，码不同的绝对不能合并。有一类题会故意设置一个陷阱，两个关系模式的属性有重叠但码不同，这时候不能合并，因为合并之后无法确定主键。

4.4 一个完整案例走一遍

假设一个简单的选课场景：学生有学号、姓名、专业；课程有课程号、课程名、学分；一个学生可以选修多门课程，一门课程可以被多个学生选修，选修时有成绩。转换过程如下。

第一步转实体，得到两个关系模式：学生（学号，姓名，专业）、课程（课程号，课程名，学分），加粗的是主键。

第二步转联系。选修是多对多联系，必须单独建表：选修（学号，课程号，成绩），主键是学号和课程号的组合，同时学号是外键引用学生表，课程号是外键引用课程表。

第三步检查合并。选修表的码是学号和课程号的组合，和学生表、课程表的码都不同，不能合并。最终结果就是三个关系模式。

如果场景改一下，变成“一个学生只能在一个班级，一个班级有多个学生”，那就是一对多联系，可以合并到学生表：学生（学号，姓名，专业，班级号），班级号是外键。如果题目里班级本身有独立属性（比如班级名称、班主任），那班级要先作为实体转成一个关系模式，然后学生表里加外键引用，这时候关系模式数量是三个而不是两个。这个差异是下午题的高频丢分点，实体和联系的边界一定要在第一步就想清楚。

5. 范式与关系代数：关系模型的两块延伸考点

范式和关系代数严格来说属于关系模型理论的延伸，软考里跟数据模型绑在一起考，分开复习很容易割裂。范式的本质是在讨论“什么样的关系模式是好的”，关系代数是在讨论“怎么从关系里取数据”，两者都建立在对关系模式和键的理解之上。这块的复习建议是紧跟在键的判定之后，趁热打铁。

5.1 函数依赖和范式的递进关系

函数依赖描述的是属性之间的决定关系。如果给定X的值就能唯一确定Y的值，就说Y函数依赖于X，记作X→Y。比如学号确定姓名，就是学号→姓名。理解了函数依赖，范式的定义就能串起来。

第一范式要求每个属性都是原子的，不可再分。这是最基本的条件，达不到就不是关系模型。

第二范式在第一范式的基础上，要求每个非主属性完全函数依赖于码，也就是不能有部分依赖。部分依赖指的是某个非主属性只依赖于码的一部分，而不是全部。典型例子是选课关系（学号，课程号，成绩，课程名），码是学号和课程号的组合，成绩完全依赖于这个组合，但课程名只依赖于课程号，属于部分依赖，所以这个关系不满足第二范式。解决办法是把课程名拆到课程表里。

第三范式在第二范式的基础上，要求非主属性不传递依赖于码。传递依赖指的是X决定Y、Y决定Z，从而X决定Z，但Z不是直接依赖于X。经典例子是学生（学号，姓名，系名，系主任），学号决定系名，系名决定系主任，系主任传递依赖于学号，所以不满足第三范式。解决办法是把系名和系主任拆到系表里。

BCNF是第三范式的加强版，要求每个决定因素都包含码。这个定义更严格，但软考里考得不多，知道概念、能判断简单例子就够。

判断范式有一个固定流程：先找出所有候选键，再区分主属性和非主属性，然后看有没有部分依赖、有没有传递依赖，逐层往上判。这个流程走熟了，判断范式就是机械操作，不容易出错。

5.2 关系代数的基本运算和扩展运算

关系代数这部分，核心是记住运算符号和语义。五个基本运算是并、差、笛卡尔积、选择、投影，其余运算都可以由这五个导出。

并、差、交属于传统的集合运算，要求参与运算的两个关系结构相同，也就是属性个数相同、对应属性的域相同。笛卡尔积把两个关系的元组两两组合，结果的元数是两个关系元数之和，基数是两者基数之积。

选择和投影是专门的关系运算。选择是从行方向筛选，按条件挑出满足要求的元组，符号是σ。投影是从列方向筛选，挑出指定的属性列，符号是π，投影之后要去掉重复的元组。这两个运算是关系代数里用得最多的，几乎每道表达式题都会用到。

连接运算是笛卡尔积加选择条件的组合。等值连接是按指定属性相等做连接，自然连接是在等值连接的基础上去掉重复的属性列。自然连接是最常用的，因为它不需要指定连接条件，只要两个关系有同名属性就自动按同名属性连接。

除运算用得少，软考里偶尔出现在选择题里，考的是“查询全部”这类语义，比如“查询选修了全部课程的学生”。遇到这种题，如果不会写除运算，可以先用其他方式理解语义，再对应到符号上。

5.3 用关系代数表达查询的固定套路

写关系代数表达式有一个固定套路，我按这个套路练了十几道题之后基本就不会卡了。

第一步，确定结果需要哪些属性，这一步对应投影。把需要的属性列出来，作为最外层的π。

第二步，确定需要哪些关系，这一步对应笛卡尔积或连接。如果多个关系之间有同名属性，优先用自然连接，没有同名属性就用等值连接或者笛卡尔积加选择。

第三步，确定筛选条件，这一步对应选择。把题目里的条件翻译成比较表达式，多个条件用逻辑与连接。

第四步，检查是否需要分组或去重。投影会自动去重，如果题目要求“至少”“全部”这类语义，考虑用除运算或者嵌套。

举个例子，“查询选修了课程号为C1的学生的姓名”。结果是姓名，所以最外层是π姓名。涉及学生表和选课表，用自然连接。条件是课程号等于C1，翻译成σ课程号='C1'。组合起来就是π姓名(σ课程号='C1'(学生⋈选课))。写完之后检查一遍属性的来源，确保每个属性都能在连接后的关系里找到，就没有问题。

6. 备考节奏：从看懂到做对之间差的是什么

看懂教材和做对题目之间有一段距离，这段距离靠的是针对性的练习和复盘。我在这一块走过弯路，第一遍看教材觉得都懂了，做题正确率不到一半，后来才发现问题出在两个地方：一是概念理解停留在字面，没有形成判定流程；二是做题之后没有复盘，同样的错反复犯。

6.1 真题的正确用法

真题不是拿来刷数量的，是拿来定位薄弱点的。我的做法是把近五年的上午题里涉及数据模型的题目全部挑出来，按知识点分成联系类型判定、键的判定、范式判断、关系代数四类，每类集中做，做完统计正确率。正确率低于七成的那一类，回头重看教材对应章节，看不懂就去找例子推一遍，然后再做题验证。

下午题的做法不一样。下午题的数据库设计大题，我要求自己完整手写，包括画E-R图和写关系模式，写完对照答案逐条核对：实体有没有漏、联系类型对不对、主键标没标、外键写没写、关系模式数量对不对。每一条都单独判断对错，不笼统地说“这道题做得好不好”。这样复盘下来，问题会非常具体，比如“我总是在弱实体的主键确定上出错”“我总是把一对多的方向搞反”，有了具体问题才能针对性解决。

6.2 考场上的时间和顺序安排

上午题的时间相对充裕，但数据模型相关的题目不建议纠结太久。我的习惯是遇到联系类型判定的题，读两遍还没把握就先标记跳过，回头再看。这类题有时候是题目表述有歧义，反复读反而越读越乱，先做别的题换换脑子，回来往往一眼就看出来了。

下午题如果遇到数据库设计大题，先花两分钟把题目里的业务规则逐句读一遍，把“每个”“只能”“可以”这类限定词圈出来，这些词直接决定联系类型。然后按实体、联系、属性的顺序补全E-R图，再按三步走做转换，最后检查主键外键和关系模式数量。整个过程不要跳步，因为下午题按步给分，跳步等于主动放弃过程分。

还有一个小技巧：转换完成之后，用题目给出的业务规则反向验证一遍。比如题目说“一个学生可以选修多门课程”，那就检查选修表是不是以学号和课程号的组合为主键，如果主键只有学号，说明多对多被错判成了一对多，赶紧回头改。这种反向验证花不了一分钟，但能拦住大部分低级错误。