Deductive database languages: problems and solutionsmengchi/papers/ddb-CS99.pdfCORAL [Ramakrishnan et al. 1994], Aditi [Vaghani et al. 1994], LogicBase [Han et al. 1994], Declare/SDS

Deductive Database Languages: Problems and SolutionsMENGCHI LIU

University of Regina

Deductive databases result from the integration of relational database and logicprogramming techniques. However, significant problems remain inherent in thissimple synthesis from the language point of view. In this paper, we discuss theseproblems from four different aspects: complex values, object orientation, higher-orderness, and updates. In each case, we examine four typical languages thataddress the corresponding issues.

Categories and Subject Descriptors: H.2.3 [Database Management]: Languages—Data description languages (DD); Data manipulation languages (DM); Querylanguages; Database (persistent) programming languages; H.2.1 [DatabaseManagement]: Logical Design—Data models; Schema and subschema; I.2.3[Artificial Intelligence]: Deduction and Theorem Proving—Deduction (e.g.,natural, rule-base); Logic programming; Nonmonotonic reasoning and beliefrevision; I.2.4 [Artificial Intelligence]: Knowledge Representation Formalismsand Methods—Representation languages; D.1.5 [Programming Techniques]:Object-oriented Programming; D.1.6 [Programming Techniques]: LogicProgramming; D.3.2 [Programming Languages]: Language Classifications; F.4.1[Mathematical Logic and Formal Languages]: Mathematical Logic—Logic andconstraint programming

General Terms: Languages, Theory

Additional Key Words and Phrases: Deductive databases, logic programming,nested relational databases, complex object databases, inheritance, object-orienteddatabases

1. INTRODUCTION

Databases and logic programming aretwo independently developed areas incomputer science. Database technologyhas evolved in order to effectively andefficiently organize, manage and main-tain large volumes of increasingly com-plex data reliably in various memorydevices. The underlying structure of da-tabases has been the primary focus ofresearch that has led to the develop-

ment of various data models. The mostwell-known and widely used data modelis the relational data model [Codd1970]. The power of the relational datamodel lies in its rigorous mathematicalfoundations with a simple user-levelparadigm and set-oriented, high-levelquery languages. However, the rela-tional data model has been found inex-pressive for many novel database appli-cations. During the past decade, many

Author’s address: Department of Computer Science, University of Regina, Regina, Saskatchewan S4S0A2, Canada; email: [email protected] to make digital / hard copy of part or all of this work for personal or classroom use is grantedwithout fee provided that the copies are not made or distributed for profit or commercial advantage, thecopyright notice, the title of the publication, and its date appear, and notice is given that copying is bypermission of the ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute tolists, requires prior specific permission and / or a fee.© 1999 ACM 0360-0300/99/0300–0027 $5.00

ACM Computing Surveys, Vol. 31, No. 1, March 1999

more expressive data models and sys-tems have been developed, such as theER model [Chen 1976], RM/T [Codd1979], TAXIS [Mylopoulos et al. 1980],SDM [Hammer and McLeod 1981], DA-PLEX [Shipman 1981], SHM1 [Brodie1984], Gemstone [Maier et al. 1986],Galileo [Albano et al. 1985], SAM*[Su1986], Iris [Fishman et al. 1987], IFO[Abiteboul and Hull 1987], the one forEXODUS [Carey et al. 1988], Orion[Kim 1990a; 1990b], O2 [Deux et al.1991], Jasmine [Ishikawa et al. 1993],Fabonacci [Albano et al. 1995], ODMG[Cattell 1996], and others.

Logic programming is a direct out-growth of earlier work in automatic the-orem proving and artificial intelligence.It is based on mathematical logic, whichis the study of the relations betweenassertions and deductions and is for-malized in terms of proof and modeltheories. Proof theory provides formalspecifications for correct reasoning withpremises, while model theory prescribeshow general assertions may be inter-preted with respect to a collection ofspecific facts. Logic programming is pro-gramming by description. It uses logicto represent knowledge and uses deduc-

tion to solve problems by deriving logi-cal consequences. The most well-knownand widely used logic programming lan-guage is Prolog [Colmerauer 1985; Kow-alski 1988; Sterling and Shapiro 1986],which uses the Horn clause subset offirst-order logic as a programming lan-guage and the resolution principle as amethod of inference with well-definedmodel-theoretic and proof-theoretic se-mantics [Lloyd 1987]. However, Prologlacks expressiveness in a number of ar-eas. Over the past several years, a num-ber of richer and more expressive logicprogramming languages have been pro-posed and implemented, such as LOGIN[Aït-Kaci and Nasr 1986], LIFE [Aït-Kaci and Nash 1986], HiLog [Chen et al.1993], Prolog11 [Moss 1994], Gödel[Hill and Lloyd 1994], Oz [Smolka1995], Mercury [Somogyi et al. 1996],XSB [Rao et al. 1997], etc.

Important studies on the relations be-tween logic programming and relationaldatabases have been conducted forabout two decades, mostly from a theo-retical point of view [Gallaire andMinker 1978; Gallaire 1981; Jacobs1982; Ullman 1982; Maier 1983]. Rela-tional databases and logic programminghave been found quite similar in theirrepresentation of data at the languagelevel. They have also been found com-plementary in many aspects. Relationaldatabase systems are superior to thestandard implementations of Prologwith respect to data independence, sec-ondary storage access, concurrency, re-covery, security and integrity [Tsur andZaniolo 1986]. The control over the exe-cution of query languages is the respon-sibility of the system, which uses queryoptimization and compilation tech-niques to ensure efficient performanceover a wide range of storage structures.However, the expressive power andfunctionality of relational databasequery languages are limited comparedto that of logic programming languages.Relational languages do not havebuilt-in reasoning capabilities. Besides,relational query languages are oftenpowerless to express complete applica-

CONTENTS

1. Introduction2. Complex-Value Deductive Languages

2.1 LDL2.2 COL2.3 Hilog2.4 Relationlog

3. Object-Oriented Deductive Languages3.1 O-Logic3.2 F-Logic3.3 ROL3.4 IQL

4. Schema and Higher-Order Features4.1 HiLog4.2 L2

4.3 F-logic4.4 ROL

5. Updates5.1 Prolog5.2 DLP and Its Extension5.3 DatalogA and LDL5.4 Transaction Logic

6. Conclusion

28 • M. Liu


tions, and are thus embedded in tradi-tional programming languages, result-ing in impedance mismatch [Maier1987] between programming and rela-tional query languages. Prolog, on theother hand, can be used as a general-purpose programming language. It canbe used to express facts, deductive in-formation, recursion, queries, updates,and integrity constraints in a uniformway [Reiter 1984; Sterling and Shapiro1986].

The integration of logic programmingand relational database techniques hasled to the active research area of deduc-tive databases [Gallaire et al. 1984; Ceriet al. 1990; Grant and Minker 1992].This combines the benefits of the twoapproaches, such as representationaland operational uniformity, reasoningcapabilities, recursion, declarative que-rying, efficient secondary storage ac-cess, etc. The function symbols of Pro-log, which are typically used forbuilding recursive functions and com-plex data structures, have not beenfound useful for operating over rela-tional databases made up of flat rela-tions. As a result, a restricted form ofProlog without function symbols calledDatalog (with negation), with a well-defined declarative semantics based onthe work in logic programming, hasbeen widely accepted as the standarddeductive database language [Ullman1989a; Ceri et al. 1990].

In the past few years, various set-oriented evaluation strategies specificfor deductive databases have been themain focus of extensive research [Ban-cilhon et al. 1986; Bancilhon and Ra-makrishnan 1986; Beeri and Ra-makrishnan 1991; Ceri et al. 1990;Ioannidis and Ramakrishnan 1988;Jiang 1990; Mumick et al. 1996; Saccaand Zaniolo 1987; Ullman 1989a; Ull-man 1989b] and a number of deductivedatabase systems or prototypes basedon Datalog have been reported. Theseinclude Nail [Morris et al. 1986], LOLA[Freitag et al. 1991], Glue-Nail [Derr etal. 1993], XSB [Sagonas et al. 1994],CORAL [Ramakrishnan et al. 1994],

Aditi [Vaghani et al. 1994], LogicBase[Han et al. 1994], Declare/SDS [Kie-bling et al. 1994] etc. See Ramakrish-man and Ullman [1995] for a survey ofthese deductive database systems. De-ductive database systems have beenused in a variety of application domainsincluding scientific modeling, financialanalysis, decision support, languageanalysis, parsing, and various applica-tions of transitive closure such as bill-of-materials and path problems [Ra-makrishman 1994]. They are bestsuited for applications in which a largeamount of data must be accessed andcomplex queries must be supported.

However, significant problems remaininherent in this kind of deductive data-base from the language point of view. Inthis paper, we investigate four problem-atic areas. The first one is that suchdeductive databases provide inexpres-sive flat structures and cannot directlysupport the complex values common innovel database applications. The secondis that object orientation offers some ofthe most promising ways of meeting thedemands of the most advanced databaseapplications, but it is not clear how toincorporate object orientation into de-ductive databases to increase their datamodeling capability. The third is thatcurrent deductive databases cannot nat-urally deal with schema and higher-order features in a uniform frameworkso that a separate, non-logic-based lan-guage is normally provided to specifyand manipulate the schema informa-tion. Finally, it is necessary to be able toupdate and modify a database, butthere is no immediately obvious way ofexpressing updates within a logicalframework. We elaborate these prob-lems and survey four typical languagesfor each area with consistent examples.

There are other significant issues rel-evant to deductive database languages.These include semantics of logic pro-grams with negation such as predicatestratification and fixpoint semantics[Apt et al. 1988], local stratification andperfect model semantics [Przmusinski1988], stable model semantics [Gelfond

Deductive Database Languages: Problems and Solutions • 29


and Lifschitz 1988; Przymusinski 1990],modularly stratified semantics [Ross1994], well-founded semantics [Gelderet al. 1991] and alternating fixpoint se-mantics [Gelder 1993]; non-Horn clauselogic programs such as disjunctive de-ductive databases [Fernández andMinker 1992a; Fernández and Minker1992b; Barback 1992; Subrahmanian1993], hypothetical reasoning [Bonner1989; Bonner 1990; Chen 1997; Inoue1994; Sattar and Goebel 1997]; con-straints [Brodsky 1993; Jaffar and Ma-her 1994; Grumbach and Su 1996], etc.However, we believe that a separatesurvey is more appropriate for theseissues. Indeed, the languages we surveyhere deal only with predicate stratifica-tion and fixpoint semantics.

Throughout this paper, we follow theProlog convention and use words start-ing with upper-case letters for variablesand ”_” for anonymous variables.

2. COMPLEX-VALUE DEDUCTIVELANGUAGES

The relational data model, which im-poses the first normal form (1NF) re-striction, has been found to be inexpres-sive for many novel databaseapplications, such as engineering de-sign, graphic databases, CAD/CAM,etc., as these applications requireproper representation and manipulationof arbitrarily complex values with inter-nal structures. The nested relationaland complex-value data models [Abite-boul et al. 1987; Ozsoyogly and Yuan1987; Roth et al. 1987; Roth 1988; Colby1989; Levene and Loizou 1993; Abite-boul and Beeri 1995] developed duringthe past decade allow tuple componentsof a relation to be possibly nestedtuples, sets or even relations.

Datalog is based on 1NF relations andtherefore cannot support nested tuplesand sets. In fact, its predecessor Prologcan indirectly support nested tuples byusing functors. For example, we mayuse the following facts in Prolog to storeinformation about cars and their own-ers:

car~vehicle~ny_858778, chevy_vega, 1983!,owner~name~arthur, keller!,

getFrom~dealer!))

car~vehicle, ~ny_358735, volkswagen, 1990!owner~name~arthur, keller!,

getFrom~owner~name~kurt, godel!,getFrom~owner~name~norbert, wiener!,

getFrom~dealer!))))))

where vehicle, name, owner, getFromare functors that are not interpreted (orare freely interpreted) because theyhave no prior meanings.

Prolog also indirectly supports sets byusing lists. In Prolog, set expressionsare represented using the built-in pred-icate setof:

setof~X, P, S!

where P represents a goal or goals, X isa variable occurring in P, and S is a listwhose elements are sorted into a stan-dard order with no duplicates and canbe treated as a set. It is read as “The setof instances of X such that P is provableis S”. In other words, S 5 $XP%.

The problems with the setof predicatein Prolog are that it is based on listsand that it is not a first-order predicateso its semantics is not well-defined. Be-sides, the usage of lists as sets is notexpressive enough. The simple member-ship predicate has to specify detailsabout implementation, such as how toiterate over the lists. When a predicateinvolves more than one set, the programcan become quite complicated and non-intuitive, which is contrary to the gen-eral philosophy of declarative program-ming [Kuper 1990].

For this reason, Datalog has been ex-tended in the past several years to in-corporate tuple and/or set constructors[Kuper 1990; Beeri 1991; Abiteboul andGrumbach 1991; Liu 1998b]. In themeantime, Prolog has also been ex-tended to incorporate general-purposeset constructs and basic operations onsets [Dovier et al. 1996; Jayaraman1992; Hill and Lloyd 1994].

30 • M. Liu


In this section, we examine four dif-ferent Datalog extensions: LDL, COL,Hilog and Relationlog.

2.1 LDL

LDL (Logical Data Language) [Tsur andZaniolo 1986; Naqvi and Tsur 1989;Chimenti et al. 1990; Beeri et al. 1991]is the first language to extend Datalogto support complex values with well-defined semantics. It has been imple-mented at MCC. Like Prolog, LDL canindirectly support tuples by using func-tors. In addition, it directly supportssets.

Example 2.1 Consider the followingnested relation Dept2Employees:3

We can represent this relation in LDLby using the following two facts:

dept2employees~ cpsc,$empl~bob, $db, ai%!,empl~joe, $os, pl, db%!%!

dept2employees~ math,$empl~sam, $gt, cm, si%!,empl~tom, $ca%!%!

