第8章 数据库管理 南昌大学科学技术学院 讲课老师：王钟庄 2010年7月 数据库原理与应用教程.

Presentation on theme: "第8章 数据库管理 南昌大学科学技术学院 讲课老师：王钟庄 2010年7月 数据库原理与应用教程."— Presentation transcript:

1 第8章 数据库管理 南昌大学科学技术学院 讲课老师：王钟庄 2010年7月 数据库原理与应用教程

2 数据库管理目录 8.1 数据库中事务的概念 8.2 数据库的恢复 8.3 数据库的并发控制 8.4 数据库的完整性 8.5 数据库的安全性
本章小结 数据库原理与应用教程

3 数据库管理 数据库管理系统要保证数据库及整个系统的正常运转，确保数据的安全性、完整性、并在多用户同时使用数据库时进行并发控制，以及当数据库受到破坏后能及时恢复正常，这就是数据库管理系统要履行的职责。本章首先介绍事务概念及其特性，然后讲述安全性控制、完整性控制、并发性控制和数据库恢复技术四个方面,介绍数据库管理系统的功能及实现这些功能的方法。 数据库原理与应用教程

4 8.1 数据库中事务的概念 事务是一系列的数据库操作，是数据库应用程序的基本逻辑单元。事务处理技术主要包括数据库恢复技术和并发控制技术。数据库恢复机制和并发控制机制是数据库管理系统的重要组成部分。在讨论数据恢复技术和并发控制技术之前先讲解事务的基本概念和事务的性质。 数据库原理与应用教程

5 8.1.1事务的基本概念 1．事务的概念 事务是用户定义的一个数据操作序列，这些操作要么全做，要么全不做，是一个不可分割的工作单位。
一个事务可以是一条SQL语句、一组SQL语句或整个程序，一个程序中可以包含多个事务。事务的开始与结束可以由用户显式控制。如果用户没有显式地定义事务，则由DBMS按缺省规定自动划分事务。 在SQL语言中，定义事务的语句有三条：①BEGIN TRANSACTION；②COMMIT；③ROLLBACK。事务通常是以BEGIN TRANSACTION开始；以COMMIT 表示事务的提交，即表示提交事务的所有操作，将事务中所有对数据库的更新写回到磁盘上的物理数据库中去，事务正常结束；ROLLBACK表示事务的回滚，即在事务运行的过程中发生了故障，事务不能继续执行，系统将事务中对数据库的所有已完成的操作全部撤销，回滚到事务开始时的状态。 数据库原理与应用教程

6 (1)原子性（Atomicity）：一个事务是一个不可分割的工作单位，事务中包括的操作要么都做，要么都不做，即不允许事务部分完成。
2．事务的特性 事务具有四个特性：原子性（Atomicity）、一致性(Consistency)、隔离(Isolation)和持续性(Durability)。这四个特性也简称为ACID特性。 (1)原子性（Atomicity）：一个事务是一个不可分割的工作单位，事务中包括的操作要么都做，要么都不做，即不允许事务部分完成。 (2)一致性(Consistency)：事务对数据库的操作必须使数据库从一个一致性状态变成另一个一致性状态。因此，只有当事务成功提交的结果时，就说数据库处于一致性状态。如果数据库系统运行中发生故障，有些事务还没有完成就被迫中断，这些没有完成的事务对数据库所做的修改有一部分已写入物理数据库，这时数据库就处于一种不一致的状态。 (3)隔离性(Isolation)：一个事务的执行不能被其它事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的。 (4)持续性(Durability)：指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。即使数据库因其它操作或故障而受到破坏，都不应对结果有任何影响。 数据库原理与应用教程

7 BALANCE=BALANCE-AMOUNT；(AMOUNT为转帐金额) IF（BALANCE<0）THEN
事务上述4个性质的英文第一个字母分别为A、C、I、D。因此，这4个性质也称为事务的ACID准则。下面是一个银行转帐事务，这个事务把一笔金额从一个帐户甲转给另一个帐户乙。 BEGIN TRANSACTION READ BALANCE；(帐户甲) BALANCE=BALANCE-AMOUNT；(AMOUNT为转帐金额) IF（BALANCE<0）THEN DISPLAY“BALANCE余额不足” ROLLBACK ELSE BALANCE1=BALANCE1+AMOUNT (帐户乙) COMMIT END 数据库原理与应用教程

8 8.2 数据库的恢复 尽管数据库系统中已采取各种各样的措施来防止数据库的安全性和完整性不被破坏，但是数据库中的数据仍然无法保证绝对不遭到破坏，比如计算机系统中硬件的故障、软件的错误、操作员的失误、恶意的破坏等都不可避免，一旦数据库损坏，将会带来巨大的损失，所以数据库恢复越来越重要，因此，数据库管理系统必须能够把数据库从错误状态恢复到某一已知的正确状态，这就是数据库的恢复。 数据库原理与应用教程

9 8.2.1事务的故障 在讲恢复的实现技术之前，我们首先来了解一下在数据库系统中都有哪些故障。数据库系统在运行过程中可能发生各种各样的故障，大致可以分为以下几类： 1．事务故障 事务故障表示由非预期的、不能由事务程序本身发现的故障。如输入数据错误、运算溢出、违反某些完整性限制、并行事务发生死锁等。 发生事务故障时，事务没有达到预期的终点（COMMIT或是显式的ROLLBACK），被迫中断的事务可能已对数据库进行了修改，为了消除对数据库的影响，强行回滚（ROLLBACK）该事务，将数据库恢复到修改前的初始状态，使得事务像没有启动一样。 数据库原理与应用教程

