INMDB中复合事件监测机制的设计与实现

贺宏达　刘梦赤

(武汉大学计算机学院　湖北 武汉 430072)



INMDB中复合事件监测机制的设计与实现

贺宏达刘梦赤

(武汉大学计算机学院湖北 武汉 430072)

对于大多数主动数据库来说，复合事件监测始终是个难题。介绍信息网模型INM(InformationNetworkModel)数据库管理系统中的复合事件监测机制，详细描述利用事件树模型监测复合事件的思想，并提供具体的算法实现。经分析，该算法在运行效率和空间占用上均比常见的有限自动机和Petri网有着更好的表现。

信息网模型主动数据库复合事件监测事件树

0　引　言

与传统数据库相比，主动数据库能够对数据库管理系统内外发生的事件自动作出响应。这种自动响应机制通过主动规则来实现。一般来说，主动规则由三部分组成：事件、条件和动作[1]。事件，指数据库系统中某一时刻的数据操作引发[2]。主动规则定义之后，一旦对应的事件发生，数据库系统将对条件部分进行求值，若条件为真，则执行对应的动作。也就是说，事件是整个主动规则执行过程的起点。因此，事件的监测是主动规则设计时的首要问题。

要对事件进行监测，就必须先提供其描述。按照是否可分，事件通常可以分为两类：

(1) 原子事件：指单个的某一类事件。比如插入元组，更新属性，删除元组等。

(2) 复合事件：由几个原子事件或者复合事件通过事件代数中的操作符连接而成。

复合事件处理CEP(CompositeEventProcessing)的应用极为广泛，它能够从看似毫无意义的原子事件组合中查找是否有更复杂的情况发生。信用卡防盗刷、安全监控和商业活动监控等方面对此均有着强烈的应用需求，知名企业如支付宝等均大量应用CEP来处理网络欺诈、网络攻击等安全威胁[3]。而IBM、Oracle和微软等更是推出了一系列CEP产品来满足用户日益增长的需求。

1　相关工作

复合事件监测的主要难点在于建模。原子事件的监测相对较为容易，因而通常采取的建模方法都是从复合事件与其子事件以及相关原子之间的关系入手，建立起抽象的数学模型。现有的复合事件监测算法有Petri网、有限状态自动机、事件树以及事件图等。

Petri网是一种强大的建模工具，能够简洁明确的描述各种各样的复杂系统，因此常被用于复合事件建模。它将复合事件抽象为节点和节点之间转换关系的集合。其中，输出节点为待监测的复合事件，而输入节点为与之相关的原子事件。Petri网结构中包含的信息由令牌标记，令牌的转移方式则代表了原子事件的发生对复合事件的影响，转移方式保存在控制矩阵之中。当令牌在节点之间转移时，整个Petri网代表的复合事件的状态也随之发生变化。令牌每经过一个节点，就对此节点做标记。当Petri网中不再有未被标记的节点时，就表示对应的复合事件被监测到。比较典型的应用有SAMOS[4]和Hi-Fi[5]等。

有限状态自动机，将复合事件视为正则表达式，并由此构造出对应的自动机。子事件的发生将引起自动机状态的改变。当自动机进入终止状态时，则代表该终止状态对应的复合事件发生。比较典型的应用有ODE[6]和SASE[7]等。

事件树，基于语法识别时复合事件表达式被解析为语法树的思想，将复合事件抽象为相应的树结构。树结构中的叶子节点表示原子事件，根节点表示需要监测的复合事件，中间的各节点表示待监测复合事件的子孙事件。只有当一个节点的子事件都发生时，该节点对应的事件才被监测到。当整棵事件树中的所有子节点对应事件均被监测到时，就表示根节点对应的复合事件的发生。比较典型的应用有READY[8]和Zstream[9]等。