To support access to elements in a set,LDL allows the use of the member pred-icate ~[!. To support the construction

of sets with rules, LDL provides twopowerful mechanisms: set enumerationand set grouping. With set enumera-tion, a set is constructed by listing all ofits elements. With set grouping, a set isconstructed by defining its elementswith a property that they must satisfy.Several examples are given below.

Example 2.2 To derive a relation onsets of book titles from the book baserelation such that the total price of anythree different books does not exceed$100, we can use the following rule witha set enumeration term $X, Y, Z% inLDL:

book2deal~$X, Y, Z%! :- book~X, Px!,book~Y, Py!, book~Z, Pz!,X Þ Z, Y Þ Z,Px 1 Py 1 Pz , 100

Note that we can specify the cardinal-ity of the sets with set enumeration.This feature is not directly supported inProlog.

Example 2.3 Consider the relationparentof represented as facts in LDL asfollows:

parentof~bob, pam!parentof~bob, tom!

The following set-grouping rule in LDLgroups all parents of a person into a setand obtains parentsof~bob, $ pam,tom%!, where ^Y& is a set-groupingterm:

parentsof~X, ^Y&! :- parentof~X, Y!

Unlike set enumeration, we cannotspecify the cardinality of the sets withset grouping.

In LDL, programs must be predicate-stratified (or layered) based on groupingand negation in order to have a seman-tics. Given a rule of the form A :- L1,..., Ln, where n $ 0, if Li is negated orA has grouping, then this rule must beevaluated after the rules whose heads

Dept_Employees

Dept Employees

Name Areas

Area

cpsc bob db

ai

joe os

pl

db

math sam gt

cm

si

tom ca



have the same predicate symbol as Li,for each 1 # i # n. That is, each Limust be completely known when weevaluate this rule. Whether or not aprogram is predicate-stratified can bedetermined statically based on the pred-icate symbols in the program.

There are three significant limita-tions in LDL. First, the grouping mech-anism is restricted to a single rulerather than to a set of rules (or a pro-gram).

Example 2.4 Consider the followingfacts:

fatherof~bob, pam!motherof~bob, tom!

We cannot use the following groupingrules in LDL to group all parents of aperson into a set and obtain parentsof~bob, $ pam, tom%!:

parentsof~X, ^Y&! :- fatherof~X, Y!parentsof~X, ^Y&! :- motherof~X, Y!

as they actually generate parentsof~bob, $ pam%! and parentsof ~bob,$tom%! instead. We have to introduce anintermediate relation parentof and useit to obtain the desired result, as shownin Example 2.3.

The second problem is that groupingrequires predicate stratification, whichmakes direct recursive definition of anested relation impossible.

Example 2.5 Consider the followingtwo rules:

ancestorsof~X, ^Y&! :- parentsof~X, S!, Y [ S

ancestorsof~X, ^Y&! :- parentsof~X, S1!, Z[ S1,ancestorsof~Z, S2!, Y [ S2

Here we intend to define the nestedrelation ancestorsof directly and recur-sively. However, we cannot achievewhat we intend in LDL as grouping isrestricted to a single rule and grouping

requires us to know the parentsof andancestorsof relations in the body be-fore we can evaluate the ancestorsofrelation in the head in the second rule.One way around this problem is to in-troduce a flat intermediate relationancestorof as follows:

ancestorof~X, Y! :- parentsof~X, S!, Y [ S

ancestorof~X, Y! :- parentsof~X, S1!, Z [ S1,ancestorof~Z, Y!

ancestorsof~X, ^Y&! :- ancestorof~X, Y!

Finally, it is cumbersome to accessdeeply nested data and to nest/unnestrelations, since we must be proceduralby introducing intermediate variablesand/or relations.

Example 2.6 Consider the LDL factsin Example 2.1 and two queries:

(1) Find the employee names in thecomputer science department foremployees whose research areas in-clude DB.

(2) Find if AI is a research area foremployees.

We can represent them in LDL asfollows by starting from the top leveland gradually getting to the level wewant and introducing intermediatevariables S1 and S2:

? 2 dept2employees~cpsc, S1!,empl~X, S2! [ S1,db [ S2.

? 2 dept2employees~_, S1!,empl~_, S2! [ S1,ai [ S2

Example 2.7 The nested relationDept_Employees in Example 2.1 can beobtained from the following normalizedrelation Dept_Employee_Area by usingthe nest operation of extended rela-tional algebra defined in Roth et al.[1988] twice.

32 • M. Liu


In order to obtain Dept_Employeesfrom Dept_Employee_Area in LDL, wehave to use grouping several times andintroduce several intermediate relationsas follows:

r1~D, E, Â&! :- dept2employee2area~D, E, A!

r2~D, empl~E, As!! :- r1~D, E, As!

dept2employees~D, Ês&! :- r2~D, Es!

2.2 COL

COL (Complex Object Language) [Abite-boul and Grumbach 1991] is a typedextension of Datalog that supports com-plex values directly. Unlike LDL, whichuses functor objects for tuples indi-rectly, COL directly supports tuples,tuple constructors and sets.

The nested relation Dept_Employeesin Example 2.1 can be represented inCOL as follows:

dept2employees~cpsc, $@bob, $db, ai%#,@joe, $os, pl, db%#%!

dept2employees~math, $@sam, $gt, cm, si%#,@tom, $ca%#%!

A novel feature of COL is the use ofinterpreted functors called data func-tions in a deductive framework. Datafunctions play a crucial role in func-tional data models and in many seman-tic data models. Their use in COL pro-vides natural support for functionaldependencies in deductive databases. InLDL, functional dependencies are notsupported.

In COL, data functions and the mem-

ber predicate ~]! can be used to accesssets and to construct sets throughgrouping or enumeration. Unlike LDL,where sets are unnamed, data functionsin COL are used to name sets.

Consider the facts in Example 2.4again. The parentsof relation can bedefined in COL using the functor par asfollows:

par~X! ] Y :- fatherof~X, Y!

par~X! ] Y :- motherof~X, Y!

parentsof~X, par~X!!

The functor par is used to group everyparent Y of a person X into a set de-noted by par~X! and grouping can in-volve more than one rule. Note that theunique set of parents associated with Xis named by the data function par~X!.

In COL, we can group a set recur-sively using data functions.

Example 2.8 The task shown in Ex-ample 2.5 can be represented in COL asfollows:

anc~X! ] Y :- par~X! ] Y

anc~X! ] Y :- par~X! ] Z, anc~Z! ] Y

ancestors~X, anc~X!!

The set enumeration of LDL shown inExample 2.2 can be performed in COLusing a 0-ary functor f as follows:

f ] $X, Y, Z% :- book~X, Px!,book~Y, Py!, book~Z, Pz!,X Þ Y, X Þ Z, Y Þ Z,Px 1 Py 1 Pz , 100

book2deal~X! :- f ] X

As a result, COL allows grouping overseveral rules recursively with data func-tions. However, it is still cumbersome toaccess deeply nested data in order tonest/unnest relations.

To represent the two queries in Ex-ample 2.6 in COL, we still must intro-

Dept_Employee_Area

Dept Employee Area

cpsc bob dbcpsc bob aicpsc joe oscpsc joe plcpsc joe dbmath sam gtmath sam cmmath sam simath tom ca



duce intermediate functions f and g asfollows:

? 2 dept2employees~cpsc, f!,f ] @X, g#, g ] db

? 2 dept2employees~_, f!,f ] @_, g#, g ] ai

The following rules in COL show howto obtain the nested relation Dept Em-ployees in Example 2.1 from the normal-ized relation Dept_Employee_Area inExample 2.7:

f~D, E! ] A :- dept2employee2area~D, E, A!

r1~D, E, f~D, E!!

g~D! ] @E, As# :- r1~D, E, As!

dept2employees~D, g~D!!

As in LDL, programs in COL must bestratified as well in order to have awell-defined semantics. Stratification isbased on predicate and function sym-bols used in the program. Given a ruleof the form A :- L1, ..., Ln, n $ 0, if Liis negated or contains a data function,or A contains a data function, then thisrule must be evaluated after the ruleswhose heads have the same predicate orfunction symbol as Li or A, for each 1# i # n. As in LDL, whether or not aprogram is stratified can be determinedstatically based on the predicate andfunction symbols occurring in the pro-gram.

For the task shown in Example 2.5,we might like to use the following tworules instead of the rules in Example2.8 in COL:

anc~X! ] Y :-parents~X, S1!,S1 ] Z,ancestors~Z, S2!,S2 ] Y.

ancestors~X, anc~X!!.

However, they are not stratified andtherefore have no semantics in COL.

The stratification of COL has the fol-lowing limitation:

Example 2.9 [Adapted from Kiferand Wu [1993]] Consider the followingprogram in COL:

person~peter, $bridge%!person~tom, $chess, tennis%!person~tom, hobby~peter!!

hobby~X! ] Y :- person~X, S!, S ] Y

The intended meaning of these rules isthat Peter’s hobby is bridge and Tom’shobbies include chess and tennis andevery hobby of Peter’s is also a hobby ofTom’s. However, the program is notstratified and therefore has no meaning.

2.3 Hilog

Hilog [Chen and Chu 1989; Chen andKambayashi 1991] is a typed extensionof Datalog intended to solve some of theproblems of LDL. In Hilog, every set ortuple must be associated with a namethat can be viewed as an atom or afunctor of Prolog. The relation Dept_Employees in Example 2.1 can be repre-sented in Hilog by using one fact asfollows:

dept2employees$dept~cpsc,

employees$employee~bob,areas$db, ai%!,

employee~joe,areas$os, pl, db%!}),

dept~math,employees$employee~sam,

areas$gt, cm, si%!,employee~tom,

areas$ca%!})}

Note that the names associated withtuples and sets must be unique (uniquename assumption). In the above exam-ple, we cannot change the name deptemployees to employees as the latter isused inside the relation.

Sets in Hilog have a special meaning.For example, areas$db, ai% does not

34 • M. Liu


mean that the set consists of db and ai.Instead, it means that db and ai areelements of the set, and is equivalent toareas$db% and areas$ai%. With thisspecial meaning, we can directly accessdeeply nested data either by givingtheir nested structure or using theunique name associated with them. Thetwo queries in Example 2.6 can then berepresented in Hilog directly as followswithout introducing any intermediatesymbols:

? 2 dept~cpsc, employees$employee~X, areas$db%!%!

? 2 dept2employees$dept~_, employees$employee~_, areas$ai%!%!}

With the unique-name assumption,nested terms in Hilog can be directlyused as atoms. Therefore, the secondquery above can be simply representedas follows:

? 2 areas$ai%

The nested relation Dept_Employeesin Example 2.1 can be obtained from thenormalized relation Dept_Employee_Area in Example 2.7 by using just therule:

dept~X, employees$employee~Y, areas$Z%!%! :-dept2employee2area~X, Y, Z!

This set mechanism naturally sup-ports grouping that involves severalrules. The parentsof relation can be ex-pressed in Hilog as follows:

parentsof~X, parents$Y%! :- fatherof~X, Y!

parentsof~X, parents$Y%! :- motherof~X, Y!

This set mechanism does not requirestratification. The task shown in Exam-ple 2.5 can be represented in Hilog asfollows:

ancestorsof~X, ans$Y%! :- parentsof~X, par$Y%!

ancestorsof~X, ans$Y%! :- parentsof~X, par$Z%!,ancestorsof~Z, ans$Y%!

The unstratified COL program in Ex-

ample 2.9 can be expressed in Hilog asfollows:

person~peter, hobbies$bridge%!

person~tom, hobbies$chess, tennis%!

person~tom, hobbies$X%! :-person~peter, hobbies$X%!

However, the special treatment ofsets in Hilog has its limitations since itdoes not allow us to specify explicitlywhat a set exactly contains. Therefore,the set enumeration of LDL is not sup-ported. Another problem with Hilog isthat the unique-name assumption is notpractical for large databases.

The Hilog language is not higher-or-der in the sense that we cannot usevariables for the names associated withthe sets and tuples. In Section 4.1, wediscuss a true higher-order languagethat has a similar name: HiLog.

2.4 Relationlog

Relationlog (Relation LOGic) [Liu 1995;1998b] is another typed extension ofDatalog with powerful set and tupleconstructors. It has been implementedat the University of Regina [Liu andShan 1998; Shan and Liu 1998]. Rela-tionlog combines the best features ofLDL, COL and Hilog. It directly sup-ports complex values as COL. Thenested relation Dept_Employees in Ex-ample 2.1 can be represented in Rela-tionlog in the same way as in COL.

Relationlog allows negation, supportsHilog’s special set treatment with par-tial set terms, and eliminates theunique-name assumption. A partial setterm has the form ^X, Y, Z& and corre-sponds to a Hilog set term p$X, Y, Z%for some name p. It also supports setenumeration in LDL with complete setterms. A complete set term is of theform $X, Y, Z% and corresponds to anLDL set-enumeration term of the sameform.

Unlike set-grouping terms in LDL,partial set terms in Relationlog can ap-



pear not only in the head but also in thebody of a rule. When a partial set termappears in the body, it denotes part of aset, as in Hilog. When appearing in thehead, it is used to group a set as in LDL.Several rules can be used to group thesame set.

Consider Example 2.4 again. The par-entsof relation can be directly defined inRelationlog as follows:

parentsof~X, ^Y&! :- fatherof~X, Y!

parentsof~X, ^Y&! :- motherof~X, Y!

Here two rules are used to group thesame set.

As in LDL and COL, programs mustbe stratified in order to have a seman-tics. Stratification is based on predicatesymbols used in the program. Given arule of the form A :- L1, ..., Ln where n$ 0, if Li is negated or contains a com-plete set term, then this rule must beevaluated after the rules whose headhas the same predicate symbol as Li, foreach 1 # i # n. As in LDL and alsoCOL, whether or not a program is strat-ified can be determined statically basedon the predicate symbols occurring inthe program.

As the use of partial set terms in thehead does not require stratification, theancestorsof relation in Example 2.5 canbe defined recursively in Relationlog asfollows:

ancestorsof~X, ^Y&! :- parentsof~X, ^Y&!

ancestorsof~X, ^Y&! :-parentsof~X, ^Z&!,ancestorsof~Z, ^Y&!

As in Hilog, deeply nested data can bedirectly accessed in Relationlog withpartial set terms. The two queries inExample 2.6 can be represented in Rela-tionlog directly as follows, without in-troducing any intermediate symbols:

? 2 dept2employees~cpsc, ^@X, ^db&#&!? 2 dept2employees~_, ^@_, âi&#&!

We can obtain the nested relationDept_Employees in Example 2.1 fromthe normalized relation Dept_Employee_Area in Example 2.7 by using only onerule, as in Hilog:

dept2employee~X, ^@Y, ^Z&#&! :-

dept2employee2area~X, Y, Z!

The unstratified COL program in Ex-ample 2.9 can be expressed clearly as astratified program in Relationlog as fol-lows:

person~peter, $bridge%!

person~tom, ^chess, tennis&!

person~tom, ^X&! :- person~peter, ^X&!

The first fact says that Peter has ex-actly one hobby, which is bridge. Thesecond fact says that Tom’s hobbies in-clude chess and tennis. The rule statesthat every hobby of Peter’s is also ahobby of Tom’s.

Relationlog has the following limita-tions. First, while it supports incom-plete sets by using partial set terms, itdoes not support incomplete tuples (i.e.,tuples with null values), which are com-mon in database applications. For ex-ample, the tuple fatherof~tom, '!,representing that Tom’s father is un-known, cannot be represented in Rela-tionlog. Therefore, it is not clear whatthe meanings of recursive rules arewhen both incomplete sets and tuplesappear. Next, since the complete setterms in Relationlog cannot containpartial set terms, it is not possible tohave a set of which we know the cardi-nality but for which we do not havecomplete knowledge of some of the ele-ments, such as $â, b&, $b, c%%. Besides,there is no easy way to query sets of aparticular cardinality in Relationlog,such as sets of cardinality $ 2 or # 2.Finally, being a complex-value lan-guage, Relationlog is lacking in its data-modeling power, as we discuss in thenext section.

