Objektorientierte Datenbanken

Beim vorigen Mal: Architektur von DB-Systemen Grundlagen der Entity-Relationship-Modellierung Probleme beim Übergang in relationale Modellierung

Heute: Anfragesprachen: SQL (kurz) Mehrbenutzerbetrieb und Sperren Transaktionen Anbindung an Programmiersprachen Probleme der relationalen Datenbanktechnologie

Ralf Möller, FH-Wedel

Übung

Ziel: Vertiefung des Vorlesungsstoffes ... ... durch Lösen von Aufgaben ... durch Beantwortung von Fragen

Durchführung: Christine Apfel, Katrin FitzTermin: Mi, 8.00 UhrOrt: RZ2Beginn: 16.4.03

Literatur, Details und Zusatzinformationen

Präsentationen: http://www.fh-wedel.de/~mo/lectures/oodb-sose-03.html

Literatur:

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.

Weitere Literatur und Danksagung

A. Kemper, A. Eickler, Datenbanksysteme: Eine Einführung

Diese Vorlesungbasiert aufPräsentations-material zu diesem Buch

Vom Entwurfs- zum Implementierungsmodell

ProfessorenPersNr Name Ran

gRaum

2125 Sokrates C4 2262126 Russel C4 2322127 Kopernikus C3 3102133 Popper C3 522134 Augustinus C3 3092136 Curie C4 362137 Kant C4 7

VorlesungenVorlNr Titel SWS Gelesen

Von5001 Grundzüge 4 21375041 Ethik 4 21255043 Erkenntnistheorie 3 21265049 Mäeutik 2 21254052 Logik 4 21255052 Wissenschaftstheorie 3 21265216 Bioethik 2 21265259 Der Wiener Kreis 2 21335022 Glaube und Wissen 2 21344630 Die 3 Kritiken 4 2137

Professoren Vorlesungenlesen1 N

Vorsicht: So geht es NICHT

ProfessorenPersNr Name Ran

gRaum liest

2125 Sokrates C4 226 50412125 Sokrates C4 226 50492125 Sokrates C4 226 4052

... ... ... ... ...2134 Augustinus C3 309 50222136 Curie C4 36 ??

VorlesungenVorlNr Titel SWS5001 Grundzüge 45041 Ethik 45043 Erkenntnistheorie 35049 Mäeutik 24052 Logik 45052 Wissenschaftstheorie 35216 Bioethik 25259 Der Wiener Kreis 25022 Glaube und Wissen 24630 Die 3 Kritiken 4

Professoren Vorlesungenlesen1 N

Anomalien

Update-Anomalie: Was passiert wenn Sokrates umzieht Lösch-Anomalie: Was passiert wenn „Glaube und Wissen“ wegfällt Einfügeanomalie: Curie ist neu und liest noch keine Vorlesungen

ProfessorenPersNr Name Rang Raum liest2125 Sokrates C4 226 50412125 Sokrates C4 226 50492125 Sokrates C4 226 4052

... ... ... ... ...2134 Augustinus C3 309 50222136 Curie C4 36 ??

VorlesungenVorlNr Titel SWS5001 Grundzüge 45041 Ethik 45043 Erkenntnistheorie 35049 Mäeutik 24052 Logik 45052 Wissenschaftstheorie 35216 Bioethik 25259 Der Wiener Kreis 25022 Glaube und Wissen 24630 Die 3 Kritiken 4

Relationale Modellierung der Generalisierung

Fachgebiet

Assistenten

Professoren

Raum Rang

is_a Angestellte

PersNr Name

Angestellte: {[PersNr, Name]}Professoren: {[PersNr, Rang, Raum]}Assistenten: {[PersNr, Fachgebiet]}

Relationale Modellierung schwacher Entitytypen

Studenten ablegen Prüfungen1 N Note

PrüfTeil

MatrNr

Vorlesungen

umfassen

VorlNr

abhalten

Professoren

PersNr

N N

M M

Prüfungen: {[MatrNr: integer, PrüfTeil: string, Note: integer]}

umfassen: {[MatrNr: integer, PrüfTeil: string, VorlNr: integer]}

