数据库期末复习指南：ER图转关系模式、SQL查询与范式分解全攻略

简介：这是一份面向华南师范大学及其他高校学生的《数据库》期末复习知识点汇总PDF，适合考前系统梳理数据库核心概念与关系运算。内容涵盖数据库三级模式与两级映像、数据独立性、数据库系统组成，以及DDL/DML/DCL语言的功能界定；在关系部分详细讲解了关系定义、关系性质、关系语言特点，并用实例区分关系模式与关系实例。关系代数与关系演算部分，对选择、投影、连接、更名、差集、并交除运算及聚集函数等均给出定义和查询示例，便于对照理解。资源为单个PDF文件，大小约1.18MB，结构按章节组织，重点公式与结论清晰，可直接用于快速回顾和考前突击。目前已有274人学习下载，尤其适合正在备考数据库期末、需要强化关系代数题型训练的读者。

1. 数据库期末复习，别让知识点汇总变成收藏夹里的 PDF

期末季最容易出现的一个场景：把《华南师范大学-数据库-期末复习知识点汇总.pdf》下载下来，花了半小时看目录，然后从第一页开始抄笔记，抄到 ER 模型就放弃，最后上考场连候选键都不会求。数据库这门课的知识点密度很大，但考来考去就那几个模块：ER 图转关系模式、SQL 增删改查、函数依赖与范式、事务与并发控制。这份 PDF 的价值不在“全”，而在它把教材里分散的内容按考点密度重新排了一遍。我要做的，就是沿着这条线，把每个模块的判定规则、操作步骤和考场陷阱拆开讲清楚，让你拿着这份汇总不是从第一页背起，而是能直接定位到自己的薄弱点。适合正在备战的本科生，也适合想快速把数据库体系重新捡起来的从业者。

2. 从 ER 图到关系模式：先把映射规则练到不用想

2.1 实体与属性：先分清“实体”和“属性”，再看联系

期末试卷里 ER 图题翻车，十有八九不是不会画，而是分不清哪个是实体、哪个是属性。我见过一份答卷把“班级”画成“学生”的属性，后面所有关系模式全部跟着错。实体是现实世界中独立存在、可以区别于其他对象的“东西”，比如学生、课程、教师；属性是实体某方面的特征，比如学号、姓名、成绩。判定的硬标准其实就一条：这个对象还有没有自己的属性？“班级”如果有“班级编号、人数、班主任”，它就是一个实体；如果只是“学生”表里的一个字符串字段，那它就是属性。

这里最容易踩的坑是“多值属性”和“复合属性”。“电话”这种一个属性对应多个值的情况，1NF 不允许，所以要么拆成“电话1、电话2”这种冗余字段（不推荐），要么拆成一张独立的“联系方式”表。“地址”这种复合属性也一样，期末题里如果明确要求转关系模式，复合属性要拆到不能再拆。比如“家庭住址”拆成“省、市、街道”，每个都是独立属性，否则后续写函数依赖的时候会发现 F 集合根本写不干净。

还有一个细节：弱实体。订单和订单项就是典型的弱实体关系，订单项离开了订单就没有存在意义。这类题的年出现率很高，处理方式是订单项的关系模式主键要带上订单号，形成复合主键。很多同学在这里丢分，是因为想当然地给订单项又加了一个自增 id，反而把弱实体语义破坏了。

2.2 联系转关系：1:1、1:N、M:N 的映射模板

ER 图里的联系最终都要变成关系模式，三条规则要刻进脑子里。1:1 联系，可以把任一方的主键放到另一方作为外键，通常选择在访问频率低的那边放外键，减少冗余；1:N 联系，把“一”那边的主键放到“多”那边作为外键；M:N 联系，必须单独拆出一张关系表，这张表的主键是两端实体的主键组合，还可以带上联系本身的属性。

我把这个规则整理成一张对照表，期末复习就对着这张表练：