36 • M. Liu


3. OBJECT-ORIENTED DEDUCTIVELANGUAGES

Object-oriented concepts have evolvedin three different disciplines: first inprogramming languages, then in artifi-cial intelligence, and then in databases(since the end of the 60’s). Indeed, objectorientation offers some of the mostpromising ways to meet the demands ofmany advanced database applications.In this section, we first introduce thefundamental principles of the object-ori-ented data models and then examinetheir applications in deductive databaselanguages.

Object Identity In a value-orienteddatabase, keys, which are values, areused to represent objects in the realworld. A fundamental problem withsuch a representation of objects is thatkeys are subject to updates. Updating akey causes a break in the continuity inthe representation of the object. Fur-thermore, care must be taken to updateall tuples and sets that refer to thisobject to reflect the change. Object-ori-ented databases permit the explicit rep-resentation of real-world objectsthrough the use of object identifiers,which are different from values in thedatabase. A unique object identifierwithin the entire database is assignedto each object that can be represented inthe database and this association be-tween object identifier and object re-main fixed. Unlike values, an objectidentifier can be created or destroyedbut cannot be updated. Two objects aredifferent if they have different objectidentifiers even if they have the sameattribute values. Whether or not theuser can access object identifiers variesfrom system to system.

Complex Values Each object is asso-ciated with a value, which may be com-plex. The value associated with the ob-ject can contain object identifiers sothat two objects can share an object byreferencing the same object identifier.Updates to the values of the sharedobject do not affect the objects that refer

to it. The value part of an object is alsocalled its state [Beeri 1989; Kim 1990a].

Objects Since an object in the realworld is associated with an object iden-tifier and a value in an object-orienteddatabase, a natural question is what anobject is in a database. There are twokinds of views in object-oriented data-bases. One view is that everything is anobject; that is, classes, object identifiers,atomic values, tuples, and sets are allobjects. Objects are related to eachother through attributes. The attributevalues of an object can change but notthe object itself. With this view, at-tributes of objects can be expressed interms of functions and all attribute val-ues together form a tuple. This view isused in Iris [Fishman et al. 1987] andJasmine [Ishikawa 1993]. This viewnaturally incorporates functional andmultivalued dependencies. The otherview is that the pair of object identifierand its associated value together is anobject. This view is used in the object-oriented data models O2 [Lecluse andRichard 1989], Orion [Kim 1990a;1990b] and ODMG-93 [Cattell 1996].The first view results in a simpler se-mantics, which is very important for alogic-based language, while the secondview allows object identifiers to identifynot only tuples but also atomic valuesand sets.

Methods Objects in an object-ori-ented database are manipulated withmethods. A method has a name, a signa-ture, and an implementation. The nameand signature provide an external inter-face to the method. The implementationis typically written in an extended pro-gramming language.

Classes A class is a set of objects thathave exactly the same internal struc-ture and therefore the same attributesand the same methods. The class towhich an object belongs is called theimmediate, proper or primary class ofthe object. A class directly captures theinstance-of relationship between an ob-ject and the class to which it belongs. Inaddition, it provides the basis on which



a query may be formulated. It also de-fines the attributes and methods of itsinstances. It is sometimes useful to al-low an object to belong to more than oneclass. However, in most systems, an ob-ject must belong to only one class forperformance reasons. In this case, anobject is said to have a unique primaryclass. As we show shortly, inheritancemakes it possible for an object to belonglogically to more than one class.

Class Hierarchies and Inherit-ance Classes are organized into classhierarchies, which capture the generali-zation relationship between a class andits subclasses. Subclasses inherit theattributes and methods of their super-classes. An instance of a subclass logi-cally belongs to its superclasses. Inher-itance enables us to reduce theredundancy of the specification whilemaintaining its completeness. Inherit-ance normally takes place betweenclasses, whereas instances are com-pletely “sterile” in the object-orienteddata models. A subclass can modify theattributes/methods inherited. This mod-ification is called overriding. In addi-tion, some attributes/methods definedin a superclass may not be applicable toits subclass. In this case, a subclassmust block (or cancel) their inheritance.Inheritance can be single or multiple. Inthe case of single inheritance, the sub-class hierarchy forms a tree; in the caseof multiple inheritance, the subclass hi-erarchy forms a DAG. Multiple inherit-ance is more elegant than single inher-itance, but conflicts may arise when anattribute/method name is defined in twoor more superclasses. Several ap-proaches are used to resolve an ambigu-ity. One is user-specified priority, whichrelies on the user to define a priorityamong the super classes whose at-tributes/methods are inherited. Anotherone is explicit renaming, which requiresthat all attributes/methods inheritedmust have distinct names. Overridingcan also be used to resolve ambiguities.Unfortunately, there is still no consen-sus for the underlying semantics of mul-tiple inheritance.

Encapsulation Encapsulation de-rives from the notion of abstract datatypes in programming languages. In anobject-oriented database, objects encap-sulate data and methods to be appliedon these data. Encapsulation requiresthat information about a given objectcan be manipulated only by means ofthe methods defined for the object. Theuser or application program cannot di-rectly examine or modify the value orthe methods associated with the object.Therefore, encapsulation provides anabstract interface to the object andachieves some kind of logical data inde-pendence. It is a very useful notion fordata modeling.

3.1 O-Logic

The object-oriented approach was firstapplied to a deductive framework in O-logic (Object Logic) [Maier 1986], whichwas in turn based on the logic program-ming language LOGIN [Aït-Kachi andNasr 1986]. It treats object identifiersand atomic values as objects that can berelated to each other through at-tributes. Classes can be used but arenot objects.

Example 3.1 The following is an O-logic program:

joe : employee@name 3 “Joe”,position 3 prof,works 3 cs]

sam : employee@name 3 “Sam”,position 3 inst,works 3 cs]

cs : dept@name 3 “ComputerScience”,head 3 joe]

prof : rank@name 3 “Professor”,pay 3 2000]

inst : rank@name 3 “Instructor”,pay 3 1000]

E : employee@salary 3 S# :-E : employee@position 3 R#,R : rank@pay 3 S#

38 • M. Liu


where employee, dept, rank areclasses, joe, sam, cs, prof, inst areobject identifiers, and name, position,works, head, pay, salary are at-tributes. The facts provide informationabout employees, departments, and payrate of professors and instructors. Therule specifies how to infer the salary ofeach employee.

In O-logic, tuples and sets are notallowed. The objects can have arbitraryattributes but no structural or behav-ioral information can be defined or de-clared on their classes and therefore noinheritance is supported.

As rules can be used, a fundamentalproblem is how to generate objects withrules. This issue is not properly ad-dressed in O-logic.

Example 3.2 Consider the followingrule in O-logic:

P : interesting2pair@employee 3 E,manager 3 M] :-

E : employee@name 3 N, works 3 D#D : dept@manager 3 M :

employee@name 3 N#]

where P, E, M, D, and N are variables,and interesting2pair, employee, anddept are classes. The intended meaningof this rule is that if the employee’sdepartment’s manager’s name coincideswith the employee’s name, then the pairof employee and manager is interestingand an object identifier should be cre-ated for this pair by using the variableP that occurs only in the head.

The problem with the rule in Example3.2 is that it is not clear how the vari-able P should be quantified [Kifer andWu 1993]. Universal quantification overP obviously does not make sense. It issuggested in Maier [1986] that P shouldbe existentially quantified as ~@E!~@M!~@N!~?P!. However, the argu-ment for such a quantification is not

well substantiated. It is pointed out inKifer and Wu [1993] that the correctquantification should be ~@E!~@M!~?P!~@N!. Both happen to work herebecause E and M functionally deter-mine N. If the label name is set-valued,the two quantifications will yield differ-ent results. There is no obvious way ofchoosing between these two quantifica-tions using only the syntactic structureof the rule. The problem is that thevariable P does not appear in the rulebody so that the rule is not domain-independent [Abiteboul 1995].

3.2 F-Logic

An extended O-logic based on O-logicwas first proposed in Kifer and Wu[1993], followed by a more general F-logic (Frame Logic) in Kifer and Lausen[1989] and Kifer et al. [1995] as a solu-tion to the problems of O-logic. F-logichas been partially implemented at Uni-versität Freiburg in Germany [Frohn etal. 1997]. It treats atomic values, objectidentifiers, functor objects, even at-tribute and classes as objects. It allowsthe declaration of attributes on classesand supports attribute inheritance.

Example 3.3 The following is an ex-ample of an F-logic program:

person@name f string,age f integer,parents ff person]

employee : : personjoe : employeetom : personpam : person25 : integer“Joe” : stringjoe@name 3 “Joe”,

age 3 25,parents33$tom, pam%]

where person, employee, integer, andstring are classes, while joe, tom, pam,25 and “Joe” are object identifiers. Thesymbols “::” and “:” denote subclass rela-



tionship and class membership respec-tively. The statement employee::personsays that employee is a subclass of per-son, joe:employee says that joe is aninstance of the class employee, etc. At-tributes applicable to the class personare declared by using double-shafted ar-rows f and ff , where the former isfor scalar attribute definitions and thelatter for set-valued attribute defini-tions. They are inherited by the sub-class employee. Attribute values of theobject joe are represented by using sin-gle-shafted arrows 3 and 33, wherethe former is for scalar values and thelatter for set values, corresponding todouble-shafted arrows.

F-logic is a powerful deductive lan-guage with a well-defined semanticscompared to O-logic. It supports functorobjects and sets. It also allows the use offunctor objects as classes, attributes,and object identifiers. The interesting-pair rule of O-logic in Example 3.2 canbe represented in F-logic as follows:

f~E, M! : interesting2pair@employee 3 E, manager 3 M# :-

E : employee@name 3 M : string, works 3 D#D : dept@manager3M : employee@name3 N#

where f is a functor and the rule infersfunctor objects such as f~bob, sam! asinstances of the class interesting pair.

This object-creation mechanism isalso used in the object-oriented deduc-tive languages C-logic [Chen and War-ren 1989] and LIVING IN A LATTICE[Heuer and Sander 1993].

Unlike O-logic, which only supportssimple attributes, F-logic supports pa-rameterized attributes. For example, wecan have the following program in F-logic:

person@children2with@person ff person#bob@children2with@liz33$tom, pam%#bob@children2with@ann33$ jim%#

F-logic has several drawbacks. First,

there is no distinction between classesand objects, since the domains forclasses and objects are the same. Theycan be distinguished only from theiroccurrences in the program. The at-tribute declaration information cannotreally be strictly separated from at-tribute value information in F-logic. Asa result, there is no clear separationbetween the notions of schema and in-stance, which is essential for databasesystems.

F-logic is a pure object-oriented de-ductive language. It does not directlysupport relationships as do in value-oriented deductive languages discussedin the previous section. It only supportsmonotonic multiple attribute inherit-ance, and does not support attributeoverriding and blocking.

In F-logic, sets are not treated as ob-jects and cannot have attributes. Func-tor objects cannot contain sets. As aresult, the object-creation mechanism inF-logic is limited, since we cannot cre-ate objects directly based on some sets.Furthermore, the arguments associatedwith attributes cannot be sets either.

The treatment of sets in F-logic is thesame as in Hilog. For a statementbob@age 3 30#, 30 is the value of theattribute age of bob. If a set is involved,the semantics is different. For a state-ment bob@children33$jim, pat%#, theset $jim, pat% does not mean that it isthe value of the children of bob. Instead,it means it is part (subset) of the setvalue and therefore it is possible to haveanother statement such asbob@children33$sam%#. The (com-plete) value of children of bob is theunion of all such partial values that canbe inferred from the program. This spe-cial treatment allows the completevalue of a set-valued attribute to beinferred in a number of steps using sev-eral rules. The following is an example:

X@ancestors33$Y%# :- X@parents33$Y%#

X@ancestors33$Y%# :- X@parents33$Z%#,Z@ancestors33$Y%#

40 • M. Liu


As in Hilog, this unique treatment ofsets makes it impossible to specify thecomplete value of a set-valued attribute.For example, if we know that tom andpam are the two parents of joe, we canonly use the statement:

joe@parents33$tom, pam%#

which will not prevent additional per-sons from being inferred as joe’s parent.

Next, F-logic is an untyped languagewith a complicated syntax and seman-tics full of various symbols. However,important features such as typing andunique primary class (the lowest classin the class hierarchy where the objectis an instance of) for objects are notbuilt into the semantics, but are dealtwith using axioms. In terms of program-ming, this means that the user shouldtake care of them by properly includingcorresponding axioms into the programsif he wants his program to be typed orobjects to have unique primary class. Aswell, the notion of typing expressed inaxioms can only be applied to attributevalues rather than functor objects.

Finally, F-logic does not support be-havioral object-oriented features suchas methods and encapsulation.

3.3 ROL

ROL (Rule-based Object Language) [Liu1996; 1998a] is a recently proposed ob-ject-oriented deductive language imple-mented at the University of Regina [Liuet al. 1998]. It is based on F-logic andsolves some of the problems of F-logicdiscussed above.

Unlike F-logic, ROL is a typed lan-guage. Objects and classes are strictlydistinguished and function at two differ-ent levels: schema and instance. At theschema level, we declare classes, at-tributes on classes, and subclasses. Theattribute declarations of a class con-strain the instances of the class. At theinstance level, we use facts and rules toprovide extensional and intensional in-formation about objects. In addition,ROL allows both partial and complete

information about set-valued attributeto be specified by supporting limitedforms of partial and complete set termsof Relationlog.

The F-logic program in Example 3.3can be expressed equivalently in ROLas follows:

Schemaperson@name f string,

age f integer,parents f $person%]

employee isa person

Factstom : personpam : personjoe : employee@name 3 “Joe”,

age 3 25,parents 3 ^tom, pam&]

where person, employee, integer, andstring are classes, joe, tom, and pamare object identifiers, and ^tom, pam&is partial set term. Unlike F-logic, ROLbuilds in value classes such as integer,string, real, etc. The symbols isa and :are used to denote immediate subclassrelationship and primary class member-ship respectively. The double-shaftedarrow f is used for both scalar andset-valued attribute definitions and thesingle-shafted arrow 3 is used forboth scalar and set-valued attribute val-ues. If we want to represent that tomand pam are the only parents of joe, wecan replace the partial set term ^tom,pam& with the complete set term$tom, pam%.

Unlike F-logic, ROL has a simple syn-tax and semantics. The semantics build-sin important object-oriented features,such as typing, multiple inheritanceand unique primary class. In ROL, func-tor objects are required to be typed withrespect to their class definitions. Forexample, functor objects interesting_pair~bob, sam! and list~1, list~2,list~3, nil!!! are instances of the func-



tor class interesting2pair andlist~integer, list!, respectively.

