ER 图（Entity-Relationship Diagram，实体关系图）是数据库设计的核心工具。无论是新系统开发、数据库重构，还是技术文档编写，一张清晰准确的 ER 图都是不可或缺的。 很多开发者习惯用专业工具（如 PowerDesigner、Navicat 建模工具、draw.io）来画 ER 图，但这些工具的输出往往难以直接嵌入到 WPS 格式的方案文档中。截图粘贴的方式又失去了可编辑性。 实际上，WPS 流程图模块完全可以绘制标准 ER 图。本文将完整讲解从零开始制作 ER 图的全部技巧，让开发人员在不切换工具的情况下完成数据库设计文档。   一、ER 图基础：先理解再看怎么画 1.1 ER 图的三个核心要素 要素 符号 含义   实体（Entity） 矩形 数据库中一张表，如「用户」「订单」「商品」  属性（Attribute） 椭圆 或 矩形内文字 实体的字段，如「用户ID」「用户名」  关系（Relationship） 菱形 或 连接线标注 实体之间的关联，如「用户 下 订单」   1.2 ER 图的两种主流表示法 目前业界有两种主流的 ER 图表示法，画之前要先选定一种： 表示法 A：陈氏表示法（Chen's Notation） • 实体：矩形 • 属性：椭圆，用线连接到实体 • 关系：菱形 • 特点：最符合学术定义，属性 visualization 最完整 • 适合：教学、详细设计文档  表示法 B：鸭爪表示法（Crow's Foot Notation） • 实体：矩形框（含属性列表） • 关系：连接线末端用"鸭爪"符号表示基数 • 特点：更紧凑，工程师阅读更高效 • 适合：实际开发文档、数据库设计评审  本文默认采用鸭爪表示法，因为它在开发团队的日常使用中最普遍。 1.3 基数（Cardinality）的含义 基数描述"一个实体实例能与另一个实体实例建立多少个关联"： 符号 含义 文字标注   一根竖线 ` ` 恰好 1 个  鸭爪 ⟨ 多个（0 个或多个） 多  圆圈 ○ 0 个 0  组合：`○ ` 0 或 1 个  组合：`⟨ ` 1 或多个   连线两端的基数组合起来，读作： • 1 — 多：一对多（如 1 个用户对应多个订单） • 1 — 1：一对一（如 1 个用户对应 1 个用户详情） • 多 — 多：多对多（如 1 个商品属于多个分类，1 个分类包含多个商品）    二、在 WPS 中绘制 ER 图的形状方案 WPS 没有原生的 ER 图形状库，但可以用通用形状模拟。 2.1 实体框的构建 ER 图的实体框通常包含实体名称和属性列表，用"双栏矩形"表示： 推荐构建方式（鸭爪表示法）： 1. 画一个矩形（宽度 180px，高度根据属性数量动态调整） 2. 顶部区域（约占 1/3 高度）填写实体名称，加粗显示 3. 用一条水平线将矩形分为上下两栏 4. 下半栏填写属性列表，每行一个属性  ┌─────────────────────┐
│      USER（用户）    │  ← 实体名，加粗
├─────────────────────┤
│ PK  user_id    BIGINT │  ← 属性列表
│     username    VARCHAR │
│     email       VARCHAR │
│     created_at  DATETIME│
└─────────────────────┘
 2.2 属性标注规范 在属性列表中，用前缀符号区分属性类型： 前缀 含义 示例   PK 主键（Primary Key） PK user_id  FK 外键（Foreign Key） FK order_id  AK 候选键（Alternate Key） AK email  无前缀 普通属性 username   可选：用特殊符号进一步标注： • 主键下方加下划线（在 WPS 中选中主键文字 → 下划线） • 外键文字用斜体（模拟学术规范）  2.3 关系连线的绘制 在鸭爪表示法中，关系用实体之间的连接线表示，基线类型表示基数： WPS 中的实现方法： 1. 从实体 A 的右侧画一条水平实线 2. 实线连接到实体 B 的左侧 3. 在连接线两端分别标注基数符号  基数符号的 WPS 模拟： 基数 WPS 中画法   1（恰好一个） 连接线末端画一条短竖线（小矩形，宽 2px，高 15px）  多（零或多） 连接线末端画"鸭爪"：三条短线呈放射状  0 或 1 圆圈（小椭圆）+ 短竖线组合  1 或多 短竖线 + 鸭爪组合   简化方案：如果鸭爪符号画起来太麻烦，可以在连接线上直接标注文字，如 1 — N、1 — 1、M — N，简单直接，工程师也能看懂。    三、完整 ER 图绘制步骤 以"电商系统"为例，完整演示一张 ER 图的制作过程。 3.1 第一步：确定实体清单 先列出系统中的所有实体（数据库的表），不要急着画： 用户（USER）
