Kapitel 10: Transaktionen und Datenintegrität

Transkript

1 1 Kapitel 10: Transaktionen und Datenintegrität Ein DBMS hat die Korrektheit des Datenbankzustandes unter realen Benutzungsbedingungen zu wahren. Dazu gehören die folgenden Punkte: Datensicherheit (Recovery) Schutz vor Verlust von Daten durch technische Fehler (z.b. Systemabsturz). Integrität (Integrity) Schutz vor Verletzung der Korrektheit und Vollständigkeit von Daten durch berechtigte Benutzer. Synchronisation (Concurrency Control) Schutz vor Fehlern durch sich gegenseitig störenden nebenläufigen Zugriff mehrerer Benutzer. Datenschutz (Security) Schutz vor Zugriffen und Änderungen durch unberechtigte Benutzer. Die Sicherstellung der Datensicherheit, Integrität (= Konsistenz) und Synchronisation wird durch das Konzept der Transaktionen erreicht. Für den Datenschutz wird mit Zugriffsrechten gearbeitet Das Transaktionskonzept Transaktionen (TAs) sind die Einheiten integritätserhaltender Zustandsänderungen einer Datenbank. Transaktion DB vorher (konsistent) DB tmp1 DB tmpn DB nachher (konsistent) Transaktionen sind ein wesentliches Konzept für die Integritätserhaltung. Sie dienen zur Synchronisation (Concurrency Control) im Mehrbenutzerbetrieb. In Bezug auf die Datensicherheit (Recovery) sind Transaktionen jedoch auch für Einbenutzersysteme wichtig. Beispiel Bankwesen: Überweisung von Huber an Meier in Höhe von 200,00 DM Möglicher Bearbeitungsplan: (1) Erniedrige Stand von Huber um 200,00 (2) Erhöhe Stand von Meier um 200,00 Möglicher Ablauf: Konto Kunde Stand Meier Huber 1.000, ,00 Konto Kunde Stand (1) (2) Meier 1.000,00 Huber 1.300,00 Systemabsturz Wichtig: Inkonsistenter Datenbankzustand darf nicht entstehen bzw. nicht dauerhaft bestehen bleiben.

2 Eigenschaften von Transaktionen Eine grundlegende Charakterisierung von Transaktionen ist durch das ACID-Prinzip gegeben: 3 Atomicity (Atomarität, alles-oder-nichts -Prinzip) Der Effekt einer Transaktion kommt entweder ganz oder gar nicht zum Tragen. Consistency (Konsistenz, Integritätserhaltung) Durch eine Transaktion wird ein konsistenter Datenbankzustand wieder in einen konsistenten Datenbankzustand überführt. Isolation (Isoliertheit, logischer Einbenutzerbetrieb) Innerhalb einer Transaktion nimmt ein Benutzer Änderungen durch andere Benutzer nicht wahr. Durability (Dauerhaftigkeit, Persistenz) Der Effekt einer abgeschlossenen Transaktion bleibt dauerhaft in der Datenbank erhalten. Eine weitere Forderung ist, daß eine Transaktion in endlicher Zeit bearbeitet werden kann. Erweitertes Konzept: Designtransaktionen Der Entwurf komplexer Systeme (CAD, Software, Multimedia-Präsentationen, ) kann nicht innerhalb weniger Sekunden oder Minuten durchgeführt werden, sondern zieht sich über Tage, Wochen oder Monate hin. Dabei sollen aber durchaus auch inkonsistente Zwischenzustände der Datensicherung unterliegen. Ansätze hierfür sind Techniken zur Verwaltung langer Transaktionen und geschachtelter Transaktionen. Steuerung von Transaktionen begin of transaction Beginn der Befehlsfolge einer neuen Transaktion SQL: Transaktionen werden stets implizit begonnen, es gibt kein begin work o.ä. end of transaction, commit Bestätigung der Transaktion durch den Benutzer Die Änderungen seit Beginn der Transaktion werden endgültig bestätigt Der jetzt erreichte Zustand soll dauerhaft gespeichert werden Der Zustand wird durch den Benutzer für konsistent erklärt SQL: commit work oder nur commit abort transaction Abbruch der Transaktion durch das Programm bzw. den Benutzer (Rücksetzen, ABORT) Die Änderungen der Transaktion werden zurückgesetzt Der ursprüngliche Zustand vor der Transaktion wird wiederhergestellt. SQL: rollback work oder nur rollback 4 Beispiel: UPDATE Konto SET Stand = Stand 200 WHERE Kunde = Huber ; UPDATE Konto SET Stand = Stand WHERE Kunde = Meier ; COMMIT;

