《数据库原理与应用》课件第6章

第6章数 据 库 保 护6.1数据库保护概述6.2数据库的安全性6.3数据库完整性6.4数据库的并发控制6.5数据库恢复小结数据库系统中的数据是由数据库管理系统(DBMS)统一管理和控制的，数据库是一个共享资源，可以供多个用户使用，当多个用户并发地存取数据库中的数据时，会发生多个事务同时存取同一数据的情况。若对并发操作不加控制就可能存取和存储不正确的数据，破坏数据库的一致性，所以DBMS必须提供并发控制机制和数据库恢复机制。为了适应数据共享的环境，保证用户高效地使用数据库，DBMS在保证数据库能并发访问的同时还应保证数据库中的数据是安全的和完整的，也就是说，DBMS必须提供数据的安全性和完整性。计算机系统在安全性方面规定了保密性、完整性、可用性的要求。保密性的目的是为了避免不合法的使用造成信息泄露；完整性的目的是为了避免对信息或者进程做不合适的修改；可用性则是为了避免对信息不正确的访问。这些安全目标与具体的DBMS都有关系，几乎在所有的信息系统中，这三个目标都有不同程度的存在。在安全设置方面，往往是层层设防，主要有用户级安全控制、数据库管理系统级安全控制、操作系统安全控制和数据库安全控制等。数据库安全性与数据完整性是分不开的。数据安全性在于保护存储数据的完整性，即保护数据项之间的结果不受破坏，保持数据的正确、有效和相容，使同一数据的不同副本尽量协调一致，提高数据的可用性。因此，安全性主要保证数据不被未授权的用户访问与破坏；而完整性主要保证数据的正确性和相容性。

为了实现数据安全可靠和正确有效地得到共享，DBMS应提供统一的数据保护功能。数据库系统的数据保护主要包括数据的安全性机制和数据的完整性机制、并发控制和数据库恢复技术。本章对涉及数据库保护的正确性、完整性、并发控制和数据库恢复等技术的基本概念和实现方法进行系统地分析和讲解。

学习内容：

(1)数据库的安全性。

(2)数据库的完整性。

(3)数据库的并发控制。

(4)数据库恢复。

6.1.1数据库遭受破坏的主要原因

一个组织或单位把存储在数据库中的数据(信息)看成是具有相当经济价值和社会效益的财富。对于使用数据库技术进行信息管理的组织而言，它们的业务工作或生产活动能否非常连续地开展，完全取决于数据库的正确性、可用性和可持续性。可以想象，一个银行数据库一旦遭到不可恢复的严重破坏，其后果是不堪设想的，它的账目将会部分或全部地丢失或搞乱，这不仅使银行业务无法进行，而且更重要的是银行要蒙受巨大的经济损失。6.1数据库保护概述一个民航公司的数据库系统若因故障几天不能恢复正常，那么相关的航班业务也许会被停顿几天。一个军事数据库失密或破坏，有可能造成重大的流血事件，甚至危及国家安全。一个数据不准确的医疗数据库可能会造成不可挽回的医疗事故。

由于数据库是众多用户的共享系统，因此受到破坏和威胁的危险性就比较大。因而对其实施保护的问题也就显得十分必要了。共享程度越高，保护问题就越加重要。

数据库保护与计算机系统环境的保护是紧密相联系的，因此这个问题需要在更大的范围内才能彻底解决。它将涉及到所处的环境、计算机硬件和软件、信息和通信设施等多方面的保护问题，以及必要的法律手段。例如，计算机要安装在安全可靠的地方，软件和硬件设备应提供多种自我保护措施，以预防、发现和修复系统故障。所有这些措施对数据库的保护无疑都具有重大的决定性意义。

综上所述，在现代信息社会，数据库是十分重要的资源，必须保证其安全可靠的运行。一般引起数据库系统遭受破坏的主要原因有四个方面：

(1)数据库系统的安全性。非法用户对数据库的访问将造成信息泄密或非法更改数据库数据。

(2)数据库的完整性。数据库数据的正确可靠和相容是系统正确运行的前提，完整性直接影响关联数据的正确和一致。

(3)并发控制。现代数据库应用一般都是多用户共享环境，多个用户同时操作数据库非常普遍，若这种并发操作控制不好，将会造成不可重复读、读脏数据和丢失修改等问题。

(4)数据库恢复。软硬件的故障、计算机病毒、黑客的破坏都会造成数据资源的破坏，为此要有比较可行的恢复策略，一旦出现上述问题，要用最短的时间，花最小的代价把数据库恢复到某一个正确的状态。6.1.2数据库管理系统对数据库提供的保护措施

一般来说，对数据库的破坏来自四个方面：非法用户(未经授权而恶意访问、修改甚至破坏数据库的用户，以及超越权限访问数据库的用户)、非法数据(不符合规定或语义要求的无效数据，一般由用户的误操作引起)、各种故障及多用户的并发访问。

针对以上四种可能对数据库产生破坏的情况，数据库管理系统要采取相应措施对数据库实施保护，具体如下：

(1)利用权限机制，只允许有合法权限的用户存取所允许的数据(这是6.2节要解决的数据库安全性问题)。

(2)利用完整性约束防止非法数据进入数据库(这是6.3节要解决的数据库完整性问题)。

(3)提供并发控制机制，控制多个用户对同一数据的并发操作，以保证多个用户并发访问的顺利进行(这是6.4节要解决的并发控制问题)。

(4)提供故障恢复能力，以保证在故障排除后，能将数据库中的数据从错误状态恢复到正确状态(这是6.5节要解决的数据库恢复问题)。

数据库的安全性是指保护数据库以防止用户不合法的使用所造成的数据泄密、更改或破坏。安全性问题不是数据库独有的，任何计算机系统都存在这个问题。在数据库系统中，大量数据集中存放，而且为许多用户直接共享，是宝贵的信息资源，从而使得安全问题更为突出。系统安全保护措施是否有效是评价数据库系统性能的主要指标之一。

一方面，安全性问题和保密问题是密切相关的。前者主要涉及数据的存取控制、修改和传播的技术手段，而后者在很大程度上涉及的是法律、政策、伦理等问题。6.2数据库的安全性另一方面，数据库安全性问题是与数据库完整性问题分不开的。数据库安全性是保证数据库能否反映现实世界的重要措施，用以防止非法使用数据库中的数据，防止错误数据的输入和输出。完整性措施的防范对象是不合语义的数据。可见，安全性是针对未授权用户而采取的数据保护措施，而完整性是针对授权用户而采取的数据保护措施。

本节主要讨论数据库的安全性和安全机制问题。6.2.1数据库的安全保密方式

数据库的安全保密方式涉及系统处理和物理两个方面。所谓物理是指，对于强行逼迫透漏口令、在通信线路上窃听以至盗窃存储设备等行为而采取的将数据编为密码，加强防卫以识别用户身份和保护存储设备等措施，它不在本节讨论之列。这里只讨论计算机系统中采取的保护措施。

一般计算机系统中，安全措施往往是一级一级层层设置的，其模型如图6.1所示。

图6.1计算机系统安全模型在这个安全模型中，用户要求进入计算机时，系统首先根据输入的用户标识进行用户身份鉴别，只有合法用户才准许进入计算机系统。对已进入系统的用户，DBMS还要设置很多访问限制，例如自由存取控制(DAC)和强制存取控制(MAC)，并只允许用户进行合法操作。操作系统一级也有自己的保护措施，它主要是基于用户访问权限的访问控制。数据还可以以密码形式存储到数据库中。6.2.2数据库安全控制

