13.1 Die ACID-Eigenschaften

Transaktionen stellen Abstraktionen von Verarbeitungsvorgängen der jeweiligen Anwendungs-Miniwelt dar (Geldauszahlung, Verkauf eines Artikels, Platzreservierung usw.). Wie in Abb. 13.1 illustriert, wird die Datenbank, welche die Miniwelt modellhaft repräsentiert, durch eine Transaktion von einem Zustand M in einen Zustand M' überführt (M = M' ist im Spezialfall von Lesetransaktionen möglich). Wesentlich für die Qualität und Korrektheit der Datenbankverarbeitung ist, daß auch nach Durchführung von Transaktionen eine hohe Übereinstimmung zwischen den resultierenden Datenbankzuständen und der Miniwelt (Realität) gewährleistet bleibt. Transaktionen müssen somit die Konsistenz der Datenbank bewahren (s. u.). Weiterhin wird zur Konsistenzwahrung verlangt, daß sämtliche DB-Zugriffe ausschließlich durch Transaktionen erfolgen.

Bezüglich der Ausführung von Transaktionen, welche aus einer oder mehreren Operationen der jeweiligen DB-Sprache (z. B. SQL) bestehen, garantiert das DBS die Einhaltung von vier grundlegenden Eigenschaften, nämlich Atomarität, Konsistenz, Isolation und Dauerhaftigkeit. Man spricht hierbei von den sog. ACID-Eigenschaften, abgeleitet von den Anfangsbuchstaben der englischen Begriffe Atomicity, Consistency, Isolation und Durability [HÄRD83b]. Diese im folgenden näher erläuterten Eigenschaften charakterisieren zugleich das Transaktionskonzept.

1. Atomarität (Atomicity, "Alles oder Nichts")

Die Ausführung einer Transaktion soll aus Sicht des Benutzers ununterbrechbar verlaufen, so daß sie entweder vollständig oder gar nicht ausgeführt wird. Dies bezieht sich vor allem auf die im Rahmen der Transaktion auszuführenden Änderungen der Datenbank. Tritt während der Ausführung einer Transaktion ein Fehler auf (Programmfehler, Hardware-Fehler, Absturz des Betriebssystems usw.), der die ordnungsgemäße Fortführung verhindert, werden seitens des DBS sämtliche bereits erfolgten Änderungen der Transaktion zurückgesetzt. Durch eine sog. Undo-Recovery werden die "Spuren" der unterbrochenen Transaktion vollständig aus der Datenbank entfernt. Um diese Fehlerbehandlung zu ermöglichen, führt das DBS ein Logging durch, d. h., zu den erfolgten Änderungen werden geeignete Informationen auf einer Protokoll- oder Log-Datei dauerhaft mitgeschrieben.
Das Zurücksetzen der Transaktion entspricht somit dem "Nichts-Fall" der Atomarität. Der "Alles-Fall" wird durch Eigenschaft 4 (Dauerhaftigkeit) gewährleistet.

2. Konsistenz (Consistency)

Die Transaktion ist die Einheit der Datenbankkonsistenz. Dies bedeutet, daß sie die Datenbank von einem konsistenten in einen wiederum konsistenten (nicht notwendigerweise unterschiedlichen) Zustand überführt. Von besonderer Bedeutung ist dabei die Einhaltung der logischen Konsistenz, so daß die Inhalte der Datenbank einem möglichst korrekten Abbild der modellierten Wirklichkeit entsprechen. Hierzu können beim Datenbankentwurf semantische Integritätsbedingungen (zulässige Wertebereiche, Schlüsseleigenschaften usw.) definiert werden, welche vom DBS automatisch zu überwachen sind. Das DBS garantiert somit, daß am Ende einer jeden Transaktion sämtliche Integritätsbedingungen erfüllt sind. Änderungen, welche zu einer Verletzung der Integritätsbedingungen führen, werden abgewiesen, d. h., sie führen zum Zurücksetzen der Transaktion. Voraussetzung für die logische ist die physische Konsistenz der Datenbank, d. h. die korrekte interne Repräsentation und Speicherung der Daten im Datenbanksystem.
Zu beachten ist, daß die Konsistenz i. allg. nur vor und nach Ausführung einer Transaktion gewährleistet wird. Während einer Transaktion dagegen können temporäre Konsistenzverletzungen eintreten bzw. notwendig werden. Als Beispiel diene eine Umbuchung zwischen Giro- und Sparkonto. Nach Abbuchen des Betrags vom Girokonto liegt ein inkonsistenter Datenbankzustand vor, wenn als Integritätsbedingung verlangt wird, daß bei Kontobewegungen innerhalb einer Bank die Summe der Kontostände unverändert bleiben soll. Die logische Konsistenz der Datenbank ist erst nach einer weiteren DB-Operation zum Gutschreiben des Betrags auf dem Sparkonto hergestellt. Solche Integritätsbedingungen, welche erst nach mehreren DB-Operationen erfüllbar sind, werden als verzögerte Integritätsbedingungen (deferred integrity constraints) bezeichnet; sie sind i. allg. am Transaktionsende zu überprüfen. Demgegenüber lassen sich unverzögerte Integritätsbedingungen (immediate integrity constraints) unmittelbar bei einer DB-Änderung überwachen, z. B. einfache Bedingungen auf einem Attribut oder einem Satz (Einhaltung von Wertebereichsgrenzen, Eindeutigkeit von Attributwerten, usw.). Auf weitere Arten von Integritätsbedingungen gehen wir in Abschnitt 13.3.1 ein.

