
\section{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.

\subsection{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}


\subsection{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}


\subsection{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}


\subsection{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}


\subsection{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}

\subsection{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}