M:N 这张表是必考中的必考，特别是联系带属性的情况，比如学生选修课程，成绩“成绩”是联系上的属性，不是学生或课程的属性，必须放进联系表里。我曾遇到过一道题，题目给的是“学生-选课-课程”三元联系，处理方式也一样：先把任意两个实体拉出来做成联系表，再把第三个实体的主键补进这个表的主键组合中。三元联系不要想复杂，记住一句话——哪个实体之间是多对多，哪几个主键就要进同一张表。

2.3 五步转换法：从 ER 图到关系模式的完整动作

我一般不会直接凭感觉画关系模式，而是按固定五步走，每一步都验证一遍，能省不少回头改的功夫。

第一步，把每个实体转成一张表，实体属性就是表字段，实体主键就是表主键。第二步，把每个 1:1 联系按规则处理，选一方放外键，并在旁边注明为什么选这一方。第三步，处理所有 1:N 联系，把“一”方主键加到“多”方表里，注意字段名最好带上语义，比如“班级编号”而不是裸的“编号”。第四步，处理 M:N 联系，新建联系表，主键是两端主键组合，如果联系有属性，一并放进联系表。第五步，检查每张表：主键是否唯一且非空，外键是否指到了确实存在的主键上，是否有字段有冗余却没有被函数依赖解释。

举一个最常见的例子：学校有“学生”和“课程”两个实体，学生有学号、姓名、专业；课程有课程号、课程名、学分；一个学生可以选多门课，一门课可以被多个学生选，选课有成绩。按五步法，学生表是 student(stu_id, name, major)，课程表是 course(course_id, course_name, credit)，选课是多对多联系，转成选课表选课(stu_id, course_id, score)，主键是 (stu_id, course_id)。这样转出来一定是 3NF 起步的，不会出现一门课的信息重复存储在学生表里的问题。

这里我特意强调一个考场习惯：转换结果写完以后，顺手做一次“反推”——从每个关系模式里挑一个样本行，看能不能通过主键和外键把 ER 图里的原信息恢复出来。能恢复，说明转换是无损的；不能恢复，说明你漏了联系。这一步大概花两分钟，但能挽回一道 15 分大题。

3. SQL 复习：把增删改查和连接分组练成肌肉记忆

3.1 SELECT 执行顺序：FROM、WHERE、GROUP BY、HAVING 谁先跑

SQL 题的错误答案，一半以上不是语法错，而是逻辑顺序错。很多人写 SQL 的时候凭感觉，尤其是分组查询，一遇到“每个系的学生人数大于 3 的系”就不知道 HAVING 和 WHERE 到底该放哪个条件。

先说结论：SQL 语句的书写顺序是 SELECT、FROM、WHERE、GROUP BY、HAVING、ORDER BY，但执行顺序完全不是这样。数据库先执行 FROM，确定数据源；再执行 WHERE，对每一行做过滤；然后执行 GROUP BY，把过滤后的行分组；接着执行 HAVING，对分组后的组做过滤；之后才轮到 SELECT 投影列；最后 ORDER BY 排序。这个顺序决定了你在 WHERE 里不能写聚合函数，因为聚合发生在分组之后；而 HAVING 里不能写原始字段条件，因为那些条件已经在 WHERE 里被用过了。

-- 正确写法：WHERE 先过滤原始行，HAVING 再过滤分组 SELECT dept_id, COUNT(*) AS stu_cnt FROM student WHERE major <> '历史学' -- 先剔除不用的学生 GROUP BY dept_id HAVING COUNT(*) >= 3 -- 再保留人数不少于3的系 ORDER BY stu_cnt DESC; -- 错误写法：把 HAVING 当 WHERE 用，且 SELECT 了未分组的列 SELECT stu_id, dept_id, COUNT(*) FROM student GROUP BY dept_id; -- stu_id 不在分组里，结果无意义

