实体关系数据建模案例|CDGP可参考
数据建模是数据工程中的一个关键过程，涉及创建可视化数据库表示。此流程定义并分析支持组织中业务发展所需的数据需求。存在多种数据建模，例如实体关系（ER）、关系、层次、维度等。在本文中，重点关注 ER 数据建模。在深入研究主题 ER 数据建模之前，让我们先了解一下为什么需要数据建模。
注意：我想强调这两个术语之间的差异：数据模型与数据建模。
数据模型是数据元素及其与现实世界实体属性的关系的蓝图。数据模型分为三种主要类型，每种类型代表不同的抽象级别，并在数据建模过程中服务于不同的目的。
数据建模是创建数据模型以将数据存储在数据库中的过程和技术。此过程涉及识别和定义数据元素及其关系。数据建模的类型包括关系建模、维度建模、面向对象建模、层次建模、网络建模、文档建模（NoSQL）、语义建模和实体关系建模。
我将在整篇文章中交替使用这两个术语。因此，了解其中的细微差别至关重要。
为什么需要数据建模
数据建模是数据库设计的基础，也是确保数据结构和存储符合业务需求和流程的重要步骤。它为构建高效、可靠和可扩展的数据库奠定了基础，这对于组织的顺利运营和发展至关重要。良好的数据模型有助于以连贯和逻辑的方式构建和组织数据。以下是精心设计的数据模型对组织的影响：
提高数据质量。
促进数据检索和高效的数据操作。
指导开发人员和工程师理解和构建系统开发。
增强技术开发人员和业务利益相关者之间的沟通。
随着业务需求的发展，便于适应和扩展。
现在了解了数据建模的意义，回到我们的主题，ER 建模，什么是 ER 建模，我们如何构建它？
1. ER 数据建模的定义
ER 数据建模是一种专注于识别实体及其关系的技术。它广泛用于关系数据库设计。ER 图用于说明数据库的结构，包括实体或表等元素、它们的属性或列以及它们之间的关系。ER 建模基于两个概念：
实体——定义为保存特定数据的表。
关系——定义为实体之间的关联或交互。
以下是在线书店的 ER 图示例：
实体及其属性：
顾客
customer_id（主键）
姓名
电子邮件
密码
地址
2. 书本
book_id（主键）
标题
作者
国际标准书号
价格
类型
3. 订单
order_id（主键）
customer_id（引用客户的外键）
订购日期
总金额
4.订单详情
orderdetails_id（主键）
order_id（外键引用订单）
book_id（外键参考书）
数量
价格
关系：
一个客户可以下多个订单（客户和订单之间是一对多的关系）。
一个订单可以包含多本书（订单和书之间的多对多关系，通过orderdetails实体实现）。
该图说明了一个逻辑模型，是设计书店数据库的蓝图，确保有组织的数据存储和针对不同操作（如客户管理、订单处理和库存跟踪）的高效数据检索。
数据建模涉及创建表示数据对象及其在数据库或系统内的关系的图表或模型。模型分为三种类型：
- 概念模型：这些高级模型概述了需要哪些数据以及如何组织数据，而无需深入研究技术细节。
- 逻辑模型：这些模型提供更多细节，显示数据及其结构之间的关系，通常独立于特定技术。满足数据库设计的需要还有待考虑。
- 物理模型：这些是最详细的并且特定于特定的数据库管理系统，详细说明了数据如何存储在数据库中。物理 ERD 代表数据库的实际设计。
2. 实体——属性——键
从上面的在线书店示例中，可以看到实体、属性和键（主键和外键）等术语。
2.1. 实体
实体是现实世界中独立于其他对象而存在的对象。实体的示例：
有形存在的物体（例如，雇员、学生、自行车）。
具有概念存在的对象（例如，课程、部门、角色）。
每个实体都有描述它的特定“属性”。例如，一个 STUDENT 实体由学生的姓名、年龄、地址、注册的课程等定义（例如，一个名叫 小王 的学生，22 岁，住在北京，注册了数据科学课程等）。
在大多数情况下，我们使用实体类型。
那么，什么是实体类型？实体类型是具有相同属性的实体的集合，这些属性称为“实体集”。
下图显示了 STUDENT 实体类型以及该类型的一些属性的列表。
请注意，实体类型在 ER 图中表示为包含实体类型名称的矩形框。我将在本文后面的 ER 图中提供一个示例。
2.2. 属性
正如我之前提到的，每个实体都由一组属性来描述。看看下图：
在 ER 图中，每个属性都由一个内部有名称的椭圆形表示。
属性有四种类型：
单值属性：不能进一步分解或划分的属性。例如，姓名和年龄。
复合属性：属性可以分为独立的更小的部分。例如，地址属性可以包括街道号码、公寓/套房号码、城市、省和国家。
多值属性：每个实体的一组值。例如，学生 A 加入了一个俱乐部，学生 B 没有加入任何俱乐部，学生 C 是两个或多个俱乐部的成员。因此，不同的学生可以有不同数量的俱乐部属性值。
派生属性：包含从其他属性计算得出的值的属性。例如，学生有“成绩”属性，GPA 可以从“成绩”属性导出，因为 GPA 是根据学生每学期获得的成绩计算的。
2.3. 键
键或键属性是对实体类型的实体的重要约束。实体类型通常具有一个或多个属性，这些属性的值对于实体集中的每个实体都是唯一的。这样的属性称为键属性。例如，STUDENT 实体类型中的典型键属性是学生 ID。
为属性赋予键意味着设置一个约束，禁止任何两个实体同时具有相同的键属性值。我们将此属性称为“主键”。
下图显示了键的示例：
在 ER 图中，每个键属性的名称在椭圆形内都带有下划线。
但是如果单个属性不够唯一怎么办？—我们将两个或多个属性组合起来形成一个独特的集合。
让我们以 ENROLLMENT 实体类型为例，该实体类型跟踪哪些学生注册了哪些课程。实体集包括：
Student_id：学生的唯一标识符。
course_id：课程的唯一标识符。
Registration_date：学生注册课程的日期。
成绩：学生在课程中获得的成绩。
在这种情况下，student_id 和 course_id 都无法唯一标识 ENROLLMENT 表中的一行，因为一个学生可以注册多个课程，并且一个课程可以有多个学生。因此，我们将 Student_id 与 course_id 组合起来，形成我们所说的复合键 (student_id, course_id)。该组合键确保学生和课程的每个组合在 ENROLLMENT 表中都是唯一的。
如果它仍然让您感到困惑，那么它的工作原理如下：
Student_id 为 123 的学生可以注册 course_id 为 456 和 789 的课程。这些注册中的每一个都将是 ENROLLMENT 表中的单独行。仅靠 Student_id 并不能使注册变得唯一。
course_id 456 的课程可以与多个学生关联：student_id 123、124、125，并且每个学生作为单独的行。仅 course_id 不足以使注册唯一。
复合键的概念确保每个记录都是唯一的，而单个键是不够的。它们有助于表示实体之间的多对多关系，并通过防止相同键属性组合的重复条目来帮助维护数据完整性。
3. 关系类型
3.1. 关系类型和关系集
关系是两个实体之间的关联，例如，实体 STUDENT ENROLLS_IN COURSE 是另一个实体。与实体类型和实体集的情况类似，关系中也有关系类型及其对应的关系集。在 STUDENT_COURSE 示例中，ENROLLS_IN 是关系类型。由于不同的学生可以注册不同的课程，因此两个实体之间相似关联的集合称为关系集。让我们看一下下面的图：
ER 图中的关系类型显示为连接两个实体类型的菱形框。
3.2. 关系类型的程度
关系类型的程度可以通过映射基数和参与度来表示。
映射基数描述了给定实体可以通过关系类型关联的最大实体数。两个实体类型之间关系类型的基数为一对一 (1:1)、一对多 (1:N) 和多对多 (M:N)。
参与根据实体通过关系类型与另一个实体的关系来指定实体的存在。参与约束有两种类型：完全参与和部分参与。
完全参与指定实体集中的每个实体必须参与关系集中的至少一个关系。实体类型和关系类型之间的双线说明了总体参与。
部分参与指定实体集中的每个实体可以参与也可以不参与关系集中的关系。部分参与使用实体类型和关系类型之间的单线表示。
4. 案例研究
我在下面展示的案例研究是公司、机构等基本设置的简单示例；因此，这些数据库距离适合大型组织的数据库还有很长的路要走。这些案例研究旨在说明本文的主题、ER 建模以及如何构建逻辑模型。
4.1. MountGame 数据库
MountGame 是一家游戏公司，其数据库存储有关员工、部门以及所从事项目（完成项目后的进度和结果）的信息。考虑以下要求：
实体：
• 员工实体。
• 部门实体。
• 项目实体。
属性：
• 员工有名字、姓氏、员工标识符、出生日期以及加入公司的日期。
• 部门有名称、标识符和位置。
• 项目有名称、项目标识符、截止日期和项目经理。
关系：
公司内设有一个或多个部门。
一个部门管理一个或多个项目。
并非每个员工都参与一个项目。
可能有一个项目没有分配任何人。
当员工加入项目时，进度就会被记录下来。有关他们开始项目的日期、完成项目的日期以及是否满足截止日期的信息都会被记录下来。
我们针对这样的需求设计ER图：
EMPLOYEE 是一个强实体，具有标识符employee_id，它是区分员工之间的主键（多个员工可以具有相同的名称）。
DEPARTMENT是一个强实体，以标识符department_id作为主键来区分部门。
PROJECT仅存在于DEPARTMENT的上下文中，因此它是一个弱实体，其中project_id作为弱键。这意味着 PROJECT 实体使用其project_id 和其所属部门的department_id 进行唯一标识。
员工不必是部门的一部分（例如，临时员工和自由职业人员），并且一个部门可以有多个员工，因此 EMPLOYEE 实体部分参与与 DEPARTMENT 实体的多对一 JOINS 关系。
并非每个员工都在一个项目上工作（例如，行政人员），并且一个员工可以在多个项目上工作，因此 EMPLOYEE 实体部分参与与 PROJECT 的多对多 WORKS_ON 关系。项目可以在没有员工的情况下存在，因此它部分地参与了这种关系。
作为一个弱实体，PROJECT 完全参与与其所属的 DEPARTMENT 的多对一识别关系。
EMPLOYEE 和 PROJECT 通过多对多 SUBMITS 关系类型关联；项目可以在没有任何员工的情况下存在，并且员工可以在不提交任何提交的情况下参与项目，因此参与不是完全的。
当员工提交项目时，需要属性来捕获提交的日期和时间以及提交是否按时。
最终的 ER 图如下：
基于上面的 ER 图，我们可以构建一个逻辑模型和/或物理模型，该模型更加详细，并为所讨论的特定领域提供更广泛的视角。
4.2. JetPink 数据库
JetPink 是一家航空公司，首席执行官希望建立一个数据库来存储有关航空公司机队、航班和乘客的数据。考虑以下要求：
实体：
飞机实体
乘客实体
飞行实体
属性：
一架飞机具有唯一的注册号、型号和容量。
航班具有唯一的航班号、出发机场、目的地机场、出发日期和时间以及到达日期和时间。
乘客有名字、姓氏、标识符和电子邮件地址。
关系：
该航空公司拥有一架或多架飞机。
特定航班一次仅由一架飞机执行。
一名乘客与航班上的一个座位相关联。
让我们设计一个 ER 图来说明上述需求：
一架AIRPLANE由其registration_num唯一标识；这是我们的主键。一架飞机可以搭载一名或多名乘客。
航班由其航班 ID 明确标识，因此航班 ID 是主键。出发和目的地属性被捕获为“从”和“到”，并且还记录出发和到达日期和时间。
PASSENGER 实体由 Passenger_id 唯一标识。
一架飞机可以承载一个或多个航班，而每个航班由一架飞机承载，因此AIRPLANE和FLIGHT实体之间的FLIES关系类型的基数为1:N；由于没有飞机就无法进行航班，因此 FLIGHT 实体完全参与这种关系。
一名乘客可以预订多个航班，并且许多乘客可以预订一个航班。关系类型 BOOKS 是 PASSENGER 和 FLIGHT 实体之间的多对多关系。
航班可以没有乘客；因此，它部分参与 BOOKS 关系类型。
最终的 ER 图如下：
5. 数据建模的最佳实践
了解业务需求：强调理解业务需求及其如何影响数据模型的重要性。
简单和清晰：讨论保持数据模型简单而有效，避免不必要的复杂性。
设计的一致性：解释模型中命名约定、数据类型和结构的一致性的必要性。
规范化与反规范化：深入研究何时规范化数据以减少冗余以及何时反规范化适合性能优化。
可扩展性和灵活性：涵盖设计可随着不断变化的业务需求而扩展和发展的数据模型。
六，结论
本文将理论与实践和现实例子相结合。我希望它可以帮助新手和经验丰富的数据工程师更好地理解数据建模基础知识，特别关注 ER 建模、各种类型的数据模型以及 ER 数据建模中最有效的方法。
本文来自微信公众号“数据驱动智能”（ID：Data_0101），作者：晓晓，36氪经授权发布。
