第 5 章 主动数据库技术

1. 第5章 主动数据库技术 • 主动数据库的一个突出的思想是让数据库系统具有各种主动进行服务的功能，并以—种统一而方便的机制来实现各种主动性需求。实现主动数据库系统有许多需要解决关键的问题，这些问题包括实现有效的事件监视器，有效的规则表示和执行机制，数据库中的事件描述、运算和复合，以及在主动数据库中的有效事务处理机制等。

2. 5.1主动数据库的产生5.1.1 数据库的被动服务与主动服务

3. 传统数据库管理系统本身都是被动的，即它只能响应和重做用户要求它们做的事情，而不会灵活地根据数据库的外部环境或内部状态等情况主动做些什么，数据库仅作为一种被动的数据存储仓库而存在。利用“被动服务”的数据库不能很好地完成带有主动性需求的任务。而在实际应用中，主动性需求是大量存在的，这就呼唤着解决该问题的方案。

4. 5.1.2实际应用的主动性需求 • 实际应用中一些最经常遇到的主动性需求： • MIS中的预警功能 • 系统的实时监控功能 • 例外或错误情况的主动处理和自动恢复功能 • 系统瞬时状态的输出或关键点状态的输出 • 协同工作或协同解决问题 • 方便灵活的实时处理能力 • 方便灵活的人机交互接口 • 自适应和学习功能 • 演绎推理功能 • 更强的系统交互性 • 原有数据库功能的加强和集成也需要主动性的帮助

5. 5.1.3 什么是主动数据库 • 近年来，一些商品化的数据库管理系统,纷纷引进了所谓的“触发器(Trigger)”和“规则（Rule）”概念。在某种意义上引入了主动处理的功能。ISO的SQL3标准也支持通用的主动规则机制。他们支持的语义有：基本事件和简单事件的复合；事件－条件（Event-Condition, EC）和条件－动作（Condition-Action, CA）耦合；多种规则粒度；串行的规则选择和可中断的规则执行方式等。

6. 主动数据库提供给用户一个统一定义主动功能的平台，方便使用和修改，同时提高了系统的可靠性和性能。主动数据库的一个突出的思想是让数据库系统具有各种主动进行服务的功能，并以—种统一而方便的机制来实现各种主动性需求。主动数据库提供给用户一个统一定义主动功能的平台，方便使用和修改，同时提高了系统的可靠性和性能。主动数据库的一个突出的思想是让数据库系统具有各种主动进行服务的功能，并以—种统一而方便的机制来实现各种主动性需求。

7. 5.2 触发器技术5.2.1 标准SQL中的主动数据库功能 • SQL3引入了触发器的功能，从而在公共的标准上实现了对主动数据的支持。

8. SQL3触发器的语法如下： • <SQL3 trigger> ::= CREATE TRIGGER <trigger name> • {BEFORE | AFTER | INSTEAD OF} <trigger event> • ON <table name> • [ORDER <order value>] • [REFERENCING <references>] • WHEN (<condition>) • <SQL Procedure statement> • [FOR EACH {ROW | STATEMENT} ] • 其中： • <trigger event> ::= INSERT | DELTE | UPDATE [ OF <column names> ] • <reference> ::= OLD AS <old value tuple> | • NEW AS <new value tuple> | • OLD_TABLE AS <old value table name> | • NEW_TABLE AS <new value table name>

9. 触发器是按照事件(Event)-条件(Condition)-动作(Action)的规则定义的。在SQL3触发器中，触发的事件仅限于数据更新操作，不支持数据查询操作。每一种触发器操作有3种可能的触发时间，他们是BEFORE、AFTER和INSTEAD OF，BEFORE为事件前触发，AFTER为事件后触发，INSTEAD OF表示触发器执行某项操作，而不是触发这个触发器的操作。SQL更新操作的对象一般来说是元组集，这样就存在一个操作粒度问题。一个SQL3触发器的操作粒度分为逐行(ROW)或以语句(STATEMENT)为单位。

