Encyclopedia of Database Systems

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

Active Database Knowledge Model

  • Mikael BerndtssonEmail author
  • Jonas Mellin
Living reference work entry
DOI: https://doi.org/10.1007/978-1-4899-7993-3_508-2


The knowledge model of an active database describes what can be said about the ECA rules, that is, what types of events are supported, what types of conditions are supported, and what types of actions are supported?

Key Points

The knowledge model describes what types of events, conditions, and actions are supported in an active database. Another way to look at the knowledge model is to imagine what types of features are available in an ECA rule definition language.

A framework of dimensions for the knowledge model is presented in [3]. Briefly, each part of an ECA rule is associated with dimensions that describe supported features. Thus, an event can be described as either a primitive event or a composite event, how it was generated (source), whether the event is generated for all instances in a given set or only for a subset (event granularity),and what types (if event is a composite event) of operators and event consumption modes are used in the detection of the composite event.

Conditions are evaluated against a database state. There are three different database states that a rule condition can be associated with [3]: (i) the database state at the start of the transaction, (ii) the database state when the event was detected, and (iii) the database state when the condition is evaluated.

There are four different database states that a rule action can be associated with [3]: (i) the database state at the start of the transaction, (ii) the database state when the event was detected and (iii) the database state when the condition is evaluated, and (iv) the database state just before action execution. The type of rule actions range from internal database updates (e.g., update a table) to external programs (e.g., send email).

Within the context of the knowledge model, it is also useful to consider how ECA rules are represented, for example, inside classes, as data members, or first-class objects. Representing ECA rules as first-class objects [1, 2] is a popular choice, since rules can be treated as any other object in the database and traditional database operations can be used to manipulate the ECA rules. Thus, representing ECA rules as first-class objects implies that ECA rules are not dependent upon the existence of other objects.

The knowledge model of an active database should also describe whether the active database supports passing of parameters between the ECA rule parts, for example, passing of parameters from the event part to the condition part.

Related to the knowledge model is the execution model that describes how ECA rules behave at run time.


Recommended Reading

  1. 1.
    Dayal U, Blaustein B, Buchmann A. et al. S.C. HiPAC: a research project in active, time-constrained database management. Technical report CCA-88-02, Xerox Advanced Information Technology, Cambridge; 1988a.Google Scholar
  2. 2.
    Dayal U, Buchmann A, McCarthy D. Rules are objects too: a knowledge model for an active, object-oriented database system. In: Proceedings of 2nd international workshop on object-oriented database systems; 1988b. p. 129–43.Google Scholar
  3. 3.
    Paton NW, Diaz O. Active database systems. ACM Comput Surv. 1999;31(1):63–103.CrossRefGoogle Scholar

Copyright information

© Springer Science+Business Media LLC 2017

Authors and Affiliations

  1. 1.University of SkövdeSkövdeSweden

Section editors and affiliations

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