abhalten: {[MatrNr: integer, PrüfTeil: string, PersNr: integer]}

Man beachte, dass in diesem Fall der (global eindeutige) Schlüssel der Relation Prüfung nämlich MatrNr und PrüfTeil als Fremdschlüssel in die Relationen umfassen und abhalten übernommen werden muß.

Relationale Modellierung schwacher Entitytypen

standardisierte - Datendefinitions (DDL)-- Datenmanipulations (DML)-- Anfrage (Query)-Sprache

derzeit aktueller Standard ist SQL 99 objektrelationale Erweiterung

SQL

Studenten

Assistenten

MatrNr

PersNr

Semester

Name

Name

Fachgebiet

Note

hören

prüfen

arbeitenFür Professoren

Vorlesungen

lesen

voraussetzen

SWS

VorlNr

Titel

Raum

Rang

PersNr

Nach-folgerVorgänger

Name

Uni-Schema

1

N

1

1

N N

N

M

MMN

ProfessorenPersNr Name Rang Raum2125 Sokrates C4 226

2126 Russel C4 232

2127 Kopernikus C3 310

2133 Popper C3 52

2134 Augustinus C3 3092136 Curie C4 36

2137 Kant C4 7

StudentenMatrNr Name Semester24002 Xenokrates 18

25403 Jonas 1226120 Fichte 10

26830 Aristoxenos 8

27550 Schopenhauer

6

28106 Carnap 329120 Theophrastos 2

29555 Feuerbach 2

VorlesungenVorlNr Titel SWS gelesenV

on5001 Grundzüge 4 2137

5041 Ethik 4 2125

5043 Erkenntnistheorie 3 2126

5049 Mäeutik 2 21254052 Logik 4 2125

5052 Wissenschaftstheorie 3 2126

5216 Bioethik 2 2126

5259 Der Wiener Kreis 2 2133

5022 Glaube und Wissen 2 21344630 Die 3 Kritiken 4 2137

voraussetzenVorgänger Nachfolger

5001 5041

5001 5043

5001 5049

5041 52165043 5052

5041 5052

5052 5259

hörenMatrNr VorlNr26120 5001

27550 5001

27550 405228106 5041

28106 5052

28106 5216

28106 5259

29120 500129120 5041

29120 5049

29555 5022

25403 5022

AssistentenPerslNr Name Fachgebiet Boss

3002 Platon Ideenlehre 2125

3003 Aristoteles Syllogistik 2125

3004 Wittgenstein Sprachtheorie 2126

3005 Rhetikus Planetenbewegung 21273006 Newton Keplersche Gesetze 2127

3007 Spinoza Gott und Natur 2126

prüfenMatrNr VorlNr PersNr Note28106 5001 2126 1

25403 5041 2125 2

27550 4630 2137 2

(Einfache) Datendefinition in SQL Datentypen character (n), char (n) character varying (n), varchar (n) numeric (p,s), integer blob oder raw für sehr große binäre Daten clob für sehr große String-Attribute date für DatumsangabenAnlegen von Tabelle create table Professoren

(PersNr integer not null, Name varchar (30) not null Rang character (2) );

Einfache SQL-Anfrage

PersNr Name2125 Sokrates2126 Russel2136 Curie2137 Kant

select PersNr, Namefrom Professorenwhere Rang= ´C4´;

Einfache SQL-Anfragen

Sortierungselect PersNr, Name, Rangfrom Professorenorder by Rang desc, Name asc;

PersNr Name Rang2136 Curie C42137 Kant C42126 Russel C42125 Sokrates C42134 Augustinus C32127 Kopernikus C32133 Popper C3

select distinct Rangfrom Professoren

RangC3C4

Duplikateliminierung

ProfessorenPersNr Name Rang Raum2125 Sokrates C4 226

2126 Russel C4 232

2127 Kopernikus C3 310

2133 Popper C3 52

2134 Augustinus C3 3092136 Curie C4 36

2137 Kant C4 7

StudentenMatrNr Name Semester24002 Xenokrates 18

25403 Jonas 1226120 Fichte 10

