Query optimization in object-oriented knowledge bases

Data & Knowledge Engineering 3 (1988/89) 285-302 North-Holland

285

Query optimization in object-oriented knowledge bases* Phffip C. S H E U * * , R.L. K A S H Y A P and S. Y O O School of Electrical Engineering. Purdue University, West Lafayette, IN 47907, USA

Abstract. We define an object-oriented knowledge base to be a deductive knowledge base that is based on an object model. One of the major advantages provided by object-oriented knowledge bases is that the first order language used for object description can be used as a query language as well. Since object-dependent procedures are included in this framework, the problem of query processing is nontrivial. On one hand some attributes involved in a query need to be derived from a procedure and constrained by some other relations, and therefore combinatorial explosion may occur; on the other hand a query may be specified in an improper order such that the search space becomes intolerable large. In this paper we first describe two approaches to optimize the query evaluation process: the semantic optimization approach and the conjunct reordering approach. Next, we examine the problem of logical query processing when an object-oriented knowledge base is built on a relational database such as Ingres.

Keywords. Knowledge base, Relational database, Query optimization.

1. Introduction

An object-oriented knowledge base is a database that is constructed based on an object data model [20]. It is intended to enhance the existing semantic databases with formal representation and more procedural semantics. The formalism is designed to capture more of the meaning of an application environment than is possible with contemporary semantic databases. Using matheinatical logic as representation, an object-oriented knowledge base is able to support classification, aggregation, generalization, and association. Specifically, it is able to describe objects, object classes, attributes of objects, inter-class relationships, intra-class relationships, methods to access objects, concepts associated with objects, properties of objects, class derivation, attribute derivation, sets of objects, procedures to update objects, and transactions. More importantly, queries are specified with high level concepts associated with objects without worrying about implementation details. The framework of object-oriented knowledge base is significantly different from most knowledge base frameworks (see e.g. [8, 13]) in the following aspects: (a) Since it deals with objects explicitly, more semantics can be associated to different entities. (b) It treates procedures as first-class entities, and therefore our knowledge about procedures can be included and used. In this paper we first describe a semantic transformation technique which employs rewriting rules to transform a conjunctive query into a form that is semantically related to the original problem, but can be evaluated much more efficiently. We also describe * This research is supported in part by the National Science Foundation under grant number CDR-85-00022. ** Author's current address: Dept. of Electrical and Computer Engineering, Rutgers University, Piscataway, NJ 08855, USA. 0169-023X/89/$3.50 (~ 1989, Elsevier Science Publishers B.V. (North-Holland)

286

P. Sheu. R.L. Kashyap and S. Yoo

approaches to order the conjuncts in a query once it has been transformed semantically. Two appraoches, namely the cheapest-first approach and the most-expensive last approach are compared. After discussing the semantic transformation technique and the conjunct reordering approaches in a rather general knowledge base environment we describe a logical query evaluation strategy that has been developed for a knowledge base built on a relational database. As an object-oriented knowledge base is defined in terms of first-order logic and a relational database can be viewed as an interpretation of a first-order language [26], extentional facts in an object-oriented knowledge base can be maintained in a relational database t. One major advantage provided by this approach is that many of the storage/ access optimization techniques available in conventional (relational) database management systems can become available in supporting low-level management functions in an objectoriented knowledge base. Following this approach, an object-oriented knowledge base accepts logical queries from users and generates Quel programs which can be sent to Ingres. in an object-oriented knowledge base, a logical query is a conjunctive formula which includes relational predicates and/or method predicates. When a relational predicate is expanded with deductive laws, it can be either recursive or non-recursive. A rule/goal graph is built for relational predicates in a logical query. Quel programs are generated for non-recursive relational predicates and they are evaluated by Ingres. For recursive queries, a series of conjunctive formulas is generated and each conjunctive formula can be translated into a Quel program. To eliminate unnecessary operations, any common sub-expression is processed only once and saved as a temporal relation. Because some method predicates need to be evaluated, interactions between an object-oriented knowledge base and Ingres are necessary for logical query evaluation. This paper is organized as follows. In Section 2 we review the essences of the framework of object-oriented knowledge base. In Section 3 and Section 4 we describe a semantic transformation approach and two conjunction reordering strategies for query optimization. In Section 5 we describe a logical query evaluation strategy when the system is built on ingres. Finally, comparison with related work is given in Section 6.

2, Object-oriented knowledge bases In an object-oriented knowledge base, entities that correspond to the actual objects in an application environment are organized into classes. Objects in the same class share the same properties and public interface, and characteristics of database entities are described by attributes. Attributes can be primary or secondary: primary attributes are our a priori knowledge about the object and second attributes are characteristics that can be derived form the primary attributes. The entities of a database are not independent in general, but rather are logically related by means of relations. This is also true for classes and attributes. Methods are associated to object classes. Methods are usually defined in a procedural language and provide type-dependent operations to entities in a class. For example, methods cen be called to retrieve data, to derive secor~dary attributes from primary ones, and to update data. To represent static or dynamic knowledge which cannot be conveniently expressed using attributes or methods, in an object-oriented knowledge base deductive laws and integrity co~zstraints can be stated. Deductive laws and integrity constraints are defined in logic and stored in a rule base. Semantically, deductive laws define views, secondary attributes, and Ill this pa[,er we assume lhat ingres 124] is used without losing generality.

Query optimization in object-oriented knowh, dge bases

287

