软考软件设计师数据库技术基础：考点、范式与解题技巧全解析

如果你正在备考中级软考软件设计师第九章“数据库技术基础”绝对是不能马虎的一章。它不光是上午题选择题的常客下午场的数据库设计大题也基本从这里出分值占比相当可观。更直白地说数据库部分学好了等于白捡十几分。这篇内容全部围绕软考中级软件设计师考试展开结合历年真题出题习惯把知识点、解题套路和避坑经验一起讲透。适合正在备考软考中级、想快速梳理数据库考点的同学也适合对关系数据库原理感兴趣、想系统补课的人。1. 第九章整体定位与备考策略1.1 为什么第九章是“性价比之王”数据库技术基础在软考软件设计师考试里的地位非常特殊。一方面它是纯理论性内容不像数据结构、算法那样需要大量刷题训练另一方面它又在下午题里占据固定位置一般来说下午第一道大设计题就是数据库设计题分值20分。这就意味着这一章你只要把核心概念和解题模板吃透就能拿到比较稳的分数。很多考生对上午题的概念辨析很头疼但数据库部分其实是上午题里“最讲理”的一块因为它的理论体系非常完整几乎没有歧义。你只要把三级模式、E-R图、范式、事务特性这几个核心概念理解清楚选择题基本不会丢分。相比那些需要大量背诵的软件工程知识点数据库更适合“先理解、再记忆”。我备考的时候把第九章放在了整体复习的第三周。前面先过了一遍计算机组成原理和操作系统有了计算机系统基础概念之后再看数据库理解成本会低很多。如果你时间紧张我建议把这章放在前五章复习因为它是下午题拿分的关键而且学起来相对轻松能快速建立信心。1.2 考试怎么考这套知识点上午题中数据库技术基础相关题目一般是4到7分。常考方向包括三级模式两级映象、关系代数运算、SQL语句语义、范式判断、事务的ACID特性、并发控制与封锁、数据库备份与恢复。这些题目的难度并不高基本上就是概念辨析和简单计算但命题人喜欢在细节上“挖坑”比如主属性与非主属性的区分、全码的概念、各级范式的判定条件都是常见陷阱点。下午题中数据库部分是一道完整的数据库设计题包含E-R图补充、关系模式填空、主键外键判断、规范化设计等内容。这道题的特点是结构固定、规律性强只要平时练过几道真题按步骤拆解拿高分不难。你需要重点关注的是E-R图转关系模式的规则、规范化的分解步骤、以及“联系”在各种场景下的处理方式。这些内容我会在后面逐一展开。2. 核心概念串讲三级模式、数据模型与关系代数2.1 三级模式两级映象别只背不画数据库系统的三级模式结构是整个数据库体系的理论基石。它分为外模式、概念模式和内模式三个层次。外模式也叫用户模式是数据库用户看见和使用的局部数据逻辑结构一个数据库可以有多个外模式概念模式也叫模式是数据库中全体数据的逻辑结构和特征的描述一个数据库只有一个概念模式内模式也叫存储模式是数据物理结构和存储方式的描述一个数据库也只有一个内模式。这三个模式之间的对应关系就是“两级映象”。外模式与概念模式之间的映象保证了数据的逻辑独立性概念模式与内模式之间的映象保证了数据的物理独立性。逻辑独立性的意思就是改变全局逻辑结构时用户视图可以不变应用程序不用改写物理独立性则是说调整存储结构不影响逻辑结构。这里有个真题常考的辨析点“数据的逻辑独立性”由谁保证答案是外模式/概念模式映象。很多人会错选成概念模式/内模式映象那对应的是物理独立性。你可以这样记逻辑问题涉及的是“用户看得见的东西变了”物理问题涉及的是“底层存储变了”。做题时先看题目里说的是哪一层发生变化再判断对应哪种映象正确率会高很多。还有一种考法是给你数据库的三级模式结构图让你标出哪一部分是外模式、哪一部分是内模式。这种题只要你理解了“用户直接接触的是外模式存储介质上的是内模式”就能做对。2.2 数据模型三要素和关系模型的几个硬术语数据模型是数据库系统的核心。数据模型通常由数据结构、数据操作和数据约束三要素组成。数据结构描述系统的静态特性数据操作描述动态特性数据约束描述数据之间的限制关系。软考考察数据模型时喜欢问“关系模型与非关系模型的主要区别”以及“常见的数据模型有哪些”。层次模型、网状模型、关系模型是三种经典数据模型现在考试重点当然是关系模型。关系模型里有几组概念你必须分得清清楚楚。关系一张二维表就是一个关系每个关系都有一个关系名。元组表中的一行就是一个元组对应一个实体或一条记录。属性表中的一列就是一个属性给每个列起个名字就是属性名。域属性的取值范围比如性别的域就是“男、女”。候选码候选键能唯一标识一个元组的最小属性集合。注意“最小”这两个字候选码不能有多余属性。主码主键从候选码里选一个作为主码用于唯一标识表中的行。一张表只能有一个主码但可以有多个候选码。外码外键一个表中的某个属性是另一个表的主码那这个属性就是外码。外码用于建立表之间的关联。主属性包含在任何一个候选码中的属性称为主属性。不包含在任何一个候选码中的属性称为非主属性。全码整个属性组都是候选码称为全码。这里面最容易混淆的是候选码和主码的关系以及主属性和非主属性的判断。真题里会给你一个关系模式列出所有函数依赖让你判断哪个属性是主属性、候选码是什么。这时候你要先把函数依赖图画出来找到所有能够唯一决定其他属性的最小集合然后逐一判断。举个例子关系模式学生学号姓名班级系别函数依赖包括学号→姓名学号→班级学号→系别。那学号就是候选码也是主码学号这个属性就是主属性其他属性都是非主属性。这种基础题一定要拿稳。2.3 关系代数选择、投影、连接怎么才能不丢分关系代数是对关系进行运算的一组规则软考上午题喜欢考它的运算结果以及运算符的含义。重点掌握三类运算选择、投影、连接。选择运算记作σ是选取满足条件的行相当于SQL里的WHERE过滤操作对象是行。它不会减少列数只减少行数。给你一个学生表σ系别‘计算机’(学生)结果就是计算机系的所有学生完整行信息。投影运算记作π是选取特定的列相当于SQL里的SELECT部分指定列操作对象是列。它不会减少行数只减少列数。给出π姓名,系别(学生)结果就是一张只包含姓名和系别两列的表而且如果投影后出现重复行要去掉重复行这是投影的一个特性。自然连接记作⋈是同时按同名属性做等值连接并去掉重复列。它的结果同时减少行和列。连接运算还有θ连接是按给定条件做连接包括等值连接、大于连接等。考试常见的出题方式有两种。一种是给你两个关系表列出具体的数据让你计算某次运算的结果包括结果有几行几列另一种是给你SQL语句让你选出与之等价的关系代数表达式。我印象里有一道真题考查的是“选择”与“投影”的组合运算题目给出一个关系表让你算σ系别‘计算机’∧性别‘男’(π学号,系别,性别(学生))执行后的结果。这类题最关键的是运算顺序关系代数表达式的优先级是先算括号内的再按运算符从前往后。只要你按顺序分步计算就不会出错。还有一个小技巧选择运算的优先级高于投影运算但具体题目给出括号时以括号为先。3. 数据库设计全流程从需求分析到E-R图3.1 数据库设计的六个阶段考试爱考排序数据库设计过程分为六个阶段需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实施、数据库运行与维护。每个阶段的目标不同对应的产物也不一样。需求分析阶段分析用户的需求产出数据流图、数据字典是整个设计的基础。概念结构设计阶段将需求抽象为信息结构产出E-R模型。逻辑结构设计阶段将E-R模型转换为关系模式并做规范化处理。物理结构设计阶段选择合适的存储结构、存取路径、索引等产出物理模型。数据库实施阶段建立数据库、装载数据、编写应用程序并试运行。数据库运行与维护阶段对数据库进行运行监控、性能调优、备份与恢复等。软考中常考“E-R模型属于哪个设计阶段的产物”“逻辑结构设计的核心任务是什么”“数据字典用于哪个阶段”。选择题直接考察这些阶段名称和顺序并不难但如果你记忆混乱就会丢分。我自己有一个顺口溜帮助记忆分析需求概念抽象逻辑转换物理搭架实施运行维护跟进。更值得留意的是“E-R图向关系模式转换”属于逻辑结构设计阶段不是概念结构设计阶段。概念阶段画E-R图形逻辑阶段转成二维表结构。这个区分特别重要真题中反复出现。3.2 E-R图的三要素实体、属性、联系E-R模型是概念结构设计的核心工具用图形描述实体类型、属性和联系。实体用矩形表示属性用椭圆形表示联系用菱形表示实体与属性之间用无向边连接。实体的“码”在属性下面加下划线表示。联系的类型有3种1对1联系、1对多联系、多对多联系。1对1记作1:11对多记作1:n多对多记作m:n。判断联系类型的方法是站在某一方看另一方一个A实体最多对应几个B实体反过来也一样再综合判断。软考下午题经常给出一个业务场景让你补充E-R图中缺失的实体、联系或属性。这种题你只要仔细读题把涉及的关键名词都圈出来再看图上哪个位置空着基本就能填对。填属性时要注意属性一定绑定在对应的实体或联系上不能随意乱放。这里有一个实际场景帮你理解。假设设计一个“学生选课系统”学生可以选多门课程课程可以被多个学生选。学生和课程之间就是m:n联系联系名为“选课”这个联系自身还带有属性“成绩”。E-R图画出来学生实体和学生实体上连着一个菱形“选课”课程实体也连到“选课”菱形再挂一个椭圆属性“成绩”。考试里考的另一个高频点是“一元联系”的处理方法也就是说一个实体集内部的联系。比如“职工”实体中一个职工可以管理多个职工而每个职工只被一个职工管理这就是职工实体上的1:n自联系。画图时要画成实体自己连向菱形再连回自己。转换关系模式时这种自联系也要额外加一个关系模式后面我会细说。3.3 E-R图转关系模式的规则下午题直接照做从E-R图转换到关系模式是下午题几乎必考的环节。规则说起来并不复杂但细节决定成败。实体向关系模式的转换每个实体转换成一个关系模式实体的属性就是关系模式的属性实体的码就是关系模式的码。1对1联系的处理联系可以与任意一端实体对应的关系模式合并。合并的方法是在合并端的关系模式中加入另一端的主码以及联系自身的属性。也可以独立成立一个关系模式包含两端实体的主码和联系自身的属性但通常更推荐合并因为合并后关系模式数量少冗余也少。1对多联系的处理联系最好与n端实体对应的关系模式合并。在n端关系模式中加入1端实体的主码和联系自身的属性。这里非常容易出错合并方向别搞反了。比如“班级”和“学生”是1:n联系应该在学生关系模式中加入班级的主码“班级编号”而不是在班级中加入学生主码。原因很简单一个班级对应很多学生班级表里加学生主码会导致一个班级出现多行表结构就错了。多对多联系的处理联系必须单独转换成一个关系模式。该关系模式的属性包括两端实体的主码和联系自身的属性组合起来作为该关系模式的主码。比如“选课”联系转换为选课学号课程号成绩其中(学号课程号)作为联合主码。多元联系的处理方式三个及以上实体间的联系一般也独立转换为一个关系模式各实体的主码组合成该关系模式的主码。考场上你需要特别注意的是属性下划线标注。转换出的关系模式主码下面要画下划线如果写答案时用文字描述要明确写出“某关系模式的主码为某某”。还有一点多对多联系转换出的关系中外键分别指向两端的实体主码这个细节在解答时最好也写清楚。4. 规范化理论函数依赖与范式判断必须吃透4.1 函数依赖怎么理解才不出错函数依赖是关系模式规范化的基础。简单地说如果属性组X的值确定了属性组Y的值也就唯一确定了就说X函数决定Y记作X→Y其中X称为决定因素。这里最关键的是一组概念完全函数依赖、部分函数依赖、传递函数依赖。完全函数依赖X→Y并且X的任何真子集都不能决定Y就说Y完全函数依赖于X。部分函数依赖X→Y但X的某个真子集也能决定Y就说Y部分函数依赖于X。传递函数依赖X→YY→Z且Y不包含于XX不函数决定Y就说Z传递函数依赖于X。听起来抽象举个例子就清楚了。假设关系模式选课学号课程号成绩学分函数依赖有(学号课程号)→成绩(课程号)→学分。成绩完全依赖于(学号课程号)而学分只依赖于课程号课程号是(学号课程号)的真子集所以学分部分依赖于(学号课程号)。如果设计成这样一个关系模式就会产生数据冗余、更新异常等一系列问题这就是低范式带来的麻烦。所以考试题目里问你“某属性是否存在部分函数依赖”你只要判断该属性能否被候选码的某个真子集决定就可以了。候选码一般是多个属性的组合时才可能出现部分函数依赖单一属性作候选码时不存在部分函数依赖。传递函数依赖的判断有一点绕。判断时先找到一条完整的依赖链比如学号→系别系别→系主任那就存在学号→→系主任的传递依赖。要注意“Y不包含于X”和“X不函数决定Y”这两个条件缺一不可否则不构成传递依赖。真题中有时会人为构造一个貌似传递但实际上不是传递的依赖来迷惑你比如X→YY→X这种相互决定的情况就不是传递函数依赖。4.2 从第一范式到BCNF判断步骤要固定范式是一个关系的规范化程度等级软考重点考察1NF、2NF、3NF和BCNF。第一范式1NF关系中的每一个分量必须是不可再分的数据项。这是关系模式最基本的要求只要表中没有“表中表”、没有重复组就满足1NF。如果某个属性里存了多个值比如“联系电话”字段里存了“010-1234567,13812345678”这就违反了1NF。第二范式2NF在满足1NF的基础上每一个非主属性都完全函数依赖于候选码。说白了就是要消除部分函数依赖。只要候选码是单属性自然满足2NF候选码是复合属性时要检查有没有非主属性只依赖候选码的一部分。第三范式3NF在满足2NF的基础上每一个非主属性既不部分依赖于候选码也不传递依赖于候选码。也就是要消除非主属性对码的传递依赖。BCNF在满足3NF的基础上每一个决定因素都包含候选码。换句话说对于关系模式中的任何函数依赖X→YX都必须包含候选码。BCNF是更严格的3NF它把决定因素必须包含码这个要求扩展到了所有属性包括主属性。判断范式的时候我建议你固定一套流程考试时按部就班就不会乱。第一步确认是否满足1NF看有没有复合属性第二步找出候选码和主属性第三步检查非主属性是否存在部分依赖判断是否满足2NF第四步检查非主属性是否存在传递依赖判断是否满足3NF第五步检查所有决定因素是否都包含候选码判断是否满足BCNF。这里有一个让人头疼的混淆点3NF不满足BCNF的典型例子。比如关系模式S学号姓名系别系主任候选码是学号函数依赖包括学号→系别系别→系主任。由于系主任是非主属性且它传递依赖于学号所以这个模式最多是2NF不满足3NF。但如果换成关系模式SC学号课程号系别系主任候选码是学号加课程号系别和系主任对候选码存在部分依赖那么连2NF都不满足。再给一个满足3NF但不满足BCNF的例子关系模式T学生课程教师存在函数依赖(学生课程)→教师教师→课程。候选码是(学生课程)所有属性都是主属性没有非主属性对码的部分或传递依赖所以满足3NF。但教师→课程这个依赖中决定因素教师不包含候选码所以不满足BCNF。这类例子在真题中出现频率很高一定要能识别出来。4.3 无损分解和保持依赖下午题的高频得分点关系模式的分解要满足两个重要性质无损连接性和保持函数依赖。无损连接性是指分解后的关系通过自然连接能够恢复到原来的关系不丢失任何信息保持函数依赖是指分解后所有函数依赖仍然能在各个子模式中得到体现。软考下午题常见的考法是给你一个关系模式和一组函数依赖让你判断某种分解是否无损或者要求你给出一个满足3NF、保持函数依赖的分解。无损分解的判断有一个经典的表格法不过这个方法步骤多考场上容易算错。还有一个更常用、更快的判断方法当分解只包含两个关系模式时如果两个模式的交集能够决定其中任意一个模式的属性集则这个分解是无损的。也就是说对分解R1和R2如果(R1∩R2)→R1或者(R1∩R2)→R2那么分解具备无损连接性。我一般会在草稿纸上把交集属性圈出来看它能否推出R1的完整属性或R2的完整属性。如果能就直接判定无损。这个方法在下午题特别管用因为下午题通常只让你判断两个关系模式。对于满足3NF且保持函数依赖的分解有一个标准做法在函数依赖集F中如果某个属性不出现在任何依赖的左右两侧就把它单独组成一个关系模式否则对于每一个函数依赖X→Y将XY作为一个关系模式的属性集。如果这些新关系模式的属性集都不能包含候选码那么再增加一个以候选码为属性的关系模式。实际答题时我建议你先把所有函数依赖梳理清楚画出依赖图找出候选码再按规则分解。如果分解后某些函数依赖“丢了”就说明没有保持依赖需要调整分解方案。历年真题里这道小题通常占4分左右步骤清晰的话很容易拿满。5. 事务与并发控制ACID和封锁协议5.1 ACID特性四个字母各有各的考法事务是数据库操作的一个逻辑单元具有四个特性原子性、一致性、隔离性、持久性缩写为ACID。原子性事务中所有操作要么全部完成要么全部不完成不会停在中间状态。一致性事务执行前和执行后数据库都处于一致状态完整性约束不被破坏。隔离性并发执行的事务之间互不干扰一个事务的中间状态对其他事务不可见。持久性事务一旦提交对数据库的改变就是永久的即使系统发生故障也不会丢失。上午题对这个知识点有几个固定的出题角度。一是问你“事务的哪个特性由DBMS的恢复子系统实现”答案是持久性因为恢复机制负责在故障后把已提交事务的修改恢复出来。二是问你“并发操作可能导致哪些一致性问题”这个问题和下一个知识点联在一起考。这里我想特别强调原子性和一致性的区别常被混淆。原子性侧重的是“不可分割”要么全做要么全不做一致性侧重的是“正确性约束”不管怎么做结果必须满足所有约束。一个事务即使原子地执行了但如果它违反了完整性约束而导致数据库不一致那也是一致性出了问题。恢复子系统主要保证原子性和持久性并发控制子系统主要保证一致性和隔离性。5.2 并发带来的三个问题用例子秒懂当多个事务并发执行时如果不加控制会产生三类问题丢失更新、不可重复读、脏读。丢失更新两个事务同时读取同一数据各自修改后写回后提交的事务覆盖了先提交的事务的结果导致一个更新被丢失。可以理解为两个人同时编辑同一份文档后保存的那个人把先保存的人做的修改覆盖掉了。不可重复读一个事务内两次读取同一数据得到不同的结果。原因是另一个事务在两次读取之间修改了该数据。举例来说事务A第一次读取余额为500元事务B随后把余额改成800元并提交事务A再次读取时发现变成了800元。脏读一个事务读取到了另一个事务尚未提交的中间数据。另一个事务之后回滚了那读到的就是“脏”数据这个数据最终不存在于数据库里。比如事务A读取了事务B修改但未提交的余额600元随后事务B回滚余额恢复为500元事务A基于600元做了操作那这个操作就是基于错误数据的。软考经常用具体数据来构造题目。解题的关键是看两个事务的操作序列和提交回滚状态如果两个事务各自修改同一个数据则是丢失更新如果同一事务内两次读取结果不同则是不可重复读如果读取了未提交事务修改的数据则是脏读。5.3 封锁协议和隔离级别软考划线重点数据库管理系统的并发控制主要采用封锁机制。基本的封锁类型有两种共享锁S锁和排他锁X锁。共享锁允许多个事务同时读取数据但不允许修改排他锁则只允许持锁事务读写该数据其他事务不能加任何锁。三级封锁协议在软考中经常考到。一级封锁协议事务在修改数据之前加X锁直到事务结束才释放。这个协议可以防止丢失更新但不能防止脏读和不可重复读。二级封锁协议在一级封锁协议的基础上事务在读取数据之前加S锁读完即释放。它可以防止丢失更新和脏读但不能防止不可重复读。三级封锁协议在二级封锁协议的基础上事务在读取数据之前加S锁直到事务结束才释放。三个问题都能防止。这个知识点在选择题里最常见的问法就是“某级封锁协议可以防止哪些并发问题”。我有一个好记的办法一级管写防丢更二级加读防脏读三级延续读锁防不可重复读。只要把对应关系背熟这种题就是送分题。隔离级别和封锁协议是有关联的。SQL标准定义了四个隔离级别由低到高分别是读未提交、读已提交、可重复读、可串行化。读未提交允许脏读读已提交防止脏读但可能出现不可重复读可重复读防止脏读和不可重复读但可能出现幻读可串行化则完全隔离并发事务防止所有问题。软考上午题有时会结合具体场景让你选择最合适的隔离级别这时候要看题目描述的是哪种并发问题再对应选择。6. SQL操作、备份恢复与数据库安全6.1 SQL语句常考题型与解题模板SQL部分是上午题的常客主要考察基本的数据定义、数据操纵和数据控制语句。你需要掌握以下内容。数据定义语言DDL包括CREATE、ALTER、DROP三种语句。考试常考的是CREATE TABLE建表语句、修改表结构的ALTER语句、删除表的DROP语句。建表语句中要会定义主键、外键、唯一约束会判断约束是否存在语法错误。数据操纵语言DML包括INSERT、UPDATE、DELETE、SELECT。软考主要考察SELECT的各种子句SELECT列名FROM表名WHERE条件GROUP BY分组HAVING过滤ORDER BY排序以及连接查询、嵌套查询、集合运算、聚合函数。这些内容在下午题里也会出现比如在嵌入式SQL或JDBC编程题中要求你补全SQL语句。数据控制语言DCL包括GRANT授权和REVOKE收回权限。上午题会问GRANT语句的语法格式以及权限级别。SQL考题最容易丢分的地方有两个。第一个是聚合函数和分组的搭配使用WHERE不能直接使用聚合函数作为筛选条件必须用HAVING。比如“查询平均成绩大于80分的课程”必须用GROUP BY课程号HAVING AVG(成绩)80不能写成WHERE AVG(成绩)80。第二个是连接查询和子查询的转换SQL中既可以用JOIN连接两张表也可以用IN嵌套子查询两者结果相同但要分清效率差异。还有一个小细节SQL语句中字符串用单引号别名可以用AS指定COUNT(*)和COUNT(列名)的区别在于前者统计所有行后者不统计NULL值。软考偶尔会在这些细节上出题多留意一下。6.2 索引、视图与数据库安全基础数据库安全与备份恢复这部分上午题经常出2分左右的选择题。索引的作用是加快数据查询速度但会降低数据更新速度因为每次INSERT、UPDATE、DELETE都需要维护索引。考试常问“索引能提高哪些操作的效率”“索引过多会造成什么影响”。答案一般是能提高查询效率但会增加存储开销、降低增删改效率。唯一索引保证列值唯一适合用于主键或唯一性要求高的列。视图是一个虚表它是从基本表导出的表数据库中只存放视图的定义不存放视图对应的数据。对视图的修改通常不能直接反映到基本表上特别是有聚合、分组、多表连接时。软考问“视图的数据存储在哪里”你脑子里就要立刻反应出“不存储实际数据只有定义”。视图的好处是简化查询、提供安全保护、逻辑独立性。数据库安全技术包括用户标识与鉴别、存取控制自主存取控制DAC和强制存取控制MAC、视图机制、审计、数据加密等。软考常考“自主存取控制与强制存取控制的区别”关键点是自主存取控制中用户对数据的访问权限可以授予他人强制存取控制则根据密级和许可证级别进行严格管理。备份与恢复方面重点掌握几种备份类型完全备份、差量备份差异备份、增量备份。完全备份是备份整个数据库全部数据恢复最慢、占用空间最大差量备份是备份自上次完全备份以来变化的数据恢复比增量备份快但备份空间比增量备份大增量备份是备份自上次备份以来变化的数据备份快、占用空间小但恢复时需要按顺序加载多个备份。软考的设问方式通常是“哪种备份占用空间最小”“哪种备份恢复时间最长”对这种题直接对比三者的特点即可。日志文件在数据库恢复中起着关键作用。数据库故障恢复时会根据日志记录将数据库恢复到某一一致状态。对于“未提交事务”要执行撤销操作UNDO对于“已提交但尚未写入数据库的事务”要执行重做操作REDO。这个知识点偶尔在选择题中出现理解为“提交则重做未提交则撤销”就行了。7. 下午题实战数据库设计题的五步解法7.1 题型结构与常见套路下午题的数据库设计题一般是给出一个实际业务场景的描述然后要求补充E-R图、转换关系模式、指出主键外键、判断范式或进行规范化。这道题的特点是“套路极其固定”所有信息都藏在题目文字里。读题时我习惯把每个实体名称、每个明显的属性、每个“实体之间的关系”都用笔圈出来然后在草稿纸上先画一个粗糙的E-R草图。这一步非常关键因为题目的图形往往是残缺的你要补全的东西必须先在你自己的草图里出现。7.2 五步解题法考场直接套用第一步找实体。把所有业务名词圈出来。通常来说题目描述中反复出现的核心对象都是实体比如“顾客”“订单”“商品”“仓库”“员工”“部门”。实体之间如果存在“拥有”“包含”“管理”“选择”等动词往往就是联系。第二步判联系。对每一对实体判断联系的类型。先看“一个A可以对应几个B”再看“一个B可以对应几个A”综合得出1:1、1:n还是m:n。如果联系本身带有属性比如成绩、数量、时间这个联系就必须单独表示。第三步转关系模式。按前文讲的规则把每个实体和每个需要独立处理的联系都转换为关系模式。你要注意1:n联系的合并方向、m:n联系必须独立建表这两条规则是阅卷给分点写错直接丢分。第四步标主键外键。每个关系模式的主键写清楚如果存在外键就标注外键并写明引用哪张表的主键。对于m:n联系转换出的关系外键有两个分别指向两端实体的主键。第五步查规范化。检查题目是否要求判断范式或给出分解方案。如果需要规范化到3NF你要从候选码出发分析非主属性是否存在部分或传递函数依赖有就拆解直到每个关系模式满足3NF。如有无损分解要求再用我前面说的交集判断法验证一遍。7.3 历年真题实例拆解这里我举一个比较典型的例子。假设题目描述了一个“图书管理系统”读者可以借阅多本图书每本图书也可以被多个读者借阅借阅时记录借书日期、还书日期。读者有读者编号、姓名、联系电话属性图书有图书编号、书名、作者、出版社属性。这个场景里实体是“读者”和“图书”联系是“借阅”。一个读者可以借多本书一本书可以被多个读者借所以联系类型是m:n。联系“借阅”自身带有借书日期和还书日期两个属性。E-R图补充时需要在“读者”和“图书”之间画一个菱形“借阅”从菱形引出借书日期、还书日期两个椭圆属性。转换成关系模式后应为读者读者编号姓名联系电话主码读者编号图书图书编号书名作者出版社主码图书编号借阅读者编号图书编号借书日期还书日期主码(读者编号图书编号)外码读者编号引用读者表图书编号引用图书表题目如果问你“该关系模式最高满足第几范式”答案就是BCNF因为每个关系模式里没有非主属性的部分依赖和传递依赖决定因素也都是候选码。但如果题目把借阅关系扩展为借阅读者编号读者姓名图书编号书名借书日期并且描述中读者姓名和书名分别依赖于读者编号、图书编号那么这一模式就会出现部分函数依赖最高只有1NF。解题时一定要看清题目给定的函数依赖合集。8. 避坑指南与速记手册8.1 三个让我差点翻车的知识坑备考和实战里有几个坑特别容易让人翻车我单独拿出来说。第一个坑是“外模式/概念模式映象”与“概念模式/内模式映象”的功能区分。简单说外模式/概念模式映象服务的是逻辑独立性概念模式/内模式映象服务的是物理独立性。我见过不少人在刷题时把这两个搞反包括我自己早期也中过招。我的办法是看到“逻辑”两个字就想外模式看到“存储/物理”就想内模式。第二个坑是“满足3NF的关系模式不一定满足BCNF”这句话在真题中出现很多次。考试时题目会给你一个函数依赖清单表面上都是主属性之间的依赖让你误以为已经是高范式了实际上BCNF要求所有决定因素都包含候选码。所以判断BCNF时千万别只盯着“是否有非主属性”要检查每一个函数依赖左边是否都包含候选码。第三个坑是“1:n联系合并到n端而不是1端”。很多人凭直觉把1端的主码加到n端表里结果关系模式设计错误。理解背后的原因就记住了1端的一条记录要对应n端的多条记录所以外键要放在n端且这个外键的值可以在n端重复出现。如果放在1端就会导致n端的多条记录拆分到1端的多行里破坏了表的原子性。8.2 考前速查表核心考点一页记下面是第九章最核心的知识点速查表考前过一遍能帮你快速唤醒记忆。考点关键信息三级模式外模式、概念模式、内模式两级映象分别对应逻辑独立性和物理独立性数据模型三要素数据结构、数据操作、数据约束关系模型为核心候选码能唯一标识元组的最小属性集合可多个主属性包含在任一候选码中的属性全码是特殊候选码E-R图实体矩形、属性椭圆、联系菱形联系类型1:1、1:n、m:nE-R转关系模式实体各成一张表1:n合并到n端m:n单独建表1NF属性不可再分2NF消除非主属性对码的部分依赖3NF消除非主属性对码的传递依赖BCNF每个决定因素都包含候选码事务特性A原子性、C一致性、I隔离性、D持久性并发问题丢失更新、不可重复读、脏读三级封锁一级防丢失更新二级加防脏读三级加防不可重复读备份类型完全备份最占空间、恢复最慢增量备份占空间最小、恢复最慢需多次恢复8.3 最后一点个人经验数据库技术基础这一章说难也难说简单也简单。难是因为它概念链比较长从数据模型到范式再到并发控制每一步都建立在前一步之上中间掉一环后面就会卡住。简单是因为它的考点非常集中软考命题多年这一章几乎没有超出上述范围的题目出现。我个人的建议是先花两个晚上把概念全部过一遍不急着刷题然后专门看近五年的真题把数据库相关的所有题目摘出来集中做一周最后总结自己的错误类型重点突破。下午题的数据库设计题如果你能把五步法练熟比上午题拿分更有把握因为这题的评分标准很清晰按点给分不会存在主观判断。如果你正在刷真题看到某个关系模式的分解题尽量先自己在草稿纸上算一遍再对照答案而不是直接背答案。这种动手计算的过程对考场上的速度提升帮助非常大。顺便说个小技巧考前一天把这章的速查表抄一遍不用背就是写一遍到了考场上你会发现很多模糊的概念会自动想起来。这个方法不只在数据库这一章管用对软考其他章节也适用。祝备考顺利一次过。