📌 本文适用人群：MySQL数据库入门学习者、数据库设计新手

📋 核心内容：E-R图绘制方法 + E-R图转关系模型（全程无SQL，纯理论+案例）

🎯 教学重点：E-R图设计、E-R图向关系模型转换

⚠️ 教学难点：设计合理的E-R图（避免冗余、解决冲突）

一、课前明确：学习目标

本节课结束后，需掌握以下3点核心能力，为后续SQL实操打基础：

1. 掌握需求分析的任务、方法

2. 掌握概念结构设计的方法、步骤及概念模型的表示方法（E-R图绘制）

3. 能将E-R图转换为具体DBMS（MySQL）对应的关系模型

二、概念结构设计（核心：E-R图绘制）

概念结构设计，简单来说就是：将用户需求（比如教务系统“管理学生、课程、教师”）抽象成信息结构（概念模型），而E-R图（实体-联系图）是表示概念模型最直观、最常用的工具，也是数据库设计的核心第一步。

2.1 必记：概念模型的4个核心概念（结合案例理解）

画E-R图前，先搞懂这4个基础概念，不用死记硬背，结合高校教务案例就能快速掌握：

1. 实体（Entity）：客观存在并可相互区别的事物（简单说：我们要管理的“对象”）。 
   ✅ 案例：高校教务系统中，学生、教师、课程都是实体（客观存在，且能明确区分）。

2. 实体型（Entity Type）：具有相同属性的实体，必然有共同的特征和性质。
   ✅ 案例：“学生”实体型，包含所有学生的共同属性（学号、姓名、专业、年级）；“课程”实体型，包含所有课程的共同属性（课程号、课程名、学分、学时）。

3. 实体集（Entity Set）：同型实体的集合。
   ✅ 案例：全体学生就是一个实体集（所有学生都属于“学生”实体型）；全体课程也是一个实体集。

4. 联系（Relationship）：实体内部属性之间、不同实体集之间的关联。
   ✅ 案例：学生和课程的“选课”联系、教师和课程的“授课”联系。

2.2 重点：E-R图绘制方法（3种图形，记牢就会画）

E-R图用3种基本图形，分别表示实体型、属性、联系，规则简单，入门必记：

图形类型	表示内容	绘制规则	案例
矩形	实体型	矩形框内写明实体名	画矩形，写“学生”“课程”
椭圆形	属性	椭圆形内写属性名，用无向边（直线）连接对应实体	椭圆形写“学号”，用直线连到“学生”矩形
菱形	联系	菱形框内写联系名，用无向边连接相关实体，标注联系类型（1:1、1:n、m:n）	菱形写“选课”，连“学生”和“课程”，标注m:n

补充：3种联系类型的判断（入门必会，易错点）

联系类型是E-R图的核心，也是后续模型转换的关键，结合案例快速区分：

1. 1:1（一对一）：一个实体的一个实例，只能对应另一个实体的一个实例。

2. 1:n（一对多）：一个实体的一个实例，可对应另一个实体的多个实例；反之不行。

3. m:n（多对多）：一个实体的一个实例，可对应另一个实体的多个实例；反之也可。
   
   

2.3 概念结构的4个核心特点（理解即可）

设计的E-R图（概念模型），需满足以下4点，后续转换为关系模型才更顺畅：

• 真实、充分反映现实世界（覆盖用户核心需求，比如教务系统要包含“选课、授课”）；

• 易于理解（初学者、用户都能看懂实体、属性、联系的含义）；

• 易于更改（后续需求变化时，能快速调整E-R图，比如新增“班级”实体）；

• 易于向关系、网状、层次模型转换（重点适配MySQL的关系模型）。

2.4 概念结构设计的4种方法（了解即可）

实际设计中，可根据需求选择，入门阶段重点掌握「自底向上」（最常用、最易上手）：

• 自顶向下：从整体需求→分解局部需求→设计局部E-R图→整合全局；

• 自底向上：先设计局部E-R图（比如“学生选课”“教师授课”）→ 逐步整合为全局E-R图（入门首选）；

• 逐步扩张：从核心实体（如“学生”）出发，逐步添加相关实体和联系；

• 混合策略：结合自顶向下和自底向上，先定整体框架，再细化局部。

2.5 重点：概念结构设计的3个步骤（结合案例实操）

这是设计合理E-R图的关键，也是本节课难点，结合「高校教务系统（简化版）」案例，一步步拆解：

步骤1：抽象数据，设计局部视图（分E-R图）

核心：拆分复杂需求，逐一设计，降低难度

1. 选择局部应用：将整体需求拆分为多个局部需求。

2. 逐一设计分E-R图：抽象实体、属性、联系，画出分图。 ‘

步骤2：集成局部视图，得到全局E-R图

核心：合并分E-R图，解决冲突，建立全局关联

