Für viele Unternehmen gehört es heute zum "guten Ton", ein relationales Datenbankmanagementsystem einzusetzen. Bei der Produktauswahl tappen die Anwender jedoch oft im dunkeln. Die in der Fachliteratur propagierten Anforderungen an ein solches Informationssystem hat Wolfgang Ebinger* als Checkliste zusammengestellt. Der Abriß beschränkt sich auf einen Grundpfeiler dieser Architektur. nämlich das Datenmanagement.

Überwachungsmechanismen für simultan ablaufende Verarbeitungen

Moderne Systeme müssen eine simultan ablaufende Bearbeitung mehrerer Anforderungen leisten, ohne daß Integritäts- oder Sicherheitsauflagen verletzt werden und ohne daß es zu einem Leistungsverlust kommt. Zu den wichtigen Systemfunktionen, die untersucht werden müssen, gehören Multi-threading, Multi-tasking, Feststellung und Verhinderung von Systemstillstand (deadlock), I/0-Überlappung sowie zentraler Betrieb. Der zentrale Betrieb soll den gleichzeitigen Online- und Batchzugriff auf eine einzige Kopie des DBMS ermöglichen. Darin eingeschlossen ist Unterstützung für mehrere Online- und Batch-Tasks, die simultan Datenänderungen durchführen. Integrität und Recovery sind dabei sichergestellt.

Support für logische Transaktionen

Aus Performance- und Recovery-Gründen ist bei Online-Systemen die Unterstützung der Transaktionsverarbeitung unerläßlich. Hierbei sollte das Konzept der logischen Arbeitseinheit (LUW) verwendet werden. Denn es ist nicht akzeptabel, daß eine Wiederherstellung des gesamten Systems durchgeführt werden muß, nur weil eine Online- oder Batch-Transaktion mißlingt. Die Hauptvorteile dieser Verarbeitung von logischen Transaktionen liegen in den Bereichen Performance und Integritätssicherung.

Recovery

Das Recovery sollte auf der Ebene der logischen Arbeitseinheiten die Form eines automatischen Recovery haben, wenn eine unabhängige Transaktion mißlingt. Dabei spielt es keine Rolle, in welchem Adreßbereich der Fehler auftritt. Auf der Systemebene ist ein Recovery nötig, um den Verlust von physischen Daten zu verhindern, wenn Hardware-Einheiten ausfallen. Eingriffe des Bedienungspersonals sollten möglichst gar nicht erforderlich sein. Das Recovery läuft am besten unter der Steuerung des DBMS und nicht unter der irgendeines TP-Monitors ab, damit eine Reihe von Adreßbereichen simultan aktiv sein kann. Recovery und Restart sind dann unabhängig von den anderen Adreßbereichen.

Sicherheit

Der Datenzugriff wird günstigstenfalls auf der Ebene des Datenelements innerhalb des logischen Satzes überwacht, und zwar für alle Zugriffsberechtigungen (Lesen, Einfügen, Andern, Löschen). Diese Berechtigungen sollten auf der Feldebene in einer Datensicht definierbar sein. Der Zugriff auf diese Sicht kann individuell jedem Benutzer gestattet werden. Das ist die strengste Sicherheitsauflage, die implementiert wird; bei der Beschränkung des Datenzugriffs kann man entsprechende Einzelheiten detailliert spezifizieren.

Kommunikations-Schnittstelle

Das System muß online laufen und ein Optimum an Performance erbringen; es muß imstande sein, alle erdenklichen Eingaben und Transaktionen zu verarbeiten. Dazu bedarf es leistungsfähiger Schnittstellen, die für den ausgewählten TP-Monitor zur Verfügung stehen müssen. Eine hohe Nutzleistung in diesem Bereich stellt nicht nur das Wachstum des Netzwerkes sicher, sondern minimiert auch die Hardware-Investitionen, die für akzeptable Antwortzeiten erforderlich sind.

Dienstprogramme

Erforderlich sind umfassende und vollständige Organisationsfunktionen. Die Art, der Typ und die leichte Anwendbarkeit dieser nicht im Vordergrund stehenden Komponenten enthalten wichtige Angaben darüber, wie sich das Produkt im Lauf der Zeit verhält. Die Wartung eines Systems macht im Durchschnitt 66 Prozent der Kosten aus. Der Grad der Unabhängigkeit, der von der Datenbank sichergestellt wird, bildet potentiell den größten Bereich für Kosteneinsparungen. Es empfiehlt sich, dies im Hinblick auf die gelieferten Dienstprogramme, ihren mutmaßlichen Nutzen sowie die Funktionen,