self-knowledge (e.g. conflict resolution in attribute inheritance). Deductive laws are applied when queries are evaluated. On the other hand, integrity constraints ensure the consistency of a database and they are applied whenever a database is updated. Formally, an object-oriented knowledge base is a tuple (A, G, IC, DL) where A is a first order object language, G is an object representation of A, IC is a set of integrity constraints, and DL is a set of deductive laws. The classes C t, C 2 , . . . , C,, are members of a fixed countable set U (the universal class). When a class is viewed as a table of objects, the names of its columns are called attributes, where the values of the attribute A i range over D~ or Domain(Ai). For each class C, we define a set of methods M c = { Met . . . . . M,.,,,} Considering an object base, i.e. a set of classes and their associated methods, we define the first order language consisting of: a set of constants (written in lower case letters), a set of variables (written in upper case letters), a set of predicates (in lower case) to describe objects, an n-place predicate symbol c:mcj for each of the n-ary method M,.j associated to class C. (For simplicity, we shall refer to the predicates obtained from methods as method predicates.) Then, with an obvious valuation [21], G constitutes an interpretation of the just built first order language, where variables range over 41 and (1) class(a) is true if a is the name of a class of objects. (2) instance_of(a,b) is true if object a is a member of class b. (3) subclass_of(a,b) is true if class a is a subclass of class b. (4) attribute(a,b,c,d) is true if every object in class a has b as its cth attributes, and the domain of b is d. (5) c:a(x~ . . . . . x,) is true if a is a method associated with the object c and has the arguments x t . . . . . x:. We call c:a(x I . . . . . xr) a method predicate. (6) f(x I . . . . . x,,) is true if (xl . . . . . x,,) is a member of a user-defined relation f. (7) f ( x t , . . . , x,,) is true if the class f has an object with value x~, 1 ~< i -< n, for its ith attribute, in cases (6) and (7), we call f ( x ~ , . . . , x,,) a relational predicate. The first order language just introduced provides a syntax by which integrity constraints and deductive laws can be asserted. With these, the associated knowledge base can be assured consistent and new objects can be derived from existing ones. The general form of clauses that can represent integrity constraints and deductive laws is: t ' t A P: A ' ' " A P k - ' * R I v R~. v "'" v R,i

where P#'s and R,/s are predicates, q is typically one or zero. (If q is zero, then the rule is an integrity constraint.) It is not difficult to discover that a logic system as described above provides a framework in which the essential concepts of database, logic programming, and object-oriented system can be nicely coupled. We shall expand this point through various examples in this paper.

Example I. Suppose we have object classes box(id, x_origin, y_origin, x_length, y_ length), basic_block(id, box, color), and layout(id, function, polybox). A definition of this database in logical form can be the following:

[]

class(box) ' attribute( box,id, l ,string ) attribute( box,x_ origin ,2,real ) attribute( box , y_ origin ,3, real ) attribute( box,x_length, 4,real) attribute(box, y_ length, 5, real )

P. Sheu. R.L. Kashyap and S. Yoo

288

method(box,move) method(box, reshape) method(box,shade) method(box,draw) method(box,intersect) method(box,area) method(box,rotate) []

class(basic_block) attribute(basic_block, id, 1,string) attribute( basic_block, box, 2, box) attribute(basic_block, color, 3,string) t method(basic_block, optimize) method(basic_block,fuse) method(basic_block,fuse) method(basic_block,well_formed)

[]

class(layout) attribute(layout, id, 1,string) attribute(layout, function,2, function) attribute(layout, polybox,3, polybox ) method(layout, optimize) method( layout, bb )

Example 2. Based on the database defined in Example 1, we may like to construct a view "diffusion_box" which includes basic_blocks whose color is green. This view can be expressed by the rule: (Rule 1) diffusion_box(Id, Box, Color)~basic_block(ld, Box, Color) A (Color = green). Similarly, views "tiny_layout" and "butting_contact" can be expressed by the rules: (Rule 2) tiny_layout(Id, Function, Polybox)~layout(Id, Function, Polybox) A Polybox:bb(A) n A:size(B) n (B <~400) (Rule 3) butting_contact(BC)<--4diffusion_box(DB, Box1, Color) nbox(B, Box2, Colorb) n Boxl :intersect(Box2, BC) A BC:width(W) A BC:length(L ) n (W <~1) A (L <<-1) Rules 1, 2, and 3 are deductive laws. A typical example of integrity constraints is (Rule 4) diffusion_box(DB1, Box1, Color) n diffusion_box(DB2, Box2, Color2) n

Box1 :distance(Box2, D)---->(D>I 3). Rule 4 says that two diffusion_boxes must be separated by at least 3 units.

3. Knowledge-based query optimization A logical query in an object-oriented knowledge base can be represented in the following form: {x,

...

(3B,,,)(f,

A ""

A L)}

where Xi's are result variables, i.e. variables that a user wants to get as a result of the query, and f~'s are predicates. In a conjunctive formula, all variables are existentially quantified. A

Query optimization in object-oriented knowledge bases

289

conduct f~ is a relational predicate or a method predicate. A method is predicate of the form: obj: method_name(i l, . . . , ira, o 1 , . . . , o n ) ,