数据库安全性控制就是防止非法用户对未被授权的数据进行访问。计算机系统在安全性方面规定了保密性、完整性、可用性的要求。如前所述，这些安全目标在所有的信息系统中都有不同程度的反映。例如，在一个工资系统中，保密性防止雇员发现老板的薪水；完整性防止雇员修改其薪水；而可用性保证按时发放薪水。

1．用户标识和鉴别

用户身份鉴别(Authentication)是系统提供的最外层安全保护措施，其方法是系统提供一定的方式让用户标识自己的名字或身份，系统经过核实，通过鉴定后才提供机器使用权。用户标识和鉴别的方法有很多种，而且在一个系统中往往多种方法并存，以获得更强的安全性。常用的方法有：

(1)利用只有用户知道的信息鉴别用户。用户以用户名或者用户标识来表明用户身份，系统鉴别用户是否是合法用户，若是，则可以进行下一步核实鉴别；若不是，则不允许用户使用计算机。口令(Password)是使用最广泛的一种标识。为了进一步核实用户，系统常常要求用户输入口令。为保密起见，用户在终端上输入的口令不显示在屏幕上。系统利用一个专门的鉴别机构(其内部记录着所有合法用户的用户名和标识)对用户名和标识(即口令)进行处理，系统核对口令以鉴别用户身份。

虽然用用户名和口令来鉴别用户的方法简单易行，但有企图的冒名顶替者可能猜中或者偷窃到口令，因此，有必要对口令加以保护。如增加口令的长度，以增加猜中口令的时间；系统提供随机数，用户根据预先定义好的某一过程或者函数进行计算，系统根据用户的计算结果是否正确进一步鉴定用户身份等。

(2)利用用户特有的物件来鉴别用户。在计算机系统中，常用磁性卡片作为用户身份的凭证，但这样的计算机系统必须安装磁卡阅读装置，而且磁卡也存在丢失或被盗的危险。

(3)利用用户的物理特征鉴别用户。例如声音、相貌、签名、指纹等都可以作为鉴别用户的物理特征。利用这些特征来鉴别用户非常可靠，但需要昂贵的、特殊的鉴别装置，因而影响它的推广和使用。

2．存取控制

存取控制是数据库管理系统级的安全措施，也是杜绝数据库被非法访问的主要方法。

数据库安全性所关心的主要问题是DBMS的存取控制机制。数据库安全最重要的一点就是确保授权给有资格的用户访问数据库的权限，同时令所有未授权的人员无法接近数据，这主要通过数据库系统的存取控制机制实现。

存取控制机制主要包括两部分：

(1)访问权限控制。所谓用户访问权限控制，是指不同的用户对于不同的数据对象允许执行的操作权限，由它指明数据对象被授予的操作类型、授权粒度(例如，表、列或者行等)。

(2)合法权限检查。每当用户发出存取数据库的操作请求后(请求一般包括操作类型、操作对象和操作用户等信息)，DBMS查找数据字典，根据安全性规则进行合法权限检查，若用户的操作超出定义权限，系统将拒绝执行此操作。

授权编译程序和合法权限检查机制一起组成了安全性子系统。授权定义中，数据对象范围越小，授权子系统就越灵活。衡量授权子系统优劣程度的另一个尺度是能否提供与数据值有关的授权。现在的DBMS一般同时支持自由访问控制和强制访问控制两种数据安全性控制方法。自由访问控制允许对于不同的数据对象，用户有不同的权利；也允许对于同一数据对象，不同的用户可以有不同的权利；还允许用户权限具有传递性。因此，自由访问控制非常灵活。强制访问控制允许对用户及其访问的数据分别进行分组归类(数据按机密程度划分为若干密级，如绝密(TopSecret)、机密(Secret)、秘密(Confidential)、一般(Public)等)，而用户根据密级和分类的组合来定义自己的安全级别。强制访问控制明确地限定每组用户能够访问的数据类别，并且不同类别的数据之间不能互相移动，因此，强制访问控制非常严格。自由访问控制按其访问粒度又可以划分为6类：整个数据库、某些关系的集合、一个关系、一个关系中的某些列、一个关系中的某些行和一个关系中的某些行中的某些列。自由访问控制通过授权的形式来实现，而授权是指DBMS赋予用户一定的访问特权，它是对用户访问权限的规定和限制。用户对数据库的各种操作可以有多种授权形式，如Read授权、Insert授权、Updata授权和Delete授权等。用户还可以获得对数据库模式进行修改的授权，如Index授权、Resource授权、Alteration授权和Drop授权。具有某种权限的用户还可以把权限传递给其他用户，但必须记录权限的传递，以便能够在将来收回授权。在关系数据库中，访问控制没有使用基本的SQL操作。SQL语言提供了授权与取消授权的GRANT语句和REVOKE语句。基本的SQL操作还包括DELETE、INSERT、SELECT、UPDATA权限。其中，数据对象的创建者自动获得关于数据对象的所有操作权限。

SQL-92标准定义了数据库模式的基本授权机制：只有模式的所有者才能对模式进行修改。因此，模式的修改(如关系的创建和删除、增加和删除关系中的某些列以及增加或去除索引)只能由模式的所有者来执行。自由访问控制存在的不足之处是：如果用户获取了某个WITHGRANTOPTION的特权，他就可以把它授予任何人，这是不安全的，在某些情况下是不允许的。

强制访问控制基于的是与每个数据项和每个用户关联的安全标记(SecurityLabel)。安全标记被分成若干个级别。数据的标记称为密级(SecurityClassification)，用户的标记称为许可证级别(SecurityClearance)。在计算机系统中，每个运行的程序继承用户的许可证级别。也就是说，用户的许可证级别不仅应用于用户，而且应用于用户运行的所有程序。当某一用户以某一密级进入系统时，在确定该用户能够访问系统上的数据时应遵循以下规则：当且仅当用户的许可证级别大于或等于数据密级时，该用户才能对数据进行写操作；当且仅当用户的许可证级别等于数据密级时，该用户才能对数据进行读操作。

DBMS在执行安全性检查时，首先检查DAC(自由存取控制)，然后对通过DAC检查并且有访问许可的数据对象进行MAC(强制存取控制)检查，只有通过MAC检查的数据对象才可以进行访问。因此，实现DBMS的安全性时，在实现MAC之前先实现DAC，即DAC和MAC共同构成DBMS的安全机制。

3．审计(Audit)

前面介绍的用户标识与鉴别、存取控制仅是安全性指标的一个重要方面，但并不是全部。为了使DBMS达到一定的安全级别，还需要在其他方面提供相应的支持。

因为任何系统的安全保护措施都不是完美无缺的，蓄意盗窃、破坏数据的人总是想方设法打破控制。审计功能把用户对数据库的所有操作自动记录下来放入审计日志中。数据库管理员(DBA)可以利用审计跟踪的信息，重现导致数据库现行状况的一系列事件，找出非法存取数据的人、时间和内容等。审计通常是很费时间和空间的，所以DBMS往往都将它作为可选特征，允许DBA根据应用对安全性的要求，灵活地打开或关闭审计功能。审计功能一般应用于安全性要求比较高的部门。同时，审计功能所探测的违规操作类型是有限的，因为它是基于违规操作总是可以通过分析异常行为的审计记录探测到这种假设的。