3 5 Ein COMMIT kann gelingen: Der neue Zustand wird dauerhaft gespeichert, oder scheitern: Der ursprüngliche Zustand wie zu Beginn der Transaktion bleibt erhalten (bzw. wird wiederhergestellt). Ein COMMIT kann scheitern, wenn die Verletzung von Integritätsbedingungen erkannt wird. Schematischer Ablauf DB vorher (konsistent) Transaktion DB tmp1 DB tmpn rollback gelingt commit mißlingt (abort) DB nachher (konsistent) Lange Transaktionen werden durch die folgenden Anweisungen unterstützt: Definition eines Sicherungspunktes, auf den sich eine (noch aktive) Transaktion zurücksetzen läßt. Die Änderungen dürfen allerdings noch nicht endgültig festgeschrieben werden, da die Transaktion bis hin zur Bestätigung des COMMIT noch scheitern kann. SQL: savepoint identifier Zurücksetzen der aktiven Transaktion auf einen definierten Sicherungspunkt. SQL: rollback to savepoint identifier oder nur rollback to identifier Datensicherheit Eine Aufgabe des DBMS besteht darin, die dauerhafte und konsistente Verfügbarkeit des Datenbestandes sicherzustellen. Ein wichtiger Aspekt ist die Berücksichtigung von Fehlern, die im laufenden Betrieb und auf den Datenträgern auftreten können. Klassifikation von Fehlern Transaktionsfehler Lokaler Fehler einer noch nicht abgeschlossenen Transaktion, z.b. aufgrund Fehler und Abbruch des Anwendungsprogrammes (z.b. Division durch Null, ) Verletzung von Integritätsbedingungen oder Zugriffsrechten expliziter Abbruch der Transaktion (rollback) durch den Benutzer Konflikte mit nebenläufigen Transaktionen. Systemfehler Verlust von Hauptspeicherinformation z.b. wegen Stromausfall, Ausfall der CPU, Absturz des Betriebssystems, etc. Die permanenten Speicher (Platten) sind nicht betroffen. Medienfehler Verlust von permanenten Daten durch Zerstörung des Speichermediums, z.b. Plattencrash, Brand, Wasserschaden, etc.