10. 由于触发器的事件只能是数据更新操作，这些操作的执行会引起数据库中的数据变动，因此提出了旧值(old value)和新值(new value)的概念，其目的是为了在触发器语句的条件和动作部分可以用到而定义一个引用名。这些新旧值作为一种过渡值，要么是单个元组，要么是一个结果元组集，一般占据的空间不大，因而一般是暂存在内存中，并随着触发器的执行完毕而释放所占用的内存空间。SQL3的触发器语法中的REFERENCING子句就是实现上述的过渡值引用问题而设置的。在<reference>的定义中，OLD AS和NEW AS分别定义元组的旧值和新值的引用名，用于逐行监控；而OLD_TABLE AS和NEW_TABLE AS分别定义元组集的旧值和新值的引用名，用于按语句监控。

11. 5.2.2 在商业DBMS中的触发器 • 1. IBM DB2 • IBM DB2的触发器语法定义如下： • <DB2 trigger> ::= CREATE TRIGGER <trigger name> • {NO CASCADE BEFORE | AFTER} <trigger event> • ON <table name> • [REFERENCING <references>] • FOR EACH {ROW | STATEMENT} MODE DB2SQL • [WHEN (<condition>)] • {SQL STATEMENTS | BEGIN ATOMIC SQL STATEMENTS END} • 其中： • <trigger event> ::= INSERT | DELETE | UPDATE [ OF <column names> ] • <reference> ::= OLD AS <old value tuple> | • NEW AS <new value tuple> | • OLD_TABLE AS <old value table name> | • NEW_TABLE AS <new value table name> • 在DB2的触发器中，被触发的SQL语句可以包含DB2函数和用户自定义函数。用户自定义函数使用C/C++语言编写的，除用于一般的SQL数据控制操作，还可以允许触发器执行非SQL操作类型。

12. 2. Oracle • Oracle的触发器语法定义如下： • <oracle trigger> ::= {CREATE | REPLACE} TRIGGER <trigger name> • {BEFORE | AFTER} <trigger event> • ON <table name> • [[REFERENCING <references>] • FOR EACH ROW [WHEN (condition>)]] • <PL/SQL block> • 其中， • <trigger event> ::= INSERT | DELETE | UPDATE [ OF <column names> ] • <reference> ::= OLD AS <old value tuple> | • NEW AS <new value tuple> • 由其语法可知触发的动作部分在PL/SQL语句块中，可以包含各种声明和调用外部过程，但不包含数据定义语句或事务控制语句。

13. 5.2.3 触发器的使用 • 虽然各个RDBMS的触发器语法都有些差异，但总体结构都是依照ECA规则定义的。下面我们按照标准的SQL3语法来举几个例子说明触发器的使用。 • 在学生课程管理数据库中，有如下三个表 • 学生表：Student(Sno, Sname, Ssex, Sdept, Sage) • 课程表：Course(Cno, Cname, Ccredit) • 选修表：SC(Sno, Cno, Grade)

14. 1. 引用完整性约束的实现 • 通过分析，不难得出共有如下六种操作会影响到引用的完整性： • SC表的INSERT操作 • Student表的DELETE操作 • Course表的DELETE操作 • SC表UPDATE(Sno, Cno)操作 • Course表UPDATE(Cno)操作 • Student表UPDATE(Sno)操作

15. 以Student的DELETE操作为例说明触发器的使用：因为在SC表中，外键Sno的定义为CASCADE，所以当在Student表中删除一个元组时，要级联删除SC表中引用该元组的主键作为外键的所有元组。触发器语句如下：以Student的DELETE操作为例说明触发器的使用：因为在SC表中，外键Sno的定义为CASCADE，所以当在Student表中删除一个元组时，要级联删除SC表中引用该元组的主键作为外键的所有元组。触发器语句如下： • CREATE TRIGGER student_delete_trigger • AFTER DELETE ON Student • REFERENCING OLD AS OldRow • FOR EACH ROW • WHEN (EXISTS ( • SELECT * FROM SC • WHERE Sno = OldRow.Sno)) • DELETE FROM SC • WHERE Sno = OldRow.Sno;

