企业官网建设流程全解析

简介：面向数据库初学者的ER图习题集，以PDF形式收录了17个典型场景的概念模型设计题，覆盖商业库存与销售、汽车运输、银行储蓄、体育锦标赛、超市连锁、大学教务、住院管理、证券业务等真实业务，适合高校学生、考研备考者及需要练习数据库概念模型设计的人群。压缩包内为单个PDF文件，大小仅83KB，轻量便携，可随时打开对照练习。目前已有2311人浏览学习。内容在每道题基础上给出实体、属性与联系解析，例如仓库-商店-商品间的库存/销售/供应三元联系、车队-车辆-司机的聘用/拥有/使用关系等，帮助读者抓住多元联系与基数判断的关键思路。通过完成这些习题，可以系统提升ER图绘制能力，为后续关系模式转换与数据库设计打下扎实基础。

1. 为什么一份 ER 图习题集值得认真对待：从这道题说开去

无论是期末备考、面试刷题，还是真正上手设计业务表结构，ER 图都是绕不开的第一道关口。很多开发者一上来就写建表 SQL，表建完才发现多对多关系漏了中间表、属性挂错了实体、外键方向反了，最后只能靠ALTER TABLE反复补救。数据库 ER 图习题.pdf 这类资料之所以有用，不是因为图本身难画，而是它逼着你面对一个最容易被忽视的问题：把一段业务描述翻译成结构正确的数据模型，你的翻译规则到底稳不稳。

我见过不少能把 SQL 写得飞快的开发者，一给业务场景让他画 ER 图就露馅，画出来的模型要么关系基数看错，要么属性归属混乱，要么弱实体和普通实体完全分不清。这些恰恰是习题集真正训练的东西。本文会带你从最核心的概念入手，把 ER 图怎么读、怎么做、怎么验证、怎么落成表结构一次梳理清楚，中间附上参数、示例和踩坑记录。适合正在复习数据库课程的学生、准备面试的求职者，以及想补建模基本功的在职开发者。这套东西不难，但值得认真过一遍。

2. 用 ER 图正确建立实体与关系：三个建模核心与两种画法

2.1 ER 图的三要素：实体、属性、联系，先把边界划干净

任何一张合规的 ER 图，本质上只表达三件事：实体是什么、属性有哪些、实体之间怎么联系。这三件事的边界如果划不干净，后面全部白搭。

先说实体。实体是现实中可区分的事物，学生、课程、订单、商品、班级都是实体。判断一个名词是不是实体的朴素标准是：它是否需要被单独记录和追踪。比如「学生的姓名」不是实体，它是学生的属性；但「学生」本身是实体，因为我们要存多个学生的多条信息。再比如「订单中的商品」，到底算实体还是属性？如果商品有自己的独立信息（价格、库存、分类）且需要被多个订单引用，它就是实体；如果只是附属于某个订单的一段描述文字，那它可以是属性。这个判断直接决定模型的结构。

属性相对简单，它是实体的特征描述。但属性也有两个容易出问题的细节点：一个是主键属性要标出来，一个是复合属性（如「家庭住址」由省、市、街道组成）要不要拆开。大多数习题不需要拆复合属性，如果你发现某个属性在业务里需要被独立查询或统计，比如按城市统计用户数量，那就该拆，否则不必强行分解，拆多了反而让图变得冗余。

联系是 ER 图的核心难点，也是习题集考察的重点。联系表达的是两个或多个实体之间的业务关联，比如「学生选修课程」是一个联系，「教师教授课程」是一个联系。联系本身也可以有属性，比如「选修」联系可以带「成绩」属性——这个成绩既不属于学生，也不属于课程，它只有在学生和课程发生关系时才存在，所以挂在联系上。

这里我先给一个自检小技巧：画任何一条联系线之前，先问三个问题——这个联系在业务上是否真实存在？它是一对一、一对多还是多对多？这个联系自己是否携带属性？三个问题都能回答，这条线才画得明白。

2.2 从一段业务描述中抽实体：抓名词、查动词、筛冗余

做习题时拿到一段业务描述，第一件事不是画图，而是把描述里的名词和动词分别圈出来。名词候选实体，动词候选联系。这是最朴素也最可靠的做法。

