% File:    kiev90-5.tex
% Author:  F. Matthes
% Date:    28.2.1991
%

\section{Open Architectures for Database Application Systems}
\label{Architecture}

\begin{figure}
\ \\ \ \\ \ \\ \ \\ \ \\
\caption{Open Language Processing in Database Application System}
\label{components}
\end{figure}

The discussion in the previous section (\ref{Efficiency}) emphasizes the
need for a substantially improved flow of information between the
various components of a Database Application System, for example,
between the application program, the parts and pieces of the compiler,
the query optimizer and the shared database schema.

Figure~\ref{components} gives an idea of the kind of information
processed, for example, during the compilation of a modular database
programming language. In contrast to traditional implementation
techniques for language processors, we envisage an \e{open}
architecture, where the individual components of the compiler are made
available to other clients in the DBAS, revealing their well-designed
overabstracted interfaces. Compared with the architecture of traditional
database programming languages \cite{ScMa90b} and persistent programming
languages \cite{BCCDM88}, the built-in system components are designed to
provide enough ``genericity'' to be instantiated with specific
parameters in a wide range of application and system programs. For
example, semantic program analysis, basic query optimization and binding
optimization in object-oriented languages \cite{Larc90} can all be
uniformly supported by formalisms like \e{attribute grammars} and
generic tools for their (incremental) computation \cite{ReTe88}.

It should be noted that in Figure~\ref{components}, the traditionally
``process-oriented'' view of a compiler (mapping from a high-level
source language to a low-level target machine) is replaced by a
``data-oriented'' translation model. A program entity (e.g. a function)
may be represented by several co-existing representations (source code,
signature, attributed syntax tree, binding) that are tailored to
particular information requirements in the DBAS.  This shift in
perception allows the mutual support and deeper integration of
programming language technology: The attribute evaluater and the linker,
which both access large, shared and persistent data structures, require
\e{database system support} for integrity control, storage management or
access control. Conversely, we already noted that database browsers,
query interfaces and query optimizers heavily rely on functionality that
is already present in the database language processor.

To summarize, there are strong arguments that database system
implementation and database application programming can both be
supported by the same DBAS language based on a set of ``generic''
language features such as typing, kinding, binding, subtyping, subkinding,
parameterization and scoping. 