事件图的思想与事件树类似，用有向无环图来表示复合事件，其中的叶子节点表示原子事件，非叶子节点表示事件复合操作。同一复合事件的不同实例，作为不同对象进行处理。事件发生的消息从叶子节点向父节点传递，并标记沿途节点。当图中所有节点均被标记时，该事件图对应的复合事件被监测到。比较典型的应用有Snoop[10]和EVE[11]等。

目前学术界的主流研究方向大多集中于有限状态自动机和Petri网。前者的缺点主要在于系统中复合事件子事件的状态数与子事件个数呈指数相关。例如，复合事件E=E1ANDE2ANDE3中每个子事件都有两个状态，从而需要8=23个状态来表示该复合事件。而后者的缺点则在于表示和执行太过复杂，处理较为简单的复合事件时显得过于累赘。例如，复合事件C2 =E3THENE4，用PetriNets表示之后不仅需要多个对象来表示复合事件的状态，还需要一个转换矩阵来控制状态之间的迁移，极为繁琐。至于事件图，该方法在表示复合事件时缺乏统一的形式框架，同时没有统一的形式规范来描述复合事件监测过程。

综合分析以上几种方法，事件树的表现更为优异。因此，本文结合INMDB的特性，基于事件树的结构作出改进，提出了一种新型的事件树结构——高级事件树AET(AdvancedEventTree)，并在此基础上设计实现了INMDB中的复合事件的监测机制。该监测机制能够准确捕获常见的几种复合事件，具有较好的运行效率和较低的空间占用，同时，又能够与原有系统很好地耦合。

2　INMDB中的事件模型

信息网模型INM(InformationNetworkModel)是面向对象的语义模型，它将现实世界的实体抽象为数据库中的对象，具有相同特点的实体被抽象为类，实体间的关系转换为对象之间的关系[12]。基于INM实现的数据库管理系统INMDB引入了角色关系、复杂关系、多元关系以及它们各自的逆关系等概念，表示对象之间的关系时显得更为直观、自然。

2.1原子事件

在INMDB中，事件区分类型和实例。按照事件代数中的约定，事件类型用大写字母开头，可以包括数字，如Event、Event1或A等；而事件实例则用小写字母开头，末尾加下标数字，如event1、event11和a1等，下标数字用于区分发生的先后次序，数字越小，对应的事件实例越先发生。

前文提到，事件可以分为原子事件和复合事件两类。INMDB中的原子事件主要包括：

(1) 方法事件。对数据库中的数据对象进行操作。

(2) 时序事件。当系统时间运行至某一特定时刻时触发，用绝对时间表示。

(3) 抽象事件。与外部环境之间的通信，由应用层的消息或用户指令显式触发。

抽象事件的发生具有不确定性，因此，不在事件监测的考虑范围内。时序事件与此类似，INMDB底层没有计时机制，所以该部分通过开放底层接口，由应用层计时来实现。抽象事件和时序事件的监测都由应用层实现，因此，不在本文的讨论范围之内。下文提到的原子事件只包含方法事件。

目前的INMDB包括类、对象和查询三个部分，其中查询不涉及对数据的修改，因此，原子事件主要与前两者相关。

例1对类的操作：创建一个“大学”的类。其中带“@”的指当前类具有的属性，而不带“@”的则指当前类与其他类之间的关系，inverse后为该关系的逆关系[13]。

createclass大学[

@建校日期：date,

所在市(N:1)：城市(inverse下辖大学)，

@世界排名：int];

例2对对象的操作：创建一个对象"教授”，并指定他所指导的学生和教授的课程以及办公室电话。

insert教授 张三[

指导学生：{李四，王五}，

教授课程：数据库系统

];

例3对对象的操作：将对象“A大学”中的关系“地址”的值修改为“B市”。

updateA大学modify地址:B市;

对象数据库中，通过向指定对象传递消息进行底层数据的访问与操作。因此，每个方法事件都与特定的类名、方法名以及操作对象的名字相关。与一般对象数据库有所区别的是，虽然INMDB中不同类型方法事件对应的类不同，如例1、例2和例3，分别对应SchmClass类、Instance类和UpdateModify类，但方法名都相同，均为execute()。因此，原子事件定义时，可以通过指定类名和操作对象名，并在此基础上进行封装，来唯一标识该事件。

