第2章 ER模型（实体-联系模型）
课程：《数据库设计与实践》（0A102） 章节：第2章 ER模型 来源：chap02 ER模型.ppt（6.73MB，PowerPoint 97-2003 图片型格式） 状态说明：PPT为图形化矢量图格式，文本层提取有限（仅获得实体、联系、ISA、UML、overlapping、WorksIn、ReportsTo、D1234、D5678 等关键词）。本篇笔记基于 ER 模型标准知识体系 + 课程框架整理，核心概念和结构与授课内容一致，具体案例和图示细节为推测，以实际课堂为准。
一、ER模型概述
1.1 什么是 ER 模型
实体-联系模型（Entity-Relationship Model，简称 ER 模型）是概念数据库设计的核心工具，由 Peter Chen 于 1976 年提出。它用图形化的方式描述现实世界中的数据及其联系，独立于具体的 DBMS 和数据模型。
ER 模型是从现实世界到关系模型的桥梁：先做 ER 设计，再转换为关系模式。
1.2 ER 模型的三要素
| 要素 | 英文 | 表示 | 说明 |
|---|---|---|---|
| 实体 | Entity | 矩形 | 客观存在并可相互区分的事物 |
| 属性 | Attribute | 椭圆形 | 实体所具有的某一特性 |
| 联系 | Relationship | 菱形 | 实体之间的关联 |
二、实体（Entity）
2.1 实体与实体集
- 实体：客观存在并可相互区别的事物。可以是具体的人、事、物，也可以是抽象的概念。
- 例：一个学生、一门课程、一次选课
- 实体集（Entity Set）：同类型实体的集合
- 例：全体学生、所有课程
- 实体型（Entity Type）：实体集的结构描述，即实体名 + 属性名集合
- 例：学生（学号，姓名，性别，出生日期，系别）
2.2 码（Key）
- 码：唯一标识实体的属性或属性组
- 候选码：能唯一标识实体的最小属性集，可以有多个
- 主码（Primary Key）：从候选码中选定的一个
- 超码（Superkey）：包含候选码的属性集（可能有冗余属性）
例：学生实体中，学号是候选码（也是主码），(学号, 姓名) 是超码但不是候选码。
2.3 属性的分类
按结构分
| 类型 | 说明 | 示例 |
|---|---|---|
| 简单属性 | 不可再分的原子属性 | 学号、性别 |
| 复合属性 | 由多个子属性组成 | 地址（省, 市, 街道, 邮编） |
取值数量分
| 类型 | 说明 | 示例 |
|---|---|---|
| 单值属性 | 一个实体只取一个值 | 学号、姓名 |
| 多值属性 | 一个实体可取多个值 | 联系电话（手机号+座机） |
多值属性在 ER 图中用双椭圆表示。
按性质分
| 类型 | 说明 | 示例 |
|---|---|---|
| 基本属性 | 直接存在的属性 | 姓名、出生日期 |
| 派生属性 | 由其他属性计算得到 | 年龄（由出生日期推导） |
派生属性在 ER 图中用虚椭圆表示。
三、联系（Relationship）
3.1 联系与联系集
- 联系：实体之间的关联
- 联系集：同类联系的集合
- 联系型：联系集的结构描述
3.2 联系的元数
按参与联系的实体集个数划分：
| 元数 | 名称 | 说明 | 示例 |
|---|---|---|---|
| 1:1 | 一元联系 | 同一实体集内部实体之间的联系 | 职工-领导（递归联系） |
| 2 | 二元联系 | 两个实体集之间的联系 | 学生-选课-课程 |
| 3 | 三元联系 | 三个实体集之间的联系 | 供应商-项目-零件供应关系 |
| n | n元联系 | 多个实体集之间的联系 |
3.3 映射基数（Mapping Cardinalities）
即一个实体通过联系集可以与另一个实体集中多少个实体相关联。
二元联系的四种基本类型
| 类型 | 含义 | 例子 |
|---|---|---|
| 1:1（一对一） | A中一个实体至多与B中一个实体关联，反之亦然 | 班级-班长 |
| 1:N（一对多） | A中一个实体可与B中多个实体关联，B中一个实体至多与A中一个实体关联 | 系-学生 |
| N:1（多对一） | 1:N 的反方向 | 学生-系 |
| M:N（多对多） | A中一个实体可与B中多个实体关联，反之亦然 | 学生-课程（选课） |
3.4 参与约束（Participation）
- 全参与（Total Participation）：实体集中的每一个实体都必须参与联系
- 例：每个学生必须属于一个系（学生端全参与）
- ER 图中用双线表示
- 部分参与（Partial Participation）：实体集中的实体可以不参与联系
- 例：并非所有教师都担任班主任
- ER 图中用单线表示
3.5 联系的属性
联系本身也可以有属性：
- 例：学生选修课程的”成绩”是选课联系的属性，不是学生的属性，也不是课程的属性
- 只有 M:N 联系的属性是必须的；1:1 和 1:N 联系的属性通常可以合并到某一端实体中
四、弱实体（Weak Entity）
4.1 定义
不能用自身属性唯一标识的实体，称为弱实体。它依赖于另一个实体（标识实体/Owner Entity）才能存在。
4.2 特点
- 弱实体有一个部分码（Partial Key）/ 分辨符：在同一个属主实体内可以唯一标识弱实体
- 弱实体的完整码 = 属主实体的主码 + 部分码
- ER 图中弱实体用双矩形表示，其与属主实体的联系用双菱形表示
4.3 示例
- 属主实体：职工（职工号为主码）
- 弱实体：职工家属
- 部分码：家属姓名
- 完整码：职工号 + 家属姓名
- 因为两个不同职工的家属可能同名
五、扩展 ER 模型（EER）
5.1 超类与子类（特化/泛化）
概念
- 超类（Superclass）：具有共同特征的一般化实体集
- 子类（Subclass）：超类中具有特殊特征的子集
- 子类继承超类的所有属性和联系
- 子类可以有自己特有的属性和联系
特化（Specialization）
从一般到特殊：自顶向下，将一个实体集按某些特征分解为多个子实体集。
例：
学生
/ | \
本科生 研究生 进修生
泛化（Generalization）
从特殊到一般：自底向上，将多个具有共同特征的实体集抽象为一个更高层的实体集。
例：
本科生 研究生 进修生
\ | /
学生
特化和泛化在 ER 图中用**三角形（ISA）**表示，顶点指向超类。提取到的关键词 “ISA” 即代表此概念。
5.2 特化/泛化的约束
成员资格约束
| 约束类型 | 说明 |
|---|---|
| 条件定义 | 按某个属性的值自动划分（如：学生按”类别”属性分为本科/研究生） |
| 用户定义 | 由用户手工指定分配 |
不相交性约束
| 约束类型 | 说明 |
|---|---|
| 不相交（Disjoint） | 一个实体最多属于一个子类 |
| 重叠（Overlapping） | 一个实体可以同时属于多个子类 |
提取到的关键词 “overlapping” 即重叠约束。
完备性约束
| 约束类型 | 说明 |
|---|---|
| 全特化（Total） | 每个超类实体必须属于某个子类 |
| 部分特化（Partial） | 超类实体可以不属于任何子类 |
四种组合：全-不相交、全-重叠、部分-不相交、部分-重叠。
5.3 聚集（Aggregation）
将一个联系集（连同参与的实体集）抽象为一个高层实体，参与其他联系。
- 适用场景：联系本身需要参与另一个联系
- 例：“学生-项目-导师”三元联系可以聚集为”指导”实体，再与”评价”联系关联
5.4 范畴（Category）/ 联合类型
由多个不同实体集的并集构成的超类。
- 与特化的区别：范畴的子类可以从多个不相关的实体集中选择成员
- 例：账户持有人可以是个人客户，也可以是公司客户
六、ER 图设计原则
6.1 实体 vs 属性
- 作为属性的条件：不需要再分解，也不需要与其他实体发生联系
- 作为实体的条件：有自己的多个属性，或需要参与其他联系
判断技巧：如果某”属性”在别处被引用，或者需要独立维护，就应该建模为实体。
6.2 实体 vs 联系
- 描述事物用实体
- 描述事物之间的关联用联系
- 一个动作事件如果有多个参与方，通常是联系（也可能是弱实体）
6.3 常见设计陷阱
| 陷阱 | 说明 |
|---|---|
| 用联系代替实体 | 把本应是实体的事物设计成了联系 |
| 用属性代替实体 | 把本应有独立结构的事物设计成了属性 |
| 不必要的联系 | 可以通过其他联系推导出来的冗余联系 |
| 联系方向搞反 | 1:N 的方向搞反 |
| 基数标注错误 | 把 M:N 错标成 1:N |
七、ER 模型到关系模型的转换
7.1 实体 → 关系表
- 每个实体集 → 一张关系表
- 实体的属性 → 表的列
- 主码 → 表的主键
7.2 联系 → 关系表/外键
| 联系类型 | 转换方式 |
|---|---|
| 1:1 | 在任意一端加入对方主码作为外键 |
| 1:N | 在 N 端实体表中加入 1 端主码作为外键 |
| M:N | 单独建一张联系表，包含两端主码+联系属性 |
| 弱实体 | 建表，主码 = 属主主码 + 部分码 |
| ISA特化 | 多种策略：只建超类表 / 每个子类建表 / 每个实体型建表 |
八、与其他章节的关联
- 《数据库设计与实践》第1章-数据库系统简介 —— 前序章节，数据库基础概念
- 后续章节：chap03 关系模型 → chap04 SQL → chap05 SQL实践 → chap07 关系规范化
数据库设计流程：需求分析 → ER 概念设计 → 关系模式转换 → 规范化 → 物理设计 → 实现