4 7 Techniken zur Wiederherstellung (Recovery) Wichtigstes Ziel ist es, wieder einen konsistenten Datenbankzustand zu erreichen. Dabei soll soviel an früherer Information wiederhergestellt werden wie möglich, nicht jedoch auf Kosten der Integrität. Abhängig von der Art des aufgetretenen Fehlers gibt es verschiedene Wiederherstellungstechniken: Rücksetzen (bei Transaktionsfehler) Der ursprüngliche Datenbankzustand wie zu Beginn der Transaktion wird wiederhergestellt; der Anfangszustand jeder TA muß deshalb bis zum COMMIT verfügbar gehalten werden. Warmstart (bei Systemfehler) Rücksetzen (UNDO) aller vor dem Fehler noch nicht abgeschlossenen Transaktionen. Kaltstart (bei Medienfehler) Aufsetzen auf einem früheren, gesicherten Datenbankzustand (backup) Nachführen (REDO) aller Transaktionen, die bereits committed waren Rücksetzen (UNDO) aller Transaktionen, deren COMMIT noch ausstand Technische Grundlagen Duplizierung (d.h. gezielte Redundanz) des Datenbankzustandes durch Backup-Techniken (Bänder, Spiegelplatten, zusätzliches Rechenzentrum in anderer Stadt, ) Logfiles (logging): Mitprotokollierung der laufenden Aktionen, Beginn und Ende (COMMIT, ABORT) von Transaktionen. Logfiles entstehen sequentiell > schnelles Schreiben möglich Integrität und Integritätsbedingungen (IB) Für die Beispiele betrachten wir das folgende relationale Datenbankschema: Kunde (KName, KAdr, Kto) Auftrag (KName, Ware, Menge) Lieferant (LName, LAdr, Ware, Preis) 8 Beispiele für Integritätsbedingungen: (IB1) Kein Kundenname darf mehrfach in der Relation Kunde vorkommen. (IB2) Jeder Kundenname in Auftrag muß auch in Kunde vorkommen. (IB3) Kein Kunden-Kontostand darf unter -100 DM absinken. (IB4) Das Konto von Weiß darf überhaupt nicht überzogen werden. (IB5) Nur solche Waren dürfen bestellt werden, für die es mindestens einen Lieferanten gibt. (IB6) Der Brotpreis darf nicht erhöht werden. Man unterscheidet statische Integritätsbedingungen: Einschränkungen der möglichen Datenbankzustände dynamische Integritätsbedingungen: Einschränkungen der möglichen Zustandsübergänge sowie modellinhärente Integritätsbedingungen: Durch das Datenmodell vorgegeben explizite Integritätsbedingungen: Durch den Benutzer formuliert

5 Inhärente Integritätsbedingungen des relationalen Modells: Typintegrität (Domains) Werte müssen zum Typ passen (Spezialfall: Zulässigkeit von Nullwerten). Von den Systemen werden verschiedene primitive Datentypen unterstützt (herstellerabhängig). Benutzerdefinierte Domains sind z.b. im SQL-Standard vorgesehen und werden zunehmend unterstützt. Schlüsselintegrität Die Datenbank darf keine zwei Tupel mit gleichem Schlüssel enthalten. Referentielle Integrität (Fremdschlüsselintegrität) Wenn Relation R einen Schlüssel von Relation S enthält, dann muß für jedes Tupel in R auch ein entsprechendes Tupel in S vorkommen. Beispiel: IB2. 9 Explizite Integritätsbedingungen Formulierung in der Anfragesprache bzw. unter möglichst geringer Erweiterung der Anfragesprache. Beispiel: Integritätsbedingungen in relationaler Algebra z.b. IB2: π KName (Auftrag) π KName (Kunde) z.b. IB3: σ Kto < 100 (Kunde) = Der Relationenkalkül eignet sich hervorragend, da sich allgemeine Aussagen gut formulieren lassen. 10 Überwachung von Integritätsbedingungen a) durch die Anwendungsprogramme Nachteile: hoher Programmieraufwand fehleranfällig (z.b. Inkonsistenzen zwischen verschiedenen Programmen) nicht unter zentraler Kontrolle (DBA und DBS) b) durch Integritätsmonitor als Komponente des DB-Systems. Realisierung: DB-Trigger Nachteil: Effizienzprobleme Formale Beschreibung von Integritätsbedingungen durch das Tripel (Auslöser, Bedingung, Aktion), engl. ECA-Rules (Event, Condition, Action): Auslöser: (Wann ist die Bedingung zu prüfen?) nach INSERT, DELETE, UPDATE oder bei Abschluß einer Transaktion Bedingung: (die eigentliche Bedingung) Aktion: (Was ist bei Verletzung der Bedingung zu tun?) Zurückweisen der Änderung Zurücksetzen der Transaktion Automatisches Auslösen von Folgeänderungen Externes Programm aufrufen (z.b. ausführliche Fehlermeldung ausgeben; Datenbankadministrator durch Mail benachrichtigen; )