这段代码里，第一段是标准动作，第二个故意写成错误例子。注意错误例子里 SELECT 出现了 stu_id，但 GROUP BY 只按 dept_id 分组，每组可能包含多个 stu_id，数据库不知道该返回哪一个，严格模式下直接报错，宽松模式返回随机值。期末出题很喜欢考这一点，看到这种题，直接判断“该查询不合法”即可。

WHERE 和 HAVING 的区分再补一刀：WHERE 是“行级过滤”，发生在分组前；HAVING 是“组级过滤”，发生在分组后。如果条件里带 COUNT、SUM、AVG，那只能去 HAVING；如果条件只是普通字段，优先放 WHERE，这样做性能也好，因为先缩小了数据量，分组的代价更低。

3.2 多表连接：内连接、左外连接与自然连接的考场陷阱

连接查询是数据库期末的大头，也是我最看好的送分题，但送分的前提是你分得清连接类型。内连接（INNER JOIN）只返回两表中匹配成功的行；左外连接（LEFT OUTER JOIN）返回左表全部行，右表没有匹配的补 NULL；右外连接反过来。自然连接（NATURAL JOIN）是内连接的一种特殊写法，自动按两表中同名列等值连接，但正因为“自动”，考场里经常翻车——题目里两表如果有两个同名字段，自然连接会把它们都作为连接条件，结果就不是出题人想要的了。

-- 查询选了“数据库原理”课程的学生姓名和成绩 -- 内连接：只保留有选课记录的学生 SELECT s.name, sc.score FROM student s JOIN course c ON c.course_name = '数据库原理' JOIN score sc ON sc.stu_id = s.stu_id AND sc.course_id = c.course_id; -- 左外连接：查所有学生及其选课信息，没有选课记录的学生也保留 SELECT s.name, c.course_name, sc.score FROM student s LEFT JOIN score sc ON sc.stu_id = s.stu_id LEFT JOIN course c ON c.course_id = sc.course_id;

这里要特别提醒参数选取的问题：第一段里我把课程过滤条件写在 ON 后面，实际效果和写在 WHERE 里一样，因为 JOIN 之后还有等值连接条件，最终返回的行是被过滤过的。但第二段左外连接里，如果把过滤条件写成LEFT JOIN course c ON c.course_id = sc.course_id AND c.course_name = '数据库原理'，结果是左表全部行保留，课程名在非匹配行上显示 NULL；如果把它写进 WHERE，那这些 NULL 行会被过滤掉，左外连接就退化成内连接了。这是期末最爱出的选择题，记住口诀：外连接里，ON 决定保留哪些行，WHERE 决定去掉哪些行。

3.3 增删改查与事务：语法骨架和两个必背语句

数据库增删改查是基础中的基础，但期末不直接考背诵，而是喜欢在一个大场景里让你补语句。比如“把学号为 20230001 的学生专业改成软件工程，同时把该学生的所有选课成绩加 5 分，要求要么都成功要么都失败”，这就是事务题。

START TRANSACTION; UPDATE student SET major = '软件工程' WHERE stu_id = '20230001'; UPDATE score SET score = score + 5 WHERE stu_id = '20230001'; COMMIT; -- 如果第二条 UPDATE 影响行数不对，可以用 ROLLBACK 撤销 -- ROLLBACK;

COMMIT 和 ROLLBACK 这两个指令是事务的结尾动作，期末一定会考它们的效果。COMMIT 提交当前事务，所有修改持久化；ROLLBACK 回滚到事务开始前，未提交的修改全部撤销。还有一个自动提交的概念，MySQL 默认每个语句自动提交，如果不显式START TRANSACTION，第一条 UPDATE 执行完就已经生效，后面再想撤销就晚了。复习汇总 PDF 里一般会把事务特性单列一页，但考得更深的是嵌套和保存点，比如SAVEPOINT sp1; ROLLBACK TO sp1;，理解成“只回滚到存档点之后的操作”就行。

