1.1 Anforderungen an Datenbanksysteme

Informationssysteme werden für bestimmte Anwendungsbereiche, auch Miniwelten genannt, eingeführt und sollen über alle Sachverhalte und Vorgänge dieser Miniwelten möglichst aktuelle Auskunft geben. Dazu ist es erforderlich, die betrachteten Realitätsausschnitte rechnerseitig durch ein Modell zu repräsentieren und die Vorgänge (Ereignisse) der Miniwelt, die zu neuen oder geänderten Sachverhalten führen, in diesem Modell zeitgerecht und genau nachzuvollziehen. Die modellhafte Nachbildung der Miniwelt erzwingt Abstraktion bei der Beschreibung ihrer Objekte und Beziehungen, die durch das Modell abgebildet werden. Vorgänge in der Realität überführen diese in neue Zustände. Da relevante Zustände vom Modell erfaßt werden müssen, sind auch die Zustandsänderungen durch Folgen von Operationen des Modells möglichst genau nachzubilden, so daß eine möglichst gute Übereinstimmung der Folgezustände in Realität und Modell erreicht werden kann. Darüber hinaus müssen Zustandsübergänge systemseitig auch hinsichtlich des Auftretens von Fehlern ununterbrechbar sein. Solche Anforderungen werden technisch durch Transaktionen umgesetzt, wobei das ACID-Paradigma [GRAY81c] weitreichende Zusicherungen für die Qualität der Modellzustände übernimmt.

 

1.1.1 Entwicklung von Anwendungssystemen

Die Entwicklung von großen Anwendungs- und Informationssystemen erfordert vielfältige Maßnahmen zur Gewährleistung aktueller, konsistenter und persistenter Daten. Systemrealisierungen, die dazu isolierte Dateien einsetzen, weisen eine Reihe schwerwiegender Nachteile auf. Mit solchen losen Sammlungen von Dateien lassen sich Ausschnitte aus einem Anwendungsbereich mit ihren Sachverhalten, Abhängigkeiten und Beziehungen nur sehr grob modellieren. Die Speicherung und Aktualisierung der Daten erfolgt ohne zentralisierte Kontrolle, so daß fehlerhafte, widersprüchliche oder unvollständige Informationen nur sehr schwer oder oft gar nicht aufgedeckt werden. In der Regel werden Dateien im Hinblick auf konkrete Anwendungen konzipiert und in ihren Speicherungsstrukturen auf die speziellen Verarbeitungsanforderungen optimiert. Diese Anwendungsanbindung erzeugt in hohem Maße Datenabhängigkeiten, schränkt die flexible Nutzung von Dateien durch andere Anwendungsprogramme ein und ist ein wesentlicher Grund für die mangelnde Erweiterbarkeit und Offenheit des gesamten Anwendungssystems. Ergebnis einer solchen Vorgehensweise ist eine häufig redundante Speicherung gleicher Daten in verschiedenen Dateien, wodurch eine zeitgerechte und alle Kopien umfassende Änderung verhindert wird. Zusätzlicher Informationsbedarf und Änderungen in betrieblichen Abläufen erzwingen ständig eine Evolution des Anwendungssystems, wobei wegen der "eingefrorenen" Datenstrukturen und -beziehungen oft nur die Einführung zusätzlicher Datenredundanz weiterhilft und so die Situation immer weiter verschlimmert wird.

Bei einer sich schnell verändernden Anwendungswelt und der Forderung nach kurzfristigen und flexiblen Anpassungen der Anwendungssysteme an die sich ständig ändernde Systemumgebung sind bei Einsatz isolierter Dateien zumindest die Entwurfsziele "Aktualität und Konsistenz der Daten" nicht zu erreichen. Seit mehr als 30 Jahren setzen sich deshalb für alle Aufgaben der Datenhaltung mit zunehmendem Erfolg Datenbanksysteme durch, die eine integrierte Sichtweise auf alle Daten anbieten und alle Fragen der Konsistenzerhaltung, Systemevolution, Anpassung an geänderte Umgebungsbedingungen usw. unabhängig von den Anwendungsprogrammen regeln.

 

1.1.2 Entwurfsziele

Die Entwicklung von Datenbanksystemen wird durch ein breites Spektrum an Anforderungen begleitet, die in geeignete Systemarchitekturen sowie Implementierungskonzepte und -techniken umzusetzen sind. Dabei sind vor allem folgende Entwurfsziele zu realisieren oder zumindest vorrangig anzustreben:

