数据库系统概论复习指南：高频试题解析与避坑技巧

简介：这份《数据库系统概论各章复习试题及答案》PDF面向高校计算机专业学生及备考数据库相关课程考试的学习者，围绕数据管理技术演进、三级模式与两级映射、数据独立性、完整性约束、并发控制与恢复等核心考点，提供分章节的复习题与参考答案，帮助读者系统梳理概念、检验掌握程度。资源包共1个PDF文件，大小约1.08MB，内容按章节组织，涵盖选择题、填空题与简答题等常见题型，便于按模块检索与自测。目前已有360人学习下载，适合需要集中刷题、查漏补缺的中初级学习者。通过逐章练习，读者可巩固数据库基本概念、体系结构、SQL操作与设计流程等知识点，并借助答案对照理解易错点，提升应试与知识运用能力。

1. 数据库系统概论复习的破局点：从背概念到能做题

很多人复习《数据库系统概论》的方式是打开教材从第一页硬啃，结果翻到第三范式就已经忘了第一范式在讲什么。这门课的知识点密度极高——关系代数、SQL、范式分解、事务隔离、并发控制、ER 图转换，每一块都能单独出大题，但它们之间又互相咬合。真正高效的复习路径不是线性通读，而是以题带点：先做各章典型试题，暴露盲区，再回头补对应的概念和推导过程。一份按章节组织的复习试题与答案，本质上就是一张知识地图的索引——它告诉你每章会考什么形态的题、答案的推导链条长什么样、哪些概念是必须能默写出来的。这篇文章面向正在准备期末考试、考研复试或课程补考的人，也面向需要快速把数据库核心知识捡回来的开发者。接下来我会按章节拆解高频考点、给出可复现的解题步骤，并指出那些反复翻车的细节。

2. 关系模型与关系代数：试题里最容易被绕进去的推导

2.1 关系代数运算的考题形态与手推方法

关系代数在试卷里几乎不会考纯定义，它总是以两种形态出现：一是给出几个小关系表，要求写出某个查询的关系代数表达式；二是给出一个表达式，要求计算结果关系的元组集合。前者的难点在于选对运算符组合，后者的难点在于笛卡尔积展开后不丢元组。

我一般建议按这个顺序手推：先确定结果需要哪些属性（决定投影 π 的范围），再确定需要连接哪几张表（决定笛卡尔积或自然连接），最后把选择条件 σ 逐条加上去。这个顺序能避免一个常见错误——先做笛卡尔积再筛，结果属性列数爆炸，自己把自己绕晕。

举个典型题：学生表 S(sno, sname, dept)，选课表 SC(sno, cno, grade)，课程表 C(cno, cname, credit)。查询“选修了‘数据库’课程且成绩大于 80 的学生姓名”。

-- 关系代数表达式（对应 SQL 见下方） -- π_sname( σ_grade>80 ∧ cname='数据库' ( S ⋈ SC ⋈ C ) )

对应的 SQL 写法：

SELECT S.sname FROM S JOIN SC ON S.sno = SC.sno JOIN C ON SC.cno = C.cno WHERE C.cname = '数据库' AND SC.grade > 80;

逻辑说明：自然连接 S ⋈ SC ⋈ C 先把三张表按同名属性拼起来，σ 同时施加成绩和课程名两个条件，最后 π 只保留 sname。参数上要注意，如果题目要求“只选修了数据库一门课的学生”，那就不是简单的选择投影，需要用到除法运算或 NOT EXISTS 双重否定，这是关系代数里区分度最高的一类题。

关系代数除法的考题在期末卷里出现频率不低，但很多人到考场上才临时推。我的做法是把它转成“全部…都…”的语义，然后用差集表达：R ÷ S = π_x(R) - π_x( (π_x(R) × S) - R )。这个公式背下来，遇到“选修了全部课程的学生”这类题直接套。

2.2 ER 图转关系模式：试题答案里的隐藏扣分点

ER 图转关系模式是数据库系统概论里必考的一道大题，通常给一个场景描述（比如“一个仓库有多个管理员，一个管理员只能管一个仓库，每种零件可以存放在多个仓库……”），要求画出 ER 图并转换成关系模式，标注主键和外键。

转换规则本身不复杂：实体转表，1:1 和 1:n 联系可以合并到某一端，m:n 联系必须单独建表。但试题答案里经常扣分的地方在于——只写了表名和字段，没标主键下划线，没标外键的参照关系，或者把弱实体的主键漏了。

我整理了一个转换检查清单，每次做完题对一遍：

