数据库系统

数据库模式⭐

三级模式结构与两级映射关系

三级模式

外模式
- 对应 “用户级数据库”，体现为用户视图。用户通过外模式（如应用程序或工具）访问数据库，仅看到所需数据部分，保障数据安全性与个性化需求。
概念模式
- 对应 “概念级数据库”，是 DBA（数据库管理员）视角的全局逻辑结构，描述数据库整体数据模型、数据关系与约束，不涉及物理存储细节，是数据库的核心逻辑层。
内模式
- 对应 “物理级数据库”，体现为内部视图，描述数据在物理存储介质（如磁盘）中的组织方式、存储结构（如文件、索引），与操作系统直接交互，关注数据物理存储优化。

两级映射

外模式 - 概念模式映射
- 建立外模式与概念模式的关联，定义用户视角数据与全局逻辑数据的转换关系。
- 当概念模式调整时，只需修改映射，不影响外模式，实现逻辑独立性。
概念模式 - 内模式映射
- 连接概念模式与内模式，定义全局逻辑结构与物理存储的转换规则。
- 若物理存储方式改变（如更换存储设备），修改此映射即可，不影响概念模式，实现物理独立性。

通过三级模式与两级映射，数据库实现了数据逻辑结构、用户视图、物理存储的分离，提升了数据管理的灵活性、独立性与可维护性。

关系表的 3 种类型

基本关系（基本表 / 基表）
- 是实际存在的表，用于逻辑化表示实际存储的数据，是数据库中数据存储的基础实体，直接对应物理存储的数据表。
查询表
- 指数据库执行查询操作后，结果所对应的表。它是查询操作的临时输出形态，呈现查询筛选、处理后的数据集合。
视图表
- 又称 “虚表”，由基表或其他视图表导出，本身不独立存储数据。数据库仅存储其定义（如查询逻辑），使用时动态生成数据，主要用于简化复杂查询或控制数据访问权限。

通过这三类关系表，数据库实现了数据存储、查询处理和逻辑抽象的不同功能，提升了数据管理的灵活性与安全性。

数据库视图、视图优点及物化视图的概念，具体内容如下：

数据库视图

定义：数据库视图是一种 “虚拟表”（逻辑层面的表），其内容通过查询定义，仅保存 SQL 查询语句，不真实存储数据。使用时，通过查询原始表动态生成数据，具备表的形式（包含列名、行数据）。

视图的优点

简化用户操作：将复杂查询封装为视图，用户直接调用视图即可获取结果，降低使用复杂度。
多角度呈现数据：同一原始数据可定义多个视图，满足不同用户对数据的个性化需求。
逻辑独立性：数据库结构重构时（如基表调整），若视图定义不变，应用程序无需修改，保障逻辑独立性。
数据安全保护：通过视图限制用户对基表数据的访问范围，隐藏机密数据，提升安全性。

物化视图

定义：区别于传统虚拟视图，物化视图是 “实体化视图”，会实际存储数据。
当原始表数据更新时，物化视图也会同步更新，兼具虚拟视图的逻辑抽象与数据存储的实体化特性。
适用于多查询少更新

分布式数据库⭐⭐⭐

分布式数据库的核心特点

除传统数据库的逻辑独立性（逻辑结构变化不影响应用）和物理独立性（物理存储变化不影响逻辑）外，新增分布独立性（分布透明性）。
用户无需关注数据在物理节点的分布细节，操作如同使用集中式数据库。

集中与自治共享结合的控制结构

局部自治：各节点的局部数据库管理系统（DBMS）可独立管理本地数据，具备自治处理能力。
集中控制：系统设置全局协调机制，统一管理跨节点的操作，执行全局应用，平衡局部自主与全局协同。

适当增加数据冗余度

在不同物理节点存储同一数据的多个副本，通过冗余实现：

可靠性提升：应对节点故障，保障数据持续可用。
性能优化：就近读取副本，减少跨节点访问开销。
可用性保障：某节点故障时，其他副本仍可支撑业务，确保数据完备。

全局的一致性、可串行性和可恢复性

分布式环境下，需保证跨节点事务的一致性（数据状态统一）、可串行性（并发事务执行效果等同于串行）及可恢复性（故障后系统能恢复到正确状态），确保分布式事务处理的正确性。

分布式数据库的模式结构

全局模式层（分布式数据库新增部分）

全局外模式
- 面向用户或应用程序，定义全局视角下的用户视图，是用户操作分布式数据库的接口。
全局概念模式
- 描述分布式数据库的全局逻辑结构，定义数据的整体逻辑模型，不涉及数据分布细节。
分片模式
- 定义数据的分片规则，即全局数据如何分割为逻辑片段（分片），解决 “数据如何拆分” 的问题。
分布模式
- 规定分片数据在物理节点上的分布位置，明确每个数据分片存储的具体场地，实现数据分布的物理映射。

局部模式层（基于集中式数据库扩展）

局部概念模式
- 对应局部数据库的逻辑结构，描述局部节点上数据的逻辑组织，与全局模式协调。
局部内模式
- 定义局部数据的物理存储结构（如文件、索引等），负责局部数据的物理存储与访问优化。

映射关系（映像）

映像 1：全局外模式与全局概念模式的映射，保障用户视角与全局逻辑的转换。
映像 2：全局概念模式与分片模式的映射，关联全局逻辑结构与数据分片规则。
映像 3：分片模式与分布模式的映射，确定数据分片的物理分布。
映像 4：分布模式与局部概念模式的映射，将全局分布数据关联到局部逻辑结构，最终通过局部内模式实现物理存储。

