Extending Trigger-by-Example Approachto Support Time Events

Kornelije Rabuzin, Mirko Malekovic and Alen LovrencicUniversity of Zagreb

Faculty of organization and informaticsPavlinska 2, 42000 Varazdin

Tel.: 042-390 800 Fax.: 042-213 413 E-mail: kornelije.rabuzingfoi.hr

Abstract-An interesting type of objects in the SQL standard anddatabase systems are triggers which are nowadays being widelyused. The capability of automatic reaction to certain events is ofgreat importance. Although the idea of triggers seems verypromising, their complexity and variety of differentprogramming languages used for their implementation hindertheir wider use. To write more complex triggers becomes adifficult task and new methods for easier implementation arerequired. An interesting approach to resolve this flaw wasalready presented, so called Trigger-By-Example approach; inthis paper we extend this idea in a way that triggers based upontime events are supported too i.e. that triggers based on timeevents can be built automatically in a specified databasemanagement system. The paper will explain the idea and showhow this was done in PostgreSQL database management system.

I. INTRODUCTION

When the SQL (Structured Query Language) wasintroduced, the idea was that end-users should also be able touse it and write queries efficiently. During the years the size ofthe standard kept growing (the last version of the standard hasapprox. 5000 pages), and it turned out to be difficult even forprofessionals to use some available, but advanced possibilities.We can say that triggers are one ofthem.

Although, conceptually speaking, the idea of ECA (EventCondition Action) rules is quite easy to understand, problemsmay arise if one has to write triggers in some particularsystem. ECA rules are mostly implemented using triggers.Different kinds of events supported as well as different kindsof languages which can be used for trigger specification makeit difficult to write triggers efficiently even for professionals,and cause huge problems for end users.

For an example, in PostgreSQL which tends to be theworld's best open source object-relational database system,one can use several programming languages to specify triggeractions including C, Perl, plpgsql, and so on. Active databasesare not used (any more) just for constraints checking, but formany different tasks as well [11, 14]. This overcomes thebasic set of SQL statements which were supposed to beexecuted as a reaction to some events in the beginning. Inorder to write triggers successfully, one has to be familiar withthese languages. Some other systems offer other options andlanguages, and one has to study triggers for some time in orderto use them efficiently.One has to take into account that there is an obvious gap

between the theory and the practice, and that practicalsolutions do not keep the pace with the theoreticalachievements. Namely, active database theory has developedsignificantly, and it is becoming more then just simpletriggers. On the other side, the SQL standard is huge as well.That is why database management systems don't support all

1-4244-1148-3/07/$25.00 2007 IEEE.

possibilities defined in the standard (mostly), while othersystems possess some possibilities not defined in the standard.

Further on, the question of correctness of the designedtriggers is also very important; it has often happened thatdesigned triggers didn't behave as expected and that fact led tocertain problems. There is a possibility that triggers areinconsistent and redundant, so static analysis is also veryimportant.

Authors in [5] have also recognized the problem (writingtriggers efficiently in various database management systems)and have tried to find a solution. Hence, it is hard to build asolution that is general and applicable for all databasemanagement systems because they all differ. As the solutionof already mentioned problem an idea of QBE (Query ByExample) was used in [5]. Although the SQL is very much inuse, some other languages can be used as well in order to workwith databases. QBE is one of them; it is based on relationalcalculus and by using QBE one can design queries (more orless) graphically by using presented table structure, predefinedsymbols and variables. One can find many examples of QBE;even Microsoft Access supports an interface for buildingqueries by using forms in a similar way like QBE. QBE is adeclarative language, and therefore more intuitive for buildingqueries, especially for end-users. Queries are being built byfilling in given table structure with certain (predefined)symbols. P. denotes that this column should be printed, and"_" denotes a variable. If two columns contained the samevariable, then their values should correspond(columnl=column2 in the SQL). A working example of QBEused in [5] is presented in Table 1.

Based upon the QBE idea, the authors came to the idea ofwriting triggers in very much the same way. Instead of writingrequired triggers manually, a new graphical interface forwriting triggers was developed and the approach was given aname Trigger-By-Example (TBE). The whole procedure iswell described in [5] and some examples were given; the paperis very well written and structured and contains a lot ofexamples.

TABLE IQuery By Example [5]

P

.Ii

313

1---1

dept Dno Dname. MgrNoA 'I I

-

I I e I

INES 2007 - 11th International Conference on Intelligent Engineering Systems - 29 June - 1 July 2007 - Budapest, Hungary

The SQL query definition would look like this ([5]):SELECT E2.EnameFROM emp El, emp E2, dept DWHERE El.Ename = _Tomn AND El.ELno = D.MgrNoAND E2.DeptNo = D.Dno

