ADBMS คืออะไร

Abstract

This survey examines an emerging technology know an active databases. It presents the fundamental characteristics of active database systems and describes features a database must support to be legitimately considered as active system. It describes the knowledge, execution and management model for supporting the active behavior and thus makes explicit the decision space within which the designers of active rule systems must work. Survey also describes some of the research prototypes and commercial systems, highlighting important similarities and differences in their implementations. Finally the survey enumerates some of the challenges in developing and implementing active functionality in database systems.

The focus of this survey is on the issues, which needs to be considered in designing active capability and understanding the way they have been addressed in current systems.

Introduction and outline of survey

This survey provides an overview of some of the issues and fundamental characteristics of active database systems. Section 1 defines active databases and enumerates the features they must support to be legitimately considered as an active system. Section 2 introduces some example applications and categories applications based on the applicability of active functionality. Section 3 presents the main components of abstract active rule system architecture and describes a knowledge, execution and management model for supporting active behavior. Section 4 describes and compares some of the representative active databases (both relational and object oriented) in research and commercial domain. Section 5 indicates what architectural features are important for the implementation of active database systems and what are the challenges in developing such systems. Section 6 specifies some fields in which future work is required. Section 7 presents the conclusion.

I Active databases

Traditional database management systems are passive. Active databases extend “passive” DBMS with the possibility of specifying (re) active behavior. The rules, which define this active behavior, are known as triggers or production rules. Thus active databases are defined as databases with production rules. The rules are stored in database and can be shared by many application programs and database can optimize their implementation.

Active databases can recognize specific situations (internal or external) and react to them without immediate, explicit user or application request. An active database system must provide a knowledge model (description mechanism) and an execution model (runtime strategy) for supporting this reactive behavior. Most common rule format is based on ECA model i.e. “ when ever event occurs, check the condition and if it holds, execute the action “.

Required characteristics of active database management systems [9]

The features a database must support, to be legitimately considered as active systems are

ECA rule definition features
1. An ADBMS has an ECA (event-condition-action) rule model

Reactive behavior must be specifiable/ definable by the user. It should provide a knowledge model consisting of data definition facilities and rule definition language as a means to specify ECA rules.

1.An ADBMS has to provide a means for defining event types

An event type (event, description, pattern, definition) describe situation to which a reaction must be shown
Event occurrences are instances of event types and are conceived as a pair <event type, timestamp, event parameters>
Events can be primitive or composite. In case of composite events, event restrictions specify conditions the components must fulfill in order to form a (legitimate) composition. Event parameters can be one way to specify such restrictions.

2. An ADBMS has to provide means for defining conditions

3. An ADBMS has to provide means for defining actions

An action formulates the reaction to an event and is executed after rule is triggered and condition is satisfied.

An ADBMS must support rule management and rule base evolution

A set of rules at a given point in time forms the rule base. ADBMS should store the information about rules, which currently exist, and how they are defined and how to make them visible to user application (provide access control)

ADBMS must also provide support to add/define new ECA rules and delete old rules, modify events, conditions or action definitions of existing rules. It should have the mechanism to enable and disable rules in rule base.

ECA rule execution features
1. An ADBMS must have an execution model

1. ADBMS must detect event occurrences (either automatically or user/application signaling)

2. ADBMS must support different binding modes and coupling modes

3. ADBMS must be able to evaluate conditions and execute actions

4. ADBMS must implement conflict resolution mechanism (in most of the systems it is currently done by means of priorities)

5. ADBMS must manage event history (consists of all the occurrences of the defined event types). The notion of event history also defines the lifetime of event occurrences and can be very useful in debugging and tracing rules

6. An ADBMS must implement consumption modes

Event consumption mode determines which component (primitive) events are considered for composite events, and how event parameters of composite event are computed from its components. Different application classes may require different consumption modes, such as ‘recent’, ‘chronicle’, ‘continuous’ and ‘cumulative’.

