the gpr system: an architecture for integrating active and deductive rules on complex database...

The GPR System: An Architecture for Integrating Activeand Deductive Rules on Complex Database Objects

Fabrizio AngiulliISI-CNR, c/o DEIS, Universita della Calabria, I-87036 Rende (CS), Italy; e-mail: [email protected]

Luigi PalopoliDipartimento di Elettronica Informatica e Sistemistica, Universita della Calabria, I-87036 Rende (CS), Italy;e-mail: [email protected]

Riccardo TorloneDipartimento di Informatica e Automazione, Universita di Roma Tre, Via della Vasca Navale, 84, I-00146 Roma,Italy; e-mail: [email protected]

This paper illustrates a prototype system, called GPRS,supporting the Generalized Production Rules (GPR)data-base language. The GPR language integrates, ina unified framework, active rules, which allow the spec-ification of event driven computations on data, anddeductive rules, which can be used to derive inten-sional relations in the style of logic programming.The prototype realizes the operational semantics ofGPR using a unique rule-evaluation engine. The datamodel of reference is object based and the systemis implemented on top of an object oriented DBMS.Hence, the GPRS prototype represents a concreteproposal of an advanced DBMS for complex objectsthat provides both active and deductive styles of ruleprogramming. c© 1997 John Wiley & Sons, Inc.

1. Introduction

A significant body of research has been recently doneto extend the capabilities of current data-base manage-ment systems, in order to meet the requirements ofnew application domains (like, for instance, CAD, mul-timedia, robotics, and expert systems). Along this line,two independent research trends have emerged: on onehand, the use of production rule languages (tradition-ally used in expert system shells) for expressing ac-tive computations, that is, manipulations of data to beexecuted automatically whenever certain events occur[5, 6, 7, 10, 13, 14, 15, 16, 17]; on the other hand, the

Received Janury 10, 1996; revised January 30, 1997; accepted June10, 1997Recommending editor: Dr. H. V. Jagadish

c© 1997 John Wiley & Sons, Inc.

use of logic based rule languages for expressing, in adeclarative way, complex data-base queries and deduc-tive computations [1, 2, 3, 4, 11].

From a practical point of view, the integration of theseparadigms (active and deductive) into a unique homoge-neous framework would clearly represent a further im-portant improvement [18]. Indeed, the two paradigmspresent strong similarities since they are both basedon rules that, roughly speaking, connect a cause withan expected effect. However, the very different seman-tics (both abstract and operational) provided so far forthese paradigms make this integration a difficult task toachieve.

Recently, we have proposed a language, called GPR(Generalized Production Rules), that allows the pro-grammer to express both active and deductive computa-tions [12]. In this paper, we describe a prototype system(GPRS) supporting this language and illustrate the inter-esting aspects related to its implementation. The systemhas been realized at DEIS, Universita della Calabria. Ithas been developed in O–SQL, with C as the host lan-guage, on top of the Iris object oriented DBMS.

GPRS realizes the operational semantics of GPR us-ing a unique rule-evaluation engine. One of the mainpoints of this engine is that the activation of rules isrealized using a unification technique, which is imple-mented by adapting the standard unification algorithmto GPR statements. The system supports an object-baseddata model for complex objects with identity, and usesthe object oriented DBMS for managing persistent data.The prototype structure is based on an abstract inter-preter that realizes the formal semantics of GPR as de-

THEORY AND PRACTICE OF OBJECT SYSTEMS, Vol. 3(4), 285–301 1997 CCC 1074-3227/97/040285-17

scribed in [12]. The underlying object-oriented DBMShas been used to store GPR schemes and as the back-endfor basic queries and updates to the current data-base in-stance. The overall architecture features a good degreeof modularity and this makes the system easy to extendand modify.

The design of our system presents a number of inter-esting features related to the evolutionary developmentof an advanced data-base management system for com-plex object data bases. Among them, we cite the use ofaction deferment and logs to solve some problems relatedto the implementation of data manipulations triggered bydeletions and modifications. Indeed, deletions must takeinto account the referential integrity maintenance policyimplemented in the underlying object oriented DBMS.With respect to modifications, the problem to be solvedis the management of both the old and the new data-basestate referred by the given modification. A further inter-esting implementation issue is that of the design of aunification algorithm for GPR atoms (which may gener-ally involve complex terms to appear as attribute values)inducing a simple management of input/output parame-ter passing towards/from GPR rules.

A first release of the system is available, and expe-riences with using GPRS for programming a numberof applications are going on. The two main applicationsthat have been realized are: (1) a traditional academic li-brary application, where triggers are used to signal book-loan time period deadlines and last-copy status for booksto lend, and (2) a robot motion planning application,where rules are used to decide the trajectory of a robotfrom a given starting point to a given target point into anoisy (due to the presence of moving obstacles) referencearea. The development of a second release of the sys-tem, featuring a graphical user interface based on Motifis ongoing.

The rest of the paper is organized as follows. Section2 contains an informal description of the GPR language.Section 3 presents an overview of the functionalities ofthe GPRS prototype. Section 4 describes the architectureof the system: more specifically, Section 4.1 illustratesthe mapping between GPR schemes and Iris schemes,Section 4.2 describes the parsing process of GPR pro-grams and goals, the rule triggering mechanism is illus-trated in Section 4.3, whereas rule execution is describedin Section 4.4. Finally, in Section 5 we draw some con-clusions.

2. The Rule Language GPR

In this section, we shall illustrate the main characteris-tics of our rule language. The interested reader can referto [12] for a more detailed presentation of this language.

2.1. Rule Languages

In a recent paper [15], rule languages used in systemssuch as expert system shells, deductive data bases, andactive data bases are all viewed as based on statementsof the following form:

Cause⇒ Effect

where the left-hand side, called rule head, determinesthe cause of rule activation whereas the right-hand side,called the body of the rule, states the effect of itsexecution.1 The same paper presents a classification ofrules that is based on the type of data-base operationsoccurring in the head and in the body of the rule. Next,we recall part of this classification.

In the case where a query is specified as the cause ofrule activation, but the effect is an update of the data-base state, then we have a production rule, like thoseemployed in expert system shells. For instance, the rule

emp(X , toy), emp(X , book)⇒ −emp(X , toy)

is activated in the current data-base state if in the emp re-lation there is at least one employee working both for thetoy department and for the book department. Its effectis to constrain this employee to work only for the bookdepartment, by deleting the tuple assigning him/her tothe toy department. Rules like these are also employedin active data-base systems and are often referred to aspattern driven triggers.

Deductive rules can be described by a statement likethe one above having queries as both cause and effect.For instance, the rule

man(X , Y )⇒ emp(X , Z), dep(Z , Y )

is activated by a query to the (intensional) relation manand the effect is a conjunctive query to the (extensional)relations emp and dep, from which the answer is con-structed. This corresponds to a backward evaluation ofa deductive rule traditionally written as:

man(X, Y)← emp(X, Z), dep(Z, Y)

A third type of rule is characterized by update opera-tions specified as both its head and its body. For instance,the rule

−dep(Y )⇒ −emp(X , Y )

is activated when a deletion takes place in the data-basesystem involving the relation dep, and its effect is todelete in turn all the employees working for the deleteddepartment. These rules are often used in active data-base systems and referred to as event driven triggers.

A more general form of rule is obtained by an activa-tion due to an update but conditioned to the satisfactionof a Boolean condition specified by a query. These rulesare known as event-condition-action rules (ECA rules,for short). In this case, rule activation takes place if both

286 THEORY AND PRACTICE OF OBJECT SYSTEMS–1997

an update is executed and some condition specified by aquery is met. For instance, the rule

−dep(toy) • dep(book)⇒ −emp(X , toy), +emp(X , book)

is activated by the deletion of the toy department only ifthe book department still exists in the data base, whichthe employees of the toy department can be moved to.The role of the bullet • is that of a syntactical separatorbetween the event and the condition specifications. Thusan ECA rule is (possibly) activated by a specific updatewhich takes place in the system, but its actual activationdepends on a check specified in its condition. Note that inthe various types of rules, it is possible to pass bindingsfrom the head to the body.