举个例子，场景是“一个学生可以选修多门课，一门课可以被多个学生选，选课后有成绩”。ER 图里学生和课程是实体，选课是 m:n 联系，成绩是联系上的属性。转成关系模式：

-- 学生表 Student(sno PRIMARY KEY, sname, dept); -- 课程表 Course(cno PRIMARY KEY, cname, credit); -- 选课表（m:n 联系单独建表） SC(sno, cno, grade, PRIMARY KEY(sno, cno), FOREIGN KEY(sno) REFERENCES Student(sno), FOREIGN KEY(cno) REFERENCES Course(cno));

参数说明：SC 表的主键是 (sno, cno) 复合主键，这是 m:n 联系转表的标志。grade 作为联系属性放在 SC 上，不能放到 Student 或 Course 里。如果题目还要求“每门课最多选 60 人”，那属于完整性约束，在关系模式里用 CHECK 或触发器表达，但试题通常只要求文字说明。

注意：ER 图转关系模式时，如果题目给了“部分参与”和“全部参与”的约束，全部参与的那一端在转表时外键不能为空，这个细节在答案里经常被忽略。

3. SQL 与范式：从写查询到判断第几范式

3.1 SQL 查询题的分层拆解策略

SQL 是数据库系统概论试卷里分值最重的一块，通常有 3 到 5 道查询题，从单表查询到嵌套查询到分组统计层层递进。很多人写 SQL 的毛病是拿到题就从头开始写 SELECT，写到一半发现条件不对又回头改，最后语句结构混乱。

我的做法是分三层拆：第一层确定结果列（SELECT 什么），第二层确定数据来源（FROM 哪些表，JOIN 条件是什么），第三层确定过滤和分组（WHERE、GROUP BY、HAVING、ORDER BY）。每层写之前先在草稿上标出来，再拼成完整语句。

看一道典型的分组统计题：查询“平均成绩大于 75 分的课程号和平均成绩”。

SELECT cno, AVG(grade) AS avg_grade FROM SC GROUP BY cno HAVING AVG(grade) > 75;

逻辑说明：GROUP BY cno 把选课记录按课程分组，AVG(grade) 计算每组平均分，HAVING 对分组后的结果过滤。这里的关键参数是 WHERE 和 HAVING 的区别——WHERE 在分组前过滤行，HAVING 在分组后过滤组。如果题目改成“查询平均成绩大于 75 分的课程号和课程名”，就需要 JOIN Course 表：

SELECT C.cno, C.cname, AVG(SC.grade) AS avg_grade FROM SC JOIN Course C ON SC.cno = C.cno GROUP BY C.cno, C.cname HAVING AVG(SC.grade) > 75;

注意 GROUP BY 后面必须带上 C.cname，因为 SELECT 里出现了非聚合列，标准 SQL 要求它出现在 GROUP BY 中。这是试题里高频的扣分点。

嵌套查询里最常考的是 EXISTS 和 NOT EXISTS。比如“查询选修了全部课程的学生姓名”，标准解法是双重 NOT EXISTS：

SELECT sname FROM Student S WHERE NOT EXISTS ( SELECT * FROM Course C WHERE NOT EXISTS ( SELECT * FROM SC WHERE SC.sno = S.sno AND SC.cno = C.cno ) );

逻辑说明：外层 NOT EXISTS 找“没有哪门课是没选的”学生，内层 NOT EXISTS 找“该学生没选的课”。两层否定叠加就是“选了全部课程”。这个结构第一次看很绕，但它是 SQL 里表达全称量词的固定套路，背下来直接套。

3.2 范式判断：试题答案的推导链条怎么还原

范式判断是试卷里另一道必考大题，通常给一个关系模式加一组函数依赖，要求判断最高属于第几范式，如果不到 3NF 还要分解。很多人判断的时候靠感觉，觉得“看起来挺规范的”就写 3NF，结果答案是 2NF，因为存在非主属性对码的部分依赖。

我一般按这个顺序推：先找候选码（能推出所有属性的最小属性集），再找主属性和非主属性，然后逐条检查函数依赖。1NF 要求属性不可再分，这个通常都满足。2NF 要求不存在非主属性对候选码的部分依赖——如果候选码是复合的，就要检查有没有非主属性只依赖于候选码的一部分。3NF 要求不存在非主属性对候选码的传递依赖。

举个例子：关系模式 R(学号, 课程号, 成绩, 教师名, 教师办公室)，函数依赖集 F = { (学号,课程号)→成绩, 课程号→教师名, 教师名→教师办公室 }。

推导过程：候选码是 (学号, 课程号)。非主属性是成绩、教师名、教师办公室。成绩完全依赖于候选码，没问题。但教师名只依赖于课程号，而课程号是候选码的一部分，所以存在部分依赖，R 不满足 2NF。分解时把部分依赖拆出去：