6 Synchronisation (Concurrency Control) Nach dem ACID-Prinzip Isolation sollen Transaktionen im logischen Einbenutzerbetrieb ablaufen, d.h. innerhalb einer Transaktion ist ein Benutzer von den Aktivitäten anderer Benutzer nicht betroffen. Probleme bei unkontrollierter nebenläufiger Ausführung von Transaktionen Ist die Isolierung der Transaktionen in einem Datenbanksystem nicht sichergestellt, können verschiedene Anomalien auftreten: Verlorengegangene Änderungen (Lost Updates) Zugriff auf schmutzige Daten (Dirty Read, Dirty Write) Nicht-reproduzierbares Lesen Phantomproblem Diese Anomalien werden unter anderem am Beispiel der folgenden Flugdatenbank erläutert: Passagiere FlugNr Name Platz LH745 LH745 Müller Meier 3A 6D LH745 Huber 5C BA932 Schmidt 9F BA932 Huber 5C Fluginfo FlugNr AnzPass LH745 3 BA (1) Verlorengegangene Änderungen (Lost Update) Änderungen einer Transaktion können durch Änderungen anderer Transaktionen überschrieben werden und dadurch verloren gehen. Beispiel: Zwei Transaktionen T1 und T2 führen je eine Änderung auf demselben Objekt aus: UPDATE Fluginfo SET AnzPass = AnzPass + 1 WHERE FlugNr = BA932 ; Möglicher Ablauf: T1 A 1.i Read Fluginfo[AnzPass] > x 1 A 1.i+1 x 1 := x 1 +1 A 1.i+2 Write x 1 > Fluginfo[AnzPass] Ergebnis: Beide Transaktionen haben die Anzahl der Passagiere (für denselben Flug) jeweils um eins erhöht. Obwohl zwei Erhöhungen stattgefunden haben, ist in der Datenbank nur die Erhöhung von T1 wirksam. Die Änderung von T2 ist verlorengegangen. T2 A 2.j Read Fluginfo[AnzPass] > x 2 A 2.j+1 x 2 := x 2 +1 A 2.j+2 Write x 2 > Fluginfo[AnzPass]

7 13 (2) Zugriff auf schmutzige Daten (Dirty Read, Dirty Write) Als schmutzige Daten bezeichnet man Objekte, die von einer noch nicht abgeschlossenen Transaktion geändert wurden. Beispiel: T1 erhöht das Gehalt um 500 Euro, wird aber später abgebrochen. T2 erhöht das Gehalt um 5% und wird erfolgreich abgeschlossen. Möglicher Ablauf: A 1.1 T1 UPDATE Personal SET Gehalt = Gehalt + 500; ROLLBACK; Ergebnis: Der Abbruch der ändernden Transaktion T1 macht die geänderten Werte ungültig, sie werden zurückgesetzt. Die Transaktion T2 hat jedoch die geänderten Werte gelesen (Dirty Read) und weitere Änderungen darauf aufgesetzt (Dirty Write). Verstoß gegen ACID: Dieser Ablauf verursacht einen dauerhaften, fehlerhaften Datenbankzustand (Consistency), bzw. T2 muß nach COMMIT zurückgesetzt werden (Durability). A 2.1 T2 UPDATE Personal SET Gehalt = Gehalt * 1.05; COMMIT; (3) Nicht-reproduzierbares Lesen Eine Transaktion sieht während ihrer Ausführung unterschiedliche Werte desselben Objekts. 14 Beispiel: T1: Gib die Fluginfo für alle Flüge und nochmal die Anzahl der Passagiere für BA932 aus. T2: Buche den Platz 3F auf dem Flug BA932 für Passagier Meier. Möglicher Ablauf: A 1.1 A 1.2 T1 SELECT * FROM Fluginfo; SELECT AnzPass FROM Fluginfo WHERE FlugNr = BA932 ; Ergebnis: Die Anweisungen A 1.1 und A 1.2 liefern ein unterschiedliches Ergebnis für den Flug BA932, obwohl die Transaktion T1 den Datenbankzustand nicht geändert hat. T2 A 2.1 INSERT INTO Passagiere (*) VALUES ( BA932, Meier, 3F ); A 2.2 UPDATE Fluginfo SET AnzPass = AnzPass + 1 WHERE FlugNr = BA932 ; COMMIT; A 2.3

