Datenbanksysteme

Informationssysteme werden für bestimmte Anwendungsbereiche, auch Miniwelten genannt, eingeführt und sollen über alle Sachverhalte und Vorgänge dieser Miniwelten möglichst aktuele 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.

DBS werden entwickelt, um (potentiell) sehr große Mengen an Daten zu verwalten, für die Anwendungen abstrakte Sichten auf die Daten bereitzustellen und auf ihre Anforderungen hin standardisierte, komplexe Operationen auf den Daten effizient und zuverlässig auszuführen. Ideal wäre hierfür ein Speicher mit nahezu unbegrenzter Speicherkapazität, kurzer Zugriffszeit bei wahlfreiem Zugriff, hohen Zugriffsraten und geringen Speicherkosten. Außerdem müßte er nichtflüchtig sein, um Objekte persistent halten zu können. Würde zudem ein solcher Speicher die „Wunscheigenschaft“ besitzen, auf Anweisung eines Prozessors arithmetische und logische Verknüpfungen direkt auszuführen, wäre die Realisierung von Rechnern möglich, bei denen zur DB-Verarbeitung keine Daten übertragen und keine Kopien erstellt werden müßten. Diese Idealvorstellung würde es sicherlich in recht einfacher Weise gestatten, alle vernünftigen Leistungs anspräche, die an die DB-Verarbeitung gestellt werden, zu befriedigen.

Die physischen Datenobjekte eines DBS werden auf nichtflüchtigen Externspeichern während ihrer gesamten Lebenszeit, die Jahrzehnte betragen kann, aufbewahrt. Zur Verarbeitung müssen diese jedesmal vom externen Speichermedium in den Hauptspeicher des Rechnersystems gebracht werden. Wegen der Flüchtigkeit dieses Speichertyps sind die Daten nach ihrer Änderung auf den Externspeicher zurückzuschreiben. Nun ist die Speichertechnologie, wie in Kapitel 2 beschrieben, von einer hohen Innovationsrate geprägt, d. h., Leistungsmerkmale und Betriebseigenschaften von Speichermedien werden ständig verbessert und mit neuen Funktionen u. a. ausgestattet. Deshalb gilt es, den DBS-Code, so gut es geht, von den Folgen dieser raschen technologischen Entwicklung abzuschirmen. So sollte es vor allem möglich sein, die Anpassung der Lese- und Schreiboperationen an neue oder geänderte Geräteeigenschaften oder die Nutzung neu eingeführter Funktionen jeweils nur durch lokale Code-Modifikationen zu bewerkstelligen.

Die hier betrachtete Abbildungsschicht führt mit Segmenten und Seiten eine weitere Abstraktionsebene ein, welche Dateien und Blöcke verbirgt und zugleich verbesserte Verarbeitungseigenschaften und Fehlertoleranzmaßnahmen verfügbar macht. Prinzipiell könnte ebenso wie bei der Speicherzuordnung eine DB-Realisierung angestrebt werden, bei der die DB als linearer Speicher erscheint, keine Segmentierung mehr aufweist und für alle referenzierenden DBS-Komponenten eine monolithische Einheit darstellt. Dann würden jedoch alle Vorteile des bei der Externspeicherverwaltung eingeführten Dateikonzeptes verlorengehen. Das in der unteren Abbildungsschicht vorgegebene Dateikonzept impliziert sinnvollerweise eine Aufteilung des logischen Adreßraums der Datenbank. Eine einfache Möglichkeit besteht darin, die durch die Dateien vorgenommene Aufteilung des Adreßraums direkt an der DB-Pufferschnittstelle zu übernehmen, wie es in vielen herkömmlichen DBS praktiziert wird. Als Folge davon wäre eine strikte Separierung der Aufgaben von Externspeicher- und DB-Pufferverwaltung nicht mehr möglich, und die Freiheitsgrade einer expliziten Seitenabbildung würden wegfallen.