10 一种情况是一些未完成事务的结果已写入数据库，这样在系统重新启动后。要强行撤销（UNDO）所有未完成事务，清除这些事务对数据库所做的修改。
2．系统故障 系统故障是指由于某种原因造成整个系统的正常运行突然停止，致使所有正在运行的事务都以非正常方式终止，系统要重新启动。引起系统故障的原因可能有：硬件错误（CPU故障）、操作系统故障、DBMS代码错误、突然断电等。这时，数据库缓冲区的内容丢失，存储在外部存储设备上的数据库并未被破坏，但内容不可靠了。系统故障发生后，对数据库的影响有以下两种情况。 一种情况是一些未完成事务的结果已写入数据库，这样在系统重新启动后。要强行撤销（UNDO）所有未完成事务，清除这些事务对数据库所做的修改。 另一种情况是有些已提交的事务对数据库的更新结果还保留在缓冲区中，尚未写到磁盘上的物理数据库中，这也使用数据库处于不一致状态，因此应将这些事务已提交的结果重新写入数据库。所以系统重新启动后，恢复子系统除需要撤销所有未完成事务外，还需要重做（REDO）所有已提交的事务，以将数据库真正恢复到一致状态。 数据库原理与应用教程

11 介质故障是指系统在运行过程中，由于外存储器受到破坏，使储存在外存储器中的数据部分丢失或全部丢失。这类故障发生的可能性要小，但破坏性很大。
3．介质故障 介质故障是指系统在运行过程中，由于外存储器受到破坏，使储存在外存储器中的数据部分丢失或全部丢失。这类故障发生的可能性要小，但破坏性很大。 4．计算机病毒 计算机病毒是一种人为的故障或破坏，是一种带有对计算机产生破坏的程序。 通过以上对4类故障的分析可以看出，故障发生后对数据库的影响有两种可能性。 一是数据库本身被破坏。二是数据库没有破坏，但数据可能不正确，这是因为事务的运行被非正常终止造成的。 接下来，我们将介绍如何通过数据库恢复技术来解决这些事务故障，使数据库回到一致性的状态。恢复的基本原理十分简单。就是用冗余技术。数据库中任何一部分被破坏的或不正确的数据可以根据存储在系统别处的冗余数据来重建。尽管恢复的基本原理很简单，但实现技术的细节相当复杂，下面介绍数据恢复的实现技术。 数据库原理与应用教程

12 8.2.2数据库恢复的基本原理及实现技术 数据库恢复技术的基本原理十分简单，就是如何利用数据的冗余。数据库中任何一部分被破坏的或不正确的数据都根据存储在系统别处的冗余数据来重建。恢复技术应该解决二个问题就可以做到数据的恢复：一种是如何建立冗余数据，即对可能发生的故障作某些准备；另一种如何利用这些冗余数据实施数据库恢复。 建立冗余数据最常用的技术是数据转储和登记日志文件，通常在一个数据库系统中，这两种方法结合起来一起使用。 数据库原理与应用教程

13 转储是十分耗费时间和资源的，不能频繁的进行，数据库管理员应该根据数据库实际使用情况来确定一个适当的转储周期。
1．数据转储 数据转储是指数据库管理员定期地将整个数据库复制到磁盘或其它磁盘上保存起来的过程，它是数据库恢复中采用的基本方法。这些转存数据称为后备副本或后援副本，当数据库遭到破坏后就可利用后援副本。 转储是十分耗费时间和资源的，不能频繁的进行，数据库管理员应该根据数据库实际使用情况来确定一个适当的转储周期。 按照转储方式转储可以分为海量转储和增量转储。海量转储是指每次转储全部数据库；增量转储每次只转储上一次转储后被更新过的数据。利用海量转储得到的后备副本进行恢复的话，一般说来会更方便，但是如果数据库内容多，事务处理又十分频繁，则增量转储方式更实用。 数据库原理与应用教程

14 按照转储状态，转储又可以分为静态转储和动态转储。静态转储期间不允许对数据库存取、修改活动，因而必须等待当前用户正在进行的事务结束后进行，新用户事务又必须在转储结束之后才能进行，这就降低了数据库的可用性；动态转储则不同，它允许在转储期间对数据库进行存取或修改，可以克服静态转储的缺点，但产生的后援副本不能保证正确有效。为了尽量避免数据的不正确性，可以把转储期间各事务对数据库的修改活动登记下来，建立日志文件。因此，备用副本加上日志文件就能把数据库恢复到某一时刻的正确状态。 2．登记日志文件 日志文件（Logging）是用来记录事务对数据库更新操作的文件。日志文件在数据库恢复中起着非常重要的作用。可以用它来对事务故障和系统故障进行恢复，并协助后授副本进行介质故障的恢复。不同数据库采用的日志文件格式并不完全一样。 数据库原理与应用教程

15 对于以记录为单位的日志文件，日志文件需要登记的内容包括： ①各个事务的开始； ②各个事务的结束； ③各个事务的所有更新操作；
这里每个事务开始的标记、每个事务的结束标记和每个更新操作均作为日志文件中的一个日志记录。 典型的日志记录主要包含以下内容： ①事务标识（标明是哪个事务）； ②操作的类型（插入、删除或修改）； ③操作对象（记录内部标识）； ④更新前数据的旧值（对于插入操作而言；此项为空值）； ⑤更新后数据的新值（对于删除操作而言，此项为空值）； 数据库原理与应用教程

