Eine relationale Datenbank gilt heute bei vielen DV-Profis als die triviale Lösung für alle anstehenden Probleme der Informationsverarbeitung. Nicht zuletzt deshalb, weil auch Anbieter relationaler DBMS-Technologien diese Meinung durch unbegründete Versprechungen schüren. Daß dem nicht so ist, müssen allzu vertrauensselige Anwender spätestens dann erfahren, wenn sie ihre ersten Schritte mit Hilfe eines der vielgepriesenen Produkte wagen.

Beim praktischen Einsatz gibt es dann unerwartet Performance-Schwierigkeiten, Integritätslücken, Flexibilitätsprobleme, Änderungs-, Lösch- und Einfüganomalien - und Unverständnis beim Endbenutzer; alles verursacht durch wieder denormalisierte Datenstrukturen im Rahmen des physischen DB-Design-Prozesses. Da erhebt sich zum x-ten Male die Frage, warum ein Unternehmen denn überhaupt eine relationale Datenbank einsetzen sollte. Rechnet sich der Aufwand?

Zunächst nur zwei Gründe für den Einsatz eines relationalen Datenbank-Management-Systems (DBMS): Die Verbesserung der Effizienz der DV-Profis (Datenadministration, Programmierung, Implementierung, Wartung . . .) und die Unterstützung "Enduser"-orientierter Systeme (IDV).

Es bleibt unbestritten, daß relationale Systeme beide Aufgaben, abhängig vom jeweiligen DBMS-Hersteller, auf unterschiedlichste Art zu lösen in der Lage sind. Grundsätzlich gilt auch, daß auf relationaler Basis konzipierte Produkte positive Schritte in beide Richtungen darstellen. Aber nur wenige Produkte sind gemessen am relationalen (Coddschen) Modell vollständig oder für einen operationalen Einsatz leistungsfähig genug. Sie verlangen deshalb in der Phase der Implementierung des logischen Datenmodells (= physisches DB-Design) geeignete, auf die Fähigkeit des eingesetzten DBMS abgestimmte Maßnahmen und Regeln, die auch vor einer Verfälschung ("Denormalisierung") der logischen Datenstruktur nicht haltmachen (siehe Abbildung 1).

Eigentlich verlangt nur das physische DB-Design aufgrund von Schwächen des eingesetzten (relationalen) Datenbank-Management-Systems und hohen Anforderungen durch die Benutzer nach den genannten Vorgehensweisen. Die Gründe für eine Verfälschung des logischen Datenmodells sind vielfältig. Dazu gehören beispielsweise ein möglichst hoher Durchsatz im Umfeld operationaler Anwendungssysteme, nicht relationale DBMS-Architektur oder Migrationsaspekte.

Oft werden relationale Datenbank-Management-Systeme auch nur als bessere "File-Systeme" mißbraucht - eine der teuersten Einsatzmöglichkeiten solcher Software.

Die Folgen für die Struktur der operationalen Informationsumgebung gleichen sich: Die Informationsstruktur auf der physischen Ebene ist keine 1:1-Abbildung des flexiblen, stabilen, nach den Coddschen Regeln entwickelten logischen Datenmodells.

Für einen "Enduser" ergeben sich daraus möglicherweise fatale Konsequenzen: Zunächst einfache Informationsstrukturen werden wieder zu komplex für eine effiziente individuelle Informationsverarbeitung. Oder richtige Fragestellungen an die DB führen zu falschen Antwortmengen: Semantische Diesintegrität nennt der Fachmann dies. Alles nur, weil Datenbeziehungen, die zunächst im Analyseprozeß erkannt worden waren, zugunsten der Performance wieder ignoriert werden mußten? Der Benutzer kann mit einer solchen Lösung auf die Dauer nicht glücklich werden.

Drei Mißverständnisse, die häufig auch vom Management an den Endbenutzer herangetragen werden - mögen sie nun von Herstellervertretern oder von DV-Gurus gesät worden sein - sollen beispielhaft zeigen, daß aus den genannten Gründen auch das DB-Design mit relationalen Datenbanksystemen das bleibt, was DB-Design immer war: Ein schwieriger, komplexer Vorgang, der Erfahrung und Abstraktionsvermögen von den Beteiligten verlangt und der keineswegs als trivial bezeichnet werden kann.

