International on Deductive and Object-Oriented Databases, Munich, December 1991, LNCS 566 p.

292-311, Springer-Verlag.

Constraints in an Object-Oriented Deductive Database

Yves CaseauBellcore, 445 South Street,Morristown NJ 07962, USA.e-mail: caseau@bellcore.com

Abstrac tThis paper relates our experience in integrating constraint resolution

into an object-oriented deductive system. We motivate this work byshowing that disjunctive information and global constraints fit naturallyin an object-oriented model and are actually necessary to performcommon tasks. We identify three difficulties in developing such anextended object-oriented system (namely, compilation, domain reduction,and heuristics) and propose a solution for each. We provide a formalsemantics and prove the correctness of those three techniques. Weillustrate the performance results with the implementation we have builtin LAURE.

1. IntroductionNon-traditional database applications, such as design and planning

(scheduling/ resource assignment), try to use object-oriented databases,because the complex structures (objects) that arise naturally whendescribing the design of a telephone switch or when assigning tasks to apool of technicians fit the object-oriented paradigm more naturally.However, there is an implicit amount of non-determinism implied in theseproblems (e,g., the design is partially specified or the tasks are not alreadyassigned), which is difficult to represent, whether in a commercial object-oriented database or in a relational database. Therefore, a naturalextension to a data model [AKG87] [INV90] [Ca91a] is to introducedisjunctive (or incomplete) information, which yields to the notion ofglobal constraints to restrict the possible completions of the incompleteinformation. For instance, the budget for a design will be seen as a globalconstraint on all the design choices (the total cost should be less than agiven value).

An object-oriented model with disjunctive information and globalconstraints may be the perfect environment to specify scheduling orplanning problems, but we still have to solve the constraints. Because ofthe complexity (disjunctive constraint problems are non-polynomial),large problems are very hard to solve. Among all the technical difficulties,we have identified three issues that must be resolved in theimplementation of a realistic constraint solver:

• We need some techniques for domain reduction [DSVH87]. Theconstraint solver which was most successful when applied to real-lifeproblems is CHIP [VH89] and is based (among other things) on smarttechniques for reducing the domains of each unknown variable byconst ra in t propagat ion before s tar t ing an enumerat ion(backtracking). One of our goal was to generalize and extend thesemethods for general order-sorted domains [Ca91b] (as opposed to flatinteger domain).

• When the complexity barrier is too high, problems are usuallysimplified by the use of domain-dependent heur ist ics. It seemsunlikely that a generic constraint-resolution strategy could replacethe various methods which have been developed for each class ofproblems. The difficulty is to find a paradigm for integrating heuristicsin a manner as declarative as possible (otherwise the advantages ofconstraint logic programming over ad hoc programming will be lost)

• We need to support compi la t ion of constraints into simpler, moremanageable units. Based on our experience, an interpreted constraintsolver simply cannot be used in a large application.

Here we decribe some techniques that were implemented in the LAURElanguage and have been used successfully for large applications. We use arelational algebra to represent constraints, which supports efficientcompilation using techniques developed for query optimization [Ca89]. Weallow the mixing of production rules with constraints, which we havefound to be a natural and efficient way to write heuristics. We performdomain reduction with an abstract interpretation of the relational algebra,which generalizes previous domain reduction techniques.

The paper is organized as follows. Section 2 describes the framework (anobject-oriented deductive database) and the motivations (non-determinism) for introducing constraints as a paradigm for object-oriented logic programming. We show why we need to integrate differentforms of logic programming to achieve a better resolution of constraints.Section 3 gives a semantics for global constraints and for databasecompletions. We show how the algebraic framework developed fordeductive rules in [Ca89] may be reused here, yielding to the notion ofalgebraic constraints. We introduce a limited set of production rules,similar to expert-systems rules, to enhance the constraint resolution.Section 4 describes the resolution strategy we use in LAURE and some ofthe tools that we have developed. We use an abstract interpretationtechnique [Ca91b] to perform domain reduction before and duringresolution; we compile rules and constraints using the relational algebra;and we introduce heuristics through production rules. Section 5illustrates the practical results we have obtained by implementing thosetechniques in the LAURE system.

2. Motivations

In this section we first recall the features of the object-orienteddeductive language [Ca89] that we used as a framework to introduceconstraint. We show that although local constraints are integrated in ourlogical language, global constraints are necessary to introduce disjunctiveinformation in the object-oriented database [IVN90]. We then investigatethe necessary relationship between constraints and rules. A morecomplete description of the LAURE data model (and a comparison withsimilar work [Ku85] [AK89] [KW89]) may be found in [Ca91a].

2.1 Object-Oriented Deduction

In this paper we assume the existence of an object domain O with ataxonomy (a lattice S of classes), a type system and some f e a t u r e s(instance variables or methods), to which we attach binary relations[Ca91a]. The object domain O is closed under finite enumeration (all finitesubsets of O belong to O) through a recursive definition. Features(members from the set F) are seen as functions from On → O. Addingextensional relations on top of O is similar to [AK89], but we limit ourselvesto binary relations, and we make a distinction between mono-valued andmulti-valued relations [KW89]. The limitation to binary relation istraditional to object-oriented programming, and we use classes to groupmany binary relations into a large n-ary relation1.

An object model is made from such an object domain O and a set R= {R1,... Rn} of relation names that is divided into R* and R1. A database instanceis defined (next section) as an assignment d of a binary relation on O toeach Ri ∈ R, such that relations from R1 are mono-valued (for each x in O,the cardinal of the set of objects bound to x by the relation is at most 1).

In [Ca89], we have described a logic language for performing deductionin such a database. Here, we give a brief overview of the LAURE logiclanguage (L3) so that we can motivate the introduction of constraints. Wefirst start with DATALOG, restricted to the relations that exist in theobject-oriented database, which are all binary relations. We can, forinstance, write a rule computing equivalence connection classes definedby the base relation bound:

rule[ if [or [bound(x y) or connected(y x)] [z exists connected(x z) connected(z y)]]]

then connected(x y)]

A first aspect specific to object-oriented databases is that some relationsare known to be mono-valued. We also want to compare objects usingorder relations defined as methods on objects (such as <,>,...). Last, somenon binary-relations are represented as methods (interpreted functions)

1 A relation R(xi , … , xn) is represented by a class and a set of n binary relations.Although equivalent from a theoretical point of view with the relational databasemodel, this representation yields to a different implementation and resolutionstrategy, since tuple creation becomes object invention [HS89].

in LAURE, and we want to integrate them into the logic language (weactually only allow ternary functional relations, which we expect to havesome mathematical properties, such as associativity inside a m o n o i dstructure, the existence of an inverse in a g r o u p s t ructure,commutativity or distributivity)2. Introducing mono-valued relations(r(x)), comparison methods ([x = y]) or operations ([x + y]) inside the logiclanguage yields to expressions that are often called local constraints ([CLP],[KKR90]). Local constraints can be merged with logic predicates to buildrelations that cannot be described with pure DATALOG. An example, takenfrom [KKR90], is the computation of an ascending transitive closure,which links two points x and y if there is a path in the base relation ofpoints joining x to y, such that the heights of intermediate points make anincreasing sequence:

rule[ i f [[bound(x y) and [height(y) >= height(x)]] or [z exists bound(x z) ascending(z y) [height(z) >= height(x)] t h e n ascending(x y)]

So far, we cannot create, inside a rule, new objects that would benecessary to represent tuples from a DATALOG relation with arity largerthan 2. We propose to allow for, inside the rule body, a limited form ofobject invention [HS89], which can be used to simulate both predicateswith higher arity or un-interpreted functions (functional terms) [Ca91a].In the following example, we want to compute the distance between twocities, which is a ternary relation. We use a functional term pair(x,y) tocreate a composite object, such that dis tance(pai r (x ,y) ,d) means thatthere is a path with length d between x and y. The expression [pair of x y]is introduced in our language to allow the invention of a pair object withslots first = x and second = y:

rule[ for_all (x pair)(y integer)if [r:road exists [start(r) = first(x)]

[or [[end(r) = second(z)] and [y = length(r)]] [[end(r) != second(z)] and [y = [length(r) + distance([path of end(r)

second(x)])]]]]] then distance(x y)]

We may now define the L3 language more formally. We identify foursubsets F1, Fc, Fo and Fp of F containing features such that (respectively)their arity is 1 (O → O); they represent a comparison (O × O → Boolean);they represent an operation (O × O → O); or they represent a bijection. AnL 3 assertion with free variables in the set V is described by the followinggrammar :

<assertion(V)> :: < R* > (<expression(V)> <expression(V)>) |[<expression(V)> <Fc> <expression(V)>]|[<expression(V)> ∧ <expression(V)>] |

2 Each of these properties are used as rewriting rules [Ca91a] that permit thetranslation from the logic form into the relational algebra.

[<expression(V)> ∨ <expression(V)>] |[∃ <z ∉ V> <expression(V ∪ {z})>*]

<expression(V)>:: V | O | <R1 | F1>(<expression(V)>) |[<expression(V)> <Fo> <expression(V)>] |[<Fp> of <expression(V)>*]

Given the notion of an assignment function ν of (V → O), the semanticsof this language is straightforward to define. Given a database instance dand an assignment function ν, if E is an expression(V), [E]d,ν is an object ofO; if A is an assertion(V), [A] d,ν is a boolean value.

2.2 Disjunctive Information and Global Constraints

LAURE supports disjunctive information, also seen as incompleteinformation [AKG87]. Disjunctive information is used to represent choicesthat are not made yet in a design or a planning problem. In the LAUREmodel, we attach disjunctive information to mono-valued attributes;another solution would be to introduce OR-objects [INV90], but usingrelations simplifies the data model. Each mono-valued relation may begiven a set of possible values for a given object x, either directly such asin:

size(John)∈{162, 177, 190}; color(my_ball) ∈ {blue,green}

or for a set of given objects such as in the following declaration:

∀ x ∈ Toy, color(x) ∈{yellow,red,purple,orange,brown}

Therefore, this model does not support any disjunctive information, butonly disjunctions about the same object and the same relation. This coversthe kind of incompleteness which is frequent with object-orientedapplications. If a certain value of the relation for an object is not known, werepresent a set of possible values instead. Therefore, we define a databaseinstance as an assignment from R to (O → P(O)).

Definition: A database instance is a function of D = (R → (O → P(O))).

For each x ∈ O, if Ri ∈ R* , d(Ri)(x) represents the class of x according to therelation denoted by R i (set of objects bound to x). If R i ∈ R1, d(Ri) ( x )represents the set of possible values for Ri(x). If this set has one uniquemember y, then it means that Ri (x) = y.

There is a lattice structure on database instances, derived from thefollowing order:

∀ d1,d2 ∈ D, d1 < d2 ⇔ ∀ Ri ∈ R* ,∀ x ∈ O, d1(Ri)(x) Ê d2(Ri)(x) ∧ ∀ Ri ∈ R1,∀ x ∈ O, d2(Ri)(x) Ê d1(Ri)(x)

The intuitive meaning of this order is that if d2 > d1 , then d2 containsthe knowledge in d1 plus some additional information (thus the reversedinclusion for mono-valued relations). A database instance d usually

contains some incomplete information through the value of relations fromR1.

This representation yields to the notion of unknown value (or goal forresolution), which is a pair ( Ri , x) such that R i (x ) is not known (i.e.,|d(Ri)(x)| > 1). Incomplete information comes generally with rules thatdefine how they can be completed. A natural paradigm is the notion ofglobal constraints, which are equations on the objects of the database,which restrict possible completions by requiring specific properties (e.g.,the total budget is less than $100K). If we compare them to localcons t ra in ts, such as those presented in the previous section, a localconstraint is an equation introduced in the body of a rule, which restrictsthe unification, whereas a global constraint is an equation on the database,which restricts the completion process.

A constraint is made of an L3 assertion a(v1 ,... vm) and some goals{ Ri(xi), i = 1 .. m} and states that the assertion a should be satisfied for thevaluation vi = Ri(xi) when each goal Ri(xi) has received a unique value. Tointroduce some factorization (the ability to write constraints that apply tomultiple objects using the class taxonomy), we choose either xi = x or xi =f i(x), and we quantify universally on x over some class s ∈ S (f i representssome instance variable of the object x). We can, therefore, represent globalconstraints over the database instance d of the form:

∀ x ∈ s, ∀ v1, v2,..., vn ∈ O,(∀ i ∈ {1…m} vi = d(Ri)(fi(x)) ) ⇒ |a(v1,...,vn)|d = true

In the LAURE syntax (see next examples), the domain s is introducedwith a for_all declaration, the goals declarations follow an if keyword, andthe L3 assertion follows the then keyword. For instance, we define a set ofpoints (a plane) and a subset (a line) defined by the equation [X + 2 Y = 10].

;; we define a new class with two coordinates[plane :: class with (slot cx -> integer) (slot cy -> integer)]

;; a line is a subset of a plane[ l ine1 :: class superset (plane)]

;; we define the line by an equationconstraint[ for_all (p:line1)

if [X = cx(p)] [Y = cy(p)]then [[X + [2 * Y]] = 10]]

Constraints do not necessarily apply to one simple object, as in theprevious example. We can use composite objects to apply a constraint tomultiple receivers. Here we create a class of objects above, such that theexistence of such an object X that points to two graphic objects a and bmust imply that b is on top of a in the layout:

;; a class of complex objects[above :: class with (slot top -> object) (slot bottom -> object)]

;; if X belongs to above, top(X) should be on top of bottom(X)constraint[ for_all (X above)

if [h1 = y(top(X))] [h2 = y(bottom(X))]then [h1 > [h2 + h(bottom(X))]]]

2.3 Rules and Constraints

In this section we present the various kinds of rules and constraintsthat we have found necessary to represent complex scheduling andplanning problems. A formal semantics for each of those logicconstructions will be given in Section 3. Here we only describe what wewould like to introduce in our deductive object-oriented database.Deductive rules (such as those presented in Section 2.1) and constraintsplay two very different roles and are both necessary. Whereas a rule tellsthat we can deduce something if a condition is true, a constraint only saysthat if we choose some values, they have to satisfy a condition. A rule(rule[ if a(x,y) then r(x y)]) is made of a condit ion assertion a(x,y) ∈ L3

and a conclusion relation r ∈ R. Informally, a rule is satisfied if all pairs forwhich the condition is true are in the conclusion relation r . This, of course,creates a problem if r is mono-valued and too many values can bededuced. This is why we see each rule on a mono-valued relation as aglobal constraint (if the assertion a(x,y) is functional in x, the constraintcaptures the same meaning):

rule[ if a(x,y) then r(x y)])

is replaced by:

constraint[ if [y = r(x)] then a(x,y)]) .

Production rules are the basic tools for building expert systems. Aproduction rule is made of a condition and a conclusion expression. Itssemantics is purely operational and says that if the condition is satisfiedby some objects at some point in time, the conclusion expression should beevaluated. We have investigated various strategies for helping constraintresolution with domain-dependent heuristics and have found that mostheuristics are easily represented by a set of production rules, as related in[Ca91c].