我一般分三步走。第一步，通读题目，把所有名词按出现顺序列出来，比如「学校、系、教师、学生、课程、教室、成绩、班级」。第二步，逐个判断：这个名词是否需要独立存储信息？「成绩」作为名词出现了，但它不是实体，它是学生和课程之间选修联系上的属性；「教室」如果题目只提了「上课地点」这个词，且不需要记录教室容量、位置等独立信息，那它大概率就是个属性。第三步，用动词验证联系：学生「选修」课程、教师「讲授」课程、系「管辖」班级，这些动词对应的主谓搭配必须能成立，如果主语和宾语有一方不是实体，这个联系就不成立。

我踩过的典型误区是「看到名词就实体的条件反射」。A 同学做练习时把「学生姓名」单拎出来作为一个实体，理由是它存储的信息不少。结果自检时发现姓名表和学生表之间是一对一关系，然后还得用外键关联，纯属自我制造工作量。判断一个名词是实体还是属性，有一个更硬的标准：它需不需要以行（记录）的形式被独立存储和检索。姓名是学生表的一列，不是一张表。同样的逻辑适用于地址、电话、邮箱这类描述性名词。

另外一个容易漏掉的是「多值属性」的存在。比如一个学生有多个手机号，这属于多值属性。在 ER 图上，正规画法是用双线椭圆表示多值属性；但如果手机号需要被单独查询，比如按手机号定位到学生，那就应该把手机号拆成一张单独的联系或实体表。习题里如果明确说了「一个学生可以有多个联系电话」，你需要决定是按多值属性画还是在转换阶段拆成子表——我的建议是直接拆成子表，因为大多数习题后续会要求转关系模式，多值属性在关系模式里是要单独成表的，一步到位更省事。

2.3 关系基数的判定方法：从业务语义反推而不是从句子结构硬猜

关系基数（1:1、1:N、M:N）判定错，是所有 ER 图错误里最致命的一类，因为它直接决定最终的建表结构。判定方法是固定套路：对每一对实体，分别从两个方向问「一个 A 最多对应几个 B」和「一个 B 最多对应几个 A」，两个答案合起来就是基数。

举个例子，「班级—学生」：一个班级对应多个学生，一个学生只属于一个班级，所以班级和学生是 1:N，班级是一端，学生是多端。再比如「学生—课程（选修）」：一个学生可以选修多门课程，一门课程可以被多个学生选修，所以是 M:N。这个方向要特别注意，很多人从文字表述的先后顺序去猜，把「学生选修课程」画成 1:N，理由是一句中文读下来像是一对多，这是完全错误的。必须双向验证。

M:N 关系在 ER 图上表示为实体间的菱形连线，而它的处理方式是习题集中最重要的考点之一：必须拆成中间表，否则两个实体的表结构无法干净落地。到时候在第三张章会用完整示例演示。

一对一关系比前两者少见，但更容易出错。典型场景比如「系—系主任」：一个系只有一个系主任，一个系主任只管一个系。这种关系在落到关系模式时需要选择一个方向放外键——到底在系表里放主任编号，还是在主任表里放系编号，两种做法都可行，但选择依据是查询方向。如果业务上经常从系查到主任，就在系表放主任编号作为外键；如果经常从主任查到系，就反过来。选择标准我会在 3.3 里展开说。

这里必须提醒一个常见误判：不要把同一张表内部的自引用关系升级为 M:N。比如「员工—员工」之间的上下级关系，一个员工有一个上级，一个员工有多个下属，这是 1:N 的自引用，不是 M:N，不需要中间表，只需要在员工表里加一列manager_id指向自己的主键。习题里但凡出现「员工」「领导」「上级」这类描述，先检查是不是自引用关系，再用基数判定法验证。自引用方向反了也会出大问题。

3. 把 ER 图转成关系模式：这是习题集里最值钱的一步

3.1 转换五规则：实体成表、属性成列、关系决定外键

绝大多数数据库习题在画完 ER 图之后都会要求「将 ER 图转换为关系模式」，这个转换过程有固定规则，不讲技巧、不需灵感，你只需要按规则走就能拿全分。

规则一：每个强实体转换成一张表，实体名就是表名，实体属性就是表的列。规则二：实体的主键就是表的主键。规则三：1:N 联系，在 N 端（多端）表中添加一个外键列，引用 1 端表的主键。规则四：M:N 联系，新建一张独立表，表里至少包含两个实体的主键作为外键，(A 主键, B 主键) 联合作为新表的主键，联系自身的属性也放进这张表。规则五：1:1 联系，任选一端的表添加另一端的主键作为外键，也可以干脆合成一张表，视业务而定。