Mißverständnis Nr. 1:

Das Design relationaler Datenbanken ist einfach, weil es lediglich eine 1:1-Abbildung der im logischen DB-Design evaluierten normalisierten Relationen auf physische DBMS-Tabellen bedeutet.

Realität:

Das DB-Design für relationale Datenbanken kann sich als äußerst komplex herausstellen, weil die am Markt befindlichen Produkte keine Mechanismen zur Abbildung von Unternehmens- oder Geschäftsregeln ("Business Rules", "Integrity Rules"), die die Daten unmittelbar betreffen, anbieten. Soweit irgendwie möglich, wird deshalb versucht, solche Regeln beispielsweise anhand von "physischen Links", automatischer Aktivierung zentraler funktionaler Algorithmen, über ein Unterprogramm oder mittels "Makros" abzubilden.

Im Augenblick stellt eine relationale Datenbank nichts anderes dar als eine Ansammlung von Tabellen, die aus Zeilen (Rows) und Spalten (columns) bestehen. Jede Zeile enthält dieselben Typen an Spalten in derselben Reihenfolge; jede Spalte ist homogen (semantisch eindeutig) mit den Werten aus dem jeweiligen Wertebereich (Domain) besetzt. Schlüssel werden über "Columns" gelegt, um Durchsatzaufforderungen einer Applikation besser erfüllen zu können (oder auch um die Eindeutigkeit der jeweiligen Zeile innerhalb der Tabelle sicherzustellen, entspricht der "Primary-Key"-Regel, im Relationenmodell).

Eine relationale Datenbank soll aber, ebenso wie eine nicht-relationale Datenstruktur, von einem logischen Datenmodell abgeleitet werden. Nur das logische Datenmodell garantiert eine stabile, einfache und trotzdem flexible Darstellung der Informationen in einer "Benutzer-, Programm- und Physik-Unabhängigen Form". Diese konzeptionelle (logische) Datenstruktur genügt den oben genannten Anforderungen nur dann, wenn sie sich in einem normalisierten Zustand (dritte Normalform) präsentiert. Eine Hauptregel für die Normalisierung lautet: "One Item in One Place".

Das logische Modell spiegelt auch datenabhängige Unternehmensregeln wider. Sie sind immer dann gültig, sobald diese Daten von einem Benutzer bearbeitet und/oder von einer Anwendung benötigt werden. Sie sind nicht vom jeweiligen Vorgang abhängig. Die Regeln beschreiben Zielbestimmung und unternehmensindividuelle Abhängigkeitsart der betreffenden Informationen. Sie sind mit den Daten von deren Bedeutung für das Unternehmen her eng verbunden, egal, welche Benutzer oder Applikationen mit diesen Informationen arbeiten und wie sie es beabsichtigen zu tun.

Solche Datenelemente besitzen eine implizite existentielle Semantik, haben also eine unternehmensweite Bedeutung, eine Verwendungsbestimmung und bestimmte Abhängigkeitsregeln. Diese Semantik könnte bei relationalen DB-Systemen über die Fähigkeit "Business Rules" zu verarbeiten implementiert werden. Hinter "Business Rules" aber können sehr komplexe Zusammenhänge im Unternehmen stecken (siehe Kasten).

Die Analyse, Erkennung und Festlegung solcher Regeln aber, ebenso wie die Beschreibung ihrer semantischen Bedeutung, ist eine Aufgabe eines funktionierenden Datenmanagements.

Fazit:

Egal ob ein Applikationsprogramm oder ein Enduser auf die den Regeln unterliegenden Daten zugreift - diese Regeln müssen in jedem Fall wirksam werden.

Über die vielzitierte "Referential Integrity"-Implementation sollen relationale Datenbank-Management-Systeme Mechanismen anbieten, die es zulassen ein Minimum datenabhängiger "Business Rules" auch auf physischer Ebene in die analysierten Informationsstrukturen einbringen zu können und zur Laufzeit automatisch wirksam werden zu lassen.

