企业官网建设流程全解析

1. 实训项目为什么必须从ER图开始：先建模还是先建表

带过几轮项目实训之后，我发现一个几乎每年都会出现的共性现象：小组拿到需求文档，后端同学第一反应就是打开Navicat开始建表，建到第三四张表的时候开始卡壳——读者和图书到底怎么关联？一个人借多本书，一本书被多个人借过，这外键加在哪边？然后一群人围在屏幕前争论半天，最后发现需求根本没理清，表结构推倒重来。

所以我现在带实训项目，第一周反复强调的就是一句话：先别急着写代码，更别急着建表，把ER图分析透了再动手。这句话不是老生常谈，而是无数个项目翻车换来的教训。数据库表结构是一个系统的地基，地基画歪了，后面所有功能开发都会跟着错位。你后端的Mapper要改、前端的接口要调、测试用例要重写，返工成本远比想象中大。

这里需要先明确三个层次的数据模型，很多教材讲过但实际做项目时大家容易混淆：

• 概念模型：与具体数据库无关，描述业务世界里有哪几类对象、对象之间什么关系。这一层用ER图表达，是需求分析阶段的主要产出。
• 逻辑模型：把概念模型转换成接近表结构的形式，确定主键、外键，考虑范式约束。也就是平时说的"关系模型"。
• 物理模型：落到具体数据库里，确定字段类型、索引、存储引擎，最终生成建表SQL。

ER图属于第一层，却直接影响第二层和第三层。实训项目里需求不会像真实企业那样有专门分析师来梳理，所以这一层更需要团队自己补上。什么时候画ER图最合适？我的建议是需求文档大致梳理完毕、功能清单列出来之后，用一到两天集中把ER图做出来，再进入表结构设计。

我见过不少同学觉得画ER图是"走形式"，直接打开MySQL Workbench反向后端表结构，生成一张表关系图就当作ER图交差。这是典型的把物理模型当概念模型用。ER图的价值在于逼着你去思考业务规则：读者能不能同时借十本书？一本书的副本怎么管理？超期罚款和借阅记录是什么关系？这些在表结构一旦定下来之后再改，代价完全不同。

2. 实体、属性、联系：ER图三大核心要素怎么判断

ER图看上去简单，无非是矩形、椭圆、菱形，但真正画起来，很多团队会在三个基础问题上反复扯皮：这个东西到底算实体还是属性？这个联系是几对几？属性该放这个实体还是那个实体？这些问题本质上是业务理解问题，不是画图技术问题。

2.1 实体判断标准：这个对象能不能被独立描述

实体（Entity）是现实世界中可区别于其他对象的"事物"。判断一个概念是否为实体，我常用的标准就一条：它有没有独立的特征需要被记录，并且能不能被唯一区分。

以图书借阅系统为例。"读者"是实体，因为读者有编号、姓名、手机号等一堆属性需要存，而且每个读者都有唯一编号。"图书"是实体，同理。但"借书"这个动作是不是实体？不是，它描述的是读者和图书之间的行为，应该用联系来表达。不过"借阅记录"是实体——因为每次借书行为产生了一条可独立描述的数据，它有借书日期、应还日期、归还状态这些自己的属性。

我经常用一个例子帮大家区分：地址。如果系统里只需要在读者信息里显示一个"联系地址"字符串，那它就是读者的属性。但如果你的业务需要对地址做统计分析，比如按城市统计读者分布，甚至地址本身包含省、市、区、街道多个结构化字段，那地址就值得独立成实体。判断的核心是"它自己有没有足够多需要管理的细节"。

2.2 属性取舍：什么时候属性该升级为实体

属性（Attribute）是实体的特征。画ER图时最容易被问住的是"出版社应该算图书的属性，还是独立实体"。

如果图书表里只记录一个出版社名称，那它是属性，没有争议。但现实中出版社还有地址、联系电话、成立年份这些信息，尤其图书馆采购图书时可能要按出版社维度的统计报表，留着这些数据价值很大。这时候把出版社独立成实体，与图书形成1:N联系，逻辑上更完整，后期扩展性也好。