订单（ORDER）
订单详情（ORDER_ITEM）
商品（PRODUCT）
商品分类（CATEGORY）
 3.2 第二步：绘制实体框 1. 按 2.1 节的方法，为每个实体画一个矩形框 2. 填入实体名称和属性列表 3. 用「对齐」工具将实体框顶部对齐 4. 大致排列位置（主键实体放左侧，从属实体放右侧）  3.3 第三步：分析实体间关系 逐一分析每两个实体之间的关系： 实体 A 关系 实体 B 基数 A→B 基数 B→A   用户 下 订单 1 多  订单 包含 订单详情 1 多  商品 属于 商品分类 多 1  订单 关联 商品 多 多   多对多关系的处理：数据库无法直接表示多对多，需要引入中间表。上例中"订单-商品"的多对多关系，通过"订单详情"表来实现（订单 1—多 订单详情 多—1 商品）。  3.4 第四步：绘制关系连线 1. 从「用户」右侧画实线连接到「订单」左侧 2. 用户端标注 1，订单端标注 N（或画鸭爪符号） 3. 依次连接所有有关系实体对 4. 在连接线上方标注关系名称（如"下""包含"）  3.5 第五步：检查与美化 1. 检查每个实体的主键是否已标注 2. 检查外键属性是否已添加到从属实体中 3. 统一所有实体框的宽度（用「相同大小」功能） 4. 统一连接线样式（颜色、粗细） 5. 添加图表标题和说明文字    四、ER 图绘制的高级技巧 4.1 用颜色区分实体类型 建立一套颜色规范，让 ER 图更易读： 实体类型 填充色 示例   核心业务实体 浅蓝色 #BDD7EE 订单、用户  配置/字典实体 浅绿色 #E2F0D9 商品分类、状态码  中间关联实体 浅黄色 #FFFFCC 订单详情、用户角色关联  外部系统实体 浅灰色 #F2F2F2 支付系统、物流系统   4.2 处理大型 ER 图的排版 当实体超过 8 个时，一张图会变得很拥挤。处理方案： 方案 A：按模块拆分 将 ER 图按业务模块拆分为多张子图： 电商系统 ER 图
  ├─ 用户模块 ER 图（用户、用户资料、用户地址）
  ├─ 商品模块 ER 图（商品、分类、库存）
  ├─ 订单模块 ER 图（订单、订单详情、支付记录）
  └─ 物流模块 ER 图（物流单、配送记录）
 方案 B：核心图 + 展开图 先画一张只包含核心实体（5~6 个）的总览图，再为每个核心实体画一张展开图，显示与该实体相关的所有实体。 4.3 在 ER 图中标注索引信息 对于开发文档，可以在属性列表中额外标注索引信息： ┌─────────────────────────┐
