On Active Deductive Databases

On Active Deductive Databases:

The Statelog Approach

Georg Lausen Bertram Ludascher Wolfgang May

Institut fur Informatik, Universitat Freiburg, Germany

flausen,ludaesch,mayg@info rmat ik.un i-fr eibur g.de

Abstract. After brie y reviewing the basic notions and terminology of

active rules and relating them to pro duction rules and deductive rules,

resp ectively,we survey a number of formal approaches to active rules.

Subsequently,we present our own state-oriented logical approach to ac-

tive rules which combines the declarative semantics of deductive rules

with the p ossibility to de ne up dates in the style of pro duction rules

and active rules. The resulting language Statelog is surprisingly simple,

yet captures many features of active rules including comp osite event de-

tection and di erent coupling mo des. Thus, it can b e used for the formal

analysis of rule prop erties like termination and expressivepower. Finally,

we showhow nested transactions can b e mo deled in Statelog, b oth from

the op erational and the mo del-theoretic p ersp ective.

1 Intro duction

Motivated by the need for increased expressiveness and the advent of new appli-

cations, rules have b ecome very p opular as a paradigm in database programming

since the late eighties [Min96]. Today, there is a plethora of quite di erent appli-

cation areas and semantics for rules. From a bird's-eye view, deductive and active

rules may b e regarded as two ends of a sp ectrum of database rule languages:

Deductive Rules Production Rules Active Rules

\higher" level \lower" level

RDL1, pro- strati ed, well-

A-RDL Ariel Starburst Postgres

:::::: :: :::: :::::: :::::: ::::::

: :

cedural Datalog founded Datalog

Fig. 1. Sp ectrum of database rule languages adapted from [Wid93 ]

On the one end of the sp ectrum, deductive rules provide a concise and elegant

representation of intensionally de ned data. Recursive views and static integrity

constraints can be sp eci ed in a declarative and uniform way using deductive

rules, thereby extending the query capabilities of traditional relational languages

like SQL. Moreover, the semantics develop ed for deductive rules with negation

are closely related to languages from the eld of knowledge representation and

In: Transactions and Change in Logic Databases, B. Freitag, H. Decker,

M. Kifer, and A. Voronkov, editors, LNCS 1472, Springer, 1998

nonmonotonic reasoning, which substantiates the claim that deductive rules are

rather \high-level" and mo del a kind of natural reasoning pro cess. However,

deductive rules do not provide enough expressiveness or control to directly sup-

p ort the sp eci cation of up dates or active b ehavior. Since up dates play a crucial

role even in traditional database applications, numerous approaches have b een

intro duced to incorp orate up dates into deductive rules.

In contrast to deductive rules, active rules supp ort reactive b ehavior like

triggering of up dates as a resp onse to external or internal events. Conceptually,

most rule languages for active database systems ADBs are comparatively \low-

level" and often allow to exert explicit control on rule execution. While such

additional pro cedural control increases the expressive power of the language

considerably, this is also the reason why the b ehavior of active rules is usually

much more dicult to understand or predict than the meaning of deductive

rules. Not surprisingly, researchers continue to complain ab out the unpredictable

b ehavior of active rules and the lack of a uniform and clear semantics.

Production rules constitute an intermediate family of languages and provide

facilities to express up dates and some asp ects of active b ehavior, yet avoid overly

detailed control features of active rules at the right end of the sp ectrum.

Contributions and Overview. In this pap er, we intro duce to the di erent

rule paradigms in databases in Figure 1, and survey a number of formal and

logical approaches to active rules. We then present a sp eci c state-oriented logical

approach to active rules called Statelog, which yields a precise formal semantics

for active rules. It can b e shown that certain pro duction rules and deductive rules

are sp ecial cases of Statelog rules, and that many but not all features of active

rules like comp osite event detection and di erent coupling mo des can b e sp eci ed

in Statelog. Thus, Statelog can serveas a uni ed logical framework for active

and deductive rules, in which fundamental prop erties of rules like termination

b ehavior, complexity, and expressiveness can b e studied in a rigorous way. The

main technical contribution of this pap er is the continuation and re nement

of [LML96], where a mo del-theoretic Kripke-style semantics for Statelog in the

context of a nested transaction mo del has b een presented.

The pap er is organized as follows: In Section 2, we rst intro duce the basic

terminology and features of active rules, and then brie y relate them to pro-

duction rules and deductive rules, resp ectively. Section 3 is a short survey on

some formal approaches to active rules. In Section 4, we intro duce Statelog, a

state-oriented extension of Datalog and summarize the main results. A key idea

of the approach is to add a state argument to every predicate: for example,

[s] px; y intuitively means that px; y holds in state [s] this idea has come

up several times; see Section 3.2. Starting from a simple mo del for at transac-

tions, the framework is extended subsequently to incorp orate nested transactions

Section 5. Section 6 develops an abstract, conceptual mo del for Statelog with

nested transactions by a mo del-theoretic Kripke-style semantics. Some conclud-

ing remarks are given in Section 7. 2

2 Rules in Databases

Rules in database programming languages come in many di erent avors. In this

section, we discuss language issues of the ab ove-mentioned rule sp ectrum and

highlight di erences b etween the paradigms.

2.1 Active Rules

Active rules are typically expressed as Event-Condition-Action ECA rules of

the form

on heventi if hcondition i then haction i.

Whenever the sp eci ed event o ccurs, the rule is triggered and the corresp onding

action is executed if the condition is satis ed in the current database state. Rules

without the event part are sometimes called production rules, rules without the

condition part are sometimes referred to as triggers.

Events. Events can be classi ed as internal or external. Internal events are

caused by database op erations like retrieval or up date insertion, deletion, mo d-

i cation of tuples, or transactional events like commit or ab ort. In ob ject-

oriented systems, such internal events may take place through metho d invo-

cations. External events o ccurring outside the database system may also be

declared and have to b e monitored by the ADB.

Starting from primitive external or internal events, more complex composite

events can b e sp eci ed using an event algebra ;typical op erators are disjunction

E jE , sequence E ; E , conjunction E ;E , etc. cf. [CKAK94,Sin95].

1 2 1 2 1 2

Alternatively, logics like past temp oral logic see e.g., [LS87,Cho95b] may be

used for the sp eci cation of comp osite events. Several event detection algorithms

have b een develop ed which allow to detect comp osite events without storing the

complete database history, for instance by applying temp oral reduction rules

[LS87,Cho95b] or residuation [Sin95].

A question arising from the use of comp osite events is which of the constituent

events \take part" in the comp osite event and how they are \consumed" by the

comp osite event. This event consumption policy is elab orated using parameter

contexts, whichwere intro duced for the SNOOP algebra in [CKAK94,CM94]. In

order to illustrate the di erent parameter contexts, consider the comp osite event

E := F; G; H , which o ccurs if H o ccurs after b oth F and G have o ccurred.

Assume the following event history is given:

G F F G F H H

1 1 2 2 3 1 2

j j j j j j j

Here, the F 's denote several o ccurrences of the same primitiveevent F , similarly

for G and H .

k l 3

Di erent parameter contexts are motivated by applications where constituent

events should b e consumed by the comp osite event in a certain way. The following

parameter contexts have b een prop osed [CKAK94]:

Recent: In this context, only the most recent o ccurrences of constituent

events are used; all previous o ccurrences are lost. In the ab ove event his-

tory, E will b e raised twice: for the constituentevents fG ;F ;H g and for

2 3 1

fG ;F ;H g.

2 3 2

Chronicle: In this context, events are consumed in their chronological order.

In a sense, this corresp onds to a rst-in- rst-out strategy: E will b e rep orted

for fG ;F ;H g and for fF ;G ;H g.

1 1 1 2 2 2

Continuous: In this context, each event which may initiate a comp osite

event starts a new instance of the comp osite event. A constituentevent can

b e shared by several simultaneous o ccurrences of the comp osite event. In the

example, each G and each F starts a new instance. Thus, the comp osite

i j

o ccurrences fG ;F ;H g, fF ;G ;H g, fF ;G ;H g, and fG ;F ;H g are

1 1 1 1 2 1 2 2 1 2 3 1

rep orted. The comp osite event initiated at F is still to b e completed.

Cumulative: In this context, all o ccurrences of constituentevents are accu-

mulated until and consumed when the comp osite event is detected. In the

example, E is raised once for the constituentevents fG ;F ;F ;G ;F ;H g.

1 1 2 2 3 1

Unrestricted: In this context, constituentevents are not consumed, but are

reused arbitrarily many times. For the ab ove history, E is rep orted for all

twelve p ossible combinations of fF ;G ;H g.

j k l

Conditions. If the triggering event of an active rule has b een detected, the

rule b ecomes eligible, and the condition part is checked. The condition can b e

a conventional SQL-like query on the current state of the database, or it may

include transition conditions, i.e., conditions over changes in the database state.

The p ossibility to refer to di erent states or delta relations is essential in order

to allow for active state-changing rules.

Actions. If the condition of the triggered rule is satis ed, the action is executed.

Internal actions are database up dates insert, delete, mo dify and transactional

commands commit, ab ort, external actions are executed by pro cedure calls

to application programs and can cause application-sp eci c actions outside the

database system e.g., send-mail, turn-on-sensor. Usually, it is necessary to pass

parameters between the di erent parts of ECA-rules, i.e., from the triggering

event to the condition and to the action part. In logic-based approaches this can

b e mo deled very naturally using logical variables, while this issue may b e more

involved under the intricacies of certain execution mo dels.

Execution Mo dels. The basic execution mo del of active rules is similar to the

recognize-act cycle of pro duction rule languages like OPS5 [BFKM85]: one or

more triggered rules i.e., whose triggering event and condition are satis ed are 4

selected and their action is executed. This pro cess is rep eated until some termi-

nation condition is reached|for example, when no more rules can b e triggered,

or a xp oint is reached. Clearly, there are a lot of p ossible choices and details

whichhave to b e elab orated in order to precisely sp ecify the semantics of rule

execution.

One issue is the granularity of rule pro cessing, which sp eci es when rules are

executed. This may range from execution at any time during the ADB's op era-

tion nest granularity, over execution only at statement b oundaries, to trans-

action b oundary execution coarsest granularity. Another imp ortant asp ect is

whether rules are executed in a tuple-oriented or set-oriented way. Set-oriented

execution conforms more closely to the standard mo del of querying in relational

databases, and is in a sense more \declarative" than tuple-oriented execution. In

contrast, tuple-oriented execution adds another degree of nondeterminism to the

language, since the outcome maynow dep end on the order in which individual

rule instances are red.

Finally, several coupling modes have b een prop osed, which describ e the re-

lationship b etween rule pro cessing and database transactions. Under immediate

and deferred coupling, the triggering event, as well as condition evaluation and

action execution, o ccur within the same transaction. In the former case, the ac-

tion is executed immediately after the condition has b ecome true, while in the

latter case, action execution is deferred to the end of the current transaction.

Under decoupled sometimes called detached or concurrent execution mo de, a

separate transaction is spawned for condition evaluation and action execution.

Decoupled execution may b e further divided into dep endent or indep endent de-

coupled: in the former case, the separate transaction is spawned only after the

original transaction commits, while in the latter case the new transaction is

started indep endently. In the most sophisticated mo dels, one may even have

distinct coupling mo des for event-condition coupling and for condition-action

coupling.

Systems. Most of the active database systems provide a low-level, procedural se-

mantics of rules; see e.g. [WC96a] for an overview on a numb er of systems. Early

precursors of active rules have b een intro duced in CODASYL, System R, and

OPS5. More recent systems include Postgres, Starburst, Ariel, Heraclitus, ODE,

