% File:    kiev90-2.tex
% Author:  F. Matthes
% Date:    6.2.1991
%
\section{Requirements of Database Application Systems}
\label{Requirements}

As argued above, database system implementation and database application
programming activities both share a large set of commonalities. We
propose to distinguish three main tasks in the construction of
integrated Database Application Systems:
\begin{description}
\item[{Data abstraction}] to classify, aggregate and generalize 
data, programs and meta-data;
\item[{Localization abstraction}] to ``factor out'' repeating or
shared patterns of data, program and meta-data;

\item[{Implementation abstraction}] to selectively hide information 
about structures defined by the previous two abstraction mechanisms.
\end{description} 

The following subsections present these three abstractions in turn,
relating them to specific activities in database modelling
and application programming. A more detailed discussion of the above
abstraction principles and their support by existing (database)
programming languages can be found in \cite{ScMa90a,ScMa89}.


\subsection{Data Abstraction}

Research and development in the area of conceptual modelling 
\cite{BMS84,MyBr89} has isolated three basic \e{data abstraction
principles} to cope with the size and complexity inherent in
data-intensive applications. These abstraction principles can be
understood as means to capture structural invariants, considered an
important subclass of static constraints among data objects:
\cite{SmSm77,Brod84}:

\begin{description}
\item[Classification / Instantiation] is a form of data abstraction in
which a collection of objects is considered as a higher-level object.
The higher-level object is a characterization of all properties shared
by each object within the collection. Classification establishes an
\e{instance-of} relationship and allows to identify, classify and
describe (possibly infinite) sets of objects by means of a single
object.

\item[Aggregation / Decomposition] is a form of data abstraction in
which a relationship between $n$ component objects is considered as a
single higher-level aggregate object. The {\em part-of} relationship
between the $n$ components and the aggregate object also allows to
identify component objects relative to the higher-level object.

\item[Generalization / Specialization] is a form of abstraction in
which a relationship between ``similar''Êobjects is considered
as a higher-level generic object. This is the {\em is-a} relationship.
\end{description}

For the purpose of this paper, the above characterization  of the
three data abstractions should be sufficient, even if there are
substantially different technical definitions, e.g., of the term
``similarity'' in various data models. We only note that much of the
power of these three abstraction principles comes from their 
generality and {\em orthogonality}, i.e.\ the possibility to apply
classification, aggregation and generalization to objects that already
have been abstracted over, e.g.\ to define metaclasses (classes of
classes \cite{MyBeWo80}), nested aggregates (complex objects
\cite{AbBe88}) or generalized generic objects (multi-level inheritance
hierarchies \cite{BMW84}).

In the context of Database Application Systems, it is not only
necessary to classify, aggregate and generalize \e{data structures} of
a given application, but also to reduce the complexity of the huge
number of other entities (functions, modules, types, iterators) found
in the application environment by organizing these entities using
well-crafted abstractions.


\subsection{Localization Abstraction}

We already emphasized in the introduction the need to
factor out possessions of data and functionality from individual
applications into a database application environment and to make them
available for shared use by a larger community. The primary goal of
this localization process is to increase the consistency between
applications and to avoid duplication of effort. Localization becomes
indispensable in any environment that is subject to change or
evolution.

The basic mechanism to achive localization is \e{naming}: The binding
of a name to an object allows the repeated use of the object denoted
by the name in different contexts without duplicating its definition.
Section~\ref{Parameterization} discusses how to substantially enhance
the possibiliy for localization by means of \e{parameterization},
allowing to abstract over partial object descriptions.

As an advanced example for localization, a traditional DBMS allows to
factor out data (shared database variables) but also to factor out
complex functionality (persistence management, access-path maintenance,
crash recovery) from data-intensive applications.


\subsection{Implementation Abstraction}

The previous two subsections were mainly concerned with modeling and
software engineering aspects of database applications. Because of the
size, value and longevity of the data to be dealt with, database
applications also have a strong demand for \e{non-functional support}
to be provided in a Database Application Environment.

The implementation of a lookup table may illustrate this aspect. In a
programming language setting, it is sufficient to implement a lookup
table by means of a hash table or a search tree. The implementation of
a lookup table is therefore adequately described by its operations
(insert, remove, lookup) and its time and space requirements. In a
database environment, implementors of a persistent and shared lookup
table have to take care of the storage management on disk, avoid
interference between concurrent update operations and guarantee the
integrity of the data structure in cases of program failures or system
crashes.

The main non-functional (or operational) requirements of database
applications can be summarized as support for persistence, atomicity,
concurrency and \e{data independence}. Whereas the first three aspects
are also captured by (special-purpose) programming languages
\cite{ACC81a,NapierRep,LCDS87,WeLi81,RiCa87} the notion of data independence
deserves more attention. A first step towards data independence is to
provide multiple implementations for a given abstract data structure
(e.g.\ a relation). The choice of a particular implementation (e.g. a
B-tree for primary key access plus two secondary indices on non-key
attributes) is made dynamically, based on additional global information
about relation cardinalities and access patterns.

Another important consequence resulting from the desire to achieve
efficiency in the presence of data independence is the need to
\e{optimize} expressions involving multiple abstract data structures
The basic idea pursued by query optimizers in database management
systems is to transform such an expression into a semantically
equivalent, but more efficiently executable form. Again, this
transformation is guided by global information about the
\e{operational} properties (e.g. time, space) of the actual
implementations available at run-time.



