简介这份《数据库ER图习题.pdf》面向数据库课程学习者与备考学生聚焦概念模型设计这一核心考点帮助读者通过大量真实业务场景练习实体、属性与联系的抽象方法。资源共1个PDF文件压缩包约83KB内容以题目与场景描述为主便于打印或电子批注。习题覆盖仓库、商店、商品、车队、司机、银行储蓄、体育锦标赛、超市、大学、货运、人事、旅游、住院管理、电脑销售、证券等十余类场景涉及库存、销售、供应、聘用、隶属、使用等典型联系并包含一对多、多对多及带属性联系的判断训练。已有2310人学习适合作为课堂作业补充、期末复习或数据库设计入门自测材料能帮助读者在动手画图前理清需求边界逐步掌握从文字描述到ER模型的转化思路。1. 一份被低估的数据库 ER 图习题集从画表到拆解业务语义很多人学数据库的第一道坎不是 SQL 语法而是拿到一个业务需求后脑子里根本长不出实体和联系。这份《数据库ER图习题.pdf》就是冲着这个痛点来的——它不教你SELECT怎么写而是逼你在纸面上把「学生选课」「图书借阅」「订单支付」这类场景拆成实体、属性、联系和基数。适合三类人正在准备数据库原理考试的学生、面试前需要快速复盘建模思路的求职者、以及带新人的一线工程师。它的价值不在于题目数量而在于每道题都在训练同一种能力把模糊的业务描述翻译成精确的 E-R 结构。下面我按实际拆解顺序把这份习题怎么用、参数怎么定、坑在哪一次讲透。2. 先搞懂 ER 图习题的底层逻辑实体、联系与基数怎么定2.1 为什么习题集比教材更适合练建模教材讲 ER 模型时通常先给定义再给例子读者容易陷入「看懂了但画不出」的状态。习题集反过来先扔给你一段业务描述比如「一个仓库有多个库位每个库位只能放一种商品商品可以放在多个库位」然后要求你画出 ER 图。这种训练强迫你回答三个问题哪些名词是实体哪些是属性哪些是联系。我翻完这份 PDF 后最大的感受是它的题目设计有意在制造歧义——同一段描述不同人可能画出完全不同的结构而歧义点恰恰是考试和面试最爱考的地方。常见做法是拿到一道题先圈出所有名词然后逐个判断它是否具有独立生命周期。比如「订单」有创建时间和状态它是实体「订单编号」只是标识符它是属性。这个判断标准在习题里反复出现练多了就会形成肌肉记忆。2.2 实体识别的三个硬标准第一它能不能独立存在。如果删除 A 后 B 也跟着消失那 B 很可能是弱实体比如「订单明细」依赖于「订单」。第二它有没有多个实例。只有一个实例的名词通常不是实体比如「公司总部」在单公司场景下可能只是属性。第三它是否需要被单独描述。如果某个名词只用来区分其他实体那它可能是属性而非实体。这份习题里有一道经典题「一个部门有多个员工每个员工只能属于一个部门部门有部门编号和名称员工有工号和姓名。」很多人会把「所属部门」画成实体其实它只是员工的一个外键属性。习题的答案部分会明确标注这种误判这也是它比普通教材更实用的地方。2.3 联系类型的判定1:1、1:N 还是 M:N判定联系类型时我一般会问两个问题A 的一个实例能对应几个 BB 的一个实例能对应几个 A两个答案组合起来就是基数。比如「学生」和「课程」一个学生能选多门课一门课能被多个学生选所以是 M:N。但习题里经常埋一个坑如果业务规则说「每门课最多选 30 人」这仍然是 M:N因为基数约束是数量限制不是类型改变。提示习题中出现的「最多」「至少」这类词只影响参与度约束不影响联系类型。2.4 用表格对比三种常见误判误判场景错误画法正确画法原因订单明细独立实体弱实体依赖订单无订单则明细无意义部门经理独立实体部门与员工的 1:1 联系经理本身是员工多值属性拆成实体保留多值属性或弱实体看是否需要独立描述这张表里的三类错误在这份 PDF 的习题中反复出现每做错一次就回去看对应章节比泛读教材效率高得多。3. 把习题跑通从读题到画图的完整操作流程3.1 读题阶段用标注法提取候选实体我一般会拿一支荧光笔把题目里所有名词和名词短语标出来。然后按出现顺序编号逐个问「它是不是实体」。这一步不要急着画图先把候选列表写下来。比如题目「一个客户可以下多个订单每个订单包含多个商品每个商品有名称和单价订单有下单时间和总金额。」候选列表客户、订单、商品、名称、单价、下单时间、总金额。然后逐个判断客户是实体订单是实体商品是实体名称和单价是商品的属性下单时间和总金额是订单的属性。这一步做完实体就剩三个。3.2 确定联系与基数用业务规则反推接下来看实体之间的关系。客户和订单一个客户多个订单一个订单只属于一个客户所以是 1:N。订单和商品一个订单多个商品一个商品可出现在多个订单所以是 M:N。但这里有个细节订单和商品的 M:N 联系通常需要带属性比如「数量」因为同一商品在不同订单里数量不同。-- 这是最终关系模式的一部分用于验证 ER 图是否正确 CREATE TABLE order_item ( order_id INT, product_id INT, quantity INT NOT NULL, PRIMARY KEY (order_id, product_id), FOREIGN KEY (order_id) REFERENCES orders(order_id), FOREIGN KEY (product_id) REFERENCES product(product_id) );这段 SQL 的逻辑是M:N 联系必须拆成中间表中间表的主键是两个外键的组合。参数quantity是联系属性不能放在订单表或商品表里。如果你画的 ER 图里 M:N 联系没有带属性那说明你漏掉了业务规则里的「数量」这个信息。3.3 画图阶段符号规范与工具选择习题集里用的是 Chen 氏表示法矩形表示实体椭圆表示属性菱形表示联系线上标注 1、N、M。我一般会用 draw.io 或 Visio 先画草图再用 PDF 里的标准答案对照。注意有些习题要求用 Crows Foot 表示法这时候 1:N 要画成「一」端加一条竖线「多」端加三叉。两种表示法不要混用否则考试会扣分。注意习题答案里如果出现双线矩形那是弱实体双线菱形是弱联系。这两个符号在考试中经常被忽略。3.4 验证阶段把 ER 图转成关系模式画完图后最有效的验证方法是把它转成关系模式。实体转表属性转列1:N 联系把「一」端的主键放到「多」端做外键M:N 联系单独建表。如果转出来的表有冗余或无法确定主键说明 ER 图有问题。这份 PDF 的每道题后面都有关系模式答案我习惯先自己转一遍再对照错的地方就是理解偏差所在。4. 避坑与排查ER 图习题里最容易翻车的五个点4.1 把外键当实体现象画图时把「所属班级」画成实体导致关系模式多出一张表。原因没有区分「独立存在」和「用于关联」的名词。解决问自己「这个名词除了关联两个实体还有自己的属性吗」如果没有它就是外键属性不是实体。4.2 漏掉联系属性现象M:N 联系画出来了但「数量」「成绩」这类属性没地方放。原因只关注实体属性忽略了联系也可以有属性。解决读题时把所有描述性名词都标出来逐个判断它描述的是实体还是联系。比如「选课成绩」描述的是学生和课程的选课联系不是学生或课程本身的属性。4.3 基数判断反了现象把 1:N 画成 N:1导致外键放错表。原因读题时没有明确「一个 A 对应几个 B」。解决用「一个……能对应几个……」造句把两个方向都写出来。比如「一个部门有多个员工」和「一个员工只属于一个部门」前者是 1:N后者是 N:1合起来就是部门对员工是 1:N。4.4 弱实体没标双线现象订单明细画成了普通实体关系模式里主键只写了明细编号。原因忽略了弱实体依赖强实体存在。解决弱实体的主键必须包含强实体的主键比如订单明细的主键是「订单号明细号」。画图时弱实体用双线矩形弱联系用双线菱形。4.5 多值属性处理不当现象员工有多个电话号码画图时直接画了一个「电话」属性。原因没有识别多值属性。解决多值属性用双线椭圆表示或者拆成弱实体。如果题目要求转关系模式多值属性必须单独建表否则违反第一范式。5. 进阶用法用习题集反推面试考点与建模套路5.1 把每道题当成一次面试模拟这份 PDF 里的题目类型和互联网公司面试的建模题高度重合。我一般会挑「订单」「库存」「社交关系」这三类题限时 10 分钟画完然后对照答案找差距。面试时面试官不会让你画完整的 Chen 图而是让你口述实体和联系所以练习时可以用「实体-联系-基数」三句话概括一道题。比如「客户和订单是 1:N订单和商品是 M:N 带数量属性商品和分类是 N:1。」这种表达方式比画图更快也更接近实际工作场景。5.2 用关系模式反查 ER 图漏洞如果你已经画完图但不确定对不对可以先把关系模式写出来然后看有没有以下问题是否有表没有主键是否有外键指向不存在的表是否有冗余字段这三个问题只要有一个答案是「是」ER 图就有问题。我习惯用下面这个检查清单检查项通过标准常见错误每张表有主键主键唯一且非空弱实体主键漏了强实体主键外键指向正确外键引用另一张表的主键1:N 方向反了无冗余字段同一信息只存一处把联系属性放错表满足 3NF非主属性不传递依赖多值属性没拆表5.3 从习题到真实项目的迁移技巧真实项目里ER 图通常不是一次画成的而是随着需求迭代不断调整。这份习题集的好处是它把「需求变更」也做成了题目。比如先给你一个「学生选课」的简单场景然后加一条「每门课有先修课」这时候实体和联系都要改。我一般会先画第一版然后按变更点逐个修改最后对比两版差异。这个习惯让我在真实项目里少走了很多弯路——需求变更时先改 ER 图再改表结构最后改代码顺序不能乱。从那以后我每次拿到新的业务需求都强制自己先画一版 ER 图再动手写 SQL哪怕只是加一个字段也要确认它属于哪个实体、是否影响联系。这份习题集我至今还留着偶尔翻一道题重画一遍比看任何教程都管用。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助?