ADBMS – usability and application features
1. An ADBMS should be tunable (for performance improvements and efficient rule execution). It should be tunable at external level or conceptual level. Tuning task is database specific and could be done by application tools or user.
2. An ADBMS should be reducible to DBMS

If user ignores all active functionality, then ADBMS should be reducible to DBMS

An ADBMS should support programming environment and require tuning, tracing and maintenance tools i.e. rule browser, rule designer, rule base analyzer, debugger, etc.

II Active database applications

Active functionality of database can be used for three types of applications [5][18]

Closed database applications

They involve the use of active functionality to describe some of the behavior manifested by the software system without reference to external devices or systems. Rules mainly deal with the maintenance of data within databases. i.e. using rules for automatic statistical analysis or for alerting users to special conditions

Open database applications

They deal with controlling and responding to events occurring outside the database system. i.e. Aircraft monitoring database [11], medical monitoring databases [14], battlefield threat assessment [15], etc.

Database system extensions

Active rules can do tasks, which are handled by special purpose sub systems in passive database. i.e. ECA rules have been used to support integrity constraints [16], materialized views [19], transaction models [20], advance data modeling constructs [21], coordination of distributed computation [22], etc. Such extensions to core database functionality are supported by defining a high level syntax for the extended functionality and a mapping onto a sets of active rules.

Example applications [18]

ADBMS can be used for dynamic data mining. In high data volume dynamic environments, active rules can be used to trigger knowledge discovery algorithms to continuously evaluate and propose data patterns as new information arrives.
ADBMS can be used to drive process-oriented environments such as workflow management systems and software development environments. i.e. insurance claim system, in which each claim may be considered as a process, which must pass through a flowchart of verification and payment containing various branching conditions and time goals. The system must keep track of progress of each claim and must pass on to appropriate participant for each subtask.
Used for automatic triggering of statistical tests, useful in detecting cancer clusters.
ADBMS are used in expert systems like MYCIN, which enable doctors to track down the particular case, which triggered a notification.
In air traffic control, active capability added to a temporal/spatial databases can be used for strategic and tactical planning to ensure that workload remains uniform for different controllers and to provide adaptive control and monitoring capability.

III Architectural issues

Key components of Active database management systems [6]

Abstract active rule system architecture

This section gives an overview of principal components/processes of active databases. In addressing these issues, reference is made to the abstract architecture of active database system presented above. The figure above makes explicit the principal processes / components (rectangles) and data stores (ellipses) used to implement active functionality. A brief description of these important components is given below.

1. Event Detector: It ascertains what events of interest to the rule system have taken place. Primitive events are notified from the database or from external sources; composite events are constructed from incoming primitive events plus the information about past events that can be obtained from the history.

2. Condition Monitor: It evaluates the conditions of rules associated with events that have been detected by the event detector.

3. Scheduler: It compares recently triggered rules with those that have previously been triggered, updates the conflict set, and fires any rules that are scheduled for immediate processing.

4. Query Evaluator: It executes database queries or actions. Access may be required both to the current state of database and to past states in order to support monitoring of how the database is evolving.

Additionally other components, which are useful and provide support, are

1. Rule Manager/Rule Catalog: Required for handling rule definition & manipulation tasks

2. Rule Execution Monitor: Required for maintaining the set of triggered rules and scheduling their execution. It operates on top of scheduler, query evaluator and event detector.

3. Rule Action Planner: It is invoked by the rule execution monitor to produce optimize execution strategies for database commands occurring in rule actions. The same query processor that executes user commands executes these commands.

Components of conceptual model [4][1][6]

An active database system must provide a knowledge, execution and management model for supporting the reactive behavior.

Knowledge Model

Event

Source Ì {Structure Operation, Behavior Invocation, transaction, Abstract, exception,

Clock, External}

Granularity Ì {Member, Subset, Set}

Type Ì {Primitive, Composite}

Operators Ì {or, and, seq, closure, times, not}