Integration der Daten und Unabhängigkeit der Datenverwaltung erfordern das Herauslösen aller Aufgaben der Datenverwaltung und Konsistenzkontrolle aus den Anwendungsprogrammen sowie ihre Standardisierung und Übernahme in ein logisch zentralisiertes System, das Zuverlässigkeit, Widerspruchsfreiheit und Vollständigkeit der Operationen auf allen Daten gewährleisten kann. Langfristigkeit der Datenspeicherung und Konsistenzzusicherungen, auch im Fehlerfall, können bei einer integrierten Datenbasis ohnehin nicht gemeinsam durch eine Menge individuell entworfener Anwendungsprogramme erbracht werden. Die Zentralisierung dieser Aufgabe erfolgte deshalb durch große, unabhängige und generische Software-Systeme, die als Datenbankverwaltungssysteme (DBVS) bezeichnet werden. Zusammen mit den gespeicherten Daten der Datenbasis, kurz Datenbank (DB) genannt, bildet das DBVS ein Datenbanksystem (DBS). In der Regel werden wir auf die feine Unterscheidung der Begriffe DBVS und DBS verzichten und DBS als einheitliche Bezeichnung benutzen.

Datenunabhängigkeit ermöglicht den Anwendungsprogrammen eine Benutzung der DB-Daten, ohne Details der systemtechnischen Realisierung zu kennen. Dies läßt sich vor allem durch logische Datenmodelle und deklarative Anfragesprachen erzielen. Datenunabhängigkeit der Anwendungen besitzt als Entwurfsziel von DBS eine herausragende Rolle, da durch zusätzlichen Informationsbedarf und Strukturänderungen in der Miniwelt die DB-Strukturen einer ständigen Evolution unterworfen sind. Idealerweise sollten Anwendungsprogramme und DBS so stark voneinander isoliert sein, daß sie eine wechselseitige Änderungsimmunität aufweisen. Neben der Datenunabhängigkeit ist beim logischen DB-Entwurf Anwendungsneutralität und damit auch Offenheit für neue Anwendungen anzustreben. Die gemeinsame Benutzung von großen und integrierten Datenbeständen läßt einen Zuschnitt auf die Anforderungen bestimmter Anwendungen nicht sinnvoll erscheinen; außerdem könnte eine einseitige Ausrichtung des DB-Entwurfs wegen der Notwendigkeit ständiger Systemevolution schnell obsolet werden. Eine solche Anwendungsneutralität beim Entwurf von logischen Datenstrukturen bedeutet die Wahl redundanzfreier und symmetrischer Organisationsformen und verbietet die explizite Bevorzugung einzelner Anwendungsprogramme durch zugeschnittene Verarbeitungs- und Auswertungsrichtungen. Aus der Sicht der Anwendungen ist Redundanzfreiheit auch für die physische Repräsentation der Daten (physischer DB-Entwurf) gefordert. Da diese sich jedoch nicht unmittelbar auf Speicherungsstrukturen (siehe nachfolgende Diskussion der Anwendungsprogrammierschnittstellen) beziehen können, kann hier selektive und DBS-kontrollierte Redundanz zugelassen werden, um beispielsweise das Leistungsverhalten wichtiger Anwendungen zu verbessern.

Wesentliche Voraussetzung für Datenunabhängigkeit und zugleich einfache Benutzung von DBS sind "hohe" Anwendungsprogrammierschnittstellen (API, application programming interface). Hauptkennzeichen sind logische Datenmodelle und deklarative Anfragesprachen, da sich DB-Operationen dadurch nur auf abstrakte Objektrepräsentationen, ohne Hinweis auf die erforderliche Zugriffslogik, beziehen können. Da nur das "was wird benötigt?" und nicht das "wie wird es aufgesucht?" zu spezifizieren ist, ergibt sich zugleich eine einfache Handhabung der Daten durch den Benutzer. Deklarative Anfragesprachen sind mengenorientiert und geben keine Auswertungsrichtung vor, was dem DBS Optimierungsmöglichkeiten bei komplexen DB-Operationen einräumt. Neben der Einbettung von Programmierschnittstellen in Wirtssprachen, die eine anwendungsbezogene Weiterverarbeitung von DB-Daten zulassen, ist ein flexibler DB-Zugang über Ad-hoc-Anfragesprachen eine wichtige Schnittstellenanforderung.

