ER 建模与数据库设计流程

一句话定义

ER 建模（Entity-Relationship Modeling）用「实体—属性—联系」三要素把业务世界抽象为图示模型，再按系统化流程翻译成关系模式，是从需求到表结构之间最重要的中间表示。

为什么重要

表结构是最难返工的资产：索引可加可删、SQL 可改可换，而错误的主键与关系拆分会让整个系统长期带着「设计债」。
ER 图是跨角色沟通语言：产品、后端、DBA 看同一张图对齐口径，比口头描述「一张表存什么」高效得多。
规范化流程（本知识点给流程、kp-007 给理论）能系统性消除冗余与更新异常，而不是靠直觉拼表。

前置知识

kp-002（关系、候选键、外键）。

核心概念

实体（Entity）：可区分的现实对象，如「客户」「订单」；弱实体（Weak Entity）依赖强实体存在（如订单明细）。
属性（Attribute）：实体的特征；区分「简单/复合、单值/多值、派生属性」。
联系（Relationship）：实体间的关联，带基数（Cardinality）：1:1、1:N、M:N；参与分「全参与/部分参与」。
联系转换为表：M:N 联系必须独立成表（含两端主键）；1:N 联系通常在「N 端」加外键；1:1 可合并或任选一端加唯一外键。
设计流程：需求分析 → 概念设计（ER 图）→ 逻辑设计（关系模式 + 范式检查）→ 物理设计（类型/索引/分区）。

原理与机制

建模的核心判断有两个。其一是「实体还是属性」：当某特征本身有独立生命周期或一对多特征（如用户的多个收货地址），应提升为实体，否则永远做属性。其二是「基数决定落表方式」：M:N 联系若强行放进某一端（存逗号分隔列表），会同时违反第一范式并丧失可查询性——这就是学生选课表（student_id, course_id）必然独立成表的理论原因。弱实体靠「强实体主键 + 区分键」构成复合主键（如 order_items(order_id, item_no)），天然与父实体同生共死。概念设计阶段的产出应与任何具体 DBMS 无关，物理考量（类型、索引）留到最后一阶段，防止过早优化污染逻辑模型。

实例或案例

电商最小模型：实体 Customer、Order、Product、Address；联系「下单」Customer-Order 为 1:N（一个客户多个订单，订单全参与——没有客户的订单不存在）；「订购」Order-Product 为 M:N 且带自身属性数量与成交价，独立成表 order_items(order_id, product_id, qty, price)；Address 与 Customer 为 1:N 独立成表（多值属性提升为实体）。得到的四张表正是后续 kp-007 范式分析的对象。

常见误区

把所有联系都建中间表：1:N 联系加外键即可，多余中间表增加连接代价。
在表里存「逗号分隔的标签列表」：违反第一范式，无法走索引与外键，应独立成关联表。
过早物化派生数据（如在客户表冗余「订单总额」列）：逻辑设计阶段应先保证无冗余，确有性能需求再在评审后有意反范式（kp-008）。

自测题

学生与课程为什么必须建中间表？答：二者是 M:N 联系，一个学生选多门课、一门课被多个学生选，任何一端存列表都违反第一范式且无法用外键保证参照完整性。
弱实体的主键如何构成？答：所属强实体的主键 + 自身区分键组成的复合主键，例如 order_items(order_id, item_no)。

公式或模型

本节不适用：本知识点为方法论，定量模型见 kp-007 的函数依赖体系。

图示

电商核心 ER 片段：M:N 联系「订购」落地为 order_items 中间表

直观类比

ER 建模像画建筑平面图：先定「房间」（实体）与「门」（联系），确认动线合理后才开始砌墙（建表）；跳过平面图直接砌墙，返工时砸掉的是承重墙。

与其他知识点的关系

kp-007 用函数依赖与范式检验本流程产出的关系模式；kp-008 说明何时有意破坏该规范；kp-003 的约束类型是逻辑设计落库时的工具箱。

前置知识点

相关知识点