Grundlagen von Datenbanken SS Synchronisation paralleler Transaktionen

Transkript

1 Grundlagen von Datenbanken SS Synchronisation paralleler Transaktionen Prof. Dr. Stefan Böttcher Universität Paderborn Agenda: Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-1

2 Wesentliche Eigenschaften von Transaktionen Transaktionen ( = mehrere Datenbank-Aktionen zusammengefasst zu einer Einheit ) sind : Eigenschaft Bedeutung Beispiel A atomar ganz oder garnicht Überweisung C consistent korrekt Dateneingabe I isoliert ungestört von parallelen Transaktionen Flugbuchung D dauerhaft Daten gesichert Auszahlung Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-2

3 Transaktionsprozeduren Transaktionsprozeduren = Prozeduren / Funktionen / Quellcodefragmente, die als atomare Einheit (ganz oder garnicht) auf der Datenbank ausgeführt werden sollen. Syntax zur Kennzeichnung der Einheit, z.b. Anfang und Ende der Transaktionsprozedur wird bestimmt durch einen der beiden Befehle Commit oder Rollback oder am Anfang steht der Befehl tbegin( ) am Ende steht tcommit( ) oder tabort( ) Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-3

4 Transaktionen einer Transaktionsprozedur Transaktion (= Ausführung einer Transaktionsprozedur auf der Datenbank) eine Folge aus Lese- und oder Schreiboperationen auf der Datenbank, denen ein Begin vorangestellt ist, und an deren Ende entweder Commit oder Abort ausgeführt wird. Commit schreibt Änderungen auf der Datenbank fest, Abort macht die Änderungen dieser Transaktion auf der Datenbank rückgängig. i.d.r. gibt es mehrere Transaktionen pro Transaktionsprozedur. Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-4

5 Transaktionsprozedur Beispiel 1 (SQL) void umbuchung ( int kto1, int kto2, int wieviel ) { stmt.executeupdate( rollback ) ; stmt.executeupdate( update K.stand = K.stand + + wieviel + where K.kto = + kto1 ) ; stmt.executeupdate( update K.stand = K.stand - + wieviel + where K.kto = + kto2 ) ; stmt.executeupdate( commit ) ; } Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-5

6 Mögliche Transaktionen zu Beispiel 1 Eine Beispieltransaktion (T1) < T1: Start > < T1: Konto1 = Konto > < T1: Konto2 = Konto2-100 > < T1: Commit > Eine andere Beispieltransaktion (T2) < T2: Start > < T2: Konto77 = Konto > < T2: Konto88 = Konto88-44 > < T2: Commit > Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-6

