数据库概要设计：E-R图绘制与关系表转换实战指南

1. 为什么概要设计阶段要先画E-R图

1.1 一张图解决的不只是“画什么表”的问题

进入数据库概要设计阶段，核心任务是从零散的需求描述中提炼出一份稳定的数据结构草案。很多人习惯跳过E-R图直接上手建表，觉得“反正最后也是要落成表，画图是多此一举”。我见过不少开发者在需求评审时拍着胸脯说“表结构我已经想好了”，结果开发到一半发现外键位置不对、中间表漏了、字段语义被两个人解读成两个意思，返工成本远高于当初画一张图的时间。

E-R图在这阶段的价值，不是“画出漂亮的图”，而是强制你把业务语言翻译成数据语言。实体、属性、联系这三类元素，本质上对应的是“系统里有哪些核心事物”“每个事物需要记录什么信息”“事物之间靠什么关系串起来”。这些如果不先在图上达成共识，后面写SQL时每个人都有自己的理解，数据库就成了各写各的烂摊子。

还有一个容易被忽略的点：E-R图是沟通工具，不是交付物。产品经理看不懂表结构，但能看懂“读者”和“图书”之间连着一条“借阅”的线。概要设计阶段画E-R图，等于给业务方和开发团队搭了一座桥，需求有问题在图纸阶段就能暴露，而不是等到联调时才发现字段对不上。

1.2 概要设计、逻辑设计、物理设计的分工边界

很多新手把概念模型、逻辑模型、物理模型混为一谈，导致在E-R图阶段就开始纠结字段类型和索引，反过来又有人在物理设计阶段才发现实体关系根本理不清。先明确边界：

• 概要设计（概念设计）：产出E-R图，只关心业务世界里有哪些实体、什么属性、什么联系。不涉及具体数据库产品，不写字段类型，不讨论主键用自增还是UUID。
• 逻辑设计：把E-R图转换成关系模式，确定每个表的主键、外键、约束，规范化到合适范式。
• 物理设计：针对具体数据库（例如MySQL、PostgreSQL、SQL Server）确定存储引擎、索引策略、分区方案、字段的精确类型。

E-R图阶段的正确姿势是：拿一张白纸（或画图工具），把业务描述中的人、物、事件画出来，连线标明关系，先不管数据库怎么实现。等这张图被业务方确认了，再做逻辑转换。用我常说的一句话：需求没理清之前，别碰CREATE TABLE。

1.3 什么样的项目尤其不能省这张图

经验下来，下面这几类项目最依赖E-R图的把关作用：

1. 实体超过10个的中大型系统。实体一多，联系就是指数级增长，靠脑子记必然出错。
2. 涉及多对多关系的业务。比如“一个订单包含多种商品，一种商品属于多个订单”，不画图几乎肯定会漏建中间表。
3. 多人协作开发的项目。每个人负责不同模块，实体之间的关联必须在图上统一定义，否则接口对齐时全是雷。
4. 后续要持续迭代的长期系统。E-R图是文档，是给半年后的自己看的。等人都走光了，新接手的人只能靠图去理解系统。

有一段真实经历：某个课程设计项目，三个成员各建各的表，A同学认为“班级”是“学院”的属性，B同学认为“班级”应该是独立实体，C同学干脆把班级表和外键都建好了。三个人吵了一下午，最后翻出最初的E-R图——图上周就画清楚了，只是谁都没按图执行。从那以后我养成了习惯：图纸必须先于建表，图纸变更必须先评审再动库。

2. 实体与属性的识别：先把“该画什么”定清楚

2.1 名词不等于实体：判定实体看三条标准

很多人拿到需求文档，第一反应是把所有名词都圈出来当实体。“用户名”“订单状态”“登录密码”“收货地址”这些名词如果全画成矩形，图就废了。实体的判定标准没那么宽松，我用三条规则卡：