A novel feature of ROL is that itsfunctor classes generalize classes andrelations. Functor objects can directlyrepresent relationships in ROL. Theycan have attributes and can be used asattribute values. In addition, functor ob-jects can contain sets and thus are moregeneral than those in F-logic. As a re-sult, ROL subsumes predicate-stratifiedDatalog (with negation) and LDL with-out grouping and Relationlog withoutpartial set terms as special cases. Forexample, the following LDL rules arealso ROL rules:

int~s~X!! :- int~X!

ancestor~X, Y! :- parent~X, Y!

ancestor~X, Y! :- parent~X, Z!,ancestor~Z, Y!

book2deal~$X, Y, Z%! :- book~X, Px!,book~Y, Py!, book~Z, Pz!X Þ Y, X Þ Z, Y Þ Z,Px 1 Py 1 Pz , 100

The interesting-pair rule in Example3.2 can be represented in ROL as fol-lows:

interesting2pair~E, M! :-E : employee@name 3 N, works 3 D#,D : dept@manager 3 M#,M : employee@name 3 N#

Here, a typed functor object interest-ing_pair ~E, M! that has no separateidentifier is used for each interesting-pair object, whereas in F-logic, an un-typed functor object of the class interest-ing_pair is used as an identifier for theassociated interesting pair.

ROL supports non-monotonic multi-ple attribute inheritance, as discussedin Borgida [1988], whereas F-logic sup-ports only monotonic multiple attributeinheritance. Subclasses in ROL can in-herit attribute declarations of their su-perclasses and can also override suchinheritance.

Example 3.4 In an international cou-rier service address database, we mayhave three classes address, us_address(for U.S.A.), cn_address (for Canada), sothat us_address and cn_address aresubclasses of address. We may definethe attribute postcode of address on in-teger which also applies to instances ofus_address. However, the postcode forcn_address must be defined on string.Therefore, cn_address should overridethe inherited attribute declaration ofpostcode from address. This can beachieved in ROL with the followingclass definitions, but is not supported inF-logic:

address@..., postcode f integer#

us2address isa address

cn2address isa address@postcode f string#

In ROL, a subclass can also block theinheritance from its superclasses to it-self and to its subclasses by using thebuilt-in class none.

Example 3.5 Consider the classesperson, french, orphan, and french_or-phan where french, and orphan can bedefined as subclasses of person and fren-ch_orphan as a subclass of both frenchand orphan. If we declare attributesfather, mother, and age for person, thenit is meaningful for french to inherit oroverride all attribute declarations fromperson, but not meaningful for orphanand french_orphan to inherit father andmother attributes. That is, orphan andfrench_orphan should block the inherit-ance of attribute father and mother fromperson. This intended semantics is nat-urally supported in ROL using the fol-lowing class definitions:

person@father f person,mother f person,age f integer]

42 • M. Liu


orphan isa person@ father f none,mother f none]

french isa person

french2orphan isa french, orphan

Even if french overrides (more accu-rately, refines) the attributes fatherand mother as follows:

french isa person@ father f french,mother f french]

the attribute father and mother are stillblocked in french_orphan because of theuse of none. If we insist that french_or-phan have mother nun, then we can usethe following class definition to overridethe inheritance blocking:

french2orphan isa french, orphan@mother f nun#

Another novel feature of ROL is thatsets are treated as first-class citizens asvalues, object identifiers, and functorobjects, so that sets can also have at-tribute. For example, we can have thefollowing class definition and fact inROL:

$person%@count f integer#

$tom, pam%@count 3 2#

ROL has the following limitations.First, like F-logic, an object identifier inROL can directly identify only a tuplebut not a set or an atomic value. ROL’streatment of classes is not generalenough as there are only two layers,objects and classes, and classes cannotbe treated as objects (or meta objects).In ConceptBase [Jarke et al. 1995],there can be infinite layers of objects:ordinary objects, classes, metaclasses,etc. Besides, parameterized attributesof F-logic are not supported in ROL.Another problem with ROL is that dif-

ferent classes not related by the sub-class relationship cannot have at-tributes of the same name.

Although ROL is a deductive lan-guage that supports both object-ori-ented and value-oriented approaches,its support for the value-oriented ap-proach is limited as it does not supportgrouping in functor objects. Its partialand complete set mechanisms are not asgeneral as those in Relationlog.

Finally, behavioral object-orientedfeatures such as methods and encapsu-lation are not supported in ROL.

3.4 IQL

IQL (Identity Query Language) [Abite-boul and Kanellakis 1989] is a typeddeductive database language based onthe object-oriented data model O2. As inO2, an object in IQL is a pair of objectidentifier and value. Unlike F-logic andROL, the value in an IQL object can benot only a tuple, but also a set or anatomic value. For example, we can havethe following objects for a family in IQL:

~o1, @name : “Bob”, spouse : o2,children : o5, phone : o6])

~o2, @name : “Liz’, spouse : o1,children : o5, phone : o6

~o3, @name : “Tom”, phone : o6#!

~o4, @name : “Pam”, phone : o6#!

~o5, $o3, o4%!

~o6, 1234567!

In this example, object identifiers o1,o2, o3 and o4 identify tuples, o5 identi-fies a set, while o6 identifies an atomicvalue. If this family changes its phonenumber or add another child, only onesimple update is needed.

In IQL, the value associated with anobject identifier can be accessed by us-ing the object identifier dereferencingoperator ˆ. For example, o 1, o 5 denotethe tuple @name : “Bob”, spouse : o2,



children : o5, phone : o6# and the set$o3, o4%, respectively.

IQL directly supports relations in ad-dition to classes. In pure object-orienteddata models such as O2 and ODMG-93,many-to-many relationships betweenobjects are difficult to deal with. Butthey can be represented in IQL by usingrelations. Indeed, using object identifi-ers for every object is burdensome andproblematic in object-oriented deductivelanguages, and a pure value-orientedapproach has been argued to be betterin this regard [Ullman 1991]. With di-rect support for relations, IQL combinesthe benefits of the relational and object-oriented approaches.

In F-logic and ROL, object identifiersare simply constants that can be intro-duced explicitly in facts and rules by theuser. In IQL, object identifiers are sys-tem-created, as in object-oriented pro-gramming languages. They can be cre-ated only by using rules that havevariables occurring in the head, but notin the body as in O-logic. This may beviewed as a syntactic variation of thenew construct in object-oriented pro-gramming languages. Unlike O-logic,there is a well-defined semantics forthis object-creation mechanism.

The intended interesting_pair rule inExample 3.2 can be represented in IQLas follows:

pair~E, M! :-employee~E, N, D!,dept~D, M!,employee~M, N, D!

interesting2pair~O, E, M! :- pair~E, M!

O 5 @E, M# :- interesting2pair~O, E, M!

The first rule generates all pairs inthe relation pair. The second creates anobject identifier for each pair with therelation interesting_pair using the vari-able O that appears in the head but notin the body. The last rule assigns thepair to the object identified by the corre-sponding object identifier.

Object identity in IQL can be used notonly for object sharing and update man-agement, but also for set grouping asdata function of COL.

Example 3.6 The following rulesshow how to derive the relation ances-torsof from the relation parentsof usingobject identifiers as grouping in IQL.

temp~X, O! :- parentsof~X, Y!

O~Y! :- temp~X, O!, parentsof~X, Y!

O~Y! :- temp~X, O!, O~Z!, parentsof~Z, Y!

ancestorsof~X, O! :- temp~X, O!

The first rule is used to create an objectidentifier for the set of ancestors foreach person. The next two rules use theobject identifiers to group all ancestorsfor each person. The last rule generatesthe relation ancestorsof by dereferenc-ing object identifiers that identify sets.

Note that the rules in the above ex-ample must be stratified; that is, thelast rule should be evaluated after thefirst three rules. Unlike Datalog (withnegation), LDL, COL and Relationlog,in which stratification is automaticallydetermined based on predicate or func-tion symbols, in IQL we may not havesuch symbols to use, as shown in thesecond and third rule in Example 3.6.Therefore, the user of IQL must takecare of stratification by using programcomposition. The rules in Example 3.6should be organized into two programswith the first three rules in the first oneand the last in the second.

IQL’s object identifier-creation mech-anism is also used in object-orienteddeductive languages LOGRES [Cacaceetal. 1990] and LLO [Lou and Ozsoyoglu1991].

Like ROL, IQL is a typed language.There is a clear separation of the no-tions of instances and schema. Objectsand classes are strictly distinguishedand function at two different levels: in-stance and schema. At the schema level,

44 • M. Liu


we declare classes and their associatedtypes. The kinds of object identifiersthat can be created with rules are com-pletely determined by the types associ-ated with the classes for these objects.

IQL has the following problems: First,the object identifier-creation mecha-nism may lead to infinite loops and doesnot support a logic-oriented semantics,as discussed in Beeri [1990]. Indeed,two kinds of semantics are used to de-fine IQL, one for the underlying datamodel and one for the IQL language,which makes the language quite compli-cated and nonintuitive.

Second, IQL is so dependent on rela-tions that no objects can exist if thereare no relations. Therefore, it is not apure object-oriented deductive databaselanguage.

Another problem is that values suchas integers, strings, tuples, sets, etc.,cannot be treated as objects that haveproperties in IQL. They can appear onlyin the value part of an object. For amathematical database, we may storeintegers and their associated attributessuch as odd, even, prime, etc. For exam-ple, ~2, @even : true, prime : true#!.In this case, an integer is identified byitself rather than by a separate identi-fier. The cases for tuples and sets arethe same.

In addition, separating relations fromclasses suffers the same problems asso-ciated with the entity-relationshipmodel. For example, relationships canonly include classes, while classes can-not include relationships and relation-ships cannot include relationships.

Finally, the schema supported by IQLis quite limited. It does not supportimportant object-oriented features suchas attribute inheritance or behavioralobject-oriented features such as meth-ods and encapsulation. Indeed, how toincorporate methods and encapsulationin an object-oriented deductive frame-work remains an open problem.

4. SCHEMA AND HIGHER-ORDERFEATURES

A database usually has a schema thatprovides the description of the databasestructure, constrains data in the data-base and query results, and guaranteespart of the consistency of the database.In relational database systems, sche-matic information is also stored in rela-tions and the same relational languagescan be used to query not only data butalso the schema.

However, the notion of schema is notproperly supported in deductive data-base languages, because they are basedon the logic programming language Pro-log, which is inherently not typed. In-deed, the semantics of schema is notwell defined in most deductive frame-works.

In Datalog, predicates correspond torelation names. In order to reason aboutschematic information, we need to usepredicate variables that belong to high-er-order logic. However, higher-orderlogics have been met with skepticism,since the unification problem is unde-cidable. A non-logic-based language hasbeen used to specify the schematic infor-mation in a few implemented deductivedatabase systems such as LDL, andsuch information cannot be queried, letalone by using a logic-based language.

Prolog actually combines first-orderlogic, higher-order constructs, andmeta-level programming in one workingsystem, so that generic predicates suchas transitive closure and sorting can bedefined, predicates can be passed as pa-rameters and returned as values, andpredicates and rules can be queried.

Example 4.1 Prolog provides abuilt-in binary predicate current_predi-cate ~Name, Term! that can be used tounify Name with the name of a user-defined predicate, and Term with themost general term corresponding to thatpredicate. Consider the following rulesin Prolog:



relation~X! :- current2predicate~X, Y!

structure~Y! :- current2predicate~X, Y!

The first rule defines a relation to col-lect all predicates (relation names) inthe database. The second rule defines arelation to collect all predicate struc-tures (predicates and their arguments)in the database.

Unfortunately, the semantics of Pro-log is based on first-order logic, whichdoes not have the wherewithal to sup-port any of these features. Therefore,they have an ad hoc status in logicprogramming.

In this section, we examine four high-er-order languages that can be used toreason about schematic information indeductive databases: HiLog, L2, F-logicand ROL. The first two are value ori-ented, while the last two are object ori-ented.

4.1 HiLog

In first-order logic, predicates and func-tions have different roles. Predicatesare used to construct atoms, while func-tions are used to construct terms thatare embedded in other terms or atoms.Predicate and function symbols havefixed arities. However, it has beenshown from Prolog applications that itis very useful to let a symbol be used asboth predicate and function with vari-ous arities.

HiLog (Higher-order Logic) [Chen etal. 1993] generalizes such a usage andgives it a well-defined declarative se-mantics. Note that HiLog here is differ-ent from Hilog discussed in Section 2.3.There are only two kinds of symbols inHiLog, parameters with various arities(or arityless) and variables. Parameterscan function as predicates, functionsand constants depending on the context.Terms are formed with parameters andvariables in the usual way and mayrepresent individuals, terms, and atomsin different contexts.

In first-order logic, unary relations

can be viewed as sets intensionally. InHiLog, unary parameterized terms canbe viewed as sets in the same way. Forexample, part of the relation in Exam-ple 2.1 can be represented in HiLog asfollows:

areas~bob!~db!areas~bob!~ai!areas~joe!~os!areas~joe!~pl!areas~joe!~db!

employees~cpsc!~bob, areas~bob!!employees~cpsc!~joe, areas~joe!!

dept2employee~cpsc, employees~cpsc!!

As HiLog does not support extension-ally represented sets, we do not classifyit as a complex-value deductive lan-guage. However, variables can be usedin place of predicates in HiLog, so thatwe can use such variables to reasonabout schematic information.

Example 4.2 Consider the databaseconsisting of three relations: hardware,software, and admin, each of which rep-resents the employees in the respectivedepartments. The tuples in all threerelations have attributes name, age andsalary. We can define the following rela-tions with higher-order queries in Hi-Log:

p1~R! :- R~_, _, _!

p2~R! :- R~joe, _, _!

p3~N! :- R~N, _, _!

p4~N! :-R1~joe, A1, _!, R2~N, A2, _!,A1 , A2

p5~N1, N2! :-R1~N1, A, _!, R2~N2, A, _!,R1 Þ R2, N1 Þ N2

p6~N1, N2! :-R1~N1, _, S!, R2~N2, _, S!,N1 Þ N2

46 • M. Liu


p7~N! :-R~N, _, S!, ¬ R~N9, _, S9!,S , S9

The relation p1 collects the relationnames in the database. The relation p2

collects the department names (relationnames) to which joe belongs. The rela-tion p3 collects the names of employeesin the hardware, software and adminrelations. The relation p4 collects thenames of employees who are older thanJoe. The relation p5 collects the pair ofthe names of employees who have thesame age but are in different depart-ments. The relation p6 collects the pairof the names of employees who have thesame salary. The relation p7 collects thenames of employees who have the high-est salary in their department.

However, we cannot define a relationto collect all relation names in HiLogsince we must explicitly deal with thearity of each relation in order to querythe relation name, as shown in the firstrule in Example 4.2. Furthermore, wecannot query attributes as they are notrepresentable in HiLog. Therefore, wecannot define in HiLog the two relationsrelation and structure, as in Example4.1.

4.2 L2

L2 [Krishnamurthy and Naqvi 1988] is ahigher-order deductive database lan-guage based on LDL. The problems dis-cussed above are solved by introducingattributes into tuples and redefining thedatabase as a tuple.

