数据库设计/实体关系数据模型

实体关系 (ER) 数据模型 已经存在超过 35 年。它非常适合用于数据库的数据建模，因为它相当抽象，易于讨论和解释。ER 模型很容易转换为关系。ER 模型，也称为 ER 模式，由 ER 图表示。

ER 建模基于两个概念

实体，定义为保存特定信息（数据）的表
关系，定义为实体之间的关联或交互

以下是一个示例，说明这两个概念如何在 ER 数据模型中结合使用：Ba 教授（实体）讲授（关系）数据库系统课程（实体）。

在本节的剩余部分，我们将使用一个名为 COMPANY 数据库的示例数据库来说明 ER 模型的概念。该数据库包含有关员工、部门和项目的信息。需要注意的重要事项包括

公司有多个部门。每个部门都有唯一的标识、名称、办公室位置和特定负责管理该部门的员工。
部门控制着多个项目，每个项目都有唯一的名称、唯一的编号和预算。
每个员工都有姓名、身份证号码、地址、工资和出生日期。员工被分配到一个部门，但可以加入多个项目。我们需要记录员工在每个项目的开始日期。我们还需要知道每个员工的直属主管。
我们想要跟踪每个员工的受抚养人。每个受抚养人都有姓名、出生日期和与员工的关系。

实体、实体集和实体类型

实体是现实世界中具有独立存在的对象，可以与其他对象区分开来。一个实体可能是

具有物理存在的物体（例如，讲师、学生、汽车）
具有概念性存在的物体（例如，课程、工作、职位）

实体可以根据其强度进行分类。如果实体的表存在依赖，则该实体被认为是弱实体。

也就是说，它不能在没有与另一个实体的关系的情况下存在
它的主键是从父实体的主键派生的
- COMPANY 数据库中的 Spouse 表是一个弱实体，因为它的主键依赖于 Employee 表。如果没有相应的员工记录，配偶记录将不存在。

如果一个实体可以独立于其所有相关实体而存在，则该实体被认为是强实体。

内核是强实体。
没有外键或包含可以为空的外键的表是强实体

另一个需要了解的术语是实体类型，它定义了类似实体的集合。

实体集 是在特定时间点对某个实体类型的实体的集合。在实体关系图 (ERD) 中，实体类型由框中的名称表示。例如，在图 8.1 中，实体类型为 EMPLOYEE。

图 8.1。具有实体类型 EMPLOYEE 的 ERD。

存在依赖

一个实体的存在依赖于相关实体的存在。如果它具有强制外键（即不能为空的外键属性），则它是存在依赖的。例如，在 COMPANY 数据库中，Spouse 实体存在依赖于 Employee 实体。

实体的种类

您还应该熟悉不同种类的实体，包括独立实体、依赖实体和特征实体。这些将在下面介绍。

独立实体

独立实体，也称为内核，是数据库的支柱。其他表都是基于它们的。内核具有以下特征

它们是数据库的基础。
主键可以是简单的，也可以是复合的。
主键不是外键。
它们的存在不依赖于另一个实体。

如果我们回到我们的 COMPANY 数据库，独立实体的示例包括 Customer 表、Employee 表或 Product 表。

依赖实体

依赖实体，也称为派生实体，依赖于其他表以获得其含义。这些实体具有以下特征

依赖实体用于将两个内核连接在一起。
据说它们存在依赖于两个或多个表。
多对多关系成为具有至少两个外键的联结表。
它们可能包含其他属性。
外键标识每个关联表。
主键有三种选择
1. 如果唯一，使用关联表的复合外键
2. 使用复合外键和限定列
3. 创建一个新的简单主键

特征实体

特征实体 提供有关另一个表的更多信息。这些实体具有以下特征

它们代表多值属性。
它们描述其他实体。
它们通常具有从一对多的关系。
外键用于进一步识别特征表。
主键选择如下
1. 使用外键加限定列的组合
2. 创建一个新的简单主键。在 COMPANY 数据库中，这些可能包括
  - Employee (EID, Name, Address, Age, Salary) – EID 是简单主键。
  - EmployeePhone (EID, Phone) – EID 是复合主键的一部分。这里，EID 也是外键。

属性

每个实体由一组属性描述（例如，员工 = （姓名、地址、出生日期（年龄）、工资）。

