Database Management Review (3)

数据库设计概述

数据库设计是指对于一个给定的应用环境，构造（设计）优化的数据库逻辑模式和物理结构，并据此建立数据库及其应用系统，使之能够有效地存储和管理数据，满足各种用户的应用需求，包括信息管理需求和数据操作要求。

信息管理要求：在数据库中应该存储和管理哪些数据对象。

数据操作要求：对数据对象需要进行哪些操作，如查询、增、删、改、统计等操作

数据库设计的目标

数据库设计的目标是为用户和各种应用系统提供一个信息基础设施和高效率的运行环境。

高效率的运行环境是指：

数据库数据的存取效率高

数据库存储空间的利用率高

数据库系统运行管理的效率高

数据库设计的特点

基本规律：三分技术，七分管理，十二分基础数据
- 管理：数据库建设项目管理，企业的业务管理
- 基础数据：数据的收集、整理、组织和不断更新。
结构（数据）设计和行为（处理）设计相结合
- 将数据库结构设计和数据处理设计密切结合
- 结构和行为分离的设计

数据库设计的基本步骤

需求分析：是否充分与准确，决定了构建数据库的速度与质量
概念结构设计：通过对用户需求进行综合、归纳与抽象，形成一个独立于具体数据库管理系统的概念模型
逻辑结构设计：将概念结构转换为某个数据库管理系统所支持的数据模型，并对其进行优化
物理结构设计：为逻辑数据结构选取一个最适合应用环境的物理结构，包括存储结构和存取方法
数据库实施：
- 根据逻辑设计和物理设计的结果构建数据库
- 编写与调试应用程序
- 组织数据入库并进行试运行
数据库运行和维护：
- 经过试运行后即可投入正式运行
- 在运行过程中必须不断对其进行评估、调整与修改。

其中：需求分析和概念设计独立于任何数据库管理系统，逻辑设计和物理设计与选用的数据库管理系统密切相关

18 需求分析

需求分析就是分析用户的要求。是设计数据库的起点，其结果是否准确地反映了用户的实际要求，将直接影响到后面各个阶段的设计，并影响到设计结果是否合理和实用。

需求分析的任务

详细调查现实世界要处理的对象（组织、部门、企业等）
充分了解原系统（手工系统或计算机系统）工作概况
明确用户的各种需求
在此基础上确定新系统的功能
新系统必须充分考虑今后可能的扩充和改变

调查的重点是“数据”和“处理”，获得用户对数据库的要求

信息要求：

用户需要从数据库中获得的信息的内容与性质

由信息要求可以导出数据要求，即在数据库中需要存储哪些数据

处理要求

用户要完成的处理功能

对处理性能的要求

安全性与完整性要求

确定用户最终需求的难点
- 用户缺少计算机知识，不能准确地表达自己的需求，他们所提出的需求往往不断地变化。
- 设计人员缺少用户的专业知识，不易理解用户的真正需求，甚至误解用户的需求
解决方法
- 设计人员必须不断深入地与用户进行交流，才能逐步确定用户的实际需求

18.1 需求分析方法

调查清楚用户的实际需求并进行初步分析
与用户达成共识
分析与表达这些需求

18.2 数据字典

数据字典是关于数据库中数据的描述，即元数据，不是数据本身。
数据字典在需求分析阶段建立，在数据库设计过程中不断修改、充实、完善。
数据字典是进行详细的数据收集和数据分析所获得的主要结果
注意：和关系数据库管理系统中数据字典的区别和联系

数据字典的内容

数据项
数据结构
数据流
数据存储
处理过程

数据项是数据的最小组成单位

若干个数据项可以组成一个数据结构

数据字典通过对数据项和数据结构的定义来描述数据流、数据存储的逻辑内容

18.2.1 数据项

数据项是不可再分的数据单位

对数据项的描述：数据项描述 = {数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其他数据项的逻辑关系，数据项之间的联系}

“取值范围”、“与其它数据项的逻辑关系”定义了数据的完整性约束条件，是设计数据检验功能的依据
可以用关系规范化理论为指导，用数据依赖的概念分析和表示数据项之间的联系。