Eng mit der Erkennung und Darstellung der "Business Rules" im Rahmen der Informationsanalyse hängt auch die Unterstützung von Datenmanagementfunktionen über die DBMS-Umgebung zusammen, kann heißen: Integriertes fachlich orientiertes Data-Dictionary.

Unglücklicherweise liefern die meisten relationalen DB-Systeme keine Funktion in diese Richtungen.

Mißverständnis Nr. 2:

Angenommen, die physische Datenbasis eines reIationalen DBMS wäre lediglich die 1:1-Umsetzung der logischen Datenstruktur, dann bliebe die Struktur der (physischen) DB vollkommen unabhängig von Applikationen und Verarbeitungsanforderungen.

Realität:

Der Entwurf relationaler Datenbanken auf der physischen Ebene ist keinesfalls unabhängig von späteren Verarbeitungsanforderungen durchführbar, da das (physische) Design immer noch Schwächen einer existierenden relationalen Sprach- und Verarbeitungsumgebung ausgleichen muß.

Betrachtet man das logische Datenmodell als die Repräsentation der relevanten Daten, ihrer Beziehungen und der anzuwendenden Unternehmensregeln, so geschieht dies immer unabhängig von der endgültigen physischen Implementierung und ebenso unabhängig von Verarbeitungsvorgaben. Deshalb kann ein logisches Datenmodell unter Anwendung von einfachen Transformationsregeln zum Beispiel in eine "ungetunte" DB2-, IMS- oder IDMS-Datenbank überführt werden.

Die wenigsten der heute auf dem Markt verfügbaren Datenbank-Management-Systeme - ihre Sprachen eingeschlossen - sind so leistungsfähig, daß sie Daten den Benutzerwünschen entsprechend beliebig schnell manipulieren können. Derartige Systemdefizite werden über geeignete Transformationsregeln aufgefangen. So versucht man zugunsten der Performance immer wieder zunächst normalisierte Strukturen (Relationen) auf der physischen DB zusammenzufassen, um so die I/O-Vorgänge des DBMS zu minimieren und Engpässe bei den System-Ressourcen zu vermeiden.

Einige Regeln innerhalb der Daten eines "High-Tech "-Unternehmens sollen diese Problematik beispielhaft verdeutlichen:

- Jeder Unternehmensbereich hat eine UB-NR, UB-NAMEN und eine STANDORT-ADRESSE

- Einige Mitglieder eines UB sind technisch-wissenschaftliche Mitarbeiter, und jeder von ihnen ist verantwortlich für ein (eindeutiges) Forschungsprojekt, das über eine PROJEKT-NR identifiziert wird.

- Einige der Mitarbeiter des UB sind Instruktoren. Sie müssen sich für einen bestimmten Bereich qualifiziert haben, Benutzern beziehungsweise Kunden die Resultate der "High-Tech"-Forschung nahebringen. Ihr Spezialgebiet ist gekennzeichnet durch einen FACH-CODE.

In diesem Beispiel bilden technisch-wissenschaftliche Mitarbeiter und Instruktoren eine sich gegenseitig ausschließende Menge an Unternehmensangehörigen: Ein Instruktor arbeitet niemals auch als Entwickler und umgekehrt.

Die Frage ist: Wieviele Relationen müssen gebildet werden, ohne die dritte Normalform zu verletzen?

Lösung 1: drei Relationen

MlTARBEITER : mit PERS-NR, NAME, ADRESSE, ABTEILUNG

T/W-MITARB. : mit PERS-NR, PROJEKT-NR

INSTRUKTOR : mit PERS-NR, FACH-CODE

Lösung 2: zwei Relationenen

T/W-MITARB. : mit PERS-NR, NAME, ADRESSE, ABTEILUNG, PROJEKT-NR

INSTRUKTOR : mit PERS-NR, NAME, ADRESSE, ABTEILUNG, FACH-CODE

Lösung 3: eine Relation

