1. 一个让我彻底重视ER图的真实场景先说个我自己的经历。几年前我带一个小型项目负责设计用户、订单、商品、库存模块的数据库。当时觉得业务简单随手建了十来张表外键看心情加字段命名全凭直觉。结果上线三个月后产品要加“满减活动绑定多商品”的功能我翻了半天表结构发现订单表和商品表之间的关联关系根本没理清——到底是订单关联商品快照还是关联商品主表促销活动和商品是多对多还是一对多谁也没法一眼说清楚。最后只好推倒重来把整个业务模型重新梳理了一遍。那次重构让我彻底明白了在动手写CREATE TABLE之前先用一张ER图画清楚实体之间的关系是成本最低、收益最高的一步。ER图Entity-Relationship Diagram实体关系图不光是大学《数据库系统概论》里的必考内容更是从业务需求到物理表结构之间那座绕不开的桥。无论是面试中被问“请画出电影评分与评价系统的ER图”还是工作中要把MySQL现有的表导出成ER关系图做架构复盘你都躲不开这个基础功。这篇文章我想把自己对ER图的理解、画图方法、实战案例和踩坑经验一次讲透。不是那种教科书式的“实体用矩形、属性用椭圆”念一遍就完而是结合真实需求和工具实操告诉你一张能落地的ER图该怎么思考、怎么画、怎么用。2. ER图到底在表达什么实体、属性、联系背后的设计思维2.1 实体不是“表”属性也不是“字段”很多人第一次学ER图喜欢把实体直接对应到数据库表、属性对应到字段。这么理解在结果上八九不离十但在思考过程里是有害的。实体应该是业务世界里一个独立存在、可以被识别的对象比如“学生”“课程”“电影”“用户”属性是这个对象自身的特征比如电影的“片名”“上映年份”“时长”。我见过不少初学者拿到需求就开始画表画出五张表、九张表越画越复杂却说不清为什么要用两张表而不是一张表。原因就是跳过了实体建模这一步。正确的顺序是先看业务里有哪些名词是独立存在的概念再看它们之间有什么关系最后才落到表结构。比如“订单”和“订单明细”在业务里是两个实体吗如果订单包含多条商品记录那对订单来说每条明细需要单独记录数量、价格它就必须是一个独立实体如果业务上订单只是一行信息不需要拆多个商品那它可以合并。2.2 联系ER图的灵魂所在实体之间的关系有三种基本度数理解透了画图就成功了一半一对一1:1一个A对应一个B反过来也是一个B对应一个A。比如“用户”和“用户身份证信息”现实中一个用户最多一条实名记录一条实名记录也只属于一个用户。在实现上可以合成一张表也可以两张表加唯一外键。一对多1:N)一个A对应多个B但一个B只对应一个A。比如“班级”和“学生”一个班有多个学生一个学生只属于一个班。这是最常见的关系也是数据库外键存在的核心场景。多对多M:N一个A对应多个B一个B也对应多个A。比如“电影”和“演员”一部电影有多个演员一个演员演过多部电影。凡是多对多关系落到关系模型时必须通过中间表交叉表拆成两个一对多。这里有一个初学者最容易犯的错看到“电影-演员”是多对多就直接画一条M:N的直线然后开始建表。但实际设计表时你需要多建一张“演职员表”里面放电影ID演员ID饰演角色。ER图上可以先保留多对多转关系模式时再拆中间表。这两个阶段不要混在一起。我在第三部分会用电影评分系统完整演示这个过程。2.3 参与约束和基数约束决定业务规则的关键除了是一对多还是多对多ER图还有一个容易被忽略的信息参与约束participation constraint。它描述的是一个实体是否必须参与到关系中。还是用“班级-学生”举例如果学生必须属于某个班级那学生在“属于”关系中就是强制参与图中用双线或实线表示。如果一个学生可以暂时未分班那它就是可选参与图中用单线或虚线表示。这个约束直接决定了数据库表的外键能不能为空。如果学生必须属于班级那“学生表.班级ID”就应该设置为NOT NULL如果允许未分班就可以允许为空同时前端校验也要跟着调整。很多人建表时对外键的NULL约束随意设根源就是画ER图时根本没想清楚参与约束。基数比和参与约束是两张图都要表达的信息。完整标注这两点ER图才真正能传递业务规则而不是只画个大概样子。2.4 三种常见符号体系选一个用到底画ER图的符号体系主要有三类混着用很容易让读者崩溃符号体系实体关系特点常见工具Chen陈氏矩形菱形最经典考试教材最爱用手绘、draw.ioCrows Foot鸡爪矩形矩形圆圈分叉线直观表达基数工业界常用MySQL Workbench、DataGripUML风格矩形连线连线适合与类图统一建模Rational Rose、PlantUML我自己在实际工作中习惯用Crows Foot因为它把1、多、可选、强制这些信息画在连线两端看起来非常直观MySQL Workbench自动生成的ER图默认就是这个表现方式。但如果你在学校或者在考场上Chen风格是主流菱形表示关系、椭圆表示属性该练还得练。工具形态是表象关键是图里表达的语义要准确。3. 实战案例一电影评分与评价系统的ER图怎么画这个例子是很多面试和课程里反复出现的题热度很高。我不直接给答案带你走一遍完整的设计思路。假设需求是这样平台上有用户、电影、用户给电影打分1到10分同时可以写一条文字评价。一个用户可以对同一部电影反复修改评分和评价吗通常业务设计是“一个用户对一部电影只能有一条评分记录可以更新分数和评语”因为要避免刷分。这个规则直接影响关系怎么画。3.1 识别实体和属性先找名词用户、电影、评分、评价、导演、演员、类型。逐个判断哪些是独立实体哪些是属性用户独立实体。属性有用户ID、昵称、注册时间。电影独立实体。属性有电影ID、片名、上映年份、时长、简介。评分/评价它们依附于“某个用户对某部电影的评价”单独作为属性挂在关系上还是做成独立实体这里恰恰是本题的关键。按第四部分的经验我推荐把“评分与评价”作为独立实体因为“用户-电影”是多对多关系中间实体需要携带评分、评语、创建时间、更新时间这些额外信息。中间实体的存在能让这张“联系表”变得完全独立后续扩展点赞数、评论数也很自然。继续看其他名词。“导演”和“演员”可以单独做实体也可以做成电影的多值属性。如果未来要按导演查电影列表就值得单独建实体“电影类型”类似多部电影可以属于同一个类型建模成独立实体“电影类型”更合理。所以最终实体集合是用户、电影、电影类型、导演、演员、评分记录。其中评分记录是联系产生的实体叫作派生实体。3.2 确定联系及基数逐对分析关系用户与评分记录一个用户可以有多条评分记录一条评分记录属于一个用户这是1:N。电影与评分记录一部电影有多条评分记录一条评分记录针对一部电影这也是1:N。电影与电影类型一部电影属于一种类型一种类型可以有多部电影这是1:N。电影与导演一部电影有一个导演简化一个导演指导多部电影1:N。电影与演员多对多用“参演”联系需要中间表。用户的参与约束用户可以评分也可以不评所以用户在评分关系中是可选参与评分记录必须属于一个用户所以评分记录是强制参与。这个规则映射到数据库就是评分记录表的用户ID外键设为NOT NULL但用户表的评分数量不做限制。3.3 画出逻辑ER图并转成关系模式基于以上分析逻辑ER图草稿如下[电影类型]1——N[电影]1——N[评分记录]N——1[用户] | 1 | N [导演] [电影]N——M[演员] 多对多待拆中间表确定无误后转为关系模式。这一步极其关键它把ER图翻译成数据库表结构关系模式主键外键用户用户ID昵称注册时间用户ID无电影类型类型ID类型名类型ID无导演导演ID姓名简介导演ID无电影电影ID片名上映年份时长简介类型ID导演ID电影ID类型ID→电影类型导演ID→导演演员演员ID姓名出生日期演员ID无参演电影ID演员ID饰演角色电影ID演员ID两个外键评分记录记录ID用户ID电影ID分数评语创建时间更新时间记录ID用户ID→用户电影ID→电影这张评分记录表就是中间实体落地的结果。它让“用户对电影的评分”成为独立表用户可以反复更新分数但不会重复插入多条业务上通过唯一约束用户ID电影ID保证一个用户对一部电影只有一条评分。关于外键我建议评分记录表的用户ID电影ID除了加唯一约束还应该建立联合索引。因为实际查询基本都是“某用户对某电影的评分状态”和“某电影的全部评分列表”联合索引能覆盖这两个高频场景。3.4 画这张图的常见翻车点我在带新人和看网上的ER图题解时经常发现三类错误错误一把评分和评价当成两个独立实体。这是最大的问题。评分和评价是同一个行为的两部分一旦拆开就会出现“用户评了分但没写评价”和“写了评价但没评分”两个互不约束的数据业务上完全失控。正确做法是放在同一张评分记录表里让分数字段和评语字段在同一行记录上。错误二把“电影类型”直接设计成电影的多值属性。有的练习答案把电影类型写在电影实体上写成“类型动作/喜剧/科幻”。这看起来方便但一旦要按类型统计票房或做筛选字符串处理非常痛苦。正确做法是独立出“电影类型”实体电影表只存一个类型ID保持单一归属。错误三多对多关系处理不到位。“演员-电影”是多对多很多人直接在电影表里加一个“主演ID列表”字段这是一个反模式。正确的做法是通过参演表交叉表来解决这也是一道高频面试题。4. 实战案例二教学管理系统ER图从简到繁的演进过程再来看另一个高频场景教学管理系统。这类ER图为什么受欢迎因为它的实体关系天然包含1:1、1:N、M:N三种情况而且附带子类教师既是授课者也是课程设计者非常适合拿来练手。4.1 最小可用版本学生、课程、选课先定义最核心的需求学校有学生和课程学生可以选择多门课程一门课程可以被多个学生选择。这是非常典型的多对多。最小可用版本的实体和关系如下学生学号姓名性别出生日期入学年份专业课程课程号课程名学分学时选课学号课程号成绩选课时间中间实体除了关联两个主键还携带成绩、选课时间等属性。注意“成绩”不能挂到“课程”或“学生”实体上它一定是选课关系上的属性。一个学生还没考试时成绩为空一个学生选了课但成绩还没录这行记录也存在。所以选课表的主键最好是学号课程号成绩字段允许为空等成绩录入后再更新。这个最小版本已经足够应付课程作业。但如果要做一个真正能上线的教学管理系统还需要继续演进。4.2 加入教师、班级、院系后的复杂版本随着需求细化教学管理系统通常还会包含教师、班级、院系等实体一个院系有多个教师一个教师属于一个院系。老师实体主要记录教师工号、姓名、职称、所属院系。一个班级有多个学生一个学生属于一个班级。如果把专业和班级分开学生就通过班级间接关联到院系。教师和课程一门课程由一个老师负责讲授一个老师可以讲多门课程这是1:N。学生通过选课表和课程关联之后还能通过课程间接知道任课老师。这个扩展后的ER图核心不再是“学生选课”而是把“教师-课程”也纳入体系。实际项目中还会遇到更细的业务规则同一个教师可以带多个班的实验课一个班有多门实验课由不同教师上这时“教师-班级-课程”就变成三元联系。三元联系是很多人搞不定的地方。我直接说结论遇到三元联系先尝试拆成多个二元联系必要时保留三元联系表。比如“某老师在某班教某门课”这种事实最稳的做法是单独建一张“授课表”包含教师ID、班级ID、课程ID再加上课的时间段。拆成“教师-课程”和“班级-课程”两张表会丢失“老师、班级、课程”三者之间的绑定关系所以必须用三元联系表来表达。ER图里的菱形可以连三条边落到数据库就是一张三外键的关联表。4.3 引入子类教师还是课程设计者教学管理系统里还有一个常见考点教师可以分为“专职教师”和“兼职教师”或者某些教师同时是“课程负责人”。ER图中处理子类的方式是ISA联系is-a就是子类继承父类的所有属性同时拥有自己的特殊属性。画图时父实体在上方子实体在下方中间画个三角形或标ISA。现实中转数据表有两种做法单表继承适合子类差异小的情况。教师表里加一个“教师类型”字段专职和兼职的差异字段全部允许NULL。类表继承父表放公共字段子表放特有字段子表主键同时是外键。适合子类属性差异大、查询经常只查某一类的情况。我在项目里一般优先选类表继承因为数据库的字段一旦冗余会导致业务校验混乱。“教师类型”字段一旦出现“专职教师上课时数”和“兼职教师工资标准”这种动名词混在一起ORM映射非常难受。反过来如果只是给部分教师加一个“是否课程负责人”的布尔标记那就老老实实加字段不要真建一张“课程负责人”子表过度设计比设计不足更常见。5. 工具实操从Rational Rose到MySQL自动导出ER图5.1 Rational Rose画ER图老牌工具的正确打开方式看到热搜里有“Rational Rose画ER图”必须说一句Rational Rose确实老了但不少高校课程和旧项目还在用而且它的逻辑数据模型Logical Data Model组件画ER图非常顺手。用Rational Rose画ER图的流程大致如下新建模型在Browser面板右键→New→Logical Data Model。在Logical Data Model图里拖入“Logical Data Model”图标进入数据建模视图。使用左侧工具栏的Entity实体工具在画布上放置实体双击打开规格窗口设置名称和属性。添加属性时注意指定数据类型、主键标示、是否允许NULL。通过Relationship工具连接实体在连接线属性里设置基数1:1、1:N、M:N、参与约束和数据完整性规则。全部画完后可以执行Tools→Data Modeler→Forward Engineer把逻辑模型转换成物理模型甚至直接生成DDL脚本。一个容易迷惑的点是Rational Rose里既有逻辑模型Logic Model也有数据模型Data Model新手经常弄混。画ER图要在数据模型的Logical Data Model区域里画不是在用例图或类图那边画。另外Rational Rose生成的默认DDL是带固定格式的字段名和表名一般不会自动加反引号导入MySQL时遇到关键字做表名需要手动调整。5.2 MySQL的现有表导出ER关系图工作中更常遇到的场景是数据库已经有一堆表了要看清楚表之间的关系。MySQL Workbench直接支持反向工程生成ER图。以MySQL Workbench 8.0为例步骤是打开MySQL Workbench菜单栏选择Database→Reverse Engineer。选择数据库连接输入密码下一步勾选要导入的表或直接选择整个Schema。Workbench会读取所有表、外键、索引自动生成EER Diagram。生成的图中表用矩形表示外键关系用连线表示线端有Crows Foot记号表达一对多。如果线上数据库表之间没有建立外键关系Workbench就不会画线——这是最尴尬的场景。提到第5点我得特别强调很多项目为了性能和管理方便在物理表上根本不建外键约束外键关系只存在于维护者的脑子里。这种情况下用Workbench反向工程导出的“ER图”就是一张张孤立的表看不到关联。遇到这种情况有两种补救方法方法一在查询里通过JIN语法手动确认关联字段然后用Workbench的Model菜单里的“Place Related Tables”来自动摆放。方法二用Navicat的“模型”功能它可以直接从表结构中读取并绘制ER图。Navicat在“模型→新建模型→导入→导入数据库”就能生成关联关系可以手动补线适合逆向梳理文档。还有一个轻量的选择draw.io。它支持各种ER图符号适合画逻辑ER图但完全不自动连数据库。如果你需要导出数据库结构化文档我建议优先用Workbench先把外键关系建好再反向工程这样图才真正有意义。5.3 各种画ER图工具怎么选工具支持符号自动反向工程适合场景draw.ioChen、Crows Foot不支持画逻辑模型、画给文章/考试用MySQL WorkbenchCrows Foot支持强分析既有MySQL数据库Navicat Model近似Crows Foot支持中等快捷导出数据库模型Rational RoseUML和逻辑数据模型一般课程教学、老项目维护DBeaver ER DiagramCrows Foot支持强看多数据库表关系最轻量PowerDesigner多种支持大型企业数据建模这里额外推荐一下DBeaver打开数据库连接后右键Schema→View Diagram秒出ER图速度非常快适合快速预览。但DBeaver的ER图默认不显示表字段类型需要手动开启细节上没有Workbench完整。6. 画ER图和用ER图过程中踩过的一些坑6.1 逐字逐句读需求别凭经验跳过很多学生在做“ER图例题”时拿到题目扫一眼就开始画结果漏掉“一门课程可以由多个教师共同授课”这种条件。我自己的经验是每次读完需求后把“名词”和“动词”分别列出来。名词对应候选实体动词对应候选关系。名词里发现“课程安排表”这种像实体又像属性的事物再回到需求里看它是否需要独立存储多条记录、是否有自己的属性。需要就设计成实体不需要就降级成属性。这种方法看着笨但特别有效几乎可以防住80%的漏实体、漏关系问题。6.2 主键的选择使用代理主键还是业务自然键画ER图推荐使用代理主键。比如用户实体里用系统自动生成的“用户ID”作为主键而不是把身份证号、手机号直接当主键。原因是业务字段可能变化而代理主键不随业务变化能最大程度保持表结构的稳定性。应用外键关联时只关联唯一标识符各种业务信息通过查询去关联获取避免因为手机号换了导致全表外键更新。这个习惯应该在画ER图阶段就定下来而不是建表时才开始想。但代理主键不意味着放弃唯一约束。用户手机号虽然不做主键仍应该加UNIQUE保证业务上不重复。6.3 命名规范ER图阶段就要统一我见过最痛苦的项目之一是订单表主键叫order_id订单明细表主键叫id外键字段叫orderNo。查询全靠脑补生成ER图后连线根本对不上。建议在画ER图时就直接确定命名约定表名用下划线命名实体名用单数形式比如movie、review_record不要出现Movies和movie混用。主键统一叫id或者统一叫实体名_id。一个项目里只能选一种不能两张表两种风格。外键取名用关联实体名_id立即能看出指向哪张表。比如review_record表里的user_id、movie_id。时间字段统一为created_at、updated_at布尔字段用is_前缀比如is_deleted。在ER图上就把这些名字定死后面建表、写ORM实体类、写接口文档都不会乱。6.4 别把一切关系都建模成一张表有一类错误方向相反过于积极地拆表。比如“用户地址”明明一个用户只有几个常用地址非要拆出“用户地址表”结果业务查询多一次JIN性能下降代码复杂度上升。ER图阶段要时刻问自己这个实体是否会独立变化是否会被多个实体引用是否有自己独立的生命周期如果答案都是否它就很可能只是一个属性或多个属性组合。拿“用户地址”举例如果用户只有一个默认收货地址直接做用户表的字段如果用户有多个收货地址且需要增删改查并且订单要绑定其中一个地址快照做成独立实体是合理的。常见的设计是结合两种方案地址独立成表订单表保存地址快照字段收货人、电话、完整地址这样即使地址被修改历史订单仍然保留当时的地址信息。这就是ER图思考延伸到物理设计的典型体现。6.5 画完ER图之后务必做一次“CRUD走查”这是我个人认为最有价值的检查手段。画完ER图后把核心业务场景写出来逐一走查用户新增一条评分在review_record表插入一行关联user_id和movie_id。用户修改评语更新review_record表对应行的comment字段同时updated_at置为当前时间。用户删除自己的账号是否需要删除他的评分记录如果保留评分但用户信息匿名化那用户表和评分记录表之间就不能设置物理外键的级联删除而是要做逻辑删除。电影下架是否连评分记录一起删删除是否影响统计报表这种走查能直接暴露图中的问题。比如发现用户删除走查过不去说明用户和评分记录的删除策略没有定清楚发现某一对关系的基数写错了JIN查询的结果会多出重复行。每发现一个问题回ER图里改掉再走查一遍。等到这张图能承载所有关键业务场景再开始建表就会很踏实。7. 看完这篇文章之后建议你做的一个练习ER图这东西光看没用必须自己画一遍。如果你现在正打算学或者复习我给出的练习路径是找一张A4纸或打开draw.io自己先画“电影评分与评价系统”的ER图画完对照第三部分的内容重点检查基数、参与约束、评分记录的归属。打开一个测试数据库用Navicat或Workbench导入几张业务表跑一次反向工程对比工具生成的ER图和你自己画的逻辑ER图有什么区别。通常会发现工具图更物理化包含索引、引擎、字符集而逻辑图更关注业务语义。试着把一个多对多关系改造成一对多表观察查询SQL的变化。这个练习会让你真正理解中间表为什么存在。画图不是目的把业务想清楚才是。ER图只是帮你把脑海里模糊的业务认识变得可见、可讨论、可校验。很多时候项目出问题不是开发代码写得不好而是从一开始人员和业务之间就没有一张图把口径对齐。ER图就是那份口径。我做项目时有个习惯任何新模块设计阶段第一张先出的文档永远是ER图。评审会上拿它给产品、后端、前端一起过确认每个实体、每条关系都符合业务直觉才进入数据库建模。这张图后续还会跟着业务的演进不断更新它既是设计文档也是团队沟通的图纸。希望这篇文章能让你在画下一张ER图的时候少走几步弯路。
1. 一个让我彻底重视ER图的真实场景先说个我自己的经历。几年前我带一个小型项目负责设计用户、订单、商品、库存模块的数据库。当时觉得业务简单随手建了十来张表外键看心情加字段命名全凭直觉。结果上线三个月后产品要加“满减活动绑定多商品”的功能我翻了半天表结构发现订单表和商品表之间的关联关系根本没理清——到底是订单关联商品快照还是关联商品主表促销活动和商品是多对多还是一对多谁也没法一眼说清楚。最后只好推倒重来把整个业务模型重新梳理了一遍。那次重构让我彻底明白了在动手写CREATE TABLE之前先用一张ER图画清楚实体之间的关系是成本最低、收益最高的一步。ER图Entity-Relationship Diagram实体关系图不光是大学《数据库系统概论》里的必考内容更是从业务需求到物理表结构之间那座绕不开的桥。无论是面试中被问“请画出电影评分与评价系统的ER图”还是工作中要把MySQL现有的表导出成ER关系图做架构复盘你都躲不开这个基础功。这篇文章我想把自己对ER图的理解、画图方法、实战案例和踩坑经验一次讲透。不是那种教科书式的“实体用矩形、属性用椭圆”念一遍就完而是结合真实需求和工具实操告诉你一张能落地的ER图该怎么思考、怎么画、怎么用。2. ER图到底在表达什么实体、属性、联系背后的设计思维2.1 实体不是“表”属性也不是“字段”很多人第一次学ER图喜欢把实体直接对应到数据库表、属性对应到字段。这么理解在结果上八九不离十但在思考过程里是有害的。实体应该是业务世界里一个独立存在、可以被识别的对象比如“学生”“课程”“电影”“用户”属性是这个对象自身的特征比如电影的“片名”“上映年份”“时长”。我见过不少初学者拿到需求就开始画表画出五张表、九张表越画越复杂却说不清为什么要用两张表而不是一张表。原因就是跳过了实体建模这一步。正确的顺序是先看业务里有哪些名词是独立存在的概念再看它们之间有什么关系最后才落到表结构。比如“订单”和“订单明细”在业务里是两个实体吗如果订单包含多条商品记录那对订单来说每条明细需要单独记录数量、价格它就必须是一个独立实体如果业务上订单只是一行信息不需要拆多个商品那它可以合并。2.2 联系ER图的灵魂所在实体之间的关系有三种基本度数理解透了画图就成功了一半一对一1:1一个A对应一个B反过来也是一个B对应一个A。比如“用户”和“用户身份证信息”现实中一个用户最多一条实名记录一条实名记录也只属于一个用户。在实现上可以合成一张表也可以两张表加唯一外键。一对多1:N)一个A对应多个B但一个B只对应一个A。比如“班级”和“学生”一个班有多个学生一个学生只属于一个班。这是最常见的关系也是数据库外键存在的核心场景。多对多M:N一个A对应多个B一个B也对应多个A。比如“电影”和“演员”一部电影有多个演员一个演员演过多部电影。凡是多对多关系落到关系模型时必须通过中间表交叉表拆成两个一对多。这里有一个初学者最容易犯的错看到“电影-演员”是多对多就直接画一条M:N的直线然后开始建表。但实际设计表时你需要多建一张“演职员表”里面放电影ID演员ID饰演角色。ER图上可以先保留多对多转关系模式时再拆中间表。这两个阶段不要混在一起。我在第三部分会用电影评分系统完整演示这个过程。2.3 参与约束和基数约束决定业务规则的关键除了是一对多还是多对多ER图还有一个容易被忽略的信息参与约束participation constraint。它描述的是一个实体是否必须参与到关系中。还是用“班级-学生”举例如果学生必须属于某个班级那学生在“属于”关系中就是强制参与图中用双线或实线表示。如果一个学生可以暂时未分班那它就是可选参与图中用单线或虚线表示。这个约束直接决定了数据库表的外键能不能为空。如果学生必须属于班级那“学生表.班级ID”就应该设置为NOT NULL如果允许未分班就可以允许为空同时前端校验也要跟着调整。很多人建表时对外键的NULL约束随意设根源就是画ER图时根本没想清楚参与约束。基数比和参与约束是两张图都要表达的信息。完整标注这两点ER图才真正能传递业务规则而不是只画个大概样子。2.4 三种常见符号体系选一个用到底画ER图的符号体系主要有三类混着用很容易让读者崩溃符号体系实体关系特点常见工具Chen陈氏矩形菱形最经典考试教材最爱用手绘、draw.ioCrows Foot鸡爪矩形矩形圆圈分叉线直观表达基数工业界常用MySQL Workbench、DataGripUML风格矩形连线连线适合与类图统一建模Rational Rose、PlantUML我自己在实际工作中习惯用Crows Foot因为它把1、多、可选、强制这些信息画在连线两端看起来非常直观MySQL Workbench自动生成的ER图默认就是这个表现方式。但如果你在学校或者在考场上Chen风格是主流菱形表示关系、椭圆表示属性该练还得练。工具形态是表象关键是图里表达的语义要准确。3. 实战案例一电影评分与评价系统的ER图怎么画这个例子是很多面试和课程里反复出现的题热度很高。我不直接给答案带你走一遍完整的设计思路。假设需求是这样平台上有用户、电影、用户给电影打分1到10分同时可以写一条文字评价。一个用户可以对同一部电影反复修改评分和评价吗通常业务设计是“一个用户对一部电影只能有一条评分记录可以更新分数和评语”因为要避免刷分。这个规则直接影响关系怎么画。3.1 识别实体和属性先找名词用户、电影、评分、评价、导演、演员、类型。逐个判断哪些是独立实体哪些是属性用户独立实体。属性有用户ID、昵称、注册时间。电影独立实体。属性有电影ID、片名、上映年份、时长、简介。评分/评价它们依附于“某个用户对某部电影的评价”单独作为属性挂在关系上还是做成独立实体这里恰恰是本题的关键。按第四部分的经验我推荐把“评分与评价”作为独立实体因为“用户-电影”是多对多关系中间实体需要携带评分、评语、创建时间、更新时间这些额外信息。中间实体的存在能让这张“联系表”变得完全独立后续扩展点赞数、评论数也很自然。继续看其他名词。“导演”和“演员”可以单独做实体也可以做成电影的多值属性。如果未来要按导演查电影列表就值得单独建实体“电影类型”类似多部电影可以属于同一个类型建模成独立实体“电影类型”更合理。所以最终实体集合是用户、电影、电影类型、导演、演员、评分记录。其中评分记录是联系产生的实体叫作派生实体。3.2 确定联系及基数逐对分析关系用户与评分记录一个用户可以有多条评分记录一条评分记录属于一个用户这是1:N。电影与评分记录一部电影有多条评分记录一条评分记录针对一部电影这也是1:N。电影与电影类型一部电影属于一种类型一种类型可以有多部电影这是1:N。电影与导演一部电影有一个导演简化一个导演指导多部电影1:N。电影与演员多对多用“参演”联系需要中间表。用户的参与约束用户可以评分也可以不评所以用户在评分关系中是可选参与评分记录必须属于一个用户所以评分记录是强制参与。这个规则映射到数据库就是评分记录表的用户ID外键设为NOT NULL但用户表的评分数量不做限制。3.3 画出逻辑ER图并转成关系模式基于以上分析逻辑ER图草稿如下[电影类型]1——N[电影]1——N[评分记录]N——1[用户] | 1 | N [导演] [电影]N——M[演员] 多对多待拆中间表确定无误后转为关系模式。这一步极其关键它把ER图翻译成数据库表结构关系模式主键外键用户用户ID昵称注册时间用户ID无电影类型类型ID类型名类型ID无导演导演ID姓名简介导演ID无电影电影ID片名上映年份时长简介类型ID导演ID电影ID类型ID→电影类型导演ID→导演演员演员ID姓名出生日期演员ID无参演电影ID演员ID饰演角色电影ID演员ID两个外键评分记录记录ID用户ID电影ID分数评语创建时间更新时间记录ID用户ID→用户电影ID→电影这张评分记录表就是中间实体落地的结果。它让“用户对电影的评分”成为独立表用户可以反复更新分数但不会重复插入多条业务上通过唯一约束用户ID电影ID保证一个用户对一部电影只有一条评分。关于外键我建议评分记录表的用户ID电影ID除了加唯一约束还应该建立联合索引。因为实际查询基本都是“某用户对某电影的评分状态”和“某电影的全部评分列表”联合索引能覆盖这两个高频场景。3.4 画这张图的常见翻车点我在带新人和看网上的ER图题解时经常发现三类错误错误一把评分和评价当成两个独立实体。这是最大的问题。评分和评价是同一个行为的两部分一旦拆开就会出现“用户评了分但没写评价”和“写了评价但没评分”两个互不约束的数据业务上完全失控。正确做法是放在同一张评分记录表里让分数字段和评语字段在同一行记录上。错误二把“电影类型”直接设计成电影的多值属性。有的练习答案把电影类型写在电影实体上写成“类型动作/喜剧/科幻”。这看起来方便但一旦要按类型统计票房或做筛选字符串处理非常痛苦。正确做法是独立出“电影类型”实体电影表只存一个类型ID保持单一归属。错误三多对多关系处理不到位。“演员-电影”是多对多很多人直接在电影表里加一个“主演ID列表”字段这是一个反模式。正确的做法是通过参演表交叉表来解决这也是一道高频面试题。4. 实战案例二教学管理系统ER图从简到繁的演进过程再来看另一个高频场景教学管理系统。这类ER图为什么受欢迎因为它的实体关系天然包含1:1、1:N、M:N三种情况而且附带子类教师既是授课者也是课程设计者非常适合拿来练手。4.1 最小可用版本学生、课程、选课先定义最核心的需求学校有学生和课程学生可以选择多门课程一门课程可以被多个学生选择。这是非常典型的多对多。最小可用版本的实体和关系如下学生学号姓名性别出生日期入学年份专业课程课程号课程名学分学时选课学号课程号成绩选课时间中间实体除了关联两个主键还携带成绩、选课时间等属性。注意“成绩”不能挂到“课程”或“学生”实体上它一定是选课关系上的属性。一个学生还没考试时成绩为空一个学生选了课但成绩还没录这行记录也存在。所以选课表的主键最好是学号课程号成绩字段允许为空等成绩录入后再更新。这个最小版本已经足够应付课程作业。但如果要做一个真正能上线的教学管理系统还需要继续演进。4.2 加入教师、班级、院系后的复杂版本随着需求细化教学管理系统通常还会包含教师、班级、院系等实体一个院系有多个教师一个教师属于一个院系。老师实体主要记录教师工号、姓名、职称、所属院系。一个班级有多个学生一个学生属于一个班级。如果把专业和班级分开学生就通过班级间接关联到院系。教师和课程一门课程由一个老师负责讲授一个老师可以讲多门课程这是1:N。学生通过选课表和课程关联之后还能通过课程间接知道任课老师。这个扩展后的ER图核心不再是“学生选课”而是把“教师-课程”也纳入体系。实际项目中还会遇到更细的业务规则同一个教师可以带多个班的实验课一个班有多门实验课由不同教师上这时“教师-班级-课程”就变成三元联系。三元联系是很多人搞不定的地方。我直接说结论遇到三元联系先尝试拆成多个二元联系必要时保留三元联系表。比如“某老师在某班教某门课”这种事实最稳的做法是单独建一张“授课表”包含教师ID、班级ID、课程ID再加上课的时间段。拆成“教师-课程”和“班级-课程”两张表会丢失“老师、班级、课程”三者之间的绑定关系所以必须用三元联系表来表达。ER图里的菱形可以连三条边落到数据库就是一张三外键的关联表。4.3 引入子类教师还是课程设计者教学管理系统里还有一个常见考点教师可以分为“专职教师”和“兼职教师”或者某些教师同时是“课程负责人”。ER图中处理子类的方式是ISA联系is-a就是子类继承父类的所有属性同时拥有自己的特殊属性。画图时父实体在上方子实体在下方中间画个三角形或标ISA。现实中转数据表有两种做法单表继承适合子类差异小的情况。教师表里加一个“教师类型”字段专职和兼职的差异字段全部允许NULL。类表继承父表放公共字段子表放特有字段子表主键同时是外键。适合子类属性差异大、查询经常只查某一类的情况。我在项目里一般优先选类表继承因为数据库的字段一旦冗余会导致业务校验混乱。“教师类型”字段一旦出现“专职教师上课时数”和“兼职教师工资标准”这种动名词混在一起ORM映射非常难受。反过来如果只是给部分教师加一个“是否课程负责人”的布尔标记那就老老实实加字段不要真建一张“课程负责人”子表过度设计比设计不足更常见。5. 工具实操从Rational Rose到MySQL自动导出ER图5.1 Rational Rose画ER图老牌工具的正确打开方式看到热搜里有“Rational Rose画ER图”必须说一句Rational Rose确实老了但不少高校课程和旧项目还在用而且它的逻辑数据模型Logical Data Model组件画ER图非常顺手。用Rational Rose画ER图的流程大致如下新建模型在Browser面板右键→New→Logical Data Model。在Logical Data Model图里拖入“Logical Data Model”图标进入数据建模视图。使用左侧工具栏的Entity实体工具在画布上放置实体双击打开规格窗口设置名称和属性。添加属性时注意指定数据类型、主键标示、是否允许NULL。通过Relationship工具连接实体在连接线属性里设置基数1:1、1:N、M:N、参与约束和数据完整性规则。全部画完后可以执行Tools→Data Modeler→Forward Engineer把逻辑模型转换成物理模型甚至直接生成DDL脚本。一个容易迷惑的点是Rational Rose里既有逻辑模型Logic Model也有数据模型Data Model新手经常弄混。画ER图要在数据模型的Logical Data Model区域里画不是在用例图或类图那边画。另外Rational Rose生成的默认DDL是带固定格式的字段名和表名一般不会自动加反引号导入MySQL时遇到关键字做表名需要手动调整。5.2 MySQL的现有表导出ER关系图工作中更常遇到的场景是数据库已经有一堆表了要看清楚表之间的关系。MySQL Workbench直接支持反向工程生成ER图。以MySQL Workbench 8.0为例步骤是打开MySQL Workbench菜单栏选择Database→Reverse Engineer。选择数据库连接输入密码下一步勾选要导入的表或直接选择整个Schema。Workbench会读取所有表、外键、索引自动生成EER Diagram。生成的图中表用矩形表示外键关系用连线表示线端有Crows Foot记号表达一对多。如果线上数据库表之间没有建立外键关系Workbench就不会画线——这是最尴尬的场景。提到第5点我得特别强调很多项目为了性能和管理方便在物理表上根本不建外键约束外键关系只存在于维护者的脑子里。这种情况下用Workbench反向工程导出的“ER图”就是一张张孤立的表看不到关联。遇到这种情况有两种补救方法方法一在查询里通过JIN语法手动确认关联字段然后用Workbench的Model菜单里的“Place Related Tables”来自动摆放。方法二用Navicat的“模型”功能它可以直接从表结构中读取并绘制ER图。Navicat在“模型→新建模型→导入→导入数据库”就能生成关联关系可以手动补线适合逆向梳理文档。还有一个轻量的选择draw.io。它支持各种ER图符号适合画逻辑ER图但完全不自动连数据库。如果你需要导出数据库结构化文档我建议优先用Workbench先把外键关系建好再反向工程这样图才真正有意义。5.3 各种画ER图工具怎么选工具支持符号自动反向工程适合场景draw.ioChen、Crows Foot不支持画逻辑模型、画给文章/考试用MySQL WorkbenchCrows Foot支持强分析既有MySQL数据库Navicat Model近似Crows Foot支持中等快捷导出数据库模型Rational RoseUML和逻辑数据模型一般课程教学、老项目维护DBeaver ER DiagramCrows Foot支持强看多数据库表关系最轻量PowerDesigner多种支持大型企业数据建模这里额外推荐一下DBeaver打开数据库连接后右键Schema→View Diagram秒出ER图速度非常快适合快速预览。但DBeaver的ER图默认不显示表字段类型需要手动开启细节上没有Workbench完整。6. 画ER图和用ER图过程中踩过的一些坑6.1 逐字逐句读需求别凭经验跳过很多学生在做“ER图例题”时拿到题目扫一眼就开始画结果漏掉“一门课程可以由多个教师共同授课”这种条件。我自己的经验是每次读完需求后把“名词”和“动词”分别列出来。名词对应候选实体动词对应候选关系。名词里发现“课程安排表”这种像实体又像属性的事物再回到需求里看它是否需要独立存储多条记录、是否有自己的属性。需要就设计成实体不需要就降级成属性。这种方法看着笨但特别有效几乎可以防住80%的漏实体、漏关系问题。6.2 主键的选择使用代理主键还是业务自然键画ER图推荐使用代理主键。比如用户实体里用系统自动生成的“用户ID”作为主键而不是把身份证号、手机号直接当主键。原因是业务字段可能变化而代理主键不随业务变化能最大程度保持表结构的稳定性。应用外键关联时只关联唯一标识符各种业务信息通过查询去关联获取避免因为手机号换了导致全表外键更新。这个习惯应该在画ER图阶段就定下来而不是建表时才开始想。但代理主键不意味着放弃唯一约束。用户手机号虽然不做主键仍应该加UNIQUE保证业务上不重复。6.3 命名规范ER图阶段就要统一我见过最痛苦的项目之一是订单表主键叫order_id订单明细表主键叫id外键字段叫orderNo。查询全靠脑补生成ER图后连线根本对不上。建议在画ER图时就直接确定命名约定表名用下划线命名实体名用单数形式比如movie、review_record不要出现Movies和movie混用。主键统一叫id或者统一叫实体名_id。一个项目里只能选一种不能两张表两种风格。外键取名用关联实体名_id立即能看出指向哪张表。比如review_record表里的user_id、movie_id。时间字段统一为created_at、updated_at布尔字段用is_前缀比如is_deleted。在ER图上就把这些名字定死后面建表、写ORM实体类、写接口文档都不会乱。6.4 别把一切关系都建模成一张表有一类错误方向相反过于积极地拆表。比如“用户地址”明明一个用户只有几个常用地址非要拆出“用户地址表”结果业务查询多一次JIN性能下降代码复杂度上升。ER图阶段要时刻问自己这个实体是否会独立变化是否会被多个实体引用是否有自己独立的生命周期如果答案都是否它就很可能只是一个属性或多个属性组合。拿“用户地址”举例如果用户只有一个默认收货地址直接做用户表的字段如果用户有多个收货地址且需要增删改查并且订单要绑定其中一个地址快照做成独立实体是合理的。常见的设计是结合两种方案地址独立成表订单表保存地址快照字段收货人、电话、完整地址这样即使地址被修改历史订单仍然保留当时的地址信息。这就是ER图思考延伸到物理设计的典型体现。6.5 画完ER图之后务必做一次“CRUD走查”这是我个人认为最有价值的检查手段。画完ER图后把核心业务场景写出来逐一走查用户新增一条评分在review_record表插入一行关联user_id和movie_id。用户修改评语更新review_record表对应行的comment字段同时updated_at置为当前时间。用户删除自己的账号是否需要删除他的评分记录如果保留评分但用户信息匿名化那用户表和评分记录表之间就不能设置物理外键的级联删除而是要做逻辑删除。电影下架是否连评分记录一起删删除是否影响统计报表这种走查能直接暴露图中的问题。比如发现用户删除走查过不去说明用户和评分记录的删除策略没有定清楚发现某一对关系的基数写错了JIN查询的结果会多出重复行。每发现一个问题回ER图里改掉再走查一遍。等到这张图能承载所有关键业务场景再开始建表就会很踏实。7. 看完这篇文章之后建议你做的一个练习ER图这东西光看没用必须自己画一遍。如果你现在正打算学或者复习我给出的练习路径是找一张A4纸或打开draw.io自己先画“电影评分与评价系统”的ER图画完对照第三部分的内容重点检查基数、参与约束、评分记录的归属。打开一个测试数据库用Navicat或Workbench导入几张业务表跑一次反向工程对比工具生成的ER图和你自己画的逻辑ER图有什么区别。通常会发现工具图更物理化包含索引、引擎、字符集而逻辑图更关注业务语义。试着把一个多对多关系改造成一对多表观察查询SQL的变化。这个练习会让你真正理解中间表为什么存在。画图不是目的把业务想清楚才是。ER图只是帮你把脑海里模糊的业务认识变得可见、可讨论、可校验。很多时候项目出问题不是开发代码写得不好而是从一开始人员和业务之间就没有一张图把口径对齐。ER图就是那份口径。我做项目时有个习惯任何新模块设计阶段第一张先出的文档永远是ER图。评审会上拿它给产品、后端、前端一起过确认每个实体、每条关系都符合业务直觉才进入数据库建模。这张图后续还会跟着业务的演进不断更新它既是设计文档也是团队沟通的图纸。希望这篇文章能让你在画下一张ER图的时候少走几步弯路。