18.2.2 数据结构

数据结构反映了数据之间的组合关系
一个数据结构可以由若干个数据项组成，也可以由若干个数据结构组成，或由若干个数据项和数据结构混合组成。

对数据结构的描述：数据结构描述 = {数据结构名，含义说明，组成：{数据项或数据结构}}

18.2.3 数据流

数据流是数据结构在系统内传输的路径

对数据流的描述：数据流描述 = {数据流名，说明，数据流来源，数据流去向，组成：{数据结构}，平均流量，高峰期流量}

数据流来源：说明该数据流来自哪个过程
数据流去向：说明该数据流将到哪个过程去
平均流量：在单位时间（每天、每周、每月等）里的传输次数
高峰期流量：在高峰时期的数据流量

18.2.4 数据存储

数据存储是数据结构停留或保存的地方，也是数据流的来源和去向之一。

对数据存储的描述：数据存储描述 = {数据存储名，说明，编号，输入的数据流，组成：{数据结构}，数据量，存取频度，存取方式}

存取频度：每小时、每天或每周存取次数，每次存取的数据量等信息
存取方式：批处理/联机处理；检索/更新；顺序检索/随机检索
输入的数据流：数据来源
输出的数据流：数据去向

18.2.5 处理过程

处理过程的具体处理逻辑一般用判断表或判定树来描述，数据字典中只需要描述处理过程中的说明性信息

处理过程说明性信息的描述：处理过程描述 = {处理过程名，说明，输入：{数据流}，输出：{数据流}，处理：{简要说明}}

简要说明：说明该处理过程的功能及处理要求
- 功能：该处理过程用来做什么
- 处理要求：处理频度要求，如单位时间里处理多少事务，多少数据量、响应时间要求等
- 处理要求是后面物理设计的输入及性能评价的标准

18.3 需求阶段的强调点

设计人员应该充分考虑到可能的扩充和改变，使设计易于更改，系统易于扩充。
必须强调用户的参与。

19 概念模型和ER模型

19.1 概念模型

将需求分析得到的用户需求抽象为信息结构（即概念模型）的过程就是概念结构设计。

概念模型的特点：

能真实、充分地反映现实世界，是现实世界的一个真实模型。
易于理解，从而可以用它和不熟悉计算机的用户交换意见。
易于更改，当应用环境和应用要求改变时，容易对概念模型修改和扩充
易于向关系、网状、层次等各种数据模型转换。

描述概念模型的工具：E-R 模型

两个实体型之间的联系：

一对一联系：如果对于实体集 $A$ 中的每一个实体，实体集 $B$ 中至多有一个（也可以没有）实体与之联系，反之亦然，则称实体集 $A$ 与实体集 $B$ 具有一对一联系，记为 $1 : 1$
一对多联系：如果对于实体集 $A$ 中的每一个实体，实体集 $B$ 中有 $n$ 个实体 $(n \ge 0)$ 与之联系，反之，对于实体集 $B$ 中的每一个实体，实体集 $A$ 中至多只有一个实体与之联系，则称实体集 $A$ 与实体集 $B$ 有一对多联系，记为 $1:n$
多对多联系：如果对于实体集 $A$ 中的每一个实体，实体集 $B$ 中有 $n$ 个实体 $(n \ge 0)$ 与之联系，反之，对于实体集 $B$ 中的每一个实体，实体集 $A$ 中也有 $m$ 个实体 $(m \ge 0)$ 与之联系，则称实体集 $A$ 与实体集 $B$ 具有多对多联系，记为 $m:n$

需要注意的是，联系中的某一方数量可以为0

除了两个实体型之间的联系，还有两个以上的实体型之间的联系，也分为一对一、一对多和多对多。比如说：课程、教师、参考书之间就存在着联系，一门课程有若干个教室讲授，一个老师只讲授一门课程，则课程与老师是 $1:n$ 的联系，一本参考书只供一门课程使用，一门课程可以用多本参考书，则两者之间是 $1:n$ 的联系。

