企业官网建设流程全解析

简介：面向数据库初学者的ER图专项练习PDF，以十余道典型习题串联数据库概念模型设计训练，适合期末备考、考研复习或入职前夯实基础的人群。资源为单个PDF文档，大小仅83KB，页面紧凑、便于打印或手机随时翻阅。习题覆盖商业运营、物流管理、教育、旅游、医疗、金融、证券等业务场景，包含仓库-商店-商品、车队-司机-车辆、银行储蓄、体育锦标赛、超市公司、大学系学生、货运公司、人事管理、住院管理、电脑销售、证券营业等经典案例，这些案例便于横向对比不同业务场景的建模差异。每道题均给出实体、属性与联系的详细解析，帮助理解一对多、多对多、三元联系等建模要点。已有2311人学习下载，适合对照教材逐题演练，在案例中锻炼从需求到ER模型的转换能力，提升数据库设计水平。

1. 数据库ER图习题不是画图，是练“把题目翻译成表结构”的本事

数据库ER图习题这份材料，表面看是让你画矩形、椭圆、菱形，实际上考的是把一段中文业务描述翻译成表结构的能力。我见过太多人把 ER 图画得漂亮，一到“转关系模式”就卡住：主键不知道选谁，外键不知道往哪放，多对多关系更是直接加字段硬凑。这里头的关键不是“会画图”，而是“会做选择题”——每一步都在回答：这是个实体还是个属性？这俩对象是一对多还是多对多？这个联系需不需要单独建表？把这几个问题练成本能，数据库设计才能真正落地到建表。这篇笔记按“三要素建模 → 解题步骤 → 关系模式转换 → 踩坑位 → 范式终检”的顺序，带你把这本习题的价值榨干净。适合准备数据库考试、正在做课程设计、或者想补建模基本功的开发者。

2. 先从三要素下手：实体、属性、联系的判定与表示法

2.1 看懂ER图的标准语法：矩形、菱形、椭圆各管什么

ER 图中三个基本符号每个都有明确分工，先把它背死：实体用矩形，属性用椭圆，联系用菱形。实体是“客观存在的对象”，比如学生、课程、教师；属性是“实体的特征”，比如学号、姓名、课程号；联系是“实体之间的业务关系”，比如“选修”“授课”“借阅”。我每次带新人，第一步永远是让他们把图例抄一遍，因为后面的所有判断都建立在“符号不要用错”上。

主键属性的标法是属性名下加下划线，这在习题里几乎必考。弱实体用双线矩形表示，它不能独立存在，必须依赖另一个实体，比如“订单项”依赖“订单”而存在。派生属性用虚线椭圆，比如“年龄”可以从“出生日期”推算出来，习题里如果出现派生属性，转关系模式时通常不需要单独建列。还有复合属性，比如“地址”由“省、市、街道”组成，有些习题要求展开成子属性，有些则允许整体当属性，具体看题目问的是“概念模型”还是“逻辑模型”。

这里有一个实用的符号速查表，做习题前先对照一遍：

很多初学者画图时把“选修”这个联系直接当一个实体画两个矩形，再用一根线连起来，这是符号层面的翻车。联系和实体最大的区别是：实体有独立的主键和自己的属性，联系是对两个实体关系的描述，本身不拥有业务主键（除非是 M:N 联系且带属性）。记不住概念的时候，就追问一句：这个东西离开关联的两边还能单独存在吗？能单独存在是实体，只能是中间关系是联系。

2.2 实体还是属性？六成初学者在第一问就翻车

习题里最经典的一道“实体还是属性”选择题，是“学生的地址”。如果按字面理解，地址是学生的一个特征，看起来该画成属性；但题目如果补充说“一个学生有家庭地址和学校地址，且要根据城市统计学生人数”，那地址就不再是简单属性，而是需要单独建模的对象。判断标准只有三条：第一，这个对象是否还拥有自己的属性；第二，是否会被多个实体引用；第三，是否需要按它的内部成员做查询或统计。三条里命中任意一条，就该考虑提升为实体。