16 为保证数据库是可恢复的，登记日志文件必须遵循两条原则： ⑴登记的次序严格按并发事务执行的时间次序。 ⑵必须先写日志文件，后写数据库。
为什么一定要遵循这两条原则呢？因为对数据的修改写入数据库中和把修改的日志记录写到日志文件中是二个不同的操作。如果先进行日志记录的修改，一旦出现故障，之前只对日志文件中登记了所做的修改，但没有修改数据库，这样在系统重新启动进行恢复时，只是撤销或重新做因发生事故而没有做过的修改，并不会影响数据库的正确性。而如果先写了数据库修改，而在运行记录中没有登记这个修改，则以后就无法恢复这个修改了，所以为了安全，一定要先写日志文件，后写数据库的修改。 数据库原理与应用教程

17 SQL Server2005提供以下完善的备份和还原功能： (1)完整数据库备份是数据库的完整副本； (2)事务日志备份公复制事务日志；
在大型的数据库管理系统当中，如SQL Server2005，就含有日志备份功能。SQL Server2005 的备份和还原组件使用户得以创建数据的副本。可将此副本存储在某个位置，以便一旦运行SQL Server实例的服务出现故障使用。如果运行SQL Server实例的服务器出现故障，或者数据库遭到某种程度的损坏，可以用备份副本重新创建或还原数据库。 SQL Server2005提供以下完善的备份和还原功能： (1)完整数据库备份是数据库的完整副本； (2)事务日志备份公复制事务日志； (3)差异备份仅复制自上一次完整数据库备份之后修改过的数据库页； (4)文件或文件组还原仅允许恢复数据库中位于故障磁盘上的那部分数据。这些选项允许根据数据库中数据的重要程度调整备份和还原进程。 数据库原理与应用教程

18 8.2.3故障恢复策略 1．事务故障的恢复 事务故障是指事务在运行至正常结束前被终止，这时恢复子系统应利用日志文件撤销此事务已对数据库进行的修改。这类恢复操作称为事务撤销（UNDO），具体恢复步骤是： （1）反向扫描日志文件，查找该事务的更新操作。 （2）对该事务的更新操作执行反向操作，即对已经插入的新记录进行删除操作，对已经删除的记录进行插入操作，对修改的数据恢复旧值，这样由后向前逐个扫描该事务做完所有更新操作，并做同样处理，直到扫描到此事务的开始标记，事务故障恢复完毕。 数据库原理与应用教程

19 2．系统故障的恢复 前面已经介绍过，系统故障造成数据库不一致状态的原因有两个，一是未完成事务对数据库的更新可能已写入数据库，二是已提交事务对数据库的更新可能还留在缓冲区还没写入数据库。因此系统故障的恢复既要撤销所有未完成的事务，还需要重做所有已提交的事务，这样才能将数据库真正恢复到一致的状态。具体做法如下： (1)正向扫描日志文件，查找已经提交的事务，将其事务标识记入重做（REDO）队列；同时查找尚未提交的事务，将其事务标识记入撤销（UNDO）队列。 (2)对撤销队列中的各个事务进行撤销（UNDO）处理，对该事务的更新操作执行反向操作，即对已经插入的新记录进行删除操作，对已经删除的记录进行插入操作，对修改的数据恢复旧值，这样由后向前逐个扫描该事务，做完所有更新操作，并做同样处理，直到扫描到此事务的开始标记。 (3)对重做队列中的各个事务进行重做（REDO）处理，进行REDO处理的方法是：正向扫描日志文件，对每个REDO事务重新执行日志文件登记的操作。 数据库原理与应用教程

20 (1)装入最新的数据库后备副本，使数据库恢复到最近一次转储时的一致性状态。
3．介质故障的恢复 发生介质故障后，磁盘上的所有数据都会被破坏，这是最严重的一种故障，破坏性很大，恢复方法是装入发生介质故障前最新的后备副本，然后利用日志文件重做已完成的事务。具体方法如下。 (1)装入最新的数据库后备副本，使数据库恢复到最近一次转储时的一致性状态。 (2)装入最新的日志文件后备副本，根据日志文件中的内容重做已完成的事务。首先扫描日志文件，找出故障发生时已提交的事务，将其记入重做队列。然后正向扫描日志文件，对每个重做队列中的所有事务进行重做处理，即将日志记录中“更新后的值”写入数据库。这样就可以将数据库恢复至故障前某一时刻的一致状态。 数据库原理与应用教程

21 8.3 数据库的并发控制 数据库最大特点就是资源的共享，可以供多个用户使用。例如火车订票系统、银行数据库系统等都是多用户数据库系统。在这样的系统中，在同一时刻并行运行的事务可达数百个。如果对并发操作不加控制的话，可能会产生操作冲突，破坏数据的完整性。即发生所谓的丢失修改、污读、不可重复读等问题。数据库的并发控制机制能解决这类问题，以保持数据库中数据在多用户并发操作时的一致性、正确性。 数据库原理与应用教程

22 8.3.1并发控制概述 前面，我们介绍到，事务是并发控制的基本单位，保证事务ACID特性是事务处理的重要任务，而事务ACID特性可能受到破坏的原因之一是多个事务对数据库的并发操作造成的。为了保证数据库的一致性，DBMS必须对并发操作进行调度。这就是数据库管理系统中并发控制的责任。 下面先来看个例子，说明并发操作带来的数据的不一致性问题。 数据库原理与应用教程