die sie ausüben, zu analysieren. Der Anwender soll sich nicht verwirren lassen, wenn einige Hersteller Verwaltungsfunktionen (Dienstprogramme) in ihre Produkte direkt einbauen oder diese sogar zum Teil überflüssig machen.

Domänen

Domänen sind außerhalb des Programmes definierte Auflagen an die Dateninhalte. Ein relationales System ohne Einhaltung des Domänenkonzeptes und ohne Integrität der Domänen läßt sich damit vergleichen, daß man einem Kind Streichhölzer gibt Irgendwann wird als unvermeidliche Folge ein Programmierer, ein Benutzer oder ein Datenbank-Administrator die Datenintegrität verletzen - zwar unabsichtlich, aber mit an Sicherheit grenzender Wahrscheinlichkeit. Es ist sicherer und für die Leistung besser, dieses Risiko überhaupt auszuschalten, als in den Handbüchern entsprechende Vorschriften anzugeben.

Referentielle Integrität

Referentielle Integrität gewährleistet die Beziehung von Objekten zueinander, zum Beispiel Kunde zu Auftrag oder Buchung zu Konto. Diese Systemfunktion kann nicht bereitgestellt werden, ohne daß in dem DBMS irgendeine Form der Domänenverwaltung vorhanden ist.

Entity-Integrität (Objekt-Integrität)

Entity-Integrität gewährleistet die Eindeutigkeit der Objekte auf der Basis ihrer Schlüssel. Die gleichen Vorteile und Risiken, die bei der referentiellen Integrität angegeben sind, gelten auch für die Entity-Integrität. Wenn beide Integritätsauflagen nicht in dem DBMS implementiert sind, gleicht das System einem Fußballspiel ohne Schiedsrichter; man ist dann gezwungen, den Spielern zu vertrauen.

Fremdschlüssel

Das relationale Modell gibt mit Hilfe von Fremdschlüsseln die Beziehungen zwischen den Entitäten (Objekten) wieder. Diese Beziehungen unterscheiden sich nach Typ und Art, das heißt einige sind erforderlich, einige sind wahlweise möglich und einige sind automatisch. Die Regeln, die diese Beziehungen beherrschen, betreffen die "Semantik" der Datennutzung. Diese Regeln bestehen vorwiegend aus geschäftlichen Leitlinien und Strategien, die die Art und Weise spezifizieren, wie die Daten bei der Erzeugung von Informationen verwendet werden.

Es gibt ausgedehnte Diskussionen, welches Datenmodell die Semantik am besten berücksichtigt. Gleichgültig wie das Ergebnis aussehen wird, es ist wichtig, daß das gewählte DBMS die Entity-Beziehungen beziehungsweise -Verknüpfungen pflegen kann, und zwar mit Hilfe der Definition von Fremdschlüsseln (falls es relational ist). Nur das relationale Modell verwendet Fremdschlüssel, um diese Probleme zu überwachen.

Set-Level-Operatoren

Ein relationales DBMS muß in der Lage sein, Set-Level-Operatoren zu unterstützen. Das Modell benötigt nur Mengen (Relationen). Hinsichtlich Tupel-orientierter (Datensatzorientierter) Sprachen müssen Kompromisse eingegangen werden, doch sollten diese als Ausnahmen betrachtet werden (zum Beispiel Cobol). Als Vorzüge ergeben sich daraus hohe Leistung und einfache Bedienung. Diese Forderung eliminiert die satzweise Verarbeitung, die den Anwendern von nicht-relationalen DBMS vertraut ist.

Primärschlüssel

Jeder Objekteintrag muß eindeutig sein, da er ein bestimmtes, eindeutiges Objekt darstellt, das von anderen unterscheidbar sein muß. Aus diesem Grund sind doppelt vorhandene Primärschlüssel nicht akzeptabel. Das relationale Modell spiegelt die tatsächlichen Geschäftsabläufe in einer möglichst einfachen Form wider. Das DBMS muß dieses Prinzip pflegen und überwachen.

Attribute

Attribute müssen über die Zugehörigkeit zu den Relationen und Domänen definiert werden, damit sie mit dem relationalen Modell übereinstimmen.

Relationen

Relationen sind die Systembausteine des Modells. Eine Datenbank ist "nicht relational", wenn sie nicht in der Lage ist, auf der logischen Ebene mit Relationen umzugehen, das heißt mit zweidimensionalen Tabellen, die normalisierte Daten enthalten. "Normalisiert" bedeutet lediglich, daß es für jede Zeilen- und Spaltenposition einen möglichen Wert gibt. Höhere "Formen" der Normalisierung eliminieren die Verbindung zur Anwendung noch weiter und bringen die Daten näher an ihre atomare Form. Je einfacher die Form ist, desto größer ist die Flexibilität und der allgemeine Wirkungsbereich der Datenstrukturen.

