ER 图怎么画？实体、属性与关系的完整梳理方法

ER 图怎么画，关键不在画图工具，而在能不能从一段业务描述里正确地分出哪些是实体、哪些是属性、哪些是关系。初学者最常犯的两个错：把"订单状态"当成实体单独画一个框，以及把多对多关系直接连一条线不建中间表。这两个错会一路带到建表阶段，改起来代价不小。

这篇按识别实体 → 定属性 → 判断关系 → 处理多对多的顺序讲，最后说清楚两种记法的差别和从代码反推的做法。

一、三个基本概念先分清

• 实体（Entity）——业务中独立存在、需要被记录的对象。用户、订单、商品、课程都是实体
• 属性（Attribute）——描述实体的特征。用户的姓名、手机号，订单的下单时间、总金额
• 关系（Relationship）——实体之间的关联。用户"下单"订单，订单"包含"商品

判断是实体还是属性的方法：问自己"它需要被单独查询和管理吗？"。订单状态如果只是一个字段值（待付款/已发货/已完成），它是属性；如果需要记录每次状态变更的时间和操作人，它就该独立成"订单状态变更记录"实体。

二、从业务描述里识别实体

有个很实用的语法技巧：通读需求描述，把名词圈出来，把动词圈出来。

• 名词 → 候选实体或属性
• 动词 → 候选关系

以"用户可以浏览商品、把商品加入购物车、提交订单，订单由多个商品组成，管理员负责审核订单"为例：

• 名词：用户、商品、购物车、订单、管理员 → 五个候选实体
• 动词：浏览、加入、提交、组成、审核 → 五个候选关系

接下来做筛选。候选实体里要去掉两类：

1. 只是属性的——如果一个名词没有自己的独立属性，只是描述另一个实体，它是属性不是实体
2. 可以合并的——用户和管理员如果字段基本一致，只是角色不同，可以合并成一个"用户"实体加"角色"属性

筛完之后通常会剩下 5–15 个核心实体。一张 ER 图的实体超过 20 个就该考虑按子域拆分。

三、属性怎么定

每个实体至少要有一个主键——能唯一标识一条记录的属性。用户表用 user_id，订单表用 order_id。

定属性时的三条经验：

先定必需的，再定可选的。 第一轮只写业务必须有的字段，避免一开始就陷入"要不要加个备注字段"的讨论。

注意派生属性。 订单总金额可以由商品单价和数量算出来，属于派生属性。要不要存是性能取舍，但在 ER 图上应该标出来，避免后续数据不一致。

多值属性要拆。 用户的"收货地址"如果可以有多个，它就不是一个属性，而应该独立成"地址"实体，和用户建立一对多关系。

四、三种关系基数怎么判断

这是 ER 图的核心，判断方法是两个方向各问一次。

一对一（1:1）——两边都是"一个对一个"。

一个用户有几个身份认证记录？一个。一条身份认证记录属于几个用户？一个。→ 1:1

一对一关系相对少见，出现时先想想是不是应该合并成一张表。通常保留独立表的理由是：字段很多且不常用，或者权限级别不同。

一对多（1:N）——一边是一个，另一边是多个。

一个用户有几个订单？多个。一个订单属于几个用户？一个。→ 1:N

这是最常见的关系，实现方式是在"多"的一方加外键。

多对多（M:N）——两边都是多个。

一个订单包含几个商品？多个。一个商品出现在几个订单里？多个。→ M:N

多对多必须建中间表，这是 ER 图里最容易出错的地方。订单和商品之间要加一张"订单明细"表，存 order_id、product_id，以及只属于这条关系的属性——购买数量、成交单价。

判断中间表要不要独立成实体的标准：这条关系本身有没有自己的属性？有（数量、单价、快照），就是一个实体；纯粹的关联，就只是中间表。

五、Chen 氏记法与 Crow's Foot 记法

两种主流画法，用途不同：

怎么选：写论文、做课程设计、需要符合学术规范时用 Chen 氏；实际做数据库设计、给研发团队看时用 Crow's Foot——它把属性列在实体内部，更接近最终的表结构，也更省空间。

六、从建表语句反推 ER 图

已有数据库、需要补文档的情况很常见。反推的顺序是：

1. 每张表对应一个实体（中间表先标记出来，最后处理）
2. 字段就是属性，主键标出来
3. 外键就是关系——外键所在的表是"多"的一方
4. 处理中间表——如果一张表只有两个外键没有其他业务字段，它是纯关联，画成多对多；如果有额外业务字段，它是独立实体
5. 核对基数——看外键字段有没有唯一约束，有唯一约束的是 1:1，没有的是 1:N

实操上可以把建表语句直接粘贴进画布，让 AI 解析成可编辑的 ER 图，再按上面的顺序人工核对。核对是必须的——代码里没有的业务约束（比如"一个用户最多三个地址"），反推时体现不出来。

七、手绘 ER 图怎么数字化

课堂上、白板上画的 ER 图草稿，可以拍照上传，AI 识别形状、文字与连接关系后转成标准可编辑图形。转换之后重点校对两处：

• 基数标记——手写的 1、N、M 容易识别混，逐条核对
• 主外键标注——草稿上常用下划线表示主键，识别后要确认没有丢失

具体做法可以看手绘草稿怎么转成可编辑流程图，ER 图的处理方式是一样的。

八、画在画布上的额外好处

ER 图很少单独存在。做系统设计时，它旁边通常还需要功能架构图、业务流程图和数据流图。

英飞·思想家支持在同一块无限画布上同时放这几种图，改数据模型时能立刻看到受影响的流程。配合实时协作和节点级批注，评审时后端同事可以直接在某个实体上标注"这个字段应该加索引"，讨论历史留在图里。

模板社区有现成的 ER 图模板，替换实体和字段即可使用，比从空白页搭框架快。

常见问题

ER 图和数据库表结构图有什么区别？

ER 图是概念层面的，描述实体和关系；表结构图是物理层面的，包含字段类型、索引、约束等实现细节。ER 图通常先画，再落成表结构。

多对多关系一定要建中间表吗？

在关系型数据库中是的。ER 图上可以直接画 M:N，但落到表结构必须通过中间表实现。

一张 ER 图画多少个实体合适？

核心实体建议控制在 20 个以内。超过就按业务子域拆分成多张图，用一张总览图串联。

能从代码或建表语句生成 ER 图吗？

可以把结构化描述或代码粘贴进画布让 AI 解析成可编辑图形，之后需人工核对基数和业务约束。

用 Chen 氏还是 Crow's Foot？

课程设计和学术论文用 Chen 氏，工程实践用 Crow's Foot。

结语

ER 图的质量取决于实体和属性有没有分对、关系基数有没有判准。这两步做扎实，后面的画图和建表都是顺理成章的事；这两步含糊，图画得再规范也会在开发阶段返工。

从需求描述起步时先圈名词动词，从已有数据库起步时先看外键。想了解产品能力，可以看AI 流程图功能页；系统设计还需要配套的架构图，可以看架构图怎么画。