8 15 (4) Phantomproblem Das Phantomproblem ist ein nicht-reproduzierbares Lesen in Verbindung mit Aggregatfunktionen. Beispiel: AnzPass werde jetzt durch COUNT(*) berechnet und nicht mehr in FlugInfo gespeichert. T1: Drucke die Passagierliste sowie die Fluginfo für den Flug LH745. T2: Buche den Platz 7D auf dem Flug LH745 für Phantomas. Möglicher Ablauf: T1 A 1.1 SELECT * FROM Passagiere WHERE FlugNr = LH745 ; A 1.2 SELECT AnzPass = COUNT(*) FROM Passagiere WHERE FlugNr = LH745 ; Ergebnis: Für die Transaktion T1 erscheint Phantomas noch nicht auf der Passagierliste, obwohl er in der danach ausgegebenen Anzahl der Passagiere schon berücksichtigt ist. A 2.1 A 2.2 T2 INSERT INTO Passagiere VALUES ( LH745, Phantomas, 7D ); COMMIT; 16 Serialisierbarkeit Eine wichtiges Konzept, um die ACID-Eigenschaft Isolation garantieren zu können, ist die Serialisierbarkeit von Transaktionen. Das bedeutet, die nebenläufige Bearbeitung von Transaktionen geschieht für den Benutzer transparent, d.h. als ob die Transaktionen (in einer beliebigen Reihenfolge) hintereinander ausgeführt worden wären. Begriffe Ein Schedule für eine Menge {T 1,, T n } von Transaktionen ist eine Folge von Aktionen, die durch Mischen der Aktionen der T i s entsteht, wobei die Reihenfolge innerhalb der jeweiligen Transaktion beibehalten wird. Ein serieller Schedule ist ein Schedule S von {T 1,, T n }, in dem die Aktionen der einzelnen Transaktionen nicht untereinander verzahnt sondern in Blöcken hintereinander ausgeführt werden. Ein Schedule S von {T 1,, T n } ist serialisierbar, wenn er dieselbe Wirkung hat wie ein beliebiger serieller Schedule von {T 1,, T n }. Die obigen Problemfälle stellen Beispiele für nicht-serialisierbare Schedules dar. Die zentrale Konsistenzbedingung für die Ablaufsteuerung nebenläufiger Transaktionen ist: Nur serialisierbare Schedules dürfen zugelassen werden.

