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

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

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

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

5.1.3 什么是主动数据库• 近年来，一些商品化的数据库管理系统 , 纷纷引进了所谓的“触发器 (Trigger)” 和“规则（ Rul

e ）”概念。在某种意义上引入了主动处理的功能。 ISO 的 SQL3 标准也支持通用的主动规则机制。他们支持的语义有：基本事件和简单事件的复合；事件－条件（ Event-Condition, EC ）和条件－动作（ Condition-Action, CA ）耦合；多种规则粒度；串行的规则选择和可中断的规则执行方式等。

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

5.2 触发器技术5.2.1 标准 SQL 中的主动数据库功能

• SQL3 引入了触发器的功能，从而在公共的标准上实现了对主动数据的支持。

• SQL3 触发器的语法如下：

• <SQL3 trigger> ::= CREATE TRIGGER <trigger name> • {BEFORE | AFTER | INSTEAD OF} <tri

gger 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>

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

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

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 操作类型。

• 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 na

mes> ]• <reference> ::= OLD AS <old value tuple> |• NEW AS <new value tuple>

• 由其语法可知触发的动作部分在 PL/SQL 语句块中，可以包含各种声明和调用外部过程，但不包含数据定义语句或事务控制语句。

5.2.3 触发器的使用• 虽然各个 RDBMS 的触发器语法都有些差异，但总体结构都是依照 ECA 规则定义的。下面我们按照标准的 SQL3 语法来举几个例子说明触发器的使用。

• 在学生课程管理数据库中，有如下三个表• 学生表： Student(Sno, Sname, Ssex, Sdept, Sa

ge)• 课程表： 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 表中引用该元组的主键作为外键的所有元组。触发器语句如下：• 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;

• 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 操作

• 下面以 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 是表的变量名作为对旧表的引用。

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

• 2. 触发器的缺点触发事件是简单事件

• 不能从简单的事件构造复杂事件的能力，也不能由用户定义其所需的事件的能力。现时的触发器技术缺乏一个统一的标准

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

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

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

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

/交互接口 程序接口

总控程序

DDL处理模块

DDL处理模块

求助和解释模块

日志和恢复模块

DML处理模块

实用程序包

事件监视和动作执行模块 数据库和数据字典

内存表格和缓冲区

ECA规则库

终端用户 程序

5.4 主动 (ECA) 规则• 主动数据库系统对 DBMS 的基本要求是能处理下列的规则：• WHENEVER < 事件 >• IF < 条件 >• THEN < 动作 >• 即当发生某一事件 (Event) 时，如果满足给定条件

(Condition) ，则执行相应的动作 (Action) ，这种规则称为 ECA 规则 (Event- Condition –Action 的缩写 ) 。主动数据库通过这样一种事件驱动的“事件－条件－动作”规则来表示数据库中的主动知识。

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

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

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

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

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

t 、 Every 、 Within 。• 事件都具有“原子性”，在某一时刻，或者完全发生，或者根本不发生，没有第三种状态。

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

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

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

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

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

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

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

fore(after)Ec” 的发生时刻即为“ before(after)Ep”的发生时刻。

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

• 事件表达式的语义表达能力取决于系统支持的事件操作符，我们这里仅列出最基本的事件操作符及其语义： 设 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) 事件

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

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

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

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

• 相联系的对象的属性变化，局部特性的变化。• 相联系的对象变化。 • 相联系的对象类的整体特性变化。

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

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

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]

• ACT 描述了执行的动作细节，如参数（ parameters ），操作步骤（ Procedure-body ）等。

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

5.5 主动数据库的实现

5.5.1 实现途径

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

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

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

5.5.2 事件监视器• 1. 事件监视器实现机制• 一个有效的事件监视器对整个主动数据库的性能起着关键作用，一个设计良好的事件监视器既能有效地检测出各种事件的发生，又不能因为它的加入运行而使原应用程序的执行速度太大地大大减慢。下面提供几种可供选择的实现机制。• 1 ） 在单处理器系统中，用操作系统控制下的一个优先级较高的独立进程来实现事件监视器，这样的进程我们通常称为服务经常或精灵进程，高的优先级能保证它总能经常地被运行，起到主动监视各种事件发生的作用。另外，可以将事件库被分成块时，对较小的块进行规则的匹配，可以进一步提高监视器的运行效率。• 2 ） 在多处理器系统中，由于事件监视器需要频繁执行，消耗大量的 CPU资源，因此，适合用一个独立的 CPU 来实现事件监视器，这样可以有效的将主动数据库的负载进行分配，数据库的传统功能和事件处理功能分开，可以实现最大的处理并行度。• 3 ） 定点检查的方式，在系统执行过程中某些指定位置，这些位置可以是系统默认指定的，也可以根据用户定义进行指定，当系统运行到指定位置的时候，暂停系统的执行，监测事件是否发生。如果事件发生则进行相应的处理，否则系统继续运行。