我的经验是：当一个"属性"下面还挂着子属性，或者它自身需要被多个实体共享时，就应该升级为实体。例如"图书分类"，如果只是存一个字符串"计算机/文学/历史"，那是属性；但如果分类有编码、有层级结构、有排序号，再当作属性就会很别扭。

这里顺便强调一下主键。画ER图时就要把主键确定下来，而不是等到建表时再想。ER图的约定是主键属性的名称加下划线标注。图书编号、读者编号这种业务代码型主键适合实训项目，语义清晰，答辩时也容易解释；自增ID也可以，但要注意在ER图上说明清楚生成策略。

2.3 联系基数：从两端各问一次"一个对应几个"

联系（Relationship）是实体之间的业务关联，最关键的是判断基数（Cardinality）。基数有三种：1对1、1对N、多对多。

判断方法我教学生一个土办法：站在其中一个实体的一端，问"一个A最多对应几个B"，再站到另一端问"一个B最多对应几个A"，两个问题的答案组合起来就是基数。

举个例子，"学生"和"课程"：一个学生能选多门课，一门课能被多个学生选，所以是M:N。"国家"和"首都"：一个国家有且仅有一个首都，一个首都只属于一个国家，所以是1:1。"出版社"和"图书"：一个出版社出版很多书，一本书通常只属于一个出版社（暂不考虑联合出版），所以是1:N。

还有两个常见变体需要提醒：

• 部分参与约束：联系的实体是否需要全部参与。比如"管理员—图书"，一个管理员负责维护一批图书，但不是每本图书都有唯一对应管理员，这种在实操中往往做成操作日志，而不是直接建立外键关联。
• 三元联系：三个实体同时发生联系。图书借阅场景里，"读者—图书—管理员"在借阅行为中缺一不可，但更合理的建模是先拆"借阅记录"实体，再分别建立与三者的一对多联系。实训项目尽量不画三元联系，拆开更清晰，后面转关系模型也简单。

3. 图书借阅系统的ER图完整拆解：从需求文档到概念模型

图书借阅是图书馆的核心服务，也是实训项目里出现频率最高的题目之一。下面演示一遍从需求分析到完整ER图产出的全过程，这也是网上那些"ER图例题"最常考的类型。

3.1 从需求文本里提取实体清单

拿到一段需求描述，第一步是把名词圈出来。这个方法虽然原始，但确实好用。

原始的图书借阅系统需求通常包含：读者可以查询图书信息、办理借书和还书手续；管理员负责维护图书信息和读者信息；借阅时需要记录借书时间和应还时间；读者如果超期还书会产生罚款；图书有分类，方便读者按类别检索。

圈出名词后得到：读者、图书、管理员、借阅记录、罚款、分类、出版社。接着逐一判断它们是不是实体：

实训项目里如果时间有限，罚款可以先作为借阅记录的一个属性字段，不需要单独建模。分类和出版社是否独立成实体，取决于需求里是否有按分类浏览、按出版社检索的功能。我一般建议把这两个都做成独立实体，这样图更完整，转关系模型后表结构也更规范，答辩时也有材料可讲。

3.2 实体属性设计：先列必填项，再谈扩展项

实体确定之后，给每个实体列属性。属性列得好不好，直接影响后面建表能不能落地。

我习惯分两轮列属性：第一轮只列当前需求明确要求的数据项，第二轮再补充作为主键、外键关联所需的关键字段。以下是一组完整度适中的属性设计：

注意一个细节：读者实体没有直接放"借了几本书"这样的字段。数量信息不应作为属性存放，而应该通过关联查询计算得出。数据库设计讲第三范式，就是为了避免这种冗余。但"馆藏总量"和"可借数量"留在图书上是有意为之，这叫适度冗余，目的是让读者在查询图书列表时不用每次都统计借阅记录，这个取舍后面会细说。

3.3 联系与基数判断：读者、图书、借阅记录三者的真实关系

实体之间有哪些联系，同样回到业务规则里去逐个分析。

