数据库原理及应用这门课很多人的压力是从第三次在线作业开始的。前两次作业大多数时候还在建表、插数据、写简单查询认真跟着课走基本能对付。到了第三次范围一下拉开——多表连接、聚合分组、范式判断、事务并发控制全挤在一起线上提交又有时间限制题型还经常是选择、填空、SQL补全、综合分析混着出。准备不充分的人很容易在某个环节卡死最后交上去的答案自己心里都没底。这篇内容就是围绕“第三次在线作业”这个节点来写的。不管你是正在准备这门课某次在线作业的在校学生还是自学者想检验一下数据库原理掌握程度又或者是要辅导别人做作业的老手这篇都能给你一张比较完整的地图这次作业可能考哪些知识点、每个知识点背后的原理怎么理解、哪些错误属于“我也犯过”的高频失分点、线上作答时怎么做最稳妥。我会尽量按数据库原理课程常见教学进度来梳理结合我见过的真实错题案例来讲不绕弯子。1. 先摸清第三次作业的知识边界1.1 为什么说第三次作业是个分水岭大部分数据库原理及应用课程的章节安排前段是关系模型、关系代数、SQL基础操作后段是数据库设计、范式理论、事务管理、并发控制、索引与查询优化。第二次作业往往还停留在“照葫芦画瓢”第三次作业就开始要求你把前面积累的知识综合运用起来。我见过太多学生前两次作业接近满分第三次一下掉到及格线附近。原因很简单前两次考的是记忆和模仿数据库建表语句、插入语句写熟了就有分第三次考的是理解和推导比如给你一组函数依赖让你判断最高范式等级或者让你分析某个事务隔离级别下会出现什么异常这不是背题能解决的。在线作业和纸质作业还有一个本质区别平台通常只给一次提交机会或者提交次数有限制。纸质作业你写错了划掉重写老师看到的是修改痕迹无所谓在线作业一旦提交错了就是错了没有回头路。所以从第三次开始你需要的不是“会一点”而是“稳一点”。1.2 按题型反推考点分布在线作业的题型结构通常能从课程平台或老师布置时透露的信息里看出来。常见的是下面几种组合题型常见呈现方式对应核心能力概念选择题单项、多项混合对数据库基础概念的精确辨析判断题直接判断正误对易混淆知识点的边界把握SQL补全题给出表结构和部分语句补写关键子句把业务查询需求翻译成SQL的能力范式分析题给出关系模式和函数依赖集合候选键求解、范式等级判定事务场景题描述并发操作分析结果和异常隔离级别、封锁机制的理解设计题给定业务需求简化为ER图ER模型到关系模式的转换拿到作业先别急着做花两分钟扫一遍所有题目在草稿纸上把题型和分值列出来你会发现命题人的意图很清楚选择题和判断题负责“扫盲”确保你基本概念没漏洞SQL补全和范式分析负责“拉分”考察你能否把原理用在具体问题上事务场景题和设计题负责“验能力”看你有没有真正理解数据库背后的设计逻辑。时间分配上我一般建议概念题控制在三分之一时间内范式分析题和SQL题各占四分之一留给设计题和检查的时间至少四分之一。一次在线作业的时长往往在一个半小时到两个半小时之间如果题型多更要保证大头题目先做。2. SQL综合查询与范式分解两块硬骨头一起啃2.1 多表查询的递进思路先画连接路径再写代码第三次作业里出现频率最高的SQL题基本集中在多表连接、分组聚合、子查询这三类。很多人看到长题干就慌其实解题路径是固定的。第一步把题目里出现的所有表列出来画出它们之间的关联字段。比如有一道题涉及“学生表”“选课表”“课程表”关联字段就是学号和课程号。我会先在草稿纸上写清楚学生表 Student(Sno, Sname, Sdept) 选课表 SC(Sno, Cno, Grade) 课程表 Course(Cno, Cname, Credit)第二步搞清楚题目要什么。是“查每个系选了某门课的学生人数”还是“查平均分超过80分的课程”。这决定了你是用 JOIN 还是用 GROUP BY是先用子查询过滤再连接还是先连接再聚合。第三步把业务语句翻译成SQL骨架。骨架搭好之后再补具体条件。比如这道题查询平均成绩大于等于85分的课程编号和平均成绩按平均成绩降序排列。翻译过程是需要“课程编号”“平均成绩” → 来自选课表 → 按课程编号分组 → 用HAVING过滤平均成绩 → 用ORDER BY排序。SQL骨架自然就是SELECT Cno, AVG(Grade) AS AvgGrade FROM SC GROUP BY Cno HAVING AVG(Grade) 85 ORDER BY AvgGrade DESC;这里有个高频考点WHERE和HAVING的区别。WHERE是在分组之前过滤行HAVING是在分组之后过滤组。如果写成 WHERE AVG(Grade) 85 SQL会直接报错因为聚合函数不能出现在WHERE子句里。反过来如果过滤条件是针对单行的比如“只统计成绩不低于60分的记录”那就该用WHERE先排除而不是在HAVING里做。子查询是另一个高频出题点。IN和EXISTS的选择逻辑很多人靠死记硬背我提供一个场景化记忆如果子查询的结果集很小IN就很合适如果子查询的结果集很大而且外层表也有过滤条件EXISTS通常更快。从考试角度两种写法能得出相同结果就算对但从理解角度你要能解释为什么在某些数据库里EXISTS性能更好——因为EXISTS只要找到第一条满足条件的记录就会停止IN要把子查询结果集全部算出来再做比较。2.2 范式判断的标准流程从候选键开始范式题是第三次作业的“分水岭中的分水岭”。给一个关系模式和一组函数依赖判断它属于第几范式。很多人一上来就靠感觉看有没有重复数据就说是没达到范式这是完全错误的。正确做法永远分三步走第一步求候选键。用函数依赖闭包的方法先找所有出现在函数依赖左边的属性集合再看哪些属性组合能推导出全部属性。比如关系模式 R(A, B, C, D)函数依赖 F {A→B, C→D, A→C}属性集合{A, A?} 不对这里要算一下。左边出现的属性有A和C但在{A, C}这个集合里A可以推出B和C也就是说{A}本身就能推出A、B、C那D呢还需要C→D而C已经被A推出来了所以{A}是整个关系模式的候选键。第二步找主属性和非主属性。候选键里的属性叫主属性不在候选键里的叫非主属性。这个区分是判断范式等级的关键。第三步对照范式定义逐个排查是否存在非主属性对候选键的部分函数依赖存在就是1NF消除部分依赖后达到2NF。是否存在非主属性对候选键的传递函数依赖存在就是2NF消除传递依赖后达到3NF。如果所有函数依赖的决定因素都包含候选键那就是BCNF。我见过太多的同学把“主键”和“主属性”混为一谈。一个组合候选键有两个属性那么这两个属性都叫主属性哪怕其中某个属性单独并不能唯一标识一条记录。比如选课关系(学号, 课程号, 成绩)候选键是(学号, 课程号)学号和课程号都是主属性。如果存在函数依赖 学号→系名那么系名这个非主属性就对候选键(学号, 课程号)形成了部分函数依赖这个关系模式只到1NF。把“学号”误当成唯一主键就会得出完全错误的范式结论。2.3 模式分解的保真要求无损连接和依赖保持范式题还有一种考法让你把一个低范式的关系模式分解成高范式比如把1NF分解成3NF。这时要检查两个性质无损连接和依赖保持。无损连接的意思是分解后做自然连接能还原出原关系不能多出错误数据也不能丢数据。依赖保持的意思是原来的函数依赖在分解后的各个关系里仍然成立。这两个性质是独立的一个分解可以满足无损连接但不满足依赖保持反过来也可能。判断无损连接有一个表格法但考试时更推荐用推导法如果两个分解后的关系有公共属性而且这个公共属性是其中一个关系的候选键那么这次分解就是无损的。判断依赖保持就把分解后每个关系的函数依赖合并起来看能不能推导出原来所有的函数依赖。举例R(A, B, C)F {A→B, B→C}候选键是{A}。分解成R1(A, B)和R2(B, C)。先看无损连接R1和R2公共属性是BB是R2的候选键吗在R2里B→CB可以决定C所以B确实是R2的候选键因此分解无损。再看依赖保持A→B在R1里B→C在R2里两个都保留了所以依赖保持也满足。这个分解就是合格的。但如果分解成R1(A, B)和R2(A, C)呢公共属性是AA是R1的候选键无损连接成立但B→C这个依赖在分解后被拆开了依赖保持不成立。而这种分解在题目里经常被设计成干扰项用来考你两个性质是否都掌握。3. 事务与并发控制概念题背后的场景逻辑3.1 ACID四个性质分别挡住了什么风险第三次作业的题库里事务相关概念题几乎是必出的。ACID四个性质——原子性、一致性、隔离性、持久性——看起来就是四个词但出题人特别喜欢把它们放在具体场景里考。我讲一个我反复使用的类比转账。从A账户转100元到B账户。原子性这个操作要么全部成功要么全部失败。不允许出现“A的钱扣了但B的钱没到账”这种中间状态。数据库用日志来做回滚一旦中途出错就把已经执行的修改全部撤销。一致性事务执行前后数据库的完整性约束不能被破坏。转账前总金额是AB转账后还是AB。如果某个事务把总金额改了就违反了一致性。注意一致性通常要靠应用逻辑来保证数据库只是提供约束手段。隔离性两个事务并发执行时互不干扰。一个事务没提交之前它对数据的修改不应该被其他事务看见。隔离性做得越强并发性能越低所以才有后面说的隔离级别。持久性事务一旦提交修改就永久生效哪怕系统崩溃也要能从日志里恢复出来。很多选择题问“事务提交后系统断电以下哪个性质能保证数据不丢”答案就是持久性靠的是重做日志而不是内存缓冲。这四种性质对应的典型失分点是分不清“一致性”和“原子性”。记忆方法原子性是“要么全做要么全不做”一致性是“做之前合法做之后也合法”。原子性崩溃了一致性大概率也被破坏但两者不是一回事。3.2 隔离级别与异常现象对照表隔离级别这块在线作业经常出一张表让你填某个隔离级别下是否会出现脏读、不可重复读、幻读。我建议你直接记住下面这张表隔离级别脏读不可重复读幻读读未提交可能可能可能读已提交不可能可能可能可重复读不可能不可能可能理论上串行化不可能不可能不可能三个异常现象的区别是另一个高频考点。脏读是读到了别人尚未提交的修改不可重复读是同一个查询语句在事务内执行两次结果却不一样因为别人提交了UPDATE幻读是同一个范围查询在事务内执行两次结果多出几行因为别人提交了INSERT。题目很喜欢考“为什么不可重复读和幻读不一样”。一句话回答不可重复读针对的是同一行的值发生变化幻读针对的是结果集的行数发生变化。UPDATE造成的是不可重复读INSERT造成的是幻读。需要提醒一点主流数据库对隔离级别的实现会有自己的变通。典型的就是可重复读隔离级别在某些数据库引擎里通过间隙锁基本消除了幻读。在线作业如果考的是教材理论按表答没问题如果考的是具体数据库行为就要按实际表现来。这个差别很细但确实出现在过作业题目里做题时留意题干是否指定了数据库环境。3.3 封锁协议与两阶段锁的考点要点封锁是数据库实现并发控制的核心手段。概念题常考三级封锁协议的对比这里有一个比较清晰的记忆框架封锁协议写锁要求读锁要求解决的问题一级封锁协议修改前加X锁事务结束释放不加S锁防止丢失修改二级封锁协议修改前加X锁事务结束释放读前加S锁读完即可释放防止丢失修改、防止脏读三级封锁协议修改前加X锁事务结束释放读前加S锁事务结束释放防止丢失修改、脏读、不可重复读死锁的判断也是考过的点。两个事务各自持有对方需要的锁各自等待对方释放形成循环等待就是死锁。在线作业如果给一个并发调度序列让你判断是否会发生死锁你只要画出每个事务的锁资源请求顺序看是否存在环路。比如事务T1持有A锁请求B锁事务T2持有B锁请求A锁这就是标准的死锁环。两阶段锁协议扩展阶段只能加锁不能解锁收缩阶段只能解锁不能加锁是保证事务可串行化的一种协议。考题一般只考概念问“两阶段锁协议能保证什么”以及“为什么不能完全避免死锁”。能保证的是并发调度的可串行化不能避免的恰恰是死锁——因为两阶段锁协议本身没有规定加锁的时机和顺序。4. 高频失分点清单这些错误我反复见过4.1 SQL书写层面的隐蔽错误SQL补全题是表现最两极分化的题型。会写的同学很快就能写出来不会写的同学往往不是不会而是错在一些不起眼的地方。我帮人排查作业时发现最频繁的是下面几类错误。第一个是LEFT JOIN之后在WHERE子句里加了右表的过滤条件。比如查“所有没有选课的学生”正确写法是 LEFT JOIN 选课表 ON 学生表.学号 选课表.学号然后在 WHERE 选课表.学号 IS NULL。但有些人写成 WHERE 选课表.成绩 IS NULL 或者 WHERE 选课表.学号 NULL——后两种都是错的。SQL里判断空值不能用等号要用 IS NULL。更隐蔽的坑是如果把左表自己的条件写在ON里和写在WHERE里语义会不同。ON里的条件在连接时生效WHERE里的条件在连接完成后过滤。对LEFT JOIN来说右表条件写在WHERE会把不满足条件的行过滤掉使结果看起来像一个INNER JOIN这就是经典的“左边连接失效”问题。第二个是GROUP BY与SELECT列不一致。SQL标准规定SELECT里出现的非聚合列必须全部出现在GROUP BY中。有些在线平台用的是MySQL的宽松模式允许你写出不规范的语句但结果可能不是你预期的。比如按系分组SELECT里写了个学号在严格模式下直接报错在宽松模式下返回的学号就是随机的一条毫无意义。写完之后养成自查习惯SELECT后面除了聚合函数每个裸列是不是都在GROUP BY里。第三个是NULL参与运算的问题。任何值与NULL做算术运算结果是NULLNULL与任何值比较结果是UNKNOWNNULL NULL也不是真而是UNKNOWN。题目考“统计某列平均值遇到NULL时怎么处理”很多人直接写 AVG(列名)其实AVG函数会自动忽略NULL但如果你先做了除法运算再聚合就会踩坑。比如算“每件商品折扣后价格的平均值”写成 AVG(价格 * 折扣率)只要有一个折扣率是NULL那一行就整行变NULLAVG结果会偏小或出问题。更稳的思路是先处理NULL比如用COALESCE把NULL替换成0或1再参与运算。4.2 范式与ER图理解层面的偏差范式题的错误往往不是计算错而是概念混淆。我把最常见的几个偏差列出来这就是在线作业的“送命题区”。一是把“候选键”直接等同于“主键”。主键是从候选键里挑出来的一个候选键是可以唯一标识元组的所有最小属性集合。求范式等级时用的是全部候选键而不是只用一个主键。如果关系模式有两个候选键函数依赖里出现了其中一个候选键的属性对另一个候选键属性的依赖这不影响BFCN的判定吗不会只要决定因素是超键函数依赖就没问题。但你如果只盯着一个主键看就可能误判。二是判断2NF时漏掉组合候选键的情况。只要候选键是一个单一属性就不存在部分函数依赖至少是2NF。很多人忘记先确认候选键是否组合上来就找传递依赖把范式等级判高了。标准流程必须从候选键开始顺序不能打乱。三是ER图转关系模式时怎么处理M:N联系。这是一道经典的送分题也是最容易丢分的题。两个实体之间的M:N联系必须转换成独立的关系模式把双方的主键都放进去组成复合主键。1:N联系则不需要额外建表把一方的主键加到多方表里作为外键就行。1:1联系更特殊任选一边放对方主键。很多同学一看到联系就建表结果1:N也建了张表画蛇添足还要丢分。四是多值属性的处理。ER模型里一个实体可以有多值属性比如“员工的多个电话号码”。转关系模式时多值属性要单独建一张表并把所属实体的主键作为外键加进去通常还要和该多值属性一起构成主键。选择题特别喜欢拿这个做干扰项问“以下哪种处理多值属性的方式是符合规范的”。4.3 时间规划与提交细节的失误在线作业的失败案例里有一类跟知识点无关纯粹是操作问题。我确实见过有同学在最后五分钟慌忙提交结果发现SQL题里中文标点混了进去或者复制答案时把题号也带上导致格式错误又或者选错题目编号提交到了错误的答题框。我的建议是在线作业不要当成考试来冲刺而要当成一份“开卷但限时”的工程任务。先花五分钟把所有题目读一遍确认哪些题目是题库原题哪些是变体题哪些完全没见过。见过原题的先做因为速度快、准确率高变体题小心做注意题干里有没有改条件完全没见过的放在最后用排除法和推理硬啃。这种做法能确保你拿到基础分的比例最大化。SQL题集中处理因为写SQL最费时间。如果在线平台支持运行SQL一定要运行验证如果不支持就把语句放到本地数据库环境里先测一遍再粘贴。我在下一节会展开讲这个操作流程。5. 在线作答的完整操作流从验证到提交5.1 先建离线答案库再上线填写我在面对任何在线作业时使用的流程都可以归纳为“离线完成、上线誊抄、提交前检查”。很多在线作业平台有时间限制但限制往往是从你点开试卷或者进入作答页面后才开始计时。如果你在进入前就把答案准备好计时开始后只是誊写和验证时间压力会小很多。具体操作是把所有题目复制到一个本地文档里每人一个答题表或者用在线文档建立独立的答案草稿区。每道题先在本地把答案写完整尤其是SQL题最好提前在本地数据库环境里实测通过。数据库软件装一个标准的关系型数据库即可或使用在线SQL练习环境。实测的时候除了确认语句能跑通还要确认结果和你手推的结果一致。有同学问为什么SQL要在本地先跑通而不用平台自带的运行功能。原因有三个第一平台自带编辑器可能没有本地开发环境顺手自动补全和格式检查都差第二某些在线平台为了防作弊会限制运行次数提前验证能避免频繁运行被系统记录第三本地运行给了你修改的余地和试错的自由平台里错误次数多了影响心态不说还可能被判定为异常操作。5.2 提交前五分钟的检查清单提交之前我强烈建议你把这道清单在脑子里过一遍核对基本信息姓名、学号栏有没有漏填选课班级有没有选错。核对题号对应答案有没有粘贴错位置尤其是SQL题和范式题这种大段文本的题目。检查SQL英文标点确认没有全角引号、全角括号、中文分号混入。重点检查字符串两侧的引号。检查SQL缩进与格式虽然计算机不看你格式但老师看成绩截图时清晰的格式能帮你避免被误判。检查附件上传如果题目要求上传ER图截图、执行结果截图确认附件已上传、格式正确、内容清晰可读。检查是否还有未作答题目页面滚动一遍空白题目标记下来即使不会也要写点相关内容能拿步骤分就拿步骤分。注意截止时间与倒计时不要掐秒提交网络延迟完全可能让你晚了几秒而平台一旦关闭提交入口你再着急也没用。我有一个印象很深的案例A同学做一道SQL题本地跑得好好的粘贴到平台后怎么提交都提示“语法错误”。后来发现是复制过程里代码中的双引号被文本编辑器自动转成了中文引号。从那以后我习惯把SQL用等宽字体显示复制时走纯文本粘贴问题就再也没出现过。5.3 把作业错题变成自己的复习资产在线作业批改结果出来后不要只看分数就结束。花二十分钟做一次复盘收益远超你的想象。我自己的做法是先把每道错题的题目和正确答案抄写在一个固定的文档里然后给错题分类是概念不清、步骤遗漏还是操作失误。概念不清的错题说明这个知识点需要回到教材重新啃一遍步骤遗漏的错题说明你的解题流程还不够标准化操作失误的错题则需要通过更细致的检查习惯来规避。这种分类的价值在于你后续花时间补的每一块短板都是真正会扣分的短板不会浪费时间。期末复习的时候你的错题文档就是最精确的复习资料。课程平台上的作业记录往往只保留一学期但你自己整理的错题可以保存很久。数据库原理整个课程的知识点是成体系的第三次作业里暴露出来的问题大概率会在期末甚至后续课程中再次出现。这也是我为什么强调“在线作业不能只求做完要追求做明白”。每次在线作业都是一次低成本的体检让你发现自己的知识盲区在哪里。与其考试时被题目难住不如在作业阶段把坑填平。把每次作业当作一次演练数据库课程学到后面你会发现自己越来越游刃有余。