2.2. Generalized Production Rules

The system we present in this paper implements theGeneralized Production Rule (GPR) language. This lan-guage is based on a new type of rule that can be viewedas an extension of the cause-effect rule seen above. Syn-tactically, generalized production rules have the follow-ing structure:

E ⇒ Q •U

where, like in ECA rules, E denotes an event triggeringthe rule, Q denotes a condition for its activation, and Udenotes the action to take place as the effect of its exe-cution. Rules are triggered either explicitly by the user,by specifying a goal, or implicitly by the system dur-ing the evaluation of GPR programs. Semantically, thisnew form of rule generalize ECA rules mainly in thatnot only data-base operations but also “logical” opera-tions, defined by a name, can appear in the head of a rule.These operations can have input and output parameters:by using a general unification mechanism this allows in-formation exchange between the head and the body ofthe rule. As a result, queries defined in the condition partC can be used not only for specifying Boolean conditionscontrolling rule activation, but also to construct bindingsthat, through unification, are passed backward to the ac-tivating literal. We will show that this mechanism allowsus to naturally express deductive rules.

Since the condition part of a generalized production isnot simply a constraint on activation, it should be viewedas being included in the effect of the rule rather thanbeing part of the cause triggering the rule, like in ECArules. The exchanged positions of the double arrow andof the bullet symbols highlight this important fact. Thus,in general, the execution of a generalized production rulewith respect to a certain data-base state returns both achange to the data-base state (as in ordinary active rules),and the answer to a query. In the following section, we

shall present a number of practical examples that will beused to clarify the semantics of GPR execution.

The GPR language is defined in the framework ofa simple data model for complex objects with identity,called ODM, that naturally generalizes the relationalmodel. Data structuring is obtained by nesting of thefollowing usual type constructors: tuples, denoted by de-limiters [ and ], sets, denoted by delimiters { and }, andsequences, denoted by delimiters 〈 and 〉. An ODM database consists of a set of classes and class instances aresets of objects. Each object is uniquely identified by anobject identifier (oid, for short). The structure of classobjects is defined in class declarations. Class objects havein general a complex structure, to any level of nesting,but they are constrained to have the tuple constructor atthe outmost level. Explicit referencing amongst classesis allowed and makes use of object identifiers as objectpointers.

An ODM scheme and an instance relative to a librarydata base application are shown in Figure 1. This database will be used as reference for all the examples pre-sented in the rest of the paper. An example of class refer-encing occurs in the class book, where the value of theattribute authors must be a set of objects belongingto the class author.

2.3. Examples of the GPR Language

We now show the use of the GPR language by meansof a number of examples that refer to the data base inFigure 1.

All GPR rules make use of atoms having a specificprefix: the symbol ? denote object query atoms, that is,atomic query operations on stored data, whereas the sym-bols +, −, and ∗ denote insertion, deletion, and mod-ification operations respectively. A number of built-inatoms are also allowed (e.g., comparison and member-ship predicates) and are generally specified using the in-fix notation.

To begin with, let us consider rules where the eventpart is missing. In this case the event triggering therule is always considered as true and the statement iscalled “goal” since it corresponds to an explicit requestof a (conditional) data-base operation. Specifically, thesemantics of one such a goal, say ⇒ C • U , is to mod-ify the underlying data-base instance according to theupdates specified in U, if the condition C is satisfied.

Example 1. Assume we want to delete the books havingPoe as author, together with all their copies. This can bedone using the following rule:

⇒ ?author(X, [name : “Poe”]),?book(Y, [authors : Z]), X ∈ Z

• −book(Y),−a book(W, [book : Y]).

The object query atoms denoting the condition areevaluated by looking for the unifying substitutions

THEORY AND PRACTICE OF OBJECT SYSTEMS–1997 287

typ(book) = [title:string, authors:{author}, total:integer, avail:integer]typ(a book) = [code:integer, book:book, year:integer]typ(person) = [name:string, position:string]

typ(loan) = [pers:person, copy:a book, period:[from:date,to:date]]typ(author) = [name:string, nation:string]

a bookauthor code book year

name nation c1 1202 b1 1902a1 Dante Italy c2 1280 b1 1980a2 Shakespeare England c3 1556 b2 1856a3 Machiavelli Italy c4 1570 b2 1970a4 Gorkij Russia c5 1855 b3 1955a5 Marx Germany c6 2370 b4 1970a6 Engels Germany c7 3536 b5 1936

c9 4666 b6 1966

booktitle authors total avail

b1 The Comedy {a1} 2 1b2 Hamlet {a2} 2 1b3 The Prince {a3} 1 1b4 The Tempest {a2} 1 0b5 The Mother {a4} 1 0b6 Manifesto {a5,a6} 1 0

loanperson pers copy period

name position l1 p1 c1 [01-09:02-09]p1 Smith Student l2 p2 c6 [03-10:04-09]p2 Black Employee l3 p2 c7 [10-12:11-12]p3 Bond Agent l4 p3 c4 [05-19:06-19]p4 McKay Student l5 p3 c9 [06-22:07-22]

FIG. 1. An ODM data-base scheme and instance.

against objects stored in the data base. The constructedsubstitutions (or bindings) are returned to the user as theanswer. If the answer is not empty, then these substitu-tions are also applied to the update part, which is thenexecuted for each of them. In the case at hand, the con-dition is not satisfied in the data base of Figure 1, andtherefore no update is executed and the empty answer isreturned. As a particular case, if no condition is specified,we obtain unconditional updates whereas if no action isspecified, we obtain simple queries on the data base. Thislatter case is illustrated by the following example.

Example 2. Assume we want to know all the books writ-ten by Shakespeare stored in the data base. Then, we canuse the following goal:

⇒ ?author(X, [name :“Shakespeare”]),?book([title : Y, authors : Z]), X ∈ Z

If the head of the rule contains a basic update oper-ation, we have a traditional form of active rule, whichis executed whenever the event occurs and the conditionis met.

Example 3. Assume that we want to delete all the loansassociated with a person as soon as this person is deletedfrom the data base. We can use the following rule:

−person(X)⇒?loan(Y, [pers : X]) • −loan(Y)

As mentioned in the previous section, “logical” op-erations, defined by a name, can also occur in the headof a rule. These operations are denoted by the prefix! and since they represent procedures on the data baseinvolving queries but (possibly) also updates, they arecalled generalized query atoms. In the example that fol-lows, we first consider a rule with no action part havinga generalized query atom in the head. This implementsa deductive rule.


Example 4. Assume we want to know all the books lentto each person. The following rule accomplishes this task:

!lent(X, Y) ⇒ ?person(Z, [name : X]),?loan([pers : Z, copy : V]),?a book(V, [book : W]),?book(W, [title : Y]).

The rule states that when the generalized query!lent(X, Y) is invoked (in the evaluation of a goal oranother rule), then a standard query to the base classeshas to be performed. The variables X and Y are used forparameter passing. For instance, the following goal canbe used to know all the people who borrowed a copy ofthe book entitled “Hamlet.”

⇒!lent(X, ”Hamlet”)

The execution of the goal above causes the invoca-tion of a generalized query atom and this correspondsto an event that can trigger rules. Note that an eventmay contain both variables and constants: rules are actu-ally activated by constructing unifiers between the eventsand rule heads (instead of using simple matching). Afterthat, the associated body is executed. In the example athand, the body of the rule contains only the query part,which is evaluated and the constructed variable substitu-tions are composed and returned to the caller. As a result,the name of the people who borrowed the book entitled“Hamlet” are bound to the variable in the goal. Note thathere the effect of a rule is simply a query. In this case,the rule behaves as (and looks like) a Datalog rule. In asimilar fashion we can also define recursive queries, asshown in the following example.

Example 5. Assume we want to know, for each authorX, the names of all the authors that are related to X,where we assume that an author Y is related to X ifX and Y were coauthors of a book or X and Z werecoauthors of a book and Z is related to Y. The followingprogram implements this query:

!coauthors(X,Y) ⇒ ?book([authors : Z]),X ∈ Z,Y ∈ Z,X ≠ Y.

