Die Datenbank: Der Vorstandsvorsitzende erhofft sich ihr den Software-technischen Weg aus dem Informationsdilemma, der Finanzchef erachtet sie in erheblichem Umfang als informationsrelevant der Datenschutzbeauftragte sieht sie als Conditio sine qua non; der DV-Leiter wollte sie immer schon, und IBM hat sie. Damit findet die überwiegende Anzahl von Datenbank-Evaluationen ihr vorläufiges Ende.
Was soll die Datenbank eigentlich bewirken? Dies ist keineswegs so kompliziert, wie es meist dargestellt wird, sondern laßt sich - überall nachlesbar - auf eine einzige Hauptforderung reduzieren mehreren Anwendungen ihre individuellen Sichten aus einem für sich gleichen Datenbestand ermöglichen. Es versteht sich von selbst, daß de Bereitstellung einer neuen Datensicht hierbei keine Auswirkung auf bereits bestehende Datensichten und die Daten selbst haben darf.
Der Anwender kennt also nicht mehr die physischen Gegebenheiten der von ihm zu verarbeitenden Informationen. Er sieht die Daten in einer Weise, als seien sie speziell für ihn und nur für ihn - aufbereitet. Da in konventionellen Dateisystemen die technische Datendefinition und -verwaltung einen erheblichen Teil des Anwendungsprogramms ausmacht, können auf dem Weg über die Datenbank vorhandene Entwicklungskapazitäten in höherem Maß der eigentlichen Anwendung zugute kommen.
Dadurch daß ein Datenbanksystem die physische und anvendungsseitige Datenbeschreibung strikt trennt und
somit Datenunabhängigkeit schafft, werden praktisch alle Abhängigkeiten zwischen dem Anwendungsprogramm und der physischen Datenstruktur eliminiert
Physisch-logische Verknüpfungen
Diese Datenunabhängigkeit nun stellt eine Eigenart dar, die praktisch jeder Anbieter in seinem System zu erkennen glaubt Die Datenbanksysteme der 60er Jahre (netzwerkartige, hierarchische und Codasyl-Systeme ohne Ausnahme) schufen tatsächlich irgendwann gewisse Formen der Unabhängigkeit von physischen Datenstrukturen, bauten aber wesentlich
schwerwiegendere Abhängigkeiten dadurch wieder auf, daß sie die Beziehungen logischer Natur der Daten untereinander durch physische Zeiger innerhalb der Benutzerdaten darstellten.
Damit wurde eine einzige Sicht eines Anwenders physisch festgeschrieben. Es hegt auf der Hand, daß eine hiervon abweichende Sicht nicht mehr bereitgestellt werden kann, ohne die bestehenden Strukturen - und somit auch bestehende Sichten - erheblich zu modifizieren.
Aus diesem Blickwinkel sind Zweifel berechtigt ob Netz- oder Hierarchiesysteme überhaupt als Datenbanksysteme zu bezeichnen sind. Besonders gravierend wirkt sich bei diesen Systemen nämlich die durch die physische Struktur ungewollt aufgebaute Abhängigkeit zwischen Daten und Programmen aus
Die definierte Struktur muß dem Anwenderprogramm wohlbekannt sein; es muß diese kennen, um durch diese Struktur gemäß seinem logischen Auftrag navigieren zu können Das Anwendungsprogramm muß wissen, bei welchen Satztypen es in Abhängigkeit von Speicherungsformen einsteigen darf beziehungsweise welche Kettform diesen Satz in die Datenbank bindet
Pointer weisen Kapazitätprobleme
Daraus folgt daß es jegliche physische Strukturierung zu vermeiden gilt da eine solche von jeder Anwendung her gesehen unterschiedlich ausfallen müßte. Darüber hinaus werden diese durch Pointer erzeugten physischen Strukturen meist derart komplex- und problembeladen, daß keineswegs Entwicklungskapazitäten für die Anwendung frei, vielmehr neue Kapazitäten in häufig gigantischem Umfang im Personal- und Maschenbereich vonnöten werden, um die Datenbank grundsätzlich zu ermöglichen und mit Leben zu erfüllen.
Derartige Überlegungen führen dann konsequent zu relationalen Datendarstellungen ohne strukturierende Informationen. Dateien ihrer arlereinfachsten Form sind zweidimensionale Tabellen, auch Flat Files genannt, die ihrerseits aus Reihen (Datensätzen oder Tuples) und Kolonnen (Feldtypen oder Domains) bestehen.
Eine solche relationale Darstellung (1 Normalform) weist im Modell folgende Eigenarten auf:
1.) Eine Datenbank besteht aus n Tabellen (Flat Files).
2.) Jede Datenbank besteht aus beliebig vielen Kolonnen und Reihen in einheitlichem Aufbau; Wiederholungsfelder sind nicht gestattet.
3.) Kolonnen sind eindeutig benamt.
4.) Kolonnen und Reihen können zu jedem Zeitpunkt in beliebiger Folge und beliebigem Umfang ohne Einfluß auf Informationsinhalt und bestehende oder künftige Anwendungen gesehen werden.
Projektionen-Kollektion
Letzteres bedeutet, daß jeder Anwender seine individuelle Sicht (= "Projektion") einer Datei hinsichtlich Inhalt und Folge hat. Die logische Strukturierung erfolgt durch eine Definition außerhalb der physischen Daten und besagt, welche Daten aus welchen Dateien die für eine Anwendung relevanten Informationen enthalten.
Auf diese Weise sieht der Anwender lediglich eine einzige logische Datei, ohne Kenntnis darüber zu haben wie sich diese Daten physisch zusammensetzen. Das aber bedeutet echte beziehungsweise logische Datenunabhängigkeit und wird im Relationenmodell als "Join" bezeichnet.
Codd formuliert: "Both the application programmer and the interactive user view the data base as a timevarying collection of normalized relations oft assorted degrees." "Degree" bedeutet in diesem Fall den Grad der Relation; eine Relation mit n Domains wird als "of degree n" oder als "n-ary" bezeichnet.
Damit eröffnet sich eine völlig neue Dimension an Einfachheit und Flexibilität. Das Design einer solchen relationalen Datenbank beschränkt sich im wesentlichen auf den Entwurf einfacher sequentieller Dateien mit entsprechenden Schlüsseln. Die Datenstrukturierung verliert ihre Schrecken, da sie nur noch auf logischer Ebene stattfindet.
Flat Files allenthalben
Selbst komplexeste Strukturen können auf diese Weise dargestellt werden. James Martin sagt hierzu in Principles of Data Base Management: "It sometimes comes as rather shock to the conventional database specialist steeped in tree or plex structures to hear that all files can be represented as flat files."
Mit dieser keineswegs neuen Erkenntnis werden Datenbank-Entscheidungen zugunsten von Netz-Hierarchie- oder Codasyl-Systemen nur noch schwer begreiflich. Sind der. artige Entscheidungen dann auch noch mit dem hierarchischen Charakter der Unternehmensdaten oder der Verfügbarkeit von Anwendungs-Software des Hardware-Herstellers begründet, ist die politisch-nostalgische Verbrämung offensichtlich.
Hierarchie, Netzwerk und Relation sind keine objektiven Alternativen allenfalls unterliegen sie einem persönlichen Geschmack -, sondern zeitliche Entwicklungsabschnitte in genau dieser Reihenfolge. Diese Erkenntnisse sind umstrittig; auch herrscht allgemein Übereinstimmung darin, daß die Datenbank-Zukunft relational sein wird.
An dieser Stelle möchte ich der häufig geäußerten Darstellung widersprechen, eine relationale Datenbank gebe es noch nicht. Datacom/DB beispielsweise, das System des von mir vertretenen Hauses ADR, bietet die vorgenannten Eigenarten in weitgehendem Umfang bereits heute. Zur Manipulation der Relationen im Coddschen Sinne fehlt die Join-Funktion ebenso wie eine relationale Sprache (relational calculus).
Beides jedoch ist durch ADR angekündigt. Datacom/DB wird noch in diesem Jahr eine vollwertige Join-Funktion erhalten; der relationale Calculus hierzu wird "Ideal" heißen.
Kontinuitätsparole
Auch der Marktführer beschäftigt sich seit geraumer Zeit mit relationalen Datenbanken und konzipiert diese als einzig gangbaren Weg in die Zukunft. Um die vorhandenen Anwender hierarchischer Systeme nicht zu verschrecken, beschwört er die vielzitierte "Kontinuität durch Aufwärts-Kompatibilität", Wenn dann einer seiner Software-Entwickler genau diese Kompatibilität bestreitet, erläutert ein Vertriebschef im nachhinein, was der Entwickler wirklich meinte.
Der einzig ernstzunehmende Einwand gegenüber relationalen Datenbanken bestand in einer ursprünglich vermuteten geringeren Performance. Hierzu führt R. S. Barnhardt in "Datamation" vom Oktober 1980 aus: "The relational design can produce substantial improvements in performance over network and hierarchical design".
Dies wird in der Praxis durch Datacom/DB unterstrichen. Uneingeschränkte Multithread-Fähigkeit und der Verzicht auf Hersteller-Zugriffsmethoden qualifizieren Datacom als das nach unserer Einschätzung heute leistungsfähigste System im Hinblick auf Durchsatz, Transaktionsraten und Datenvolumina.
Wolfgang Mudter ist Prokurist der Applied Data Research (ADR) Deutschland GmbH und von der Stuttgarter Niederlassung aus für den Vertrieb der Datacom-Produktreihe zuständig.