Chapter 6 Entity-Relationship Model¶

Database Design Approaches

E-R Model（本章重点）：从概念设计（conceptual design）出发，把企业/组织建模为实体（entity）与联系（relationship）的集合，再用图表示。
Normalization Theory（后续章节）：从关系模式出发，形式化分析“一个设计为什么不好”，并通过分解消除异常。

1 Modeling Components¶

1. 1 Entity Sets¶

实体建模强调的是设计视角，而不是程序实现视角。数据库可以被视为一组实体和实体之间的一组联系。

实体（entity）：一个客观存在且可与其他对象区分开的对象。
实体集（entity set）：具有相同类型、共享相同属性结构的一组实体。

例如：某位教师 Einstein 是一个实体，所有教师构成 instructor 实体集，所有学生构成 student 实体集。

1. 2 Attributes¶

属性用于描述实体或联系的特征，一个实体通常由一组属性来刻画，例如 instructor = (ID, name, street, city, salary)， course = (course_id, title, credits)。

每个属性都有自己的域（domain），即允许取值的集合。

属性类型	含义	示例
简单属性（simple）	不可再分	`salary`
复合属性（composite）	可继续拆成若干组成部分	`name`、`address`
单值属性（single-valued）	一个实体在该属性上只有一个值	`date_of_birth`
多值属性（multivalued）	一个实体可对应多个值	`phone_numbers`
派生属性（derived）	可由其他属性计算得到	`age` 可由 `date_of_birth` 推出

复合属性

name 可拆成 first_name、middle_initial、last_name
address 可拆成 street / city / state / postal_code
若某个组成部分还能继续拆分，则形成多层复合属性

温馨提示

复合属性适合于查询时经常要分别访问组成部分的场景
多值属性说明一个实体对应多个同类值，后续转换为关系模式时通常需要单独建表
派生属性通常不必冗余存储，除非有性能或业务需要

冗余属性（Redundant Attributes）

若某个信息已经由一个显式联系表达，就不应再在实体内部重复存储同样语义的属性。

例如，假设 instructor 中有属性 dept_name，同时又存在实体集 department 和联系集 inst_dept(instructor, department)，此时 dept_name 与 inst_dept 表达的是同一语义，dept_name 就是冗余属性。

冗余会导致信息重复、更新不一致、语义边界模糊，需要移除。

但是在后续把 E-R 图转换回关系模式时，为了减少额外关系、提高实现效率，这类属性有时会以外键列的形式重新出现。

1. 3 Relationship Sets¶

联系是多个实体之间的关联，同类联系的集合称为联系集。从形式上看，联系集可以看作多个实体集上的一个数学关系：

\[ R \subseteq E_1 \times E_2 \times \cdots \times E_n \]

其中每个元组 \((e_1, e_2, \dots, e_n)\) 表示一条具体联系。

例如，教师与学生之间的指导关系可以表示为 advisor，(44553, 22222) ∈ advisor 可解释为 ID = 44553 的教师是 ID = 22222 的学生的导师。

Degree of a Relationship Set

联系参与的实体集个数称为联系的度（degree）。

类型	含义	说明
二元联系（binary relationship）	涉及两个实体集	最常见
三元联系（ternary relationship）	涉及三个实体集	比较少见，但非常重要
\(n\) 元联系	涉及 \(n\) 个实体集	实践中较少

advisor(instructor, student) 是二元联系
proj_guide(instructor, student, project) 是三元联系

Extra Attributes in Relationship Sets

大多数联系集只表达有关联这一事实，不带额外属性，但也有联系本身需要被描述。例如 advisor 关系可以增加属性 date，表示学生从何时开始由该教师指导。这说明属性不只属于实体，联系本身也可以带属性。

1. 4 Keys¶

Super Key（超键）：一个或多个属性的集合，其取值能够唯一确定实体集中的每个实体。
Candidate Key（候选键）：最小超键，即去掉任一属性后不再唯一。
Primary Key（主键）：从候选键中选出的一个，作为实体集的主要标识。

参与联系的各实体集的主键组合，一定构成该联系集的一个超键。例如 advisor 的一个超键是 (s_id, i_id)。不过它是否是最小超键，还要看映射基数（mapping cardinality）。

1. 5 Mapping Cardinality Constraints¶

映射基数约束描述一个实体能通过某个联系关联到多少个另一个实体。对于二元联系，映射基数只有四种基本类型：

类型	含义	联合集的主键
One-to-One（1:1）	两边每个实体至多对应对方一个实体	任取一侧主键即可
One-to-Many（1:N）	左边一个实体可对应右边多个；右边至多对应左边一个	取多一侧实体集的主键
Many-to-One（N:1）	左边多个实体可对应右边一个	取多一侧实体集的主键
Many-to-Many（M:N）	两边都可对应多个	两边主键的并集是最小超键，通常作为主键

2 E-R Diagrams¶

基本符号

矩形（Rectangle）：实体集
菱形（Diamond）：联系集
矩形内部列出的名称：属性
下划线属性：主键属性
连线/箭头：参与与映射基数