1. 独立性：这个事物能否脱离其他事物单独存在？“图书”可以独立存在，哪怕没有任何读者。”订单状态”不行，它脱离了订单没有任何意义。
2. 多实例性：系统是否会保存这个事物的多个实例？一张表至少得能存多行才有意义。“学校名称”这种全局唯一值，适合做成配置或属性，不是实体。
3. 被引用性：是否有其他实体需要引用它的标识？比如“出版社”被“图书”引用，出版社是实体；而“作者简介”只是“作者”的一个属性，因为不会有其他表通过“作者简介”来找作者。

给个容易混淆的例子。“收获地址”在很多电商系统里是“订单”的属性，但如果用户有多个常用地址、需要维护地址簿，那地址就应该升级为独立实体，再和用户挂1:N联系。同一件事在不同业务里可能是属性也可能是实体，判断依据就是上面三条，尤其是“是否被独立维护”。

2.2 属性归属的主次判断

实体的属性要比实体好找得多，但属性的归属问题经常翻车。最常见的错误是属性挂错对象。“图书价格”挂在“出版社”上，就是笑话；“借阅日期”挂在“读者”上，那就彻底乱了。

判断属性归属我一般问三个问题：

• 这个属性直接描述谁的状态？价格描述的是图书本身，不是出版社。
• 如果换成另一个关联实体，这个属性还成立吗？“读者姓名”换成任何一位读者都成立，但它只属于当前这个读者；“图书分类”换成任何一本图书都有值，但它描述的是图书，不是读者。
• 这个属性的值随哪个实体的变化而变化？“库存数量”随图书变化，挂在图书上；“剩余可借额度”随读者变化，挂在读者上。

如果属性描述的是一个“动作”或“一次交互”的结果，比如“借出时间”“应还日期”“续借次数”，这些属性既不属于读者，也不属于图书，而属于“借阅”这个联系。这一步判断直接影响后续转换表时，是给“图书”表加个“最后借出时间”字段，还是建一个独立的“借阅记录”表。E-R图阶段想不清楚，建表阶段必然做出奇怪的设计。

2.3 主键属性怎么选择：业务主键还是代理主键

每个实体必须有主键，这是E-R图上必须标注的。主键的选择有两种路线，提前定清楚能避免后面一堆麻烦：

• 业务主键：用有业务含义的字段做主键，比如“图书编号（书号）”“身份证号”。优点是直观，团队不用额外记忆。缺点是一旦业务规则变化，主键就变成僵化的约束。
• 代理主键：用无业务含义的自增ID或UUID做主键，比如“book_id”。优点是稳定、不随业务变化，缺点是查询时经常需要额外关联才能拿到真正关心的业务编号。

我的原则是：业务主键只用于极稳定、全局唯一的场景，比如书号、行政区划代码；其余一律加代理主键。原因很实在——业务主键通常长度较长，做关联查询时索引效率不如整型自增ID。更麻烦的是，某些业务主键存在合并、拆分、重编码的可能，一旦变更，所有外键都得跟着改。用代理主键，业务编号只是普通字段，改起来安全得多。

E-R图阶段就要把这个决策标注出来，用下划线标注主键属性，避免逻辑设计时又来一次大讨论。

2.4 派生属性与复合属性的特殊处理

派生属性是指可以由其他属性计算得出的值，比如“读者年龄”由“出生日期”推导，“订单总金额”由各明细金额求和得出。处理原则很简单：不在E-R图上作为基础属性保存。如果确实需要展示，就标注为派生属性（用虚线椭圆区分），并注明计算逻辑。这样做的好处是避免数据冗余，也避免出现“年龄字段和出生日期对不上”的脏数据。

复合属性则需要决定到底拆不拆。比如“联系地址”包含了省、市、区、详细地址几个部分，如果业务上要按省统计、按市筛选，那就拆成多个属性；如果只是展示用，就保留一个属性。这个决定在E-R图阶段做，比建表后再拆字段要省事得多。

3. 联系的类型与基数：决定表结构复杂度的关键

3.1 从业务规则推导三个基数类型

联系是E-R图的灵魂。实体画得再准，联系标错，转出来的表结构照样不能用。三种基本基数类型并不难，难的是判断当前业务到底属于哪一种。