Example 4.3 The database discussedin Example 4.2 can be defined in L2 as atuple as follows:

db 5 ~hardware : r1,software : r2,admin : r3)

where hardware, software and adminare attribute names that function aspredicates or relation names of the da-tabase tuple db, and r1, r2, r3 are corre-sponding relations, each of which is aset of tuples of the form ~name : ...,age : ..., salary : ...!. A specific at-tribute value joe in the relation hard-ware can be referenced with.hardware~.name 5 joe!. Besides 5,we can also use Þ, ,, #, ., and $.

In L2, each relation has an orderingof attributes in the tuples, so that at-tributes can be omitted according to thisordering. We can use variables for at-tribute names (relation names) and weneed not deal with their arity.

Example 4.4 Based on the databasein Example 4.3, we can define the fol-lowing relations with higher-order que-ries:

.p1~R! :- .R

.p2~R! :- .R~.name 5 joe!

.p3~N! :- .R~.name 5 N!

.p4~N! :-.R1~.name 5 joe, .age 5 A!,.R2~.name 5 N, .age . A!

.p5~N1, N2! :-.R1~.name 5 N1, .age 5 A!,.R2~.name 5 N2, .age 5 A!,R1 Þ R2

.p6~N1, N2! :-.R1~.name 5 N1, .salary 5 S!,.R2~.name 5 N2, .salary 5 S!,N1 Þ N2

.p7~N! :-.R~.name 5 N, .salary 5 S!,R ¬ ~.name Þ X, .salary . S!,

.p8~A! :- .hardware~.A!

.p9~R, Â&! :- .R~.A!



The relation p1 collects all relationnames in the database no matter whatarity they have. It is the L2 version ofthe first rule in Example 4.1. The rela-tions p2 to p7 are the same as in Exam-ple 4.2. The relation p8 collects all theattribute names of the relation hard-ware in the database. The relation p9

collects all relation names and their at-tributes, where Â& is a set-groupingterm. Its definition is more intuitivethan the second rule in Example 4.1.

A novel feature of L2 is the introduc-tion of replacement semantics as a solu-tion to higher-order unification. In bot-tom-up evaluation of rules in deductivedatabases, general unification is notneeded. Instead, only matching is used;that is, only one of the two terms con-tains variables. The higher-order vari-ables in L2 are limited to range overdatabase attributes. A rule with higher-order variables can be rewritten by re-placing the variables with attributes.The rewritten rules are in first-orderlogic and their meaning is well defined.Since the number of database attributesmust be finite, the language is decid-able. This approach is a natural andsimple way towards the integration ofthe definition and manipulation ofschema and data.

However, L2 does not have a notion ofschema. In the database in Example4.3, if one of the relations r1, r2, r3 isempty, then we have no structural in-formation such as name, age, and sal-ary. Furthermore, it is not required thattuples in a relation have the same form.For example, r1 can contain two tuples:~name : joe, age : 30, salary : 30K!and ~name : sam, wife : pam!. There-fore, the last two rules in Example 4.4are not really meaningful in this case.

4.3 F-logic

In pure object-oriented databases, wehave classes instead of relations. A class

denotes a set of objects that have com-mon attributes and prescribes the at-tributes applicable to their instances.Classes are organized into a subclasshierarchy such that the prescribed at-tributes of superclasses can be inheritedby the subclasses.

A natural question for object-orienteddatabases is how to reason about thesubclass hierarchy, attribute informa-tion of classes, and class and attributeinformation of objects. F-logic is thefirst object-oriented deductive languagethat supports reasoning about class andattribute information.

Example 4.5 The following is a por-tion of an F-logic program based on thedatabase discussed in Example 4.1. Ithas classes and subclass definitions andpart of the objects.

employee : : person

hardware : : employee

software : : employee

admin : : employee

joe : hardware

employee@name f string,age f integer,salary f integer,children ff person]

joe@name 3 ‘‘Joe’’,age 3 30,salary 3 30K,children33$bob, sam%]

. . .

Unlike L2, we can define attributeinformation for classes in F-logic. Eventhough we have no instances in theclass, the attribute information re-mains.

As discussed in Section 3, classes andattributes are also objects in F-logic.They differ from other objects in theiroccurrences in special places. Therefore,we can use variables for the places ofclasses and attributes and reason about

48 • M. Liu


class and attribute information in F-logic.

Example 4.6 For the F-logic programin Example 4.5, we can use the follow-ing rules with higher-order queries tocollect all classes, all attributes of theclass hardware, all attributes of eachclass, and all instances of each class inF-logic:

db@classes33$C%# :- C : : Ddb@classes33$C%# :- D : : Cdb@classes33$C%# :- O : Cdb@classes33$C%# :- C@A f D#db@classes33$C%# :- C@A ? D#db@classes33$C%# :- D@A f C#db@classes33$C%# :- D@A ? C#

employee@subclasses33$C%# :-C : : employee

hardware@attributes33$A%# :-hardware@A f C#

hardware@attributes33$A%# :-hardware@A ? C#

C@attributes33$A%# :- C@A f D#

C@attributes33$A%# :- C@A ff D#

C@instances33$O%# :- O : C

As shown in the above example, it iscumbersome to query all classes in F-logic. The reason is that F-logic does notdistinguish between ordinary objectsand classes. As a result, we have toquery all possible places for classes. Theuse of two kinds of arrows is somewhatburdensome, too. Similarly, it is alsocumbersome to query all immediatesubclasses, superclasses, and immedi-ate instances of a class in F-logic. Forexample, the following rules show howto collect all immediate subclasses1

C@immediate2subclasses33$D%# :-C : : D,¬C@intervening2class@D33$E%#

C@intervening2class@D33$E%# :-C : : E, E : : D,C Þ E, E Þ D

4.4 ROL

ROL [Liu 1996; 1998a] is another lan-guage that supports reasoning aboutsubclass hierarchy, attribute informa-tion of classes, and class and attributeinformation of objects. It has a clearnotion of schema and allows class andattribute variables in rules. The seman-tics of higher-order features of ROL isbased on replacement semantics of L2 sothat the language is still decidable.

Example 4.7 The F-logic program inExample 3.3 can be represented in ROLas follows:

Schemapersonemployee isa person

@name f string,children f $person%,phone f integer]

hardware isa employeesoftware isa employeeadmin isa employee

Factsjoe : hardware

@name 3 “Joe”,age 3 30,salary 3 30K,children 3 $bob, sam%]

. . .

In ROL, the user explicitly definesimmediate subclasses and primary classmembership using the symbols “isa”and “:”, respectively, based on whichgeneral subclasses and class member-ship can be derived using the symbols“isap” and “:p”, respectively.

Example 4.8 Consider the followingROL rules with higher-order queriesbased on the ROL program in Example4.7:1This example is due to one of the referees.



db@classes 3 ^C&# :- C

employee@subclasses 3 ^C&# :-C isap employee

hardware@attributes 3 Â&# :-hardware@A f _#

C@attributes 3 Â&# :- C@A f _#

C@immediate2subclasses 3 ^D&# :-D isa C

C@non2immediate2subclasses 3 ^D&# :-D isap C, ¬ D isa C

C@immediate2instances 3 Ô&# :- O : C

C@non2immediate2instances 3 Ô&# :-O :p C, ¬O : C

C@instances 3 Ô&# :- O :p C,

C@highest2paid2employee 3 O# :-O : C@salary 3 S1#¬O9 : C@salary 3 S2#,S1 , S2

The first five rules are the ROL versionsof the F-logic rules in Example 4.6. Thenext four collect all immediate sub-classes, all nonimmediate subclasses,all immediate instances and all nonim-mediate instances of of each class, re-spectively. The last rule finds the em-ployees who have the highest salary intheir department.

As discussed in Section 3, ROL’s func-tor classes can be used as relations.However, the higher-order mechanismused in ROL only allows us to query therelation schema and it is impossible toquery just the attributes in the rela-tions. In addition, the non-immediateand immediate features are cumber-some.

5. UPDATES

Like a relational database, a deductivedatabase also undergoes updates to ab-sorb new information. In the past de-cade, various methods to incorporateupdate constructs into logic-based lan-

guages have been proposed [Abiteboul1988; Abiteboul and Vianu 1991; Bon-ner and Kifer 1993; Bonner et al. 1993;Bonner and Kifer 1994; Bry 1990; Chen1997; de Maindreville and Simon 1988;Kakas and Mancarella 1990; Kowalski1992; Manchanda 1989; Montesi et al.1997; Naqvi and Krishnamurthy 1988;Naish et al. 1987; Reiter 1995; Wichertand Freitag 1997]. Indeed, modeling up-dates in logic-based languages is stillthe subject of substantial current re-search.

The important issues related to up-dates from a deductive database point ofview are:

(1) extensional and intensional data-base updates,

(2) nondeterministic updates,

(3) bulk or set-oriented updates,

(4) conditional updates.

In this section, we discuss four familiesof deductive languages that support up-dates, Prolog, DLP and its extension,DatalogA and LDL, and TransactionLogic, and show how they deal with theabove issues.

5.1 Prolog

In Prolog, the basic update primitivesare assert and retract. Assert is used toinsert a single fact or rule into the data-base. It always succeeds initially andfails when the computation backtracks.Facts and rules can be deleted from thedatabase in Prolog by using retract. Ini-tially, retract deletes the first clause inthe database that unifies with the argu-ment of retract. On backtracking, thenext matching clause is removed. Itfails when there are no remainingmatching clauses. Therefore, both ex-tensional and intensional databases canbe updated with Prolog.

Example 5.1 Let employee be a baserelation that stores the department andsalary of each employee. The followingquery in Prolog is used to fire employee

50 • M. Liu


Joe in the Toy department with a salaryof 10K and hire an employee Bob in theShoe department with a salary of 15K.

? 2 retract~employee~joe, toy, 10K!!,assert~employee~bob, shoe, 15K!!

Updates expressed in queries can beperformed only once. If the same kind ofupdates may be used more than once, itis better to write a general update ruleand then query the head of the rule forspecific updates.

Example 5.2 Let account be a baserelation that stores the balance of eachaccount. The following rule can be usedto withdraw money from an account:

withdraw~Acc, Amt! :-account~Acc, Bal1!,Bal1 $ Amt,Bal2 5 Bal1 2 Amt,retract~account~Acc, Bal1!!,assert~account~Acc, Bal2!!

If we want to withdraw $30 from theaccount a123, then we can use a query?- withdraw~a123,30!.

In Prolog, variables that occur only inthe body of a rule are existentiallyquantified. Therefore, updates in Prologcan be nondeterministic.

Example 5.3 Let course, section andsize be base relations where coursestores the sections for each course, sec-tion stores students for each section,and size stores the size of each section.The following Prolog rule can enroll astudent into one section of the coursewhose size is no more than 30 nondeter-ministically:

enroll~Student, Course! :-course~Course, Section!,size~Section, Num1!,Num1 , 30, Num2 5 Num1 1 1,retract~size~Section, Num1!!,assert~section~Section, Student!!,assert~size~Section, Num2!!

The nondeterminism is due to the vari-able Section, which occurs only in thebody of the rule and is therefore exis-tentially quantified.

Prolog uses a top-down, tuple-at-a-time, backtracking-based inferencemechanism for updates and queries. Forbulk updates, it resorts to recursive up-date rules in Prolog.

Example 5.4 Let employee be a baserelation as in Example 5.1. The follow-ing recursive rules can be used to giveevery employee an X% salary increasein Prolog:

raise~X!:- ¬employee~Name, Dept, Sal!

raise~X!:-retract~employee~Name, Dept, Sal1!!,Sal2 5 Sal1 1 Sal1pX,raise~X!,assert~employee~Name, Dept, Sal2!!

In order to give every employee a 10%salary increase, we can issue a query ?-raise~0.1!. If there are still employeesin the database, the second will nonde-terministically delete an employee, callthe query ?- raise~0.1! recursively, andthen insert the employee with a newsalary. In this way, the salary of eachemployee can be increased.

Unfortunately, the semantics of assertand retract is not well defined in Prolog.The exact effect of calling code contain-ing assert and retract is often difficult topredict. The resulting database updaterelies only on the operational semanticsof Prolog, rather than just the declara-tive semantics. The order of execution ofsubgoals is as important as the logicalcontent of the goal. For the rules inExamples 5.2, 5.3 and 5.4, changing theorder of emph assert or retract in thebody of the rules may yield differentresults. Many distributed Prolog sys-tems have versions of retract with bugsor strange behavior (sometimes called“features”). In an external or distrib-



uted database system, the problemswith assert and retract become muchmore severe. Multiuser access createseven more difficulties. In addition, thetuple-at-a-time, backtracking-based up-date mechanism of Prolog is not suit-able for deductive databases. The fol-lowing example shows another problemwith conditional updates in Prolog.

Example 5.5 Let employee be as inExample 5.1 and avg2sal an inten-sional relation based on employee thatgives the average salary of employees ineach department. Consider the follow-ing Prolog rule:

hire~Name, Dept, Sal! :-assert~employee~Name, Dept, Sal!!,avg2sal~Dept, Avg!, Avg # 50K

The intention here is to hire an em-ployee only if the average salary in thedepartment stays below 50K after hir-ing. However, in Prolog, if the averagesalary after hiring Bob is greater than50K, Bob has still been hired, sinceProlog does not undo updates duringbacktracking.

5.2 DLP and Its Extension

The notion of states is inherent in anynotion of updates. A state in Datalog isa set of base and derived relations. Up-dates cause transitions from a statethrough a state space, thereby changingthe database. Dynamic logic [Harel1979] is a logic for reasoning about pro-grams that test and change the valuesof an environment. It provides a naturalstate-transition semantics for updatesand is therefore used in several exten-sions of Datalog with updates.

DLP (Dynamic Logic Programming)[Manchanda and Warren 1988] is sucha Datalog extension. It allows only theextensional database to be updated. Theintensional database cannot be updated.

In DLP, predicate symbols are dividedinto three disjoint sets: base predicatesymbols, rule predicate symbols and dy-

namic predicate symbols. For everybase predicate symbol p, two associateddynamic predicate symbols 1p and 2pare used to specify basic addition anddeletion of tuples in the base relation p,respectively. Atoms formed using dy-namic predicate symbols are called dy-namic atoms.

An update query in DLP is of the form^D&~a! where D is a dynamic atom usedfor updates and a is a query. The up-dates specified in D are executed only ifthe query a is evaluated true after theupdates. If a is just true, then we cansimply use ^D& as an update query. As acan contain an update query, complexupdates can be expressed.

The updates in Example 5.1 can berepresented as a nested update query inDLP in two different ways as follows:

? 2 ^2 employee~joe, toy, 10K!&~^1 employee~bob, shoe, 15K!&!

? 2 ^2 employee~bob, shoe, 15K!&~^1 employee~joe, toy, 10K!&!