16. 2. 导出数据的及时更新 • 一个典型的例子就是实视图的更新，实视图是由基表导出的表，作为一个实在的表存储在数据库中。恰当使用实视图可以提高查询速度，但在基表更新时，要保证实视图要及时刷新。 • 假设我们要对“计算机”系的学生成绩表CSCourse创建一个实视图，则可以由下面的语句创建： • SELECT Sname, Cno, Grade • FROM Student, SC • WHERE Student.Sno = SC.Sno AND Sdept=’计算机’； • 通过分析，可以得出下列的操作影响CSCourse的值： • Student表DELETE操作，且删除元组中有院系为计算机系的元组 • Student表INSERT操作，且删除元组中有院系为计算机系的元组 • Student表UPDATE(SName, Sno, Sdept)操作 • SC表DELETE操作 • SC表INSERT操作 • SC表UPDATE操作

17. 下面以Student表的DELETE操作为例，说明实视图的更新：如果Student删除的元组中有“计算机”系的元组，则要更新CSCourse表。一个简单的办法就是删除整个CSCourse表的全部内容，然后再生成新的CSCourse表。触发器语句如下：下面以Student表的DELETE操作为例，说明实视图的更新：如果Student删除的元组中有“计算机”系的元组，则要更新CSCourse表。一个简单的办法就是删除整个CSCourse表的全部内容，然后再生成新的CSCourse表。触发器语句如下： • CREATE TRIGGER cscourse_delete_trigger • AFTER DELETE ON STUDENT • REFERENCING OLD_TABLE AS OT • FOR EACH STATEMENT • WHEN (EXISTS ( • SELECT * FROM OT • WHERE Sdept = ‘计算机’)) • DELETE FROM CSCourse; • INSERT INTO CSCourse • SELECT Sname, Cno, Grade • FROM Student, SC • WHERE Student.Sno = SC.Sno AND Sdept=’计算机’; • 其中，OT是表的变量名作为对旧表的引用。

18. 5.2.3 触发器的优缺点 • 1. 触发器的优点 安全性 • 基于数据库的值使用户具有操作数据库的某种权利。具体表现在： 可以基于时间限制用户的操作，例如不允许下班后和节假日修改数据库数据。 可以基于数据库中的数据限制用户的操作，例如不允许股票的价格的升幅一次超过10%。 • 审计 • 可以跟踪用户对数据库的操作。表现在： • 审计用户操作数据库的语句。 • 把用户对数据库的更新写入审计表。 • 实现复杂的非标准的数据库相关完整性规则 • 在修改或删除时级联修改或删除其它表中与之匹配的行。 • 在修改或删除时把其它表中与之匹配的行设成NULL值。 • 在修改或删除时把其它表中与之匹配的行级联设成缺省值。 • 触发器能够拒绝或回滚那些破坏相关完整性的变化，取消试图进行数据更新的事务。

19. 2. 触发器的缺点 触发事件是简单事件 • 不能从简单的事件构造复杂事件的能力，也不能由用户定义其所需的事件的能力。 现时的触发器技术缺乏一个统一的标准 • 由于各个RDBMS厂商实现触发器的途径不一样，甚至它们定义同一个触发器的语法也不一样。这些造成了它们必依附在特定系统上，对软件环境的具体实现依赖性很大，不利于数据库的移植和代码一致性。 规则的执行方式不完备 当事件发生前或发生后，如果满足条件，则规则处于触发状态，动作将被执行。就动作触发的时间而言，可分为三类：立即式、延迟式、并发式。现时支持触发器的RDBMS一般都只支持立即执行方式，对于推迟到事务的末尾执行的延迟式以及具有并发/并行的并发式，由于其实现机制的复杂性，目前几乎还没有一个DBMS产品支持这两种执行方式。

20. 5.3主动数据库体系结构 • 在功能上，一个主动数据库系统(ADBS)由一个传统数据库系统(DBS)和一个事件驱动的知识库（简称事件库EB）及其相应的事件监视器(EM)组成，用公式表示为： • ADBS＝DBS+EB+EM

21. DBS(Database System)这个部分等同于一般的传统数据库系统，主要用来存储数据和对数据进行维护、管理与运用； • EB(Event Base)这也是一个数据库，这个数据库用来存储规则和对规则进行维护、管理与应用，是由事件驱动的一组知识组成的集合（规则集合），称为“事件库/规则库”，其中每一项知识表示在相应的事件发生时，如何来主动地执行其中包含的由用户预先设定的动作； • EM是一个随时监视EB中的事件是否已经发生的监视模块，一旦监视到某事件已经发生时就主动地触发系统，按照EB中指明的相应知识执行其中预先设定的动作。

