Eine Kritik der Datenmodelle mit einem Diskussionsvorschlag zur Verbesserung der Datenunabhängigkeit bei formatierten Datenbanksystemen.

Teil III. Die letzte Folge erschien in der COMPUTERWOCHE 17 vom 27. April 1979.

Das Relationenmodell

Mit Schlagworten wie "Die Relationenzukunft hat schon begonnen" oder "Bei den Relationisten steht der Anwender im Vordergrund" können falsche Hoffnungen erweckt werden. Die Unfähigkeit des Relationenmodells, Sätze mit gleichem Informationsgehalt zu verwalten (doppelte Tupeln sind nicht zulässig, weil es mindestens ein Schlüsselattribut geben muß, das einen Satz von den anderen Sätzen unterscheidet), stellt einen Datenorganisator dann vor Probleme, wenn er wegen dieser Forderungen Schlüssel definieren muß, die für den Benutzer einen zusätzlichen, meist als überflüssig empfundenen Pflegeaufwand bedeuten.

Das Relationenmodell geht davon aus, daß in jeder Relation, die nach der "Normalformlehre" normalisiert vorliegt, alle Schlüsselkandidaten bekannt sind und daß die Attributwerte, die zu diesen Schlüsselkandidaten gehören, auch existieren. Durch das Zusammenfügen aller Schlüsselwerte zu einem ENTITY ist der Eingangsmechanismus gesichert.

In der Praxis treten Probleme auf, bei denen die Philosophie der Bildung eines ENTITY durch das Zusammenfügen von Schlüsselkandidaten nicht möglich ist.

Dafür gibt es zwei Gründe:

a) Es läßt sich nicht feststellen, welche Attribute Schlüsselkandidaten sind, und ein ENTITY wird durch die Bildung einer laufenden Nummer definiert.

b) Zum Zeitpunkt der Neuaufnahme (aber auch bei einem Änderungsablauf) der Daten ist ein Attributwert eines Schlüsselwertes nicht bekannt, auch wenn alle Schlüsselattribute bekannt sind.

Manche in der Realität vorkommenden Informationsstrukturen können aber mit dem Relationenmodell nicht abgedeckt werden.

Beispiele:

Bei der Speicherung und Wiedergewinnung von Informationen, die sich nicht ändern (Zeitrelationen genannt, wie zum Beispiel Zahlungen) oder die an verschiedenen Orten entstehen können (zum Beispiel Kundenadressen), ist es unmöglich, festzulegen, wer für die Vergabe einer neuen Nummer (Kundennummer, Adressennummer, Rechnungsnummer) verantwortlich sein soll, weil gleichzeitig (online) von verschiedenen Orten eine neue Nummer vergeben werden kann.

Solche Nummern sind nur bei Änderung oder Löschung für den Benutzer interessant. Die Tatsache, ob bereits eine Adresse im Datenbestand vorhanden ist oder nicht, kann er nur durch die Suche im Datenbestand feststellen, eine laufende Nummer nutzt ihm nichts. Es müssen in solchen Fällen immer zentrale Stellen in einer EDV-Abteilung eingeschaltet werden, deren Mitarbeiter für die Vergabe einer eindeutigen Nummer verantwortlich sind. Die Neu-Numerierung kann aber das Datenbanksystem selbst durchführen (was bis heute die Aufgabe eines Benutzerprogramms ist, wobei aber wiederum verschiedene Programme mit dem DBS korrespondieren können). Ob es sich um eine Neuaufnahme oder Veränderung eines Satzes handelt, kann nur der Sachbearbeiter entscheiden.

In einer Datei beispielsweise, die der Verbrechensbekämpfung dienen soll, ist es schlicht unmöglich, irgendwelche Attribute als Schlüsselattribute zu deklarieren. Auch wenn man alle Attribute zu einem Ordnungsbegriff (Schlüsselkandidat) erklärt, bleibt das Problem bestehen. Man kann zwar ein Zeitergebnis (oder eine laufende Nummer) jedem Satz zuordnen, dieses Attribut ist aber für die Fahndung und für die Entscheidung, ob es sich um eine Änderung oder Neuaufnahme von Informationen handelt, ohne Bedeutung.

Bei der Verwaltung multipler Felder, deren Anzahl von Anfang an nicht bekannt ist, gibt es immer wieder Probleme, wenn solche Felder linear in einem Satz angeordnet werden. Man kann pro Feld einen neuen Satz bilden, wobei aber nach dem Relationenmodell alle Schlüssel des Satzes zusammen mit den nichtssagenden Schlüsselattributen "laufende Nummer" in diese Relation überführt werden müssen. Solche Sätze dehnen außerdem den Platzbedarf unverantwortlich aus.

