MÜNCHEN (uk) - Eineinhalb Jahre nach der Neuvorstellung des "Universellen Datenbanksystems UDS (CW Nr. 17 vom 23. April 1976) hat Siemens jetzt die UDS-Version 2 vorgelegt. Während sich Version 1 noch strikt an die Codasyl-Vorschläge anlehnte, soll das neue Release die Koexistenz von Relationen-, Netzwerk- und hierarchischen Datenbanken ermöglichen. Die Modell-Verträglichkeit auf der untersten Stufe, nämlich auf ein und derselben Datenbank, ist mit UDS 2 nach Siemens-Angaben zwar noch nicht voll verwirklicht worden - ist jedoch Ziel der Weiterentwicklung. UDS-Chefentwickler Eberhard Wildgrube beschreibt im folgenden Beitrag dieses Koexistenzmodell und erläutert an einem Anwendungsbeispiel inwieweit in Version 2 dieser theoretische Ansatz verwirklicht wurde:

Die Diskussion um Datenmodelle wurde entfacht durch die CODASYL-Vorschläge, die pragmatisch orientiert waren im wesentlichen auf einem Netzwerksmodell beruhen und zu mehreren in der Praxis erfolgreich eingesetzten Systemen geführt haben. Das auf der mathematischen Mengenlehre aufbauende Relationenmodell von CODD hat das Thema Datenbank und Datenmodelle in den Hochschulen aktiviert und damit in den vergangenen Jahren zu einer wahren Flut von Arbeiten geführt. Die zum Teil kontrovers geführte Diskussion um Relationenmodell kontra Netzwerkmodell war insgesamt sehr fruchtbar für die Weiterentwicklung der Datenmodelle und konvergiert seit etwa zwei Jahren im Sinne einer "Koexistenz" verschiedener Datenmodelle. Das Koexistenzmodell ist ein Drei-Schema-Modell, wie es vor allem im ANSI-report und dessen Interpretationen vorgeschlagen worden ist, und das heute

als weitgehend akzeptiert gelten kann.

Die Frage der "Koexistenz" verschiedener Datenmodelle stellt sich nur an der Benutzerschnittstelle. Der Benutzer soll die Freiheit erhalten, das ihm gemäße Datenmodell zu wählen. Dabei müssen wir 2 Stufen der Koexistenz unterscheiden:

- Koexistenz in demselben Datenbanksystem, das heißt mit derselben Software können Datenbanken, die gemäß den verschiedenen Datenmodellen strukturiert sind, realisiert werden.

- Koexistenz auf derselben Datenbank, das heißt ein und derselbe Datenbestand kann gleichzeitig aus verschiedenen Benutzersichten mit unterschiedlichen Datenmodell-Vorstellungen betrachtet werden.

Für die Koexistenz-Fähigkeit eines Systems interessiert (hauptsächlich) der angebotene Funktionsumfang für Daten- die relationale Sicht der Daten über Netzdefinition (DDL) und Datenmanipulation (DML).

In der Diskussion um die Koexistenz von Datenmodellen hat es sich eingebürgert, von 3 Hauptmodellen auszugehen:

- Relationenmodell (n-stellige Relationen)

- Hierarchisches Datenmodell (Baumstrukturen)

- Netzwerkmodell (Netzstrukturen)

An einem Beispiel soll die Behandlung dieser 3 Grundmodelle aufgezeigt werden. Das Beispiel beschreibt eine Ausbildungsdatenbank einer Firma mit Weiterbildungskursen im Hause. Für jeden Weiterbildungskurs enthält die Datenbank Informationen über alle Kurse, die Voraussetzung zum Besuch eines bestimmten Kurses sind, sowie über die nach Ort und Termin unterschiedlichen Angebote des gleichen Kurses. Für jeden dieser durchzuführenden Kurse sind alle beteiligten Lehrer und alle angemeldeten Schüler notiert, wobei sowohl Lehrer wie Schüler zugleich Angestellte dieser Firma sind.