23 ①甲售票点（甲事务）读出某一客运班线的车票余额R，设R=30。 ②乙售票点（乙事务）读出同一客运班线的车票余额R，也为R=30。
例8.1 并发售票操作。 ①甲售票点（甲事务）读出某一客运班线的车票余额R，设R=30。 ②乙售票点（乙事务）读出同一客运班线的车票余额R，也为R=30。 ③甲售票点卖出一张车票，修改余额R=R-1=29，把R=29写回数据库。 ④乙售票点卖出一张车票，修改余额R=R-1=29，把R=29写回数据库。 结果两个事务共售出2张票，但是数据库中的车票只减少1张。得到这种错误情况是由数据库的并发操作所引起的，数据库的并发操作导致数据库不一致性有以下3种情况。 数据库原理与应用教程

24 1．丢失修改 当两个或多个事务选择同一数据，并且基于最初选定的值更新该数据时，会发生丢失修改问题。每个事务都不知道其它事务的存在。最后的更新将重写由其它事务所做的更新，这将导致数据丢失。上面预定车票的例子就属于这种并发问题。事务1与事务2先后读入同一数据R=30，事务1执行R-1，并将结果A=29写回，事务2执行R-1，并将结果R=29写回。事务2提交的结果覆盖了事务1对数据库的修改，从而使事务1对数据库的修改丢失了，具体见表8.1所示。 数据库原理与应用教程

25 表8.1丢失修改问题 时间 事务1 R的值 事务2 T0 30 T1 FIND R T2 T3 R=R-1 T4 T5 UPDATE R
29 T7 数据库原理与应用教程

26 2．污读 一个事务读取了另一个未提交的并行事务写的数据。当第二个事务选择其它事务正在更新的时候，会发生未确认的相关性问题。第二个事务正在读取的数据还没有确认并且可能由更新此行的事务所更改。换句话说，当事务1修改某一数据，并将其写回磁盘，事务2读取同一数据后，事务1由于某种原因被撤销，这时事务1已修改过的数据恢复原值，事务2读到的数据就与数据库中的数据不一致，是不正确的数据，称为污读，具体见表8.2所示。 数据库原理与应用教程

27 时间 事务1 R的值 事务2 T0 30 T1 FIND R T2 R=R-1 T3 UPDATE R T4 29 T5 ROLLBACK
表8.2污读问题 数据库原理与应用教程

28 3．不可重复读 一个事务重新读取前面读取过的数据，发现该数据已经被另一个已提交的事务修改过。即事务1读取某一数据后，事务2对其做了修改，当事务1再次读数据时，得到的与第一次不同的值，具体见表8.3所示。 数据库原理与应用教程

29 时间 事务1 R的值 事务2 T0 30 T1 FIND R T2 T3 R=R-1 T4 29 UPDATE R T5
表8.3不可重复读问题 数据库原理与应用教程

30 产生上述3类数据不一致的主要原因就是并发操作破坏了事务的隔离性。并发控制就是要求DBMS提供并发控制功能以正确的方式高度并发事务，避免并发事务之间的相互干扰造成数据的不一致性，保证数据库的完整性。
数据库原理与应用教程

31 8.3.2封锁及其解决问题的办法 封锁是事务并发控制的一个非常重要的技术。所谓封锁就是事务T在对某个数据对象操作之前，先向系统发出请求，对其加锁。加锁后事务T就对数据库对象有了一定的控制，在事务T释放它的锁之前，其他事务不能更新此数据对象。 1.封锁类型 DBMS通常提供了多种数据类型的封锁。一个事务对某个数据对象加锁后究竟拥有什么样的控制是由封锁类型决定的。基本的封锁类型有两种：排他锁（Exclusive lock，简记为X锁）和共享锁（Share lock简记为S锁） 排他锁又称为写锁。若事务T对数据对象R加上X锁，则只允许T读取和修改R，其他任何事务都不能再对R加任何类型的锁，直到T释放R上的锁。这就保证了其他事务在T释放R上的锁之前不能再读取和修改R。 数据库原理与应用教程

32 共享锁又称为读锁。若事务T对数据对象R加上S锁，则其他事务只能再对R加S锁，而不能加X锁，直到T释放R上的锁。这就保证了其他事务可以读R，但在T释放R上的S锁之前不能对R做任何修改。
2.封锁协议 封锁的目的是为了保证能够正确地调度并发操作。为此，在运用X锁和S锁这两种基本封锁，对一定粒度的数据对象加锁时，还需要约定一些规则，例如，应何时申请X锁或S锁、持锁时间、何时释放等。我们称这些规则为封锁协议（locking protocol）。对封锁方式规定不同的规则，就形成了各种不同的封锁协议，它们分别在不同的程度上为并发操作的正确调度提供一定的保证。本节介绍保证数据一致性的三级封锁协议。 数据库原理与应用教程

33 对并发操作的不正确调度可能会带来三种数据不一致性：丢失更新、污读、不可重复读。三级封锁协议分别在不同程度上解决了这一问题。 ①一级封锁协议 一级封锁协议的内容是：事务T在修改数据R之前必须先对其加X锁，直到事务结束才释放。事务结束包括正常结束（COMMIT）和非正常结束（ROLLBACK）。 一级封锁协议可以防止丢失或覆盖更新，并保证事务T是可以恢复的。例如，表8.4使用一级封锁协议解决了定车票例子的丢失修改问题。 数据库原理与应用教程

34 时间 事务1 R的值 事务2 T0 XLOCK R 30 T1 FIND R T2 T3 R=R-1 WAIT T4 UPDATE R T5
UNLOCK R 29 T6 T7 T8 T9 28 表8.4无丢失修改问题 数据库原理与应用教程