22. 主动数据库管理系统与一般数据库管理系统在结构上的区别主要在于它除了有一个传统的关系型被动的数据库外，还添加了一个事件驱动的事件库和一个和多个事件监视器，监视器处于运行系统当中，主动并实时检测各种事件的发生，然后自动地根据发生的事件和条件按照一定的规则触发并执行所需动作。主动数据库管理系统的体系结构可用图1表示。图中实线表示控制连接，虚线表示数据连接。主要的区别是新增加事件监视和执行模块，它与规则库、数据库、数据字典乃至总控模块都有数据交换关系。主动数据库管理系统与一般数据库管理系统在结构上的区别主要在于它除了有一个传统的关系型被动的数据库外，还添加了一个事件驱动的事件库和一个和多个事件监视器，监视器处于运行系统当中，主动并实时检测各种事件的发生，然后自动地根据发生的事件和条件按照一定的规则触发并执行所需动作。主动数据库管理系统的体系结构可用图1表示。图中实线表示控制连接，虚线表示数据连接。主要的区别是新增加事件监视和执行模块，它与规则库、数据库、数据字典乃至总控模块都有数据交换关系。

23. 图1主动数据库管理系统的体系结构

24. 5.4 主动(ECA)规则 • 主动数据库系统对DBMS的基本要求是能处理下列的规则： • WHENEVER <事件> • IF <条件> • THEN <动作> • 即当发生某一事件(Event)时，如果满足给定条件(Condition)，则执行相应的动作(Action)，这种规则称为ECA规则(Event- Condition –Action的缩写)。主动数据库通过这样一种事件驱动的“事件－条件－动作”规则来表示数据库中的主动知识。

25. 5.4.1 ECA规则的构成 • 事件驱动的“事件—条件—动作”规则的语义是：“一旦指定的事件发生，计算机就主动触发执行其后的条件判断规则。即如果条件为真，则执行其后的动作。 • 规则的组成的三要素的：事件、条件、动作。 • 1）事件是在数据库系统在运行过程当中某特定时刻发生的，对系统有特定意义的事情，包括基本事件和复合事件，复合事件事是由基本事件经过各种事件运算构成的，复合事件是一种表达复杂事件的手段，使用户可以根据实际需要定义复杂事件，便于规则的设计、维护与传送。

26. 2）条件是关于当前或某个特定事件的数据库状态的一种假定，用某种逻辑(例如模糊逻辑)中的任意的一个合法的逻辑公式来表示一个条件，对于条件，可以依据逻辑运算将条件定义成简单的条件，也可以构造出很复杂的条件。2）条件是关于当前或某个特定事件的数据库状态的一种假定，用某种逻辑(例如模糊逻辑)中的任意的一个合法的逻辑公式来表示一个条件，对于条件，可以依据逻辑运算将条件定义成简单的条件，也可以构造出很复杂的条件。 • 3）动作是数据库可以执行的一组操作序列，这些序列中可以有系统预先定义的一些标准动作，也可以由用户定义复杂的动作，或是用某种程序设计语言表现的一个过程，而这些单个动作可以组合成动作序列，共同完成更加复杂的操作。

27. 5.4.2 ECA规则描述 • 数据库的主动功能主要是通过在主动数据库中预先设置一些处理规则来实现的。这些规则规定了事件发生的条件、相应的动作等内容。这些规则的表示模式主要是采用事件—条件—动作这种模式来表示（在一些系统中也有采用情景－动作模式即S-A来描述规则），即ECA规则。我们的事件库就是存储和管理这一系列ECA规则的地方，ECA规则的基本描述为： • RULE<规则名>[<参数列表>] • ON<事件列表> • IF<条件1> THEN • <动作1 > • [WHERE<约束1>] • [EXCEPTION<例外处理动作1>] • ．．．．．． • IF<条件n> THEN • <动作n > • [WHERE <约束n> ] • [EXCEPTION <例外处理动作n>] • END RULE