• 一对一（1:1）：A的一个实例对应B的唯一实例，反过来也一样。比如“员工”和“工牌”，一个员工只有一张工牌，一张工牌只属于一个员工。E-R图上在联系两端各标1。
• 一对多（1:N）：A的一个实例对应B的多个实例，B的一个实例只对应A的一个实例。比如“班级”和“学生”，一个班级有多名学生，一个学生只在一个班级。E-R图上在“多”的那一端标N。
• 多对多（M:N）：A的一个实例对应B的多个实例，B的一个实例也对应A的多个实例。比如“图书”和“读者”——严格来说是一本图书可以被多名读者借阅，一名读者可以借多本图书。E-R图上两端分别标M和N。

但注意，这里的判断完全依赖实际业务规则，不能拍脑袋。“图书”和“读者”这个例子，如果系统规定同一时刻一本图书只能被一名读者借走，那就变成1:N了——读者是“1”，图书是“N”。所以画图前必须找业务方确认一句话：有没有上限？有没有互斥？

3.2 基数约束里的业务语义不能丢

基数判断的本质是把业务约束翻译成结构约束。我举个例子让大家感受一下：

某学校要求每位导师最多带5名学生，每名学生只能选择一位导师。那么“导师-指导学生”是1:N联系，但N不能无限大，N ≤ 5。E-R图上虽然只画1和N，但这个“≤5”的业务规则要在需求文档或图上备注清楚，因为转换成表后，这对应的是应用层的校验逻辑，数据库结构本身无法约束上限。

再举一个容易画反的例子：“省-市”是1:N还是N:1？从概念上讲是一个省包含多个市，所以站在“省”的角度是1:N。画E-R时连线从“省”出发到“市”标N。到了转换表阶段，外键放在“市”表里，即“省编号”出现在“市”表里，因为N的一端需要携带1的一端的标识。

有一种情况很容易错：供应商和商品之间，一个供应商供应多种商品，一种商品也可以由多个供应商供应。这是M:N。但如果业务上规定“一种商品只能由一家供应商供应”，那就变成1:N。需求的一句话改动，直接影响要不要建中间表，这就是概要设计必须较真的地方。

3.3 联系本身带属性怎么办

联系不一定只是“连一条线”，很多业务信息挂在联系上。“读者借图书”这个联系至少携带“借书日期”“应还日期”“是否续借”。这时候有两个处理方向：

1. 把联系转化为独立实体（借阅记录），携带属性，再用两条1:N连线出去。
2. 把关联信息全部拆到子表里，用一条“借阅明细”表存储，本质上还是转化成了实体。

在E-R图上，典型的画法是把菱形框“借阅”用矩形包裹，或者直接标成“弱实体”。弱实体类似于依附实体——它无法脱离“读者”和“图书”而独立存在，它的主键往往是由关联实体主键加上序号组成。比如“借阅记录”没有自己的独立编号，含义上它就是“读者借阅图书”这一事件的具体化。

从建模习惯上讲，只要联系连带着两个或两个以上的属性，或者要记录“发生时间”这类信息，我就建议直接把联系升级为实体。这是数据库从业者的通用经验，因为转换到关系表时需要建立独立的表，提前在E-R图上把它画成实体，后面转换根本不费力。

3.4 三元联系与递归联系的实战处理

多数初学者只见过两个实体之间画连线。实际项目里会有更复杂的情况：

三元联系：比如“医生-患者-科室”之间，一次诊疗涉及三者。处理建议：先在E-R图阶段用三元菱形标注，到逻辑设计阶段，几乎总是拆成联系实体“就诊记录”——携带患者ID、医生ID、科室ID、就诊时间。E-R图阶段的“三线交汇”只是一个分析过程，最后落到表结构时，照样是一张中间记录表带多个外键。

递归联系：实体和自身发生联系。“员工”和“员工”之间的“上下级”，“分类”和“分类”之间的“父子关系”。E-R图上画一条从实体出发又回到自身的弧形连线，标上1:N。转成表结构时，就是在原表里加一个“上级ID”字段，自引用。