Consumption mode Ì {Recent, Chronicle, Cumulative, Continuous}

Role Î {Mandatory, Optional, None}

Condition

Role Î {Mandatory, Optional, None}

Context Ì {DB_T*, Bind _E*, DB_E*, DB_C*}

Action

Options Ì (Structure Operation, Behavior Invocation, Update Rules, Abort, Inform,

External, Do Instead}

Context Ì {DB_T*, Bind _E*_, Bind _C*, DB_E*, DB_C*_,DB_A*}

* refer symbol table at the end

Dimensions of the Knowledge Model

Knowledge model of an active database system indicates what can be said about active rules in the system. It essentially supports the description of active functionality. The knowledge model of an active rule is considered to have (up to) three principal components, an event, a condition, and an action. The table above illustrates a number of dimensions of active behavior and makes explicit the decision space within which the designers of active rule systems work. The nature of the description and the way in which the event can be detected largely depend on the source or generator of the event. They can be caused by the structure operation, exception, method invocation, etc. The event granularity indicates whether event is defined for every object in a set, or for specific members of the set. The role of event indicates the relative importance of events in rule structure. Similarly the role of condition indicate the condition importance and its context indicates the setting in which the condition is evaluated.

Execution Model

Condition Mode Ì {Immediate, Deferred, Detached}

Action Mode Ì {Immediate, Deferred, Detached}

Transition Granularity Ì {Tuple, Set}

Net-effect policy Î {Yes, No}

Cycle policy Ì {Iterative, Recursive}

Priorities Î {Dynamic, Numerical, Relative, None}

Scheduling Î {All Parallel, All Sequential, Saturation, Some}

Error handling Ì {Abort, Ignore, Backtrack, Contingency}

Dimensions of the Execution Model

Principal steps that take place during rule execution

The execution model specifies how a set of rules is treated at run time. The table above illustrates a number of dimensions of execution model. The condition and action coupling modes specifies when condition and action should be executed relative to the event that triggers the rule. The net effects of event occurrences indicate whether cumulative effect of event rather than individual event occurrence should be considered. The cycle policy specifies the mode when events are signaled during condition and action execution of rule. The transaction granularity indicates the relationship between event occurrences and rule instantiations. When the transition granularity is ‘tuple’, a single event occurrence triggers a single rule. When granularity is set then a collection of event occurrences are used together to trigger a rule. The scheduling phase determines what happens when multiple rules are triggered at the same time. The execution model is closely related to aspects of underlying DBMS. The main phases in rule evaluation are

1. Signaling Phase: Refers to the appearance of an event occurrence caused by an event source.

2. Triggering phase: It takes the event produced so far and triggers the corresponding rules. The association of a rule with its event occurrence forms a rule instantiation.

3. Evaluation Phase: It evaluates the condition of the triggered rules. The rule conflict set is formed from all rule instantiations whose conditions are satisfied.

4. Scheduling phase: It indicates how the rule conflict set is processed.

5. Execution Phase: It carries out the actions of the chosen rule instantiations. During action execution other events can in turn be signaled that may produce cascaded rule firing.

Rule Management

Description Ì {Programming language, Query Language, Objects}

Operations Ì {Activate, Deactivate, Signal}

Adaptability Î {Compile time, Run time}

Data Model Î {Relational, Extended Relational, Deductive, Object-Oriented}

Programmer Support Ì {Query, Trace}

Dimensions of Rule Management

It illustrates the facilities provided by the system for managing rules, specifically what operations can be applied to rules and how can they be represented and what’s the programming support for rules. The ‘description’ of rule refers how rules themselves are normally expressed. The ‘operation’ specifies tasks, which they support on rule base. The ‘adaptability’ refers to the degree of support for changes in rules. The ‘ data model’ refers to the base database and has significant influence on the design of rule system. The ‘programmer support’ is of paramount importance if active rules are to be adopted as a mainstream implementation technology in any practical and useful environment.

IV Prototypes