4．数据加密

对于高度敏感的机密数据，例如财务数据、军事数据、国家机密，除以上安全性措施外，还必须进一步提高其安全性，即对数据库中的数据进行加密。

数据加密是防止数据库中的数据在存储和传输中失密的有效手段。加密的基本思想是根据一定的算法将原数据(术语为明文，PlainText)变换为不可直接识别的格式(术语为密文，CipherText)，从而使不知道解密算法的人无法知道数据的真实内容。

加密算法主要有两种。一种是替换方法，该方法使用密钥将明文中的每个字符转换成密文中的一个字符。另一种是置换方法，该方法仅将明文中的字符按不同顺序重新排列。单独使用任一种方法都是不够安全的。将这两种方法结合起来就能达到比较高的安全程度。

一个好的加密技术应具有以下特性：

(1)对授权用户来说，进行数据加密和解密的过程都很简单。

(2)加密模式不应依赖于算法的保密，而应依赖于被称作密钥的算法参数。

(3)对于恶意入侵者来说，确定密钥极其困难。

目前，有些数据库产品已经提供了数据加密例行程序，系统可以根据用户的要求自动对存储和传输的数据进行加密处理。另外，还有一些数据库产品虽然本身未能提供加密程序，但提供了接口，允许用户用其他厂商的加密程序对数据加密。

由于数据加密与解密都是比较复杂的操作，而且数据加密与解密程序会占用大量的系统资源，因此数据加密功能通常也是作为可选特征，允许用户自由选择。

5．定义视图

通过定义用户的子模式也可以对机密数据提供一定的安全保护功能。通常采用的方法是为不同的用户定义不同的视图，通过视图机制把需要保密的数据对普通用户隐藏起来，但由于视图机制的主要功能是提供数据独立性，因此提供的安全保护功能并不十分强大，时常满足不了应用系统的要求。实际应用中经常和其他安全性保护方法共同使用。6.2.3SQLServer的安全性体系简介

1．SQLServer安全体系结构

SQLServer的安全体系由三级组成，从外向内，分别是DBMS或数据库服务器级、数据库级、语句与对象级，由内向外一级比一级要求高。其安全体系结构见图6.2所示。从安全策略上讲，要访问数据库服务器必须先成为RDBMS的登录用户，登录用户可以分配到某个角色或用户组；要访问某个数据库，必须将某个登录用户或其所属的角色设置成该数据库的用户；成为某个数据库的用户后，如要访问该数据库下的某个数据库对象，或执行某个命令语句，还必须为该用户授予所要操作对象或命令的权限。

图6.2SQLServer安全体系结构需要强调的是，SQLServer是构建在某个操作系统之上的，它们各自都有其安全体系。操作系统的登录用户只有成为SQLServer的登录用户后，才能访问SQLServer。

2．SQLServer登录用户

SQLServer在安装时，会自动创建一个数据库服务器的登录用户SA，即系统管理员(SystemAdministrator，简称SA)，该用户具有三级体系的所有权限，是超级用户。几乎所有的创建用户和授权的工作都是由SA来完成的，除非将授权工作转授给专门的权限管理人员。

除此之外，还可利用存储过程来进行数据库服务器登录用户的创建。

登录用户一旦被创建，即可连接SQLServer。如果指定了默认数据库，则在登录后，即可连接到该数据库。

3．SQLServer角色定义

SQLServer安装过程中，会自动创建一些系统角色。系统角色又分为服务器级和数据库级，每个系统角色的权限在系统安装好后就固定了。

服务器级的系统角色主要包括：Sysadmin(系统管理)、Securityadmin(安全管理)、Serveradmin(服务器管理)、Setupadmin(启动管理)、Processadmin(进程管理)、Diskadmin(磁盘管理)、Dbcreator(数据库创建者)和Bulkadmin(备份管理)。

数据库级系统角色包括Public和Dbo。Public角色只具备最基本的访问数据库的权限。Dbo角色对该数据库或对象具有所有的操作权限。

各角色的具体权限请参阅SQLServer的技术资料。

4．SQLServer数据库用户

数据库用户是指有权访问或创建数据库对象的数据库用户。在SQLServer中有两个重要的数据库用户：Dbo和Guest。

SQLServer在安装时，自动创建了一个默认数据库用户，即Guest。一个登录用户在被设定为某个数据库的用户之前，可以以Guest用户身份访问该数据库，只不过其权限非常有限。

数据库所有者(Dbo)具有数据库范围内的管理权，可以创建、修改和删除数据库中的所有对象。缺省的Dbo是数据库的创建者。

SQLServer提供了GRANT和REVOKE两条数据控制语句，用以控制对数据库的访问。关于语句的详细信息在前面第4章已进行了介绍，此处不再赘述。

数据库的完整性是指数据的正确性和相容性，或一致性和协调性。保证数据库的完整性非常重要，它涉及到数据库系统能否真实地反映现实世界。据分析，数据库的完整性方面的破坏主要来自操作员或者终端用户的错误输入，数据库应用程序出错，数据库中并发操作控制不正确，数据冗余引发的数据正、副本间的不一致性，DBMS或操作系统程序出错和系统硬件出错等。6.3数据库完整性数据的完整性和数据的安全性是两个不同的概念。完整性是为了防止合法用户使用数据库时向数据库中加入不符合语义的数据，防止错误信息的输入和输出，即所谓垃圾进垃圾出(GarbageInGarbageOut)所造成的无效操作和错误结果。而安全性是保护数据库防止非法用户的恶意破坏和非法存取。也就是说，安全性措施的防范对象是非法用户和非法操作，完整性措施的防范对象是不合语义的数据。当然，数据的完整性和安全性是密切相关的，特别是从系统的实现方法上看，某一种机制常常既可以用于安全性保护也可以用于完整性保护。6.3.1完整性约束条件

在DBMS系统中，通过一套维护数据库完整性的机制，保证数据库中的数据满足语义完整性。我们把对数据库中的数据上强加的语义约束条件称为数据库完整性约束条件，即现实世界或者系统设计者要求数据项应满足的条件。

完整性约束条件是完整性控制机制的核心。完整性约束条件作用的对象可以是关系、元组、列三种粒度。其中，对列的约束指的是对列的类型、取值范围、精度、排序等的约束条件；对元组的约束指的是对元组中各个字段间的联系的约束；对关系的约束则是指对若干元组间、关系集合上以及关系之间的联系的约束。涉及完整性约束条件的这三类对象，其状态可以是静态的，也可以是动态的。所谓静态约束，是指数据库的每一确定状态是数据对象所应满足的约束条件，它反映数据库状态合理性约束，这是最重要的一类完整性约束。动态约束是指数据库从一种状态转变为另一种状态时，新、旧值之间所应满足的约束条件，它是反映数据库状态变迁的约束。涉及完整性约束条件的三类对象均可以有静态和动态之分，我们可以将完整性约束条件划分成六类，其含义如表6.1所示。表6.1完整性约束条件的分类及含义完整性约束条件一般是用完整性约束规则来表示的。完整性约束规则可以用五元组(D,O,A,C,P)来形式化地表示。其中，D(Data)表示约束作用的数据对象；O(Operation)描述对数据库的操作类型，如插入、删除、修改等；A(Assertion)表示数据对象必须满足的断言或语义约束，它是规则的主题；C(Condition)表示选择A作用的数据对象值的谓词；P(Procedure)表示违反完整性规则时触发执行的操作过程。对数据D进行O类型操作又可以分为以下三种情况：条件A不成立，允许操作执行；条件A成立，C为真，允许操作进行；条件A成立，C为假，则执行过程P。例如，在人口统计中，出生和死亡将导致统计表的插入和删除操作，这时应该自动增、减人口总数，对此过程可以用上述五元组表示如下：