另一个高频考点是“多值属性”。学生的联系电话可能有两个：手机号和座机号。概念模型里，如果只画一个“电话”椭圆，转关系模式时会发现一列存不下两个号码，强行用逗号拼接会让后续查询痛苦。规范做法是单列出来一张电话表，或者在 ER 图上用双线椭圆表示多值属性。做过几道题之后你会发现，这类题考的其实是你对“每一列不可再分”这句话的理解程度。

我在陪某高校同学复习时遇到过一个真实场景：她把“班级”画成学生的属性，后来题目补充“每个班级有班主任、有教室”，这时候班级必须变成实体，否则班长、教室这些信息无处安放。所以做习题时养成一个习惯：读到题干里“某对象有……，还要记录它的……”结构，立刻警惕——这多半是在暗示你要把名词提升为实体。实体和属性的边界不是固定语法，而是业务需要，这是 ER 图习题和纯语法题最大的区别。

2.3 一对多与多对多：读题干时找准基数词

联系的基数判断是 ER 图习题的第二个重灾区。题干里通常有明确的量词线索：说“一个系有多个学生，一个学生只属于一个系”，这是 1:N 联系；说“一个学生可以选多门课程，一门课程可以被多个学生选”，这是 M:N 联系；说“一个班级只有一个班主任，一个班主任只带一个班级”，这是 1:1 联系。做题时我习惯把题干中的“每”“各”“只”“多”圈出来，先写两句话，再用箭头标基数，这样能减少漏判。

除了基数，还要注意“参与约束”。部分参与和完全参与在习题里常被一句话带过，比如“每个学生都必须选课”表示学生完全参与选课联系；“教师可以不带课”表示教师部分参与授课联系。ER 图上完全参与用双线连接，部分参与用单线。这个约束直接影响转关系模式时外键列要不要加 NOT NULL：完全参与的一方，其外键列必须非空；部分参与的一方则允许为空。我见过不少人在这一步丢分，因为画图时没标双线，转表时也没有对应的非空约束，习题答案自然对不上。

“联系本身带不带属性”也是判分点。选课这个联系通常会带“成绩”属性，借书联系带“借书日期”。带属性的联系如果恰好是 M:N，转关系模式时要单独建一张中间表，联系属性就作为中间表的普通列；如果是一对多联系带属性，可以把属性并入 N 方实体。判断口诀：联系带的属性越多，越倾向于独立建表，否则容易造成数据冗余。

3. 拿到一道练习题：从原题文本到草图的完整拆解步骤

3.1 五步拆题法：名词、动词、量词、属性、主键

做 ER 图习题我不建议直接上手画图，而是按固定顺序做信息提取。第一步，通读题干，把所有名词抄出来，名词是实体和属性的候选池。第二步，给名词分类：能独立存在、有自己特征的是实体；依附实体、没有下一级特征的留作属性；出现“编号”“名称”“时间”这类词，优先当属性考虑。第三步，找动词，动词往往对应联系，比如“选修”“讲授”“存放”“属于”。第四步，把每个动词两边各是哪个名词写清楚，再用量词确定基数。第五步，回头给每个实体补属性，圈出主键。

这五步看起来啰嗦，但能有效避免“画到一半发现漏了实体”的返工。具体操作时可以用一张草稿纸分成三栏，分别写实体候选、属性候选、联系候选，全部理完再画图。有经验的做题者还会在题干上做标记：下划线画实体，波浪线画属性，圆圈圈联系，这样 E-R 图上的元素在原文里全部有出处，检查时可以对号入座。