为了便于索引及组成复合事件，所有事件都具有唯一的事件名。事件名与事件代数中用于表示事件类型和实例的标识符不同，不受后者定义时对首字母的限制。

事件定义语句的文法描述如下：

CREATEEVENTeventNameEQUeventExpressionSEMICOLON

例4原子事件的定义：定义名为“updateJack”的原子事件，监测对象“Jack”中的数据的修改。

createeventupdateJack=updateJackmodify;

该定义语句经过语法解析之后，可以得到对应的类名UpdateModify和操作对象名Jack。这些信息封装在原子事件类primitiveEvent中，存入数据库底层。针对原子事件建立两个索引，分别以“类名+操作对象名”和“事件名”为键值。

在原子事件updateJack已被存入数据库底层的前提下，当用户输入命令“updateJackmodifyage:25;”时，原子事件监测器会以操作类名updateModify和操作对象名Jack为键值在数据库底层进行查找，并成功返回。此时，即表示事件updateJack被监测到。

2.2复合事件

复合事件的处理往往会涉及到时间范围的限制。与一般主动数据库不同，INMDB中的时间间隔由子事件来标识，而非绝对时间点。在需要使用绝对时间点的地方，可以先创建对应的原子事件，对其进行封装。这样的设计使得INMDB在可扩展性方面表现更好。

按照事件操作符的不同，复合事件具体可以分为六类，操作符依据涉及的子事件个数又可分为二元操作符和三元操作符两大类。

二元操作符对应复合事件具有如下形式：

Event=Event1OPEvent2

具体分为：

合取:对应操作符为AND，只有当Event1、Event2均发生时，Event才发生；

析取:对应操作符为OR，当Event1或Event2已发生时，Event才发生；

顺序:对应操作符为THEN，只有当Event1在Event2之前发生时，Event才发生；

二元事件的时间范围默认为同一事务中。

三元操作符对应复合事件具有如下形式：

Event=OPEvent2inEvent1,Event3

Event1,Event3用于标记一段时间间隔。

具体分为：

截止:对应操作符为ALL，将指定时间间隔内Event2的所有发生视为一次发生，并以此触发Event的发生。

历史:对应操作符为mTIMES，只有当Event2在指定时间间隔内发生m次时，Event才发生。

否定:对应操作符为NO，只有当Event2在指定时间间隔内没有发生时，Event才发生。

复合事件的状态随子事件状态的变化而变化。下面将用一个例子来大致阐述该过程。

例5定义事件instantiationOfA，监测在类A创建之后插入其对象a的行为。

createeventcreateSchmA=createclassA;

createeventinsertInstA=insertAa;

createeventinstantiationOfA=createSchmAtheninsertInstA;

instantiationOfA为顺序复合事件，该事件虽然是二元复合事件，却与三元复合事件有着相似之处。当子事件createSchmA未被监测到时，无论另一个子事件insertInstA是否发生，均不会影响其状态。而createSchmA发生后，则instantiationOfA被“激活”，开始接受insertInstA状态的影响。若insertInstA此时发生，则instantiationOfA状态发生变化，标识着该复合事件被监测到，进而触发主动规则中其他部分的执行以及当前事件的父事件状态的变化。随后，两个子事件的状态被重置，以便监测下一次发生。

复合事件与其子事件之间状态变化信息的传递通过高级事件树AET(AdvancedEventTree)完成。

3　高级事件树

高级事件树AET的设计建立在事件树的基础之上。其构建基于对复合事件定义语句进行的语法解析。为了方便对复合事件进行词法分析和语法解析以获得必要的信息，建立事件表达式的文法描述如下：

eventExpression:primitiveEventExpression

|compositeEventExpression

compositeEventExpression:binaryEventExpression

|ternaryEventExpression

binaryEventExpression:eventNameANDeventName

|eventNameOReventName