单个实体型之间也会存在联系，比如说职工实体型内部具有领导与被领导的关系，即某一职工（上司）“领导”若干名职工，而一名职工仅被另一个职工直接领导，所以是一对多的关系。

19.2 E-R 模型

联系的度：参与联系的实体型的数目

2个实体型之间的联系度为2，也称为二元联系；
3个实体型之间的联系度为3，也称为三元联系；
$N$ 个实体型之间的联系度 $N$ ，也称为 $N$ 元联系

19.2.1 E-R 图的表示方法

实体型：矩形表示，矩形框内写明实体名。
属性：用椭圆形来表示，并用无向边将其与相应的实体型连接起来。

例如，学生实体具有学号、姓名、性别、出生年份、系、入学时间等属性，用E-R图可以如下方式表示

联系：用来菱形表示，菱形框内写明联系明，并用无向边分别与有关实体型连接起来，同时在无向边旁标上联系的类型（ $1:1$ , $1:n$ 或 $m:n$ ）
联系可以具有属性

19.2.2 ISA联系

有的实体型是某个实体型的子类型，这种父类-子类联系称为“ISA”联系，用三角形表示。
ISA联系的性质：子类继承了父类的所有属性，子类也可以有自己的属性。

ISA联系-分类属性

分类属性是父实体型的一个属性
分类属性的值把父实体型中的实体分派到子实体型中。

上图中的学生类别就是一个分类属性

ISA联系-不相交约束与可重叠约束

不相交约束：描述父类中的一个实体不能同时属于多个子类中的实体集，即一个父类中的实体最多属于一个子类实体集。（在三角形中打一个叉号来表示）
可重叠约束：父类中的一个实体能同时属于多个子类中的实体集。子类符号中没有叉号表示是可重叠的。

ISA联系-完备性约束

描述父类中的一个实体是否必须是某一个子类中的实体
- 如果是，则叫做完全特化（Total specialization）
- 否则的话叫做部分特化（Partial specialization）
完全特化用父类到子类的双线连接来表示
部分特化用父类到子类的单线连接来表示

基数约束

说明实体型中的任何一个实体可以在联系中出现的最少次数和最多次数
对实体之间一对一、一对多、多对多联系的细化
约束使用一个数对 $\min .. \max$ 来表示， $0 \le \min \le \max$ 。例如 $0 ..1$ ， $1..3$ ， $1..*$ ，其中 $*$ 代表无穷大。
$\min = 1$ 的约束叫做强制参与约束，即被施加基数约束的实体型中的每个实体都要参与联系。
$\min = 0$ 的约束叫做非强制参与约束，被施加基数约束的实体型中的实体可以出现在联系中，也可以不出现在联系中。

Part-of 联系

描述某个实体型是另一个实体型的一部分
Part-of 联系可以分为两种情况
- 非独占的 Part-of 联系，简称非独占联系：即整体实体如果被破坏，另一部分实体仍然可以独立存在，那么就是非独占的 Part-of 联系。
- 独占的 Part-of 联系，简称独占联系：整体实体如果被破坏，部分实体不能存在。
Part-of 联系如何表示
- 用非强制参与联系表示非独占的 Part-of 联系
- 用弱实体类型和识别联系来表示独占联系

弱实体型和独占联系

如果一个实体型的存在依赖于其他实体型的存在，则这个实体型叫做弱实体型，否则叫做强实体型。
用弱实体型和识别联系来表示独占联系，双矩阵表示弱实体型，双菱形表示识别联系。

20 概念结构设计

概念结构设计的方法：

自顶向下：首先定义全局概念结构的框架，然后逐步细化。
自底向上：首先定义各局部应用的概念结构，然后将它们集成起来，得到全局概念结构。
逐步扩张：首先定义最重要的核心概念结构，然后向外扩充，以滚雪球的方式逐步生成其他概念结构，直至总体概念结构。
混合策略：将自顶向下和自底向上相结合，用自顶向下策略设计一个全局概念结构的框架，以它为骨架集成由自底向上策略中设计的各局部概念结构。