UB-MITARBEITER : mit PERS-NR, NAME, ADRESSE, ABTEILUNG, PROJEKT-NR,

FACH-CODE

(Anmerkung: PROJEKT-NR ist NULL bei Instruktoren, FACH-CODE ist NULL für T/W-MA).

Lösung 2 bietet sich dann nicht an, wenn ein Anwender alle Mitarbeiter eines Unternehmensbereichs abfragen will und das verwendete relationale Produkt die UNION-Operation nicht anbietet.

Lösung 3 ist nicht möglich, wenn das eingesetzte relationale Produkt NULL-Werte-Verarbeitung nicht unterstützt. Angenommen, man will die Eindeutigkeitsregel auf die Projekte anwenden, und bildet deshalb einen Index über die PROJEKT-NR, so kann diese Eindeutigkeit genau dann nicht erreicht werden, wenn ein relationales DBMS-Produkt annimmt, ein Tupel mit NULL-Wert sei gleich einem beliebigen anderen Tupel mit NULL-Wert im Attribut PROJEKT-NR.

Es kann nämlich eine Reihe von Tupeln (Zeilen) mit NULL-Wert im Feld PROJEKT-NR geben - bei allen Instruktoren beispielsweise. Wenn das einqesetzte DBMS-Produkt NULL-Wert-Verarbeitung nicht zuläßt, so kann ein eindeutiger Index nicht gebildet werden, da die NULL-Wert-Felder in diesem Fall mit irgendeinem anderen Wert substituiert werden, zum Beispiel mit "0".

Sollte die PROJEKT-NR als Primärschlüssel der Relation dienen, so ist von vornherein ein Verstoß gegen das Coddsche Relationenmodell gegeben ("Primary-Key"-rule).

Mißverständnis Nr. 3:

Relationale Datenbanken sind einfach zu "tunen" und zu modifizieren.

Realität:

Relationale Datenbanken sind normalerweise einfacher zu optimieren als nicht-relationale DBs. Dennoch bedürfen diese Aktivitäten immer noch einer sorgfältigen Planung.

Viele relationale Systeme erlauben die dynamische Modifikation und Neudefinition von relationalen Datenobjekten (tables) während des laufenden Betriebs. Diese Systemverwaltungsfunktionen schließen das Hinzufügen neuer Spalten, neuer Tabellen, neuer Indizes oder neuer "Views" mit ein. Dennoch gibt es Modifikationen, die dynamisch durchgeführt, während des laufenden Betriebs schlichtweg nicht zu empfehlen sind.

Dazu ein Beispiel: Angenommen ein LEHRER lehrt mehrere KURSE, und jeder KURS wird nur von einem bestimmten LEHRER unterrichtet. Mit anderen Worten: Es existiert eine 1:m-Beziehung zwischen den Objekten KURS und LEHRER. Das Objekt KURS enthält die Attribute LEHRER-NR, KURS-NR, RAUM-NR, TAG, ZEIT.

Nun ändert sich die "Business Rule" über LEHRER und KURS insofern, als ein KURS künftig von mehr als einem LEHRER unterrichtet werden soll ("Teambildung"). Es entsteht eine neue Bezieung zwischen KURS und LEHRER-Objekt, eine n:m-Beziehung (siehe Abbildung 2).

Ist die Implementierung dieser neuen Beziehung in einer relationalen Datenbank einfach?

Der modifizierte Teil des logischen Modells zeigt jetzt plötzlich drei Relationen auf:

LEHRER: LEHRER-NR, FACH-CODE

KURS: KURS-NR, TAG, ZEIT, RAUM-NR

EINSATZPLAN: LEHRER-NR, KURS-NR

Lösung:

1) Erzeugen der neuen Tabelle EINSATZPLAN

2) Festlegen der neuen "Business Rules" zwischen LEHRER, KURS, EINSATZPLAN

3) Sperren (DROP) der LEHRER-NR-Spalte aus der KURS-Tabelle

4) Modifikation aller "Views", die auf der Basis dieser Daten gebildet werden.

