7 Transaktionsverwaltung in Verteilten Datenbanksystemen

7.3 Integritätssicherung

Die zweite der vier ACID-Eigenschaften, Consistency, verlangt, daß Transaktionen die semantische Integrität der Datenbank bewahren. Hierzu können sogenannte Integritätsbedingungen spezifiziert werden, die festlegen, welche Datenbankzustände bzw. Zustandsübergänge korrekt sind, so daß DB-Inhalt und modellierte Miniwelt inhaltlich übereinstimmen. Eine Änderungstransaktion darf nur dann zum Commit kommen, wenn sie alle definierten Integritätsbedingungen einhält. Integritätsbedingungen lassen sich hinsichtlich verschiedener Kriterien klassifizieren, z.B. ihrer Reichweite (Attribut, Tupel, Relation, mehrere Relationen) oder Überprüfbarkeit (sofort oder verzögert am Transaktionsende) [Re87]. Eine Sonderrolle nehmen die modellinhärenten Bedingungen ein, die unabhängig von der jeweiligen Anwendung gewahrt bleiben müssen. Im Relationenmodell sind dies die beiden Relationalen Invarianten, also Eindeutigkeit des Primärschlüssels sowie die referentielle Integrität (Kap. 2.1.1).

Die Überwachung von Integritätsbedingungen in Verteilten DBS kann weitgehend wie im zentralen Fall erfolgen, jedoch erhöht sich der Overhead möglicherweise erheblich durch zusätzlich notwendig werdende Kommunikationsvorgänge. So kann es beim Einfügen eines neuen Tupels (bzw. Änderung des Primärschlüssels) zur Eindeutigkeitsprüfung des Primärschlüssels notwendig werden, sämtliche Knoten zu involvieren, an denen Fragmente der Relation vorliegen. Der Kommunikationsaufwand kann bei horizontaler Fragmentierung nur reduziert werden, wenn die Fragmentierung über Wertebereiche auf dem Primärschlüssel definiert wurde.

Bezüglich der referentiellen Integrität ist zu unterscheiden zwischen Änderungsoperationen auf der referenzierenden (abhängigen) Sohn-Relation S, die den Fremdschlüssel enthält, sowie der referenzierten Vater-Relation V, auf deren Primärschlüssel sich der Fremdschlüssel bezieht. Das Löschen eines S-Satzes sowie das Einfügen eines V-Satzes erfordern keine zusätzlichen Aktionen hinsichtlich der referentiellen Integrität. Beim Einfügen eines S-Satzes bzw. Änderung des Fremdschlüsselattributs ist zu überprüfen, ob der neue Fremdschlüsselwert definiert ist. Dies erfordert einen zusätzlichen Kommunikationsvorgang, falls das betreffende V-Fragment an einem anderen Knoten vorliegt. Die beim Löschen eines V-Satzes oder Ändern eines Primärschlüssels vorzunehmenden Aktionen können in SQL92 anwendungsspezifisch festgelegt werden [DD92]. Eine Option ist, die Änderungen abzuweisen, sofern noch abhängige S-Tupel vorliegen. Diese Überprüfung erfordert im Worst-Case den Zugriff auf alle S-Fragmente. Dies gilt auch für die Alternativen, in der alle abhängigen Tupel ebenfalls gelöscht bzw. deren Fremdschlüssel geändert werden. Im günstigsten Fall werden jedoch zusätzliche Kommunikationsvorgänge vollständig vermieden; dies ist bei abhängiger horizontaler Fragmentierung möglich (Kap. 5.3.2). Die effiziente Implementierung der zur Überprüfung der referentiellen Integrität an jedem Rechner anfallenden Aufgaben wird in [HR92] diskutiert.

Ähnlich wie die Modellbedingungen erfordern auch die anwendungsbezogenen Integritätsbedingungen zusätzliche Verarbeitungsschritte und Kommunikationsvorgänge in Abhängigkeit der vorliegenden Datenverteilung. Eine Besonderheit ergibt sich bei Integritätsbedingungen, die verzögert am Transaktionsende auszuwerten sind[31]. Deren Überwachung ist jetzt ins Commit-Protokoll einzubinden, wofür ggf. auch Rechner zu involvieren sind, die an der Transaktionsausführung selbst nicht beteiligt waren. Bei einem Zwei-Phasen-Commit-Protokoll geschieht die Überprüfung in der ersten Commit-Phase, wobei dann der Prepared-Zustand natürlich nur bei erfolgreichem Test eingenommen wird.

[31] Dies sind z.B. alle Integritätsbedingungen, die mehrere Relationen betreffen, da in SQL Änderungsoperationen jeweils auf eine Relation beschränkt sind.