这套规则看似简单，真正执行时最容易出问题的不是规则本身，而是「关系属性到底放哪」。举个例子说明完整流程：业务描述是「一个学生可选修多门课程，一门课程可被多名学生选修，学生选修课程产生成绩」。实体是学生和课程，联系是选修，M:N。那么转换结果是：

-- 学生表：强实体，直接转换 CREATE TABLE student ( student_id CHAR(10) PRIMARY KEY, -- 学号作为主键 student_name VARCHAR(50) NOT NULL, gender CHAR(1), enroll_year SMALLINT ); -- 课程表：强实体，直接转换 CREATE TABLE course ( course_id CHAR(8) PRIMARY KEY, -- 课程编号 course_name VARCHAR(80) NOT NULL, credit DECIMAL(3,1) -- 学分，允许 3.5 这种小数值 ); -- 选修表：M:N 联系拆出的中间表 CREATE TABLE takes ( student_id CHAR(10), course_id CHAR(8), grade DECIMAL(4,2), -- 成绩：联系属性放中间表 PRIMARY KEY (student_id, course_id), FOREIGN KEY (student_id) REFERENCES student(student_id), FOREIGN KEY (course_id) REFERENCES course(course_id) );

代码逻辑和参数说明如下：takes表是 M:N 联系的核心产物，它的主键由两个外键共同组成，这保证了同一条学生-课程记录不会重复插入。grade字段是联系自身的属性，它不属于 student 也不属于 course，必须放在中间表上。DECIMAL(4,2)允许最大 99.99 的成绩值，如果题目要求百分制整数，那用TINYINT UNSIGNED更合适——这是你需要根据题目要求调的地方。CHAR(10)用于学号是因为学号通常定长且不会参与计算，如果用VARCHAR(10)也不是错误，但定长字符在 MySQL 里做等值检索时性能略优，你需要有自己的选择依据。

3.2 多对多联系必须拆中间表：为什么不能直接在两个实体表里互加对方主键

这个问题我在批改练习时见过无数次，也是在初学阶段最容易犯的设计硬伤：把 M:N 关系直接在两个实体表里互加外键列。

错误做法是有诱惑力的——直觉上，学生表里加一个「已选课程 ID」的字段，课程表里加一个「选课学生 ID」的字段，看起来就能表达关系了。但稍微推演一下就会发现死路：一个学生选了三门课，course_id字段里要存三个值，这违反了第一范式；如果把三个值用逗号拼接成一个字符串，那你将会需要在应用层split字符串来做任何关联查询，完全失去 SQL 的关联能力，外键约束也会失效。这是黑匣子一样的隐患，当时没事，一查数据全乱。

拆成中间表之后，一个学生选多少门课都对应中间表的多条记录，每一行都是原子值，外键约束、级联删除、JOIN 查询全部正常工作。判断一个关系是否需要中间表，就一句话：从两端看都是一对多，那这个关系就必然是多对多，别想着省一张表。

另外要注意中间表主键的选择。上面示例用双外键联合做主键，这是默认做法。但如果中间表自己还有多层含义，比如同一学生同一课程有多次重修记录，那么双外键联合主键就不够用了，需要加一个自增列作为代理主键，双外键作为普通外键并加联合唯一索引。这两种写法的差异是一个常见的进阶考点：

-- 带重修记录的中间表，允许同一学生同一课程出现多行 CREATE TABLE takes_with_retake ( takes_id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, student_id CHAR(10) NOT NULL, course_id CHAR(8) NOT NULL, grade DECIMAL(4,2), retake_count TINYINT DEFAULT 0, UNIQUE KEY uk_stu_course_retake (student_id, course_id, retake_count), FOREIGN KEY (student_id) REFERENCES student(student_id), FOREIGN KEY (course_id) REFERENCES course(course_id) );

参数说明：AUTO_INCREMENT代理主键让每一条重修记录有独立标识；联合唯一索引uk_stu_course_retake只是约束了「同一学生同一课程同一次重修」不重复，但不能防止不同重修次数插入多行——这正是我们想要的。TINYINT选它是因为重修次数理论上不会超过 127，没必要用INT占用 4 字节。这里要记住一个点：不要盲目给中间表加代理主键，能不加就不加，联合主键本身已经能完成大多数场景的完整性约束，加代理主键会让索引体积变大、写入多一次索引维护。加的说清楚为什么加，不加的也说清楚为什么不加，这才算把这块吃透了。