Die gemeinsame Datenbenutzung erfordert zwingend eine Zentralisierung aller Maßnahmen zur Integritätskontrolle. Das betrifft vier verschiedene Arten von Kontrollaufgaben mit entsprechenden Reaktionen bei erkannten Integritätsverletzungen. Die erste Kontrollaufgabe regelt die Zulässigkeit des Datenzugriffs aufgrund betrieblicher Regelungen oder gesetzlicher Maßnahmen (Datenschutz). Durch Zugriffskontrolle ist zu gewährleisten, daß nur berechtigte Benutzer Daten verarbeiten dürfen, und zwar im Rahmen der für sie definierten Zugriffsrechte und Datengranulate. Um die Datenbank konsistent zu halten, muß mit Hilfe von semantischen Integritätsbedingungen (constraints) bei allen Änderungen oder Aktualisierungen (siehe Transaktionskonzept) geprüft werden, ob der neue DB-Zustand akzeptabel ist.[1] Solche Bedingungen (Prädikate) sind explizit zu spezifizieren und durch das DBS zu überwachen, was bei Systemevolution auch die Durchführung von Änderungen oder Ergänzungen der Integritätsbedingungen erleichtert. Weiterhin muß das DBS durch Aufzeichnung redundanter Daten (Logging) im Normalbetrieb Vorsorge für den Fehlerfall treffen, um beispielsweise nach Auftreten eines Systemausfalls oder eines Gerätefehlers einen konsistenten DB-Zustand (genauer, den jüngsten transaktionskonsistenten DB-Zustand [HÄRD83b]) wiederherstellen zu können (Recovery). Schließlich muß das DBS für Synchronisation, d. h. für korrekte Abwicklung konkurrierender Benutzeroperationen auf den gemeinsamen DB-Daten sorgen. Hierbei handelt es sich vor allem um die Vermeidung von Fehlern, die im unkontrollierten Fall durch wechselseitige Beeinflussung provoziert werden. Es ist offensichtlich, daß alle genannten Kontrollaufgaben nicht von einzelnen Anwendungsprogrammen ausgeübt werden können; sie verlangen vielmehr zentralisierte Überprüfung und Abhilfemaßnahmen.

Zentralisierte Integritätskontrolle ist wiederum Voraussetzung für den Transaktionsschutz, durch den das DBS jeder Anwendung weitreichende Zusicherungen für die Ausführung ihrer Aufsuch- und Aktualisierungsoperationen garantiert. Durch das Transaktionskonzept mit seinen ACID-Eigenschaften [GRAY81c] werden Korrektheit und Ablauf der gesamten DB-Verarbeitung, insbesondere bei konkurrierender Benutzung und im Fehlerfall, in wesentlichen Aspekten festgelegt. Als dynamische Kontrollstruktur bietet eine Transaktion Atomarität (atomicity) für alle ihre DB-Operationen, Konsistenz (consistency) der geänderten DB, isolierte Ausführung (isolation) der Operationen im Mehrbenutzerbetrieb sowie Dauerhaftigkeit (durability) der in die DB eingebrachten Änderungen [HÄRD83b][2]. Im Kern verkörpert das Transaktionskonzept die "Alles-oder-Nichts"-Eigenschaft (Atomarität) jeglicher DBS-Verarbeitung, was ein einfaches Fehlermodell für die Abwicklung von DB-Operationen zuläßt. Auch im Fehlerfall wird eine Transaktion entweder vollständig unter Beachtung der ACID-Eigenschaften ausgeführt oder alle ihre Auswirkungen in der DB werden so getilgt, als sei sie nie gestartet worden. Diese weitreichenden Garantien erlauben die Implementierung einer Art Vertragsrecht durch DBS-Anwendungen. Sie machen es einsichtig, daß heute alle unternehmenskritischen Vorgänge und Abläufe DB-seitig transaktionsgeschützt abgewickelt werden. Das betrifft sowohl zentralisierte als auch verteilte Anwendungen. In [GRAY93] wird gezeigt, wie durch sog. Ressourcen-Manager-Architekturen neben den DB-Daten auch andere Betriebsmittel wie Nachrichten, Dateien, Programmiersprachenobjekte usw. sich in den Transaktionsschutz einbeziehen lassen.

Historisch gesehen wurde der Begriff "Transaktion" Mitte der siebziger Jahre durch DBS-Forscher und -Entwickler geprägt [GRAY76]. Seit dieser Zeit führte das Transaktionskonzept in DBS zu einem Paradigmenwechsel bei der Anwendungsprogrammierung. Seine Hauptvorteile liegen vor allem darin, daß dem Anwendungsprogramm eine fehlerfreie Sicht auf die Datenbank gewährt wird und daß es von allen Aspekten des Mehrbenutzerbetriebs isoliert ist. Weiterhin hat sich die Transaktionsorientierung als wesentliches Systemmerkmal in rasanter Weise durchgesetzt. Für DBS gilt sie heute bereits als unverzichtbare Eigenschaft, ja sogar als Definitionskriterium: ein DBS ohne Transaktionskonzept verdient seine Bezeichnung nicht. Auch in anderen Systemen, wie z. B. Betriebssystemen, findet es zunehmend Eingang.

