简介这份PPT面向高校数据库课程学习者与备考学生系统讲解数据库概念设计阶段的核心内容——实体-联系模型与ER图。资源以「数据库系统概论」第二章为框架从信息世界的基本概念切入依次梳理实体、属性、码、域、实体型与实体集等术语并重点剖析一对一、一对多、多对多三类联系及映射基数的判定方法同时给出实体用矩形、属性用椭圆、联系用菱形表示的ER图绘制规范。包内共1个PPT文件约622KB内容紧凑、图文并茂适合课堂同步学习或考前快速回顾。目前已有411人学习下载读者可借助它理清概念模型到关系模型的转化思路掌握两个及以上实体型联系、单个实体型内部联系的分析方法为后续逻辑设计与物理设计打下基础。1. 数据库系统概论里的 ER 图从课堂 PPT 到能落地的数据建模很多人第一次接触《数据库系统概论》里的实体-联系模型都是在期末前对着 PPT 死记硬背矩形是实体、椭圆是属性、菱形是联系。考完就忘工作里画表还是拍脑袋。但真实情况是ER 图恰恰是把业务需求翻译成 MySQL 表结构之间最便宜的一道保险。你画错一个基数后面可能就是一张中间表白建、一次联表查询慢到报警。这篇笔记不打算复述教材而是把「实体-联系模型、ER 图」这套东西拆成能动手的路径先用它把需求理清楚再把 ER 图落成建表语句最后讲清楚画图工具怎么选、哪些坑我踩过。适合正在学《数据库系统概论》第六版、要交 ER 图作业的学生也适合工作里需要给一个模块做数据建模的工程师。热词里那些「er图例题」「er图怎么画」「mysql 的表导出 er 关系图」本质都是同一个问题怎么让 ER 图真正服务于建表而不是交完就扔。2. 实体-联系模型到底在建模什么三个符号背后的判断标准2.1 实体、属性、联系不是画法问题是粒度问题教材把 ER 模型拆成实体、属性、联系三件套但真正难的不是记住符号而是判断一个业务概念该做成实体还是属性。我的经验是如果一个东西你需要单独查询它、给它加字段、或者它和别的东西有多对多关系它就该是实体否则先当属性。比如「学生」有「姓名」「学号」姓名是属性因为没人会单独查「姓名」这张表但「班级」在很多场景下要单独管理就该是实体。热搜里「画出电影评分与评价的 er 图」就是典型电影、用户是实体评分是联系带分值属性评价如果只是一段文字可以当联系的属性但如果评价要支持点赞、回复它就得升级成实体。这个判断标准比背符号有用得多。实体用矩形属性用椭圆联系用菱形这是《数据库系统概论》第六版的标准画法。但落到工具里很多软件默认不画椭圆属性而是把属性列在实体框里这叫「陈氏表示法」的简化版。考试时按教材画工作里按工具默认画别纠结。2.2 基数约束1:1、1:N、M:N 决定后面建几张表基数是最容易画错、也最影响建表的地方。判断方法很朴素站在一端问「一个 A 能对应几个 B」再站到另一端问一遍。一个班级有多个学生一个学生只属于一个班级所以班级对学员是 1:N。一个学生选多门课一门课被多个学生选所以是 M:N。这里有个反直觉的点M:N 联系在关系模型里必须拆成一张独立的表而 1:N 联系可以把外键放在 N 那一端不用单独建表。很多新手画完 ER 图直接照着实体数量建表结果 M:N 的联系没地方放只能回头补一张中间表。所以画 ER 图时看到菱形就要顺手标记基数这决定了后面CREATE TABLE写几张。2.3 弱实体和依赖联系什么时候需要双线矩形弱实体是《数据库系统概论》里容易被忽略但工作中很常见的东西。如果一个实体的存在依赖于另一个实体离开对方就没有意义它就是弱实体。比如「订单明细」离开「订单」就不存在订单明细的主键要带上订单号。画法上弱实体用双线矩形依赖联系用双线菱形。判断弱实体的实操标准它的主键里是否包含另一个实体的主键。如果是基本就是弱实体。这个判断直接影响建表时的联合主键设计漏了会导致明细数据无法唯一标识。3. 从需求到 ER 图一套可复现的建模步骤3.1 先列名词再筛实体需求文本处理拿到一段需求不要直接开画。我一般先把需求里所有名词圈出来然后逐个过筛。筛的标准就是 2.1 里说的能独立查询、有自己字段、参与多对多关系的留下当实体其余降级为属性。假设需求是「学生可以选多门课程每门课程有课程号和课程名学生选课后有成绩」。圈出的名词有学生、课程、课程号、课程名、成绩。筛完学生、课程是实体课程号、课程名是课程的属性成绩是「选课」这个联系的属性。这个过程用表格记录最清楚名词判定理由学生实体需独立管理参与多对多课程实体需独立管理参与多对多课程号属性依附课程不单独查询课程名属性依附课程成绩联系属性只有选课发生才有值这张表就是 ER 图的草稿。热搜里「数据库系统概论 er 图例题」大多可以用这个流程拆解先筛再画比直接下笔稳。3.2 用 Mermaid 快速验证 ER 图逻辑正式画图前我习惯用 Mermaid 的 erDiagram 先把结构写出来因为它逼你把基数和属性写清楚改起来也快。Mermaid 的 ER 语法在 GitHub、Typora、VS Code 插件里都能渲染。erDiagram STUDENT ||--o{ ENROLLMENT : 选课 COURSE ||--o{ ENROLLMENT : 被选 STUDENT { string student_id PK 学号 string name 姓名 } COURSE { string course_id PK 课程号 string course_name 课程名 } ENROLLMENT { string student_id FK 学号 string course_id FK 课程号 decimal score 成绩 }这段代码里||--o{表示一对多左边一个学生右边多个选课记录。ENROLLMENT就是 M:N 联系拆出来的中间实体它同时持有两个外键外加联系属性score。PK标主键FK标外键。逻辑说明学生和课程本身不直接相连而是通过选课记录关联这样成绩才有地方放。参数说明decimal用于成绩比float更稳避免浮点误差主键用业务号还是自增 ID考试按教材用业务号生产环境我一般加一个自增id做主键、业务号做唯一索引。提示Mermaid 的 ER 图适合验证逻辑不适合交作业。作业要求椭圆属性、菱形联系时还是得用传统画法。3.3 把 ER 图翻译成 MySQL 建表语句ER 图验证完落成 SQL 才是终点。转换规则固定每个强实体一张表M:N 联系一张中间表1:N 联系在 N 端加外键弱实体用联合主键。-- 学生表强实体 CREATE TABLE student ( student_id VARCHAR(20) PRIMARY KEY COMMENT 学号, name VARCHAR(50) NOT NULL COMMENT 姓名 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 课程表强实体 CREATE TABLE course ( course_id VARCHAR(20) PRIMARY KEY COMMENT 课程号, course_name VARCHAR(100) NOT NULL COMMENT 课程名 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 选课表M:N 联系拆出的中间表 CREATE TABLE enrollment ( student_id VARCHAR(20) NOT NULL COMMENT 学号, course_id VARCHAR(20) NOT NULL COMMENT 课程号, score DECIMAL(5,2) COMMENT 成绩, PRIMARY KEY (student_id, course_id), CONSTRAINT fk_enroll_student FOREIGN KEY (student_id) REFERENCES student(student_id), CONSTRAINT fk_enroll_course FOREIGN KEY (course_id) REFERENCES course(course_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;逻辑说明enrollment的联合主键(student_id, course_id)保证一个学生同一门课只有一条记录这正是 M:N 联系拆表的语义。两个外键约束保证引用完整性。参数说明DECIMAL(5,2)表示最多 5 位、2 位小数够放百分制成绩utf8mb4支持中文和 emojiInnoDB支持外键MyISAM 不支持别选错。如果成绩允许为空选课未出分score不加NOT NULL。3.4 用工具把已有 MySQL 表反向导出 ER 图工作里更常见的是接手一个已有库需要补 ER 图。热搜里「mysql 的表导出 er 关系图」就是这类需求。常见做法是用 MySQL Workbench 的 Reverse Engineer或者用 DBeaver 的 ER 图功能。以 Workbench 为例菜单Database→Reverse Engineer连上库勾选 schema它会自动根据外键生成 ER 图。注意如果表之间没有建外键约束反向出来的图是没有连线的这时候要么补外键要么手动连线。这也是为什么我建议建表时就写外键哪怕生产环境为了性能不启用文档层面也有价值。4. 画 ER 图的工具选型从交作业到团队协作4.1 学生交作业draw.io 和亿图够用如果目标是交《数据库系统概论》的 ER 图作业要求标准陈氏符号draw.io现 diagrams.net最省事。它有现成的实体、属性、联系图形拖出来连线即可导出 PNG 或 PDF 都行。亿图图示的符号库更贴近国内教材但免费版有水印。Rational Rose 是热搜里出现的老工具教材年代常用但现在装起来麻烦除非老师强制要求不建议折腾。判断标准很简单老师要什么符号你就选能画出那个符号的工具别为了工具本身花两小时。4.2 工程团队代码化 ER 图更可持续团队协作里图片版 ER 图最大的问题是会过期。表改了图没改新人照着旧图理解就翻车。我的做法是用代码描述 ER 图跟代码一起进版本库。Mermaid 写在 Markdown 里是一种另一种是用 DBMLDatabase Markup Language配合 dbdiagram.io 渲染。DBML 的好处是语法接近建表语句改起来快。erDiagram USER ||--o{ ORDER : 下单 ORDER ||--|{ ORDER_ITEM : 包含 PRODUCT ||--o{ ORDER_ITEM : 被购买 USER { int id PK string phone } ORDER { int id PK int user_id FK datetime created_at } ORDER_ITEM { int order_id FK int product_id FK int quantity } PRODUCT { int id PK string title decimal price }这段描述了一个电商下单场景。ORDER ||--|{ ORDER_ITEM里的|{表示至少一条即一个订单至少有一个明细这是业务约束的体现。逻辑说明订单明细作为弱实体主键是(order_id, product_id)联合主键。参数说明quantity用intprice用decimal。把这段放进仓库的docs/schema.md谁改表谁改图Code Review 时能一起看。4.3 工具对比按场景选不按热度选工具适合场景是否支持陈氏符号是否代码化draw.io交作业、一次性图支持否MySQL Workbench已有库反向导出否Crows Foot否Mermaid文档内嵌、版本管理否是DBML/dbdiagram团队协作、持续维护否是Rational Rose老教材指定支持否选型逻辑要交作业选支持陈氏符号的要长期维护选代码化的要快速看现有库选反向工程的。三者不冲突可以组合用。5. 避坑ER 图建模里最容易翻车的五个地方5.1 把多对多画成一对多中间表凭空消失现象ER 图上学生和课程直接连了一条线标了 1:N建表时发现一个学生只能选一门课。原因没站在两端各问一次基数凭直觉画。解决每个联系都做双向基数检查M:N 必须拆中间表中间表带两个外键和联系属性。5.2 属性画成实体表数量爆炸现象把「姓名」「性别」都画成独立实体最后建了十几张表联表查询写到崩溃。原因没做 3.1 的名词筛选把所有名词都当实体。解决用「能否独立查询、是否有自己字段、是否参与多对多」三条标准过筛不满足的降为属性。5.3 弱实体主键漏了父实体主键现象订单明细表用自增 id 做主键结果同一订单里出现重复商品行无法区分。原因没识别弱实体主键设计错误。解决弱实体的主键必须包含父实体主键订单明细用(order_id, product_id)或(order_id, line_no)做联合主键。5.4 反向导出 ER 图没有连线现象用 Workbench 反向工程出来的图全是孤立的表没有关系线。原因建表时没加外键约束工具无法推断关系。解决要么补外键要么手动连线长期看建表时就写外键约束文档和工具都能受益。5.5 联系属性放错位置现象把「成绩」放在学生表或课程表里导致一个学生只能有一个成绩。原因没理解联系属性只属于联系本身。解决M:N 联系的属性必须放在中间表里1:N 联系的属性放在 N 端表里1:1 联系看业务频率决定放哪端。6. 进阶用 ER 图驱动一次真实的表结构评审把 ER 图用出价值的关键是让它成为表结构评审的输入而不是作业。我现在的习惯是任何新模块建表前先花二十分钟画一版 Mermaid ER 图贴到评审文档里让产品和后端一起看。评审时只问三个问题基数对不对、弱实体识别了没、联系属性放对位置没。这三个问题能拦掉大部分后期改表的返工。验证 ER 图是否正确有个便宜的办法拿它去套几个真实查询。比如「查某学生所有课程成绩」如果 ER 图里学生和课程是 M:N 且成绩在中间表这个查询就是三表联查写出来顺畅如果画成 1:N这个查询根本写不出来。能支撑目标查询的 ER 图才是对的 ER 图。再进阶一点可以把 ER 图和数据库迁移工具结合。比如用 Flyway 或 Liquibase 管理建表脚本ER 图作为文档和脚本一起进版本库每次迁移都对照图检查。这样 ER 图不会过期新人接手也能快速理解结构。最后说个我自己的教训早年我觉得 ER 图是学生作业工作里直接建表更快。结果一个订单模块因为把 M:N 画成 1:N上线两周后加了个「一个订单多个优惠券」的需求中间表没建只能停机改表迁数据。从那以后我再小的模块也先画 ER 图二十分钟换一次不改表这笔账很划算。希望帮到你。本文还有配套的精品资源点击获取