% File:    infosys.tex
% Author:  Florian Matthes, Joachim W. Schmidt
% Date:    15-OCT-1993
% Purpose: Information Systems Article 
%	   [including comments from Matthias & Dennis]
%          Synopsis for FIDE book. 5-jun-1997 GS
%
\documentstyle[epsf]{clmult01}

\pagestyle{myheadings}

\def\descriptionlabel#1{\hspace\labelsep \bf #1\hfil}

% -- Macros:
\newcommand{\e}[1]{{\em #1\/}}
\newcommand{\p}[1]{{\tt{}#1}}
\newcommand{\k}[1]{{\bf{}#1}}
\newcommand{\nfnf}{NF$^2$}

\title{Chapter 2.1.2\\
The DBPL Project:\\
Advances in Modular Database Programming}

\author{Joachim W.~Schmidt \and Florian Matthes}

\institute{Technical University Hamburg-Harburg\\Harburger Schlo{\ss}stra{\ss}e 20\\D-21071 Hamburg, Germany}

\begin{document}

\authorrunning{Joachim~W.~Schmidt \and Florian~Matthes}
\titlerunning{The DBPL Project: Advances in Modular Database Programming}

\maketitle

\abstract{This paper is a synopsis of \cite{ScMa94}.}

\section{Introduction}


In the DBPL project we tackled the problem of supporting data-intensive
applications in a single framework, clean and simple in its conceptual
foundation and free of technical mismatches.
Our development of specific language
extensions required by data-intensive applications was
guided by a strict adherence to the language design
principles of simplicity, orthogonality and abstraction.
The project started in the mid 70ies with Pascal/R \cite{Schm77b,Schm78,Schm80,JaSc82b}
and Modula/R \cite{Reim83,MRS84} where we first suggested some high-level language constructs for data of
type relation.
This research culminated in the delivery of
a mature implementation of the DBPL system
\cite{ScMa94,ScMa93a,MaSc93a,MaSc89,ScMa83}, 
a database programming language based on Modula-2.



% ----------------------------------------------------------------------

\section{DBPL Language Concepts}

In the full paper \cite{ScMa94} we describe the rationale, 
the conceptual basis for the language design \cite{ScMa91d} and 
the specific language elements in detail.
Conceptually, we based the DBPL language on Modula-2 with built-in extensions for data-intensive
applications:
\begin{itemize}
\item a parametric bulk type constructor for ``keyed sets'' or relations;
\item a module concept which supports sharing across programs and implies persistence;
\item a procedure concept with transactional semantics, i.e., 
      serializability and recovery;
\item abstraction from bulk iteration through associative access
      expressions. 
\end{itemize}
%
In particular, we eliminated the competence and impedance
mismatch between programming languages and database
management systems by providing
\begin{description} 
\item[orthogonal persistence,]
 a uniform treatment of volatile and persistent data,
\item[type completeness,]
 a uniform treatment of large quantities of objects with a simple 
      structure and small quantities of objects with a complex structure, 
      as well as 
\item[strong static typing,]
 a uniform (static) compatibility check between the declaration and the 
      utilization of each name. 
\end{description} 
%
\pagebreak
In implementing the DBPL system we adopted a rather strict approach by
aiming for 
\begin{itemize}
\item full orthogonality in our relationally extended type space, leading especially to nested relations;
\item type-complete persistence, i.e. longevity of data from Booleans to relations;
\item functional abstraction for relational expressions including
recursion.
\end{itemize}
%
Without going into details it should be noted that naming (of
statements, expressions etc.) naturally leads to the concept of
recursion (see Fig.~\ref{Fig:AccessExp}). The semantics of a recursive query expression in DBPL is not
defined operationally (as is common practice for procedures) but as a
least fixed point of recursive set equation \cite{ERMS91,JLS85}.

\begin{figure}[htb]
\begin{verbatim}
TYPE NumPairType = RELATION OF RECORD
                               Super, Sub : PartNumType END;

CONSTRUCTOR TransitiveMadeFrom: NumPairType;
BEGIN
  {p.Name, mf.Num} OF 
     EACH p IN PartRel, EACH mf IN p.MadeFrom:
       p.State = comp,
  {mf1.Super, mf2.Sub} OF 
    EACH mf1 IN {TransitiveMadeFrom},
    EACH mf2 IN {TransitiveMadeFrom}:
      mf1.Sub = mf2.Super
END TransitiveMadeFrom;
\end{verbatim}
\caption{Recursive query (access expression) in DBPL}
\label{Fig:AccessExp}
\end{figure}


\section{DBPL System Architecture}

In the full paper we
report on experience gained during DBPL system
implementation and refinement in
\begin{itemize}
\item removing conventional compiler implementation restrictions \cite{ScMa90b},
\item extending the expressiveness of the bulk query language,
\item generalizing the storage model, and
\item reducing system performance bottlenecks resulting from
mismatches between independently developed contributing technologies \cite{JaKo83}.
\end{itemize}
%
A repeating pattern in the development of the DBPL system was the need
to generalize existing database solutions to meet the requirements
imposed by the orthogonal DBPL language model.

DBPL was not the end of our efforts in supporting
database programming. We embedded it into a network of DBPL-based
spin-off projects ranging from distributed DBPL \cite{JGLR88,LEERS87} 
to DBPL-oriented programming environments (DAIDA) \cite{Jark93,JMW*90,SWBM89}.
The Open DBPL/SQL gateway \cite{MRSS94} and the
bidirectional call interfaces between DBPL and other languages
demonstrated that it requires a surprisingly small effort to embed a
``closed'' database programming language with a well-designed internal
architecture into ``open'' system environments.


\section{On Project Termination}

Over the years, we encountered several data modeling concepts
(inheritance, object identifiers, ordered bulk data structures,
triggers, \ldots) and database system requirements (communication
between concurrent processes, exception handling, \ldots) that did not
fit nicely into the original DBPL language framework (see, for example, \cite{BJS86,JLRS88}).
We regard the monomorphic type system of Modula-2,
the lack of first-class procedures, and the strict separation between
built-in and user-defined system functionality in the DBPL system
architecture as hard, built-in limitations which prevent, without
violating our design principles, DBPL extensions beyond the realms of
set- and predicate-based data models and first-order programming
languages.

The DBPL project results in a mature product for modular database
application programming and a follow-up project Tycoon (see Chapters 1.1.1 and 2.1.4) based on polymorphic
types and other higher-order concepts.
Thus the Tycoon project carries forward in a more
general linguistic and architectural framework the experience gained
with bulk data typing, iteration abstraction, and modularization in DBPL.

\begin{acknowledgement}
This research was supported by ESPRIT Basic Research, \#892 (DAIDA), \#3070 (FIDE), \#6309 (FIDE$_2$).
\end{acknowledgement}

\small
\bibliographystyle{plain}
\bibliography{../dbis-macros,../florian}

\end{document}