Einfügen, Löschen, Ändern, Lesen

Diese Forderung hört sich vielleicht selbstverständlich und trivial an, es ist jedoch der Mühe wert, sie noch einmal zu wiederholen. Denn von den Herstellern, deren Technologie diese Forderung unterstützt, wird allgemein akzeptiert, daß abgeleitete Sichten die geeigneten Anwendungssichten jedes DBMS und insbesondere eines relationalen DBMS sind. Abgeleitete Tabellen oder Sichten vereinfachen das Einfügen, Löschen, Ändern und Lesen, da in diesem Fall die Benutzer und Programmierer nicht mehr wissen müssen, wo die Daten gespeichert sind und wie der Zugriff durchgeführt wird.

Unabhängigkeit von der physischen Datenbank-Struktur

Zielsetzung des relationalen Modells war es, alle Teile, die gegenüber physischen Änderungen anfällig sind, aus dem Anwendungsprogramm herauszunehmen. Relationale Datenbanken sollten nicht unter dem am meisten störenden Merkmal der Datenverarbeitung leiden - nämlich unter der Notwendigkeit, Programme zu ändern, deren Funktionen sich zwar nicht geändert haben, die aber geändert werden müssen, weil die physische Struktur, auf die sie zugreifen, eine Änderung notwendig macht.

Je weniger Arbeit und CPU-Leistung benötigt werden, um mit einer solchen Änderung fertigzuwerden (insbesondere wenn Aktualisierungsprogramme davon betroffen sind), desto besser ist das System. Da physische Änderungen unvermeidlich sind, verringert die Unabhängigkeit der physischen Datenbank die notwendige Wartung und Pflege. Die beste Methode, solch eine physische Unabhängigkeit sicherzustellen, besteht in einer logischen "Ebene", welche aus Basistabellen besteht, die wiederum aus Daten der physischen Dateien zusammengesetzt sind. Der Zugriff erfolgt dann auf dieses konzeptuelle Schema der Basisrelationen und nicht auf die physischen Dateien selbst. Die Änderungen in den physischen Dateien müssen nur in der Definition der Basistabelle berücksichtigt werden - nicht in jedem Programm. Da eine Kenntnis der physischen Strukturen nicht mehr notwendig ist, wird die Arbeit des Entwicklers ebenfalls sehr vereinfacht.

Unabhängigkeit der logischen Datenbank-Struktur

Der Schutz und die verlängerte Nutzung der Anwendungsinvestitionen gehören zu den Zielen von relationalen Systemen. Die Unabhängigkeit gegenüber allen Änderungen würde eine erhebliche Verringerung der Wartung und Pflege nach sich ziehen.

Fähigkeit zu abgeleiteten Relationen/Datensichten

Einer der Hauptgründe, warum man relationale DBMS im Gegensatz zu DBMS mit Netzwerk- oder hierarchischer Struktur in Erwägung zieht, ist die einfache Benutzung. Die wahren Vorteile des relationalen Modells treten zutage, wenn abgeleitete Relationen/Datensichten definiert werden und der Zugriff auf sie in einfacher Weise möglich ist. Mit abgeleiteten Sichten läßt sich der Grad der Unabhängigkeit noch um eine Stufe erhöhen. Die konzeptuellen Tabellen oder Basistabellen, welche die Unabhängigkeit der physischen Strukturen sicherstellen, können selektiv wiederum zu einfacheren Strukturen zusammengefaßt werden. Dieser Schritt entfernt alle Bezüge zu den physischen Dateien und den konzeptuellen Relationen. Er führt zu logischen "Sichten" der Daten, die von den Programmen und Prozeduren verwendet werden. Solche Sichten heißen "externe Sichten".

Vollständige operationale Funktion bei komplexen Sichten

Die Bereitstellung von komplexen Sichten ist erforderlich, wenn die Anwendungsinvestition vor Änderungen in den physischen und logischen Datenstrukturen geschützt werden soll. Solche Sichten haben jedoch nur einen begrenzten Wert, wenn nicht alle Operationen unterstützt werden. Eine Produktionsanwendung, die keine Daten ändern, löschen oder neue Daten hinzufügen kann, erfüllt keinen sinnvollen Zweck. Wenn das DBMS keine vollständig operationalen Funktionen für komplexe Sichten bereitstellt, dann müssen bei der Verarbeitung von Änderungen weiterhin veraltete Techniken angewendet werden.

Drei-Schema-Architektur