Active databases are a powerful, yet complex, extension to traditional database technology. This section presents some of the prominent research prototypes and commercial systems of different types of ADBMS implementations in research and industry, highlighting important similarities and differences. The two category of systems discussed are relational and object oriented.

Active Relational Database Systems

Research prototypes

Starburst [13]

Starburst active rule system adds active functionality to an extensible relational database system. The unique feature of starburst is that rule processing is invoked automatically at the end of each user transaction that triggers one or more rules. In addition, user can invoke rule processing within transactions by issuing special commands.

The rule system of starburst is based on set based execution model, in which rules are triggered by the net effect of a set of changes to the data. When an operation takes place that is being monitored by a rule the nature of the change is logged in a transition table. The information that is logged in a transition table is used to trigger rules at rule assertion points that may take place either during or at the end of a transition. Thus events do not trigger rules directly. Moreover the role of event is mandatory. For conflict resolution, it uses relative priorities. The operation it supports for rule management are ‘Signal’, ‘Activate’ and ‘Deactivate’ and the scheduling it offers is all-sequential. The action mode it supports is ‘immediate’ and condition mode is ‘deferred’. The semantics of rule execution in starburst is still quite complex and it can be argued that supporting many more facilities in rule sets can make it difficult to understand and maintain

POSTGRES [3]

POSTGRES rule system is a tuple-oriented active relational database system. The role of event is mandatory and the scheduling is all-sequential. It does not use priorities but support immediate condition and action execution mode. When a rule action is executed, it may modify additional tuples, each of which may (immediately) trigger additional rules. Thus rule processing is inherently recursive and synchronous.

Commercial standards

SQL 3

SQL 3 standard support both row level (within transition granularity of tuple) and statement level triggers (with a transition granularity of set). Statement level triggers are executed once in response to an update operation on a table, no matter how many tuples are affected by the update. The most important feature of SQL 3 is that it makes explicit how triggers are to interact with other features found in relational database i.e. declarative integrity checking mechanism.

The role of event is mandatory and scheduling is all-sequential. For errors recovery it support backtracks/ rollback the transaction. It has both immediate and deferred action execution mode. No conflict resolution is necessary, since no two rules can be defined to have same triggering event. Further, additional syntactic restrictions on rule definition ensure that same table cannot be modified multiple times in a sequence of rule firing, thereby ensuring termination.

Active Object Oriented Database Systems [12]

Research prototypes

HiPAC [2]

HiPAC was associated with passive OODB PROBE. It pioneered many of the most important ideas in active databases, such as coupling modes and composite events. In HiPAC, the definer has the flexibility of deciding whether or not the conditions and actions should execute in the triggering transaction. It supports two level coupling i.e Event-Condition coupling and Condition-Action coupling. Rule processing in HiPAC is invoked whenever any event occurs that triggers one or more rules. Rather than selecting one triggered rule to execute using some form of conflict resolution HiPAC executes all triggered rules concurrently. Thus it uses an extension of nested transaction model of execution. HiPAC rules may have relative ordering, and this ordering is used to influence the serialization order of concurrently executing nested sub-transactions. The role of event is mandatory and it supports all ‘immediate’, ‘deferred’ and ‘detached’ condition and execution modes. The transaction granularity is ‘set oriented’.

This active object oriented database is not based upon persistent C++ system.

Sentinel [6]

Sentinel is an active extension to the C++ based open OODB system from Texas Instruments. The focus in this project has been upon the provision of comprehensive event specification mechanisms, representative of rules as database objects, and integration of rule system with sophisticated transaction manager. The rules may have relative priorities assigned to them. The scheduling support of parallel execution is provided. It has tuple level of transaction granularity and has both ‘immediate’ and ‘deferred’ condition execution mode. It supports all event consumption policies i.e. ‘recent’, ‘chronicle’, ‘continuous’, ‘cumulative’, etc. Also the role of event is mandatory in sentinel.

Commercial systems

SAMOS [6][10]

