Datenbank und Informationssysteme - · PDF fileSQL Ergebnis-mengen S R *C Beispiel 1.1 Die...

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


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


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


2007at

12:59:41C

ET Seite 4


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


2007at

12:59:41C

ET Seite 5


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


2007at

12:59:41C

ET Seite 6


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


2007at

12:59:41C

ET Seite 7


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


2007at

12:59:41C

ET Seite 8


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


2007at

12:59:41C

ET Seite 9


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


2007at

12:59:41C

ET Seite 10


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


2007at

12:59:41C

ET Seite 11


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


2007at

12:59:41C

ET Seite 12


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


2007at

12:59:41C

ET Seite 13


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


2007at

12:59:41C

ET Seite 14


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


2007at

12:59:41C

ET Seite 15


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


2007at

12:59:41C

ET Seite 16


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


2007at

12:59:41C

ET Seite 17


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


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


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


2007at

12:59:41C

ET Seite 20


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


2007at

12:59:41C

ET Seite 21


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


2007at

12:59:41C

ET Seite 22


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


2007at

12:59:41C

ET Seite 23


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


2007at

12:59:41C

ET Seite 24


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


2007at

12:59:41C

ET Seite 25


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


2007at

12:59:41C

ET Seite 26


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


2007at

12:59:41C

ET Seite 27


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


2007at

12:59:41C

ET Seite 28


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


2007at

12:59:41C

ET Seite 29


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


2007at

12:59:41C

ET Seite 30


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


2007at

12:59:41C

ET Seite 31


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


2007at

12:59:41C

ET Seite 32


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


2007at

12:59:41C

ET Seite 33


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


2007at

12:59:41C

ET Seite 34


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


2007at

12:59:41C

ET Seite 35


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


2007at

12:59:41C

ET Seite 36


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


2007at

12:59:41C

ET Seite 37


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


2007at

12:59:41C

ET Seite 38


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


2007at

12:59:41C

ET Seite 39


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


2007at

12:59:41C

ET Seite 40


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


2007at

12:59:41C

ET Seite 41


DB2Mitschrift

WS 06/07

DB

2_M


2007at

12:59:41C

ET Seite 42


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


2007at

12:59:41C

ET Seite 43


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


2007at

12:59:41C

ET Seite 44


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


2007at

12:59:41C

ET Seite 45


DB2Mitschrift

3.3.2 Joins inverteilten Datenbanken

Beispiel :

select * from SP natural join P

am Standort A

Semĳoin

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


2007at

12:59:41C

ET Seite 46


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


2007at

12:59:41C

ET Seite 47


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


2007at

12:59:41C

ET Seite 48


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


2007at

12:59:41C

ET Seite 49


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


2007at

12:59:41C

ET Seite 50


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


2007at

12:59:41C

ET Seite 51


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


2007at

12:59:41C

ET Seite 52


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


2007at

12:59:41C

ET Seite 53


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


2007at

12:59:41C

ET Seite 54

Datenbank und Informationssysteme - · PDF fileSQL Ergebnis-mengen S R *C Beispiel 1.1 Die...

Documents

Transcript of Datenbank und Informationssysteme - · PDF fileSQL Ergebnis-mengen S R *C Beispiel 1.1 Die...

Datenbank und Informationssysteme - · PDF fileSQL Ergebnis-mengen *S *R *C Beispiel 1.1 Die...

Documents

Transcript of Datenbank und Informationssysteme - · PDF fileSQL Ergebnis-mengen *S *R *C Beispiel 1.1 Die...

Datenbank und Informationssysteme - · PDF fileSQL Ergebnis-mengen S R *C Beispiel 1.1 Die...

Transcript of Datenbank und Informationssysteme - · PDF fileSQL Ergebnis-mengen S R *C Beispiel 1.1 Die...