下面用一个模拟题完整走一遍。题干是：“某高校开展实验室预约。教师可预约实验室的某个时段，每个时段只能被一位教师预约；实验室信息包括编号、位置、可容纳人数；教师信息包括工号、姓名、职称。预约成功后需记录预约用途和预约时间。”按五步法：名词有教师、实验室、时段、编号、位置、人数、工号、姓名、职称、用途、时间。其中编号、位置、人数是实验室的属性，工号、姓名、职称是教师的属性，用途和时间是联系属性。动词“预约”连接教师和实验室，每个时段只对应一个教师，但一个教师可以预约多个时段，所以是 1:N 联系，N 端是“预约记录”。

3.2 一张“实验室预约”题的完整演练：从实体清单到关系模式

上题的实体与属性可以整理成这样一张表，画图时照此落笔：

这里的关键判断在“时段”。题目说“每个时段只能被一位教师预约”，说明时段不能独立存在，它由实验室和时间共同确定，本质上是预约记录的组成部分。如果题目没有要求对时段单独管理，就不必为它单独建实体；如果题目后面还有“按时段统计使用率”这种需求，那就把时段提升为实体。这就是 ER 图建模里的“需求决定模型，模型跟着查询走”。

转换成关系模式时，按照 1:N 联系的通用做法：把 1 方（实验室）的主键“实验室编号”并入 N 方（预约记录），同时把教师主键“工号”也并入预约记录，因为预约记录本质上是教师在某个实验室的预约行为，它需要引用双方。最终得到三个关系模式：

• 教师（工号，姓名，职称）
• 实验室（实验室编号，位置，可容纳人数）
• 预约记录（工号，实验室编号，预约时间，预约用途）

注意预约记录的主键不能只用工号或实验室编号，必须用“工号 + 实验室编号 + 预约时间”联合做主键，否则一位教师在一段时间内多次预约实验室，会产生重复主键。这一条在答案里非常容易丢分，却是批改评分时最常见的扣分点。

3.3 画完草图的自检七问：别急着转关系模式

画完 ER 图先别着急写关系模式，花两分钟过一遍自检清单。第一问：每一个实体是否都有主键？第二问：每一个联系是否标了基数？第三问：完全参与的一方是否画了双线？第四问：联系附带的属性有没有挂错位置？第五问：多值属性是否有独立表示？第六问：弱实体是否标了双矩形并确认了标识符？第七问：题干里的每个名词是否都在图上有落脚点？

这七问专门针对阅卷中的高频扣分项。第七问尤其有效：把题目原文放在旁边，一个词一个词地核对，凡是没在图里出现的名词，要么是属性漏了，要么是实体漏了，总有一方缺位。我和身边同事平时评审新人设计稿也是这么查的，对着需求文档查模型，比对着模型猜需求可靠得多。画图这件事没有玄学，全是查缺补漏的功夫。

4. ER图转关系模式：四条规则与一张建表SQL的落地过程

4.1 四条转换规则对照：联系类型决定表的去留

ER 图转关系模式是习题册后半部分的固定题型，规则其实就四条。实体独立转成一张表，属性转成列，主键转成主键。1:1 联系可以选择并入任意一端，把另一端的主键作为外键放过来。1:N 联系必须把 1 方的主键并入 N 方作为外键，方向反了就出问题。M:N 联系必须单独建一张关系表，表中包含双方主键作为联合主键，联系自带的属性放在这张表里。

用表格把这四条整理清楚，配合习题对着查：

这条规则的反面教训我也见过：有人在 1:N 联系里把外键放到了 1 方，结果一个系下面有几百个学生，系表里就要存几百个学号，这表根本没法用。所以判断外键方向时记住一句话：外键永远放在“多”的这一边，谁的数量大，谁承接外键。

4.2 用“学生选课”这道典型题走一遍SQL落地

“学生选课”是每本数据库ER图习题里都绕不开的经典题。题干通常是：学生有学号、姓名、性别，课程有课程号、课程名、学分，一名学生可选多门课程，一门课程可被多名学生选修，选课后记录成绩。按转换规则，学生和课程分别建表，选课是 M:N 联系，必须建选课表，成绩放在选课表里。最终关系模式如下：