│      ORDER（订单）        │
├─────────────────────────┤
│ PK  order_id     BIGINT  │  ← 聚簇索引
│ FK  user_id     BIGINT  │  ← 普通索引
│     order_no    VARCHAR  │  ← 唯一索引
│     total_amount DECIMAL │
│     status      TINYINT  │  ← 普通索引
│     created_at  DATETIME │  ← 普通索引
└─────────────────────────┘
 用不同标记区分索引类型： • PK：主键索引（自动创建） • IDX：普通索引 • UIDX：唯一索引  4.4 将 ER 图与数据字典联动 ER 图展示了"结构"，数据字典展示了"细节"。建议在 ER 图旁边（或同一文档的下一页）附上数据字典表格： 表名 字段名 类型 是否空 默认值 说明   ORDER order_id BIGINT NOT NULL — 订单ID，自增  ORDER user_id BIGINT NOT NULL — 用户ID，外键  ORDER total_amount DECIMAL(10,2) NOT NULL — 订单总金额   ER 图 + 数据字典，才是完整的数据库设计文档。   五、从 ER 图到建表 SQL 的检查清单 ER 图画完后，在写建表 SQL 之前，按以下清单检查： □ 每个实体都有主键（PK 标注）
□ 所有外键关系都在从属实体中有对应的外键字段（FK 标注）
□ 多对多关系已引入中间表
□ 一对一关系已确认哪方持有外键
□ 每个字段的数据类型已标注
□ 非空约束（NOT NULL）已标明
□ 索引需求已标注
□ 实体名称已确认为英文（对应表名）
□ 属性名称已确认为英文（对应字段名）
□ 关系名称已用动词描述（如"下""包含""属于"）
   六、ER 图常见错误与修正 错误 1：把多对多关系直接连起来 错误做法：商品实体和分类实体之间直接画一条多对多连线。 正确做法：引入中间表「商品分类关联」（PRODUCT_CATEGORY），将多对多拆成两个一对多。 错误 2：外键字段遗漏 错误做法：画了"用户 1—多 订单"的关系，但订单实体框里没有 user_id 字段。 正确做法：在从属实体（订单）中必须添加外键字段，并在属性列表中标注 FK。 错误 3：实体框里放了大量无关属性 错误做法：把"创建时间""更新时间""创建人""更新人"等审计字段放到每个实体框里，导致框体过长。 正确做法：审计字段可以统一说明，不必每个实体都列出来；或者只在核心实体中列出，其他实体用"（含审计字段）"标注。 错误 4：基数标注错误 错误做法：把"用户 1—多 订单"标成"用户 多—1 订单"。 检查口诀： • 走进实体 A，看 A 的一个实例"能对应 B 的几个实例"→ 这是 A 端的基数 • 走进实体 B，看 B 的一个实例"能对应 A 的几个实例"→ 这是 B 端的基数    七、WPS 流程图 ER 图 vs 专业数据库建模工具 对比维度 WPS 流程图 PowerDesigner / Navicat 建模   学习成本 低 中高  自动生成 SQL 不支持（需手动写） 支持（从模型直接生成建表 SQL）  反向工程（从数据库生成 ER 图） 不支持 支持  嵌入 WPS 文档 原生支持，双击可编辑 需截图，不可编辑  协作编辑 云文档支持多人协作 一般不支持或需额外配置  适合场景 设计文档、方案汇报 实际数据库开发、维护   建议： • 如果是写设计文档、做方案汇报，用 WPS 流程图画 ER 图 • 如果是实际开发，用专业建模工具设计，再导出图片插入 WPS 文档    八、总结 用 WPS 流程图画 ER 图，核心思路是"用矩形框模拟实体，用连接线模拟关系"。虽然不如专业工具自动化程度高，但胜在与 WPS 文档体系无缝融合，特别适合需要输出 WPS 格式数据库设计文档的场景。 关键要点回顾： 要点 说明   表示法选择 推荐鸭爪表示法，工程师阅读效率最高  实体框构建 矩形分两栏：实体名（加粗）+ 属性列表  属性标注 PK/FK/AK 前缀 + 数据类型  基数表示 连接线末端标注 1/N/M 或绘制鸭爪符号  多对多处理 必须引入中间表，拆成两个一对多  检查清单 10 项逐条确认后再写建表 SQL   掌握这些，你画的 ER 图将不再是"示意图"，而是真正能指导数据库实现的设计蓝图。