常用策略：自顶向下进行需求分析，自底向上设计概念结构

自底向上设计概念结构的步骤：

抽象数据并设计局部视图
集成局部视图，得到全局概念结构

20.1 实体与属性的划分

原则

为了简化 E-R 图的处置，现实世界的事物能作为属性对待的，尽量作为属性对待。
两条准则：
1. 作为属性，不能再具有需要描述的性质。属性必须是不可分的数据项，不能包含其他属性。
2. 属性不能与其他实体具有联系，即E-R图中所表示的联系是实体之间的联系。

20.2 有关 E-R 图

E-R 图的集成

合并。解决各分 E-R 图之间的冲突，将分 E-R 图合并起来生成初步 E-R 图
修改和重构。消除不必要的冗余，生成基本 E-R 图。

20.2.1 合并E-R图

各个局部应用所面向的问题不同，各个子系统的 E-R图之间必定会存在许多不一致的地方，这称为冲突。子系统 E-R图之间的冲突主要有以下的三类：

属性冲突
命名冲突
结构冲突

20.2.2 属性冲突

属性域冲突，即属性值的类型、取值范围或取值集合不同

例如零件号，有的部门把它定义为整数，有的部门把它定义为字符串

年龄，某些部门以出生日期形式表示职工的年龄，而另一些部门用整数表示职工的年龄
属性取值单位冲突

例如，零件的重要有的以公斤为单位，有的以斤为单位，有的以克为单位

20.2.3 命名冲突

同名异义，即不同意义的对象在不同的局部应用中具有相同的名字。
异名同义（一义多名），即同一意义的对象在不同的局部应用中具有不同的名字。

如对科研项目，财务科称为项目，科研处称为客体，生产管理处称为工程。
命名冲突
- 可能发生在实体、联系一级上
- 也可能发生在属性一级上
- 通过讨论、协商等行政手段加以解决。

20.2.4 结构冲突

同一对象在不同应用中具有不同的抽象

例如，职工在某一局部应用中被当做实体，而在另一局部应用中则被当做属性。

解决方法：把属性变换为实体或把实体变换为属性，使同一对象具有相同的抽象。但仍然要遵循实体与属性的划分原则。
同一实体在不同子系统的E-R图中所包含的属性个数和属性排列次序不完全相同

解决方法：使该实体的属性取各子系统的 E-R图中属性的并集，再适当调整属性的次序。
实体间的联系在不同的 E-R图中为不同的类型

实体 $E_1$ 与 $E_2$ 在一个 E-R图中是多对多联系，在另一个 E-R图中是一对多联系

解决方法：根据应用的语义对实体联系的类型进行综合或调整。

20.2.5 E-R图的修改和重构

消除不必要的冗余，设计基本 E-R图

所谓冗余的数据是指可由基本数据导出的数据，冗余的联系是指可由其他联系导出的联系。
消除冗余主要采用分析方法，即以数据字典和数据流图为依据，根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。

21 逻辑结构设计

逻辑结构设计的任务

把概念结构设计阶段设计好的基本E-R图转换为与选用数据库管理系统产品所支持的数据模型相符合的逻辑结构。
转换内容：
- E-R图由实体型、实体的属性和实体型之间的联系三个要素组成。
- 关系模型的逻辑结构是一组关系模式的集合。
- 将E-R图转换为关系模型：将实体型、实体的属性和实体型之间的联系转换为关系模式。

实体型转换为关系模式

关系的属性：实体的属性
关系的码：实体的码

21.1 转换原则

1：1联系

一个 $1:1$ 联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。

转换为一个独立的关系模式：
- 关系的属性：与该联系相连的各实体的码以及联系本身的属性。
- 关系的候选码：每个实体的码均是该关系的候选码。
与某一端实体对应的关系模式合并
- 合并后关系的属性：加入对应关系的码和联系本身的属性。
- 合并后关系的码：不变。

1：n联系

一个 $1:n$ 联系可以转换为一个独立的关系模式，也可以与 $n$ 端对应的关系模式合并

