数据库复习

1 关系模式与关系数据库

1.1数据库的数据、逻辑、物理独立性

 数据独立性高

• 物理独立性
  指用户的应用程序与存储在磁盘上的数据库中数据是相互独立的。当数据的物理存储改变了，应用程序不用改变。
• 逻辑独立性
  指用户的应用程序与数据库的逻辑结构是相互独立的。数据的逻辑结构改变了，用户程序也可以不变。
• 数据独立性是由DBMS的二级映像功能来保证的

本质：希望不管怎么变，想不修改应用程序

1.2关系数据库三级模式、两级映像

数据库系统模式的概念

模式是数据库结构的描述、关系模式是表的结构的描述;

“型” 和“值” 的概念

型(Type)
对某一类数据的结构和属性的说明

值(Value)
是型的一个具体赋值
例如
学生记录型：
（学号，姓名，性别，系别，年龄，籍贯）
一个记录值：
（900201，李明，男，计算机，22，江苏）

模式（Schema）

数据库逻辑结构和特征的描述（数据模型是什么，表的结构、表之间的关系等等）
是型的描述，反映的是数据的结构及其联系
模式是静态的，相对稳定的，是数据库的蓝图或框架

一个数据库只有一个模式（三级模式中的概念模式）

实例（Instance）

模式的一个具体值
反映数据库某一时刻的状态
同一个模式可以有很多实例
实例随数据库中的数据的更新而变动

例如：在学生选课数据库模式中，包含学生记录、课程记录和学生选课记录

2003年的一个学生数据库实例，包含：
2003年学校中所有学生的记录
学校开设的所有课程的记录
所有学生选课的记录
2002年度学生数据库模式对应的实例与2003年度学生数据库模式对应的实例是不同的

数据库三级模式的结构和特征

1. 外部模式（External Schema）：

   • 定义：外部模式描述特定用户或应用程序可以看到和访问的数据库部分视图。它定义了用户视角的数据结构。
   • 特征：
     • 每个用户或应用程序可以有不同的外部模式，提供个性化的数据库视图。
     • 通过视图（Views）来实现。
     • 保障数据的安全性和隐私，用户只能访问授权的数据。

2. 概念模式（Conceptual Schema）：

   • 定义：概念模式描述数据库的全局逻辑结构，是对数据库中所有数据的整体描述，独立于物理存储细节。
   • 特征：
     • 包含所有实体、关系、属性及其约束。
     • 提供数据库的全局视图，隐藏了物理细节。
     • 确保数据的一致性和完整性。
     • 独立于任何特定用户视角。

3. 内部模式（Internal Schema）：

   • 定义：内部模式描述数据库在物理存储层面的实现细节，涉及数据存储结构、存储路径、索引、压缩和加密等技术。
   • 特征：
     • 关注数据在存储设备上的布局和组织方式。
     • 优化数据的存储和访问性能。
     • 涉及具体的存储结构和文件组织方式。
     • 包含存储分配、数据压缩、索引和访问方法等细节。

三级模式体系的优点

• 数据独立性：
  • 逻辑数据独立性：概念模式独立于外部模式，用户的视图变化不会影响概念模式。
  • 物理数据独立性：内部模式独立于概念模式，物理存储的变化（如存储结构优化）不会影响概念模式。
• 灵活性：能够根据不同用户或应用程序的需求定制不同的外部模式视图。
• 数据安全性：通过外部模式控制用户对数据的访问权限，保障数据安全性和隐私。

示例说明

假设有一个大学管理系统，其数据库设计如下：

• 外部模式：

  • 教师视图：包括教师信息和所教授的课程信息。
  • 学生视图：包括学生信息和所选课程信息。
  • 管理员视图：包括所有教师、学生和课程的详细信息。

• 概念模式：

  • 实体：教师（Teacher）、学生（Student）、课程（Course）。
  • 关系：教师教授课程（Teacher teaches Course）、学生选修课程（Student enrolls Course）。
  • 属性：教师ID、教师姓名、学生ID、学生姓名、课程ID、课程名称等。

• 内部模式：

  • 数据存储：教师、学生、课程表在磁盘上的具体存储方式。
  • 索引：在教师ID、学生ID、课程ID上创建索引以加速查询。
  • 存储结构：使用B树或哈希表来组织存储。

