数据库系统概论第5版答案（王珊版）：核心概念与习题解析

简介：这份文档是《数据库系统概论》第五版（王珊版）的课后习题参考答案，面向高校计算机及相关专业学生、考研复习者与数据库入门自学者，用于对照教材章节核对习题思路、巩固关系数据库基础理论。压缩包内共1个doc文件，约588KB，按教材章节组织答案，覆盖关系模型三要素、关系数据语言分类、实体完整性与参照完整性规则、关系代数五种基本运算，以及SQL语言特点、建表与查询语句等典型题目，并给出SPJ数据库等习题的完整推导过程。已有1724人学习下载，适合课后对答案、期末梳理考点或作为复习提纲使用，帮助读者快速定位薄弱知识点并理解解题步骤。

1. 翻开答案之前，先搞懂“数据库系统概论”到底在讲什么

很多人第一次听到“数据库系统概论”这门课，脑子里浮现的画面是：一堆表格、一堆 SQL 语句、一堆看不懂的符号。等到期末复习，手里攥着一份答案文档，却发现答案里全是“π”“σ”“∞”这些像外星文一样的符号，抄都不知道从哪抄起。其实这门课讲的事情特别朴素：怎么把现实世界里的信息，规规矩矩地存进计算机，并且保证存进去的东西不打架、不丢失、不重复。打个比方，它就像教你怎么设计一个超大号的、永远不会乱套的档案柜。这份《数据库系统概论第5版答案（王珊版）》文档，覆盖的正是这套“档案柜设计学”的核心章节——从关系模型、SQL 语言，到安全性、完整性、范式理论、数据库设计。搞懂它，你搞懂的不是一道题，而是一整套组织数据的思维方式。

2. 关系模型：数据库世界的“表格思维”到底特别在哪

2.1 一张表就是一个小世界

关系模型听起来玄乎，说白了就是“用二维表格来组织数据”。你打开 Excel 看到的那些行列结构，本质上就是关系模型的民间版本。但数据库里的“表”比 Excel 严格得多：每一列必须有一个明确的名字和数据类型，每一行代表一个完整的记录，而且行的顺序、列的顺序都不重要——重要的是值本身。文档里反复出现的 S 表（供应商）、P 表（零件）、J 表（工程）、SPJ 表（供应关系），就是四个互相咬合的表格，拼出一个完整的供应链小世界。

关系模型由三样东西组成：数据结构（就是这些表）、关系操作（对这些表做的查询和修改）、完整性约束（保证表里的数据不荒唐的规则）。这三者缺一不可，就像一辆车需要车架、发动机和刹车系统。

2.2 为什么要有“完整性约束”这种东西

你可能会想：表里填什么数据，我自己把关不就行了？问题是，数据库面对的是成百上千个用户同时操作，靠人盯根本盯不住。所以需要机器来守规矩。文档里讲了两条最核心的规矩：

实体完整性：主键不能为空。比如供应商表里，供应商编号是主键，那这一列就不能出现空值。为什么？因为主键是用来唯一标识一条记录的，如果主键为空，你就没法区分“这条记录是谁”。

参照完整性：外键要么为空，要么必须指向一个真实存在的主键。比如 SPJ 表里记录了“供应商 S1 给工程 J1 供应了零件 P1”，那 S1 必须在 S 表里真实存在。否则就出现了“幽灵供应商”，数据就乱套了。

文档里有一个容易被忽略的细节：外键的值在什么情况下可以为空？答案是——当这个外键属性本身不是主属性的时候。通俗地说，如果这个字段只是“顺便记录一下”，不承担唯一标识的职责，那它可以空着；但如果它同时是主键的一部分，那就绝对不能空。

2.3 关系代数：用符号“点菜”的艺术

关系代数那堆 π、σ、∞ 符号，吓退过不少人。其实它们就是几种“点菜方式”：

文档里那道“求没有使用天津供应商生产的红色零件的工程号”，用的就是“差”运算：先找出所有工程号，再减去“用了天津供应商红色零件”的工程号。这种思路在 SQL 里对应NOT IN子查询，本质上是同一件事的两种表达。