|eventNameTHENeventName

ternaryEventExpression:ALLeventNameINeventNameCOMMAeventName

|INT_STRTIMESeventNameINeventNameCOMMAeventName

|NOeventNameINeventNameCOMMAeventName

binaryEventExpression表示二元复合事件，ternaryEventExpression表示三元复合事件。INT_STR表示整型常量，eventName对应事件名。

3.1节点

AET中的节点分为叶子节点和非叶子节点两类。节点与事件相对应，在INMDB中存储时以事件名为索引。事件可以与多条主动规则相关，也可以作为其他复合事件的子事件。作为子事件时，事件的状态将会对作为父事件的复合事件产生影响。对于顺序复合事件和三元复合事件，只有特定位置的子事件状态改变后，当前复合事件的状态才会发生变化。因此，存储相关复合事件时，需要依据当前事件的状态是否会对其造成影响而分类，分别设为activeComEvents和passiveComEvents。同时，还需要保存当前事件在相关复合事件中的位置。

因此，作为基类的Event类设计如下：

classEvent{

private:

stringeventName;

mapactiveComEvents;

//状态会受当前事件影响

mappassiveComEvents;

//状态不受当前事件影响

vectorrelatedRules;

};

与事件树相同，AET中的叶子节点表示原子事件。不同之处在于，中间节点不再只表示待监测复合事件的子孙事件，而可以表示其他待监测复合事件。通过按事件名索引，AET将所有相关的复合事件合并在同一颗树中，而不是每个复合事件都单独占用一颗事件树。

设有以下两个复合事件表达式：

(1)A=BANDC

(2)C=DORE

用一般的事件树表示，如图1所示。

图1　一般事件树表示

用AET表示，如图2所示。

图2　AET表示

因此，在复合事件表达式相同时，AET的空间占用比一般的事件树更少。

原子事件中封装有对应数据操作的类名和操作对象名。例如，createclassA[]; 操作对应的类为SchmClassPre，而对应的操作对象名为A。因此，AET中的叶子节点设计如下：

classPrimitiveEvent{

private:

stringoperationType;

stringoperationName;

};

其中，operationType为事件对应的操作类型，而operationName为事件对应的操作对象名。

依据文法描述，复合事件可以分为二元复合事件和三元复合事件两种。对于二元复合事件，其状态取决于两个子事件的状态。同时，子事件对齐影响方式取决于二元复合事件的类型。因此，二元复合事件类BinaryEvent设计如下：

classBinaryEvent:publicEvent{

private:

stringeventType;

boolleftStatus;

boolrightStatus;

stringleftEvent;

stringrightEvent;

};

其中，eventType为事件类型，leftEvent和rightEvent分别为左右子事件名。

考虑到三元复合事件与二元复合事件中的顺序复合事件有所类似，不妨将事件表达式E=OPE2inE1,E3中的E2视为待监测事件。截止、历史和否定复合事件均需要记录待监测事件的发生次数，因此，三元复合事件类TernaryEvent设计如下：

classTernaryEvent:publicBinaryEvent{

private:

intmonitoredEventCount;

inttargetValue;

stringmonitoredEvent;

};

monitoredEventCount记录待监测事件的发生次数。targetValue保存待监测事件的期望发生次数，在截止复合事件中默认值为-1，历史复合事件中与定义语句中相同，而否定复合事件中其值为0。

3.2边

依据3.1节中Event类的描述，AET中的边对应着子事件指向相关复合事件的指针。子事件的状态变化通过该指针进行传递，表现在AET中便是状态变化的消息沿叶子节点一直向上传递。

3.3AET的构建

AET的构建过程，主要分为事件表达式解析过程和预处理过程。前者主要目的在于通过事件表达式的语法解析，生成对应的事件类；而后者的主要目的在于建立起新的事件与数据库中已有事件之间的关系。

在INMDB中，事件定义语句具有如下形式：

createeventeventName=eventExpression;

