备考数据库这一章的时候我见过太多人把E-R图的矩形、椭圆、菱形背得滚瓜烂熟一到做题还是卡壳。问题不在于记性而在于很多人把这两套模型当成两套独立的图形符号去背没搞清楚它们之间是什么关系、考试为什么非要把它们放在一起考。数据模型这一块在软考里属于典型的“分值不大但丢不起”的内容上午题里数据库系统部分通常只有几分E-R模型和关系模型相关的题能占到其中一半下午题如果碰上数据库设计大题E-R图补全加关系模式转换几乎是标配。这篇内容我打算把E-R模型和关系模型拆开讲透再讲清楚两者之间的转换链路以及范式和关系代数这两块延伸考点。适合刚接触软考数据库部分、看教材觉得术语太多抓不住重点的人也适合考过一次发现这块总是丢分、想回头系统补一遍的人。文中涉及的判定方法和答题套路都是我自己反复做题、整理错题之后总结出来的能直接拿去用。1. 数据库章节里数据模型这块分值不重但丢不起软考数据库部分的考法有个很明显的特征知识点铺得很宽但真正反复出题的核心就那么几块数据模型是其中之一。很多人复习时会做一道算术题——数据库在上午题里才几分E-R模型和关系模型又只占其中一部分投入产出比不高于是草草翻过。我一开始也是这么想的直到在下午题上栽了跟头才明白这块内容的真正价值不在上午那几道选择题而在于它是数据库设计大题的入口。E-R图看不懂、关系模式转不出来后面那些范式判断、SQL语句填空基本连锁崩盘。1.1 上午题和下午题对两类模型的不同考法上午题考数据模型基本都是概念辨析和快速判定。常见问法有几种给出一个场景描述问两个实体之间是什么联系类型给出一个关系模式问哪个属性组是候选键给出几个函数依赖问这个关系最高满足第几范式给出一个E-R图片段问转换成关系模式后有几个关系、主键是什么。这类题的特点是单题耗时短、答案唯一、没有过程分会就是会不会就只能猜。下午题的考法完全是另一个路数。典型形式是给一段业务说明加一张不完整的E-R图要求补充缺失的实体、联系或属性然后转换成关系模式标出每个关系的主键和外键有时候还会追问某个关系是否满足3NF、怎么分解。这类题有过程分即使最终答案不完美把实体和联系补对、把转换规则走对也能拿到大部分分数。所以我在复习这块的时候上午题和下午题是分开练的上午题练速度和概念辨析下午题练流程完整性和书写规范。题型位置主要考查形式答题要求我在复习时的侧重上午题联系类型判定、键的判定、范式判断结论唯一无过程分限时训练每题控制在40秒内下午题E-R图补全、关系模式转换、主外键标注有过程分看步骤完整性手写完整流程规范画图交叉考点关系代数表达式、视图与完整性常在上午题出现记住基本运算符号和含义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是第三范式的加强版要求每个决定因素都包含码。这个定义更严格但软考里考得不多知道概念、能判断简单例子就够。范式核心要求要消除的依赖典型拆分1NF属性原子无多值属性单独建表2NF非主属性完全依赖码部分函数依赖把只依赖部分码的属性拆出3NF非主属性不传递依赖码传递函数依赖把间接依赖的属性拆出BCNF每个决定因素都包含码主属性对码的部分和传递依赖按函数依赖进一步分解判断范式有一个固定流程先找出所有候选键再区分主属性和非主属性然后看有没有部分依赖、有没有传递依赖逐层往上判。这个流程走熟了判断范式就是机械操作不容易出错。5.2 关系代数的基本运算和扩展运算关系代数这部分核心是记住运算符号和语义。五个基本运算是并、差、笛卡尔积、选择、投影其余运算都可以由这五个导出。并、差、交属于传统的集合运算要求参与运算的两个关系结构相同也就是属性个数相同、对应属性的域相同。笛卡尔积把两个关系的元组两两组合结果的元数是两个关系元数之和基数是两者基数之积。选择和投影是专门的关系运算。选择是从行方向筛选按条件挑出满足要求的元组符号是σ。投影是从列方向筛选挑出指定的属性列符号是π投影之后要去掉重复的元组。这两个运算是关系代数里用得最多的几乎每道表达式题都会用到。连接运算是笛卡尔积加选择条件的组合。等值连接是按指定属性相等做连接自然连接是在等值连接的基础上去掉重复的属性列。自然连接是最常用的因为它不需要指定连接条件只要两个关系有同名属性就自动按同名属性连接。除运算用得少软考里偶尔出现在选择题里考的是“查询全部”这类语义比如“查询选修了全部课程的学生”。遇到这种题如果不会写除运算可以先用其他方式理解语义再对应到符号上。5.3 用关系代数表达查询的固定套路写关系代数表达式有一个固定套路我按这个套路练了十几道题之后基本就不会卡了。第一步确定结果需要哪些属性这一步对应投影。把需要的属性列出来作为最外层的π。第二步确定需要哪些关系这一步对应笛卡尔积或连接。如果多个关系之间有同名属性优先用自然连接没有同名属性就用等值连接或者笛卡尔积加选择。第三步确定筛选条件这一步对应选择。把题目里的条件翻译成比较表达式多个条件用逻辑与连接。第四步检查是否需要分组或去重。投影会自动去重如果题目要求“至少”“全部”这类语义考虑用除运算或者嵌套。举个例子“查询选修了课程号为C1的学生的姓名”。结果是姓名所以最外层是π姓名。涉及学生表和选课表用自然连接。条件是课程号等于C1翻译成σ课程号C1。组合起来就是π姓名(σ课程号C1(学生⋈选课))。写完之后检查一遍属性的来源确保每个属性都能在连接后的关系里找到就没有问题。6. 备考节奏从看懂到做对之间差的是什么看懂教材和做对题目之间有一段距离这段距离靠的是针对性的练习和复盘。我在这一块走过弯路第一遍看教材觉得都懂了做题正确率不到一半后来才发现问题出在两个地方一是概念理解停留在字面没有形成判定流程二是做题之后没有复盘同样的错反复犯。6.1 真题的正确用法真题不是拿来刷数量的是拿来定位薄弱点的。我的做法是把近五年的上午题里涉及数据模型的题目全部挑出来按知识点分成联系类型判定、键的判定、范式判断、关系代数四类每类集中做做完统计正确率。正确率低于七成的那一类回头重看教材对应章节看不懂就去找例子推一遍然后再做题验证。下午题的做法不一样。下午题的数据库设计大题我要求自己完整手写包括画E-R图和写关系模式写完对照答案逐条核对实体有没有漏、联系类型对不对、主键标没标、外键写没写、关系模式数量对不对。每一条都单独判断对错不笼统地说“这道题做得好不好”。这样复盘下来问题会非常具体比如“我总是在弱实体的主键确定上出错”“我总是把一对多的方向搞反”有了具体问题才能针对性解决。6.2 考场上的时间和顺序安排上午题的时间相对充裕但数据模型相关的题目不建议纠结太久。我的习惯是遇到联系类型判定的题读两遍还没把握就先标记跳过回头再看。这类题有时候是题目表述有歧义反复读反而越读越乱先做别的题换换脑子回来往往一眼就看出来了。下午题如果遇到数据库设计大题先花两分钟把题目里的业务规则逐句读一遍把“每个”“只能”“可以”这类限定词圈出来这些词直接决定联系类型。然后按实体、联系、属性的顺序补全E-R图再按三步走做转换最后检查主键外键和关系模式数量。整个过程不要跳步因为下午题按步给分跳步等于主动放弃过程分。还有一个小技巧转换完成之后用题目给出的业务规则反向验证一遍。比如题目说“一个学生可以选修多门课程”那就检查选修表是不是以学号和课程号的组合为主键如果主键只有学号说明多对多被错判成了一对多赶紧回头改。这种反向验证花不了一分钟但能拦住大部分低级错误。