关系模型与数据库完整性及规范化知识解析

### 关系模型与数据库完整性及规范化知识解析 #### 1. 关系数据库模型基础概念 关系数据库模型基于一系列基础概念构建，这些概念是理解和设计数据库的基石。 - **核心概念**：包括实体、实体集、关系、联系、元组、候选键、主键、备用键、索引、外键、域、基数和度等。 - **域的定义**：域是一个命名的标量值集合，属性值从中选取。例如，员工的性别属性值只能从“男”“女”这个域中选取。 - **关系的构成**：关系由表头和表体组成。表头包含在特定域上定义的原子属性，表体由一组属性 - 值对构成，每个属性的值都来自其对应的域。 在数据库系统中，常见的关系类型有多种，如下表所示： | 关系类型 | 说明 | | ---- | ---- | | 基本关系 | 数据库中实际存储数据的关系 | | 逻辑视图 | 基于基本关系的虚拟表，不实际存储数据 | | 快照 | 某一时刻数据库的副本 | | 查询结果 | 执行查询操作后得到的结果集 | | 中间结果 | 在复杂查询过程中产生的临时结果 | | 临时关系 | 临时创建和使用的关系 | 关系数据库系统（RDBS）是一组随时间变化的规范化关系的集合，通过合适的用户界面进行管理，并具备增强数据库有效、高效管理的约束和特性。 联系是涉及两个或多个关系的内在映射，主要有六种类型：一对一（1:1）联系、一对多（1:M）联系、多对一（M:1）联系、多对多（M:M）联系、组件联系和子类型联系。 实体 - 联系图（ERD）是数据库模型的图形化表示，掌握在 ERD 上表示关系/实体和联系的方法非常重要。同时，在实际数据库设计中，了解如何实现各种类型的联系也必不可少。关系 - 属性列表（RAL）和联系列表（RL）是 ERD 的有用替代或补充，尤其适用于大型、复杂的系统。在规划数据库时，建议从一开始就使用唯一的属性名，方便在整个系统中跟踪数据。 下面是关系数据库模型构建的简单 mermaid 流程图： ```mermaid graph LR A[确定核心概念] --> B[定义域] B --> C[构建关系] C --> D[确定关系类型] D --> E[设计联系] E --> F[绘制 ERD] F --> G[使用 RAL 和 RL 补充] ``` #### 2. 数据库完整性规则 数据库设计者必须了解两个基本的完整性规则：实体完整性规则和参照完整性规则。 - **实体完整性规则**：基本关系中主键的任何组成部分都不允许接受空值。这意味着在关系模型中，我们不会记录无法识别的事物的信息。需要注意的是，该规则仅适用于基本关系和主键，且主键必须完全非空。如果主键是单个属性，关系中的任何元组该属性都不能为空；如果是复合主键，组成该复合主键的任何属性都不能为空。同时，选择复合主键时要确保选择正确的属性，选择过少会使主键失去区分元组的唯一性，选择过多则会使主键冗余并增加数据库开销。 - **参照完整性规则**：数据库中不能包含不匹配的外键值。不匹配的外键值指的是在被引用（目标）关系中没有匹配项的非空外键值。也就是说，如果 B 引用 A，那么 A 必须存在。需要注意的是，该规则要求外键必须与主键匹配，而不是备用键，并且外键和参照完整性是相互定义的，解释其中一个必然会涉及另一个。 #### 3. 外键概念 外键是关系数据库中连接不同关系的重要元素。属性 FK 是基本关系 R2 的外键，当且仅当它满足以下条件： - 每个 FK 的值要么完全为空，要么完全非空。 - 存在一个基本关系 R1，其主键为 PK，使得 FK 的每个非空值都与 R1 中某个元组的 PK 值相同。 基于上述定义，还有以下几点需要注意： 1. 外键和被引用的主键必须定义在相同的域上，但属性名可以不同。 2. 外键不一定是宿主关系主键的组成部分，在这种情况下可以接受空值，但后续需要更新。例如，员工关系通过多对一联系引用部门关系，可能存在暂时未分配部门的员工。 - `Department {Dept#, DeptName, ...} PK[Dept#]` - `Employee {Emp#, Emp_FName, Emp_LName, Emp_Dept#, ...} PK[Emp#] FK[Emp_Dept#] references Department.Dept#` 3. 如果关系 Rn, R(n - 1), R(n - 2) ... R1 满足 Rn → R(n - 1) → R(n - 2) →