简介这份文档是数据库系统概论课程的期末考试试题整理面向互联网技术学习者、计算机专业学生、考研复习者以及需要巩固数据库基础的开发者可用于考前自测、考点梳理和教学参考。资源包内仅包含1个doc格式文件大小约170KB内容以完整试卷形式呈现轻量便携。全文覆盖数据库系统基础、关系模型与关系代数、SQL语言、数据库设计步骤、DBMS功能、数据安全、事务处理、并发控制与封锁机制、数据库恢复等核心知识点题型包含选择题、填空题、判断题、简答题和应用题并附有相关解答思路与示例。题目中涉及物理数据独立性概念、数据库系统特点、候选码与外码判定、传统集合运算、视图的SQL定义与GRANT授权、事务原子性、S锁机制、可串行化调度以及无损连接判断等内容能有效帮助读者系统检验数据库原理掌握程度也能为教学出题提供参考。目前已有3502人学习下载适合作为期末冲刺与日常复习的实用资料。1. 数据库系统概论期末考试试题薄弱项自测与跨版本套卷解析数据库系统概论的期末考试向来是计算机相关专业里通过率最不稳定的几门课之一。不少人栽在范式判断上更多人翻车在无损连接和 ER 图转关系模型这类计算题上。这份《(完整 word 版)数据库系统概论期末考试试题》不是单套卷而是包含多年多份期末试题的文档覆盖物理数据独立性、关系代数、SQL、事务并发控制、候选码与闭包计算、ER 图转换等核心考点正好用来做考前自测和查漏补缺。无论是期末冲刺的学生还是准备面试的求职者都可以用它检验自己到底哪些知识点还没真正掌握。下面我以这套试题为蓝本把每类题型的拆解方法和踩坑经验完整梳理一遍。2. 翻开试卷先看考点分布自测优先级怎么定把整套试卷摊开你会发现它不像很多零散题库那样只堆选择题而是按选择、填空、判断、简答、应用、综合六种题型布局并且不同年份的卷子侧重点还不一样。对备考的人来说先看分布比直接埋头做题重要得多。2.1 考点模块与易错等级对照根据试题内容我把高频考点整理成下面的对照表方便你按投入产出比安排复习顺序。考点模块出现题型核心考查点易错等级数据库基础概念选择、填空数据的独立性、数据库系统特点低关系代数与 SQL选择、应用、综合投影/选择/连接的区别、SQL 嵌套查询中范式与函数依赖判断、综合部分依赖、传递依赖、BCNF 分解高无损连接判断应用初始二维表构造、追踪过程高候选码与闭包综合属性分类、闭包计算高ER 图转关系模型综合实体、联系转关系模式的规则中事务与并发控制选择、填空封锁、可串行化、脏数据中我一般会建议按“低 → 高”的易错顺序推进先把概念题快速扫完拿到基础分再集中火力攻克范式和无损连接。这套试题最值钱的部分恰恰是后面的大题因为概念题答案基本固定而计算题能在短时间内拉开差距。2.2 用套卷自测的推进节奏拿到这份文档以后不建议一上来就做整张卷子。我的做法分三遍走。第一遍只做选择和填空限时 20 分钟目的是激活记忆。做完对答案把错题涉及的知识点标注到教材目录上。这份卷子里很多道题会重复考查相同概念比如物理数据独立性考了不止一次第一遍如果做错说明基础概念还没形成条件反射。第二遍做判断和简答重点看你对结论的论证能力。比如卷子里有一道判断题view 可串行化的调度一定也是冲突可串行化的调度答案是错误的。这种题光记住结论不够你得能写出反例否则考试时换个说法就又懵了。第三遍集中做应用和综合题。这时不要边翻书边做尽量像考试一样在草稿纸上完整写出每一步。做完以后对照答案重点检查分解无损连接的二维表追踪过程以及候选码求解时是否遗漏了某些属性组合。提示套卷是有限的做完一遍以后别急着做第二遍。把错题背后对应的知识点拉到教材里重新过一遍再做同一套卷正确率才会真实反映掌握程度。3. 范式判断是拿分大户从函数依赖到 BCNF 的判定手法范式判断占据了这份试题综合题的半壁江山。不少人对 1NF、2NF、3NF、BCNF 的理论背得滚瓜烂熟但一落到具体关系模式上就不知道从哪下手。问题通常出在没养成固定的分析顺序。3.1 判定范式的三步固定流程我把整套试题里涉及范式判断的题目走了一遍发现判定过程可以固化成三个步骤按顺序执行基本不会漏判。第一步写出全部函数依赖。这是最原始的材料所有后续判断都建立在它之上。比如卷子里那个工厂日产量的关系模式 R职工编号日期日产量车间编号车间主任题目给出的规则可以翻译成三条 FD职工编号日期→ 日产量 职工编号 → 车间编号 车间编号 → 车间主任第二步确定候选码。这里用“谁不在函数依赖右侧”来缩小范围。左侧出现过的属性是职工编号、日期、车间编号其中车间编号能被职工编号推出来可以排除。候选码锁定为职工编号日期。第三步检查非主属性对候选码的依赖方式判断部分依赖和传递依赖。非主属性包括日产量、车间编号、车间主任。日产量完全依赖候选码没问题。但车间编号和车间主任只依赖职工编号而职工编号是候选码的真子集这就构成了部分函数依赖说明 R 不是 2NF。对照这段流程可以写出一个作业脚本方便以后拿到任何关系模式都按同样顺序检查def check_nf(candidate_key, fds, attributes): # candidate_key: 候选码集合元组 # fds: 函数依赖列表每个元素是 (左部集合, 右部属性) # attributes: 全部属性集合 non_primary attributes - set(candidate_key) partial_deps [] transitive_deps [] for lhs, rhs in fds: if set(lhs).issubset(set(candidate_key)) and set(lhs) ! set(candidate_key): if rhs in non_primary: partial_deps.append((lhs, rhs)) # 检查传递依赖存在 X-Y, Y-Z且 Y 不是候选码 return partial_deps, transitive_deps这里的关键参数是候选码的选取和函数依赖的左部集合。脚本只做结构检查真正的判断还需要你确认每一个依赖是不是完全依赖因为候选码的判断本身需要闭包计算。脚本的价值在于把流程机械化避免手工检查时漏掉某个依赖。3.2 BCNF 判定的边界条件到了 BCNF 这一步规则变成每个非平凡函数依赖的决定因素都必须是超码。判断时有一个容易忽略的坑就是非主属性对候选码的部分依赖消除以后主属性内部可能还藏着部分依赖。卷子里有个例子RWXYZF { X→ZWX→Y }。候选码是 WX。把 R 分解成 R1WXY和 R2XZ以后R1 的依赖是 WX→YR2 的依赖是 X→Z两个依赖的决定因素分别是 WX 和 X恰好是它们各自的候选码所以都是 BCNF。但并不是所有分解到 2NF 的模式都能一步到 BCNF。卷子里那个职工日产量的例子R1职工编号车间编号车间主任就是 2NF 但不是 3NF因为存在传递依赖职工编号→车间编号→车间主任。要拆成 R11职工编号车间编号和 R12车间编号车间主任才能进 BCNF。3.3 判断前先画依赖图这里有个实操小习惯很值得养成拿到函数依赖集合先用箭头把依赖关系画成图再开始判断。画图时你会直观看到哪些属性有多条出边哪些属性是被推导出来的。比如 A→BC 加上 B→D图上就能看到 A 经过 B 间接指向 D这意味着 D 对 A 的依赖是传递的不能想当然地认为 A→D 是直接依赖。这套试题里有一道经典的 Armstrong 公理证明题由 X→Z 和 X→Y 证明 X→YZ。画依赖图以后你会发现这个证明无非就是沿着增广律和传递律的路径把已知依赖串起来。画图不是为了考试拿步骤分而是防止你漏掉藏在函数依赖之间的隐藏依赖。4. 无损连接与候选码求解二维表追踪法和闭包计算的完整流程无损连接判断和候选码求解是这套试题里得分率最低的两个题型也是面试时经常被追问的细节。这两类题方法固定只要流程走对答案不会跑偏。4.1 无损连接判断的二维表构造与追踪规则无损连接判断的标准做法是构造初始二维表。做法是把分解后的每个关系模式作为一行把全部属性作为列。如果某个关系模式包含某个属性就在对应位置填 a否则填 b 加行号。以卷子里那道题为例RU, FU{A, B, C, D, E}F{AB→C, C→D, D→E}分解为 R1(A, B, C)、R2(C, D)、R3(D, E)初始表是这样的属性ABCDER1a1a2a3b14b15R2b21b22a3a4b25R3b31b32b33a4a5接着按函数依赖逐条扫描。AB→C 这条依赖R1 行有 A 和 B 的 a 值C 本身就是 a3不用改。C→D 这条R1 行的 C 是 a3D 是 b14R2 行的 C 是 a3D 是 a4根据规则把 R1 的 D 从 b14 改成 a4。D→E 同理R1 的 E 从 b15 改成 a5R2 的 E 从 b25 改成 a5。此时 R1 行全变成 a说明该分解是无损连接。需要注意的一个细节是扫描函数依赖时要反复多轮因为第一轮改动之后某些之前不满足条件的行在新状态下可能又能推进了。我见过很多人只扫一轮就下结论结果漏掉了本该成功的匹配。追踪过程可以用一个简单的表驱动脚本模拟核心逻辑就是不断比对函数依赖的左部和右部把能改的 b 全部改成 adef judge_lossless(relations, attributes, fds): # 构造初始表 table {} for i, rel in enumerate(relations): for attr in attributes: table[(i, attr)] fa{attributes.index(attr)1} if attr in rel else fb{i1}{attributes.index(attr)1} changed True while changed: changed False for lhs, rhs in fds: rows_with_lhs [i for i in range(len(relations)) if all(table[(i, x)][0] a for x in lhs)] if rows_with_lhs: target table[(rows_with_lhs[0], rhs)] for i in rows_with_lhs: if table[(i, rhs)] ! target: table[(i, rhs)] target changed True return any(all(table[(i, attr)][0] a for attr in attributes) for i in range(len(relations)))这段代码里最关键的两个参数是 fds 的格式和初始表构造时 a/b 的命名规则。命名规则影响的是显示层判断逻辑只看首字母是否 a。实际做题时手写二维表比跑脚本更快但脚本适合用来验证你手算的结果尤其是多轮扫描以后容易数错行列的场合。4.2 候选码求解属性分类和闭包计算候选码求解是范式判断的前提解法不唯一但推荐用属性分类法加闭包验证的组合。先按属性在函数依赖中的位置分类只出现在左边的属性是必选属性只出现在右边的属性是必选不选属性两边都出现的属性是待定属性两边都不出现的属性是必选属性。以 F { A→BCCD→EB→DE→A } 为例U{A, B, C, D, E}。A 在左边和右边都出现是待定属性B 左边和右边都出现C 只出现在左边是必选D 只出现在右边E 在左边和右边都出现。整理以后候选码里必须包含 C 和 D因为 D 虽然在右边出现但它没有别的属性可以直接推出它。然后验证候选码。先试 CD计算 (CD)由 C 单独推不出新属性D 也推不出新属性但 CD 整体能推出 EE 又能推出 AA 又能推出 BC。最后 (CD) ABCDE说明 CD 是候选码。再试能否去掉某个属性C 单独闭包是 CD 单独闭包是 D都不能覆盖全集所以 CD 是最小候选码。同理继续试 A、E、BC最后得到候选码集合是 {A, BC, CD, E}。闭包计算的代码可以写成下面这样方便你反复验证不同属性组合def closure(attrs, fds): result set(attrs) changed True while changed: changed False for lhs, rhs in fds: if set(lhs).issubset(result) and rhs not in result: result.add(rhs) changed True return result用这个函数验证closure({C,D}, fds) 返回的集合长度是否等于全部属性数。如果等于说明候选码成立。实际笔试时不需要写代码但代码能帮你建立一个精确的判定标准而不是凭直觉猜。候选码求解还有个容易踩的细节属性 X 如果不在任何函数依赖的左右两侧出现它必须包含在候选码里。这道判断题在卷子里出现过很多人想当然地认为“左右都不出现就不重要”实际恰恰相反只有 X 自己能决定 X不包含它的话闭包永远不可能覆盖全集。5. 常见问题避坑刷套卷时容易错的五个细节成套刷下来加上不同年份卷子对比我发现有几个细节错误出现频率极高。这里按“现象 → 原因 → 解决”的格式整理帮你提前排雷。5.1 无损连接判断只看一轮扫描就下结论现象手工追踪二维表时第一轮扫描结束后发现没有一行是全 a直接判定分解有损结果参考答案说无损。原因第一轮改动之后新产生的 a 值可能激活原本不满足条件的函数依赖需要第二轮甚至第三轮继续扫描。很多教材例题碰巧一轮就能出结果导致不少人误以为扫描一轮就够。解决写完初始表以后强制自己至少扫描三轮或者设置一个规则只要这一轮有任意一个 b 被改成 a就必须再扫一轮直到某轮完全没有改动为止。5.2 判断候选码时漏掉左右都不出现的属性现象求候选码时把出现在函数依赖左边的属性都列了一遍结果漏掉了某个关键属性导致闭包算不满。原因函数依赖集合本身没有覆盖全部属性那些既不在左部也不在右部的属性没有被任何依赖约束但它们确实属于关系模式。不把它们纳入候选码闭包永远不可能等于全集。解决做题第一步先拿全部属性和函数依赖里出现过的属性做差集差集里的每个属性都必须直接放进候选码然后再去验证其他组合。5.3 SQL 嵌套查询的关联关系没理清现象卷子里有一道检索比“王华”年龄大的学生姓名有人写成 SELECT SN, AGE, SEX FROM S WHERE AGE (SELECT AGE FROM S WHERE SN 王华)结果没问题。但换一道题比如检索选修了 C2 且成绩最高的学生学号就有人把子查询里的表别名写错导致关联列引用报错或语义错误。原因嵌套查询里内层和外层引用同一张表时容易混淆列的归属。尤其是当子查询里还有聚合函数时很多人会在 WHERE 子句里写 MAX(GRADE)但没意识到聚合函数不能直接出现在 WHERE 中。解决遇到聚合条件先写成子查询再比较。比如 MAX(GRADE) 必须出现在子查询的 SELECT 中外层用 GRADE (SELECT MAX(GRADE) ...) 来关联。如果子查询和外层引用了同一张表养成给表起别名的习惯。5.4 视图的存储机制理解偏差现象选择题问到“数据库中只存放视图的什么”四个选项里总有人选“对应的数据”。原因视图的本质是虚拟表它的数据来自基本表数据库系统只在数据字典里存储视图的定义不额外存储一份派生数据。把视图理解成“存储查询结果”是常见的误解。解决记一个对比结论表存数据视图存定义。凡是视图相关的题目先确认题目问的是存储还是查询存储永远选定义。5.5 ER 图转关系模式时 M:N 联系的主键选错现象ER 图里有一个 M:N 联系转换为关系模式时有人直接取联系本身的某个属性作为主键结果无法唯一标识每条记录。原因M:N 联系在转换时新关系模式的主键必须由两端实体的主键组合而成。单独取其中任何一端的主键都不能区分另一端的多条记录。解决遇到 M:N 联系先写两端实体的主键再拼接成组合主键。如果联系还有自己的属性比如违章编号、时间等它们只能作为普通属性加入不能取代组合主键。6. 把笔试能力转化成岗位技能从一个建表习惯说起数据库理论题做多了以后你会发现一个有意思的现象面试题和期末题考的是同一套底层逻辑只不过换了一层业务外衣。范式判断、无损连接、候选码这些概念在真实工作中直接对应表结构设计的好坏。我自己的习惯是设计任何一张业务表之前先强制自己走一遍笔试里的分析流程。第一步列出所有字段。第二步写出字段之间的函数依赖这一步最花时间但能逼你理清业务关系。第三步找候选码。第四步检查是否存在部分依赖或传递依赖有就直接拆表。举个例子假设要设计一张订单表字段包括订单号、用户号、用户姓名、商品号、商品名称、下单时间。函数依赖一眼就能看出问题用户号→用户姓名商品号→商品名称这两组依赖让用户姓名和商品名称对订单号只是部分依赖。按照范式理论这张表必须拆成订单表、用户表、商品表三张。如果不拆用户改一次姓名所有历史订单里的用户姓名都要跟着改这就是数据冗余和更新异常的真实来源。-- 规范化后的建表语句 CREATE TABLE users ( user_id CHAR(8) PRIMARY KEY, user_name VARCHAR(50) NOT NULL ); CREATE TABLE products ( product_id CHAR(8) PRIMARY KEY, product_name VARCHAR(100) NOT NULL ); CREATE TABLE orders ( order_id CHAR(16) PRIMARY KEY, user_id CHAR(8) NOT NULL, product_id CHAR(8) NOT NULL, order_time DATETIME NOT NULL, FOREIGN KEY (user_id) REFERENCES users(user_id), FOREIGN KEY (product_id) REFERENCES products(product_id) );这条建表语句的逻辑和试卷里 ER 图转关系模式的思路完全一致每个实体单独成表联系通过外键表达。差异只是把“关系模式”换成了“物理表结构”。有一次我给内部系统设计权限模块起初为了图省事把所有角色和菜单放在一张大表里上线前自测时发现某个角色加菜单权限要更新多条记录稍有不慎就出现权限不一致。后来我强迫自己先写函数依赖、找候选码再动手建表半小时就把表结构调整到位了。从那以后我每次接到建表需求都强制走一遍范式分析流程即便是临时表也不例外。笔试里那些看似枯燥的判断步骤其实就是生产环境里避免返工的最短路径。希望帮到你也建议你把这份套卷里的大题当成设计练习来做做完以后再用真实业务场景验证一遍理解会深很多。本文还有配套的精品资源点击获取
简介这份文档是数据库系统概论课程的期末考试试题整理面向互联网技术学习者、计算机专业学生、考研复习者以及需要巩固数据库基础的开发者可用于考前自测、考点梳理和教学参考。资源包内仅包含1个doc格式文件大小约170KB内容以完整试卷形式呈现轻量便携。全文覆盖数据库系统基础、关系模型与关系代数、SQL语言、数据库设计步骤、DBMS功能、数据安全、事务处理、并发控制与封锁机制、数据库恢复等核心知识点题型包含选择题、填空题、判断题、简答题和应用题并附有相关解答思路与示例。题目中涉及物理数据独立性概念、数据库系统特点、候选码与外码判定、传统集合运算、视图的SQL定义与GRANT授权、事务原子性、S锁机制、可串行化调度以及无损连接判断等内容能有效帮助读者系统检验数据库原理掌握程度也能为教学出题提供参考。目前已有3502人学习下载适合作为期末冲刺与日常复习的实用资料。1. 数据库系统概论期末考试试题薄弱项自测与跨版本套卷解析数据库系统概论的期末考试向来是计算机相关专业里通过率最不稳定的几门课之一。不少人栽在范式判断上更多人翻车在无损连接和 ER 图转关系模型这类计算题上。这份《(完整 word 版)数据库系统概论期末考试试题》不是单套卷而是包含多年多份期末试题的文档覆盖物理数据独立性、关系代数、SQL、事务并发控制、候选码与闭包计算、ER 图转换等核心考点正好用来做考前自测和查漏补缺。无论是期末冲刺的学生还是准备面试的求职者都可以用它检验自己到底哪些知识点还没真正掌握。下面我以这套试题为蓝本把每类题型的拆解方法和踩坑经验完整梳理一遍。2. 翻开试卷先看考点分布自测优先级怎么定把整套试卷摊开你会发现它不像很多零散题库那样只堆选择题而是按选择、填空、判断、简答、应用、综合六种题型布局并且不同年份的卷子侧重点还不一样。对备考的人来说先看分布比直接埋头做题重要得多。2.1 考点模块与易错等级对照根据试题内容我把高频考点整理成下面的对照表方便你按投入产出比安排复习顺序。考点模块出现题型核心考查点易错等级数据库基础概念选择、填空数据的独立性、数据库系统特点低关系代数与 SQL选择、应用、综合投影/选择/连接的区别、SQL 嵌套查询中范式与函数依赖判断、综合部分依赖、传递依赖、BCNF 分解高无损连接判断应用初始二维表构造、追踪过程高候选码与闭包综合属性分类、闭包计算高ER 图转关系模型综合实体、联系转关系模式的规则中事务与并发控制选择、填空封锁、可串行化、脏数据中我一般会建议按“低 → 高”的易错顺序推进先把概念题快速扫完拿到基础分再集中火力攻克范式和无损连接。这套试题最值钱的部分恰恰是后面的大题因为概念题答案基本固定而计算题能在短时间内拉开差距。2.2 用套卷自测的推进节奏拿到这份文档以后不建议一上来就做整张卷子。我的做法分三遍走。第一遍只做选择和填空限时 20 分钟目的是激活记忆。做完对答案把错题涉及的知识点标注到教材目录上。这份卷子里很多道题会重复考查相同概念比如物理数据独立性考了不止一次第一遍如果做错说明基础概念还没形成条件反射。第二遍做判断和简答重点看你对结论的论证能力。比如卷子里有一道判断题view 可串行化的调度一定也是冲突可串行化的调度答案是错误的。这种题光记住结论不够你得能写出反例否则考试时换个说法就又懵了。第三遍集中做应用和综合题。这时不要边翻书边做尽量像考试一样在草稿纸上完整写出每一步。做完以后对照答案重点检查分解无损连接的二维表追踪过程以及候选码求解时是否遗漏了某些属性组合。提示套卷是有限的做完一遍以后别急着做第二遍。把错题背后对应的知识点拉到教材里重新过一遍再做同一套卷正确率才会真实反映掌握程度。3. 范式判断是拿分大户从函数依赖到 BCNF 的判定手法范式判断占据了这份试题综合题的半壁江山。不少人对 1NF、2NF、3NF、BCNF 的理论背得滚瓜烂熟但一落到具体关系模式上就不知道从哪下手。问题通常出在没养成固定的分析顺序。3.1 判定范式的三步固定流程我把整套试题里涉及范式判断的题目走了一遍发现判定过程可以固化成三个步骤按顺序执行基本不会漏判。第一步写出全部函数依赖。这是最原始的材料所有后续判断都建立在它之上。比如卷子里那个工厂日产量的关系模式 R职工编号日期日产量车间编号车间主任题目给出的规则可以翻译成三条 FD职工编号日期→ 日产量 职工编号 → 车间编号 车间编号 → 车间主任第二步确定候选码。这里用“谁不在函数依赖右侧”来缩小范围。左侧出现过的属性是职工编号、日期、车间编号其中车间编号能被职工编号推出来可以排除。候选码锁定为职工编号日期。第三步检查非主属性对候选码的依赖方式判断部分依赖和传递依赖。非主属性包括日产量、车间编号、车间主任。日产量完全依赖候选码没问题。但车间编号和车间主任只依赖职工编号而职工编号是候选码的真子集这就构成了部分函数依赖说明 R 不是 2NF。对照这段流程可以写出一个作业脚本方便以后拿到任何关系模式都按同样顺序检查def check_nf(candidate_key, fds, attributes): # candidate_key: 候选码集合元组 # fds: 函数依赖列表每个元素是 (左部集合, 右部属性) # attributes: 全部属性集合 non_primary attributes - set(candidate_key) partial_deps [] transitive_deps [] for lhs, rhs in fds: if set(lhs).issubset(set(candidate_key)) and set(lhs) ! set(candidate_key): if rhs in non_primary: partial_deps.append((lhs, rhs)) # 检查传递依赖存在 X-Y, Y-Z且 Y 不是候选码 return partial_deps, transitive_deps这里的关键参数是候选码的选取和函数依赖的左部集合。脚本只做结构检查真正的判断还需要你确认每一个依赖是不是完全依赖因为候选码的判断本身需要闭包计算。脚本的价值在于把流程机械化避免手工检查时漏掉某个依赖。3.2 BCNF 判定的边界条件到了 BCNF 这一步规则变成每个非平凡函数依赖的决定因素都必须是超码。判断时有一个容易忽略的坑就是非主属性对候选码的部分依赖消除以后主属性内部可能还藏着部分依赖。卷子里有个例子RWXYZF { X→ZWX→Y }。候选码是 WX。把 R 分解成 R1WXY和 R2XZ以后R1 的依赖是 WX→YR2 的依赖是 X→Z两个依赖的决定因素分别是 WX 和 X恰好是它们各自的候选码所以都是 BCNF。但并不是所有分解到 2NF 的模式都能一步到 BCNF。卷子里那个职工日产量的例子R1职工编号车间编号车间主任就是 2NF 但不是 3NF因为存在传递依赖职工编号→车间编号→车间主任。要拆成 R11职工编号车间编号和 R12车间编号车间主任才能进 BCNF。3.3 判断前先画依赖图这里有个实操小习惯很值得养成拿到函数依赖集合先用箭头把依赖关系画成图再开始判断。画图时你会直观看到哪些属性有多条出边哪些属性是被推导出来的。比如 A→BC 加上 B→D图上就能看到 A 经过 B 间接指向 D这意味着 D 对 A 的依赖是传递的不能想当然地认为 A→D 是直接依赖。这套试题里有一道经典的 Armstrong 公理证明题由 X→Z 和 X→Y 证明 X→YZ。画依赖图以后你会发现这个证明无非就是沿着增广律和传递律的路径把已知依赖串起来。画图不是为了考试拿步骤分而是防止你漏掉藏在函数依赖之间的隐藏依赖。4. 无损连接与候选码求解二维表追踪法和闭包计算的完整流程无损连接判断和候选码求解是这套试题里得分率最低的两个题型也是面试时经常被追问的细节。这两类题方法固定只要流程走对答案不会跑偏。4.1 无损连接判断的二维表构造与追踪规则无损连接判断的标准做法是构造初始二维表。做法是把分解后的每个关系模式作为一行把全部属性作为列。如果某个关系模式包含某个属性就在对应位置填 a否则填 b 加行号。以卷子里那道题为例RU, FU{A, B, C, D, E}F{AB→C, C→D, D→E}分解为 R1(A, B, C)、R2(C, D)、R3(D, E)初始表是这样的属性ABCDER1a1a2a3b14b15R2b21b22a3a4b25R3b31b32b33a4a5接着按函数依赖逐条扫描。AB→C 这条依赖R1 行有 A 和 B 的 a 值C 本身就是 a3不用改。C→D 这条R1 行的 C 是 a3D 是 b14R2 行的 C 是 a3D 是 a4根据规则把 R1 的 D 从 b14 改成 a4。D→E 同理R1 的 E 从 b15 改成 a5R2 的 E 从 b25 改成 a5。此时 R1 行全变成 a说明该分解是无损连接。需要注意的一个细节是扫描函数依赖时要反复多轮因为第一轮改动之后某些之前不满足条件的行在新状态下可能又能推进了。我见过很多人只扫一轮就下结论结果漏掉了本该成功的匹配。追踪过程可以用一个简单的表驱动脚本模拟核心逻辑就是不断比对函数依赖的左部和右部把能改的 b 全部改成 adef judge_lossless(relations, attributes, fds): # 构造初始表 table {} for i, rel in enumerate(relations): for attr in attributes: table[(i, attr)] fa{attributes.index(attr)1} if attr in rel else fb{i1}{attributes.index(attr)1} changed True while changed: changed False for lhs, rhs in fds: rows_with_lhs [i for i in range(len(relations)) if all(table[(i, x)][0] a for x in lhs)] if rows_with_lhs: target table[(rows_with_lhs[0], rhs)] for i in rows_with_lhs: if table[(i, rhs)] ! target: table[(i, rhs)] target changed True return any(all(table[(i, attr)][0] a for attr in attributes) for i in range(len(relations)))这段代码里最关键的两个参数是 fds 的格式和初始表构造时 a/b 的命名规则。命名规则影响的是显示层判断逻辑只看首字母是否 a。实际做题时手写二维表比跑脚本更快但脚本适合用来验证你手算的结果尤其是多轮扫描以后容易数错行列的场合。4.2 候选码求解属性分类和闭包计算候选码求解是范式判断的前提解法不唯一但推荐用属性分类法加闭包验证的组合。先按属性在函数依赖中的位置分类只出现在左边的属性是必选属性只出现在右边的属性是必选不选属性两边都出现的属性是待定属性两边都不出现的属性是必选属性。以 F { A→BCCD→EB→DE→A } 为例U{A, B, C, D, E}。A 在左边和右边都出现是待定属性B 左边和右边都出现C 只出现在左边是必选D 只出现在右边E 在左边和右边都出现。整理以后候选码里必须包含 C 和 D因为 D 虽然在右边出现但它没有别的属性可以直接推出它。然后验证候选码。先试 CD计算 (CD)由 C 单独推不出新属性D 也推不出新属性但 CD 整体能推出 EE 又能推出 AA 又能推出 BC。最后 (CD) ABCDE说明 CD 是候选码。再试能否去掉某个属性C 单独闭包是 CD 单独闭包是 D都不能覆盖全集所以 CD 是最小候选码。同理继续试 A、E、BC最后得到候选码集合是 {A, BC, CD, E}。闭包计算的代码可以写成下面这样方便你反复验证不同属性组合def closure(attrs, fds): result set(attrs) changed True while changed: changed False for lhs, rhs in fds: if set(lhs).issubset(result) and rhs not in result: result.add(rhs) changed True return result用这个函数验证closure({C,D}, fds) 返回的集合长度是否等于全部属性数。如果等于说明候选码成立。实际笔试时不需要写代码但代码能帮你建立一个精确的判定标准而不是凭直觉猜。候选码求解还有个容易踩的细节属性 X 如果不在任何函数依赖的左右两侧出现它必须包含在候选码里。这道判断题在卷子里出现过很多人想当然地认为“左右都不出现就不重要”实际恰恰相反只有 X 自己能决定 X不包含它的话闭包永远不可能覆盖全集。5. 常见问题避坑刷套卷时容易错的五个细节成套刷下来加上不同年份卷子对比我发现有几个细节错误出现频率极高。这里按“现象 → 原因 → 解决”的格式整理帮你提前排雷。5.1 无损连接判断只看一轮扫描就下结论现象手工追踪二维表时第一轮扫描结束后发现没有一行是全 a直接判定分解有损结果参考答案说无损。原因第一轮改动之后新产生的 a 值可能激活原本不满足条件的函数依赖需要第二轮甚至第三轮继续扫描。很多教材例题碰巧一轮就能出结果导致不少人误以为扫描一轮就够。解决写完初始表以后强制自己至少扫描三轮或者设置一个规则只要这一轮有任意一个 b 被改成 a就必须再扫一轮直到某轮完全没有改动为止。5.2 判断候选码时漏掉左右都不出现的属性现象求候选码时把出现在函数依赖左边的属性都列了一遍结果漏掉了某个关键属性导致闭包算不满。原因函数依赖集合本身没有覆盖全部属性那些既不在左部也不在右部的属性没有被任何依赖约束但它们确实属于关系模式。不把它们纳入候选码闭包永远不可能等于全集。解决做题第一步先拿全部属性和函数依赖里出现过的属性做差集差集里的每个属性都必须直接放进候选码然后再去验证其他组合。5.3 SQL 嵌套查询的关联关系没理清现象卷子里有一道检索比“王华”年龄大的学生姓名有人写成 SELECT SN, AGE, SEX FROM S WHERE AGE (SELECT AGE FROM S WHERE SN 王华)结果没问题。但换一道题比如检索选修了 C2 且成绩最高的学生学号就有人把子查询里的表别名写错导致关联列引用报错或语义错误。原因嵌套查询里内层和外层引用同一张表时容易混淆列的归属。尤其是当子查询里还有聚合函数时很多人会在 WHERE 子句里写 MAX(GRADE)但没意识到聚合函数不能直接出现在 WHERE 中。解决遇到聚合条件先写成子查询再比较。比如 MAX(GRADE) 必须出现在子查询的 SELECT 中外层用 GRADE (SELECT MAX(GRADE) ...) 来关联。如果子查询和外层引用了同一张表养成给表起别名的习惯。5.4 视图的存储机制理解偏差现象选择题问到“数据库中只存放视图的什么”四个选项里总有人选“对应的数据”。原因视图的本质是虚拟表它的数据来自基本表数据库系统只在数据字典里存储视图的定义不额外存储一份派生数据。把视图理解成“存储查询结果”是常见的误解。解决记一个对比结论表存数据视图存定义。凡是视图相关的题目先确认题目问的是存储还是查询存储永远选定义。5.5 ER 图转关系模式时 M:N 联系的主键选错现象ER 图里有一个 M:N 联系转换为关系模式时有人直接取联系本身的某个属性作为主键结果无法唯一标识每条记录。原因M:N 联系在转换时新关系模式的主键必须由两端实体的主键组合而成。单独取其中任何一端的主键都不能区分另一端的多条记录。解决遇到 M:N 联系先写两端实体的主键再拼接成组合主键。如果联系还有自己的属性比如违章编号、时间等它们只能作为普通属性加入不能取代组合主键。6. 把笔试能力转化成岗位技能从一个建表习惯说起数据库理论题做多了以后你会发现一个有意思的现象面试题和期末题考的是同一套底层逻辑只不过换了一层业务外衣。范式判断、无损连接、候选码这些概念在真实工作中直接对应表结构设计的好坏。我自己的习惯是设计任何一张业务表之前先强制自己走一遍笔试里的分析流程。第一步列出所有字段。第二步写出字段之间的函数依赖这一步最花时间但能逼你理清业务关系。第三步找候选码。第四步检查是否存在部分依赖或传递依赖有就直接拆表。举个例子假设要设计一张订单表字段包括订单号、用户号、用户姓名、商品号、商品名称、下单时间。函数依赖一眼就能看出问题用户号→用户姓名商品号→商品名称这两组依赖让用户姓名和商品名称对订单号只是部分依赖。按照范式理论这张表必须拆成订单表、用户表、商品表三张。如果不拆用户改一次姓名所有历史订单里的用户姓名都要跟着改这就是数据冗余和更新异常的真实来源。-- 规范化后的建表语句 CREATE TABLE users ( user_id CHAR(8) PRIMARY KEY, user_name VARCHAR(50) NOT NULL ); CREATE TABLE products ( product_id CHAR(8) PRIMARY KEY, product_name VARCHAR(100) NOT NULL ); CREATE TABLE orders ( order_id CHAR(16) PRIMARY KEY, user_id CHAR(8) NOT NULL, product_id CHAR(8) NOT NULL, order_time DATETIME NOT NULL, FOREIGN KEY (user_id) REFERENCES users(user_id), FOREIGN KEY (product_id) REFERENCES products(product_id) );这条建表语句的逻辑和试卷里 ER 图转关系模式的思路完全一致每个实体单独成表联系通过外键表达。差异只是把“关系模式”换成了“物理表结构”。有一次我给内部系统设计权限模块起初为了图省事把所有角色和菜单放在一张大表里上线前自测时发现某个角色加菜单权限要更新多条记录稍有不慎就出现权限不一致。后来我强迫自己先写函数依赖、找候选码再动手建表半小时就把表结构调整到位了。从那以后我每次接到建表需求都强制走一遍范式分析流程即便是临时表也不例外。笔试里那些看似枯燥的判断步骤其实就是生产环境里避免返工的最短路径。希望帮到你也建议你把这份套卷里的大题当成设计练习来做做完以后再用真实业务场景验证一遍理解会深很多。本文还有配套的精品资源点击获取