28. 说明如下： • 1）规则名用来在系统中唯一标识该规则，在进行规则的匹配和管理时用来指定规则。 • 2）参数列表，参数列表是可选的，在检查该规则时，这些参数将带入系统的实时值。 • 3）事件列表描述的是该规则要处理的事件。 • 4）条件表达式是一种合法的逻辑公式，如果条件表达式的值为真，则其后描述的动作序列将被执行。 • 5）动作序列是当相应的事件发生并且条件满足时执行的一系列预定的动作，在动作当中，可以进一步引发另一个事件。 • 6）约束是指这条规则执行时必须遵循的约束条件，包括对执行时间的约束、动作开始前的前置条件以及在动作完成后结果应满足的后置条件等等，约束时可选的，当不指明WHERE子句时，表示没有约束。 • 7）异常（例外）处理动作指出在规则的执行过程当中，当出现异常或约束未被满足时所应作的一系列预定的动作，异常处理动作是可选的，当不指明EXCEPTION子句时，表示没有异常处理。

29. 5.4.3 事件 • 1. 事件定义 • 事件是在数据库系统运行中的某特定时刻对系统有某种意义的“发生”，包括两方面的含义： • (1)事件标志着系统行为，数据库系统的行为可以是数据库操作、事务管理操作、时间行为或系统与外部环境的交互等。事件又分为基本事件和复合事件，各种基本事件经过各种事件运算构成了复合事件。复合事件的引入，减少了类似规则关于不同基本事件的重复定义，使一条规则能对多种复杂的触发事件进行监控，便于规则的设计、维护与传送。 • (2)事件还标志着系统行为发生的时间属性，由于系统行为往往发生在一个时间段，或是一个时间点，事件可以用一个时间参照点来指明。我们可以选择的系统行为开始的瞬间，也可以是系统行为结束的瞬间作为事件的时间参照点，还可为周期事件或区间事件，通常，我们对于数据库中的每种数据操作可以定义以下五个事件：Before。After、At、Every、Within。 • 事件都具有“原子性”，在某一时刻，或者完全发生，或者根本不发生，没有第三种状态。

30. 2. 原子事件 • 原子事件(Primitive Event)是规则系统预先定义的，不可分割的最小事件，只有有限种，事件按发生的持续时间可分为瞬时事件与区间事件。每个事件都有一个事件名标识，并有开始(发生)时间B(e)、终止(发生)时间E(e)和发生期D(e)等属性，其中e是一个事件名。 • 原子事件可以按照性质近似于聚类分成若干不同种类，在面向对象的主动数据库中，与对象操纵有关的方法的执行都是原子事件．在关系数据库中，原子事件按照性质可以分为三类： • 数据操纵类 • 事务类 • 时序类

31. (1) 时间相关事件 • 时间相关事件指在某个特定的时间点上或时间区段内发生的事件，数据库事件是根据数据库的状态进行监测的，而时间事件不能由数据库系统自动地检测，它由系统指定的时间来确定事件的发生．即由一个附加的系统组件，使用系统时钟，作为脉冲生成器向数据库系统发送时间脉冲 • 绝对时间事件：(Absolute time events)。一个绝对时间事件描绘了一个绝对时间点t0．每个事件类只有一个实例作为绝对时间事件并且只能发生一次。 • 相对时间事件（relative time events）。一个相对时间事件指定了一个事件相对于另外一个事件发生的时间点。 • 周期时间事件（Periodic time events），当起始事件发生后将周期地激活周期时间事件。

32. (2) 数据库状态相关事件 • 数据库状态发生改变时引发数据库状态相关事件。这类事件又可分为： • ①系统提供的操作，如插入、检索、删除、修改等 • ②用户定义的操作 • ③事务的开始与结束

33. （3）外部事件 • 外部事件来源于系统外部组件，它是一种系统不能预先定义的活动标志，如I/O中断，外部命令、一个运行在后台的进程、外接设备等引起的中断或发出的信号。但这种事件不一定与数据库的操作或时间有关。

34. (4) 异常事件 • 某种异常操作引发的事件，如对于一些未经授权的数据进行访问，违反完整性约束的操作等引发的事件。

35. (5) 其它的基本事件 • 除上述的几类基本事件外，还有数据库操作语言或处理引发的事件、数据库同一用户各个程序之间和不同用户之间变量使用、通讯和同步而可能引发的各类事件等基本事件，这些事件常在程序中实现处理、实施监控或在复合事件中应用。