35 在一级封锁协议中，如果仅仅是读数据不对其进行修改，是不需要加锁的，所以它不能保证可重复读和脏读。 ②二级封锁协议
上图中，事务1在读R进行修改之前先对R加X锁，当事务2再请求对R加X锁时被拒绝，只能等事务1释放R上的锁。事务1修改值R=29写回磁盘，释放R上的X锁后，事务2获得对R的X锁，这时他读到的R已经是事务1更新过的值29，再按此新的R值进行运算，并将结果值A=28回到磁盘。这样就避免了丢失事务1的更新。 在一级封锁协议中，如果仅仅是读数据不对其进行修改，是不需要加锁的，所以它不能保证可重复读和脏读。 ②二级封锁协议 二级封锁协议的内容是：在一级封锁协议的基础上，另外加上事务T在读取数据R之前必须先对其加S锁，读完后即可释放S锁。 二级封锁协议除防止了丢失问题，还可进一步防止污读。例如，表8.5使用二级封锁协议解决了污读的问题。 数据库原理与应用教程

36 时间 事务1 R的值 事务2 T0 XLOCK R 30 T1 FIND R T2 T3 R=R-1 T4 UPDATE R T5 29
SLOCK R T6 ROLLBACK WAIT T7 UNLOCK R T8 T9 UNLOCK S 表8.5无污读问题 数据库原理与应用教程

37 在二级封锁协议中，由于读完数据后即可释放S锁，所以它不能保证可重复读。 ③三级封锁协议
事务1在对R进行修改之前，先对R加X锁，修改其值后写回磁盘。这时事务2请求R加上S锁，因事务1已在R上加了X锁，事务2只能等待事务1释放它。之后事务1因某种原因被撤销，R恢复为原值30，并释放R上的X锁。事务2获得R上的S锁，读R=30。这就避免了事务2污读数据。 在二级封锁协议中，由于读完数据后即可释放S锁，所以它不能保证可重复读。 ③三级封锁协议 三级封锁协议的内容是：1级封锁协议加上事务T在读取数据之前必须先对其加S锁，直到事务结束才释放。 三级封锁协议除防止丢失或覆盖更新和不污读数据外，还进一步防止了不可重复读例如表8.6所示，使用三级封锁协议解决了可重复读。 数据库原理与应用教程

38 时间 事务1 R的值 事务2 T0 30 T1 SLOCK R T2 FIND R T3 XLOCK R T4 WAIT T5 COMMIT
UNLOCK S T7 T8 FIND T9 R=R-1 T10 29 UPDATE R T11 UNLOCK X 数据库原理与应用教程 表8.6可重复读问题

39 3.封锁粒度 X锁和S锁都是加在某一个数据对象上的。封锁的对象可以是逻辑单元，也可以是物理单元。例如，在关系数据库中，封锁对象可以是属性值、属性值集合、元组、关系、索引项、整个索引、整个数据库等逻辑单元；也可以是页（数据页或索引页）、块等物理单元。封锁对象可以很大，比如对整个数据库加锁，也可以很小，比如只对某个属性值加锁。封锁对象的大小称为封锁的粒度（lock granularity）。 封锁粒度与系统的并发度和并发控制的开销密切相关。封锁的粒度越大，系统中能够被封锁的对象就越小，并发度也就越小，但同时系统开销也越小；相反，封锁的粒度越小，并发度越高，但系统开销也就越大。 数据库原理与应用教程

40 前面介绍的封锁技术有效地解决了并行操作引起的数据不一致性问题，但也产生新的问题，即可能产生活锁和死锁问题。
因此，如果在一个系统中同时存在不同大小的封锁单元供不同的事务选择使用是比较理想的。而选择封锁粒度时必须同时考虑封锁机构和并发度两个因素，对系统开销与并发度进行权衡，以求得最优的效果。一般说来，需要处理大量元组的用户事务可以以关系为封锁单元；需要处理多个关系的大量元组的用户事务可以以数据库为封锁单位；而对于一个处理少量元组的用户事务，可以以元组为封锁单位以提高并发度。 4.死锁和活锁 前面介绍的封锁技术有效地解决了并行操作引起的数据不一致性问题，但也产生新的问题，即可能产生活锁和死锁问题。 数据库原理与应用教程

41 (1)活锁 如果事务T1在对数据R 封锁后，事务T2又请求封锁R，于是T2等待。T3也请求封锁R。当T1释放了R上的封锁后，系统首先批准了T3的请求，T2继续等待。然后又有T4请求封锁R，T3释放了R上的 封锁后，系统又批准了T4的请求，以此类推，T2可能永远处于等待状态，从而发生了活锁，如表8.7所示。 数据库原理与应用教程

42 时间 事务T1 事务T2 事务T3 事务T4 T0 LOCK R - T1 … T2 WAIT T3 UNLOCK T4 T5 T6 T7
表8.7 活锁 数据库原理与应用教程

43 避免活锁的简单方法是采用先来先服务的策略。当多个事务请求封锁同一数据对象时，封锁子系统按请求封锁的先后次序对事务排队，数据对象上的锁一旦释放就批准申请队列中第1个事务获得锁。
(2)死锁 如果事务T1在对数据R1封锁后，又要求对数据R2封锁，而事务T2已获得对数据R2的封锁，又要求对数据R1封锁，这样就出现了T1在等待T2，而T2又在等待T1的局面，T1和T2两个事务永远不能结束，形成死锁。如果表8.8所示。 数据库原理与应用教程

44 时间 事务T1 事务T2 T0 LOCK R1 - T1 LOCK R2 T2 T3 T4 WAIT T5 T6 T7 表8.8死锁
数据库原理与应用教程

