简介江西理工大学《数据库原理》期末考试复习题及答案.doc是一份面向该校计算机类学生的期末备考资料内容围绕期末考点与常见题型整理可帮助学生在考前快速建立知识框架并进行针对性训练。资源共包含1个doc文档资源包大小1006KB体积小巧但覆盖全面便于下载后直接阅读或打印。文档以题目和答案相互对照的形式编排涉及数据库基础概念、关系数据库与数据库模式设计、ER模型及其应用、SQL数据查询与更新操作、范式理论与规范化、索引机制、事务的ACID特性、并发控制、备份与恢复、数据库安全及性能优化等核心知识点并给出相应参考答案便于读者对照教材逐项检验掌握程度理解解题思路。目前已有268人学习下载适合需要系统复习、巩固基础概念和提升解题能力的备考学生使用。1. 江西理工数据库原理期末考试复习题及答案为什么值得把一份.doc当项目做江西理工数据库原理期末考试复习题及答案这份在考前传了一届又一届的.doc真实价值往往被人用错把它当“背答案的捷径”你会被换了个数字的同款题直接打回原形把它当“考纲路标”却能省下至少三分之一的无用功。它要解决的其实不是“押中原题”而是“知道考什么、怎么考、按什么顺序复习”。适合两类人——还剩两三周想突击的选手和学完一遍却不知道漏洞在哪的在读学生。拿到它的第一步我建议不是翻答案而是先做一次诊断性自测把盲区暴露出来再动手。2. 题型结构与高频考点先看分再刷题别被“全部都要背”吓住2.1 从复习题里拆出五个板块先建自己的考频表绝大多数数据库原理期末卷的布局是固定的复习题里的题目再多也逃不出五个板块关系模型与完整性、关系代数与SQL、ER图与关系模式转换、范式与函数依赖、事务与并发控制。我拿到复习题的第一件事不是从头做而是把每道题按板块归类统计每个板块的题量占比。题量最大的板块通常就是分值最重的板块复习顺序也应该按这个权重倒着排。板块典型考法常见分值占比复习优先级关系模型与完整性选择、填空、判断15%-20%低理解概念即可关系代数与SQL大题手写查询25%-35%高必须闭卷练熟ER图与关系模式转换设计题15%-25%高套路固定范式与函数依赖判断范式级别、分解10%-20%中手算流程要熟事务与并发控制简答、填空10%-15%中乐观锁悲观锁场景必考这个表不是死规矩不同学校出题风格会有偏移但“SQL和关系代数占比最高”这件事在绝大多数考卷里是成立的。你拿到复习题后先自己重新统计一次把题号标在每个板块后面统计完再决定先刷哪个部分。我自己的经验是如果关系代数与SQL板块的题目量超过三分之一那这一块值得花掉后面一半的复习时间。有个很实用的细节选择题和判断题里的错误选项往往比正确选项更有价值。对答案时不要只看对错把每个错误选项为什么错写出来一条条对应到教材里的概念描述。比如“视图是实际存储的数据”这个说法是错的错误点在于视图只是虚拟表不实际存储数据。这种辨析题靠背答案完全无效但你只要把每个选项背后的原理过一遍同类的填空题和简答题也顺便解决了。2.2 用一次诊断性自测代替“背答案式刷题”背答案式刷题的最大问题是你会误以为自己会了。合上答案再做一遍发现题目里换了个数值、改了个表名立刻卡住。所以我拿到复习题的第一轮做法是诊断不是学习。步骤很简单三条固定时间90分钟闭卷作答只看题面不翻书不翻答案做不出的题标“盲区”做完后按板块归类错题统计每个板块的错误率错误率超过40%的板块属于“概念崩坏区”先回去重读教材再做复习题错误率在20%-40%之间属于“练习区”靠重复刷同类题就能补低于20%属于“稳定区”考前过一遍错题即可。这个阈值是我按带过的复习节奏定的你可以根据自己的基础调整但核心逻辑不变先诊断再用药。我见过太多人拿到复习题第二天就开始背答案背到第三天发现还有三分之一的题没见过心态先崩了。诊断自测的作用就是让你在第一天就知道那三分之一在哪后面两天集中打靶比漫无目的地从头背到尾高效得多。做完诊断后把错题按板块整理成一张清单每道题后面写一句“卡在哪”。比如“不会判断传递依赖”“LEFT JOIN和INNER JOIN用混了”“不知道乐观锁悲观锁的区别”。这张清单就是你后面几天的复习索引比复习题本身更值钱。3. 关系代数与SQL大题把题面翻译成可执行查询的落地写法3.1 考场上先写关系代数还是先写SQL复习题里的查询大题通常只有两种问法一种是直接要求“写出关系代数表达式”另一种是“用SQL实现下列查询”。很多人的习惯是直接上手写SQL这在一张满分100分的卷子里其实是吃亏的。关系代数题是按步骤给采分点的——投影对了给一分、选择条件对了给一分、连接关系对了再给一分而SQL题往往全对才给全分错一个条件整道题白写。所以我给的建议是先用关系代数把查询逻辑拆开再把关系代数逐句翻译成SQL。关系代数里就五个核心操作选择σ、投影π、连接⋈、并∪、差外加一个除法÷。它们和SQL的对应关系非常直接σ对应WHEREπ对应SELECT⋈对应JOIN∪对应UNION差对应EXCEPT或NOT IN。你把关系代数写出来SQL基本就是机械翻译不容易漏条件阅卷时还能让老师看到你的思路。以复习题里最常见的一道题为例“查询选修了全部课程的学生学号与姓名”。这道题考了无数次核心是除法运算。关系代数写法是π_sno,sname( student ⋈ ( π_sno( sc ) ÷ π_cno( course ) ) )先用sc表投影出学号再用course表投影出全部课程号做除法得到“选了全部课程”的学号最后和学生表连接取姓名。如果这道题直接写SQL很多新手会想用COUNT比较但SQL里没有直接除法最标准的做法是双重NOT EXISTS下面细说。3.2 SQL四类必考边界EXISTS、NOT EXISTS、NULL与聚合先看“选修了全部课程的学生”的标准SQL写法-- 查询选修了全部课程的学生姓名和学号 SELECT s.sid, s.sname FROM student s WHERE NOT EXISTS ( -- 不存在这样一门课 SELECT 1 FROM course c WHERE NOT EXISTS ( -- 该学生没选它 SELECT 1 FROM sc WHERE sc.sid s.sid AND sc.cid c.cid ) );这段SQL的注释里已经把两层NOT EXISTS的逻辑写清楚了。外层“不存在一门课”内层是“该学生没选这门课”两个否定叠加就是“所有课都选了”。这个写法的好处是即使某门课没有学生选或者某个学生没有成绩记录它依然能正确返回结果不会因为空值翻车。同一类题的另一个常见变体是“查询一门课都没选的学生”很多人的第一反应是用NOT INSELECT sid, sname FROM student WHERE sid NOT IN ( SELECT DISTINCT sid FROM sc );这个写法在课本示例里是对的但工程里和考卷里都可能踩坑只要查询结果里出现一个NULLNOT IN的整个结果就变成空集。比如sc表里有学生选了课但成绩字段为空或者子查询里sid本身包含NULL一定条件下会直接让你这道题白做。所以我遇到“不在集合里”这类查询时默认优先写NOT EXISTS它不会因为子查询里的NULL而改变语义。这也算一个可以写进复习笔记的结论考试写SQL优先NOT EXISTS少用NOT IN。再给一个必考的分组聚合模板复习题里“求每门课平均分并按高低排序”是常客-- 每门课的平均分、选课人数只保留选课人数大于等于5人的课程 SELECT c.cname, AVG(sc.score) AS avg_score, COUNT(sc.sid) AS student_cnt FROM course c JOIN sc ON sc.cid c.cid GROUP BY c.cname HAVING COUNT(sc.sid) 5 ORDER BY avg_score DESC;这里有两个高频扣分点。第一GROUP BY后面只能放分组字段SELECT里非聚合列必须是分组键否则在开启ONLY_FULL_GROUP_BY的数据库里直接报错很多考试机上的MySQL默认就开这个模式。第二HAVING和WHERE的分工WHERE在分组前筛行HAVING在分组后筛组。想筛选“选课人数大于5”只能用HAVING因为COUNT是分组后才算出来的。我见过太多人把HAVING写成WHERE或者把分组前的条件硬塞进HAVING这两种错在复习题的答案解析里也很常见自己要留个心眼。还有一个容易漏的点COUNT(sid)和COUNT()在带JOIN的查询里结果可能不同。如果sc表里同一学生同一课程有多条记录COUNT()会把重复记录也算进去。考点就是“统计选课人数要去重”应该写COUNT(DISTINCT sc.sid)。这一点在复习题的选择题里经常以“以下哪个聚合函数写法正确”的形式出现你平时做SQL题时顺手养成写DISTINCT的习惯考试就不用临时想。4. 范式与ER图用手算流程拆开应用题的每个采分点4.1 范式判断的手算流程闭包先行再谈级别范式题在复习题里占据固定位置而且是最容易“感觉会了但一算就错”的部分。原因很简单函数依赖一多传递依赖藏得很深肉眼根本看不出来。我见过太多人拿到一个关系模式扫一眼就说“这是3NF”结果漏了一条传递依赖实际只是2NF。为了避免这种翻车我给自己定了一个固定手算流程四步走列出关系R的全部属性集合和全部函数依赖F对每个可能的属性组合求闭包找出所有候选键检查是否存在非主属性对候选键的部分依赖检查是否存在非主属性对候选键的传递依赖。判定规则也很直接存在部分依赖最多是1NF消除了部分依赖达到2NF消除了非主属性对码的传递依赖达到3NF每个决定因素函数依赖左边都是超键才是BCNF。这里面最容易漏的是第4步很多人判断到3NF就停了没检查“决定因素是否为超键”这一条。闭包是整套流程的计算基础。逻辑很简单给定一个属性集合X不断把函数依赖左边能由X推出的右边属性加进来直到集合不再变大。这个计算完全可以靠一段小脚本辅助验证def attr_closure(all_attrs, fds, attr_set): # all_attrs: 关系R的全属性集合例如 {A,B,C,D} # fds: 函数依赖列表每一项是 (前件集合, 后件集合) # attr_set: 想要求闭包的属性集合 result set(attr_set) changed True while changed: changed False for lhs, rhs in fds: if lhs.issubset(result) and not rhs.issubset(result): result.update(rhs) changed True return result # 例R(A,B,C,D)F {A-B, B-C, C-D} all_attrs {A, B, C, D} fds [({A}, {B}), ({B}, {C}), ({C}, {D})] # 求A的闭包结果应等于全部属性说明A是候选键 print(attr_closure(all_attrs, fds, {A}))脚本本身很简单但它能帮你快速验证“某属性组合是不是超键”——只要闭包等于全属性集合就是超键如果去掉某个属性后闭包仍然等于全集那这个属性就是冗余的继续去掉直到不能再拆剩下的就是候选键。比如R(A,B,C,D)里如果AB是候选键你要验证A本身成不成立再验证B本身成不成立两个都不是超键才能确认AB是候选键而不是A或B单方面能决定的。我自己复习时有个习惯先用脚本跑闭包再动手在草稿纸上把闭包过程完整写一遍。脚本负责确认“答案对不对”手写负责“考试时能复现过程”。因为考场上没有脚本可用你必须练到闭包四步能闭卷默写出来这道题才算真正拿下。4.2 ER图转关系模式一张映射表记住大部分采分点ER图题在复习题里通常有两种考法给你一段需求描述让你画ER图或者给你ER图让你转成关系模式。后者套路非常固定核心就是记住实体和联系的映射规则多数采分点都在这里。元素关系模式写法参数说明普通实体实体名(属性1, 属性2, …)主码直接写在实体属性里下划线标出1:1联系任选一端实体加入另一端主码作为外键外键加在查询频率高的那一端1:N联系N端实体加入1端主码作为外键外键始终加在“多”的那一端M:N联系独立关系表联系名(端1主码, 端2主码, 联系属性)主码是两端主码的组合联系属性写在表里多值属性独立关系表属性表(实体主码, 属性值)一个实体有多条记录外键对回实体主码这张表背下来能解决大部分ER转换题。我重点提醒两个高频翻车点。第一个是M:N联系。假设“学生选修课程”是M:N联系成绩应该存放在独立的选课关系表里写成sc(sid, cid, score)主码是(sid, cid)组合。有人偷懒把成绩放进学生表或者课程表语义就错了——成绩既不属于学生也不属于课程它属于“选课”这个行为。复习题里的设计题很喜欢在这埋陷阱判断标准就一句话联系有属性M:N必须拆独立表。第二个是多值属性。比如“一个员工有多个电话号码”如果把phone直接写在员工表里要么出现冗余要么违反1NF。正确做法是把电话号码拆成独立表员工主码作外键对回去。答题时只要看到“多个”“若干”这类词就要条件反射想到拆表。这个点在填空和判断里也常出现答法一致多值属性必须单独建表不能堆在主表里。关系模式转换做完后还有一个加分项检查每个关系模式的主码是否能唯一标识记录。比如M:N联系拆出的表主码组合中任何一个字段为空整条记录就没有意义所以两端主码都要标NOT NULL并作为联合主码。写在卷子上会让阅卷老师一眼看出你理解到位了比只写“sc(sid, cid, score)”更稳。5. 刷这套复习题最容易翻车的5个坑从文档乱码到并发控制5.1 背完答案题目一换数据就崩现象头天晚上背熟了“查询选修了全部课程的学生”的SQL第二天卷子上变成“查询选修了全部课程的女生”直接卡住只会照抄原题。原因背的是具体表名和答案没有抽象出“双重NOT EXISTS”这个解题模式。解决把复习题里的表名、字段名、数值全部换成字母或者别的名字重新推一遍。换名不换结构做三遍以上才算真正掌握这道题背后的套路。应对策略很简单每道SQL题做完自己在旁边写一句“这类题的通用解法”比如“全部/所有类型的查询优先想双重NOT EXISTS”。5.2 .doc打开乱码公式和下标全丢了现象从群里下载的.doc复习题用旧版Word打开函数依赖箭头变成问号SQL括号显示异常部分题目直接缺字。原因老式.doc兼容性差公式符号在不同的编辑器里渲染规则不一致。解决先用WPS或新版Word把.doc另存为.docx再转一份PDF备用如果文档里的函数依赖实在看不清不要硬猜直接回到教材对应章节找标准符号。这份复习题的正确用法是当索引题目看不清就靠它的题面去定位教材知识点而不是执着于复原那一行公式。5.3 SQL“先查后改”造成死锁乐观锁悲观锁选型错了现象复习题里有一道事务题让你设计一个“扣减库存”的并发流程。按直觉先SELECT库存再UPDATE扣减两个事务同时执行时互相等待甚至覆盖更新。原因没有区分乐观锁和悲观锁的适用场景。解决读多写少、冲突概率低的场景用乐观锁在表里加版本号字段每次更新时检查版本号是否一致用CAS方式更新写冲突频繁、业务上不允许重试的场景用悲观锁直接SELECT ... FOR UPDATE把行锁住更新完再释放。考试简答不会让你写完整代码但会考“乐观锁、悲观锁的实现原理和适用场景”你至少要把版本号机制和FOR UPDATE两个关键词答出来并说清楚各自适合的并发强度。5.4 判断范式漏了传递依赖把3NF误判成BCNF现象R(A,B,C,D)F{A-B, B-C, C-D}扫一眼觉得A能决定一切直接写BCNF结果答案是3NF。原因漏判了A-D这条传递依赖A通过B和C才决定DA本身不是每个函数依赖左边的超键。解决判断BCNF不能只看主属性要看每个函数依赖的左边是否都是超键。做法就是把F里的每个决定因素都拿去做闭包运算闭包结果必须等于全属性集合否则直接排除BCNF。闭包脚本在4.1节已经给了题目做错时把每个依赖左边带入跑一遍错误原因立刻暴露。5.5 第一遍就死磕难题基础题还没热身先崩了现象从复习题最后一道设计题开始刷被一道ER图难住后心态爆炸前面最基础的选择题反而没时间看。原因违背了“先易后难、先诊断后补漏”的复习节律。解决按“选择填空判断 → SQL → 关系代数 → ER图 → 范式 → 事务”的顺序过两遍。第一遍快速过每道题不超过5分钟不会就标记跳过第二遍只刷标记过的错题。这个顺序能保证你先把基础分拿稳再集中火力攻大题。6. 把复习题改造成可检索的错题库Anki自测与掌握度验证6.1 用Python把题目转成CSV喂给抽认卡工具复习题的原始形态是一份线性文档按顺序往下看很低效因为同一知识点的题目可能散落在不同位置。我会把错题库里每道题拆成一张卡片字段包括主题、题干、答案、错因。用一段小脚本导出CSV再导入Anki或任何抽认卡工具按主题分组随机抽测。import csv questions [ {topic: sql_not_exists, question: 查询选修了全部课程的学生, answer: 双重NOT EXISTS, why_wrong: 没想清楚外层语义}, {topic: paradigm_bcnf, question: R(A,B,C,D), F{A-B,B-C,C-D} 最高范式, answer: 3NF, why_wrong: 漏了传递依赖}, {topic: lock, question: 乐观锁与悲观锁适用场景, answer: 读多写少用乐观锁写冲突多用悲观锁, why_wrong: 不会区分场景}, ] with open(db_principle_cards.csv, w, newline, encodingutf-8-sig) as f: writer csv.DictWriter(f, fieldnames[topic, question, answer, why_wrong]) writer.writeheader() writer.writerows(questions)这里的关键字段是why_wrong它比答案本身更重要。复习到第二轮时我只随机抽topic列里的主题名不显示题干逼自己回忆这道题出现过什么坑、正确解法是什么。如果看到主题名只能想起答案、想不起当初为什么错说明这个坑还没真正填平。6.2 一张掌握度验证表考前最后一晚只看它抽认卡工具负责日常复习考前最后一晚则要换个策略随机抽10道错题限时30分钟闭卷重做按主题统计正确率。正确率高于80%的主题考前不再碰低于60%的主题回到教材重新过概念中间段只重复做错题。这个验证表我用过很多轮比“从头到尾翻一遍复习题”节省至少两个小时。它逼你把注意力钉在真正没掌握的主题上而不是反复确认自己已经会了的内容。我现在的习惯是每次复习数据库原理第一件事不是翻开复习题从头看而是先跑一遍错题卡把上次翻车的题目重新做一次。这个习惯帮我避开了很多重复踩坑的弯路。希望帮到你。本文还有配套的精品资源点击获取