数据库的二级映像功能与数据独立性

三级模式是对数据的三个抽象级别

二级映象在DBMS内部实现这三个抽象层次的联系和转换

外模式／模式映像
模式／内模式映像

① 外模式／模式映象
模式：描述的是数据的全局逻辑结构
外模式：描述的是数据的局部逻辑结构

同一个模式可以有任意多个外模式
每一个外模式，数据库系统都有一个外模式／模式映象，定义外模式与模式之间的对应关系
映象定义通常包含在各自外模式的描述中
保证数据的逻辑独立性

当模式改变时，数据库管理员修改有关的外模式／模式映象，使外模式保持不变
应用程序是依据数据的外模式编写的，从而应用程序不必修改，保证了数据与程序的逻辑独立性，简称数据的逻辑独立性。

② 模式／内模式映象
模式／内模式映象定义了数据全局逻辑结构与存储结构之间的对应关系。

  例如，说明逻辑记录和字段在内部是如何表示的

数据库中模式／内模式映象是唯一的
该映象定义通常包含在模式描述中
保证数据的物理独立性

当数据库的存储结构改变了（例如选用了另一种存储结构），数据库管理员修改模式／内模式映象，使模式保持不变。
应用程序不受影响。保证了数据与程序的物理独立性，简称数据的物理独立性。

关系模式与关系r

关系模式是表的结构的描述

关系模式可以形式化地表示为：

R（U，D，DOM，F）
R 关系名
U 组成该关系的属性名集合
D 属性域

属性域定义了每个属性的取值范围或数据类型。例如，StudentID 的域可以是整数类型，Name 的域可以是字符串类型。

DOM 属性的取值范围

DOM(Ai​) 表示属性 Ai的取值范围，确保每个属性的值符合其定义的域。例如，DateOfBirth 的域可能是日期格式。

F 属性间的数据依赖关系集合

函数依赖是一组约束，表示在关系中某些属性的值决定了其他属性的值。例如，StudentID -> Name 表示学生ID唯一确定学生的名字。
·

关系模式通常可以简记为
R (U) 或 R (A1，A2，…，An)
R: 关系名
A1，A2，…，An : 属性名

关系
在关系型数据库中，"关系"和"表"通常可以互换使用。

1.3关系数据库的完整性约束：实体完整性、参照完整性、 自定义完整性

码（Key）：唯一标识实体的属性集称为码。例如学号是学生实体的码。又可以称为键。

候选码是最小的码集合，它可以唯一地标识数据表中的每一条记录，并且没有冗余的成分。换句话说，候选码是那些没有多余属性的码，不能再去掉任何属性而仍然保持其唯一性。

简单的情况：候选码只包含一个属性，最极端的情况：关系模式的所有属性组是这个关系模式的候选码，称为全码（All-key），若一个关系有多个候选码，则选定其中一个为主码（Primary key），所有的候选码的属性加起来称为主属性（Prime attribute），不包含在任何侯选码中的属性称为非主属性（Non-Prime attribute）或非码属性（Non-key attribute）。

三大完整性约束

实体完整性（Entity Integrity）

若属性A是基本关系R的主属性，则属性A不能取空值

例：
SAP(SUPERVISOR，SPECIALITY，POSTGRADUATE)
主码POSTGRADUATE 不能取空值

实体完整性规则的说明
(1) 实体完整性规则是针对基本关系而言的。一个基本表通常对应现 实世界的一个实体集。
(2) 现实世界中的实体是可区分的，即它们具有某种唯一性标识。
(3) 关系模型中以主码作为唯一性标识。
(4) 主码中的属性即主属性不能取空值。主属性取空值，就说明存在某个不可标识的实体，即存在不可区分的实体，这与第（2）点相矛盾，因此这个规则称为实体完整性

外码（Foreign Key）
设F是基本关系R的一个或一组属性，但不一定是关系R的码。如果F与基本关系S的主码Ks相对应，则称F是基本关系R的外码,即该码是另一个表的主码。
基本关系R称为参照关系（Referencing Relation），即本表。
基本关系S称为被参照关系（Referenced Relation） 或目标关系（Target Relation），即外码对应的主码所在的表。

