数据库ER图怎么设计？从概念模型到关系表

设计数据库ER图时，应先确认实体和业务规则，再为实体定义稳定标识，按基数映射外键或关联表，最后用唯一、非空、检查和引用约束验证关系表是否能表达原始事实。

一、数据库ER图与关系表的衔接

数据库ER图连接业务概念模型和关系表设计。重点是实体边界、主键、外键、基数、关联实体和约束，而不是先列一张字段清单。

二、ER模型到关系表的映射

三、数据库建模的5个判断点

1. 先锁定概念实体

实体应来自业务对象和生命周期，不要直接把报表列、接口参数或页面字段当成最终表。

2. 为标识选择稳定主键

主键应能唯一识别记录且不随展示名称、状态或业务规则轻易变化。

3. 按基数放置外键

1:N通常在N端放外键；1:1和可选关系需要额外唯一或非空约束。

4. 把M:N拆成关联实体

关系属性如数量、角色、成交价和有效期不能丢在一条线里。

5. 用约束保护业务规则

非空、唯一、检查、外键和级联策略应能对应图中的基数与可选性。

四、把判断落成可评审模型的6步流程

1. 建立概念模型

从需求识别实体、属性、联系和基数，暂不绑定具体数据库方言。

2. 确定逻辑标识

为实体选择主键、候选键和业务唯一性，记录生成方式与生命周期。

3. 映射一对一关系

根据访问、所有权和可选性决定外键位置，并增加唯一或非空约束。

4. 映射一对多关系

在多端增加外键，确认删除、更新和孤儿记录处理。

5. 拆解多对多与多值

增加关联实体或子表，保存关系本身的属性和唯一规则。

6. 回到真实数据验证

用重复、缺失、迁移、删除和并发场景检查模型能否保护事实。

五、关系表设计的3个实际判断

1. 订单明细保存购买事实

订单与商品的M:N关系需要订单明细，数量和成交单价属于某次购买，不应覆盖商品当前价格。

2. 唯一不等于主键

邮箱、商品SKU可能需要唯一约束，但业务规则变化时仍应保留稳定的内部主键。

3. 可选关系需要落到约束

客户可以没有地址时外键可为空；订单必须属于客户时外键应非空并引用客户表。

六、AI辅助数据库建模时的3项人工检查

1. AI适合生成映射草稿

给出已确认的实体、基数和业务约束后，AI可生成候选表、外键和迁移检查清单。

2. AI不能决定数据所有权

模型可能把派生值、缓存和历史快照混为一谈；表的所有权与生命周期需要数据负责人确认。

3. SQL与图双向核验

生成SQL后用ER图检查基数和约束，再用数据库约束反查图是否漏掉实现限制。

七、交付前的数据库模型检查清单

1. 关系能映射成表

每条联系都有外键、关联表或明确不落表的理由。

2. 约束与基数一致

非空、唯一、外键和检查条件能阻止明显的非法记录。

3. 迁移和删除可解释

历史、删除、归档和级联行为在图或说明中有负责人和规则。

八、常见错误与修正方法

1. 先从字段清单画图

字段往往混合展示、计算和临时信息，直接画会丢掉实体生命周期。

2. 把M:N留成一条线就建表

关系属性和唯一规则没有位置，最终会造成重复或事实丢失。

3. 只画主键不画约束

没有可选性、唯一和删除策略，数据库仍可能接受违反业务的记录。

九、按任务继续阅读

• ER图概念与边界
• ER图符号与基数
• ER图怎么画
• ER图案例与模板
• ER图在线绘制工具

十、数据库ER图怎么设计常见问题

数据库ER图和普通ER图有什么区别？

数据库ER图更关注主键、外键、关联表、字段约束和关系表映射；普通概念ER图先解决业务实体与关系含义。

ER图如何转换成数据库表？

实体通常映射为表，属性映射为列，1:N在N端放外键，M:N增加关联表，再补充唯一、非空和检查约束。

主键和外键必须画在概念ER图里吗？

概念层可以先保持抽象；进入逻辑或物理设计时应明确主键、外键、唯一和可空性。

AI可以自动生成数据库ER图吗？

AI可以根据结构化需求生成初稿，但实体边界、主键、基数、约束和数据安全仍需人工与数据库测试确认。

十一、把模型转成下一步成果