Roles

同一个实体集在一个联系中可以出现多次，每次出现扮演的语义不同，这种语义标签称为角色（role）。

例如在课程先修关系中，同一个 course 实体集可出现两次，一次扮演当前课程 course_id，一次扮演先修课程 prereq_id，这两个名字就是角色名。

大学企业 E-R 图

Participation Constraints & Cardinality Limits

参与约束描述某个实体集中的实体是否必须参加某个联系。

类型	含义	图中表示
Total Participation	每个实体都必须至少参加一次该联系	双线
Partial Participation	某些实体可以完全不参加该联系	单线

section 在 sec_course 中通常是全参与：每个班次都必须属于某门课程
instructor 在 advisor 中通常是部分参与：并不是每位教师都一定担任导师

除了箭头/连线外，还可以用 l..h 形式表示更精细的基数与参与约束。

0..*：可为 0 个，也可为多个
1..1：必须且只能有 1 个

这种写法可以同时表达最大参与数和最小参与数，因而也能顺带表达是否全参与。

Ternary Relationships

对于三元及更高元联系，至多只允许一个箭头。若允许多个箭头，会出现不同教材/形式化体系中含义不一致的问题，因此为避免歧义，这里直接禁止。

3 Weak Entity Sets¶

没有自身完整主键、其存在依赖于另一个强实体集的实体集，称为弱实体集。

弱实体必须满足的条件

存在一个标识实体集（identifying entity set），通常是强实体集
通过一个标识联系（identifying relationship）与其相连
该联系对弱实体一侧通常是全参与
标识联系通常是从强实体到弱实体的 1:N

弱实体虽然没有完整主键，但通常仍有一个在局部范围内可区分的属性集，称为 Discriminator 或 Partial Key（部分键）。弱实体的主键通常由强实体的主键加上弱实体的部分键共同组成。

弱实体的表示方法

section 是弱实体，course 是其标识强实体
sec_course 是标识联系，因此用双菱形
sec_id / semester / year 是弱实体的判别属性，因此用虚线下划线
section 的主键是 (course_id, sec_id, semester, year)

强实体主键不一定要作为普通属性显式写在弱实体内部，它可以由标识联系隐含地带入。

如果把 course_id 明确放进 section 里，那么 section 也可以被改造成强实体，但这样会使 section 与 course 的联系语义部分重复。

4 Reduction to Relation Schemas¶

总体规则

每个实体集通常对应一个关系模式
每个联系集不一定都单独生成关系模式，要看基数与参与约束
每个多值属性通常单独生成一个关系模式

4. 1 Representing Entity Sets¶

强实体集直接转换为同名关系 + 相同属性，如 student(ID, name, tot_cred)。
弱实体集转换为关系时需要加入标识强实体的主键，如 section(course_id, sec_id, sem, year)，其中 course_id 来自强实体 course，sec_id, sem, year 来自弱实体 section。

4. 2 Representing Relationship Sets¶

Many-to-Many：通常必须单独建表，关系模式包含两个参与实体集的主键以及该联系自身的描述属性，例如 advisor(s_id, i_id)。
Many-to-One / One-to-Many：若联系在多侧是全参与，则可以把一侧主键直接加入多侧实体对应的表中，即内嵌为外键。例如不单独创建 inst_dept，而是在 instructor 中加入 dept_name。
One-to-One：可将任一侧主键加入另一侧表中，但如果被吸收的一侧在该联系中是部分参与，则新增外键列可能出现 null。
Weak Entity Identifying Relationship：弱实体与其标识强实体之间的联系模式通常是冗余的，例如 section 的模式已经包含了 course_id，因此通常无需再单独创建 sec_course(...)。

4. 3 Composite and Multivalued Attributes¶

复合属性在关系模式中要被摊平（flatten）。

示例

假设 instructor.name 由 first_name、middle_initial、last_name组成，则关系模式中可写成 first_name、middle_initial、last_name。若存在歧义，可保留前缀，如 name_first_name。

多值属性需要单独转换成新关系。若实体 E 有多值属性 M，则创建模式 EM(E 的主键, M)。

示例

假设教师有多值属性 phone_number，则有 inst_phone(ID, phone_number)。

若教师 22222 有两个电话号码 456-7890 和 123-4567，则映射为两条元组：

(22222, 456-7890)
(22222, 123-4567)

Special Case: time_slot

若某个实体除主键外只有一个多值属性，则可省略原实体关系，只保留多值属性关系。

例如上图可转化为 time_slot(time_slot_id, day, start_time, end_time)，但这也会导致 section 中的 time_slot 不再适合作为普通外键直接引用该优化前的实体关系。

5 Extended E-R Features¶

5. 1 Specialization & Generalization¶

特化（specialization）是自顶向下（top-down）的设计过程，它从一个高层实体集出发，划分出若干具有特殊属性或特殊联系参与方式的低层实体集，通常用一个标有 ISA 的三角形连接高层与低层实体集。低层实体集会继承高层实体集的全部属性以及全部联系参与能力。

