简介本资源是一份面向计算机专业本科生的《数据库系统概论》期末复习备考资料聚焦核心概念辨析、典型题型训练与易错点解析助力考生高效梳理知识体系、查漏补缺。内容覆盖数据库基本原理、E-R模型与关系模型转换、SQL语法与授权操作、事务特性与并发控制、规范化理论及数据库恢复机制等高频考点题型包括20道单项选择题含详细解析、9道填空题及部分简答思路提示全部题目均紧扣教学大纲与常见考试命题逻辑。资源为单个PDF文件大小174KB结构清晰、排版紧凑便于打印或移动端随时查阅。已有149人学习下载适合作为期末冲刺阶段的自测卷、知识点速记手册与标准答案参考。1. 这不是一张卷子而是一份数据库系统“通关地图”20道单选9空填空5道简答4道设计1道综合覆盖《数据库系统概论》核心考点闭环你手头这份《数据库系统概论复习期末试题及答案.pdf》表面看是高校计算机专业常见的期末模拟卷但拆开细看它根本不是用来“刷题对答案”的——它是用20年教学沉淀压缩出来的知识校验器。我带过三届数据库课设每次学生卡在E-R图转关系模式、范式分解、事务隔离级别判断这三处翻遍教材也理不清逻辑链而这套题从第3题实体-联系模型到第15题3实体3m:n转6关系、再到第5大题综合建模全程踩着这些“断点”出题。它把抽象概念全锚定在可执行动作上比如第7题“列车运营”主码选C车次日期不是考死记硬背而是逼你现场验证“单一属性能否唯一标识一次运营事件”第19题并发操作图直接暴露“丢失修改”的时序漏洞比教科书上的伪代码更刺眼。适合两类人一是临考前72小时需要快速定位知识盲区的本科生二是刚接手数据库运维、想用标准题检验自己对ACID/锁机制理解深度的初级DBA。它不教你从零入门但能让你3小时内看清自己离“真正懂数据库”还差哪几块砖。2. 单项选择题20道题就是20个数据库系统“决策快照”每道题背后都藏着一个真实场景的取舍逻辑2.1 核心组件辨析为什么DBMS才是数据库系统真正的“大脑”第1题问“数据库系统的核心是”选项B数据库管理系统是唯一正确答案。这里必须划重点很多初学者误以为“数据库”本身即存储数据的文件集合是核心但实际运行中所有增删改查、事务控制、并发调度、安全校验全由DBMS这个软件层完成。比如你执行INSERT INTO Student...DBMS要先校验主键约束第10题D选项能插入正是因为Sno和Sname满足NOT NULL、再检查外键引用第1题隐含的参照完整性、最后写日志第17题提到的日志文件。没有DBMS数据库文件只是一堆无法被安全访问的二进制垃圾。这解释了为什么第16题强调事务隔离性——DBMS必须保证T1读A100时T2的AA-8写回不能干扰T1的后续操作这是靠锁管理器第18题S锁和事务调度器协同实现的。-- 模拟第10题建表语句注意PRIMARY KEY和NOT NULL的强制约束 CREATE TABLE Student( Sno CHAR(4) PRIMARY KEY, -- 主键唯一且非空插入时必须提供值 Sname CHAR(8) NOT NULL, -- 非空Sname字段不允许NULL但Sex/Age可为空 Sex CHAR(2), -- 允许NULL对应D选项中SexNULL的合法性 Age INT -- 允许NULL对应D选项中AgeNULL的合法性 );提示执行此建表后尝试插入A选项(5021,刘祥,男,21)会失败——因为男未加引号SQL解析为列名而非字符串字面量B选项NULL,刘祥,NULL,21违反主键约束C选项(5021,NULL,男,21)违反Sname NOT NULL约束。只有D选项满足所有约束条件。2.2 数据独立性物理与逻辑独立性的本质差异决定你改表结构时会不会“炸掉”业务系统第4题考物理独立性用户程序与磁盘数据分离第5题考逻辑独立性应用程序与数据逻辑结构分离。这两者常被混淆但实际影响天壤之别。物理独立性意味着DBA可以更换存储引擎如从InnoDB切到RocksDB、调整页大小、甚至迁移到分布式存储只要DBMS接口不变应用代码完全无感而逻辑独立性则依赖“模式/外模式映像”第5题答案A当DBA把Student表拆成Student_Info和Student_Contact两个表时只需修改视图定义第2大题第4小题的VIEW6就是典型外模式原有查询SELECT * FROM Student仍能运行。这解释了为什么第2题选C数据冗余度大是错误特点——现代DBMS通过规范化第13/14题涉及的范式理论和索引第2大题第3小题的UNIQUE INDEX主动压制冗余而非放任它存在。2.3 关系代数与SQL映射从R∩S到S-(S-R)看透集合运算背后的执行代价第8题R∩S等价于S-(S-R)这不是数学游戏而是优化器的真实工作逻辑。假设R有100万学生选课记录S有10万门课程信息R∩S需遍历R中每条记录查S是否存在匹配而S-(S-R)先算S-R10万门课减去R中已选的课程再用S减去这个结果——实际执行时数据库会自动选择哈希连接或排序合并但底层仍是集合差运算。第9题全外联接FULL OUTER JOIN的选项A直指现实痛点学校教务系统必须同时展示“未分配宿舍的学生”和“空床位”若用左联接B会漏掉空床位右联接C会漏掉未住宿学生。这种需求在ERP系统库存模块中极为常见——既要显示“有库存但未销售的商品”也要显示“已下单但仓库缺货的订单”。3. 填空题与简答题10个空格3道问答精准定位你对数据库“肌肉记忆”的薄弱环节3.1 基础概念填空每个空都是数据库设计的“宪法条款”填空题第1空“关系数据模型由关系数据结构、关系操作和______三部分组成”答案“关系完整性约束”看似简单但实操中90%的线上故障源于此。比如第10题建表时定义PRIMARY KEY本质就是声明主码完整性约束第11题授权语句GRANT UPDATE(QTY) ON SPJ TO 李勇则是通过权限约束控制数据修改边界。第5空“候选码是A和B,C”直接关联第5大题范式分解——当函数依赖A→B,A→C,A→D,(B,C)→A存在时A和(B,C)都能唯一标识元组但(B,C)→A导致A部分依赖于(B,C)破坏BCNF第5大题第1小题结论。这揭示了一个血泪经验设计表时若发现某属性能被多个属性组合推导出来立刻警觉可能存在冗余或更新异常。填空题序号答案关联实战场景参数/配置要点第2空属性自然连接NATURAL JOIN要求表间有同名同类型列若两表均有id列但类型不同INT vs VARCHAR自然连接会失败需显式指定ON条件第3空CREATE UNIQUE INDEX Stusname ON student(Sname)用户名去重场景避免注册重复姓名UNIQUE确保Sname列无重复值ON student(Sname)指定索引字段索引名Stusname便于后续DROP INDEX第4空NOT IN查询“未购买商品的客户”时常用但NULL值会导致结果为空若子查询返回NULL!ALL和NOT IN均失效应改用NOT EXISTS第6空命名冲突不同部门设计的E-R图中“员工编号”可能被命名为emp_id或staff_no合并分E-R图时需统一命名否则转换关系模式会产生歧义3.2 简答题3道题直击DBMS最脆弱的三个“神经节点”第1题“参照完整性规则”本质是外键约束的法理依据。现实中删除父表记录前若不处理子表关联数据就会触发ON DELETE CASCADE或RESTRICT策略MySQL默认RESTRICT。第2题“视图作用”中的第4点“安全保护”对应第11题授权粒度——给财务人员只授UPDATE(QTY)权限而非整个SPJ表这是最小权限原则的落地。第3题“登记日志文件原则”先写日志后写库是崩溃恢复的基石。想象一下T1执行UPDATE EMP SET SALARY1200 WHERE ENOE001若先改数据库再写日志断电后新工资值丢失且无日志可回滚反之日志中已记录“将E001工资改为1200”重启后DBMS按日志重做REDO即可恢复。4. 设计题4道SQL1道范式分解暴露你在真实业务场景中写SQL的“手抖时刻”4.1 多表关联查询从“张三没选的课”到“供应相同商品的商店”练就SQL思维肌肉第1题SQL查询SELECT CNO FROM C WHERE CNO NOT IN (SELECT CNO FROM S,SC WHERE S.SNOSC.SNO AND SNAME张三)表面是求补集实则考验对NULL的敏感度。若子查询结果含NULL如SC表中某记录SNO为NULLNOT IN会返回空集——这是线上SQL最隐蔽的坑。正确写法应为-- 更健壮的写法用LEFT JOIN IS NULL替代NOT IN SELECT C.CNO FROM C LEFT JOIN ( SELECT DISTINCT SC.CNO FROM S JOIN SC ON S.SNO SC.SNO WHERE S.SNAME 张三 ) AS T ON C.CNO T.CNO WHERE T.CNO IS NULL;第2题第2小题“找供应相同商品的商店”是典型的集合包含Containment问题。NOT EXISTS嵌套三层的写法题干答案虽正确但性能极差。生产环境应改用GROUP BY HAVING COUNT-- 高效解法统计各商店供应的商品数与256号商店对比 SELECT A.ANAME, A.CITY FROM A JOIN AB ON A.A# AB.A# WHERE AB.B# IN ( SELECT B# FROM AB WHERE A# 256 ) GROUP BY A.A#, A.ANAME, A.CITY HAVING COUNT(DISTINCT AB.B#) ( SELECT COUNT(DISTINCT B#) FROM AB WHERE A# 256 );4.2 范式分解实战从1NF到BCNF的“手术刀式”拆解拒绝纸上谈兵第5大题第2小题要求将R(A,B,C,D,E)分解为BCNF。题干给出函数依赖ABC→DE, BC→D, D→E我们一步步拆找候选码因ABC→DEABC能推出全部属性且无更小子集满足故ABC是候选码检查1NF关系R已是平面表满足检查2NF非主属性D,E对候选码ABC存在部分依赖BC→D中BC是ABC真子集故R∉2NF消除部分依赖按BC→D拆出R2(BC,D)剩余R1(ABC,DE)检查R2BC为候选码D→E不在R2中但R2中BC→D是完全依赖满足BCNF检查R1函数依赖变为ABC→DE但D→E在R1中仍存在传递依赖ABC→D→E需进一步拆消除传递依赖按D→E拆出R22(D,E)剩余R21(ABC,D)。最终得到R1(ABC)、R21(BC,D)、R22(D,E)三个BCNF关系。关键洞察每次分解都要验证新关系的函数依赖集不能简单按依赖左边分组——比如若错误地按ABC→DE拆出R(ABC,DE)R中仍存在D→E传递依赖未达BCNF。5. 综合题与避坑指南E-R建模到关系模式的“最后一公里”以及95%考生栽倒的5个深坑5.1 E-R图到关系模型从“工厂-产品-职工”业务语义读懂数据库设计的底层契约第5大题综合题描述“工厂生产多种产品产品可在多个工厂生产”明确是m:n联系“职工只能在一个工厂工作”是1:n联系。E-R图中必须体现工厂与产品间“生产”联系带属性“计划数量”因多对多联系需独立成表工厂与职工间“聘用”联系带属性“聘期、工资”1:n联系可合并到职工表实体工厂、产品、职工的主码分别为工厂编号、产品编号、职工号。转换后的关系模式工厂(工厂编号,厂名,地址)主码工厂编号产品(产品编号,产品名,规格)主码产品编号职工(职工号,姓名,工厂编号,聘期,工资)主码职工号外码工厂编号引用工厂表生产(工厂编号,产品编号,计划数量)主码(工厂编号,产品编号)外码分别引用工厂和产品表。注意题干要求“1:1和1:n联系进行合并”故聘用联系不单独建表而将工厂编号作为职工表的外键——这正是外键约束的典型应用场景确保职工记录必属某个有效工厂。5.2 避坑指南那些让阅卷老师皱眉、让线上服务宕机的致命细节现象第10题插入元组时选A选项(5021,刘祥,男,21)报错原因SQL中字符串字面量必须用单引号包裹男未加引号被解析为列名导致语法错误解决改为(5021,刘祥,男,21)或使用标准SQL的CAST(男 AS CHAR(2))现象第11题授权语句写成GRANT QTY ON SPJ TO 李勇被扣分原因权限对象名李勇是标识符不应加单引号加引号后变成字符串字面量DBMS找不到该用户解决严格按GRANT UPDATE(QTY) ON SPJ TO 李勇书写用户名不加引号现象第2大题第2小题用NOT IN写“供应相同商品”查询结果为空原因子查询SELECT B# FROM AB WHERE A#256若返回NULL如256号商店无商品NOT IN逻辑失效解决改用NOT EXISTS或LEFT JOIN ... IS NULL或在子查询中加WHERE B# IS NOT NULL现象第5大题范式分解后R21(BC,D)的函数依赖写成BC→D但未说明BC是候选码原因BCNF定义要求“每个非平凡函数依赖的决定因素必须是超码”仅写BC→D不证明BC是候选码解决需验证BC是否能推出全部属性本例中BC仅推出D故R21中BC是候选码现象第3大题简答题“登记日志原则”只答“先写日志后写库”未提“按时间序登记”原因并发事务日志若乱序崩溃恢复时无法确定操作先后导致数据不一致解决必须强调两条原则缺一不可日志序列号LSN是DBMS保证顺序的核心机制6. 从“抄答案”到“建能力”用这套题反向构建你的数据库知识图谱附赠3个验证技巧这套题最大的价值不是让你记住“第7题主码是车次日期”而是教会你用题干信息反推设计原则。比如看到第7题“列车运营”实体含车次、日期、实际发车时间等属性立刻启动三步验证第一单属性车次能否唯一标识否同一车次每天运行第二单属性日期能否唯一标识否多车次同日运行第三车次日期组合能否唯一是G101次2024-06-01只运行一次。这个过程就是ER建模中“识别实体-确定主码”的标准流程。再如第19题并发操作图不要只背“丢失修改”而要动手画时间轴T1读A100→T2读A100→T1写A95→T2写A92最终A92而非95这就是丢失修改的具象化。我一般会用三个技巧验证自己是否真正掌握逆向命题把第14题“设计关系模式是逻辑设计阶段任务”改成判断题“物理设计阶段才确定关系模式”然后解释为何错误——物理设计关注索引、分区、存储参数关系模式已在逻辑设计中固化场景移植将第5大题“工厂-产品-职工”模型迁移到电商场景“店铺-商品-用户”此时“用户收藏商品”是m:n联系必须建收藏表而非简单在用户表加商品ID数组错误注入故意在第10题建表语句中删掉PRIMARY KEY然后执行D选项插入观察是否允许重复Sno——这能直观感受主键约束的强制力。从那以后我每次审数据库设计文档都强制走一遍“主码验证→范式检查→外键追溯→日志策略确认”四步哪怕只是看别人写的DDL。因为这套题早已不是试卷而是刻在脑子里的检查清单。希望帮到你。本文还有配套的精品资源点击获取 数据库系统核心考点通关地图：从E-R建模到BCNF分解
简介本资源是一份面向计算机专业本科生的《数据库系统概论》期末复习备考资料聚焦核心概念辨析、典型题型训练与易错点解析助力考生高效梳理知识体系、查漏补缺。内容覆盖数据库基本原理、E-R模型与关系模型转换、SQL语法与授权操作、事务特性与并发控制、规范化理论及数据库恢复机制等高频考点题型包括20道单项选择题含详细解析、9道填空题及部分简答思路提示全部题目均紧扣教学大纲与常见考试命题逻辑。资源为单个PDF文件大小174KB结构清晰、排版紧凑便于打印或移动端随时查阅。已有149人学习下载适合作为期末冲刺阶段的自测卷、知识点速记手册与标准答案参考。1. 这不是一张卷子而是一份数据库系统“通关地图”20道单选9空填空5道简答4道设计1道综合覆盖《数据库系统概论》核心考点闭环你手头这份《数据库系统概论复习期末试题及答案.pdf》表面看是高校计算机专业常见的期末模拟卷但拆开细看它根本不是用来“刷题对答案”的——它是用20年教学沉淀压缩出来的知识校验器。我带过三届数据库课设每次学生卡在E-R图转关系模式、范式分解、事务隔离级别判断这三处翻遍教材也理不清逻辑链而这套题从第3题实体-联系模型到第15题3实体3m:n转6关系、再到第5大题综合建模全程踩着这些“断点”出题。它把抽象概念全锚定在可执行动作上比如第7题“列车运营”主码选C车次日期不是考死记硬背而是逼你现场验证“单一属性能否唯一标识一次运营事件”第19题并发操作图直接暴露“丢失修改”的时序漏洞比教科书上的伪代码更刺眼。适合两类人一是临考前72小时需要快速定位知识盲区的本科生二是刚接手数据库运维、想用标准题检验自己对ACID/锁机制理解深度的初级DBA。它不教你从零入门但能让你3小时内看清自己离“真正懂数据库”还差哪几块砖。2. 单项选择题20道题就是20个数据库系统“决策快照”每道题背后都藏着一个真实场景的取舍逻辑2.1 核心组件辨析为什么DBMS才是数据库系统真正的“大脑”第1题问“数据库系统的核心是”选项B数据库管理系统是唯一正确答案。这里必须划重点很多初学者误以为“数据库”本身即存储数据的文件集合是核心但实际运行中所有增删改查、事务控制、并发调度、安全校验全由DBMS这个软件层完成。比如你执行INSERT INTO Student...DBMS要先校验主键约束第10题D选项能插入正是因为Sno和Sname满足NOT NULL、再检查外键引用第1题隐含的参照完整性、最后写日志第17题提到的日志文件。没有DBMS数据库文件只是一堆无法被安全访问的二进制垃圾。这解释了为什么第16题强调事务隔离性——DBMS必须保证T1读A100时T2的AA-8写回不能干扰T1的后续操作这是靠锁管理器第18题S锁和事务调度器协同实现的。-- 模拟第10题建表语句注意PRIMARY KEY和NOT NULL的强制约束 CREATE TABLE Student( Sno CHAR(4) PRIMARY KEY, -- 主键唯一且非空插入时必须提供值 Sname CHAR(8) NOT NULL, -- 非空Sname字段不允许NULL但Sex/Age可为空 Sex CHAR(2), -- 允许NULL对应D选项中SexNULL的合法性 Age INT -- 允许NULL对应D选项中AgeNULL的合法性 );提示执行此建表后尝试插入A选项(5021,刘祥,男,21)会失败——因为男未加引号SQL解析为列名而非字符串字面量B选项NULL,刘祥,NULL,21违反主键约束C选项(5021,NULL,男,21)违反Sname NOT NULL约束。只有D选项满足所有约束条件。2.2 数据独立性物理与逻辑独立性的本质差异决定你改表结构时会不会“炸掉”业务系统第4题考物理独立性用户程序与磁盘数据分离第5题考逻辑独立性应用程序与数据逻辑结构分离。这两者常被混淆但实际影响天壤之别。物理独立性意味着DBA可以更换存储引擎如从InnoDB切到RocksDB、调整页大小、甚至迁移到分布式存储只要DBMS接口不变应用代码完全无感而逻辑独立性则依赖“模式/外模式映像”第5题答案A当DBA把Student表拆成Student_Info和Student_Contact两个表时只需修改视图定义第2大题第4小题的VIEW6就是典型外模式原有查询SELECT * FROM Student仍能运行。这解释了为什么第2题选C数据冗余度大是错误特点——现代DBMS通过规范化第13/14题涉及的范式理论和索引第2大题第3小题的UNIQUE INDEX主动压制冗余而非放任它存在。2.3 关系代数与SQL映射从R∩S到S-(S-R)看透集合运算背后的执行代价第8题R∩S等价于S-(S-R)这不是数学游戏而是优化器的真实工作逻辑。假设R有100万学生选课记录S有10万门课程信息R∩S需遍历R中每条记录查S是否存在匹配而S-(S-R)先算S-R10万门课减去R中已选的课程再用S减去这个结果——实际执行时数据库会自动选择哈希连接或排序合并但底层仍是集合差运算。第9题全外联接FULL OUTER JOIN的选项A直指现实痛点学校教务系统必须同时展示“未分配宿舍的学生”和“空床位”若用左联接B会漏掉空床位右联接C会漏掉未住宿学生。这种需求在ERP系统库存模块中极为常见——既要显示“有库存但未销售的商品”也要显示“已下单但仓库缺货的订单”。3. 填空题与简答题10个空格3道问答精准定位你对数据库“肌肉记忆”的薄弱环节3.1 基础概念填空每个空都是数据库设计的“宪法条款”填空题第1空“关系数据模型由关系数据结构、关系操作和______三部分组成”答案“关系完整性约束”看似简单但实操中90%的线上故障源于此。比如第10题建表时定义PRIMARY KEY本质就是声明主码完整性约束第11题授权语句GRANT UPDATE(QTY) ON SPJ TO 李勇则是通过权限约束控制数据修改边界。第5空“候选码是A和B,C”直接关联第5大题范式分解——当函数依赖A→B,A→C,A→D,(B,C)→A存在时A和(B,C)都能唯一标识元组但(B,C)→A导致A部分依赖于(B,C)破坏BCNF第5大题第1小题结论。这揭示了一个血泪经验设计表时若发现某属性能被多个属性组合推导出来立刻警觉可能存在冗余或更新异常。填空题序号答案关联实战场景参数/配置要点第2空属性自然连接NATURAL JOIN要求表间有同名同类型列若两表均有id列但类型不同INT vs VARCHAR自然连接会失败需显式指定ON条件第3空CREATE UNIQUE INDEX Stusname ON student(Sname)用户名去重场景避免注册重复姓名UNIQUE确保Sname列无重复值ON student(Sname)指定索引字段索引名Stusname便于后续DROP INDEX第4空NOT IN查询“未购买商品的客户”时常用但NULL值会导致结果为空若子查询返回NULL!ALL和NOT IN均失效应改用NOT EXISTS第6空命名冲突不同部门设计的E-R图中“员工编号”可能被命名为emp_id或staff_no合并分E-R图时需统一命名否则转换关系模式会产生歧义3.2 简答题3道题直击DBMS最脆弱的三个“神经节点”第1题“参照完整性规则”本质是外键约束的法理依据。现实中删除父表记录前若不处理子表关联数据就会触发ON DELETE CASCADE或RESTRICT策略MySQL默认RESTRICT。第2题“视图作用”中的第4点“安全保护”对应第11题授权粒度——给财务人员只授UPDATE(QTY)权限而非整个SPJ表这是最小权限原则的落地。第3题“登记日志文件原则”先写日志后写库是崩溃恢复的基石。想象一下T1执行UPDATE EMP SET SALARY1200 WHERE ENOE001若先改数据库再写日志断电后新工资值丢失且无日志可回滚反之日志中已记录“将E001工资改为1200”重启后DBMS按日志重做REDO即可恢复。4. 设计题4道SQL1道范式分解暴露你在真实业务场景中写SQL的“手抖时刻”4.1 多表关联查询从“张三没选的课”到“供应相同商品的商店”练就SQL思维肌肉第1题SQL查询SELECT CNO FROM C WHERE CNO NOT IN (SELECT CNO FROM S,SC WHERE S.SNOSC.SNO AND SNAME张三)表面是求补集实则考验对NULL的敏感度。若子查询结果含NULL如SC表中某记录SNO为NULLNOT IN会返回空集——这是线上SQL最隐蔽的坑。正确写法应为-- 更健壮的写法用LEFT JOIN IS NULL替代NOT IN SELECT C.CNO FROM C LEFT JOIN ( SELECT DISTINCT SC.CNO FROM S JOIN SC ON S.SNO SC.SNO WHERE S.SNAME 张三 ) AS T ON C.CNO T.CNO WHERE T.CNO IS NULL;第2题第2小题“找供应相同商品的商店”是典型的集合包含Containment问题。NOT EXISTS嵌套三层的写法题干答案虽正确但性能极差。生产环境应改用GROUP BY HAVING COUNT-- 高效解法统计各商店供应的商品数与256号商店对比 SELECT A.ANAME, A.CITY FROM A JOIN AB ON A.A# AB.A# WHERE AB.B# IN ( SELECT B# FROM AB WHERE A# 256 ) GROUP BY A.A#, A.ANAME, A.CITY HAVING COUNT(DISTINCT AB.B#) ( SELECT COUNT(DISTINCT B#) FROM AB WHERE A# 256 );4.2 范式分解实战从1NF到BCNF的“手术刀式”拆解拒绝纸上谈兵第5大题第2小题要求将R(A,B,C,D,E)分解为BCNF。题干给出函数依赖ABC→DE, BC→D, D→E我们一步步拆找候选码因ABC→DEABC能推出全部属性且无更小子集满足故ABC是候选码检查1NF关系R已是平面表满足检查2NF非主属性D,E对候选码ABC存在部分依赖BC→D中BC是ABC真子集故R∉2NF消除部分依赖按BC→D拆出R2(BC,D)剩余R1(ABC,DE)检查R2BC为候选码D→E不在R2中但R2中BC→D是完全依赖满足BCNF检查R1函数依赖变为ABC→DE但D→E在R1中仍存在传递依赖ABC→D→E需进一步拆消除传递依赖按D→E拆出R22(D,E)剩余R21(ABC,D)。最终得到R1(ABC)、R21(BC,D)、R22(D,E)三个BCNF关系。关键洞察每次分解都要验证新关系的函数依赖集不能简单按依赖左边分组——比如若错误地按ABC→DE拆出R(ABC,DE)R中仍存在D→E传递依赖未达BCNF。5. 综合题与避坑指南E-R建模到关系模式的“最后一公里”以及95%考生栽倒的5个深坑5.1 E-R图到关系模型从“工厂-产品-职工”业务语义读懂数据库设计的底层契约第5大题综合题描述“工厂生产多种产品产品可在多个工厂生产”明确是m:n联系“职工只能在一个工厂工作”是1:n联系。E-R图中必须体现工厂与产品间“生产”联系带属性“计划数量”因多对多联系需独立成表工厂与职工间“聘用”联系带属性“聘期、工资”1:n联系可合并到职工表实体工厂、产品、职工的主码分别为工厂编号、产品编号、职工号。转换后的关系模式工厂(工厂编号,厂名,地址)主码工厂编号产品(产品编号,产品名,规格)主码产品编号职工(职工号,姓名,工厂编号,聘期,工资)主码职工号外码工厂编号引用工厂表生产(工厂编号,产品编号,计划数量)主码(工厂编号,产品编号)外码分别引用工厂和产品表。注意题干要求“1:1和1:n联系进行合并”故聘用联系不单独建表而将工厂编号作为职工表的外键——这正是外键约束的典型应用场景确保职工记录必属某个有效工厂。5.2 避坑指南那些让阅卷老师皱眉、让线上服务宕机的致命细节现象第10题插入元组时选A选项(5021,刘祥,男,21)报错原因SQL中字符串字面量必须用单引号包裹男未加引号被解析为列名导致语法错误解决改为(5021,刘祥,男,21)或使用标准SQL的CAST(男 AS CHAR(2))现象第11题授权语句写成GRANT QTY ON SPJ TO 李勇被扣分原因权限对象名李勇是标识符不应加单引号加引号后变成字符串字面量DBMS找不到该用户解决严格按GRANT UPDATE(QTY) ON SPJ TO 李勇书写用户名不加引号现象第2大题第2小题用NOT IN写“供应相同商品”查询结果为空原因子查询SELECT B# FROM AB WHERE A#256若返回NULL如256号商店无商品NOT IN逻辑失效解决改用NOT EXISTS或LEFT JOIN ... IS NULL或在子查询中加WHERE B# IS NOT NULL现象第5大题范式分解后R21(BC,D)的函数依赖写成BC→D但未说明BC是候选码原因BCNF定义要求“每个非平凡函数依赖的决定因素必须是超码”仅写BC→D不证明BC是候选码解决需验证BC是否能推出全部属性本例中BC仅推出D故R21中BC是候选码现象第3大题简答题“登记日志原则”只答“先写日志后写库”未提“按时间序登记”原因并发事务日志若乱序崩溃恢复时无法确定操作先后导致数据不一致解决必须强调两条原则缺一不可日志序列号LSN是DBMS保证顺序的核心机制6. 从“抄答案”到“建能力”用这套题反向构建你的数据库知识图谱附赠3个验证技巧这套题最大的价值不是让你记住“第7题主码是车次日期”而是教会你用题干信息反推设计原则。比如看到第7题“列车运营”实体含车次、日期、实际发车时间等属性立刻启动三步验证第一单属性车次能否唯一标识否同一车次每天运行第二单属性日期能否唯一标识否多车次同日运行第三车次日期组合能否唯一是G101次2024-06-01只运行一次。这个过程就是ER建模中“识别实体-确定主码”的标准流程。再如第19题并发操作图不要只背“丢失修改”而要动手画时间轴T1读A100→T2读A100→T1写A95→T2写A92最终A92而非95这就是丢失修改的具象化。我一般会用三个技巧验证自己是否真正掌握逆向命题把第14题“设计关系模式是逻辑设计阶段任务”改成判断题“物理设计阶段才确定关系模式”然后解释为何错误——物理设计关注索引、分区、存储参数关系模式已在逻辑设计中固化场景移植将第5大题“工厂-产品-职工”模型迁移到电商场景“店铺-商品-用户”此时“用户收藏商品”是m:n联系必须建收藏表而非简单在用户表加商品ID数组错误注入故意在第10题建表语句中删掉PRIMARY KEY然后执行D选项插入观察是否允许重复Sno——这能直观感受主键约束的强制力。从那以后我每次审数据库设计文档都强制走一遍“主码验证→范式检查→外键追溯→日志策略确认”四步哪怕只是看别人写的DDL。因为这套题早已不是试卷而是刻在脑子里的检查清单。希望帮到你。本文还有配套的精品资源点击获取