1. 集成方式（二选一）：
   ① 一次集成（局部图少，如本次简化案例）；
   ② 逐步集成（先合并2个，再加入第3个，适合复杂场景）。

2. 集成步骤：
   ① 确定实体关联（如“学生→选课→课程→授课→教师”的关联）；
   ② 合并分图（课程实体只保留1个，避免重复）。

3. 难点：解决3类冲突（必记，避免后续出错）：
   - 🔴 属性冲突：同一实体的同一属性，类型/取值不一致（如“课程学分”，一个设整数、一个设小数，统一为整数）；
   - 🔴 命名冲突：实体/属性/联系名称不一致（如“教师工号”和“工号”，统一为“教师工号”）；
   - 🔴 结构冲突：同一实体在不同分图中属性个数/类型不一致（如“学生”实体，一个有“年龄”、一个没有，根据需求决定是否保留）。

步骤3：评审（优化E-R图）

核心：消除冗余，确保E-R图简洁、准确

• 评审内容：检查冗余数据（如“课程学分”，无需在“选课”联系中重复）、冗余联系（如“学生”和“教师”，通过“选课+授课”间接关联，无需单独画“被授课”联系）；

• 优化原则：结合用户需求，删除冗余，覆盖所有核心需求即可。

三、逻辑结构设计（核心：E-R图转关系模型）

逻辑结构设计的核心任务：将设计好的E-R图（概念模型），转换为MySQL支持的关系模型（也就是后续要创建的“数据表”结构，关系=数据表，关系模式=数据表结构）。

关系数据库（MySQL）的逻辑结构设计，只需2步：① E-R图转关系模型；② 优化关系模型（本节课重点讲第①步，第②步简单了解）。

3.1 核心规则：E-R图转关系模型（必记，结合案例）

转换的关键：将E-R图中的「实体」和「联系」，全部转换为对应的关系（数据表），分两类规则：

规则1：实体集的转换（最简单，入门必会）

「一个实体集」→「一个关系（数据表）」，对应关系如下：

• 实体的「属性」→ 关系的「字段」（数据表的列）；

• 实体的「码」（唯一标识实体的属性，如学生的“学号”）→ 关系的「主键」（数据表的主键）；

• 关系的结构 = 关系模式（如学生表的关系模式：学生（学号，姓名，专业，年级））。

规则2：实体集间联系的转换（重点+难点，易错点）

根据联系类型（1:1、1:n、m:n、多元联系），转换方法不同，结合教务案例逐一讲解，记牢规则即可：

（1）1:1联系的转换（一对一）

两种方法，任选一种，推荐第二种（更简洁，适配MySQL）：

1. 方法1：转换为独立关系（数据表）；
   - 关系属性：联系相连的各实体的码 + 联系自身的属性；
   - 主键：每个实体的码都是候选码（任选一个）。

• 方法2：与任意一端实体的关系合并（推荐）；
  - 被合并关系新增属性：联系自身的属性 + 另一个实体的码； - 原实体主键不变。
  

  方案1：联系形成的关系独立存在：

          班主任（教工号，姓名，性别，职务）

          班级（班级编号，系别，专业）        

          管理（教工号，班级编号，开始时间），其中“教工号”与“班级编号”均是候选码

  方案2：“管理”与“班主任”两个关系合并：          

          班主任（教工号，姓名，性别，职务，班级编号，开始时间）          

          班级（班级编号，系别，专业）

  方案3：“管理”与“班级”两个关系合并：          

          班主任（教工号，姓名，性别，职务）          

          班级（班级编号，系别，专业，教工号，开始时间）

（2）1:n联系的转换（一对多，最常用）

两种方法，推荐第二种（减少数据表数量，更简洁）：

1. 方法1：转换为独立关系；
   - 关系属性：联系相连的各实体的码 + 联系自身的属性；
   - 主键：n端实体的码（n端是“多”的一方）。

2. 方法2：在n端实体的关系中新增属性（推荐）；
   - 新增属性：1端实体的码 + 联系自身的属性； - 原n端实体主键不变。
   
   方案1：1：n联系形成的关系独立存在。    
           学生（学号，姓名，性别，出生日期，所在系）；        
           宿舍（宿舍编号，宿舍名称，宿舍地址）；        
           分配（学号，宿舍编号） 。
   方案2：联系形成的关系与n端对象合并。          
           学生（学号，姓名，性别，出生日期，所在系，宿舍编号）；        
           宿舍（宿舍编号，宿舍名称，宿舍地址）。
   
   【例3.3】图3-15中含有同实体集的      1：n联系，将它转换为关系模型。
   方案1：转换为两个关系模式。              
           教工（教工号，姓名，性别，职务）；              
           领导（教工号，领导工号，）
   方案2：转换为一个关系模式。              
           职工（教工号，姓名，性别，职务，领导工号）。

（3）m:n联系的转换（多对多，重点中的重点）

