- 绪论
- 理解数据库的4个基本概念:数据、数据库、数据库管理系统、数据库系统;(P4~5)
(1)数据(data):描述事物的符号记录称为数据。数据与其语义是不可分的。
(2)数据库(DataBase,简称DB):长期存储在计算机内的、有组织的、可共享的大量数据的集合。
(3)数据库管理系统(Database Management System,简称DBMS):是一个系统软件(和操作系统一样是计算机的基础软件),用于科学地组织和存储数据,高效地获取和维护数据。
主要功能:
1)数据定义-创建、删除或修改数据库对象
- DDL(如Create, Drop, Alter)
2)数据操纵-对数据库进行查询或更新
- DML(如Select, Delete, Insert, Update)
3)数据库的事务管理和运行管理
-并发控制、系统恢复、安全性、完整性检查等
4)数据库的建立和维护、组织和存储
-初始数据的输入、存储和管理各种数据(数据字典、用户数据)、数据转换、性能监视等
- 数据库系统(DataBase System,简称DBS):是采用了数据库技术的计算机系统, 包括:数据库DB、数据库管理系统DBMS、应用系统、数据库管理员DBA等。
数据管理技术的发展:人工管理阶段、文件系统阶段、数据库系统阶段。
- 理解概念模型在数据库设计中的作用,理解相关概念,尤其是联系的类型;(P17)
(1)实体(Entity)
客观存在并可相互区别的事物称为实体。
(2)属性(Attribute)
实体所具有的某种特性,一个实体可由若干属性来刻画。
(3)码(Key)
唯一标识实体的属性集称为码。
(4)域(Domain)
属性的取值范围称为该属性的域。
(5)实体型(Entity Type)
具有相同属性的实体具有共同的特性和性质。
用实体名及其属性名集合来抽象和刻画同类实体,
称为实体型。
(6)实体集(Entity Set)
同型实体的集合称为实体集。
(7)联系(Relationship)
现实世界中事物之间的联系在信息世界中反映为实体型之间的联系。实体型之间的联系通常指不同实体集之间的联系。
两个实体型间的联系
一对一联系
如果对于实体集A中的每一个实体,实体集B中至多有一个实体与之联系,反之亦然,则称实体集A与实体集B具有一对一联系。记为1:1。
实例:班级与班长之间的联系
一对多联系
如果对于实体集A中的每一个实体,实体集B中有n个实体(n≥0)与之联系,反之,对于实体集B中的每一个实体,实体集A中至多只有一个实体与之联系,则称实体集A与实体集B有一对多联系。记为1:n
实例:班级与学生之间的联系
多对多联系
如果对于实体集A中的每一个实体,实体集B中有n个实体(n≥0)与之联系,反之,对于实体集B中的每一个实体,实体集A中也有m个实体(m≥0)与之联系,则称实体集A与实体集B具有多对多联系。记为m:n
实例:课程与学生之间的联系。
*应用系统开发的哪个阶段需要使用概念模型?
*实体、实体型、实体集有何区别?
- 了解数据库领域主要的逻辑模型有哪些?(P18)
层次模型 (Hierarchical Model)
网状模型 (Network Model)
关系模型 (Relational Model)
- 理解数据库系统的三级模式结构,掌握各模式的含义、别名及其与数据库对象的对应关系;(P28~29)
- 模式(定义见课本),也叫逻辑模式,对应数据库中的基本表;
模式:也称逻辑模式,是数据库中全体数据的逻辑结构和特征的描述。
一个数据库只有一个模式。
- 外模式(定义见课本),也叫用户模式或子模式,对应数据库中的视图;
外模式:也称子模式或用户模式,是数据库中局部(用户)数据的逻辑结构和特征的描述。
1)外模式通常是模式的子集。
2)一个数据库可以有多个外模式。
3)一个应用程序只能使用一个外模式。
4)多个应用程序可共用一个外模式。
- 内模式(定义见课本),也叫存储模式,对应数据库中的数据文件。
内模式:也称存储模式,是数据物理结构和存储方式的描述。
- 理解为什么数据库的二级映像能够保证数据的逻辑独立性和物理独立性;(P30)
逻辑独立性:当数据的逻辑结构修改时,应用程序不用改变;
物理独立性:当数据的存储结构修改时,应用程序不用改变。
1 外模式/模式映像
对于每一个外模式,都有一个外模式/模式映像,它定义了该外模式与模式间的对应关系;映像定义包含在外模式中;保证数据的逻辑独立性 。
2. 模式/内模式映像
定义了模式与内模式的对应关系;映像定义包含在模式中;保证数据的物理独立性。
- 理解数据库系统(DBS)的组成情况;(P31)
数据库系统一般由数据库、数据库管理系统(及其开发工具)、应用系统、数据库管理员和用户构成。
- DB
- DBMS
- 应用程序
- DBA等
- 关系数据库
- 理解相关基本概念:关系、元组、分量、候选码、主码、主属性、非主属性、全码(P38~40);
笛卡尔集(Cartesian Product):给定一组域D1,D2,…,Dn,则其笛卡尔积为:
D1×D2×…×Dn={(d1,d2,…,dn)|di∈Di,i=1,2,…,n}
(1)关系:D1×D2×…×Dn的子集称为在域D1,D2,…,Dn上的关系,记为:R(D1,D2,…,Dn) 。
关系也是一个二维表,
表的每行对应一个元组,表的每列对应一个域;
域可以相同,为了加以区分,必须对每列起一个名字,称为属性。
(2)元组:其中每一个元素(d1,d2,…,dn)叫做一个n元组,或简称为元组。
(3)分量:元素中每个值di称为分量。
一个域允许的不同取值个数称为这个域的基数。区别:属性的个数称为元数。
(4)全码:关系模式的所有属性组成的候选码。
(5)外码:关系R中的某个属性组不是R的候选码,但它与另一个关系S的候选码对应,则这个属性组为R的外码。
要求能够联系实例,分析下列元素的构成情况。
- 候选码:唯一标示一条元组的极小属性组。
- 主码:若候选码有多个,可以任意选择一个候选码作为主码;
- 主属性:包含在任何候选码中的属性;
- 非主属性:不包含在任何候选码中的属性;
- 理解关系和关系模式的联系与区别、表示方法(P42~43);
关系模型由关系数据结构、关系操作集合和关系完整性约束三部分组成。
关系模式是型(表头),关系是值(表)。
(1)关系的类型:基本关系(基本表)、查询表(查询结果对应的表)、视图(由基表或其他视图导出的虚表);
(2)关系模式:关系的描述称为关系模式。
关系模式通常可以简记为R(A1,A2,…,An),其中R为关系名,A1,A2,…,An为属性名。
(3)关系数据库
其值是某一时刻关系的集合,通常就称作关系数据库。
其型是关系模式的集合,是数据库描述,称作关系数据库模式。
- 理解关系模型的三类完整性约束及其作用(P45~48);
- 实体完整性;
(1)实体完整性
实体完整性规则:若属性A是基本关系R的主属性,则属性A不能取空值。
- 参照完整性;
(2)参照完整性规则 :若属性(或属性组) F 是基本关系 R 的外码,它与基本关系 S 的主码 Ks 相对应(基本关系R和S不一定是不同的关系),则对于 R 中每个元组在 F 上的值必须为:
1)或者取空值(F的每个属性值均为空值);
2)或者等于S中某个元组的主码值。
- 用户定义的完整性。
(3)用户针对具体应用问题定义的完整性约束条件。
实体完整性和参照完整性由系统自动支持;
- 熟练掌握关系代数的各类运算,包括:并、差、交、笛卡尔积、选择、投影、连接和除运算,能够灵活利用关系代数实现特定问题的查询(P48~57);
- SQL(重点!)
- 掌握利用create table语句定义表的方法、利用alter table语句修改表结构的方法、利用drop table语句删除表的方法;
- 熟练掌握单表查询(尤其是各种集函数的用法)、连接查询、嵌套查询的实现方法;
- 熟练掌握插入数据、修改数据、删除数据的方法;
- 注意:字符串常量外需要打上单引号,数值型常量不需要打单引号。
- 掌握建立视图的方法(P121)。
视图的特点:
虚表,是从一个或几个基本表(或视图)导出的表;
只存放视图的定义,不存放视图对应的数据;
基表中的数据发生变化,从视图中查询出的数据也随之改变;
视图一经定义,可以和基本表一样被查询。但对视图的更新操作则有一定的限制。
语句格式
CREATE VIEW
<视图名> [ ( <列名> [,<列名>] … ) ]
AS <子查询>
子查询可以是任意复杂的SELECT语句,但通常不允许含ORDER BY子句。
注:一些视图是不可更新的,因为对这些视图的更新不能唯一地有意义地转换成对相应基本表的更新。
视图的作用:
1)视图能够简化用户的操作
2)视图能够对机密数据提供安全保护
3)视图对重构数据库提供了一定程度的逻辑独立性
4)利用视图可以更清晰地表达查询
- 数据库安全性(不考)
- 数据库完整性(5.1节~5.3节)
- 掌握数据库完整性约束定义的方法;
(1)实体完整性
实体完整性在CREATE TABLE中用PRIMARY KEY定义。
根据主码的属性的构成情况可以定义为列级约束或表级约束。
(2)参照完整性
参照完整性在CREATE TABLE中用FOREIGN KEY定义哪些列为外码,用REFERENCES指明参照哪个表的主码。
(3)用户定义的完整性
在CREATE TABLE中根据应用要求,定义数据必须满足的语义要求,包括:
NOT NULL:列值非空
UNIQE:列值唯一
CHECK:检查列值是否满足一个布尔表达式
- 理解DBMS进行完整性检查的时机以及DBMS进行违约处理的手段。
(1)实体完整性检查和违约处理
当用户对基本表插入一条元组或对主码列进行更新时,DBMS将按实体完整性规则自动进行检查。包括:
检查主码各属性是否为空,有一个为空就拒绝插入或修改。
主码值是否唯一,如果不唯一则拒绝插入或修改;
(2)参照完整性检查和违约处理
DBMS的违约处理:可有三种策略
拒绝(NO ACTION):一般设置为默认策略。
级联操作(CASCADES,更新被参照表时)
更新被参照表时若发生不一致情况,则同时更新参照表。
置空值(SET NULL,更新被参照表时)
更新被参照表时若发生不一致情况,则将参照表相应属性设为空值。
(3)约束条件检查和违约处理
当向表中插入元组或修改属性值时,DBMS检查属性或元组上的约束条件是否满足,若不满足则操作被拒绝执行。
3.触发器(Trigger)
作用:可以实现比约束更为复杂的检查或操作,用来控制数据的完整性。
触发器是一种特殊的存储过程,它不能被显式地调用, 而是在往表中插入记录、更改记录或者删除记录,当事件发生时,才被自动地激活,响应同时执行一定的操作。
create trigger <触发器名> on <表名>
after | instead of
insert,update,delete --触发事件
as <sql语句> --执行操作
- 关系数据理论(重点!)
- 设计不好的关系模式存在的问题有哪些?能够举例说明。(P179,建议回顾课件上的例子)
- 数据冗余
- 更新异常
- 插入异常:应该插入的信息无法插入;
- 删除异常:不该删除的信息被删除。
设计单一的关系模式 :
Student( Sno, Sdept, Mname, Cno, Grade )
主码:(Sno,Cno)
数据冗余
例如每一个系的系主任姓名重复出现,与该系所有学生的所有课程成绩出现次数相同,浪费存储空间。
更新异常
当某个系的系主任更换后,必须修改与该系学生有关的每一个元组,系统要付出很大代价来维护数据库的完整性。
插入异常:应该插入的信息无法插入;
当一个系初建时,还未招收学生,系和系主任的信息无法存储在数据库。
删除异常:不该删除的信息被删除。
当学生毕业时,要删除所有学生信息,系和系主任的信息也被丢掉了。
- 理解相关概念,包括函数依赖,平凡的FD,非平凡的FD,完全FD,部分FD,传递FD(P181);
(1)函数依赖:设R(U)是一个属性集U上的关系模式,X,Y时U的子集,不可能存在两个元组在X上的属性值相等,而在Y上的属性值不等,则称“X函数确定Y”或“Y函数依赖于X”,记作X→Y。称X为这个函数依赖的决定因素或决定属性组。
在关系模式R(U)中,对于U的子集X和Y,
(2)非平凡的FD:如果X→Y,但Y不包含于X,则称X→Y是 非平凡的FD;
(3)平凡的FD:如果X→Y,但Y 包含于X, 则称X→Y是平凡的FD。
(4)完全FD:在关系模式R(U)中,如果X→Y,并且对于X的任何一个真子集X’, 都有X’推不出Y,则称Y对X完全函数依赖。
(5)部分FD:若X→Y,但Y不完全函数依赖于X,则称Y对X部分函数依赖。
注意:
只有当决定因素是组合属性时,讨论部分函数依赖才有意义;
当决定因素是单属性时,一定是完全函数依赖。
- 熟练掌握如何分析和判断关系模式的范式级别;
范式:关系数据库中的关系必须满足一定的要求,满足不同程度要求的为不同范式。
规范化:一个低一级范式的关系模式通过模式分解转换为若干个高一级范式的关系模式的集合,这个过程叫做规范化。
- 理解什么叫规范化,知道各种范式之间的关系。(P182,P189图6.8)
1NF:如果一个关系模式R的所有属性都是不可分的基本数据项,则R∈1NF。
2NF:若关系模式R∈1NF,并且不存在非主属性对码的部分依赖,则R∈2NF。
3NF:若R∈2NF,且不存在非主属性对码的传递依赖,则R∈3NF。
BCNF:每一个决定因素都包含候选码。
3NF和BCNF区别:消除了主属性对候选码的部分依赖和传递依赖。
注:3NF并不完美,存在主属性对不包含它的候选码的部分依赖
- 能够对设计不合理的关系模式进行模式分解,使其达到较高的范式级别;
关系规范化小结:
3NF必定为2NF和1NF,反之不一定;
BCNF必为3NF,反之不一定;
在函数依赖范围内,BCNF已完全消去了插入和删除异常;
- 理解FD集的闭包、属性集的闭包;
FD集的闭包:在关系模式R<U,F>中为F所逻辑蕴含的函数依赖的全体叫作 F的闭包,记为F+。
属性集的闭包:对于R<U,F>,X 含于U, XF+ ={ A|X→A能由F 根据Armstrong公理导出},XF+称为属性集X关于函数依赖集F 的闭包。
求属性集闭包的用途:将判定X→Y是否被F蕴含的问题,就转化为求XF+ ,判定Y是否为XF+的子集的问题。
- 能够熟练计算属性集的闭包,并利用它判断某个FD是否成立;
- 计算方法非常简单,一定要掌握,可以参考课件及作业。
- 掌握Armstrong公理系统的6条推理规则(自反律、增广律、传递律、合并规则、伪传递规则、分解规则);(P190~191)
(1)自反律:若Y含于X含于U,则X →Y 为F 所蕴含。
(2)增广律:若X→Y为F所蕴含,且Z 含于U,则XZ→YZ 为F 所蕴含。
(3)传递律:若X→Y及Y→Z 为F 所蕴含,则X→Z为F所蕴含。
(4)合并规则:由X→Y,X→Z,有X→YZ。
(5)伪传递规则:由X→Y,WY→Z,有XW→Z。
(6)分解规则:由X→Y及 Z含于Y,有X→Z。
- 理解FD集等价的含义;
FD集等价:如果F+=G+,就说函数依赖集F与G等价。
F+ = G+ 的充分必要条件是:F含于G+ ,和G 含于F+
- 掌握求候选码的方法,能够判断关系模式最高属于第几范式。
- 方法非常简单,一定要掌握,可以参考课件及作业。
对于关系模式R<U,F>的候选码K:
1. K→U: KF+为U
2. 极小:K不包含冗余属性
根据F分析属性的种类:
1.只出现在左边: 必包含在任何候选码中
2.只出现在右边: 必不包含在任何候选码中
3.两边都出现: 可能包含于某个候选码中
- 掌握求最小依赖集的方法;
如果函数依赖集F满足下列条件,则称F为一个最小依赖集。
(1) F中任一FD的右部仅含有一个属性。(右部单属性)
(2) F中不存在FD X→A,使得F-{X→A}与F等价。(无冗余FD)
(3) F中不存在FD X→A,使得F-{X→A}∪{Z→A}与F等价。(左部无冗余属性)
12. 模式分解应:1.保持无损连接性;2.保持函数依赖。
- 数据库设计(重点!)
- 理解数据库设计的6个阶段;
数据库设计的基本步骤:
(1)需求分析:系统需要实现什么功能,需要存储哪些信息;(数据流图、数据字典)
(2)概念结构设计:构造E-R图;(概念模式)
(3)逻辑结构设计:转化为DBMS支持的关系模型,并进行优化;(逻辑模式)
(4)物理结构设计:确定存储结构、存取方法;(内模式)
(5)数据库实施:根据设计结果建立数据库,编制应用程序,组织数据入库,试运行;
(6)数据库运行、维护:运行过程中进行评价、调整和修改。
- 掌握E-R图的表示方法(P217);
- 实体型:矩形
- 属性:椭圆形
- 联系:菱形
- 掌握实体与属性的划分原则,注意理解联系的语义,注意消除E-R图中不必要的冗余;
属性不需要进一步描述,即必须是不可分的数据项;
属性不能与其他实体具有联系。
合并E-R图冲突:
属性冲突,命名冲突,结构冲突。
- 熟练掌握E-R图向关系模式转换的方法;(必考内容)
- 实体型怎么转换?
- 联系怎么转换?(esp.要求转换后关系模式的总数最少时)
- 1:1
- 1:m
- m:n
实体型:转换为关系
属性:转化为关系的属性
(1)一个m:n联系:转换为一个关系模式。
该关系的属性:与该联系相连的各实体的码以及联系本身的属性
该关系的码:相连各实体码的组合
(2)一个1:n联系:与n端实体对应的关系模式合并
合并后关系的属性:在n端关系中加入1端关系的码和联系本身的属性
合并后关系的码:不变
(3)一个1:1联系:与某一端对应的关系模式合并
合并后关系的属性:加入另一端关系的码和联系本身的属性
合并后关系的码:不变
- 数据库编程(不考)
- T-SQL中局部变量和全局变量的表示方法;
- @前缀
- @@前缀
全局变量:以@@字符开头,由系统定义和维护
局部变量:先声明后使用,使用@符号作为前缀。
- 什么是存储过程及其特点(见课件);
存储过程:
在大型数据库系统中,一组完成特定功能的SQL语句集,经编译后存储在数据库中,可被反复调用,用户通过指定过程名和参数来执行它。
特点:
1)存储过程只在创建时编译和优化;
2)可减少网络流量,存储过程存储在服务器端,应用程序通过调用语句就可以执行它,不需要将大量SQL语句传送到服务器端;
3)可将复杂操作封装起来与DB提供的事务处理结合一起使用,如对多个表进行update、insert、delete、select时;
4)可重复使用,减少DB开发人员工作量;
5)安全性高,可设定用户对存储过程的使用权。
第10 章 数据库恢复技术
- 理解什么是事务;
事务(Transaction)是用户定义的一个数据库操作序列,这些操作要么全做,要么全不做,是一个不可分割的工作单位。
定义方式:
BEGIN TRANSACTION
SQL 语句1
SQL 语句2
......
COMMIT / ROLLBACK
- 事务的开始语句和结束语句,commit、rollback的含义(P293);
- Commit:提交
- Rollback:回滚
Commit:提交,即提交事务的所有操作。将事务中所有对数据库的更新写回到磁盘上的物理数据库中去。
Rollback:回滚。系统将事务中对数据库的所有已完成的操作全部撤销,回滚到事务开始时的状态。
- 理解事务的4个特性ACID;(P294)
- 原子性
- 一致性
- 隔离性
- 持续性
(1)原子性:事务是数据库的逻辑工作单位,事务中包括的诸操作要么都做,要么都不做。
(2)一致性:定义事务时,应保证事务执行的结果必使数据库从一个一致性状态变到另一个一致性状态.
(3)隔离性:对并发执行而言,一个事务的执行不能被其他事务干扰。
(4)持续性:一个事务一旦提交,它对数据库中数据的改变就应该是永久性的。
- 写日志文件和写数据库的先后次序;(P300)
- 先写日志文件,后写数据库
日志文件是用来记录事务对数据库更新操作的文件
恢复技术:
基本原理:冗余。当数据库被破坏或产生不正确的数据时,用存储在系统别处的冗余数据来重建。
转储的分类:
(1)静态转储:转储过程中不允许运行事务。
动态转储:转储过程中允许运行事务。
(2)海量转储:每次转储全部数据。
增量转储:每次只转储上一次转储后更新过的数据。
- 事务故障、系统故障、介质故障的恢复策略;
事务故障的恢复:UNDO
系统故障的恢复:UNDO + REDO
介质故障的恢复重装备份并恢复到一致性状态 + REDO
(1)事务故障:
事务在运行过程中被中断,没有达到预期的终点。
例如:运算溢出,操作违反了某些完整性约束
恢复策略:由恢复子系统利用日志文件撤消(UNDO)此事务已对数据库进行的修改。
事务故障的恢复由系统自动完成,不需要用户干预。
(2)系统故障:
造成系统停止运转的事件,影响所有正在运行的事务。
例如:系统断电、CPU故障、OS故障、DBMS代码错误等
系统故障造成数据库不一致状态的原因:
1)一些未完成事务对数据库的更新已写入数据库
2)一些已提交事务对数据库的更新还留在缓冲区没来得及写入数据库
恢复策略:1. Undo 故障发生时未完成的事务
2. Redo 已完成的事务
系统故障的恢复由系统在重新启动时自动完成,不需要用户干预.
(3)介质故障:
硬故障,指外存故障,如磁盘损坏、磁场干扰等。
恢复策略:1)装入最新的数据库副本,使数据库恢复到最近一次转储时的一致性状态。
2) 装入相应的日志文件副本,重做已完成的事务。
介质故障由DBA恢复。
(4)计算机病毒
- 具有检查点的恢复技术;
- 并发控制技术(11.3和11.5.2不考)
- 并发操作带来的三类问题;(P310)
- 丢失修改;
- 不可重复读;
- 读“脏”数据。
(1)丢失修改:
事务T1、T2读取相同的数据,并做修改,T1的修改被T2覆盖。
(2)不可重复读:
事务T1读取某一数据后,
1)事务T2对其做了修改,当事务T1再次读该数据时,得到与前一次不同的值。
2)事务T2删除了其中部分记录,当事务T1再次读取数据时,发现某些记录神密地消失了。
3)事务T2插入了一些记录,当事务T1再次按相同条件读取数据时,发现多了一些记录。
(3)读“脏”数据:
T1修改某一数据后,T2读取它,接着T1回滚,使得T2读取的值和数据库中实际的值不一致。
- 基本的封锁类型及其含义;
- 读锁
- 写锁
(1)封锁:封锁就是事务T在对某个数据对象(例如表、记录等)操作之前,先向系统发出请求对其加锁;加锁后事务T就对该数据对象有了一定的控制,在事务T释放它的锁之前,其它的事务不能更新此数据对象。
(2)基本的封锁类型
1)排它锁(Exclusive locks,简记为X锁,写锁)
若事务T对数据对象A加上X锁,则只允许T读取和修改A,其他事务不能再对A加任何类型的锁,直到T释放A上的X锁。
2)共享锁(Share locks,简记为S锁,读锁)
若事务T对数据对象A加上S锁,则T可以读取A但不能修改A,其他事务只能再对A加S锁,不能加X锁,直到T释放A上的S锁。
- 封锁方法带来的问题及相应的解决方法,注意理解其含义;
- 活锁
- 死锁
(1)活锁:某个事务被其它后来的事务抢占了,产生一直没有运行的现象
避免活锁的方法:先来先服务策略
(2)死锁:两个事务各自需要对方解决自己要操作的数据对象上的锁的权限,永久等待对方释放锁。
解决死锁的方法:
1)预防:
一次封锁法
顺序封锁法
2)定期诊断+解除:
超时法
事务等待图法
解除死锁:选择一个处理死锁代价最小的事务,将其撤消,释放此事务持有的所有的锁,使其它事务能继续运行下去。
- 正确调度的充要条件;
- 并发调度,当且仅当它是可串行化的,才是正确的调度。
什么样的并发操作调度是正确的?
答:显然,串行调度肯定正确;
事务的并发执行是正确的,当且仅当其结果与某一串行调度结果相同。这种调度策略称为可串行化的调度。
- 两段锁协议的含义、作用,能够判断某调度序列是否遵守了两段锁协议;(P319)
- 两段锁协议是可串行化的充分条件
如何保证并发操作的调度是正确的?
两段锁协议(Two-Phase Locking,简称2PL);
理论上已证明使用2PL产生的调度是可串行化的。
两段锁协议的内容
1.在对任何数据进行读、写操作之前,事务首先要获得对该数据的封锁;
2.在释放一个封锁之后,事务不再申请和获得任何其他封锁。
可以证明,若并发执行的所有事务都遵守两段锁协议,则对这些事务的任何并发调度都是可串行化的
封锁对象的大小称为封锁粒度