SAMOS provides active facilities on top of the ObjectStore, a commercial object oriented database. As the developer of SAMOS did not have access to the source of ObjectStore, the active system is implemented as a layer on top of ObjectStore. The most important feature of SAMOS is its event detector, the semantics of which is based upon Petrinets, which in turn is implemented using graph structures.

It supports ‘immediate’, ’deferred’, ’detached’ condition and action execution modes. It has sequential scheduling policy and support adaptability at runtime. The consumption policy for events is chronicle and it supports both member and set level event granularity.

Features	Rule expressiveness				Execution semantics			Efficiency
System	Database Events	Temporal Events	External Events	Event Constructors	Coupling modes	Cascade rule exec	Multiple rule exec	Arch.	Type
HiPAC	Insert Delete Modify	Absolute Relative	Yes	Disjunction Sequence Closure	Immediate Deferred Detached	Yes	Using extended nested transaction	Integrated Object oriented	Research Prototype
Postgres	Retrieve Replace Delete Append New, old	Time() Date()	No	Only disjunction	Immediate	Yes	Using user defined priorities	Extended relational	Research Prototype
Starburst	Inserted Deleted Updated	No	No	Only disjunction	Deferred	Yes	Using a conflict resolution strategy	Extended Relational	Research Prototype
Sybase	Insert Update Delete	No	No	No	Immediate	Yes	No	Relational	Commercial system

V Challenges [17]

There are some key challenges that need to be handled before this technology can be efficiently used. Some of the issues in developing active database applications are

1. Given the requirement, which components/parts of database should be supported using active mechanism and what performance penalty is likely to result from the use of rules.

2. The functionality of large rule base may be difficult to understand, with rules interacting in complex ways and no single description of how control flows through an application.

3. The tools associated with active rule system may be minimal, with little support for browsing, monitoring or debugging of active rules.

The following issues reflect the need for design methodologies, rule analysis techniques and tools for debugging and explanation.

Challenges in developing and implementing active functionality in database systems [6][8][7]

Rule design: Given the requirement of an application, design techniques should provide guidance on the aspects that should be supported using active mechanisms, and those that are better addressed using other facilities. Proposals have been made for methods with explicit support for active behavior. Some of the examples are

(ER)²[23] is an extension of the ER model to support the description of events and rules that can be mapped to active rule facilities.
IFO₂[24] adopts the modeling constructs of IFO semantic data model and is use in describing composite events.

These approaches assume that all active rules should surface explicitly in the design method, which might be very difficult and unreasonable.

IDEA methodology [25] provides high-level description language which in the later stages of development are mapped into low-level triggers and are much more flexible.

Rule analysis: There are a number of different characteristics of rule behavior for which a rule analyzer can search [26]

1. Termination problem

(Is the rule processing guaranteed to terminate?) Static analysis of a rule base can indicate if given set of rules may fail to terminate. Less conservative approach is to examine the conditions and actions of rules in more detail (but is more system specific)

2. Confluence

(Is the result of rule processing independent of the order in which simultaneously triggered rules are selected for processing?) A rule base is confluent if for any two rules R_i and R_j triggered in any initial state S, a single final state F is guaranteed to be reached regardless of the order in which any subsequent simultaneously triggered rules are selected for firing. Work on confluence analysis has developed algorithms for analyzing complete rule base [26] and for considering the effect of an update on the truth of the condition [27].

3. Observable determinism

(Does the user of the system observe the effect of rule processing, independent of the order in which triggered rules are selected for processing?) There can be a range of possible solutions for this like rule prioritization, rule condition or action modification to change there effect, dropping rules which are implementing conflicting policies, etc.

Rule debugging: The fact that rule base exhibits terminating and confluent behavior does not imply that it is correct. As the rule base language becomes complicated, the need for rule debugging environment becomes very important. Developing a rule base debugger is a difficult task because insidious interactions rather than state are the main source of incorrect or unexpected behavior and this context-dependent control exhibited by active rules imposes new complex demands on rule debugger [28].

