简介：万常选教材《数据库原理与设计》配套课后习题答案，专为高校计算机、软件工程等专业学生及数据库自学者提供。资料覆盖第2～6章及第9章内容，由作者亲笔撰写并经校验，重点解析关系模型与关系代数、实体—联系模型、关系数据理论与模式求精等核心章节，其中关系代数涵盖选择、投影、连接等运算，规范化部分对1NF至BCNF进行逐步讲解，能帮助读者系统排查课后练习中的疑难步骤。压缩包共7个文件，以3份Word文档承载核心解答，另含2个SQL脚本用于演示建表及完整性约束设置，以及1份作业说明和1个补充资料包（涉及查询优化、事务管理等拓展内容），整体体积约85KB，下载与使用都很方便。当前已有3903人学习，多用于课程作业参考、期末考试复习或考研准备。通过研读解题过程与脚本，既能加深对E-R建模、关系运算和规范化理论的理解，也能提升实际建库与数据操作能力，配合课后作业说明还能进一步梳理解题思路。
1. 万常选版数据库课后习题答案：先问自己一句，你拿到的是答案还是参考答案
深夜两点，刷到一道「求最小函数依赖集」的课后题，对照手里的习题答案，怎么推都推不出它中间那步。你开始怀疑是自己范式分解没学透，还是这份答案本身就漏了条件。坦白说，我当年也卡在同一道题上，最后把课本正文、习题集、答案三样摆在一起逐句对，才发现答案省略了两个关键推导步骤。这个场景就是万常选版数据库课后习题答案真正要解决的问题：它不是给你一个「背下来就完事」的结果，而是一套围绕某一版教材习题的解答集合。它的价值不在纸面上那几行字，而在于你能不能拿它核验自己的推导、补全被跳过的中间过程，以及判断哪些题在更新版本里已经被删改。
这份资源适合三类人：一类是正在按章节刷题的自学者，需要一套能对照过程而非只给结果的答案；一类是高校里带习题课或批改作业的助教，需要快速核验学生提交的SQL和范式分解是否合理；还有一类是准备期末考试或考研复试的人，想把「会做」升级成「知道为什么这么做」。至于它到底长什么样——可能是PDF、可能是网页转写、也可能是某位前辈整理的笔记，这不重要，重要的是你得先回答一个问题：你手上这份答案，和你的教材版本、习题版本真的一致吗？后面所有章节，都围绕「核验、复现、补全」这三个动作展开。
2. 版本识别是第一步：题号对不上，后面全是白做功
2.1 三个地方确认你手上的答案属于哪个版次
万常选版教材在国内高校数据库原理课里使用面很广，但很多人没意识到它存在多个版次、多个印次，而每一次修订可能调整习题编号、增删题目，甚至修改题干里的条件。拿到一份题目写「万常选版数据库课后习题答案」的资源，我建议你先做三件事，而不是直接翻到答案页。
第一，翻教材的版权页和前言。版权页会写清楚版次（例如第某版）和印次，前言里如果有「本次修订调整了部分习题」这类表述，那答案版本就必须和这个版次严格对应。第二，对比习题编号。取教材第三章的3.1、3.2这种编号格式，看答案里对应章节的题号是否连续、是否出现教材里根本没有的题号。第三，对照题干关键词。比如某版教材用「供应商-零件」数据库，修订后改成「学生-课程-选课」库，答案里的表名如果和你教材完全对不上，说明版本不匹配。
这一步没什么玄学，就是笨功夫，但绝大多数翻车都是从这里开始的。我自己吃过一次亏：拿着网上流传的答案准备复习，结果第三章的12道题里只有8道能在我的教材上找到对应，后来一查才发现那份答案是初版的习题，而我的教材是修订版，删掉了3道题、重排了序号。从那以后，我只要拿到一份答案，第一件事永远是去翻教材前言确认版次。
2.2 建立「题号→知识点→答案状态」的映射清单
确认版本一致后，下一步不是开始刷题，而是先花二十分钟建一张映射表。这张表的目的是让后续每一章的核对、验证、补全都有据可查；否则你会陷在「这题答案错没错」的单点怀疑里，效率极低。
| 教材章节 | 题号范围 | 知识点标签 | 答案状态 | 备注 |
|---|---|---|---|---|
| 第2章 关系数据库 | 2.1-2.9 | 关系代数、元组演算、域演算 | 已核对，2.4推导省略 | 需补中间步骤 |
| 第3章 SQL | 3.1-3.15 | 建表、嵌套查询、视图更新 | 已验证，3.7 SQL在SQLite下有差异 | 见第3节验证脚本 |
| 第4章 规范化 | 4.1-4.10 | 函数依赖、范式分解、多值依赖 | 4.6无损连接未验证 | 待补分解验证 |
| 第5章 数据库设计 | 5.1-5.6 | ER图、关系模式转换 | 部分缺图 | 答案只有文字描述 |
这张表的「答案状态」一列很关键。我建议你用三种状态：未核对、已核对待验证、已验证通过。已核对待验证的意思是「答案本身逻辑看起来通顺，但SQL或分解过程没有实际跑过」；已验证通过则意味着你亲手做了验证。有了这张表，你在复习时能精准判断哪些章节可以闭眼背、哪些章节必须动手验。
3. 逐章复现答案：把「纸面解答」变成「可执行验证」
3.1 概念与简答题：三个核对维度，避免被「看起来对」骗过去
数据库课后题里有相当一部分是概念题、简答题和论述题，比如「解释三级模式结构」「简述事务的ACID特性」。这类题目最坑的地方在于：答案看起来都对，但和你的教材正文措辞不一致，考试时按答案写反而丢分。
我核对这类题目时只看三个维度。第一，术语是否与教材一致。万常选版对部分术语的翻译和通俗教材不同，比如「关系」和「表」、「元组」和「行」，答案如果用了另一套术语体系，即使含义对，最好也按教材原文改一遍。第二，是否覆盖了教材里的全部要点。很多「精简版」答案会把三级的映射关系压缩成一句话，但考试评分通常是踩点给分，少一个点就少一分。第三，有无教材修订后新增的内容。新版教材可能会在概念题里加入「数据库安全」「大数据与数据库」这类衍生内容，旧答案没写，你不能当作不存在。
实操上，我会把教材每章正文里的黑体定义句标出来，然后逐个对照答案里的表述。答案里如果有一句话在教材里找不到出处，就标记为「存疑」。这个方法很笨，但它能救命——因为概念题的分是最容易拿的，也是最容易因为措辞差异丢的。
3.2 SQL与关系代数题：用最小的本地环境把答案跑一遍
SQL题是万常选版习题的重头戏，也是答案质量最参差不齐的地方。抄答案只能保证你「看过」，不能保证你「会写」。我的习惯是：拿到任何一道SQL题的答案，先在本地建一个最小复现环境跑一遍，验证结果和题目预期是否一致。
最小环境用SQLite就够，不需要装完整数据库服务。以某道「查询选修了全部课程的学生姓名」为例，常见答案会写成关系除法或NOT EXISTS嵌套。下面是我验证这类题目的固定脚本。
-- 建表：学生、课程、选课，最小数据集 CREATE TABLE student(sno TEXT PRIMARY KEY, sname TEXT); CREATE TABLE course(cno TEXT PRIMARY KEY, cname TEXT); CREATE TABLE sc(sno TEXT, cno TEXT, score REAL, PRIMARY KEY(sno, cno)); INSERT INTO student VALUES ('001','张三'),('002','李四'),('003','王五'); INSERT INTO course VALUES ('C1','数据库'),('C2','操作系统'),('C3','网络'); INSERT INTO sc VALUES ('001','C1',90),('001','C2',85),('001','C3',88), ('002','C1',75),('002','C2',80), ('003','C1',70),('003','C2',72),('003','C3',69); -- 验证NOT EXISTS写法：查没有「一门课他没选」的学生 SELECT sname FROM student s WHERE NOT EXISTS ( SELECT 1 FROM course c WHERE NOT EXISTS ( SELECT 1 FROM sc WHERE sc.sno = s.sno AND sc.cno = c.cno ) );这段SQL的逻辑是双层NOT EXISTS。内层找出「某学生没选的课程」，外层反选「不存在这样课程的学生」，结果就是选修了全部课程的人。跑完后你会看到只返回张三和王五，李四因为缺C3被排除。这里有三个参数值得注意。第一，数据集的边界要覆盖「全选」「缺一门」「全不选」三种情况，否则验证不出来差异。第二，SQLite对NULL的处理和标准SQL有细微差异，如果建表时sno或cno允许为空，NOT EXISTS的语义可能偏离教材预期。第三，如果答案用的是GROUP BY + HAVING COUNT的写法，需要保证COUNT里对cno去重，否则同一门课选两次会导致误判。
关系代数题没法直接跑，但可以转换成SQL来核对结果。比如题目要求用关系代数表达式写「查询平均成绩大于80的学生」，答案给的是某个σ和聚合的组合，我会手写出等价SQL，看结果是否符合直觉。这一招能抓出不少「步骤美观但结果不对」的答案。
3.3 范式分解与函数依赖题：把每一步推导拆开验一遍
范式分解是数据库课后题里最容易出错的板块，也是答案「省略步骤」的重灾区。很多答案直接给出最终分解结果，跳过了求闭包、找候选键、判断是否需要继续分解的过程。如果你只是对照最终结果，会发现「看起来没错」，但让你自己从原题推一遍就卡住。
我一般会准备一张检查表，对照答案逐步核验。第一步，重新计算属性闭包，确认答案里写的候选键没错。第二步，验证每个分解后的关系模式是否满足它声称的范式。第三步，最重要的一步——检查分解是否具有无损连接性。很多答案给出的分解满足BCNF，但分解本身把原关系的信息弄丢了，这是最隐蔽的错。
无损连接的验证方法很传统：构造一张初始判定表，逐行依赖应用填充，如果某一行能填满所有属性，说明无损。这个手工过程繁琐但可靠，我建议至少在4-5道典型题上完整做一遍，之后就能凭经验判断哪些分解「一眼有损」。这里没有捷径，所谓的「直觉」也是建立在反复验证之上的。
4. 当答案和教材对不上：版本漂移、题号错位与题干残缺
4.1 答案页码与题号错位的三种具体表现
核对得多了你会发现，答案和教材对不上不一定是答案错，很多时候是结构性问题。第一种表现是「题号对但题干不同」。我见过一份答案里第三章3.9题问的是「建立计算机系学生视图」，但我的教材上3.9题问的是「建立选修数据库课程的学生视图」，题干条件整个换掉。第二种表现是「答案里有教材没有的题」。这种情况通常是答案覆盖了习题集的增补题，或者上一版教材的题目。第三种表现是「连续题号之间缺题」。答案从3.7直接跳到3.9，缺了3.8，大概率是版本修订删题后重排造成。
遇到这三种情况，我的处理原则是：所有核对以你手上的教材为准。答案里有而教材没有的题，直接跳过，不要在它上面花时间；题干不一致的，必须按教材题干重新解答，不能直接抄旧答案。很多人在这一步犯懒，觉得「意思差不多」，但考试时如果考的是教材原题，你就会发现自己背的是另一个版本的答案，一字之差全盘皆输。
4.2 符号系统差异：你的答案可能来自另一套教材体系
另一个高频「对不上」的原因是符号系统。不同版本的教材在关系代数符号上有差异，有的用σ、π、⋈，有的用SELECT、PROJECT、JOIN。万常选版教材本身在不同版次里也调整过符号体系，比如联结运算有的版次写 ⋈，有的版次直接用自然联结的英文名。答案里如果出现你教材里根本没有的符号，别急着改答案，先确认是不是版本差异。
我的建议是：在建立映射清单时，「知识点标签」一列就顺手标上该章用的符号体系。然后遇到符号不一致的答案，先翻译成你教材的符号，再比对逻辑。翻译完之后如果逻辑一致，这题算「已核对但需转换」；如果逻辑对不上，再进入真正的纠错环节。这一步能避免你把版本差异误判成答案错误。
4.3 题干条件残缺：有些题是教材自己印错了
说句掏心窝的话，教材也会出错。我遇到过一道求候选键的题，题干里给的函数依赖集合互相矛盾——某个属性同时出现在依赖左边和右边，导致闭包计算永远不收敛。当时我拿答案对了两遍都觉得不对劲，最后把题干里的依赖集合整理出来才发现，其中一个依赖的右边属性按上下文应当是另一个属性，应该是教材在排版时印错了。
这种情况下答案反而可能是对的。我的经验是：当题目本身有歧义或错误时，优先按「该章知识点最合理」的方向理解题干。如果答案恰好是按合理理解解的，那就直接用；如果答案是按有歧义的另一层含义解的，你需要自己按正确理解重解一遍。这类情况不用深究，但值得在映射清单备注里写一句「题干疑似印刷错误」，免得复习时又绕回去浪费时间。
5. 数据库习题答案避坑指南：五个最容易踩的坑，我都替你踩过
5.1 把「参考解答」当「标准答案」，连推导过程都照背
现象：某道数据库设计题的答案只给了最终ER图和关系模式，你背下来了，但考试换了个场景就完全不会画。原因：参考解答省略了「从需求中识别实体、属性、联系」的推理过程，你背的是结果不是方法。解决：每道设计题必须在草稿纸上自己重推一遍，从题干描述出发，标出所有实体、属性、联系，再对照答案的ER图找差异。差异才是你的薄弱点，而不是答案本身。
5.2 SQL题只抄不跑，上机才发现查询结果和预期不符
现象：对着答案看SQL，觉得嵌套查询写得挺顺，但习题课要求现场演示，输入同样的语句返回空结果集。原因：SQL的语义受具体数据库实现影响，教材里的标准SQL在某个具体系统里可能因为语法差异或数据边界问题而行为不同。解决：本章第3.2节的最小SQLite复现环境必须用起来，而且数据集必须包含边界情况。空结果和不对结果都可能是因为数据没造好，不一定是SQL错的。
5.3 忽略无损连接验证，范式分解「看着像BCNF」就通过
现象：答案给出的分解后每个模式都能满足BCNF定义，但合并回原关系时信息对不上——某些属性组合被凭空拆分或丢失依赖。原因：BCNF是每个分解后模式内部的性质，无损连接是整个分解方案的外部性质，两者独立，满足前者不代表满足后者。解决：每个分解方案必须单独验证无损连接性。一次完整的手工验证只需要几分钟，但能帮你过滤掉至少三成看似专业实则有损的答案。
5.4 拿旧版答案套新版教材，考试前才发现整章白背
现象：复习到并发控制一章，答案里讲的是两段锁协议的旧分类方式，教材已经改成新分类方式，术语都对不上。原因：教材修订后章节结构和术语体系可能调整，而网上流传的答案往往基于旧版。解决：回到第2章的版本识别三步法，确认版次一致后再投入记忆。如果手头只有旧版答案，宁可先标记「版本待确认」，也不要直接开背。
5.5 页面转写导致内容残缺，凭「大概」补题
现象：答案里的ER图显示不全，某道SQL题只留下半句，你凭记忆把缺的部分补上了，结果后续推导全错。原因：从网页或PDF转写来的答案，经常因为格式问题丢失图片、表格、多行SQL的缩进，而缺失的部分往往正是关键。解决：遇到图片缺失或SQL断行，立刻标记为「缺图/缺语句」，不要用猜测补全。优先找同一题在其它答案里的变体版本对照，实在找不到就自己按教材题干重解，再在映射清单里注明「此题以自解为准」。
6. 把答案整理成自己的习题库：一套可维护的核验工作流
前五章解决的是「怎么核对一份现成答案」，但更长效的做法是：把这份答案连同你的验证结果，整理成一份属于你自己的习题库。这样做的收益是后续复习、考试前冲刺、甚至给同学讲题时，你不用每次从头核对，直接查自己的标注即可。
具体做法分三步。第一步，为每道题建立一个唯一编号，格式可以是「章号-题号-版本」，例如3.7-v2表示第三章第7题第二版核对结果。第二步，在编号后记录三种状态之一：已验证通过、已验证但需注意、未验证凭印象。第三步，对SQL题和设计题各保留一份「可执行产物」——SQL题保留能跑的脚本和预期结果说明，设计题保留你手工验证无损连接的草稿照片或复述文字。
我用一张简易表格管理这些信息，结构和第2.2节的映射清单类似，但多一列「验证日期」。之所以加日期，是因为复习周期拉长后，你可能会发现当初验证通过的题现在看又有新理解，此时旧标注可以作为「当时的结论」而不是「永远的结论」。
这套工作流最值钱的部分是：它把一份来路不明的「答案」变成了带个人验证记录的「知识资产」。题库里任何一道标着「已验证通过」的题，你都能拍胸脯说出为什么对；标着「需注意」的题，你知道风险在哪。知识这东西，背下来是负担，验证过才是能力。
顺便说一句，我自己的目录下一直有个叫db-answer-check/的文件夹，每学期过了三分之一就会更新一次。有时候是发现某道SQL题的答案在另一个数据库引擎下结果不同——这不是答案错，而是语义在具体实现里有边界。我会在备注里写上「仅SQLite验证，PostgreSQL需重测」。这种习惯保了我很多次，希望你也能把这道工序留在自己的复习流程里。希望帮到你。
本文还有配套的精品资源，点击获取