每个属性都有一个名称，并与一个实体和一个合法值的域相关联。但是，有关属性域的信息不会显示在 ERD 上。

在实体关系图中（如图 8.2 所示），每个属性由一个包含名称的椭圆表示。

图 8.2. 属性在 ERD 中的表示方式。

属性类型

您需要熟悉几种类型的属性。其中一些保持原样，但一些需要调整以方便在关系模型中表示。本节将讨论属性类型。稍后我们将讨论将属性修复以正确适应关系模型。

简单属性

简单属性是从原子值域中提取的属性；它们也被称为单值属性。在 COMPANY 数据库中，一个例子是：Name = {John}；Age = {23}

复合属性

复合属性是由属性层次结构组成的属性。使用我们的数据库示例，如图 8.3 所示，Address 可能由 Number、Street 和 Suburb 组成。因此这将被写为 → Address = {59 + ‘Meek Street’ + ‘Kingsford’}

图 8.3. 复合属性示例。

多值属性

多值属性是每个实体都有值集的属性。来自 COMPANY 数据库的多值属性示例（如图 8.4 所示）是员工的学位：BSc、MIT、PhD。

图 8.4. 多值属性示例。

派生属性

派生属性是包含从其他属性计算得出的值的属性。如图 8.5 所示，Age 可以从 Birthdate 属性派生。在这种情况下，Birthdate 被称为存储属性，它被物理保存到数据库中。

图 8.5. 派生属性示例。

键

对实体的一个重要约束是键。键是一个属性或一组属性，其值可以用来唯一标识实体集中单个实体。

键类型

键有几种类型。这些在下面描述。

候选键

候选键是唯一且最小的简单键或复合键。它是唯一的，因为表中的两行不能在任何时候都具有相同的值。它是最小的，因为需要每列才能获得唯一性。

从我们的 COMPANY 数据库示例中，如果实体是 Employee(EID, First Name, Last Name, SIN, Address, Phone, BirthDate, Salary, DepartmentID)，可能的候选键是

EID、SIN
First Name 和 Last Name - 假设公司中没有其他人具有相同的姓名
Last Name 和 DepartmentID - 假设两个姓氏相同的人不在同一个部门工作

复合键

复合键由两个或多个属性组成，但它必须是最小的。

使用候选键部分的示例，可能的复合键是

First Name 和 Last Name - 假设公司中没有其他人具有相同的姓名
Last Name 和 Department ID - 假设两个姓氏相同的人不在同一个部门工作

主键

主键是由数据库设计人员选择的候选键，用作整个实体集的识别机制。它必须唯一标识表中的元组，并且不能为 null。主键在 ER 模型中通过下划线属性来表示。

候选键由设计人员选择以唯一标识表中的元组。它不能为 null。
键由数据库设计人员选择用作整个实体集的识别机制。这被称为主键。此键在 ER 模型中通过下划线属性来表示。

在以下示例中，EID 是主键

Employee(EID, First Name, Last Name, SIN, Address, Phone, BirthDate, Salary, DepartmentID)

次要键

次要键是专门用于检索目的的属性（可以是复合属性），例如：Phone 和 Last Name。

备用键

备用键是所有未被选为主键的候选键。

外键

外键 (FK)是表中引用另一个表中主键的属性，或者可以为 null。外键和主键必须具有相同的数据类型。

在下面的 COMPANY 数据库示例中，DepartmentID 是外键

Employee(EID, First Name, Last Name, SIN, Address, Phone, BirthDate, Salary, DepartmentID)

空值

空值是一个特殊符号，独立于数据类型，表示未知或不适用。它不表示零或空白。空值的特征包括

没有数据条目
主键中不允许
应避免在其他属性中使用
可以表示
- 未知属性值
- 已知但缺失的属性值
- “不适用”条件
在使用 COUNT、AVERAGE 和 SUM 等函数时可能会导致问题
在关联表链接时可能会导致逻辑问题

注意：当任一参数为 null 时，比较运算的结果为 null。当任一参数为 null 时，算术运算的结果为 null（忽略 null 的函数除外）。

null 使用示例

使用图 8.6 中的 Salary 表 (Salary_tbl) 作为 null 使用示例。

图 8.6. null 示例的 Salary 表，作者：A. Watt。