Die DB-Pufferverwaltung hat zusammen mit der Segment- und Seitenabbildung einen linearen logischen Adreßraum für höhere Systemschichten im Hauptspeicher zur Verfügung zu stellen. Idealerweise sollte dieser „unendlich“ groß sein; in realen DBS erreicht er heute als DB-Puffer Größen im Bereich von GBytes und besitzt eine Seitenstruktur. Nach Anforderung werden die benötigten DB-Objekte in diesem Puffer zum Lesen oder Ändern in Einheiten von Seiten bereitgestellt; dort ist ihre direkte Adressierung und Manipulation mit den Zugriffsoperationen der nächsthöheren Systemschicht möglich. Falls ein angefordertes DB-Objekt nicht schon im Puffer steht, muß, sofern Speichermangel herrscht, durch Ersetzung freier Platz geschaffen werden. Wurde das zu ersetzende DB-Objekt verändert, ist bei der Externspeicherverwaltung sein Rückschreiben in die Datenbank zu veranlassen, bevor das angeforderte DB-Objekt eingelesen werden kann.

Die nächsthöhere Abbildungsschicht wird in unserem Schichtenmodell (siehe Abb. 1.7) durch den Begriff „Speicherungsstrukturen“ bezeichnet. Ausgehend von den an der DB-Pufferschnittstelle bereitgestellten Segmenten und Seiten hat sie an ihrer oberen Schnittstelle, interne Satzschnittstelle genannt, Operationen auf physischen Sätzen und Zugriffspfaden verfügbar zu machen, die zur Verwaltung und Speicherung der (logischen) DB-Objekte dienen. Das Erzeugen und Warten dieser Strukturen erfolgt satzorientiert mit Hilfe ihrer vorgegeben Modifikationsoperatoren; sie lassen sich durch Anweisungen der Art „Speichere Ausprägung vom Satztyp X“ oder „Aktualisiere B*-Baum mit Eintrag Y“ charakterisieren. Ebenso ist das Aufsuchen satzorientiert, und zwar mit wertbasierten und sequentiellen Zugriffen über vorhandene Zugriffspfade. Die zur Verwaltung der Speicherungsstrukturen anfallenden Aufgaben lassen sich gewöhnlich gut separieren und so verschiedenen Komponenten dieser Abbildungsschicht zuordnen:

Für die Leistungsfähigkeit eines DBS ist es entscheidend, Sätze über inhaltliche Kriterien (Schlüssel) möglichst effizient auffinden zu können. Es sind deshalb Hilfsstrukturen bereitzustellen, um einen Satz oder eine Menge zusammengehöriger Sätze möglichst direkt zu lokalisieren und damit die sequentielle Suche in allen Seiten eines Segmentes oder gar der gesamten DB zu vermeiden. Diese Zugriffshilfen haben ganz allgemein die recht anschauliche Bezeichnung „Zugriffspfade“. Sie sollen das Aufsuchen von Sätzen wirksam unterstützen, ohne dabei durch den zusätzlich anfallenden Speicherbedarf und den benötigten Wartungsaufwand das gesamte Leistungsverhalten des DBS zu sehr zu belasten. Dabei lassen sich in erster Linie folgende Arten von Zugriffen unterscheiden:

Eindimensionale Zugriffspfade gestatten den direkten Schlüsselzugriff auf alle Sätze eines Satztyps und lokalisieren dabei einen Satz oder eine Menge von Sätzen mit Hilfe eines Primärschlüssels bzw. Sekundärschlüssels. Sie stellen gewissermaßen Basiszugriffsverfahren dar, mit denen sich auch höhere DB-Operationen flexibel und effizient abwickeln lassen. Fallweise ist es jedoch zu empfehlen, zur Unterstützung wichtiger Beziehungstypen oder häufig vorkommender DB-Operationen zugeschnittene Zugriffsverfahren zu entwickeln, die den Zugriff über mehrere Satztypen — also einen typübergreifenden Zugriff — beschleunigen, um ein verbessertes Leistungsverhalten zu erzielen.