Diese Forderungen führen zwangsläufig zu der Drei-Schema-Architektur. Die drei Schemata wurden 1977 vom ANSI vorgeschlagen und bestehen aus internem, konzeptuellem und externem Schema. Das interne Schema definiert die physischen Dateien. Die Unabhängigkeit von dieser Ebene wird sichergestellt durch das konzeptuelle Schema: eine Sammlung von Basistabellen in Normalform. Damit sollen die gegenwärtigen Datenstrukturen des Unternehmens logisch wiedergegeben werden, und zwar unabhängig von den Anwendungen. Die Unabhängigkeit der Programme von Änderungen die auf dieser Ebene vorgenommen werden, wird sichergestellt durch das externe Schema. Dabei handelt es sich um eine Sammlung von komplexen abgeleiteten Sichten.

Integration und Management einer Unternehmens-Datenbank zu einer einzigen Betriebseinheit

Die Drei-Schema-Architektur macht es zum ersten Mal möglich, alle Datenanforderungen eines Unternehmens auf logische Weise in dem konzeptuellen Schema abzubilden. Das optimale DBMS integriert und verwaltet dieses konzeptuelle Schema auch dann, wenn einige dieser Daten in physischen Bereichen außerhalb der Datenbank gespeichert sind (zum Beispiel VSAM-Dateien). Diese Forderung vergrößert den Wirkungsbereich eines DBMS zu einer kompletten Datenmanagement-Funktion, so wie es eigentlich sein sollte.

Abbildung von semantischen Daten

Durch die Erweiterung des Wirkungsbereiches kommt eine neue Forderung hinzu - die Semantik. Unter "Semantik" versteht man die Gesamtmenge von Unternehmensrichtlinien, die die Datenverwendung betreffen; im Grundsatz handelt es sich also um alle Firmenrichtlinien und Prozeduren, die festlegen, was von en Benutzern und den Programmen gemacht werden kann und was nicht.

Ohne diese DBMS-Funktion bleibt die Arbeit des Programmierers unnötig kompliziert, da diese Firmenrichtlinien und Prozeduren dann in jedem Programm implementiert und eingehalten werden müssen. Durch die Zentralisierung und Konsolidierung dieser Datenregeln wird die Leistung des DBMS und des konzeptuellen Schemas gesteigert.

Verwaltung von Redundanzen

Das konzeptuelle Schema kann zwar pragmatisch erstellt werden doch sind im allgemeinen schon Komponenten des internen Schemas vorhanden. Bedauerlicherweise gibt es in den meisten Rechnern eine

Sammlung von Datenbank- und Nicht-Datenbankdateien, die als eine konzeptuelle Einheit verwaltet werden müssen.

Das DBMS sollte eine zentrale und konsistente Verwaltung von Redundanzen bei allen Dateien und Zugriffsmethoden bieten. Dies vereinfacht die Programme sowie die operationalen Prozeduren und verringert die Anfälligkeit gegenüber Bedienungsfehlern.

Automatisierter Entwurf

Die Anforderungen an den Entwurf einer logischen Datenbank steigen, sobald man damit beginnt, alle Daten über das konzeptuelle Schema zu verwalten. Aus Gründen der Konsistenz und Produktivität ist ein Software-Werkzeug für den automatisierten Entwurf mehr als wünschenswert.

Automatisierte Definition der Datenbank aus dem Ergebnis des Entwurfs

Der Anteil des automatisierten Entwurfs in der Erstellung des konzeptuellen Schemas sollte erhöht und das interne Schema sollte automatisch erzeugt werden. Da einige Daten bereits vorhanden sein dürften, müssen Vorkehrungen getroffen werden, die vorhandenen Daten in das so erzeugte interne Schema eingeben und konsolidieren zu können.

Datenbeschreibungskatalog, der für Benutzer zugänglich ist

Die bereits behandelten Systemfunktionen erfordern eine zentrale Steuereinrichtung, die allgemein als Dictionary oder Directory bezeichnet wird. Die Verwaltung der Umgebung ist zweifellos ohne eine solche Komponente schwierig.

Wenn das Directory die externen, konzeptuellen und internen Zusammenhänge bei der Durchführung auflöst, kann das volle Potential der Drei-Schema-Architektur realisiert werden. Es können also auf jeder Ebene Änderungen vorgenommen werden, ohne daß sich daraus Auswirkungen auf die anderen Ebenen ergeben. Zum Beispiel lassen sich physische Dateien neu strukturieren, oder Basistabellen können geändert werden, ohne daß ein Programm davon betroffen wird.

*Wolfgang Ebinger ist Marketingleiter bei der Cincom Systems GmbH & Co. oHG, Frankfurt.