!related(X,Y) ⇒ !coauthors(X,Y).

!related(X,Y) ⇒ !coauthors(X,Z),!related(Z,Y).

If we want to know the authors related to Engels wecan use the goal:

⇒!related(X, “Engels”)

We assume a sequential execution of rules, that is,triggered rules are executed one at a time. Clearly, itmay happen that more than one rule has been triggeredand is ready for activation at a given specific time, butonly one can be selected and activated. The policy ac-cording to which this selection is made influences thesemantics of programs. This problem has been solved inGPR by associating priorities to rules: rules with higherpriorities are selected first. Ties on priorities are solved

according to the order in which rules occur in the pro-gram source text file. Further ties (that may arise whentwo instances of the same rule are triggered at the sametime) are solved non-deterministically — at the imple-mentation level this simply implies that the rule instanceexecuted first is the one corresponding to the substitutiongenerated first.

The following example shows how two different kindsof generalized production rules may interact.

Example 6. Assume we wish to enforce the referentialintegrity constraint between authors and books by delet-ing an author Y of a book X if X is deleted from thedata base and there exists no other book having Y asone of the authors. We can use the following rules inwhich the former is used to define the generalized queryatom !otherbook(X, W) used in the latter:

!otherbook(X, W) ⇒ ?book(Z, [authors : V]),X ∈ V, W /= Z.

−book(X, [authors : Y]) ⇒ not(!otherbook(Z, X)),Z ∈ Y

• −author(Z).

The above examples show that in general, the execu-tion of a rule can cause the activation of other rules (cas-cading activation). In this respect, a language can imple-ment different strategies depending on whether the rulesare evaluated depth-first or breadth-first. In the first case,if the evaluation of an atom in a goal (or in the bodyof a rule) triggers a set of rules, these rules are han-dled first, before other atoms occurring in the same goalare considered. In the latter case the goal is first com-pletely evaluated and then the triggered rules are takeninto account. In the literature, these execution strategiesare known as immediate and deferred execution modali-ties, respectively [10]. Depending on the chosen strategy,condition evaluation and action execution might be doneat different times and thus on different data-base states.Hence, different results might be obtained. The seman-tics of GPR is defined for both modalities. However, thecurrent release of GPRS implements the immediate ex-ecution modality only. The implementation of the de-ferred modality will be included in a future release ofthe system.

The same scheme used in the previous examples canbe employed to program complex data manipulationstriggered by a generalized query.

Example 7. Assume we want to program the procedurefor storing the loan of a book copy to a certain person.This can be done as follows:

!new loan(X,Y) ⇒ ?a book(V,[code:Y,book:W]),?book(W,[avail:Q]),Q>1,today(D),person(P,[name:X])

• ∗(book(W),[avail:Q-1]),+loan([pers:P,copy:V,period:[from:D,to:D+15]]).


Finally, we mention that in GPRS it is possible to use“external” triggering, i.e., triggering raised by externalalerters. These kinds of triggers are relevant in time-dependent rule executions. An example follows.

Example 8. Assume we want to generate a report asso-ciated to all latecomers. This report has to be generatedfor each day in the week. The following rule is triggeredby the function !newday(), which is raised each timea new day starts according to the system calendar. Thegeneralized query atom !write on report(X), whosedefinition is not reported for simplicity, simply recordsthe oids corresponding to latecomers in a specific class:

!late(X) ⇒ ?loan([pers : X, period : [to : Y]]),?today(Z), Z > Y.

!newday() ⇒ !late(X), !write on report(X).

3. Overview of the GPR System

The GPR language described above has been imple-mented in a prototype called GPRS that allows the defi-nition and the manipulation of ODM data bases. The userinteracts with the system through a simple interface. Thefunctionalities provided by the system can be classifiedas follows.

• Data-base scheme management. Data-base schemesare edited by the user off line. Then, once on-line, theuser can request to open a certain data base DBG. IfDBG is a new data base, it is compiled into an equiva-lent Iris scheme DBI. Otherwise, the appropriate Irisschema is loaded. If DBG was already compiled intoan Iris schema DBI, but modified afterwards, the usercan explicitly request its recompilation into a new Irisschema DB′I. The Iris schema DBI formerly associ-ated to DBG is then overwritten by the new schemaDB′I. Therefore, in the present system release, it is upto the user to guarantee the consistency between thecurrent GPR data base and the actual Iris data base.The translation of GPR schemes into Iris schemes isdescribed in Section 4.1.

• Program management. GPR programs are nothing butsets of GPR rules. Rules must be edited off-line in or-dinary text files. It is expected that all the rules form-ing one GPR program be stored into a single textfile. When a data base has been opened, the user canspecify a GPR program file P to be loaded in mainmemory. This can cause either the system to com-pile P into an internal object-code format, which isthen loaded into main memory, or to simply load thecorresponding object-code file, if P was already com-piled. Analogously to the previous case, if a programis modified, it is the responsibility of the user to ex-plicitly ask for its recompilation in order to update thecorrespondent object-code. The process of compilingGPR programs into their internal format is illustratedin Section 4.2.

• Goal management. Computations starts with the sub-mission of goals. Goals can be either explicitly sub-mitted by users or implicitly executed by the systemin response to the raising of an external event. Asfor the first case, goals can be edited either off-lineinto text files, or specified on-line. In either case, anobject-code format of the goal is possibly generatedand then loaded. As for schemes and programs, thecompilation takes place on off-line edited goals onlyfor new or modified files, whereas it always takesplace on on-line edited goals. Once loaded, the goalis executed and the appropriate rule triggering is ac-tivated, according to the process described in the pre-vious section. If the execution of a goal causes thetriggering of some rules, these rules are executed ac-cording to the immediate triggering policy. As spec-ified above, rule execution may cause other rules tobe triggered and executed in turn. The computationterminates when there are no triggered rules to beexecuted.Alternatively, computations can be activated by “ex-ternal” events. This mechanism is implemented byopening a GPRS session, specifying the appropriatedata base and GPR program and then requesting thesystem to remain idle while waiting for a specificevent to occur. This is simply realized in the presentsystem release by looking for a file having the samename as the expected event and containing event pa-rameters (if any). The system traps the events by pe-riodically examining the content of a specific direc-tory, where these files are stored. When the event istrapped, a corresponding object-code goal is automat-ically executed, and the computation proceed as ex-plained before.

In the next section, we shall illustrate the system ar-chitecture. Implementation details (e.g., the syntax of Iriscommands) will be specified only when useful for thesake of the presentation.

4. System Architecture

The architecture of GPRS is structured as shown inFigure 2 where boxes represent software componentsand lines between boxes represent exchange of infor-mation.

The main components of the system are the follow-ing. The User Interface (UI) accepts user commandsspecified through multiple-choice menus (e.g., executea goal, compile a program, compile a new data-basescheme, and so on), and returns results of evaluations,in a rather simple form. The Schema Parser (SP) com-piles an ODM scheme provided by the user through theUI, and generates an equivalent Iris scheme. The Pro-gram and Goal Parser (PGP) compiles GPR user pro-grams and goals into an internal representation. The Trig-gered Rules Manager (TRM) monitors rule triggeringand manages triggered rules. The Rule Executor (RE)


User Interface

@@

@

��

�

��

AAAAAAAAA

SchemaParser

Prog. & GoalParser

RuleEvaluator

PPPPPPPP

��

Triggering RuleManager

DeductionEvaluator

@@

@@

UpdateExecutor

��

��

QueryResolver

,,

,,,

IRIS DBMS

FIG. 2. GPRS prototype architecture.

takes a goal as input and evaluates it using the other mod-ules. The Query Resolver (QR) evaluates object queryatoms. The Update Executor (UE) executes updates onthe underlying data base. Finally, the Deduction Eval-uator (DE) evaluates subsets of rules corresponding topure deductions.

We now illustrate the various modules in more detail.

4.1. Schema Parser

The purpose of this module is to obtain a translationof an ODM scheme specified by the user through theUI into an equivalent Iris scheme. ODM schemes areedited off-line and stored in ordinary text files whichare the input of the Schema Parser. We now describe thetranslation operated by the SP by using the ODM schemereported in Figure 1.

