基本概念

• 数据(Data)
  • 定义：数据是描述事物的符号记录。
  • 数据的种类：文本、图像、视频等
  • 数据的含义称为语义
• 数据库(DB：Database)
  • 定义：是==长期储存==在计算机内、==有组织==的、==可共享==的大量数据的集合
  • 基本特征
    1. 数据按一定的数据模型组织、描述和储存（有组织）
    2. 可为各种用户共享、冗余度较小（共享）
    3. 数据独立性较高、易扩展
    4. 针对明确的目标而设计、建立、加载（为用户服务）
    5. 数据库应该反映现实世界中的某一方面（静态和动态特征）
• 数据库管理系统(DBMS： Database Management System )
  • 定义：对数据库中的数据进行存储和管理的 对数据库中的数据进行存储和管理的软件系统
  • 分类：小型：ACCESS；大型：DB2, ORACLE
  • DBMS主要功能：
    1. 数据定义——提供数据定义语言、定义数据库中的数据对象
    2. 数据组织、存储、管理
    3. 数据操纵功能——实现对数据库的基本操作，增删改查
    4. 数据库的事务管理和运行管理——安全性、完整性、多用户并发使用、故障恢复
    5. 数据库的建立和维护功能
• 数据库系统(DBS：Database System) or 数据库应用系统(DBAS： Database Application System）
  • 在计算机系统中引入数据库后的系统。

发展历史

什么是数据管理：对数据进行分类、组织、编码、存储、检索和维护。

数据管理技术的发展动力：应用需求和计算机软硬件的发展

发展三阶段：

1. 人工管理阶段：20世纪40年代中–50年代中，没有磁盘、操作系统，只能计算、无法存储结果。
2. 文件管理阶段：20世纪50年代末–60年代中，出现操作系统，可以存储计算结果。
3. 数据库管理阶段：20世纪60年代末–现在，大容量磁盘，DBMS，大规模数据处理，数据共享。

文件系统和数据库系统的本质区别：

• 内部 ：数据库的数据是结构化的，有联系的、文件系统的各记录无联系
• 外部 ：数据库系统是共享的、文件系统基本上是面向特定用户的

数据独立性

物理独立性

• 指用户的应用程序与存储在磁盘上的数据库中数据是相互独立的 。当数据的物理存储改变了，应用程序不用改变。

逻辑独立性

• 指用户的应用程序与数据库的逻辑结构是相互独立的。数据的逻辑结构改变了，用户程序也可以不变。

数据库系统的组成

狭义

• 数据库
• 数据库管理系统
• 数据库应用系统
• 数据库管理员

广义

• 数据库
• 数据库管理系统
• 数据库应用系统
• 人员（数据库管理员、系统分析人员、数据库设计员、程序员）
• 软件平台
• 硬件平台用户

数据和数据模型

描述事物的符号记录称为数据。

• 将从数据中获得的有意义的内容称为信息。
• 数据是信息存在的一种形式，只有通过解释或处理才能成为有用的信息。

两种特征

1. 静态特征
   • 数据的基本结构（学生的学号、姓名、性别、出生日期）
   • 数据间的联系（学生选课中的学号与学生基本信息中的学号）
   • 数据取值范围约束（考试成绩在0～100分之间）
2. 动态特征
   • 指对数据可以进行的操作以及操作规则，包括增、删、改、查等。

一般将对数据的静态特征和动态特征的描述称为数据模型三要素，即数据的基本结构、数据的约束条件和定义在数据上的操作。

数据模型 (data model) 也是一种模型，它是对现实世界数据特征的抽象。

在数据库中用数据模型这个工具来抽象、表示和处理现实世界中的数据和信息

两大类数据模型

把现实世界中的客观对象抽象为概念模型

• 它是从数据的应用语义视角来抽取并按用户的观点来对数据和信息进行建模，用于数据库设计。

把概念模型转换为某一DBMS支持的组织模型

• 从数据的组织方式来描述数据，

概念层数据模型

ER模型是常用的概念层数据模型（除此之外还有面向对象的模型）

基本概念

实体（Entity）：客观存在并可相互区别的事物称为实体，可以是具体的人、事、物或抽象的概念

属性（Attribute）：实体所具有的特征或性质、一个实体可以由若干个属性来刻画

主码（Primary key）：唯一标识实体的属性集称为码。

联系（Relationship）：现实世界中事物内部以及事物之间的联系在信息世界中反映为实体内部的联系和实体之间的联系。实体内部的联系通常是指组成实体的各属性之间的联系，实体之间的联系通常是指不同实体集之间的联系。

联系包括一对一联系、一对多联系、多对多联系。

ER图表示

实体：矩形，矩形内写实体名称

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

码：属性名加下划线

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

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

联系：用菱形表示。

数据库系统的结构

三级模式和两级映像

三级模式

1. 外模式

外模式也称子模式（subschema）或用户模式，它是数据库用户（包括应用程序员和最终用户）能够看见和使用的局部数据的逻辑结构和特征的描述，是数据库用户的数据视图，是与某一应用有关的数据的逻辑表示。

一个数据库可以有多个外模式。但一个应用程序只能使用一个外模式。

1
2
3
4
5
6

简单理解为数据库的视图，或者视图的集合，view，操作包括：
- 视图（Views）：视图是基于一个或多个表的查询结果集，用户可以通过视图来访问数据，视图的定义包含了选择、投影和连接等操作。
- 索引（Indexes）：索引是为了提高数据检索效率而创建的数据结构，外模式DDL可以定义索引的创建、修改和删除。
- 权限（Privileges）：外模式DDL可以定义用户或角色对特定对象的访问权限，包括SELECT、INSERT、UPDATE、DELETE等权限。
- 存储过程（Stored Procedures）：存储过程是一组预先编译的SQL语句集合，可以在数据库中存储和执行，外模式DDL可以定义存储过程的创建和修改。
- 触发器（Triggers）：触发器是一种在数据库中定义的自动化程序，当满足特定条件时会自动执行，外模式DDL可以定义触发器的创建和修改。

2. 模式（逻辑模式）

模式也称逻辑模式，是数据库中全体数据的逻辑结构和特征的描述，是所有用户的公共数据视图。使用DDL来定义模式。

1
2
3
4
5
6
7
8

简单理解为数据库的表，table，操作包括：
- CREATE: 用于创建数据库中的各种对象，如表、视图、索引等。
- ALTER: 用于修改数据库中已有对象的结构，如修改表结构、添加字段等。
- DROP: 用于删除数据库中的对象，如删除表、视图等。
- TRUNCATE: 用于删除表中的所有数据，但保留表结构。
- COMMENT: 用于给数据库中的对象添加注释。
- RENAME: 用于重命名数据库中的对象。
- GRANT: 用于赋予用户或角色对数据库对象的特定权限。

3. 内模式

内模式也称存储模式（storageschema），一个数据库只有一个内模式。它是数据物理结构和存储方式的描述，是数据在数据库内部的组织方式

两级映像

外模式/模式映像

当模式改变时（例如增加新的关系、新的属性、改变属性的数据类型等），由数据库管理员对各个外模式／模式的映像作相应改变，可以使外模式保持不变。

应用程序是依据数据的外模式编写的，从而应用程序不必修改，保证了数据与程序的逻辑独立性，简称数据的逻辑独立性。

模式/内模式映像

当数据库的存储结构改变时（例如选用了另一种存储结构），由数据库管理员对模式／内模式映像作相应改变，可以使模式保持不变，从而应用程序也不必改变。保证了数据与程序的物理独立性，简称数据的物理独立性。

关系代数

分为分为两大类：

• 传统的集合运算 ：广义笛卡尔积运算、并、交和差运算。
• 专门的关系运算 ： 选择、投影、连接和除运算

关系运算

选择（限制）

从行的角度进行运算。在关系R中选择满足给定条件的诸元组

F：选择条件，是一个逻辑表达式

$$
\sigma_{\mathrm{F}}(R)={t|t{\in}R\wedge F(t){=}`\text{真}}
$$

投影

从R中选择出若干属性列组成新的关系

$$
\Pi_{A}(R)={t[A]\mid t\in\mathbb{R}}
$$

A：R中的属性列

连接

从两个关系的笛卡尔积中选属性间满足一定条件的元组

$$
R\operatorname*{\longrightarrow}{{A0B}}{\mathcal S}={\begin{array}{cc}{\widehat{t_{r}t_{s}}}\\end{array}|t_{r}\in R\wedge t_{s}\in{\mathcal S}\wedge t{r}[A]\theta t_{_s}[B]}
$$

• A和B：分别为R和S上度数相等且可比的属性组
• θ：比较运算符

连接运算就是从R和S的广义笛卡尔积RXS中选取（R关系）在A属性组上的值与（S关系）在B属性组上值满足比较关系0的元组

除

给定关系R(X，Y)和S(Y，Z)，其中X、Y、Z为属性组。

R与S的除运算得到一个新的关系P(X)，P是R中满足下列条件的元组在X属性列上的投影：

$$
\mathbf{R}\div\mathbf{S}={\mathbf{t}{\mathrm{r}}[\mathbf{X}]\mid\mathbf{t}{\mathrm{r}}\in\mathbf{R}\wedge\mathbf{\pi}{\mathrm{Y}}(\mathbf{S})\subseteq\mathbf{Y}{\mathrm{x}}}
$$

函数依赖

函数依赖基本概念

这里的关系模式可以理解为数据库表的列。

如果有关系模式R(A1,A2,…，An)，X和Y为{A1,A2，…An} 的子集，则对于关系R中的任意一个X值，都只有一个Y值与之对应，则称X函数决定Y，或Y函数依赖于X，表示为：

$$
X \to Y
$$

设有关系模式R（A1，A2，..，An），X和Y均为{A1,A2，…，An}的子集，r是R的任一具体关系t1、t2是r中的任意两个元组; 如果由t1[x]=t2[x]可推导出t1[Y]=t2[Y],则称X函数决定Y，或Y函数依赖于X,记为X→Y。

$$
X \to Y
$$

一些术语和符号

设有关系模式R（A1,A2，..，An），X和Y均为{A1，A2，…,An}的子集，则有以下结论：

1. 如果X→Y，但Y不包含于X，则称 $X\to Y$是非平凡的函数依赖。（默认为非平凡函数依赖）
2. 如果X→Y，但Y包含于X，则称 $X\to Y$是平凡的函数依赖。
3. 如果$X\to Y$则称X为决定因子，Y为被决定因子
4. 如果$X\to Y$且$Y\to X$则记作$X\leftrightarrow Y$

如果$X\to Y$，且对于X的一个任意真子集$X’$，都有$X’\nrightarrow Y$成立，则称Y完全函数依赖于X（没有任何其他属性能够决定这些属性的值。）：

$$
X \xrightarrow{f} Y
$$

如果$X\to Y$，且对于X的一个任意真子集$X’$，有$X’\rightarrow Y$成立，则称Y部分函数依赖于X（X中任意一个属性不能单独决定Y）：

$$
X \xrightarrow{p} Y
$$

如果$X\to Y$，非平凡函数依赖，且：$Y\nrightarrow X$，$Y\to Z$则称Z传递函数依赖于X，记作：

$$
X \xrightarrow{传递} Y
$$

为什么要讨论函数依赖

通过分解关系模式消除不合适的数据依赖。

范式

关系模式中的码

候选码：设K为R（U,F）中的属性或属性组，若K完全决定U，则K为R的候选码。

主码：关系R（U, F）中可能有多个候选码：则选其中一个作为主码。

全码：候选码为整个属性组。

主属性：包含在任一候选码中的属性称为主属性，不包含在任一候选码中的属性称为非主属性

1
2
3
4
5

主码是**集合**，主属性是集合中的**元素**

举例来说，如果有一个关系模式 $R(A, B, C)$，其中属性 $A$ 和属性 $B$ 一起定义了主码$(A, B)$ ，那么 $A$ 和 $B$ 都是主属性。

在这种情况下，主码由多个属性组成，但主码仍然是唯一的，用来唯一标识关系中的每个元组。

外码 ：关系之间建立关联的属性（组）。关系模式R中属性（组）X是另一个关系模式S的候选码（通常为主码），则称 X 为R的外码。

范式

数据库范式是一组规范化（Normalization）的原则，用于设计关系型数据库结构，以减少数据冗余并确保数据的一致性和完整性。

分为第一范式 (1NF)、第二范式(2NF)、第三范式(3NF)、扩展的第三范式(BCNF)

总览：

$$
1NF \subset 2NF \subset 3NF \subset BCNF
$$

且

$$
1NF \xrightarrow{消除非主属性对码的部分函数依赖} 2NF \xrightarrow{消除非主属性对码的传递函数依赖} 3NF \xrightarrow{消除主属性对码的部分和传递依赖} BCNF
$$

某一关系模式R为第n范式，可简记为$R\in NF$

一个低一级范式的关系模式，通过模式分解可以转换为若干个高一级范式的关系模式的集合，这种过程就叫规范化。

第一范式（1NF）：所有属性都不可分的关系。

第二范式 (2NF）: 如果$R(U,F) \in 1NF$，并且R中的每个非主属性都完全函数依赖于码，则$R(U,F)\in 2NF$

分解方法：

• 首先，对于组成主码的属性集合的每一个子集，用它作为主码构成一个表。
• 然后，将依赖于这些主码的属性放置到相应的表中。
• 最后，去掉只由主码的子集构成的表。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

对 S-L-C(Sno, Sname, Ssex, Sdept, SLOC, Cno, Grade)

**首先**分解为如下形式的三张表：

- S-L (Sno，...）
- C(Cno, ...）
- S-C(Sno, Cno,...)

**然后**，将**依赖**于这些主码的属性放置到相应的表中，形成如下三个关系模式：

- S-L(Sno, Sname, Ssex, Sdept, SLOC)
- C(Cno)
- S-C(Sno, Cno, Grade)

**最后**，去掉只由主码的子集构成的表。

- S-L(Sno, Sname, Ssex, Sdept, SLOC)
- S-C(Sno, Cno, Grade)

---

分解后的函数依赖关系：

- S-L(Sno, Sname, Ssex, Sdept, SLOC)

$Sno \xrightarrow{f} Sname$
$Sno \xrightarrow{f} Ssex$
$Sno \xrightarrow{f} Sdept$
$Sno \xrightarrow{f} SLOC$

- S-C(Sno, Cno, Grade)

$(Sno, Cno) \xrightarrow{f} Grade$

目前存在的问题：

数据冗余：有多少个学生就有多少个重复的Sdept和SLOC
插入异常：当新建一个系时，若还没有招收学生，则无法插入；

第三范式（3NF）:如果$R(U,F)\in 2NF$并且所有非主属性都不传递依赖于码则$R(U,F)\in 3NF$

S-L(Sno, Sname, Ssex, Sdept, Sloc)

因为 Sno->Sdept, Sdept->SLOC, 所以Sno -传递-> SLOC，S-L不是3NF

分解方法：

1. 对于不是候选码的每个决定因子，从表中删去依赖于它的所有属性
2. 新建一个表，新表中包含在原表中所有依赖于该决定因子的属性，将决定因子作为新表的主码。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

S-L(<u>Sno</u>, Sname, Ssex, Sdept, Sloc)

候选码是Sno，但是Sdept是SLOC的决定因子，因此删去SLOC。

S-D(Sno, Sname, Ssex, Sdept)

新建一个表，新表中包含在原表中所有依赖于该决定因子的属性，将决定因子作为新表的主码。

S-L(Sdept, SLOC)

---

因此，S-L-C(Sno, Sname, Ssex, Sdept, SLOC, Cno, Grade)被分解为了以下三个模式：

S-D(<u>Sno</u>, Sname, Ssex, Sdept)
S-L(<u>Sno</u>, Sname, Ssex, Sdept, Sloc)
S-C(<u>Sno</u>, <u>Cno</u>, Grade)

不能说规范化程度越高的关系模式就越好。

扩展的第三范式

关系模式$R(U, F)\in 3NF$，若$X\to Y$且$Y \nsubseteq X$ 时X必含有码，则$R(U, F)\in BCNF$

等价于： 每一个决定属性因素都包含候选码。

如果$R\in 3NF$且R只有一个候选码，则

事务

事务

事务是用户定义的数据操作系列，这些操作作为一个完整的工作单元，一个事务内的所有语句被作为一个整体，要么全部执行，要么全部不执行。

一个事务可以是一组SQL语句、一条SQL语句或整个程序，一个应用程序可以包括多个事务。

事务的特征（ACID）

• 原子性(Atomicity) 事务是数据库的逻辑工作单位，事务中的操作要么都做，要么都不做。
• 一致性(Consistency) 事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。
• 隔离性(Isolation) 数据库中一个事务的执行不能被其它事务干扰。
• 持久性(Durability) 也称为永久性。事务一旦提交，对数据库数据的改变是永久的。

事务的ACID特性可能遭到破坏的因素有两种：

• 多个事务并行运行时，不同事务的操作有交叉情况
• 事务在运行过程中被强迫停止。

SQL事务处理模型

隐式事务：又称自动提交事务，每条数据操作语句都自动成为一个事务。

显式事务：有显式的开始和结束标记的事务。【ISO事务处理模型、T-SQL事务处理模型】

ISO事务处理模型

明尾暗头：事务的开头是隐含的，事务的结束有明确标记。

事务结束符
COMMIT：事务成功结束符
ROLLBACK：事务失败结束符

事务起始/终止位置：程序的首条SQL语句或事务结束符后的语句；在程序正常结束处或COMMIT语句处成功终止；在程序出错处或ROLLBACK处失败终止。

1
2
3
4
5
6
7

UPDATE 支付表
SET 帐户总额页 = 帐户总额 - n
WHERE 帐户名 = 'A'
UPDATE 支付表
SET 帐户总额 = 帐户总额 + n
WHERE 帐户名 = 'B'
COMMIT

T-SQL事务处理模型
每个事务都有显式的开始和结束标记。

事务的开始标记是：BEGIN TRANSACTION | TRAN

事务的结束标记为：

1
2

COMMIT [TRANSACTION | TRAN ]
ROLLBACK [ TRANSACTION | TRAN ]

1
2
3
4
5
6
7
8
9
10

BEGIN TRANSACTION

UPDATE 支付表
SET 帐户总额页 = 帐户总额 - n
WHERE 帐户名 = 'A'
UPDATE 支付表
SET 帐户总额 = 帐户总额 + n
WHERE 帐户名 = 'B'

COMMIT

并发控制概述

系统中，可能同时运行着多个事务，而事务的运行需要时间 ，并且事务中的操作是在一
定的数据上进行的。当系统中同时有多个事务在运行时，特别是当这些事务是对同一段数据进行操作时，彼此之间就有可能产生相互干扰的情况。

不同的多事务执行方式

1. 串行执行

每个时刻只有一个事务运行，其他事务必须等到这个事务结束以后方能运行。

问题：不能充分利用系统资源，发挥数据库共享资源的特点。

2. 交叉并行执行

在单处理机系统中，事务的并行执行是这些并行事务的并行操作轮流交叉运行。

单处理机系统中的并行事务并没有真正地并行运行，但能够减少处理机的空闲时间，提高系统的效率。

3. 同时并发方式

多处理机系统中，每个处理机可以运行一个事务。多个处理机可以同时运行多个事务，实
现多个事务真正的并行运行。

并发带来的问题

1
2
3
4
5
6
7
8

飞机订票系统中的一个活动序列：
1. 甲售票点(甲事务)读出某航班的机票余额A，设A=16;
2. 乙售票点(乙事务)读出同一航班的机票余额A，也为16;
3. 甲售票点卖出一张票，修改余额A←A-1，所以A为15，写回数据库。
4. 乙售票点也卖出一张票，修改余额A←A-1，所以A为15，写会数据库。

结果：明明卖出两张机票，数据库中机票余额只减少1
原因：第4步中乙事务修改A并写回后覆盖了甲事务的修改。

问题：

• 多个事务同时存取同一数据的情况。
• 可能会存取和存储不正确的数据。
• 破坏事务一致性和数据库的一致性。

并发控制是衡量 DBMS 性能的重要标志之一。

并发控制机制的任务

• 对并发操作进行正确调度
• 保证事务的隔离性
• 保证数据库的一致性

数据不一致情况

• 丢失修改(LostUpdate)
• 读“脏”数据(DirtyRead)
• 不可重复读(Non-repeatableRead)
• 产生“幽灵”数据

丢失修改(LostUpdate)

读“脏”数据(DirtyRead)

事务 T1对数据进行了更新但没有提交，事务T2读到了事务T1更新后(未提交)的数据。如果事务T1进行了回滚，那么刚刚事务T2看到的数据就是脏数据。事务T2 进行了脏读。

示例：甲给乙转账500，但是甲还没有提交，但是此时乙查询自己账户多了500。然后甲发现转错人了，回滚了转账。然后乙多出的500就没了。在这个过程中乙查到了没有提交的数据（多出的500），这就是脏读。

不可重复读(Non-repeatableRead)

不可重复读：事务A读取数据库中的数据后，事务B更新了数据，当A再次读取数据时，就会发现数据已经发生了改变，这就是不可重复读取。不可重复读取所导致的结果就是一个事务前后两次读取的数据不相同。重点在于update

示例：甲查询自己银行余额为1万，乙这个时候用甲的账号取走了3000，甲再一次查询余额，变成了7000。对甲而言两次结果不一致就是不可重复读。

产生“幽灵”数据（幻读）

幻读：如果事务T1基于某个条件读取数据后，另一个事务则更新了同一个表中的数据，这时第一个事务再次读取数据时，根据搜索的条件返回了不同的行，这就是幻读。重点在于insert

示例：甲查询自己银行明细中与乙的资金往来，之后乙向甲转了一笔账，甲再次查询发现比之前的查询多了一条新的记录，这就是幻读。

并发控制措施

控制目标：事务运行过程中尽可能隔离事务外操作对本事务数据环境的影响，保证操作的正确性和一致性

并发控制的主要技术——加锁(Locking)

• 加锁就是事务T在对某个数据操作之前，先向系统发出请求，封锁其所要使用的数据。在事务T释放它的锁之前，其他事务不能操作这些数据。

基本封锁类型

• 排它锁（X锁）
• 共享锁（S锁）

X锁（写锁）：若事务T对数据对象A加上X锁，则允许事务T读取和修改A，其它任何事务都不能再对A加任何类型的锁进行任何操作，直到事务T释放X锁，保证其他事务在事务T释放X锁之前不能再读取和修改数据。

S锁（读锁）：若事务T对数据对象A加上S锁，则事务T只能读A，但不能修改A，其它事务只能再对A加S锁，而不能加X锁，直到事务T释放A上的S锁为止。保证其他事务可以读数据，但是在事务T释放S锁前不能对数据做任何修改。

封锁协议

在运用X锁和S锁对数据对象进行加锁时，还需要约定一些规则，如何时申请X锁或S锁、持锁时间、何时释放锁等。称这些规则为封锁协议或加锁协议。

规则不同，封锁协议不同，达到的系统一致性级别不同。

一级封锁协议

规定：对事务T要修改的数据加X锁，直到事务结束（包括正常结束和非正常结束）时才释放。

效果：可以防止丢失修改。不能防止可重复读和不读“脏”数据。

1
2
3
4
5
6

![Pasted image 20240311152433](img/image-20240311152433.png)

1. 事务T1在读A进行修改之前先对A加**X锁**
2. 当T2再请求对A加X锁时被拒绝，T2只能等待T1释放A上的锁后才能获得对A的X锁
3. 这时T2读到的A已经是T1更新过的值15
4. T2按此新的A值进行运算，并将结果值A=14送回到磁盘。避免了丢失T1的更新

二级封锁协议

规定：一级封锁协议加上对事务T对要读取的数据加S锁，读完后即释放S锁。

效果：可以防止丢失修改、防止读“脏”数据，不能防止可重复读数据。

1
2
3
4
5

![Pasted image 20240311152632](img/image-20240311152632.png)

1. T1在对C进行修改前，先对C加X锁，修改后写回磁盘
2. T2想要读取数据的时候先请求C上加S锁，因T1已在C上加了X锁，T2只能等待
3. T1因某种原因被撤销，C恢复为原值100，T1释放C上的X锁后T2获得C上的S锁，读C=100。避免了T2读“脏”数据，

三级封锁协议

规定：一级封锁协议加上事务T对要读取的数据加S锁，并直到事务结束才释放。

效果：可以防止丢失修改、防止读“脏”数据、防止不可重复读，

1
2
3
4
5

![Pasted image 20240311152835](img/image-20240311152835.png)

1. T1读A，B前，先对A, B加S锁。其他事务只能再对A，B加S锁，而不能加X锁，即其他事务只能读A，B，而不能修改。
2. 当T2为修改B而申请B的X锁时被拒绝只能等T1释放B上的锁，T1为验算再读A，B，这时读出的B仍是100，求和结果仍为150，即可重复读。
3. T1结束才释放A，B上的S锁。T2才获得对B的X锁

死锁

死锁的预防

1
2
3

在操作系统中广为采用的预防死锁的策略并**不很适合数据库的特点**

DBMS 在解决死锁的问题上更**普遍采用的是诊断并解除死锁**的方法

产生死锁的原因：两个或多个事务都已封锁了数据对象，又都请求对已被其他事务封锁的数据对象加锁，从而出现死等待。

预防死锁的发生就是要破坏产生死锁的条件：一次封锁法、顺序封锁法。

一次封锁法

要求每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行。

存在的问题：

• 降低系统并发度。
• 难于事先精确确定封锁对象。

顺序封锁法

顺序封锁法是预先对数据对象规定一个封锁顺序，所有事务都按这个顺序实行封锁。

• 维护成本大：数据库系统中封锁的数据对象多，且在不断地变化。
• 难以实现：很难事先确定每一个事务要封锁哪些对象。

死锁的诊断与解除

超时法

如果一个事务的等待时间超过了规定的时限，就认为发生了死锁。

优点：实现简单。

缺点

• 时限设置过短，有可能误判死锁
• 时限设置太长，死锁发生后不能及时发现

等待图法

用事务等待图动态反映所有事务的等待情况：

事务等待图是一个有向图，每个结点表示正运行的事务，每条边表示事务等待的情况，若T1等待T2，则从T1指向T2划一条有向边，图中存在回路，则表示系统中出现了死锁。

解除死锁：

选择一个处理死锁代价最小的事务，将其撤消； 释放此事务持有的所有锁，使其它事务能继续运行。

并发调度的可串行性

可串行化调度：

• 多个事务的并发执行是正确的，当且仅当其结果与按某一次序串行地执行这些事务时的结果相同

可串行性：

• 并发事务正确调度的准则。
• 一个给定的并发调度，当且仅当它是可串行化的，才认为是正确调度。

两段锁协议

两段锁协议：指所有事务必须分两个阶段对数据项加锁和解锁。

第一阶段是获得封锁，也称为扩展阶段：

• 事务可以申请获得任何数据项上的任何类型的锁，但是不能释放任何锁。

第二阶段是释放封锁，也称为收缩阶段：

• 事务可以释放任何数据项上的任何类型的锁，但是不能再申请任何锁。

事务遵守两段锁协议是可串行化调度的充分条件，而不是必要条件。

数据库故障

两种：数据库本身被破坏或者数据库没有被破坏但数数据不正确。

事务内部的故障

事务内部故障指非预期的，不能由应用程序处理。例如：运算溢出，违反了某些完整性限制等。

事务故障的恢复：事务故障意味着事务没有达到预期的终点，数据库可能处于不正确状态，因此，要在不影响其它事务运行的情况下，撤销该事务已经做的对数据库的修改，使得该事
务好像根本没有运行一样。

事务故障的恢复操作：撤销事务（UNDO）

系统故障

系统故障称为软故障，是指造成系统停止运转的任何事件，使得系统要重新启动。 例如突然断电。

带来的问题：

• 整个系统的正常运行突然被破坏
• 所有正在运行的事务都非正常终止
• 数据库缓冲区的信息全部丢失；不破坏数据库。

发生系统故障时，事务未完成：强行撤消(UND0)所有未完成事务。

发生系统故障时，事务已提交，但缓冲区中的信息尚未完全写回到磁盘上：重做（REDO）所有已提交的事务。

其他故障

介质故障（磁盘损坏）：装入数据库发生介质故障前某个时刻的数据副本。重做自此时始（副本备份时刻）的所有成功事务，将这些事务已提交的结果重新记入数据库。

病毒：查杀病毒，安装防火墙或者实时监控软件。恢复数据库

数据库备份

恢复操作的基本原理：冗余

利用存储在系统其它地方的冗余数据来重建数据库中已被破坏或不正确的那部分数据

数据的恢复涉及两个关键问题：

1. 如何建立冗余数据：备份
2. 如何利用这些冗余数据实施数据库恢复。

数据备份是指定期或不定期地对数据库数据进行复制。备份的介质可以用磁盘。

备份的内容

备份数据（数据转储）

1. 表（结构），包含系统表、用户定义的表
2. 数据库用户（包括用户和用户操作权）
3. 用户定义的数据库对象和数据库中的全部数据
4. 备份日志（登记日志文件）

备份频率

要考虑两个因素：

• 出现故障时，允许丢失的数据量的大小。
• 数据库的事务类型（读多还是写多）以及事故发生的频率（经常发生还是不经常发生）。

通常情况下，数据库可以每周备份一次，事务日志可以每日备份一次。

对于一些重要的联机事务处理数据库，可以每日备份，事务日志则每隔数小时备份一次。

备份数据（数据转储）

数据转储：转储是指DBA将整个数据库复制到磁带或另一个磁盘上保存起来的过程，备用的数据称为后备副本或后援副本。

如何使用：数据库遭到破坏后可以将后备副本重新装入；重装后备副本只能将数据库恢复到转储时的状态。

备份方法：

1. 静态转储与动态转储
2. 海量转储与增量转储

==静态转储==：在系统中无运行事务时进行的转储操作，转储期间不允许对数据库的任何存取、修改活动。得到的是数据一致性的副本 。实现简单但降低了数据库的可用性。

==动态转储==：转储操作与用户事务并发进行，允许对数据库进行存取或修改。不会影响事务的运行，但不能保证副本中的数据正确有效。

==海量转储==：每次转储全部数据库。

==增量转储==：只转储上次转储后更新过的数据。

海量转储与增量转储比较：

• 从恢复角度看，使用海量转储得到的后备副本进行恢复往往更方便；
• 但如果数据库很大，事务处理又十分频繁，则增量转储方式更实用更有效。

登记日志文件

日志文件的格式和内容

日志文件(log)：用来记录事务对数据库的更新操作的文件。

日志文件的格式

• 以记录为单位的日志文件；
• 以数据块为单位的日志文件。

以记录为单位的日志文件（日志记录的组成）：

1. 事务标识
2. 事务的开始标记
3. 事务的结束标记
4. 事务的所有更新操作（类型、对象、更新前旧值、更新后新值）

以数据块为单位的日志文件的内容：

1. 事务标识
2. 被更新的数据块（更新前和更新后的）

日志文件的作用

• 进行事务故障恢复；
• 进行系统故障恢复；
• 协助后备副本进行介质故障恢复。

登记日志文件

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

必须先写日志文件，后写数据库：

• 写日志文件操作：将修改的记录写到日志文件
• 写数据库操作：把对数据的修改写到数据库中。

数据库恢复

恢复数据库是指将数据库从错误描述状态恢复到正确的描述状态（最近的正确时刻）的过程。

恢复策略

事务故障的恢复

事务故障：事务在运行至正常终止点前被终止。

恢复方法：利用日志文件撤消此事务已对数据库进行的修改。事务故障的恢复由系统自动完成，对用户是透明的，不需要用户干预。

步骤：

1. 反向扫描文件日志，查找该事务的更新操作。
2. 对该事务的更新操作执行逆操作。
3. 继续反向扫描日志文件，查找其他更新操作，同样处理。
4. 直至读到此事务的开始标记，事事务故障恢复就完成了。

系统故障的恢复

系统故障造成数据库不一致状态的原因：

• 未完成事务对数据库的更新已写入数据库
• 已提交事务的更新还留在缓冲区没来得及写入数据库

恢复方法：

1. 撤销故障发生时未完成的事务；
2. 重做已完成的事务。

系统故障的恢复由系统在重新启动时自动完成。

1. 正向扫描日志文件：
   • 重做队列 : 在故障发生前已经提交的事务；
   • 撤销队列 : 故障发生时尚未完成的事务；
2. 对撤销队列事务进行撤销处理
   • 反向扫描日志文件，对每个撤销事务执行逆操作。
3. 对重做队列事务进行重做处理
   • 正向扫描日志文件，对每个重做事务重新执行。

介质故障的恢复

1. 装入最新的后备数据库副本，使数据库恢复到最近一次转储时的一致性状态。
   • 利用静态转储的数据库副本，装入数据库后，系统处于一致性状态
   • 利用动态转储的数据库副本，还须同时装入转储时刻的日志文件副本，才能将数据库恢复到一致性状态。
2. 装入有关的日志文件副本，重做已完成的事务。
   • 首先扫描日志文件，找出故障发生时已提交的事务的标识，将其记入重做队列。
   • 然后正向扫描日志文件，对重做队列中的所有事务进行重做处理。

介质故障的恢复需要DBA介入。

• DBA的工作：重装最近转储的数据库副本和有关的各日志文件副本；
• 执行系统提供的恢复命令。

具体的恢复操作仍由DBMS完成。

恢复技术

利用备份技术

定期备份； 利用备份文件将数据库恢复到备份时刻的状态。

利用事务日志

利用事务日志可以恢复执行不完整的事务；恢复数据库到事务执行前的状态；系统自动完成。

数据库镜像

问题：

• 介质故障对系统影响严重，影响数据库的可用性。
• 介质故障恢复比较费时；
• 为预防介质故障，DBA必须周期性地转储数据库。

解决方案：数据库镜像（Mirror）

DBMS自动把整个数据库或关键数据复制到另一个磁盘上。
DBMS自动保证镜像数据与主数据库的一致性。
当主数据库更新时，DBMS自动把更新后的数据复制过去。

用途：
没有出现故障时：数据库镜像可用于并发操作。
出现介质故障时：

• 可由镜像磁盘继续提供使用
• 同时DBMS自动利用镜像磁盘数据进行数据库的恢复；
• 不需要关闭系统和重装数据库副本

频繁地复制数据自然会降低系统运行效率。只对关键数据和日志文件镜像，而不是对整个数据库进行镜像。

数据库设计概述

新奥尔良方法：

过程迭代和逐步求精。

基本步骤：

1. 需求分析（任务、调查重点是数据和处理）
2. 结构设计（概念、逻辑和物理结构设计）
3. 行为设计（功能、事务和程序设计）
4. 数据库实施（加载数据、调试运行等）
5. 数据库运行和维护

数据库需求分析

调查处理对象，了解原系统，明确新系统的功能，考虑以后可能的扩充和改变。

数据库结构设计

1. 概念结构设计：形成DB概念模式，用语义层模型描述，如E-R图
2. 逻辑结构设计：形成DB逻辑模式与外模式用结构层模型描述，例如基本表、视图等。
3. 物理结构设计：形成DB内模式，用文件级术语描述。例DB文件或目录、索引。

概念结构设计

自底向上：先定义局部应用的概念结构，然后按一定的规则把它们集成起来，从而得到全局概念模型。
自顶向下：先定义全局概念模型，然后再逐步细化。
由里向外：先定义最重要的核心结构，然后再逐步向外扩展
混合策略：将自顶向下和自底向上结合起来使用。

1. 设计局部E-R模型：E-R模型的设计内容包括确定局部E-R模型的范围、定义实体、联系以及它们的属性。
2. 设计全局E-R模型将所有局部E-R图集成为一个全局E-R图即全局E-R模型
3. 优化全局E-R模型

设计局部E-R模型

概念结构是对现实世界的一种抽象。所谓抽象是对实际的人、物、事和概念进行人为处理，抽取所关心的共同特性，忽略非本质细节，并把这些特性用各种概念准确的加以描述。一般有三种抽象方法：分类、概括、聚集

分类：在相似的个体之间提取共性，建立 “ 类 ” 的概念（集合）

• 个体与个体之间 ：具有相似的状态与行为，有相同的描述结构，相互用主码值区分。
• 个体与类之间 ：个体 Is a member of 类

两条准则：

1. 属性不能再具有需要描述的性质。即属性必须是不可分的数据项，不能再由另一些属性组成
2. 属性不能与其他实体具有联系 ，联系只发生在实体之间。

设计全局E-R模型

将局部E-R图集成为全局E-R图，需消除各分E-R图合并时产生的冲突。解决冲突是合并E-R图的主要工作和关键所在。

冲突主要有三类：

1. 属性冲突：属性域冲突、属性取值单位冲突
2. 命名冲突：同名异义和异名同义
3. 结构冲突：同一对象在不同应用中具有不同的抽象、同一实体在不同的局部E-R图中所包含的属性个数和属性的排列次序不完全相同。

优化全局E-R模型

实体个数尽可能少，实体所包含的属性尽可能少，实体间联系无冗余。

逻辑结构设计

逻辑结构设计的步骤：E-R图转化为关系模型，对数据模型进行优化，外模式的设计。

将实体型和实体间的联系转换为关系模式，并确定这些关系模式的属性和码

实体的转换原则：一个实体转换为一个关系模式。实体的属性就是关系的属性，实体的标识符就是关系的码。一个实体转换为一个关系模式、实体的名称对应关系模式的名称、实体的属性对应关系模式的属性、实体的候选码对应关系模式的候选码。

联系的转换原则：

对于实体间的联系有以下不同的情况：

• 一个1：1联系可以转换为一个独立的关系模式，也可以与任意一端所对应的关系模式合并。
• 一个1：n联系可以转换为一个独立的关系模式，也可以与n端所对应的关系模式合并。
• 一个m：n联系转换为一个关系模式。
• 三个或三个以上实体间的一个多元联系可以转换为一个关系模式。具有相同码的关系模式可以合并。

从理论上讲，1：1联系可以与任意一端对应的关系模式合并

但在一些情况下，与不同的关系模式合并效率会大不一样。因此究竟应该与哪端的关系模式合并需要依应用的具体情况而定。

由于连接操作是最费时的操作，所以一般应以尽量减少连接操作为目标。例如，如果经常要查询某个班级的班主任姓名，则将管理联系与教师关系合并更好些。

数据模型优化

1. 确定数据依赖，包括关系模式内部各属性之间的数据依赖不同关系模式属性之间数据依赖
2. 消除冗余的联系
3. 确定所属范式
4. 按照数据处理的要求，确定是否合并或分解。

注意：并不是规范化程度越高的关系就越优，一般说来，第三范式就足够了

常用分解优化方法：水平分解和垂直分解。

水平分解

以时间、空间、类型等范畴属性取值为条件，满足相同条件的数据行为一个子表。分解的依据一般以范畴属性取值范围划分数据行。这样在操作同表数据时，时空范围相对集中，便于管理。

垂直分解

以非主属性所描述的应用对象生命历程的先后为条件，对应相同历程的属性为一个子表。分解的依据是将非主属性按其数据生成的时间段划分，描述相同时间段的属性划分在一个组中。使操作同表数据时时空范围相对集中，但便于管理。

物理结构设计

物理结构设计的步骤：确定数据库的物理结构，对物理结构进行时间和空间效率的评价。

为关系模式选择 存取方法（建立存取路径）设计关系、索引等数据库文件的物理存储结构。

建立索引

一般用户可以通过建立索引的方法来加快数据的查询效率。建立索引的一般原则为：在经常作为查询条件、连接条件、分组条件，连接操作的属性上建立索引。

注意：一个表可以建立多个索引，但只能建立一个聚簇索引。

确定存储结构

一般的存储方式有：顺序存储、散列存储、聚簇存储

一般情况下系统都会为数据选择一种最合适的存储方式。