视图这一块也常被忽略。视图是虚拟表，不存储数据，查询视图本质是查询背后的 SELECT 语句。期末喜欢问“创建视图后，原表结构变了，视图还能用吗”，答案是用不了，因为视图依赖的表结构和列名都要存在。我记得做过一道题，问能否在视图上执行 INSERT，结论是：如果视图包含聚合、DISTINCT、GROUP BY 或者多表连接，通常不可更新；只有单一基表、且包含所有非空列的子集才可能更新。这个结论背下来，判断直接套。

4. 函数依赖与范式分解：从 1NF 到 BCNF 的判定与分解算法

4.1 函数依赖闭包：候选键判定的唯一硬方法

范式题是数据库期末的“分水岭”，30% 的人在这里拿满，70% 的人靠蒙。蒙的原因很简单：没有掌握闭包这个工具。求候选键必须算属性集闭包，这个不练熟，后面判定 BCNF 全是空中楼阁。

函数依赖的定义是：如果两个元组在属性集 X 上的值相等，那么它们在属性集 Y 上的值也一定相等，就称 X 函数决定 Y，记作 X→Y。闭包就是给定一组函数依赖 F，从一个属性集 X 出发，反复利用 F 里的依赖能推出所有属性的集合，记为 X⁺。

# 计算属性集闭包，用于判定候选键 def closure(attrs, fds): result = set(attrs) changed = True while changed: changed = False for lhs, rhs in fds: if set(lhs).issubset(result) and not set(rhs).issubset(result): result |= set(rhs) changed = True return result # 示例：关系模式 R(A,B,C,D)，函数依赖 F = {A→B, B→C, D→B} fds = [("A", "B"), ("B", "C"), ("D", "B")] print(sorted(closure("A", fds))) # 结果是 ['A','B','C'] print(sorted(closure("AD", fds))) # 结果是 ['A','B','C','D']

这个 Python 脚本的逻辑很简单：先初始化闭包为给定属性集，然后循环扫描所有函数依赖，只要依赖的左边已经被当前闭包覆盖，就把右边加进去，直到闭包不再变化。第一行求 A 的闭包，得到 ABC，说明 A 能推出 B 和 C，但推不出 D；第二行求 AD 的闭包，得到全部四个属性，说明 AD 是一个候选键。

期末求候选键的标准流程是：先把所有只出现在函数依赖右边的属性找出来，这些属性不可能出现在任何候选键里，先排除；再把只出现在左边的属性和不出现任何依赖里的属性找出来，这些属性必须属于每一个候选键，称为“必选属性”。之后从必选属性出发，逐个尝试加上剩余属性，算闭包，能找到全集的极小集合就是候选键。比如上面的例子里，D 只出现在右边，不在候选键里；A 和 B 都在左边，都要考虑。最后得到 AD 是唯一候选键。闭包脚本在考场里没法用，但复习时拿它可以快速验证手工计算结果，省很多时间。

4.2 范式判定流程：每一级看什么

范式的判定有严格的递进关系，1NF 是所有表结构的基础，要求每个属性都是不可分的原子值；2NF 在 1NF 基础上，要求消除非主属性对候选键的部分依赖；3NF 要求消除非主属性对候选键的传递依赖；BCNF 要求每个函数依赖的左边都是超键，也就是“每一个决定性因素都必须包含候选键”。

我复习时把判定流程做成一张决策表，考场上按顺序检查：

这里特别要注意的是“部分依赖”和“传递依赖”的区分。部分依赖只发生在候选键是复合键的情况下，比如选课表 (学号, 课程号)→成绩，如果还有学号→姓名，那姓名只依赖学号这一部分，这就是部分依赖，表就只到 1NF。传递依赖发生在单属性候选键下，比如学生表学号→系号，系号→系主任，那学号→系主任就是传递依赖，表最多到 2NF。