Update rules whose body contains up-date query can be used in DLP. Theupdates in Example 5.2 can be repre-sented as an update rule in DLP asfollows:

^withdraw~Acc, Amt!& :-^2 account~Acc, Bal1!&~Bal1 $ Amt, Bal2 5 Bal1 2 Amt,^1 account~Acc, Bal1!&)

To withdraw $30 from the accounta123, we can use an update query ?-^withdraw~a123,30!&.

As in Prolog, a top-down, tuple-at-a-time, backtracking-based inferencemechanism is used in DLP for both up-dates and queries. However, unlike Pro-log, it undoes updates during backtrack-ing. For the above query ?2^withdraw~a123,30!&, DLP first deletes the tupleaccount~a123, Bal1!. If Bal1 $ 30 is

52 • M. Liu


not true, DLP undoes the deletion dur-ing backtracking.

Like Prolog, DLP also supports non-deterministic updates as variables oc-curring in the body of a rule are existen-tially quantified. The nondeterministicupdate rule in Example 5.3 can be de-fined in DLP with a different orderingas follows:

ênroll~Student, Course!& :-course~Course, Section!,size~Section, Num1!,^1 section~Section, Student!&~Num1 , 30, Num2 5 Num1 1 1,^2 size~Section, Num1!&~^1 size~Section, Num2!&!!

If a course DB has two sections, thequery ? 2 enroll~joe, db! inserts Joeinto one section and then checks if it isfull. If so, it backtracks, undoes theinsertion, and tries another section.Therefore, if neither section is full, Joewill be enrolled nondeterministically ina section.

As an update query in DLP contains aquery part that must be evaluated true,we can express conditions that com-pleted updates must satisfy. For exam-ple, the conditional updates in Example5.4 can be represented as follows:

^hire~Name, Dept, Sal!& :-^1 employee~Name, Dept, Sal!&~avg2sal~Dept, Ave!, Avg # 50K

Given a query ? 2 ^hire~bob, toy,15K!&, if the average salary after hiringBob is greater than 50K, then Avg# 50K will fail. Therefore, the wholequery will fail and the update will beundone without leaving a residue in thedatabase.

As in Prolog, the bulk updates in Ex-ample 5.5 must be represented in DLPby recursive update rules as follows:

^raise~X!& :- ¬employee~Name,Dept,Sal!

^raise~X!& :-^2 employee~Name, Dept, Sal1!&~Sal2 5 Sal1 1 Sal1pX,!^raise~X!&~^1 employee~Name, Dept, Sal2!&!

Updates in DLP have an operationalsemantics with a left-to-right reading.In addition, its tuple-at-a-time, back-tracking-based update mechanism isnot suitable for deductive databases. Asa result, DLP is extended in Manchanda[1989] to directly support bulk updates.For example, the updates in Example5.5 can be represented in this extensionof DLP as follows:

raise~X! : $employee2~Name, Dept, Sal2! :-employee~Name, Dept, Sal1!,Sal2 5 Sal1 1 Sal1pX}

Given a query ?- raise~0.1!, the up-dates are performed as follows: trans-form the given definition into the Data-log one:

raise2employee2~X, Name, Dept, Sal2! :-employee~Name, Dept, Sal1!,Sal2 5 Sal1 1 Sal1pX

Then evaluate the relation denoted byraise_employee2 in the current data-base; project out the first attribute (cor-responding to X) from this relation; re-place the current instance of employeewith this projection.

5.3 DatalogA and LDL

DatalogA (Datalog with Actions) [Naqviand Krishnamurthy 1988] is another ex-tension of Datalog with updates only tobase relations. Like DLP, it uses dy-namic logic to assign state-transitionsemantics to updates.

In DatalogA, base facts can be up-dated by using primitive update actionsthat are represented by prefixing a sym-bol 1 or 2 to a base predicate, where 1is for insertion and 2 is for deletion.For example, 1 employee~joe, toy,



50K! denotes the action that inserts thebase fact employee~joe, toy, 50K! intothe current state.

Two kinds of updates are distin-guished in DatalogA and have differentsemantics. The first kind is the updatein which all different orders of execu-tion yield the same final state. Thiskind of update has a declarative seman-tics and is represented by a, b, where a

and b stand for update actions. Theother kind is the update in which theupdate results depend on the order ofexecution. That is, different orders ofexecution may yield different finalstates. This kind of update has an oper-ational semantics and is represented bya;b, where a and b stand for updateactions. The semantics for this kinddoes not require that a executed beforeor after b gives the same result.

The updates in Example 5.1 can berepresented as a query in DatalogA asfollows:

? 2 employee~joe, toy, 10K!,1 employee~bob, shoe, 15K!

Example 5.6 If we want to fire Joeand give his salary to Bob, we can usethe following query:

? 2 employee~joe, toy, Sal!;1 employee~bob, shoe, Sal!

In this query we cannot change the or-der of actions, as we need to execute thedeletion first to get the substitution forthe variable Sal, and then perform theinsertion.

Rules with update actions in the bodycan also be defined in DatalogA. Forexample, the update rule in Example5.2 can be represented as follows:

withdraw~Acc, Amt! :-account~Acc, Bal1!,Bal1 $ Amt,Bal2 5 Bal1 2 Amt,~2 account~Acc, Bal1!;1 account~Acc, Bal2!)

In DatalogA, rules with update ac-tions are evaluated only if the head ofthe rule is queried (i.e., top-down),while rules without update actions areevaluated bottom-up even if they arenot directly queried.

Unlike Prolog and DLP, in whichvariables occurring only in the body ofan update rule are existentially quanti-fied, such variables in DatalogA are uni-versally quantified so that a set-ori-ented non-backtracking-based inferencemechanism can be used for updates. Forexample, the updates in Example 5.4can be represented as follows:

raise~X! :-employee~Name, Dept, Sal1!,Sal2 5 Sal1 1 Sal1pX,~ 2 employee~Name, Dept, Sal1!;1 employee~Name, Dept, Sal2!)

In this update rule, employee~Name,Dept, Sal1! is a query that generates allsubstitutions for Name, Dept, and Sal1,and ~2 employee~Name, Dept, Sal1!;1 employee~Name, Dept, Sal2!!, isused to change the salary of the employeefrom Sal1 to Sal2 for each group of sub-stitutions.

Like Prolog, DatalogA does not sup-port conditional updates, as it has noprovision for backtracking and remov-ing the effects of previous updates if thecondition fails. Therefore, the intendedupdates in Example 5.5 cannot be ex-pressed in DatalogA.

As the semantics for variables occur-ring only in the body and inferencemechanism in DatalogA are differentfrom those in Prolog, the update resultscan be quite different too, even thoughthe rules look similar. The followingrule is the DatalogA version of the rulein Example 5.3:

enroll~Student, Course! :-course~Course, Section!,size~Section, Num1!,Num1 , 30, Num2 5 Num1 1 1,2 size~Section, Num1!,1 section~Section, Student!,1 size~Section, Num2!.

54 • M. Liu


If a course DB has two sections, thenthe query ?- enroll~joe, db! will insertJoe into both sections of the DB course.Indeed, nondeterministic updates arenot supported in DatalogA.

The update mechanism of DatalogA isincorporated in LDL. The nondetermin-istic updates in LDL are supportedthrough the use of the choice operator ofthe form choice~~X!, ~Y!!, where X andY are vectors of terms, which selectsthose instantiations of the variables Xand Y that satisfy the functional depen-dency X 3 Y. The nondeterministic up-dates in Example 5.3 can be repre-sented in LDL as follows:

enroll~Student, Course! :-course~Course, Section!,size~Section, Num1!,Num1 , 30, Num2 5 Num1 1 1,choice~~Course!, ~Section!!,2 size~Section, Num1!,1 section~Student, Section!,1 size~Section, Num2!

The choice operator here guaranteesthat only one section of the course isselected for insertion.

The dynamic logic interpretation ofupdates in DatalogA and LDL providesa semantics to updates that is conso-nant with the operational meanings ofthe update predicates. However, this se-mantics is rather tricky.

5.4 Transaction Logic

The notion of transaction is essential fordatabase operations. It was first intro-duced into Prolog informally in Naish etal. [1987]. Its use in logic programmingwas then formalized in TransactionLogic T5 [Bonner and Kifer 1993; 1994;Bonner et al. 1993]. T5 is an extensionof first-order logic, both syntacticallyand semantically. Not only the exten-sional database but also the intensionaldatabase can be updated in T5. Unlikeother approaches, the main novel fea-ture of T5 is that it has a natural model

theory and a sound and complete prooftheory.

In T5, two primitive operations areprovided to delete and insert facts andrules: del and ins. A new logical connec-tive called serial conjunction and de-noted by R is introduced to sequencetransactions, where a R b means do a

then do b. The updates in Example 5.1do not require sequencing and can berepresented as a transaction in T5 asfollows:

? 2 del : employee~joe, toy, 10K!,ins : employee~joe, shoe, 10K!

The updates in Example 5.6 requiresequencing and can be represented us-ing R as follows:

? 2 del : employee~joe, toy, Sal! Rins : employee~joe, shoe, Sal!

In T5, transactions can be definedusing rules that can call other transac-tions. The update rule in Example 5.2can be represented as follows:

withdraw~Acc, Amt! :-balance~Acc, Bal! RBal $ Amt Rdel : balance~Acc, Bal! Rins : balance~Acc, Bal 2 Amt!

As in Prolog and DLP, in T5 variablesoccurring only in the body of a rule areexistentially quantified and tuple-at-a-time evaluation mechanism is used.However, the evaluation can be exe-cuted either bottom-up or top-down.Nondeterministic updates are naturallysupported in this way. The rule in Ex-ample 5.3 can be represented in T5 asfollows:

enroll~Student, Course! :-~course~Course, Section!,size~Section, Num!,Num , 30 R

ins : section~Section, Student! Rdel : size~Section, Num! Rins : size~Section, Num 1 1!.



As a transaction must be done atomi-cally, the conditional updates in Exam-ple 5.4 can be represented in T5 asfollows:

hire~Name, Dept, Sal! :-ins : employee~Name, Dept, Sal! Ravg2sal~Dept, Ave! RAvg # 50K

As in DLP and DatalogA, if the aver-age salary after hiring an employee isgreater than 50K, the whole query willfail without leaving a residue in thedatabase.

In order to support bulk updates, T5

uses relational assignment as in rela-tional databases, in the same spirit asthe extension of DLP discussed in Sec-tion 5.2. For example, the followingrules in T5 can be used to give everyemployee a 10% salary increase.

employee2~Name, Dept, Salp1.1! :-employee~Name, Dept, Sal!

raise :- @employee :5 employee2#

Given a query ?2 raise, the new contentsof the employee relation are computedby the first rule and are held in the rela-tion employee2. Then the relational as-signment @employee :5 employee2# inthe second rule assigns the new contentsinto the relation employee.

Unfortunately, the relational assign-ment cannot pass arguments. There-fore, we cannot define the rule in Exam-ple 5.4 that gives every employee an X%salary increase in T5.

6. CONCLUSION

Approaches to deductive databases aretorn by two opposing forces. On one sidethere are the stringent real-world re-quirements of actual databases. The re-quirements include efficient processingas well as the ability to express complexand subtle real-world relationships. Onthe other side are the simple and clear

semantics of logic programming and itsinference capabilities. The need for ex-pressiveness has forced deductive data-base languages away from their simpleroots in logic programming and the rela-tional data model.

In this paper, we have discussed theproblems with the standard deductivedatabase language Datalog (with nega-tion) from four different aspects: com-plex values, object orientation, higher-orderness and updates. In each case, wehave examined four typical solutions.

There are three important areas thatwe have not discussed here, since littlehas been published to date. One is thatnone of the deductive database lan-guages are computationally complete sonot all programming tasks can be per-formed in a single framework. The sec-ond is that none of the deductive data-base languages support unknown/nullvalues, which are common in databaseapplications. Indeed, it is not clear howto derive information with rules whenthere are null values in the database.Finally, most object-oriented deductivelanguages are only structurally object-oriented, since methods and encapsula-tion, two important features of objectorientation, are not properly supported.In Bertino and Montesi [1992], encapsu-lation is addressed in an object-orienteddeductive framework, but the semanticsis not defined.

We expect that a few more expressivedeductive database languages will bedeveloped that incorporate various im-portant features to solve the problemsdiscussed here. In the mean time, vari-ous implementation techniques will beinvestigated. Powerful deductive data-base systems will eventually be deliv-ered to the database market to extenddatabase applications further.

ACKNOWLEDGMENTS

The author would like to thank MichaelFranklin, associate editor of ACM Com-puting Surveys, and reviewers for theircritical reading of the article. Theirmany valuable comments and sugges-

56 • M. Liu


tions substantially helped to improvethe quality and accuracy of this survey.Thanks also to Katrina Avery at ACMComputing Surveys, Cory Butz, andShilpesh Katragadda for their correc-tions. This work was partly supportedby the Natural Sciences and Engineer-ing Research Council of Canada.

REFERENCES

ABITEBOUL, S. 1988. Updates, a New DatabaseFrontier. In Proceedings of the InternationalConference on Data Base Theory (Pruges, Bel-gium). Springer-Verlag, New York, 1–18.

ABITEBOUL, S. AND BEERI, C. 1995. The Power ofLanguages for the Manipulation of ComplexValues. VLDB J. 4, 4, 727–794.

ABITEBOUL, S., FISCHER, P. C., AND SCHEK, H.,Eds. 1987. Proceedings of the InternationalWorkshop on Theory and Applications ofNested Relations and Complex Objects in Da-tabases. (Darmstadt, Germany) Springer-Verlag, New York.

ABITEBOUL, S. AND GRUMBACH, S. 1991. A rule-based language with functions and sets.ACM Trans. Database Syst. 16, 1 (Mar.),1–30.

ABITEBOUL, S. AND HULL, R. 1987. IFO: a formalsemantic database model. ACM Trans. Da-tabase Syst. 12, 4 (Dec. 1987), 525–565.

ABITEBOUL, S., HULL, R., AND VIANU, V.1995. Foundations of Databases. Addison-Wesley, Reading, MA.

ABITEBOUL, S. AND KANELLAKIS, P. 1989. ObjectIdentity as a Query Language Primitive. InProceedings of the 1989 ACM SIGMOD inter-national conference on Management of data(SIGMOD ’89, Portland, Oregon, June 1989),J. Clifford, J. Clifford, B. Lindsay, D. Maier,and J. Clifford, Eds. ACM Press, New York,NY, 159–173.

ABITEBOUL, S. AND VIANU, V. 1991. Datalog ex-tensions for database queries and up-dates. J. Comput. Syst. Sci. 43, 1 (Aug.1991), 62–124.

AÏT-KACI, H. 1993. An Introduction to Life. InProceedings of the Joint International Confer-ence and Symposium on Logic Programming(Vancouver, Canada). MIT Press, Cam-bridge, MA, 506–524.

AÏT-KACI, H AND NASR, R 1986. Login: A logicprogramming language with built-in inherit-ance. J. Logic Program. 3, 3 (Oct. 1986),185–215.