Bild 1 zeigt ein relationales Schema für diesen Datenbestand in üblicher Schreibweise: Der Relationsname steht voran, in der Klammer die Attributnamen.

Bild 2 zeigt für den gleichen Datenbestand ein hierarchisches Schema, das 2 Teilbäume enthält, wovon einer nur aus einer "root"-Satzart besteht. Das Schema ist auf minimale Redundanz ausgelegt das heißt die Hierarchie selbst ist Informationsträger.

Bild 3 schließlich zeigt das Netzwerkschema für dieses Beispiel, wieder mit minimaler Redundanz. Es liegen mehrere "viele:viele"-Beziehungen vor, die über 2 funktionale Beziehungen abgebildet werden.

Werden diese 3 Schemata realisiert, so lautet die Datendefinition im Subschema gemäß Bild 4, wobei entsprechende Definitionen im Schema vorausgesetzt sind. Im Falle der Hierarchie bzw. des Netzwerkes wird nur ein Teil der Felder benötigt. Die zugehörige Strukturdefinition zeigt Bild 5, wobei hier umgekehrt im Falle von Hierarchie und Relationenschema nur ein Teil der SET's bzw. überhaupt keine SET-Definitionen im Schema benötigt werden.

Bisher wurde besprochen, welche System-Fähigkeiten für die Koexistenz der 1. Stufe vorliegen müssen, um, wie in unserem Beispiel, 3 verschiedene Ausprägungen der Datenbank für dieselbe Anwendungs-"Miniwelt" realisieren zu können.

Welche Voraussetzungen müssen bei der Strukturierung der Datenbank erfüllt werden, damit auch die Koexistenz 2. Stufe ermöglicht wird? Diese Frage führt auf ein viel diskutiertes Thema: Ist der Set als Informationsträger sinnvoll oder nicht? "Information bearing set" beziehungsweise "essential set" contra "non-information bearing set" oder "inessential set"? In unserem Beispiel sind bisher nur "essential sets" verwendet worden. Wenn jedoch die Verknüpfungsinformation zwischen den Sätzen in Feldinhalten, wie im relationalen Fall, hinterlegt wird und zusätzlich Sets definiert werden, so werden dies "noninformation bearing sets" mit der Funktion von Zugriffspfaden, die ganz so wie Indexdaten über bestimmten Feldern (partial inverted files) zu sehen sind. Deshalb ist es sinnvoll, den Begriff "Redundanz" differenziert zu betrachten und zwischen semantischer Redundanz (mehrfache Repräsentanz gleicher Tatbestände, Information) und System-Redundanz (vom System erzeugte und kontrollierte Redundanz in Zugriffspfaden) zu unterscheiden.

Werden in der Schema-Definition nur "inessential sets" verwendet, so sind dann zumindest für Datenwiedergewinnungsprogramme alle 3 Subschemata möglich.

Im Fall von Satzeinfügungen und Löschungen sollte jedoch mit Subschema gleich Schema gearbeitet werden.

Bisher wurde als Benutzerschnittstelle das "program interface" (DML) betrachtet. Mit einer höheren Abfragesprache (Interactive query language) kann der Endbenutzer am Terminal aber eigene Satzarten aus Feldern verschiedener Satzarten der Datenbank zusammengesetzt definieren (Relationen). Er kann über mehrere Satzarten hinweg in der Datenbank inhaltlich suchen, wobei der Bezug auf die Datenstruktur einmalig durch das Auswahl-Struktur-Statement hergestellt wird. In unserem Beispiel kann man so über dem Netzwerkschema alle Relationen des relationalen Schemas erzeugen und sich am Bildschirm ausgeben lassen. Da damit die relationale Sicht der Daten über Netzwerks- und hierarchische Strukturen ermöglicht wird, wird zum Teil die Koexistenz 2. Stufe erreicht.