45 一次加锁虽然可以有效地预防死锁的发生，但也存在一些问题。
(3)死锁的预防 在数据库中，产生死锁的原因是两个或多个事务都已经封锁了一些数据对象，然后又都请求对已为其他事务封锁的数据对象加锁，从而出现死等待。防止死锁的发生其实就是要破坏产生死锁的条件。死锁的预防有两种方法： ①一次加锁法 一次加锁法是要求每个事务必须将所有要使用的数据对象依次全部加锁，否则就不能继续执行。如事务T1启动后，立即对数据R1和R2依次加锁，加锁成功后，执行T1，而事务T2等待。直到T1执行完后释放R1和R2上的锁，T2继续执行。这样就不会发生死锁。 一次加锁虽然可以有效地预防死锁的发生，但也存在一些问题。 第一，对某一事务所要使用的全部数据一次性加锁，扩大了封锁的范围，从而降低了系统的并发度。第二，数据库中的数据是不断变化的，原来不要求封锁的数据，在执行过程中可能会变成封锁对象，所以很难事先精确地确定每个事务所要封锁的对象，这样只能在开始扩大封锁范围，将可能要封锁的数据全部加锁，这就进一步降低了并发度。 数据库原理与应用教程

46 ②顺序加锁法 顺序加锁法是预先对数据对象规定一个加锁顺序，每个事务都需要按此顺序加锁。如T1先封锁R1，再封锁R2。当T2再请求封锁R1时，因为T1已对R1加锁，T2只能等待。待T1释放R1后，T2再封锁R1，则不会发生死锁。 顺序加锁法虽然有效防止了死锁，但也存在一些问题。首先，数据库系统中封锁的对象极多，并且在运行过程中不断变化，要维护这样一种封锁顺序比较困难，成本很高。其次，随着事务的执行而动态地决定，所以很难事先确定封锁对象，因此也就很难按规定的顺序去施加封锁。 数据库原理与应用教程

47 数据库系统中诊断死锁的方法与操作系统类似。一般采用超时法或事务等待图法来诊断系统中是否存在死锁。 ①超时法
(4)死锁的诊断与解除 数据库系统中诊断死锁的方法与操作系统类似。一般采用超时法或事务等待图法来诊断系统中是否存在死锁。 ①超时法 如果一个事务的等待时间超过了规定的时限，就认为发生了死锁。超时法实现简单，但是有其不足之处。一是有可能误判死锁，因为事务等待时间超过时限，系统会误认为发生了死锁。二是时限若设置得太长，死锁发生后不能及时发现。 ②等待图法 事务T1需要数据R1，但R1已被事务T2封锁，那么从T1到T2画一个箭头，事务T2需要数据R2，但R2已被事务T1封锁，那么从T2到T1画一个箭头。如果事务依赖图中沿着箭头方向存在一个循环，那么死锁的条件就形成了，系统就会出现死锁。 数据库原理与应用教程

48 在解除死锁的过程中，抽取牺牲事务的标准时根据系统状态及其实际情况来确定的，通常采用的方法之一是选择一个处理死锁代价最小的事务，将其撤销。
SQL Server2005使用加锁技术确保事务完整性和数据库一致性。锁定可以防止用户读取正在由其他用户更改的数据，并可以防止多个用户同时更改相同数据。 数据库原理与应用教程

49 8.4 数据库的完整性 数据库的完整性是指保护数据库中数据的正确性和相容性。数据库完整性由各种各样的完整性约束来保证，因此可以说数据库完整性设计就是数据库完整性约束的设计。数据库完整性约束可以通过DBMS或应用程序来实现。 数据库原理与应用教程

50 8.4.1数据库完整性约束条件的分类 完整性约束条件作用对象可以是关系、元组、列。其中列约束主要是列的数据类型，取值范围，精度，是否为空等等；元组约束是元组之间列的约束关系；关系约束是指关系中元组之间以及关系和关系之间的约束。 完整性约束从约束对象的状态可分为静态约束和动态约束。 1．静态约束 静态约束从约束条件使用的对象来分，可以分为值的约束和结构约束。 (1)值的约束 值的约束是对一个列的取值域的说明，这是最常用也最容易实现的一类完整性约束， 数据库原理与应用教程

51 ①对数据类型的约束，包括数据的类型，长度，单位，精度等。
例如：姓名类型为字符型，长度为 8。货物重量单位为公斤(kg)，类型为数值型，长度为24位，精度为小数点后4位。 ②对数据格式的约束 例如：出生日期的格式为'YYYY-MM-DD'。学生学号的格式共八位，前两位为入学年份，中间两位是院系编号，后面四位是顺序编号。 ③对取值范围或取值集合的约束 例如：学生成绩的取值范围位0～100，性别的取值集合为[男，女]。 ④对空值的约束 空值表示未定义或未知的值，与零值和空格不同，可以设置列不能为空值。 例如：学生学号不能为空值，而学生成绩可以为空值。 数据库原理与应用教程

52 在一个关系的各个元组之间或者若干关系之间常常存在各种联系或约束。常见的结构约束有: ①实体完整性约束。 ②参照完整性约束。
(2)结构约束 在一个关系的各个元组之间或者若干关系之间常常存在各种联系或约束。常见的结构约束有: ①实体完整性约束。 ②参照完整性约束。 ③用户自定义完整性约束。 ④函数依赖约束。大部分函数依赖约束都在关系模式中定义。 ⑤统计约束。即字段值与关系中多个元组的统计值之间的约束关系。 2.动态约束 动态约束是指数据库在关系变化前后状态上的限制条件，新、旧值之间所应满足的约束条件。 例如：工人工龄在更改时只能增长。 数据库原理与应用教程