这两种情况不需要太紧张，知道它们的存在即可，多数业务建模前期碰不上。但一旦碰上，不要在E-R图阶段把三元联系强行拆成二元联系，那样会丢失业务语义。让分析保持在图上，转换在逻辑设计阶段统一进行。

4. 把E-R图翻译成关系表：转换规则与决策逻辑

4.1 实体转表、联系转外键的完整过程

E-R图画完验收通过，接下来就是经典的三步转换。我假设你已经画好了一张标准的E-R图，现在要落成CREATE TABLE。

第一步：每个实体转成一张表。实体名就是表名，属性就是字段，主键属性就是表的主键。这是最直观的一步，没有太多决策空间。

第二步：1:N联系，在N端实体对应的表里加一个外键字段，指向1端主键。例如“班级-学生”1:N，学生表加“班级编号”外键。为什么外键放N端而不是1端？因为N端的每一行都必须知道自己属于哪个1端，放N端查询最快，也符合数据库范式。如果放在1端班级表里存学生列表，就得用一个变长列表字段，直接违反第一范式。

第三步：M:N联系，新建中间表。中间表至少有两个字段：两边实体表的主键，两者联合起来通常作为联合主键，有时也加一个独立自增主键。中间表本身可以携带联系属性，比如“借阅记录”表的借书日期。

1:1联系则要按业务访问特点处理，我单独在下一节展开。

4.2 一对一联系的三条处理策略

1:1联系在转表时有三条路，按访问频率、数据变动频率、数据量大小做选择：

• 合并成一张表。两个实体的字段总量不大，且总是同时查询时，直接合并最省事。比如“员工”的“紧急联系人信息”，几乎和员工基本资料一起查，就没必要拆两张表。
• 将1:1联系当作特殊1:N处理，把外键放在其中一张表里，并加唯一约束。比如“员工”表里存“工牌编号”外键，并保证该列唯一。
• 保持两张表，通过相同的主键关联。适用于两个实体属性都很庞大，或者访问频率差异极大的场景。比如用户核心信息频繁读写，用户扩展资料极少访问，拆开降低锁竞争和备份成本。

业务上区分不出1:1的左右时，转换决策就从“性能”和“数据隔离”两个角度出发，这也正是概要设计为物理设计铺垫的意义。

4.3 转换后的逻辑模型示例：来一套完整的SQL

为了把上面的规则落到实处，我用一个“图书馆借阅系统”的简化例子把全过程串起来。假设E-R图上有这些核心实体和联系：

• 读者（读者编号、姓名、联系电话、可借额度）
• 图书（图书编号、书名、作者、出版社编号、馆藏数量）
• 出版社（出版社编号、名称、联系电话）
• 联系：读者-图书是M:N借阅，借阅联系带有借书日期、应还日期、归还日期；出版社-图书是1:N。

根据转换规则：

• 出版社、读者、图书三张基础表独立建立；
• 图书表加“出版社编号”外键；
• “借阅”是一个M:N联系，转换出“借阅记录”中间表，含读者编号、图书编号、借书日期、应还日期、归还日期。

建表SQL示意如下：

-- 出版社表 CREATE TABLE publisher ( publisher_id INT PRIMARY KEY AUTO_INCREMENT, publisher_name VARCHAR(50) NOT NULL, contact_phone VARCHAR(20) ); -- 图书表 CREATE TABLE book ( book_id INT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(100) NOT NULL, author VARCHAR(50), publisher_id INT, stock_count INT DEFAULT 0, CONSTRAINT fk_book_publisher FOREIGN KEY (publisher_id) REFERENCES publisher(publisher_id) ); -- 读者表 CREATE TABLE reader ( reader_id INT PRIMARY KEY AUTO_INCREMENT, reader_name VARCHAR(30) NOT NULL, phone VARCHAR(20), max_borrow_count INT DEFAULT 5 ); -- 借阅记录表 CREATE TABLE borrow_record ( borrow_id INT PRIMARY KEY AUTO_INCREMENT, reader_id INT NOT NULL, book_id INT NOT NULL, borrow_date DATE NOT NULL, due_date DATE NOT NULL, return_date DATE, CONSTRAINT fk_borrow_reader FOREIGN KEY (reader_id) REFERENCES reader(reader_id), CONSTRAINT fk_borrow_book FOREIGN KEY (book_id) REFERENCES book(book_id) );

