Time Issues in Active Database Systems

Transcription

1 accepted for Intl. Workshop on an Infrastructure for Temporal Databases, Arlington, Texas, June 93 Time Issues in Active Database Systems Klaus R. Dittrich, Stella Gatziu Institut für Informatik, Universität Zürich Winterthurerstrasse 190, CH-8057 Zürich, Switzerland {dittrich Abstract Active mechanisms based on event-condition-action rules will play an important role in next-generation database management systems. As an event, in its most general form, is essentially a point in time, it is obvious that an appropriate concept of time is needed for the specification of events. However, there are also other aspects related to time that need to be considered in active database systems, and which should tie in with the general concept of time in case the active database is also a temporal one. This position paper gives a brief account of where time issues arise in active database systems, and especially demonstrates various options for powerful event specification features. 1 Motivation and relationship to temporal databases Active mechanisms are generally considered to be one of the important features needed in next-generation database systems [Comm 90], and a lot of research is currently being conducted in this field [Chak 93]. While their origins date far back to simple trigger concepts as e.g. proposed during the development of System R [Eswa 76], they are recently treated with a much broader and more general scope which is mainly based on co-called event-conditionaction rules (ECA-rules; [Daya 88]). ECA-rules have the general form on if do <event> <condition> <action> and can be coarsely interpreted as when the specified <event> occurs and the <condition> holds, execute the <action>, where a <condition> is defined over the state of the database and its environment (e.g. the user running the transaction which causes the <event>), and an <action> may be an arbitrary program (which of course may also include database operations). A database system supporting ECA-rules is called an active database system (adbs), whatever other (e.g. object-oriented) features it may support, and thus whatever additional terminology may be used (e.g. active object-oriented or active relational DBS). Obviously, any more exact explanation of the ECA-rule semantics (which in view of a lack of standards may be different from system to system anyhow!) has to resort to time issues at some point (e.g. when is the condition checked once the event has occurred?). Most prominently, an event may be considered as just a point in time, but various (also elaborate) ways are needed to indicate which points in time are really of interest in the context of a set of ECA-rules. Given this scenario, we strongly suggest that an infrastructure for time in databases also comprises those elements that are needed in the context of active mechanisms. Obviously, to avoid a proliferation of individual concepts, time features for ECA-rules should be optimally integrated with those needed for temporal databases in general. To this end, we try to identify time issues found in adbs in chapter 2. In chapter 3, we deal in more detail with advanced event specification including explicit time definition. As this paper is mainly understood as a basis for discussion with the temporal database community, it is mostly restricted to the presentation of concepts; it purposely does not give much motivation for the introduction of individual features and also refrains from dwelling upon implementation issues. We also do not claim that any entirely new technical contribution is made; instead, previous findings of others and ourselves are put into context and are viewed from the perspective of working towards a 1

2 general infrastructure for time in databases. Most details are drawn from SAMOS, an active objectoriented DBMS currently researched and prototyped in our group ([GaDi 93]). However, though some of our means for event specification seem to be pretty novel, similar time requirements might be gained from other adbs (e.g. some of those represented in [Chak 93]) as well. 2 An overview of time issues in active database systems In the sequel, we present an enumeration and short discussion of issues where time is involved in adbs. While some of the aspects mentioned would be similar in other kinds of systems, most of them are specific for active mechanisms. (a) (b) (c) event specification An event is a point in time, and thus the specification of events will by necessity involve the (explicit or implicit) specification of time. As this may get rather elaborate in order to reach a high degree of functionality for an adbs, we will address event specification in more detail in chapter 3. condition specification The <condition> in an ECA-rule is a predicate that has to hold for the database; it may also refer to environment parameters like the user running the event-triggering transaction. For the sake of simplicity, we assume that system-owned specific database entities (relations, objects) exist which hold all current environment data and can be tested (i.e. queried) in the same way as all user-provided database entities. If a temporal database is used together with the active mechanisms, the <condition> can obviously also refer to time data. The concepts that apply in this respect are those of the underlying temporal data model. condition evaluation and action execution (d) Once the occurrence of an event has been detected, the associated <condition> needs to be checked. This can be done ([Ston 92]) immediately after the detection (i.e. before anything else is done on behalf of the event-triggering transaction), or later, e.g. at the end of the execution of the database operation that raised the command (in cases where such operations are used for event specifications; see chapter 3), at the end of the event-triggering transaction (i.e. right before commit processing), or after the end of this transaction. The latter case assumes that the condition evaluation takes place in a separate transaction, which is a general option that might also be desired for the other cases (in contrast to condition evaluation in the same transaction). With a separate transaction, it is obvious that the checking time determination has to be interpreted as at earliest when..., because the condition checking transaction will be independently scheduled by the transaction manager which may introduce delays (see also (e) below). Note that the time of the condition evaluation may have a considerable influence on its outcome as the database may have changed between the occurrence of the event and the (deferred) checking. Similar arguments apply for the <action> execution in case the <condition> holds; it may again take place immediately or deferred, within the same or in a separate transaction. rule activation and supervision An ECA-rule may be needed temporarily only. As it would be inconvenient to remove and later redefine such a rule, an adbs may provide operations for the activation and deactivation of rules. During the time interval where a rule is dormant (not activated), the occurrence of its event is not monitored and thus no reaction may happen. The activation interval is implicitly defined by the times the activate and deactivate operations have been recognized by the system. The definition of a new rule may either be regarded as implying an activate operation, or the newly defined rule may initially be dormant until explicit activation takes place. Obviously, the deletion of an existing rule will automatically terminate its activation, with immediate effect. Further, it may be desired that the activation/deactivation of a rule can be preplanned. In this case, it would again be inconvenient if the application or some administrator were required to explicitly issue appropriate activate/deactivate operations 2

3 (e) (f) when needed. Rather, the time intervals for activation can be explicitly specified beforehand (together with the rule definition itself or in a separate step; of course, the definition of this supervision time intervals should also be changeable). The ways for the explicit specification of supervision time intervals are those that also apply for other kinds of intervals and are detailed in chapter 3 below. rule system responsiveness An ECA-rule should be executed (i.e. its condition should be checked etc.) whenever the triggering event occurs (deferred condition checking as discussed above not withstanding). The question arises, however, when an event is really detected in the system. Due to the processing of other tasks, this may be noticeably after the (explicitly or implicitly) defined time for that event. Similar arguments hold for the definition, deletion, activation and deactivation of rules etc. which may be effective only noticeably after the time actually assumed. Thus the question of time granularity has to be dealt with (what is the smallest unit of time ECArules should use for specifying time seconds or better minutes?) which crosses the bridge to realtime databases ([Rama 93]) where, among others, the predictability of processing times and time delays is an important issue. CA-rules ECA-rules may also be specified with the omission of either the <event>- or the <condition>-part. While a missing <condition> is simply regarded as if it would always evaluate to true, an unspecified <event>-part needs more elaborate consideration. Intuitively, the action of a CA-rule has to be executed at the time (which can then be implicitly taken as the event missing to have a complete rule) when the <condition> becomes true. While this case will need additional (and rather complicated!) mechanisms for detection, it also allows for at least three different semantics which are explained by the following example. Assume the CA-rule on if e1.salary > do <action> has been defined. This might be interpreted as an <action>-execution being required (1) whenever the salary of object e1 is higher than , (2) when e1 s salary gets higher than for the first time, (3) always when e1 s salary increases from or below to above. While the first case is not very likely to make sense in an adbs 1 (it would obviously lead to a kind of thrashing situation when the salary is and remains indeed above the threshold the <action> would then have to be repeated all the time until the condition becomes false; the only meaningful use is thus where the <action> decreases the salary), both other cases do. If (2) applies, the <action> will definitely take place only once; if (3) applies, multiple executions may happen depending on the dynamic evolution of the database (e1 s salary in this case). At any rate, additional syntax (e.g. keywords like first and always after on) will be needed to tell the system which case is desired. In conclusion, various aspects of time are relevant for active databases. Most of them, like the granularity of time units, the specification of intervals and the determination of specific times (compare to concepts like valid time, transaction time or event time with a slightly different notion of event ; cf. e.g. [KiCh 92]) also apply to temporal databases and are thus candidates for consolidation into a common infrastructure. 3 Time concepts in event specifications As mentioned before, an event in adbs is essentially a point in time, where time is perceived as a discrete sequence of time points. We can therefore say that an event happens every unit of time, where a unit will be e.g. one minute; other quantums may be used as the unit as well, but would be probably too coarse for many applications (e.g. one hour ), too small to be appropriately handled by reasonable systems (e.g. one second ), or too unhandy for practical use (e.g. 70 seconds ). We will therefore as- 1. The real-time database community might think differently about this situation! 3

4 sume the use of minutes and appropriate customary larger units (like hours, days, weeks, months, years) in the sequel. Now obviously not every event as defined above is of interest for ECA-rules. The next question is therefore, how do we specify the events of interest for an ECA-rule, i.e. those which have to be indicated in the <event>-part of such a rule 2. Three general observations apply in this respect: (1) Such specifications may be explicit (i.e. by indicating a clock time) or implicit (by indicating something that will happen, with the assumption that the time of this occurrence is the one we are interested in). (2) Such specifications can be made directly (the event of interest is immediately the one specified; we will talk about primitive events in this case) or indirectly (the event of interest results from a combination of other events; we will talk about composite events then, giving rise to an event algebra). (3) As will be seen, most event specifications will actually refer to not just one point in time, but will describe multiple events (i.e. various points in time will fulfill a specification). That means that we will principally specify event classes which may include one or more (or in some cases even 0) individual events. As confusion should not arise, we will nevertheless continue to simply speak about events. For further simplification, when we talk about an event in the sequel, we always mean an event of interest (which may still refer to the fact that it is of interest as such, or in contributing to the specification of other events). Let us now briefly explain a variety of ways to specify events in an adbs, where we purposely want to show how broad the spectrum is if we want to support also sophisticated applications from various areas. 2. We do not address the question here whether these events really need to be specified directly in an ECA-rule, or whether syntax permits to also specify them independently, assign a name to them and just indicate this name in the <event>-clause of rules. Probably the latter will be the favorite solution, but this is obviously syntactical sugar. We assume that the syntax we use for examples will be intuitive for the reader. Let us start with primitive events. What immediately comes to mind is an absolute time specification, for example , 16:15 which specifies a certain time at a given date. Exactly one such event exists. Obviously, various parts of a specification like this might be left out and replaced by defaults (e.g. we take 00 for the minutes if only hours are given, or we insert the date of the day when the specification is recorded if only hours and minutes are given). Absolute time specifications may also be made for multiple events by means of repeated absolute time specification. In this case, a repeating factor like 1, 2, 3,... and a repeating unit like years, months, weeks, days, hours, minutes has to be indicated, like in every 15 minutes every 2 days, 16:15 every month, 01, 08:00 every week, monday, 08:00 Obviously, some consistency rules between the time indication itself and the repetition information apply (the time has to make sense relative to the repeating unit). Moreover, such a repeated absolute time specification may include time intervals during which we are interested in events. The following example shows the two cases that apply here: every week [monday friday], 16:30 [ ] While the first interval indicates 5 individual events per week, the second one states that we are interested in these events during summertime (april through september) only, but not for the rest of the year. Intervals are regarded as being closed, and of course again certain consistency rules apply for such specifications to make sense. Next, let us look at some implicitly specified primitive events. Most popular, even in active mechanisms that are already marketed today, are so-called 4

5 DBMS-events. A DBMS-event (or database event) is the occurrence of a DBMS-operation like an insert-, update or select-operation in a relational system, or the execution of an object method in an object-oriented system, or the execution of a transaction. More precisely, as an event is a point in time and all such operations will last for a period of time, we have to indicate whether the event is the point in time immediately before the operation is executed (specified as before), or the point in time immediately after the completion of it (specified as after). Furthermore, we will also want to differentiate (by adding appropriate parameters in the specification) that we are e.g. interested in insert-operations affecting the employee-relation, but not in others. Obviously, the exact set of DBMS-events depends on the DBMS used and on its data model; in the case of objectoriented data models, it also depends on the classes (and their methods) that are currently defined. A final kind of primitive events are abstract events. From the point of view of the adbs, those are placeholders only where the system knows nothing else than their name (which has to be declared beforehand). Abstract events are useful to indicate events taking place in applications, but for which it still makes sense that the adbs can use them in ECA-rules. Their occurrence needs to be explicitly signalled from the application by means of a special operation like raise <event_name>. DBMS-events as well as abstract events (and most of the events described below) may also be specified with a time interval to restrict their applicability. Let us now turn to composite events. They are used to specify points in time that are defined on the basis of other points in time. We will thus end up with an event algebra where the appropriate operators may be applied to primitive events and other composite events. The simplest case here is relative time specification where the event is defined in the form <event> + <time unit> or <event> - <time unit>, for example raise E5 + 1 hour. For a subtraction to make sense, we obviously need an explicitly specified <event> as otherwise we would not know ahead the first operand and thus could not calculate the resulting event until after it has already passed. Next, we have event disjunction, conjunction and sequence. The event disjunction <event1> <event2> defines the event that occurs whenever either <event1> or <event2> takes place. Accordingly, the conjunction <event1>, <event2> occurs when both participating events have happened, in whatever sequence (i.e. the composite event is the same point in time as the one that happens second). In contrast, the sequence <event1> ; <event2> of two events requires that the participating events occur in that sequence. As a consequence, <event1>, <event2> = (<event1> ; <event2>) (<event2> ; <event1>) holds. Furthermore, one may also be interested in the fact that some event has not happened, which however (as once more we have to recall that any event is a point in time) makes only sense if the non-occurrence is specified relative to a time interval. We call this specified as negative events, not <event> [<time interval>]; the negative event is the end point of the indicated time interval if the <event> has not happened during the interval. Finally, there are also two more complex composite events that have proven useful. They both refer to specific 5

6 treatments of singular events based on repeated events. The *-operator, specified as * <event> [<time interval>], produces the point in time where <event> occurs for the first time within the given interval, with the additional property that further occurrences of <event> within that interval are not considered any more. If no interval is given at all, <event> is signalled at most once during the lifetime of the respective ECA-rule. The times-operator, which is specified as times (n, <event>) [<time interval>] or, as a second case, as times (n1, n2, <event>) [<time interval>] is the point in time where <event> has occurred exactly n times during the given interval, or the end point of the interval when <event> has occurred between n1 and n2 times during the interval. In this chapter, we have sketched a variety of ways to specify events in ECA-rules. We do not claim that this is a complete set, and we have not covered all details. For example, we did not elaborate that of course time intervals as needed for several operators may also be subject to specific composition operators like intersection, union, and the like. Finally, we would like to mention that in case the underlying data model is a temporal one, there is once again an interesting combination effect as times or time intervals as needed for the specification of events may be drawn out of the database. As an intuitive example, take the event (select start_date from vacation_plan where emp = Smith ) - 2 days which happens two days before the vacation of a given employee starts (probably at 00:00 hours on that day, depending on default rules). Obviously, one would expect that changes of the temporal data in the database would automatically trigger changes for the affected events 3. 4 Conclusions In this position paper, we have tried to make the point that mechanisms in active database systems entail a number of time issues, some of which are similar to those discussed for temporal databases in general. We therefore strongly suggest that time needs in adbs are considered in a general infrastructure for temporal databases right from the beginning. We feel that a lot of interesting commonalities in both areas could be exploited and lead to considerable cross-fertilization in that events can be recorded in the database proper, and on the other hand temporal database data may contribute to event specifications. References [Chak 93] [Comm 90] [Daya 88] [Eswa 76] [GaDi 93] [KiCh 92] [Rama 93] [Ston 92] Chakravarthy, S. (ed.): IEEE Quarterly Bulletin on Data Engineering, Special Issue on Active Database Research, January 1993 The Committee for Advanced DBMS Functionality: Third-generation database system manifesto. ACM SIGMOD Record 19(1990)3 Dayal, U. et al.: The HiPAC project: combining active databases and timing constraints. ACM SIGMOD Record 17(1988)1 Eswaran, K.P.: Specifications, implementations, and interactions of a trigger subsystem in an integrated data base system. IBM Research Report RJ1820 (August 1976) Gatziu, S; Dittrich, K.R.: SAMOS an active object-oriented database system. In: [Chak 93] Kim, S.-K.; Chakravarthy, S.: A retrospective analysis of time concepts in temporal databases. Technical Report, University of Florida, UF-CIS-TR , 1992 Ramamritham, K.: Real-time databases. Int. Journal of Distributed and Parallel Databases, 1(1993)2 Stonebraker, M: The integration of rule systems and database systems. IEEE Transactions on Knowledge and Data Engineering 4(1992)5 3. Obviously, here and in similar cases we mentioned before, the basic concepts of active mechanisms could themselves be used internally to effect these triggered changes. 6