简介面向数据库课程学习者、备考考生以及需要快速回顾数据库核心概念的自学者这份《数据库系统概论》各章复习试题及答案PDF以章节为单位覆盖数据管理技术发展、数据模型、数据库体系结构、三级模式与两级映射、完整性与安全性、并发控制及数据库恢复等关键主题内容系统且重点突出。资源包仅包含1个PDF文件整体大小约1.08MB轻量便捷可直接打印或导入手机、平板阅读。目前已有360人学习下载适合期末复习、考研备战或自学自测。文中收录了多套选择题、填空题和简答题均配有参考答案通过题型训练帮助巩固对数据库系统概论的理解内容还涉及数据库设计流程、数据操纵语言DML与数据定义语言DDL等实践知识针对易混淆概念如数据独立性、三级模式、DBMS功能等做了专门练习可有效检验学习效果并查漏补缺。1. 数据库系统概论复习试题直接看题和直接看书的差距在哪数据库系统概论这门课的内容放到互联网行业里看其实非常务实数据管理技术的演进、数据库体系结构、关系模型、SQL 操作、安全与完整性控制、范式理论几乎是每一家公司在数据库岗位笔试里都会考的东西。很多人复习时喜欢先翻教材把每一章的正文读一遍再做题问题在于教材的编排顺序和考试出题顺序并不一致读完一遍回头做题照样抓不住重点。这套按章划分的复习题把每个章节的选择题、填空题、简答题和综合应用都拆了出来从数据独立性到 ER 图转换、从 SQL 书写到 3NF 分解正好用来反向验证你对知识点的掌握程度。无论你是期末备考、准备入职笔试还是想把自己零散的知识点串一遍这份资料都能直接当自测题库用。2. 三级模式两级映射理解数据独立性的四道门槛2.1 三阶段演进为什么数据库系统阶段独立性最高在第一章的考查里高频概念集中在数据管理技术的发展过程人工管理阶段、文件系统阶段、数据库系统阶段。选择题问“数据独立性最高的是哪个阶段”正确答案是数据库系统。很多人会把“文件系统”和“数据库系统”搞混原因是文件系统阶段确实已经做到了按名字存取但它仍然存在明显的数据冗余、数据不一致和应用程序与数据文件强绑定问题。数据库系统阶段引入了数据库管理系统DBMS由它统一管理数据的存储结构和访问路径使得应用程序不再直接面对磁盘上的物理文件数据独立性这才真正建立起来。数据库的特点也是第一章选择题反复出现的考点数据可以共享或数据结构化、数据独立性、数据冗余小易扩充、统一管理和控制。注意这里强调的是“冗余小”而不是“没有冗余”教材从不说数据库消除了一切冗余只是把冗余控制在可控范围。数据不一致的根本原因是数据冗余这道题在第 1 章的第 12 题出现过它其实是在引导你把两个概念联系起来冗余是原因不一致是结果。对比文件系统阶段数据库通过共享机制让同一份数据被多个应用复用从根本上减少重复存储不一致的问题也就随之减少。再看“数据库、数据库系统、数据库管理系统三者关系”数据库系统DBS包括数据库DB和数据库管理系统DBMSDBMS 是数据库系统的核心和基础数据库是存储在计算机内有结构的数据集合DBMS 是位于用户与操作系统之间的一层系统软件。数据库系统的最大特点是数据的三级抽象和二级独立性DBMS 的主要功能有数据定义、数据操纵、数据库的运行管理和数据库的建立维护四个方面。只要把“数据定义、数据操纵”和 DDL、DML 对应上这道题就变成了一道送分题。2.2 三级模式两级映射逻辑独立性与物理独立性的一次说清数据库体系结构按模式、外模式、内模式三级组织这是第一章填空题的基本内容。三者的关系可以用一张表直接理清层次别名作用面向对象外模式用户模式用户看到的那部分数据的局部逻辑结构应用程序、最终用户模式概念模式数据库中全体数据的全局逻辑结构DBA、数据库设计者内模式存储模式数据的物理存储结构与存取方式存储设备、DBMS两级映射分别对应两种独立性。外模式/模式映射负责逻辑数据独立性模式/内模式映射负责物理数据独立性。也就是说全局逻辑结构改了只要不修改外模式应用程序不用跟着变存储结构改了只要模式不变应用程序也不用变。这两句话就是数据独立性最核心的解释简答题和填空题都会换着方式考建议直接记牢。题库里有一道经典题将数据库的结构划分成多个层次是为了提高数据库的①和②答案是数据独立性和物理独立性。这里有个容易踩的坑逻辑独立性是“模式变了而外模式不变”物理独立性是“内模式变了而模式不变”两者关注的层面完全不同做题时不要看到“独立性”三个字就直接选 A。另外描述数据库中全体数据全局逻辑结构和特征的是“模式”外模式是局部逻辑结构内模式是存储结构这三个词一定要能一字不差地对应上。练习题里还有“数据字典”的简答题答案由数据项、数据结构、数据流、数据存储和处理过程五部分组成。数据字典在数据库设计中是数据流图的配套产物复习时可以和“需求分析”阶段关联记忆。数据模型由数据结构、数据操作和完整性约束三部分组成数据结构描述静态特性数据操作描述动态特性这两个填空题答案也是高频考点。2.3 从 E-R 图到关系表把实体联系翻译成主码外码第一章补充作业放了两道 E-R 图题这其实是概念设计到逻辑设计的经典练习也常在大题里出现。第一题是教学管理规定学生选修课程并取得成绩教师讲授课程。三个实体是学生、课程、教师。学生和课程是 m:n 联系并带有成绩属性教师和课程是 1:n 联系。转换后的关系模式有三个表学生学号、姓名、课程课程号、课程名、选修学号、课程号、成绩。注意“成绩”不能单独建表它是选修联系上的属性所以合并进选修关系模式。第二题是某企业集团的生产管理系统涉及工厂、产品、职工三个实体。工厂和产品是 m:n 联系附带计划数量属性工厂和职工是 1:n 联系附带聘期和工资属性。转换后的关系模式为关系模式主码外码工厂工厂编号厂名地址工厂编号无产品产品编号产品名规格产品编号无职工职工号姓名工厂编号聘期工资职工号工厂编号生产工厂编号产品编号计划数量工厂编号产品编号工厂编号、产品编号注意生产表的主码由两个属性联合构成外码同时引用了工厂和产品两表的主码这是 m:n 联系的典型转换方式。1:n 联系则把“1”方的主码放到“n”方关系里职工表里的工厂编号就是这样来的。做题时先画 E-R 图、标出联系类型再决定“属性并入哪张表、主码外码怎么放”转换题基本不会错。3. 关系代数与 SQL 语句先懂五种基本运算再写查询3.1 五种基本运算与专门关系运算的辨析第二章的选择题一直在关系代数里打转。关系代数中五种基本运算是并、差、笛卡尔积、投影、选择专门的关系运算有选择、投影、连接。注意“连接”不在基本运算里因为连接可以由笛卡尔积加上选择运算组合得到属于导出运算。三个容易混淆的名字需要分开记并是横向合并关系差是去掉共有元组笛卡尔积是两两拼接元组。题目问“五种基本运算”时选项里出现自然连接或交通常都是干扰项直接排除。自然连接要求 R 和 S 含有一个或多个共有的属性连接运算以相同属性值为条件拼接元组。考试里问“花费时间可能最长的运算”时答案通常落在笛卡尔积上因为它对左边关系的每个元组都要和右边关系的每个元组做组合结果规模是两表元组数的乘积复杂度最高。除运算也常被问但它不在五种基本运算之列复习时把它归入专门关系运算即可。关系模型里“关键字候选码”的定义是能唯一标识任一元组的一个或多个属性组合。一个关系模式的候选码可以有多个主码只能从候选码里挑一个。第二章填空里有“系和学生”两个关系系表主码是系编号、无外码学生表主码是学号、外码是系编号这组例子把主码、外码、候选码三个概念串在了一起也是后面 E-R 图转换题的基础。关系模式的属性要求不可再分这是第一范式的雏形选择题里说“关系模式的任何属性不可再分”就是在考这个点。3.2 六个必会写的 SQL 查询从连接查询到双重否定SQL 是关系数据库标准语言属于非过程化语言有两种使用方式交互式 SQL 和嵌入式 SQL。第三章的选择题基本在考这些描述真正拉开差距的是书面作业的六道题。这六道题覆盖了连接查询、BETWEEN 范围、GROUP BY 分组、HAVING 筛选、NOT EXISTS 双重否定值得逐题上手跑一遍也是这套资料里最值得实机验证的一部分。第一题检索选修课程名称为 MATHS 的学生的学号与姓名。学生表 S、选课表 SC、课程表 C 三张表都要参与先通过 S# 和 C# 做等值连接再用 CNAME 过滤SELECT S.S#, S.SNAME FROM S, SC, C WHERE S.S# SC.S# AND C.C# SC.C# AND C.CNAME MATHS;这段 SQL 的逻辑是先把三张表做笛卡尔积再用 WHERE 里的等值条件筛出有效组合。FROM 里同时出现三张表并用 WHERE 写连接条件是关系数据库初学阶段最常见的写法比 JOIN 写法直观。实际工作中我习惯换成 JOIN 语法效果一样但思路更清晰。第二题检索至少学习了课程号为 C1 和 C2 的学生学号。最简单的解法是用 IN 和两次子查询SELECT S# FROM SC WHERE C# C1 AND S# IN (SELECT S# FROM SC WHERE C# C2);外层查出选了 C1 的学生内层查出选了 C2 的学生IN 取交集结果就是两门课都选的人。另一种更通用的写法是用 NOT EXISTS 做双重否定它也是第五题的基础可以先放一放把 IN 版本先掌握。第三题检索年龄在 18 到 20 之间含 18 和 20的女生的学号、姓名和年龄。SELECT S#, SNAME, AGE FROM S WHERE AGE BETWEEN 18 AND 20 AND SEX 女;BETWEEN AND 是闭区间包含边界值。我见过不少同事在类似场景里写成 AGE 18 AND AGE 20范围差一点就可能把边界上的数据漏掉这类题丢分很不值。想验证的时候把 18、20 换成日期型的出生年月也要留意闭区间边界。第四题检索平均成绩超过 80 分的学生学号和平均成绩。SELECT S#, AVG(GRADE) AS 平均成绩 FROM SC GROUP BY S# HAVING AVG(GRADE) 80;GROUP BY 按学号分组后AVG 作用于每个组HAVING 是分组后的筛选条件。注意 WHERE 不能直接跟聚合函数平均成绩超过 80 这个条件放在 HAVING 而不是 WHERE这是常错点。如果写成 WHERE AVG(GRADE) 80数据库会直接报错因为 WHERE 在分组之前执行此时聚合结果还不存在。第五题检索选修了全部课程的学生姓名。这道题用的是课程表的反向覆盖思路比第二题更进一步是整份资料里难度天花板SELECT SNAME FROM S WHERE NOT EXISTS (SELECT * FROM C WHERE NOT EXISTS (SELECT * FROM SC WHERE SC.S# S.S# AND SC.C# C.C#));逐层解读内层的 SC 子查询查“这个学生是否学了这门课”中层的条件为“是否存在一门课该学生没学”。如果某学生名下所有课程都被学了中层就会返回空集外层的 NOT EXISTS 成立这个学生入选。这个双重否定结构是考场上最容易写错的三段式建议抄下来背住然后自己在本地数据库里改几个条件跑一遍运行结果会远比干看答案记得牢。关联条件 SC.S# S.S# 和 SC.C# C.C# 一个都不能少漏一个查询结果就变成全表或空集。第六题检索选修了三门课以上的学生的姓名。SELECT SNAME FROM S, SC WHERE S.S# SC.S# GROUP BY SNAME HAVING COUNT(*) 3;GROUP BY 按姓名分组COUNT(*) 统计选修门数。如果学生表里没有重名用 SNAME 分组没问题严谨一点也可以 GROUP BY S.S#SELECT 里输出 SNAME。答题时如果题目要求“学生姓名”记得 SELECT 的是 S 表的 SNAME 而不是 S#输出字段和题目不一致也会扣分。3.3 完整性约束与权限管理把 DBMS 的控制功能写成 SQL数据库完整性和安全性虽然在第 4、5 章才正式出现但对应的 SQL 操作在 SQL 章就可以顺手掌握。完整性分三类实体完整性指基本表主属性不能取空值参照完整性指外码要么为空要么是另一个关系主码的有效值用户定义完整性是自定义的取值约束比如成绩属性限制在 0 到 100。触发器在 INSERT、UPDATE、DELETE 操作时自动执行删除触发器用 DROP。权限管理用 GRANT 和 REVOKE 两个语句。授权给用户 ZHAO 修改 SC 表 GRADE 列的权限GRANT UPDATE(GRADE) ON SC TO ZHAO;收回用户 ZHAO 对学生表 STUD 中学号 XH 列的修改权REVOKE UPDATE(XH) ON STUD FROM ZHAO;注意列权限写在权限名后面的括号里表名写在 ON 之后用户写在 TO/FROM 之后。REVOKE 语句有个常见写法错误是把 ON 后面写成 TABLE正确的是直接写表名第 4 章选择题第 6 题的四个选项就是专门在考这个格式。安全性控制的一般方法有用户标识鉴定、存取控制、审计、数据加密和视图保护五级安全措施这些概念和 GRANT/REVOKE 配合记忆第五章的填空题就能顺手拿下。4. 范式理论与分解实操函数依赖是一条主线4.1 候选码、部分依赖与传递依赖判定范式等级的三步法第六章关系数据理论是整个数据库课程中最抽象、也最实际的一章。判定一张表属于第几范式核心是找准候选码再检查非主属性与候选码之间的依赖关系。三个判定条件对应三个步骤第一步看关系模式是否所有属性都不可再分不满足就不是 1NF第二步看非主属性是否对候选码存在部分函数依赖存在则最高只能到 1NF第三步看非主属性是否存在对候选码的传递函数依赖存在则最高只能到 2NF都不存在就是 3NF进一步所有决定因素都包含候选码则达到 BCNF。部分函数依赖指的是候选码的某个真子集就能决定某个非主属性典型场景是复合码。比如一本书的章节标题依赖“书号”而不依赖“书号页码”就会出现部分依赖。传递函数依赖是一条链X 决定 Y、Y 决定 Z而 Z 不能直接从 X 推出。考试里问“候选关键字中的属性称为主属性”就是这个意思主属性和非主属性的划分完全取决于候选码的构成。题库里有一道很经典的判断题关系模式 R(A,B) 已属于 3NF下列说法哪个正确。答案是它仍可能存在插入删除异常除非达到 BCNF。这个结论提醒我们3NF 不一定能完全消除异常想彻底解决适合性设计问题要看是否达到 BCNF 或更高。选项里“一定消除了插入和删除异常”和“一定属于 BCNF”都是干扰项3NF 只是一般意义上的设计基线不是终点。4.2 综合题拆解从原模式到 2NF 再到 3NF 的完整路径先看第一个完整题目学生关系模式 S(Sno, Sname, SD, Sdname, Course, Grade)。先写出函数依赖Sno → SnameSno → SDSD → Sdname(Sno, Course) → Grade候选码是 (Sno, Course)。Sname、SD、Sdname 都是部分依赖候选码的非主属性因此原模式只满足 1NF。分解时先把部分依赖拆出去得到S1(Sno, Sname, SD, Sdname)S2(Sno, Course, Grade)S2 没有非主属性部分依赖候选码也没有传递依赖直接达到 3NF。S1 里 SD 依赖 SnoSdname 依赖 SD非主属性 Sdname 传递依赖 Sno所以 S1 仍停在 2NF。继续拆S11(Sno, Sname, SD)S12(SD, Sdname)拆到最后三个关系 S11、S12、S2 都是 3NF。这个分解过程要保持两条原则无损连接性和保持函数依赖。无损连接意味着可以自然连接还原原关系保持函数依赖意味着每个依赖都能在某个分解后的关系里继续成立。只拆属性不检查依赖很容易把 Sdname 和 SD 拆散导致依赖丢失。第二个题目是教学关系 R(课程名, 教师名, 教师地址)候选键是课程名函数依赖为课程名→教师名、教师名→课程名、教师名→教师地址。课程名→教师地址是通过教师名传递得到的所以 R 是 2NF 而不是 3NF。删除某门课程时会把教师地址也带丢产生删除异常。分解为 R1(课程名, 教师名) 和 R2(教师名, 教师地址) 后删除课程数据只影响 R1R2 里的教师地址保留异常消失。这道题的价值在于展示“删除异常不是靠删数据解决而是靠拆表解决”。第三个题目是商业集团关系 R(商店编号, 商品编号, 数量, 部门编号, 负责人)三个规定推出三条函数依赖(商店编号, 商品编号) → 部门编号(商店编号, 部门编号) → 负责人(商店编号, 商品编号) → 数量候选码按题目答案取 (商店编号, 商品编号, 部门编号)。从候选码的真子集 (商店编号, 商品编号) 推出数量说明非主属性数量部分依赖于候选码因此 R 最高只达到 1NF。实际业务中设计订单明细表时如果日期、门店、商品、数量混在一起而主码定错就会产生这种部分依赖导致同一笔订单重复统计。这组题目做完可以总结出一套动作先把题干约束逐条转成函数依赖再从依赖出发找候选码然后判断部分依赖和传递依赖最后按需分解并检查依赖保持。这套流程也能直接用在数据库设计评审里新表落库前花十分钟过一遍能省掉后续很多改表结构的麻烦。5. 避坑复盘这份题库里最常踩的五个错题点5.1 现象把数据独立性与数据一致性混为一谈现象选择题里出现“数据独立性”时容易选成“数据不会变化、数据都一致”尤其当选项里同时出现“数据一致性”时两个概念往往会被当成同一个东西。第一章第 9 题问数据库系统正确叙述有人看到“避免了一切冗余”就选实际教材只承诺减少冗余。原因数据独立性定义是“应用程序与数据库中存储的数据不存在依赖关系”理解不到位时就把抽象关系记成了数据状态。数据一致性是正确性和相容性的问题归完整性控制管和独立性是两条线。解决把独立性拆成物理独立性和逻辑独立性用两级映射去对应记忆把一致性归到完整性控制的内容群。复习时遇到“独立性”先问自己“谁和谁独立”答出应用程序和存储结构就不会和一致性混淆。5.2 现象子查询的 WHERE 条件张冠李戴现象写“选修全部课程”这类双重否定 SQL 时会把 SC.S# S.S# 写成 C.C# SC.C#或者漏掉内层关联条件结果查出来的是空集或全表。题库第 5 题的三层嵌套结构每一层的连接条件都要独立检查。原因相关子查询的子查询引用外层别名执行顺序和普通子查询不同初学阶段容易把关联条件位置放错。内层子查询里的 SC.S# 和 SC.C# 是连接桥梁缺一个就构不成“这个学生学了这门课”的判断。解决先把 SQL 写成两个版本的对比IN 版本和 NOT EXISTS 版本都写一遍验证结果一致再对照复习。跑不出来时按“外层遍历→中层判断→内层验证”的次序逐层排查。我当时是用一个三行两列的小表手跑了一遍子查询才把三重 NOT EXISTS 的执行顺序真正看明白。5.3 现象GRANT/REVOKE 语法对象写反授权语句在 ON 后面抖现象写 REVOKE 语句时把 ON 后面写成 TABLE或者不写具体列权限直接写权限名例如 REVOKE UPDATE ON STUD FROM ZHAO。第 4 章选择题第 6 题四个选项的差异就在 ON 后面是 TABLE 还是具体表名答案要求是直接写 STUD。原因把完整性约束和权限管理的语法混在一起记或者把 CREATE TABLE 的语法惯性带进来。GRANT 和 REVOKE 的对象格式是固定的列权限写在权限名后的括号里表名写在 ON 后面用户写在 TO/FROM 后面顺序错了语义就变了。解决把这组语法固定成模板。GRANT UPDATE(GRADE) ON SC TO ZHAOREVOKE UPDATE(XH) ON STUD FROM ZHAO。要改变的是 ON 后面的表名和权限括号里的列名其他位置不要动。上线环境回收权限时漏写表名会造成误回收这个格式值得在动手前默写一遍。5.4 现象范式分解后函数依赖对不上现象把关系模式拆成多张表后原有的函数依赖在分解后的表中找不到载体例如把 SD→Sdname 拆没了或把 (商店编号, 商品编号)→数量漏掉。分解完再检查发现原始约束无法在任意一张关系里完整表达。原因分解时只盯着属性拆分没有同步检查每条函数依赖在哪个关系里继续成立。函数依赖是设计约束不是可以随意丢弃的临时条件。无损连接和依赖保持是分解的两条底线只保属性不保依赖等于白拆。解决分解每一步都按依赖检查。把每个函数依赖写在一张纸上拆完一个关系就打勾一项全部拆完后确认所有依赖仍被某个关系覆盖。S11(Sno, Sname, SD) 和 S12(SD, Sdname) 拆开时SD→Sdname 必须落在 S12 里这样才叫保持依赖。5.5 现象把主码、外码和候选码三种身份混用现象工厂、产品、职工和生产关系里把工厂编号直接当职工表的主码或在生产表里把工厂编号单独当成主码。这种错误在 E-R 图转换应用题里出现频率很高。原因三类概念在填空题里反复考但在具体表结构转换时很多人还没养成先标候选码再选主码、最后标外码的习惯。主码是本关系内唯一标识元组的属性外码是引用其他表主码的属性候选码是可能成为主码的属性集合三个身份各不相同。解决做表转换时先圈出每个关系的候选码再选一个做主码最后看哪些属性引用了别的表。生产表主码为 (工厂编号, 产品编号)语义是“某个工厂生产某种产品”单一编号标识不了这个联系。实际开发中设计表时养成在表头标注 PK/FK 的习惯能避免后续 JOIN 时选错关联字段也能让接手的人一眼看懂表关系。6. 把这份题库变成可重复的自测流程用这套题自测按三轮走最快。第一轮只做选择题和填空题按章节切限时 40 分钟重点看概念能不能即时反应。第二轮做 SQL 书面作业和范式综合题时长控制在 60 分钟以内SQL 题必须手写一遍别直接看答案。第三轮把错题按来源标记成三种A 类是记忆错误比如数据独立性定义背串B 类是理解偏差比如子查询范围意思对但边界不清C 类是推导错误比如范式分解路径写错。错题标注完再回到对应章节去翻原始定义而不是只看本题答案。推荐用一张很小的自测记录表按章节记录“题目号、我的答案、标准答案、错误类型、对应知识点”五列。几轮下来你会很清楚自己的薄弱点到底在概念辨析、SQL 书写还是范式推导这比盲目重刷整本习题省时间。SQL 题建议直接在本地数据库里建三张极简表学生、课程、选课把书面的六道题真实跑一遍看到查询结果的那一刻很多语法细节会立刻沉淀下来比反复读答案有效得多。我自己复习时吃过一次亏只看题不做复盘整本做完还是会在“外模式/模式/内模式”的选择题上反复错。后来把错误类型标记加上去才发现错因是 B 类和 C 类各占一半而不是记忆问题。从那以后每轮复习都强制走一遍“做题→标错因→翻知识点→重做错题”的流程速度和正确率同时上来了。希望这套方法也能帮到你。本文还有配套的精品资源点击获取