Encyclopedia of Database Systems

Living Edition
| Editors: Ling Liu, M. Tamer Özsu

Active Database Management System Architecture

  • Jonas MellinEmail author
  • Mikael Berndtsson
Living reference work entry
DOI: https://doi.org/10.1007/978-1-4899-7993-3_507-2

Synonyms

Definition

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.

Historical Background

Several architectures have been proposed: HiPAC [1, 2], REACH [3], ODE [4], SAMOS [5], SMILE [6], and DeeDS [1]. Each of these architectures emphasizes particular issues concerning the actual DBMS that they are based on as well as the type of support for active capabilities. Paton and Diaz [7] provide an excellent survey on this topic. Essentially, these architectures propose that the active capabilities of an ADBMS require the services specified in Table 1. It is assumed that queries to the database are encompassed in transactions, and hence transactions imply queries as well as database manipulation operations such as insertion, updates, and deletion of tuples.
Table 1

Services in active database management systems

Service

Responsibility

Event monitoring

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

Rule evaluation

The rule evaluation service is responsible for invoking condition evaluation of triggered ECA rules and submitting actions for execution to the scheduler

Scheduling service

The scheduling service is responsible for readying and ordering schedulable activities such as ECA rule actions, transactions, etc., for execution

The services in Table 1 interact as depicted in Fig. 1. Briefly, transactions are submitted to the scheduling service that updates the dispatch table read by the transaction processing service. When these transactions are processed by the transaction processing service, events are generated. These events are signaled to the event monitoring service that analyzes them. Events that are associated with rules (subscribed events) are signaled to the rule evaluation service that evaluates the conditions of triggered rules (i.e., rules associated with signaled events). The actions of the rules whose conditions are true are submitted for scheduling and are executed as dictated by the scheduling policy. These actions execute as part of some transaction according to the coupling mode and can, in turn, generate events. This is a general description of the service interaction, and it can be optimized by refining it for a specific purpose, for example, in immediate coupling mode no queues between the services are actually needed.
Fig 1

Service interaction view of architecture (Based on architecture by Paton and Diaz [7])

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 [2]. 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 [3]. 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 [3] that require the possibility to express constraints between transactions.

The nested transaction model [10] 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., [11]). 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 [8].

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 [1], COBEA [6], Hermes [12], and X2TS [13]. Further, it has been addressed in event-based systems for mobile networks by Mühl et al. [14]. 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 [15]).

Another issue that is significant in distributed active databases is the time and order of events. For example, in Snoop [16] 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.

Foundations

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 [3], 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 [1], 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 [1], 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).

Key Applications

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.

Researchers have aimed for various application domains such as:
  • Stock market

  • Inventory control

  • Bank applications

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.

Future Directions

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 [17] 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?

Intertransaction events and rules have been proposed by, for example, Buchmann et al. [3]. How should this be managed with respect to the isolation levels proposed by Gray and Reuter [8, Chap. 7]?

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.

Cross-References

Recommended Reading

  1. 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. 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. 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. 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. 5.
    Gatziu S. Events in an active object-oriented database system. PhD thesis, University of Zurich, Switzerland; 1994.Google Scholar
  6. 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
  7. 7.
    Paton N, Diaz O. Active database systems. ACM Comput Surv. 1999;31(1):63–103.CrossRefGoogle Scholar
  8. 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
  9. 9.
    Ullman JD. Principles of database systems. Rockville: Computer Science; 1982.zbMATHGoogle Scholar
  10. 10.
    Moss JEB. Nested transactions: an approach to reliable distributed computing. Cambridge: MIT; 1985.Google Scholar
  11. 11.
    Gray J, Reuter A. Transaction processing: concepts and techniques. Los Altos: Morgan Kaufmann; 1994.zbMATHGoogle Scholar
  12. 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. 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
  14. 14.
    Mühl G, Fiege L, Pietzuch PR. Distributed event-based systems. Berlin: Springer; 2006.zbMATHGoogle Scholar
  15. 15.
  16. 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. 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. 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. 19.
    Jaeger U. Event detection in active databases. PhD thesis, University of Berlin; 1997.Google Scholar
  20. 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

Copyright information

© Springer Science+Business Media LLC 2017

Authors and Affiliations

  1. 1.The Informatics Research Centre and School of InformaticsUniversity of SkövdeSkövdeSweden

Section editors and affiliations

  • M. Tamer Özsu
    • 1
  1. 1.Cheriton School of Computer ScienceUniversity of WaterlooWaterlooCanada