数据控制功能

4．2．3　数据控制功能

从数据模型角度看数据约束是RDBMS的基本内容之一，具体说来它包括数据约束条件的设置、检查及处理，它也称数据控制（data control）。

关系数据库管理系统的控制分静态控制与动态控制两种，其中静态控制是对数据模式的语义控制，包括安全控制与完整性控制；动态控制则是对数据操纵的控制，即是在多个进程（或线程）作并行数据操纵时所出现的控制，称并发控制。此外动态控制还包括在执行数据操纵时所出现的数据库故障的控制，它称为数据库的故障恢复。

在静态控制中首先要建立数据模式的语义关联，我们知道，任一个数据模式都是基于应用需求的，它们都含有丰富的语义关联，特别是数据间的语义约束关联。如模式中任一个基本数据项均有一定取值范围约束，如数据项间有一定函数依赖约束、有一定的因果约束等，这种约束叫完整性约束或叫完整性控制。而有一种与安全有关的特殊语义关联我们称为安全性约束或称安全性控制，这种约束是用户与数据体间的访问语义约束。如学生用户可以读他自己的成绩，但他不能修改自己的成绩等。

在动态控制中主要是并发控制与数据库故障恢复。为讨论这两种控制必须首先引出数据操纵中的基本动态操纵单位，它就是事务。因为动态控制均是以事务为单位进行控制的。

数据库管理系统的数据控制包括完整性控制、安全性控制、事务、故障恢复及并发控制等五个部分，同时RDBMS中也有相应的SQL语句以完成此部分的功能。

在本书中，我们介绍前面的四部分内容，而最后的一部分内容即并发控制内容大多由系统自动完成而并不与用户直接关联，因此就不作讨论了。

4．2．3．1　安全性控制

所谓数据库安全性控制（security control）即是保证对数据库的正确访问与防止对数据库的非法访问。数据库中的数据是共享资源，必须在数据库管理系统中建立一套完整的使用规则。使用者凡按照规则访问数据库必能获得访问权限并可访问数据库，而不按规则访问数据库者必无法获得访问权限，而最终无法访问数据库。

在安全性控制中其控制对象分为主体与客体两种，其中主体（subject）即是数据访问者，它包括一般的用户程序、进程及线程等，而客体（object）即数据体，它包括表、视图及存储过程等。而数据库的安全控制即是主体访问客体时所设置的控制。

目前常用的安全性控制有如下几种手段，它们是：

（1）身份标识与鉴别（identification and authentication）

在数据库安全中每个主体必须有一个标志自己身份的标识符，用以区别不同的主体，此称为身份标识。当主体访问客体时RDBMS中的安全控制部分鉴别其身份并阻止非法访问，此称为身份鉴别。

目前常用的标识与鉴别的方法有用户名、口令等，也可用计算过程与函数，最新的也可用密码学中的身份鉴别技术等手段。

身份标识与鉴别是主体访问客体的最简单也是最基本的安全控制方式。

（2）自主访问控制DAC（discretionary access control）

自主访问控制是主体访问客体的一种常用的安全控制方式，它是一种基于存取矩阵的模型，此模型由三种元素组成，它们是主体、客体与存／取操作，它们构成了一个矩阵，矩阵的列表示主体，矩阵的行则表示客体，而矩阵中的元素则是存／取操作（如读、写、删、改等），在这个模型中，指定主体（行）与客体（列）后可根据矩阵得到指定的操作，其示意图如图4．3所示。

图4．3　存／取矩阵模型示意图

在自主访问控制中主体按存取矩阵模型要求访问客体，凡不符合存取矩阵要求的访问均属非法访问。

在自主访问控制中存取矩阵的元素是可以经常改变的，主体可以通过授权的形式变更某些操作权限。

（3）审计（audit）

在数据库安全中除了采取有效手段对主体访问客体做检查外，还采用辅助的跟踪、审计手段，随时记录主体对客体访问的轨迹，并做出分析供参考。同时在一旦发生非法访问后能即时提供初始记录供进一步处理，这就是数据库安全中的审计。

审计的主要功能是对主体访问客体做即时的记录，记录内容包括：访问时间、访问类型、访问客体名、是否成功等。为提高审计效能，还可设置审计事件发生积累机制，当超过一定阈值时能发出报警，以提示采取措施。

目前一般关系数据库管理系统中均有身份标识及鉴别功能以及自主访问控制功能，而部分系统中还具有审计功能。而在SQL中也有相应语句以实现这些功能。

4．2．3．2　完整性控制

