Lec 2数据建模——关系模型、ER 图与键
Lec 2 数据建模——关系模型、ER 图与键（Data Modeling）
对应 MIT CTL.SC4x · Supply Chain Technology and Systems · 第 2 讲
核心参考：SC4x Key Concept Document (Summer 2019) & MITx MicroMasters SCM 课程大纲
TL;DR
- 数据建模是将现实业务实体及其关联转化为规范化数据库物理模式的核心桥梁。
- 关系模型以一阶谓词逻辑为基础，通过二维表（关系）、元组（行）与属性（列）组织结构化数据。
- 主键确保实体唯一性，外键与基数约束（1:1、1:N、M:N）确保跨业务表引用完整性。
联结表解耦与多对多陷阱
在供应链核心业务流程中，“多对多（M:N）”关系无处不在——如一张采购订单可包含多个物料 SKU，而一个物料又会出现在多个订单中。初学者常犯的错误是在单表中堆叠冗余字段，这会引发更新异常与数据不一致。工程实践中必须通过联结表（Junction Table / Associative Entity）将其拆解为两个一对多关系，保证关系模式满足第三范式（3NF）。
1. 数据建模在整个流程中的位置
Lec1 讲了"数据洪流"和 CRISP-DM 的宏观流程；本讲进入数据库设计的第一步——数据建模（Data Modeling）。
数据建模是把一个**逻辑模型（logical model）转化为物理模式（physical schema）**的过程——即先想清楚"数据应该长什么样、彼此如何关联"，再把它落地成真正可以建库的结构。一个完整的数据模型包含四个组成部分：
- 实体与属性（entities and attributes）
- 主键（primary keys）
- 外键（foreign keys）
- 关系与基数（relationships and cardinality）
2. 关系模型（Relational Model）
关系模型是一种管理数据的方法，核心思想是所有数据都被组织成"关系"（relation，即表）。它由 Edgar F. Codd 于 1969 年基于**一阶谓词逻辑（first-order predicate logic）提出：所有数据都以元组（tuple）**的形式表示，元组被归类到不同的"关系"中。
2.1 核心术语对照表
| 术语 | 含义 | 类比电子表格 |
|---|---|---|
| Entity（实体） | 对象、概念或事件 | —— |
| Attribute（属性/列） | 实体的一个特征 | 列（column） |
| Record / Tuple（记录/元组，行） | 某一个具体实体实例的属性取值集合 | 行（row） |
| Entry（条目） | 某记录在某属性上的具体取值 | 单元格 |
| Table（表） | 记录的集合 | 一张 sheet |
| Database（数据库） | 表的集合 | 一个工作簿（workbook） |
单张关系表看起来很像一张电子表格，但术语不同：不再说"行/列"，而说"记录（record/tuple）"和"属性（attribute）"。
2.2 表与属性的命名规范
- 表代表实体，通常用复数名词命名，且不带空格：如
Companies、Customers、Vehicles、Orders。 - 属性是实体的特征，通常是名词。写法惯例：
表名(属性1, 属性2, ..., 属性N)，例如：Vehicles (VIN, Color, Make, Model, Mileage)
实体类型 vs 实体实例：Entity Type 是我们想要建模和存储的某一类对象（如"车辆"这个类别）；Entity Occurrence 是属于该实体类型的、可唯一标识的某一个具体对象（如某一辆具体的车）。
3. 数据模型的设计步骤与规则
3.1 设计步骤
- 建立一个数据模型，描述数据库中有哪些数据、以及如何访问它；
- 定义数据库中的表与属性——数据中每一个重要的概念/名词都对应数据库里的一张表。
数据模型的作用：用标准化的方式描述每个表中的实体，让用户能够对存储的数据施加规则、约束和关系，同时帮助理解业务规则、处理和分析数据。
3.2 关系数据模型的规则
- 数据模型是构建数据库的"设计图纸"（schematic）；
- 每个属性（列）在表内名称唯一；
- 属性下所有条目都必须是该属性的合法取值示例；
- 一个好的数据库中，每条记录（行）都应唯一；
- 记录和属性的排列顺序不重要（关系模型本质是集合，不是有序列表）。
3.3 什么是"好"的数据模型
一个好的关系数据模型应当：
- 完整——包含所有必要数据；
- 无冗余；
- 能有效落实业务规则；
- 可复用，适配不同应用场景；
- 灵活，能应对业务规则或数据需求的变化。
4. 关系与基数（Relationships and Cardinality）
一句话公式：关系 + 基数 = 业务规则（Relationships + Cardinality = Business Rules）
理解数据，离不开理解数据之间如何关联、属性的唯一性程度如何。实体类型的定义过程本身就有助于文档化和确定业务规则。
4.1 ER 图（Entity-Relationship Diagram）
ERD 是对一个信息系统的图形化表示，用来可视化系统内各实体之间的关系，本质上是数据库的"示意图（schematic）"。绘制规则：
- 实体画成方框（boxes）；
- 实体间的关系用连接实体的线表示；
- 基数（cardinality）描述关系中两个实体之间"预期存在多少关联实例"，用 crow's foot（乌鸦脚）记号法表示，同时标注该关系是必须（Mandatory）还是可选（Optional）。
4.2 域校验实体（Domain Validation Entities）
也叫"选择列表（pick lists）"或"校验列表（validation lists）"。这类实体用于标准化数据库中的数据：它们本身是只有单一属性的表，专门用来约束相关表中某属性只能取一组指定的值——相当于给某一列设一个"合法值白名单"。
5. 键（Keys）
| 键类型 | 定义 |
|---|---|
| 主键（Primary Key） | 一个或多个属性，能唯一标识一条记录 |
| 外键（Foreign Key） | 独立（父）实体的主键，作为非键属性存放在依赖（子）实体中，用来表示子实体的记录与父实体记录的关联关系 |
| 复合键（Composite Key） | 由多个属性共同构成的主键。例：包机航班（charter airline），每趟航班有不同编号，需要多个属性联合才能唯一标识 |
5.1 多对多关系（Many-to-Many）
当父实体在另一张表中对应多个子实体类型时，就产生了多对多关系。经典例子：一辆车可以被多个司机驾驶，一个司机也可以驾驶多辆车。
解决方式：引入一张关联表（associative entity），也叫联结表（junction table）——父表的主键被用作子表主键的一部分，从而把多对多关系拆解为两个一对多关系。
5.2 参照完整性（Referential Integrity）
当父表中的主键发生变化时，参照完整性用来维护外键的有效性——每一个外键要么匹配某个主键，要么为 NULL。
级联规则（Cascade rules），即删除操作时的两种可选策略：
- Cascade Restrict：如果主键表中的某行在外键表中还有对应记录，则不允许删除该行，除非先删除所有关联记录；
- Cascade Delete：删除主键表中的某行时，外键表中所有关联记录会一并被自动删除。
6. 本讲小结与学习目标回顾
- 数据模型描述了数据库中存储了什么数据、以及如何访问这些数据；
- 数据模型帮助用户理解业务规则，从而有效地处理和分析数据；
- 业务规则是通过"关系 + 基数"施加在数据库上的；
- 同一份数据集，随着业务逻辑演变，数据模型也可能随之调整；
- 数据建模过程往往会暴露数据中原有的不一致或错误，这些问题必须在导入数据库前修正；
- 从一份扁平文件（flat file）中挑选出合适的实体与属性，并不总是显而易见的，需要反复推敲。
下一讲（Lec 3）：模型设计好之后，就要落地成真正的数据库——进入 SQL 基础：数据类型、建库建表与 SELECT 查询。