Active Database Management System Architecture
The active database management system (ADBMS) architecture is the software organization of a DBMS with active capabilities. That is, the architecture defines support for active capabilities expressed in terms of services, significant components providing the services, as well as critical interaction among these services.
Services in active database management systems
The event monitoring service is responsible for collecting events, analyzing events, and disseminating results of the analysis (in terms of events) to subscribers, in particular, ECA rules
The rule evaluation service is responsible for invoking condition evaluation of triggered ECA rules and submitting actions for execution to the scheduler
The scheduling service is responsible for readying and ordering schedulable activities such as ECA rule actions, transactions, etc., for execution
In more detail, transactions are submitted to the scheduling service via a queue of schedulable activities; this queue of schedulable activities is processed, and a dispatch table of schedulable activities is updated. This scheduling service encompasses scheduling of transactions as well as ECA rule actions in addition to other necessary schedulable activities. It is desirable for the scheduling service to encompass all these types of schedulable activities, because they impact each other, since they compete for the same resources. The next step in the processing chain is the monitored transaction processing service, which includes the transaction management, lock management, and log management [8, Chap. 5], as well as a database query engine (cf. query processor [9, Chap. 1]), but not the scheduling service. Another way to view the transaction processing service is as a passive database management system without the transaction scheduling service. The transaction processing service is denoted “monitored,” since it generates events that are handled by the active capabilities. The monitored transaction processing service executes transactions and ECA rule actions according to the dispatch table. When transactions execute, event occurrences are signaled to the event monitoring service via a filtered event log. When event monitoring executes, it updates the filtered event log and submits subscribed events to the rule evaluation service. An example of event log filtering is that if a composite event occurrence is detected, then for optimization reasons (cf. dynamic programming) this event occurrence is stored in the filtered event log. Another example is that when events are no longer needed, then they are pruned; for example, when a transaction is aborted, then all event occurrences can be pruned unless intertransaction events are allowed (implying that dirty reads may occur). The rule evaluation service reads the queue of subscribed events, finds the triggered rules, and evaluates their conditions. These conditions may be queries, logical expressions, or arbitrary code depending on the active database system . The rule evaluation results in a set of actions that is submitted to the scheduling service for execution.
The general view of active capabilities (in Fig. 1) can be refined and implemented in different ways. As mentioned, it is possible to optimize an implementation by removing the queues between the services if only immediate coupling mode is considered; this results in less overhead but restricts the expressibility of ECA rules significantly. A service can be implemented via one or more servers. These servers can be replicated to different physical nodes for performance or dependability reasons (e.g., availability, reliability).
In active databases, a set of issues have a major impact on refinement and implementation of the general service-oriented view depicted in Fig. 1. These issues are (i) coupling modes; (ii) interaction with typical database management services such as transaction management, lock management, and recovery management (both precrash such as logging and checkpointing and postcrash such as the actually recovery) (cf., e.g., transaction processing by Gray and Reuter [8, Chap. 4]); (iii) when and how to invokeservices; and (iv) active capabilities in distributed active databases.
The coupling modes control how rule evaluation is invoked in response to events and how the ECA rule actions are submitted, scheduled, dispatched, and executed for rules whose conditions are true (see entry “Coupling modes” for more detailed description). There are different alternatives to interaction with a database system. One alternative is to place active database services on top of existing database management systems. However, this is problematic if the database management system is not extended with active capabilities . For example, the deferred coupling mode requires that when a transaction is requested to commit, then queued actions should be evaluated. This requires the transaction management to interact with the rule evaluation and scheduling services during commit processing (e.g., by using back hooks in the database management system). Further, to be useful, the detached coupling mode has a set of significant varieties  that require the possibility to express constraints between transactions.
The nested transaction model  is a sound basis for active capabilities. For example, deferred actions can be executed as subtransactions that can be committed or aborted independently of the parent transaction. Nested transactions still require that existing services are modified. Alternatively rule evaluation can be performed as subtransactions.
To achieve implicit events the database schema translation process needs to automatically instrument the monitored systems. An inferior solution is to extend an existing schema with instrumented entities, for example, each class in an object-oriented database can be inherited to an instrumented class. In this example, there is no way to enforce that the instrumented classes are actually used. The problem is to modify the database schema translation process, since this is typically an intrinsic part in commercial DBMSs.
Concerning issue (iii), the services must be allocated to existing resources and scheduled together with the transactions. Typically, the services are implemented as a set of server processes, and transactions are performed by transaction programs running as processes (cf., ). These processes are typically scheduled, dispatched, and executed as a response to the requests from outside the database management system or as a direct or indirect response to a time-out. Each service is either invoked when something is stored in the queue or table or explicitly invoked, for example, when the system clock is updated to reflect the new time. The issues concerning scheduling are paramount in any database management system for real-time system purposes .
Event monitoring can either be (i) implicitly invoked whenever an event occurs or it can be (ii) explicitly invoked. This is similar to coupling modes, but it is between the event sources (e.g., transaction processing service and application) and the event monitoring service rather than in between the services of the active capabilities. Case (i) is prevalent in most active database research, but it has a negative impact in terms of determinism of the result of event monitoring. For example, the problem addressed in the event specification and event detection entry concerning the unintuitive semantics of the disjunctive event operator is a result of implicit invocation. In distributed and real-time systems, explicit invocation is preferable in case (ii), since it provides the operating system with the control when something should be evaluated. Explicit invocation solves the problem of disjunction operator (see event specification and event detection entries), since the event expressions defining composite event types can be explicitly evaluated when all events have been delivered to event monitoring rather than implicitly evaluated whenever an event is delivered.
In explicit invocation of event monitoring, the different event contexts can be treated in different ways. For example, in recent event context, only the most recent result is of interest in implicit invocation. However, in terms of explicit invocation, all possible most recent event occurrences may be of interest, not only the last one. For example, it may be desirable to keep the most recent event occurrence per time slot rather than per terminating event.
Issue (iv) has been addressed in, for example, DeeDS , COBEA , Hermes , and X2TS . Further, it has been addressed in event-based systems for mobile networks by Mühl et al. . Essentially, it is necessary to perform event detection in a moving time window, where the end of the time window is the current time. All events that are older than the beginning of the time window can be removed and ignored. Further, the heterogeneity must be addressed, and there are XML-based solutions (e.g., Common Base Events ).
Another issue that is significant in distributed active databases is the time and order of events. For example, in Snoop  it is suggested to separate global and local event detection, because of the difference in the time granularity of the local view of time and the global (distributed) view of time.
For a particular application domain, common significant requirements and properties as well as prerequisites of available resources need to be considered to refine the general architecture. Depending on the requirements, properties, and prerequisites, different compromises are reached. One example is the use of composite event detection in active real-time databases. In REACH , composite event detection is disallowed for real-time transactions. The reason for this is that during composite event detection, contributing events are locked and this locking affects other transaction in a harmful way with respect to meeting deadlines. A different approach is proposed in DeeDS , where events are stored in the database and cached in a special filtered event log; during event composition, events are not locked thus enabling the use of composite event detection for transaction with critical deadlines. The cost is that isolation of transactions can be violated unless it is handled by the active capabilities.
Availability is an example of a property that significantly affects the software architecture. For example, availability is often considered significant in distributed systems, that is, even though physical nodes may fail, communications links may be down, or the other physical nodes may be overloaded; one should get, at least, some defined level of service from the system. An example of availability requirements is that emergency calls in phone switches should be prioritized over nonemergency calls, a fact that entails that existing phone call connections can be disconnected to let an emergency call through. Another example to improve availability is pursued in DeeDS , where eventual consistency is investigated as a mean to improve availability of data. The cost is that data can temporarily be inconsistent.
As addressed in the aforementioned examples, different settings affect the architecture. Essentially, there are two approaches that can be mixed: (i) refine or invent new method, tools, and techniques to solve a problem, and these method, tools, and techniques can stem from different but relevant research areas and (ii) refine the requirements or prerequisites to solve the problem (e.g., weaken the ACID properties of transactions).
The architecture of ADBMSs is of special interest to developers of database management systems and their applications. In particular, software engineering issues are of major interest. Researchers performing experiments can make use of this architecture to enable valid experiments, study effects of optimizations, etc.
Concerning real examples of applications, only simple things such as using rules for implementing alerters has been tested, for example, when an integrity constraint is violated. SQL Triggers implement simple ECA rules in immediate coupling mode between event monitoring and rule evaluation as well as between rule evaluation and action execution.
Essentially, any application domain in which there is an interest to move functionality from the applications to the database schema in order to reduce the interdependence between applications and databases is a key application.
There are no silver bullets in computer science or software engineering, and each refinement of the architecture (in Fig. 1) is a compromise providing or enabling certain features and properties. For example, by allowing only detached coupling mode, it is easier to achieve timeliness, an important property of real-time systems; however, the trade-off is that it is difficult to specify integrity rules in terms of ECA rules, since the integrity checks are performed in a different transaction. The consequence is that dirty transactions as well as compensating transactions that perform recovery from violated integrity rules must be allowed.
It is desirable to study architectures addressing how to meet specific requirement of the application area (e.g., accounting information in mobile ad hoc networks) and the specific environment in which the active database are used (e.g., distributed systems, real-time systems, mobile ad hoc networks, limited resource equipment). The major criteria for a successful architecture (e.g., by refining an existing architecture) are if anyone can gain something from using it. For example, Borr  reported that by refining their architecture by employing transaction processing, they improved productivity, reliability, as well as average throughput in their heterogenous distributed reliable applications.
An area that has received little attention in active database is optimization of processing. For example, how can queries to the database be optimized with condition evaluation if conditions are expressed as arbitrary queries? Another question is how to group actions to optimize performance? So far, the emphasis has been on expressibility as well as techniques on how to enable active support in different settings. Another area that has received little attention is recovery processing, both precrash and postcrash recovery. For example, how should recovery with respect to detached but dependent transactions be managed?
There are several other areas with which active database technology can be combined. Historical examples include real-time databases, temporal databases, main-memory databases, and geographical information systems. One area that has received little attention is how to enable reuse of database schemas.
- 1.Andler S, Hansson J, Eriksson J, Mellin J, Berndtsson M, Eftring B. DeeDS towards a distributed active and real-time database system. ACM SIGMOD Rec. 1996;25(1)Google Scholar
- 2.Eriksson J. Real-time and active databases: a survey. In: Proceedings 2nd international workshop on active, real-time, and temporal database systems. Milan; 1997. p. 1–23.Google Scholar
- 3.Buchmann AP, Zimmermann J, Blakeley JA, Wells DL. Building an integrated active OODBMS: requirements, architecture, and design decisions. In: Proceedings of 11th international conference on data engineering. Taipei; 1995. p. 117–28.Google Scholar
- 4.Lieuwen DF, Gehani N, Arlein R. The ODE active database: trigger semantics and implementation. In: Proceedings 12th international conference on data engineering. New Orleans; 1996. p. 412–20.Google Scholar
- 5.Gatziu S. Events in an active object-oriented database system. PhD thesis, University of Zurich, Switzerland; 1994.Google Scholar
- 6.Ma C, Bacon J. COBEA: A CORBA-based event architecture. In: Proceedings of 4th USENIX conference on object-oriented technologies and system. Santa Fe; 1998. p. 117–32.Google Scholar
- 8.Berndtsson M, Hansson J. Issues in active real-time databases. In: Proceedings of 1st international workshop on active and real-time database system. Skovde; 1995. p. 142–50.Google Scholar
- 10.Moss JEB. Nested transactions: an approach to reliable distributed computing. Cambridge: MIT; 1985.Google Scholar
- 12.Pietzuch P, Bacon JH. A distributed event-based middleware architecture. In: Proceedings of 22nd international conference on distributed computing systems workshop. Vienna; 2002. p. 611–8.Google Scholar
- 13.Chakravarthy S, Blaustein B, Buchmann AP, Carey M, Dayal U, Goldhirsch D, Hsu M, Jauhuri R, Ladin R, Livny M, McCarthy D, McKee R, Rosenthal A. HiPAC: a research project in active time-constrained database management. Technical report XAIT-89-02, Xerox Advanced Information Technology; 1989.Google Scholar
- 15.Common Base Events. Http://www.ibm.com/developerworks/library/specification/ws-cbe/
- 16.Dayal U, Blaustein B, Buchmann A, Chakravarthy S, Hsu M, Ladin R, McCarty D, Rosenthal A, Sarin S, Carey MJ, Livny M, Jauharu R. The HiPAC project: combining active databases and timing constraints. ACM SIGMOD Rec. 1988;17(1)Google Scholar
- 17.Borr AJ. Robustness to crash in a distributed database: a non shared-memory multi-processor approach. In: Proceedings of 10th international conference on very large data bases. Singapore; 1984. p. 445–53.Google Scholar
- 18.Chakravarthy S, Krishnaprasad V, Anwar E, Kim SK. Composite events for active database: semantics, contexts, and detection. In: Proceedings of 20th international conference on very large data bases. Santiago; 1994. p. 606–17.Google Scholar
- 19.Jaeger U. Event detection in active databases. PhD thesis, University of Berlin; 1997.Google Scholar
- 20.Liebig CM, Malva AB. Integrating notifications and transactions: concepts and X2TS prototype. In: Second international workshop on engineering distributed objects. Davis; 2000. p. 194–214.Google Scholar