UNIVERSITY OF SKÖVDE Department of Computer Science
Management of Rules in Object-Oriented Databases
Mikael Berndtsson (
[email protected])
Technical Report HS-IDA-TR-94-001
In Proceedings of the Baltic Workshop on NATIONAL INFRASTRUCTURE DATABASES: - Problems, Methods and Experiences Vol. 1, pages 78-85, Vilnius, Lithuania 17-20 May, 1994
Management of Rules in Object-Oriented Databases Mikael Berndtsson University of Skövde, Sweden
[email protected] ABSTRACT This paper proposes a new approach to associating rules with events in object oriented database systems. In it we propose a new run time subscription mechanism, which associates rules with specific event definitions. This provide a basis for indexing rules by event definitions, which reduces rule checking to a minimum. The proposed subscription mechanism is general, in that it can be applied to both primitive events and composite events. Both rules and events are represented as first class objects. This architecture has been adopted in the ACOOD2 prototype on top of ONTOS™.
1 Introduction Traditional database systems are passive in their behaviour, which means that they only do things when you actually require them to do so. Most of the non-traditional applications, such as Shop Floor Control (SFC), Computer Integrated Manufacturing (CIM), or air traffic control, require automatic monitoring of the database state. The enumerated applications also require that the database system should be able to take immediate action as events, which signal changes to the database state, occur. Previous approaches to support automatic situation monitoring can broadly classified in two approaches; i) periodically poll the database, ii) embed or encode event detection and related action execution in the application code. The major disadvantage with first approach is that the queries must be run exactly when the event occurs. The frequency of polling can be increased in order to detect the event, but if the polling is too frequent, then the database is overloaded with queries that most of the time will fail. On the other hand if the frequency is too low, the event will be missed. The second approach has several drawbacks. Firstly, rules are embedded in application code, which means that modification of rules and events implies making changes in every method supporting the rule. Secondly, the programmer has to understand all the rules, so that interaction between rules can be handled properly. Neither of the two above approaches can efficiently support automatic situation monitoring. The need for reactive mechanisms in next generation database systems has been recognized in [12]. Reactive DBMS has been proposed as an approach to support applications that require automatic situation monitoring. Reactive1 database technology opens up a new paradigm within database research, where the database is not seen as a slave to an application but as a peer. That is, a reactive database system can react to events, both primitive and composite events, which might have 1. We adopt the use of the term reactive instead of the previously used term active, since the term reactive describes the semantics of such a database system better than the previous used term active[1].
1
occurred within the system or external to it. The cooperation between the DBMS and the application can then be viewed as a two way communication, where the DBMS can support and control the application's activities. Most proposals for introducing rules in database systems are based upon event-condition-action (ECA) rules, introduced by the HiPAC project [4]. The semantics of an ECA-rule are: when the event occurs, evaluate the condition, and if the condition is satisfied execute the action. Early research on reactive databases was largely within the context of relational database systems ([10], [13], [14]), where rules are treated as global constraints. More recently, there have been a number of proposals for introducing reactive behaviour, expressed by ECA rules, in the context of object-oriented database systems ([1], [3], [6], [7], [8], [11]). Several important design issues for introducing ECA-rules in object-oriented database systems have been identified in [1]. In section 2 of this paper, we focus on event and rule management for reactive objectoriented databases, highlighting the architecture of one such system, ACOOD2. In particular we introduce a subscription mechanism between rules and specific events, which reduces rule checking further than previous solutions such as centralized rule checking or rules indexed by classes ([1], [6]). The proposed subscription mechanism can easily be applied to both primitive and composite events, since rules are indexed by event object identifiers. Our approach clearly distinguishes between concepts such as event generators, event definitions and event occurrences. We adopt the ECA paradigm with both event and rule definitions represented as first class objects. Conclusions are presented in section 3. 2 Event and rule management 2.1 Event generators In object oriented database systems, all communication between different objects is made via methods. By sending a message to an object we invoke a method, which can raise an event. In theory, we can treat every method invocation as a triggering event, where each method can generate two types of events: i) before the execution of a method, and ii) after the execution of a method. Thus, it is important that the user can specify which methods will generate events, since every method invocation might potentially generate a primitive event. A method that is allowed to generate a primitive event is called an event generator (EG). The concept of event generators can be extended to capture any system that produces events which may need a special response. Thus, both a system clock and an application that produces events can be viewed as event generators. In this paper we will concentrate on methods as event generators. Object oriented database systems provide the user with mechanisms such as inheritance. This means that we cannot assume that a method name alone will identify a triggering event. Therefore, we must also know in which class the triggering event has occurred, since a method may have different meaning according to which class it was invoked in. Given the previous paragraphs, we follow the ADAM project [6] and define a triggering event in our reactive object oriented model as: Event=Class+Method. When a method has been invoked in ACOOD2 a primitive event is generated as follows: Generated primitive event = [EventOid + Oid + Parameters + Time] EventOid - event object identifier. (event type) Oid - object identity of the object that generated the event. Parameters - the parameters that were involved when the method was invoked. Time - the time when the event occurred. 2
There is no need to include information about whether the event was generated before or after the method execution, since this type of information is captured by the event definition. 2.2 Events We propose that the term event should be clearly separated into two terms: event definition and event occurrence. It is sometimes confusing when we just talk about events. Do we mean the definition of an event or do we mean the actual occurrence of an event? An event occurrence is a signal that indicates that a specific situation has occurred and certain actions may have to be performed due to the event occurrence. Furthermore, the task of an event definition is to specify the moment when rules might be triggered. Current approaches to representing event definitions can be broadly classified into: i) event definitions as expressions within class definitions (Ode [8]), ii) event definitions as rule attributes ([2], O2 [11]) and iii) event definitions as first class objects (Sentinel [1], SAMOS [7], ADAM [6]). In this paper we follow the approach of representing event definitions as first class objects. This approach has several advantages. Event definitions can have attributes and methods of their own, that describes their state and behaviour. This means that they are not dependent upon the existence of other objects, e.g. rules, in contrast to the two other approaches. They can easily be added, deleted and modified. Furthermore, we can use the parameters computed when the event is raised. Briefly, events can be decomposed into i) primitive events such as method events and temporal events and ii) composite events, where a composite event consists of a set of primitive events or composite events related by defined operators. Event Primitive event
Temporal event
Composite event
Method event
Fig. 1 Event hierarchy In this paper we will concentrate on method events since they require more special treatment than other event types. Method events in ACOOD2 are defined as follows: DEFINE EVENT ON