and SAMOS. HiPAC has b een in uential by establishing the ECA-rule paradigm;

follow-on pro jects are Sentinel [CKAK94] with its p owerful event sp eci cation

language SNOOP and REACH. Regarding commercial systems, the current

SQL3 prop osal o ers so-called declarative constraints used sp eci cally for main-

taining referential integrity, and general-purp ose triggers [CPM96,ISO97].

A-RDL [SK96] is closely related to deductive databases: intensional relations

are de ned by means of deductive rules. Delta relations record the net e ect of

changes to edb -relations during execution of a transaction. Active b ehavior is

enco ded via rules in an if-then style.

Chimera [CFPT96] distinguishes b etween declarative and pro cedural expres-

sions: Declarative expressions are used in query primitives, integrity constraints, 5

and view declarations; transactions are sp eci ed using pro cedural expressions

for actions and declarative expressions in conditions.

2.2 Pro duction Rules

Pro duction rules can b e viewed as ECA-rules without the event part. However,

pro duction rules have b een around long b efore the ECA paradigm has b een

established. In particular, the pro duction rule language OPS5 [BFKM85] has

b een used in the AI community since the seventies. From a more abstract p oint

of view, one can regard general ECA-rules also as pro duction rules since the

event detection part can b e enco ded in the condition. This abstraction is very

useful as it allows to apply techniques and results develop ed for pro duction rules

to active rules.

Acharacteristic feature of pro duction rule semantics is the forward chaining

execution mo del: The conditions of all rules are matched against the current

state. From the set of triggered rules candidate set one rule is selected using

some con ict resolution strategy and the corresp onding actions are executed.

This pro cess is rep eated until there are no more triggered rules.

In the database community, such a forward chaining or xpoint semantics

has b een studied for a number of Datalog variants see, e.g., [AV91] thereby

providing a logic-based formalization of pro duction rules:

Let Datalog denote the class of Datalog programs which allow negated atoms

in rule b o dies. The in ationary Datalog semantics I-Datalog turns the well-

known immediate consequence op erator T develop ed for de nite logic pro-

grams into an in ationary op erator T bykeeping all tuples whichhave b een