CREATE TABLE student ( student_id VARCHAR(20) PRIMARY KEY, name VARCHAR(50) NOT NULL, gender CHAR(1) CHECK (gender IN ('M', 'F')) ); CREATE TABLE course ( course_id VARCHAR(20) PRIMARY KEY, course_name VARCHAR(100) NOT NULL, credit DECIMAL(3,1) NOT NULL ); CREATE TABLE sc ( student_id VARCHAR(20) NOT NULL, course_id VARCHAR(20) NOT NULL, score DECIMAL(5,2), PRIMARY KEY (student_id, course_id), FOREIGN KEY (student_id) REFERENCES student(student_id), FOREIGN KEY (course_id) REFERENCES course(course_id) );

这段 SQL 的每个设计点都对应 ER 图上的一个选择。选课表的主键是“学号 + 课程号”联合主键，这正是 M:N 联系单独建表的标志性写法；成绩字段允许为空，因为学生选课后不一定马上有成绩，这是把部分参与约束落到了列上；两个外键分别引用学生表和课程表，保证不会插入不存在的学号或课程号。如果 ER 图上标了“每个学生选课后必须有成绩”，那把 score 改成 NOT NULL 即可，这正好体现了 ER 图设计对建表语句的直接影响。

参数选择也值得留意：student_id 用 VARCHAR(20) 而不是数字，因为学号通常带前导零，用 INT 会丢格式；credit 用 DECIMAL(3,1) 是因为学分常见 1.5、2.0 这类小数；score 用 DECIMAL(5,2) 支持百分制带两位小数。这些细节不是 ER 图的考点，但建表落地时是基本功，习题做完不妨顺手把 SQL 写出来验证一遍设计是否可行。

4.3 主键和级联删除：两个一旦选错代价很高的点

主键选择在转关系模式时最容易出问题。特别是 1:N 联系产生的表，比如“订单”和“订单项”，如果把订单项的主键单独设成“订单项编号”，而没包含“订单编号”，则无法保证同一订单下的子项唯一；规范做法是把“订单编号 + 订单项序号”作为联合主键，同时订单编号做外键。做题时判断主键的标准很简单：找出能唯一确定一行记录的最少字段组合，并且这个组合里的每个字段在业务上都有存在意义。

外键上的级联删除也要想清楚。学生选课表的外键一般不加 ON DELETE CASCADE，因为删除学生时连带删掉选课记录可以接受；但如果删除课程时把选课记录也级联删了，可能导致成绩数据整体丢失。更稳妥的做法是 ON DELETE RESTRICT，让删除操作在还有选课记录时被阻止，由业务层决定如何处理历史数据。习题虽然很少直接考级联选项，但面试或实际建表时这是高频追问点，把“为什么不用 CASCADE”的逻辑讲清楚，比单纯写对 SQL 更显功底。

5. 数据库ER图习题里的5个高频踩坑位：现象、原因、解决

5.1 把地址、电话这种对象画成实体，白多一张冗余表

现象：ER 图画出了一堆“地址”实体和“电话”实体，转关系模式时每个都单独建表，结果学生表里除了地址冗余重复，还多出一堆几乎没用的关系表。原因：初学者判断实体与属性时只看“这个名词是不是客观存在”，忽略了“它有没有独立属性和被引用的必要”。解决：复习实体/属性判断三问——自己有没有属性？是否被多方引用？是否要独立查询？三条都不满足就画属性，不要为了“画得全”而过度建模。

5.2 多值属性被当成普通属性，后续查询没法写

现象：学生有两个电话，建模时只画了一个“电话”椭圆，转换为学生表的一列，数据插入时只能把两个号码拼在一个字段里，后续按号码查询时只能靠 LIKE，索引形同虚设。原因：没有识别“一个学生可以有多个电话号码”这一多值语义。解决：在两个场景里做选择——电话变化频繁且需要独立查询，就拆出一张电话表；如果题目没说明多值，按单值属性处理。做题时看到“至少两个”“多个”字样，多值属性基本跑不了。