• 关系R和S不一定是不同的关系
• 目标关系S的主码Ks 和参照关系的外码F必须定义在同一个（或一组）域上
• 外码并不一定要与相应的主码同名，当外码与相应的主码属于不同关系时，往往取相同的名 字，以便于识别

参照完整性规则

若属性（或属性组）F是基本关系R的外码它与基本关系S的主码Ks相对应（基本关系R和S不一定是不同的关系），则对于R中每个元组在F上的值必须为：

• 或者取空值（F的每个属性值均为空值）
• 或者等于S中某个元组的主码值
• 外码的值要么为空，要么为S中某个元组的主码值

 蓝色表示有参照关系，横线表示主属性

用户定义的完整性

• 针对某一具体关系数据库的约束条件，反映某一具体应用所涉及的数据必须满足的语义要求
• 关系模型应提供定义和检验这类完整性的机制，以便用统一的系统的方法处理它们，而不要由应用程序承担这一功能

2关系代数 

关系代数运算符

传统的集合运算

① 并（Union）

② 差（Difference）

③ 交（Intersection）

④ 笛卡尔积（Cartesian Product）

专门的关系运算 

① 几个记号

② 选择（Selection）

③ 投影（Projection）

④ 连接（Join）

❶ 左连接、右连接、外连接

⑤ 除（Division）

⑥ 综合举例

，“除”运算有以下几个主要作用：

1. 处理全包含查询

“除”运算最常见的作用是处理全包含查询，即查找那些在所有给定条件下都符合的记录。例如：

• 在学生选课的例子中，查找选修了所有必修课程的学生。
• 在销售数据中，查找那些在所有给定月份内都有销售记录的销售员。

2. 数据筛选和过滤

通过“除”运算，可以筛选出那些在特定条件下全部符合的记录。这在许多实际应用中非常有用，例如：

• 选出那些符合所有标准的产品。
• 找出在所有项目中都取得成功的员工。

3SQL语⾔

基本表的定义、删除与修改—TABLE

定义基本表的标准格式
CREATE TABLE <表名>(
      <列名> <数据类型>[ <列级完整性约束条件> ]
      [，<列名> <数据类型>[ <列级完整性约束条件>] ]
       ………
      [，<表级完整性约束条件> ]
 );

• 如果完整性约束条件涉及到该表的多个属性列，则必须定义在表级上，否则既可以定义在列级也可以定义在表级。

定义主码、定义外码

• 示例：
  
  

数据类型

• SQL中域的概念用数据类型来实现

• 定义表的属性时 需要指明其数据类型及长度

• 选用哪种数据类型

  • 取值范围
  • 要做哪些运算

• 以下是通用数据类型，不同数据库的数据类型可能有所不同，可查相关文档。

修改基本表

ALTER TABLE <表名>
[ ADD <新列名> <数据类型> [ 完整性约束 ] ]
[ DROP <完整性约束名> ]
[ ALTER COLUMN<列名> <数据类型> ]；

[例8]向Student表增加“入学时间”列，其数据类型为日期型。

• 不论基本表中原来是否已有数据，新增加的列一律为空值。

     ALTER TABLE Student ADD S_entrance DATE;

[例9]将年龄的数据类型由字符型（假设原来的数据类型是字符型）改为整数。

ALTER TABLE Student ALTER COLUMN Sage INT;

[例10]增加课程名称必须取唯一值的约束条件。

   		ALTER TABLE Course ADD UNIQUE(Cname);

删除基本表

标准格式：
DROP TABLE <表名>［RESTRICT| CASCADE］；

RESTRICT：删除表是有限制的。
欲删除的基本表不能被其他表的约束所引用（三类完整性约束，这里主要指参照完整性）
如果存在依赖该表的对象，则此表不能被删除（视图、索引、触发器）

CASCADE：删除该表没有限制。
在删除基本表的同时，相关的依赖对象一起删除

数据库设计

 一、数据库设计的必要性

         在实际的软件项目中，如果系统中需要存储的数据量比较大，需要设计的表比较多，表与表之间的关系比较复杂，那我们就需要进行规范的数据库设置。如果不经过数据库的设计，我们构建的数据库不合理、不恰当，那么数据库的维护、运行效率会有很大的问题。这将直接影响到项目的运行性和可靠性。

