\documentclass[11pt,a4paper]{article}

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

\def\automed{\textsc{AutoMed}}
\title{The AutoMed Repositories and API\\[1em]
	\large AutoMed Technical Report 3, Version 3 (Draft)}
\author{Michael Boyd, Peter \mcbrien\ and Nerissa Tong\\
	\emph{\{mboyd,pjm,nnyt98\}@doc.ic.ac.uk}}

\begin{document}
\maketitle
\bibliographystyle{alpha}

\section{Introduction}
%%%%%%%%%%%%%%%%%%%%%%

This report describes the AutoMed \keyword{repositories API} which
provides a Java interface to a \keyword{persistant store} of
descriptions using the BAV approach \cite{MP03a} of data modelling
languages, schemas in those languages, and transformations between
those schemas. It is assumed that the reader is familiar with the BAV
approach. The repositories API has been used in developing data
integration tools in the AutoMed project, such as a graphical schema
transformation and intregation tool, schema improvement tool, data
migration and schema evolution tool, and the query processing,
optimisation and translation API.

The persistence in the repositories API is currently implemented by
storing the details of models, schemas and transformations in a
relational database. To permit the use of other persistent storage
mechanisms in the future, as illustrated in Figure~\ref{pic:api_arch},
the repositories API does not access the relational database directly,
but instead uses \keywordabbr{model definitions repository}{MDR},
\keywordabbr{schemas and transformations repository}{STR}, and
\keywordabbr{data source repository}{DSR}.  The details of these are
discussed in Section~\ref{persistent-store-sec}. The division
between MDR and STR is made so that several users of AutoMed may share
descriptions of modelling langauges held in a central MDR, whilst
maintaining individual stores of schemas and transformations in their
own STR repositories. Apart from this distinction, the user of the 
repositories API need not concern themselves with the API provided by
the STR, MDR and DSR, and it is intended that these APIs are only used
by the repositories API.

\begin{stdfigure}{Architecture of the AutoMed Repositories API}{pic:api_arch}

\stdpicmag{0}

\begin{picture}(25,30)
\putcolourbox(0,0)(25,30){PCAone}{}
\entity(7,17){Repository\\API}
\entity(2,9){MDR}
\entity(12,9){STR}
\pathvector(6,15)(6,13)
\path(6,15)(16,15)
\pathvector(16,15)(16,13)
\path(11,15)(11,17)
\entity(7,2){DSR}
\database(21,4){Rep\\DB}
\labbivector(15,4)(19,4){JDBC}{}
\pathvector(6,9)(9,6)
\pathvector(16,9)(13,6)
\pathvector(11,15)(11,6)
\entity(2,24){AutoMed\\GUI tools}
\entity(12,24){User\\Applications}
\pathvector(6,24)(9,21)
\pathvector(16,24)(13,21)
\end{picture}

\end{stdfigure}

To permit the use of a number of different modelling languages, the
AutoMed project defines the constructs of a higher-level modelling
languages in terms of a generic lower-level \keywordabbr{hypergraph
data model}{HDM} \cite{MP99a}. The MDR part of the
repository API achieves this using three key classes (illustrated in
Figure~\ref{rep-schema-fig}):

\begin{itemize}

\item Instances of the \textsf{Model} class are used to represent data
modelling languages, where each \textsf{Model} has a unique textual
\textsf{name} provided by the user and a numeric \textsf{SID} provided
by the repository. For example, a user may create a \textsf{Model}
named \textsf{er} and have assigned a \textsf{MID} of 1. Henceforth
the \textsf{Model} may be identified by either \textsf{name} or \textsf{MID}.

\item Instances of the \textsf{Construct} class are used to represent
constructs in a particular \textsf{Model}, where each
\textsf{Construct} has a textual \textsf{name} provided by the user
(which must be unique with respect to the \textsf{Model}) and a unique
numeric \textsf{cid} provided by the repository. For example,
a user may create \textsf{Construct}s named \textsf{entity}, \textsf{attribute}
and \textsf{relationship} and be assigned CIDs of 1,2 and 3.

\item Instances of the \textsf{Scheme} class are used to represent
elements of the \keyword{scheme} of a \textsf{Construct}, which
describes the details of the \textsf{Construct}. Each \textsf{Scheme}
may indicate the use of a string name, a reference to another
\textsf{Construct} or a constraint expression. For example, the
\textsf{entity} \textsf{Construct} might have a single string
\textsf{Scheme} used to hold its name, whilst the \textsf{attribute}
\textsf{Construct} might have first a reference \textsf{Scheme} pointing
at the \textsf{entity} \textsf{Construct}, followed by a string \textsf{Scheme}
for the name of the attribute, and a constraint \textsf{Scheme} for
the cardinality of the attribute.

\end{itemize}

\begin{stdfigure}{Repository Schema}{rep-schema-fig}

\stdpicmag{-4}
\footnotesize

\begin{picture}(46,30)(-1,-1)
\putcolourbox[bl,i](-1,-1)(30,19){PCAone}{\textbf{\textsf{\large MDR}}}
\putcolourbox[tr,i](-1,22)(46,19){PCBone}{\textbf{\textsf{\large STR}}}
\entity(20,0){Model}
\relationship(24,4)(24,12){}{0:N}{1:1}
\entity(20,12){Construct}
\relationship(8,14)(20,14){}{1:1}{1:N}
\entity(0,12){Scheme}
\relationship(24,16)(24,24){}{0:N}{1:1}
\entity(20,24){Schema\\Object}
\relationship(28,26)(40,26){}{0:N}{}
\path(40,26)(40,30)
\putbox[l,i](40,28)(0,2){~1:2}
\putbox[l,i](40,34)(0,2){~2:2}
\entity(36,30){Transforma\-\\tion}
\relationship(28,38)(40,38){}{0:N}{}
\path(40,38)(40,34)
\relationship(8,26)(20,26){}{1:1}{0:N}
\entity(0,24){Object\\Scheme}
\relationship(24,28)(24,36){}{1:N}{1:N}
\entity(20,36){Schema}
\relationship(8,38)(20,38){}{1:1}{0:N}
\entity(0,36){Access\\Method}
\end{picture}

\end{stdfigure}

Once a \textsf{Model} with appropriate \textsf{Construct}s has been
defined for a modelling language, any number of schemas may be defined
which use those constructs, and transformations may be described on
those schema. The STR part of the repository API
achieves this using five key classes (illustrated in
Figure~\ref{rep-schema-fig}):

\begin{itemize}

\item Instances of the \textsf{Schema} class represent a
\keyword{schema}, \ie a structuring of data. Schemas are
\textsf{extensional} if all the \textsf{SchemaObject}s of the schema
are stored in the repository, or \textsf{intensional} if the
\textsf{SchemaObject}s are derived by the application of one or more
\textsf{Transformation}s to an extensional \textsf{Schema}. Each
\textsf{Schema} has a unique textual \textsf{name} provided by the
user and a numeric \textsf{SID} provided by the repository. For
example, the user may supply the name \textsf{s1} and that might
receive an \textsf{SID} of 1.

\item Instances of the \textsf{SchemaObject} class are used to
describe the contents of a \textsf{Schema}, where each
\textsf{SchemaObject} has a scheme provided by the user
(which must be unique with respect to the \textsf{Model}) and a unique
numeric \textsf{obid} provided by the repository. For example,
a user may create \textsf{SchemaObjects}s with schemes \hdms{person},
and \hdms{person,id,key} and be assigned OBIDs of 1,2 and 3.

Each \textsf{SchemaObject} is also associated to a particular
\textsf{Construct}, and hence a data modelling language. Note that
this allows for a instance \textsf{Schema} to contain
\textsf{SchemaObjects} formed of constructs from more than one
modelling language, which is useful when transforming between schemas
in different modelling languages, since the intermidiate schemas
generated have \textsf{SchemaObjects} from both modelling languages.

\item The scheme of a \textsf{SchemaObject} are describe by instances
of the \textsf{ObjectScheme} class associated to the
\textsf{SchemaObject} instance. The repository API checks that they
conform with the instances of the \textsf{Scheme} class that are
associated with the \textsf{Construct} associated to the
\textsf{SchemaObject}.