完整性控制（intigrity control）指的是数据库中数据正确性的维护，任何数据库都会由于某些自然或人为因素而受到局部或全局的破坏。因此如何及时发现并采取措施防止错误扩散并及时恢复，这是完整性控制的主要目的。

1）关系数据库完整性控制的功能

在关系数据库中为实现完整性控制须有三个基本功能，它们是：

（1）设置功能：需设置完整性约束条件（又称完整性规则），这是一种语义约束条件，它由系统或用户设置，它给出了系统及用户对数据库完整性的基本要求。

（2）检查功能：关系数据库完整性控制必须有能力检查数据库中数据是否有违反约束条件的现象出现。

（3）处理功能：在出现有违反约束条件的现象时须有即时处理的能力。

2）完整性规则的三个内容

关系数据库完整性规则由如下三部分内容组成。

（1）实体完整性规则（entity integrity rule）

这条规则要求基表上的主键中属性值不能为空值，这是数据库完整性的最基本要求，因为主键是惟一决定元组的，如为空值则其惟一性就成为不可能的了。

（2）参照完整性规则（reference integrity rule）

这条规则也是完整性中的基本规则，它不允许引用不存在的元组。亦即是说在基表中的外键要么为空值，要么其关联表中必存在相应的元组。如在基表S（sno，sn，sd，sa）与SC （sno，cno，g）中，SC的主键为（sno，cno），S的主键为sno，而SC的外键为sno，SC与S通过sno相关联，而参照完整性规则要求SC中的sno的值必在S中有相应元组值，如有SC（S₁₃，C₈，70）则必在S中存在S（S₁₃，…，…，…）。

这条规则给出了表之间相关联的基本要求。

上述两种规则是关系数据库所必需遵守的规则，因此任何一个DBMS必须支持。

（3）用户定义的完整性规则（userdefined integrity rule）

这是针对具体数据环境与应用环境由用户具体设置的规则，它反映了具体应用中数据的语义要求。

在RDBMS中一般都提供数据库完整性控制上述三个内容的功能，其中前两个内容由系统自动给出，而用户定义的完整性规则则由用户通过SQL语句定义并由系统完成。

3）用户定义的完整性约束的设置、检查与处理

由于用户定义的完整性规则由用户给出，因此本节就介绍用户定义的有关情况以及系统处理情况。

（1）可对用户定义的完整性规则作约束条件设置，它包括域约束，表约束及断言。其中域约束即可约束数据库中数据域的范围与条件，表约束可以约束与定义表中的主键、候选键及外键，同时还可以对表内属性间建立约束，最后断言即是建立表间属性的约束。

（2）在完整性条件设置后在DBMS中有专门软件对其做检查以保证所设置条件能得以监督与实施，这即为完整性约束条件的检查。

（3）在RDBMS中同样有专门的软件对完整性约束条件的检查结果作处理，特别是一旦出现违反完整性约束条件的现象作出响应、报警或报错，在复杂情况下可调用相应的处理过程。

4．2．3．3　事务处理

事务处理是数据库动态控制中的一个基本单位。数据库是一个共享的数据实体，多个用户可以在其中做多种操作（包括读操作与写操作），为了保持数据库中数据的一致性，每个用户对数据库的操作必须具有一定操作连贯性。为说明此问题我们从一例说起，设某银行有A，B两个账户，它们分别存有20000元与10000元人民币，现有一笔转账业务须从A将5000元钱转至B，此应用的操作可描述如下：

应用T1：

Read（A）

A：＝A－5000

Write（A）

Read（B）

B：＝B＋5000

Write（B）

在执行T1前A＝20000，B＝10000，其银行总存款为A＋B＝20000＋10000＝30000元，在此六个步骤完成后，A与B分别为：A＝15000，B＝15000，其银行的总存款数为A＋B＝15000＋15000＝30000，此时仍保持其总款数不变，亦即是说，在数据库中从原有的一致性在经过操作T1后保持了新的一致性。但是在此六个步骤操作必须作为整体一次完成，其中间是不应允许被其他应用所打断的，否则其一致性就受到破坏。如在第三步结束后中间被另一个应用T2打断，此时T2所面对的数据库是一个不一致的数据库，即原有银行总存款数为A＋B＝30000，但是在此时T1执行并没有完成，呈现在T2面前的总存款数为A＋B＝15000＋10000＝25000，此时出现了不一致性，而T2在此不一致性的数据库面前是无法正确执行操作的。为解决此问题，必须保证T1执行操作的连贯性，即T1整个六步操作必须连贯完成，其中间不允许被其他应用所打断，这就引出了事务的概念。