We shall not consider the LAURE production rule paradigm in its fullgenerality in this paper, but rather the practical subset that we need forimproving constraint resolution and to which we can give "clean"semantics. All production rules in LAURE have a similar form: they aredefined with a for_all statement that gives their range of validity; an if L3

condition on one or two variables; and a then statement, which representsthe conclusion expression to be evaluated each time a new pair satisfiesthe L3 condition. The implementation of production rules is done byefficient propagation (e.g., the RETE algorithm [Fo82]). In LAURE, we useformal differentiation (cf. Section 4.2 and [Ca91a]) which supportscomplete compilation into C code.

Propagation rules have the same form as deductive rules (a conditionassertion and a conclusion relation) but are evaluated in a bottom-up

manner (Section 4.2). The conclusion is simply Ri(x y). For instance, hereis a production rule that maintains the maximum salary in a department:

axiom[ for_all (d department)(y integer)if [e:employee exists [works(e) = d] [salary(e) = y] [y > max(d)]

then max(d y)]

Negative constraints are used to forbid some values for a given goal(R,x). The conclusion is [R no x y], and it means that y is no longer apossible value for R(x). Here is an example which says that two queensshould not be on the same line in the famous queens problem (how toplace eight queens on a chessboard):

constraint[ for_all (q queen)(c case)if [z:queen exists [line(place(z)) = line(c)]]

then [place no q c]]

Integrity Constraints can be used to check the integrity of a completion.The conclusion (introduced by the keyword c h e c k) is another L3expression. The associated semantics is that if the conclusion condition isnot verified, an error (contradiction) is raised. Here is the classic databaseexample (an employee shouldn't make more than his manager):

constraint[ for_all (x integer) (y integer)if [z:employee exists salary(z x) [y = salary(manager(z))]

check [x < y]]

Integrity constraints play a very important part in the development ofa knowledge system, independantly of the constraint resolution studied inthis paper. They are implemented as production rules which conclusion isto check some given assertion. Using differentiation, this allows a fast andminimal checking of the condition each time a relevant fact is added to thedatabase.

3. Semantics

3.1 Logic Constraint Satisfaction

A LAURE constraint is a syntactical object that restricts the possiblecompletion of the database instance. It is also a generic constraint since itapplies to possibly many LAURE objects. In this paper we assume that wehave an order-sorted domain O (see [Ca91a] for details) with a classtaxonomy (S,<) that is a sublattice of P(O) (each class is seen as a subset ofO). A constraint is defined as previously:

Definit ion: A constraint is a tuple (s ∈ S, l = ((R1 ƒ1) ,…,(Rm ƒm) ) ,a(x,v1,...,vm)) where s is a class of S, l is a list such that ∀ i, Ri ∈ R1 andf i is a slot on s (instance variable) or the identity function, anda(x,v1,…,vm) is a L3 assertion with free variables {x,v1,…, vm}.

For instance, the two constraints in the previous section would berepresented as:

(LINE, ((cx Id) (cy Id)), [[v1 + [2 * v2]] = 10])

(ABOVE, ((y top) (y bottom)), [v1 > [ v2 + h(bottom(x))]])

We implicitly have a set of unknown values (called goals) Ê R1 × O, onwhich the completion will operate. For each goal (Ri,x), we have a possibledomain, which is d(Ri)(x), and a value y if |d(Ri)(x)| = 1 and d(Ri)(x) = {y}(also written d(Ri)(x) = y). A database instance is complete if it contains nodisjunctive information. In this paper, we suppose that the set of goals isfinite, and we write |d| = |{(Ri,x) ∈ R1 × O, |d(Ri)(x)| > 1}| (thus d is complete if|d| = 0). We call D the set of all database values (R → (O → P(O))), and Dc theset of all complete database values. A solution to a constraint is a completedatabase instance such that all assertions are satisfied:

Definit ion: A constraint (s, ((R1 ƒ1), ... ,(Rm ƒm)), a(x,v1, ..., vm)) issatisfied by a complete database instance if and only if:

∀ o ∈ O, o ∈ c ⇒ |a(o, R1(f1(o)), ...,Rm(fm(o)))|d = true

A constraint satisfaction problem is made of an initial domain valuationd0 and a set C of constraints. A solution is a completed database instance vthat satisfies all the constraints in C such that for all x in O, d(Ri)(x) ∈d0(Ri)(x). A given constraint problem can have many or no solutions. Thesemantics we have given is general in the sense that it applies to any formof constraint assertions [Ca91b]. However, there usually is (partially) away to go from the possible values (d0) to a solution using constraintpropagation. We shall now build a more explicit characterization by usingthe lattice structure on D. For a given database instance d, we now definean arc-consistency function [Ma77] Id(c) ∈ R1 × O → P(O) for all c ∈ C by:

∀ c = (s, l = ((R1 ƒ1), ... ,(Rm ƒm)), a(x,v1, ..., vm)), ∀ i ∈ {1, ... ,m}, Id(c)(Ri,x) = { y ∈ O, ∀ o ∈ fi-1(x), ∃ v ∈ Dc, v > d,

v(ui) = y ∧ |a(o,R1(ƒ1(o)) ... , Rm(ƒm(o))) |v=true}

I d(c)(Ri ,x) is the set of values that can be given to R i(x) in one of thesolutions of the constraint c ( f i -

1(x) is the set of object o such that f i(o)= x). We assume that I d(c) can be computed directly (not by a simpleenumeration of all valuations) so we can define a deduction step with thefunction ε from D → D:

Definition: the deduction function ε is defined by the application ofeach constraint to each unknown value:

(ε(d)(Ri))(x) = d(Ri)(x) ∩ { ∩ Id(c)(Ri,x), c =(s, (...(Ri fi) ...),a)}, ε is isotone (order-preserving): (d1 > d2 ⇒ ε(d1) >ε(d2))

This function represents a complete propagation of the set of possiblevalues through the constraints (which is not always practical). Any

solution of the set of constraints C is a fixpoint of ε by definition, but theconverse is not necessarily true. The deduction function has a leastfixpoint YD(ε), which is not (always) a solution but verifies:

Theorem [Ta55]: YD (ε ) (d0) is smaller than any solution v of theconstraint problem (d0, C). In particular, if YD(ε)(d0)(R)(x) =∅ for some (R,x), there are no solutions.

The idea is to use YD (ε )(d0) instead of d0 to start the enumeration ofpossible valuations because it represents a smaller set. The goal of Section4.1 is to provide approximations of YD (ε) because its computation is tooexpensive. We can now give a characterization of constraints solutions:

Definition: An approximation sequence is a sequence d0, d1 ... dn

such that: ∀ i, |di| = |di-1|- 1, |dn| = 0, di > ε(di-1) A fixpoint approximation sequence is an

approximation sequence such that: ∀ i, di > YD(ε)(di-1)

Theorem: A completed database instance v is a solution of (d0, C) iffeither: • there exists an approximation sequence(di) such that dn = v, • there exists a fixpointapproximation sequence (di) such that dn= v.

Proof: An approximation sequence is equally defined by a sequence ofchoices (Ri(xi) = yi, i = 1 ... n), such that di(Rj) = di-1(Rj) and di(Ri)(x) =di-1(Rj)(x) for x ≠ xi. If v is a solution, we can take an arbitrary ordering inthe goals of d0, which yields a sequence of choices (Ri(xi) = v(Ri)(xi)). Sincev is a solution, it follows that v > Y(ε)(di) for any i , and thus the sequence(d i) is both a fixpoint approximation and an approximation sequence.Conversely, if we consider an approximation sequence (d i ), a givenconstraint c = (s,((R1 ƒ1), ... ,(Rm ƒm)), a(x,v1, ..., vm))), and o a givenobject of s, we consider the smallest i such that all goals (R i , fi(o)) arereduced (a unique value has been assigned). By construction the choice(R i(x i) = yi) for d i is such that there exists j , such that x i = f j(o). Sinceyi ∈ ε(di)(Ri,xi), it follows that |a(o,R1(ƒ1(o)) ..., Rn(ƒn(o)))|di = true, andthus dn satisfies the constraint c for the object o. Thus, dn satisfies allconstraints and is a solution of the initial problem. This theorem (and itsvariations used in Section 4.1) is the basis for showing that constraintresolution algorithms are sound and complete.

3.2 Algebraic Representation

A relational algebra can be formed from some classical operations onbinary relations [McL81]. For our model, these operations are composition(written o ), which is the binary case of the relational join, intersection(written ∩), union (written ∪ ) , inversion (written - 1), and cartesianproduct (A × B is the graph of a binary relation). An important property isthat each operation can be evaluated on a "set-at-a-time" basis. Moreover,efficient compilation techniques relieve us from physically computing the

sets involved in intermediate computations [Ca89]. The algebra A (R) ismade from the set of variables R and the relational operations. Some otheroperations are introduced to capture the object functions. Precisely wedefine:

∀ c ∈ Fc, φ (r1 c r2)(x y) ⇔ ∃ x1, x2, r1(x x1) ∧ r2(x x2) ∧ c(x1,x2) = true ∧ x = y

∀ ƒ ∈ Fo ∪ Fp2, ψ (r1 ƒ r2)(x y) ⇔

∃ x1, x2, r1(x x1) ∧ r2(x x2) ∧ ƒ(x1,x2) = y

We add the notion of term variable to the induced algebra and obtainthe query algebra A (R) defined by:

<term(R)>:: <R> | <P> | <F p1> | <TYPE> × <TYPE> | <term(R)> -1 |

<term(R)> o <term(R)> |<term(R)> ∪ <term(R)> | <term(R)> ∩ <term(R)> | φ (<term(R)> <Fc><term(R)>) |

ψ(<term(R)> <Fo ∪ Fp

2> <term(R)>) |[<z ∉ R>:<term(R)>, <term(R ∪ {z})>]

Each term t of the algebra represents a binary relation on O for anygiven database instance, written d(t). For instance, the semantics of thelatter introduced construction is:

d([z:t1, t2]) = d(t2), with the extension d(z) = d(t1).

A logic assertion and an algebraic term are equivalent if theyrepresent the same relation for every database instance. We have shownthat each assertion could be translated into an equivalent algebraic term,and reciprocally, which means:

Theorem [Ca91a]: For any assertion a(x,y) with two free variables,there exists a term T of A (R) such that: (x,y) ∈ d(T) ⇔|a(x,y)|d = true. Conversely there exists such an assertion ofL3 for any term T of A(R).

The actual translation of an L3 query into an algebraic query isinteresting because among many possible algebraic translations, there isusually one optimal solution. Translation into the algebraic form is basedon rewriting and involves a lot of knowledge about object functions. Theprinciple is to solve the equation assertion(x,y), while considering that x isknown and that y is searched. The result of the resolution is a relationalalgorithm that explains how to get y from x and is represented as a termin our relational algebra.

We can now take each LAURE constraint c =(s,((R1 ƒ1), ...,(Rm ƒm)),a(x,v1,..., vm)) and translate them into m algebraic constraints {Ri Ê Ti } [Ca91a],where T i = t o ƒi

-1, and t is equivalent to the assertion a(x,R1(ƒ1(x)), ..., Ri -

1(ƒi -1(x)),y,Ri+1 (ƒi+1 (x)), ..., Rn(ƒn(x))). The interest of this translation isgiven by:

I(c)((Ri,x)) = {y | (x,y) ∈ d(Ti) } .

We say that the algebraic constraint {Ri Ê Ti} is derived from the initialconstraint set C. A technique for compiling efficiently the computation {y,(x,y) ∈ d(T)} was developed for rule resolution [Ca91a] which can bereused here. Because the relational algebra is a good framework forcompiling, we will now extend our algebraic representation to all logicconstructions defined in Section 2.3.

3.3 Combined Semantics for Rules and Constraints

We use the algebra to represent all conditions from the L3 language. If Ri

is multi-valued (Ri ∈ R*), a rule

rule[ if a(x,y) then Ri(x y)]

is translated into an algebraic rule (t Ê Ri), wheret is equivalent to the L3assertion a(x,y).

Definition: A rule is a formula (Ti Ê Ri) where Ti ∈ A (R) and Ri ∈R*. A database instance d satisfies a rule (Ti Ê Ri) if and only ifd(Ri) Ê d(Ti).

Example : The rule rule[if [z exists friend(x z) friend(z y)] then friend(x y)]is transformed into (friend o friend Ê friend)

The semantics of rule resolution is based on a minimal fixpoint, as usual:

Theorem [Ta55]: For any initial database instance d0, there exists aunique minimal database instance which contains d0 andsatisfies a given set of rules.

Rules will be evaluated top-down, using the Query/subquery withDif ferent iat ion algorithm described in [Ca91a]. If Ri is mono-valued, asimilar rule (rule[ if a(x,y) then Ri(x y)]) is translated into an algebraicconstraint that states that the value Ri(x) must be one of those given bya(x,y)3. Algebraic constraints are also derived from objects constraints(previous section) by considering each goal R i(ƒ i(x)) and generating asolved-form of the condition T i , which gives the value of Ri(ƒi(x)) if allother goals are solved. Thus, we represent constraints and rules with afamily of algebraic constraints, that have the converse form of a rule:

Definition: A constraint is a formula (Ri Ê Ti) where Ti ∈ A (R) and Ri∈ R1. A database instance d satisfies a constraint (Ri Ê Ti) if and only ifd(Ri) Ê d(Ti).

Example : constraint[ for_all (x rectangle)if [l = length(x)] [w = width(x)] [a = area(x)]

then [[l * w] = a] ]is transformed into (length Ê ψ ( /,area,width), area Ê ψ (

*,length,width), …)

3 Thus, if there is a unique y for an object x, we get Ri(x) = y.

Constraints are more interesting since we do not simply search for adatabase which satisfies all constraints (the empty database would do);instead, we look for a complete database instance, which associates onevalue to each resolution goal. Because of the correctness of the translation,we can show that constraints solutions can be expressed as:

Definition: A database instance d is a solution for the constraint (Ri

Ê Ti) if and only if d is complete and d satisfies the constraints.

We now introduce production rules to take care of propagation rules onmono-valued relations, negative constraints, and integrity constraints.An algebraic production rule (Ti ⇒ ƒ) is made with a condition term Ti

and a conclusion action ƒ.

Definition: A production rule (Ti ⇒ ƒ) is made from a term T∈ A (R)and an action ƒ. Its semantics is that ƒ(x,y) is executed each time thedatabase instance changes from d to d' and (x,y) ∈ d'(Ti) ∧ (x,y) ∉d(Ti).

In general, since we have given no order to production rules, this is anon-deterministic operational semantics (the order in which rules aretriggered may be important). In this paper, we only consider three sortsof production rules for which we can give a more precise semantics:

• Propagation rules were introduced with the syntax:

axiom[ if a(x,y) then Ri(x y)] .

The conclusion operation of such a rule is a definite update: d(Ri)(x) ←y. The assertion a is translated into the equivalent term T i and thealgebraic rule is written (T i ⇒ Ri). All propagation rules on a givenrelation Ri are combined with the ∪ operator (T1 ⇒ Ri and T2 ⇒ Ri arecombined into (T1 ∪ T2) ⇒ Ri). We also suppose that R1 is divided into aset of relations that are defined with constraints and a set of relationsthat are defined with propagation rules (no intersection to avoidconflicts). In practice, this occurs since we use propagation rules tobuild and maintain additional information useful for the constraintresolution.

• Integrity constraints were introduced with the syntax:

constraint[ if a(x,y) check a'(x,y)] .

The assertion a is translated into t, and the assertion a' into t' . Theconclusion operation of such a rule is to test if (x,y) ∈ d(t') and raise acontradiction if (x,y) ∉ d(t'). We shall write those production rules (T i

⇒ t')

• Negative constraints were introduced with the syntax:

constraint[ if a(x,y) then [R i no x y]] .

The conclusion operation of such a rule is to remove y from the set ofpossible values d(Ri)(x) → d(Ri)(x) - {y}, assuming that no choice was

made on Ri(x) (in which case the rule is ignored). This implies that wehave a way in the database to make a distinction between Ri(x) = {y}because a choice was made and Ri(x) = {y} because y is the uniquepossible value. A negative constraint, therefore, specifies which valueshould not be taken for a goal when a choice is made and isimplemented as an algebraic production rule. We shall write them (T i

⇒ · Ri) .

Since propagation rules have the same expressive power as a Turingmachine, it is undecidable to know if a the program defined as a set ofproduction rules halts or characterizes uniquely its solution4. This is theprice to pay for introducing a powerful paradigm to describe heuristics. Inthe rest of the paper, we simply call F(Pr ,d) the result of applying to d a setof production rules (in a given order) that is supposed to end and tocapture the intended heuristic. Further research is needed to see if we canidentify a smaller class of production rules with a deterministic semantics,in which useful strategies can still be written.

If we now mix production rules with constraints, we use the previouscharacterization of all solutions to define the semantics of a program madeof an initial database d0 , some rules, some constraints, and someproduction rules:

Definition: Given a set of constraints C and a set of production rulesPr, an computation sequence is an sequence d0, d1 ,... dn such that: ∀ i,|di| = |di-1|- 1, |dn| = 0, di > ε(F(Pr , di-1)). A solution of a program (d0, C,P r ) is a complete database instance which is the last member of acomputation sequence.

Because we have restricted propagation rules (partition on R1), we canshow that a solution of a program (d0, C, Pr) is a solution of (d0, C). Ruleson mono-valued relations are supposed to be evaluated implicitly eachtime a mono-valued relation appears in a logic or algebraic expression,according to [Ca91a]. Therefore, the deductive rule resolution is a slave ofthe constraint resolution.

4. Resolution

4.1 Abstract Interpretation

In this section we give an overview of the general method proposed in[Ca91b], which is itself an application of [CC77] to the resolution ofconstraints. More details and the demonstrations of the results may befound in these two papers. Since the ε computation is done on sets of P(O ),the first step is to build an abstraction P#(O) [Ca91b] of P(O). We call D# thesub-lattice induced by P#(O): D# = {d ∈ D, ∀ Ri ∈ R1, ∀ o ∈ O, d(Ri)(o) ∈ P#}.

4 Consider the following (legal) program: r(x) = 1 ⇒ r(x) = 2 , r(x) = 2 ⇒ r(x) = 1 .

Following [MMS86], we define the abstraction (α ) and concretization (γ)functions as follows:

Definition: We define the abstraction function α by: ∀ d∈ D, ∀ (Ri,x) ∈R1 × O, α (d)(Ri)(x) = ∩ {y, y ∈ P#(O) ∧ d(Ri)(x) Ê y}; we take theidentity on D# → D as the concretization function γ.

In order to build an abstract approximation of ε , we first build anabstract approximation of the relational calculus on A (R). If a binaryrelation on O is represented by a function from ℜ = (O → P(O)) (a functionalview on relations), the algebra A (R) is generated by some operations on ℜ ,such as ∪ , ∩ ... and so on. For each of these operations, we can define anabstract operation ∪ # , ∩ # such that:

(r1# ∪# r1#)(x) = ∩ {y, y ∈ P#(O) ∧ (r1#(x) ∪ r2#(x)) Ê y} ...

To improve the feasibility, we only require that the abstract operatorreturns an abstract set which is larger than the abstraction of the correctresult. Obviously, the closer the abstraction is, the better practical resultwe will get. Therefore, we use as many mathematical properties as we canto improve the prediction. The result is an abstract evaluation d#(T) ofany relational term T in the abstract representation d# = α (d ) of thedatabase instance d, such that:

∀ d ∈ D, ∀ T ∈ A(R), d#(T) ∈ (O → P#(O)) and ∀ x ∈ O, d(T)(x) Êd#(T)(x)

We can now define the abstract deduction function:

Definition: ∀ d# ∈ D#, ∀ Ri ∈ R1 , ∀ x ∈ O,

ε#(d#)((Ri,x)) = d#((Ri,x)) ∩# { ∩ d#(Ti)(x), (Ri Ê Ti) is derived from C}

We have defined a consistent abstract interpretation [CC77]. Bycombining this result with the property of Y(ε)(d0), we get:

Theorem [Ca91b]: ε# has a lower fixpoint operator such thatY(ε#)(α (d0)) is smaller than any solution to the problem (d0,C).

This means that we can consistently reduce the possible domains beforestarting the enumerations of possible valuations (prediction of the possibledomains). Since we have identified an application of the fixpoint Y(ε) tobuild solutions through approximation sequences, we can use abstractinterpretation in a more general manner rather than for simple domainprediction. We define the notion of abstract approximation sequence:

Definition: An abstract approximation sequence is a sequence d0,d1 ... dn such that: ∀ i, di ∈ D#, |di| = |di-1|- 1, |dn| = 0, di > ε#(di-1)

Abstract approximation sequences are easier to generate because thecost of the abstract computation is independent from the database size.However, this is still a sound and complete procedure:

Theorem [Ca91b]: A completed database instance v is a solution of(d0, C) iff there exists an abstract approximation sequence(di) such that dn = v.

We can also define abstract fixpoint approximation sequence, which willconverge faster (there is a smaller set of abstract fixpoint approximationsequences) but with a high complexity of computation (computing Y(ε#) ismore complex).

4.2 Lazy Evaluation vs. Propagation

In the next section, we shall describe an algorithm that builds anexhaustive enumeration of abstract computation sequences; thus, it issound and complete. There are still two freedom degrees upon which theefficiency of the resolution will depend:

• Goal ordering: some problems (for instance, the n-queens with alarge number of queens [VH89]) demand the application of the first-fail principle, which states that the goal with the smallest domainshould be tried first; some other problems, such as placementproblems, hold a better order derived from the object topology.

• Balance between propagation and evaluation: each constraint can beevaluated lazily just before a value is chosen for a goal, or it can bepropagated so as to maintain the domains for all goals as soon as anyhypothetical assignment is made. The previously mentioned first-failprinciple requires some propagation so that the choice madeaccording to cardinality is significant.

In this paper we describe an algorithm that uses the first-fail principlebecause we have found it to be the more commonly useful, but we havealso used some variations (other orders) for other problems such as[GGN90]. The cardinality of each goal (Ri,xi) is the cardinal of the abstractset d#(Ri)(xi). Those sets will be maintained by active propagation becauseof the following.

• Active constraints: each constraint has a mode, that is either specifiedby the user or inferred from some general declarations. A constraintcan be lazy (it will be used with a ε -reduction step at the "lastminute"), abstract-lazy (it will also be used at the last minute for a ε# -reduction step), or act ive. When a constraint is active, the abstractsets are dynamically reduced so that the current database instance isa fixpoint for the ε# reduction function associated to this constraint.

• Negative constraints can be lazy or active. When a negative constraintis active, the negative constraint is implemented as an abstractpropagation rule (cf. Section 3.3).

Active constraints or propagation rules rely on the ability toefficiently propagate an update in the database. We need to know whichnew pairs satisfy a rule condition (an algebraic term) when an updateR i (a ,b ) is made. As was noticed in [FU76] and detailed in [PS77],incrementally computing a set of objects satisfying a given specification isanalogous to mathematical differentiation. Differentiation rules have beendeveloped for database relational algebra ([BR86] or [SKGB87]). A niceproperty of this relational algebra (A (R)) is that differentiation can beintroduced as a higher-order operation [Ca91a].

If we define the induced functional algebra F(R1 ,…, Rn) as A(0,1,R1 ,…,R n), where 0 and 1 are reserved names , each term ƒ of this algebrarepresents a function from O × O to P(O × O) for each database instance d. Byextension, we write this function d(ƒ), which is defined by:

∀ o1,o2 ∈ O, d(ƒ)(o1,o2) = d(ƒ) in A(0,1,R1 , ..., Rn), where d(0) = ∅ , d(1) = {(o1,o2)) and ∀ i, d(Ri) = d(Ri)

The key property of this algebra is the existence of a formal operation∂/∂ called differentiation on A (R) × R → F (R), defined by formal rules. Wewrite ∂t/∂Ri for the differentiate of the term t according to Ri.The interestof differentiation holds in this result:

Theorem: • ∀ d ∈ D, ∀ Ri ∈ R, ∀ (o1,o2) ∈ O × O, ∀ t ∈ A(R), if (o1,o2) does not belong to d(Ri) and if we define a database

instance d' by d'(Ri) = d'(Ri) ∪ {(o1,o2)) and d'(Rj) = d'(Rj) for all other j:

d '( t )= d(t) ∪ d'(∂t/∂Ri)(o1,o2)

• ∂ t / ∂ Ri is the smallest term from F (R) which satisfies theprevious equation

(any other similar term represents a function that alwayscontains ∂t/∂Ri) .

The idea of differentiation can be found in the RETE algorithm [Fo82],where it is a graph operation, or for relational databases, where it isdefined by a database computation [BR86]. In this model, we obtain af o r m a l differentiation (on abstract functions instead of databaseinstances), which provides a better implementation. More details andcorrectness proofs may be found in [Ca91a]. As explained in [Ca89], thedifferentiated terms can be in turn compiled into efficient low-levelfunctions.

4.3 Resolution Algorithm

We shall now describe a resolution algorithm that produces one(possible) solution to a set of constraints, rules, and production rules. Thefirst step is to compute an approximation of the fixpoint, using the abstract

interpretation. We then start the enumeration of all completions, usingthe first-fail principle. The propagation is based on two operations:

• The function obtained by di f ferent ia t ion, ∂ T /∂ Ri(x,y), returns theexact set of pairs that appears in d(T) when (x,y) is added in d(Ri) (cf.previous section).

• Similarly ∂ #T /∂ Ri(x ,S) returns a set of pairs (x ' ,S') where S' is anabstract interpretation of d(T)(x'), which uses the new value S givento d(Ri)(x). Notice that this is just a convenient notation (there is no"differentiation" with abstract interpretation since we must have S' =d#(T)(x') because the new value S is not a positive update).

We use an exception-handling mechanism described in [Don90], whichcatches contradictions raised either by the detection of an empty set ofpossible values or the violation of an integrity constraint. We may nowdescribe the algorithm (the database instance d, the constraints, rules,and production rules are global resources), which solves a list of givengoals. The resolution algorithm [Ca91c] uses two steps: Predict(L) andEnumerate(L).

Predict(L) computes (semi-naive iteration) the fixpoint Y(ε#) [Ca91b] forthe goals in L. We apply each reduction step (ε#) for each relevant ruleuntil no further reduction can be performed. Enumerate(L) builds all thepossible approximation sequences using a ε -reduction step for lazyconstraints, a ε#-reduction step for abstract lazy constraints and a Y(ε#) -reduction step for active constraints. The backtrack mechanism relies onthe ability to make copies of the database and return to previously storedstates. Fortunately, this is supported efficiently in the LAURE system[Ca91a]. Whenever a new fact Ri(x,y) is obtained (for instance, a choiceR i (x) = y is made by the constraint solver), it is propagated usingdifferentiation to activate all relevant production rules and using theabstract computation to reduce the domains of the current goals.

This algorithm is sound and returns one possible solution. With a minormodification, we can use it to build the set of all solutions. Thecompleteness relies on the fact that the algorithm builds all computationsequences because of the respective properties of abstract interpretationand differentiation. Since solutions are complete computation sequence bydefinition, the result follows. Notice that because of the characterization ofSection 3.1, a corollary is that the algorithm finds the exact set of allsolutions for a "pure" constraint problem(d0, C) with no production rules.

The implementation has been described in other papers [Ca89,91a] withmore details. Here we just give some principles, that may explain some ofthe good results that will be presented in the next section. Each rule orconstraint is transformed into an equivalent algebraic form which holdsno logic variables and can be compiled into low-level (C) code. The ability ofdirect procedural compilation is one great advantage of combinatoric logic.The translation is performed before run-time, and the algebraic form isactually the representation of an imperative computation. The practical

application of this property is presented in [Ca89], which shows howcompiled demons are produced from logical rules. Each rule, axiom orconstraint is actually stored as a set of equivalent demons, stored in thedemon attributes of the relations. The logic language L3 is implemented asan extension of the LAURE programming language. Resolution algorithmsare just reduced to triggering the right compiled functions, with very littleoverhead, and the unification (top-down) or pattern-matching (bottom-up) work is entirely performed during the compilation.

The current implementation uses LAURE's own main-memory objectmanagement. This makes LAURE a deductive database language ratherthan a true database. However, we have tried large problems using virtualmemory and obtained good results (task assignment problems, largetransitive closures). We believe that our resolution techniques are wellsuited for a large volume of information. The main reason is the tightcoupling with the object-oriented model, which supports the efficienthandling of a large domain through set organization. Our current work isto use C++ as a common object layer, to interface LAURE with a commercialOODBMS. This will add persistency to LAURE objects and complete ourdatabase system.

5. Results

5.1 Constraints Classics

Comparing LAURE with other languages is difficult. When all solutionsare needed, our experiments have found that ad-hoc (non declarative)PROLOG programs were faster than most constraint solvers. For finitedomains constraints, when one solution is needed, the CHIP [VH89] systemis a better candidate. Since we have used LAURE and (compiled Quintus3.0) PROLOG on a SUN Sparc1, we divided numbers given in [VH89] by 10,to take into account the better hardware and the better performance thatnew implementations of CHIP-like systems now achieve and we alsomodified the times reported with other machines in [VD91] and [AB91](Figure 1). Since this is an empiric approximation, the results are onlysignificant by their order of magnitude.

For instance, constraint solvers are usually not very fast to find all thesolutions of the 8-queens problem (an ad-hoc PROLOG program is fasterwith 330ms for all solutions). The result in the first example of Figure 1says that a naive LAURE program (three small constraints) is faster thanthe complex PROLOG program. When the number of queens grows, aconstraint-resolution strategy starts to pay (the previous PROLOGprogram fails).

The second example is the classic cryptarithmetic puzzle SEND+MORE =MONEY. The domain reduction methods used in the CHIP system [VH89]allow the reduction of those sets of possible values in such a way that onlyone backtracking is necessary to find the solution. This result is also

obtained with LAURE, which was expected since our abstractinterpretation captures the dual representation of the CHIP system. Thetotal computation time for LAURE is 12ms with active constraints and 6mswith abstract lazy constraints, which compares correctly to the CHIPapproach. All the execution time for active constraints is spent in theabstract fixpoint computation, but compilation gives performance that isalmost comparable to a hand-coded implementation (such as CHIP'sdomain reduction procedure).

On some other constraint problems for which there is a good strategy,LAURE performs even better when compared to other constraints solvers.For instance, LAURE solved the 8th magic series problem [VH89] in 170ms, whereas newer CHIP compiled implementations are in the 1s range ona SUN4.

Problem LAURE other

8 queens (all solutions) 200 ms 330 ms Prolog

64 queens (one solution) 200 ms 250 msCHIP* [AB91]

SEND+MORE=MONEY (one solution) 6 ms 6 ms CHIP/10[VH89]

8th magic series (one solution) 170 ms 1.3 s cc(fd) [VD91]

House problem (all solution) 50 ms 120 ms CHIP/10 [VH89]

Figure 1: Classics (SUN SPARC1 Workstation)

5.2 Real-Life Problems

Our conclusion from these small problems is that LAURE is an efficientconstraint solver, in the same range (at least) of the newer and fasterimplementation of the CHIP system. This is obtained with a more generalsystem, which supports constraints on object hierarchy and can beextended with production rules. When production rules are used to helpthe constraint resolution (such as for the magic series), performance canbe increased by an order of magnitude. Similar results were also obtainedwith the PECOS language [PA91], which also combines constraints andobjects. Real-life (or larger) problems are more interesting, but it is alsomore difficult to set up a fair comparison. In the rare cases where theproblem is totally exposed, there are still many tricks used in testingprograms which modify performance significantly.

A good example is the building of a five-segment bridge, taken fromBartusch's PhD thesis and reported by P. Van Hentenryck in [VH89]. Thisproblem is made of 46 tasks, with precedence, sharing, and domain-specific constraints. Its interest is to be both a representative problem anda well-described one. We first wrote a simple, declarative LAURE program,with five generic constraints that were instantiated into 250 objects.

Following the indications in [VH89], we used an extra attribute (orderingon shared tasks), so as to take care of mutual exclusion first. It is a well-known strategy that, when each pair of exclusive tasks have beenordered, the optimal schedule is found through a graph computation ofthe atleast and atmost date for each task [VH89]. Although LAURE has nospecific knowledge about how to solve inequations, abstract interpretationof the scheduling constraints (incremental updates of the abstractdomains as soon as any new hypothesis is made) mimic the deterministiccomputation of the at least and atmos t date. This is done with similarefficiency to the original CHIP implementation. To extend LAURE with someknowledge about scheduling problems, we added a set of four axioms thatincrementally compute the two extra attributes atleast and atmost and weordered the tasks according to their durations. This new program is muchfaster. It finds the optimal solution in 200 ms and its proof of optimalityin 2 s on a SUN Sparc1. This is slightly faster than the 3s reported in[AB91] or the 5s obtained with cc(fd). However, for instance, usingredundant constraints and a better organization (different from the onein [VH89]), a PECOS program only needs 1.5s. For this problem, LAURE isalso in the same range of efficiency, and we keep a definite conclusion for amore detailed analysis.

LAURE is now being tested in a very large scheduling-assignmenttelecommunications problem (many thousands of tasks). In this problem,the complexity barrier is too high, and we need to make somesimplifications, using heuristics. These heuristics involve variousadditional pieces of information that can be computed with productionrules. In this large example, we actually use the production-rule paradigmin its full generality [Ca89] (the conclusion of the production rule can beany expression of the host language), which is quite versatile but bringsus even further from a clean declarative semantics. The production rulesare the interface between the constraint resolution and a library ofalgorithms described with m e t h o d s in the LAURE object-orientedlanguage. The efficiency of this hybrid approach is guaranteed by thecompilation of production rules through differentiation. We have also usedLAURE for automatic layout problems [GGN90], where the disjunctiveabstract interpretation gives very good results. Those two last examplesshow the real problems which LAURE is eventually used for.Unfortunately, it is more difficult to evaluate performance, both becausethose two problems do not fit readily into existing available constraintsolver, and also because the comparison should include the time spent indevelopment. Ultimately, to goal of a constraint solver is to provideperformance which is comparable to a low-level implementation at a muchlower cost.

4.3 Comparison with Related Work

LAURE is a general constraint solver for order-sorted finite domains.Although it may be seen as a Constraint Logic Programming language,

LAURE is very different from CLP(R) [CLP], PROLOG-III or other systemsintensively based on Horn-clause resolution because it uses no logicvariables and deals with global constraints. The LAURE resolution strategy,including the prediction phase, is directly inspired by work performed atthe ECRC on the CHIP system [DSVH87] [VH89]. The main contribution is toextend integer techniques related in [VH89] to arbitrary order-sorteddomains, using abstract interpretation. Two other important contributionsare the algebraic framework, which supports efficient compilation, and theintegration with production rules, which permits domain-specificextensions.

A lot of work has been done to integrate constraint resolution into logicprogramming languages: real number constraints into Horn-clauses(CLP(R) family); integer constraints into order-sorted logic (LIFE [AKP90]);finite (flat) domains (actually integer) constraints into PROLOG (CHIPfamily [VH89]); or various constraints theories into DATALOG [KKR90].Our work is at a lower level since we deal with the actual resolution ofconstraints, not their integration into another language. For instance, if weuse this work as a theory of constraints over an order-sorted domain, itmakes perfect sense to study CLP(O) [JL87], where O is our order-sorteddomain. This is actually a subject for further research, such as using thisconstraint theory for the constraint scheme used for LIFE [AKP90]. As acontribution to the theory of constraints over an order-sorted domain,this approach is very general and could be adapted for any object-oriented constraint solver. It is our intuition that most efficient constraintsolvers on object-oriented domains use techniques to reduce the searchspace that could be easily described with an abstract interpretation.Representing a domain reduction algorithm as an abstract interpretationhas two advantages: it gives a consistency result [CC77], and it gives toolsto compare and combine techniques using the lattice of abstractinterpretat ions.

It is still an open question to find out if introducing production rules isan overkill. Because there is no simple semantics for productions rules,some of the declarativeness is lost when we introduce production rules. Onthe other hand, we have found that most heuristics translate easily intoproduction rules, because of their expressive power (we have also foundthat trying to mimic constraint resolution with production rules is veryinefficient). Our current research is to identify a smaller production ruleslanguage (only the propagation rules cause problems). There are manypossible syntactical restrictions that would yield a nicer semantics, but wedo not know yet if we would still be able to use them for real-life situations.From a practical perspective, LAURE is close to commercial expert-systemshells such as ART or pro-Kappa. However, LAURE includes a sophisticatedconstraint solver which we think is mandatory in an object-orienteddeductive system. In addition, we have found LAURE to be much faster onpure production-rules applications, such as small expert-systembenchmarks. Because differentiation produces only the new relevantobjects, propagation is performed with the minimal number of

computations [BR86], whereas the graph of nodes built into RETE is onlyan approximation of this property. In addition, differentiation produces asequence of computations that can be executed without any special datastructure, whereas the RETE algorithm requires a complex graphstructure to be maintained.

This work shares many similarities with many theoretical approaches tomerging object-oriented and logic programming [Ku85] [AK89] [AKP90].The closest example is the revisited O-logic [KW89], which is also intendedas a framework for AI programming. The LAURE model is a strict subset ofthis more ambitious model but is able to propose realistic implementationtechniques from these restrictions [Ca91a]. In addition, the LAURE modelallows explicit representation of disjunctive information, which we think isa very useful feature for deductive object-oriented database applications(cf. Section 1.1). There is some similarity (in the motivations) between theLAURE data model and OR-objects for representing disjunctiveinformation [INV90] although the hierarchical aspect (order-sorteddomain) plays a critical role in the LAURE model [Ca91a]. Another subjectfor further research is the adaptation of the constraint resolution theory,upon which LAURE is based [Ca91b], to OR-objects.

6 .Conc lus ionThis paper has identified a research domain, investigated three

technical issues and proposed a proven solution. We have motivated theintegration of global constraints into object-oriented database from anapplication point of view. We have proposed a semantics for object-oriented constraints, which translated easily into a relational algebra, thusgiving tools for optimization and compilation. We developed an abstractinterpretation technique that extends previously known integer domainreduction methods to any order-sorted domain. We have argued thatsome room should be left to domain-specific heuristics to solve realisticlarge problems and that productions rules are a natural way to go. Wehave proposed, based on the above-mentioned techniques, a resolutionalgorithm that has proven to be efficient in practical examples.

A c k n o w l e d g m e n tThis work has benefited from fruitful discussions with Hassan Aït-Kaci

and Pascal Van Hentenryck. I would like to thank Drew Adams, FrancoisMonnet and Diane Hoffoss for their support and encouragements. I am alsograteful to members of our database research group at Bellcore, includingSam Epstein, Madhur Kohli, Shamim Naqvi, and Yatin Saraya.

R e f e r e n c e s[AB91] A. Agoun, N. Beldiceanu: Overview of the CHIP Compiler. Proc. of

the 8th ICLP, Paris, 1991.

[AKG87] S. Abiteboul, P. Kanellakis, G. Grahne. On the Representation andQuerying of Sets of Possible Worlds. Proc. of ACM SIGMOD, 1987.

[AK89] S. Abiteboul, P. Kanellakis. Object Identity as a Query LanguagePrimitive. Proc. ACM Conf. on Management of Data, 1989.

[AKP90] H. Aït-Kaci, A. Podelski. The Meaning of Life. PRL ResearchReport, DEC, 1990.

[BMM89] A. Borning, M. Maher, A. Martindale , M. Wilson. Constra intHierarchies and Logic Programming. Proc. of the 6th ICLP , Lisbon,June 1989.

[BR86] F. Bancilhon, F. Ramakrishnan. An Amateur's Introduction toRecursive Query Processing Strategies. Proc. ACM SIGMOD Conf. onthe Management of Data, Washington, May 1986.

[Ca89] Y. Caseau. A Formal System for Producing Demons from Rules.Proc. of DOOD89, Kyoto 1989.

[Ca91a] Y. Caseau. A Deductive Object-Oriented Language. in the Annalsof Mathematics and Artificial Intelligence, Special Issue onDeductive Databases, February 1991.

[Ca91b] Y. Caseau. Abstract Interpretation of Constraints over anOrder-Sorted Domain. Proc. of ILPS, San Diego, October 1991.

[Ca91c]Y. Caseau. Rule-Aided Constraint Resolution in LAURE. PDK91, toappear in Lecture Notes in Computer Science, 1991.

[CC77] P. Cousot, R. Cousot. Abstract Interpretation: A Unified LatticeModel for Static Analysis of Programs by Constructions orApproximation of Fixpoints. Proc. Fourth ACM Symposium ofPrinciples of Programming Languages, 1977.

[CLP] N. Heintze & al.: Constraint Logic Programming: A Reader. Proc. 4thIEEE Symposium on Logic Programming, San Francisco, 1987.

[FU76] A. Fong, J. Ullman. Induction Variables in Very High LevelL a n g u a g e s . Proc. Third ACM Symposium of Principles ofProgramming Languages, 1976.

[Don90] C. Dony. Exception Handling and Object-Oriented Programming:Towards a Synthesis. Proc of OOPSLA'90, Ottawa, 1990.

[DSVH87] M. Dincbas, H. Simonis, P. Van Hentenryck. Extending EquationSolving and Constraint Handling in Logic Programming.Colloquium on Resolution of Equation in Algebraic Structures,Austin, May 1987.

[Fo82] C.L. Forgy. RETE: A Fast Algorithm for the Many Pattern/ManyObject Pattern Matching Problem. Artificial Intelligence, no 19,1 9 8 2 .

[G&al90] M. Ganti, P. Goyal, R. Nassif, P. Sunil. An Object-OrientedDevelopment Environment. COMPCON, Feb 1990.

[HS89] R. Hull, J. Su. Untyped Sets, Invention, and Computable Queries.Proceeding of PODS-89, Philadelphia, 1989.

[INV90] T. Imielinski, S. Naqvi, K. Vadaparty. Querying Design andPlanning Databases. Proc. of DOOD91, Munich, 1991.

[JL87] J. Jaffar, J.-L. Lassez. Constraint Logic Programming. Proc. ACMSymp. Principles of Programming Languages, San Francisco, 1987.

[KKR90] P. Kanellakis, G. Kuper, P. Revesz. Constraint Query Languages.Proc. of 9th ACM PODS, 1990.

[KW89] M. Kifer, J. Wu. A logic for Object-Oriented Logic Programming(Maier's O-Logic Revisited). Proceeding of PODS-89, Philadelphia,1 9 8 9 .

[Ku85] G. M. Kuper. The Logical Data Model: A New Approach to DatabaseLogic. PhD Dissertation, Stanford University, 1985.

[Ma77] A. Mackworth: Consistency in Networks of Relations. ArtificialIntelligence vol.8, 1977.

[McL81] B.J. MacLennan. Programming With A Relational Calculus. Rep n°NPS52-81-013, Naval Postgraduate School, September 1981.

[Mel86] C.S. Mellish. Abstract Interpretation of Prolog Programs. Proc.Third Int. Conf. Logic Programming, 1986.

[MS90] K. Marriott, H. Sondergaard. Analysis of Constraint LogicPrograms. Proc. of the NACLP, Austin, 1990

[PA91] J.F. Puget, P. Albert: PECOS: programmation par contraintesorientée objets. Génie Logiciel et Systèmes Experts, vol. 23, 1991.

[PS77] B. Paige, J.T. Schwartz. Expression Continuity and the FormalDifferentiation of Algorithms. Proc. Fourth ACM Symposium ofPrinciples of Programming Languages, 1977.

[SKGB87] H. Schmidt, W. Kiessling, V. Guntzer, R. Bayer. C o m p i l i n gExploratory and Goal-Directed Deduction into Sloppy Delta-I terat ion. Proc. of the Symposium on Logic Programming, SanFrancisco, 1987.

[Ta55] A. Tarski. A Lattice Theoretical Fixpoint Theorem and itsApplication. Pacific Journal of Mathematics n° 5, 1955.

[VHD91] P. Van Hentenryck, Y. Deville. The Cardinality Operator: A NewLogical Connective for Constraint Logic Programming. Proc. of the8th ICLP, Paris, 1991.

[VH89] P. Van Hentenryck. Constraint Satisfaction in Logic Programming.The MIT press, Cambridge, 1989.

[Vi86] L. Vieille. Recursive Axioms in Deductive Databases: TheQuery/Subquery Approach. Proc. First Intl. Conference on ExpertDatabase Systems, Charleston, 1986.