BCNF 比 3NF 严格得多。3NF 允许“非主属性决定另一个非主属性”，比如“系号→系主任”，只要系主任不是主属性，3NF 就放过；但 BCNF 不放过，因为它要求每个函数依赖的左边都必须包含候选键，系号显然不包含学号，直接判定不满足。期末考试经常给一个 3NF 的关系，让你指出“它为什么还不是 BCNF”，答案就在“系号→系主任”这种依赖上。

4.3 分解算法：无损连接分解到 BCNF，保依赖分解到 3NF

范式题的第二大问通常是“将它分解到 BCNF 或 3NF”。BCNF 分解的算法是：找到违规的函数依赖 X→Y（X 不含候选键），把关系拆成两张表，一张是 X∪Y，另一张是原关系减去 Y 加上 X。然后对每一张分出的表继续检查，直到没有违规依赖。

举个例子。关系模式 R(A,B,C,D)，候选键是 A，函数依赖 F = {A→B, BC→D, D→C}。A→B 左边 A 是超键，没问题；BC→D 左边 BC 不含候选键 A，违规，于是把 R 拆成 R1(B,C,D) 和 R2(A,B,C)。R1 里的函数依赖是 BC→D 和 D→C，候选键是 BC 和 BD，D→C 左边 D 不包含候选键，继续违规，再把 R1 拆成 R1a(C,D) 和 R1b(B,D)，R1b 只有一个非主属性 D，没有违规依赖了。R2(A,B,C) 里的函数依赖是 A→B，A 是候选键，满足 BCNF。最终得到 R1a(C,D)、R1b(B,D)、R2(A,B,C) 三个关系，这个分解是无损的，但可能不保持函数依赖。

3NF 分解常用“合成算法”：先求函数依赖集的最小覆盖，再把每个依赖的左边相同的依赖合并，每一组依赖的所有属性构成一张表，最后检查候选键是否出现在某张表中，如果没有，加一张候选键表。合成算法保依赖，但可能不是无损的。期末判卷时，分解题最常扣分的地方就是“结果表的主键没标对”和“分解后函数依赖不全”。主键错了，整个分解的合法性就没了。所以每一张表分解出来，第一步就是写清楚主键是什么，再谈其他。

5. 数据库复习避坑：范式、SQL 与事务的 5 个高频翻车点

5.1 现象：主键选错导致插入异常

复习时做课本习题，经常遇到一张“选课表”里主键写成“选课 id”，结果同一个学生选了同一门课两条记录都能插入，数据乱成一团。原因是对 M:N 联系表的主键语义不敏感，选了代理主键却忘了加唯一约束。解决方法是明确 M:N 联系表的主键必须是两端实体主键的组合，如 (学号, 课程号)；如果业务要求同一个人同一门课只能选一次，这个组合主键天然满足。代理 id 不是不能用，但要额外加 UNIQUE(学号, 课程号)，考场则没必要，直接组合主键最稳。

5.2 现象：GROUP BY 后 SELECT 了未聚合列

很多同学手写 SQL 题时，习惯把 SELECT 后面的列写全，写上想查的就完事，结果分组查询里混入了未分组的列。比如按系分组统计人数，却把学号放进了 SELECT。原因是没有把“分组后每一组只能返回一行”这个约束当回事。解决的办法是自检三句话：这个列在分组里吗？不在分组里那它被聚合了吗？既不在分组里也没被聚合，就是错的。用 MySQL 的 ONLY_FULL_GROUP_BY 模式去跑练习，它会在这种错误上直接报错，比手写自查更强制。

5.3 现象：隔离级别和锁混为一谈

事务这一章翻车的常见原因是把“可重复读”理解成“锁住所有读数据”。可重复读是隔离级别，锁是实现隔离的手段之一，但快照读并不加锁。MySQL 默认的可重复读下，普通 SELECT 走的是快照读，不会阻塞别的事务插入新数据；而 SELECT ... FOR UPDATE 加的是当前读锁，会阻塞写操作。期末选择题里喜欢把这两种行为混在一起，让你判断某个事务在另一事务提交前看到什么。解决方式是做题时先问一句：这个 SELECT 是快照读还是当前读？如果是快照读，答案基本是“读的是事务开始时的快照”，跟其他事务是否提交无关。