Da Speichermedien immer billiger und zuverlässiger werden, wachsen heute die betrieblichen Datenbestände in enorme Größenordnungen, so daß effiziente und parallele Verfahren der DB-Verarbeitung einen hohen Stellenwert gewinnen. Zugriffsmethoden sollten sehr schnell und idealerweise unabhängig von der Größe des Datenbestandes sein, jedoch höchstens logarithmisch in der Zahl der Externspeicherzugriffe mit den Datenvolumina wachsen. Auswertungen, die durch neue Anforderungen auch immer komplexer werden, sollten durch zugeschnittene Algorithmen, verbesserte Vorplanung, vermehrten Hauptspeichereinsatz zur Datenpufferung usw. sowie durch Nutzung inhärenter Zugriffsparallelität optimiert werden können, um Leistungseinbußen beim Größenwachstum so weit wie möglich abzufangen.

Die Ubiquität von DBS in betrieblichen Anwendungs- und Informationssystemen verlangt quasi ständige Betriebsbereitschaft, was einerseits hohe Verfügbarkeit und Fehlertoleranz (continuous operation) erzwingt und andererseits keine separaten Zeiträume für die Reorganisation der Datenbestände, das Erstellen von Sicherungskopien usw. offenläßt. Folglich müssen Implementierungstechniken für Speicherungsstrukturen und Sicherungsmaßnahmen so ausgelegt sein, daß laufend dynamisch reorganisiert und inkrementell vorgegangen werden kann. Natürlich verlangt die Realisierung solcher Anforderungen redundante Auslegung und gekapselste Hardware- und Software-Entwurfseinheiten, um Fehler lokal isolieren und den Betrieb aufrechterhalten zu können. Techniken zur Erzielung sehr hoher Zuverlässigkeit sind jedoch nicht Inhalt dieses Buchs.

Ein DBVS ist als generisches System zu sehen, das in verschiedensten Anwendungsbereichen und mit unterschiedlichsten Leistungsanforderungen in bezug auf Durchsatz und Antwortzeit eingesetzt werden soll. Deshalb ist es außerordentlich wichtig, daß es Skalierbarkeit als wesentliche und durchgängige Systemeigenschaft besitzt, um bei unterschiedlichen Anwendungsprofilen mit weit variierenden Leistungsbereichen genutzt werden zu können. Ausschließlich durch Installation von mehr oder leistungsstärkeren Prozessoren sowie durch Vergrößerung von Haupt- und Externspeicher sollte eine idealerweise lineare Leistungssteigerung erzielbar sein, die sich in Einheiten der Anwendungsverarbeitung (Transaktionen) messen läßt. Beispielsweise sollte bei Zukauf von Hardware-Ressourcen der Transaktionsdurchsatz bei gleichbleibender mittlerer Antwortzeit entsprechend anwachsen. Andererseits sollte es, allerdings in gewissen Grenzen, möglich sein, durch vermehrten Hardware-Einsatz bei gleichbleibendem Transaktionsdurchsatz die mittlere Antwortzeit zu senken. Skalierbarkeit bedeutet vor allem, daß Datenvolumina und Anwendungslasten eines DBVS in weiten Bereichen ausschließlich durch Einsatz von HW-Ressourcen anwachsen können, ohne daß seine Leistung beeinträchtigt wird. Skalierbarkeit eines DBVS ist deshalb die Voraussetzung, daß es sich einerseits für Anwendungen unterschiedlichster Größe und Leistungsanforderungen heranziehen läßt und daß andererseits ein DBS mit dem Unternehmen wachsen kann.

[1] Akzeptabel heißt hier, daß eine Transaktion einen DB-Zustand hinterläßt, der alle definierten Integritätsbedingungen erfüllt. Das bedeutet nicht, daß der DB-Zustand auch korrekt ist, d. h. mit der abgebildeten Miniwelt übereinstimmt.

[2] Daß sich diese weitreichenden Zusicherungen des Transaktionsmodells auch lückenlos auf reale Anwendungen übertragen lassen, wünscht Jim Gray allen Betroffenen: "May all your transactions commit and never leave you in doubt".