derived b efore, i.e., T I := I[T I , where I is the set of ground atoms

derived in the previous round. Starting with a set of facts I the initial state,

T is iterated until a xp oint the nal state is reached. Since the computation

:: 2

is in ationary, deletions cannot be expressed directly. In contrast, Datalog

has a nonin ationary semantics by allowing negative literals to o ccur also in

the head of rules and interpreting them as deletions: if a negative literal : A

is derived, a previously inferred atom A is removed from I . If b oth A and : A

are inferred in the same round, several options exists: prioritymay b e given ei-

ther to insertion or to deletion, or a \no-op" may b e executed, using the truth

value of A from the previous state, or the whole computation may b e ab orted

[Via97]. While for I-Datalog termination is guaranteed, this is no longer the case

:: ::

of Datalog : it is undecidable whether a Datalog program reaches a xp oint

for all databases; moreover, con uence is no longer guaranteed if instead of the

presented semantics, a nondeterministic semantics is used [AS91]. On the other

hand, nondeterminism can b e a p owerful programming paradigm which increases

the theoretical and practical expressiveness of a language [AV91,GGSZ97].

For eciency reasons however, the distinction b etween events and conditions may

b e crucial in practice.

Another nonin ationary semantics called P-Datalog is obtained by only keeping the

newly derived tuples in each iteration; see also Section 4.5. 6

A problem with these \pro cedural" Datalog semantics is that the handling

of negation can lead to quite unintuitive results:

Example 1 Under the in ationary semantics, the program

tcX,Y eX,Y.

tcX,Y eX,Z, tcZ,Y.

non tcX,Y : tcX,Y.

do es not compute in non tc the complement of the transitive closure of a given

edge-relation e. The reason is that the last rule is applied \to o early", i.e., b efore

the computation of the xp oint for tc is completed. Thus, despite the fact that

the derivation of non tcx,y maybeinvalidated by a subsequent derivation of

tcx,y, this unjusti ed tuple remains in non tc.

Although the given program may be rewritten using a somewhat intricate

technique for delaying rules, a b etter solution is to use one of the declarative se-

mantics develop ed for logic programs whenever the use of negation is imp ortant;

see Section 2.3.

RDL1 [KdMS90] is a deductive database language with pro duction rule se-

mantics; a rule algebra is used as an additional control mechanism. A-RDL

[SK96] extends RDL1 by active database concepts, in particular delta relations

and a mo dule concept.

2.3 Deductive Rules

The logic programming and deductive databases communities have studied in-

depth the problem of assigning an appropriate semantics to logic programs with

negation and have come up with nowwell-established solutions: The strati ed,

wel l-founded, and stable semantics [ABW88,VG89,GL88] are generally accepted

as intended and intuitive semantics of logic programs with negation. For strat-

i ed programs like the one in Example 1, all three semantics coincide. For

non-strati ed programs, the well-founded semantics yields a unique three-valued

mo del, whereas the stable semantics consists of a p ossibly empty set of two-

valued stable mo dels, each of them extending the well-founded mo del.

For relational databases, i.e., nite structures, termination and con uence of

declarative rules can b e guaranteed: For example, under the strati ed semantics,

rules are partitioned into strata according to the dep endencies between rule

de nitions. Thus, the strata induce a partial order on rules which is used to

evaluate programs. Within each stratum, the rules are red simultaneously in

a set-oriented way. Since the computation within strata is monotonic, the rules

may also b e evaluated in arbitrary order and/or tuple-oriented within a stratum

without sacri cing con uence. Termination is guaranteed since it is not p ossible

to add and remove the same fact rep eatedly as is the case for Datalog and

nonin ationary Datalog .

A program is strati ed if no relation de nition negatively dep ends on itself; thus,

there is \no recursion through negation". 7

In principle, although Datalog is primarily a query language, it could be

used as a relational up date language, for example byinterpreting relations like

old R and new R as the old and new values of a relation R , resp ectively, or

0 00

by assuming that R , R , etc. refer to di erent states of R . However, suchan

approach has several drawbacks: First, part of the semantics is enco ded into

relation names and thus outside of the logical framework. More imp ortantly, the

language do es not incorp orate the notion of state which is central to up dates

and active rules. In particular, only a xed numb er of state transitions can b e

mo deled by \priming" relation names as describ ed ab ove.

Anumb er of deductive database prototyp es with declarative semantics exist

including Aditi, Coral, FLORID, Glue-Nail, LDL, LOLA, and XSB-Prolog cf.

[RH94,Min96,SP97].

3 Formal Approaches to Active Rules

Whereas the meaning of deductive rules is based on solid logical foundations,

the meaning of the more low-level and op erationally intricate active rules is

often hard to understand and predict|esp ecially, if the semantics is only given

informally. This has lead to numerous research towards formal foundations of

active rules. In the sequel, we discuss some of these approaches; due to lackof

space and the fo cus on logic-based approaches, we can only provide a rough and

necessarily incomplete summary.

3.1 Analysis of Rule Prop erties

Although there is a great variety of execution mo dels for active rules, certain

fundamental prop erties like termination and complexity come up rep eatedly and

have b een studied in the context of the resp ective execution mo dels:

Termination, Con uence, and Determinism. [AWH95] develop static anal-

ysis techniques for active rules which guarantee termination, con uence, and ob-

servable determinism i.e., whether each program pro duces a unique stream of

observable actions under the Starburst execution model. Rule analysis is based

on a triggering graph which contains an edge b etween rules r and r if the for-

i j

mer may trigger the latter. Termination is guaranteed if the triggering graph

is acyclic, con uence is guaranteed if all unrelated rules commute pairwise. Re-

lated work on static rule analysis using triggering and dep endency graphs or

techniques from term rewriting include [ZH90,BW94,BCP95,KC95,KU96].

ExpressivePower and Complexity. [PV97] develop a generic formal frame-

work for the sp eci cation of active databases: A trigger program consists of rules

of the form condition ! action, where condition is a rst-order sentence and

action is an external program. Each rule is assigned a coupling mo de either

immediate or deferred and a set of database events insertion, deletion on 8

which it reacts. It is assumed that a priority is assigned to rules, and that the

semantics is deterministic. Existing active database prototyp es can b e obtained

by sp ecializing certain parameters of the framework which allows to compare

their relative expressiveness. Moreover, the impact of active database features

on expressivepower and complexity is studied. In the presented framework, the

complexity of immediate triggering is essentially EXPTIME,even without delta

relations and PSPACE if there is a b ound on the nesting of immediate queues.

Deferred triggering is more expressive and captures PSPACE, EXPSPACE,or

all computations on ordered databases, dep ending on the allowed op erations for

queue management.

3.2 Logic-Based Formalizations of Rule Semantics

Whereas the ab ove-mentioned works fo cus on analysing rule prop erties in some

sp eci c execution mo del, a lot of research aims at formalizing and characterizing

the semantics of active rules in the rst place. Once a formal mo del has b een

established, abstract prop erties like termination or expressiveness can b e studied.

Situation Calculus Based. In [BL96,BLT97] a language L for active

activ e

rules is develop ed, which allows to formalize and reason ab out the b ehavior of

active rules. The language b orrows from L [BGP97], an extension of the ac-

tion description language A [GL93] used for mo deling actual and hyp othetical

actions and situations, which in turn is based on the situation calculus. The

main constructs of L are causal laws describing which uents are added

activ e

or deleted by an action, executability conditions stipulating when actions can

b e executed, and active rules de ning a triggering event, an evaluation mo de, a

conjunctive precondition, and a sequence of actions. The automaton-based se-

mantics of L uses transition diagrams with states lab eled by sets of uents

activ e

and transitions lab eled by actions to sp ecify the meaning of an active database

description in L . A translation of L into logic programs is presented

activ e activ e

using a situation calculus notation. The generated rules are non-strati ed, and

the choice op erator of [SZ90] which is based on stable mo dels is used for nonde-

terministically selecting one rule among all rules that may b e red in a situation.

Like the situation calculus, L fo cuses more on reasoning ab out the e ect of

activ e

actions than on the computationally easier task of executing them.

State-Oriented Datalog Extensions. By extending Datalog with a notion of

state, reactive pro duction rules and deductive rules can b e handled in a uni ed

way, thereby combining the advantages of active and deductive rules. Two such

closely related Datalog extensions are XY-Datalog [Zan93,Zan95,MZ97] and

Statelog [LHL95,LML96] see [KLS92] for an early precursor of the latter. The

sp eci cation of op erational asp ects like comp osite event detection and coupling

mo des is p ossible in the logical language since the rules allow access to di erent

database states|even complex execution mo dels for nested transactions can

be handled in this wayasshown in detail for Statelog in subsequent sections. 9

However, the more pro cedural asp ects are intro duced into the language, the more

intricate the representation of these features in the logical framework b ecomes.

XY-Datalog and Statelog are themselves closely related to Datalog [Cho95a],

a query language for temp oral databases.

Logic-Based Formalization of Op erational Semantics. In [FWP97], a

framework for the integration of the di erent operational semantics of active

and deductive rules is develop ed. The meaning of ECA rules is sp eci ed using

distinct sp eci cation languages for events, conditions, and actions, resp ectively.

The op erational semantics for these ECA sublanguages and their interplay is

formalized by means of deductive rules. More precisely, the database history

i.e., the ordered set of database states is mo deled using timestamp ed atoms,

and the meaning of events, conditions, and actions is de ned based on the event

calculus in [Kow92]. The approach has b een used for the formalization of the

active rule comp onent which is added to the deductive ob ject-oriented database

system ROCK&ROLL [BFP 95].

In contrast to Statelog and XY-Datalog, which provide a single uni ed lan-

guage for active and deductive rules, [FWP97] integrate the di erent operational

semantics of active and deductive rules using a common deductive sp eci cation

formalism.

Another approach to logic-based formalization of active rule semantics is pre-

sented in [FT95], where so-called Extended ECA rules are used to enco de the

op erational semantics of an ADB. Using these user-readable EECA rules, exist-

ing ADBs can b e compared and classi ed. The precise meaning of EECA rules

is obtained by translating them into a logical core language which sp eci es pro-

cedural details likeevent consumption, coupling mo des, etc. Unlike in Statelog,

this logical language is not meant to b e handled by the rule programmer, but is

considered as an internal representation which is used by the execution mo del,

and thus is on a lower-level than the EECA rules.

Pro duction Rule Semantics. Many approaches to active rules are based on a

forward chaining execution mo del in the style of pro duction rules, e.g., [AWH95],

[PV95], and [Zan93,LHL95]above. This is particularly true also for the PARK

semantics of active rules [GMS92], which can be conceived as an in ationary

xp oint semantics extended by a mechanism to handle up date literals +L and

L, denoting insertion and deletion of L, resp ectively. Similar as in Statelog

Section 4, up date literals corresp ond to events if they o ccur in the b o dy, and

to actions if they o ccur in the head. A main b ene t of the approach is the simple

and precise semantics with its exible con ict resolution p olicy, the latter b eing

a parameter to the PARK semantics. The Statelog approach also allows exible

con ict resolution p olicies, however, they are not treated as a black boxas in

Due to their declarative semantics with explicit states the latter may also b e eval-

uated top-down, say in XSB-Prolog [SSW94]; however, the b ottom-up view is more

natural in this context. 10

[GMS92], but can b e programmed within the logical rule language Section 5.5

and [Lud98].

3.3 Up date Languages vs. Active Rules

Since active b ehavior can b e sp eci ed by de ning new up dates as an automatic

resp onse to previous up dates, active rule languages and languages for up dates

share essential features. A prominent logical framework for up dates is Transac-

tion Logic T [BK94], a language that deals on a high level of abstraction with

the phenomenon of state change in logic databases. The fo cus is on the comp osi-

tion of complex up dates, whereas primitive up dates so-called elementary tran-

sitions are not part of T but regarded as parameters which are supplied bya

transition oracle. In T |like in most languages based on top-down evaluation|

up dates are expressed in the body. These approaches are often tuple-oriented,

so the sp eci cation of set-oriented up dates bulk-up dates b ecomes an issue.

[WF97] present an up date language based on deferredupdates which solves this

problem. Other well-known approaches in the deductive database community

subsumable under the \up dates in the b o dy" paradigm are the early works on

DLP [MW88] based on dynamic logic, and LDL up dates [NT89]. In contrast,

frameworks with semantics similar to pro duction rules typically express up dates

in the head of rules cf. Sections 2.2 and 4. A main di erence b etween up date

languages and active rules is that in the former, up dates are initiated explicitly

by the user, whereas the latter sp ecify how rules initiate up date transactions

automatically in resp onse to o ccurring events.

Bibliographic Notes

A go o d starting p oint for further reading is [WC96a] which contains a nice in-

tro duction to active rules [WC96b], and describ es the essentials of a number of

prototyp es. [DHW95] is another intro ductory text, [Cha92] contains a sp ecial

issue on active databases. [PDW 93] discusses dimensions of active b ehavior

such as structure and execution mo del of active rules which allow to examine

and classify ADBs according to their distinctive features. [FT95] contains an-

other classi cation of ADBs: the di erent p ossible options in rule b ehavior are

enco ded using Extended ECA rules, expressing the ab ove-mentioned semantic

dimensions, which are then translated into an internal core language. [PCFW95]

surveys work on formal sp eci cation of active database functionality. [DGG95]

presents the active database management system manifesto. In [Day95], a survey

on the accomplishments of research in active databases is given. The workshops

[WC94] and [BH95] were dedicated particularly to active rules; the workshop

series [PW93,Sel95,GB97] also has ma jor sections on active rules. 11

4 Extending Datalog with States: Flat Statelog

Although there has b een lot of work in active databases, no single generally

accepted framework for active rules has evolved the ECA paradigm|though

widely used and accepted|only givesavery rough idea of rule execution and

leaves most issues unresolved. The semantics of active rules is often de ned

only in an informal and pro cedural way, making it very dicult to understand

and predict the b ehavior of rules. Not surprisingly,it is required in the active

database manifesto [DGG95] that \::: rule execution must have a clear seman-

tics, i.e., must de ne when, how, and on what database state conditions are

evaluated and actions executed".

In the sequel, weintro duce Statelog, a logical framework for active rules which

precisely and unambiguously de nes the meaning of rules. Moreover, it allows

to study fundamental prop erties of active rules like termination, con uence and

expressivepower. The framework do es not account for all facets of active rules

which may be useful in practice e.g., tuple-level execution, but covers many

essential features including immediate and deferred execution and comp osite

events.

In this section, we present \ at" Statelog, which is based on a linear state

space and corresp onds to a at transaction mo del. Using a hierarchical state

space, a framework incorp orating nested transactions is develop ed in Section 5.

For simplicity of presentation, we p ostp one a detailed description of the signa-

ture delta relations, control relations, etc. to Section 5.2; the intended use of

relations will b e clear from the context.

4.1 Basic Execution Mo del

The basic execution mo del of Statelog is illustrated in Figure 2: States are iden-

ti ed by the natural numb ers IN ; the k -th nal state is denoted by f 2 IN .

0 k 0

Assume f is the current nal state of the database. The database remains

in this state as long as no new external events o ccur. Queries are executed

against f and mayinvolve base relations, derived relations i.e., lo cal views on

the current state, or historical information using certain auxiliary relations;

see Section 4.4. Observe that intermediate states are depicted as small circles,

whereas bigger circles corresp ond to nal states, i.e., which are materialized

and directly accessible to the user. External actions corresp ond to outputs of

the active rule program and are rep orted at nal states. As describ ed b elow, a

stream of incoming external events is conceived as a sequence E ; E ;::: of sets of

0 1

events which induces i a sequence of transactions b etween user-visible nal

states f ; f ;:::, and ii a stream of outgoing external actions A ; A ;:::

0 1 0 1

The simultaneous o ccurrence of a set of external events E is mo deled by

asserting, at the i-th nal state f , a nite set of facts

E = f[f ] ex j event ex has o ccurredg :

i i

For clarity, relations for external events \input" and external actions \output"

are pre xed with \ " and \ ", resp ectively; states are often bracketed: [s]. 12

In general, using this new \seed" information, the rules of a Statelog program

de ne a sequence of intermediate transitions

f ; f +1 ; f +2 ; ; f +k = f

i i i i i+1

until the transaction starting at f ends in the next nal state f . Events

i i+1

o ccurring b etween f and f are mapp ed to the new nal state f . It should

i i+1 i+1

b e clear from Figure 2 that the logic mo del of P [D [E [ [ E where D

0 k

denotes the initial database is \add-only", i.e., past states cannot b e changed,

and new events in uence only the current and future states. System-de ned

predicates BOT and EOT can b e used to distinguish b etween the di erent kinds

of states. In this mo del, the state space or temporal domain over which the

database evolves is isomorphic to the natural numb ers IN , i.e., a linear time

mo del is used. Another more general mo del is presented in Section 5.

incoming

E E E

0 1 i

external events

Classi cation of states

state BOT EOT

initial true false

f :: : f ::: f ::: f

0 1 i i+1

intermediate false false

BOT EOT EOT EOT

BOT BOT [$]

past nal true true

actual nal [$] false true

outgoing

A A A

0 1 i

external actions

Fig. 2. Mapping of external events to nal states and classi cation of states

4.2 Syntax

In Statelog, access to di erent database states is accomplished via state terms of

the form [S +k ] , where S +k denotes the k -fold application of the unary function

symbol \+1" to the state variable S . Since the database evolves over a linear

state space, S may only b e b ound to some n 2 IN .

A Statelog database D [k ] at state k 2 IN is a nite set of facts of the form

[k ] px ;:::;x where p is an n-ary relation symb ol and x are constants from

1 n i

the underlying domain. If k = 0, or is understo o d from the context, we simply

write D .

A Statelog rule r is an expression of the form

[S +k ] H [S +k ] B ; ::: ; [S +k ] B

0 1 1 n n

where the head H is a Datalog atom, B are Datalog literals atoms A or negated

atoms : A, and k 2 IN . The leap l := k k of B is the distance b etween the

i 0 i 0 i i

state referred to in the head and the state for B in the b o dy. If several literals

i 13

share the same state term [S +k ], then [S +k ] can b e \factored out": e.g., the

body [S ] B ; [S +1] B ; [S +1] B may b e abbreviated as [S ] B ; [S +1] B ;B .

1 2 3 1 2 3

We require that Statelog rules are progressive, since the current state cannot

be de ned in terms of future states, nor should it be p ossible to change past

states: A rule r is called progressive,ifk k for all i =1;:::;n.Ifk = k for

0 i 0 i

all i =1;:::;n, then r is called local and corresp onds to the usual query rules.

On the other hand, if k = 1 and k = 0 for all i 1, r is called 1-progressive

0 i

and denotes a transition rule. A Statelog program is a nite set of progressive

Statelog rules.

4.3 Semantics

Every Statelog program may b e conceived as a standard logic program by view-

ing the Statelog atom [S +k ] pt ;:::;t assyntactic sugar for pS +k; t ;:::;t .

1 n 1 n

In this way, notions e.g., local strati cation and declarative semantics e.g., per-

fect model M develop ed for deductive rules can b e applied directly to Statelog.

Here, we adopt the state-strati ed semantics as the canonical mo del of a

Statelog program P with database D . P is called state-strati ed, if there are no

negative cyclic rule dep endencies within a single state [LHL95]. More precisely,

state-strati cation is based on the extended dependency graph G of P . Its no des

l;:

are the rules of P . Given two rules r ;r there is an edge r ! r 2G if the

1 2 1 2 P

relation symb ol in the head of r o ccurs p ositively negatively in the b o dy of

r . Here, l is the leap of the corresp onding literal in r . P is state-strati ed

2 2

if G contains no local cycle C i.e., where l = 0 involving a

l;:

r ! r 2C

1 2

negative edge. This notion is closely related to XY-strati cation [Zan93] and

ELS-strati cation [KRS95]. Together with the requirement of progressiveness,

state-strati cation implies lo cal strati cation [Lud98]:

Theorem 1 State-Strati cation

Let P beaconstant-free and progressive Statelogprogram. Then,

P is state-strati ed , P is local ly strati ed.

Thus, if P is lo cally strati ed, there exists a unique perfect model M [Prz88],

P [D

for any Statelog database D = D [0] .

Example 2 Consider the following progressive Statelog program, which deletes

all employees E from a department D which is deleted:

r : [S ] del:empE,Sal,D [S ] del:deptD, , empE,Sal,D .

r : [S +1] empE,Sal,D [S ] empE,Sal,D, : del:empE,Sal,D .

On o ccurrence of a delete eventtodept, r checks whether there is an employee

E working at department D, and if so, this employee is put in a sp ecial delta

relation del:emp cf. Section 5.2. r is a frame rule sp ecifying that only those

Here, p denotes anytyp e of relation base, control, ...; see Section 5.2.

See Section 6 for a mo del-theoretic Kripke-style semantics. 14

tuples are copied to the instance of emp at the next state which are not in

del:emp.Thus, logically, no real deletion o ccurs but a smaller \copy" of the old

database state is created. Note that although the program is not strati ed, it is

1;:

! r ! r is not lo cal i.e., do es not state-strati ed since the negative cycle r

1 2 2

o ccur within a single state.

Note that state-strati cation do es not imply lo cal strati cation for non-

progressive rules hence the progressiveness requirement in Theorem 1:

Example 3 Non-Progressive Rules The program

P : [S ] p [S +1] : p.

is state-strati ed since it contains no lo cal cycle. However, the truth-value of

[n] p dep ends negatively on the unfounded sequence [n+1], [n+2], :::,soP is

not lo cally strati ed: in the well-founded mo del, p is unde ned.

4.4 Comp osite Events

Although the Statelog language is surprisingly simple, various kinds of comp osite

events and consumption mo des can be expressed, as shown in [MZ95] using a

closely related variant of Datalog . Assume, for instance, that wewant to detect

the comp osite event

E X; Y :=F X ; GY ;

i.e., F X followed by GY for some external or internal events F and G.

Under an unrestrictedcontext, this can b e expressed by temporal reduction rules

similar to [LS87,Cho95b]:

[S ] detd:F X [S ] F X :

[S +1] detd: F X [S ] detd:F X :

[S +1] detd: E X; Y [S ] detd:F X ; [S +1] GY :

Auxiliary relations detd: R store det ected events. Using slight mo di cations of

these rules, di erentevent consumption mo des can b e accomplished:

to the second rule, only the most recent o ccur- If one adds the goal : F

rences of F are used, thereby mo deling event consumption with recent context.

Note that in this variant the most recent o ccurrence of F can take part in several

o ccurrences of E .However, if : F and : E ; are added to the second rule,

then every o ccurrence of E consumes all constituentevents, so F can take part

only in one o ccurrence of E .

Under the chronicle context,events are pro cessed in a rst-in- rst-out man-

ner, and thus make use of a queue in an essential way. Therefore, one can show

see [Lud98] that comp osite events with chronicle contexts are not expressible

in pure Statelog and require appropriate extensions e.g., timestamping as in

[MZ95]. 15

4.5 Formal Results

Using Statelog as a uni ed logical language for active and deductive rules allows

to study abstract rule prop erties like termination, expressivepower, and com-

plexity see also Section 3.1. Here, we only sketch the main results; see [LLM98]

and [Lud98] for details.

For notational convenience, we do not distinguish b etween base relations and

external events b elow, but assume w.l.o.g. that a Statelog database D [k ] includes

the set of external events o ccurring in state k as a set of facts.

Termination. We say that a Statelog program P terminates for D , if the

sequence of database states induced by P and D b ecomes stationary|more

precisely: if for some n and all n n : M [n] = M [n+1], where the

0 0 P [D P [D

snapshot M [n] at state n of the p erfect mo del M is de ned as

P [D P [D

M [n] := fpx j M j=[n] pxg :

P [D P [D

If P terminates for D , then M [$] is used as a generic notation for the unique

P [D

nal state; otherwise, we agree to set M [$] := ;.

P [D

Let Term denote the set of pairs P; D such that P terminates for D ;

P;D

Term and Term denote the set of Statelog programs which terminate

9D ;P 8D ;P

for some and al l databases D , resp ectively. Then one can show [Lud98]:

Theorem 2 Termination 1. Term and Term are undecidable.

9D ;P 8D ;P

2. Term is PSPACE-complete with n = jD j.

P;D

3. Term can be decided using a Statelog program P which i terminates

P;D

for al l D , and ii is e ectively constructible from P .

Note that 3 means, in a sense, that Statelog programs allow to \sp eak" ab out

their termination b ehavior at run-time i.e., for given D . However, since testing

for termination may b e prohibitively exp ensive, it is desirable to identify ecient

classes of terminating programs:

One such class is G-Statelog guarded Statelog where each up date rule is

required to have a p ositive o ccurrence of an external event in the b o dy, thereby

guaranteeing that such rules can be applied only once at the b eginning of a

transaction. Another more p owerful class is -Statelog -monotonic Statelog :

here, the basic idea is to enforce termination by preventing oscillation of up dates

i.e., rep eated insertion and deletion of the same tuple. Since Statelog programs

op erate on nite structures, the corresp onding constructions guarantee termina-

tion in PTIME.

Di erent Rule Semantics in Statelog. As shown ab ove and in Section 5,

Statelog allows to handle typical features of active rules at the right end of the

sp ectrum in Figure 1, like comp osite event detection and reactive programming

of up dates. Moreover, several of the more declarative languages in the middle

and further to the left of the sp ectrum turn out to b e special cases of Statelog

rules: 16

Production rules : Let I-Datalog and P-Datalog denote the in ationary and

nonin ationary or partial semantics for Datalog , resp ectively.

Deductive rules : The declarative semantics for Datalog programs are de-

noted by S-Datalog strati ed Datalog and WF-Datalog well-founded Dat-

alog, resp ectively.

These semantics have a very natural representation in Statelog [Lud98]; see

Figure 3: Observe that the nonin ationary P-Datalog semantics only transfers

those tuples to the new state, which are derived anew. In contrast, the in a-

tionary I-Datalog semantics propagates all previously derived tuples through all

states. S-Datalog rules can b e represented directly by lo cal state-strati ed rules.

Finally, one way to represent the alternating xp oint computation [VG89] of

WF-Datalog is as shown in Figure 3: this enco ding yields a terminating pro-

gram i the well-founded mo del is total; however, using a \doubled" enco ding,

it is easy to obtain a program which explicitly computes the true, false, and

unde ned atoms and always terminates.

P-Datalog : [S +1 ] H [S ] B; [S ] : C

I-Datalog : [S +1 ] H [S ] B; [S ] : C

[S +1 ] H [S ] H

H B; : C ,

S-Datalog : [S ] H [S ] B; [S ] : C

WF-Datalog : [S +1 ] H [S +1] B; [S ] : C

Fig. 3. Enco ding schema for di erent rule semantics

Expressive Power and Complexity. With every Statelog program P one

can asso ciate di erent database mappings: The most imp ortant one describ es

the transaction expressiveness, i.e., the mapping : D [0] 7! M [$] from

P [D

the initial database state to the nal state.

A natural question is: What kind of database mappings can be expressed

using Statelog wrt. transactions? For languages involving intermediate states

like XY-Datalog and Statelog, one can also consider transition expressiveness,

i.e., the class of database mappings from one state to the immediate successor

state.

Figure 4 summarizes the main results wrt. transition and transaction ex-

pressiveness: In the middle, well-known classes of database transformations are

depicted cf. [AHV95]. To the left and right, the equivalent wrt. transitions

and transactions, resp ectively Statelog variants are depicted: 17

Transition Expressiveness Transaction Expressiveness

All

fPjNFjWFj"g-Statelog

While

XY-Datalog

WF-Statelog

Fixp oint

fIjg-Statelog

fGjjNFj"g-Statelog

S-Datalog

G-Statelog

XY-Datalog

Datalog

9FO

fPjIg-Statelog =

pos9FO

Conjunctive

DB-PSPACE

Data Complexity :

DB-PTIME

Fig. 4. Summary of expressiveness results [Lud98]

WF-Statelog is a Statelog variant where rules need not be strati ed, but

mayinvolvewell-founded negation; G-, -, NF-, P-, I-, and "-Statelog denote

guarded, -monotonic, normal form, nonin ationary, in ationary, and unre-

stricted Statelog, resp ectively [LLM98,Lud98]. In NF-Statelog, for example, rules

may only be 1-progressiveor lo cal. The expressiveness results in Figure 4 can

be established using rewritings into NF-Statelog and the ab ove enco dings of

di erent Datalog semantics. The nice matchbetween Statelog classes and the

known query classes also yields the corresp onding complexity results: Statelog

transitions are always evaluable in PTIME, whereas transactions may require

PSPACE in general. An ecient i.e., PTIME-evaluable class of transactions

is given by -Statelog, a class of terminating Statelog programs which|unlike

in ationary languages|allows b oth insertions and deletions.

5 Nested Transactions in Statelog

The Statelog programs considered so far de ne a single transaction from the

current state to the new nal state for any given database which includes a set

of external events. External events o ccurring subsequently corresp ond to new

facts b eing added and initiate the next transaction. Thus, the Statelog execution 18

mo del depicted in Figure 2 corresp onds to a at transaction mo del. In the se-

quel, we showhow Statelog can b e extended to mo del nestedtransactions. With

nested transactions, Statelog provides a uni ed framework for mo deling several

advanced concepts in active databases, e.g., sophisticated coupling mo des, event

consumption p olicies, and trigger ring p olicies.

The following example, adapted from [MW88,Che95], motivates why struc-

turing capabilities and a re ned transaction mo del may b e useful:

Example 4 To Hire or Not to Hire

Consider relation emp from Example 2. We want to hire an employee only if

the average salary after the up date do es not exceed a certain limit. Such a

\p ost-conditional" up date may b e expressed in at Statelog as follows:

[S ] ins:empE,Sal,D, [S +1] checksalD [S ] hire if p ossibleE,Sal,D.

[S ] check ok [S ] checksalD, avgD, AvgSal, AvgSal < 50000.

[S +1] del:empE,Sal,D [S ] hire if p ossibleE,Sal,D, [S +1] : check ok.

On o ccurrence of the external event hire if p ossibleE,Sal,D, employee E is

preliminarily inserted and the new average salary is checked in [S +1]. If it

exceeds the admissible amount, the insertion is undone by the last rule.

The ab ove program sp eci es the desired transaction, yet there are some p otential

pitfalls and drawbacks with this solution:

Undoing the e ect of changes here: the comp ensation of insertions by corre-

sp onding deletions has to b e programmed by the rule designer. However, it

is often desirable to automatical ly propagate the failure of a subtransaction

like checksal.

There is no structure which allows grouping of semantically closely related

rules.

The e ects of ephemeral changes [Zan95], i.e., changes whose e ect is undone

later within the same transaction, and hypothetical changes are visible to

other rules, since there is no encapsulation of e ects of semantically related

rules. E.g., if hire if p ossible... o ccurs in [S ], the delete request ins:emp

may trigger other active rules, although in [S +2] the up date is revoked. This

may lead to unjusti ed reactions by other rules, similar to those describ ed

in [Zan95].

To avoid these problems, the transaction concept considered so far has to be

re ned: First, sp eci c system-de ned rules can be used to automatically undo

the e ect of failed transactions. Moreover, the second and third item can be

resolved by grouping rules into certain mo dules which encapsulate rule e ects.

In principle, a at transaction mo del would be sucient here. However, it is

often natural and more adequate to mo del certain tasks as subtransactions which

For simplicity,we view the predicate holding the average salary avgD,AvgSal of a

department D as a built-in. 19

are nested within the calling transaction: For example, hireE,Sal,D maybea

subtransaction of a top-level transaction main; the salary check in turn maybe

a subtransaction of hire see Example 6.

5.1 Hierarchical State Space

In order to mo del nested transactions and handle the problems describ ed ab ove,

[LML96] prop ose the concept of Statelog procedures. A Statelog pro cedure is

a named and p ossibly parameterized set of Statelog user rules. In this sense, the

at Statelog programs considered so far can be seen as parameterless anony-

mous Statelog pro cedures. When is called at run-time, it de nes a transaction

T by issuing primitive up dates through delta relations and/or calling other

pro cedures which in turn may de ne subtransactions, etc. T either terminates

successfully indicated by a sp ecial predicate committed: , or ab orts. When

calls another pro cedure , a subtransaction T is started whose results are either

incorp orated into T ,ifT commits, or discarded otherwise. From the p ointof

view of the calling transaction T , the subtransaction T is atomic, therefore

requests derived directly within T and those submitted by T should b e indis-

tinguishable. This is achieved by certain system-de ned rules.

The b ehavior of is encapsulated, since deltas de ned by T are only visible

within T , but not in other concurrent transactions. Subtransactions execute

in isolation and in an al l-or-nothing manner, i.e., no results of T will b e visible

in T if T ab orts. Note that this do es not mean that T also ab orts|on the

contrary, can detect the failure of T via ab orted: and issue alternativeor

comp ensating actions, or retry the execution of later.

In order to mo del the isolated execution of a Statelog pro cedure as a

subtransaction T , a unique name space for each parameterized invo cation

of x has to b e intro duced. This is accomplished by extended state terms and

frame terms. The latter provide the transaction frame in which executes.

The execution of Statelog pro cedures as nested transactions induces a hier-

archical structure of the state space instead of the linear structure considered

b efore cf. Figure 5. Every state term enco des the complete transaction hierar-

chy from the top-level transaction down to the current transaction. States on the

same level are group ed into transaction frames. The mo del-theoretic foundation

of this concept is given by Kripke structures with di erent accessibility relations,

see Section 6.

Given a xed set of pro cedure names of a Statelog program, the set of

state identi ers S and frame identi ers F are de ned as the least sets such

that

["] 2 F ,

[f:n] 2 S ,if[f ] 2 F and n 2 IN ,

! 9

[s: x ] 2 F ,if[s] 2 S ; 2 , and x 2 U .

9 ! i

U := U .

i2IN 20

[":2: ]

[":2::0] [":2::n ]

[":0] [":1] [":2] [":3] ["]

[":2: :0] [":2: :m ]

[":2: ]

[":2: :1] [":2: :m{1 ]

[":2: :1::0] [":2: :1::k ]

[":2: :1: ]

Fig. 5. States and frames

Here, the arity of matches that of x = x ;:::;x , and U is the underlying

1 k

domain. State terms and frame terms are de ned similarly but may also involve

variables. State and frame identi ers induce a hierarchically structured state

space: The initial frame ["] denotes the top-level transaction, its initial state is

[":0] . Let [s] denote the current state. Then for a pro cedure call x , the frame

of the subtransaction induced by the execution of x is[f ] =[s: x ] and the

rst state of the transaction is [f:0] =[s: x :0] . The successor state of [f:n]

on the same level is [f:n+1] . The grouping of states into a frame [f ] 2 F

is de ned as

[f ] := f [f:n] j n 2 IN g ;

which implies that every state [f:n] b elongs to exactly one frame [f ] . Using this

representation, the frames [s: x ] and [s:y ] induced by di erent parallel

pro cedure calls of and in the same state [s] can b e uniquely identi ed if the

name of the pro cedure is the same, at least the parameters are di erent. Sim-

ilarly, frames of transactions induced by the same procedurecal l from di erent

states,[s : x ] and [s : x ] , can also b e distinguished. The constructor \." is

1 2

left-asso ciative: e.g., [s : :s2: ] = [s : :s2: ].

1 1 2 1 1 2

5.2 Signature

In order to mo del the sp eci c features of active rules, weintro duce several typ es

of relations their precise semantics and interplay will be sp eci ed by system-

de ned Statelog rules b elow: The set of relation symb ols of a given schema R

is given as the disjoint union of the following sets:

______

R = edb R [ idb R [ R [ R [ R [ prot R [ R [ ctl R: 21

Base and Derived Relations. The extensional database edb R comprises

the base relations which are stored in the database. In user-de ned rules, edb -

relations may only o ccur in the b o dy; they are up dated via delta relations from

R. In contrast, derived relations b elong to the intensional database idb R

and de ne views. Thus, idb -relations may o ccur in rule heads and b o dies but

may not be changed directly. Typically, idb -relations are not materialized but

computed on demand.

External Events and Actions. Relations from R represent external events

of interest which are monitored by the ADB. Consequently, external events can

only o ccur in rule b o dies. External actions are de ned by the relations from

R and represent requests to execute certain actions outside the ADB system.

Relation symb ols denoting external events and actions are pre xed with the

symb ols \ " and \ ", resp ectively.

Delta Relations. For every base relation p 2 edb R there are delta relations

del:p; ins:p 2 R. Delta relations or just deltas denote up date requests to

delete or insert the corresp onding tuples into p, resp ectively.For simplicity,we

write mo d:px=y instead of del:px; ins :py .

Pro cedure Calls. R denotes the set of procedure names. A pro cedure

with parametersx is \called" by deriving x in the head of a rule.

Proto col Relations. For every base relation p 2 edb R there are protocol

relations deld:p; insd:p 2 prot R for ins erted and deleted, resp. which store

the accumulated net e ect of a sequence of up dates. They can b e used for sev-

eral purp oses, e.g., to enforce termination, as an auxiliary store for ab orting

transactions, or for returning the net e ect of a subtransaction [Lud98].

Note that from the ab ove-mentioned relations, only those from idb R, R,

R, and R are user-de nable; the relations from edb R and prot R are

maintained by the system.

Control Relations. ctl R contains sp ecial control relations like BOT, EOT,

running, and ab ort for transaction control, and auxiliary relations for the detec-

tion of comp osite events. Additionally, ab orted: x orcommitted: x indicate

if a subtransaction has b een ab orted or committed.

5.3 User-De ned vs. System-De ned Rules

In the Statelog core language there is no distinction between user-de ned and

system-de ned rules e.g., the program given in Example 2 explicitly contains

the frame rule r . However, an ADB system should provide the user with a

prede ned intuitive programming \environment" which takes care of low-level 22

asp ects of the execution mo del like frame rules and transaction control. In par-

ticular, one may hide the explicit handling of states from the user by forcing

her to use only lo cal rules. If the user really needs to refer to di erent states,

syntactic sugaring in the form of prede ned op erators can b e used Example 5.

5.4 User-De ned Rules

We require that all user-de ned Statelog rules are lo cal; thus, state terms may

b e omitted. Moreover, only relations from idb R, R, R, R and cer-

tain distinguished relations from ctl R are allowed to o ccur in rule heads of a

user program. For example, the usual integrity constraints from databases like

functional, join, and inclusion dep endencies can b e enco ded in the form of de-

nials, i.e., as a set of lo cal rules s.t. ab ort is derived by these rules if an integrity

violation is detected.

Programs and Pro cedures. A Statelog program is a nite collection of

Statelog pro cedures. A Statelog procedure is an expression of the form

pro c X ;:::;X fH B ; ::: ; H B g

1 n 1 1 k k

where X ;:::;X are the parameters of whichmay o ccur in the Statelog user

1 n

rules H B .Every program contains a distinguished pro cedure main.

i i

As in the case of at Statelog, the meaning of rules is given by the declarative

semantics of their representation as a logic program. Esp ecially, if rules are lo cally

strati ed, a unique p erfect mo del exists.

Dep ending on the relation symb ol in the head of a rule, the following cases

can b e distinguished:

Views: pX ::: if p 2 idb R

Change Requests: ins:pX ::: if ins:p 2 R

del:pX ::: if del:p 2 R

Procedure Cal ls: X ::: if 2 R

External Actions: aX ::: if a 2 R

Transaction Control: ab ort :::

External events are allowed only in the b o dy of rules of main, whereas actions

may o ccur in all pro cedures, but are only allowed in rule heads. Since edb -

relations are not directly user-de nable, all changes to base relations havetobe

accomplished through insert and delete requests. The materialization of these

requests is implemented by frame rules as describ ed b elow.

A logic programming semantics for Statelog with nested transactions is presented

in [LML96 ]. Note that in order to guarantee lo cal strati cation, also dep endencies

through subtransactions have to b e considered. 23

Visibilityof User-De ned Rules. Let P denote the user-de ned rules

of a pro cedure . Apart from P , the visible user-de ned rules P [S: x ] in

frame [S: x ] include idb -relations of the calling transaction:

De nition 1 The set of visible rules P [F ] of a frame is de ned as

P ["] := P main

P [F :n: x ] := P [fp::: B 2 P [F ] j p 2 idb Rg

for all n 2 IN ; 2 R:

Thus, idb -relations are communicated to subtransactions by passing their de n-

ing rules, whereas edb -relations are communicated to subtransactions by copying

their extensions into the initial state of a subtransaction.

5.5 System-De ned Rules

System-de ned frame and pro cedure rules implement the intended semantics of

request relations, proto col relations, and pro cedure calls. All changes are encap-

sulated within the current transaction frame and invisible everywhere else until

the transaction commits. State terms are used in the sp eci cation of transitions

and transaction management.

Starting a Transaction. If one or more external events ex o ccur, the

b eginning of a transaction is signaled:

[S ] BOT [S ] eX :

We assume that all external events which are detected within a certain time

interval are raised only in the initial state of the top-level transaction which

coincides with the nal state of the previous transaction. All events o ccurring

subsequently are asso ciated with the next initial state.

Frame Rules sp ecify the correct handling of up date requests and transitions.

For all p 2 edb R, there are the following frame rules:

[S +1] pX [S ] ins:pX ; : EOT:

[S +1] pX [S ] pX ; : del:pX ; : EOT:

Thus, up dates to base relations are executed immediately in the transition to

the successor state, unless the end of transaction is detected. Clearly, instead

of this immediate coupling b etween condition evaluation and action execution,

one could also sp ecify deferred execution. Then a di erent set of frame rules

accumulates delete requests and executes all of them at the end of transaction.

Frame rules also propagate the edb to the subsequent transaction:

[S +1] pX [S ] ins:pX ; BOT:

[S +1] pX [S ] pX ; : del:pX ; BOT: 24

Proto col relations insd:p; deld:p 2 prot R store the accumulated net e ect of

changes during a transaction:

[S +1] insd:pX [S ] ins:pX ; : EOT:

[S +1] insd:pX [S ] insd: pX ; : del:pX ; : EOT:

[S +1] deld:pX [S ] del:pX ; : EOT:

[S +1] deld:pX [S ] deld:pX ; : ins:pX ; : EOT:

While there are p ending change requests, a transaction is running:

[S ] running [S ] ins:pX ; : pX :

[S ] running [S ] del:pX ;pX :

A xp oint is reached when there are no more changes, so EOT is signaled:

[S ] EOT [S ] BOT; : running:

[S +1] EOT [S ] running; : ab ort; [S +1] : running:

The internal event ab ort terminates a transaction prematurely:

[S ] EOT [S ] ab ort:

Apart from user-de ned ab orts, a transaction ab orts if inconsistent requests are

raised:

[S ] ab ort [S ] ins:pX ; del:pX :

Other con ict resolution p olicies can also be easily sp eci ed: For example, if

the previous rule is omitted, the ab ove frame rules give priority to insertions

whenever insertions and deletions o ccur simultaneously. Similarly, if one adds

the goal : del:pX to the ab ove frame rules with ins:pX in the body, then

deletions will have higher priority.

Pro cedure Rules implement the semantics of pro cedure calls, i.e., the execu-

tion of subtransactions.

For all 2 R;p 2 edb R, there are the following rules:

A pro cedure call creates the initial state of a new frame, signals BOT and

initializes the edb -relations:

[S: X :0] BOT [S ] X :

[S: X :0] pY [S ] pY ;X :

The pro cessing of the results is implemented by rules checking the successful

termination of the subtransactions and evaluating their proto col relations. Since

these contain the changes made by the subtransactions, their extensions are

copied into the request relations of the parent transaction:

[S ] ins:pY [S ] X ; [S: X :N ] insd:pY ; EOT; : ab ort:

[S ] del:pY [S ] X ; [S: X :N ] deld:pY ; EOT; : ab ort: 25

Thus, up date requests rep orted to the parent by are indistinguishable from

those derived directly provided commits, i.e., EOT ^:ab ort holds.

Parent transactions also p erform some b o okkeeping ab out committed and

ab orted subtransactions:

[S ] committed: X [S ] X ; [S: X :N ] EOT; : ab ort:

[S ] ab orted: X [S ] X ; [S: X :N ] EOT; ab ort:

The user can formulate application-sp eci c asp ects of transaction management,

e.g., that the parent transaction should ab ort, if the child ab orts:

ab ort X ; ab orted: X :

Serial Conjunction. It is sometimes convenient, esp ecially in the context of

pro cedures and nested transactions, to provide the user with a sp ecial connective

\ " denoting a serial version of conjunction. To this end, we de ne

A A B B

0 n 0 m

as a shorthand notation for the Statelog rule

[S +m] A ;:::;[S +m+n] A ; [S ] running;:::;[S +m+n] running

0 n

[S ] B ;:::;[S +m] B :

0 m

For example, a rule of the form A A B; where A and A are primitive

0 1 0 1

actions like ins:p, del:p or pro cedure calls, informally means: \if B is true, then

do A fol lowed by A ". Conversely, the rule A B B intuitively says: \if

0 1 0 1

B was previously true, and B holds now, then do A".

0 1

5.6 Examples

Example 5 Hyp othetical Up dates In order to implement ahyp othetical

deletion of an employee, we can use the rule

del:empE,Sal,D ins:empE,Sal,D hyp del empE, empE,Sal,D.

del empE o ccurs, employee E is removed from the database and im- When hyp

mediately inserted afterwards. If wewant to determine if E is an \indisp ensable"

employee, i.e., one whose deletion would result in an unp opulated department,

we can use the rule:

ins:indisp ensableE hyp del empE, empE,Sal,D :emp , ,D.

The hierarchical transaction mo del allows a exible treatmentofseveral inter-

esting features of databases, like the following:

The symbol \ " is b orrowed from [BK94 ], where it denotes a similar connective. 26

Static integrity constraints can be implemented by ab orting transactions

Example 6.

Checking the admissibility of changes and blo cking inadmissible ones: for

any fact px that should be guaranteed, derive ins:px . Every request to

delete it causes an inconsistency.

Ephemeral up dates: every transaction can try some up dates, check their

results and decide whether it should commit or ab ort Example 6.

Hyp othetical up dates: every transaction can work on relations which are

deleted b efore committing without having any e ect at commit-time. By

this it can create a hyp othetical scenario, check the outcome and rep ort the

consequences. This can b e used to evaluate several alternatives in parallel.

Finally,we are suciently equipp ed to revisit Example 4 in the extended frame-

work. Observe that the problems of the at approach mentioned at the b eginning

of Section 5 are resolved here:

Example 6 To Hire or Not to Hire, Cont'd

We sp ecify the hire and checksal transactions by pro cedures:

pro c main fhireE,Sal,D hire if p ossibleE,Sal,Dg.

pro c hireE,Sal,D fins:empE,Sal,D checksalD BOT;

ab ortab orted:checksalDg.

pro c checksalD fab ortavgD,AvgSal>50000g.

Whenever hire if p ossible o ccurs, a subtransaction hire::: is initiated. At the

b eginning of transaction and only then, hire adds the new employee followed

by a call to checksal. If checksal ab orts then hire also ab orts, resulting in an

unchanged database. Otherwise hire commits and the insertion is realized. The

following signatures are de ned:

edb R=fempg; R=fins:emp; del:empg;

prot R=finsd:emp; deld:empg; R=fmain; hire; checksalg;

ctl R=fBOT; running; EOT; ab ort; ab orted:checksal; ab orted:hireg:

Figure 6 depicts the state space which is created when hirejohn,60000,d1 is

called and eventually ab orted, since the average after the hyp othetical up date

exceeds 50000.

Frames are represented by shadowed b oxes, states are represented by ordinary

boxes. In all states, the upp er entry denotes the state term, the data b elow the

rst horizontal line are facts which are derived by frame rules or lo cal rules, and

the data b elow the second line if it exists are facts which are derived from

results of subtransactions.

Example 7 The Christmas-Problem

Consider a relation empE, BirthDay, Sal with the obvious meaning. We want

to implement the following, informally given pro cedure: Every employee shal l be

given a salary raise by 5 at her birthday; on Christmas every employee shal l

get an extra $1000. This is accomplished in at Statelog as follows [LHL95]: 27

[":n]

hirejohn,60000,d1, running

[":n1] [":n+1]

ab orted:hirejohn,60000,d1

["]

[":n.hirejohn,60000,d1.1]

[":n.hirejohn,60000,d1.0]

emp john,60000,d1, insd:emp john,60000,d1,

BOT,

checksald1

ins:empjohn,60000,d1 checksald1,

ins:empjohn,60000,d1, running.

ab orted:checksald1, ab ort, EOT

[":n:hirejohn,60000,d1]

[":n.hirejohn,60000,d1.0.

checksald1.0]

BOT, avgd1,50001, ab ort, EOT

[":n:hirejohn,60000,d1.0.checksald1 ]

Fig. 6. Frames and Database States

[S +1] mo d:empE,Bday,Sal/Sal1

[S ] daily, dateDay, Day=Bday, empE,Bday,Sal, Sal1:= Sal*1.05.

[S +1] mo d:empE,Bday,Sal/Sal1

[S ] daily, dateDay, xmasDay, empE,Bday,Sal, Sal1:= Sal+1000.

These rules work ne unless there is some employee whose birthday is on Christ-

mas: Then two inconsistent mo dify-requests are generated, and the subsequent

state is not well-de ned. In a at mo del, the problem could b e solved by complete

case splitting or by a rule using three states however, this raises the problem

that the intermediate state should not trigger other rules. In the structured

mo del, the sequential comp osition inc xmas inc bday can b e used by the top-

level transaction incsal to sp ecify the order of execution:

pro c main fincsalDay daily, dateDayg.

pro c incsalDay finc xmasDay inc bdayDay BOTg.

pro c inc xmasDay fmo d:empE,Bday,Sal/Sal1

BOT,xmasDay,empE,Bday,Sal, Sal1:= Sal+1000g.

pro c inc bdayDay fmo d:empE,Bday,Sal/Sal1

BOT, Day=Bday, empE,Bday,Sal, Sal1:= Sal*1.05g.

xmasDay inc bdayDay were replaced by the simultaneous conjunction If inc

inc xmasDay , inc bdayDay, then two con icting requests would b e derived and

the transaction would be ab orted automatically by the corresp onding system-

de ned rules.

Using the nested transaction mo del, di erent rule schemata for mo deling

certain coupling mo des, event consumption p olicies, and trigger ring p olicies

can b e de ned, thereby providing a concise, formal sp eci cation of these features. 28

Example 8 Control Features Instead-triggers can b e mo deled by replacing

a pro cedure call x by another call x : when a call x is derived, it is

discarded immediately, and the call x is derived instead. The pro cedure rules

from Section 5.5 are mo di ed, for every 2 R, as follows:

[S: X :0] BOT [S ] X ; : discard: X :

[S: X :0] pY [S ] pY ;X ; : discard: X :

Now the instead-trigger \ x instead of x " is expressed by the lo cal rule

X ; discard:X X :

Before- and after-triggers can be mo deled as sp ecialized instances of instead-

triggers based on serial conjunction : Consider a trigger of the form \before x

do x ". This can b e accomplised by the following rules contains the same

rules as :

X ; discard:X x :

X f X X BOTg: pro c

Other control features which can be handled include di erent event consump-

tion mo des see Section 4.4 and deferred instead of immediate coupling cf.

Section 5.5.

5.7 Op erational Semantics

The ab ove rule system de nes a partial order on state identi ers: Within a

frame, [f:n] [f:m] if n

2 R and all k 2 IN. With the additional requirement on user-de ned rules

that there are no negative dep endencies from relations of R to any other

relation of the same state, can serve as a base for computing the individual

database states as follows:

1. compute [f:i]edb R [ prot R from [f:i{1] edb R [ R [ prot R,

2. compute [f:i]idb R [ R [ R,

3. compute f[f :i: x:IN ] j [f:i] x holdsg recursively,

4. add the resulting requests from

f[f :i: x:n ] prot R j [f:i] x and [f :i: x :n] EOT holdsg to [f:i] R,

5. extend [f:i]idb R [ R [ R, based on the additions to [f:i] R from

step 4 \add-only", since these relations do not dep end negatively on R,

6. compute f[f :i: x:IN ] j [f:i] x has b een derived in the previous stepg,

7. iterate steps 4{6 until a xp oint is reached,

8. if not [f:i] EOT, pro ceed with step 1 for [i+1].

Note that with the ab oveschema, [f:i]edb R [ prot R are computed once in

the rst step. Therefore, the database in the initial state [f :i: x :0] of subframes

is identical for all subframes [f :i: x ] , indep endent from the iteration step in

which the pro cedure call has b een derived. 29

R R

Fig. 7. Hierarchical Kripke Structure

6 Kripke-Style Semantics

A conceptual mo del for Statelog with nested transactions is established using a

Kripke-style semantics, thereby providing states as \ rst-class citizens" of the

logical framework. State identi ers are mapp ed to states of a Kripke structure

which formalizes the relationships b etween individual states in terms of accessi-

bility relations. The Kripke semantics yields an abstract and natural mo del of

the hierarchical state space and can serve as a basis for the sp eci cation and

veri cation of prop erties of a database system. We show that the rules given in

the previous section where states are \rei ed", i.e., enco ded into the language

are correct wrt. the abstract Kripke semantics.

De nition 2 Statelog Kripke Structure A Statelog Kripke structure over

a given Statelog signature R is a tuple K =G ; U ; R; Q; S ; M; P , cf. Figure 7

where

G is a set of states,

U is the universe,

R GG is an accessibility relation mo deling the temp oral successor relation.

Q; S G R U G are two lab eled accessibility relations b etween states

representing the pro cedure-call and -return relation, resp ectively.

M is a function which maps every state to a rst-order interpretation over R

with universe U ,

P is a function which maps every g 2G to a set of lo cal rules the rules visible

in g .

Here, the Statelog Kripke frame G ; R; Q; S mo dels the relationships b etween

states and frames: Every computation path g ;g ;::: in a Statelog Kripke struc-

1 2

ture s.t. Rg ;g for all i corresp onds to a frame in the hierarchical state space

i i+1

note that Rg; g denotes that a subtransaction has reached a xp oint, i.e., then,

Mg j= EOT holds. Q denotes the frame-subframe-relation, i.e., Qg; x ;g

means that the rst state of the subtransaction induced by a call of pro cedure

0 0 0

with arguments x is g . S g ;x ;g means that g is the nal state of the

subtransaction induced by a call of pro cedure with arguments x in g .Thus,

results of subtransactions are communicated along S . 30

The following characterization covers the intended semantics of the Statelog

frame rules:

De nition 3 A Statelog Kripke structure K = G ; U ; R; Q; S ; M; P over a

signature R is a model of a Statelog program P over R and an initial database

D if

U is the active domain of P and D .

There is a g 2G s.t. Mg j = D , and Mg j = ;, and there

0 0 0

edb R prot R

is no g s.t. Qg; ;g orRg; g existence of an initial state.

0 0

External events are only mapp ed to the initial state of transactions on the

6= ; only if R g ;g and g = g highest hierarchical level, i.e., Mg j

0 0

or Mg j= EOT.

The relation R mo dels the temp oral successor relation, i.e.,

Rg; h Ph=P g

and the following relationship between edb R and R in g and edb R

and prot Rinh holds:

Rg; h for all p 2 edb R:

Mhp=Mg p [Mg ins:p nMg del:p and

Mhinsd:p=Mg insd:p [Mg ins:p nMg del:p and

Mhdeld:p=Mg deld:p [Mg del:p nMg ins:p

0 0

and R is total, i.e., for every g 2G there is a g 2G s.t. Rg; g .

Q mo dels the subtransaction calls: for all g 2G, 2 R, u 2U :

Mg j= u , there is an h s.t. Qg; u;h ;

and Qg; u;h implies that Mh j= BOT, Mhj = Mg j ,

edb R edb R

Mhj = ;, and

prot R

P h=P [fp::: B 2Pg j p 2 idb Rg :

S mo dels the return-from-subtransaction relation:

0 0 !

for all g; g ;h 2G, 2 R, u 2U :

0 0 0 0 0

Qg; u;g and R g ;h and Mh j= EOT , S h ;u;g :

For every g 2G,

Mg =M Mg j [Cg

P g

edb R[prot R[ R

where C g is the set of requests which are contributed to g by subtransac-

tions and communicated along S , given as

0 ! 0

C g ins:p:=fu j there are g 2G; 2 R; v 2U s.t. S g ;v ;g and

0 0

Mg j= : ab ort and u 2Mg insd:pg

0 ! 0

C g del:p:=fu j there are g 2G; 2 R; v 2U s.t. S g ;v ;g and

0 0

Mg j= : ab ort andu 2Mg deld:pg :

as usual, R denotes the transitive closure of R. 31

Prop osition 3 In every Statelog Kripke structure which is a model of a Statelog

program P , the fol lowing holds:

The temporal successor relation R is deterministic modulo external events:

for al l g ; h; h 2G:

0 0

Rg; h and Rg; h Mhj = Mh j :

Rn R Rn R

For every g 2 G in a non-top level frame i.e., on a level where there are

no external events s.t. Mg j= BOT, there is a unique computation path

g ;g ;:::;g with g j= : EOT for al l i

0 1 n i n

for every Statelogprogram P , database D , and sequence E ; E ; E ;::: of sets

0 1 2

of external events, there is a unique Kripke model of P with an initial state

Mg = M D[E and a top-level computation path g ;g ;::: s.t.

0 main 0 0 1

Mg j= EOT , i 2 ff ;f ;:::g f denotes the i-th nal state; see

i 1 2 i

j= E . Section 4.1; in this case: Mg

i 2 f

S can also b e regarded as a relation describing the e ects of subtransactions:

For 2 R and u 2U ,

ug :=h 2G s.t. h; g 2S u

is the result of executing u in state g . The relationship b etween Mg and

M ug is imp ortant for expressing correctness prop erties of subtransac-

tions. With this, C g can be characterized in terms of the e ects of the sub-

transactions which are issued in g :

C g ins: p=fu j there is a 2 R; v 2U s.t.v 2Mg and

M y g j= : ab ort and u 2M y g insd :pg ;

C g del:p=fu j there is a 2 R; v 2U s.t.v 2Mg and

M y g j= : ab ort and u 2M y g deld:pg :

Equipp ed with a notion of states, computation sequences, and subtransactions,

the semantics of the individual subsets of a Statelog signature cf. Section 5.2

can b e describ ed in terms of state transitions and subtransactions:

Theorem 4 Adequacy Statelog Kripke structures areanadequate model of

the intended semantics of nested transactions based on the elementary actions

ins and del:

R models the temporal successor relation:

{ edb -relations are changed exactly via requests: for al l p 2 edb R, g; h 2

G :ifg; h 2R, then

Mhp=Mg p nMg del:p [Mg ins:p :

{ In al l states, the protocol relations contain the non-revoked changes of the

corresponding subtransactions: For al l g; h 2QR and al l p 2 edb R:

Mhp=Mg p [Mhinsd:p nMhdeld:p : 32

Q models the subtransaction cal ls:

{ In the initial states of subtransactions, the edb is the same as in the

cal ling state and the protocol relations procedure know ledge are empty.

{ The de nition of the IDB in a subtransaction contains the de nition of

the IDB in the cal ling transaction.

S models the return-from-subtransaction relation:

{ For al l g; h 2G,if S h; ;g and Mh 6j= ab ort, then for al l p 2 edb R:

Mg ins:p Mhinsd:p and Mg del:p Mhdeld:p :

Internal semantics of states Perfect model of P g :

{ Insert/delete requests are derived by user-de ned rules or contributedby

subtransactions.

{ IDB and subtransaction cal ls are derived by user-de ned rules.

The declarative semantics of the p erfect mo del of a Statelog program and the

op erational semantics given in Section 5.7 for computing a Statelog mo del state-

by-state coincide with the presented Kripke semantics:

Theorem 5 Equivalence Fix a Statelog program P , an initial database D ,

and a sequence E = E ; E ;::: of sets of external events. For every Statelog

0 1

Kripke structure K = G ; U ; R; Q; S ; M; P which is a model of P , there is a

partial mapping : S !G such that:

dom =f[s] j M j=[s] running _ EOTg, i.e., the \used" states.

P [D [E

For al l literals L over R, M s j= L i M j=[s] L.

P [D [E

For every n 2 IN ; [f:n] 2 dom : P [f:n]= P [f ].

0 2

7 Summary and Conclusion

Active rules extend the traditional passive database technology and are a p ow-

erful programming paradigm with a large numb er of application areas. While an

increasing numb er of systems b ecomes available and active rule programming is

carried out in real world applications, theoretical foundations of active rules are

still rare. In the rst part of the pap er, wehaveintro duced the basics of active

rules and related them to pro duction rules and deductive rules, resp ectively. Af-

ter discussing a numb er of formal approaches to active rules, wehave elab orated

on a state-oriented logical framework whichintegrates active and deductive rules.

The underlying core language Statelog precisely sp eci es the meaning of a set

of active rules and allows to investigate fundamental prop erties like termination

and expressive power [LLM98,Lud98]. Although the basic execution mo del of

at Statelog is relatively straightforward and corresp onds to at transactions

dealing only with immediate and deferred coupling on the statement-level, it

captures many essential features of active rules including comp osite events. It

can be shown [Lud98] that some features like chronicle contexts of comp osite

events cannot be expressed directly, but require certain extensions like event 33

queues or timestamping, as presented in [MZ95]. While the prop osed frame-

work enjoys the desirable feature of a deterministic semantics, it is sometimes

useful to consider nondeterministic extensions, in particular to mo del existing

nondeterministic systems. A p ossible extension is to use the choice construct of

[SZ90] which can be integrated seamlessly with a state-oriented language like

Statelog or XY-Datalog see e.g., [GGSZ97]. Finally, wehave shown how the

at transaction mo del can be extended to handle nested transactions using a

hierarchical state space. In this extended framework, low-level pro cedural con-

structs like before- and instead-triggers can b e formalized in an intuitiveway. Fi-

nally, a mo del-theoretic semantics based on lab eled Kripke-structures has b een

develop ed for Statelog with nested transactions, which provides a conceptual,

implementation-indep endent mo del for active rule b ehavior.

References

[ABW88] K. R. Apt, H. Blair, and A. Walker. Towards a Theory of Declarative

Knowledge. In J. Minker, editor, Foundations of Deductive Databases and

Logic Programming, pp. 89{148. Morgan Kaufmann, 1988.

[AHV95] S. Abiteb oul, R. Hull, and V. Vianu. Foundations of Databases. Addison

Wesley, 1995.

[AS91] S. Abiteb oul and E. Simon. Fundamental Prop erties of Deterministic and

Nondeterministic Extensions of Datalog. Theoretical Computer Science,

781:137{158, 1991.

[AV91] S. Abiteb oul and V. Vianu. Datalog Extensions for Database Queries and

Up dates. Journal of Computer and System Sciences, 431:62{124, 1991.

[AWH95] A. Aiken, J. Widom, and J. M. Hellerstein. Static Analysis Techniques for

Predicting the Behavior of Active Database Rules. ACM Transactions on

Database Systems TODS, 201:3{41, March 1995.

[BCP95] E. Baralis, S. Ceri, and S. Parab oschi. Improving Rule Analysis by Means

of Triggering and Activation Graphs. In Sellis [Sel95 ], pp. 165{181.

[BFKM85] L. Brownston, R. Farrel, E. Kant, and N. Martin. Programming Expert

Systems in OPS5: An Introduction to Rule-BasedProgramming. Addison-

Wesley, 1985.

[BFP 95] M. L. Barja, A. A. A. Fernandes, N. W. Paton, M. H. Williams, A. Dinn, and

A. I. Ab delmoty. Design and implementation of ROCK&ROLL: a deduc-

tive ob ject-oriented database system. Information Systems, 203:185{211,

1995.

[BGP97] C. Baral, M. Gelfond, and A. Provetti. Representing Actions: Laws, Obser-

vations and Hyp otheses. Journal of Logic Programming, 311{3:201{243,

1997.

[BH95] M. Berndtsson and J. Hansson, editors. 1st Intl. Workshop on Active and

Real-Time Database Systems ARTDB,Workshops in Computing, Skovde,

1995. Springer.

[BK94] A. J. Bonner and M. Kifer. An Overview of Transaction Logic. Theoretical

Computer Science, 1332:205{265, 1994.

[BL96] C. Baral and J. Lob o. Formal Characterization of Active Databases. In

Pedreschi and Zaniolo [PZ96 ], pp. 175{195. 34

[BLT97] C. Baral, J. Lob o, and G. Tra jcevski. Formal Characterization of Active

Databases: Part II. In F. Bry, K. Ramamohanarao, and R. Ramakrish-

nan, editors, Intl. ConferenceonDeductive and Object-Oriented Databases

DOOD,numb er 1341 in LNCS, pp. 247{264, Montreux, Switzerland, 1997.

Springer.

[BW94] E. Baralis and J. Widom. An Algebraic Approach to Rule Analysis in

Exp ert Database Systems. In Intl. ConferenceonVery Large Data Bases,

pp. 475{486, Santiago, Chile, 1994.

[CFPT96] S. Ceri, P.Fraternali, S. Parab oschi, and L. Tanca. Active Rule Manage-

ment in Chimera. In Widom and Ceri [WC96a ], chapter 6, pp. 151{176.

[Cha92] S. Chakravarthy, editor. Bul letin of the Technical Committee on Data En-

gineering: Special Issue on Active Databases,volume 151{4. IEEE Com-

puter So ciety, 1992.

[Che95] W. Chen. Programming with Logical Queries, Bulk Up dates and Hyp othet-

ical Reasoning. In B. Thalheim, editor, Workshop Semantics in Databases,

Prague, January 1995. Technische Universitat Cottbus.

[Cho95a] J. Chomicki. Depth-Bounded Bottom-Up Evaluation of Logic Programs.

Journal of Logic Programming, 251:1{31, Octob er 1995.

[Cho95b] J. Chomicki. Ecient Checking of Temp oral Integrity Constraints Us-

ing Bounded History Enco ding. ACM Transactions on Database Systems

TODS, 202:149{186, 1995.

[CKAK94] S. Chakravarthy, V. Krishnaprasad, E. Anwar, and S.-K. Kim. Comp osite

Events for Active Databases: Semantics, Contexts and Detection. In J. B.

Bo cca, M. Jarke, and C. Zaniolo, editors, Intl. Conference on Very Large

Data Bases, pp. 606{617, Santiago de Chile, 1994.

[CM94] S. Chakravarthy and D. Mishra. Sno op: An ExpressiveEvent Sp eci cation

Language for Active Databases. Data & Know ledge Engineering, 14:1{26,

1994.

[CPM96] R. Co chrane, H. Pirahesh, and N. Mattos. Integrating Triggers and Declar-

ative Constraints in SQL Database Sytems. In Intl. Conference on Very

Large Data Bases, pp. 567{578, Mumbai Bombay, India, 1996.

[Day95] U. Dayal. Ten Years of Activity in Active Database Systems: What HaveWe

Accomplished? In M. Berndtsson and J. Hansson, editors, 1st Intl. Work-

shop on Active and Real-Time Database Systems ARTDB,Workshops in

Computing, pp. 3{22, Skovde, 1995. Springer.

[DGG95] K. R. Dittrich, S. Gatziu, and A. Gepp ert. The Active Database Manage-

ment System Manifesto: A Rulebase of ADBMS Features. In Sellis [Sel95 ],

pp. 3{20.

[DHW95] U. Dayal, E. Hanson, and J. Widom. Active Database Systems. In W. Kim,

editor, Modern Database Systems: The Object Model, Interoperability, and

Beyond,chapter 21, pp. 434{456. ACM Press, 1995.

[FT95] P.Fraternali and L. Tanca. A Structured Approach for the De nition of the

Semantics of Active Databases. ACM Transactions on Database Systems,

204:414{471, 1995.

[FWP97] A. A. A. Fernandes, M. H. Williams, and N. W. Paton. A Logic-Based In-

tegration of Active and Deductive Databases. New Generation Computing,

152:205{244, 1997.

[GB97] A. Gepp ert and M. Berndtsson, editors. Proc. of the 3nd Intl. Workshop on

Rules in Database Systems RIDS,numb er 1312 in LNCS, Skovde, Sweden,

1997. 35

[GGSZ97] F. Giannotti, S. Greco, D. Sacc a, and C. Zaniolo. Programming with Non-

Determinism in Deductive Databases. Annals of Mathematics and Arti cial

Intel ligence, 19I{I I:97{125, 1997.

[GL88] M. Gelfond and V. Lifschitz. The Stable Mo del Semantics for Logic Pro-

gramming. In R. Kowalski and K. Bowen, editors, Intl. ConferenceonLogic

Programming ICLP, pp. 1070{1080, 1988.

[GL93] M. Gelfond and V. Lifschitz. Representing Action and Change by Logic

Programs. Journal of Logic Programming, 17:301{321, 1993.

[GMS92] G. Gottlob, G. Mo erkotte, and V. S. Subrahmanian. The PARK Semantics

for Active Rules. In P.M. G. Ap ers, M. Bouzeghoub, and G. Gardarin,

editors, Intl. Conference on Extending Database Technology,numb er 1057

in LNCS, Avignon, France, 1992. Springer.

[ISO97] ISO-ANSI Working draft. SQL3, 1997. ISO/IEC JTC 1/SC 21/WG3.

[KC95] S.-K. Kim and S. Chakravarthy. A Con uent Rule Execution Mo del for Ac-

tive Databases. Technical Rep ort UF-CIS-TR-95-032, University of Florida,

1995. http://www.cis.u .edu/~sharma.

[KdMS90] G. Kiernan, C. de Maindreville, and E. Simon. Making Deductive Database

a Practical Technology: a step forward. In ACM Intl. Conference on Man-

agement of Data SIGMOD, pp. 237{246, 1990.

[KLS92] M. Kramer, G. Lausen, and G. Saake. Up dates in a Rule-Based Language

for Ob jects. In Intl. Conference on Very Large Data Bases VLDB, pp.

251{262, Vancouver, 1992.

[Kow92] R. A. Kowalski. Database Up dates in the Event Calculus. Journal of Logic

Programming, 121&2:121{146, 1992.

[KRS95] D. B. Kemp, K. Ramamohanarao, and P. J. Stuckey. ELS Programs and

the EcientEvaluation of Non-Strati ed Programs byTransformation to

ELS. In Ling et al. [LMV95 ], pp. 91{108.

[KU96] A. P. Karadimce and S. D. Urban. Re ned Triggering Graphs: A Logic-

Based Approach to Termination Analysis in an Active Ob ject-oriented

Database. In 12th International Conference on Data Engineering ICDE,

pp. 384{391, 1996.

[LHL95] B. Ludascher, U. Hamann, and G. Lausen. A Logical Framework for Active

Rules. In Proc. 7th Intl. Conference on Management of Data COMAD,

pp. 221{238, Pune, India, 1995. Tata McGraw-Hill.

[LLM98] G. Lausen, B. Ludascher, and W. May. On Logical Foundations of Active

Databases. In J. Chomicki and G. Saake, editors, Logics for Databases and

Information Systems,chapter 12, pp. 389{422. Kluwer Academic Publish-

ers, 1998.

[LML96] B. Ludascher, W. May, and G. Lausen. Nested Transactions in a Logical

Language for Active Rules. In Pedreschi and Zaniolo [PZ96 ], pp. 196{222.

[LMV95] T. W. Ling, A. O. Mendelzon, and L. Vieille, editors. Intl. Conferenceon

Deductive and Object-Oriented Databases DOOD,numb er 1013 in LNCS,

Singap ore, 1995. Springer.

[LS87] U. W. Lip eck and G. Saake. Monitoring Dynamic Integrity Constraints

Based on Temp oral Logic. Information Systems, pp. 255{269, 1987.

[Lud98] B. Ludascher. Integration of Active and Deductive Database Rules. PhD the-

sis, Institut fur Informatik, Universitat Freiburg, 1998. in x-Verlag, Sankt

Augustin, 1998, ISBN 3-89601-445-5.

[Min96] J. Minker. Logic and Databases: a 20 Year Retrosp ective. In Pedreschi and

Zaniolo [PZ96 ], pp. 3{57. 36

[MW88] S. Manchanda and D. S. Warren. A Logic-Based Language for Database

Up dates. In J. Minker, editor, Foundations of Deductive Databases and

Logic Programming, pp. 363{394. Morgan-Kaufmann, Los Altos, CA, 1988.

[MZ95] I. Motakis and C. Zaniolo. Comp osite Temp oral Events in Active Database

Rules: A Logic-Oriented Approach. In Ling et al. [LMV95 ], pp. 19{37.

[MZ97] I. Motakis and C. Zaniolo. Temp oral Aggregation in Active Database Rules.

In ACM Intl. Conference on Management of Data SIGMOD, pp. 440{451,

Tucson, Arizona, 1997.

[NT89] S. Naqvi and S. Tsur. ALogical Language for Data and Know ledge Bases.

Computer Science Press, New York, 1989.

[PCFW95] N. W. Paton, J. Campin, A. A. A. Fernandes, and M. H. Williams. Formal

Sp eci cation of Active Database Functionality: A Survey. In Sellis [Sel95 ],

pp. 21{37.

[PDW 93] N. W. Paton, O. D az, M. H. Williams, J. Campin, A. Dinn, and A. Jaime.

Dimensions of Active Behaviour. In Paton and Williams [PW93 ], pp. 40{57.

[Prz88] T. C. Przymusinski. On the Declarative Semantics of Deductive Databases

and Logic Programs. In J. Minker, editor, Foundations of Deductive

Databases and Logic Programming, pp. 191{216. Morgan Kaufmann, 1988.

[PV95] P. Picouet and V. Vianu. Semantics and Expressiveness Issues in Ac-

tive Databases. In ACM Symposium on Principles of Database Systems

PODS, 1995.

[PV97] P. Picouet and V. Vianu. Expressiveness and Complexity of Active

Databases. In F. Afrati and P. Kolaitis, editors, 6th Intl. Conference on

Database Theory ICDT, number 1186 in LNCS, pp. 155{172, Delphi,

Greece, 1997. Springer.

[PW93] N. W. Paton and M. H. Williams, editors. 1st Intl. Workshop on Rules in

Database Systems RIDS,Workshops in Computing, Edinburgh, Scotland,

1993. Springer.

[PZ96] D. Pedreschi and C. Zaniolo, editors. Intl. Workshop on Logic in Databases

LID,numb er 1154 in LNCS, San Miniato, Italy, 1996. Springer.

[RH94] K. Ramamohanarao and J. Harland. An Intro duction to Deductive

Database Languages and Systems. The VLDB Journal, 32:107{122, April

1994.

[Sel95] T. K. Sellis, editor. 2nd Intl. Workshop on Rules in Database Systems

RIDS,numb er 985 in LNCS, Athens, Greece, 1995. Springer.

[Sin95] M. P. Singh. Semantical Considerations on Work ows: An Algebra for

Intertask Dep endencies. In Intl. Workshop on Database Programming Lan-

guages, electronic Workshops in Computing, Gubbio, Italy, 1995. Springer.

[SK96] E. Simon and J. Kiernan. The A-RDL System. In Widom and Ceri [WC96a ],

chapter 5, pp. 111{149.

[SP97] P. Sampaio and N. Paton. Deductive Ob ject-Oriented Database Systems:

A Survey. In Gepp ert and Berndtsson [GB97 ], pp. 1{19.

[SSW94] K. F. Sagonas, T. Swift, and D. S. Warren. XSB as an Ecient Deduc-

tive Database Engin. In ACM Intl. Conference on Management of Data

SIGMOD, pp. 442{453, 1994.

[SZ90] S. Sacc a and C. Zaniolo. Stable Mo dels and Non-Determinism in Logic

Programs with Negation. In Proc. of the 9th ACM Symposium on Principles

of Database Systems, pp. 205{217, 1990.

[VG89] A. Van Gelder. The Alternating Fixp oint of Logic Programs with Negation.

In ACM Symposium on Principles of Database Systems PODS, pp. 1{10,

1989. 37

[Via97] V. Vianu. Rule-Based Languages. Annals of Mathematics and Arti cial

Intel ligence, 19I{I I:215{259, 1997.

[WC94] J. Widom and S. Chakravarthy, editors. 4th Intl. Workshop on Research

Issues in Data Engineering RIDE. IEEE Computer So ciety Press, 1994.

[WC96a] J. Widom and S. Ceri, editors. Active Database Systems: Triggers and Rules

for Advanced Database Processing. Morgan Kaufmann, 1996.

[WC96b] J. Widom and S. Ceri. Intro duction to Active Database Systems. In Active

Database Systems: Triggers and Rules for Advanced Database Processing

[WC96a ], chapter 1, pp. 1{41.

[WF97] C.-A. Wichert and B. Freitag. Capturing Database Dynamics by Deferred

Up dates. In Intl. ConferenceonLogic Programming ICLP, Leuven, Bel-

gium, 1997. MIT Press.

[Wid93] J. Widom. Deductive and Active Databases: TwoParadigms or Ends of a

Sp ectrum. In Paton and Williams [PW93 ].

[Zan93] C. Zaniolo. A Uni ed Semantics for Active and Deductive Databases. In

Paton and Williams [PW93 ], pp. 271{287.

[Zan95] C. Zaniolo. Active Database Rules with Transaction Conscious Stable

Mo del Semantics. In Ling et al. [LMV95 ], pp. 55{72.

[ZH90] Y. Zhou and M. Hsu. A Theory for Rule Triggering Systems. In Intl. Conf.

on Extending Database Technology, pp. 407{421, 1990. 38