The translation is carried out in two steps. The firststep consists in flattening complex terms. The secondone consists in translating flat ODM classes into an Irisscheme.

Thus, the first step consists in rewriting ODM userclasses into a number of classes, where no nested con-structs occur. For each user class, the translation yieldsone flattened basic class, plus a number of auxiliaryclasses, which are used to implement structured terms.Auxiliary classes generated are kept distinct from theothers and are not visible to the user. In auxiliary classes,the outmost type constructor can be either the tuple orthe set or the sequence constructor, whereas only the tu-

ple constructor appears as the outmost type constructorfor basic classes.

As an example, consider classes defined in the ODMscheme of Figure 1. The result of the first step of thetranslation is shown below.

author = [name : string, nation : string].book = [title : string, authors : book 0,

total : integer, avail : integer].book 0 = {author}.a book = [code : integer, book : book,

year: integer].loan = [pers : person, copy : a book,

period: loan 0].loan 0 = [from : integer, to : integer].person = [name : string, position : string].

Note that in this way the system is able to manage classescontaining any number of nested constructors in a uni-form manner.

Figure 3 shows the structure of a Iris scheme gener-ated by the system for the ODM scheme in Figure 1.In this figure, classes are represented by boxes. For sim-plicity, not all the class attributes have been reported.It can be noted that each object is an instance of aspecial class called GPRS Root and not visible to theusers. This most general class has three specializations:Basic, Auxiliary, and Delete-Log that are alsoclasses not visible to the users. Actual basic and auxil-iary classes appear in this scheme as specializations ofthese classes. The special class Delete-Log is used toimplement deletions of objects from the data base andtriggering of rules possibly associated to these deletions.


GPRS-Root

Delete-Log

��*

Basic Class

num of classesb

Auxiliary Class

author loan book 0 loan 0

��

��

��

��3

ZZ

ZZ

ZZZ}

��

��

��7

SS

SS

SSo

��

��

��7

SS

SS

SSo

b

b

b b

oid

class name

to be deleted to be deleted

` ` ` ` ` ` ` `

FIG. 3. Iris target scheme for an ODM scheme.

A more detailed explanation of the role of the specialclass Delete-Log will be given in Section 4.3.

Instances are implemented by means of special func-tions taking object identifiers as input and returning at-tribute values. Depending on the outmost constructor as-sociated to the given class, different translations are pos-sible.

• Tuple constructor. Attributes of classes where theoutmost constructor is the tuple are translated usingsingle-valued functions, whose domain is the sameclass and whose co-domain is the basic type or theclass associated with the corresponding attribute. Forinstance, the attribute title in the class book istranslated into the function book title, whose in-put argument has type book and returns a string. Thetranslation of all the attributes in the class book isshown below. The specification key tells the Iris sys-tem that the defined function is single-valued. Con-versely, multi-valued functions are declared by spec-ifying the string nokey.

create function

book title(book key) → Charstring;

create function

book authors(book key) → book 0;

create function

book total(book key) → Integer;

create function

book avail(book key) → Integer;

create function

to be deleted(book key) → Boolean;

The additional attribute to be deleted is an aux-iliary attribute that is used to obtain a correct im-

plementation of triggering based on deletions (seebelow).To obtain a greater efficiency, the translation of theclass book is closed with a cluster declaration thatgroups all the functions we have defined on book

into a unique data structure.• Set constructor. Instances of (auxiliary) classes whose

outmost type constructor is the set (e.g., book 0 inour example) are implemented by using a pair of func-tions. The first function is many-valued; the secondone is single-valued. The many-valued function re-turns a set of pairs 〈n, x〉, where n is an integer usedfor fast identification of set elements, and x denotesan element of the represented set. The single-valuedfunction returns the cardinality of the given set and isautomatically updated by the system whenever an el-ement is inserted or deleted. For the the class book 0

we than have:create function

book el 0(book 0 nokey) →<Integer, author>;

create function

book card 0(book 0 key) → Integer;

• Sequence constructor. Classes where the outmost typeconstructor is the sequence one have a representationsimilar to the classes having the set as the outmostconstructor. The only difference is the role played bythe first argument of the pair returned by the multi-valued function: in this case, it denotes the positionof the element in the sequence.

Clearly, the translation scheme we have adopted isnot the only possible one. However, this scheme hasbeen preferred because returned types have a uniformstructure, independent of the nesting level of ODM userclasses. This allowed us to develop simple algorithms fortheir manipulation.


4.2. Program and Goal Parser

The module compiles GPR programs and goals andproduces the corresponding internal representations. Werecall that GPR programs are edited off-line by the userand stored in ordinary text files which are then scannedby the PGP. Each rule included in a GPR program mustbe preceded by the specification of its priority. The pri-ority is specified using a notation of the form (n), wheren is a positive integer less than 100. If no priority isspecified for a rule, that rule is assumed to have priority1 by default. GPR goals can be either edited off-line andstored in text files, or edited on-line and directly evalu-ated within the current session.

In more detail, the tasks of the PGP module are thefollowing:

1. It checks whether rules specified by the user are syn-tactically correct. If this is the case, they are stored inmain memory into a data structure called Gen rule.This is a multi-list whose format closely resemblesthat of GPR rules.

2. Variables appearing in each Gen rule structure aresubstituted by indexed variables. This technique al-lows an efficient access to the variables and to theterms associated with them during substitutions (seebelow). For instance, the rule

!p(X, Y)⇒ q(X, 2)

will be represented in the corresponding Gen rule

structure as

