SnoopIB: Interval-based event specification and detection for active databases

Abstract

Detection-based semantics does not differentiate between event detection and event occurrence and has been used for detecting events in most of the active systems that support Event–Condition–Action rules. However, this is a limitation for many applications that require interval-based semantics. In this article, we formalize the detection of Snoop (an event specification language) event operators using interval-based semantics (termed SnoopIB) in various event consumption modes. We show how events are detected using event detection graphs, and present a few representative algorithms to detect SnoopIB operators and comment on their implementation in the context of Sentinel—an active object-oriented DBMS.

Introduction

There is consensus in the database community on the Event–Condition–Action (or ECA) rules as being one of the most general formats for expressing rules in an active database management system. As the event component was the least understood (conditions correspond to queries, and actions correspond to transactions) part of the ECA rule, there is a large body of work on languages for event specification. Snoop [17], [19] was developed as the event specification component of the ECA rule formalism used as a part of the Sentinel project [8], [15], [16], [18] on active object-oriented DBMS. Snoop supports expressive ECA rules that include coupling modes and parameter contexts (or event consumption modes).¹

An event was initially defined to be an instantaneous, atomic (happens completely or not at all) occurrence of interest and the time of occurrence of the last event in an event expression was used as the time of occurrence for the entire event expression. An event, which is an indicator of happening can be either primitive (e.g., depositing cash in a bank) or composite (e.g., depositing cash, followed by withdrawal of cash). Primitive events occur at a point in time (i.e., time of depositing). Composite events occur over an interval (i.e., the interval starts at the time cash is deposited and ends when cash is withdrawn). Thus, primitive events are detected at a point in time, whereas the composite events can be detected either at the end of the interval (i.e., detection-based semantics) or can be detected over the interval (i.e., occurrence/interval-based semantics).

In all event specification languages used in active DBMSs (ACOOD [10], [23], ADAM [21], [35], COMPOSE [28], [29], Event-based conditions [11], Reach [12], [13], [14], Samos [27], [26], and Snoop [17], [19]) even composite events are considered as “instantaneous”, although an event occurs over an “interval”. Because of this, all the proposed event specification languages detect a composite event at the end of an interval over which it occurs (i.e., detection-based semantics). When events are detected using the detection-based semantics, where event occurrence and event detection is not differentiated, it leads to incorrect detection of events (detailed in Section 1.1) [24], [25], when certain event operators, such as sequence, are composed more than once.

Interval-based semantics is needed to overcome the problems that are caused by the detection-based semantics. Below, we explain event detection with a detailed example using both detection-based and interval-based semantics, and highlight why the distinction between detection-based and interval-based semantics is critical.

We will first identify the conditions that are needed to detect an event. Primitive events are predefined in the system and are detected at the time of occurrence. Composite event detection on the other hand involves two steps: (i) checking the detection condition based on the operator semantics and (ii) determining the time of detection. These two steps are handled differently in detection-based semantics and interval-based semantics as explained below.

Consider an example, where a stock trading agent wants to take some action, when “Dow Jones Industrial (DJI) average increases by 5%, followed by a 5% price increase in Sun Microsystems stocks and a 2% price increase in IBM stocks”. Stock trading agent uses Snoop event operators to express this requirement.

“If (DJIA ; (Sun ∧ IBM)) then take the appropriate action.”

• DJIA, Sun, IBM are primitive events that correspond to DJI average increases by 5%, 5% price increase in Sun stocks, and 2% price increase in IBM stocks, respectively.²

• (Sun ∧ IBM) and (DJIA ; (Sun ∧ IBM)) are composite events, where “;” (Snoop “sequence” event operator) represents followed by condition and “∧” (Snoop “and” event operator) represents And condition.

  • “;” detects a sequence of two events whenever the first event happens before the second event. “∧” detects an “And” event whenever both the events happen. Semantics for these operators are different for detection-based semantics and interval-based semantics and are illustrated below.

Case 1: Assume that primitive events DJIA, Sun and IBM occur at 10.30 a.m., 10 a.m., and 11 a.m. respectively. Fig. 1 depicts events that are detected along with the time of occurrence and detection.

• Primitive events are detected at the time of occurrence. Thus, events DJIA, Sun and IBM are detected at 10.30 a.m., 10 a.m., and 11 a.m., respectively.

• Composite event (Sun ∧ IBM) detection involves two steps as previously mentioned.

  • “And” condition is satisfied as both the events have occurred.

  • Sun starts the composite event (Sun ∧ IBM) detection at 10.00 a.m. IBM terminates the composite event (Sun ∧ IBM) at 11 a.m. Since events are considered as “instantaneous” and are detected at end of the interval, composite event (Sun ∧ IBM) is detected at 11 a.m. (though it occurred over an interval from 10 a.m. to 11 a.m.).