D=人口统计

O=插入或删除

A=真

C=假

P=增减人口总数的过程

注：完整性约束条件一般作为模式的一部分存放在数据库中。6.3.2完整性约束类型

根据数据库中输入的列值，可以加入以下五种类型的完整性约束限制：

(1)非空(NULL)值完整性约束。在默认情况下，一个表中所有列值都允许为空。列值非空约束要求某个表中的某列不能为空值。

(2)键值唯一性约束。键值唯一完整性约束规定组成键的一列中的每个值或者列的组合必须是唯一的，即一个表中的两行在组成键的列或者列的组合没有完全相同的值。

(3)主键完整性约束。数据库中的每个表至少有一个主键约束。该约束所属的一列值或者一组列值构成一行的唯一标识。

(4)外键(参照)完整性约束。一个关系数据库中的不同的表可以通过共同的列关联起来，因此必须有维护管理列之间的关联的规则。参照完整性规则保证这些联系得以实现。对于一个表中的每行，外键中的值匹配父表中的值。外键可以包括多列。然而，一个组合的外键必须参照一个具有相同列数和相同数据类型的组合主键或者唯一的键。

(5)检查完整性约束。检查约束可以定义在列级，也可以定义在表级。它通过对表中一列或多列指定检查条件，以保证域值的完整性约束。6.3.3完整性约束机制

DBMS在完整性约束机制中应具有三方面的功能：

(1)定义功能，即提供定义完整性约束的条件机制。

(2)检查功能，即检查用户发出的操作请求是否违背了完整性约束条件。

(3)若发现用户的操作请求使数据违背了完整性约束条件，则采取一定的动作保护数据的完整性。

目前，许多关系数据库管理系统都提供了定义和检查完整性的功能。对于违背实体完整性和用户自定义完整性约束的操作，一般都采用拒绝执行的方式进行处理。对于违背参照完整性的操作，并不都是简单的拒绝执行，有时应根据语义执行一些附加操作，以保证数据库的正确性。此外，DBMS还应在完整性约束机制方面提供：责任分割、事件重构、权限委派、现场检查和操作连续性等。

所有这些完整性约束机制都是为了确保数据的完整性。6.3.4SQLServer的完整性约束机制

SQL中将完整性约束分为基本表完整性约束、域完整性约束和断言完整性约束三种

类型。

1．基本表完整性约束

SQL中基本表约束有三种形式：主键定义、外键定义和检查约束定义。

1)主键定义

主键定义格式为

PRIMARYKEY(<列名序列>)；其中，列名序列中不能为空。一个关系表只能有一个PRIMARYKEY，也就是说，PRIMARYKEY定义了主键(不能为空)。

例6.1

对于关系S(sno，sname，age，sex，clname)，可以使用如下语句创建表：

CREATETABLES

(snoCHAR(8),

snameCHAR(10),

ageINT,

sexCHAR(2),

clnameCHAR(20),

PRIMARYKEY(sno))；

2)外键定义

外键定义的基本形式为

POREIGNKEY(<列名序列>)

REFERENCES表名<目标表名>│(<列名序列>)

[NODELETE<参照动作>]

[NOUPDATE<参照动作>]

我们已经知道，作为外键的关系表称为依赖表，作为主键的关系表称为参照表。在上述定义中：

·“FOREIGNKEY(<列名序列>)”中的“(<列名序列>)”是依赖表的外键。

·“REFERENCES表名<目标表名>│(<列名序列>)”中的“<目标表名>”是参照表的名称，而“<列名序列>”是参照表的主键和候选键。

·“[NODELETE<参照动作>]”和“[NOUPDATE<参照动作>]”中的“<参照动作>”指当对参照表进行删除和更新操作时如果涉及其中的主键，这些操作会对与其匹配的依赖表产生影响。

当需要删除参照表中的某个元组(即要删除一个主键值)时，对依赖表产生的影响由下述参照动作确定：

①NOACTION，表示对依赖表没有影响；

②CASCADE，表示将依赖表中所有外键值与参照表中要删除的主键值相对应的元组一同删除；

③RESTRIC，表示只有当依赖表中没有一个外键值与要删除的参照表中主键值相对应时，系统才能执行删除操作，否则就拒绝删除；

④SETNULL，表示删除参照表中元组时，将依赖表中所有与参照表中被删除主键值相对应的外键值均置为空值；

⑤SETDEFAULT与SETNULL类似，将外键值都置为预先设定好的默认值。当需要更新参照表中某个元组(即要更新一个主键值)时，则对依赖表产生的影响与“删除”中情况类似，只需要将相应的“删除”改为“更新”即可。

在实际过程中，对上述五种方式的选择需要根据应用环境确定。

3)检查约束定义

检查约束定义的基本形式为

CHECK(<条件表达式>)

在对具有CHECK子句约束的基本表进行更新操作时，需要对相关的元组进行检查，看其是否满足CHECK子句所定义的约束条件。当不满足约束条件时，系统拒绝更新操作。

在例6.1中，加入CHECK子句：

ageNUMERIC(2)CHECK(ageBETWEEN18AND25)

CHECK子句只对定义它的关系起到约束作用，对其他关系没有约束作用，有可能会产生违反参照完整性的情形。

例6.2

在关系SC中加入CHECK子句。

CHECK(snoIN(SELECTsnoFROMS))

CHECK(cnoIN(SELECTcnoFROMC))

此时，就会出现违反参照完整性的情况，即当关系S中删除一个元组时，该操作与关系SC中的CHECK无关。这样，如果SC还存在被删除学生的选课元组，则SC不会不满足CHECK子句的约束。在CHECK子句中的条件最好不要涉及其他关系，而使用外键子句或断言子句定义相关完整性：

CREATETABLESC

(

snoCHAR(8)，

cnoCHAR(3)，

gradeINT，

RRIMARYKEY(sno，cno)，

FOREIGNKEY(sno)REFERENCES，

FOREIGNKEY(cno)REFERENCEC，

CHECK((gradeISNULL)OR(gradeBETWEEN0AND100)))；

2．域约束

SQL域约束的含义是作用于所有属于指定域的属性列的约束，并且使用“CREATEDOMAIN”语句实现该约束，约束语句中允许出现CHECK子句。

域约束规则的基本形式为

CREATEDOMAIN<域名><域类型>CHECK<条件>

为了便于引用，约束可以命名。约束命名使用保留字CONSTRAINT。

例6.3

下述语句定义了一个新的域Grades，并且加了一个名为“VALID-Grades”的域约束，CHECK子句指明了定义在该域的列上的取值，默认值为“？”。

CREATEDOMAINGradesCHAR(1)DEFULT'?'

CONSTRAINTVALID-Grades