语法解析过程中，对该定义语句进行处理，可以获得当前事件的事件名。对于复合事件，还可获得其子事件的事件名。结合前文中事件表达式的文法描述，便可构建出相应的Event类。

在预处理过程中，借助INMDB底层提供的查询接口[14]，按照子事件名进行查找，找到复合事件对应的子事件，并依据复合事件的类型修改子事件中的activeComEvents或者passiveComEvents，从而将新的复合事件添加到INMDB中。该过程的AET表示，如图3、图4所示。

图3　AET构建前

图4　AET构建后

4　复合事件监测算法

如第3节所述，事件定义语句中所包含的信息经过语法解析后，用于构造对应的Event类，并存入数据库底层。INMDB中的所有Event类彼此关联，形成一棵完整的AET。PrimitiveEvent类是它的叶子节点，而BinaryEvent类及其子类对应的事件则通过共同的子事件相关联，作为中间节点，并且其中有一部分会成为AET的根节点。

当数据操作命令输入时，可以通过语法解析获取操作类型对应的类名operationType和操作对象名operationName。通过在数据库中进行查找，可以确定是否存在对应的原子事件。如果能找到，则证明原子事件被监测到。

此后的处理方式与复合事件被监测到之后相同，即，将事件发生的消息传递给所有相关的父事件，即activeComEvents，并根据在父事件中的位置而做出不同的处理。设该部分对应函数为invoke()，用算法描述如下：

Input：Event中的activeComEvents

Output：无

FORactiveComEvents中的每个activeComEvent

//即对

IFactiveComEvent.second==left:

//置对应的左事件状态为true

activeComEvent.first.leftStatus=true

ENDIF

IFactiveComEvent.second==right

//置对应的右事件状态为true

activeComEvent.first.rightStatus=true

ENDIF

IFactiveComEvent.second==middle

//将待监测事件的计数增1

++activeComEvent.first.monitoredEventCount

ENDIF

ENDFOR

复合事件的监测建立在子事件被监测到的基础之上，而不同类型的复合事件的监测算法又有所不同。在介绍复合事件监测算法前，引入两个辅助函数，activateIn(subEvent)和deactivateIn(subEvent)。前者的功能为将当前复合事件从指定子事件的passiveComEvents转移到activeComEvents中。后者反之。

当复合事件被监测到之后，用于表示其子事件状态的leftStatus、rightStatus等均被重置，以便等待下一次发生。

4.1二元复合事件

二元复合事件可以分为三类：合取复合事件、析取复合事件以及顺序复合事件。

依据2.2节中的定义，当且仅当左右子树对应的事件均被监测到时，合取复合事件才被监测到；而只要左右子树对应的事件有一个被监测到，则析取复合事件就被监测到。

顺序复合事件相对较为复杂。对于形如Event1THENEvent2的顺序复合事件，只有两个子事件按顺序发生时，顺序复合事件才被监测到。即，若Event1未发生，则Event2的发生对复合事件而言没有意义。该状态可以通过将顺序复合事件置于Event2对应事件类的成员passiveComEvents中来表示。当且仅当Event1发生之后，Event2才被“激活”，从而能够影响复合事件的状态。相对应地，通过调用activateIn(Event2)，顺序复合事件从passiveComEvents转移到activeComEvents中。

根据上述分析，可以设计出二元复合事件的监测算法如下：

Input：BinaryEvent

Output: 无

SWITCHeventType:

CASEconjunction:

IFleftStatus&&rightStatus:

当前复合事件被监测到

invoke(activeComEvents)

//重置子事件状态，等待下一次发生

leftStatus=false

rightStatus=false

ENDIF

CASEdisjunction:

IFleftStatus||rightStatus

当前复合事件被监测到

invoke(activeComEvents)

//重置子事件状态，等待下一次发生

leftStatus=false

rightStatus=false

ENDIF

CASEsequence:

IFleftStaus

//在右子树中激活

activateIn(rightEvent)

ENDIF

IFrightStatus

当前复合事件被监测到

invoke(activeComEvents)