5.3 M:N 联系只画线不建表，关系模式里塞外键

现象：学生与课程之间只画了一条菱形连线，没单独建选课表，转关系模式时把课程号塞进学生表，结果一个学生选了 5 门课，学生表里就要存 5 个课程号，数据根本无法规范化。原因：对 M:N 的建表规则理解不深，把关系模式的“联系必须建表”理解成“联系只画线”。解决：M:N 联系单独建表是铁律，不需要犹豫。判断标准：一条线上两个方向都标 N 或 M，就必须有一个中间表。

5.4 弱实体没标双矩形，也没有组合主键

现象：订单项被画成独立实体，转表后只有一个自增编号做主键，删除订单时订单项变成孤儿数据。原因：漏看题干中“订单项从属于订单”“离开订单订单项没有意义”这类表述。解决：弱实体的标准处理是双线矩形表示，主键用“依赖实体的主键 + 部分序号”组合。比如订单项的主键是“订单编号 + 订单项序号”，同时订单编号是外键，这样才能保证订单项在业务上始终依附于订单。

5.5 转换后出现更新异常，说明ER图本身有问题

现象：关系模式写完后进行增删改查演练，发现修改某个教师职称时必须同时更新多行，否则数据不一致；或者删除某门课程时把学生成绩也误删了。原因：ER 图上的联系或属性位置标错，导致转换后的表违背了范式要求。解决：把“更新一条记录应当只影响一行”当检验标准。查课程成绩时，如果发现一个属性出现在多张表中，先别急着调 SQL，回头改 ER 图上的归属，通常是把属性从错误的实体挪到联系上，或者补一张中间表。这里常见的做法是先用 SQL 把候选表结构建出来，插几条测试数据做增删改查，异常自然会暴露。

6. 用函数依赖做终检：比对着答案看范式更靠谱

习题做到后期，我的习惯是每一道转关系模式的题都用函数依赖验证一遍。具体做法：写出候选键后，逐一检查每个非主属性对候选键的依赖关系。以选课表 SC（学号，课程号，成绩）为例，候选键是（学号，课程号），成绩完全函数依赖于这个组合，所以它满足第二范式。如果把成绩放进学生表，就会出现“学号 → 成绩”这种不完整的依赖，因为成绩实际上是学号和课程号共同决定的，这就违背了第二范式，也解释了为什么之前会看到数据冗余。

再往上走一步查传递依赖。比如“班级表（班级编号，班主任，学生人数）”里，如果班主任既依赖班级编号，又依赖“学生人数”所依赖的其他属性，就会产生更新麻烦。实际做题时遇到这种表，直接回 ER 图去查：被传递依赖的属性是不是从某个联系里错误并入的。修改方式通常是把属性移回正确的实体，或者单独建关联表。

我现在的习惯是：拿到一份数据库ER图习题，先花 10 分钟把所有题目里的实体和联系扫一遍，再逐题做五步拆题，画完图不急着对答案，先做第三节的自检七问，转完关系模式再用函数依赖检查范式。这个过程坚持下来，后面做课程设计、真实项目建表时，脑子里的第一反应不是“照抄表结构”，而是先问“这是 1:N 还是 M:N，外键放哪，会不会产生更新异常”。某次 A 同学交课程设计，把“用户关注”画成 1:N，导致取粉丝列表时要遍历整张用户表，我帮他改成 M:N 中间表后，查询量直接降了一个数量级——这种代价，应该在画 ER 图的阶段就避免掉。

希望你做这套题时也能建立起同样的反射：画图之前先列实体，画完图先过自检，转表之后再看范式。这一套流程走顺了，数据库设计的地基就稳了，希望帮到你。

本文还有配套的精品资源，点击获取