通过这种分层架构与多级映射，分布式数据库实现了数据分布透明性、逻辑独立性和物理独立性，协调全局管理与局部自治的关系。

分布式数据库管理系统（DDBMS）的组成与结构

分布式数据库管理系统 - 组成

局部数据库管理系统（LDBMS）
- 负责管理局部节点的数据库，处理本地数据的存储、查询、更新等操作，保障局部数据的自治性。
全局数据库管理系统（GDBMS）
- 从全局视角协调分布式数据库，管理跨节点的事务、数据分布策略，执行全局范围内的数据操作。
全局数据字典
- 存储分布式数据库的元数据（如数据分片规则、分布位置、全局模式定义等），为 GDBMS 和 LDBMS 提供数据描述信息。
通信管理（CM）
- 负责分布式节点间的通信协调，确保数据在不同节点间的传输、消息交互，支持分布式事务的通信需求。

分布式数据库管理系统 - 结构

全局控制集中的 DDBMS
- 全局控制逻辑集中在一个节点，统一管理分布式系统的全局事务、数据分布等，适合对集中协调需求高的场景。
全局控制分散的 DDBMS
- 全局控制功能分散到多个节点，各节点协同完成全局管理，提升系统的分布式处理能力与容错性。
全局控制部分分散的 DDBMS
- 结合集中与分散的特点，部分全局控制功能集中管理，部分分散到节点，平衡集中管理与分布式自治的需求。

分布透明性

分布透明性的核心分类

分片透明性
- 定义：用户无需关心数据的分片方式，对数据的操作基于全局关系进行，分片逻辑对用户不可见。
- 分片类型：包括水平分片（按行划分数据）、垂直分片（按列划分数据）、混合分片（结合水平与垂直分片）。
位置透明性
- 定义：用户不必知晓数据存储的具体物理位置，即数据分配到哪些站点存储对用户透明。
局部数据模型透明性（局部映像透明性 / 逻辑透明）
- 定义：最低层次的透明性，用户无需关注局部数据库管理系统（DBMS）支持的数据模型、操纵语言，系统自动完成数据模型与语言的转换，对异构型或同构异质的分布式数据库系统至关重要。

延伸概念：复制透明性

用户无需关心数据库在网络节点的复制情况，数据更新由系统自动处理，确保复制数据的一致性。

两阶段提交协议（2PC）

2PC 事务提交的两个阶段

表决阶段
- 目标：协调者收集各参与者对事务的处理意见，形成全局统一的决定（提交或撤销事务）。
执行阶段
- 目标：根据表决阶段协调者做出的决定，执行最终操作（如全局提交或撤销事务），确保分布式事务的一致性。

两条全局提交规则

全局撤销规则
- 只要有一个参与者提出撤销事务的请求，协调者必须做出全局撤销事务的决定，避免部分节点执行不一致的操作。
全局提交规则
- 仅当所有参与者均同意提交事务时，协调者才能做出全局提交事务的决定，保证分布式环境下事务的原子性（要么全部执行，要么全部不执行）。

数据库设计阶段⭐⭐

数据库设计的标准流程

需求分析
- 目标：收集用户对当前及未来应用的数据需求和数据处理要求。
- 产出：通过数据流图、数据字典、需求说明书，明确系统需要处理的数据及业务逻辑。
概念结构设计
- 目标：构建独立于数据库管理系统（DBMS）的概念模型。
- 方法：以用户视角设计数据模型，常用 ER 模型（实体 - 关系模型）描述数据实体、属性及关系，形成与 DBMS 无关的概念层设计。
逻辑结构设计
- 目标：将概念模型转换为 DBMS 支持的逻辑模型。
- 方法：依据转换规则和规范化理论，把 ER 模型转化为关系模式（如关系数据库的表结构），并定义视图、完整性约束及应用处理规则。
物理设计
- 目标：结合 DBMS 特性、硬件环境、操作系统（OS）特性，确定数据库物理存储结构。
- 内容：设计数据存储方式、索引策略、文件组织等，确保数据库在物理层面高效运行。

整个流程体现了从用户需求抽象到物理实现的系统化设计思路，每一步均以前期成果为基础，逐步细化直至落地。

概念结构设计⭐

概念结构设计的流程、集成方法及冲突处理

概念结构设计流程
1. 需求分析：收集和分析用户需求，为后续设计提供基础。
2. 抽象数据：从需求中提取核心数据，进行抽象化处理。
3. 设计局部 ER 模型：基于抽象数据，设计局部的实体 - 关系（E-R）模型，描述局部数据结构。
4. 合并局部模型，消除冲突：将多个局部 E-R 模型集成，解决集成过程中产生的冲突（如属性、命名、结构冲突）。
5. 重构优化，消除冗余：优化合并后的模型，去除冗余数据或关系，确保模型简洁高效。
6. 逻辑设计：将优化后的概念模型转换为逻辑模型，进入下一设计阶段。
集成方法
- 一次性集成：直接合并多个局部 E-R 图。
- 逐步集成：通过累加方式，每次集成两个局部 E-R 图，逐步完成整体合并。
集成冲突及解决办法
- 属性冲突：
  - 属性域冲突：同一属性在不同模型中数据类型、取值范围不同。
  - 属性取值冲突：同一属性在不同模型中取值规则不一致。