提示：关系代数的五种基本运算是并、差、笛卡尔积、投影、选择。交、连接、除都可以用这五种推出来。考试爱考这个“基本”二字，因为它意味着这套运算体系是“最小完备”的。

3. SQL 语言：为什么它被称为“数据库的普通话”

3.1 说“要什么”而不是“怎么拿”

SQL 最反直觉的地方在于：你只告诉它“我要什么”，不告诉它“怎么去拿”。这叫非过程化。打个比方，你去餐厅点菜说“来一份宫保鸡丁”，你不需要告诉厨师先去冰箱第几层拿鸡胸肉、用几档火候翻炒。数据库的查询优化器就是那个厨师，它自己决定先扫哪张表、用不用索引。

文档里总结了 SQL 的五个特点：综合统一（定义、操纵、控制一把抓）、高度非过程化、面向集合（一次操作一批数据，不是一条一条来）、两种使用方式（既能单独敲命令，也能嵌在程序里用）、简捷易学。这五条里，面向集合是最容易被低估的——你写UPDATE P SET COLOR='蓝' WHERE COLOR='红'，它一次改掉所有红色零件，而不是循环一条条改。

3.2 建表时埋下的“保险丝”

文档里建 SPJ 表的语句值得细看：

CREATE TABLE SPJ ( Sno CHAR(2), Pno CHAR(2), Jno CHAR(2), QTY INT );

这段代码只定义了列和类型，没有定义主键和外键。但在实际设计里，SPJ 表的主键应该是 (Sno, Pno, Jno) 三列的组合，同时 Sno 参照 S 表、Pno 参照 P 表、Jno 参照 J 表。这些约束在建表时加上，就等于给数据装上了保险丝——不合规的插入会被直接拒绝，而不是等到事后才发现数据烂了。

3.3 视图：给数据开一扇“过滤窗”

视图是 SQL 里一个特别巧妙的设计。它本身不存数据，只存一条查询定义。你可以把它理解成给原始表加了一层“滤镜”：不同岗位的人透过不同的滤镜看同一批数据，看到的范围不一样。文档里提到视图的四个好处——简化操作、多角度看待数据、逻辑独立性、安全保护。其中安全保护最实用：工资表里每个人的工资都能看到，但你可以建一个视图只暴露部门平均工资，然后把视图的查询权限给出去，原始表锁死。

但视图不是万能的。文档明确指出：基本表的行列子集视图一般可更新，含集合函数或表达式的视图不可更新。原因很简单——视图是虚的，你对它做修改，数据库得想办法翻译成对真实表的修改。如果视图里有一列是AVG(工资)，你把这个平均值改成 8000，数据库根本不知道该把哪个人的工资调成多少。

4. 安全性与完整性：一对容易搞混的“守门员”

4.1 防的是两种完全不同的事

初学者最容易把“安全性”和“完整性”混为一谈，因为它们都跟“数据别出问题”有关。但两者的防范对象截然不同：

• 安全性防的是人：不让没权限的人看到或改动数据。比如普通员工不能查别人的工资。
• 完整性防的是数据本身：不让不符合语义的数据进库。比如年龄不能填 200 岁，订单日期不能早于公司成立日期。

打个比方：安全性是小区门禁，拦住外人；完整性是电梯限重，拦住超载。门禁再严，电梯该超载还是超载；电梯再灵敏，也拦不住小偷进门。

4.2 自主存取控制和强制存取控制

文档里讲了两种访问控制思路。自主存取控制（DAC）是“谁有权限谁说了算”，用GRANT和REVOKE来发权限、收权限，还能用WITH GRANT OPTION让被授权的人继续往下发。强制存取控制（MAC）则是“按密级来”，每个数据对象贴一个密级标签，每个用户发一个许可证级别，系统强制规定“低级别不能读高级别”。前者灵活，后者严格，适用场景不同。

文档里有一道典型题：让每个职工只能查自己的记录。答案用了GRANT SELECT ON 职工 WHEN USER()=NAME TO ALL，意思是“当当前用户名等于记录里的姓名时才放行”。这种行级控制在实际系统里通常靠视图或应用层实现，但题目考的是思路。

4.3 审计：事后追责的“黑匣子”