这里最关键在于读者和图书的M:N联系。概念模型阶段，我们可以直接用菱形画出"借阅"联系连接读者和图书，但到了第4章转关系模型时，这个M:N必须拆成"借阅记录"这个中间实体来处理。也就是说，"借阅记录"既是联系（语义上表达了借阅行为），又是实体（有自己的属性）。这种"联系实体"在ER图分析里是个核心概念，理解透了这个点，后面表结构设计就顺了。

3.4 画出完整ER图：实体、属性、主键、联系一图说清

把上面的分析落到图上，可以这样表示（用文字描述，实际画图时按同样结构）：

• 读者(读者编号, 姓名, 证件类型, 证件号码, 手机号, 邮箱, 注册日期, 状态)
• 图书(图书编号, 书名, 作者, ISBN, 出版日期, 价格, 馆藏总量, 可借数量)
• 管理员(管理员编号, 姓名, 登录账号, 密码, 联系电话, 角色)
• 借阅记录(借阅编号, 借书日期, 应还日期, 实际归还日期, 状态)
• 出版社(出版社编号, 出版社名称, 联系电话, 地址)
• 分类(分类编号, 分类名称, 父分类编号)

实体间联系：

• 出版社(1) —— 出版(N) —— 图书
• 分类(1) —— 归属(N) —— 图书
• 读者(1) —— 产生(N) —— 借阅记录
• 图书(1) —— 对应(N) —— 借阅记录
• 管理员(1) —— 办理(N) —— 借阅记录

这里借阅记录同时和读者、图书、管理员三个实体形成1:N联系，实际上就是把原来的M:N联系"借阅"处理成了实体后自然得到的结果。ER图画到这个程度，概念层面的分析已经完成，可以进入关系模型设计了。

4. ER图转关系模型：实训报告和面试都绕不开的转化规则

"ER图转化为关系模型"是实训报告和作业里必写的步骤，也是面试题里反复出现的内容。很多同学卡在这一步，本质上是对转化规则不够理解。这里把三条核心规则讲透。

4.1 三条转化规则：实体成表、外键承接联系、多对多拆中间表

规则一：每个实体转换成一张关系表，实体的属性转换成表的字段，实体的主键作为表的主键。

这条最简单，按实体属性清单建表即可，没有太多可说的。唯一需要注意的是主键的生成方式：业务主键用字符串，如读者编号"R001"，还是自增整数ID？实训项目两者皆可，但要统一，不要一半表用自增、一半表用业务编码。

规则二：1对1和1对N联系通过增加外键来实现。

1对N联系的处理方式是"在N端加外键"。比如出版社和图书的1:N联系，在图书表里增加出版社编号字段作为外键。1对1联系的处理方式灵活一些，可以在任意一端加外键，实操中一般把外键加在访问频繁或数据量更大的一端。比如"用户—用户详情"这种1对1，通常在详情表里加用户ID外键。

规则三：M对N联系必须拆成独立的关系表，表里包含两端的主键以及联系自身的属性。

读者和图书的M:N联系如果直接建外键，无论外键放哪边都没法表达"一本书被多个读者借过"这种关系。所以必须建"借阅记录"表，里面含有读者编号和图书编号两个外键，再加上借书日期、应还日期、状态等属性。

4.2 图书借阅落地示例：五张表的完整结构

把第3章的ER图按规则转化，得到如下表结构（这里先不谈用户扩展，按核心业务给五张表）：

读者表 reader

• reader_id（主键）
• name
• id_type
• id_number
• phone
• email
• register_date
• status

图书表 book

• book_id（主键）
• title
• author
• isbn
• publication_date
• price
• total_count
• available_count
• publisher_id（外键→出版社）
• category_id（外键→分类）

出版社表 publisher

• publisher_id（主键）
• publisher_name
• contact_phone
• address

分类表 category

• category_id（主键）
• category_name
• parent_id（自关联外键）

借阅记录表 borrow_record

• borrow_id（主键）
• reader_id（外键→读者）
• book_id（外键→图书）
• admin_id（外键→管理员）
• borrow_date
• due_date
• return_date
• status