7 Transaktionsprozedur Beispiel 2 (Poet OODB) int bestelle ( int kto, Bestellung b ) { tbegin( ) ; aktuellerpreis = DB.Bestellungen.insert(b) ; DB.Konten( kto ). stand -= aktuellerpreis ; if ( DB.Konten( kto ). ueberziehungslimiterschoepft ( ) ; { tabort( ) ; // Datenbankoperationen dieser T zurücksetzen return 255 ; } else { tcommit( ) ; // Datenbankoperationen dieser T festschreiben return 1; } } Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-7

8 Mögliche Transaktionen zu Beispiel 2 Eine Beispieltransaktion (T3) < T3: Start > < T3: Bestellungen.insert( 33, Meier, Teil66 ) > < T3: Konto22 = Konto > < T3: read( Konto22 ) > // noch genug auf dem Konto < T3: Commit > Eine andere Beispieltransaktion (T4) < T4: Start > < T4: Bestellungen.insert( 33, Meier, Teil66 ) > < T4: Konto22 = Konto > < T4: read( Konto22 ) > // nicht genug auf dem Konto < T4: Abort > Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-8

9 Parallele Transaktionen mehrere Transaktionen arbeiten gleichzeitig auf der Datenbank z.b. verschiedene Bestellungen und Umbuchungen und Kontostandsabfragen gleichzeitig Ziele: hoher Parallelitätsgrad erwünscht kritischer Abschnitt geht nicht, fehlerhafte parallele Abläufe sollen vermieden werden 4 typische Fehlerklassen: Lesen schmutziger Daten (= dirty read) nicht wiederholbares Lesen (= non-repeatable read) verlorene Änderung (= lost update) Phantomproblem (= phantom problem) Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-9

10 Fehlerklasse Lesen schmutziger Daten (= Dirty Read) // Summe aller Konten ist 0 < T1: Start > < T1: Konto1 = Konto1-100 > < T1: Konto2 = Konto > < T1: Commit > < T2: Start > < T2: read(konto1) > < T2: read(konto2) > < T2: Commit > // Summe ist -100?? Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-10

11 Nicht-wiederholbares Lesen (= non-repeatable read) < T1: Start > < T1: Konto1 = Konto1-100 > < T1: Commit > < T2: Start > < T2: read(konto1) > < T2: read(konto1) > //?? 2 verschiedene Werte < T2: Commit > Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-11

12 Fehlerklasse Verlorene Änderung (= lost update) < T1: Start > < T1: temp1 = Konto > < T1: Konto1 = temp1 > < T1: Commit > < T2: Start > < T2: temp2 = Konto > < T2: Konto1 = temp2 > < T2: Commit > Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-12

13 Hintergrund der Fehlerklassen (1) - Konflikt Operationen aus T1 und T2 stehen zu einander in Konflikt 2 Operationen (read oder write) auf demselben Objekt (z.b. demselben Datenwert) stehen zueinander in Konflikt, wenn mindestens eine der beiden Operationen eine Schreiboperation (write) ist. Idee: ( Konflikt = Nichtvertauschbarkeit ) 2 Operationen stehen zueinander in Konflikt, wenn sie nicht vertauschbar sind Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-13

14 Hintergrund der Fehlerklassen (2) - Abhängigkeit Operationen jeder Ti gehören unteilbar zusammen Wenn o1 aus T1 zu o2 aus T2 in Konflikt steht, kommt es auf die Reihenfolge von o1 und o2 an: Durch o1 vor o2 entsteht eine Abhängigkeit T1 vor T2 durch o2 vor o1 entsteht eine Abhängigkeit T2 vor T1 T1 vor T2 wäre korrekt oder T2 vor T1 wäre korrekt, aber T1 vor T2 und T2 vor T1 (zyklische Abhängigkeit) ist nicht korrekt. Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-14

15 Gemeinsamkeiten der Fehlerklassen Operationen aus T1 und T2 stehen so zu einander in Konflikt, dass zyklische Abhängigkeiten entstehen T1 vor T2 und T2 vor T1 Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-15

16 Fehlerklasse Lesen schmutziger Daten (= Dirty Read) // Summe aller Konten ist 0 < T1: Start > < T1: Konto1 = Konto1-100 > < T1: Konto2 = Konto > < T1: Commit > < T2: Start > < T2: read(konto1) > < T2: read(konto2) > < T2: Commit > // Summe ist -100?? Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-16

17 Nicht-wiederholbares Lesen (= non-repeatable read) < T1: Start > < T2: Start > < T2: read(konto1) > < T1: Konto1 = Konto1-100 > < T2: read(konto1) > //?? 2 verschiedene Werte < T1: Commit > < T2: Commit > Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-17

18 Fehlerklasse Verlorene Änderung (= lost update) < T1: Start > < T1: temp1 = Konto > < T2: Start > < T2: temp2 = Konto > < T2: Konto1 = temp2 > < T2: Commit > < T1: Konto1 = temp1 > < T1: Commit > Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-18

19 Formale Definition von Serialisierbarkeit (1) Eine Transaktion Ti, von Operationen, T Lies x Schreibe i i ( i ) ist eine partielle Ordnung einer Menge x x ist Datenelement Abbruch, Ende,, i i i mit einer zugehörigen partiellen Ordnungsrelation folgenden Eigenschaften: Abbruch i Abbruch i T i bzw. ist die letzte Operation in d.h. für i alle an anderen Operationen oi T i gilt, oi i Abbruch i bzw. o. i i Ende i - Für jedes Paar oi, o, die in Konflikt stehen, ist 1 i T 2 i entweder o o oder o o. i1 i i i 2 2 i i 1 Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-19 i Ende T i. Ende, T i mit

20 Formale Definition von Serialisierbarkeit (2) Eine vollständige Historie einer Menge von n Transaktionen mit Ordnungsrelationen 1 i n ist eine partielle Ordnung H, H mit Ordnungsrelation H n T i 1 i n H i 1 i und wobei alle Paare von Operationen i H, 1, o2 H die zueinander in Konflikt stehen, werden durch die vollständige Historie geordnet, d. h. 1 H o 2 oder o2 H o 1. H o o, T i Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-20

21 Formale Definition von Serialisierbarkeit (3) Eine Historie Historie H 2 H 1, H' H folgenden Eigenschaften: H' Für Für H alle alle o o 1 1 H ', o, o 2 2 H H' H ' ist ein Präfix einer vollständigen, also eine partielle Ordnung mit gilt gilt : o o o o H' o H'. Historien können also Transaktionen enthalten, die noch nicht vollständig ausgeführt sind. : Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie H ' H o 2 2 o 2 1 H o 2. 1

22 Formale Definition von Serialisierbarkeit (4) Zwei Historien von Transaktionen heißen aquivalent, wenn sie über derselben Menge von Transaktionen definiert sind, dieselben Operationen enthalten und zueinander in Konflikt stehende Operationen nicht abgebrochener Transaktionen in derselben Weise ordnen. Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-22

23 Formale Definition von Serialisierbarkeit (5) Eine vollständige Historie von Transaktionen heißt seriell, wenn für jedes Paar alle Operationen von von T j T T i, T j T i von Transaktionen entweder vor allen Operationen auftreten, oder umgekehrt alle Operationen von vor allen Operationen von auftreten. j T i Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-23

24 Formale Definition von Serialisierbarkeit (6) Eine vollständige Historie von Transaktionen heißt serialisierbar, wenn sie äquivalent zu einer seriellen Historie ist Eine Historie heißt serialisierbar, wenn der Präfix ihrer mit Ende (=Commit) abschlossenen Transaktionen serialisierbar ist. Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-24

25 Serialisierbarkeitstheorem (7) Der Abhängigkeitsgraph einer Historie von Transaktionen enthält einen Knoten pro Transaktion und für jede Abhängigkeit T1 vor T2 eine Kante von T1 nach T2. Eine Historie von Transaktionen ist genau dann serialisierbar, wenn ihr Abhängigkeitsgraph projiziert auf die mit Commit abgeschlossenen Transaktionen zyklenfrei ist. Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-25

26 2-Phasen-Sperren Lese- und Schreibsperren Wird eine angeforderte Sperre nicht gewährt, muss T warten bis die Sperre gewährt wird Operationen auf Sperren: rlock( T, A ) = Transaktion T fordert Lesesperre auf A an wlock( T, A ) = Transaktion T fordert Schreibsperre auf A an unlock( T, A ) = Transaktion T gibt Sperre auf A wieder frei auch benutzte Kurzschreibweise: lock( T, A ) = Transaktion T fordert Lese- oder Schreibsperre auf A an Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-26

27 2-Phasen-Sperren - Legalität T hält beim Schreiben eines Objektes A eine Schreibsperre und beim Lesen eines Objektes eine Schreib- oder Lesesperre Legalität: Für alle Operationen write(t, A) T gilt: es gibt wlock(t,a) T und unlock(t,a) T mit wlock( T, A ) < H write( T, A ) < H unlock( T, A ) Für alle Operationen read(t, A) T gilt: es gibt lock(t,a) T und unlock(t,a) T mit lock( T, A ) < H read( T, A ) < H unlock( T, A ) Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-27

28 2-Phasen-Sperren Sperr-Regel Schreibsperren (wlock) auf A verbieten gleichzeitige andere Sperren auf A, und Lesesperren (rlock) auf A verbieten gleichzeitige andere Schreibsperren auf A rlock wlock rlock ok wait wlock wait wait Sperr-Regel: Für alle wlock(ti,a), unlock(ti,a), wlock(tk,a), unlock(tk,a) mit i k gilt: unlock(ti,a) < H wlock(tk,a) v unlock(tk,a) < H wlock(ti,a) Für alle rlock(ti,a), unlock(ti,a), wlock(tk,a), unlock(tk,a) mit i k gilt: unlock(ti,a) < H wlock(tk,a) v unlock(tk,a) < H rlock(ti,a) Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-28

29 Warum 2-Phasigkeit notwendig ist // Summe aller Konten ist 0 ( z.b. A+B = 0 ) // T1 bucht 100 von A nach B um, T2 liest A und B wlock( T1, A) < T1: A = A > // write(t,a) unlock(t1,a) rlock(t2,a) ; rlock(t2,b) < T2: read(a) > < T2: read(b) > unlock(t2,a) ; unlock(t2,b) wlock(t1,b) // Summe A+B ist -100?? < T1: B = B > unlock(t1,b) // dirty read trotz Legalität und eingehaltener Sperr-Regel Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-29

30 2-phasige Transaktionen Jede Transaktion T muss mit der Freigabe ihrer Sperren warten, bis sie alle Sperren erhalten hat. Sie macht ihre erste Sperrfreigabe erst nach allen Sperranforderungen 2-Phasigkeit einer Transaktion T: Für alle rlock(t,a), wlock(t,b), unlock(t,c) gilt: rlock(t,a) < H unlock(t,c) und wlock(t,b) < H unlock(t,c) Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-30

31 Serialisierbarkeit durch 2-Phasen-Sperren 2-Phasen-Sperren garantiert serialisierbare Historien Serialisierbarkeitssatz für 2-Phasen-Sperren: Jede Historie, die nur aus legalen 2-phasigen Transaktionen besteht und die Sperr-Regel einhält ist serialisierbar. Beweis: Widerspruchsbeweis über die Ordnung < H. Angenommen, die Historie H ist nicht serialisierbar, dann gibt es einen Zyklus im Serialisierbarkeitsgraph mindestens 1 der am Zyklus beteiligten Transaktionen ist nicht legal oder nicht 2-phasig oder H verletzt die Sperr-Regel Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-31

32 Parallele Validierung (nach Kung & Robinson) (1) Zeit Transaktionen T haben 2 oder 3 Phasen T lies aus der Datenbank und schreibe auf lokale Kopien validiere (=prüfe), ob Abhängigkeiten azyklisch sind, d.h., dass T nicht von neuerer Transaktion abhängt nur wenn Validierung erfolgreich war, schreibe lokale Kopien in die Datenbank Lesephase Validierungsphase optionale Schreibphase Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-32

33 Parallele Validierung (nach Kung & Robinson) (2) Zeit Transaktionen T bekommen am Ende der Lesephase ihren Zeitstempel Neuere Transaktionen validieren gegen ältere T lies aus der Datenbank und schreibe auf lokale Kopien hier bekommt die Transaktion T ihren Zeitstempel validiere (=prüfe), ob Abhängigkeiten azyklisch sind, d.h., dass T nicht von neuerer Transaktion abhängt wenn Validierung erfolgreich war, schreibe lokale Kopien in die Datenbank Lesephase Validierungsphase optionale Schreibphase Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-33

34 Parallele Validierung (nach Kung & Robinson) (3) Grundideen: 1. Transaktionen werden nicht gesperrt, müssen nicht warten 2. Lasse neuere Transaktionen vordrängeln, aber auf eigenes Risiko, d.h., wenn sie zu früh gestartet wurden, müssen sie abbrechen und wiederholt gestartet werden. 3. Neuere Transaktionen sind die, die einen späteren Zeitstempel bekommen, d.h. später mit der Lesephase fertig wurden. 4. Um die Datenbank nicht zu beschädigen, schreiben Transaktionen in der Lesephase nur auf lokale Kopien, und nur nach erfolgreicher Validierung schreiben sie (in der Schreibphase) in die Datenbank Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-34

35 Parallele Validierung (nach Kung & Robinson) (4) Wenn es eine Abhängigkeit Tneu Talt geben könnte, breche Tneu ab, d.h. Tneu schreibt nicht in die Datenbank (Tneu hat keine Schreibphase) Zeit Talt Abhängigkeiten Talt Tneu sind o.k. L V [& S] Tneu Lesephase Validierung [ & Schreibphase ] Validierung von Tneu verhindert diese Abhängigkeit Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-35

36 Validierung unterscheidet 3 Gruppen älterer Transaktionen Zeit Talt1 o.k. r Tneu wird bei jeder Abhängigkeit Tneu Talt abgebrochen (zyklische Abhängigkeit wäre möglich) Talt2 writeset(talt2) readset(tneu) = v [& w] r Talt3 writeset(talt3) readset(tneu) = und writeset(talt3) writeset(tneu) = v [& w] r Tneu Lesephase v [& w] Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-36 Validierung [& Schreibphase]

37 Implementierung der Validierungsphase von Tneu Tneu unterteilt alle älteren Transaktionen in 3 Gruppen: 1. Talt1: Transaktionen, die beendet werden, bevor Tneu in der Lesephase ist 2. Talt2: Transaktionen, die beendet werden, während Tneu in der Lesephase ist 3. Talt3: Transaktionen, die beendet werden, nachdem Tneu in der Lesephase war Validierung liefert genau dann false, wenn es eine T Talt2 gibt mit writeset(talt2) readset(tneu) oder wenn es eine T Talt3 gibt mit writeset(talt3) ( readset(tneu) writeset(tneu) ) Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-37

38 Korrektheit der parallelen Validierung time Tneu Talt kann es nicht geben für Told1 o.k. Talt1, denn : ende von Talt1 vor start von Tneu r Talt2, Talt3, weil Validierung das ausschließt Told2 Tneu validiert erfolgreich v writeset(talt2) readset(tneu) = [& w] r Told3 writeset(talt3) readset(tneu) = writeset(talt3) writeset(tneu) = v [& w] r Tnew Lesephase v [& w] Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-38 Validierung [& Schreibphase]

39 Transaktionsprozedur zum Phantomproblem TP1: EXEC SQL insert into Konten values( KontoNr3, 3000 ) ; TP2: EXEC SQL select Count(KontoNr) into :Kontenanzahl from Konten if ( Kontenanzahl 0 ) // zeige Durchschnittsbetrag { EXEC SQL select SUM(KontoStand) into :Summe from Konten println(''durchschnittsbetrag ist :'', Summe / Kontenanzahl ) ; } Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-39

40 Transaktionen zum Phantomproblem T2 stellt fest, dass KontoNr3 nicht existiert < T1: Start > < T1: insert (KontoNr3, 3000 ) > < T1: Commit > < T2: Start > < T2: read(kontonr1) > < T2: read(kontonr2) > < T2: not exists(kontonr3) > < T2: read(kontostand1) > < T2: read(kontostand2) > < T2: read(kontostand3) > < T2: Commit > Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-40

41 Konflikt mit Phantom-Tupeln T2 stellt fest, dass KontoNr3 nicht existiert < T2: not exists(kontonr3) > < T1: insert (KontoNr3, 3000 ) > Vertauschung der Operationen ändert das Ergebnis Konflikt < T1: insert (KontoNr3, 3000 ) > T2 stellt fest, dass KontoNr3 existiert < T2: read(kontonr3) > Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-41

42 Prädikatives Sperren Problem des physischen Sperrens: Es sperrt die gelesenen Tupel der Relation, d.h. nur die gelesenen und als wahr interpretierten Tupel des Schemas Idee zur Verhinderung des Phantomproblems: Sperre alle gelesenen Tupel des Schemas, auch die als falsch interpretierten Tupel des Schemas Realisierung: Benutze Sperren mit Formeln (z.b. des Tupelkalküls) für Mengen von gesperrten Tupeln des Schemas Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-42

43 Prädikatives Sperren - Beispiel Betrag rlock( T1, { t Konto t.betrag > 5000 } ) 5000 wlock( T2, { t Konto t.name >= Q } ) Schema( Konto ) Name Q { t Konto t.betrag > 5000 } { t Konto t.name >= Q } t.betrag > 5000 t.name >= Q ist erfüllbar T2 Sperre nicht gewähren Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-43

44 Prädikatives Sperren - Kritik Hauptkritikpunkt: Test für die Sperrvergabe braucht einen Beweis dauert zu lange Aber unvollständige Beweiser genügen O(Vergleichsanzahl³) Im Zweifelsfall: Sperre nicht gewähren, d.h. Transaktion warten lassen { t Konto t.betrag > 5000 } { t Konto t.name >= Q } t.betrag > 5000 t.name >= Q ist erfüllbar T2 Sperre nicht gewähren Alternativvorschläge: 1. Indexsperren (konzeptuell: eingeschränkte prädikative Sperren) 2. Sperren der EOF-Marke (Hauptkritikpunkt: blockiert alle Einfüger) Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-44

45 Prädikative Validierung Idee zur Verhinderung des Phantomproblems: Benutze zur Validierung Anfrage statt Beweis T validiert von ihr geschriebene alte und neue Werte von Tupeln der Relation gegen Formeln (z.b. des Tupelkalküls) der Lese- und Schreibmengen älterer Transaktionen, d.h. Formeln beschreiben von älteren Transaktionen gelesene bzw. geschriebene Tupel des Schemas + möglich durch Anfrage effizient durchführbar in jedem DBMS implementierbar Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-45

46 Prädikative Validierung - Beispiel Betrag read-set( Talt, { t Konto t.betrag > 5000 } ) write-set( Tneu, Konto + { ( Name= Reich, Betrag=6000 ) } ) Konto - { ( Name= Reich, Betrag=4000 ) } Schema( Konto ) Name Q Reich { t { ( Name= Reich, Betrag=6000 ), ( Name= Reich, Betrag=4000 ) } t.betrag > 5000 } Validierung von Tneu scheitert Tneu abbrechen und neu starten Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Folie 9-46