第7章 主动数据库技术.docx
《第7章 主动数据库技术.docx》由会员分享，可在线阅读，更多相关《第7章 主动数据库技术.docx（39页珍藏版）》请在冰点文库上搜索。
第7章主动数据库技术
第6章主动数据库技术
传统的数据库管理系统只能根据用户的命令被动地完成相应的动作，被动地为用户服务，称得上主动完成的一类工作是对各种约束条件的检查，例如，数据完整性，一致性，安全性等。
主动数据库的一个突出的思想是让数据库系统具有各种主动进行服务的功能，并以—种统一而方便的机制来实现各种主动性需求。
实现主动数据库系统有许多需要解决关键的问题，这些问题包括实现有效的事件监视器，有效的规则表示和执行机制，数据库中的事件描述、运算和复合，以及在主动数据库中的有效事务处理机制等。
本章将介绍主动数据库基本概念、数据库模型、体系结构以及面向主动对象的数据库，主要讨论了主动数据库的规则和事件机制，并就当前商业DBMS广泛支持的触发器技术进行了讨论，最后给出一个应用实例。
6.1主动数据库的产生
6.1.1数据库的被动服务与主动服务
数据库理论和实践历经30余年的研究发展，从文件系统、层次型数据库系统、网状型数据库系统、关系型数据库系统、面向对象型数据库系统到对象—关系型数据库系统，这些技术已发展得相当成熟。
由于DBMS（数据库管理系统）提供了统一的管理数据库的功能及友善的数据管理界面，当用户需要查询、更新数据中的某些满足一定条件的数据时，用户只需要通过相关的命令或操作就可以实现。
但是，这些传统数据库管理系统本身都是被动的，即它只能响应和重做用户要求它们做的事情，而不会灵活地根据数据库的外部环境或内部状态等情况主动做些什么，数据库仅作为一种被动的数据存储仓库而存在。
如果用户的应用需要实现某些主动性的功能，就必须手动编写逻辑控制代码，并通过其它的程序设计语言与数据库进行连接而实现。
然而，对于同一个目的，不同的用户编写的代码不尽相同，甚至差别很大，这就造成了一些问题：
一方面，编写不同的代码不利于维护和交流；另一方面，用户编写的代码健壮性难以得到保证，甚至可能会危及到数据库数据的完整性。
在各种应用当中，主动性的需要有时显得很重要。
一个例子就是在电费管理系统中，除了具有基本的用户余额管理和用户使用电度数管理之外，往往还要求具有对用户余额的监控功能，当用户的余额低于一定的数额或已低于当前使用额的时候，自动打印出余额不足账单，工作人员可以在一定的间隔时间内检查账单并寄给用户。
传统的数据库只能提供“被动服务”，因此，利用“被动服务”的数据库不能很好地完成带有主动性需求的任务。
而在实际应用中，主动性需求是大量存在的，这就呼唤着解决该问题的方案。
下面我们论述在实际应用中的主动性需求。
6.1.2实际应用的主动性需求
许多实际应用中都有对数据库的主动性功能的要求，以往对这些主动性的实现是由开发人员编写程序，将规则，规则的匹配，规则的执行等功能都编写在程序代码当中，这样做可以从一定程度上解决当前应用的要求，但是这种方法存在不灵活，修改不方便，结构不清晰等等这些缺点。
因此实际应用呼唤着数据库的“主动服务”，因为如果由数据库提供主动服务，就不需要进行复杂的编码，我们所要做的事件只是设置规则、说明处理要求而已，其他的工作由数据库帮助我们实现。
下面是实际应用中一些最经常遇到的主动性需求：
●MIS中的预警功能
●系统的实时监控功能
●例外或错误情况的主动处理和自动恢复功能
●系统瞬时状态的输出或关键点状态的输出
●协同工作或协同解决问题
●方便灵活的实时处理能力
●方便灵活的人机交互接口
●自适应和学习功能
●演绎推理功能
●更强的系统交互性
●原有数据库功能的加强和集成也需要主动性的帮助
上述的主动性需求虽然其表现形式不尽相同，但都可以通过设计一种统一的处理机制来实现。
主动数据库就是设计这样一种通用的、统一的机制来设计，主动数据库强调的是一种“统一的机制”来实现，这样用户就不必自己编写复杂的程序来实现主动性需求，并且这种实现方法是统一的、安全的。
6.1.3什么是主动数据库
早期的数据库管理系统中，除了能主动地做—些数据一致性和完整性检查之外，不再有其他的主动性设施。
近年来，一些商品化的数据库管理系统，例如Ingres、Oracle和Sybase等数据库系统，纷纷引进了所谓的“触发器（Trigger）”和“规则（Rule）”概念。
在某种意义上引入了主动处理的功能。
随着这些商品化系统的广泛应用，数据库的主动性功能正在各种应用中发挥越来越大的作用。
ISO的SQL3标准也支持通用的主动规则机制。
他们支持的语义有：
基本事件和简单事件的复合；事件－条件（Event-Condition,EC）和条件－动作（Condition-Action,CA）耦合；多种规则粒度；串行的规则选择和可中断的规则执行方式等。
主动数据库是相对于传统数据库的被动性而言的。
在各种管理信息系统（MIS）或决策支持系统（DSS）中，传统数据库在数据的存储与检索等方面已为各种用户提供了良好的服务。
当人们需要获得、改变、加入或删除数据库中某些满足一定条件的数据时，用户可以通过相应的命令或操作来实现其目的。
但各种传统数据库的所有这些功能都有一个共同的特性，就是数据库本身是被动的，用户给什么命令，系统就做什么动作，它丝毫不会根据数据库的内部状态等情况主动做些什么，而许多实际的应用领域．如管理信息系统（MIS）、计算机集成制造系统（CIM）、计算机辅助设计和制造系统（CAD/CAM）、办公自动化系统（OA）常常希望数据库系统在紧急情况下能根据数据库的当前状态，主动的进行相应的处理，不需要用户的干预，快速有效地解决实际环境中遇到的问题。
为了达到这样的目的，对传统的数据库系统就提出了对事件做出主动响应的要求，这就推动了主动数据库技术的产生。
目前，主动数据库及其管理系统一方面已在各种应用中起着越来越重要的作用。
主动数据库提供给用户一个统一定义主动功能的平台，方便使用和修改，同时提高了系统的可靠性和性能。
主动数据库的一个突出的思想是让数据库系统具有各种主动进行服务的功能，并以—种统一而方便的机制来实现各种主动性需求。
6.2触发器技术
6.2.1标准SQL中的主动数据库功能
目前，一些主流的RDBMS产品都有部分主动数据库的功能。
但是由于缺乏这方面的标准，各种产品在主动数据库的功能和规则的表示形式上是有差异的。
在SQL92及以前的标准版本中，不包含真正的主动数据库功能，只是包含表的约束、引用完整性约束和断言等。
而SQL3引入了触发器的功能，从而在公共的标准上实现了对主动数据的支持。
SQL3触发器的语法如下：
:
:
=CREATETRIGGER
{BEFORE|AFTER|INSTEADOF}
ON
[ORDER]
[REFERENCING]
WHEN（）
[FOREACH{ROW|STATEMENT}]
其中：
:
:
=INSERT|DELTE|UPDATE[OF]
:
:
=OLDAS|
NEWAS|
OLD_TABLEAS|
NEW_TABLEAS
由上面的语法可知，触发器是按照事件（Event）-条件（Condition）-动作（Action）的规则定义的。
在SQL3触发器中，触发的事件仅限于数据更新操作，不支持数据查询操作。
每一种触发器操作有3种可能的触发时间，他们是BEFORE、AFTER和INSTEADOF，BEFORE为事件前触发，AFTER为事件后触发，INSTEADOF表示触发器执行某项操作，而不是触发这个触发器的操作。
SQL更新操作的对象一般来说是元组集，这样就存在一个操作粒度问题。
一个SQL3触发器的操作粒度分为逐行（ROW）或以语句（STATEMENT）为单位。
例如在电费管理系统中，如果要监控某用户的余额是否低于一定数额，就必须使用逐行监控。
如果要监控每一个删除操作，就必须通过语句为单位的监控。
由于触发器的事件只能是数据更新操作，这些操作的执行会引起数据库中的数据变动，因此提出了旧值（oldvalue）和新值（newvalue）的概念，其目的是为了在触发器语句的条件和动作部分可以用到而定义一个引用名。
这些新旧值作为一种过渡值，要么是单个元组，要么是一个结果元组集，一般占据的空间不大，因而一般是暂存在内存中，并随着触发器的执行完毕而释放所占用的内存空间。
SQL3的触发器语法中的REFERENCING子句就是实现上述的过渡值引用问题而设置的。
在的定义中，OLDAS和NEWAS分别定义元组的旧值和新值的引用名，用于逐行监控；而OLD_TABLEAS和NEW_TABLEAS分别定义元组集的旧值和新值的引用名，用于按语句监控。
6.2.2在商业DBMS中的触发器
在主流关系数据库管理系统（RDBMS）中，一般都支持触发器功能，下面就DB2和Oracle为例说明商业DBMS的触发器。
1.IBMDB2
IBMDB2的触发器语法定义如下：
:
:
=CREATETRIGGER
{NOCASCADEBEFORE|AFTER}
ON
[REFERENCING]
FOREACH{ROW|STATEMENT}MODEDB2SQL
[WHEN（）]
{SQLSTATEMENTS|BEGINATOMICSQLSTATEMENTSEND}
其中：
:
:
=INSERT|DELETE|UPDATE[OF]
:
:
=OLDAS|
NEWAS|
OLD_TABLEAS|
NEW_TABLEAS
在DB2的触发器中，被触发的SQL语句可以包含DB2函数和用户自定义函数。
用户自定义函数使用C/C++语言编写的，除用于一般的SQL数据控制操作，还可以允许触发器执行非SQL操作类型。
例如：
在注册用户管理系统中，当用户注册时系统会自动发送一封欢迎信，就可以通过用户自定义函数来实现：
在触发器的动作部分包含该函数，当事件触发并符合条件时，就发送电子邮件给该用户。
2.Oracle
Oracle的触发器语法定义如下：
:
:
={CREATE|REPLACE}TRIGGER
{BEFORE|AFTER}
ON
[[REFERENCING]
FOREACHROW[WHEN（condition>）]]
其中，
:
:
=INSERT|DELETE|UPDATE[OF]
:
:
=OLDAS|
NEWAS
由其语法可知触发的动作部分在PL/SQL语句块中，可以包含各种声明和调用外部过程，但不包含数据定义语句或事务控制语句。
6.2.3触发器的使用
触发器技术在现时的商业RDBMS中有着广泛的应用，虽然各个RDBMS的触发器语法都有些差异，但总体结构都是依照ECA规则定义的。
下面我们按照标准的SQL3语法来举几个例子说明触发器的使用。
在学生课程管理数据库中，有如下三个表
●学生表：
Student（Sno,Sname,Ssex,Sdept,Sage）
●课程表：
Course（Cno,Cname,Ccredit）
●选修表：
SC（Sno,Cno,Grade）
1.引用完整性约束的实现
通过分析，不难得出共有如下六种操作会影响到引用的完整性：
●SC表的INSERT操作
●Student表的DELETE操作
●Course表的DELETE操作
●SC表UPDATE（Sno,Cno）操作
●Course表UPDATE（Cno）操作
●Student表UPDATE（Sno）操作
以Student的DELETE操作为例说明触发器的使用：
因为在SC表中，外键Sno的定义为CASCADE，所以当在Student表中删除一个元组时，要级联删除SC表中引用该元组的主键作为外键的所有元组。
触发器语句如下：
CREATETRIGGERstudent_delete_trigger
AFTERDELETEONStudent
REFERENCINGOLDASOldRow
FOREACHROW
WHEN（EXISTS（
SELECT*FROMSC
WHERESno=OldRow.Sno））
DELETEFROMSC
WHERESno=OldRow.Sno;
2.导出数据的及时更新
一个典型的例子就是实视图的更新，实视图是由基表导出的表，作为一个实在的表存储在数据库中。
恰当使用实视图可以提高查询速度，但在基表更新时，要保证实视图要及时刷新。
假设我们要对“计算机”系的学生成绩表CSCourse创建一个实视图，则可以由下面的语句创建：
SELECTSname,Cno,Grade
FROMStudent,SC
WHEREStudent.Sno=SC.SnoANDSdept=’计算机’；
通过分析，可以得出下列的操作影响CSCourse的值：
●Student表DELETE操作，且删除元组中有院系为计算机系的元组
●Student表INSERT操作，且删除元组中有院系为计算机系的元组
●Student表UPDATE（SName,Sno,Sdept）操作
●SC表DELETE操作
●SC表INSERT操作
●SC表UPDATE操作
下面以Student表的DELETE操作为例，说明实视图的更新：
如果Student删除的元组中有“计算机”系的元组，则要更新CSCourse表。
一个简单的办法就是删除整个CSCourse表的全部内容，然后再生成新的CSCourse表。
触发器语句如下：
CREATETRIGGERcscourse_delete_trigger
AFTERDELETEONSTUDENT
REFERENCINGOLD_TABLEASOT
FOREACHSTATEMENT
WHEN（EXISTS（
SELECT*FROMOT
WHERESdept=‘计算机’））
DELETEFROMCSCourse;
INSERTINTOCSCourse
SELECTSname,Cno,Grade
FROMStudent,SC
WHEREStudent.Sno=SC.SnoANDSdept=’计算机’;
其中，OT是表的变量名作为对旧表的引用。
在这个例子中，如果数据库操作影响到CSCourse表，则首先删除整个表，然后再重新生成CSCourse表。
实际上，在CSCourse表中受影响的元组往往比较少，如果CSCourse表很大，这样将会造成严重的效率问题。
在实视图的更新算法中，有一种“增量式”算法，它能计算出实视图的变化，这样就可以只更新修改了的部分，从而大大地提高了更新效率。
6.2.3触发器的优缺点
1.触发器的优点
主流的商业RDBMS提供了对触发器的支持，实现了部分的主动数据库功能，在一定程度上缓解了用户对数据库“主动服务”的迫切需求。
触发器具有如下的优点：
1）安全性
基于数据库的值使用户具有操作数据库的某种权利。
具体表现在：
a）可以基于时间限制用户的操作，例如不允许下班后和节假日修改数据库数据。
b）可以基于数据库中的数据限制用户的操作，例如不允许股票的价格的升幅一次超过10%。
2）审计
a）可以跟踪用户对数据库的操作。
表现在：
b）审计用户操作数据库的语句。
c）把用户对数据库的更新写入审计表。
3）实现复杂的非标准的数据库相关完整性规则
触发器可以对数据库中相关的表进行级联更新，以达到数据表的参照完整性和一致性。
其表现在：
a）在修改或删除时级联修改或删除其它表中与之匹配的行。
b）在修改或删除时把其它表中与之匹配的行设成NULL值。
c）在修改或删除时把其它表中与之匹配的行级联设成缺省值。
d）触发器能够拒绝或回滚那些破坏相关完整性的变化，取消试图进行数据更新的事务。
2.触发器的缺点
虽然主流的商业RDBMS提供了触发器实现了一些简单的“主动性”功能，但它有下面两方面的缺点：
1）触发事件是简单事件
不能从简单的事件构造复杂事件的能力，也不能由用户定义其所需的事件的能力。
2）现时的触发器技术缺乏一个统一的标准
由于各个RDBMS厂商实现触发器的途径不一样，甚至它们定义同一个触发器的语法也不一样。
这些造成了它们必依附在特定系统上，对软件环境的具体实现依赖性很大，不利于数据库的移植和代码一致性。
3）规则的执行方式不完备
当事件发生前或发生后，如果满足条件，则规则处于触发状态，动作将被执行。
就动作触发的时间而言，可分为三类：
立即式、延迟式、并发式。
现时支持触发器的RDBMS一般都只支持立即执行方式，对于推迟到事务的末尾执行的延迟式以及具有并发/并行的并发式，由于其实现机制的复杂性，目前几乎还没有一个DBMS产品支持这两种执行方式。
这些数据库系统虽然已经具备一定的主动性功能，但还不是一个完全的主动数据系统。
因为采用这种简单的机制并不能建立起具有完善主动功能的系统，所以提出一种具有完善的主动功能的DBMS概念是完全有必要的。
下面我们讨论一个具有较完善主动动能的主动数据库的体系结构。
6.3主动数据库体系结构
在功能上，一个主动数据库系统（ADBS）由一个传统数据库系统（DBS）和一个事件驱动的知识库（简称事件库EB）及其相应的事件监视器（EM）组成，用公式表示为：
ADBS＝DBS+EB+EM
各部分说明如下：
●DBS（DatabaseSystem）这个部分等同于一般的传统数据库系统，主要用来存储数据和对数据进行维护、管理与运用；
●EB（EventBase）这也是一个数据库，这个数据库用来存储规则和对规则进行维护、管理与应用，是由事件驱动的一组知识组成的集合（规则集合），称为“事件库/规则库”，其中每一项知识表示在相应的事件发生时，如何来主动地执行其中包含的由用户预先设定的动作；
●EM是一个随时监视EB中的事件是否已经发生的监视模块，一旦监视到某事件已经发生时就主动地触发系统，按照EB中指明的相应知识执行其中预先设定的动作。
从上面的主动数据库模型可以看出主动数据库管理系统与一般数据库管理系统在结构上的区别主要在于它除了有一个传统的关系型被动的数据库外，还添加了一个事件驱动的事件库和一个和多个事件监视器，监视器处于运行系统当中，主动并实时检测各种事件的发生，然后自动地根据发生的事件和条件按照一定的规则触发并执行所需动作。
主动数据库管理系统的体系结构可用图6.1表示。
图中实线表示控制连接，虚线表示数据连接。
实际系统中的用户接口、DDL处理模块、DMI。
处理模块、日志和恢复模块、求助与解释模块、内存表格和缓冲区、数据库和数据字典的组织和处理等与一般数据库管理系统的处理方法没有原则的区别，主要的区别是新增加事件监视和执行模块，它与规则库、数据库、数据字典乃至总控模块都有数据交换关系。
图6-1主动数据库管理系统的体系结构
在某种意义上，传统数据库系统中的完整性和一致性等约束性检查也可以认为是主动进行的，只不过它的主动功能不够完善，事件的种类在实现时就已经固定，不允许用户根据需要自己来设置各种特定事件。
而一个功能完善的主动数据库系统必须具有各种主动进行服务的功能，并以一种统一而方便的机制来实现这些功能。
这样就要求把所有主性功能用一种统一的方法与原有的数据库功能集成在一个数据库系统中，这种机制可以通过事件库来实现。
我们可以将系统所定义和用户所定义的所有事件集中在一个事件库中，同时再提供一个自动“监视”模块，它主动时不时检查这个事件库所包含的事件是否已经发生，一旦发现某事件发生时，就主动执行某个命令序列。
由于事件库可以由用户自己定义，这样通过它就可以提供用户一种自己设置和构造其所需事件的能力，而且事件库具有一般性和统一性，它不依赖于某特定系统中的特定设施，对软件系统的具体实现依赖性很小。
所以，可以说拥有事件库的数据库系统具有较完善主动功能。
6.4主动（ECA）规则
主动数据库系统对DBMS的基本要求是能处理下列的规则：
WHENEVER<事件>
IF<条件>
THEN<动作>
即当发生某一事件（Event）时，如果满足给定条件（Condition），则执行相应的动作（Action），这种规则称为ECA规则（Event-Condition–Action的缩写）。
主动数据库通过这样一种事件驱动的“事件－条件－动作”规则来表示数据库中的主动知识。
下面简要介绍ECA规则的构成、描述和基本要素：
事件、条件、动作。
6.4.1ECA规则的构成
事件驱动的“事件—条件—动作”规则的语义是：
“一旦指定的事件发生，计算机就主动触发执行其后的条件判断规则。
即如果条件为真，则执行其后的动作。
规则的组成的三要素的：
事件、条件、动作。
1）事件是在数据库系统在运行过程当中某特定时刻发生的，对系统有特定意义的事情，包括基本事件和复合事件，复合事件事是由基本事件经过各种事件运算构成的，复合事件是一种表达复杂事件的手段，使用户可以根据实际需要定义复杂事件，便于规则的设计、维护与传送。
2）条件是关于当前或某个特定事件的数据库状态的一种假定，用某种逻辑（例如模糊逻辑）中的任意的一个合法的逻辑公式来表示一个条件，对于条件，可以依据逻辑运算将条件定义成简单的条件，也可以构造出很复杂的条件。
3）动作是数据库可以执行的一组操作序列，这些序列中可以有系统预先定义的一些标准动作，也可以由用户定义复杂的动作，或是用某种程序设计语言表现的一个过程，而这些单个动作可以组合成动作序列，共同完成更加复杂的操作。
6.4.2ECA规则描述
主动数据库（ADBS=DBS+EB+EM）是在数据库的基础上增加了事件库、事件监视器。
在主动数据库的运行中，事件监视器根据事件库对数据库进行监控，根据监测到的信息触发数据库系统的主动服务。
数据库的主动功能主要是通过在主动数据库中预先设置一些处理规则来实现的。
这些规则规定了事件发生的条
升级会员 