53 8.4.2数据库完整性控制 为了实现完整性控制，数据库管理员应向DBMS提出一整套完整性规则，来检查数据库中的数据，看其是否满足完整性约束。
具体地说，完整性控制机制主要有以下3个功能： ⑴ 定义功能：提供定义完整性约束条件的机制。 ⑵ 检查功能：检查用户发出的操作请求是否违背了完整性约束条件。 ⑶ 保护功能：如果发现用户的操作请求使数据违背了完整性约束条件,则采取一定的动作来保证数据的完整性。 完整性控制机制根据检查用户操作请求，可以分为立即执行约束和延迟执行约束。 数据库原理与应用教程

54 立即执行约束（Immediate Constraints）是指在执行用户事务过程中，某一条语句执行完成后，系统立即对此数据进行完整性约束条件检查；延迟执行约束（Deferred Constraints）是指在整个事务执行结束后，再对约束条件进行完整性检查，结果正确才能提交。 例如，银行数据库中“借贷总金额应平衡”的约束条件就应该属于延迟执行约束，从账号Ａ转一笔钱到账号Ｂ为一个事务，从账号Ａ转出钱后，账就不平了，必须等转入账号Ｂ后，账才能重新平衡，这时才能进行完整性检查。 如果发现用户操作请求违背了完整性约束，系统可以拒绝该操作，以保护数据的完整性；但对于延迟执行的约束，系统将拒绝整个事务，把数据库恢复到该事务执行前的状态。 数据库原理与应用教程

55 一条完整性规则可以用一个五元组（D、O、A、C、P）来形式化地表示。 ①D(Date)：代表约束作用的数据对象；
②O(Operation)：代表触发完整性检查的数据库操作，即当用户发出什么操作请求时需要检查该完整性规则： ③A(Assertion)：代表数据对象必须满足的与语义约束，这是规则的主体； ④C(Condition)：代表选择A作用的数据对象值的谓值； ⑤P(Procedure)：代表违反完整性规则时触发执行的操作过程。 例如，对于“高级工程师工资不能低于800”的约束中 D代表约束作用的数据对象为工资属性； O代表当用户插入或修改技术人员元组时； A代表工人工资不能小于800； C职称=’高级工程师’ P代表拒绝执行用户请求。 数据库原理与应用教程

56 目前，许多关系数据库都提供了定义和检查实体完整性、参照完整性和用户自定义完整性功能，其中最重要的是实体完整性和参照完整性，其他完整性约束条件则可以归入用户定义的完整性。对于违反实体完整性和用户自定义完整性规则的操作一般都是采用拒绝执行的方式进行处理。而对于违反参照完整性的操作，并不都是简单地拒绝执行，一般在接受这个操作的同时，执行一些附加操作，以保证数据库的状态仍然是正确的。 数据库原理与应用教程

57 8.5 数据库的安全性 数据库的安全性是指保护数据库，以防止非法使用所造成数据的泄漏、更改或破坏。影响数据库安全性的因素很多，不仅有软硬件因素，还有环境和人的因素；不仅涉及技术问题，还涉及管理问题，政策法律问题等等。概括起来，计算机系统的安全性问题可分为三大类，即：技术安全类，管理安全类和政策法律类。 这里主要讨论的数据库本身的安全性问题，即主要考虑安全保护的策略，尤其是控制访问的策略。 数据库原理与应用教程

58 8.5.1数据库安全性控制方法用户 在一般计算机系统中，安全措施是一级一级层层设置的。其安全模型如图8.1所示。
在图8.1的安全模型中，用户要求进入计算机系统时，系统首先会根据输入的用户标识进行用户身份鉴定，只有合法的用户才能进入到计算机系统中。如果用户合法进入系统后，DBMS将进行存取控制，只允许用户执行合法的操作。操作系统应能保证数据库中的数据必须由DBMS访问，而不允许用户越过DBMS，直接通过操作系统或其他方式访问。数据最后还可以以密码形式存储到数据中。 这里只讨论和数据库有关的用户标识和鉴别、存取控制、视图机制、数据加密和审计等几类安全性技术。 数据库原理与应用教程

59 用户标识和鉴定的方法有多种，为了获得更强的安全性，往往是多种方法并举，常用的方法有以下几种：
1.用户标识和鉴别 用户标识和鉴定是系统提供的最外层的安全保护措施，其方法是由系统提供一定的方式让用户标识自己的名字或身份，系统内部记录着所有合法用户的标识，每次用户要求进入系统时，由系统进行核实，通过鉴定后才提供机器的使用权。 用户标识和鉴定的方法有多种，为了获得更强的安全性，往往是多种方法并举，常用的方法有以下几种： (1)用一个用户名或用户标识号来标明用户的身份，系统以此来鉴别用户的合法性。如果正确，则可进入下一步的核实，否则，不能使用系统。 (2)用户名是用户公开的标识，它不能成为鉴别用户身份的主要凭证。为了进一步核实用户身份，常采用用户名与口令（Password）相结合的方法，系统通过核对口令判别用户身份的真伪。 数据库原理与应用教程