事务（transaction）是数据库应用程序的基本逻辑工作单位，在事务中集中了若干个数据库操作，它们构成了一个操作序列，它们要么全做，要么全不做，是一个不可分割的基本工作单位。

一般而言，一个数据库应用程序是由若干个事务组成，每个事务构成数据库的一个状态，它形成了某种一致性，而整个应用程序的操作过程则是通过不同事务使数据库由某种一致性不断转换到新的一致性的过程。

1）事务的性质

事务具有四个特性，它们是事务的原子性（atomicity）、一致性（consistency）、隔离性（iso－lation）以及持久性（durability），简称为事务的ACID性质。

（1）原子性

事务中所有的数据库操作是一个不可分割的操作序列，这些操作要么全执行，要么全不执行。

（2）一致性

事务执行的结果将使数据库由一种一致性到达了另一种新的一致性。

（3）隔离性

在多个事务并发执行时事务不必关心其他事务的执行，如同在单用户环境下执行一样。

（4）持久性

一个事务一旦完成其全部操作后，它对数据库的所有更新永久地反映在数据库中，即使以后发生故障也应保留这个事务执行的结果。

事务及其ACID性质保证了并发控制与故障恢复的顺利执行，因此在下面的讨论中均以事务为基本执行单位。

2）事务活动

事务活动一般由三个事务语句控制，它们是置事务语句（SET TRANSACTION），提交语句（COMMIT）及回滚语句（ROLLBACK）。

一个事务一般由SET TRANSACTION开始至COMMIT或ROLLBACK结束。在事务开始执行后，它不断做Read或Write操作，但是，此时所做的Write操作，仅将数据写入磁盘缓冲区，而并非真正写入磁盘内。在事务执行过程中可能会产生两种状况：其一是顺利执行———此时事务继续正常执行；其二是产生故障等原因而中止执行，对此种情况称事务夭折（abort），此时根据原子性性质，事务需返回开始处重新执行，此时称事务回滚（rollback）。在一般情况下，事务正常执行直至全部操作执行完成，以后再执行事务提交（commit）后整个事务结束，所谓提交即是将所有在事务执行过程中写在磁盘缓冲区的数据，真正、物理地写入磁盘内，从而完成整个事务。因此，事务的整个活动过程可以用图4．4表示。

图4．4　事务活动过程图

在RDBMS的SQL中一般都提供有关事务活动语句。

4．2．3．4　故障恢复

1）概述

尽管对数据库采取多种严格的防护措施，但是数据库遭受破坏仍是不可避免的，因此，一个关系数据库管理系统除了要有较好的完整性、安全性保护措施以及并发控制能力外，还需要有数据库故障恢复的能力。数据库故障恢复技术是一种被动的方法，而数据库完整性、安全性保护及并发控制技术则是主动的保护方法，这两种方法的有机结合可以使数据库得到有效的保护。

数据库故障恢复技术所采用的主要手段是冗余与事务。所谓数据冗余即是采取数据备用复本和日志，所谓事务即是利用事务作为操作单位进行恢复。

2）数据库故障分类

为讨论数据库恢复，我们首先须对数据库故障作分类，数据库故障大致可以分为小型故障、中型故障与大型故障等三种类型，并可细分为共六个部分。

（1）小型故障

●事务内部故障：此类故障是事务内部执行时所产生的逻辑错误与系统错误，如数据输入错误、数据溢出、资源不足（以上属逻辑错误）以及死锁、事务执行失败（以上属系统错误）等，此类故障属小型故障。

所谓小型故障即是其故障影响范围在一个事务之内。

（2）中型故障

●系统故障：此类故障是由于系统硬件（如CPU）故障、操作系统、DBMS以及应用程序代码错误所造成的故障，此类故障可以造成整个系统停止工作，内存破坏，正在工作的事务全部非正常中止，但是磁盘数据不受影响，数据库不遭破坏，此类故障属中型故障。

●外部影响：此类故障主要是由于外部原因（如停电等）所引起的，它也造成系统停止工作，内存破坏，正在工作的事务全部非正常中止，但数据库不受破坏，此类故障属中型故障。

中型故障的影响范围是事务级的，即某些事务要重做，某些事务要撤销，但是它不需要对整个数据库做全面修复。

（3）大型故障

●磁盘故障：此类故障包括磁盘表面受损，磁头损坏等，此时整个磁盘受到破坏，数据库严重受影响。