In order to show that triggers are complex, the CREATETRIGGER statement defined in the SQL 2003 standard isgiven:

<trigger definition>CREATE TRIGGER <trigger name> <trigger

action time> <trigger event> ON <table name>[ REFERENCING <transition table or variablelist> ]<triggered action>

<trigger action time> ::=BEFOREI AFTER

<trigger event> ::=INSERT DELETE UPDATEOF <trigger column list> I

<trigger column list> ::= <column name list>

<triggered action> ::=FOR EACH { ROW STATEMENT } ]WHEN <left paren> <search condition>

<right paren> I <triggered SQL statement>

<triggered SQL statement> ::=<SQL procedure statement> IBEGIN ATOMIC

<SQL procedure statement> <semicolon> }... END<transition table or variable list>

<transition table or variable>...<transition table or variable>OLD [ ROW ] [ AS I <old transition variable

name>NEW [ ROW ] [ AS ] <new transition

variable name>OLD TABLE [ AS ] <old transition table

name>NEW TABLE [ AS ] <new transition table

name><old transition table name> <transition

table name><new transition table name> <transition

table name><transition table name> ::= <identifier>

We are not going to explain the syntax in a detail, but justpoint out some most important parts. As one can see in theCREATE TRIGGER statement, supported events (triggerevents) are just three basic operations that are part of the datamanipulation language: INSERT, UPDATE or DELETE. Aswe have already said, active database theory has beendeveloping during the years, and it turned out that new typesof events were also needed and some even implemented. So,different kinds of events were introduced during the years,including time events, method events, transaction events, andabstract events [11, 14]. Namely, it has been shown (and onecan find many examples) that different types of events shouldbe supported as well, and not just the basic manipulationstatements.

Since TBE supports only basic database operations (Insert,Update and Delete) as events, we have decided to try to extendthe approach and enable automatic creation of triggers basedon time events. For that purpose we have used PostgreSQLdatabase management system that doesn't support time eventsat all. So, what we had to do was to find a way to implementtime events, and then to build an interface for writing triggersbased upon time events.We were also working on a project that dealt with hospital

logistic and a multiagent system was used in order to resolvesome of the problems. The problem and the project werealready presented and described in [8]. One of the problemsthat occurred within the project was the problem of how tocontrol the set of autonomous agents; it is always a problemwhen a multiagent system is used [13]. Since PostgreSQL wasused, the idea was to implement a control mechanism by usingtime triggers. Since PostgreSQL didn't support the concept oftime triggers, and based upon already presented TBEapproach, we decided to extend TBE approach to support timetriggers as well (for PostgreSQL), and in that way to build acontrol mechanism and ensure control behavior in amultiagent system.

The rest of the paper is organized as follows: the nextchapter is devoted to active databases, then the basic types ofevents are being discussed, and finally the solution ispresented. The conclusion summarizes the paper.

II. ACTIVE DATABASE MANAGEMENT SYSTEMS

ADBMS is a conventional database system capable ofreacting to some events of interest, which can occur within thedatabase or outside it. The basic concept on which an ADBMSrelies - the concept of (already mentioned) ECA, or activerules - needs to be considered. According to it, when certainevents occur (ON EVENT), and some conditions are fulfilled(IF CONDITION), some actions are performed automatically(THEN ACTION). These actions are performed without anyneed for the user's intervention. An event can be defined as astate change of interest that requires intervention. From thepoint of view of ADBMSs these events of interest can bedivided into two categories: simple and complex events. Moreon different kinds of events can be found in [2, 4, 7, 1 1 ].The active rule is triggered when the event specified in the

event part of that rule occurs. The triggered rule does not haveto be executed; this depends on condition evaluation (Fig. 1).

Each ADBMS possesses a language used for triggerspecification (definition), and has an execution model thatdetermines how the rules are going to be executed.

There are several arguments justifying the use ofADBMSs.First of all, it is cheaper to build an application which usestriggers and its performances are better, at least when a smallnumber of triggers is involved [ 11]. Secondly, such anapplication is smaller and easier to maintain [14]. Thirdly,triggers are declarative technology (at least conceptuallyspeaking) and, according to [3], the trend has clearly alwaysbeen away from procedural toward declarative - that is, fromhow to what.

314

K Rabuzin, M. Malekovic, A. Lovren6ic v Extending Trigger-by-Example Approach to Support Time Events

EVENT TRG' E EVAENTD SELECTERDSIGNALING OCURRENCES TRIGGEIN RULES IAUTO UE SHDLN UE XCTO

Fig. 1: Rule execution [16]

Some questions regarding different execution models, staticanalysis, performance measurement, etc. are addressed in [ 1],and for more information we refer to [1, 6, 10, 14, 15].

Active databases were used in many different fields [12,14], and due to already mentioned merits we have alreadyinvestigated how to implement different kinds of businessrules in active databases [11], how to use them in multiagentsystems [8], and how to implements multimodal biometricsystems using triggers as well [9].

III. SUPPORTED TYPES OF EVENTS

As we have already said, the SQL standard defines onlythree types of events that can be used in trigger specification:INSERT, UPDATE, and DELETE. But for solving realproblems many different types of events were introduced aswell [1, 7, 12, 14]. Accordingly, several types of simple eventscan be distinguished in active database theory:

- Database operations: INSERT, UPDATE, and/orDELETE,

- Time events:a) absolute - certain point oftime,b) periodic - every day, month, etc., andc) relative- for example, 30 minutes after somethingelse has happened,