60 (3)通过用户名和口令来鉴定用户的方法简单易行，但由于用户名和口令的产生和使用比较简单，容易被窃取，因此还可采用更复杂的方法。例如每个用户都可以事先预设好一个计算过程或一个函数，鉴别用户身份时，系统随机提供一个数字，用户根据自己设定好的计算过程或函数，系统根据用户提供的答案和事先预设的结果是不是一样，决定该用户是否是真实的用户。 2.用户存取权限控制 数据库安全性关心的主要是DBMS的存取控制机制。用户存取权限指的是不同的用户对于不同的数据对象允许执行的操作权限。在数据库系统中，每个用户只能访问他有权存取的数据并执行有权使用的操作。因此，必须预先定义用户的存取权限。对于合法的用户，系统根据其存取权限的定义对其各种操作请求进行控制，确保合法操作。 数据库原理与应用教程

61 存取控制机制主要包括两部分： (1)用户权限定义：用户权限是指不同的用户对于不同的数据对象允许执行的操作权限，系统必须提供适当的语言定义用户权限，这些定义经过编译后存放在数据字典中，被称作安全规则。 (2)合法权限检查：每当用户发出存取数据库的操作请求后，DBMS查找数据字典，根据安全规则进行合法权限检查，若用户的操作请求超出了定义的权限，系统将拒绝执行此操作。 数据库原理与应用教程

62 3.视图机制 通过视图机制我们可以为不同的用户定义不同的视图，可以限制每个用户的访问范围。通过视图用户只能查询和修改他们所能见到的数据。数据库中的其他数据则既看不见也取不到。数据库授权命令可以使每个用户对数据库的检索限制到特定的数据库对象上，但不能授权到数据库特定行和特定的列上。通过视图，用户可以被限制在数据的不同子集上。 4.审计 前面介绍的用户标识与鉴别、存取控制仅是安全性保障的一个重要措施，但实际上任何系统的安全性措施都不是绝对可靠的，窃密者总有办法打开这些控制。对于某些高度敏感的保密数据，必须以审计（audit）作为预防手段。审计功能是一种监视措施，跟踪记录有关数据的访问活动。 数据库原理与应用教程

63 审计追踪把用户对数据库的所有操作自动纪录下来，存放在一个特殊文件中，即审计日志（audit log）中。利用这些信息，可以重现导致数据库现有状况的已发生的一系列事件，以进一步找出非法存储数据的人、时间和内容等。 使用审计功能会大大增加系统的开销，所以DBMS往往将其作为可选特征，提供相应的操作语句可灵活的打开或关闭审计功能。审计功能一般用于安全性要求较高的部门。 5.数据加密 数据加密是防止数据库中的数据在存储或传输过程中被窃取的有效手段。例如，偷取数据的磁盘，或者在通信线路上窃取数据，为了防止这些窃密活动，比较好的办法是对数据加密（data encryption）。加密的基本思想是根据一定的算法将原始数据（术语为明文，plain text）加密成为不可直接识别的格式（术语为密文，cipher text），从而使窃取的人在没有密码的情况下无法读取数据。 数据库原理与应用教程

64 加密方法有两种：一种为替换方法，该方法使用密匙（encryption key）将明文中的每一个字符转换为密文中的一个字符；另一种是置换方法，该方法将明文中的字符按不同的顺序重新排列。如果单独使用，不够安全，但是将这两种方法结合起来用，就可以达到相当高的安全程度。例如，美国1977年制定的官方加密标准，数据加密（DES，Data Encryption Standard）就是使用这种方法的例子。 目前不少数据库产品提供了数据加密例行程序，可根据用户要求自动进行加密处理，还有一些未提供加密程序的产品也提供了相应的接口，允许用户用其他厂商的加密程序对数据加密。 用密码存储数据，在存储时需要加密与解密，加密与解密程序会占用比较多的系统资源，降低了数据库的性能。因此数据加密功能通常允许用户自行选择，只对那些保密级别高的数据，才进行数据加密。 数据库原理与应用教程

65 本章小结 数据库管理系统提供多用户共享数据，数据库管理系统要保证数据库及整个系统的正常运转，确保数据的安全性、完整性、并在多用户同时使用数据库时进行并发控制，以及当数据库受到破坏后能及时恢复正常，这就是数据库管理系统要履行的职责。 数据库的安全性是指保护数据库，以防止非法使用所造成数据的泄漏、更改或破坏。影响数据库安全性的因素很多，不仅有软硬件因素，还有环境和人的因素；不仅涉及技术问题，还涉及管理问题，政策法律问题等等。 数据库的完整性是指保护数据库中数据的正确性和相容性。数据库完整性由各种各样的完整性约束来保证，因此可以说数据库完整性设计就是数据库完整性约束的设计。数据库完整性约束可以通过DBMS或应用程序来实现。 数据库原理与应用教程

66 并发控制是为了防止多个用户同时存取同一数据，造成数据库的不致性。事务是数据库的逻辑工作单位，并发操作中只有保证系统中一切事务的原子性、一致性、隔离性和持久性，才能保证数据处于一致状态。并发操作导致的数据库不一致性主要有丢失修改、污读和不可重读3种。实现并发控制的方法主要是封锁技术，基本的封锁类型有排他锁和共享锁两种，3个级别的封锁协议可以有效解决并发操作的一致性问题。对数据对象施加封锁，会带来活锁和死锁问题，并发控制机制可以通过采取一次加锁法或顺序加锁法预防死锁的产生。 数据库的恢复是指系统发生故障后，把数据从错误状态中恢复到某一正确状态的功能。对于事务故障、系统故障和介质故障3种不同类型的故障，DBMS有不同的恢复方法。登记日志文件和数据转储是恢复中常用的技术，恢复的基本原理是利用存储在日志文件和数据库后备副本中的冗余数据来重建数据库。 数据库原理与应用教程