Diese Modifikationen berühren alle den zur Laufzeit aktiven DBMS-Katalog (siehe DB2) und können zu einem erheblichen Performance-Verlust während der Änderungsaktionen führen, falls diese im laufenden (Produktions-) Betrieb durchgeführt werden: Den Engpaß dabei bildet der DBMS-Katalog!

FAZIT:

Auch das Design relationaler Datenbanken ist nicht so einfach wie es zunächst scheint.

Die Verbesserung in der Produktivität des IV-Betriebs hängt einerseits von den Fähigkeiten des DBMS ab, DB-Objekte und physische DB-Tabellen dynamisch definieren und modifizieren zu können, und von der Möglichkeit, das logische Datenmodell in die physische Ebene direkt übertragen zu können. Die Mächtigkeit relationaler Sprachen führt wiederum zu einer erheblichen Produktivitätssteigerung im Anwendungsentwicklungsprozeß. Angestrebte Produktivitätsgewinne sollten jedoch nicht auf Kosten der Erkenntnis aus der Datenanalyse gehen.

Die Endbenutzerorientierung relationaler DB-Systeme andererseits ergibt sich zunächst aus der Einfachheit des relationalen Konzepts und der damit verbundenen Datenstrukturen. Die Zeit, die in System- und Informationsanalyse investiert werden muß, sichert diese Endbenutzerorientierung nur dann genügend ab, wenn die aufgedeckten "Business Rules" auch de facto in der physischen DB-Struktur verankert werden können.

Heute sind die meisten relationalen DB-Systeme noch nicht einmal in der Lage, die einfachsten Grundsätze referentieller Integrität ( "Ownermember"-Beziehungen) zu verarbeiten. Daraus folgt, daß "Business Rules", wo immer notwendig, in die Applikationsprogramme verlagert werden müssen.

Mögliche Folgen im Falle von Änderungen sind leicht erkennbar.

Die Einbindung relationaler DB-Systeme und ihrer Sprachen in eine "gesunde", methodisch wie praktisch ausgereifte und leistungsfähige Entwicklungsumgebung (4GL-Umgebung mit DDS und Hochsprache?) kann die heute noch auftretenden (DBMS-) Schwächen und daraus resultierende (Denormalisierungs-) Maßnahmen für die Zukunft transparent halten. Sie läßt bei zunehmendem Reifegrad relationaler DBMS spätere Änderungen mit vertretbarem Aufwand möglich werden.

Einfache Beispiele von "Business Rules"

-Ein Kunde kann solange nicht aus dem Kundenverzeichnis gestrichen werden, solange noch ein offener Auftrag von ihm existiert, dessen Bearbeitung den Status "offen" trägt. (Lösch-Regel)

-Ein neuer Auftrag wird durch eine Auftragsnummer, die eindeutig und nicht "null"* ist, identifiziert. (Eindeutigkeitsregel)

-Eine Auftragsnummer ist ein dreistelliger numerischer Wert zwischen 100 und 999 (Wertebereichsregel)

-Neu-Kunden werden aufgrund des Gebiets, in dem sie ihren Sitz haben, automatisch einem entsprechendem Filial-Leiter zugewiesen ("Default"-Regel)

-Ein Auftrag für einen Kunden, der weder dem DB-System noch dem Unternehmen bekannt ist, kann nicht in der Datenbank abgelegt werden (Einfüge-Regel)

Es gibt eine Reihe weiterer Geschäftsregeln, die die Integrität der Daten und deren Semantik im logischen Datenmodell beeinflussen beziehungsweise festlegen. Idealerweise werden solche Regeln vom DBMS unterstützt und ihre Einhaltung dort überwacht. In nicht-relationalen Systemen werden solche Regeln über die Datenbankstruktur überwacht ; so etwa Physische "Links", Schema-Optionen, IMS-Lösch-/Einfüge Regeln.

Regeln, die nicht im DBMS implementiert werden können, sind üblicherweise in die Anwendungsprogramme verlagert.

* "null" ist nicht gleichzusetzen mit dem mathematichen Wert 0, sondern der informationstechnischen Aussage "kein Wert".