• 2. 事件监视器分类• 按监测到某事件后激活执行相应动作的时间分类

– 立即式。事件监视器监测到事件发生后立即对事件进行处理。– 延迟式。事件监视器监测到事件发生后不立即对事件进行处理，一般有一个时间的延迟，这个延迟可能是用户定义的，也可能是系统执行上的要求（如等待一个事务的完成）。– 并发式。事件监视器监测到事件发生立即生成一个并发进程对事件进行处理。

• 按可能被激活执行的位置或时间分类– 全程式。允许在在被监视过程的执行过程中任何地方启动监视器处理事件。– 定点式。事件监视器只有在特定的过程执行点上才能对事件进行相应的处理，例如在过程的开始，结束处，在过程挂起的时候等。

按物理实现模式分类– 软件式。事件监视器由软件实现，不需要硬件的干预，这样的监视器简单，方便，不过性能差，执行效率较低。– 硬件式。由硬件和固件来实现事件监视器，这种监视器一般效率和成本都较高，在实时环境中使用较多。– 软硬件结合式。有软件和硬件共同配合实现事件监控器，性能相关的部分用硬件实现，灵活性要求高的部分使用软件实现，充分结合软硬件的特定。

• 按内部的执行模式分类– 串行式。事件触发后，规则的执行是按串行的方式执行的。– 并行式。事件触发后，规则的执行是按并行的方式执行的，一般生成多进程进行规则的处理。– 择一式。对于匹配命中的多条规则，并不是全部都执行，而是根据一定的规则，选择并执行其中的部分。– 递归式。规则的执行允许递归，在执行一条规则的时候允许激活执行本条规则自身，这种监视器较多的应用于诸如演绎推理等工作中。

5.5.3 基于组件的主动数据库模型探讨• 1. 基于组件的主动数据库结构• 传统的 ADBMS由一个传统的 DBMS 和一个能自动检测系统事件并进行条件匹配和活动触发的主动机制组成 , AD

BMS 中所有的事件都被事件探测器监视 , 当事件发生时 , 事件处理器进行条件匹配 , 如果成功则触发相应的动作执行。• 基于组件的 ADBMS 实现方法直接利用已有的 DBMS 完成数据组织、共享等方面的功能 , 在数据连接层加入一个中间层组件监视系统发生的变化 , 并将这些变化实时地传给系统的事件监视器 , 当事件监视器发现有系统定义的事件发生时自动进行条件匹配 , 如果匹配成功 , 则触发相应的动作执行。其结构如图 2 所示。

用户应用程序1 用户应用程序N

主动数据操作组件

DB1 DBN

语义分析器

内存映射文件

事件库 情形表事件库

事件监视

器

方法库

活动触发

器

情形评价

器

时钟发生器 活动队列

外部主动机制实现模块...

...

• 2. 模型实现中的主要技术• 基于组件的 ADBMS 进行事件监视的关键在于 , 能够实时地探测用户对数据库的操作 , 并把用户的操作发送给事件监视器。基于组件的 ADBMS采用对象包含探测用户对数据库的操作 , 利用消息队列将探测到的信息发送给事件监视器。• 利用微软发布的 COM 包含方法复用了 ADO组件所提供的功能，实现了主动数据库组件对数据库的访问。使用微软消息队列 (Microsoft Message Queue, 简称MSMQ) 来实现组件间的消息传递。 MSMQ 是面向组件的消息系统 , 提供了基于事务的消息截获和消息事务 , 通过实现一个先进先出的队列 , 在组件之间传递消息。