3.3 一对一的三种落表方式与选择依据：外键放哪端，答案在查询里

一对一关系的落表方式有三种，各有适用场景。第一种是合并成一张表，适用情况是两端实体在业务上总是同时访问，比如「用户」和「用户扩展资料」，合并之后查询少一次 JOIN。第二种和第三种分别是把外键放在 A 表或 B 表，选择依据是「哪端在业务里先从自己出发去查对方」。

举个具体习题例子：「每个系有一名系主任，每名系主任只管理一个系」。实体是系（department）和教师（teacher），关系是「系主任任职」1:1。两个落表方向：

-- 方案一：外键放系表，适合经常从系信息出发查主任是谁 CREATE TABLE department ( dept_id CHAR(4) PRIMARY KEY, dept_name VARCHAR(50) NOT NULL, chair_teacher_id CHAR(6), UNIQUE KEY uk_chair (chair_teacher_id), FOREIGN KEY (chair_teacher_id) REFERENCES teacher(teacher_id) ); -- 方案二：外键放教师表，适合经常从人出发查他在哪个系当主任 CREATE TABLE teacher ( teacher_id CHAR(6) PRIMARY KEY, teacher_name VARCHAR(50) NOT NULL, manage_dept_id CHAR(4), UNIQUE KEY uk_dept (manage_dept_id), FOREIGN KEY (manage_dept_id) REFERENCES department(dept_id) );

注意两种方案都加了UNIQUE约束——这才是 1:1 关系落表最关键的一步。不加UNIQUE的话，外键列可以重复，关系就退化成 1:N 甚至 M:N 了，外键约束只保证引用存在，不保证唯一。你可以把 UNIQUE 约束看成是数据库在强制执行「一对一」的语义。丢了它，整个 1:1 设计名存实亡。

选择哪一个方案，我的经验是看高频查询的方向：系统里最常见的页面是「系信息页显示主任名字」，那就在 department 表放外键；最常见的是「教师详情页显示他当主任的系」，那就放 teacher 表。没有唯一正确答案，但必须有决策依据。习题考试里默认选哪端都行，你只需要在答案里写一句「外键设置在 X 端，理由是从 X 端查询 Y 更为频繁」，这就是满分答案的样子。

关于合表做法，要谨慎。合表虽然查询最快，但会把两类内聚度不同的属性搅在一起。如果未来业务上「用户核心表」和「用户扩展表」被不同的服务访问，强行合表会让服务之间的数据权限难以划分。模块划分时一张表只属于单一领域服务的原则在多数情况下比「少一次 JOIN」更重要。

4. 做 ER 图习题的避坑指南：这些错误我批改时见到最多

4.1 把「不需要记录的数据」硬建模成实体，导致表数量失控

现象：提交的答案里，学生表旁边还立了张「学生手机号表」，课程表旁边立了一张「课程教材表」，最后实体数量比题目描述的名词数量还多，关系模式里 70% 是两列的小表。

原因：没有先做「是否需要独立存储和检索」的判断，看到关键词就想当然。比如题目只说「课程有教材名称」，那教材就只是 course 表里的textbook_name一列，不需要单独一张表。

解决：建任何实体之前问一句：这个对象有没有除了名称之外的独立信息需要记录？如果没有，它就是属性。拿不准的时候可以反向测试：如果把「教材」当成属性塞进 course 表，查询「所有使用某本教材的课程」会不会受影响？不会的话就不要拆实体。做习题时可以用这条规则筛掉至少三分之一的多余实体。

4.2 M:N 识别失败：漏拆中间表或者中间表主键设计成单列

现象：学生和课程多对多，但只有两张表，没有中间表；或者有中间表了，但主键只有一个student_id，导致同一学生同一课程无法存在多条记录，成绩项被覆盖。

原因：基数判定没做双向验证；或者是做中间表时「顺手」把其中一个外键设成了主键，没有意识到 M:N 关系里必须两个外键联合才能保证记录的粒度。

解决：画图阶段就双向问「一个 A 对应几个 B」和「一个 B 对应几个 A」，任一端出现「多个」，就把逻辑标在图上。转关系模式时，凡是在图上标记了 M:N 的菱形，直接套中间表模板：联合主键 + 两个外键 + 联系属性列。自检写一道查错语句：如果你在中间表定义里没有看到PRIMARY KEY (外键1, 外键2)，那大概率就是错了。