!p(#1, #2)⇒ q(#1, 2).

3. Gen rule structures are then stored into an array,called Int prog. This dynamic array is the struc-ture storing the internal representation of the GPRprogram. According to what we have said in Sec-tion 2.3, rules are ordered in Int prog accordingto the following policy: ordering is lexicographic onthe event part of the rules; ties are solved in favorof the rules associated with highest priority; furtherties are solved in favor of rules occurring first in theoriginal program text file. Int prog is used by themodule TRM (described below) to select potentiallytriggered rules, where a rule is said to be potentiallytriggered if the predicate name specified in the cur-rently considered atom is the same as the predicatename appearing in the rule’s event part. Potentiallytriggered rules are singled out employing a binarysearch algorithm which uses the lexicographic eventparts ordering of rules within Int prog.

4. All rules realizing purely deductive computations aresingled out and marked, in order to have them eval-uated by the special module DE (described below).A rule r is marked as “purely deductive” if: (a) itsaction part is empty, and (b) the action part of eachrule that is recursively potentially triggered by atomsoccurring in the condition part of r is empty as well.

The process described above stores in Int prog the“static” representation of the GPR program at hand. Atexecution time, an instance of a rule r to be consideredfor execution is represented by a pair (#r, θ), where #ris a reference to the Gen rule structure representing rand θ is the current substitution instantiating it. Analo-gously, an instance of an atom a is represented by a pair(#a, θ), where #a denotes a reference to a substructureof the Gen rule corresponding to an occurrence of ain r. Substitutions instantiating rules are implementedusing dynamic arrays storing pointers to terms. Such ar-rays have n entries, where n is the number of variablesoccurring in the rule to which the substitution is applied.Consider a pair (#r, θ). A term t pointed by the ith entryof the array implementing θ means that the ith variableappearing in r is bound to t by θ. A null pointer in thesame position of the array indicates that this variable isfree in θ. The size of the array associated to a substitu-tion may increase during rule evaluation because of theintroduction of new variables (this point will be clarifiedin Section 4.3). The pair (#r, ∅) represents the trivialrule instance, i.e., a rule to which no substitution is cur-rently applied. We also note that substitutions can becomposed. For instance, if the substitution θ2 is appliedto the instance (#r, θ1) of the rule r, then (#r, θ1 ◦ θ2)will denote the resulting instance, where θ1◦θ2 representsthe usual composition between substitutions applied to θ1

and θ2 [9].

4.3. Triggered Rules Manager

This module includes a number of procedures devotedto the management of rule triggering. In particular:

• the procedure Trig that selects the rules triggered bya given atom;

• the procedure Unification, that realizes the unifica-tion between GPR terms;

• the procedure Valid, that updates the set of triggeredrules waiting for execution, by deleting those ruleswhose triggering events have been invalidated. Thishappens when, for instance, a rule is triggered by theinsertion of an object but this object is deleted beforethis rule is executed;

• the procedures managing the priority queue in whichtriggered rules waiting for execution are stored.

In more detail, the module TRM realizes the followingfunctionalities:

1. It selects, within the GPR program stored in mainmemory, all the rules which are potentially triggeredby the atom currently under consideration; as alreadyspecified above, the present version of the system im-plements a simple rule search algorithm based on bi-nary search.

2. It finds, in the set of potentially triggered rules, thoserules which are actually triggered and constructs theactivation records, which store information on trig-


gered rules (for more details about activation records,see the section on Parameters’ Passing below).

3. It stores activation records in a priority queue (accord-ing to priorities specified with rules). Priority queuesare stored in main memory.

4. It updates the content of the priority queue so that itstores, in every moment, only rules whose triggeringevents are still valid.

5. It picks rules from the priority queue according totheir order, as specified in the previous section.

We now consider, in more detail, the main function-alities of the TRM module.

UNIFICATION

The procedure Unification implements a specificunification algorithm. This procedure takes as inputtwo atom instances A1 = (#p(t1, . . . , tn), θ) and A2 =(#p(t′1, . . . , t′n), θ′), called activating and activated atomrespectively, and returns two substitutions θ1 and θ2, ifthe two atoms can be unified, or failure, otherwise. Thesubstitution θ1 binds variables occurring in A1 to vari-ables, constants, or complex terms occurring in both A1

and A2. The substitution θ2 binds variables occurring inA2 to either constants or complex terms occurring in A1

or to variables, constants, or complex terms occurringin A2. The reason for not returning a single unifier sub-stitution, as is more usually done, is that, by so doing,we were able to obtain a simpler implementation of in-put/output parameter passing between triggering eventatoms and triggered rules. Indeed, with this schema, θ2

stores input parameters which are passed to the activatedrule, whereas θ1 is used in the reverse direction.

Before presenting the unification algorithm imple-mented in GPRS, we need to introduce the notion ofequivalent term. Let S1, . . . , Sn be disjoint sets of vari-ables, θ1, . . . , θn be a set of substitutions, and Y be avariable. The substitution associated to Y is the unique θi

such that Y ∈ Si. Now, let X be a variable. Then the termequivalent to X with respect to S1, . . . , Sn, θ1, . . . , θn is de-noted by E

S1,...,Snθ1,...,θn

(X) and is defined as follows: if a bindingof the form X/Z belongs to θ1∪ . . .∪θn then E

S1,...,Snθ1,...,θn

(X)equals E

S1,...,Snθ1,...,θn

(Z); otherwise, ES1,...,Snθ1,...,θn

(X) equals X.

Example 9. Consider the sets of variables S1 ={X, Y, Z, W} and S2 = {A, B, C} and the substitutionsθ1 = {X/Y, Y/A, Z/B} and θ2 = {A/ < B, C >, B/C}.Then we have:

ES1,S2θ1,θ2

(X) = ES1,S2θ1,θ2

(Y) = ES1,S2θ1,θ2

(A) =

= ES1,S2θ1,θ2

(< B, C >) = < B, C >;

ES1,S2θ1,θ2

(Z) = ES1,S2θ1,θ2

(B) = ES1,S2θ1,θ2

(C) = C;

ES1,S2θ1,θ2

(W) = W.

The substitutions θ1 and θ2 resulting from the unifi-cation of (#p(t1, . . . , tn), θ) and (#p(t′1, . . . , t′n), θ′) are builtby the following algorithm:

1. θ1 := θ; θ2 := θ′; i := 1; let S1 denote the set ofvariables occurring in t1, . . . , tn and S2 denote the setof variables occurring in t′1, . . . , t′n.

2. for each pair of variables (ti, t′i ), construct the term t

equivalent to ti and the term t′ equivalent to t′i (withrespect to S1, S2, θ1, and θ2) and the associated sub-stitutions (call them θt and θt′ , respectively).

3. if t is a variable and t′ is a constant or a structure,then set θ1 to θ1 ∪ {t/t′} if θt = θ1, and set θ2 toθ2 ∪ {t/t′} otherwise;

4. if t′ is a variable and t is a constant or a structure,then set θ1 to θ1 ∪ {t′/t} if θt′ = θ1, and set θ2 toθ2 ∪ {t′/t} otherwise;

5. if both t and t′ are variables, then set θt to θt∪{t/t′}if θt = θ1, and set θt′ to θt′ ∪ {t′/t} otherwise;

6. if t and t′ are structures of the same type, the proce-dure is recursively called for each pair of elements oft and t′ occurring in corresponding positions (in therecursive execution, step 1 is not executed);

7. if both t and t′ are constants then return Failure andstop if t /= t′ (the two input atoms are not unifiable);

8. i := i + 1;9. if i ≤ n then go to 2 else return 〈θ1, θ2〉 (the unifica-

tion terminates successfully).

An example follows.

Example 10. Consider the pair

〈#p(< X, Y >, X, Z, W), #p(A, B, < B, A, C >, B)〉

the execution of the unification algorithm on this input isas follows:

i = 1. θ1 =∅, θ2 = {A/ < X, Y >};i = 2. θ1 = {X/B}, θ2 = {A/ < X, Y >};i = 3. θ1 = {X/B, Z/ < B, A, C >}, θ2 = {A/ < X, Y >};i = 4. θ1 = {X/B, Z/ < B, A, C >, W/B},

θ2 = {A/ < X, Y >}.

A condition to be met by yielded substitutions is thatno variables of the activating atom can appear in the sub-stitution θ2. Therefore, when during the construction ofsubstitutions a variable of the activated atom is bound toa structure occurring in the activating atom that containsvariables, this structure is copied and its variables aresubstituted with (possibly new) variables associated tothe activating atom. Referring to Example 4.3 above, thecomplete application of the algorithm finally producesthe following pair of substitutions:

θ1 = {X/B, Z/ < B, A, C >, W/B, Y/Y′},θ2 = {A/ < B, Y′ >}

where Y′ is a new variable associated to the activatedatom.


PARAMETERS’ PASSING

After having selected rules of the program potentiallytriggered by the current atom, the module TRM singlesout those rules which are actually activated, by callingthe procedure Trig that in turn uses the unification al-gorithm illustrated above.

Rules whose event unifies with the current activatingatom are stored in a priority queue according to theirpriorities, as specified in the text program. A new pri-ority queue called BR is created for each execution ofthe procedure Verify, which is described below. Eachpriority queue is realized as an array (one entry for eachof the allowed priorities). Each array entry stores in turna queue of activation records. Activation records includethe following information:

• a pointer #r′ to the activated rule;• a pair of substitutions (θ1, θ2), produced by the unifi-

cation algorithm, as explained in the previous section.

Activation records storing rules whose events con-tain query atoms are instantiated in the procedure Trigthrough the procedure Unification. In this case the ac-tual input parameters of this algorithm are:

• the instance (#q, θ) of a query atom q occurring in arule r, and

• the instance (#h,∅) of the event part h of a rule r′

that is potentially triggered by q.

An activation record associated to a rule with priorityi is inserted in the queue at the ith entry of the array.We recall that textual ordering in the original program isused to decide precedence between rules with the samepriority.

Before evaluating an activated rule, parameter pass-ing from the activating event atom to the activated rulemust be realized. This is obtained by applying the sub-stitution θ2 to the activated rule. Thus, if the activationrecord (#r′, (θ1, θ2)) is extracted from the priority queue,then the instance of the rule to be evaluated is (#r′, θ2).In other words, input parameter passing towards the ac-tivated rule is realized by applying the substitution θ2.

At the end of evaluation of the activated rule an out-put parameter passing takes place in the reverse direc-tion, that is, from the activated rule towards the activat-ing one. Parameter passing is realized by executing theassignment θ1 := θ1 ◦ θ2 where we recall that θ1 ◦ θ2

denotes the composition of θ1 and θ2 [9].

UPDATE TRIGGERING

As already pointed out, rules triggered by the updateatom currently considered in the procedure Execute areselected by the procedure Trig. This procedure performsa number of operations that depend on the update atomtype. In more detail:

• insertions: let u = +C(oid, oex) and +C(o′id, o′ex) be theevent part of a rule r. Then, r is activated by u if bothoid unifies with o′id and oex unifies with o′ex. Moreover,all attributes specified in o′ex must be specified in oex

as well. Conversely, attributes specified in oex may benot specified in o′ex;

• deletions: let u = −C(oid, oex) and −C(o′id, o′ex) be theevent part of a rule r. Then, r is activated by u onlyif oid unifies with o′id. In this case, however, the unifi-ability of oex and o′ex is not sufficient to determinethe activation of r. This is because oex could denoteonly partially the object value associated to oid. Thesame holds for o′ex. As an example, consider an up-date that deletes all employees working in a given de-partment and a rule that is triggered by the deletionof female employees. Then, the update has a valuespecified only for the department name and the eventof the rule has a value specified for the sex only. Inthe case that the deleted department had no femaleemployees, the rule should not be activated. There-fore, before executing the deletion, the object queryatom ?C(o′id, o′ex) must be evaluated, and its valuationmust return a non-empty result for the rule to be con-sidered for actual activation. Note that the unificationof the terms associated to attributes occurring both inoex and in o′ex is guaranteed by the unification of oid

and o′id and the evaluation of the object query atom?C(oid, oex) against the current data-base instance;

• modifications: let u = ∗(C(oid, oex), o′ex) and∗(C(o′′id, o′′ex), o′′′ex ) be the event part of a rule r. Then,r is activated by u only if oid unifies with o′′id. Asfor deletion, however, the unifiability of oex and o′′ex

is not sufficient to state the activation of r. There-fore, the object query atom ?C(o′′id, o′′ex) is evaluatedon the current data-base instance and must yield anon-empty valuation. Since, as explained below, theprocedure Perform has not yet actually executedthe requested modification when Trig is executed,by evaluating this object query atom we verify thatthe object to be updated corresponds to the specifica-tion appearing in the rule event part. For the rule tobe actually triggered it is, moreover, necessary thatthe object value produced by executing the modifi-cation corresponds to the second component of thespecification appearing in the rule event part. To ver-ify this latter condition, the unification algorithm iscalled on o′ex and o′′′ex . In particular, each attribute oc-curring in o′′′ex must occur in o′ex as well. The converseis not needed. Moreover, the rule is activated only ifthe attributes specified in o′′′ex have been modified intothe specified values. For instance, the modify atom

∗(book(X, [title : ′′Hamlet′′, total : T]),

[total : T + 1])

does not trigger a rule with event part:

∗(book(X, [title : ′′Hamlet′′, avail : A]),

[avail : A − 1])

since, despite the fact the modified object unifies withthe rule event part, the attribute avail of the classbook has been not actually modified.


4.4. Rule Executor

The module RE takes a goal as the input and evalu-ates it. It uses the modules TRM, QR, and UE. Infor-mally speaking, the module RE implements the controlstructure of the interpreter of the language. The GPR in-terpreter consists of a main program, called Interpreter,and three procedures: Verify, Execute, and Calculate.Next, we describe this interpreter.

PROCEDURE INTERPRETER

The main procedure Interpreter is reported in Figure 4.This main procedure takes an initial data-base state

and a goal as the inputs and returns the answer to thegiven goal, in terms of a set of variable substitutions, plusa new data-base state. Variable substitutions are com-puted by calling the procedure Verify. If the computedanswer is not empty, then the new state is computed bythe procedure Execute that evaluates the action part ofthe goal instantiated with each computed substitution.

The module RE makes use of two global variables:BRup and depthup. The former is a stack whose elementsare arrays realizing a priority queue. The latter stores thepointer to the top of the stack. BRup is used to implementupdate operations and a description of its managementis given in Procedure Execute below.

PROCEDURE VERIFY

The procedure Verify, shown in Figure 5, takes a querypart Q as the input, evaluates it against the current data-base state, and returns the associated (possibly empty)set Θ of variable substitutions.

The procedure Verify is basically based on a top-down evaluation strategy. However, the bottom-up eval-uation strategy is used to evaluate purely deductive rulesubsets using the semi-naive fixpoint, which features agreat simplicity coupled with good performances. In thetop-down case, the goal to be evaluated is selected ac-cording to the left-to-right ordering within the query partQ under consideration. As already said, selection policyfor rules is instead that of choosing those associated withhigher priorities first and ties on priorities are solved ac-cording to the order in which rules occur in the programsource text file. The search tree associated to the evalua-tion of the query is visited depth-first. The constructionof the answer is set-oriented.

The procedure Verify considers one atom q of thequery part Q at the time and evaluates it according to itscharacteristics. More precisely:

• If q is a built-in atom (e.g., a comparison predicate),the set Θc of current computed answers is built bycalling the procedure Calculate. This procedure,implemented in the module RE, includes the code forrealizing all built-in predicates.

• If q is a generalized query atom whose computationis purely deductive, the set Θc of current computedanswers is built by the special procedure Evaluateof the module DE, that evaluates the associated setof rules bottom-up, using a semi-naive fixpoint algo-rithm.

• If q is an object query atom then it is evaluated againstthe current data-base instance. This operation is car-ried out by calling the procedure Val of the moduleQR that returns the set Θc of current computed an-swers. Then, for each rule Ex ⇒ Qx • Ux triggeredby q (such rules are stored in the priority queue BR,which is duplicated for each activation of the pro-cedure Verify, and are selected by calling the pro-cedure Trig of the module TRM) the associated setof answers Θx is computed by recursively calling theprocedure Verify. If this recursive call is successful(i.e., a non-empty set of answers is returned), the pro-cedure Execute is called to evaluate Uxθ, for eachvariable substitution θ ∈ Θx.2 Moreover, through acall to the procedure Valid of the module TRM, allrules whose triggering events are invalidated by theexecution of update atoms in UxΘx are deleted fromBRup. The set of answers Θx is added to the set Θc.If, after evaluating all involved rules, the set Θc isempty, then the atom q fails and, consequently, thequery part Q fails globally. In this case, the Booleanvariable fail is set to true.

Upon termination of the evaluation of the first atom q,the set Θc is assigned to the set Θ of computed answers.Any set Θc computed by evaluating any atom but thefirst one is instead composed with the global set Θ. Ifthe variable fail is set to true, the procedure Verifyterminates with failure. If a failure does not occur, whenall the atoms in Q have been evaluated, the procedureVerify terminates returning the set Θ.

PROCEDURE EXECUTE

The structure of the procedure Execute is shown inFigure 6. It takes an action part U as input and mod-ifies the current data-base state according to the up-dates specified in U. We recall that the system imple-ments the immediate mode version of GPR semantics,that is, rules are executed as soon as they are triggered.

The first operation carried out in Execute is to incre-ment the value of the level variable depthup. This cor-responds to inserting a new element in the stack BRup.After that, an update atom u is chosen and the corre-sponding operation is performed by calling the proce-dures Perform, Mark Objects for Deletion, and Per-form Modification of the module UE. Then, rules pos-sibly triggered by the update u are selected by callingthe procedure Trig of the module TRM. Those rules arestored in the stack entry BRup[depthup]. For each ruletriggered by u, say Ex ⇒ Qx • Ux the condition partQx is evaluated by further calling the procedure Verify


procedure Interpreter;input: a goal ⇒ Q •U and a data-base state s;output: a set Θ of answer substitutions and a new data-base state sout;begin

depthup:=0;Verify(Q, Θ);output(Θ);if Θ ≠∅ then Execute(UΘ);Perform Deletion()

end;

FIG. 4. The GPR interpreter – main procedure.

and, if no failure is notified, the action part Ux (suit-ably instantiated by the variable substitutions obtainedby the evaluation of Qx) is executed by the procedureExecute. At the same time, the procedure Valid deletesfrom the stack BRup all triggered rules having an updateatom specified in their event parts and whose trigger-ing events have been invalidated by update atoms in Ux.At termination of the evaluation of all atoms in U, the

variable depthup is decreased by 1 and the procedureExecute terminates.

4.5. Query Resolver

This module implements the procedure Val of the in-terpreter. As such, it builds the set of variable substitu-tions associated to the evaluation of a query atom. Thus,the QR receives an object query atom either from the

procedure Verify(Q : a condition; var Θ : a set of answer substitutions);var Θc, Θx: sets of substitutions; BR: a priority queue; fail: boolean;begin

Θ :=∅; BR :=<>; fail:=false;while Q ≠∅ and not fail do

Θc :=∅;extract from Q the next atom q;if q is a built–in atom then Calculate(qΘ,Θ) and exit;if q corresponds to a pure deduction then Evaluate(qΘ,Θ) and exit;if q is an object query atom then

if | Θ | ≤ 1 then Θc := Val(qΘ, s) else Θc := Θ ◦ Val(q, s);BR:=Trig(P, qΘ);while BR ≠∅ do

select from BR the rule Ex ⇒ Qx •Ux that comes firstin the order determined by priorities and textual order;

Verify(Qx, Θx);if Θx ≠∅ then begin

Execute(UxΘx);for i:=1 to depthup do

BRup[i] :=Valid(BRup[i], UxΘx);Θc := Θc ∪Θx;

endifendwhileif Θc =∅ then fail:=true;Θ := Θc;

endwhileend;

FIG. 5. GPR interpreter: the procedure Verify.


procedure Execute(U : an action part);varΘ, Θx : sets of computed answer substitutions;begin

depthup:=depthup+1;while U ≠∅ do

extract from U the next atom u;Θq := Perform(u);if Θq ≠∅ then

BRup[depthup] :=Trig(P, uΘq);if u is a delete atom then

Mark Objects for Deletion(class of u, Θq);if u is a modify atom then

Perform Modification(uΘq);while BRup[depthup] ≠∅ do

select from BRup[depthup] the rule Ex ⇒ Qx •Ux that comes firstin the order determined by priorities and textual order;

Verify(Qx, Θx);if Θx ≠∅ then

Execute(UxΘx);for i:=1 to depthup do

BRup[i] :=Valid(BRup[i], UxΘx);endif

endwhileendif

endwhiledepthup := depthup − 1;

end;

FIG. 6. GPR interpreter: the procedure Execute.

module RE or from the module DE and returns its evalu-ation constructed by submitting a suitable O–SQL queryto the underlying object oriented DBMS.

The procedure yielding the O–SQL query correspond-ing to a given object query atom takes the class name andthe value term of this atom as input and returns three listsas the output.

1. S–Part: a list of variable names describing the select–clause of the O–SQL query;

2. F–Part: a list of pairs 〈type, variable name〉 describingthe for–each–clause of the O–SQL query;

3. W–Part: a list denoting a conjunction of conditions(each of which is implemented as a function call) de-scribing the where–clause of the O–SQL query.

Some examples that refer to the data base in Figure 1are given next. To begin with, assume we want to knowall authors from Italy. The following object query atomcan be submitted to the system:

?author([name : X, nation : “Italy”])

The translation algorithm constructs the following O–SQL query:

SELECT X

FOR EACH author Z, Charstring X

WHERE to be deleted(Z) = False AND

author name(Z) = X AND

author nation(Z) = “Italy”;

Since deletions are not actually executed before theend of the evaluation of a goal, the query includes thecondition to be deleted(Z) = False in order to dis-card objects that have been (implicitly) deleted before.

Assume now we want to know the titles of the bookssuch that no copy is currently lent. The following objectquery atom can be submitted to the system.

?book([title : Y, total : Z, avail : Z])

The correspondent O–SQL query is the following:

SELECT Y, Z

FOR EACH book X, Charstring Y, Integer Z

WHERE to be deleted(X) = False AND

book title(X) = Y AND

book total(X) = Z AND

book avail(X) = Z;


With reference to the example data base reported inFigure 1, the computed answers would be: Y = “ThePrince”, Z = 1.

The following query returns the author(s) of the bookentitled “Hamlet”:

?book([title : ”Hamlet”, authors : X])

The correspondent O–SQL query and the answer con-structed for the data-base instance of Figure 1 are thefollowing:

SELECT X

FOR EACH book Z, book 0 X

WHERE to be deleted(Z) = False AND

book title(Z) = ”Hamlet” AND

book authors(Z) = X;

X = {Shakespeare}.The system does not display the actual value bound to

the variable X: this value is an oid and, as such, is mean-ingless to the user. Therefore, values to be displayed areobtained by a recursive dereferencing over oid values.The dereferencing process is performed as follows. As-sume for simplicity that we begin with a single oid, sayoid, as in the previous example. The first step of the pro-cess consists in substituting oid with the correspondingcomplex value oex. If oex does not contain any furtheroid, then the process terminates. Otherwise, each oid oc-curring therein is substituted by the corresponding ob-ject value. The process is iterated until no oid occurs inthe computed value, or a cycle is encountered. Cyclesmay occur at the extensional level when recursion in thetype structure is present. For instance, assume we have adata base with a class type person having an attributespouse whose type is person. In this case, it mayhappen that there are two objects (oid, oex) and (o′id, o′ex)such that the value of the attribute spouse equals o′idin oex and oid in o′ex, respectively. By using a stack, thedereferencing process detects this situation and stops theiteration. Dereferencing is carried out within the proce-dure Val, at termination of the O–SQL query evaluation.

4.6. Update Executor

The module UE includes the procedures Perform,Mark Objects for Deletion, Perform Modificationand Perform Deletion, which are illustrated next.

PROCEDURE PERFORM

The procedure Perform receives an update atom fromthe module RE and returns a set of substitutions definingbindings between a variable and the oid of an object thathas been or has to be updated and, possibly, a new data-

base state. Depending on the form of the update atom itreceives, the procedure Perform executes different ma-nipulations on data, as follows.

• +C(oid, oex): the operation is executed only if oex isground. The oid term can be either ground or a vari-able. In the former case, it has been bound throughan object atom valuation: this means that the objectalready exists in some class C′ and the requested op-erations consists in making a copy of the object inthe class C. In the latter case, a new oid value is in-vented by the system and assigned to oid. Then, theprocedure stores the oid together with the object ex-tension (as specified by oex) in the class C. If complexterms are specified in oex, other suitable objects arepossibly created and stored in auxiliary classes (seeSection 4.1). If the oid is invented, a special counter,called number of classes and storing the numberof classes to which an object belongs, is set to 1, oth-erwise it is incremented by 1.

• −C(oid, oex): in this case, the first operation carriedout by Perform is to evaluate the object query atom?C(oid, oex) on the current data-base instance. The re-turned objects have to be deleted from the data base.However, they are not immediately deleted, in orderto allow a correct management of triggering basedon deletions. They are simply “marked” as deletedand treated accordingly in the following operations.We will describe the mechanism used to implementdeletions next.

• ∗(C(oid, oex), o′ex): similarly to the execution of dele-tions, the first operation carried out by Perform isto request the evaluation of the object query atom?C(oid, oex) on the current data-base instance. This op-eration returns the set of objects of C to be modified.Even in this case, the update operations are not im-mediately executed.

EXECUTION OF DELETE AND MODIFY ATOMS

As briefly illustrated above, the procedure Performdoes not execute any explicit deletions or modificationsof objects stored in the current data-base instance. Thereason is to allow, in the procedure Trig, a correct han-dling of triggering on the basis of deletions and modifi-cations. Actually, the execution of modifications is post-poned just slightly. Indeed, actual modifications are car-ried out by the procedure Perform Modification whichis executed at the end of the procedure Trig, so as toallow checking of both the old and the new values ofobjects involved in a modify operation.

Differently from modifications, the execution ofdelete atoms needs to be further procrastinated until thevery end of the entire evaluation of the initial user goal.Indeed, the behavior of the referential integrity con-straint mechanism of the Iris object manager does notallow us to obtain a correct handling of triggering basedon deletions if the straightforward strategy consistingin executing deletions as soon as they are requested is


adopted. This situation is illustrated by the following ex-ample. Consider the rule:

−book(X)⇒ true • −a book(Y, [book : X]).

that deletes all copies of a book if the book itself is re-moved from the data base. If the deletion −book(X)were explicitly executed before the triggering of the rule,the underlying object manager would assign, for eachobject stored in the data base, the null value to all at-tributes of type book that were previously referencingthe deleted object. As a consequence, differently fromwhat the rule states, no objects from the class a bookwould be deleted by executing this rule. Therefore, dele-tions are handled as follows. At termination of the pro-cedure Trig, if the atom under consideration is a deleteatom, the procedure Mark Objects for Deletion iscalled. This procedure executes the following operationson each object to be deleted:

1. the object and the class from which the object hasto be deleted are stored in the Delete-Log class(we recall that an object may belong to more thanone class and, as such, a deletion from a class doesnot necessarily imply a deletion from the whole database);

2. the object is implicitly deleted by assigning true tothe attribute to be deleted; note that the moduleQR generates queries that discard those objects whoseattribute to be deleted is set to true.

Explicit deletion of objects stored in the Delete-Logclass takes place only at termination of the entire eval-uation of a goal with the procedure Perform Deletion,which is called within the main procedure of the Inter-preter. In more detail, for each object specified in theDelete-Log:

1. the class counter (stored in the attribute number of

classes) is decremented by 1;2. if the object does not belong to other classes, that

is, its number of classes attribute equals 0, thenthe object is physically removed by invoking the Irisdelete object operation, otherwise the object is simplyforced to leave the class specified in the Delete-

Log by invoking the Iris remove type operation.

4.7. Deduction Evaluator

This module evaluates atoms corresponding to puredeductions using a bottom-up strategy, rather than usingthe top-down one. We recall that an atom correspondsto a pure deduction if its evaluation cannot directly orindirectly cause any update to the current data-base in-stance. The rationale under this choice is that top-downevaluation of rules presents some problems related to ter-mination of recursive rules, which does not characterizebottom-up strategy. In the presence of updates, due to theinherent procedurality of state transitions associated tothem, the use of top-down execution can not be avoided.

The module DE is based on the procedure Evaluate thattakes the goal corresponding to one such evaluation asthe input and evaluates the corresponding set of rulesusing a semi-naive fixpoint computation algorithm.

5. Conclusions

In this paper, the GPRS prototype has been presented.The system supports the rule language GPR [12], that in-tegrates, into a unified syntactic and semantic frameworkdeductive and active rules. This characteristic makes thesystem a powerful tool for the development of data-baseapplications based on rules. The system has been de-veloped in O–SQL with C as the host language on topof Iris, an object oriented data-base system. The systemruns under Unix on workstations HP Apollo 700. Theprototype structure is based on an abstract interpreterthat implements the formal semantics of GPR workingunder the immediate execution modality [12]. The under-lying object-oriented DBMS is used to implement data-base scheme definitions and basic manipulations on data(retrievals and updates).

At the moment, we are testing the system “on thefield” using two rule applications. A first, more tradi-tional one, regards the management of loans, acquisition,and dismission of books in an academic library. The sec-ond one is a (simulated) robot motion planning applica-tion. Simplified versions of some of the GPR rules usedin the former application are reported in this paper.

Several features are still missing in the present ver-sion of the system and will be added in the near future.First of all, we are developing a graphical interface basedon Motif to substitute the present naive one. Then, weare designing modules to implement the deferred execu-tion mode. Third, we are developing the porting of thesystem onto other commercial relational data-base man-agement systems, in order to have the system testable ina wider number of environments. Last but not the least,we are planning to implement tools for checking termi-nation and confluence, in order to make easier the workof programmers in rule applications development.

Acknowledgments

This work has been partially supported by ConsiglioNazionale delle Ricerche.

Notes

1. It is worth pointing out that here and elsewhere in this paper, thedouble arrow ⇒ does not indicate any kind of logical implica-tion; it can be simply seen as a syntactic that separates the causespecification from the effect specification.

2. Recall that the order of application of substitutions in Θx is non-deterministic.


References

[1] Abiteboul, S. (1990). Towards a deductive object-oriented databaselanguage. Data and Knowledge Engineering, 5:263–287.

[2] Abiteboul, S., and Vianu, V. (1991). Datalog extensions fordatabase queries and updates. J. Comput. System Sci., 43(1):62–124.

[3] Cacace, F., Ceri, S., Crespi-Reghizzi, S., Tanca, L., and Zicari,R. (1990). Integrating object oriented data modeling with a rule-based programming paradigm. In ACM SIGMOD Int. Conf. onManagement of Data, pp. 225–236.

[4] Ceri, S., Gottlob, G., and Tanca, L. (1989). Logic Programmingand Data Bases. Springer-Verlag.

[5] Ceri, S., Fraternali, P., Paraboschi, S., and Tanca, L. (1995). Activerule management in Chimera. In Active Database Systems. (S. Ceriand J. Widom, eds.) Morgan-Kauffman, pp. 101-128.

[6] Chakravarthy, S., and Nesson, S. (1990). Making an object-oriented DBMS active: design, implementation, and evaluation ofa prototype. In EDBT’90 (Int. Conf. on Extending Database Tech-nology,) Venice, LNCS 416, Springer-Verlag.

[7] Hanson, E. N. (1989). An initial report on the design of Ariel: aDBMS with an integrated production rule system. ACM SIGMODRecord, 18(3):12–19.

[8] Kiernan, J., de Maindreville, C., and Simon, E. (1990). Makingdeductive databases a practical technology: a step forward. In ACMSIGMOD Int. Conf. on Management of Data, pp. 237–246.

[9] Lloyd, J. W. (1987). Foundations of Logic Programming. Springer-Verlag, 2nd ed.

[10] McCarty, D., and Dayal, U. (1989). The architecture of an ac-tive database management system. In ACM SIGMOD Int. Conf.on Management of Data, pp. 215–224.

[11] Naqvi, S., and Tsur, S. (1989). A Logical Language for Data andKnowledge Bases. Computer Science Press, Potomac, Maryland.

[12] Palopoli, L., and Torlone, R. (1994). Generalized Production Rulesas a Basis for Integrating Active and Deductive Databases. IEEETrans. on Knowledge and Data Eng. To appear. An extended ab-stract of this paper appeared in the proceedings of Fourth Inter-national Workshop on Research Issues in Data Engineering: Ac-tive Database Systems (RIDE-ADS’94), IEEE Comput. Soc. Press,pp. 30–38, 1994.

[13] Sellis, T., Lin, C. C., and Raschid, L. (1993). Coupling productionsystems and database systems: a homogeneous approach. IEEETrans. on Knowledge and Data Eng., 5(2):240–256.

[14] Sellis, T., Lin, C. C., and Raschid, L. (1988). Implementing largeproduction systems in a DBMS environment: concepts and al-gorithms. In ACM SIGMOD Int. Conf. on Management of Data,pp. 404–412.

[15] Stonebraker, M. (1992). The integration of rule systems anddatabase systems. IEEE Trans. on Knowledge and Data Eng.,4(5):415–423.

[16] Stonebraker, M. L., Jhingran, A., Goh, J., and Potamianos, S.(1990). On rules, procedure, caching and views in database sys-tems. In ACM SIGMOD Int. Conf. on Management of Data,pp. 281–290.

[17] Widom, J., and Finkelstein, S. (1990). Set-Oriented productionrules in relational database systems. In ACM SIGMOD Int. Conf.on Management of Data, pp. 259–270.

[18] Zaniolo, C. (1993). On the unification of active databases and de-ductive databases. In Advances in Databases – 11th British Na-tional Conf. on Databases (BNCOD 11) LNCS 696, pp. 23–39,Springer-Verlag.


the gpr system: an architecture for integrating active and deductive rules on complex database...

Documents