-- 拆成三个关系 R1(学号, 课程号, 成绩); -- 满足 3NF R2(课程号, 教师名); -- 满足 3NF R3(教师名, 教师办公室); -- 满足 3NF

参数说明：分解后的每个关系都要标注主键。R1 的主键是 (学号, 课程号)，R2 的主键是课程号，R3 的主键是教师名。分解要保持无损连接和函数依赖保持，试题里通常要求说明这两点。无损连接的判断方法是看分解后的自然连接能否还原原关系，函数依赖保持的判断方法是看 F 的每个依赖是否在某个子关系的投影依赖集里。

提示：范式分解题里，如果题目只要求“分解到 3NF”，不需要追求 BCNF。BCNF 要求每个决定因素都包含候选码，条件更严，有些 3NF 分解不满足 BCNF，但试题不会因此扣分。

4. 事务、并发与恢复：试题里最容易翻车的三个点

4.1 可串行化调度的判断方法

并发控制的考题通常给一个调度序列，要求判断是否可串行化。很多人看到读写交替就懵了，其实判断方法很固定：画出优先图，如果图里没有环就是可串行化的。

优先图的画法：对于每一对冲突操作（不同事务对同一数据项的操作，至少一个是写），如果 Ti 的操作先于 Tj 的操作，就画一条 Ti→Tj 的边。所有边画完后检查有没有环。

看一个典型调度：R1(A) W2(A) R1(B) W2(B) R3(A) W3(B)。冲突对分析：R1(A) 和 W2(A) 冲突，R1(A) 在前，画 T1→T2。R1(B) 和 W2(B) 冲突，画 T1→T2。W2(A) 和 R3(A) 冲突，画 T2→T3。W2(B) 和 W3(B) 冲突，画 T2→T3。优先图是 T1→T2→T3，无环，可串行化，等价于串行顺序 T1, T2, T3。

如果调度里出现 W1(A) R2(A) W2(A) R1(A)，冲突对是 W1(A) 和 R2(A) 画 T1→T2，R2(A) 和 W2(A) 不冲突（都是 T2），W2(A) 和 R1(A) 画 T2→T1。优先图里 T1→T2 和 T2→T1 形成环，不可串行化。

这个方法的参数要点是：只考虑冲突操作，不冲突的操作之间不画边。读读操作不冲突，不同数据项的操作不冲突。试题里经常混入不冲突的操作来干扰判断。

4.2 两段锁协议与死锁的试题形态

两段锁协议（2PL）的考题通常问“某个调度是否遵守 2PL”或者“2PL 能否保证可串行化”。前者的判断方法是看每个事务的加锁和解锁是否分两个阶段——加锁阶段不能有解锁，解锁阶段不能有加锁。后者的答案是能保证可串行化，但不能避免死锁。

死锁的考题会给一个调度，问是否发生死锁。判断方法是看有没有事务在等待另一个事务持有的锁，且形成循环等待。比如 T1 持有 A 的锁等待 B，T2 持有 B 的锁等待 A，就是死锁。

预防死锁的常见方法有一次封锁法和顺序封锁法。一次封锁法要求事务一次性申请所有需要的锁，缺点是降低了并发度。顺序封锁法要求所有事务按同一顺序申请锁，缺点是维护锁顺序的开销大。试题里通常要求对比这两种方法的优缺点，答案要写到“一次封锁法可能浪费锁资源，顺序封锁法需要预知所有锁对象”。

4.3 日志恢复的 undo 和 redo 判断

恢复技术的考题通常给一个日志序列，包含事务的开始、更新、提交和检查点，要求说明系统崩溃后哪些事务需要 redo、哪些需要 undo。

判断规则：已经提交的事务需要 redo（重做），未提交的事务需要 undo（撤销）。如果有检查点，检查点之前已提交的事务不需要 redo（因为已经落盘），检查点之后提交的事务需要 redo，崩溃时未提交的事务需要 undo。

看一个日志例子：

T1: start, update A, commit T2: start, update B T3: start, update C, commit CHECKPOINT T4: start, update D, commit T5: start, update E CRASH

分析：T1 和 T3 在检查点前已提交，不需要 redo。T4 在检查点后提交，需要 redo。T2 和 T5 崩溃时未提交，需要 undo。T2 在检查点前开始但未提交，undo 时要回滚它的更新。

参数说明：undo 操作是按日志逆序执行反向操作，redo 操作是按日志正序重新执行。试题里经常要求写出具体的 undo/redo 序列，这时候要注意顺序——undo 必须逆序，redo 必须正序，顺序写反了整道题的分就没了。