CHECK(VALUEIN

('A','B','C','D','E','?'));

如果对学生成绩基本表SC(sno，cno，G)中的G用域Grades定义：

CREATETABLESC

(snoCHAR(8),

cnoCHAR(3),

GGrades,

)；

则表示对SC进行插入操作时，每插入一条学生成绩记录，其成绩G就必须为CHECK子句中指明的值，默认值为“？”；否则为非法成绩值，系统将会产生一个含有约束名为“VALID-Grades”的诊断信息，以表明当前操作不满足该域约束。…

3．断言约束

当完整性约束涉及面较为广泛，与多个关系有关，或是涉及聚合操作时，则可以使用SQL中提供的“断言”(Assertion)语句来编写完整性约束。断言可以像关系一样，用CHECK语句定义，其基本格式为

CREATEASSERTION<断言名>CHECK(<条件>)

这里，<条件>与SELECT语句中WHERE子句的条件表达式一样。

撤销断言的基本格式为

DROPASSERTION<断言名>

但撤销断言的句法不提供RESTRICT和CHECK(<条件>)。

例6.4

在教学数据库中的关系T、S、C、SC中使用断言写出完整性约束。

①每位学生选修的课程不超过6门。

CREATEASSERTIONASSE1CHECK

(6>=ALL(SELECTCOUNT(cno)

FROMSC

GROUPBY(sno)))；

②每门课程最多50名男学生选修。

CREATEASSERTIONASSE2CHECK

(50>ALL(SELECTCOUNT(SC.sno)

FROMS,SC

WHERES.sno=SC.snoANDsex='男'

GROUPBY(cno)));

有时，在关系中定义可以用CHECK子句形式替代断言，但CHECK子句不一定能保证完整性约束彻底实现，而断言则能保证不出现错误。

数据库系统一般可以分为单用户系统和多用户系统两种。在任何时刻只允许一个用户使用的数据库系统称为单用户数据库系统；允许多个用户同时使用的数据库系统称为多用户数据库系统。例如，飞机订票数据库系统、银行储蓄数据库系统等都是多用户数据库系统。在这样的系统中，在同一时刻并行运行的事务数可达数百或数千个。6.4数据库的并发控制当多个用户并发地存取数据库中的数据时就会产生多个事务同时存取同一数据的情况。若对并发操作不加控制就可能会存取和存储不正确的数据，破坏数据库的完整性。并发控制就是一种在多用户的环境下，对数据库的并发操作进行规范的机制，其目的是为了避免对数据的丢失更新、读“脏”数据和不可重复读等，从而保证数据的正确性与一致性。并发控制机制的好坏是衡量一个DBMS性能的重要标志之一。

DBMS的并发控制是以事务为单位进行的。6.4.1事务

1．事务(Transaction)及其性质

所谓事务，是用户定义的一组数据库操作序列，它是数据库的逻辑工作单位。事务是由事务开始与事务结束之间执行的全部操作组成。这些操作要么全做要么全不做，是一个不可分割的工作单位。在关系数据库中，一个事务可以是一条SQL语句、一组SQL语句或整个程序。

并不是任意的数据库操作序列都可定义为事务。事务一般具备以下四个性质。

1)原子性(Atomicity)

事务是数据库的逻辑工作单位，事务的所有操作是一个整体，事务中包括的诸操作“要么都做，要么都不做”(nothingorall)，不允许出现失误致使部分执行的情况。

事务的原子性是由DBMS的事务管理子系统来实现的。

2)一致性(Consistency)

事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。

如果事务执行过程中始终遵循“要么全做，要么全不做”的原则，一般可以保证事务的一致性。事务一致性通常是由编写事务程序的应用程序员编程完成的。它也可以由系统测试完整性约束自动完成。

事务的原子性和一致性密切相关。例如某公司在银行中有A、B两个账号，现在公司想从账号A中取出1万元，存入帐号B。那么就可以定义一个事务，该事务包括两个操作，第１个操作是从账号A中减去1万元，第２个操作是向账号B中加入1万元。这两个操作要么全做，要么全不做。全做或者全不做，数据库都处于一致性状态。如果只做一个操作则用户逻辑上就会发生错误，少了1万元，这时数据库就处于不一致性状态。可见一致性与原子性是密切相关的。

3)隔离性(Isolation)

在多个事务并发执行时，系统应保证各事务的执行结果与这些事务先后单独执行时的结果一样，即一个事务的执行不能被其他事务干扰。

事务之间的隔离性一般由并发控制子系统来实现。

4)持续性(Durability)

持续性也称永久性(Permanence)，指一个事务一旦成功执行，它对数据库中数据的改变就应该是永久性的，既使以后系统发生了故障也应该保留这个事务的执行结果。

事务的持续性是由DBMS的恢复管理子系统实现的。以上四个性质简称为事务的ACID性质。

事务是恢复和并发控制的基本单位，保证事务的ACID特性是事务处理的重要任务。事务的ACID特性可能遭到破坏的因素主要有两个：第一，多个事务并发执行时，不同事务的操作交叉执行；第二，事务在执行过程中被强行终止。

2．事务的状态

事务是数据库的基本执行单元。事务的执行情况有两种可能：一种情况是事务成功执行，数据库进入一个新的一致状态；另一种情况是事务因为故障或其他原因未能成功执行，但已经对数据库作了修改。未能成功执行的事务极有可能导致数据库处于不一致状态。这时候就需要对未能成功执行的事务(也称中止事务)造成的变更进行撤销操作(也称回滚ROLLBACK)。如果中止事务造成的变更已经撤销，就称事务已回滚。成功完成的事务称为已提交事务。对数据库进行更新的已提交的事务使数据库进入一个新的状态，即使出现系统故障，这个状态也必须保持。另一方面，成功提交的事务必能通过中止来撤销它造成的影响，此时必须采用执行一个称为“补偿事务”的方法来撤销。

一般事务的执行会形成5种稳定的状态，事务必须处于这5种状态之一。这5种状态是：

(1)活动状态。活动状态即事务的初始状态，事务执行时处于这个状态。

(2)部分提交状态。当操作序列的最后一条语句成功执行后，事务处于部分提交状态。这时，事务虽然已经完全执行，但由于实际输出可能还临时驻留在内存中，在事务成功完成前仍有可能出现硬件故障，事务仍有可能不得不中止。因此，部分提交状态并不等于事务成功执行。

(3)失败状态。由于硬件或逻辑等错误，使得事务不能继续正常执行后，事务就进入了失败状态。处于失败状态的事务必须回滚(ROLLBACK)。

(4)中止状态。事务回滚并且数据库恢复到事务开始执行前的状态称为中止状态。

(5)提交状态。当事务成功完成后，称事务处于提交状态。只有事务处于提交状态后，才能说事务已经提交。

我们可以在事务中执行如下的操作实现事务状态的转换：

(1)

BEGIN_TRANSACTION：开始执行事务，使事务进入活动状态。

(2)

END_TRANSACTION：说明事务中的所有读/写操作都已完成，使事务进入部分提交状态，把事务的所有操作对数据库的影响存入数据库。

(3)

COMMIT：标志事务已经成功地完成，事务中的所有操作对数据库的影响已经安全地存入数据库，事务进入提交状态，结束事务的运行。

(4)