再严密的安全措施也可能被绕过，所以需要审计——把所有操作自动记到日志里。文档说得很直白：任何系统的安全保护都不是完美无缺的，蓄意破坏的人总可能存在。审计日志就是数据库的“黑匣子”，出了事能回放：谁、在什么时间、动了什么数据。这东西平时用不上，用上的时候就是救命稻草。

5. 范式与设计：为什么表不能随便拆随便合

5.1 函数依赖：数据之间的“因果关系”

范式理论那一堆 1NF、2NF、3NF、BCNF，核心就一句话：表里的字段之间不能有“绕弯子”的依赖关系。什么叫绕弯子？文档里学生表的例子很典型：学号决定班级，班级决定系，系决定宿舍区。于是学号间接决定了宿舍区——这就是传递函数依赖。这种绕弯子会导致什么问题？如果某个系搬了宿舍区，你得改一堆学生记录，改漏一条就出现“同一个系的学生住在两个宿舍区”的矛盾。

部分函数依赖则是另一种毛病：主键是 (学号, 课程号) 的组合，但成绩只依赖这两者的组合，而学生姓名只依赖学号——姓名对组合主键是“部分依赖”。这种依赖会导致姓名在每条选课记录里重复存储，浪费空间还容易改漏。

5.2 各级范式到底在“消除”什么

文档里有一个重要结论：任何二目关系（只有两个属性的表）必定属于 BCNF。因为两个属性之间要么互相决定，要么一个决定另一个，不存在“绕弯子”的空间。这个结论考试爱考，理解上也不难：路只有两条，绕不出花来。

5.3 数据库设计不是“画完 E-R 图就完事”

文档把数据库设计分成六个阶段：需求分析、概念结构设计、逻辑结构设计、物理设计、实施、运行维护。很多人以为重点是画 E-R 图，其实需求分析才是地基。需求没搞清楚，E-R 图画得再漂亮也是空中楼阁。概念设计阶段产出的 E-R 图是“信息世界”的模型，不绑定任何具体数据库产品；逻辑设计阶段才把它翻译成关系表。这个“先独立于产品、再落地到产品”的思路，是为了让设计在换数据库时不用推倒重来。

文档里学校 E-R 图的例子展示了实体和联系的转换规则：一个系有若干班级和教研室，一个教研室有若干教员，教员带研究生，班级有学生，学生选课。转换成关系模型时，一对多联系通常把“一”方的主键放到“多”方做外键，多对多联系则单独建一张表。这些规则不复杂，但需要反复练才能形成直觉。

6. 什么时候该翻这份答案，什么时候不该

这份文档的价值不在于“抄答案”，而在于它把教材里散落的概念用问答形式串了一遍。适合用的场景很明确：复习时对照检查自己哪里没吃透，做题卡住时看它的推导思路，考前快速过一遍核心定义。比如关系代数的除法运算、视图可更新性的判断、3NF 和 BCNF 的区别，这些点自己啃书容易绕晕，看一遍标准表述能省不少时间。

但有两种情况我建议你别急着翻。第一种是还没自己想过就去看答案。数据库这门课的概念之间有很强的推演关系，比如“为什么外键可以为空”这个问题，你自己先琢磨一遍“主属性和非主属性的区别”，再看答案，印象会深得多；直接看答案，下次换个问法又懵了。第二种是把答案里的 SQL 语句当成唯一正确写法。文档里有些查询用了NOT IN子查询，有些用了分步查询，实际写的时候可能有更简洁或更高效的写法。答案给的是“一种可行解”，不是“标准答案”。

还有一个容易踩的坑：文档里部分 SQL 语句的语法带有特定数据库产品的痕迹（比如WHEN USER()=NAME这种写法并不是所有数据库都支持），照着抄到别的环境里可能跑不通。理解它想表达的语义比记住语法重要。

我自己当年学这门课的时候，习惯是先把每章的习题在纸上写一遍思路，哪怕写不全，也要把“这题考的是哪个概念”标出来，然后再对照答案看差距在哪。后来发现，真正让我记住的不是答案原文，而是那些“我以为自己懂了、一写就卡住”的地方。从那以后我每次复习都强制走一遍“先写思路再对答案”的流程，比单纯读答案效率高得多。希望这份文档也能帮你把“看懂”变成“真懂”。

本文还有配套的精品资源，点击获取