ALBANO, A., CARDELLI, L., AND ORSINI, R.1985. GALILEO: a strongly-typed, interac-tive conceptual language. ACM Trans. Data-base Syst. 10, 2 (June 1985), 230–260.

ALBANO, A., GHELLI, G., AND ORSINI, R.1995. Fibonacci: A Programming Languagefor Object Databases. VLDB J. 4, 3, 403–444.

APT, K. R., BLAIR, H. A., AND WALKER,A. 1988. Towards a theory of declarativeknowledge. In Foundations of deductive da-tabases and logic programming, J. Minker,Ed. Morgan Kaufmann Publishers Inc., SanFrancisco, CA, 89–148.

BANCILHON, F., MAIER, F., SAGIV, Y., AND ULLMAN,J. 1986. Magic Sets and Other StrangeWays to Implement Logic Programs. In Pro-ceedings of the ACM Symposium on Principlesof Database Systems (PODS ’86, Cambridge,Massachusetts). ACM Press, New York, NY,1–16.

BANCILHON, F. AND RAMAKRISHNAN, R. 1986. AnAmateur’s Introduction to Recursive QueryProcessing Strategies. In Proceedings of theconference on Management of data (SIGMOD’86, Washington, D.C., May 28-30, 1986), C.Zaniolo, Ed. ACM Press, New York, NY, 16–52.

BARBACK, M., LOBO, J., AND LU, J.1992. Minimizing Indefinite Information inDisjunctive Deductive Databases. In Pro-ceedings of the International Conference onData Base Theory (Berlin, Ger-many). Springer-Verlag, New York,246–260.

BEERI, C. 1989. Formal Models for Object-Ori-ented Databases. In Proceedings of the Inter-national Conference on Deductive and Object-Oriented Databases (Kyoto, Japan), W. Kim,J. Nicolas, and S. Nishio, Eds. North-Hol-land Publishing Co., Amsterdam, The Nether-lands, 405–430.

BEERI, C. 1990. A formal approach to object-oriented databases. Data Knowl. Eng. 5, 2,353–382.

BEERI, C., NAQVI, S., SHMUELI, O., AND TSUR,S. 1991. Set constructors in a logic data-base language. J. Logic Program. 10, 3/4(Apr./May 1991), 181–232.

BEERI, C. AND RAMAKRISHNAN, R. 1991. On thepower of magic. J. Logic Program. 10, 3/4(Apr./May 1991), 255–299.

BERTINO, E. AND MONTESI, D. 1992. Towards aLogical Object-oriented Programming Lan-guage for Databases. In Proceedings of theInternational Conference on Extending Data-base Technology (Vienna, Austria). Springer-Verlag, New York, NY, 168–183.

BONNER, A. J. 1989. Hypothetical datalog nega-tion and linear recursion. In Proceedings ofthe eighth ACM SIGACT-SIGMOD-SIGARTsymposium on Principles of Database Systems(PODS ’89, Philadelphia, PA, Mar. 29–31,1989), A. Silberschatz, Ed. ACM Press, NewYork, NY, 286–300.

BONNER, A. J. 1990. Hypothetical datalog: com-plexity and expressibility. Theor. Comput.Sci. 76, 1 (Oct. 31, 1990), 3–51.

BONNER, A. J. AND KIFER, M. 1993. Transactionlogic programming. In Proceedings of thetenth international conference on Logic pro-gramming (ICLP’93, Budapest, Hungary,



June 21–25, 1993), D. S. Warren, Ed. MITPress, Cambridge, MA, 257–279.

BONNER, A. J. AND KIFER, M. 1994. An overviewof transaction logic. Theor. Comput. Sci.133, 2 (Oct. 24, 1994), 205–265.

BONNER, A., KIFER, M., AND CONSENS,M. 1993. Database Programming in Trans-action Logic. In Proceedings of the Interna-tional Workshop on Database ProgrammingLanguages (New York, NY). Morgan Kauf-mann Publishers Inc., San Francisco, CA,309–337.

BORGIDA, A. 1988. Modeling class hierarchieswith contradictions. In Proceedings of theConference on Management of Data (SIGMOD’88, Chicago, IL, June 1-3, 1988), H. Boral andP.-A. Larson, Eds. ACM Press, New York,NY, 434–443.

BRODIE, M. 1984. On the development of datamodels. In On Conceptual Modelling, M.Brodie, J. Mylopoulos, and J. Schmidt,Eds. Springer-Verlag, New York, NY, 19–48.

BRODSKY, A., JAFFAR, J., AND MAHER, M.1993. Towards practical constraint databas-es. In Proceedings of the International Con-ference on Very Large Data Bases (Dublin,Ireland). Morgan Kaufmann Publishers Inc.,San Francisco, CA, 557–580.

BRY, F. 1990. Intensional Updates: Abductionvia Deduction. In Proceedings of the Interna-tional Conference on Logic Programming(Budapest, Hungary). MIT Press, Cam-bridge, MA, 561–575.

CACACE, F., CERI, S., CREPI-REGHIZZI, S., TANCA, L.,AND ZICARI, R. 1990. Integrating Object-Oriented Data Modelling with a Rule-BasedProgramming Paradigm. In Proceedings ofthe 1990 ACM SIGMOD International Confer-ence on Management of Data (SIGMOD ’90,Atlantic City, NJ, May 23–25, 1990), H. Gar-cia-Molina, Ed. ACM Press, New York, NY,225–236.

CAREY, M. J., DEWITT, D. J., AND VANDERBERG, S.1988. A data model and query language forEXODUS. In Proceedings of the Conferenceon Management of Data (SIGMOD ’88, Chi-cago, IL, June 1-3, 1988), H. Boral and P.-A.Larson, Eds. ACM Press, New York, NY,413–423.

CATTELL, R., Ed. 1996. The Object DatabaseStandard: ODMG-93. Release 1.2 MorganKaufmann Publishers Inc., San Francisco,CA.

CERI, S., GOTTLOB, G., AND TANCA,L. 1990. Logic programming and databas-es. Springer-Verlag, New York, NY.

CHEN, P. 1976. The Entity-Relationship model:Toward a unified view of data. ACM Trans.Database Syst. 1, 1, 9–36.

CHEN, Q. AND CHU, W. 1989. HILOG: A High-Order Logic Programming Language for Non-1NF Deductive Databases. In Proceedings ofthe International Conference on Deductive and

Object-Oriented Databases (Kyoto, Japan), W.Kim, J. Nicolas, and S. Nishio, Eds. North-Holland Publishing Co., Amsterdam, TheNetherlands, 431–452.

CHEN, Q. AND KAMBAYASHI, Y. 1991. Nested Re-lation Based Database Knowledge Represen-tation. In Proceedings of the 1991 ACM SIG-MOD International Conference onManagement of Data (SIGMOD ’91, Denver,CO, May 29–31, 1991), J. Clifford and R.King, Eds. ACM Press, New York, NY, 328–337.

CHEN, W. 1997. Programming with LogicalQueries, Bulk Updates and Hypothetical Rea-soning. IEEE Trans. Knowl. Data Eng. 9, 4,587–599.

CHEN, W., KIFER, M., AND WARREN, D.S. 1993. HILOG: a foundation for higher-order logic programming. J. Logic Program.15, 3 (Feb. 1993), 187–230.

CHEN, W. AND WARREN, D. S. 1989. C-logic ofcomplex objects. In Proceedings of the eighthACM SIGACT-SIGMOD-SIGART symposiumon Principles of Database Systems (PODS ’89,Philadelphia, PA, Mar. 29–31, 1989), A. Sil-berschatz, Ed. ACM Press, New York, NY,369–378.

CHIMENTI, D., GAMBOA, R., KRISHNAMURTHY, R.,NAQVI, S., TSUR, S., AND ZANIOLO, C.1990. The LDL System Prototype.IEEE Trans. Knowl. Data Eng. 2, 1, 76–90.

CODD, E. 1970. A relational model for largeshared databases. Commun. ACM 13, 6,377–387.

CODD, E. F. 1979. Extending the Database rela-tional model to capture more meaning. ACMTrans. Database Syst. 4, 4 (Dec.), 397–434.

COLBY, L. 1989. A Recursive Algebra andQuery Optimization for Nested Relations. InProceedings of the 1989 ACM SIGMOD inter-national conference on Management of data(SIGMOD ’89, Portland, Oregon, June 1989),J. Clifford, J. Clifford, B. Lindsay, D. Maier,and J. Clifford, Eds. ACM Press, New York,NY, 124–138.

COLMERAUER, A. 1985. Prolog in 10 figures.Commun. ACM 28, 12 (Dec. 1985), 1296–1310.

DE MAINDREVILLE, C. AND SIMON, E.1988. Modelling Non Deterministic Queriesand Updates in Deductive Databases. InProc. 14th International Conference on VeryLarge Data Bases (Los Angeles, CA). Mor-gan Kaufmann Publishers Inc., San Fran-cisco, CA, 395–406.

DERR, M., MORISHITA, S., AND PHIPPS,G. 1993. Design and Implementation of theGlue-Nail Database System. In Proceedingsof the 1993 ACM SIGMOD international con-ference on Management of data (SIGMOD ’93,Washington, DC, May 26–28, 1993), P. Bun-eman and S. Jajodia, Eds. ACM Press, NewYork, NY, 147–167.

58 • M. Liu


DEUX, O. 1991. The O2 system. Commun.ACM 34, 10 (Oct. 1991), 34–48.

DOVIER, A., OMODEO, E., PONTELLI, E., AND ROSSI,G. 1996. {log}: A Language for Program-ming in Logic with Finite Sets. J. Logic Pro-gram. 28, 1, 1–44.

FERNÁNDEZ, J. AND MINKER,J. 1992a. Semantics of Disjunctive Deduc-tive Databases. In Proceedings of the Inter-national Conference on Data Base Theory(Berlin, Germany). Springer-Verlag, NewYork, 21–50.

FERNÁNDEZ, J. A. AND MINKER, J. 1992b.Disjunctive Deductive Databases. In Pro-ceedings of the International Conference onLogic Programming and Automated Reason-ing (LPAR ’92, St. Peterburg, Rus-sia). Springer-Verlag, New York, 332–356.

FISHMAN, D. H., B., B., CATE, H. P., CHOW, E. C.,CONNORS, T., DAVIS, J. W., DERRETT, N., HOCH,C. G., KENT, W., LYNGBAEK, P., MAHBOD, B.,NEIMAT, M. A., RYAN, T. A., AND SHAN, M.C. 1987. Iris: An object-Oriented DatabaseManagement System. ACM Trans. Off. Inf.Syst. 5, 1, 48–69.

FREITAG, B., SCHUTZ, H., AND SPECHT, G.1991. LOLA—A Logic Language for Deduc-tive Databases and its Implementation. InProceedings of the 2nd International Sympo-sium on Database Systems for Advanced Ap-plications (DASFAA ’91, Tokyo, Japan,Apr.). 216–225.

FROHN, J., HIMMERÖDER, R., KANDZIA, P., LAUSEN,G., AND SCHLEPPHORST, C. 1997. Florid: APrototype for F-logic. In Proceedings of theInternational Conference on Data Engineer-ing. IEEE Computer Society, New York, NY.

GALLAIRE, H. 1981. Impacts of Logic on DataBases. In Proceedings of the InternationalConference on Very Large Data Bases(Cannes, France). IEEE Computer Society,New York, NY, 248–259.

GALLAIRE, H. AND MINKER, J., Eds. 1978. Logicand Data Bases. Plenum Press, New York,NY.

GALLAIRE, H., MINKER, J., AND NICOLAS, J. M.1984. Logic and Databases: A Deductive Ap-proach. ACM Comput. Surv. 16, 2, 153–186.

GELFOND, M. AND LIFSCHITZ, V. 1988. The stablemodel semantics for logic programming. InProceedings of the 5th International Confer-ence on Logic Programming (Washington,DC). MIT Press, Cambridge, MA, 1070–1080.

GRANT, J. AND MINKER, J. 1992. The impact oflogic programming on databases. Commun.ACM 35, 3 (Mar. 1992), 66–81.

GRUMBACH, S. AND SU, J. 1996. Towards practi-cal constraint databases (extended abstract).In Proceedings of the fifteenth ACM SIGACT-SIGMOD-SIGART symposium on Principlesof database systems (PODS ’96, Montreal,P. Q., Canada, June 3–5, 1996), R. Hull,Ed. ACM Press, New York, NY, 28–39.

HAMMER, M. AND MCLEOD, D. 1981. Databasedescription with SDM: A semantic databasemodel. ACM Trans. Database Syst. 6, 3(Sept.), 351-386.

HAN, J., LIU, L., AND XIE, Z. 1994. LogicBase: adeductive database system prototype. InProceedings of the 3rd International Confer-ence on Information and Knowledge Manage-ment (CIKM ’94, Gaithersburg, Maryland,Nov. 29–Dec. 2, 1994), N. R. Adam, B. K.Bhargava, and Y. Yesha, Eds. ACM Press,New York, NY, 226–233.

HAREL, D. 1979. First-Order Dynamic Logic.Lecture Notes in Computer Science, vol.361. Springer-Verlag, New York.

HEUER, A. AND SANDER, P. 1993. The LIVINGIN A LATTICE Rule Language. Data Knowl.Eng. 9, 4, 249–286.

HILL, P. AND LLOYD, J. 1994. The Gödel pro-gramming language. MIT Press, Cambridge,MA.

INOUE, K. 1994. Hypothetical Reasoning inLogic Programs. J. Logic Program. 18, 3,197–227.

IOANNIDIS, Y. AND RAMAKRISHNAN, R. 1988.Efficient Transitive Closure Algorithms. InProc. 14th International Conference on VeryLarge Data Bases (Los Angeles, CA). Mor-gan Kaufmann Publishers Inc., San Fran-cisco, CA, 382–394.

ISHIKAWA, H., SUZUKI, F., KOZAKURA, F., MAKINOU-CHI, A., MIYAGISHIMA, M., IZUMIDA, Y.,AOSHIMA, M., AND YAMANE, Y. 1993. Themodel, language, and implementation of anobject-oriented multimedia knowledge basemanagement system. ACM Trans. DatabaseSyst. 18, 1 (Mar. 1993), 1–50.

JACOBS, B. 1982. On Database Logic. J. ACM29, 2 (Apr.), 310–332.

JAFFAR, J. AND MAHER, M. 1994. Constraintlogic programming: A survey. J. Logic Pro-gram. 19-20, 503-581.

JARKE, M., GALLERSDÖRFER, R., JEUSFELD, M. A.,STAUDT, M., AND EHERER, S. 1995.ConceptBase—a deductive object base formeta data management. J. Intell. Inf. Syst.4, 2 (Mar. 1995), 167–192.

JAYARAMAN, B. 1992. Implementation of subset-equational programs. J. Logic Program. 12,4 (Apr. 1992), 299–324.