- 命名冲突：
  - 同名异义：相同名称对应不同含义的实体、属性。
  - 异名同义：不同名称对应同一含义的实体、属性。
- 结构冲突：
  - 同一对象在不同应用中抽象方式不同（如实体 vs. 属性）。
  - 同一实体在不同局部 E-R 图中，属性个数、排列顺序不一致。

逻辑结构设计

数据模型

数据模型三要素
- 数据结构：描述数据的组织形式（如实体、属性等）。
- 数据操作：对数据的操作方式（如增、删、改、查）。
- 数据的约束条件：确保数据完整性的规则（如主键约束、取值范围限制）。
数据模型类型
- 层次模型：以树状结构组织数据。
- 网状模型：支持复杂的多对多关系。
- 面向对象模型：基于面向对象思想建模。
- 关系模型（重点标注）：以二维表形式组织数据

完整性约束

实体完整性约束

核心规则：规定基本关系中主属性不能取空值。
逻辑依据：主属性（如主键）用于唯一标识实体，若为空则无法确定具体元组，破坏数据唯一性。例如 “学生表” 中学号（主属性）必须有值，不能空缺。

参照完整性约束

核心规则：关系间引用时，外键取值需满足两种情况：
- 引用其他关系的主键值（确保数据关联有效）；
- 允许取空值（若外键无实际关联需求）。
作用：维护关系模型中表间关联的正确性，避免无效引用。

用户自定义完整性约束

核心规则：根据具体应用环境定义约束条件。
示例：如规定 “年龄” 属性必须大于 0，或 “成绩” 在 0-100 范围内，由业务需求决定约束内容。

触发器：它是实现完整性约束的一种机制，通过定义触发条件和执行动作，自动维护数据约束（如数据插入、更新时检查规则）。

流程及核心内容

逻辑结构设计流程

概念设计→转化为数据模型：
- 将概念设计阶段的 E-R 图转换为关系模型，包括：
  - 实体向关系模式的转换：每个实体对应一个关系模式，实体属性转为关系属性，实体主键确定关系主键。
  - 联系向关系模式的转换：根据联系类型（一对一、一对多、多对多），将联系转换为独立关系模式或合并到相关实体的关系中。
关系规范化：通过范式（如 1NF、2NF、3NF 等）消除数据冗余、更新异常等问题，优化关系模式结构。
模式优化：进一步调整关系模式，提升存储效率与操作性能。
设计用户子模式：根据不同用户需求，设计个性化的视图（子模式），简化用户对数据的访问。
衔接物理设计：逻辑结构设计完成后，进入物理设计阶段，关注数据存储结构与访问方式。

核心内容补充

E-R 图向关系模式的转换：明确实体与联系的转换规则，是逻辑设计的基础。
关系模式的规范化：通过规范化理论确保数据完整性与一致性。
确定完整性约束：定义实体完整性、参照完整性、用户自定义完整性，保证数据正确性。
用户视图的确定：提高安全性与独立性
- 根据数据流图确定处理过程所需视图，
- 按用户类别划分不同视图，控制数据访问范围。
应用程序设计：关联逻辑结构与应用功能实现。

E-R 图向关系模式转换

实体型转换规则

核心原则：一个实体型必须转换为一个关系模式。
操作：实体的属性直接作为关系模式的属性，实体的主键确定关系模式的主键。

联系转换规则（按联系类型划分）

一对一联系：
- 独立关系模式：引入两端实体的主键及联系自身属性，主键可选任一端实体的主键。
- 归并到一端实体：将另一端实体的主键和联系属性并入某一端实体的关系模式，主键保持原实体主键不变。
一对多联系：
- 独立关系模式：包含两端实体主键及联系属性，主键设为多端实体的主键。
- 归并到多端实体：将一端实体的主键和联系属性并入多端实体的关系模式，主键沿用多端实体原主键。
多对多联系：
- 唯一方式：独立关系模式：必须单独创建关系模式，包含两端实体主键及联系属性，主键为两端主键的组合键（复合主键）。

关系代数⭐⭐⭐⭐

关系代数操作

关系基本概念

属性列（目）：关系表中的列
元组（行 / 记录）：关系表中的行

关系代数操作及实例

并（∪）：
- 定义：合并两个关系中所有不重复元组。
- 示例： $S1 \cup S2$ 的结果包含 S1 和 S2 的所有元组（如 No0001、No0003 等）。
交（∩）：
- 定义：取两个关系中相同的元组。
- 示例： $S1 \cap S2$ 仅保留 S1 与 S2 共有的元组（如 No0001）。
差（-）：
- 定义：保留在第一个关系中存在，但在第二个关系中不存在的元组。
- 示例： $S1 - S2$ 结果为 S1 有而 S2 没有的元组（如 No0003、No0004）。
笛卡尔积（×）
- 定义：两个关系的笛卡尔积是它们元组的所有可能组合。
- 示例： $S1 \times S2$ 的结果包含 S1 与 S2 的全部元组组合。原 S1 有 3 个元组，S2 有 3 个元组，笛卡尔积生成 $3 \times 3 = 9$ 个元组，属性列合并（重复属性保留），呈现所有可能的元组配对。
投影（π）
- 定义：从关系中选取指定属性列，生成新关系。
- 示例： $\pi_{Sno, Sname}(S1)$ 表示从 S1 中选取 “Sno” 和 “Sname” 列，结果只保留这两列数据（如 No0001-Mary、No0003-Candy 等），去除无关属性（如 Sdept）。
选择（σ）
- 定义：按条件筛选关系中的元组。
- 示例： $\sigma_{Sno=No0003}(S1)$ 表示筛选 S1 中 Sno 为 “No0003” 的元组，最终结果仅包含 Sno=No0003、Sname=Candy、Sdept=IS 这一条元组，实现数据的条件过滤。
自然连接（ $\text{S1} \bowtie \text{S2}$ ），通过等值匹配合并两表，保留有用属性。