Error recovery: One issue not fully addressed in many ADBMS is the semantics of error recovery during rule processing. Most database rule systems handle errors during rule processing by aborting the current transaction. But in case of error conditions produced by rule actions, this is not the only possible reasonable behavior. Other alternatives are to terminate execution of that rule and continue rule processing, to return to the state preceding rule processing and resume database processing, or to restart rule processing. Another challenge is how to recover events after system crashes especially for temporal or external events.

Features for analyzing rule processing include the ability to trace rule execution, to display the current set of triggered rules, to query and browse the set of rules, and to cross reference rules and data. Other useful features include the ability to control errors in rule programs, to activate and deactivate selected rules or group of rules while database system is processing transactions, and to experiment with rules off-line.

VI Future Directions

The theory and technology of active database systems is still maturing. There has been a considerable experimentation in developing ADBMSs in different domains but relatively little work is done on standardization and theory. This has resulted in wide range of constructs; execution strategies and software architecture being proposed that have utility in different problem domains. Thus there is a need to develop a formal framework for ADBMS so that it can be used to investigate several basic issues relating to their semantics and expressiveness. Along with this framework, a generic performance metrics for active databases are needed so that different systems and the optimization technique they use can be meaningfully compared.

Some of the domains in which a lot of work is needed are

Increasing the expressive power of rules: Some applications may need the ability to define rules with more complex triggering events, conditions, or actions than currently can be expressed in database rule language. Methods for increasing the expressiveness of rules while maintaining efficient implementation deserves further study.

Improved algorithms: Efficient algorithms for processing rules are crucial for delivering the functionality of active databases without excessively degrading the performance of conventional database processing.

Distribution and parallelism: Active databases have been considered primarily in centralized database environment. Many issues, including the distribution and fragmentation of rules and algorithms (that guarantee equivalence with centralized rule processing) need to be considered for distributed or parallel database systems.

Support for additional functionality: A lot of work is needed in distributed rule processing of triggers, coupling ADBMS and expert system shell, automatic translation of higher-level specifications to triggers and techniques for debugging active databases.

VII Conclusion

Despite the challenges presented, the rewards offered by active functionality are great and as the field matures, it will prove as an enduring force within the area of database technology.

VIII References

S.Chakravarthy, Architectures and Monitoring Techniques for Active Databases: An Evaluation, (1992).

Dayal U., Blaustein B., Buchmann A., Chakravarthy U., Hsu M., Ledin R., McCarthy D., Rosenthal A., Sarin S.: The HiPAC Project: Combining Active Databases and Timing Constraints, SIGMOD RECORD, Vol. 17, No. 1.

The Design Of Postgres - Stonebraker, Rowe.

S. Chakravarthy, E. Anwar, and L. Maugis. Design and implementation of active capability for an object-oriented database. Technical Report UFCIS -TR-93-001, University of Florida, Computer and Information Sciences, 1993.

Norman W. Paton, Oscar Díaz: Introduction. Active Rules in Database Systems.

Norman W. Paton, Oscar Díaz: Active Database Systems. ACM Computing Surveys 31(1): 63-103 (1999)

P. Picouet and V. Vianu. Semantics and Expressiveness Issues in Active Databases. In Proc. ACM Symposium on Principles of Database Systems, 1995.

“Moving active functionality from centralized to open distributed heterogeneous environments ” by Mariano Cilla, Christof Bornhovd, Alejandro P. Buchmann.

The Active Database Management System Manifesto: A Rulebase of ADBMS features, A joint report by the ACT-NET Consortium.

S. Chakravarthy, A comparative Evaluation of Active Relational Databases. (1993)

Naqvi and Ibraham, 1994. Rule and knowledge management in an active database system. In proceedings of the first international workshop on rules in database systems.