转换为一个独立的关系模式：
- 关系的属性：与该联系相连的各实体的码以及联系本身的属性
- 关系的码： $n$ 端实体的码
与 $n$ $n$ 端对应的关系模式合并
- 合并后关系的属性：在 $n$ 端关系中加入 $1$ 端关系的码和联系本身的属性
- 合并后关系的码：不变
- 可以减少系统中的关系个数

m：n联系

一个 $m: n$ $m : n$ 联系转换为一个关系模式：
- 关系的属性：与该联系相连的各实体的码以及联系本身的属性
- 关系的码：各实体码的组合

22 物理结构设计

数据库在物理设备上的存储结构与存取方法称为数据库的物理结构，它依赖于选定的数据库管理系统。
为一个给定的逻辑数据模型选取一个最适合应用要求的物理结构的过程，就是数据库的物理设计。

数据库物理设计的步骤：

确定数据库的物理结构，在关系数据库中主要指存取方法和存储结构;
对物理结构进行评价，评价的重点是时间和空间效率
若评价结果满足原设计要求，则可进入到物理实施阶段。否则，就需要重新设计或修改物理结构，有时甚至要返回逻辑设计阶段修改数据模型。

数据库物理设计的内容和方法：

设计物理数据库结构的准备工作：
- 充分了解应用环境，详细分析要运行的事物，以获得选择物理数据库设计所需参数。
- 充分了解所用关系型数据库管理系统的内部特征，特别是系统提供的存取方法和存储结构。
关系数据库物理设计的内容：
- 为关系模式选取存取方法
- 设计关系、索引等数据库文件的物理存储结构。
物理数据库设计所需参数：
- 数据库查询事务：查询的关系，查询的条件所涉及的属性，连接条件所涉及的属性，查询的投影属性。
- 数据更新事务：被更新的关系，每个关系上的更新操作条件所涉及的属性。
- 修改操作要改变的属性值。
每个事务在各关系上运行的频率和性能要求

22.1 关系模式存取方法选择

数据库系统是多用户共享的系统，对同一个关系要建立多条存取路径才能满足多用户的多种应用要求。物理结构设计的任务之一是根据关系数据库管理系统支持的存取方法确定选择哪些存取方法。

数据库管理系统常用存取方法：

$B+$ 数索引存取方法
$Hash$ 索引存取方法
聚簇存取方法

22.1.1 B+树索引存取方法的选择

选择索引存取方法的主要内容：根据应用要求确定

对哪些属性列建立索引
对哪些属性列建立组合索引
对哪些索引要设计为唯一索引

选择索引存取方法的一般规则

如果一个（或一组）属性经常在查询条件中出现，则考虑在这个（或这组）属性上建立索引（或组合索引）
如果一个属性经常作为最大值和最小值等聚集函数的参数，则考虑在这个属性上建立索引
如果一个（或一组）属性经常在连接操作的连接条件中出现，则考虑在这个（或这组）属性上建立索引

需要注意的是，并不是索引越多数据库存取的效率就会越高，关系上定义的索引数过多会带来较多的额外开销（维护、查找索引的开销)。

22.1.2 Hash索引存取方法的选择

如果一个关系的属性主要出现在等值连接条件中或主要出现在等值比较选择条件中，而且满足下列两个条件之一

该关系的大小可预知，而且不变；
该关系的大小动态改变，但所选用的数据库管理系统提供了动态Hash存取方法。

22.1.3 聚簇索引存取方法的选择

既适用于单个关系独立聚簇，也适用于经常进行连接操作的多个关系。

把多个连接的元组按连接属性值聚集存放
从而实现多个关系的“预连接”，提高连接操作的效率。

选择聚簇存储方法，即确定需要建立多少个聚簇，每个聚簇中包含哪些关系。一个数据库可以建立多个聚簇，一个关系只能加入一个聚簇
设计候选聚簇

常在一起进行连接操作的关系可以建立组合聚簇
如果一个关系的一组属性经常出现在相等比较条件中，则该单个关系可建立聚簇；
如果一个关系的一个（或一组）属性上的值重复率很高，则此单个关系可建立聚簇。

