简介这是一份面向华南师范大学及其他高校学生的《数据库》期末复习知识点汇总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 联系必须单独拆出一张关系表这张表的主键是两端实体的主键组合还可以带上联系本身的属性。我把这个规则整理成一张对照表期末复习就对着这张表练联系类型转换方式关系模式主键典型例子1:1任一方主键作为另一方外键保持不变班级与班长1:NN 方添加一方主键作为外键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非主属性是否完全依赖候选键候选键是复合键某非主属性只依赖其中一部分3NF非主属性是否直接依赖候选键存在“学号→系号→系主任”的传递链BCNF每个函数依赖左边是否包含候选键存在非候选键决定候选键的依赖这里特别要注意的是“部分依赖”和“传递依赖”的区分。部分依赖只发生在候选键是复合键的情况下比如选课表 (学号, 课程号)→成绩如果还有学号→姓名那姓名只依赖学号这一部分这就是部分依赖表就只到 1NF。传递依赖发生在单属性候选键下比如学生表学号→系号系号→系主任那学号→系主任就是传递依赖表最多到 2NF。BCNF 比 3NF 严格得多。3NF 允许“非主属性决定另一个非主属性”比如“系号→系主任”只要系主任不是主属性3NF 就放过但 BCNF 不放过因为它要求每个函数依赖的左边都必须包含候选键系号显然不包含学号直接判定不满足。期末考试经常给一个 3NF 的关系让你指出“它为什么还不是 BCNF”答案就在“系号→系主任”这种依赖上。4.3 分解算法无损连接分解到 BCNF保依赖分解到 3NF范式题的第二大问通常是“将它分解到 BCNF 或 3NF”。BCNF 分解的算法是找到违规的函数依赖 X→YX 不含候选键把关系拆成两张表一张是 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 和 BDD→C 左边 D 不包含候选键继续违规再把 R1 拆成 R1a(C,D) 和 R1b(B,D)R1b 只有一个非主属性 D没有违规依赖了。R2(A,B,C) 里的函数依赖是 A→BA 是候选键满足 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 逐一查漏周五上考场心里基本有底。期末复习最大的敌人不是知识难而是不知道边界在哪里——用这份知识点汇总把边界划清楚再把薄弱点逐个击破比漫无目的地从头抄一遍管用得多。我自己考前一晚也翻过车代价是第二天在考场上临时推导候选键算法手忙脚乱。从那以后我养成了一个习惯任何复习资料拿到手先把目录读三遍再决定从哪一章开始看。希望帮到你。本文还有配套的精品资源点击获取