二、什么是数据库设计

      数据库对象包含表、索引、图表等等。

      数据库设计实际上就是规划和结构化数据库中的数据对象以及这些数据对象之间的关系过程。

三、数据库设计的重要性

      Ø 不经过设计的数据库或是设计糟糕的数据库很可能导致

            1、 数据库运行效率地下

            2、 更新、删除、添加数据出现问题

      Ø 良好设计的数据库

             1、 执行效率高

             2、 使应用程序更便于开发

             3、 扩展性好

             4、 维护性好

四、数据模型

       数据模型就像是数据间联系的一个轮廓图，整个模型就像一个框架。

       如果按照数据间联系的表示方式，对数据模型进行分类，可以分为：层次模型、网状模型、关系模型。前两种又称为格式化数据模型。数据模型的好坏直接影响到数据库的性能，所以数据模型的选择是数据库设计的首要任务。一般选实体-关系（E-R）数据模型。

       Ø 实体-关系（E-R）数据模型

              E-R数据模型（Entity-Relationship data model），即实体-关系数据模型。E-R数据模型不同于传统的关系数据模型，它不是面向实现，而是面向现实物体的。

       Ø 实体（Entity）

              数据是用来描述现实中的物体的，而描述的对象都是形形色色的，有具体的、也有抽象的；有物理上存在的、也有概念性的。凡是可以互相区别而且可以被人们认识的事、物、概念等统统抽象为实体。多个相同的类型的实体可以称为实体集（Entity set）。因此，在E-R数据模型中，也有型与值之分；实体可以作为型来定义，每个实体可以是它的实例和值。

       Ø 属性（Attribute）

              实体一般具有若干特征，这些特征称为实体的属性。而每个属性都有自己的取值范围，在E-R数据模型中称为值集（value set）。在同一实体集中，每个实体的属性及其值集都是相同的，但可能取不同的值。属性对应数据库表的列。

在一个实体中，能够惟一标识实体的属性或属性集称为“实体标识符”

       Ø 联系（Relationship）

              实体之间会有各种关系，这些关系抽象为联系。不但实体可以有属性，关系也可以有属性。

       Ø 联系的元数

              一个联系涉及到的实体集个数，称为该联系的元数或度数（Degree）

• 一元联系（递归联系）：同一个实体集内部实体之间的联系

• 二元联系: 两个不同实体集实体之间的联系

• 三元联系: 三个不同实体集实体之间的联系

五、数据库设计步骤

       Ø 数据库设计可以分为以下几个阶段

              1、 需求分析阶段：分析客户的业务需求，特别是数据方面的需求

              2、 概要设计阶段：绘制数据库的E-R图，并确认需求文档的正确性和完整性，E-R图是项目的设计人员、开发人员、测试人员，以及和客户进行沟通的重要凭据

              3、 详细设计阶段：将概要设计阶段的E-R图转换为数据库表，进行逻辑设计，确定各个表之间的主外键关系，运用数据库的三范式进行审核，并进行技术评审。最后决定选哪种数据库（Oracle、SQLServer、MySQL）来建库、建表。

       Ø 需求分析阶段：数据库系统分析

              需求分析阶段的重点是调查、收集、分析客户的业务数据需求以及数据的安全性、完整性需求等。

       需求分析步骤：

              1、 确认业务需求

              2、 标识关系实体

              3、 标识每个实体的具有的属性

              4、 确认实体之间的关系

       Ø 概要设计阶段：绘制E-R图

              作为数据库设计者，你需要和项目组内其他成员分享你的设计思路，共同研讨数据库设计的合理性、安全性、完整性，并确认是否符合客户的业务需求。那么使用E-R图，这种图形化的表示方式最为直观。

              * E-R图中的实体、属性和关系

                     

              上面的简单E-R图可以看出用户和收支之间的关系。在上图中可以看出：用矩形表示实体，实体是一般名词；椭圆表示属性，一般也是名词；菱形表示关系，一般是动词。

              * E-R图

              E-R图可以以图形化的方式将数据库的整个逻辑结构表示出来，组成部分有：

                     1、 矩形表示实体集

                     2、 椭圆表示属性

                     3、 菱形表示联系

                     4、 直线用来连接实体集与属性、实体集和联系

                     5、 直线箭头表示实体集之间映射基数

           【P6】ER图_哔哩哔哩_bilibili

            实体间的联系

            1对1联系：1个A对应1个B

            1对n联系：1个A对应n个B

            n对m联系：n个A对应m个B

            

           E-R图转换为关系模型

           第一步：将各个实体的名字转换为各个关系模式的名字

           第二步：实体的属性就是关系的属性，实体的码就是关系的码

           第三步：实体间联系的转换   

           1对1联系：在任意一方加入对方的主码并设为其外码，并加入联系本身的属性

           1对n联系：将1方的主码加入n方作为外码，并同时将联系的属性加入n方

           n对m联系：将联系本身转换为一个关系模式，将联系双方的主码加入其中设为码，并将联系的属性也加入其中