• 3. 基于组件的 ADBMS 实现模型• 根据基于组件的 ADBMS结构 , 我们利用动态数据对象在数据连接层实现了基于组件的 ADBMS模型。该模型仍采用 ECA模式 , 通过主动数据操作对象实时地监视用户在数据连接层的操作 , 并将这些操作通过消息机制传给系统的事件监视器 , 同时将用户的操作进行语法分析提取相关数据后 , 再保存到内存文件中。当系统探测到定义的事件发生时 , 可直接到内存文件中提取用户操作的信息 , 根据操作信息与事件所对应的条件进行匹配 , 如果匹配成功则触发相应的活动执行。• 模型各模块划分及功能如下 :

• 1) 语义分析器： 用于分析用户命令中的 SQL 语言 , 得到用于所要修改的对象信息及修改的内容 , 并把分析得到的数据存入系统运行时的内存映射文件中。事件监视器利用对象信息及修改的数据值 , 由数据驱动判断用户定义的事件是否发生。• 2) 事件监视器：根据带消息机制的 ADO组件发出的消息，取出内存文件中记录的用户操作信息 , 再与事件库中记录的事件进行比较 , 判断是否符合用户定义事件或系统事件 , 如果符合则触发相应的事件 , 将事件放入运行时的事件表中排队 , 等待情形评价器进行规则匹配。事件监视器还负责记录系统中发生的所有事件及相关信息 , 为系统维护及检查做日志。• 3) 情形评价器：根据事件及事件所对应的规则组成 (E-C) 耦合 , 并把每一组 (E-C) 耦合组成一个情形。当有事件发生时 , 检查所有具有该事件的情形中的规则 , 如果规则成立则触发该情形所对应的方法 , 并根据情形所定义的优先级调度该方法。• 4) 活动触发器 : 当运行时产生的情形触发与之相关联的活动时 , 根据活动库中定义的活动名称、活动体和活动参数 , 按照定义的活动执行方式调度活动执行。在活动执行失败时撤消活动并对活动所引起的事务进行回滚操作。• 5) 时钟定时器 : 定时地发送系统时钟消息到事件监视器 , 用以产生时间事件。• 6) 事件及规则管理器 : 所有用户定义的事件和规则都需要永久地保留在系统数据库中 , 并可以随时调出供用户修改。事件及规则管理器负责维护和管理系统中的事件及规则。

5.6 面向主动对象的数据库• 面向主动对象的数据库系统将两者功能有机地结合在一起，一方面增强了面向对象数据库的功能，另一方面也弥补了主动数据库系统的某些不足。

5.6.1 面向主动对象数据库的组成• 与传统主动类似，在功能上 ,面向主动对象的数据库系统 (AOODBS) 可描述为 : 一个传统的面向对象系统 (OODBS) 和一个由事件驱动的知识库 ( 或称事件库 EB) 及相应的事件监视器 ( EM)组成 . 可用如下公式表示 :• AOODBS = OODBS + EB + EM• 其中 OODBS 用来存储对象以及对对象进行维护管理与使用 ; 事件库 EB 由系统和用户定义的各种事件驱动规则组成 ;EM 是一个随时监视 EB 中的事件是否已经发生的监视模块 , 一旦监视到某事件已经发生 , 就主动触发执行 EB 中事先设定的动作 .

5.6.2 主动对象类及面向主动对象的数据库模型• 一个“主动对象类”可以描述为一个四元组：• AO = {O, M, ECA, AOS}• 各个元素的含义描述如下：• O —— 一个对象元素的集合 , 每个对象元素可以是以某种方式由更简单的对象元素构成的复杂对象；• M —— 一个可施加在 O 上的方法 ( 或操作 ) 的集合 , 其中每个方法 m 可被表示为一个三元组：• m = {mn, md, eca}• 其中：

– mn 为方法 m 的外部接口 ,由方法名及其参数构成 ;– md 为对方法的具体描述 , 是对象内对方法的定义 , 对外不可见；– eca 为主动数据库中属于方法 m 的“事件—条件—动作—规则”集合 , 或简称 ECA 规则 . 它表示执行方法 m 时应激活的一个规则组 .

• ECA —— 主动数据库中属于对象 AO 的一组“事件—条件—动作”规则的集合 . 它表示在存取或操作该对象类中的对象时 ( 或者之前 , 或者之后 ) 应主动激活执行的一个规则集；• AOS —— 是一个对象类名字的有限集合 , 在此说明 AO 的各个超类。• 上述定义的对象具有“主动性”，是一种“主动对象”。并且该主动对象具有一般对象所具有的性质 : 支持封装 ,继承等特性，从而构成了一种层次结构 ( 单重继承 ) 或网状结构 (允许多重继承 ) 。