注意：如果日志里没有检查点，所有已提交事务都要 redo，所有未提交事务都要 undo。检查点的作用是缩小恢复范围，不是改变恢复规则。

5. 避坑与排查：复习和做题时反复踩的五个坑

5.1 把 SQL 的 WHERE 和 HAVING 混用

现象：分组统计题里把聚合条件写在 WHERE 里，比如WHERE AVG(grade) > 75，数据库报错或结果不对。

原因：WHERE 在分组前过滤行，此时聚合函数还没有计算，所以不能出现在 WHERE 里。HAVING 在分组后过滤组，才能用聚合函数。

解决：记住“聚合条件进 HAVING，行条件进 WHERE”。如果题目同时有行条件和聚合条件，比如“查询 2023 年选课且平均成绩大于 75 的课程”，年份条件放 WHERE，平均成绩条件放 HAVING。

5.2 范式判断时漏掉候选码的推导

现象：判断最高范式时直接看函数依赖，没有先找候选码，导致主属性和非主属性判断错误。

原因：部分依赖和传递依赖都是针对非主属性定义的，如果候选码找错了，主属性集合就错了，后面的判断全错。

解决：每道范式题第一步先求候选码。求法是找只在函数依赖左边出现的属性（必在候选码中）、两边都出现的属性（可能在候选码中）、只在右边出现的属性（不在候选码中），然后对可能的属性集求闭包，看能否推出所有属性。

5.3 关系代数除法题用错语义

现象：题目要求“选修了全部课程的学生”，写成了“选修了某门课程的学生”，答案完全不对。

原因：没有识别出“全部”这个全称量词语义，用了存在量词的写法。

解决：看到“全部”“所有”“每一门”就想到除法或双重 NOT EXISTS。看到“有些”“至少一门”才用存在量词。这两种语义在关系代数里对应完全不同的表达式，不能混。

5.4 并发调度判断时把不冲突操作也算进去

现象：画优先图时把读读操作也画了边，导致出现假环，判断为不可串行化。

原因：冲突的定义是“不同事务对同一数据项的操作，至少一个是写”。读读操作不冲突，不同数据项的操作不冲突。

解决：画优先图前先把所有操作按数据项分组，只在同一数据项的不同事务操作之间画边，且至少一个是写操作。不同数据项的操作之间不画边。

5.5 恢复题里 undo 和 redo 的顺序写反

现象：日志恢复题里 undo 序列写成了正序，redo 序列写成了逆序，答案与标准答案相反。

原因：undo 是撤销未提交事务的更新，必须按日志逆序执行反向操作，否则可能撤销顺序不对导致数据不一致。redo 是重做已提交事务的更新，按日志正序执行。

解决：做题时先标出哪些事务需要 undo、哪些需要 redo，然后 undo 从日志末尾往前扫，redo 从日志开头往后扫。写序列时标注方向，避免搞混。

6. 用试题反推知识盲区：一个可复用的自测方法

复习到后期，很多人会陷入“看了都会，一做就错”的状态。我的做法是用试题做盲区定位，而不是刷题量。具体操作是：每做完一套章节试题，把错题按知识点归类，然后回到教材对应章节只读那一节，读完立刻重做错题。如果第二次还错，说明这个知识点不是“没记住”而是“没理解”，需要找一道更基础的题来验证前置概念。

比如范式分解题反复错，往前追可能是候选码求法不熟；候选码求法不熟，再往前追可能是函数依赖闭包的计算不熟。追到最底层那个不熟的点，集中练 5 到 10 道同类题，比泛做 50 道混合题有效得多。

另一个技巧是把试题答案当“推导模板”用。数据库系统概论的答案往往有固定的推导链条，比如范式分解题的答案结构是“求候选码→判断范式→分解→验证无损和依赖保持”。把这个结构背下来，遇到新题直接套结构，只需要替换具体的函数依赖和属性集。这比每次从头想推导路径要快得多，也更不容易漏步骤。

我自己的习惯是考前一周不再看教材，只翻错题本和推导模板。错题本上每道题只记三样东西：题目关键条件、我错在哪、正确推导的第一步是什么。最后那一样最重要——很多题只要第一步走对了，后面就是顺水推舟。数据库系统概论这门课，知识点之间的依赖关系很强，前面的关系代数和 SQL 不熟，后面的并发和恢复题也会受影响。所以复习顺序建议按章节推进，但每章做完题后回头看一眼上一章的核心概念，保持链条不断。

希望帮到你。

本文还有配套的精品资源，点击获取