9 17 Techniken zur Synchronisation Pessimistische Ablaufsteuerung (Sperrverfahren, Locking) Durch Lese- und Schreibsperren wird verhindert, daß Änderungen sich auf nebenläufige Transaktionen auswirken können. Nachteil: Schreibende, aber auch nur-lesende Transaktionen müssen ggf. warten, bis andere schreibende (oder auch lesende) Transaktionen abgeschlossen sind. Vorteil: In der Regel nur wenige Rücksetzungen aufgrund von Synchronisationsproblemen nötig. > Standardverfahren in kommerziellen DBMS Optimistische Ablaufsteuerung (Zeitstempelverfahren) Transaktionen dürfen ungehindert bis zum COMMIT arbeiten. Bei COMMIT wird geprüft, ob ein Konflikt aufgetreten ist (Validierung). Die Transaktion wird ggf. zurückgesetzt. Die Validierung wird anhand von Zeitstempeln durchgeführt ( Gab es seit Beginn der Transaktion ein Commit einer anderen Transaktion, das dieselben Daten betrifft? ). > nur geeignet, falls Konflikte zwischen Schreibern sehr selten auftreten. Nur-lesende Transaktionen können sich gegenseitig nicht beeinflussen, da Synchronisationsprobleme nur im Zusammenhang mit Schreiboperationen auftreten. Es gibt deshalb die Möglichkeit, Transaktionen als nur-lesend zu markieren, wodurch die Synchronisation vereinfacht und ein höherer Parallelitätsgrad ermöglicht wird: SET TRANSACTION READ-ONLY (kein INSERT, UPDATE, DELETE) SET TRANSACTION READ-WRITE (alle Zugriffe möglich) 10.5 Datenschutz Begriff: Schutz der Daten vor Zugriffen und Manipulation durch unberechtigte Benutzer. Allgemeine Maßnahmen Identifikation des Benutzers (etwa durch Paßwort oder sogar durch Personal) Schutz vor physischen Angriffen (Diebstahl von Magnetbändern, Anzapfen von Datenübertragungsleitungen, etc.) Betriebssystem muß Zugriff auf DB-Files durch fremde Programme verhindern. Datenverschlüsselung DBS-spezifische Techniken Sichten (Views) als Schutzmechanismus (insbesondere read-only Sicht). Es ergeben sich Probleme, wenn auch Änderungen erlaubt sein sollen. Verwaltung von Rechten entsprechend einem Sicherheitsmodell Discretionary Access Control Mandatory Access Control Umsetzung: In relationalen Systemen können Rechte vom System über eine Systemtabelle verwaltet und innerhalb des Systems weitergegeben werden. 18

10 19 Das Sicherheitsmodell DAC Für das Modell Discretionary Access Control (DAC) werden die folgenden Informationen verwaltet: Wer hat das Recht? (Sicherheitssubjekte) > Benutzeridentifikator für einzelne Benutzer oder Menge von Benutzern Auf welche Teile der Datenbank bezieht sich das Recht? (Sicherheitsobjekte) > beschrieben durch Anfragesprache oder Datendefinitionssprache Worin besteht das Recht (erlaubte Operationen)? > Zugriffsrechte für Lesen und für Ändern (Einfügen, Entfernen, Modifizieren) Darf das Recht weitergegeben werden? Grundprinzipien: > Jeder Benutzer hat Rechte bzgl. der von ihm erzeugten Objekte. > Datenbankadministrator (DBA) hat alle Rechte. Bewertung: Einfaches und sehr gebräuchliches Modell Erzeuger von Daten sind mit der Verantwortung für deren Sicherheit belastet. Abhängig von der Granularität der Objekte (Datenbank, Relationen, Tupel) kann die Verwaltung der Rechte sehr aufwendig werden. 20 Das Sicherheitsmodell MAC Beim Modell Mandatory Access Control (MAC) werden Subjekte und Objekte mit einer Sicherheitseinstufung markiert (z.b. streng geheim, geheim, vertraulich, unklassifiziert ): Vertrauenswürdigkeit ( Clearance ) eines Subjektes s: clear(s) Sensitivität ( Classification ) eines Objektes o: class(o) Für die Zugriffskontrolle werden die folgenden Regeln verwendet: Ein Subjekt s darf ein Objekt o nur lesen, wenn das Objekt eine geringere Sicherheitseinstufung besitzt: class(o) clear(s) Beim Ändern muß ein Objekt o mindestens die Einstufung des schreibenden Subjektes s erhalten: clear(s) class(o) Die zweite Regel kontrolliert den Informationsfluß, um den Mißbrauch durch autorisierte Benutzer zu verhindern. Eine streng geheime Information könnte sonst durch einen berechtigten Benutzer öffentlich zugänglich gemacht werden (Write-Down). Bewertung Potentiell größere Sicherheit durch abgestufte Sicherheitsklassen Jedes Objekt wird einzeln eingestuft > hoher Verwaltungsaufwand in der Datenbank. Benutzer mit unterschiedlicher Einstufung können nur schwer zusammenarbeiten, da von höher eingestuften Benutzern veränderte Daten von niedriger eingestuften Kollegen nicht mehr lesbar sind.