26830 Aristoxenos 8

27550 Schopenhauer

6

28106 Carnap 329120 Theophrastos 2

29555 Feuerbach 2

VorlesungenVorlNr Titel SWS gelesenV

on5001 Grundzüge 4 2137

5041 Ethik 4 2125

5043 Erkenntnistheorie 3 2126

5049 Mäeutik 2 21254052 Logik 4 2125

5052 Wissenschaftstheorie 3 2126

5216 Bioethik 2 2126

5259 Der Wiener Kreis 2 2133

5022 Glaube und Wissen 2 21344630 Die 3 Kritiken 4 2137

voraussetzenVorgänger Nachfolger

5001 5041

5001 5043

5001 5049

5041 52165043 5052

5041 5052

5052 5259

hörenMatrNr VorlNr26120 5001

27550 5001

27550 405228106 5041

28106 5052

28106 5216

28106 5259

29120 500129120 5041

29120 5049

29555 5022

25403 5022

AssistentenPerslNr Name Fachgebiet Boss

3002 Platon Ideenlehre 2125

3003 Aristoteles Syllogistik 2125

3004 Wittgenstein Sprachtheorie 2126

3005 Rhetikus Planetenbewegung 21273006 Newton Keplersche Gesetze 2127

3007 Spinoza Gott und Natur 2126

prüfenMatrNr VorlNr PersNr Note28106 5001 2126 1

25403 5041 2125 2

27550 4630 2137 2

Anfragen über mehrere Relationen

Welcher Professor liest "Mäeutik"?

select Name, Titelfrom Professoren, Vorlesungenwhere PersNr = gelesenVon and Titel = `Mäeutik‘ ;

n))Vorlesungeen(Professor ( Mäeutik''TitelgelesenVonPersNr TitelName, ×∏ =∧=σ

Anfragen über mehrere Relationen

RaumRangNamePersNr226232

7

C4C4

C4

SokratesRussel

Kant

21252126

2137

Professorengelesen VonSWSTitelVorlNr

21374Grundzüge5001

21374Die 3 Kritiken4630

21252Mäeutik5049

21254Ethik5041

Vorlesungen

Verknüpfung

4630

50415001

5049

50415001

VorlNr

Die 3 Kritiken

EthikGrundzüge

Mäeutik

EthikGrundzüge

Titel

4

44

2

44

SWS

2137

21252137

2125

21252137

gelesen Von

7

232232

226

226226

Raum

C4Kant2137

RangNamePersNrC4Sokrates2125

C4Russel2126C4Russel2126

C4Sokrates2125

C4Sokrates1225

PersNr

Name Rang Raum VorlNr Titel SWS gelesen Von

2125 Sokrates C4 226 5049 Mäeutik 2 2125

Name TitelSokrate

sMäeutik

Auswahl

Projektion

Anfragen über mehrere RelationenWelche Studenten hören welche Vorlesungen?

select Name, Titelfrom Studenten, hören, Vorlesungenwhere Studenten.MatrNr = hören.MatrNr and

hören.VorlNr = Vorlesungen.VorlNr;Alternativ:select s.Name, v.Titelfrom Studenten s, hören h, Vorlesungen vwhere s. MatrNr = h. MatrNr and

h.VorlNr = v.VorlNr

Veränderung am Datenbestand

Einfügen von Tupelninsert into hören

select MatrNr, VorlNrfrom Studenten, Vorlesungenwhere Titel= `Logik‘ ;

