"Ist ein Datenbanksystem relational, dann ist es auch gut." Diese simplifizierende Vorstellung hat sich bereits bei vielen Anwendern eingenistet. Es gibt jedoch keinen Bedarf an relationalen DB-Systemen an sich, vielmehr besteht ein starker Bedarf an flexiblen und leicht bedienbaren Datenbanken.
Die "Vertrauensseligkeit" der Anwender hat denn auch dazu geführt daß die Bezeichnung "relational" im Produktmarketing gern mißbraucht wird: Die Produkte werden vielfach nur mit einer "relationalen Tünche" überzogen. Dabei nehmen es die Marketingstrategen mit den relationalen Eigenschaften und erst recht mit den notwendigen technischen Qualitäten nicht so genau. Dann entstehen solch wohlklingende Wortkreationen wie beispielsweise "hybrid-relational ".
Heikle Muß-Werte in den Coddschen Kriterien
Es ist deshalb verständlich, daß Ted Codd als der Vater des relationalen Modells Kriterien erarbeitete, nach denen die Relationalität eines DBMS gemessen werden kann (siehe CW Nr. 15 bis 17, jeweils Seite 12). Dabei stellte er auch einige heikle Muß-Werte auf.
Das Relationen-Modell enthält eigentlich nur Regeln für die Organisation und Manipulation von Daten als Mengen. Warum aber ein DBMS, um relational zu sein, einen Katalog benötigt, in den die Definitionen als Zeichenstrings abgelegt sein müssen, leuchtet nicht ein. Es ist in DV-Kreisen inzwischen allgemein akzeptiert, daß ein Data Dictionary für eine systematische Datenverwaltung erforderlich ist - und das nicht nur beim DB-Einsatz. Aber ein Katalog, wie er etwa bei DB2 vorhanden ist, stellt noch lange kein Data Dictionary dar.
Erstrebenswert wäre vielmehr ein DBMS mit integriertem Data Dictionary. Dabei ist es erfahrungsgemäß wichtiger, daß dieses Data Dictionary statt mit der formalen SQL-Sprache besser mit maskengestütztem Dialog bearbeitet werden kann, um den Aufbau und die Administration auch für den Endbenutzer zu erleichtern.
Verantwortung wird auf die Benutzer abgeschoben
Auch die korrekte Einhaltung der Coddschen Anforderungen ist noch keine Garantie dafür, was das relationale Konzept eigentlich bewirken soll, nämlich ein fernwirkungsfreies Datenmodell. Zum Beispiel stellt kein relationales DBMS sicher, daß die Daten wirklich normalisiert abgespeichert sind, oder daß jede Tabelle einen eindeutigen Primärschlüssel besitzt, was die Regel des garantierten Zugriffs aber voraussetzt. Dies liegt noch immer in der Verantwortung der DV-Mitarbeiter, die somit um eine entsprechende Ausbildung in Methoden der Datenanalyse und -modellierung nicht umhinkommen.
Die Erfahrungen mit realationalen DB-Systemen zeigen, daß im praktischen Einsatz auch mit nicht-normalisierten Strukturen und Redundanzen gearbeitet werden muß. Gerade unter diesen Gesichtspunkten wäre es sogar nützlich, wenn ein DBMS auch nicht-relationale Strukturen wie multiple Felder unterstützt. So lassen sich immer wiederkehrende Probleme besser lösen als durch Aufsplitten in eine Vielzahl von Kleintabellen und Join-Operationen bei jeder Benutzung.
Allerdings muß sich der Anwender über Schwachstellen im klaren sein die er mit nicht-normalisierten Strukturen schafft. Obwohl das Relationen-Modell das Wissen um die Daten und die Verantwortung dafür den Endbenutzern nehmen will, wird nämlich bei den heutigen relationalen DB-Systemen eine wichtige Aufgabe in die Verantwortung der Enduser und deren Programme übertragen: die Integritätskontrolle. Und dieser Aspekt sollte mehr als nur ein Zwölftel der DB-Bewertungskriterien ausmachen, wie sie von Ted Codd aufgestellt wurden.
Anwender nennen erfahrungsgemäß meist zwei Aspekte als die wichtigsten Auswahlkriterien für ein DB-System: Flexibilität und Handhabung. Flexibilität beinhaltet sowohl leichte Anpaßbarkeit der Datenbank als auch Datenunabhängigkeit. Einfache Handhabung umfaßt Implementierung, Programmierung und Administration. Das Relationen-Modell bietet zwar die theoretische Grundlage zu DB-Systemen mit hoher Datenunabhängigkeit und leichter Handhabung, sagt aber nichts über die technische Realisierung aus.
Doch für die Praxis ist die technische Realisierung entscheidend. Es ist beispielsweise ein wesentlicher Unterschied für den Anwender, ob die Ergänzung eines neuen Feldes die sich einfach mit dem Befehl "alter table" formulieren laßt, auch nur zu einer einfachen Änderung im Directory des DBMS führt, oder ob danach alle betroffenen Sätze mühsam expandiert werden müssen. Ebenso spielt es eine Rolle für den Benutzer, wie die sich aus dem Relationen-Modell ergebenden komplexen Selektionsoperationen technisch abgewickelt werden und welche Auswirkungen das hat.
Relationale DB-Systeme mit User-Wünschen im Einklang
Das Relationen-Modell beschreibt wichtige Grundeigenschaften der Datenorganisation und -behandlung. Und in der Tat kommen relationale Datenbanken den Anwenderforderungen nach flexiblen und leicht handhabbaren Systemen derzeit am nächsten. Dennoch reicht es für einen erfolgreichen DB-Einsatz noch lange nicht aus, wenn ein System relational ist; es müssen auch leistungsfähige technische Lösungen dahinter stecken. Dabei ist es müßig, zu diskutieren, ob ein DBMS alle akademischen Forderungen an ein relationales System erfüllt - entscheidend ist seine Praktikabilität.
*Michael Bauer ist Geschäftsführer der Innova Forum GmbH, Radolfzell.