N. Paton, J. Campin, A.A.A. Fernandes, and M. Howard Williams, "Formal Specification of Active Database Functionality: A Survey," in Rules in Database Systems, Proc. of the 2nd International Workshop RIDS'95, T. Sellis, Ed., 1995.

Jennifer Widom, “The starburst Active Database Rule System “.

BLUE, A., BROWN, B., AND GRAY, W. 1988. An implementation of alerters for health district management. In Proceedings of the Sixth British National Conference on Databases (BNCOD), W. Gray, Ed., 125–140.

DAYAL, U., BUCHMANN, A., AND MCCARTHY, D. 1988. Rules are objects too: A knowledge model for an active object oriented database system. In Proceedings of the Second International Workshop on OODBS, LNCS 334, K. Dittrich, Ed., Springer-Verlag, 129–143

DIAZ, O. 1992. Deriving rules for constraint maintenance in an object-oriented database. In Proceedings of the International Conference on Databases and Expert Systems DEXA, I. R. A. M. Tjoa, Ed., Springer-Verlag, 332– 337.

BUCHMANN, A., ZIMMERMANN, J., BLAKELY, J., AND WELLS, D. 1995. Building an integrated active OODBMS: Requirements, architecture, and design decisions. In Proceedings of IEEE Data Engineering, 117-128.

James A. Bailey, K. Ramamohonarao, “ Issues in Active databases “.

STONEBRAKER, M., JHINGRAN, A., GOH, J., AND POTAMIANOS, S. 1990. On rules, procedures, caching and views in database systems. In Proceedings of ACM SIGMOD, 281–290. Verlag, 158–169.

GEPPERT, A. AND DITTRICH, K. 1994. Rule-based implementation of transaction model specifications. In Proceedings of the First International Workshop on Rules in Database Systems, N. Paton and M. Williams, Eds., Springer-Verlag, 127–142.

PATON, N., DIAZ, O., AND BARJA, M. 1993. Combining active rules and metaclasses for enhanced extensibility in object-oriented systems. Data Knowl. Eng. 10, 45–63.

CERI, S. AND WIDOM, J. 1993. Managing semantic heterogeneity with production rules and persistent queries. In Proceedings of the Nineteenth International Conference on Very Large Data Bases, R. Agrawal, S. Baker, and D. Bell, Eds., Morgan Kaufmann, San Mateo, CA, 108–119.

NAVATHE, S., TANAKA, A., MADHAVAN, R., AND GAN, Y. H. 1995. A methodology for application design using active database technology. Tech. Report RL-TR-95-41, Rome Laboratory.

ABITEBOUL, S. AND HULL, R. 1987. IFO: A formal semantic database model. ACM Trans. Database Syst. 12, 4 (Dec.), 525–565.

CERI, S. AND FRATERNALI, P. 1997. Designing Applications with Objects and Rules: The IDEA Methodology. International Series on Database Systems and Applications, Addison- Wesley Longman, Reading, MA.

AIKEN, A., WIDOM, J., AND HELLERSTEIN, J. 1992. Behavior of database production rules: Termination, confluence, and observable determinism. In SIGMOD Rec. 21, 59–68.

BARALIS, E. AND WIDOM, J. 1994. An algebraic approach to rule analysis in expert database systems. In Proceedings of the Twentieth VLDB, J. Bocca, M. Jarke, and C. Zaniolo, Eds., Morgan-Kaufmann, San Mateo, CA, 475–486.

DIAZ, O., JAIME, A., AND PATON, N. 1994a. DEAR: A DEbugger for Active Rules in an object-oriented context. In Proceedings of the First International Workshop on Rules in Database Systems, N. Paton and M. Williams, Eds., Springer-Verlag, 180–193.

Symbol table

SYMBOLS	DESCRIPTION
ADBMS	Active Database Management System
ECA	Event Condition Action
DB_T	Start of current transaction
DB_E	Start of current Event
DB_C	Start of current Condition
DB_A	Start of current Action
Bind _E	Bind with the event
Bind _C	Bind with the condition

ถอยกลับ