Die in Kapitel 7 diskutierten Zugriffspfadstrakturen zum Zugriff auf eine homogene Satzmenge sind eindimensional in dem Sinne, daß als Suchschlüssel nur der Wert genau eines Attributes verwendet werden kann. Suchschlüssel oder -ausdrücke, die als Kombination von Werten verschiedener Attribute aufgebaut sind, lassen sich nicht direkt über einen Zugriffspfad auswerten. Es müssen vielmehr mehrere unabhängige Suchvorgänge abgewickelt werden, deren Ergebnisverknüpfung mit Hilfe mengentheoretischer Operationen auf TID-Listen den Effekt einer mehrdimensionalen Suche zustandebringt. Dabei wird gewissermaßen die mehrdimensionale Suche mit Hilfe von n eindimensionalen Suchvorgängen simuliert. Ähnlich wie weitere Verfahren, wie beispielsweise die Konkatenation von Attributen als Schlüssel eines B*-Baumes, stellen solche Vorgehensweisen unbefriedigende Lösungen dar und können nur in sehr eingeschränkter Weise zur mehrdimensionalen Suche genutzt werden. Da einerseits die Topologie der Objekte oft aus Gründen der Verarbeitungslokalität u. a. bei der Datenspeicherung zu berücksichtigen ist und andererseits in DB-Anwendungen häufig über mehrere Attribute gesucht wird (Mehrattributsuche), sollte ein DBS aus Effizienzgründen mehrdimensionale Cluster-Bildung und echte mehrdimensionale Suche unterstützen.

Die Objekte der internen Satzschnittstelle, deren wichtigste Implementierungstechniken in den Kapiteln 6 – 9 beschrieben wurden, sind physische Objekte in dem Sinne, daß sie direkt in den spezifizierten Formaten in den DB-Seiten gespeichert sind. Alle Objekte höherer DB-Schnittstellen stellen Abstraktionen dieser physischen Objekte dar; sie sind logische Objekte in dem Sinne, daß sie selbst keine direkte physische Repräsentation besitzen, sondern jeweils nur zum aktuellen Referenzzeitpunkt „existieren“, d. h. aus den physischen Objekten der internen Satzschnittstelle abgeleitet bzw. auf sie abgebildet werden.

Unsere Beschreibungssystematik für die Architektur eines datenunabhängigen DBS sieht vor, daß die oberste Schicht unseres Architekturmodells (siehe Abb. 1.7) eine mengenorientierte DB-Schnittstelle auf eine satzorientierte DB-Schnittstelle abbildet. Die wichtigste Aufgabe dieser Abbildung ist die Übersetzung und Optimierung von deklarativen und mengenorientierten Anfragen, so daß sich diese möglichst kosteneffektiv durch (potentiell lange) Folgen von satzorientierten DB-Operationen abwickeln lassen. Wir diskutieren diese Aufgabe im Kontext von SQL-Anfragen.

Dieses und die folgenden Kapitel befassen sich mit dem Transaktionskonzept und seiner Realisierung. Die Einhaltung dieses auch als ACID-Paradigma bezeichneten Konzepts ist Voraussetzung für die sichere und konsistente Ausführung von DB-Operationen, trotz gleichzeitiger DB-Zugriffe durch zahlreiche Benutzer und möglicher Fehlersituationen wie Rechner- oder Plattenausfällen. Die Grundlagen des Transaktionskonzepts sowie wesentliche Implementierungstechniken wurden bereits in den siebziger Jahren entwickelt, insbesondere in Verbindung mit der Implementierung der ersten relationalen DBS [GRAY78]. Die Unterstützung des Transaktionskonzepts ist seitdem längst eine obligatorische Funktion aller Datenbanksysteme, unabhängig vom zugrundeliegenden Datenmodell. Für wesentliche Aufgaben der Transaktionsverwaltung, insbesondere Synchronisation, Logging und Recovery, steht ein Fundus an leistungsfähigen und in der Praxis erprobten Verfahren zur Verfügung.