where obj is an object, method_name is the name of the method, i's are input arguments, and o's are output arguments. A predicate which matches some deductive laws is expanded before the predicate is evaluated. Some example queries are: (a) { A ] polygon(a) ^ contains(A,a) ^ contains(null, A)} {*Find the largest superset of a*} (b) {B[ polygon(a) ^ a:optimize(B) ^ B : m b b ( C ) ^ C:size(D ) ^ (D ~ 12000)} {*Find an optimization of the layout a such that the size of the resulting minimal bounding box does not exceed 12000*} (c) { PI synchronous_cell(g) ^ g:papth(a,b,P) ^ g:delay(P,L ) i~ lesseq(L,r)} {*For a synchronous cell circuit g, find an electric path between two terminals a ad b with delay no more than r*} In general, the scope of queries in an object-oriented knowledge base can be much wider than that in traditional databases. On one hand we can query the structural information about objects (e.g. query (a)); on the other hand we can retrieve objects based on secondary attributes (e.g. B in query (b); P in query (c)), which is not possible in conventional databases. As in deductive databases, a query in an object-oriented knowledge base is a theorem to be proved. In a small system where the facts (extentionai database) and the rules (intentional database) are relatively few in number, a simple interpretive method employing the depth-first-left-right control strategy as used in standard PROLOG is sufficient to generate the entire search space of answers for a given query. The search space is small and hence answering queries can be done efficiently even with exhaustive search strategies. However, for systems of reasonable complexity, the simple generate-and-test evaluation mechanism may suffer from the fact that method predicates can be part of a query (e.g. path in query (c)), evaluation of queries in an object-oriented knowledge base may involve significant complexity. To see this, consider query (c). If we employ the interpretive method to the above queries, we will have to enumerate all the possible paths between a and b in g, which is intolerably inefficient even when g is not large. Fortunately, in many situations we may get around these problems through the program transformation technique [6, 18]. The basic idea behind the program transformation approach is similar to that of the compiled approach in deductive databases (see e.g. [3, 4, 9, 14]), although the same approach cannot be applied here directly since a query involving method predicates may not be pure relational. In a transformation system, there are four components: the intentional processor, the conjunct reordering processor, the query interpreter, and the extentional database. The intentional processor accepts a query f as its input and producuces an equivalent query f ' by applying rewriting rules [2]. Subsequently, the conjuncts in the transformed query f ' are reordered to minimize the evaluation cost. Finally, the reordered query f" is interpreted by the interpreter through the standard theorem proving technique used in PROLOG. As an example of the semantic transformation approach, assuming that associated with the class synchronous_cell, we have an efficient algorithm called G:shortpath(A .B,P,R), which asserts the existence of a path P of length less than or equal to R between vertices A and B in a circuit G. This statement can be expressed as a rewriting rule (1) given below of the form (which means the formula R H S can be replaced by the formula L H S ) LHS ~ RHS

P. Sheu, R.L. Kashyap and S. Yoo

290

(Rewriting Rule 1) G : s h o r t p a t h ( A , B , P , R ) ~ G : p a t h ( A , B , P ) A G:length(P,L ) ^ lesseq(L,R) We also know that finding an electrical path which does not pass through a specific terminal is equivalent to finding a path in a modified circuit which excludes the undesirable terminal from the original circuit. The above knowledge can be described by rewriting rule (2): (Rewriting Rule 2) G:remove(C,G') A G ' : p a t h ( A , B , P ) ~ G : p a t h ( A , B , P ) ^ -.- G:member (C,P), where G:remove(C,G') is a method to remove a terminal C from a circuit G and the resulting circuit is G'. With this, query (c) can be transformed to c' after applying rewriting rule (1): (c') { P l synchronous_cell( g) A g:shortpath(a,b,P,r) } . Note that the notation :::> (in f=>r) only means f implies r; consequently query transformation with the use of rewriting rules may not preserve the same set of answers for a query. In order to replace f (in a query) by r, we need to have both rewriting rules f ::> r and r =), f. In case f => r does not exist but f <:: r exists, applying the rule f,(:: r may eliminate some answers from the original query. In this situation, supposing that the cost of evaluating r is less than that of ]~ one reasonable strategy is as following: evaluate r first; if the answers for r are not acceptable, then evaluate f.

4. The conjunct reordering problem Given a query of the form {X I ft A f2 A "'" fM}, and assuming that the depth-first-leftright evaluation strategy is used to evaluate a conjunctive query, the conjunct ordering problem is to order ]'1 . . . . . f,, such that the total cost of evaluating the query can be minimized. The conjunct-ordering problem has been shown to be NP-complete [26]. Thus in the worst case, it is necessary to examine a large number of possible conjunct orderings for a set of conjuncts. Fortunately, we can usually do much better than this without sacrificing optimality. One common heuristic [22] for ordering conjuncts is to take the "cheapest" conjunct next at each stage in the ordering process. More precisely, the cheapest conjunct is chosen first, then assuming that those variables will be found, the cost of each remaining conjunct is evaluated, and the process is repeated. While the cheapest-first heuristic works very well for some particular problems, there are many simple examples where it fails miserably. Theoretically, it is not difficult to see why the cheapest-first approach fails in many situations. Given a sequence of conjuncts t = f~ ^ - . . A fM tO be evaluated from left to right, let n i ~ f~[ be the size of the search space of f/. Let avg(f/; A) be the average number of tuples which satisfy £, assuming A is a set of conjuncts and all the conjuncts in A have been solved. We define the "reduction factor" of f~ due to f~ as

or;j=

,,vg f,; {L})

forl~
]~
(1)

II i

Also, we assume that for each f~, the cost of generating a solution is uniform; consequently,

Query optimization in object-orienwdknowledge bases

291

the total cost of evaluating t according to the above order would be: COSt(t) = ~ n u m s o l ( t t . , ) ,

(2)

i

where t~.i = f~ ^ "'" ^ f~ and numsol(t~.i) is the number of variable tuples which satisfy the conjunctive formula t~.~. Based on the above definition, we can represent numsol(tl.~) as: (3)

n u m s o l ( tl.i ) = (n , )(n2a2, ) . . . (n iail . . . ai{i_ , ~)

or, alternatively, numsol(t,.i)=

n,)(

(4)

1-[ a t * ) . k
Since t = t l. M = fl A ' ' " A fM, from (3), we can obtain COSt(t) = ~ i=!

nj -

ohk .

(5)

o,,)

(6)

k
Since

M