[!TIP]

在关系代数优化中，尽早执行选择操作以减少参与运算的数据量是关键原则

规范化理论⭐⭐⭐⭐⭐

非规范化关系模式的常见问题

数据冗余：同一数据在关系中重复存储。例如，学生的姓名、班级等信息在多个记录中重复出现，浪费存储空间。
更新异常：修改数据时因冗余导致部分数据未同步更新，破坏一致性。如修改学生所在班级，若未更新所有相关记录，会出现同一学生班级信息不一致的情况。
插入异常：因关系模式设计不合理，导致本应插入的数据无法正常插入。例如，若规定 “选课表中必须同时有学生和课程信息”，但新增学生还未选课时，因缺少课程信息而无法插入学生记录。
删除异常：删除操作误删有用数据。例如，删除某门课程的选课记录时，若课程与学生信息绑定不合理，可能连带删除学生的其他有效信息。

函数依赖

函数依赖定义

在关系模式 $R(U, F)$ 中（U 为属性集合，F 为函数依赖集合）X 和 Y 是 U 的子集。
对于 R 的任意关系 r，若其中任意两个元组 u、v，只要 $u[X] = v[X]$ （即 X 属性值相等），就有 $u[Y] = v[Y]$ （Y 属性值也相等），则称 X 函数决定 Y，或 Y 函数依赖于 X，记为 $X \rightarrow Y$ 。

键

候选键

定义：能唯一标识关系中每个元组，且无冗余属性的属性集合。
核心作用：确保元组的唯一性，且属性不可再精简。例如，学生表中，若 “学号” 和 “身份证号” 均可唯一标识学生，则二者分别是候选键。

主键

定义：从候选键中任选一个作为主键，用于唯一标识元组。
与候选键的关系：主键是候选键的子集，是人为选定的 “最具代表性” 的候选键。如在学生表中，选择 “学号” 作为主键。

外键

定义：本关系中引用其他关系主键的属性（集）。
作用：建立不同关系间的关联。例如，在 “课程表” 中引入 “学生表” 的主键 “学号”，此时 “学号” 作为课程表的外键，用于关联学生与课程。

主属性与非主属性

主属性：参与组成候选键的属性。
非主属性：不参与组成候选键的属性。

求候选键

有向图表示函数依赖:将关系模式中的函数依赖关系（如 $X \rightarrow Y$ ）用 有向图 可视化：
- 图中每个结点代表一个属性；
- 有向边表示函数依赖方向，例如 $X \rightarrow Y$ 对应从属性 X 指向 Y 的边。
基于入度为 0 的属性集初步判断
- 入度为 0 的属性：指没有其他属性通过函数依赖指向它的属性。
- 以入度为 0 的属性集合为起点，尝试遍历有向图中所有结点：
  - 若能遍历所有结点，则该属性集就是关系模式的 候选键。因为它能通过函数依赖推导出所有属性，满足唯一标识元组且无冗余的条件。
处理复杂情况（补充中间结点）:若入度为 0 的属性集无法遍历所有结点，需进一步操作：
- 尝试将 中间结点（既有入度，也有出度的属性）并入入度为 0 的属性集中；
- 重复验证新集合能否遍历所有结点，直到找到能遍历所有结点的属性集合，该集合即为 候选键。

函数依赖类型

部分函数依赖
- 关系模式与依赖集：
  - 关系模式 R1 包含属性 $A, B, C, D$ ，函数依赖集为 $\{AB \rightarrow D, A \rightarrow C\}$ 。
  - 候选键分析：AB 是候选键（因 AB 可唯一确定 D）。
- 部分函数依赖体现：
  - 属性 C 仅依赖于候选键 AB 的一部分 A（即 $A \rightarrow C$ ），而非整个候选键 AB。这种 “属性依赖于候选键的部分属性” 的依赖关系，即为 部分函数依赖，会导致数据冗余，违反第二范式（2NF）。
传递函数依赖
- 关系模式与依赖集：
  - 关系模式 R2 包含属性 $A, B, C$ ，函数依赖集为 $\{A \rightarrow B, B \rightarrow C\}$ 。
- 传递函数依赖推导：
  - 由 $A \rightarrow B$ 和 $B \rightarrow C$ ，可推导出 $A \rightarrow C$ 。此时，C 不直接依赖于 A，而是通过中间属性 B 间接依赖，形成 传递函数依赖。这种依赖会引发数据更新异常，违反第三范式（3NF）。

Armstrong 公理（函数依赖推理规则）

基本推理规则