4.3 弱实体识别错误：把弱实体当成普通实体，生成孤儿记录

现象：题目描述「一个职工有多个家属，家属依赖职工而存在」，答案里家属表完全独立存在，有自己独立的主键，跟职工表只是普通外键关系。业务上家属离开了职工就没有存在意义，这种数据应该由职工记录的删除级联清除，而不是独立存活。

原因：没有明确「弱实体」和「普通实体」的分界线。弱实体必须依赖另一个强实体而存在，它自己没有足够的主键属性来独立标识一条记录。家属表如果没有职工 ID，单靠家属姓名这种属性根本无法区分不同职工的重名家属。

解决：识别弱实体看两点——业务上离开父实体是否还有存在意义，以及是否无法独自构成主键。如果答案是「没意义」和「无法独自构成主键」，那就是弱实体。落表时把弱实体的主键定义为「父表外键 + 判别符」的联合主键，而且外键必须加ON DELETE CASCADE：

CREATE TABLE dependent ( employee_id CHAR(8), dependent_name VARCHAR(50), relation VARCHAR(20), birth_date DATE, PRIMARY KEY (employee_id, dependent_name), FOREIGN KEY (employee_id) REFERENCES employee(employee_id) ON DELETE CASCADE );

这里PRIMARY KEY (employee_id, dependent_name)正是弱实体「部分键（partial key）」的体现：同一个员工名下不能有重名的家属，不同员工之间重名无所谓。ON DELETE CASCADE保证员工离职后家属信息自动清理，不产生孤儿数据。忘记 CASCADE 是另外一半人容易犯的延伸错误——弱实体的外键不带级联删除，这个弱实体约束就不完整。

4.4 属性归属错误：把联系属性挂在实体上，导致语义错位

现象：先看两版建表。错误版把成绩做成学生表的一列grade，或者做成课程表的一列。正确版是放在中间表。

原因：没有理解「成绩」这个值依赖于「学生-课程」这个配对，它在业务里天然属于联系而不是任何单端实体。把它放在学生表，就会发生一个学生选了五门课，学生表里只能存五个成绩值，一个字段装不下，又回到第一范式的那条岔路上。

解决：判定属性归属的万能方法：造一个英文句子「A 的 B 是在与 C 的关系中产生的」，如果句子成立，这个 B 属性属于 A 与 C 的联系。举个例子：「学生的成绩是在与课程的关系中产生的」，成立，所以成绩属于学生和课程的选修联系，放进中间表。再试「学生的性别是在与课程的关系中产生的」，不成立，所以性别是学生实体的自身属性。这个造句法虽然土，但在做习题时快且准，我一直在用。

4.5 复查顺序：一套五步自检清单

做完一张 ER 图或一套关系模式，按固定顺序复查五遍，能拦截大部分低级错误。

第一步，检查每个实体是否有主键，主键是否最小（不要有多余列）。第二步，逐条联系线验证基数，双向问「一个 X 对应几个 Y」。第三步，检查 M:N 联系是否有对应中间表，中间表主键是否为联合形式。第四步，检查外键引用列与对应的被引用主键列类型是否完全一致——包括数据类型和长度，CHAR(10)的学号不能引用CHAR(8)的列，MySQL 在有一部分类型不一致时会直接建表失败，其余情况会留下隐患。第五步，做语义终检：拿着建好的表名和列名，对着题目原文逐句念一遍，每一句业务描述必须能在表结构里找到位置。这五步做完，习题的正确率会有非常明显的提升。一套检查顺序固定下来，比漫无目的的看图高效太多。

5. 用工具验证练习结果：从 ER 图到 MySQL 建表语句的落地

5.1 MySQL Workbench 的 EER 图建模：从画图到导出 SQL 的最小操作

手绘 ER 图可以训练建模思维，但它验证不了表结构是否合理。我把练习的最后一关固定为「画图工具出图 + 自动导出建表语句」，让工具帮我抓漏。MySQL Workbench 是这一步的主力工具，免费且对习题场景足够用。

常见做法是在 Workbench 中新建一个 EER Model，然后按下面步骤操作：

# 没有安装 MySQL Workbench 的话，在 Ubuntu/Debian 上可这样装 sudo snap install mysql-workbench-community