36. 3. 复合事件 • 事件操作符允许将一个复杂事件Ec描述为任意称之为Ep的基本事件的原子事件或复合事件的组合，即将若干成分事件（原子事件或复合事件）用系统规定的事件操作符联结起来，作为单个的事件处理。复合事件的发生也有原子性。并且同样用事件修饰符界定具体发生的时刻。导致某复合事件Ec发生的原子事件Ep称为其结束事件：“before(after)Ec”的发生时刻即为“before(after)Ep”的发生时刻。

37. 复合事件的组成用事件表达式表示。事件表达式可定义如下：复合事件的组成用事件表达式表示。事件表达式可定义如下： • （1）任意原子事件e都是事件表达式。 • （2）如果e1，e2，...，en是事件表达式，则事件操作符作用于e1,e2,...,en上的结果为事件表达式。 • （3）对于任意事件表达式e，（e)是事件表达式。

38. 事件表达式的语义表达能力取决于系统支持的事件操作符，我们这里仅列出最基本的事件操作符及其语义： 设e与e’为两个事件，B(e)为事件e开始发生的时间．E(e)为事件e结束的时间，D(e)是事件e的发生期，以下是各种事件运算的定义： • (1)同时发生运算∧ （ΠθεΣΦβθλμ∞∏∈∑∩∪∧∨┓∣） • (2)选择发生运算 ∣ • (3)合并发生运算V • (4)相继发生运算符号• • (5)之前发生运算< • (6)之后发生运算> • (7)不发生运算┓ • (8)ANY运算(运算符V'm) • (9)计数算子(COUNT)事件

39. 5.4.4 条件 • 条件通常认为是关于当前或某个特定时间的数据库状态的一种假定，在评价条件数据库状态的变迁、趋势及所经历的数据都是要考虑的因素。条件一般用逻辑公式表示。条件规定执行行动时数据库相关部分处于何种状态，即它告知必须评价什么，规则触发后必须接着竞选条件的评价。规则条件部分的复杂性对规则的应用来说是关键性的因素，这不仅涉及它的说明、评价与监视，还直接关系到其数据库模型的规范说明。分类规则条件如下：

40. 1. 简单条件：只需对单个数据对象进行评价的条件，这种条件只与单个对象相联，且易于评价。它又可具体分为下列情形： • 只与指定对象的指定属性有关，例如表中某行数据的某一列数据。 • 与指定对象的多个属性相关，例如表中某行数据的多个列。 • 与任何对象的指定属性相关，这里涉及到了多个对象，但是只与其中的一个属性有关，例如两个表中某指定行的指定列数据的评价。 • 与任何对象的任何属性(可以多个)相关。 • 与对象作为整体的变化有关，将对象作为整体考虑，不考虑其中的局部属性的不同，即对象的增减。

41. 2. 统计条件：这些条件与更全面的统计观点相关，这些条件的评价涉及到大量的数据，例如统计人的年龄，系统的平均负荷等，这种条件可以是； • 单个对象类的一个或多个属性的导出数据，对这多个属性进行统计评价，如一个计划的可行性评价必须综合考虑经济可行性，技术可行性，法律可行性的诸多因素。 • 多个对象类的单个属性的导出数据，对多个对象的某个属性进行统计评价，例如统计某个工人的评价工资水平。

42. 3. 结构条件：上述两类条件都涉及独立的单个对象，结构条件则与对象间的语义结构联系有关，其联系可以是聚集(Aggregation)、概括/特化(Generalization／Specification)、关联(Association)，结构条件的评价与对象间联系的语义有关，故要在规则定义时专门给定。这类条件可以是有关下列情况的： • 相联系的对象的属性变化，局部特性的变化。 • 相联系的对象变化。 • 相联系的对象类的整体特性变化。

43. 4. 时限条件：与时间有关的条件评价。它总是与时间事件相联，要求系统能够进行时间的识别和运算，即系统必须有的“识时”机制。绝对时间、相对时间或周期时间都可以在时限条件中进行评价，如“事件A发生２小时以后”，“事件A在3：00发生”，“事件A每小时发生一次”。

44. 5. 复杂条件：复杂条件是由前面介绍的简单条件经过条件运算构成的，这些条件包括条件的布尔表达式、跨多个事务的条件、涉及数据集而不是单个数据值的条件等。复杂条件在表示、监视与评价方面都更为复杂。这类条件可包括： • 跨多个事务。例如判断多个事务是否都成功完成。 • 与(数据库)模式识别有关。 • c，多个条件的组合。多个简单条件的布尔运算，这些运算有Not 、And、Or等。

45. 5.4.5 动作 • 动作可以是触发事务本身的一部分，也可以是其子事务(若有事务嵌套概念)或独立事务。 • 被触发的动作虽然也是施加于对象上的操作，但与一般操作不同的是：我们必须确定它该如何执行、何时执行以及与它的触发事务和条件的联系等方面，这些方面的信息必须包括在被触发动作描述当中。一般地，被触发动作可描述如下： • TRIGGERED-ACTION=[<ACT>， • EXECUTION-INTERVAL，C-AMODE， • SCHEDULING-INFOR，FAILURE-HANDLING] • ACT=[PROCEDURE-Name(parameters)，Procedure-body] • ． EXECUTION-INTERVAL=[Start-event，End-event]

46. ACT描述了执行的动作细节，如参数（parameters），操作步骤（Procedure-body）等。ACT描述了执行的动作细节，如参数（parameters），操作步骤（Procedure-body）等。 • EXECUTION-INTERVAL描述了动作执行的时间区间，在Start-event表示此事件发生时开始动作，End-event表示此事件发生结束动作的执行。 • C-AMODE说明条件评价与动作的耦合方式，这些耦合方式有三种：立即式、延迟式和分离式(deecoupled) ，将在后面详细介绍。 • SCHEDULING—INFOR记录系统调度需要的信息，指明动作如何执行，如指定动作执行的优先级(在多个激发的触发器中间)等。 • FAILURE-HANDLING说明失败处理方式．有两类失败，一是触发事务的失败，二是被触发动作本身失败。触发事务的失败直接作用于被触发动作，此时可以有两种处理方式，当它们结合很紧密时，触发事务的失败引起动作的还原(rollback)(如果动作已开始执行)或撤消(如果尚未启动执行)，当它们的关系相对独立时，对触发事务的失败，被触发动作可以不予理睬。对被触发动作本身失败的处理也可有多种选择，简单的是“夭折”或“不管”。但对某些情况，更合理一点还可以是“重复若干次再夭折”或“执行另一个事务”，甚至可以是它们的组合。

47. 5.5 主动数据库的实现5.5.1 实现途径

48. 1. 改造的途径 • 对于主动数据库来说，首先要有与传统数据库具有的数据操作功能。因此，实现主动数据库的一种方法是在已有的关系型数据库的基础之上进行改造，扩充其功能，为其添加事件监视器和事件库，使其可以完成主动数据库的功能。其中事件监视器具有较高的执行优先级别以及较小的系统开销，事件库可以保存在关系型数据库中，规则由用户预先定义，这样我们就建立起一个高效率的、有实用价值的主动数据库。

49. 2. 嵌入主动程序设计语言的途径 • 这种方法需要改造或重新设计一种程序设计语言，这种程序设计语言具有主动功能，在程序中可描述ECA结构，规则库在程序语言中被说明和使用，成为其中的一个对象，这样设计处理的程序具有主动功能，然后有这种具有主动功能的程序将传统数据封装起来，主动程序作为人机接口，给用户提供一个主动数据库。这种途径减少了规则匹配时间，运行效率可以得到大大提高。

50. 3. 重新设计主动数据库的途径 • 重新设计主动数据库就是从零开始，针对主动数据库的特点，设计出一个全新的数据系统，其中的数据存储方法，系统结构，人机接口都是完全重新设计的，这样的一种方法可以最大限度的提高系统的性能，但是重新设计一种数据库的工作量也是巨大的。 • 第一种途径是一种最简单的途径，可以充分利用现有的技术和资源，但效率较差；第二种途径是一种折中方案，改造的工作量适中，除了在两种语言的接口部分可能损失一定的效率之外，运行效率较好；第三种途径是一种最彻底的方案，运行效率高，但是开发较为复杂，开发时间也需要较长。因此应根据具体情况对上述三种实现途径进行具体的选择。