聚簇索引（Clustered Index）

1. 定义：聚簇索引是一种物理排序方式，其中数据记录按照索引的顺序存储在表中。每个表只能有一个聚簇索引，因为表中的数据行只能有一种物理顺序。

2. 优点：

   • 查询效率高：特别适用于范围查询和顺序扫描。
   • 数据读取速度快：由于数据按索引顺序存储，减少了磁盘I/O操作。

3. 缺点：

   • 更新开销大：插入、删除和更新操作可能需要重排数据，导致性能下降。
   • 占用大量空间：索引和数据存储在一起，占用较多的存储空间。

二级索引（Secondary Index）

1. 定义：二级索引又称非聚簇索引，存储的是索引键和对应数据行的指针。数据在表中的物理顺序不受索引影响，可以有多个二级索引。

2. 优点：

   • 灵活性高：可以为表中的多个列创建二级索引，适应不同的查询需求。
   • 更新开销相对较小：因为数据物理顺序不变，更新操作主要涉及索引本身的调整。

3. 缺点：

   • 查询效率相对较低：每次查询需要通过索引查找到数据行的指针，再根据指针访问数据行，增加了I/O操作。
   • 占用额外空间：索引需要额外的存储空间来维护索引键和数据行指针。

B+树索引（B+ Tree Index）

1. 定义：B+树是一种平衡树数据结构，常用于实现数据库中的聚簇索引和二级索引。B+树的每个节点包含多个键值和指针，叶子节点通过指针相互连接，形成一个双向链表。

2. 优点：

   • 平衡性好：B+树保持高度平衡，确保所有叶子节点在同一层，查询时间复杂度为O(log n)。
   • 支持范围查询：叶子节点间的双向链表使得顺序访问和范围查询非常高效。
   • 插入和删除效率高：B+树的分裂和合并操作使其能够快速调整结构，维持平衡。

3. 缺点：

   • 实现复杂：B+树的插入、删除和查找算法相对复杂。
   • 维护开销大：特别是在数据频繁变动的情况下，维护B+树的平衡需要额外的计算和I/O开销。

总结

• 聚簇索引适用于需要高效范围查询和顺序扫描的场景。
• 二级索引适用于需要为多个列创建索引以满足不同查询需求的场景。
• B+树索引作为常见的实现方式，提供了平衡的查询和维护性能，广泛应用于数据库系统中。

关系模式规范化

函数依赖
专业定义：设R(U)是一个属性集U上的关系模式，X和Y是U的子集。若对于R(U)的任意一个可能的关系r，r 中不可能存在两个元组在X上的属性值相等， 而在Y上的属性值不等， 则称“X函数确定Y”或“Y函数依赖于X”，记作X→Y。

案例演示：在关系Student(Sno, Sname, Ssex, Sage, Sdept)，假设不允许重名，有:

Sno → Sname
Sno → Ssex
Sno → Sage
Sno → Sdept
Sname → Sno
Sname → Ssex
Sname → Sage
Sname → Sdept
平凡函数依赖
专业定义：X→Y，但Y⊆X 则称X→Y是平凡的函数依赖。

由于整体（X）可以确定其部分（Y），这种依赖总是存在的，因为部分总是由整体决定的，这就是为什么称之为“平凡”的原因。因此若不特别声明， 我们总是讨论非平凡函数依赖

非平凡函数依赖
专业定义：X→Y，但Y⊈X则称X→Y是非平凡的函数依赖。

这种依赖关系不是基于子集这一逻辑上的包含关系，而是需要通过数据的内在联系来确定，因此被认为是“非平凡”的。

完全函数依赖
专业定义：