🔴 唯一方法：必须转换为独立关系（数据表），无法合并到任意一端实体！

• 关系属性：联系相连的各实体的码 + 联系自身的属性；

• 主键：两个相连实体码的组合（联合主键，单个实体码无法唯一标识联系）。

【例3.4】将图3-16中含有m：n二元联系的E-R图，转换为关系模型。
转换的关系模型如下：        
        学生（学号，姓名，年龄，性别，  出生日期，所在系）；       
        课程（课程号，课程名，先行课程，学分）；        
       选修（学号，课程号，成绩）

【例3.5】将图3-17中含有同实体集间m：n联系的E-R图转换为关系模式
转换后的关系模型为：            
        零件（零件号，名称，价格）；            
        组装（组装件号，零件号，数量）。

（4）三个及以上实体集的多元联系（了解即可）

入门阶段重点掌握前3种，多元联系简单了解：

1. 一对多多元联系：修改n端实体的关系，新增1端实体的码和联系属性；

2. 多对多多元联系：新建独立关系，属性为各实体的码 + 联系属性，主键为各实体码的组合。

3.2 关系模型优化（简单了解）

转换后的关系模型，需优化以提升MySQL操作性能，常用方法：

1. 确定数据依赖（如“课程号”决定“课程名”“学分”）；

2. 极小化处理：消除冗余联系（重复属性、重复关系）；

3. 确定范式：根据数据依赖，判断关系模式属于第几范式（后续课程详解）；

4. 结合用户需求：调整字段（如“选课表”新增“成绩”字段，满足成绩管理需求）。

四、完整案例实操：E-R图→关系模型（教务系统简化版）

结合前面的规则，将“高校教务系统（简化版）”的E-R图，完整转换为MySQL关系模型，巩固知识点，入门必练！

1. 全局E-R图回顾

• 实体：学生（学号，姓名，专业，年级）、教师（教师工号，姓名，院系，职称）、课程（课程号，课程名，学分，学时）；

• 联系：学生-课程（选课，m:n）、教师-课程（授课，1:n）。

2. 转换过程（一步一步来）

1. 实体转换（按规则1）：
   - 学生表（学号，姓名，专业，年级），主键：学号；
   - 教师表（教师工号，姓名，院系，职称），主键：教师工号；
   - 课程表（课程号，课程名，学分，学时），主键：课程号。

2. 联系转换（按规则2）：
   - 教师-课程（1:n，授课）：采用“n端新增属性”，合并到课程表 → 课程表（课程号，课程名，学分，学时，教师工号），主键：课程号；
   - 学生-课程（m:n，选课）：新建选课表 → 选课表（学号，课程号，选课日期，成绩），主键：（学号，课程号）（联合主键）。

3. 最终关系模型（MySQL数据表结构，入门必记）

• 学生表：学号（主键）、姓名、专业、年级；

• 教师表：教师工号（主键）、姓名、院系、职称；

• 课程表：课程号（主键）、课程名、学分、学时、教师工号；

• 选课表：学号（主键）、课程号（主键）、选课日期、成绩。

五、入门小结+易错点提醒（重中之重）

1. 核心小结（浓缩本节课重点）

• 概念结构设计：需求 → 抽象实体/属性/联系 → 画分E-R图 → 合并全局E-R图 → 评审优化；

• E-R图绘制：矩形（实体）、椭圆形（属性）、菱形（联系），标注联系类型；

• 模型转换：实体→数据表；联系按类型转换（1:1可合并、1:n可合并到n端、m:n必须新建表）。

2. 易错点提醒（初学者必看，避免踩坑）

• 🔴 混淆联系类型：把“学生-课程”的m:n误判为1:n，导致不新建选课表；

• 🔴 合并E-R图忽略冲突：属性类型、命名、结构不一致，导致后续转换出错；

• 🔴 m:n联系转换忘记设联合主键：选课表只设“学号”为主键，无法唯一标识一条记录；

• 🔴 冗余数据/联系：课程表的“学分”，在选课表中重复添加，造成冗余。

六、课后练习（入门必做）

1. 手动绘制“学生-学生证”（1:1）、“教师-课程”（1:n）的E-R图；
2. 将绘制的E-R图，转换为对应的关系模型；
3. 尝试设计“图书管理系统”的E-R图（实体：图书、读者，联系：借阅，m:n），并转换为关系模型。

【例3.6】将图3-18中含有多实体集间的多对多联系的E-R图转换为关系模型。
转换后的关系模型为：
        供应商（供应商号，供应商，地址）；
        零件（零件号，零件名，价格）；
​​​​​​​        产品（产品号，产品名，型号）；  
​​​​​​​        供应（供应商号，零件号，产品号，数量）。
​​​​​​​关系合并规则 在关系模型中，具有相同码的关系，可根据情况合并为一个关系。