简介这份PPT面向数据库课程学习者与备考人员系统讲解数据库概念设计阶段的核心内容——实体-联系模型与ER图。资源共1个PPT文件压缩包约622KB以幻灯片形式组织便于课堂演示与自学翻阅。内容从信息世界的基本概念切入依次梳理实体、属性、码、域、实体型与实体集等术语并重点展开联系的类型一对一、一对多、多对多结合班级与班长、班级与学生、课程与学生等实例说明映射基数的含义。此外还涵盖两个以上实体型之间的联系、单个实体型内部的联系以及ER图的图形表示方法包括矩形表示实体、椭圆表示属性、菱形表示联系及连线标注联系类型。已有411人学习适合需要理解概念模型建模思路、掌握ER图绘制规范的读者可作为课程复习与作业参考的辅助材料。1. 数据库系统概论里的实体-联系模型为什么它是画 ER 图之前必须啃透的一层很多人第一次翻《数据库系统概论》翻到实体-联系模型这一章会觉得概念太虚——实体、属性、联系、基数考试考完就忘。但真正到了项目里让你给一个业务画 ER 图你会发现卡住你的从来不是画图工具而是脑子里没把业务拆成实体和联系。实体-联系模型Entity-Relationship Model简称 E-R 模型解决的就是这件事在动手建表之前先用一套不依赖任何数据库产品的语言把现实世界的业务对象和它们之间的关系描述清楚。它适合两类人一类是要应付数据库系统概论课程和课后习题的学生另一类是接手新业务、需要先理清数据结构的后端和数据分析工程师。ER 图是这套模型的图形化产物而模型本身才是你判断「这个设计对不对」的依据。画图工具换哪个都行模型想不清楚换什么工具都白搭。2. 实体-联系模型的四个基本构件从业务语言翻译成 ER 图符号2.1 实体、属性、联系、基数到底各自管什么实体Entity是业务里可以被独立识别和区分的对象比如学生、课程、订单、电影。判断一个东西是不是实体有个很实用的标准它能不能被单独拿出来说「这一个」和「那一个」。学生张三和李四是两个不同的实体而「姓名」不是实体它是张三这个实体的一个属性。属性Attribute描述实体的特征。属性分几类画 ER 图时容易混简单属性和复合属性比如「地址」可以拆成省、市、街道单值属性和多值属性一个人可以有多个电话号码还有派生属性比如「年龄」可以由出生日期算出来通常不单独存储。在 ER 图里属性用椭圆表示主键属性在文字下面加下划线。联系Relationship是实体之间的关联。学生和课程之间有「选修」联系电影和用户之间有「评分」联系。联系本身也可以带属性比如「选修」这个联系上有「成绩」「评分」这个联系上有「分数」和「评价时间」。这一点是新手最容易漏的——成绩不属于学生也不属于课程它属于「学生选修课程」这个动作。基数Cardinality描述一个联系中两边实体的数量对应关系常见的有 1:1、1:N、M:N。一个班级有多名学生是 1:N一名学生选多门课、一门课被多名学生选是 M:N。基数判断错了后面建表时外键放哪边、要不要建中间表全都会跟着错。2.2 用一段选课业务把四个构件串起来光看定义记不住拿一段具体业务走一遍。假设要描述「学生选课」这件事学生属性有学号主键、姓名、性别、出生日期课程属性有课程号主键、课程名、学分、开课院系教师属性有工号主键、姓名、职称联系一学生与课程之间是「选修」M:N联系上有属性「成绩」联系二教师与课程之间是「讲授」1:N假设一门课由一位教师主讲把这四个构件摆清楚ER 图的骨架就出来了。接下来才是选工具、画图形。很多人一上来就打开软件拖方框结果画到一半发现联系方向不对、属性挂错了实体返工重来。先在本子上把实体和联系列成文字再上工具能省掉大量返工。2.3 弱实体和依赖联系什么时候需要单独拎出来有一类实体不能独立存在必须依附于另一个实体这叫弱实体Weak Entity。典型例子订单和订单明细。订单明细离开了订单就没有意义它的主键是「订单号 明细行号」这样的组合。在 ER 图里弱实体用双线矩形表示它和所属实体之间的联系用双线菱形表示。判断要不要用弱实体看两点它的标识符是否部分来自另一个实体它是否在业务上不能脱离那个实体单独讨论。订单明细、合同条款、设备维修记录通常都是弱实体。把弱实体识别出来建表时你才知道主键该怎么设计不会傻乎乎地给订单明细单独加一个自增 ID 就完事——虽然加自增 ID 在工程上很常见但你要清楚这是实现层面的选择不是模型层面的必然。3. 从 ER 图到关系模式把图形翻译成能建表的表结构3.1 实体转表、联系转表的通用规则ER 图画完下一步是转成关系模式也就是能直接拿去建表的表结构。转换规则不复杂但每条都要记牢ER 构件转换规则备注强实体转成一张表属性转成列主键保留复合属性拆成多列弱实体转成一张表主键包含所属实体的主键形成组合主键1:1 联系任选一边加外键或单独建表通常把外键放在参与度低的一边1:N 联系在 N 端加外键指向 1 端不需要单独建表M:N 联系单独建一张联系表主键是两边主键的组合联系上的属性放这张表多值属性单独建表不能直接塞进实体表这张表是转换的核心。拿选课业务套一遍学生表、课程表、教师表各一张「选修」是 M:N单独建一张选课表字段是学号、课程号、成绩主键是学号加课程号「讲授」是 1:N在课程表里加一个教师工号作为外键。3.2 用 SQL 把选课业务的 ER 图落地把上面的转换结果写成建表语句你能直观看到 ER 图每个构件去了哪里-- 学生表对应强实体「学生」 CREATE TABLE student ( student_id VARCHAR(12) PRIMARY KEY, -- 学号主键 name VARCHAR(50) NOT NULL, gender CHAR(1), birth_date DATE ); -- 教师表对应强实体「教师」 CREATE TABLE teacher ( teacher_id VARCHAR(12) PRIMARY KEY, -- 工号主键 name VARCHAR(50) NOT NULL, title VARCHAR(30) ); -- 课程表对应强实体「课程」同时承载 1:N 的「讲授」联系 CREATE TABLE course ( course_id VARCHAR(12) PRIMARY KEY, -- 课程号主键 course_name VARCHAR(80) NOT NULL, credit DECIMAL(3,1), dept VARCHAR(50), teacher_id VARCHAR(12), -- 外键来自「讲授」联系 FOREIGN KEY (teacher_id) REFERENCES teacher(teacher_id) ); -- 选课表对应 M:N 的「选修」联系联系属性「成绩」放这里 CREATE TABLE enrollment ( student_id VARCHAR(12), course_id VARCHAR(12), grade DECIMAL(4,1), -- 联系属性成绩 PRIMARY KEY (student_id, course_id), -- 组合主键 FOREIGN KEY (student_id) REFERENCES student(student_id), FOREIGN KEY (course_id) REFERENCES course(course_id) );这段 SQL 里每个外键都能对应回 ER 图上的一条联系。course表里的teacher_id来自「讲授」这个 1:N 联系放在 N 端enrollment表整体就是「选修」这个 M:N 联系的产物grade是联系属性。参数上要注意组合主键的顺序会影响索引效率一般把选择性高的列放前面外键列的数据类型必须和被引用列完全一致否则建表会报错。3.3 转换时最容易出错的三个判断点第一个判断点联系上的属性到底放哪张表。规则很简单——联系属性跟着联系走。M:N 联系单独建表属性就放这张表1:N 联系不单独建表联系属性就放在 N 端那张表里。很多人把「成绩」放到学生表里结果一个学生选多门课就存不下了。第二个判断点1:1 联系的外键放哪边。如果两边参与度都是全部参与放哪边都行如果一边是部分参与外键放在部分参与的那一边避免出现大量空值。比如「教师」和「教研室主任」是 1:1不是每个教师都是主任外键就放在教师表里。第三个判断点多值属性要不要拆表。一个学生有多个电话号码如果直接在学生表里加phone1、phone2、phone3那第四个号码就没地方放了。正确做法是单独建一张电话表用学号做外键。这个坑在真实项目里非常常见血泪经验就是凡是可能出现「不确定几个」的属性一律拆表。4. 画 ER 图的工具选型和实操从纸笔到 Mermaid 代码4.1 工具选型不同场景用不同工具画 ER 图的工具大致分三类选错了会浪费很多时间纸笔或白板适合需求讨论阶段快速勾勒实体和联系改起来零成本。别小看这一步很多设计问题在纸上就能发现。可视化建模工具适合正式文档和团队评审图形规范、能导出。这类工具适合画完整的、要存档的 ER 图。代码化绘图适合放进代码仓库、跟着版本走。Mermaid 的 ER 图语法就是这一类改一行代码图就更新评审时直接在 PR 里看 diff。我的习惯是讨论用纸笔定稿用可视化工具需要长期维护的用代码化绘图。三者不冲突关键是别在讨论阶段就打开重型工具那会拖慢节奏。4.2 用 Mermaid 语法画一张可版本管理的 ER 图Mermaid 的 ER 图语法很简洁适合放进 Markdown 文档或代码仓库。下面这张图描述的就是前面选课业务的模型erDiagram STUDENT ||--o{ ENROLLMENT : 选修 COURSE ||--o{ ENROLLMENT : 被选 TEACHER ||--o{ COURSE : 讲授 STUDENT { string student_id PK 学号 string name 姓名 string gender 性别 date birth_date 出生日期 } COURSE { string course_id PK 课程号 string course_name 课程名 decimal credit 学分 string teacher_id FK 授课教师工号 } TEACHER { string teacher_id PK 工号 string name 姓名 string title 职称 } ENROLLMENT { string student_id PK,FK 学号 string course_id PK,FK 课程号 decimal grade 成绩 }这段代码里||--o{表示一对多}o--o{表示多对多。PK标主键FK标外键PK,FK表示既是主键又是外键——这正是 M:N 联系转成联系表后的典型特征。参数说明Mermaid 的 ER 图不支持直接画椭圆属性属性写在实体块里用注释字符串补充中文说明。如果你的文档平台支持 Mermaid这段代码可以直接渲染成图如果不支持可以复制到在线编辑器里导出图片。4.3 从现有 MySQL 库反向导出 ER 图如果是接手一个已经存在的数据库想快速看清表之间的关系可以从information_schema里把外键关系查出来再拼成 Mermaid 或其它格式。下面这段 SQL 能列出所有外键约束-- 查询当前库中所有外键关系用于反向生成 ER 图 SELECT TABLE_NAME AS 子表, COLUMN_NAME AS 子表列, REFERENCED_TABLE_NAME AS 父表, REFERENCED_COLUMN_NAME AS 父表列, CONSTRAINT_NAME AS 约束名 FROM information_schema.KEY_COLUMN_USAGE WHERE TABLE_SCHEMA your_database_name AND REFERENCED_TABLE_NAME IS NOT NULL ORDER BY TABLE_NAME;把your_database_name换成你的库名执行后得到一张关系清单。逻辑说明KEY_COLUMN_USAGE记录了所有键的使用情况过滤REFERENCED_TABLE_NAME IS NOT NULL就只剩外键。拿到结果后可以手工整理成 Mermaid 代码也可以写脚本自动生成。注意这种方式只能还原出外键关系还原不出联系上的属性——那些属性在物理表里就是普通列需要你结合业务判断哪些列原本是联系属性。5. 避坑与排查ER 图设计和转换中的五个高频翻车点5.1 把属性当实体或者把实体当属性现象ER 图画出来实体框里塞了一堆本该独立的东西或者反过来一个明显该独立的对象被当成了某个实体的属性。原因没有用「能否独立识别」这个标准去判断。解决拿「这一个和那一个」去套能区分的就是实体不能区分的才是属性。比如「院系」在简单场景下可以是学生的一个属性但如果院系本身有院长、有办公地点、有经费那它就该是独立实体。5.2 联系属性挂错位置现象一个学生选多门课成绩只存了一个或者建表后发现成绩列不知道该放哪。原因把 M:N 联系上的属性挂到了某一端的实体上。解决记住规则——联系属性跟着联系走。M:N 联系单独建表属性放联系表1:N 联系不单独建表属性放 N 端。画图时就把联系属性画在菱形旁边转表时自然知道放哪。5.3 基数判断反了导致外键放错边现象建完表发现查询时要多绕一张表或者出现大量空值。原因1:N 的方向搞反了外键放到了 1 端。解决外键永远放在 N 端。判断方法问「一个 A 对应几个 B一个 B 对应几个 A」多的一方就是 N 端。画图时在连线上标清楚 1 和 N转表时照着标就行。5.4 多值属性硬塞进实体表现象学生表里出现phone1、phone2、phone3业务说最多五个号码结果第六个没地方放。原因图省事把多值属性直接展开成多列。解决多值属性一律单独建表用外键关联回实体表。这样号码数量不受限制查询时用 JOIN 或聚合函数处理。这个坑在真实项目里翻车率极高属于典型的「当时省事、后面还债」。5.5 弱实体主键设计错误现象订单明细表用了自增 ID 做主键结果同一订单下出现重复明细行业务上无法约束。原因没有识别出弱实体主键设计丢了所属实体的标识。解决弱实体的主键必须包含所属实体的主键。订单明细的主键应该是「订单号 行号」而不是单独的自增 ID。如果工程上确实需要自增 ID 做代理键那也要在业务键上加唯一约束保证「同一订单下行号不重复」。6. 进阶技巧用 ER 图反推业务规则以及一套自查清单画 ER 图不只是为了建表它还能帮你发现业务规则里的漏洞。举个例子如果「电影」和「用户」之间有「评分」联系评分上有「分数」属性那你要追问——一个用户对同一部电影能评几次如果业务说只能评一次那这个 M:N 联系的主键就是「用户 ID 电影 ID」分数是联系属性如果能评多次那就要再加一个「评价时间」进主键或者把「评价」升级成一个独立实体。这个追问过程就是 ER 图在帮你把模糊的业务规则逼清楚。我一般会在 ER 图定稿前过一遍下面这张自查清单检查项判断标准不通过时的动作每个实体能否独立识别能用主键区分每一条记录不能区分的降为属性每个联系属性是否挂对位置M:N 放联系表1:N 放 N 端重新判断联系类型基数方向是否正确外键在 N 端画图时标清 1 和 N多值属性是否拆表不存在 phone1/phone2 这类列拆成独立表弱实体主键是否含所属实体主键组合主键包含父实体主键补上父实体主键是否存在冗余联系能由其它联系推导出的联系删掉避免数据不一致这张表我用了很多年每次评审 ER 图都拿出来对一遍能挡掉大部分低级错误。最后一个习惯ER 图定稿后别急着建表先拿几个真实的业务查询去套一遍看能不能顺畅地写出来。如果某个查询要绕三四张表那可能是模型有问题回去改图比改表便宜得多。希望帮到你。本文还有配套的精品资源点击获取