insert into Studenten (MatrNr, Name)values (28121, `Archimedes‘);

StudentenMatrNr Name Semester

29120 Theophrastos

2

29555 Feuerbach 228121 Archimedes -

Null-Wert

Veränderungen am Datenbestand

Löschen von Tupelndelete Studentenwhere Semester > 13;

Verändern von Tupelnupdate Studenten

set Semester= Semester + 1;

Nebenläufigkeit und Transaktionen

Der erste Teil dieser Vorlesung (13 Präsentationen) baut auf der Vorlesung "P3" von Bernd Neumann an der Universität Hamburg auf.

Für eine Vertiefung desThemas Transaktionen und Sperren (Locks) siehe Kapitel 12 aus:

Beispiel Kontoführung

Prozeß 1: Umbuchung eines Betrages von Konto A nach Konto BProzeß 2: Zinsgutschrift für Konto A

Umbuchungread (A, a1)a1 := a1 - 300write (A, a1)read (B, b1)b1 := b1 + 300write (B, b1)

Zinsgutschriftread (A, a2)a2 := a2 * 1.03write (A, a2)

Möglicher verzahnter Ablauf:

Umbuchung Zinsgutschriftread (A, a1)a1 := a1 - 300

read (A, a2)a2 := a2 * 1.03write (A, a2)

write (A, a1)read (B, b1)b1 := b1 + 300write (B, b1)

Wo ist die Zinsgutschrift geblieben??

Beispiel Besucherzählung

Drehkreuz1:loop {read (Counter, c1)if (c1 ≥ MaxN) lockif (c1 < MaxN) openif enter incr(c1)if leave decr(c1)write (Counter, c1)}

Drehkreuz2:loop {read (Counter, c2)if (c2 ≥ MaxN) lockif (c2 < MaxN) openif enter incr(c2)if leave decr(c2)write (Counter, c2)}

Verzahnte Ausführung der zwei Prozesse Drehkreuz1 und Drehkreuz2 mit Zugriff auf gemeinsamen Counter kann inkorrekte Besucherzahl ergeben!

=> Überfüllung, Panik, Katastrophen durch Studium der Nebenläufigkeit vermeiden

Mehrbenutzersynchronisation

Die nebenläufige Ausführung mehrerer Prozesse auf einem Rechner kann grundsätzlich zu einer besseren Ausnutzung des Prozessors führen, weil Wartezeiten eines Prozesses (z.B. auf ein I/O-Gerät) durch Aktivitäten eines anderen Prozesses ausgefüllt werden können.

Zeitunverzahnte Ausführung

verzahnte Ausführung

Prozesse synchronisieren = partielle zeitliche Ordnung herstellen

Mehrbenutzerbetrieb von Datenbanksystemen

Um Probleme durch unerwünschte Verzahnung nebenläufiger Zugriffe (s. Beispiel Kontoführung) zu vermeiden, werden atomare Aktionen zu größeren Einheiten geklammert: Transaktionen.Eine Transaktion ist eine Folge von Aktionen (Anweisungen), die ununterbrechbar ausgeführt werden soll.

Da Fehler während einer Transaktion auftreten können, muß eine Transaktionsverwaltung dafür sorgen, daß unvollständige Transaktionen ggf. zurückgenommen werden können.Befehle für Transaktionsverwaltung:• begin of transaction (BOT) Beginn der Anweisungsfolge einer Transaktion • commit Einleitung des Endes einer Transaktion,

Änderungen der Datenbasis werden festgeschrieben• abort Abbruch der Transaktion, Datenbasis wird in den

Zustand vor der Transaktion zurückversetzt

Eigenschaften von Transaktionen

ACID-Paradigma steht für 4 Eigenschaften:

Atomicity (Atomarität)Eine Transaktion wird als unteilbare Einheit behandelt ("alles-oder-nichts").

Consistency (Konsistenz)Eine Transaktion hinterläßt nach (erfolgreicher oder erfolgloser) Beendigung eine konsistente Datenbasis.

IsolationNebenläufig ausgeführte Transaktionen beeinflussen sich nicht gegenseitig.

Durability (Dauerhaftigkeit)Eine erfolgreich abgeschlossene Transaktion hat dauerhafte Wirkung auf die Datenbank, auch bei Hardware- und Software-Fehlern.

Mehrbenutzerbetrieb in DBsystemenSynchronisation mehrerer nebenläufiger Transaktionen:• Bewahrung der indendierten Semantik einzelner Transaktionen• Protokolle zur Sicherung der Serialisierbarkeit • Sicherung von Rücksetzmöglichkeiten im Falle von Abbrüchen• Vermeidung von Schneeballeffekten beim Rücksetzen• Behandlung von Verklemmungen

Synchronisation bei Mehrbenutzerbetrieb

Synchronisationsproblem = verzahnte sequentielle Ausführung nebenläufiger Transaktionen, so daß deren Wirkung der intendierten unverzahnten ("seriellen") Hintereinanderausführung der Transaktionen entspricht.

Konfliktursache im DB-Kontext ist read und write von zwei Prozessen i und k auf dasselbe Datum A: readi(A) readk(A) Reihenfolge irrelevant, kein Konflikt

readi(A) writek(A) Reihenfolge muß spezifiziert werden, Konflikt

writei(A) readk(A) analog

writei(A) writek(A) Reihenfolge muß spezifiziert werden, Konflikt

Serialisierbarkeitsgraph:Knoten = atomare Operationen (read, write)Kanten = Ordnungsbeziehung (Operation i vor Operation k)

Serialisierbarkeitstheorem:Eine partiell geordnete Menge nebenläufiger Operationen ist genau dann serialisierbar, wenn der Serialisierungsgraph zyklenfrei ist.

Beispiel für nicht serialisierbare Historie

T1 T2

BOTread(A)write(A)

BOTread(A)write(A)read(B)write(B)commit

read(B)write(B)commit

Der Effekt dieser Verzahnung entspricht keiner der 2 möglichen Serialisierungen T1 vor T2 oder T2 vor T1: Die Historie ist nicht serialisierbar

T1 T2

BOTread(A)write(A)read(B)write(B)commit

BOTread(A)write(A)read(B)write(B)commit

T1 T2

BOTread(A)write(A)read(B)write(B)commit

BOTread(A)write(A)read(B)write(B)commit

verzahnte Historie Serialisierung 1 Serialisierung 2

Sperrsynchronisation

Viele Datenbank-Scheduler verwenden Sperranweisungen zur Erzeugung konfliktfreier Abläufe:

• Sperrmodus S (shared, read lock, Lesesperre)Wenn Transaktion Ti eine S-Sperre für ein Datum A besitzt, kann Ti read(A) ausführen. Mehrere Transaktionen können gleichzeitig eine S-Sperre für dasselbe Objekt A besitzen.

• Sperrmodus X (exclusive, write lock, Schreibsperre)Nur eine einzige Transaktion , die eine X-Sperre für A besitzt, darf write(A) ausführen.

Verträglichkeit der Sperren untereinander: (NL = no lock, keine Sperrung)

NL S X

S ok ok -

X ok - -

Zwei-Phasen-Sperrprotokoll(Englisch: two-phase locking, 2PL)Protokoll gewährleistet die Serialisierbarkeit von Transaktionen.Für jede individuelle Transaktion muß gelten:

Verschärfung zum "Strengen 2PL-Protokoll" zur Vermeidung von Schneeballeffekten beim Zurücksetzen:Keine Schrumpfungsphase, alle Sperren werden bei EOT freigegeben.

1. Jedes von einer Transaktion betroffene Objekt muß vorher entsprechend gesperrt werden.

2. Eine Transaktion fordert eine Sperre, die sie besitzt, nicht erneut an.

3. Eine Transaktion muß solange warten, bis es eine erforderliche Sperre entsprechend der Verträglichkeitstabelle erhalten kann.

4. Jede Transaktion durchläuft 2 Phasen:

- in Wachstumsphase werden Sperren angefordert, aber nicht freigegeben- in Schrumpfungsphase werden Sperren freigegeben, aber nicht angefordert

5. Bei EOT (Transaktionsende) muß eine Transaktion alle ihre Sperren zurückgeben.

Beispiel für 2PL-Verzahnung

T1 T2

BOTlockX(A)read(A)write(A)

BOTlockS(A) T2 muß warten

lockX(B)read(B)unlockX(A) T2 wecken

read(A)lockS(B) T2 muß warten

write(B)unlock(B) T2 wecken

read(B)commit

unlockS(A)unlockS(B)commit

T1: Modifikation von A und B(z.B. Umbuchung)

T2: Lesen von A und B(z.B. Addieren der Salden)

Verklemmungen (Deadlocks)

Sperrbasierte Synchronisationsmethoden können (unvermeidbar) zu Verklemmungen führen:Gegenseitiges Warten auf Freigabe von Sperren

T1 T2

BOTlockX(A)

BOTlockS(B)read(B)

read(A)write(A)lockX(B) T1 muß auf T2 warten

lockS(A) T2 muß auf T1 warten=> Deadlock

T1: Modifikation von A und B(z.B. Umbuchung)

T2: Lesen von B und A(z.B. Addieren der Salden)

Transaktionen leicht modifiziert:

Strategien zur Erkennung und Vermeidung von Verklemmungen

1. Wartegraph hat Zyklen

T1 T2

T3

w = wartet aufw w

w T4w Nach Erkennen eines Zyklus muß

Verklemmung durch Zurücksetzen einer geeigneten Transaktion beseitigt werden.

2. Preclaiming - Vorabforderung aller SperrenBeginn einer Transaktion erst, nachdem die für diese Transaktion insgesamt erforderlichen Sperren erfolgt sind.Problem: Vorab die erforderlichen Sperren erkennen

3. ZeitstempelTransaktionen werden durch Zeitstempel priorisiert. Zurücksetzen statt Warten, wenn T1 Sperre fordert, T2 aber Sperre erst freigeben muß:

• Strategie Wound-wait: Abbruch von T2, falls T2 jünger als T1, sonst warten

• Strategie Wait-die: Abbruch von T1, wenn T1 jünger als T2, sonst warten

Zugriff auf Daten in Progr.sprachen: Embedded SQL#include <stdio.h>/*Kommunikationsvariablen deklarieren */

exec sql begin declare section;varchar user_passwd[30];int exMatrNr;

exec sql end declare section;exec sql include SQLCA;main() {

printf("Name/Password:");scanf("%", user_passwd.arr);

user_passwd.len=strlen(user_passwd.arr);exec sql wheneversqlerror goto error;exec sql connect :user_passwd;while (1) {

printf("Matrikelnummer (0 zum beenden):");scanf("%d", &ecMatrNr);if (!exMatrNr) break;exec sql delete from Studenten

where MatrNr= :exMatrNr;}exec sql commit work release;exit(0);

error:exec sql whenever sqlerror continue;exec sql rollback work release;printf(“Fehler aufgetreten!\n");exit(-1);}

Anfragen in Anwendungsprogrammen

genau ein Tupel im Ergebnis

exec sql select avg (Semester)into :avgsemfrom Studenten;

Anfragen in Anwendungsprogrammen• mehrere Tupel im Ergebnis

SatzorientierteProgrammiersprache

mengenorientiertesDBMS

1. Anfrage

3. Tupel sequentiell verarbeiten

4. Cursor/Iterator schließen

2. Anfrage auswerten, Ergebnistupel im Cursor/Iterator/ResultSet bereitstellen

Cursor-Schnittstelle in SQL1. exec sql declare c4profs cursor for

select Name, Raum from Professoren

where Rang=‘C4‘;

2. exec sql open c4profs;

3. exec sql fetch c4profs into :pname, :praum;

4. exec sql close c4profs;

Impedance MismatchDatenmodellierungsform in

Programmiersprachen paßt nicht zu Form in Datenbanken

Programmiersprachen: Record/Tupelorientiert Mit hoher Frequenz einfache

Operationen durchführenDatenbanksysteme: Mengenorientiert

Mit niedriger Frequenz komplexe Operationendurchführen

Probleme relationaler Datenbanktechnologie

Zwar methodisch saubere aber schwierig zu lernende manuelle Umsetzung des Entwurfsmodells (ERM) in das Implementierungsmodell

Impedance MismatchJoins bei Navigierendem Zugriff sehr

aufwendigSprache für Integritätsbedingungen meist

schwach (hier nicht vertieft)

Zusammenfassung, Kernpunkte

Anfragesprachen: SQLMehrbenutzerbetrieb und SperrenTransaktionenAnbindung an ProgrammiersprachenProbleme der relationalen

Datenbanktechnologie

Was kommt beim nächsten Mal?

Objektorientierte Modellierung