ABORT：标志事务进入失败状态，系统撤消事务中所有操作对数据库和其他事务的影响，结束事务的运行。

事务进入中止状态后，系统一般有两种选择。一种是重启事务。当事务中止的原因是由软、硬件错误引起而不是由事务内部逻辑错误所产生时，一般采用重启事务的方法。重启事务可以被看成一个新事务。另一种是杀死事务。这样做通常是因为事务中止的原因是由于事务内部的逻辑造成的错误，或者是由于输入错误，也可能是由于所需数据在数据库中没有找到等原因。

图6.3事务的状态转换图

3．事务的调度

我们考虑一个简单的银行数据库系统。设每个账号在数据库中具有一条数据库记录，记录这个账号的存款数量和其他信息。设有两个事务T0

和T1，事务T0从账号A转2000元到账号B；事务T1从账号A转20%的款项到账号B。T0和T1的定义如下：

T0: read(A);T1:read(A);

A:=A-2000;temp:=A*0.2;

write(A);A:=A-temp;

read(B);write(A);

B:=B+2000;read(B);

write(B)。B:=B+temp;

write(B)。

说明：假设用A和B分别表示账号A和账号B的存款数量；A、B的初值为10000和20000，即初始存款数量总和为30000。

如果这两个事务顺序执行，可以有两种方案：一种是先执行T0

后执行T1，如图6.4所示，运行结束时，A和B的最终值分别是6400和23600；另一种是先执行T1后执行T0，如图6.5所示，A和B的最终值分别是6000和24000。无论采用两种方案的哪一种，事务执行结束后存款总和仍然是30000。

图6.4串行调度(先T0后T1)

图6.5串行调度(先T1后T0)通过上面这个例子，我们已经对事务的调度概念有了初步认识。下面，我们对与事务调度相关的问题进行讨论。

(1)调度(Schedule)：事务的执行次序。

(2)串行调度(SerialSchedule)：多个事务依次串行执行，且只有当一个事务的所有操作都执行完后才执行另一个事务的所有操作。

(3)并行调度(ConcurrentSchedule)：利用分时的方法，多个事务要么同时，要么相互穿插地执行，它们在执行的时间上是重叠的，即系统同时处理多个事务。从前面的例子可以看出，不论是先执行T0

后执行T1，还是先执行T1后执行T0，只要是串行调度，执行的结果都是稳定的和正确的。对于N个事务，一定最多有N!种正确的串行调度。但是，对于N个事务进行并发调度时，情况会变得复杂得多，它的调度方案远大于N!个，而且并发调度的结果有可能是错误的。图6.6是一个并发调度，它与图6.4的串行调度的结果是一样的，即这两个调度是等价的，我们称这个并发调度是正确的。图6.7也是一个并发调度，但其导致A、B的最终结果为8000和24000，A+B=8000+24000≠30000，这个结果是错误的。我们称此并行调度将产生不一致状态。

图6.6并行调度(结果正确)

图6.7并行调度(结果错误)

4．并发事务的可串行化

从前面的例子可以看出，在事务的并发调度中，如果不加限制，可能导致不能保持数据库一致性的现象。那么，如何才能产生正确的并发调度呢？下面的可串行化并行调度策略可以做到这一点。

可串行化并行调度策略：多个事务的并行执行是正确的，当且仅当其结果与按某一次序串行执行它们时的结果相同。

可串行性是并行事务正确性的唯一准则。按这个准则规定，一个给定的并发调度，当且仅当它是可串行化时，才认为是正确的调度。6.4.2并发控制

实际应用中，数据库往往作为一个重要的共享资源，不同的用户可以在不同时间或相同时间使用数据库中的数据，即数据库的并发操作，这种系统一般称为多用户数据库系统，例如飞机订票系统、银行账务系统。这种并发操作可能会带来一些问题，极有可能无法保证事务之间的隔离性，破坏数据库的一致性、正确性。因此，DBMS的一个重要任务就是要有一种机制去保证事务在并发地存取和修改数据的时候，数据的完整性不被破坏，同时确保这些事务能正确地运行并取得正确的结果。并发控制就是一种在多用户环境下，对数据库的并发操作进行规范的机制。

1．并发带来的好处和问题

1)并发的优点

并发有如下优点：

(1)改善系统的资源利用率。多个事务在执行过程中可以采用串行和并行两种方法。如果采用串行的方法，则某个时刻只有一个事务在运行，一个事务执行完之前，另一事务必须等待。但事务在执行过程中需要不同的资源(如有时需要CPU，有时存取数据库，有时需要进行I/O，有时需要通信等)，如果采用串行执行，则系统许多资源处于空闲状态。如果采用事务的并发执行，则可以交叉地利用空闲资源。因此，为了充分利用系统资源，发挥数据库共享资源的特点，应允许多个事务并行地执行，以提高整个系统的效率。

(2)改善短事务的响应时间。设想有两个事务A和B，A事务需要较长的时间才能完成，而B事务只需要较短的时间就能完成。假设A事务先开始，刚开始执行时，B事务到达等待系统执行。如果采用串行执行事务的方法，则B事务必须等到A事务执行完才能开始执行，为此B事务必须等待较长的时间。如果采用并发执行的方法，则B事务和A事务可以重叠地进行，A事务没有执行完时，往往B事务可能已经执行完了，这使多个事务的平均等待时间大大缩短，明显改善了响应时间。

2)并发所引发的问题

并发操作虽然具有提高系统资源利用率和有利于短事务运行的优点，但是在并发执行过程中，如果不对并发执行的事务通过某种机制加以控制，又有可能产生数据的不一致性等问题。

下面先来看一个例子，说明并发操作带来的数据的不一致性问题。

以飞机订票系统为例，其中的一个活动序列：

甲售票点(甲事务)读出某航班的机票余额A，设A

=

16。

乙售票点(乙事务)读出同一航班的机票余额Ａ，也为16。甲售票点卖出一张机票，修改余额A←A

-

1，所以A变为15，把Ａ写回数据库。

乙售票点也卖出一张机票，修改余额A←A

-

1，所以A也变为15，把Ａ写回数据库。

结果明明卖出两张机票，但数据库中机票余额只减少了1。这种情况称为数据库的不一致性。这种不一致性是由并发操作引起的。在并发操作情况下，对甲、乙两个事务的操作序列的调度是随机的。若按上面的调度序列执行，甲事务的修改就被丢失。这是由于第步中乙事务修改Ａ并写回后覆盖了甲事务的修改。可见，若对并发事务访问数据库的操作不进行有效控制，数据库中的数据就有可能变的不正确，从而影响数据的正确性。

经过对大量实例的分析，我们发现并发操作带来的数据不一致性通常表现为三类：丢失修改、不可重复读和读“脏”数据，如图6.8所示。

图6.8三种数据的不一致性

(a)丢失修改；(b)不可重复读；(c)读脏数据

(1)丢失修改(LostUpdate)。丢失修改是由于两个事务对同一数据并发地写入所引起的，常称为写后写冲突(Write-WriteConflict)。上面的飞机订票例子就属此类。

(2)不可重复读(Non-RepeatableRead)。不可重复读是指事务T1读取数据后，事务T2

执行更新操作，使T1无法再现前一次读取的结果。具体地讲，不可重复读包括三种情况：

