|Title |Introduction |Integrating App's |Integrity Maintenance |AOODB Model |Backward Propagation |HVC |Constraint Maintenance |Conclusion |References|
3 Integrity Maintenance in Active Databases
Integrity constraint is a condition that data within a database must satisfy. It also indicates types of processing that may or may not take place [Prat87;Eswa76]. Integrity maintenance (or constraint enforcement) is a set of activities to keep a database in a consistent sate, where all instances in the database satisfy integrity constraints.
In this chapter, we describe previous research on integrity maintenance in active databases. Approaches to integrity maintenance in active databases can be classified into three categories as depicted in Figure 3-1: the application of
Figure 3-1 Approaches to integrity maintenance in active database
the general trigger, the separation/generalization of the constructor for constraint from the general event/trigger constructor, and the application of the constraint analysis for specification and propagation of constraint.
The integrity maintenance with the general trigger means that integrity constraints can be supported with general purpose triggers that can be used in both constraint enforcement and automatic invocation of the pre-specified procedures. Some researchers have insisted that general event/trigger mechanism is not sufficient to define and maintain integrity constraints in non-standard application domains [Hsu88;Kotz88;Geha91]. So they extended or generalized current event/trigger to the dedicated constructors for constraint enforcement. Since these approaches and the approaches with the general triggers use strategy to abort a transaction when it counters an inconsistent database state, the constraint enforcement in these approaches is called the passive constraint enforcement [Caca90]. The constraint analysis is a logical derivation of the constraint propagation and repairing process from user declaration of integrity constraint. From the result of the analysis, a DBS automatically provides additional operations, instances, or constructors for constraint to maintain the specified constraint. These approaches with the constraint analysis are called the active constraint enforcement [Caca90], since they actively change database states to enforce integrity constraints. Approaches to the constraint analysis can be classified into two categories, the inherent constraints and the explicit constraints, according to the property of the analysis domain [Urba88].
Before the discussion about the related issues, since active databases provide a suitable paradigm for operational support of integrity maintenance, we describe the fundamental research on active databases in Section 3.1 In Section 3.2 the separation/generalization of the event/trigger constructors for constraint enforcement is described along with comparisons with our approach. The approaches based on the constraint analysis are presented in Section 3.3.
3.1 Active Databases
Conventional databases do not process data without explicit requests by users or application programs. An active database can initiate processes automatically when its state reaches a certain pre-defined condition. McCarthy has defined the active database system (ADBS) as 'a database management system that allows users to specify actions to be taken automatically, without user intervention, when a certain condition arises' [McCa89].
Automatic responses of active databases can be declared by using the Event-Condition-Action (ECA) rules proposed in [Daya88], and several databases use the triggers to realize the rules. The ECA rules have the event clause monitoring a certain transaction (an event) in a database, the condition clause describing a logical expression that is evaluated when the event occurs, and the action clause to be executed when the condition clause is satisfied.
Recent efforts in this research area have focused on incorporating object-oriented paradigm for expressive representation of objects' behavior in trigger definition. As a result, several active object-oriented database systems (AOODBSs) have been developed. HiPAC (High Performance ACtive database system) was developed on the Smalltalk environment [Chak89;MaCa89; Daya88a,88b]. The research suggested the ECA rule as a formalism for active databases which is a generally accepted model for ADBSs now. The suggested ECA model also contains various temporal constructors for the trigger execution. Another AOODBS, Ode, was developed at AT&T Bell laboratory [Geha91,92;Anwa93]. The researchers of Ode insisted that constructors for integrity constraint in ADBSs should be separated from the trigger constructor. They pointed out the significant conceptual difference between the constructors for constraint and trigger as the reason for the separation.
Another commercially available AOODBS, UniSQL/X, also has supported a trigger constructor since release 2.0 [UniS93a]. Its trigger constructor implements an active rule in the ECA framework. Extended from relational DBS with object-oriented features, UniSQL/X provides the join operations between classes [UniS93a]. ADAM [Diaz91;Diaz92;Anwa93] is an OODBS prototype implemented in the PROLOG. The DBS manages rules and objects in a uniform approach and provides automatic translation of high-level specifications of object behavior into equivalent sets of rules [Diaz92]. CPLEX is a language for defining and manipulating a persistent object base [Hsu88]. It classifies rules into two classes, the consistency rules for constraint enforcement and the automation rules for automatic procedure invocation. DAPLEX functional data model and language provide the bases of the language. Other DBSs, such as POSTGRESS [Ston88,89,90] and STARBURST [Wido92], also provide active facilities as their dedicated components.
3.2 Separation of Integrity Constraints from General Trigger/Event
Several researchers have insisted that the general trigger/event mechanism is not enough to represent and manage integrity constraints in advanced database application domains such as engineering [Hsu88;Kotz88;Geha91]. They developed or separated the dedicated constructors for constraint maintenance separate from the general trigger/event constructor.
Considering semantic rules required for engineering applications, Kotz presented a generalized event/trigger mechanism for semantic rules, which allowed flexible checking time and arbitrary actions in the case of rule violation [Kotz88]. This generalized event/trigger mechanism can be used to cover semantics of engineering applications in checking and enforcing engineering constraints.
CPLEX supports rules that are classified into the consistency rules and the automation rules [Hsu88]. The consistency rule consists of a trigger that has a predicate that may become true when a constraint is violated. The rule, therefore, enables the databases to manage the constraints. The automation rule simply executes the reserved procedure that has no concern about integrity constraints after the consistency rules determines the proposed modification to be valid. The consistency rule is the dedicated constructor for integrity constraints separated from the general triggers.
Ode also separates the constraints and the triggers [Geha91]. The significant conceptual differences between them are the reason of the separation. An example of the difference is that the triggers are not concerned about object consistency and fired whenever the specified condition becomes true [Geha91]. The constraints and the triggers in Ode are similar to the consistency rules and the automation rules in CPLEX, respectively.
We also chose the same approach in order to describe engineering semantics using the constraint enforcement mechanism based on the triggers. Like the previous work, we extend the trigger mechanism of an existing AOODBS [UniS93a] to a dedicated constructor for integrity maintenance, CONSTRAINTCCH. What differentiates ours from others is the reason of the separation. The reason for previous research effort has been the limited expressive power [Kotz88] and the conceptual differences between constructors for constraint and trigger/event [Hsu88;Geha91]. We, however, separated the constructor for constraint to avoid the side effect of constraint propagation. Triggers for automatic execution of procedures do not need the backward propagation that occurs when constraint should propagate against a class composition hierarchy. Rather, the backward propagation in the triggers causes a side effect of attaching unnecessary triggers to participating classes. The comparisons are shown in Table 3-1.
Table 3-1 Comparisons of approaches to constraint and trigger separation
|
System/Mechanism [Reference] |
Extension Method |
Constructor for Integrity Maintenance |
Reason for Extension |
|
ETM [Kotz88] |
generalization |
generalized event and trigger |
limitations of expression power |
|
CPLEX [Hsu88] |
separation |
consistency rule /automation rule |
difference in semantics |
|
Ode [Geha91] |
separation |
constraint /trigger |
difference in semantics |
|
ICA [Do94] |
separation |
CONSTAINTCCH /trigger |
a side effect of the backward propagation |
3.3 Constraint Enforcement with Integrity Analysis
The activities for constraint maintenance in the constraint analysis often consist of declaration of constraints, constraint analysis, and constraint repairing [Flat93]. The declaration of constraints is a set of activities for the user to declare constraints on objects in constraint language. The database models and the constraint languages are related features in this phase. The constraint analysis is $)C!.a process that reasons about the user-defined constraints to understand the effects of constraints on object manipulation, identifying possible constraint violations and design alternatives for handling violations$)C!/ [Urba88]. In analyzing integrity constraints, the analysis method and the analysis target (domain) must be considered. The constraint repairing makes database state return to consistent condition when the result of object manipulation violates the user-defined constraint. The repairing language and the repairing methods are the related features in this phase. The sequence and the related features for each step are depicted in Figure 3-2.
Figure 3-2 Sequence of defining integrity constraint in the constraint analysis
Flaternali et al. reviewed the approaches to integrity maintenance in active databases and other kinds of databases [Flat93]. They compared the approaches in several features [Flat93]. The three from the six approaches in [Flat93] are selected and introduced in this paper, since the remaining approaches do not use active databases. The following is the description of the related research compared in [Flat93].
Ceri's approach [Ceri90]
This approach is a pioneering work for the constraint enforcement in active database using repairing mechanism. It allows the user to specify constraints in a declarative constraint language, whose syntax extends SQL. Then, the specified constraints are translated into a set of ECA rules for the constraint enforcement. In the generated ECA rules, the event clauses list all the data operations potentially violating the constraint, and the condition clauses contain predicates indicating the constraint violation. The action clauses in the ECA rules should be added manually by the user. A separated work for automatic generation of repairing rules is performed by the Ceri et al. [Ceri92] and enhances [Ceri90] for the preparation of the action clause.
Urban's approach [Urba92b]
Urban also has proposed a translation of user specified constraints into the rules for integrity enforcement in active databases [Urba92b]. In this approach, integrity constraints specified by the user are translated into Integrity Maintenance Production Rules (IMPRs). During the translation, the infinite triggering and conflict updates are checked through the trigger graph. A tool called CONTEXT supports the generation of IMPRs from user defined constraints [Urba88;92a]. The tool needs user's assistance for generating the IMPRs on complex and explicit constraints. The IMPRs associated with integrity maintenance subsystem check integrity constraints of a transaction before its commitment with an update log file.
Ceri's approach [Ceri92]
The goal of this work is to define an architecture of an integrity maintenance system based on the active database paradigm. It is enhanced by the automatic generation of repairing rules so the repairing rules are automatically generated from declarative constraints specified in a constraint language that is a subset of Relational Calculus. The work also shows the correctness and termination of repairing rules, providing soundness and completeness of the rule generation algorithm.
Our approach[Do94]
Our approach has similar features to those of the above approaches, including the constraint language extending SQL, the ECA rules in constraint repairing, and compile time resolution. There are, however, several differences between ours and the above works.
The first difference is that ours considers a specific problem of propagating integrity constraints against a class composition hierarchy in an object-oriented database. Other approaches to integrity maintenance use the predicate logic or the set-oriented notation in which constraints are declared in declarative and non-directional manner. Hence, they overlooked the problem of the navigational (directional) propagation of constraints over class composition hierarchies.
The problem most closely related to the backward propagation problem we proposed is the inverse property in the inherent constraints proposed by Urban et al. [Urba92]. An inverse property is used to show that two properties (predicates) have explicit inverse to describe the extensional meaning of the schema (for example the owned_by and the owner_of properties in [Urba92]). The property is used in reasoning about object relationship. [Urba92], however, does not consider the propagation over class composition hierarchies in object-oriented database and multi-level propagation.
The second difference is the constraint repairing mechanism we propose. We propose a virtual class in object-oriented database along with ECA rules as a message reflector over the participating classes. This virtual class, providing the efficient backward propagation approach, can be used as a constraint management unit in a constraint management system (see Section 7.1.3).
There are limitations of our approach compared with other approaches. One is the lack of the explicit constraint analysis. The explicit constraint is arbitrary properties to be satisfied by the database instance that cannot be captured by schema restriction [Urba92]. We provide analysis and repairing mechanism for the inherent constraint only, which are related to the schema restriction. The automatic analysis and repairing of the explicit constraint that is partially automated in the current research on integrity enforcement is left as a further work.
The other is automatic detection of the inherent constraint we support. We consider the backward propagation approaches in the case that the user detects the constraint that causes the backward propagation. The detection mechanism can be automated, by testing several properties of constraint and class composition hierarchy of the participating classes. We, however, leave the automatic detection as another further work. Table 3-2 shows the comparisons between our approach and others.
Table 3-2 Comparisons of the constraint analysis approaches (revised from [Frat93])
| Reference | Data Model | Constraint Language | Repairing Action Language | Repairing Technique | Analysis Target | Analysis |
| [Ceri90] | relational | extended SQL | extended SQL | ECA rules | Triggering Graph | |
| [Urba92] | DOO | restricted 1st order logic | rich object update language | ECA rules | Inherent/ Explicit | not addressed |
| [Ceri92] | relational | restricted domain relational calculus | insert, delete, update | ECA rules | Triggering hypergraph Problem solver | |
| [Do94] | OO | extended trigger | extended SQL | ECA rules with virtual class | Inherent | CCH check (manual) |
Korean Engineering Databases ¨Ï copyright Namchul Do, 1996