- Method events: method invocation,- Transaction events: for example BEGIN or COMMIT,

and- Abstract events: some user defined events.Complex events can be built by using several simple events,

or by using several existing constructs (i.e. negation, sequence,repeat, etc.).

Since TBE approach allows defining triggers only on basicdatabase operations, and many problem-solving applicationsrequire other types of events (which were introduced duringthe years), we have decided to extend TBE approach in orderto support time events as well.As an example, this could be very important for a class of

so called notification applications that only notify whethersomething has happened or not. In our example we had tobuild a control mechanism that could be used in a multiagentsystem to control agents by sending messages. Of course,many other fields and problems could also benefit as well.

IV. EXTENDING THE SET OF SUPPORTED EVENTS

There are two basic approaches of how to extend a databasemanagement system: layered or integrated. The third one was

already abandoned (application approach). Layered approachsubsumes that you add a new layer (that performs something),while integrated approach allows you to make changes to thesource code in order to implement new functionality. We havechosen the first mentioned approach.

People who have been working with Unix systems haveheard of the CRON; it is a daemon functioning pretty muchthe same as Windows scheduler. So our idea was to use theCRON system in order to implement time triggers (somehow),because it can ensure that some actions are executed in acertain point of time.

So what we have done is a Perl script (function) and triggerwhich adds actions to be executed in a certain point of time toa file which is read by the CRON system, and we have built aninterface which enables that time event as well as conditionsare defined based on the table structure (the idea of QBE). Inthat way it is possible to determine time events (absolute andperiodic) and specify important conditions. Although the ideawas to support different kinds of actions, that turned out to bea difficult task, especially for a general solution that could beused with different systems that are not in accordance with theSQL standard. So, we have restricted our solution and actionsare for now limited (sending email), but that was enough forsending control messages to agents and ensure control in thesystem. The problem of control in multiagent system is stillsignificant, and new solutions are required.A part of the script that was built is presented; each time a

new time trigger should be created, date and time parametersare added to a file which is read by the CRON system. Whenthat time comes, a PUP script is started that checks whetherconstraints are satisfied, and then sends emails if necessary. Inthat way all data (important date/time parameters) are writtenin just one place (file), and can be managed easily.

CREATE OR REPLACE FUNCTION perlnstate() RETURNStrigger AS $$# date parameters$year = substr($ TD_>{new}{date},0,4);$month = substr($ TD->{new}{date},5,2);$day = substr($ TD->{new}{date},8,2);$hour = substr($ TD->{new}{time},0,2);$minute = substr($_TD->{new}{time},3,2);