①事务T1读取某一数据后，事务T2对其做了修改，当事务T1再次读该数据时，得到与前一次不同的值。例如，T1读取B=100进行运算，T2读取同一数据B，对其进行修改后将B=200写回数据库。T1为了对读取值校对，重读B，B已为200，与第１次读取值不一致。

②事务T1按一定条件从数据库中读取了某些数据记录后，事务T2删除了其中部分记录，当T1再次按相同条件读取数据时，发现某些记录神秘地消失了。

③事务T1按一定条件从数据库中读取了某些数据记录后，事务T2插入了一些记录，当T1再次按相同条件读取数据时，发现多了一些记录。

后两种不可重复读有时也称为幻影(PhantomRow)现象。

(3)读“脏”数据(DirtyRead)。读“脏”数据是指两个或多个事务并发执行时，事务T1修改了某一数据，并将其写回磁盘，事务T2在这之后读取了同一数据，此时事务T1在未正式提交之前由于某种原因被撤消，系统就要对事务T1已修改过的数据恢复原值，这样事务T2读的数据就与数据库中的数据产生了不一致，称这种数据为“脏”数据。

产生上述三类数据不一致性的主要原因是并发操作破坏了事务的隔离性。

3)并发控制的正确性准则

并发控制就是要用正确的方式调度并发操作的事务，使任何一个事务的执行不受并行的其他事务的干扰，从而避免造成数据的不一致性。由此可见，并发控制主要涉及保证并发的各个事务本身正确的问题。

但是，计算机系统对并行事务的调度是随机的，不同的调度可能产生不同的结果。这就存在怎样判断结果是正确的问题。显然，如果将所有的事务均按照某一顺序串行执行，虽然也有可能会产生不同的结果，但由于它不会将数据库置于不一致状态，因此这样产生的结果都可以认为是正确的。由此得出：几个事务的并行执行是正确的，当且仅当其结果与按某一次序串行执行事务的结果相同。

为了保证并行操作的正确性，DBMS的并行控制机制必须提供一定的手段来保证调度是可串行化的。目前流行的数据库管理系统(如Oracle，SQLServer等)普遍采用封锁机制，即加锁来保证并发事务调度的正确性。

2．封锁

封锁是实现并发控制的一个非常重要的技术。

1)封锁的定义及类型

所谓封锁，就是事务T在对某个数据对象(如表、记录等)操作之前，先向系统发出请求，对其加锁。加锁后事务T就对该数据对象有了一定的控制，在事务T释放它的锁之前，其他的事务不能更新此数据对象。加锁必须满足一定的协议，即封锁协议(LockingProtocol)。

基本的封锁类型有两种：排它锁(ExclusiveLocks，简称X锁)和共享锁(ShareLocks，简称S锁)。

·排它锁(又称写锁)：若事务T对数据对象A加上X锁，则只允许T读取和修改A，其他任何事务都不能再对A加任何类型的锁，直至T释放其锁为止。这就保证了其他事务在T释放A上的锁之前不能再读取和修改Ａ。

·共享锁(又称读锁)：若事务T对数据对象A加上S锁，则事务T可以读A但不能修改A，其他事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。这就保证了其他事务可以读A，但在T释放A上的锁之前不能对A做任何修改。表6.2封锁类型的相容矩阵在表6.2所示的封锁类型的相容矩阵中，最右边的一列表示事务T1已经获得的数据对象上的锁的类型，其中横线“－”表示没有加锁。最上面一行表示另一事务T2对同一数据对象发出的封锁请求。对T1、T2的封锁请求能否被满足用“是”和“否”表示。

2)封锁粒度

所谓封锁粒度，是指封锁对象的大小。封锁的对象可以是逻辑单元，也可以是物理单元。

例如，在关系数据库中，封锁对象可以是属性值、属性值集合、元组、索引项、整个数据库等逻辑单元；也可以是数据页、索引页或块等物理单位。

封锁粒度与系统的并发程度和并发控制的开销密切相关。选择封锁粒度时必须同时考虑封锁机构和并发程度两个因素，对系统开销和并发程度进行权衡，最终求得理想的效果。应用X锁和S锁这两种基本封锁类型对数据对象进行加锁时，还需要约定一些规则，例如何时申请X锁或S锁、

持锁的时间、

何时释放等。我们统称这些规则为封锁协议(LockingProtocol)。对封锁方式规定不同的规则，就形成了各种不同的封锁协议。

3．活锁和死锁

封锁协议解决了并发操作带来的数据不一致性问题，但也可能引起活锁和死锁问题。

1)活锁

如果事务T1封锁了数据R，事务T2又请求封锁R，于是T2等待。T3也请求封锁R，当T1释放了R上的封锁之后系统首先批准了T3的请求，T2仍然等待。然后T4又请求封锁R，当T3释放了R上的封锁之后系统又批准了T4的请求……这样，T2有可能永远等待下去，这就是活锁问题，如图6.9(a)所示。

图6.9死锁和活锁示意图(a)活锁；(b)死锁避免活锁的简单方法是采用先来先服务的策略。当多个事务请求封锁同一数据对象时，封锁子系统按请求封锁的先后次序对事务排队，数据对象上的锁一旦释放就批准申请队列中的第一个事务请求，使其获得封锁。

2)死锁

死锁指多个事务循环等待其他事务释放锁而陷入停滞状态，不借助外力干预则无法解开的状态。换句话说，如果事务T1封锁了数据R1，T2封锁了数据R2，然后T1又请求封锁R2，因T2已封锁了R2，于是T1等待释放R2上的锁。接着T2又申请封锁R1，因T1已封锁了R1，T2也只能等待T1释放R1上的锁。这样就出现了T1在等待T2，而T2又在等待T1的局面，T1和T2两个事务永远不能结束，形成死锁，如图6.9(b)所示。

采用封锁的方法能够避免事务并发处理产生的问题，但也有可能引起死锁。目前在数据库中解决死锁问题的主要方法有两类：一类是采取一定措施来预防死锁的发生；另一类是允许发生死锁，但同时采用一定手段定期诊断系统中有无死锁，若有则解除之。

预防死锁通常有两种方法：一种叫一次封锁法，它要求每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行；另一种叫顺序封锁法，它是预先对数据对象规定一个封锁顺序，所有事务都按这个顺序实行封锁。

数据库系统中诊断死锁的方法与操作系统类似，一般使用超时法或事务等待图法。

4．两段锁协议

可串行性是并发事务正确性的唯一准则。按这个准则规定，一个给定的并发调度，当且仅当它是可串行化的，才是正确的调度。

两段锁协议是保证并发调度可串行性的封锁协议。

两段锁(Two-PhaseLocking，简称2PL)协议把所有事务对数据项的加锁和解锁过程分成两个阶段：

(1)申请加锁阶段。此阶段，事务可以申请封锁，但是不能解除任何已取得的封锁。

(2)释放封锁阶段。此阶段，事务可以释放封锁，但是不能申请新的封锁。我们通常称遵守两段封锁协议的事务为“两段式事务”。可以证明，若并发执行的所有事务均遵守两段锁协议，则对这些事务的任何并发调度策略都是可串行化的。因此，所有的两段式事务，其并行执行的结果一定是正确的。