打开后选择 File → New Model，双击Add Diagram进入画布。右侧面板拖入 Table 节点，双击表名进入编辑区：设置表名、添加列名和数据类型、勾选 PK/ NN / UQ / AI 约束。设置外键的正确姿势是双击关系连线——选中两个表的关联列，Workbench 的 Foreign Key 面板会自动生成引用关系，不需要手写 SQL。

画完图之后最关键的一步是让工具替你做复查：Database → Forward Engineer，选择导出到 SQL 文件而不是直连数据库，得到一个完整建表脚本。把脚本里的表结构和你手写的答案对照，工具生成的 SQL 会强制使用它自己的命名规范，比如FK_table1_table2，对照时你把注意力集中在列名、类型、约束上，不要在命名前缀上花时间。

这步能立刻暴露的问题包括：外键忘加（工具生成时对应关系连线缺失）、数据类型在列定义时选错（比如主键选了INT但业务上需要BIGINT）、联合主键没有在表定义里正确勾选多列。Workbench 这类的图形工具本身不会判断你的模型正确与否，但它能把你的设计固化成精确的 SQL 文本，错误反而更容易暴露。

5.2 从导出的 SQL 逆向检查 ER 图：通过正向和逆向比对确认设计一致性

只做正向导出，得到的 SQL 很可能带着你自己建模时的错误一路输出，所以必须做第二步：把导出的 SQL 重新逆向导入为 ER 图，看看工具理解出来的模型是否与你的本意一致。

MySQL Workbench 的做法是File → Import → Reverse Engineer MySQL Create Script，选到刚导出的文件，工具会重新生成一个 ER 图。然后对比两件事：实体数量是否一致；每个联系的类型是否一致。如果工具逆向出来的 M:N 联系在你原图里显示的是 1:N，说明你在画图时联系定义有偏差——很常见的具体表现是：你原本想画学生和课程的多对多，但 Workbench 的建模面板里只定义了一个外键方向，另一次外键没有被识别，导致 M:N 退化成 1:N。这种问题看图画未必看得出来，逆向对比一轮，马上暴露。

这里值得留意一个通用工具使用技巧：正向导出和逆向导入形成的闭环，本质上是「设计意图」和「机器理解」之间的一致性问题。做习题时你希望的是「机器理解 = 题目要求」，所以正向导出后逆向导入这个动作千万别省。第一遍做时可能要多花二十分钟，但每次都能发现一个小错误，几次之后所有常见坑都被模型记住了。

5.3 PowerDesigner 与 draw.io 的选型参考：谁的颗粒度适合你

不是所有人都喜欢用 MySQL Workbench。习题练习环境下，我推荐三个工具，按场景选。

第一个是 PowerDesigner，老牌建模工具，功能重量级，支持概念数据模型（CDM）、逻辑数据模型（LDM）、物理数据模型（PDM）三层分离，适合做大型业务系统的数据架构设计。它能把概念模型自动映射为物理模型，生产级项目里使用广泛。缺点是启动慢、界面复杂，做几道练习题有点杀鸡用牛刀，但如果你工作环境里已经在用它，拿它练手完全没问题。

第二个是 draw.io（也叫 diagrams.net），免费、轻量、纯网页可用。它适合快速画 ER 图来辅助思考，画完可以导出 PDF 或者图片放进答案。但它的绘制方式本质是自由画布，表和联系之间没有真正的「模型」语义层，也就是说你画出来的菱形连线和矩形方块图无法被工具理解成外键关系，也无法直接导出建表语句。如果你的需求只是把图做出来给人看，draw.io 足够；如果你需要验证表结构，还是回到 Workbench 这类带模型语义的工具。

第三个是 Navicat Data Modeler 这类数据库客户端附带的建模扩展，优点是和实际数据库连接打通——你可以在库里建好表，然后反向生成模型，方便做「练习答案 vs 实际 LaunchDB 表」的对比。但它不是免费的，且功能覆盖不如 Workbench 全面，学生党一般不需要特意购买。

我的选型经验是：做练习阶段用 Workbench 足够，它恰好横跨「画图」和「生成 SQL」两个能力；当题目复杂度上升，比如要处理几十张表的分层设计，再考虑 PowerDesigner 的概念模型与物理模型分离能力。

5.4 让工具讲题：把习题描述转成 SQL 再转回 ER 图，你会看到什么