$initial ="*";$typ = $_TD->{new}{typ};if ($typ>l) { $initial="0-6';

# open filefileopen(FH," >>/home/stuff/krabuzin/perl/trigger");print FH "$minute $hour $day $month$initial lynx -dumphttp://arka.foi.hr/krabuzin/emika/mail_notification.php \n";

close FH;system ('crontab/home/stuff/krabuzin/perl/trigger'); return;$$ LANGUAGE plperlu;

The picture below demonstrates the interface that wasdeveloped (Fig. 2). One has to enter the trigger name, as wellas time and date when the trigger should be fired. For now onecan choose between absolute (one point in time) and periodictime events (every day).

315

INES 2007 - 11th International Conference on Intelligent Engineering Systems - 29 June - 1 July 2007 - Budapest, Hungary

Fig 2: Extended TBE - supported time events

Below that one can see the table structure; one can entereither id or name of some item, and specify the condition thathas to be checked. If a periodic event was specified, it wouldbe checked daily whether the constraint is satisfied or not, andappropriate message would be sent. In the case of absoluteevent, a specified constraint would be checked in a point oftime.

It is important to notice that PostgreSQL didn't support timeevents at all. So we had to implement time triggers first, andthen build an interface which enables that triggers based ontime events are specified using. For that purpose we have usedlayered approach and built a module that takes care when anew constraint is added; this module automatically opens a filewhich is used by the CRON system and adds a new line thatwill ensure that trigger is triggered. This file contains timeswhen certain constraint should be checked, and starts a PUPscript that will check the specified constraints.The solution was built to control agents in multiagent

system as well, and the form presented was added later inorder to make solution more general in a sense. Namely, theterm silent-commerce denotes that agents are operating andgraphical interface was not required. But in order to satisfyTBE, it was added.

V. CONCLUSION

The idea of how to extend the set of supported events inorder to build triggers automatically is very promising anduseful (for example to notify whether something has (not)happened within the database). An interface used to specifytriggers based upon time events has been built. One couldargue that for now the solution is limited in a way that actions

are restricted (sending email messages). The former is not aproblem for now because we have used this solutionexclusively for notification purposes, but it would be good toenable that other actions could be specified and used intriggers as well. This would make the idea more general in asense, but is also a more complicated task to achieve.What is the hardest part is to make a solution that makes it

possible to build time triggers independently on the databasesystem being used. Namely, the database management systemsdon't possess same characteristics and it is not so easy to makethe solution general in a sense. What is hard to achieve is toimplement and support different kinds of actions as reactionsto recognized events.Of course, the research will be extended and results

presented are just the beginning, but we will pursue the ideaand present results in future papers.

REFERENCES

[1] A. Dinn, N. W. Paton, M. H. Williams: Active rule analysis andoptimisation in the rock & roll deductive object-oriented database,Information Systems, vol. 24, no. 4, p. 327-353, 1999.

[2] A. Koschel, P. C. Lockemann: Distributed events in active databasesystems: Letting the genie out of the bottle, Data & KnowledgeEngineering, vol. 25, no. 1-2, p. 11-28, 1998.

[3] C. J. Date: What not how - the business rules approach to applicationdevelopment, Addison Wesley, 2000.

[4] C. W. Tan, A. Goh: Composite event support in an active database,Computers & Industrial Engineering, vol. 37, no. 4, p. 731-744, 1999.

[5] D. Lee, W. Mao, H. Chiu, H., W. W. Chu: Designing Triggers withTrigger-By-Example, Knowledge and Information Systems, vol. 7, no.1, p. 110 - 134, 2005.

[6] I. Vlahavas, N. Bassiliades: Parallel, Object-Oriented, and ActiveKnowledge Base Systems, Kluwer Academic Publisher, London, 1998.

[7] K. R. Dittrich, H. Fritschi, S. Gatziu, A. Geppert, A. Vaduva: SAMOS inhind sight: experiences in building an active object-oriented DBMS,Information Systems, vol. 28, no 5, p. 369-392, 2003.

[8] K. Rabuzin, M. Malekovic, M. Baca: A Combination of Reactive andDeliberative agents in Hospital Logistics, The Proceedings of 17thInternational Conference on Information and Intelligent Systems,Varazdin, Croatia, p. 63-70, 2006.

[9] K. Rabuzin, M. Malekovic, M. Baca: A Multimodal Biometric SystemBased upon the Active Database Paradigm, Journal of Management,Informatics and Human Resources, vol. 39, no. 7, Kranj, Slovenia, p.425-43 1, 2006.

[10] K. Rabuzin, M. Malekovic, M. Baca: Active databases, business rulesand reactive agents - What is the connection?, Journal of Informationand Organizatinal Sciences - JIOS, vol. 29, no. 1, Varazdin, Croatia, p.63-73, 2005.

[11] K. Rabuzin, M. Malekovic: Implementing Business Rules in ActiveDatabases, Proceedings of 15th International Conference on Informationand Intelligent Systems (IIS), Varazdin, 2004.

[12] K. Rabuzin: Aktivne baze podataka: implementacija poslovnih pravila uPostgreSQL-u, Magistarski rad, Fakultet organizacije i informatike,Varazdin, 2004. (in Croatian)

[13] M. Wooldridge, N. R. Jennings: Agent Technology Foundations,Applications, and Markets, Springer, Berlin, 2002.

[14] N. W. Paton: Active rules in database systems, Springer, New York,1998.

[15] S. F. Andler, J. Hansson: Active, real time, and temporal databasesystems, Springer, Berlin, 1998.

[16] X. Li, J. M. Marn, S. V. Chapa: A structural model of ECA rules inactive database, C.A. Coello et al. (Eds.): MICAI 2002, LNAI 2313,Springer-Verlag Berlin, p. 486-493, 2002.

316