自反律（A1）：若 $Y \subseteq X \subseteq U$ $Y \subseteq X \subseteq U$ ，则 $X \rightarrow Y$ $X \to Y$ 成立。
- 示例：若属性集 $X = \{A, B\}$ ， $Y = \{A\}$ ，则 $A,B \rightarrow A$ 必然成立。
增广律（A2）：若 $Z \subseteq U$ $Z \subseteq U$ 且 $X \rightarrow Y$ $X \to Y$ ，则 $XZ \rightarrow YZ$ $XZ \to Y Z$ 成立。
- 示例：已知 $A \rightarrow B$ ，若 $Z = \{C\}$ ，则 $A,C \rightarrow B,C$ 成立。
传递律（A3）：若 $X \rightarrow Y$ $X \to Y$ 且 $Y \rightarrow Z$ $Y \to Z$ ，则 $X \rightarrow Z$ $X \to Z$ 成立。
- 示例：已知 $A \rightarrow B$ ， $B \rightarrow C$ ，可推导出 $A \rightarrow C$ 。

导出推理规则

合并规则：由 $X \rightarrow Y$ $X \to Y$ 、 $X \rightarrow Z$ $X \to Z$ ，可得 $X \rightarrow YZ$ $X \to Y Z$ 。
- 由 $X \rightarrow Y$ ，通过增广律（A2）得 $X \rightarrow XY$ ；
- 由 $X \rightarrow Z$ ，通过增广律（A2）得 $XY \rightarrow YZ$ ；
- 最后通过传递律（A3），由 $X \rightarrow XY$ 和 $XY \rightarrow YZ$ ，推导出 $X \rightarrow YZ$
伪传递规则：由 $X \rightarrow Y$ $X \to Y$ 、 $WY \rightarrow Z$ $WY \to Z$ ，可得 $XW \rightarrow Z$ $X W \to Z$ 。
- 由 $X \rightarrow Y$ ，通过增广律（A2）得 $WX \rightarrow WY$ ；
- 结合已知 $WY \rightarrow Z$ ，通过传递律（A3），推导出 $WX \rightarrow Z$ 。
分解规则：由 $X \rightarrow Y$ $X \to Y$ 且 $Z \subseteq Y$ $Z \subseteq Y$ ，可得 $X \rightarrow Z$ $X \to Z$ 。
- 由 $Z \subseteq Y$ ，通过自反律（A1）得 $Y \rightarrow Z$ ；
- 结合已知 $X \rightarrow Y$ ，通过传递律（A3），推导出 $X \rightarrow Z$ 。

范式判断

属性的分类

简单属性和复合属性：
- 简单属性：不可再细分的原子属性，如 “姓名”“年龄”。
- 复合属性：由多个简单属性组成，可进一步拆分，如 “地址” 可拆分为 “省、市、区”。
单值属性和多值属性：
- 单值属性：一个实体在该属性上只对应一个值，如 “身份证号”。
- 多值属性：一个实体在该属性上对应多个值，如 “联系方式”（可能有多个电话）。
NULL 属性：表示属性值未知、缺失或无意义，用于描述数据缺失状态。
派生属性：通过其他属性计算或推导得出的属性，如 “年龄” 可由 “出生日期” 派生计算得到。

范式优化目标

通过逐步优化关系模式，解决数据库的 插入异常、删除异常、数据冗余 问题。

各范式定义与优化内容

1NF（第一范式）：
- 要求：属性值均为不可再分的原子值（如避免 “姓名 + 电话” 合并存储）。
- 意义：确保数据的基础规范性。不满足无法建表
2NF（第二范式）：
- 要求：在满足 1NF 基础上，消除 非主属性对候选键的部分函数依赖。
- 示例：若候选键为 AB，非主属性 C 仅依赖 A，需拆分关系消除该部分依赖。
3NF（第三范式）：
- 要求：在满足 2NF 基础上，消除 非主属性对候选键的传递函数依赖。
- 示例：若 $A \rightarrow B$ 、 $B \rightarrow C$ ，需拆分关系消除 A 对 C 的传递依赖。B,C都是非主属性
BCNF（巴斯 - 科德范式）：
- 要求：消除 主属性对候选键的部分依赖和传递依赖，进一步约束关系模式的函数依赖。

逻辑关系

范式层级呈递进优化：1NF → 2NF → 3NF → BCNF，每一层级在上一层基础上解决更复杂的数据依赖问题，最终提升数据库结构的合理性。

模式分解

基本定义

在数据库规范化理论中，若关系模式 R 被分解为数据库模式 $\rho = \{R1, R2, \dots, Rk\}$ ，
F 是 R 上的函数依赖集，每个分解后的子模式 Ri 对应函数依赖集 Fi。
当 $\{F1, F2, \dots, Fk\}$ 与原函数依赖集 F 逻辑等价（即相互逻辑蕴含，能推导出彼此的函数依赖）时，称该分解 $\rho$ 保持函数依赖。

举例

例 1
- 原关系模式： $R(A, B, C)$ ，函数依赖集 $F = \{A \to B, B \to C\}$ 。
- 分解结果： $R1(A, B)$ 、 $R2(B, C)$ 。
- 判断过程：
  - R1 上的函数依赖 $F1 = \{A \to B\}$ ，R2 上的函数依赖 $F2 = \{B \to C\}$ 。
  - 合并 $F1 \cup F2 = \{A \to B, B \to C\}$ ，与原 F 完全一致。
- 结论：该分解保持函数依赖。
例 2
- 原关系模式： $R(A, B, C)$ ，函数依赖集 $F = \{A \to B, B \to C, A \to C\}$ 。
- 分解结果： $R1(A, B)$ 、 $R2(B, C)$ 。
- 判断过程：
  - R1 上的函数依赖 $F1 = \{A \to B\}$ ，R2 上的函数依赖 $F2 = \{B \to C\}$ 。
  - 合并 $F1 \cup F2 = \{A \to B, B \to C\}$ ，虽未直接包含 $A \to C$ ，但通过 $A \to B$ 和 $B \to C$ ，可逻辑推导出 $A \to C$ 。因此 $F1 \cup F2$ 与原 F 等价。