\item Instances of the \textsf{Transformation} class link pairs of
\textsf{Schema} instances, and describe how that pair of schemas
differ from each other by the addition, subtraction or alteration of a
particular \textsf{SchemaObject}. A particular pair of schemas may
only have one transformation defined between them, and therefore 
each \textsf{Transformation} can be identified by a pair of \textsf{Schema}
instances. 

\item Instances of the \textsf{AccessMethod} describe how the
data of an extensional
schema is accessable from some external \keyword{data source},
in which case the \textsf{Schema} instance is denoted as being a
data source schema.

\end{itemize}


\begin{stdfigure}{A network of schemas}{schema-network-fig}

\stdpicmag{0}

\def\sname#1{\textsf{#1}}
\def\extschema(#1,#2)#3{\cschema(#1,#2){PCAtwo}{\sname{#3}}}
\def\intschema(#1,#2)#3{\cschema(#1,#2){PCAone}{\sname{#3}}}
\def\cschema(#1,#2)#3#4{\userx=#1%
\usery=#2%
\advance\userx -2%
\advance\usery -2%
\putcolourbox(\userx,\usery)(4,4){#3}{#4}}

\def\ctrans(#1,#2)(#3,#4){\Thicklines\ifnum#1<#3%
\userx=#1%
\advance\userx 2%
\usery=#3%
\advance\usery -2%
\labbivector(\userx,#2)(\usery,#4){}{}%
\else%
\userx=#2%
\advance\userx 2%
\usery=#4%
\advance\usery -2%
\labbivector(#1,\userx)(#3,\usery){}{}%
\fi}
\def\trans(#1,#2)(#3,#4){\ctrans(#1,#2)(#3,#4)}
\def\idtrans(#1,#2)(#3,#4){\textcolor{midgrey}{\ctrans(#1,#2)(#3,#4)}}

\begin{picture}(46,22)(-1,-1)
\putcolourbox[b,i](-1,-1)(46,6){lightgrey}{subnet \sname{s1}}
\putcolourbox[b,i](-1,7)(46,6){lightgrey}{subnet \sname{s2}}
\putcolourbox[b,i](-1,15)(46,6){lightgrey}{subnet \sname{s3}}
% s1
\extschema(2,2){s1}
\trans(2,2)(10,2)
\intschema(10,2){s1a}
\trans(10,2)(18,2)
\intschema(18,2){s1b}
\trans(18,2)(26,2)
\intschema(26,2){s1c}
\trans(26,2)(34,2)
\intschema(34,2){s1d}
\trans(34,2)(42,2)
\intschema(42,2){s1e}
\idtrans(42,2)(42,10)
% s2 
\extschema(2,10){s2}
\trans(2,10)(10,10)
\intschema(10,10){s2a}
\trans(10,10)(18,10)
\intschema(18,10){s2b}
\trans(18,10)(26,10)
\intschema(26,10){s2c}
\trans(26,10)(34,10)
\intschema(34,10){s2d}
\trans(34,10)(42,10)
\intschema(42,10){s2e}
\idtrans(42,10)(42,18)
% s3
\extschema(2,18){s3}
\trans(2,18)(10,18)
\intschema(10,18){s3a}
\trans(10,18)(18,18)
\intschema(18,18){s3b}
\trans(18,18)(26,18)
\intschema(26,18){s3c}
\trans(26,18)(34,18)
\intschema(34,18){s3d}
\trans(34,18)(42,18)
\intschema(42,18){s3e}
\end{picture}

\stdpicmag{-2}

\begin{picture}(65,5)
\extschema(2,2){} \putbox[l,i](5,2)(0,0){\shortstack[l]{extensional\\schema}}
\intschema(18,2){} \putbox[l,i](21,2)(0,0){\shortstack[l]{intensional\\schema}}
\trans(30,2)(38,2) \putbox[l,i](37,2)(0,0){\shortstack[l]{normal\\
transformation}}
\idtrans(48,2)(56,2) \putbox[l,i](55,2)(0,0){\shortstack[l]{ident\\
transformation}}
\end{picture}
\end{stdfigure}

\section{Describing Modelling Languages}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%e
To build a new modelling language in the \automed\ repository, we
must create a new instance of the \textsf{Model} class, giving the 
modelling language an appropriate name. For example, to create
an ER modelling language we might have the code:

\begin{codelist}
Model er=Model.createModel("er"); 
\end{codelist}

Using the approach from \cite{MP99a}, we may build a represenation
in the HDM of the constructs in our new modelling language.
This approach relies classifying the constructs of the modelling language
as follows:

\begin{itemize}

\item \keyword{nodal} constructs may be present in a model independent
of any other constructs.

\item \keyword{linking} constructs can only exist in a model when certain
other nodal constructs exist. 

\item \keyword{nodal-linking} constructs are nodal constructs that can only
exist when certain other nodal constructs exist, and that are linked to
these constructs.

\item \keyword{constraint} constructs are those which restrict the values
instances of the other three constructs may take.

\end{itemize}

The constraint classification may be applied in addition to any of the
other classification, \eg a construct may be either nodel-constraint
or plain nodal.  Viewing the ER model in Table~\ref{er-model-table},
the entity construct best matches the \keyword{nodal} classification.
In the repository, we define the such a nodel construct in the following
way:

\begin{codelist}
Construct entity=
er.createConstruct("entity",Construct.CLASS\_NODAL,true);
\end{codelist}

The third attribute of \textsf{createConstruct} being set to \textsf{true}
indicates that this construct one of the primitive constructs of the
modelling language being defined, as opposed to being something that can
only appear as part of some other construct.

If we choose to represent entities by the scheme \hdms{entity\_name},
then we can define the scheme of the \textsf{entity} construct as 
follows:

\begin{codelist}
entity.createConstructScheme(Scheme.TYPE\_NAME,null, true,
Scheme.HDM\_TYPE\_N1,1,1);
\end{codelist}

Each call to \textsf{createConstructScheme} creates one or more
possitions in a scheme of a constuct. The above call creates a string
name since the first attribute is set of \textsf{TYPE\_NAME}, and
which because the third parameter is set to \textsf{true}, that string
name key attribute of the scheme. The fourth parameter set to
\textsf{HDM\_TYPE\_N1} means that the string name applies to a node,
and the fifth and sixth parameters being \textsf{1,1} mean that
exactly one of these string names for nodes must appear in each
scheme.

The ER attribute construct fits most closely to the
\keyword{link-nodal} classification, since attributes take values, but
can only appear when linked to some entity. The defination of the
construct is very similar to that for entities, but the defintion of
the scheme is much more complex:

\begin{codelist}
Construct attribute=er.createConstruct("attribute",
Construct.CLASS\_LINK\_NODAL,true); \\
attribute.createConstructScheme(Scheme.TYPE\_CONSTRUCT,entity,true, \\
\>Scheme.HDM\_TYPE\_P1,1,1); \\
attribute.createConstructScheme(Scheme.TYPE\_NAME, null, true, \\
\>Scheme.HDM\_TYPE\_N1,1,1); \\
attribute.createConstructScheme(Scheme.TYPE\_NAME, null,false,  \\
\>Scheme.HDM\_TYPE\_C,1,1); \\
\end{codelist}

Here we have made the scheme comprise of three fields in the form
\hdms{entity\_name, attribute\_name, constraints}. The 
\textsf{entity\_name} deis fined as type \textsf{TYPE\_CONSTRUCT} to
indicate that it is a preexisting object in the schema, the second 
parameter being \textsf{entity}, which we have previously bound to be
the construct for ER entitie. The fourth parameter is \textsf{HDM\_TYPE\_P1}
to indicate that this is a preexisting HDM node.

The \textsf{attribute\_name} 

\begin{codelist}
Construct relationship=er.createConstruct("relationship", 
Construct.CLASS\_LINK,true); \\
relationship.createConstructScheme(Scheme.TYPE\_NAME, null, true,  \\
\> Scheme.HDM\_TYPE\_N1, 1,1); \\
relationship.createConstructScheme(Scheme.TYPE\_CONSTRUCT, entity, true,  \\
\> Scheme.HDM\_TYPE\_P1, 2,2); \\
relationship.createConstructScheme(Scheme.TYPE\_NAME, null,  true,  \\
\> Scheme.HDM\_TYPE\_C, 2,2); \\
\end{codelist}

\begin{codelist}
Construct generalisation=er.createConstruct("generalisation", 
Construct.CLASS\_CONSTRAINT,true); \\
generalisation.createConstructScheme(Scheme.TYPE\_NAME, null, true,  \\
\> Scheme.HDM\_TYPE\_C,1,1); \\
generalisation.createConstructScheme(Scheme.TYPE\_NAME, null, true,  \\
\>Scheme.HDM\_TYPE\_C,1,1); \\
generalisation.createConstructScheme(Scheme.TYPE\_CONSTRUCT,entity, true,  \\
\> Scheme.HDM\_TYPE\_C,1,1); \\
generalisation.createConstructScheme(Scheme.TYPE\_CONSTRUCT, entity, true,  \\
\> Scheme.HDM\_TYPE\_C,2,0); \\
\end{codelist}

\subsection{MDR Overview}
%%%%%%%%%%%%%%%%%%%%%%%%%

The MDR (Model Definitions Repository) stores descriptions of
modelling languages.  In essence, it comprises of a list of constructs
for each modelling language along with the arguments needed to create
an instance of each construct and the means by which to translate
instances of constructs into HDM.

Each argument needed to create an instance can be a simple name, a
reference to an existing object of a given construct type, a list of
alternatives or a sequence.  Each argument has a lower and upper
cardinality\footnote{An upper bound of infinitry is denoted by giving
an upper bound which is lower than the lower bound.} which specifies
how many times the name / construct / alternation / sequence can
appear (all occurances make up the one argument for the construct).

Each construct is given an HDM type which can be either nodal,
linkage, link-nodal, or constraint (which simply means there is no
corresponding HDM), see \cite{PM98} for details.  Each HDM type (and
therefore each construct) has a template with varaiables that the
arguments specified for instantiating the construct can be assigned
to.

A very simple example would be an ER entity and attribute.  An entity
would have a nodal HDM type and would have one construction argument
-- the entity's name.  An attribute would have an HDM type of
link-nodal (because it creates a node for the attribute but can only
exist in relation to an existing entity) and its two construction
arguments would be the name of the attribute and the existing entity
to which it should be linked\footnote{A more realistic example might
have cardinality arguments as well}.

\subsection{STR Overview}
%%%%%%%%%%%%%%%%%%%%%%%%%

The STR (Schemas and Transformations Repository) stores information
about schemas and transformation pathways between them.  A schema is a
list of objects and associated object schemes.  Each object is
identified as being an instance of a particular construct in the MDR.
The object references that make up an object's scheme directly relate
to the instantiation arguments in the MDR for the object's construct.

The first instantiation argument of type name (as opposed to a
reference to an existing construct, alternation or sequence) is given
special treatement.  This name is used as the name of the object and
the object reference for the argument in which the name appeared
references the object it instantiates.  If a construct has more than
one name in its arguments then extra objects are created to store
these values.  These extra objects have no construct type.  Other than
that, the result is the same as it would be if there was a construct
representing whatever was named and a reference to an instance of that
construct used instead of just its name in the argument list.

Schemas themselves have no inherent modelling language.  Instead, each
object, through its construct type, is of a particular modelling
language.  This means that transformation pathways that convert a
schema from one language to another can be defined because the
intermediatory schemas with some constructs from both languages can be
described.

Their are two types of schema wich are stored -- schemas of acutal data
sources (extensional data) and intermediatory schemas (intentional
data) that exist in transformation pathways between the schemas of
actual data sources.  These intermediatory schemas are usually
themselves intentional\footnote{Intentional with respect to the schema
as opposed to the data described by the schema}; that is, the schemas
can only be desribed by looking at another schema's extension and a
pathway of transformations between the two.  The intentional schemas
can be temporarily materialised (i.e. made extensional) and indeed
this automatically happens when the schema's description is asked for
so that these differences are, for the most part, transparent to tools
using the repositories.


% diagrams of s1 and s2
\begin{stdfigure}{Example ER schemas}{fig:example_er}

\stdpicmag{-2}
\begin{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
%\setlength{\unitlength}{1cm}
\begin{picture}(58,25)
\schema(3,0)(24,23){s1}{\entity(14,2){person}
\cardattribute(14,6)(8,7){sex}{1:1}{1:N}
\cardattribute(14,4)(6,4){name}{1:1}{1:N}
\cardattribute(14,2)(8,1){\underline{id}}{1:1}{1:1}
\relationship(18,6)(18,18){\tiny worksin}{1:1}{1:N}
\entity(14,18){dept}
\cardattribute(14,20)(8,20){\underline{dname}}{1:1}{1:1}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% s2
\schema(29,3)(32,18){s2}{\entity(12,13){person}
\entity(7,1){\texttt{male}}
\entity(17,1){\texttt{female}}
\generalisation(13,9){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{id}}{1:1}{1:1}
\cardattribute(12,16)(6,17){name}{1:1}{1:N}
\cardattribute(20,15)(26,15){dname}{1:1}{1:N}}
\end{picture}

\end{small}
\end{stdfigure}

\section{The AutoMed Repositories API}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\label{sec:repAPI}

The repositories API 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 extensional schemas.  An ER diagram of how
these entities are related to each other is given in
Appendix~\ref{automed-rep-fig}.  The repositories API comprises of Java
classes representing each of these entities, all the methods for
manipulating the repositories are in these classes.

\begin{stdfigure}{Overview of the AutoMed Repository}{oldautomed-rep-fig}

\stdpicmag{-4}
\footnotesize

\begin{picture}(50,48)(-1,0)
\putcolourbox[bl,i](-1,-1)(30,23){PCAone}{\textbf{\textsf{\large MDR}}}
\putcolourbox[tl,i](-1,30)(50,23){PCBone}{\textbf{\textsf{\large STR}}}
\entity(20,0){Model}
\relationship(24,4)(24,16){}{0:N}{1:1}
\entity(20,16){Construct}
\relationship(8,18)(20,18){}{1:1}{0:N}
\entity(0,16){Scheme}
\relationship(24,20)(24,32){}{0:N}{1:1}
\entity(20,32){Schema\\Object}
\relationship(28,34)(44,34){}{0:N}{}
\path(44,34)(44,40)
\putbox[l,i](44,38)(0,2){~2:2}
\putbox[l,i](44,44)(0,2){~2:2}
\entity(40,40){Transforma\-\\tion}
\relationship(28,50)(44,50){}{0:N}{}
\path(44,50)(44,44)
\relationship(8,34)(20,34){}{1:1}{0:N}
\entity(0,32){Object\\Scheme}
\relationship(24,36)(24,48){}{1:1}{0:N}
\entity(20,48){Schema}
\end{picture}

\end{stdfigure}

The two major classes that will be created directly by the (AutoMed) tool
are the \textsf{Model} class (from the MDR) and the \textsf{Schema} class
(from the STR).  The classes we have created (partially) so far 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 are
included in Section~\ref{sec:mdr_classes} and Section~\ref{sec:str_classes}
respectively.

\subsection{Classes related to the MDR}
\label{sec:mdr_classes}

The \texttt{Model} class represents data models.  The argument required for
creating a \texttt{Model} object is the \texttt{name} of the model.  For
example, the following line creates a \texttt{Model} named \texttt{ER}:

\texttt{Model myER = new Model(``ER'');}

To create \texttt{Constructs} for the \texttt{Model}, a method is provided
in the \texttt{Model} class.  For example, to create an entity for the
\texttt{myER} model, we do the following:

\begin{verbatim}
Construct myEREnt = myER.createConstruct(``Entity'',
                                   Construct.CONSTRUCT_CLASS_NODAL,
                                   true);
\end{verbatim}

The first argument of the \texttt{createConstruct} methods takes a
\texttt{String} value which represents the name of the \texttt{Construct}.
The second argument is a constant integer indicating the class of the
construct, its value must be \texttt{Construct.CONSTRUCT\_CLASS\_\$}, where
\texttt{\$} is one of \texttt{NODAL}, \texttt{LINK}, \texttt{LINK\_NODAL},
and \texttt{CONSTRAINT}.  The third argument accepts a \texttt{boolean}
value.  It is set to \texttt{true} if the construct is indeed a construct
in the model (the \textbf{isRoot} field in the \emph{Construct} table of
the MDR) and set to \texttt{false} otherwise.  A model identifier
(\textbf{mid}) is created upon creation of a \texttt{Model} object and a
unique construct identifier (\textbf{cid}) is created for each
\texttt{Construct} object.  To fill the \emph{construct} table in the MDR, 
the value for the field \textbf{mid} is implied by the calling
\texttt{Model} object that calls the \texttt{createConstruct} method.

We now need to fill the \emph{scheme} table of the MDR for the construct
we have created.  The method \texttt{createSchemePos} in the
\texttt{Construct} class allows us to do so.

\begin{verbatim}
myEREnt.createSchemePos(SchemePos.SCHEME_TYPE_NAME,
                        null,
                        true,
                        SCHEME_HDM_TYPE_N1,
                        1, 1);
\end{verbatim}

The \texttt{createSchemePos} method does not return a value.  The
first argument takes the value \texttt{SchemePos.SCHEME\_TYPE\_\$},
where \texttt{\$} is one of \texttt{NAME}, \texttt{CONSTRUCT},
\texttt{ALTERNATION}, and \texttt{SEQUENCE}.  The second argument is
always \texttt{null} if the SCHEME\_TYPE is \texttt{NAME}.  It is of
type \texttt{Construct} if the SCHEME\_TYPE is \texttt{CONSTRUCT}.  We
have not yet arrived at a decision as to what the treatment should be
for the other two SCHEME\_TYPES.  The third argument refers to the
\textbf{isKey} field of the \emph{scheme} table in the MDR.  The
fourth argument indicates the corresponding HDM type in the HDM
template.  Its value is \texttt{SchemePos.SCHEME\_HDM\_TYPE\_\$},
where \texttt{\$} is one of \texttt{N1}, \texttt{N2}, \texttt{P1},
\texttt{P2}, and \texttt{C}.  The last two arguments refer to the
\textbf{lower} and \textbf{upper} fields in the \emph{scheme} table,
and control the cardinality of the attribute (i.e. how many times the
attribute may be repeated). If $\textbf{upper}<\textbf{lower}$ then
the attribute may be repeated an unlimited number of times.

The fragments of code together provide the MDR complete information for
the ER entity construct.  Table~\ref{table:mdr_er} shows the state of the
MDR after the execution of the code fragments.  An ER attribute can be
created in a similar fashion.  Table~\ref{table:mdr_all} shows the state
of the MDR after the attribute construct has also been created.

\begin{verbatim}
/*.......................... code fragment for ER Attribute ...*/
Construct myERAtt = myER.createConstruct(``Attribute'',
                            Construct.CONSTRUCT_CLASS_LINK_NODAL,
                            true);

myERAtt.createSchemePos(SchemePos.SCHEME_TYPE_CONSTRUCT,
                        myEREnt,
                        true,
                        SCHEME_HDM_TYPE_P1,
                        1, 1);

myERAtt.createSchemePos(SchemePos.SCHEME_TYPE_NAME,
                        null,
                        true,
                        SCHEME_HDM_TYPE_N2,
                        1, 1);
/*....................... end of code fragment ER Attribute ...*/

\end{verbatim}

\begin{stdtable}{MDR (ER entity created)}{table:mdr_er}
\subtable[]{
\begin{tabular}{ll}
\multicolumn{2}{>{\columncolor{tablename}}c}{model} \\
\rowcolor{columnname}
\underline{mid} & name \\
1 & ER \\
\end{tabular}}
\hspace{1em}
\subtable[]{
\begin{tabular}{lllll}
\multicolumn{5}{>{\columncolor{tablename}}c}{construct} \\
\rowcolor{columnname}
mid & \underline{cid} & name & class & isRoot \\
1 & 1 & Entity & NODAL & true \\
\end{tabular}}

\subtable[]{
\begin{tabular}{llllllllll}
\multicolumn{10}{>{\columncolor{tablename}}c}{scheme} \\
\rowcolor{columnname}
mid & \underline{cid} & \underline{pos} & type & argMid & argCid & isKey
& HdmType & lower & upper \\
1 & 1 & 1 & NAME & - & - & true & N1 & 1 & 1 \\
\end{tabular}}
\end{stdtable}


\begin{stdtable}{MDR (ER entity \& attribute created)}{table:mdr_all}
\subtable[]{
\begin{tabular}{ll}
\multicolumn{2}{>{\columncolor{tablename}}c}{model} \\
\rowcolor{columnname}
\underline{mid} & name \\
1 & ER \\
\end{tabular}}
\hspace{1em}
\subtable[]{
\begin{tabular}{lllll}
\multicolumn{5}{>{\columncolor{tablename}}c}{construct} \\
\rowcolor{columnname}
mid & \underline{cid} & name & class & isRoot \\
1 & 1 & Entity & NODAL & true \\
1 & 2 & Attribute & LINK-NODAL & true \\
\end{tabular}}

\subtable[]{
\begin{tabular}{llllllllll}
\multicolumn{10}{>{\columncolor{tablename}}c}{scheme} \\
\rowcolor{columnname}
mid & \underline{cid} & \underline{pos} & type & argMid & argCid & isKey
& HdmType & lower & upper \\
1 & 1 & 1 & NAME & - & - & true & N1 & 1 & 1 \\
1 & 2 & 1 & CONSTRUCT & 1 & 1 & true & P1 & 1 & 1 \\
1 & 2 & 2 & NAME & - & - & true & N2 & 1 & 1 \\
\end{tabular}}
\end{stdtable}


\subsection{Classes related to the STR}
\label{sec:str_classes}

The \texttt{Schema} class represents schemas.  A \texttt{Schema} object
is created by calling the \texttt{Schema} class constructor with the
value for the name of the schema (of type \texttt{String}) and three
\texttt{boolean} values indicating whether or not the schame is an
extentional schema, an extentional database, and a data source.  The
following is an example creating a schema named \texttt{mySchema}.

\texttt{Schema mySchema = new Schema(``s1'', true, true, true);}

Schema objects are added to the schema by calling the
\texttt{createSchemaObject} method of the \texttt{Schema} class.
The following code fragment creates an entity and an attribute for
\texttt{mySchema}.

\begin{verbatim}
SchemaObject myEntity1 = mySchema.createSchemaObject(myEREnt,
                                          new Object[] {``E1''});
SchemaObject myAttribute = mySchema.createSchemaObject(myERAtt,
                               new Object[] {``A1'', myEntity1});
\end{verbatim}

The first argument of the \texttt{createSchemaObject} method takes
an object reference of type \texttt{Construct}, which indicates the type of
construct to which the schema object being created belongs.  The
second argument is an \texttt{Object} array that accepts values of
either of type \texttt{String} or \texttt{SchemaObject}.  Only one
\texttt{String} value is allowed in the \texttt{Object} array.  This
\texttt{String} corresponds to the \textbf{value} field in the
\emph{schema\_objects} table in the STR.  An \texttt{ObjectScheme}
object is automatically created for each \texttt{SchemaObject}
object by taking the \texttt{Object} array argument.  In the creation
of each \texttt{ObjectScheme} object, the type of the elements in the
\texttt{Object} array are verified against the data in the
\textbf{scheme} table in the MDR.  Data entries are made in the
\emph{object\_schemes} table in the STR according to the order in which
the elements in the \texttt{Object} array are declared.  The result
produced by the fragments of code is shown in Table~\ref{table:str}.


\begin{stdtable}{STR (Schema with ER entity \& attribute created)}
{table:str}
\subtable[]{
\begin{tabular}{llllll}
\multicolumn{6}{>{\columncolor{tablename}}c}{schemas} \\
\rowcolor{columnname}
\underline{sid} & name & es & edb & data\_source & is\_cached \\
1 & s1 & 1 & 1 & 1 & 0 \\
\end{tabular}}

\subtable[]{
\begin{tabular}{llllll}
\multicolumn{6}{>{\columncolor{tablename}}c}{schema\_objects} \\
\rowcolor{columnname}
sid & mid & cid & \underline{obid} & value & is\_temp \\
1 & 1 & 1 & 1 & E1 & 0 \\
1 & 1 & 2 & 2 & A1 & 0 \\
\end{tabular}}
\hspace{1em}
\subtable[]{
\begin{tabular}{lll}
\multicolumn{3}{>{\columncolor{tablename}}c}{object\_schemes} \\
\rowcolor{columnname}
\underline{obid} & \underline{scheme\_pos} & sobid \\
1 & 1 & 1 \\
2 & 1 & 1 \\
2 & 2 & 2 \\
\end{tabular}}
\end{stdtable}

\section{Persistent Store}
%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{persistent-store-sec}

Figure~\ref{rep-schema} illustrates the ER model of the MDR and STR.

\begin{stdfigure}{Repository Schema}{rep-schema}

\stdpicmag{-3}
\footnotesize

\begin{picture}(66,68)
\entity(30,0){model}
\keyattribute(30,3)(26,4){mid}
\attribute(30,1)(26,0){model}
\relationship(34,4)(34,16){mid}{0:N}{1:1}
\entity(30,16){construct}
\keyattribute(38,19)(42,20){cid}
\attribute(38,17)(42,16){construct}
\relationship(18,18)(30,18){\underline{cid}}{1:1}{0:N}
\entity(10,16){scheme}
\keyattribute(10,20)(6,22){pos}
\attribute(10,19)(6,20){type}
\nullattribute(10,18)(6,18){argMid}
\nullattribute(10,17)(6,16){argCid}
\attribute(10,16)(6,14){HDMType}
\attribute(12,16)(11,12){lower}
\attribute(16,16)(17,12){upper}
\attribute(14,20)(14,24){isKey}
\relationship(34,20)(34,32){cid}{0:N}{1:1}
\entity(30,32){schema\\object}
\keyattribute(31,32)(30,29){obid}
\attribute(31,36)(30,39){value}
\attribute(37,36)(38,39){is\_temp}
\relationship(38,32)(57,32){from\\obj}{0:N}{0:1}
\path(57,32)(57,40)
\relationship(38,36)(51,36){to\\obj}{0:N}{0:1}
\path(51,36)(51,40)
\entity(50,40){transforma\-\\tion}
\attribute(58,43)(62,44){action}
\nullattribute(58,42)(62,42){function}
\nullattribute(58,41)(62,40){cons}
\relationship(38,52)(57,52){from\\schema}{0:N}{1:1}
\path(57,52)(57,44)
\relationship(38,48)(51,48){to\\schema}{0:N}{1:1}
\path(51,48)(51,44)
\relationship(18,34)(30,34){\underline{obid}}{1:1}{0:N}
\entity(10,32){object\\scheme}
\keyattribute(10,35)(6,36){scheme\_pos}
\attribute(10,33)(6,32){sobid}
\relationship(34,36)(34,48){\underline{oid}}{1:1}{0:N}
\entity(30,48){schema}
\isa(27,50)(30,50)
\generalisation(21,49){es}
\path(18,50)(21,50)
\entity(10,48){extensional\\schema}
\isa(14,57)(14,52)
\generalisation(11,57){edb}
\path(14,64)(14,59)
\entity(10,64){extensional\\database}
\isa(21,66)(18,66)
\generalisation(21,65){\shortstack{data\\source}}
\path(27,66)(30,66)
\entity(30,64){data\\source}
\relationship(38,66)(50,66){sid}{0:N}{1:1}
\entity(50,64){access\\method}
\keyattribute(58,68)(62,70){amid}
\attribute(58,67)(62,68){url}
%\attribute(58,66)(62,66){pid}
\attribute(58,65)(62,64){db\_driver}
\attribute(58,64)(62,62){username}
\entity(30,56){protocol}
\keyattribute(30,59)(26,60){pid}
\attribute(30,57)(26,56){name}
\relationship(38,58)(52,58){pid}{0:N}{1:1}
\path(52,58)(52,64)
\end{picture}

\end{stdfigure}

\subsection{The STR Repository}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{sec:str}

The STR is made up of six tables, they are the \texttt{schema} table,
the \texttt{object} table, the \texttt{scheme} table, the
\texttt{transformation} table, the \texttt{accessMethod} table, and
the \texttt{protocol} table.

\subsubsection{The \texttt{schema} table}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{sec:schema}

% the schemas table
% caption for table???
\begin{center}
\begin{tabular}{|ll|}\hline
\multicolumn{2}{|c|}{\textbf{schema}}\\\hline\hline
\underline{SID} & integer\\
name & varchar\\ extSchema & integer\\ extDB & integer\\ dataSource &
integer\\ isCached & integer\\\hline
\end{tabular}
\end{center}

\vspace{0.3cm}

Each schema entered into the repository is assigned a schema ID
(\texttt{SID}) which uniquely identifies itself in the table.  Schemas
are assumed to have unique names.  Information about the nature of the
schemas is also recorded -- whether a schema is an extensional schema
(\texttt{extSchema}), whether it is an extensional database
(\texttt{extDB}), and whether it is a data source (\texttt{dataSource}).
An extentional schema is one which physically exists, whereas an intentional
schema is one which is computed or derived from some other extentional or
intentional schema(s).  An extentional database is one with instances of
the schema objects stored.  An intentional database has its schema object
instances derived from an extiontional database when they are required to
be materialized.  A data source refers to an actual external data repository.
Data sources whose schemas and objects are materialized and stored
locally are not considered to be data sources.  The \texttt{isCached}
field is a special field indicating whether or not a schema's objects
have been materialized and temporarily stored in the STR.  This field
is designed to be used only by the interface above this layer.


Figure~\ref{fig:example_er} shows two example ER schemas \texttt{s1} and
\texttt{s2}.  The following table shows how these two schemas are stored
in the \texttt{schema} table.

\vspace{0.3cm}

% show how these two schemas are stored into the schemas table
% the schemas table with 2 schemas
\begin{center}
\begin{tabular}{lrrrrr}
\multicolumn{6}{>{\columncolor{tablename}}c}{schema} \\
\rowcolor{columnname}
\underline{SID} & name & extSchema & extDB & dataSource & isCached \\
1 & s1 & 1 & 1 & 1 & 0 \\
2 & s2 & 1 & 1 & 1 & 0 \\
\end{tabular}
\end{center}


\subsubsection{The \texttt{object} table}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{sec:object}

% the schemas_objects table
\begin{center}
\begin{tabular}{|ll|}\hline
\multicolumn{2}{|c|}{\textbf{object}}\\\hline \hline
SID & integer\\
MID & integer\\
CID & integer\\
\underline{OBID} & integer\\
value & varchar\\
isTemp & integer\\\hline
\end{tabular}
\end{center}

\vspace{0.3cm}

The \texttt{object} table stores information about each
object (or construct) in a schema.  Each object is given a unique
object identifier (\texttt{OBID}).  The \texttt{MID} (model ID)
and \texttt{CID} (construct ID) fields indicate the modelling
language used and the type of construct the object belongs to
in this modelling language.  The \texttt{SID} field records to
which schema a particualr object belongs and the \texttt{value}
field stores the name (or simply value for constraints) of the
object.  The \texttt{isTemp} field is a special field that
will be used by the inteface at a higher level.  It is set to
\texttt{true} (1) when an object of an intentional schema is
materialized, i.e., when the object is copied from the schema
from which the intentional schema is derived.

Assume we have the following two tables that define the
model identifier and construct identifier for each model:

\stdpicmag{-2}
\begin{small}

\begin{picture}(20, 22)
\put(13,11){
\begin{tabular}{ll}
\multicolumn{2}{>{\columncolor{tablename}}c}{model} \\
\rowcolor{columnname}
\underline{MID} & model \\
1 & relational \\
2 & ER \\
3 & ER+ \\
4 & UML \\
\end{tabular}}
\put(33,11){
\begin{tabular}{lll}
\multicolumn{3}{>{\columncolor{tablename}}c}{construct} \\
\rowcolor{columnname}
\underline{MID} & \underline{CID} & construct \\
1 & 1 & relation \\
1 & 2 & attribute \\
1 & 3 & func. dep. \\
2 & 1 & entity \\
2 & 2 & attribute \\
2 & 3 & relationship \\
2 & 4 & generalisation \\
2 & 5 & constraint \\
\multicolumn{3}{c}{\vdots}\\
\end{tabular}}
\end{picture}

\end{small}

The following table shows how the objects of the two schemas
\texttt{s1} and \texttt{s2} are stored in the
\texttt{object} table (omitting cardinality constraints
for attributes).

\vspace{0.3cm}

% show how the objects from s1 and s2 are stored in the schema_objects
% table
\begin{small}

\begin{center}
\begin{tabular}{lrrrrr}
\multicolumn{6}{>{\columncolor{tablename}}c}{object} \\
\rowcolor{columnname}
SID & MID & CID & \underline{OBID} & value & isTemp \\
1 & 2 & 1 & 1 & person & 0 \\
1 & 2 & 1 & 2 & dept & 0 \\
1 & 2 & 2 & 3 & id & 0 \\
1 & 2 & 2 & 4 & name & 0 \\
1 & 2 & 2 & 5 & sex & 0 \\
1 & 2 & 2 & 6 & dname & 0 \\
1 & 2 & 3 & 7 & worksin & 0 \\
1 & 2 & 5 & 8 & 1:1 & 0 \\
1 & 2 & 5 & 9 & 1:N & 0 \\
2 & 2 & 1 & 10 & person & 0 \\
2 & 2 & 1 & 11 & male & 0 \\
2 & 2 & 1 & 12 & female & 0 \\
2 & 2 & 2 & 13 & id & 0 \\
2 & 2 & 2 & 14 & name & 0 \\
2 & 2 & 2 & 15 & dname & 0 \\
2 & 2 & 4 & 16 & sex & 0 \\
2 & 2 & 5 & 17 & total & 0 \\
\end{tabular}
\end{center}

\end{small}


\subsubsection{The \texttt{scheme} table}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{sec:scheme}

% the object_schemes table
\begin{center}
\begin{tabular}{|ll|}\hline
\multicolumn{2}{|c|}{\textbf{scheme}}\\\hline \hline
\underline{OBID} & integer\\
\underline{schemePos} & integer\\
SOBID & integer\\\hline
\end{tabular}
\end{center}

\vspace{0.3cm}

The \texttt{object} table records details about each objects
individually, however, it does not provide information about the
linkage between different objects in the schema.  The
\texttt{scheme} table is designed to hold this information.
Every construct in each of the models has a \textbf{scheme}.  The
definition of what the scheme should be for each construct is
stored in the MDR.  The following shows four
example schemes for the ER model.

\vspace{0.3cm}

\begin{center}
\begin{tabular}{ll}
\multicolumn{2}{>{\columncolor{tablename}}c}{Schemes for ER constructs} \\
\rowcolor{columnname}
construct & scheme \\
entity & \texttt{$\hdms{E}$} \\
attribute & \texttt{$\hdms{E, A}$} \\
relationship & \texttt{$\hdms{R, E_1, E_2, C_1, C_2}$} \\
generalisation & \texttt{$\hdms{G, T, E, S_1, ..., S_n}$} \\
\end{tabular}
\end{center}

\vspace{0.3cm}

The scheme of an entity contains only the entity itself.  An attribute has
the entity with which it is associated in its scheme, followed by itself.
The scheme of a (binary) relationship contains the relationship as the
first argument, followed by the (two) entities connected by the
relationship, and their associted cardinality constraints for the
relationship.  The size (number of arguments) of the scheme for a
generalisation is not fixed.  It is dependent on the number of
sub-entities in the generalisation.  The first argument in the
generalisation scheme is the generalisation itself, followed by the type
of the generalisation (either partial or total), the super-entity and
a number of sub-entities.

The \texttt{scheme} table records the content of each position
of the scheme of a particular schema object.  The \texttt{OBID} field
refers to the schema object whose scheme content is stored in the row.
The \texttt{schemePos} field indicates which position in the scheme
\texttt{SOBID}, which is another schema object, is located.  The
following table shows how the \texttt{scheme} table of the two
schemas \texttt{s1} and \texttt{s2} are filled.


% show how these object_schemems are stored into the object_schemes
% table for the objects from s1 and s2
\begin{small}

\begin{picture}(20,32)
\put(8,15){
\begin{tabular}{lrr}
\multicolumn{3}{>{\columncolor{tablename}}c}{scheme} \\
\rowcolor{columnname}
\underline{OBID} & \underline{schemePos} & SOBID \\
1 & 1 & 1 \\
2 & 1 & 2 \\
3 & 1 & 1 \\
3 & 2 & 3 \\
4 & 1 & 1 \\
4 & 2 & 4 \\
5 & 1 & 1 \\
5 & 2 & 5 \\
6 & 1 & 2 \\
6 & 2 & 6 \\
7 & 1 & 7 \\
7 & 2 & 1 \\
7 & 3 & 2 \\
7 & 4 & 8 \\
7 & 5 & 9 \\
\end{tabular}}

\put(37,16){
\begin{tabular}{lrr}
\multicolumn{3}{>{\columncolor{tablename}}c}{scheme (cont'd)} \\
\rowcolor{columnname}
\underline{OBID} & \underline{schemePos} & SOBID \\
10 & 1 & 10 \\
11 & 1 & 11 \\
12 & 1 & 12 \\
13 & 1 & 10 \\
13 & 2 & 13 \\
14 & 1 & 10 \\
14 & 2 & 14 \\
15 & 1 & 10 \\
15 & 2 & 15 \\
16 & 1 & 16 \\
16 & 2 & 17 \\
16 & 3 & 10 \\
16 & 4 & 11 \\
16 & 5 & 12 \\
\end{tabular}}
\end{picture}

\end{small}


\subsubsection{The \texttt{transformation} table}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{sec:transformation}

% the transformations table
\begin{center}
\begin{tabular}{|ll|}\hline
\multicolumn{2}{|c|}{\textbf{transformation}}\\\hline \hline
action & varchar\\
fromObj & integer\\
toObj & integer\\
\underline{fromSchema} & integer\\
\underline{toSchema} & integer\\
function & varchar\\
cons & varchar\\\hline
\end{tabular}
\end{center}

\vspace{0.3cm}

An intentional schema is formed by transforming an extentional schema,
or another intermediate intentional schema.  Transformations between
schemas are specified in the \texttt{transformation} table.  When a
particular intentional schema is to be materialized, the corresponding
transformations are looked up from this table and operated on by the
interface at a level above the MDR and the STR.

The specification of a transformation includes an \texttt{action},
which is one of ``\texttt{add}'', ``\texttt{del}'', ``\texttt{ren}'',
``\texttt{ext}'', and ``\texttt{con}''.  The input of the action is
a schema object, whose ID (\texttt{OBID}) is recorded in the
\texttt{fromObj} field of the table.  The output of the action is
another schema object -- the \texttt{toObject} in the table.  For
all the transformation operations except ``\texttt{ren}'', only one
entry of either \texttt{fromObj} or \texttt{toObj} is made, a
negative \texttt{OBID} (which is an invalid \texttt{OBID}) is entered
into the field that is not applicable.  In the case of an
``\texttt{ren}'' (rename) transformation, the \texttt{fromObj} field
contains the ID of the schema object with its original name, and
the \texttt{toObj} field contains the ID of the schema object with
the new name.  The \texttt{fromSchema} and \texttt{toSchema} fields
store the ID of the source schema and result schema of the
transformation, respectively.  The query whose value represents the
extent of the transformed construct, if any, is stored in the
\texttt{function} field.  Any constraints associated with a
transformation are entered into the \texttt{cons} field.

% diagram of s4
\begin{stdfigure}{Example ER schema \texttt{s4}}{fig:er_s4}

\stdpicmag{-2}
\begin{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}}}

\begin{picture}(58, 20)
\schema(3,0)(52,18){s4}{\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}}
\end{picture}

\end{small}
\end{stdfigure}

For example, if we have an intentional schema called \texttt{s4} with
schema ID \texttt{4} (shown in Figure~\ref{fig:er_s4}), the
transformations between \texttt{s1} and \texttt{s4} can be represented
in the \texttt{transformation} as follows (An intermediate schema
is created after each transformation.  The intermediate schemas
between \texttt{s1} and \texttt{s4} are named \texttt{s1a},
\texttt{s1b}, and \texttt{s1c}, with schema ID \texttt{5}, \texttt{6},
and \texttt{7} respectively):

\vspace{0.3cm}

% show how the transformation steps between s1 and s4 are stored in
% transformations table
\begin{small}

\begin{center}
\begin{tabular}{lrrrrrr}
\multicolumn{7}{>{\columncolor{tablename}}c}{transformation} \\
\rowcolor{columnname}
action & fromObj & toObj & \underline{fromSchema} &
\underline{toSchema} & function & cons \\
add & null & 18 & 1 & 5 & query & cons \\
add & null & 19 & 5 & 6 & query & cons \\
add & null & 20 & 6 & 7 & query & cons \\
del & 22 & null & 7 & 4 & query & cons \\
\end{tabular}
\end{center}

\end{small}

\vspace{0.3cm}

The following tables show the portions of data in the
\texttt{schema} and \texttt{object} tables that are related
to the transformations between \texttt{s1} and \texttt{s4}.  Arbitrary
object identifiers (\texttt{OBID}) are assigned to the schema objects
belonging to \texttt{s4} and the intermediate schemas between \texttt{s1}
and \texttt{s4}.  Note that all the objects of \texttt{s4} and the
intermediate schemas have the value of \texttt{1} for the
\texttt{isTemp} field because \texttt{s4} and the intermediate schemas
are intentional schemas, hence their objects are ``copied'' from their
parent schema(s) and are not to be permanently stored in the STR.

\vspace{0.3cm}

% show s4 and intermediate schemas in the schemas table
\begin{small}

\begin{center}
\begin{tabular}{lrrrrr}
\multicolumn{6}{>{\columncolor{tablename}}c}{schema} \\
\rowcolor{columnname}
\underline{SID} & name & extSchema & extDB & dataSource & isCached \\
\multicolumn{6}{c}{\vdots} \\
4 & s4 & 0 & 0 & 0 & 0 \\
5 & s1a & 0 & 0 & 0 & 0 \\
6 & s1b & 0 & 0 & 0 & 0 \\
7 & s1c & 0 & 0 & 0 & 0 \\
\end{tabular}
\end{center}

\end{small}

\vspace{0.3cm}

% show how the objects of s4 in the schema_objects table
\begin{small}

\begin{center}
\begin{tabular}{lrrrrr}
\multicolumn{6}{>{\columncolor{tablename}}c}{object} \\
\rowcolor{columnname}
SID & MID & CID & \underline{OBID} & value & isTemp \\
1 & 2 & 2 & 5 & sex & 0 \\
\multicolumn{6}{c}{\vdots} \\
5 & 2 & 1 & 18 & male & 1 \\
6 & 2 & 1 & 19 & female & 1 \\
7 & 2 & 4 & 20 & sex & 1 \\
7 & 2 & 5 & 21 & total & 1 \\
7 & 2 & 2 & 22 & sex & 1 \\
\end{tabular}
\end{center}

\end{small}


\subsubsection{The \texttt{accessMethod} table}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\label{sec:accessMethod}

% the access_methods table
\begin{center}
\begin{tabular}{|ll|}\hline
\multicolumn{2}{|c|}{\textbf{accessMethod}}\\\hline \hline
\underline{AMID} & integer\\
SID & integer\\
URL & varchar\\
PID & integer\\
dbDriver & varchar\\
username & varchar\\\hline
\end{tabular}
\end{center}

\vspace{0.3cm}

The \texttt{accessMethod} table stores information about how to
make connection to databases.  Each access method has a unique
identifier (\texttt{AMID}), the schema identifier (\texttt{SID})
that describes the schema of the database, the URL (\texttt{URL})
of the database, the protocol identifier (\texttt{pid} -- see
section~\ref{sec:protocol}) that indicates the protocol used
for the connection, the database driver (\texttt{dbDriver}), and
the userame (\texttt{username}) that can be used to log in to the
database.

The following table shows some sample access methods stored in the
\texttt{accessMethod} table.

\vspace{0.3cm}

% sample db connection methods in the access_methods table
\begin{small}

\begin{center}
\begin{tabular}{lrrrrr}
\multicolumn{6}{>{\columncolor{tablename}}c}{accessMethod} \\
\rowcolor{columnname}
\underline{AMID} & SID & URL & PID & dbDriver & username \\
1 & 1 & jdbc:mysql://x.y.z:1234/db & 1 & org.mysql.Driver & dbadmin \\
2 & 1 & jdbc:postgresql:emp & 1 & org.postgresql.Driver & foo \\
3 & 2 & jdbc:odbc:People & 1 & sun.jdbc.odbc.JdbcOdbcDriver & bar \\
\end{tabular}
\end{center}

\end{small}

\subsubsection{The \texttt{protocol} table}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\label{sec:protocol}

% the protocols table
\begin{center}
\begin{tabular}{|ll|}\hline
\multicolumn{2}{|c|}{\textbf{protocol}}\\\hline \hline
\underline{PID} & integer\\
name & varchar\\\hline
\end{tabular}
\end{center}

\vspace{0.3cm}

The \texttt{protocol} table stores the types of database connection
protocols.  Each protocol is given an identifier (\texttt{PID}) and
described in the \texttt{name} field.

\vspace{0.3cm}

% sample db connection methods in the accessMethod table
\begin{small}

\begin{center}
\begin{tabular}{ll}
\multicolumn{2}{>{\columncolor{tablename}}c}{protocol} \\
\rowcolor{columnname}
\underline{PID} & name \\
1 & JDBC \\
2 & ODBC \\
3 & XML \\
\end{tabular}
\end{center}

\end{small}

\subsection{MDR Schema}
%%%%%%%%%%%%%%%%%%%%%%%
\label{mdr-schema-sec}

Table~\ref{mdr-tab} lists the tables which make up the
\keywordabbr{model definitions repository schema}{MDR Schema}. Each
type of modelling language (for example ER, Relational, UML, \etc)
that may be held in the MDR will have one entry in the \keyword{model}
table, where the fields have the following meaning:

\begin{itemize}

\item \keyword{mid} is a numeric identifier for the modelling language,
used inside the MDR. 

\item \keyword{name} is the textual name the modelling langauge may be
referred to as in API calls made to the MDR.

\end{itemize}

\begin{stdtable}{Model Definitions Repository Schema}{mdr-tab}

\subtable[]{
\begin{tabular}{|ll|}
\hline \multicolumn{2}{|c|}{model} \\
\hline\hline \underline{mid} & integer \\
name & varchar \\
\hline
\end{tabular}}
\hspace{1em}
\subtable[]{\begin{tabular}{>{\bf}lll}
\multicolumn{3}{>{\columncolor{header}}c}{construct} \\
\underline{mid} 
& integer 
& references model \\
\rowcolor{evenrow}
\underline{cid} 
& integer 
& \\
name 
& varchar  
& \\
\rowcolor{evenrow}
class 
& \multicolumn{2}{>{\columncolor{evenrow}}l}{ $(\textrm{Nodal} \mid
\textrm{Link} \mid \textrm{Link-Nodal} \mid \textrm{Constraint})$ } \\
isRoot 
& boolean 
& 
\end{tabular}}

\subtable[]{\begin{tabular}{|lll|}
\hline \multicolumn{3}{|c|}{scheme} \\
\hline\hline \underline{mid} & integer & references model \\
\underline{cid} & integer & \\
\underline{pos} & integer & \\
type & 
\multicolumn{2}{l|}{ (Name $|$ Construct $|$ Alternation $|$ Sequence) } \\
argMid 
& integer & \\
argCid 
& integer 
& \\
isKey 
& boolean 
& \\
HdmType & \multicolumn{2}{l|}{ ($N_{1} \mid P_{1} \mid N_{2} \mid P_{2} 
\mid C$) } \\
lower & integer & \\
upper & integer & \\
\hline
\multicolumn{3}{|l|}{ (mid, cid) references construct } \\
\multicolumn{3}{|l|}{ (argMid, argCid) references scheme } \\
\hline
\end{tabular}}

\end{stdtable}

The \keyword{construct} relation has one tuple per modelling language
construct.  Examples of modelling language constructs are entities,
attributes, relationships etc.  The class field determines the
correspondence between the construct and its representative HDM.  This
determines, via the HDM template below, what values the HdmType field
may take in this construct's different scheme positions.  Note that
all HDM types may have constraints associated with them; the
constraint HDM type serves to model a constaint alone.


\begin{stdtable}{HDM Types supported by the MDR}{mdr-hdmtypes-tab}

\begin{tabular}{l|l}
\multicolumn{1}{c|}{class} & \multicolumn{1}{c}{HDM Template} \\
\hline Nodal & $\hdms{N_{1}}$ \\
Link & $\hdms{N_{1}, P_{1}, P_{2}}$ \\
Link-Nodal & $\hdms{N_{1}, P_{1}, N_{2}}$ \\
Contstraint & $X$ \\
\end{tabular}

\end{stdtable}

Each construct has a number of scheme tuples associated with it.  Each
scheme tuple corresponds to one argument in the constructor for its
construct.  The HdmType of an argument must be either constraint or
one of the types in the HDM template for the class of the associated
construct.  If the type is name then argMid and argCid have no meaning and
the only HDM type allowed (other than constraint) is $N_{i}$.
Otherwise, they refer to another construct and the only allowable HDM
type is $P_{i}$.  Fields lower and upper determine how many times the
scheme argument can be repeated, repetitions are comma seperated and
together form the HDM type $N_{i}$ or $P_{i}$.  When (argCid, argMid)
refer to another construct, all schemes for the construct with isKey
true must be named to uniquely identify it.  If upper is less than lower
(typically lower = 1, upper = 0) then there is no upper bound. 

The type construct simply means that this argument must refer to an
existing construct of the type referred to by argCid and argMid.  The
type alternation means that any one of the schemes of the construct
referred to can appear as the argument.  It could be used, for
instance to state that an attribute is always associated with an
existing entity or relationship.  In this case the construct that is
referenced would have two scheme arguments of type construct and it
would probably have isRoot set to false as it is unlikely to be a
construct of the modelling language itself.  The type sequence is
similar to alternation, the difference being that all the scheme
arguments of the referenced construct, in order, make up the scheme
argument.

\subsection{ER Example}
%%%%%%%%%%%%%%%%%%%%%%%

\label{er-example-sec}

Figure~\ref{mdr-er-example-fig} is an example of how to represent
simple \keywordabbr{entity relationship}{ER} \cite{Che76}, which
contains entities, simple attributes on entities, and binary
relationships without cardinality constraints.

\begin{stdfigure}{ER Model Represented in the MDR}{mdr-er-example-fig}



\begin{tabular}{|ll|}
\hline \multicolumn{2}{|c|}{model} \\
\hline \multicolumn{1}{|l}{mid} & \multicolumn{1}{|l|}{name} \\
\hline 1 & ER \\
\hline
\end{tabular}
\hspace{1em}
\begin{tabular}{|lllll|}
\hline \multicolumn{5}{|c|}{construct} \\
\hline \multicolumn{1}{|l}{mid} & \multicolumn{1}{|l}{cid} & \multicolumn{1}{|l}{name} &
\multicolumn{1}{|l}{class} & \multicolumn{1}{|l|}{isRoot} \\
\hline 1 & 1 & entity & Nodal & true \\
1 & 2 & attribute & Link-Nodal & true \\
1 & 3 & relationship & Link & true \\
\hline
\end{tabular}

\begin{tabular}{|llllllllll|}
\hline \multicolumn{10}{|c|}{scheme} \\
\hline \multicolumn{1}{|l}{mid} & \multicolumn{1}{|l}{cid} & \multicolumn{1}{|l}{pos} &
\multicolumn{1}{|l}{type} & \multicolumn{1}{|l}{argMid} & \multicolumn{1}{|l|}{argCid} & 
\multicolumn{1}{|l}{isKey} & \multicolumn{1}{|l}{HdmType} & \multicolumn{1}{|l}{lower} &
\multicolumn{1}{|l|}{upper} \\
\hline 1 & 1 & 1 & name & - & - & true & $N_{1}$ & 1 & 1 \\
1 & 2 & 1 & construct & 1 & 1 & true & $P_{1}$ & 1 & 1 \\
1 & 2 & 2 & name & - & - & true & $N_{2}$ & 1 & 1 \\
1 & 3 & 1 & name & - & - & true & $N_{1}$ & 1 & 1 \\
1 & 3 & 2 & construct & 1 & 1 & true & $P_{1}$ & 1 & 1 \\
1 & 3 & 3 & construct & 1 & 1 & true & $P_{2}$ & 1 & 1 \\
\hline
\end{tabular}

\end{stdfigure}

In this example there is a direct one-to-one correspondence between
the modelling language constructs and the HDM types.  Note that
although attribute has HDM type Link-Nodal, it has no $N_{1}$ in the
constructor.  This means that the HDM name of the edge between the
attribute node and entity node has no name.  E.g.

\vspace{0.3cm}

\begin{tabular}{l|l}
\multicolumn{1}{c|}{Construct} 
& \multicolumn{1}{c}{Resulting HDM} \\
\hline ER.entity(person) 
& \hdmn{person} \\
ER.attribute(person,age) 
& \hdme{null,person,age} \\
ER.entity(department) 
& \hdmn{department} \\
ER.relationship(works\_in,person,department) 
& \hdme{works\_in,person,deparment} \\
\end{tabular}

\vspace{0.3cm}

If we allow relationships between more than two entities then we
simply change the upper limit on scheme(1,3,2) or scheme(1,3,3) to 0.
If we also wanted to allow attributes on relationships then we need to
define an alternation for the attribute to refer to.

\vspace{0.3cm}

\begin{tabular}{|lllll|}
\hline \multicolumn{5}{|c|}{construct} \\
\hline \multicolumn{1}{|l}{mid} & \multicolumn{1}{|l}{cid} & \multicolumn{1}{|l}{name} &
\multicolumn{1}{|l}{class} & \multicolumn{1}{|l|}{isRoot} \\
\hline \vdots & \vdots & \vdots & \vdots & \vdots \\
1 & 4 & entity\_relationship & constraint & false \\
\hline
\end{tabular}

\vspace{0.3cm}

This defines the construct and states that it is not a user construct
of the modelling language.  The class constraint simply means that an
instance of this construct does not directly relate to any HDM.

\vspace{0.3cm}

\noindent We now need to define the alternatives for the construct.

\vspace{0.3cm}

\begin{tabular}{|llllllllll|}
\hline \multicolumn{10}{|c|}{scheme} \\
\hline \multicolumn{1}{|l}{mid} & \multicolumn{1}{|l}{cid} & \multicolumn{1}{|l}{pos} &
\multicolumn{1}{|l}{type} & \multicolumn{1}{|l}{argMid} & \multicolumn{1}{|l|}{argCid} & 
\multicolumn{1}{|l}{isKey} & \multicolumn{1}{|l}{HdmType} & \multicolumn{1}{|l}{lower} &
\multicolumn{1}{|l|}{upper} \\
\hline \vdots & \vdots & \vdots & \vdots & \vdots & \vdots & \vdots & \vdots & \vdots & \vdots \\
1 & 4 & 1 & consruct & 1 & 1 & true & $C$ & 1 & 1 \\
1 & 4 & 2 & name & - & - & true & $C$ & 1 & 1 \\
\hline
\end{tabular}

\vspace{0.3cm}

Note that the construct itself is not defined as an alternation, a
reference to it specifies what its arguments mean.  Also note that
the HdmType is $C$, this simply means that there is no correspinding
HDM for this argument (as must be the case as the construct itself
is of type constraint).

\noindent We can now change the definition of attribiute so that the referenced
construct $P_{1}$ can be either an entity or relationship.

\vspace{0.3cm}

\begin{tabular}{|llllllllll|}
\hline \multicolumn{10}{|c|}{scheme} \\
\hline \multicolumn{1}{|l}{mid} & \multicolumn{1}{|l}{cid} & \multicolumn{1}{|l}{pos} &
\multicolumn{1}{|l}{type} & \multicolumn{1}{|l}{argMid} & \multicolumn{1}{|l|}{argCid} & 
\multicolumn{1}{|l}{isKey} & \multicolumn{1}{|l}{HdmType} & \multicolumn{1}{|l}{lower} &
\multicolumn{1}{|l|}{upper} \\
\hline \vdots & \vdots & \vdots & \vdots & \vdots & \vdots & \vdots & \vdots & \vdots & \vdots \\
1 & 2 & 1 & consruct & 1 & 4 & true & $P_{1}$ & 1 & 1 \\
\vdots & \vdots & \vdots & \vdots & \vdots & \vdots & \vdots & \vdots & \vdots & \vdots \\
\hline
\end{tabular}

\vspace{0.3cm}

We can now add an attribute to the works\_in relationship.

\vspace{0.3cm}

\begin{small}
\begin{center}
\begin{tabular}{l|l}
\multicolumn{1}{c|}{Construct} & \multicolumn{1}{c}{Resulting HDM} \\
\hline ER.attribute((works\_in, person, department), salary) & $\ll null,\ll works\_in,person,deparment \gg,salary \gg$ \\
\end{tabular}
\end{center}
\end{small}

\vspace{0.3cm}

Note that we have to name all the key scheme positions of the relationship works\_in.


\bibliography{database}

\end{document}
