%%
\documentclass[11pt]{article}
%%
\usepackage{amssymb,xspace,latexsym}


\setlength{\textwidth}{17.0cm}                  % increase line length
\setlength{\textheight}{22.0cm}
\setlength{\oddsidemargin}{-.1in}               % change page offset
\setlength{\topmargin}{-.7in}                   % change offset from page top

\addtolength{\parskip}{.8mm}                     % increase paragraph spacing
\addtolength{\baselineskip}{+.03\baselineskip}   % increase line spacing
\addtolength{\topsep}{-.4\topsep}              % decr space betw items & text
\addtolength{\parsep}{-.4\parsep}              % decrease spacing betw items


\newcommand{\sg}{\smallskip\\}
\newcommand{\mg}{\medskip\\}
\newcommand{\bg}{\bigskip\\}
\newcommand{\wbreak}{\linebreak[0]}     % nonmandatory break
\newcommand{\impl}{\mbox{\Large $\; {\bf \leftarrow} \;$}}  % implication sign
\newcommand{\fimpl}{\mbox{\Large $\; {\bf \rightarrow} \;$}}  % fwd impl sign
\newcommand{\biimpl}{\mbox{\Large $\; {\bf \leftrightarrow} \;$}}  % iff  sign
\newcommand{\conj}{{\,\, \& \,}}        % conjunction -- in examples
\newcommand{\query}{\, ?\! - \, }
%%
\newcommand{\tab}{\hspace*{4em}}
\newcommand{\ind}{\hspace*{2em}}
%%
\newcommand{\fd}{\rightarrow}
\newcommand{\ra}{\rightarrow}
\newcommand{\la}{\leftarrow}
\newcommand{\lra}{\leftrightarrow}
%%
\newcommand{\Fd}{\Rightarrow}
\newcommand{\Ra}{\Rightarrow}
\newcommand{\La}{\Leftarrow}
%%
\newcommand{\mvd}{\rightarrow\!\!\!\!\rightarrow}
\newcommand{\Mvd}{\Rightarrow\!\!\!\!\Rightarrow}

\newcommand{\llparen}{\mbox{\large (\,}}
\newcommand{\lrparen}{\mbox{\large \,)}}
%%
%%
\newtheorem{dummylemma}{BLA}[section]
\newtheorem{proposition}[dummylemma]{Proposition}%[section]
\newtheorem{theorem}[dummylemma]{Theorem}%[section]
\newtheorem{lemma}[dummylemma]{Lemma}%[section]
\newtheorem{corollary}[dummylemma]{Corollary}%[section]
\newtheorem{ExamplE}[dummylemma]{\em Example}%[section]
\newtheorem{claim}[dummylemma]{Claim}%[section]
\newtheorem{algorithm}[dummylemma]{Algorithm}%[section]
\newtheorem{DefinitioN}[dummylemma]{\em Definition}%[section]
%%
%%
\newenvironment{romanEnum}
                {\begin{list}
                    {(\roman{enumi})}           % form of label
                    {\usecounter{enumi}         % set margins, counter
                     \setlength{\rightmargin}{\leftmargin}
                     \setlength{\labelwidth}{7.5mm}
                    }
                }{\end{list}}
%%
\newenvironment{example}[1]
                {\begin{ExamplE}[#1] \rm}{\hfill $\Box$ \end{ExamplE}}
\newenvironment{definition}[1]
                {\begin{DefinitioN}[#1]\rm}{\hfill $\Box$\end{DefinitioN}}
\newenvironment{proof}{{\noindent\it Proof:}}{$\Box$ \bigskip}

\newcommand{\canonic}[1]{\bM_{#1}}
\newenvironment{mathlines0}[1]{\begin{center}\begin{math}\begin{array}{#1}}{\end{array}\end{math}\end{center}}

\newcommand{\finfers}{\infers_f}
\newcommand{\rinfers}{\infers_r}
\newcommand{\xinfers}{\infers_x}
%%

%\newcommand{\proof}[1]{{\noindent \hspace*{0.5cm} \bf Proof:~~}#1
%                                        \hspace{1cm} \medskip$\Box$\hfill}
\newcommand{\Example}[1]{{\begin{ExamplE}\rm #1
                                        \hspace{1cm} $\Box$\end{ExamplE}}}
\newcommand{\Definition}[1]{{\begin{DefinitioN}{\rm #1}
                                        \hspace{1cm} $\Box$\end{DefinitioN}}}
\newcommand{\Algorithm}[1]{{\begin{algorithm}\tt #1 \end{algorithm}}}

\newcommand{\addreferences}{\addcontentsline{toc}{section}{References}}

%%
\newcommand{\eq}{\doteq}
%%
\newcommand{\myfrac}[2]{\begin{array}{l} #1 \\ \hline #2 \end{array}}
\newcommand{\bA}{{\bf A}}
\newcommand{\bB}{{\bf B}}
\newcommand{\bC}{{\bf C}}
\newcommand{\bD}{{\bf D}}
\newcommand{\bE}{{\bf E}}
\newcommand{\bF}{{\bf F}}
\newcommand{\bG}{{\bf G}}
\newcommand{\bH}{{\bf H}}
\newcommand{\bI}{{\bf I}}
\newcommand{\bJ}{{\bf J}}
\newcommand{\bK}{{\bf K}}
\newcommand{\bL}{{\bf L}}
\newcommand{\bM}{{\bf M}}
\newcommand{\bN}{{\bf N}}
\newcommand{\bO}{{\bf O}}
\newcommand{\bP}{{\bf P}}
\newcommand{\bQ}{{\bf Q}}
\newcommand{\bR}{{\bf R}}
\newcommand{\bS}{{\bf S}}
\newcommand{\bT}{{\bf T}}
\newcommand{\bU}{{\bf U}}
\newcommand{\bV}{{\bf V}}
\newcommand{\bW}{{\bf W}}
\newcommand{\bX}{{\bf X}}
\newcommand{\bY}{{\bf Y}}
\newcommand{\bZ}{{\bf Z}}
%%
%%
\newcommand{\widevec}[1]{\stackrel{\longrightarrow}{#1}}
\newcommand{\eqdef}{\,\stackrel{\rm def}{=}\,}
%%
\newcommand{\nmmodels}{\mid\!\!\,\approx}       % nonmonotonic entailment
\newcommand{\nmvdash}{\mid\!\!\,approx}         % nonmonotonic proof
\newcommand{\tuple}[1]{\langle #1 \rangle}      % tuple: < ... >
\newcommand{\tup}[1]{\langle #1 \rangle}      % tuple: < ... >
%%
\newcommand{\cA}{{\cal A}}
\newcommand{\cB}{{\cal B}}
\newcommand{\cC}{{\cal C}}
\newcommand{\cD}{{\cal D}}
\newcommand{\cE}{{\cal E}}
\newcommand{\cF}{{\cal F}}
\newcommand{\cG}{{\cal G}}
\newcommand{\cH}{{\cal H}}
\newcommand{\cI}{{\cal I}}
\newcommand{\cJ}{{\cal J}}
\newcommand{\cK}{{\cal K}}
\newcommand{\cL}{{\cal L}}
\newcommand{\cM}{{\cal M}}
\newcommand{\cN}{{\cal N}}
\newcommand{\cO}{{\cal O}}
\newcommand{\cP}{{\cal P}}
\newcommand{\cQ}{{\cal Q}}
\newcommand{\cR}{{\cal R}}
\newcommand{\cS}{{\cal S}}
\newcommand{\cT}{{\cal T}}
\newcommand{\cU}{{\cal U}}
\newcommand{\cV}{{\cal V}}
\newcommand{\cW}{{\cal W}}
\newcommand{\cX}{{\cal X}}
\newcommand{\cY}{{\cal Y}}
\newcommand{\cZ}{{\cal Z}}

\newcommand{\dO}{\cO^d}
\newcommand{\tO}{\cO^t}
\newcommand{\doracle}{{\dO}}
\newcommand{\toracle}{{\tO}}

\newcommand{\HB}{{\cal HB}}

% L of T specific definitions

\newcommand{\union}{\cup}
\newcommand{\intersect}{\cap}
\newcommand{\ie}{{\it i.e.},\xspace}
\newcommand{\eg}{{\it e.g.},\xspace}
\newcommand{\ppath}{{\tt path}\xspace}
\newcommand{\state}{{\tt state}\xspace}
\newcommand{\aarc}{{\tt arc}\xspace}
\newcommand{\through}{{\it go\_thru}\xspace}
\newcommand{\prof}{{\it Prof}}
\newcommand{\crs}{{\it Crs}}
\newcommand{\go}{{\it goto}}
\newcommand{\at}{{\it at}}
\newcommand{\lifted}{{\it lifted}}
\newcommand{\aand}{\,\,\&\,}
\newcommand{\And}{\wedge}
\newcommand{\Or}{\vee}
\newcommand{\add}[1]{\mbox{\it $#1$.add}}
\newcommand{\rem}[1]{\mbox{\it $#1$.rem}}
\newcommand{\del}[1]{\mbox{\it $#1$.del}}
\newcommand{\ins}[1]{\mbox{\it $#1$.ins}}
\newcommand{\change}[1]{\mbox{\it $#1$.change}\xspace}
\newcommand{\empti}[1]{\mbox{\it $#1$.empty}}
\newcommand{\decr}[1]{\mbox{\it $#1$.decr}\xspace}
\newcommand{\incr}[1]{\mbox{\it $#1$.incr}\xspace}
\newcommand{\achieve}[1]{\mbox{\it $#1$.achieve}\xspace}
\newcommand{\lock}[1]{\mbox{\it $#1$.lock}\xspace}
\newcommand{\unlock}[1]{\mbox{\it $#1$.unlock}\xspace}
\newcommand{\locked}[1]{\mbox{\it locked\_$#1$}}
\newcommand{\unlocked}[1]{\mbox{\it unlocked\_$#1$}}
\newcommand{\eqfd}[1]{{\,\stackrel{#1}{:=}\,}}
\newcommand{\infers}{{\it \vdash}}
\newcommand{\DB}{{\bf D}}
\newcommand{\HBF}{{\cal HB(F)}}
\newcommand{\dbeq}{{\,\stackrel{\mbox{\tiny $\cal L$}}
                               {\mbox{\large $\sim$}}\,}}
\newcommand{\TR}{{\,\cal T\mbox{\small $\cR$}}\xspace}
\newcommand{\TRp}{{\,\cal T\mbox{\small $\cR$}}\xspace}
\newcommand{\inode}{I_{node}}
\newcommand{\ipath}{I_{path}}
\newcommand{\sbpth}{{\sqsubset}}
\newcommand{\fst}{{\bf 1}}
\newcommand{\lst}{{\ell}}
\newcommand{\obj}{{\bf o}}
\newcommand{\pth}{{\bf p}}
\newcommand{\stat}{{\bf s}}
\newcommand{\pref}{{\sf pref}}
\newcommand{\suff}{{\sf suff}}
\newcommand{\pbrk}{{\sf brk}}
\newcommand{\repr}{{\,\leadsto\,}}
\newcommand{\dashV}{\mbox{\small $\,-\!\|\,$}}
\newcommand{\dbseq}{\mbox{\,{-}{-}{-}\,}}
\newcommand{\noop}{\mbox{\tt no-op}}
\newcommand{\ISD}   {$\Im^\Diamond$\xspace}  % Inf system with hypo
\newcommand{\IS}    {$\Im^I$\xspace}         % Inf system I
\newcommand{\ISS}   {$\Im^{II}$\xspace}      % Inf system II
\newcommand{\sequent}[2]{\bP,#1\dbseq\,\infers\, #2}
\newcommand{\blackBox}{\mbox{\footnotesize $\blacksquare$}}
\newcommand{\blackDiamond}{\mbox{\small $\blacklozenge$}}
\newcommand{\0}{\linebreak[0]}


\newenvironment{lines}[1]{\begin{center}\begin{tabular}{#1}}{\end{tabular}\end{center}}
\newenvironment{mathlines}[1]{\medskip\begin{center}\begin{math}\begin{array}{#1}}{\end{array}\end{math}\end{center}\medskip}





%%
\begin{document}

\title{\huge\bf Transaction Logic Programming \medskip\\
\Large (or, A Logic of Procedural and Declarative Knowledge) \bigskip}

\author{
        Anthony J.~Bonner \\
\small Department of Computer Science\\
\small University of Toronto\\
\small Toronto, Ontario ~M5S 1A4, Canada\\
\small {\tt bonner@db.toronto.edu}
        \and
        Michael Kifer \\
\small  Department of Computer Science\\
\small  SUNY at Stony Brook\\
\small  Stony Brook, NY 11790, U.S.A.\\
\small  {\tt kifer@cs.sunysb.edu}
        }
\date{}


\sloppy
{\addtolength{\footnotesep}{1mm} \maketitle}
\pagestyle{headings}
\thispagestyle{empty}

%  BEGIN MANUSCRIPT

\normalsize
\begin{abstract}
\normalsize
%\setlength{\baselineskip}{1.1\baselineskip}
A new formalism, called {\em Transaction Logic}, is proposed to
account in a clean and declarative fashion for the phenomenon of state
changes in logic programs and databases. Transaction Logic extends
classical logic with connectives specifically designed for combining simple
actions into complex transactions and for providing control over their
execution.  
The proposed logic has a natural model theory and a sound and complete
proof theory, but unlike many other logics, it allows users to {\it
program\/} transactions.  This is possible because, like classical
logic, Transaction Logic has a ``Horn'' version which has a procedural
as well as a declarative semantics.  In addition, the semantics leads
naturally to features whose amalgamation in a single logic has proved
elusive in the past.  These features include both hypothetical {\it
and\/} committed updates, dynamic constraints on transaction
execution, nondeterminism, and bulk updates.  Finally, Transaction
Logic holds promise as a logical model of hitherto non-logical
phenomena, including so-called {\em procedural knowledge\/} in AI,
{\em active databases}, and the {\it behavior\/} of object-oriented
databases, especially methods with side effects.  Apart from the
applications to Databases and Logic Programming, we also discuss
applications to a number of AI problems, such as planning, temporal
specifications, and the frame problem.
\end{abstract}
\bigskip


\newpage
\pagenumbering{roman}
\setcounter{page}{1}
\tableofcontents

\newpage
\pagenumbering{arabic}
\setcounter{page}{1}


\section{Introduction}
\thispagestyle{empty}

The ability to change the current state of the underlying database is an
integral part of any practical logic programming language.  Unfortunately,
such state changes are not accounted for by the classical Horn semantics of
logic programs and deductive databases, which limits their usefulness in
real-world applications.  As an interim solution, logic programming
languages have resorted to handling updates through non-logical operators.
To remedy this problem, this paper provides the theoretical foundations
for logic programming with updates.  This is accomplished in three ways:
$(i)$ we develop a general logic of state change, called {\em Transaction
  Logic}, with a natural model theory; $(ii)$ we show that this logic has a
``Horn'' fragment, with both a procedural and a declarative semantics; and
$(iii)$ we show that programs in the logic can be executed by an SLD-style
proof procedure, in the logic-programming tradition.  The result is a
rule-based language with a purely logical semantics (and a
sound-and-complete proof theory) in which users can program and execute
database transactions.  Moreover, in the absence of updates, this language
reduces to classical Horn logic.  It therefore represents a conservative
extension of the logic programming paradigm.


Transaction Logic (or \TR for short) is a general logic of state
change that provides a clean and simple account of database updates
and transactions, and of important related phenomena, such as the
order of update operations, transaction abort and rollback,
savepoints, and execution constraints.  \TR has applications in many
areas, including databases, logic programming, workflow management,
and artificial intelligence.  For instance, in logic programming, \TR
provides a clean, logical alternative to the {\em assert\/} and {\em
retract\/} operators of Prolog \cite{trans-tr-95}.  In relational
databases, \TR provides a logical language for programming
transactions, for updating database views, and for specifying active
rules \cite{trans-tr-95,trans-dbpl93,bonner-dbpl97-long}.  In
object-oriented databases, \TR can be combined with object-oriented
logics, such as F-logic~\cite{flogic-new}, to provide a logical
account of {\it methods}---procedures hidden inside objects that
manipulate these objects' internal states~\cite{kifer-dood-95}.  In
AI, \TR suggests a logical account of procedural knowledge and
planning, and it can also serve as a powerful formalism for reasoning
about the effects of actions
\cite{trans-tr-95,trans-ictl94,trans-reasoning-98}. In addition, \TR
has been shown an effective tool for a number of emerging areas in
information systems, such as workflow management
\cite{davulcu-workflow-98,bonner-pods99-long} and web databases
\cite{webbase-98}.

All these applications are described in detail in the cited
papers, and we shall not discuss them here. Instead, our focus will be on
the rigorous development of the model and the proof theory of \TR.


\paragraph{\TR and other logics.}
On the surface, there would seem to be many other logics available for
specifying database transactions, since many logics reason about
updates or about the related phenomena of time and action.  However,
despite a plethora of action logics, researchers continue to complain
that there is no clear declarative semantics for updates either in
databases or in logic
programming~\cite{beeri-challenge-92,bancilhon-cocktail,glue-91}.  In
particular, database transaction languages are not founded on action
logics, the way that query languages are founded on classical logic.
The main reason, we believe, is that reasoning about action is {\it
not\/} the same thing as declarative programming, especially in a
database context.  This difference manifests itself in several ways:

\begin{enumerate}

\item Unlike classical Horn logic, many logics of action do not have a
  procedural interpretation.  Allen's binary connectives on temporal
  intervals are a typical example~\cite{allen-84}.  Such logics are
  often intended for specifying relationships between actions.  For
  instance, one might specify that action $A$ comes before action $B$,
  and that action $B$ comes before action $C$, and then infer that $A$
  comes before $C$.  In such logics, it is not possible to execute
  actions, since one may not know what an action actually does,
  $i.e.$, what changes it makes to the database state.  Indeed, the
  logic may not include a notion of databaase state at all.  In
  addition, the ability to combine simple actions into complex
  programs is often limited.

\item Other logics of action take a very procedural view of programs,
  their goal being to reason about these procedural entities.  Dynamic
  logic is a typical example~\cite{harel79}.  Such action logics
  typically have two separate languages: a procedural language for
  representing programs, and a logical language for reasoning about
  them.  The programs themselves are not declarative or logical at
  all, but are more akin to Algol programs.  Moreover, logic is not
  used {\it inside\/} programs to specify database queries, but is
  used {\it outside\/} programs to specify program properties.  This
  is the exact opposite of database languages and logic programs,
  where the goal is to make programming as declarative as possible,
  and often logic itself {\it is\/} the programming language, or a
  significant part of it.  The result is that it is difficult to
  integrate such action logics with database query languages and logic
  programs, since there is a natural ``impedance mismatch'' between
  them.

\item For logics of action, the proof theory does not execute programs
  and update the database.  Instead, the logics are inherently
  hypothetical.  At best, they can infer what {\it would\/} be true
  {\it if\/} a program were executed; the database itself is unchanged
  by such inferences.  To actually execute a program and update the
  database, a separate run-time system is needed outside the logic.
  This is contrary to the idea of logic programming, in which the
  logical proof theory acts as the run-time system, so that programs
  are executed by proving theorems.

\end{enumerate}


\paragraph{Prolog.}
The system that comes closest in spirit to the paradigm developed in
this paper is Prolog.  Although it is not a logic of action per se,
database transactions can be defined in Prolog via the operators {\it
assert\/} and {\it retract}.
Prolog addresses many of the problems listed above, and has many of
the properties we wish to model: $(i)$ it is a programming language
based on a Horn subset of a full logic, $(ii)$ programs are executed
by an SLD-style proof procedure---not via a separate run-time system,
$(iii)$ updates are real, not hypothetical, $(iv)$ in the absence of
updates, it reduces to classical Horn logic.
Unfortunately, updates in Prolog are non-logical
operations; so each time a programmer uses {\em assert\/} or {\it
retract}, he moves further away from declarative programming.
Moreover, Prolog does not support some important features of database
transactions, such as abort and rollback.  For these reasons,
state-changing procedures are often the most awkward of Prolog
programs, and the most difficult to understand, debug, and maintain.

In addition, updates in Prolog are not integrated into a complete
logical system.  It is therefore not clear how {\em assert\/} and {\em
retract\/} should interact with other logical operators such as
disjunction and negation.  For instance, what does \,\mbox{${\it
assert}(X) \vee {\it assert}(Y)$}\, mean?  or \mbox{$\neg {\it
assert}(X)$}?  or \,\mbox{${\it assert}(X) \la {\it retract}(Y)$}?\,
Also, how does one logically account for the fact that the order of
updates is important?  None of these questions is addressed by
Prolog's operational semantics, or by the classical theory of logic
programming.


\TR provides a general solution to the aforementioned limitations,
both of Prolog and of action logics.  The solution consists of two
parts: $(i)$ a general logic of state change, and $(ii)$ a Horn-like
fragment that supports logic programming.  In the Horn fragment, users
can specify and execute transaction programs; and in the full logic,
users can also express properties of programs and reason about
them~\cite{trans-reasoning-98}.  This paper first develops the syntax
and semantics of the full logic.  The paper then develops the Horn
fragment, and shows that it provides a logic-programming language with
updates.  A central feature of this development is an SLD-style proof
procedure based on unification, a key requirement for any practical
logic-programming language.  This procedure executes logic programs,
updates the database, and answers queries, all as a result of proving
theorems, and all in accordance with the logical semantics.

The Horn fragment of \TR allows users to combine elementary database
operations into complex logic programs.  Unlike many logics of action, Horn
\TR is not concerned with the axiomatization of elementary operations, but
with their logical combination into programs.  A logical axiomatization of
elementary operations is essential only for reasoning about the properties
of actions, not for programming and executing them.  Such axiomatizations
can be carried out in full \TR~\cite{trans-reasoning-98}, but they are not
considered in this paper because they are not needed for logic programming.
In logic programming and databases (as in C and Pascal), application
programmers spend no time on specifying elementary operations. Instead,
their time is mainly spent on combining these operations into complex
transactions and programs.



\section{Overview of Transaction Logic}
\label{sec-overview}


\subsection{The General Logic}
\label{sec-general}

Transaction Logic is an extension of first-order classical logic for
reasoning about database transactions.  It extends classical logic
with a new operator called {\it serial conjunction}, denoted
$\otimes$.  Syntactically, if $\alpha$ and $\beta$ are logical
formulas in \TRp, then so is \,\mbox{$\alpha\otimes\beta$}.  Logical
formulas may also be constructed from the connectives and quantifiers
of classical logic.  Thus \,\mbox{$\neg\alpha$},\,
\,\mbox{$\alpha\Or\beta$}\, and \,\mbox{$\forall X\, \alpha$}\, are
logical formulas in \TRp.  Logical formulas in \TR are called {\it
transaction formulas}.  To illustrate, we give some simple examples of
transaction formulas and their intuitive meanings.  In these examples,
the atomic formula \,\mbox{$withdraw(N,A)$}\, means, ``{\it $N$
dollars is withdrawn from bank account $A$}.''


\paragraph{Classical Connectives.}
The meaning of classical connectives in Transaction Logic is the same
as in classical logic.

\begin{itemize}
\item $withdraw(50,123) \,\Or\, withdraw(50,456)$

	\$50 is withdrawn from account 123 or from account 456.

\item $\exists A~withdraw(50,A)$

	\$50 is withdrawn from some account, $A$.

\item $\neg withdraw(50,123)$

	\$50 is not withdrawn from account 123.

\item $\forall A \,\neg\, [withdraw(50,A) \lra withdraw(80,A)]$

	Withdrawing \$50 from an account is not the same as
	withdrawing \$80.

\end{itemize}


\paragraph{Non-Classical Connectives.}
Serial conjunction extends classical logic with the ability to make
statements about the order in which actions occur.  It can be combined
arbitrarily with the classical connectives.  In the examples below,
the atom \,$deposit(N,A)$\, means, ``{\it $N$ dollars is deposited
into account $A$},'' and the atom \,{\it transfer}$(N,A_1,A_2)$\,
means, ``{\it $N$ dollars is transferred from account $A_1$ to account
$A_2$}.''  The formulas below combine these atoms into more complex
statements.

\begin{itemize}
\item $withdraw(50,123) \,\otimes\, deposit(50,456)$

	\$50 is withdrawn from account 123, and then deposited into
	account 456.


\item $\exists N~withdraw(N,123) \otimes [deposit(N,456) \Or deposit(N,789)]$

	Some amount, $N$, is withdrawn from account 123, and then
	deposited into account 456 or account 789.


\item
 $\forall N A_1 A_2~~ withdraw(N,A_1) \otimes deposit(N,A_2) ~\ra~ {\it transfer}(N,A_1,A_2)$

	If $N$ dollars is withdrawn from account $A_1$ and then
	deposited into account $A_2$, then $N$ dollars is transferred
	from account $A_1$ to $A_2$.

\end{itemize}


\paragraph{Static Constraints.}
Atoms like $withdraw(50,123)$ and $deposit(50,456)$ are statements
about a dynamic, changing world.  In \TRp, one can also make
statements about a static, unchanging world.  For instance, suppose
the atom \,$balance(B,A)$\, means, ``{\it $B$ is the balance of
account $A$}.''  There is no notion of change in this statement.%
%
\footnote{When the formal semantics is developed in
Section~\ref{sec-semantics}, we will see that static statements are
just a special case of dynamic statements.  That is, all statements
are associated with a sequence of database states,
\,\mbox{$\left<s_1,s_2,...,s_n\right>$}.~ Static statements are simply
associated with sequences of length 1, $i.e.$, sequences of the form
\,\mbox{$\left<s_1\right>$}.}
%
However, static and dynamic statements can be combined in \TR to
provide rich descriptions of changing worlds.  For example,

\begin{itemize}

\item $balance(90,123) \otimes withdraw(50,123) \otimes balance(40,123)$

	The balance of account 123 is \$90, and then \$50 is
	withdrawn, and then the balance of account 123 is \$40.


\item $\forall A B~~ balance(B,A) \otimes withdraw(50,A) ~\lra~
                     withdraw(50,A) \otimes balance(B-50,A)$

	$B$ is the balance of an account {\it before\/} withdrawing
	\$50 dollars if and only if $B-E$ is the balance {\it after\/}
	withdrawing \$50.


\item $\forall A B\, \neg\,[balance(B,A) \otimes withdraw(50,A) ~\lra~
                          withdraw(50,A) \otimes balance(B,A)]$

	The balance of an account {\it before\/} withdrawing \$50 is
	not the same as the balance {\it after\/} withdrawing \$50.

\end{itemize}

These last examples describe the effects of the $withdraw$
transaction.  By building on this idea, one can give a complete
axiomatization in \TR of the effects of any elementary action.  It is
then possible to reason about the effects of actions in open
worlds~\cite{trans-reasoning-98}.


\paragraph{Dynamic Constraints.}
By combining serial conjunction with classical conjunction, we can
express dynamic constraints on the way a dynamic world evolves.  To
simplify the example below, we use logical equivalence to define
abbreviations.

\begin{itemize}
\item $d ~\lra~ \exists N A~deposit(N,A)$

$d$ represents any deposit.

\item $w ~\lra~ \exists N A~withdraw(N,A)$

$w$ represents any withdrawal.

\item $wd ~\lra~ w \Or d$

$wd$ represents any withdrawal or deposit.

\item $s3 ~\lra~ wd \otimes wd \otimes wd$

$s3$ represents any sequence of three withdrawals or deposits.

\item $c3 ~\lra~ (wd \otimes wd \otimes wd) \,\And\, \neg (w \otimes w \otimes w)$

$c3$ represents a constrained sequence, $i.e.$, any sequence of three
withdrawals or deposits {\it other than\/} a sequence of three
withdrawals.

\end{itemize}



\subsection{Procedural Interpretation}
\label{sec-procedural}

The examples above illustrate the {\it declarative\/} semantics of
\TRp.  Every logical formula of \TR has a declarative interpretation,
just as every formula of classical logic does.  In addition, some
formulas of \TR have an equivalent {\it procedural\/} interpretation,
just as Horn formulas in classical logic do.

In the procedural interpretation, transaction formulas can be viewed
imperatively, that is, as commands to execute actions.  For instance,
the atom \,\mbox{$withdraw(amount,account)$}\, can be viewed as a
command to withdraw an amount of money from a bank account.  In this
interpretation, logical connectives become action constructors.  For
instance, the formula \,\mbox{$\alpha\otimes\beta$}\, now means,
``{\it First do $\alpha$, and then do $\beta$}.''  Likewise, the
formula \,\mbox{$\alpha\Or\beta$}\, means, ``{\it Do $\alpha$ or do
$\beta$},'' and the formula \,\mbox{$\exists X\, \alpha(X)$}\, means,
``{\it Do $\alpha(x)$, for some $x$}.''  Even negative formulas can be
treated imperatively: the formula $\neg\alpha$ simply means, ``{\it Do
not do $\alpha$}.''  This interpretation of transaction formulas
provides the basis for a logic programming language for database
transactions, described below.  In this language, complex database
transactions are built up from elementary database updates.

The theory of Transaction Logic does not depend on any particular set
of elementary updates, as can be seen from the formal development in
Section~\ref{sec-oracles}.  However, for the purpose of illustration,
we often use a familar set of update operations.  Specifically, for
each database predicate, $p$, we introduce two other predicates,
denoted $\ins{p}$ and $\del{p}$, to represent database insertion and
deletion, respectively.  In the declarative semantics, the atomic
formula $\ins{p(b)}$ means, ``{\it The atom $p(b)$ is inserted into
the database.}''  Likewise, the atomic formula $\del{p(b)}$ means,
``{\it The atom $p(b)$ is deleted from the database.}''  In the
procedural semantics, these atomic formulas become commands to insert
and delete atoms from the database, respectively.

Using the logical connectives of \TRp, these elementary updates can be
combined into executable database transactions.  To illustrate, the
following examples give some simple transaction formulas and their
procedural interpretations:


\begin{itemize}
\item \mbox{$\del{p}(b) \otimes \ins{q}(b)$}

``{\it First delete $p(b)$ from the database, and then insert $q(b)$
into the database}.''


\item \mbox{$p(b) \otimes \del{p}(b)$}

``{\it First check that $p(b)$ is in the database, and then delete
$p(b)$ from the database}.''


\item \mbox{$\ins{p}(b) \Or \ins{q}(a)$}

``{\it Insert $p(b)$ into the database, or insert $q(a)$ into the
database}.''


\item \mbox{$[\ins{p}(a) \otimes \ins{p}(b)] \Or [\del{q}(a) \otimes
\del{q}(b)]$}

``{\it Do one of the following: insert $p(a)$ and then insert $p(b)$;
or delete $q(a)$ and then delete $q(b)$}.''


\item \mbox{$\exists X\, \del{p}(X)$}

``{\it Delete $p(x)$ from the database, for some $x$}.''


\item \mbox{$\exists X\,[q(X) \otimes \ins{p}(X)]$}

``{\it First retrieve $q(x)$ from the database, and then insert $p(x)$
into the database, for some $x$}.''

\end{itemize}



\subsection{Transaction Logic Programming}
\label{sec-programming}

Like classical logic, Transaction Logic has a Horn fragment, called
{\it serial-Horn\/} \TRp, in which logical formulas can be interpreted
as programs.  As in classical Horn logic, the procedural semantics of
serial-Horn \TR is based on an SLD-style proof procedure that executes
programs by proving theorems, in the logic programming tradition.
However, unlike classical logic programming, the proof procedure for
serial-Horn \TR does more than just evaluate queries: it also {\it
updates\/} the database.  These updates are handled in a completely
logical manner, and are an essential part of the proof theory of \TRp.
This section defines the syntax of serial-Horn \TRp, and illustrates
its use in programming database transactions and robot actions.

Serial-Horn \TR is based on the idea of {\it serial goals}.  A serial
goal is a transaction formula of the form\, \mbox{$a_1 \otimes a_2
\otimes ...  \otimes a_n$}, \,where each $a_i$ is an atomic formula
and $n\geq 0$.  A {\em serial-Horn rule\/} \index{serial-Horn rule}
has the form ~\mbox{$b \la a_1 \otimes a_2 \otimes ... \otimes a_n$},~
where the body, ~\mbox{$a_1 \otimes a_2 \otimes ...  \otimes a_n$},~
is a serial goal and the head, $b$, is an atomic formula.  Finally, a
serial-Horn transaction base is simply a set of serial-Horn rules.
Observe that a serial-Horn transaction base can be transformed into a
classical Horn rulebase by replacing each occurrence of $\otimes$ by
$\And$.  This transformation changes the serial-Horn rule ~\mbox{$b
\la a_1\otimes ... \otimes a_n$}~ into the classical Horn rule
~\mbox{$b \la a_1\And ... \And a_n$}.  In the absence of updates, this
transformation is a logical equivalence.  Classical Horn logic is thus
a special case of serial-Horn \TRp.

Specifying and executing logic programs in serial-Horn \TR is similar
to using Prolog.  To specify programs, the user writes a set of
serial-Horn rules (the transaction base).  These rules define database
transactions, including queries, updates, or a combination of both.
To execute programs, the user submits a serial goal to a
theorem-proving system, which also acts as a run-time system.  This
system executes transactions, updates the database, and generates
query answers, all as a result of proving theorems.  As in Prolog,
rules are evaluated in a top-down fashion, rule premises are evaluated
from left to right, and if a rule premise fails, then the program
defined by the rule also fails.

Unlike Prolog, \TR provides a basic property of database transactions,
namely {\it atomicity\/}: the appearance that a program either
executes to completion or not at all.  Atomicity allows a complex
program to be treated as an atomic or elementary operation.
Unfortunately, Prolog lacks this basic transactional feature.
Consequently, state-changing procedures in Prolog are the most
difficult to understand, debug and maintain, and their semantics is
heavily dependent on rule order.  Moreover, even if the operational
semantics of Prolog did support atomicity (as in \TRp), a logical
semantics would still be needed to account for it and for updates.
This semantics is provided by the model theory of \TRp.
Operationally, when a \TR program fails, the theorem prover aborts the
program's execution, and rolls back {\it both\/} the program state and
the database state to the last choice point (or save-point), from
whence execution resumes.  In this way, the theorem prover guarantees
atomicity by implementing other transactional features, such as abort,
rollback, and
save-points~\cite{bonner-dbpl97-long,bonner-pods99-long}.  These
features are all supported by the implementation of serial-Horn \TR
described in~\cite{samuel-thesis}.


\begin{example}{Financial Transactions}
\label{ex-finance}
Suppose the balance of a bank account is given by the predicate\,
\mbox{$balance(Acct,Amt)$}.  \,The transaction base below defines four
predicates, each representing a transaction program:\, \mbox{{\it
change}$(Acct,Bal_1,Bal_2)$} \,changes the balance of account $Acct$
from $Bal_1$ to $Bal_2$;\, \mbox{$withdraw(Amt,Acct)$} \,withdraws an
amount from an account;\, \mbox{$deposit(Amt,Acct)$} \,deposits an
amount into an account;\, and \mbox{${\it
transfer}(Amt,Acct_1,Acct_2)$} \,transfers an amount from account
$Acct_1$ to account $Acct_2$.
%
{\small
\begin{mathlines}{ll}
  \multicolumn{2}{l}{
{\it transfer}(Amt,Acct_1,Acct_2)  ~\la~
   withdraw(Amt,Acct_1) \,\otimes\, deposit(Amt,Acct_2)
   }
 \mg

withdraw(Amt,Acct)  ~\la~ & balance(Acct,Bal) \\
   & ~~\otimes\, Bal > Amt \,\otimes\, {\it change}(Acct,Bal,Bal-Amt) \mg

   \multicolumn{2}{l}{
deposit(Amt,Acct)  ~\la~ 
   balance(Acct,Bal) \,\otimes\, {\it change}(Acct,Bal,Bal+Amt)
   }
 \mg

   \multicolumn{2}{l}{
{\it change}(Acct,Bal_1,Bal_2)  ~\la~
   \del{balance}(Acct,Bal_1) \,\otimes\, \ins{balance}(Acct,Bal_2)
   }
\end{mathlines}
}
%
These rules can be interpreted in a typical logic-programming style.
The first rule says: to transfer an amount, $Amt$, from $Acct_1$ to
$Acct_2$, first withdraw $Amt$ from $Acct_1$; and then, if the
withdrawal succeeds, deposit $Amt$ in $Acct_2$.  Likewise, the second
rule says, to withdraw $Amt$ from an account $Acct$, first retrieve
the balance of the account; then check that the account will not be
overdrawn by the transaction; then, if all is well, change the balance
from $Bal$ to \mbox{$Bal-Amt$}.  The last rule changes the balance of
an account by deleting the old balance and then inserting the new one.
Observe that the {\it transfer\/} transaction fails (aborts) if either
of the subtransactions {\it withdraw\/} or {\it deposit\/} fails.
Likewise, the {\it withdraw\/} transaction fails if the query
$balance(Acct,Bal)$ fails ($e.g.$, if $Acct$ is not a valid account)
or if the test \,\mbox{$Bal > Amt$}\, fails ($i.e.$, if the balance is
not big enough).
\end{example}


Observe that the rules in Example~\ref{ex-finance} can easily be
rewritten in Prolog, by replacing ``$\otimes$'' with ``,'' and
replacing the elementary transitions, $\ins{balance}$ and
$\del{balance}$, with {\em assert\/} and {\em retract}, respectively.
However, the resulting, apparently innocuous, Prolog program will not
execute correctly!  The problem is that Prolog does not undo updates
during backtracking.  As an example, consider a transaction involving
two transfers, defined as follows:
\[
        \query {\it transfer}(fee,client,broker) \,\otimes\,
        {\it transfer}(cost,client,seller)
\]
That is, a fee is transferred from a client to a broker, and then a
cost is transferred from the client to a seller.  Because this is
intended to be a transaction, it must behave atomically; that is, it
must execute entirely or not at all.  Thus, if the second transfer
fails, then the first one must be rolled back.  In this respect, \TR
behaves correctly.  Prolog, however, does not, since it commits
updates immediately and does not undo partially executed transactions.
Thus, if the second transfer above were to fail (say, because the
client's account would be overdrawn by the transaction), then Prolog
would {\it not\/} undo the first one, thus leaving the database in an
inconsistent state.

Getting around this problem takes much out of the simplicity of Prolog
programming.  In fact, the non-logical behavior of Prolog updates is
notorious for making Prolog programs cumbersome and heavily dependent
on Prolog's backtracking strategy.  Some Prologs provide the means to
implement backtrackable updates through the use of non-logical
operations, such as {\it assert}, {\it retract}, and cut (!).
However, the logic behind the resulting update operations has not been
developed.  Transaction Logic can be considered to provide the missing
semantics and proof theory, although there are many fine differences
between simplistic implementations of backtrackable updates and the
logic.


\begin{example}{Non-deterministic, Recursive Robot Actions}
\label{ex-robot}
The transaction base below simulates the movements of a 
robot arm in a
world of toy blocks.  States of this world are defined in terms of
three predicates: $on(x,y)$, which says that block $x$ is on top of
block $y$;\, $isclear(x)$, which says that nothing is on top of block
$x$;\, and $wider(x,y)$, which says that $x$ is strictly wider than
$y$.  The rules define four predicates representing actions that
change the state of the world.
%%
\begin{equation}\label{eq-stack}
\begin{array}{ll}
  \multicolumn{2}{l}{
stack(N,X) ~\la~ N>0 \,\otimes\, move(Y,X) \,\otimes\, stack(N-1,Y) 
        } \medskip\\
stack(0,X) ~\la~ \medskip\\
\multicolumn{2}{l}{
move(X,Y) ~\la~ pickup(X) \,\otimes\, putdown(X,Y) 
        } \medskip\\
\multicolumn{2}{l}{
pickup(X) ~\la~ isclear(X) \,\otimes\, on(X,Y) \,\otimes\,
        \del{on}(X,Y) \,\otimes\, \ins{isclear}(Y)
        } \medskip\\
putdown(X,Y) ~\la ~ & wider(Y,X) \,\otimes\, isclear(Y) \\
        & ~~\otimes\, \ins{on}(X,Y) \,\otimes\, \del{isclear}\,(Y)
\end{array}
\end{equation}
%%
The actions $pickup(X)$ and $putdown(X,Y)$ mean, respectively: ``{\em
pick up block $X$}'' and ``{\em put down block $X$ on top of block
$Y$, where $Y$ must be wider than $X$}.''  The effects of both actions
are specified in terms of elementary inserts and deletes to database
relations.  The remaining rules combine simple actions into more
complex ones.  For instance, $move(X,Y)$ means, ``{\it Move block $X$
to the top of block $Y$,}'' and $stack(N,X)$ means, ``{\it Stack $N$
arbitrary blocks on top of block $X$.}''

The actions {\em pickup\/} and {\em putdown\/} are deterministic,
since each set of argument bindings specifies only one robot
action.\footnote{Assuming that only one block can be on top of another
block.}  In contrast, the action $stack$ is {\it non-deterministic\/}.
To perform this action, the theorem prover searches the database for
blocks that can be stacked (represented by variable $Y$).  If, at any
step, several such blocks can be placed on top of the stack, the
system arbitrarily chooses one of them.
\end{example}



\section{Syntax}
\label{sec-syntax}

The previous section introduced \TR informally.  This section begins
the formal development.

We define the alphabet of a language of \TR to consist of the
following symbols:
%%
\begin{itemize}
\item $\cV$: a countably-infinite set of variables.
  
\item $\cF$: a countably-infinite set of function symbols. Each symbol
  $f \in \cF$ has a non-negative number, its {\em arity}, indicating
  the number of arguments $f$ can take.  There are infinitely many
  symbols of each arity.  Constants are viewed as 0-ary function
  symbols.

\item $\cP$: a countably-infinite set of predicate symbols.  Like
  functions, predicate symbols have arity, and $\cP$ has infinitely
  many predicate symbols of each arity.  0-ary predicate symbols are
  viewed as propositional constants.

\item Logical connectives $\vee$, $\wedge$ (classical disjunction and
conjunction), $\oplus$, $\otimes$ (serial disjunction and
conjunction), $\neg$ (classical negation). Additional connectives will
be defined in terms of these later.

\item Quantifiers $\forall$, $\exists$.

\item Auxiliary symbols, such as ``('', ``)'',
and ``,''.
\end{itemize}
%%
Terms are defined as usual in first-order logic: A variable is a term;
if $f$ is an $n$-ary function symbol and $t_1 ,\,\ldots\,,\, t_n$ are
terms, then $f(t_1 ,\,\ldots\,,\, t_n)$ is a term. When $n=0$, we
write $f$ instead of $f(\,)$.  In this paper, we adopt the Prolog
convention that variables begin in upper case, and function and
constant symbols begin in lower case.



\subsubsection*{Transaction Formulas}

\TR extends the syntax of first-order predicate logic with two new
binary connectives, $\otimes$ and $\oplus$, called {\it serial
conjunction\/} and {\it serial disjunction\/}, respectively.  The
resulting logical formulas are called {\it transaction formulas}.

Formally, transaction formulas are defined recursively as follows.
First, an {\em atomic\/} transaction formula is an expression of the
form $p(t_1, \ldots , t_n)$, where $p \in \cP$ is a predicate symbol,
and $t_1, \ldots , t_n$ are terms.  Second, if $\phi$ and $\psi$ are
transaction formulas, then so are the following expressions:
%%
\begin{itemize}
\item   $\phi \vee \psi$, ~$\phi \wedge \psi$,
        ~$\phi \oplus \psi$, ~$\phi \otimes \psi$, ~and ~$\neg \phi$.
\item   $(\forall X) \phi$ ~and~ $(\exists X) \phi$, ~where $X$ is a
        variable.
\end{itemize}
%%
The following are examples of transaction formulas:
\begin{itemize}
\item $b(X)\otimes c(X,Y)$
\item $a(X) \Or \neg\llparen b(X) \otimes c(X,Y)\lrparen$
\item $\forall X \llparen a(X) \Or \neg b(X)\oplus \neg c(X,Y)\lrparen$
\end{itemize}
%%
Intuitively, the formula $\psi\otimes\phi$\, means, ``Action $\psi$
occurs, and then action $\phi$ occurs,'' and the formula
$\psi\oplus\phi$\, (very roughly) means, ``Action $\psi$ occurs now or
action $\phi$ occurs later.''  Formally, $\oplus$ and $\otimes$ are
defined to be dual, so that $\neg(\psi\oplus\phi)$\, is equivalent to
$\neg\phi\otimes\neg\psi$.  Note that the classical first-order
formulas are transaction formulas that do not use $\otimes$ and
$\oplus$.  As in classical logic, we introduce convenient
abbreviations for complex formulas.  For instance, $\psi \la \phi$ is
an abbreviation for $\psi \Or \neg \phi$, for any transaction formulas
$\psi$ and $\phi$.



\section{Elementary Operations}
\label{sec-oracles}

Classical logic theories always come with a parameter: a language for
constructing well-formed formulas.  This language is not fixed, since
almost any set of constants, variables and predicate symbols can be
``plugged into'' it.  Likewise, \TR theories are also parameterized by
a language.  In addition, they have another parameter: a pair of
oracles, called the {\em data oracle\/} and the {\em transition
oracle}, which specify elementary database operations.  The data
oracle specifies a set of primitive database {\it queries}, $i.e.$,
the {\it static\/} semantics of states; and the transition oracle
specifies a set of primitive database {\it updates}, $i.e.$, the {\it
dynamic\/} semantics of states.  These two oracles encapsulate
elementary database operations.
%They also separate the specification of elementary operations from the
%logic of combining them.  As we shall soon see, this separation has
%two main benefits: $(i)$ it allows us to develop a logic for combining
%and programming transactions without committing to a particular theory
%of elementary updates; and $(ii)$ it allows \TR to accommodate a wide
%variety of database semantics, from classical to non-monotonic to
%various other non-standard logics.
Like the language of the logic, the oracles are not fixed, since
almost any pair of oracles can be ``plugged into'' a \TR theory.


\subsection{State Data Oracles}

One of the goals underlying the design of \TR is to make it general
enough to deal with any kind of database state, including relational
databases and more general deductive databases.  One may therefore be
tempted to define a state as an arbitrary first-order formula and
close the issue.  However, things turn out to be more involved.  For
one thing, stating that a database state is a first-order formula does
not determine the set of truths about that state.  This is because in
databases and logic programming, one usually assigns a {\em
non-standard\/} semantics to such databases, such as Clark's
completion, a perfect-model or a well-founded model
semantics~\cite{lloyd-logic-programming,gelder-ross-schlipf-91,gelfond-stable-88}.
Because of this, it is wise to insulate the dynamic aspects of
transaction execution from the static aspects pertaining to the truth
at database states.  Not only will this allow Transaction Logic to
work with different database semantics, but it will also enable us to
study the dynamics in separation from those static aspects.

Another problem is that logically equivalent first-order formulas may
represent different database states. For instance, in databases and logic
programming, $\{p \impl \neg q\}$ is viewed as a different state than
$\{q \impl \neg p\}$, even though the two formulas are classically
equivalent.  In the first database, $p$ is considered as true and $q$ as
false; in the second state, it is just the opposite.

To achieve the needed generality, the semantics of states is specified
by a {\it state data oracle}. We assume a countable set of symbols,
called {\em state identifiers}, which the oracles use to refer to
database states. Note, these symbols are not part of the language of
\TR, just as the oracles are not part of it. Indeed, transaction
formulas in \TR never address database states or oracles directly.
However, state identifiers and oracles are used to define the
semantics and the proof theory of \TR.
%%
\begin{definition}{State Data Oracle}
\label{def-doracle} 
A {\em state data oracle\/} is a mapping, $\dO$, from the set of state
identifiers to sets of closed first-order formulas.
\end{definition}
%%
Intuitively, if $i$ is a state identifier, then $\doracle(i)$ is the
set of formulas considered to be all the truths known about the state.
In practice, it is not necessary to materialize all these truths.
Instead, given a logical formulas $\phi$, and a state identifier $i$,
the proof theory for \TR only needs to know whether
\,\mbox{$\phi\in\dO(\bD)$}.  Thus, to do inference in \TR, an
enumeration of $\dO(i)$ is all that is needed.

Since the state id uniquely identifies a state, we shall use the terms
``state'' and ``state id'' interchangeably.  To connote the right
intuition, many examples in this paper use first-order formulas (or
sets of first-order formulas) as state identifiers.  This is
appropriate because many useful oracles can be conveniently described
in terms of such formulas.  However, our results and definitions do
not depend on this representation and, in general, any construct can
be a state identifier.
%%
%%A state identifier could be a set of non-logical objects, such as flat
%%files, documents or disk pages.
%%For example, in Section~\ref{sec-sitcalc}, we use function terms as
%%state identifiers.

To get a better grasp of the idea of an oracle-as-database-state,
Section~\ref{sec-oracles-ex} provides a number of examples, which are
used frequently in this paper.


\subsection{State Transition Oracles}
\label{sec-elem}

The next step is to specify {\em elementary\/} changes to the
database.  One way to define such changes is to build them into the
semantics, as in
\cite{manchanda-88,naqvi-updates-88,bonner-tcs-90,chen-tods-95,vianu-pods-88,mccarty83}.
The problem with this approach is that adding new kinds of elementary
transitions requires redefining the very notion of a model and, hence,
entails a revamping of the entire theory, including the need to
reprove soundness and completeness results.  In other words, such
theories are not extensible.  This is a serious problem, since the
ability to add new transitions is by no means an esoteric whim.
In~\cite{trans-tr-95,trans-dbpl93}, for instance, we use a new kind of
transition called {\em relational assignment\/} to perform bulk
updates and non-deterministic sampling.  In scientific databases, an
elementary transition may be a sophisticated numerical operation, such
as a Fourier transform.

The problem is aggravated by the fact that, for arbitrary logical
databases, the semantics of elementary updates is not clear, not even
for relatively simple updates like insert and delete.  For example,
what does it mean to insert an atom $b$ into a database that entails
$\neg b$, especially if $\neg b$ itself is not explicitly present in
the database?  Or, is insertion of $\{q\}$ into $\{p \impl \neg q\}$
the same as the insertion into $\{q \impl \neg p\}$?  There is no
simple answer to this question, and many solutions have been proposed
(see \cite{katsuno-mendel-kr91} for a comprehensive discussion).
Furthermore, Katsuno and Mendelzon \cite{katsuno-mendel-kr91} pointed
out that, generally, state transitions belong to two major
categories---{\em updates\/} and {\em revisions\/}---and, even within
each category, several different flavours of such transitions are
worth looking at.  Thus, there appears to be no small, single set of
elementary state transitions that is best for all purposes.

For this reason, rather than committing \TR to a fixed set of
elementary transitions, we have chosen to treat elementary state
transitions as a {\em parameter\/} of \TR.  Each set of elementary
transitions thus gives rise to a different version of the logic.  To
achieve this, elementary state transitions are specified outside \TR,
using the notion of a {\em state transition oracle\/}.  In this way,
elementary transitions are separated from the issue of specifying
complex transactions.  \TR can thus work with any algorithmic or
declarative language for specifying elementary transitions.

\begin{definition}{State Transition Oracle}
\label{def-toracle}
A {\em state transition oracle}, $\toracle$, is a mapping from ordered
pairs of database state identifiers into sets of ground ({\it i.e.},
variable-free) atomic formulas.  We will often refer to these ground
atoms as {\em elementary transitions}.
\end{definition}
%%
Intuitively, if $i_1$ and $i_2$ are state identifiers, then
$\tO(i_1,i_2)$ is the set of elementary updates that can transform
state $i_1$ into state $i_2$.  An elementary update can thus be
non-deterministic, since for each update, the transition oracle
defines a binary relation on states.  In practice, this relation does
not have to be materialized.  Instead, for a given update $u$, and a
given state $i_1$, the proof theory of \TR only needs an enumeration
of the possible successor states, $i_2$.

Because the transition oracle returns ground atoms only, the
elementary updates are completely specified.  To see this, suppose
that $\tO(i_1,i_2)$ contained the formula $a \Or b$.  Intuitively,
this would mean that one of $a$ or $b$ transforms the database from
state $i_1$ to state $i_2$, but we do not know which one.\footnote{
%%
We could allow arbitrary closed formulas like $a \Or b$ to be returned
by the transition oracle, but this would complicate the theoretical
development, and it is not clear what applications this generalization
would have.}

Finally, the names of elementary transitions, such as \ins{b} and
\del{b} in Section~\ref{sec-procedural}, have {\em no\/} special
status in \TR.  That is, they are ordinary atomic formulas that just
happen to be mentioned by the oracle.  In principle, nothing prevents
the user from putting rules for \ins{b} into the transaction
base.\footnote{
%%
However, preventing the user from tinkering with the definitions of
elementary transitions may be a good practice.}
%%
Even the fancy names of these predicates is nothing but a convention
adopted for this paper.

%%A logic program in \TR consists of two parts: a transaction base,
%%$\bP$, which is a set of (transaction) formulas and the current database
%%state, $\bD$, 
%%which is a set of first-order formulas, and which is updatable by the
%%transactions defined in $\bP$.



\subsection{Examples}
\label{sec-oracles-ex}

This section gives examples of data and transition oracles.  In each
example, a database state is a set of data items, as in the theory of
transaction management \cite{bernstein87}.  Intuitively, a data item
can be any persistent object, such as a tuple, a disk page, a file, or
a logical formula.  Formally, however, a database state has no
structure, and our only access to it is through the two oracles.  Some
of the oracles below can be combined to yield more powerful oracles.
Typically, such combinations are possible when oracles operate on
disjoint domains of data items.

\paragraph{\em Relational Oracles:}
~A state $\bD$ is a set of ground atomic formulas.  The data oracle
simply returns all these formulas.  Thus, $\doracle(\bD) = \bD$.
Moreover, for each predicate symbol $p$ in $\bD$, the transition
oracle defines two new predicates, $\ins{p}$ and $\del{p}$,
representing the insertion and deletion of single atoms, respectively.
Formally, ~$\ins{p}(\overline{x}) \in \tO(\bD_1,\bD_2)$~ iff ~$\bD_2 =
\bD_1 \cup \{p(\overline{x})\}$.  Likewise, ~$\del{p}(\overline{x})
\in \tO(\bD_1,\bD_2)$~ iff ~$\bD_2 = \bD_1 - \{p(\overline{x})\}$.
SQL-style bulk updates can also be defined by the transition
oracle~\cite{trans-tr-95,trans-dbpl93}, as can primitives for creating
new constant symbols.

\paragraph{\em Scientific Oracles:}
~A state is a set of square matrices.  For each matrix, $B$, in a
state, the data oracle defines three ternary relations, $b$, $b.inv$
and $b.dft$, representing the matrix itself, its inverse, $B^{-1}$,
and its two-dimensional discrete Fourier transform, $dft(B)$,
respectively.  Formally, ~$b(i,j,v) \in \dO(\bD)$~ iff ~$B(i,j)=v$ in
$\bD$.  Likewise, ~$b.inv(i,j,v) \in \dO(\bD)$~ iff ~$B^{-1}(i,j)=v$;~
and ~$b.dft(i,j,v) \in \dO(\bD)$~ iff ~$dft(B)(i,j)=v$.  ~In this way,
the data oracle provides three built-in views of each
matrix.\footnote{
%%
Matrix inversion and discrete Fourier transforms are typically
provided as built-in operations by scientific software packages.}
%%
The transition oracle also defines three predicates, $b.set$,
$b.rswap$ and $b.cswap$, which update matrix $b$.  The first predicate
sets the value of an element of the matrix.  Formally, ~$b.set(i,j,v)
\in \tO(\bD_1,\bD_2)$~ iff $\bD_1 = \bD_2$ except that $B(i,j)=v$ in
state $\bD_2$.  Likewise, $b.rswap(i,j)$ swaps rows $i$ and $j$ of the
matrix, while $b.cswap$ swaps columns $i$ and $j$.  Note that for
main-memory systems, these updates can be implemented with an
efficiency comparable to that of variable assignment, $i.e.$, much
more efficiently than assert and retract in Prolog.

\paragraph{\em Classical Oracles:}
~A state $\bD$ is a consistent set of variable-free, classical
first-order formulas.  The data oracle defines all the logical
implications of these formulas.  Thus ~\mbox{$\dO(\bD)$} = \mbox{$\{
\psi \mid \bD \models^c \psi \}$},~ where $\models^c$ denotes
classical entailment.  The transition oracle defines primitives for
adding and removing formulas from the database, resolving any
conflicts between the new formulas and existing formulas.  Such
conflicts can be resolved in numerous ways, as shown by Katsuno and
Mendelzon \cite{katsuno-mendel-kr91}.  For instance, for each
first-order formula, $\mu$, the transition oracle could define four
predicates, $update[\mu]$, $erase[\mu]$, $revise[\mu]$ and
$contract[\mu]$ for doing updates, erasure, revision, and contraction
as defined in \cite{katsuno-mendel-kr91}.

\paragraph{\em Well-Founded Oracle:}
~A state $\bD$ is a set of generalized-Horn rules,\footnote{
%%
Generalized-Horn are rules with possibly negated premises.}
%%
and $\doracle(\bD)$ is the set of literals in the well-founded model
of $\bD$ \cite{gelder-ross-schlipf-91}.  Such oracles can represent
any rule-base with well-founded semantics, which includes Horn
rule-bases, stratified rule-bases, and locally-stratified rule-bases.
For sophisticated applications, one may want to augment
$\doracle(\bD)$ with the rules in $\bD$.

\paragraph{\em Generalized-Horn Oracles:}
~A state $\bD$ is a set of generalized-Horn rules and $\doracle(\bD)$
is a classical Herbrand model of $\bD$.  Such oracles can represent
Horn rule-bases, stratified rule-bases, locally-stratified rule-bases,
rule-bases with stable-model semantics~\cite{gelfond-stable-88}, and
any rule-base whose meaning is given by a classical Herbrand model.
Again, one may want to augment $\doracle(\bD)$ with the rules in
$\bD$.



\subsection{Implementing Oracles}

Unlike the formulas in a transaction base, we do not expect the
oracles to be coded by casual users.  Although the oracles allow for
many different semantics for states and state changes, we envision
that any logic programming system based on \TR will likely have a
carefully selected repertoire of built-in database semantics, and a
tightly controlled mechanism for adding new ones.  This latter
mechanism would not be available to ordinary programmers.  For this
reason, we assume in this paper that the data and transition oracles
are fixed.
%We have therefore not provided a
%language for specifying large transition bases succinctly, although in
%principle this could be done through mechanisms like the situation
%calculus \cite{sitcalc-69}.

Unfortunately, there is no general solution to the practical problem
of {\em how\/} oracles can best be implemented.  For the classical
oracle described above, the problem has been partly solved by Grahne,
Mendelzon, and Winslett \cite{grahne-mendel-91,winslett-tods-88}.
Winslett showed that, in general, the problem of updating
propositional formulas is NP-hard.  Subsequently, though, Grahne and
Mendelzon proved that updating sets of ground atoms with arbitrary
propositional formulas can be done in polynomial time.  More
importantly, this result carries over to deductive databases, in which
only the extensional part is updated.  In this case, as with
relational databases, updates are fast and straightforward.

For scientific databases, the oracles may involve complex calculations
and simulations, such as matrix inversion or numerical integration.
Good algorithms for carrying out these operations have been carefully
developed by scientists and numerical analysts.  These algorithms
should be incorporated into the oracles.  It is completely impractical
to expect a user to specify declaratively a complex numerical
operation, and expect an optimizer to find the best way of
implementing it.  This would require the optimizer to automatically
reproduce years of research in combinatorial optimization.  Instead,
oracles allow us to exploit what combinatorialists have discovered,
without having to rediscover it.

By design, the issue of specifying and implementing elementary
operations is orthogonal to our work.  In \TR, the data and transition
oracles are external parameters, and all that matters practically is
the existence of an algorithm to compute the outcome of an operation,
or to enumerate the possible outcomes if the operation is
non-deterministic.  Finally, we note that transaction definitions are
independent of the oracles.  This latter point contributes to making
\TR a lucid and flexible language for defining transaction programs.



\section{Model Theory}
\label{sec-semantics}

The model theory of \TR is based on a few simple ideas.  We discuss
these ideas, and then develop the model theory in detail.

\paragraph{\em States.~}
As in modal logic, a semantic structure in \TR is based on a set of
states.  Beyond this similarity, however, the two logics are very
different.  For instance, in modal logic, the set of states is not
fixed, but can vary from one semantic structure to another.  In
Transaction Logic, the set of states is the same for all semantic
structures: it is the set of states that comes with the data and
transition oracles.  Changing the oracles can change the set of
states, and thus the set of semantic structures.  This is one way in
which different oracles give rise to different versions of \TR.


\paragraph{\em Transaction Execution Paths.~}
When a transaction is executed, the database may change, going from an
initial state, $\bD_1$, to a final state, $\bD_n$.  As illustrated in
Section~\ref{sec-semantics-ex}, the database may also pass through any
number of intermediate states, \,$\bD_2,\ldots,\bD_{n-1}$,\, along the
way.  We say that the sequence
\,\mbox{$\tuple{\bD_1~\bD_2~\ldots~\bD_{n-1}~\bD_n}$}\, is the {\it
execution path\/} of the transaction, and that it has {\em length\/}
$n$.  The semantics of Transaction Logic is based on execution paths,
or {\it paths\/} for short.  As illustrated
in~\cite{trans-tr-95,trans-ictl94,trans-dbpl93}, paths allow us to
model a wide range of constraints on transaction execution.  For
example, we may require that every intermediate state satisfies some
condition, or we may forbid certain sequences of states.  Because of
the emphasis on paths, semantic structures in \TR are called {\it path
structures}.

Unlike modal structures, truth of formulas in path structures is
defined on paths, not states. This is because, as in Process
Logic~\cite{process-log-82}, transactions should be able to examine
and query intermediate states of their execution.  For example, we
would say that the path ~\mbox{$\tuple{\{a\}~\{a,b\}~\{a,b,c\}}$}~
satisfies the formula $\ins{b}\otimes a \otimes\ins{c}$, since it
represents an insertion of $b$ followed by an insertion of $c$, and
the proposition $a$ is true in the intermediate state created by the
first update.  On the other hand, the path
~\mbox{$\tuple{\{a\}~\{a,c\}~\{a,b,c\}}$}~ does {\it not\/} satisfy
this formula; instead, it satisfies the formula $\ins{c}\otimes a
\otimes\ins{b}$.  This simple example illustrates a general idea in
\TR: {\em the truth of a formula on a path corresponds to a complete
execution of a transaction program}.  One consequence of this idea is
that a formula may be true on a path, but false on all its proper
subpaths.  This is because only the full path represents a {\it
complete\/} execution.  For example, although the formula
\,\mbox{$\ins{b}\otimes a \otimes\ins{c}$}\, is true on the path
~\mbox{$\tuple{\{a\}~\{a,b\}~\{a,b,c\}}$},~ it is false on the
subpaths ~\mbox{$\tuple{\{a\}~\{a,b\}}$}~ and
~\mbox{$\tuple{\{a,b\}~\{a,b,c\}}$}.

The kind of transaction that a formula represents depends on the paths
that satisfy it.  If the paths are of length 1 ({\it i.e.}, consist of
a single state), then the transaction is a query; if the paths are of
length 2, then the transaction is (usually) an elementary update; and
if the paths are of length greater than 2, then the transaction is a
composite update.  If the paths are of various lengths, then different
executions of the transaction program correspond to different kinds of
transaction.  In this way, one model-theoretic device, paths, accounts
for queries, updates, and more general transactions.

To define truth on paths in a completely general way, we assign a
first-order semantic structure to each path, $\pi$.  This structure
specifies those atomic formulas that are true on $\pi$.  The
satisfaction of complex formulas on $\pi$ is determined by the
semantic structures assigned to $\pi$ and its subpaths.  Intuitively,
all formulas---atomic or complex---that are true on a path represent
transactions that execute along the path.  This reliance on paths is
reminiscent of a version of Process Logic defined in
\cite{process-log-82}.  However, there is a vast difference in {\em
how\/} truth is defined and in {\em what\/} formulas actually denote.
Further comparison is provided in Section~\ref{sec-comparisons}.


\paragraph{\em Stored Facts vs.~Derived Facts.~}
In classical database systems, a subtle distinction is made between
stored facts and derived facts.  Typically, update procedures
distinguish between these two types of facts, but query processors do
not.  For example, a deductive database has a set of base facts
$\bD$, called the {\em extensional\/} database, and a set of rules
$\bP$, called the {\em intensional\/} database.  The query processor,
however, sees only the logical consequences of $\bD\cup \bP$.  In this
way, a user cannot tell whether a fact is stored or derived.  In
contrast, update-procedures act only on the stored facts $\bD$.  Even
if a user requests an update to a derived fact (a view update), the
request is translated into an equivalent set of updates to the stored
facts.  The reason, of course, is that derived facts cannot be changed
without changing the base facts that support them.

To reflect this distinction, the path structures of \TR carefully
distinguish between a state $\bD$ and the path $\tuple{\bD}$ of
length 1.  Intuitively, the state $\bD$ represents the formulas stored
in the database, and the path $\tuple{\bD}$ represents formulas
derived by combining the database and the transaction base.  That is,
in database terminology, $\tuple{\bD}$ is a {\it view\/} of
$\bD$.\footnote{
%%
Of course, the state $\bD$ also represents derived information, but
only information that is derivable from the formulas in the database.}
%%
Only the state $\bD$ (the stored data) is updated, and only the path
$\tuple{\bD}$ (the view) is queried.  The user, therefore, sees the
state indirectly, through the view.  To capture this idea formally,
formulas are {\it never\/} evaluated at states (unlike modal logic).
Thus, one cannot inquire about the truth of a formula $\psi$ at a state
$\bD$, since this would be tantamount to querying stored facts
directly.  However, $\psi$ can be evaluated on the path $\tuple{\bD}$,
which is tantamount to querying the view over $\bD$, as in the
classical theory of deductive databases.


\subsection{Path Structures}
\label{sec-structures}

This section makes the preceding discussion precise.

The formal definition of path structures relies on the familiar notion
of classical first-order semantic structures~\cite{enderton-logic}.
The turnstile \,$\models^c$\, denotes satisfaction in these
structures, $i.e.$, classical satisfaction.  For our purposes, it is
convenient to augment these classical structures with a {\em special},
abstract structure, denoted $\top$.  We define $\top$ to satisfy every
first-order formula.  Even though $\top$ is not a classical structure,
we shall call it ``classical'' because adding it to classical logic
does not change the logic in any essential way---it simply adds one
more model to every formula (and some notions, such as satisfiability
and consistency, require minor adjustments).  Having $\top$ is
convenient because it provides a degree of tolerance to inconsistency
that may exist between database states and views over them.\footnote{
%%
In the case of Horn \TR, inconsistencies do not arise, so $\top$ has
no affect.
%%
 }
%%
It is also a simple adaptation of techniques used in paraconsistent
logics ($e.g.$,~\cite{kifer-apc}), which analyze the knowledge
contained in inconsistent states.  Section~\ref{sec-discussion}
provides further discussion of $\top$.

As described in Section~\ref{sec-syntax}, \TR comes with a language,
$\cL$ (which determines the syntax of formulas), and with a pair of
oracles, $\doracle$ and $\toracle$ (which determine the semantics of
databases).  These oracles come with a set of database state
identifiers (or states).  We define a {\em path\/} of length $k$ (or
{\it k-path\/}) to be a finite sequence of these states,
\mbox{$\tuple{\bD_1~\ldots~\bD_k}$}, where $k \geq 1$.  In the rest of
this paper, the language $\cL$ and the oracles, states and paths are
implicit.

In the following definition, each path structure has a domain of
objects and an interpretation for all function symbols.  These are
used to interpret formulas on every path in the structure.


\begin{definition}{Path Structures}
\label{def-structures}
~Let $\cL$ be a language of \TR with the set of function symbols
$\cF$.  A {\em path structure}, $\bM$, over $\cL$ is a triple
$\tuple{U, I_\cF, \ipath}$, where:
%%
\begin{itemize}
\item   $U$ is a set, called the {\em domain\/} of $\bM$.

\item $I_\cF$ is an interpretation of function symbols in $\cL$. It assigns
  a function $U^n \longmapsto U$ to every $n$-ary function symbol in $\cF$.

  ~~~Given $U$ and $I_\cF$, let $Struct(U, I_\cF)$ denote the set of all
  classical first-order semantic structures over $\cL$ of the form
  $\tuple{U, I_\cF, I_\cP}$, where $U$ is the domain of the structure,
  $I_\cP$ is a mapping that interprets predicate symbols in $\cP$ by
  relations on $U$ of appropriate arity, and $U$ and $I_\cF$ are the same
  as in $\bM$.  In accordance with an earlier remark, we also assume that
  $Struct(U, I_\cF)$ contains the special ``classical'' structure $\top$.

\item $\ipath$ is a mapping that assigns to every path a semantic
  structure in $Struct(U, I_\cF)$.  Finally, we subject the mapping
  $\ipath$ to two restrictions:
  %    
  \begin{itemize}
  \item {\em Compliance with the data oracle\/}:
    %%
    $\ipath (\tuple{\bD}) \models^c \phi$,~ for every $\phi \in
    \doracle(\bD)$, which means that the view over any database state must
    be a model of whatever the oracle considers to be true of that
    state.\footnote{
    %%
      Observe that unlike the early versions of \TR
      \cite{trans-iclp93,trans-tcs94}, $\ipath (\tuple{\bD})$ is not
      required to be a model of $\bD$. It will be a model, however, if the
      oracle is such that $\bD$ is logically implied by $\doracle(\bD)$,
      such as in the case of the Generalized Horn Oracle.
      %%
      }
      %%
    (As before $\models^c$ denotes classical satisfaction in first-order
    models.)
  \item {\em Compliance with the transition oracle\/}:
    %%
    $\ipath (\tup{\bD_1~\bD_2}) \models^c b$ whenever
    $b \in \toracle(\bD_1,\bD_2)$.
  \end{itemize}
  %
\end{itemize}
\vspace{-8mm}
\end{definition}


\noindent
The mapping $\ipath$ specifies what atoms are true on what paths.
These atoms denote actions that take place along various paths.  In
arbitrary path structures, these actions are independent of one
another.  In particular, the semantic structure assigned to path $\pi$
is independent of the subpaths of $\pi$.  Intuitively, this means that
we know nothing about the relationship between transactions and their
subtransactions.  Such knowledge, when it exists, is encoded as
transaction formulas, as described in Section~\ref{sec-models}.  These
formulas constrain the mapping $\ipath$, forcing the atoms on one path
to be related in precise ways to atoms on other paths.

Path structures are also constrained by the data and transition
oracles.  The oracles specify elementary database operations which all
path structures must model.  Definition~\ref{def-structures}
formalizes this idea by imposing two restrictions on path structures.
Intuitively,
%%
\begin{itemize}
\item
restriction~1 says that the data oracle is modeled by 1-paths in a
path structure; $i.e.$, the semantic structure assigned to path
$\tuple{\bD}$ is a classical model of the formulas stored at $\bD$;

\item
restriction~2 says that the transition oracle is modeled by 2-paths
in a path structure; $i.e.$, the semantic structure assigned to path
$\tuple{\bD_1~\bD_2}$ is a classical model of the elementary
transitions from $\bD_1$ to $\bD_2$.

\end{itemize}

One more point about Definition~\ref{def-structures} is worth noting.
In a path structure, $\bM$, the mapping $I_\cF$ is shared by all
classical first-order structures mentioned in $\bM$.  In modal logics,
such semantics is said to be based on the assumption of ``rigid
designators.''  If this assumption is not made, the number of models
of a formula may increase and so certain valid formulas (with respect
to rigid designators) may become non-valid.  As in modal logics, the
decision to use rigid designators has a profound effect on \TR. For
instance, when equality is allowed, {\em non\/}-rigid designators
would lead to unintuitive semantics in the context of \TR.

As a simple exercise, the reader can verify the following
after reading through the rest of this section.  Suppose that $I_\cF$
is allowed to vary from state to state within a path structure.
Suppose also that the transaction base contains a single rule, $\, p(X)
\impl (X=c) \otimes \ins{q}(b) \otimes (X=c)$.\, Intuitively,
executing the transaction $\query p(c)$\, on an empty database should
cause the insertion of $q(b)$ into the database.  However, this is
{\it not\/} the case with non-rigid designators. Indeed, the
interpretation of $c$ in the state corresponding to the empty database
may differ from the interpretation of $c$
in the state corresponding to the database $\{ q(b) \}$.  In this case, the
transaction would fail, and the database would remain empty!


\subsection{Satisfaction on Paths}
\label{sec-satisfaction}

Transaction formulas are evaluated on paths.  That is, they are true
or false on paths in a structure.  This subsection makes this idea
precise.

Given a path, $\pi = \tuple{\bD_1 ~...~ \bD_n}$, it is convenient to
define a {\em split\/} of $\pi$ to be any pair of subpaths, $\pi_1$ and
$\pi_2$, such that $\pi_1 = \tuple{\bD_1 ~...~ \bD_i}$ and $\pi_2 =
\tuple{\bD_i ~...~ \bD_n}$\, for some $i$ ($1 \leq i \leq n$).  In this
case, we shall write $\pi = \pi_1 \circ \pi_2$.  In other words,
$\pi = \pi_1 \circ \pi_2$ if and only if $\pi_1$ is a prefix of
$\pi$, $\pi_2$ is a suffix of $\pi$, and the last state in $\pi_1$ is the
first state in $\pi_2$.

As in classical logic, in order to define the truth value of
quantified formulas and of open formulas, it is convenient to
introduce variable assignments.  A {\em variable assignment\/}
is a mapping $\nu:\,\cV \longrightarrow \cU$, which takes a variable as input,
and returns a Herbrand term as output.  We extend the mapping from
variables to terms in the usual way, {\it i.e.}, $\nu(f(t_1
,\,\ldots\,,\, t_n)) = f(\nu(t_1) ,\,\ldots\,,\, \nu(t_n))$.


\begin{definition}{Satisfaction}
\label{def-sat-tr}
~Let \,$\bM = \tuple{U, I_\cF, \ipath}$\, be a path structure, let
$\pi$ be an arbitrary path, and let $\nu$ be a variable assignment.
Then:
%%
\begin{enumerate}
%%
\item {\bf Base Case:} \\ 
$\bM, \pi \models_\nu b$~ if and only if ~$\ipath(\pi) \models^c_\nu
b$,~~ where $b$ is an atomic formula.

\item {\bf Negation:} \\
$\bM, \pi \models_\nu \neg\phi$~ if and only if it is not the case
that ~$\bM, \pi \models_\nu \phi$.

\item {\bf Classical Conjunction:} \\
$\bM, \pi \models_\nu \phi \wedge \psi$~ if and only if ~$\bM, \pi
\models_\nu \phi$~ and ~$\bM, \pi \models_\nu \psi$.

\item {\bf Classical Disjunction:} \\
$\bM, \pi \models_\nu \phi \vee \psi$~ if and only if ~$\bM, \pi
\models_\nu \phi$~ or ~$\bM, \pi \models_\nu \psi$.

\item {\bf Serial Conjunction:} \\
$\bM, \pi \models_\nu \phi \otimes \psi$~ if and only if ~$\bM, \pi_1
\models_\nu \phi$~ and ~$\bM, \pi_2 \models_\nu \psi$~ for {\em
some\/} split $\pi_1 \circ \pi_2$ of path $\pi$.

\item {\bf Serial Disjunction:} \\
$\bM, \pi \models_\nu \phi \oplus \psi$~ if and only if ~$\bM, \pi_1
\models_\nu \phi$~ or ~$\bM, \pi_2 \models_\nu \psi$~ for {\em
every\/} split $\pi_1 \circ \pi_2$ of path $\pi$.

\item {\bf Universal Quantification:} \\
$\bM, \pi \models_\nu (\forall X)\phi$~ if and only if ~$\bM, \pi
\models_\mu \phi$~ for {\em every\/} variable assignment $\mu$ that
agrees with $\nu$ everywhere except on $X$.

\item {\bf Existential Quantification:} \\
$\bM, \pi \models_\nu (\exists X)\phi$~ if and only if ~$\bM, \pi
\models_\mu \phi$~ for {\em some\/} variable assignment $\mu$ that
agrees with $\nu$ everywhere except on $X$.
%%
\end{enumerate}
\end{definition}


\noindent
As in classical logic, the mention of variable assignment can be
omitted for {\em sentences\/}, {\it i.e.}, for formulas with no free
variables.  From now on, we will deal only with sentences, unless
explicitly stated otherwise.  If \,$\bM,\pi \models \phi$,\, then we
say that $\phi$ is {\it satisfied\/} (or is {\it true\/}) on path
$\pi$ in structure $\bM$.


Several points about Definition~\ref{def-sat-tr} are worth mentioning:
%%
\begin{itemize}
\item
The base case captures the intuition behind transaction execution
along a path: if the atom $p(t_1,\,\ldots\,,\,t_n)$ is true on path
$\pi$, then transaction $p$ can execute along $\pi$ when invoked with
arguments $t_1,\,\ldots\,,\,t_n$.

\item
The semantics of all ``classical'' connectives ($\And$, $\neg$, etc.)\
is defined in a classical fashion.  For these connectives, truth on a
path depends only on the classical structure assigned to the path.
The classical nature of these connectives is made precise by
Lemma~\ref{lem-sat-classical} below.

\item
For the non-classical connective $\otimes$, truth on a path depends
not just on the path, but on its {\it subpaths\/} as well.  In this
way, actions on different paths can be made to depend on each other.
Intuitively, the formula \mbox{$\phi\otimes\psi$} is true on a path if
the path corresponds to an execution of $\phi$ followed by an
execution of $\psi$.  This idea is illustrated in
Sections~\ref{sec-models} and~\ref{sec-inference1}.

%%\item
%%The conjunction $\phi\And\psi$ does {\em not\/} specify the concurrent
%%execution of transactions $\phi$ and $\psi$.  Instead, it corresponds
%%to their {\it constrained execution}.  Both these transactions may be
%%non-deterministic actions that can be executed in many possible ways.
%%``Classical'' conjunction constrains their non-determinism.
%%Intuitively, $\phi\And\psi$ means, ``Execute action $\phi$ in such a
%%way that $\psi$ is satisfied.''  Sections~\ref{sec-intro-constraints}
%%and~\ref{sec-constraints} illustrate this further.

\item
For paths of length 1, the connectives $\otimes$ and $\And$ are
equivalent, as shown in Lemma~\ref{lem-sat-state} below.  It follows
that on 1-paths, every occurrence of $\otimes$ in a transaction
formula can be replaced by $\And$ to give an equivalent first-order
formula.  By Lemma~\ref{lem-sat-classical}, this formula has a
classical semantics.  Thus, on paths of length 1, $\otimes$ and $\And$
reduce to ordinary conjunction in classical predicate logic.  On
longer paths, these two connectives extend the classical semantics of
conjunction in two different ways.
\end{itemize}


\begin{lemma} \label{lem-sat-classical}
If $\phi$ is a first-order formula, then ~$\bM,\pi\models\phi$~ if and
only if ~$\ipath(\pi)\models^c\phi$,~ for any path structure $M$ and
any path $\pi$, where $\models^c$ denotes classical entailment.
\end{lemma}
%%
\begin{proof}
Follows by a straightforward induction on the structure of $\phi$.
\end{proof}


\begin{lemma} \label{lem-sat-state}
If $\alpha$ and $\beta$ are two transaction formulas, then
~\mbox{$\bM,\tup{\bD}\models\alpha\otimes\beta$}~ if and only if
~\mbox{$\bM,\tup{\bD}\models\alpha\And\beta$},~ for any path structure
$\bM$ and any state $\bD$.
\end{lemma}
%%
\begin{proof}
Follows from the observation that \,$\tuple{\bD} \circ \tuple{\bD}$\,
is the only split of path $\tuple{\bD}$.
\end{proof}

The reader may have noticed that although the definitions of path
structures and satisfaction invoke the classical predicate calculus
when it comes to the logic of individual states ($e.g.$, in the base
case of Definition~\ref{def-sat-tr}), we do not rely on the actual
properties of that calculus.  In fact, \TR relies only on the
existence of an entailment relation, such as $\models^c$, that can be
used by the state data oracle. Indeed, \cite{kifer-dood-95} shows how
a different logic of states (F-logic \cite{flogic-new}) can be used as
a simple drop-in replacement for predicate calculus within the
framework of \TR.


\subsubsection*{Abbreviations}

Before continuing, we define a few useful abbreviations.  As usual in
first-order logic, we define $\psi \la \phi$ and $\phi \ra \psi$ to
mean $\psi \vee \neg\phi$, and $\psi \biimpl \phi$ to mean $(\psi \la
\phi) \wedge (\psi \ra \phi)$.  By replacing $\vee$ and $\wedge$ with
$\otimes$ and $\oplus$ we obtain another interesting pair of
connectives: the {\em left serial implication\/}, $\psi \La \phi$,
standing for $\psi \oplus \neg \phi$, and the {\em right\/} serial
implication, $\phi \Ra \psi$, standing for $\neg\phi \oplus \psi$.  As
follows from Definition~\ref{def-sat-tr}, in plain English these
formulas say the following: ``action $\phi$ must be immediately
preceded (resp., followed) by action $\psi$.'' Note that unlike
``$\la$'' and ``$\ra$'', the connectives ``$\La$'' and ``$\Ra$'' are
not just syntactic variations of each other, {\it i.e.}, $\psi \La
\phi$ is not equivalent to $\phi \Ra \psi$; rather, $\psi \La \phi$ is
equivalent to $\neg\psi \Ra \neg\phi$.  Applications of these
connectives are discussed in~\cite{trans-tr-95,trans-dbpl93}.
Finally, we introduce two more abbreviations, for iterating the
operators $\otimes$ and $\oplus$:
\[
\otimes^n\psi~~\equiv~~\underbrace{\psi\otimes \cdots \otimes\psi}_n
~~~~~~~~~~~~~~~
\oplus^n\psi~~\equiv~~\underbrace{\psi\oplus \cdots \oplus\psi}_n 
\]



\subsubsection*{Truth on States}

In addition to the abbreviations above, we assume that our language
contains a predefined propositional constant, $\state$, which is true
only on paths of length 1, that is, on database states.  Formally, for
any path structure $\bM$ and path $\pi$, it is the case that \,$\bM,
\pi \models \state$\, if and only if $\pi$ is a path of length 1.
Thus, $\state$ is false on every path having more than one state, even
on loops like $\tuple{\bD~\bD}$.  (Such loops can arise if, for
instance, a transaction inserts an atom into a database when the atom
is already there.  In such cases, the initial and final states of the
database are the same.)  Another useful constant is $\ppath$, defined
as $\state \vee \neg \state$, which is true on every path in $\bM$.
In fact, $\ppath$ is equivalent to $\phi \vee \neg \phi$ for any
formula $\phi$, and thus $\ppath$ does not increase the expressive
power of the logic.  In contrast, $\state$ cannot be independently
defined in \TR, and so it {\it does\/} increase the expressive power
of the logic.

(In Section~\ref{sec-hypo-sem} we shall see that $\state$ can be
expressed using $\ppath$ and the possibility operators.  To see that
$\state$ cannot be expressed using the part of \TR introduced so far,
suppose there is a formula $\phi$ such that $\phi \equiv \state$.\,
Let $\bM$ be a path structure, and let $\bD$ be a state in $\bM$.
Choose $\ipath$ so that \,$\ipath(\tuple{\bD~\bD}) = \ipath(\tuple{\bD})$.\,
It is easy to verify by structural induction that
\,\mbox{$\bM,\tuple{\bD~\bD} \models \psi$}\, if and only if
\,\mbox{$\bM,\tuple{\bD} \models \psi$},\, for any formula $\psi$.  But
\,\mbox{$\bM,\tuple{\bD} \models \phi$},\, since $\phi$ is true on {\it
all\/} states, and thus \,\mbox{$\bM,\tuple{\bD~\bD} \models \phi$}.\, But
this contradicts the assumption that $\phi$ is true {\it only\/} on
states.)

It might seem that $\state$ gives a special status to paths of length
1, since \TR can now distinguish them from all other paths.  However,
one can use $\state$ to specify paths of {\it any\/} given length.
Thus, no particular path length is special.  To do this, we first
observe that the formula \mbox{$\neg\state$} is true on paths of
length greater than 1, that is, on paths with at least one arc.  The
formula \,\mbox{$\neg\state\otimes\neg\state$}\, is therefore true on
paths with at least two arcs.  More generally, the formula
\,\mbox{$\otimes^n\neg\state$}\, is true on paths with at least $n$
arcs.  Finally, we observe that the negation of this formula has a
particularly simple form:
\[
        \neg\otimes^n\neg\state~~\equiv~~\oplus^n\state
\]
This formula is true on paths with fewer than $n$ arcs, {\it i.e.},
fewer than $n+1$ states. Thus, their length is at most $n$.  We
can now define the proposition \mbox{\tt n-path}, which is true on
paths of length {\it exactly\/} $n$:
\[
        \mbox{\tt n-path}~~\equiv~~\oplus^n\state\,\And\,
                \neg \oplus^{n-1}\state
\]
As a special case, we define the proposition $\aarc$ to be equivalent
to \mbox{\tt 2-path}.  That is,
\[
        {\aarc}~~\equiv~~(\state\oplus\state)\,\And\,\neg\state
\]
This proposition, which is true on arcs, is analogous to the familiar
temporal operator $\tt next$.  By iterating {\aarc}, we obtain an
alternate definition of \mbox{\tt n-path},\, namely, \,{$\mbox{\tt
n-path}\,\equiv\,\otimes^{n-1} {\aarc}$}.



\subsection{Models}
\label{sec-models}

Path structures assign a first-order semantic structure,
$\ipath(\pi)$, to each path, $\pi$.  For arbitrary path structures,
this assignment is completely arbitrary.  Intuitively, this represents
a situation in which we have no knowledge about actions: each ground
atom represents an action, but we do not know on which paths this
action takes place.  When it exists, knowledge about actions is
expressed as logical formulas.  In this case, we are not interested in
{\it arbitrary\/} path structures, but in {\it models\/} of the
logical formulas.  In these models, the semantic structures assigned
by $\ipath$ are {\it not\/} arbitrary, but satisfy constraints and
dependencies that are implicit in transaction formulas, which
constrain the semantic structures on all paths, and can create
dependencies between the semantic structures on a path and its
subpaths.

%%Note that, by definition, path structures must conform to the data oracle
%%and the transition oracle that comes with any given language of \TR.
%%Data oracles constrains path structures on paths of length 1, while
%%transition oracles do this for paths of length 2.
%%Transaction formulas, on the other hand, constrain the
%%semantic structures on all paths, and can create dependencies between
%%the semantic structures on a path and its subpaths.

%%Recall that an elementary transition is an expression of the form
%%$\tuple{\DB_1~\DB_2}u$, where $u$ is a ground atomic formula, and
%%$\DB_1$ and $\DB_2$ are (finite sets of) first-order formulas.
%%Intuitively, this expression means that update $u$ causes a transition
%%from database $\DB_1$ to database $\DB_2$.  We formalize this idea in
%%the next definition.
%%
%%
%%\begin{definition}{Models of Transition Bases}
%%\label{def-models-elem}
%%Consider a path-structure, \mbox{$\bM = \tuple{U,I_{\cF},\ipath}$}.
%%Let $\tuple{\bD_1~\bD_2}u$ be an elementary state
%%transition.
%%Then, the elementary transition is {\em satisfied\/}
%%in $\bM$, \,denoted $\bM\models\tuple{\bD_1~\bD_2}u$,\, if and only if
%%$\bM, \tuple{\bD_1~\bD_2} \models u$.
%%We say that $\bM$ is a {\em path-model\/} (or simply a {\em model\/})
%%of a transition base $\cB$ if and only if $\bM$ satisfies every elementary
%%state transition in $\cB$.
%%\end{definition}
%%
%%
%%In this definition, $\tuple{\bD_1~\bD_2}$ is a path of length
%%2, and the statement \,$\bM,\tuple{\bD_1~\bD_2} \models u$\, is
%%from Definition~\ref{def-sat-tr}.\footnote{
%%We can use $\models$ instead of
%%$\models_{\nu}$ because $u$ is an elementary transition and is,
%%therefore, ground.
%%}
%%Since $u$ is atomic, only the first item in
%%Definition~\ref{def-sat-tr} is applicable.  Thus,
%%\mbox{$\,\bM\models\tuple{\bD_1~\bD_2}u\,$} if and only if
%%\mbox{$\,\ipath(\tuple{\bD_1~\bD_2}) \models^c u$},\, {\it i.e.}, if
%%and only if the atom $u$ is classically true in the semantic structure
%%assigned to path $\tuple{\bD_1~\bD_2}$.

Note that the definition of path structures guarantees that they come
with a certain amount of structure.  For example, if $u, v$ are
elementary transitions such that \,\mbox{$u \in
\toracle(\bD_1,\bD_2)$}\, and \,\mbox{$v \in
\toracle(\bD_2,\bD_3)$},\, where $\toracle$ is the state transition
oracle, then the atom $u$ is true on the path $\tuple{\bD_1~\bD_2}$,
and the atom $v$ is true on the path $\tuple{\bD_2~\bD_3}$.  This
bare-bones structure has certain logical consequences.  For instance,
by Item 5 of Definition~\ref{def-sat-tr}, the formula $u \otimes v$ is
true on the path $\tuple{\bD_1~\bD_2~\bD_3}$.  However, since each
elementary transition refers to a specific arc, a transition oracle
cannot impose constraints on arbitrary paths or between paths.  This
is the job of the transaction base, which is a set of arbitrary
transaction formulas.


\begin{definition}{Models of Transaction Formulas}
\label{def-models-tr}
~A path structure $\bM$ is a {\em path-model\/} (or just {\em model\/}) of
a \TR-formula $\phi$ if and only if \,\mbox{$\bM,\pi\models\phi$}\, for
every path $\pi$.  In this case, we write \,$\bM\models\phi$.\, A path
structure is a model of a set of formulas if it is a model of every formula
in the set.
\end{definition}


In the models of a transaction formula, dependencies may exist between
the classical semantic structures assigned to a path and its subpaths.
To see this, consider a simple transaction formula \,$p \la q \otimes
r$,\, where $p$, $q$, and $r$ are ground atomic formulas.  Let
\,$\tuple{U, I_\cF, \ipath}$\, be a model of this formula, and let
$\pi$ be any path.  If $\pi_1\circ\pi_2$ is a split of $\pi$, then
$\ipath$ exhibits a dependency between three different semantic
structures on three different paths, $\pi$, $\pi_1$, and $\pi_2$:
%%
\begin{center}
{\it if} ~~~$\ipath(\pi_1) \models^c q$~~~
{\it and} ~~~$\ipath(\pi_2) \models^c r$~~~
{\it then} ~~~$\ipath(\pi) \models^c p$
\end{center}
%%
That is, if $q$ is true on $\pi_1$, and $r$ is true on $\pi_2$, then
$q \otimes r$ is true on $\pi$ (by Definition~\ref{def-sat-tr}), so
$p$ must also be true on $\pi$.  Informally, if $q \otimes r$ can
execute along path $\pi$, then so can $p$.  In a logic-programming
setting, this means that $p$ is a {\em name\/} of the procedure $q
\otimes r$.



\subsection{Validity}

Having developed the notion of a model, it is natural to ask which
formulas are true in all models.  Such formulas are said to be {\it
valid}.  Validity is a standard logical notion.


\begin{example}{Valid Formulas}
It is easy to verify that the following formulas, analogous to De
Morgan's laws, are valid in \TR:
%%
\begin{equation}\label{eq-demorgan}
\begin{array}{rcl}
\neg(\phi \oplus \psi) & \biimpl & \neg\phi \otimes \neg\psi\\
  
\neg(\phi \otimes \psi) & \biimpl & \neg\phi \oplus \neg\psi\\

(\phi \vee \psi) \otimes \eta & \biimpl & (\phi \otimes \eta)
                                          \vee (\psi\otimes\eta) \\
  
(\phi \wedge \psi) \oplus \eta & \biimpl & (\phi \oplus \eta)
                                          \wedge (\psi\oplus\eta) \\
  
(\phi \vee \psi) \oplus \eta & \impl & (\phi \oplus \eta)
                                                  \vee (\psi\oplus\eta) \\

(\phi \wedge \psi) \otimes \eta & \fimpl & (\phi \otimes \eta)
                                         \wedge (\psi\otimes\eta)
\end{array}
\end{equation}
%%
The first pair of laws establishes duality between the serial
connectives $\otimes$ and $\oplus$.  The standard duality between
$\vee$ and $\wedge$ also holds.  The last pair of implications is
unidirectional, which means that $\otimes$, $\oplus$ do not fully
distribute through $\wedge$ and $\vee$, respectively.  Likewise,
$\oplus$ and $\otimes$ do not distribute through each other and
$\vee$, $\wedge$ do not distribute through $\oplus$ and $\otimes$.
The standard De Morgan's laws involving $\vee$, $\wedge$, $\neg$, and
quantifiers {\em do\/} hold, however.  In particular, this implies
that every \TR-formula has prenex normal form, but not necessarily
conjunctive or disjunctive normal forms.
\end{example}


\begin{example}{Valid Formulas}
The following are valid formulas involving the propositional constant
$\state$, which is true only on paths of length 1:
%%
\begin{mathlines}{l}
\phi \biimpl (\phi\otimes\state) \\
\phi \biimpl (\state\otimes\phi) \\
\phi \biimpl (\phi\La\state) \\
\phi \biimpl (\state\Ra\phi)
\end{mathlines}
\end{example}


From valid formulas like those above, one can derive more valid
formulas using inference rules.  For instance, if the formula
\,\mbox{$\alpha \la \beta$}\, is valid, then so is the formula
\,\mbox{$\alpha \otimes \gamma \la \beta \otimes \gamma$}\, and the
formula \,\mbox{$\gamma \otimes \alpha \la \gamma \otimes \beta$}.
This idea is developed in~\cite{trans-reasoning-98}, where an
inference system for reasoning about the properties of actions in \TR
is provided.

We shall not say anything more about validity in this paper.  This is
because validity is concerned with {\it all possible\/} executions of
an action, while this paper is concerned with {\it individual\/}
executions.  That is, we want to execute logic programs, not reason
about their properties.\footnote{Readers interested in reasoning in
\TR are referred to~\cite{trans-reasoning-98}.}  To this end, we
introduce a new model-theoretic notion called {\it executional
entailment}.  It provides the semantic foundation for the proof
procedures developed in Section~\ref{sec-proof}.  These procedures
execute transactions, update the database, and generate query answers,
all as a result of proving theorems.


\subsection{Execution as Entailment}
\label{sec-queries}

A \TR logic program consists of two distinct parts: the transaction
base $\bP$, and the initial database state, $\DB$.  Each of these
parts plays a distinct role in defining executional entailment.  Of
these two parts, only the database state is updatable.  The state (or,
more precisely, what the data oracle reveals about it) consists
entirely of classical first-order formulas, which represent a view of
the actual contents of the state.  In practice, we expect that certain
kinds of database states will arise more frequently than others.  The
most common databases will be sets of ground atoms (relational
databases), function-free Horn clauses (deductive databases), general
Horn clauses (logic programs), and disjunctive and existentially
quantified formulas (indefinite databases).  In contrast, the
transaction base contains transaction formulas that define procedures
that update the database.  As such, it will normally be composed of
formulas containing the serial connectives $\otimes$ or $\oplus$,
though classical first-order formulas are also allowed.


\begin{definition}{Executional Entailment}
\label{def-query}
Let $\bP$ be a transaction base.  Let $\phi$ be a transaction formula,
and $\bD_0,\bD_1,\,\ldots\,,\,\bD_n$ be a sequence of database state
identifiers. Then, the statement
%%
\begin{equation}\label{eq-entail-P-D-D}
        \bP,\bD_0,\bD_1,\,\ldots\,,\,\bD_n  ~\models  ~\phi  
\end{equation}
%%
is true if and only if \,\mbox{$\bM, \tuple{\bD_0~\bD_1~\ldots~ \bD_n}
\,\models\, \phi$}\, for every model $\bM$ of $\bP$.

Related to this are the following statements:
%%
\begin{eqnarray}
    \bP,\bD_0\dbseq ~ \models  ~\phi \label{eq-entail-P-D} \\
    \bP,\bD_0\dbseq\bD_n ~\models~ \phi \label{eq-entail-P-D3}\\
    \bP,\dbseq\bD_n ~\models~ \phi \label{eq-entail-P-D4}
\end{eqnarray}
%%
which are true if and only if there is a sequence of databases
\mbox{$\bD_0,\bD_1,\,\ldots\,,\,\bD_n$} such that
Statement~(\ref{eq-entail-P-D-D}) is true.
%%
\end{definition}
%
Intuitively, Statement (\ref{eq-entail-P-D-D}) says that a successful
execution of transaction $\phi$ can change the database from state
$\bD_0$ to $\bD_1$ $\ldots$ to $\bD_n$.  Formally, it means that in
every model of $\bP$, the path\,
\mbox{$\tuple{\bD_0\,\bD_1\,\ldots\,\bD_n}$} \,satisfies formula
$\phi$.  The statement is read as follows: ``Under the transaction
base $\bP$, transaction $\phi$ may transform database ${\bD}_0$ into
database ${\bD}_n$ by passing through intermediate states $\bD_1
,\,\ldots\,,\, \bD_{n-1}$.''

Normally, users issuing transactions know only the initial database
state $\bD_0$, so defining transaction execution via
(\ref{eq-entail-P-D-D}) is not always appropriate.  To account for
this situation, the version of entailment in (\ref{eq-entail-P-D})
allows us to omit the intermediate and the final database states.
Informally, Statement (\ref{eq-entail-P-D}) says that transaction
$\phi$ can execute successfully starting from database $\bD_0$.
Formally, this statement is read as follows: ``Under the transaction
base $\bP$, the transaction $\phi$ succeeds from database $\bD$.''
When the context is clear, we simply say that transaction $\phi$ {\it
succeeds\/}.  Likewise, when statement~(\ref{eq-entail-P-D}) is not
true, we say that transaction $\phi$ {\it fails}.  In
Section~\ref{sec-proof}, we present an inference system that allows us
to actually {\it find\/} a database sequence
\mbox{$\bD_1,\,\ldots\,,\,\bD_n$} (in fact, to enumerate all
sequences) that satisfy Statement~(\ref{eq-entail-P-D-D}) whenever a
transaction succeeds.

Statement (\ref{eq-entail-P-D4}) is the dual of (\ref{eq-entail-P-D}).
Intuitively, it says that $\phi$ can execute successfully, {\it
terminating\/} at state $\bD_n$.  It is discussed more fully in
Section~\ref{sec-inference2}.  Statement (\ref{eq-entail-P-D3}) is
also a useful abbreviation that will be used throughout the paper.
Informally, it says that $\phi$ can execute successfully starting at
state $\bD_0$ and ending at state $\bD_n$.

The following lemma lists some straightforward consequences of
Definition~\ref{def-query}.

\begin{lemma}[Basic Properties of Executional Entailment] \label{lem-entails}
For any transaction base $\bP$, any sequence of database states
\mbox{$\bD_0,\,\ldots\,,\,\bD_n$}, and any closed transaction formulas
$\alpha$ and $\beta$, the following statements are all true:
%%
\begin{enumerate}
\item   ~If~~ $\bP,\bD_0,\,\ldots\,,\,\bD_n\models\alpha$
        ~~and~~ $\bP,\bD_0,\,\ldots\,,\,\bD_n\models\beta$
        ~~~then~~~ $\bP,\bD_0,\,\ldots\,,\,\bD_n\models\alpha\And\beta$.

\item   ~If~~ $\bP,\bD_0,\,\ldots\,,\,\bD_i\models\alpha$
        ~~and~~ $\bP,\bD_i,\,\ldots\,,\,\bD_n\models\beta$
        ~~~then~~~ $\bP,\bD_0,\,\ldots\,,\,\bD_n\models\alpha\otimes\beta$.

\item   ~If~~ $\alpha\la\beta$\, is in $\bP$
        ~~and~~ $\bP,\bD_0,\,\ldots\,,\,\bD_n\models\beta$
        ~~~then~~~ $\bP,\bD_0,\,\ldots\,,\,\bD_n\models\alpha$.

\item   ~If~~ $\toracle(\bD_0,\bD_1) \models^c \alpha$
        ~~~then~~~ $\bP,\bD_0,\bD_1\models\alpha$.

\item   ~If~~ $\doracle(\bD_0) \models^c \alpha$
        ~~~then~~~ $\bP,\bD_0 \models \alpha$.
\end{enumerate}
%%
In the last two items, $\alpha$ is a first-order formula and
$\models^c$ denotes classical entailment.
\end{lemma}
%%
Note that the assertions in Lemma~\ref{lem-entails} deal with the
inference of two kinds of true statement.  On the one hand, items 4
and 5 infer truth directly from the transition oracle and the data
oracle.  Specifically, item 4 deals with elementary updates, and item
5 handles database queries.  On the other hand, items 1, 2, and 3
combine existing entailments to infer new truths.  Specifically, item
1 infers classical conjunctions; item 2 infers serial conjunctions;
and item 3 infers defined transactions.  Items 2--5 anticipate the
proof procedures given in Section~\ref{sec-proof}, and indeed, they
form the model-theoretic basis of these procedures.  Item 1 is the
basis for a wide class of dynamic constraints, such as those describe
in~\cite{trans-tr-95,trans-ictl94,trans-dbpl93}.

Also note that the case $n=0$ in Lemma~\ref{lem-entails} corresponds
to transactions that do not update the database, {\it i.e.}, that act
as queries.  In this case, items 1 and 2 collapse to the same form,
and classical and serial conjunction become identical.  In fact,
Lemma~\ref{lem-sat-state} leads immediately to the following result:


\begin{corollary}[Conjunctive Queries]
For any transaction base $\bP$, any database state $\bD$, and any
transaction formulas $\alpha$ and $\beta$,
\[
	\bP,\bD\models\alpha\And\beta
	~~~~\mbox{\it if and only if}~~~~
	\bP,\bD\models\alpha\otimes\beta
\]
\end{corollary}
%
Intuitively, this lemma says that the result of evaluating a
conjunctive query is the same whether the conjuncts are evaluated
sequentially or in classical fashion.  In fact, we can prove a
stronger result to show that in the absence of updates, serial
conjunction reduces to classical conjunction, serial disjunction
reduces to classical disjunction, and executional entailment reduces
to classical entailment.
%
%In the following lemma, recall that $\dO$ is the data oracle, and
%$\dO(\bD)$ is the set of formulas that are true of database state
%$\bD$.

\begin{lemma}[Relationship to Classical Logic]
\label{lem-reduce}
Let $\bP$ be a transaction base, and let $\bP^c$ be a set of
first-order formulas derived from $\bP$ be replacing each occurrence of
$\otimes$ by $\And$, and each occurrence of $\oplus$ by $\Or$.  Then,
for any first-order formula $\alpha$, and any database $\bD$,
\[
        \bP,\bD \models \alpha
        ~~~~\mbox{\it if and only if}~~~~
        \bP^c\,\union\,\dO(\bD) \,\models^c\, \alpha
\]
Moreover, in the special case of classical oracles
(Section~\ref{sec-oracles-ex}),
\[
        \bP,\bD \models \alpha
        ~~~~\mbox{\it if and only if}~~~~
        \bP^c\,\union\,\bD \,\models^c\, \alpha
\]
\end{lemma}




\subsection{Examples}
\label{sec-semantics-ex}

This section gives examples of executional entailment in \TR.  Each
entailment is derived using Lemma~\ref{lem-entails}.  The examples
themselves are based on Example~\ref{ex-robot}, in which a robot
simulator moves blocks around a table-top.  In fact, we assume that
the transaction base $\bP$ contains the following four rules, adapted
from that example:
%
\begin{mathlines}{l}
stackTwoBlocks(X,Y,Z) ~\la~ move(Y,Z)\otimes move(X,Y) \smallskip\\
move(X,Y) ~\la~ pickup(X)\otimes putdown(X,Y) \smallskip\\
pickup(X) ~\la~ isclear(X)\otimes on(X,Y)\otimes
                \del{on}(X,Y)\otimes\ins{isclear}(Y) \smallskip\\
putdown(X,Y) ~\la~ X \not = Y \otimes isclear(Y)\otimes
                \ins{on}(X,Y)\otimes\del{isclear}(Y)
\end{mathlines}


For simplicity, we assume in the examples that the databases are
relational, {\it i.e.}, sets of ground atoms (which is the case for
the majority of applications, including most ``blocks-world''
examples).  Likewise, we assume the oracles are relational (as defined
in Section~\ref{sec-semantics}).  Thus, the data oracle, $\doracle$,
makes all the atoms in the database visible.  That is,
\,\mbox{$\doracle(\bD) = \bD$}.\, In addition, the transition oracle,
$\toracle$, gives the intended meaning to atoms like $\ins{p}$ and
$\del{p}$.  That is, for any ground atom $p$, \,$\ins{p} \in
\toracle(\bD,\bD')$\, if and only if \,$\bD' = \bD + \{p\}$;\, and
similarly for $\del{p}$.  For instance,
%%
\begin{mathlines}{rcl}
\del{on}(a,b) & \in &
\toracle(\{on(a,b),on(b,c),isclear(a)\},~\{on(b,c),isclear(a)\})
\bigskip\\

\ins{isclear}(b) & \in &
\toracle(\{on(b,c),isclear(a)\},~\{on(b,c),isclear(a),isclear(b)\})
\bigskip\\

\del{isclear}(a) & \in &
\toracle{\{on(b,c),isclear(a),isclear(b)\},~\{on(b,c),isclear(b)\}}
\end{mathlines}
%%
for any blocks $a$, $b$, and $c$.

Finally, all actions in this section start from the following initial
database, representing an arrangement of three blocks where $blkA$ is
on top of $blkC$, which in turn is on $blkD$, and $blkB$ stands by itself:
\[
        \bD_0~=~\{isclear(blkA),isclear(blkB),on(blkA,blkC),on(blkC,blkD)\}
\]

\begin{example}{Picking up a block} \label{ex-pickup-a-block}
Starting from the initial database, $\bD_0$, we infer that the robot
can pick up $blkA$.  During the pickup action, the database passes
through an intermediate state, $\bD_1$, and ends up at state $\bD_2$,
where
\begin{mathlines}{l}
\bD_1~=~\{isclear(blkA),isclear(blkB),on(blkC,blkD)\} \sg
\bD_2~=~\{isclear(blkA),isclear(blkB),isclear(blkC),on(blkC,blkD)\}
\end{mathlines}
Here is the sequence of inferences.  The final inference, line 8,
states that the action $pickup(blkA)$ successfully takes the database
 from state $\bD_0$ to state $\bD_2$ via state $\bD_1$.
%%
\begin{enumerate}
\item
         $\bP,\bD_0 ~\models~ isclear(blkA)$,
      ~~ by item 5 of Lemma~\ref{lem-entails}. 
\item
         $\bP,\bD_0 ~\models~ on(blkA,blkC)$,
      ~~ by item 5 of Lemma~\ref{lem-entails}.
\item
         $\bP,\bD_0,\bD_1 ~\models~ \del{on}(blkA,blkC)$,
      ~~ by item 4 of Lemma~\ref{lem-entails}. 
\item
         $\bP,\bD_1,\bD_2 ~\models~ \ins{isclear}(blkC)$,
      ~~ by item 4 of Lemma~\ref{lem-entails}.
\item
         $\bP,\bD_0 ~\models~
                        isclear(blkA) \otimes on(blkA,blkC)$,
      ~~ by lines 1 and 2, and item 2 of Lemma~\ref{lem-entails}. 
\item
         $\bP,\bD_0,\bD_1 ~\models~ 
                        isclear(blkA) \otimes on(blkA,blkC)
                                    \otimes \del{on}(blkA,blkC)$, \\
        by lines 5 and 3, and item 2 of Lemma~\ref{lem-entails}. 
\item
         $\bP,\bD_0,\bD_1,\bD_2 ~\models~
                        isclear(blkA) \otimes on(blkA,blkC)
                                    \otimes \del{on}(blkA,blkC)
                                    \otimes \ins{isclear}(blkC)$, \\
      ~~ by lines 6 and 4, and item 2 of Lemma~\ref{lem-entails}.
\item
         $\bP,\bD_0,\bD_1,\bD_2 ~\models~ pickup(blkA)$,
      ~~ by line 7, the rule for {\it pickup\/},
                and item 3 of Lemma~\ref{lem-entails}.
\end{enumerate}
\end{example}


\begin{example}{Moving a block} \label{ex-entails2}
Starting from the initial state $\bD_0$, we infer that the robot can
move $blkA$ from $blkC$ to $blkB$.  In the process, the database
passes through three intermediate states, $\bD_1$, $\bD_2$ and
$\bD_3$, and ends up at state $\bD_4$.  Here,
\begin{mathlines}{l}
\bD_3 ~=~ \{isclear(blkA),isclear(blkB),isclear(blkC),on(blkA,blkB),on(blkC,blkD)\} \sg
\bD_4 ~=~ \{isclear(blkA),isclear(blkC),on(blkA,blkB),on(blkC,blkD)\}
\end{mathlines}
and states $\bD_0$, $\bD_1$, and $\bD_2$ are as before.  First, from
Example~\ref{ex-pickup-a-block}, we have the following:
\[
        \bP,\bD_0,\bD_1,\bD_2 ~\models~ pickup(blkA)
\]
In a similar fashion, it is not hard to show that
\[
        \bP,\bD_2,\bD_3,\bD_4 ~\models~ putdown(blkA,blkB)
\]
Thus, by item 2 of Lemma~\ref{lem-entails}, we get:
\[
        \bP,\bD_0,\bD_1,\bD_2,\bD_3,\bD_4 ~\models~ 
                                pickup(blkA) \otimes putdown(blkA,blkB)
\]
Finally, by the rule for $move$ and by item 2 of
Lemma~\ref{lem-entails}, we get:
\[
        \bP,\bD_0,\bD_1,\bD_2,\bD_3,\bD_4 ~\models~ move(blkA,blkB)
\]
and thus also $\bP,\bD_0 \dbseq \models move(blkA,blkB)$
and $\bP,\bD_0 \dbseq \bD_4 \models move(blkA,blkB)$.
\end{example}

\begin{example}{Stacking blocks} \label{ex-entails3}
By following the method of the previous two examples, we can build a
stack of three blocks, $blkC$, $blkA$ and $blkB$.  In particular, we
can infer the following statement:
\[
        \bP,\bD_0,\bD_1,\bD_2,\bD_3,\bD_4,\bD_5,\bD_6,\bD_7,\bD_8 
                                ~\models~ stackTwoBlocks(blkC,blkA,blkB)
\]
where $\bD_0, \ldots, \bD_4$ are as before, the state $\bD_8$ is
\[
         \{isclear(blkC),on(blkC,blkA),on(blkA,blkB),on(blkC,blkD)\}
\]
and $\bD_5 \ldots \bD_7$ are left to the reader.  As in
Example~\ref{ex-entails2}, each {\em move operation\/} causes four
state transitions.  Thus, during the stacking operation, the database
passes through seven intermediate states, $\bD_1$--\,$\bD_7$, to end
at state $\bD_8$.
\end{example}

The last example suggests that inference may require keeping track of
a long history of database states.  Fortunately, for a large and
important class of transactions, this is not necessary.  In fact, the
proof procedures presented in Section~\ref{sec-proof} record only the
current database state, $\bD_i$, advancing it from $\bD_0$ to $\bD_1$
$\ldots$ to $\bD_n$ as inference proceeds.



\subsection{Transaction Answers}
\label{def-semantics-answers}

So far, we have defined what it means for a formula to be true, which
allows us to perform transactions that return yes/no answers.  In databases,
however, we often want queries and transactions to
return a {\it set\/} of answers ({\it e.g.}, all employees who earn
more than \$100,000).

For queries, the solution is straightforward: As in classical logic,
we can define a {\it query\/} to be a first-order formula
$\phi(X_0,\,\ldots\,,\, X_k)$ with free variables $X_0,\,\ldots\,,\, X_k$.  The answer
to this query is the set of variable bindings that makes the formula
true.  That is, the answer is the following set of tuples:
\[
            \{\,\tuple{c_1,\,\ldots\,,\, c_k}
        ~~|~~ \bP,\bD\models\phi(c_1,\,\ldots\,,\, c_k) \}
\]
where each $c_i$ is a ground term.

For transactions, the situation is more complex.  Because
transactions are non-deterministic, the answer can depend on
non-deterministic choices made during transaction execution.  For
instance, continuing Example~\ref{ex-robot}, suppose we want our robot
to build stacks of blocks, and to return (as an answer) the names of
all blocks whose tops are clear {\it after\/} the stacks are built.  We do
not care what blocks are used to build the stacks, so long as these stacks
satisfy certain criteria (such as height and color).  In this
case, the particular blocks affected by the stacking operation is
non-deterministic (and is determined by the system at run time), so
the answer returned by the transaction is non-deterministic, too.

To make this example concrete, we define a specific stacking
operation by adding the following rule to the transaction base:
\[
        stack(X) \la move(Y,X) \otimes move(Z,Y)
\]
The procedure $stack(X)$ stacks two blocks on top of block $X$. First,
it chooses a block, $Y$, and puts it on $X$; then it chooses another
block, $Z$, and puts it on top of $Y$.  The final state of the
database is non-deterministic since the choices for the two blocks, $Y$
and $Z$, are non-deterministic.

Having defined this stacking operation, we ask the robot to stack two
blocks on top of $blkA$, and to return the set of blocks that are
clear after the operation is complete.  This transaction is expressed
by the following formula:
\begin{equation} \label{trans-stack1}
        stack(blkA) \,\otimes\, isclear(X)
\end{equation}
That is, first execute $stack(blkA)$, and then retrieve those values
of $X$ that make $isclear(X)$ true.  Note that the retrieved values
depend on the {\it final\/} database state, which is non-deterministic.

The answer to a transaction may depend on the {\it initial\/} state of
the database as well as the final state.  For example, we might ask
for those blocks $X$ that are clear {\it both\/} before and after the
stacking operation.  This transaction is expressed by the formula
\[
        isclear(X) \,\otimes\,stack(blkA) \,\otimes\, isclear(X)
\]
that retrieves the values of $X$ that make $isclear(X)$ true
in both the initial and the final states.

More generally, the answer to a transaction may depend on the {\it
intermediate} database states.  For example, we might ask the robot to
build two stacks, one after the other, and to return those blocks that
are clear in between the two stacking operations.  This transaction is
expressed by the following formula:
\[
        stack(blkA) \,\otimes\, isclear(X) \,\otimes\, stack(blkB)
\]
This formula commands the robot
to stack two blocks on $blkA$, then to retrieve those
blocks $X$ that are clear, and then to stack two blocks on $blkB$.
Note that here the answers may be different for different execution paths,
even if the initial and the final states of these paths are the same.

Thus, unlike database queries, the answer returned by a transaction is
not determined by the current database alone.  Instead, it may depend on the
entire execution path of the transaction.
Definition~\ref{def-trans}, below, captures this idea.
This simple definition is sufficient for our present purposes.  However, as
with database queries \cite{chandra80a},
this definition could be augmented with additional requirements, such
as computability and genericity.

\begin{definition}{Abstract Transactions} \label{def-trans}
An {\em abstract transaction\/} is a total mapping from {\em sequences\/}
of database states to sets
of tuples of ground terms.
\end{definition}

Note that database queries are captured by a special case of this
definition, the case of sequences of length 1.  This is appropriate
since queries are a special kind of transaction.

In \TR, transactions are specified by a
transaction base $\bP$ and a transaction formula $\psi(X_1,\,\ldots\,,\,
X_k)$ with free variables $X_1,\,\ldots\,,\, X_k$.  Specifically, these three
elements define an abstract transaction $\Psi$, where
%%
\begin{equation}\label{eq-ab-trans}
        \Psi(\DB_0,\,\ldots\,,\, \DB_n) ~=~
        \{\,\tuple{c_1,\,\ldots\,,\, c_k}~~|~~
    \bP,\bD_0,\,\ldots\,,\, \bD_n ~\models~ \psi(c_1,\,\ldots\,,\, c_k) \,\}
\end{equation}
%%
where each $c_i$ is a ground term, and each $\bD_i$ is a database.

It follows immediately from Definition~\ref{def-trans} that when
applied to an initial database, $\bD_0$, the answer returned by a
transaction is non-deterministic.  Indeed, from $\bD_0$, the
transaction may execute along any one of many possible paths, each
returning a different answer.  This idea is captured by the following
definition.

\begin{definition}{Transaction Answers} \label{def-answers}
Let $\Psi$ be an abstract transaction,
and let $\bD_0,\,\ldots\,,\, \bD_n$ be a sequence
of databases.  Then $\Psi(\bD_0,\,\ldots\,,\, \bD_n)$ is a possible answer to
$\Psi$ at state $\bD_0$.
\end{definition}

Of course, for many sequences of
databases, the set (\ref{eq-ab-trans})
will be empty.  The transaction does not execute
along these paths.  It only executes along a path that returns a
non-empty answer.  If the answer set is empty for every path, then the
transaction fails.


\subsection{Discussion}
\label{sec-discussion}

Entailment in \TR has certain subtle properties that may not be readily
seen from the examples so far.  Those examples focus on the special case in
which the Relational Oracle is used and rule-bodies of program rules are
sequences of atomic actions.  More generally, database states may be more
complex, involving arbitrary kinds of oracles, and the transaction base may
be an arbitrary transaction formula.  Furthermore, the transition oracle may
mention only a fraction of all possible database states.  In these cases,
entailment in \TR can display subtle and important properties.  This
section discusses some of them.


\subsubsection*{Classical Conjunction}

In Definition~\ref{def-query}, there may be more than one sequence
$\DB_0,\DB_1,\,\ldots\,,\,\DB_n$ that starts at $\DB_0$.  In this case,
transactions can succeed in many different ways.  This property has
two consequences worth mentioning, both concerning classical
conjunction.

First, although two transactions $\phi$ and $\psi$ may succeed
individually, their conjunction $\phi \And \psi$ may fail.  This is
possible because a conjunction requires all its conjuncts to execute
along the {\it same\/} path.

%\begin{example}{Classical Conjunction}
%\label{ex-entail1}
%Suppose the transition base $\cB$ consists of exactly the following
%two formulas (and no more):
%\[
%       \tuple{\DB_1~\DB_2}a ~~~~~~~~~~  \tuple{\DB_1~\DB_3}b
%\]
%where $\DB_2 \not\equiv \DB_3$.  Then the following statements are
%both true, for any transaction base $\bP$:
%\[
%\cB,\bP,\DB_1 \dbseq ~\models~ a ~~~~~~~~~~
%\cB,\bP,\DB_1 \dbseq ~\models~ b
%\]
%Thus, the transactions $a$ and $b$ both succeed from $\DB$, but they
%succeed along different paths.  Furthermore, if the transaction base contains
%no rules that infer $a$ or $b$, then $a$ and $b$ cannot execute along
%any other paths.  In particular, they cannot execute along the {\it
%same} path.  In this case, the following statement is {\em false\/}:
%\[ \cB,\bP,\DB_1 \dbseq ~\models~ a \And b \]
%\end{example}
%\medskip

The second consequence is closely related to the first: It is possible
that transactions $\psi$ and $\neg\psi$ may {\it both\/} succeed from
the same database.  Again, the reason is that $\psi$ may succeed along
one path, while $\neg\psi$ will succeed along another path.  The
resolution of this apparent inconsistency is that the transaction
$\psi\And\neg\psi$ always fails, since it is false on every path.

\begin{example}{Apparent Inconsistency}
\label{ex-inconsistency}
Consider a transition oracle that satisfies the following:
\[
       a \in \toracle(\DB_1,\DB_2) ~~~~~~~~~~ b\in \toracle(\DB_1,\DB_3)
\]
where $\DB_2 \not\equiv \DB_3$, and suppose that the transaction base,
$\bP$, contains the two rules \,$c \la a$\, and \,$\neg c \la b$.  Then
{\it both} the following statements are true:
\[
\bP,\DB_1 \dbseq ~\models~ c ~~~~~~~~~~ \bP,\DB_1 \dbseq ~\models~ \neg c
\]
But the following statement is {\it false\/}:~ 
$\bP,\DB_1 \dbseq ~\models~ c \And \neg c$.
\end{example}



\subsubsection*{Inconsistency}

The previous example discussed {\it apparent\/} inconsistencies in
\TR.  This section discusses {\it real\/} inconsistencies.  There are
three possible sources of inconsistency in \TR: the transaction base,
the oracles, and the interaction between the two.  We consider each in
turn.

The first, and simplest, source of inconsistency is the transaction
base $\bP$.  It may contain an inconsistent combination of formulas,
such as $\{b,~c,~\neg b \Or \neg c\}$.  There is only one
path-structure that satisfies such a transaction base---one that
assigns the special classical structure, $\top$, to every
path. Essentially, it is the user's responsibility to avoid this kind
of inconsistency, by writing consistent transaction bases.  This is
easily accomplished in practice, since modern database and logic
programming systems infer only positive facts.  They are therefore
guaranteed to be consistent.  Even the advanced examples considered
later in this paper, which go well beyond current technology, do not
infer negative facts, and so do not lead to inconsistency.

The second source of inconsistency is the oracles, which determine the
set of possible states and state transitions in the system.  In
principle, the oracles may define transitions to inconsistent database
states ({\it i.e.}, states where $\doracle(\bD)$ is classically
unsatisfiable), in which case, transactions may enter such states
during execution.  If $\bD$ is such a state, the only possible view
over it is $\top$, {\it i.e.}, $\ipath(\tuple{\bD})= \top$\, in
Definition \ref{def-structures}.  Since $\top$ satisfies all formulas,
any transaction entering an inconsistent state (or launched from such
a state) immediately succeeds, without any change of state.  Thus,
once a transaction enters an inconsistent state, future transactions
may not cause any state change at all.  In this sense, inconsistent
states act as ``black holes'' in the state space of \TR.  The
important point here is that inconsistency is ``localized;'' that is,
inconsistency in just one possible database state {\em does not\/}
spread to all possible database states, and, thus, inconsistent states
{\em do not\/} render the entire logic useless.

Even if the transaction base $\bP$ and the oracles are consistent by
themselves, they may not be consistent together.  This is the third,
and most subtle, source of inconsistency.  Suppose, for instance, that
the transaction base contains the formula $ c \la b$, and that the
current database state, $\bD$, contains the atom $b$ (assuming the
Classical Oracle).  Now suppose that we insert the atom $\neg c$ into
the database, making a transition to a state where both $b$ and $\neg
c$ is true.  From here, both $c$ and $\neg c$ are derived.  In this
case, the database ({\it i.e.}, the stored formula) is consistent, but
the view is not.  Again, if $\bD$ is such a state, the only possible
view over it is $\top$, and it will thus act as a black hole.

For a vast majority of practical applications, however, the above
situations do not arise because modern systems normally deal with positive
facts only.  For instance, for the situation just described, the transition
oracle would have to have elementary transitions that insert negative
literals into the database.  That is, it would have to have entries of the
form:
\[
        \ins{\,\neg c} \in
        \toracle(\bD,\bD+\{\neg c\})
\]
Such updates simply do not occur in modern relational database systems
or in classical logic programming systems.\footnote{
Of course, one may want to {\em delete\/} $c$, but this is radically
different from inserting $\neg c$.  The operation of deletion was called
{\em erasure\/} in \cite{katsuno-mendel-kr91}. For instance, erasure
(deletion) of $c$ from $\bD$ yields $\bD \Or \bD'$, where $\bD'$ is the
result of inserting $\neg c$ into $\bD$.  If $\bD$ is a set of Horn
clauses and $c$ is an atom whose predicate does not occur in the rule
heads, then erasure of $c$ yields $\bD - \{ c \}$.
}
Furthermore, as discussed above, logic programming systems do
not infer negative facts.  Thus, there is no way to insert or to
derive a negative fact, so inconsistency is impossible.  Even the
advanced examples considered later in this paper will not lead to
inconsistent views, since they do not infer negative facts.

In other applications, however, especially those in Artificial
Intelligence, the derivation of both positive and negative facts may be
important.  In such cases, inconsistency is possible, so users must be
careful not to build inconsistent knowledge-bases.  This is as true for
systems based on first-order logic and modal logic, as it is for systems
based on \TR.  Still, if inconsistency is expected to arise, it would be
important to ``localize'' its effects, so that it will not render the
entire knowledge-base useless.  Our use of $\top$ addresses this issue.
Inconsistency has been addressed in more sophisticated ways in work on
para-consistent logics. We mention, in particular, the works
\cite{subrahmanian-tcs-89,kifer-ri,kifer-apc}, since their ideas can be
applied to \TR without much difficulty.



\section{Proof Theory}
\label{sec-proof}

The model theory developed in Section~\ref{sec-semantics} provides a
{\it declarative\/} semantics for \TR.  In this semantics, every \TR
formula is an assertion about a dynamic world.  However, as pointed
out in Section~\ref{sec-procedural}, some \TR formulas also have a
{\it procedural\/} semantics, and so they can be interpreted as
programs.  In fact, like classical logic, \TR has a Horn-like subset,
called {\it serial-Horn\/} \TR, with a simple SLD-style proof theory
in which programs can be executed by proving theorems, in the
logic-programming tradition.  However, unlike classical logic
programming, the proof theory of serial-Horn \TR computes new database
states {\em as well as\/} query answers.  It is this property that
allows users to program database transactions within the logic.

This section defines the serial-Horn subset of \TR and develops its
proof theory.


\subsection{Serial Horn Programs}
\label{sec-serial-horn}

A \TR program consists of two kinds of logical formula: those provided
by the transaction base, $\bP$, which define transactions; and those
provided by the data oracle, $\doracle$, which define queries.  The
procedural semantics developed here requires both kinds of formula to
be Horn-like.  Specifically, they must satisfy
Definitions~\ref{def-serial-horn1} and~\ref{def-serial-horn2} below,
which characterize {\it serial-Horn} programs in \TR.


\begin{definition}{Serial-Horn Formulas} ~
\label{def-serial-horn1}
\begin{itemize}
\item
A {\em serial goal\/} is a transaction formula of the form $\,b_1
\otimes b_2 \otimes ...  \otimes b_n\,$, where each $b_i$ is an atomic
formula, and $n\geq 0$.  When $n=0$, we often write $(\,)$.

\item
An {\em existential serial goal\/} is a transaction formula of the
form $(\exists\overline{X})\phi$, where $\phi$ is a serial goal, and
$\overline{X}$ is a list of all free variables in $\phi$.

\item
A {\em serial-Horn rule\/} is a transaction formula of the form \,$b
\la \phi$,\, where $b$ is an atomic formula, and $\phi$ is a serial
goal.

\item
A {\em serial-Horn transaction base\/} is a finite set of serial-Horn
rules.
\end{itemize}
\end{definition}
%%
The following rules are all serial-Horn:
\[
        a(Y) \la b(Y) ~~~~~~~~~~
        a(X,Y) \la b(X,Y) \otimes c(X,Y) ~~~~~~~~~~
        a(X) \la b(X,Y) \otimes c(Y,Z) \otimes a(Z)
\]


A few comments on Definition~\ref{def-serial-horn1} are in order.
First note that if the atomic formulas $a_1\,$,...,$\,a_n$ do not
update the database, then the expression \,$a_1\otimes ...  \otimes
a_n$\, is equivalent to \,$a_1\And ... \And a_n$.  Thus, classical
Horn rules are a special case of serial-Horn rules.  Second, because
every serial goal, $\alpha$, is equivalent to $\alpha \otimes \state$,
the {\em empty\/} serial goal, $(\,)$, can be identified with
$\state$.  Finally, it is important to keep in mind that an
empty-bodied rule, $a \impl (\,)$, is equivalent to $a \impl \state$,
and {\em not\/} to the atomic formula $a$.  The former rule means that
$a$ is true {\em in every state}, while the latter atom means that $a$
is true {\em on every path}---not a very useful axiom, since we
already have $\ppath$, a proposition that is characterized precisely by
this property.  For that reason, it is meaningless to include
atoms-as-such in transaction bases; their absence also leads to a more
uniform proof theory.

To avoid the need to treat atoms $\state$, $\aarc$, and $\ppath$ specially in
our proof theory, we shall assume that they are defined by the oracles and
the transition base.  This assumption does not limit the generality, but it
simplifies the presentation significantly.  Specifically, we assume that
$\state$ is defined by the data oracle so that $\state \in \dO(\bD)$ for
every state identifier $\bD$, and $\state$ does not appear in the head of
any rule in the transaction base (and it is not modified by the transition
oracle).  Similarly, we can assume that $\aarc \in \toracle(\bD_1,\bD_2)$
for every pair of state identifiers, and that $\aarc$ is defined exclusively
by the transition oracle. Finally, $\ppath$ can be implemented by the
transaction base via the following rules:
%%
\[
        \ppath \la \state  ~~~~~~~~~~ \ppath \la \aarc \otimes \ppath
\]


\begin{definition}{Serial-Horn Conditions}
\label{def-serial-horn2}
A transaction base, $\bP$, a data oracle, $\dO$, and a transaction
formula (or query), $Q$, satisfy the serial-Horn conditions if:
%%
\begin{romanEnum}
\item
$\bP$ is a set of serial-Horn rules;

\item
$\doracle$ is a Generalized Horn Oracle;

\item
$Q$ is an existential serial goal; and

\item
$\doracle$ is {\em independent\/} of $\bP$, $i.e.$, for every database
state, $\bD$, no predicate symbol occurs both in a rule-head in $\bP$
and in a rule-body in $\doracle(\bD)$.
%%
\end{romanEnum}
\end{definition}


In this definition, Condition~(iv) intuitively says that database
views cannot be defined in terms of transactions.  For instance, if
the rule \,$b \la c$\, is in the transaction base, then the rule \,$a
\la b$\, {\it cannot\/} be in the database; although the rule \,$b \la
a$\, {\it can\/} be in the database.  Condition~(iv) arises naturally
in two situations: $(a)$ when the database is relational (a set of
ground atomic formulas), and $(b)$ when a conceptual distinction is
desired between updating actions and non-updating queries.  In the
former case, we can use the Relational Oracle, which is a special case
of a Generalized Horn Oracle.  In the latter case, the logic would
have two sorts of predicates, query predicates and action predicates.
Action predicates would be defined only in the transaction base, and
query predicates would be defined only in the database.  In this case,
the independence condition is satisfied with any Generalized Horn
Oracle.

The serial-Horn restrictions have a simple interpretation.  Primarily,
they are a demand for complete information: serial-Horn rules imply
that actions are completely specified, and generalized Horn oracles
imply that database states are completely specified, $i.e.$, do not
contain any indefinite or disjunctive information.  In addition, the
independence condition simplifies the interaction between the database
and the transaction base, and allows the state oracle to return rules
with negated premises.  Together, these restrictions lead to a simple
and practical, SLD-style inference system for action execution,
described below.

In contrast to the proof theory developed in this section, the model
theory developed in Section~\ref{sec-semantics} is completely general,
and does not depend on any syntactic restrictions.  If we were
interested only in the serial-Horn case, then the model theory of \TR
could be simplified~\cite{bonner-dbpl97-long,bonner-pods99-long}.  In
particular, we would only need to consider the satisfaction of
formulas on arcs (pairs of states) instead of on paths (sequences of
states).  In general, however, an arc-based semantics has severe
limitations.  For instance, it does not provide a useful
interpretation for the conjunction and the negation of transactions.
Furthermore, it does not permit the expression of constraints on
transaction execution (since intermediate states are not represented).
As a simple example, suppose that the predicate {\tt goto}$(L)$ is
defined by a serial-Horn program that intuitively means, ``Go to
location $L$.''  Then, the following non-Horn formula intuitively
means, ``Go to the kitchen without passing through the bedroom'':
%%
\[
{\tt goto} (kitchen) \And \neg (\ppath \otimes {\tt at} (bedroom) \otimes \ppath)
\]
%%
Observe that in addition to serial conjunction, this formula involves
classical conjunction, disjunction and negation.  The semantics of
such formulas is provided by the model theory developed in
Section~\ref{sec-semantics}, but the proof theory developed here does
not handle them, since it deals only with serial Horn rules.  Dynamic
constraints based on non-Horn formulas are described in detail
in~\cite{trans-tr-95,trans-ictl94,trans-dbpl93}.



\subsection{Two Inference Systems}\label{sec-two-systems}

Section~\ref{sec-semantics-ex} gave detailed examples of inference in
\TR in the serial Horn case.  These examples were all based on
Lemma~\ref{lem-entails}, and on items 2--5 in particular.  Each of
these items is, in effect, an inference rule; and taken together, they
form an inference system.  In fact, the system based on
Lemma~\ref{lem-entails} is sound and complete for the serial-Horn
case.\footnote{
  %%
  Item 1 of Lemma~\ref{lem-entails} is not needed here, since it deals with
  classical conjunction and thus goes beyond the serial-Horn case.  It is
  needed for constraints and is treated in more detail in
  \cite{mother-tl-92}.
%%
  }
%%
We call this simple system the {\it naive} inference system.
Conceptually, the naive system is simple and elegant, but it is not very
practical.  There are three reasons for this: $(i)$ it is a bottom-up
system, which does not take the query (transaction) into account, $(ii)$ it
is a {\it ground} inference system, one not based on unification, and
$(iii)$ it records and accesses the {\it history} of the database, not just
the current database state.  The first two points mean that the naive proof
theory is not an SLD-style inference system, like Prolog; and the third
point implies that enormous amounts of storage and disk access may be
required, as suggested by Example~\ref{ex-entails3}.

Fortunately, one can develop more practical inference systems.  This
section presents two such systems for the serial-Horn case.  These
systems are dual to each other and have many similarities.  For
instance, both systems are based on unification, both return most
general unifiers (mgu's) as answers to queries, both record only the
{\it current} database state, and both can be operated in either a
top-down or a bottom-up mode.  Both systems also have exactly three
inference rules, which is the minimum number possible, since separate
rules are needed to deal with elementary transitions, the transaction base,
and the database state.  The main difference between the two
systems is the kind of inferences they make.  In terms of
Definition~\ref{def-query}, one system makes inferences of the form
\,$\bP,\bD\dbseq\,\infers\,\psi$,\, while the other makes
inferences of the form \,$\bP,\dbseq\bD\,\infers\,\psi$.

In both systems, inference can be carried out in two natural ways:
top-down (starting at the goal) and bottom-up (starting at the
axioms).  These two modes of deduction correspond naturally to two
kinds of execution: forward execution of transactions (the normal
kind), and reverse execution ({\it i.e.}, starting from the current
state, and computing subsequent states by executing all updates in
reverse).  Furthermore, there is an interesting duality that connects
the two inference systems and the two modes of deduction: what one
system does bottom-up, the other does top-down.  This duality has
important consequences for implementation.  A logic-programming
system, for instance, is most naturally implemented as a top-down
system, where the query (or transaction) guides the inferences and
updates.  A database system, however, is most naturally implemented as
a bottom-up system, in order to minimize disk accesses.  The choice of
inference system may thus depend on the kind of software system being
built.

%While performing inference, both systems also execute transactions and
%update the database.  In fact, both systems can execute transactions
%in a ``forward'' and a ``reverse'' direction.  In the forward
%direction, the system treats $\bD$ as the initial database state, and
%computes the final state(s).  In the reverse direction, the system
%treats the $\bD$ as the final state, and computes the initial
%state(s).  Thus, the database may be moved forward or backward in
%time.  The direction of execution and update depends on which system
%is used and on whether it is operated in a top-down or a bottom-up
%mode.



\subsection{Inference System \IS}
\label{sec-inference1}

This section develops an inference system for verifying that
\,\mbox{$\bP,\bD_0\dbseq\models\psi$}.\, Informally, this
statement says that transaction $\psi$ can successfully
execute starting from state $\bD_0$.  The inference succeeds if and
only if it finds an execution path for the transaction $\psi$, that
is, a sequence of databases $\bD_1,\,\ldots\,,\, \bD_n$ such that
\,\mbox{$\bP,\bD_0,\bD_1,\ldots,\bD_n\models\psi$}.  As we shall
see, certain inference strategies generate the execution path in a way
that corresponds to the intuitive notion of transaction execution.  In
particular, top-down inference corresponds to normal execution, and
bottom-up inference corresponds to reverse execution.  We refer to the
inference system of this section as \IS.

Because we are dealing with the serial-Horn case, the transaction
$\psi$ is an existential serial goal, $i.e.$, a formula of the form
\,$(\exists\overline{X})\,(a_1 \otimes a_2 \otimes \ldots \otimes
a_m)$,\, where each $a_i$ is an atom.  Since {\em all\/} free
variables in $\psi$ are assumed to be existentially quantified, we
shall often omit the $\overline{X}$.  However, lest the existential
nature of transactions slip our mind, we often leave $(\exists)$ in
front of a transaction.  Note that this existential quantification is
consistent with the traditions of logic programming and databases.
The inference rules below all focus on the left end of such
transactions.  To highlight this focus, we write the rule-bodies as
$\phi\otimes rest$, where $\phi$ is the piece of the conjunction that
the inference system is currently focussed on, and $rest$ is the rest
of the conjunction.


Recall that a \TR theory comes with a data oracle, $\doracle$, and a
transition oracle, $\toracle$, which provide the semantics of
databases and elementary transitions, respectively (as described in
Sections~\ref{sec-syntax} and~\ref{sec-semantics}).  \IS invokes these
oracles to read and update the database.

\begin{definition}{Inference System \IS} \label{def-inference1}
If $\bP$ is a transaction base, then \IS is the following system of
axioms and inference rules, where $\bD$ and $\bD_i$ are any database
state identifiers.
%%
\begin{description}
\item[Axioms:]~~ $\bP,\bD\dbseq ~\infers~ (\,)$.

\item[Inference Rules:]
In Rules~1--3 below, $\sigma$ is a substitution, $a$ and $b$ are
atomic formulas, and $\phi$ and $rest$ are serial goals.
%%
\begin{description}

\item[1.~~{\it Applying transaction definitions:}] ~ \\
Suppose \,$a \la \phi$\, is a rule in $\bP$ whose variables have been
renamed so that the rule shares no variables with $b\otimes rest$.  If
$a$ and $b$ unify with mgu $\sigma$, then
%%
\medskip\newline
\begin{math}
\begin{array}{l}
\bP,\bD\dbseq ~\infers~ (\exists)\,(\phi \otimes rest)\sigma \\
\hline
\bP,\bD\dbseq ~\infers~ (\exists)\,(b \otimes rest)
\end{array}
\end{math}
\medskip

\item[2.~~{\it Querying the database:}] ~ \\
If \,$b\sigma$\, and \,$rest\,\sigma$\, share no variables, and
\,\mbox{$\doracle(\bD) \models^c (\exists)\, b\sigma$},\, then
%%
\medskip\newline
\begin{math}
\begin{array}{l}
\bP,\bD\dbseq ~\infers~ (\exists)\,rest\,\sigma \\
\hline
\bP,\bD\dbseq ~\infers~ (\exists)\,(b \otimes rest)
\end{array}
\end{math}
\medskip

\item[3.~~{\it Performing elementary updates:}] ~ \\
If \,$b\sigma$\, and \,$rest\,\sigma$\, share no variables, and
\,\mbox{$\toracle(\bD_1,\bD_2) \models^c (\exists)\, b\sigma$},\, then
%%
\medskip\newline 
\begin{math}
\begin{array}{l}
\bP,\bD_2\dbseq ~\infers~ (\exists)\,rest\,\sigma \\
\hline
\bP,\bD_1\dbseq ~\infers~ (\exists)\,(b \otimes rest)
\end{array}
\end{math}
%%
\end{description}
\end{description}
%%
\end{definition}
%%
This system manipulates expressions of the form
\,$\bP,\bD\dbseq\;\infers\;(\exists)\,\phi$,\, called {\it
sequents}.  The informal meaning of such a sequent is that the
transaction $(\exists)\,\phi$ can {\em succeed\/} from $\bD$, {\em
i.e.}, it can be executed on a path emanating from the database $\bD$,
{\it i.e.}, a path whose initial state is $\bD$.  Each inference rule
consists of two sequents, one above the other, and has the following
interpretation: If the upper sequent can be inferred, then the lower
sequent can also be inferred.  Based on the axiom-sequents, the system
uses the inference rules to infer more-and-more sequents.

In \IS, the axioms describe the empty transaction, ``$(\,)$''.  By
definition, this transaction does nothing and always succeeds.  That
is, if the user issues the command $\query (\,)$, then the database
simply remains in its current state.\footnote{
%%
  Model theoretically, ``$(\,)$'' corresponds to the special atom $\state$,
  which is true on every path of length 1.  In particular, it is true on
  the 1-path corresponding to any database $\bD$.
%%
  }
%%
The axioms formalize this behavior.

The three inference rules describe more complex transactions.  They
capture the roles of the transaction base, the data oracle, and the
transition oracle, respectively.  To understand these rules, it is
convenient to temporarily ignore the unifier, $\sigma$, and to assume
that $a$ is identical to $b$.  With this in mind, we can interpret the
rules as follows:
%%
\begin{enumerate}
\item
Inference rule~1 deals with defined transactions.  It says that if $b$
is defined by $\phi$, and if $\phi\otimes rest$ succeeds from $\bD$,
then $b \otimes rest$ also succeeds from $\bD$.  Intuitively, the rule
replaces a subroutine definition, $\phi$, by its calling sequence,
$b$.  This rule is a serial version of modus ponens.

\item
Inference rule~2 deals with tests ({\it i.e.}, queries), which do not
cause state changes.  It says that if $b$ is true at $\bD$, and if
$rest$ succeeds from $\bD$, then $b \otimes rest$ also succeeds from
$\bD$.  Intuitively, $b$ is a pre-condition that is satisfied by
$\bD$, and so it can be attached to the front of the transaction
$rest$.

%%We observe that one can remove all restrictions on the data oracle,
%%$\doracle$, imposed in the definition of Serial Horn programs, provided
%%that we strengthen the inference rule~2. Namely, instead of 
%%$\doracle(\bD) \models^c b$, we could  require
%%$(\doracle(\bD) \cup classic(\bP)) \models^c b$, where $classic(\bP)$ is
%%$\bP$ with all serial conjunctions, $\otimes$, replaced with classical
%%conjunctions, $\And$.
%%The completeness theorem, Theorem~\ref{thm-completeness1}, holds for this
%%latter system as well, and the proof is similar.

\item
Inference rule~3 deals with elementary updates.  It says that if $b$
changes database $\bD_1$ into $\bD_2$, and if $rest$ succeeds from
$\bD_2$, then $b \otimes rest$ succeeds from $\bD_1$.  Intuitively,
$b$ is attached to the front of $rest$, so that the resulting
transaction starts from $\bD_1$ instead of $\bD_2$.
\end{enumerate}
%%
Without the unifier $\sigma$, \IS would be sound and complete for
ground inference, that is, for the special case in which all queries
and transactions are ground.  Unification ``lifts'' inference from
ground transactions to transactions with free-variables, converting
the system into a more-practical, SLD-style system, one that returns
most-general-unifiers as answers, as Prolog does.  As in classical
resolution, any instance of an answer-substitution is a valid answer
to a query.  Our use of unification exploits the assumption that
transactions are existential.  In particular, for any substitution
$\sigma$, if \,$\bP,\bD\dbseq\infers\,(\exists)\,\phi\sigma$\, can
be inferred, then \,$\bP,\bD\dbseq\infers\,(\exists)\,\phi$\, can
also be inferred.  This idea is implicit in each inference rule.

For future reference, we remind the reader of the general notion of
deduction in an inference system:

\begin{definition}{General Deduction}\label{def-gen-deduction}
Given an inference system, a {\em deduction\/} (or {\em proof\/}) of a
sequent, $seq_n$, is a series of sequents, $seq_0,\, seq_1
,\,\ldots\,,\, seq_{n-1}, \, seq_n$, where each $seq_i$ is either an
axiom-sequent or is derived from earlier sequents by an inference
rule.
\end{definition}

In \IS, as in most inference systems, the main purpose of the proof
theory is to find deductions for a given sequent.  To reduce the
search space, many proof theories employ specialized inference
strategies.  Two well-known strategies are {\em bottom-up\/} and {\em
top-down\/} inference (also known as {\em forward-chaining\/} and {\em
backward-chaining\/}, respectively).  In the bottom-up mode, a
deduction is constructed by starting with the {\it first\/} sequent,
$seq_0$, which is an axiom, then applying an inference rule to derive
the second sequent, $seq_1$, then applying another inference rule to
derive the third sequent, $seq_2$, etc.  Bottom-up inference is
typical of database query processing.  In the top-down mode, a deduction
is constructed by starting with the {\it last\/} sequent, $seq_n$,
then applying an inference rule {\it in reverse\/} to derive the
second-last sequent, $seq_{n-1}$, then the third-last, etc, until an
axiom sequent is reached.  Top-down inference is typical of
logic-programming systems, like Prolog.  In \IS, top-down and
bottom-up inference have a special importance, since they correspond
closely to transaction execution, as we shall see.


\begin{theorem}[Soundness and Completeness of \IS]
\label{thm-completeness1}
~Under the serial Horn conditions, the executional entailment
~\mbox{$\bP,\bD\dbseq ~\models~ (\exists)\,\phi$}~ holds if and only
if there is a deduction in \IS of the sequent \mbox{$\bP,\bD\dbseq
~\infers~ (\exists)\,\phi$}.
\end{theorem}
%%
\begin{proof}
See Appendices~\ref{app.sound} and~\ref{app.complete}.
\end{proof}

\noindent
In this theorem, completeness relies on the serial-Horn conditions,
but soundness does not.  The inference system is sound for any
transaction base, any data oracle, any transition oracle, and any
query.  The theorem itself characterizes the inferences in \IS
model-theoretically in the serial-Horn case.

The examples below illustrate the inference system.  In these
examples, and in the rest of this paper, all deductions are drawn
vertically with the final sequent, $seq_n$ at the top, and the initial
sequent, $seq_0$, at the bottom.  With this convention, top-down
inference corresponds to building a deduction vertically from the top,
down; and bottom-up inference corresponds to building a deduction
vertically from the bottom, up.  To emphasize the direction of
inference, we often insert the word {\it if\/} into a deduction.
Here and in other examples, we assume the Relational Oracle.


\begin{example}{Query Processing} \label{ex-query1}
Suppose that the transaction base $\bP$ contains the following three
rules:
\[
         p \la q \otimes r
~~~~~~~~ q \la s \otimes t
~~~~~~~~ r \la u \otimes v
\]
Then the formula $p$ represents a yes/no query, one that is true when
the database contains the atoms $s,t,u,v$.  This can be seen from the
following deduction (where ``$(\exists)$'' has been omitted from the
queries, since they are variable-free):
%%
\begin{lines}{lll}
           & $\bP,\{s,t,u,v\}\dbseq ~\infers~ p$ \smallskip\\
{\it if}~~ & $\bP,\{s,t,u,v\}\dbseq ~\infers~ q \otimes r$
           & by inference rule~1, \smallskip\\
{\it if}~~ & $\bP,\{s,t,u,v\}\dbseq ~\infers~ s \otimes t \otimes r$
           & by inference rule~1, \smallskip\\
{\it if}~~ & $\bP,\{s,t,u,v\}\dbseq ~\infers~ t \otimes r$
           & by inference rule~2, \smallskip\\
{\it if}~~ & $\bP,\{s,t,u,v\}\dbseq ~\infers~ r$
           & by inference rule~2, \smallskip\\
{\it if}~~ & $\bP,\{s,t,u,v\}\dbseq ~\infers~ u \otimes v$
           & by inference rule~1, \smallskip\\
{\it if}~~ & $\bP,\{s,t,u,v\}\dbseq ~\infers~ v$
           & by inference rule~2, \smallskip\\
{\it if}~~ & $\bP,\{s,t,u,v\}\dbseq ~\infers~ (\,)$
           & by inference rule~2.
\end{lines}
This deduction succeeds because the bottom-most sequent is an axiom.
%%
\end{example}
\medskip

Example~\ref{ex-query1} illustrates a similarity between inference
system \IS and Prolog: operating top-down, both systems process
rule-premises from left to right.  Our inference system thus provides
a formal basis for the left-to-right aspect of Prolog's proof
strategy.  Of course, \IS does not even attempt to mimic certain
aspects of Prolog's operational semantics, such as the rule selection
strategy, for fear of becoming incomplete.

In the deduction of Example~\ref{ex-query1}, the database does {\it
not\/} change from one sequent to the next, because only inference
rules~1 and~2 are used.  In the next example, however, the database
{\it does\/} change, because inference rule~3 is used.

\begin{example}{Sequential Updates} \label{ex-sequential1}
Suppose that the database is propositional and that the transition oracle,
$\toracle$, defines inserts and deletes of single atoms.  Thus, for
every database state, $\bD$, and every atom, $d$, the transition oracle
satisfies the following:
\[
        \ins{d} \in \toracle(\bD, \bD + \{ d \})     \tab\tab
        \del{d} \in \toracle(\bD, \bD - \{ d \})
\]
Then the formula \,$\ins{b} \otimes \ins{c} \otimes \ins{d}$\,
represents an updating transaction, one that inserts $b$ into the
database, then $c$, and then $d$.  For instance, if the current
database state is $\{a\}$, then when the transaction executes, the
database changes from $\{a\}$ to $\{a,b\}$ to $\{a,b,c\}$ to
$\{a,b,c,d\}$.  This behavior is recorded in the following deduction:
\smallskip
\begin{lines}{lll}
           & $\bP,\{a\}\dbseq ~\infers~ 
             \ins{b} \otimes \ins{c} \otimes \ins{d}$~~ \smallskip\\
{\it if}~~ & $\bP,\{a,b\}\dbseq ~\infers~ \ins{c} \otimes \ins{d}$
           & by inference rule~3,  \smallskip\\
{\it if}~~ & $\bP,\{a,b,c\}\dbseq ~\infers~ \ins{d}$
           & by inference rule~3, \smallskip\\
{\it if}~~ & $\bP,\{a,b,c,d\}\dbseq ~\infers~ (\,)$
           & by inference rule~3. \smallskip
\end{lines}
This deduction succeeds because the bottom-most sequent is an axiom.
%As in Example~\ref{ex-query1}, this deduction can be constructed
%either top-down or bottom-up.
\end{example}


\subsubsection{Execution as Deduction}
\label{sec-exec-as-deduct}

Having developed the inference system we must remind ourselves
that our original goal was not so much proving statements of the form
\,$\bP,\bD\dbseq\,\models\,(\exists)\,\phi$,\, but rather of the
form
%%
\[
        \bP,\bD_0,\ldots,\bD_n~\models~(\exists)\,\phi
\]
%%
where $\bD_0$ is the initial database state, $i.e.$, the state at the
moment when transaction $(\exists)\phi$ began executing.  Note that at
this moment, the intermediate database states, \mbox{$\bD_1
,\,\ldots\,,\, \bD_{n-1}$}, and the final state, $\bD_n$, are still
{\em unknown}.  An important task for the inference system is to
compute these unknown states.  The general notion of deduction is not
tight enough to do this conveniently.  The problem is that a general
deduction may record the execution of many unrelated transactions.
Furthermore, these executions may be mixed up in a haphazard way, and
may start from different database states.


\begin{example}{General Deduction} \label{ex-haphazard}
The deductions from Examples~\ref{ex-query1} and~\ref{ex-sequential1}
can be interleaved to produce perfectly-valid general deductions.  The
following deduction interleaves the entire deduction from
Example~\ref{ex-sequential1} with the bottom four lines of the
deduction from Example~\ref{ex-query1}:
\begin{lines}{lll}
8.   & $\bP,\{s,t,u,v\}\dbseq ~\infers~ r$
     & by sequent 7. \smallskip\\
7.   & $\bP,\{s,t,u,v\}\dbseq ~\infers~ u \otimes v$
     & by sequent 4. \smallskip\\

6.   & $\bP,\{a\}\dbseq ~\infers~ 
        \ins{b} \otimes \ins{c} \otimes \ins{d}$~~
     & by sequent 5. \smallskip\\
5.   & $\bP,\{a,b\}\dbseq ~\infers~ \ins{c} \otimes \ins{d}$
     & by sequent 2. \smallskip\\


4.   & $\bP,\{s,t,u,v\}\dbseq ~\infers~ v$
     & by sequent 3. \smallskip\\
3.   & $\bP,\{s,t,u,v\}\dbseq ~\infers~ (\,)$
     & an axiom. \smallskip\\

2.   & $\bP,\{a,b,c\}\dbseq ~\infers~ \ins{d}$
     & by sequent 1. \smallskip\\
1.~~ & $\bP,\{a,b,c,d\}\dbseq ~\infers~ (\,)$
     & an axiom.
\end{lines}
This deduction interleaves the execution records of two transactions,
$r$ and $\ins{b}\otimes\ins{c}\otimes\ins{d}$.  Moreover, these two
executions start from different database states: $r$ starts from state
$\{s,t,u,v\}$, while $\ins{b}\otimes\ins{c}\otimes\ins{d}$ starts from
state $\{a\}$.  
\end{example}


Since we are interested in the execution of a particular transaction,
it is convenient to introduce a more specialized notion of deduction,
which we call {\it executional deduction}.  This notion defines a
narrower range of deductions than does
Definition~\ref{def-gen-deduction}, but without sacrificing
completeness.  Intuitively, an executional deduction has no extraneous
sequents: Each sequent contributes toward proving the final sequent.
An executional deduction thus proceeds directly from an axiom sequent,
$seq_0$, to a goal sequent, $seq_n$, without digressing toward other
goals.  One of the main characteristics of such deductions is that
they record the execution of a single transaction.  In particular, the
database states mentioned in the sequents correspond exactly to the
states the database passes through during transaction execution.


\begin{definition}{Executional Deduction}
\label{def-exec-deduction}
%%
Let $\bP$ be a transaction base.  An {\em executional deduction\/} of
a transaction, \mbox{$(\exists)\,\phi$}, is a deduction, \mbox{$seq_0
,\,\ldots\,,\, seq_n$}, that satisfies the following conditions:
%%
\begin{enumerate}
\item
The initial sequent, $seq_0$, is an axiom.
%
\item For $i > 0$, each sequent, $seq_i$, is obtained from the {\it
previous\/} sequent, $seq_{i-1}$, by one of the inference rules of
system \IS (i.e., $seq_{i-1}$ is the numerator of the rule, and
$seq_i$ is the denominator).
%
\item   
The final sequent, $seq_n$, has the form
\,\mbox{$\bP,\bD\,\dbseq~\infers ~(\exists)\,\phi$},\, for some
database $\bD$.
\end{enumerate}
\end{definition}
%%
The deductions in Examples~\ref{ex-query1} and~\ref{ex-sequential1}
are both executional.  Note how they record the execution of the
transactions, keeping track of any changes (or lack thereof) to the
database state.

Theorem~\ref{thm-completeness1} (soundness and completeness) remains
valid even if deductions are required to be executional.  However,
because we now have a stronger form of deduction, we can prove
stronger results about it.  Theorem~\ref{thm-completeness1}, for
instance, does not specify the execution path of the transaction.
With executional deduction, we can be specific about the path itself.

Intuitively, the execution path of a transaction is the sequence of
states that the database passes through during transaction execution.
Each state change is caused by an elementary state transition invoked
by the transaction during execution.  The execution path is not
difficult to extract from an executional deduction.  The key
observation is that system \IS applies elementary transitions exactly
when inference rule~3 is invoked.  Invoking this rule during inference
is the proof-theoretic analogue of executing an elementary transition.
Thus, to extract the execution path from an executional deduction, we
need only pick out those points in the deduction where inference
rule~3 was applied, as in Figure~\ref{fig-executional}.  Given the
arbitrary executional deduction in Figure~\ref{fig-executional}, we
define its {\it execution path\/} to be the sequence
$\bD_0\,\bD_1\,\bD_2\,\ldots\,\bD_n$.  Thus, in
Example~\ref{ex-sequential1}, the execution path is $\{a\}$,
$\{a,b\}$, $\{a,b,c\}$, $\{a,b,c,d\}$, and in Example~\ref{ex-query1},
it is $\{s,t,u,v\}$, a path of length 1. The next theorem provides a
model-theoretic meaning for execution paths.  It also connects the
idea of executional deduction with that of executional entailment,
given in Definition~\ref{def-query}.

\begin{figure}
\begin{center}
\begin{tabular}{llll}
m. &       & $\bP,\bD_0\dbseq\,\infers\,(\exists)\,\phi$ \\
   &       & ~~~~~~$\cdots$ \\
k+1. ~~~~ &     & $\bP,\bD_0\dbseq\,\infers\,(\exists)\,\psi_0$ \smallskip\\
k. & {\it if}~~ & $\bP,\bD_1\dbseq\,\infers\,(\exists)\,\phi_1$ 
           & by inference rule~3, \\
   &       & ~~~~~~$\cdots$ \\
j+1. &     & $\bP,\bD_1\dbseq\,\infers\,(\exists)\,\psi_1$ \smallskip\\
j. & {\it if}   & $\bP,\bD_2\dbseq\,\infers\,(\exists)\,\phi_2$
           & by inference rule~3, \\
   &       & ~~~~~~$\cdots$ \\
i+1. &     & $\bP,\bD_{n-1}\dbseq\,\infers\,(\exists)\,\psi_{n-1}$ \smallskip\\
i. & {\it if}   & $\bP,\bD_n\dbseq\,\infers\,(\exists)\,\phi_n$
           & by inference rule~3, \\
   &       & ~~~~~~$\cdots$ \\
0. &         & $\bP,\bD_n\dbseq\,\infers\,(\,)$ \\
\end{tabular}
\end{center}
\caption{Construction of an Executional Deduction in \IS~~~~~~}
\label{fig-executional}
%
\begin{quote}
\it This deduction involves $m$ inferences and \mbox{$m+1$} sequents,
where $0$ is the initial sequent, and $m$ is the final sequent.  The
deduction includes $n$ changes of state (where \mbox{$0 \leq n \leq
m$}), each carried out by inference rule 3, such as the inferences
from sequent $i$ to \mbox{$i+1$}, from sequent $j$ to \mbox{$j+1$},
and from sequent $k$ to \mbox{$k+1$} (where \mbox{$0 \leq i < j < k
\leq m$}).
\end{quote}
\end{figure}


\begin{samepage}
\begin{theorem}[Executional Soundness and Completeness of \IS]
\label{thm-completeness1-exec}
~Under the serial-Horn conditions, the executional entailment
~\mbox{$\bP,\bD_0,\bD_1,\ldots,\bD_n ~\models~ (\exists)\,\phi$}~
holds if and only if there is an executional deduction of
\,\mbox{$(\exists)\,\phi$}\, whose execution path is
\,\mbox{$\bD_0,\bD_1,\ldots,\bD_n$}.
\end{theorem}
\end{samepage}
%%
\begin{proof}
See Appendix~\ref{app-exec}.
\end{proof}

\noindent
As before, completeness relies on the serial-Horn conditions, but
soundness does not.


Using Theorem~\ref{thm-completeness1-exec}, the following two
statements can be added to Examples~\ref{ex-query1}
and~\ref{ex-sequential1}, respectively:
%%
\begin{mathlines}{l}
        \bP,\{s,t,u,v\} \,\models\, p \medskip \\
        \bP,\{a\},\{a,b\},\{a,b,c\},\{a,b,c,d\} \,\models\,
                \ins{b}\otimes\ins{c}\otimes\ins{d}
\end{mathlines}
%%
Notice that these statements make the entire history of the database
explicit, yet they are inferred by an inference system that makes only
a single database explicit.  Notice, too, that any executional
deduction can be constructed either top-down or bottom-up.


\subsubsection{Executing Transactions}
\label{sec-exec}

This section defines what it means to {\it execute\/} a transaction
formula in \TR, thus making precise a notion that we have used
informally until now.  In fact, we shall define two notions of
execution, which we call {\it normal\/} and {\it reverse\/} execution.
They correspond naturally to two forms of executional deduction:
top-down and bottom-up, respectively.

As mentioned earlier, given a database $\bD_0$ and a transaction
formula $(\exists)\,\psi$, we wish to prove the statement
\begin{equation} \label{eq-execute}
        \bP,\bD_0,\bD_1,\ldots,\bD_n~\models~(\exists)\,\phi
\end{equation}
for some sequence of databases, $\bD_1,\ldots,\bD_n$.  The important
point is that these latter databases are {\it unknown\/} at the outset
and must be computed during the proof.  The process of constructing
such a proof is called a {\it normal execution\/} of $(\exists)\,\phi$
with respect to $\bP$.  Thus, given the state $\bD_0$,
normal execution determines whether the transaction $(\exists)\,\phi$
can start from state $\bD_0$, and if so, it computes the successor
states, $\bD_1,\ldots,\bD_n$.  Intuitively, this computation
corresponds to updating the user's database from $\bD_0$ to $\bD_1$
$\ldots$ to $\bD_n$.

Figure~\ref{fig-executional} suggests a natural approach to normal
execution: Use top-down inference to prove the sequent
\,$\sequent{\bD_0}{(\exists)\,\phi}$.\, Note that this sequent, which
is the starting point for top-down inference, contains only known
quantities.  Furthermore, as the figure shows, by reasoning top-down,
the successor states are computed in order, from $\bD_1$ to $\bD_2$
$\ldots$ to $\bD_n$, thus carrying out a normal execution of the
transaction $(\exists)\,\phi$.  This can also be seen in
Example~\ref{ex-sequential1}, since by constructing the deduction in a
top-down fashion, a sequence of databases is computed, from the
initial state, $\{a\}$, through the intermediate states, to the final
state, $\{a,b,c,d\}$, thus carrying out a normal execution of the
transaction $\ins{b}\otimes\ins{c}\otimes\ins{d}$.  As these examples
show, top-down inference computes databases in the order $\bD_0$,
$\bD_1$ $\ldots$ $\bD_n$.  The reason for this behavior can be found
in inference rule~3: When this rule is applied in reverse, the
database is changed from $\bD_1$ to $\bD_2$, {\it i.e.}, from an earlier
state to a later state.  This is why top-down inference is well-suited
to normal execution.

There are other ways of using system \IS to perform normal execution.
However, none is as natural as top-down inference, and many are
impractical and involve huge amounts of unguided search.  Large search
spaces are often a problem in logic programming, but with updates, a
new dimension of search comes into play.  To illustrate, consider
bottom-up inference.  As Figure~\ref{fig-executional} shows, it begins
with the axiom-sequent \,$\sequent{\bD_n}{(\,)}$\, and ends with the
goal-sequent \,$\sequent{\bD_0}{(\exists)\,\phi}$.\, The axiom sequent
involves an {\it unknown\/} quantity, the final database state,
$\bD_n$.  Bottom-up inference cannot begin without a value for this
state.  To get around this problem, we could choose a value for
$\bD_n$ at random, and then try to verify the sequent
\,$\sequent{\bD_0}{(\exists)\,\phi}$\, using bottom-up inference.  If
the verification fails, we would choose another value for $\bD_n$ and
try again, repeating the process until we stumbled upon the correct
value of $\bD_n$ by chance.  This approach is obviously impractical.
It is clearly more practical to compute the new database states
directly from the initial state, as top-down inference does.

Not all top-down systems avoid the problem of having to know (or
randomly choose) the final database state.  For instance, although
\cite{manchanda-88,manchanda-phd} develop a logical language for
transactions, the inference system there requires that {\it both\/}
the initial and final database states be known {\it before\/}
inference can begin.  This restriction makes the inference system
impractical in any mode, be it top-down or bottom-up.\footnote{
Being aware of this problem, \cite{manchanda-88,manchanda-phd} develop an
{\em interpreter\/} that does not need to know the final state.  However,
this interpreter is not based on a proof theory and is incomplete, too.
}


\subsubsection{Reverse Execution}

So far, we have described how to execute transactions ``normally.''
However, it is also possible to execute them {\it in reverse}.  This
possibility leads to a strong duality between top-down and bottom-up
inference.

In reverse execution of $(\exists)\,\psi$, the current database is
$\bD_n$ and we wish to prove Statement~(\ref{eq-execute}) for some
sequence of databases, $\bD_0,\ldots,\bD_{n-1}$.  The important point
is that these latter databases are {\it unknown\/} at the outset and
must be computed during the proof.  The process of constructing such a
proof is called a {\it reverse execution\/} of $(\exists)\,\phi$ with
respect to $\bP$.  Thus, given the state $\bD_n$, reverse
execution determines whether the transaction $(\exists)\,\phi$ can
{\it terminate\/} at the state $\bD_n$, and if so, it computes the
predecessor states, $\bD_{n-1},\ldots,\bD_0$.  Intuitively, this
computation corresponds to updating the user's database in reverse,
from $\bD_n$ to $\bD_{n-1}$ $\ldots$ to $\bD_0$.

Bottom-up inference carries out reverse-execution just as naturally as
top-down inference carries out normal execution.  This duality can be
seen in Example~\ref{ex-sequential1}.  The deduction in this example
is correct no matter how it is constructed, top-down or bottom-up.  By
constructing it top-down, we start with the initial database, $\{a\}$,
and compute its successor states.  By constructing it bottom-up, we
start with the database $\{a,b,c,d\}$ and compute 
states in reverse order.

Figure~\ref{fig-executional} illustrates the general case.  In this
figure, bottom-up inference starts with the axiom sequent
\,$\sequent{\bD_n}{(\,)}$\, and works toward the goal-sequent
\,$\sequent{\bD_0}{(\exists)\,\phi}$.  Inference thus starts with a
known quantity, the state $\bD_n$, from which it computes 
other states in reverse order, from $\bD_{n-1}$ to $\bD_{n-2}$
$\ldots$ to $\bD_0$.  The reason for this behavior can be found in
inference rule~3: When this rule is applied, the database is changed
from $\bD_2$ to $\bD_1$, {\it i.e.}, from a later state to an earlier state.
This is why bottom-up inference is well-suited to reverse execution.
Bottom-up inference thus has the same advantage with reverse execution
that top-down inference has with normal execution: it starts with a
{\it known\/} database state.  Likewise, top-down inference now has
the disadvantage of starting with an {\it unknown\/} state, $\bD_0$.
It is thus impractical as a method of reverse execution.

Examples~\ref{ex-query1} and~\ref{ex-sequential1} illustrate other
aspects of top-down and bottom-up inference.  For instance, when
operated top-down, the inference system decomposes transactions from
left to right, that is, in the order of normal execution.  But, when
operated bottom-up, the system builds transactions up from right to
left, that is, in the order of reverse execution.  These observations
further illustrate the duality between the two modes of inference and
the two modes of execution.



\subsubsection{Example: Non-Deterministic Updates}
\label{sec-nondet2}

Having developed the proof theory, we can now apply it to more complex
examples.  This section examines the proof theory in the context of
non-deterministic transactions, that is, transactions that have more
than one possible outcome.

Using the same transition oracle as in
Example~\ref{ex-sequential1}, we consider a transaction base, $\bP$,
consisting of the following two rules:
\begin{eqnarray}
\label{proof-rule1}  p & \la & a \otimes \del{c} \\
\label{proof-rule2}  p & \la & b \otimes \del{d}
\end{eqnarray}
Here, the atoms $a$ and $b$ act as pre-conditions.  That is, $c$ is
deleted only if $a$ is true in the initial database state; and $d$ is
deleted only if $b$ is true in the initial state.  The behavior of
transaction $p$ thus depends on which pre-conditions are true.  If
neither pre-condition is true, then neither rule can execute, so the
transaction fails.  If only one pre-condition is true, then only one
rule can execute, so the transaction is deterministic.  If both
pre-conditions are true, then both rules can execute, so the
transaction is non-deterministic.  Formally, the latter possibility
means that there can be two proofs of $p$, each resulting in a
different final state of the database.  Here is a proof of
~$\bP,\{a,b,c,d\},\{a,b,d\}\,\models\,p$,\, a proof that uses
Rule~(\ref{proof-rule1}):
\begin{lines}{lll}
           & $\bP,\{a,b,c,d\}\dbseq~\infers~p$ \smallskip\\
{\it if}~~ & $\bP,\{a,b,c,d\}\dbseq~\infers~a\otimes\del{c}$
           & by inference rule~1, \smallskip\\
{\it if}~~ & $\bP,\{a,b,c,d\}\dbseq~\infers~\del{c}$
           & by inference rule~2, \smallskip\\
{\it if}~~ & $\bP,\{a,b,d\}\dbseq~\infers~(\,)$
           & by inference rule~3.
\end{lines}
Likewise, here is a proof of
~$\bP,\{a,b,c,d\},\{a,b,c\}\,\models\,p$,\, a proof that uses
Rule~(\ref{proof-rule2}):
\begin{lines}{lll}
           & $\bP,\{a,b,c,d\}\dbseq~\infers~p$ \smallskip\\
{\it if}~~ & $\bP,\{a,b,c,d\}\dbseq~\infers~b\otimes\del{d}$
           & by inference rule~1, \smallskip\\
{\it if}~~ & $\bP,\{a,b,c,d\}\dbseq~\infers~\del{d}$
           & by inference rule~2, \smallskip\\
{\it if}~~ & $\bP,\{a,b,c\}\dbseq~\infers~(\,)$
           & by inference rule~3.
\end{lines}
%%
This example shows that by generating all possible executional
deductions, we can enumerate all possible outcomes of a transaction.
Alternatively, by arbitrarily selecting a single deduction, we can
execute transactions non-deterministically.


\subsubsection{Example: Inference with Unification}
\label{sec-unify}

In the previous examples of this section, all the formulas were
propositional.  Being conceptually simple, these examples are a good
illustration of the basic ideas behind the proof theory.  However,
propositional formulas are not typical of either database queries or
logic programs.  This section shows how inference works in the
presence of variables.  In this case, the inference system returns a
substitution, as Prolog does.  The substitution specifies values of
the free variables for which the transaction succeeds.  The example
itself is similar to those in Section~\ref{sec-semantics-ex}, in which
a robot simulator moves blocks around a table top.  That section
illustrated naive inference, in which inferences are made blindly and
inefficiently, with no regard for the transaction actually requested
by the user.  In contrast, this section is concerned with the
efficient execution of a particular, user-specified transaction. For
comparison purposes, we rework Example~\ref{ex-pickup-a-block}.

We consider a transaction base, $\bP$, containing the following rule,
which describes the effect of picking up a block $X$:
\[
pickup(X) ~\la~ isclear(X)\,\otimes\, on(X,Y)\,\otimes\,
                \del{on}(X,Y)\,\otimes\,\ins{isclear}(Y)
\]
Suppose the user orders the robot to pick up a block, by typing
\,$\query pickup(X)$.  Since the block is left unspecified, the
transaction is non-deterministic.  The inference system attempts to
find a value for $X$ that enables the transaction to succeed, updating
the database in the process.  To illustrate, suppose the initial
database represents an arrangement of three blocks where $blkA$ is on
top of $blkC$, and $blkB$ stands alone.  As shown in
Example~\ref{ex-pickup-a-block}, if the robot picks up $blkA$, then
the database should be updated from state $\bD_0$ to $\bD_1$ to
$\bD_2$, where
%%
\begin{eqnarray*}
        \bD_0 & = & \{isclear(blkA),\,isclear(blkB),\,on(blkA,blkC)\} \\
        \bD_1 & = & \{isclear(blkA),\,isclear(blkB)\} \\
        \bD_2 & = & \{isclear(blkA),\,isclear(blkB),\,isclear(blkC)\}
\end{eqnarray*}

An executional deduction in which the robot picks up $blkA$ is shown
in the table below.  In this table, each sequent is derived from the
sequent immediately below by an inference rule, and the bottom-most
sequent is an axiom.  Each inference involves unifying the leftmost
atom in the transaction against either a database fact (returned by
the data oracle), a transaction name (defined in the transaction
base), or an elementary transition (returned by the transition
oracle).  For example, in deriving sequent 4 from sequent 3, the
inference system unifies the atom $isclear(X)$ in the transaction
against the atom $isclear(blkA)$ in the database, $\bD_0$.  In this
way, the system ``chooses'' to pick up $blkA$.  Likewise, in deriving
sequent 3 from sequent 2, the inference system unifies the atom
$on(blkA,Y)$ in the transaction against the atom $on(blkA,blkC)$ in
the database.  In this way, the system retrieves $blkC$, the block on
which $blkA$ is resting.  Note that each line in the table shows three
items: a numbered sequent, the inference rule used in deriving it from
the sequent below, and the unifying substitution.  The answer
substitution is obtained by composing all the unifiers, which yields
$\{X/blkA,\,Y/blkC\}$, and then projecting onto the substitution for
$X$, which yields $\{X/blkA\}$.  The operational interpretation of
this proof is that the robot has picked up $blkA$.
%%
\begin{center}
{\renewcommand{\arraystretch}{1.5}
\begin{math}
\begin{array}{|c|c|ll|}
\hline
{\rm Rule}     & {\rm Unifier} & & \# ~~~~~~~~~~~~{\rm Sequent} \\
\hline
1  &           & 5. & \bP,\bD_0\dbseq~\infers~(\exists)\,pickup(X) \\
2 & \{\}       & 4. & \bP,\bD_0\dbseq~\infers~
                  (\exists)\,\llparen isclear(X)\,\otimes\, on(X,Y)\,\otimes\,
                  \del{on}(X,Y)\,\otimes\,\ins{isclear}(Y)\lrparen~~ \\
2 & \{X/blkA\} & 3. & \bP,\bD_0\dbseq~\infers~
                  (\exists)\,\llparen on(blkA,Y)\,\otimes\,\del{on}(blkA,Y)\,\otimes\,
                      \ins{isclear}(Y)\lrparen \\
3 & \{Y/blkC\} & 2. & \bP,\bD_0\dbseq~\infers~
                 (\exists)\,\llparen\del{on}(blkA,blkC)\,\otimes\,\ins{isclear}(blkC)\lrparen\\
3 & \{\}       & 1. & \bP,\bD_1\dbseq~\infers~\ins{isclear}(blkC) \\
  & \{\}       & 0. & \bP,\bD_2\dbseq~\infers~(\,) \\
\hline
\end{array}
\end{math}
}
\end{center}
\bigskip

\subsubsection{The Role of the Oracles---Observations}
\label{sec-proof-transbase-observe}

Two aspects of the proof theory---both related to the data and
transition oracles---are worth mentioning.

As discussed in Section~\ref{sec-elem}, for each elementary update,
the transition oracle defines a binary relation on databases.  Since
this relation is infinite, any implementation of inference rule 3
would include an algorithm for enumerating the oracle.  Such
implementation of an infinite axiom base by an algorithm is akin to
algorithmic implementations of inference rules, such as the resolution
rule, which have no finite representation in classical logic.

In \IS, the enumeration algorithm would take an update $b$ and a
database state $D$ as input, and then it would enumerate all possible
successor states, {\it i.e.}, states, $D'$, such that $b \in
\toracle(D,D')$.  For instance, given $\ins{d}$ and $\{a,b,c\}$ as
input, the algorithm would return $\{a,b,c,d\}$ as output (assuming
the Relational Oracle).  Thus, procedures that perform elementary
updates are treated as black boxes that can be ``plugged into" the
inference system.

Non-enumerable transition oracles are easy to conceive, and they are
sometimes useful in practical programming languages, especially in the case
of data oracles.  For instance,
testing the emptiness of a predicate is a frequent operation in logic
programming, but, unfortunately, it is not recursively enumerable.  To
make use of such an operation in \TR, we could introduce a
predicate, $\empti{p}$, for each predicate $p$, where
$\empti{p} \in \doracle(\bD)$, if, and only if $p$
has an empty extension in $\bD$.  Since $\bD$ can be an arbitrary
logic program, this data oracle cannot be recursively enumerated.
Nevertheless, relying on the oracle,
Rule~3 of system \IS will effectively test for an empty relation
whenever an elementary update of the form $\empti{p}$ is encountered.
Notice that this is done in a completely monotonic way, without
invoking negation-as-failure, which is otherwise the standard logic-programming
solution.  Of course, in practice, transition oracles that are
non-$r.e.$ cannot be implemented.  In such cases, the algorithms that
attempt to enumerate the oracle would not always terminate,
or they would be defined only for a practical subset of databases
(such as relational or deductive databases), or approximation
algorithms could be used.  All of these approaches are easy to encode
as oracles, but are awkward or impossible to encode by other
declarative means.



\subsection{Inference System \ISS}
\label{sec-inference2}

We now develop an inference system, called \ISS, that is dual to
system \IS.  In \ISS, reverse execution is achieved via {\em
top-down\/} deduction, while normal transaction execution is obtained
via {\em bottom-up\/} deduction.  The new system manipulates sequents of
the form \,\mbox{$\bP,\dbseq\bD\,\infers\,\psi$}.  Intuitively,
such a sequent says that transaction $\psi$ can execute in the normal
direction along a path
{\it terminating\/} at database state $\bD$, or equivalently, that $\psi$
can execute in reverse {\it starting\/} from state $\bD$.  As with
system \IS, the ultimate goal of \ISS is to prove statements of the
form~(\ref{eq-execute}).  As before, different kinds of deduction
correspond to different kinds of execution, normal or reverse.

As in Section~\ref{sec-inference1}, we assume that the serial-Horn
conditions are satisfied.  Transaction $\psi$ is thus an existential
serial goal, $i.e.$, a formula of the form $(\exists)\,(a_1 \otimes
a_2 \otimes \ldots \otimes a_m)$, where each $a_i$ is an atom.  Unlike
\IS, though, \ISS focuses on the {\it right} end of a transaction.
We therefore represent transactions as $(\exists)\,(rest \otimes
\phi)$, where $\phi$ is the piece of the transaction that the
inference system is currently focussed on, and $rest$ is the part of
the rule-body preceding $\phi$.

Recall that a \TR theory comes with a data oracle, $\doracle$, and a
transition oracle, $\toracle$, which provide the semantics of
databases and elementary transitions, respectively (as described in
Sections \ref{sec-syntax} and \ref{sec-semantics}).  \ISS invokes
these oracles to read and update the database.


\begin{definition}{Inference System \ISS} \label{def-inference2}
If $\bP$ is a transaction base, then \ISS is the following system of
axioms and inference rules, where $\bD$ and $\bD_i$ are any database
state identifiers.
%%
\begin{description}
\item[Axioms:]~~ $\bP,\dbseq\bD ~\infers~ (\,)$.

\item[Inference Rules:]
In Rules~$1'$--$3'$ below, $\sigma$ is a substitution, $a$ and $b$ are
atomic formulas, and $\phi$ and $rest$ are serial goals.
%%
\begin{description}

\item[$1'$.~~{\it Applying transaction definitions:}] ~ \\
Suppose that \,$a \la \phi$\, is a rule in $\bP$ whose variables have
been renamed so that the rule shares no variables with $b\otimes
rest$.  If $a$ and $b$ unify with mgu $\sigma$, then:
%%
\medskip\newline
\begin{math}
\begin{array}{l}
\bP,\dbseq\bD ~\infers~ (\exists)\, (rest \otimes \phi)\sigma \\
\hline
\bP,\dbseq\bD ~\infers~  (\exists)\,(rest \otimes b)
\end{array}
\end{math}
\medskip

\item[$2'$.~~{\it Querying the database:}] ~ \\
If \,$b\sigma$\, and \,$rest\,\sigma$\, share no variables, and
\,\mbox{$\doracle(\bD) \models^c (\exists)\, b\sigma$},\, then
%%
\medskip\newline
\begin{math}
\begin{array}{l}
\bP,\dbseq\bD ~\infers~ (\exists)\,rest\,\sigma\\
\hline
\bP,\dbseq\bD ~\infers~  (\exists)\,(rest \otimes b)
\end{array}
\end{math}
\medskip

\item[$3'$.~~{\it Performing elementary updates:}] ~ \\
If \,$b\sigma$\, and \,$rest\,\sigma$\, share no variables, and
\,\mbox{$\toracle(\bD_1,\bD_2) \models^c (\exists)\, b\sigma$},\, then
%%
\medskip\newline 
\begin{math}
\begin{array}{l}
\bP,\dbseq\bD_1 ~\infers~ (\exists)\,rest\,\sigma \\
\hline
\bP,\dbseq\bD_2 ~\infers~ (\exists)\,(rest \otimes b)
\end{array}
\end{math}
%%
\end{description}
\end{description}
%%
\end{definition}
%%
As before, each inference rule consists of two sequents, one above the
other, and each means that if the upper sequent can be inferred, then
the lower sequent can also be inferred.  As with all logical inference
systems, \ISS can be operated in a top-down or a bottom-up mode.

These axioms and inference rules correspond closely to those of \IS.
In both systems, the axioms describe the empty transaction, $(\,)$, a
transaction that does nothing.  Likewise, Rules~1 and~$1'$ abstract a
transaction by replacing a sequence of atoms by a single atom; Rules~2
and~$2'$ extend a transaction by appending a test (or query) to it;
and Rules~3 and~$3'$ extend a transaction by appending an elementary
update to it.  An important difference between the two systems is in
the way updates are applied in Rule~$3'$: In going from the upper
sequent to the lower sequent, Rule~$3'$ moves the database from state
$\bD_1$ to state $\bD_2$, that is, from the current state to a {\it
later\/} state.  In contrast, in \IS, Rule~3 moves the database from
the current state to an {\it earlier\/} state.  Thus, when operated in
a bottom-up mode, \ISS executes transactions in a {\it forward\/}
direction, whereas \IS executes them in a {\it reverse\/} direction.
This is another way in which the two inference systems are dual.

The notion of deduction is the same for \ISS as for \IS.  The
definitions of normal and reverse execution need further adjustments,
though, as do the theorems of soundness and completeness.

\begin{theorem}[Soundness and Completeness of \ISS]
\label{thm-completeness2}
~Under the serial Horn conditions, the executional entailment
~$\bP,\dbseq\bD ~\models~ (\exists)\,\phi$~ holds if and only if there
is a (general) deduction in \ISS of the sequent $\bP,\dbseq\bD
~\infers~ (\exists)\,\phi$.
\end{theorem}
%%
\begin{proof}
Parallel to the proof of Theorem~\ref{thm-completeness1} presented in
Appendices~\ref{app.sound} and~\ref{app.complete}.
\end{proof}

The examples below illustrate the new inference system.  They
correspond to the examples of Section~\ref{sec-inference1} and use the
same transition oracle.  As in that section, we draw deductions
vertically with the final sequent, $seq_n$, at the top, and the
initial sequent, $seq_0$, at the bottom.  Thus, top-down and bottom-up
inference still correspond to building a deduction from top to bottom
and from bottom to top, respectively.

\begin{example}{Query Processing} \label{ex-query2}
As in Example~\ref{ex-query1}, suppose that the transaction base $\bP$
contains the following three rules:
\[
         p \la q \otimes r
~~~~~~~~ q \la s \otimes t
~~~~~~~~ r \la u \otimes v
\]
Then $p$ represents a yes/no query; it is true when
the database contains the atoms $s,t,u,v$.  This can be seen from the
following deduction (where ``$(\exists)$'' has been omitted from the
queries, since they are variable-free):
\begin{lines}{lll}
           & $\bP,\dbseq\{s,t,u,v\} ~\infers~ p$ \smallskip\\
{\it if}~~ & $\bP,\dbseq\{s,t,u,v\} ~\infers~ q \otimes r$
           & by inference rule~$1'$, \smallskip\\
{\it if}~~ & $\bP,\dbseq\{s,t,u,v\} ~\infers~ q \otimes u \otimes v$
           & by inference rule~$1'$, \smallskip\\
{\it if}~~ & $\bP,\dbseq\{s,t,u,v\} ~\infers~ q \otimes u$
           & by inference rule~$2'$, \smallskip\\
{\it if}~~ & $\bP,\dbseq\{s,t,u,v\} ~\infers~ q$
           & by inference rule~$2'$, \smallskip\\
{\it if}~~ & $\bP,\dbseq\{s,t,u,v\} ~\infers~ s \otimes t$
           & by inference rule~$1'$, \smallskip\\
{\it if}~~ & $\bP,\dbseq\{s,t,u,v\} ~\infers~ s$
           & by inference rule~$2'$, \smallskip\\
{\it if}~~ & $\bP,\dbseq\{s,t,u,v\} ~\infers~ (\,)$
           & by inference rule~$2'$,
\end{lines}
This deduction succeeds because the bottom-most sequent is an axiom.
\end{example}
\medskip

Notice that in Example~\ref{ex-query2}, the inference system focuses
on the right side of the query, whereas in Example~\ref{ex-query1}, it
focuses on the left side.  Thus, when operating in a top-down mode,
\ISS processes queries from right to left, whereas \IS processes them
from left to right.

Since the deduction in Example~\ref{ex-query2} uses inference
rules~$1'$ and~$2'$ only, the databases does not change during
inference.  In the next example, however, the deduction uses inference
rule~$3'$, so the database {\it does\/} change.  Notice that the
direction of update is {\it opposite\/} to that of system \IS.  This
is due to inference rules~3 and~$3'$, which update the database in
opposite directions.


\begin{example}{Sequential Updates}
\label{ex-sequential2}
As in Example~\ref{ex-sequential1}, the formula \,$\ins{b} \otimes
\ins{c} \otimes \ins{d}$\, represents an updating transaction, one
that inserts $b$ into the database, then $c$, and then $d$.  Thus, if
the current database state is $\{a\}$, then when the transaction
executes, the database changes from $\{a\}$ to $\{a,b\}$ to
$\{a,b,c\}$ to $\{a,b,c,d\}$.  This behavior can be seen in the
deduction below by reading it from bottom to top.  Alternatively, by
reading it from top to bottom, a reverse execution can be seen.
\begin{lines}{lll}
           & $\bP,\dbseq\{a,b,c,d\} ~\infers~ 
             \ins{b} \otimes \ins{c} \otimes \ins{d}$ \smallskip\\
{\it if}~~ & $\bP,\dbseq\{a,b,c\} ~\infers~ \ins{b} \otimes \ins{c}$
           & by inference rule~$3'$, \smallskip\\
{\it if}~~ & $\bP,\dbseq\{a,b\} ~\infers~ \ins{b}$
           & by inference rule~$3'$, \smallskip\\
{\it if}~~ & $\bP,\dbseq\{a\} ~\infers~ (\,)$
           & by inference rule~$3'$.
\end{lines}
This deduction succeeds because the bottom-most sequent is an axiom.
\end{example}
\medskip

As with system \IS, general deductions are not always as simple as
those in Examples~\ref{ex-query2} and~\ref{ex-sequential2}.  In
general, a deduction may record the execution of many transactions,
interleaved in a haphazard way.  Since we are interested in the
execution of single transactions, we again introduce the stronger
notion of {\em executional\/} deduction.  The deductions in
Examples~\ref{ex-query2} and~\ref{ex-sequential2} are both
executional.


\begin{definition}{Executional Deduction in \ISS}
\label{def-exec-deduction2}
~Let $\bP$ be a transaction base.  An
{\em executional deduction\/} of a transaction, $(\exists)\,\phi$, is
any deduction, $seq_0,\,\ldots\,,\,seq_n$, in \ISS that satisfies the
following conditions:
%%
\begin{enumerate}
\item
   The initial sequent, $seq_0$, has the form
        \,$\bP,\dbseq\bD'~\infers~(\,)$,\,
        for some database $\bD'$.
\item
   The final sequent, $seq_n$, has the form
        \,$\bP,\dbseq\bD~\infers~(\exists)\,\phi$,\,
        for some database $\bD$.
\item
    Each sequent $seq_i$, (for $i>0$), is obtained from
    the {\em previous\/} sequent, $seq_{i-1}$, by one of the inference rules
    of system \ISS ({\it i.e.}, $seq_{i-1}$ is the numerator of the rule
    and $seq_i$ is the denominator).
\end{enumerate}
\end{definition}
%%

Given an executional deduction for system \ISS,
Example~\ref{ex-sequential2} suggests a notion of execution path that
is similar to the corresponding notion for \IS.  Once again, the key
observation is that system \ISS applies elementary transitions exactly
when inference rule~$3'$ is invoked.  This time, however, we define
the execution path to go from the bottom to top of a deduction,
instead of the other way around.  To be more precise, consider an
arbitrary executional deduction in \ISS, as shown in
Figure~\ref{fig-executional2}.  We define the execution path of this
deduction to be the sequence $\bD_0,\bD_1,\bD_2,\ldots,\bD_n$.  Thus,
in Example~\ref{ex-sequential2}, the execution path is $\{a\}$,
$\{a,b\}$, $\{a,b,c\}$, $\{a,b,c,d\}$, and in Example~\ref{ex-query2},
it is $\{s,t,u,v\}$, a path of length 1.  

The common point in the notions of execution path for \IS and \ISS is
that, in both cases, the existence of an executional deduction, with a
corresponding execution path, $\bD_0,\bD_1 ,\,\ldots\,,\, \bD_n$, is
tantamount to the existence of the executional entailment
\,$\bP,\bD_0,\bD_1 ,\,\ldots\,,\, \bD_n ~\models (\exists)\,\phi$.
~Theorem~\ref{thm-completeness1-exec}, above, establishes this for
\IS, and Theorem~\ref{thm-completeness2-exec}, below, establishes it
for \ISS.  These theorems thus provide a model-theoretic meaning for
execution paths.  They also connect the idea of executional deduction
with that of executional entailment, given in
Definition~\ref{def-query}.


\begin{figure}
\begin{center}
\begin{tabular}{lll}
           & $\bP,\dbseq\bD_n\,\infers\,(\exists)\,\phi$ \\
           & ~~~~~~$\cdots$ \\
           & $\bP,\dbseq\bD_n\,\infers\,(\exists)\,\psi_n$ \smallskip\\
{\it if}~~ & $\bP,\dbseq\bD_{n-1}\,\infers\,(\exists)\,\phi_{n-1}$
           & by inference rule~$3'$, \\
           & ~~~~~~$\cdots$ \\
           & $\bP,\dbseq\bD_2\,\infers\,(\exists)\,\psi_2$
\smallskip\\
{\it if}   & $\bP,\dbseq\bD_1\,\infers\,(\exists)\,\phi_1$
           & by inference rule~$3'$, \\
           & ~~~~~~$\cdots$ \\
           & $\bP,\dbseq\bD_1\,\infers\,(\exists)\,\psi_1$ \smallskip\\
{\it if}   & $\bP,\dbseq\bD_0\,\infers\,(\exists)\,\phi_0$
           & by inference rule~$3'$. \\
           & ~~~~~~$\cdots$ \\
           & $\bP,\dbseq\bD_0\,\infers\,(\,)$
\end{tabular}
\end{center}
\caption{An Executional Deduction in \ISS~~~~~~~~}
\label{fig-executional2}
\end{figure}


\begin{samepage}
\begin{theorem}[Executional Soundness and Completeness of \ISS]
\label{thm-completeness2-exec}
~Under the serial Horn conditions, the following statements are
equivalent:
%%
\begin{enumerate}
\item   $\bP,\bD_0,\bD_1 ,\,\ldots\,,\, \bD_n ~\models ~(\exists)\,\phi$.
\item
        There is an executional deduction of \,$(\exists)\,\phi$
        in \ISS whose execution path is $\bD_0,\,\bD_1,\,\ldots\,,\,\bD_n$.
\end{enumerate}
\end{theorem}
\end{samepage}
%%
\begin{proof}
Parallel to the proof of Theorem~\ref{thm-completeness1-exec}
presented in Appendix~\ref{app-exec}.
\end{proof}


When applied to Examples~\ref{ex-query2} and~\ref{ex-sequential2},
Theorem~\ref{thm-completeness2-exec} says that the deductions in those
examples prove the following executional entailments, respectively:
%%
\begin{mathlines}{l}
        \bP,\{s,t,u,v\} \,\models\, p \medskip \\
        \bP,\{a\},\{a,b\},\{a,b,c\},\{a,b,c,d\} \,\models\,
                \ins{b}\otimes\ins{c}\otimes\ins{d}
\end{mathlines}


As with system \IS, we can execute transactions by constructing
executional deductions.  As Figure~\ref{fig-executional2} shows, by
constructing the deduction from bottom to top, the database is
systematically updated from $\bD_0$ to $\bD_1$ $\ldots$ to $\bD_n$.
This is {\it normal\/} execution.  Likewise, by constructing the
deduction from top to bottom, the database is systematically updated
from $\bD_n$ to $\bD_{n-1}$ $\ldots$ to $\bD_0$.  This is {\it
reverse\/} execution.  Example~\ref{ex-sequential2} illustrates why
transactions can be executed in both forward and reverse directions.
When operated bottom-up, system \ISS processes transactions from right
to left, that is, in the order of normal execution.  When operated
top-down, however, it processes transactions from left to right, the
order of reverse execution.




\section{Hypothetical Reasoning}
\label{sec-hypo}

Hypothetical queries play an important role in reasoning about
knowledge.  A frequently cited example comes from the British
Nationality Act, which states that, ``You are eligible for citizenship
if your father {\it would\/} be eligible {\it if\/} he were alive''
\cite{gabbay84}.  The reader is referred to \cite{bonner-tcs-90} for
numerous other examples of hypothetical queries.  Because of such
queries, it is often necessary to perform hypothetical updates as well
as real ones.  For instance, a game-playing program may reason as
follows: After performing some given series of actions, $\alpha$, does
the opponent's situation improve?  Observe that the actions mentioned
in this query are purely hypothetical and are {\it not\/} committed.
If the answer to the query is ``no,'' then the program could perform
action $\alpha$, at which point the action {\it is\/} committed.
Otherwise, the program could do further depth analysis and perform the
most favourable move that it finds.  By distinguishing between real
and hypothetical actions, this program combines reasoning about action
(planning, exploration of alternatives, etc) with actual execution of
actions (committing itself to a particular course of action).
%\TR the only logic we are aware of that can do {\it both\/} these
%things.

This section extends the syntax and the semantics of \TR to deal with
hypothetical actions.  Extension of the proof theory then follows.  The
last subsection discusses a number of applications of hypothetical
reasoning in \TR.


\subsection{Hypothetical Formulas}\label{sec-hypo-sem}

To express hypotheticals, we introduce a modal operator ``$\Diamond$''
({\em executional possibility\/}) and a closely related operator ``$\Box$''
({\em executional necessity\/}).  In modal terms, $\Diamond\,\phi$ means
that execution of $\phi$ is {\it possible\/} starting at the present state,
and $\Box\,\phi$ means that the execution of $\phi$ is {\it necessary\/} at
the present state.  Intuitively, ``necessity'' means that $\phi$ is the
only transaction that can succeed from the present state.  Formally, it
means that $\phi$ is executable along every path leaving the current state,
$\bD$.  Likewise, ``possibility'' means that $\phi$ is executable along
{\it some\/} path leaving the current state.

To define the meaning of the new operators formally, let ${\bf M} = \tuple
{U, \cF, \ipath}$ be a path structure, let $\bD$ be a state,
and let $\nu$ be a variable assignment.  Then
%%
\begin{itemize}
\item   ${\bf M} , \tuple{\bD} \models_\nu \Diamond \phi$~ if and only if  
        there is a path, $\pi$, starting at state $\bD$, such that
        ${\bf M} , \pi \models_\nu \phi$~ holds.
\item   ${\bf M} , \tuple{\bD} \models_\nu \Box \phi$~ if and only if
        for every path, $\pi$, starting at state $\bD$, it is the case that
        ${\bf M} , \pi \models_\nu \phi$.
\end{itemize}
%%
Here, $\tuple{\bD}$ is the path of length 1 containing state $\bD$.
From these definitions, it is easy to verify that the following
formulas are valid, {\it i.e.}, that they are true on every path of
every structure:
%%
\begin{equation} \label{eq-hypos}
\begin{array}{rclcrcl}
  \Diamond\Diamond\phi & \biimpl & \Diamond\phi 
        & ~~~~~~~~~~~~~~~~~~~~ &
                  \Diamond\Box\phi & \biimpl & \Box\phi \\
  \Diamond(\phi\Or\psi) & \biimpl & \Diamond\phi \,\Or\, \Diamond\psi 
        &                       &
                  \Box(\phi\And\psi) & \biimpl & \Box\phi \,\And\, \Box\psi \\
  \Diamond(\phi\And\psi) & \ra & \Diamond\phi \,\And\, \Diamond\psi 
        &                       &
                  \Box(\phi\Or\psi) & \la & \Box\phi \,\Or\, \Box\psi \\
  \Diamond(\phi\otimes\psi) & \ra & \Diamond\phi 
        &                       &
                  \Box(\phi\oplus\psi) & \la & \Box\phi\\
  \Diamond(\phi\otimes\psi) & \biimpl & \Diamond(\phi\otimes\Diamond\psi)
\end{array}
\end{equation}

Note that executional modalities hold at states, {\it i.e.}, over paths of
length 1 and so they do not cause any real state transitions.  This is
reflected formally by the following equivalence:
\[
        \state~\equiv~\Diamond \ppath
\]
where, as before, $\ppath$ is the special atom that is true on every
path, and $\state$ is the special atom that is true on every path of
length 1 ({\it i.e.}, at every state).  To see that this equivalence holds,
note that,
%\,$\bM,\tuple{\bD}\models\ppath$~ for any state $\bD$, and thus
%\,$\bM,\tuple{\bD}\models\Diamond\ppath$~ for any state $\bD$, {\it i.e.},
%\,$\bM,\pi\models\Diamond\ppath$~ for any path $\pi$ of length 1.  
by definition, $\Diamond \ppath$ is true {\it only\/} on paths of length 1.
Hence, \,$\bM,\pi\models\Diamond\ppath$~ if and only if ~$\pi$ is path of
length 1, {\it i.e.}, if and only if \,$\bM,\pi\models\state$.  It is shown
in Section~\ref{sec-satisfaction} that $\state$ cannot be expressed in \TR
without the operator of executional possibility.  Thus, this operator
increases the expressive power of our language.  Henceforth, we shall treat
$\state$ as an abbreviation for $\Diamond\ppath$.  In fact, since $\ppath$
is just an abbreviation for $\phi\Or\neg\phi$, for any $\phi$, we no longer
need any predefined atoms at all.

Unlike the standard modal operators, our ``$\Diamond$'' and ``$\Box$''
are not dual to each other in the normal sense; that is, \,$\Box\phi
\not\equiv \neg\Diamond\neg\phi$\, and \,$\Diamond\phi \not\equiv
\neg\Box\neg\phi$.  Instead, we have the following two equivalences:
\[
        \Box\phi~\equiv~\state\,\And\,\neg\Diamond\neg\phi
        ~~~~~~~~~~~~~~
        \Diamond\phi~\equiv~\state\,\And\,\neg\Box\neg\phi
\]
However, it is not hard to define new executional modalities,
$\blackDiamond$ and $\blackBox$, for which the usual duality holds.
They are based on the idea of a continuation path: a path $\pi'$ is a
{\it continuation\/} of path $\pi$ if and only if $\pi$ is a prefix of
$\pi'$.  Thus, $\tuple{\bD_1~\bD_2~\bD_3~\bD_4}$ is a continuation of
$\tuple{\bD_1~\bD_2}$.
%%
\begin{itemize}
\item   $\bM,\pi \models \blackDiamond \phi$~ if and only if 
        there is a continuation, $\pi'$, of $\pi$ such that
        $\bM,\pi' \models \phi$~ holds.
\item   $\bM,\pi \models \blackBox\phi$~ if and only if for
        every continuation, $\pi'$, of $\pi$, it is the case that
        $\bM,\pi' \models \phi$.
\end{itemize}
%%
It is not difficult to see that \,$\blackDiamond\phi \equiv \neg
\blackBox\neg\phi$\, and \,$\blackBox\phi \equiv \neg
\blackDiamond\neg\phi$.  \,The previous form of executional modalities can
now be expressed as follows: $\Diamond\phi \equiv \state \And \blackDiamond
\phi$,\, and $\Box\phi \equiv \state \And \blackBox \phi$.  However, the
proposition $\state$ itself cannot be expressed using these new modalities,
while it can with the old ones.  Therefore, the expressive power of the new
modalities is not the same.  The operators ``$\blackBox$'' and
``$\blackDiamond$'' are useful for reasoning about program execution, and
are related to the operator ``{\bf suff}'' in the version of Process Logic
described in \cite{process-log-82}.  In this paper, however, we shall
consider ``$\Diamond$'' and ``$\Box$'' only.



\subsection{Examples}

Using hypothetical modalities, we can express new kinds of conditions
on actions.  We give several examples involving the modality of
executional possibility, $\Diamond$, since it is the focus of the
proof theory developed later in this section.

As a simple example, suppose that a robot has two choices of action,
{\it goLeft} and {\it goRight}.  Also suppose that going right is
safer, but going left has greater potential rewards.  If we are
cautious, we might want to command the robot to go right if going left
could lead to a bad situation.  This can be done with the following
formula:
\[
	\Diamond ({\it goLeft} \otimes bad) \,\otimes\, {\it goRight}
\]

As another example, suppose the action $goto(Y)$ commands a robot to
go to position $Y$.  Using this predicate, the rule below defines a
more cautious version of the action, called {\it goCarefully}$(Y)$,
that commands the robot to go to position $Y$ but only if it can get
back to its original position without any harm.  Here, the atom
$at(X)$ means the robot is at position $X$, and the atom $ok$ means
the robot has not come to any harm.
\[
	{\it goCarefully}(Y)  ~\la~  at(X)
	  \,\otimes\, \Diamond [goto(Y) \otimes goto(X) \otimes ok]
	  \,\otimes\, goto(Y)
\]

The last two examples show the use of hypotheticals as action
pre-conditions; but they can also be used as post-conditions.  As an
example, consider the action $stack(N,X)$ in Example~\ref{ex-robot},
which commands a robot to stack $N$ blocks on top of block $X$.  As
described in the example, this is a non-deterministic action since the
robot may have many blocks to choose from.  Observe that the
particular blocks it chooses can restrict our future courses of
action.  For instance, if the robot uses up narrow blocks to build a
stack on top of a wide block, then it may not be able to build a
narrow stack in the future.  By using hypotheticals, we can specify
that we want to preserve certain options for the future.  For
instance, suppose we want to stack 5 blocks on top of block $b$ and
still have the option of stacking 3 blocks on top of block $d$.  The
following formula does exactly this:
\[
	stack(5,b) \,\otimes\, \Diamond stack(3,d)
\]


\subsection{Reverse Executional Modalities}

Before proceeding to the proof theory, we introduce yet another class of
executional modalities.  We call them {\em reverse\/} executional
modalities (or {\em retrospectives\/}).  Intuitively, a retrospective
formula $\phi\Diamond$ tests whether we {\it could have\/} executed $\phi$
to reach the current state.  Likewise, $\phi \Box$ tests whether we {\it
  must have\/} executed $\phi$ to reach the current state.

The semantics of the retrospectives is dual to that of the forward
executional modal formulas.  This duality is closely related to the duality
between normal and reverse execution of transactions introduced in
Section~\ref{sec-inference1}.  This connection will be seen clearly in the
proof theory in the next subsection.  To define the meaning of the
retrospectives formally, let ${\bf M} = \tuple {U, \cF, \ipath}$ be a path
structure, let $\bD$ be a state, and let $\nu$ be a variable assignment.
Then
%%
\begin{itemize}
\item   ${\bf M} , \tuple{\bD} \models_\nu \phi \Diamond$~ if and only if
        there is a path $\pi$ {\em ending\/} at state $\bD$ such that
        ${\bf M} , \pi \models_\nu \phi$~ holds.
\item   ${\bf M} , \tuple{\bD} \models_\nu \phi \Box$~ if and only if
        for every path $\pi$ ending at state $\bD$, it is the case that
        ${\bf M} , \pi \models_\nu \phi$.
\end{itemize}
%%
Again, $\tuple{\bD}$ is the path of length 1 made from state $\bD$.
The following valid formulas are analogous to (\ref{eq-hypos}):
%%
\begin{eqnarray*}
\begin{array}[t]{rcl}
  \phi\Diamond\Diamond & \biimpl & \phi\Diamond \\
  (\phi\Or\psi)\Diamond & \biimpl & \phi\Diamond \,\Or\, \psi\Diamond \\
  (\phi\And\psi)\Diamond & \ra & \phi\Diamond \,\And\, \psi\Diamond \\
  (\phi\otimes\psi)\Diamond & \ra & \psi\Diamond \\
  (\phi \otimes \psi)\Diamond & \biimpl & (\phi\Diamond \otimes \psi)\Diamond
\end{array}
~~~~~~~~~~~~~~~~~~~~
\begin{array}[t]{rcl}
  \phi\Box\Box            & \biimpl & \phi\Box \\
  (\phi\And\psi)\Box      & \biimpl & \phi\Box \,\And\, \psi\Box \\
  (\phi\Or\psi)\Box       & \la     & \phi\Box \,\Or\, \psi\Box \\
  (\phi\oplus\psi)\Box    & \la     & \psi\Box
\end{array}
\end{eqnarray*}


Retrospective formulas are not dual to each other in the usual sense, just
as forward executional modal operators are not.  However, we can define a
version of retrospectives that obeys duality, just as in the case of
forward executional modalities.


\subsection{Proof Theory for Executional Modalities}
\label{sec-proof-hypo}

Executional modalities are interesting in their own right, but in addition,
they bind together the two proof theories of Section~\ref{sec-two-systems},
systems \IS and \ISS.  We demonstrate this in stages.  First, we expand
system \IS so that it infers forward-executional modal formulas.  Likewise,
we expand system \ISS so that it infers retrospectives.  We then combine
the two into a single, unified inference system.


\subsubsection{$\Diamond$-Serial-Horn Programs}
\label{sec-Dserial-horn}

The first step is to generalize the idea of serial Horn rules to include
executional modalities.  The generalization allows the possibility
operator, $\Diamond$, in rules bodies, but not the necessity operator,
$\Box$.  This is analogous to allowing existential quantifiers in the
bodies of classical Horn rules, but disallowing universal quantifiers.  Our
extension of serial-Horn rules is thus called $\Diamond$-serial-Horn rules.
A {\em $\Diamond$-serial-Horn\/} rule is a formula of the form $a \impl
\phi$, where $a$ is atomic and $\phi$ is a {\em $\Diamond$-serial goal},
defined as follows:

\begin{definition}{$\Diamond$-Serial-Horn Goals}~
\label{def-D-serial-horn}
\begin{itemize}
\item   an atomic formula is a $\Diamond$-serial goal.
    
\item   if $\psi_1$ ... $\psi_k$ are $\Diamond$-serial-Horn goals,
        then so is $\psi_1 \otimes \cdots \otimes \psi_k$.
\item   if $\psi$ is a $\Diamond$-serial-Horn goal,
        then so are $\Diamond\psi$ and $\psi\Diamond$.
\end{itemize}
\end{definition}
%%
The following formulas are all $\Diamond$-serial-Horn goals:
\[
        a(X) \otimes b(X) ~~~~~~~~~~
        a(X) \otimes \Diamond b(X) ~~~~~~~~~~
        a(X)\Diamond \otimes b(X) ~~~~~~~~~~
        \Diamond a(X) \otimes b(X) \Diamond
\]
\[
        \Diamond \llparen a(X) \otimes \Diamond b(X)\lrparen ~~~~~~~~~~~~~~~~~~~~
        \llparen a(X) \otimes \Diamond(b(X) \otimes c(X)\Diamond)
              \otimes d(X)\lrparen\Diamond\Diamond
\]
%%
We define a {\em $\Diamond$-serial-Horn transaction\/} to be an
existentially quantified $\Diamond$-serial goal, which we write as
$(\exists)\,\phi$, where $\phi$ is a $\Diamond$-serial goal.  As a
special case, any serial-Horn transaction (or rule) is also a
$\Diamond$-serial-Horn transaction (or rule).  We define a {\it
$\Diamond$-serial-Horn program\/} to be any finite set of
$\Diamond$-serial-Horn rules.  The definition of data oracles needs no
modification, though we still require them to satisfy the conditions
of Definition~\ref{def-serial-horn2}, such as independence from the
transaction base, etc.

In the above definitions, we assume that special atoms $\state$,
$\aarc$ and $\ppath$ are implemented via the oracles and the
transaction base, as described in Section~\ref{sec-serial-horn}.  This
simplifies the theoretical development, but does not reduce the
expressive power of $\Diamond$-serial-Horn rules.


\subsubsection{Inference System \ISD}

We now present a proof theory that amalgamates our earlier inference
systems, \IS and \ISS, and that is sound and complete for $\Diamond$-serial
Horn programs.  The new system, called \ISD, has ten inference rules: the
six rules of systems \IS and \ISS, plus four new rules---4, $4'$ and 5,
$5'$---defined below.  The axioms for the new system are just the axioms
for \IS plus the axioms for \ISS.  Intuitively, \ISD combines normal
execution and reverse execution in a single inference system.  This
generality is needed since we have one form of executional modality for
forward execution and another for reverse execution.

Each of the four new rules is based on two ideas: $(i)$ combining two
executions from the same database state into a single serial execution, and
$(ii)$ treating one of the two executions as forward or backward.  Since
there are two kinds of execution (normal and reverse), executions can be
paired in four possible ways, which is why there are four new inference
rules.  For clarity, we divide these rules into two types.  Rule 4 extends
system \IS to include forward execution, and Rule $4'$ extends system \ISS
to include backward execution.  Rules 5 and $5'$ then combine these two
systems into a single system for arbitrary combinations of executional
modalities.

%%
\begin{description}
\item[\it Introduction of modalities:] ~
\\
Let $\sigma$ be a substitution, and $rest$ and $test$ be
a $\Diamond$-serial goal.  Then,
\medskip\\
        \begin{math}
            {\bf 4.}~~\myfrac
            {\textstyle \bP,\bD\dbseq~\infers~(\exists)\,test\,\sigma~~~~~~~~~
                        \bP,\bD\dbseq~\infers~(\exists)\,rest\,\sigma}
            {\textstyle  \bP,\bD\dbseq~\infers~
                                    (\exists)\,(\Diamond test) \otimes rest}
        \end{math}
        ~~~ if \,$test\,\sigma$\, and \,$rest\,\sigma$\, share no variables.
        \medskip\\
        \begin{math}
            {\bf 4'.}~~\myfrac
            {\textstyle \bP,\dbseq\bD~\infers~(\exists)\,rest\,\sigma~~~~~~~~
                        \bP,\dbseq\bD~\infers~(\exists)\,test\,\sigma}
            {\textstyle  \bP,\dbseq\bD~\infers~
                                     (\exists)\,rest \otimes (test \Diamond)}
        \end{math}
        ~~~ if \,$test\,\sigma$\, and \,$rest\,\sigma$\, share no variables.
\end{description}
%%
Intuitively, Rule 4 combines two normal executions into a single normal
execution, converting one execution into an executional possibility.
Likewise, Rule $4'$ combines two reverse executions into a single reverse
execution, converting one execution into a reverse executional modality.
We can also interpret these rules from the perspective of top-down
inference.  From this view, to execute \,$\Diamond test \otimes rest$,\,
Rule 4 separates the executional modality from the rest of the transaction,
and executes it separately, in the background.  Likewise, to execute
\,$rest \otimes test \Diamond$, Rule $4'$ separates the retrospective from
the rest of the transaction, and executes it separately.

The requirement that \,$test\,\sigma$\, and \,$rest\,\sigma$\, must share
no variables simplifies the proof theory.
% Tony, I commented this out because we have already made too many promises
%\footnote{
%  A more complex proof theory without this restriction will appear in
%\cite{trans-book}.}
%%
It implies that unification will involve only one sequent at a time.  In
terms of top-down SLD inference, it means that any variables common to
$test$ and $rest$ should be bound to ground terms before $test$ is
executed.  This kind of requirement is common in logic programming systems.
For example, Prolog systems often require that variables in negative goal
literal be bound to ground terms before the negative literal is executed.
Of course, unlike negation-as-failure, executional modality has a
well-defined, monotonic semantics, and there are no problems with recursion
through these modalities.

By adding rules 4 and $4'$ to inference systems \IS and \ISS, respectively,
we get two new inference systems, one for forward executional possibility
and one for the backward execution.  Taken together, Rules~1--4 are sound
and complete for $\Diamond$-serial-Horn transaction bases that use only the
forward executional modalities (where Rules~1--3 come from system \IS).
Likewise, inference Rules~$1'$--$4'$ are sound and complete for transaction
bases that use only the backward executional modalities (where
Rules~$1'$--$3'$ come from system \ISS).

Note that Rules~4 and $4'$ use different kinds of sequents.  One kind has
the form \,$\bP,\bD\dbseq\,\infers\,\phi$,\, as in inference system \IS.
Here, $\bD$ is the {\it initial\/} state in the execution of transaction
$\psi$.  The other kind of sequent has the form
\,$\bP,\dbseq\bD\,\infers\,\phi$,\, as in \ISS.  Here, $\bD$ is the {\it
  final\/} state in the execution of $\psi$.  So far, these two kinds of
sequents have been independent of each other, isolated in separate
inference systems.  However, to execute transactions that contain both both
types of executional modalities, we need both kinds of sequents.  This is
because the current database state can be both the {\it initial\/} state of
a forward execution, and the {\it final\/} state of a retrospective
execution.  The following inference rules capture this idea, integrating
the two kinds of sequents into a single inference system.
%%
\begin{description}
\item[\it Mixed introduction of modalities:] ~
\\
Let $\sigma$ be a substitution, and $rest$ and $test$ be
a $\Diamond$-serial goal.  Then,
\medskip\\
        \begin{math}
            {\bf 5.}~~\myfrac
            {\textstyle \bP,\dbseq\bD~\infers~(\exists)\,test\,\sigma~~~~~~~~
                        \bP,\bD\dbseq~\infers~(\exists)\,rest\,\sigma}
            {\textstyle  \bP,\bD\dbseq~\infers~
                                    (\exists)\,(test \Diamond) \otimes rest}
        \end{math}
        ~~~ if \,$test\,\sigma$\, and \,$rest\,\sigma$\, share no variables.
        \medskip\\
        \begin{math}
            {\bf 5'.}~~\myfrac
            {\textstyle \bP,\dbseq\bD~\infers~(\exists)\,rest\,\sigma~~~~~~~~
                        \bP,\bD\dbseq~\infers~(\exists)\,test\,\sigma}
            {\textstyle  \bP,\dbseq\bD~\infers~
                                    (\exists)\,rest \otimes (\Diamond test)}
        \end{math}
        ~~~ if \,$test\,\sigma$\, and \,$rest\,\sigma$\, share no variables.
\end{description}
%%
Intuitively, Rule 5 combines a reverse execution and a normal execution
into a single normal execution, converting the reverse execution to a
reverse modal formula.  Likewise, Rule $5'$ combines a reverse execution
and a normal execution into a single reverse execution, converting the
normal execution to a forward modality.  We can also interpret these rules
from the perspective of top-down inference.  From this view, to execute
\,$test \Diamond \otimes rest$,\, Rule 5 separates the retrospective from
the rest of the transaction, and executes it in reverse, but in the
background.  Likewise, to execute \,$rest \otimes \Diamond test$,\, Rule
$5'$ separates the modality from the rest of the transaction, and executes
it normally, but in the background.

In Definition~\ref{def-gen-deduction} we stated the general notion of
deduction.  Since this definition is applicable to any inference
system, it is applicable to \ISD in particular.  Using it, we can
state the following soundness and completeness result, which is
analogous to Theorem~\ref{thm-completeness1}.
\medskip

\begin{theorem}[Soundness and Completeness for \ISD]
\label{thm-completeness1-hypo}
If the $\Diamond$-serial-Horn conditions are satisfied, then
%%
\begin{itemize}
\item   
    ~$\bP,\bD\dbseq ~\models~ (\exists)\,\phi$~~
    if and only if there is a deduction in \ISD of the sequent
    ~$\bP,\bD\dbseq ~\infers~ (\exists)\,\phi$.
\item   
    ~$\bP,\,\dbseq\bD ~\models~ (\exists)\,\phi$~~
    if and only if there is a deduction in \ISD of the sequent
    ~$\bP,\,\dbseq\bD ~\infers~ (\exists)\,\phi$.
\end{itemize}
%%
\end{theorem}
%%
\begin{proof}
See Appendices~\ref{app-hypo-sound} and~\ref{app-hypo-complete}.
\end{proof}
\medskip


It is worth noting that with executional modalities it is possible to
reformulate our inference systems using only one type of sequent,
\,$\bP,\bD\,\infers\,\phi$.  \,These sequents correspond to statements of
the form \,$\bP,\bD_0,\ldots,\bD_n\models\phi$\, with $n=0$, as given in
Definition~\ref{def-query}.  The reformulation itself, which we leave as an
exercise for the reader, is made possible by the following result.


\begin{lemma}
If the $\Diamond$-serial-Horn conditions are satisfied, then
%%
\begin{itemize}
\item
~$\bP,\bD\dbseq\,\models\,(\exists)\,\phi$~~~
if and only if
~~~\,$\bP,\bD\,\models\,(\exists)\,\Diamond\phi$

\item
~$\bP,\dbseq\bD\,\models\,(\exists)\,\phi$~~~
if and only if
~~~\,$\bP,\bD\,\models\,(\exists)\, \phi\Diamond$

\end{itemize}
\end{lemma}


\subsubsection{Example: Executional Possibility}
\label{sec-ex-hypo}

This section gives an example of inference when real and hypothetical
updates are mixed in a single transaction.  The example, which uses
only one kind of sequent, also illustrates the use of inference rule
4.  Unlike the deductions of Section~\ref{sec-proof}, the deduction in
this section is not linear, but has a tree-like structure.

The example centers on the transaction \,$\query p \otimes \Diamond q
\otimes r$.  This transaction consists of three subtransactions, $p$,
$q$ and $r$, where first $p$ is executed, then $q$ is executed
hypothetically, and finally $r$ is executed.  Because $q$ executes
hypothetically, all its updates are rolled back before $r$ starts
executing.  Thus, $\Diamond q$ acts as a test, one that must be
satisfied before $r$ can execute.  In contrast, updates due to $p$ and
$r$ are not rolled back and have a permanent affect on the database,
{\it i.e.}, they are committed.

Execution of the transaction is recorded in the deduction below, which
we describe from a top-down perspective.  In this deduction, the
initial database is empty, and the transaction base contains the
following three rules:
\[
        p \la \ins{a}\otimes\ins{b} ~~~~~~~~~~~~
        q \la \ins{c}\otimes\ins{d}\otimes b \otimes d ~~~~~~~~~~~~
        r \la \ins{e}\otimes\ins{f}\otimes\ins{g}
\]
%%
Top-down deduction proceeds by first trying to execute $p$, just as in
system \IS.  Next, inference rule 4 is applied, which separates the
possibility test, $\Diamond q$, from the rest of the transaction:
\begin{lines}{lll}
           & $\bP,\{\}\dbseq~\infers~
              p \otimes \Diamond q \otimes r$ \smallskip\\
{\it if}~~ & $\bP,\{\}\dbseq~\infers~ 
              \ins{a}\otimes\ins{b}\otimes \Diamond q \otimes r$
           & by inference rule 1, \smallskip\\
{\it if}~~ & $\bP,\{a\}\dbseq~\infers~ 
              \ins{b}\otimes \Diamond q \otimes r$
           & by inference rule 3, \smallskip\\
{\it if}~~ & $\bP,\{a,b\}\dbseq~\infers~
              \Diamond q \otimes r$
           & by inference rule 3, \smallskip\\
{\it if}~~ & $\bP,\{a,b\}\dbseq~\infers~ q$ \\
{\it and}  & $\bP,\{a,b\}\dbseq~\infers~ r$
           & by inference rule 4.
\end{lines}
Notice how inference rule 4 has split the sequent 
\,$\bP,\{a,b\}\dbseq~\infers~\Diamond q \otimes r$
into two sequents.  Intuitively, one sequent
is for the execution of $q$, and the other is for the execution of
$r$.  The proof now splits into two branches, each proceeding exactly
as in inference system \IS.

\medskip

\noindent
\begin{tabular}{llll}
The branch for proving $q$:~~~~ &
           & $\bP,\{a,b\}\dbseq~\infers~ q$ \smallskip\\
                          &
{\it if}~~ & $\bP,\{a,b\}\dbseq~\infers~
               \ins{c}\otimes\ins{d}\otimes b \otimes d$
           & by inference rule 1, \smallskip\\
                          &
{\it if}~~ & $\bP,\{a,b,c\}\dbseq~\infers~
               \ins{d}\otimes b \otimes d$
           & by inference rule 3, \smallskip\\
                          &
{\it if}~~ & $\bP,\{a,b,c,d\}\dbseq~\infers~b \otimes d$
           & by inference rule 3, \smallskip\\
                          &
{\it if}~~ & $\bP,\{a,b,c,d\}\dbseq~\infers~d$
           & by inference rule 2, \smallskip\\
                          &
{\it if}~~ & $\bP,\{a,b,c,d\}\dbseq~\infers~()$
           & by inference rule 2.
\end{tabular}

\medskip

\noindent
\begin{tabular}{llll}
The branch for proving $r$:~~~~ &
           & $\bP,\{a,b\}\dbseq~\infers~r$ \smallskip\\
                          &
{\it if}~~ & $\bP,\{a,b\}\dbseq~\infers~
              \ins{e}\otimes\ins{f}\otimes\ins{g}$
           & by inference rule 1, \smallskip\\
                          &
{\it if}~~ & $\bP,\{a,b,e\}\dbseq~\infers~ \ins{f} \otimes \ins{g}$
           & by inference rule 3, \smallskip\\
                          &
{\it if}~~ & $\bP,\{a,b,e,f\}\dbseq~\infers~ \ins{g}$
           & by inference rule 3, \smallskip\\
                          &
{\it if}~~ & $\bP,\{a,b,e,f,g\}\dbseq~\infers~ ()$
           & by inference rule 3.
\end{tabular}

\smallskip

\noindent
Both branches terminate with an axiom sequent, so they both succeed,
and so the entire deduction succeeds.

Notice that the two branches both begin at the same database state,
$\{a,b\}$.  Thus, the branch for $r$ ignores all the updates carried
out by the branch for $q$.  Intuitively, this is because $q$'s updates
are hypothetical, and are thus rolled back before $r$ starts
executing.  Also note that the two branches end at different states,
$\{a,b,c,d\}$ and $\{a,b,e,f,g\}$.  However, only the latter state
is the result of committed updates, so it represents the new state of
the database after transaction execution.



\subsubsection{Example: Retrospectives}
\label{sec-ex-retro}

This section modifies the example of Section~\ref{sec-ex-hypo} so that
it combines real and retrospective updates in a single transaction.
The example also illustrates the use of inference rule 5 to change
from one kind of sequent to another.  Again, unlike the deductions of
Section~\ref{sec-proof}, the deduction in this section is not linear,
but tree-like.

The example centers on the transaction \,$p \otimes q \Diamond \otimes
r$.  This transaction consists of three subtransactions, $p$, $q$ and
$r$, where first $p$ is executed, then $q$ is executed
retrospectively, and finally $r$ is executed.  Because $q$ executes
retrospectively, all its updates are rolled back before $r$ starts
executing.  
%$q \Diamond$ thus acts as a test, one that must be
%satisfied before $r$ can execute.
In contrast, updates due to $p$ and $r$ are committed.

Execution of the transaction is recorded in the following
top-down deduction.  In this deduction, the
initial database is empty, and the transaction base contains the
following three rules:
\[
        p \la \ins{a}\otimes\ins{b} ~~~~~~~~~~~~
        q \la d \otimes b \otimes\del{d}\otimes\del{c} ~~~~~~~~~~~~
        r \la \ins{e}\otimes\ins{f}\otimes\ins{g}
\]
%%
Top-down deduction proceeds by first trying to prove $p$, just as in
system \IS.  Next, inference rule 5 is applied, which separates the
retrospective test, $q \Diamond$, from the rest of the transaction:
%%
\begin{lines}{lll}
           & $\bP,\{\}\dbseq~\infers~ p \otimes q \Diamond \otimes r$
              \smallskip\\
{\it if}~~ & $\bP,\{\}\dbseq~\infers~
              \ins{a}\otimes\ins{b} \otimes q \Diamond \otimes r$
           & by inference rule 1, \smallskip\\

{\it if}~~ & $\bP,\{a\}\dbseq~\infers~
              \ins{b} \otimes q \Diamond \otimes r$
           & by inference rule 3, \smallskip\\

{\it if}~~ & $\bP,\{a,b\}\dbseq~\infers~ q \Diamond \otimes r$
           & by inference rule 3, \smallskip\\

{\it if}~~ & $\bP,\dbseq\{a,b\}~\infers~ q$ \\
{\it and}  & $\bP,\{a,b\}\dbseq~\infers~ r$
           & by inference rule 5.
\end{lines}
Notice how inference rule 5 has split the fourth sequent (involving
\,$q \Diamond \otimes r$) into two, different-style sequents:
one is for the reverse execution of $q$, and the
other is for the normal execution of $r$.  The proof now splits into
two branches, one using inference system \ISS, and the
other using \IS. In this way, system
\ISD integrates \IS and \ISS in one system.


\medskip

\noindent
\begin{tabular}{llll}
The branch for proving $q$:~~~~ &
           & $\bP,\dbseq\{a,b\}~\infers~ q$ \smallskip\\
        &
{\it if}~~ & $\bP,\dbseq\{a,b\}~\infers~
              d \otimes b \otimes \del{d}\otimes\del{c}$
           & by inference rule $1'$, \smallskip\\
        &
{\it if}~~ & $\bP,\dbseq\{a,b,c\}~\infers~
              d \otimes b \otimes \del{d}$
           & by inference rule $3'$, \smallskip\\
        &
{\it if}~~ & $\bP,\dbseq\{a,b,c,d\}~\infers~ d \otimes b$
           & by inference rule $3'$, \smallskip\\
        &
{\it if}~~ & $\bP,\dbseq\{a,b,c,d\}~\infers~d$
           & by inference rule $2'$, \smallskip\\
        &
{\it if}~~ & $\bP,\dbseq\{a,b,c,d\}~\infers~()$
           & by inference rule $2'$.
\end{tabular}

\medskip

\noindent
\begin{tabular}{llll}
The branch for proving $r$:~~~~ &
           & $\bP,\{a,b\}\dbseq~\infers~r$ \smallskip\\
        &
{\it if}~~ & $\bP,\{a,b\}\dbseq~\infers~
              \ins{e}\otimes\ins{f}\otimes\ins{g}$
           & by inference rule 1, \smallskip\\
        &
{\it if}~~ & $\bP,\{a,b,e\}\dbseq~\infers~ \ins{f} \otimes \ins{g}$
           & by inference rule 3, \smallskip\\
        &
{\it if}~~ & $\bP,\{a,b,e,f\}\dbseq~\infers~ \ins{g}$
           & by inference rule 3, \smallskip\\
        &
{\it if}~~ & $\bP,\{a,b,e,f,g\}\dbseq~\infers~ ()$
           & by inference rule 3.
\end{tabular}

\noindent
Both branches terminate with an axiom sequent, so they both succeed,
and so does the entire deduction.

As in the previous subsection,
the branch for $r$ ignores all the updates carried
out by the branch that proves $q$, as $q$'s updates
are retrospective and thus are rolled back before $r$ starts
executing.  Likewise, the two branches end at different states,
$\{a,b,c,d\}$ and $\{a,b,e,f,g\}$, but only the latter state
is the result of committed updates, so it represents the new state of
the database after transaction execution.




\subsubsection{Execution as Deduction in \ISD}
\label{sec-hypo-exec-deduc}

According to Theorem~\ref{thm-completeness1-hypo}, inference system
\ISD allows us to prove statements of the form
 \,$\bP,\,\dbseq\bD\,\models\,(\exists)\,\phi$\, and
\,$\bP,\,\bD\dbseq\models\,(\exists)\,\phi$.  By themselves, these
statements tell us that a transaction succeeds from a given database
state, $\bD$; but they do {\it not\/} tell us what the resulting
database state is.  For this reason, we also want to prove statements
of the form
\begin{equation} \label{eq-execute2}
        \bP,\bD_0,\ldots,\bD_n\,\models\,(\exists)\,\phi
\end{equation}
In particular, given the initial state, $\bD_0$, or the final state,
$\bD_n$, we want to infer the other states.  Intuitively, this
corresponds to forward and reverse execution, respectively.

This problem also arose in the development of systems \IS and \ISS in
Section~\ref{sec-proof}.  There, we addressed the problem by defining
the notion of {\it executional deduction}.  The idea was to weed out
spurious sequents so that the execution path, $\bD_0,\ldots,\bD_n$,
could easily be extracted from a proof.  For systems \IS and \ISS,
this was easy because each inference rule has exactly one premise and
one consequent.  Executional deductions thus have a linear structure,
in which each sequent is derived from the one immediately preceding
it.

In system \ISD, things are more complex, because the new inference
rules in this system have {\it two\/} antecedents.  An executional
deduction is therefore structured as a {\it binary tree}.  In this
tree, each node is a sequent, where leaf nodes are axioms, and
internal nodes are derived from their children.  Intuitively, one
branch in this tree represents the execution of the committed portion
of the user's transaction.  Tributaries of this branch represent the
execution of hypothetical or retrospective subtransactions.

We now formalize these ideas, beginning with the following definition.
%%
\begin{definition}{Executional Deduction in \ISD}
\label{def-hyp-deduction}
Let $\bP$ be a transaction base.  An
{\em executional deduction\/} in \ISD of a transaction
$(\exists)\,\phi$ is a binary tree of sequents that satisfy the
following conditions:
%%
\begin{enumerate}
\item The root of the tree is a sequent of the form
        ~$ \bP, \bD\dbseq\,\infers\,(\exists)\,\phi$~ or
        ~$ \bP, \dbseq\bD\,\infers\,(\exists)\,\phi$,~ for some database
        $\bD$.

\item The leaves of the tree are axiom-sequents, {\it i.e.}, sequents of the
        form ~$ \bP, \bD' \dbseq\,\infers\,(\,)$~
        or ~$ \bP, \dbseq \bD'\,\infers\,(\,)$,~
        for some database $\bD'$.

\item Each non-leaf node can be derived from its children by applying
one of the inference rules of system \ISD; {\it i.e.}, the node is
the consequent of some rule for which the children are the
antecedents.
\end{enumerate}
\vspace{-.4cm}
\end{definition}
%%
It is not hard to see that any topological sort of the sequents in an
executional deduction yields a deduction in the general sense of
Definition~\ref{def-gen-deduction}.  The example deductions given in
Sections~\ref{sec-ex-hypo} and~\ref{sec-ex-retro} are both
executional.

A close examination of the inference rules of System \ISD reveals that
in each rule, the consequent involves a formula called $rest$.  This
is the committed part of the transaction, and in each rule, exactly
one antecedent involves this formula.  We call this antecedent the
{\it committed antecedent} of the rule.  For example, in inference
rules 1--3 and $1'$--$3'$, there is only one antecedent, and it is
committed.  In inference rules 4, $4'$ and 5, $5'$, there are two
antecedents, one is committed, and the other is hypothetical or
retrospective.

We can extend this idea to executional deductions.  First, in deriving
a node (sequent) from its children, we apply a single inference rule.
Exactly one of the children corresponds to the committed antecedent of
the rule.  We call it the {\it committed child\/} of the node.
Second, starting from the root of the binary tree, we trace a path to
a leaf by always moving from the current node to its committed child.
This defines a branch of the tree, which we call the {\it committed
branch}.  The leaf at the end of this branch is called the {\it
committed leaf}.  Intuitively, the committed branch describes a
sequence of permanent database updates, and the committed leaf
describes the final database state.  In contrast, tributaries of the
committed branch describe sequences of temporary updates.

The committed path for the deduction in Section~\ref{sec-ex-retro} is
given in Figure~\ref{fig-committed}.  The top-most sequent is the
root, and the bottom-most sequent is the committed leaf.  Reading the
path from top-to-bottom, we see an execution of $p$ followed by an
execution of $q$.  Notice that execution of the retrospective,
$q \Diamond$, is completely ignored.  This path is therefore almost
identical to the executional deduction for the non-hypothetical
transaction $p \otimes r$.
%%
\begin{figure}
\begin{lines}{ll}
$\bP,\{\}\dbseq~\infers~ p \otimes q \Diamond \otimes r$ \\
$\bP,\{\}\dbseq~\infers~
            \ins{a}\otimes\ins{b} \otimes q \Diamond \otimes r$ \\
$\bP,\{a\}\dbseq~\infers~\ins{b} \otimes q \Diamond \otimes r$
  & by inference rule 3, \\
$\bP,\{a,b\}\dbseq~\infers~ q \Diamond \otimes r$
  & by inference rule 3, \\
$\bP,\{a,b\}\dbseq~\infers~r$ \\
$\bP,\{a,b\}\dbseq~\infers~\ins{e}\otimes\ins{f}\otimes\ins{g}$ \\
$\bP,\{a,b,e\}\dbseq~\infers~ \ins{f} \otimes \ins{g}$
  & by inference rule 3, \\
$\bP,\{a,b,e,f\}\dbseq~\infers~ \ins{g}$
  & by inference rule 3, \\
$\bP,\{a,b,e,f,g\}\dbseq~\infers~ ()$
  & by inference rule 3.
\end{lines}
\caption{The Committed Branch of an Executional Deduction}
\label{fig-committed}
\end{figure}

Examining the inference rules, it is not hard to see that every
executional deduction has the following property: all sequents on the
committed branch have the same style---they are either all of the
form \,$\bP,\bD\dbseq\,\infers\,\phi$, \,as in system \IS, or
all of the form \,$\bP,\dbseq\bD\,\infers\,\phi$, \,as
in system \ISS.  In Figure~\ref{fig-committed}, for instance, the
sequents are all \IS-style.

It is now easy to define the notion of the execution path of a
deduction in \ISD.  Consider the committed branch of such a deduction.
From the above observation, we know that all sequents on this branch
have the same style.  If they are \IS-style sequents, then as in
\IS-executional deductions, the committed branch has the structure
depicted in Figure~\ref{fig-executional} of
Section~\ref{sec-exec-as-deduct}.  The execution path of this
deduction is $\bD_0,\bD_1,\bD_2,\ldots,\bD_n$ --- a sequence of states
picked out each time an inference is made via Rule~3.  Likewise, if
the sequents on the committed branch are \ISS-style, then the branch
has the structure depicted in Figure~\ref{fig-executional2}
(Section~\ref{sec-inference2}).  The execution path of this deduction
has the same form, $\bD_0,\bD_1,\bD_2,\ldots,\bD_n$, but the states
are picked out via Rule~$3'$.  Thus, for the committed branch in
Figure~\ref{fig-committed}, the execution path is
\[
        \{\},~\{a\},~\{a,b\},~\{a,b,e\},~\{a,b,e,f\},~\{a,b,e,f,g\}
\]

The next theorem relates the notion of execution path and the notion
of executional entailment (see Definition~\ref{def-query}).

\begin{theorem}[Executional Soundness and Completeness of \ISD]
\label{thm-completeness-hypo-exec}
Under the $\Diamond$-serial-Horn conditions, the following statements
are equivalent:
%%
\begin{enumerate}
\item   $\bP,\bD_0,\bD_1 ,\,\ldots\,,\, \bD_n ~\models~ (\exists)\,\phi$.
\item
        There is an executional deduction in \ISD of ~$(\exists)\,\phi$~
        whose execution path is $\bD_0,\bD_1,\ldots,\bD_n$.
\end{enumerate}
%%
\end{theorem}
%%
\begin{proof}
See Appendix~\ref{app-hypo-exec}.
\end{proof}


As an example, using the transaction base from Section~\ref{sec-ex-retro},
we can make the following statement:
\[
        \bP,\{\},\{a\},\{a,b\},\{a,b,e\},\{a,b,e,f\},\{a,b,e,f,g\}
        ~\models~ p \otimes q\Diamond \otimes r
\]

At this point, it is instructive to look at the special case in which
a transaction is purely hypothetical, {\it i.e.}, has the form
$\Diamond\phi$.  In such cases, the committed branch consists of
exactly two sequents, and the execution path consists of a single
database state.  Consider, for instance, the transaction
\,$\Diamond(\ins{b}\otimes\ins{c})$\, applied to the database $\{a\}$.
This defines the root of an executional deduction.  Using top-down
inference, we can generate the rest of the deduction.  The first step,
is to apply inference rule 4 with \,$test = \ins{b}\otimes\ins{c}$\,
and \,$rest = ()$.  This generates two children for the root.  In
fact, the entire deduction consists of the following two branches:
\begin{mathlines}{ll}
\bP,\{a\}\dbseq~\infers~\Diamond(\ins{b}\otimes\ins{c}) ~~~~~~~~ &
\bP,\{a\}\dbseq~\infers~\Diamond(\ins{b}\otimes\ins{c})
\\
\bP,\{a\}\dbseq~\infers~\ins{b}\otimes\ins{c} &
\bP,\{a\}\dbseq~\infers~()
\\
\bP,\{a,b\}\dbseq~\infers~\ins{c} &
\\
\bP,\{a,b,c\}\dbseq~\infers~() &
\end{mathlines}
The left-hand branch is hypothetical, and the right-hand branch is
committed.  From the committed branch, we see that the execution path
consists of the single state $\{a\}$.  Thus, using
Theorem~\ref{thm-completeness-hypo-exec}, we can make the following formal
statement:
\[
        \bP,\{a\}~\models~\Diamond(\ins{b}\otimes\ins{c})
\]
Because the execution path consists of just a single state,
hypothetical transactions leave the database unchanged.



\subsubsection{Normal and Reverse Execution in \ISD}
\label{sec-exec-hypo}

We are now in a position to extend the ideas of section~\ref{sec-exec}
to system \ISD.  That is, we can define what it means to execute a
$\Diamond$-serial-Horn transaction, thus making precise a notion that
we have been using informally in this section.

As mentioned earlier, given a database $\bD_0$ and a transaction
formula $(\exists)\,\psi$, we wish to prove the statement
\begin{equation} \label{eq-execute3}
        \bP,\bD_0,\bD_1,\ldots,\bD_n~\models~(\exists)\,\phi
\end{equation}
for some sequence of databases, $\bD_1,\ldots,\bD_n$.  The important
point is that these latter databases are {\it unknown\/} at the outset
and must be computed during the proof.  The process of constructing
such a proof is called a {\it normal execution\/} of $(\exists)\,\phi$
with respect to $\bP$.  Thus, given the state $\bD_0$,
normal execution determines whether the transaction $(\exists)\,\phi$
can start from state $\bD_0$, and if so, it computes the successor
states, $\bD_1,\ldots,\bD_n$.  Intuitively, this computation
corresponds to updating the user's database from $\bD_0$ to $\bD_1$
$\ldots$ to $\bD_n$.

Likewise, {\it reverse execution\/} is the process of constructing a
proof of (\ref{eq-execute3}) when $\bD_n$ is known at the outset and
$\bD_0,\ldots,\bD_{n-1}$ are unknown.  Reverse execution thus
determines whether the transaction $(\exists)\,\phi$ can {\it
terminate\/} at state $\bD_n$, and if so, it computes the predecessor
states, $\bD_0,\ldots,\bD_{n-1}$.  Intuitively, this computation
corresponds to updating the user's database in reverse, from $\bD_n$
to $\bD_{n-1}$ $\ldots$ to $\bD_0$.

Inference system \ISD can execute $\Diamond$-serial-Horn transactions
normally and in reverse.  All that is needed is to construct an
executional deduction of the transaction, from which the execution
path can be extracted.  In practice, the direction of execution will
depend on how the committed branch is constructed, top-down or
bottom-up.  For instance, if the user's current database is empty, and
if the branch in Figure~\ref{fig-committed} is constructed from the
top, down, then the transaction $p \otimes \Diamond q \otimes r$ is
executed normally, updating the database from $\{\}$ to
$\{a,b,e,f,g\}$.  On the other hand, if the user's current database is
$\{a,b,e,f,g\}$, and if the branch in Figure~\ref{fig-committed} is
constructed from the bottom, up, then the transaction is executed {\it
in reverse}, updating the database from $\{a,b,e,f,g\}$ to $\{\}$.
These ideas were discussed in greater detail in Section
\ref{sec-exec}.

In Figure~\ref{fig-committed}, the committed branch involves sequents
of the form \,$\bP,\bD\dbseq\,\infers\,\phi$.  ~However, if the
committed branch contained sequents of the other form,
\,$\bP,\dbseq\bD\,\infers\,\phi$, then a dual relationship would
hold between the directions of inference and execution.  
That is, top-down inference would naturally correspond to reverse execution,
and bottom-up inference would naturally correspond to normal
execution.  Thus, as in Section~\ref{sec-proof}, the following
properties are closely related: $(i)$ the style of sequent on the
committed branch, $(ii)$ the direction of inference on the committed
branch, and $(iii)$ the direction of execution.  The exact
relationship is summarized in the table below.

\begin{center}
\renewcommand{\arraystretch}{1.2}
\begin{tabular}{|c|c|c|}
\hline
Sequent Style & Inference Direction & Execution Direction \\
\hline
$\bP,\bD\dbseq\,\infers\,\phi$     & top-down  & forward \\
$\bP,\bD\dbseq\,\infers\,\phi$     & bottom-up & reverse \\
$\bP,\dbseq\bD\,\infers\,\phi$     & top-down  & reverse \\
$\bP,\dbseq\bD\,\infers\,\phi$     & bottom-up & forward \\
\hline
\end{tabular}
\end{center}

There is a subtlety about inference in \ISD that should be pointed out:
Although the committed branch of a deduction may be constructed in a
top-down or a bottom-up manner, all tributaries of this branch ({\it i.e.},
its side branches) must be computed top-down in any practical system.  The
reason for this is quite simple.  In \ISD, an executional deduction is a
tree.  Constructing this tree bottom-up means starting at the leaves and
building up towards the root.  However, before starting this process, we
must know what sequent is at every leaf of the tree.  Knowing this is a
practical impossibility.  In practice, we will know only the current
database state, $\bD$, and the user's transaction, $\phi$.  This knowledge
is enough to specify only four sequents, the goal sequents
\,$\bP,\bD\dbseq\,\infers\,\phi$\, and \,$\bP,\dbseq\bD\,\infers\,\phi$,
\,and the axiom sequents \,$\bP,\bD\dbseq\,\infers\,()$\, and
\,$\bP,\dbseq\bD\,\infers\,()$.  ~In practice, therefore, we can start at
the top of a committed branch or at its leaf, for either sequent style.
However, starting inference at any other leaf means knowing the state at
which a hypothetical subtransaction terminates.  This knowledge simply is
not available to us {\it a priori}.  In practice, therefore, the branches
for executional modal formulas must be constructed top-down.

For example, consider the deduction in Section~\ref{sec-ex-hypo}.
Whether we construct the committed branch top-down or bottom-up, we
reach eventually the sequent
\,$\bP,\{a,b\}\dbseq\,\infers\,\Diamond q \otimes r$.  ~At this
point, we can construct the branch for $q$.  But since we are now
positioned at the top of this branch, we have little choice but to
construct it in a top-down fashion.  A similar observation is true for
the deduction in Section~\ref{sec-ex-retro}.

In closing this section, we remark that it is possible to develop
other inference systems for $\Diamond$-serial-Horn programs, systems
that can operate in a completely bottom-up manner.  (We leave this as
an exercise.)  However, such systems cannot operate top-down.



\section{Comparison with Other Work}
\label{sec-comparisons}

********** Rework ***********

As mentioned earlier, there would appear to be many other candidates
for a logic of transactions, since many logics reason about state
changes or about the related phenomena of time and action.  However,
despite the abundance of action logics, none has ever been found
suitable for a database or logic programming system, and none has
become a core of database or logic-programming theory.  This is in
stark contrast to classical logic, which is the foundation of database
queries and logic programming, both in theory and in practice.  The
introduction described a few broad reasons for this unsuitability of
existing action logics.  This section looks at specific formalisms in
more detail.  We first discuss declarative languages that were
designed for updating databases.  We then look closely at action
logics presented in the literature of Logic and AI.

%%As far as databases and logic programming are concerned, we are not
%%aware of any approach to logics for updates that is as comprehensive
%%as \TR.  In particular, none of the works discussed below is capable
%%of expressing constraints on the execution of complex transactions.
%%Likewise, none of them can {\em seamlessly\/} accommodate hypothetical
%%state transitions with transitions that actually commit and
%%permanently change the current database state.  Furthermore, most of
%%the works are limited to updating sets of ground atomic facts.

As far as databases and logic programming are concerned, few logics can
match the broad range of applications of \TR, especially in comparison to
the small number of new features added to first-order classical logic to
achieve these capabilities. Apart from the suite of applications discussed
here, minor extensions to \TR enable it to seamlessly integrate
hypothetical transactions, counterfactual reasoning, and even concurrent
and communicating transactions.


One feature that sharply distinguishes \TR from all other formalisms
are the data and transition oracles.  The transition oracle exploits
\TR's distinction between stored and derived data.  Since the oracle
is a parameter to the logic, many kinds of elementary update can be
performed by specialized, efficient algorithms that are commonly used
in database systems.  Furthermore, many algorithmic features of
database systems, such as bulk updates and random sampling, can be
relegated to the transition oracle without sacrificing
declarativeness~\cite{trans-tr-95,trans-dbpl93}.  The same is true of
heuristic approximations to intractable problems.  Indeed, localizing
the {\em ad hoc\/} nature of such heuristics to the transition oracle
makes them invisible to the proof theory, the model theory, and the
run-time environment of the system.

In a similar fashion, the data oracle separates the dynamics of the
logic from details pertaining to the semantics of states.  This has
the additional benefit that we can push certain non-monotonic aspects
of various problems down to the data oracle.  Queries to the data
oracle do not even have to be recursively enumerable, since states are
treated as black boxes by the proof theory (which is complete modulo
the oracles).  One example is testing the emptiness of a predicate in
a logic program.  In logic programming and deductive databases, such
problems are typically dealt with by developing non-monotonic,
second-order semantics, and by imposing syntactic restrictions on
programs ({\it
e.g.},~\cite{przymusinski-perfect-model,gelder-ross-schlipf-91,gelfond-stable-88}).
\TR's data oracle factors out such problems from the dynamics of the
logic, so they can be treated separately.  In this way, \TR is able to
provide a monotonic, first-order semantics for incorporating complex
(even non-monotonic) queries into complex transactions.

In other words, even though elementary database operations may be
non-monotonic or non-logical, their {\it combination\/} into complex
programs is often both logical and monotonic.  \TR allows the user to
factor out any nastiness in elementary operations, and provides a simple
logic for combining them.  The examples in this paper demonstrate the
utility of this approach in a wide range of applications.


\subsection* {Languages for database updates.}

Winslett \cite{winslett-tods-88} did foundational work by supplying
the first generally acceptable semantic definition for the result of
updating a logical theory.  Later on, Grahne, Katsuno and Mendelzon
\cite{katsuno-mendel-kr91,grahne-kr91,grahne-mendel-91} axiomatized
various theories of state transition and studied tractable cases of
what we call ``elementary state transitions.''  Our approach to state
transitions is inspired by these results.

\paragraph{Approaches Based on Dynamic Logic:}
Several authors~\cite{casanova-81,manchanda-88,ldl-book,Spruit92a,Spruit94}
base their approaches to updates on Dynamic Logic~\cite{harel79}.
Casanova~\cite{casanova-81} applies an adaptation of Dynamic Logic to
reasoning about concurrent execution of procedural programs that are built
out of relational algebra operators plus an explicit relational assignment
operator.  Updates are done in the hypothetical mode and no complete proof
theory is given.


\paragraph{Dynamic Prolog:}
Manchanda and Warren~\cite{manchanda-88} developed Dynamic Prolog, a
logic programming language for database transactions.  The semantics
of Dynamic Prolog is based on Dynamic Logic.  This language is by far
the most similar to \TR.  For instance, \TR and Dynamic Prolog are the
only logic programming languages that account not just for updates,
but for transaction abort and rollback as well.  However, the proof
theory for Dynamic Prolog is impractical for carrying out updates,
since one must know the final database state {\it before\/} inference
begins.  This is because this proof theory is a {\em verification\/}
system: Given an initial state, a final state, and a transaction
program, the proof theory {\it verifies\/} whether the program causes
the transition; but, given just the initial state and the program, it
cannot {\it compute\/} the final state.  In other words, the proof
theory cannot execute transaction programs as \TR's proof theory does.
Apparently realizing this drawback, Manchanda and Warren developed an
interpreter whose aim was to ``execute'' transactions.  However, this
interpreter is incomplete with respect to the model theory and,
furthermore, it is not based on the proof theory.  To a certain
extent, it can be said that Manchanda and Warren have managed to
formalize their intuition as a program, but not as an inference
system.  In addition, there are several other differences between
Dynamic Prolog and \TR.  For instance, Dynamic Prolog assumes that
databases are relational, and it does not support bulk database
updates or constraints on program execution.  Furthermore, an
execution path in Dynamic Prolog consists of the initial and the final
state only, and it does not record the intermediate states. As a
consequence, it is impossible to express constraints on transaction
execution, such as those needed for advanced applications in AI,
workflow management, etc. \cite{trans-tr-95,davulcu-workflow-98}.


\paragraph{LDL:}
Naqvi and Krishnamurthy~\cite{naqvi-updates-88} extended Datalog with
update operators, which were later incorporated in the LDL
language~\cite{ldl-book}.  Since LDL is geared towards database
applications, this extension has bulk updates, for which an
operational semantics exists.  Unfortunately, the model theory
presented in~\cite{naqvi-updates-88,ldl-book} is somewhat limited.
First, it matches the execution model of LDL only in the propositional
case, and so it does not cover bulk updates.  Second, it is only
defined for update-programs in which commutativity of elementary
updates can be assumed.  For sequences of updates in which this does
not hold, the semantics turns out to be rather tricky and certainly
does not qualify as ``model theoretic.''  Third, the definition of
``legal'' programs in~\cite{naqvi-updates-88,ldl-book} is highly
restrictive, making it difficult to build complex transactions out of
simpler ones.


\paragraph{Chen's Calculus:}
Chen developed a calculus and an equivalent algebra for constructing
transactions~\cite{chen-tods-95}.  Like \TR, this calculus uses logical
operators to construct database transactions from elementary updates.
There are several differences however.  First, the calculus is not
part of a full logic.  Second, it assumes that databases are
relational.  Third, it has a very different semantics for conjunction.
Specifically, whereas \TR uses $\And$ to express dynamic constraints,
Chen's calculus uses it to express parallel actions.  The main
motivation here is that parallel actions make bulk updates easy to
express, which is an important database feature.  However, there are
several disadvantages in the way this is achieved.  First, the
calculus cannot express the kind of dynamic constraints that \TR
can~\cite{trans-tr-95}, while \TR expresses bulk updates through other
means~\cite{trans-dbpl93,trans-tr-95}.  Second, parallel actions
greatly complicate the semantics, since they require a minimality
principle, which makes the algebra non-monotonic even in the absence
of negation.  Third, the syntax is not closed.  For instance, negation
can be applied to some formulas but not to others.  In particular, if
$\psi$ is an updating transaction, then rules like $p\la\psi$ are not
allowed, since it is equivalent to $p\Or\neg\psi$; indeed, this
formula has no meaning in Chen's calculus.  It therefore seems
unlikely that this calculus can be developed into a full {\it logic\/}
in a straightforward or satisfying way.  Furthermore, the calculus
itself is very limited as a programming language, since it has no
mechanism for defining recursion or subroutines.


\paragraph{Bry's Approach:}
In~\cite{bry-iclp-90}, Bry takes a two-tiered approach: first, he uses
ordinary queries to determine (generate) the set of atoms to be
added/deleted; then, he performs updates meta-logically.  Dynamic
constraints are also meta-logical; and they involve pairs of different
theories.  Thus~\cite{bry-iclp-90} can neither define nor compose
complex transactions.  It is also impossible to specify constraints on
transaction execution or to insert and delete rules.  In a
sense,~\cite{bry-iclp-90} provides a {\em methodology\/} for
expressing what is to be updated rather than a logic for {\em
performing\/} updates.


\paragraph{Hypothetical Datalog:}
Bonner has carried out a thorough analysis of reasoning in
Hypothetical Datalog~\cite{bonner-jlp97a,bonner-jlp97b,bonner-tcs-90},
including a sophisticated complexity analysis.  Like \TR, this work
combines elementary updates into complex transactions.  Both works
also use similar tactics to avoid the frame
problem~\cite{trans-tr-95}.  However, Hypothetical Datalog does not
commit updates, does not deal with arbitrary logical databases, and
does not combine updates with other logical connectives in arbitrary
ways.  Instead, Hypothetical Datalog is a disjunction-free logic
programming system for relational databases.  The semantics of
Hypothetical Datalog is also based on different principles than \TR's.
In particular, it does not embrace the concept of the execution path,
which is fundamental to \TR.  Consequently, dynamic constraints of the
kind discussed in~\cite{trans-tr-95,trans-ictl94,trans-dbpl93} cannot
be expressed.


\paragraph{Abiteboul-Vianu's Update Languages:} 
Abiteboul and Vianu developed a family of Datalog-style update
languages~\cite{abiteboul-jcss91,abiteboul-icdt-88}, including
comprehensive results on complexity and expressibility.  Unlike
Transaction Logic, these languages are not part of a full {\it logic}:
arbitrary logical formulas cannot be constructed, and although there
is an operational semantics, there is no corresponding model theory
and no logical inference system.  In addition, these languages lack
several features that are present in \TR.  First, they assume that
databases are relational.  Second, they do not support
subtransactions, savepoints, or partial abort and rollback.  Third,
there is no facility for constraining program execution, and program
output is the only concern.  Fourth, there is no support for
subroutines.  This can be seen most clearly in the procedural
languages defined in~\cite{abiteboul-jcss90}.  This lack of
subroutines is reflected in the PSPACE data complexity of some of the
languages, since subroutines would lead to {\it alternating\/} PSPACE,
that is, EXPTIME~\cite{bonner-pods99}.


The works~\cite{glue-91,maindreville-88} are related
to~\cite{vianu-pods-88} in that they all borrow much of their syntax
from deductive databases and yet their semantics is operational
(although inspired by logical model theory).  As such, these languages
are in a different league than \TR; they are also unsuitable for
defining transactions, constraints, and for reasoning about actions.


\subsection{Logics of Action}

The work described above is aimed at specifying and {\it executing\/}
database updates.  In contrast, logics of action are aimed at
specifying and {\it reasoning\/} about actions.  Updates are a special
case of actions and, in a sense, execution is a special case of
reasoning where one infers the final state of the database from
the initial state.  With this in mind, we examine a number of
prominent action logics from the perspective of databases and logic
programming.

Generally, these action logics have far greater expressive power than
the database languages discussed above.  In a sense, however, they are
{\it too\/} expressive.  One lesson of database theory and practice is
that if a declarative language (like SQL) is not too expressive, then
optimization and high performance are possible.  Often, database
languages aim for the {\it minimal\/} power needed to get a job done.
Indeed, most of the languages discussed above have natural
implementations that are reasonably efficient and optimizable.  In
contrast, most of the logics in this section provide no clues about
how to efficiently execute transactions.
%%One problem is that they do
%%not distinguish between stored data and derived data.  Thus, there is
%%no obvious way to materialize an updated database without also
%%materializing all the logical consequences of the theory.  In
%%contrast, state materialization is a central feature of \TR.  This is,
%%perhaps, most apparent in the proof theory of Section~\ref{sec-proof},
%%where each new state is explicitly materialized.  There is no analogue
%%of this in other logics.

Although logics of action can have great expressive power, it is
sometimes the wrong kind of expressiveness for databases.  For
instance, since most action logics were not designed as programming
languages, important programming features (such as subroutines) are
often awkward, if not impossible to express.  In addition, action
logics often make a sharp distinction between queries and updates.
This distinction may be important in some applications, but it is
ill-suited for programming.  For example, Prolog-style
languages and most object-oriented languages treat queries and updates
uniformly.  A sharp distinction can also be a hindrance to application
development.  For instance, to debug a query, a programmer may want to
insert an update into its definition to monitor its execution or to
count the number of times it is called.  More generally, as an
application evolves, simple queries may develop into more complex
transactions with updates, and vice-versa.  An abrupt distinction
between queries and updates makes this kind of evolution difficult, if
not impossible.

\TR makes no such distinction.  It treats queries and updates
uniformly, as two extreme points on a spectrum of transactions.  Like
ordinary programs, every formula in \TR can both update the database
{\em and\/} return an answer.  While \TR does
not distinguish between queries and updates, it does not force the user to
blur the line between the two.
If an application calls for such a distinction, it can easily be
achieved by using two sorts of predicates, query predicates and update
predicates.  One way to distinguish the two is to require that all
update predicates be prefixed with {\it do:\/}.  Thus, {\it
do:enroll(student course)\/} would be an update, while {\it
grade(student,course)\/} would be a query.  In a similar fashion,
deductive databases distinguish two kinds of predicates (base and
derived), while the underlying (classical) logic does not.

Finally, most logics of action do not actually perform database
updates.  Many, in fact, do not even have a notion of database, since
they were not intended for database applications.  Typically, an
action logic describes relationships between different states, without
describing how to get from one state to the next.  This is fine for
reasoning about action; but to actually execute an action, one needs
much more information.  Unfortunately, large numbers of logical
formulas are often needed to completely describe even very simple
actions.  Even when this is not a problem, however, an action logic is
usually just a specification language.  Actually executing an action
and updating the database must be done outside of the logic.  This
contrasts with classical logic programming, where executing a query
can be carried out by purely logical means, {\it i.e.}, by the proof
theory.  Unlike most logics of action, \TR is a language for {\it
both\/} specifying and executing actions.  This is possible because
\TR includes logical mechanisms for executing an action and updating
the database.  This is formalized model-theoretically by the notion of
{\it executional entailment\/} (Section \ref{sec-queries}).  It is
even more apparent in the proof theory, in which each elementary
update produces a new database state.


%There is one more aspect that sharply distinguishes \TR from all
%action logics---the transition base.  As noted earlier, the transition
%base relies on \TR's distinction between stored and derived data.  It
%is also crucial to the efficiency of elementary updates in \TR.
%Indeed, the transition base serves as an oracle for the proof theory
%of \TR, and many kinds of elementary updates there can be performed
%by specialized, efficient algorithms that are commonly in use in
%database languages.  Furthermore, as explained in
%Section~\ref{sec-proof-transbase-observe}, elementary transitions need
%not be recursively enumerable, in general.  Testing for the emptiness
%of a predicate is one example.  Thus, the transition base allows \TR
%to embed various efficient heuristic approximations to generally
%undecidable problems without sacrificing declarativeness.  Moreover,
%localizing the {\em ad hoc\/} aspects of these heuristics in the
%transition base would make them transparent to the proof theory and to
%the run-time environment of the system.



\paragraph{Dynamic Logic and Process Logic:}
Dynamic Logic~\cite{harel79} and Process Logic~\cite{process-log-82}
allow a user to express properties of procedural programs and to
reason about them.%
%
\footnote{A number of different process logics have been proposed in
the literature, beginning with Pratt's original
work~\cite{pratt-process-79}.  The version in \cite{process-log-82} is
closer to \TR than any other incarnation of Process Logic we are aware
of.}
%
Unlike serial-Horn \TR, Process and Dynamic Logics are not logic
programming languages.  This difference shows up in several ways.
First, Process Logic and Dynamic Logic represent programs
procedurally, not as sets of logical rules.  Second, they do not have
an SLD-style proof procedure for executing programs.  In fact, they
were not intended for executing programs, but rather for reasoning
about their properties.  Third, in both Process Logic and Dynamic
Logic, the logic itself is used {\it outside\/} of programs to specify
their properties.  In particular, the logic is not used for {\it
constructing\/} the programs themselves or for specifying database
queries.  Fourth, Process Logic and Dynamic Logic were not designed
for database programming.  For instance, they do not have the notions
of a database or a query, and they do not support named procedures,
such as subroutines and views.



\paragraph{Action Logic and Related Proposals:}
Pratt~\cite{pratt-ai-90} develops a logic, called {\em Action Logic},
that has a few similarities with \TR but is different from it in many
essential ways.  Like \TR, Action Logic does not distinguish between
actions and propositions: actions are simply propositions that hold on
intervals.  The semantics and the intent of the two formalisms are
very different however.  First, Action Logic is not a language for
updating databases or defining transactions.  In fact, it has no
notion of database, no analogue of \TR's transition oracle, and no
counterpart to executional entailment.  Instead, Action Logic is an
extension of regular expressions, and as such, it can be viewed as a
formalism for defining languages.


\paragraph{McCarty and Van der Meyden:}
In~\cite{mccarty-kr92}, McCarty and Van der Meyden develop a theory
for reasoning about ``indefinite'' actions.  This work is orthogonal
to \TR.  The main similarity is that both works are concerned with
defining complex actions in terms of simpler ones, and in both works,
the actions may be non-deterministic (or ``indefinite'').  However,
unlike \TR, \cite{mccarty-kr92} does not address action execution or
the updating of databases.  Instead, they are concerned with
inferences of the following sort: given that certain (complex) actions
have occurred, determine what other (complex) actions must also have
occurred.

In earlier work, McCarty outlined a logic of action as part of a
larger proposal for reasoning about deontic concepts~\cite{mccarty83}.
His proposal contains three distinct layers, each with its own logic:
first-order predicate logic, a logic of action, and a logic of
permission and obligation.  In some ways, the first two layers are
similar to \TR, especially since the action layer uses logical
operators to construct complex actions from elementary actions.
Unfortunately, this promising proposal was not developed in detail.
For instance, although a model theory based on sequences of partial
states is presented, there is no sound-and-complete proof theory, and
no mechanism is presented for executing actions or updating the
database.


\paragraph{The Situation Calculus:}
The situation calculus is a methodology for specifying the effects of
elementary actions in first-order classical logic.  It was introduced
by McCarthy~\cite{sitcalc-63} and then further developed by McCarthy
and Hayes \cite{sitcalc-69}.  After a hiatus of about 30 years, the
situation calculus has recently been resurrected by
Reiter~\cite{reiter-sitcalc99}.  Unlike serial-Horn \TR, the situation
calculus is not a programming language.  Instead, the emphasis is on
specifying and reasoning about elementary actions, not on combining
them into complex programs.  As such, the frame problem has been a
central issue in the development of the situation
calculus~\cite{sitcalc-69,reiter-sitcalc99}.  The frame problem is
also an issue in {\it full\/} \TR when it is used to specify and
reason about elementary actions, a context in which frame axioms are
unavoidable~\cite{trans-reasoning-98}.


\paragraph{The Action Language of Gelfond and Lifschitz:}
Gelfond and Lifschitz have proposed a high-level language called $\cA$
for describing the effects of actions~\cite{gelfond-actions92}.
Clearly inspired by the situation calculus, $\cA$ has rules for
specifying the effects of sequences of actions, causal laws, initial
knowledge, etc.  Like the situation calculus, and unlike serial-Horn
\TR, $\cA$ is not a programming language.  Instead, the emphasis is on
specifying and reasoning about elementary actions, not on combining
them into complex procedures.


\paragraph{The Event Calculus:}
The event calculus is a methodology for encoding actions in
first-order classical logic.  It was originally developed by Kowalski
and Sergot for reasoning about time and events in a logic-programming
setting~\cite{sergot-86,kowalski-eventcalc-92} and for overcoming some
of the problems of the situation calculus.  A comparison of the event
calculus and the situation calculus is developed
in~\cite{eventcalc-sitcalc-97}.  Unlike serial-Horn \TR, the event
calculus is not a language for programming database transactions.  In
fact, the event calculus does not update the database at all.
Instead, it is a query language for historical databases.  However,
these databases are not temporal databases in the traditional sense;
$i.e.$, they do not record the state of the world at various points in
time.  Instead, they record the events that have taken place, just as
a logical database log records the transactions that have executed.


\paragraph{Golog:}
Levesque et al.\ have recently developed Golog, a procedural language
for programming complex actions, including database
transactions~\cite{golog-jlp-97}.  Syntactically, Golog is similar to
the procedural database language QL developed by Chandra and
Harel~\cite{chandra80a} extended with subroutines and
non-deterministic choice.  Semantically, Golog is based on the
situation calculus and second-order classical logic.  It is possible
to express properties of Golog programs in classical logic and to
reason about them.

Unfortunatley, despite the claims of its developers, Golog is {\it
not\/} a logic programming language.  This is because having a logical
semantics is not the same thing as programming in logic.  Certainly,
formalizing the semantics of Fortran in logic would not make Fortran a
logic programming language (although it would make it possible to
reason about Fortran programs).  In many ways, Golog is the {\it
opposite\/} of logic programming.  Most obviously Golog programs are
not defined by sets of Horn-like rules, but by procedural statements
in an Algol-like language.  Golog also does not come with an SLD-style
proof procedure that executes programs and updates databases by
proving theorems.  Finally, unlike serial-Horn \TR, Golog does not
include classical logic programming as a special case.  That is,
classical logic programs and deductive databases are not Golog
programs, nor can they be integrated with Golog programs in a
straightforward way.  In effect, Golog abandons the traditional
logic-programming paradigm.


\paragraph{Datalog with State:}
A number of researchers have worked on adding a notion of state to
Datalog programs~\cite{zaniolo-MISC-93,ludaescher-comad-95}.  In these
works, states are represented through a special, distinct argument,
which is added to each updatable predicate.  Updates are then modeled
as state transitions.  This approach can be viewed as an adaptation of
the situation calculus to Datalog.  As such, it has several important
differences with Reiter's theory of database evolution and with
Golog.

First, unlike Reiter's theory, Datalog with state uses a form of
closed-world semantics (XY-stratification~\cite{zaniolo-MISC-93} or
state-stratification~\cite{ludaescher-comad-95}), which is closer to
the database tradition.  Moreover, unlike Reiter's theory, Datalog
with state has no problem in representing database views, recursive or
otherwise.  Second, actions in Datalog with state are limited to the
insertion and deletion of ground atomic formulas.  Because of this
restriction, the frame problem is not a serious issue, since it only
needs to be axiomatized for a small, fixed number of actions.  Third,
unlike Golog (and \TR), Datalog with state has no notion of
subroutine.  That is, transaction programs cannot be named and used
within other programs.


\paragraph{Approaches Based on Temporal Logic:}
In addition to the situation and event calculi, there are other
approaches to modeling actions within first-order logic ({\it e.g.},
\cite{allen-84,mcdermott-temp-82}).  Generally, these approaches are
concerned with difficult problems in Artificial Intelligence and
Linguistics.  Often they are concerned with the interaction of
time and action with belief, intention and causality.  As such, the
number and the complexity of the axioms for these systems is quite
large compared to the proof theory of \TR.  More importantly,
developing a declarative programming language (like \TR) for
specifying and executing transactions is not their main concern.
Indeed, these formalisms were intended for {\it reasoning about\/}
action, not for actually updating databases.  Such reasoning is
feasible if actions are relatively simple.  However, once actions are
as complex as programs, reasoning about them is outside of $r.e.$, and
so it cannot be formulated in first-order logic.  Inference systems for
such reasoning may be sound, but they cannot be complete.  In
contrast, because \TR focuses on execution, this problem does not
arise, and inference in \TR is {\it both\/} sound and complete.  Many
of our comments about the situation calculus also apply to other
encodings of action in first-order logic, especially those comments
about the frame problem and the use of explicit time variables.

Besides these general comments, the work by James Allen deserves
special mention \cite{allen-84,allen-cacm-83,allen-ijcai-83}.  This
is because actions in Allen's logic are not instantaneous, but take
place over time {\it intervals}, much as actions in \TR take place
over {\it paths}.  Allen's logic supports a rich set of relations
between actions: besides coming before or after one another, actions
can overlap, start at the same time, end at the same time, etc.  As
illustrated in Section~\ref{sec-serial-impl}, similar relations can be
expressed in \TR.  Allen's logic can also express sequential planning
goals, such as, ``First boil the water, and then add the coffee''
\cite{allen-ijcai-83}.  As illustrated in Section
\ref{sec-planning-scripts}, such goals can also be expressed in \TR.
Generally, though, the two logics have different applications.  Allen's
logic is intended for {\it reasoning\/} about action, whereas \TR provides
{\it executable specifications\/} for complex actions.
Specifically, Allen's logic uses temporal variables, which
provide a powerful reasoning capability, while \TR uses a transition
oracle, which provides efficient execution.

The work of Halpern and Shoham~\cite{HalShoham-86}, which is based on
Allen's logic of time intervals, develops a propositional modal logic for
reasoning about time intervals, including results about undecidability.
Although, by following this approach, one can represent some aspects of
transaction programming, it is not completely adequate for the task.  For
instance, there is no counterpart to \TR's transition oracle, nor to the
notion of executional entailment, and it is not clear that subroutines can
be expressed in a straightforward way.  In addition, although actions can
be sequenced, this is not done using a logical connective of serial
conjunction, as in \TR.  Consequently, there is no counterpart to
\TR's dual connective of serial disjunction, nor to serial
implication.  Thus, there is no obvious way to express constraints
based on these connectives, such as those illustrated in
Section~\ref{sec-serial-impl}.  Finally, although the logic is
propositional, validity is already outside of $r.e.$ for some
important models of time, including real time and integer time.

In \cite{Gab89}, Gabbay uses USF, a temporal logic of integer linear time
with operators {\em since}, {\em until}, and {\em fixpoint}, to model
execution of processes.  Like \TR, USF queries the database via an
analogue of the state data oracle, but USF does not use transition oracles.
Apart from this and the emphasis on execution, the details and the
capabilities of the two logics are very different.

USF uses a standard temporal semantics; in particular, all formulas are
true at states, and execution is modeled by the process of constructing
temporal models for the time points in the future of now.  In contrast,
\TR's formulas are true on paths, and execution is modeled by verifying
that a transaction holds on a path in all models of the program. Thus, in
\TR, execution corresponds to logical entailment, while in USF it
corresponds to satisfiability.  Consequently, \TR uses a proof theory to
execute actions, while USF uses a model-building procedure.

The goals of the two logics are also quite different. USF was intended as a
language for process control, so it is best suitable for specifying dynamic
properties of executing processes. \TR, on the other hand, emphasizes
action definition through subroutines and composition, so it is best suited
as a logic for defining and executing complex transaction.  Moreover, if
USF were applied to specifying database transactions, it would have to face
the dreaded frame problem.




%\subsubsection*{Temporal Logic Programming}

In \cite{moszkowski-86}, Moszkowski develops an imperative programming
language, called {\it Tempura}, based on Interval Temporal Logic (ITL)
\cite{halpern-icalp83,moszkowski-phd}.  Moszkowski shows how each
Tempura statement translates into ITL, shows how to specify numerous
applications in Tempura, and describes an interpreter for executing
Tempura programs.  There are important similarities between Tempura
and \TR.  For instance, Tempura emphasizes the {\it execution\/} of
programs specified in logic.  Tempura also evaluates formulas on
paths, that is, on sequences of states; and it has an operator of
sequential composition, called {\it chop}, which is identical to
serial conjunction in \TR.  Finally, like serial-Horn \TR, Tempura
represents a subset of a larger logic.  However, there are also many
significant differences between Tempura and \TR, which we itemize
below.

\begin{itemize}

\item
Tempura is not a {\it database\/} programming language.  Indeed, there
is no notion of database or of persistence in Tempura or in ITL, and
there is no analogue to \TR's transition oracle.  Furthermore, if
applied to databases, Tempura and ITL would both suffer from the frame
problem and the ramification problem (Section
\ref{sec-frame-problem}).

\item
Although it has a logical semantics, Tempura is an {\it imperative\/}
programming language, not a {\it logic\/} programming language.
Consequently, Tempura has no built-in facilities for unification, for
backtracking, or for non-determinism.

\item
Although a notion of serial conjunction is defined, the dual notion of
serial disjunction is not considered, nor is serial implication.
Consequently, the kind of dynamic constraints described in Section
\ref{sec-constraints} were not developed.

\item
Tempura represents an executable fragment of ITL, but a fragment
without a clean, simple characterization.  In particular, Tempura is
not a ``Horn'' fragment of ITL.

\item
Unlike serial-Horn \TR (and classical Horn logic), Tempura lacks an
efficient SLD-style inference system.  In fact, proof theory is barely
mentioned in \cite{moszkowski-86}.

\item
Although Tempura has subroutines, they cannot be expressed within ITL
\cite{moszkowski-86}.  It may be possible to extend ITL to include
(recursive) subroutines, perhaps by adding a fixpoint operator, but
\cite{moszkowski-86} provides no details.
\end{itemize}

Finally, it is worth comparing \TR, ITL and Process Logic (discussed
earlier).  As in \TR and Process Logic, formulas in ITL are true on
paths, that is, on sequences of states.  However, the semantics of ITL
and Process Logic are fundamentally different from that of \TR.  For
instance, in both ITL and Process Logic, an atom is true on a path iff
it is true at the first state of the path.  In contrast, in \TR, the
truth of atoms on a path is interpreted as {\em execution\/} and 
is independent of the states that make up the
path.  Such dependencies can be described in \TR by logical axioms,
but they are not built into the semantics.  One consequence is that in
ITL and Process Logic, an atom can only represent a static fact, such
as $age(tony,32)$, whereas in \TR, an atom can represent an action,
such as $promote(tony,manager)$.  This is one reason why ITL must be
extended in order to define subroutines, since there is no facility
for assigning names to complex actions.



\paragraph{Procedural Logic:}
Georgeff and Lansky develop a formalism called Procedural Logic whose
intent is very similar to that of
\TR~\cite{lansky-proc-logic-85,georgeff-proc-know-86}.  Both systems
focus on executable specifications of transactions, both provide a
subroutine facility, both allow for arbitrary primitive actions,
non-deterministic actions, and both provide some kind of constraints.
Indeed, we are in complete agreement with Georgeff and Lansky on the
limitations of existing logics of action.  However, there are
important differences between Procedural Logic and \TR, both
practically and philosophically.  These difference arise largely
because Procedural Logic is actually two separate things: An
implementation (called {\em PRS\/}), which provides the aforementioned
functionality; and a formalization, which accounts for only a fraction
of this functionality.  It is probably fair to say that \TR is a
formalization that accounts for almost all of PRS and more.  In the
following discussion, we use the term ``Procedural Logic'' to refer to
the formalization.

The most obvious difference between \TR and Procedural Logic is
syntactic: Whereas \TR uses Horn-like rules to define transactions,
Procedural Logic uses what in AI are called ``recursive transition
networks,'' which are a generalization of finite automata.
Furthermore, the status of transactions in the two formalisms is quite
different.  In \TR, transaction definitions are logical statements,
while in Procedural Logic, they are modal operators, as in Process
Logic and Dynamic Logic.  Each transition network defines a distinct
modal operator.

A more important difference concerns functionality: Procedural Logic
does not have a database.  As Georgeff and Lansky remark, having an
updatable database ``introduces all the standard planning issues, such
as the frame problem and consistency maintenance''
\cite{lansky-proc-logic-85}.  These are problems that \TR has
resolved.  Because it lacks a database, Procedural Logic cannot be
used for specifying or executing database transactions.  The
implementation, PRS, does not have this limitation, but it is not a logic
and provides no rigorous account of actions.  Likewise, only in the
implementation can a user specify primitive updates.  This is
impossible in the logic itself, which has no notion of database and
thus no notion of update, primitive or otherwise.  In
\TR, primitive executable actions are specified in the transition
oracle.

Another important difference between \TR and Procedural Logic is
semantic.  Like \TR, Procedural Logic claims to have a declarative
semantics.  However, the declarative semantics of Procedural Logic is
still very procedural, and seems to anticipate a Prolog-style
backtracking interpreter.  It is for this reason that the semantics is
burdened with the notions of ``successful'' and ``failed'' behaviors.
Indeed, as Georgeff and Lansky remark, ``the declarative semantics is
surprisingly complex'' \cite{lansky-proc-logic-85}, even though
databases and updates are not even included!  In contrast, \TR has an
elegant model-theoretic semantics that accounts for databases,
primitive updates, complex transactions, subroutines, and executions
that succeed or fail.

Finally, like \TR, Procedural Logic has an operational semantics.
However, unlike \TR, the operational semantics of Procedural Logic is an
{\em interpreter\/} for the logic, not a logical inference system.
Moreover, the interpreter is not complete with respect to the declarative
semantics.  The main problem is that the interpreter cannot rollback failed
transactions, just as Prolog cannot rollback {\em assert\/} and {\em
retract\/} operations.  Indeed, as pointed out in
\cite{lansky-proc-logic-85}, soundness {\it without\/} completeness ``is
the best one can really hope for when any particular selection may cause
some possibly irreversible action.''  Note that without rollback,
Procedural Logic cannot model sub-transactions.  In contrast, \TR provides
a logical inference system that is both sound and complete with respect to
its model-theory.  It thus provides both a theory and a procedure for
dealing with transaction rollback and sub-transactions.  Furthermore, the
procedure is a practical SLD-style inference system based on resolution.
Thus, unlike Procedural Logic (or PRS), \TR extends the advantages and
elegance of pure Prolog to Prolog with updates.  \bigskip



%%%% PROOFS
\newpage

\appendix


\section{Appendix: Soundness of \IS}
\label{app.sound}

This appendix contains proofs of soundness of the inference system \IS
developed in Section~\ref{sec-inference1}.  The proof for system \ISS
is exactly parallel.  Unlike completeness, soundness holds for
arbitrary formulas and transaction bases, and does not require the
serial-Horn conditions of Section~\ref{sec-serial-horn}.

For convenient reference, we reproduce the axioms and inference rules
of system \IS below.  Recall that the inference system assumes a data
oracle, $\doracle$, and a state transition oracle, $\toracle$.  As
described in Sections \ref{sec-syntax} and \ref{sec-semantics}, the
data oracle specifies the semantics of database states, and the
transition oracle specifies the semantics of elementary state
transitions.  Intuitively, if $b$ is a first-order formula and \,$b
\in \dO(\bD)$,\, then $b$ is true in database state $\bD$.  Likewise,
if \,$b \in \tO(\bD_1,\bD_2)$,\, then $b$ is an elementary transition
that transforms database $\bD_1$ into $\bD_2$.  The rest of this
appendix assumes that these two oracles are given.


\begin{definition}{Inference System \IS}
If $\bP$ is a transaction base, then \IS is the following system of
axioms and inference rules, where $\bD$ and $\bD_i$ are any database
state identifiers.
%%
\begin{description}
\item[Axioms:]~~ $\bP,\bD\dbseq ~\infers~ (\,)$.

\item[Inference Rules:]
In Rules~1--3 below, $\sigma$ is a substitution, $a$ and $b$ are
atomic formulas, and $\phi$ and $rest$ are serial goals.
%%
\begin{description}

\item[1.~~{\it Applying transaction definitions:}] ~ \\
Suppose \,$a \la \phi$\, is a rule in $\bP$ whose variables have been
renamed so that the rule shares no variables with $b\otimes rest$.  If
$a$ and $b$ unify with mgu $\sigma$, then
%%
\medskip\newline
\begin{math}
\begin{array}{l}
\bP,\bD\dbseq ~\infers~ (\exists)\,(\phi \otimes rest)\sigma \\
\hline
\bP,\bD\dbseq ~\infers~ (\exists)\,(b \otimes rest)
\end{array}
\end{math}
\medskip

\item[2.~~{\it Querying the database:}] ~ \\
If \,$b\sigma$\, and \,$rest\,\sigma$\, share no variables, and
\,\mbox{$\doracle(\bD) \models^c (\exists)\, b\sigma$},\, then
%%
\medskip\newline
\begin{math}
\begin{array}{l}
\bP,\bD\dbseq ~\infers~ (\exists)\,rest\,\sigma \\
\hline
\bP,\bD\dbseq ~\infers~ (\exists)\,(b \otimes rest)
\end{array}
\end{math}
\medskip

\item[3.~~{\it Performing elementary updates:}] ~ \\
If \,$b\sigma$\, and \,$rest\,\sigma$\, share no variables, and
\,\mbox{$\toracle(\bD_1,\bD_2) \models^c (\exists)\, b\sigma$},\, then
%%
\medskip\newline 
\begin{math}
\begin{array}{l}
\bP,\bD_2\dbseq ~\infers~ (\exists)\,rest\,\sigma \\
\hline
\bP,\bD_1\dbseq ~\infers~ (\exists)\,(b \otimes rest)
\end{array}
\end{math}
%%
\end{description}
\end{description}
%%
\end{definition}


The following simple theorem is the main result of this section.

\begin{theorem}[Soundness of \IS]
\label{thm-soundness}
~~If~~ $\bP,\bD\dbseq\,\infers\,\phi$ ~~then~~
$\bP,\bD\dbseq\models\phi$
\end{theorem}



To prove Theorem \ref{thm-soundness}, it is enough to show that the
axioms and inference rules of system \IS are sound.
Lemma~\ref{lem-soundness-axioms} below shows that the axioms are
sound.  Lemma~\ref{lem.soundness.rules} shows that the inference rules
are sound.


\begin{lemma} \label{lem-soundness-axioms}
~$\bP,\bD\,\models\,(\,)$~ for any transaction base $\bP$ and any
database $\bD$.
\end{lemma}

\begin{proof}
Recall that $(\,)$ is an abbreviation for the special proposition
$\state$, which is true on all states.  By definition,
\,$\bM,\tuple{D}\models\state$\, for all path structures, $\bM$, and
in particular, for all models of $\bP$.  Thus ~$\bP,\bD\models\state$.
{\it i.e.}, ~$\bP,\bD\models(\,)$.
\end{proof}


%To prove that the inference rules of system \IS are sound, we shall
%need the following lemma.
%%
%\begin{lemma} \label{lem.queries}
%Let $\phi$ be any first-order formula, and $\bM$ be any path
%structure.
%\[
%{\it If}~~~ \doracle(\bD) \models^c \phi~~~{\it then}~~~\bM,\tuple{\bD}\models\phi
%\]
%\end{lemma}
%%
%\begin{proof} 
%Let \,$\bM = \tuple{U,I_\cF,\ipath}$,\, and assume that
%%
%\,$\dO(\bD)\models^c\phi$.  \,Then
%\,$\ipath(\tup{\bD})\models^c\phi$\, by
%Definition~\ref{def-structures}.  Thus
%\,$\bM,\tuple{\bD}\models\phi$\, by Lemma~\ref{lem-sat-classical}
%since $\phi$ is first-order.
%\end{proof}


\begin{lemma} \label{lem.soundness.rules}
Suppose $b$ and $rest$ are two transaction formulas, and $\sigma$ is a
substitution.
%%
\begin{enumerate}
\item
Suppose that \,$a \leftarrow \phi$\, is a rule in $\bP$ whose
variables may have been renamed, and suppose that $a$ and $b$ unify
with mgu $\sigma$.
\sg
If ~~$\bP,\bD_1...\bD_n\models (\exists)\,(\phi \otimes rest)\sigma$~~
then ~~$\bP,\bD_1...\bD_n\models (\exists)\,(b \otimes rest)$.

\item
Suppose \,$b\sigma$\, and \,$rest\,\sigma$\, share no variables, and
\,\mbox{$\doracle(\bD_1) \models^c (\exists)\,b\sigma$},\, then
%%
\sg
If ~~$\bP,\bD_1...\bD_n\models (\exists)\, rest\,\sigma$~~ then
~~$\bP,\bD_1...\bD_n\models (\exists)\,(b \otimes rest)$.

\item
Suppose \,$b\sigma$\, and \,$rest\,\sigma$\, share no variables, and
\,\mbox{$\toracle(\bD_1,\bD_2) \models^c (\exists)\,b\sigma$},\, then
%%
\sg
If ~~$\bP,\bD_2...\bD_n\models (\exists)\, rest\,\sigma$~~ then
~~$\bP,\bD_1...\bD_n\models (\exists)\,(b \otimes rest)$.
%%
\end{enumerate}
\end{lemma}


\begin{proof}
We prove each item in turn.

$\bullet$ To prove item {\it 1}, first note that since \,$a \leftarrow
\phi$\, is in $\bP$, every model of $\bP$ is also a model of \,$a
\leftarrow \phi$\, and, therefore, of \,$(a \leftarrow \phi)\sigma$.
With this in mind, suppose that ~$\bP,\bD_1...\bD_n\models
(\exists)\,(\phi \otimes rest)\sigma$.  ~Then for every model $\bM$ of
$\bP$,
\mg
\mbox{~~~~~~}
\begin{tabular}{lll}
    $\bM,\tuple{\bD_1~...~\bD_n} \models (\exists)\,(\phi \otimes rest)\sigma$ \sg

    $\bM,\tuple{\bD_1~...~\bD_n} \models_{\nu} (\phi \otimes rest)\sigma$
    & for some variable assignment, $\nu$, by Definition~\ref{def-sat-tr}; \sg

    $\bM,\tuple{\bD_1~...~\bD_i} \models_{\nu} \phi\sigma$
    & for some $i$,\, by Definition~\ref{def-sat-tr}; \\
    ~~{\it and}~~$\bM,\tuple{\bD_i~...~\bD_n} \models_{\nu} rest\,\sigma$ \sg

    $\bM,\tuple{\bD_1~...~\bD_i} \models_{\nu} a\,\sigma$
    & since $\bM$ is a model of \,$(a \leftarrow \phi)\sigma$; \\
    ~~~{\it and}~~$\bM,\tuple{\bD_i~...~\bD_n} \models_{\nu} rest\,\sigma$ \sg

    $\bM,\tuple{\bD_1~...~\bD_i} \models_{\nu} b\,\sigma$
    & since \,$a\,\sigma = b\,\sigma$,\, as $\sigma = mgu(a,b)$; \\
    ~~{\it and}~~$\bM,\tuple{\bD_i~...~\bD_n} \models_{\nu} rest\,\sigma$ \sg

    $\bM,\tuple{\bD_1~...~\bD_n} \models_{\nu} (b \otimes rest)\sigma$
    & by Definition~\ref{def-sat-tr}; \sg

    $\bM,\tuple{\bD_1~...~\bD_n} \models_{\mu} (b \otimes rest)$
    & where \,$\mu(X) = \nu(X\sigma)$,\, for every variable $X$; \sg

    $\bM,\tuple{\bD_1~...~\bD_n} \models (\exists)\,(b \otimes rest)$
    & by Definition~\ref{def-sat-tr}.
\end{tabular}
\mg
%%
Since this is true for every model, $\bM$, of $\bP$, it follows
that ~$\bP,\bD_1...\bD_n\models (\exists)\,(b \otimes rest)$.
\medskip

$\bullet$ To prove item {\it 2}, suppose that \,$\dO(\bD_1)\models^c
(\exists)\, b\sigma$.\,  Then \,\mbox{$\bM,\tuple{\bD_1}\models
(\exists)\,b\sigma$}\, for {\it any\/} path structure, $\bM$, by
Definition~\ref{def-structures}.  Thus
\,\mbox{$\bM,\tuple{\bD_1}\models_{\mu} b\sigma$}\, for some variable
assignment, $\mu$.  With this in mind, suppose that
~\mbox{$\bP,\bD_1...\bD_n\models (\exists)\, rest\,\sigma$}.  ~Then
for every model, $\bM$, of $\bP$,
%%
\mg\mbox{~~~~~~}
\begin{tabular}{lll}
    $\bM,\tuple{\bD_1~...~\bD_n} \models (\exists)\, rest\,\sigma$ \sg

    $\bM,\tuple{\bD_1~...~\bD_n} \models_{\nu} rest\,\sigma$
    & for some variable assignment, $\nu$.
\end{tabular}
\mg
Let $\kappa$ be a variable assignment that coincides with $\nu$ on the
variables in $rest\,\sigma$, and with $\mu$ on the variables in
$b\sigma$.  This is possible since $b\sigma$ and $rest\,\sigma$ share
no variables.  Continuing:
%%
\mg \mbox{~~~~~~}
\begin{tabular}{lll}
    $\bM,\tuple{\bD_1~...~\bD_n} \models_{\kappa} rest\,\sigma$ 
        & by the previous item and the construction of $\kappa$;\sg

    $\bM,\tuple{\bD_1} \models_{\kappa} b\sigma$
        & since \,$\bM,\tuple{\bD_1}\models_{\mu} b\sigma$\,
          and by construction of $\kappa$; \sg

    $\bM,\tuple{\bD_1~...~\bD_n} \models_{\kappa}
        (b\sigma \otimes rest\,\sigma)$ 
        & by Definition~\ref{def-sat-tr}; \sg

    $\bM,\tuple{\bD_1~...~\bD_n} \models_{\kappa} (b \otimes rest)\sigma$ \sg

    $\bM,\tuple{\bD_1~...~\bD_n} \models_{\eta} (b \otimes rest)$
        & where \,$\eta(X) = \kappa(X\sigma)$,\, for every variable, $X$; \sg

    $\bM,\tuple{\bD_1~...~\bD_n} \models (\exists)\,(b \otimes rest)$
        & by Definition~\ref{def-sat-tr}.
\end{tabular}
\mg
Since this is true for every model, $\bM$, of $\bP$, it follows
that ~$\bP,\bD_1...\bD_n\models (\exists)\,(b \otimes rest)$.
\medskip

$\bullet$ To prove item {\it 3}, suppose
that
\,\mbox{$\toracle(\bD_1,\bD_2)\models^c (\exists) b\sigma$}.\, 
Then \,$\bM,\tuple{\bD_1~\bD_2}\models (\exists) b\sigma$\, for {\it
any\/} path structure, $\bM$, by Definition~\ref{def-structures}.
Thus, \,\mbox{$\bM,\tuple{\bD_1~\bD_2}\models_{\mu} b\sigma$}\, for
some variable assignment, $\mu$.  With this in mind, suppose that
~$\bP,\bD_2...\bD_n\models (\exists)\, rest\,\sigma$.  ~Then for every
model, $\bM$, of $\bP$,
%%
\mg\mbox{~~~~~~}
\begin{tabular}{lll}
  $\bM,\tuple{\bD_2~...~\bD_n}\models (\exists)\, rest\,\sigma$ \sg

  $\bM,\tuple{\bD_2~...~\bD_n}\models_{\nu} rest\,\sigma$
  & for some variable assignment, $\nu$.
\end{tabular}
\mg
As before, let $\kappa$ be a substitution that coincides with $\nu$ on
the variables in $rest\,\sigma$, and with $\mu$ on the variables in
$b\,\sigma$.  Then, as before, we have
\,\mbox{$\bM,\tuple{\bD_1~\bD_2}\models_{\kappa} b\sigma$}\, and
\,\mbox{$\bM,\tuple{\bD_2~...~\bD_n}\models_{\kappa} rest\,\sigma$}.
Therefore,
%%
\mg\mbox{~~~~~~}
\begin{tabular}{lll}
  $\bM,\tuple{\bD_1~\bD_2~...~\bD_n}\models_{\kappa} (b\sigma \otimes rest\,\sigma)$
  & by Definition~\ref{def-sat-tr}; \sg

  $\bM,\tuple{\bD_1~\bD_2~...~\bD_n}\models_{\kappa} (b \otimes rest)\sigma$ \sg

  $\bM,\tuple{\bD_1~\bD_2~...~\bD_n}\models_{\eta} (b \otimes rest)$
  & where \,$\eta(X) = \kappa(X\sigma)$,\, for every variable, $X$; \sg

  $\bM,\tuple{\bD_1~\bD_2~...~\bD_n} \models (\exists)\,(b \otimes rest)$
  & by Definition~\ref{def-sat-tr}.
\end{tabular}
\mg
Since this is true for every model, $\bM$, of $\bP$, it follows that
~$\bP,\bD_1...\bD_n\models (\exists)\,(b \otimes rest)$.
\end{proof}


%%\newpage

\section{Appendix: Completeness of \IS}
\label{app.complete}

This appendix proves that inference system \IS developed in
Section~\ref{sec-inference1} is complete.  (The proof for system \ISS
is exactly parallel.)  The axioms and inference rules of \IS are
conveniently reproduced in Appendix \ref{app.sound}.  Our proof
strategy is to first prove completeness of ground inference using a
canonical-model construction.  We then prove completeness of general
inference using a Herbrand theorem and a lifting lemma.  As in the
other appendices, we assume that a Transition Oracle, $\toracle$, and
a Data Oracle, $\doracle$, are given.  We also assume that all
transactions are existential serial goals, that the transaction base
is a set of serial Horn rules, and that the other conditions of
Definition~\ref{def-serial-horn2} are satisfied.


\subsection{Ground Inference}
\label{sec-ground-inf}

This section develops a ground version of inference system \IS called
{\it Ground \IS}.  To simplify the proof of completeness, this new
inference system also keeps track of the execution path,
$\bD_1...\bD_n$, of a transaction.  Systems \IS and Ground \IS use the
same data oracle, $\dO$, and the same transition oracle, $\tO$.  Both
systems thus have the same set of database state identifiers, and the
same semantics for states and transitions.  In addition to the serial
Horn conditions, this subsection assumes that the transaction base,
$\bP$, and all transaction invocations are ground.


\begin{definition}{Inference in Ground \IS}
Let $\bP$ be a (possibly infinite) transaction base that is ground and
serial Horn.  Then Ground \IS is the following system of axioms and
inference rules, where $\bD$ and $\bD_i$ are any database state
identifiers.\footnote{
%%
Note that the databases need not be ground; that is, $\doracle(\bD)$
may contain variables.}
%%
\begin{description}
\item[Axioms:]~~ $\bP,\bD ~\infers~ (\,)$

\item[Inference Rules:]
In Rules~$1'$--$3'$ below, $b$ is a ground atomic formula, and $\phi$
and $rest$ are ground serial goals.
%%
\begin{description}
%%
\item[$1'.$~~{\it Applying transaction definitions:}]
If \,$b \la \phi$\, is a rule in $\bP$, then:
%%
\medskip\newline
\begin{math}
\begin{array}{l}
\bP,\bD_1...\bD_n ~\infers~ \phi \otimes rest \\
\hline
\bP,\bD_1...\bD_n ~\infers~ b \otimes rest
\end{array}
\end{math}
\medskip

\item[$2'.$~~{\it Querying the database:}]
If \,\mbox{$\doracle(\bD_1) \models^c b$},\, then
%%
\medskip\newline
\begin{math}
\begin{array}{l}
\bP,\bD_1...\bD_n ~\infers~ rest \\
\hline
\bP,\bD_1...\bD_n ~\infers~ b \otimes rest
\end{array}
\end{math}
\medskip

\item[$3'.$~~{\it Performing elementary transitions:}]
If \,\mbox{$\toracle(\bD_1,\bD_2)\models^c b$},\, then
%%
\medskip\newline 
\begin{math}
\begin{array}{l}
\bP,\bD_2...\bD_n ~\infers~ rest \\
\hline
\bP,\bD_1,\bD_2...\bD_n ~\infers~  b \otimes rest
\end{array}
\end{math}
%%
\end{description}
\end{description}
%%
\end{definition}


Like \IS, the soundness of Ground \IS follows immediately from Lemmas
\ref{lem-soundness-axioms} and \ref{lem.soundness.rules}, which show
that each axiom and inference rule of Ground \IS is sound.  We
thus have the following result.

\begin{theorem}[Soundness of Ground \IS]
\label{thm-soundness-ground}
Let $\phi$ be a ground serial goal.
\[
  {\it If}~~~~ \bP,\bD_1...\bD_n\,\infers\,\phi
  ~~~~{\it then}~~~~ \bP,\bD_1...\bD_n\models\phi
\]
\end{theorem}


Below, we give some properties of Ground \IS.  The properties in
Lemma~\ref{lem.inf.properties} are special cases of the inference
rules with $rest = (\,)$.  Lemma~\ref{lem.inf.split} is a bit more
difficult, and is central to our proof of completeness for ground
inference.

\begin{lemma}[Basic Properties]
\label{lem.inf.properties}
Ground \IS has the following properties, where $b$ is a ground atomic
formula:
%%
\begin{enumerate}
\item
If ~$b \leftarrow \phi$~ is a rule in $\bP$, and if
~~$\bP,\bD_1...\bD_n\,\infers\,\phi$, ~~then~~
$\bP,\bD_1...\bD_n\,\infers\,b$.

\item
If ~$\doracle(\bD) \models^c b$~ then ~$\bP,\bD\,\infers\,b$.

\item
If ~$\toracle(\bD_1,\bD_2)\models^c b$~ then
~$\bP,\bD_1,\bD_2\,\infers\,b$.
\end{enumerate}
\end{lemma}


\begin{lemma} \label{lem.inf.split}
Ground \IS has the following property, where $\alpha$ and $\beta$ are
ground serial goals:
\[
{\it If}~~~ \bP,\bD_1...\bD_i\,\infers\,\alpha ~~~{\it and}~~~
\bP,\bD_i...\bD_n\,\infers\,\beta ~~~{\it then}~~~
\bP,\bD_1...\bD_n\,\infers\,\alpha \otimes \beta
\]

\end{lemma}

\begin{proof}
We shall transform a derivation of
\,$\bP,\bD_1...\bD_i\,\infers\,\alpha$\, into a derivation of
\,$\bP,\bD_1...\bD_n\,\infers\,\alpha \otimes \beta$.
%%The main
%%idea is to change the starting point of the derivation from the axiom
%%\,$\bP,\bD_i\,\infers\,(\,)$\, to the expression
%%\,$\bP,\bD_i...\bD_n\,\infers\,\beta$.
The proof is by induction over the length of the former derivation.

\paragraph{Basis:} Suppose that the sequent
\,$\bP,\bD_1...\bD_i\,\infers\,\alpha$\, can be derived in 1 step.  It
is therefore an axiom, so $i=1$ and $\alpha = (\,)$.  Thus, \,$\alpha
\otimes \beta = \beta$,\, so the sequent
\,$\bP,\bD_1...\bD_n\,\infers\,\alpha \otimes \beta$ is identical to
the sequent \,$\bP,\bD_1...\bD_n\,\infers\,\beta$,\, which is
identical to the sequent \,$\bP,\bD_i...\bD_n\,\infers\,\beta$,\,
which is given to be true.

\paragraph{Induction:} Suppose the lemma is true for all sequents
\,$\bP,\bD_1...\bD_i\,\infers\,\alpha$\, derivable in at most $N$
steps.  Since $\alpha$ is a ground serial goal, it has the form $b
\otimes rest$, where $b$ is a ground atomic formula, and $rest$ is a
ground serial goal.  Suppose the sequent
\,$\bP,\bD_1...\bD_i\,\infers\, b \otimes rest$\, can be derived in
$N+1$ steps.  We must show that ~$\bP,\bD_1...\bD_n\,\infers\, b
\otimes rest \otimes \beta$\, is derivable.  There are three cases,
depending on the last inference rule used in the derivation.
\medskip

$\bullet$
If Rule~1 is the last inference rule used, then
\,$\bP,\bD_1...\bD_i\,\infers\, \phi \otimes rest$,\, for some rule
\,$b \leftarrow \phi$\, in $\bP$.  Moreover, this sequent can be
derived in at most $N$ steps.  Hence, by induction hypothesis,
~$\bP,\bD_1...\bD_n\,\infers\, \phi \otimes rest \otimes \beta$.
~Finally, by inference rule~1, we have ~$\bP,\bD_1...\bD_n\,\infers\,
b \otimes rest \otimes \beta$.
\medskip

$\bullet$
If rule~2 is the last inference rule used, then ~$\doracle(\bD_1)
\models^c b$ ~and~ $\bP,\bD_1...\bD_i\,\infers\, rest$.  Moreover, the
last sequent can be derived in at most $N$ steps.  Hence, by induction
hypothesis, ~$\bP,\bD_1...\bD_n\,\infers\, rest \otimes \beta$.
~Finally, by inference rule~2, we have ~$\bP,\bD_1...\bD_n\,\infers\,
b \otimes rest \otimes \beta$.
\medskip

$\bullet$
If rule~3 is the last inference rule used,
\,\mbox{$\toracle(\bD_1,\bD_2) \models^c b$}\, and
\,\mbox{$\bP,\bD_2...\bD_i\,\infers\, rest$},\, where the latter
sequent can be derived in at most $N$ steps.  Hence, by induction
hypothesis, ~$\bP,\bD_2...\bD_n\,\infers\, rest \otimes \beta$.
~Finally, by inference rule~3, we have ~$\bP,\bD_1...\bD_n\,\infers\,
b \otimes rest \otimes \beta$.
\end{proof}



\subsection{Completeness of Ground \IS}
\label{sec.canonical}

To prove the completeness of Ground \IS, we construct a canonical
Herbrand model of the transaction base $\bP$.  This model,
constructed proof theoretically, provides the necessary link between
the proof theory and model theory.  Once again, in addition to the
serial Horn conditions, this subsection assumes that the transaction
base $\bP$ and all transactions are ground.

Given a language for \TR, we define the Herbrand universe and
classical Herbrand interpretations in a standard way.  The {\it
Herbrand universe\/} is the set of all ground terms that can be
constructed out of the symbols in $\cF$, and a {\it Herbrand
interpretation\/} is a semantic structure where the domain is the
Herbrand universe and where function symbols are interpreted in a
fixed way: $I_\cF(f)(t_1,...,t_n) = f(t_1,...,t_n)$.  The symbol $\HB$
shall denote the set of all ground atomic formulas, which is commonly
known as the {\it Herbrand base}.
%% The Herbrand base does {\it not\/} include the special predicates
%% $\state$, $\aarc$ and $\ppath$. 
There is a 1--1 correspondence between Herbrand interpretations and subsets
of $\HB$, so we shall often treat them as the same thing.

Recall from Definition~\ref{def-structures} that a path structure is a
triple $\tuple{U, I_\cF, \ipath}$, where $U$ is the domain, $I_\cF$
interprets function symbols, and $\ipath$ interprets paths.  A {\em
Herbrand path structure\/} is any path structure whose domain is the
Herbrand universe and whose function symbols have the Herbrand
interpretation.  Thus, since $U$ and $I_\cF$ are the same for all
Herbrand path structures, we can omit them and specify Herbrand path
structures in terms of $\ipath$ alone.


\begin{definition}{Canonical Model}
\label{def.model.canonic}
The canonical model of a transaction base $\bP$ is the Herbrand path
structure \,$\canonic{\bP} = \tup{\ipath}$,\, where
%%
\begin{center}
\begin{tabular}{rcl}
   $\ipath(\tuple{\bD_1~...~\bD_n})$ & = &
          $\{~ b \in \HB~~|~~ \bP,\bD_1,...,\bD_n \,\infers\, b ~\}$
\end{tabular}
\end{center}
\vspace{-5mm}
\end{definition}

We first observe that $\canonic{\bP}$ is a legitimate path structure.
This follows immediately from Definition~\ref{def-structures} and the
following lemma.

\begin{lemma} \label{lem.structure}
%%
Let $\canonic{\bP} = \tup{\ipath}$ be the canonical model of $\bP$.
Then:
%%
\begin{romanEnum}
\item 
  $\ipath(\tuple{\bD}) \models^c \phi$~ for every
  closed first-order formula such that \,$\phi \in \doracle(\bD)$
  \\(so $\canonic{\bP}, \tup{\bD} \models \phi$)
\item 
  $\ipath(\tup{\bD_1~\bD_2}) \models^c b$~ for every $b$ such that
   \,$b \in \toracle(\bD_1,\bD_2)$
   \\(so $\canonic{\bP}, \tup{\bD_1~\bD_2} \models b$)
\end{romanEnum}
%%
\end{lemma}

\begin{proof}
Recall that $\tO(\bD_1,\bD_2)$ is a set of ground atomic formulas.
Item $(ii)$ then follows directly from Lemma~\ref{lem.inf.properties}
and Definition~\ref{def.model.canonic}.  That is, if ~\mbox{$b \in
\tO(\bD_1,\bD_2)$}~ then ~\mbox{$\bP,\bD_1,\bD_2\,\infers\,b$}~ so
~\mbox{$b \in \ipath(\tup{\bD_1~\bD_2})$}~ so
~\mbox{$\ipath(\tup{\bD_1~\bD_2})\models^c b$}.
 
To prove item $(i)$, recall that because of the serial Horn
restrictions, $\doracle(\bD)$ is {\it independent\/} of $\bP$.
That is, no predicate symbol in the head of a rule in $\bP$ appears in the
body of a rule in $\doracle(\bD)$.  Thus, rules in $\doracle(\bD)$ do not
use conclusions inferred by rules in $\bP$.

Second, note that in the canonical model, every atom in
$\ipath(\tuple{\bD})$ comes from a sequent of the form
\,$\bP,\bD\,\infers\,b$.  \,These expressions are generated only by
inference rules~1 and~2.  Rule~2 infers
\,$\bP,\bD\,\infers\,b$ ~iff~ $\doracle(\bD) \models^c b$,~ and
rule~1 infers \,$\bP,\bD\,\infers\,b$\, only if $b$ is the head
of a rule in $\bP$.  Let $S$ be the set of ground atomic formulas
classically entailed by $\dO(\bD)$. Thus,  $\ipath(\tuple{\bD})$
consists of the atoms in $S$ plus the heads of some rules in $\bP$.

By the serial-Horn restrictions on the data oracle, $S$ must contain
some model of $\doracle(\bD)$.  Since the rules in $\doracle(\bD)$ are
independent of the rules in $\bP$, any set obtained from $S$ by adding
some rule-heads of $\bP$ is also a model of $\doracle(\bD)$.  Since
$\ipath(\tuple{\bD})$ is just such a set, it is a Herbrand model of
$\doracle(\bD)$.  Thus \,$\ipath(\tuple{\bD}) \models^c \phi$~ for
every \,$\dO(\bD) \models^c \phi$.
\end{proof}

The following lemma states a basic result about canonical models.
Theorem~\ref{thm-canonical1} partially generalizes this result from
atoms to serial goals.  A full generalization is given in
Corollary~\ref{cor.canonical3}.
%%
\begin{lemma} \label{lem.canonical0}
If $b$ is a ground atomic formula, then
\[
        \canonic{\bP},\tuple{\bD_1~...~\bD_n} \models b
        ~~~~{\it iff}~~~~
        \bP,\bD_1...\bD_n \,\infers\, b
\]
\end{lemma}
%%
\begin{proof}
Follows immediately from Definitions~\ref{def.model.canonic}
and~\ref{def-sat-tr}.
\end{proof}


\begin{theorem}
\label{thm-canonical1}
Let $\phi$ be a ground serial goal.
\[
        {\it If}~~~~
        \canonic{\bP},\tuple{\bD_1~...~\bD_n} \models \phi
        ~~~~{\it then}~~~~
        \bP,\bD_1...\bD_n \,\infers\, \phi
\]
\end{theorem}

\begin{proof}
$\phi$ has the form $b_1\otimes...\otimes b_k$, where $k \geq 0$ and
each $b_i$ is a ground atomic formula.  Our proof is by induction on
$k$.  In the base case, $k=0$ and $\phi$ is the empty clause ({\it
i.e.}, $(\,)$, or $\state$).  If the expression
\,$\canonic{\bP},\tuple{\bD_1~...~\bD_n} \models (\,)$\, is true, then
$n=1$, since the empty clause is true only on states.  But, the
sequent \,$\bP,\bD_1\,\infers\,(\,)$\, is trivially true, since it is
an axiom.

For the inductive case, assume the claim is true for all values of $k$ from
$0$ to $m$.  We show that it is true for $k= m+1$:
\medskip
%%
\begin{center}
\begin{tabular}{ll}
$\canonic{\bP},\tuple{\bD_1~...~\bD_n}
\models b_1 \otimes ... \otimes b_m \otimes b_{m+1}$
        & given; \sg

$\canonic{\bP},\tuple{\bD_1~...~\bD_i} \models b_1 \otimes ... \otimes b_m$
~~~{\it and}~~~
$\canonic{\bP},\tuple{\bD_i~...~\bD_n} \models b_{m+1}$~~~~
        & for some $i$, by Definition~\ref{def-sat-tr}; \sg

$\bP,\bD_1...\bD_i\,\infers\,b_1 \otimes ... \otimes b_m$
~~~{\it and}~~~
$\canonic{\bP},\tuple{\bD_i~...~\bD_n} \models b_{m+1}$
        & by induction hypothesis; \sg

$\bP,\bD_1...\bD_i\,\infers\,b_1 \otimes ... \otimes b_m$
~~~{\it and}~~~
$\bP,\bD_i...\bD_n\,\infers\,b_{m+1}$
        & by Lemma~\ref{lem.canonical0}; \sg

$\bP,\bD_1...\bD_n\,\infers\, b_1 \otimes ... \otimes b_m \otimes b_{m+1}$
        & by Lemma~\ref{lem.inf.split}.
\end{tabular}
\end{center}
\end{proof}


\begin{theorem}
\label{thm-canonical2}
~$\canonic{\bP}$ is a model of $\bP$.
\end{theorem}

\begin{proof}
Let \,$b \la \phi$\, be any rule in $\bP$.  Then, for any path
$\tuple{\bD_1~...~\bD_n}$,
%%
\begin{center}
\begin{tabular}{lll}
{\it if}
   & $\canonic{\bP},\tuple{\bD_1~...~\bD_n} \,\models\, \phi$ \sg
{\it then}
   & $\bP,\bD_1...\bD_n \,\infers\, \phi$
     & by Theorem \ref{thm-canonical1}; \sg
   & $\bP,\bD_1...\bD_n \,\infers\, b$
     & by Lemma~\ref{lem.inf.properties}; \sg
   & $\canonic{\bP},\tuple{\bD_1~...~\bD_n} \,\models\, b$
     & by Lemma~\ref{lem.canonical0}.
\end{tabular}
\end{center}
%%
$\canonic{\bP}$ thus satisfies the rule \,$b \leftarrow \phi$\, on
every path.  $\canonic{\bP}$ is therefore a model of every rule in
$\bP$, so it is a model of $\bP$.
\end{proof}


To prove the completeness of \IS, we do not need the completeness of
Ground \IS~per se.  Instead, we need Theorems \ref{thm-canonical1} and
\ref{thm-canonical2}.  However, since all the machinery is already in place,
we can state the completeness of Ground \IS as an easy corollary.


\begin{corollary}[Completeness of Ground \IS]
\label{cor.ground.completeness}
For any ground serial goal, $\phi$,
\[
        {\it if}~~~ \bP,\bD_1...\bD_n\,\models\,\phi
        ~~~{\it then}~~~ \bP,\bD_1...\bD_n\,\infers\,\phi
\]
\end{corollary}

\begin{proof}
Suppose that ~$\bP,\bD_1...\bD_n\,\models\,\phi$.  Then:
\begin{center}
\begin{tabular}{lll}
  $\bM,\tuple{\bD_1~...~\bD_n}\,\models\,\phi$
        & for every model, $\bM$, of $\bP$,
          by Definition~\ref{def-query}, \sg
  $\canonic{\bP},\tuple{\bD_1~...~\bD_n}\,\models\,\phi$
        & since $\canonic{\bP}$ is a model of $\bP$,
          by Theorem \ref{thm-canonical2}, \sg
  $\bP,\bD_1...\bD_n\,\infers\,\phi$
        & by Theorem~\ref{thm-canonical1}.
\end{tabular}
\end{center}
\end{proof}


Although this completes the proof of completeness in Ground \IS, we
include one more important corollary.  This corollary generalizes
Lemma~\ref{lem.canonical0} from atoms to serial goals.  It
shows that inference in Ground \IS is equivalent to satisfaction in
the canonical model.

\begin{corollary}
\label{cor.canonical3}
If $\phi$ is a ground serial goal, then
\[
        \canonic{\bP},\tuple{\bD_1~...~\bD_n} \models \phi
        ~~~~{\it iff}~~~~
        \bP,\bD_1...\bD_n \,\infers\, \phi
\]
\end{corollary}

\begin{proof}
The {\it only if\/} direction is just Theorem \ref{thm-canonical1}.
The {\it if\/} direction follows from the soundness of Ground \IS,
since, by Theorem~\ref{thm-canonical2}, $\canonic{\bP}$ is a model of $\bP$.
\end{proof}



\subsection{Completeness of \IS}
\label{sec.lifting}

Having proved the completeness of Ground \IS, we now prove the
completeness of \IS itself.  We first prove a result analogous to the
Herbrand Theorem of classical logic, which lets us reduce general
entailment to ground inference.  Then we prove a lifting lemma,
whose purpose is to
``lift'' ground inferences up to general inferences.  In this
subsection, we again assume the serial Horn conditions, but not
groundness.  Thus, transactions and the transaction base $\bP$ may
be non-ground.  The ground instantiation of $\bP$ is denoted $\bP^*$.
We shall need to distinguish between the sequents of inference systems
\IS and Ground \IS.  In general, sequents of the form
\,$\bP,\bD\dbseq\infers\phi$\, belong to \IS, while sequents of the 
form \,$\bP^*,\bD_1...\bD_n\infers\phi$\, belong to Ground \IS.


\begin{lemma}
\label{lem.herbrand.canonic}
~$\canonic{\bP^*}$ is a model of $\bP$.
\end{lemma}

\begin{proof}
  Let $b \leftarrow \phi$ be a rule in $\bP$ with free variables
  $\overline{X} = \{X_1...X_m\}$.  For any variable assignment, $\nu$, let
  $\theta_{\nu}$ be a substitution that replaces each variable $X_i \in
  \overline{X}$ with the Herbrand term $\nu(X_i)$.  Note that \,$(b
  \leftarrow \phi)\theta_{\nu}$\, is ground.  Moreover, by the discussion
surrounding Definition~\ref{def-sat-tr},
%%
\begin{equation}
\label{stmt.model}
        \canonic{\bP^*},\pi \models_{\nu} b \leftarrow \phi ~~~~~~{\it
iff}~~~~~~      \canonic{\bP^*},\pi \models (b \leftarrow
\phi)\theta_{\nu}
\end{equation}
%%
for any path, $\pi$.  Observe that the right-hand side of
(\ref{stmt.model}) is a true statement,  since \,$(b \leftarrow
\phi)\theta_{\nu}$\, is a rule in $\bP^*$, and $\canonic{\bP^*}$ is a
model of $\bP^*$, by Theorem \ref{thm-canonical2}.  Thus, the
left-hand side of (\ref{stmt.model}) is also true, for any variable
assignment, $\nu$.  Thus,
\[
      \canonic{\bP^*},\pi \models \forall \overline{X}\,(b \leftarrow \phi)
\]
by Definition~\ref{def-sat-tr}.  Since this is true for every path,
$\canonic{\bP^*}$ is a model of \,$b \leftarrow \phi$,\, by Definition
\ref{def-models-tr}.  $\canonic{\bP^*}$ is thus a model of every rule
in $\bP$, so it is a model of $\bP$.
\end{proof}

We can now prove a result that is analogous to Herbrand's Theorem in
classical logic.
%%
\begin{corollary}[Herbrand's Theorem for \IS]
\label{cor.herbrand}
Let $\phi$ be a serial goal.
\[
        {\it If}~~~ \bP,\bD_1...\bD_n\,\models\,(\exists)\,\phi
        ~~~{\it then}~~~ \bP^*,\bD_1...\bD_n\,\infers\,\phi'
\]
for some ground instance, $\phi'$, of $\phi$.
\end{corollary}

\begin{proof}
If ~$\bP,\bD_1...\bD_n\,\models\,(\exists)\,\phi$~ then
%%
\begin{center}
\begin{tabular}{lll}
  $\bM,\tuple{\bD_1~...~\bD_n}\,\models\,(\exists)\,\phi$
        & for every model, $\bM$, of $\bP$, \sg
  $\canonic{\bP^*},\tuple{\bD_1~...~\bD_n}\,\models\,(\exists)\,\phi$
        & since $\canonic{\bP^*}$ is a model of $\bP$,
          by Lemma~\ref{lem.herbrand.canonic}, \sg
  $\canonic{\bP^*},\tuple{\bD_1~...~\bD_n}\,\models_{\nu}\,\phi$
        & for some variable assignment, $\nu$, \sg
  $\canonic{\bP^*},\tuple{\bD_1~...~\bD_n}\,\models\,\phi\theta_{\nu}$
        & as described in the proof of Lemma~\ref{lem.herbrand.canonic}, \sg
  $\bP^*,\bD_1...\bD_n\,\infers\,\phi\theta_{\nu}$
        & by Theorem \ref{thm-canonical1}.
\end{tabular}
\end{center}
The result follows with $\phi' = \phi\theta_{\nu}$.
\end{proof}



\begin{lemma}[Lifting Lemma for \IS]
\label{lem.lifting}
Let $\psi$ be a serial goal, and let $\psi'$ be one of its
ground instantiations.
\[
      {\it If}~~~~ \bP^*,\bD_1...\bD_n\,\infers\,\psi'
~~~~{\it then}~~~~ \bP,\bD_1\dbseq\infers\,(\exists)\,\psi
\]
\end{lemma}

\begin{proof}
The proof is by induction on the length of the ground derivation.

\paragraph{Basis:} In this case, both inference expressions are axioms, so
they are both trivially true.

\paragraph{Induction:} Suppose the lemma is true for all ground derivations
having at most $N$ steps.  Now suppose the sequent
~$\bP^*,\bD_1...\bD_n\,\infers\,\psi'$~ is derivable in Ground \IS in
$N+1$ steps.  There are three cases, depending on the last inference
rule used in the derivation.
\medskip

$\bullet$ Suppose inference rule~$1'$ was used last in the ground
derivation.  Then $\psi$ has the form \,$b \otimes rest$\, and $\psi'$
has the form \,$b' \otimes rest'$,\, where $b$ and $b'$ are atomic
formulas.  Moreover, for some rule \,$b' \leftarrow \phi'$\, in
$\bP^*$, the sequent ~$\bP^*,\bD_1...\bD_n\,\infers\,\phi' \otimes
rest'$~ is derivable in Ground \IS in at most $N$ steps.

The rule \,$b' \leftarrow \phi'$\, is a ground instantiation of some
rule \,$a \leftarrow \phi$\, in $\bP$.  We show below that the
formula \,$\phi' \otimes rest'$\, is a ground instantiation of
\,$(\phi \otimes rest)\sigma$, where $\sigma$ is the most general
unifier (mgu) of $a$ and $b$.  Thus, by induction hypothesis,
~$\bP,\bD_1\dbseq\infers\,(\exists)\, (\phi \otimes rest)\sigma$.
~From this we get ~$\bP,\bD_1\dbseq\infers\,(\exists)\,(b \otimes
rest)$~ by inference rule~1 of \IS and rule $a \leftarrow \phi$ in
$\bP$.
\medskip

To show that \,$\phi' \otimes rest'$\, is a ground instantiation of
\,$(\phi \otimes rest)\sigma$,\, note that the atom $b'$ is a ground
instantiation of both $a$ and $b$.  The atomic formulas $a$ and $b$
therefore unify. Let $\sigma$ be their mgu.  The atom $b'$ is thus a
ground instantiation of \,$b\sigma = a\sigma$, {\it i.e.}, there is a
ground substitution $\sigma'$ such that \,$b' = a\sigma\sigma' =
a\sigma\sigma'$.\, Hence,
%%
\begin{mathlines0}{rcl}
b' \otimes rest' & = &
            (b \otimes rest)\sigma\sigma'\sigma_1 \sg
b' \leftarrow \phi' & = &
            (a \leftarrow \phi)\sigma\sigma'\sigma_2
\end{mathlines0}
%%
for some pair of ground substitutions, $\sigma_1$ and $\sigma_2$; the
substitution $\sigma\sigma'$ instantiates the variables in $a$ and
$b$.  The substitutions $\sigma_1$ and $\sigma_2$ instantiate any
remaining variables.  By inference rule~1, the variables in the rule
\,\mbox{$a \leftarrow \phi$}\, have been renamed so that it and
\,\mbox{$b \otimes rest$}\, have no variables in common.  Thus,
\,\mbox{$(a \leftarrow \phi)\sigma\sigma'$}\, and \,\mbox{$(b \otimes
rest)\sigma\sigma'$}\, have no variables in common, since
$\sigma\sigma'$ is a ground substitution.  Thus, $\sigma_1$ and
$\sigma_2$ instantiate different variables.  Thus $\sigma_1$ and
$\sigma_2$ commute; that is, \,$\sigma_2\sigma_1 =
\sigma_1\sigma_2$.

Extracting subformulas from the formulas above, we get:
%%
\begin{center}
$rest'  ~=~ rest\,\sigma\sigma'\sigma_1 
        ~=~ rest\,\sigma\sigma'\sigma_1\sigma_2$ \sg
$\phi' ~=~ \phi\,\sigma\sigma'\sigma_2 ~=~ \phi\,\sigma\sigma'\sigma_2\sigma_1$
\end{center}
%%
The rightmost equalities follow because applying substitutions to
ground formulas has no effect.  Combining these equalities, and using
the commutativity of $\sigma_1$ and $\sigma_2$, we get:
%%
\begin{mathlines0}{rcl}
   \phi' \otimes rest'
     & = & \phi\,\sigma\sigma'\sigma_1\sigma_2 ~\otimes~ 
           rest\,\sigma\sigma'\sigma_1\sigma_2 \sg
     & = & (\phi \otimes rest)\sigma\sigma'\sigma_1\sigma_2
\end{mathlines0}
%%
Thus, the formula \,$\phi' \otimes rest'$\, is a ground instantiation
of \,$(\phi \otimes rest)\sigma$.
\medskip

$\bullet$ Suppose inference rule~$2'$ was used last in the ground
derivation.  Then $\psi$ has the form $b \otimes rest$, and $\psi'$
has the form $b\sigma \otimes rest\,\sigma$, for some ground
substitution, $\sigma$.  Moreover, \,$\dO(\bD_1)\models^c b\sigma$,\,
and the sequent ~$\bP^*,\bD_1...\bD_n\,\infers\,rest\,\sigma$~ is
derivable in Ground \IS in at most $N$ steps.  Thus, by induction
hypothesis, the sequent
~$\bP,\bD_1\dbseq\,\infers\,(\exists)\,rest\,\sigma$~ is derivable in
\IS, since $rest\,\sigma$ is (trivially) a ground instance of
$rest\,\sigma$.  Also, $b\sigma$ and $rest\,\sigma$ share no
variables, since they are both ground.  Thus, the sequent
~$\bP,\bD_1\dbseq\,\infers\,(\exists)\,(b \otimes rest)$ is derivable
in \IS, by inference rule~2.
\medskip

$\bullet$ Suppose inference rule~$3'$ was used last in the ground
derivation.  Then $\psi$ has the form \,$b \otimes rest$,\, and
$\psi'$ has the form \,$b\sigma \otimes rest\,\sigma$,\, for some
ground substitution, $\sigma$.  Moreover, \,$\tO(\bD_1,\bD_2)\models^c
b\sigma$,\, and the sequent
~$\bP^*,\bD_2...\bD_n\,\infers\,rest\,\sigma$~ is derivable in Ground
\IS in at most $N$ steps.  By induction hypothesis, the sequent
~$\bP,\bD_2\dbseq\,\infers\,(\exists)\,rest\,\sigma$~ is derivable in
\IS, since $rest\,\sigma$ is (trivially) a ground instance of
$rest\,\sigma$.  Also, $b\sigma$ and $rest\,\sigma$ share no
variables, since they are both ground.  Thus, the sequent
~$\bP,\bD_1\dbseq\,\infers\,(\exists)\,(b\otimes rest)$~ is derivable
in \IS, by inference rule~3.
\end{proof}


\begin{theorem}[Completeness of \IS]
\label{thm-completeness}
Let $\phi$ be a serial goal. Then:
\[
            {\it If}~~~~ \bP,\bD\dbseq\models(\exists)\,\phi
        ~~~~{\it then}~~~~ \bP,\bD\dbseq\,\infers\,(\exists)\,\phi
\]
\end{theorem}


\begin{proof}
If ~\mbox{$\bP,\bD\dbseq\models(\exists)\,\phi$}~ then
~\mbox{$\bP,\bD,\bD_2...\bD_n\models(\exists)\,\phi$}~ for some
databases $\bD_2...\bD_n$, by Definition~\ref{def-query}.  Thus
~\mbox{$\bP^*,\bD,\bD_2...\bD_n\,\infers\, \phi'$}, where $\phi'$ is some
ground instance of $\phi$, by Corollary~\ref{cor.herbrand}.  Hence
~\mbox{$\bP,\bD\dbseq\,\infers\, (\exists)\, \phi$},~ by Lemma
\ref{lem.lifting}.
\end{proof}

Although this completes our proof of completeness in \IS, we include
the following important corollary.  It shows that inference in \IS is
equivalent to satisfaction in the canonical model.

\begin{corollary}
\label{cor.canonic}
Let $\phi$ be a serial goal. Then:
%%
\begin{center}
        $\bP,\bD\dbseq\,\infers\,(\exists)\,\phi$  ~~~{\it iff}~~~
        $\canonic{\bP^*},\tuple{\bD~\bD_2~...~\bD_n}\models (\exists)\,\phi$
        ~~for some databases $\bD_2...\bD_n$.
\end{center}
\end{corollary}

\begin{proof}
The {\it only if\/} direction:
\medskip

\mbox{~~~~}
\begin{tabular}{ll}
$\bP,\bD\dbseq\,\infers\,(\exists)\,\phi$ & given;\sg
$\bP,\bD\dbseq\models(\exists)\,\phi$
             & by Soundness, Theorem \ref{thm-soundness}; \sg
$\bP,\bD,\bD_2...\bD_n\models(\exists)\,\phi$
             & for some $\bD_2...\bD_n$, by Definition~\ref{def-query}; \sg
$\bM,\tuple{\bD~\bD_2~...~\bD_n}\models(\exists)\,\phi$
             & for all models, $\bM$, of $\bP$; \sg
$\canonic{\bP^*},\tuple{\bD~\bD_2~...~\bD_n}\models(\exists)\,\phi$
             & since $\canonic{\bP^*}$ is a model of $\bP$,
               by Lemma~\ref{lem.herbrand.canonic}.
\end{tabular}
\medskip

The {\it if\/} direction:
\medskip

\mbox{~~~~}
\begin{tabular}{ll}
$\canonic{\bP^*},\tuple{\bD~\bD_2~...~\bD_n}\,\models\,(\exists)\,\phi$
         & given; \sg
$\canonic{\bP^*},\tuple{\bD~\bD_2~...~\bD_n}\,\models_{\nu}\,\phi$
         & for some variable assignment, $\nu$,
           by Definition~\ref{def-sat-tr}; \sg
$\canonic{\bP^*},\tuple{\bD~\bD_2~...~\bD_n}\,\models\,\phi\theta_{\nu}$
         & as described in the proof of Lemma~\ref{lem.herbrand.canonic}; \sg
$\bP^*,\bD,\bD_2...\bD_n\,\infers\,\phi\theta_{\nu}$
         & by Theorem \ref{thm-canonical1}; \sg
$\bP,\bD\dbseq\,\infers\,(\exists)\,\phi$
         & by the lifting lemma, Lemma~\ref{lem.lifting}.
\end{tabular}

\end{proof}


%%\newpage

\section{Appendix: Executional Deduction in \IS}
\label{app-exec}

Section~\ref{sec-exec-as-deduct} developed the notion of executional
deduction, a special kind of deduction that corresponds to the
intuitive notion of transaction execution.  Executional deductions
trace out the execution path of a transaction during inference.  The
proofs of soundness and completeness given in Appendices
\ref{app.sound} and \ref{app.complete} are for general deductions in
inference system \IS.  This appendix adapts these proofs to
executional deductions in \IS.  (The proofs for system \ISS are
exactly parallel.)  As in Appendix~\ref{app.complete}, we assume that
all transactions are existential serial goals, that the transaction
base is a set of serial Horn rules, and that the other conditions of
Definition~\ref{def-serial-horn2} are satisfied.

Our proof strategy is to define a new inference system called {\it
Path\/} \IS.  Path \IS is identical to \IS except that it records the
execution path of a transaction.  Sequents in Path \IS have the form
~$\bP,\bD_1,\bD_2\ldots\bD_n\,\infers\,\psi$,~ which intuitively means
that \,$\bD_1,\bD_2\ldots\bD_n$\, is an (inferred) execution path for
transaction $\psi$.  Path \IS is similar to inference system Ground
\IS developed in Appendix \ref{sec-ground-inf}, except that the
transaction base $\bP$ and the transaction $\psi$ need not be
ground.  Since Path \IS is closely related to \IS and Ground \IS, it
is easy to show that Path \IS is sound and complete.  The only
remaining step is to show that any general deduction in Path \IS can
be associated with an executional deduction in \IS, and vice-versa.


\begin{definition}{Inference in Path \IS}
\label{def.path.inference}
If $\bP$ is a transaction base, then Path \IS is the following system
of axioms and inference rules, where $\bD$ and $\bD_i$ are any
database state identifiers.
%%
\begin{description}
\item[Axioms:]~~ $\bP,\bD\dbseq ~\infers~ (\,)$.

\item[Inference Rules:]
In Rules~$1'$--$3'$ below, $\sigma$ is a substitution, $a$ and $b$ are
atomic formulas, and $\phi$ and $rest$ are serial goals.
%%
\begin{description}

\item[$1'.$~~{\it Applying transaction definitions:}] ~ \\
Suppose \,$a \la \phi$\, is a rule in $\bP$ whose variables have been
renamed so that the rule shares no variables with $b\otimes rest$.  If
$a$ and $b$ unify with mgu $\sigma$, then
%%
\medskip\newline
\begin{math}
\begin{array}{l}
\bP,\bD_1\ldots\bD_n\dbseq ~\infers~ (\exists)\,(\phi \otimes rest)\sigma \\
\hline
\bP,\bD_1\ldots\bD_n\dbseq ~\infers~ (\exists)\,(b \otimes rest)
\end{array}
\end{math}
\medskip

\item[$2'.$~~{\it Querying the database:}] ~ \\
If \,$b\sigma$\, and \,$rest\,\sigma$\, share no variables, and
\,\mbox{$\doracle(\bD) \models^c (\exists)\, b\sigma$},\, then
%%
\medskip\newline
\begin{math}
\begin{array}{l}
\bP,\bD_1\ldots\bD_n\dbseq ~\infers~ (\exists)\,rest\,\sigma \\
\hline
\bP,\bD_1\ldots\bD_n\dbseq ~\infers~ (\exists)\,(b \otimes rest)
\end{array}
\end{math}
\medskip

\item[$3'.$~~{\it Performing elementary updates:}] ~ \\
If \,$b\sigma$\, and \,$rest\,\sigma$\, share no variables, and
\,\mbox{$\toracle(\bD_1,\bD_2) \models^c (\exists)\, b\sigma$},\, then
%%
\medskip\newline 
\begin{math}
\begin{array}{l}
\bP,\bD_2\ldots\bD_n\dbseq ~\infers~ (\exists)\,rest\,\sigma \\
\hline
\bP,\bD_1,\bD_2\ldots\bD_n\dbseq ~\infers~ (\exists)\,(b \otimes rest)
\end{array}
\end{math}
%%
\end{description}
\end{description}
%%
\end{definition}


Path \IS is a trivial extension of \IS, and there is a one-to-one
correspondence between derivations in \IS and derivations in Path
\IS.  The soundness and completeness proofs for \IS are easily
adapted to Path \IS, to give Theorem \ref{thm-path-completeness}
below.  Note that this theorem specifies the execution path both in
the $\models$ sequent and in the $\infers$ sequent.  This theorem thus
contains more information than the soundness and completeness theorems
for \IS (Theorems \ref{thm-soundness} and \ref{thm-completeness}), in
which the execution paths are unspecified.


\begin{theorem}[Soundness and Completeness of Path \IS]
\label{thm-path-completeness} ~ \\
If $\psi$ is a serial goal, then the following two statements
are equivalent:
%%
\begin{enumerate}
\item
$\bP,\bD_1,\bD_2\ldots\bD_n\,\models\,(\exists)\,\psi$

\item
The sequent ~\mbox{$\bP,\bD_1,\bD_2\ldots\bD_n\,\infers\,(\exists)\,\psi$}~ is
derivable in Path \IS.
%%
\end{enumerate}
\end{theorem}

\begin{proof}
Lemmas \ref{lem-soundness-axioms} and \ref{lem.soundness.rules} show
that the axioms and inference rules of Path \IS are sound.  This
proves that item {\it 2\/} implies item {\it 1\/} (soundness).  To
prove the converse (completeness), suppose that
~$\bP,\bD_1\ldots\bD_n\,\models\,(\exists)\,\psi$.  ~Then
~$\bP^*,\bD_1\ldots\bD_n\,\infers\, \psi'$~ is derivable in Ground \IS
for some ground instance, $\psi'$, of $\psi$, by Corollary
\ref{cor.herbrand}.\footnote{
%%
Recall that $\bP^*$ is the ground instantiation of $\bP$.}
%%
We must now show that a derivation in Ground \IS can be ``lifted'' to
a derivation in Path \IS.  That is, if $\psi$ is a serial
conjunction, and $\psi'$ is one of its ground instantiations, then
%%
\begin{center}
\begin{tabular}{lll}
   {\it if} & $\bP^*,\bD_1\ldots\bD_n\,\infers\,\psi'$
            & {\it is derivable in Ground \IS} \mg
 {\it then} & $\bP,\bD_1\ldots\bD_n\infers\,(\exists)\,\psi$
            & {\it is derivable in Path \IS}
\end{tabular}
\end{center}
%%
The proof of this is a straightforward adaptation of the proof of
Lemma~\ref{lem.lifting}.  Completeness follows immediately.
\end{proof}


Theorem~\ref{thm-path-completeness} links executional entailment with
inference in Path \IS.  The next theorem finishes the job by linking
inference in Path \IS with executional deduction in \IS.  The reader
is referred to Definition~\ref{def-exec-deduction} for a precise
description of executional deduction, and to
Section~\ref{sec-exec-as-deduct} for a description of execution paths.


\begin{theorem}
\label{thm-path-equiv}
If $\psi$ is a serial goal, then the following two statements
are equivalent:
%%
\begin{enumerate}
\item   The sequent ~$\bP,\bD_1,\bD_2\ldots\bD_n \,\infers\, (\exists)\,\psi$~
        is derivable in Path \IS.
\item   There is an executional deduction of \,$(\exists)\,\psi$\,
        in \IS whose execution path is \,$\bD_1,\bD_2\ldots\bD_n$.
\end{enumerate}
%%
\end{theorem}


\begin{proof}
Since every executional deduction is also a general deduction, it is
easy to show that item {\it 2\/} implies item {\it 1}.  The proof is a
straightforward induction on the length of executional deductions.  To
show the converse, that item {\it 1\/} implies item {\it 2}, suppose
the sequent ~$\bP,\bD_1\ldots\bD_n \,\infers\, (\exists)\,\psi$~ is
derivable in Path \IS.  Our proof is by induction on the length of
this derivation.

\paragraph{Basis:}
If a sequent is derivable in Path \IS in one step, then it is an
axiom of Path \IS.  It therefore has the form
~$\bP,\bD\,\infers\,(\,)$.  ~But ~$\bP,\bD\dbseq\,\infers\,(\,)$~ is
an axiom of \IS.  Thus, there is an executional deduction of $(\,)$
in \IS whose execution path is $\bD$.

\paragraph{Induction:}
Suppose that item {\it 1\/} implies item {\it 2\/} for all sequents
derivable in Path \IS in at most $N$ steps.  Now suppose the sequent
~$\bP,\bD_1,\bD_2\ldots\bD_n \,\infers\, (\exists)\,(b \otimes rest)$~
is derivable in Path \IS in $N+1$ steps.  There are three cases,
depending on the last rule of inference used in the derivation.
\medskip

$\bullet$
Suppose that inference rule~$1'$ is the last rule used in the
derivation.  Then the sequent ~$\bP,\bD_1\ldots\bD_n \,\infers\,
(\exists)\,(\phi\otimes rest)\sigma$~ is derivable in Path \IS in at
most $N$ steps.  Here, \,$\sigma = mgu(a,b)$\, for some rule \,$a \la
\phi$\, in $\bP$.  By induction hypothesis, there is an executional
deduction of \,$(\exists)\,(\phi\otimes rest)\sigma$\, in \IS whose
execution path is $\bD_1\ldots\bD_n$.  Using inference rule~1 in
\IS, this can be extended by one sequent to an executional deduction
of \,$(\exists)\,(b \otimes rest)$.  \,Moreover, since this extension
does not involve inference rule~3, the execution path is still
$\bD_1\ldots\bD_n$.
\medskip

$\bullet$
Suppose that inference rule~$2'$ is the last rule used in the
derivation.  Then, the sequent
~$\bP,\bD_1\ldots\bD_n\,\infers\,(\exists)\,rest\,\sigma$~ is
derivable in Path \IS in at most $N$ steps.  Here, $b\sigma$ shares no
variables with $rest\,\sigma$ and \,$\dO(\bD)\models^c (\exists)
b\sigma$.  ~By induction hypothesis, there is an executional deduction
of \,$(\exists)\,rest\,\sigma$\, in \IS whose execution path is
$\bD_1\ldots\bD_n$.  Using inference rule~2 in \IS, this can be
extended by one sequent to an executional deduction of
\,$(\exists)\,(b \otimes rest)$.  \,Since this extension does not
involve inference rule~3, the execution path is still
$\bD_1\ldots\bD_n$.
\medskip

$\bullet$
Suppose that inference rule~$3'$ is the last rule used in the
derivation.  Then, the sequent
~$\bP,\bD_2\ldots\bD_n\,\infers\,(\exists)\,rest\,\sigma$~ is
derivable in Path \IS in at most $N$ steps.  Here, $b\sigma$ shares no
variables with $rest\,\sigma$ and \,$\tO(\bD_1,\bD_2) \models^c
(\exists) b\sigma$.  ~By induction hypothesis, there is an executional
deduction of \,$(\exists)\,rest\,\sigma$\, in \IS whose execution path
is $\bD_2\ldots\bD_n$.  Using inference rule~3 in \IS, this can be
extended by one sequent to an executional deduction of
\,$(\exists)\,(b \otimes rest)$. The execution path is extended to
$\bD_1,\bD_2\ldots\bD_n$.
\end{proof}


Combining Theorems \ref{thm-path-completeness} and
\ref{thm-path-equiv}, we get the following corollary, which is the
main result of this appendix.


\begin{corollary}[Executional Soundness and Completeness of \IS]
\label{cor-completeness-exec} ~ \\
If $\psi$ is a serial goal, then the following two statements
are equivalent:
%%
\begin{enumerate}
\item   $\bP,\bD_1,\bD_2\ldots\bD_n ~\models ~(\exists)\,\psi$.
\item   There is an executional deduction of \,$(\exists)\,\psi$\,
        in \IS whose execution path is \,$\bD_1,\bD_2\ldots,\bD_n$.
\end{enumerate}
%%
\end{corollary}




%%\newpage

\section{Appendix: Soundness of \ISD}
\label{app-hypo-sound}

In Section~\ref{sec-proof-hypo}, we developed \ISD, an inference
system for specifying and executing hypothetical as well as committed
transactions. This appendix proves that \ISD is sound.  Unlike
completeness, soundness holds for arbitrary transaction formulas and
transaction bases, and does not require the serial-Horn conditions of
Sections~\ref{sec-serial-horn} and~\ref{sec-Dserial-horn}.

For convenient reference, we reproduce below the axioms and inference
rules of system \ISD, developed in Sections~\ref{sec-inference1},
\ref{sec-inference2}, and~\ref{sec-proof-hypo}.  To simplify references
during proofs, we have re-numbered the rules.  Thus, rules~$1$
and~$1'$ are now called 1$f$ and 1$r$, respectively.  The adornments
$f$ and $r$ indicate whether rules correspond to forward or reverse
execution during top-down inference.  Recall that the inference system
assumes a data oracle, $\doracle$, and a state transition oracle,
$\toracle$.  As described in Sections \ref{sec-syntax} and
\ref{sec-semantics}, the data oracle specifies the semantics of
database states, and the transition oracle specifies the semantics of
elementary state transitions.  The rest of this appendix assumes that
these two oracles are given.


\begin{definition}{Inference System \ISD}
\label{def-inf-hypo}
If $\bP$ is a transaction base, then \ISD is the following system of
axioms and inference rules, where $\bD$ and $\bD_i$ are any database
state identifiers.
%%
\begin{description}
\item[Axioms:]~
%%
\medskip\\
$\bP,\bD\dbseq ~\infers~ (\,)$
%%
\medskip\\
$\bP,\dbseq\bD ~\infers~ (\,)$

\item[Inference Rules:]
In the rules below, $\sigma$ is a substitution, $a$ and $b$ are atomic
formulas, and $\phi$,~$rest$ and $test$ are $\Diamond$-serial goals.
%%
\begin{description}

\item[{\it Applying transaction definitions:}]
~Suppose \,$a \la \phi$\, is a rule in $\bP$ whose variables have been
renamed so that the rule shares no variables with $b \otimes rest$.
If $a$ and $b$ unify with mgu $\sigma$, then:
\medskip\\
%%
$1f.$~~~
\begin{math}
\begin{array}{l}
\bP,\bD\dbseq ~\infers~ (\exists)\,(\phi \otimes rest)\sigma \\
\hline
\bP,\bD\dbseq ~\infers~ (\exists)\,b \otimes rest
\end{array}
\end{math}
\medskip\\
%%
$1r.$~~~
\begin{math}
\begin{array}{l}
\bP,\dbseq\bD ~\infers~ (\exists)\,(rest \otimes \phi)\sigma \\
\hline
\bP,\dbseq\bD ~\infers~ (\exists)\,rest \otimes b
\end{array}
\end{math}
\medskip

\item[{\it Querying the database:}]
~If $b\sigma$ and $rest\,\sigma$ share no variables, and
\,$\doracle(\bD) \models^c \,(\exists) \,b\sigma$,\, then
\medskip\\
%%
$2f.$~~~
\begin{math}
\begin{array}{l}
\bP,\bD\dbseq ~\infers~ (\exists)\,rest\,\sigma  \\
\hline
\bP,\bD\dbseq ~\infers~ (\exists)\,b \otimes rest
\end{array}
\end{math}
\medskip\\
%%
$2r.$~~~
\begin{math}
\begin{array}{l}
\bP,\dbseq\bD ~\infers~ (\exists)\,rest\,\sigma \\
\hline
\bP,\dbseq\bD ~\infers~ (\exists)\,rest \otimes b
\end{array}
\end{math}
\medskip

\item[{\it Performing elementary transitions:}]
~If $b\sigma$ and $rest\,\sigma$ share no variables, then:
\medskip\\
%%
$3f.$~~~
\begin{math}
\begin{array}{l}
\bP,\bD_2\dbseq ~\infers~ (\exists)\,rest\,\sigma \\
\hline
\bP,\bD_1\dbseq ~\infers~ (\exists)\,b \otimes rest
\end{array}
\end{math}
~~~~if \, $\toracle(\bD_1,\bD_2) \models^c \,(\exists)\, b\sigma$
\medskip\\
%%
$3r.$~~~
\begin{math}
\begin{array}{l}
\bP,\dbseq\bD_2 ~\infers~ (\exists)\,rest\,\sigma \\
\hline
\bP,\dbseq\bD_1 ~\infers~ (\exists)\,rest \otimes b
\end{array}
\end{math}
~~~~if \,$\toracle(\bD_2,\bD_1) \models^c \,(\exists) \,b\sigma$
\medskip

\item[{\it Introduction of modalities:}]
~If \,$test\,\sigma$\, and $rest\,\sigma$ share no variables, then
\medskip\\
%%
$4f.$~~~
\begin{math}
\begin{array}{l}
\bP,\bD\dbseq~\infers~(\exists) test\,\sigma ~~~~~~~~~
             \bP,\bD\dbseq~\infers~(\exists)\,rest\,\sigma \\
\hline
\bP,\bD\dbseq~\infers~(\exists)\,(\Diamond test) \otimes rest
\end{array}
\end{math}
\medskip\\
%%
$4r.$~~~
\begin{math}
\begin{array}{l}
\bP,\dbseq\bD~\infers~(\exists)\,rest\,\sigma ~~~~~~~~~
             \bP,\dbseq\bD~\infers~(\exists) test\,\sigma \\
\hline
\bP,\dbseq\bD~\infers~(\exists)\,rest \otimes (test \Diamond)
\end{array}
\end{math}
\medskip

\item[{\it Mixed introduction of modalities:}]
~If \,$test\,\sigma$\, and $rest\,\sigma$ share no variables, then
\medskip\\
%%
$5f.$~~~
\begin{math}
\begin{array}{l}
\bP,\dbseq\bD~\infers~(\exists) test\,\sigma ~~~~~~~~~
             \bP,\bD\dbseq~\infers~(\exists)\,rest\,\sigma\\
\hline
\bP,\bD\dbseq~\infers~(\exists)\,(test \Diamond) \otimes rest
\end{array}
\end{math}
\medskip\\
%%
$5r.$~~~
\begin{math}
\begin{array}{l}
\bP,\dbseq\bD~\infers~(\exists)\,rest\,\sigma ~~~~~~~~~
             \bP,\bD\dbseq~\infers~(\exists) test\,\sigma \\
\hline
\bP,\dbseq\bD~\infers~(\exists)\,rest \otimes (\Diamond test)
\end{array}
\end{math}

\end{description}
\end{description}
%%
\end{definition}


\begin{theorem}[Soundness of \ISD]
\label{thm-hypo-soundness}
Let $\phi$ be a transaction formula.
\[
  {\it If}~~~~ \bP,\bD\dbseq\,\infers\,\phi
  ~~~~{\it then}~~~~ \bP,\bD\dbseq\models\phi
\]
%%
\[
  {\it If}~~~~ \bP,\dbseq\bD\,\infers\,\phi
  ~~~~{\it then}~~~~ \bP,\dbseq\bD\models\phi
\]
\end{theorem}


To prove Theorem \ref{thm-hypo-soundness}, it is enough to show that
the axioms and inference rules of system \ISD are sound.
Lemma~\ref{lem-soundness-axioms} shows that the axioms are sound.
Lemma~\ref{lem.soundness.rules} shows that inference rules~1$f$, 2$f$
and~3$f$ are sound.  Lemma~\ref{lem.soundness.rules2} below shows that
inference rules~4$f$ and~5$f$ are sound.  Similar results (with
similar proofs) hold for inference rules~1$r$ to~5$r$.


\begin{lemma}
\label{lem.soundness.rules2}
Suppose $rest$ and $test$ are two transaction formulas, and $\sigma$
is a substitution such that \,$test\,\sigma$\, and $rest\,\sigma$ share no
variables.
%%
\begin{enumerate} \setcounter{enumi}{3}
\item
If ~~~$\bP,\bD_1,\bD_2'...\bD_m'\models (\exists)\,test\,\sigma$~~~
and ~~~$\bP,\bD_1,\bD_2...\bD_n\models (\exists)\,rest\,\sigma$ \sg
then ~~~$\bP,\bD_1,\bD_2...\bD_n\models (\exists)\,(\Diamond test) \otimes rest$.

\item
If ~~~$\bP,\bD_m'...\bD_2',\bD_1\models (\exists)\,test\,\sigma$~~~
and ~~~$\bP,\bD_1,\bD_2...\bD_n\models (\exists)\,rest\,\sigma$ \sg
then ~~~$\bP,\bD_1,\bD_2...\bD_n\models (\exists)\,(test \Diamond) \otimes rest$.

\end{enumerate}
\end{lemma}


\begin{proof}~
To prove item {\it 4}, suppose that the {\it if\/} part is true.
Then, for every model, $\bM$, of $P$,
\mg
\mbox{~~~~~~}
\begin{tabular}{lll}
  $\bM,\tuple{\bD_1~\bD_2'~...~\bD_m'}\models (\exists)\,test\,\sigma$ \\
  ~~~{\it and}~~~
  $\bM,\tuple{\bD_1~\bD_2~...~\bD_n}\models (\exists)\,rest\,\sigma$
  & by Definition~\ref{def-query}; \mg

  $\bM,\tuple{\bD_1~\bD_2'~...~\bD_m'}\models_\nu test\,\sigma$ 
  & for some variable assignment, $\nu$, which exists \\
  ~~~{\it and}~~~
  $\bM,\tuple{\bD_1~\bD_2~...~\bD_n}\models_{\nu} rest\,\sigma$~~~
  & since $test\,\sigma$
  and $rest\,\sigma$ share no variables; \mg

  $\bM,\tuple{\bD_1~\bD_2'~...~\bD_m'}\models_{\mu} test$ \\
  ~~~{\it and}~~~
  $\bM,\tuple{\bD_1~\bD_2~...~\bD_n}\models_{\mu} rest$~~~
  & where \,$\mu(X) = \nu(X\sigma)$\, for all variables, $X$; \mg

  $\bM,\tuple{\bD_1}\models_{\mu} \Diamond test$ \\
  ~~~{\it and}~~~
  $\bM,\tuple{\bD_1~\bD_2~...~\bD_n}\models_{\mu} rest$
  & by the definition of $\Diamond$; \mg

  $\bM,\tuple{\bD_1~\bD_2~...~\bD_n}\models_{\mu} (\Diamond test) \otimes rest$
  & by Definition~\ref{def-sat-tr}; \mg

  $\bM,\tuple{\bD_1~\bD_2~...~\bD_n}\models (\exists)\,(\Diamond test) \otimes rest$
  & by Definition~\ref{def-sat-tr}.
\end{tabular}
\mg
%%
Since this is true for every model, $\bM$, of $\bP$, it follows that
~$\bP,\bD_1,\bD_2...\bD_n\models (\exists)\,(\Diamond test) \otimes rest$.
\medskip

To prove item {\it 5}, suppose that the {\it if\/} part is true.
Then, for every model, $\bM$, of $P$,
\mg
\mbox{~~~~~~}
\begin{tabular}{lll}
  $\bM,\tuple{\bD_m'~...~\bD_2'~\bD_1}\models (\exists)\,test\,\sigma$ \\
  ~~~{\it and}~~~
  $\bM,\tuple{\bD_1~\bD_2~...~\bD_n}\models (\exists)\,rest\,\sigma$
  & by Definition~\ref{def-query}; \mg

  $\bM,\tuple{\bD_m'~...~\bD_2',\bD_1}\models_\nu test\,\sigma$
  & for some variable assignment, $\nu$, which exists\\
  ~~~{\it and}~~~
  $\bM,\tuple{\bD_1~\bD_2~...~\bD_n}\models_{\nu} rest\,\sigma$~~~
  & since $test\,\sigma$
  and $rest\,\sigma$ share no variables; \mg

  $\bM,\tuple{\bD_m'~...~\bD_2',\bD_1}\models_{\mu} test$ \\
  ~~~{\it and}~~~
  $\bM,\tuple{\bD_1~\bD_2~...~\bD_n}\models_{\mu} rest$~~~
  & where \,$\mu(X) = \nu(X\sigma)$\, for all variables, $X$; \mg

  $\bM,\tuple{\bD_1}\models_{\mu} test \Diamond$ \\
  ~~~{\it and}~~~
  $\bM,\tuple{\bD_1~\bD_2~...~\bD_n}\models_{\mu} rest$
  & by the definition of $\Diamond$; \mg

  $\bM,\tuple{\bD_1~\bD_2~...~\bD_n}\models_{\mu} (test \Diamond) \otimes rest$
  & by Definition~\ref{def-sat-tr}; \mg

  $\bM,\tuple{\bD_1~\bD_2~...~\bD_n}\models (\exists)\,(test \Diamond) \otimes rest$
  & by Definition~\ref{def-sat-tr}.
\end{tabular}
\mg
%%
Since this is true for every model, $\bM$, of $\bP$, it follows that
~$\bP,\bD_1,\bD_2...\bD_n\models (\exists)\,(test \Diamond) \otimes rest$.
\end{proof}



%%\newpage

\section{Appendix: Completeness of \ISD}
\label{app-hypo-complete}

This appendix proves that inference system \ISD developed in Section
\ref{sec-proof-hypo} is complete.  Recall that \ISD is an inference
system for hypothetical and retrospective transactions as well as
committed transactions.  The axioms and inference rules of \ISD are
reproduced in Appendix~\ref{app-hypo-sound}.  We shall use the
numbering system given there to identify inference rules, {\it i.e.},
1$f$, 1$r$, 2$f$, 2$r$, etc.

As in Appendix \ref{app.complete}, our strategy is to first prove
completeness of ground inference using a canonical-model construction.
We then prove completeness of general inference using a Herbrand
theorem and a lifting lemma.  As in the other appendices, we assume
that a Transition Oracle, $\toracle$, and a Data Oracle, $\doracle$,
are given.  We also assume that all transactions are $\Diamond$-serial
conjunctions, that the transaction base is a set of $\Diamond$-serial
Horn rules, and that the other conditions of
Definition~\ref{def-serial-horn2} are satisfied.


\subsection{Ground Inference}
\label{sec-hypo-ground-inf}

This section develops a ground version of inference system \ISD called
{\it Ground \ISD}.  As in the case of Ground \IS, this inference
system keeps track of transaction execution paths and is an important
auxiliary construction used in the proof of completeness.  Systems
\ISD and Ground \ISD use the same data oracle, $\dO$, and the same
transition oracle, $\tO$.  Both systems thus have the same set of
database state identifiers, and the same semantics for states and
transitions.  In addition to the $\Diamond$-serial Horn conditions,
this subsection assumes that the transaction base $\bP$ and all
transaction invocations are ground.

Ground \ISD uses two kinds of sequents.  They are based on two
turnstyles, $\finfers$ and $\rinfers$, which correspond to the two kinds
of sequent in inference system \ISD.  Specifically, the sequent
~$\bP,\bD_1...\bD_n\,\finfers\,\phi$~ corresponds to
~$\bP,\bD_1\dbseq\infers\phi$,~ while the sequent
~$\bP,\bD_n...\bD_1\,\rinfers\,\phi$~ corresponds to
~$\bP,\dbseq\bD_1\infers\phi$.  ~From the perspective of top-down (or
goal-directed) inference, $\finfers$ corresponds to the forward (or
normal) execution of transactions, while $\rinfers$ corresponds to
reverse execution.


\begin{definition}{Inference in Ground \ISD}
\label{def-inf-hypo-ground}
Let $\bP$ be a (possibly infinite) ground $\Diamond$-serial Horn
transaction base.  Then Ground \ISD is the following system of axioms
and inference rules, where $\bD$ and $\bD_i$ are any database state
identifiers.\footnote{
%%
Note that the databases need not be ground; that is, $\doracle(\bD)$
may contain variables.}
%%
\begin{description}
\item[Axioms:]~
%%
\medskip\\
$\bP,\bD ~\finfers~ (\,)$
%%
\medskip\\
$\bP,\bD ~\rinfers~ (\,)$

\item[Inference Rules:]
In the rules below, $b$ is a ground atomic formula, and $\phi,~rest$
and $test$ are ground $\Diamond$-serial goals.
%%
\begin{description}

\item[{\it Applying transaction definitions:}]
If \,$b \la \phi$\, is a rule in $\bP$, then
\medskip\\
%%
$1f.$~~~
\begin{math}
\begin{array}{l}
\bP,\bD_1...\bD_n ~\finfers~ \phi \otimes rest \\
\hline
\bP,\bD_1...\bD_n ~\finfers~ b \otimes rest
\end{array}
\end{math}
\medskip\\
%%
$1r.$~~~
\begin{math}
\begin{array}{l}
\bP,\bD_n...\bD_1 ~\rinfers~ rest \otimes \phi \\
\hline
\bP,\bD_n...\bD_1 ~\rinfers~ rest \otimes b
\end{array}
\end{math}
\medskip

\item[{\it Querying the database:}]
If \,$\doracle(\bD_1) \models^c b$,\, then
\medskip\\
%%
$2f.$~~~
\begin{math}
\begin{array}{l}
\bP,\bD_1...\bD_n ~\finfers~ rest \\
\hline
\bP,\bD_1...\bD_n ~\finfers~ b \otimes rest
\end{array}
\end{math}
\medskip\\
%%
$2r.$~~~
\begin{math}
\begin{array}{l}
\bP,\bD_n...\bD_1 ~\rinfers~ rest \\
\hline
\bP,\bD_n...\bD_1 ~\rinfers~ rest \otimes b
\end{array}
\end{math}
\medskip

\item[{\it Performing elementary transitions:}] ~
\medskip\\
%%
$3f.$~~~
\begin{math}
\begin{array}{l}
\bP,\bD_2...\bD_n ~\finfers~ rest \\
\hline
\bP,\bD_1,\bD_2...\bD_n ~\finfers~ b \otimes rest
\end{array}
\end{math}
~~~~if \,$\toracle(\bD_1,\bD_2) \models^c b$
\medskip\\
%%
$3r.$~~~
\begin{math}
\begin{array}{l}
\bP,\bD_n...\bD_2 ~\rinfers~ rest \\
\hline
\bP,\bD_n...\bD_2,\bD_1 ~\rinfers~ rest \otimes b
\end{array}
\end{math}
~~~~if \,$\toracle(\bD_2,\bD_1) \models^c b$
\medskip

\item[{\it Introduction of modalities:}] ~
\medskip\\
%%
$4f.$~~~
\begin{math}
\myfrac
{\textstyle  \bP,\bD_1,\bD_2'...\bD_m'~\finfers~test~~~~~~~~~
             \bP,\bD_1,\bD_2...\bD_n~\finfers~rest}
{\textstyle  \bP,\bD_1,\bD_2...\bD_n~\finfers~(\Diamond test) \otimes rest}
\end{math}
\medskip\\
%%
$4r.$~~~
\begin{math}
\myfrac
{\textstyle  \bP,\bD_n...\bD_2,\bD_1~\rinfers~rest~~~~~~~~~
             \bP,\bD_m'...\bD_2',\bD_1~\rinfers~test}
{\textstyle  \bP,\bD_n...\bD_2,\bD_1~\rinfers~rest \otimes (test \Diamond)}
\end{math}
\medskip

\item[{\it Mixed introduction of modalities:}] ~
\medskip\\
%%
$5f.$~~~
\begin{math}
\myfrac
{\textstyle  \bP,\bD_m'...\bD_2',\bD_1~\rinfers~test~~~~~~~~~
             \bP,\bD_1,\bD_2...\bD_n~\finfers~rest}
{\textstyle  \bP,\bD_1,\bD_2...\bD_n~\finfers~(test \Diamond) \otimes rest}
\end{math}
\medskip\\
%%
$5r.$~~~
\begin{math}
\myfrac
{\textstyle  \bP,\bD_n...\bD_2,\bD_1~\rinfers~rest~~~~~~~~~
             \bP,\bD_1,\bD_2'...\bD_m'~\finfers~test}
{\textstyle  \bP,\bD_n...\bD_2,\bD_1~\rinfers~rest \otimes (\Diamond test)}
\end{math}

\end{description}
\end{description}
%%
\end{definition}


The soundness of Ground \ISD follows immediately from the proof of
soundness of \ISD (Theorem \ref{thm-hypo-soundness}).  We thus have
the following result.

\begin{theorem}[Soundness of Ground \ISD]
\label{thm-hypo-soundness-ground}
Let $\psi$ be a ground $\Diamond$-serial goal.
\[
        {\it If}~~~~ \bP,\bD_1...\bD_n\,\xinfers\,\psi
        ~~~~{\it then}~~~~ \bP,\bD_1...\bD_n\models\psi
\]
where $x \in \{f,r\}$.
\end{theorem}


Below, we give some properties of Ground \ISD.  The properties in
Lemma~\ref{lem-hypo-inf-properties} are special cases of the inference
rules with $rest = (\,)$.  Lemma~\ref{lem-hypo-inf-split} is a bit
more difficult, and is central to our proof of completeness of the
ground inference.
%%
%We also use the symbol $\xinfers$ to mean either $\finfers$ or
%$\rinfers$.


\begin{lemma}[Basic Properties]
\label{lem-hypo-inf-properties}
Ground \ISD has the following properties, where $b$ is a ground atomic
formula, $\phi$ is a $\Diamond$-serial goal, and $x \in \{f,r\}$:
%%
\begin{itemize}
\item
If ~$b \leftarrow \phi$~ is a rule in $\bP$ and if
~$\bP,\bD_1...\bD_n\,\xinfers\,\phi$ ~~then~~
$\bP,\bD_1...\bD_n\,\xinfers\,b$

\item
If ~$\doracle(\bD) \models^c b$~ then ~$\bP,\bD\,\xinfers\,b$

\item
If ~$\toracle(\bD_1,\bD_2) \models^c b$~ then
~$\bP,\bD_1,\bD_2\,\xinfers\,b$

\item
If ~$\bP,\bD_1...\bD_n\,\finfers\,\phi$~
then ~$\bP,\bD_1\,\xinfers\,\Diamond\phi$

\item
If ~$\bP,\bD_n...\bD_1\,\rinfers\,\phi$~
then ~$\bP,\bD_1\,\xinfers\,\phi\Diamond$

\end{itemize}
\end{lemma}



\begin{lemma}
\label{lem-hypo-inf-split}
Ground \ISD has the following property, where $\alpha$ and $\beta$ are
ground $\Diamond$-serial goals, and $x \in \{r,f\}$,
\[
        {\it If}~~~ \bP,\bD_1...\bD_i\,\xinfers\,\alpha ~~~{\it and}~~~
        \bP,\bD_i...\bD_n\,\xinfers\,\beta ~~~{\it then}~~~
        \bP,\bD_1...\bD_n\,\xinfers\,\alpha \otimes \beta
\]
\end{lemma}

\begin{proof}
~We prove the lemma for $\finfers$; the proof for $\rinfers$ is
similar.  The proof is similar to, but more complex than the proof of
Lemma~\ref{lem.inf.split}.  We transform a derivation of
~$\bP,\bD_1...\bD_i\,\finfers\,\alpha$~ into a derivation of
~$\bP,\bD_1...\bD_n\,\finfers\,\alpha \otimes \beta$.  ~The proof is
by induction on the length of the derivation of
~$\bP,\bD_1...\bD_i\,\finfers\,\alpha$.  ~(The proof for $\rinfers$ is
by induction on the length of the derivation of
~$\bP,\bD_i...\bD_n\,\rinfers\,\beta$.)

\paragraph{Basis:} Suppose that the sequent
\,$\bP,\bD_1...\bD_i\,\finfers\,\alpha$\, can be derived in 1 step.
It is therefore an axiom, so $i=1$ and $\alpha = (\,)$.  Thus,
\,$\alpha \otimes \beta = \beta$,\, so the sequent
\,$\bP,\bD_1...\bD_n\,\finfers\,\alpha \otimes \beta$ is identical to
the sequent \,$\bP,\bD_1...\bD_n\,\finfers\,\beta$,\, which is
identical to the sequent \,$\bP,\bD_i...\bD_n\,\finfers\,\beta$,\,
which is given to be true.

\paragraph{Induction:} Suppose the lemma is true for derivations of
length at most $N$, and suppose the expression
~$\bP,\bD_1...\bD_i\,\finfers\, \alpha$~ can be derived in $N+1$
steps.  We must show that the sequent
~\mbox{$\bP,\bD_1...\bD_n\,\finfers\, \alpha \otimes \beta$}~ is
derivable.  There are five cases, depending on the last inference rule
used in the derivation of ~$\bP,\bD_1...\bD_i\,\finfers\, \alpha$.
\medskip

$\bullet$ For inference rules~1$f$, 2$f$, and~3$f$, the proof is
essentially identical to the proof of Lemma~\ref{lem.inf.split}.
\medskip

$\bullet$ If inference rule~4$f$ is the last rule used in the
derivation, then $\alpha$ has the form \,$(\Diamond test) \otimes
rest$.  Moreover, ~\mbox{$\bP, \bD_1, \bD_2' ...
\bD_m'\,\finfers\,test$}~ for some databases $\bD_2'...\bD_m'$, and
the sequent ~\mbox{$\bP,\bD_1...\bD_i\,\finfers\, rest$}~ can be
derived in at most $N$ steps.  Thus, by induction hypothesis, the
sequent ~\mbox{$\bP,\bD_1...\bD_n\,\finfers\, rest \otimes \beta$}~ is
derivable.  Hence, by rule~4$f$, ~\mbox{$\bP,\bD_1...\bD_n\,\finfers\,
(\Diamond test) \otimes rest \otimes \beta$},~ which is synonymous
with ~$\bP,\bD_1...\bD_n\,\finfers\, \alpha\otimes\beta$.
\medskip

$\bullet$ If inference rule~5$f$ is the last rule used in the
derivation, then $\alpha$ has the form \,$(test \Diamond) \otimes
rest$.  Moreover, ~\mbox{$\bP, \bD_m'... \bD_2', \bD_1\,
\rinfers\,test$}~ for some databases $\bD_m' ...  \bD_2'$, and the
sequent ~\mbox{$\bP, \bD_1 ... \bD_i\, \finfers\, rest$}~ can be
derived in at most $N$ steps.  Thus, by induction hypothesis, the
sequent ~\mbox{$\bP,\bD_1...\bD_n\,\finfers\, rest \otimes \beta$}~ is
derivable.  ~Hence, by rule~5$f$,
~\mbox{$\bP,\bD_1...\bD_n\,\finfers\, (test \Diamond) \otimes rest
\otimes \beta$},~ which is synonymous with
~\mbox{$\bP,\bD_1...\bD_n\,\finfers\, \alpha\otimes\beta$}.
\end{proof}


\subsection{Completeness of Ground \ISD}
\label{sec-hypo-canonical}

To prove the completeness of Ground \ISD, we construct a canonical
Herbrand model of the transaction base $\bP$.  This model,
constructed proof theoretically, provides the necessary link between
the proof theory and model theory.  Again, in addition to the
$\Diamond$-serial Horn conditions, this subsection assumes that the
transaction base $\bP$ and all transaction invocations are ground.

Given a language for \TR, we define the Herbrand universe and classical
Herbrand interpretations in a standard way, as in Appendix
\ref{sec.canonical}.  The symbol $\HB$ shall denote the set of all ground
atomic formulas, {\it i.e.}, the Herbrand base.
%% The Herbrand base does not include the special predicates $\state$,
%% $\aarc$ and $\ppath$.
There is a 1--1 correspondence between Herbrand interpretations and subsets
of $\HB$, so we shall often treat them as the same thing.  Recall from
Appendix~\ref{sec.canonical} that Herbrand path structures are determined
by the mapping $\ipath$ alone, since the domain and the interpretation of
function symbols are fixed.


\begin{definition}{Canonical Model} 
\label{def-hypo-model-canonic}
The canonical model of a transaction base $\bP$ is the Herbrand path
structure \,$\canonic{\bP} = \tup{\ipath}$,\, where
%%
\begin{center}
\begin{tabular}{rcl}
   $\ipath(\tuple{\bD_1~...~\bD_n})$ & = &
          $\{~ b \in \HB~~|~~ \bP,\bD_1...\bD_n \,\finfers\, b 
              ~~~{\it and}~~~ \bP,\bD_1...\bD_n \,\rinfers\, b ~\}$
\end{tabular}
\end{center}
\vspace{-6mm}
\end{definition}

We first observe that $\canonic{\bP}$ is a legitimate path structure.
This follows immediately from Definition~\ref{def-structures} and the
following lemma.

\begin{lemma} \label{lem-hypo-structure}
%%
Let $\canonic{\bP} = \tup{\ipath}$ be the canonical model of $\bP$.
Then:
%%
\begin{romanEnum}
\item 
  $\ipath(\tuple{\bD}) \models^c \phi$~ for every closed first-order
  formula $\phi$ in $\doracle(\bD)$
  \\(so $\canonic{\bP}, \tup{\bD} \models \phi$)
\item
  $\ipath(\tup{\bD_1~\bD_2})\models^c b$~ for every $b$ in
   $\toracle(\bD_1,\bD_2)$
   \\(so $\canonic{\bP}, \tup{\bD_1~\bD_2} \models b$)
\end{romanEnum}
%%
\end{lemma}

\begin{proof}
The same as for Lemma~\ref{lem.structure}.
\end{proof}

The following lemma states a basic result about canonical models; its proof
is analogous to that of Lemma~\ref{lem.canonical0}.
Theorem \ref{thm-hypo-canonical1} partially generalizes
this result from atoms to $\Diamond$-serial goals.
Corollary~\ref{lem-compl-ground-ISD}, below, is a full generalization of
this result.
%%
\begin{lemma}
\label{lem-hypo-canonical0}
If $b$ is a ground atomic formula, then
\[
        \canonic{\bP},\tuple{\bD_1~...~\bD_n} \models b
        ~~~~{\it iff}~~~~
        \bP,\bD_1...\bD_n \,\finfers\, b
        ~~~{\it and}~~~
        \bP,\bD_1...\bD_n \,\rinfers\, b
\]
\end{lemma}


\begin{theorem} 
\label{thm-hypo-canonical1}
Let $\phi$ be a ground $\Diamond$-serial goal.
\[
        {\it If}~~~~
        \canonic{\bP},\tuple{\bD_1~...~\bD_n} \models \phi
        ~~~~{\it then}~~~~
        \bP,\bD_1...\bD_n \,\xinfers\, \phi
\]
where $x \in \{f,r\}$.
\end{theorem}

\begin{proof}
The proof is by induction on the number of logical operators in
$\phi$.  In the base case, $\phi$ is a singleton $\Diamond$-serial
goal, that is, either a ground atomic formula or the empty clause
($i.e.$, $\state$).  In the former case, the result follows by Lemma
\ref{lem-hypo-canonical0}.  In the later case, if the expression
\,$\canonic{\bP},\tuple{\bD_1~...~\bD_n} \models (\,)$\, is true, then
$n=1$, since the empty clause is true only on states.  But, the
sequent \,$\bP,\bD_1\,\xinfers\,(\,)$\, is trivially true, since it is
an axiom.

For the inductive case, assume the theorem is true for formulas with
at most $N$ logical operators, and suppose that $\phi$ has $N+1$
logical operators.  There are three cases, one for each type of
operator.
%%
\begin{itemize}
\item
If $\phi$ has the form $\phi_1 \otimes \phi_2$, then $\phi_1$ and
$\phi_2$ have at most $N$ logical operators each.  Thus,
%%
\begin{center}
\begin{tabular}{ll}
$\canonic{\bP},\tuple{\bD_1~...~\bD_n} \models \phi_1 \otimes \phi_2$
        & given; \sg
$\canonic{\bP},\tuple{\bD_1~...~\bD_i} \models \phi_1$
~~~{\it and}~~~
$\canonic{\bP},\tuple{\bD_i~...~\bD_n} \models \phi_2$ 
~~~~    & for some $i$, by Definition~\ref{def-sat-tr}; \sg
$\bP,\bD_1...\bD_i\,\xinfers\,\phi_1$
~~~{\it and}~~~ $\bP,\bD_i...\bD_n\,\xinfers\,\phi_2$ 
        & by induction hypothesis; \sg
$\bP,\bD_1...\bD_n\,\xinfers\,\phi_1\otimes\phi_2$
        & by Lemma~\ref{lem-hypo-inf-split}.
\end{tabular}
\end{center}

\item
If $\phi$ has the form $\Diamond\psi$, then $\psi$ has at most $N$
logical operators, and $n=1$, since executional modal formulas are true
only on states.  Thus,
%%
\begin{center}
\begin{tabular}{ll}
  $\canonic{\bP},\tuple{\bD_1} \models \Diamond\psi$ & given; \sg
  $\canonic{\bP},\tuple{\bD_1~\bD_2'~...~\bD_m'} \models \psi$ & for some
  databases $\bD_2'...\bD_m'$, by definition; \sg
  $\bP,\bD_1,\bD_2'...\bD_m'\,\finfers\,\psi$ & by induction
  hypothesis; \sg 
  $\bP,\bD_1\,\xinfers\,\Diamond\psi$ & by Lemma
  \ref{lem-hypo-inf-properties}.
\end{tabular}
\end{center}

\item
If $\phi$ has the form $\psi\Diamond$, then $\psi$ has at most $N$
logical operators, and $n=1$, since retrospective formulas are true
only on states.  Thus,
%%
\begin{center}
\begin{tabular}{ll}
  $\canonic{\bP},\tuple{\bD_1} \models \psi\Diamond$ & given \sg
  $\canonic{\bP},\tuple{\bD_m'~...~\bD_2',\bD_1} \models \psi$ & for some
  databases $\bD_m'...\bD_2'$, by definition; \sg
  $\bP,\bD_m'...\bD_2',\bD_1\,\rinfers\,\psi$ & by induction
  hypothesis; \sg
  $\bP,\bD_1\,\xinfers\,\Diamond\psi$ & by Lemma
  \ref{lem-hypo-inf-properties}.
\end{tabular}
\end{center}

\end{itemize}
\end{proof}


\begin{theorem}
\label{thm-hypo-canonical2}
~$\canonic{\bP}$ is a model of $\bP$.
\end{theorem}

\begin{proof}
Let \,$b \leftarrow \phi$\, be any rule in $\bP$.  Then, for any path
$\tuple{\bD_1~...~\bD_n}$,
%%
\begin{center}
\begin{tabular}{lll}
{\it if}
 & $\canonic{\bP},\tuple{\bD_1~...~\bD_n} \,\models\, \phi$ \sg
{\it then}
 & $\bP,\bD_1...\bD_n \,\xinfers\, \phi$
   & for $x \in \{f,r\}$,\, by Theorem \ref{thm-hypo-canonical1}, \sg

 & $\bP,\bD_1...\bD_n \,\xinfers\, b$
   & by Lemma~\ref{lem-hypo-inf-properties}, \sg

 & $\canonic{\bP},\tuple{\bD_1~...~\bD_n} \,\models\, b$
   & by Lemma~\ref{lem-hypo-canonical0}.
\end{tabular}
\end{center}
%%
$\canonic{\bP}$ thus satisfies the rule \,$b \leftarrow \phi$\, on
every path.  It is therefore a model of every rule in $\bP$ and, thus,
of $\bP$.
\end{proof}


To prove the completeness of \ISD, we do not need the completeness of
Ground \ISD~per se.  Instead, we need Theorems
\ref{thm-hypo-canonical1} and \ref{thm-hypo-canonical2}.  However, the
completeness of Ground \ISD has now become an easy corollary.


\begin{corollary}[Completeness of Ground \ISD]
\label{lem-compl-ground-ISD}
For any ground $\Diamond$-serial goal, $\phi$,
\[
        {\it If}~~~ \bP,\bD_1...\bD_n\,\models\,\phi
        ~~~{\it then}~~~ \bP,\bD_1...\bD_n\,\xinfers\,\phi
\]
where $x \in \{f,r\}$.
\end{corollary}

\begin{proof}
The same as for Corollary~\ref{cor.ground.completeness}.
\end{proof}


Although the proof of completeness in Ground \ISD is now finished, we
include two more important corollaries.  The first generalizes Lemma
\ref{lem-hypo-canonical0} from atoms to $\Diamond$-serial
conjunctions.  It shows that inference in Ground \ISD is equivalent to
satisfaction in the canonical model.  The second shows that in Ground
\ISD, forward and backward derivations yield the same set of sequents.


\begin{corollary}
\label{cor-hypo-canonical3}
If $\phi$ is a ground $\Diamond$-serial goal, and $x \in \{f,r\}$,\,
then
\[
        \canonic{\bP},\tuple{\bD_1~...~\bD_n} \models \phi
        ~~~~{\it iff}~~~~
        \bP,\bD_1...\bD_n \,\xinfers\, \phi
\]
\end{corollary}

\begin{proof}
The same as for Corollary~\ref{cor.canonical3}.
\end{proof}


\begin{corollary}
\label{cor-hypo-canonical4}
For any ground $\Diamond$-serial goal, $\phi$,
\[
        \bP,\bD_1...\bD_n\,\finfers\,\phi ~~~~{\it iff}~~~~
        \bP,\bD_1...\bD_n\,\rinfers\,\phi
\]
\end{corollary}

\begin{proof}
Follows immediately from Corollary~\ref{cor-hypo-canonical3}:

        \mbox{~~~~~~}
        $\bP,\bD_1...\bD_n\,\finfers\,\phi$
        ~~~~{\it iff}~~~~
        $\canonic{\bP},\tuple{\bD_1~...~\bD_n}\models\phi$
        ~~~~{\it iff}~~~~
        $\bP,\bD_1...\bD_n\,\rinfers\,\phi$
        \mbox{~~~~~~}
\end{proof}





\subsection{Completeness of \ISD}
\label{sec-hypo-lifting}

Having proved the completeness of Ground \ISD, we now prove the
completeness of \ISD itself.  As in Appendix \ref{sec.lifting}, we
first prove a result analogous to the Herbrand Theorem of classical
logic, which lets us reduce general entailment to ground inference.
We then prove a lifting lemma, to ``lift'' ground inference up to
general inference.  In this subsection, we again assume the
$\Diamond$-serial Horn conditions, but not groundness.  Thus, the
transaction base $\bP$ and transaction invocations may be
non-ground.  The ground instantiation of $\bP$ is denoted $\bP^*$.  We
shall need to distinguish between the sequents of inference systems
\ISD and Ground \ISD.  In general, sequents of the form
\,$\bP,\bD\dbseq\,\infers\,\phi$\, belong to \ISD, while sequents of
the form \,$\bP^*,\bD_1...\bD_n\,\infers_x\,\phi$\, belong to Ground
\ISD, where $x \in\{f,r\}$.


\begin{lemma}
\label{lem-hypo-herbrand-canonic}
~$\canonic{\bP^*}$ is a model of $\bP$.
\end{lemma}

\begin{proof}
The same as for Lemma~\ref{lem.herbrand.canonic}.
\end{proof}


\begin{corollary}[Herbrand's Theorem for \ISD]
\label{cor-hypo-herbrand}
Let $\phi$ be a $\Diamond$-serial goal, and $x \in \{f,r\}$.
\[
        {\it If}~~~ \bP,\bD_1...\bD_n\,\models\,(\exists)\,\phi
        ~~~{\it then}~~~ \bP^*,\bD_1...\bD_n\,\infers_x\,\phi'
\]
for some ground instance, $\phi'$, of $\phi$.
\end{corollary}

\begin{proof}
The same as for Corollary~\ref{cor.herbrand}.
\end{proof}


\begin{lemma}[Lifting Lemma for \ISD]
\label{lem-hypo-lifting}
Let $\psi$ be a $\Diamond$-serial goal, and let $\psi'$ be one
of its ground instantiations.
\[
      {\it If}~~~~ \bP^*,\bD_1...\bD_n\,\infers_f\,\psi'
~~~~{\it then}~~~~ \bP,\bD_1\dbseq\,\infers\,(\exists)\,\psi
\]
\[
      {\it If}~~~~ \bP^*,\bD_n...\bD_1\,\infers_r\,\psi'
~~~~{\it then}~~~~ \bP,\dbseq\bD_1\,\infers\,(\exists)\,\psi
\]
\end{lemma}


\begin{proof}
The proof is by induction on the length of ground derivations.

\paragraph{Basis:} In this case, both sequent are axioms, so they are
both trivially true.

\paragraph{Induction:} Suppose the lemma is true for all ground
derivations having at most $N$ steps.  Now consider derivations of
$N+1$ steps.  There are ten cases, depending on the last inference
rule used in the derivation.  We shall consider only the five
$f$-rules, since proofs for the five $r$-rules are similar.  We
therefore assume that the sequent
~$\bP^*,\bD_1...\bD_n\,\infers_f\,\psi'$~ is derivable in Ground \ISD
in $N+1$ steps.
\medskip

$\bullet$ When the last inference rule used in the ground derivation
is 1$f$, 2$f$, or 3$f$, the proof is the same as in
Lemma~\ref{lem.lifting}.
\medskip

$\bullet$
Suppose inference rule~4$f$ is the last rule used in the ground derivation.
Then $\psi$ has the form $(\Diamond test) \otimes rest$,\, and $\psi'$
has the form $(\Diamond test\,\sigma) \otimes rest\,\sigma$\, for some
ground substitution $\sigma$.  Moreover, the following two sequents
are derivable in Ground \ISD in at most $N$ steps:
\[
        \bP^*,\bD_1,\bD_2'...\bD_m'\,\infers_f\,test\,\sigma ~~~~~~~~~~
        \bP^*,\bD_1,\bD_2...\bD_n\,\infers_f\,rest\,\sigma
\]
for some databases $\bD_2'...\bD_m'$.  Thus, by induction hypothesis,
the following two sequents are derivable in \ISD:
\[
        \bP,\bD_1\dbseq\,\infers\,(\exists)\,test\,\sigma ~~~~~~~~~~
        \bP,\bD_1\dbseq\,\infers\,(\exists)\,rest\,\sigma
\]
since $test\,\sigma$ and $rest\,\sigma$ are (trivially) ground
instantiations of $test\,\sigma$ and $rest\,\sigma$, respectively.
Being ground, $test\,\sigma$ and $rest\,\sigma$ share no variables.
Thus, the sequent ~$\bP,\bD_1\dbseq\,\infers\,(\exists)\,(\Diamond
test) \otimes rest$~ is derivable in \ISD, by rule~4$f$.
\medskip

$\bullet$
Suppose inference rule~5$f$ is the last one used in the ground derivation.
Then $\psi$ has the form $(test \Diamond) \otimes rest$,\, and
$\psi'$ has the form $(test\,\sigma\,\Diamond) \otimes
rest\,\sigma$\, for some ground substitution, $\sigma$.  Moreover, the
following two sequents are derivable in Ground \ISD in at most $N$
steps:
\[
        \bP^*,\bD_m'...\bD_2',\bD_1'\,\infers_r\,test\,\sigma ~~~~~~~~~~
        \bP^*,\bD_1,\bD_2...\bD_n\,\infers_f\,rest\,\sigma
\]
for some databases $\bD_m'...\bD_2'$.  Thus, by induction hypothesis,
the following two sequents are derivable in \ISD:
\[
        \bP,\dbseq\bD_1\,\infers\,(\exists)\,test\,\sigma ~~~~~~~~~~
        \bP,\bD_1\dbseq\,\infers\,(\exists)\,rest\,\sigma
\]
since $test\,\sigma$ and $rest\,\sigma$ are (trivially) ground
instantiations of $test\,\sigma$ and $rest\,\sigma$, respectively.
Being ground, $test\,\sigma$ and $rest\,\sigma$ share no variables.
Thus, the sequent
~$\bP,\bD_1\dbseq\,\infers\,(\exists)\,(test\Diamond) \otimes rest$~
is derivable in \ISD, by rule~5$f$.
\end{proof}


\begin{theorem}[Completeness of \ISD]
\label{thm-hypo-completeness}
Let $\phi$ be a $\Diamond$-serial goal.
\[
        {\it If}~~~~ \bP,\bD\dbseq\models(\exists)\,\phi
        ~~~~{\it then}~~~~ \bP,\bD\dbseq\,\infers\,(\exists)\,\phi
\]
%%
\[
        {\it If}~~~~ \bP,\dbseq\bD\models(\exists)\,\phi
        ~~~~{\it then}~~~~ \bP,\dbseq\bD\,\infers\,(\exists)\,\phi
\]
\end{theorem}


\begin{proof}
As in Theorem \ref{thm-completeness}.  For instance, if
~\mbox{$\bP,\bD\dbseq\models(\exists)\,\phi$,}~ then
~\mbox{$\bP,\bD,\bD_2...\bD_n\,\models\,(\exists)\,\phi$}~ for some
databases $\bD_2\ldots\bD_n$, by Definition~\ref{def-query}.  ~Thus
~\mbox{$\bP^*,\bD,\bD_2...\bD_n\,\infers_f\, \phi'$},~ where $\phi'$
is some ground instance of $\phi$, by
Corollary~\ref{cor-hypo-herbrand}.  Hence
~\mbox{$\bP,\bD\dbseq\,\infers\, (\exists)\, \phi$},~ by Lemma
\ref{lem-hypo-lifting}.
\end{proof}


Although this completes our proof of completeness, we include the
following important corollary.  It shows that inference in \ISD is
equivalent to satisfaction in the canonical model.

\begin{corollary} \label{cor-hypo-canonic}
Let $\phi$ be a $\Diamond$-serial goal. Then:
%%
\begin{center}
\begin{tabular}{llll}
   $\bP,\bD\dbseq\,\infers\,(\exists)\,\phi$
 & {\it iff}
 & $\canonic{\bP^*},\tuple{\bD~\bD_2~...~\bD_n}\models (\exists)\,\phi$
 & for some databases $\bD_2...\bD_n$. \mg

   $\bP,\dbseq\bD\,\infers\,(\exists)\,\phi$ 
 & {\it iff}
 & $\canonic{\bP^*},\tuple{\bD_n~...~\bD_2,\bD}\models (\exists)\,\phi$
 & for some databases $\bD_n...\bD_2$.
\end{tabular}
\end{center}
\end{corollary}

\begin{proof}
The same as for Corollary~\ref{cor.canonic}.
\end{proof}


%%\newpage

\section{Appendix: Executional Deduction in \ISD}
\label{app-hypo-exec}

Section~\ref{sec-hypo-exec-deduc} developed the idea of executional
deduction for hypothetical and retrospective inference.  Executional
deductions trace out the execution path of a transaction during
inference.  The proofs of soundness and completeness given in
Appendices~\ref{app-hypo-sound} and~\ref{app-hypo-complete} are for
general deductions in \ISD.  The present appendix adapts these proofs to
executional deductions in \ISD.  As in Appendix
\ref{app-hypo-complete}, we assume that all transactions are
$\Diamond$-serial goals, that the transaction base $\bP$ is a set of
$\Diamond$-serial Horn rules, and that the other conditions of
Definition~\ref{def-serial-horn2} are satisfied.

As in Appendix \ref{app-exec}, the main idea is to introduce an
intermediate inference system called {\it Path\/} \ISD.  Path \ISD is
identical to \ISD except that it records the execution path of a
transaction.  Sequents in Path \ISD have the form
~$\bP,\bD_1,\bD_2\ldots\bD_n\,\infers\,\psi$,~ which intuitively means
that \,$\bD_1,\bD_2\ldots\bD_n$\, is an (inferred) execution path for
transaction $\psi$.  Path \IS is similar to inference system Ground
\ISD developed in Appendix \ref{sec-hypo-ground-inf}, except that the
transaction base $\bP$ and the transaction $\psi$ need not be
ground.  Path \ISD is a trivial extension of \ISD, and there is a
one-to-one correspondence between derivations in \ISD and derivations
in Path \ISD.  The soundness and completeness proofs for \ISD are
thus easily adapted to Path \ISD, to give Theorem
\ref{thm-hypo-path-completeness} below.  The only remaining step is to
show that any general deduction in Path \ISD can be associated with an
executional deduction in \ISD, and vice-versa.  This is done in
Theorem \ref{thm-hypo-path-equiv} below.  The proofs are a
straightforward extension of those in Appendix \ref{app-exec}, so we
simply state the main results.


\begin{theorem}[Soundness and Completeness of Path \ISD]
\label{thm-hypo-path-completeness} ~ \\
If $\psi$ is a $\Diamond$-serial goal, then the following two
statements are equivalent:
%%
\begin{enumerate}
\item
$\bP,\bD_1,\bD_2\ldots\bD_n\,\models\,(\exists)\,\psi$

\item
The sequent ~\mbox{$\bP,\bD_1,\bD_2\ldots\bD_n\,\infers\,(\exists)\,\psi$}~ is
derivable in Path \ISD.
%%
\end{enumerate}
\end{theorem}


\begin{theorem}
\label{thm-hypo-path-equiv}
If $\psi$ is a $\Diamond$-serial goal, then the following two
statements are equivalent:
%%
\begin{enumerate}
\item   The sequent ~$\bP,\bD_1,\bD_2\ldots\bD_n \,\infers\, (\exists)\,\psi$~
        is derivable in Path \ISD.
\item   There is an executional deduction of \,$(\exists)\,\psi$\,
        in \ISD whose execution path is \,$\bD_1,\bD_2\ldots\bD_n$.
\end{enumerate}
%%
\end{theorem}


\begin{corollary}[Executional Soundness and Completeness of \ISD]
\label{cor-hypo-completeness-exec} ~ \\
If $\psi$ is a $\Diamond$-serial goal, then the following two
statements are equivalent:
%%
\begin{enumerate}
\item   $\bP,\bD_1,\bD_2\ldots\bD_n ~\models ~(\exists)\,\psi$.
\item   There is an executional deduction of \,$(\exists)\,\psi$\,
        in \ISD whose execution path is \,$\bD_1,\bD_2\ldots,\bD_n$.
\end{enumerate}
%%
\end{corollary}



\subsubsection*{Acknowledgments:}

Alberto Mendelzon provided us with many insights regarding updates of logic
theories.  Thanks to Ray Reiter for commenting on various aspects of this
paper, especially on the issues related to the frame problem.  Mariano
Consens took a very close look at the first draft and many improvements are
due to his comments.  Comments by Greg Meredith on Pratt's Action Logic,
and discussions with Dieter Fensel, G\"{o}sta Grahne, Peter Revesz,
Fangzhen Lin, Javier Pinto, Dimitris Lagouvardos, Jan Van den Bussche, Roel
Wieringa, Mark Willems, Jan Chomicki, Ron van der Meyden, and Rodney Topor
are also gratefully acknowledged.

The first author was supported in part by an Operating Grant from the
Natural Sciences and Engineering Research Council of Canada (NSERC)
and by a Connaught Grant from the University of Toronto.  The second
author was supported in part by NSF grants CCR-9102159, IRI-9404629,
and a grant from New York Science and Technology Foundation.  Support
of Computer Systems Research Institute of University of Toronto is
also gratefully acknowledged.



\input{incl.bibfile.tex}
\bibliographystyle{plain}

\end{document}




The last example also illustrates a basic principle of \TR: all
transactions are treated uniformly, whether they are queries, updates,
or a combination of both.  For instance, $withdraw(50,A)$ is a
transaction that updates the database, while $balance(B,A)$ is a
read-only transaction, that is, a query.  However, since they are both
transactions, they can be combined sequentially using $\otimes$.
Likewise, they can be combined using any of the classical operators.