- 结论：该分解也保持函数依赖。
例 3
- 原关系模式： $R(A, B, C)$ ，函数依赖集 $F = \{A \to B, B \to C, A \to C\}$ 。
- 分解结果： $R1(A, B)$ 、 $R2(A, C)$ 。
- 判断过程：
  - R1 保留 $A \to B$ ，R2 保留 $A \to C$ ，但原依赖 $B \to C$ 的属性 B 和 C 未共存于同一分解模式中，无法推导 $B \to C$ 。
  - 分解后的函数依赖集 $\{A \to B, A \to C\}$ 与原 F 不等价（缺少 $B \to C$ ）。
- 结论：不保持函数依赖。
例 4
- 原关系模式： $R(A, B, C, D, E)$ ，函数依赖集 $F = \{A \to B, D \to E\}$ 。
- 分解结果： $R1(A, B, C)$ 、 $R2(D, E)$ 。
- 判断过程：
  - R1 保留 $A \to B$ ，R2 保留 $D \to E$ ，原 F 中所有函数依赖均被分解后的子模式保留。
  - 分解后的函数依赖集 $\{A \to B, D \to E\}$ 与原 F 完全一致。
- 结论：保持函数依赖。
核心逻辑：若分解后子模式的函数依赖集能完全覆盖原依赖集（或通过推导等价），则保持函数依赖；若原依赖因分解导致属性分离而无法保留或推导，则不保持。

该分解是 无损分解，分析如下：

分解后的关系模式：
- 成绩（学号，课程号，分数）：保留（学号，课程号）→分数的依赖。
- 学生（学号，姓名）：保留学号→姓名的依赖。
- 课程（课程号，课程名）：保留课程号→课程名的依赖。
还原验证：
- 通过自然连接：
  - 成绩表与学生表以 “学号” 为公共属性连接，获取 “学号、姓名、课程号、分数”。
  - 再与课程表以 “课程号” 为公共属性连接，最终还原出原关系模式的所有属性（学号，姓名，课程号，课程名，分数）。
- 分解后的关系通过自然联接能完全还原原关系模式，未丢失数据，符合无损分解定义。

无损分解

表格法判断无损分解步骤⭐:
- 适用场景：通用型判断方法，通过表格变换验证。
1. 构建初始表
  - 列：原关系模式所有属性 $A_1, A_2, \dots, A_n$ 。
  - 行：对应分解后的每个关系模式 $R_i$ 。若 $R_i$ 包含属性 $A_j$ ，则填 $a_j$ （表示该属性在 $R_i$ 中明确存在）；否则填 $b_{ij}$ （唯一标识的符号）。
2. 根据函数依赖修改表格
- 对每个函数依赖 $X \to Y$ $X \to Y$ ：
  - 找到所有在 X 属性列上取值相同的行。
  - 若这些行在 Y 属性列有 a，则将其他行的 Y 列也改为 a；若无 a，则统一为最小的 b 符号。
- 重复此过程，直到表格无法再修改。
1. 判断结果
  - 若某一行出现 全 a 列，则分解是无损分解；否则为有损分解。
- 示例：原关系模式 $R(A,B,C)$ ，分解为 $R_1(A,B)$ 、 $R_2(B,C)$ ，函数依赖 $B \to C$ 。
  - 初始表：
    
    A B C
    
    $R_1$ $a_1$ $a_2$ $b_{13}$
    
    $R_2$ $b_{21}$ $a_2$ $a_3$
  - 根据 $B \to C$ ， $R_1$ 的 C 列改为 $a_3$ ，最终 $R_1$ 行全 a，判定为无损分解。

	A	B	C
$R_1$	$a_1$	$a_2$	$b_{13}$
$R_2$	$b_{21}$	$a_2$	$a_3$

公式法（定理法）判断无损分解步骤
- 适用场景：当分解中有一个关系模式包含原关系的候选键时使用。
- 求原关系模式的候选键
  - 通过函数依赖集 F，计算属性闭包，找出候选键 K（能决定所有属性的最小属性集）。
- 检查分解结果
  - 若分解后的关系模式中，至少有一个 $R_i$ 包含候选键 K，则分解是无损分解。
- 示例：原关系模式 $R(A,B,C)$ ，函数依赖 $A \to B, A \to C$ ，候选键为 A。
- 若分解为 $R_1(A,B)$ 、 $R_2(A,C)$ ，因 $R_1$ 和 $R_2$ 均包含候选键 A，判定为无损分解。

无损分解定理（双模式分解场景）
- 适用场景：当关系模式 R 分解为 $\rho = \{R_1, R_2\}$ 时，分解具有无损联接性的
- 充要条件 是： $R_1 \cap R_2 \to (R_1 - R_2) \quad \text{或} \quad R_1 \cap R_2 \to (R_2 - R_1)$
  - $R_1 \cap R_2$ ： $R_1$ 与 $R_2$ 的公共属性。
  - $R_1 - R_2$ ： $R_1$ 中去除公共属性后的属性集； $R_2 - R_1$ 同理。
