t Datenbank(schema) besteht aus Relationen, Entw

7 Datenbanksysteme
➢ Bisheriger Kenntnisstand über (relationale) Datenbanken:
❏ Datenbank(schema) besteht aus Relationen, Entwurf guter“ Schemata
”
❏ Zugriff über SQL: Anfragen, Änderungen, DDL, Zugriffskontrolle, . . .
❏ Trennung logischer und interner Aspekte ( Datenunabhängigkeit“)
”
❏ bislang jedoch: lediglich die Ein-Benutzer-Sicht“
”
➢ Verwendung eines Datenbanksystems bietet mehr
❏ Transaktions-Management
❏ Verteilung
❏ Tuning-Möglichkeiten, Automatische Optimierung
❏ Programmierungsschnittstellen
❏ Objektorientierte Erweiterungen, Web-Anbindung, Geo-/Spatial-DBen, Temporale DBen,
Förderierte/Multi-Datenbanken, . . .
Im Folgenden nur ein grober Überblick über einige dieser Aspekte
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-1
Stichworte
➢ Transaktions-Management
❏ Parallelität: kontrollierter Mehrbenutzerbetrieb ( Concurrency Control“)
”
❏ Fehlertoleranz: Automatische“ Korrektur im Fehlerfall ( Recovery“): Technische Störungen
”
”
(Stromausfall, Festplatten-Crash, . . .) können abgefangen werden
➢ Verteilung: Verschiedene (Teile von) Datenbanken können an unterschiedlichen Standorten
(Rechner, Ort) betrieben, aber gemeinsam genutzt werden.
➢ Tuning-Möglichkeiten: Ausnutzung der Trennung logische ↔ physische Ebene: Speicherungsstrukturen, Indexe, Anfrageoptimierung
➢ Programmierungsschnittstellen: Der typische Zugriff auf Datenbanken geschieht durch
Programme, nicht über interaktive SQL-Schnittstellen
❏ Aufruf von SQL-Kommandos aus normalen“ Programmiersprachen (Java, C,. . .):
”
Embedded SQL/Call Level Interface“, Host Language Coupling“
”
”
❏ Heute können auch Programmteile direkt auf der Datenbank (d.h. im DBMS-Server)
ausgeführt werden: Stored Procedures“, Methoden in der DB
”
❏ Stored Procedures können insbesondere auch auf Datenbankereignisse“ (Einfügen,
”
Löschen, Ändern von Tupeln) reagieren: Trigger“, Aktive Datenbanken“
”
”
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-2
7.1
Interne Organisation eines DBMS
➢ Der Aufbau der internen Ebene eines DBMS und die Optimierung des Datenbankbetriebs ist
ein wesentlicher Kernbereich von kommerziellen DBMSen und Forschungsarbeiten!
➢ Wahl effizienter Speicherungsstrukturen, insbes. für den assoziativen Zugriff (vgl. Datenstrukturen und Algorithmen).
➢ Realisierung effizienter Ausführungsalgorithmen für die Operationen der Schnittstelle (SQL).
7.1.1
Speicherungsaspekte
Häufige Unterscheidung in der Literatur: Primär- und Sekundärspeicherung.
➢ Primärspeicherung: Speicherung der Datensätze ( Primärdaten“) in einem bestimmten
”
Format (beispielsweise: Sortierung einer Relation nach dem Primärschlüssel)
➢ Sekundärspeicherung: Zusätzliche Speicherung von Hilfs-Informationen zum effizienten
Zugriff:
❏ Indizes (=Zugriffspfade, z.B. Suchbäume, Hashing) für oft benötigte Attribute
❏ Hier ist Redundanz erwünscht!
❏ Auswahl der richtigen Primär- und Sekundärspeicherung
✧ entscheidend für effizienten Betrieb einer Datenbank
✧ schwieriges Optimierungssproblem (schon Teilprobleme sind NP-vollständig !)
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-3
Abbildung 7-1: Systempuffer
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-4
Entities
Abbildung auf
physische Datensätze
feste
Länge
Unterstützung
inhaltsbezogener Zugriffe
Zugriff über
Primärschlüssel
variable
Länge
sortierte
Speicherung
sortierte
Listen
Hilfstabellen
Indexe
Zugriff über
Sekundärschlüssel
HashVerfahren
sortierte
Listen
ISAM
B-Baum
B*-Baum
...
Indexe
B-Baum
B*-Baum
...
Abbildung 7-2: Abbildung von Entities
Beziehungen
(Relationships)
keine spezielle
physische
Unterstützung
Invertierung
physische
Nachbarschaft
Verkettung
Zeigerfelder
Abbildung 7-3: Abbildung von Beziehungen
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-5
7.1.1.1
Zur Erinnerung: Hash-Verfahren
➢ Grundgedanke:
❏ Berechnung der Satzadresse oder der Blocknummer aus dem (Primär)schlüssel des
Datensatzes.
❏ Sei dom(pk) der Wertebereich des (Primär)schlüssels, S die Menge der möglichen Speicheradressen (Satzadressen oder Blocknummern): Hashfunktion h : dom(pk) −→ S.
❏ Datensätze werden über einen vorgegebenen Speicherbereich verstreut (daher auch
gestreute“ Speicherung).
”
❏ Abbildung i.a. nicht eindeutig, d.h. verschiedene (Primär)schlüsselwerte können auf dieselbe
Speicheradresse abgebildet werden:
=⇒ Kollision =⇒ Kollisions-Behandlung.
➢ Hashfunktionen:
❏ Gute (gleichmäßige) Verteilung wichtig
❏ Standardverfahren: Divisionsrest-Methode
b = Anzahl von Speicher-Blöcken
s = (Primär)schlüssel (numerisch, ggf. vorher umwandeln)
h(s) := s mod b
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-6
➢ Für (statische) Hash-Verfahren gilt allgemein:
❏ Nicht reorganisationsfrei
❏ Dynamisches Wachstum (Vergrößerung Hashbereich) nicht möglich.
❏ Zugriff auf Datensätze in (Primär)schlüsselfolge wird nicht unterstützt, somit
✧ kein sequentieller Zugriff auf Datensätze in Sortierfolge möglich
✧ nur für Punktanfragen“ vom Typ Attributwert = Konstante“ einsetzbar
”
”
❏ Gefahr der Clusterbildung kann durch geeignete Wahl der Hashfunktion weitgehend
vermieden werden, z.B. durch zusammengesetzte Hashfunktion h(randomize(s))“
”
➢ Erweiterungen (=⇒ mehr Dynamik)
❏ Erweiterbares, dynamisches Hashing (Kombination mit Directories) z.T. sogar auch
sortiert-seq. Zugriff möglich
❏ Mehrdimensionale Verfahren,. . .
❏ Als mittelbarer“ Zugriffspfad: Datensätze“ in Hashtabellen enthalten lediglich Adressen
”
”
der eigentlichen Sätze
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-7
➢ Würdigung Hashverfahren
❏ Hash-Verfahren sind eine äußerst wichtige Form der Datenorganisation.
❏ Bei richtiger Auslegung schnellstes assoziatives Zugriffsverfahren. (Im Mittel 1,2 Zugriffe
sind leicht zu erreichen!)
❏ Satzreihenfolge entspricht bei den meisten Verfahren nicht mehr der Sortierreihenfolge,
dann
✧ i.a. kein sequentieller Datendurchlauf in Sortierfolge möglich
✧ nur für punktweise Anfragen geeignet, nicht für Bereichsanfragen.
❏ Vielzahl publizierter Verfahren, immer noch Gegenstand von Forschungs- und Entwicklungsarbeiten
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-8
7.1.1.2
B*-Bäume
➢ B-Baum gut für gezieltes Aufsuchen von Schlüsseln bzw. Datensätzen Traversierung in
Schlüsselreihenfolge (=Sortierfolge) zwar möglich, aber etwas umständlich
➢ Gezielter Einstieg und Weiterverarbeitung in Sortierfolge in praktischen Anwendungen jedoch
relativ häufig
➢ Ansatz B*-Baum:
❏ Die Datenseiten befinden sich ausschließlich in den Blättern (und sind untereinander
verkettet)
❏ Die oberen“ Baumknoten sind reine Indexknoten und dienen nur der Suchraum”
Partitionierung
29
11
2
6
8
a
10
11
16
13
15
b
17
19
25
30
c
32
33
38
40
44
d
42
50
46
48
e
49
50
52
58
f
Abbildung 7-4: Beispiel für B*-Baum
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-9
7.1.2
Anfrage-Bearbeitung & -Optimierung
7.1.2.1
Phasen der Anfrage-Bearbeitung
SQL-Query
↓
Syntaktische und
semantische Analyse
↓
Parse-Tree/Operatorbaum
↓
Anfrage-Optimierung
↓