3. Isolation

Datenbanksysteme unterstützen typischerweise eine große Anzahl von Benutzern, die gleichzeitig auf die Datenbank zugreifen können. Trotz dieses Mehrbenutzerbetriebs wird garantiert, daß dadurch keine unerwünschten Nebenwirkungen eintreten, wie z. B. das gegenseitige Überschreiben desselben Datenbankobjektes. Vielmehr bietet das DBS jedem Benutzer und Anwendungsprogramm einen "logischen Einbenutzerbetrieb", so daß parallele Datenbankzugriffe anderer Benutzer unsichtbar bleiben. Diese Isolation bzw. Ablaufintegrität der Transaktionen wird seitens des DBS durch geeignete Synchronisationsmaßnahmen erreicht, z. B. durch bestimmte Sperrverfahren. Ablaufintegrität ist Voraussetzung zur Einhaltung der Datenbankkonsistenz.

4. Dauerhaftigkeit (Durability)

Das DBS garantiert die Dauerhaftigkeit bzw. Persistenz erfolgreicher Transaktionen, deren Operationen vollständig ausgeführt wurden. Dies bedeutet, daß Änderungen dieser Transaktionen alle künftigen Fehler überleben, insbesondere auch Systemabstürze oder Externspeicherausfälle. Hierzu sind gegebenenfalls die Änderungen seitens des DBS im Rahmen einer Redo-Recovery zu wiederholen. Dafür sind wiederum geeignete Logging-Maßnahmen erforderlich, insbesondere sind vor Abschluß einer Transaktion die für die Recovery benötigten Informationen zu protokollieren.

Die automatische Gewährleistung der ACID-Eigenschaften durch das DBS bedeuten für den Benutzer bzw. Anwendungsprogrammierer eine erhebliche Erleichterung. Insbesondere kann bei der Entwicklung von Anwendungen aufgrund der Atomaritäts- und Dauerhaftigkeitszusicherungen von einer fehlerfreien Umgebung ausgegangen werden. So ist nach Bestätigung des erfolgreichen Transaktionsendes das weitere "Überleben" der Änderungen gesichert. Tritt während der Transaktionsausführung ein Fehler auf, erfolgt ein automatisches Zurücksetzen der Transaktion, um wieder einen konsistenten DB-Zustand herzustellen. Es entfällt somit auch eine sehr aufwendige manuelle Ermittlung, welche Änderungen bis zu dem Fehlerzeitpunkt schon ausgeführt wurden, um diese zu eliminieren bzw. die restlichen Änderungen noch zur Ausführung zu bringen[1]. Durch die Undo-Recovery des DBS genügt zur Durchführung der unterbrochenen Änderungen ein erneuter Start der Transaktion. Die Isolationszusicherung gestattet die Datenbanknutzung wie im Einbenutzerbetrieb; potentielle Nebenwirkungen gleichzeitiger Datenbankzugriffe sind in der Anwendung nicht abzufangen. Schließlich entfällt aufgrund der automatischen Überwachung von Integritätsbedingungen die Durchführung entsprechender Überprüfungen in den Anwendungsprogrammen.

Die anwendungsseitige Behandlung von Fehlern und Mehrbenutzereffekten sowie Überprüfung von Integritätsbedingungen würde zudem eine i. allg. inakzeptable Abhängigkeit der Datenbankkonsistenz zur Korrektheit der Anwendungen bedeuten. Zudem verbietet sich eine solche Vorgehensweise schon deshalb, da somit die entsprechenden Kontrollaufgaben redundant in zahlreichen Anwendungen realisiert werden müßten. Allerdings bleibt eine Mitverantwortung des Programmierers insbesondere hinsichtlich der semantischen Integrität der Datenbank bestehen. Denn i. allg. wird schon aus Aufwandsgründen über die definierten Integritätsbedingungen die vollständige Übereinstimmung der Datenbank mit dem modellierten Realitätsausschnitt nicht garantiert werden können. Vor allem ist es Aufgabe des Anwendungsprogrammierers, die Zuordnung der DB-Operationen zu einer Transaktion so festzulegen, daß die damit verbundenen Änderungen tatsächlich einem konsistenzerhaltenden Vorgang der Realität entsprechen (vgl. obiges Beispiel der Umbuchung).

Das DBS kann über die Prüfung der Integritätsbedingungen hinaus keine Zusicherungen zur logischen Konsistenz treffen, sondern geht ansonsten von der Korrektheit der Anwendungen aus. Wird nachträglich ein logischer Fehler in der Anwendung festgestellt, kann daher das DBS auch keine Unterstützung zum Rückgängigmachen der jeweiligen Änderungen anbieten, da diese aufgrund der Dauerhaftigkeitszusicherung aus DBS-Sicht Bestand haben müssen. Die Korrektur solcher Änderungen kann somit nur auf Anwendungsebene durch kompensierende Transaktionen erfolgen.


[1] Dies würde allein schon dadurch nahezu unmöglich werden, da eine Änderungsoperation im DBS i. allg. mehrere Teiländerungen umfaßt, die z. B. durch einen Hardware-Fehler an beliebiger Stelle unterbrochen werden können.