//重置子事件状态，等待下一次发生

leftStatus=false

rightStatus=false

deactivateIn(rightEvent)

ENDIF

4.2三元复合事件

三元复合事件主要用于监测指定时间间隔内，特定事件的发生次数。其左右子事件分别标记这段时间间隔的开始与结束，而三元复合事件类中的monitoredEvent成员则对应特定事件。因此，只有当左子事件发生之后，待监测事件与右子事件才被“激活”。同样，该步骤用activateIn()函数的调用来表示。

依据monitoredEvent发生次数的不同，三元复合事件可以分为截止复合事件、历史复合事件和否定复合事件三类。指定时间间隔内只要monitoredEvent发生，截止复合事件就被监测到；反之，若monitoredEvent没有发生，则否定复合事件被监测到。而只有当monitoredEvent发生指定次数时，历史复合事件才会被监测到。

三者均需要统计monitoredEvent的发生次数，用统一的成员变量monitoredEventCount来保存该值。特别地，历史复合事件中还需用targetValue来保存指定的monitoredEvent发生次数。

根据上述分析，可以设计出三元复合事件的监测算法如下：

Input:TernaryEvent

Outpu: 无

IFleftStatus

activateIn(monitoredEvent)

activateIn(rightEvent)

ENDIF

IFrightStatus

SWITCHeventType

CASEclosure

IFmonitoredEventCount> 0

当前复合事件被监测到

invoke(activateComEvents)

ENDIF

CASEhistory

CASEnot

IFmonitoredEventCount==targetValue

当前复合事件被监测到

invoke(activateComEvents)

ENDIF

//重置子事件状态，等待下一次发生

leftStatus=false

monitoredEventCount= 0

rightStatus=false

deactivateIn(monitoredEvent)

deactivateIn(rightEvent)

ENDIF

5　实　验

目前的主流研究方向集中在有限状态自动机和Petri网上，因此，为了测试AET在复合事件监测方面的性能，本文使用INMDB与SAMOS(采用Petri网)和ODE(采用状态机)进行比较。测试指标为处理相同复合事件定义语句所需要的时间。本文中用到的测试环境为Intel(R)Xeon(R)CPUE5-2407v2 @2.40GHz，memory3GB，RedHatEnterpriseLinuxServerrelease6.4 (Santiago)。

5.1数据与实验设计

我们通过批量处理复合事件定义语句来计算其平均时间。因为复合事件的处理极为耗时，实验主要测试了百、千、万级别的复合事件定义语句的处理时间。该时间取5次处理的平均值。每次处理前，数据库中都只有必要的原子事件。

5.2实验结果

表1和图5分别记录了不同数据库处理相同数量的复合事件定义语句的总时间和平均时间。

表1　复合事件定义语句总处理时间　　　单位:s

图5　复合事件平均处理时间/ms

5.3结果分析

表1中的数据为多次实验的平均值，最大限度地排除了偶然误差。从数据来看，处理100条复合事件时，INMDB只需2.451s，而SAMOS则需要7.193s，ODE更是耗时达14.387s。类似的情况也出现在处理千、万级别数量的复合事件定义语句时。因此，可以认为，处理相同数量的复合事件定义语句，INMDB耗时比SAMOS和ODE更少。将复合事件定义语句总处理时间转换为平均处理时间，用图5中的柱状图表示，可以直观地看出三者之间的性能差异。

综上所述，实验结果表明，单位时间内，INMDB能处理的复合事件语句数量比SAMOS和ODE更多，充分体现了AET在复合事件监测方面的优越性。

6　结　语

本文综合分析对比了各种主流复合事件监测算法之后，选择了事件树作为基础，提出了AET的概念，并以此为模型在INMDB现有基础之上设计并实现了复合事件监测机制。经过实验对比，该模型在单位时间内处理复合事件的效率比主流的有限状态自动机和Petri网更为出色。