JIANG, B. 1990. A Suitable Algorithm for Com-puting Partial Transitive Closures. In Proc.IEEE Sixth International Conference on DataEngineering (Kobe, Japan, May). IEEE Com-puter Society, New York, NY, 264–271.

KAKAS, A. AND MANCARELLA, P. 1990. DatabaseUpdates through Abduction. In Proceedingsof the 16th VLDB Conference on Very LargeData Bases (VLDB, Brisbane, Australia).VLDB Endowment, Berkeley, CA, 650–661.

KIEBLING, W., SCHMIDT, H., STRAUB, W., AND DUN-ZINGER, G. 1994. DECLARE and SDS:Early Efforts to Commercialize Deductive Da-tabase Technology. VLDB J. 3, 2, 211–243.



KIFER, M. AND LAUSEN, G. 1989. F-Logic: AHigher-Order Language for Reasoning aboutObjects, Inheritance, and Schema. In Pro-ceedings of the 1989 ACM SIGMOD interna-tional conference on Management of data(SIGMOD ’89, Portland, Oregon, June 1989),J. Clifford, J. Clifford, B. Lindsay, D. Maier,and J. Clifford, Eds. ACM Press, New York,NY, 134–146.

KIFER, M., LAUSEN, G., AND WU,J. 1995. Logical foundations of object-ori-ented and frame-based languages. J. ACM42, 4 (July 1995), 741–843.

KIFER, M. AND WU, J. 1993. A logic for program-ming with complex objects. J. Comput. Syst.Sci. 47, 1 (Aug. 1993), 77–120.

KIM, W. 1990a. Introduction to Object-OrientedDatabases. MIT Press, Cambridge, MA.

KIM, W. 1990b. Object-Oriented Databases:Definition and Research Direction. IEEETrans. Knowl. Data Eng. 2, 3 (Sept.), 327–341.

KOWALSKI, R. A. 1988. The early years of logicprogramming. Commun. ACM 31, 1 (Jan.1988), 38–43.

KOWALSKI, R. 1992. Database updates in theevent calculus. J. Logic Program. 12, 1/2(Jan. 1992), 121–146.

KRISHNAMURTHY, R. AND NAQVI, S. 1988.Towards a Real Horn Clause Language. InProc. 14th International Conference on VeryLarge Data Bases (Los Angeles, CA). Mor-gan Kaufmann Publishers Inc., San Fran-cisco, CA, 252–263.

KUPER, G. M. 1990. Logic programming withsets. J. Comput. Syst. Sci. 41, 1 (Aug. 1990),44–64.

LECLUSE, C. AND RICHARD, P. 1989. The O2 Da-tabase Programming Language. In Proceed-ings of the fifteenth international conferenceon Very large data bases (Amsterdam, TheNetherlands, Aug 22–25 1989), R. P. van deRiet, Ed. Morgan Kaufmann Publishers Inc.,San Francisco, CA, 411–422.

LEVENE, M. AND LOIZOU, G. 1993. Semantics fornull extended nested relations. ACM Trans.Database Syst. 18, 3 (Sept. 1993), 414–459.

LIU, M. 1995. Relationlog: A Typed Extensionto Datalog with Sets and Tuples (ExtendedAbstract). In Proceedings of the Interna-tional Symposium on Logic Programming(ILPS ’95, Portland, Oregon, Dec. 4–7). MITPress, Cambridge, MA, 83–97.

LIU, M. 1996. ROL: A Deductive Object BaseLanguage. Inf. Syst. 21, 5, 431–457.

LIU, M. 1998a. An Overview of Rule-based Ob-ject Language. J. Intell. Inf. Syst. 10, 1,5–29.

LIU, M. 1998b. Relationlog: A Typed Extensionto Datalog with Sets and Tuples. J. LogicProgram. 36, 3, 271–299.

LIU, M. AND SHAN, R. 1998. The Design andImplementation of the Relationlog DeductiveDatabase System. In Proceedings of the 9th

International Workshop on Database and Ex-pert System Applications (DEXA Workshop’98, Vienna, Austria, Aug. 24–28). IEEEComputer Society Press, Los Alamitos, CA,856–863.

LIU, M., YU, W., GUO, M., AND SHAN,R. 1998. ROL: A Prototype for Deductiveand Object-Oriented Databases. In Proceed-ings of the International Symposium on Data-base Engineering and Applications (ICDE ’98,Orlando, FL, Feb. 23–27). IEEE ComputerSociety Press, Los Alamitos, CA, 598.

LLOYD, J. W. 1987. Foundations of Logic Pro-gramming. 2nd ed. Springer-Verlag SymbolicComputation and Artificial Intelligence Se-ries. Springer-Verlag, Vienna, Austria.

LOU, Y. AND OZSOYOGLU, M. 1991. LLO: A De-ductive Language with Methods and MethodInheritance. In Proceedings of the 1991 ACMSIGMOD International Conference on Man-agement of Data (SIGMOD ’91, Denver, CO,May 29–31, 1991), J. Clifford and R. King,Eds. ACM Press, New York, NY, 198–207.

MAIER, D. 1983. The Theory of Relational Data-bases. Computer Science Press, Inc., NewYork, NY.

MAIER, D. 1986. A logic for objects. TechnicalReport CS/E-86-012. Oregon Graduate Cen-ter, Beaverton, Oregon.

MAIER, D. 1987. Why Database Languages area Bad Idea. In Proceedings of the Workshopon Database Programming Languages(Roscoff, France).

MAIER, D., STEIN, J., OTIS, A., AND PURDY,A. 1986. Development of Object-OrientedDBMS. In OOPSLA ’86. ACM Press, NewYork, NY, 472–482.

MANCHANDA, S. 1989. Declarative expression ofdeductive database updates. In Proceedingsof the eighth ACM SIGACT-SIGMOD-SI-GART symposium on Principles of DatabaseSystems (PODS ’89, Philadelphia, PA, Mar.29–31, 1989), A. Silberschatz, Ed. ACMPress, New York, NY, 93–100.

MANCHANDA, S. AND WARREN, D. S. 1988. A log-ic-based language for database updates. InFoundations of deductive databases and logicprogramming, J. Minker, Ed. Morgan Kauf-mann Publishers Inc., San Francisco, CA,363–394.

MONTESI, D., BERTINO, E., AND MARTELLI,M. 1997. Transactions and Updates in De-ductive Databases. IEEE Trans. Knowl.Data Eng. 9, 5, 784–797.

MORRIS, K., ULLMAN, J. D, AND VAN GELDER,A. 1986. Design overview of the NAIL! sys-tem. In Proceedings on Third internationalconference on logic programming (London,UK, July 14-18, 1986), E. Shapiro, Ed.Springer-Verlag, New York, NY, 554–568.

MOSS, C. 1994. Prolog11. Addison-Wesley Long-man Publ. Co., Inc., Reading, MA.

MUMICK, I. S., FINKELSTEIN, S. J., PIRAHESH, H.,AND RAMAKRISHNAN, R. 1996. Magic condi-

60 • M. Liu


tions. ACM Trans. Database Syst. 21, 1,107–155.

MYLOPOULOS, J., BERNSTEIN, P. A., AND WONG, H.K. T. 1980. A Language Facility for De-signing Database-Intensive Applications.ACM Trans. Database Syst. 5, 2 (June), 185–207.

NAISH, L., THOM, L., AND RAMAMOHANARAO, K.1987. Concurrent Database Updates in Pro-log. In Proceedings of the International Con-ference on Logic Programming (Melbourne,Australia). MIT Press, Cambridge, MA,178–189.

NAQVI, S. AND KRISHNAMURTHY, R. 1988.Database Updates in Logic Programming. InProc. 7th ACM SIGACT-SIGMOD-SIGARTSymposium on Principles of Database Systems(Austin, TX, Mar.). 261–272.

NAQVI, S. AND TSUR, S. 1989. A logical languagefor data and knowledge bases. ComputerScience Press principles of computer scienceseries. Computer Science Press, Inc., NewYork, NY.

OZSOYOGLU, Z. M. AND YUAN, L.-Y. 1987. A newnormal form for nested relations. ACMTrans. Database Syst. 12, 1 (Mar. 1987), 111–136.

PRZYMUSINSKI, T. C. 1988. On the declarativesemantics of deductive databases and logicprograms. In Foundations of deductive data-bases and logic programming, J. Minker, Ed.Morgan Kaufmann Publishers Inc., San Fran-cisco, CA, 193–216.

PRZYMUSINSKI, T. 1990. Extended Stable Se-mantics for Normal and Disjunctive Pro-grams.In Proceedings of the International Conferenceon Logic Programming (Budapest, Hunga-ry). MIT Press, Cambridge, MA, 459–477.

RAMAKRISHMAN, R., Ed. 1994. Applications ofLogic Databases. Kluwer Academic Publish-ers, Hingham, MA.

RAMAKRISHNAN, R., SRIVASTAVA, D., SUDARSHAN, S.,AND SESHADRI, P. 1994. The coral deductivesystem. VLDB J. 3, 2, 161–210.

RAMAKRISHMAN, R. AND ULLMAN, J. D. 1995. ASurvey of Deductive Database Systems. J.Logic Program. 23, 2, 125–150.

RAO, P., SAGONAS, K., SWIFT, T., WARREN, D., AND

FREIRE, J. 1997. XSB: A System for Eff-ciently Computing. In Proceedings of the In-ternational Conference on Logic Programmingand Non-Monotonic Reasoning (LPNMR ’97,Dagstuhl, Germany). Springer-Verlag, NewYork, 431–441.

REITER, R. 1984. Towards a logical reconstruc-tion of relational database theory. In OnConceptual Modelling, M. Brodie, J. Mylopou-los, and J. Schmidt, Eds. Springer-Verlag,New York, NY, 191–233.

REITER, R. 1995. On Specifying Database Up-dates. J. Logic Program. 25, 1, 53–91.

ROSS, K. A. 1994. Modular stratification andmagic sets for Datalog programs with nega-tion. J. ACM 41, 6 (Nov. 1994), 1216–1266.

ROTH, M. A., KORTH, H. F., AND BATORY, D. S.1987. SQL/NF: a query language for ¬ 1NFrelational databases. Inf. Syst. 12, 1 (Jan.1987), 99–114.

ROTH, M. A., KORTH, H. F., AND SILBERSCHATZ,A. 1988. Extended algebra and calculus for¬1NF relational databases. ACM Trans. Da-tabase Syst. 13, 4 (Dec. 1988), 389–417.

SACCA, D. AND ZANIOLO, C. 1987. Magic Count-ing Methods. In Proceedings of the ACMSIGMOD Annual Conference on Managementof Data (SIGMOD ’87, San Francisco, CA,May 27-29, 1987), U. Dayal, Ed. ACM Press,New York, NY, 49–59.

SAGONAS, K., SWIFT, T., AND WARREN, D.1994. XSB as an Efficient Deductive Data-base Engine. In Proceedings of the 1994ACM SIGMOD International Conference onManagement of Data (SIGMOD ’94, Minneap-olis, Minnesota, May 24–27, 1994), R. T.Snodgrass and M. Winslett, Eds. ACMPress, New York, NY, 442–453.

SATTAR, A. AND GOEBEL, R. 1997. Consistency-motivated reason maintenance in hypotheti-cal reasoning. New Gen. Comput. 15, 2, 163–186.

SHAN, R. AND LIU, M. 1998. Introduction to theRelationlog System. In Proceedings of the6th Intl. Workshop on Deductive Databasesand Logic Programming (DDLP ’98, Manches-ter, UK, June 20 1998). 71–83.

SHIPMAN, D. W. 1981. The Functional DataModel and the Data Language DAPLEX.ACM Trans. Database Syst. 6, 1, 140–173.

SMOLKA, G. 1995. The Oz programming mod-el. In Computer Science Today, J. van Leeu-wen, Ed. Lecture Notes in Computer Sci-ence, vol. 1000. Springer-Verlag, New York,324–343.

SOMOGYI, Z., HENDERSON, F., AND CONWAY, T.1996. The Execution Algorithm of Mercury:An Efficient Purely Declarative Logic Pro-gramming Language. J. Logic Program. 29,1–3, 17–64.

STERLING, L. AND SHAPIRO, E. 1986. The art ofProlog: advanced programming tech-niques. MIT Press series in logic program-ming. MIT Press, Cambridge, MA.

SU, S. Y. W. 1986. Modeling Integrated Manu-facturing Data with SAM p. IEEE Computer19, 1, 34–49.

SUBRAHMANIAN, V. S. 1992. Paraconsistent dis-junctive deductive databases. Theor. Com-put. Sci. 93, 1 (Feb. 3, 1992), 115–141.

TSUR, S. AND ZANIOLO, C. 1986. LDL: A Logic-based data-language. In Proceedings of the12th international conference on on VeryLarge Data Bases (Kyoto, Japan, Aug.,1986). VLDB Endowment, Berkeley, CA, 33-41.



ULLMAN, J. 1982. Principles of Database Sys-tems. Computer Science Press, Inc., NewYork, NY.

ULLMAN, J. 1989a. Principles of Database andKnowledge-Base Systems. Computer SciencePress, Inc., New York, NY.

ULLMAN, J. D. 1989b. Bottom-up beats top-down for datalog. In Proceedings of theeighth ACM SIGACT-SIGMOD-SIGART sym-posium on Principles of Database Systems(PODS ’89, Philadelphia, PA, Mar. 29–31,1989), A. Silberschatz, Ed. ACM Press, NewYork, NY, 140–149.

ULLMAN, J. 1991. A Comparison between De-ductive and Object-Oriented Databases Sys-tems. In Proceedings of the InternationalConference on Deductive and Object-OrientedDatabases (Munich, Germany), C. Delobel, M.

Kifer, and Y. Masunaga, Eds. Springer-Ver-lag, New York, 263–277.

VAGHANI, J., RAMANOHANARAO, K., KEMP, D., SOMO-GYI, Z., STUCKEY, P., LEASK, T., AND HARLAND,J. 1994. The Aditi Deductive DatabaseSystem. VLDB J. 3, 2, 245–288.

VAN GELDER, A. 1993. The alternating fixpointof logic programs with negation. J. Comput.Syst. Sci. 47, 1 (Aug. 1993), 185–221.

VAN GELDER, A., ROSS, K. A., AND SCHLIPF, J. S.1991. The well-founded semantics for gen-eral logic programs. J. ACM 38, 3 (July1991), 619–649.

WICHERT, C.-A. AND FREITAG, B. 1997.Capturing Database Dynamics by DeferredUpdates. In Proceedings of the InternationalConference on Logic Programming (Leuven,Belgium). MIT Press, Cambridge, MA.

Received: March 1997; revised: September 1997, April 1998; accepted: July 1998

62 • M. Liu


Documents

Deductive database languages: problems and solutionsmengchi/papers/ddb-CS99.pdfCORAL [Ramakrishnan et al. 1994], Aditi [Vaghani et al. 1994], LogicBase [Han et al. 1994], Declare/SDS