先确定“谁是谁”
客户、订单和商品各有唯一 ID。订单明细用“订单 ID+行号”共同标识,同一订单可以记录多行商品。
从一个订单,读懂实体之间的关系
实体表示要记录的对象,属性描述对象的信息,联系说明对象之间的关系。下面用一个简化的订单模型,展示主键、外键和关系基数。
客户、订单和商品各有唯一 ID。订单明细用“订单 ID+行号”共同标识,同一订单可以记录多行商品。
一个客户可以没有订单,也可以有多笔订单;每笔订单属于一个客户。连线两端的数量规则都要说清。
订单与商品通过“订单明细”关联。数量、成交单价放在明细中,商品调价后仍能保留历史成交信息。
例如“订单被确认时,必须至少有一条明细”,需要单独说明和验证,不能只靠一条外键关系保证。
从熟悉的业务开始
参考社区中的管理系统与数据库模型,调整实体、字段和关系。模板是起点,实际基数、必填条件和业务边界仍需逐项确认。
在社区寻找更多ER图案例,查看完整作品与使用条件。
浏览更多ER图模板从业务需求到可讨论的模型
先明确业务含义,再处理图形布局。命名、关系和例外情况清楚了,图才便于后续设计与交付。
从业务描述中找出需要独立记录的对象,例如客户、订单和商品。说明这张图覆盖哪些业务,避免把操作步骤直接当成实体。
形成:实体清单与业务边界为实体列出必要字段,确定唯一标识。画逻辑模型时标清 PK、FK;多字段共同构成主键时,要说明组合规则。
形成:字段说明与标识规则逐条判断一对一、一对多或多对多,并确认是否允许零个关联。需要记录多对多关系时,用关联实体承载关系自身的属性。
形成:关系、数量与可选性检查新建、修改、删除和异常情形。例如客户尚未下单、商品调价、订单取消时,已有记录应怎样保留,再与团队确认后分享。
形成:可评审的模型与问题清单把模型放进团队讨论
在 Boardmix 中,除了绘制 ER 图,还可以用文本、便签和评论补充约束与待确认事项。业务同事说明规则,开发同事核对字段,减少图与说明分散带来的遗漏。
先理解实体与关系,再学习画法、基数和关系表映射。
ER 图描述实体、属性及实体之间的关系,重点是“数据如何关联”;流程图描述动作、判断与先后顺序,重点是“事情如何执行”。设计订单系统时,可用 ER 图说明客户与订单的数据关系,用流程图说明下单、支付和发货的过程。
取决于模型阶段和团队约定。Chen 表示法常用矩形表示实体、椭圆表示属性、菱形表示联系;带字段的实体框与乌鸦脚等标记常用于更细的数据建模。本页订单示例使用实体框和数字基数。选择一种清晰的表示法,并提供必要图例,避免混用符号却不解释。
概念模型可以直接表达多对多关系;推进到关系表设计时,通常增加关联实体。例如订单与商品之间增加订单明细,用订单 ID 和商品 ID 关联两端,并记录数量、成交单价。主键设计要符合业务,本页用“订单 ID+行号”,允许同一商品在一笔订单中出现多行。
可以从免费账户开始绘制,再按实际需要选择方案。可编辑文件、协作及导出等权益以当前账户和官方定价说明为准;不要将免费开始理解为所有功能和使用量均无限制。
可以通过 Boardmix 的分享与协作功能邀请成员参与,按实际需要设置查看或编辑权限。评审时建议把字段含义、关系基数和待确认事项放在图旁,交付前再次检查分享对象与权限。
还没有。ER 图用于表达和讨论数据关系;落地数据库时,还需确认字段类型、非空与唯一约束、索引、删除规则及性能要求。画布上的连线不等于数据库已经创建外键,也不代替数据库中的约束配置和验证。
了解当前账户权益:查看定价与方案