案例演示：在关系SC(Sno, Cno, Grade)中，有：

部分函数依赖
专业定义：

案例演示：在关系SC(Sno, Cno, Grade)中，则有：

传递函数依赖
专业定义：

案例演示：在关系Std(Sno, Sdept, Mname)中，有：

Sno → Sdept ， Sdept → Mname
6.2、码

注意：所有候选码的属性合起来为主属性，不是候选码的属性为非主属性。 

      Ø 数据库设计中经常出现的问题

            1、 数据冗余大

            2、 插入数据异常

            3、 删除异常

            4、 更新异常

      Ø 规范设计

              一个低一级范式的关系模式,通过模式分解(后面会介绍)可以转换为若干个高一级范式的关系模式的集合,这种过程就叫规范化(normalization) .

          数据库第6章 关系数据理论（第二部分：范式理论 BCNF)_哔哩哔哩_bilibili

首先，需要判断关系模式中的候选码、主属性、非主属性

怎么判断？

枚举，视频中有。

1、 第一范式（1NF）

      关系中的每个属性必须是不可再分的简单项，不能是属性组合，即属性的取值是不可拆分的原子值。

      换句话说，不能表中有表。       

 2、 第二范式（2NF）

      非主属性不存在对主属性的部分函数依赖。

      如何规范化？

     从部分函数依赖中找到非主属性部分依赖的主属性，并将这个主属性大哥复制，连同它的非主属性小弟新建一个关系模式。

3、 第三范式(3NF)

     非主属性不存在对主属性的传递函数依赖。

     如何规范化？

     将传递函数依赖中的桥梁复制，带着它的非主属性小弟新建一个关系模式

4、 BCNF

      主属性之间不存在部分函数依赖和传递函数依赖。

      两种方式判断：

      1 看箭头左侧是否都包含候选码，如果有一个没有则不满足BCNF

       2 直接看主属性之间是否有存在部分函数依赖和传递函数依赖

      如何规范化？

     从部分函数依赖中找到主属性部分依赖的主属性，并将这个主属性大哥复制，连同它的主属性小弟新建一个关系模式。

      Ø 规范化和性能关系           

     为了满足三大范式，数据库的性能可能会有一定程度的降低。所以，在实际数据库设计中，我们既要尽量满足三大范式，从而避免数据冗余和各种数据库的操作异常，同时也要考虑数据的访问性能。有时候，为了提高数据库的访问效率，适当的允许少量数据冗余咧存在，才是最适合的数据库设计方案。

封锁及封锁协议

1、封锁的定义

• 概念：事务T在对某个数据对象例如表、记录等操作之前，先向系统发出请求，对其加锁。加锁后事务T就对该数据对象有了一定的控制，在事务T释放它的锁之前，其他事务对该数据的操作受到一定限制。

2、基本的封锁类型

• 排它锁（Exclusive Locks，简称X锁，也称写锁）

• 共享锁（Share Locks，简称S锁，也称读锁）

3、封锁协议包含的内容

• 什么操作需要申请何种锁？----排它锁、共享锁

• 何时加锁？----事务开始前、操作前

• 何时解锁？----操作结束后、事务结束前

• 对于等待的理解，当这条指令要访问被上锁的资源，则就进入等待状态。

4、封锁协议的分类

• ==一级封锁协议==

  事务T在修改数据R之前，必须先对R加X锁，直到事务结束才释放。事务结束包括正常结束（COMMIT）和非正常结束（ROLLBACK）

  ==一级封锁协议不加S锁==

  

• ==二级封锁协议==

  在一级封锁协议的基础上，加上事务T在读取数据R之前必须先对其加S锁，读完后即可释放S锁

  

• ==三级封锁协议==

  在一级封锁协议的基础上，加上事务T在读取数据R之前必须先对其加S锁，直到事务结束才释放

  

• ==一二三级封锁协议的一致性保证==

  

5、并发调度的可串行性

• 调度的正确性：

  • 能将数据库置于一致状态的调度一定是正确的调度

  • 将所有事务串行起来的调度策略一定是正确的调度（因为每个事务都会保证一致性状态，故事务串行一定会保证一致性）

  • 与串行调度等价的调度是正确的调度