请注意，我在转换时给“借阅记录”加了一个自增主键borrow_id，而不是用reader_id + book_id做联合主键。理由很现实：同一名读者可能反复借同一本书，如果以复合主键参与，无法表达多次借阅的历史记录。这是经验之谈，E-R图阶段虽然画的是M:N，转换时很多人想当然地用两张外键做联合主键，等到要记录同一对组合第二次发生时，才发现主键冲突。

5. 绘图的工具、规范与完整成图流程

5.1 工具选型：不用争论，合适就好

E-R图绘制工具从来不是技术难点，但选错了影响协作效率。我用过几类工具，做一个简单对比供参考：

工具类型	典型代表	优点	缺点	适用场景
通用绘图工具	在线绘图平台、桌面绘图软件	上手快，模板多	没有数据库专属约束，需要手动控制	临时草图、快速勾画
数据库建模工具	专业的ER建模软件	支持正向/反向工程，可导出SQL	学习成本略高	大型项目、需要持续维护
数据库客户端自带设计器	数据库管理工具的设计模块	边画边生成表结构	只能在特定库产品内使用	已经是明确选型后的物理设计阶段

概要设计阶段，我更推荐用通用绘图工具先把业务图画清楚，轻量、快捷、方便评审时现场改。项目定型进入逻辑设计阶段，再迁移到专业建模工具去管理版本变更。不要在一开始就陷进“画得漂亮”的需求里，那是本末倒置。

5.2 统一的图例规范：团队协作的基础

E-R图不是自嗨图，团队必须共用一套图例，否则换个人就看不懂。我现在会固定使用这套规范：

• 矩形框表示实体，框内写实体名，主键属性加下划线
• 椭圆表示属性，和对应实体用直线连接
• 菱形表示联系，联系名写中间，实体到菱形两端标注基数（1、N、M）
• 实线边表示实体有强制的关联，虚线边表示可选关联
• 弱实体用圆角矩形或双线矩形标注，联系实体用双层菱形标注

另外强调命名规范。实体名、属性名一律用有业务含义的名称，字符用英文、下划线或驼峰，团队统一选择一种风格。不要出现“a1表”“字段x”这种毫无语义的命名。E-R图阶段大家嫌麻烦，后面写代码时全在猜字段意思，那才是真的麻烦。

5.3 成图的七个步骤：从混乱需求到干净图纸

我画过的E-R图不下几十张，流程已经固定下来，这里直接分享：

1. 通读需求材料，把所有名词、动词摘出来，写在白板上。名词候选实体，动词候选联系。
2. 用2.1的三条标准筛选实体，去除伪实体，得到核心实体清单。
3. 为每个实体补充属性，用2.2的归属判断避免属性挂错。
4. 在实体之间画候选联系，先全部画出来，不管基数。
5. 逐个确认联系的基数，不确定的列个清单去问业务方。这一步是整个流程里最容易返工的，务必一次问清。
6. 给带属性的联系标注独立属性明细。如果联系带三个以上属性，直接升级为实体再画一次。
7. 最后检查整张图：有没有孤立实体没连线？有没有冗余的联系可以通过已有路径推导？属性有没有重复出现在多个实体里？

在实际操作里，第七步最容易发现问题。一次给某电商订单系统画E-R图，有个“收货人”实体，和“订单”“用户”之间都有联系。检查时发现收货人的信息几乎完全可以从“用户”表取到，而且收货人和订单的联系才是真正的业务必需，和用户的联系属于图上看着完整、实际冗余。删掉冗余联系后，表结构清爽不少。

6. 我在实际项目中反复踩过的E-R图设计坑