检查候选聚簇中的关系，取消其中不必要的关系

从聚簇中删除经常进行全表扫描的关系
从聚簇中删除更新操作远多于连接操作的关系
从聚簇中删除重复出现的关系
当一个关系同时加入多个聚簇时，必须从这多个聚簇方案（包括不建立聚簇）中选择一个较优的，即在这个聚簇上运行各种事务的总代价最小。

聚簇的局限性

聚簇只能提高某些特定应用的性能
建立与维护聚簇的开销相当大
- 对已有关系建立聚簇，将导致关系中元组的物理存储位置移动，并使此关系上原有的所有索引无效，必须重建。
- 当一个元组的聚簇码改变时，该元组的存储位置也要做相应改变。

当通过聚簇码进行访问或连接是该关系的主要应用，与聚簇码无关的其他访问很少或者是次要的时，可以使用聚簇。尤其当SQL语句中包含有与聚簇码有关的ORDER BY, GROUP BY, UNION, DISTINCT等子句或短语时，使用聚簇特别有利，可以省去或减化对结果集的排序操作。

22.2 确定数据库的存储结构

确定数据库物理结构主要指确定数据的存放位置和存储结构，包括：确定关系、索引、聚簇、日志、备份等的存储安排和存储结构，确定系统配置等。

影响数据存放位置和存储结构的因素：

硬件环境
应用需求：存取时间、存储空间利用率、维护代价（这三个方面常常是相互矛盾的，必须进行权衡，选择一个折中的方案）

确定数据存放位置的基本原则：根据应用情况将易变部分与稳定部分分开存放，经常存取部分与存取频率较低部分分开存放。

确定系统配置：系统为这些变量赋予了合理的缺省值。进行物理设计时需要根据应用环境确认参数值，使系统性能最优，同时也要根据系统实际运行情况来做进一步的调整，以切实改进系统性能。（包括同时使用数据库的用户数，同时打开的数据库对象数，内存分配参数等）

评价物理结构：对数据库物理设计过程中产生的多种方案进行评价，从中选择一个较优的方案作为数据库的物理结构。

评价方法：定量估算各种方案

存储空间
存取时间
维护代价

23 数据库的实施和维护

略非重点

24 面向驱动的数据库编程

不同的数据库管理系统通过不同的驱动来加载。具体可看 JDBCLeraning

25 过程化SQL

过程化SQL是SQL的扩展，在SQL的基础上增加了过程化语句功能，基本结构是块，每个块完成一个逻辑操作，且块与块是可以嵌套的。

需要注意的是，这部分SQL 与 MYSQL 语法是有区别的！

定义块与执行块

DECLARE <变量> | <常量> | <游标> | <异常>

定义的变量、常量等只能在该基本块中使用
当基本块执行结束时，定义就不再存在。

BEGIN
	<SQL语句> | <过程化SQL的流程控制语句>
EXCCEPTION
	<异常处理部分>
END;

变量和常量的定义

变量定义：

DECLARE <变量名> <数据类型> [[NOT NULL] := <初值表达式>]
DECLARE <变量名> <数据类型> [[NOT NULL] <初值表达式>]

常量定义：

DECLARE <常量名> <数据类型> CONSTANT := <常量表达式>

**注意：**常量在声明时必须要给一个值，并且该值在存在期间或常量的作用域内是不能改变的。如果试图改变常量，那么过程化SQL将会返回一个异常。

赋值语句：

<变量名称> := <表达式>

流程控制-条件控制语句

IF <condition> THEN
	<SQL语句>
END IF;

IF <condition> THEN
	<SQL语句>
ELSE
	<SQL语句>
END IF;

MYSQL 中有 IF() 和 IFNULL() 函数来在语句内部进行条件的控制。IF() 是可以嵌套的

流程控制-循环控制语句

LOOP
-- 提供EXIT/BREAK/LEAVE等循环结束语句 --
	<SQL语句>
END LOOP;

WHILE <condition> LOOP
	<SQL语句>
END LOOP;