示例

person 可特化为 student 与 employee
employee 还可进一步特化为 instructor 与 secretary

泛化（generalization）"是自底向上（bottom-up）的设计过程，它将多个具有共同特征的实体集合并为一个更高层的实体集。在图形上，泛化与特化的表示方法完全相同。

Multiple Specializations

一个实体集可以基于不同标准发生多次特化。例如，对 employee 可以同时做两套划分：

按岗位：instructor / secretary
按用工方式：permanent_employee / temporary_employee

因此一个具体员工可能同时属于 instructor 和 permanent_employee。

5. 2 Design Constraints on Specialization / Generalization¶

成员资格约束

低层实体集的成员资格可以由两种方式决定：

Condition-defined：由条件自动决定，例如年龄大于 65 的 person 自动属于 senior_citizen
User-defined：由设计者/业务规则显式决定

低层实体是否可交叉

Disjoint（互斥）：一个高层实体最多属于一个低层实体集
Overlapping（重叠）：一个高层实体可以同时属于多个低层实体集

完备性约束

用于说明高层实体是否必须落入至少一个低层实体集：

Total：必须属于至少一个低层实体集
Partial：可以不属于任何低层实体集

5. 3 Aggregation¶

当我们需要在联系之上再建立联系时，可使用聚合（aggregation）。

聚合的动机

设有三元联系 proj_guide(instructor, student, project)。

若还要记录某次指导活动对应的评估 evaluation，直接再建一个普通联系会造成与 proj_guide 的语义重叠。

聚合的做法是：

把原联系整体看成一个更高层次的抽象对象
再让它与其他实体建立联系

示例

某位教师指导某位学生完成某个项目
这个“指导事实”本身还可以关联一个 evaluation

聚合转换为关系模式时，需要建立一个关系来表示：

被聚合联系的主键
相关实体集的主键
以及聚合联系的描述属性

示例

对于 eval_for，可创建 eval_for(s_ID, project_id, i_ID, evaluation_id)。

如果愿意允许 evaluation_id 取 null，那么 proj_guide 关系在某些设计中甚至可以被视为冗余。

5. 4 Representing Specialization via Schemas¶

方法 1：为高层实体和每个低层实体都单独建立关系模式。

示例

person(ID, name, street, city)
student(ID, tot_cred)
employee(ID, salary)

特点：不冗余，但访问某个低层实体完整信息时，通常需要与高层表连接。

方法 2：每个低层实体关系中直接包含其继承属性。

示例

student(ID, name, street, city, tot_cred)
employee(ID, name, street, city, salary)

如果特化是 total specialization，则高层实体表甚至可以不实际存储，而只作为视图存在。

若一个实体可能同时属于多个低层实体集，则继承属性可能会被重复存储。

6 Design Issues¶

6. 1 Entity Sets vs Attributes¶

是否把某个概念设计为实体集，而不是属性，取决于它是否值得被独立描述。

phone 作为实体比作为属性更灵活

若把 phone 设计成独立实体，可以进一步记录：

电话号码类型
运营商
是否为主号码
一个人拥有多个号码

6. 2 Entity Sets vs Relationship Sets¶

若某个概念主要描述的是实体之间发生的一次动作/交互，通常更适合建模为联系集，而不是实体集。

6. 3 Binary vs N-ary Relationship Sets¶

虽然理论上非二元联系常常能被二元联系替代，但不能机械地拆成二元关系，因为 \(n\) 元联系更直接表达多个实体共同参与同一事实，一旦强行拆分，原有约束可能不再明显，甚至丢失

示例

parents(child, father, mother) 看似三元联系，但通常拆成 father(child, father) 和 mother(child, mother)，因为现实中父亲信息和母亲信息可能是不完整、分别获取的。
proj_guide(instructor, student, project) 更自然地表达为三元联系，因为它强调的是三者共同构成的一条事实。

6. 4 Converting Non-Binary Relationships to Binary Form¶

若必须把一个 \(n\) 元联系转成多个二元联系，可引入一个人工实体集（artificial entity set）。

转换思路

将三元联系 \(R(A, B, C)\) 转换为：

一个新实体集 \(E\)
三个二元联系 \(R_A(E, A)\)、\(R_B(E, B)\)、\(R_C(E, C)\)

若原联系中有一条事实 \((a_i, b_i, c_i)\)，则：

创建一个新的 \(e_i ∈ E\)
插入 \((e_i, a_i)\) 到 \(R_A\)
插入 \((e_i, b_i)\) 到 \(R_B\)
插入 \((e_i, c_i)\) 到 \(R_C\)

局限

原联系上的约束需要额外翻译
并非所有约束都能无损保留
转换后可能出现一些二元关系实例，并不对应任何合法的原三元联系实例

如果不想给 \(E\) 单独造一个标识属性，也可以把 \(E\) 设计成一个由三条联系共同标识的弱实体集。