数据库原理课后题实战：用SQLite复现SQL、范式与事务验证-北京尧图网络

简介《数据库系统原理与设计》第四版课后答案是一份数据库课程学习辅助文档面向正在系统学习数据库原理的本科生、考研备考生以及相关课程授课教师用于对照教材章节习题检验作答效果、巩固概念理解。压缩包内共有1个doc文件整体大小约230KB文件为Word文档格式方便直接查看或打印使用。目前已有89人学习浏览。答案内容围绕数据库系统核心知识展开对数据、数据库、数据库系统、数据库管理系统等基础概念逐一给出定义与语义解析并通过典型问答题梳理文件系统与数据库系统的区别和联系指出各自适用的应用场景同时结合实例详细阐述数据库系统的数据结构化、共享性高、冗余度低、数据独立性高等主要特点。读者既可以快速核对课后习题答案也能从解析中提炼简答题与论述题的作答框架适合课程同步学习与考前集中复习。1. 数据库系统原理与设计课后答案为什么大家都在找这份doc拿到后该怎么用期末复习周或者自学数据库原理时很多人会搜“《数据库系统原理与设计》课后答案-第四版.doc”本质是想快速拿到概念题的标准表述、SQL题的参考写法。这份答案确实有用但只拿来对答案就浪费了课后题恰好是这门课唯一不需要额外搭环境的实战训练它考的是读ER图、写SQL、判范式、调事务而这些能力在后来的课程设计、面试和日常开发里全都要用。这篇笔记按我自己的复习和带人经验把第四版课后题按概念、设计、SQL三类拆开说清楚每类题怎么下手、怎么验证、坑在哪里适合正在补数据库基础的学生也适合想快速捡起数据库知识的一线开发者。2. 第四版课后题到底考什么概念题、SQL题与设计题的分工《数据库系统原理与设计》第四版的课后题不是单纯的背诵清单它更像是把数据库课程设计的知识点切成一个个可检验的单元。整套题大致能分成三类概念题考的是“能不能把原理讲清”设计题考的是“能不能把现实世界建模成表”SQL题考的是“能不能把想法变成可执行语句”。三者的复习方式完全不同用一套背答案的方法对付所有题最后大概率是概念题背了忘、设计题不会转换、SQL题跑不出结果。2.1 概念题从“背答案”到“讲得清原理”概念题通常集中在数据库基础知识、事务特性和恢复技术上。典型题目包括三种模式两级映像的作用、关系完整性的分类、事务ACID特性的含义、并发控制中锁的粒度、日志在恢复中的作用。这类题在答案文档里往往只有一句话的标准表述但考试和面试真正考的是你能不能在这个表述后面补上一层“为什么”。我一般建议用“先用白话解释再补标准术语”的方式复习一个概念。比如“三级模式两级映像”标准答案是一句话外模式、概念模式、内模式三级外模式/概念模式映像和概念模式/内模式映像两级。白话版本是用户看到的表结构和数据库物理存储可以分开变应用程序的SQL不用跟着存储结构调整而重写。有了这个白话再去记标准答案你会发现那不是一串名词而是一个分层解耦的设计思想。再比如事务的ACID记忆点不在四个英文单词而在于每一层的防守对象原子性防“执行到一半失败”一致性防“数据违反约束”隔离性防“并发互相干扰”持久性防“提交后丢数据”。复习概念题时拿一张纸左边写标准答案右边写一个自己编出来的小例子能写出例子就说明你懂了这个概念写不出来就回去翻书。2.2 设计题ER图、关系模式与范式判断的得分点设计题是课后答案文档里最容易被“只看不做”跳过的一类但它恰恰是期末考和课程设计的大头。设计题的标准流程是读懂需求描述画出ER图把实体、属性、联系抽出来再转成关系模式最后判断范式级别并做规范化分解。画ER图的关键是区分实体和属性以及确定联系的基数。常见混淆点是“某个字段到底是实体的属性还是另一个实体”。判断规则很简单如果这个字段在应用里需要被独立查询或参与其他联系就应该是实体否则是属性。比如“系”如果只需要存一个系名就是学生实体的属性如果系还有系主任、系办地址、开设专业就必须独立成实体。ER图转关系模式有固定的转换规则这部分答案通常比较死但容易踩坑。第一1:1联系一般可以合并到任一端实体里外键加在哪边都可以第二1:N联系在N端实体中加外键外键引用1端的主键第三M:N联系必须单独成一张表表里至少包含两端的实体主键再加上联系自带的属性。很多学生对“联系本身有属性”这件事特别容易忽略比如选课联系上的“成绩”字段它既不属于学生也不属于课程必须放在选课表里。范式判断是设计题里最不能靠背答案的部分。判断顺序是先找候选键再看是否存在部分依赖1NF上判断2NF再看是否存在传递依赖2NF上判断3NF最后看每个决定因素是否是候选键BCNF。拿学生选课模型来说设学生有学号、姓名、系、系主任课程有课号、课名、学分选课有学号、课号、成绩。这个模型里选课表以学号课号为联合主键成绩完全依赖于联合主键属于1NF和2NF学生表里学号决定系、系决定系主任系主任通过系传递依赖于学号所以学生表不满足3NF需要把系拆成独立表。这个判断过程比最后一句“属于第几范式”更重要因为课程设计报告里要求写清楚每一步的依赖关系。2.3 SQL题第四版课后题里反复出现的三类查询课后题的SQL部分通常围绕教学库、选课库或订单库展开题型集中在三类增删改查基础操作、连接查询与嵌套查询、视图与授权。其中连接查询和子查询几乎每章都会出现而且很难用背答案的方式准备——同样的查询需求换个表结构语句就不同了。做题顺序我习惯固定为先读表结构确认主外键再写SELECT最后用执行计划检查连接顺序。对于嵌套查询优先考虑用IN或EXISTS实现再想能不能改写成JOIN。一个常见例子是“查询没有选修任何课程的学生”用NOT EXISTS写比用NOT IN更稳妥因为子查询结果里如果出现NULLNOT IN的语义会直接出问题而NOT EXISTS不会。这类边界条件在课后答案里不一定有说明但在数据库课程设计的答辩里经常被追问。SQL题还有一个容易被低估的内容视图和授权。视图部分经常考“为什么用视图”和“视图能否更新”后者是玄学最多的领域——含聚合、含连接、含DISTINCT的视图通常不可更新答案文档里往往只给一句话结论。复习时最好把视图当成一段命名的SQL来理解能不能更新取决于这段SQL的底层表映射是否保持了一对一关系。3. 把课后SQL题落到本地库用SQLite复现第四版习题的最小命令课后答案文档里的SQL题最大的问题是它只给你结果不给你运行环境。很多学生对着word里的SELECT语句看了半天觉得自己看懂了到了课程设计真要写时却报错。我的做法是把书里的每个SQL题用SQLite在本地跑一遍跑通之后再回头对比答案里的写法这时候才能看出标准答案的边界条件在哪里。3.1 为什么选SQLite做复现而不是直接上MySQL常见的选择是装一个MySQL或SQL Server然后建库建表。这条路在实验课上没问题但课后自己练习时太重需要安装服务、配置账号、处理字符集和端口冲突。SQLite的优势是零配置、单文件、启动快而且它的SQL语法和标准SQL高度重合课后题涉及的建表、插入、连接查询、子查询、视图在SQLite里都能直接跑。唯一要注意的是SQLite不是所有功能都和MySQL完全一致。它默认不检查外键约束需要手动开启它没有真正的存储过程它对并发写的支持比较弱。但课后题里最多用到视图和触发器的语法验证SQLite完全够用。如果你后面要接课程设计再把同一套脚本迁到MySQL或达梦数据库迁移成本也不高。Windows、macOS和Linux都能直接用命令行版SQLite不需要额外权限不会弹防火墙。做完的库就是一个.db文件可以放在U盘里拷走比MySQL的data目录方便得多。3.2 建库建表照着课后题写DDL的边界课后题一般给好了表结构练习时最好自己先写一遍DDL再和答案对比重点看主键、外键和非空约束有没有漏掉。下面以最经典的学生选课库为例建一个student.db。-- student.db 建库脚本SQLite PRAGMA foreign_keys ON; -- 开启外键检查SQLite默认是关闭的 CREATE TABLE student ( sno TEXT PRIMARY KEY, -- 学号 sname TEXT NOT NULL, -- 姓名 sdept TEXT, -- 系 sage INTEGER CHECK (sage 0) -- 年龄加一个范围约束 ); CREATE TABLE course ( cno TEXT PRIMARY KEY, cname TEXT NOT NULL, credit INTEGER ); CREATE TABLE sc ( sno TEXT NOT NULL, cno TEXT NOT NULL, grade INTEGER, PRIMARY KEY (sno, cno), FOREIGN KEY (sno) REFERENCES student(sno) ON DELETE CASCADE, FOREIGN KEY (cno) REFERENCES course(cno) ON DELETE CASCADE );这段DDL的每一行都对应一个考点。PRAGMA foreign_keys ON 是SQLite特有的开关MySQL里默认就检查外键这里不写的话删课程时不会报错查答案时表现就和教材不符。student表里sage字段的CHECK约束不是必须的但它能检验你对“完整性约束”的理解答案文档里容易漏。sc表用(sno, cno)联合主键对应的是M:N联系单独建表的规则两个外键都加了ON DELETE CASCADE意思是一端实体被删掉时选课记录跟着删除这是设计题里经常要你补全的内容。3.3 插入数据与查询验证join、group by、子查询建表之后插入测试数据数量不用多但要覆盖边界。比如有一门课没人选用来验证外连接有一个学生选了两门课用来验证分组统计。-- 插入测试数据 INSERT INTO student VALUES (S001, 张一, 计算机, 20); INSERT INTO student VALUES (S002, 李二, 计算机, 21); INSERT INTO student VALUES (S003, 王三, 数学, 20); INSERT INTO course VALUES (C001, 数据库原理, 4); INSERT INTO course VALUES (C002, 数据结构, 3); INSERT INTO course VALUES (C003, 操作系统, 3); INSERT INTO sc VALUES (S001, C001, 85); INSERT INTO sc VALUES (S001, C002, 92); INSERT INTO sc VALUES (S002, C001, 70); -- 王三没有选任何课下面三条查询是课后题的高频题型建议每条都手写一遍再拆解。第一查询选了“数据库原理”的学生名单用连接查询。第二查询每门课的平均分只显示平均分大于80分的课程用GROUP BY加HAVING。第三查询成绩高于自己所选课程平均分的学生用子查询。-- 查询1选了数据库原理的学生名单连接查询 SELECT s.sno, s.sname FROM student s JOIN sc ON s.sno sc.sno JOIN course c ON sc.cno c.cno WHERE c.cname 数据库原理; -- 查询2平均分大于80的课程分组过滤 SELECT c.cno, c.cname, AVG(sc.grade) AS avg_grade FROM course c JOIN sc ON c.cno sc.cno GROUP BY c.cno, c.cname HAVING AVG(sc.grade) 80; -- 查询3成绩高于自己所选课程平均分的学生子查询 SELECT s.sno, s.sname, sc.cno, sc.grade FROM student s JOIN sc ON s.sno sc.sno WHERE sc.grade ( SELECT AVG(sc2.grade) FROM sc sc2 WHERE sc2.sno s.sno );三条语句对应三种容易扣分的细节。查询2里GROUP BY后面必须跟c.cno和c.cname两个字段如果只写c.cnoSQLite会因为cname没有被聚合而报错很多答案文档只给结论不给这个约束。查询3的子查询里用了表别名sc2这是必须的因为内层查询会和外层引用同一张sc表不区分别名SQL解析会有歧义。HAVING和WHERE的区别在这里很直观WHERE是在分组前过滤行HAVING是在分组后过滤组答案里经常把平均分的条件误写成WHERE AVG(...)。3.4 把答案改成可重复执行的脚本对着sqlite3命令行一条条敲能跑通但课程设计需要可重复的交付物。我习惯把建表和查询分别存成schema.sql和query.sql然后在命令行里一次性执行结果输出到文本文件里对比。# 通过命令行执行整个脚本结果保存到result.txt sqlite3 student.db .read schema.sql sqlite3 student.db .read query.sql result.txt # 查看表结构和索引确认DDL生效 sqlite3 student.db .schema用脚本执行的好处是能保留中间修改的记录改一条SQL不用把整个库重建。排错顺序是先看schema是否建成功再单独跑一条查询最后跑全量脚本。如果脚本执行时提示“no such column”基本是字段名拼写和建表不一致提示“no such table”就是.read的顺序不对表还没建完就查了。这个习惯搬到MySQL上同理用source命令或Navicat运行SQL文件道理一样。4. 范式与事务不是背的用SQL和脚本验证你的答案对不对范式判断和事务管理是课后题里最容易“背对答案但不理解”的部分。范式题不是计算题不是套完公式就结束事务题在纸面上也推不出真实行为。我的建议是把这两类题也变成能在数据库里验证的实验做完之后你对答案的理解会深一个层次。4.1 用SQL验证函数依赖与候选键别靠肉眼判断范式需要先找出函数依赖和候选键很多人只靠肉眼扫数据这很容易在数据量小的时候看走眼。数据量小不代表依赖关系成立你只看到了三行数据没冲突但约束是全量数据的逻辑。一个可行的方法是造一组专门用来“拆台”的数据用SQL查它是否违反依赖。-- 检查sno能否函数决定sdept如果同一个学号对应多个系说明sno不能决定sdept SELECT sno, COUNT(DISTINCT sdept) AS cnt FROM student GROUP BY sno HAVING COUNT(DISTINCT sdept) 1;如果这条查询返回空说明当前数据下sno函数决定sdept如果返回非空说明这个函数依赖不成立。同理可以检查复合属性要判断(sno, cno)是否函数决定grade用同样的GROUP BY方法。你还可以反过来验证候选键把想验证的属性组合作为GROUP BY字段如果每一组的行数都等于1说明这个组合能唯一决定一行是候选键的候选者。这个方法的实操价值在于课程设计答辩时老师经常会拿学生设计的表问“你这个表到底属于第几范式怎么证明的”你能说“我用查询验证过每一组依赖、没有发现冲突”这比空口说一句“我觉得是3NF”可信得多。4.2 事务隔离级别与死锁一个可复现的并发脚本课后题里有关并发控制的部分大多是背锁的类型和隔离级别。真要搞懂死锁最好自己复现一次。我用Python加SQLite模拟两个事务互相等待的过程。import sqlite3 import threading import time def update_sno(lock_sno, wait_sno, db_name): # 每个线程独立连接模拟两个数据库会话 conn sqlite3.connect(db_name, timeout10) conn.execute(BEGIN IMMEDIATE) conn.execute(UPDATE course SET credit credit 1 WHERE cno ?, (lock_sno,)) time.sleep(2) # 加锁后停留等待对方持有所需资源 conn.execute(UPDATE course SET credit credit 1 WHERE cno ?, (wait_sno,)) conn.commit() conn.close() t1 threading.Thread(targetupdate_sno, args(C001, C002, student.db)) t2 threading.Thread(targetupdate_sno, args(C002, C001, student.db)) t1.start() t2.start() t1.join() t2.join()这段脚本模拟的是两个连接分别锁住C001和C002然后各自申请对方的锁形成互相等待。SQLite的机制是其中一个会因锁超时抛出database is locked异常相当于一个简化版的死锁表现。真实MySQL里两个事务会真的卡死直到锁等待超时或你手动KILL。跑完这个实验你才能真正理解事务隔离为什么需要“锁的粒度”和“等待超时”这两个参数。锁粒度越粗并发越低越不容易死锁粒度越细并发越高越容易产生锁竞争。课后答案里把死锁原因归类成“资源竞争”和“加锁顺序不一致”这个实验就是“加锁顺序不一致”的最直观演示。4.3 索引与执行计划验证“为什么这样查更快”优化是数据库原理课里最贴近实战的部分但课后题往往只给理论B树索引为什么快、最左前缀原则是什么。验证这些最好的方式是直接看执行计划SQLite用EXPLAIN QUERY PLANMySQL用EXPLAIN。-- 无索引时的查询计划 EXPLAIN QUERY PLAN SELECT * FROM sc WHERE grade 85; -- 创建索引后再看 CREATE INDEX idx_grade ON sc(grade); EXPLAIN QUERY PLAN SELECT * FROM sc WHERE grade 85;第一次执行计划大概率显示SCAN SC表示全表扫描创建索引后显示SEARCH SC USING INDEX idx_grade说明走了索引。这一个实验就把B树索引到底做了什么讲清楚了它把全表扫描变成了按索引的有序查找。这里我建议顺手把教材里“为什么要最左前缀”也验证一下在(a,b)复合索引上只查b字段执行计划不会走索引你亲眼看到一次比背十遍规则管用。5. 常见问题与避坑答案文档、数据库环境与国产库的4个翻车点做课后题和课程设计时最容易翻车的往往不是题目本身而是答案文档、运行环境和数据库选型之间的摩擦。我自己在原题环境下踩过不少坑下面列几条最常见的按“现象→原因→解决”的顺序说。5.1 现象答案doc里的SQL在MySQL里直接报错很多课后答案的SQL是按照教材配套的SQL Server或Oracle方言写的直接复制到MySQL里会出现一堆语法错误。典型的有分页查询在Oracle里用ROWNUM在SQL Server里用TOP在MySQL里用LIMIT字符串拼接Oracle用||MySQL和SQL Server用CONCAT函数日期加减Oracle用SYSDATE加数字MySQL用DATE_ADD。原因是教材为了覆盖面广习题不一定统一用一种方言答案文档也未必标明出处。解决方法是先看题目所属章节再确认目标数据库类型写的时候做方言转换。最靠谱的做法是在SQLite里先跑标准SQL再迁移到目标库迁移时只改分页和函数部分。5.2 现象Navicat连接达梦数据库时驱动或字符集不匹配现在不少学校课程设计指定国产数据库用的是达梦数据库。实际连达梦时最常见的报错是“驱动版本不匹配”或“初始化会话失败”。原因是达梦默认兼容Oracle语法和模式但Navicat连接达梦需要单独的DM JDBC或ODBC驱动版本要跟数据库服务端对应另外达梦默认字符集和Navicat客户端的字符集如果不一致建表后中文全部乱码查询还查不到数据。解决方法是先确认达梦服务端版本和位数然后去达梦官网下载对应驱动在Navicat连接配置里选“达梦”连接类型端口默认5236不要用MySQL的3306。连上之后先执行一条SELECT 测试中文确认字符集正常再开始建表。如果字符集有问题联网的解决方案是调整达梦数据库的字符集设置离线环境则是初始化实例时选对编码。5.3 现象课程设计环境里数据库只能使用40个核心连接池参数调不上去期末课程设计时小组多人用同一个MySQL实例有人跑导入脚本占满CPU其他组员连不上报错提示连接数超限。检查之后发现服务器的连接数只有几十并发一高就拒绝连接连调大连接池上限都报权限不足。原因是MySQL默认的max_connections偏保守而且连接池本身只是客户端行为最终上限由服务端决定。data sources连接池设置成200并不意味着数据库能接住200个连接还要看服务端的max_connections和线程并发限制。解决方法是登录服务端执行SET GLOBAL max_connections300同时给每个连接设置wait_timeout缩短空闲占用。更长期的做法是别让每个人直接连库而是改为一台机器跑脚本、其他人通过结果文件协同避免连接爆炸。5.4 现象数据库死锁重启才恢复有过一次惨痛教训课程设计里两个表互相更新事务一更新订单再更新库存事务二更新库存再更新订单结果两个事务各持一把锁等对方数据库服务直接挂住重启才恢复。答案是数据被锁死但死锁根因是加锁顺序不一致。解决方法是所有事务里统一加锁顺序比如先锁订单表再锁库存表不要交叉同时给关联字段建索引避免全表锁让锁范围扩大。MySQL下还可以用SHOW ENGINE INNODB STATUS查看LATEST DETECTED DEADLOCK里面明确记录了互相等待的SQL和涉及的行比盲猜可靠得多。死锁不是玄学它就是资源等待环。5.5 现象multisim访问数据库报错其实是64位驱动问题有人做综合课程设计时把Multisim数据库功能连MySQL结果一直报“无法加载数据库驱动程序”。查了大半天发现是Windows系统是64位的MySQL装的是64位ODBC驱动但Multisim这个软件本身是32位它访问ODBC时去32位的数据源管理器中找驱动找不到就报错。原因是ODBC数据源分32位和64位两套系统自带的“ODBC数据源”入口是64位管理器不管32位应用。解决办法是用C:\Windows\SysWOW64\odbcad32.exe打开32位数据源管理器新建一个指向MySQL的系统DSN让Multisim走这个数据源。这个坑和数据库本身无关纯粹是应用位宽和驱动位宽不匹配但能把人卡一下午。遇到这个报错时先确认调用方软件的位数再装对应的驱动和配置对应的数据源。6. 把课后答案改造成课程设计一个可交付的验证技巧6.1 一个半小时把课后题变成课程设计课程设计最不需要从零开始。选课库这个模型本身就是最好的底子——它有实体、联系、外键、视图、触发器和事务覆盖了数据库设计一大半考点。我的做法是把课后答案里涉及的表结构扩展一点增加教师实体、课程与教师的关系、成绩视图和一个统计触发器然后写成一套脚本作为交付物。-- 课程设计里常用到的视图和触发器 CREATE VIEW v_stu_avg AS SELECT sno, AVG(grade) AS avg_grade FROM sc GROUP BY sno; CREATE TRIGGER trg_no_negative BEFORE INSERT ON sc FOR EACH ROW WHEN (NEW.grade 0) BEGIN SELECT RAISE(ABORT, grade cannot be negative); END;视图是把重复查询固化成虚拟表触发器则是数据库层的完整性防线课后答案里对这两块的解释通常比较薄但答辩时特别容易被问到。把这套脚本跑通以后再配一份ER图说明文档课程设计的主体就有了比临时想一个系统靠谱得多。6.2 验证答案的三个习惯我后来带人做课设时一直强调三个习惯。第一每个SQL都要用EXPLAIN看一眼执行计划确认有没有走索引第二答案里的每条SELECT都要改成可执行脚本不留在word里第三测试数据必须带边界情况——空成绩、重复选课、删除课程时的外键行为。这些年我吃过最大的亏就是对着课后答案看一遍觉得自己全会了到写课程设计时第一个JOIN就报错。从那以后我宁可每题多花十分钟跑一遍也不再看一遍纸质答案就想当然。数据库这个方向没有捷径把书里的题在本地库里跑通一遍比背十份答案都管用。希望这篇笔记能帮你在复习和课设的路上少走几步弯路也祝你做出能交付的数据库作品。本文还有配套的精品资源点击获取

数据库原理课后题实战：用SQLite复现SQL、范式与事务验证

相关推荐

基于Node.js与Vue.js的外卖订单系统开发实践

C# TCP/IP服务端实现LIS双向通讯与ASTM协议解析

透明加密软件别急着全量推：先搞懂这 6 件事

更多资讯

VMware Tools 8.8.0 安装实战：内核模块编译与常见故障排查

Spark cache与unpersist深度解析：从内存管理到缓存治理

智慧城市人行道检测实战：自建YOLO数据集与边缘部署全流程

Log Explorer for SQL Server：事务日志解析与UNDO脚本生成实战

DC-4靶机实战解析：Linux权限提升与漏洞链式推理

SSD生命周期预测：从SMART数据到机器学习实战

今日更新

小波包能量谱原理与MATLAB实现：从频带分解到故障特征提取

基于LSTM的网易云音乐评论情感分析：数据清洗与模型调优实战

Alpha-Beta剪枝与极大极小值算法：博弈树搜索原理与实战优化

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？