6.1 状态、类型字段被误画成实体

“图书状态”如果是“在馆/借出/下架”，这就应该是一个普通属性，或者用代码表的枚举值，不应该是独立实体。但很多人喜欢把这类字段画成实体再连一条线，理由是“状态还有很多后续信息”。问题来了：状态如果只是几个枚取值，独立成表纯属增加JOIN成本。

这条坑的判定经验：如果一个候选实体没有自己的非主键属性，没有其他实体引用它，那它就是属性的化身。别客气，压回属性那一层。

6.2 递归联系画对了，却忘了“层级深度”的语义

分类表设计成自引用，父子关系，这是E-R图阶段能画对的。但树表的坑在于层级深度的处理。如果业务上分类永远只有两级（比如一级分类、二级分类），自引用表完全够用；如果层级不确定（比如多级目录），光靠自引用加递归查询，性能会很难看。

E-R图阶段应该就把这个问题问清楚，并决定是否引入“路径枚举”方案。这不是逻辑设计才有的问题，E-R图不体现树模型，但树模型背后的业务约束需要在图上备注。轻描淡写地画一条递归线，后面写查询的人会很想摔键盘。

6.3 多对多中间表忘记携带业务字段

很多人画“订单-商品”M:N，转换时新建了中间表，但只放了订单ID和商品ID，就把E-R图上的联系属性全丢了。于是“订单商品数量”“购买单价”没地方放，只能硬塞进商品表或订单表，出现“一列多值”的典型反范式设计。

这个坑的根源在于：E-R图阶段把联系属性都挂在菱形“商品订购”下面，转换时没有同步从菱形搬进中间表。所以画图时的习惯很重要——只要画出了带属性的联系，转表前第一件事就是把这个联系作为独立实体处理，属性逐项落进新表。

6.4 循环引用导致删除和加载顺序全乱

实体之间可能出现循环引用。例如“订单”里放“员工编号”作为业务员外键，“员工”表里又放“最近处理订单ID”作为冗余引用。两个表互相引用，插入时必须先打破一个方向，删除时又互相依赖，代码里到处是临时置空逻辑。

E-R图阶段就要做环检查：把实体当节点、联系当边，跑一下有没有环。有环就重新审视哪些联系可以被舍弃或改造成普通字段。如果业务上确实避免不了，必须在图上标注“删除依赖顺序”，让后面的开发心里有数。最省事的方案是枪毙“员工表里放最近处理订单ID”这种冗余引用，让引用关系保持单向。

6.5 缺失的历史数据设计，字段信息保不住

E-R图只反映了“当前”的数据结构。现实中很多业务关心历史值变化——读者调整了额度，图书改了分类。如果在E-R图阶段没有“记录历史”的实体设计，后面想补就要大改表。旧值覆盖新值是最常见也最隐形的问题，接口调用方查不到历史记录时，才意识到结构上压根没留位置。

我在好几个项目里吃了这个亏之后，现在画图时会习惯性问一句：这个属性的变化过程，业务方要不要追溯？要追溯，就设计变化记录实体，把原属性保留为最新值，变化历史走独立日志表。两全其美，别等到上线后追悔。

6.6 一图到底，E-R图被改成了“物理模型”

最后一个常见问题，也是我特别想说的：E-R图是概念层的东西，不要在图上标注字段类型、默认值、索引、存储引擎、字符集。很多工具支持这些，画着画着就让人忘记了E-R图的本职。一但把物理细节混进去，评审时大家只顾着讨论“这个字段用VARCHAR还是TEXT”，业务逻辑反而没人看了。

我的做法是E-R图永远保持简洁，只有实体、属性、联系、基数。物理设计另开一张索引表、字段类型表去管理。两者分开后，沟通成本反而更低，E-R图回归到了它真正的价值——描述业务世界的关系结构。如果想在这个方向上进一步扩展，可以再把E-R图与数据库自动化脚本生成工具联动，正向生成建表DDL，校验模型一致性。不过那是后话了，先把图画对，后面的路才能走得稳。