- algebraische Optimierung;
- Auswahl Join-Verfahren;

- Zugriffspfad-Auswahl
Ausführungsplan
↓
Code-Generierung
↓
ausführbarer“ Code
”
↓
- unmittelbare Ausführung;
- spätere Ausführung (Speicherung)
Laufzeit-Query Processor
↓
Anfrage-Ergebnis
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-10
➢ Erläuterungen:
❏ Syntaktische und semantische Analyse:
✧ Welche Relationen / welche Attribute sind angesprochen?
✧ Was ist zu tun?
❏ Anfrage-Optimierung:
(siehe unten)
❏ Code-Generierung:
✧ direkt ausführbarer Maschinen-Code oder
✧ direkt ausführbarer Code mit interpretativen“ Anteilen oder
”
✧ ausführbarer“ Operatorbaum → interpretierende Ausführung
”
❏ Laufzeit(system)-Query Processor:
✧ bei späterer Ausführung:1
– Prüfung, ob zugrundeliegender Ausführungsplan noch aktuell2 ggf. Zurückweisung
oder (falls möglich) automatische Re-Compilation der Query (=⇒ DB2)
– Bereitstellung zentraler Module für Katalogzugriff, Synchronisation, Recovery,. . .
✧ bei sofortiger Ausführung:
– Wie oben, jedoch die Überprüfung der Aktualität des Zugriffsplans entfällt, da Query
unmittelbar ausgeführt wird.
– Interpreter für erzeugten Zwischen-Code.
1
2
bei wiederholter Anwendung ( repetitive queries“) Übersetzung in Maschinensprache i.d.R. vorteilhafter als (reine) Interpretation.
”
Man spricht in diesem Zusammenhang von early binding“, bei interpretativer Ausführung ( Bindung“ zur Ausführungszeit)
”
”
hingegen von late binding“ im Hinblick auf die Festlegung hinsichtlich DB-Schema und Zugriffspfaden.
”
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-11
7.1.2.2
Überblick: Optimierung von Anfragen
➢ Optimierung findet auf zwei Ebenen statt:
❏ algebraisch“: Die Anfrage wird in Relationenalgebra überführt und die vorhandenen
”
Äquivalenzregeln (siehe Kapitel 2) werden angewandt um eine äquivalente Anfrage zu
bekommen, die sich einfacher auswerten lässt:
✧ besonders sinnvoll: Eliminierung von überflüssigen Joins, Push-Down“ von Selektionen
”
✧ (nicht immer) sinnvoll: Push-Down“ von Projektionen (Warum?)
”
❏ “nichtalgebraisch“: Aufgrund der vorliegenden Speicherstrukturen (Sortierreihenfolgen,
zusätzliche Indizes, Bewertung verfügbarer Auswertungsalgorithmen) wird ein spezieller
Ausführungsplan für eine Anfrage festgelegt.
❏ Wichtig: Adäquate Bewertung (Kostenmodell)
➢ Optimierung spielt eine zentrale Rolle, insbesondere in relationalen DBMSen!
❏ Performanz
❏ Erhaltung der Unabhängigkeit zwischen Externer und Interner Ebene (3-EbenenArchitektur) ⇒ DBMS muss diese Optimierung selbst (automatisch) durchführen,
sonst wollen“ die Nutzer/Programmierer Kenntnis über die interne Speicherung erlangen.
”
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-12
7.2
Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
➢ Bisher betrachtet:
❏ Datenbanksysteme aus der Sicht eines einzelnen Benutzers/Programms (Einbenutzer-Sicht)
➢ Bisher nicht betrachtet:
❏ Welche Anforderungen entstehen durch den zeitgleichen Zugriff mehrerer Benutzer auf die
gemeinsamen Daten?
❏ Wie handhabt ein DBMS paralleles Ändern und Lesen im Mehrbenutzerbetrieb?
❏ Wie kann sich ein DBMS gegen Programm- und System- Abstürze“ absichern?
”
❏ Was kann ein DBMS zur Schadensbegrenzung im Fall von Plattendefekten (Lesefehlern)
tun?
➢ Anwendungsszenarien
❏ Flugbuchung / Platzreservierung
❏ Bankbuchungen, Umbuchungen, Abbuchung, Überweisung . . .
❏ allgemein Geschäftsvorfälle“ (häufig: mission critical applications“)
”
”
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-13
➢ Charakteristisch: Von vielen Benutzern kommen gleichzeitig“ Anfragen und Änderungsauf”
träge an das Info-System
K1
K2
1
2
...
Kn
..
IS
Klienten:
Terminals
PCs / Workstations
Endgeräte (Geldautomaten,
Kontoauszugdrucker,
EC-Kartenleser, ...)
Informations-Server
Abbildung 7-5: Typisches Anwendungsszenario für Mehrbenutzer-IS
➢ Problem: Korrekte Abwicklung der parallelen Aufträge
Abstraktion von Geldtransaktionen, Banktransaktionen, Buchungstransaktionen, . . .
⇓
Transaktion
. . . Folge von DB-Operationen mit den Eigenschaften
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-14
· Integrität (Consistency)
(führt integren DB-Zustand
in neuen integren über)
· Isolation
(Einbenutzersicht
bei Parallelbetrieb)
AP +
DBMS
Concurrency
Control
· Atomarität
(Alles- oder Nichts)
· Persistenz (Durability)
Recovery
(Dauerhaftigkeit)
"ACID - Paradigma"
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-15
7.2.1
Aspekte der Datenbank-Integrität
➢ Inhalt der Datenbank ist ein Abbild (Modell) der Realwelt (Ausschnitt).
➢ Daten sollten möglichst korrekt (Einzelbetrachtung) und widerspruchsfrei (im Zusammenhang
mit anderen Daten) sein.
➢ Datenbank-Änderungsoperationen sollten die Integrität der Datenbank nicht verletzen.
7.2.1.1
Semantische Integrität
➢
Inhaltsbezogene“ Betrachtung von Datenbank-Operationen.
”
➢ Einbeziehung Wissen über die Semantik“ von Attributen.
”
➢ Beispiel 7-1:
❏
❏
❏
❏
❏
PersNr ist zwar als INTEGER definiert, sollte aber nur Werte zwischen 10.000 und 99.999
”
annehmen, da keine höheren Personalnummern vergeben werden. Außerdem muß sich die
letzte Ziffer (Prüfziffer) nach Algorithmus x“ aus den ersten 4 Ziffern ergeben.“
”
Falls Familienstand ledig‘, muß Steuerklasse ∈ {1, 2} sein.“
”
’
Übergang von Familienstand verheiratet‘ auf Familienstand ledig‘ ist nicht erlaubt.“
”
’
’
Eine Kursbuchung mit einem neuen Teilnehmer in der Nimmt teil-Relation darf nur
”
durchgeführt werden, wenn er/sie bereits in der Teilnehmer-Relation eingetragen wurde.“
Eine Kontobuchung muß stets auf einem Soll- und einem Habenkonto ausgeführt werden
”
(doppelte Buchführung).“
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-16
7.2.1.2
Operationale Integrität (Konsistenz)
➢
Formale“ Betrachtung von DB-Operationen.
”
➢ Keine Verfälschungen der Daten/Informationen durch das DBMS selbst (z.B. durch
ungenügende Isolation“ der Benutzer im Mehrbenutzerbetrieb).
”
=⇒ Synchronisation ( Concurrency Control“)
”
7.2.1.3
Integritäts-Wiederherstellung (Recovery)
➢ Rückgängigmachung von Änderungen wegen Verstoß gegen Integritätsregeln, BenutzerAbbruch (ABORT) oder Absturz“ des Anwendungsprogramms
”
=⇒ transaction rollback, undo, in-transaction backout“
”
➢ Wiederherstellung der Datenbankintegrität nach System-Zusammenbrüchen (SW-Fehler,
Stromausfall, . . .)
=⇒ crash recovery
➢ Wiederherstellung der Datenbankintegrität nach Speicherfehlern (z.B. Disk-Block nach Head
”
Crash“ nicht mehr lesbar)
=⇒ media recovery
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-17
7.2.1.4
Maßnahmen zur Gewährleistung der Integrität
➢ Semantische Integrität
❏ Durch DBMS-unterstützte Integritätsprüfungen
✧ z.B. CHECK-, UNIQUE-Klauseln, in SQL-Systemen
❏ Durch Prüfungen im Anwendungsprogramm.
➢ Operationale Integrität (Konsistenz)
❏ Durch geeignete Isolierung“ der Benutzer im Mehrbenutzerbetrieb
”
✧ z.B. Einhaltung von Sperrprotokollen
✧ z.B. durch kein vorzeitiges“ Sichtbarmachen von Änderungen.
”
➢ Recovery (Fehlerbehandlung)
❏ Durch Speicherungs-Redundanz
✧ für das Rückgängigmachen von Änderungen
✧ für das Wiedereinspielen ( Wiederholen“) bereits durchgeführter Änderungen
”
❏ Durch Erzwingung geeigneter Update-Propagation“-Strategien durch die Systempuffer”
Verwaltung.
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-18
7.2.2
Transaktionen
➢ Transaktion = Eine durch den Benutzer explizit markierte Folge logisch zusammengehörender
DB-Operationen.
➢ Kann eine Transaktion (TX) nicht ganz ausgeführt werden (z.B. wegen Integritätsverletzung),
so ihre evtl. vorgenommenen Änderungen in der DB komplett rückgängig zu machen.
⇒ Alles-oder-nichts-Prinzip“ (Atomarität).
”
➢ Mit COMMIT WORK“ wird eine TX abgeschlossen ( End of Transaction“).34
”
”
➢ Mit ABORT WORK“ wird die TX abgebrochen und eventuelle Änderungen rückgängig
”
gemacht (in-transaction backout, undo, rollback).5
➢ Nach jedem COMMIT WORK“ oder ABORT WORK“ (bzw. beim Start der Datenbank”
”
Sitzung) wird implizit ein Begin of Transaction“ (BOT) ausgeführt.
”
➢ Eine vollständig ausgeführte TX überführt die Datenbank (per Definition!) von einem
konsistenten Zustand S in einen neuen konsistenten Zustand S 0.6
➢ Eine TX muß deshalb (aus DBMS-Sicht) stets vollständig ausgeführt werden (operationaler
Aspekt).
3
4
5
6
Wir betrachten hier die entsprechenden SQL-Anweisungen für RDBMSe, allgemeine Notationen: BOT, EOT, RBT.
I.d.R. gibt es auch einen Arbeitsmodus, bei der jedes SQL-Statement als eigene TX betrachtet wird ( auto-commit“).
”
Wie bereits früher erwähnt, lassen sich bei manchen DBMSen DDL-Operationen nicht zurücksetzen; im Gegenteil, sie implizieren
sogar ein COMMIT WORK“. Bei der Verwendung dieser Operationen in Anwendungsprogrammen ist also Vorsicht geboten!
”
Stellt sich für eine gegebene TX nachträglich heraus, daß diese Prämisse falsch war, so muß die Datenbank manuell“ (z.B. durch
”
Ausführung einer inversen“ TX) repariert werden“. Normale Recovery-Funktionen sind nicht mehr anwendbar.
”
”
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-19
➢ Beispiel 7-2:
❏ Transaktion“ aus Anwendersicht:
”
(Programm mit Embedded SQL)
➢ {BOT}
➢ < Übernehme AngNr, KursNr, TnNr von Eingabemaske >;
➢ < SELECT ∗ FROM Angebot WHERE AngNr = . . . AND KursNr = . . . >;
➢ < if ”NOT FOUND” then Fehlermeldung; ABORT WORK >;
➢ < andere Anweisungen des Anwendungsprogramms >
➢. . .
➢ < SELECT ∗ FROM Teilnehmer WHERE TnNr = . . . >;
➢ < if ”NOT FOUND” then Fehlermeldung; ABORT WORK >;
➢ < andere Anweisungen des Anwendungsprogramms >
➢. . .
➢ < INSERT INTO Nimmt teil VALUES (. . . ) >;
➢ COMMIT WORK; {EOT}
❏ Dieselbe Transaktion aus DBMS-Sicht: ( reines SQL )
”
”
(Annahme: NOT FOUND-Bedingung war nirgends erfüllt)
{BOT}
< SELECT ∗ FROM Angebot WHERE AngNr = . . . AND KursNr = . . . >;
< SELECT ∗ FROM Teilnehmer WHERE TnNr = . . . >;
< INSERT INTO Nimmt teil VALUES (. . . ) >;
COMMIT WORK; {EOT}
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-20
➢ Beispiel 7-3:
❏
Transaktion“ aus Anwendersicht:
”
➢{BOT}
➢< for i := 1 to 4 do >
➢{
➢< Lese Eingabe von Maske >;
➢< SELECT ∗ FROM . . . >
➢< if FOUND then Fehlermeldung; ABORT WORK >;
➢< INSERT INTO . . . VALUES . . . >;
➢}
➢ COMMIT WORK; {EOT}
❏ Dieselbe Transaktion aus DBMS-Sicht:
(Annahme: FOUND-Bedingung nicht eingetreten)
{BOT}
< SELECT ∗ FROM . . . >
< INSERT INTO . . . VALUES . . . >;
< SELECT ∗ FROM . . . >
< INSERT INTO . . . VALUES . . . >;
< SELECT ∗ FROM . . . >
< INSERT INTO . . . VALUES . . . >;
< SELECT ∗ FROM . . . >
< INSERT INTO . . . VALUES . . . >;
COMMIT WORK; {EOT}
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-21
➢ Anmerkungen:
❏ Das DBMS weiß nichts von der Ablauf-Logik des Anwendungsprogramms.
❏ Eine Transaktion ist aus DBMS-Sicht lediglich eine Folge von SQL-Anweisungen, die
stückweise“ zur Laufzeit des Programms an das DBMS übergeben werden.
”
➢ Etwas formaler . . .
τ = {T1, T2, . . . , Tn}
Menge von gegenseitig unabhängigen Transaktionen
(
Reihenfolge der Ausführung beliebig)
T =< A1, A2, . . . , Ak >
Jede Transaktion ist eine Folge von Aktionen
A = [op, a]
Jede Aktion ist Paar aus Operation op und Objektmenge a
op: Datenbankoperation (z.B.: read, write)
a ∈ 2DB, DB = Menge von Datenbank-Objekten
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-22
7.2.3
Synchronisation parallel ausgeführter Transaktionen (Concurrency
Control)
7.2.3.1
Einführung
➢ Zur Erhöhung des System-Durchsatzes werden Transaktionen in Mehrbenutzersystemen in der
Regel nicht sequentiell (hintereinander), sondern (überlappt) parallel ausgeführt.
➢ Pro Benutzer / Anwendungsprogramm wird (mind.) eine DBMS-Task gestartet (zur
Ausführung des DBMS-Codes)7.
➢ Übliche Task- Umschalt“-Zeitpunkte: I/O-Operation erfordert Externspeicherzugriff
”
(Systempuffer-Zugriff reicht nicht aus oder Seite nicht im Systempuffer)8
➢ DBMS wartet“ nicht auf I/O-Beendigung (asynchrones I/O), sondern schaltet auf andere
”
Task um.
➢ Aktivierung einer Task durch den Scheduler des DBMS.
➢ Der Scheduler bestimmt damit die Folge der Lese-/Schreib-Operationen auf der Datenbank.
7
8
Da in diesen Tasks“ jeweils derselbe (reentrant Code ausgeführt wird, wird bei der DBMS-Implementierungen oft ein
”
vereinfachtes Task-Konzept verwendet (−→ Threads, Multi-Threated“ Tasks).
”
Mit Systempuffer“ ist der durch das DBMS verwaltetete Seiten-Puffer gemeint.
”
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-23
User 1
¾
AP 1
T1 :
User 2
¾
AP 2
..
.
T2 :
..
.
Tn :
SQL-Stmt 14
SQL-Stmt 23
SQL-Stmt 13
SQL-Stmt 22
SQL-Stmt 12
...
...
User n
¾
AP n
..
.
SQL-Stmt n4
SQL-Stmt n3
Transaktionen
SQL-Stmt n2
SQL-Stmt 21
SQL-Stmt
SQL-Stmt 11
n1
Query Compiler / Interpreter
.
..
..
.
r122 [d]
w 222 [d]
r121 [c]
.
..
w 113 [a]
r221 [d]
r112 [b]
r111 [a]
..
.
rn22 [e]
..
.
r213 [a]
r212 [g]
[f]
r
...
211
rn21 [c]
.
..
w n13 [f]
DB-Aktionen
r n12 [f]
rn11 [a]
r213 [a]
Input Queue
w 113 [a]
DBMS-Scheduler
rn11 [a]
executing
..
.
r211 [f]
Schedule
r111 [a]
Datenbank
Abbildung 7-6: Ausführung paralleler Transaktionen durch das DBMS
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-24
➢ Unkoordinierter Schreib-/Lesezugriff auf Daten kann zu Konsistenzproblemen führen!
❏ nicht integre Zwischenzustände werden sichtbar
❏ verlorene Änderung ( lost update“)
”
❏ einfügen in Lesemenge (Phantome; siehe später)
❏ Beispiel 7-4: Kreditcheck: Für eine gewünschte Abbuchung soll geprüft werden, ob dadurch das Kreditlimit überschritten würde. Falls ja, Buchung zurückweisen, falls nein,
Abbuchung durchführen.
Programmskizze:{BOT}
Eingabe Kontonummer k, Abbuchung a;
read Kontostand s und Kreditlimit kl von k aus DB;
if (s − a) < kl then {‘Zurückweisung’, ABORT};
s := s − a;
update Kontostand s von k in DB;
COMMIT WORK {EOT}
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-25
Annahme: Für das Konto 5371 mit Kreditlimit −10.000 DM und aktuellem Kontostand
−2.000 DM laufen gleichzeitig zwei Abbuchungsaufträge über je 7.900 DM ein.
T1:
Eingabe k, a
read(k) →s1, kl1
hs1 − a1 ≥ kl1i
k.s := s1 − a1
write(k)
COMMIT
Zeit
T2:
Eingabe k, a
read(k) →s2, kl2
hs2 − a2 ≥ kl2i
k.s := s2 − a2
write(k)
COMMIT
Resultat:
✧ beide Abbuchungen würden genehmigt.
✧ die erste Abbuchung würde verloren gehen ( lost update“).
”
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-26
7.2.3.2
Schedules – Serialisierbarkeit
Definition 7-1: Schedule
Die Sequenz der vom Datenbank-Scheduler auf der Datenbank ausgeführten Lese- und
Schreiboperationen nennt man Schedule.
➢ Die Lese- und Schreiboperationen einer gegebenen Schedule können von mehreren Transaktionen stammen und verschränkt“ (überlappend) sein.
”
D
E
i1
i2
Schedule . . . Folge der Aktionen aller Ti ∈ τ .
S = A1 , A 1 , . . .
Jede Transaktion T ist Teilfolge in S .
2
2
n
1
T1 A 1 A 2
1
1
...
2
2
...
n
...
A 1 A 2 A 1 A 1 ...
T2 A 1 A 2
Schedule für t
Tn A 1 A 2
n
t
[V9-Sche]
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-27
Definition 7-2: Serielle Schedule
Jeweils alle Aktionen einer Transaktion werden direkt hintereinander ausgeführt (keine
überlappte Ausführung von Transaktionen)
2
2
n
n
1
1
A 1 A 2 ... A 1 A 2 ... A 1 A 2 ...
T2
Tn
T1
➢ Korrektheit bei paralleler Ausführung?
AXIOM:
Die serielle Ausführung ist korrekt
➢ Bei paralleler Ausführung:
Nachweisen, daß es (mindestens) eine serielle Ausführung gegeben hätte, die äquivalent zur
parallelen Ausführung ist. → Äquivalenz?
➢ Erforderlich: Kriterien, wann eine nicht-serielle (überlappende) Ausführung von Transaktionen
zu korrekten (konsistenten) Resultaten führt.
➢ Sei Ten,par := {T1, T2, . . . , Tn} eine Menge parallel (gleichzeitig) ausgeführter Transaktionen.
➢ Sei S ein konsistenter Ausgangszustand der Datenbank und S 0 := S(Ten,par ) der Zustand der
Datenbank nach Ausführung der Transaktionen t ∈ Ten,par , ausgehend von S .
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-28
Definition 7-3: Serialisierbarkeit paralleler Transaktions-Ausführungen
Gibt es zu Ten,par mindestens eine serielle Ausführungsreihenfolge Ten,seq für die gilt
S(Ten,seq) = S(Ten,par ), dann nennt man Ten,par serialisierbar.
Definition 7-4: Konsistenz von Datenbank-Zuständen
Ein Datenbankzustand S 0 := S(Ten,par ) ist konsistent, wenn der Ausgangszustand S
konsistent ist und Ten,par serialisierbar ist.
➢ Forderung: Durch die parallele Ausführung von Datenbank-Transaktionen sollen:
❏ keine anderen Datenbank-Ausgaben und
❏ keine anderen Datenbank-(End-)Zustände auftreten können, als es auch im sequentiellen
Betrieb möglich wäre (=⇒ logischer Einbenutzer-Betrieb).
➢ Die Sicherstellung dieser Forderung wird durch geeignete Verfahren zur Synchronisation
(concurrency control) paralleler Transaktionen erreicht.
➢ Fragen:
❏ Wann ist eine gegebene Schedule serialisierbar?
❏ Wie gewährleistet man, daß ein Scheduler nur serialisierbare Schedules erzeugt?
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-29
Definition 7-5: Konflikt
Sei Ai die Menge der Datenbank-Operationen (Aktionen) von Transaktion Ti, Aj die
Menge der Aktionen von Tj (Ti 6= Tj ):
Zwei Aktionen a ∈ Ai und b ∈ Aj stehen in Konflikt, kurz a konflikt b, wenn beide auf
dasselbe Datenbank-Objekt (z.B. Tupel) zugreifen und mindestens eine von beiden eine
Schreib-Aktion ist.
Definition 7-6: Abhängigkeits-Graph G(τ, E)
Bezeichne T S n,par die für die Transaktionen Ten,par erzeugte Schedule.
Sei τ := {T1, T2, . . . Tn} die Menge der Knoten in G, wobei gilt:
T ∈ τ ⇐⇒ T ∈ Ten,par .
E ist die Menge der gerichteten Kanten in G, wobei gilt:
eij ∈ E ⇐⇒ ∃a ∈ Ai, ∃b ∈ Aj : a konflikt b ∧ a < b in T S n,par.10
(Anm.: a < b in T S“ steht für a tritt vor b in Schedule T S auf“)
”
”
Lemma:
Ein Schedule T S n,par für eine gegebene Ausführungsreihenfolge der Aktionen von T S n,par
ist serialisierbar, wenn der Transaktions-Abhängigkeitsgraph von T S n,par zyklenfrei ist.
10 Mit Systempuffer“ ist der durch das DBMS verwaltetete Seiten-Puffer gemeint.
”
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-30
Beispiel 7-5: Gegeben sei folgender Schedule der Transaktionen T1, T2 und T3:
TS
Konflikt-Analyse:
r1[v] < w3[v]
r2[v] < w1[v]
r2[v] < w3[v]
w1[v] < r3[v]
w1[v] < w3[v]
3,par
:= hr1[v] r2[v] w1[v] r3[v] w2[u] w3[v]i
=⇒
=⇒
=⇒
=⇒
=⇒
e13
e21
e23
e13
e13
∈
∈
∈
∈
∈
E
E
E
E
E
T
1
T
2
T
3
Abhängigkeits-Graph
Resultat: Abhängigkeitsgraph ist zyklusfrei ⇒ Schedule ist serialisierbar!
Äquivalenter serieller Schedule:
TS
3,seq
:= hr2[v]w2[u]r1[v]w1[v]r3[v]w3[v]i
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-31
Beispiel 7-6: Gegeben sei der folgende Schedule der Transaktionen T1, T2, T3 :
TS
Konflikt-Analyse:
a) r1[v] <
b) r2[v] <
c) w2[v] <
d) r3[v] <
e) w1[v] <
w2[v]
w1[v]
r3[v]
w1[v]
w3[v]
3,par
:= hr1[v]r2[v]w2[v]r3[v]w1[v]w3[v]i
=⇒
=⇒
=⇒
=⇒
=⇒
e12
e21
e23
e31
e13
∈
∈
∈
∈
∈
E
E
E
E
E
a)
T
1
b)
T
2
d)
e)
c)
T
3
Abhängigkeits-Graph
Resultat: Der Abhängigkeits-Graph ist nicht zyklenfrei. (Der Schedule ist nicht serialisierbar.)
Anmerkungen:
➢ Die Aussage in Beisp. 7-6: (Resultat) Abhängigkeits-Graph nicht zyklenfrei ⇒ Schedule
”
nicht serialisierbar“ ist streng genommen nicht korrekt.
➢ Es gibt Schedules mit zyklischem Abhängigkeits-Graphen, die dennoch serialisierbar sind.11
➢ Solche Schedules sind im Rahmen des normalen Scheduling allerdings nicht erzeugbar und
daher praktisch nicht relevant.12
➢ Konstruktion des Abhängigkeits-Graphen i.w. nur für den Korrektheitsnachweis von Synchronisationsverfahren interessant, weniger zur Realisierung von Scheduling-Algorithmen.
11
12
Die Zyklen werden von Aktionen verursacht, deren Ergebnisse von später folgenden Aktionen blind“ überschrieben werden.
”
Vgl. etwa (Weikum und Vossen 2001)
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-32
Definition 7-7: (Konflikt-Serialisierbarkeit)
Ein Schedule S heißt konflikt-serialisierbar, wenn es einen seriellen Schedule mit gleicher
Abhängigkeitsrelation gibt.
Abhängigekeitsrelation: gibt die Reihefolge der im Konflikt stehenden Operationen verschiedener
Transaktionen in einem Schedule wieder.
In der Literatur: S ∈ CPSR . . . Klasse der Conflict Preserving-Serializable Schedules“
”
Satz 7-1:
Ein Schedule ist genau dann CP-serialisierbar, wenn sein Abhängigkeitsgraph zyklenfrei ist.
Beweisskizze:
➢ Kein Zyklus =⇒ topologische Sortierung
↓
äquivalenter serieller Schedule S 0
➢ CP-Serialisierbar =⇒ ∃ äquivalenten seriellen Schedule
↓
kein Zyklus, sonst Widerspruch!
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-33
Vorberechnung serialisierbarer Schedules nicht möglich, weil
➢ die Aktionsfolgen einer Transaktion in der Regel nicht im voraus bekannt sind
➢ die Berechnungskomplexität zu hoch wäre: Bei n Transaktionen T1, T2, . . . Tn, mit jeweils
mi Aktionen (1 ≤ i ≤ n) sind insgesamt
#sched =
n
P
i=1
n
Q
mi !
Schedules möglich.13
mi!
i=1
Zahlenbeispiel:
3 Transaktionen mit je 5 Aktionen: #sched =
13
15!
(5!)3
= 756.756
Das Problem der Bestimmung aller möglichen Schedules läßt sich zurückführen auf die Bestimmung der Permutationen von k
Elementen x1 , x2 , . . . , xk , wobei nicht alle xi (1 ≤ i ≤ k) voneinander verschieden sind.
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-34
7.2.3.3
Überblick: Synchronisationsverfahren
➢ hier nur Überblick: ausführlich in vertiefenden Vorlesungen
➢ Vorgehensweisen von Synchronisationsverfahren zur Gewährleistung serialisierbarer Schedules:
es gibt prinzipiell unterschiedliche Ansätze, je nach Vermutung über die Häufigkeit von
Konflikten
1. Vor Ausführung einer Aktion einer Transaktion wird jeweils geprüft, ob ein Konsistenzproblem auftreten würde =⇒ Sperrverfahren ( pessimistische Verfahren“):
”
❏ Jede Transaktion sperrt die benötigten Objekte, bevor diese verwendet werden,
d.h. andere Transaktionen können während dieser Zeit nicht auf dieses Objekt zugreifen.
❏ Innerhalb einer Transaktion können Sperren für verschiedene Objekte zu verschiedenen
Zeitpunkten gesetzt und wieder gelöscht werden.
❏ trotzdem Probleme möglich!
❏ 2-Phasen-Sperr-Protokoll (2PL): Jede Transaktion hat erst eine Sperrphase“, und
”
dann eine Freigabephase“. Nach der ersten Freigabe können keine weiteren Sperren
”
angefordert werden.
❏ 2-Phasen-Sperr-Protokoll sichert Serialisierbarkeit zu!
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-35
2. Nach Ausführung aller Aktionen einer Transaktion (bei EOT) wird geprüft, ob ein COMMIT
Konsistenzprobleme mit anderen Transaktionen verursachen würde =⇒ Optimistische“
”
Synchronisationsverfahren:
❏ keine Verwaltung von Sperren notwendig.
❏ Es wird aufgezeichnet, welche Objekte von Transaktionen gelesen/geschrieben wurden.
❏ Transaktionen, bei denen ein Konflikt mit anderen, schon beendeten Transaktionen
aufgetreten ist, werden abgebrochen und müssen von neuem gestartet werden.
❏ Neustarten von Transaktionen ist zeitintensiv: Dieses Verfahren ist nur einsetzbar, wenn
die erwartete Anzahl von Konflikten sehr gering ist.
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-36
7.2.4
Recovery und Datensicherung
➢ Aktueller Datenbankzustand kann ggf. rekonstruiert werden aus
❏ Backup: Sicherung der Datenbank zu einem bestimmten Zeitpunkt.
❏ und einem Log-File: Speicherung aller Schreiboperationen einer Transaktion in chronologischer Reihenfolge.
➢ Backup und Log-File müssen getrennt von der eigentlichen Datenbank gespeichert werden!
➢ Aus dem Logfile kann ein gültiger Datenbankzustand rekonstruiert werden:
❏ Rücksetzen der Schreiboperationen der nichtbeendeten Transaktionen (Verlierer)
❏ Ausführen der vollständig im Log-File protokollierten Transaktionen (Gewinner)
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-37
7.3
7.3.1
Verteilte Datenbanken
Grundlegende Konzepte
Verteilte Datenbank besteht aus einer Menge von Informationseinheiten, die auf mehreren über
ein Kommunikationsnetzwerk (LAN, WAN, Internet) verbundenen Rechnern verteilt sind:
➢ Autonomie: Auf jedem Server können lokale Anwendungen ohne die Daten der anderen Server
arbeiten.
➢ Integration: in globalen Anwendungen über das Kommunikationsnetzwerk.
Die an dem Kommunikationsnetzwerk beteiligten Rechner können unterschiedliche Aufgaben
haben und auf verschiedene Weise miteinander kommunizieren.
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-38
7.3.1.1
Mögliche Architekturen
➢ Kopplung/Integration mehrerer Subsysteme
IS
SubIS 1
SubIS 2
...
SubIS k
❏ Zum Beispiel:
✧ Textsystem + Graphiksystem + Datenbanksystem ( + Editoren. . . )
✧ Datenwörterbuch/Directory
❏ Typisch: Funktionalität mehrerer Subsysteme über eine Schnittstelle ansprechen
❏ Anwendungen: Büro, CIM
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-39
➢ Örtliche Verteilung/lokale Verarbeitung
IS 2
IS 1
IS
3
❏
Gleiches“ IS an verschiedenen Orten
”
Grundlage: Verteilte DBMSe
❏ Anwendung: Filialen (Bank, Versicherung . . . )
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-40
➢ Client-/Server- oder Server-Workstation-Kopplung
WS
1
WS
S
WS
2
k
❏ Workstations für spezielle Aufgaben ausgestattet
Anwendung: Reisebüros, Versicherungen,. . .
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-41
7.3.1.2
Grundlegender Aufbau eines VDBMS
globales Schema
Fragmentierungsschema
Zuordnungsschema
lokales Schema
...
lokales Schema
lokales DBMS
...
lokales DBMS
...
Station S1
Station Sn
Abbildung 7-7: Aufbau eines verteilten DBMS
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-42
Ein wesentlicher Entwurfsaspekt besteht in der Entscheidung, wie die Daten auf den verschiedenen
Rechnern fragmentiert und ggf. repliziert werden:
➢ redunzfreie Allokation
➢ Allokation mit Replikation
Fragmentierung
R
Allokation
R11
R1
Station S1
R12
R2
R21
R3
Station S2
R23
R33
Station S3
Abbildung 7-8: Fragmentierung und Allokation
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-43
➢ Fragmentierung kann auf verschiedene Weise geschehen:
❏ horizontal: Selektionen
❏ vertikal: Projektionen
❏ kombiniert
➢ Transparenz: Verteilung nicht sichtbar. Dadurch können Benutzer/Anwendungsprogramme
flexibler arbeiten.
Transparenz ist auf verschiedenen Stufen möglich:
❏ Fragmentierungstransparenz
❏ Allokationstransparenz
❏ Lokale Schematransparenz
➢ Anfrageoptimierung in verteilten Datenbanken:
❏ Allokationstransparenz
❏ wesentlicher Kostenfaktor: Austausch von Teilergebnissen zwischen verschiedenen Rechnern.
❏ spezielle Join-Algorithmen, die lokal ausgeführt werden, und nur notwendige Daten
übertragen =⇒ Semi-Joins
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-44
7.3.2
Das Zwei-Phasen-Commit-Protokoll ( Two-Phase-Commit, 2PC“)
”
➢ Idee: Zur Beendigung einer globalen Transaktion wird ein (Zwischen-)Zustand eingerichtet,
der ein sicheres gemeinsames COMMIT oder ABORT der beteiligten Subsysteme ermöglicht.
GST1
BOT1
Opk,1 … OpK,n
LDBMS1
Opl,1 … Opl,o
LDBMS2
GST2
BOT2
Verzögerung bis zum EOTi
der längsten GSTi
GST3
BOT3
Opk,1 … OpK,p
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
LDBMS3
7-45
➢ Die zwei Phasen des 2PC:
❏ Kern:
Alle an der Ausführung von T beteiligten Knoten stimmen ab, ob T global
committed“ oder aborted“ wird.
”
”
(Knoten, auf dem T gestartet ist, ist Koordinator“, übrige sind Agenten“)
”
”
❏ Phase 1:
Prepare to Commit and Vote“
”
Koordinator fordert Agenten auf, Commit von T vorzubereiten und fordert
Abstimmungsergebnis an (⇒ Sichern der After-Images)
❏ Phase 2:
Commit/Abort“
”
Nach Erhalt aller positiver Stimmen (Fall Commit) oder mindestens einer
negativen Stimme (Fall Abort) teilt der Koordinator
Ergebnis mit:
COMMIT im Fall Commit, ABORT, falls mind. eine Abort-Meldung
(⇒ Freigabe von Sperren)
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-46
➢ Übersicht: 2-Phase-Commit
Koordinator
Commit-Wunsch
von T
K1
Sende Prepare to Commit
an alle Agenten
K2
von mind.
einem Agenten
"No" erhalten
von allen Agenten
"Yes" erhalten
K3
Speichere
"EOT-COMMIT"
für T sicher
K AB
Sende
"ABORT T"
an alle
Agenten
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
K CO
Sende
"COMMIT T"
an alle
Agenten
7-47
Agenten
"Prepare to Commit"
erhalten
A1
Sende "Yes"
an Koordinator
Sende "No"
an Koordinator
A2
"ABORT T"
erhalten
AAB
setze T
zurück
"Commit T"
erhalten
A CO
führe
COMMIT für T
aus
bei Knoten-Crash oder Unterbrechung: Time-Out“ Parameter!
”
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-48
7.3.3
Synchronisation replizierter Daten
➢ Einfache Möglichkeit: Wenn ein Datum geändert wird, so muß es in allen Fragmenten, wo es
auftritt sofort geändert werden.
❏ Vorteil: Lesetransaktionen können sich das optimale Fragment aussuchen.
❏ Nachteil: Schreibtransaktionen müssen alle zugehörigen Fragmente sperren.
➢ Alternative: Quorum-Consensus:
❏ Schreibtransaktionen verändern nur einen bestimmten Anteil Qw der beteiligten Fragmente.
❏ Lesetransaktionen lesen mindestens Qr Fragmente, um sicher zu sein, daß das gelesene
Datum korrekt ist.
❏ Dabei können die Quoren flexibel gesetzt werden, damit sichere“ von unsicheren“ Servern
”
”
unterschieden werden können.
❏ Dafür muß gelten:
1. Qw (A) + Qw (A) > W (A) und
2. Qr (A) + Qw (A) > W (A).
➢ Beispiel 7-7:
Station (Si)
S1
S2
S3
S4
Kopie (Ai)
A1
A2
A3
A4
Gewicht (wi)
3
1
2
2
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
Mögliche Quoren:
❏ Qr (A) = 4
❏ Qw (A) = 5
7-49
7.4
Zusätzliche Literaturhinweise
➢ zu Architektur und Realisierung von DBSen: (Härder 1999; Heuer und Saake 1999;
Ramakrishnan 1998; Mitschang 1995; Elmasri und Navathe 1994)
➢ zu Transaktionsverwaltung: (Bernstein und Newcomer 1997; Jajodia 1997; Gray und Reuter
1994; Weikum 1988; Bernstein et al. 1987; Lockemann und Schmidt 1987; Reuter 1981;
Weikum und Vossen 2001)
➢ zu Verteilten Datenbanken: (Ceri und Pelagatti 1984; Özsu und Valduriez 1991; Kudlich 1992;
Bell und Grimson 1992; Gray und Reuter 1994; Dadam 1996)
Bell, D. und J. Grimson (1992). Distributed Database Systems. Addison-Wesley.
Bernstein, P. und E. Newcomer (1997). Principles of transaction processing . Morgan Kaufmann.
Bernstein, P.A., V. Hadzilacos und N. Goodman (1987). Concurrency Control and Recovery in Database Systems.
Addision-Wesley.
Ceri, S. und G. Pelagatti (1984). Distributed Databases, Principles and Systems. McGraw-Hill.
Dadam, P. (1996). Verteilte Datenbanken und Client/Server-Systeme: Grundlagen, Konzepte und Realisierungsformen. Springer.
Elmasri, R. und S. Navathe (1994). Fundamentals of Database Systems. The Benjamin/Cummings Publ. Comp.,
Redwood City, CA., 2 Aufl.
Gray, J. und A. Reuter (1994). Transaction processing — concepts and techniques. Morgan Kaufmann.
Härder, T (1999). Datenbanksysteme: Konzepte und Techniken der Implementierung . Springer.
Heuer, A. und G. Saake (1999). Datenbanken: Implementierungstechniken. Int’l Thompson Publishing, Bonn.
Jajodia, S. (1997). Advanced transaction models and architectures. Kluwer.
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-50
Kudlich, H. (1992). Verteilte Datenbanken, Systemkonzepte und Produkte. Siemens Nixdorf Informationssysteme
AG.
Lockemann, P.C. und J. Schmidt, Hrsg. (1987). Datenbank-Handbuch. Springer-Verlag.
Mitschang, B. (1995). Anfrageverarbeitung in Datenbanksystemen - Entwurfs- und Implementierungsaspekte.
Vieweg.
Özsu, M.T. und P. Valduriez (1991). Principles of Distributed Database Systems. Prentice Hall.
Ramakrishnan, R. (1998). Database Managment Systems. ...
Reuter, A. (1981). Fehlerbehandlung in Datenbanksystemen. Carl Hanser-Verlag.
Weikum, G. (1988). Transaktionen in Datenbanksystemen. Addison-Wesley.
Weikum, Gerhard und G. Vossen (2001). Transactional Information Systems: Theory, Algorithms, and Practice of
Concurrency Control and Recovery . Morgan Kaufmann, San Francisco, CA.
c M. Scholl, 2001/02 – Informationssysteme: 7. Datenbanksysteme
7-51