Embed Size (px)
Citation preview
On Specifying the Reactive Behavior
on Constraint Violations
Michael Gertz
Institut fur Informatik, Universitat Hannover, Lange Laube 22, D-30159 Hannover
Abstract
Recent approaches to integrity enforcement in active databases suggest notonly to check for inconsistencies by triggers but also to utilize triggers to performrepair actions on constraint violations. Typically, respective repairing triggersare derived automatically from constraint specifications following almost fixedderivation strategies. However, in order to incorporate more semantic knowledgeof the application these approaches often require refinements or even revisionsof already derived integrity checking and inconsistency repairing triggers by thedesigner.
In this paper we argue that analyzing and specifying repair actions on con-straint violations should be also a design task and exclusively be carried out inthe conceptual design. For this purpose, we provide a declarative specificationlanguage for repair actions on inconsistencies with an operational semantics, suit-able to express most of the designers’ intentions on the behavior on constraintviolations. We describe a design methodology for reaction specifications andshow how integrity checking and inconsistency repairing triggers can be derivedfrom these specifications.
Contents
1 Introduction 1
2 Definitions and Notations 2
2.1 Integrity Constraints and Transactions . . . . . . . . . . . . . . . . . . . . . 2
2.2 Example Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Constraint Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Reaction Specifications 8
3.1 Syntax and Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Pattern of Reaction Specification . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.1 Rollback of Violating Operations . . . . . . . . . . . . . . . . . . . . 12
3.2.2 Attribute Replacement Reactions . . . . . . . . . . . . . . . . . . . . 14
3.2.3 Propagations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.4 Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3 Default Reactions on Constraint Violations . . . . . . . . . . . . . . . . . . . 27
4 Analyzing and Structuring Reactions 29
4.1 Dependency Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2 Ordering Reactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.4 Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5 Trigger Derivation 38
5.1 Trigger Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2 Integrity Checking and Inconsistency Repairing Triggers . . . . . . . . . . . 39
5.3 Monitoring Cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.4 Repair Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6 Conclusions and Further Work 45
References 46
1 Introduction
Facilities of active databases provide a suitable framework to realize efficient integrity main-taining mechanisms through triggers as part of the DBMS and hence avoid external integritymonitoring programs. Respective approaches to derive integrity maintaining triggers fromconstraint specifications have been presented in, e.g., [CW90, GL93]. Recent approaches toactive integrity enforcement in deductive [ML91], object-oriented [ST92, UD92, UKN92] andrelational databases [FPT93] also suggest to utilize triggers to perform repair actions in caseof inconsistencies caused by ad-hoc transactions.
However, the proposed approaches almost follow fixed derivation strategies and thus oftenrequire refinements of already derived integrity checking and inconsistency repairing triggersin order to incorporate more and necessary semantic knowledge of the application, e.g.,on the order of trigger execution. Herewith, apart from decreasing efficiency of previouslyderived triggers often inconsistencies or critical specifications may be introduced, e.g., cyclesof repair actions.
Assuming ad-hoc transactions, the general problem of repairing inconsistencies is that evensimple integrity constraints may be violated through several operations and also often amultitude of repair actions exists, different from a complete rollback of the faulty transaction.Although the designer can extend the action parts of standard integrity checking triggers[CW90], it is difficult for him/her to take all interrelations between constraints, reactions andtriggers into account. In particular, assuming constraints specified in a declarative manner,e.g., as first-order formulas, the modification of integrity checking triggers takes place ina completely different framework. Conditions and actions of triggers are specified in aprocedural manner, i.e. in a certain data definition and manipulation language, depending onthe underlying DBMS. We argue that specifying constraints and repair actions on violationsshould take place in the same framework, i.e. in the conceptual design, and in particular thesame specification language should be used for these specifications.
To realize such an approach we present a declarative specification language for reactionson constraint violations in relational active databases, suitable to express most of the in-tended behavior in case of an inconsistency introduced by a user or application transaction.Reactions on constraint violations can be rollbacks of single violating operations, multipleattribute replacements on violating tuples, modifications in addition to those in a transac-tion (also called propagations) or descriptions of exceptional cases for constraints. A mainfeature of our specification language (also neglected in most other approaches) is that ana-lyzing violations can easily be integrated into repair actions. Thus it is possible to react indifferent ways dependent on certain database states and properties of violations. An im-portant requirement on repair actions is that not only violations under consideration shouldbe removed, but also no new inconsistencies (at least of the same constraint) should beintroduced due to repair modifications. For this, we suggest some pattern for so-called saferepair actions which guarantee such a behavior. These patterns are drawn from analysis ofdifferent cases of violating operations and database states.
In contrast to integrity checking approaches, modelling reactive behavior on constraint vio-lations can become a very complex design task. Constraints and repair actions need to beanalyzed, e.g., possible dependencies have to be identified. For example, a repair action onviolations of one constraint may violate another constraint. To capture and visualize theoften complex and mutual interrelations between integrity constraints and repair actions we
1
use so-called dependency graphs. Inter alia, such graphs reflect the order when to check acertain constraint before another constraint at run time in order to achieve an efficient checkand repair process.
All information necessary to derive integrity checking and inconsistency repairing triggersare modelled within such a dependency graph. This includes the order of repair actions to beconsidered for each constraint at run time, but also strategies on how to handle ambiguousconstraint violations and (possible) cycles of repair actions. Hence, after integrating allnecessary semantic knowledge of the underlying application into such a graph refinementsor revisions of later triggers should become superfluous.
After completing the modelling of reactive behavior as a conceptual design task, a set ofintegrity checking and inconsistency repairing triggers is derived automatically. These trig-gers are stratified such that in each situation of the repair process they are always checkedin a fixed deterministic (specified) order. Although it is in general not decidable (based ona simple static analysis) whether or not inconsistencies present in a certain database statecan be repaired, a restricted mechanism is presented to avoid unnecessary repair actionsin presence of (other) irreparable inconsistencies. As a desired goal, the derived triggersguarantee that no ad-hoc transaction can ever invalidate any of the specified constraints andthus result in an inconsistent state.
The paper is structured as follows: In section 2 we give preliminary definitions and notationson integrity constraints, transactions and constraint violations. In section 3 we present thesyntax and semantics of our reaction specification language. We focus on the different typesof reactions on possible violating operation patterns and also on their (desired) properties.Methodological guidelines on modelling the reactive behavior, analyzing and specifying re-actions are discussed in detail in section 4. After a description of the derivation approach forchecking and repairing triggers in section 5 we conclude with some remarks on the presentedapproach and our further work.
2 Definitions and Notations
2.1 Integrity Constraints and Transactions
To express static constraints over relational databases we use formulas of first-order predicatelogic (FOL) including non-generic function symbols and the typical built-in predicates like=, <,>, etc. We denote the set of predicate symbols corresponding to the base relationsof a given database schema by P and those corresponding to built-in predicates by P ∗.The approach described in the sequel utilizes integrity constraints in a so-called ImplicativeNormal Form (INF) which has the pattern
C ≡ ∀~x : p1(~xp1) ∧ . . . ∧ pn(~xpn
) ⇒ ∃~y : q1(~xq1, ~yq1
) ∨ . . . ∨ qm(~xqm, ~yqm
). (1)
Each predicate symbol pi and qj corresponds to a base relation or built-in predicate.1 Thevectorial notations ~xpi
, ~x, ~yqjand ~y represent respective arguments of the predicates, i.e. con-
stants, variables and functions, such that ~x =⋃n
x=1 ~xpiand ~y =
⋃m
j=1 ~yqj. For a constraint in
1Throughout the paper we use the terms predicate (symbol) and relation synonymously.
2
INF, the conjunction on the left side of the implication is called the body and the disjunctionon the right side is called the head of the constraint.
More complex integrity constraints which are not in INF can be transformed into a prenexnormal form Q1x1, . . . , Qnxn : (M) such that the matrix M , which follows the quantifiersQ1, . . . , Qn, is in a conjunctive normal form [CL73]. Using Skolem functions and constantsfrom each conjunctive part in the matrix M then a constraint in INF can be derived [UD92].However, considering practical applications it turns out, that the pattern (1) is suitable toexpress most of the static integrity constraints, in particular referential integrity constraintsor constraints restricting attribute values. In the sequel we only consider constraints of thepattern (1) above.
An important requirement on the constraints is that they must be evaluable, i.e. everyuniversally quantified variable xi ∈ ~x which appears in a literal qj in the head must alsoappear in at least one literal pi in the body [vGT91]. Although commercial relational DBMSavoid this problem by respective implementations, formally allowing non-evaluable formulasmay result in indefinite query results.
In the following C denotes the set of constraints in INF for a given database schema. Fora constraint C ∈ C, ∆crit
C denotes the set of critical operation patterns, i.e. the pattern ofelementary database operations which may invalidate C. Such operations have the patternIp (insertion into p), Up (update on p), or Dp (deletion from p) where p is a base relation.Critical operation patterns for a constraint C can easily be determined by a syntax basedapproach [LR84]: for each relational symbol pi corresponding to a base relation which appearsin the body of C, insertions into pi and updates on pi are critical operations. Analogously,for each base relation symbol qj which appears in the head of C, deletions and updates on qj
are critical operations.2 Note that ∆critC contains only the names of critical operations, not
instances of such operations, e.g., given by a transaction.
A transaction T determines a finite set ∆T of database operation instances, e.g., ∆T ={Ip(~a), Ip(~b), Uq(~c), . . . , Dq(~e)}, where ~a, . . . , ~e are tuples. In ∆T only the transaction neteffect appears, i.e.
• if a tuple is updated several times in T , only the composite update appears in ∆T ,• if a tuple is inserted and then updated in T , only the insertion of the updated tuple
appears in ∆T ,• if a tuple is updated and then deleted in T , only the deletion of the original tuple
appears in ∆T , and• if the same tuple is deleted and then inserted in T (or vice versa), nothing appears in
∆T .
We require that for each base relation p ∈ P there exist three delta relations which we denoteby ∆Ip
,∆Upand ∆Dp
. They are utilized to store all tuples inserted, updated and deleted bya transaction. Therefore ∆Ip
, ∆Upand ∆Dp
inherit all attributes from the corresponding baserelation p. For any base relation p with n attributes ∆Up
has n additional attributes to storethe old value of the updated tuple. In an expression of the form ∆Up
(x′1, . . . , x′n, x1, . . . , xn)
the variables x′1, . . . , x′n refer to the old attribute values and the variables x1, . . . , xn to the
new attribute values. In each delta relation ∆ω for an operation pattern ω ∈ {Ip, Up, Dp | p ∈P}, again only the net effect appears. At the beginning of a transaction all delta relations
2In section 3.2.2 we will give a criterion for refining properties of updates which are critical for a constraint.
3
are assumed to be empty. The transaction net effect thus can be described in terms of deltarelations, i.e.
∆T =⋃
p∈P
∆Ip∪⋃
p∈P
∆Up∪⋃
p∈P
∆Dp
In active database systems like Ariel, Postgres or Starburst, delta relations (often also calledtransition tables) are a typical means to keep information about the triggering operationsinstances occurred in a transaction. They can be referred to in the condition as well as inthe action part of a trigger [Han91, WF90, SJGP90]. In our approach we will utilize deltarelations to formulate efficient integrity checks and repair actions.
2.2 Example Database
To illustrate our techniques by examples, we utilize a database schema describing a personaldatabase of a company. The schema comprises the following relations:
emp[loyee](eno, name, jno → job, dno, salary)dep[artment](dno, dname, location)job(jno, title, paygrade)proj[ect](pno, pname, head → emp(eno), dno)head(mgrno → emp(eno), eno → emp)
The following constraints expressed by domain calculus formulas restrict single possibledatabase states to admissible states (data types of arguments are omitted):
C1: ∀eno, . . . , salary : emp(eno, . . . , salary) ⇒ salary > 1000Every employee must earn more than 1000.
C2: ∀eno, . . . , dno, . . . , salary : emp(eno, . . . , dno, . . . , salary) ⇒∃dname, location : dep(dno, dname, location)
Every employee has to work in a department.
C3 ∀mgrno, eno : head(mgrno, eno) ⇒ ∃mgrno′ : head(mgrno′,mgrno)Every manager again has a manager (allowing a manager to be his own manager).
C4 ∀pno, pname, head, dno : prj(pno, pname, head, dno) ⇒∃jno, salary : emp(head, jno, dno, salary)
A manager leading a project in a department must work in the same department.
In addition to the constraints above we also sometimes use more simple constraints referring,e.g., to base relations q, p, etc. Variables in such constraints then are denoted by lower lettersv, w, x, y, z with indices.
2.3 Constraint Violations
Given an integrity constraint C ∈ C, we now describe how to evaluate violations of C whichmay arise due to a transaction T and how to extract possible reasons for the violation(s)from ∆T . We give also criteria on unambiguous violations of C, i.e. operations from ∆T asa definite reason for a certain violation of the constraint C. In this context it is important
4
to note that we assume that inconsistencies may only arise due to operations of the mostrecently accomplished transaction T . Note that it is also possible that “reasons” for aninconsistency may have been introduced by previous transactions. The fact that insertingnew information leads to an inconsistency does not imply that the inserted information isincorrect! It turns out that reaction specifications can take such circumstances into accountthrough the capability to modify also facts introduced by any previous transaction performedbefore T .
A constraint C ∈ C is violated in a database state σ iff σ 6|= C holds [LT85, Rei84]. Then thestate σ is said to be inconsistent with respect to C. To evaluate a constraint C in a givendatabase state σ the violation query C for C is obtained by negating the defining formulaof C and then freeing all existentially quantified variables ~x.
Example 2.1: Assume constraint C3 stating that every manager must also have a manager.The respective violation query C3 is
C3 ≡ ∀mgrno′ : head(mgrno, eno) ∧ ¬head(mgrno′,mgrno)
Thus ∆violC ≡ {mgrno, eno | ¬∃mgrno′ : head(mgrno, eno) ∧ head(mgrno′,mgrno)}
The query C determines a set of violations (tuples) denoted by ∆violC . Each row (tuple) in
∆violC corresponds to a substitution θ of the free variables in C such that [σ, θ] |= C holds. Up
to now the evaluation of constraint violations described above reflect the typical procedurewhich is sufficient for “ordinary” integrity checking methods, i.e. to simply check a constraint(or rather the violation query) and to perform a complete rollback of the transaction in caseof any violation. Since we investigate repairing violations in a more sophisticated way, it isalso important to identify reasons for an inconsistency, e.g., operation instances, in order toreact in a suitable way. For this an important term are join tuples:
Definition 2.2 (Join Tuples):Let C be a constraint in INF having the body p1(~xp1
) ∧ . . . ∧ pn(~xpn). A join tuple of
C in a state σ is a tuple from the relation Pbody ≡ ./ni=1 pi (natural join). The attribute
values of a single join tuple in the state σ correspond to a substitution θ such that [σ, θ] |=p1(~xp1
) ∧ . . . ∧ pn(~xpn) holds.3 2
Obviously, if σ is an inconsistent state violating constraint C, ∆violC ⊆ Pbody holds. Based on
join tuples we can identify two types of constraint satisfaction:
Definition 2.3 ((Non)-Trivially Satisfied Constraint):Let t be a join tuple for a constraint C in INF in a state σ, determining a substitution θas in definition 2.2. C is said to be non-trivially satisfied in σ by t if there exists atleast one relation qi ∈ head(C) and a substitution θy for the variables ~yqi
in qi(~xqi, ~yqi
) suchthat [σ, θ + θy] |= p1(~xp1
) ∧ . . . ∧ pn(~xpn) ∧ qi(~x, ~yqi
) holds. For any tuple t′ determining asubstitution θ′ of the variables ~x such that [σ, θ′] |= p1(~xp1
) ∧ . . . ∧ pn(~xpn) does not hold in
σ, C then is said to be trivially satisfied by t′ respectively θ′. 2
A transaction T can only invalidate a constraint C if there exists at least one operationinstance oi in ∆T , ∆T = {o1, . . . , on}, such that the pattern of oi (denoted as ω) is a criticaloperation, i.e. ω ∈ ∆crit
C . To determine in the poststate σ of a transaction which operation
3In the following we utilize the term join tuple and substitution θ for p1(~xp1)∧. . .∧pn(~xpn
) synonymously.
5
instances o ∈ ∆T (having a certain pattern ω) are (possible) reasons for a violation of C,the semijoin [Ull88]
∆ωC := ∆ω >< ∆viol
C (2)
determines a subset ∆ωC of tuples from the delta relation ∆ω which are involved in violations
of ∆violC . We assume that for ω = Up only the attribute values corresponding to new attribute
values appear in ∆ωC, i.e. ∆
UpC := πx1,...,xn
(∆Up>< ∆viol
C ) for each p ∈ P . In the sequel werefer to such a set ∆ω
C of violating tuples using the relation symbol ∆ωC. A relation ∆ω
C also iscalled specialized violation relation, i.e. a specialization of the relation ∆viol
C to the operationpattern ω.
However, the question whether a certain constraint violation from ∆violC depends exactly on
one operation instance from ∆T in general cannot be answered unambiguously. This fact isillustrated in the following example:
Example 2.4: Consider constraint C2 stating that every employee has to work in a depart-ment. Critical operations for this constraint are insertions (updates) in (from) the relationemp and deletions (updates) from (on) the relation dep. Thus ∆viol
C2= {Iemp, Uemp, Ddep, Udep}.
Assume a transaction T which only performs an insertion of a single employee into the rela-tion emp with the department number (dno) 40 and a deletion from the relation dep whichdeletes the department with the number 40, e.g., ∆T = {Iemp(112,
′miller′, 10, 40, 1200),Ddep(40,′sales′,′boston′)}. Furthermore, assume that in the prestate of the transaction noemployee works in the department with number 40. In the transaction’s poststate a violationis present, namely that there exists an employee working in a department which does notexist. This violation is evaluated using the violation query C2. This query determines theset ∆viol
C2of violations of C2 which contains only the tuple (112,′miller′, 10, 40, 1200). Using
∆violC2
we get the following specialized violation relations
• ∆Iemp
C2= {(112,′miller′, 10, 40, 1200)}, and
• ∆Ddep
C2= {(40,′sales′,′boston′)}.
The violation in ∆violC2
is caused by both operations but undoing only one operation, i.e. theinsertion or the deletion, removes this violation. Thus, the violation in ∆viol
C2is ambiguous.
Definition 2.5 (Unambiguous Violation):Let t ∈ ∆viol
C (respectively θ) be a violation of a constraint C in a state σ such that [σ, θ] |=p1(~xp1
) ∧ . . . ∧ p(~xpn) holds. t (respectively θ) is said to be an unambiguous violation if
there exists a violation relation ∆ωC concerning a base relation pi such that for each violation
relation ∆ω′
C , ω′ 6= ω, concerning a base relation pj the condition
[σ, θ] |= ∆ωC(~xpi
) ∧ ¬∆ω′
C(~xpj)
holds. If for the violation t no such violation relation ∆ωC exists, the violation is said to be
ambiguous. 2
Often situations arise where a certain violation from ∆violC cannot be assigned unambiguously
to exact one operation in a specialized violation relation. In particular, for constraints withcomplex bodies, transactions which modify tuples in base relations appearing in these con-straints may cause a lot of ambiguous violations. Note that in contrast to “naive” constraint
6
checking methods it plays an important role in our framework to determine reasons for viola-tions, in particular unambiguous violations, but also properties of violations, e.g., attributevalues of violating tuples. Appropriate reactions on violations can only be performed if vi-olations have been analyzed (in context of the current database state or other violations)and repair actions have been chosen on respective analysis results at run time. This feature,however, has been neglected in other approaches. That is why there often already derivedtriggers have to be refined in order to incorporate more semantics of the application. Inthe following section we discuss how the analysis of violations can easily be integrated intorepair actions.
7
3 Reaction Specifications
In our opinion one of the main reasons why database designer avoid specifying integrityconstraints explicitly (although a wide range of powerful integrity maintaining mechanismswith respective implementations are suggested in the literature, e.g., [EC75, HM75, SV84]), isthe fact that existing integrity checking methods lack on flexibility when handling constraintviolations. If a transaction violates a constraint the complete transaction will be rolled back.Even for single simple violations all other operations of the same transaction will be rolledback. For this, reaction specifications are intended to be means for the database designer toincorporate semantic knowledge on the desired (and also intended) behavior of the databasesystem when constraint violations occur.
In the sequel we discuss the general syntax and semantics of reaction specifications and thenconcentrate on the different patterns of reactions specifying repair actions on constraintviolations.
3.1 Syntax and Semantics
Reaction specifications describe in a declarative way modifications to be performed on thedatabase contents when operations of a certain pattern ω ∈ ∆crit
C violate a constraint Cand, optionally, certain static conditions are met. For this, reactions allow to query thecurrent (inconsistent) database state as well as violations (which are determined by thespecialized violation relations). Based on the query result, e.g., a subset of violating tuplesfrom ∆ω
C, reactions may modify the current database contents in order to remove violations.Similar to an ordinary transaction, a reaction specification consists of a precondition anda postcondition which describe the modifications to perform. In the following we definefour types of reactions which, we think, reflect most of the desired behavior on constraintviolations.
Definition 3.1 (Reaction Specification):Let C ∈ C be an integrity constraint. Furthermore, let ω be a critical operation affecting abase relation p appearing in C, i.e. ω ∈ ∆crit
C , and ∆ωC the corresponding violation relation.
A reaction specification rωC has the general form
rωC ≡ ∆ω
C(x1, . . . , xn) ∧ ϕω � do refuse |set (xj = tj; )
+ | ϕ | do nothing
The variables x1, . . . , xn correspond to the variables ~xp as specified in C. ϕω is an evaluableFOL-formula which may also refer to any (specialized) violation relation ∆ω′
C′ or ∆violC’ . The
conjunction ∆ωC(x1, . . . , xn) ∧ ϕω forms the precondition of the reaction. The postcondition
of a reaction consists of exactly one of the listed “actions” specifying the modifications toperform on the database contents.
i. do refuse specifies to roll back violating operations of the pattern ω from ∆T whichintroduced tuples in the violation relation ∆ω
C,
ii. the expression “set (xj = tj;)+” may change multiple attribute values of violating
tuples in ∆ωC such that xi ∈ {x1, . . . , xn} and ti is a constant or a variable xj 6= xi, xj ∈
{x1, . . . , xn}, or a function having only variables from {x1, . . . , xn} as arguments,
8
iii. ϕ is a FOL-formula consisting of a conjunction of literals which only refer to the baserelations appearing in C. ϕ forms the condition which must hold in the poststateof the reaction. Variables appearing in ϕ must be a subset of the free variables in∆ω
C(x1, . . . , xn) ∧ ϕω, and
iv. do nothing specifies so-called exceptions for violating tuples from ∆ωC. 2
The third type of reaction patterns describe the most general repair action which mayperform arbitrary operations on base relations in case of constraint violations. As we willsee in later sections the first and second type of repair actions describe special cases of thispattern restricted to certain operations.
To give in intuition of how reaction specifications of the different patterns may look we givesome examples. The detailed semantics of these reactions are given in later sections.
Example 3.2: The following reaction specifies that insertions into the relation emp (aspart of a transaction T ) which violate constraint C1 should be rolled back.
rIemp
C1≡ ∆
Iemp
C1(eno, ename, jno, dno, salary) � do refuse
In order to repair violations of constraint C1 which are caused by updates on the relationemp, i.e. violations on the salary, we can utilize the following reaction. This reaction setsthe salary of employees having a salary below 1000 to 1100, thus the constraint is no longerviolated by these tuples.
rUemp
C1≡ ∆
Uemp
C1(eno, ename, jno, dno, salary) � set salary = 1100;
Deleting a department where employees are working for violates the referential integrityconstraint C2. In order to repair such type of violations we can utilize the following reactionwhich specifies to shift employees of the deleted department to a new, already existingdepartment (here the department with number 30):
rDdep
C2≡ ∆
Ddep
C2(dno, dname, location) ∧ emp(eno, ename, jno, dno, salary) �
¬emp(eno, ename, jno, dno, salary) ∧ emp(eno, ename, jno, 30, salary)
According to our first reaction above the following reaction specifies exceptional cases ofviolating insertions into the relation emp, i.e. violations which are “allowed”:
rIemp
C1≡ ∆
Iemp
C1(eno, ename, jno, dno, salary) ∧ dno = 10 � do nothing
Insertions of employees into the relation emp which violate constraint C1 and where theemployees are working in department number 10 are considered as exceptional cases for theconstraint and thus cause no rollback and no modifications of the current database contents.
Note that a reaction specification rωC does not contain any query to check whether or not C
is violated by an operation oi ∈ ∆T of the pattern ω since this is comprised in the evaluationof ∆ω
C. If the (optional) condition ϕω contains a closed formula, the reaction is said to bestate dependent. If only free variables occur in ϕω, the precondition determines a set ofsubstitutions for the variables in ϕω for which the precondition holds (e.g., as the thirdreaction in the example above). These substitutions can be utilized as “parameters” for thepostcondition. The postconditions set(xj = tj;)
+ and ϕ thus can be considered as named
9
procedures which are discussed in detail in the sections 3.2.2 and 3.2.3. There we also explainthe necessity of restricting the variables used in replacements of the form set(xj = tj;)
+.
First, we investigate how ϕω is utilized to restrict the applicability of a reaction to certainviolations and database states:
Definition 3.3 (Reaction Applicability):Let a constraint C be violated in a state σ such that for a violation relation ∆ω
C 6= ∅ holds.A reaction specification rω
C is applicable in σ (to violating tuples in ∆ωC) if there exists
at least one substitution θ for the free variables in φdef⇐⇒ ∆ω
C(x1, . . . , xn) ∧ ϕω such that[σ, θ] |= φ holds. rω
C is said to be completely applicable in σ iff for each substitution θ′
of the free variables in ∆ωC(x1, . . . , xn) such that [σ, θ′] |= ∆ω
C(x1, . . . , xn) holds, there existsa substitution θ ⊇ θ′ of the free variables in φ such that also [σ, θ] |= ∆ω
C(x1, . . . , xn) ⇒[σ, θ] |= φ holds. 2
Inter alia, using an extra condition ϕω the precondition of a reaction determines a subset oftuples in the violation relation ∆ω
C, e.g., those having certain attribute values, on which toapply the modification(s) described in the postcondition (see the fourth case in the exampleabove). In this case we say that the reaction is applicable to these tuples (violations). In thesequel we denote the set of respective substitutions for the free variables in ∆ω
C(x1, . . . , xn)∧ϕω by Θω
C. Of course, the applicability property depends on the current database state whereviolations are processed and hence is in general not (simply syntactically) decidable for agiven reaction specification. It is obvious that reactions which not have a condition ϕω arealways completely applicable in case of respective violations.4
As already mentioned at the end of section 2.3 analyzing violations plays an importantrole for repair actions. For that respective checks can easily be integrated into reactionspecifications by means of preconditions. Thus it is possible to check in the precondition ofa reaction rω
C if in the current state, e.g., a constraint C ′ different from C is violated, too,or if C is also violated by operations of a different pattern ω ′. According to the reactionpattern in definition 3.1 respective preconditions look as follows:
rωC ≡ ∆ω
C(x1, . . . , xn) ∧ ∃x′1, . . . , x′l : ∆viol
C’ (x′1, . . . , x′l) ∧ . . . � . . . , C ′ 6= C
orrωC ≡ ∆ω
C(x1, . . . , xn) ∧ ∃x′1, . . . , x′l : ∆ω′
C(x′1, . . . , x′l) ∧ . . . � . . . , ω′ 6= ω
For a constraint C several reactions on violations can be specified. We denote this set byRC . For each operation pattern ω ∈ ∆crit
C there may exist a reaction specification rωC. But
there may also exist more than only one reaction for the same pattern ω, e.g., there mayexist reactions r1
ωC , r2
ωC ∈ RC . For example, if for a given ω ∈ ∆crit
C the type of reaction shoulddepend on the current state or on different characteristics of the violations, several casesneed to be considered, and more than one reaction concerning ω has to be specified.
4However, as we will see in the sequel, a condition ϕω often is required to assure a certain behavior ofthe repair actions to be performed by a reaction.
10
Example 3.4: For constraint C1 stating that every employee must not earn less than 1000,the preconditions
∆IempC1
(eno, name, jno, dno, salary) ∧ dno = 20 � . . . and
∆IempC1
(eno, name, jno, dno, salary) ∧ dno = 30 � . . .
of reactions on violating insertions of employees depend on the characteristics of the insertedtuples or rather their attribute values. In contrast to this the following two preconditionsspecify reactions which depend on the database state rather than on the properties of theviolations:
∆IempC1
(eno, name, jno, dno, salary) ∧ ∃eno : . . . � . . . and
∆IempC1
(eno, name, jno, dno, salary) ∧ ∀eno : . . . � . . .
However, we require that specifications concerning the same pattern ω are unambiguous ineach inconsistent state σ, i.e. there exists no substitution θ ∈ Θω
C such that both, r1ωC and
r2ωC are applicable to θ. Otherwise there is the possibility that two reactions may perform
different modifications on the database contents concerning the same violating tuples in ∆ωC,
and hence it is not clear which modification to choose. In the previous example the secondpair of preconditions can both be applicable to the same violations in ∆
IempC1
, and thus arenot permitted. The first pair of preconditions, however, always exclude each other.
Definition 3.5 (Unambiguous specifications):Let Rω
C be a set of reaction specifications all concerning the same operation pattern ω. RωC is
said to be unambiguous if in each state σ where C is violated by operations of the patternω the preconditions ϕiω and ϕjω
of each pair of reaction specifications riωC and rj
ωC from Rω
C
exclude each other. 2
This property is more restrictive as it looks at the first moment since there may exist asubstitution θ in a state σ such that [σ, θ] |= ∆ω
C(x1, . . . , xn) ∧ ϕωi∧ ϕωj
holds but the tworeactions ri
ωC and rj
ωC may react different (e.g. for ri
ωC set x1 = t1 and for rj
ωC set x2 = t2),
and hence are somehow of unambiguous. However, in the sequel we require exclusivelyunambiguous sets RC of reaction specifications for a constraint C. To determine whethertwo reactions ri
ωC and rj
ωC are unambiguous one can use proof theoretic procedures to check
if ϕiω ∧ ϕjωis satisfiable.
11
3.2 Pattern of Reaction Specification
A reaction specification describes a state transition from an inconsistent state σ to a newstate σ′. The state σ′, however, must not necessarily be consistent, e.g., repairing a violationof a constraint C may lead to a violation of another constraint C ′. Furthermore, a reactionconsiders only certain violations of a constraint such that after repairing these violationsother violations, in particular of other constraints, may remain. However, a single reactionrωC should guarantee that at least all violations from ∆ω
C on which rωC was applicable in σ
are removed in σ′. Thus reactions have to perform modifications on the current databasecontents in order to satisfy the constraint under consideration. Concerning the four differenttypes of postconditions for reactions, we thus have to restrict the pattern of reactions bydemanding additional preconditions which guarantee the following behavior:
Definition 3.6 (Safe Behavior):Let rω
C be a reaction specification. rωC has a safe behavior if in each state σ where rω
C is appli-cable to tuples (violations) in ∆ω
C, for each θ ∈ ΘωC the condition [σ, θ] |= ∆ω
C(x1, . . . , xn) ⇒[σ′, θ] |= ¬∆ω
C(x1, . . . , xn) holds, i.e. all violations in ∆ωC on which rω
C is applicable in σ areremoved in the poststate σ′ of the reaction. 2
Note that a reaction rωC which has a safe behavior does not necessarily remove other violations
of the constraint C, i.e. violations introduced by operations of a pattern ω ′ different fromω. As mentioned above, a reaction may also violate other constraints. In order to identifypossible interdependencies of reactions and constraints we consider each reaction as an atomictransaction, also having a net effect and a set of operation patterns, i.e. Ip, Up, Dp(p ∈ P).We denote the set of operation patterns occurring in the net effect of a reaction rω
C by op(rωC).
3.2.1 Rollback of Violating Operations
In order to restore (partially) consistency an often desired reaction on a constraint violationis to perform a rollback (undo) only of the violating operations instead of the completetransaction which contains the violating operations. A reaction of the pattern
rωC ≡ ∆ω
C(x1, . . . , xn) ∧ ϕω � do refuse (3)
specifies to undo operations of the patter ω which introduced tuples in ∆ωC and on which rω
C
is applicable. Depending on the pattern ω, rωC formally specifies a state transition as follows:
Definition 3.7 (Partial Rollback):Let rω
C be a reaction specification of the pattern (3) applicable in an inconsistent state σ,determining a set Θω
C of substitutions such that [σ, θ] |= ∆ωC(x1, . . . , xn) ∧ ϕω holds for each
substitution θ ∈ ΘωC. Depending on the pattern ω, rω
C performs a state transition from σ toa new state σ′ such that the following conditions hold:
i. For ω = Ip, i.e. insertions into p ∈ P , p ∈ body(C), for each θ ∈ ΘωC the condition
[σ, θ] |= ∆ωC(x1, . . . , xn) ∧ p(x1, . . . , xn) ⇒ [σ′, θ] |= ¬∆ω
C(x1, . . . , xn) ∧ ¬p(x1, . . . , xn)
holds. Insertions into p on which rωC is applicable are undone, i.e. rω
C performs deletionsof respective tuples in ∆ω
C from the base relation p. Thus op(rωC) = {Dp}.
12
ii. For ω = Up, i.e. updates on p ∈ P , for each θ ∈ ΘωC and each substitution θ′ of the
free variables x′1, . . . , x′n such that [σ, θ + θ′] |= ∆Up
(x′1, . . . , x′n, x1, . . . , xn) holds, the
condition
[σ, θ + θ′] |= ∆ωC(x1, . . . , xn) ∧ p(x1, . . . , xn) ∧∆Up
(x′1, . . . , x′n, x1, . . . , xn) ⇒
[σ′, θ + θ′] |= ¬∆ωC(x1, . . . , xn) ∧ p(x′1, . . . , x
′n) ∧ ¬p(x1, . . . , xn)
holds. Updates on the relation p are undone, i.e. rωC performs deletions of violating
tuples from p on which rωC is applicable and insertions of the corresponding old tuples
(x′1, . . . , x′n) stored in the delta relation ∆Up
. Since we consider only the composedmodifications performed by rω
C (net effect), op(rωC) = {Up}(≡ {Ip, Dp}) holds.
iii. For ω = Dq, i.e. deletions from q ∈ P , q ∈ head(C), for each substitution θ ∈ ΘωC the
condition
[σ, θ] |= ∆ωC(x1, . . . , xn) ∧ ¬q(x1, . . . , xn) ⇒ [σ′, θ] |= ¬∆ω
C(x1, . . . , xn) ∧ q(x1, . . . , xn)
holds. Deletions from q causing a violation of C are undone, i.e. rωC performs re-
insertions of tuples from ∆ωC into q on which rω
C is applicable. Hence op(rωC) = {Iq}
holds.
2
Example 3.8: Consider our constraint C1 stating that an employee must not earn lessthan 1000:
C1 ≡ ∀eno, . . . , dno, salary : emp(eno, . . . , dno, salary) ⇒ salary > 1000
To specify that updating an employees salary below 1000 causes a rollback of the update,i.e. to restore the old salary, we utilize the following reaction specification (ω ≡ U emp):
rωc1≡ ∆ω
c1(eno, . . . , salary) � do refuse
In each state σ where updates on salary cause violations of C1 this reaction is completelyapplicable to all violations in ∆ω
c1. The reaction specification for violating insertions looks
similar. There the pattern U emp has to be replaced by Iemp.
Note that for each pattern ω ∈ {Ip, Up, Dq} partial rollback reactions guarantee a safe be-havior. However, they do not guarantee that new violations of the same constraint may beintroduced. This observation can be restricted to constraints where undos are performed onoperations affecting relations which appear twice in the constraint.
Definition 3.9 (Twin Predicate):Let p be a predicate symbol corresponding to a base relation appearing in a constraint C.p is said to be a twin predicate in C iff p appears in the body and in the head of C. Wedenote the set of twin predicates appearing in a constraint C by twin(C). 2
Example 3.10: Consider for example constraint C3. The predicate head appears in thebody and in the head of the constraint. Undoing a single violation caused by an insertioninto head trivially satisfies the constraint for the violation under consideration, but may alsointroduce a new violation, namely if there exist tuples satisfying the body of the constraintand for which the matching tuple (in the head) herewith was deleted.
13
3.2.2 Attribute Replacement Reactions
In contrast to roll back single violating operations from a transaction, it is sometimes desir-able to modify these operations directly after the transaction in such a way that the modifiedoperations do not introduce inconsistencies any longer. For these often minor replacementson attribute values of tuples modified by violating operations are sufficient, as also suggestedin [FPT93]. To handle violating operations in such a way, we provide reactions of the pattern
rωC ≡ ∆ω
C(x1, . . . , xn) ∧ ϕω � set(xj = tj; )+ (4)
where the expression set(xj = tj; )+ denotes a non-empty set {xi→ti, . . . , xl→tl} of replace-
ments for attribute values {xi, . . . , xl} ⊆ {x1, . . . , xn} of violating tuples. In the followingwe describe the operational semantics of replacement reactions in terms of insert and deleteoperations on the base relation which contains the violating tuples.
Definition 3.11 (Attribute Replacement Reactions):Let rω
C be a reaction specification of the pattern (4) with replacements xi→ ti, . . . , xl→tl (1 ≤ i, l ≤ n). Let rω
C be applicable in an inconsistent state σ, determining a set ΘωC
of substitutions such that [σ, θ] |= ∆ωC(x1, . . . , xn) ∧ ϕω holds for each substitution θ ∈ Θω
C.Depending on the pattern ω, rω
C performs a state transition from σ to a new state σ′ suchthat the following holds:
i. Let ω = Ip, i.e. insertions into p ∈ P , p ∈ body(C). For each θ ∈ ΘωC the condition
[σ, θ] |= ∆ωC(x1, . . . , xn) ∧ p(x1, . . . , xn) ⇒
[σ′, θ] |= ¬∆ωC(x1, . . . , xn) ∧ ¬p(x1, . . . , xn) ∧ p(x1, . . . , ti, . . . , tl, . . . , xn)
holds.
ii. Let ω = Up, i.e. updates on p ∈ P . For each θ ∈ ΘωC the condition
[σ, θ] |= ∆ωC(x1, . . . , xn) ∧ p(x1, . . . , xn) ⇒
[σ′, θ] |= ¬∆ωC(x1, . . . , xn) ∧ p(x1, . . . , ti, . . . , tl, . . . , xn) ∧ ¬p(x1, . . . , xn)
holds.
iii. Let ω = Dq, i.e. deletions from q ∈ P , q ∈ head(C). For each substitution θ ∈ ΘωC the
condition
[σ, θ] |= ∆ωC(x1, . . . , xn) ∧ ¬q(x1, . . . , xn) ⇒
[σ′, θ] |= ¬∆ωC(x1, . . . , xn) ∧ q(x1, . . . , xn) ∧ ¬q(x1, . . . , ti, . . . , tl, . . . , xn)
holds. 2
The affect common to replacement reactions is that the violating operations on which thereaction rω
C is applicable are undone. Therefore these reactions have the same safe behavioras the reactions defined in 3.7 which performed a rollback of single violating operations.But additionally, replacement reactions perform the withdrawn operations with replacedattribute values determined by the terms ti, . . . , tl. For example, if ω = Dq a replacementreaction rω
C performs a re-insertion of deleted tuples into q (on which rωC is applicable) followed
by deletions of tuples from q with attribute values (x1, . . . , ti, . . . , tl, . . . , xn). Due to theimplicit composition of the delete and insert operations on the same relation (net effect), foreach pattern ω ∈ {Ip, Up, Dp} the operation pattern op(rω
C) consists only of a {Up} if not forall variables {x1, . . . , xn} replacements are specified. Otherwise the operation pattern op(rω
C)consists of {Ip, Dp}.
14
Example 3.12: Consider constraint C1. A violation of C1 can only arise if an employee isinserted with a salary below 1000, or, in case of an update, the salary falls bellow 1000. Thefollowing reaction specifies to set the salary of an employee to 1100 in case of a violatingupdate:
rUemp
C1≡ ∆
Uemp
C1(eno, name, jno, dno, salary) � set salary = 1100;
The operation pattern op(rUemp
C1) consists only of {Uemp} since the attribute values for eno,
. . . , dno remain unchanged.
Although replacement reactions remove violations from the violation relation ∆ωC they may
again introduce violations of C. If for constraint C1 above an inconsistency arises due toinserting an employee with a salary less than 1000, only changing the department number(dno) of the inserted employee still violates the constraint. Here, replacing attribute valueshas necessarily to take place on such attributes that are potentially responsible for theviolation under consideration. Of which kind are those attribute values? We thereforeintroduce the term of connection variables:
Definition 3.13 (Connection Variable):Let C be a constraint in INF. Each variable appearing in at least two predicates p and q in Csuch that not both, p and q, appear exclusively in the head of C is a connection variablein C. For an integrity constraint C ∈ C, cv(C) denotes the set of all connection variables inthe constraint. For predicates p1, . . . , pn in C, cv(p1, . . . , ps) denotes the set of all variablescommon in p1(~xp1
), . . . , ps(~xps). 2
In example 3.12 above the variable salary is a connection variable of the underlying constraintC1. Using connection variables we now can refine critical updates as follows:
Theorem 3.14:Let p a predicate corresponding to a base relation appearing in a constraint C. An up-date operation on p can only violate C if at least one connection variable in p is affected,i.e. changed by the update. 2
Proof: We have to distinguish two cases, both based on the notion of join tuples of aconstraint C and the definition of the join operator: 1. case: let t be a join tuple whichsatisfy the constraint C non-trivially in a state σ, i.e. there exists a matching tuple in atleast one relation qj which appears in the head of the constraint. Such a matching tuple isdetermined by the connection variables common to qj and the predicates p1, . . . , pn whichappear in the body of C, i.e. by the variables ~xcv := ~xqj
∩ {~xpi| pi ∈ body(C)}. An
update affecting at least one variable in ~xcv of qj may remove this matching tuple from qj
for the join tuple t, thus C can be violated. Due to the definition of the join operator anyupdate on a predicate pi ∈ body(C), pi ∈ P , such that at least one variable in {cv(pi, pj) |pi, pj ∈ body(C), i 6= j}, i.e. a connection variable in pi, is affected by the update, a newjoin tuple can be build for which no matching tuple in at least one relation ql ∈ head(C)exists, thus may violate C, too. 2. case: let t′ (respectively θ) be a tuple which satisfyC trivially in σ, i.e. [σ, θ] |= ¬(p1(~xp1
) ∧ . . . ∧ pn(~xpn)). Due to the definition of the join
operator any update on a predicate pi ∈ body(C), pi ∈ P , such that at least one variable in{cv(pi, pj) | pi, pj ∈ body(C), i 6= j}, a join tuple can be build for which no matching tuplein at least one relation ql ∈ head(C) exists, thus may violate C.
From this we can derive a necessary condition for safe replacement reactions:
15
Corollary 3.15: Let ∆ωC be a non-empty violation relation in a state σ. A reaction rω
C ofthe pattern
rωC ≡ ∆ω
C(x1, . . . , xn) ∧ ϕω � set(xj = tj;)+
can only remove violations of C by operations of the pattern ω if at least one variable xi tobe replaced by a term ti is a connection variable in C, i.e. xi ∈ cv(C). 2
As described in definition 3.1 the replacement value for a (connection) variable xi can beany term ti. Variables appearing in ti are restricted to the variables x1, . . . , xn in orderto force deterministic replacements. Consider for example a simple precondition of thepattern ∆ω
C(x, y) ∧ q(y, z). For a certain substitution θ of the variables x and y such that[σ, θ] |= ∆ω
C(x, y) holds there may exist more than one substitution θz for the free variablez such that [σ, θ + θz] |= ∆ω
C(x, y) ∧ q(y, z) holds. Then, following definition 3.11, the(operational) semantics of the replacement set(x = f(z)), (f= any function including theidentity), is nondeterministic since the replacement for a certain x depends on the chosensubstitution θz for z, i.e. for an attribute value of one tuple in ∆ω
C there may exist severalreplacements.
Although the above restriction guarantees deterministic replacements, the domain to choosereplacement values from still comprises values which are unsuitable in the sense that newviolations may be introduced. That is why we give some syntactical characteristics forreactions in the sequel, in particular for their preconditions, performing replacements onviolating operations respectively their attribute values. The main property of the reactionsthen will be as follows:
Definition 3.16 (Safe Replacements):Let rω
C be a replacement reaction, ω ∈ {Ip, Up, Dp}. rωC is said to be a safe replacement reac-
tion if, in addition to definition 3.11, in each resulting state σ ′ also [σ′, θ] |= ¬∆Up
C (x1, . . . , xi→ti, . . . , xl→tl, . . . , xn) holds. 2
The main property of a safe replacement reaction rωC is that all violations ∆ω
C on whichrωC is applicable are removed as well as no new violations of the same constraint will be
introduced by the replacements. In order to assure safe replacements we have to restrict thepreconditions of such reactions. We will illustrate these restrictions by an example:
Example 3.17:Assume the following constraint C referring to the base relations p1, p2, q1 and q2:
∀x, y, x : p1(x, y, z) ∧ p2(x, y, z′) ⇒ ∃v, w : q1(v, z
′) ∨ q2(x, y, w)
In each state σ where C is violated, loosely speaking, the “reason” for inconsistencies is thesame: there exists at least one join tuple built by a natural join on the relations p1 and p2
for which no matching tuple in q1 or q2 exists (remember that ∆violC ⊆ Pbody holds). As a
concrete reason, now assume a single violation of C due to an insertion of a tuple, say l, intothe relation p1. There exist three alternatives to restore the consistency of C by replacingthe attribute value for y of the tuple l inserted into p1 (for violations caused by insertionsinto p2 the analogous holds). Common to each of this alternatives is first the deletion of theinserted tuple l (safe behavior). Then one can perform an insertion of the tuple (x, y→t, z)such that
• in case of a join tuple which can be built by the tuple (x, y → t, z) inserted into p1 atleast one matching tuple in q1 or q2 exists such that C becomes non-trivially satisfied.
16
• for the value of t there exists no tuple in p2 having the same attribute value for y. Forthis insertion then no join tuple can be built and hence C becomes trivially satisfied.
• for the value of t there already exists a tuple l′ in p1 − {l} having the same attributevalue for y. Assuming that the insertion under consideration was the only violation ofC then either this tuple l′ is involved in a join tuple or not, in both cases assuring theconsistency of C.5
These alternatives for replacements guarantee, apart from a safe behavior, that the insertionof the tuple (x, t, z) into p1 does not lead to further or new violations of C. Each varianttakes the advantage of identifying inconsistencies by building join tuples. The first variantrequires evaluations including the relations q1 and q2, whereas the last two two variantsexploit the attribute values of the common variable y in p1 and p2, respectively.
We formalize our observations on attribute replacements in the example above in a generalway, taking all critical operation patterns for a constraint into account and also considerviolations in a set oriented way. However, we again have to distinguish critical operationsaffecting predicates in the body and those affecting predicates in the head of a constraint.Let ~xp denote the arguments of a predicate p as specified in a constraint C. The expressionsCbody[xi→ti, . . . , xl→tl] and Chead[xi→ti, . . . , xl→tl] denote the body and the head of theconstraint C, respectively, with replacements of all variables xi, . . . , xl in each predicateappearing in the body (head) by terms ti, . . . , tl. We assume that Cbody[. . .] is not quantified,i.e. all variables in Cbody[. . .] are free.
Proposition 3.18 (Safe replacements on violating insertions/updates):Let C be a constraint with predicates p1, . . . , ps appearing in the body of C. Let rω
C bea reaction concerning a critical operation pattern ω ∈ {Ipt
, Upt}, pt ∈ {p1, . . . , ps}, pt ∈
P and ∆ωC(x1, . . . , xn) the corresponding violation relation. Furthermore, let rω
C specify asubstitution of the variables {xi, . . . , xl} ⊆ {x1, . . . , xn} by the terms ti, . . . , tl such that atleast one xj ∈ {xi, . . . , xl} is a connection variable, i.e. xj ∈ cv(C). Each precondition ofrωC which logically implies one of the listed preconditions ψi assures a safe behavior and safe
replacements on each tuple in ∆ωC on which rω
C is applicable:
i. ψ1 ≡ ∆ωC(x1, . . . , xn) ∧ Cbody[xi→ti, . . . , xl→tl] ⇒ Chead[xi→ti, . . . , xl→tl]
If join tuples can be built such that the updated tuples in pt are involved in the jointuples then matching tuples in at least on relation qj appearing in the head must exist.
ii. ψ2 ≡ ∆ωC(x1, . . . , xn) ∧ ¬Cbody[xi→ti, . . . , xl→tl]
For updated tuples in pt no join tuples can be built, thus C becomes trivially satisfied.
iii. Let xj→tj, . . . , xk→tk denote the maximal subset of replacements xi→ti, . . . , xl→tlspecified in rω
C such that xj, . . . , xk are all connection variables in pt:
ψ3 ≡ ∆ωC(x1, . . . , xn) ∧ ¬∆ω
C(x′1, . . . , xj→tj, . . . , xk→tk, . . . , x′n)
∧ pt(x′1, . . . , xj→tj, . . . , xk→tk, . . . , x
′n)
There already exist non-violating tuples in pt with free variables x′1, . . . , x′n which have
the same attribute values concerning the connection variables.
2
5This alternative mainly reflects the idea of the inconsistency repairing replacement actions presentedin [FPT93] which perform single replacements on attribute values in case of inconsistencies using attributevalues of non-violating tuples.
17
Up to now, we have only considered safe replacements on violations which are caused byinsertions and updates on base relations whose predicate symbol appears in the body ofthe constraint. We now investigate in violations caused by deletions and updates on baserelations appearing in the head of a constraint. It turns out that respective preconditionsfor safe replacements are substantially more restrictive than safe replacements presented inproposition 3.18 above.
Example 3.19: Review our constraint of example 3.17. Assume a violation caused by adeletion (update) on q1, i.e. a matching tuple of a join tuple, say l, has been deleted from q1.The only possibility to accomplish a safe replacement regarding the violating operation is todelete (update) instead a tuple l′ from q1 which is not referred by any join tuple. The deletedtuple l then has to be re-inserted and l has to be restored in case of a violating update onq1, respectively.
Proposition 3.20 (Safe replacements on violating deletions/updates):Let C be a constraint with predicates q1, . . . , qr appearing in the head of C. Let rω
C bea reaction concerning a critical operation pattern ω ∈ {Dqt
, Uqt}, qt ∈ {q1, . . . , qr}, and
∆ωC(x1, . . . , xn) the corresponding violation relation. Furthermore, let rω
C specify a substi-tution of the variables {xi, . . . , xl} ⊆ {x1, . . . , xn} by the terms ti, . . . , tl such that at leastone x ∈ {xi, . . . , xl} is a connection variable in C. Each precondition of rω
C which logicallyimplies the following condition ψ assures a safe behavior and safe replacements on each tuplein ∆ω
C on which rωC is applicable:
ψ ≡ ∆ωC(x1, . . . , xn) ∧ ¬Cbody[xi→ti, . . . , xl→tl]
2
This precondition specifies that for tuples to delete/update instead of the violating tuples inqt no join tuples exist.
Example 3.21: Referring to the constraint in example 3.17 assume a violation by anupdate on the relation q2. The precondition of a reaction specification for safe replacementson violating updates on q2, e.g., replacements of the attribute value y by a term t, looks asfollows (ω ≡ Uq2
)ψ ≡ ∆ω
C(x, y, w) ∧ ¬ (p1(x, t, z) ∧ p2(x, y→t, z′))
Variables which occur in tmust be a subset of variables in {x, y, w}. Based on the operationalsemantics given in definition 3.11 the reaction performs a deletion of each tuple from (x, y, w)from the base relation q2 on which rω
C is applicable followed by insertions of tuples (x, t, w).For each tuple (x, y, w) from ∆ω
C on which rωC is applicable the delta relation ∆Up
contains atuple of the from (x′, y′, w′, x, t, w) in the poststate of the reaction.
Note that the preconditions itemized in proposition 3.18 and 3.20 can be extended by anyfurther (closed) formula in order to analyze the violations in ∆ω
C, to determine replacementsin a certain context or to further restrict safe replacements. Since, e.g., the first preconditionlisted in proposition 3.18 is rather complex, we suggest for each type of precondition suitablespecification templates such that inter alia only a further condition specified by the designerneeds to be added. Thus, simple replacement reactions setting, e.g., default values forattribute values of violating tuples can easily be specified.
18
3.2.3 Propagations
Inconsistencies often arise due to introducing incomplete rather than “false” information.In particular, if many dependencies between and/or within relations in a database schemaexist (e.g., referential dependencies), it is difficult to comply with all such interrelationswhen carrying out large and in particular complex ad-hoc transactions. Often, updatingone relation requires additional updates on other relations in order to preserve consistency[MRC85, AH87, CM89, dB91]. If additional (necessary) modifications are missing within atransaction T but can (easily) be derived from, e.g., operations in T , it seems useful to movethe enforcement of dependencies partially to an automatic mechanism. This strategy thencan be used to realize immediate transaction completions in order to preserve consistency.
Dependencies between and/or within relations in a database schema are specified by meansof integrity constraints. To perform modifications on relations in addition to operations of acertain pattern ω violating such a dependency constraint we provide reaction specificationsof the pattern
rωC ≡ ∆ω
C(x1, . . . , xn) ∧ ϕω � ϕ (5)
which we denote in the sequel as propagations. The modifications to perform in case ofrespective violations are specified in the reaction’s postcondition ϕ which may consist of aconjunction of literals referring only to base relations which appear in C. Positive literals areinterpreted as insertions, negative literals are interpreted as deletions from base relations.Before giving the general semantics for a propagation rω
C like above, we will convey anintuition on how violations of a dependency constraint can be enforced by propagatingmodifications on base relations.
Example 3.22:Given the following constraint referring to the base relations p1, p2, q1 and q2:
C ≡ ∀x, y, z, z′ : p1(x, y, z) ∧ p2(x, y, z′) ⇒ ∃v, w : q1(v, z
′) ∨ q2(x, y, w)
Assume a single violation of C by inserting a tuple, say l, into the relation p1, i.e. ω =Ip1
∈ ∆critC . Then there exist (inter alia) join tuples built by the tuple l for which neither
a matching tuple in q1 nor in q2 exist. In this case a multitude of modifications exist torestore the consistency caused by the violating insertion (undoing or modifying the violatinginsertion itself excluded):
• remove (update) tuples from (in) p2 having the same attribute values for x and y asthe inserted tuple l. This modification reflects the strategy to remove join tuples builtby l such that C becomes trivially satisfied. Note that x and y are connection variablescommon to p1 and p2.
• insert tuples into q1 (q2) which have the same attribute values for z ′ (x, y) as the jointtuples built by l. This modification reflects the idea to satisfy C non-trivially.
• update at least one tuple in q1 (q2) such that the updated tuple “matches” the jointuples built by l. This modification satisfies C non-trivially, too.
It is important to note that these suggested propagations guarantee a safe behavior of therepair actions, i.e. the violations are removed (although new violations can be introduced).
19
Definition 3.23 (Propagations):Let rω
C be a reaction specification of the pattern (5) above. Let rωC be applicable in an
inconsistent state σ, determining a set ΘωC of substitutions such that [σ, θ] |= ∆ω
C(x1, . . . , xn)∧ϕω holds for each substitution θ ∈ Θω
C. The propagation rωC then performs a state transition
leading to a new state σ′ such that the condition [σ, θ] |= ∆ωC(x1, . . . , xn)∧ϕω ⇒ [σ′, θ] |= ϕ
holds for each substitution θ ∈ ΘωC. 2
Remember that due to definition 3.1 each variable appearing in the postcondition ϕ mustbe a free variable which also appears in the applicability condition ∆ω
C(x1, . . . , xn) ∧ ϕω.Allowing, e.g., existentially quantified variables in a postcondition immediately introducesnondeterminism into the construction of the new state σ′ unless suitable strategies are pro-vided to handle such variables, e.g., to determine their values in interaction with the user atrun time.
The semantics given in definition 3.23 is rather declarative than operational. We easilyget the operational semantics when considering a postcondition ϕ as a sequence of (setoriented) operations. The new state σ′ is then obtained by applying the net effect of theinstantiated condition ϕ in the state σ, utilizing the set Θω
C of substitutions. This net effectis also exerted when determining the operation patterns op(rω
C) of a propagation. In op(rωC)
only the net effect or rather the operation patterns of the net effect appears. Assume forexample a propagation with the postcondition ϕ ≡ ¬p(x, y, z)∧p(x, y, z ′)∧¬q(x, y, w). Thenop(rω
C) = {Up, Dq} holds. More formally, the net effect of ϕ contains an operation patternUp iff ϕ contains the literals ¬p(~x) and p(~y) such that the intersection ~x ∩ ~y is non-empty.It contains the pattern Ip iff ϕ contains a literal of the pattern p(~x) such that for no otherliteral ¬p(~y) in ϕ the condition ~x∩ ~y 6= ∅ holds. For the pattern Dp in op(rω
C) the analogousconditions holds.6
Due to “arbitrary” postconditions in propagations, i.e. modifications on any base relationappearing in C, even a safe behavior cannot be guaranteed. Hence it is desirable to restrictpropagation specifications such that also [σ′, θ] |= ¬∆ω
C(x1, . . . , xn) holds in σ′ for eachsubstitution θ ∈ Θω
C (e.g. as illustrated in example 3.22). Since it is also desirable that thespecified modifications in rω
C do not introduce further violations of the same constraint wenow give criteria on propagations for which |∆viol
C |σ ≥ |∆violC |σ′ holds, i.e. the number of
violations of C in σ′ declines. We denote propagations ensuring this two properties as safepropagations which we formally describe in the sequel, again dependent on the pattern ω ofthe violating operation.
Proposition 3.24 (Safe propagations on violating insertions/updates (I)):Let C be a constraint with predicates p1, . . . , ps appearing in the body of C and predicatesq1, . . . , qr appearing in the head of C. Let rω
C be a reaction concerning a critical operationpattern ω ∈ {Ipt
, Upt}, pt ∈ {p1, . . . , ps}. Let ~xpi
and ~yqjdenote the arguments of the
predicate pi and qj in C, respectively. Each of the following pattern for rωC assures a safe
behavior and that no further violations of C are introduced:
i. Let pi ∈ {p1, . . . , ps}, pi 6= pt, a base relation such that cv(pt, pi) 6= ∅. Then
rωC ≡ ∆ω
C(x1, . . . , xn) ∧ pi(~xpi) � ¬pi(~xpi
)
assures a safe propagation. The operation pattern for rωC is op(rω
C) = {Dpi}.
6This property, however, can be refined by taking, e.g., primary key attributes into account.
20
ii. Let I = {i1, . . . , ik} be a non-empty index set of a subset of predicates correspondingto base relations appearing in the body of C such that t 6∈ I. Then
rωC ≡ ∆ω
C(x1, . . . , xn) ∧s∧
u=1
u6=t
pu(~xpu) �
∧
i∈I
¬pi(~xpi)
assures a safe propagation. The operation patterns for rωC is op(rω
C) = {Dpi| i ∈ I}. 2
Safe propagations of the first pattern reflect the strategy to delete those tuples from a baserelation pi which participate in join tuples built by the violating insertions (updates) in (on)pt. These tuples from pi are determined by utilizing the connection variables common to pt
and pi as given in the specification of C. Thus, for a single violation from ∆ωC several deletions
from a single relation pi may be performed. To delete tuples from relations which participatein join tuples but for which no connection variables common to variables in {x1, . . . , xn} exist,we provide safe propagations of the second pattern. This pattern comprises propagationsof the pattern (i) if I = {i} but requires an evaluation of join tuples over the relationsp1, . . . , ps.
Example 3.25: Referring to the constraint in example 3.22
C ≡ ∀x, y, z, z′ : p1(x, y, z) ∧ p2(x, y, z′) ⇒ ∃v, w : q1(v, z
′) ∨ q2(x, y, w)
the following propagation on violating insertions into p1 deletes those tuples from the relationp2 which are involved in join tuples built by the violating insertions (ω ≡ Ip1
):
rωC ≡ ∆ω
C(x, y, z) ∧ p2(x, y, z′) � ¬p2(x, y, z
′)
It is obvious that deletions of respective tuples from the relation p2 trivially satisfy theconstraint with respect to violating insertions into p1.
Safe propagations like above are rather straightforward since they trivially satisfy the con-straint C for each violation in ∆ω
C (they are also always completely applicable). As illustratedin example 3.22 it is also possible to perform updates on relations engaged in join tuplesbuilt by violating insertions and updates, respectively. In section 3.2.2 we already exam-ined how to specify safe replacements on attribute values of tuples introduced by violatingoperations. Here now, attribute replacements can take place on any tuples participatingin join tuples built by violating insertions (updates). Consider for example the followingfigure (fig. 1) depicting join tuples over relations p1, . . . , ps which are built by a tuple l ∈ pt
(under the simplified assumption that for each pi(i = 1, . . . , s−1), cv(pi, pi+1) 6= ∅ andcv(pi, pj) = ∅ for i 6= j + 1 holds):
��
� �
�� �
��
��
� �
�� �
��
��
�
��
�
��
�
��
�
��
� �
��
��
� �
��
��
� �
�� �
��
@@��
��
���
aaLLLL
@@��
TTT
pt
pspt+1
. . .
. . .
. . .
t1
t2
t′1
t′2
t′3
l
. . .
. . .
. . .
p1 pt−1
Figure 1: Join tuples built by a tuple l ∈ pt
21
Updates on relations pi ∈ P (pi 6= pt) can then be subdivided into updates where cv(pt, pi) 6=∅, i.e. updates on pt−1 or pt+1, and updates where cv(pt, pi) = ∅. To assure safe propagationsboth types of updates must guarantee for the new state σ′ that, if join tuples exist which arebuilt by an updated tuple, matching tuples in relations qj appearing in the head must exist.In analogy to proposition 3.24 these requirements can be formulated by means of a precon-dition. In the following the expression p(~xp[xi→ti, . . . , xl→tl]) denotes the replacements ofall variables in ~xp ∩ {xi, . . . , xl} by the terms ti, . . . tl.
Proposition 3.26 (Safe propagations on violating insertions/updates (II)):Let C be a constraint and rω
C a reaction as in proposition 3.24. Let ~xpiand ~yqj
denotethe arguments of the predicate pi and pj in C, respectively. Let xi→ti, . . . , xl→tl specifya substitution of the variables xi, . . . , xl in pj by terms ti, . . . , tl such that at least onex ∈ {xi, . . . , xl} is a connection variable. The pattern
rωC ≡ ∆ω
C(x1, . . . , xn) ∧s∧
u=1
u6=t
pu(~xpu) ∧ (Cbody[xi→ti, . . . , xl→tl] ⇒ ∃~y : Chead[xi→ti, . . . , xl→tl])
� ¬pj(~xpj) ∧ pj(~xpj
[xi→ti, . . . , xl→tl])
for the reaction rωC assures a safe propagation. Due to the composed operations on the
relation pj specified in the postcondition op(rωC) = {Upj
} holds.2
The first disjunction determines all tuples from relations pu 6= pt involved in join tuplesdetermined by tuples of the violation relation ∆ω
C. The implication requires that for jointuples (determined by substitution of the free variables in the first conjunction) which canbe built based on the specified replacements, matching tuples in at least one relation qu
appearing in the head of C must exist.
Example 3.27: Assume that for the constraint
C ≡ ∀x, y, z, z′ : p1(x, y, z) ∧ p2(x, y, z′) ⇒ ∃v, w : q1(v, z
′) ∨ q2(x, y, w)
in case of violating insertions into p1 replacements of attribute values of these tuples shouldbe performed which are involved in respective join tuples. For the constraint above the onlypossibility are replacements on tuples in p2. Such replacements have to take place at leastat one connection variable. In C all the variables in p2(x, y, z
′) are connection variables. Wechoose the attribute value for z′ to be replaced by the term t, i.e. z ′→t. Based on proposition3.26 we thus get the following propagation (ω ≡ Ip1
):
rωC ≡ ∆ω
C(x, y, z) ∧ p2(x, y, z′) ∧ (p1(x, y, z) ∧ p2(x, y, t) ⇒ ∃v, w : q1(v, t) ∨ q2(x, y, w))
� ¬p2(x, y, z′) ∧ p2(x, y, t)
This reaction assures a safe propagation since for new join tuples built by p1(x, y, z) ∧p2(x, y, t) matching tuples in q1 must exist.
Up to now the proposed propagations take only place on base relations appearing in the bodyof the violated constraint. A illustrated in example 3.22 another possibility is to satisfy theconstraint non-trivially by performing operations on base relations appearing in the head ofthe constraint.
Again, respective safe propagations are substantially more restrictive than the previouslydiscussed propagations. Here, the problems arise due to (possible) existentially quantified
22
variables in the head. If in case of a violation by an operation on a base relation pi a matchingtuple should be inserted into a base relation qj, the values of existentially quantified variables(substitutions) have to be determined. A simple solution, of course, is to use default valuesfor these variables, e.g., determined by constants or functions.
Proposition 3.28 (Safe propagations on violating insertions/updates (III)):Let C be a constraint and rω
C a reaction as in proposition 3.24. Let I = {i1, . . . , ik} a non-empty index set of a subset of predicates corresponding to base relations which appear inthe head of C. Furthermore, let ~tqj
= {t1, . . . , tl} denote a replacement of all existentiallyquantified variables appearing in qj, j ∈ I, such that variables in a term ti correspond to thefree variables in C. A reaction of the pattern
rωC ≡ ∆ω
C(x1, . . . , xn) ∧s∧
u=1
u6=t
pu(~xpu) �
∧
i∈I
qj(~xqj,~tqj
)
assures a safe propagation. The operation patterns for rωC is the set {Iqj
| i ∈ I}. 2
Another, more flexible approach to determine existentially quantified variables for a prop-agation is to ask the user for these values of the variables at run time. A requirement forthis is to explain each violation under consideration, i.e. each tuple from ∆ω
C. Of course,this approach makes only sense and is only acceptable if always a few violations in ∆ω
C arepresent.
In case C has no existentially quantified variables, i.e. if we have a constraint of the pattern
∀~x : p1(~xp1) ∧ . . . ∧ pn(~xpn
) ⇒ q1(~xq1) ∨ . . . ∨ qm(~xqm
)
there is no need to use default values. All values for the tuples to be inserted into the baserelation qj can be determined automatically. Referring to safe propagations presented inproposition 3.28 a respective safe propagation then has the pattern
rωC ≡ ∆ω
C(x1, . . . , xn) ∧s∧
u=1
u6=t
pu(~xpu) �
∧
i∈I
qi(~xqi)
A further possibility of a safe propagation performing modifications on base relation qi areattribute replacements. For this the idea is to update tuples in (at least one relation) qi suchthat the new values of the updated tuples match at least all join tuples built by violations.In order to avoid introducing new violations of the same constraint, however, there exists animportant requirement: tuples to be updated in qi must not match any join tuple (note thatfor a join tuple there may exist matching tuples in more than only one relation qi ∈ head(C)).
We finally turn to violating deletions and updates on relations appearing in the head of aconstraint. For this consider again the constraint in example 3.22.
Example 3.29: Assume a violation of C by deleting a tuple, say l, from the relation q1.There exist the following alternatives to restore the consistency of C concerning this violatingoperation:
• delete (update) tuples from (in) p1 and/or p2 involved in the join tuples for which thematching tuple l was deleted. In case of deletions from p1 and/or p2 the constraint
23
becomes trivially satisfied. In case of updates on p1 and/or p2 the constraint eitherbecomes trivially satisfied (no join tuple can be built by the updated tuple) or theconstraint becomes non-trivially satisfied if a matching tuple in q1 or q2 exists.
• insert (update) tuples in q1 and/or q2 such that the new tuples match the join tuplesfor which the matching tuple l was deleted. Thus the constraint becomes non-triviallysatisfied.
Since only safe propagations for the first case are relevant for most practical applications werestrict the proposed reaction pattern to this case.
Proposition 3.30 (Safe propagations on violating deletions/updates):Let C be a constraint with predicates p1, . . . , ps appearing in the body of C and predicatesq1, . . . , qr appearing in the head of C. Let rω
C be a reaction concerning a critical operationpattern ω ∈ {Dqt
, Uqt}, qt ∈ {q1, . . . , qr}, qt ∈ P . Let ~xpi
and ~yqjdenote the arguments of
the predicates pi and qj, respectively, as specified in the constraint C. Each of the followingpattern for rω
C assures a safe propagation:
i. Let I a non-empty index set of predicates from {p1, . . . , ps} such that there exists aj ∈ I with cv(qt, pj) 6= ∅ and (optionally) there exists an order {i1, . . . , ik} on theelements in I such that cv(pj, pj+1) 6= ∅ for j = i1, . . . , ik. Furthermore, let I ′ be anon-empty subset of I such that each element in I ′ corresponds to the index of a baserelation which appear in the body.
rωC ≡ ∆ω
C(x1, . . . , xn) ∧(∧
i∈I
pi(~xpi))�( ∧
i∈I′
¬pi(~xpi))
Deletions of all tuples involved in join tuples for which no matching tuples in the relationqt exist trivially satisfy the constraint. Here, op(rω
C) = {Dpi| i ∈ I ′}.
ii. Let {xi→ ti, . . . , xl → tl} denote a substitution of the variables in a predicate pj ∈{p1, . . . , ps} such that cv(pj, qt) 6= ∅ holds:
rωC ≡ ∆ω
C(x1, . . . , xn) ∧ (Cbody[xi→ti, . . . , xl→tl] ⇒ ∃~y : Chead[xi→ti, . . . , xl→tl])� ¬pj(~xpj
) ∧ pj(~xpj[xi→ti, . . . , xl→tl])
Updated tuples in pj for which join tuples can be built a matching tuple in at least onerelation qu must exist. Due to the composition of the insert and delete operation on pj
op(rωC) = {Upj
} holds if ~xpj∩{~xpj
[xi→ti, . . . , xl→tl]} 6= ∅, otherwise op(rωC) = {Dpj
, Ipj}
holds.
2
A very common reaction on constraint violations, in particular on violations of referentialintegrity constraints, are cascading deletions as already suggested in SQL2 [DD93] and alsoprovided by commercial database systems like, e.g., Oracle or SYBASE. The first type ofpropagations listed in proposition 3.30 above specifies cascading deletions if I = {1, . . . , s},qt is a twin predicate in C and I ′ = {t} like in the following example.
24
Example 3.31: Recall constraint C3 from our example database stating that every man-ager again must have a manager. In C3 head is a twin predicate:
C3 ≡ ∀mgrno, eno : head(mgrno, eno) ⇒ ∃mgrno′ : head(mgrno′,mgrno)
According to the pattern (i) in proposition 3.30 the following reaction specifies a cascadingdeletion as a reaction on violating deletions from the relation head, i.e. ω = Dhead:
rωC3≡ ∆ω
C3(mgrno′,mgrno) ∧ head(mgrno, eno) � ¬head(mgrno, eno)
Another very common type of propagations are those described by the second pattern.
Example 3.32: Recall constraint C2 stating that every employee has to work in an existingdepartment. Volation of C2 are deletions of departments where some employees are yetworking for and thus are violating the foreign key constraint. According to pattern (ii) inproposition 3.30 the following reaction specifies to assign to all employees affected by sucha violation another, existing department (ω = Ddept):
rωC2≡ ∆C2
(dno, dname, location) ∧ [∗] ∧ (emp(eno, dno→dno′, salary) ⇒∃dname′, location′ : dept(dno′, dname′, location′))
� ¬emp(eno, . . . , dno, salary) ∧ emp(eno, . . . , dno′, salary)
The number dno′ of the new department for the employees can, e.g., directly be specified bya constant or it can be determined by a condition exploiting the current database state asfollows
[∗] ≡ prj(pno, pname, 1001, dno′)
Through this, all employees affected by violating deletions are assigned to the departmentwhere the employee with number eno = 1001 leads a project.
For such type of propagation it is important to note that if the predicate pi is a twin predicatein the underlying constraint, cascading updates can be specified.
As suggested for safe replacements the specification of safe propagations should be supportedby suitable specification templates, too. For safe propagations presented in proposition3.24 (ii) it is sufficient that the designer only gives the index I of predicates to consider.Analogously, for safe propagations suggested in proposition 3.26 it is sufficient to determineonly the predicate pj with respective replacements of attribute values.
3.2.4 Exceptions
Integrity constraints modelled from the scratch sometimes express desired properties of adatabase like, e.g., “normally, an employee leading a project in a department must also workin this department”. In contrast to constraints specifying structural properties of relations,e.g., primary key conditions, such constraints often have exceptional cases which need to beexpressed. Typically, these cases are encoded within the constraint specification itself. Thisstrategy, however, may lead to complex specifications, in particular when exceptional cases
25
depend on certain different and complex properties of database states. In order to simplifythe specification and maintenance of exceptional cases we provide reactions of the pattern
rωC ≡ ∆ω
C(x1, . . . , xn) ∧ ϕω � do nothing (6)
Such type of reactions, here simply called exceptions, specify to consider all violations ofthe pattern ω of the constraint C on which rω
C is applicable as exceptional cases for theconstraint. The reaction has no effect, i.e. no modifications on the database contents areperformed, thus op(rω
C) = ∅.
Formally, specifying an exception to a constraint C corresponds to the introduction of apredicate exceptC as follows:
Definition 3.33 (Exceptions):Let C be a constraint with universally quantified variables x′1, . . . , x
′m and let rω1
C , . . . , rωs
C
be reactions which specify exceptional cases for C. Let ΘC be a set of substitutions for thefree variables in C such that [σ, θ] |= C holds for each substitution θ ∈ ΘC in a state σ whereC is violated. For the exception predicate exceptC with arguments x′1, . . . , x
′m then
[σ, θ] |= exceptC(x′1, . . . , x′m)
def⇐⇒ [σ, θ + θ′] |= C ∧
(s∨
i=1
(∆ωi
C(x1, . . . , xn) ∧ ϕωi)
)(7)
holds. θ′ denotes a substitution of the free variables in each part ϕωi of a precondition of areaction specification rωi
C .7 2
A constraint C for which exceptions of the pattern (6) are specified is formally extended toC ′ ≡ C ∨ exceptC(x′1, . . . , x
′m). Note that introducing this modified constraint specification
is necessary to describe a database state which is consistent with respect to all constraintsspecified in the database schema. In principle, each constraint C ∈ C can be extended by anexception predicate. In order to allow querying exceptional cases of constraint, i.e. violationinstances, the database schema is extended by this predicate for each constraint C ∈ C forwhich at least one exception has been specified.
Example 3.34: For constraint C1 of our example database specifying that an employeemust earn more than 1000 the exception
rωC1≡ ∆ω
C1(eno, name, jno, dno, salary) ∧ job(jno, title, paygrade)
∧ title =′Salesman′ � do nothing, (ω = Iemp or ω = Uemp)
specifies that employees which are salesmen may earn less than 1000, i.e. they are exceptionalcases for constraint C1.
Apart from the easy way to specify exceptional cases of constraint violations, handling ex-ceptions as separate specifications has another important advantage. Rather than to compilea full constraint specification which has already been explicitly extended by exceptions intotriggers, exceptions given by reaction specifications can be compiled into corresponding trig-gers independently.
7Note that also [σ, θ] |= exceptC(x′
1, . . . , x′
m) ⇒ [σ, θ] |= ∆violC (x′
1, . . . , x′
m) holds, i.e. exceptC is a subsetof ∆viol
C .
26
Thus exceptions of a constraint can simply be added or withdrawn during run time, e.g., if adesired behavior specified by exceptions becomes consolidated such that exceptions for theconstraint (specifying the desired behavior) are not longer allowed (note that by adding toomuch exceptions to a constraint, the constraint itself can become superfluous.)
3.3 Default Reactions on Constraint Violations
The different types of reaction specifications we have discussed in the previous sections up tonow describe explicitly when and how to react on constraint violations of certain patterns.For each possible violation of a constraint C, i.e. for each operation pattern ω ∈ ∆viol
C ,there need not exist a respective reaction explicitly. In real applications often constraintsmay exist which can only be preserved by rolling back the complete faulty transaction.Although possible repair actions can be (formally) given, these reactions then do not reflectthe designer’s intention or the application requirements.
Given a reaction specification rωC for a constraint C at run time there may as well exist
violating operations of a certain pattern ω, for which rωC is not applicable. To guarantee in
such cases that every ad-hoc transaction nevertheless results in a consistent state (in theworst case by rolling back the complete transaction), we assume for each constraint C ∈ Ca default reaction as follows:
Definition 3.35 (Default Reaction):For a constraint C ∈ C let RC = {r1
ω1
C , r2ω1
C , . . . , rlωs
C } be a set of reaction specifications whichtake a subset reactC = {ω1, . . . , ωs} ⊆ ∆crit
C into account. Let σ0 be a consistent databasestate in which a transaction T is performed leading to a state σ. Let σ ′ be an arbitrarystate reached from σ by performing reactions on violations. For C a set Rdefault
C of defaultreactions is assumed such that in each state σ′ in which C is violated, a reaction fromRdefault
C performs a complete rollback to the state σ0 if
i. there exists at least one tuple in a violation relation ∆ωC in σ′, such that ω 6∈ reactC , or
ii. there exists at least one tuple in a violation relation ∆ωC, ω ∈ reactC , for which no
explicitly specified reaction in RC is applicable in σ′. 2
Default reactions on constraint violations are implicitly assumed and complete the consis-tency enforcement process specified by reactions in a well defined way. They describe how tobehave in a repair process in presence of violations which cannot be repaired by the specifiedreactions. For later implementations of default reactions for a constraint C these reactionshave to be subdivided into two classes: those corresponding to definition 3.35 item (i) andthose corresponding to item (ii).
Let RC be a set of reaction specifications as in definition 3.35 above. The first type of defaultreactions, containing only a reaction dC is defined as follows
dC ≡∨
ωi 6∈reactC
∃~xp : ∆ωi
C(~xp) � rollback, ωi operation patterns on relation p (8)
The clause rollback in the postcondition specifies a normal rollback to the state σ0. Thesecond type comprises reactions for operations of the pattern ω ∈ reactC , and is defined asfollows:
dωC ≡ ∃x1, . . . , xn : ∆ω
C(x1, . . . , xn) ∧ ¬ϕ � rollback, (9)
27
where ϕ is the disjunction of all precondition parts ϕω of reactions concerning the criticaloperation pattern ω. Note that default reactions for a constraint C are not an explicit partof the specifications in RC . They can easily be derived from the reaction specifications inRC as illustrated in (8) and (9).
28
4 Analyzing and Structuring Reactions
In view of acceptance of inconsistency repairing triggers there exist two substantial demands:In an inconsistent state these triggers should guarantee termination in a consistent state,but they also should guarantee a deterministic and observable behavior concerning the re-pair process. Therefore an important prerequisite for the trigger derivation process is thatconstraints and corresponding reactions have to be specified by the designer in a stepwisemanner and that they have to be analyzed carefully in the context of previous specifica-tions. Integrity constraints have to be checked for redundancies, inconsistencies and alsofor implicit constraints which are logically implied by the specified constraints. For criticaloperations, i.e. operations which may invalidate the specified constraints, the designer thencan specify reactions on possible violations according to the application requirements andimposed restrictions. Reactions are examined for “local consistency”, i.e. if they are in gen-eral applicable to violations and not contradicting each other. With regard to the demandof determinism of a repair process a set of reactions has in particular to be analyzed whetheror not it is confluent. A set of reactions (triggers) is said to be confluent if, for every initialstate σ, every valid and complete execution sequence of repair actions beginning in σ hasthe same final state [AWH92].
In the sequel we first describe which dependencies between constraints may be present due tospecified reactions and how integrity constraints and reactions are integrated into so-calleddependency graphs, which build the basis for the trigger derivation process. To incorporatefurther semantic knowledge into the trigger derivation, we then examine the need of speci-fying weights on reactions and cycles in dependency graphs. We conclude this section by adiscussion on suitable design strategies for the reactive behavior and requirements on toolssupporting this design process.
4.1 Dependency Graphs
Having many integrity constraints and corresponding reactions on violations, a lot of de-pendencies between constraints and reactions may be present. For instance, a reaction on aconstraint violation may perform modifications on the current database contents and thusmay violate other constraints. To avoid repeated evaluations of violations of the same con-straint, it is desirable to check a constraint C not until all other constraints which may“influence” the validity of C (due to repair actions) have been checked and respective viola-tions perhaps have been repaired (we denote this policy as lazy violation evaluation strategy).Concerning the proposed patterns of reaction specifications, we can identify the followingtypes of dependencies:
Definition 4.1 (Dependencies):Let C and C ′ be two integrity constraints from C with corresponding sets RC and RC′ ofreaction specifications. C ′ depends
• negatively on C if there exists an operation pattern ω ′ ∈ op(rωC) such that ω′ ∈ ∆crit
C′ .
• positively on C if there exists a predicate pi ∈ P appearing in the body of C ′ and areaction rω
C ∈ RC such that {Dpi, Upi
} ∩ op(rωC) 6= ∅, or there exists a predicate qj ∈ P
appearing in the head of C ′ and a reaction rωC ∈ RC such that {Iqj
, Uqj} ∩ op(rω
C) 6= ∅.
29
• inherently on C if there exists a reaction specification rωC’ ∈ RC′ with a condition ϕω
and a reaction specification rωC ∈ RC such rω
C performs modifications on base relationsappearing in ϕω 2
Although negative dependencies between constraints are the most evident, their numberdecreases if safe replacements/propagations are used to specify repair actions. Thus, atleast the number of constraints which depend negatively on itself can be reduced. However,this attribute may be dependent on the respective application. Positive dependencies reflectthe (sometimes) useful property of a reaction rω
C to remove not only violations of C, butalso some violations of another constraint C ′. For this consider the following concrete case:let C1, . . . , Ck be constraints of the pattern Ci ≡ ∀~x : p1(~xp1
) ∧ . . . pn(~xpn) ⇒ ∃~yi :
qi(~xqi, ~yqi
), (i = 1, . . . , k) derived from a constraint C of the pattern ∀~x : p1(~xp1) ∧ . . . ∧
pn(~xpn) ⇒ ∃~y : q1(~xq1
, ~yq1)∧. . .∧qk(~xqk
, ~yqk). If at least for one constraint Ci a corresponding
repair action trivially satisfies Ci, i.e. by removing tuples from a relation pi ∈ {p1, . . . , pn},all other constraints Cj 6= Ci become trivially satisfied, too.
In other work on inconsistency repair actions, e.g., [FPT93], this property has not been takeninto account. Only in [UKN92] this property is (inherently) encapsulated in their constraintgraphs, there as so-called co-dominating clauses which exactly correspond to the clauses (orrather constraints) C1, . . . , Ck above.
The third type of dependencies, denoted as inherent dependencies, results rather from thepattern of reactions than from the corresponding constraints. Assume for instance a reactionrωC with a precondition ϕω ≡ ∃x, y : q(x, y) ∧ x > y, i.e. a state dependent applicability
condition. Note that q need not occur in C ′ itself. Any reaction rω′
C’ which performs operationson the relation q now can influence the applicability condition of rω
C, e.g., by removing thelast tuple from q for which x > y holds.
Note that the dependency properties rest only on (static) examinations of the syntax ofconstraint and reaction specifications. Whether or not a certain reaction in fact, e.g., violatesa constraint can only be determined at run time. Of course, there may exist a constraintC ′ which depends negatively on a constraint C due to a reaction rω
C (or rather op(rωC)),
but rωC can never invalidate C ′ in case of a violation of C, since no “critical instances”
will ever occur. But this attribute may vary from application to application and specifiedreactions, respectively. That is why we consider only dependencies which are obvious due tothe specifications.
All dependencies which can be determined from the given constraint and reaction specifica-tions are now incorporated into a so-called dependency graph, a structure which builds thebasis for the trigger derivation process, but which is also utilized to represent interdepen-dencies to the designer:
Definition 4.2 (Dependency Graph):A dependency graph DG for a set C of integrity constraints in INF and a set {RC | C ∈ C}of reaction specifications is a pair DG =< V,E > where V is a finite set of nodes andE ⊆ V ×V is a set of directed edges such that each node v ∈ V is labelled with a constraintC ∈ C such that the labelling function ν : V → C is a bijection. Edges are labelled with theidentifier of a reaction.
There exists a directed edge e = (v, v′) labelled with rωC from a node v with ν(v) = C to a
node v′ with ν(v′) = C ′ iff C ′ depends positively, negatively or inherently on C due to rωC. 2
30
A dependency graph intuitively reflects the order when constraints have to be checked beforeother constraints. Two types of nodes can in particular be distinguished in a dependencygraph: those nodes which have no ingoing edges, denoted as initial nodes, and nodes with nooutgoing edges to other nodes, denoted as final nodes. These nodes correspond to constraintswhich cannot be violated by repair actions and to constraints for which no repair actionsexist or specified repair actions cannot violate any (other) constraint.
Another feature of a dependency graph is that it can be separated into n maximal connectedsubgraphs DG1, . . . , DGn. A subgraph DGi =< Vi, Ei >, Vi ⊆ V,Ei ⊆ E is said to beconnected if each node v ∈ Vi can be reached from a different node v′ ∈ Vi when consideringedges in DGi as non-directed.
The following picture illustrates an example of a typical dependency graph structure for aset C of constraints and a set RC of reactions (edge labels are omitted):
�����
�
��
� �
��
��
�
��
�
��
�
��
�
��
�
��
� �
��
?
QQQs
.
���= ��=
?
ZZZ~
6�
��=
ZZZ~
ZZ~C5
C0
C1
C2
C3 C4
C6C7
C8
C9
Figure 2: Dependency Graph
In this graph three maximal connected subgraphs can be identified (using respective nodelabels):
• DG1 = {C7}• DG2 = {C0, . . . , C6}• DG3 = {C8, C9}
DG1 corresponds to constraint C7 which cannot be violated by any specified repair actionand for which no explicit repair action exists. In DG3 there exists a repair action forconstraint C8 which may again violate C8. Concerning a loop label at a node v, ν(v) = C,we can distinguish between reactions specifying cascading deletions or updates, i.e. for whichω ∈ op(rω
C) and ω ∈ reactC holds, and reactions which may invalidate C by an operationpattern ω′ for which no (other) reaction rω
′
C exists, i.e. only the default reaction dC is assumed.
An important property of maximal connected subgraphs is that they are pairwise confluent(for the notion of confluent rule sets see also [AWH92]):
Definition 4.3 (Confluent Subgraphs):Let DG1 =<V1, E1> and DG2 =<V2, E2> two maximal connected subgraphs of a depen-dency graph DG =<V,E> such that Vi ⊆ V,Ei ⊆ E, (i = 1, 2), E1∩E2 = ∅ and V1∩V2 = ∅.Let σ be any inconsistent database state. The pair of subgraphs DG1 and DG2 is said tobe confluent if applying repair actions on a constraint covered in DG1 before applying arepair action on a constraint in DG2 results in the same state σ′ as processing the other wayaround. 2
31
Theorem 4.4:Any pair of Maximal connected subgraphs in a dependency graph is confluent. 2
This result can be derived directly from the commutativity property of rules as discussedin [AWH92]. In our case rules are given in form of reaction specifications. If there existsa reaction specification rω
C in a subgraph DG1 which does not commute with a reactionspecification rω
C’ in a subgraph DG2 then these two subgraphs are not confluent.
Thus, for confluent subgraphs there exists at most one final state σ ′ which is independentof the chosen order on starting processing repair actions in one or another graph. Considerfor instance our graph in figure 2. If in a state σ both, C3 and C8 are violated, applyingrespective repair reactions on C3 before those on C8 (and so on) leads to the same state σ′
as applying repair reactions on C8 before those on C3 (and so on).
In the sequel we restrict our considerations to a single maximal connected subgraph. Theapproaches presented can be applied analogously to each such subgraph. That is why wealso use the term dependency graph instead of maximal connected subgraph.
4.2 Ordering Reactions
For a single constraint a lot of reactions may be specified, in particular several unambiguousreactions for the same operation pattern ω ∈ ∆crit
C , like in example 3.4. Our next goal is toimpose a total order on reactions for a single constraint. This order comprises also defaultreactions as discussed in section 3.3. To obtain such an order we choose a designer drivenapproach since (s)he is the only one who has the “semantic knowledge” of the applicationand the specified repair reactions. Other approaches, e.g., in [FPT93] utilize heuristicsto incorporate semantic knowledge on the execution order of repair actions, thus possiblyrequiring refinements and revisions of automatically generated triggers afterwards.
Two items need to be considered when imposing an order (weight) on repair actions: possibleambiguous violations and when to consider default reactions. Ambiguous violations are themost critical point when processing repair actions. Consider for instance our constraint inexample 2.4. Assume a transaction T comprising a violating insertion and deletion, bothdetermining the same join tuple from ∆viol
C , which thus is an ambiguous violation. If, e.g.,for both, violating insertions and deletions, partial rollbacks are specified a rollback of theviolating insertion results in a state which is different from rolling back the violating deletionfirst. Thus, repairing can be nondeterministic, depending on the choice of reaction order,and hence a weight has to be assigned to each reaction. Default reactions are also influencedby ambiguous violations. Assume, e.g., that for violating insertions above no repair actionexists, i.e. the default reaction dC takes this operation pattern into account. In case of aviolation of C like above, performing dC first results in a complete rollback of the transactionT whereas by rolling back the violating deletion first dC becomes non-applicable. Thus, thetime when to check for a default reaction dC can reflect two different strategies, a scepticalone and an optimistic one. The sceptical one which considers the default reaction dC firstis obviously more restrictive. Using the optimistic strategy, however, as much as possibleviolations can be repaired.
Note that it does not make any difference when to check for a default reaction of the secondtype dω
C if C does not depend inherently on itself due to a reaction rωC. If there are reac-
tions r1ωC , . . . , rn
ωC all concerning the same operation pattern ω, before applying any of those
32
reactions the default reaction dωC can be checked for non-applicability of violations in ∆ω
C.If, however, C depends inherently on itself due to a reaction ri
ωC , this reaction may change
the applicability of another reaction rjωC . Thus, in every case where only one reaction for an
operation pattern ω ∈ ∆critC exists, the default reaction dω
C can be assumed to precede rωC.
Let RC = {r1ω1
C , r2ω1
C . . . , rnωr
C } be the set of explicit reaction specifications for a constraint C.Let reactC = {ω1, . . . , ωr} the set of critical operation pattern from ∆crit
C considered by RC.Let noreactC = ∆crit
C − reactC , i.e. those critical operation patterns for which no reactionsin RC (explicitly) exist. A total order is imposed on the set R′
C containing the followingreactions
• the implicitly assumed default reaction dC ,• the implicitly assumed default reactions dω1
C , . . . , dωr
C , and• the explicitly specified reactions r1
ω1
C , . . . , rnωr
C .
w : R′C → IN assigns a weight to every reaction such that w is an injective function. A
reaction, say ri ∈ R′C , then is considered at run time before all other reactions rj ∈ R′
C
for which w(ri) > w(rj) holds. We require that weights are assigned to the reactions by thedesigner.
Example 4.5: Consider the following part of a dependency graph. This part contains theconstraint (node) C with its outgoing edges (default reaction are represented by dead-endedges):
�� �
��
��
@@
................
��................
@@@R?.
dC
C
dωC dω1
C
r1ωC r3
ω1
Cr2ωC
Figure 3: Constraint with belonging Reactions
Assume that r1ωC and r2
ωC are unambiguous reactions concerning the same critical operation
pattern ω ∈ ∆critC .8 Furthermore assume that w(r1
ωC) > w(r2
ωC) > w(r3
ω1
C ) holds due to anorder specified by the designer. Assume a violation of C in a state σ such that only theviolation relations ∆ω
C and ∆ω1
C are not empty. The reactions on the violations can then beexecuted in the following order:
1. if tuples in at least one violation relation ∆ω′
C , ω′ 6= ω/ω1, exists, perform a complete
rollback (default reaction dC), else
2. if there exist tuples in ∆ωC on which neither r1
ωC nor r2
ωC is applicable then perform a
complete rollback (default reaction dωC), else
3. r1ωC on those tuples in ∆ω
C on which r1ωC is applicable
4. r2ωC on those tuples in ∆ω
C on which r2ωC is applicable
5. if there exist tuples in ∆ω1
C on which r3ω1
C is not applicable then perform default reactiondω1
C , else
8As stated in section 3 we always assume that reactions concerning the same critical operation patternω ∈ ∆crit
C are always unambiguous.
33
6. r3ω1
C on violations in ∆ω1
C on which r3ω1
C applicable
Obviously, if r1ωC , r2
ωC and r3
ω1
C are safe reactions, after reacting on violations of C a state σ ′
is reached such that σ′ |= C holds.
This example reflects a concrete (sceptical) strategy on handling ambiguous violations, sinceit is also possible to check the default reaction dC after reacting on violations in ∆ω1
C and∆ω
C. A more “optimistic” strategy on handling ambiguous violations of C, however, is toassign the lowest weights to each default reaction. In our example, then the default reactionsdω
C, dω1
C and dC then are considered after all three reactions r1ωC , r2
ωC and r3
ω1
C .
Although the way to handle ambiguous violations plays an important role in repairing vio-lations, this problem has not been considered in a suitable way before. Here, the designercan choose a concrete strategy for each constraint. Weighting should in general be carriedout by the designer. Even for constraints for which only one reaction, say rω
C, exists (s)hehas to determine whether the default reaction dC has to be considered before or after rω
C.
4.3 Cycles
The most critical elements when executing repair actions by triggers at run time are cyclessince they may lead to non-termination of the repair process. Although a lot of papershave discussed the problem of cycles in the context of static analysis of production rules[CW90, KU90, AWH92, vdVS93], a general solution on handling cycles cannot be given. Toforbid the specification of cycles seems not to be a pragmatic solution, either, since evensimple cascading deletions and updates thus would be prevented. Based on our patterns ofrepair actions a cycle is formally defined as follows:
Definition 4.6 (Dependency Path/Cycle):(v0, . . . , vn) is a path of the length n in a dependency graph DG iff (vi−1, vi) ∈ E for alli = 1, . . . , n. A path (v0, . . . , vn) corresponding to constraints (C0, . . . , Cn) is a cycle inDG iff v0 = vn and there exists a sequence (ω0, . . . , ωn) of operation pattern such thatwi ∈ op(r
ωi−1
Ci−1) and there exists a reaction rωi
Ci∈ RCi
for each i = 1, . . . , n and ω0 ∈ op(rωn
Cn).2
It is important to note that the fact that, e.g., two constraints C and C ′ are mutuallydependent does not necessarily imply that there exist a cycle comprising C and C ′. Thismay be the case for every path (v0, . . . , vn) where v0 = vn holds. Of course, it is necessaryto visualize this aspect to the designer in a respective design tool.
The most simple type of cycles which may occur in a dependency graph consists of a singleconstraint C for which a reaction in RC exists specifying cascading deletions (or updates).The constraint typically depends negatively on itself.
Example 4.7: Let the following nodes v1 and v2 labelled with the constraints C1 and C2
as part of a dependency graph are given:
The path (v1, v2) is a cycle if
• ω′ ∈ op(rωC1
), i.e. there exists a reaction on violations of C2 caused by repair actions onC1, and
34
?
��6� �
��
�
��
� C1 C2
rω′
C2
rωC1
Figure 4: Cycle in a dependency graph
• ω ∈ op(rω′
C2), i.e. there exists a reaction (here rω
C1) on violations of C1 caused by repair
actions on C2.
If, e.g., ω 6∈ op(rω′
C2) then there is no cycle since no repair action on violations of C1 caused
by ω′ ∈ op(rω′
C2) exist.
In proposition 3.30 we gave a criterion for the first pattern when a propagation specifies acascading deletion. For this case, as far as no reaction for the same constraint exists whichspecifies a re-insertion of the deleted tuples, termination of a repair process following sucha cycle can be guaranteed due to a fixpoint property.9 The repair process then terminatesif the reaction rω
C is not applicable furthermore or, in the worst case (e.g. if rωC is always
complete applicable), the whole relation from which tuples are deleted is empty and thusthe constraint is trivially satisfied.
Let us now investigate how to handle more complex cycles in a dependency graph, i.e. cy-cles comprising more than only one node. Although the defining property of a cycle as indefinition 4.6 can be refined in several ways, complex cycles are rather scarce. However, incase of such a cycle it is desirable to identify a node (constraint) which should be checkedbefore the other constraints in the cycle. Loosely speaking, all nodes comprised in a cyclehave the same “priority”, i.e. there is no reason (or simply syntactical decidable property ofthe elements of the cycle) that a certain constraint should be checked for violations beforeother constraints in the cycle. The following strategies on handling cycles and imposing anorder on the constraints within a cycle seem reasonable:
First, in the context of the complete dependency graph, a cycle within the graph shouldbe considered as a single “meta-”node. Once a cycle is entered for checking a constraint,all constraints outside the cycle should not be checked until processing constraint violationswithin the cycles has terminated.10 We illustrate this aspect by an example:
Example 4.8: Consider figure 5. It is clear, that C and C ′′ should be checked before anyconstraint within the cycle. Hence the cycle can only be entered via an edge which comesfrom C or C ′′. When coming from C ′′ constraint checking (and repairing) in the cycle thenfollows the path from C3, C1, C2, C3, . . . and so on, depending on the respective violations andreactions. Since processing through the cycle in such a way may not terminate, constraintsC ′ and C ′′′ should not be checked before termination.11 The process terminates if, e.g., C2
9For conflicting modifications see, e.g., [KU90]. However, remember that our reactions concerning thesame critical operation pattern are required to be unambiguous and thus reduce the possibility of conflicts.
10as far as no constraint C in the cycle depends transitively on a constraint C ′ not comprised in the cycle11If, e.g., C3 depends transitively on C ′′′ (what is indicated by the dotted edge from C ′′′ to C3) also
constraints outside of the cycle have to be checked.
35
��
� C ′′
��
� C ′′′
��
� C ′′
��
� C ′′′ �6
��
�
��
� �
��
��
�
��
�
��
�
��
�
��
�
��
��/ @@
@I��
�/-�
@@@R
���
@@@R �
���
����
@@@I�
��=
6
C2 C3
C C ′
C(1,2,3)⇒
C1
C C ′
Figure 5: Reducing a Cycle
is not violated any more. Then checking and repairing can be continued with constraint C ′
or C ′′′. This fact is represented in the right part of the figure 5 above, making a possiblesequence of constraints to check more clear.
Is it, however, advisable to start checking within a cycle with the constraint (node) whichhas been entered by an edge, i.e. repair action? We think, that there are two differentstrategies which may be more efficient. Both strategies are based on the number of ingoingedges to a node within the cycle. For this, we consider only edges corresponding to negativedependencies.
The first strategy is to start with the node which has the fewest ingoing edges. It is plausiblethat the respective constraint can be violated by repair actions more rarely than constraints(nodes) in the cycle which have more ingoing edges. In such a case processing the cyclemay follow the path through the cycle only one time, ending with checking the startingconstraint.
In contrast the second strategy starts checking at the node with the most ingoing edges.Through this the corresponding constraint, say C, can be violated due to several repairactions. In this case, the possibility that in case of a violation a repair action for C cannotbe applied and thus the default reaction is performed is higher than for other constraintsrespectively nodes having less ingoing edges. Processing constraints in the cycle then mayterminate directly at the first node by performing the default reaction concerning non ap-plicability such that other constraints in the cycle do not need to be considered.
However, both approaches depend heavily on the underlying application. If, for example,transactions typically affect most of the relations appearing in a certain constraint of thecycle, this constraint should be checked first, independently of the number of in- and outgoingedges. That is why we require that the designer has to mark a node in each cycle of adependency graph to start processing constraint checking and repairing with.
4.4 Remarks
Based on a set of integrity constraints, specifying, analyzing and structuring reactions canbecome a very complex design task which should be supported by suitable design tools.Visualizing properties of constraints, e.g., dependencies of different types due to specifiedreactions, should be a main feature of these tools. Constraints should be specified in astepwise manner, i.e. in each step a single constraint with its reactions. In this context simple
36
templates for (safe) reaction specifications and for partial rollbacks or exceptions should besupplied to the designer. A constraint with weighted reactions can then be considered asa constraint module. Modules can be analyzed for interrelations, i.e. dependencies. Theoverall complexity of this design task depends mainly on the number of reactions specifiedfor the constraints. The more reactions are introduced which cause dependencies, the morecomplex the design task becomes. Thus, reactions should be applied only to such violationsif it is meaningful and also reflect the application requirements.
37
5 Trigger Derivation
In this section we describe how integrity checking and inconsistency repairing triggers can bederived from given constraint and reaction specifications. These triggers should guaranteeat run time that no (ad-hoc) transaction can ever invalidate any of the specified constraintsand herewith result in an inconsistent state. Triggers should repair inconsistencies in awell defined and observable way, leading to a consistent state, i.e. a database state whereno constraint is violated. Furthermore we concentrate on efficient integrity maintenanceby triggers. Triggers should avoid unnecessary repair actions on violations when other in-consistencies are present for which no repair actions exist. For example, a violation of anindependent constraint (initial node in a dependency graph) for which no explicit reactionon any violation exist (i.e. only the default reaction dC) should be checked before any otherconstraint for which repair actions exist.
In the sequel we first concentrate on the underlying trigger (or synonymously called rule)language and we shortly sketch the underlying execution semantics. We then describe howintegrity checking and inconsistency repairing triggers can be derived from constraint andreaction specifications, and how these triggers can be optimized. At the end of the section,we give some ideas of how cycles as discussed in section 4.3 can be monitored at run time, andthen discuss further requirements on integrating our approach into active database systems.
5.1 Trigger Language
The rule language we will use for our triggers is based on the language used in Starburst, aprototype relational database system developed at the IBM Almaden Research Center, butcan be easily adopted to other systems. The main advantage of the rule system provided inStarburst is that triggers (rules) are deferred to the end of a transaction and that prioritiesbetween triggers can be specified. A detailed description of Starburst and the integratedproduction rule system can be found in [HCLM90, WF90, WCL91]. Here we focus on thefeatures relevant to our trigger generation.
The syntax for specifying a trigger (synonymously called a rule) is as follows:
create rule <name> on <relation>when <triggering-operations>
[if <condition>]then <list of actions>[precedes <rule-list>][follows <rule-list>]
The name names the rule and each rule is defined on a base relation. The clauses in squarebrackets above indicate optional parts of a rule definition. The when clause specifies oneor more triggering operations. A rule is activated after the end of a transaction if at leastone of the specified triggering operations inserted, updated or deleted has occurred onthe relation during the transaction and has participated in its net effect.12 The triggering
12See also the delta relations discussed in section 2.1
38
operation updated may include a list of columns of the relation. Then at least one update onone of the listed columns must have occurred in the net effect to trigger the rule. Note thattriggering operations correspond to operation patterns discussed in the previous sections.
The if clause of a rule specifies a condition which is evaluated once if a rule is triggered. Acondition may be any select statement and is evaluated to true (after triggering the rule)if the statement produces at least one tuple (instead of the select command also the SQLpredicate exists can be used). We then say “the rule fires”. If the condition is omitted, itis always assumed to be true and thus the rule is fired. Then the then clause, which maycontain a list of actions, is executed. An action can be any database operation, i.e. select,insert, update and delete statement, including a rollback. Actions are executed sequentiallyin the listed order.
The optional precedes and follows clause list other defined rules and are used to specifyrule priorities. When a rule R specifies a rule R′ in its precedes list, this indicates that ifboth rules are triggered at the same time, R precedes R′. In contrast, if a rule R specifies arule R′ in its follows list, R′ will be considered before R if both are triggered at the sametime.
The condition and the action parts of a rule may refer to the current database state, i.e. thestate when the rules are triggered. They may also refer to delta relations we introduced insection 2.1. If a rule on a relation p specifies inserted as its triggering operation, the deltarelation inserted used in the condition and/or action part refers to the logical table con-taining all tuples that were inserted into the relation p. The delta relation new updated andold updated contain the current and the original values of tuples updated by the triggeringtransaction on p.
Rules are processed automatically at the end of each transaction (deferred triggers). Ruleprocessing typically starts with the end of a user- or application generated transaction Tbefore committing T . A transaction T performs a state transition from an initial state σ to a
new state σ′, denoted as σT−→ σ′. If a rule R is triggered in σ′ and its condition is evaluated
to true, the rule fires. The execution of its action is again considered as a transaction TR
leading to a new state σ′′ (σ′TR−→ σ′′). If any rule executes a rollback the entire transaction
aborts, leading to the initial state σ. Otherwise the entire transaction T, TR, . . . commitswhen rule processing terminates, i.e. when no rule is triggered after a transaction. For moredetails on the semantics of rule execution in Starburst, in particular how transition tablesare maintained during rule execution, we refer to [WF89, WF90].
5.2 Integrity Checking and Inconsistency Repairing Triggers
Basis for the approach presented in the sequel is a maximal connected subgraph DG withweighted reactions and marked nodes in each cycle of DG. We refer to the set of constraintsinvolved in DG by C and the corresponding set of explicit reaction specifications by RC.
For the most simple type of graphs, i.e. graphs having only one node corresponding toa constraint which is independent from all other constraints and on which no other con-straint depends, only integrity checking triggers have to be derived. Suitable approachesto derive corresponding triggers are described, e.g., in [CW90] or [GL93]. Let now C besuch a constraint, and ∆crit
C the corresponding set of critical operation patterns. For a set
39
{ω1, . . . , ωn} ⊆ ∆critC of patterns concerning the same base relation p the following trigger is
derived:
create rule check C on pwhen ω1 or . . . or ωn
if C holdsthen rollbackprecedes all checking rules for constraints for which repair actions are specified
The violation query C for C in the if clause is formulated by using the SQL predicate existsas illustrated in the following example.
Example 5.1: Assume that for constraint C1 from our example database no reaction isspecified and that it also does not depend on another constraint. We can derive the followingtrigger to check a violation of C1:
create rule check C on empwhen inserted, updatedif exists (select ∗ from emp
where not (salary > 1000))precedes . . .
No further trigger for checking C1 is necessary since all critical operations in ∆violC1
refer onlyto the relation emp. Furthermore, the rule above can be optimized in two ways: first, asdiscussed in section 3.2.2, an update on emp can only violate the constraint if the updateaffects also the salary, since salary is a connection variable in C1. Thus, we can refine thetriggering operation to updated(salary). Secondly, we can specialize the evaluation of theviolation query in the if clause to the delta relations inserted and new updated to avoidevaluation over the complete relation emp. This can be done since the constraint is assumedto be valid before the initial transaction and thus need only to be checked for newly insertedand updated employees. For this, we have to split the condition above into two existsclauses:
if exists (select ∗ from inserted
where not (salary > 1000))or exists (select ∗ from new updated
where not (salary > 1000))
It is reasonable that triggers for independent constraints should precede all other integritychecking and inconsistency repairing triggers for constraints for which reactions on violationsare explicitly specified to avoid unnecessary repair actions. We assume that all triggers forthe specified constraints have priorities depending on the constraints (prio : C→IN), andthat triggers for constraints like in example 5.1 have the highest priority 1.
The steps sketched in the following are applied analogously to each maximal connectedsubgraph DG of a given dependency graph. As indicated in the previous section, constraintsshould be checked in a certain order to guarantee efficiency. To obtain an order on the
40
constraints a hierarchy on the the nodes in DG has to be derived. This hierarchy (like it isused in a similar way for logic programs) is based on the assumption that repairing violationsof a constraint at one hierarchy level may only violate constraints of a lower hierarchy level.The following algorithm yields a priority for each node (constraint) v ∈ DG:
Algorithm 5.2:
For each cycle in DG = <V,E> doremove all ingoing edges to the node marked by the designerwhich belong to the cycle subgraph
od;
For each v ∈ V, ν(v) = C do prio(C) := 2 od;RepeatFor each vi ∈ V , (vi, vj) ∈ E, i 6= j do{ let Ci = ν(vi) and Cj = ν(vj) }prio(Cj) = max(prio(Cj), prio(Ci) + 1);
od;Until no priority has changed. 2
By this algorithm constraints corresponding to nodes with no ingoing edges get the highestpriority 2 and those corresponding to nodes with no outgoing edges get the lowest priorities.
Assume that a constraint C with a set RC of explicitly specified reactions, and a specifiedorder on all reactions in R′
C for C including the default reactions are given. The respectivetriggers (rules) can be derived as follows: For each reaction in RC one checking and repairingtrigger is required, for each operation pattern in reactC a trigger for a default reaction dω
C isrequired13, and finally d triggers for the default reaction dC are required (we will describe thevariable d later). Thus, each set R′
C has (|RC | + | reactC | +d) associated triggers. Assumethat the constraint C has the priority prio(C) = p. Let the explicit and implicit reactionsin R′
C be denoted by {r1, . . . , rn}.
For the default reaction dC(= ri) ∈ R′C we get the following trigger:
create rule C dcwhen ω ∈ {∆crit
C − reactC} occurredif at least one specialized violation relation ∆ω
C
(ω ∈ {∆critC − reactC}) is not empty
then rollbackprecedes all rules for C ′ ∈ C, prio(C ′) > p
all rules for rj ∈ R′C,w(rj) < w(ri)
follows all rules for C ′ ∈ C, prio(C ′) < pall rules for rj ∈ R
′C,w(rj) > w(ri)
When an operation pattern in a transaction net effect occurs for which no reaction is specifiedand if there exists a specialized violation relation which is not empty in the state when C dcis triggered, the rule performs a complete rollback. The rules listed in the precedes and
13See also section 3.3.
41
follows clauses reflect the priorities computed by algorithm 5.2 and the specified order(weights) on reactions R′
C for C. In the patterns for the following rules the same holds forthis two clauses. That is why we do not list all rules in these clauses explicitly.14
Since a single rule cannot be defined on more than one base relation, the rule above has to besplitted. Actually, we thus have to define one rule on each relation affected by an operationpattern from {∆crit
C − reactC}. E.g., if we have {∆critC − reactC} = {Ip, Up, Dq, Uq} we have to
derive one rule for the relation p and one rule for the relation q. However, these rules havethe same pattern as above, in particular they have the same precedes and follows clauses.
For a default reaction dωC concerning a critical operation pattern ω ∈ ∆crit
C on a relation pfor which a reaction has been specified, we can derive the following rule:
create rule C dcw on pwhen ωif there exist tuples in the specialized violation relation ∆ω
C on whichno reaction in RC concerning the pattern ω is applicable
then rollbackprecedes . . . / follows . . .
Finally, for each reaction rωC ∈ RC concerning a critical operation pattern ω ∈ ∆crit
C on arelation p a rule has to be derived. We first present the general pattern and then discuss thecondition in the if clause and the action part in more detail:
create rule C react on ω on pwhen ωif ∆ω
C is not emptythen begin
evaluate substitutions ΘωC for which ∆ω
C(x1, . . . , xn) ∧ ϕω holdsand store them in temporary table temp;perform modifications specified in the postcondition of rω
C
for each substitution in the table tempend;precedes . . . / follows . . .
It is necessary to evaluate the violation relations in each rule for a constraint C again sincepreceding rules, in particular those concerning the same operation pattern ω ∈ reactC , mayhave removed violations by repair actions (see example 4.5). It is important to note thatthe condition in the if clause of each rule for a constraint C comprises the evaluation of theviolation query C for a constraint C.
14Since it is not possible to list non-existing rules in the precedes and follows clause of a rule, firstall rules have to be derived without this clauses. After all rules are derived, the rules then can be alteredby additionally specifying respective following and preceding rules determined by the given priorities andweights.
42
Example 5.3: Assume for constraint C2 from our example database a reaction has beenspecified on violating insertions into the relation emp, i.e. insertions of employees for whichno department exists. We get the following condition for the respective rule:
create rule C2 react on ins on empwhen insertedif exists (select ∗ from inserted ins emp
where not exists(select ∗ from depwhere dep.dno = ins emp.dno))
then . . .precedes . . .follows . . .
A reaction can only take place if an insertion into the relation emp is involved in a violationof C2.
Once a rule is fired, the action is performed. For the two types of default reactions dC and dωC
the action is simply a rollback leading to the state where the initial transaction has started.However, for a default reaction dω
C in addition to the violation query C we have to checkwhether there exist tuples in the specialized violation ∆ω
C for which no reaction concerningthe pattern ω in RC exist.15 This can be done in the if clause but also in the action part ofthe respective rule.
5.3 Monitoring Cycles
As discussed in section 4.3 cycles of constraint check and repair actions may cause non-termination. We now want to give some ideas of how to monitor cycles, but also whichproblems arise with approaches monitoring cycles. For further discussions on detectingand maintaining cycles at run time see, e.g., [KU90] or [vdVS93]. Again, we start ourconsiderations with the most simple type of cycles, i.e. a repair action rω
C of a constraintC such that ω ∈ op(rω
C) holds. For this, consider the following reaction on violations ofconstraint C1 by updates on the relation emp (i.e. ω = Uemp):
rωC1≡ ∆C1
(eno, . . . , salary) � set salary = salary + 10
This reaction obviously again violates C1 if the salary is less than 991. However, this cycleterminates after a finite number of applications of the repair action rω
C1to the same violations.
In contrast, assume a specification error in the postcondition of the reaction above such thatthe new salary is set to the old salary minus 10. Although this reaction again violates C1 incase of a violating update, the repair cycle will never terminate.
For more complex cycles non-termination may be caused if a repair action for a constraintC ′ in the cycle undoes repair actions performed concerning a constraint C in the cycle.However, in most cases such properties depend on operation instances, thus it is difficult todetect such cycles or rather their non-termination property in a static analysis as discussedin section 4. Once a cycle is detected, the underlying design tool therefore should provide a
15See also section 3.3, reaction pattern (9).
43
suitable mechanism to examine cycles by simulating triggering repair actions in the cycle byappropriate constraint violations and operation instances. For this, one problem is to gener-ate suitable test data for, e.g., constraint violations. Suggestions on the topic of automaticgeneration of test data can be found in [Nob83, MR89, NML93].
But how can cycles be maintained at run time? The most restrictive method to preventinfinite triggering is to execute every potential rule triggering within a cycle only a finitenumber of times, as suggested in [CW90]. The problem with this approach is how to choosean appropriate number for each cycle. If, for example, we choose a number of ten for ourcycle above on changing the salary, triggering this reaction results in a state consistent withregard to C1 only if the initial salary is greater than 901. For an initial (violating) salary lessthan 901 triggering this repair action will stop after increasing the salary ten times althoughthe violation can be repaired after a finite number of triggering rω
C1.
Another possibility to maintain cycles at run time is to keep a history of operation instancesperformed by repair actions as suggested in [KU90]. For our reaction patterns this approachcan be refined by keeping track of violation instances on which each reaction for a constraintparticipating in the cycle has been applicable. If a reaction, say rω
C, is applicable to violationsin a state σ respective instances of the violating operation ω are stored in a relation and atimestamp is added. This procedure is applied to each operation instance in each state whererωC is applicable. If in following state σ′ the current violations (on which rω
C is applicable)are a superset of violations produced by rω
C in any previous state, the cycle may cause non-termination since violations have not been repaired or repair actions have been undone. Thisapproach, however, results in a complex overhead of comparisons between the current andall previous violations if a lot of constraints with many repair actions are comprised in acycle. Additionally, corresponding checking and repairing triggers have to be extended byrespective procedures to store and to compare violation instances.
For more sophisticated approaches on handling and maintaining cycles at rune time, however,still more investigations on analyzing techniques are necessary. The aspect on suitableinteractions with the user/designer should be part of further work on triggering cycles, too.
5.4 Repair Information
The operations performed by the triggers derived from constraint and reaction specificationsas described in section 5.2 are completely invisible to the user. In case of complex repairactions which perform many modifications of the database contents the database state whichresults from the initial (violating) transaction and the following repair action may differ alot of the user’s (intended) transaction. Thus, the repair process need to be enriched bysuitable mechanisms which yield information about violations, performed repair actions,etc. We suggest the following information should be yielded by triggers:
• actual constraint to be checked (based on the derived hierarchy)• (unambiguous) violations of the constraint under consideration• for default reactions of the pattern dC and dω
C all violation instances which cause acomplete rollback
• for each reaction rωC all violations on which rω
C is applicable and for each such violationthe performed modification(s)
44
All these information can easily be determined within checking/repairing triggers such thatno additional mechanisms like, e.g., programs which monitor the repair process, are neces-sary. A completely automated repair process of constraint violations by triggers thus is onlyacceptable if triggers incorporate as much explanation facilities as necessary and possible.
6 Conclusions and Further Work
In this paper we have presented a framework for the specification of the reactive behavior onconstraint violations in active relational databases. We described a declarative specificationlanguage for repair actions with an operational semantics. These repair actions are suitable toexpress most of the designers’ intentions on the behavior on constraint violations. Based oncritical operation patterns, i.e. database operations which may violate specified constraints,we have worked out patterns of reaction specifications which guarantee a safe behavior.Such safe behavior assures that the violations under consideration are removed and thatno further violations of the same constraint are introduced by repair actions which performmodifications of the database contents.
Based on the proposed specification language we provided a concept for analyzing and struc-turing reactions in a dependency graph. Such graphs reflect the order when to check a con-straint before other constraints at run-time, but also the order of repair actions to applyto violations of a constraint. We have shown how the designer can incorporate semanticknowledge of the underlying application into a dependency graph, too. Based on a fullyspecified dependency graph we have presented our approach to derive integrity checking andinconsistency repairing triggers from specified repair actions. Additionally we illustratedguidelines of handling cycles in a repair process and how triggers can be enriched to yieldinformation about the repair process.
The main purpose of the paper was to provide a clear cut between the specification of repairactions and their implementation by triggers such that all (semantic) knowledge about theapplication is already captured in the conceptual design in interaction with the designer.Thus automatically derived triggers do not need refinements by the designer and herewiththe possibility to introduce inconsistent specifications.
Our further work concentrates on developing a more general framework for repairing incon-sistencies in (active) databases. The repair process, in particular, has to be refined in atwo-phase process. The first phase has to concentrate exclusively on diagnosing violationsof the different constraints and on identifying those operations of a transaction which aremost “plausible” for the present violations. A necessary requirement therefore is to exploitinterrelations between constraints, e.g., to identify those constraints which take the samebase relations into account. Based on such diagnosis results it is desirable to decide alreadyin an inconsistent database state whether or not applying specified reactions will result in aconsistent state. Thus some kind of hypothetical reasoning about repair actions is necessary,too. The second phase of the repair process then is to apply repair actions to the identifiedviolations. For this it is conceivable to choose repair actions based on a minimal changesemantics, i.e. to perform as less as possible modifications on the database contents in orderto achieve consistency.
Our further work also includes extending the language for reactions specifications presentedin this paper in order to provide more expressive and functional repair actions. This includes
45
in particular repair actions on violations of dynamic integrity constraints. Like our previ-ous work on integrity maintenance [GL93], we are also integrating the presented approachin a toolbox called ICE (integrity-centered environment). Developing integrity enforcingmechanisms is the main line of the project for database design.
References
[AH87] S. Abiteboul, R. Hull: IFO: A Formal Semantic Database Model. ACM Transactionson Database Systems 12:4 (December 1987), 525–565.
[AWH92] A. Aiken, J. Widom, J. M. Hellerstein: Behavior of Database Production Rules: Termi-nation, Confluence, and Observable Determinism. In M. Stonebraker (ed.), Proceedingsof the 1992 ACM SIGMOD International Conference on Management of Data, 59–68,ACM Press, 1992.
[CL73] C. Chang, R. Lee: Symbolic Logic and Mechanical Theorem Proving. Academic Press,London, 1973.
[CM89] I.-M. A. Chen, D. McLeod: Derived Data Update in Semantic Databases. In P. M. G.Apers, G. Wiederhold (eds.), Proceedings of the 15th Int. Conf. on Very Large DataBases - 1989, 225–234, Morgan Kaufmann Publishers, 1989.
[CW90] S. Ceri, J. Widom: Deriving Production Rules for Constraint Maintenance. InD. McLeod, R. Sacks-Davis, H. Schek (eds.), Proceedings of the 16th Int. Conf. onVery Large Data Bases - 1990, 566–577, Morgan Kaufmann Publishers, 1990.
[dB91] R. A. de By: The Integration of Specification Aspects in Database Design. PhD thesis,University of Twente, The Netherlands, 1991.
[DD93] C. J. Date, H. Darwen: A Guide to the SQL Standard (Third Edition). Addison-Wesley,Reading (MA), 1993.
[EC75] K. Eswaran, D. Chamberlin: Functional Specifications of a Subsystem for Data BaseIntegrity. In Proc. Int. Conf. on Very Large Data Bases 1975, 48–68, 1975.
[FPT93] P. Fraternali, S. Paraboschi, L. Tanca: Automatic Rule Generation for ConstraintEnforcement in Active Databases. In U. W. Lipeck, B. Thalheim (eds.), ModellingDatabase Dynamics, Volkse 1992, 153–173, Springer-Verlag, 1993.
[GL93] M. Gertz, U. W. Lipeck: Deriving Integrity Maintaining Triggers from TransitionGraphs. In Ninth International Conference on Data Engineering, 1993, 22–29, IEEEComputer Society Press, April 1993.
[Han89] E. N. Hanson: An Initial Report on the Design of Ariel: A DBMS with an IntegratedProduction Rule System. SIGMOD Record 18:3 (September 1989), 12 – 19.
[Han91] E. N. Hanson: The Design and Implementation of the Ariel Active Database RuleSystem. Technical Report UF-CIS-018-92, Department of Computer and InformationScience, Gainsville, Florida, September 1991.
[HCLM90] L. M. Haas, W. Chang, G. M. Lohman, J. McPherson: Starburst Mid-Flight: Asthe Dust Clears. IEEE Transactions on Knowledge and Data Engineering 2:1 (March1990), 143 – 160.
46
[HM75] M. Hammer, D. McLeod: Semantic Integrity in a Relational Database System. In Proc.Int. Conf. on Very Large Data Bases 1975, 25–47, 1975.
[KU90] A. P. Karadimce, S. D. Urban: Diagnosing Anomalous Rule Behaviour in Databaseswith Integrity Maintenance Production Rules. In J. Goers, A. Heuer (eds.), SecondWorkshop on Foundations of Models and Languages for Data and Objects - 24.9.-28.9.90 in Aigen, 77–102, Informatik-Bericht 90/03, TU Clausthal, 1990.
[LR84] T.-W. Ling, P. Rajagopalan: A Method to Eliminate Avoidable Checking of IntegrityConstraints. In Proc. IEEE Trends & Applications Conference: Making Database Work,60–69, 1984.
[LT85] J. W. Lloyd, R. W. Topor: A Basis for Deductive Database Systems. The Journal ofLogic Programming (1985), 93–109.
[ML91] G. Moerkotte, P. C. Lockemann: Reactive Consistency Control in Deductive Databases.ACM Transactions on Database Systems 16:4 (December 1991), 670–702.
[MR89] H. Mannila, K.-J. Raiha: Automatic Generation of Test Data for Relational Queries.Journal of Computer and System Science 38:2 (1989), 240–258.
[MRC85] L. Mark, N. Roussopoulos, B.-t. Chu: Update Dependencies. In T. B. Steel Jr.,R. Meersman (eds.), Preliminary Proceedings - Database Semantics (DS-1), Jan. 7-11,1985, Hasselt, Belgium, North-Holland, January 1985.
[NML93] A. Neufeld, G. Moerkotte, P. Lockemann: Generating Consistent Test Data: Restrictingthe Search Space by a Generator Formular. The VLDB Journal 2:2 (April 1993), 173–214.
[Nob83] H. Noble: The Automatic Generation of Test Data for a Relational Database. Infor-mation Systems 8:2 (1983), 79–86.
[Rei84] R. Reiter: Towards a Logical Reconstruction of Relational Database Theory. InM. L. Brodie, J. Mylopoulos, J. W. Schmidt (eds.), On Conceptual Modelling, 191–238. Springer-Verlag, 1984.
[SJGP90] M. Stonebraker, A. Jhingran, J. Goh, S. Potamianos: On Rules, Procedures, Chachingand View in Database Systems. In H. Garcia-Molina, H. V. Jagadish (eds.), Proceedingsof the 1990 ACM SIGMOD International Conference on Management of Data, 281–290,ACM Press, 1990.
[ST92] K.-D. Schewe, B. Thalheim: Computing Consistent Transactions. Preprints CS-08-92,FB Informatik, Universitat Rostock, December 1992.
[SV84] E. Simon, P. Valduriez: Design and Implementation of an Extendible Integrity Subsys-tem. In B. Yormark (ed.), Proc. ACM SIGMOD Int. Conf. on Management of Data1984, Boston, 9–17, ACM Press, 1984.
[UD92] S. D. Urban, M. Desiderio: CONTEXT: A CONstrainT EXplanation Tool. Data &Knowledge Engineering 8:2 (May 1992), 153–183.
[UKN92] S. D. Urban, A. P. Karadimce, R. B. Nannapaneni: The Implementation and Evaluationof Integrity Maintenance Rules in an Object-Oriented Database. In F. Golshani (ed.),Eighth International Conference on Data Engineering - 1992, 565–572, IEEE ComputerSociety Press, 1992.
47
[Ull88] J. Ullman: Principles of Database and Knowledge Base Systems Vol. I (3rd edition).IEEE Computer Science Press, Rockville (Md.), 1988.
[vdVS93] L. van der Voort, A. Siebes: Termination and Confluence of Rule Execution. Technicalreport, CWI, Amsterdam, The Netherlands, 1993.
[vGT91] A. van Gelder, R. W. Topor: Safety and Translation of Relational Calculus Queries.Transactions on Database Systems 16:2 (June 1991), 235–278.
[WCL91] J. Widom, R. J. Cochrane, B. Lindsay: Implementing Set-Oriented Production Rulesas an Extension to Starburst. In G. M. Lohmann, A. Sernadas, R. Camps (eds.),Proceedings of the 17th Int. Conf. on Very Large Data Bases - 1991, 275–285, MorganKaufmann Publishers, 1991.
[WF89] J. Widom, S. J. Finkelstein: A Syntax and Semantics for Set-Oriented ProductionRules in Relational Database Systems. SIGMOD Record 18:3 (1989), 36–45.
[WF90] J. Widom, S. J. Finkelstein: Set-Oriented Production Rules in Relational DatabaseSystems. In H. Garcia-Molina, H. V. Jagadish (eds.), Proceedings of the 1990 ACMSIGMOD International Conference on Management of Data, 259–270, ACM Press,1990.
48
![Data Glitches = Constraint Violations – Empirical …Divesh Srivastava AT&T Labs-Research A spaceman's word for irritating disturbances [Time, 23 Jul 1965]. ... – Data glitches](https://img.pdfslide.us/doc/110x75/5f08c5587e708231d423a432/data-glitches-constraint-violations-a-empirical-divesh-srivastava-att-labs-research.jpg)
![BPEL Validation with Object Constraint Language …moeller/publist-sts-pw...Introduction BPEL [3] or BPEL4WS1 is a language for specifying the Business Process logic that defines](https://img.pdfslide.us/doc/110x75/5f77f6535076bc0ba975fef0/bpel-validation-with-object-constraint-language-moellerpublist-sts-pw-introduction.jpg)
