LOGIDATA+: Deductive Databases with Complex Objects (Lecture Notes in Computer Science)

q. Let n q is similar. 5. x = EmptySet and y = {t},~,m with n > l . 27(EmptySet) = {13} ~ {v, 9 1;s I v, C 27(t)and n
27ix) r Z(y) ill OII = 0). 6. If x, y are two classes, we have the following cases: (a) y E C p and there is not an explicit ISA such that xlSA y. Given the semantics of a primitive class, it is alway possible to build 27,1; and o 9 O C V such that o 9 27(x) but o r 2"(y). (b) y E CD and 3Cp 9 C p such that: Cp 9 4~(y) but Cp r O(x). Let 2732 and o 9 O C_ 1; such that o 9 Z ( x ) but o r then, given

104

that I (y) C_I (Cp), o • 2: (y). (c)

REF(TYP(x),TYP(y))--FALSE. Given that x is a coherent class, it must be TYP(x) ~ TYP(Cp) VC~ e r Now by induction, there are it*, Y*, v* such that v* 9 2:* (TYP(z)) but v* r 2:~ (TYP(y)). Let oo be an object identifier such that 6(o0) - v*; I) = F* U {o0}; let 2: be an interpretation function over Y such that: a) for every type s, Z (s) C Z* (s) U {oo}, b) VCp 9 ~(x)o0 9 Z (Cp). Then, from a), v* E Z (TYP(x)) while the assumption b) is valid given that, ~f(o0) = v* 9 2: (TYP(z)) C 2: (TYP(Cp)) VCp 9 ~(x). On the other hand, v* ~ 2: (TYP(y)), therefore, due to the definition of class interpretation, o0 e I ( x ) but o0 r Z(y).

T a x o n o m i c R e a s o n i n g w i t h Cycles in LOGIDATA + Domenico Beneventano and Sonia Bergamaschi and Claudio Sartori CIOC

-

CNR, Dipartimento di Elettronica, Informatica e Sistemistica Viale Risorgimento 2, 40136 Bologna, Italy e_malh {domenico,sonia,claudio }@deis64.cineca.it

A b s t r a c t . This paper shows the subsumption computation techniques for a LOGIDATA+ schema allowing cyclic definitions for classes. The formal framework LOGIDATA~vc , which extends LOGIDATA* to perform taxonomic reasoning in the presence of cyclic class definitions is introduced. It includes the notions of possible instances of a schema; legal instance of a schema , defined as the greatest fixed-point of possible instances; subsumption relation. On the basis of this framework, the definitions of coherent type and consistent class are introduced and the necessary algorithms to detect incoherence and compute subsumption in a LOGIDATA+ schema are given. Some examples of subsumption computation show its feasibility for schema design and validation.

1

Introduction

This paper shows the subsumption computation techniques for a LOGIDATA + schema allowing cyclic definitions for classes. The reader is referred to Taxonomic Reasoning in LOGIDATA +, by A. Artale, F. Cesarini, G. Soda, D. Beneventano, S. Bergama.schi, C. Sartori, in this volume for tile motivation of taxonomic reasoning in this enviromnent. When class definitions are allowed to contain cycles, the models of the schema must be found by means of some fixed-point operation, hence it becomes necessary to precisely define the starting points and the fixed-point which are to be allowed. In section 2 the formal, the framework LOGIDATA* model, is given. In section 3 a running example and an intuitive introduction to the paper topic are given. In section 4 a formal definition of a L O G I D A T A ~ yc schema is given, the notion of possible instance is introduced and its problems are discussed. In section 5 the legal instance of a schema is formally defined as the greatest fixed-point of possible instance and a computation algorithm is provided; this is done by introducing a modified schema where the primitive classes are transformed in order to find a valid starting point and compute the fixed-point. The main results on the fixed-points are also recalled. In section 6 the subsumption relation is formally defined. In section 7 the definitions of coherent type and consistent class are introduced, as a support for * This work was partially supported by the Italian project Sistemi informatici e Calcolo Parallelo, subproject 5, objective LOGIDATA+ of the National Research Council

(CNR).

106

schema validation. Then the validated schema is simplified in order to effectively compute the subsumption relation. Finaliy, in section 8 some examples of subsumption computation are given and its feasibility for schema design and validation and object recognition is shown.

2

T h e LOGIDATA* M o d e l

In order to fit taxonomic reasoning in LOGIDATA + some modifications are necessary. The LOGIDATA* model has been individuated as a formal framework which is common with the work done in Introducing taxonomic reasoning in LOGIDATA +, in this volume. In section 4 some additions will also been introduced in order to deal with cycles. The main structure of LOGIDATA* is the class that denotes sets of objects, each of which is identified by an object identifier (oid). Objects in classes can have complex structures obtained by repeatedly using the tuple and set constructors 2. Furthermore, type names are provided to simplify user declarations. Further, set types with cardinality constraints are introduced, integrating in the object description a kind of integrity constraint in the database environment and classes are distinguished as primitive and defined. 2.1

Database Schema

We consider, as base types B, the two countable, non-finite set of strings and integers, which are disjoint. Let C p be a countable set of primitive class names, CB a countable set of defined class names, C = C p U CD, T a countable set of type names, L a countable set of labels; sets B, Cp, CD and T are pairwise disjoint, C o including the universal class, which will be denoted by the symbol T. We indicate by 7-(L, B, C, T ) (often abbreviated simply as 7") the whole set of type descriptors, over L, B, C, T defined as follows: - each base type name B E B is a type; each class name C E C is a type; - each type name T E T is a type; - if t is a type, then {t}(min,max) is also a type called set type, where min is a not-negative integer, max is a positive integer or c~, and max > min; e m p t y s e t is the empty set type; - i f Q , . . . , t k , with k > 0, are types and l l , . . . , l k are distinct labels, then [11 : t l , . . . , lk : tk] is also a type, called tuple type. -

-

Let ISA be a partial order over C: C ISA C' states that each object belonging to class C also belongs to class C', i.e., class C is a subclass (or a specialization) of C'. Let TYP be a function from T U C to the set of type descriptors in 7"(L, B, C, T). TYP is such that: - for each T E T, TYP(T) is a tuple or set type descriptor of 7"; 2 The sequence type (0) can be easily added.

107

- for each C E C, TYP(C) is a tuple type descriptor of 7-; T Y P ( T ) is the empty tuple ~, i.e. the tuple type with no labels. D e f i n i t i o n 1 ( L O G I D A T A * S c h e m a ) . A LOGIDATA* schema is a five-tuple S - ( C p , C D , T , TYP, ISA) where T, Cp, CD, ISA and TYP are defined as above. 2.2

Database

Values

L e t / ) i be the set of values associated with the base type name Bi E B. L e t / ) be T) = O~=liDi. Each element v E / ) is a basic value. We assume that sets T)i are

pairwise disjoint. Let O be a countable set of symbols called object identifiers (o is a generic object identifier), disjoint f r o m / ) . D e f i n i t i o n 2 ( V a l u e s ) . A set I / o f values is Y = / ) U O U/)T O 1/s where VT is the set of tuple values: VT = {vt ] vt is a mapping, vt : L --~ 12}. We denote with [ll : V l , . . . , l k : vk] the total mapping defined on { l l , . . . , l k } such that vt (li) = vi E "12,i = 1 , . . . , k . - Vs is the set of set-values: /;s = (v~ I vs C_ V}. A set-value is denoted by ( V l , . . . , v k } , with vi E V,i = 1 , . . . , k . -

We note that the object identifiers are values, too. Since objects are usually considered to be pairs of identifiers and values, we assume the existence of a function that assigns values to object identifiers. D e f i n i t i o n 3 ( V a l u e A s s i g n m e n t a n d D o m a i n ) . Value assignment is a total mapping, denoted by 6, that associates a tuple value with each object-identifier: 6:O , V T . T h e d o m a i n ~ is the couple Z = ( O , 6). 2.3

Interpretation and Database Instance

The LOGIDATA* syntax is associated with a semantic which regulates the relationship between the intensional and extensional levels of the model. D e f i n i t i o n 4 ( I n t e r p r e t a t i o n ) . Given a LOGIDATA* schema S, let 7-be the type descriptors in S. Given a domain L', the i n t e r p r e t a t i o n f u n c t i o n E of S over V is a function from 7- to 2 V such that:

z (c) c_ o

Z(T) c v - o The interpretation is extended to types in 7- as follows: I([ll:tl,...,lk:tk])

= {vt E VT]Vt is defined atleast on {11,...,1~} and vt

(li) E I ( t i ) , i = 1 , . . . , k } .

2: ( e m p t y s e t ) = {q}}.

z ({t}r

= {v, 9 Vs I n <11 v, c_ z (t) II_< m}.

108

This i n t e r p r e t a t i o n is obviously not satisfactory as an instance of a database, as we w a n t objects of a class to agree on the type description associated to the class. T h u s in the two papers we will introduce the notion of legal instance of a d a t a b a s e for acyclic and cyclic schema declarations.

3

Defined Classes, Cycles and Subsumption

T h e e x a m p l e shown in table 1 will be used t h r o u g h o u t the paper, in order to give an intuitive account of the formal f r a m e w o r k developed and the s u b s u m p t i o n computation.

t y p e StringSet t y p e Date p r i m - c l a s s Person p r i m - c l a s s Organization class Structure p r i m - c l a s s Division

= = = = = =

prim-class

=

Employee

class Clerk class Department

= =

class Secretary class Office

= =

class Typist

=

prim-class

Section

=

{string}(a,3) [ day: integer, month: integer, year: integer] [ name : string, birth-date: Date] [ name : string] isa Organization [ collaborates : {Structure}(0,a) isa Organization [ employs : {Employee}o,20), turnover: integer] isa Person [ salary : integer, work-in : Division, emp-code: integer] isa Employee [ work-in : Department ] isa Division [ head : Clerk, employs : { Clerk }(1,5) ] isa Employee [ level : integer] isa Division [ head : Typist, employs : {Typist}(1,5) ] isa Employee [ work-in : Office , level : integer, qualification : StringSet] isa Division , Structure [ name : string, head : Clerk ]

T a b l e 1. Example of LOGIDATA~y c schema declaration

T h e e x a m p l e syntax is quite intuitive: declarations prefixed with the keyword t y p e introduce type n a m e s in order to simplify declarations, as is usual in m a n y p r o g r a m m i n g languages. In our case, two type names, one type having sets of string as values and a tuple type are introduced. ~ denote tuples, {} sets, string and integer base type; i s a denotes explicit isa relationship. A class is described by a list of superclasses and a tuple of differentiae properties. Notice that, isa relationship is p a r t of a class description and superclasses can be ancestors (not necessarily parents) of the described classes. T h e m a i n extension, with respect

109

to well-known complex object data models, is the distinction between primitive classes declaration (Person, Organization, Division, Employee, Section) and defined classes (Structure, Employee, Clerk, Department, Secretary, Office, Typist). From an extensional point of view we can show the differences introduced by this distinction with an example. Consider the objects John, Mary and Store:

John is an Employee has 2 for level

Mary is a Person has 1600 for salary has 65782 for emp-code work in Store

Store is a Division

The object John can be automatically recognized as a Secretary, since Secretary is a defined class and its extension can be computed. On the contrary, the object Mary cannot be recognized as an Employee, even if it is qualified with all the properties of that class, since that class is primitive. For cycles we need further considerations: Typist is a cyclic defined class (Typist mentions Office in its declaration and vice versa). It is non-obvious to define the semantics of cyclic definitions. For example:

John is an Employee has 2 for level has some qualifications work in Research-office

Research-office is a Division has John as head has John as employee

John is recognized as a Typist if Research-office is a Office and viceversa. This case points out the need for a fixed-point semantics in order to formalize the meaning of cyclic definitions. Furthermore, notice that also Division and Employee give rise to circular descriptions but, as they are primitive, we do not need any fixed-point semantics. Let us comment subsumption at the intensional level. From the definition of Secretary, it is quite intuitive to conclude that all elements of Typist are also elements of Secretary, consequently Typist is subsumed by Secretary. The subsnmption computation will enrich the ISA hierarchies provided by the user with those computed by the taxonomic reasoning system. In Figure 1 we represent the schema description after subsumption computation (the only property labels which give raise to cyclic description has been drawn). The computed isa are denoted in the figure with a dashed line. The dashed line with a , denote the computed ISA which are related to cycles and then depend on the choice of the fixed-point semantics. This point is one of the main results of this contribution and is dealt with by the techniques developed in the AI knowledge representation area [Neb91]. 4

Database

Schema

and Instance

This section introduces the formal definition of a LOGIDATA~y c schema and extends LOGIDATA* to support cyclic definitions. Cycles are recognized by

110

person * )

organiz.n

works

division

employee

structure

ploys

works secretary

section *

clerk employs

\

I

/*

.~

\. works

typist

off:ice employs

Fig. 1. Schema with user-defined and computed hierarchies

means of the notion of dependence. D e f i n i t i o n 5 ( D e p e n d s o n ) . N depends on N', where N,N' G T U C if N' is contained in the expression defining N, TYP(N), or if N depends on N" and N" depends on N'. D e f i n i t i o n 6 ( L O G I D A T A ~ y c S c h e m a ) . Given a set of base types B and a finite set of attributes L, a LOGIDATA~y c schema is a five-tuple S = ( C p , CD, T, TYP, ISAo), where: -- C p , C D and T, are defined as in section 2; - TYP is a function on C U T such that: 9 for each T G T, TYP(T) is a set type or tuple type of 7"; the relation depends on, restricted to type names, is a partial, non-reflexive order, 9 for each C G C, TYP(C) is a tuple type of 7-3; the relation depends on, restricted to class names, can contain cycles (i.e. it is a reflexive partial order); we say that a class C is cyclic when C depends on C.

111

- ISAo is a partial, non-reflexive order over C and is completed with C ISAu T for any C E C. The ISAu relationship is the ISA provided by the user. In the following the transitive closure ISA~ of the user-supplied ISA, will also be considered. Each schema S = ( C p , CD, T, TYP, ISAu) is associated with a set of type descriptors T. The total order on type names prevents recursive type descriptions, which would generate infinite structures. As seen above, a class C is specified by means of the structure of its instances (TYP(C)) and the supersets of its instances (the ISA~.). Thus, the type specification must agree with the type specifications of superclasses. In section 7 this agreement will be formally specified by means of the notion of consistent

schema. Multiple inheritance is allowed: a class can inherit from two or more classes, but in case of ambiguity (i.e. when the same label comes from two or more parent classes) the attribute must be redefined. For this reason, the attribute n a m e in the class Section of table 1 has been redefined. The schema S = ( C p , C o , T, TYP, ISAu) corresponding to the example of section 1 is shown in table 2. 4.1

Instance of a LOGIDATA~y C Schema

An arbitrary instance of a schema S = (Cp, CD, T, TYP, ISAu) is the range (subset of I)(O)) of an arbitrary interpretation 5 for a given domain ~U. In the following, for simplicity, we will indicate with the same symbol, 5, an interpretation and the instance it produces. Of course, the only interpretations of interest are those giving an instance which is in accordance with the schema descriptions. In order to formally define these interpretations, let us consider, for a given interpretation 5, the set of object identifiers associated to a class name C which are compatible with both the type definitions and the user defined hierarchy ISAu: D e f i n i t i o n 7 ( P o s s i b l e I n s t a n c e ) . Given a domain S , an interpretation/7 is a possible instance of a schema S if and only if VCp E C p , VCD E C o and VT E T we have:

N

C ISAu C,

z(q )

C ISAu C, 5 (W) = 5 (TYP(T)),

(3)

a A class type is constrained to be a tuple, in accordance with the LOGIDATA + model; the subsumption algorithm can easily be extended to any class type, as shown in [BN91].

112

C=CpUCD= {Person, Organization, Division, Section } L3 {Structure, Employee, Clerk, Depart ment, Typist, Office, Secret ary } T = { StringSet, Date} Structure ISAv Organization, Division ISAu Organization, Clerk ISAu Employee, Employee ISAu Person, Department ISAu Division, Typist ISAu Employee, Office ISAu Division, Secretary ISAu Employee, Section ISAu Division. The T Y P function is the following: TYP(StringSet) TYP(Date) TYP(Person)

= {string}o,3 ) = [day : integer, month : integer, year : integer] = [name : string, birth-date : Date] -I

TYP(Organization) = [name: string I TYP(Structure) TYP(Division) TYP(Employee) TYP(Clerk) TYP(Department) TYP(Secretary) TYP(Office) TYP(Typist)

TYP(Section)

[name: string, collaborates : {Structure}(0,a)] = [name: string, employs : {Employee}(1,20), turnover : integer] = [name : string, birth-date : Date, salary : integer, Work-in : Division, emp-code : integer] = [name : string, birth-date : Date, salary : integer, work-in : Department, emp-code : integer] = [name : string, employs : {Clerk}(l,s), turnover : integer, head : Clerk] = [name : string, birth-date : Date, salary : integer, work-in : Division, emp-code : integer, level: integer] = [name: string, employs : {Typist}(1,5), turnover : integer, head : Typist] = [name: string, birth-date: Date, salary : integer, emp-code : integer, qualification : StringSet, work-in : Office, level : integer] = [name : string, collaborates : {Structure}(0,3), turnover: integer, employs: {Employee}(1,20), head : Clerk] =

T a b l e 2. Example of LOGIDATA~vc schema

Notice t h a t Z (T) = 0 ; in fact, T Y P ( T ) = D and :Z (D) = l;w , then the set {o E O I 6(o) E Z ( T Y P ( T ) ) } is equal to O. Further, r e m e m b e r t h a t VC, C ISAuT, thus the last intersection in the expressions 1 and 2 has at least one c o m p o n e n t which coincides with O. As an e x a m p l e of possible instance, let us consider a subset of the s c h e m a introduced above: C p = {Person, Organization, Division}, CD = {Employee, Clerk, D e p a r t m e n t , Secretary, Structure}. Let us consider the d o m a i n shown in table 3. In general, for a given schema S and d o m a i n Z: = ( O , 6 ) , there are m a n y

113

0

6(ol) ~(o~) ~(o3) 8(04) 8(os) 608) 8(07) 8(o8) 8(0,) 8(olo) ~(o11) ~(oa~)

Co1 ~02, 03, 04,05,06,07, 08,09,010,011,012 }

= = = = = = = -= =

[name: "A", collaborates: {o2}] [name: "B" , collaborates : {03}] [name: "C", collaborates: {oa }] [name: "D" , collaborates : {o5, 06}] Cname : "E", collaborates: {o,}1 [name: "F" , collaborates : {}] [name: "G", collaborates: {}] [name: "Research", employs: {oxo, oaa }, head: o,o, turnover: 13] [name: "Development", employs : {oa2}, head :o12, turnover: 16] [name: "Rupert", birth-date : [day : 18, month : 9, year: 1951], salary : !0000, works-in : os,emp--code : 250] = [name : "Robert", birth-date : [day : 28, month : 6, year : 1957], salary : 9000, works-in : os, emp-code : 132, qualification : {administrative}] = [name : "Mark", birth-date : [day : 5, month : 4, year : 1967], salary : 10000, works-in : o9, emp-code : 278 qualification : {engineer}, level: 1]

T a b l e 3. Example of domain

possible instances (depending on the primitive assignment). For a defined class C o , the possible instance is a set of object identifiers influenced by both the type definitions and the user defined hierarchy ISAu. T h e c o m p u t a t i o n of this set is related to the depends on relation, introduced in definition 5. If a class does not depend on itself, its possible instances can be univocally determined, given a d o m a i n Z and the interpretations of base types and primitive classes. For cyclic defined classes the possible instance, given the d o m a i n and the primitive classes, m a y not be unique, and additional choices are necessary. This p r o b l e m has been recognized also in [KV84], when dealing with queries. In our example, Employee, Clerk and D e p a r t m e n t ( a m o n g others) have recursive types. Let us consider the following interpretations of primitive classes:

Z (Person) = {o10, o11, o12} I (Organization) = {Ol, o2, o3, o4, 05,06, o7, os, o9} Z (Division) = {ol, o~, 03, o4, 05, or o7, os, o9}

T h e above interpretation admits, a m o n g others, the following interpretations of the defined classes Employee, Clerk, D e p a r t m e n t , and Structure:

114

271(Structure)

271(Employee) 271(Clerk) 2:x(Department) 272(Structure)

Z (Employee) 272(Clerk) 272(Department) 273(Structure) /:3(Employee) 273(Clerk)

273(Department)

= {04, 05,06, 07} {O10, Oll, O1~ {} = {04, 05, 06, 0~}

{o10, o11, o1 } {OLO,o11} {08} = {Ol, 05,06, o7} ---- {010 , 011,012} : {010,011,012}

{os, o9}

It can be observed that the interpretation of a cyclic defined class (see Employee) can be univocally computed when its description contains at least one reference to a primitive class (Division). But the interpretation of a cyclic defined class cannot be uniquely computed if its description contains classes which refer directly or indirectly to itself and are all defined (Clerk, Department, and Structure). The interpretations of Clerk, Department, and Structure vary between a minimum and a maximum. Since the definition of a possible instance is recursive, we can say that every possible instance is a fixed-point. The schema interpretation is then to be specified by choosing the possible instances which are legal instances, that is, are accepted as instances of a given schema. A possible choice is to adopt descriptive semantics, which accepts any possible instance as a legal instance. The descriptive semantics has the drawback of allowing many different instances for the same domain. Another choice is the least fixed-point semantics, which corresponds to a bottom-up computation and leads to the legal instance I1. In particular, the least fixed-point solution does not allow cycles in the data 3. From a semantic point of view this happens to be satisfactory when the cycle involves only one relationship, as in Structure, while it is less acceptable when more relationships are involved, as in Clerk and Department. The greatest fixed-point semantics corresponds to a top down evaluation and leads to the legal instance 273. In this case, the oids {o10, o11, o12} and {os, 09} are inserted in 27(Clerk) and 27 (Department) respectively. On the other hand, the cyclic objects Ol, 02, o3 are now inserted in 27(Structure). In [Neb91] an extensive survey on terminological knowledge representation formalisms with cycles is given and the computational problems are also considered, whereas in [BeBe92] the adoption of onsemanticse or another, with respect 3 Cycles in the data exist when an element is connected to itself via one or more

relationships.

115

to complex object data models, is discussed. Our choice, as in [BN91], is to adopt the greatest fixed-point, since it is more adequate to our intuition when dealing with cyclic class definitions, such as Clerk and Department. It is worth remembering that also in [LR89] a greatest fixed-point solution is adopted but is used there to compute the greatest possible extension of classes, while the actual extensions are strictly user-defined and, in our view, this corresponds to a schema with primitive classes only.

5

Legal Instance of a L O G I D A T A ~ y c S c h e m a

Definition 8 (Legal I n s t a n c e ). The legal instance ofa LOGIDATA~yc schema is the greatest fixed-point of all the possible instances which have identical interpretation of the atomic primitive classes. This section aims to provide an operational definition of the legal instance, hence the corresponding algorithm. In particular, the schema is transformed in order to introduce the atomic primitive classes and find a valid starting point from which the greatest fixed-point can be computed. 5.1

Canonical S c h e m a G e n e r a t i o n

Let S = (Cp, CD, T, TYP, ISA) be a schema, associated with a set of type descriptors T(L, B, C, T) and ~U a domain. In the previous section, the interpretation of primitive classes has been used as a starting point for interpretation of the defined classes. In general, this operation is subject to some constraints, since the description of the primitive class contains a set of necessary conditions to be satisfied by its instances. The constraints are due both to the structures and the interpretations of other classes. Let us consider, for instance, with reference to the example of the previous section, the object o13 with the following v a l u e:

[name: "Store", employs : {o10}, head: o11, turnover: 10, collaborates: {}] The arbitrary assignment o13 E 77(Section), may not be allowed or, in other words, this interpretation is not a good starting point, since it depends on the assignment oll E 2: (Clerk) and 27(Clerk) must be computed, as it is a defined class. In order to obtain a correct initial assignment, we define the new schema S, called canonical schema, which is obtained from S by substituting each primitive class Cp with a new primitive class Cp called atomic primitive class without any structure, and a defined class with the same structures as Cp. The transformation is shown in figure 2: the portion of schema of part a) is transformed into the portion of part b). Formally, we associate to a schema S over T(L, B, C, T) a schema S = ( Cp, CD, T, TYP, ISAo) over T(L, B, C, T) with the following properties:

116

1. C = C p [.J C D such that CD = Cp U CD, and C p is an isomorphic copy of Cp. 2. T = 0. In order to simplify the formalization it is convenient to have a schema S not containing the type names, by replacing the type name T by TYP(T). This is recursively produced by the function: 7 :T(L,B,C,T)--*T(L,B,C,T)

7 (t) = TYP(t) if t 9 T 7(t) = t i f t

9 BUC

7 ({t}(min,rnax)) -- {7 (t)}(min,max) 7 (emptyset) = emptyset

7([11 :tl,...,lk :tk])

=

[ll :7(tl),...,lk :7(tk)]

Since in set T there is a strict partial order and T is finite, there exists a natural number n such that 7 n = 7 n+l and we set ~ = {Tn(t) It e 7-}. 3. TYP(C) = TYP(C) V C 9 CD TYP(Cp) = TYP(T) VCp 9 Cp 4. ISAu is the same as ISAu with the following additional relations: Cp ISAo Cp

VCp E Cp

will indicate a possible instance of schema S. P r o p o s i t i o n 9. For any possible instance Z of S, there exists a possible instance of S, and viceversa, such that -

-

27 (c) = 27(c)

D

vc e cD

P r o o f S k e t c h Let Z be a possible instance of S; it follows immediately that 27 with 27 (C) = Z (C) VC E CD is a possible instance of S. In the opposite direction, it is easy to find an interpretation of the primitive atomic classes such that the result follows, ra Having proved the equivalence between the possible instance 7: of S and Z of S, we will, in the following, use 7: for simplicity. We are now able to formalize the intuitive result that the possible instance of an acyclic defined class can be uniquely constructed from the initial partial interpretations that assign oids to atomic primitive classes. Such initial partial interpretations will be denoted by 27. P r o p o s i t i o n 1 0 . Let S be a schema without cyclic descriptions. For any domain, any initial partial interpretation :~ can be uniquely extended to a possible instance of-S and then of S.

117

P r o o f S k e t c h If there are no cyclic descriptions then the class n a m e can be ordered so that each class names C E CD depends only on preceding class names and there are class names which do not depend on other class names (only on T). As the interpretation of the base types are predefined, and those of the atomic primitive classes are given, the interpretation of the class names can be constructed in the obvious way, starting from the class names which do not depend on other class names [] The characteristic of uniqueness will be maintained also in presence of classes with cycles. This result will be obtained by means of the fixed-point semantics, as introduced in the previous section.

person* ' )

person'*)

/

[

employee*)

(emp,o,ee)

I

( c,erk ) a)

b)

Fig. 2. Trasformation of the schema S in the schema

5.2

Computation

of the Legal Instance

In the present section we introduce a complete lattice of interpretations k~ and a m a p p i n g F : ~P --+ k~. A fixed-point of F will be a possible instance of a

118

LOGIDATA~y c schema. This allows the application of some results concerning the fixed-point techniques, which are drawn from [Sch86, Llo87, Baa90], to the computation of the legal instance. Let T ( L , B, C, T) be a set of types and S a domain. We denote with ~ the set of all interpreation over ,U with the same initial partial interpretation :~4, i.e. all interpretations that have identical interpretation of atomic primitive classes. The relation C is defined on #2 as follows:

z' E_Z

g Z(C)

VCeCD.

i.e. ~ is ordered componentwise by the inclusion relation over the interpretation of defined classes s. ~ t ordered by E is a complete lattice; least upper bounds (lub) are obtained by componentwise set union and greatest lower bounds (glb) by componentwise set intersection. The least element of ~ is Zj. (27j_(C) = 0, VC) and the greatest is ZT (ZT (C~ = O, VC). Let S be a schema over T(L, B, C, T) and F a function mapping intrepretations to interpretations as follows:

such that

r(z(c))={oeOl6(o)eZffVP(c))}n(

z(c,)) C iSAu C,

By comparing the above equation with the possible instance of defined classes, we can see that an interpretation 27 E ~ is a possible instance of S over ,U, if and only if 77 is a fixed-point of F. The function F is monotonic on ~ t (it immediately follows from the fact that / ' is downward w-continuous, as proved in the next section); consequently,/' has a fixed-point, or, equivalently, any :~ can be extended to a possible instance of S. More precisely,/' has the greatest fixed-point, the least fixed-point and, possibly, other fixed-points in between. By proposition 10, in a schema S without class names and having circular descriptions, the least fixed-point and the greatest fixed-point are identical, i.e. F has a unique fixed-point. In the following we show how the greatest legal instance can be constructed from a given initial partial interpretation. P r o p o s i t i o n 11. Let ~ be the set of all interpretations over ~ and F be the corresponding mapping. Then

g/p (r) = N r' (zT) i>0

4 The dependence of k~t on L' will be left unexpressed. 5 We note that, for all type t, if 2"~ ___ 2" then :T~(t) C_ 2"(t) V,U, i.e. the relation E_ can be extended to all types.

119

Proof. First of all, we show any increasing chain Z0 E lub({F(Ei);i > 0]). In fact, be the interpretation defined

that function F is upward w-continuous, i.e., for 1:1 _ Z~ E ... we have F(iub({Zi;i>O])) = let X = { Z 1 , . . . , Z , } , a subset of ~P~, and let Z by:

(C) :

5

~k (C)

k--I

C e -C D

Then, for all t E 7": Z (t) - N~=IEk (t). Furthermore, from the definition of F it is easy demonstrate that we have ~t

= n r(zk) k--I

Hence mapping F is downward w-continuous, thus the following result holds: gfp(C) = glb ({C (T); n _ 0}).

W e are now able to give the algorithm for the computation of greatest legal instance. First of all, we recall that C ~ (IT) = IT, C { (T) = F (C {-I (T)); F is monotonic, hence by induction C i-1 (ZT) _~ C i (ET). Consequently, from the expression of proposition I 1 it follows that: gfp(C) = C ~ (ZT)

where ~ is the least natural number such that F 7+I (ZT) = FT(ET). In order to simplify the algorithm it is convenient to find another expression for the greatest fixed-point of C. The notion of atomic primilive generalizations is introduced as follows:

Gp(C) -- {Cp I C ISAe Cp] In other words, Gp(C) is the set of atomic primitive classes reached with the ISAs relationship. Hence a possible instance can be expressed, according to the equation of the possible instance of defined classes, as follows:

Z(C) =

~

I(Cp~) n {o e O I 6(0) 6 Z (Y-Y-P(C))} n

(4)

cj , ap (c) C ISAE C{

where Z is the initial partial interpretation, as introduced in section 5. By observing the above equation it is naturM to choose, as the initial interpretation, the intersection of the ancestor primitive atomic classes, that is:

z+(c) =

N Cp,eGp (C)

+(+,)

120

Obviously, for any fixed-point 77 of r we have 27* _ 77; hence, g y p ( F ) is the greatest fixed-point of r which is less than or equal to 27*. Then g y p ( F ) can be expressed as glb ( { r n (27*); n > 0}); thus, by the above considerations, we have g y p ( r ) = r ~ (27*) where ~ is the least natural number such that r ~+1 (77*) = r z (27*). Finally, in table 4 we show the algorithm for the computation of greatest legal instance. As an example of computation, let us consider the following :~:

9 Initialitazion and iteration - class types:

If i = 0 then 2"o(C) =

N

t(C--pp~)

C p j e G p (C)

If i > 0 then Z, (C) = Z0 (C) n {o e O I ~(o) e z,_~ (YV-P(c)) } n

C ISAB Cr -

-

-

base types: Ii (Bk) = 79k ; set types: Z~ ({t}(.,m~) = {v. 9 Vs I " --<11"0 C_ Z, (t) I1_< m}; empty set: 2"i (emptyset) = {0}; tuple types: 27i ([1, : t~,...,lk : t~]) = {vt E I)T I vt is defined at least on {]1, . . . ,lk }

and vt(1,) E 2"i (ti),i = 1,...,k}. 9 Stop -

Zi = / ? i + 1

13

Table 4. A l g o r i t h m 1 [Computation of legal instance]

:~(Person) = :~(Employee) = {010,011,012} :~(Organization) = :~(Division) = {01,02, 03, 04,05,06,07, os, 09} Table 5 illustrates the activity of algorithm 1 for the computation of the gypinstance, given the above initial partial interpretation.

121

Class

Structure Clerk

Zo Ol,

9 9 .

Z1 ,

09

010~Ol1~O12

01,

Department o a , . . . , 09 Typist o10, on, o12 Ot~ce

9 9 9 , Or

O101011~O12

01 ~ 9 9 9 ~ 09

Z= O1,

9 9 9 , 07

O10~Ol1~O12

Za = Z O1,

9 .

.

,

Or

O101011~O12

os, 09

os, 09

os, oo

o12

o12

o~2

0 8 ~ 09

09

09

Table 5. Example of computation of a g/p-instance

6

Subsumption

The subsumplion relationship can be introduced with reference to the legal instance. D e f i n i t i o n 12 ( S u b s u m p t i o n ) . Given two types t and t' of a L O G I D A T A ~ y c schema S, we say that t' subsumes t, written t <: t', if and only if:

w

vz on 5, z (0 g 2" (t').

It immediately follows that < is transitive, reflexive and not symmetric (i.e. it is a pre-order) and induces an equivalence relationship _~ on types: t "~t ' ~

t < t ' A t' < t.

A class which explicitly inherits properties from another class is, of course, subsumed by that class. P r o p o s i t i o n 13. Given a L O G I D A T A ~ y c schema S and two classes C, C' E C: C ISAt, C' ::> C < C'. P r o o f S k e t c h The proof follows immediately from the definition of 2" (C). [] The inverse does not generally hold, as we will show by computing that Typist < Secretary, Typist _< Clerk and Office < Department even if not expliciy stated.

7

Coherent

and

Consistent

Schemata

One of the main objectives of taxonomic reasoning in a database environment is the validation of a schema. In a L O G I D A T A ~ y c schema there are two possible sources of validity problems: type definitions and ISA relationships. For this reason we will provide two definitions related to validity: coherence, with respect to types, and consistence, with respect to ISA and inheritance. Coherence and consistence can be violated independently. Nevertheless, we are interested in schemata which are both coherent and consistent, and it is possible to give a unique syntactical characterization for the two properties.

122

D e f i n i t i o n 14 ( C o h e r e n t t y p e s ) . Given a schema S = (Cp, CD, T, TYP, ISAu), a type t in S is coherent if and only if:

3 ~ ~z over •, z (t) ~

{}

A schema S is coherent if and only if it contains only coherent types. As mentioned in section 4, the type specification of class C must agree with the type specifications of superclasses of C. We are now able to formally specify this agreement by means of the notion of consistent schema. Definition15

(Consistency and inheritance).

Given a schema S = (Cp,

CD, T, TYP, ISAu) a class C E C is consistent with respect to inheritance if and only if: TYP(C)__TYP(C')

VC I C ISA~ C'

A schema S is consistent if and only if it contains only consistent classes. In a consistent schema we do not allow two related classes (C ISAu C') to have arbitrary associated types; the type associated to a class describes the internal structure of the instances of the class. An instance of a class (say Employee) being also an instance of its superclass Person, we want the instances to share common structures. It is worth noting that the concepts of consistence and coherence are independents. For example, let us consider the classes Wide-Division, Recorder and Middle-Division with the following descriptions: class Wide-Division = isa Division[employs: {Employee}(30,40)] class Recorder = isa Employee[work-in : Wide-Division] class Middle-Division = isa Division[employs: {Employee}(lo,30)] and with the following types: TYP(Wide-Division) = [name : string, employs : {Employee}(ao,40), turnover : integer] TYP(Recorder) = [name: string, birth-date : Date, salary : integer,1 work-in : Wide-Division, emp--code : integer] TYP(Middle-Division) = [name: string, employs : {Employee}(10,30), turnover : integer] In LOGIDATA~y c the incoherence can derive from the redefinition of common labels. The Wide-Division class, is not coherent, as the employs label is redefined on a type obviously disjoint from the corresponding type of Division, and is not consistent (TYP(Wide-Division) ~ TYP(Division)). The Wide-Divisibn class is not consistent (TYP(Wide-Division) ~ TYP(Division)) but is coherent (in fact, it admits the objects of the Division class with n employees, where 10 < n < 20). Finally, as TYP(Recorder) is not coherent and thus subsumed by any other type, the Recorder class is not coherent but is consistent.

123

7.1

C o m p u t a t i o n of t h e Legal I n s t a n c e

In this section, we will show how computation of the legal instance can be simplified when the schema is coherent and consistent. Intuitively, by comparing equation 4 and definition 15 it can be seen that the following set: (

N

{o e O ] 8(o) e Z (TYP(Ci))})

C IsAB Ci does not influence any legal instance 2" (C) if the schema is coherent and consistent. The effect of coherence is not obvious due to the presence of the cyclic defined classes, as shown in the following example. Let us consider the defined classes C1 , C2 and C3 with C2 ISAo C1, TYP(CI) = [a:inleger], TYP(C2) = [a : C3], TYP(C3) = [b : C2]. The class C2 is consistent but not coherent, as 2"(TYP(C~)) is disjoint from Z(TYP(C1)); we cannot then simplify 2"(C2) by eliminating the set {o E O ] 3(o) E 2"(TYP(C1))}. For this reason, we will consider a simplified schema, say S, derived from -S, where the ISAE assertions between defined classes are ignored, since they are implicitly contained in function TYP. The portion of schema of part b) of figure 2 is thus transformed as shown in figure 3. We will then prove the equivalence of the computation of the legal instance in S and in S. Let S = (Cp, CD, T, TYP, ISAu) be a coherent and consistent schema and be the associated schema defined as in section 5. It is already proved that the computation of a legal instance of S is equivalent to computation of a legal instance of S. In the simplified schema S = (Cp, CD,T, TYP, IS~-'Av) the ISAu relationship is defined as follows: C ISAu Cp

iff C ISA~ Cp,

VC E CD,

VCp E Cp

P r o p o s i t i o n 16. Let S be a coherent and consistentschema, I a primitive assignment and E the corresponding legal instance of S and ~ the corresponding legal instance of'S. Then

z (c) = i (c)

vc e

~D

Proof. The proof is in [Ben91]. The new formulation of the legal instance allows to be simplified algorithm 1 by rewriting the computation for class types as follows: -

class types: - If i = 0 then 2"0 (C) = [~CpjeGp (C):~(Cpj); - I f / > 0 then 2"i (C) = 2"0 (C) N{o E O ] 6(0) e 1i-1 (TYP(C))}

124

person*

person

employee

clerk

Fig. 3. Trasformation of the schema S into schema

7.2

Subsumption Computation

The purpose of this section is to give a syntactical characterization for the subsumption relationship and for the coherence and consistency checks. In the following we will show how the computation of subsumption for a consistent and coherent schema can be performed by the boolean function s u b s on the basis of a syntactical comparison of type descriptions 6. The same function s u b s can be used to check if a syntactically correct schema S is coherent and consistent. Notice that we cannot adopt an algorithm like the one presented in Introducing taxonomic reasoning in LOGIDATA*, as the presence of cyclic defined classes could lead to endless loops. As an example, consider the case of the classes Office and Department: the computation of Office < Department leads a new computation of some comparison Office < Department. The structure of the algorithm is strictly related to that of algorithm 1. In s The algorithm considers only types in canonical form, the extension to types with names is straightforward.

125

particular, the initialization step for classes takes, as a s t a r t i n g point, the subs u m p t i o n s which immediately follow from the user-provided ISA hierararchy. T h e implications which are not compatible with type descriptions are then discarded.

s u b s is a function s u b s : T x T --* {true, f a l s e } defined as: * Initialitazion and iteration class types:

-

-

-

-

If i = 0 then subsi(C',C) = true iff G p (C') C_ G p (C); If i > 0 then subsi(C',C) = true iff (subs0(C',C) = true) A (subsi_l (TYP(C'),TYP(C)) = true); base types:

subsi(B',B) = true iff B = B'. -

set types:

- subsi({t'}( .... ),{t}(p,q)) = true iff (subsi(t',t) = true ^ n < p A m >_ q); - subsi({t'}( .... ) , e m p t y s e t ) = true iff n = 0; - subs, ( e m p t y s e t , e m p t y s e t ) = true; - tuple types:

subs,([...,lk:

tk . . . .

],[ ....

l',: t'j,...]) =

true

iff Vk 3 j :

= Z;) ^ t

(subsi (tk,ti) = true); . Stop - subsi+l = subsiC3.

T a b l e 6. A l g o r i t h m 2 [Computation of subsumption]

T h e algorithm stops after a finite n u m b e r of steps; in fact, the initialization sets a finite n u m b e r of relationships and subsequent steps can only exclude relationships (if s u b s / = f a l s e then s u b s j = f a l s e for j > i), there exists a n a t u r a l n u m b e r i such t h a t s u b s / = s u b s i + l and we set s u b s = s u b s / . Theorem

17. Given two types t and t' o f a coherent and c o n s i s t e n t s c h e m a S ; t < t'

r

subs(t',t) = true.

Proof. T h e proof is in [Ben91].

An i m m e d i a t e consequence of this result is a partial inverse for proposition 13, valid only for primitive classes. C o r o l l a r y 1 Given a coherent and consistent schema S and two classes Cp ECp andC EC: C _~ C p ,r

C ISAu C p .

126

The following theorem shows how the checking coherence and the checking consistence of a schema can be performed by algorithm 2. T h e o r e m l 8 . A schema S is coherent and consistent iffVC: subs(TYP(Ci),TYP(C)) = true

VCi I C ISAo Ci[3

Proof. The proof is in [Ben91].

8

E x a m p l e s of Taxonomic Reasoning

Table 7 shows an example of computation of the function subs for the schema introduced in section 1. The table includes only the most significant results.

subs(C, C')

subs0

sUbSl

subs2

subs3

subs4

subs

(Clerk, Employee) (Clerk, Typist) (Typist, Clerk) (Clerk, Secretary) (Secretary, Clerk) (Typist, Employee) (Typist, Secretary) (Secretary, Typist) (Department, Division) (Department, Office) (Office, Department) (Department, Section) (Office, Division) (Office, Section

true

true

true true true true true true true true true true true true true

true false true false false false true false true true true false true

false true false false false false false true false true false true false false

false true false false false false false true false true false false false false

false true false false false false false true false true false false false false

false true false false false false false true false true false false false false

Table 7. Selected values for function subs

It is easy to extend the results of table 7 in order apply theorem 18 and to verify that the given schema is coherent and consistent. Consequently, we can say that subs computes the subsumption for the given schema. Besides the most intuitive subsumptions, subs computes the following relations: Typist < Secretary, Typist < Clerk and Office < Department. As an example of the effectiveness of subsumption computation for schema consistency checks, we add the following class definition: class Adm-Department = isa Department[employs: {Typist}(1,5)]

127

If the consistency check is performed only by explicit isa relationships, AdmDepartment would be detected as inconsistent with respect to strict inheritance, as the redefined property employs has value Typist which has not been explicitily declared as a specialization of Clerk. By subsumption, Typist is computed as a specialization of Clerk, therefore the class Adm-Department is recognized as consistent with respect to the schema and automatically classified as a specialization of the Department class. Further, by subsumption computation, we can detect equivalence between classes with different explicit descriptions, thus detecting synonymous ones and avoiding redundancies. Suppose the following classes X and Y be given: class X

isa Employee, Secretary [work-in :Y]

class Y = isa Department [head: X, employs: {X}(1,5)] The following equivalences are detected: X _~ Typist Y "-" Office. Therefore, X and Y can be simply stored as synonymous. It is worth noting that all three semantics (greatest, descriptive and least) mentioned in section 4 produce legal instances which can be considered valid (i.e. useful at some respect). Our choice for the greatest fixed-point pushes objects down in the hierarchy (i.e. towards more specific classes) and this allows a set of inferences which are, in our opinion, more interesting. Algorithm 2 can be used to restructure a schema and the result is a schema which is equivalent to the original one only with respect to the greatest fixed-point. Roughly speaking, this leads to computation of a greater set of ISA relationships and, possibly, to considering equivalent classes which, with other, more conservative semantics could be different.

References Baader, F. Terminological cycles in KL-ONE-based KR-languages. In Proeeedings of the 8th National Conference of the American Association for Artificial Intelligence, Boston, Mass., 1990. Computation of Subsumption with Cycles in [Ben91] Beneventano, D. LOGIDATA+. Technical Report 80, CIOC - CNR, Bologna, October 1991. [BeBe92] Beneventano, D., and Bergamaschi, S. Subsumption for Complex Object Data Models. Proceedin9s of the International Conference on Database Theory, Berlin -1992, Springer Verlag Publisher. Bergamaschi, S., and Nebel, B. Theoretical fondations of complex object [BN91] data models Technical Report 5/91, CNR, Progetto Finalizzato Sistemi Informatica e Calcolo Parallelo, Sottoprogetto 5, January 1992. [KV84] Kuper, G.M., and Vardi, M.Y. A new approach to database logic. In PODS '84, pages 86-96. SIGACT-SIGMOD-SIGART, ACM Press, 1984. Lecluse, C., and Richard, P. The O~ data model. In Int. Conf. On Very [LR89] Large Data Bases, 1989. Lloyd, J.W. Foundations of Logic Programming. Springer Verlag, Berlin, [Llo87] 1987. [Baa90]

128

[Neb91] [Sch86]

B. Nebel. Terminological cycles: semantics and computational properties. In J. Sowa, editor, Principles o.f Semantic Networks. Morgan Kaufmann, 1991. D.A. Schmidt. Denotational Semantics: A Methodology ]or Languages Development. Allyn and Bacon, Boston, 1986.

Modeling Semantic Integrity Constraints in Object-Oriented Database Schemas Anna Formica, Michele Missikoff IASI CNR - Viale Manzoni 30, 1-00185 Rome, Italy

A b s t r a c t . Recent years have witnessed a continuous evolution models towards richer and more expressive paradigms. Along

of database the line of enriching the modeling capabilities, Object-Oriented databases (OODBs) have been introduced. In this paper, we propose a further enhancement to OODB models aiming at enriching the database s c h e m a by explicitly declaring semantic integrity constraints therein. In the paper, we present an Object-Oriented data definition language, referred to as TO~. It allows the construction of an OODB schema using the well known data structuring mechanisms, such as NF2 attributes, complex types, and multiple inheritance in class (type) hierarchies. In addition, TO,,L allows the further enrichment of the schema by expressing explicit integrity constraints. The proposal includes the definition of the formal semantics of TO~, according to a denotational approach, and the notion of correctness of schemas, with particular emphasis on the legality of ISA hierarchies. The proposed language is the basis of the prototype MOSAICO, an environment for the design and rapid prototyping of OODB applications developed at IASI.

1 Introduction Object-Oriented database (OODB) systems appear to be the candidate successors of relational database systems. With respect to the latter, the former are characterized by richer functionalities and more expressive data languages [8], [2], [15], [30]. In particular, an OODB system is a DBMS and an Object-Oriented system [6]. Being a DBMS, it is characterized by persistence and advanced data management functions, such as secondary storage management, concurrence, ad hoc query facility. Being an Object-Oriented system, it is endowed with the following features: object identity, complex objects (possibly recursively built), inheritance and hierarchical organization of types and classes, encapsulated methods, overriding combined with late binding, extensibility and computational completeness. The field of OODB systems appears, at present, characterized by a strong experimental activity which contrasts with the lack of a unifying view of the data

This research has been partially supported by "Progetto Finalizzato Sistemi Informatici e Calcolo Parallelo" of CNR, Subproject 5, Group Logidata+, and Subproject 6, Group Infokit.

130

model and formal foundations. It appears difficult to reach large consensus on a clear and formal specification of the model, on a declarative data manipulation language (something similar to SQL for relational databases), and on techniques for enhancing performance in data retrieval with query optimization. Furthermore, most of current Object-Oriented database systems lack direct support for formulating complex semantic integrity constraints. Nevertheless the existence of facilities to handle such constraints is an essential premise to improve the development and management of complex applications. In a data model, constraints are required for semantic and integrity reasons. In terms of semantics, they allow to enhance the expressiveness of the model by defining schemas which capture the real world situations in a more detailed way. In terms of integrity, they prevent certain iypes of inconsistencies, caused by misunderstanding or inaccuracy, by restricting the possible database states to those that satisfy such constraints.

1.1 Related Work

In contrast with the great demand for data integrity in database applications, there are only few OODB systems that provide explicitly this type of capabilities, and, in particular, that provide a declarative constraint language. This issue has been mainly investigated for traditional database systems [33], and in particular in relational and deductive databases areas. The latter, in particular, has been influenced by logic programming and, more recently, by Constraint Logic Programming [24]. Let us briefly survey the literature in these areas. In relational models, this problem has been widely studied. For example, in [11], [14], integrity constraints have been formalized providing a general purpose Constraint Specification Language which is a natural extension of the data definition language. In [31], a model of integrity control is presented, that addresses both validity and completeness of a relational database, also dealing with the integrity of the answers produced by the queries. Integrity constraints have been also studied in logic programming area. Constraint Logic Programming (CLP) [24], [13] is an extension of logic programming, where mechanism of unification is replaced by the more general notion of solvability of a set of constraints. Deductive databases have been developed taking advantage of the two above mentioned research areas: relational databases and logic programming [19]. The aim of this approach is to use logical languages to reason and query about database content. In this area, integrity constraints are closed first order formulas that database is required to satisfy [22], [3], [29]. As said before, the problem of expressing declarative constraints in an ObjectOriented data model has been analyzed by only a few authors. We recall, for example, the ALICE language [36], [34], that is used to express complex constraints by means of Horn logic expressions. Another proposal is related to the PIROL project [20], that is devoted to support complex objects and explicit semantic integrity constraints. Similarly, the ODE [21] system allows the definition of constraints, focusing on

131

actions to be taken in presence of violations. These proposals are very rich. However, their complexity precludes the possibility of investigating theoretical aspects of database schemas and, in particular, to define a clear declarative semantics needed to support the design of correct database schemas. In this paper, we propose a formal model for Object-Oriented databases which allows the definition of a schema in terms of types and constraints. The goal is to supply a uniform frame for the database designer, to define at intensional level not only the structural component (essentially the types) but also to enrich it with semantic integrity constraints. The intensional component of the model is presented by means of the language TO~ (Typing as Query Language). TO.,6represents the synthesis of the work carded out both at a theoretical [18], [16] and experimental [25] levels, within the project MOSAICO, at IASI-CNR, and the national research activity LOGIDATA+ [5], which aims at extending the functionalities of the Object-Oriented database systems in the direction of deductive databases. The guide lines of TOJ~ have been influenced by existing OODB systems, such as 0 2 [26], [27], [28], ORION [7], ODE [21], and by theoretical researches in the field [9], [ 12], [4]. The main features of TO,6model are: (i) clear separation between types and classes (and, therefore, between intensional and extensional components of the database), (ii) formal definition of class as a collection of objects, extension of a type in the schema, (iii) possibility of expressing explicit integrity constraints within the database schema, (iv) complex types modeling as sets of necessary and sufficient conditions for the corresponding objects. These characteristics are formalized using a pure denotational semantics and represent new issues with respect to existing proposals in the fields [27], [21], [7]. Existing systems present characteristics such as: (a) use of class names to define types, (b) semantics informally defined or, eventually, defined following an operational approach, (c) the notion of class derived from programming languages, i.e. as a structure encapsulating data and behaviour, rather than databases, i.e. as extension of a type declared in the schema, (d) absence of mechanisms associating integrity constraints to types in the schema, and integrity enforcement performed by methods, (e) complex types considered, essentially, for structuring purposes rather than for semantic integrity. The rest of the paper is organized as follows. Section 2 gives an overview of the main static characteristics of Object-Oriented data models, focusing on specific TO.# features. In Section 3, the innovative features of the TO.~ data model are introduced: the uniform view of type structure with ISA hierarchy and integrity constraints. Section 4 presents the formal syntax of TO,L and the notion of TO.,L schema. Furthermore, the definition of legal ISA hierarchy is given, and the normal form of types is introduced. In Section 5, the formal semantics of TO~ types and integrity constraints is shown, followed by the definitions of interpretation and model of a Tt2L schema. Finally, conclusions are given.

132

2 Main Features of Object-Oriented Data Models In this section, the main features of the static component of an Object-Oriented database model are presented [6]. It is agreed that a desirable feature of a database model is a clear separation between the intensional (i.e. schema) and extensional (i.e. data) components of the database [35]. This goal is not easily achieved in OODB model, due to its origin rooted in programming languages and the complexity of the model itself. For example, in the 0 2 data model, types are defined in terms of classes and their semantics are tightly interwoven. A second point is the co-existence of objects and values: what are their respective roles, when to use one or the other. We believe that avoiding their mixing will substantially increase the simplicity of the model, without loss of expressiveness. Let us briefly analyze both these issues. In TO~ data model, the intensional component (i.e. the schema) is represented by type-definitions. Type-definitions are T0.,6 formulas that can be composed without referring to database classes, objects, values, nor to any other extensional element. Classes and objects are not expressible in TO~ they belong to the realm of data. With this approach, we reach a complete separation between intensional and extensional components of the database. In this respect, the approach is closely related to logical theories, where types correspond to logical formulas and classes to their interpretations. About the dichotomy between objects and values, we agree with [9] and, in particular, with the notion of abstract object. Abstract objects represent any conceivable conceptualization of real (and sometimes unreal) world entities, from a simple integer or string, such as 27 or "ferrafi", to complex entities, such as persons and cars. Objects are denoted by a special class of names, called identifiers, or oids for short. There is a special class of "built-in" objects, on which the system is able to perform well defined manipulations, such as integers or strings. For those "fully axiomatized" objects, referred to as values, the state corresponds to the oid. In this perspective, values are reduced to a special case of oids, i.e. identifiers of fully axiomatized objects. Complex values do not exist, we have complex objects instead. Here, the Object-Oriented features of the TO~ data model are briefly presented. They are illustrated following the points exposed by [6], with few modifications due to the specificity of our proposal. Obiects and Values - Objects are the basic entities of an OODB, which is essentially seen as a collection of them. All objects are atomic and, unlike other proposals, they are not endowed with an "internal" state. Nevertheless, we distinguish elementary and complex objects essentially on the base of the relationships with other atomic objects. In this view, we can use the term state, for a complex object, to indicate the set of relationships with other objects. Such a state is associated to a complex object, and is represented by a tuple of labeled oids. Values are just special objects: they are elementary objects known to the system, and they do not need to be defined by an associated tuple. Obiect identity - This is a central notion for OODB models. Every object has an identity, given to it when it is created. Such an identity is unique within the database

133

and immutable throughout its lifetime. Oids give the possibility to specify the relationships that complex objects have with other objects. Object sharing is a desirable characteristic that originates from the use of complex objects within tuples. Comolex obiects - Complex objects are represented by those oids that have an associated tuple. Tuple constructors can be nested to any (finite) depth. Since we restrict the components to be only oids, we obtain complex objects inherently different from complex values [1], [23]. For example, elementary objects (values) are: 34, ted, fiat, john, 21, math, 150. Complex objects are: #per 12, #car3, #stud 1, and their corresponding tuples are: [name:ted, age:34, vehicle:#car3], [maker:fiat, speed: 150], [name:john, age:21, vehicle:#car3, dept: math]. Note that, to increase readability, oids of complex objects start with the character # (pound). Recursive obiects - This is a feature common to expressive Object-Oriented data models. The use of oids of complex objects in a tuple allows the reference to another tuple which, in turn, can reference the former. There are no limitations in the use of this mechanism, having also oids referencing their own structures (i.e. self-recursive objects) or participating in a circular chain of arbitrary length. Below, two recursive objects are given. mgr: (#empl2, [name:john, salary:50K$, head_of: #d3]) dept: (#d3, [name:toys, floor: 4, manager: #empl2]) Type - A type is an abstract representation of the characteristics common to a set of objects. Given an object, it is always possible to decide whether it satisfies a type or not. Type-definitions are sentences of TO,6 having a label, a definition expressed as a tuple of typed properties and, eventually, one or more integrity constraints associated to them. A database schema consists of a collection of type-definitions which, therefore, represents the first information to be given when creating a database. Then objects can be entered according to the types in the schema (unlike other systems, such as ORION [7], untyped objects are not allowed in TO# databases). The presence of type labels plays a primary role, allowing the definition of recursive types and, very desirable feature, avoiding the use of class names in type definitions. In the following, two type-definitions are illustrated. mgr := [name:string, salary:string, head_of: dept] dept := [name:string, floor:integer, manager: mgr]

134

Nested Tuoles - In a tuple, a property can be typed using a type label or another tuple. The former allows object sharability at extensional level, the latter allows the definition of nested tuple types whose instances will be represented by nested tuples of objects not sharable by other objects. For example: person := [name:string, address: [street:string, city:string]]. Recursive Types -TO~ allows a rich mechanism for recursion. We have a selfrecursive type when at least a property is typed using the same label of the typedefinition. In general, recursion is achieved when a type has a property typed with the label of a type-definition that, in turn, has a property typed with the former. The following is an example of recursive type-definition (note the use of curly brackets to indicate multi-valued properties): person := [name:string, age:integer, child:{person}]. Subtyping - Types are organized according to a generalization hierarchy, using the very powerful relationship of subsumption[10], also referred to as refinement [5]. The semantics of T0.~ subsumption includes the three kinds of structured inheritance inclusion, constraint, and specialization inheritance [6] - introduced in existing OODB systems. Essentially, subtyping implies the inclusion between the corresponding extensions of types, i.e. between the sets of objects that satisfy such types (classes). Therefore, subtyping is a partial order relationship over the set of types. Class - Classes form the extensional component of the database. There is one class for each type-definition in the schema. Classes are the repositories for objects, therefore, they represent an extensional notion. The notions of type and class are disjoint: they correspond, respectively, to the notion of formula and interpretation in a logical theory. In this view, the schema of a database is seen as a theory and the database as an interpretation. A database update represents a transition from an interpretation to another one. Extensibilitv - The set of types is extensible, in the sense that, given a database, new types can be defined, and there is no distinction between existing and newly defined types [6]. In the next section, we introduce the two main features of the TOJ~data model: the ISA hierarchy, based on strict refinement, and semantic integrity constraints. Their rigorous formulation and formal foundation are not common to existing ObjectOriented database [6].

3 Enriching OODB Schemas with Constraints The TO_Ldata model allows the definition of implicit and explicit constraints. Implicit constraints are expressed inside the tuple of the type definitions as, for example, cardinality constraints or domain constraints. Explicit constraints are associated to

135

tuples. They enrich the expressiveness of the model adding declarative knowledge to the schema, thus allowing the reduction of the procedural component of the database. We also consider inherent constraints, i.e. constraints that are imposed by the model itself, such as refinement constraints, related to the ISA construct, or aggregation constraints, related to tuples of typed properties. In this paper, T0,,6 refinement constraint will be analyzed only for what concerns the structural component of the language. Refinement is briefly introduced below, followed by a description of implicit and explicit integrity constraints. The next section will focus on refinement in a more detailed way.

3.1 The ISA Hierarchy In TO~, the ISA construct is used to define a type in terms of its supertypes. This construct can be followed by a tuple of typed properties. This represents the structural definition of the type (the dynamic definition, represented by methods, will not be tackled in this paper). A type defined by means of the ISA construct inherits the typed properties of its supertypes (it inherits explicit constraints as well, but here we concentrate on the structural aspects only). For each typed property, inheritance can be absolute, composed or refined. Inheritance is absolute if the property belongs to only one supertype and is not re-defined in the subtype. Inheritance is composed if the property belongs to at least two supertypes. Finally, inheritance is refined if the property belongs to supertypes and to the definition of the subtype. If inheritance is absolute, the typed property is inherited without any modification. In the second case, a composition of typing for properties having the same name is required. As we will show in Section 4, such a composition is obtained by considering a type (if there exists) that is subsumed [18] by the given ones. Finally, in case of refined inheritance, an overriding is required. In particular, the typed properties of the supertypes will be overridden by the one specified in the definition, if the latter is a refinement of the former. In case of properties belonging to more than one supertype and also to the definition of the type, composition is applied before overriding. The above conditions determine the legality of ISA hierarchies. This issue will be formally tackled in Section 4. In this subsection, some examples are provided. The following ISA hierarchy is legal: person := [name:string, age:integer] parent := ISA person [age:(10..150), child:{person} 1,5]. Note that TO~ allows the typing of properties by explicitly defining a range of values in parenthesis. Furthermore, in the example, cardinality constraints are associated to the multi-valued property child. In applying the refined inheritance to the property age, the condition of refinement between the type integer and the set of values specified in the tuple is satisfied. Refinement is violated in the following type-definitions:

136

vehicle := [maker:string, color: {(red,blue,green) }1,3] car := ISA vehicle [maxspeed:integer, color: {(yellow,red)} 1,2] , because the types of the property color are not in subsumption relationship. In the following, we sketch the TOoLrefinement rules, that have been developed in a first version in [18], on the line of [12]. Two types are in refinement (subsumption) relationship if the subtype is obtained from the supertype by: (i) adding one or more properties to the properties of the supertype, or (ii) refining the cardinality constraints of one or more multi-valued properties of the supertype, or (iii) refining one or more properties of the supertype by defining subsets of enumerated types, or (iv) refining one or more properties of the supertypes by typing them with labels of refined types. A type-definition which is not defined by means of the ISA construct is said to be in normal form. In the next section, the problem of the legality of the ISA hierarchy is analyzed in detail, and the related problem of normal form reduction of a typedefinition will.be addressed.

3.2 Implicit Constraints Being expressed in the tuple, implicit constraints are introduced through the flexible typing mechanism for properties. Implicit constraints can be classified into the following four cases. - Tvnin~ constraints In the preceding section, we have seen that properties can be typed using type labels. For example, in the type-definition: person := [name:string, age:integer, vehicle: {car }] car is a type label which needs to be defined in terms of a TO.# sentence. It imposes a typing constraint on the property vehicle, requiring that the vehicles of a person, whenever they are present, have to be cars.

- Domain constraints TO,# properties can be typed also using enumeration or an interval specification. Domain constraints have the form of a list, or an interval (in case of well ordered domains), defined using constant symbols. In the following example: car := [maker:(Fiat,Ford,BMW), m_speed:(120..200), owner:person] the instances of the type car will be only objects produced by one of the three listed firms. Furthermore, the maximal speed will be any integer falling in the specified interval. - (Tardinalitv con,traints As already mentioned, multi-valued properties allow the association of a set of objects to another object. In TO.#, it is possible to express constraints on the (minimal and maximal) cardinality of the sets denoted by multi-valued properties. For example:

137

person := [name: {string }1,3, age:integer, vehicle:{ car} +]. If m,M represent the interval extremes, in TO,t2sentences the absence of curly brackets is a short-hand for m -- M = 1, while curly brackets without cardinality constraints or followed by the + symbol are short forms for m = 0, M = o~, and m = 1, M -- oo, respectively. - Referential constraints A referential constraint is obtained combining typing and cardinality constraints. For example, in the following type-definition:

person := [name:string, age:integer, vehicle:car] each person is required to have one (and only one) vehicle, and this vehicle must be a car .

3.3

Explicit

Constraints

TO,L explicit constraints are comparisons over properties, expressed using the dotnotation formalism. They are specified in the schema, being part of the typedefinition. They are referred to as "0-constraints", where "0" stands for arithmetic comparators, such as "=", ";e", ">", ">". Comparisons are declared between values and, more generally, oids. For example: person := [name:string, age:integer, ssn:integer, child: {person} 1,5], icl: this.ssn ~ person.ssn teacher := ISA person [student: {person }+], ic2: this.student ;e this.child employee := ISA person [salary:integer, boss:employee], ic3: this.salary < this.boss.salary In the above schema, three explicit constraints are given. Note that, the first has the right hand side defined using a type-label, while the other ones use the keyword "this". In particular, the constraint icl states that the social security number (ssn) of a person must be different from the one of all the other persons. The second, expresses that teachers cannot teach to their children. The third states that an employee has to earn less than the salary of his boss. From this example follows that, in explicit integrity constraints, a type label denotes an entire class, while the keyword "this" refers to a single object. Note that, when the right hand side of the comparison starts with the type label of the type being defined, as for the integrity constraint icl, the type label denotes the corresponding class, less the object denoted by "this". In Section 5, we will see that a "0-constraint" is assumed to be universally quantified on the denoted sets (universal quantification on paths). For instance, in the above example, ic2 requires that all the students of a teacher have to be different from all his/her children. Furthermore, in TOj2, given a type-definition, explicit integrity constraints must be satisfied by every object in the associated class (universal quantification on classes). In this sense, all the teachers have to satisfy the constraint

138

ic2. With this assumption, the keyword "this" stands for a pseudo-variable ranging over the entire class.

4 F o r m a l Issues on D a t a b a s e Definition In this section, the syntax of the language TO~ is formally presented. The language is a direct derivation of 00.6, developed to analyze the relationships between ObjectOriented systems and the Frame-based systems proposed in Artificial Intelligence [32], [18]. Previous proposals of T0~ have been presented in [16], [17]. In the second subsection, the formal definition of TO~ schema is given. Finally, the legality of the ISA hierarchy is formally introduced and, successively, the normal form reduction of a type-definition, that is not in normal form, is illustrated. These notions are the basis of the static verification performed to check the correctness of TO~ schemas.

4.1 T0~ Syntax In TO~, we have terms and sentences. Terms can be tterms, p_terms, and c_terms. A t_term is a type label. A p_term is a property name. A c_term is a constant, or a sequence of p_terms (path) preceded by a t_term or the keyword "this". Sentences can be atomic, type-sentences, constraint expressions and type-definitions. An atomic sentence is simply a name, e.g. car, person, color, integer, or an enumerated set, e.g. (4,8,9,22) or (red,green,yellow). A type-sentence is defined using two basic constructors (not mutually exclusive): ISA and tuple. A constraint expression is a binary comparison predicate, taking two c_terms as arguments. A type-definition associates a t_term to a type-sentence or to an atomic sentence and, eventually, to one or more constraint expressions. In the following boxes, the formal syntax of TO~ is presented: non-terminal symbols are in small plain characters, while terminal symbol are in bold. Symbols in italics are user-defined strings.

Definition 4.1 Syntax of T0~. ::= t t e r m := [, ..... ] ::= IISA t t e r m ... t_term ::= t_term I I (value_set) I [<tp>,...,<tp>] ::= integer I real I boolean I string I T O P <tp> ::= p_term:{}m, M

m,M ~ 1~0 u {~}, m < M

The following box shows, in particular, how the value_set construct can be expressed. It canbe enumerated, or an interval specification. The interval can be open or closed.

139

Definition

4.1 continued: the (value_set) construct.

9 Enumerated Example : (red, green, yellow) (1,4,7,12) 9 Interval Stw,cification - (n..N) n,N are included - (n<..N) n is not included and N is included - (n..
- (..N) if the interval is (- oo,N) - (n..) if the interval is (n,+ =) where n,N e 9~ and n_< N.

TO.X;explicit integrity constraints are now formally introduced. They are binary comparison predicates taking c_terms as arguments. This simple form can be easily generalized to boolean expressions of binary comparisons [17]. A c t e r m is a constant, or it is defined by using a path. A path is a sequence of p_terms composed using the dot-notation formalism. Dot-notation is a means to traverse data connections in a database. It selects the oids on which the constraint must hold. The syntax of integrity constraints is given in the box below. The terminal symbol "this" stands for a pseudo-variable ranging over the class denoted by the type being defined.

Definition 4.1 continued: integrity constraints. ::= label : ::= <0> ::= this.<path> ::= this.<path> I t_term.<path> I k <path> ::= p_term .... .p_term <0> ::= < 1 > 1 < 1 > 1 = 1 ~

4.2 TO# Schemas

In this subsection, we define the properties that a set of type-definitions must satisfy in order to be a TO/: schema. A non empty set of type-definitions S is fully defined (defined for short) if and only if all the t_terms used to form type-sentences and constraint expressions in S are

140

left hand side of type-definitions in S. Then, we have the following definition of T0os schema. Definition 4.2 TQL schema. A TO~ schema is a defined set of type-definitions,n Consider the set of To~ type-definitions: person := [name: {string} 1,2, age:integer, child: {person}] student := ISA adult [age:(18..40), college:university] This is not a schema because the t_terms adult and university do not appear in the left hand side of any type-definition, nor are they basic types. On the contrary, the set: person :-- [name: {siring }1,2, age:integer, child: {person }] student := ISA person [age:(18..40), college:string] is a TO,L schema.

4.3 Legality of the ISA Hierarchy In Section 3, we have seen that a type, defined by means of the ISA construct, inherits the definition of its supertypes. Typed properties of supertypes are inherited as they are (absolute inheritance), by composition (composed inheritance), or by refinement (refined inheritance). We have also anticipated that, the legality of the ISA hierarchy is related to the refinement of types of common properties. In this subsection, we give the formal definition of legal ISA hierarchy. Then, some examples, related to it, follow.

Definition 4.3 Legal ISA hierarchy. Given a schema, the ISA hierarchy of such a schema is legal iff ISA is not cyclic, and for each type-definition with ISA, the following conditions are verified.

1) Comoosed inheritance: for each property p_termh belonging to at least two supertypes (eventually belonging also to the definition of the type), as in the following: t_term := ISA t_terml ... t_termr [...] t_terml := [.... p-termh:{bodyl}ml,M1 .... ] t_termn := [.... p_termh:{bodyn}mn,Mn.... ] where 2 < n < r, there exists bodyh such that: if bodyi, i -- 1..n, are basic types or sets of values, than bodyh = N i bodyi r O if bodyi, i = i..n, are type labels or tuples, than bodyh is a type label of the schema, that is the greatest lower bound (glb) of bodyi, i = 1..n, according to the partial order induced by the subsumption relationship over types. Furthermore, there exists an interval of cardinality, [m h, Mh], such that,

141

for i = 1..n: [mh, Mh] = 0 i [mi, Mi] ~ O. Then, the inherited typed property, will be the following one: p-termh: {b~ }mh,Mh"

2) Refined inheritance: for each property p_term h belonging to supertypes and to the definition of the type, as in the following: t_term := ISA t terml ... t__termr [ .... p_termh:{bodyh}mh,Mh .... ] t_termi := [.... p_termh:{bodyi}mi,Mi .... ] where 1 < i < r, it results: bodyh is subsumed by bodyi. mi_< mh and Mh < Mi. The inherited typed property will be the following one: p_termh: {bodyh }mh,Mh. -

[] Note that, as already mentioned in Section 3, when a typed properly must be inherited by composition and by refinement, composed inheritance will be performed before than the refined one. Therefore, conditions related to refined inheritance will be verified on the typed properties inherited by composition. For example, the ISA hierarchy of the following schema is legal: vehicle := [maker:string, color:(red,green,blue)] car := ISA vehicle [colon(red)]. In fact, the property color has to be inherited by refinement, and the conditions related to types and cardinality intervals of such a property are satisfied. Also the following ISA hierarchy is legal: young := [name:string, age:(0..30)] mother := [name:string, sex:(female), age:(10..150)] youngmother := ISA young mother [age:(10..25)] because the property age is inherited first by composition, with typing (10..30), and then by refinement, with typing (10..25) specified in the tuple. On the contrary, the following ISA hierarchy: person := [name:string, age:(0..150), vehicle: {car}2, 3] student := [name:string, age:(18..40), vehicle: {car }0,1 ] gr_student := ISA person student [age:(23..40)] car := [maker:string, color:string] is not legal, because the conditions for composed inheritance are not satisfied. In fact, even if the property age is correctly inherited first by composition and then by refinement, for what concerns the property vehicle, the intervals of cardinality have empty intersection, Also the following ISA hierarchy:

142

student := [name:string, age:(18..40)] mother := ISA student [age:(20..150)] is not legal. In fact, the type of the property age is not a refinement of the corresponding type in the supertype student. However, these are patterns easy to correct; in fact, in order to obtain a legal ISA hierarchy, it is sufficient to consider the intersection (or a subset of it) of the types of the property age. For the example, the system will suggest to the designer to modify the type of the property age of a mother, with the interval (20..40). Similarly, consider the example: person := [name:string, age:(0.. 150)] teenager := ISA person [age:(13.. 19)] young := ISA teenager [age:(18..25)]. Also in this case, the system notifies the illegality and suggests, for example, the following correction: young:= ISA teenager [age:(18.. 19)].

4.3.1 Normal Form Reduction

In this subsection, we deal with the problem of reducing in normal form a typedefinition expressed by means of the ISA construct. To this end, inheritance is thoroughly applied (we consider schemas having legal ISA hierarchies) and typedefinitions are re-written by using only typed properties. In the following, it is shown how this problem is related to the possibility of verifying subtyping between types on the basis of their typed properties only. We show that this happens if the typedefinitions with ISA are normal form reducible. Let us introduce the following definition. Definition 4.4 Normal form reducible type-definition.

A type-definition with the ISA construct is normal form reducible iff, applying inheritance, it can be transformed into a semantically equivalent type-definition that is in normal form. ra Note that, two type-definitions are semantically equivalent iff they denote the same set of objects for all the interpretations. The above definition states that, if a type-definition is normal form reducible, then there exists another type-definition, in normal form, semantically equivalent to it. Normalized type-definitions are then used to verify subtyping. On the contrary, if the type-definition is not normal form reducible, subtyping is axiomatic, and cannot be proven. In such cases, the ISA construct represents more than inheritance. It represents an axiomatic set containment constraint that cannot be modeled by any structural component. For example, consider the following schema:

143

person := [name:string, age:(0..150)] student := ISA person [age:(18..40), friend:student]. In this case, the second type-definition is normal form reducible because it can be transformed into the following type-definition, semantically equivalent to it: student := [name:string, age:(18..40), friend:student]. Therefore, in this case, it is possible to verify that person is a supertype of student also using the last type-definition, i.e. only on the basis of their respective typed properties. Consider now the schema: person := [name:slxing, friend:person] student := ISA person [friend:student]. The ISA hierarchy of this schema is legal since student is a subtype of person. However, if we apply inheritance, and we override the property friend, we obtain the following type-definition: student := [name:string, friend:student] that is not semantically equivalent to the original one since student is not a refinement of person any more. In this case, the ISA conslluct is axiomatic and, therefore, it is not possible to establish that a student is a subtype of person on the ground of theh' structure, i.e. their typed properties. In this sense, we say that, if a type-definition is not normal form reducible, then the refinement relationship between types and supertypes is not effectively computable. Finally, we introduce the following definition. Definition 4.5 ISA certifiable schema. A schema containing at least one type-definition with ISA is ISA certifiable iff all its type-definitions with ISA are normal form reducible. [] Therefore, in a ISA certifiable schema, the system is able to verify the hierarchical relationships between type-definitions on the ground of their structure, and no axiomatic set containment relationships are given.

5 Formal

Semantics

of TQL

The semantics of TO~ given here follows a pure denotational approach [10]. With this approach, a type is a formula and a class is simply one of its possible extensions. Given an interpretation, there is a tight and immutable association between types and classes: given a type, there is only one class that corresponds to it. In this perspective, a class update causes a transition from an interpretation to another one. An interpretation is represented by a database state. Preliminary work, in this direction, has been carried out by comparing OODB systems and knowledge representation systems [32], [18].

144

Definition 5.1 The semantics of T0,# types and integrity constraints. Let 5", be a finite set of oids representing a given state of the Application Domain, T the set of T0,,6 sentences, and P ( c T ) the set of p_terms. Consider a function ~ from T to the powerset ~o(~): ~ : T ---> ~o(~) and a function I'I from P to the powerset ~o(Y, x Y,): 11: P-->

~(XxX).

Then, 8 is an extension function over Y. with respect to the type-definition:

t_terma := type [, c_expr ..... c_expr] iff the values of 8 on the type and integrity constraints are constructed starting from the values of their components as follows. Given a path = p_term 1.... .p_term n, we define the set Spath,x as follows:

S~path,x = { x } , ath,x = { Y ~ Y-[ <x,y> ~ Ilt p_term 1 ~ } Spath,x = { y ~ ~ l 3 (Yl .... Y n - 1 ) : ( x , y l ) ~ I I t P termlY, (Yl,Y2) r I-ltp_term2[ ..... (Yn-I,Y) ~ 1-Itp_te~mn[ }

if n = 0; ifn = 1; if n > 2 .

The extensions of types and an integrity constraints are computed following the structure of the syntax. Extension

of

tVDeS:

a) ~ b o d y [ b) ~ t I S A t_term...t_term body[ = (A i ~t_termi[) n ~tbody[ ~ body [ = c) ~ t t term [ e) ~t (value set) [ = {value set} n Z 0 gt[tp,..._tp][: Oj g t [ 6 j ] [ g~bt[ =

g) ~ intei~er ~ = Z n Z h) ~ r e a l ? = R n Z i) ~ b o o l e a n ~ = {true,false} n Z

1) ~ s t r i n g [ = $ m) ~ T O P ~ = Z

nZ

~ [tp] ~ = ~ [p_term:{bodY}m,M] [ = E 1 n E 2 where: E l = { X ~ 5".[ V y ~ Sn t e r m , x ~ y ~ E2={x~ X l m
~body[}

145

and ISpterm,x I represents the cardinality of the set Sp_term,x. Extension of inte~ritv constraints: ~ c_expr ~ = ~ label: c_term 1 0 c_term2 ~= I x e E [ V y e ~ c _ t e r m l [ , V z e ~ c _ t e r m 2 [ ~ yOz} ~ c_term [ = a) ~ k ~ = {k] b) 8~ this. path ~ = C) G~ttermb. path ~ P a l ~ Spath,z I z ~ ~ttermb ~, z ;~ x if t_terma = ttermb } where t_termb is any type label and t_terma is the label of the type-definition we are analyzing. []

Definition 5.2 Interpretation of a TO,/3 schema. An interpretation of a T0d2schema is a 3-tuple 3 = <~,~ ,H> where ~ represents the Application Domain, I-I is a function as defined above, and ~ is an extension function over ~ with respect to each type-definition of the schema. [] Definition 5.3 Model of a TO~ schema. A model of a T0d2schema is an interpretation 3 = <~,~ ,I-I> such that, for each typedefinition in the schema: t_term := type [, c_expr ..... c_expr] it results: ~ t_term [ = ~ type t [ n (tqj ~ {c_exprj })]. [] Given an interpretation, the mapping between type-definitions and subsets of the Application Domain is at the basis of the query processing in TO.~ [16]. Given a query, expressed as a TO,L type-definition, the solution is simply its extension, determined under the given interpretation (i.e. the current state of the database).

6 Conclusion In this work, an Object-Oriented database model, enriched by integrity constraints, has been presented. The model has been described using the language TOOL.This is a formalism conceived as data definition language and as constraint specification language. ISA hierarchies have been investigated with the aim of introducing the notions of legal ISA hierarchy and normal form reduction of a type-definition. The latter is a mechanism based on inheritance that allows the rewriting of a typedefinition with ISA by using the inherited set of typed properties. Furthermore, the expressive power of TQ6 has been analysed, using a declarative semantics. Currently, in order to have systems able to completely certify the correctness of schemas, we are analysing the problem of the satisfiability of a set of T0~ integrity constraints and, in particular, the finite satisfiability of a Tt2/~schema.

146

TO,~ is the basis of the prototype MOSAICO, an environment that supports the design and rapid prototyping of Object-Oriented database applications. MOSAICO is currently under development at IASI-CNR. The prototype has been implemented in BIM-Prolog on a Sun workstation.

References

1.

2. 3.

4. 5. 6. 7.

8. 9. 10. 11. 12. 13. 14. 15. 16.

S.Abiteboul, C.Beeri; "On the power of Languages for Manipulating Complex Objects"; International Workshop on Theory and Applications of Nested Relations and Complex Objects; Darmstadt, 1987. R.Agrawal, N.H.Gehafii; "ODE (Object Database and Environment): The Language and the Data Model"; Proc. of ACM SIGMOD 89 Conference; 1989. P. Asirelli, P. Inverardi, A. Mustaro; "Improving Integrity Constraint Checking in Deductive Databases"; Lecture Notes in Computer Science 326, 72-86, ICDT'88; 1988. S.Abiteboul, P.C.Kanellakis; "Object Identity as a Query Language Primitive"; SIGMOD '89; 1989. P.Atzeni, L.Tanca; "The LOGIDATA+ model and language"; Next Generation Information Systems Technology, LCNS 504, Springer Verlag, 1991. M.Atkinson, F.Bancilhon, D.DeWitt, K.Dittrich, D.Maier, S.Zdonik; "The Object-Oriented Database System Manifesto"; Technical Report, Altair 30-89, 1989. J.Banerjee, H.Chou, J.F.Garza, W.Kim, D.Woelk, N.Ballou; "Data Model Issues for Object-Oriented Applications"; Readings in Database Systems, M.Stonebraker (Ed.), Morgan Kaufmann Pub., 1988. F.Bancilhon; "Object-Oriented Database Systems"; 7th ACM SIGACTSIGMOD-SIGART Symp. on Principles of database Systems; 1988. C.Beeri; "A formal approach to object-oriented databases"; Data & Knowledge Engineering 5; 353-382; North-Holland, 1990. RJ.Brachman, Hj.Levesque; "The tractability of Subsumption in Frame-Based Description Languages"; Proc. of National Conference on Artificial Intelligence - AAAI 84, 34-37; Austin, 1984. E. Bertino, D. Musto; "Correctness of Semantic Integrity Checking in Database Management Systems"; Acta Informatica 26, 25-57; 1988. L.Cardelli; "A Semantics of Multiple Inheritance"; Lecture Notes in Comp. Science, No.173, Springer Verlag; 1984. J.Cohen; "Constraint Logic Programming"; Communications of the ACM; Vol.33, No.7; July 1990. S.Ceri, J.Widom; "Deriving Production Rules for Constraint Maintenance"; Proc. of the 16th VLDB Conference; Brisbane, Australia 1990. D.Fishman et al.; "Iris: an object-oriented database management system"; ACM TOIS 5(1), 46-69, 1987. A.Formica, M.Missikoff; "Materialization of recursive objects in ObjectOriented Databases"; Proc. of the Ninth International Symposium Applied Informatics; Innsbruck, 1991.

147

17. A.Formica, M.Missikoff; "Adding Integrity Constraints to Object-Oriented Database"; ISMM First InternationalConference on Information and Knowledge Management (CIKM-92), Baltimore,November 1992. 18. A.Formica, M.Missikoff, S.Vazzana; "An Object-Oriented Data Model for Artificial Intelligence Applications"; Next Generation Information Systems Technology, LNCS 504, Springer Verlag, 1991. 19. H.Gallaire et al.; "Logic and Databases: A Deductive Approach"; Computing Surveys; vo1.16, n.2; June 1984. 20. R.Gernert, N.Greif; "Modelling of Complex Objects and Semantic Integrity Constraints in Product Databases"; Informatik Informationem - Report No.2/1990; Berlin 1990. 21. N.Gehani, H.V.Jagadish, "Ode as an Active Database: Constraints and Triggers", Proc. of the 17th VLDB Conference, Barcelona, Sept. 1991. 22. R. Kowalski, F.Sadri, P.Soper; "Integrity Checking In Deductive Databases"; Proc. of the 13th VLDB Conference; 61-69, Brighton; 1987. 23. G.M.Kuper, M.Y.Vardi; "A New Approach to Database Logic"; Proc. of ACM Symposium on Principles on Database Systems, 1984. 24. C. Lassez; "Constraint Logic Programming"; BYTE, 171-176, August 1987. 25. H.Lam, M.Missikoff; "Mosaico: A Specification and Rapid Prototyping Environment for Object-Oriented Database Applications"; Technical Note December 1992. 26. C.Lecluse, P.Richard; "The 0 2 database programming language"; Proc. of VLDB '89 Conference; Amsterdam, 1989. 27. C.Lecluse, P.Richard; "Modeling Complex Structures in Object-Oriented Databases"; Proc. of ACM PODS Conference; 1989. 28. C.Lecluse, P.Richard, F.Velez; "02: an Object-Oriented Data Model"; Proc. of ACM SIGMOD Conference; Chicago, 1988. 29. G.Moerkotte, S.Karl; "Efficient Consistency Control in Deductive Databases"; Lecture Notes in Computer Science 326, 118-128, ICDT'88; 1988. 30. D.Maier, A.Otis, A.Purdy; "Development of an object-oriented dbms"; Quart. Bull. IEEE Database Engineering 8, 1985. 31. A.Motro; "Integrity = Validity + Completeness"; ACM Transactions on Database Systems, Vol.14, No.4, 480-502; December 1989. 32. M.Missikoff, S.Vazzana; "OOL: an Object Oriented Language for Knowledge Representation"; Proc. of IV International Symposium on Knowledge Engineering, Barcelona, May 1990. 33. T.Sheard, D.Stemple; "Automatic Verification of Database Transaction Safety"; Proc. of ACM TODS, Vol. 14, No.3; September 1989. 34. S.D. Urban, L.M.L. Delcambre; "Constraint Analysis: a Design Process for Specifying Operations"; Transactions on Knowledge and Data Engineering; March 1991. 35. J.D.Ullman; "Principles of Database and Knowledge-base Systems"; vol.I; Computer Science Press; 1988. 36. S.D. Urban; "ALICE: An Assertion Language for Integrity Constraint Expression"; COMPSAC Proceedings; Orlando, September 1989.

Evaluation of Negative Logic Programs * Sergio Greco, Massimo Romeo and Domenico Saccg DEIS-UNICAL, 87030 Reade, Italy

A b s t r a c t . Negative programs are logic programs where negation may arise also in the head of rules and have been recently introduced to handle exceptions to general rules. In this paper we present efficient techniques for computing the intended model of stratified negative programs.

1

Introduction

Several recent papers have addressed the problem to extend logic programming to allow negation not only in the body of the rules but also in the head in order to express exceptions to rules. For instance, suppose that the papers that are eligible to a prize are those in the April issue of the journal "JACM" plus the ones that are referred in eligible papers. This can be stated by the following program:

eligibl,(P) +-- app,ars_april_j acre(P) 9 ligibl,(P) *-- ,ligibl,(Q), r,f,r,_to(Q, P) Suppose now that someone objects and says: those papers that are corrected in the May issue cannot be considered eligible for the prize; furthermore, those papers with more than three ce[Bauthors are not eligible either. These refinements in the definition of eligible can be listed as exceptions in the following way: ~ e l i g i b l e ( P ) ~-- appears..may_jacm(Q), i s _ a _ c o r r e c t i o n ( Q , P) ~ e l i g i b l e ( P ) ~- number_of_authors(P, ~), N > 3 Exceptions are added without changing the structure of the original program. Two mainly extensions have been proposed in the literature. The first one extends standard logic programming with a new form of negation, called classical negation [6, 10]. This approach permits two different negations: negation as default (denoted by not) and classical negation (denoted by -~). Programs consist of rules where negation by default can appear only in the body while classical negation can appear only in the head. The second approach considers only one form of negation and, therefore, allows for a uniform treatment of negation. Moreover, following this approach, it is possible to recognize a large class of programs, stratified negative programs, for which the definition of the intended model is a natural extension of the notion * Work supported by the CNR project "Sistemi Informatici e Calcolo ParMlelo" subproject "Logidata+'.

149

of stratified model as given for classical program. In this paper we present an algorithm for the efficient computation of the stratified model for a negative program and a technique for extending the magic set method to restrict this computation to those elements that are relevant in answering a query. The rest of the paper is organized as follows. In sections 2 we review some basic definitions and results concerning negative programs. In section 3 we present the class of stratified negative programs and we describe an algorithm for computing their stratified models. In section 4, we present an extension of the magicset optimization technique for negative logic programs. Finally, in section 5, we present our conclusions.

2

Negative

Programs

In this section we present our language, that is logic p r o g r a m m i n g without function symbols where negation may arise not only in the body but also in the head of rules. This language is an extension of I)ATALOG-' [15, 4, 11] and will be here called "DATALOG . An atom is a formula of the language of the form p(tl, ...,tin) where p is a predicate symbol of a finite arity m _> 0 and t92 ...,tin are variables or constants (arguments of the atom). A literal is either an a t o m (positive literal ) or its negation (negative literal ). An a t o m A, and its negation (i.e., the literal --A) are said to be the complement of each other. Moreover, if/3 is a literal, then --,B denotes the complement of B. A negative rule (or, simply, a rule) is of the form: A0 *-- A1, ..., An. where A0 is a literal (head of the rule) and A1, ..., A,, is a conjunction of literals (body of the rule). If A0 is positive then the rule is a seminegalive rule; moreover, if also A1,..., Am are all positive then the rule is a positive rule (or Horn clause). A rule with empty body is a fact. Given a rule r, H ( r ) and B(r) denote respectively the head and the body of r. With a little abuse of notation and whenever no confusion arises, we shall also see B(r) as a set of literals, i.e., B(r) = {A1,..., A,~}. A rule is a fact if it has an e m p t y body and is ground if it is variable free. A term, atom, literal or rule is ground if it is variable free. A -'I)ATALOG program is a set of rules. If all rules are seminegative (resp., positive) then the program is called seminegative or a DATALOG-'p r o g r a m (resp., positive or a DATALOGprogram). Let 79 be a "DATALOG program. 79+ (resp., 79-) denotes the set of all seminegative (resp., non-seminegative) rules in 79. The Herbrand's Universe of 79 (denoted by H~,) is the set of all constants occurring in 79. The Herbrand's Base of 79 (denoted by B~,) is the set of all possible ground predicates whose predicate symbols occur in 79 and whose arguments are elements of H~,. As there are no function symbols, both H~, and B~, are finite.

150

A ground instance of a rule r in 7) is a rule obtained from r by replacing every variable X in r by ~b(X), where ~ is a mapping from the set of all variables occurring in 7) to H r . The set of all ground instances of all rules in 7) is denoted by ground(7)). Let X be a set of ground literals whose atoms are in B~, ; then -~X denotes the set {-~AIA ~ X } , X + (resp., X - ) denotes the set of all positive (resp., negative) literals in X. Moreover, X" denotes all elements of the Herbrand Base which do not occur in X, i.e., X" = {AIA E B~, and neither A nor -,A E X}. A set of literMs X is said to be consistent if there not exist a literal A E X such that --,A E X. An (partial) interpretation for 7) is any consistent subset of B~, O -~B~,. An interpretation I is total if 7 is empty. Let I be an interpretation. Given a ground literal A, we say that A is true in I (resp., false in I) if A E X (resp., -~A E I). A conjunction A1, ...,An of ground literals is true in I if each Ai is true in I, and is false in I if there exists some Ai that is false in I. If a literal (or a conjunction) is neither true nor false then it is undefined in X. An interpretation I for 7) is a (partial) model for 7) if 1. for each A in I + and for each r in ground(7)) with H(r) = -~A, B(r) is false in I, and 2. for each --A in I - , either there exists r in ground(7)) with H(r) = -~A such that B(r) is true in I or for each rule r in ground(P) with H(r) = A, B(r) is false in I. Moreover, if 7 is empty then the model I is total. The existence of a total model is not guaranteed. In other words, given a model M, a ground literal may occur in M only if there is no rule that could contradict it (possibly by assigning suitable values to undefined literals in M-). However, a negative literal can be contradicted if it is reconfirmed by an non-seminegative rule. This corresponds to say that non-seminegative rules represent a refinement of the knowledge supplied by seminegative rules, thus they are a kind of exceptions to a theory. It turns out that a rule r in P - is meaningful only if there exists al least one rule in P+ whose head predicate symbol is is equal to that of r. From now on, we assume that P only contains meaningful rules. The problem of selecting the "intended" model for a "DhTtLOG program, i.e., the model which captures the semantics of the program, has been discussed in [7] suitable extensions of founded [14] well-founded [lS] and stable model semantics [5] have been proposed. In this paper we shall only consider the intended model only for the class of stratified "DATALOG programs, that are defined in the next section. To this end, we need to extend the classical immediate consequence transformation Tp [9] to negative programs. For each interpretation I, we define

7"p(I) = { A [ r E ground(P) A U(r) = A A B(r) is true in I } { A I r E ground(P)- A U(r) = -~A A B(r) is not false in I }

151

Recall that, according to our notation, ground(P)- contains all non-seminegative rules in ground(P). If P is a DATAL0(I" program then Tp coincides with Tp. We have that T~, is monotonic in the finite lower semi-lattice < I , C_>, where 2; is the family of all interpretations of P. T h e r e f o r e the least fixpoint of T~, denoted by T~r exists and there exists a natural i, i ~ 0 such that ~ ( 0 ) -As proven in [7], T ~ ( 0 ) is a model for P but not a total model; it is indeed a rather poor model as it contains only those negative elements that can be derived from the rules and such elements are not in general sufficient to derive all possible positive elements because of negative literals in the rule bodies. Nevertheless, as shown in the next section, a particular use of Tp(0) will eventually allow to determine the intended model of stratified "DATALOG programs. 3

Stratified

Negative

Programs

Let us first extend the concept of dependency graph as given for D A T A L O G ~ programs [15]. Given a -'DATALOG program P , the dependency graph of P , denoted by Gp, is a directed graph < N , A > such that N is the set of all predicate symbols occurring in P and A is defined as follows. Given two predicate symbols p and q, there exists an arc from q to p in A if there exists a rule r in P such that (i) the head predicate symbol of r is p, and (ii) one of the literals in the body of r, say Q, has q as predicate symbol. Moreover, the arc is marked if either Q is positive and H(r) is negative or Q is negative and H(r) is positive. Given two predicate symbols p and q we say that q <_ p if there is a path from q to p in Gp; moreover, q < p if there is a path in Gp from q to p passing through at least one negative arc. P is stratified if there exists no cycle in Gp containing a marked arc.

Example 1. Consider the program ~01 and its associated dependency graph G~,I, that are shown in Figure 1. As Gpl does not contain cycles with marked arcs, then the program 7) 1 is stratified. rich(X)

~- i n h e r i t s ( X , Y ) ,

~rich(X) ~-benefactor(X). rich(john). rich(mary),

rich(Y),

rfch----n

~

~. \

benefactor

inherits

- - F i g u r e 1. Stratified Program P l - -

Consider now the program P~ and its dependency graph Gp2 , that are shown in Figure 2. As Gp2 contains a cycle with a marked arc, the program I)2 is not stratified.

152

rich(john). rich(X) +--inherits(X,Y),

] ~poor(Y).

~rich(X) ~--benefactor(X). poor(X) ~ - i n h e r i t s ( X , Y ) , - r i c h ( Y ) . poor(mary),

1

rich 9

l benefactor

~

poor

~..~

l inherits

- - F i g u r e 2. Non Stratified Program --

A stratified dependency graph of 79, denoted by (~,, is a directed graph < 15, A > such that 15 is a partition of the set of nodes of G~,, A is: {(Ni, Nj)INi, Nj E 15/~ 3k E Ni and i G Njs.t.(k, i) E G~,} and the following two conditions holds: (1) for each Ni E 15, there exist no p, q in Ni such that p < q, and (2) for each Ni, Nj E 15, if there exist p E Ni and q E Nj for which p < q, then for each iOE Ni and q G Nj, ~ , such that for each Ni, 1 < i < rn, whenever there are p, q for which q < p and p G Ni, then q is in some Nj with j < i. A topological sort < N1, N2, ..., Nm > represents a stratification of the predicate symbols in 79. Note that in general a program has several stratified dependency graphs; moreover, given a stratified dependency graph, there are several stratifications. In case of seminegative programs, the above definitions coincide with the definitions of stratified programs and stratification as given in [1].

Ezample 2. Consider the stratified program 793 that is shown in Figure 3) together with its dependency graph. p(X)

~--r(X,Y), q(Y).

~p(X) ( X, Y, V) ,) , p(Y). ~q(Y). q(X) ~ s~(rX -p(X)

+-r(X,Y).

I

P 9

l

q

"1

1

r

s

- - F i g u r e 3. Stratified Program 793 --

There are three stratified dependency graphs for 793 that are shown in Figure 4. The first graph gives the stratifications: Sx = < {r}, {s}, {p, q} > and $2 = < {s}, {r},{p,q} >. The second and third graph gives the stratification $3 = < {r}, {s,p, q} > and $4 = < {r, s}, {p, q} >, respectively. Note that the each node of the first stratified dependency graph corresponds to the set of nodes of a strong component of the dependency graph; moreover, the stratificatitions induced by this graph are the finest stratifications.

153

{p,q}

/

{r}

\

{p.q,s}

{p,q}

t{r}

t-

{s}

- - F i g u r e 4. Stratified Dependency Graphs

-

-

$3 = < {r}, {s}, {p, q} > and $4 = < {s}, {r}, {p, q} >. The topological orders $3 and $4 contain the elements corresponding to the strong components of the dependency graph. Let < N1,...,Nm > be a stratification of P and for each i, 1 < i < m, let 7)i = {rlr E 7) and the head predicate symbol of r is in Ni} and B~ = {AIA E Bp and the predicate symbol of A is in Ni}. Then we define:

M+= M~- =

it=

M~= .

~

1

7

- M +)

M t LJ J ' ~ ( M I ) M 1- U--,(B~ - i + )

6

+

Mm_ 1 I.J -p~(.rV/rn--1) M(

_I

- M,+).

M,~ is the stratified model of 7). Note that the stratified model is total and unique, thus it is independent from the stratified dependency graph and the stratification that have been chosen. In Figure 5 we present an algorithm for computing the stratified model of 7) . This algorithm first reads the program and, then, calls the procedure construct_dependency_graph that returns the dependency graph. Using the definition of dependency graph, this procedure can be easily implemented in such a way that its time complexity is linear in the size of the program. Then the algorithm calls the procedure strong_components which computes the strong components of the dependency graph. As the strong components define a partition of nodes that satisfy the conditions of a stratified dependency graph, the procedure also determines a topological sort for this partition (if any) and, then, it returns an ordered list of sets of predicate symbols, which represents a stratification of the program. If there exists no topological sort, then the procedure notifies that the program is not stratified through the boolean variable stratified. Using well-known graph algorithms, this procedure can be easily implemented in such a way that its time complexity is linear in the number of arcs and, therefore, in the size of the program. Once a stratification < C1, ..., Crn > is available, the computation of the positive literals in the stratified model is started, according to the order of the stratitification; this order coincides with order of the list C. First of all, the function sub_program returns the subprogram /5 that is obtained from P by taking all rules whose head predicate symbols are in (~. Then we compute N + = M + applying the naive method to a transformation T that is much simpler than J~. In fact T is evaluated in the following way:

T~,(X +) = {AIA = U(r), ,'E ground(75), B(r) is true in X + }

154

A l g o r i t h m Stratified.Model; Var P, #: Program;G:Graph;stratified: boolean; Q,M,N:set of Literal;

~ :set of Predicate.Symbol; C:list o] set of Predicate..Symbol; begin input(P);

construct_dependency-graph(P, G) ; strong_components(G, C, stratified); if stratified t h e n M + := $; for each C E C d o N + := P := sub_program(P, ~) Repeat

Q+ := N + ; N := T ( P , M + u Q + ) ; N + := N + - - , N until N + =

Q+;

M + := M + o N + endfor;

output('The stratified model is", M +) else

Output (" The program is not stratified") endlf

end; - - Figure 5. Algorithm Stratified_Model - -

where a positive literal B is true in X + if B E X + and a negative literal -~B is true in X + if B ~ X +. Thus T, as the classical transformation T, is independently applied to each rule, without having to check possible contradictions as it is instead required by 7~. This means that ~ can be computed in time linear on the size of the ground program. Possible negative literals that are derived by T are used to remove complementary positive literals. This subtraction can be done in O(h x !o9 h) where h is the size of the Herbrand Base. The number of iterations is obviously bound on the size of the Herbrand Base since at least a new positive literal is to be derived in every step. It turns out that the overall time complexity of the algorithm is O(h x loeh x l) where ! is the size of the ground program 9 . The algorithm can be improved by using hash indices for the subrtaction replacing the naive method with the semi-naive one in the computation of the fixpoint of T [16]; however, the application of the semi-naive method needs some attention for taking care of subtraction and, for the sake of brevity, it is not reported here. For the sake of the presentation, the actual implementation of the various procedures used in the algorithm are not described either. Note that the algorithm makes use of suitable data structures such as Literal, (i.e., a predicate symbol followed by a list of bound arguments), Program (i.e., a set o f lists of literals, where each list represents a rule), and Graph (i.e., the nodes are predicate symbols and the arcs are represented by adjacency lists).

155

4

Query

Answers

The algorithm of Figure 4 computes the whole set of the positive literals in the stratified model. This computation becomes exuberant in the case of answering queries, where only a subset of the stratified model is required. In the case of seminegative programs, this drawback is removed by using program rewriting techniques such as magic sets [2, 3], counting [2, 12, 3], magic counting [13] and others [16]. We claim that rewriting techniques can be also applied to stratified "DATALOG programs using simple adjustments for passing the binding on rules with negative heads. We next show how this can be done for the case of the magic set method, that is assumed to be familiar to the reader. Let 79 be a stratified "DAThL06 program, M + be the set of the positive literals in the stratified model of P, and Q be a positive literal (query). The answer of the query Q, denoted by AO, is the set of all elements in M + which unify with Q. We compute A O as follows: 1. Find the strong components of the dependency graph of 79; 2. Construct the program 75 by taking each seminegative rule in 79 without any modification and by replacing each other rule r into § as follows: H(~) = --,H(r) and for each B in B(r), "-,B is in B(f) if the predicate symbols of B and H(r) belong to the same strong components or B is in B(f) otherwise; 3. Rewrite the program 75 for the query Q by applying the magic set method; let Magic(790) and Modified(75) be the sets of magic rules and of modified rules in the rewritten program, respectively; 4. Construct the program Modified(79Q) by taking the rules in Modified(75) derived from seminegative rules of 79 and by modifying each other rule r as follows: the head H(r) is replaced by --,H(r) and each body atom B which is mutually recursive with H(r) with -,B; (this corrresponds to do the reverse substitution of step 2); 5. If the program 790 = Magic(79o)UM~ is stratified then use the algorithm of Figure 4 for computing the stratified model M+Q and A O consists of all literals in M+Q which unify with Q.

Example3. Consider the followin~l program 79 with the query Q = p(1,Y) : p(X,Y) +-- a(X,Y). p(X,Y) +-- a(X,Z), p(Z,Y). ~p(X,Y) +-- q(X,Y). q(X,Y) +-- B(X,Y). q(X,Y) +-- b(X,Z), q(Z,Y).

I

p,

q

The dependency graph G~, pictured above does not contain cycles with marked arcs and then 79 is stratified. In order to generate the rewritten program we first replace the non-seminegative rule -,p(X,Y)~--q(X, u with the seminegative rule p(X, Y),---q(X, Y) (step 2) and then we apply the standard magic-set method to the program (step 3). The magic-set method generates among other the modified

156

rule p(X, Y) ~- magic..p(X), q(X, Y) that is derived from the non-seminegative rule. Then we replace this rule with the modified rule --,p(X, Y),--,*agie..p(X), q(X, Y) (step 4). The rewritten program 79c,~is still stratified and is as follows:

magic..p(a) -magic..p(Z) ',-- magic..p(X), a(X, Z).

q(X, Y) ~-- magic_q(X), b(X, Y). q(X, Y) ~- .agir b(X, Z), q(Z, V).

.agio_qCX) -.agic.pCX)

I

I l

magic-q(Z) +-- magic_q(X), b(X, Z).

p(x,,) ~-

-asir

~p(X, Y) *---

magic..p(X), q(X, Y).

q

a(x, Y).

l

I "?"-"'7

0

As shown in the next example, it may happen that the program 790 is not stratified. Example,~. Consider the following program P with the query p(1,Y):

p(X,Y) ~-- a(X,Y). p(X,Y) +-- p(X,Z), p(Z,Y). ~p(X,Y) *-- q(X,Y). q(X,Y) ~-- b(X,Y). q(X,Y) ~-- q(X,Z), q(Z,Y).

~ --

q

The rewritten program "190 and its dependency graph are given below. The dependency graph is not stratified because there is a cycle with a marked arc, then the rewritten program 790 is not stratified.

magic-p(1) magic..p(Z) +- magic-p(X), p(X, Z).

q(X, Y) ~ magic..q(X), b(X, Y). q(X, Y) ~- ~,~gi~_q(x), q(x, z), q(z, v).

magic_q(Z) +---magic.q(X),

q(x,z).

p(X, Y) ~-p(X, Y) +-~p(X, Y) '--

~(x,Y). p(x,z), p(z,v). q(x,Y).

0

magic-p(X), magic-p(X), magic-p(X),

P'

q

II II

157

If the program 79Q happens not to be stratified, the only possibility to answer the query is to compute the whole stratified model by applying the algorithm of Figure 4 to :P rather than to PQ. However, the binding propagation of T~Q can be exploited also in the case PQ is not stratified by using the technique described in [8].

5

Conclusion

"DATALOG programs are function-free logic programs where negation m a y arise also in the head of rules and allow to single out exceptions to a theory without having to overload general rules with refinements for special cases. In this paper we have presented efficient techniques for computing the intended model of a stratified "DATALOG program or the part of it that is relevant to answer a query. These techniques do not require to transform a -'DATALOG p r o g r a m into an equivalent logic program without negated rule heads (serninegative version) as they are directly applied to the original program. This is very i m p o r t a n t since the seminegative version of a stratified -~DATALOG program m a y loose stratification so that finding the intended model becomes much more complex.

References 1. K. Apt, H. Blair, A. Walker, Towards a Theory of Declarative Knowledge, In Foundations of Deductive Databases and Logic Programming, Minker, J. (ed.), Morgan Kaufman, Los Altos, pages 88-148, 1988. 2. F. Bancilhon, D. Mayer, Y. Sagiv, and J.F. Ullman. Magic sets and other strange ways to implement logic programs. In Proceedings of the Fifth ACM Symposyum on Principles of Database Systems, pages 1-15, 1986. 3. C. Beeri and R. Ramakrisnhan. On the power of magic. In Journal of Logic Programming, 10 (3 & 4), pages 255-299, 1991. 4. S. Ceri, G. Gottlob, L. Tanca, Logic Programming and Databases, Springer-Verlag, 1990. 5. M. Gelfond and V. Lifschitz. The stable model semantics of logic programming. In Proceedings of the Fifth Intern. Conference on Logic Programming, pages 10701080, 1990. 6. M. Gelfond, V. Lifschhitz, Logic Programs with Classical Negation, In Proe. of the Seventh Int. Conf. Logic Programming, pages. 579-597, 1990. 7. S. Greco, D. Sacck, Negative Logic Programs, In Proc. of the North American. Conf. on Logic Programming, pages 480-497, 1990. 8. S. Greco, D. Sacck, Magic Set Transformation for Negative Logic Programs, Technical Report, 1992. 9. J.W. Lloyd, Foundations o/Logic Programming, Springer Verlag, Berlin, 1987. 10. R.A. Kowalski, F. Sadri, Logic Programming with Exeptions, In Proc. of the Seventh Int. Conf. Logic Programming, pages 598-616, 1990. 11. N. Leone, M. Romeo, P. Rullo, D. Sacck, Effective Implementation of negation in Database Logic Query Languages, In this volume. 12. D. Sacch and C. Zaniolo, The generalized counting method of recursive logic queries for databases. In Theoretical Computer Science, No. 62, pages 187-220, 1989.

158

13. D. Sacc~ and C. Zaniolo, Magic-counting methods. In Proceedings o] the 1987ACM SIGMOD Int. Conf. on Management o] Data, pages 149-59, 1987. 14. D. Sacc~t, C. Zaniolo, Stable models and Non-determinism for logic programs with negation, In Proc. A CM SIGMOD-SIGACT Syrup. on Principles o] Database Systems, pages 205-217, 1990. 15. J.D. Ullman, Principles o] Database and Knowledge-Base Systems, Vol. 1, Computer Science Press, Rockville, Md., 1988. 16. J.D. Ullman, Principles o.f Database and Knowledge-Base Systems, Vol. 2, Computer Science Press, Rockville, Md., 1989. 17. A. Van Gelder, Negation as Failure Using Tight Derivations for Logic Programs, in Foundations of Deductive Databases and Logic Programming, Minker, J. (ed.), Morgan Kaufman, Los Altos, pages 88-148, 1988. 18. A. Van Gelder, K.A. Ross, and J.S. Schlipf. The well-founded semantics for generM logic programs. In Journal o] ACM, Vol. 38, No. 3, pages 149-176, 1991.

Effective Implementation of Negation in Database Logic Query Languages * Nicola Leone 1 , Massimo Romeo 2, Pasquale Rullo 3 and Domenico Sacc~ 1 1 DEIS-UNICAL, 87030 Rende, Italy 2 ISI-CNR, 87030 Rende, Italy 3 Dip. di Matem~tica-UNICAL, 87030 Rende, Italy

A b s t r a c t . Total stable models provide a powerful semantics for D A T A L O ~ ~ programs which increases the expressive power of current database query l~nguage by means of non-determinism. An efficient algorithm for determining one of stable models of a DATAL0(I"programs, if any, is presented

so that stable models may have also a practical interest.

1

Introduction

is a logic programming language with negation in the rule bodies but without functions symbols. It is used as a database query language that, because of recursion, has an expressive power greater than relational algebra. The semantics of a DATALOG-~ program without negation is rather simple: the meaning of the program, i.e., the intended model, is given by the m i n i m u m model, that is the intersection of all total models. As soon as there are negative goals in some rule, the selection of the "intended" model becomes more complex and is a key issue of the current research. Total stable models have been recently proposed as the semantics for logic programs with negation and, then, also for DATAL06-~ programs. However, the existence of multiple stable models for the same program (or, on the other side, the lack of total stable) has caused some conceptual difficulties to researchers as the canonical meaning of a logic program is traditionally based on a unique model. Our claim is that this anomaly of total stable models is not a drawback but provides the ground for adding non-determinism to logic programming. Total stable models are also criticized because of the lack of an efficient procedure for their computation. In fact computing a stable model for DATALOG" programs is NP-hard. Also for this aspect, our claim that this is not a drawback as long as DATALOG" programs are able to formulate NP-hard problems; indeed, it must be required that finding a stable model be polinomyal only if the p r o g r a m formulates a polynomial problem. In this paper we present an effective algorithm for computing a stable model of a DATALOG" program. This algorithm is based on a backtracking search strategy and on some new interesting characterizations of stable models. DATALOG"

* Work partially supported by the CNR project "Sistemi Informatici e Calcolo Parallelo', subproject "LOGIDATA+".

160

The paper is organized as follows. In section 2 we give the preliminary definitions and basic notation and we present the theoretical results for characterizing stable models in Section 3. Finally we describe the algorithm in Section 4.

2

DATALOG

with

Negation

Let us first review the basic concepts and notation of the database logic query language DATILOGwith negation (or simply DATALOG") [16], that is Horn clauses plus negated goals in rules but without function symbols [7]. An atom is a formula of the language of the form p(tl, ..., tin) where p is a predicate symbol of a finite arity m > 0 and tl, ..., tm are variables or constants (arguments of the atom). A literal is either an atom (positive literal ) or its negation (negative literal ). An atom A, and its negation (i.e., the literal -~A) are said to be the complement of each other. Moreover, if B is a literal, then -,B denotes the complement of B. A rule is a formula of the language of the form A ~ A1,...,An. where A is an atom (head of the rule) and A1,...,An is a (possibly, empty) conjunction of literals (body of the rule). Given a rule r, we shall denote the head of the rule by H ( r ) and the body by B(r), i.e., H ( r ) = A and B(r) = A1,..., An. With a little abuse of notation and whenever no confusion arises, we shall also see B(r) as a set of literals, i.e., B(r) = {A~, ...,An}. A rule with empty body is called a fact. A rule without negative literals in the body is positive, i.e., it is a Horn clause. A term, atom, literal or rule is ground if it is variable free. A DATALOG-' program is a finite set of rules. A DATALOG" program is positive if all its rules are positive; in this case it is also called a DITALOG program. Let a DATALOG"program 79 be given. The Herbrand universe for 79, denoted H~, is the set of all constants occurring in 79. If there is no constant in the program then one is added arbitrarily. The Herbrand Base of 79, denoted BT~, is the set of all possible ground atoms that can be constructed using the constants in HT, and the predicate symbols occurring in 79. Note that both H~, and B~, are finite. A ground instance of a rule r in 79 is a rule obtained from r by replacing every variable X in r by r where r is a mapping from all variables occurring in r to H~,. The set of all ground instances of all rules in 79 is denoted by ground(79). Let X be a set of ground literals whose atoms are in B~,; then -,X denotes the set {-~AIA E X}, X + (resp., X - ) denotes the set of all positive (resp., negative) literals in X. Moreover, X denotes all elements of the Herbrand Base which do not occur in X, i.e., -X = {AIA E B~, and neither A nor -,A E X}. Given a ground literal A, we say that A is true in X (resp., false in X) if A E X (resp., -,A E X). A conjunction A1,..., A , of ground literals is true in X if each Ai is true in X, and is false in X if there exists some A / t h a t is false in X. Note that

161

a literal (or a conjunction) can be both true and false in X or, even, neither true nor false; in the latter case, it is undefined in X. Given X C_ B~,U~BT~ and Y C_ B~,, Y is an unfounded set w.r.t. X if for each rule r in ground(7)) with H ( r ) E Y, B(r) is false in X or B(r) A Y # 0 [18, 19]. The union of all unfounded sets w.r.t. X, is also an unfounded set w.r.t. X , is called the Greatest Unfounded Set, and is denoted by GUS~,(X). As pointed out in [18, 19], GUS~, is a monotonic transformation from 2 B ~ u ' ~ to 2 B ' . Let us now introduce another important transformation from 2 BT'~ to 2 BT', called the immediate consequence transformation and denoted by T~,[7]. This transformation is defined as follows: for each X C B~, O --B~,, T~,(X) = {AIA = H ( r ) , r E ground(7)) and B(r) is true in X}. Observe that T~, is monotone in a finite complete lattice and, then, the least fixpoint of T~,, denoted by T~~ exists and coincides with T~(0), for some natural k, where T~(0) = 0, and for each i > O, T~(O) = T~,(T~-I(O)) [15]. Let us now introduce the important notions of interpretation and model in the domain of partial interpretations. Given I C_ Bp U -~Bp, I is a (partial) interpretation of 7) if it is consistent, i.e., I + A - - I - : 0 so that a ground literal cannot be, at the same time, true and false in [. Moreover, if 7 = 0, the interpretation I is called total and, in this case, any ground literal will be either true or false in I. As far as the notion of model is concerned, we first recall the classical definition of model for total interpretations: a total interpretation M of 7) is a total modelofT) if for each r in ground(P), (1) H(r) is true in M or (2) B ( r ) is false in M. As shown in [14], such models have the following characterization: a total interpretation M is a total modelifand only i f - - , M - is an unfounded set w . r . t . M . We point out that there are several alternative views on how this definition model is to be extended to the domain of partial interpretations [4, 11, 13, 14, 18, 19]. Following [13, 14], we shall say that an interpretation M of 7) is a (partial) model ofT) if for each r in ground(7)), (1) H(r) is not false in M (thus it is true or undefined), or (2) B ( r ) is false in M. Note that, in case M is a total interpretation then the above condition (1) reduces to H(r) is true in M. Thus, this definition of model is a rather natural extension of the definition of total model. This is confirmed by the fact that models preserve the same characterization in terms of unfounded sets as total models: an interpretation M is a model if and only if --,M- is an unfounded set w . r . t . M . A DATALOG" program 7) has in general several models but only one of them, the so-called "intended" model, represents the natural meaning of it. It is wellknown that if 7) is positive then the intended model is the total model M7 whose set of positive literals M + coincides with T ~ (0), thus M + contains all literals that can be inferred from the rules of the program. Note that MT is also the m i n i m u m model of 7), i.e., for each total model M of 7) M + C_ M +. On the other hand, in case 7) is not positive, MT is not any-more guaranteed to be a model as M T = --,(B~, - T ~ (0)) is not necessarily an unfounded set. Therefore, the issue of what model to base the semantics of a DATAL0(]-" program becomes much more complex and alternative definitions of the intended model have been

162

made in the literature, e.g., negation by failure [3], stratified model [1, 2, 9, 17], locally-stratified model [10], well-founded model [18, 19], total stable models [6], and various extensions of stable model in the domain of partial interpretations [12, 13, 14]. As discussed in the next section, we shall take the total stable model as the intended model of a DATALOG"~ program. 3

Total

Stable

Models

A first common requirement of the various proposals of semantics for nonpositive programs is justifiability[20], i.e., the positive literals of the intended model must be inferred from the rules of the program through the immediate consequence transformation as for positive programs, but possibly using negative literals as additional axioms for the inferences. This requirement is found under several names in the work of several authors (e.g., the notion justifiability used in [20] is similar to that of 'stability' [6] or that of 'founded models' [13]), and can be formalized by the following condition: D e f i n i t i o n 1. Given a model M of T~, the stability condition holds for M if there

exists X C_ M - such that S~,x($ ) = M +, where the transformation ST,,x : 2 n'u-'B" ---* 2 n" is defined as follows: for each Y C_ B~ U ",BT,, ST,,x(Y) = T~ ( X U Y). Thus the negative literals in X are used to infer the positive literals in M +. Obviously if such an X exists then we can use also M - instead of X for such inferences; so we could have used directly M - in Definition 1. The reason we have stressed that the whole M - is not necessary in the definition will become clear later in the paper when we shall use a suitable subset of M - to compute a justified model. A second requirementi s minimal undefinedeness, i.e., the intended model M may not retain literals in M that could be otherwise included in M + or M - . This requirement can be implemented in different ways, each of them resulting in an alternative definition of intended model. The strictest implementation requires that M be empty, thus M is a total model; this requirement together with the one of Definition 1 provides the following definition of total stable model that is equivalent to the original definition given in [6]: D e f i n i t i o n 2 . A model M of'P is a (total) stable model of 1) if both M is total

and the stability condition holds for M . In this paper we shall assume that the intended model of a DATALOG-"program be a total stable model that, from now on, we shall call stable model for short. We point out that a DATALI36"program could have several alternative stable models or even none. Therefore, as uniqueness and existence have been a basic requirement for any classical definition of intended models, it would seem that our choice for intended models has a serious drawback. Instead our claim is that the lack of the two above properties is an actual advantage as it increases the

163

expressive power of DhTALOG"~. Indeed, the existence of several intended models entails for the implementation of a powerful non-deterministic choice mechanism as demonstrated by the following two examples taken from [14]. On the other hand, the lack of stable models means that the problem has no solution (see Example 2). Example 1. The following program states that glasses must be colored with one of the available colors but two glasses cannot share the same color. Colors and glasses are defined by a number of facts. colored(G, C) ~-- color(C), glass(G),-,diffChoice(C, G). di f fChoice(C, G) +-- colored(C, 1~), G r G. d i f f C h o i c e ( C , G) +-- colored(C, G), C r C. Note that the non-determinism is here used to perform a "don't care" choice. This program admits at least one stable model, thus the problem has a solution no matter is the base of facts for colors and glasses. In particular, if the number of available colors is less than the number of glasses then some glass will have assigned no color. ! Example 2, Consider the following program that computes a kernel of a directed graph whose nodes and edges are defined by a number of facts with predicate symbol n and e, respectively. A kernel is a subset of nodes such that no two nodes in the kernel are joined by an edge whereas every node that is not in the kernel is joined to some node of the kernel. Finding a kernel of a graph is an NP-complete problem [5].

a(x) joined_to_iV(X) disconnectedY_f rom~ conneded_N kernel kernel

.(x),-,n(x). ,+- e(Y, X), fi(Y). ,--- ~( X ) , - , j o i n e d J o . ~ (X ) . ,-- h( X ), joined_to_N ( X ). ~ --,disconnected.T_from_N , --,connected_IV. ~-- --,kernel.

The first two rules realize a partition of the nodes into two classes 2V and -N. In a stable model of the program the former class 2V will represent the kernel, while the latter will collect all nodes outside the kernel. If M is a stable model of the program then kernel is in M+ ; in fact, because of the last rule, --,kernel cannot be in M, as the falsity of kernel would falsify the rule kernel <-----,kernel. (the body would be true while the head w.ould be false). Hence kernel is in M +, but, since stable model are justified, then kernel has been derived from the previous rule; so both -',disconnected3_from..N and --,connected.f[ are in M - . Hence, the set of nodes Ig determined by M is a kernel. On the other side, if the graph has no kernel, then kernel remains undefined and the program has no stable models. Thus the number of stable models coincides with the number of distinct kernels in the graph. The program describes the kernel problem using

164

a direct non-deterministic formulation: the last rule forces to select among all possible partitions the one which satisfies the kernel conditions. The goal of this paper is to present an efficient algorithm for computing one of the stable models of a given DATALOG"program or reporting that the program admits no stable models. To this end, we use the following characterization of stable model [19]: F a c t 1 A total interpretation M of a given DATALOG" program 79 is a stable model of 79 if and only if M is a fixpoint of the transformation W r : 2 B ~ ' v ' B ~ - > 2 B~v'B~ defined as follows: for each X C Bp U ~ B p , W p ( X ) = TT~(X) U

n Note that, as Wp is a monotonic transformation in a complete finite lattice, there exists a natural k _> 0 such that W ~ ( 0 ) = W~(0). Thus W ~ ( 0 ) i s the least fixpoint of W~, and is called the well-founded model of P [18, 19]. The following property holds. F a c t 2 The well-founded model of a DATALOG" program 7) is a model of 79 and is contained in any stable model of 7~. O We point out that, as a stable model is total, it is sufficient to return just the positive literals of it. Therefore, negative literals need not be computed unless they are necessary to perform inferences of positive literals. This means that, in order to efficiently compute a stable model, the transformation W~, should be modified by replacing the (3US with a subset of it containing only those literals in the (:;US whose falsity is useful to draw positive conclusions. This subset is called the Greatest Useful Unfounded Set ((3UUS).

Example 3. Consider the program ae-b. C 4--- -'~d~

and let M - 0. It is easy to see that GUS(M) - {a,b,d}. However, only the element d is useful for positive derivations; so GUUS(M) : {d}. We next give a formal definition of the GUUS. To this end, we first need to introduce the important notion of Possibly Unfounded Conjunction. D e f i n i t i o n 3. Let 7) be a DATALOG" program and X C_ B~ U'~B~,. A non-empty subset Y o f ' X is a possibly unfounded conjunction w.r.t. X if there exists a rule r in ground(P) such that:

1. 2. 3. ~.

H(r) qL X +, and ~ Y C B(r), and all positive iiterals in B(r) are true in X , and no negative literal in B(r) is false in X .

165

The set of all possibly unfounded conjuctions w.r.t. X is denoted by PUCST~(X). Moreover, given Z C_ B~,, the restriction of PUCS~(X) to Z, denoted by I:UCS~,(X/Z), is PUCS~(X/Z) = {CIC ~ PgCS~(X) ^ C C Z}.

0 Example 4. Consider the program a~--b. c 4--- -~d. e *-- -~e,-~b. and let M = O. It is easy to see that t ~ C S p , M ( M ) -" {{d},{b,e}}. Note that, given Y = {b, d}, PUCS~,.M(M/Y) = {{d}} since the possibly unfounded conjunction {b, e} is not contained in Y. We are now ready to give the definition of GUUS. D e f i n i t i o n 4 . Let a D A T A L O G ~ program 79 and X C Bp U -~BT~ be given. The Greatest Useful Unfounded Set of 79 w.r.t. X is

6vus (x) :

U

(c).

ce ~ c s ~ (x/c~s~ (x))

Example 5. Consider the program of Example 4. For M = 0, we have that GUST~(M) = {a, b, d}. Since the only possibly unfounded conjunction that is contained in {a, b, d} is {d}, GUUST~(M) = {d}. We next show that the well-founded model can be determined by replacing the (3US with the GUUS in the transformation W~,. D e f i n i t i o n 5. Given a DATALOG~ program 79, the transformation VT~ is defined

as follows: for each X C_ B~, tO -,BT~

v~,(x)

= T ~ ( x ) u ~ a ~ ; s ~ ( T ~ (x) u x - ) u x -

The transformation V~, is not monotone. Nevertheless, the sequence V~(O), i > O, V~(O) = V~,(V~-I(O)), is a monotonic sequence of models. Hence, the fixpoint V~~ exists and, as the Herbrand base is finite, there is a natural i such that V ~ ( 0 ) = Vr Now we are in a position to state a fundamental result that has been proven in [8]. F a c t 3 Let 79 be a DATALOG" program and Mwl be the well-founded model of 79. Then, M = V~(O) is a model of 79, M + = MgI,+ and M U -,GUS~,(M) =

M~I.

O

166 From the above fact, it follows that the positive literals of the well-founded model can be found using the transformation V~,. Note that if the well-founded model is total then it is also stable; therefore, in this case, no further computation is needed. Recognizing whether the well-founded is total or not can be easily done using the following result of [8]. F a c t 4 Let 7" be a DATAL0fl" program and M = V~~ Then the wellfounded model ofT" is total (i.e., it is a stable model) if and only if PUCS~,(M) =

!

O. Example 6. Let us compute the stable model for the following program c

~-.. --le.

a~-.-c. b+--~a.

d,.-b. e+...-f,

As V~,(O) = O, we have T ~ ( V # ( O ) ) = 0, PUCS~,(O) = { { a } , {e}}, GUS-p(O) = {e, f } and, then, GUUS~,(O) = {e}; so V~,(O) = V~(V#(O)) = {--,e}. NowT~(V~,(O)) = {a, c} and ~ V S ~ ( { a , c,-,e}) = 0 as m C S ~ ( { ~ , e,-,e}) = O; so V#(O) = V~,(V~(~)) = {a, e,-,e}. As V#(O) = V~,(V~>(O)) = {a, c, ~e} = V~>(O), V~>(O) is the fixpoint of V~,. Therefore, {a,c} is the set of positive literals in the well-founded model Mw! of 7'. Since PUCS~,(V~,(O)) = 0, the well-founded model is total, thus {--,b,-~d-,e,--,f} = M~, 1 . If the test of Fact 4 fails, we have to perform further computation to deter, mine a stable model. To this end, we have to move beyond the fixpoint V ~ ( 0 ) . Let us show how this can be done using first an example.

Example 7. Consider the following program: |

a ~ - -nO, "aC. C *--- "na.

b *--- -~a. a~--c.

We can easily see that O is the well.founded model Mtoi that is obviously partial and coincides with V~~ We have that PUCS~,(Mwl) = {{a}, {b, c}}. Now, in order to move beyond the well-founded model M~ol , we assume the falsity of all literals in one of the elements of PUCS~,( Mw l ) to draw new inferences. For instance, if we add both ",b and --% we get that a is true, i.e., we obtain M = {a, c, -~b}, that is a stable model (Note that selecting b or e alone is not sufficient to draw new inferences.) On the contrary, adding -~a leads to a contradiction, as a will be then derived. O We now formalize the above intuition by introducing an extension of V~,.

167

D e f i n i t i o n 6 . Let P be a DhTALOG~ program and C be a choice function, i.e., a function which selects an arbitrary element from a set. Then the transformation Vp,c : 2BT"u'B~ ---+2 BT"u'B~ is defined as follows: for each X C BT~ U "-,B~,, V~,e(X) = f V~(X) ifV~(X) # X [ x o { - ~ c ( P u c s ~ , ( x ) ) } otherwise

D There are as many transformations V~',c as the number of different functions C. Furthermore, for any choice function C, the sequence Vr i > 0, is a monotonic increasing sequence of subsets of B~, U -~B~, and the least fixpoint of it, denoted by r ~ , c ( 0 ) , coincides with some element of the sequence. The following result holds. F a c t 5 Let P be a D A T A L O G program. Then 1. for each choice function C, V~(O) C_ (/~,c(O), 2. if for some choice function C, M = (/~,c(0) is an interpretation of 79 and PUCS.p(M) = 0, then M is a model of 79, and M U--,M is a stable model of 79; 3. if N is a stable model of 79 then there exists a choice function C such that N = M U-~'ff, where M = 9~,c(0 ).

D Facts 3, 4 and 5 provide the ground for constructing an efficient algorithm for computing a total stable model. This algorithm is described in the next section.

4

Computing the Total Stable Model

A l g o r i t h m Stable_Model; var M : Literals; P : Program; stable : Boolean begin i n p u t (P); Compute_V ~176 (P, M); Compute_V ~ ( P, stable, M); if stable t h e n o u t p u t ("A stable model of :P', M +) else o u t p u t ("no stable model for P") endlf end Stable_Model. Fig. 1. Algorithm Stable_Model

168

In this section we present an algorithm for computing a stable model that is based on the results of the previous section. This algorithm, described in Figure 1, takes a DATALOG"~program P in input and first fires the function Compute_Voo which computes the fixpoint V ~ (0). Then, it calls the procedure Compute_Voo which searchs for a choice function C satisfying the conditions of Part (2) of Fact 5. In case of a successful search, the procedure Compute_Voo notifies that a choice function C has been found by assigning the value true to the boolean variable stable and returns M = r~.c(0); the algorithm then outputs M + which coincides with the set of positive literals of a total stable model. (Because of totality, there is no need to output negative literals.) On the other hand, a possible search failure is indicated by the value false for the variable stable; in this case, the algorithm reports that the program admits no total stable models. Finally, observe that Program and Literals are data types for storing sets of rules and of ground literals, respectively.

P r o c e d u r e Compute_Vcc(P : Program; var M : Literals); var 57/: Literals; begin M := ~; repeat

~1 := T~176 M-; M := .~f U -~(7~]US(P,,~I) until M = / f / end Compute_Vet; Fig. 2. Procedure Compute_V ~162

The procedure Compute_Voo is shown in Figure 2 and performs the computation of V~'(@) using a simple iteration scheme. Note that the procedure makes use of two functions: T ~ and GUUS. The function T ~ simply computes the fixpoint T ~ ( M ) ; for instance, it can make use of relational algebra and of an additional fixpoint operator [16]. For the sake of presentation, we assume that Too is a built-in function. The function GUUS computes tim GUUS and will be described later in this section. Note that, by Fact 3, the procedure Compute_Voo computes the set of all positive literals of the well-founded model. After computing M = V~~ the procedure Compute_f z~ of Figure 3 is called. This procedure tests whether PUCST,(M) = @. If this test succeeds, then M + is the set of positive literals of a total stable model by Fact 4 and, therefore, the procedure returns the value true for the variable stable as the well-founded model is also stable. Otherwise, by Part (2) of Fact 5, the procedure has to find a choice function C such that M is an interpretation of T' and PUCSv(M) = 0, where M = fz~,c(@). The procedure is essentially based on a backtracking strategy (from which the name Backtracking Fixpoint [13]). To this end, the function make_list stores the elements of PUCSv(M) into a list L of possibly unfounded

169

Compute_f'~ : Program; var stable : BOOLEAN; v a r M : Literals); v a r N, M : Interpretation; L : List of Literals; Y : Literals; begin if PUCS(P, M) = ~ t h e n stable := true Procedure

else

stable := false; L := make_list(P, trdCS(P, M)); N := M; while not stable a n d (L ~ ~) do Y := pop(L); (* pop the first possibly unfounded conjunction from L *) M := N U -~Y; r e p e a t (* compute the next fixpoint of Vv *) ~I := TCc(P,M) U M-; M := h;/U -~GUUS(P, l~l) until (M = J~/) or (M N ~M ~ 0); if M A-.M = 0 t h e n (* M is an interpretation *) Cornpute_l/'~ (P, stable, M) endif endwhile endif e n d Compute_f/~ ; Fig. 3. Procedure Compute_V ~

conjunctions, that is ordered by according to any predefined ordering of the Herbrand Base. We construct the choice function by taking the first element of L; M is stored into N in order to possibly backtrack to the next element. Then we move to a new fixpoint M of V~,. Of course as soon as we realize that M becomes non-consistent (i.e., it is not an interpretation) we try with the next possibly unfounded conjunction of the list. If the are no other elements left in the list, the procedure stops returning the value false for the variable stable. In case no contradiction arises then the procedure Cornpute_V ~ is recursively called to test whether PUCSp(M) is e m p t y for the fixpoint M of V~. It the test succeeds then M + is the set of positive literals of a stable model by Part (2) of Fact 5 and, therefore, the procedure returns the value true for the variable stable as a total stable model has been found. Otherwise, we move to a next fixpoint of V~,. In sum, if a choice function C satisfying the condition of Part (2) of Fact 5 exists, it will be eventually found by the backtracking search strategy. On the other side, if such a function does not exists, the program has no stable model by Part (3) of Fact 5; so the procedure correctly reports this situation by returning the value false for the variable stable. Note that the procedure makes use of the functions PUCS and (:~US, that will be defined later in the next section, and of the simple functions make_list and pop that can be thought of as a built-in functions.

170

Example 8. Consider the following program: a+--b. c~--~a.

d +---c, ~e, ~ f . e *--~d.

f *-- - d . g +---e,-,g. The procedure of Figure 1 works as follows. First, the procedure Compute_V ~176 returns M = {c, ~a}; then the procedure Compute_~/~ is invoked for the first time. Since PUCST~(M) ~ 0, stable is set to false and, by selecting the alphabetic order, L 1 is set to < { d } , { e , f } >; moreover, N 1 -- M - {c,-~a}. (We use a superscript for identify local variables of different instances of the proce. dure Compute_~/~.) Then {d} is taken from L 1 so that L 1 becomes < {e, f } > and M = {c, e, f , - a , ",d} is computed. Since M is an interpretation, the procedure Compute_f/~ is invoked for the second time. Since again t~CS~,(M) 0, the list L 2 = < {g} > is created; so, by taking the first element, M be. comes {c, e, f, g, -,a,',d, - g } and, then, is not consistent. So the next possibly unfounded conjunction of L 2 is to be considered. But L 2 is empty; so the procedure stops and the first instance of the procedure Cornpute_~/~ is resumed. Since stable is false, the possibly unfounded conjunction {e, f } is taken from L 1 and M = {c, d, ~a,'-,e, ",f} is obtained. Since M is an interpretation, the procedure Cornpute_V ~ is invoked again. This time FUCS~,(M) = 0; so stable is set to true and the procedure stops. The first instance of the procedure Compute_f/~ resumes and, as stable is true, it stops so that the main program can take over and it outputs M + = {c, d}. A stable model is indeed {c, d, ",a, "~b, ",e, - f , ~g}. Let us finally show how the functions for computing the PUGS and the GUUS can be implemented. Definition 3 can be immediately used to devise a simple algorithm for computing the / ~ C S . We present this algorithm as a function (see Figure 4) that makes use of the special predicate symbol not that is evaluated as follows: given X C B~, U-,B~, and a ground literal A, not(A) is true in M if A is not in M, otherwise it is false. The function constructs a program/~ by taking all the rules of P with negative literals in the body and restructuring them so that the above negative literals are moved to the rule heads. The head of a rule is actually a conjunction; if the body is true in M (i.e., all positive literals are true, no negative literal is false and the head is undefined) then the whole conjunction is derived by applying the immediate consequence transformation. Possible non-undefined literals in the conjunction are removed in the next iteration. Example 9. Consider a program having { a, b, c, d} as Herbrand Universe and containing the following rule:

p(X)

171

F u n c t i o n PUCS(P : Program; M : Literals) : Set o] Literals; vat PUCS1, PUCS2 : Set o] Literals;C : Literals; P : Program; begin

P := 0; for e a c h r E P s.t.

B(r)- # 0 d o

(* let B ( r ) - = -~A1, ...,--A, *) P := Pt.J {-~B(r)- ~-- B(r) +, not(-~B(r)-), not(H(r)), not(-~H(r)).} endfor PUCS~ := T(P, m); PUCS2 := 0; for e a c h C E PUCS1 d o C := C - "-M-; if C # 0 t h e n PUC9~ := PUCS2 u {C} endlf; endfor; return ~ C S 2 end PUCS;

Fig. 4. Function PUGS

This rule in transformed by the function PUCS of Figure 4 into the following rule: {s(X), u ( X ) } ~-- q(X), not(s(X)), not(u(X)), not(p(X)), not(-~p(X)).

Let M = {q(a), q(b), q(c),-,s(b), ~u(a), ~u(b), p(c),--p(d)}. By applying the transformation T to the above rule, we obtain PUCSx - {{s(a), u(a)}, {s(b), u ( b ) ) ) . Let us now construct IrdCS2. In the first conjunction {s(a), u(a)}, u(a) is in - , M - ; so only {s(a)} is added to FUCS,. As both s(b) and u(b) are in - , M - , the next conjunction is removed. Therefore, I=UCS1 = {{s(a)}}. Definition 4 is not very effective as it is based on the definition of the GUS whose c o m p u t a t i o n we want to avoid. Therefore we shall next give a different definition of the GUUS. To this end, we need to expand the t=UCS to include all undefined a t o m s t h a t can be useful to prove the unfoundness of elements in the FUCS.

Example 10. Consider the program rl : f ~-- a,~b. r 2 : g ~ C, ~d. r3:b~---e. r4:e~---b.

172

and let M = {a}. Now, observing rule rx, it is easy to see that proving that b is unfounded is useful for the derivation of f (i.e., {b} is a possibly unfounded conjunction). The same reasoning does not apply to d, as c is not true in M (see rule r2). On the other hand, as b depends positively on e (see rule r3), the unfonndness ore is needed to prove the nnfoundness orb (and vice versa). We now formalize the intuition of the preceding discussion by giving the definition of closure of PUCS. D e f i n i t i o n 7 . Given a D A T A L O G program P and X C_ B~, U",B~, , the closure of m C S ~ , ( X ) , denoted by m C S ; , ( X ) , is defined as follows:

1. A is in PUCS~,(X) if it is in some element of PUCS~,(X), and e. A E "X is in PUCS~,(X) if there exists r E ground(P) with head in PUCS.},(X) such that B(r) is not false in X and A e B(r) +.

Example 11. Given the program in the Example 10 and the model M = {a}, it is immediately recognized that I~CS~,( M ) = {b, e}. Following [11], given X C_ B~, U -,By, we define the transformation F'p,x as follows: for each Y C_ B~,,

F~,,x(Y) = {A G YiVr e ground(P), H(r) # A V B(r)is false inX U -~Y} The following important property is proven in [8]. F a c t 6 Let P be a DATALOG" program and X C_ B~, U "~B~,. Then,

6UUS~, ( X ) = PUCS~ ( X / F~,,x ( t:UCS~ ( X ) ) ) .

Thus Fact 6 is a constructive definition of the GUUS that is suitable for a simple and efficient implementation as shown in the function GUUS of Figure 5. Note that in this function we construct rules whose body is of the form < Q1 > < Q2 >, where Q1 and Q2 are two conjunctions of literals. Moreover we introduce a function T which is applied to a program and a pair of set of literals, say X and Y, so that for every rule of the program, Q1 is evaluated w.r.t. X whereas Q2 is evaluated w.r.t.Y. Finally, F p , M ( Y ) is computed as Y - ~'P,M(Y) where

P~',M(Y) = {A E Y l 3 r G g r o u n d ( P ) , H ( r ) = A and B ( r ) is not false in M U - , Y } .

173

F u n c t i o n (3UUS(P : Program; M : Literals) : Literals; var/5, ~ : Program; PUCS.P : Set of Literais; PUCSO, I ~ C S . , Y, GUUSO : Literals; begin PUCS_P := PUCS(P,-M); PUCSO := 0; (*Compute first all elements of the possibly unfounded conjunctions*) for each C 6 PUCS_P do PUCSO :=/~dCS0 U {C} endfor; 15 := 0; (* Construct/5 for computing the PUCS* *) for each r 6 P do for each A 6 B(r) + do /5 :=/5 U {A ~---< H ( r ) > < not(-~B(r)), not(A) > .} endfor endfor; PUCS* := t~CSO; (* Compute the I=UCS* *) repeat Y : : PUCS*; PUCS* := 7~(/5, Y, M) until Y = PUCS*; P := 0; (* Construct P for computing F~,M(PUCS* ) *) for each r E P do (* let B ( r ) + = A1,..., A, and B ( r ) - = -~B1,...,-~B,~ *) P := PU {H(r) ~---< H(r)) > < not(-~B(r)) > .} endfor; (* Compute F~,M(PUCS. ) *) repeat Y := PUCS*; PUCS* := PUCS * - T ( P, PUCS* , -~t=UCS * UM) until Y = PUCS*; GUUS0 := 0; (* Compute the GUUS *) for each C E PUCS-P do if C C PUCS* t h e n GUUS0 : : GUUS0 W C endif; endfor; r e t u r n GUUS0 e n d (~7]S; ^

Fig. 5. Function ~ S

-

-

174

Example 12. Consider the followin 9 program: a 6.- .-.nb, "~c. a +-- " a d . C ~

-rid, -no.

d~e,f. e~---d. Let M = O. The function (Z/US starts computing trUCS-P = {{b, c}, {d}, {d, c}}. Then it sets I:UCS* = {b, e, d} and constrncts the program P consisting of the following rules: e *--< d > < not(~e), not(-~f), not(e) > . f ~--< d > < not(-ne), not(-nf), n o t ( f ) > . d *---< e > < not(--,d), not(d) > .

At this point PUCS* is saturated through a fizpoint computation. At the f r s t step, 7"(P, {b, c, d},O) gives the set {b, c, d, e , f } ; this set is recomputed, in the next step so that it is the fixpoint. Thus FUCS* = {b, c, d, e, f}. Next the function constructs the program P consisting of the following rules: a ,--< a > < not(b), not(c) > . a , - < a > < not(d) > . c , - - < c > < not(d), not(d), not(c) > . d ,---< d > < not(--,e), not(--,f) > . e ~---< e > < not(",d) > .

Another fizpoint computation is started. At the first step T ( ~ , {b, c, d, e, f}, { - b , - c , ~ d , - e , - f } ) = {c}

thus c is to be removed from t~CS*. As in the next step T ( ~ , {b, d, e, f}, {-,b,-,d,-,e,-~f}) = 0 {b, d, e, f} is the fixpoint. Finally, the function computes the GUUS by restricting PUCS-P to {b, d, e, f } . The only possibly unfounded conjunction that is contained in {b, d, e, f} is {d}; so the ~ S is {d}. B References

1. Apt, K., Bair, H., and Walker, A., "Towards a Theory of Declarative Knowledge", in Foundations of Deductive Databases and Logic Programming , J. Minker (Ed.), Morgan Kauffman, pp. 89-148, 1988. 2. Chandra, A., and D. Hard, "Horn Clauses and Generalization", Journal at Logic Programming 2, 1, pp. 320-340, 1985. 3. Clark, K.L., "Negation as Failure", in Logic and Data Bases, (Gallaire and Minker, eds), Plenum Press, New York, pp. 293-322, 1978.

175

4. Fitting, M., and M. Ben-Jacob, "Stratified and Three-valued Logic Programming Semantics", Proc. 5th Int. Conf. and Syrup. on Logic Programming, MIT Press, Cambridge, Ma, pp. 1054-1068, 1988. 5. Garey, M. R., and Johnson, D.S., Computers and Intractability, W.H. Freeman and Company, 1979. 6. Gelfond, M., and Lifschitz, V., "The Stable Model Semantics for Logic Programming", Proc. 5th lnt. Conf. and Syrup. on Logic Programming, MIT Press, Cambridge, Ma, pp. 1070-1080, 1988. 7. Lloyd, J. W., Foundations of Logic Programming, Springer-Verlag, 1987. 8. Leone, N., Rullo, P., "Safe Computation of the Well-Founded Semantics of DATALOG Queries", Information System 17, 1, 1992. 9. Naqvi, S.A., "A Logic for Negation in Database Systems", in Foundations ol Deductive Databases and Logic Programming, (Minker, J., ed.), Morgan Kaufman, Los Altos, 1987. 10. Przymusinski, T.C., "On the Declarative Semantics of Stratified Deductive Databases and Logic Programs", in Foundations ol Deductive Databases and Logic Programming, (Minker, J. ed.}, Morgan Kaufman, Los Altos, pp. 193216, 1987. 11. Przymusinski, T.C., "Every logic program has a natural stratification and an iterated fixed point model", Proc. ACM Syrup. on Principles of Database Systems, pp. 11-21, 1989. 12. Przymusinski T.C., "Extended stable semantics for normal and disjunctive programs", Proc. of the 7th lnt. Conf. on Logic Programming, MIT Press, Cambridge, 1990, pp. 459-477. 13. Sacca, D. and Zaniolo, C., "Partial Models, Stable Models and NonDeterminism in Logic Programs with Negation", Proc. ACM Syrup. on Principles of Database Systems, pp. 205-218,1990. 14. Sacca, D. and Zaniolo, C., "Determinism and Non-Determinism in Logic Programs with Negation", unpublished manuscript, 1992. 15. Tarski, A., "A Lattice Theoretical Fixpoint Theorem and its Application", Pacific Journal of Mathematics 5, pp. 285-309, 1955. 16. Ullman, J, D., Principles of Database and Knowledge-Base Management System , Academic Press, 1988. 17. Van Gelder, A., "Negation as Failure Using Tight Derivations for Logic Programs", Proc. 3rd IEEE Syrup. on Logic Programming, Springer-Verlag, pp. 127-138, 1986. 18. Van Gelder A., Ross K., and J.S. Schlipf, "Unfounded Sets and Well-Founded Semantics for General Logic Programs", A CM SIGMOD-SIGA CT Symp. on Principles of Database Systems, pp. 221-230, 1988'. 19. Van Gelder A., Ross K., and J.S. Schlipf, "The Well-Founded Semantics for General Logic Programs", Journal of the ACM 38, 3, pp. 620-650, 1991. 20. You,J-H. and L.Y. Yuan, "Three-Valued Formalization in Logic Programs: is it really needed?", A CM SIGMOD-SIGA CT Syrup. on Principles of Database Systems, pp. 172-181, 1990

Modules in Logic Programming: a Framework for Knowledge Management* Annalina Fabrizio, Maurizio Capaccioli, Sandra Valeri Systems & Management ~ via Vittorio Alfieri 19 10121 Torino, Italy

Abstract. This paper describes a proposal for knowledge modularization in a logic language. Our aim is to define structuring mechanisms for the integration and composition of modules in order to provide software reusability, clean problem definition and non-standard programming techniques. The proposed mechanisms include the ability to define modules and connections between them. A program module can be combined with other modules (by using the link mechanism) to offer a programming paradigm based on the separation of the problem in independent subproblems. A suitable set of operators on logic modules offers a kernel for a rational reconstruction of knowledge representation and programming-inthe-large techniques. Modules can be represented by using different technologies: a module can be a data base or a C language program.

1

Introduction

The purpose o f this paper is to describe a structuring mechanism for logic programming languages. Prolog is a rule based logic language, hence showing characteristics o f syntax simplicity that, on one hand allow a highly declarative description, on the other show the problem o f code understanding. The lack o f structuring results in little readable programs, so it is difficult to maintain and to reuse them. A structuring mechanism is required to organise a complex program in smaller, interrelated units. By describing the problem through separated and cooperating program modules, it is possible to specify problems o f a high degree o f complexity. Because each module is designed to solve a particular part o f the problem, it is easier to write and to reuse it. Interesting features o f this approach are simplicity o f description, flexibility of use and readability. There is another important issue that deserves more attention: the integration of the logic language with other programming * Work partially mpported by CNR, "PF Sistemi lnformatici e Calcolo Parallelo, Sottoprogelto 5, LRC LOGIDATA+" o Work completed by tile authors actually employed in other companies.. You can contact: Annalina Fabrizio, via U. Viale I/A 56124 Pisa Italy.

177

languages, programming paradigms and representation technologies, in particular with a relational DBMS. The proposal has been realised through the metaprogramming approach [2], which provides a powerful and conceptually neat technique for the definition and implementation of new formalisms. Metaprograms treat other programs as data. The writing of metaprograms is particularly easy in Prolog [3,14] due to the equivalence of programs and data: both are Prolog terms. In the paper we present our modularization mechanisms. Three different points of view are considered: the structuring of a logic program in related typed modules, the composition of logic modules and the integration with modules that use different representation technologies. Some of the ideas on modularization, structuring and integration among different modules of knowledge are based on the Epsilon system [8,9,15,16] and are presented in [10]. In order to define knowledge composition we based our work on the studies for the definition of operators defining an algebra on theories and hierarchical operators among theories [4,12,13]. A first version of this proposal can be found in [11]. In the follow we sketch the paper contents. In the second section we present the basic concept of our knowledge structuring that are link and module, then the structured program shape and four different types of link are presented and the practical use is shown by an example. In the third section we show the algebraic operators on which the operators we propose are based, then we describe the operators we propose and how construct a new module with them. The fourth section deals with the integration of logic modules with C program and a relational database. The C module and the database module are shown. Then you can find conclusion and references in the fifth and sixth section respectively.

2

Knowledge

Structuring

The proposed structuring mechanisms include the ability to define modules and connections between them. A program module can be combined with other modules (by using the link mechanism) to offer a programming paradigm based on the separation of the problem in independent sub-problems. To describe our proposal we consider Prolog rules.

2.1

Logic Modules and Links

A logic module is a set of logic rules and has a name. A logic module contains Prolog rules. To start up the resolution of a goal it is necessary to specify in which module the goal itself has to be evaluated. The metapredicate

query(M, G) represents the evaluation of goal G inside the module M. For example, if M is defined as follows:

178

M: p(X):- q(X).

q~a). the request query(M, p(a)) will be successful. A module can be related to other modules, meaning that the knowledge contained into a module is used "together" with the knowledge of another one. To this purpose we define a mechanism called link. A link is a semantic relation between modules whose effect is to define an "extended" knowledge, obtained from the cooperation of the knowledge belonging to the involved modules. Suppose we have modules M, N related by a link from M to N. Let M defined as above and N as follows:

N: q(b).

p(c). A link from M to N implies that to solve a goal inside module M it is possible also to refer to the knowledge in N. The knowledge contained in module M is extended with the knowledge contained in module N. We provide a set of links (see section 2.3) in order to support several ways for extending the knowledge of a module. It is worthwhile to note that a link has a "direction" from M to N, representing an order in the consultation of M and N: the module M is first consulted and then N is consulted. So a link is graphically represented by an arrow connecting the source module and the destination module of the link. The direction of a link is even more important in a "chain" of modules. In the example shown in figure 1, the consultation of the knowledge for the solution of a query passes through the chain of modules until the answer is found or when all modules have been consulted.

M1

~link-->

I I M2

~link~>

...

~link~>

I

Mn

Fig. 1. Chain of modules Several links having the same source module and different destination modules can be defined. In order to find a solution of a query, in the example shown in figure 2, the knowledge in M1 is extended with the knowledge in M2 or in M3.

179

lin' lM21 '

link - - >

I

M3

I

Fig. 2. M1 knowledge is extended with the knowledge in M2 or in M3 Moreover, several source modules can exploit the same destination module as shown in figure 3. The destination module represents the knowledge shared among the source modules.

M,I, link --> M3

link -->

I M2 [/ Fig. 3. M1 and M2 share the knowledge in M3

2.2 Programs A program is defined by a pair <M, L>, where M represents a set of modules and L represents a set of links. The knowledge base dictionary describes the modules and the links among them through a set of metapredicates of the form module(A) and link(A, B, Type), where A and B are module names and Type is a predefined link Type. It is possible to create/delete a link from a module M1 to a module M2 adding/removing the metapredicate link(M1, M2, Type) to/from the dictionary. To allow the dynamic creation and deletion of links at run time the metapredicates makelink(M1,M2, Type) and dellink(M1,M2, Type) can be used. These metapredicates can be used as any other predicate inside a clause. For example, rules contained in a module can be accessed just under a condition. Let be P = <{M1, M2}, { }> a program where M1, M2 are defined as follows:

180

MI:

q(X):-

p(X), makelink(M1,M2,Type), fiX), dellink(M1,M2,Type).

q(b). p(a). M2:

p(b). r(a).

r(b). Consider the following query to be solved: query(Ml, q(X)) The link from M1 to M2 is created only if the goal p(X) is successful, hence making M2 accessible for the resolution of r(X) predicate. Note that, during the evaluation of r(X), the program is P' = <{M1, M2},{link(M1,M2,Type)}>; the metapredicate dellink(M1,M2, Type), establishes that the link existence is restricted to the whole resolution of the goal r(X). Finally it is worthwhile to note that modules can exchange knowledge by using explicitly the query metapredicate. The query metapredicate can appear inside a clause in a module, so it is possible to solve a goal in a given module independently of the structure of the program induced by the links.

2.3

Link Types

Different ways can be identified to relate two or more modules [10]. By means of different types of links it is possible to combine the knowledge of distinct modules by using each time the appropriated link type for a specified problem interaction. The cooperation of rules contained in different modules rise from two kinds of orthogonal modalities: open~close and use/consultance. They state in which manner we can refer to the knowledge of a related module, to evaluate a goal in a source module. Open/Close Modality. The open~close cooperation modality between modules deals with visibility: it states which part of knowledge in the destination module has to be consulted.

open modality: all the predicates defined in the destination module are visible from the source module; by this way the knowledge contained in a module is extended with the whole knowledge contained in the related module.

close modality: only the predicates of the destination module that are not defined in the source module are visible; by this way the knowledge contained in a module is extended with the knowledge contained in the related module only for predicates that are not already defined.

181

Use/Consultance Modality. The use/consultance cooperation modality between modules deals with how a goal is evaluated inside a related module, namely how to consult the knowledge of the destination module. 9

consultance modality: the goal evaluation in the destination module takes

place, eventually with a return value. The destination module is a "black box": it takes a goal and returns failure or success, together with the bindings for variables. The evaluation process in the destination module is hidden. 9

use modality: the goal evaluation in the destination module starts up the search of the goal definition in the module; the first found definition is evaluated in the source module, observing the same evaluation rule. In this case the source and destination modules have to be written in the same language.

The combination of the above cooperation modalities originates four types of knowledge structuring represented by four link types between modules: openuse, closeuse, openconsultance, closeconsultance.

For example, let be P=< {M1, M2}, {link(M1,M2,Type)} >, where M1 and M2 are defined as follows and Type represents a generic link type: MI: p(a). q(X):-r(X). M2: qCo). r(X):-p(X). Consider the query: query(M1, q(X)). The following table summarises the answers that could be obtained with the combination of the two different m(~.lalities: modality

open

close

use

{ q(a), q(b) }

{ q(a) }

consultance

{ q(b) }

{}

table 1 If the link from M1 to M2 is o p e n u s e , the solutions are { q(a), q(b) }. The answers obtained by using an openuse link are the same achievable from a "sorted"

182

union of the rules contained in M1 and M2, but by using an openuse link we can have best results in efficiency and modularity. In fact we can use the two modules both alone and together and, in addition, they can be dynamically disconnected and connected with others. Moreover, if a goal is obtained only exploiting M1 rules, the search is done on a less number of rules. If the link from M1 to M2 is closeuse the solution is { q(a) }. In this case the clause q(b) in M2 is not used in the resolution because a clause defining q is already existing in M1. In any case with the use modality, any clause is interpreted starting from the source module, even though its definition resides in a different module. If the link from M1 to M2 is openconsultance the solution is { q(b) }, in this case q(a) is not a solution because the evaluation of r(X) considers only the rules in M2 and it fails. If the link is closeconsult the solution is { }. In this case q(a) is not a solution as already seen for the openconsultance link, and q(b) is not a solution since the close modality hide the additional definition of q in M2. In any case, with the consultance modality the evaluation takes place inside the destination module. 2.4

An Example

The proposed knowledge structuring mechanisms permit to define the knowledge concerning an entity into a module and to extend it, through links, by using additional knowledge contained into separate and distinct modules. By this way is possible to deal with specialisation and generalisation of subjects and to support the exception handling. It is also possible to solve directly a given query in a specified module by using an explicit call, thus ignoring the structure of the program given by the links. Suppose the program P is defined as follows: P =< {vialli, football_player, person, gullit, matches, teams}, { link( vialli, football_player, openuse). link( vialli, person, openuse). link( gullit, footballplayer, closeuse). link( gullit, person, openuse). link( football_player, matches, closeconsultance). }> Figure 4 shows a graphical representation of P

vialli

I enue l, payol

I

1"

openuse

closeuse

$

i

cloecon

matches

teams

Fig. 4. Graphical representation of P

183

Suppose the modules are so defined: football player: nationality(italian). address(X):- team(T), query(teams,address(T,X)). gain(X,Y):- match(Y), percentage(Y, Z), takings(Y,W), X is W*Z. teams: address(juventus, "via... Torino"). colours(milan, rossonero). address(milan, "via... Milano")) colours 0uventus, bianconero). person: address(X):- age(Y), Y < 18, father(F), query(F, address(X)). address(X):- wife(Y), query(Y, address(X)). age(X):- bornyear(Y), currentyear(Z), X is Z-Y. vialli: team(juventus). match0uventus-milan). percentage(juventus-milan, 0.001) percentage(X, 0.005):- awaymatch(X). gullit: bomyear(.. ). team(milan). matchOuventus-milan). nationality(dutch). percentage(... ). matches: takings(X,Y)... gain(X,Y)...

football__player describes players of italian football teams, person contains private data of people. We define particular characteristics of two football players, i.e. Vialli and Gullit, respectively in vialli and gullit modules. The openuse link between vialli and football_player will express that anything valid for italian players is also valid for Vialli; for example the fact of being an italian person. The closeuse link from gullit tofootball__player can be used to describe that Gullit has general characteristics of an italian football player, but he has same properties different from the general ones, e.g. he is not italian. With the use modality

184

it is possible to describe the knowledge for generalisation/specialisation, while the

close modality can be used to manage the exceptions. To know how much Vialli earns we can require the evaluation of the goal

query(viaUi, gain(X, Y)) In the vialli module is not defined gain, so the evaluation refers to the knowledge offootball__player where gain(X, Y) is defined, gain(X, Y) representing profits X of a football player on the basis of his percentage on the takings of the match Y. The resolution in module vialli of the clause defining gain(X, Y) will bind the variable Y to "juventus-milan" and the variable Z to 0,001. At this point, since in vialli is not present any information on takings, the resolution of takings( 'Tuventus-milan", W) considers thefootball_.player module knowledge. The module does not contain that information and then the matches module is consulted, yielding the goal solution. It is worthwhile to note that in this example a consultance link is used to relate the matches module, so the takings definition is not provided because we are interested only in the answer provided by the module and takings is solved only inside the matches module rather than in the chain of modules starting from the vialli module. Moreover, the link to matches is close so it is possible to redefine gain, also defined in football..player, with a different meaning because it can only be used locally. We can execute query(gullit, address(X)) to know the address of Gullit. This query starts the search for address in guUit and then infootball_.player. The evaluation of the body of address will bind the variable T to "milan" and therefore the metapredicate query(teams, address(milan, X)) is called: so address is explicitly activated in teams, giving back as a result the team address. Note that if another solution for address is requested, we could obtain the Gullit wife address. The explicit use of the knowledge of a module through the query metapredicate can be obtained also by using the makelink and dellink predicates. For example in football__players the clause defining address could be substituted as follows: address(X):- team 03, makelink(football_players, teams, closeconsultance), address(T,X), dellink(football_players, teams, closeconsultance). By this way, the search of a definition for the Gullit address will start from the gullit module, while by using the query metapredicate, the evaluation is immediately made active in teams.

3

Module Composition Operators

A suitable set of operators on logic modules offers a kernel for a rational reconstruction of knowledge representation and programming-in-the-large techniques. It is possible to compose the knowledge of two logic modules in a single module. This can be obtained introducing in the language operators on modules whose

185

effect is to produce a new module. The user can explicitly query the new module referring a specific operator through the query metapredicate: query(lVll operator M2, Goal) A module which result from the evaluation of M1 operator M2 will be created and the query Goal will be evaluated in this module. To define our operators we refer to [12,13] where a set of operators defining an algebra on logic theories is provided, and to [4] where hierarchical operators between theories are defined based on these algebraic operators. We propose operators based on the algebraic operators shown in the following. The intersection operator produces a new module that contains intuitively the shared knowledge of the argument modules. If M1, M2 contain a common predicate p" MI: p(tl ..... m):--Bodyl . . .

M2: ~ 1 7 6

p(sl ..... sn):-Body2 . ~

then the module M obtained by the operation intersection(M1, M2) contains: p((tl ..... m)~t) :- (Bodyl, Body2)~ where kt is the most general unifier between (tl ..... tn) and (sl ..... sn). The union operator produces a new module whose clauses are given by the union of the clauses of the two arguments. The negation operator produces a new module containing the definition of new predicates that are the negation of the predicates of the argument. An example is in the follow. Suppose program P = < ({ uefa, champions, cups }, { }) >, where: uef~ participate(X):- won(X, uefa, 89). participate(X):- classified (2, championship, 89). participate(X):-... regular_team(X):- players(X,Y), Y>=I 1, Y<=22.

186

cups: participate(x):- won(X, cups, 89),competitor(x). participate(X):- won(X, italycup, 89). regular_team(x):- foreign_players(X,Y), Y<=3. champions: participate(X):- won(X, champions, 89). participate(X):- won(x, championship, 89). regular_team(x):- reserves(X,Y), Y<=5.

participate(X) describes rules so that team X can participate to the relative tournament; regular_team(X) describes the characteristics of a candidate team for the tournament. An intersection operator takes sense between modules showing a common knowledge. An intersection operator between uefa e cups underlines the common characteristics for both cups. For example an intersection operator between uefa and cups defines another module from which we can obtain the team that can participate to both the cups. The following query: query((uefa intersection cups), participate(X)). produces the following temporary module: uefa intersection cups: participate(X):(X). participate(X):participate(X):-

won(X, uefa, 89), won(X, cups, 89), competitor won(X, uefa, 89), won(X, italycup, 89). classified(2, championship, 89), won(X, cups, 89), competitor (X). classified(2,championship,89), won(X, italycup,

participate(X):89). participate(X):-... regular_team(X):- players (X,Y) Y>= 11, Y<=22, foreign_players (X,Z), Z<=3.

The union operator between uefa and champions modules creates a new module underlining the properties of a candidate team (regular_team) and the characteristics of participation of a team (participate) to the Uefa cup or the Champions cup. The goal: query (uefa union champions, participate(X)). will produce file module:

187

uefa union champions: participate(X):won(X, uefa, 89). participate(X):classified(2, championship, 89). participate(X):participate(X):won(X, champions, 89). participate(X):won(X, championship, 89). regular_team(X):- players(X,Y ), Y>= 11, Y<=22. regular_team(X):- reserves(X,Y), Y<--5. The negation operator on cups module creates a new module that underlines the characteristics of no participation of teams to the Cup's cup by using the predicate -participate, negation of the predicate participate. The goal: query(negation(cups), -participate(X)). will produce the module: negation cups: -participate(X):- -won(X, cups, 89), -won(X, italycup, 89). -participate(X):- -competitor (X), -won(X, italycup, 89).

3.1

Composition Operators

Now we present the set of operators we propose. They are based on the ones previously presented. The operators can be used only between logic modules. The cat operator produces a new module whose clauses are given appending the clauses of the first module with those of the second one. (It is the same of union operator). For example, suppose program P = ({M1,M2}, {}), where M1, M2 are defined as follows: MI: p(X):-q(X). r(a). p(b). M2: q(a). q(X):-r(X). then module M = M1 cat M2 will be:

188

M:

p(X):-qO0. r(a). pCo). q(a). qOO:-rO0. The knowledge represented in module M is the same knowledge that can be obtained by the program: P = <{M1, M2}, { link(M1, M2, openuse) }> We can choose to use one of these solutions according to the problem we want to solve. For example, by using the cat operator we have a better efficiency, while by using the openuse link we have a greater modularity. Given two modules M1 and M2, the union without repetition operator produces a new module M: M -- M1 unionwr M2 that will contains:

1)

All the predicates of M1 that are not defined in M2; if the clause C: p(tl,t2 ..... tn):- Bodyl is in M1 and it does not exist in M2 a clause with head p then C is in M.

2)

All the predicates of M2 that are not defined in M1; if the clause C: p(tl,t2 ..... tn):- Body2 is in M2 and it does not exist in M1 a clause with head p then C is in M.

3)

All the predicates defined in both modules are treated as the following: if p(tl,t2 ..... m):- Bodyl is in MI and p(sl,s2 ..... sn):- Body2 is in M2 and it exists the most general unifier IX of (sl,s2 ..... sn) and (tl,t2 ..... tn) then p((tl,t2 ..... tn)IX):- (Bodyl, Body2)IX is in M.

Intuitively, the resulting module M includes the common knowledge to M1 and M2, and the knowledge useful to evaluate the common knowledge. This operation corresponds to define a module M as the intersection of M1 and M2 and create two closeuse links: the first one from M to M1 and the second one from M to M2. The close modality is used to hide definitions common to M1 and M2, and the use modality is chosen to access definitions in rule bodies. For example, suppose:

189

P = < {MI, M2}, {} > where M1, M2 are defined as follows: MI:

p(X):- q(X). q(a). q(f(X)):- r(x).

r(f(c)). M2:

s(b). q(X):-t(f(X)). t(f(X)):-t(x).

t(0). then M = M1 unionwr M2 will be: M:

p(X):- q(X). r(f(c)).

s(b). q(a):-t(f(a)). q(f(X)):- r(x), t(f(X)).

t(f(x)):-t(x). t(0). Generally, we can describe in the first module a general knowledge and in the second one a more specified part of the same field of knowledge, so the module resulting by using the unionwr operator, will contain the application of general knowledge to the specific description. Finally, the user can explicitly query a module obtained by using the above operators through the query metapredicate: query(M1 operator M2, Goal) the module which result from the evaluation of M1 operator M2 will be constructed and stored, so it will be available for further queries until the program will remain active; the constructed module will be deleted when the user leaves the program.

190

4

Integrating Different Kinds of Knowledge

It can be interesting to use, in a structured program, modules that can be written with other programming languages or other programming technologies. Modules that are the destination of a consultance link give back only bindings for variables, so we can suppose that a goal in a destination module can be solved by any interpreter. In fact, the representation technology of the destination module of a consultance link can be different from that used for the source module. For example the source module can be a logic program and the destination module retrieving facts from a data base data through a database management interface program. In order to define different type of module we have to extend the description of a module in the knowledge base dictionary. It becomes:

module (M, Type) where Type can be:

simple

logic modules without structure, namely modules interacting without exploiting links;

structured logic modules structured with links; database

database modules;

C

modules written in C language.

The reason for having simple modules besides structured ones is that structured modules are metainterpreted by a suitable metainterpreter, while simple modules can be interpreted directly by the underlying Prolog system: their execution is therefore more efficient. A goal in a logic structured module could be evaluated in a C module or in a database module or in a logic module (if a link exists to these modules) and in the original logic module it is transparent.

4.1 C Modules A C module is composed of a set of functions written in C language. It is represented by a description module containing the list of object programs that constitute the module and the list of functions associated to logic predicates. The logic module can use the function contained in a C module with the metapredicate query(Module, P(X)), where Module is the name of the module and P is a predicate associated to a function defined in the C module. A C module can be used only as destination module of a consultance link. The functions described in the description module will be implicitly accessible only by structured modules source of openconsultance or closeconsultance link towards the C module.

191

4.2

Database

Modules

A database module is composed of a set of tuples of a relational data base. It is represented by a description module containing the list of relations and names and types of each field. It represents the interface towards a relational database. The logic module can use the knowledge contained in a database module with the metapredicate query(Module, Q), where Module is the name of the module and Q is the query to the database. In logic programming, the database is defined to be the set of facts. However, there is nothing in the language that prohibits it from working directly on large, permanently stored relational databases: because of the natural correspondence between logic programming and the relational data model, from a conceptual point of view the integration of a relational DBMS in Prolog-based languages turns out to be particularly interesting and easy to pursue [6]. Databases are included in the proposal as modules of a particular type, called database: A database module represents the knowledge contained in a relational database. It is possible to use from a logic program data stored in the relational database by a query in the database module. Each database module is the Prolog data dictionary of the relational database that it represents. It is possible both to work with an already existing database and to create a new one. Let us see an example of a database module named company that contains three relations: personnel, offices and projects: company: offices( off_num :: smallint, location :: char(15), manager :: integer, address :: char(25), city :: char(25), state :: char(2), country :: char(25), zipcode :: char(5)). projects( proj_num :: smallint, start_date :: date, end_date :: date, manager :: integer, description :: char(120)).

192

personnel( pers_num :: serial, fname :: char(15), lname :: char(20), soc_sec__no :: char(11), hire_date :: date, title :: char(25), salary :: money, last_review :: date, last_raise :: decimal, address :: char(25), city :: char(25), state :: char(2), zipcode :: char(5), off_num :: smallint, post_date :: date, proj_num :: smallint). The data dictionary shows, for each relation, the name and type of each field with the syntax: FieldName::FieldType, where FieldType is one of the types supported by the underlying DBMS. The system provides commands for updating both data and the data base schema. Commands which operate on the whole database are carried out as instances of operations on modules. These are the operations for creating, selecting, quitting and deleting a database. Other statements enable to create, modify and drop database tables. It is possible to use existing databases where views and indexes are defined. In particular, views are treated as standard relations; moreover, it is possible to define logical views through Prolog programs. The most interesting feature of the integration with a DBMS is the ability to use from a logic program data stored in a relational database. In particular, the language metapredicate query(Module, Query) allows a database module to be queried from another one (of course, database modules can only be queried from logic modules and cannot query other modules). This general mechanism allows data stored in a database to be used from logic modules. In the following, we show a logic program contained in a simple module named simplemod that performs some deductions by relating different tables and elaborating data contained in the company relational database represented through the above company module. The program works on logic views of the database relations, built in simplemod by using the query metapredicate.

193

simplemod: offices_view(Num,Manag,City) :query(company, offices(Num,_,Manag,_,City . . . . . . )). proj ects_view(Num,Manag) :query(company, projects(Num. . . . ,Manag,_)). personnel_view(Num,Name, Salary,Off_num,Proj_num) :query(company, personnel(Num,_,Name . . . . . . . Salary, . . . . . . . . . . . . Off num,_,Proj_num)). manager_o f(Pers,Manag) :projects_view(Proj,Manag), personnel_view(Pets . . . . . . . Proj). check_projecLbalance(Proj,Res) :- projects_view(Proj,Manag), find bahance(Manag,Res). find_balance(Manag,balanced) :- \+(check_salary(Manag)), !. find_balance(Manag,unbalanced). check_salary(Manag) :- manager_of(Pers,Manag), personnel_view(Pers,_,Pers_sal,_,__), personnel_view(Manag,_,Man_sal,_,_), Man_sal < Pers_sal, !. If we write the previous example in a structured module named structmod linked to company with a closedconsultance link, the logical views can be defined as follows: struclmod: offices_view(Num,Manag,City) :- offices(Num,_,Manag,_,City . . . . . ). projects_view(Num,Manag) :- projects(Num ..... Manag,_). personnel_view(Num,Name, Salary,Off_num,Proj__num) :personnel(Num,_,Name . . . . . . . Salary . . . . . . . . . . . . . Off num,_,Proj_num)

The rest of the program is the same as before, and the knowledge base dictionary of this knowledge base looks as follows: module(company,~tabase) module(structmod,structured) link(structmod,company,closedconsultance)

194

As you can see, it is no longer necessary to call explicitly the database module company_from the logic program, since data contained in the inherited module are automatically retrieved. The logic program is independent from the name of the inherited module and is not affected by the fact that the inherited module is a database module: it uses in the same way both logic predicates and predicates which correspond to database relations. In this sense the integration between Prolog and DBMS becomes completely transparent. Another type of link which can be used by structuredmodules to access database modules is the openconsultancelink. In this case, a predicate can be defined partly in a structured module and partly in a database module, e.g. there may exist facts in the structured module with the same functor and arity as a data base relation, and they will be treated by the structuredmodule in the same way.

5

Conclusions

Rule programming languages have characteristics of declarativity and simplicity of learning and use, however they have problems concerning readability and flexibility in code management. These disadvantages are caused mainly by the flat structure of logic programs, and they result more remarkable when complex problems are considered. The proposed solution is to organise a logic program into separately defined modules and to relate them. Using this approach, it is also possible to integrate a logic language with other paradigms in a simple manner and finally non standard programming techniques are available through module composition operators. A prototype exists [6] that implements the proposed mechanisms. The prototype is written in Prolog language using metaprogramming techniques. The prototype provides a programming environment allowing the user to define the structure of a program by providing facilities to create and destroy links, modules and programs.

References [1] [2] [3] [4] [5] [6]

P. Atzeni, F. Cacace, S. Ceri, L. Tanca. The LOGIDATA+ model. Technical report Logidata+ 5120,July 1990. K. A. Bowen and R. A. Kowalski. Amalgamating language and metalanguage in logic programming. In K. L. Klark and S. A. Tarnlund Eds., Logic Programming, Academic Press 1982, pages.153-172 K. A. Bowen and T. Weinberg. A recta-level extention of Prolog. In 1985 IEEE Symposium on Logic Programming, IEEE Computer Socierty Press 1985, pages 48-53 A. Brogi, P. Mancarella, D. Pedreschi, F. Turini. A Hierarchies through Basic Meta-Level Operators. In Proc. Workshop on Metaprogramming in Logic, META 90, Leuven, Belgio, May 1990. S. Ceri, G. Gottlob, L. Tanca. Logic Programming and Databases. SpringerVerlag, 1990. P. Coscia, A. Fabrizio. Moduli in Logidata+: il prototipo. Technical Report Logidata+ 5/78, August 1991.

LOA: the LOGIDATA+ Object Algebra U m b e r t o N a n n i l, Silvio S a l z a 2'3, M a r i o T e r r a n o v a 3 1 Universitg de L'Aquila, Dipartimento di Matematica Pura ed Applicata, Coppito, L'Aquila, Italy Universitg di Roma "La Sapienza", Dipsartimento di Informatica e Sistemistica, via Salaria 113, 1-00198 Roma, Italy Consiglio Nazionale delle Ricerche, Istituto di AnMisi dei Sistemi ed Informatica, viale Manzoni 30, 1-00185 Roma, Italy

A b s t r a c t . In this paper we present the Logidata Object Algebra (LOA), an algebra for complex objects which has been developed within LOGIDATA+, a national project funded by the Italian National Research Council, as an internal language in a prototype system for the management of extended relational databases with complex object types. LOA is a set-oriented manipulation language which was conceived as an internal language for a prototype system. More precisely it is supposed that user programs, expressed in the external high level language have to be compiled into LOA programs, and then processed by an underlying Object Manager. In other words LOA is supposed to play in our prototype the same role as the relational algebra in a relational system with a very high level user environment. T h a t is providing a suitable formal framework to develop efficient access to mass storage and powerful query optimization strategies. The algebra refers to a d a t a model that includes structured d a t a types and object identity, thus allowing both classes of objects and value-based relations. LOA must support a rule based language with possible recursive programs with limited forms of negation. LOA programs explicitly include a FIXPOINT operator over a set of equations. Another original feature of the algebra is the ability to cope with object identity, and, at the same time, to preserve the capability of handling value based complex structures without identity. This is obtained by extending the semantics of classical operators of the relational algebra to deal with the LOGIDATA d a t a structures, and by introducing additional operators, such as type conversion and oid invention. The paper also briefly discusses some implementation issues of the FIXPOINT operator and the other algebraic primitives.

1

Introduction

In the last d e c a d e the r e l a t i o n a l m o d e l as p r o p o s e d by C o d d [14] has been widely a d o p t e d for s t a n d a r d a p p l i c a t i o n s , b e c a u s e of its simple a n d u n i f o r m s t r u c t u r e and of the larger deal of i n d e p e n d e n c e between t h e logical a n d p h y s i c a l level.

196

However the relational approach has proved to be not satisfactory for several non-conventional applications, as CAD, CASE, office automation, multimedia databases and knowledge bases. In all these cases the flat structure of the model makes the representation of complex and structured data clumsy. Several proposals have been made to extend the relational model, both overcoming the restrictions imposed by First Normal Form [18, 15, 27, 26], and introducing the concept of object identity [20, 21, 19, 4, 28]. For such extended models several authors have presented query and manipulation languages based on calculus [8], on algebra [2, 15, 1] and logic [3]. Dealing with the LOGIDATA language and model requires to support a rich and expressive environment, that is a rule based language in conjunction with an object oriented data model. In this context the conceptual distance between the user (external) language and the implementation level, both in terms of data structure and language constructs, can be tackled by properly choosing some intermediate level in query processing (the internal language), in which user transactions have to be compiled before proceeding in the execution process on physical data. Of course such an internal language must have at least the same expressive power as the external language. Our choice is to adopt an intermediate set-oriented manipulation language that will play in our prototype a role equivalent to that of the relational algebra in a relational system, that is providing a suitable framework to develop efficient access methods for data handling and storage, and powerful query processing strategies. This approach makes especially sense when the object oriented system is aimed at traditional database applications, where the typical transaction involves large sets of objects. For this class of applications indeed the relational systems perform already quite well, and the motivation for using the object oriented model lies mostly in making more natural both the user language and the design phase, and, in general, in having a more direct representation of the real world in the schema. Therefore in such a context the relational model can still be used as an internal level of representation, by mapping the object schema into a relational schema. According to these ideas a prototype system has been developed within LOGIDATA+, a national project funded by the Italian National Research Council, that has the goal of integrating logic programming and extended relational databases, with complex data types. In general an approach to database query and management based on an intermediate language may have the disadvantage that it makes less effective the optimization process, which must be broken in two distinct phases, but has a number of advantages. A good level of modularity can be achieved in the design of the global architecture: this has the obvious consequence to separate different kinds of problems (source code interpretation and data processing) in different modules and, more interestingly, it allows a very fast and cheap experimentation of different solutions. This seems to be a basic requirement in

197

an experimental context in which both the user language and the data model can be subject to possible settlements, and furthermore different hardware/software environments can be tested for prototyping. Moreover the existence of such an intermediate language (in turn subjected to possible extensions) might point out the consequences, in terms of practical performance, of different choices at user language level and implementation of lower level primitives. Let us consider two possible choices for an intermediate (internal) language, characterizing the underlying data management support. In both cases they consist of a traditional environment enriched by several features in order to deal with the expressive power of the external language: -

-

a rule based language on a fiat (relational) data model, that is a sort of datalog, supporting tuple identity, and limited forms of negation; a procedural algebraic language on an object oriented data model, in which additional features must be embodied to handle recursive queries.

We remark that in the case of a fiat relational data model it has been shown that these two approaches - - generalized versions of datalog and relational algebra - - may lead to the same expressive power, provided that suitable enhancements and restrictions are defined such as, for example, a limited form of negation (or complementation) and the absence of functions producing new data values not included in the active domain of the data base. Moreover this can be achieved with reasonable (polynomial) computational complexity (see, for example [12]). Unfortunately in the case of a more complex data model, this is not true, and the problem can achieve an arbitrary complexity [22, 17] and even become undecidable [4]. In this paper we focus on the algebraic approach, consisting in a suitable extension of the relational algebra to support the features of the LOGIDATA data model and external language. The Logidata Object Algebra (LOA) extends the relational algebra in several aspects, incorporating and extending some ideas and features from heterogeneous sources [6, 18, 15, 27, 2, 26, 28]: - the semantics of the classical operators of the relational algebra are suitably redefined in order to deal with the richer object oriented data model; - more operators are included to build and navigate complex data structures; - procedural features are included, such as the FIXPOINT operator, in order to deal with recursive programs. In this paper the problem of extracting data from an existing database is considered, and more precisely the problem of expressing by an algebraic language recursive queries in an object oriented environment. This extends the approach that the authors presented in [24] to deal with recursion. The rest of this paper is organized as follows. In the next section the basic elements of the formal definition of the LOGIDATA+ model are summarized. In section 3 an overview of the features of LOA is described together a basic semantics of LOA. In section 4 we introduce the language used to express complex conditions inside the operators of the extended relational algebra. These

198

operators are discussed in section 5, and in the following one we introduce the structure and conversion operators to explicitly handle transformations between objects and values.

2

The

Data

Model

LOA provides set-oriented operators to manipulate collections of complex objects and structured values, which are defined according to the L O G I D A T A + model [7], whose main features are the following: - it allows the definition of types, functions, and two kinds of data collections: the class (based on object identity), and the relation (value based); d a t a are basically structured with the tuple, set, and sequence constructors; - an isa hierarchy with multiple inheritance can be defined in the set of classes. -

Given a finite set of domains D 1 , . . . , D D with domain names :Dx,... ,:Do, a countable domain of object identifiers 12, and a countable set of attribute names A1,.Az,..., we refer to a database schema composed by the following elements: - A finite set of types names, or shortly types, 01,..., 0o, and the corresponding

type definitions. A finite set of classes C x , . . . , C c with names C 1 , . . . , C c . - A finite set of relations R x , . . . , R R with names T~l,... , ~ n . - An ISA hierarchy between the classes. -

The domain f2 contains the object identifiers that are associated to the objects, each one having an identifier which is unique in all the database. Classes are collections of objects of the same type, and relations are collections of structured values. T y p e definitions allow to build structured types from the basic types associated to the domains, and, for object types, to add the identity. A value set, i.e. the set of all possible vahms, is associated to each type. More formally: -

-

-

-

-

A type 0 is either a value type r or an object type w. A domain name :Di is a value type and the corresponding value set is Di 9 If 0 1 , . . . , 0 , are types with value sets V i , . . . , V , , then r = (Ax : 01,...,A,~ : 0,) defines a tuple type r, with value set V~ = V1 • ... x V , . Round brackets denote the tuple constructor. If 0 is a type and V is the corresponding value set then r = {0} defines a set type r with value set V~ = PART(V), i.e. the powerset of V. Curly brackets denote the set constructor.

- If 0 is a type and V is the corresponding value set then r = (0) defines a sequence type r with value set V~ = SEQ(V), i.e. the set of all the sequences over V. Angle brackets denote the sequence constructor. If r is a tuple value type with value set V, and C is a class name, then = [C, r] is an object type, and the corresponding value set is V,~ = 12 x V.

199

FAMILY(father,mother,children,address)

\

s~

~name,sex,age) it 9

\\

, ,///

1

~:7"~<,.,,,.,, l/"'~176

\ \ ,\

E,MP.I.,Q.YT~(*,position)

/

(department,salary) Curriculum(Ostud,exams) IntegerJ/

/ / Name(givermames,lastname)

r \

String (course,grade)

/\

Stung Integer Fig. 1. A sample schema

String

/ \

String

Integer

200

Each relation is defined on a value type and each class is defined on an object type. More precisely, as we shall see below, there is a one to one correspondence between object types and classes. We may now introduce the notion of refinement as a partial order relationship in the set of types, according to the following definition. A type 0 (either an object type or a value type) is a refinement of a type 0 I (in symbols # _ 0I) if and only if one of the following condition holds: -

0=0';

- 0 = w = [C,r], 0' = w' = [C',r'], with r _ r'; - r = (,41 : O l , . . . , A k + p :Ok+p), r ' = (.Az :0~ . . . . ,Ak : O~), with Oi _-< O;, for l
3

Basic Features of the Logidata Object Algebra

User programs are written in the LOGIDATA+ language, that is a rule based language on an object oriented data model, supporting identity. A stratified form of negation is allowed in the user external language. If a logic program is stratified, it is possible to rewrite it as a set of formulas which are monotonic, i.e. a repeated application of the formulas increases the collection of data stored in the variables. We define a stratified semantics for our FIXPOINT operator. In fact, deciding whether a set of equations is stratifiable is computationally easy. Indeed it would be possible to adopt an inflationary semantics: this approach, used in [4, 9], is strictly more expressive than the stratified semantics [12] and has been proved to coincide with the least fixpoint [16] in the case of finite structures. Nevertheless, in the case of a more complex data model (including oid invention and functions with infinite domain), stratification is not a sufficient condition for a fixpoint of a set of equations to exist [4] and the computation may not terminate. The study of satisfactory solutions for this problem deserves further research effort. In the seminal paper [6] several ways of introducing a fixpoiat operator (or equivalent constructs) within a database language are considered. This has been

201

Domain names: String;

I n t e g e r ; Sex.

Value types: rname = (givennames : (String), lastname : String); Tpers = (name : marne,sex : Sex, age : Integer); rstud = (name : ~aame, sex : Sex, age : Integer, curriculum : rcurr); rcurr = (#stud: Integer, exams: {(course: String, grade: Integer)}); r e m p l = (name : marne, sex : Sex, age : Integer, position : Tpos); Tpos = (department : String, salary : Integer); r f a m = (father: Wpers, mother : wpers, children: (wpers), addr : String).

Object types: wpers -- [Person, rpers]; O;stud ----[Student, rstud]; Wempl = [Employee, rempl ]. Relations: Family : rfam. Classes: Person; Student; Employee.

ISA hierarchy: Student ISA Person; Employee ISA Person.

Fig. 2. Type definitions for the sample schema

202

done with quite different approaches such as, for example the alpha operator [5] or the pointwise recursion [17]. In [12] an overview of the topic is given, comparing the expressive power and complexity of the various constructs. Examples of an approach integrating a rule based language and an object oriented data model are IQL [4], and LOGRES [9]. An algebraic approach integrating recursion and a complex data model can he found in [13]. In the following we provide a very high level description of the overall processing of user programs, clarifying the role of LOA in our approach. At the user (external) level, a program is expressed in a rule-based declarative language, and then a compiler is in charge to determine its structure and stratification, by using standard techniques (see for example [29, 11]), and eventually to rewrite it as an equivalent LOA program. A LOA program is a sequence of blocks. Each block can be a single LOA algebraic equation or a fizpoint block. Each fixpoint block consists of a FIXPOINT operator applied to a set of LOA algebraic equations. These blocks are sequentially evaluated by the LOA processor, which maintains the mapping between the object schema and the relational schema, and translates the object algebra expressions into relational algebra with conditioned loops constructs to compute the stratified fizpoint of the block, as shown, for example, in [4, 9]. A more detailed description of a LOA program is the following9 A LOA program P is a sequence of fixpoint blocks: P = (B1,B2 . . . . ,Bin), where the generic block Bk is either a single equation Rk or it is built up by a FIXPOINT operator applied to a set of equations: (FIXPOINT{Rk,1, Rk,2 . . . . , Rk,nk }). Each equation Rk,i has the form Vk,i ---- gk,i where the left hand side is a typed variable and the right hand side Ck,i is a LOA expression on typed variables and constants. The type of each variable can be a class type or a relation type, and a constant is a class or relation in the knowledge base. A variable Vhj can occur in the right hand side of a rule Rk,i : Vk,i = gk,i if it occurs in the left hand side of some other equation either in the same block or in a previous blocks, that is if h < k (thus including the variable Vk,i itself). In the case where a block Ilk is constituted by a single equation Rk : Vk = gk, then Ck can only contain references to variables in the previous blocks9 Moreover, since the program is stratified, if a variable Vhj appears as a second term of a difference operator (hence coming from a negated predicate) it can not he defined in the same block, but only in the previous ones. The structure of a LOA program can be summarized as follows:

( FIXPOINT{VI,1 -- ~1,1(V1,1,...,

Vl,nl)

V1,2 = gl,2(Vl,1,..., Vl,.,) v~,., = ~ , . , ( v ~ : , . . . ,

v~,.,)}

FIXPOINT{V2,1 -~- ~2,1(V1,1,... , Vl,n,, V2,1,..., V2.,~ = 8 2 , , ~ ( V i : , . . . , vk = 8k(v1,~, . . . , V ~ . , , , . . . ,

V2,n2)

V1,,,, V2:, . . . ,

V2,,,,)}

vk=1:,..., v~_~,,~_,)

203

FIXPOINT

{ Vm,1 . .

-~-

~rn,l(V1,1,...,

Ul,n1,

" " , Vk, " " ,

Vm,l,...,

Vm,n,~)

,

V~,.~

-- ~m,.~

( VI,I,

. . . , VI,.,

, "

" , Vk,

" " " , V,.,1,

. . . , Vm,.~)

} )

In the execution phase each block is evaluated by the LOA processor in sequence according the stratified fixpoint. A simple description of the inflationary fixpoint and a comparison with other fixpoint computations in the case of the flat relational model is given in [12] and a more detailed presentation can be found in [11]. Not much is known about fixpoint computations in the case of a more complex data model (see, for example [4, 9]). In our case the fixpoint of a LOA program is computed by interpreting each block as a cycle containing a sequence of assignments on the variables in the left hand side of any equation. We remark that the presence of several fixpoint blocks (and several equations within each block) should not increase the expressive power of the language (see [16] for the case of a flat model) but makes more flexible and natural the description of a LOA program; furthermore this simplifies the compilation process, that is the translation of user queries from the external language to LOA. In the following sections we specify the syntax and semantics of the operators used in LOA expressions. As far as the algebraic operators are concerned, we generalize previous proposals. These basically refer to the Nested Relation model [15, 27, 2] having only the relation and tuple constructors, thus producing a recursive schema with a tree structure. Abiteboul and Beeri [1] consider a set constructor adding to the algebra a powerset operator to reach the expressive power of the domain independent calculus. In our case, besides considering different kinds of constructors, the main original contributions are related to the need to deal with object identity, and, at the same time, to preserve the capability of handling value based complex structures without identity. These features are not considered in most of the previous proposals which referred to strictly value based models. Object identifiers are treated as special atomic values that cannot be directly accessed, and have to be preserved in the relational operations. This had to be taken into account in the definition of the semantics of the operators, and demanded for additional operators to convert objects into structured values and vice versa. The extension of the operators of the relational algebra is attained by introducing in the conditions a set of navigational operators to move through complex data structures, e.g. to take components from structures, to extract elements from sequences, and to transform data types. Nes~ and Unnest operators are defined as in [18, 26]. These allow respectively the grouping of several tuples introducing a set constructor over an attribute or group of attributes, and the distribution of the elements of a set attribute over a set of tuples. Similar operators are also provided for the tuple constructor. We may point out that, due to the introduction of the navigational operators in the conditions, the role of the Nest and Unnest is mainly restricted to the

204

restructuring of data. Further primitives are defined to transform objects or their components into tuples and vice versa. The latter operation generates new objects and requires object invention.

4

Conditions on Structured Types

To extend the operators of relational algebra we need to extend the definition of the conditions to deal with structured d a t a types. In the relational algebra, selection and ~9-join operators require as additional argument a clause or condition, that is a predicate which must be satisfied by the tuples to contribute to build the resulting relational table. In the most general ease a predicate is a boolean formula over simple predicates, and each of t h e m has an operator (a binary predicate), and two atomic values as operands, which are either two attributes of the tuple(s) or one attribute and a constant (only in the case of a selection clause). In the more complex LOGIDATA model, a clause is used in selection and join as well, and it has the same basic structure, consisting of a boolean formula over simple predicates. In this case the operands of the simple predicates are not necessarily atomic values but can have a structure of arbitrary complexity. We introduce the notion of derived component, which is an expression that can be used in the conditions to denote an operand extracted from an object or a tuple: in general it is a structured value that is a part of it or can be built up from it. Formally, given a relation T~ or a class C of type/9: - If ,4 is an attribute of type/9 then ,4 denotes a derived component from ,4 of type/9. - If ,4 is an attribute of type /9, with corresponding value type r = (,41 : /91,... ,,4k : /gk), and Ei is a derived component from ,4i of type OE, then ,4.Ei is a derived component from attribute ,4 of type/gE. - I f , 4 is an attribute of type {/gB}, with corresponding value type rB ----(,41 : /91,... ,,4k : /gk), and Ei is a derived component from ,4i of type /gE, then A.Ei is a derived component from attribute `4 of type {/gE}. If `4 is an attribute of type (0B), with corresponding value type VB ----(`41 : /91,... ,`4k : /gk), and Ei is a derived component from `4i of type OE, then A.Ei is a derived component from attribute ,4 of type (/gE). - If E denotes a derived component of type /gE, with an associated value type "rE, then: - if"rE = {{/gB}} then FLAT(E) denotes a derived component of type {/gB}; - if "rE = ((6B)) then FLAT(E) denotes a derived component of type (/gB); - if "rE = (/gB), then P o s ( E , n) denotes a derived component of type 0B (the n-th element in the sequence), and SET(E) denotes a component of type -

-

{/gB};

- IfT~ is a relation of type 7" = (,41 :/91,... ,Ak : /gk), and and Ei is a derived component from `4i of type/gE, then Ti.Ei is a derived component from the

205

-

relation T~ of type OE, and ~ denotes a derived component of type r, i.e. a tuple in the relation. I f C is a class of type 0 with associated value type r = (.A1 : 0 1 , . . . ,.Ak : 0k), and El is a derived component from .Ai of type 0E, then C.Ei is a derived component from the class C of type 9E, and C denotes a derived component of type 0, i.e. an object in the class.

With reference to the schema in the Figures 2 and 3, the following are examples of components: -

-

-

S t u d e n t : denotes an object of type Wstud in the class S t u d e n t . S t u d e n t . c u r r i c u l u m . e x a m s : denotes the set of couples ( c o u r s e , d e g r e e ) of an object of the class S t u d e n t . F a m i l y . c h i l d r e n . n a m e . g i v e n n a m e s : denotes the sequence of sequences of givennames of the children of a given family. To get the set of names one should write: Family.FLAW(SEW(r

Components are used to build conditions,i.e.boolean predicates based on the comparisons between components and constants of a compatible type. Formally: - If E 1 and E2 are components of value type TI and 7"2,with value sets V I -V 2 - V, then EloPE2 and E1oPv are conditions, where oP is a comparison operator, and v E V. - If Ez and E~ are components of object type ~vl and w~, then El = E2 or

E1 :/: E2 are conditions. - If E1 is a component of type O and E2 is a: component of type {0} then E1 E E2 and E1 r E2 are conditions. - Every boolean expression whose terms are conditions is a condition. Note that only equality and inequality comparisons are allowed between components of object type, and that comparison may take place between objects of different types. In all these cases the comparison is based on the object identity.

5

Extending

the

Operators

of Relational

Algebra

The traditional operators of the relational algebra, SELECT, PROJECT and JOIN, are extended in two ways. First more powerful conditions are allowed, using the framework introduced in the previous section. The other extension concerns the definition of the type of the result according to the type of the operands and the structure of the conditions. The SELECT extracts from a relation or a class the subset of elements satisfying a given condition. Formally: - If Tr is a relation of type r and / a condition on the type r, then TO' r SELECT(T~;f) is a relation of type r. - If C is a class of type w = [C, r] and ] a condition on the objects of C, then C' r SELECT(C; f ) is a class of type w' = [C', 7-].

206

The PROJECT extends the relational operation in the sense that, instead of a subset of attributes one has to specify the supertype of the operand type that contains the required information. Note that all the nested levels of the data structure are kept in the result. Formally: - If T~ is a relation of type r and r ___ r ' then 7~' r PROJECT(~; r ' ) is a relation of type v'. - If C is a class of type w = [C, r] and r _ r', then C' r PROJECT(C; r t) is a class of type w' = [C', r']. The projection includes the duplicate elimination. This can be effective only when the operand is a relation. The JOIN is defined in such a way that, regardless of the type of the operands, that can be classes or relations in any combination, the result is a binary relation, i.e. one further level is added to the structure of the type. Formally, if X1 and 2'2 are classes or relations of types 01 and 82, a n d / i s a condition involving components from types 01 and 02, then 7~' r JOIN(X1., X2; f ) is a relation of type r' = ( A 1 : 8 1 , A 2 : 0~). With reference to the schema in Fig. t the following are sample queries: Homonyms~ SELECT (Family ;Family. father, name SET (givennames) N

Family. FLAT (SET ( children, name SET (giv snnames ) ) )~

Homonymscontains all the families in which at least one child shares a name with the father. F_ n a m e s ~ = P R O J E C T ( F a m i l y ; ( f a t h e r : ( n a m e : ( g i v e n n a m e s ) ) ) ) .

F_names contains the givennames of the fathers in Family. Note that, as the type of the result is a supertype of the type of the operand, it maintains the complete nested structure around the projected attributes. To flatten the structure, one should use the structure operators introduced in the next section. Artists~JOIN(Family,Student;(Family.SET(children)~Student) A (Student.curriculum.exams.course,'fine arts')).

A

A r t i s t s is a binary relation of type: (Family : tram, S t u d e n t : Wstud ) and contains all the families with a child who passed the exam of fine arts. Additional operators are provided for set operations. These are straightforward extensions of the corresponding relational operators UNION, INTERSECT, DIFFERENCE. 6

Structure

and

Conversion

Operators

The need for these operators arises from the richer structure of the types in the object oriented data model. They are required in the algebra to attain the full capability of data restructuring. This includes the transformation of the

207

components in a structure, from values to objects, and vice versa. Some of these operators have been introduced in algebras for the nested relation model [26, 10]. The structure operators apply only to relations, and produce a relation as a result. T h e y allow to modify the structure by means of actions such as gathering several attributes in a tuple and multiple values of an attribute in a set. More specifically NEST is used to collect in a set the group of distinct values of an attribute of a tuple that share the same value of the rest of the tuple. Formally, ifT~ is a relation of type r = (A1 : 01,... ,Ak : Ok) then 7~' r NEST(T~;.Ak) is a relation of type r = ( , 4 1 : 0 1 , . . . , A k : {Ok}). UNNEST is the reverse operation, and generates a separate tuple in the result relation for every distinct value in an attribute of type set. Formally, if 7~ is a relation of type r = (,41 : 01,... ,Ak : {Ok}) then 7~' r UNNEST(~;.Ak) is a relation of type r I = (-41 : 01,... ,.Ak : Ok). With the same definition the UNNEST can be applied also to sequences. For example the following steps compute a binary relation that associates to each father the set of his wives: C o u p l e s ~ PROJECT(Family ; (father, mother) ) P o l y g a m y ~ NEST (Couples ;mother) O n the other end the following steps compute from Family the relation Parent that contains the couples (parent, child): U..Familyr

UNNEST

Parent ~ UNION PROJECT

(Family ;children)

(PROJECT

(U..Family ;(father :Person, children :Person) ), (mother: Person, children: Person) ) )

(U..Family;

In addition to NEST and UNNEST two more operators are provided, C L U S T E R that groups a subset of attributes in a tuple to generate a subtuple in a single attribute, and M E L T which does the reverse operation, i.e.flattens a tuple structure with a nested tuple attribute. Conversion operators basically allow to convert values into objects and vice versa. Depending if the whole structure or part of it is to be converted, different operators are required: - CLASS: transforms the elements of a relation into objects, thus defining a new class and the corresponding object type. - DECLASS: transforms the objects in a class in structured values, by depriving them of the object identity, and thus eliminating duplicate values from their result. - OBJECT: converts a value component inside a tuple structure into a component of object type, thus defining a new class. - VALUE: converts an object component inside a tuple structure into the corresponding value. Note that the execution of the conversion operators m a y require the invention of object identifiers.For further details and examples one should refer to [23].

208

7

Conclusions

In this paper we present LOA, that is an algebra for the manipulation of complex objects. The algebra refers to a data model (LOGIDATA+) dealing with structured data types and two different kinds of data collections: classes, with object identity enforcement, and value based relations. Moreover, due to the inclusion of a FIXPOINT operator, using LOA it is possible to express recursive programs. With respect to the basic relational primitives, more powerful conditions are provided, based on a set of navigational operators that allow to move through complex data structures; these are to be used in conjunction with the classical operators of projection, selection and join. Additional new operators are defined to manipulate the structure of data, and to attain the full capability of data restructuring. The algebra has been developed within the project LOGIDATA+ as an internal language in the prototype object oriented system. The algebraic set-oriented approach proves to be effective, especially when moving to the object oriented model traditional database applications, where transactions typically operate on large sets of objects. In the prototype system, user programs are to be compiled into LOA programs which are interpreted by an underlying object manager. Details of the implementation of the object manager are described in [25]. Although the algebra has been originally conceived as an internal language for the prototype, it proves also to be quite effective in expressing complex queries. It may then form the basis for the definition of a high level user oriented query and manipulation language.

References 1. S. Abiteboul and C. Beeri. On the Power of Languages for the Manipulation of Complex Objects. Technical Report 846, INRIA, 1988. 2. S. Abiteboul and N. Bidoit. Nonfirst normal form relations: an algebra allowing data restructuring. Journal of Comp. and System Sc., 33 (1), 361-393, 1986. 3. S. Abiteboul and S. Grumbach. Col: a logic-based language for complex objects. Proceedings International Conference on Extending Database Technology), Venezia, Lecture Notes in Computer Science, 303, 271-293, Springer-Verlag, 1988. 4. S. Abiteboul and P. Kanellakis. Object identity as a query language primitive. Proceedings ACM SIGMOD International Conf. on Management of Data, 159173, 1989. 5. R. Agrawal. Alpha: An Extension of Relational Algebra to Express a Class of Recursive Queries. IEEE Transactions on Software Engineering, 14 (7), July 1988. 6. A. V. Aho and J. D. Ullman. Universality of Data Retrieval Languages. Proceedings ACM Conference on Programming Languages, 110-120, 1979. 7. P. Atzeni and L. Tanca. The LOGIDATA+ Rule Language. Proceedings Workshop "Information Systems '90", Kiev, 1990.

209 8. F. Bancilhon and S. Khoshafian. A calculus for complex objects. Journal of Comp. and System Sc., 38(3):326-340, 1989. 9. F. Cacace, S. Ceri, S. Crespi-Reghizzi, L. Tanca, and R. Zicari. Integrating Object-Oriented Data Modeling with a Rule-Based Programming Paradigm. Proceedings ACM SIGMOD International Conf. on Management of Data, 225236, 1990. 10. S. Ceri, S. Crespi-Reghizzi, G. Lamperti, L.A. Lavazza, and R. Zicari. ALGRES: an advanced database system for complex applications. IEEE Software, 7(4), July 1990. 11. S. Ceri, G. Gottlob and L. Tanca. Logic Programming and Databases. Springer Verlag, 1990. 12. A. K. Chandra. Theory of Database Queries. Proceedings ACM Symposium on Principles of Database Systems, 1-9, 1988. 13. L. S. Colby. A Recursive Algebra and Query Optimization for Nested Relations. Proceedings ACM SIGMOD International Conf. on Management of Data, 273283, 1989. 14. E.F. Codd. A relational model for large shared data banks. Communications of the ACM, 13 (6), 377-387, 1970. 15. P.C. Fischer and S.J. Thomas. Operators for non-first-normal-form relations. Proceedings ]EEE Computer Software Applications, pages 464-475, 1983. 16. Y. Gurevich and S. Shelah. Fixed-point extensions of first-order logic. Annals of Pure and Applied Logic, 32, Noth Holland, 1986, 265-280. Also in Proceedings Int. Conf. on Foundations of Computer Science, 346-353, 1985. 17. R. Hull and J. Su. On accessing Object-Oriented Databases: Expressive Power, Complexity, and Restrictions. Proceedings A CM SIGA C T SIGMOD Symposium on Principles of Database Systems, 147-158, 1989. 18. G. Jaeschke and H.-J. Schek. Remarks on the algebra for non first normal form relations. Proceedings ACM SIGACT SIGMOD Symposium on Principles of Database Systems, 124-138, 1982. 19. S. Khoshafian and G. Copeland. Object identity. Proceedings ACM Symposium on Object Oriented Programming Systems, Languages and Applications, 1986. 20. G.M. Kuper. The Logical Data Model: A New Approach to Database Logic. PhD thesis, Stanford University, 1985. 21. G.M. Kuper and M.Y. Vardi. A New Approach to Database Logic. Proceedings Third A CM SIGA CT SIGMOD Symposium on Principles of Database Systems, 1984. 22. G.M. Kuper and M.Y. Vardi. On the complexity of queries in the logical data model. Proceedings International Conference on Data Base Theory, 267-280, 1988. 23. U. Nanni, S. Salza, and M. Terranova. LOA: the LOGIDATA+ Object Algebra. Technical Report 5/23, Progetto Finalizzato Sistemi Informatici e Calcolo Parallelo, 1990. 24. U. Nanni, S. Salza, and M. Terranova. An Algebraic Approach to the Manipulation of Complex Objects. Proceeding Hawaii International Conference on System Sciences, Kaloa, Hawaii, January 7-10, 1992. 25. U. Nanni, S. Salza, and M. Terranova. The LOGIDATA+ Prototype System. In this volume. 26. M. A. Roth, H. F. Korth, and A. Silberschatz. Extended Algebra and Calculus for Nested Relational Databases. ACM Trans. on Database Syst., 13 (4), 389417, December 1988.

210

27. H.-J. Schek and M.H. SchoU. The relational model with relation-valued attributes, ln]ormation Systems, 1986. 28. M.H. Scholl and H.-J. Schek. A relational object model. Proceedings International Conference on Data Base Theory, Paris, Lecture Notes in Computer Science, 470, 89-105, 1990. 29. J. D. Ullman. Database and Knowledge-Base Systems (voi. I). Computer Science Press, 1988.

The LOGIDATA+ Prototype System Umberto Nanni 1, Silvio Salza u,3, Mario Terranova 3 I Universit?* de L'Aquila, Dipartimento di Matematica Pura ed Applicata, Coppito, L'Aquila, Italy Universitg di Roma "La Sapienza', Dipartimento di Informatica e Sistemistica, via Salaria 113, 1-00198 Roma, Italy 3 Consiglio Nazionale delle Ricerche, Istituto di Analisi dei Sistemi ed Informatica, viale Manzoni 30, 1-00185 Roma, Italy A b s t r a c t . In this paper we present a prototype system based on the LOGIDATA+ model, hence supporting a rule based language on a data model with structured data types, object identity and sharing. The system has an interactive user interface, with a units interaction composed by LOGIDATA+ programs, that can extract information from the knowledge base and/or modify the schema. A program consists of a set of rules written in the LOGIDATA+ language, and of additional directives to handle the data output and/or updates to the schema. The intermediate results and the updates to the schema, affect a temporary working environment connected to the working session, but can also be saved in a (user or global) permanent environment. The system uses LOA (LOGIDATA+ Object Algebra) as an intermediate internal language. User programs are compiled, with a set of transformations that includes rewriting and stratification, and then translated into LOA programs, i.e. sequences of fixpoint systems of algebraic equations. The object oriented schema is mapped into a relational schema, and the database is actually managed by a relational DBMS, that provides the basic support for the permanent storage of data as well as for concurrency control and recovery. The object algebra expressions can then be mapped into relational algebra expressions, thus relying on the efficiency of the RDBMS for the access to mass storage structures and the efficient execution of set-oriented operations. Moreover a main memory database has been included in the architecture, to improve the performance in the evaluation of the fixpoint systems, by keeping in main memory the intermediate results.

1

Introduction

This paper presents the architecture of the L O G I D A T A + prototype system, an experimental object oriented database management system, developed within the L O G I D A T A + project. The primary goal of the prototype was to implement the main ideas in the data model [3] and the language, but a good deal of effort has been devoted to study several important problems connected to the efficient implementation of object oriented systems, and to analyze the various solutions in terms of cost and performance. This has led to a modular architecture, in the sense that each module is connected to a different topic, that had been the object of research activity during

212

the project: The first issue is the persistent storage of complex objects, and has been studied in terms of access cost, and processing cost of transactions. Other interesting problems are connected to the language interface, like rewriting of rule based programs in a context with structured data types, and dynamic management of temporary environments. Finally a crucial issue is how to perform efficiently the computation of the least fixed point on large mass memory sets of data. A main implementation choice has been to utilize an existing, commercial, relational DBMS, to implement the persistent storage of the objects, instead of building the prototype on a file system with variable length records, like it has been done for example in O~ [5]. Our choice has several motivations. First, of course, feasibility and ease of implementation. But, beside this, it can be claimed that such choice is rather reasonable also in terms of performance, at least for a large class of end user applications. These are all those applications that do not require as a basic operation the instantiation of complex objects. For instance, most business applications that already perform reasonably well on relational systems, but that could take great advantage in being designed and maintained in an object oriented framework. The architecture of the prototype system is presented in Figure 1. The diagram shows several layers in the architecture, which corresponds to the various phases of the transformation, and of the evaluation of LOGIDATA+ programs. The first layer corresponds to the language interface. The input language is the LOGIDATA+ language [4], and the output language is LOA (LOGIDATA+ Object Algebra), an algebra for complex objects developed within the project [17]. The programs are first transformed by using rewriting techniques, then stratified and translated into a sequence of blocks, each formed by a system of LOA equations. Evaluating a program requires to compute the least fixed point of these blocks. The second layer is composed by the schema managerand the relational mapper. The first module generates and manages the mapping between the object oriented schema and the relational schema, and the relational mapper translates the LOA equations into the relational algebra, according to that mapping. This requires a first level of optimization. The last layer corresponds to the fixpoint evaluation of the systems of relational algebraic equations. This is performed by the procedural code generator that produces a program written in a special internal code, and by the fixed point evaluator which finally executes the procedural program. The procedural code has primitives to perform relational operations both on relations stored in the Mass Storage DataBase (MSDB) managed by the RDBMS, and on temporary structures stored in the Main Memory Da~hbase (MMDB). This gives the way to efficiently carry on the fixed point computation, by maintaining in main memory the intermediate results, and requires a further level of optimization, to find the tradeoff between fast computation in main memory and moving data back and forth between MSDB e MMDB.

213 LANGUAGE INTERFACE

LOA / EQUATION/~/

~

TYPE ~DEFINITIONS

--~A~O--. i

l

,C--A

REELAuTIOoNNAL

~

I

OBJECT

~' ~

RELcAHT/ONAL

RDBMS

MAIN MEMORY DATABASE

Fig. 1. The LOGIDATA+ Prototype Architecture

214

The paper is organized as follows. In the next Section we present the language interface, and discuss the process of rewriting the rule-based programs and translating them into the object algebra. Next in Section 3 we show how to map the object schema into a relational schema. Sections 4 and 5, present the lower part of the architecture, and discuss how to optimize the least fixed point computation. Finally Section 6 deals with the translation and the optimization of an important class of object oriented queries.

2

The

language

interface

This section is devoted to the description of the language interface of our prototype which provides an interactive environment where the user can execute a sequence of LOGIDATA§ programs. Each program may simply consist of a query to be answered, or may have side effects on both the schema or the data, or, in general, it might consist of any combination of these basic functions. Side effects affect the behavior of the system either in the current working section, or permanently, as required by the user, who is given an explicit control over the evolution of the working environment, that is the collection of intensional and extensional data which are considered in the evaluation of the programs in the current working section. A remarkable example of an explicit control over the evolution of data and/or metadata is shown in [7]. In the current state of the implementation, a program may include negation in the body with the additional constraint to be stratified. When intensional predicates are to be instantiated a stratified semantics is used [10]. This might be later generalized to an inflationary semantics [11], which can be applied to a wider class of programs and is strictly more expressive [2, 9]. The choice of an inflationary semantics received further legitimation in [13]. Nevertheless, while dealing with a complex data model (based on object identity), this approach does not guarantee that the evaluation of the program terminates, as shown in [1]. The unit of interaction with the object base is a LOGIDATA program, consisting in a set of rules, plus a set of (possibly implicit) directives to direct the output and to handle the evolution of the environment. These include the specification of what among the new classes or relationship defined within the program has to be instantiated or what intensional or extensional data are to be made permanent, thus affecting what is called the permanent environment. More precisely, in the middle of a working section, both the LOGIDATA schema and database can be thought to be partitioned into a permanent environment and a working (temporary) one. The latter in general contains references to the permanent environment and is affected by the side effects of the programs. The user can make permanent a consistent set of data and/or metadata, with the constraint that no permanent d a t a / m e t a d a t a can refer to what is contained in the working environment. What is initially a set of rules in a program is transformed, through the evaluation process, in a set of LOA equations that eventually will be interpreted

215

as a sequence of assignment statements. In any case any equation (or rule) has a left side (head) which is the name of a predicate to be defined, and a right hand side (body) that will be successively transformed until it becomes a LOA expression. Of course several rules with the same head will produce a single assignment statement, as shown later. A user program may refer to extensional predicates, corresponding to classes or relationships having associated collections of data in the extensional data base, and to intentional predicates which are defined by means of rules. The definition of an intensional predicate may appear either within the program itself, or in the schema (in either the working or the permanent environment). These are called views, by analogy with the standard database terminology. An additional constraint, analogously to the one common in the relational model, is the safety of the rules. A variable x which, appear as argument in a built-in predicate (such as an arithmetic comparison) must have a bounded domain. If x appears in the same rule as argument of a non negated intensional or extensional predicate, it has a bounded domain. Otherwise in the rule there must be a chain of equality predicates imposing that x is equal to another variable y having a bounded domain. The main modules in the language interface are the following: - the LOGIDATA compiler takes user programs as input, applies possible rewriting techniques, and generates a set of rectified rules; - the separator individuates the part of the program concerning addressing of output and management of the object schema, excluding them from being processed together with the declarative part of the program; - the view handler individuates the predicates used in the program corresponding to views in the schema, and includes the rules defining them inside the program itself: the resulting program refers only to predicates defined therein or to extensional predicates; - the stratifier/sequencer finds outs the stratification of the program according standard techniques and individuates the inherent sequential structure of the program (if any) providing a fragmentation of the program in a sequence of

blocks; The external processing of user programs in our prototype is now drawn in more detail. The compiler, which is not extensively described in this paper, performs a first scanning of the program and applies rewriting techniques to the source LOGIDATA+ program. Furthermore in this first phase the rules are rectified [20], in the sense that a renaming of variables with possible substitution of constants within each rule is performed, so that any rule with the same head has exactly the same sequence of variables as arguments. The separator module can be considered a part of the compiler and simply separates the part of the program consisting in primitives to direct output and/or handling the environment. The view handler is in charge to include in the program the rules defining the predicates corresponding to the view-predicates. One of the functions of the

216

schema handler is in fact to store such intensional definitions in "compiled" form. Of course this mechanism to describe views by means of rules (with possible negation) is strictly more powerful than a purely algebraic description (i.e. not using operators to handle recursion). The stratifier/sequencer, as remarked before, operates in a standard fashion (as described, for example, in [20, 8]). In particular it builds the dependency graph which will be used to find the stratification of the negation, thus giving a partial ordering among the rules according the strata. Actually the sequencer individuates the strongly connected components of the dependency graph, finding out the inherent sequential structure of the program. In general an overall sequential structure arises when there are portions of the program which are not mutually recursive. As an example, if a program P uses a view-predicate V, in the dependency graph the connected component containing the node V (included by the view handler) has no edge coming from nodes corresponding to intensional predicates defined within the program (note that the program can not redefine some predicate which the view V is defined on). This means that the predicates corresponding to the nodes in that connected component might be instantiated before the rest of the program. A simple syntactical transformation of the rules converts them into algebraic form, and furthermore all the rules with the same head are grouped to give raise to a single LOA equation. Any LOA equation has a form V = g, where V is the name of the variable/predicate being defined, and E is a LOA ezpression (whose evaluation will be described in the following sections). Moreover V corresponds to a node in the dependency graph, namely to the node with the same name. The other nodes in the dependency graph, by virtue of the view handler, can only be nodes corresponding to extensional predicates. The stratifier/sequencer is in charge to perform a fragmentation of the program into a sequence of blocks, each of them corresponding to a strongly connected component of the dependency graph. Each block consists of either a single LOA equation or a fizpoint blocks. Any fixpoint block will be interpreted as a F I X P O I N T operator applied to the set of equations it includes. The total ordering of the blocks in the resulting sequence must fillfill the constraint that any equation is not allowed to refer to variables/predicates which are defined in the following blocks. Note that if the program is stratified, in the dependency graph a negated arc can not occur within a strongly connected component. This means that if a fixpoint block will include rules with negation in the body, the negated predicates either are defined in a previous blocks, or are extensional. The resulting sequence of blocks is what we call a LOA program. The language interface also manages the working and permanent environments as described above, allowing a reasonable context to work interactively. In more detail, the schema manager will be able to support a hierarchy of environments, according the following behavior, which resembles the behavior of interactive systems in very different contexts. The LOGIDATA schema (and database) has to be considered partitioned in environments. An environment A

217

is based on the environment B if the ( m e t a ) d a t a contained in A are allowed to refer d a t a in B. The constraint is that this relationship defines a partial order among environments. As an example, suppose that G is a single global environment which is permanent. Then several environment U1, U 2 , . . . , UN based on G can be defined. Each Ui may correspond to a user, or a group of users, and contains the customized permanent data, such as views. At any time an interactive user logs into the system, a new e m p t y working environment is built. In this manner the side effects of user programs affects only the working environment, and are reflected in the subsequent programs only within the current working session. At any time the user may ask to make permanent a consistent portion of the working environment. This is allowed by the schema manager only if the portion of the environment to be transferred does not contain references to the working environment. Given the definition of a LOGIDATA schema, is not difficult to implement primitives which, for example, allow the user to require a view V defined during the current working section to become permanent together with any other things in the working environment which C is based on. Of course this management results effective also in the case that many users are simultaneously using the system. The support of a DBMS with built-in locking features on data will result usefill in the implementation of these features in the prototype. The hierarchy of enviromnents is only visible to the schema manager, that provides the mapping from any variable/predicate referred in a particular environment to a unique collection of data (class or relation), or to a view within the schema.

3

Mapping Objects into Relations

For sake of simplicity in this and the following sections we shall refer to a data model, which is a simplified version of the L O G I D A T A + model, with tuple and set constructors and object identity. The model actually contains the relevant aspects of most object oriented models. Therefore the results we present in the paper can be easily extended to a more general framework. More formally given a finite set of domains D 1 , . . . , D D with domain names D 1 , . . . , D D , a countable domain of object identifiers ~, and a countable set of attribute names .,41,.A2,..., we refer to an object schema 0 composed by the following elements: - A finite set of types names, or shortly types, 01,..., 0o, and the corresponding

type definitions. - A finite set of classes C 1 , . . . , C c

with names C l , . . . , C c .

The domain /? contains the object identifiers associated to the objects, that are unique in all the database. The classes are collections of objects of the same type. T y p e definitions allow to build structured types from the basic types associated to the domains, and, for object types, to add the identity. A value set, i.e. the set of all possible values, is associated to each type:

218

- A type 0 is either a value type r or an object type w. - Each domain name 19i is a value type (called base type), and the corresponding value set is Di 9 If 8 1 , . . . , a,~ are types with value sets V l , . . . , V,~, then r = (A1 : 81, . . . , A , : 8n) defines a tuple type r, with value set V r = V1 x ... • Round brackets denote the tuple constructor. - If 8 is a tuple type ;and V is the corresponding value set then r = {0} defines a set type r with value set V r = PART(V), i.e. the powerset of V. Curly brackets denote the set constructor. - If r is a tuple value type with value set V, and C is a class name, then w = [C, r] is an object type, and the corresponding value set is V~ = / 2 x V. -

Note that we require a tuple constructor inside each set constructor. This, as we shall see later, is to have a more direct representation of the schema into the relational model. For similar reasons we assume that tuple constructors cannot be directly nested. Both assumptions do not produce any loss generality. According to our definitions each class corresponds to an object type. Furthermore, if wl and w2 are objects types, and w2 appears in the definition o f ~ l , we say that w2 is part-of wl. The structure of the objects in the schema can be effectively represented by the object graph. The graph contains a node for every type in the schema that has a tuple constructor at the outermost level. The nodes corresponding to object types are called class nodes. The nodes are connected by two different types of arcs. The set links and the old links. The former represent a set constructor, and the latter a part-of relationship. The definition of a sample object schema and the corresponding object graph are presented in Figures 2 and 3. In the figure solid lines represent set-links and dashed lines represent old-links. Note that the graph only represents the nested structure of the objects, and the part-of relations between the classes. Attributes of base type are not explicitly represented. The graph may be cyclic if recursive type definitions are allowed. We now address the problem of mapping the object oriented schema with a relational schema. This obtained through a transformation Oc, that generates a normalized relational schema S c that we callcanonical schema, defined as follows: - There is a relation Ri in S c for each node ni in the object graph. If (a/l, a~, , ...., ak) i is the tuple constructor corresponding to the node, then the relation Ri has schema (b0,ba,b i i 9,. .... ,bD. Attributes in the canonical schema are either of base type, corresponding to base types in the object schema, or of oid type, or of link type. - If a~ is an attribute of base type the corresponding attribute b~ in P~ has the same type. - If ni is a class node, then R/ is called a c-relation and b~ has oid type (oid attribute), and is a key to the relation. -

219

Domains (base types): Char; S t r i n g ;

Integer.

Value types: rstud = (name : String, code : I n t e g e r , curriculum : rcurr, a t t e n d s : r a t t ) ; rteache r = (name : String, teaches : {rteaches}, h i s t o r y : {this}); r c l a s s e s = (course : String, room : String, time : Integer); Tcurr = ( c o u r s e : String, t e s t : { r t e s t } ) ; treat = (year : Integer, grade : Char); rat t = (schedule : Wclasses); rteache s = (schedule : O:classes); 7~nis = (course : String, year : Integer).

Object types: Wstud -----[Student, rstud]; Wteache r = [Teacher, ~teacher]; ":classes = [Classes, rclasses].;

Classes: Student; Teacher; Classes. Fig. 2. A sample object schema

I PERSON I

STUDENT

/

I

I

\

/

,,\ ~ TEST 3 Fig. 3. The object graph

d/"

CLASSES

I

TEACttER

\

I

220 If ni is a non-class node with a set link from attribute a~ of node nj, then the corresponding relation R/ is called a s-relation, and both b~ in Rj and b~ are of link type (link attributes). - If a~ is an attribute of object type, then b~ has oid type. -

The link attributes are introduced to represent the unnesting of set constructors. Similarly oid attributes are used to implement the object identity, and to represent the part-of relationship. According to these definitions we may map the Object Oriented DataBase (OODB) into a pure relational canonical database, in which in every c-relation there is a tuple for every object in the corresponding class, and for every srelation there is a tuple for every element of every set. The canonical schema for the OODB of Figure 2 is reported in Figure 4.

STUDENT(#student: Old, name: String, code: Integer, @curriculum: Link, @attends: Link); TEACHER(#teacher: Oid, name: String, @teaches: Link, @history: Link); CLASSES(#classes: Old, course: String, room: String, time: Integer); CURRICULUM(@curricultm: Link, code: Integer, @test: Link); TEST(@test: Link, year: Integer, grade: Char); ATTENDS(@attends: Link, schedule: 0id-CLASSES); TEACHES(@teaches: Link, schedule: Oid-CLASSES); HISTORY(@history: Link, course: String, year: Integer)

Fig. 4. The canonical schema

Note that all the information contained in the OODB is preserved in the canonical schema, and that a reverse transformation ~9~ 1 can be defined from Sc toO. Once we have defined the mapping (9c between the object schema and canonical schema, we may consider the problem of evaluating a query consisting of an expression L" of the object algebra. More precisely, computing ~' transforms the object schema O in a new schema O'. We then say that a set of relational expressions (El, E 2 , . . . , Ek) is equivalent to ~: according to the mapping 69c, if the canonical schema S c is transformed into a new schema S ' c , such that Z ' c corresponds to O' in the mapping (9c. It can be easily shown that El, E2, . . . , Ek can be computed for any •, and are expressions of the relational algebra, with the only addition of the old-invention if restructuring primitives are included in the object algebra, as proposed in [16]. The result of the original query can be obtained by applying the inverse transformation Oc 1. Therefore the set of fixpoint algebraic equations generated by the language interface can be computed on the canonical database, through the repeated

221

evaluation of relational expressions. We address the problem in more detail in the following section.

4

The

Procedural

Code

and the Fixed

Point

Evaluator

As we have shown in the previous sections, LOGIDATA+ programs are first translated into fixpoint blocks of object algebra equations, and then transformed, according to the canonical mapping, into fixpoint systems of relational algebraic equations. To perform the evaluation the Code generator generates a procedural program, written in an internal code, that is later executed by the Fixed Point Evaluator. Non recursive equations are directly translated into relational queries and the computation is performed by the mass memory RDBMS. We will discuss how to optimize this step in Section 6. In this section we address the problem of the efficient evaluation of sets of mutually recursive equations. The least fixed point is computed with the semi-naive algorithm [6]. This algorithm notably solves by iteration a system of algebraic equations. For every unknown relation in the system two relations are maintained during the computation. The first one, called differential relation, contains the tuples produced during the current iteration, and the second one, the integral relation, cumulates all the tuples produced by the previous iterations. Only the new tuples are used in the next iteration. The computation terminates when no new tuples have been produced during the last iteration. More specifically the system of equations generated by the Relational Mapper has the form:

Ri = E ~ Ri = E i ( R , , . . . , R ~ , B 1 , . . . , B k ) ,

i=

1,...,m

(1)

.

i=l,...,m

.

(2)

where the /~ are the unknown relations to be computed, B 1 , . . . , B~ the base relations of the canonical database involved in the computation, and the first set of equations define the base values for the Pq. The Ei and E ~ are expressions of the relational algebra. Referring to this system the schema of the semi-naive evaluation is given in Figure 5. The first two group of steps (al . . . . ,a,n and b l , . . . , bin) are executed only once to initialize the integral and differential relations; the remaining steps are iterated until the integral relations stabilize. More specifically steps (cl, ..., cm) incrementally compute the new tuples, using the expressions OEi, that are the derivatives of the Ei. The last two groups of steps (dl, 999 dm and e l , . . . ,era) perform a peculiar union-difference operation between the integral relations and the corresponding differential relations. That is the new tuples are added to the integral relations and the old tuples are deleted from the differential relations.

222

am : R., ~ 0 bl : c~R1 *-- E ~

bin: OR~ ,- E~

Bk)

cl : OR1 *-- O E I ( R 1 , . . . , R m , ~ g R 1 , . . . , O R m , B 1 , . . . , B k ) l c,~ : ~gR m ~ O E ~ ( R 1 , . . . , R,,~ , (gR 1 , . . . , (gR,~ , B 1 , . . . , B k ) d l : 01~1 ..- OR1 - (R1 n O R 1 )

am : O R m ~ O R ~ - ( R m n O R m ) e l : R1 ~ R 1 U OR1

em: Rm ~ Rm U CgRm

Fig. 5. Semi-naive evaluation of a fixpoint block

Hence the semi-naive evaluation requires to maintain several, rapidly evolving intermediate relations, and the repeated executions of relational operations, some efficiently supported by the RDBMS (like Join and Select), and some not, like the union-difference performed at the end of each iteration. For these reasons the architecture of the prototype system includes the Main Memory Database (MMDB), and specific primitives have been defined in the instruction set of the procedural code. The MMDB provides for the storage of the intermediate relations, their access structures, and for the efficient execution in main memory of the relational operations. Different physical structures are provided for the integral and differeatial relations. Both are sorted, but the latter are managed as a simple list in main memory, while the former ones are organized in some kind of paged structure that allows, if needed, a partial overflow to mass memory. As for the index structures in main memory, the problem has been thoroughly investigated in [14] and [15]. According to this analysis, and taking into account that in our application the relations are highly dynamical, we adopted the B*-tree, which makes a reasonable tradeoff between the access cost and the memory cost. The size of the blocks was chosen in order to allow, if needed, an easy overflow of the index to mass memory. When this happens, the blocks are

223

gradually paged out and managed with a LRU policy. The procedural code is generated in such a way that indices are always maintained on the join attributes. If there is an index only on one attribute (which is usually the case), the relations are sorted and the join is performed through a merge in linear time. Otherwise a nested loop is used. More specifically the procedural code provides three classes of primitives: -

The MMDB Primitives allow to create the temporary relations and the corresponding access structures, and to execute in main memory some relational operations: -

--

-

CREATE: creates a new relation with a given schema in the MMDB or in the Mass Storage Database (MSDB), and sets up indexes on the specified attributes (or groups of attributes). It has to be specified if the relation is an integral or a differential one, since, as we will see later, different physical representations are used. coPY: performs a copy on the specified relation. This is used to initialize the temporary relations. PROJECT: performs a projection on a temporary relation. The result is stored too in the MMDB. JOIN: performs a join. Both the operands and the result are in the MMDB. SWAP:performs the union-difference operation, needed in the semi-naive evaluation. The operands are an integral relation and the corresponding differential relation. The swAP adds to the integral relation the new tuples, and deletes from the differential relation the old tuples.

- The Communication Primitives allow to move the relations between the MMDB and the MSDB, to print the result of a query, and to request the RDBMS to execute a subquery: --

--

-

LOAD:moves an extensional relation to the MMDB. STORE: moves a temporary relation from the MMDB to the MSDB. EXTRACT: requests the RDBMS to compute a SQL query and to move the result to the MMDB. EXECUTE: requests the RDBMS to compute a SQL query, and to keep the result in mass memory for further computation.

- The Control Primitives allow to express the iterative computation that, as we have seen earlier, is required by the semi-naive evaluation: begins a block of procedural code that has to be iterated until some specified integral relations stabilize. marks the end of a fixpoint loop. HALT:stops the computation.

--

F

I

--

E

N

--

X

D

P

F

O

I

I

N

X

:

T

:

As an example let us consider the very simple system, that defines the transitive closure of a relation P: A($1, $2) = a$2=~P($1, $2) .

(3)

224

A($1, $2)

=

A($1, $2) O A($1, $2) re,l=,2 P($1, $2) .

(4)

which corresponds to the semi-naive computation: al: A($1,$2) *-- 0 bm: 0A($1, $2) ~ a$2=aP($1, $2) cl: 0A($1, $2) *- 0A($1, $2) N,1=,2 P($1, $2) dl: OA($1, $2) *-- 0A($1, $2) - (A($1, $2) n 0A($1, $2)) e l : A($1, $2) *-- A($1, $2) U 0A($1, $2) The corresponding procedural code is given in Figure 6. Note that the computation is partially performed in main memory. The interaction with the RDBMS is limited to lines 8 and 9. At every iteration the new tuples in the relation DELTA-A are stored in the MSDB (line 8), and then the RDBMS is requested to compute a semijoin and to move the result to the MMDB (line 9). At the end of the iteration the integral relations are updated, and only the new tuples are left in the differential relations (line 10).

01: CREATE~ A($1:CHAR(12),$2:CHAR(12)) INDEX ($1,$2) 02: CREATENN DELTA-A($1:CHAR(12),$2:CHAR(12)) 03: CREATENN XI($1:CHAR(12)) 04: CREATEMS X2($1:CHAR(12)) 05: EXTRACTDELTA-A($1,$2) SOL(SELECTP.$1, P.$2 FROM P

WHEREP.$2 = "a") 06: FIXPOINT DELTA-A 07: PROJECT X1($1) FROMDELTA-A($1,$2) 08: STORE X1($1) INTO X2($1) 09: EXTRACTDELTA-A($1,$2) SOL(SELECTP.$1, P.$2 FROM P, X2 WHEREP.$2 = Xl.$1) I0: SWAP DELTA-A, A 11: ENDFIX

Fig. 6. Procedural code for the semi-naive evaluation of Figure 5

5

Optimizing the Fixed Point Computation

An optimization phase is provided to generate a procedural code that exploits the different options available in the architecture, to perform the computation either directly in main memory, or in mass storage through the RDBMS. As we

225

already pointed out, this is especially interesting in the semi-naive evaluation of recursive sets of equations. Basically there are three different options in performing the semi-naive evaluation: -

-

-

Mass Storage Evaluation. All the relational operations are performed on the

MSDB through the EXECUTE command, and all the intermediate are stored in the MSDB too. Tight Coupling. Most of the computation takes place in the MMDB. Repeated interaction with the RDBMS takes place at each iteration, when, using the STORE and EXTRACT commands, the differential relations are moved to the MSDB, to perform a semijoin and bring back the result to the MMDB for the next iteration. Loose Coupling. All the extensional relations involved in the query are initially moved to the MMDB where all the computation takes place.

The first option proves to be valuable only in extreme situations, when both the base relations and the intermediate results have a very large size. Actually the RDBMS is especially designed to handle efficiently such cases. In other situations this choice is not reasonable because of the overhead in the RDBMS, and of the inefficiency of the union and difference operations, that instead are integrated and efficiently performed by the swAP command in the MMDB. Normally the optimizer must choose between the remaining two options, i.e. tight and loose coupling, and decide which extensional relations are to be entirely loaded. This is done by estimating and comparing, on one side the I/O cost connected to all the accesses to the mass storage relations needed to perform the semijoins when working in tight coupling mode, and on the other side the cost of loading the whole relations. In the latter case all the blocks of the relation are accessed, but sequentially. The problem then becomes that of estimating the number of iterations in the seminaive evaluation, and the number of tuples of a given extensional relation that are accessed at each iteration. To see how this can be done, let us consider a binary relation with both the attributes on the same domain, and represent it as a graph where the nodes are the values in the domain, and the arcs represent the tuples of the relation (Figure 7). Using an approach similar to the one introduced in [6], we make the assumption that the graph is layered, with h layers, and define ~gp and 69c as the average number of arcs respectively entering and leaving a node. In our example the average number of parents and children for every individual. These parameters can then be estimated from the following values, that, in turn, can be easily extracted from the MSDB catalog: -

N : number of tuples in the relation. Np: number of distinct values assumed by the first attribute. No: number of distinct values assumed by the second attribute. Npc: number of values common to both attributes.

226

bh.1 4

Q

/

P

@

Q

0 @ 0

/

\

I

\ I

/

,

\

0p

/

\

\

/ /

!

\

#

S

S

S

g

4

I

@ 9 D

b0 Fig. 7. The relation graph

In fact, according to the definition of Op and Oe: N o,,=~

N eo=~.

(~1

Assuming a regularstructure in the graph, the shape of the graph can be deduced from the values of Op and Oc. We have two cases: - O v = Oc. In this case we assume for the graph a rectangular shape. The number of layers h and the number of nodes b can then be expressed as:

-

b = N~ - N ~ o .

(6)

h = 1+ [b-~ 1

(7)

Op # Oc. In this case we assume for the graph a trapezoidal shape, and express accordingly h and the the number bi of nodes in layer i. For instance, if Op < Oc, and referring to Figure 7: b0=

Nc-Npc

bh-l=Np-Npc

(8)

.

.

(9)

227

h = 1+

f

log

(10)

To give an example of how this can lead to practical results, let us refer to the procedural code in Figure 6, and show how to compute an upper bound to the number of accesses performed in the MSDB to the relation A at each iteration of the EXTRACT at line 09. To get the upper bound we take the node corresponding to the constant in the query (i.e. a) in the layer 0 of the graph. This is, of course, the worst case, and r e q u i r e s h - 1 iterations. During the computation, iteration i passes from a subset AZ/_I of the nodes of the layer / - 1 to the subset of the nodes of layer / that are connected to the nodes in Af/-1. Now, if we assume that the nodes are randomly connected, and if we call ni the cardinality of Af/, i t c a n be proved that:

:

{i

b,(1-

1

i= x,...,h-

1

Then the number of tuples ti accessed in the base relation in iteration i is given by:

ti = [•pni-,]

i= 1,...,h-

1 .

(12)

The actual number of I/O accesses needed at each iteration can then be computed by using the well known formula of Yao [21]. 6

Object

Selection

Queries

In this section we discuss the issues connected to the translation of non-recursive object oriented queries into relational queries. The results extend of course also to the translation of the algebraic expressions which are part of fixpoint blocks. To discuss the problem we restrict to a specific class of queries, that consist in extracting from a class the set of objects that satisfy a given condition. We shall call these object selection queries, and we will see in a while that these queries are far more powerful than a relational selection. In order to define conditions on structured objects, we first introduce, referring to an instance of the OODB, the notion of value tree of an object. - The node of the tree are of four different types: tuple, set, oid and value; these represent respectively the constructors in the type of the object, the oid of the object and subobjects, and the base values. - The root of the tree is a node of type old, and has only one child of type tuple, which represent the outermost constructor in the object type. - Each node of type tuple has one child for every attribute in the corresponding constructor; if the attribute is of base type, the node is a leaf and represents the value of the attribute; if the attribute is of object type the node represents the oid of the subobject; if the attribute is of set type the node is of set type.

228

- Each node of set type has one child for every element in the corresponding set. - Each node of old type is the root of the value tree of the corresponding object. Note that even in the case of recursive type definition the value of an object is still represented by a tree. In such cases the tree may become infinite, but this is not a problem since, as we shall see in a while, we only need to consider a finite portion of it. Referring to the object schema in Figure 2, a sample value tree of an object of the class S T U D E N T is represented in Figure 8. The purpose of the vahie tree is to expand the set constructors, explicitly representing all the combinations of values in the object. Let us now consider the atomic values in the tree, i.e. the base values in the leaves, and the old in the oid nodes. Each of these atomic values is characterized by a value path, defined as the sequence of attributes traversed in the tree by the path from the root to the node. We may then define an atomic condition, by associating it to a value path, and say that the condition is satisfied by any atomic value on the value tree that has that path. For instance referring to the value tree of Figure 8 the atomic condition: STUDENT.curriculum.test.year

= 1990

is satisfied by two different atomic values. To set up more complex conditions, i.e boolean expressions built on atomic conditions, we need then to allow distinction between atomic values belonging to different elements of the same set. To do so, we introduce the notion of instance tree, defined as a subtree of the value tree, in which for every set node only one child, if any, is retained. We then say that an object satisfies a condition if and only if it exists for that object an instance tree that satisfies the condition, and that a selection query Q(C; B), on the class C selects all the objects in C that satisfy the condition B. For instance considering the object selection query:

Ql:(STUDENT;STUDENT.curriculum.course ='MATH1' A STUDENT.curriculum.test.grade =' A' A STUDENT.curriculum.test.year= 1990) we see that the object of Figure 8 is not selected by the query, although each atomic condition is satisfied by an atomic value in the value tree. Instead the query: 02 : (STUDENT;STUDENT.curriculum.course ----'MATH1 ~ A STUDENT.curriculum.test.grade =' A' A STUDENT.attends.course ----'MATH2')

229

ISTUDENT ]

1991

A

Fig. 8. The value tree

selects the object, since the condition is satisfied by the instance tree of Figure 9. According to what we have seen in Section 3 an object selection query can be readily translated into a a relational query on the canonical schema. The resulting relational expression is in general quite complex, and its optimization is a crucial problem. This is because evaluating conditions on objects with complex nested structure, may require to perform a large number of joins, mostly on the link attributes introduced by the mapping of the schema. To discuss the optimization strategy we focus on a sub-class of the selection queries, the sd-queries in which the condition/3 is decomposable, i.e. has conjunctive form B = B1/~/32 A . . . / ~ Bk, and each Bi contains only atomic conditions on the attributes of a single tuple constructor. For these queries the optimization problem has a very clean fornmlation, since they can be translated into relational SPJ queries, consisting in a series of selections on the base relations of the canonical schema, followed by a chain of joins on link attributes. As an example Figure 10 shows the relational query tree for query q2. In most RDBMs, such lnultijoin queries are usually computed with a nested loop algorithm, provided that indices are maintained on all the join attributes. This avoids the materialization of the intermediate results, and exploits the

230

I ......./ /

S'l'r~l)EN'r I sToea2 I

"'""

] cu.'iculum

..."

",;..

\

o.o.~.ooo~ i()i y.....~, coume ..." 1r PHY8

me MATH1

~()i year/ ... lg90

year/

'...grade .. 0

llt~ y~ 199'

~ A18

3

CL.008 ~.....r....:-.....~:-: ~ e

/" ', ,..'room"

CHEM

~r C2

"- tlme

"~

1

o.o.oJf..o., i:..(,.y.......t )i

,.~176176176176176176 {

"test ,...#L...~ i l I i /

MATH2

\grade B

de

nA

Fig. 9. The instance tree

selectivity of the select and the join conditions. In our case, at least for the sdqueries, this strategy fits very well, since all the joins are performed on the link and oid attributes, and it is very reasonable to keep an index on each link and oid attribute. The optimization of the nested loop computation of the multijoin queries has been given a good deal of attention in the literature. The basic problem is the ordering of the joins to maximize the selectivity along the query tree, and hence to minimize the number of page fetches. The problem is NP-complete, and therefore intractable for large number of joins. Nevertheless some reasonably efficient heuristic algorithms have been proposed [12, 19]. In our case the cost model can be easily defined, since the joins are on link attributes. Hence estimates of their extensional and statistical parameters, such as originality and multiplicity, can be computed from a user supplied quantitative characterization of the object schema, e.g. average cardinality of the set attributes etc. This kind of approach is particularly meaningful in the case of precompiled queries. Moreover in a context of predefined transactions we may consider another level of optimization, based on the idea of improving the execution cost by

231

ourse-'MATH2'

~

,

~ STUDENT

_ CLASSES

,

ATTENDS

CURRICULUM

F i g . 10. The relational query tree

means of transformations oil the canonical schema. These consist in precomputing some of the joins on the link attributes. This leads to consider all the class of admissible schemata, where the optimal schema for a given workload, is the one with the best tradeoff between the increase in access cost due to larger relations, and the saving connected to prejoins. These issues are discussed in [18] , where a detailed cost model is presented, and the applicability of some heuristics is analyzed.

References 1. S. Abiteboul and P. Kanellakis. Object identity as a query language primitive. In ACM SIGMOD International Con]. on Management o] Data, pages 159-173, 1989. 2. S. Abiteboul and V. Vianu. Procedural and declarative database update languages. In Seventh AUM SIGACT-SIGMOD-SIGART Syrup. on Principles of Database Systems, 1988. 3. P. Atzeni, F. Cacace, S. Ceri, and L. Tanca. The LOGIDATA+ model. Rapporto LOGIDATA+ 5/20, Progetto Finallizzato Sistemi Informatici e Calcolo Parallelo, 1990.

232

4. P. Atzeni and L. Tanca. The LOGIDATA+ Rule Language. Rapporto LOGIDATA+, Politecnico di Milano e IASI-CNR, Roma, 1990. Presented at the Workshop "Information Systems '90", Kiev. 5. F. Bancilhon et al. The design and implementation of 02 an object-oriented database system. In Advances in Object-Oriented Database Systems, Proc. Second Int. Workshop on Object-Oriented Database Syst., K. Dittrieh, Ed., Bad Munster, FRG, 1988. 6. F. Bancilhon and R. Ramakrishnan. An amateur's introduction to recursive query processing strategies. In ACM SIGMOD International Conf. on Management of Data, pages 16-52, 1986. 7. F. Cacace, S. Ceri, S. Crespi-Reghizzi, L. Tanca, and R. Zicari. Integrating object oriented data modelling with a rule-based programming paradigm. In ACM SIGMOD International Conf. on Management of Data, pages 225-236, 1990. 8. S. Ceri, G. Gottlob, and Tanca L. Logic Programming and Databases. SpringerVerlag, Berlin, 1990. 9. A.K. Chandra. Theory of database queries. In Seventh ACM SIGACT-SIGMODSIGART Symp. on Principles of Database Systems, pages 1-9, 1988. 10. A.K. Chandra and D. Harel. Horn clauses and generalization. Journal of Logic Programming, 2(1):320-340, 1985. 11. Y. Gurevich and S. Shelah. Fixed-point extensions of first-order logic. Annals of Pure and Applied Logic, 32:265-280, 1986. Also in Proceedings Int. Conf. on Foundations of Computer Science, pp. 346-353, 1985. 12. T. Ibaraki and T. Kameda. On the optimal nesting order for computing nrelational joins. ACM Trans. on Database Syst., 9(3):483-502, 1984. 13. P.G. Kolaitis and C. Papadimitriou. Why not negation by fixpoint. In Seventh A CM SIGA CT SIGMOD SIGART Syrup. on Principles of Database Systems, pages 231-239, 1988. 14. T. J. Lehman and M. 3. Carey. Query processing in main memory database management systems. In ACM SIGMOD International Conf. on Management of Data, 1986. 15. T. J. Lehman and M. J. Carey. A study of index structures for main memory database management systems. In Twelfth International Conference on Very Large Data Bases, Kyoto, pages 294-303, 1986. 16. U. Nanni, S. Salza, and M. Terranova. An algebraic approach to the manipulation of complex objects. In 25-th Hawaii International Conference on System Sciences, 1EEE Press, January 1992. 17. U. Nanni, S. Salza, and M. Terranova. LOA: the LOGIDATA+ Object Algebra. Technical Report 5/23, Progetto Finalizzato Sistemi Informatici e Calcolo Parallelo, 1990. 18. S. Salza and M. Terranova. Efficient Implementation of Object-oriented Databases on Relational Systems. Technical Report, IASI-CNR, 1991. 19. E.J. Shekita and M.J. Carey. A performance evaluation of pointer-based joins. In ACM SIGMOD International Conf. on Management of Data, pages 300-311, 1990. 20. J.D. Ullman. Principles of Database and Knowledge Base Systems. Volume 1, Computer Science Press, Potomac, Maryland, second edition, 1982. 21. S. B. Yao. Approximating block accesses in database organizations. Communications of the ACM, 20(4):260-261, 1977.

MOOD * A n A r c h i t e c t u r e for O b j e c t O r i e n t e d A c c e s s a R e l a t i o n a l D a t a B a s e **

to

Marco Lugli, Luca Nini 1 and Stefano Ceri 2 1 CICAIA, Universits degli Studi di Modena 2 Politecnico di Milano

A b s t r a c t . In this paper we describe MOOD, a system which may be used to easily and efficiently build C + + programs accessing a relational database. MOOD has its own data model, which is Object-Oriented, and supports object identity, generalization hierarchies, and object sharing; by processing schema definitions, the MOOD system builds a relational schema and a C + + Class Library that enable the interaction between a C + + programming environment and a conventional relational database. We associate a C + + class to each class in the MOOD schema. Methods of this class may be used to access, create or modify MOOD objects. In particular, MOOD primitives provide tools for expressing complex, set-oriented queries to extract objects by traversing the MOOD schema along semantics finks. These primitives generate SQL queries in order to extract relevant tuples and assign them to Cq-+ objects; the interface thus developed solves the impedence mismatch between C + + (recordoriented) and SQL (set-oriented). MOOD can be used as a low-level programming environment for building applications; in particular, it is currently considered as an environment for implementing the Logidata+ language.

1

Introduction

In recent years, the language C + + has emerged as a de-facto standard for the development of object-oriented applications. Object-orientation is in-fashion as a programming style, and indeed has been able to improve p r o g r a m m e r ' s productivity and the quality and reusability of software being produced. On the other hand, C + + is a programming language; as such, it lacks of several concepts for data management which exist in conventional databases, such as reliability, integrity, security, and support for shared access. Therefore, database m a n a g e m e n t is one of the difficult features in the development of object-oriented applications. * MOdena Object Database ** This work has been partially supported by CINECA, CICAIA - Universits degli Studi di Modena, and by Progetto Finalizzato Informatica e Calcolo Parallelo, Subproject LOGIDATA+

234

This difficulty is currently addressed by a number of competitive approaches. The revolutionary approach aims at the development of new object oriented languages with persistency; examples include systems like Orion, Gemstone, 02. The evolutionary approach aims at extending SQL, the de-facto standard for relational databases, incorporating a number of object-oriented features into it. None of these approach will probably bring to C + + programmers the environment that they would probably prefer, namely, a transparently persistent C++; and, on the other hand, such extension would probably be too powerful to be also effective. In this paper, we propose a third approach, where C + + programmers need to rely on current, conventional relational technology for database storage; however, the system that we propose, MOOD, takes the responsibility of generating both the database design and the methods for database access that would otherwise be programmed within the application. As such, MOOD can be considered as a low-level programming tool for interfacing object-oriented programming with the relational technology. In this interface, MOOD eliminates a significant source of conceptual difficulties and errors which was recently denoted as the "impedence mismatch" between record-oriented languages (such as C + + ) and set-oriented languages (such as SQL). This mismatch arises whenever a query to a relational system is used within a record-based language, and is commonly solved by depositing some of the resulting tuples into a few buffer records and then controlling, from the programmming language, a producer-consumer mapping, where new tuples are retrieved and deposited as soon as the old one have been used; these mechanisms are currently implemented by SQL c u r s o r s . One additional problem, which exists in the mapping between programming languages and relational queries, concerns the differences in data types between the language data structures and flat relations; to reduce type coercion, usually the language data structures are also flattened, but this reduces the effectiveness of programs. In this paper, we show how MOOD solves both the impedence and type mismatch problems. MOOD has its own data model, which is Object-Oriented, and supports object identity, generalization hierarchies, and object sharing; by processing schema definitions, the MOOD system builds a relational schema and a C + + Class Library that enables the interaction between a C + + programming environment and a conventional relational database. Since both relational data definitions and C + + class descriptions are generated by MOOD, there is no type mismatch problem. We associate a C + + class to each class in the MOOD schema. Methods of this class may be used to access, create or modify MOOD objects. In particular, MOOD primitives provide tools for expressing complex, set-oriented queries to extract objects by traversing the MOOD schema along semantics links. These primitives generate SQL queries in order to extract relevant tuples and assign them to C + + objects; the interface thus developed eases the impedence mismatch between C + + and SQL. In first place, the correspondence between meth-

235

ods and SQL queries is ensured by MOOD, that generates the correct SQL queries from high-level descriptions of methods. In second place, the methods which are generated by MOOD include primitives for the selective iteration through results, implementing a high-level cursor. Though this paper is focused on programs which interact heavily with relational data-bases, indeed MOOD is best suited to writing classical objectoriented applications, where the language C + + has proved to be most successful. MOOD, however, bridges these applications with some persistent stored data. Overall guideline of the project has been generality and portability; the use of commercially available products and languages ensures that this objective is met. 2

Data

Model

In this section, we describe the MOOD data model. 2.1

Rationale

Various research groups all over the world have concentrated their work in the study of new data models called object-oriented models. In these models, objects are grouped into Classes; each class has an associated set of Methods, which are the only applicable computations to the class. In general, objects of the same class have the same type. Common feature to these models is to support concepts which are lacking from the simpler relational model, such as:

- Object identity: each object has an intrinsic identity, which does not depend on the value of the object. Identity is usually provided by associating to each object a system-wide unique object identifier. Generalization hierarchies between classes: though a few alternative interpretations exist for them, the usual interpretation of partial orders between classes, say C1 < C2, is to say that the set of objects of class C1 (or: the extent of C1) is a subset of the set of objects of class C2, and that the type of T1 is a refinement of the type of T2. - Object Sharing: objects Call relate to each other with part-subpart relationships, and in particular each object can be shared by multiple other objects. -

In designing the MOOD data model, our goal was to choose the most commonly used and representative concepts of object-oriented data models, so that MOOD could be considered a general basis for the development of objectoriented applications. 2.2

Description

A MOOD database consists of a. set of classes. Classes are sets of objects having an unique object identifier (oid), which are not hidden to the users. Each class has associated a type. Class (type) names must be unique in the schema.

236

Classes and their types are defined through class definitions. Some class names useful for building other class definitions may have a forward declara-

tion. A class type is built from other types with a tuple constructor. Each of the types involved in a class definition must be one of the following: - A basic type provided by MOOD. Currently they are integer and string (fixed length strings). - A previosly declared class type. - A sequence of the above types. Sequences, however, are not used arbitrarily, as orthogonal type constructors. Thus, sequences allow to represent multivalued mappings (e.g., a person is mapped to multiple children and to multiple addresses), but not general complex, structured values (e.g. a the address above is a simple string, and not the thriple street, city, state). Each type in a class definition denotes a property of objects of the class. Properties have names. For example, name and age are properties of the class Persons. Properties corresponding to basic types are given values compatible with those types. Properties corresponding to classes assume as values either the oids of existing objects in the referred class, or the nil value. Class valued properties model part_of associations. We distinguish between a direct and inverse sides. Inverses are always explicit: whenever class A refers to class B through attribute x, then class B must have an attribute y denoting the inverse relation. This is declared with a specific syntactic construct. The user should be aware of the fact that inverse associations are traversed less effectively; he is offered the option of modelling a single part_of association through two independent associations, with an opposite choice of direct and inverse link, but then must also preserve the correctness of these redundant associations when they are manipulated by programs. Class hierarchies are supported in MOOD. Given two classes A and B such that B is a subclass of A (A isa B), then: - Objects belonging to class B have the same properties of those in A, optionally extended by others. - Each object of B is also an object of A, i.e. it may be used wherever an object of class A is used.

2.3

Syntax

Figure 2.3 contains the context-free grammar of the MOOD DDL. Items enclosed in curly brackets may be repeated zero or more times. Multiple rules for the same non terminal correspond to alternative productions. Figure 2.3 describes the schema declaration in MOOD for a classical PersonStudent-Department database. Note that, in view of the definition in Fig. 2.3, each person may direct multiple departments while each department has a single director; students are specific persons with codes and sequence of grades.

237

MoodSchema ~ ClassDescription { ClassDescription } ClassDescription --~ c l a s s class_name : f o r w a r d ; ClassDescription --. c l a s s class_name ( property_name : T y p e { , property_name : T y p e }

); ClassDescription ~ c l a s s class_name i s a superclass_name ( property_name : Type { , property_name : Type }

); T y p e ---* BaseType T y p e --~ s e q u e n c e BaseType BaseType BaseType BaseType BaseType

--* --* ~ ~

int char(n)

class_name class_name i n v e r s e o f class_name

F i g . 1. Grammar of MOOD Schema Definition Language c l a s s Person f o r w a r d ; c l a s s Department ( DepName: char(20), Director: Person

); c l a s s Person ( Name: char(20), Age: i n t , Directs: s e q u e n c e Department i n v e r s e o f Director

); c l a s s Student i s a Person ( Code: i n t , Grades: s e q u e n c e i n t

);

F i g . 2. Example of schema definition in MOOD.

238

3

Architecture

This section describes the use of the MOOD system in the context of the development of C + + applications. The general architecture of MOOD is illustrated in Fig. 3. The MOOD system is composed of three components: -

A compiler of the 1~IOOD schema definitions. The compiler checks definitions for consistency (in particular, verifies that all inverse relations are correctly specified) and then produces two outputs: 9 Source code for the C + + Class Library which includes C + + definitions for classes and methods derived by analyzing a MOOD schema. These create the Mood Application Library (MAL). 9 Source code containing SQL schema definitions required to build a relational database incorporating suitable relations to model the objects in the MOOD schema. - The (Mood Generic Library (MGL). It contains general MOOD primitives, whose use will be described in the next section. The Access Methods (AM) for accessing the DBMS; AMs are specialized for the specific sofware products being used for database access, and contain all non-portable software, which is thus localized, though stored within the MGL. Currently, two AMs are based on the ORACLE C interface and Informix, other AMs could be easily added.

-

The C + + schema generated the MOOD schema compiler is produced according to the following rules: 1. Each MOOD class Ca is represented with a C + + class with the same name. It is either a subclass of other C + + classes corresponding to MOOD superclasses of Ca, or a subclass or the predefined class Tuple. Each class Ca is also associated to an object of the predefined type Handle, called Ca-DB. The Handle is used for ;tccessing the database through low-level access methods. 2. Each property of type int, char(n), or sequence is represented with a method of the same name and type int, char[], or Sequence, respectively; Sequence is a predefined type with associated methods. 3. Each property of type Class type A is represented with a method returning a reference (pointer) to a C + + object of class A. Obviously we cannot represent an object-oriented MOOD schema in a relational schema with ~t one-to-one correspondence. The relational model lacks such features as inheritance, composite attributes, object identity, tuple-valued attributes, etc. The SQL schema produced by the MOOD schema compiler generates a normalized relational representation, built as it follows: 1. Each class of the MOOD schema is represented with a SQL relation having the same name. All SQL relations obtained this way have an attribute Old of type integer. 2. Each property of type int or char(n) is represented with an attribute of SQL type INTEGER or CHAR(n), respectively.

239

+ ..................

]

+

MOOD Schema

J

+ ..................

+

II MOOD Compile [[ ++====mm~m===§

II

II

C++ Compile II It + ..................

I

MAL

+ ..................

Sql Compile ~ Execution II II +

i +

+ ..................

+

i Relational DB

J

+ ..................

+ . . . . . . . . . . . . . . . . . .

+

+

+ . . . . . . . . . . . . . . . . . .

f User C++ Program J i + ..................

+

li il II

M(]L / AM

+ ..................

+

i +

il II il

If c++ Compile & Link II + . . . . . . . . . . . . . . . . . .

+

JExecutable Program i + . . . . . . . . . . . . . . . . . .

+

Fig. 3. Software Architecture for using MOOD.

3. Each direct property of typ~ Class is represented with the Old of the corresponding object, physically stored as an attribute of type INTEGER. It will contain the value 0 if the associated Old is nil. 4. Each property of type seq/lence is represented using an additional relation to bring the schema in first normal form. Each relation has: (a) The Oid attribute of the relation it refers to. (b) An integer attribute Pos specifying the ordinal position of the value in the sequence. (c) An attribute for the value. Its type is either integer or string. The name of this relation is the catenation of the class name and the attribute name.

240

5. An index is built over the Oid attribute of each relation; relations corresponding to sequences have a composite index on the Oid and Pos attributes. The relational schema corresponding to the example of Fig. 2.3 is shown in Fig. 3. Note that no table implements the inverse o f the Director association. When a property is declared as i n v e r s e , the corresponding method invokes a query returning the required element by inspecting the direct property, extensionally stored in the database.

person(0id, Name, Age) department(0id, DepName, Director) s t u d e n t ( 0 i d , Code) studentMarks(0id, Seq, Marks) Fig. 4. Relational schema for the MOOD database of Fig. 2

At run time, before using MOOD libraries, the programmer must indicate which data-base interface should be used, and open it. This is an explicit and somehow undesired link, but in this way the Access Methods AM in the MGL are absolutely general; they refer to variable names that are initialized through this activity. The Database Definition is specific for the particular DBMS: when using Oraclel one needs to specify a username and a password, whereas with Informix the database name is sufficient. An example declaration could be 3. Database

*SehoolDatabase

= new

InformixDatabase("School");

The database must be opened, i.e. the program must call the LogOn method before each operation on the database, and LogOff at the end of the execution.

4

MOOD Application Programs

MOOD application programs are written using standard C + + ; however, the MGL library contains a number of generalized data types and methods that may be used in applications; they provide the basic functionalities for database access and for navigation upon the retrieved data. 3 This is a C + + definition for a variable S c h o o l D a t a b a s e of type "pointer to Database" initialized with an instance of the class I n f o r m l x D a t a b a s e , specialized for the database whose external name is School.

241

4.1

Initialization

T h e M O O D primitives are methods of an object type called N a v i g a t i o n N o d e s . This object may be considered as a meta variable that can hold subsets of database objects (i.e. objects of the MOOD schema) belonging to a specified class. Navigation nodes are declared by application programmers in correspondence to the sets of objects that they want to manipulate in their programs; each navigation node is associated to a unique C + + class, but several navigation nodes may correspond to the same class. Further, each navigation node is associated to an object that serves as a handler into the database. The handler of a class is a special object which is responsible for accessing the relational database for retrieving an object from it; it also maintains a cache of retrieved objects so that, when the requested object is already in main memory, no external access to the database is done. T h e following lines present the declarations of two NAVIGATION_NODE (the C + + type for a Navigaion Node). S T U D E N T _ . D B and P E R S O N _ D B are the handlers for the classes Student and Person.

NAVIGATIONNODE My_Student_Navigation_Node( SchoolDatabase, STUDENT_DB); NAVIGATION_NODE AllPersons( SchoolDatabase, PERSON_DB);

4.2

Use of Navigation Nodes

Each NAVIGATION_NODE has a 'current object' which may be changed by iteration primitives (Foreach). One can access this object with the method Current(). Thus, a normal C + + variable can be given a value which is achieved by using the Current method on a NAVIGATION_NODE, as illustrated by the following code fragment: Student s ; .

~

.

s = AS_STUDENT(My_Student_Navigation ~

.

printf('~ 9

.

l|ode. Current ()) ;

9

'', s - > N a m e ( ) ) ;

~

Having an object of some database type, one can access the attributes of it via C + + methods (as in s --. Name()). One interesting feature of this model of operations (thanks to a standard feature of the C + + language) is that, in order to follow a path through part_of relations, one has just to use C + + pointerfollowing as if exploring an in-memory structure. For instance, in the following code fragment we indicate how the name of the director of a department m a y be printed:

242

Department d; .

.

.

d = .... ; printf (. . . . ~

.

4.3

~

9

9

d->Director()->Name()

...

);

~

MOOD Primitives

The following primitives are part of the standard MOOD library. We describe each of them, including some fragments of C + + / M O O D code to exemplify their use.

Foreach(Variable); Follow(Attribute, Variable); Clear(Variable); Sql( V ariable, " whereclause" ) ; And(Vres, V1, V2);

Or(V~, v~, V2); Not(Yr,,, V); Join(Join_Condition, V1, V2); BuildRel(Result, l~, ..., Vn);

Foreach. This primitive implements iteration over a set of Tuples, contained in Variable (a NAVIGATION_NODE ); for instance, in the following program fragment it selects all persons currently in the navigation node AlIPersons; their names and ages are subsequently printed.

NAVIGATION_NODEAIIPersons(PERSON_DB); .

o ~

while (AllPersons.Forsach~)) { printf("...", AllPersons.Current()->Nams(), AllPersons.Current()->Age() ); } At each iteration through the loop, the 'current object' of AllPersons will return a different object contained in AllPersons (the order of iteration is not specified). Follow. The Follow primitive may be used to navigate in the database through part_of relations. Follow is normally used in conjunction with Foreach, as exemplified by the following code fragment which connects each director to the departments he directs.

243

NAVIGATION_NODE AIIDepartments(DEPARTMENT_DB); NAVIGATION_NODE AIIDirectors(PERSON_DB); Person p; while (AllDirectors.Foreach()) AllDirectors.Follow("Directs",

AllDepartments);

The Follow primitive has a source and a target navigation node variables; as effect of executing the primitive, the target variable contains all the objects that are connected to objects in the source variable through the part_of link. Note that one could navigate along part_of links through the corresponding methods, hut without instantiating the target navigation node; further, the Follow primitive is more efficient than the use of methods with part_of links of type sequence. Clear. It simply empties a NAVIGATION-NODE variable. It may be used to prepare a NAVIGATION_NODE for the next computation. For instance: NAVIGATION_NODE Persons_Older_Than_20(PERSON_DB);

Persons_Older_Than_20.Clear(); Persons_Older_Than_20.Sql( "age > 20" ); Persons_Older_Than_20.Sql( "age < I0" ); // Persons_Older_Than_20 now contains // the union of the results of both // SQL operations.

A n d , Or a n d Not. This functions implement the obvious boolean operations on the NAVIGATION_NO-DEs; and~or are applied to pairs of navigation nodes and generate their intersection or union; not generates the complement of an instantiated navigation node with respect to the values contained in the database for that node. NAVIGATION_NODE Persons_Older_20(PERSON_DB); NAVIGATION_NODE Toy_Directors(PERSON_DB); NAVIGATION_NODE Toy_Directors_Older_20(PERSON_DB); Persons_O1der_20.Sql( "age > 20" ); Toy_Directors.Sq1( "DepName = Toy* "); And(Toy_Directors_Older_20, Persons_Older_20, Toy_Directors);

244

Sql. Sql executes a query on the table associated to the current navigation node Vamable, and loads it with the resulting tuples, after type coercion. For example, we retrieve all persons more than 20 years old, and print their name, as it follows:

NAVIGATION_NODE Persons_Older_Than_20(PgRSON_DB); .

.

~

Persons_Older_Than_20.Sql( "age > 20" );

while (Persons_Older_Than_20.Foreach()) printf("...", Persons_Older_Than_20.Current()->Name()

);

The query expression can contain complex predicates, i.e. joins with other relations; this primitive, however, selects the result on t h e target table. The predicate may involve condition on attributes of subobjects, but in doing so the programmer must know the underlying relational schema. Full joins can be obtained with the primitive Join described later in this section. J o i n . In order to execute efficiently a relational full join operation, MOOD provides the primitve Join. Given a join condition (which, as in the Sql primitive, may be any legal SQL predicate) and two NAVIGATION_NODE s, MOOD executes a query on the relational database joining the relations associated with the NAVIGATION..NODEs. Consider for example the following program fragment:

NAVIGATION_NODE Directors (PERSON_DB) ; NAVIGATION_NODE Departments (DEPARTMENT_DB) ; , . .

Join("Person. Oid = Department.Director", Directors, Departments) ; .

.

.

To execute the join, MOOD will execute the following SQL query: select * from person, department where person.oid = department.director

After the execution of a Join primitive, MOOD loads selected objects into the corresponding NAVIGATION_NODE Directors and Departments, and sets up additional information between objects related by the join (as after the execution of a Follow primitive) to support a possible, subsequent execution of the BuildRel primitive. B u i l d R e l . This function must be preceded by a series of navigations with F o l low and Foreach, or with Join. Its effect is to build a relation that describes

245

all selected navigations. More precisely, the relation contmns one tuple for each distinct path ~ o m all selected objects in V1 to all selected objects in V~ (n is limited to a given max value, MOOD-implementation dependent). The only constraint is that all navigation nodes re~renced by the ~ must have been previously instantiated, through, Foreach, Follow, and Join primitives.

// Link each director with the department he directs NAVIGATION_NODE AIIDepartments(DEPARTMENT_DB); NAVIGATION_NODE AllDirectors(PERSON_DB); Person p; 9

.

,

.hile (AllDirectors.Foreach()) AllDirectors.Follow("Directs",

AllDepartments);

// Generate a relation linking departments // to their directors, called // "persons_departments" .

.

.

BuildRe1( "persons_departments", A11Persons, AliDepartments );

4.4

I m p l e m e n t i g t h e Isa H i e r a r c h y

The isa hierarchy C1 < C2, defined in a MOOD schema, is translated as follows:

1. Relational Schema. Each class corresponds to a different relation; therefore, R1 and R2 are generated. However, their Old attributes take values from the same domain D. If objects O1 E C1 and 02 E C2 are hierarchically related (O1 < O~), then the corresponding tuples tl E R1 and t2 E R2 have the same Old value. 2. C § 2 4 Data 7 Structures. We use the default C + + inheritance; thus, subclasses automatically inherit all methods of the superclass. Since we want to be able to use an object at each level in the isa hierarchy, we must store the representations of the attributes of all the subclasses in the top object. By doing so, all the objects in the hierarchy are the same length, and we may have a single pointer to an object, independently to the class to which it belongs; we may use a simple C + + type cast to change the class of the object 4. On the contrary, if we store the attributes in the object to which they belong, then objects at different level in the hierarchy would have different 4 Though a normal cast would suffice, the macro AS_class should always be used since it checks if the object really belongs to the class we are casting it to. Objects mantain a record of their identity, and trying to use an object with the wrong identity (i.e. asking the marks of a Person which is not a Student) would cause a Runtime Error.

246

length, and we couldn't have the same pointer to the objetct regardless of the class. 4.5

Building a Mood Application

We now detail the steps which are needed to run MOOD applications. First of all, the user must compile the MOOD schema. Let us assume that it is contained in a file named school.too, then the following commands are executed (mc is the

mood compiler): 7. m c -s s c h o o l . m o 7. mc -c s c h o o l . m o

The first command produce a file school.sql that should be run on the relational database for table creation. The second command produces, for each MOOD class~ one file with the .cc extension, containing C + + methods source code, and one with the .h extension, containing declarations to be imported in each user program. It also produces the files school.cc and school.h which contain general definitions about the schema. In our example, the produced files are: person.cc, department cc, student, cc, person.h, department.h, student h, school.cc, schooi.h. They are next compiled in a library, using the conventional C + + compiler and utilities. Finally, the programmer can write his application. This is a normal C + + program, which imports the MOOD definitions, defines appropriate navigation nodes, and uses the MOOD primitives. When the program is completed, it must be compiled and linked with the library just created. It can then be normally executed.

5

Example

A sample (real) program which queries the database for various operations is the following: I 2 3 4 5 6 7

#include #include #include #include #include #include #include

8

Database *SchoolDatabase =

9 I0

11

<stream.h> <School.h> <Student.h>

new InformixDatabase("School"); NAVIGATION_lODE

Persons_Older_Than_25(SchoolDatabase,

PERSON_DB),

247

Directors(SchoolDatabase, PERSON_DB), Departments(SchoolDatabase, DEPARTMENT_DB), Student_1OO(SchoolDatabase, STUDENT_DB);

12 13 14

15

main(int argc, char **argv)

16

{

17 18

SchoolDa~abase->LogOn(); Persons_Older_Than_25.Sql("age

19 20

//Sql - pers cout << "Names of employees older than 2Skn";

21

//while -i while (Persons_Older_Than_25.Foreach()) { Student s = AS_STUDENT(PersonsOlder_Than_25.Current()); Person p = AS_PERSON(Persons_OlderThan_25.Current());

22 23 24 25 26

27 28

c o u t << p->Name() << "\t"; c o u t << p - > J o b ( ) << " \ n " ;

29 30 31 32 33 34

i~ (s)

> 25");

cout << "\tCode: " << s->Code() << "\nkn"; else cout << "\t(This is not a Student !!)\nkn";

} tout << "\n";

35 36

//Sql - dep Departments.Sql( ....);

37 38 39 40

//while -2 while (Departments.Foreach()) { Departments.Follow("Director",

41 42

//while -3 cout << "Department data\n";

43 44 45 46 47

while (Departments.Foreach()) { D e p a r t m e n t d = AS_DEPARTMENT(Departments. C u r r e n t ( ) ) ; c o u t << d->DepName() << " \ t " ; c o u t << d - > D i r e c t o r ( ) - > N a m e ( ) << " \ n " ;

Directors);

}

}

248

48 49

50 51 52 53 54 55 56 57 58 59

60 61

cout << "\n"; tout << "Directors data\n"; while (Directors.Foreach()) { Person p = AS_PERSON(Directors.Current()); c o u t << p->Name() << "\n"; cout << "\n"; t o u t << " B u i l d R e l : Departments - Directors\n"; BuildRel("ne.rel", ~Departments, ~Directors, NULL); tout << "\n"; .hile (Persons_Older_Than_25.Foreach()) { Student s = AS_STUDENT(Persons_Older_Than_25.Current()); if (s == NULL) continue;

Pix i; c o u t << s->Name() << " \ t " ; Sequence v = s->Votes();

62 63 64 65 66 67

tOUt << "Votes: "; if ( ! S E m p t y ( v ) ) {

f o r ( i = S S t a r r ( v ) ; i != O; S N e x t ( v , i ) ) t o u t << " " << *SAZ(v, i , i n t * ) ;

68

}

69

70 71 72 73 74

{

} tOUt << "\n" ;

> SchoolDatabase->LogOff();

We now describe in detail each part of the program. - Lines 1-7 include (i.e. they import) the external declarations needed by the program. - Lines 8-14 define the database interface and the NAVIGATION_NODE used. Each NAVIGATION_NODE is connected to the database and to the particular class. - The program starts executing at line 17 doing a LogOn to the database, by using the method L o g O n ( ) . - At line 18 the program makes its first query to the database. It asks the MAL to retrieve some Persons from the relational database and to create the corresponding NAVIGATION_NODE P e r s o n s _ O l d e r _ T h a n _ 2 5 , so that the program will be able to operate on them, as it will do in lines 22-33. It iterates over all the M O O D objects just retrieved displaying some data about them. It also checks which Persons are also Students by trying a coercion to the desired class (the macro AS_STUDENT) and checking if the resulting object pointer is NULL (i.e. the nil object).

249

-

-

-

-

6

Line 36 executes a query on the Departments class, retrieving all the objects. At lines 38-40 we see how to execute a Follow between Departments and Directors. The effect of this loop is to retrieve and put in the NAVIGATION_NODE D i r e c t o r s pointers to all the persons ( D i r e c t o r s ) which are directors of some department. MOOD also stores information needed to remember which department caused the inclusion of which person (for this particular couple of NAVIGATION_NODE ). This information will be used by the B u i l d R e l at line 56. Lines 56-72 iterate over all the persons (retrieved in line 18) which are also students to display their votes. Lines 67-69 iterates over the votes of a single student. The expression *SAt(v, i, int *) extracts the i-th vote of the student. Macros S S t a r t and S N e x t control the iteration. Finally, at line 73, the programs Logs Off the database.

Previous

Related

Work

MOOD presents an interface between an object-oriented language and a relational database; related work concerns various methods for interfacing databases with programming languages. 6.1

Logic Systems

Logic offers an ideal setting for these intefaces because of the "natural" correspondence between predicaies in logic and relalions in databases. Several systems and prototypes proposed in the literature couple Prolog to a relational database, including CGW, PRIMO, BERMUDA, ESTEAM, and Q U I N T U S - P R O L O G [3]. The coupling is almost always loose, i.e. the interaction with the database takes place independently of the inference process. Some of the predicates used in the prolog program are classified database predicates. When the program refers to one of them, the underlying coupling system transforms the logic goal into a SQL query; the query is executed by the relational system; and results are transferred from into the main-memory environment of the Prolog program. 6.2

Object-oriented Databases

A significant trend in database systems is toward the design of object-oriented data models where it is possible to describe complex objects with identity (see [9], [10], [11]). In this field, there should be in principle no need for interfacing with programming languages, since these systems propose new-generation languages which are computationally complete and persistent. However, in ahnost all of them the need is felt for interfacing the most popular programming languages (e.g. C02 between C and 0~, [9]), because conventional programming languages remain the most conventional vehicles for writing applications. This consideration has influenced our work.

250

6.3

H o s t L a n g u a g e Interfaces to SQL

Since SQL is not computationally complete, it has always been hosted by conventional programming languages, like COBOL or C or PASCAL, with statements like: EXEC SQL SELECT COUNT(*)

INTO :COUNT-EMPLOYEES FROM EMPLOYEES

END EXEC

The above instructions store the count of employees into a variable COUNTEMPLOY-EES which must be known to both SQL and the host language. This is a first mechanism for communication, eased by the fact that the query result is a singleton relation. When instead queries select sets or multisets, communication is achieved through cursors. First a cursor must be associated with a query, and then the host program can use the F E T C H instruction to retrieve successive tuples from the query result into the variables of the programming language. This approach forces the programmer to use two languages in the same program, and to alternate tuple-based with set-oriented processing. Compared to cursors, the approach defined in this paper is at a higher level: the programmer can use methods and primitives for all its interaction with the database. Primitives such as Foreach and Follow allow navigations across semantic links, while the primitive BuildRel assemble the results of computations in a powerful ways. However, the full power of SQL is available, through Sql and Join primitives, if one wants to lower the level of the interaction. 7

Conclusions

The design and implementation of MOOD has now reached a stable state. In particular, all functions described in this paper have been implemented. Given the loos-coupling approach, the prototype is not an high performance system. This meets our expectations: we were aiming at verifying the feasibility of the approach, not its performance. The current state of MOOD is not definitive, in particular we expect it to evolve along various directions:

11 Methodology ~J Tools. In order to turn MOOD into a workable programming system, it must include some tools, to enable the programmer to design and tailor his application: schema analyzers, automatic code generators for "standard" tasks, and so on. 2. Access to existing databases. MOOD builds its own database to store classes. It is conceivable to do the opposite, i.e. starting from an existing relational database and then build the C + + classes to access the database. We could then use all primitives developed for MOOD in this new context.

251

3. Dynamic MOOD. MOOD is a static system: it is not possible to extend the schema at runtime. This is because C + + is a statically typed language. Nevertheless, if one wants to build interactive applications, it would be nice to have the capability to define new classes at runtime. While C + + prevents us to define new types, it has features that may give some run-time flexibility. 4. Development of other systems with MOOD. MOOD can be used as a tool for building other systems. We are considering to implement L O G I D A T A + in C + + using MOOD; other applications could be in the context of graphical database interfaces to generate navigational queries through pointing devices on the schema.

References 1. P. Atzeni, F. Cacace, S. Ceri, L. Tanca: "The Logidata+ Model" ; Rapporto Interno,

Obiettivo Logidata+, 1990. 2. F. Cacace, S. Ceri, S. CrespiReghizzi, L. Tanca, R. Zicari: "The LOGRES Project: Integrating Object Oriented Data Modeling with a Rule Based Programming Paradigm."; Rapporto Interno n. 89039, Politecnico di Milano, Dipartirnento di

Elettronica, 1989. 3. S. Ceri, d. Gottlob, L. Tanca: "Logic Programming and Databases"; Springer Vet-

lag, 1990. 4. B. Stroustrup: "The Cq--t- Programming Language", Addison Wesley, 1986. 5. S. Ceri, d. Gottlob, G. Wiederhold: "Interfacing relational databases and Prolog efficiently."; Proc. 1st Int. Conf. Expert Database Systems, Charleston, 1986. 6. E. Ioannidis et at.: "BERMUDA- an architectural perspective on interfacing Prolog to a database machine."; Computer Science Technical Report 723, University of

Wisconsin, Madison, Wis. Oct. (1987).. 7. F. Gozzi: "Design and implementation of efficient interfaces between logic programming environments and relational databases - complex predicates (in Italian)";

Diploma Dissertation, Computer Science School, University of Modena, Modena, Italy, Dec. (1987).. 8. M. Lugli: "Design and implementation of efficient interfaces between logic programming environments and relational databases - metainterpreter and simple predicates (in Italian)"; Diploma Dissertation, Computer Science School, University of

Modena, Modena, Italy, Dec. (1987)_ 9. O. Deux et at.: "The 02 System"; Communications of the ACM, October 1991,

Vol. 34 No. 10 10. C. Lamb, G. Landis, J. Orenstein, D. Weinreb: "The Objectstore Database System"; Communications of the ACM, October 1991, Vol. 34 No. 10 11. P. Butterworth, A. Otis, J. Stein: "The Gemstone Object Database Management System"; Communications of the ACM, October 1991, Vol. 3,4 No. 10

P r o t o t y p e s in t h e LOGIDATA

- Project 1

A. Artale, J.P. Ballerini, S. Bergamaschi, F. Cacace, S. Ceri, F. Cesarini A. Formica, H. Lain, S. Greco, G. Marrella, M. Missikog, L. Palopoli L. Pichetti, D. Saccd, S. Salza, C. Sartori, G. Soda L. Tanca and M. Toiati

Authors' affiliations:

A. Artale, F. Cesarini and G. Soda: Dipartimento di Sistemi ed Informatica, Universit~ di Firenze, Italy. J.P.BaUerini, S. Bergamaschi and C. Sartori: CIOC-CNR, Bologna, Italy. F. Cacace, S. Ceri and L. Tanca: Dipartimento di Elettronica, Politecnico di Milano, Milano, Italy. A. Formica, M. MissikoI~, L. Pichetti, S. Salza and M. Toiati: IASI-CNR, Roma, Italy. S. Greco, G. Marrella, L. Palopoli and D. Saccd: Dipartimento di Elettronica, Informatica e Sistemistica, Universit~ della Calabria, Rende, Italy. H.Lam: Database Systems R&D Center, University of Florida, USA.

1

Presentation

(L. P a l o p o l i )

The purpose of the LOGIDATA+ project has been to design and implement an advanced database environment supporting a number of advanced features such as a complex data model integrating value-based, object-based and functionbased data entities, a logic-based query language with negation including module specifications and exception handling, a complex object basic query machine efficiently implementing query answering on LOGIDATA+ databases, a logic based language for updating the LOGIDATA+ databases and, finally, a taxonomic classifier to perform type classification based querying on the schema and to be used also as kernel component of a tool for computer aided database design. The LOGIDATA+ project was designed as a 3 plus 2 years project, where the former three years were intended to serve for researching about a number of open problems in the field covered by the project, and the latter two years

253

were intended to serve for developing a complete prototype of the LOGIDATA+ system. This paper covers the prototypes development activities carried out in the former three years of the project. There are a number of research topics amongst that covered by the former three years of the LOGIDATA+ project whose study has been followed by a prototyping activity. Taxonomic reasoning, complex forms of negation, modularization, implementation models and techniques are among those research topics. In the sequel of this section, the prototypes are briefly overviewed. Three prototypes correspond to the research developed on the problem of adding taxonomic reasoning facilities in a complex object database framework. The first prototype (Section 2) is called LOGITAX and has been developed at the Dipartimento di Sistemi ed Informatica - Universits di Firenze by A. Artale, F. Cesarini e G. Soda. LOGITAX is a prepocessor which allows to build a taxonomy of classes defined according to an extension of the LOGIDATA+ data model, called LOGIDATA*. The second prototype (Section 3) is called ODL-DESIGNER and has been developed at the CIOC-CNR- Bologna by J.P. Ballerini, S. Bergamaschi and C. Sartori. ODL-DESIGNER is a tool supporting the acquisition of complex object schemata, which are checked for consistency and minimality. The third prototype (Section 4), called MOSAICO has been designed and implemented at IASI-CNR, Roma, by A. Formica, H.Lam, M. Missikoff and M.Toiati. MOSAICO is a tool designed to help the rapid prototyping of database applications based on a complex object data model. One prototype has been developed which regards the problem of augmenting classical logic programming with very powerful kinds of negation. The prototype, called PATRIOTS Ms (Section 5), has been developed at the Dipartimento di Elettronica Informatica e Sistemistica - Universitk della Calabria by S. Greco, G. Marrella and D. Sacc~. Its purpose is to implement several techniques defined within the project to compute non-deterministic stable semantics and semantics with exceptions in logic languages with negation. The LOGRES prototype (Section 6) can be thought of as being associated to a many-fold research topic: studying the modularization issue in logic languages for databases, studying the problem of update and query specifications on complex object databases through a logic based language and, finally, investigating the suitability of non first normal form relational databases as kernel on which to implement complex object databases. This prototype, has been developed at the Dipartimento di Elettronica, Politecnico di Milano by F. Cacace, S. Ceri and L. Tanca. The LOGRES prototype translates complex object declarations in the extended relational model of the Algres language. A corresponding translations takes place for rules too, which are then executed on the Algres interpreter. The last prototype presented in this overview relates to the problem of efficiently bridging a logic query language environment to an existing (commercial) relational database. The focus in this case is on the efficiency of the coupling between the two environments. The prototype, called LOGIBASE+ (Section 7),

254

has been developed at IASI-CNR, Roma, by S. Salza and L. Pichetti. The system has been defined to extend the capability of a commercial database management system by providing a rule based interface and a number of modules to optimize and evaluate logic queries. The paper closes with a reference section and a final section in which the table and the figures referred throughout are reported. 2

LOGITAX:

A classifier

for LOGIDATA+

(A. Artale,

F. Cesarini, G. Soda) LOGITAX (LOGIdata TAXonomy) is a tool developed in the LOGIDATA+ project for organizing class descriptions in a taxonomic graph. The taxonomy refers to the concept of subsumption; a class C subsumes a class C ~ if and only if C' is a subclass of C. Therefore the taxonomy is built by determining all the subsumers and subsumees of each class. Subsumption can be determined by examining the class descriptions, according to a suitable denotational .semantics. This kind of approach strongly relies on the concept of defined class, i.e., a class whose type definition gives necessary and sufficient conditions for an object to belong to it. The taxonomy makes it possible to perform some inferences (taxonomic reasoning) that are useful in several applications, such as conceptual schema design, instance recognition and query answering. Since taxonomic reasoning is not usually present in Object-Oriented Data models, its introduction in the LOGIDATA+ model has required a suitable formal framework. The classifier implemented refers to the LOGIDATA* Data Model which allows us to distinguish between defined and primitive classes. A class is called primitive if its definition gives necessary conditions for an object to belong to it, it is called defined if the conditions are necessary and sufficient. Subsumption between primitive classes must be stated by user ISA declarations, whereas, in the case of defined classes, it can be computed examining the structure of the class definitions: Therefore, the classifier can be used as a preprocessor for checking both user definitions and discovering ISA links not explicitly stated by the user. Since LOGIDATA* supports multiple inheritance and acyclic definitions, LOGITAX manages a Direct Acyclic Graph (DAG) whose nodes represent the classes. Futhermore, the graph is maintained in a minimal form, that is, there is a link between nodes x and y if and only if y subsumes z and there is not any z such that y subsumes z and z subsumes z.

2.1

LOGITAX Structure

The classification process consists of two main steps: Parsing and Insertion.

Parsing In this step, the description of the new class is acquired and translated into a canonical form. The parser recognizes whether or not an input string is a

255

LOGIDATA* description, making a distinction between a type_declaration and a class_declaration. During this phase LOGITAX verifies the absence of recursive definitions and description correctness. An automatic translation mechanism for converting a user class description into a canonical form is embodied in the parser. The canonization-process generates the class structure that is used in the next phase of classification; multiple inheritance is managed by expanding the class names appearing in the ISA clause.

Insertion The aim of this step is to arrange the class, expanded in the previous phase, within the graph. Insertion is performed by : 1) finding all the direct parent classes (the Most Specific Subsumers, MSSs); 2) finding all the immediate descendants (the Most General Subsumees, MGSs). Furthermore, all the operations necessary for maintaining the graph in a minimal form are performed. Search of the Most Specific Subsumers In this step, a class is put under its most specific subsumers in the graph hierarchy on the basis of its properties. Since the data model supports multiple inheritance, it is possible for a class to be subsumed by two or more incomparable classes. In determining the most specific subsumers we take into account the graph's structure and the ISA clause appearing in the user class description, operating in both a top-down and bottom-up way. Let x be the class we want to introduce; the search process is carried out by means of the following steps: 1. A list of classes that subsume x is built by only considering the user-specified ISAs and the transitivity of the links present in the graph. This process is performed by means of a bottom-up navigation of the graph. 2. For each class of the list, all its direct subclasses are examined looking for a subsumption relationship. If one of these subclasses subsumes z then LOGITAX proceeds top-down examining all its direct subclasses, otherwise, it skips onto the next subclass. In this way, the classifier finds out the Most Specific Subsumers of x, i.e., the classes that subsume x and do not have subclasses that in turn subsume x; a link is then asserted between z and each of its Most Specific Subsumers.

Search of the Most General Subsumees In this step LOGITAX looks for classes y subsumed directly by z (i.e., it does not exist z for which x subsumes z and z subsumes y). Due to the transitivity of subsumption, any MGS of z is subsumed by all the MSS of z. Therefore, in order to find all the MGSs of x, it is sufficient to choose a MSS of x and to determine whether or not its descendants are subsumed by x. At the end of this phase, all the redundant links are eliminated, thus the graph minimality is maintained. LOGITAX is implemented in C-Prolog under Ms/Dos.

256

3

The

ODL-DESIGNER

Prototype

(J.P.

Ballerini,

S.

Bergamaschi, C. Sartori) ODL-DESIGNER is an active tool which supports automatic building of classes and types taxonomies, preserving consistency and minimality of a database schema. It is based on the inference technique taxonomic reasoning, developed in the AI environment. Taxonomic reasoning is founded on the computation of subsumption relationships between two classes on the basis of their descriptions and allows the discovery of implicit ISA relationships between derived classes (also named defined of virtual), which are analogous to database wiews and whose descriptions constitute necessary and sufficient conditions. ODL-DESIGNER is based on a subsumption algorithm tractable and complete which is able to compare very general class and types descriptions, as is addressed in papers Taxonomic reasoning in LOGIDATA-t- and Taxonomic reasoning with cycles in LOGIDATA-I-, in this volume. In ODL-DESIGNER a class is expressed as genus, i.e. a conjunction of ancestors (not necessarily parent) class names, and differentiae, i.e. class descriptions obtained by freely nest'ing the tuple, sequence and set operators. Futher, set cardinalities are expressed and, besides primitive classes (whose descriptions constitute necessary conditions), derived classes are also supported. The main feature, with respect to LOGITAX and to Mosaico (see Sections 2 and 4) is the support of cyclic definitions. The tool is able to guarantee a passive consistency check for a taxonomy of primitive classes: given a new class , by subsumption, it is possible to compare its description with a given class taxonomy and to detect if it is incoherent (subsumed by the empty class)and thus refuse it. A more active role can be played if the taxonomy includes also derived classes: for a coherent class description a minimal description (i.e., a rewritten description on the basis of its most specific generalizations) is computed and thus the class is placed in the right position of a taxonomy. In this way, semantic equivalence of classes can be recognized (i.e., different names and/or syntactic descriptions which correspond to the same minimal description) and redundancies with respect to a taxonomy are removed. Figure 1 shows the architecture of ODL-DESIGNER. The program is divided into two main functional groups: F I : allows the creation and the transformation of an ODL schema from a syntactical and semantical point of view, checks if the ISA relation graph and the relations between types are cycle free and, if the schema is correct, generates the canonical form of the ODL schema; F2: finds out the minimal ODL schema starting from the canonical ODL schema. Figure 2 depicts the structure of CREATE, the schema creation procedure: the user interface allows schema creation by directly inserting a description or by giving the name of a text file containing the descriptions. The input schema i s t h e n analyzed from a syntactical and semantical point of view and, in case of success, the absence of ISA cycles and type cycles is checked. If the schema is well formed (i.e. the previous checks are positive), the canonical schema is

257

generated, to recognize possibly incoherent classes or types. In this phase an interaction with the user is necessary when errors are detected, in order to ease the design process. The canonical schema becomes the input to the taxonomic reasoner which generates the minimal schema. The ADD procedure has a structure very similar to that of CREATE. The main difference is that it allows a simplified reasoning algorithm, since it compares new descriptions, which are potentially incorrect/conflicting, with a corpus of well formed definitions. Finally the MODIFY procedure is similar to ADD, as it starts from an existing schema, but in this case the knowledge has a non monotonic growth and then the coherence computation for the modified schema has to be done from scratch.

4 MOSAICO: a System for Specification and Rapid Prototyping of Object-Oriented Database Application (A.Formica, H.Lam, M.Missikoff, M.Toiati) The system Mosaico has been conceived to support the design and rapid prototyping of data intensive applications based on Object-Oriented Databases (OODBs). The system is described illustrating first its architecture, then its data model, and finally some implementation issues. 4.1

Architecture of the system Mosaico

The architecture of the system is depicted in Figure 3. The functions supplied by the systems can be grouped into four main subsystems. - O O D B A p p l i c a t i o n S p e c i f i c a t i o n - This subsystem support the designer in the process of constructing the specification of an application, using the specification language T Q L + + . An application is specified by defining a set of types and a set of associated actions. Types can be defined from scratch or imported (and possibly adjusted) from a type library. New types are inserted in the type library for future reuse. Type and action definitions form the Object-Oriented application specification, referred to as schema + + (the term schema without pluses is used for the structural specification alone, i.e. data definition without actions). - O O D B A p p l i c a t i o n V e r i f i c a t i o n - The formal nature of the language T Q L + + allows the semantic verificaton of the specification of an application. Mosaico processes the specification aiming at finding incorrect descriptions, such as incomplete, inconsistent, or unsafe assertions. To this end the specification is translated to an internal (logical) format and is supplied to a theorem prover. - R a p i d p r o t o t y p i n g - This subsystem is devoted to the compilation of the s c h e m a + + and the production of executable code. The code produced implements a prototype of the application. To actually run the prototype, it

258

is generally required to load a few objects. To this end Mosaico supplies a language, Lobster, for object definition and the initial load of the database. - Q u e r y processing tool - Having defined the schema and having populated the database, it is possible to perform query functions. One key feature of the system is the possibility of querying the database using the same language conceived for the Data Definition: TQL. In essence the enquiry is performed by defining new q u e r y - types, then the system retrieves all the objects that satisfy the query-type and constructs the a n s w e r class. 4.2

The TQL++ data model

The data model of TQL system is based on the traditional elements that can be found in other proposals of the field. In particular objects have identifiers (oids), which are immutable throughout their life, and unique, i.e. each object has a different identifier. Objects have a state, given in terms of the values of the properties. Properties, when evaluated, can be associated to basic values, corresponding to built-in types (such as integer or string), or to complex objects. In the latter case, referenced objects are identified by means of oids. Mosaico allows the designer to specify a database application by defining a schema++, i.e. a set of complex types and their associated actions. Types include the specification of the structure of the objects, semantic integrity constraints, and the protocol (i.e. set of action declarations). Actions define objects' behavior in a declarative way. The data definition component Of a type is composed by a tuple of typed properties (due to lack of space, we skip the behavioral part). A property can be typed with: (i) basic types, (ii) an explicit set of values (enumerated type), (iii) an interval, (iv) a user-defined type, (v) a tuple of typed properties. A property can be single-valued or multivalued. In the latter case it is possible to impose cardinality constraints. Types are organized in a generalization hierarchy. Example I. The type person and student, and two objects, defined according to the syntax of TQL and Lobster, respectively:

person := [name:err, addr: [street:err,

city:str],

tel:{int}o,3,

age:(O..I80), sex:(N,F),vehicle:car] student := ISA person [college:sir] PERSON = {(#p3: [name:john, addr: [street: broadway, city:S.F.], tel:34S6667, age:34, sex:M, vehicle:#cl2]), (#pT: [name:amy, addr: [street: tinyWay, city:L.A.],

te1:{7666345, 7666543}, age:22, sex:F, vehicle:#c12]) In the example we assume that the type car has been defined. The oids are indicated by a code that starts with the character # (pound).

259

4.3

Implementation issues

A first prototype of Mosaico has been developed on a SUN workstation, using BIM-Prolog. Current version generates prototypes in the form of Prolog code. A code generation for generating C + + code is under development.

5 A System Prototype for the Computation of DATALOG Programs with negation (S. Greco, G. Marrella, D. Sacc&) DATALOG is a Horn clause language without function symbols which is mainly used as query language for relational databases [4, 15]. Because of recursion, its expressive power is greater than that of classical database languages based on predicate calculus; nevertheless, DATALOG is unable to fulfill all requirements of new demanding knowledge-based applications. Therefore, many research projects are recently involved in adding new features to DATALOG [5, 11, 10, 16]. In [9] and [7] two particular usages of negation have been proposed to add, respectively, non-determinism and exception mechanisms to DATALOG and have described a number of algorithms for implementing their semantics. In this section we describe a prototype that has been used both to experiment the expressive power of the two mechanisms and to verify the feasibility of their implementation. 5.1

Architecture of the Prototype

The prototype handles queries on DATALOG programs with negation, whose base of facts is stored in mass memory (files or relational databases). The architecture of the prototype is pictured in Figure 4. There are six main modules in the prototype: the User Interface, the Schema Manager, the Program Manager, the Query Compiler, the Interpreter and the Database Interface. The User Interface manages the dialogue with the user and provides the access to the three main services supported by the prototype: (i) design of the fact base schemata, (ii) definition of DATALOG programs on the fact base of one of the available schemata, and (iii) submission of queries. The Schema Manager handles the data dictionary of the schemata used by the DATALOG programs; in particular, for each schema, it stores the name of each base predicate symbol, the name of the corresponding relation, and the database or the file where the tuples of each relation are stored. The Program Manager receives DATALOG programs from the user interface and stores them into a repository. Each program is partitioned into a partially ordered set of subprograms (components), each of them consisting of the rules which define mutually recursive predicates. The Query Executor receives from the user interface a query on a program and compiles the program in such a way that all answers of the query are computed possibly using constants for restricting this computation. The result of a query

260

compilation is a new program (rewritten program) whose execution generates all query answers. The steps performed by the executor are the followings: 1. selecting the components of the program that are useful to compute the query (and possible desirable properties such as program stratification are checked to devise a better execution strategy); 2. reordering goals appearing in the body of rules in order to guarantee safety and improve the performance of execution; 3. generating the rewritten program; 4. sending the rewritten program to the interpreter; 5. forwarding the answers received from the interpreter to the user interface and, if required, storing the rewritten program into the repository for further executions. The Interpreter consists of a program that computes a DATALOG program using classical fixpoint computations as well as the algorithms of [9,7]. It is written using meta-programming in PROLOG so that the powerful mecfianisms of this language represent the basic components of the DATALOG machine; e.g., unification is used to implement the operations of relational algebra. The Database Interface provides the access to external database relations or files. It realizes a 'tight' coupling, that is, the loading of external data as facts in main memory is optimized using the knowledge on the history of previouslyexecuted retrievals for caching [4]. Also this module is realized through rectaprogramming in PROLOG.

5.2

An Example of Implementation of the Prototype

As shown in Figure 4, the module Interpreter is implemented as a PROLOG meta-program. In order to give an idea of how this module is realized, next we sketch the implementation of the part of the Interpreter which computes the fixpoint of a DATALOG program. This computation is a key operation in the evaluation of DATALOG programs and is the basis for the actual implementation of the algorithms of [9,7] As already mentioned, a program P is partitioned into a number of components {P1,-.., Pn} that are partially ordered in such a way that each predicate appearing in a subprogram Pi depends only on predicates appearing in subprograms Pj for which j _
compute (Component s),

ev Z(X). The predicate relevant.program computes the list [Pkl, Pk2, ..., Pk,~] of components that are relevant for the execution of the query. The sequence of components are listed in the above order. The Interpreter computes the components following this order.

261

compute(B )9 r lOthercomponents]) ~- seminaive(Pj, 0), compute(Othercomponents). The predicate seminaive computes each component Pj using the seminaive strategy [15]. The iterative process of the seminaive computation is enforced using the construct fail inside the body of the rules. The second argument of seminaive stores the index of the iteration. s e m i n a i v e ( P j , O) *-- e x i t _ r u l e ( P j , R u l e ) , e v a l . / u l e ( R u l e , 0),

fail. seminaive(Pj,I)~- I > O, recursive_rule(Pj,Rule), eval_rule(Rule, I), fail. seminaive(Pj, I) ~- generated_tuples(Pj), I 1 is I + 1 seminaive(Pj,Ii). seminaive(_,_). The computation of the above rules can be summarized as follows: 1. at step 0 the exit rules of the component Pj (first rule) are computed ; 2. at step I > 0 the recursive rules of Pj (second rule) are computed; 3. the computation of the second rule is repeated until no new facts are generated; at this point, if at least one fact has been generated in the current step, the third rule starts the computation for a new step, otherwise the computation halts, since the fixpoint has been reached. For the evaluation of a rule, we first evaluate the body, and then, if the body is true, we store the head. Notice that, because the rules are safe, the head of the rule, after the evaluation of the body, is bound, that is, it does not contain free arguments.

eval_rule((Head : --Body), I) +- eval_body(Body, I), store(Head, I), fail. The body of a rule is true if all its goals are true. The predicate eval_body is then:

eval_body((B1, B2) ,I) +- !,eval_predicate(Bl, I), eval_body(B2, I). eval_body(Bl, I) +eval_predicate(Bi, I).

262

The predicate eval_predicate first checks if there exists in main memory a tuple that matches with the specified predicate. If such a tuple does not exists and if the argument is a base predicate then it call the Database Interface to load more tuples from the database. As already pointed out, this prototype has been implemented to experiment the expressive power of the stable model semantics [9] and of negation in the rule heads [7]. For the case of programs with negative head rules (the so-called negative programs), the prototype requires stratification whereas no restriction is asked for non-negative programs. If imposing stratification simplifies the computation, on the other side it reduces the expressive power as argued in [9]; therefore, future work is devoted to deal with unstratified negative programs. The present name of the prototype, P A T R I O T S Ms (Possibly Another Tool for Rapid Implementation of Total Stable Model Semantics), is not stable; we are waiting for new developments of the prototype to select a more impressive name.

6

The

LOGRES

prototype:

a logic language

for object

oriented databases (F. Cacace, S. Ceri, L. Tanca) The Logres system is an advanced database system based on the integration of object oriented data modeling and a rule based language for the specification of queries and updates. The data model includes generalization hierarchies, object identity and object sharing. The rule language can be seen as an extension of Datalog, designed to handle complex objects. A Logres program consists of two parts: 1. data structure declaration, which may include the definition of classes (sets of objects with identity) and relations (sets of ordinary tuples), and which is specified defining the type associated to each class or relation; 2. rule program, which consists of a set of logical rules partitioned into modules (also called "Logres applications"). The Logres system prototype translates class definitions into the extended relational model of the Algres language [3]. The rules in the program are translated into extended relational algebra expressions which are evaluated by the Algres interpreter when a query is requested. Algres is an advanced system for the development of applications which need a capability of defining and manipulating complex data structures. The Algres abstract machine executes relational algebra operations on non first normal form relations which are stored in a memory workspace. The Algres environment consists of the Algres abstract machine and several interface modules. The rational underlying using Algres as prototyping tool for the Logres system is two-fold: - evaluating the representational capabilities of Algres against the highly complex data model of Logres, which is significantly outside the realm of the ordinary relational model;

263

- verifying the feasibility of building generic object based DBMSs using ordinary relational systems taking advantage of their technological maturity. In order to obtain the Aigres representation of the main problems are to be solved:

Logres data model, four

the tuples in an Algres relation have a fixed schema; counterwisely, objects belonging to a generalization hierarchy in Logres must be looked at as variant records and therefore their structure do not obey to a fixed schema; so, there exists a structural mismatch which has be taken into account; Algres is value-oriented like any other relational system and therefore it does not support data identity, which is a basic component of the Logres model; - the Logres model allows object sharing, which is not supported in Algres; - cyclic schema definitions are allowed for Logres classes whereas they can not be used within the Algres model. -

-

In the implementation of the Logres system, many design choices were motivated by efficiency reasons. Before presenting the most important of those design choices it is therefore worth illustrating what are the relatively most frequent operations ordinarily carried out on Logres data structures. The working hypothesis on frequencies gives the following as the maximally frequent operations: - to request all the objects belonging to a given class; - to evaluate attribute values of a given object; -- to evaluate attribute values of an object which is part of another object (navigation of a part-of relationship). Thus, the translation of the Logres data model into the defined along the following design choices:

Algres one has been

1. an Algres relation is created for each class or relation defined in the declaration part of a Logres program; then, Algres relations corresponding to Logres classes belonging to a certain generalization hierarchy are related using severa] auxiliary distinct Algres relations; 2. the schema of each Algres relation corresponding to a Logres class includes a supplementary attribute named Self which is used to simulate object identifiers; 3. each Algres relation corresponding to a Logres class has type s e q u e n c e and is ordered with respect to the Self attribute; so doing, the navigation along a hierarchical relationships can be realized through merge-join operation between Algres relations, obtaining a linear complexity in the cardinalities of the involved classes; 4. whenever a part-of relationship exists in Logres between two classes, a supplementary AIgres relation is created which includes pairs of (values simulating Logres) object identifiers expressing the part-of relationships; this relation is ordered along one of its two attributes and is used for indexed accesses to the involved relations.

264

As already mentioned, a Logres program consists of a declaration part in which all the data entities used in the application are defined, and of a set of rules written according to a syntax similar to the Datalog one, which express the manipulation to be carried over the defined data structures. It is known from the theory of deductive databases that the minimal model of a Datalog program can be computed bottom up as the fixed point of a transformation associated to the translation of Datalog rules into relational algebra expressions. This technique can be also adopted in the case of Logres programs. Thus the evaluation of a generic Logres programs consist of the following steps: 1. the dependency graph associated to the given program is first constructed; then, it is partitioned into a collection of connected components each of which can be evaluated in successive applications of the fixed point procedure; 2. the relational algebra expression associated to each rule of the given program is generated; 3. the fixed.point procedure is applied to each of the connected component of the dependency graph, along the order computed at steep 1. Steps 1 and 2 are statically executed by the Logres compiler which translate its source program into an object program coded in ALICE. The integrated utilization of Algres and the C language seems to be very well suited for the efficient implementation of Logres rules and the instructions needed for the execution control, respectively. The object program coded in ALICE has the following structure: - the structure of the Algres entities corresponding to Logres objects is generated during the declaration compilation phase; Algres relations corresponding to extensional predicates in the Logres logic program are loaded in the workspace by several call of the POI module, which manages persistent entities; - a loop controlling a number of Aigres expressions for rule evaluations is included for each connected component of the dependency graph; conditions which check for the termination of the fixed point evaluation process are associated with each loop; - depending on the specific instruction included in the given Logres programs the Algres relation associated to intentional predicates in the Logres programs are either stored in mass memory by invoking the POI Module or used for query answering. -

7

The

LOGIBASE~-

prototype

(S. S a l z a , L. Pichetti)

LOGIBASE+, is a prototype system for the management of large deductive databases developed at IASI-CNR [14]. The aim of the project has been to overcome the practical limitations of the classic logic programming systems (e.g., Prolog), that can reasonably perform only on applications of limited size. The system extends the capability of a commercial relational database management

265

system (Oracle), by providing a rule based interface and additional processing modules to optimize and efficiently evaluate logic queries. The system has been especially conceived to provide a good performance on the evaluation of recursive queries. This has been attained on one hand by relying on the efficient execution of set-oriented operations by the relational DBMS, and on the other hand by introducing additional capabilities for the optimizations of queries, the management of temporary relations and the execution of the relational primitives in main storage. More precisely a Main Memory Database (MMDB) has been implemented to store temporary relations with suitable access structures, and new relational primitives have been defined and implemented to efficiently carry on the fixed point evaluation. This has required a large implementation effort, but finally allowed a dramatic improvement in the performances. Great attention has been devoted to query optimization. This is indeed a very important feature in a relational DBMS, and becomes a critical issue when recursive queries are taken into account. The problem has been largerly addressed in the literature but although no final solution to it has been given [1,12,13]. Traditional optimization consists of logical rewriting methods. In our system we have added another level, the physical optimization, to take into account the possibility of performing the relation operations either in main memory or through the RDBMS. The crucial issue in the design has been the efficient coupling with RDBMS. The architecture of the prototype provides indeed a series of options, that range from having all the computation performed by the RDBMS, to loose coupling, i.e., loading the relations entirely in main memory, and to tight coupling, i.e., working with frequent and more selective interactions with the RDBMS. The first option allows to keep the RDBMS efficiency on non recursive queries, while the other gives room to the optimization procedure for recursive queries that selects the kind of coupling based on the estimation of the execution cost: The architecture of the LOGIBASE+ prototype is sketched in Figure 5. The diagram shows three layers in the architecture which correspond to the various phases of the transformation and of the evaluation of deductive queries. The first layer corresponds to the logic level, where the transaction is originally expressed as a logic program in a deductive rule-based language. More specifically Rule based Interface provides the user access to the schema of the deductive database and allows to consult the database catalog, to define new intensional predicates, to add new rules for them and to submit queries. The latter are in fact logic programs, and are passed, for a first level optimization, to the Logical Optimizer. This module utilizes the rewriting techniques to produce a new logic program, equivalent to the original one, but better suited for an efficient b o t t o m up evaluation. The second layer translates the declarative program into a procedural program, written in an internal code to be evaluated against the extensional database. The procedural code includes the primitives for communication with the RDBMS, and the control structures needed to perform the fixed point evaluation of re-

266

cursive queries. Additional primitives are provided to efficiently perform the relational operations directly in main memory. The procedural code generation is strictly connected to a second level of optimization which we shall call physical optimization, in sense that it strongly depends on the physical allocation of the database, i.e., on the extensional parameters and the access structure in the mass storage database (MSDB), managed by Oracle, and on the current status of the Main Memory Database. The third layer corresponds to the evaluation phase, which is performed by the Fixed-point Evalnator. This module interacts on one end with the ttDBMS, to which it may directly request the evaluation of expression of the relational algebra, and on the other end with the MMDB. The latter is used to store the intermediate results as temporary relations, and to efficiently perform in main memory the operations that are required during the fixed point evaluation. The prototype has been implemented on a Sun Sparcl workstation, running Oracle version 6 under Unix. The performance of the prototype has been studied on a sample workload that has been randomly generated for the purpose. The database is the typical family database, with a relation Parent of 50000 tuples, and a relation Person of 30000 tuples. More precisely, the relation Parent is structured as a layered graph with 6 layers of 5000 nodes each, and two arcs entering and two arc leaving each node. The sample workload included several queries. For the non recursive queries the response times were compared to that of the equivalent queries directly submitted to Oracle through the SQLPLUS interactive interface. The times were indeed pretty much the same. This because, in such cases, the system adopts the strategy of directly translating into SQL expression which is entirely executed by Oracle. As a sample recursive query we used the same-generation, that has been indeed heavily used in the literature. The query was run for several values of the constant. In fact, referring to the layered structure of the relation graph, the execution cost depends on the layer to which belongs the node corresponding to the constant in the query. More precisely (assuming a linear cost for the joins) the cost goes exponentially with the number of layers that are traversed. Some experimental results are reported in Table 1 for several values of the node layer. The table gives the total elapsed time and the time spent by Oracle. Considering the size of the relation and the number of layer, these data seem to be quite satisfactory, although a direct comparison is not easy, since most of the systems presented in the literature work in main memory and with considerably smaller relations.

267

References 1. F. Banchilon, R. Ramakrishnan, An amateur's introduction to recursive query processing strategy, Proc. ACM SIGMOD Conf. on Managment of Data, 16-52, 1986. 2. F.Cacace, S.Ceri, S. Crespi Reghizzi, L. Tanca, R. Zicari, Integrating object oriented data modeling with a rule-based programming paradigm, Pvoc. A C M SIGMOD Conf. on the Management of Data, Atlantic City, 1990. 3. S.Geri, S. C'respi Reghizzi, G. Lamperti, L. Lavazza, R. Zicari, Algres: an advanced database system for complex applications, IEEE Software, July 1990. 4. S. Ceri, G. Gottlob, G. Wiederhold, Efficient Database Access Through Prolog, IEEE Transactions on Software Engineering, Feb. 1989. 5. D. Chimenti, R. Gamboa, R. Krishnarnurty, S. Naqvi, S. Tsur, C. Zaniolo, The LDL System Prototype, IEEE Transactions on Knowledge and Data Engineering, Vol. 2, No. 1, March 1990. 6. A.Formiea, M.Missikoff; Adding Integrity Constraints to Object-Oriented Database; Proc. of the ISMM First International Conference on Inforvnation and Knowledge Management (CIKM 9~), Baltimore, Maryland, 1992. 7. S. Greco, M. Romeo, D. Sacc~., Evaluation of Negative Logic Programs, in this volume. 8. H.Lam, M.Missikoff; Mosaico: A Specification and Rapid Prototyping Environment for Object-Oriented Database Applications; Tech Report, IASI, Jan. 1993. 9. N. Leone, M. Romeo, P. Rullo, D. Sacc~, Effective Implementation of Negation in Database Logic Query Languages, in this volume. 10. G. Pbipps, M. A. Derr, K.A. Ross, Glue-NAIL!: A deductive database system, Proc. A C M SIGMOD Conference, Denver, USA, June 1991. 11. R. Ramakrishnan, D. Srivastava, S. Sudarshan, CORAL - Control, Relations and Logic, Proc. 18th VLDB Conference, Vancouver, Canada, August 1992. 12. D. Sacca', C. Zaniolo, The generalized counting method for recursive logic queries, Proc. ICDT, Rome, LNCS 243, 1986. 13. D. Sacca', C. Zaniolo, Magic counting methods, Proc. ACM SIGMOD Conf. on Managment of Data, 49-59, 1987. 14. S. Salza, L. Pichetti, Logibase: an efficient implementation of a rule based interface to a commercial database management system, V-th Int. Conf. on Systems of Data and Knowledge Bases, Lvov, URSS, Sept. 1991. 15. J.D. Ullman, Principles of Database and Knowledge-Base Systems, Vol. 1 and 2, Computer Science Press, Rockville, Md., 1989. 16. J. Vaghani, K. Ramamohanarao, D. Kemp, Z. Somogyi, P. Stuckey, The Aditi deductive database systems, Proc. of the NACLP'90 Workshop on Deductive Database Systems, Austin, USA, October 1990.

268

8

Figures and Tables

creation modification addition F1

v] canonical form generation of an ODL schema

F2

canonical ODL schema

well for medness check

subsumption computation

minimal ODL Schema computed ISA relations table F i g . 1. O D L - D e s i g n e r ' s F u n c t o n a l A r c h i t e c t u r e

incoherent classes an types

269

Schema \

w

\

/ ",,,

,/

"~UserInterface~

I Sintactical-Semantical Analizer / Cyclesl~econgniserJ

CanonicalForm~'~ Generator J J J

I I

j

I

89

J

Incoherent ClassandTypes

f r~xonomlc -%=

(Canonical~ Schema. J

Fig.2. ODL-Designer:CREATEF~dnction

Schema

Computed ISARelations Table

270

~, Application user

~( Design team member Result of f DB application / analysis ~

Object DB test cases

I~

,

~

~ h I

I Tool

~9 ss~ ..........1..................

~

++

I -

9

l

i qu'ery I

/

[Schema Editor ] i l and Browser .'k ~ - ~ l Semantic I Verification Module

l | '

,

[iobie~DB"ii i . ~ Generator ~ i

i

r

I .. Object D )~

IPrototype

!I c,^.s !l ('_~"Y~,,. ~.t "] Code iI "~. . . . . . . Ii ' :.................................. :

Specif cation of DB application domain

F i g . 3. Functional Architecture o f Mosaico

I

I

~

271

Q•-

Answer

Programs/ Schema

I~=i he

Query-

Fig. 4. Architecture of the PATRIOT prototype

272

INTERACTI V E USER RULE-BASED

INTEFACE ~,.~,,~ ~..~~.,~

OPTIMIZER REWRITTEN RULES MMDB

GENERATOR& t

CODE

EDB CATALOG

-'~'-"t,..Ys,c..oPT,,,,z~. l

PROCEDURAL CODE

EVALUATO~

ORACLE RDBMS

/

MAINMEMORY DATABASE (MMDB) Fig. 5. The LOGIBASE+ prototype architecture.

273

layer result cardin~lity e l a p s e d t i m e Oracle t i m e 0

683

109.4 sec

31.5 sec

1

167

23.7 sec

8.5 sec

2

42

6.3 sec

2.2 sec

3

10

2.2 sec

0.6 sec

4

3

1.6 sec

0.4 sec

T a b l e 1. Performance on the saxne-generation query

Lecture Notes in Computer Science For information about Vols. 1-620 please contact your bookseller or Springer-Verlag

-

Vol. 621: O. Nurmi, E. Ukkonen (Eds.), Algorithm Theory SWAT '92. Proceedings. VIII, 434 pages. 1992.

Vol. 643: A. Habel, Hyperedge Replacement: Grammars and Languages. X, 214 pages. 1992.

Vol. 622: F. Schmalhofer, G. Strube, Th. Wetter (Eds.), ContemporaryKnowledge Engineering and Cognition. Proceedings, 1991. XII, 258 pages. 1992. (Subseries LNAI).

Vol. 644: A. Apostolico, M. Crochemore, Z. Galil, U. Manber (Eds.), Combinatorial Pattern Matching. Proceedings, 1992. X, 287 pages. 1992.

Vol. 623: W. Kuieh (Ed.), Automata, Languages and programming. Proceedings, 1992. XlI, 721 pages. 1992. Vol. 624: A. Vomnkov (Ed.), Logic Programming and Automated Reasoning. Proceedings, 1992. XlV, 509 pages. 1992. (Subseries LNAI).

Vol. 645: G. Pernul, A M. Tjoa (Eds.), Entity-Relationship Approach - ER '92. Proceedings, 1992. XI, 439 pages, 1992. Vol. 646: J. Biskup, R. Hull (Eds.), Database Theory ICDT '92. Proceedings, 1992. IX, 449 pages. 1992.

Vol. 625: W. Vogler, Modular Construction and Partial Order Semantics of Petri Nets. IX, 252 pages. 1992.

Vol. 647: A. Segall, S. Zaks (Eds.), Distributed Algorithms. X, 380 pages. 1992.

Vol. 626: E. B6rger, G. J~iger, H. Kleine Biining, M. M. Richter (Eds.), Computer Science Logic. Proceedings, 1991. VIII, 428 pages. 1992.

Vol. 648: Y. Deswarte, G. Eizenberg, J.-J. Quisquater (Eds.), Computer Security - ESORICS 92. Proceedings. XI, 451 pages. 1992.

Vol. 628: G. Vosselman, Relational Matching. IX, 190 pages. 1992.

Vol. 649: A. Pettorossi (Ed.), Meta-Programming in Logic. Proceedings, 1992. XII, 535 pages. 1992.

Vol. 629: I. M. Havel, V. Koubek (Eds.), Mathematical Foundations of Computer Science 1992. Proceedings. IX, 521 pages. 1992.

Vol. 650: T. Ibaraki, Y. Inagaki, K. lwama, T. Nishizeki, M. Yamashita (Eds.), Algorithms and Computation. Proceedings, 1992. XI, 510 pages. 1992.

Vol. 630: W. R. Cleaveland (Ed.), CONCUR '92. Proceedings. X, 580 pages. 1992.

Vol. 651: R. Koymans, Specifying Message Passing and Time-Critical Systems with Temporal Logic. IX, 164 pages.

Vol. 631: M. Brnynooghe, M. Wirsing (Eds.), Programming Language Implementation and Logic Programming. Proceedings, 1992. XI, 492 pages. 1992. Vol. 632: H. Kirchner, G. Levi (Eds.), Algebraic and Logic Programming. Proceedings, 1992. IX, 457 pages. 1992.

1992.

Vol. 652: R. Shyamasundar (Ed.), Foundations of Software Technology and Theoretical Computer Science. Proceedings, 1992. XII1, 405 pages. 1992.

Vol. 633: D. Pearce, G. Wagner (Eds.), Logics in AI. Proceedings. VIII, 410 pages. 1992. (Subseries LNAI).

Vol. 653: A. Bensoussan, J.-P. Verjus (Eds.), Future Tendencies in Computer Science, Control and Applied Mathematics. Proceedings, 1992. XV, 371 pages. 1992.

Vol. 634: L. Boag6, M. Cosnard, Y. Robert, D. Trystram (Eds.), Parallel Processing: CONPAR 92 - VAPP V. Proceedings. XVII, 853 pages. 1992.

Vol. 654: A. Nakamura,M. Nivat, A. Saoudi, P. S. P. Wang, K. Inoue (Eds.), Parallel Image Analysis. Proceedings, 1992. VIII, 312 pages. 1992.

Vol. 635: J. C. Derniame (Ed.), Software Process Technology. Proceedings, 1992. VIII, 253 pages. 1992.

Vol. 655: M. Bidoit, C. Choppy (Eds.), Recent Trends in Data Type Specification. X, 344 pages. 1993.

Vol. 636: G. Comyn, N. E. Fuchs, M. J. Ratcliffe (Eds.), Logic Programming in Action. Proceedings, 1992. X, 324 pages. 1992. (Subseries LNAI).

Vol. 656: M, Rusinowitch, J. L. R6my (Eds.), Conditional Term Rewriting Systems.Proceedings, 1992. XI, 501 pages. 1993.

Vol. 637: Y. Bekkers, J. Cohen (Eds.), Memory Management. Proceedings, 1992. XI, 525 pages. 1992.

Vol. 657: E. W. Mayr (Ed.), Graph-Theoretic Concepts in Computer Science. Proceedings, 1992. VIII, 350 pages. 1993.

Vol. 639: A. U. Frank, I. Campari, U. Formentini (Eds.), Theories and Methods of Spatio-Temporal Reasoning in Geographic Space. Proceedings, 1992. XI, 431 pages. 1992. Vol. 640: C. Sledge (Ed.), Software Engineering Education. Proceedings, 1992. X, 451 pages. 1992. Vol. 641: U. Kastens, P. Pfahler (Eds.), Compiler Construction. Proceedings, 1992. VIII, 320 pages. 1992. Vol. 642: K. P. Jantke (Ed.), Analogical and Inductive Inference. Proceedings, 1992. VIII, 319 pages. 1992. (Subseries LNAI).

Vol. 658: R. A. Rueppel (Ed.), Advances in Cryptology EUROCRYPT '92. Proceedings, 1992. X, 493 pages. 1993. Vol. 659: G. Brewka, K. P. Jantke, P. H. Schmitt (Eds.), Nonmonotonie and Inductive Logic. Proceedings, 1991. VIII, 332 pages. 1993. (Sabseries LNAI). Vol. 660: E. Lamma, P. Mello (Eds.), Extensions of Logic Programming. Proceedings, 1992. VIII, 417 pages. 1993. (Subseries LNAI).

Vol. 661: S. J. Hanson, W. Remmele, R. L. Rivest (Eds.), Machine Learning: From Theory to Applications. VIII, 271 pages, 1993.

Vol. 684: A. Apostolico, M. Crochemore, Z. Galil, U. Manber (Eds.), Combinatorial Pattern Matching. Proceedings, 1993. VIII, 265 pages. 1993.

Vol. 662: M. Nitzberg, D. Mumford, T. Shiota, Filtering, Segmentation and Depth. VIII, 143 pages. 1993.

Vol. 685: C. Rolland, F. Bodart, C. Cauvet (Eds.), Advanced Information Systems Engineering. Proceedings, 1993. XI, 650 pages. 1993.

Vol. 663: G. v. Bochmann, D. K. Probst (Eds.), Computer Aided Verification. Proceedings, 1992. IX, 422 pages. 1993. Vol. 664: M. Bezem, J. F. Groote (Eds.), Typed Lambda Calculi and Applications. Proceedings, 1993. VIII, 433 pages. 1993. Vol. 665: P. Enjalbert, A. Finkel, K. W. Wagner (Eds.), STACS 93. Proceedings, 1993. XIV, 724 pages. 1993. Vol. 666: J. W. de Bakker, W.-P. de Roever, G. Rozenberg (Eds.), Semantics: Foundations and Applications. Proceedings, 1992. VIII, 659 pages. 1993. Vol. 667: P. B. Brazdil (Ed.), Machine Learning: ECML 93. Proceedings, 1993. XII, 471 pages. 1993. (Subseries LNAI). Vol. 668: M.-C. (3audel, J.-P. Jouannaud (Eds.), TAPSOFT '93: Theory and Practice of Software Development. Proceedings, 1993. XII, 762 pages. 1993. Vol. 669: R. S. Bird, C. C. Morgan, J. C. P. Woodcock (Eds.), Mathematics of Program Construction. Proceedings, 1992. VIII, 378 pages. 1993. Vol. 670: J. C. P. Woodcock, P. (3. Larsen (Eds.), FME '93: Industrial-Strength Formal Methods. Proceedings, 1993. XI, 689 pages. 1993. Vol. 671: H. J. Ohlbach (Ed.), GWAI-92: Advances in Artificial Intelligence. Proceedings, 1992. XI, 397 pages. 1993. (Subseries LNAI). Vol. 672: A. Barak, S. Guday, R. G. Wheeler, The M(3SIX Distributed Operating System. X, 221 pages. 1993. Vol. 673: G. Cohen, T. Mora, O. Moreno (Eds.), Applied Algebra, Algebraic Algorithms and Error-Correcting Codes. Proceedings, 1993. X, 355 pages 1993. Vol. 674: G. Rozenberg (Ed.), Advances in Petri Nets 1993. VII, 457 pages. 1993. Vol. 675: A. Mulkers, Live Data Structures in Logic Programs. VIII, 220 pages. 1993.

Vol. 686: J. Mira, J. Cabestany, A. Prieto (Eds.), New Trends in Neural Computation. Proceedings, 1993. XVII, 746 pages. 1993. Vol. 687: H. H. Barrett, A. F. Gmitro (Eds.), Information Processing in Medical Imaging. Proceedings, 1993. XVI, 567 pages. 1993. Vol. 688: M. (3authier (Ed.), Ada - Europe '93. Proceedings, 1993. VIII, 353 pages. 1993. Vol. 689: J. Komorowski, Z. W. Ras (Eds.), Methodologies for Intelligent Systems. Proceedings, 1993. XI, 653 pages. 1993. (Subseries LNAI). Vol. 690: C. Kirchner (Ed.), Rewriting Techniques and Applications. Proceedings, 1993. XI, 488 pages. 1993. Vol. 691: M. Ajmone Marsan (Ed.), Application and Theory of Petri Nets 1993. Proceedings, 1993. IX, 591 pages. 1993. Vol. 692: D. Abel, B.C. Ooi (Eds.), Advances in Spatial Databases. Proceedings, 1993. XIII, 529 pages. 1993. Vol. 693: P. E. Lauer (Ed.), Functional Programming, Concurrency, Simulation and Automated Reasoning. Proceedings, 1991/1992. XI, 398 pages. 1993. Vol. 694: A. Bode, M. Reeve, G. Wolf (Eds.), PARLE '93. Parallel Architectures and Languages Europe. Proceedings, 1993. XVII, 770 pages. 1993. Vol. 695: E. P. Klement, W. Slany (Eds.), Fuzzy Logic in Artificial Intelligence. Proceedings, 1993. VIII, 192 pages. 1993. (Subseries LNAI). Vol. 696: M. Worboys, A. F. Grundy (Eds.), Advances in Databases. Proceedings, 1993. X, 276 pages. 1993. Vol. 697: C. Courcoubetis (Ed.), Computer Aided Verification. Proceedings, 1993. IX, 504 pages. 1993. Vol. 698: A. Voronkov (Ed.), Logic Programming and Automated Reasoning. Proceedings, 1993. XIII, 386 pages. 1993. (Subseries LNAI).

Vol. 676: Th. H. Reiss, Recognizing Planar Objects Using Invariant Image Features. X, 180 pages. 1993.

Vol. 699: G. W. Mineau, B. Moulin, J. F. Sowa (Eds.), Conceptual Graphs for Knowledge Representation. Proceedings, 1993. IX, 451 pages. 1993. (Subseries LNAI).

Vol. 677: H. Abdulrab, J.-P. P~cuebet (Eds.), Word Equations and Related Topics. Proceedings, 1991. VII, 214 pages. 1993.

Vol. 700: A. Lingas, R. Karlsson, S. Carlsson (Eds.), Automata, Languages and Programming. Proceedings, 1993. XI1, 697 pages. 1993.

Vol. 678: F. Meyer auf der Heide, B. Monien, A. L. Rosenber 8 (Eds.), Parallel Architectures and Their Efficient Use. Proceedings, 1992. XII, 227 pages. 1993.

Vol. 701: P. Atzeni (Ed.), LOGIDATA+: Deductive Databases with Complex Objects. VIII, 273 pages. 1993.

Vol. 679: C. Fermllller, A. Leitsch, T. Tammet, N. Zamov, Resolution Methods for the Decision Problem. VIII, 205 pages. 1993. (Subseries LNAI). Vol. 681: H. Wansin 8, The Logic of Information Structures. IX, 163 pages. 1993. (Subseries LNAI). Vol. 682: B. Bouchon-Meunier, L. Valverde, R. R. Yager (Eds.), IPMU '92 - Advanced Methods in Artificial Intelligence. Proceedings, 1992. IX, 367 pages. 1993. Vol. 683: G.J. Milne, L. Pierre (Eds.), Correct Hardware Design and Verification Methods. Proceedings, 1993. VIII, 270 Pages. 1993.