oumsol,t,=(nn,)( n I<~i<~M

is a constant for a given set { f 1 , - - - , fro}, we can scale cost(t) by n u m s o l ( t ) and obtain COSt*(t): COSt*(t) ,,._.

nl + a 2 , n , n 2 + " " + n , n 2 . . ,

nM_znM(a2,)(%2)(a3,)''"

" " (t~M,)""" (aM{M-,))

nin2 . " . n M _ , n M ( a 2 , ) ( a 3 2 ) ( a 3 , ) "

=

1

1+

1

1+

[(M-!)

nMl H -

OlM/)

riM-!

1=!

1+

((~_~2)

i--! )

(1-I

1)])

OI(M-

-

(a) 1+...

(aM,)'''(aM{M-,))

i=l

(b) 1+...

l + a2-1a 2

"'"

(7)

ni.j= 1

Since n~ has been factored out in (7), its value would not affect the value of cost*(t). Choosing the predicate with the smallest search space as the first conjunct to evaluate may result in small values of %~ for some j and increase the value of cost*(t) (and therefore cost(t)). In other words, choosing a conjunct with the smallest search space which cannot contribute too much to other conjuncts may result in significant evaluation cost. To cure the problem of committing the choice of f~ too early, the following most-expensive-last approach

292

P. Sheu. R . L . Kashyap and S. Y o o

can be used. This approach avoids choosing ft until it is necessary. More precisely, it chooses the conjunct, say f,, which gives the largest value of n;(llj,; ao) as the last conjunct to evaluate (such that term (a) in the resulting sequence is maximized), then it chooses the conjunct which gives the largest value of n;(llj,;.;, a#) as the second last conjunct to evaluate (such that term (b) in the resulting sequence is maximized), and so on, until there is no more conjunct remains to be ordered. Formally, this approach can be described as follows: Algorithm 1. The most-expensive-last algorithm Step 1 (Initialization) candidate = ( ) , conjunct_left = conjunct_set = { fl . . . . . Step 2 compute ~;j, 1 <~ i,j <~ M; Step 3 For Pi in conjunct_/eft do cost*( f i ) = n i I-I

fM };

aij;

( j # i.fjEconjunct-left )

Let cost(L ) = max cost*(fi), delete f, from conjunct_left; i If conjunct_left = 0 then terminate, else goto Step 4; Step 4 candidate = s I candidate (where the symbol I denotes concatenation), goto Step 3. Clearly, the complexity of this algorithm is O(M2), where M is the number of conjuncts in a query. It may be difficult to prove which of the above two approaches performs better, and this is not the point we want to make here. As a matter of fact, we think these two approaches complement each other; hence we suggest that both of them be tried and the one with better performance is taken for a case given. Our point can best be illustrated by the following example. Example 3. Given three conjuncts Pl, P2 and P3, let t,. = ( p l , P2, P3) be the sequence obtained by the cheapest-first heuristic, and let t m = (p3, P2, P~) be the sequence obtained by the most-expensive-last heuristic. For simplicity, we assume that no conjunct may become ground even if all other conjuncts are solved. Also assume that all the predicates involved are relational and the cost of generating a solution for each relation is 1. According to the cheapest-first heuristic, the following facts can be inferred from t,.: (1) n I < n 2, n I < n 3 , a n d (2) a v g ( p 2 ; { p t } ) < a v g ( p 3 ; { p , } ). Based on the most-expensive-last heuristic, the following facts can be inferred from tin: (1) a v g ( p t ; { p 2 , P 3 } ) > a v g ( p 2 ; { p ~ , p 3 } ) . (2) a v g ( p , ; { p 2 , P 3 } ) > a v g ( p 3 ; { p ~ , p 2 } ) . (3) a v g ( p 2 ; { P 3 } ) > avg(p3;{P2} ). The costs for them would be: COSt(to) = n I + n 2 a v g ( P 2 ; { p l } ) + n I a v g ( P 2 ; { p l } ) a v g ( P 3 ; { P l , P 2 ) ) cost(t,,,) = n 3 + n 3 avg( P2; { P3} ) + n3 avg( P2; { P3} ) avg( Pl ;{ P2, P3} ).

The exact delineation of the conditions for precisely specifying the inequality COSt(tin)<

Query optimization in object-oriented knowledge bases

293

cost(to) is hard. However, we can state the following sufficient conditions (see Appendix A): (a) cost(t m ) < cost(tc ) if avg( p2;{ P,} ) > [n3 - nl + n3avg( P2;{ P3} )(1 + avg( p~ ;{ P2,P3} )]/[nl( 1 + avg( P3;{ Pl ,P2})] ( b ) cost(t m ) > cost( t ~) if avg( P3; { P, } ) <~avg( P3; { P2} ). 5. Logical query evaluation with a relational database

When realizing an object-oriented knowledge base with a relational database such as Ingres, relational predicates can be converted into Quel programs and evaluated by Ingres; some basic methods associated to classes integer, real, and string can also be processed by Ingres. Typical examples of these methods are comparisons (e.g. >, <, or ~ ) between integer numbers, between real numbers, and between strings. These methods can be converted into selection conditions in Quel programs. Other methods which are not supported by lngres are processed by the knowledge base and only these methods are referred to as methods in the remaining of this paper when there is no special note. Given a logical query, a rule/goal graph can be built first. In the rule/goal graph, those relational predicates which are defined by deductive laws are expanded. When a relational predicate is expanded with a deductive law, the body of the deductive law forms a logical query again. In case that more than one deductive law is matched by a relational predicate, disjunctive queries are generated. This procedure is repeated until no relational predicate can be expanded. The rule/goal graph is evaluated in a bottom-up fashion. Once a rule/goal graph is obtained, conjuncts in conjunctive formulas (which may contain methods) are ordered based on our discussion in Section 4. Then variables in the rule/goal graph are classified (according to the relationship among them) in order to evaluate the rule/goal graph in an optimal way. This sequence can be summarized as follows: (1) Build a rule/goal graph for a given conjunctive formula. (2) Order the conjuncts. (3) Classify the variables in the rule/goal graph. (4) Evaluate the Rule/Goal Graph. Each step in the above sequence is discussed in the following subsections.

5.1 Building a rule~goal graph Among several existing graph formalisms for describing a set of rules, e.g. predicate connection graphs [17] and rule/goal trees [27], we have chosen rule/goal trees with a variation. The variation we made is that any goal node which is unifiable with another goal node in the graph is not added into the graph; instead it will be merged into the existing node. This variation is made for two purposes: First, we can detect any recursion in the set of rules by finding cycles in the graph. Second, it reduces the cost of query processing because the relation corresponding to the merging node is derived only once and saved for future uses. In the remaining part of this paper, this variation of a rule/goal tree will be called as a rule/goal graph. In a rule/goal graph, merging nodes are defined as nodes which include more than one goal node. In an object-oriented knowledge base, predicates with the same symbol have some relationship among them. For example, when two predicates are unifiable, their interpretations may have common tuples. In this case, the two predicates are said to be compatible. The relationship among the predicates in a merging node can be represented by

P. Sheu, R.L. Kashyapand S. Yoo

294

a compatibility tree. Specifically, a compatibility tree can be built for a set of predicates which have the same head and different sets of arguments. In a compatibility tree, the most general predicate (in which every argument is a variable) is placed at the root, and each node in the tree can be unified by its descendant nodes. Example 4. Suppose we have three predicates in a rule/goal graph: tiny_iayout(ld, Function, Polybox), tiny_layout(Id, function1, Polybox), and tiny_layout(Id, Function, polyboxl ). In the above predicates the arguments that start with a capital letter are variables as in Prolog. In this case, a merging node can be built based on the three predicates because

tiny_layout( Id, function1, Polybox) and tiny_layout( Id, Function, polybox l ) can be unified with tiny_layout(Id, Function, Polybox). The merging node is shown in Fig. 1, where tiny_layout(Id, Function, Polybox) is the most general predicate. Example 5 According to the database defined in Example 1 and the rules described in example 2, a query could be as follows: {A I layout(A, Fnt, Pb) ^ butting_contact(B) ^ diffusion_box(C, Box, Col) ^ Pb:intersect (B, D ) ^ Pb :intersect(Box, E) }. The above query asks for the layouts which intersect with a butting_contact and a diffusion_box. The rule/goal graph corresponding to the above query is shown in Fig. 2.

5.2 Ordering conjuncts In an object-oriented knowledge base, the ordering mechanism described in section 4 can be further extended by including inferences and procedural methods among conjuncts. In general, methods in a sequence of conjuncts divide the conjuncts into several sequences of relational predicates; after each sequence is reordered, these sequences (together with the methods) can be evaluated using a sequential generate-and-test procedure. In a rule/goal graph, levels can be defined according to the relative positions of the predicates. Those relational predicates which are included in the logical query are defined to

I I I I

I I I I

~tiny-.layout (Id,funetion1 ,Polybox) ..

tiny_layout(Id,Funet|on.polyboxl) •

j

'!

Fig. 1. A compatibilitytree for a mergingnode.

layout(A,Fnt,Pb)

r

butting~ontaet(B)

1

~diffusion_box(C,Box,Col) , diffusion_box B,Boxl,Color) .._-_a diffusion_box B,Boxl,Col r):-

buttiny=_contact~B):.

.

.

.

.

.

.

.

.

.

.

.

.

.

Boxl:i~el~sect(B~x2,B) ~ ~ ~.l basic-block(DB,Boxl,Color) i~ B:width(W) (W~
Pb:intersect(Box,E) Fig. 2. A rule/goal graph.

Query optinu,:ation in object-oriented knowledge bases

295

be at the top level (i.e. level l), and the predicates which are expanded from the predicates at the top level constitute the lower levels (levels 2, 3, 4 . . . . ). Each conjunctive formula in a rule/goal graph is ordered separately; different formulas are ordered in a bottom-up fashion (i.e. from the lowest level to the top level) and different formulas at the same level can be ordered in an arbitrary order. In ordering a conjunctive formula, we determine the order of methods first. The relationship between inputs and outputs of methods gives constraints to the permissible orders of methods. Once the order of methods is fixed, an optimal order for the conjunctive formula can be found by applying one of the heuristics discussed in Section 4. Example 6. Consider the conjuncts in a view definition for butting_contact in Fig. 2:

{diffusion_box(DB, Boxl, Coll) ^ box(Bid, Box3, Col2) ^ Boxl :intersect(Box2, B) A B: width(W) A B: length(L ) ^ ( W <~1 ) ^ (L <~1 ) } The first step is to determine the order of the methods, Boxl:intersect(Box2, B), B:width(W), and B:length(L). Because any input variable must be instantiated before a method

can

be

evaluated,

two

possible

{ Boxl :intersect(Box2, B) B: width(W) B :length(L ) B: width(W) }.

orders

of

B:length(L) } and

these three methods are { Box! :intersect(Box2, B)

The next step is to determine the order of the remaining predicates. Because the method intersect has two input variables, i.e. Box1 and Bex2, the predicates diffusion_box(DB, Box1, Coil ) and box(B, Box2, Co12) must be placed before the method intersect. On the other hand the predicates (W<~I) and (L<~I) must come after B:width(W) and B:length(L), respectively. Otherwise, the number of solutions for the predicates (W ~< 1 ) or (L <~ 1) becomes infinite. Considering these, the optimal ordering is then {diffusion_

box(DB, Box1, Coll ) A box(Bid, Box2, Col2) A Boxl :intersect(Box2, B) A B:width(W) A (W <<-1 ) A B:length(L ) A (L <~1 )}. 5.3 Classifying variables in the rule~goal graph As we mentioned earlier, methods in a conjunctive formula divide the conjuncts into several groups of predicates, and a sequential generate-and-test procedure can be applied to evaluate a query at group level. In performing the generate-and-test procedure, some variables are active variables (i.e. answers to those variables can be reused later) and some others are not used anymore. The purpose of classifying variables is to minimize the work space for query evaluation by removing unnecessary attributes from temporary relations. Consider a logical quely of the form:

{A, .." A k ] ( 3 B , ) ' " ( 3 B m ) ( t , A ' ' " ^ t.)} where Ai's are result variables and each tj is either a sequence of relational predicates or a method. In the above formula, each B k can belong to one of three classes, i.e. it can be an active variable, an inactive variable, or a dummy variable; we mark them as B k, B k, and B d, respectively. For each tj (which is a sequence of relational predicates or a method), any variable which exists in tj+~,.--, t, is an active variable. In evaluating tj, the result of the active variables should be saved. Different from active variables, inactive variables are used only in evaluating tj but are not needed anymore. For this reason, inactive variables need not be retrieved from Ingres in the generate-and-test procedure. Finally, an inactive variable which only appears once in tj is called a dummy variable. Variables appear at the top level of a rule/goal graph are classified first, then the result is passed down to the lower levels in the graph; variables at level j + 1 which correspond to result, active, and inactive variables at level j are classified as result variables. With this

P. Sheu, R.L. Kashyap and S. Yoo

296

inheritance mechanism, each conjunctive formula in the rule/goal graph becomes a logical query whose variables are classified. In evaluating a conjunctive formula at level i, where i > 1, only the attributes corresponding to result variables are saved in temporary relations so that they can be used at the next higher level (i.e. level i - 1). Formally, the complete procedure for classifying variables in a rule/goal graph is given in Algorithm 2: Algorithm 2. Classifying variables in a rule~goal graph Input: An ordered rule/goal graph with result variables at the top level are marked. Output: A rule/goal graph with classified variables. Method: 1. For each tj at the top level o f the rule/goal graph, do the following steps. (a) For each t/, make a list lj, which contains the names of variables in tj (except the result variables) and the number of occurrences of each variable. For methods, list all input and output variables. (b) For each variable in lj, scan lj+~,..., l,. If a variable does not appear in lj+~,.--, l, and it appears only once in l/, it is a dummy variable. If a variable does not appear in lj+ ~,--., Ir and it appears more than once in lj, it is an inactive variable. The remaining variables in l/are active variables. 2. For the remaining levels, variables are classified in a top-down order. For each goal node at level i, do the following steps. Initially, i is set to 1 (which is the top level). (a) If the goal node is included in a recursion, skip the node and try the next goal node. (b) The result variables, active variables, and inactive variables of the goal node are marked as result variables in the corresponding rule nodes at level i + 1. (c) Each rule node at level i + 1 is connected to a set of goal nodes at level i + 2. In the set of goal nodes, those variables which correspond to some result variables in the rule node are marked as result variables. (d) Now, each set of goal nodes at level i + 2 forms a conjunctive formula. For each conjunctive formula, repeat (a) and (b) in Step 1. (e) If i + 1 is the bottom level, stop. Otherwise set i to i + 2 and go to (a).

Example 7. In this example, consider the same query as in example 5. { A [layout(A, Fnt, Pb) ^ butting_contact(B) ^ diffusion_box (C, Box, Col) ^ Pb :intersect( B , D) ^ Pb :intersect( Box, E)} The rule/goal graph for this query is shown in Fig. 2. Following the steps in Algorithm 2, variables in the rule/goal graph can be classified. The result of the classification is shown in Fig. 3. I

layout(A r,Fntd,pb a) butting_eontact(B a )

~diffusion_box(Cd,Boxa,Col d) ~,, diffusion_box Bd,Bozl",Colo,d).__a ,

buttinng~:contac~Br),---

B°xli:i~ersect(~°x2a,i~)

~

~.-

basic_block('DBd,Boxl-r,Col'or'a')" i~

, r z I d a d B r :width(W a )(W~
( Colori=green) Pb ~:intersect(B i,D d) Pb ~:intersect(Boxi,Ed) Fig. 3. A rule/goal graph with classified variables.

Query optimization in object-oriented knowledge bases

297

5.4 Evaluation of the rule~goal graph In a rule/goal graph, a goal node may be unified with several rules. Each rule node can be expanded into a set of goal nodes using the body of the corresponding deductive law. The set of goal nodes expanded from a rule node forms a conjunctive formula. Evaluation of a rule-goal graph consists of separate evaluations of the set of the conjuctive formulas and finally taking the union of the results. If a conjunctive formula includes any method, it is evaluated interactively between the knowledge base and Ingres by a generate-and-test procedure. Otherwise, it is evaluated in Ingres. Given a conjunctive formula {t i ^ ' ' "

^

tr}

where tj is either a sequence of relational predicates or a method. For a tj which is a sequence of predicates, it is evaluated by Ingres with Quei programs. On the other hand, if tj is a method, it is evaluated in the knowledge base using the results obtained the Ingres. The query is evaluated by a generate-and-test procedure executing from t~ to t r. A predicate in tj which is a squence of relational predicates can be recursive or non-recursive. For each sequence of non-recursive predicates in ti, a Quel program can be generated and evaluated by Ingres. For each recursive predicate in tj, a set of relational queries can be generated; in this case, termination conditions are used to stop the evaluation. Once tj has been evaluated and useful results have been saved in temporary relations, the final results for ti are retrieved into the knowledge base from Ingres so that they can be used by the method following the sequence. If j = r, and results are the answers to the conjunctive formula. In the following, we shall discuss the approaches to evaluation non-recursive predicates, recursive predicates, and methods.

Evaluation of non-recursive predicates A rule/goal graph corresponding to a sequence of non-recursive predicates can be evaluated in several ways. First, we can translate a rule/goal graph into a disjunctive normal form. As an example, suppose we have the following rules: (1) A ( X , Y ) , - ~ B ( X , Z ) ^ Z:a_method(Y) ^ ( r > 100) (2) A(X,Y)~--~ B ( X , Z ) A D(Z,k) (3) B ( X , Z ) , ~ F(X,W) ^ G(W,Z) (4) B(x,z) H(X,W) A /(W,Z) The distinctive normal form corresponding to the query A(X, Y) can be as follows: (i) {F(X,W) A G(W,Z) ^ Z:a_method(Y) A ( r > 100)} v (ii) {H(X,W) A I(W,Z) ^ Z:a_method(Y) ^ ( r > 100)} v (iii) { F(X,W) A G(W,Z) A D(Z,k)} v (iv) {H(X,W) A I(W,Z) A D(Z,k)}. In this example, the expansion of B ( X , Z ) is duplicated in (i), (ii), (iii), and (iv). These cause some redundancies when the above disjuncts are evaluated separately. One way to remove these redundancies is to evaluate the rule/goal graph in a bottom-up fashion. When a rule/goal is evaluated in a bottom-up fashion, the predicates at the top level are evaluated from left to right. For each predicate at the top level, the rule/goal graph originated from that node is enumerated in post order (i.e. a node is visited after all its children are visited). A temporary relation is generated for each rule node and it is deleted when it is not needed anymore. When a goal node is a merging node, a relation corresponding to the most general predicate in the node is generated and is saved until all the predicates in the node are evaluated. Formally, given a rule/goal graph, the following algorithm translates the rule/goal graph into a Quel program.

P. Sheu. R.L. gashyap and S. Yoo

298

Algorithm 3. Translating a sequence of non-recursive predicates into a Quel program Input: A classified rule/goal graph for a sequence of non-recursive predicates. Output: A Quel program.

method: 1. For each predicate at the top level, the rule/goal graph originated from it is enumerated in the post-order. (1) For each rule node enumerated, do the following: (a) Generate a temporary variable for each child goal connected to the rule node using "range" command. When a goal node is a merging node, retrieve and save the relation which corresponds to the most general predicate in the node. Once a predicate in a merging node is evaluated, delete it from the node. In this way, when the node becomes empty, the temporary relation can be deleted. (b) Generate a "retrieve" command for the rule node. At this time, save only the answers to the result variables into a temporary relation. (c) Generate a "where" clause using the common variables among the children goals and comparison predicates. A mathematical predicate can be a condition directly. Enumerate the result variables and the active variables throughout the children goal nodes. If two predicates share a common variable, generate an equality relation. (2) For each goal node which is not a leaf node, do the following: (a) Generate a temporary variable for each rule connected to the node (as a child) using a "range" command. (b) Generate an "append to" command for the goal node. At this time, save the answers to the result, active, and inactive variables into a temporary relation. 2. Generate a Quel program for the goal nodes at the top level with the similar procedure as in Step 1. One difference in this case is that there is no rule node. Instead, the variables are all classified. Among the variables we only need to save the result variables and the active variables. Using these variables, a "retrie,~e" command can be generated as in Step 1.1.b.

Example 8. A Quel program can be generated for a part of a rule/goal graph which is connected without any methods. In evaluating butting_contact(B) in Fig. 2, for example, the following Quel program can be generated to retrieve the relevant data: range of tl is basic_block retrieve into tempi(Box1 = tl. Box) where (tl. Col = green) range of t2 is templ retrieve into temp2(Boxl = t2. Box1, Box2 = tl. Box)

Evaluation of methods Methods are evaluated in the knowledge base. Given input variables, methods generate outputs. In general, the inputs of a method are obtained from relation tables. Consequently, the results from previous conjuncts can be used.

Example 9. In this example, we consider evaluating the predicate butting_contact(B) as a continuation of Example 7. Once the join of diffusion_box and basic_block is retrieved from the database, the methods intersect, width, and length can be evaluated for each row. For each output of the methods width and length, the conditions (W ~< 1) and (L <~ 1) can be checked. Note that the conditions (W <~ 1) and (L ~< 1) can be evaluated in the objectoriented knowledge base as methods or in lngres as inequalities.

Query optimization in object-oriented knowledge bases

299

Evaluation of recursive conjuncts When a predicate in a sequence of relational conjuncts is recursive, it cannot be evaluated using Algorithm 3 because it includes cycles in the corresponding rule/goal graph. In a small database in which ground clauses can be retrieved into the main memory, recursive rules can be evaluated efficiently using the Prolog evaluator. However, for nontriviai applications such as CAD, CAM, and expert systems, ever~ one relation may not fit into the main memory. In these cases the tuple-at-a-time strategy followed by Prolog may cause too many page faults and makes it impractical. To solve this problem, several approaches have been proposed [1, 10, 27, 28]. In an object-oriented knowledge base, for a sequence of relational predicates (in a query) in which some predicates are recursive, a series of conjunctive formulas can be generated using deductive laws. In the series, each conjunctive formula consists of only base predictates and it can be evaluated using relational operations. The union of the results for each conjunctive formula can then be taken to obtain the final answer. In the series of conjunctive formulas generated, the conjuncts in each formula are included in subsequent formulas. Tile result of a conjunctive formula can be saved as a temporary relation, and it can be used when next conjunctive formula is evaluated. The series of conjunctive formulas can be evaluated at run time and are checked for termination conditions at each step. There are two termination conditions: First, if the answers of a conjunct in a conjunctive formula is evaluated to be an empty set, then the answer of the formula is the empty set. Second, if the answers of a conjunctive formula is evaluated to be the same as those of the previous formula, then no new tuple will be produced by evaluating subsequent formulas. We can stop the evaluation at this point.

Example 10. One example of recursive predicates is as follows: (Rule 5) connected(G, X, Y),-4graph(G, E) n edge(E, X, Y) (Rule 6) connected(G, X, y)~--4graph(G, E) n edge(E, X, Z) n connected(G, Z, Y) With these, a query can be as follows: { Vertices I connected( gl, input_nodel, Vertices) } which asks for a set of vertices connected to "input_nodel" in graph "g1". To evaluate this query, a series of conjunctive formulas can be generated as follows:

graph( gl,E1 ) ^ graph( g 1, E 1 ) ^ graph( g l,E I ) ^ graph(gl,E3) ^

edge(El,input_nodel, D ) edge( E 1, input_nodel ,D ) ^ graph( g 1, E2 ) ^ edge(E2, C, D 1 ) edge(E1 ,input_nodel, D ) ^ graph( g l ,E2 ) ^ edge( E2, C, D1 ) ^ edge(E3,C1,D2 )

In the above Example, we can evaluate any common part only once and reuse the results later. 6. Previous work

Recently there have been various approaches proposed to implementing object-oriented data models. One of the approaches is to expand an object-oriented language into a database system. GemStone [5, 6] adds to Smalltalk-80 permanent data storeage, multiple concurrent users transactions, and secondary indices. LOOM [12] was designed to assist main memory resident SmaUtalk-80 in managing large objects by providing object-swapping virtual me-

300

P. Sheu, R.L. Kashyap and S. Yoo

mory. The most significant difference between these systems and the framework of objectoriented knowledge base is that an object-oriented knowledge base has a logical query language. With the logical query language, in an object-oriented knowledge base a user can retrieve objects associatively, which has not been supported by most object-oriented query languages. Along another direction, relational databases have been extended in several systems. An optimizing translation mechanism to integrate a logic-based expert system written in Prolog and a database accessible through SQL was designed in [11]. In [11], translation of Prolog data requests into queries in SQL and syntatic and semantic optimization were discussed. However, the logical query language of an object-oriented knowledge base has been expanded with procedural methods. Each method is associated to an object class and provides the objects with customized operations. Several semantic database languages have been defined to be a front-end of relational databases. Some examples of these languages were proposed in GEM [25], Iris [7], and Ariel [15]. Although implementation details of these systems are different, the basic philosophies are similar. They extended the relational model to support some semantic data models and provided various database managcmcnt functions such as concurrency control and storage systems. One aspect in which an object-oriented knowledge base is different from these systems is that a semantic model is defined using the first order language in the framework of object-oriented knowledge base. With this formal definition, the semantic model can be provided with a logical query language which has reasoning power. The formal definition also provides a uniform representation for intentional and extentional facts for query processing and management functions. POSTGRES [19, 23] has been designed to simulate semantic data models by including mechanisms such as abstract data types, procedures, and rules. It can also support the major concepts provided in an object-oriented data model, which include structured attribute types, inheritance, union type attributes, and shared subobjects. Even though a language for stating rules has been described in POSTGRES, the power of this language has not been analyzed comparing to that of the first order language. Based on the formal definition of object schema, the logical query language of an objecv,~dented knowledge base has the expressive power of the first order language. The formal definition also enables an object-oriented knowledge base to enforce integrity constraints whose scope is much wider.

7. Conclusion

In this paper, we have described two complementary approaches to optimize the cost of query processing in object-oriented knowledge bases. The first approach employs rewriting rules to transform a query to a semantically related query with smaller search space, and the second approach reorders the conjuncts in a query according to the cost function. In the second approach, we have described the most-expensive-last heuristic. Following this heuristic, we determine the optimal evaluation sequence according to the benefit each conjunct can recieve from solving the other conjuncts first. We have also described an approach to evaluate logical queries in an object-oriented knowledge base assuming it is built on top of Ingres. In this case, given a logical query, a rule/goal graph can be constructed first. Once a rule/goal graph is built, its conjuncts are reordered and variables are classified. Finally, evaluation is done according to three different types of predicates: non-recursive conjuncts, methods, and recursive conjuncts. In our approach, common parts among different pieces of a query can be reused as much as possible.

Query optimization in object-oriented knowledge bases

301

An extension of this work reported here would be to consider the problem of logical query processing in a distributed environment in which significant communication cost may be involved in evaluating conjunctive problems whose underlying databases are distributed.

Appendix A

cost(to) = n, + n,avg( P2;{ P,}) + n,avg( p2; { P,})avg( P3;{ P,,P2} ) cost(t.,)= n 3 + n3avg(p2;{p3})+ n3avg(p2;{p3})avg(pt;{p2,P3}) (a) cost(tin) - cost(tc) = (n 3 - nl) + n3avg(p2;{p3})(1 + avg(pi;{p2,p3 })) n~avg( p2;{ pl } )(1 + avg( p3;{ pl,p2} ) • cost(t m) < cost(t~) if nlavg( p2;{ pl} )(1 + avg(p3;{ pi,p2} )) > (n 3 - nl) + n3avg(p2;{p3})(1 + avg(p~;{p2,p3}) (b) If avg(p:,~;{ p~} ) <~avg(p3;{ P2}) then by the fact that (1) avg(p2;{pl}) < avg(p3;{pi}). (2) avg(p2;{p3})> avg(p3;{p2} ), (3) n 3 > n~, and (4) avg(pl;{p2,p3}) > avg(p3;{ Pl ,P2}), we can obtain (i) avg(p2;{p3})> avg(p2;{p~}). n3(P2;{P3}) > n~(p2;{Pl}), (ii) avg( p2; { p3} ) > avg( p2; { p~ } ), n3avg( P2;{ P3} )avg( p~ ;{ P2, P3 }) > n~avg( P2; { P~ })avg( P3; { P~ ,P2} )References Bancihon, and R. Ramakrishnan, An amateur's introduction to recursive query processing strategies, Proc. SIGMOD (1986). 121 A. Bundy, The Computer Modeling of Mathematical Reasoning (Academic Press, NY, 1984). 131 C.L. Chang, On evaluation of queries containing derived relations in relational database, in Advances in Database Theory, Vol. I. (Gallaire, et al., Eds) (Plenum Press, 1981). 141 U.S. Chakravarthy, D.H. Fishman and J. Minker, Semantic query optimization in Expert systems and database systems, 1st Workshop on Expert Database Systems (N.C. 1984). 151 G. Copeland and D. Maier, Making Smalltalk a database system, Proc. SIGMOD (1984). 161 M. Feather, A survey and classification of some program transformation approaches and techniques, IFIP Working Conf. on Program Specification and Transformation (Germany, 1986). D. I71 Fish et al., Iris: An object-oriented database management system, ACM Transactions on Office Information Systems, Vol. 5, No. 1 (1987). 181 H. Gallaire, J. Minker and J-M. Nicolas, Logic and databases, a deductive approach, Computing Surveys, Vol. 16, No. 2 (1984). I91 J. Grant and J. Minker, Optimization in deductive and conventional relational systems, in Advances in Database Theory (Gallaire, Minker and Nicolas, Eds), Voi. ! (Plenum Press, 1981). 11Ol L. Henschen and S. Naqvi, On compiling queries in recursive first-order data bases, J. ACM, Vol. 31 (1984). !111 M. Jarke, J. Clifford and Y. Vassiliou, An optimizing prolog front-end to a relational query system, Proc. SIGMOD (1984). 112] T. Kaehler and G. Krasaer, L O O M - Large Object Oriented Memory for Smalltalk-80 systems, Smalltalk-80, Bits of History, Words of Advice, G. Krasner, Ed. (Addison Wesley, 1983). 1131 C. Kellogg, From data management to knowledge management, Computer (January, 1986). [14] J. King, Query Optimization by semantic reasoning, Ph.D. Thesis, Dept. of CS, Stanford University (1981). [151 R. MacGregor, Ariel- A semantic front-end to relational DBMSs, Proc. VLDB (1985). I161 D. Maier and J. Stein, Development of an object-oriented DBMS, OOPSLA '86 Proceedings (1986). I171 D. Mckay and S. Shapiro, Using active connection graphs for reasoning with recursive rules, Proc. 7th Int. Joint Conference on Artificial lntelligience (1981). 1181 H. Partsch and R. Steinbruggen, Program transformation systems, ACM Computing Surveys, Vol. 15, No. 3 (1983).

111 F.

302 [19] [20] [21] [22] [23]

P. Sheu, R.L. Kashyap and S. Yoo

L. Rowe and M. Stonebraker, The POSTGRES data model, Proc. VLDB (1987). EC-Y. Sheu, Describing semantic databases in logic, (to appear) J. Systems and Software (1988). J. Shoenfield, Mathematical Logic (Addison-Wesley, 1967). D.E. Smith and M.R. Genesereth, Ordering conjunctive queries, Artificial Intelligence (1985). M. Stonebraker, E. Hanson and C. Hong, The design of the POSTGRES rules system, Proc. Data Engineering (1987). [24] M. Stonebraker, E. Wong, P. Kreps and G. Held, The design and implementation of INGRES, ACM Trans. Database Systems, Vol. 1, No. 3 (1976). [25] S. Tsur and C. Zaniolo, An implementation of G E M - supporting a semantic data model on a relational back-end, Proc. SIGMOD (1984). [26] J.D. Ullman, Principles of Database Systems (Computer Science Press, 1982). [27] J.D. Uliman, Implementation of logical query languages for databases, ACM Trans. Database Systems, Vol. 10, No. 3 (1985). [28] L. Vieiile, Recursive axioms in deductive databases: the query/subquery approach, Proc. First Int. Conf. Expert Database Systems (Charleston, 1986).