简介《数据库系统概论》配套课件聚焦实体-联系模型与ER图设计适合数据库初学者、高校学生及备考者用于概念模型阶段学习帮助理解从现实世界到机器世界的建模思路。课件以PPT形式呈现全包仅1个独立文件大小约622KB内容精炼、便于直接打开学习涵盖信息世界的基本概念、实体与属性、码与域、实体型与实体集以及联系的分类与映射基数等核心知识点。已有411人学习下载。通过该课件可系统掌握一对一、一对多、多对多三类联系的判别方法并学会用矩形、椭圆、菱形等符号绘制标准ER图为后续将概念模型转化为关系模式打下扎实基础。整体适合课堂辅助、期末复习或自学入门使用。1. 为什么数据库设计要先画ER图再谈建表翻开任何一本《数据库系统概论》第二章几乎都是实体-联系模型。这不是编排巧合而是因为设计数据库时绝大多数业务错误都发生在建表之前——表结构还能改但实体边界划错了、联系类型判错了后面所有表和SQL都要推倒重来。ER模型的价值在于它先不管存储、索引和性能用矩形画实体、椭圆画属性、菱形画联系把业务规则用图形语言固定下来。这个阶段虽然不产出任何可执行的DDL却决定了后续关系模式的质量。如果你带过学生做课程设计会发现教学管理系统也好、银行储蓄系统也好大家卡住的从来不是SQL语法而是“课程和教师到底是不是多对多”这类判定问题。这篇文章就把ER模型的概念、联系分类、画图规范和工具落地整个链路拆一遍。2. 实体、属性、码与映射基数信息世界的六个基本概念2.1 实体与属性的粒度边界实体Entity是客观存在且可相互区别的事物可以是具体的人或物也可以是抽象概念。学生、班级、课程是实体“专业”“院系”也可能是实体而不是属性——这里就涉及粒度判断。设计时经常出现的争议是某个字段到底该作为独立实体还是作为现有实体的属性判断依据是它是否能被多个实体共享、是否自身还有需要附加的属性。判断维度作为属性作为实体归属关系只属于一个实体无独立语义被多个实体引用或自身有属性更新频度随实体一起变更可能独立变化需要单独维护查询粒度不需要按它单独检索需要按它分组、筛选或关联学生实体的“所在院系”如果只存一个院系名字那是属性但院系还有院长、电话、成立时间这些信息且一个院系下有多个学生那就应该拆成独立实体。这个决策直接决定后面是加字段还是加表。初次建模时拿不准我一般会看一条业务规则“这个数据的取值集合会不会被多个实体引用”。会就升级为实体。2.2 码、域与实体型/实体集的落地表达码Key是唯一标识实体的属性集比如学号之于学生、课程号之于课程。码不一定是单属性也可能是属性组合所以教材里强调“属性集”。域Domain则是属性的取值范围比如性别域是{男, 女}年龄域是[1, 150]的整数区间。域落到数据库端就是字段类型加CHECK约束码落到数据库端就是主键或唯一索引。实体型Entity Type是用实体名加属性名集合描述同类实体的结构框架实体集Entity Set是同一类型实体的全部实例集合。用代码类比“学生实体型”是类“学生实体集”是该类的所有对象。CREATE TABLE student ( sno CHAR(10) PRIMARY KEY, -- 学号码的唯一标识 sname VARCHAR(20) NOT NULL, -- 姓名 sex CHAR(2) CHECK (sex IN (男,女)), -- 域约束 age SMALLINT CHECK (age BETWEEN 1 AND 150), sdept VARCHAR(30) -- 所属院系决策点暂作属性处理 );这段建表SQL里PRIMARY KEY对应ER模型中的码CHECK约束对应域NOT NULL表达实体属性的强制性。先在建ER图时把这些标注清楚建表语句几乎可以机械翻译出来。实体型中属性间还可能存在函数依赖比如“班级号→班主任”这种实体内部联系通常不会单独画在ER图中但会体现在关系模式的范式判定里。2.3 映射基数与参与约束映射基数Mapping Cardinality指明通过一个联系集能同时与另一实体相联系的实体数目它决定联系的类型是1:1、1:n还是m:n。判定时不能只看业务描述要看两个方向的可选数量。假设有实体集A和B先问“A中一个实例最多关联几个B实例”再问反向答案组合起来就是映射基数。参与约束描述实体参与联系的强制性总参与每个实例都必须参与联系和部分参与允许有实例不参与。比如规定每个学生必须属于某个班级这是总参与建表时外键列就要加NOT NULL允许个别学生暂时无班级则是部分参与外键列允许NULL。ER图中常见做法是用双线边框或双线连接表示总参与有些教材用(min, max)标注比如(1, n)代表至少参加一次、至多n次。参与约束经常被忽略但它是外键能否为空的唯一依据。3. 联系的类型判定从1:1、1:n到m:n及多元联系3.1 两个实体型之间三类联系的定义与实例两个实体型之间的联系是ER模型里最常考的部分。一对一联系1:1指实体集A中每个实体至多对应B中一个实体反之亦然。一个班级只有一个正班长一个班长只在一个班级任职这是1:1。一对多1:n指A中一个实体对应B中多个实体而B中每个实体只对应A中一个实体一个班级有若干学生每个学生只属于一个班级。多对多m:n则是双向都可对应多个一门课程有若干学生选修一个学生可以选修多门课程。联系类型单向描述典型实例关系模式处理1:1A至多对应一个BB至多对应一个A班级-班长并入任一侧实体表1:nA对应多个BB只对应一个A班级-学生在n侧实体表加外键m:nA对应多个BB对应多个A课程-学生新建中间联系表一对多联系落到数据库端要理解外键为什么必须放在n侧。一个学生只属于一个班级那么student表上放class_id外键一条学生记录带一个班级编号完全没有冗余反过来如果放在班级表里存“学生列表”一个班级对应几十个学生就会产生大量重复行或需要逗号拼接字符串完全违背关系模型设计原则。-- 1:n 联系班级(1) - 学生(n) CREATE TABLE student ( sno CHAR(10) PRIMARY KEY, sname VARCHAR(20), class_id CHAR(6) NOT NULL, -- 外键对应class表的class_id FOREIGN KEY (class_id) REFERENCES class(class_id) ); -- m:n 联系课程(m) - 学生(n)必须借助中间表 CREATE TABLE course ( cno CHAR(6) PRIMARY KEY, cname VARCHAR(50) ); CREATE TABLE sc ( sno CHAR(10), cno CHAR(6), grade DECIMAL(4,1), PRIMARY KEY (sno, cno), FOREIGN KEY (sno) REFERENCES student(sno), FOREIGN KEY (cno) REFERENCES course(cno) );这个例子同时说明了联系本身也可以带属性选课联系上的grade成绩既不属于学生也不属于课程只能挂在联系上。这是后续设计里最容易漏掉的信息点。3.2 三个及以上实体型联系无法两两拆解的情况当涉及三个及以上实体型时联系类型不能简单拆成多组两两联系必须整体判定。课程、教师与参考书三个实体型构成一对多联系一门课程可以有若干教师讲授、使用若干本参考书但每个教师只讲授一门课程每本参考书只供一门课程使用。这里实体集E1课程与另外两个实体集之间的对应关系共同决定基数是1:m:n的结构。更典型的三个以上实体型间多对多联系是供应商-项目-零件一个供应商可以供给多个项目多种零件每个项目可以使用多个供应商供应的零件每种零件可由不同供应商供给。这是m:n:p的联系且“供应量”这个属性既不属于供应商、项目、零件任何一个实体只属于三者之间的供应联系。建模时要把供应量挂在联系上不能挂到任何一个实体里否则会出现语义错位。多元联系的映射基数判定有个常见误区把三元联系强行拆成三个二元联系再各自定基数。比如课程-教师-参考书如果拆开看课程和教师是1:n、课程和参考书是1:n但这两个1:n无法表达“一门课程同时对应教师集合和参考书集合”的完整语义因为两个方向的联系相互约束。正确做法是整体判定教材上的定义表述是若实体集E1, E2, ..., En存在联系对给定其他实体集的实体最多只与Ei中的一个实体相联系则称Ei与其余实体集之间是一对多的。3.3 单个实体型内部的递归联系单个实体型内部也可以有联系最经典的例子是职工实体型内部的领导与被领导关系一个职工干部领导若干名职工一个职工仅被另一个职工直接领导这是一对多联系。在ER图中联系名“领导”用菱形表示两条无向边都连向“职工”矩形连线旁标注1和n。递归联系的陷阱在于外键方向。职工表中的领导关系本质上是职工表到自身的外键约束把“领导工号”作为职工表的一个外键列指向同一张表的emp_id主键。这里需要注意的是该外键列必须允许NULL因为最高领导者没有上级如果建模时按总参与处理把外键设为NOT NULL就会陷入“第一个员工无法插入”的鸡生蛋问题。递归联系的一对一版本也存在比如职工内部一对一的配偶关系映射基数判定方法与两个实体型间完全一致只是实体表相同而已。4. E-R图的绘制规范与E-R图到关系模式的转换4.1 图形符号与主键的下划线标注E-R图是概念模型的标准表示方法符号体系固定实体型用矩形属性用椭圆联系用菱形三者之间用无向边连接。实体和联系之间连线旁标注联系类型1:1、1:n或m:n主码属性在椭圆中加下划线。“ER图主键怎么表示”是最常见的问题。标准做法是在属性椭圆内给主码属性名下加下划线比如学生实体的“学号”椭圆内文字下方加下划线课程实体的“课程号”同样处理。组合码则要同时给多个属性加下划线比如选课联系中的“学号课程号”。多值属性用双椭圆表示派生属性可以由其他属性计算得到如“年龄”可由出生日期推出用虚线椭圆表示这些在复杂建模中会用到。画图顺序常见做法是先确定实体集和它的全部属性再标注码属性然后画实体间的联系菱形并连线最后标映射基数。实际操作里很多人先画实体再画属性结果属性散落各处导致边线交叉严重。我一般先在一张草稿上列出所有实体用表格登记每个实体的属性清单和码确定联系清单之后再正式画图边线交叉率会大幅下降。课程设计里常见的教学管理系统ER图最先画的一定是学生、教师、课程三个实体及各自的主键然后再补“选修”“讲授”这些联系这个顺序能保证主键不遗漏。4.2 从E-R图到关系模式的转换规则E-R图最终要转换为关系模式转换规则是整套理论中最具操作性的部分。每个实体型转换为一个关系模式实体的属性就是关系的属性实体的码就是关系的码。联系则分三种情况1:1联系可以并入任一侧实体关系模式在另一侧模式中加入对方主码1:n联系并入n侧实体关系模式在n侧加对方主码作外键m:n联系必须单独转换为一个关系模式该模式包含两端实体的主码和联系自身的属性码为两端主码的组合。联系类型转换方式关系模式示例1:1并入任一侧班级(班级号, 班长学号, ...)1:n并入n侧学生(学号, 姓名, 班级号, ...)m:n独立关系模式选课(学号, 课程号, 成绩)1:1递归并入实体模式职工(工号, 姓名, 配偶工号, ...)1:n递归并入实体模式职工(工号, 姓名, 领导工号, ...)三元m:n独立关系模式供应(供应商号, 项目号, 零件号, 供应量)递归联系的转换规则容易被忽略。职工领导关系转换时在职职工关系模式中添加“领导工号”属性它参照职工关系模式的主码“工号”。一个表参照自身主码的外键在SQL中完全合法关键约束条件是取值必须来自已有职工的工号。多元联系中的m:n:p例如供应联系直接转换为包含三方码加“供应量”属性的四个关系模式不要试图拆成多个二元表。4.3 常见画图错误与检查方法ER图绘制中有几个高频错误一是把m:n联系画成1:n漏掉联系表导致业务规则丢失二是联系属性无处安放比如把“成绩”画成课程实体的属性结果反映不出“哪个学生的成绩”三是忽略主键下划线转换关系模式时找不到码四是不检查参与约束外键约束全都画成可空导致逻辑上“每个学生必须有班级”的规则丢失。一张画完的ER图应该能回答三件事每个实体靠什么唯一标识、每两个实体之间怎么连、联系上挂了哪些属性。5. 从PowerDesigner到MySQL Workbench把ER图落到建表脚本ER图画完不等于建模完成工具落地的流程也值得捋一遍。PowerDesigner是课程设计里常用的建模工具新建模型时选Conceptual Data ModelCDM在画布上添加实体后双击配置属性属性窗口里需要区分Data Type和Domain——Data Type决定字段类型Domain可复用小范围的业务约束。添加两个实体后用Relationship工具连接在Relationship窗口的Cardinalities页签中选One-to-Many或Many-to-ManyPowerDesigner会按映射基数自动生成外键列。CDM完成后选Tools下的Generate Physical Data Model实体自动转成表联系自动转成外键约束这一步对1:n和m:n的处理和人工转换规则完全一致。-- PowerDesigner生成的物理模型中的一段典型脚本 ALTER TABLE student ADD CONSTRAINT FK_STUDENT_CLASS FOREIGN KEY (class_id) REFERENCES class (class_id);如果已经是建好库的业务系统需要反向出图常见做法是用MySQL Workbench的Reverse Engineer功能。菜单路径是Database - Reverse Engineer选择连接后勾选目标schemaWorkbench会读取information_schema中的表、列、索引和外键信息自动生成一张EER图。对已有系统做文档梳理时这个逆向过程能把外键关系可视化方便核对表间联系是否与设计文档一致。需要注意Workbench只能恢复外键约束明确的关联如果业务表间的逻辑外键没有物理建立约束逆向结果会缺线需要手工补画。在线工具方面dbdiagram.io这类SQL to ER工具适合快速预览表结构关系粘贴建表DDL即可生成关系图适合临时演示和快速核对。它的局限在于无法表达联系的自定义属性比如选课联系上的成绩字段在线工具只会显示表间连线不会生成联系属性复杂建模还是要回到PowerDesigner或Workbench。ER图质检我一般跑一个“三查”清单一查码完整性每个实体是否都有下划线标注的主键组合码是否全部标出二查联系表所有m:n联系是否都有对应的独立关系模式联系属性是否挂在了联系上三查外键数量1:n关系中外键是否落在n侧1:1关系外键是否只出现一次。三查全部通过后对照ER图手工写一份关系模式清单再和工具生成的建表脚本逐项比对确认没有多余字段和缺失外键。整个流程跑下来从概念模型到物理表结构的路就基本走通了。本文还有配套的精品资源点击获取 ER图详解：从实体联系模型到关系模式转换的完整指南
简介《数据库系统概论》配套课件聚焦实体-联系模型与ER图设计适合数据库初学者、高校学生及备考者用于概念模型阶段学习帮助理解从现实世界到机器世界的建模思路。课件以PPT形式呈现全包仅1个独立文件大小约622KB内容精炼、便于直接打开学习涵盖信息世界的基本概念、实体与属性、码与域、实体型与实体集以及联系的分类与映射基数等核心知识点。已有411人学习下载。通过该课件可系统掌握一对一、一对多、多对多三类联系的判别方法并学会用矩形、椭圆、菱形等符号绘制标准ER图为后续将概念模型转化为关系模式打下扎实基础。整体适合课堂辅助、期末复习或自学入门使用。1. 为什么数据库设计要先画ER图再谈建表翻开任何一本《数据库系统概论》第二章几乎都是实体-联系模型。这不是编排巧合而是因为设计数据库时绝大多数业务错误都发生在建表之前——表结构还能改但实体边界划错了、联系类型判错了后面所有表和SQL都要推倒重来。ER模型的价值在于它先不管存储、索引和性能用矩形画实体、椭圆画属性、菱形画联系把业务规则用图形语言固定下来。这个阶段虽然不产出任何可执行的DDL却决定了后续关系模式的质量。如果你带过学生做课程设计会发现教学管理系统也好、银行储蓄系统也好大家卡住的从来不是SQL语法而是“课程和教师到底是不是多对多”这类判定问题。这篇文章就把ER模型的概念、联系分类、画图规范和工具落地整个链路拆一遍。2. 实体、属性、码与映射基数信息世界的六个基本概念2.1 实体与属性的粒度边界实体Entity是客观存在且可相互区别的事物可以是具体的人或物也可以是抽象概念。学生、班级、课程是实体“专业”“院系”也可能是实体而不是属性——这里就涉及粒度判断。设计时经常出现的争议是某个字段到底该作为独立实体还是作为现有实体的属性判断依据是它是否能被多个实体共享、是否自身还有需要附加的属性。判断维度作为属性作为实体归属关系只属于一个实体无独立语义被多个实体引用或自身有属性更新频度随实体一起变更可能独立变化需要单独维护查询粒度不需要按它单独检索需要按它分组、筛选或关联学生实体的“所在院系”如果只存一个院系名字那是属性但院系还有院长、电话、成立时间这些信息且一个院系下有多个学生那就应该拆成独立实体。这个决策直接决定后面是加字段还是加表。初次建模时拿不准我一般会看一条业务规则“这个数据的取值集合会不会被多个实体引用”。会就升级为实体。2.2 码、域与实体型/实体集的落地表达码Key是唯一标识实体的属性集比如学号之于学生、课程号之于课程。码不一定是单属性也可能是属性组合所以教材里强调“属性集”。域Domain则是属性的取值范围比如性别域是{男, 女}年龄域是[1, 150]的整数区间。域落到数据库端就是字段类型加CHECK约束码落到数据库端就是主键或唯一索引。实体型Entity Type是用实体名加属性名集合描述同类实体的结构框架实体集Entity Set是同一类型实体的全部实例集合。用代码类比“学生实体型”是类“学生实体集”是该类的所有对象。CREATE TABLE student ( sno CHAR(10) PRIMARY KEY, -- 学号码的唯一标识 sname VARCHAR(20) NOT NULL, -- 姓名 sex CHAR(2) CHECK (sex IN (男,女)), -- 域约束 age SMALLINT CHECK (age BETWEEN 1 AND 150), sdept VARCHAR(30) -- 所属院系决策点暂作属性处理 );这段建表SQL里PRIMARY KEY对应ER模型中的码CHECK约束对应域NOT NULL表达实体属性的强制性。先在建ER图时把这些标注清楚建表语句几乎可以机械翻译出来。实体型中属性间还可能存在函数依赖比如“班级号→班主任”这种实体内部联系通常不会单独画在ER图中但会体现在关系模式的范式判定里。2.3 映射基数与参与约束映射基数Mapping Cardinality指明通过一个联系集能同时与另一实体相联系的实体数目它决定联系的类型是1:1、1:n还是m:n。判定时不能只看业务描述要看两个方向的可选数量。假设有实体集A和B先问“A中一个实例最多关联几个B实例”再问反向答案组合起来就是映射基数。参与约束描述实体参与联系的强制性总参与每个实例都必须参与联系和部分参与允许有实例不参与。比如规定每个学生必须属于某个班级这是总参与建表时外键列就要加NOT NULL允许个别学生暂时无班级则是部分参与外键列允许NULL。ER图中常见做法是用双线边框或双线连接表示总参与有些教材用(min, max)标注比如(1, n)代表至少参加一次、至多n次。参与约束经常被忽略但它是外键能否为空的唯一依据。3. 联系的类型判定从1:1、1:n到m:n及多元联系3.1 两个实体型之间三类联系的定义与实例两个实体型之间的联系是ER模型里最常考的部分。一对一联系1:1指实体集A中每个实体至多对应B中一个实体反之亦然。一个班级只有一个正班长一个班长只在一个班级任职这是1:1。一对多1:n指A中一个实体对应B中多个实体而B中每个实体只对应A中一个实体一个班级有若干学生每个学生只属于一个班级。多对多m:n则是双向都可对应多个一门课程有若干学生选修一个学生可以选修多门课程。联系类型单向描述典型实例关系模式处理1:1A至多对应一个BB至多对应一个A班级-班长并入任一侧实体表1:nA对应多个BB只对应一个A班级-学生在n侧实体表加外键m:nA对应多个BB对应多个A课程-学生新建中间联系表一对多联系落到数据库端要理解外键为什么必须放在n侧。一个学生只属于一个班级那么student表上放class_id外键一条学生记录带一个班级编号完全没有冗余反过来如果放在班级表里存“学生列表”一个班级对应几十个学生就会产生大量重复行或需要逗号拼接字符串完全违背关系模型设计原则。-- 1:n 联系班级(1) - 学生(n) CREATE TABLE student ( sno CHAR(10) PRIMARY KEY, sname VARCHAR(20), class_id CHAR(6) NOT NULL, -- 外键对应class表的class_id FOREIGN KEY (class_id) REFERENCES class(class_id) ); -- m:n 联系课程(m) - 学生(n)必须借助中间表 CREATE TABLE course ( cno CHAR(6) PRIMARY KEY, cname VARCHAR(50) ); CREATE TABLE sc ( sno CHAR(10), cno CHAR(6), grade DECIMAL(4,1), PRIMARY KEY (sno, cno), FOREIGN KEY (sno) REFERENCES student(sno), FOREIGN KEY (cno) REFERENCES course(cno) );这个例子同时说明了联系本身也可以带属性选课联系上的grade成绩既不属于学生也不属于课程只能挂在联系上。这是后续设计里最容易漏掉的信息点。3.2 三个及以上实体型联系无法两两拆解的情况当涉及三个及以上实体型时联系类型不能简单拆成多组两两联系必须整体判定。课程、教师与参考书三个实体型构成一对多联系一门课程可以有若干教师讲授、使用若干本参考书但每个教师只讲授一门课程每本参考书只供一门课程使用。这里实体集E1课程与另外两个实体集之间的对应关系共同决定基数是1:m:n的结构。更典型的三个以上实体型间多对多联系是供应商-项目-零件一个供应商可以供给多个项目多种零件每个项目可以使用多个供应商供应的零件每种零件可由不同供应商供给。这是m:n:p的联系且“供应量”这个属性既不属于供应商、项目、零件任何一个实体只属于三者之间的供应联系。建模时要把供应量挂在联系上不能挂到任何一个实体里否则会出现语义错位。多元联系的映射基数判定有个常见误区把三元联系强行拆成三个二元联系再各自定基数。比如课程-教师-参考书如果拆开看课程和教师是1:n、课程和参考书是1:n但这两个1:n无法表达“一门课程同时对应教师集合和参考书集合”的完整语义因为两个方向的联系相互约束。正确做法是整体判定教材上的定义表述是若实体集E1, E2, ..., En存在联系对给定其他实体集的实体最多只与Ei中的一个实体相联系则称Ei与其余实体集之间是一对多的。3.3 单个实体型内部的递归联系单个实体型内部也可以有联系最经典的例子是职工实体型内部的领导与被领导关系一个职工干部领导若干名职工一个职工仅被另一个职工直接领导这是一对多联系。在ER图中联系名“领导”用菱形表示两条无向边都连向“职工”矩形连线旁标注1和n。递归联系的陷阱在于外键方向。职工表中的领导关系本质上是职工表到自身的外键约束把“领导工号”作为职工表的一个外键列指向同一张表的emp_id主键。这里需要注意的是该外键列必须允许NULL因为最高领导者没有上级如果建模时按总参与处理把外键设为NOT NULL就会陷入“第一个员工无法插入”的鸡生蛋问题。递归联系的一对一版本也存在比如职工内部一对一的配偶关系映射基数判定方法与两个实体型间完全一致只是实体表相同而已。4. E-R图的绘制规范与E-R图到关系模式的转换4.1 图形符号与主键的下划线标注E-R图是概念模型的标准表示方法符号体系固定实体型用矩形属性用椭圆联系用菱形三者之间用无向边连接。实体和联系之间连线旁标注联系类型1:1、1:n或m:n主码属性在椭圆中加下划线。“ER图主键怎么表示”是最常见的问题。标准做法是在属性椭圆内给主码属性名下加下划线比如学生实体的“学号”椭圆内文字下方加下划线课程实体的“课程号”同样处理。组合码则要同时给多个属性加下划线比如选课联系中的“学号课程号”。多值属性用双椭圆表示派生属性可以由其他属性计算得到如“年龄”可由出生日期推出用虚线椭圆表示这些在复杂建模中会用到。画图顺序常见做法是先确定实体集和它的全部属性再标注码属性然后画实体间的联系菱形并连线最后标映射基数。实际操作里很多人先画实体再画属性结果属性散落各处导致边线交叉严重。我一般先在一张草稿上列出所有实体用表格登记每个实体的属性清单和码确定联系清单之后再正式画图边线交叉率会大幅下降。课程设计里常见的教学管理系统ER图最先画的一定是学生、教师、课程三个实体及各自的主键然后再补“选修”“讲授”这些联系这个顺序能保证主键不遗漏。4.2 从E-R图到关系模式的转换规则E-R图最终要转换为关系模式转换规则是整套理论中最具操作性的部分。每个实体型转换为一个关系模式实体的属性就是关系的属性实体的码就是关系的码。联系则分三种情况1:1联系可以并入任一侧实体关系模式在另一侧模式中加入对方主码1:n联系并入n侧实体关系模式在n侧加对方主码作外键m:n联系必须单独转换为一个关系模式该模式包含两端实体的主码和联系自身的属性码为两端主码的组合。联系类型转换方式关系模式示例1:1并入任一侧班级(班级号, 班长学号, ...)1:n并入n侧学生(学号, 姓名, 班级号, ...)m:n独立关系模式选课(学号, 课程号, 成绩)1:1递归并入实体模式职工(工号, 姓名, 配偶工号, ...)1:n递归并入实体模式职工(工号, 姓名, 领导工号, ...)三元m:n独立关系模式供应(供应商号, 项目号, 零件号, 供应量)递归联系的转换规则容易被忽略。职工领导关系转换时在职职工关系模式中添加“领导工号”属性它参照职工关系模式的主码“工号”。一个表参照自身主码的外键在SQL中完全合法关键约束条件是取值必须来自已有职工的工号。多元联系中的m:n:p例如供应联系直接转换为包含三方码加“供应量”属性的四个关系模式不要试图拆成多个二元表。4.3 常见画图错误与检查方法ER图绘制中有几个高频错误一是把m:n联系画成1:n漏掉联系表导致业务规则丢失二是联系属性无处安放比如把“成绩”画成课程实体的属性结果反映不出“哪个学生的成绩”三是忽略主键下划线转换关系模式时找不到码四是不检查参与约束外键约束全都画成可空导致逻辑上“每个学生必须有班级”的规则丢失。一张画完的ER图应该能回答三件事每个实体靠什么唯一标识、每两个实体之间怎么连、联系上挂了哪些属性。5. 从PowerDesigner到MySQL Workbench把ER图落到建表脚本ER图画完不等于建模完成工具落地的流程也值得捋一遍。PowerDesigner是课程设计里常用的建模工具新建模型时选Conceptual Data ModelCDM在画布上添加实体后双击配置属性属性窗口里需要区分Data Type和Domain——Data Type决定字段类型Domain可复用小范围的业务约束。添加两个实体后用Relationship工具连接在Relationship窗口的Cardinalities页签中选One-to-Many或Many-to-ManyPowerDesigner会按映射基数自动生成外键列。CDM完成后选Tools下的Generate Physical Data Model实体自动转成表联系自动转成外键约束这一步对1:n和m:n的处理和人工转换规则完全一致。-- PowerDesigner生成的物理模型中的一段典型脚本 ALTER TABLE student ADD CONSTRAINT FK_STUDENT_CLASS FOREIGN KEY (class_id) REFERENCES class (class_id);如果已经是建好库的业务系统需要反向出图常见做法是用MySQL Workbench的Reverse Engineer功能。菜单路径是Database - Reverse Engineer选择连接后勾选目标schemaWorkbench会读取information_schema中的表、列、索引和外键信息自动生成一张EER图。对已有系统做文档梳理时这个逆向过程能把外键关系可视化方便核对表间联系是否与设计文档一致。需要注意Workbench只能恢复外键约束明确的关联如果业务表间的逻辑外键没有物理建立约束逆向结果会缺线需要手工补画。在线工具方面dbdiagram.io这类SQL to ER工具适合快速预览表结构关系粘贴建表DDL即可生成关系图适合临时演示和快速核对。它的局限在于无法表达联系的自定义属性比如选课联系上的成绩字段在线工具只会显示表间连线不会生成联系属性复杂建模还是要回到PowerDesigner或Workbench。ER图质检我一般跑一个“三查”清单一查码完整性每个实体是否都有下划线标注的主键组合码是否全部标出二查联系表所有m:n联系是否都有对应的独立关系模式联系属性是否挂在了联系上三查外键数量1:n关系中外键是否落在n侧1:1关系外键是否只出现一次。三查全部通过后对照ER图手工写一份关系模式清单再和工具生成的建表脚本逐项比对确认没有多余字段和缺失外键。整个流程跑下来从概念模型到物理表结构的路就基本走通了。本文还有配套的精品资源点击获取