FOR <count> IN [REVERSE] <bound1> ... <bound2> LOOP
	<SQL语句>
END LOOP;

如果过程化SQL在执行时出现异常，则应该让程序在产生异常的语句处停下来，根据异常的类型去执行异常处理语句
SQL标准对数据库服务器提供什么样的异常处理做出了建议，要求过程化SQL管理器提供完善的异常处理机制

存储过程

存储过程化SQL语句书写的过程，经过编译和优化后存储在数据库服务器中，使用的时候只要调用就可以了，优点：

运行效率高
降低了客户机和服务器之间的通信量
方便实施企业规则

创建存储过程：

CREATE OR REPLACE PROCEDURE <过程名>([<参数1>, <参数2>]) AS <过程化SQL块>

过程名：数据库服务器合法的对象标识
参数列表：用名字来标识调用时给出的参数值，必须指定值的数据类型。参数也可以定义输入参数、输出参数或输入/输出参数，默认为输入参数
过程体：是一个<过程化SQL块>，包括声明部分和可执行语句部分

26 事务

事务（Transaction）是用户定义的一个数据库操作序列，这些操作要么全做，要么全不做，是一个不可分割的工作单位。

事务和程序是两个概念：

在关系数据库中，一个事务可以是一条SQL语句，一组SQL语句或者整个程序
一个程序通常包含多个事务

事务是恢复和并发控制的基本单位

26.1 定义事务

显式定义事务
BEGIN TRANSACTION
<SQL语句1>
<SQL语句2>
...
COMMIT;

BEGIN TRANSACTION
<SQL语句1>
<SQL语句2>
...
ROLLBACK;
COMMIT：
1. 事务正常结束
2. 提交事务的所有操作（读+更新）
3. 事务中所有对数据库的更新写回到磁盘上的物理数据库中
ROLLBACK：
1. 事务异常终止
2. 事务运行的过程中发生了故障，不能继续执行
3. 系统将事务中对数据库的所有已完成的操作全部撤销
4. 事务滚回到开始时的状态
隐式方式：当用户没有显式地定义事务时，数据库管理系统按缺省规定自动划分事务。

26.2 事务的特性（ACID）

26.2.1 原子性 Atomicity

事务是数据库的逻辑工作单位：事务中包括的所有操作要么全部都一起做了，要么都不做。

26.2.2 一致性 Consistency

事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态
一致性状态：数据库中只包含成功事务提交的结果
不一致状态：
- 数据库系统运行中发生故障，有些事务尚未完成就被迫中断；
- 这些未完成事务对数据库所做的修改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态

26.2.3 隔离性 Isolation

一个事务的执行不能被其他事务干扰
一个事务内部的操作及使用的数据对其他并发事务是隔离的
并发执行的各个事务之间不能互相干扰

26.2.4 持续性 Durability

一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。
接下来的其他操作或故障不应该对其执行结果有任何影响。

破坏事务ACID特性的因素

多个事务并行运行时，不同事务的操作交叉执行：数据库管理系统必须保证多个事务的交叉运行不影响这些事务的隔离性
事务在运行过程中被强行停止：数据库管理系统必须保证被强行终止的事务对数据库和其他事务没有任何影响

后面主要介绍的是数据库遇到错误和发生异常时的策略，主要是通过日志文件来 redo 和 undo 某些事务。同时介绍了需要定时转储数据库中的数据和日志文件等。

日志文件的记录方式有所不同，但大体的方式就是记录事务的每一条操作，然后对事务的操作进行 redo，直到恢复到故障时刻的数据。

等级日志文件需要满足两条原则：

登记的次序严格按照并发事务执行的时间次序

必须要先写日志文件，然后写数据库：如果先写数据库再写日志文件，那么写数据库过程中若是发生故障，则日志文件里就会缺失一部分的事务执行记录。如果先写了数据库修改，而在日志文件中没有登记下这个修改，则以后就无法恢复这个修改了

Reference

数据库系统概论（第五版）
数据库系统概念
南京大学软件学院2022春季学期数据管理基础课程