5.4 现象：死锁排查只盯日志不看事务申请顺序

期末不考排查日志，但考死锁的概念和条件。很多人把死锁理解成“两个事务同时锁了同一行”，这是错的。死锁需要四个条件同时满足：互斥、持有并等待、不可剥夺、循环等待。平时练习 MySQL 遇到死锁错误（比如 ERROR 1213），光看日志里哪条语句死锁是不够的，要看两个事务各自持有哪把锁、申请哪把锁，顺序是不是构成了环。我一个血泪经验是：死锁的解决办法不一定是加锁，而是减小锁范围、固定事务访问表的顺序，或者把大事务拆小。考试答题时写“死锁是双方互相持有对方需要的资源并等待”，再补一个例子，就能拿全。

5.5 现象：SQL 查询结果和关系代数结果对不上

关系代数表达式写对了，但转成 SQL 后结果多出几行，这个翻车点最隐蔽。常见原因是把自然连接直接换成 JOIN，却忘了自然连接会按所有同名列等值连接。比如选课表和课程表都有“课程号”和“学分”两个同名字段，自然连接会同时要求课程号相等且学分相等，SQL 里如果只写 ON 选课课程号 = 课程课程号，结果就会多出“课程号相同但学分不同”的行。解决方式是：看到题目明确写“自然连接”，先列出两表同名字段，再写等值条件；如果题目只写连接没写自然连接，老老实实用指定的连接条件，别自作聪明。

6. 把知识点汇总变成自己的复习地图：三遍压缩法与五个自测题

6.1 三遍压缩法：把 PDF 从一百页压到一页

拿到复习汇总 PDF，我习惯做三遍压缩。第一遍快速翻完，用铅笔在页边标出“认识”和“陌生”两类知识点，认识的只过标题，陌生的重点看。第二遍针对陌生点，把每章的核心结论抄到一张 A4 纸上，不抄解释，只抄判定规则和公式。比如范式那张纸只留“2NF：消除部分依赖；3NF：消除传递依赖；BCNF：左部超键”这一行。第三遍就是考前两小时，只看这张 A4 纸，看完能默写出来就过关，默写不出来的地方再翻回 PDF 对应的页。这个方法治“背诵时觉得自己会，做题时大脑空白”的毛病，因为它强迫你输出而不是输入。

6.2 五个必考自测题与答案要点

自测不用做整套卷子，五道题就够了。第一题：给出一个含有部分依赖和传递依赖的关系模式，求候选键并分解到 3NF。这题覆盖第 4 章全部核心。第二题：写一条多表连接查询，要求包含 WHERE、GROUP BY、HAVING 三层结构，比如“查询平均成绩大于 85 的系及其人数”。第三题：画一个学生选课的 ER 图，再写出对应关系模式，重点检查 M:N 联系表是否正确。第四题：给定两个事务的读写序列，判断是否会发生冲突，说明隔离级别的影响。第五题：解释 BCNF 和 3NF 的区别并举一个“3NF 但不是 BCNF”的实例。

这五题做完，基本可以覆盖期末 80% 的大题考点。我那学期就是这么干的：周一到周三每天只做一题，周四把五题答案对着 PDF 逐一查漏，周五上考场心里基本有底。期末复习最大的敌人不是知识难，而是不知道边界在哪里——用这份知识点汇总把边界划清楚，再把薄弱点逐个击破，比漫无目的地从头抄一遍管用得多。我自己考前一晚也翻过车，代价是第二天在考场上临时推导候选键算法，手忙脚乱。从那以后我养成了一个习惯：任何复习资料拿到手，先把目录读三遍，再决定从哪一章开始看。希望帮到你。

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