ER 图

ER 图

ER 图描述实体、属性与关系，适合数据模型沟通。构图AI 可一句话生成可编辑手绘 ER 图。

登录可免费体验 1 次；VIP 期内不限制日常画图；导出 PNG / SVG / .excalidraw。

什么时候用

• 建库之前：先对齐有哪些实体、如何关联，再写迁移脚本，避免返工改表。
• 需求变更：加「优惠券」「会员等级」时评估影响哪些表、哪些基数会变。
• 跨端对齐：后端、数据仓库、BI 对同一业务对象有共同命名与关系理解。
• 面试与教学：用一张图讲清「用户—订单—商品」经典模型，比口头列举更清楚。

不适合表达接口调用顺序（时序图）或系统分层（架构图）。组织汇报关系用组织结构图，而不是 ER。管道式数据搬运用数据流图；ER 专注「结构」，数据流专注「流动」。

核心元素

元素	说明
实体	可独立识别的业务对象（用户、订单）
属性	实体字段；主键宜醒目标注
关系	连线上的基数：1:1、1:N、N:M
外键	虚线或标注指向被引用实体
业务域分组	相关实体就近，避免满图交叉

原则：先关系后字段——关系错了，字段再全也救不回模型。概念层可以画 N:M，落库时通常需要关联表，图上最好有交代，避免研发各自理解。

排版规则（ER 专用）

1. 强关联实体相邻：用户贴近订单、订单贴近订单项，外键线尽量短。
2. 主键置顶：实体框内先写 PK，再写 2～5 个关键属性，其余进数据字典。
3. 基数写在线上两端：1 / N 不要只口头约定；N:M 落库前补关联实体。
4. 按业务域分块：交易域、会员域、商品域用虚线分组，跨域关系再连。

反例：把「用户」实体塞进二十个字段（头像 URL、最后登录 IP、各种偏好开关），同时省略与订单的基数——评审会盯着字段吵架，却答不出「一个用户能否有多笔订单」。应先画清关系与 PK/FK，字段细节另附。

Prompt 好坏对比

	示例	为什么
差	画个数据库图	无实体无关系，模型随机
差	把所有表字段都画上	图不可读，失去扫读价值
好	画电商 ER：用户、订单、商品、分类；用户—订单 1:N，订单—商品 N:M 用订单项	实体与基数齐全
好	画用户-订单 ER，标主键与外键，属性只保留关键业务字段	粒度适合评审

评审时可让产品念业务规则、研发指着基数核对：一个用户能否有多笔订单、订单能否对应多个 SKU。规则与图不一致时，优先改模型定义，再改代码与迁移。

常见错误

1. 用流程步骤当实体：把「支付成功」画成实体；实体应是可持久化的名词。
2. N:M 不拆中间表：概念层可保留 N:M，实现层常需关联实体，评审时要说清楚。
3. 属性堆砌：把几十个字段全写进框，图失去扫读价值；只保留主键与关键业务属性。
4. 连线交叉无布局：多实体时用网格，相关实体靠近，外键方向可读。
5. 命名口语化：同一对象在图上叫「客人」、在库里叫 user，跨团队必然混乱。

与相邻图类型的区别

维度	ER 图	架构图	数据流图
对象	数据实体与关系	运行组件与分层	数据搬运路径
边含义	基数关系	调用依赖	数据传送
是否含字段	常含关键属性	一般不含	可注数据格式
典型	电商库表	微服务全景	ETL 管道

建模检查清单

落库前用这五条快速自检，比「再加几个字段」更管用：

1. 每个实体能否用一句话定义业务边界？（说不清就可能该拆或该合）
2. 每条关系是否写了基数？N:M 是否已决定关联表名称？
3. 主键策略是否统一？（自增、雪花、UUID 混用要在图外说明）
4. 软删除、审计字段是否全局约定，而不是每个实体重复画一堆？
5. 读写分离、宽表、缓存是否误画进 ER？那些属于架构/数据流，应拆图。

电商场景可先对齐「用户—订单—订单项—商品」骨架，再扩展优惠券、地址、库存；不要一上来把营销玩法全塞进第一版模型。对照 用户订单 ER 示例 看字段粒度，再决定本项目的详略。

若已有线上库，可先导出核心表名再生成 ER，再人工核对基数是否与真实外键一致；图与库不一致时，以业务规则为准回写迁移，而不是让错误模型继续传播。

生成后若发现实体超过十二个，优先按业务域拆成两张 ER，再画一张「域间关系」总览，比单图密密麻麻更适合评审投影。

用构图AI怎么画

选择「ER 图」，描述实体与关系，例如：「画电商 ER：用户、订单、商品、分类」。生成后补主键与基数，整理布局再导出。可先打开用户-订单示例对照基数画法，再扩展优惠券、库存等实体。

构图AI 共 12 种技能，复杂业务可先画 ER 定模型，再配数据流图说明同步与汇总链路，形成「结构 + 流动」两套材料。

相关：用户订单 ER 示例 · 电商订单示例 · 示例库 · 使用此技能画图