This document defines the language TL that is used as the application and system programming language in the Tycoon database environment. The Tycoon project follows an add-on approach to generic database programming that emphasizes type-safe system scalability and extensibility.

TL is a polymorphic higher-order functional language with imperative features and inductively defined subtyping rules over types and type operator, extended by language constructs motivated by the needs of database programming.

A promising approach to improve the quality of next-generation database programming languages is to strictly separate data modeling and data manipulation tasks from data storage issues. This separation greatly simplifies the development of tailor-made database languages and data models based on the generic services of a data model neutral object store protocol that provides efficient, transactional access primitives to persistent, shared and possibly distributed data objects.

As a first step towards this goal, this paper investigates the specific services which language clients require from their supporting object stores. It gives insight into the process of selecting a suitable object store for a polymorphic higher-order programming environment (P-Quest) and sketches the mapping of higher-level language objects like functions, environments and polymorphic aggregates, onto more primitive storage structures. The functionality of three candidate object stores (O2, Mneme and Napier POS) is evaluated based on the requirements imposed by the Quest language.

The database programming language DBPL is based on the notion of bulk type and iteration abstraction, supports data persistence and transaction procedures, and has Modula-2 as its algorithmic kernel.

This fist part of this document is intended for users of the DBPL system and gives an introduction into the DBPL language concepts and illustrates their use in a larger modular database application.

The second part gives some insight into the implementation of the DBPL system. As of today, the DBPL system exists in two fully source code compatible implementations, VAX/VMS DBPL and Sun DBPL. Both are written entierly in Modula-2 and consist of a compilation and a run time environment. The multi-user run time system is highly portable and runs under VAX/VMS 6.1, SunOS 4.1, IBM AIX 3.2 and IBM OS/2. Both DBPL systems can be integrated deeply into commercially available software development environments (NSE, SCCS, CMS) and provide optimized transactional multi-user access not only to type-complete DBPL databases but also to external relational databases via a fully transparent SQL gateway.

A gateway from DBPL (being a superset of Modula-2) to the commercial Ingres is described. DBPL extends Modula-2 in several ways, in particular, it introduces a new bulk and persitent data type ``relation'', and high-level relational expressions (queries) based on the predicate calculus. The gateway enables the user to write normal DBPL programs addressing Ingres databases. In contrast to typical implementations that embed SQL statements into a programming language, the interface becomes fully transparent to DBPL programmers: they need not to be familiar with SQL and Ingres. In this way the impedance mismatch problem is avoided. DBPL queries and other statements referring to Ingres tables are automatically converted into corresponding SQL statements, and the output from Ingres automatically becomes the property of the DBPL program. The gateway supports queries that refer both, Ingres and DBPL relations. This paper presents design assumptions of the gateway and implementation methods. In addition, we discuss design and implementation difficulties.

This document provides a smooth intorduction into the language concepts of P-Quest and the underlying persistence model.

This document explains the structure and the use of the Tycoon compiler toolkit, a library of generic modules in the Tycoon system library implemented in P-Quest including a strongly-typed LL(1) parser generator.

The database programming language DBPL is based on notion of bulk type and iteration abstraction, supports data persistence and transaction procedures, and has Modula-2 as its algorithmic kernel. This document describes the rationale behind DBPL and defines the elements of the language.

Mit der Entwicklung objektorientierter Datenbanken (OODBn) sollen die vielfach bemerkten Restriktionen des relationalen Datenmodells überwunden werden. Im Gegensatz zu diesem fehlt den Konzepten objektorientierter Datenbanken bisher allerdings sowohl eine zufriedenstellende formale Grundlage als auch ein allgemein akzeptiertes Datenmodell.

Ziel unserer gemeinsamer Forschungsarbeiten in Hamburg und Rostock ist die Entwicklung eines formal abgesicherten objektorientierten Datenmodells (OODM) als Beitrag zu einer einheitlichen mathematischen Theorie für OODBn.

Grundlegend für das OODM ist die Unterscheidung zwischen Werten und Objekten. Erstere werden durch Typen, letztere durch Klassen strukturiert. Ein zentrales Problem ist dabei die Bereitstellung eindeutiger Identifikationsmechanismen für Objekte. Wir lösen dieses Problem für Klassen, deren Objekte durch Werte vollständig repräsentiert werden können. Solche Klassen werden dann als werterepräsentierbar bezeichnet. Da eine Datenbank zu jedem Zeitpunkt nur endlich viele Objekte enthalten kann, ist Werterepräsentierbarkeit unter bestimmten Voraussetzungen entscheidbar, nämlich, wenn endlich repräsentierbare rekursive Typen existieren und alle benutzerdefinierten Integritätsbedingen sog. uniqueness constraints sind.

Ein Vorteil relationaler Datenbanken ist die Existenz eindeutig durch das Datenbankschema definierter generischer Veränderungsoperationen. Wir zeigen, daß diese Eigenschaft im OODM nur für werterepräsentierbare Klassen gilt. In diesem Fall aber wird sichergestellt, daß implizit durch das Schema gegebene Referenz- und Inklusionsintegritätsbedingungen automatisch bewahrt werden. Wir geben einen Algorithmus zur Erzeugung dieser generischen Operationen an und zeigen, daß dieser durch linguistische Reflexion implementierbar ist.

Dieses Ergebnis läßt sich auf ausgezeichnete Klassen statischer Integritätsbedingungen erweitern. Wir zeigen sogar, daß Integritätserzwingung im allgemeinen durch die Konstruktion größter konsistenter Spezialisierungen (GCS) möglich ist. Für eine beliebige Methode S und eine statische oder Transitionsintegritätsbedingung I kann gezeigt werden, daß die GCS S(I) immer existiert und bis auf semantische äquivalenz auch eindeutig ist. Mehr noch, GCSn sind mit Konjunktionen von Integritätsbedingungen, Vererbung und Verfeinerung kompatibel. Für benutzerdefinierte Transaktionen ist es allerdings nicht ausreichend, die hierin vorkommenden einfachen Veränderungsoperationen jeweils durch ihre GCSn zu ersetzen.