能看到借阅记录表里三个外键分别对应读者、图书、管理员，这就是联系实体转化后的典型形态。管理员单独建表后，借阅记录通过admin_id记录"谁办理的这笔业务"，后面要统计某个管理员的办理量，一条SQL就能查出来。

4.3 面试和答辩常见问法以及答题思路

面试题里关于ER图转化最多的考法是：给一个多对多的业务场景，让你写出关系模式，或者反过来给几个表，让你画出ER图。核心考点就是多对多的拆解。

一个高频追问是："为什么需要中间表？不建中间表行不行？"回答思路是：关系型数据库只能表达表和表之间的1对多关联，多对多关系必须通过中间表转换成两个1对多。中间表里除了两端的主键，还能存放联系自带的属性。如果不建中间表，借书日期、还书状态这些数据就没有地方存放。

另一个高频追问是："借阅记录表的主键为什么不用复合主键？"用(reader_id, book_id)当复合主键，意味着一个读者对同一本书只能有一条记录，但实际借阅场景中读者借完还了再借同一本书，是允许产生多条记录的。所以实训项目里借阅记录更合适的主键是独立的borrow_id，而不是复合主键。判断依据是业务上是否允许重复联系发生。

关于"ER图转关系模型"还有一个通用做题步骤，我总结成五步：

1. 圈出所有实体，标注主键。
2. 判断每对实体间的联系及基数。
3. 1:1和1:N联系在相应表中加外键字段。
4. M:N联系建立独立关系表，放入两端主键和联系属性。
5. 检查每个表的主键是否唯一、外键是否指向明确，消除冗余。

5. 团队分工怎么切：ER图阶段的角色划分与接口约定

标题里"分工"这两个字，在实训项目里其实比ER图本身更容易翻车。很多小组习惯于"数据库同学画ER图，其他人等图出来再干活"，结果画图的同学既当分析师又当设计者，其他人全程围观，等到评审的时候一堆人提意见，画图的人改到崩溃。

5.1 反面案例：一个人画图全班等，是最差的分工方式

带实训时我看到过这样的真实情况：小组里A同学负责数据库，抱着需求文档闷头画了两天ER图，画完发到群里让大家确认。结果B同学说"这里读者和图书应该是多对多吧"，C同学说"管理员不用单独建实体吧"，A又改了一版。到了建表阶段，D同学说"借阅记录表为什么有三个外键"，A要重新解释一遍。整个流程特别低效，问题的根源就是ER图阶段没有把全员拉进来参与。

合理的做法是：ER图阶段全员参与，但角色分工不同。每个人都要看需求，但对不同模块负责程度不一样。我把角色分成四类：

实训项目的组员规模一般是4到6人，这个角色分配能保证每个人有具体任务，同时又不会出现有人完全没参与建模讨论。

5.2 按业务域拆分实体清单，各画各的再合并

实体比较多的时候，一个人握着所有实体画容易顾此失彼，而且画到后面会越画越乱。我建议按业务域拆分，把实体清单分成几组，不同组员负责不同的域。

以图书借阅系统为例，拆分成三个域：

• 读者管理域：读者、借阅证（若有）、罚款记录。
• 图书管理域：图书、出版社、分类。
• 流通管理域：借阅记录、预约记录、续借记录。

三个人各画自己负责的域的局部ER图，画完后开一次"合并会议"。合并时主要做三件事：统一实体命名、核对跨域联系、检查是否有遗漏实体。

跨域联系是合并时的重点，比如"借阅记录"同时连接读者域的读者和图书域的图书，属于流通域，但它引用了另外两个域的实体的主键。合并会议就要明确跨域引用的接口字段是什么、命名是否一致，比如读者主键在读者域叫reader_id，流通域也要叫reader_id，不能一会儿readerId一会儿读者编号。

时间节奏上，我通常建议实训小组按这样的节点推进：

这个节奏不是死规定，但至少要有明确的里程碑。没有截止时间的ER图阶段，往往会拖到编码前最后一天才草草完成。