• 并发事务的正确性准则：多个事务的并发执行是正确的，当且仅当其结果与某一次序串行地执行它们时的结果相同，我们称这种调度策略为可串行化的调度。

  

  

16.4 两段锁协议

• 概念：所有事务必须分两个阶段（获得阶段和释放阶段，亦即扩展阶段和收缩阶段）对数据项加锁和解锁。

  • 获得封锁：在对任何数据进行读、写操作之前，首先要申请并获得对该数据的封锁；

  • 释放封锁：==在释放一个封锁之后，事务不再申请和获得任何其他封锁。==

    例子：

    

• ==两段锁协议是可串行化的充分条件，而不是必要条件==

• 一次封锁法遵守两段锁协议，但两段锁协议不要求事务必须一次将所有要使用的数据全部加锁，因此遵守两段锁协议的事务可能发生死锁。

  例子：

  

• 三级封锁是两段锁的一种，因为三级封锁都是事务结束再释放锁，事务结束后显然事务不会再申请和获得任何其他封锁。

• 活锁和死锁

  • 活锁（饥饿）：某一个事务无限等待。解决方法：先来先服务

  • 死锁：两个或多个事务都已封锁了一些数据对象，然后又都请求对已被其他事务封锁的数据对象加锁，从而出现死等待。

  • 解决死锁：

    • 预防：破坏死锁产生的四个必要条件（互斥、请求和保持、不可剥夺、循环等待）。几个方法：静态申请法，一次性申请所有资源，资源的利用率不高；延迟进程的执行，能够获得所有资源时才允许执行，并发度不好；有序资源分配法，给资源编号

    • 避免：类似os中的银行家算法，在资源分配之前进行检查，防止死锁的发生

    • 诊断与解除

      • 死锁的诊断：

        • 超时法：超过规定的时间就认为发生死锁。

          不足：可能误判死锁，也可能不能及时发现死锁

        • 等待图法：以事务为结点，边表示事务等待的情况，若T1等待T2，则 T1→T2。系统周期性地检测事务等待图，若图中存在回路，则出现死锁。

      • 死锁的解除：选择一个处理死锁代价最小的事务，撤销。对撤销的事务所执行的数据修改操作必须加以恢复。

16.5 封锁的粒度

• 封锁的粒度：指封锁对象的大小，封锁的粒度包括整个数据库、关系、元组、索引

• 封锁粒度的选择：选择封锁粒度时应该同时考虑并发度和开销两个因素。==封锁粒度越大，并发度越小，系统开销越小。==

• 多粒度封锁

  • 概念：在一个系统中同时支持多种封锁粒度供不同的事务选择。

    多粒度封锁协议允许多粒度树中的每个结点被独立地加锁。对每个结点的加锁意味着这个结点的所有后裔结点也被加以同样类型的锁。

  • 显式封锁：应事务的要求直接加到数据对象上的封锁

  • 隐式封锁：该数据对象没有独立加锁，是由于其上级结点加锁而使该数据对象加上了锁

  • 判断能否对一个数据对象加锁：

    • 检查该数据对象有无显式封锁与之冲突；

    • 检查其所有上级结点，看本事务的显式封锁是否与该数据对象上的隐式封锁冲突；

    • 检查其所有下级结点，看上面的显式封锁是否与本事务的隐式封锁冲突。

      不需要检查下级结点的隐式封锁，因为有隐式封锁肯定可以向上找到显式封锁

• ==意向锁==

  • 概念：如果对一个结点加意向锁，则说明该结点的下层结点正在被加锁；对任一结点加锁时，必须先对它的（所有）上层结点加意向锁。

  • 意向共享锁（简称IS锁）：如果对数据对象加IS锁，表示它的后裔结点拟加S锁

  • 意向排它锁（简称IX锁）：如果对数据对象加IX锁，表示它的后裔结点拟加X锁

  • 共享意向排它锁（简称SIX锁）：如果对数据对象加SIX锁，表示先加S锁，再加IX

    eg. 对某个表加SIX锁，表示该事务要读整个表（所以要对该表加S锁），同时会更新个别元组（所以要对该表加IX锁）

    

    加锁是从上往下的

IS锁和IX锁是相容的，因为最终会转化到下层结点，如果最终S锁和X锁加到了同一个对象上，那么在这个对象上的这两个锁是不相容的；如果没有加到同一个对象上，那么IS锁和IX锁就不会出现问题。