- 含义：若公共属性能函数决定某一模式的非公共属性，则分解无损。
- 示例：
  - 已知条件：
    - 关系模式 $R(ABC)$ ，函数依赖 $F = \{A \to B\}$ 。
    - 分解 $\rho_1 = \{R_1(AB), R_2(AC)\}$ ， $\rho_2 = \{R_1(AB), R_3(BC)\}$ 。
  - 对 $\rho_1$ 的判断：
    - $R_1 \cap R_2 = \{A\}$ ， $R_1 - R_2 = \{B\}$ 。
    - 因 $A \to B$ 在 F 中成立，满足 $R_1 \cap R_2 \to (R_1 - R_2)$ ，故 $\rho_1$ 是无损分解。
  - 对 $\rho_2$ 的判断：
    - $R_1 \cap R_3 = \{B\}$ ，需验证 $B \to A$ 或 $B \to C$ 。
    - 但 F 中无 $B \to A$ 或 $B \to C$ ，不满足定理条件，故 $\rho_2$ 不是无损分解。

并发控制⭐

ACID 特性

原子性（Atomicity）
- 定义：事务是一个不可分割的整体，包含的所有操作 要么全部成功提交，要么全部失败回滚（Rollback），不能部分完成。
- 示例：转账操作中，扣款与到账必须同时成功，若其中一步失败，整个事务回滚，确保数据状态不变。
一致性（Consistency）
- 定义：事务执行前和执行后，数据库需从一个 一致性状态 转换到另一个 一致性状态。即事务需维护数据库的完整性约束（如数据逻辑、业务规则）。
- 示例：转账前后，账户总金额不变，事务保证这一业务规则的一致性。
隔离性（Isolation）
- 定义：多个事务并发执行时，彼此相互隔离。一个事务的操作及使用的数据，对其他并发事务不可见，避免干扰。
- 示例：多个用户同时转账，每个事务的执行不受其他事务影响，如同独占数据库。
持久性（Durability）
- 定义：事务一旦提交（Commit），对数据库的修改是 永久性 的，即使发生故障（如断电、系统崩溃），数据改变也会保留。
- 示例：事务提交后，数据写入磁盘等持久化存储，后续故障不影响已提交的结果。

这四大特性共同确保了数据库在事务处理中的可靠性、正确性和稳定性。

三类典型问题

丢失更新
- 问题描述：多个事务读取同一数据并更新时，后提交的事务覆盖先提交事务的更新，导致先执行的更新丢失。
- 示例：
  - T1：读 (A=10)，执行 (A=A-5)（写回前）。
  - T2：读 (A=10)，执行 (A=A-8) 并写回。最终 T1 的更新被 T2 覆盖，T1 的修改丢失。
不可重复读
- 问题描述：一个事务内两次读取同一数据，结果不一致（因其他事务修改了数据），破坏事务隔离性。
- 示例：
  - T1：首次读 (A=20)、(B=30)，求和 50。
  - T2：读 (A=20)，执行 (A=A+50) 并写回 (A=70)。
  - T1：再次读 (A=70)，求和变为 100，前后结果矛盾，验算失败。
读 “脏” 数据
- 问题描述：事务读取了其他事务未提交的中间数据，若后者回滚，前者读取的数据即为无效的 “脏数据”。
- 示例：
  - T1：读 (A=20)，执行 (A=A+50) 写回 70（未提交）。
  - T2：读取 (A=70)。
  - T1：回滚，A 恢复 20，但 T2 已读取到未提交的 70，即 “脏数据”。

这三类问题均因事务并发执行时缺乏有效隔离控制导致，需通过数据库的并发控制机制（如锁机制、事务隔离级别等）解决。

并发控制的封锁协议

问题与解决方案关联
- 并发问题：明确并发执行事务可能引发 丢失更新、不可重复读、读 “脏” 数据 三类问题。
- 解决方案：通过 封锁协议 解决上述问题，核心是利用锁机制控制事务对数据的访问。
封锁协议核心内容
- 锁类型：
  - S 锁（共享锁）：读操作时加锁，允许多个事务同时获取，实现 “读共享”。
  - X 锁（排他锁）：写操作时加锁，独占数据，其他事务不可读写，实现 “写独占”。
- 各级封锁协议：
  - 一级封锁协议：通过 X 锁防止丢失更新。
  - 二级封锁协议：在一级基础上，增加 S 锁，解决读 “脏” 数据问题。
  - 三级封锁协议：进一步完善，同时处理丢失更新、不可重复读、读 “脏” 数据。
两段锁协议：事务分两个阶段加锁与释放锁，确保并发调度的可串行化，是实现数据一致性的重要协议。
死锁相关
- 封锁协议可能引发死锁（事务相互等待对方释放锁）。
- 后续需处理 死锁预防（如有序加锁）和 死锁解除（如选择回滚代价低的事务）。

X 锁的排他性和一级封锁协议的规则。以下是详细解释：

1. X 锁的排他性本质

X 锁（排他锁）的定义是：一旦事务 T 对数据 R 加了 X 锁，在 T 释放 X 锁之前，其他任何事务都不能对 R 加 S 锁（共享锁）或 X 锁。这意味着：

其他事务无法修改 R（因为无法加 X 锁）；

其他事务也无法读取 R（因为无法加 S 锁）。

但这里有个前提：其他事务必须遵守锁协议的规则。如果协议允许其他事务跳过锁检查直接访问数据，X 锁的排他性就会被 “绕过”。

2. 一级封锁协议的规则

一级封锁协议的规则是：