5.3 统一规范：命名、主键、评审这三点提前约定

以下几个规范必须在画图开始前就定下来，否则中间一改就是连环修改。

命名规范方面，实体名一律用单数名词，比如book而不是books。字段名统一用下划线命名，如register_date。类型用integer、varchar、date这样的统一定义。这些规定看起来琐碎，但能在合并时省掉大量的对齐工作。

主键规范方面，每个实体必须设计主键，不能出现"感觉应该有个ID"但还没确定的情况。建议统一用编号字符串或自增整数，避免有的表用业务编码、有的表用自增，导致后面关联查询时类型不一致。

评审机制方面，我们实训里用的是"两轮评审"：第一轮画图人自讲，全员从业务角度挑刺，比如"管理员这个实体到底有没有独立存在的必要""罚款到底是属性还是实体"；第二轮按关系模型转化后的表结构再过一遍，检查外键是否引用明确。两轮评审后定稿，之后进入建表阶段尽量不做大的结构变更。

6. 画图工具选型：从白板草稿到团队协作的落地选择

ER图分析阶段用什么工具画，看着是个小事，实际上影响不小。选错了工具，光是同步和多端打开就够折腾的。

6.1 草稿阶段：白板和纸笔永远是最快的讨论工具

画ER图的前半程，我强烈建议用白板或者A4纸。它的优势不是美观，而是修改成本极低。三个人围在白板前争论读者和图书到底是M:N还是1:N的时候，拿白板笔涂改几下就能换一种表达，远比每个人在自己电脑上通过协同工具改来得高效。

实操中我会先让团队在白板上画出实体框，用几条线把联系连出来。这个阶段只看结构和争议，不去美化框线，也不管字体对齐。等实体、属性、联系都讨论清楚了，再进入电子工具做正式版本。

6.2 团队协作工具：draw.io和ProcessOn怎么选

进入正式版本阶段，工具选择要满足几个条件：免费或低价、支持多人协作、能导出图片嵌入实训报告。

draw.io（现在叫diagrams.net）是我用得最多的。它免费、免登录也能画，实体、联系用现成图形拖拽即可，文件可以存在本地也可以存Google Drive或GitHub，导出PNG、SVG都方便。缺点是初始界面略朴素，但画ER图完全够用。

ProcessOn的优点是对国内网络友好、模板丰富，搜"ER图"能找到大量现成模板直接改，上手门槛比draw.io还低。缺点是免费版有文件数量限制，团队多人协同免费版体验有限，导出也有水印或数量限制。

我的建议是：人多的实训小组用draw.io，文件让一位同学统一管理，其他人通过在线链接查看和评论；如果大家喜欢有模板参照，用ProcessOn也可以，但提前确认免费版够不够用。

6.3 Navicat和MySQL Workbench的逆向ER图：物理模型不等于概念模型

很多同学搜索"mysql的表导出er关系图"或"navicat画er图"，实际上是想把已经建好的表一键生成ER图，用于实训报告或答辩PPT。

Navicat的用法很简单：打开模型（Model）功能，新建模型后从数据库导入表，表之间的外键关系会自动生成线。MySQL Workbench则是在菜单栏选Database，点Reverse Engineer，按向导选择数据库连接和库，完成后生成一张EER图。

这种从表结构逆向生成的图，严格来说是数据库表关系图（物理模型），不等于业务层面的ER图（概念模型）。二者的区别在于：物理模型展示的是字段和外键，概念模型展示的是实体和业务联系。实训报告里最好两张图都有——概念模型证明你做了业务分析，物理模型展示落地实现，这样结构才完整。

在实训答辩时，如果老师问"你的ER图和表关系图有什么区别"，能答出这两个层次的区别，会是很加分的点。

7. ER图实战中的高频踩坑：这些教训每年实训都能见到

这一部分写的是我做实训辅导这几年里反复遇到的典型问题，每一条都有真实的反面教材，希望后面做项目的人能提前避开。

7.1 坑一：把联系当实体画，把实体当属性画

