Datenbank und Informationssysteme
Inhaltsverzeichnis
1 Programmierung von Datenbankzugriffen 21.1 Architektur des SQL/CLI am Beispiel JDBC . . . . . . . . . . . . . . . . . . . 41.2 SQl-Anweisungen und Ergebnismengen . . . . . . . . . . . . . . . . . . . . . . . 91.3 Metainformationen und adaptives Programmieren . . . . . . . . . . . . . . . . . 121.4 Architektur von ADO.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.5 Speicherresidente Datenbankstrukturen mit ADO.NET . . . . . . . . . . . . . . 161.6 Objekt-Relationales Mapping am Beispiel Hibernate . . . . . . . . . . . . . . . 19
2 Transaktionen und Nebenläufigkeitskontrolle 222.1 Eigenschaften und Verwendung von Transaktionen . . . . . . . . . . . . . . . . 222.2 Serialisierbarkeit und Nebenläufigkeitskontrolle . . . . . . . . . . . . . . . . . . 242.3 Isolationslevel in SQL-Datenbanksystemen . . . . . . . . . . . . . . . . . . . . . 31
2.3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.3.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.3.3 Implementierung durch Sperrverfahren . . . . . . . . . . . . . . . . . . . 342.3.4 Implementierung durch Multiversioning . . . . . . . . . . . . . . . . . . 35
2.4 Strategien der Nebenläufigkeitskontrolle . . . . . . . . . . . . . . . . . . . . . . 36
3 Verteilte Datenbanken 393.1 Architektur verteilter Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . . 393.2 Datenspeicherung in verteilten Datenbanken . . . . . . . . . . . . . . . . . . . . 423.3 Verteilte Anfragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.3.1 Kosten von SQL-Anfragen: . . . . . . . . . . . . . . . . . . . . . . . . . 433.3.2 Joins inverteilten Datenbanken . . . . . . . . . . . . . . . . . . . . . . . 45
3.4 Änderung verteilter Daten und Replikation . . . . . . . . . . . . . . . . . . . . 463.4.1 Techniken synchroner Replikation . . . . . . . . . . . . . . . . . . . . . 463.4.2 Techniken asynchroner Replikation . . . . . . . . . . . . . . . . . . . . . 463.4.3 Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.5 Verteilte Transaktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.5.1 Acrchitektur verteilter Transaktionen . . . . . . . . . . . . . . . . . . . 483.5.2 2-Phasen-Commit-Protokoll (2PC) . . . . . . . . . . . . . . . . . . . . . 49
1
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
4 Informationssysteme zur Entscheidungsfindung 514.1 Data-Warehouses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 2
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
1 Programmierung von Datenbankzugriffen
Situation:
AnwendungFrontend
myProg
BackendDB-Server
DBMSDaten
SQL
Ergebnis-mengen
*S
*R
*C
Beispiel 1.1 Die Grundstruktur des Datenbankzugriffs mit JDBC besteht in sechs Schritten.
Listing 1: JDBC-Abfrage1 import java . s q l . ∗ ;
3 public class BasicJDBC {
5 public stat ic void main ( St r ing [ ] a rgs ){Connection con = null ;
7 Statement stmt = null ;Resu l tSet r s = null ;
9
try{11 /∗∗ Schritt 1 : Treiber r eg i s t r i e r en ∗/
WS 06/07
DB
2Mitschrift.tex,v,1.1,January
30,2007
at12:59:41
CE
T Seite 3
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
Class . forName ( " sun . jdbc . odbc . JdbcOdbcDriver " ) ;13
/∗∗ Schritt 2 : Connection zur Datenbank hers te l l en ∗/15 con = DriverManager . getConnect ion ( " jdbc : odbc : azamon " ,
" d i s " , " ∗∗∗∗∗ " ) ;17
/∗∗ Schritt 3 : Satement erzeugen ∗/19 stmt = con . createStatement ( ) ;
21 /∗∗ Schritt 4 : Anweisung direkt ausfuehren ∗/r s = stmt . executeQuery ( " s e l e c t author , t i t l e from Books " ) ;
23
/∗∗ Schritt 5 : Ergebnis verwenden ∗/25 while ( r s . next ( ) ){
System . out . p r i n t l n ( r s . g e t S t r i n g ( " author " ) + " "27 + r s . g e t S t r i n g ( " t i t l e " ) ) ;
}29
} catch ( Exception e ) {e . pr intStackTrace ( ) ; }31 f ina l ly {
try{33 /∗∗ Schritt 6 : Nicht mehr benoetigte Resourcen fre igeben ∗/
i f ( r s != null ) r s . c l o s e ( ) ;35 i f ( stmt != null ) stmt . c l o s e ( ) ;
i f ( con != null ) con . c l o s e ( ) ;37
} catch ( Exception e ){ e . pr intStackTrace ( ) ; }39 }
41 }}
Es sind sechs Schritte, die die Grundstruktur eines JDBC-Programms bilden:
1. Treiber registrieren
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver")Mit der klassenglobalen Funktion forName von Class wird das Class-Objekt Jdbc-Odbc-Driver erzeugt, in unserem Fall die so genannten JDBC-ODBC-Bridge. Diese tr“agt sichim statischen Treiberregister von JDBC ein. Mit diesem Schritt eröffnen wir uns denZugriff auf ein Objekt, den Treiber, der den Datenzugriff auf eine Datenquelle durchfhrenkann.
2. Connection zur Datenbank herstellen
Connection con = DriverManager.getConnection()Der JDBC-Treibermanager DriverManager ist ein Singleton, sein Konstruktor ist privatund alle seine Methoden sind statisch, also klassenglobal. Er verwendet die JDBC URL (inunserem Fall jdbc:odbc:azamon), bietet sie jedem registrierten Treiber an, bis sich dererste findet, der zu dieser URL eine Connection herstellen kann. Der Treiber instantiiertein Objekt der Klasse Connection, das der Treibermanager der Anwendung bergibt.(Danach spielt der Treibermanager gar keine Rolle mehr, es ist das Connection-Objekt,das für die Anwendung die Verbindung zur Datenquelle repräsentiert.)
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 4
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
3. Statement erzeugen
Statement stmt = con.createStatement()Das Objekt der Klasse Statement wird von der Connection erzeugt; es wird verwendet,um SQL-Anweisungen an die Datenquelle zu richten.
4. Anweisung ausführen und Ergebnismenge erzeugen
ResultSet rs = stmt.executeQuery(...)Die SQL-Anweisung wird ausgefhrt und die Methode executeQuery liefert eine Referenzauf die Ergebnismenge zurück. Die Klasse ResultSet repräsentiert die Ergebnismengeeiner SQL-Anweisung und hat Methoden, mit denen der (implizite) Cursor auf derErgebnismenge bewegt wird und mit denen die Werte aus der Ergebnismenge gelesenwerden. Im einfachsten (und im Default) Fall hat das Objekt rs einen Cursor, derschrittweise vorwärts ber die Zeilen des Ergebnisses bewegt werden kann.
5. Ergebnis verwenden
while ( rs.next() ) {...Die Methode next() der ResultSet positioniert den Cursor zunächst auf die ersteZeile der Ergebnismenge, und bewegt ihn dann mit jeder Iteration ber die folgendenZeilen. Mit den Methoden getXXX(), in unserem Fall getString(), können die Werteder Spalten aus der aktuellen Zeile der Ergebnismenge gelesen werden. Als Parameter derGetMethoden kann man den Namen der Spalte oder auch ihre Position (bei 1 beginnend)angeben. JDBC ist sehr komfortabel was die Konvertierung der Datentypen angeht – inder JDBC-Dokumentation geben Listen Auskunft ber die möglichen Konversionen.
6. Nicht mehr benötigte Resourcen freigeben
rs.close() ...Sicherlich würde auch schlussendlich der GarbageCollector von Java die Objektevernichten und in diesem Zuge die entsprechende Methode close() aufrufen. Auch wennein bergeordnetes Objekt vernichtet wird, ruft JDBC die entsprechenden Funktionen deruntergeordneten Objekte auf. Herr Renz hat gleichwohl bewusst im Beispiel die ganzeReihung der CloseMethoden explizit angegeben, um auf folgenden Punkt aufmerksam zumachen: Die GarbageCollection von Java kann keine Ahnung davon haben, wie externeResourcen verwaltet werden, Resourcen, die die Datenbank oder etwa ein ODBC-Treiberbereitstellt. Infolgedessen kann es auch keinen Mechanismus geben, der den geeignetenZeitpunkt automatisch ermittelt, zu dem diese Resourcen freigegeben werden sollten.Es ist also guter Stil in einem JDBC-Programm, nicht mehr benötigte Resourcen selbstfreizugeben.
1.1 Architektur des SQL/CLI am Beispiel JDBC
Zwei grundlegende Techniken des Zugriffs:
1. SLI: Statement Level Interface (embedded/eingebettetes SQL)
2. CLI: Call LevelInterface
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 5
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
SLI am Beispiel SQLJ:
Prinzip: SQL-Anweisung als „Teil“ unseres Codes
Listing 2: sli-Beispiel.java1 . . .
s t r i n g i s b i n = new s t r i n g ( " 3 −458 . . . " ) ; . . .3 #s q l {SELECT author , t i t l e INTO: author : t i t l e
FROM Books WHERE isbn =: i sbn }5 . . . .
Dieser Code steht in einer „.SQLJ“-Datei. Der SQLJ-Translator erzeugt daraus eine .java- undeine .ser-Datei. Der Java-Compiler erzeugt aus dem .java-Code eine ausfhrbare Java-Klasse.class. Bei der Ausfhrung greift die Klassendatei auf den vorbereiteten SQL-Ausfhrungsplanaus der .ser-Datei zu, der in der Datenbank vorgehalten wird ⇒ statisches SQL.
file.ser
file.ser
enthält vorcompiliertenZugriffsplan des DBMS füralle #SQL-Anweisungen infile.sqlj
file.sqlj
file.java
file.class
SQLJRun-Time
javac
SQL-Translator
Statisches SQL Erstellen des Zugriffsplan des DBMS zur Compilierzeit.
Vorteil: Zugriffsplan steht bei der Ausfhrung schon fertig zur Verfgung, Ausfhrung dadurchetwas schneller.
Nachteil: Hohe Kopplung an die Datenbank, Datenbank muß beim Compilieren verfgbar sein.
Dynamisches SQL Erstellen des Zugriffsplans des DBMS zur Ausfhrungszeit.
Nachteil: Zugriffsplan muß zur Ausfhrungszeit berechnet werden. (kann optimiert werden)
Vorteil: Unter Umständen kann das DBMS jederzeit ohne Anpassung des Codes gewechseltwerden.
Außerdem Vorteil SLI: Meist statisches und dynamisches SQL möglich.
CLI: Call Level Interface
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 6
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
Beispiel:
ODBC JDBC ADO.NET sind Implementierungen vonC/C++ Java C# SQL/CLI = Teil des SQL-Standards.
Aufbau JDBC:
• Java-Anwendung kommuniziert mit (DBMS-unabhängigem) JDBC-Treibermanager.(java.sql.*)
• Treibermanager kommuniziert mit DBMS-abhängigem JDBC-Treiber.
• Spezifischer JDBC-Treiber kommuniziert mit seinem DBMS.
Die Java-Anwendung sendet SQL-Anweisungen an JDBC und erhält Ergebnismengen zurück.
JDBC (Treibermanager)JDBC-TreiberOracle
JDBC-TreibermySQL
JDBC-Treiber
DB2DBMS-spezifisch
DBMS-unabhängig
Java-Anwendung
SQL Ergebnis-mengen
java.sql.*
DB-Server
Oracle
DB-Server
mySQL
DB-Server
DB2
Aufbau ODBC äuivalent.
Problem: SQL-Dialekte in den DBMS machen die DBMS-unabhängikeit wieder schwieriger,Dialekte und spezielle Features sollten nach Möglichkeit vermieden werden.
4 Arten von JDBC-Treibern:
Die Unterschiede ergeben sich durch die verschiedenen Typen der JDBC-Treiber, die in derAbbildung skizziert sind.
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 7
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
Java-Anwendung
JDBC-Treibermanager
Client
NaiverProtokoll-Treiber
Client
JDBCNet-Treiber
DB-Middleware
Client
NaiverAPI-Treiber
Client-DB-Lib
ClientJDBC-ODBC-Bridge
ODBC
Client-DB-LibT
reibervom
: Typ 1 Typ 2 Typ 3 Typ 3
Typ 1: JDBC-ODBC-Bridge (sun.jdbc.odbc.JdbcOdbcDriver)
Typ 2: Native API-Treiber
Typ 3: JDBC-Net-Treiber
Typ 4: Nativer Protokoll-Treiber
Typen von JDBC-Treibern
1. Treiber vom Typ 1 implementieren die JDBC API durch das Mapping der Funktionenauf eine andere SQL CLI, die nicht in Java geschrieben ist. In der Regel handelt essich dabei natrlich um ODBC, d.h. Treiber vom Typ 1 sind eine JDBC-ODBC-Bridge. Einsolcher Treiber ist Bestandteil von SUNs JDK. Der Vorteil dieser Technik besteht darin,dass man vorhandene und installierte ODBC-Funktionalität sofort nutzen kann – es standsomit von der ersten JDBC-Version an der Zugriff auf nahezu alle denkbaren Datenquellenzur Verfgung. Der große Nachteil liegt darin, dass ODBC nicht für Applets genutzt werdenkann, weil ODBC die Sicherheitsrestriktionen für Applets verletzt.
2. Treiber vom Typ 2 beruhen auf den Datenbankspezifischen Schnittstellen, d.h.sie verwenden die (in der Regel in C geschriebenen) Low-Level-APIs des jeweiligenDatenbankHerstellers. Bezglich der Applets verbessert sich die Lage gegenüber derJDBC-ODBC-Bridge dadurch natrlich nicht.
3. Treiber vom Typ 3 sind rein in Java geschrieben und kommunizieren ber ein Da-tenbankunabhängiges Netzprotokoll mit einer Middleware-Komponente, die auf demServer installiert ist. Diese Komponente fhrt dann den eigentlichen DatenbankZugriffdurch. Um ein Beispiel zu nennen: Easysoft bietet eine JDB-CODBC-Bridge vom Typ 3an. Auf Client-Seite wird ein reiner Java-Treiber verwendet, der mit dem UDP-Protokoll
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 8
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
(user datagram protocol) via TCP/IP mit dem Server spricht. Serverseitig werden nundie Anfragen des JDBC-Treibers in ODBC-Anfragen transformiert und ODBC fhrt dann deneigentlichen Datenzugriff weiter.
4. Treiber vom Typ 4 sind rein in Java geschrieben und kommunizieren mit demDatenbank-Server ber sein Netzprotokoll. D.h. der Java-JDBC-Treiber tritt an dieStelle des Datenbank-Clients und wickelt die Kommunikation mit dem Server direkt ab.Ein Beispiel für einen Treiber dieses Typs ist jConnect von Sybase. Der JDBC-TreiberjConnect verwendet das Protokoll TDS (tabular data stream) von Sybase und richtetso seine Anfragen direkt an den Datenbank-Server. Treiber vom Typ 4 versprechen diebeste Performance.
Treibermanager
• Registrieren und Laden von Treibern
• Herstellen der Verbindung zur DB
• Konfiguration der Verbindung
• Delegation an JDBC-Treiber
1. Registrieren und Laden von Treibern
Methode 1: Explizites Laden der Treiberklasse:
1 Class . forName ( org . po s tg r e s . Dr iver )
Methode 2: properties-Datei:
1 jdbc . d r i v e r s=org . p o s tg r e s . Driver , . . .
Methode 3: Systemeigenschaft (Parameter beim Aufruf):
1 java −D jdbc . d r i v e r s = . . . . MyClass
Methode 4: (neu in JDBC 4.0) automatisches Laden bei getConnection anhandURL
2. Herstellen der Verbindung zur Datenbank
Methode 1: DriverManager.getConnection(url,uid,pwd)
jdbc:<subprotocol>:<subname>
z. B.:
1 jdbc : odbc : azamon /∗= DSN in ODBC∗/jdbc : p o s t g r e s q l : / / host : port / database /∗= URL der DB auf postgreSQL−
Server ∗/
Methode 2: Verwenden einer DataSource
Vorteil: Nur der Name muß bekannt sein, keine Ports etc..
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 9
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
Schritt 1: Der Anbieter einer Datenquelle registriert DataSource beiJNDI← Namensdienst
Schritt 2: Der Verwender holt sich eine Connection bei der DataSource
DataSource ds = ( DataSource ) new I n i t i a l C o n t e x t ( ) . lookup ( "Name derDatenque l l e " ) ;
2 Connection con = ds . getConnect ion ( ) ;
1.2 SQl-Anweisungen und Ergebnismengen
select author , t i t l e from Books where ISBN=’ 3 . . . ’
SQL-Gramatik
Systemkatalog
Parsen
Validieren
Optimieren
binärer Zugriffs-plan erzeugen
Zugriff durch-führen
1
EXECUTE
DIRECT
zur Laufzeit
2
PREPARE
zur Laufzeit
EXECUTE
zur Laufzeit,
mehrfach durch-
führbar
3
STORED
PROCEDU-
RE erzeugen
STORED
PROCEDU-
RE verwenden
Methode 1:
1 Statement stmt = con . createStatement ( ) ;Resu l tSet r s = stmt . executeQuery ( " s e l e c t author , t i t l e from Books where
ISBN = ’ 3 . . . ’ " ) ;
Methode 2: Parametrisierte Anweisung
PreparedStatement pstmt = con . prepareStatement ( " s e l e c t author , t i t l e fromBooks where ISBN = ? " ) ;
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 10
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
PreparedStatement wird vom DBMS bei prepareStatement(...) vorbereitet/bearbei-tet und zwischengespeichert
1 pstmt . s e t S t r i n g (1 , " 3 −123 . . . " ) ;Resu l tSet r s = pstmt . executeQuery ( ) ;
Methode 3:
CREATEE PRODUCERE readbook @isbn char (13)2 AS select author , t i t l e from Books
where i sbn =@isbn ;4
Cal lab leStatement cstmt = con . prepareCa l l ( " { c a l l readbook ( ? ) }) ;6
Resu l tSet r s = cstmt . executeQuery ( ) ;
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 11
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
Arten von Anweisungen
a) Abfragende Anweisung – liefert ResultSet
1 " s e l e c t . . . " Resu l tSet r s = stmt . executeQuery ( . . . ) ;
b) Modifizierende Anweisung – liefert Zahl der veränderten Zeilen
1 " i n s e r t . . . "" update . . . " int rows = stmtm . executeUpdate ( . . . ) ;
3 " d e l e t e . . . "
c) Beliebige Anweisung – liefert ein Boolean
1 " . . . " boolean t o r f = stmt . execute ( . . . ) ; // true or f a l s ewenn t o r f==true // Ergebnis i s t ResultSet
3 r s . stmt . ge tResu l tSe t ( ) ;wenn t o r f==fa l se // Ergebnis i s t int
5 r s . getUpdateCount ( ) ;
Ergebnismengen
Relationales Modell: Tabellen/Relationen enthalten Zeilen von Werten.
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 12
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
OO-Programmiersprachen: Variablen, Objekte mit Attributen(Variablen), Datenstrukturen,...-> Konzeptbruch / "paradigma mismatch"
Programmiersprache
Ein Resultset rs repräsentiert einen Cursor auf eine Zeile der Ergebnismenge (Relation) ausdem DBMS. Die Ergebnismenge muß nicht zwangsläufig bei executeQuery sofort vollständig„materialisiert“ sein, Zeilen können bei Bedarf nachgeladen werden.Metainformationen über die Ergebnismenge stehen in den SQL-Deskriptoren, beginnend bei 1für Spalte 1.
Arten von Ergebnismengen
1. Scroll-Eigenschaften
• TYPE_FORWARD_ONLY (Abrufen nur vorwärts, schnell und einfach aber beschränkt)
• TYPE_SCROLL_INSENSITIVE (Insensitive: Änderungen während der Verarbeitungdes Results bleiben unsichtbar)
• TYPE_SCROLL_SENSITIVE (Sensitive: Alle Änderungen während der Verarbeitungdes Results wirken sich sofort aus)
2. Änderbarkeit
• CONCUR[RENCY]_READ_ONLY (Cursor hat nur Lesezugriff)
• CONCUR[RENCY]_UPDATEABLE (An der Position des Cursor können Daten verändertwerden)
1+2 wird angegeben bei createStatement.
1.3 Metainformationen und adaptives Programmieren
Fragestellungen:
• nicht nur Nutzdaten, sondern Informationen über die Nutzdaten über das Datenbank-system
• Informationen über die Fähigkeiten eines DBMS, um diese in einer Anwendung berück-sichtigen zu können
1. Fehler- und Statusinformationen
Konzept der DB: SQL Communication Area (Datenstrukturen für Fehler- und Status-meldungen)
• standardisierte Fehlercodes (in SQL)
• DBMS-spezifische Fehlermeldungen
Konzept in JDBC: SQLException ex, enthält
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 13
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
• Beschreibung des Fehlers: ex.getMessage();
• SQL-Status: ex.getSQLState();
• Meldung der Datenquelle: ex.getErrorCode();
• Kette der (bei der DB) anliegenden Meldungen: ex.getNextException();
Konzept in ADO.NET: DataException de, enthält
• Beschreibung: de.getMessage();
• Reihe von abgeleiteten Klassen wie z.B.
– DuplicateNameException
– InvalidExpressionException
– · · ·
Besonderheiten in ADO.NET: Connection erzeugt ein Event InfoMessage, korrespondie-render Delegat behandelt das Event (entspricht Fehlermeldung).
2. Informationen über einzelne Werte
Konzept der DB: Indikatorvariable (wird intern vom Treiber bei der Kommunikationmit dem DBMS verwendet, insb. für NULL-Werte interessant)
Konzept in JDBC: ResultSet rs
• rs.wasNull() =̂ die zuletzt aus rs gelesene Info war ein NULL-Wert.
Konzept in ADO.NET: DataReader rs
• dr.IsDBNull(int i); // int i: Index der Spalte)
3. Aufbau einer Ergebnismenge
Konzept der DB: SQLDeskriptor
• SQLDeskriptor beschreibt eine Spalte einer Ergebnistabelle: Spaltenname, Datentyp,· · ·
• pro Spalte ein SQLDeskriptor, Zählung startet bei 1
Konzept in JDBC:
ResultSetMetaData rsmd ;2 rsmd = r s . getMetaData ( ) ; // Meta−Daten dieses ResultSets
int rsmd . getColumnCount ( ) ; // Zahl der Spalten4 int rsmd . getColumnType ( int i ) ; // Typ der Spalte i , beginnend bei 1
s t r i n g rsmd . getColumnName ( int i ) ; // Name der Spalte
Konzept in ADO.NET:
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 14
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
1 DataReader dr ; dr . ExecuteReader ( ) ;dr . FieldCount ; // Zahl der Spalten des Ergebnis
3 dr . GetName( int i ) ; // Name der Spalte i , beginnend bei 0DataTable dr . GetSchemaTable ( ) ;
Eine Zeile der Schema-Tabelle beschreibt eine Spalte der (Nutzdaten-)Tabelle.
4. Informationen über die Datenquelle
Konzept der DB: Systemkatalog
• Informationen, die die JDBS-Treiber bzw. ADO.NET DataProvider liefern
Konzept in JDBC: DatabaseMetaData dbmd = con.getMetaData();
• allgemeine Informationen: getURL(), getDatabaseProductVersion();
• Eigenschaften der Datenquelle:
supportsFullOuterJoin(); supportsANSI92EntryLevelSQL();
• Grenzwerte in der Datenquelle: getMaxConnections(); getMaxRowSize();
• Systemkatalog: getTables(); getPrimaryKeys(); ...
Konzept in ADO-ET (2.0)
DataTable dt = con.getSchema(); //DataTable enthält Infos
DataTable tables = con.getSchema("TABLES");
Adaptives Programmieren
Ziele:
1. Programmcode soll für verschiedene DBMS funktionieren.
2. Programmcode soll fähig sein, spezielle Eigenschaften eines DBMS auszunutzen.
Lösung: Adaptives Programmieren = verwende Metainformationen über die Datenquelle umden Zugriff zu steuern.
Bsp in JDBC: (Technik = adaptives Programmieren)
. . . DatabaseMetaData dbmd = con . getMetaData ( ) ;2 . . .
4 i f (dbmd . support sFul lOuterJo in ( ) ) {.
6 . . . // f u l l outer jo ins} else {
8 . . . // geschachtelte Se lects ( oder andere " Notloesung ")}
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 15
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
1.4 Architektur von ADO.NET
• Grundkonzept von ADO.NET:
Trennung des Datenzugriffs von der Datenmanipulation (MS)
• Zwei Komponenten im .NET-Framework:
– DataProvider: bietet Zugriff auf Datenquellen, Persistenzmechanismen (Kap. 1.4)
– DataSet: bietet Zugriff auf Daten, Datenmanipulation (Kap 1.5)
.NET Framework Data Provider
DataProvider
Command
Parameters
Connection
Transaktion
DataAdapter
DeleteCommand
UpdateCommand
InsertCommand
SelectCommand
DataSet
XML
DataTableCollection
DataTable
ConstraintCollection
DataColumnCollection
DataRowCollection
DataRelationCollection
Database
Wichtige Klassen in der Komponente .NET Framework DataProvider:
• Connection – Verbindung zur Datenquelle
• Command – SQL-Anweisung, auch parametrisiert
• DataReader – Cursor auf Ergebnismenge (READ_ONLY, FORWARD_ONLY)
• DataAdapter – Verbindet Datenquelle mit DataSet (siehe Kap 1.5)
Microsoft stellt 4 DataProvider bereit:
1. MS SQL Server – System.Data.SqlClient
2. OLE DB – System.Data.OleDB
3. ODBC – System.Data.OBDC
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 16
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
4. Oracle – SystemData.OracleClient
Unterschiede in der Architketur ADO.NET – JDBC
Programmieren mit ADO.NET DataProvider
1 IDbConnection con = new SqlConnect ion ( ) ; // einen hiervonIDbConnection con = new OdbcConnection ( ) ; // auswaehlen , j e nach Datenbank !
3
IDbCommand cmd = con . CreateCommand ( ) ;5 cmd . Commant Text = " s e l e c t ∗ . . . " ;
IDataReader dr = cmd . ExecuteReader ( ) ;
Fragwürdige Programmiertechnik, da DB-Zuordnung fest im Code verankert ist und evtl. zumÄndern viele Aufrufe und includes angepasst werden müssen.
Seit ADO.NET 2.0: ProviderFactory
2 DbProviderFactory f a c t = DBProviderFactor ies . GetFactory ( " s q l s e r v e r " ) ;//Zuordnung in Config−Fi le (machine . conf ig ) moeglich
4 IDbConnection con = f a c t . GetConnection ( ) ;
1.5 Speicherresidente Datenbankstrukturen mit ADO.NET
(Folie: Aufbau einer DataSet)
1. DataSet speicherresidente Datenbank (In-Memory Database): enthält Tabellen (= Ob-jekte der Klasse DataTable)
• DataTable hat
TableName,
Coulumns (mit CoulmnName, DataType,...),
Rows (mit Items pro Column)
• DataRelations hat
parentCol = Tabelle + Spalte von Parent,
ChildCol = Tabelle + Spalte von Child
• Ferner Constraints: UniqueConstraint, ForeingnKeyConstraint
• Speziell DataView: Sicht auf DataTable; zum Sortieren, Filtern o.ä. -> Anbindungan GUI
2. Anbindung an die Datenbank
verantwortlich ist der DataAdapter, hat Properties
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 17
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
• SelectCommand z. B.: "select author, title from Books"
• InsertCommand z. B.: "insert into Books(author, title) values (?,?)"
• UpdateCommand z. B.:
"update Books set author=?, title=? where author=? and title=?"
• DeleteCommand z. B.: "delete from Books where author=? and title=?"
Methode Fill des DataAdapter erzeugt DataTable in einem DataSet entsprechendSelectCommand.
Klasse CommandBuilder erzeugt InsertCommand
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 18
AD
O.N
ET az
amon
Boo
ksis
bnau
thor
3-14
5.. . .
Moo
re. . .
RA
M,D
ataS
eten
th.D
ataT
able
Boo
ksis
bnau
thor
3-14
5.. . .
Moo
re. . .
Rel
eati
onal
esM
odel
lal
sO
bjek
tstr
uktu
r(g
ener
isch
)
da.F
ill()
da.U
pdat
e()
Ent
spre
chun
g
Dat
aGri
dM
etho
deSe
tDat
aBin
ding
GU
I
*IS
BN
Aut
or3-
145.
Moo
re
Dat
aGri
dlo
okan
dfe
elD
ataG
ridT
able
Styl
eD
ataG
rid
feue
rtE
vent
Row
Cha
ngin
g
Dat
aVie
wM
anag
erpr
äsen
tier
tT
abel
len
und
Frem
dsch
lüss
el-
Pri
mär
schl
üsse
l-be
zieh
ung
OR
Maz
amon
Boo
ksis
bnau
thor
3-14
5.. . .
Moo
re. . .
b1:B
uch
isbn
="3
-145
"au
thor
="M
oore
"
b2:
OO
-Dom
änen
mod
ell
(spe
ziel
l)G
UI
19
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
1.6 Objekt-Relationales Mapping am Beispiel Hibernate
Thema: Konzeptbuch Rel. Modell – OO Sprachen
Leitidee: Gegeben „normale“ Objekte z. B. Buch b = new Buch("3-145..."), Persistenz-mechanismus für Objekte, möglichst „nicht-invasiv“
Technik: OR Mapping z. B. Java Data Objects, Hibernate
Beispiel 1.2 Buchverwender (Klassen-deutsch, Tabellen-englisch)
AuftragsNrDatum
setKunde()addAPos()
KundenNrName
ISBNTitelAutor
* 0..1Auftrag Kunde
0..1
*APos Buch* 0..1
Anzahl
setBuch()
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 20
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
1
//Auftragsbearbeitung3
Se s s i on s e s s i o n = getSe s s i onFacto ry ( ) . openSess ion ( ) ;5 Transact ion tx = s e s s i o n . beg inTransact ion ( ) ;
7 Auftrag a = new Auftrag ( ) ;a . setAuftragsNr (112) ;
9 Date today = new Date ( ) ;a . setDatum ( today ) ;
11
s e s s i o n . save ( a ) ; // s o l l pers i s tenz se in13
15 APos ap1 = new APos ( ) ;ap1 . setBuch ( " 3 −145 . . . " ) ;
17 ap1 . setAnzahl (1 ) ;
19 APos ap2 = new APos ( ) ;ap2 . setBuch ( " 0 −120 . . . " ) ;
21 ap2 . setAnzahl (1 ) ;
23
Kunde k = new Kunde ( ) ;25
k . KundenNr (14568) ;27 k . setName ( " Schne ider " ) ;
29 a . setKunde ( k ) ;a . addAPos ( ap1 ) ;
31 a . addAPos ( a2 ) ;
33 tx . commit ( ) ;
35 s e s s i o n . c l o s e ( ) ;
Folge:
1 insert into Customers ( cid , cname )values (14568 , " Schne ider " )
3 insert into Order( ordernum , cid , order_date )values (112 , 14568 , " 2006−11−14 " )
5 insert into OrderItems ( ordernum , i sb in , qty )values (112 , " 3 −145 . . . " , 1 )
7 insert into OrderItems ( ordernum , isbn , qty )values (112 , " 0 −120 . . . " , 1 )
wie kann das gehen? −→ Hibernate erzeugt diese SQL-Anweisungen!
1. Entwickler der Klassen muss ein Paar Konventionen einhalten
• Konstruktor ohne Parameter
• Setter- unf Getter- Methoden
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 21
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
• Assoziationen zwischen Klassen müssen durch Interface deklariert sein.
z. B.:.....private set APos = new HashSet()
set ∼= CollectionInterface, Hashset ∼= Collection Impl.
2. Zuordnung der Klassen zu den Datenbank-Tabellen
wird deklariert in XML-Dateien mit Endung .hbm.xml
z. B.: books.hbm.xml
<hibernate−mapping>2 <c l a s s name = " Buch " t a b l e = " Books ">
<id name = "ISBN" column = "ISBN" \>4 <property name = " autor " column = " author " />
<property name = " t i t e l " column = " t i t l e " />6 <\ c l a s s>
<\ hibernate−mapping>
3. Infrastruktur von Hibernate
Die wichtigsten Klassen:
SessionFactory– sorgt für Zugang zur Datenbank, konfiguriert in hibernate.cfg.xml
1 <?xml version=’ 1 .0 ’ encoding=’ utf−8 ’ ?><!DOCTYPE hibernate−c o n f i g u r a t i o n PUBLIC "−//Hibernate / Hibernate Conf igurat ion
DTD//EN" " h t t p : // h ibe rnate . s o u r c e f o r g e . net / hibernate−con f i gu r a t i on −2.0 . dtd ">3 <hibernate−c o n f i g u r a t i o n>
<s e s s i o n−f a c t o r y>5 <property name=" h ibe rnate . connect ion . d r i v e r _ c l a s s ">sun . jdbc . odbc . JdbcOdbcDriver
</ property><property name=" h ibe rnate . connect ion . u r l ">jdbc:odbc:azamon</ property>
7 <property name=" h ibe rnate . connect ion . username ">d i s</ property><property name=" h ibe rnate . connect ion . password ">∗∗∗∗∗∗∗</ property>
9 <property name=" h ibe rnate . connect ion . poo l_s i ze ">10</ property><property name=" show_sql ">true</ property>
11 <property name=" d i a l e c t ">net . s f . h ibe rnate . d i a l e c t . MySQLDialect</ property><property name=" h ibe rnate . d i a l e c t ">net . s f . h ibe rnate . d i a l e c t .M$SQLDialect</
property>13 <property name=" h ibe rnate . hbm2ddl . auto ">update</ property>
<!−− Mapping f i l e s −−>15 <mapping r e s o u r c e=" books .hbm. xml " />
</ s e s s i o n−f a c t o r y>17 </ hibernate−c o n f i g u r a t i o n>
Session ∼= Connection
Transaction ∼= Transaktion
Query ∼= eine Maschine für SQL ähnliche Abfragen mit Objekten
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 22
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
2 Transaktionen und Nebenläufigkeitskontrolle
2.1 Eigenschaften und Verwendung von Transaktionen
Notation:
Szenario 1 Überweisung von 100e von Konto A auf Konto B
1. Belaste Konto A mit 100e, Saldo A = 100;
2. Buche 100e auf Konto B, Saldo B += 100;
muss als logische Einheit durchgeführt werden
Szenario 2 Konto A mit Saldo von -20e
Abbuchung nur bei positivem Kontostand erlaubt
Zeit
T1 T2 Saldo A
-20e
+100e 80e
-80e 0e
rollback-20e ?-100e ?
Wie steuert man Zugriff mehrerer Anwendungen bzw. Transaktionen.
Definition 2.1 Eine Transaktion ist eine logische Arbeitseinheit, die auch mehrere Daten-bankaktionen umfassen kann.
Eigenschaften: ACID
Atomarität „alles oder nicht “
Consistency Daten sind vor und nach Transaktion in konsistenten Zustand (z. B. ref. IntegritätPK/FK)
Isolation Abschirmung einer Transaktion gegen Wirkungen anderer Transaktionen
Durability Commitete Daten bleiben unter allen Umständen erhalten
Verwendung von Transaktionen in JDBC bzw. ADO.NET
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 23
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
• Auto-Commit-Modus eine einzelne SQL-Anweisung wird also als eine Transaktiondurchgeführt
z. B.:
1 · · · insert into Customers ( c id ) values (112) · · ·→ Commit
3 · · · update Customers set cname =" Hans " where c id = 112→ Commit
In nichttrivialen Datenbankenanwendungen muss man den Auto-Commit-Modus aus-schalten.
Connection hat Methode void setAutoCommit(boolean enable)
Transaktiongrenzen:
– in SQL werden Transaktionen automatisch gestartet(bzw. explizit START TRANSACTION in SQL: 2003)
– Transaktionen werden explizit beendet mit commit oder rollback.
Connectin hat Methode void commit() und void rollback().
• Einstellung des Isolationslevels (später mehr dazu!)
Connection hat Methode void set TransactionIsolation(int Isolevel)
Elegant in ADO.NET (2.0)
Transact ionOption to = new Transact ionOption ( ) ;2 to . I s o l a t i o n l e v e l = I s o l a t i o n l e v e l . ReadCommitted ;
4 us ing ( TransactionScope| {z }begin Transaction
t s = new Transact ionScope ( · · ·) )
{6 us ing ( SQLConnection con = new SQLConnection ( · · ·) )
{8 · · ·
...10 // eigene DB-Sachen
...12 }
ts.Consistent| {z }end Transaction
= true ; // Eigenschaft der Transaktion-Code
14 ent s che ide t , ob h i e r commit=true oder r o l l b a c k=fa l se gemacht wird
16
}
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 24
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
2.2 Serialisierbarkeit und Nebenläufigkeitskontrolle
Sehr, sehr einfaches Modell einer Datenbank, nämlich
• Datenbank hat Datenobjekte x, y, z, · · ·
• es gibt folgende Datenbankaktionen:
r(x) lese Datenobjekt x (read)w(x) schreibe Datenobjekt x (write)c committ Transaktion (commit)a breche die Transaktion ab (abort)
• eine Transaktion T ist eine Folge solcher Aktionen
T : r(x);w(x); r(y);w(z); c
• bei mehreren Transaktionen verwenden wir Indexe
T1 : r1(x);w1(x); r1(y);w1(y)
T2 : r2(x);w2(x)
• ein Ablauf S in einer Datenbank ist eine (zeitliche) Veschränkung von Transaktionen.
S1 : r1(x);w1(x); r1(y);w1(y)︸ ︷︷ ︸T1
; r2(x);w2(x)︸ ︷︷ ︸T2
// seriell
S2 : r1(x)︸ ︷︷ ︸T1
; r2(x)︸ ︷︷ ︸T2
;w1(x); r1(y)︸ ︷︷ ︸T1
;w2(x)︸ ︷︷ ︸T2
;w1(y)︸ ︷︷ ︸T1
; // nicht serialisierbar
S3 : r1(x);w1(x)︸ ︷︷ ︸T1
; r2(x);w2(x)︸ ︷︷ ︸T2
; r1(y);w1(y)︸ ︷︷ ︸T1
// serialisierbar
Definition 2.2 Ein Ablauf heißt seriell, wenn alle Schritte einer Transaktion ausgeführtwerden, ehe die nächste Transaktion ausgeführt wird.
Beispiel 2.1 Ablauf S1 ist seriell (Definition: s. o.)
Definition 2.3 Zwei Aktionen in einem Ablauf stehen in Konflikt, wenn gilt
1. sie gehören zu unterschiedlichen Transaktionen
2. sie verwenden desselben Datenobjekt
3. mindestens einer der beiden Aktionen ist write
Beispiel 2.2
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 25
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
stehen in Konflikt
S1 : r1(x);w1(x); r1(y);w1(y); r2(x);w2(x)
Definition 2.4 Zwei Abläufe heißen konfliktäquivalent, wenn die Reihenfolge aller Paarevon im Konflikt stehenden Aktionen gleich ist.
Bsp.: S1 und S2 sind nicht konfliktäquivalent, denn
X
vertauscht �
X
S2 : r1(x); r2(x);w1(x); r1(y);w2(x);w1(y)
Bsp.: S1 und S3 sind konfliktäquivalent, denn
XX
X
S3 : r1(x);w1(x); r2(x);w2(x); r1(y);w1(y)
Definition 2.5 Ein Ablauf S heißt (konflikt-) serialisierbar, wenn er konfliktäquivalentzu einem seriellen Ablauf ist.
Bsp.:
1. S1 ist seriell, also serialisierbar
2. S2 ist nicht serialisierbar
S1 = T1.T2 S2 ist nicht äquivalet zu S1
S′1 = T2.T11 man überprüft leicht, das S2 auch nicht zu S
′1 äquivalent ist.
3. S3 ist serialisierbar, weil äquivalent zu S1, einem seriellen Ablauf.
Transaktionen:
S1 : r1(x);w1(x); r1(y);w1(y); r2(x);w2(x);S2 : r2(x); r2(x);w1(x); r1(y);w2(x);w1(y);S3 : r1(x);w1(x); r2(x);w2(x); r1(y);w1(y);
Einfaches Modell einer Datenbank:
ri(x) Read-Aktion, wi(x) Write-Aktion der Transaktion Ti auf Datenobjekt x
Serielle Abläufe
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 26
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
serialisierbare Abläufe
Fragestellung: Kriterium für (Konflikt-)Serialisierbarkeit
Definition 2.6 Ein Präzedenzgraph zu einem Ablauf ist ein gerichteter Graph mit KnotenT1, T2, · · · , Tn der am Ablauf beteiligten Transaktionen Ti und Kanten Ti → Tj , wenn eineAktion in Ti in Konflikt steht mit einer Aktion in Tj und die Aktion Ti vor der Aktion in Tj
steht.
Beispiele:
S1
T1 T2
seriell, serialisierbarS2
T1 T2
nicht serialisierbar S3
T1 T2serialisierbar,nicht seriell
Satz 2.1 Ein Ablauf S ist Konfliktserialisierbar⇐⇒ sein Präzedenzgraph G hat keinen Zyklus.
Beweis 2.1 =⇒)
Annahme: G hat einen Zyklus, z.B.
T1 T2 T3 Tk
· · · · · · · · · · · ·
Das bedeutet: in einem äquivalenten seriellen Ablauf kommen alle Aktionen von T1 vor denenvon T2. Aber auch alle Aktionen von Tk müssen vor denen von T1 kommen → Widerspruch!
(⇐= zu zeigen: wenn G keinen Zyklus hat, dann ist S serialisierbar. Induktion über die Zahln der Knoten in G = Zahl der Transaktionen im Ablauf
Ist n = 1, dann gibt es nur eine Transaktion im Ablauf S, d.h. S ist seriell.
Induktionsvoraussetzung: Aussage gilt für n− 1 Knoten.
Sei S ein Ablauf mit T1, T2, T3, · · · , Tn. Präzendenzgraph G hat keinen Zyklus.
Das bedeutet: es gibt mindestens einen Knoten in G, der nicht Spitze einer Kante ist.
Sei Ti dieser Knoten. D.h. es gibt keine Aktion in S, die von Ti kommen und zu Aktionen inTi in Konflikt stehen. Also ist der Ablauf S′′ = Ti + restliche Aktionen von S︸ ︷︷ ︸
S′
Konfliktäquivalent zu S.S′ hat n− 1 Transaktionen, ist also nach Induktionsvoraussetzung
serialisierbar, also ist S serialisierbar.
Bemerkung 2.1 Es gibt auch den Begriff der View-Serialisierbarkeit. Jeder konfliktseria-lisierbare Ablauf ist view-serialisierbar, aber nicht umgekehrt.
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 27
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
Bemerkung 2.2 Ein Algorithmus auf Basis dieses Satzes erfordert die Beobachtung allerTransaktionen. Deshalb gehen DBMS nach Regeln/Protokollen vor, die Serialisierbarkeitgarantieren sollen, ohne dass alle Transaktionen beobachtet werden müssen.
Ein solches Protokoll ist Sperr-Protokoll (Locking), ein anderes Multiversionierung (Multiver-sioning)
Wir betrachten nun ein einfasches Modell für ein Sperr-Protokoll:
2-Phasen-Lock-Protokoll
Wir verwenden folgendes (simple)Modell der binären Sperren:
l(x) Sperre auf Datenobjekt x (lock)u(x) Freigeben von x (unlock)
Protokoll:
A) Verhalten der Transaktionen
1. Eine Transaktion muss vor jeder Read- oder Write-Aktion auf x die Aktion l(x)erfolgreich ausführen.
2. Eine Transaktion muss die Aktion u(x) ausführen, wenn sie keine weitern Aktionenauf x mehr vor hat.
B) Verhalten des Systems
1. l(x) einer Transaktion wird nur dann ausgeführt, wenn keine andere Transaktioneine Sperre auf x hat, andernfalls muss die Transaktion warten.
2. Wenn eine Freigabe u(x) erfolgt, werden eventuell wartende Transaktionen wiederangestoßen.
Bemerkung 2.3 Modell ist sehr einfach, wird so in DBMS nicht verwendet. Oft wird unter-schieden zwischen sogenannten Modus-Sperren:
• read-lock: Nur lesender Zugriff erlaubt, aber von verschiedenen Transaktionen
• write-lock: Exklusiver Zugriff einer einzigen Transaktion
Bemerkung 2.4 Das Befolgen des Protokolls garantiert nicht die Serialisierbarkeit vonTransaktionen.
Definition 2.7 Eine Transaktion folgt dem 2-Phasen-Sperr-Protokoll (2PL), wenn sie alleSperr-Aktionen l vor der ersten Freigabe u ausführt.
Man nennt die erste Phase, in der die Locks angefordert werden, die Wachstumsphase, unddie zweite Phase, in der nur noch Freigaben erfolgen, die Schrumpfungsphase
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 28
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
Satz 2.2 Das 2PL-Protokoll garantiert, dass nur Abläufe entstehen, die (konflikt-)serialisierbarsind.
Warum?
Induktion über die Zahl n der Transaktionen:
n = 1√
Angenommen: n Transaktionen T1, T2, T3, · · · , Tn. Sei Ti die Transaktion, die das erste ui(x)macht. Dann kann man alle Aktionen von Ti ganz an den Anfang schieben.
Angenommen Tii steht im Konflikt zu Tj und Tj kommt vor Ti
· · ·wj(x) · · ·wi(x) · · ·ui(x) · · ·uj(x), dann muss es nach 2PL-Protokoll Sprerren geben
· · · lj(x) · · ·wj(x) · · · li(x) · · ·wi(x) · · ·ui(x)
Widerspruch: Damit li(x) ausgeführt werden kann, müsste es vorher ein uj(x) geben, dadurchwäre ui(x) nicht mehr die erste Freigabe!
· · · lj(x) · · ·wj(x) · · ·uj(x) · · · li(x) · · ·wi(x) · · ·ui(x)
Also ist der Ablauf äquivalent zu TiS′ und S
′ enthält nur n− 1 Transaktionen, ist also nachder Induktionsveraussetzung serialisierbar.
Bemerkung 2.5 Das 2PL-Protokoll verhindert Verklemmungen (Deadlocks) nicht!
Deadlocks/Verklemmungen
Definition 2.8 Der Wait-For-Graph ist ein gerichteter Graph mit den Transaktionen alsKnoten. Zwei Transaktionen T und U sind durch eine gerichtete Kante verbunden, wenn T erstfortfahren kann, nachdem U eine Sperre auf ein Datenobjekt freigibt
T U = „T wartet auf U“
Beispiel 2.3 Die Transaktionen T1, T2, T3 beabsichtigen folgenden Aktionen
T1 : l1(a); r1(a); l1(b);w1(b);u1(a);u1(b);
T2 : l2(c); r2(c); l2(a);w2(a);u2(c);u2(a);
T3 : l3(b); r3(b); l3(c);w3(c);u3(b);u3(c);
T1 T2
T3
Möglicher Ablauf:
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 29
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
Zeit
T1 T2 T3
l(a), r1(a)l2(c), r2(c)
l3(b), r3(b)l2(a)← T2wartet auf T1
l3(c)← T3wartet auf T2
l1(b)← T1wartet auf T3
Satz 2.3 Der Wait-For-Graph hat genau dann einen Zyklus, wenn eine Verklemmung (Dead-lock) entstanden ist.
Bemerkung 2.6 Der Wait-For-Graph kann auf zwei Arten verwendet werden.
• Deadlock-Erkennung
• Deadlock-Vermeidung
Algorithmus zur Deadlock-Erennung
Stelle den Wait-For-Graph als matrix dar, die Zeilen und Spalten repräsentieren die Transak-tionen T1, T2, · · · , Tn und für ein Element Wij der Matrix gilt:
Wi,j =
{1 wenn Ti auf Tj wartet0 andernfalls
In unserem Beispiel:
T1 T2 T3
T1 0 0 1T2 1 0 0T3 0 1 0
Schritte zur Deadlock-Erkennung
• Entferne alle Transaktionen aus der Matrix, die an keinem Zyklus beteiligt sind, nämlich
– a) die Zeilen mit allen Einträgen = 0 oder
T a) nur eingehende Pfeile (Kanten)
T b) nur ausgehende Pfeile (Kanten)
– b) die Spalten mit allen Einträgen = 0
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 30
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
• Wenn jetzt noch Transaktion übrig sind, dann müssen sie an einem Zyklus beteiligtsein.
TAlso, Deadlock erkanntwähle ein Opfer. D. h. breche eine Transaktion ab.↪→ weiter mit schritt 1
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 31
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
2.3 Isolationslevel in SQL-Datenbanksystemen
Phänomene bei verschränkten Transaktionen:
1. Lost Update[1]
T1 T2 Saldo
100eupdate kontoset saldo=200where ktoNr=1 200e
update kontoset saldo=250where ktoNr=1commit 250e
rollback 100e
2. Dirty Read
T1 T2 Saldo
100eupdate kontoset saldo=200where ktoNr=1 200e
select saldofrom kontowhere ktoNr=1...liest und verwendet200e...commit
200e
rollback 100e
T2 verwendet den niegültigen Saldo von 200e
3. Nonrepeatable Read
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 32
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
T1 T2 Saldo
100eselect saldofrom kontowhere ktoNr=1
liest 100e...select saldofrom kontowhere ktoNr=1
liest 200e
update kontoset saldo=saldo + 100where ktoNr=1
commit 200e
T1 liest innerhalb einerTransaktion verschiedeneWerte
3.’ Lost Update[2] (Variante von Nonrepeatable Read)
T1 T2 Saldo
100eselect saldofrom kontowhere ktoNr=1
liest 100e
update kontoset saldo = 200where ktoNr=1
commit
select saldofrom kontowhere ktoNr=1
liest 100
update kontoset saldo = 150where ktoNr = 1
commit
200e
150e
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 33
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
4. Phantom Row
Konto1 100e2 200e
T1 T2
select sum(saldo)from konto
liest 300e
select sum(saldo)from konto
liest 400e
insert into kontovalues (3,100)
commit
Werte weichen ab,weil neue Zeile (Phantom)entstanden ist
Bemerkung 2.7 Die Beispiele sind so konstruiert, dass SQL-Anweisungen verwendet werden.Achtung: Innherhalb einer SQL-Anweisung führt DBMS oft mehrere Aktionen aus, d.h.die Phänomene können auch auftreten, wenn in einer Transaktion nur eine SQL-Anwendungausgefhrt wird.
Definition 2.9 Definition der Isolationslevel (SQL 92)
Level Phänomen Dirty-Read Nonrepeatable-Read Phantom-RowREAD UNCOMMITED erlaubt erlaubt erlaubtREAD COMMITED garantiert nicht erlaubt erlaubtREPEATABLE READ garantiert nicht garantiert nicht erlaubtSERIALIZABLE garantiert nicht garantiert nicht garantiert nicht
Isolationslevel in SQL 92
Wenn ich für meine Transaktion <LEVEL> verlange, garantiert mir das DBMS, dass
< LEV EL > Dirty Read Nonrepeatable Red Phantom RowREAD UNCOMMITED möglich möglich möglichREAD COMMITED unmöglich möglich möglichREPEARTABLE READ unmöglich unmöglich möglichSERIALIZABLE unmöglich unmöglich unmöglich
ist
SQL-Standard:
„The isolationlevel of an SQL-transaction defines the degree to which the operations onSQL-data · · · in that SQL-transaction are affected by the effects of · · · of operations · · · inconcurrent SQL-transactions“
SQL: 2003
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 34
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
Zuordnung des DBMS bzgl. Isolationslevel gegenüber andere Transaktionen.
2.3.1
2.3.2
2.3.3 Implementierung durch Sperrverfahren
Konzepte:
Arten von Sperren:
Readlocks (= Shared Lock)Writelock (Exclusive Locks)Predicated Locks/Prädikatsperre
[Prädikatsperre: select * from T where C // C = Prädikat
Prädikatsperre bedeutet: während der Sperre besteht, bleibt des Ergebnis des Prädikatsunveränder. Nur solche Anordnungen sind erlaubt, die die Auswertung des Prädikats nichtverändern]
Person:
Pid Name1 Hans2 Erika
select Pid from Personwhere Name = ’Hans’
Ergebnis: [1,Hans]
Pid Nme1 Hans2 Erika3 Hans
Pid 3: Phantom Row
Ergebnis: [1,Hans]
[3,Hans]
=⇒ UNGLEICH
Dauer der Sperre:
kurze Sperre = Sperre während des Zugriffs
Lange Sperre = Besteht bis zum Commit, d. h. bis zum Ende der Transaktion.
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 35
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
Sperrprotokoll:
Level Readlocks WritelocksREAD UNCOMMITTED keine schreiben nicht erlaubt im
Level READ UNCOMMITEDREAD COMMITTED kurze Locks auf
Ergebnismengelange Prädikatlock beiINSERT, UPDATE, DELETE
REPEATABLE READ lange Sperre aufErgebnismenge
lange Prädikatlock beiINSERT, UPDATE, DELETE
SERIALIZABLE lange Prädikatlock beiSELECT
lange Prädikatlock beiINSERT, UPDATE, DELETE
Dise Implementierung hat z. B. Microsoft SQL-Server
2.3.4 Implementierung durch Multiversioning
Grundlage des DBMS führt zu jedem Datenobjekt eine Versionsnummer und hat einen globalenVersionzähler
1. Read-only Multiversioning
Bei Beginn der Trnsaktion muss man unterscheiden
• Read.only - Transaktion (Isolationslevel READONLY)
erhält Schnappschuss der Datenbank zum Zeitpunkt des ersten Zugriffs der Trans-aktion
• Read/Write - Transaktion
Striktes 2PL-Protokoll (Sperrprotokoll)
2. Read-Consistency Multiversioning ConstraintCollection Control
Bei Beginn der Transaktion read-only oder read/write
• Read-only - Transaktion erhält Schnappschuss
• Schreibaktion in Read/Write-Transaktion benötigt einen langen Write-Lock.
• Leseaktion in Read/Write - Transaktion erhält stets die aktuellste Version.
=⇒ Implementierung von READ COMMITTED in Oracle/PostgreSQL
• Snapshot Isolation
Keine Unterscheidung read-only oder read/write bei Beginn der Transaktion
– Jede lesende Aktion erhält die werte zu Beginn der Transaktion(Schnappschuss – Read-Consistency)
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 36
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
– Zwei parallele Transaktionen müssen die disjoint-write-Eigenschaft haben
disjoint-write = dürfen nur unterschiedliche (disjunkte) Datenobjekte ändern,andernfalls wird eine der beiden abgebrochen.
=⇒ Implementierung von SERIALIZABLE in Orace und Implementierung conSNAPSHOT in MS-SQL Server 2005
Bemerkung 2.8 Snapshot-Isolation verhindert zwar die Phänomene nach SQL-Standard,garantiert aber nicht Serialisierbarkeit. (Besp.: als Übungsaufgabe)
Bemerkung 2.9 Beim Wechsel zwischen DBMS mit unterschiedlichen Implementierungender Isolationslevel können subtile Probleme auftreten!!
2.4 Strategien der Nebenläufigkeitskontrolle
Datenbank- und Geschäftsstrategie
Motivation 1 Beispielcode
1...
try{3 con . s e t T r a n s a c t i o n I s o l a t i o n ( Connection .
TRANSACTION_SERIALIZABLE)// diverse Datenbank-Aktionen
5...
commit ( ) ;7 }
catch ( e ) {9
MessageBox mb = →11 new MessageBox ( " Fehler " ) ;
13
con . r o l l b a c k ( ) ;15 MessageBox mBox = new MessageBox ( Fehler " ) ;
b e s s e r vertauschen con . r o l l b a c k ( ) ;
Begriffe:
kurze Transaktion Datenbanktransaktion ohne Benutzerinteraktion
lange Transaktion Datenbanktransaktion mit Benutzerinteraktion
(Vorsicht: Begriffe werden in Büchern unterschiedlich verwendet)
Motivation 2 Beispiel: Kartenvorverkauf Alteoper Frankfurt
Schritt 1 System zeigt freie Plätze der Veranstaltung ]*
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 37
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
Schritt 2 Kunde wählt Plätze
Schritt 3 System reserviert die Plätze und bucht Preis ab. (EC-Karte) ]+
* = Datenbanktransaktion *+ = Datenbanktransaktion +
]Geschäftstransaktion
Datenbank-Transaktion: Transaktion gesteuert durch durch DBMS
Geschäfts-Transaktion: Ein Ablauf eines Geschäftsprozesses mit zusammengehörenden,evtl. mehreren Datenbank-Transaktionen
Grundprinzip: Vermeide lange Transaktionen.
Also möglichst: Geschäftstransaktion = eine kurze Datenbank-Transaktion
Beispiel: Abheben von Konto am Geldautomaten:
Schritt 1 Sammle alle benötigten Informationen: Identität des Kunden, Konto, Betrag etc.
Schritt 2 Buche Kontoveränderung und gib Geld aus.
//]X
= kurze Transaktion
Schritt 3 Biete weitere Daten an
Bemerkung 2.10 Art die Transaktion abzuhlen hat Einfluss auf die Gestaltung derInteraktion mit dem Benutzer!
Was tun, wenn das Grundprinzip nicht anwendbar/praktisch ist?
1. Optimistische Strategie – Kartenvorverkauf
Spalte die Geschäftstransaktion in mehrere kurze Datenbanktransaktionen auf
• Interaktion mit dem Benutzer außerhalb der Datenbanktransaktion
• Anwendung geht davon aus, dass Konflikt mit anderen Transaktionen unwahrschein-lich ist (deshalb „optimistisch“)
Beispiel: Kartenvorverkauf
Schritt 1: Kurze (lesende) Transaktion in Isolevel READ_COMMITED zeigt freie Plätze
Schritt 2: Kunde wählt Plätze
Schritt 3: Kurze (schreibende) Transaktion in Isolevel SERIALIZABLE schreibt die Bu-chung des Kunden.
Erfolgreich, wenn zwischenzeitlich niemand anderes die Plätze gekauft hat.
↪→ Sonst: wieder von vorne beginnen
• In Schritt 3 Check auf Veränderung z.B. per Timestamp prüfen.
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 38
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
• · · ·
2. Pessimistische Strategie – Vorgangsbearbeitung (Kontobuchung, · · · )
Während der Geschäftstransaktion findet eine lange Datenbanktransaktion statt.
• Anwendung geht davon aus, dass ein Konflikt mit einer anderen Transaktionunbedingt vermieden werden muss, (deshalb pessimistisch).
Beispiel: Vorgangsbearbeitung bei einer Behörde
Szenario: Personenbezogener Vorgang, z. B. KFZ-Zulassung, Anträge bei Behörden.
Typisch:
• Bearbeitung findet im Beisein des Kunden oder auf Basis von Akten statt.
• Bearbeitet erfordert Schritte, die man nicht im voraus abfragen kann.
• Bearbeitung kann evtl. sehr lange Dauern (Stunden).
Vorgehensweisen:
a) Lange Datenbanktransaktion in Isolationslevel REPEATABLE_READ (mind.).
b) Lange Datenbanktransaktion auf einer speziellen Tabelle, die den Zugriff auf Nutz-daten regelt (Nadelöhr).
c) Wie b. aber mit kurzen Transaktionen.
3. Kompensatorische Strategie – Verfügbarkeitsprüfung
Beispiel: Verfügbarkeitsprüfung
Szenario: Kundenbestellungen von Artikeln im Lager.
• Kunden bestellen Artikel, Verfügbarkeit wird sofort geprüft.
• Kunden bestellen mehrere Artikel und geben Bestellparameter sukzessive ein.
Kunde A, B:
Pessimistische Strategie → B muss warten, bis A fertig ist.
Optimistische Strategie → B wird Artikel zugeordnet, obwohl er nicht mehr verfügbarist.
Kompensatorische Strategie:
Die Reservierung durch Kunde A führt zu
a) Kurzere Datenbanktransaktion „Vermindere Bestand um 1“
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 39
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
b) zum Notieren einer kompensatorischen Transaktion „Erhöhe Bestand um 1“
Bei Commit der Geschäftstransaktion: Lösche notierte/gemerkte kompensatorischeTransaktion
Bei Abbruch der Geschäftstransaktion: Führe alle notierten/gemerkten kompen-satorischen Transaktionen aus.
3 Verteilte Datenbanken
Hamburg
Stuttgart München
Ora
Ora Ora
geografische verteilte Dateneine (logische) Datenbank
3.1 Architektur verteilter Datenbanken
Gründe für verteilte Datenbank
Beispiel 3.1 nationale/globale Firma
Beispiel 3.2 Bestellung bei Azamon, Bezahlung per Kreditkarte
Unterschiede:
Beispiel 3.1: eine logische Datenbank
Beispiel 3.2 Kooperation zweier Datenbanken in einem Geschäftsprozess
hier typisch Beispiel 3.1
Forderung an eine verteilte Datenbank 12 + 1 Ziele (ChrisDate)
Ziel 0 Fundamentales Prinzip: „Transparent“
Ziel 1 Lokale Autonomie
Ziel 2 Keine Abhängigkeit von einer Zentrale
Ziel 3 Unterbrechungsfreier Betrieb
Ziel 4 Ortunabhängigkeit
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 40
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
Ziel 5 Fragmentierungsunabhängigkeit
Ziel 6 Replikationunabhängigkeit
Ziel 7 Verteilte Anfragen
Ziel 8 Verteilte Transaktionen
Ziel 9 Hardwareunabhängigkeit
Ziel 10 Unabhängigkeit vom Betriebsystem
Ziel 11 Unabhängigkeit vom Netz
Ziel 12 Unabhängigkeit vom DBMS
Typen verteilter Datenbank
bzgl. DBMS:
homogene verteilte Datenbank (z. B. überall Oracle)
heterogene verteilte Datenbank (Mix von DBMS)
bzgl. lokale Autonomie
eng integrierte verteilte DB (∼= nur globale Daten)
förderierte verteilte Datenbank (∼= lokale Daten + globale Daten)
Multidatenbanksystem – lose Kopplung autonomer Datenbank
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 41
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 42
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
3.2 Datenspeicherung in verteilten Datenbanken
Fragmentierung
Horizontale Fragestellung
Fragment 1
Fragment 2
Fragment 3
Beispiel 3.3 Tabelle Mitarbeiter fragmantiert nach Standort
Zerlegung nach select z. B. select * from Mitarbeiter where Standort =?
Verbindung der Fragmente durch Union
Vertikale Fragmentierung
PK
Fragment 1
Fragment 2
Zerlegung durch Projektionen z. B.
select Mid, telefon from Mselect Mid, gehalt from M
Verbindung des Fragmente durch join (verlustfrei)
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 43
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
Gemischte Fragmentierung
Beispiel Mitarbeiter
restliche Spalten
horizontalfragment
nachStandort
gehaltsrelevanteSpalten fürzentrale Personal-abteilung
Replikationen redundante Datenhalterung
Synchrone Replikation alle Kopien sind immer auf dem gleichen Stand
Asynchrone Replikation Aktualisierung erfolgt nicht synchron, sondern z. B.periodisch
Beispiel: Mobile Datenbank
→ später mehr
Kataloginformation in einer verteilten Datenbank
Zentraler Katalog z. B. durch Namensdienst
• verletzt Ziel 2 von Daten
• einfach
Verteilter Katalog Varianten:
• vollredundanter Katalog (= jeder Standort hat den kompletten Katalog)
• hierarchischer Clusterkatalog
• nur lokale Kataloge (= volle Verteilung)
3.3 Verteilte Anfragen
3.3.1 Kosten von SQL-Anfragen:
• Hauptspeicheroperationen (vernachlässigbar)
• I/O-Operationen (der Kostenfaktor bei zentralisierten DB)
• Übertragungskosten (der Kostenfaktor bei verteilten DB)
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 44
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
Kostenmodell:
n Zahl der zu übertragenden BytesC0 Initialisierungszeit in SekundeC1 Datenrate in Bits/s
Kosten: C0 + nC1
Beispiel 3.4 Datenbank
S(SNo,City) 10.000 Tupel aus Stanort AP (PNo, Color) 10.000 Tupel aus Standort BSP (SNo, PNo) 10.000.000 Tupel aus standaortA
Jedes Tupel hat 25 Bytes
Situation:
• Zahl der roten Teile: 10
• Zahl der Lieferungen aus London: 100.000
• C0 = 0, 1 SekundenC1 = 50.000 Bits/s
Anfragen
Select SNo from S natural join SP2 natural join P where City=’ London ’
an Color=’ red ’
Strategien für verteilte Anfragen, gestellt an Standort A
1. Übertrage die kompletten Tabelle P von B nach A und führe dann die Anfrage durch |6,67 Minuten
2. Berechne S 1 SP und prüfe für jeden Datensatz, ob das Teil rot ist, mit 2 Verbindungpro Anfrage (hin und zurück) 5,56 Sekunden
3. Restriktion von P auf roten Teile aus Standort B. übertrage Restriktion nach A undführe dort die Anfrage durch 0,1 Sekunden
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 45
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
3.3.2 Joins inverteilten Datenbanken
Beispiel :
select * from SP natural join P
am Standort A
Semijoin
1. Berechne am standort A die Projektion SPp auf die Joinattribute SPp = φPNo(SP )übertrage SPp auf Standort B
2. Berechne am standort B den Join RR = SPp 1 P übertrage PR zurück nach A
3. Berechne nun an Standort A den Join SP 1 PR
Bloom join
1. Wähle eine Hashfunktion h und eine Zahl n, sodass h die Werte des Joinattributs aufeine Zahl < n abbildet.
An Standort A bildet man BitVektor
0 1 2 i n− 11 0 1· · · ·· Länge
Gibt es zum Index x in SP einen Wert x mit h(x) = i, dann ist das Bit am Index i 1, 0sonst.
Übertrage diesen BitVektor an Standort B.
2. Selektiere diejenigen Zeilen in P, für die gilt:
X ist der Wert des Joinattributs und am Index h(x) steht im BitVektor 1.
Die entstehende Tabelle nennt man PR (Reduktion von P)
Übertrage diese Tabelle nach Standort A
3. Bilde an Standort A den Join SP 1 PR
Beispiele in den Übungen
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 46
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
3.4 Änderung verteilter Daten und Replikation
3.4.1 Techniken synchroner Replikation
RoWA-Verfahren read-one-write-all
In einer Transaktion aller Kopien aktualisiert (write-all), beim Lesen kann man x-beliebigeKopie nehmen (read-one)
→ Ändernde Transaktion dauert so lange, bis alle Kopien aktualisiert sind.
In der Praxis nur für Cluster nahe benachbarter DB-Systeme verwendet.
Abstimmverfahren
Nicht alle Kopien werden unbedingt sofort aktualisiert, sondern nur eine Mehrheit
Beispiel 3.5 7 von 10
In einer ändernden Transaktion werden mindestens 7 kopien sofort aktualisiert.
Lesende Anfragen müssen 4 Kopien lesen um sicher aktuelle Daten zu finden
Fazit zu synchroner Replikation:
aufwändigbei langsamen Verbindungen nicht praktisch
3.4.2 Techniken asynchroner Replikation
Replikation mittels Masterkopie
Die Kopien werden unterschieden in ein Original = Masterkopie und in Duplikate = Sekun-därkopien.
Eine ändernde Transaktion muss tets des Original, die Masterkopie ändern.
Später werden Änderungen des Masterkopie an die Sekundärkopien weitergeleitet durch – volleKopie oder durch – Deltas.
Auch genannt:
Publisher-Subscriber-Verfahren
Masterkopie
Abonnent-Sekundärkopien
Push-Modell Publisher initialisieret die Synchronisation
Pull-Modell Subscriber fragen nach, ob neue Daten da sind.
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 47
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
Peer-to-Peer-Replikation
Gleichberechtigte Kopien von denen jede verändert werden kann.
Zeitversetzte Synchronisation aller Kopien.
Man bracuht konfliktlösungsstrategie
• Konfliktvermeidung
• Priorisierung
• zeitliche Kriterien
3.4.3 Beispiel
Oracle: Multimaster-Replikation
3.5 Verteilte Transaktionen
Vorbemerkung: Konzept der Verarbeitung von Transaktionen
ACID
RecoveryIsoLeveletc
Grundidee: führe während der Transaktion ein Logik
Prinzipielle Inhalt eines Logs:[ begin T] Beginn einer Transaktion // T: interne Id derTransaktion
[read x T] Datenobjekt x wurde von Transaktion T gelesen
[write x T Vbefor, Vafter] // Vbefor= Wert von x vor write; Vafter Wert von x nach write
[comit T] commit
[abort T] rollback
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 48
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
[eot T] ende der Transaktion
[checkpoint] alle beendeten Transaktionen sind in BD geschrieben
Vorgehen beim Recovery
• DBMS startet wieder
• liest des Logfile rückwärts (von hinten nach vorne)
[begin T12]...[write y, T12, yb, ya]*...[write x, T12, xb, xa]*...
* erfordert Rollback
• Rollback aller offenen Transaktionen
3.5.1 Acrchitektur verteilter Transaktionen
Lokales DBMS hat einen Transaktionsmanager der ACID garantiert.
Globale Transaktion, die in lokale Subtransaktion erfüllt
Transaktionskoordinator
• startet globale Transaktion
• zerlegt sie in Subtransaktion und delegiert diese an lokale DBMS
• koordiniert das Ergebnis der lokalen Transaktionen
Beginn der globalen TransaktionBeginn von lokalen TransaktionDatenänderung lokaleLokale CommitsGlobale Commit
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 49
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
3.5.2 2-Phasen-Commit-Protokoll (2PC)
Beteiligte:
Koordinator Transaktionskoordinator der globalen Transaktion
Teilnehmer Transaktionsmanager der lokalen Subtransaktion
Ziel: garantiere, dass entweder alle Subtransaktion erfolgreich sind oder dass alle scheitern!
Das Protokoll beginnt, in dem der Koordinator ein globales Commit ausführen möchte
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 50
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
neue Einträge in Log:
[prepare T] Prepare-Phase des 2PC[ready T]
Analyse des Protokolls
Beispiel 3.6 Ausfall eines Teilnehmer
1. Vor der Antwort auf 〈prepare〉
→ globales Abort
2. nach der Antwort auf 〈prepare〉
Teilnehmer führt Recovery durch
Teilnehmer kann in Log entdecken
[eot T] X, oder[commit T] X[write · · · ] kann nicht sein[ready T] =̂ ich war bereit für Commit, weiß aber nicht wie die globale Transaktionbeschrieben wurde also Koordinator fragen[abort T]
Beispiel 3.7 Ausfall des Koordinators
Die Teilnehmer müssen entscheiden, was zu tun ist, ohne Möglichkeit der Kommunikationmit dem Koordinator
Im Zustand ———– dies tun〈commit〉 bekommen ausführen, 〈ACK〉 später senden〈abort〉 bekommen ausführen, 〈ACK〉 später senden[ready, T] geschrieben warten bis Koordinator Ergebnis der Abstimmung meldet
BLOCKADE!
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 51
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
4 Informationssysteme zur Entscheidungsfindung
4.1 Data-Warehouses
operatives GeschäftAuftragsbearbeitungLagerhaltungBuchungssysteme...
OLTP OnlineTransaction Processing
EntscheidungsfragenTrends im KundenverhaltenPreisenwicklungKennziffern...
OLAP Online↪→ DatenanalyseDSS „Decision Support System“
Data Warehouse Sammlung (bereinigten) unternehmensweiten Daten zur Entscheidungsfin-dung mit Datenanalysewerkzeugen.
Eigenschaften:
• sehr groß, Terabyte!
• historische Daten
• komplexe Anfraen mit Aggregationen
• Updates periodisch
Data Marts Ausschnitt eines Datawarehouse für spezielle Zwecke
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 52
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
ETL Prozess Extract-Transform-Load
• Datenmigration
• Datenbereinigung
• Datenüberwachung
• Datenmenge
Konzeptionelles Modell von Data Warehouses
Multidimensionales Datenmodell
1. Menge von Fakten (häufig numerische Werte) z. B. Verkaufszahlen, Einnahmen, ROI(Return on Investments)
2. Jedes Faktum hängt von einer Menge von Dimensionen ab z. B. Produkt, Datum,Kunden, Verkaufsort, . . .
3. Die Dimensionen zusammen bestimmen eindeutig ein Faktum, d. h ein Faktum in einwert in multidimensionalen Raum
Beispiel 4.1 Dimensionen: Produkt, Ort, DatumFaktum: Verkaupszahl
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 53
Rami SwailemFH Gießen-Friedberg
DB2Mitschrift
E
D
C
B
A
F OF GI MR BH FBOrt
Datum
112 Produkt E in Fam 1.1 verkauft
In der Regel sind die Dimensionen hierarchisch organisiert z. B. Verkaufsort
Warengruppe
Kategorie
Produkt
Region Hessen, By
Land D, F, · · ·
Ort F, oF, M, S · · ·
Woche Monat
Jahr
Tag
Typische Aktionen im multidimensionalen Modell
Pivotierung/Rotation Betrachtung des Wurfels aus verschiedenen Prespektiven z. B. Produktbezogen auf Datum/Ort
Roll-Up stärkere Aggregation z. B. vorher: Produkt pro Tag nachher: pro Monat
Drill-Down detailierte Darstellung
Drill-Acros Kennzahl wechseln
Slice Scheibe herausschneiden
Dice Teilwurfel herausschneiden
WS 06/07
DB
2_M
itschrift.tex,v,1.1,January30,
2007at
12:59:41C
ET Seite 54