• Composite event (DJIA ; (Sun ∧ IBM)) detection involves two steps and they are

  • “Followed by” condition is only satisfied when event DJIA happens before event (Sun ∧ IBM). In our example, this condition is satisfied, since event DJIA is detected at 10.30 a.m. (step 1) and event (Sun ∧ IBM) is detected at 11 a.m. (step 2b). Thus, event DJIA happens before the event (Sun ∧ IBM) (i.e., 10.30 a.m. < 11 a.m.).

  • Composite event (DJIA ; (Sun ∧ IBM)) is detected at 11 a.m. (even though it occurs over an interval from 10.30 a.m. to 11 a.m.).

Even though event Sun had occurred well before event DJIA (i.e., 10.00 a.m. < 10.30 a.m.), the composite event (DJIA ; (Sun ∧ IBM)) is detected, which is incorrect. This is because of the condition checking in step 3a fails to capture the correct semantics, since it does not consider the start of interval. From this, it is evident that detection-based semantics does not detect events in the correct way under certain pattern of event occurrences. The detection-based semantics typically used by all the aforementioned event specification languages used in active DBMSs does not differentiate between event occurrence and event detection and have similar problems.

Same examples are used to explain interval-based semantics in this section where both times (start and end) are considered. This brings out the need for intervals for real-world events and the re-examination of the instantaneous occurrence assumption.

Case 2: Let us assume that primitive events DJIA, Sun and IBM occur at 10.30 a.m., 10 a.m., and 11 a.m. respectively. Fig. 2 depicts events that are detected, along with the time of occurrence and detection.

• Primitive events are detected at the time of occurrence, thus events DJIA, Sun and IBM are detected at 10.30 a.m., 10 a.m., and 11 a.m. respectively.

• Composite event (Sun ∧ IBM) detection involves two steps as previously mentioned.

  • “And” condition is satisfied, since both the events have occurred.

  • With the interval-based semantics start time of an event is considered and it is detected over an interval. As explained in Case 1, event Sun starts and event IBM terminates the composite event (Sun ∧ IBM), but the composite event is detected over the interval [10 a.m., 11 a.m.].³

• Composite event (DJIA ; (Sun ∧ IBM)) detection involves two steps and they are:

  • “Followed by” condition is only satisfied when event DJIA happens before event (Sun ∧ IBM). In our example, this condition is not satisfied, since event DJIA is detected at 10.30 a.m. in step 1, and composite event (Sun ∧ IBM) is detected over the interval [10.00 a.m., 11 a.m.] in step 2b. Thus, event DJIA does not happen before the event (Sun ∧ IBM) (i.e., 10.30 a.m. ≮ 10 a.m.).

  • Composite event (DJIA ; (Sun ∧ IBM)) is not detected.

Both the Cases 1 and 2 detect composite event (DJIA ; (Sun ∧ IBM)) using the same set of primitive events. Case 1 uses detection-based semantics, and the composite event is detected, which is not correct as event Sun had occurred well before event DJIA. Case 2 detects events using interval-based semantics, where the composite event is correctly not detected. Thus, event detection using interval-based semantics is needed for detecting events correctly. The rest of the article elaborates on event operators using the interval-based semantics.

SnoopIB [1], [2], [3], [5] is an event specification language based on interval-based semantics. Active rules have been shown to provide active capability to object oriented databases, relational databases, and so on. Lately, they have been shown to support diverse application areas such as information security [4], XML processing [9], information filtering [22], Data stream processing [31], [30], semantic web [34], and sensor databases [38]. Interval-based semantics has far-reaching applications and has been utilized in XML processing [9], information filtering [22], and cooperative information system [37].

Need for interval-based semantics was established in the previous section using an example, where events are detected in the unrestricted context (i.e., none of the event occurrences are discarded after participating in event detection). The example only makes a case for the need for alternative semantics, and whether an application/domain can live with non-interval-based semantics is a design decision. It is clear that both detection/point-based and interval-based semantics are needed as one is not sufficient for all applications. Furthermore, since event consumption modes are used in most applications, the interval-based semantics needs to be extended to event consumption models as well. Events that are detected using event consumption modes are subsets of events detected using the unrestricted context.

Snoop supports four event consumption modes (i.e., Recent, Chronicle, Continuous, and Cumulative) and a number of event operators. In this article, due to space constraints, we present interval-based semantics for some of the Snoop event operators using Recent and Continuous context (refer [1], [2], [3], [5] for other operators and contexts). First, we formally define Snoop event operators in both the contexts using event histories (i.e., a log). Second, we show how Snoop event operators detect event occurring online (i.e., one event at a time) using event detection graphs in both the contexts, and comment on the implementation of event operators in Sentinel. Finally, we present a few representative event operator algorithms for event detection.

The rest of the article is organized as follows. Related work is explained in Section 2. Snoop operators and their semantics in the unrestricted context using interval-based semantics are explained in Section 3. SnoopIB operators are formalized in recent and continuous context in Sections 4 Interval-based event operator formalization in recent context, 5 Interval-based event operator formalization in continuous context, respectively. Section 6 provides an illustrative example of event detection using event graphs and event histories in interval-based semantics along with few sample algorithms. Section 7 shows that no other event combinations, other than the unrestricted event combinations, are generated when contexts are used, and show that events detected using histories and graphs are same. Conclusions and future work are provided in Section 8.