Eine eminent wichtige Aufgabe von DBS liegt in der Gewährleistung einer weitgehenden Datensicherung. Trotz Auftretens von Fehlern verschiedener Art ist die Konsistenz der Datenbank automatisch zu wahren und Datenverlust zu verhindern. Die Fehlerbehandlung ist Aufgabe der Recovery-Komponente des DBS. Sie benötigt neben den Datenbankinhalten redundante Informationen, welche durch ein Logging im Normalbetrieb zu protokollieren sind. Die notwendigen Recovery-Aufgaben sind weitgehend durch das Transaktionskonzept (vor allem die Eigenschaften A und D, siehe Abschnitt 13.1) bestimmt. Insbesondere sind aufgrund der Dauerhaftigkeitszusicherung Änderungen erfolgreich beendeter Transaktionen gegenüber allen erwarteten Fehlerarten zu bewahren. Weiterhin verlangt die Alles-oder-Nichts-Eigenschaft das Zurücksetzen von Änderungen für Transaktionen, welche aufgrund eines Fehlers ihr Commit nicht abschließen konnten.

Das Transaktionskonzept mit den ACID-Eigenschaften ist als Verarbeitungsmodell für Datenbankanwendungen fest etabliert. Es wird darüber hinaus auch für andere Anwendungsbereiche zunehmend eingesetzt, die eine sichere und zuverlässige Nutzung von Ressourcen durch mehrere Benutzer benötigen. Wesentlich für die große Akzeptanz des Transaktionskonzepts sind u. a. seine einfache Benutzerschnittstelle, seine klare Fehlersemantik (Alles-oder-Nichts), die Nutzbarkeit in zentralisierten und verteilten Systemen sowie die Verfügbarkeit effizienter Implementierungen. Andererseits ist die Einfachheit des ACID-Paradigmas, welches von „flachen“ Transaktionen ohne Binnenstruktur ausgeht, für nicht wenige Anwendungsfälle zu restriktiv. Diese Beschränkungen wurden bereits frühzeitig erkannt, u. a. in [GRAY81c]. Es wurde in der Folgezeit eine kaum überschaubare Zahl von Erweiterungen des ACID-Konzepts vorgeschlagen. Als am bedeutsamsten haben sich dabei verschiedene Varianten geschachtelter Transaktionen herausgestellt, welche eine Zerlegung von Transaktionen in interne Sub-Transaktionen unterstützen. Hierfür bestehen mittlerweile erste Implementierungen im Rahmen von TP-Monitoren (z. B. Encina) sowie objektorientierten Systemen. Zur Klassifikation unterschiedlicher erweiterter Transaktionsmodelle wurden Metamodelle wie ACTA [CHRY90, CHRY94] vorgeschlagen, welche eine formale Charakterisierung der einzelnen Ansätze gestatten sowie die Spezifikation neuer Transaktionsmodelle unterstützen. Die Realisierung solch generischer Modelle wird u.a. in Arbeiten wie [BILI94, GEOR94, BARG95] untersucht.

In diesem Buch haben wir die wesentlichen Konzepte und Techniken vorgestellt, die zur Realisierung der DBS-Funktionalität, wie sie durch unser Schichtenmodell beschrieben wird, eingesetzt werden. Wir orientierten uns dabei hauptsächlich an den Anforderungen satzorientierter DB-Schnittstellen, also beispielsweise navigierender oder objektorientierter DB-Modelle und -Sprachen, sowie mengenorientierter DB-Schnittstellen, vor allem nach dem Relationenmodell und seiner Standardisierung nach SQL92¹ [EISE98]. Das durch alle fünf Schichten angebotene Funktionsspektrum läßt sich als die Kernfunktionalität von zentralisierten DBS charakterisieren. Erweiterungen, wie sie unser Kapitel über DBS-Architekturen anspricht, wurden von uns nicht weiter aufgegriffen und verfeinert — wir verweisen dazu auf speziellere Lehrbücher und Veröffentlichungen, etwa zu Transaktionssystemen [BERN97, GRAY93], zu verteilten und parallelen DBS [RAHM94] oder zu Multimedia-DBS [APER97].