简介面向数据库初学者的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:1不建并入任一端班级与班主任1:N不建并入 N 端系与学生M: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 图的阶段就避免掉。希望你做这套题时也能建立起同样的反射画图之前先列实体画完图先过自检转表之后再看范式。这一套流程走顺了数据库设计的地基就稳了希望帮到你。本文还有配套的精品资源点击获取
简介面向数据库初学者的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:1不建并入任一端班级与班主任1:N不建并入 N 端系与学生M: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 图的阶段就避免掉。希望你做这套题时也能建立起同样的反射画图之前先列实体画完图先过自检转表之后再看范式。这一套流程走顺了数据库设计的地基就稳了希望帮到你。本文还有配套的精品资源点击获取