事件监测是主动规则中最重要的一部分，而复合事件监测更是重中之重。该部分的顺利完成为INMDB中整个主动机制的实现打下了坚实的基础。放眼未来，分布式是数据库发展的主流。目前的复合事件监测机制主要针对单机环境，因此，下一步的工作是在保持单机环境下事件处理优势的前提下，实现分布式环境下的复合事件监测。

[1]PatonNW,DíazO.Activedatabasesystems[J].ACMComputingSurveys(CSUR),1999,31(1):63-103.

[2] 郝忠孝.主动数据库系统理论基础[M].北京:科学出版社,2009.

[3] 蔡学镛.轻松理解复合事件处理[J].程序员,2010(6):112-113.

[4]GatziuS,DittrichKR.SAMOS:Anactiveobject-orienteddatabasesystem[J].IEEEDataEng.Bull.,1992,15(1-4):23-26.

[5]AlShaerE,AbdelWahabH,MalyK.Hifi:Anewmonitoringarchitecturefordistributedsystemsmanagement[C]//DistributedComputingSystems,1999.Proceedings.19thIEEEInternationalConferenceon.IEEE,1999:171-178.

[6]GehaniNH,JagadishHV.OdeasanActiveDatabase:ConstraintsandTriggers[C]//Proceedingsofthe17thInternationalConferenceonVeryLargeDataBases,Barcelona,Catalonia,Spain, 1991.SanFrancisco,California,USA:MorganKaufmann,1991:327-336.

[7]AgrawalJ,DiaoY,GyllstromD,etal.Efficientpatternmatchingovereventstreams[C]//Proceedingsofthe2008ACMSIGMODinternationalconferenceonManagementofdata.ACM,2008:147-160.

[8]GruberRE,KrishnamurthyB,PanagosE.ThearchitectureoftheREADYeventnotificationservice[C]//Proceedingsofthe19thInternationalConferenceonDistributedComputingSystems,Austin,TX,USA,1999.Washington,DC,USA:IEEE,1999:0108.

[9]MeiY,MaddenS.Zstream:acost-basedqueryprocessorforadaptivelydetectingcompositeevents[C]//Proceedingsofthe2009ACMSIGMODInternationalConferenceonManagementofdata.ACM,2009:193-206.

[10]ChakravarthyS,MishraD.Snoop:Anexpressiveeventspecificationlanguageforactivedatabases[J].Data&KnowledgeEngineering,1994,14(1):1-26.

[11]GeppertA,TombrosD.Event-baseddistributedworkflowexecutionwithEVE[C]//Middleware’98.SpringerLondon,1998:427-442.

[12]LiuM,HuJ.Informationnetworkingmodel[M]//ConceptualModeling-ER2009.SpringerBerlinHeidelberg,2009:131-144.

[13] 徐倩,胡婕,刘梦赤.复杂语义关系的描述与操作[J].计算机科学与探索,2014,8(12):1432-1441.

[14] 金铮,刘梦赤,胡婕.信息网数据库管理系统的查询优化[J].计算机科学与探索,2015,9(3):300-309.

DESIGNANDIMPLEMENTATIONOFCOMPOSITEEVENTSDETECTIONMECHANISMININMDB

HeHongdaLiuMengchi

(SchoolofComputer,WuhanUniversity,Wuhan430072,Hubei,China)

Formostactivedatabasesystem,it’sdifficulttodetectcompositeevent.ThepaperintroducesthecompositeeventdetectingmechanisminINMDBmanagementsystem,describesindetailtheideaofusingeventtreemodeltodetectcompositeevents,andprovidesspecificalgorithmicimplementationaswell.Accordingtotheanalysis,thisalgorithmisbetterthanfiniteautomatonandPetrinets,whicharemuchmorecommon,inbothrunningefficiencyandmemoryoccupation.

Informationnetworkmodel(INM)ActivedatabasesCompositeeventsdetectionEventtree

2015-07-20。贺宏达，硕士，主研领域：数据库技术。刘梦赤，教授。

TP

ADOI:10.3969/j.issn.1000-386x.2016.10.010