Die Gestaltung einer relationalen Datenbank ist vorwiegend eine Design-Aufgabe - denn auf der physikalischen Ebene ist die Datenspeicherung bedingt durch die heutige Technologie bei allen Datenbank-Systemen nahezu gleich. Der eigentliche Vorteil des Datenbank-Einsatzes liegt vielmehr darin, daß die Datenorganisation zweckmäßigerweise aus verarbeitungstechnischer Sicht und nicht aus physikalischen Aspekten gestaltet werden muß. DB/DC-Systeme führen inzwischen mit ihren speziellen Abfragesprachen zu eindeutigen Verarbeitungsvorteilen für den Endbenutzer.
Die Entwicklung eines betrieblichen Informationssystems ist ohne Einführung einer Datenbank oder der Nutzung eines Datenbank-Systems nicht möglich. Datenbank-Systeme sind seit vielen Jahren in unterschiedlichen Entwicklungsstufen in Gebrauch. Die ersten Datenbank-Systeme wurden in den 60er Jahren von allen größeren DV-Herstellern auf den Markt gebracht.
Im Jahre 1968 wurde seitens der Codasyl-Konferenz (Conferenz on Data System Languages, ein Zusammenschluß von DV-Herstellern und Anwendern) ein Vorschlag entwickelt, der zu einer Standardisierung der Datenbank-Systeme führte. Diese standardisierten Systeme haben gemäß dem Codasyl-Vorschlag folgende Eigenschaften:
- Die Realisierung von vernetzten Datenbanken mit adreßmäßiger Verknüpfung logischer Zugriffswege muß möglich sein.
- In vielen Fällen ist die Verknüpfung der Daten nicht sinnvoll. Aus diesem Grunde ist es notwendig, neben den verketteten Daten die Darstellung von sogenannten "inverted files" zu ermöglichen. Aufgrund von Schlüsseln (Suchbegriffen) werden die zu diesem Suchbegriff gehörenden Daten in einer Tabelle abgelegt und können jederzeit schnell wieder aufgefunden werden. Dies ist auch das Grundprinzip der relationalen Datenbank-Systeme.
Zu Beginn der 70er Jahre veröffentlichte CODD eine grundlegende Arbeit über das "Relational Data Base Modell". In dieser Studie wurde darauf hingewiesen, daß diesem Modell die Zukunft gehören wird.
In den letzten ein bis zwei Jahren wurde die Idee des relationalen Datenbank-Modells von verschiedenen DV-Herstellern aufgegriffen und durch Ankündigungen auf dem Hard- und Software-Sektor so dargestellt, als ob das Design einer relationalen Datenbank in erster Linie ein Software-Problem sei. Diese Aussage ist falsch: Die derzeitige Hardware-Technologie der Von-Neumann-Computer läßt die Datenspeicherung und -wiederauffindung nur auf der Basis physikalischer Adressen zu. Das heißt, jedes Datum, das auf einem externen Plattenspeicher abgelegt wird, kann nur mittels der dem Datum zugeordneten Adresse abgelegt und auch wieder aufgefunden werden. Jedes System, gleichgültig ob es sich um ein herkömmliches Datenzugriffssystem des Betriebssystems handelt oder um ein Datenbank-System, muß also generell die Adresse des Datums kennen, bevor es ein Datum speichern oder wieder auffinden kann.
Relational auf "Inverted file"-Basis
Das bedeutet, daß der Grundgedanke des relationalen Datenbank-Modells auf der physikalischen Ebene zur Zeit nicht realisierbar ist. Der Grundgedanke des relationalen Modells beinhaltet das Ablegen und Wiederauffinden der Daten ausschließlich nach den Suchargumenten und damit werteorientiert. Das heißt, die Daten sollen nicht über eine umgerechnete Adresse, sondern direkt über das entsprechende Suchargument gefunden werden können. Die derzeit einzige technische Realisierung besteht auf der Basis von "inverted files".
Aufgrund dieser Sachlage kann festgehalten werden, daß zum heutigen Zeitpunkt Software- und Abfrage-Sprachen existieren, die relationale Datenbanken auf der logischen Seite ermöglichen. Auf der physikalischen Seite haben wir es immer mit einer Datenspeicherung zu tun, die keinerlei Unterschiede zwischen herkömmlichen Dateien, "hierarchischen Datenbanken" "Codasyl-Datenbanken" oder "relationalen Datenbanken" macht.
Um nun relationale Datenbanken beziehungsweise die Verarbeitung von Datenrelationen zu ermöglichen bedarf es einer grundlegenden organisatorischen Arbeit. Diese ist wiederum völlig identisch bei all den bisher angesprochenen Systemen. Es sind Datensätze zu erstellen, die grundsätzlich einen Ordnungsbegriff (Suchargument beziehungsweise Key-Attribute, wie dies beim Relation-Modell heißt) enthalten und dazugehörende Datenfelder, die zu diesem Suchargument in einer 1:1-Relation stehen. Jedes Datenfeld, das einem derartigen Datensatz zugeordnet wird, darf nur ein einziges Mal in einer Verbindung zu dem Suchargument stehen. Datenfelder, die zu einem Suchargument mehrfach vorhanden sind, sind jeweils in eigenen neuen Datensätzen mit neuen Suchargumenten unterzubringen. Eine so gestaltete Datenorganisation ist die Basis für jedwede Datenbank, unabhängig vom eingesetzten Datenbank-System und den dazugehörenden Sprachmöglichkeiten. Das physikalische Design (sprich: die Ablage der Daten auf den Plattenspeichern) muß dann den Möglichkeiten des eingesetzten Datenbank-Systems entsprechen.
Lange Antwortzeiten bei Realtime
Betrachten wir die heute in der Datenverarbeitung aufgebauten Dateien und Datensätze, so wird verständlich, daß die Organisation einer Datenbank eine generelle Neuorganisation der Datenbestände zur Folge hat. Nur in den seltensten Fällen ist eine Datei nach den oben erwähnten Kriterien aufgebaut. Im Regelfall sind die Datensätze nach rein physikalischen Gesichtspunkten mit mehrfachen und mehrdeutigen Beziehungen zwischen Suchbegriffen (Schlüsselbegriff) und den zugehörigen Datenfeldern aufgebaut.
Aus diesem Grunde ist eine unveränderte Übernahme bestehender Dateien in eine Datenbank nicht zu empfehlen, da dies aus informationstechnischer Sicht nicht zu vertreten ist. Dies führt unabhängig vom eingesetzten Datenbank-System zur Ausführungszeit unter Umständen zu erheblichen Zukunftsproblemen und damit zu unvertretbar langen Antwortzeiten im Realtime-Betrieb.
In der Praxis wird häufig so vorgegangen, daß die bestehenden Datenbestände 1:1 in eine Datenbank überführt und dem Datenbank-System unterstellt werden. Dies ist ein einfacher und unkomplizierter Weg, innerhalb kürzester Frist eine Datenbank zu erstellen. Solange auf diese Datenbanken nur wenige Benutzer zugreifen oder nur wenige Batch-Anwendungen mit diesem System laufen, führt dies im allgemeinen zu keinem Zugriffsproblem. Wird jedoch die Datenbank als das zentrale Informationsarchiv eingesetzt, so ist die informationsgerechte Organisation der Daten unerläßlich. In diesem Fall kommt es zur gleichzeitigen Nutzung durch eine Vielzahl von Realzeit- und Batch-Anwendungen, die alle beim Datenbank-System unter Umständen zu Zugriffskonflikten führen. Unvertretbar lange Antwortzeiten und Durchsatzprobleme sind die Folge. Um diese zu beseitigen, wird es notwendig, Tuning-Maßnahmen durchzuführen. Damit wird die Arbeit des logischen Datenbank-Designs in mühseliger Kleinarbeit nachgeholt.
Wird ein logisches Design erstellt und werden Datensätze entwickelt, die den Anforderungen eines "Relation-Modells" (nur 1:1-Relationen) entsprechen, so können diese jedem x-beliebigen Datenbank-System unterstellt werden. Dabei ist es völlig gleichgültig, ob man in Abhängigkeit von den hauptsächlichen Verarbeitungsanforderungen oder den Möglichkeiten des eingesetzten Datenbank-Systems diese Daten nun in Sets, Ketten oder in Tabellenform aufbereitet abspeichert.
Die so vorbereitete Datenbank kann dann mit den Benutzer-Abfragesprachen (Query-Languages) oder in Verbindung mit problemorientierten Programmiersprachen wie zum Beispiel Cobol, problemlos verarbeitet werden.