Das ENTITY-SET-Modell

Der Datenstrukturentwurf nach dem Modell der CODASYL-Gruppe ist für eine n Datenorganisator einfacher. Dort wo er bereits mit dem Codd'schen Normalisierungsprozeß scheitern würde, ist er mit den Begriffen "OWNER", "MEMBER", "SET" immer noch in der Lage, die ENTITIES festzustellen, auch wenn er keine Schlüssel erkennen kann. Die Behauptung, daß eine "tabellarische" (also relationale) Denkweise mehr als die "hierarchische" dem menschlichen Denken entspricht, ist nach meiner Ansicht unzutreffend.

Eine Entscheidung zugunsten eines DBVS, das nach dem Modell der CODASYL-Gruppe arbeitet, stellt aber eine langfristige und folgenschwere Entscheidung dar, weil die zu einem bestimmten Zeitpunkt vorliegende Datenstruktur dem DBVS mittels eines SCHEMAS mitgeteilt werden muß und danach nur schwer änderbar ist.

Wenn die gesamte Informationsstruktur von Anfang an nicht vollständig ist, weil im Laufe der Verfahrensentwicklung mit Strukturveränderungen zu rechnen ist, müssen auch die mittels der SCHEMA-Definition vorgegebenen Organisationsinformationen des Systems in den Sekundärdateien später modifiziert werden. Dies ist aber nur mit umfangreichen Dienstprogrammen möglich, weil das System auch die internen Pointer in dem Primärbestand an die neue Struktur anpassen muß. Dabei werden in der Regel auch die nicht betroffenen SUBSCHEMA-Definitionen in den Programmen übersetzt, auch wenn die entsprechende Änderung weder die E/A-Bereiche noch die Verarbeitungsalgorithmen auf irgendeine Weise beeinflußt.

Zu bedenken ist auch, daß die einmal logisch richtig und vollständig definierte Struktur eventuell aus Performance-Gründen modifiziert werden muß, weil man sonst auf eine Antwort unzumutbar lange warten müßte.

An dem Datenmodell der CODASYL-Gruppe wird also nicht das ENTITY-SET-Konzept für den Datenstrukturentwurf kritisiert, sondern die Tatsache, daß die ENTITY-SETs mit SET-Namen versehen in einem SCHEMA oder SUBSCHEMA definiert werden müssen, damit sich das System an diesem Pfad orientieren kann und der logische Zugriffspfad 1:1 physisch in der Datenbank abgebildet wird.

Die Synthese der beiden Modelle auf der logischen Ebene sähe wie folgt aus:

Ob ein ENTITY durch Zusammenführen aller Schlüsselattribute zu einem Ordnungsbegriff (Schlüsselkandidat) oder aus dem Zugriffspfad (SET-Name) entsteht, ist für das DBVS unerheblich, weil es beide Formen der ENTITY-Festlegung akzeptieren kann. Das DBVS muß selbst dafür sorgen (durch die Vergabe einer Satznummer und Akzeptanz eines neuen Satzes mit gleichem Informationsgehalt), daß der Eingangsmechanismus richtig funktioniert, auch wenn keine Vereinbarung des Zugriffspfades durch eine SCHEMA-Definition getroffen wurde. Es kann ohne den SET-Namen zum Ablaufzeitpunkt alle Strukturanweisungen dynamisch interpretieren und auf Wunsch die vorhandene Struktur dokumentieren, wobei die Informationen über die Struktur nur in den Primärdaten enthalten sein dürfen.

Die mit den Begriffen "OWNER-MEMBER" angegebenen funktionalen Abhängigkeiten können durch einen internen Normalisierungsprozeß in einer Relationen-Datenbank abgebildet werden.

Damit wird auch vermieden, daß bei einem logischen Verbund (JOIN) auch ENTITIES gebildet werden, die semantisch keinen Sinn ergeben, weil angenommen werden muß, daß der Benutzer nur solche Verbindungen als relevant erklärt, die er auch bei der Wiedergewinnung benötigt.

Die Voraussetzungen für eine Synthese der beiden Datenorganisations-Modelle (Relationenmodell und Modell der CODASYL-Gruppe) sind dann gegeben, wenn:

a) auf die SCHEMA-Definition und den SET-Namen verzichtet werden kann,

b) die Speicherung von gleichen Tupeln möglich ist.

* Ladislav Motl ist Mitarbeiter der Münchner Unternehmensberatung UNA.