16.6 隔离级别（四种）

• 未提交读（读未提交， read uncommitted）：事务隔离的最低级别，一个事务可以读到另外一个事务未提交的数据，不允许丢失修改，接受读脏数据和不可重复读现象。

• 提交读（读已提交， read committed）：SQL Server 默认级别。若事务还没提交，其它事务不能读取该事务正在修改的数据。不允许丢失修改和读脏数据，接受不可重复读现象。

• 可重复读（repeatable read）：事务多次读取统一数据对象的结果一致。不允许丢失修改、读脏数据和读不一致，接受幻影读现象。

• 可串行读（serializable）：事务隔离的最高级别，保证可串行化，不允许丢失修改、读脏数据、读不一致以及幻影读现象的发生。

• 隔离级别允许不同类型的行为：

  隔离级别	丢失修改	脏读	不可重复读取	幻像
  未提交读	否	是	是	是
  提交读	否	否	是	是
  可重复读	否	否	否	是
  可串行读	否	否	否	否

• 设置隔离级别的语法

  set transaction isolation level
  {
      read committed | 
      read uncommitted |
      repeatable read |
      serializable read
  }

16.7 数据库恢复

• 概念：把数据库从错误状态恢复到某一个已知的正确状态（亦称为一致状态或完整状态）的功能。

• 目标：在故障发生时，确保事务的原子性和持久性

• 特点：因为DB与内存用户工作区之间的数据交换是通过缓冲区进行的，而这个交换一般是以缓冲区是否满来触发的。因此，有可能提交事务的数据仍在缓冲区而没有写到DB中，而未提交事务的数据却写到了DB中。所以，故障恢复时，可能既要REDO已经提交了的事务，又要UNDO未提交的事务，以保证事务的原子性

• 技术

  DBMS提供备份机制、日志机制、检查点机制来协助数据库故障恢复;

  ==基本原理：数据冗余。==

• ==数据转储：==DBA定期地将整个数据库复制到磁带或另一个磁盘上保存起来的过程。这些备用的数据文本称为后备副本或后援副本。

  数据转储的分类：

  • 按照转储时的状态可以分为静态转储和动态转储。静态转储是指在系统中无运行事务时进行的转储操作。动态转储是指转储期间允许对数据库进行存取或者修改，但此时需要把转储期间各事务对数据库的修改记录在日志文件中，从而将来可以恢复

  • 按方式不同可以分为海量转储和增量转储。海量转储是指每次转储全部数据库。增量转储是指每次只转储上一次转储后更新的数据库。

  

• ==登记日志文件==：记录事务对数据库的更新操作

  日志文件的格式：以记录为单位的日志文件和以数据块为单位的日志文件。

  • 以记录为单位的日志文件：一个日志记录包括每个事务的开始标志（BEGIN TRANSACTION）、结束标志（COMMIT 或 ROLLBACK）、每个更新操作

  • 以数据块为单位的日志文件：包含事务标识和被更新的数据块

  

  登记日志文件的原则：

  • 登记的次序按并发事务执行的时间次序

  • 必须先写日志文件，后写数据库==（日志先写原则）==

• 系统故障的恢复实现策略

  • 系统故障导致的数据库不一致 （1）未完成的事务对DB产生影响 （2）已完成的事务在缓冲区的内容未写入DB

  • 恢复功能 （1）UNDO未完成的事务 （2）REDO已完成的事务

  • 恢复步骤 （1）正向扫描日志文件，建立UNDO和REDO队列；（不需要redo日志中所有已完成的事务） （2）反向扫描日志文件，对每个UNDO事务的更新执行逆操作； （3）正向扫描日志文件，对每个REDO事务的更新重新执行。

• ==检查点技术：==

  当事务正常运行时，数据库系统按一定的时间间隔设检查点。一旦系统需要恢复数据库状态，就可以根据最新的检查点的信息，从检查点开始执行，而不必从头开始执行那些被中断的事务。

  系统在检查点做的动作主要如下：

  • 暂时中止现有事务的执行

  • 在日志中写入检查点记录，并把日志强制写入磁盘

  • 把主存中被修改的数据缓冲区强制写入磁盘

  • 重新开始执行事务

  例子：