简介本资源是一份面向高校数据库课程学习者与备考学生的《数据库原理及应用SQL》配套习题集聚焦数据库核心理论与SQL实践能力训练。内容覆盖ER模型设计、三级模式结构、SQL数据查询与控制语句SELECT/GRANT/REVOKE、事务ACID特性、并发控制机制封锁协议、死锁判断、数据库安全性与完整性约束等关键知识点题型规范、解析完整含42道单项选择题及标准答案便于自测与巩固。资源为单个Word文档.doc大小2.21MB结构清晰、排版工整适合作为课后练习、期末复习或教师组卷参考。目前已有229人下载学习题目紧扣教学大纲涵盖概念辨析、语法应用与原理理解特别适合夯实数据库基础、提升应试能力与工程思维。1. 这不是一份普通习题集它是数据库原理课的“错题本通关 checklist”覆盖 ER 建模、SQL 实战、事务调度、并发控制四大硬核模块专治概念模糊、SQL 写不对、E-R 图画不全、调度死锁理不清你有没有过这种经历上课听懂了范式分解一做设计题就卡在“该不该拆表”背熟了 ACID 四大特性看到“PX 协议”“两段锁”“可串行化调度”还是头皮发麻写 SELECT 时 WHERE 和 GROUP BY 总分不清先后顺序JOIN 写完发现结果多了一倍更别说 PBPowerBuilder窗口事件里 SQLCA.sqlcode100 到底代表什么——是查无此人还是语法错误还是连接断了这份《数据库原理及应用 SQL-习题集含答案》不是那种堆砌定义的教辅它是一线教师用 15 年教学反馈打磨出来的“问题驱动型资源”40 道单选题直击概念混淆点比如第 9 题考 PX 协议下更新前必须先加 X 锁不是 S 锁第 17 题辨析两段锁与可串行化的逻辑关系5 道综合设计题强制你从语义描述→E-R 图→关系模式三步推演第 51 题“销售职工/产品/供应商/订货人”四实体交叉关联稍不留神就漏掉“订购”这个弱实体30 道 SQL 编程题覆盖真实业务场景统计北京供应商、更新零件属性、建存储过程查零件详情甚至包含 PowerBuilder 窗口级交互逻辑第 61 题登录验证、第 65 题数据未保存拦截。它不讲“应该学什么”只问“你能不能当场写出正确 SQL”“你画的 E-R 图能否无歧义转成带主外键的关系表”——这才是数据库原理课真正的验收标准。适合正在备考期末/考研、刚接手数据库课程设计、或需要快速补全 SQL 实战手感的从业者。2. 从单选题开始建立概念锚点用 40 道题把 ER 模型、三级模式、事务特性、封锁机制等抽象概念钉进肌肉记忆2.1 单选题不是选择游戏而是概念校准器每道题都对应一个易错认知陷阱这份习题集的单选题设计有明确的教学意图不是为难人而是帮你识别“我以为我懂了”的认知盲区。比如第 2 题“数据库系统的三级模式结构中定义索引的组织方式属于〔 〕”选项是 A.概念模式 B.外模式 C.逻辑模式 D.内模式。很多初学者会选 C因为“逻辑模式”听起来像管结构的但正确答案是 D内模式。原因在于内模式Internal Schema描述的是数据的物理存储细节包括索引类型B树/哈希、存储位置、压缩方式、簇集策略等而逻辑模式即模式/Schema只定义表结构、字段类型、约束不涉及物理实现。再如第 4 题考“物理数据独立性”题干说“物理结构的改变不影响整体逻辑结构”这正是内模式变动比如加索引、换存储引擎而模式不变时应用程序无需修改的体现。这类题强迫你区分“谁管什么”——概念模式管用户视角的数据视图模式管全局逻辑结构内模式管磁盘上怎么存。提示做单选题时别急着看答案先合上文档用一句话解释每个选项为什么对/错。比如第 13 题“实体完整性规则是指关系中〔 〕”正确答案 B主键不允许有空值你要能说出A 错在“空行”是记录级概念完整性规则针对属性值C 错在“空列”指整列为空与主键约束无关D 错在外键允许空值表示可选关联。这种自问自答比单纯记答案管用十倍。2.2 关键概念链用题目串联起 ER 模型→关系模式→SQL 实现的完整闭环习题集把孤立知识点编排成递进链条。第 1 题ER 模型属于概念模型是起点第 26 题E-R 转关系模型的错误表述是深化第 27、33、55 题E-R 图转换发生在逻辑设计阶段是落地。我们以第 6 题和第 37 题为例看这个链条第 6 题“一个供应商可供给多种零件而一种零件可由多个供应商供给”联系是 D多对多。这是 ER 层的直观判断。第 37 题“一辆汽车由多个零部件组成且相同的零部件可适用于不同型号的汽车”联系也是 DM:N。但注意这里隐含了“组成”关系的语义——它不是简单的关联而是强依赖零部件脱离汽车无独立意义这直接影响后续建模M:N 联系必须转化为独立关系表如“生产”表、“订购”表且该表的主键是双方主键的组合外键分别指向原实体表。这个结论在第 51 题答案中得到验证“供给〔产品号供应商号数量〕主键〔产品号供应商号〕 外键产品号供应商编号”。这种“题干语义→E-R 判断→关系表结构→SQL 建表语句”的闭环正是数据库设计的核心能力。单选题在这里的作用是帮你把“多对多必须拆表”从一句口号变成条件反射。2.3 事务与并发控制用调度冲突、锁类型、ACID 属性题构建防御性思维事务部分的题目第 9、16、17、19、20、30、34、36、48、49 题不是考死记硬背而是训练你在并发场景下的预判能力。例如第 16 题“事务依赖图中构成循环则出现〔 〕”答案 A死锁。这要求你理解当事务 T1 等待 T2 释放 R 的锁T2 又等待 T1 释放 S 的锁循环等待形成系统无法自动推进必须由 DBMS 检测并回滚其中一个事务。再如第 30 题“事务 T 已在数据 R 上加了 X 锁则其他事务在 R 上〔 〕”答案 D不能加任何锁。这是排他锁Exclusive Lock的本质——X 锁排斥所有其他锁S 或 X保证写操作独占。而第 34 题考 S 锁共享锁“T 加了 S 锁其他事务可加 S 锁但不可加 X 锁”这解释了为什么多个读操作可以并发但读写/写写必须互斥。这些题共同指向一个实践原则写 SQL 时要预判你的语句会持有什么锁、持有多久、可能阻塞谁。比如 UPDATE 语句默认加 X 锁如果在高并发下单条 UPDATE 涉及大量行就可能成为瓶颈。这就是为什么第 43 题强调“INSERT 和 DELETE”实现数据更新而非 UPDATE因为批量插入/删除可通过分批、加索引优化而 UPDATE 的锁粒度更难控制。3. 综合设计题手把手带你把业务需求翻译成 E-R 图再精准落地为带主外键的关系模式3.1 E-R 图绘制从语义描述中提取实体、属性、联系的三步法综合设计题第 51–55 题是检验你是否真懂数据库设计的试金石。它不接受模糊描述要求你从自然语言中精确剥离出结构要素。以第 51 题“订单管理系统”为例我们拆解其语义识别实体题干明确列出“销售职工”“产品”“供应商”“订货人”共 4 个实体。注意“订单”本身未被列为实体但它隐含在“每次订货有订货日期和数量”中——这是一个典型的弱实体Weak Entity因为它依赖于“订货人”和“产品”才能存在自身无独立标识符主键。提取属性每个实体后跟括号说明如“销售职工有职工号”这里“职工号”是显式主键“”是属性名需补全如“姓名”空白处可能是“电话”“邮箱”等设计时需合理补充。关键点属性必须属于且仅属于一个实体不能跨实体定义。例如“数量”不属于“产品”或“供应商”而属于“订购”这个联系。判定联系类型题干说“每个销售职工可销售多种产品每个产品可被多个销售职工销售”这是典型的 M:N多对多同理“供应商↔产品”“订货人↔产品”均为 M:N。而“销售职工↔订货人”未直接说明但从“每次订货”动作可推断为 M:N一个订货人可多次订货一个销售职工可服务多个订货人。注意E-R 图中联系的“基数”1:1, 1:N, M:N必须严格对应语义。第 19 题单选题就是为此铺垫“每个职员只能属于一个部门一个部门可以有多名职员”从职员到部门是 N:1即“多对一”答案 C。这个“方向性”在画图时极易搞反务必以题干主语为基准。3.2 关系模式转换主键、外键、联系表的生成规则与边界条件E-R 图转关系模式不是机械映射需根据联系类型和约束动态决策。第 51 题答案给出了标准范式实体型 → 关系模式直接转换主键为原实体标识符如“销售职工〔职工号工资〕主键职工号”。M:N 联系 → 独立关系模式必须新建表如“订购〔订货人号职工号产品号时间数量〕”主键为参与实体主键的组合〔订货人号职工号产品号〕每个参与实体主键作为外键引用原表。1:N 联系 → 合并到 N 端如第 52 题“车间只在一个工段中”联系是 1:N工段:N 车间则将工段号作为外键加入“车间”表“车间〔车间号车间名车间领导工段号〕外键工段号”无需新建表。1:1 联系 → 任选一端加外键如第 54 题“每个工程项目属于一个部门”可将部门号加入“工程项目”表或反之。关键避坑点弱实体如“订购”必须有自己的主键且该主键必须包含其所依赖的强实体主键。第 51 题中“订购”主键是〔订货人号职工号产品号〕而非简单加一个“订单号”——因为业务语义上同一订货人、同一职工、同一产品在同一时间的订购是唯一的用自然键更符合范式要求。3.3 关系模式验证用主外键约束反向检查 E-R 图的合理性写完关系模式后要用约束反推 E-R 图是否完备。以第 55 题“企业集团工厂”为例其关系模式包含工厂〔工厂编号厂名地址〕主键工厂编号产品〔产品编号产品名规格〕主键产品编号职工〔职工号工资聘期工厂编号〕主键职工号外键工厂编号生产〔产品编号工厂编号计划数量〕主键〔产品编号工厂编号〕外键产品编号、工厂编号验证逻辑“职工”表有外键“工厂编号”说明 E-R 图中“职工”与“工厂”必有联系且是 N:1多个职工属一个工厂题干“每名职工只能在一个工厂工作”印证此点“生产”表同时引用“产品”和“工厂”且主键为二者组合证明 E-R 图中“生产”是 M:N 联系一种产品可在多个工厂生产一个工厂生产多种产品题干“每一种产品可以在多个工厂生产”完全匹配“生产”表有“计划数量”属性说明该联系是有属性的联系不能简化为外键合并必须独立成表。这种“从模式反推图”的验证能暴露你最初建模时的遗漏比如忘了给联系加属性或误判了联系类型。4. SQL 编程题从基础查询到存储过程覆盖真实开发中 90% 的高频操作场景4.1 基础查询用子查询、JOIN、GROUP BY 解决嵌套业务逻辑SQL 编程题第 56–60 题的难度梯度设计非常务实。以第 56 题“供应商-零件”库为例求供应红色零件的供应商名字SELECT SNAME FROM S WHERE SNO IN ( SELECT SNO FROM SP WHERE PNO IN ( SELECT PNO FROM P WHERE COLOR 红色 ) );这里用了三层嵌套子查询但更优写法是 JOINSELECT DISTINCT S.SNAME FROM S JOIN SP ON S.SNO SP.SNO JOIN P ON SP.PNO P.PNO WHERE P.COLOR 红色;关键点DISTINCT 防止同一供应商供应多个红色零件时重复JOIN 比子查询更易读、DBMS 优化器更易处理。统计每个供应商供应的项目总数SELECT SNO, COUNT(DISTINCT PNO) AS 供应项目数 FROM SP GROUP BY SNO;注意COUNT(DISTINCT PNO)而非COUNT(*)——因为 SP 表中同一供应商对同一零件可能有多个供货记录不同时间/数量我们要的是“供应了多少种零件”不是“供货了多少次”。4.2 数据更新与视图理解 DML 语句的副作用与视图的安全边界第 56 题第 4 小题“把零件 P2 的重量增加 5 公斤颜色改为黄色”UPDATE P SET WEIGHT WEIGHT 5, COLOR 黄色 WHERE PNO P2;参数说明WEIGHT WEIGHT 5是安全的自增写法避免读-改-写竞态WHERE条件必须精确否则批量更新会灾难性。第 59 题第 6 小题“建立健康状况为‘差’的职工的视图”CREATE VIEW bad_health AS SELECT 职工.*, 保健.健康状况 FROM 职工 JOIN 保健 ON 职工.职工号 保健.职工号 WHERE 保健.健康状况 差;注意视图是虚拟表不存储数据但CREATE VIEW语句必须可执行即 JOIN 条件有效、字段存在。此处若“保健”表中某职工号在“职工”表不存在JOIN 会过滤掉视图结果只包含健康状况为“差”且信息完整的职工——这正是视图的筛选价值。4.3 存储过程封装业务逻辑降低应用层耦合第 56 题第 6 小题要求“建立存储过程输入零件编号显示零件详情”CREATE PROCEDURE P_LIST Id CHAR(4) AS SELECT PNAME, WEIGHT, COLOR, CITY FROM P WHERE PNO Id;参数说明Id CHAR(4)是输入参数长度 4匹配 PNO 格式AS后是主体 SQL。调用时EXEC P_LIST P2。对比第 58 题第 6 小题“通过输入学号显示学生选课门数”CREATE PROCEDURE c_count id INT AS SELECT COUNT(DISTINCT C#) AS 选课门数 FROM SC WHERE S# id;关键差异此处id INT是整型因学号为数字COUNT(DISTINCT C#)确保同一课程多次选修只计 1 门。存储过程的价值在于业务规则如“选课门数”定义固化在数据库层应用代码只需传参调用避免各端重复实现逻辑且便于统一审计和优化。5. 避坑指南那些让你调试到凌晨三点的 SQL 和建模陷阱都在这 5 条血泪经验里5.1 现象E-R 图转关系模式后外键约束报错“引用的表不存在”原因建表顺序错误。例如第 51 题中“订购”表有外键订货人号引用“定货人”表职工号引用“销售职工”表。如果你先建“订购”表DBMS 会因“定货人”“销售职工”表尚未创建而拒绝。解决严格按依赖顺序建表——先建所有实体表销售职工、产品、供应商、定货人再建联系表订购、供给。在 SQL 脚本中把CREATE TABLE语句按此顺序排列并用注释标明依赖关系。5.2 现象SQL 查询结果行数远超预期如“统计每个供应商供应项目数”返回 1000 行而非 10 行原因忘记GROUP BY或DISTINCT。例如写成SELECT SNO, COUNT(*) FROM SP;无 GROUP BYDBMS 会返回单行聚合结果所有记录数而非按供应商分组若写成SELECT SNO FROM SP JOIN P ON SP.PNOP.PNO WHERE P.COLOR红色;无 DISTINCT同一供应商供应多个红色零件时会重复出现。解决凡涉及聚合函数COUNT/SUM/AVG且需分组必须配GROUP BY凡需去重优先用DISTINCT而非依赖GROUP BY。养成习惯写完 SELECT立刻检查是否有聚合函数若有下一个念头就是“GROUP BY 哪个字段”5.3 现象PowerBuilder 中sqlca.sqlcode100但 MessageBox 显示“输入的用户或口令错误”实际是数据库连接失败原因sqlca.sqlcode100在 PowerBuilder 中表示“无数据”No Data Found常用于 SELECT 未查到记录但它不是通用错误码。连接失败、语法错误、权限不足等sqlca.sqlcode可能是 -1、-999 等其他值。第 61 题代码if sqlca.sqlcode100 then ...只处理了“用户不存在”一种情况忽略了其他失败可能。解决必须检查sqlca.sqlcode的所有常见值sqlca.sqlcode 0成功sqlca.sqlcode 100SELECT 无结果sqlca.sqlcode 0错误如 -1语法错误-999连接失败正确写法int id SELECT number INTO :id FROM teacher WHERE number :sle_1.text AND password :sle_2.text; IF sqlca.sqlcode 0 THEN // 登录成功 Open(w_main) ELSEIF sqlca.sqlcode 100 THEN MessageBox(警告, 用户名或密码错误) ELSE MessageBox(错误, 数据库错误 sqlca.sqlerrtext) END IF5.4 现象UPDATE 语句执行后数据未变或部分字段被设为 NULL原因WHERE条件不匹配或 SET 子句中字段名拼写错误。例如第 56 题第 4 小题若写成UPDATE P SET WEIGHT WEIGHT 5, COLOR 黄色 WHERE PNO P02;PNO 写错则无记录更新若写成UPDATE P SET WIEGHT WEIGHT 5 ...WIEGHT 拼错则新字段WIEGHT被创建并设为 NULL某些 DBMS 允许原WEIGHT不变。解决执行 UPDATE 前先用 SELECT 验证 WHERE 条件-- 先确认要更新的记录存在 SELECT * FROM P WHERE PNO P2; -- 再执行更新 UPDATE P SET WEIGHT WEIGHT 5, COLOR 黄色 WHERE PNO P2; -- 最后验证 SELECT * FROM P WHERE PNO P2;这是 DBA 的黄金三步法能避免 90% 的误更新。5.5 现象创建视图后SELECT * FROM view_name报错“列名不明确”原因视图定义中 JOIN 了多张表且 SELECT 子句使用了*或未加表别名的同名字段。例如第 59 题视图bad_health若写成SELECT * FROM 职工 JOIN 保健 ...当两表都有职工号字段时SELECT *会返回两个职工号导致列名冲突。解决视图定义中所有字段必须显式指定且同名字段加表别名前缀CREATE VIEW bad_health AS SELECT 职工.职工号 AS 职工号, 职工., 职工.性别, 职工.职务, 保健.保健卡编号, 保健.检查身体日期, 保健.健康状况 FROM 职工 JOIN 保健 ON 职工.职工号 保健.职工号 WHERE 保健.健康状况 差;这样SELECT * FROM bad_health才能明确返回每一列。6. 进阶验证用三类测试法确保你的 SQL 和建模成果经得起生产环境拷问6.1 边界数据测试用极端值验证 SQL 逻辑的鲁棒性写完一道 SQL 题如第 57 题第 3 小题“按出版社编号统计图书种数和平均定价”不要只用正常数据测试。必须构造边界案例空数据出版社编号为“CS”的图书表为空COUNT(DISTINCT 图书分类)应返回 0AVG(定价)应返回 NULL不是 0。验证语句-- 插入空数据测试 INSERT INTO 图书 (图书编号, 书名, 出版社编号, 图书分类, 定价) VALUES (TEST, TEST, CS, TEST, NULL); -- 执行原查询检查 AVG 是否为 NULL SELECT 出版社编号, COUNT(DISTINCT 图书分类), AVG(定价) FROM 图书 WHERE 出版社编号 CS GROUP BY 出版社编号;NULL 值定价字段含 NULLAVG()会自动忽略 NULL但COUNT(*)会计入。确保你理解COUNT(*)计所有行、COUNT(列名)计非 NULL 值、COUNT(DISTINCT 列名)计非 NULL 的唯一值的区别。提示在 MySQL/SQL Server 中AVG(NULL)返回 NULL在 Oracle 中AVG忽略 NULL 是标准行为。无论哪种你的 SQL 都应预期并处理 NULL 结果而不是假设它总返回数字。6.2 事务一致性测试用并发模拟验证 ACID 特性的实际表现第 20、36 题考 ACID但纸上谈兵不如动手验证。以“转账”业务为例虽不在习题集中但原理相通创建简易账户表CREATE TABLE account (id INT PRIMARY KEY, balance DECIMAL(10,2)); INSERT INTO account VALUES (1, 1000), (2, 500);模拟两个并发事务事务 A扣款UPDATE account SET balance balance - 100 WHERE id 1;事务 B入账UPDATE account SET balance balance 100 WHERE id 2;测试原子性在事务 A 执行后、提交前查账户 1 余额是否为 900答案是否定的——未提交事务的修改对其他事务不可见隔离性保证所以查到的仍是 1000。只有COMMIT后余额才真正变更。测试持久性执行COMMIT后杀掉数据库进程再重启余额是否仍为 900这依赖事务日志第 50 题答案 CDBMS 会在重启时重放日志恢复数据。这种小实验花 10 分钟却能让你彻底明白“事务提交前修改不可见”不是理论而是数据库引擎的硬性保障。6.3 E-R 模型反向工程用 SQL DDL 生成 E-R 图检验设计完整性当你完成第 51 题的关系模式可将其转为 SQL DDL数据定义语言再用工具反向生成 E-R 图与自己手绘的对比-- 生成 DDL 示例以“销售职工”和“订购”为例 CREATE TABLE 销售职工 ( 职工号 VARCHAR(10) PRIMARY KEY, 姓名 VARCHAR(20), 工资 DECIMAL(10,2) ); CREATE TABLE 订购 ( 订货人号 VARCHAR(10), 职工号 VARCHAR(10), 产品号 VARCHAR(10), 时间 DATE, 数量 INT, PRIMARY KEY (订货人号, 职工号, 产品号), FOREIGN KEY (订货人号) REFERENCES 定货人(定货人号), FOREIGN KEY (职工号) REFERENCES 销售职工(职工号), FOREIGN KEY (产品号) REFERENCES 产品(产品号) );用开源工具 SchemaSpy 或 MySQL Workbench 导入 DDL自动生成 E-R 图。你会立刻发现“订购”表是否被正确识别为关联表无主键图标而是连线两端外键连线是否指向正确的父表“时间”“数量”等属性是否作为“订购”表的字段而非挂在某个实体上这招是我带学生做课程设计时的后悔药只要 DDL 能跑通反向图就大概率正确如果反向图漏了联系或连错了方向一定是 DDL 的外键定义有误。从那以后我每次交设计稿前都强制走一遍“手绘图→DDL→反向图”闭环再没被导师打回来过。希望帮到你。本文还有配套的精品资源点击获取