需要说明的是，事务遵守两段锁协议是可串行化调度的充分条件，但不是必要条件。也就是说，若并发事务都遵守两段锁协议，则对这些事务的任何并发调度都是可串行化的；反之，若对并发事务的一个调度是可串行化的，却不一定能保证这些事务都符合两段锁协议。图6.10中，(a)图和(b)图都是可串行化的调度，但(a)图中T1和T2都遵守了两段锁协议，(b)图中T1和T2没有遵守两段锁协议。

图6.10可串行化调度(a)遵守两段锁协议；(b)不遵守两段锁协议

5．三级封锁协议

三级封锁协议是保证数据一致性的封锁协议，不同级别的封锁协议达到的数据一致性级别是不同的。

(1)一级封锁协议：事务T在修改数据之前必须先对其加X锁，直到事务T结束(包括正常结束和非正常结束)才释放。

一级封锁协议可防止丢失修改，并保证事务T是可恢复的。根据约定，一级封锁协议中，如果仅读取数据而不对其进行修改，则不需要加锁，所以无法解决不可重复读和读“脏”数据的问题。

(2)二级封锁协议：它是在一级封锁协议的基础上再加上该事务T在读取数据R之前必须先对其加S锁，读完后即可释放S锁。

二级封锁协议除解决丢失修改问题外，还可以进一步防止读“脏”数据。但由于该协议允许读完数据后即可释放S锁，所以它不能解决不可重复读问题。

(3)三级封锁协议：它是在一级封锁协议的基础上再加上该事务T在读取数据R之前必须先对其加S锁，直到事务结束才释放S锁。

三级封锁协议除防止了丢失修改和读“脏”数据外，还进一步防止了不可重复读。

上述三级协议的主要区别在于什么操作需要申请封锁，以及何时释放锁(即持锁时间)。应用三个级别的封锁协议解决数据不一致性问题的说明示例如图6.11所示，三个级别的封锁协议可以总结为如图6.12所示。

图6.11三级封锁协议解决数据不一致性的示例

(a)解决丢失修改；(b)可重复读；(c)不读“脏”数据

图6.12不同级别的封锁协议的总结

尽管数据库系统中采取了各种保护措施来防止数据库的安全性和完整性被破坏，保证并发事务的正确执行，但是计算机系统中硬件的故障(如磁盘损坏、电源故障)、软件的错误、操作人员的失误以及某些恶意的破坏仍是不可完全避免的。6.5数 据 库 恢 复这些故障轻则造成运行事务非正常中断，影响数据库中数据的正确性；重则破坏数据库，使数据库中全部或部分数据丢失。因此，DBMS必须保证事务的原子性，一旦出现错误，具有把数据库从错误状态恢复到某个已知的正确状态(又称为一致状态或完整状态)的功能，这就是数据库的恢复。

数据库恢复技术是一种被动的保护方法，而数据库的安全性、完整性和并发控制则是一种主动的保护方法，这两种方法的有机结合才能使数据库得到有效的保护。

数据库恢复原理是建立在事务基础之上的，而实现恢复的基本思想是使用存储在另一个系统中的“冗余”数据以及事先建立起来的日志文件，重新构建数据库中已经被损坏的数据，或者修复数据库中已经不正确的数据。6.5.1故障的种类

破坏事务原子性和引起数据库错误的原因很多，大致可以分为以下几类：

1．事务内部的故障(简称事务故障)

事务故障指由于事务没有达到预期的终点，导致数据库可能处于一种不正确的状态。事务故障有的是可以通过事务程序本身发现的(见下面转账事务的例子)，有的是非预期的，不能由事务程序处理的。例如，银行转账事务，该事务把一笔资金从账户甲转给账户乙：

BEGINTRANSACTION

读账户甲的余额BALANCE

BALANCE=BALANCE-AMOUNT；(AMOUNT为转账金额)

IF(BALANCE<0)THEN

｛打印'金额不足，不能转帐'；

ROLLBANCK;(撤销刚才的修改，恢复事务)｝

ELSE

{读账户乙的余额BALANCE1；

BALANCE1=BALANCE1+AMOUNT；

写回BALANCE1；

COMMIT；}

ENDIF

这个例子所包括的两个更新操作要么全部完成要么全部不做，否则就会使数据库处于不一致状态。例如，只把账户甲的余额减少了而没有把账户乙的余额增加。

在这段程序中，若产生账户甲余额不足的情况，应用程序可以发现并让事务滚回，并撤销已做的修改，恢复数据库到正常状态。事务故障更多的是非预期的，是不能由应用程序处理的。如运算溢出、并发事务发生死锁而被撤销、违反了某些完整性限制等，称这类事务故障为非预期的故障。

发生事务故障时，夭折的事务可能对数据库已经做了部分修改并写回磁盘。恢复程序的作用就是要在不影响其他事务运行的情况下，强行滚回(ROLLBACK)该事务，即撤销该事务已经做出的任何对数据库的修改，使得该事务好像根本没有启动一样。这类恢复操作称为事务撤销(UNDO)。

2．系统故障

系统故障(通常称为软故障，SoftCrash)是指在造成系统停止运转的任何事件(如硬件故障、操作系统错误、DBMS代码错误、突然停电等)的影响下，造成正在运行的事务都以非正常的方式终止所引起的内存信息丢失，但磁盘数据不受影响，数据库不至于遭到破坏，致使系统需要重新启动的故障。

这类故障发生时，内存内容，尤其是数据库缓存区(在内存)中的内容将可能丢失，所有运行事务都非正常终止。这时，数据的不一致性会表现为如下两种现象：

(1)一些尚未完成的事务的结果可能已送入物理数据库，从而造成数据库可能处于不正确的状态。为保证数据一致性，需要清除这些事务对数据库的所有修改。但由于无法确定哪些事务已更新过数据库，因此，恢复子系统必须在系统重新启动时让所有非正常终止的事务回滚，强行撤销(UNDO)所有未完成事务。

(2)有些已完成的事务可能有一部分甚至全部数据留在缓冲区，尚未写回到磁盘上的物理数据库中，系统故障将导致这些事务对数据库的修改部分或全部丢失，也会使数据库处于不一致状态，因此应将这些事务已提交的结果重新写入数据库。所以系统重新启动后，恢复子系统除需要撤销所有未完成事务外，还需要重做(REDO)所有已提交的事务，以将数据库真正恢复到一致状态。

系统故障的影响范围是各个事务，即某些事务要重做，某些事务要撤销，但是它不需要对整个数据库做全面的恢复，所以此类故障属于中型故障。

3．介质故障

介质故障(通常又称为硬故障，HardCrash)是指外存故障，如磁盘损坏、磁头碰撞、瞬时强磁场干扰等引起磁盘内容读不出来，最终导致存储在外存中的数据部分丢失或全部丢失的故障。这类故障将破坏整个数据库或部分数据库，并影响正在存取这部分数据的所有事务。这类故障比前两类故障发生的可能性小得多，但破坏性最大。

发生介质故障时，只能重新装入发生故障前的数据备份，并重新执行。

4．计算机病毒

计算机病毒是一种人为的故障或破坏，是一些恶作剧者研制的一种计算机程序。这种程序与其他程序不同，它像微生物学所称的病毒一样可以繁殖和传播，并造成对计算机系统，包括数据库的危害。

计算机病毒已成为计算机系统的主要威胁，自然也是数据库系统的主要威胁。为此，计算机安全工作者已经研制了许多预防病毒的“疫苗”，检查、诊断、消灭计算机病毒的软件也在不