Die aktuelle Technik für Großrechner-Datenbanksysteme läuft seit Anfang der 80er Jahre unter dem Stichwort "relational". Jürgen Kalin* will aufzeigen, welche Datenbanksysteme die Informationsverarbeitung in den 90er Jahren prägen werden, und welche Anforderungen die Benutzer bereits heute stellen.
Nicht überall, wo "relational" drauf steht, ist "relational" drin. "Relationalität" ist für Einsteiger ein Schlagwort und verspricht bessere Datenverwaltung, Arbeitserleichterungen und auch High-Tech-Image. Für Anbieter ist es ein Marketing-Argument, das selbst alte Softwaretechnik mit neuem Glanz versehen kann.
Doch neben den schwarzen Schafen unter den Anbietern gibt es auch Hersteller, die den Coddschen Regeln für relationale Datenbanksysteme nacheifern. Noch kein Produkt scheint heute jedoch allen Haupt- und Nebenregeln ganz zu entsprechen, einige zeigen zumindest eine gewisse Annäherung, und ganz wenige können dem "Meister" folgen. In diesem Zusammenhang müßte geprüft werden, ob überhaupt alle Regeln von Codd als Regeln anerkannt werden sollen.
Welche Produkte sind im Markt, und welche sind - um mit einem K.o.-Faktor die Anzahl zu begrenzen - nicht nur per Definition relational? Obenan, zumindest in der Verbreitung, steht als Produkt DB2. Dahinter, und nahe den Forderungen des Datenbank-Gurus Codd, Supra und Oracle sowie als Newcomer im Großrechnerbreich, Ingres.
Für DB2 gilt, so ist oft zu hören: Was von IBM kommt, ist erst einmal gut. Der Hersteller-Bonus reicht aus. DB2-Anwender dagegen bemängeln die Verfügbarkeit für andere Netz- und Rechnerwelten. Sie stört, daß DB2 nur auf einem System, nämlich auf dem IBM-eigenen MVS läuft. Auf Portabilität muß der DB2-Anwender also verzichten. Doch gerade Portabilität ist für viele eine der wichtigsten Forderungen an ein modernes Datenbank-Management-System.
Während bei dir Hardware ein Lebenszyclus drei bis fünf Jahre anhält, wird die Anwendungssoftware durchschnittlich 15 Jahre genutzt. Das bedeutet, eine Generation Anwendungssoftware muß in der Regel drei Hardwaregenerationen überleben. Daraus ergibt sich die Forderung: Entweder bleibt die Hardware kompatibel oder die Software wird "portabel". Die Anpassung der Software ist die Lösung, die heute von Datenbankherstellern realisiert wird (siehe Checkliste).
Bei der Lösung des Portabilitätsproblems muß die Software herhalten. Auf Datenbank-Management-Systeme übertragen heißt, ein Datenbanksystem muß sowohl den Generationswechsel eines Herstellers überleben als auch dem Wunsch nach freier Herstellerwahl gerecht werden. Auch ein Wechsel des Betriebssystems soll und muß mit beachtet werden.
Portabilität schützt Software-Investitionen
Portabilität bedeutet konkret, daß Anwendungen nur einmal entwickelt und überall in einem Unternehmen auf zentralen Großrechnern, dezentralen Systemen sowie auf Arbeitsplatzsystemen verfügbar gemacht werden. Verfügbarkeit auf Rechnersystemen von IBM, Siemens oder DEC ist eine Minimalforderung. Wer das als Hersteller nicht garantieren kann und nicht zugleich Unix und OS/2 (MS-DOS) für die nähere Zukunft im Ärmel hat, der hat im DBMS-Bereich nichts verloren. Die Produkte sollen nicht nur unterschiedliche Rechner, sondern auch unterschiedliche Betriebssysteme und Netzwerke zu einem einzigen homogenen System zusammenfassen.
Portabilität bedeutet Schutz der Anwendungen und somit Schutz der Software-Investition. Dies freut insbesondere den Kaufmann. Und für den DV-Leiter und Einkäufer bedeutet Portabilität, daß sie frei und unabhängig in der Wahl der Hardware und im Hardware-Mix sind.
Die Verteilung soll eine lokale Transparenz garantieren. Das heißt, als Anwender soll es mich nicht interessieren, daß und auf welchem Rechner oder in welchem Netz die Daten verteilt sind. Wichtig ist daß die Anwendung funktioniert.
Auch muß das Datenbanksystem über verschiedene Rechner hinweg Updates innerhalb einer Transaktion ermöglichen. Dieser Forderung kommen nicht alle Hersteller nach. Viele hochgelobte und bekannte Produkte können Updates nur auf einem einzigen Rechner realisieren, weil es an der nötigen Datenintegrität fehlt.
Relationale Datenintegrität heißt auch Datenkonsistenz. Dafür steht beispielsweise das Primary-Key-Concept. Daß bedeutet, daß das relationale DBMS automatisch dafür sorgt, daß der Schlüssel einer Tabelle eindeutig ist und immer einen Inhalt hat. Das Domain-Concept unterstützt den Datenbank-Administrator bei der Definition von Attributen und deren Wertebereichen. Es können also für jedes Attribut Wertebereiche bestimmt werden. Nur Werte, die diesen Bereichen entsprechen, dürfen in der Datenbank abgespeichert werden. Das RDBMS muß diese überwachen beziehungsweise prüfen.
Die referentielle Integrität, die Beziehungen zwischen Tabellen, Foreign-Key- und Primary-Key-Konzept, soll nicht durch Programme, sondern durch das Datenbanksystem anhand extern definierbarer Integritätsregeln stattfinden.
Beispiel: In einer Personaltabelle mit Personalnummer und Abteilungsnummer darf nur dann etwas eingefügt werden, wenn es in der "Tabelle Abteilung" auch eine entsprechende Abteilung gibt. Ansonsten muß bei Bestellungen festgestellt werden, ob der Kunde und das entsprechende Produkt in der Datenbank existieren. Das Querprüfen zwischen Tabellen muß das RDBMS automatisch machen. Auch dürfen keine Produkte in einer Datenbank gelöscht werden, für die es noch Bestellungen gibt.
Die Frage nach der Verfügbarkeit oder dem Dauerbetrieb der Datenbank ist für viele Anwender wichtig. 24-Stunden-Betrieb heißt hier die Forderung, und sie bedeutet, daß Wartungsarbeiten während des laufenden Betriebs durchgeführt werden können, die Sicherungen der Daten jederzeit im Hintergrund ablaufen sollen oder über die Konfiguration die Anzahl der Buffer dynamisch veränderbar sein müssen.
Es muß gewährleistet werden, daß die Datenbank etwa bei Ausfall der Plattenbereiche bei Headcrashs verfügbar bleibt. Lösungen sind Spiegeldatenbanken oder das Doppelführen von Logfiles, wodurch die Datenintegrität und Datenkonsistenz auch nach Ausfall des Systems wieder hergestellt werden können.
Neben der Portabilität darf man als zweiten Schritt erwarten, daß das RDBMS in der Lage ist, die Verteilung in einem heterogenen System zu realisieren. Das System muß dies vom Design her können; viele DBMS sind heute aber noch nicht so weit.
Immer wieder stehen die Endbenutzer "kleine" Änderungs- oder Verbesserungswünsche an die "Spezialisten der DV-Abteilung". Moderne DBMS-Systeme bieten heute den weniger geübten Benutzer Möglichkeiten, selbst ans Ziel zu kommen. Pop-up-Menüs, Fenstertechnik oder Dialogformulare sollen die Benutzer selbst realisieren. Angeboten werden Werkzeuge, die dies ermöglichen. Bedienungsfreundlich können mit diesen Tools Datenbanktabellen geändert und kombiniert oder neue Tabellen definiert und erstellt werden.