●计算机病毒：计算机病毒是目前破坏数据库系统的主要根源之一，它不但对计算机主机产生破坏（包括内存）也对磁盘文件产生破坏。

●黑客入侵：黑客入侵可以造成主机、内存及磁盘数据的严重破坏。

以上三种故障造成内存、磁盘及主机严重破坏，同时也使整个数据库受到破坏，因此此类故障属系统级故障。

3）数据库故障恢复三大技术

为恢复数据库中的数据一般采用下面三大技术。

（1）数据转储

所谓数据转储即是定期将数据库中的内容复制到另一个存储设备中去，这些存储的拷贝称为后援复本或备份。

转储可分为静态转储与动态转储。静态转储指的是转储过程中不允许对数据库有任何操作（包括存取与修改操作），即转储事务与应用事务不可并发执行。动态转储指的是转储过程中允许对数据库作操作，即转储事务与应用事务可并发执行。

静态转储执行比较简单，但转储事务必须等到应用事务全部结束后才能进行，因此带来一些麻烦。动态转储可随时进行，但是转储事务与应用事务并发执行，容易带来动态过程中的数据不一致性，因此技术上要求较高。

数据转储还可以分为海量转储与增量转储，海量转储指的是每次转储数据库的全部数据，而增量转储则是每次只转储数据库中自上次转储以来所产生变化的那些数据。由于海量转储数据量大，不易进行，因此增量转储往往是一种有效的办法。

（2）日志（logging）

所谓日志即是系统建立的一个文件，该文件用于系统记录数据库中更改型操作的数据更改情况，其内容有：

●事务开始标记；

●事务结束标记；

●事务的所有更新操作。

具体的内容有：事务标志、操作时间、操作类型（增、删、或改操作）、操作目标数据、更改前数据旧值、更改后数据新值。

日志以事务为单位按执行的时间次序，且遵循先写日志后修改数据库的原则进行。

（3）事务撤销与重做

数据库故障恢复的基本单位是事务，因此在数据恢复时主要使用事务撤销与事务重做两种操作。

①事务撤销操作

在一事务执行中产生故障，为进行恢复，首先必须撤销该事务，使事务恢复到开始处，其具体过程如下：

●反向扫描日志文件，查找应该撤销的事务。

●找到该事务更新的操作。

●对更新操作做逆操作，即如是插入操作则做删除操作，如是删除操作则用更改前数据旧值作插入，如是修改操作则用修改前值替代修改后值。

●如此反向扫描一直反复做更新操作的逆操作，直到事务开始标志出现为止，此时事务撤销结束。

②事务重做操作

当一事务已执行完成，它的更改数据也已写入数据库，但是由于数据库遭受破坏，为恢复数据需要重做，所谓事务重做实际上是仅对其更改操作重做，重做的过程如下。

●正向扫描日志文件，查找重做事务。

●找到该查找事务的更新操作。

●对更新操作重做，如是插入操作则将更改后新值插入至数据库，如是删除操作，则将更改前旧值删除，如是修改操作则将更改前旧值修改成更新后新值。

●如此正向扫描反复做更新操作，直到事务结束标志出现为止，此时事务重做操作结束。

4）恢复策略

利用后备副本（或称复本）、日志以及事务的撤销与重做可以对不同的数据库进行恢复，其具体恢复策略如下。

（1）小型故障的恢复

小型故障属事务内部故障，其恢复方法是利用事务的撤销操作，将事务在非正常中止时利用撤销恢复到事务起点。

（2）中型故障的恢复

中型故障所需要恢复的事务有两种：

●事务非正常中止。

●已完成提交的事务，但其更新操作还留在内存缓冲区尚未来得及写入，由于故障使内存缓冲区数据丢失。

对第一种事务采用撤销操作，使其恢复至事务起点，对第二种事务用重做操作进行重做。

（3）大型故障的恢复

大型故障是那些整个磁盘、内存及系统都遭受破坏的故障，因此对它的恢复就较为复杂，它大致分为下列步骤：

●将后备复本拷贝至磁盘。

●做事务恢复第一步———检查日志文件，将拷贝后所有执行完成的事务做重做。

●做事务恢复第二步———检查日志文件，将未执行完成（即事务非正常中止）的事务做撤销。

经过这三步处理后可以较好完成数据库中数据的恢复。数据库中恢复一般由DBA执行。数据库恢复功能是数据库的重要功能，每个数据库管理系统都有此种功能。

在SQL中一般均向用户提供多种有关故障恢复的语句与操作。