一个模拟场景：题目描述「医院有多个科室，每个科室有多名医生，一名医生只能属于一个科室；一名医生可以负责多个病人，一个病人可以被多名医生治疗；每名医生对每个病人的治疗记录包含治疗日期和诊断结果。」现在把这个描述手画成 ER 图，然后按 5.1 和 5.2 的流程用工具建模并导出 SQL。你会得到如下表结构：

CREATE TABLE department ( dept_id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, dept_name VARCHAR(50) NOT NULL UNIQUE ); CREATE TABLE doctor ( doctor_id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, doctor_name VARCHAR(50) NOT NULL, dept_id INT UNSIGNED NOT NULL, FOREIGN KEY (dept_id) REFERENCES department(dept_id) ); CREATE TABLE patient ( patient_id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, patient_name VARCHAR(50) NOT NULL, birth_date DATE ); CREATE TABLE treatment ( doctor_id INT UNSIGNED, patient_id INT UNSIGNED, treatment_date DATE, diagnosis VARCHAR(255), PRIMARY KEY (doctor_id, patient_id, treatment_date), FOREIGN KEY (doctor_id) REFERENCES doctor(doctor_id), FOREIGN KEY (patient_id) REFERENCES patient(patient_id) );

参数说明有两点值得注意。第一，treatment表主键是三列联合而不是两列，因为描述里提到「每名医生对每个病人的治疗记录」——如果同一天、同一医生、同一病人只存在一次诊断，三列联合主键刚好满足；但如果有「同一天内同一医生给同一病人看两次病」的业务，那必须再加一个就诊序号字段进主键，或者换成自增代理主键。第二，department.dept_name加UNIQUE是因为科室名称在业务上自然不可重复；doctor.dept_id没有加UNIQUE，因为一个科室有多个医生，这个外键是可重复的，它的粒度和 department 的主键粒度不同，约束自然不同。

用工具导出完这段 SQL 后，你对照手写的答案会发现一个常见隐藏错误：很多人画医生和科室时，在 doctor 表里设置了dept_id但忘了加NOT NULL。如果某个医生可能暂时没有分配科室，那NOT NULL不应该加；如果题目隐含「每个医生都属于且必属于一个科室」，那必须加NOT NULL。这就是题目语义对字段约束的影响，工具本身不会帮你判断这个是该不该为空的问题，需要你在画图阶段就意识到它属于「参与度约束」（total participation）。

6. 进阶：把 ER 图习题当校验集的技巧：一题三做，让答案之间互相验证

练习册的价值不在做题本身，而在「一题三做」——同一道题用三种不同产出物去表达，让它们互相校验。养成这个习惯之后，你做的不再是题，而是一套对数据模型的反复确认过程。

第一遍做：拿到题目纯手绘 ER 图，不允许打开任何工具，用笔或任何画图应用把实体、属性、联系画出来，标清基数。这一步训练的是建模直觉，也是考试时的真实状态。第二遍做：不回头看图，直接依据题目原文写关系模式——强实体成表、联系定外键、1:1 选方向、M:N 拆中间表，每一步都要能说清依据。第三遍做：拿第二遍写出的关系模式建 SQL 表，然后在本地或工具里反向生成 ER 图，与第一遍的手绘图逐项对比。多个实体之间数量不一致的、联系类型对不上的、属性列归属错位的，在这一轮都会露出马脚。

这一步我管整个方向叫「把习题当作一套校准数据集」：手绘图是主观版本，SQL 是客观版本，两者对齐之后，你对「从业务描述到表结构」这条链路的理解就完成了一次闭环验证。很多人练 ER 图只练到「把图画完对一下答案」，这其实只完成了一半训练。正如增删改查不是数据库的全部，ER 图也不是只画不建。画完图能干活，干完活能回查，这才算真正掌握了建模能力。

我自己早年做练习时图省事，直接跳过手绘，开着工具一边看题一边拖表，结果考试时离开工具完全画不出连贯的图。后来被某公司的笔试题按在地上摩擦了一次，才老老实实回到「三做」这套笨办法。练了不到两周，画图速度和准确率都上来了。现在每次拿到新的业务需求，我仍然会在纸上过一遍实体和关系线，再开工具建模，中间省掉的那一步推演，会在后面某个改表结构的需求里连本带利找回来——这大概就是那一次踩坑换来最大的教训。毕业后发现，真正值得投入时间的不是收集多少习题，而是用一套固定的方法反复练透每个概念。希望这套流程和踩坑记录能帮你少绕几段弯路。

本文还有配套的精品资源，点击获取