首先，查找所有在 Sales (jobName 列下) 的员工 (emp#) ，其薪资加上佣金大于 30,000。

SELECT emp# FROM Salary_tbl
WHERE jobName = Sales AND
(commission + salary) > 30,000 –> E10 和 E12

由于佣金列中的 null 值，此结果不包含 E13。为了确保包含带有 null 值的行，我们需要查看各个字段。通过将 E13 的佣金和薪资相加，结果将为 null 值。解决方案如下。

SELECT emp# FROM Salary_tbl
WHERE jobName = Sales AND
(commission > 30000 OR
salary > 30000 OR
(commission + salary) > 30,000 –>E10 和 E12 和 E13

关系

关系是将表格连接在一起的纽带。它们用于连接表格之间相关的信息。

关系强度基于相关实体的主键的定义方式。如果相关实体的主键不包含父实体的主键组件，则存在弱关系或非识别关系。公司数据库示例包括

Customer(CustID, CustName)
Order(OrderID, CustID, Date)

如果相关实体的主键包含父实体的主键组件，则存在强关系或识别关系。示例包括

Course(CrsCode, DeptCode, Description)
Class(CrsCode, Section, ClassTime…)

关系类型

以下是各种关系类型的描述。

一对多 (1:M) 关系

一对多 (1:M) 关系应该是任何关系数据库设计的规范，并且存在于所有关系数据库环境中。例如，一个部门有多个员工。图 8.7 显示了其中一名员工与部门的关系。

图 8.7. 一对多关系示例。

一对一 (1:1) 关系

一对一 (1:1) 关系是一个实体与另一个实体之间仅存在一种关系，反之亦然。它在任何关系数据库设计中都应该很少见。实际上，它可能表明两个实体实际上属于同一个表。

来自 COMPANY 数据库的示例是，一个员工与一个配偶相关联，一个配偶与一个员工相关联。

多对多 (M:N) 关系

对于多对多关系，请考虑以下几点

它不能在关系模型中这样实现。
它可以更改为两个 1:M 关系。
它可以通过分解来实现，以生成一组 1:M 关系。
它涉及组合实体的实现。
创建两个或多个 1:M 关系。
组合实体表必须至少包含原始表的主键。
链接表包含外键值的多次出现。
可以根据需要分配其他属性。
它可以通过创建组合实体或桥接实体来避免 M:N 关系固有的问题。例如，一名员工可以参与多个项目，或者一个项目可以有多名员工参与，具体取决于业务规则。或者，一名学生可以选修多门课程，一门课程可以容纳多名学生。

图 8.8 显示了 M:N 关系的另一个方面，即员工在不同项目中具有不同的开始日期。因此，我们需要一个包含 EID、Code 和 StartDate 的 JOIN 表。

图 8.8. 员工在不同项目中具有不同开始日期的示例。

映射 M:N 二元关系类型的示例

对于每个 M:N 二元关系，识别两个关系。
A 和 B 代表参与 R 的两个实体类型。
创建一个新关系 S 来表示 R。
S 需要包含 A 和 B 的 PK。这些可以一起成为 S 表中的 PK，或者这些与新表 R 中的另一个简单属性一起可以成为 PK。
主键 (A 和 B) 的组合将构成 S 的主键。

一元关系 (递归)

一元关系，也称为递归关系，是同一个实体集的实例之间存在关系的一种关系。在这种关系中，主键和外键相同，但它们表示两个具有不同角色的实体。请参见图 8.9 中的示例。

对于一元关系中的一些实体，可以创建一个单独的列，该列引用同一实体集的主键。

图 8.9. 一元关系示例。

三元关系

三元关系是涉及三个表之间多对多关系的关系类型。

请参见图 8.10 中映射三元关系类型的示例。注意n 元表示关系中的多个表。（记住，N = 多个。）

对于每个 n 元 (> 2) 关系，创建一个新关系来表示该关系。
新关系的主键是参与实体的主键的组合，这些主键包含 N (多个) 一侧。
在大多数 n 元关系的情况下，所有参与实体都包含多个方面。

图 8.10. 三元关系示例。

关键词

备用键: 所有未被选为主键的候选键

候选键: 一个简单或复合键，它是唯一的（表中没有两行可以具有相同的值）并且是最小的（每列都是必要的）

特征实体: 提供有关另一个表的更多信息的实体

复合属性: 由属性层次结构组成的属性

复合键: 由两个或多个属性组成，但它必须是最小的

从属实体: 这些实体依赖其他表来获取其含义

派生属性: 包含从其他属性计算得出的值的属性

派生实体: 参见从属实体

EID: 员工识别码 (ID)

实体: 现实世界中具有独立存在并且可以与其他对象区分开来的事物或对象

实体关系 (ER) 数据模型: 也称为 ER 架构，由 ER 图表示。它们非常适合用于数据库的数据建模。

实体关系架构: 参见实体关系数据模型

实体集: 在某个时间点，实体类型的实体集合

实体类型: 类似实体的集合

外键 (FK): 表中引用另一个表的主键的属性，或者可以为 null

独立实体: 作为数据库的构建块，这些实体是其他表的基础

内核: 参见独立实体

键: 属性或属性组，其值可用于唯一标识实体集中的单个实体

多值属性: 每个实体都有一组值的属性

n 元: 多个表之间的关系

空: 一个特殊的符号，独立于数据类型，表示未知或不适用；它不表示零或空白

递归关系: 参见 *一元关系*

关系: 实体之间的关联或交互；用于连接表之间相关的資訊

关系强度: 基于相关实体主键的定义方式

次要键: 严格用于检索目的的属性

简单属性: 从原子值域中提取

SIN: 社会保险号

单值属性: 参见 *简单属性*

存储属性: 物理保存到数据库中

三元关系: 一种关系类型，涉及三个表之间多对多关系。

一元关系: 同一实体集的发生之间存在关系。

练习

ER建模基于哪两个概念？
图 8.11 中的数据库由两个表组成。使用此图回答问题 2.1 到 2.5。图 8.11. 导演和戏剧表，用于问题 2，作者 A. Watt。
1. 识别每个表的主键。
2. 识别 PLAY 表中的外键。
3. 识别两个表中的候选键。
4. 绘制 ER 模型。
5. PLAY 表是否具有引用完整性？为什么或为什么不？
定义以下术语（您可能需要使用互联网查找其中一些）：模式主机语言数据子语言数据定义语言一元关系外键虚拟关系连接复合键链接表
RRE 货运公司数据库包含图 8.12 中的三个表。使用图 8.12 回答问题 4.1 到 4.5。图 8.12. 卡车、基地和类型表，用于问题 4，作者 A. Watt。
1. 识别每个表的主键和外键。
2. TRUCK 表是否具有实体和引用完整性？为什么或为什么不？解释你的答案。
3. TRUCK 表和 BASE 表之间存在什么关系？
4. TRUCK 表包含多少个实体？
5. 识别 TRUCK 表候选键。图 8.13. 客户和图书订单表，用于问题 5，作者 A. Watt。
假设您正在使用图 8.13 中的数据库，它由两个表组成。使用图 8.13 回答问题 5.1 到 5.6。
1. 识别每个表中的主键。
2. 识别 BookOrders 表中的外键。
3. 两个表中是否有任何候选键？
4. 绘制 ER 模型。
5. BookOrders 表是否具有引用完整性？为什么或为什么不？
6. 表中是否包含冗余数据？如果是，哪个表以及冗余数据是什么？
查看图 8.14 中的学生表，列出所有可能的候选键。为什么您选择这些？图 8.14. 用于问题 6 的学生表，作者 A. Watt。图 8.15. 学校数据库的 ERD，用于问题 7-10，作者 A. Watt。使用图 8.15 中的学校数据库的 ERD 回答问题 7 到 10。
识别 ERD 中的所有核心和从属和特征实体。
哪些表有助于弱关系？强关系？
查看图 8.15 中的学校数据库中的每个表，哪个属性可能具有 NULL 值？为什么？
哪些表是由于多对多关系而创建的？

另请参见 *附录 B：样本 ERD 练习*

归属

这章 *数据库设计*（包括图像，除非另有说明）是 Nguyen Kim Anh 创作的 *使用实体关系模型的数据建模* 的衍生作品，授权协议为知识共享署名许可证 3.0 版

以下内容由 Adrienne Watt 撰写

空值部分和示例
关键词
练习

参考文献

BCOpenCampus：数据库设计

← 关系数据模型

数据库设计

完整性规则和约束 →