5.6.3 面向主动对象数据库的 ECA 规则• 面向主动对象数据库的 ECA 规则比传统的主动数据库 ECA 规则语义更丰富，一条 ECA 规则表示如下：• RULE < 规则名 > [<参数列表 >]• ON < 事件列表 >[(< 事件 - 条件耦合模式 >)]• IF < 条件 1> [(< 条件 - 动作耦合模式 1>)] THEN• < 动作 1 >• [WHERE<约束 1>]• [EXCEPTION< 例外处理动作 1>] • ．．．．．．• IF < 条件 1> [(< 条件 - 动作耦合模式 1>)] THEN• < 动作 n >• [WHERE <约束 n> ]• [EXCEPTION < 例外处理动作 n>]• END RULE• 主动对象类所属的 ECA 规则及其方法所属的 eca 规则都可用上述的“事件 -条件 - 动作”规则来描述。

5.6.4 面向主动对象数据库的实现途径• 1. 改造的途径• 面向对象的主动数据库系统可以通过在其原 RDBMS 或 OODBMS 上的基础上 , 通过增加事件检测部件来实现 . 事件库是用户事先设置好的一个库 , 应用程序运行的同时 ,由事件监视器来监视事件的发生 ,并根据事件库的设置自动支持相应的动作或动作序列 . 这种途径方法简单 ,但效率较差。• 2. 嵌入主动程序设计语言的途径• 将一般程序设计语言改造成为一种主动程序设计语言或重新设计一种主动的程序设计语言 ,然后设计一个接口把数据库操作嵌入其中进行执行 . 特别是采用面向对象的范式 , 可将事件库分布到各个对象中 ,运行效率大大提高 .• 3. 重新设计主动数据库设计语言• 这种方法要求重新建立面向主动对象的数据模型 , 定义主动的对象类 ,扩充和改进 ECA - 规则 ,设计适当的体系结构来实现 . 但是难度和工作量都比较大 ,目前正处于积极地探索中 .

5.6.5 面向主动对象数据库的优点• 1. 增强面向对象数据库的功能• 在原有面向对象数据库的基础上，面向主动对象数据库还包含更灵活和更完善的“一致性”和“完整性”检查、更强的安全性等，都可以通过在“ ECA 规则集”中灵活方便地放置一些关于一致性、完整性和安全性的检查规则来得以实现。• 。

• 2. 弥补主动数据的不足• 面向主动对象数据库不但增强了原有的面向对象数据库的功能，其面向对象特性还可以弥补主动数据库设计上的不足，表现如下：• ECA 规则库的“树状”结构使得运行效率大大加强• 主动数据库一般都是把所有的“ ECA 规则”放在一个全局的规则库中，每当事件监视器检查事件是否发生时都要扫描整个库而使运行效率降低。结合面向对象数据库后，运用面向对象的封装性、继承性，可以方便地把属于各个类的 ECA 规则封装在各自的类中，使得同一个类的不同对象可以共享共同的规则库，并在继承的机制下形成了一个“树状”的规则库，从而大大地提高了运行效率，在一定程度上缓解了主动数据库由于事件监视器的引入而出现效率降低的矛盾。• 具有面向对象的特性• 根据面向对象数据库中的继承机制，各层之间具有继承性，子规则库可以继承父规则库的内容。这样不但减少了规则的冗余，而且更适合于当前流行的面向对象思想，大大方便了 ECA 规则的设计、修改和维护

5.7 本章小结• 主动数据库是目前数据库技术中一个活跃的研究领域，近年来的研究已取得了很大的成果，但作为一个正在研究的领域，许多概念尚不成熟。本章介绍了主动数据有关的知识，包括主动性需求，主动数据库的发展历史，主动数据库的模型和系统结构、实现机制，触发器技术，面向主动对象的数据库技术等，并详细介绍了主动数据库中的

ECA 规则的内容，这些内容有事件及事件的运算，条件的分类以及要考虑的问题，动作的定义异常处理，然后介绍了 ECA 规则执行中的一些概念，包括规则的耦合、规则的优先级、规则的触发粒度等。