有个小组在画"预约借书"业务时，直接画了一个叫做"预约"的菱形连接读者和图书，没有给它设计任何属性。等到转关系模型的时候发现"预约时间""预约状态""失效日期"这些数据没有地方放，又回头在菱形外挂一堆属性，最后这个菱形实际上承担了实体的职责，本质上应该拆成一个预约记录实体。

区分方法很简单：如果一个联系本身有需要记录的数据项，它就应该作为联系实体来处理。联系实体在ER图中既表达联系又有属性，转关系模型时直接变成一个独立表，这是最规范的方式。

另一个方向的问题是把实体降级为属性。比如有人把"出版社"作为图书的一个属性字段，画图阶段觉得省事了，但后来想查"每个出版社出版了多少本馆藏图书"时，发现按文本字段group by确实也能查，但出版社改名、合并时根本没法维护。属性能否升级为实体，判断标准我前面提过：它是否有子属性，是否被多个实体共享。满足任何一条，都应该独立成实体。

7.2 坑二：同书多副本的业务细节没有建模

图书借阅系统有个典型业务细节经常被忽略：同一本书图书馆往往有多个副本，比如十本《活着》。一种设计是图书表里一条记录对应一个"品种"，馆藏总量10本；另一种是一条记录对应一个物理副本，每本书一个编号。

如果按"品种"建模，借阅记录里的book_id指向的是品种，那同一品种的10本被借出时，需要在借出时扣减available_count，归还时加回来。这种方案的问题是并发场景下容易超借，需要事务和状态校验。

如果按"副本"建模，每本书从采购入库起就有唯一的book_id，读者借到的是具体哪一本清清楚楚。缺点是同一品种的书在书架上会有多条记录，图书检索时需要按书名分组展示。

实训项目里我建议按"品种+可借数量"来建，简单直接，答辩时能把这个取舍理由讲清楚也能加分。如果你要挑战更复杂的方案，按副本建模也完全可以，但要在ER图上体现"品种"和"副本"两个实体，并明确它们之间1:N的关系。

7.3 坑三：评审只看图画得多不多，不看业务对不对

评审环节如果只是"大家看一眼这张图画得挺全，没什么问题"，那评审就失去了意义。无效评审最大的特征是只核对了实体数量，没有逐条核验业务规则。

我列一个评审检查清单，照着过一遍基本不会漏：

• 每个实体有没有明确主键，主键字段是否能唯一标识一条记录？
• 每一个联系你都能不能用一句业务话术描述出来？比如"一个读者可以产生多条借阅记录，一条借阅记录只属于一个读者"。
• 有没有列出联系基数的反面例子？比如问"同一个读者同一时间能不能借同一本书两次"，这个问题的答案决定了借阅记录表的主键是独立编号还是复合主键。
• 属性里有没有冗余字段？冗余字段如果在备注里说明用法，是可以接受的；如果没有任何解释，后期维护会一头雾水。
• 所有外键是否都来自某个实体的主键？外键字段名是否统一？

把这份清单打印出来，评审时逐条打钩，比一堆人围着图热烈讨论要高效得多。

7.4 给后面实训的一点个人经验

如果让我用一句话总结ER图阶段的要点，那就是"ER图不是文档负担，而是整个项目的第一份设计合同"。团队里每个人都应该在动笔写代码前，对这份合同达成共识。图画得越仔细，后面的开发、测试、答辩都越顺畅。

另外提醒一个小细节：最终定稿的ER图不代表项目过程中就不改了。实际开发中因为需求变更或发现新问题，ER图会被反复微调。每调整一次，记得同步更新关系模型和表结构文档，不要让ER图和实际数据库越漂越远。答辩时如果老师拿你交的ER图和数据库实际表结构对比，发现对不上，那才是真的尴尬。

做实训项目本来就是"在错误中学习"的过程，ER图分析这关过好了，后面的路会顺很多。至少我见过的项目里，凡是ER图阶段认真开过评审会的小组，代码阶段几乎没有人再回头改表结构。