第五章 数据库设计与 E-R 模型
第五章 数据库设计与 E-R 模型
5.1 数据库设计概述
5.1.1 设计阶段
数据库设计分为以下几个阶段:
- 初始阶段:全面描述数据库潜在用户的数据需求
- 概念设计阶段:选择合适的数据模型,将需求转换为数据库的概念模式 (Conceptual Schema)
- 一个完善的概念模式应能反映企业的功能需求
- 描述将在数据上执行的各种操作(或事务)
- 最终阶段:从抽象数据模型过渡到数据库实现
- 逻辑设计:确定数据库模式(关系模式集合),解决以下问题:
- 商业决策:应该记录哪些属性?
- 计算机科学决策:应该有哪些关系模式?属性如何分布?
- 物理设计:确定数据库的物理存储布局
- 逻辑设计:确定数据库模式(关系模式集合),解决以下问题:
5.1.2 设计中的两大陷阱
在设计数据库模式时,必须避免两个主要问题:
- 冗余:不好的设计可能导致重复信息,进而引发数据不一致
- 不完整:不好的设计可能使企业的某些方面难以或无法建模
仅避免不好的设计还不够——可能有大量"好"的设计需要从中选择。
5.1.3 设计方法
| 方法 | 核心思想 |
|---|---|
| E-R 模型 | 将企业建模为实体 (Entity) 和关系 (Relationship) 的集合,用 E-R 图表示 |
| 规范化理论 | 形式化地定义什么是"坏"的设计,并提供检测方法 |
5.2 实体-关系(E-R)模型
5.2.1 E-R 模型的三个基本概念
E-R 数据模型通过以下三个核心概念来描述数据库的整体逻辑结构:
- 实体集 (Entity Sets)
- 关系集 (Relationship Sets)
- 属性 (Attributes)
E-R 模型通过 E-R 图 图形化地表示数据库的整体逻辑结构。
5.2.2 实体与实体集
- 实体:存在且可与其他对象区分的对象
- 例:特定的人、公司、事件、植物
- 实体集:同类型、共享相同属性的实体集合
- 例:所有人员、公司、树木、假日的集合
- 属性:实体集中所有成员所拥有的描述性属性
- 例:
instructor = (ID, name, salary),course = (course_id, title, credits)
- 例:
- 主键:属性的一个子集,能够唯一标识实体集中的每个成员
在 E-R 图中,矩形表示实体集,属性列在矩形内部,下划线标识主键属性。
5.2.3 关系与关系集
- 关系:多个实体之间的关联
- 例:学生 44553(Peltier)与导师 22222(Einstein)之间的
advisor关系
- 例:学生 44553(Peltier)与导师 22222(Einstein)之间的
- 关系集:数学意义上的 n 元关系,每个实体取自不同的实体集:
{(e1,e2,…,en)∣e1∈E1,e2∈E2,…,en∈En} \{(e_1, e_2, \ldots, e_n) \mid e_1 \in E_1, e_2 \in E_2, \ldots, e_n \in E_n\} {(e1,e2,…,en)∣e1∈E1,e2∈E2,…,en∈En}
在 E-R 图中,菱形表示关系集。
关系集也可以有描述性属性。例:advisor 关系集可以有 date 属性,记录学生开始接受该导师指导的日期。
5.2.4 角色
关系集中的实体集不必互不相同。每个实体集的参与被称为在关系中扮演一个"角色"。
例:prereq(先修课)关系中,course_id 和 prereq_id 分别扮演不同角色。
5.2.5 关系的度
- 二元关系:涉及两个实体集(度为 2),数据库系统中大多数关系集是二元的
- 多元关系:涉及三个或更多实体集,较少见
- 例:
proj_guide是 instructor、student 和 project 之间的三元关系
- 例:
5.3 复杂属性类型
| 属性类型 | 说明 | 示例 |
|---|---|---|
| 简单属性 | 不可再分的原子属性 | — |
| 复合属性 | 可划分为子属性 | name → first_name + last_name |
| 单值属性 | 每个实体只有一个值 | date_of_birth |
| 多值属性 | 每个实体可有多个值 | phone_numbers |
| 派生属性 | 可从其他属性计算得出 | age ← date_of_birth |
- 域:每个属性的允许值集合
5.4 映射基数约束
映射基数约束表示一个实体可以通过关系集关联到另一个实体的数量,在描述二元关系集时最有用。
5.4.1 四种映射基数类型
| 类型 | 含义 |
|---|---|
| 一对一 | A 中每个实体最多关联 B 中的一个实体,反之亦然 |
| 一对多 | A 中一个实体可关联 B 中的多个实体;B 中每个实体最多关联 A 中的一个实体 |
| 多对一 | A 中每个实体最多关联 B 中的一个实体;B 中一个实体可关联 A 中的多个实体 |
| 多对多 | A 中一个实体可关联 B 中的多个实体,反之亦然 |
在 E-R 图中:有向线 (→) 表示"一",无向线 (—) 表示"多"。
5.4.2 全部参与与部分参与
| 类型 | 图示 | 含义 |
|---|---|---|
| 全部参与 | 双线 | 实体集中的每个实体至少参与关系集中的一个关系 |
| 部分参与 | 单线 | 某些实体可能不参与任何关系 |
例:student 在 advisor 关系中是全部参与(每个学生必须有导师),instructor 是部分参与(并非每位教师都指导了学生)。
5.4.3 基数约束的数值表示
使用 l..h 的形式表示最小和最大基数:
- 最小值
1表示全部参与 - 最大值
1表示最多参与一个关系 - 最大值
*表示无限制
例:导师可指导 0..* 个学生;学生必须有 1..1 个导师。
5.5 主键
5.5.1 实体集的主键
- 实体集中的任意两个实体在所有属性上不能有完全相同的值
- 键:足以区分实体的一组属性
5.5.2 关系集的主键
关系集 R 涉及实体集 E1,E2,…,EnE_1, E_2, \ldots, E_nE1,E2,…,En:
- R 的主键由 E1,E2,…,EnE_1, E_2, \ldots, E_nE1,E2,…,En 的主键的并集组成
- 若 R 有描述性属性 a1,a2,…,ama_1, a_2, \ldots, a_ma1,a2,…,am,则这些属性也包含在主键中
5.5.3 二元关系主键的选择
| 映射基数 | 主键选择 |
|---|---|
| 多对多 | 两个实体集主键的并集 |
| 一对多 | "多"侧的主键 |
| 多对一 | "多"侧的主键 |
| 一对一 | 任意一侧的主键均可 |
5.6 弱实体集
弱实体集的存在依赖于另一个实体(称为标识实体),而非弱实体集称为强实体集。
5.6.1 问题场景
考虑 section 实体,其唯一标识需要 course_id、semester、year 和 sec_id。若在 section 中去掉冗余的 course_id,则剩余的 sec_id、year、semester 不足以唯一标识一个 section。
5.6.2 解决方案
- 将
sec_course关系作为特殊关系——它提供额外的course_id信息来唯一标识 section - 使用标识实体(course)加上额外的分辨符来唯一标识弱实体
5.6.3 相关术语
| 术语 | 含义 |
|---|---|
| 标识实体集 | 提供标识信息的强实体集 |
| 拥有 | 标识实体集拥有其所标识的弱实体集 |
| 标识关系 | 将弱实体集与标识实体集关联的关系 |
| 存在依赖 | 弱实体集依赖于标识实体集而存在 |
5.6.4 E-R 图表示
| 元素 | 符号 |
|---|---|
| 弱实体集 | 双矩形 |
| 弱实体的分辨符 | 虚线下划线 |
| 标识关系 | 双菱形 |
例:section 的主键 = (course_id, sec_id, semester, year)
5.7 移除实体集中的冗余属性
若实体集 student 已有 dept_name 属性,且存在关系集 stud_dept 关联 student 和 department,则 student 中的 dept_name 冗余,应移除。
⚠️ 注意:在将 E-R 图转换回关系表时,某些情况下该属性会被重新引入。
5.8 将 E-R 图转换为关系模式
5.8.1 基本转换规则
E-R 图中的每个实体集和关系集都对应一个唯一的关系模式,模式名与实体集/关系集名相同,列对应属性。
5.8.2 强实体集的转换
强实体集转换为具有相同属性的模式:
student(ID, name, tot_cred)
5.8.3 弱实体集的转换
弱实体集转换为包含标识强实体集主键的表:
section(course_id, sec_id, sem, year)
5.8.4 复合属性的处理
复合属性被扁平化,为每个子属性创建独立的列:
instructor(ID, first_name, middle_initial, last_name,
street_number, street_name, apt_number,
city, state, zip_code, date_of_birth)
5.8.5 多值属性的处理
实体 E 的多值属性 M 由独立的模式 EM 表示:
inst_phone(ID, phone_number)
每个多值属性的值映射为 EM 关系的一个独立元组。
5.8.6 关系集的转换
- 多对多关系集:转换为包含两个参与实体集主键的模式,加上描述性属性
advisor(s_id, i_id, date) - 一对多/多对一(多在侧的参与为全部):可通过在"多"侧添加"一"侧主键来合并,无需独立模式
- 一对一:任意一侧都可作为"多"侧处理
- 弱实体集的标识关系:其模式冗余(信息已在弱实体模式中体现)
5.8.7 大学数据库的完整模式
classroom(building, room_number, capacity)
department(dept_name, building, budget)
course(course_id, title, dept_name, credits)
instructor(ID, name, dept_name, salary)
section(course_id, sec_id, semester, year, building, room_number, time_slot_id)
teaches(ID, course_id, sec_id, semester, year)
student(ID, name, dept_name, tot_cred)
takes(ID, course_id, sec_id, semester, year, grade)
advisor(s_ID, i_ID)
time_slot(time_slot_id, day, start_time, end_time)
prereq(course_id, prereq_id)
5.9 扩展 E-R 特性
5.9.1 特化
特化是自顶向下的设计过程——在实体集内指定与其他实体有区别的子分组。
- 子分组变为低层实体集,具有高层实体集不共享的属性或关系
- 用标记为 ISA 的三角形表示(如 instructor “is a” person)
- 属性继承:低层实体集继承高层实体集的所有属性和关系参与
特化可以是 重叠(如 student/employee)或不相交(如 instructor/secretary),也可以是全部或部分。
转换为模式的两种方法:
| 方法 | 做法 | 缺点 |
|---|---|---|
| 方法一 | 为高层实体建模式,为每个低层实体建独立模式(含高层主键+本地属性) | 查询需要访问两个关系 |
| 方法二 | 为每个实体集建包含所有属性的模式 | 同时属于多个低层实体的实体信息冗余 |
5.9.2 泛化
泛化是自底向上的设计过程——将共享相同特征的多个实体集合并为一个高层实体集。
特化与泛化互为逆操作,在 E-R 图中表示方式相同,两个术语常互换使用。
5.9.3 完整性约束
规定高层实体集中的实体是否必须属于泛化中至少一个低层实体集:
| 类型 | 含义 |
|---|---|
| 全部 | 实体必须属于某个低层实体集(用关键字 total 标记) |
| 部分 | 实体可以不属任何低层实体集(默认) |
例:
student泛化是全部的——每个学生实体必须是 graduate 或 undergraduate。
5.9.4 聚集
聚集处理的是关系集之间的重叠信息。当两个关系集表示重叠信息但其中一个不能丢弃时,通过聚集将关系抽象为实体来处理。
将关系视为抽象实体,允许关系之间的关系。
转换规则:创建包含以下内容的模式:
- 被聚集关系的主键
- 关联实体集的主键
- 描述性属性
例:
eval_for(s_ID, project_id, i_ID, evaluation_id)
此时 proj_guide 模式变为冗余。
5.10 E-R 设计问题
5.10.1 常见设计决策
| 决策问题 | 建议 |
|---|---|
| 属性 vs 实体集? | 若需存储关于某概念的额外信息或支持多个值,应作为实体集 |
| 实体集 vs 关系集? | 关系集通常描述实体之间发生的动作 |
| 二元 vs 非二元关系? | 非二元关系更清晰地展示多个实体参与同一关系,但某些情况下用二元关系更好 |
| 强实体 vs 弱实体? | 取决于是否存在依赖关系 |
| 特化/泛化? | 有助于模块化设计 |
| 聚集? | 将聚合实体集作整体看待,无需关注其内部结构 |
5.10.2 非二元关系到二元关系的转换
任何非二元关系都可以用二元关系表示——创建一个人工实体集 E:
- 将实体集 A、B、C 之间的三元关系 R 替换为 E + 三个二元关系 RA、RB、RC
- 为 E 创建标识属性,将 R 的属性添加到 E
- 对 R 中的每个关系 (ai,bi,ci)(a_i, b_i, c_i)(ai,bi,ci),创建新实体 ei∈Ee_i \in Eei∈E 并添加到 RA、RB、RC
⚠️ 约束转换可能不完整——翻译后的模式可能存在 R 中不存在的实例。可通过使 E 成为由三个关系集标识的弱实体集来避免创建标识属性。
5.10.3 常见错误举例
在 E-R 图中常见的错误包括:属性误作实体、关系基数标注错误、冗余属性未移除等。
5.11 替代表示法
5.11.1 常用 E-R 表示法
| 表示法 | 特点 |
|---|---|
| Chen 表示法 | 经典表示法,矩形=实体、菱形=关系、椭圆=属性 |
| IDE1FX (乌鸦脚) | 用"乌鸦脚"符号表示"多"侧,业界常用 |
| UML 类图 | 统一建模语言的类图对应 E-R 图,但存在若干差异 |
5.11.2 E-R 图符号总结
| 元素 | 符号 |
|---|---|
| 实体集 | 矩形 |
| 弱实体集 | 双矩形 |
| 关系集 | 菱形 |
| 标识关系 | 双菱形 |
| 属性 | 椭圆 |
| 多值属性 | 双椭圆 |
| 派生属性 | 虚线椭圆 |
| 主键属性 | 下划线 |
| 弱实体分辨符 | 虚线下划线 |
| 全部参与 | 双线连接 |
| 基数"一" | 有向线(→) |
| 基数"多" | 无向线(—) |
| 特化/泛化 | ISA 三角形 |
5.12 数据库设计的其他方面
- 功能需求:系统需要支持哪些查询和事务
- 数据流与工作流:数据如何在系统中流转和处理
- 模式演化:数据库模式如何随时间和需求变化而调整
本章重点:掌握 E-R 模型的核心概念(实体集、关系集、属性、映射基数)、弱实体集的处理、E-R 图到关系模式的转换规则、以及扩展特性(特化/泛化/聚集)。这些是数据库概念设计的基石。
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。
更多推荐


所有评论(0)