写操作：事务修改数据前必须加 X 锁，且锁持续到事务结束；

读操作：没有任何锁要求（既不要求加 S 锁，也不要求检查锁状态）。

这导致了一个矛盾的现象：

X 锁本身是排他的，但协议未强制读操作获取 S 锁或检查锁状态。

因此，当事务 T1 持有 X 锁修改数据时，其他事务（如 T2）可以直接读取该数据（无需加锁），X 锁的排他性对读操作无效。

3. 为什么 X 锁未释放时其他事务能读取数据？

根本原因在于一级封锁协议未对读操作施加任何锁控制。具体来说：

X 锁的排他性仅在其他事务尝试加锁时才会生效。

如果其他事务根本不需要加锁（例如一级协议中的读操作），它们就可以直接访问数据，绕过 X 锁的限制。

举个例子：

数据 R被 T1 加了 X 锁（正在修改）。

事务 T2

尝试读取 R：

按照一级协议，T2 不需要加 S 锁，也不需要检查 R 是否被 X 锁锁定。

因此，T2 可以直接读取 R，看到 T1 未提交的中间结果（脏数据）。

4. 总结：X 锁在一级协议中的局限性

X 锁本身是独占的，但仅对写操作有效（因为其他事务无法加 X 锁）。

对读操作无效，因为协议允许读操作跳过锁检查。

因此，一级协议无法解决脏读问题，必须通过二级或三级协议（要求读操作加 S 锁）才能真正实现 X 锁的排他性。

一句话总结

X 锁的排他性需要协议规则的支持。一级封锁协议未强制读操作加锁，导致 X 锁的 “独占性” 在读操作时被架空，其他事务可以直接读取被 X 锁锁住的数据。

数据库的安全性⭐

数据库安全性的常见措施

用户标识和鉴定
- 属于数据库最外层的安全保护手段，通过用户账户、口令、随机数检验等方式，验证用户身份的合法性，确保只有授权用户能访问数据库。
存取控制
- 核心是对用户授权，明确用户可执行的操作类型（如查找、插入、删除、修改等），以及允许操作的数据对象范围。通常通过 SQL 语句 Grant（授予权限）和 Revoke（收回权限）实现。
密码存储和传输
- 针对远程终端传输的信息，采用密码加密方式，保障数据在存储和传输过程中的安全性，防止信息泄露。
视图的保护
- 通过对数据库视图进行授权，限制用户只能访问视图定义范围内的数据，间接保护底层真实数据，控制数据访问边界。
审计
- 利用专用文件或数据库，自动记录用户对数据库的所有操作（如查询、修改等），用于追溯操作历史、检测非法访问，辅助安全审计与问题排查。

数据库备份与恢复技术⭐

数据备份

备份方式定义
- 冷备份（静态备份）：关闭数据库，在停止状态下复制数据库所有文件完成备份。
- 热备份（动态备份）：利用备份软件，在数据库正常运行时直接备份数据文件。
优缺点对比

备份方式	优点	缺点
冷备份	1. 备份速度快（仅复制文件）； 2. 易归档与恢复（还原文件即可）； 3. 可结合归档恢复数据库 “最佳状态”； 4. 维护成本低，安全性高。	1. 单独使用时，仅支持特定时间点恢复； 2. 备份期间数据库无法执行其他操作； 3. 磁盘空间不足时，需转存外部设备，速度慢； 4. 不支持按表或用户恢复。
热备份	1. 支持表空间或数据库文件级备份，耗时短； 2. 备份时数据库仍可使用； 3. 支持秒级恢复，可恢复几乎所有数据库实体； 4. 恢复速度快。	1. 操作容错率低，出错后果严重； 2. 若备份失败，无法用于时间点恢复； 3. 维护难度大，不允许 “失败告终”。

备份方式及日志文件

数据备份方式
- 完全备份
  - 定义：对数据库中的所有数据进行完整备份，涵盖全部数据内容。
- 差量备份
  - 定义：仅备份自上一次完全备份之后发生变化的数据。即每次差量备份的内容，都是基于最近一次完全备份的增量部分。
- 增量备份
  - 定义：备份自上一次任意类型备份（如完全备份、增量备份）之后变化的数据。与差量备份不同，增量备份的 “上一次备份” 不局限于完全备份。
日志文件
- 作用：事务日志用于记录数据库的所有改变操作（如增、删、改等），并将记录结果存储在独立文件中。日志文件是数据恢复的重要依据，可辅助还原数据库操作历史，实现精准恢复。

数据库故障与恢复

数据库故障分类及处理

事务本身的可预期故障
- 原因：事务自身逻辑问题。
- 解决：在程序中预先设置 Rollback 语句，主动回滚事务。
事务本身的不可预期故障
- 原因：如算术溢出、违反存储保护等意外错误。
- 解决：由数据库管理系统（DBMS）的恢复子系统通过日志，撤销事务对数据库的修改，回退到事务初始状态。
系统故障
- 原因：系统停止运转（如宕机）。
- 解决：利用检查点法，在系统重启时自动完成恢复。
介质故障
- 原因：外存（如磁盘）被破坏。
- 解决：通过日志重做业务，恢复数据。

恢复核心操作（UNDO 与 REDO）

撤销事务（UNDO）：针对故障发生时未完成的事务，通过日志记录将其操作撤销，回滚未提交的修改。
重做事务（REDO）：针对故障发生前已提交的事务，通过日志重新执行其操作，确保已提交的数据被正确恢复。