\documentclass[11pt,a4paper]{article}

\pagenumbering{arabic}
\usepackage{graphicx}
\usepackage{a4wide}
\usepackage{pjmnotes}
\usepackage{stdpjm}
\usepackage{hdm}
\usepackage{ukdate}
\usepackage{amsmath}
%\usepackage{multirow}
\usepackage{rotating}

\newcommand{\myhdms}[1]{\ensuremath{\hdms{\textsf{#1}}}}
\newcommand{\myhdmf}[1]{\ensuremath{\hdms{\textsf{\footnotesize #1}}}}

\title{\huge Database Schema Transformation Optimisation Techniques\\for the
   AutoMed System}
\author{Nerissa Tong\\
	\emph{nnyt98@doc.ic.ac.uk}}

\begin{document}
\date{Friday $8^{\ \underline{\textup{th}}}$ March 2002}
\maketitle
\bibliographystyle{alpha}

%%% Abstract
% no abstract
\begin{abstract}
\noindent
AutoMed is a database schema transformation and integration system
that is designed to support the integration of schemas expressed in
a variety of high-level conceptual modelling languages.
It is based on the idea of expressing transformations as a
sequence of primitive transformation steps, each of which is a
bi-directional mapping between schemas.  To become
an efficient schema integration system in practice, where the
number and size of schemas involved in the integration may be very large,
the amount of time spent on the evaluation of transformations must
be reduced to a minimal level.  It is also important that the
integrity of a set of transformations is maintained during the
process of transformation optimisation.  This paper discusses a
new representation of schema transformations which facilitates
the verification of the well-formedness of transformation sequences,
and the optimisation of transformation sequences.
\end{abstract}

%%% Main body
\section{Introduction}

Database integration is
essentially the generation of a global schema from a collection of
existing databases.  The process is similar to that in view
integration, where a global conceptual schema is produced as a
result of combining a set of smaller views created by individual
users.  The difference between database integration and view
integration is that database integration occurs when the databases
are in operation, wherease view integration is usually performed in
the design phase of a database.  Although these two integration
activities occur in different stages in database developement,
the techniques used are fundamentally the same.  A generic term
\textbf{schema integration}~\cite{Bat86}
is used to refer to both integration activities.

\subsection{Schema Integration Approaches}

There are generally two main approaches to schema integration.  The
\textbf{query-oriented} approach~\cite{MP02}
is adopted by a number of information
integration systems~\cite{Dus97, GPQR+97, RS97, KLS95}.
The popularity of this approach can be attributed to its
simplicity in implementation.  Source schemas are
%\emph{logically integrated}
integrated
in the definition of a set of query
templates.  Contained in each query template is a predefined query
plan which describes the location of the required data and the
method to retrieve this data.  The result is that the task of query
planning is made very simple and efficient.  However, this approach
suffers from one major drawback -- when new schemas are added to the
system or existing schemas are modified, all corresponding query
templates will have to be rewritten.  Also, the number of possible
queries that can be made to the system is restricted to the number
of query templates available.

In the \textbf{schema-oriented}
approach~\cite{MP02}
source schemas are
%\emph{physically integrated}
integrated by applying a set
of transformations to arrive at a common schema (the global schema).
Adopting this approach at the user or application level is also
very simple, yet the schema-oriented approach offers much greater
flexibility over the query-oriented approach in user-query
formulation and source schema combination.
Section~\ref{sec:automed_framework} discusses in more detail
the characteristics of this approach.


\subsection{The Need for Schema Transformation Optimisation}

The sequence of transformations defined for transforming schema
\texttt{s1} to schema \texttt{s2} is called a
\textbf{transformation pathway}
from \texttt{s1} to \texttt{s2}.
When the number and size of schemas increase, and hence the number of
transformations between
schemas increase, it is very likely to find the presence of redundant
transformations in the transformation pathways.  In particular, during
the evolution of schemas, new constructs may be added that are already
present in another schema, which is connected to the new schema via
a chain of transformations.
The aim of building the schema
transformation optimisation tool is to detect such transformations, and
rebuild the transformation pathway with the redundant transformations
removed, so as to make the execution of transformations, and hence the
materialization of intentional schemas, more efficient.
The idea of optimisation transformations
for AutoMed was initiated in~\cite{MP02} and the purpose of the work
mentioned in this paper is to find appropriate techniques for automating
these early ideas.


% The following line is only appropriate for the schema improvement tool
%Another aim
%is to provide assistance to users in detecting duplicated data and
%constructs that are not properly correlated in the schemas.

%!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
% shortening begins - nt 08/03/02
%This research is based on the framework for schema transformation
%described in~\cite{PM98}, which is being implemented in the AutoMed
%project~\cite{boy01a}
%(more details in Section~\ref{sec:automed_implementation}).  The AutoMed
%framework is described in
%Section~\ref{sec:automed_framework}, along with examples made from
%the scenario illustrated in Figure~\ref{fig:example_er}.
%Figure~\ref{fig:example_er} shows two source schemas \texttt{s1}
%and \texttt{s2}, and a global schema \texttt{sg} which is the
%result of integrating \texttt{s1} and \texttt{s2}.

The main theme of this paper is to study how optimisation of
transformations can be performed.  Section~\ref{sec:bg} gives an
overview of the AutoMed framework~\cite{MP98,PM98,MP99a,MP99b}
and a description of how schemas are transformed.
%schemas in Figure~\ref{fig:example_er} are transformed.
%Figure~\ref{fig:example_er} shows two source schemas \texttt{s1}
%and \texttt{s2}, and a global schema \texttt{sg} which is the
%result of integrating \texttt{s1} and \texttt{s2}.
We then discuss
the notation of our Transformation Manipulation Language and how
it can be used to facilitate optimisation of transformations in
Section~\ref{sec:sem_and_tml}.  Section~\ref{sec:tran_combo} gives
a summary of the results of combining pairs of different
transformations.  Section~\ref{sec:future_work} concludes the
issues discussed in the paper and gives the directions for future
work.


\begin{stdfigure}{Example ER schemas}{fig:example_er}

\stdpicmag{-2}
\small

\def\schema(#1,#2)(#3,#4)#5#6{\setlength{\fboxsep}{0em}
\put(#1,#2){\colorbox{lightgrey}{\makebox(#3,#4){}}}
\put(#1,#2){\begin{picture}(#3,#4)
#6
\end{picture}}
\put(#1,#2){\makebox(2,2){\tt #5}}}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ev2
\begin{picture}(58,80)
\schema(0,55)(58,20){ev2}{\entity(16,13){\tt person}
\entity(11,1){\tt male}
\entity(21,1){\tt female}
\generalisation(17,9){\tt sex}
\path(15,5)(15,7)(25,7)(25,5)
\path(20,7)(20,9)
\isa(20,11)(20,13)
\cardattribute(16,13)(10,12){\underline{\tt id}}{\tt 1:1}{\tt 1:1}
\cardattribute(16,15)(7,15){\tt name}{\tt 1:1}{\tt 1:N}
\cardattribute(16,17)(10,18){\tt dname}{\tt 1:1}{\tt 1:N}
\relationship(24,15)(36,15){\tiny \tt worksin}{\tt 1:1}{\tt 1:N}
\entity(36,13){\tt dept}
\cardattribute(44,15)(50,15){\underline{\tt dname}}{\tt 1:1}{\tt 1:1}}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% s1
\schema(0,25)(24,23){s1}{\entity(14,2){\tt person}
\cardattribute(14,6)(8,7){\tt sex}{\tt 1:1}{\tt 1:N}
\cardattribute(14,4)(6,4){\tt name}{\tt 1:1}{\tt 1:N}
\cardattribute(14,2)(8,1){\underline{\tt id}}{\tt 1:1}{\tt 1:1}
\relationship(18,6)(18,18){\tiny \tt worksin}{\tt 1:1}{\tt 1:N}
\entity(14,18){\tt dept}
\cardattribute(14,20)(8,20){\underline{\tt dname}}{\tt 1:1}{\tt 1:1}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% s2
\schema(26,27)(32,18){s2}{\entity(12,13){\tt person}
\entity(7,1){\texttt{male}}
\entity(17,1){\texttt{female}}
\generalisation(13,9){\tt sex}
\path(11,5)(11,7)(21,7)(21,5)
\path(16,7)(16,9)
\isa(16,11)(16,13)
\cardattribute(12,14)(6,13){\underline{\tt id}}{\tt 1:1}{\tt 1:1}
\cardattribute(12,16)(6,17){\tt name}{\tt 1:1}{\tt 1:N}
\cardattribute(20,15)(26,15){\tt dname}{\tt 1:1}{\tt 1:N}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\schema(3,1)(52,18){sg}{\entity(12,13){\tt person}
\entity(7,1){\tt male}
\entity(17,1){\tt female}
\generalisation(13,9){\tt sex}
\path(11,5)(11,7)(21,7)(21,5)
\path(16,7)(16,9)
\isa(16,11)(16,13)
\cardattribute(12,14)(6,13){\underline{\tt id}}{\tt 1:1}{\tt 1:1}
\cardattribute(12,16)(6,17){\tt name}{\tt 1:1}{\tt 1:N}
\relationship(20,15)(32,15){\tiny \tt worksin}{\tt 1:1}{\tt 1:N}
\entity(32,13){\tt dept}
\cardattribute(40,15)(46,15){\underline{\tt dname}}{\tt 1:1}{\tt 1:1}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\labvector(40,52)(40,48){\isnsref{s2ev3} .. \isnsref{s2ev1}}{}
\labvector(44,48)(44,52){}{\snsref{s2ev1} .. \snsref{s2ev3}}
\labvector(10,24)(10,20){\snsref{s11} .. \snsref{s15}}{}
\labvector(14,20)(14,24){}{\isnsref{s15} .. \isnsref{s11}}
\labvector(40,24)(40,20){\snsref{s21} .. \snsref{s24}}{}
\labvector(44,20)(44,24){}{\isnsref{s24} .. \isnsref{s21}}
\end{picture}

\end{stdfigure}

%!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
% just use the diagram with the evolved schema, saves more space - nt 07/03/02
%
%\begin{stdfigure}{Example ER schemas, and the transformations that relate them}{fig:example_er}
%
%\stdpicmag{-2}
%\small
%
%\def\schema(#1,#2)(#3,#4)#5#6{\setlength{\fboxsep}{0em}
%\put(#1,#2){\colorbox{lightgrey}{\makebox(#3,#4){}}}
%\put(#1,#2){\begin{picture}(#3,#4)
%#6
%\end{picture}}
%\put(#1,#2){\makebox(2,2){\tt #5}}}
%
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% s1
%\begin{picture}(58,50)
%\schema(0,25)(24,23){s1}{\entity(14,2){\tt person}
%\cardattribute(14,6)(8,7){\tt sex}{\tt 1:1}{\tt 1:N}
%\cardattribute(14,4)(6,4){\tt name}{\tt 1:1}{\tt 1:N}
%\cardattribute(14,2)(8,1){\underline{\tt id}}{\tt 1:1}{\tt 1:1}
%\relationship(18,6)(18,18){\tiny \tt worksin}{\tt 1:1}{\tt 1:N}
%\entity(14,18){\tt dept}
%\cardattribute(14,20)(8,20){\underline{\tt dname}}{\tt 1:1}{\tt 1:1}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% s2
%\schema(26,27)(32,18){s2}{\entity(12,13){\tt person}
%\entity(7,1){\texttt{male}}
%\entity(17,1){\texttt{female}}
%\generalisation(13,9){\tt sex}
%\path(11,5)(11,7)(21,7)(21,5)
%\path(16,7)(16,9)
%\isa(16,11)(16,13)
%\cardattribute(12,14)(6,13){\underline{\tt id}}{\tt 1:1}{\tt 1:1}
%\cardattribute(12,16)(6,17){\tt name}{\tt 1:1}{\tt 1:N}
%\cardattribute(20,15)(26,15){\tt dname}{\tt 1:1}{\tt 1:N}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%\schema(3,1)(52,18){sg}{\entity(12,13){\tt person}
%\entity(7,1){\tt male}
%\entity(17,1){\tt female}
%\generalisation(13,9){\tt sex}
%\path(11,5)(11,7)(21,7)(21,5)
%\path(16,7)(16,9)
%\isa(16,11)(16,13)
%\cardattribute(12,14)(6,13){\underline{\tt id}}{\tt 1:1}{\tt 1:1}
%\cardattribute(12,16)(6,17){\tt name}{\tt 1:1}{\tt 1:N}
%\relationship(20,15)(32,15){\tiny \tt worksin}{\tt 1:1}{\tt 1:N}
%\entity(32,13){\tt dept}
%\cardattribute(40,15)(46,15){\underline{\tt dname}}{\tt 1:1}{\tt 1:1}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%\labvector(10,24)(10,20){\snsref{s11} .. \snsref{s15}}{}
%\labvector(14,20)(14,24){}{\isnsref{s15} .. \isnsref{s11}}
%\labvector(40,24)(40,20){\snsref{s21} .. \snsref{s24}}{}
%\labvector(44,20)(44,24){}{\isnsref{s24} .. \isnsref{s21}}
%\end{picture}
%
%\end{stdfigure}


\section{Background}
\label{sec:bg}

\subsection{The AutoMed Framework}
\label{sec:automed_framework}

\begin{figure} [ht]
\begin{center}
\includegraphics{restructure_examples.eps}
\caption{Restructuring equivalent ER schemas\label{fig:restructure_example}}
\end{center}
\end{figure}

In this paper, examples will be made based on the scenario illustrated
in Figure~\ref{fig:example_er}.
Figure~\ref{fig:example_er} shows two source schemas \texttt{s1}
and \texttt{s2}, and a global schema \texttt{sg} which is the
result of integrating \texttt{s1} and \texttt{s2}.

In the AutoMed framework~\cite{MP98,PM98,MP99a,MP99b},
schemas are transformed \textbf{incrementally}
by applying a set of \textbf{primitive transformtions}.
When the same concepts are represented by using different modelling
constructs, 
%a situation commonly found in schemas expressed in
%high-level modelling languages,
\textbf{composite transformations}~\cite[pg.~55]{PM98} are
required to map the differences between the schemas.  Some examples
of restructuring equivalent ER schemas represented by different
constructs within
the data model are shown in Figure~\ref{fig:restructure_example}.  For
the example in Figure~\ref{fig:example_er}, the gender of a person
is represented by the \myhdmf{person, sex}
attribute in \texttt{s1} whereas the same information is represented
as a generalization hierarchy \myhdmf{sex, person, male, female}
in \texttt{sg}.  These composite transformations are broken down into
smaller steps -- primitive transformations -- that are expressed in
the base constructs of the modelling language.
%To summarize, the main features
Some of the primitive transformations contain a query that describes
the \textbf{extent} of the
construct being transformed, that is, the query describes what data
%are \emph{embedded} with a query that describes what data
instances are to fill the new construct.
%is \emph{embedded} in the transformation.
For the example in Figure~\ref{fig:example_er}, \texttt{sg} has an entity
\myhdmf{male} which contains the instances of \myhdmf{person}
in \texttt{s1} that have \texttt{`m'} as the value of the
\footnotesize \textsf{sex} \normalsize
attribute.  So, for transformation \snsref{s11} in Example~1 (which shows
the transformations required to transform
\texttt{s1} into \texttt{sg}), the query
\footnotesize \textsf{$\langle$X,'m'$\rangle$
$\in$ \myhdmf{\textsf{person, sex}}} \normalsize
is embedded in the transformation.
Because of the presence of this query, we may derive
\begin{sffamily}
\footnotesize
\isnsref{s11}~delEntity(\myhdmf{male}, \{X $\mid \langle$X,`m'$\rangle$
%$\overline{1}$~delEntity(\myhdmf{male}, \{X $\mid \langle$X,`m'$\rangle$
$\in$ \myhdmf{person, sex}\}).
%~\footnote{since the schemas are represented
%in the ER model, we will use ER-style schemes in the transformation to
%simplify the writing.}
\end{sffamily}
\normalsize
Thus, transformations in the AutoMed framework are
\textbf{automatically reversible}.  In this paper, a transformation is
denoted $t$ or \sns{t} and its reverse transformation is denoted
$\overline{t}$ or \isns{t}.  We may complete the mapping
from \texttt{s1} to \texttt{sg} by transformations \snsref{s11} to
\snsref{s15} shown in Example 1.

\textbf{Example 1}\\
\texttt{s1} $\rightarrow$ \texttt{sg}:\\
% changing font
\begin{sffamily}
\footnotesize
%1. addEntity($\hdms{\textsf{male}}$,
\snslabel{s11} addEntity(\myhdmf{male},
\{X $\mid \langle$X,`m'$\rangle \in$ \myhdmf{person, sex}\})\\
\snslabel{s12} addEntity(\myhdmf{female},
\{X $\mid \langle$X,`f'$\rangle \in$ \myhdmf{person, sex}\})\\
\snslabel{s13} addGeneralization(
            \myhdmf{sex, person, male})~\footnote{Because
            an ER generalization is translated down into a constraint
            in HDM, and constraints do not have an extent, so a query
            is not required for the \emph{addGeneralization}
            transformation.  More details can be found
            in~\cite{MP99a}~\cite[pg.~104]{MP99b}.}\\
\snslabel{s14} addGeneralization(\myhdmf{sex, person, female})\\
\snslabel{s15} delAttribute(\myhdmf{person, sex},
\{X,Y $\mid$ X $\in$ \myhdmf{male} $\wedge$ Y = `m' $\vee$
X $\in$ \myhdmf{female} $\wedge$ Y = `f'\})\\
\end{sffamily}
\normalsize

Reversing the transformations \snsref{s11} to \snsref{s15} in
Example~1 gives us the
transformation pathway for the mapping from \texttt{sg} back to
\texttt{s1} as follows:

\texttt{sg} $\rightarrow$ \texttt{s1}:\\
\begin{sffamily}
\footnotesize
\isnsref{s15} addAttribute(\myhdmf{person, sex},
\{X,Y $\mid$ X $\in$ \myhdmf{male} $\wedge$ Y = `m' $\vee$
X $\in$ \myhdmf{female} $\wedge$ Y = `f'\})\\
\isnsref{s14} delGeneralization(\myhdmf{sex, person, female})\\
\isnsref{s13} delGeneralization(\myhdmf{sex, person, male})\\
\isnsref{s12} delEntity(\myhdmf{female},
\{X $\mid \langle$X,`f'$\rangle \in$ \myhdmf{person, sex}\})\\
\isnsref{s11} delEntity(\myhdmf{male},
\{X $\mid \langle$X,`m'$\rangle \in$ \myhdmf{person, sex}\})\\
\end{sffamily}
\normalsize

The transformations between schema \texttt{s2} and the global schema
\texttt{sg} are derived in a similar fashion and are shown as
follows:

\texttt{s2} $\rightarrow$ \texttt{sg}:\\
\begin{sffamily}
\footnotesize
\snslabel{s21} addEntity(\myhdmf{dept},
\{X $\mid \langle$\_,X$\rangle \in$ \myhdmf{person, dname}\})\\
\snslabel{s22} addAttribute(\myhdmf{dept, dname},
\{X,X $\mid \langle$\_,X$\rangle \in$ \myhdmf{person, dname}\})\\
\snslabel{s23} addRelationship(\myhdmf{worksin, person, dept, 1:1, 1:N},
\{X,Y $\mid \langle$X,Y$\rangle \in$ \myhdmf{person, dname}\}\\
\snslabel{s24} delAttribute(\myhdmf{person, dname},
\{X,Y $\mid \langle$\_,X,Y$\rangle \in$ \myhdmf{worksin, person, dept}\}\\
\end{sffamily}
\normalsize


\texttt{sg} $\rightarrow$ \texttt{s2}:\\
\begin{sffamily}
\footnotesize
\isnsref{s24} addAttribute(\myhdmf{person, dname},
\{X,Y $\mid \langle$\_,X,Y$\rangle \in$ \myhdmf{worksin, person, dept}\}\\
\isnsref{s23} delRelationship(\myhdmf{worksin, person, dept, 1:1, 1:N},
\{X,Y $\mid \langle$X,Y$\rangle \in$ \myhdmf{person, dname}\}\\
\isnsref{s22} delAttribute(\myhdmf{dept, dname},
\{X,X $\mid \langle$\_,X$\rangle \in$ \myhdmf{person, dname}\})\\
\isnsref{s21} delEntity(\myhdmf{dept},
\{X $\mid \langle$\_,X$\rangle \in$ \myhdmf{person, dname}\})\\
\end{sffamily}
\normalsize


We now consider the case where \texttt{s2} is evolved into \texttt{ev2}
via 3 transformation steps:

\texttt{s2} $\rightarrow$ \texttt{ev2}:\\
\begin{sffamily}
\footnotesize
\snslabel{s2ev1} addEntity(\myhdmf{dept},
\{X $\mid \langle$\_,X$\rangle \in$ \myhdmf{person, dname}\})\\
\snslabel{s2ev2} addAttribute(\myhdmf{dept, dname},
\{X,X $\mid \langle$\_,X$\rangle \in$ \myhdmf{person, dname}\})\\
\snslabel{s2ev3} addRelationship(\myhdmf{worksin, person, dept, 1:1, 1:N},
\{X,Y $\mid \langle$X,Y$\rangle \in$ \myhdmf{person, dname}\}\\
\end{sffamily}
\normalsize

The contents of \texttt{ev2} will be exactly the same as that as in
\texttt{sg} except that a redundant attribute \myhdmf{person, dname}
is present in \texttt{ev2}.

Now, the transformation pathway from \texttt{ev2} to \texttt{sg} can be
derived from putting together the transformations in the pathways
\texttt{ev2} to \texttt{s2}, i.e., the reverse of the pathway \texttt{s2}
to \texttt{ev2}, and \texttt{s2} to \texttt{sg}:

\texttt{ev2} $\rightarrow$ \texttt{sg}:\\
\begin{sffamily}\footnotesize
\isnsref{s2ev3} delRelationship(\myhdmf{worksin, person, dept, 1:1, 1:N},
\{X,Y $\mid \langle$X,Y$\rangle \in$ \myhdmf{person, dname}\}\\
\isnsref{s2ev2} delAttribute(\myhdmf{dept, dname},
\{X,X $\mid \langle$\_,X$\rangle \in$ \myhdmf{person, dname}\})\\
\isnsref{s2ev1} delEntity(\myhdmf{dept},
\{X $\mid \langle$\_,X$\rangle \in$ \myhdmf{person, dname}\})\\
\snsref{s21} addEntity(\myhdmf{dept},
\{X $\mid \langle$\_,X$\rangle \in$ \myhdmf{person, dname}\})\\
\snsref{s22} addAttribute(\myhdmf{dept, dname},
\{X,X $\mid \langle$\_,X$\rangle \in$ \myhdmf{person, dname}\})\\
\snsref{s23} addRelationship(\myhdmf{worksin, person, dept, 1:1, 1:N},
\{X,Y $\mid \langle$X,Y$\rangle \in$ \myhdmf{person, dname}\}\\
\snsref{s24} delAttribute(\myhdmf{person, dname},
\{X,Y $\mid \langle$\_,X,Y$\rangle \in$ \myhdmf{worksin, person, dept}\}\\
\end{sffamily}\normalsize

We can see that the execution of the majority of the transformation steps
is superfluous and should be omitted to increase performance.  For example,
the transformation steps \isnsref{s2ev3} and \snsref{s23} are
redundant since the
transformation object involved is the same object, and that the
\textbf{action} of the transformations are ``of the opposite sign''
(\textsf{del} and \textsf{add}, respectively).  The removal of these two
transformation steps from the set of transformations will have no effect
on the resultant schema.  The same applies to the pairs of transformation
steps \isnsref{s2ev2} \& \snsref{s22}, and \isnsref{s2ev1}
\& \snsref{s21}.  After the removal of
the redundant steps in the pathway, we have only one transformation step
left to execute to transform the schema \texttt{ev2} to \texttt{sg}:

\texttt{ev2} $\rightarrow$ \texttt{sg}:\\
\begin{sffamily}\footnotesize
\snsref{s24} delAttribute(\myhdmf{person, dname},
\{X,Y $\mid \langle$\_,X,Y$\rangle \in$ \myhdmf{worksin, person, dept}\}\\
\end{sffamily}\normalsize

%As the chances of having redundant transformation steps in pathways grow
%as the number of schemas and transformations increases, and that the
%number of schemas and transformations are generally high in real world
%cases, a realistic schema integration tool must optimise transformation
%steps for it to perform efficiently.


The AutoMed framework also supports the integration of schemas
that are expressed in different data modelling languages, without
the need to first translate the constructs in source schemas into
those belonging to the language used in the global schema~\cite{MP99a}.
Most of the research carried out in the area of schema integration
adopts a high-level conceptual model as the Common Data Model (CDM)
(~\cite{Bat86} contains a
comprehensive survey of schema integration methodologies).  The
use of a high-level model makes it very complicated to map
constructs of different models with one another because,
typically, high-level models provide a richer set of modelling
constructs and hence a concept can possibly be represented in
a number of ways.  To avoid this complication, the AutoMed
framework adopts the Hypergraph Data Model approach~\cite{PM98},
where a low-level hypergraph-based data model is used as the CDM.
Higher-level modelling constructs can be mapped easily to
constructs used in the HDM.

The only constructs contained in the HDM are \textbf{\emph{Node}},
\textbf{\emph{Edge}}, and \textbf{\emph{Cons}} (Constraint).  An HDM
schema is then a triple containing a set of Nodes, a set of Edges,
and a set of Constraints --
$\langle$\emph{Nodes, Edges, Constraints}$\rangle$.  A set of
mappings between higher-level model constructs and HDM constructs
is defined.  For example, an ER entity is mapped to a \emph{Node}
in the HDM; an ER relationship is mapped to an \emph{Edge} in the
HDM.  A set of primitive transformations have been defined to
transform HDM models.  By using the mappings between constructs
of different models, not only that schemas can be translated into
ones expressed in another modelling language, transformations for
higher-level schemas can also be automatically
derived~\cite{MP99a}.
%A distinguishing feature of the HDM approach is that transformations
%are \emph{automatically reversible}, i.e., transformations pathways
%are bi-directional.  This means that queries posed on different
%semantically equivalent or overlapping schemas can be automatically
%translated into appropriate queries on a particular schema, as long
%as there are transformations defined between them.  A demonstration
%of using this approach in integrating ER schemas can be found
%in~\cite{si:mcbrien_poulovassilis:automatic_migration}.  In the
%same paper, there is also a description on how transformation
%primitives can be extended to handle transformations between
%non-equivalent schemas.

%\textbf{mention later...}\\
%A low-level hypergraph-based data model (the HDM) is used as
%opposed to using high-level conceptual data modelling languages.
%It has been shown that high-level modelling concepts can ultimately
%be translated down into the HDM~\cite{MP99a}.  Thus, the AutoMed
%framework provides a flexible way in supporting the integration of
%multiple data sources whose schemas may be described in a variety
%of data modelling languages.

\subsection{Implementation of the AutoMed Framework}
\label{sec:automed_implementation}

%!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
% shortening paper - nt 08/03/02
%Two main components in the AutoMed architecture are the Model
%Definitions Repository (MDR) and the Schemas and Transformations
%Repository (STR).  The MDR contains definitions of how high-level
%modelling constructs are translated down into HDM and the STR
%stores information about schemas in terms of the modelling
%language constructs described in the MDR as well as primitive
%transformations between schemas.  Figure~\ref{fig:api_arch}
%illustrates how the STR and MDR fit
%together with other (proposed) components in the AutoMed
%architecture.  The Data Source Repository (DSR) is simply a helper
%component that provides common functionality to the MDR and
%the STR.
%
%\def\longentity(#1,#2)#3{\sf\thicklines\putcolourframebox(#1,#2)(10,4){white}{\shortstack{#3}}}
%
%% arch of MDR, STR, DSR and the repAPI
%\begin{stdfigure}{Components in the AutoMed Architecture}{fig:api_arch}
%
%\stdpicmag{-2}
%
%\begin{picture}(47,31)
%\put(0,0){\colorbox{lightgrey}{\makebox(47,31){}}}
%\put(1,1){\colorbox{blue}{\makebox(21,14){}}}
%\entity(8,21){\tt Reps\\\tt API}
%\entity(2,10){\tt MDR}
%\entity(14,10){\tt STR}
%\path(6,14)(6,18)(18,18)(18,14)
%\path(12,6)(12,21)
%\entity(8,2){\tt DSR}
%\path(10,6)(6,10)
%\path(14,6)(18,10)
%\longentity(29,25){\tt Optimisa-\\\tt tion tool}
%\longentity(29,17){\tt AutoMed\\\tt GUI tool}
%\path(29,27)(25,27)(25,19)(29,19)
%%\path(26,14)(26,20)
%\path(16,23)(25,23)
%\put(36,13){Other}
%\put(36,11){system}
%\put(34,9){components}
%% horrible way of drawing dotted lines...
%\path(31,29)(31,30)
%
%\path(31,30)(32,30)
%\path(33,30)(34,30)
%\path(35,30)(36,30)
%\path(37,30)(38,30)
%\path(39,30)(40,30)
%\path(41,30)(42,30)
%\path(43,30)(44,30)
%\path(45,30)(46,30)
%
%% vertical
%\path(46,30)(46,29)
%\path(46,28)(46,27)
%\path(46,26)(46,25)
%\path(46,24)(46,23)
%\path(46,22)(46,21)
%\path(46,20)(46,19)
%\path(46,18)(46,17)
%\path(46,16)(46,15)
%\path(46,14)(46,13)
%\path(46,12)(46,11)
%\path(46,10)(46,9)
%\path(46,8)(46,6)
%\path(46,6)(46,5)
%
%% another one...
%\path(46,6)(45,6)
%\path(44,6)(43,6)
%\path(42,6)(41,6)
%\path(40,6)(39,6)
%\path(38,6)(37,6)
%\path(36,6)(35,6)
%\path(34,6)(33,6)
%\path(32,6)(31,6)
%
%%vertical
%\path(31,6)(31,7)
%\path(31,8)(31,9)
%\path(31,10)(31,11)
%\path(31,12)(31,13)
%\path(31,14)(31,15)
%\path(31,16)(31,17)
%
%\path(31,21)(31,21.7)
%\path(31,22.4)(31,23.6)
%\path(31,24.3)(31,25)
%\end{picture}
%
%\end{stdfigure}
%
%The reader is referred to~\cite{boy01a} for details about the structure
%of the MDR, STR and DSR.  The Repositories (reps) API provides a Java
%interface to the MDR and the STR and is dicussed in the next section.
%Progress of the project can be found in~\cite{automedwww}.


%\subsubsection{The Repositories (reps) API}
%\label{sec:repsAPI}

The AutoMed Repositories (reps) API~\cite{boy01a} is a core component
that provides an interface for accessing several system components.
It provides methods to create, query, alter and
remove models, constructs, construct schemes, schemas, schema objects,
object schemes, transformations as well as some ancillary entities
such as access methods for source schemas.
%such as access methods for extensional schemas.
%An ER diagram of how
%these entities are related to each other is given in
%Appendix~\ref{sec:repSchema}.
%The reps API comprises of Java
%classes representing each of these entities, all the methods for
%manipulating the repositories are in these classes.

%Other components in the AutoMed architecture will access the MDR and
%STR via the AutoMed Repositories API.  The two major classes that will
%be created directly by the components are the \texttt{Model} class
%(from the MDR) and the \texttt{Schema} class (from the STR).  The
%classes that have been implemented for the AutoMed Repositories API
%are listed in Table~\ref{table:api_classes}.
%
%
%\begin{stdtable}{Classes for the AutoMed Repositories API}
%{table:api_classes}
%
%\begin{tabular}{lll}
%\multicolumn{3}{>{\columncolor{header}}c}{AutoMed Repositories API Classes} \\[0.3cm]
%\rowcolor{header}
%Class & Repository & Created By \\
%\textbf{Model}
%& MDR
%& AutoMed tool \\
%\rowcolor{evenrow}
%\textbf{Construct}
%& MDR
%& Model \\
%\textbf{SchemePos}
%& MDR
%& Construct \\
%\rowcolor{evenrow}
%\textbf{Schema}
%& STR
%& AutoMed tool \\
%\textbf{SchemaObject}
%& STR
%& Schema \\
%\rowcolor{evenrow}
%\textbf{ObjectScheme}
%& STR
%& SchemaObject \\
%\textbf{Transformation}
%& STR
%& AutoMed tool \\
%\rowcolor{evenrow}
%\textbf{AccessMethod}
%& STR
%& AutoMed tool \\
%\textbf{Protocol}
%& STR
%& AutoMed tool \\
%\end{tabular}
%
%\end{stdtable}
%
%
%Examples showing the usage of the classes related to the MDR and STR
Examples showing the usage of the reps API
are included in~\cite{boy01a} and will not be discussed in this paper.
However, we will have a closer look at a special transformation
that is not one of the original primitive transformations of the
AutoMed framework but is used only by the reps API
%.  This special
%transformation is the \emph{identity transformation}
%(\emph{id transformations}).
%The \emph{id transformation} is used
for \textbf{connecting} two
schema objects from two individual source schemas when they actually
refer to the same schema object in the global schema.
Since the AutoMed project~\cite{automedurl} is implemented in
the Java programming language, here, connecting two schema
objects means making the references to the two individual
\texttt{SchemaObject}s point to the same memory location.
For the example in Figure~\ref{fig:example_er}, the entity
\myhdmf{person} in \texttt{sg} refers to the same entity
\myhdmf{person} in \texttt{s1} and \texttt{s2}.  Java objects
are instantiated
for all the constructs in source schemas (\texttt{s1} and
\texttt{s2}).  If we have Java objects named \texttt{s1person}
and \texttt{s2person} instantiated for the \myhdmf{person}
entity in \texttt{s1} and \texttt{s2}, respectively, and we
have a set of transformations \snsref{s11} to \snsref{s15}
defined that transform \texttt{s1} to \texttt{sg}, when we
define transformation \snsref{s24}, which is the last transformation
from \texttt{s2} to \texttt{sg}, we need to also specify that
\texttt{s2person} is referencing the same object as
\texttt{s1person}.  This is the function of the \emph{id}
transformation.  It takes two construct references that
represent the same construct in a particular schema and make
adjustments to indicate that they are in fact referring to
the same construct.


%\subsection{An Example of Schema Transformation Optimisation}

%A simple example as shown in Figure~\ref{fig:example_er} will be
%used here to give an informal description of how the
%transformation optimisation process can be carried out.


\section{Semantics of Transformations and a Transformation
Manipulation Language}
\label{sec:sem_and_tml}

In this section, we will introduce an algebraic \textbf{transformation
manipulation language} and discuss the semantics of the different
kinds of transformations.  The transformation manipulation language
provides a formal approach to
verifying if a transformation pathway is well-formed and 
identifying situations where
transformations can be re-ordered and/or removed.
%and/or simplified.
A detailed discussion on the semantics of transformations can be
found in~\cite{PM98}.

The transformations discussed include the five main
operations on schema constructs, namely \emph{add}, \emph{delete},
\emph{extend}, \emph{contract}, and \emph{rename}, plus
the special transformation for the repositories API
(Section~\ref{sec:automed_implementation}), \emph{id}.
These operations will be abbreviated as \emph{add}, \emph{del},
\emph{ext}, \emph{con}, \emph{ren} and \emph{id}, respectively.
We will not discuss separately the types of constructs acted upon in
the transformations because the semantics of the transformation
operations, regardless of the type of constructs involved, are
inherently the same.


\subsection{Transformation Manipulation Language}
\label{sec:tml}

%It is required in the design of the Transformation Manipulation
%Language (TML) that the language must be able to handle both
%\emph{unary} and \emph{binary} transformation operations (unary
%operations name just one construct and include \emph{add}, \emph{del},
%\emph{ext}, and \emph{con};
%binary operations name two constructs and include \emph{ren} and
%\emph{id}).  Also,
The Transformation Manipulation Language (TML)
must be able to indicate clearly the necessary existence or
absence of particular constructs both before and after applying the
transformation for it to be valid.  Hence we propose that the general
form of a transformation in TML is as follows:


%\newcommand{\tml}[5]{\ensuremath{^{+#2}_{-#3}{{#1}^{+#4}_{-#5}}}}

% moved the + and - sign
% usage: \tml{tName}{PosPre}{NegPre}{PosPost}{NegPost}
\newcommand{\tml}[5]{\ensuremath{\sideset{_{#3}^{#2}}{_{#5}^{#4}}{\mathop{#1}}}}
%\newcommand{\tml}[5]{\ensuremath{\sideset{_{#3-}^{#2+}}{_{#5-}^{#4+}}{\mathop{#1}}}}

\begin{center}
\setlength{\extrarowheight}{11pt}
\begin{tabular}{cl}
% another color is tablename
%\multicolumn{1}{C}{\scriptsize\textsf{add(A)}\small} &
\multicolumn{1}{C}{\raisebox{1ex}[0cm][0cm]{\tml{t}{C_1^+}{C_2^-}{C_3^+}{C_4^-}}} &
where
\end{tabular}
\setlength{\extrarowheight}{0pt}
\end{center}

\begin{itemize}
   \item    $t$ is a transformation label, with the transformation's
            preconditions and postconditions on the left and right
            side of the label, respectively.
   \item    $C_i^{+/-}$ represents a set of constructs.  $C_i^+$ on
            the left (right) side of $t$ denotes the set of constructs
            that must exist before (after) $t$ can be applied.
            $C_i^-$ on the left (right) side of $t$ denotes the set of
            constructs that must not exist before (after)
            $t$ has been applied.
   \item    $\emptyset$ is used for $C_1$, $C_2$, $C_3$, or $C_4$, if
            no construct is required to be present or absent.
\end{itemize}

The function $c(C_n)$ returns the union of all the constructs referenced
by each construct $E_i$, where $E_i \in C_n$, i.e.,
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{eqnarray*}
c(C_n) = c(E_1) \cup c(E_2) \cup \ldots \cup c(E_n)
\end{eqnarray*}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
$c(E)$ is a recursive function that returns the construct $E$
itself, plus $c(e_1) \cup c(e_2) \cup \ldots \cup c(e_n)$, where
$e_i$ are the constructs referenced by $E$, i.e.,
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{eqnarray*}
c(\myhdmf{$e, e_1, e_2, \ldots, e_n$})
= \myhdmf{$e, e_1, e_2, \ldots, e_n$} \cup c(e_1) \cup c(e_2) \cup \ldots \cup c(e_n)
\end{eqnarray*}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
For example, c(\myhdmf{worksin, person, dept, 1:1, 1:N})\\
\phantom{\hspace{1.97cm}}
   = \{\myhdmf{worksin, person, dept, 1:1, 1:N},
      \myhdmf{person}, \myhdmf{dept}\}\\
%$c(\myhdmf{worksin, person, dept, 1:1, 1:N})$
%evaluates to:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%\begin{eqnarray*}
%& & c(\myhdmf{worksin, person, dept, 1:1, 1:N})\\
%%& = & \{\myhdmf{worksin, person, dept, 1:1, 1:N}\normalsize\}
%%  \cup c(\myhdmf{person}\normalsize)
%%  \cup c(\myhdmf{dept}\normalsize)\\
%%& = & \{\myhdmf{worksin, person, dept, 1:1, 1:N}\normalsize\}
%%   \cup \{\myhdmf{person}\}
%%\cup \{\myhdmf{dept}\normalsize\}\\
%& = & \{\myhdmf{worksin, person, dept, 1:1, 1:N},
%      \myhdmf{person},
%      \myhdmf{dept}\}
%\end{eqnarray*}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Table~\ref{table:gen_form_tml_1}
shows the general TML form for the \emph{add}, \emph{del}, and
\emph{ren} transformations.  Each of the transformation and
their TML notation will be discussed in more detail.


%\setlength{\extrarowheight}{4pt}
\setlength{\extrarowheight}{8pt}
\begin{table}
\begin{center}
\begin{tabular}{|c|c|l|}\hline

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% row 1
\emph{add}($P_1, \{x|Q\}$) &
\tml{t}{(c(P_1)-P_1) \ \cup \ c(Q)^+}
      {\phantom{\hspace{2.28cm}}P_1^-}
      {c(P_1) \ \cup \ c(Q)^+}{\emptyset} &
$P_1,P_2,\ldots$ are constructs,
%$C$ is a function that\\
\\

$S_1 \rightarrow S_2$ &
$P_1 \notin S_1$, $P_1 \in S_2$ &
%\raisebox{1.5ex}[0cm][0cm]{$C_1,C_2,\ldots$ are constructs,}
$c(P_n)$ is a function that
%returns all constructs\\
\\\cline{1-2}

%\emph{ext}(\texttt{A}, \texttt{VOID}) &
%\tml{t}{\emptyset}{A}{A}{\emptyset} &
%$^{\emptyset}_{-A}{t^{+A}_{\emptyset}}$ &
%that appear in $Q$\\\hline
%\raisebox{1.5ex}[0cm][0cm]{$C$ is a function that}
%\\\cline{1-2}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% row 2

\emph{del}($P_1, \{x|Q\}$) &
%$^{+AC}_{\emptyset}{t^{\emptyset}_{-A}}$ &
\tml{t}{c(P_1) \ \cup \ c(Q)^+}
      {\phantom{\hspace{1.75cm}}\emptyset}
      {(c(P_1)-P_1) \ \cup \ c(Q)^+}{P_1^-} &
%\raisebox{1.5ex}[0cm][0cm]{$C(C_n)$ is a function that returns}
returns construct $P_n$ and all
%$C$ is a function that\\
\\

$S_1 \rightarrow S_2$ &
$P_1 \in S_1$, $P_1 \notin S_2$ &
%\raisebox{1.5ex}[0cm][0cm]{$C_n$ and all constructs referenced}
constructs referenced by $P_n$.
%returns all constructs\\
\\\cline{1-2}

%\emph{con}(\texttt{A}, \texttt{VOID}) &
%$^{+A}_{\emptyset}{t^{\emptyset}_{-A}}$ &
%\tml{t}{A}{\emptyset}{\emptyset}{A} &
%\raisebox{1.5ex}[0cm][0cm]{which $X$ depends on}\\\cline{1-2}
%that appear in $Q$\\\hline

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% row 3

\emph{ren}($P_1, P_2$) &
\tml{t}{c(P_1) \ \cup \ (c(P_2) - P_2)^+}
      {\phantom{\hspace{2.38cm}}P_2^-}
      {(c(P_1) - P_1) \ \cup \ c(P_2)^+}{P_1^-} &
%\raisebox{1.5ex}[0cm][0cm]{by $C_n$.}
$c(Q)$ is a function that
\\
%$^{+A}_{-B}{t^{+B}_{-A}}$ & \\

$S_1 \rightarrow S_2$ &
$P_1 \in S_1$, $P_2 \notin S_1$ &
returns all constructs that
\\

& $P_2 \in S_2$, $P_1 \notin S_2$ &
appear in query $Q$.
\\\hline

%\emph{id}(\texttt{A}, \texttt{B}) &
%\tml{t}{A}{B}{B}{A} & \\\hline
%$^{+A}_{-B}{t^{+B}_{-A}}$ & \\\hline

\end{tabular}
\end{center}
\caption{TML representation of the \emph{add}, \emph{del}, and \emph{ren} transformations\label{table:gen_form_tml_1}}
\end{table}
\setlength{\extrarowheight}{0pt}


% add
\textbf{\emph{The add transformation}}\\
The preconditions for applying an \emph{add}($P_1, \{x|Q\}$)
transformation, where $P_1$ is a construct and $Q$ is
a query giving the extent of $P_1$,
on schema \texttt{s1} to create schema \texttt{s2} are that,
(i) $P_1$ must not exist in \texttt{s1}, or that any construct
that is of the same type as $P_1$ must not share the same name as
$P_1$;  also, (ii) all the constructs referenced by $P_1$ (all
the constructs that appear in the scheme of $P_1$, apart from
$P_1$ itself) must already exist in \texttt{s1}\footnote{Precondition
(ii) may appear to be redundant as one may argue that, $P_1$ could not
have been created in the first place with the absence of any of the
constructs referenced by it.  However, as will be discussed in
Section~\ref{sec:op_rules}, it is necessary to state this precondition
explicitly for determining certain properties of a transformation or
the whole transformation pathway to which it belongs.}; and (iii) the
constructs that appear in $Q$ must already exist in \texttt{s1}.
%As a result, the TML form of this \emph{add} transformation $t$ has on
%its left side all the constructs referenced by $P_1$ and all
%the constructs contained in the query $Q$ --
%$(c(P_1)-P_1) \ \cup \ c(Q)$ -- as its positive precondition, and
%$P_1$ as its negative precondition.
As a result, the positive precondition is $(c(P_1)-P_1) \ \cup \ c(Q)$,
i.e., all the constructs referenced by $P_1$ and all the constructs
appeared in $Q$, and the negative precondition is $P_1$.
Assuming that all the preconditions are satisfied, the postconditions
of this transformation are that, (i) $P_1$ must exist in \texttt{s2}
after the transformation has been applied; (ii) the constructs
referenced by $P_1$ must still exist in \texttt{s2}; and
(iii) the constructs that appear in $Q$ must still exist in
\texttt{s2}.  So, in TML form, $t$ has $P_1$, all the constructs
referenced by $P_1$, and all the constructs contained in the query
$Q$ -- $c(P_1) \ \cup \ c(Q)$ -- as its positive postcondition.
Since no particular construct is required to be absent after the
transformation has been applied, the $\emptyset$ is the negative
postcondition of $t$.

The \emph{ext} transformation is very similar to the \emph{add}
transformation.  The only difference is that, $P_1$ in the
\emph{add} transformation is derivable from other existing constructs
in \texttt{s1} whereas $P_1$ in the \emph{ext} transformation is
not.
%for the \emph{ext} transformation, $P_1$ is a completely new
%concept introduced which cannot be derived from the existing
%constructs in \texttt{s1}.
This difference is indicated by the
query giving the extent of $P_1$ being present in the \emph{add}
transformation.  For \emph{add}($P_1, \{x|Q\}$), the query
$Q$ will return all
the data instances (evaluated from the constructs in \texttt{s1})
that will be used to fill $P_1$ in \texttt{s2}.  For
\emph{ext}($P_1$, \texttt{VOID}), this query will simply be
\texttt{VOID}, indicating
that the constructs in \texttt{s1} cannot be used to derive
the data instances for $P_1$.  Since not having a query $Q$ that
gives the extent of the transformation
construct means that there are no particular requirements that the
constructs in $Q$ must pre-exist, we will define that:
\begin{displaymath}
c(\texttt{VOID}) = \emptyset
\end{displaymath}

There are two interpretations of the \emph{ext}($P_1$, \texttt{VOID})
transformation.  The \textbf{strict} interpretation states that 
$P_1$ must be a completely new concept introduced which
\textbf{cannot} be derived from the existing constructs in \texttt{s1}.
The \textbf{non-strict} interpretation says that, even though the
query giving the extent of $P_1$ is not present, it still
implies that the extent of $P_1$ may be derivable from \texttt{s1},
but the person who created the transformation did not put this
infomation in the transformation either because (s)he does not know
how to construct the query or it was simply an omission.
In this paper, the non-strict interpretation is used for the
\emph{ext} and \emph{con} transformations.

% delete
\textbf{\emph{The delete transformation}}\\
Since $S_1$ $\rightarrow$ $S_2$ via \emph{del}($P_1, \{x|Q\}$)
$\equiv$ $S_2$ $\rightarrow$ $S_1$ via \emph{add}($P_1, \{x|Q\}$),
the conditions for the
\emph{del} transformation are the inverse of those of
the \emph{add} transformation.  For a
\emph{del}($P_1, \{x|Q\}$) transformation,
The preconditions
are that, (i) \texttt{s1} must have the construct $P_1$
already existing in the schema;  (ii) the constructs referenced by
$P_1$ must also exist in \texttt{s1}; and (iii) the constructs
in the query $Q$ must exist in \texttt{s1}.  In its TML form,
$t$ has as its positive precondtion the construct $P_1$, the
constructs referenced by $P_1$, and all the constructs contained
in the query $Q$ -- $c(P_1) \ \cup \ c(Q)$.  Since no construct
is required to be absent before the transformation is applied,
$t$ has $\emptyset$ as its negative precondition.  The successful
application of the \emph{del} transformation
implies that (i) \texttt{s2} {must not} contain $P_1$; and (ii)
the constructs referenced by $P_1$ must still exist in
\texttt{s2} and (iii) the constructs in $Q$ must still
exist in \texttt{s2}.  In TML form, a \emph{del} transformation
$t$ has as its positive postcondition the constructs referenced
by $P_1$ and all the constructs contained in the query $Q$ --
$(c(P_1)-P_1) \ \cup \ c(Q)$.  The negative postcondition of $t$
would be the deleted construct $P_1$.

As with
the \emph{add} and \emph{ext} transformations, the \emph{con}
transformation shares similar characteristics as the \emph{del}
transformation.  If $P_1$ can be derived from \texttt{s1} then
\emph{del}($P_1, \{x|Q\}$) will be used.  If $P_1$ cannot be
derived from \texttt{s1} then \emph{con}($P_1$, \texttt{VOID})
should be used
instead to transform \texttt{s1} into \texttt{s2}.  The query
$Q$ of \emph{del}($P_1, \{x|Q\}$) specifies how
$P_1$ can be derived from the existing constructs (other than
$P_1$ itself).  Like the
\emph{ext} transformation, the \emph{con} transformation contains
\texttt{VOID} as its query.

% rename
\textbf{\emph{The rename transformation}}\\
The \emph{ren}($P_1, P_2$) transformation requires two preconditions
to be satisfied: (i) $P_1$ must exist in \texttt{s1}, and
(ii) $P_2$ must not exist in \texttt{s1}.  Thus,
in the TML form of \emph{ren}($P_1, P_2$), $t$ has on its left side
$P_1$ as its positive precondition and $P_2$ as its negative
precondition.  After the transformation has been applied, the
postconditions of \emph{ren}($P_1, P_2$) are that (i) $P_2$
must exist in \texttt{s2} and (ii) $P_1$ must not
exist in \texttt{s2}.  In TML form, the right side of $t$ has
the positive postcondition $P_2$ and the negative postcondition
$P_1$.  The \emph{ren}($P_2, P_1$) transformation poses the same
preconditions and postconditions as \emph{ren}($P_1, P_2$), with the
arguments reversed.  The \emph{ren} transformation does not contain a
query because data instances remain intact after the transformation.

The \emph{id}($P_1, P_2$) transformation behaves the same as the
\emph{ren}($P_1, P_2$) transformation, excpet that constructs
$P_1$ and $P_2$ in \emph{id} transformations must share the
same name (note that, for the implementation of the system, even
though $P_1$ and $P_2$ share the same name, they are
\textbf{not} the same construct~\footnote{The AutoMed system is
being implemented in Java.  Internally, each schema object is
represented in the system as a Java object.  The \emph{id}
transformation takes two schema objects, i.e., two references to
two Java objects, and marks them as being the same schema object.
The use of \emph{id} transformations is required when schema objects
from separate source schemas are integrated into a global schema,
see Section~\ref{sec:automed_implementation} for more details.}).
Both the
conditions and TML representation of \emph{id}($P_1, P_2$) and
\emph{id}($P_2, P_1$) are exactly the same as those for the
\emph{ren}($P_1, P_2$) and \emph{ren}($P_2, P_1$) transformations,
respectively.  For the same reason as for
the \emph{ren} transformation, the \emph{id} transformation
does not contain a query.



%The treatment for the \emph{ext}, \emph{con}, and \emph{id} transformations
%is the same as to \emph{add}, \emph{del}, and \emph{ren}, respectively.
%For \emph{ext} and \emph{con} transformations,
%the query giving the extent of the
%transformation construct is \texttt{VOID} to indicate that the
%construct is not derivable from the schema on which the transformation
%is applied.
Table~\ref{table:gen_form_tml_2}
shows the general TML form for the \emph{ext}, \emph{con}, and
\emph{id} transformations.

%\setlength{\extrarowheight}{4pt}
\setlength{\extrarowheight}{8pt}
\begin{table}
\begin{center}
\begin{tabular}{|c|c|l|}\hline

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% row 1
\emph{ext}($P_1$, \texttt{VOID}) &
\tml{t}{c(P_1)-P_1^+}
      {\phantom{\hspace{0.94cm}}P_1^-}
      {c(P_1)^+}{\emptyset} &
$P_1,P_2,\ldots$ are constructs,
%$C$ is a function that\\
\\

$S_1 \rightarrow S_2$ &
$P_1 \notin S_1$, $P_1 \in S_2$ &
%\raisebox{1.5ex}[0cm][0cm]{$C_1,C_2,\ldots$ are constructs,}
$c(P_n)$ is a function that
%returns all constructs\\
\\\cline{1-2}

%\emph{ext}(\texttt{A}, \texttt{VOID}) &
%\tml{t}{\emptyset}{A}{A}{\emptyset} &
%$^{\emptyset}_{-A}{t^{+A}_{\emptyset}}$ &
%that appear in $Q$\\\hline
%\raisebox{1.5ex}[0cm][0cm]{$C$ is a function that}
%\\\cline{1-2}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% row 2

\emph{con}($P_1$, \texttt{VOID}) &
%$^{+AC}_{\emptyset}{t^{\emptyset}_{-A}}$ &
\tml{t}{c(P_1)^+}
      {\phantom{\hspace{0.75cm}}\emptyset}
      {c(P_1)-P_1^+}{P_1^-} &
%\raisebox{1.5ex}[0cm][0cm]{$C(C_n)$ is a function that returns}
returns construct $P_n$ and all
%$C$ is a function that\\
\\

$S_1 \rightarrow S_2$ &
$P_1 \in S_1$, $P_1 \notin S_2$ &
%\raisebox{1.5ex}[0cm][0cm]{$C_n$ and all constructs referenced}
constructs referenced by $P_n$.
%returns all constructs\\
\\\cline{1-2}

%\emph{con}(\texttt{A}, \texttt{VOID}) &
%$^{+A}_{\emptyset}{t^{\emptyset}_{-A}}$ &
%\tml{t}{A}{\emptyset}{\emptyset}{A} &
%\raisebox{1.5ex}[0cm][0cm]{which $X$ depends on}\\\cline{1-2}
%that appear in $Q$\\\hline

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% row 2

\emph{id}($P_1, P_2$) &
\tml{t}{c(P_1) \ \cup \ (c(P_2) - P_2)^+}
      {\phantom{\hspace{2.4cm}}P_2^-}
      {(c(P_1) - P_1) \ \cup \ c(P_2)^+}{P_1^-} &
%\raisebox{1.5ex}[0cm][0cm]{by $C_n$.}
$c(Q)$ is a function that
\\
%$^{+A}_{-B}{t^{+B}_{-A}}$ & \\

$S_1 \rightarrow S_2$ &
$P_1 \in S_1$, $P_2 \notin S_1$ &
returns all constructs that
\\

& $P_2 \in S_2$, $P_1 \notin S_2$ &
appear in $Q$.
\\\hline

%\emph{id}(\texttt{A}, \texttt{B}) &
%\tml{t}{A}{B}{B}{A} & \\\hline
%$^{+A}_{-B}{t^{+B}_{-A}}$ & \\\hline

\end{tabular}
\end{center}
\caption{TML representation of the \emph{ext}, \emph{con}, and \emph{id} transformations\label{table:gen_form_tml_2}}
\end{table}
\setlength{\extrarowheight}{0pt}


%!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
% shortening again - nt 08/03/02
%% extend
%\textbf{\emph{The extend transformation}}\\
%Similar rules as the ones for the \emph{add} transformation
%apply to the \emph{ext}($P_1$, \texttt{VOID}) transformation.
%The preconditions for applying \emph{ext}($P_1$, \texttt{VOID})
%are that (i) $P_1$ \emph{must not} exist in \texttt{s1}, or that
%any construct that is of the same type as $P_1$ must not share the
%same name as $P_1$;  also, (ii) all the constructs referenced by
%$P_1$ (all the constructs that appear in the scheme of $P_1$,
%apart from $P_1$ itself) must already exist in \texttt{s1}.
%The postconditions of this transformation are that, (i) $P_1$ must
%exist in \texttt{s2} after the transformation has been applied; and
%(ii) the constructs referenced by $P_1$ must still exist in
%\texttt{s2}.
%
%Essentially, the \emph{ext} transformation is simply an \emph{add}
%transformation with the query giving the extent of $P_1$
%(the \texttt{Q} in \emph{add}($P_1, \{x|Q\}$)) replaced with
%\texttt{VOID}.
%So, by substituting $Q$ as \texttt{VOID} in the TML form
%of \emph{add}($P_1, \{x|Q\}$), the \emph{ext} transformation is expressed
%in TML as
%\tml{t}{(c(P_1)-P_1) \ \cup \ c(\texttt{VOID})^+}
%       {\phantom{\hspace{2.72cm}}P_1^-}
%       {c(P_1) \ \cup \ c(\texttt{VOID})^+}{\emptyset}.
%Since not having a query $Q$ that gives the extent of the transformation
%construct means that there are no particular requirements that the
%constructs in $Q$ must pre-exist, we will define that:
%\begin{displaymath}
%c(\texttt{VOID}) = \emptyset
%\end{displaymath}
%Thus, the \emph{ext}($P_1$, \texttt{VOID}) transformation in TML form
%can be simplified as:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%\begin{eqnarray*}
%& & \tml{t}{(c(P_1)-P_1) \cup \ c(\texttt{VOID})^+}
%         {\phantom{\hspace{2.6cm}}P_1^-}
%         {c(P_1) \ \cup \ c(\texttt{VOID})^+}{\emptyset}\\
%& = & \tml{t}{(c(P_1)-P_1) \ \cup \ \emptyset^+}
%         {\phantom{\hspace{1.83cm}}P_1^-}
%         {c(P_1) \ \cup \ \emptyset^+}{\emptyset}\\
%& = & \tml{t}{c(P_1)-P_1^+}
%         {\phantom{\hspace{0.93cm}}P_1^-}
%         {c(P_1)^-}{\emptyset}
%\end{eqnarray*}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%There are two interpretations of the \emph{ext}($P_1$, \texttt{VOID})
%transformation.  The \textbf{\emph{strict}} interpretation states that 
%$P_1$ must be a completely new concept introduced which
%\textbf{cannot} be derived from the existing constructs in \texttt{s1}.
%The \textbf{\emph{non-strict}} interpretation says that, even though the
%query giving the extent of $P_1$ is not present, it still
%implies that the extent of $P_1$ may be derivable from \texttt{s1},
%but the person who created the transformation did not put this
%infomation in the transformation either because (s)he does not know
%how to construct the query or it was simply an omission.
%In this paper, the non-strict interpretation is used for the
%\emph{ext} and \emph{con} transformations.
%
%% contract
%\textbf{\emph{The contract transformation}}\\
%The relationship between the \emph{con} and \emph{del}
%transformations is the same as that between the \emph{ext}
%and \emph{add} transformations.  Like
%\emph{del}($P_1, \{x|Q\}$),
%The preconditions for applying \emph{con}($P_1$, \texttt{VOID})
%are that (i) $P_1$ \emph{must} exist in \texttt{s1}; and
%(ii) all the constructs referenced by $P_1$ must already exist
%in \texttt{s1}.
%The postconditions of this transformation are that, (i) $P_1$
%\emph{must not} exist in \texttt{s2} after the transformation has
%been applied; and (ii) the constructs referenced by $P_1$ must still
%exist in \texttt{s2}.  The TML form of \emph{con} is very similar
%to that of \emph{del}, except that all occurrences of $c(Q)$ are
%missing for \emph{con} (it is replaced with $c(\emptyset)$ which
%evaluates to $\emptyset$.
%
%% id
%\textbf{\emph{The id transformation}}\\
%The \emph{id}($P_1, P_2$) transformation behaves the same as the
%\emph{ren}($P_1, P_2$) transformation, excpet that constructs
%$P_1$ and $P_2$ in \emph{id} transformations must share the
%same name (note that, for the implementation of the system, even
%though $P_1$ and $P_2$ share the same name, they are
%\textbf{not} the same construct~\footnote{The AutoMed system is
%being implemented in Java.  Internally, each schema object is
%represented in the system as a Java object.  The \emph{id}
%transformation takes two schema objects, i.e., two references to
%two Java objects, and marks them as being the same schema object.
%The use of \emph{id} transformations is required when schema objects
%from separate source schemas are integrated into a global schema,
%see Section~\ref{sec:automed_implementation} for more details.}).
%Both the
%conditions and TML representation of \emph{id}($P_1, P_2$) and
%\emph{id}($P_2, P_1$) are exactly the same as those for the
%\emph{ren}($P_1, P_2$) and \emph{ren}($P_2, P_1$) transformations,
%respectively.  For the same reason as for
%the \emph{ren} transformation, the \emph{id} transformation
%does not contain a query.

\textbf{Example 2}\\
Transformations \snsref{s11} to \snsref{s15} that transform
\texttt{s1} $\rightarrow$ \texttt{sg} in TML representation:\\

\snsref{s11} \tml{t_1}{\myhdms{p},\myhdms{p,s}^+}
            {\phantom{\hspace{0.84cm}}\myhdms{m}^-}
            {\myhdms{m},\myhdms{p},\myhdms{p,s}^+}{\emptyset}\\
\snsref{s12} \tml{t_2}{\myhdms{p},\myhdms{p,s}^+}
            {\phantom{\hspace{1cm}}\myhdms{f}^-}
            {\myhdms{f},\myhdms{p},\myhdms{p,s}^+}{\emptyset}\\
\snsref{s13} \tml{t_3}{\myhdms{p},\myhdms{m},\myhdms{p,s}^+}
            {\phantom{\hspace{0.89cm}}\myhdms{sex,p,m}^-}
            {\myhdms{sex,p,m},\myhdms{p},\myhdms{m},\myhdms{p,s}^+}
            {\emptyset}\\
\snsref{s14} \tml{t_4}{\myhdms{p},\myhdms{f},\myhdms{p,s}^+}
            {\phantom{\hspace{0.9cm}}\myhdms{sex,p,f}^-}
            {\myhdms{sex,p,f},\myhdms{p},\myhdms{f},\myhdms{p,s}^+}
            {\emptyset}\\
\snsref{s15} \tml{t_5}{\myhdms{p,s},\myhdms{m},\myhdms{f}^+}
            {\phantom{\hspace{2.28cm}}\emptyset}
            {\myhdms{m},\myhdms{f}^+}{\myhdms{p,s}^-}

Table~\ref{table:scheme_abbr} shows the abbreviations used for the
scheme of constructs in Example~2 and all other examples in the rest
of this paper.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{table}
\begin{center}
\begin{tabular}{|l|l|}
\hline
Abbreviation & Scheme \\
\hline
\myhdmf{p} & \myhdmf{person}\\
\myhdmf{p,s} & \myhdmf{person,sex}\\
\myhdmf{m} & \myhdmf{male}\\
\myhdmf{f} & \myhdmf{female}\\
\myhdmf{sex,p,m} & \myhdmf{sex,person,male}\\
\myhdmf{sex,p,f} & \myhdmf{sex,person,female}\\
\myhdmf{w,p,d} & \myhdmf{worksin,person,dept}\\
\myhdmf{d} & \myhdmf{dept}\\
\myhdmf{p,dn} & \myhdmf{person,dname}\\
\myhdmf{d,dn} & \myhdmf{dept,dname}\\
\hline
\end{tabular}
\caption{Abbreviations used for the scheme of constructs in
examples\label{table:scheme_abbr}}
\end{center}
\end{table}

\subsection{Rules for Optimisation}
\label{sec:op_rules}

We can verify whether or not a transformation pathway is well-formed
by expressing the transformation steps in TML.  Provided the pathway
is well-formed, we can also determine when the order of two
transformations can be rearranged, when they can be simplied, and
when they are redundant and hence can be removed from the transformation
pathway.  In the following sections, $TP$ refers to the following
transformation pathway:

\begin{center}
$TP_{1,n}$ = [\tml{t_1}{a_1^+}{b_1^-}{c_1^+}{d_1^-},
         \tml{t_2}{a_2^+}{b_2^-}{c_2^+}{d_2^-},
$\ldots$, \tml{t_n}{a_n^+}{b_n^-}{c_n^+}{d_n^-}]
\end{center}

\subsubsection{Verifying the well-formedness of a transformation pathway}
\label{sec:rule_wellform}

Starting with a simple case where $TP$ contains only two transformations,
$t_1$ and $t_2$, it is clear that $TP$ is \textbf{not} well-formed if
the postconditions of $t_1$ conflict with the preconditions of $t_2$,
regardless of whether or not the preconditions of $t_1$ are satisfied.
The first observation for a transformation pathway to be well-formed
is that at least the following rules hold:

\begin{center}
\begin{tabular}{ll}
$c_1^+ \ \cap \ b_2^-$ = $\emptyset$ &
$\phantom{\hspace{2cm}}$(1.1)\\
$d_1^- \ \cap \ a_2^+$ = $\emptyset$ &
$\phantom{\hspace{2cm}}$(1.2)
\end{tabular}
\end{center}

However, when there are more than two transformations in $TP$,
the above rules must be extended to account for the accumulative
effect of conditions posed by the transformations.
A transformation pathway is said to be \textbf{well-formed} if (i) for any
given transformation step in the pathway, its preconditions and
postconditions do not conflict with those of \textbf{all} other
transformations, and (ii) the
\textbf{accumulative non-verifiable preconditions}
%, $NVP(TP)$, 
of all the transformations are satisfied either by the content of the
initial schema, $S_{init}$, on which the transformations in
$TP$ are to be applied, or by other transformations in the
pathway.  Accumulative non-verifiable preconditions are those whose
satisfiability cannot be determined solely by analysing the
preconditions and postconditions of the preceeding transformation.
Their satisfiability can be determined only if we look further down
the chain of preceeding transformations and when there are no
more preceeding transformations, the content of the initial schema.
The following recursive rule $wf$ determines whether or not a
transformation pathway is well-formed:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{eqnarray*}
wf(P, M, [S_{init},t_1,\ldots,t_n]) & \leftarrow &
(c_n^+ \ \cap \ M = \emptyset) \wedge 
(d_n^- \ \cap \ P = \emptyset) \wedge \\
& & wf(P-c_n^++a_n^+, M-d_n^-+b_n^-, [S_{init},t_1,\ldots,t_{n-1}])
\phantom{\hspace{0.5cm}}\textrm{(1.3)}\\
wf(P, M, [S_{init}]) & \leftarrow &
P \in S_{init} \wedge M \notin S_{init}
\end{eqnarray*}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Working backwards from the last transformation step $t_n$ in a
transformation pathway, we first make sure that the positive
postcondition $c_n^+$ does not conflict with the \textbf{accumulative
negative conditions} $M$ and the negative postcondition $d_n^-$
does not conflict with the \textbf{accumulative positive conditions}
$P$.
%The value of both $P$ and $M$ will always be $\emptyset$ when
%the rule is first run, so the first two conditions of the rule will
%always be satisfied.
If $t_n$ is the last transformation in $TP$ and we are verifying
whether or not $S_{init}$ satisfies all the requirements for the
existence and non-existence of constructs specified by all
the transformations in $TP$, except the requirements satisfied by
some other transformations in $TP$, the initial value of both
$P$ and $M$ will be $\emptyset$.  In cases where there exists a
schema $S_{final}$, which is supposed to be the result of applying
all transformations in $TP$ on $S_{init}$, and we wish to verify
if both $S_{init}$ and $S_{final}$ satisfy the construct requirements
on their contents, the value of $P$ would then be set to the contents
of $S_{final}$ and the value of $M$ would be $\emptyset$.
The positive conditions produced by applying
$t_n$ ($c_n^+$) is then taken away from $P$, and the positive conditions
required by $t_n$ ($a_n^+$) is added to $P$, hence the name
\textbf{accumulative} positive conditions.  Similar treatment is made
to the negative conditions -- the negative conditions produced by
applying $t_n$ ($d_n^-$) is taken away from $M$, and the negative
conditions required by $t_n$ ($b_n^-$) is added to $M$.  The new
values of $P$ and $M$ is then checked against with the previous
transformation step in the pathway, $t_{n-1}$.  This way, we ensure
that the positive (negative) postcondition of one transformation does
not conflict with the negative (positive) preconditions of the
next transformation and those after it.  The rule is run
recursively for each transformation step until the initial schema
$S_{init}$ is reached.  At that point, all the constructs in
$P$ and $M$ are those that have not been satisfied by any of the
transformations in the pathway.  The transformation is said to
be well-formed if all the constructs in $P$ exist in $S_{init}$ and
all the constructs in $M$ does not exist in $S_{init}$.  Example~3
shows how the rule of well-formedness is applied to a transformation
pathway.


\textbf{Example 3}\\
Verifying the well-formedness of the transformation pathway
$TP_{\texttt{s1}\rightarrow \texttt{sg}}$ (transformations
\snsref{s11} to \snsref{s15}):
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{eqnarray*}
TP_{\texttt{s1}\rightarrow \texttt{sg}} & = &
[
\tml{t_1}{\myhdms{p},\myhdms{p,s}^+}
            {\phantom{\hspace{0.84cm}}\myhdms{m}^-}
            {\myhdms{m},\myhdms{p},\myhdms{p,s}^+}
            {\emptyset},
\tml{t_2}{\myhdms{p},\myhdms{p,s}^+}
            {\phantom{\hspace{1cm}}\myhdms{f}^-}
            {\myhdms{f},\myhdms{p},\myhdms{p,s}^+}{\emptyset},\\
& & \tml{t_3}{\myhdms{p},\myhdms{m},\myhdms{p,s}^+}
            {\phantom{\hspace{0.89cm}}\myhdms{sex,p,m}^-}
            {\myhdms{sex,p,m},\myhdms{p},\myhdms{m},\myhdms{p,s}^+}
            {\emptyset},\\
& & \tml{t_4}{\myhdms{p},\myhdms{f},\myhdms{p,s}^+}
            {\phantom{\hspace{0.9cm}}\myhdms{sex,p,f}^-}
            {\myhdms{sex,p,f},\myhdms{p},\myhdms{f},\myhdms{p,s}^+}
            {\emptyset},
\tml{t_5}{\myhdms{p,s},\myhdms{m},\myhdms{f}^+}
            {\phantom{\hspace{2.28cm}}\emptyset}
            {\myhdms{m},\myhdms{f}^+}{\myhdms{p,s}^-}
]
\end{eqnarray*}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Recursion 1 (working on $t_5$):\\
$
\phantom{\hspace{1cm}}
wf(\emptyset, \emptyset, [\texttt{s1}, t_1, t_2, t_3, t_4, t_5])
\rightarrow \\\phantom{\hspace{1.5cm}}
(\{\myhdmf{m},\myhdmf{f}\} \ \cap \ \emptyset = \emptyset) \wedge
(\{\myhdmf{p,s}\} \ \cap \ \emptyset = \emptyset) \wedge\\
\phantom{\hspace{1.5cm}}
wf(\{\myhdmf{p,s},\myhdmf{m},\myhdmf{f}\}, \emptyset,
[\texttt{s1}, t_1, t_2, t_3, t_4])
$

Recursion 2 (working on $t_4$):\\
$
\phantom{\hspace{1cm}}
wf(\{\myhdmf{p,s},\myhdmf{m},\myhdmf{f}\}, \emptyset,
[\texttt{s1}, t_1, t_2, t_3, t_4])
\rightarrow \\\phantom{\hspace{1.5cm}}
(\{\myhdmf{sex,p,f},\myhdmf{p},\myhdmf{f},\myhdmf{p,s}\} \ \cap
\ \emptyset = \emptyset) \wedge
(\emptyset \ \cap \ \{\myhdmf{p,s},\myhdmf{m},\myhdmf{f}\} = \emptyset)
\wedge\\
\phantom{\hspace{1.5cm}}
wf(\{\myhdmf{m},\myhdmf{p},\myhdmf{f},\myhdmf{p,s}\},
\{\myhdmf{sex,p,f}\}, [\texttt{s1}, t_1, t_2, t_3])
$

%!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
% shortening starts - nt 09/03/02
%Recursion 3 (working on $t_3$):\\
%$
%\phantom{\hspace{1cm}}
%wf(\{m,p,f,(p,s)\}, \{(sex,p,f)\}, [\texttt{s1}, t_1, t_2, t_3])
%\rightarrow \\\phantom{\hspace{1.5cm}}
%(\{(sex,p,m),p,m,(p,s)\} \ \cap \ \{(sex,p,f)\} = \emptyset) \wedge
%(\emptyset \ \cap \ \{m,p,f,(p,s)\} = \emptyset) \wedge\\
%\phantom{\hspace{1.5cm}}
%wf(\{f,p,m,(p,s)\}, \{(sex,p,f),(sex,p,m)\}, [\texttt{s1}, t_1, t_2])
%$
%
%Recursion 4 (working on $t_2$):\\
%$
%\phantom{\hspace{1cm}}
%wf(\{f,p,m,(p,s)\}, \{(sex,p,f),(sex,p,m)\}, [\texttt{s1}, t_1, t_2])
%\rightarrow \\\phantom{\hspace{1.5cm}}
%(\{f,p,(p,s)\} \ \cap \ \{(sex,p,f),(sex,p,m)\} = \emptyset) \wedge
%(\emptyset \ \cap \ \{f,p,m,(p,s)\} = \emptyset) \wedge\\
%\phantom{\hspace{1.5cm}}
%wf(\{m,p,(p,s)\}, \{(sex,p,f),(sex,p,m),f\}, [\texttt{s1}, t_1])
%$
%
%Recursion 5 (working on $t_1$):\\
%$
%\phantom{\hspace{1cm}}
%wf(\{m,p,(p,s)\}, \{(sex,p,f),(sex,p,m),f\}, [\texttt{s1}, t_1])
%\rightarrow \\\phantom{\hspace{1.5cm}}
%(\{m,p,(p,s)\} \ \cap \ \{(sex,p,f),(sex,p,m),f\} = \emptyset) \wedge
%(\emptyset \ \cap \ \{m,p,(p,s)\} = \emptyset) \wedge\\
%\phantom{\hspace{1.5cm}}
%wf(\{p,(p,s)\}, \{(sex,p,f),(sex,p,m),f,m\}, [\texttt{s1}])
%$
% shortening ends - replaced with \vdots
$\phantom{\hspace{2cm}}\vdots$

Recursion 6 (working on \texttt{s1}):\\
$
\phantom{\hspace{1cm}}
wf(\{\myhdmf{p},\myhdmf{p,s}\}, \{\myhdmf{sex,p,f},\myhdmf{sex,p,m},
\myhdmf{f},\myhdmf{m}\}, [\texttt{s1}])
\rightarrow \\\phantom{\hspace{1.5cm}}
\{\myhdmf{p},\myhdmf{p,s}\} \in \texttt{s1} \wedge
\{\myhdmf{sex,p,f},\myhdmf{sex,p,m},\myhdmf{f},\myhdmf{m}\} \notin \texttt{s1}
$

%The following recursive rule determines whether or not a positive
%precondition $p$,
%where $p \in a_{i}+$ of $t_{i}$ and $t_{i} \in TP$, $i \geq 1$,
%is satisfied:

%\begin{eqnarray*}
%con\_present(p,t_i) & \leftarrow &
%p \in (c_{i-1}+) \vee p \in (a_{i-1}+)
%\vee con\_present(p, t_{i-1}) \ for \ i > 1\\
%con\_present(p, t_1) & \leftarrow & p \in S_{init}(TP)
%\end{eqnarray*}

%For any positive precondition $p$ in $a_{i}+$ of $t_i$, its
%satisfiability is fulfilled if $p$ is present in the set of
%positive postconditions of the preceeding transformation step
%$t_{i-1}$.  Its satisfiability is also fulfilled if $p$ is
%present in the set of positive preconditions of $t_{i-1}$.
%We make such a conclusion because the positive preconditions of
%$t_{i-1}$ are assumed to have already been satisfied.  If
%neither the preconditions nor the postconditions of $t_{i-1}$
%contain $p$, we then look for its presence in the preconditions
%and postconditions of the transformation step that preceeds
%$t_{i-1}$, i.e., we search for $p$ in $t_{i-2}$.  When there
%are no more transformation steps in the pathway that preceed
%the one that is being looked at, i.e., when the $i$ in $t_{i}$
%is $1$, $p$ is searched for in the content of the initial
%schema, $S_{init}(TP)$, to which the transformation steps in
%$TP$ are to be applied.

%Similar rules apply to determine whether or not a negative
%precondition $m$, where $m \in b_{i}-$ of $t_{i}$ and $t_{i} \in TP$,
%$i \geq 1$, is satisfied:

%\begin{eqnarray*}
%con\_not\_present(m,t_i) & \leftarrow &
%m \in (d_{i-1}-) \vee m \in (b_{i-1}-)
%\vee con\_not\_present(m, t_{i-1}) \ for \ i > 1\\
%con\_not\_present(m, t_1) & \leftarrow & m \notin S_{init}(TP)
%\end{eqnarray*}

%In summary, $TP$ is well-formed if the following conditions are
%satisfied:

%\begin{center}
%\begin{tabular}{lll}
%& $c_{i}+ \ \cap \ b_{i+1}-$ = $\emptyset$ & \\
%$\wedge$ & $d_{i}- \ \cap \ a_{i+1}+$ = $\emptyset$ &
%\raisebox{1ex}[0cm][0cm]{\huge \} \normalsize $\forall i$}\\
%$\wedge$ & $con\_present(p,t_i)$\\
%$\wedge$ & $con\_not\_present(m,t_i)$ &
%\raisebox{1ex}[0cm][0cm]{\huge \}
%\normalsize $\forall ipq \mid p \in a_i+, q \in b_i-$}\\
%%$\wedge$ & $NVP(TP)$ $\in$ $S_{init}(TP)$
%\end{tabular}
%\end{center}


\subsubsection{Determining whether or not two transformations can be reordered}

Before considering whether or not any pairs of transformation steps
in a transformation pathway can be reordered, it must be ensured that
the transformation pathway is well-formed.  The rules for order
rearrangement are, (i) the change in the order of any two transformations
must maintain the well-formedness of the transformation pathway, and
(ii) the overall result of all the transformations in the pathway
must remain unchanged.

%For example, the change of order must not cause any conflicts between the
%neighbouring pairs of transformations.
%For example, if we have a set of transformations
%$T$ = [$t_1$, $t_2$, $t_3$], let's say we wish to change
%the order of the transformations in $T$ to create $T'$
%such that $T'$ = [$t_2$, $t_1$, $t_3$].  The changing of
%the order is allowed only if the preconditions of $t_2$ are satisfied,
%and the postconditions of $t_2$ do not conflict with the preconditions
%of $t_1$, and the postconditions of $t_1$ do not conflict with the
%preconditions of $t_3$.  Generally speaking, there is a conflict
%between conditions if
%there exists a pair of positive and negative conditions on the same
%construct.  So, if we compare the positive postconditions
%of $t_1$ ($c_1+$) and the negative preconditions of $t_3$ ($b_3-$), if
%the intersection of the two sets $c_1+$ and $b_3-$ does not yield
%$\emptyset$, it means that conflicts exist between the conditions and
%hence we cannot put $t_1$ and $t_3$ together in that order.
To swap
the order of two adjacent transformation steps $t_i$ and $t_{i+1}$,
we must also ensure that $t_{i+1}$ does not contain in its
preconditions a construct that is satisfied by the postconditions of
%the changes made by applying
the transformation step that preceeds it.  For example, if $t_{i+1}$
requires that construct $P$ to exist, i.e., $P \in a_{i+1}^+$, then
$P$ must not have been created by $t_i$, i.e.,
$P \notin (c_i^+ \ \cap \ b_i^-)$.
Similarly, if $t_{i+1}$ requires that construct $Q$ not to exist, i.e.,
$Q \in b_{i+1}^-$, then $Q$ must not have been removed by $t_i$, i.e.,
$Q \notin (d_i^- \ \cap \ a_i^+)$.

Putting the rules altogehter, the order of $t_i$ and $t_{i+1}$ in $TP$,
where $1 \leq i < n$, can be rearranged if the following holds:

\begin{center}
\begin{tabular}{ll}
$c_{i-1}^+ \ \cap \ b_{i+1}^-$ = $\emptyset$ &
$\phantom{\hspace{5cm}}$(2.1)\\
$d_{i-1}^- \ \cap \ a_{i+1}^+$ = $\emptyset$ &
\raisebox{1ex}[0cm][0cm]{\huge \} \normalsize if $i > 1$}
$\phantom{\hspace{3.14cm}}$(2.2)\\
$c_i^+ \ \cap \ b_{i+2}^-$ = $\emptyset$ &
$\phantom{\hspace{5cm}}$(2.3)\\
$d_i^- \ \cap \ a_{i+2}^+$ = $\emptyset$ &
\raisebox{1ex}[0cm][0cm]{\huge \} \normalsize if $i < n-1$}
$\phantom{\hspace{2.43cm}}$(2.4)\\
$(c_i^+ \ \cap \ b_i^-) \ \cap \ a_{i+1}^+ = \emptyset$ &
$\phantom{\hspace{5cm}}$(2.5)\\
$(d_i^- \ \cap \ a_i^+) \ \cap \ b_{i+1}^- = \emptyset$ &
$\phantom{\hspace{5cm}}$(2.6)\\
\end{tabular}
\end{center}


\textbf{Example 4}\\
Determining whether or not the order of a few of the transformations
in the pathway $TP_{\texttt{s1}\rightarrow \texttt{sg}}$ (transformations
\snsref{s11} to \snsref{s15}) can be altered:

Attempting to swap the order of $t_2$ and $t_5$:

\begin{center}
$
\tml{t_2}{\myhdms{p},\myhdms{p,s}^+}
         {\phantom{\hspace{1cm}}\myhdms{f}^-}
         {\myhdms{f},\myhdms{p},\myhdms{p,s}^+}{\emptyset},
\tml{t_5}{\myhdms{p,s},\myhdms{m},\myhdms{f}^+}
         {\phantom{\hspace{2.28cm}}\emptyset}
         {\myhdms{m},\myhdms{f}^+}{\myhdms{p,s}^-}
$
\end{center}

The rules of order rearrangement are evaluated as follows:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{eqnarray*}
c_1^+ \ \cap \ b_5^- & = &
\{\myhdmf{m},\myhdmf{p},\myhdmf{p,s}\} \ \cap \ \emptyset = \emptyset\\
d_1^- \ \cap \ a_5^+ & = & \emptyset \ \cap
\ \{\myhdmf{p,s},\myhdmf{m},\myhdmf{f}\} = \emptyset\\
c_2^+ \ \cap \ b_6^- & = & \emptyset \ \textrm{because $t_6$ does not exist}\\
d_2^- \ \cap \ a_6^+ & = & \emptyset \ \textrm{because $t_6$ does not exist}\\
(c_2^+ \ \cap \ b_2^-) \ \cap \ a_5^+ & = &
(\{\myhdmf{f},\myhdmf{p},\myhdmf{p,s}\} \ \cap
\ \{\myhdmf{f}\}) \ \cap
\ \{\myhdmf{p,s},\myhdmf{m},\myhdmf{f}\} = \{\myhdmf{f}\}\\
(d_2^- \ \cap \ a_2^+) \ \cap \ b_5^- & = &
(\emptyset \ \cap \ \{\myhdmf{p},\myhdmf{p,s}\}) \ \cap
\ \emptyset = \emptyset
\end{eqnarray*}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Because not all the rules evaluate to $\emptyset$, we can conclude
that the order of $t_2$ and $t_5$ cannot be altered.


Attempting to swap the order of $t_2$ and $t_3$:

\begin{center}
$
\tml{t_2}{\myhdms{p},\myhdms{p,s}^+}
         {\phantom{\hspace{1cm}}\myhdms{f}^-}
         {\myhdms{f},\myhdms{p},\myhdms{p,s}^+}{\emptyset},
\tml{t_3}{\myhdms{p},\myhdms{m},\myhdms{p,s}^+}
         {\phantom{\hspace{0.89cm}}\myhdms{sex,p,m}^-}
         {\myhdms{sex,p,m},\myhdms{p},\myhdms{m},\myhdms{p,s}^+}
         {\emptyset}
$
\end{center}

The rules of order rearrangement are evaluated as follows:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{eqnarray*}
c_1^+ \ \cap \ b_3^- & = &
\{\myhdmf{m},\myhdmf{p},\myhdmf{p,s}\} \ \cap
\ \{\myhdmf{sex,p,m}\} = \emptyset\\
d_1^- \ \cap \ a_3^+ & = &
\emptyset \ \cap
\ \{\myhdmf{p},\myhdmf{m},\myhdmf{p,s}\} = \emptyset\\
c_2^+ \ \cap \ b_4^- & = &
\{\myhdmf{f},\myhdmf{p},\myhdmf{p,s}\} \ \cap
\ \{\myhdmf{sex,p,f}\} = \emptyset\\
d_2^- \ \cap \ a_4^+ & = &
\emptyset \ \cap \ \{\myhdmf{p},\myhdmf{f},\myhdmf{p,s}\} = \emptyset\\
(c_2^+ \ \cap \ b_2^-) \ \cap \ a_3^+ & = &
(\{\myhdmf{f},\myhdmf{p},\myhdmf{p,s}\} \ \cap
\ \{\myhdmf{f}\}) \ \cap
\ \{\myhdmf{p},\myhdmf{m},\myhdmf{p,s}\} = \emptyset\\
(d_2^- \ \cap \ a_2^+) \ \cap \ b_3^- & = &
(\emptyset \ \cap \ \{\myhdmf{p},\myhdmf{p,s}\}) \ \cap
\ \{\myhdmf{sex,p,m}\} = \emptyset
\end{eqnarray*}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Because all the rules are satisfied, we can conclude that the
order of $t_2$ and $t_3$ can be reversed without affecting the
overall result of all the transformations in the pathway.


\subsubsection{Detecting redundant transformations that can be removed}

Two transformations $t_i$ and $t_{i+1}$, that are adjacent to each
other in $TP$, are redundant if
$t_i$ is the reverse of $t_{i+1}$, i.e., $t_i = \overline{t_{i+1}}$
and vice versa.  In this case, the state of the
resultant schema after applying all the transformations in $TP$
is the same whether or not both $t_i$ and $t_{i+1}$ are applied.
In TML terms, two transformations $t_i$ and $t_{i+1}$ are redundant
if the following holds:

\begin{center}
$(a_i^+ \ = \ c_{i+1}^+) \wedge \ (b_i^- \ = \ d_{i+1}^-)
\wedge \ (c_i^+ \ = \ a_{i+1}^+) \wedge \ (d_i^- \ = b_{i+1}^-)$
$\phantom{\hspace{1cm}}$(3)
\end{center}

It is logically obvious that if the above rules hold, then $t_i$
and $t_{i+1}$ are redundant, since the preconditions of $t_i$ are
exactly the same as the postconditions of $t_{i+1}$, and the
postconditions of $t_i$ are exactly the same as the preconditions
of $t_{i+1}$, i.e., the net effect of the two transformations is
$\emptyset$.  Since the preconditions of $t_i$ are the same as
the postconditions of $t_{i+1}$, if $TP$ prior to $t_i$ is
well-formed, then $TP$ with $t_i$ and $t_{i+1}$ taken out of
the pathway must still be well-formed because $t_i$ and $t_{i+1}$
produce no overall effect on $TP$.

To determine whether or not two transformations $t_x$ and $t_y$,
which are not adjacent to each other, are redundant, their order
in $TP$ must first be changed so that they become adjacent to
each other and apply the above rule.  Note that, the adjacency
of the transformations is the only requirement for applying our
rule for detecting redundancy.  The order of $t_x$ and $t_y$ is
irrelevant, since saying ``$t_x$ and $t_y$ are redundant'' is
the same as saying ``$t_y$ and $t_x$ are redundant'', and our
rule produces the same result no matter how $t_x$ and $t_y$
are ordered against each other.


\textbf{Example 5}\\
Determining whether or not transformation pairs are redundant:

Testing $t_4$ and $t_5$:
\begin{center}
\tml{t_4}{\myhdms{p},\myhdms{f},\myhdms{p,s}^+}
         {\phantom{\hspace{0.9cm}}\myhdms{sex,p,f}^-}
         {\myhdms{sex,p,f},\myhdms{p},\myhdms{f},\myhdms{p,s}^+}{\emptyset},
\tml{t_5}{\myhdms{p,s},\myhdms{m},\myhdms{f}^+}
         {\phantom{\hspace{2.28cm}}\emptyset}
         {\myhdms{m},\myhdms{f}^+}{\myhdms{p,s}^-}
\end{center}
Because $a_4^+ \neq c_5^+$, we can already conclude that $t_4$
and $t_5$ are not redundant without checking the other three
conditions in the rule.

Testing $t_6$ and $t_{\overline{10}}$:
\begin{center}
\tml{t_6}{\myhdms{p,dn}^+}
         {\phantom{\hspace{0.38cm}}\myhdms{d}^-}
         {\myhdms{p,dn},\myhdms{d}^+}{\emptyset},
\tml{t_{\overline{10}}}{\myhdms{d},\myhdms{p,dn}^+}
         {\phantom{\hspace{1.75cm}}\emptyset}
         {\myhdms{p,dn}^+}{\myhdms{d}^-}
\end{center}

Because all the conditions
$a_6^+ = c_{\overline{10}}^+$ and $b_6^- = d_{\overline{10}}^-$ and
$c_6^+ = a_{\overline{10}}^+$ and $d_6^- = b_{\overline{10}}^-$ are
satisfied, we can conclude that $t_6$ and $t_{\overline{10}}$
are redundant.

% !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
% shortened - not enough time to complete - nt 07/03/02
%
%\subsubsection{Detecting transformations that can be simplified}
%
%\begin{verbatim}
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% below is wrong!! 2 B rewritten
%\end{verbatim}
%
%Transformations that can be simplified but are not redundant are
%more difficult to detect.  One obvious starting point is to look for
%transformations that act on the same construct.
%
%(situations in which we expect to find simplifiable transformations)
%
%
%In cases where the preconditions (postconditions) of $t_i$ are
%not exactly the same as the postconditions (preconditions) of
%$t_{i+1}$, the following must hold true for these two transformations
%to be qualified as simplifiable:
%
%\begin{center}
%$(a_{i}+ \ \subseteq \ b_{i+1}+) \ \wedge
%\ ((b_{i+1}+) - a_{i}+)+$ must hold previously\\
%$(a_{i}- \ \subseteq \ b_{i+1}-) \ \wedge
%\ ((b_{i+1}-) - a_{i}-)-$ must hold previously\\
%$(b_{i}+ \ \subseteq \ a_{i+1}+) \ \wedge
%\ ((a_{i+1}+) - b_{i}+)+$ must hold previously\\
%$(b_{i}- \ \subseteq \ a_{i+1}-) \ \wedge
%\ ((a_{i+1}-) - b_{i}-)-$ must hold previously\\
%\end{center}
%
%In essence, the positive(negative) postconditions of $t_i$ must
%be a subset of the positive(negative) preconditions of $t_{i+1}$
%and the difference between the sets of conditions must already
%hold true in previous transformation steps in the pathway; and
%the positive(negative) preconditions of $t_i$ must be a subset
%of the positive(negative) postconditions of $t_{i+1}$ and the
%difference between the sets of conditions must already hold
%true in previous transformation steps in the pathway.  To do
%this, we match the difference with the conditions in previous
%transformations in the pathway.  If there are no matches, we
%check the conditions of the difference against the database.
%If the conditions of the difference are satisfied, $t_i$ and
%$t_{i+1}$ are then classified as being redundant.  As a small
%example to illustrate how conditions of the difference are
%checked against previous transformation steps and the source
%database, suppose we
%have $a_{i}+ \ = \ \{\myhdms{P}\}$ and $b_{i+1}+ \ =
%\ \{\myhdms{P}, \myhdms{Q}\}$, then we must ensure that
%$(a_{i}+) - b_{i+1}+ = \{\myhdms{Q}\}+$ must already hold true
%in the conditions of previous transformations.  If we fail to
%find a match of $\{\myhdms{Q}\}+$ in the conditions of previous
%transformation steps in the pathway, we will try to verify the
%existence of \myhdms{Q} in the source schema (the database).
%
%
%
%%Assuming we are still working on the set of
%%transformations $T$, the general steps for determining whether
%%or not $t_1$ and $t_2$ are redundant are as follows:
%
%%\begin{enumerate}
%%   \item    There must not exist any conflicts between the postconditions
%%            and preconditions of any pair of transformations (violating
%%            this condition indicates that the transformation pathway is not
%%            a valid one in the first place).
%%   \item    Compare the postconditions of $t_1$ with the preconditions
%%            of $t_2$, any construct that has the $+$ ($-$) sign in
%%            $t_2$'s preconditions must also exist as a positive
%%            (negative) pre- or post-condition for $t_1$.
%%   \item    Compare $t_1$'s preconditions with $t_2$'s postconditions.
%%            If there are any matching constructs, they must also have the
%%            same sign.  To qualify $t_1$ and $t_2$ to be redundant,
%%            these matching constructs must also be the matching
%%            constructs found in step 2.  Do the same comparison with
%%            $t_1$'s postconditions against $t_2$'s preconditions.
%%\end{enumerate}
%
%
%%If we have a series of transformations $T_{1}$ =
%%[\footnotesize
%%\textsf{add(A)}, \textsf{ext(B)},
%%\textsf{del(A)}
%%\normalsize],
%%in TML form, $T_{1}$ = [
%%\tml{t_{1}}{C}{A}{AC}{\emptyset},
%%\tml{t_{2}}{\emptyset}{B}{B}{\emptyset},
%%\tml{t_{3}}{AC}{\emptyset}{C}{A}],
%%we can apply the
%%order rearrangement rule to $t_{1}$ and $t_{2}$ because by
%%swapping the order of $t_{1}$ and $t_{2}$, the postconditions of
%%$t_{1}$ do not conflict with the preconditions of $t_{3}$, and the
%%postconditions of $t_{2}$ do not conflict with the preconditions
%%of $t_{1}$.  So, we now have $T_{1}'$ = [
%%\tml{t_{2}}{\emptyset}{B}{B}{\emptyset},
%%\tml{t_{1}}{C}{A}{AC}{\emptyset},
%%\tml{t_{3}}{AC}{\emptyset}{C}{A}].
%%Applying the
%%rules for collapsing redundant transformations, we remove
%%$t_{1}$ and $t_{2}$ from $T_{1}'$.  Thus, we have reduced
%%$T_{1}$ to
%%[\tml{t_{2}}{\emptyset}{B}{B}{\emptyset}],
%%i.e., [\footnotesize\textsf{ext(B)}\normalsize].
%
% end of shortening - nt 07/03/02

\subsection{An Example Using TML for Transformation Optimisation}

We will now revisit the example in Figure~\ref{fig:example_er} and
represent the transformations using the TML, to illustrate how the
TML can be used to facilitate the detection of re-orderable and
redundant transformations.
%Figure~\ref{fig:example_er_evolve}
%shows the same scenario as Figure~\ref{fig:example_er}, with the
%addition of a schema named \texttt{ev2}, which is evolved from
%\texttt{s2} via 3 transformation steps.


%\textbf{Summary (figure)}

We will concentrate on the transformations between the schemas
\texttt{ev2} and \texttt{sg}.  Recall from Section~\ref{sec:bg} that
the transformations from \texttt{ev2} to \texttt{sg} are:\\[0.1cm]

\begin{sffamily}\footnotesize
\isnsref{s2ev3} delRelationship(\myhdmf{worksin, person, dept, 1:1, 1:N},
\{X,Y $\mid \langle$X,Y$\rangle \in$ \myhdmf{person, dname}\}\\
\isnsref{s2ev2} delAttribute(\myhdmf{dept, dname},
\{X,X $\mid \langle$\_,X$\rangle \in$ \myhdmf{person, dname}\})\\
\isnsref{s2ev1} delEntity(\myhdmf{dept},
\{X $\mid \langle$\_,X$\rangle \in$ \myhdmf{person, dname}\})\\
\snsref{s21} addEntity(\myhdmf{dept},
\{X $\mid \langle$\_,X$\rangle \in$ \myhdmf{person, dname}\})\\
\snsref{s22} addAttribute(\myhdmf{dept, dname},
\{X,X $\mid \langle$\_,X$\rangle \in$ \myhdmf{person, dname}\})\\
\snsref{s23} addRelationship(\myhdmf{worksin, person, dept, 1:1, 1:N},
\{X,Y $\mid \langle$X,Y$\rangle \in$ \myhdmf{person, dname}\}\\
\snsref{s24} delAttribute(\myhdmf{person, dname},
\{X,Y $\mid \langle$\_,X,Y$\rangle \in$ \myhdmf{worksin, person, dept}\}\\
\end{sffamily}\normalsize


Let $T_{ev2\rightarrow sg}$ be the transformation pathway consisting of
the above set of transformations,
$T_{ev2\rightarrow sg}$ in TML form is as follows:\\[0.1cm]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{eqnarray*}
& & [
\tml{t_{\overline{12}}}
      {c(C_{\overline{12}}) \ \cup \ c(Q_{\overline{12}})}
      {\phantom{\hspace{1.97cm}}\emptyset}
      {\{c(C_{\overline{12}}) - \{C_{\overline{12}}\}\} \ \cup
      \ c(Q_{\overline{12}})}
      {C_{\overline{12}}},
\tml{t_{\overline{11}}}
      {c(C_{\overline{11}}) \ \cup \ c(Q_{\overline{11}})}
      {\phantom{\hspace{1.97cm}}\emptyset}
      {\{c(C_{\overline{11}}) - \{C_{\overline{11}}\}\} \ \cup
      \ c(Q_{\overline{11}})}
      {C_{\overline{11}}},\\
& & \tml{t_{\overline{10}}}
      {c(C_{\overline{10}}) \ \cup \ c(Q_{\overline{10}})}
      {\phantom{\hspace{1.97cm}}\emptyset}
      {\{c(C_{\overline{10}}) - \{C_{\overline{10}}\}\} \ \cup
      \ c(Q_{\overline{10}})}
      {C_{\overline{10}}},
\tml{t_{6}}{\{c(C_6) - \{C_6\}\} \ \cup \ c(Q_6)}
      {\phantom{\hspace{2.7cm}}C_6}
      {c(C_6) \ \cup \ c(Q_6)}
      {\emptyset},\\ 
& & \tml{t_{7}}
      {\{c(C_7) - \{C_7\}\} \ \cup \ c(Q_7)}
      {\phantom{\hspace{2.7cm}}C_7}
      {c(C_7) \ \cup \ c(Q_7)}
      {\emptyset}, 
\tml{t_{8}}
      {\{c(C_8) - \{C_8\}\} \ \cup \ c(Q_8)}
      {\phantom{\hspace{2.7cm}}C_8}
      {c(C_8) \ \cup \ c(Q_8)}
      {\emptyset},\\ 
& & \tml{t_9}
      {c(C_9) \ \cup \ c(Q_9)}
      {\phantom{\hspace{1.72cm}}\emptyset}
      {\{c(C_9) - \{C_9\}\} \ \cup \ c(Q_9)}
      {C_9}
]\\
& = & [
\tml{t_{\overline{12}}}
      {\myhdms{w,p,d},\myhdms{p},\myhdms{d},\myhdms{p,dn}^+}
      {\phantom{\hspace{3.65cm}}\emptyset}
      {\myhdms{p},\myhdms{d},\myhdms{p,dn}^+}{\myhdms{w,p,d}^-},
\tml{t_{\overline{11}}}
      {\myhdms{d},\myhdms{d,dn},\myhdms{p,dn}^+}
      {\phantom{\hspace{2.85cm}}\emptyset}
      {\myhdms{d},\myhdms{p,dn}^+}
      {\myhdms{d,dn}^-},\\
& & \tml{t_{\overline{10}}}
      {\myhdms{d},\myhdms{p,dn}^+}
      {\phantom{\hspace{1.74cm}}\emptyset}
      {\myhdms{p,dn}^+}{\myhdms{d}^-},
\tml{t_{6}}{\myhdms{p,dn}^+}
      {\phantom{\hspace{0.38cm}}\myhdms{d}^-}
      {\myhdms{p,dn},\myhdms{d}^+}{\emptyset},
\tml{t_{7}}{\myhdms{d},\myhdms{p,dn}^+}
      {\phantom{\hspace{0.7cm}}\myhdms{d,dn}^-}
      {\myhdms{d},\myhdms{p,dn},\myhdms{d,dn}^+}{\emptyset},\\
& & \tml{t_{8}}{\myhdms{p},\myhdms{d},\myhdms{p,dn}^+}
      {\phantom{\hspace{1.31cm}}\myhdms{w,p,d}^-}
      {\myhdms{p},\myhdms{d},\myhdms{p,dn},\myhdms{w,p,d}^+}{\emptyset},
\tml{t_{9}}{\myhdms{p},\myhdms{p,dn},\myhdms{w,p,d}^+}
      {\phantom{\hspace{2.95cm}}\emptyset}
      {\myhdms{p},\myhdms{w,p,d}^+}{\myhdms{p,dn}^-}
]
\end{eqnarray*}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Transformations $t_{\overline{10}}$ and $t_6$
%(
%[$\ldots$,
%\tml{t_{\overline{10}}}{\myhdms{d},\myhdms{p,dn}^+}
%         {\phantom{\hspace{1.74cm}}\emptyset}
%         {\myhdms{p,dn}^+}{\myhdms{d}^-},
%\tml{t_{6}}{\myhdms{p,dn}^+}
%         {\phantom{\hspace{0.38cm}}\myhdms{d}^-}
%         {\myhdms{p,dn},\myhdms{d}^+}{\emptyset}, $\ldots$])
satisfy
the rules for the removal of redundant transformations, so we can
safely remove them from the list.  Similarly, $t_{\overline{11}}$ and
$t_7$
%([$\ldots$,
%\tml{t_{\overline{11}}}{\myhdms{d},\myhdms{d,dn},\myhdms{p,dn}^+}
%{\phantom{\hspace{2.85cm}}\emptyset}
%         {\myhdms{d},\myhdms{p,dn}^+}{\myhdms{d,dn}^-},
%\tml{t_{7}}{\myhdms{d},\myhdms{p,dn}^+}
%         {\phantom{\hspace{0.7cm}}\myhdms{d,dn}^-}
%         {\myhdms{d},\myhdms{p,dn},\myhdms{d,dn}^+}{\emptyset},
%$\ldots$]
%)
and $t_{\overline{12}}$ and $t_8$
%([$\ldots$,
%\tml{t_{\overline{12}}}
%         {\myhdms{w,p,d},\myhdms{p},\myhdms{d},\myhdms{p,dn}^+}
%         {\phantom{\hspace{3.65cm}}\emptyset}
%         {\myhdms{p},\myhdms{d},\myhdms{p,dn}^+}
%         {\myhdms{w,p,d}^-},
%\tml{t_{8}}{\myhdms{p},\myhdms{d},\myhdms{p,dn}^+}
%      {\phantom{\hspace{1.31cm}}\myhdms{w,p,d}^-}
%      {\myhdms{p},\myhdms{d},\myhdms{p,dn},\myhdms{w,p,d}^+}
%      {\emptyset},
%$\ldots$]
%)
can also be removed.
The result optimised pathway is [
$t_9$
%\tml{t_{9}}{\myhdms{p},\myhdms{p,dn},\myhdms{w,p,d}^+}
%         {\phantom{\hspace{2.95cm}}\emptyset}
%         {\myhdms{p},\myhdms{w}^+}{\myhdms{p,dn}^-}
].  Table~\ref{table:opt_ev2_sg} shows in detail the necessary
steps for such optimisation.


\small
\begin{stdtable}
{Steps for optimising transformation pathway $T_{ev2\rightarrow sg}$}
{table:opt_ev2_sg}

\begin{tabular}{ll}
\multicolumn{2}{>{\columncolor{header}}c}{Optimising $T_{ev2\rightarrow sg}$} \\%[0.3cm]
$T_{ev2\rightarrow sg}$
&
[
\tml{t_{\overline{12}}}
      {\myhdms{w,p,d},\myhdms{p},\myhdms{d},\myhdms{p,dn}^+}
      {\phantom{\hspace{3.65cm}}\emptyset}
      {\myhdms{p},\myhdms{d},\myhdms{p,dn}^+}{\myhdms{w,p,d}^-},
\tml{t_{\overline{11}}}{\myhdms{d},\myhdms{d,dn},\myhdms{p,dn}^+}
      {\phantom{\hspace{2.85cm}}\emptyset}
      {\myhdms{d},\myhdms{p,dn}^+}{\myhdms{d,dn}^-},\\
&
\tml{t_{\overline{10}}}{\myhdms{d},\myhdms{p,dn}^+}
      {\phantom{\hspace{1.74cm}}\emptyset}
      {\myhdms{p,dn}^+}{\myhdms{d}^-},
\tml{t_{6}}{\myhdms{p,dn}^+}
      {\phantom{\hspace{0.38cm}}\myhdms{d}^-}
      {\myhdms{p,dn},\myhdms{d}^+}{\emptyset},
\tml{t_{7}}{\myhdms{d},\myhdms{p,dn}^+}
      {\phantom{\hspace{0.7cm}}\myhdms{d,dn}^-}
      {\myhdms{d},\myhdms{p,dn},\myhdms{d,dn}^+}{\emptyset},\\
&
\tml{t_{8}}{\myhdms{p},\myhdms{d},\myhdms{p,dn}^+}
      {\phantom{\hspace{1.31cm}}\myhdms{w,p,d}^-}
      {\myhdms{p},\myhdms{d},\myhdms{p,dn},\myhdms{w,p,d}^+}
      {\emptyset},
\tml{t_{9}}{\myhdms{p},\myhdms{p,dn},\myhdms{w,p,d}^+}
      {\phantom{\hspace{2.95cm}}\emptyset}
      {\myhdms{p},\myhdms{w,p,d}^+}{\myhdms{p,dn}^-}
] \\
\rowcolor{evenrow}
Removing 
& \\
\rowcolor{evenrow}
$t_{\overline{10}}$ and $t_6$
&
\raisebox{1.5ex}[0pt]{
[$\ldots$,
\tml{t_{\overline{10}}}{\myhdms{d},\myhdms{p,dn}^+}
      {\phantom{\hspace{1.74cm}}\emptyset}
      {\myhdms{p,dn}^+}{\myhdms{d}^-},
\tml{t_{6}}{\myhdms{p,dn}^+}
      {\phantom{\hspace{0.38cm}}\myhdms{d}^-}
      {\myhdms{p,dn},\myhdms{d}^+}{\emptyset}, $\ldots$]
}
\\
$T_{ev2\rightarrow sg}'$
&
[
\tml{t_{\overline{12}}}
      {\myhdms{w,p,d},\myhdms{p},\myhdms{d},\myhdms{p,dn}^+}
      {\phantom{\hspace{3.65cm}}\emptyset}
      {\myhdms{p},\myhdms{d},\myhdms{p,dn}^+}{\myhdms{w,p,d}^-},
\tml{t_{\overline{11}}}
      {\myhdms{d},\myhdms{d,dn},\myhdms{p,dn}^+}
      {\phantom{\hspace{2.85cm}}\emptyset}
      {\myhdms{d},\myhdms{p,dn}^+}{\myhdms{d,dn}^-},\\
&
\tml{t_{7}}{\myhdms{d},\myhdms{p,dn}^+}
      {\phantom{\hspace{0.7cm}}\myhdms{d,dn}^-}
      {\myhdms{d},\myhdms{p,dn},\myhdms{d,dn}^+}{\emptyset},
\tml{t_{8}}{\myhdms{p},\myhdms{d},\myhdms{p,dn}^+}
      {\phantom{\hspace{1.31cm}}\myhdms{w,p,d}^-}
      {\myhdms{p},\myhdms{d},\myhdms{p,dn},\myhdms{w,p,d}^+}{\emptyset},\\
&
\tml{t_{9}}{\myhdms{p},\myhdms{p,dn},\myhdms{w,p,d}^+}
      {\phantom{\hspace{2.95cm}}\emptyset}
      {\myhdms{p},\myhdms{w,p,d}^+}{\myhdms{p,dn}^-}
] \\
\rowcolor{evenrow}
Removing 
& \\
\rowcolor{evenrow}
$t_{\overline{11}}$ and $t_7$
&
\raisebox{1.5ex}[0pt]{
[$\ldots$,
\tml{t_{\overline{11}}}{\myhdms{d},\myhdms{d,dn},\myhdms{p,dn}^+}
      {\phantom{\hspace{2.85cm}}\emptyset}
      {\myhdms{d},\myhdms{p,dn}^+}{\myhdms{d,dn}^-},
\tml{t_{7}}{\myhdms{d},\myhdms{p,dn}^+}
      {\phantom{\hspace{0.7cm}}\myhdms{d,dn}^-}
      {\myhdms{d},\myhdms{p,dn},\myhdms{d,dn}^+}
      {\emptyset}, $\ldots$]
}
\\
$T_{ev2\rightarrow sg}''$
&
[
\tml{t_{\overline{12}}}
      {\myhdms{w,p,d},\myhdms{p},\myhdms{d},\myhdms{p,dn}^+}
      {\phantom{\hspace{3.65cm}}\emptyset}
      {\myhdms{p},\myhdms{d},\myhdms{p,dn}^+}{\myhdms{w,p,d}^-},\\
&
\tml{t_{8}}{\myhdms{p},\myhdms{d},\myhdms{p,dn}^+}
      {\phantom{\hspace{1.31cm}}\myhdms{w,p,d}^-}
      {\myhdms{p},\myhdms{d},\myhdms{p,dn},\myhdms{w,p,d}^+}
      {\emptyset},
\tml{t_{9}}{\myhdms{p},\myhdms{p,dn},\myhdms{w,p,d}^+}
      {\phantom{\hspace{2.95cm}}\emptyset}
      {\myhdms{p},\myhdms{w,p,d}^+}{\myhdms{p,dn}^-}
] \\
\rowcolor{evenrow}
%Removing 
& \\
\rowcolor{evenrow}
%$t_{\overline{12}}$ and $t_8$
Removing
&
\raisebox{1.5ex}[0pt]{
[
\tml{t_{\overline{12}}}
      {\myhdms{w,p,d},\myhdms{p},\myhdms{d},\myhdms{p,dn}^+}
      {\phantom{\hspace{3.65cm}}\emptyset}
      {\myhdms{p},\myhdms{d},\myhdms{p,dn}^+}{\myhdms{w,p,d}^-},
}\\
\rowcolor{evenrow}
$t_{\overline{12}}$ and $t_8$
& \\
\rowcolor{evenrow}
&
\raisebox{1.5ex}[0pt]{
\tml{t_{8}}{\myhdms{p},\myhdms{d},\myhdms{p,dn}^+}
      {\phantom{\hspace{1.31cm}}\myhdms{w,p,d}^-}
      {\myhdms{p},\myhdms{d},\myhdms{p,dn},\myhdms{w,p,d}^+}
      {\emptyset}, $\ldots$]
}
\\
$T_{ev2\rightarrow sg}'''$
&
[\tml{t_{9}}{\myhdms{p},\myhdms{p,dn},\myhdms{w,p,d}^+}
      {\phantom{\hspace{2.95cm}}\emptyset}
      {\myhdms{p},\myhdms{w,p,d}^+}{\myhdms{p,dn}^-}] \\
\end{tabular}

\end{stdtable}

\normalsize


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% trying out \sideset

%
%\newcommand{\mysideset}[3]{%
%   \@mathmeasure\z@\displaystyle{#3}%
%   \global\setbox\@ne\vbox to\ht\z@{}\dp\@ne\dp\z@
%   \setbox\tw@\box\@ne
%   \@mathmeasure4\displaystyle{\copy\tw@#1}%
%   \@mathmeasure6\displaystyle{#3\nolimits#2}%
%   \dimen@-\wd6 \advance\dimen@\wd4 \advance\dimen@\wd\z@
%   \hbox to\dimen@{}\mathop{\kern-\dimen@\box4\box6}%
%}

%$\mysideset{_1^1}{_2^2}\prod$
%$\sideset{_1^1}{_2^2}{\mathop{t}}$

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


\section{Analysis of different transformation combinations}
\label{sec:tran_combo}

In this section, we will investigate all the possible combination
pairs of all the different kinds of transformations, and determine which
%of these transformation pairs are invalid, optimisable, or non-optimisable.
of these transformation pairs are invalid, redundant, or non-optimisable.
The query in the transformations are omitted in this section for
clarity and simplicity.

A transformation pair is \textbf{invalid} if it is not logically
correct when placed next to each other.  For example, the
combination of
\emph{add}(\texttt{A}) and
\emph{ext}(\texttt{A}) is invalid because a
construct cannot be extended to a schema that already contains the
%same construct.  A transformation pair is \textbf{optimisable}
same construct.  A transformation pair is \textbf{redundant}
if the net effect of the transformations in the combination is
$\emptyset$.
%, i.e., the transformations are redundant; or when the
%transformations can be simplified.
For example, the combination of
\emph{ext}(\texttt{A}) and
%\emph{con}(\texttt{A}) is optimisable because
\emph{con}(\texttt{A}) is redundant because
the effects of these transformations cancel out each other, i.e.,
they give an empty model ($\emptyset$).
%The combination of
%\emph{add}(\texttt{A}) and \emph{ren}(\texttt{A},\texttt{B})
%is also optimisable because the pair can be reduced to a single
%transformation \emph{add}(\texttt{B}) without the loss of
%correctness on the contents of the schema.
A transformation
pair is \textbf{non-optimisable} if no optimisation can be
done to it, no matter how the transformations are ordered.  For
example, the combination of
\emph{ren}(\texttt{A}, \texttt{B}) and
\emph{del}(\texttt{D}) is non-optimisable
because no matter how their order is rearranged, the net
effect of these transformations is still the same, so they
cannot be optimised to a simpler level.

The transformations we will be looking at are the five main
primitive transformations
\footnotesize\textsf{add(A)}\normalsize,
\footnotesize\textsf{del(A)}\normalsize,
\footnotesize\textsf{ext(A)}\normalsize,
\footnotesize\textsf{con(A)}\normalsize,
\footnotesize\textsf{rename(A,B)}\normalsize, and
\footnotesize\textsf{rename(B,A)}\normalsize,
plus the special transformations for the reps API
(Section~\ref{sec:automed_framework})
\footnotesize\textsf{id(A,B)}\normalsize \ and
\footnotesize\textsf{id(B,A)}\normalsize.

%use the rule on the
%well-formedness of a transformation pathway
%(Section~\ref{sec:rule_wellform}) to find out if the transformation
%pair is well-formed, assuming that the requirements for the contents
%of the initial schema are always satisfied.  So, bascially, we only
%compare the pre- and post-
%condtions of two transformations, if there exists any conflicts, i.e.,
%if any of the intersections of their pre- and post-conditions
%adjacent to each other do not evaluate to $\emptyset$.
%For example, given two transformations 
%\tml{t_i}{a_i^+}{b_i^-}{c_i^+}{d_i^-} and
%\tml{t_{i+1}}{a_{i+1}^+}{b_{i+1}^-}{c_{i+1}^+}{d_{i+1}^-},
%if $(c_{i}^+ \ \cap \ b_{i+1}^- \ \neq \ \emptyset)
%\vee (d_{i}^- \ \cap \ a_{i+1}^+ \ \neq \ \emptyset)$,
%then this transformation combination pair is invalid.
%Table~\ref{table:invalid_tran} shows all the invalid transformation
%combination pairs evaluated using this TML method.


%\newcolumntype{C}{>{\columncolor{header}}c}

%\begin{tabular}{*{2}{C}*{6}{c}}
%\multicolumn{2}{c}{} & \multicolumn{6}{C}{To } \\
%\rowcolor{header}
%\multicolumn{2}{c}{}
%              & $R_1$ & $R_2$ & $R_3$ & $R_4$ & $R_5$ & $R_6$  \\
%      & $R_1$ & 0   & 0   & 0   & 0   & 0   & 0   \\
%      & $R_2$ & 0   & 0   & 0   & 0   & 0   & 0   \\
%From  & $R_3$ & 0   & 0   & 0   & 0   & 0   & 0   \\
%      & $R_4$ & 0   & 0   & 0   & 0   & 0   & 0   \\
%      & $R_5$ & 0   & 0   & 0   & 0   & 0   & 0   \\
%      & $R_6$ & 0   & 0   & 0   & 0   & 0   & 0
%\end{tabular}


%\begin{table}
%\setlength{\extrarowheight}{4pt}
%\small
%\begin{center}
%\begin{tabular}{|c|c|c|c|c|c|}\hline
%
%& &
%\multicolumn{1}{|C|}{\scriptsize\textsf{add(A)}\small} &
%\multicolumn{1}{|C|}{\scriptsize\textsf{ext(A)}\small} &
%\multicolumn{1}{|C|}{\scriptsize\textsf{ren(B,A)}\small} &
%\multicolumn{1}{|C|}{\scriptsize\textsf{id(B,A)}\small}
%\\\cline{3-6}
%
%\raisebox{1.5ex}[0cm][0cm]{\scriptsize\textsf{add(A)}\small}&
%\raisebox{1.5ex}[0cm][0cm]{\tml{t}{C}{A}{AC}{\emptyset}}&
%\tml{t}{C}{A}{AC}{\emptyset} &
%\tml{t}{\emptyset}{A}{A}{\emptyset} &
%\tml{t}{B}{A}{A}{B} &
%\tml{t}{B}{A}{A}{B}
%\\\hline
%
%& &
%\multicolumn{1}{|C|}{\scriptsize\textsf{del(A)}\small} &
%\multicolumn{1}{|C|}{\scriptsize\textsf{con(A)}\small} &
%\multicolumn{1}{|C|}{\scriptsize\textsf{ren(A,B)}\small} &
%\multicolumn{1}{|C|}{\scriptsize\textsf{id(A,B)}\small}
%\\\cline{3-6}
%
%\raisebox{1.5ex}[0cm][0cm]{\scriptsize\textsf{del(A)}\small}&
%\raisebox{1.5ex}[0cm][0cm]{\tml{t}{AC}{\emptyset}{C}{A}}&
%\tml{t}{AC}{\emptyset}{C}{A} &
%\tml{t}{A}{\emptyset}{\emptyset}{A} &
%\tml{t}{A}{B}{B}{A} &
%\tml{t}{A}{B}{B}{A}
%\\\hline
%
%& &
%\multicolumn{1}{|C|}{\scriptsize\textsf{add(A)}\small} &
%\multicolumn{1}{|C|}{\scriptsize\textsf{ext(A)}\small} &
%\multicolumn{1}{|C|}{\scriptsize\textsf{ren(B,A)}\small} &
%\multicolumn{1}{|C|}{\scriptsize\textsf{id(B,A)}\small}
%\\\cline{3-6}
%
%\raisebox{1.5ex}[0cm][0cm]{\scriptsize\textsf{ext(A)}\small}&
%\raisebox{1.5ex}[0cm][0cm]{\tml{t}{\emptyset}{A}{A}{\emptyset}}&
%\tml{t}{C}{A}{AC}{\emptyset} &
%\tml{t}{\emptyset}{A}{A}{\emptyset} &
%\tml{t}{B}{A}{A}{B} &
%\tml{t}{B}{A}{A}{B}
%\\\hline
%
%& &
%\multicolumn{1}{|C|}{\scriptsize\textsf{del(A)}\small} &
%\multicolumn{1}{|C|}{\scriptsize\textsf{con(A)}\small} &
%\multicolumn{1}{|C|}{\scriptsize\textsf{ren(A,B)}\small} &
%\multicolumn{1}{|C|}{\scriptsize\textsf{id(A,B)}\small}
%\\\cline{3-6}
%
%\raisebox{1.5ex}[0cm][0cm]{\scriptsize\textsf{con(A)}\small}&
%\raisebox{1.5ex}[0cm][0cm]{\tml{t}{A}{\emptyset}{\emptyset}{A}}&
%\tml{t}{AC}{\emptyset}{C}{A} &
%\tml{t}{A}{\emptyset}{\emptyset}{A} &
%\tml{t}{A}{B}{B}{A} &
%\tml{t}{A}{B}{B}{A}
%\\\hline
%
%& &
%\multicolumn{1}{|C|}{\scriptsize\textsf{del(A)}\small} &
%\multicolumn{1}{|C|}{\scriptsize\textsf{con(A)}\small} &
%\multicolumn{1}{|C|}{\scriptsize\textsf{ren(A,B)}\small} &
%\multicolumn{1}{|C|}{\scriptsize\textsf{id(A,B)}\small}
%\\\cline{3-6}
%
%\raisebox{1.5ex}[0cm][0cm]{\scriptsize\textsf{ren(A,B)}\small}&
%\raisebox{1.5ex}[0cm][0cm]{\tml{t}{A}{B}{B}{A}}&
%\tml{t}{AC}{\emptyset}{C}{A} &
%\tml{t}{A}{\emptyset}{\emptyset}{A} &
%\tml{t}{A}{B}{B}{A} &
%\tml{t}{A}{B}{B}{A}
%\\\hline
%
%& &
%\multicolumn{1}{|C|}{\scriptsize\textsf{add(A)}\small} &
%\multicolumn{1}{|C|}{\scriptsize\textsf{ext(A)}\small} &
%\multicolumn{1}{|C|}{\scriptsize\textsf{ren(B,A)}\small} &
%\multicolumn{1}{|C|}{\scriptsize\textsf{id(B,A)}\small}
%\\\cline{3-6}
%
%\raisebox{1.5ex}[0cm][0cm]{\scriptsize\textsf{ren(B,A)}\small}&
%\raisebox{1.5ex}[0cm][0cm]{\tml{t}{B}{A}{A}{B}}&
%\tml{t}{C}{A}{AC}{\emptyset} &
%\tml{t}{\emptyset}{A}{A}{\emptyset} &
%\tml{t}{B}{A}{A}{B} &
%\tml{t}{B}{A}{A}{B}
%\\\hline
%
%& &
%\multicolumn{1}{|C|}{\scriptsize\textsf{del(A)}\small} &
%\multicolumn{1}{|C|}{\scriptsize\textsf{con(A)}\small} &
%\multicolumn{1}{|C|}{\scriptsize\textsf{ren(A,B)}\small} &
%\multicolumn{1}{|C|}{\scriptsize\textsf{id(A,B)}\small}
%\\\cline{3-6}
%
%\raisebox{1.5ex}[0cm][0cm]{\scriptsize\textsf{id(A,B)}\small}&
%\raisebox{1.5ex}[0cm][0cm]{\tml{t}{A}{B}{B}{A}}&
%\tml{t}{AC}{\emptyset}{C}{A} &
%\tml{t}{A}{\emptyset}{\emptyset}{A} &
%\tml{t}{A}{B}{B}{A} &
%\tml{t}{A}{B}{B}{A}
%\\\hline
%
%& &
%\multicolumn{1}{|C|}{\scriptsize\textsf{add(A)}\small} &
%\multicolumn{1}{|C|}{\scriptsize\textsf{ext(A)}\small} &
%\multicolumn{1}{|C|}{\scriptsize\textsf{ren(B,A)}\small} &
%\multicolumn{1}{|C|}{\scriptsize\textsf{id(B,A)}\small}
%\\\cline{3-6}
%
%\raisebox{1.5ex}[0cm][0cm]{\scriptsize\textsf{id(B,A)}\small}&
%\raisebox{1.5ex}[0cm][0cm]{\tml{t}{B}{A}{A}{B}}&
%\tml{t}{C}{A}{AC}{\emptyset} &
%\tml{t}{\emptyset}{A}{A}{\emptyset} &
%\tml{t}{B}{A}{A}{B} &
%\tml{t}{B}{A}{A}{B}
%\\\hline
%
%\end{tabular}
%\end{center}
%\caption{Invalid transformation combinations\label{table:invalid_tran}}
%\end{table}
%\normalsize
%\setlength{\extrarowheight}{0pt}

%Other combinations of transformations and their net effect are shown
%in Table~\ref{table:tranComb}.  Note that there are a few assumptions
%made when compiling the table:

Table~\ref{table:tranComb} shows all the possible combinations of
different transformations in pairs and their combined effect.  In
the table, \textbf{red} indicates that the transformation is pair
is redundant; \textbf{NoOp} indicates that the transformations are
non-optimisable; numbers indicate that the transformation pair is
invalid, the number is the rule number (Section~\ref{sec:op_rules})
violated by the transformations.  A few assumptions have been made
when compiling the table:

\begin{enumerate}
   \item    The table should be read in the way so that the
            transformations on the vertical axis preceeds the ones
            on the horizontal axis.  That is the order in which the
            transformations are supposed to be executed.
   \item    The constructs involved in the transformations, \texttt{A}
            and \texttt{B}, represent unique objects.  That is, the
            two occurrences of \texttt{A} in any pair of transformations
            indicate the \textbf{same} schema construct.
   \item    The query giving the extent of the transformation construct,
            if there is one, is omitted from the transformations for this
            analysis.  The queries of any pair of transformations, which
            involve the same construct, are assumed to be the same when
            their combined effect is analysed.
   \item    The construct \texttt{C} represents all the constructs
            referenced by \texttt{A} (and \texttt{B} if it is a construct
            in the transformation) and all the constructs appeared in
            the omitted query.
\end{enumerate}

%We have already mentioned in Section~\ref{sec:bg} the idea that
%transformations are reversible, e.g., for each \emph{add} \texttt{C},
%we may automatically derive \emph{del} \texttt{C}.  Intuitively, we can
%remove from a set of transformations a pair of transformations \emph{$t$}
%and \emph{$\overline{t}$}, provided that the construct in \emph{$t$} and
%\emph{$\overline{t}$} does not form part of the query expression of any
%other transformations inthe same set of transformations to which they
%belong, without affecting the result of applying the whole set of
%transformations.  A more detailed investigation of the possible
%combination of the different kinds of transformations reveals that
%there exist more transformation combinations that can be removed or
%optimised.  The result of this analysis is summarized in
%Table~\ref{table:tranComb}.  Note that there are a few assumptions made
%when compiling the table:


%The kinds of transformtions that produce similar effects, such as
%\footnotesize\textsf{add(A)}\normalsize and
%\footnotesize\textsf{ext(A)}\normalsize, will be grouped
%together when their effects in a transformation pair are discussed,
%i.e., the net effects of the transformation combinations
%\emph{add}(\texttt{A}) and \emph{del}(\texttt{A}), and
%\emph{ext}(\texttt{A}) and \emph{del}(\texttt{A}), will be discussed 
%in the same paragraph.  Examples and counter-examples will be used
%to illustrate the validity of the results in the table.  Note that
%the transformations in each combination are ordered.

%\newcolumntype{C}{>{\columncolor{header}}c}
\newcommand{\fc}[1]{\multicolumn{1}{>{\columncolor{evenrow}}c}{#1}}
\newcommand{\fcy}[1]{\multicolumn{1}{>{\columncolor{yellow}}c}{#1}}

\begin{center}
\begin{table}
%\footnotesize
\scriptsize
\begin{tabular}{@{}C@{}c@{}c@{}c@{}c@{}c@{}c@{}c@{}c@{}c@{}c@{}}%\cline{3-10}
\multicolumn{3}{c}{} &
\multicolumn{8}{C}{Second transformation}\\%\cline{3-10}

\multicolumn{3}{c}{} &
\fc{\emph{\textbf{add}}(\texttt{A})} & \fc{\emph{\textbf{del}}(\texttt{A})} &
\fc{\emph{\textbf{ext}}(\texttt{A})} & \fc{\emph{\textbf{con}}(\texttt{A})} &
\fc{\emph{\textbf{ren}}(\texttt{A,B})} & \fc{\emph{\textbf{ren}}(\texttt{B,A})} &
\fc{\emph{\textbf{id}}(\texttt{A,B})} & \fc{\emph{\textbf{id}}(\texttt{B,A})}\\

\multicolumn{3}{c}{} &
% add
\fc{\tml{t}{C^+}{A^-}{AC^+}{\emptyset}} &
% del
\fc{\tml{t}{AC^+}{\emptyset}{C^+}{A^-}} &
% ext
\fc{\tml{t}{C^+}{A^-}{AC^+}{\emptyset}} &
% con
\fc{\tml{t}{AC^+}{\emptyset}{C^+}{A^-}} &
% ren(A,B)
\fc{\tml{t}{AC^+}{B^-}{BC^+}{A^-}} &
% ren(B,A)
\fc{\tml{t}{BC^+}{A^-}{AC^+}{B^-}} &
% id(A,B)
\fc{\tml{t}{AC^+}{B^-}{BC^+}{A^-}} &
% id(B,A)
\fc{\tml{t}{BC^+}{A^-}{AC^+}{B^-}}\\

& \fc{\emph{\textbf{add}}(\texttt{A})} &
\fc{\tml{t}{C^+}{A^-}{AC^+}{\emptyset}} &
(1.1) & \fcy{red} & (1.1) &
%NoOp & \fcy{\emph{add}(\texttt{B})} & inv & \fcy{\emph{add}(\texttt{B})} &
NoOp & NoOp & (1.1) & NoOp &
(1.1)\\

& \fc{\emph{\textbf{del}}(\texttt{A})} &
\fc{\tml{t}{AC^+}{\emptyset}{C^+}{A^-}} &
\fcy{red} & (1.2) & NoOp &
(1.2) & (1.2) & NoOp & (1.2) & NoOp\\

& \fc{\emph{\textbf{ext}}(\texttt{A})} &
\fc{\tml{t}{C^+}{A^-}{AC^+}{\emptyset}} &
(1.1) & NoOp & (1.1) &
%\fcy{$\emptyset$} & \fcy{\emph{ext}(\texttt{B})} & inv &
%\fcy{\emph{ext}(\texttt{B})} & inv \\
\fcy{red} & NoOp & (1.1) &
NoOp & (1.1)\\

& \fc{\emph{\textbf{con}}(\texttt{A})} &
\fc{\tml{t}{AC^+}{\emptyset}{C^+}{A^-}} &
NoOp & (1.2) & \fcy{red} &
(1.2) & (1.2) & NoOp & (1.2) & NoOp\\

& \fc{\emph{\textbf{ren}}(\texttt{A,B})} &
\fc{\tml{t}{AC^+}{B^-}{BC^+}{A^-}} &
NoOp & (1.2) & NoOp &
(1.2) & (1.2) & \fcy{red} & (1.2) & \fcy{red}\\

& \fc{\emph{\textbf{ren}}(\texttt{B,A})} &
\fc{\tml{t}{BC^+}{A^-}{AC^+}{B^-}} &
(1.1) &
%\fcy{\emph{del}(\texttt{B})} & inv & \fcy{\emph{con}(\texttt{B})} &
NoOp & (1.1) & NoOp &
\fcy{red} & (1.1) & \fcy{red} & (1.1) \\

& \fc{\emph{\textbf{id}}(\texttt{A,B})} &
\fc{\tml{t}{AC^+}{B^-}{BC^+}{A^-}} &
NoOp & (1.2) & NoOp & (1.2) & (1.2) &
\fcy{red} & (1.2) & \fcy{red}\\

\raisebox{1ex}[0cm][0cm]{\begin{turn}{90}First transformation\end{turn}}
& \fc{\emph{\textbf{id}}(\texttt{B,A})} &
\fc{\tml{t}{BC^+}{A^-}{AC^+}{B^-}} &
(1.1) &
%\fcy{\emph{del}(\texttt{B})} & inv & \fcy{\emph{con}(\texttt{B})} &
NoOp & (1.1) & NoOp &
\fcy{red} & (1.1) & \fcy{red} & (1.1)\\%\hline

\end{tabular}
\normalsize
\caption{analysis of all possible combinations of different kinds of
transformations\label{table:tranComb}}
\end{table}
\end{center}

The results in Table~\ref{table:tranComb} are derived by applying
the optimisation rules discussed in Section~\ref{sec:op_rules},
using the TML notation of the transformations.
With the use of the TML and its rules on transformation optimisation,
it is easy to identify those transformation combinations that are
invalid or redundant.


\section{Future work}
\label{sec:future_work}

While the study of using techniques on database schema optimisation
as a way to increase the efficiency in the schema integration and
querying processes receives considerable
attention~\cite{Bom94, HP95, Pro97, BW92},
the study of optimisation focused soley on transformations is a
rather new topic.  It is our intention to develop our TML as a
general transformation manipulation language that can be used
by other schema transformation formalisms.  Generally speaking,
our TML is ready to be used by other schema transformation
languages, so long as these languages clearly indicate the
pre- and post-conditions of the transformation and the
associations between new and existing constructs.
The possibility of using TML with other transformation languages
described in~\cite{TS93, DK97, HP95} will be investigated.

The following points are recognized as directions for further
research:

\begin{enumerate}
   \item    The proof of the correctness of the TML optimisation rules
            by providing proofs of their soundness and completeness.
   \item    The implementation of internally representing transformations
            in TML notation and applying the optimisation rules in the
            AutoMed project.  Appropriate measures will be chosen to
            evaluate the performance of TML optimisation techniques.
   \item    The use of the strict interpretation for the \emph{ext} and
            \emph{con} transformations in optimisation.  Currently, the
            non-strict interpretation is adopted for these transformations,
            which means that \emph{add}(\texttt{A}) and
            \emph{con}(\texttt{A}) is a valid combination.  Under the
            strict interpretation, the same combination would be
            invalid.  The strict interpretation offers more restricted
            yet more logical semantics for transformations.
   \item    In this paper, the only optimisation detected by the set
            of optimisation rules is when two transformations are
            redundant.  However, there are other situations where
            transformations may also be optimised.  For example,
            \emph{add}(\texttt{A}), \emph{ren}(\texttt{A}, \texttt{B})
            may be simplified to \emph{add}(\texttt{B}).  Further
            investigation is required for finding the patterns
            occurred in TML when such optimisation is possible.
\end{enumerate}

%\newpage \appendix
%
%\input{repsSchema}

\bibliography{database}

\end{document}
