Präsentation herunterladen
Die Präsentation wird geladen. Bitte warten
Veröffentlicht von:Marcus Acker Geändert vor über 9 Jahren
1
Objektorientierte Datenbanken zBeim vorigen Mal: yArchitektur von DB-Systemen yGrundlagen der Entity-Relationship-Modellierung yProbleme beim Übergang in relationale Modellierung zHeute: yAnfragesprachen: SQL (kurz) yMehrbenutzerbetrieb und Sperren yTransaktionen yAnbindung an Programmiersprachen yProbleme der relationalen Datenbanktechnologie Ralf Möller, FH-Wedel
2
Übung zZiel: yVertiefung des Vorlesungsstoffes... y... durch Lösen von Aufgaben y... durch Beantwortung von Fragen zDurchführung: Christine Apfel, Katrin Fitz zTermin: Mi, 8.00 Uhr zOrt: RZ2 zBeginn: 16.4.03
3
Literatur, Details und Zusatzinformationen Präsentationen: http://www.fh-wedel.de/~mo/lectures/oodb-sose-03.html Präsentationen: http://www.fh-wedel.de/~mo/lectures/oodb-sose-03.html Literatur:
4
Weitere Literatur und Danksagung zA. Kemper, A. Eickler, Datenbanksysteme: Eine Einführung zDiese Vorlesung basiert auf Präsentations- material zu diesem Buch
5
Vom Entwurfs- zum Implementierungsmodell Professoren PersNrNameRangRaum 2125SokratesC4226 2126RusselC4232 2127KopernikusC3310 2133PopperC352 2134AugustinusC3309 2136CurieC436 2137KantC47 Vorlesungen VorlNrTitelSWSGelesen Von 5001Grundzüge42137 5041Ethik42125 5043Erkenntnistheorie32126 5049Mäeutik22125 4052Logik42125 5052Wissenschaftstheorie32126 5216Bioethik22126 5259Der Wiener Kreis22133 5022Glaube und Wissen22134 4630Die 3 Kritiken42137 Professoren Vorlesungen lesen 1 N
6
Vorsicht: So geht es NICHT Professoren PersNrNameRangRaumliest 2125SokratesC42265041 2125SokratesC42265049 2125SokratesC42264052... 2134AugustinusC33095022 2136CurieC436?? Vorlesungen VorlNrTitelSWS 5001Grundzüge4 5041Ethik4 5043Erkenntnistheorie3 5049Mäeutik2 4052Logik4 5052Wissenschaftstheorie3 5216Bioethik2 5259Der Wiener Kreis2 5022Glaube und Wissen2 4630Die 3 Kritiken4 Professoren Vorlesungen lesen 1 N
7
Anomalien zUpdate-Anomalie: Was passiert wenn Sokrates umzieht zLösch-Anomalie: Was passiert wenn „Glaube und Wissen“ wegfällt zEinfügeanomalie: Curie ist neu und liest noch keine Vorlesungen Professoren PersNrNameRangRaumliest 2125SokratesC42265041 2125SokratesC42265049 2125SokratesC42264052... 2134AugustinusC33095022 2136CurieC436?? Vorlesungen VorlNrTitelSWS 5001Grundzüge4 5041Ethik4 5043Erkenntnistheorie3 5049Mäeutik2 4052Logik4 5052Wissenschaftstheorie3 5216Bioethik2 5259Der Wiener Kreis2 5022Glaube und Wissen2 4630Die 3 Kritiken4
8
Relationale Modellierung der Generalisierung Fachgebiet Assistenten Professoren RaumRang is_a Angestellte PersNrName Angestellte: {[PersNr, Name]} Professoren: {[PersNr, Rang, Raum]} Assistenten: {[PersNr, Fachgebiet]}
9
Relationale Modellierung schwacher Entitytypen Studenten ablegen Prüfungen 1 N Note PrüfTeil MatrNr Vorlesungen umfassen VorlNr abhalten Professoren PersNr NN MM 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]}
10
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
11
zstandardisierte -Datendefinitions (DDL)- -Datenmanipulations (DML)- -Anfrage (Query)-Sprache zderzeit aktueller Standard ist SQL 99 yobjektrelationale Erweiterung SQL
12
Studenten Assistenten MatrNr PersNr Semester Name Fachgebiet Note hören prüfen arbeitenFür Professoren Vorlesungen lesen voraussetzen SWS VorlNr Titel Raum Rang PersNr Nach- folger Vorgänger Name Uni-Schema 1 N 1 1 N N N M M MN
13
Professoren PersNrNameRangRaum 2125SokratesC4226 2126RusselC4232 2127KopernikusC3310 2133PopperC352 2134AugustinusC3309 2136CurieC436 2137KantC47 Studenten MatrNrNameSemester 24002Xenokrates18 25403Jonas12 26120Fichte10 26830Aristoxenos8 27550Schopenhauer6 28106Carnap3 29120Theophrastos2 29555Feuerbach2 Vorlesungen VorlNrTitelSWSgelesenVo n 5001Grundzüge42137 5041Ethik42125 5043Erkenntnistheorie32126 5049Mäeutik22125 4052Logik42125 5052Wissenschaftstheorie32126 5216Bioethik22126 5259Der Wiener Kreis22133 5022Glaube und Wissen22134 4630Die 3 Kritiken42137 voraussetzen VorgängerNachfolger 50015041 50015043 50015049 50415216 50435052 50415052 5259 hören MatrNrVorlNr 261205001 275505001 275504052 281065041 281065052 281065216 281065259 291205001 291205041 291205049 295555022 254035022 Assistenten PerslNrNameFachgebietBoss 3002PlatonIdeenlehre2125 3003AristotelesSyllogistik2125 3004WittgensteinSprachtheorie2126 3005RhetikusPlanetenbewegung2127 3006NewtonKeplersche Gesetze2127 3007SpinozaGott und Natur2126 prüfen MatrNrVorlNrPersNrNote 28106500121261 25403504121252 27550463021372
14
(Einfache) Datendefinition in SQL Datentypen zcharacter (n), char (n) zcharacter varying (n), varchar (n) znumeric (p,s), integer zblob oder raw für sehr große binäre Daten zclob für sehr große String-Attribute zdate für Datumsangaben Anlegen von Tabelle zcreate table Professoren (PersNrinteger not null, Namevarchar (30) not null Rangcharacter (2) );
15
Einfache SQL-Anfrage PersNrName 2125Sokrates 2126Russel 2136Curie 2137Kant selectPersNr, Name fromProfessoren whereRang= ´C4´;
16
Einfache SQL-Anfragen Sortierung select PersNr, Name, Rang fromProfessoren order by Rang desc, Name asc; PersNrNameRang 2136CurieC4 2137KantC4 2126RusselC4 2125SokratesC4 2134AugustinusC3 2127KopernikusC3 2133PopperC3
17
select distinct Rang from Professoren Rang C3 C4 Duplikateliminierung
18
Professoren PersNrNameRangRaum 2125SokratesC4226 2126RusselC4232 2127KopernikusC3310 2133PopperC352 2134AugustinusC3309 2136CurieC436 2137KantC47 Studenten MatrNrNameSemester 24002Xenokrates18 25403Jonas12 26120Fichte10 26830Aristoxenos8 27550Schopenhauer6 28106Carnap3 29120Theophrastos2 29555Feuerbach2 Vorlesungen VorlNrTitelSWSgelesenVo n 5001Grundzüge42137 5041Ethik42125 5043Erkenntnistheorie32126 5049Mäeutik22125 4052Logik42125 5052Wissenschaftstheorie32126 5216Bioethik22126 5259Der Wiener Kreis22133 5022Glaube und Wissen22134 4630Die 3 Kritiken42137 voraussetzen VorgängerNachfolger 50015041 50015043 50015049 50415216 50435052 50415052 5259 hören MatrNrVorlNr 261205001 275505001 275504052 281065041 281065052 281065216 281065259 291205001 291205041 291205049 295555022 254035022 Assistenten PerslNrNameFachgebietBoss 3002PlatonIdeenlehre2125 3003AristotelesSyllogistik2125 3004WittgensteinSprachtheorie2126 3005RhetikusPlanetenbewegung2127 3006NewtonKeplersche Gesetze2127 3007SpinozaGott und Natur2126 prüfen MatrNrVorlNrPersNrNote 28106500121261 25403504121252 27550463021372
19
Anfragen über mehrere Relationen Welcher Professor liest "Mäeutik"? select Name, Titel from Professoren, Vorlesungen where PersNr = gelesenVon and Titel = `Mäeutik‘ ;
20
Anfragen über mehrere Relationen RaumRangNamePersNr 226 232 7 C4 Sokrates Russel Kant 2125 2126 2137 Professoren gelesen VonSWSTitelVorlNr 21374Grundzüge5001 21374Die 3 Kritiken4630 21252Mäeutik5049 21254Ethik5041 Vorlesungen Verknüpfung
21
4630 5041 5001 5049 5041 5001 VorlNr Die 3 Kritiken Ethik Grundzüge Mäeutik Ethik Grundzüge Titel 4 4 4 2 4 4 SWS 2137 2125 2137 2125 2137 gelesen Von 7 232 226 Raum C4Kant2137 RangNamePersNr C4Sokrates2125 C4Russel2126 C4Russel2126 C4Sokrates2125 C4Sokrates1225 Pers Nr NameRangRaumVorlNrTitelSWSgelesen Von 2125SokratesC42265049Mäeutik22125 NameTitel SokratesMäeutik Auswahl Projektion
22
Anfragen über mehrere Relationen Welche Studenten hören welche Vorlesungen? select Name, Titel from Studenten, hören, Vorlesungen where Studenten.MatrNr = hören.MatrNr and hören.VorlNr = Vorlesungen.VorlNr; Alternativ: select s.Name, v.Titel from Studenten s, hören h, Vorlesungen v where s. MatrNr = h. MatrNr and h.VorlNr = v.VorlNr
23
Veränderung am Datenbestand Einfügen von Tupeln insert into hören select MatrNr, VorlNr from Studenten, Vorlesungen where Titel= `Logik‘ ; insert into Studenten (MatrNr, Name) values (28121, `Archimedes‘);
24
Studenten MatrNrNameSemester 29120Theophrastos2 29555Feuerbach2 28121Archimedes- Null-Wert
25
Veränderungen am Datenbestand Löschen von Tupeln delete Studenten where Semester > 13; Verändern von Tupeln update Studenten set Semester= Semester + 1;
26
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 des Themas Transaktionen und Sperren (Locks) siehe Kapitel 12 aus:
27
Beispiel Kontoführung Prozeß 1: Umbuchung eines Betrages von Konto A nach Konto B Prozeß 2: Zinsgutschrift für Konto A Umbuchung read (A, a1) a1 := a1 - 300 write (A, a1) read (B, b1) b1 := b1 + 300 write (B, b1) Zinsgutschrift read (A, a2) a2 := a2 * 1.03 write (A, a2) Möglicher verzahnter Ablauf: Umbuchung Zinsgutschrift read (A, a1) a1 := a1 - 300 read (A, a2) a2 := a2 * 1.03 write (A, a2) write (A, a1) read (B, b1) b1 := b1 + 300 write (B, b1) Wo ist die Zinsgutschrift geblieben??
28
Beispiel Besucherzählung Drehkreuz1: loop { read (Counter, c1) if (c1 ≥ MaxN) lock if (c1 < MaxN) open if enter incr(c1) if leave decr(c1) write (Counter, c1) } Drehkreuz2: loop { read (Counter, c2) if (c2 ≥ MaxN) lock if (c2 < MaxN) open if 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
29
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. Zeit unverzahnte Ausführung verzahnte Ausführung Prozesse synchronisieren = partielle zeitliche Ordnung herstellen
30
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 commitEinleitung des Endes einer Transaktion, Änderungen der Datenbasis werden festgeschrieben abortAbbruch der Transaktion, Datenbasis wird in den Zustand vor der Transaktion zurückversetzt
31
Eigenschaften von Transaktionen ACID-Paradigma steht für 4 Eigenschaften: A tomicity (Atomarität) Eine Transaktion wird als unteilbare Einheit behandelt ("alles-oder-nichts"). C onsistency (Konsistenz) Eine Transaktion hinterläßt nach (erfolgreicher oder erfolgloser) Beendigung eine konsistente Datenbasis. I solation Nebenläufig ausgeführte Transaktionen beeinflussen sich nicht gegenseitig. D urability (Dauerhaftigkeit) Eine erfolgreich abgeschlossene Transaktion hat dauerhafte Wirkung auf die Datenbank, auch bei Hardware- und Software-Fehlern.
32
Mehrbenutzerbetrieb in DBsystemen Synchronisation 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
33
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: read i (A)read k (A)Reihenfolge irrelevant, kein Konflikt read i (A)write k (A)Reihenfolge muß spezifiziert werden, Konflikt write i (A)read k (A)analog write i (A) write k (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.
34
Beispiel für nicht serialisierbare Historie T1T2 BOT read(A) write(A) BOT read(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 T1T2 BOT read(A) write(A) read(B) write(B) commit BOT read(A) write(A) read(B) write(B) commit T1T2 BOT read(A) write(A) read(B) write(B) commit BOT read(A) write(A) read(B) write(B) commit verzahnte HistorieSerialisierung 1Serialisierung 2
35
Sperrsynchronisation Viele Datenbank-Scheduler verwenden Sperranweisungen zur Erzeugung konfliktfreier Abläufe: Sperrmodus S (shared, read lock, Lesesperre) Wenn Transaktion T i eine S-Sperre für ein Datum A besitzt, kann T i 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) NLSX Sokok- Xok--
36
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.
37
Beispiel für 2PL-Verzahnung T1T2 BOT lockX(A) read(A) write(A) BOT lockS(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)
38
Verklemmungen (Deadlocks) Sperrbasierte Synchronisationsmethoden können (unvermeidbar) zu Verklemmungen führen: Gegenseitiges Warten auf Freigabe von Sperren T1T2 BOT lockX(A) BOT lockS(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:
39
Strategien zur Erkennung und Vermeidung von Verklemmungen 1. Wartegraph hat Zyklen T1T1 T2T2 T3T3 w = wartet auf w w w T4T4 w Nach Erkennen eines Zyklus muß Verklemmung durch Zurücksetzen einer geeigneten Transaktion beseitigt werden. 2. Preclaiming - Vorabforderung aller Sperren Beginn einer Transaktion erst, nachdem die für diese Transaktion insgesamt erforderlichen Sperren erfolgt sind. Problem: Vorab die erforderlichen Sperren erkennen 3. Zeitstempel Transaktionen werden durch Zeitstempel priorisiert. Zurücksetzen statt Warten, wenn T 1 Sperre fordert, T 2 aber Sperre erst freigeben muß: Strategie Wound-wait: Abbruch von T 2, falls T 2 jünger als T 1, sonst warten Strategie Wait-die: Abbruch von T 1, wenn T 1 jünger als T 2, sonst warten
40
Zugriff auf Daten in Progr.sprachen: Embedded SQL #include /*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);
41
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);
42
error: exec sql whenever sqlerror continue; exec sql rollback work release; printf(“Fehler aufgetreten!\n"); exit(-1); }
43
Anfragen in Anwendungsprogrammen zgenau ein Tupel im Ergebnis exec sql select avg (Semester) into :avgsem from Studenten;
44
Anfragen in Anwendungsprogrammen mehrere Tupel im Ergebnis Satzorientierte Programmiersprache mengenorientiertes DBMS 1. Anfrage 3. Tupel sequentiell verarbeiten 4. Cursor/Iterator schließen 2. Anfrage auswerten, Ergebnistupel im Cursor/Iterator/ ResultSet bereitstellen
45
Cursor-Schnittstelle in SQL 1.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;
46
Impedance Mismatch zDatenmodellierungsform in Programmiersprachen paßt nicht zu Form in Datenbanken zProgrammiersprachen: yRecord/Tupelorientiert yMit hoher Frequenz einfache Operationen durchführen zDatenbanksysteme: Mengenorientiert yMit niedriger Frequenz komplexe Operationen durchführen
47
Probleme relationaler Datenbanktechnologie zZwar methodisch saubere aber schwierig zu lernende manuelle Umsetzung des Entwurfsmodells (ERM) in das Implementierungsmodell zImpedance Mismatch zJoins bei Navigierendem Zugriff sehr aufwendig zSprache für Integritätsbedingungen meist schwach (hier nicht vertieft)
48
Zusammenfassung, Kernpunkte zAnfragesprachen: SQL zMehrbenutzerbetrieb und Sperren zTransaktionen zAnbindung an Programmiersprachen zProbleme der relationalen Datenbanktechnologie
49
Was kommt beim nächsten Mal? zObjektorientierte Modellierung
Ähnliche Präsentationen
© 2025 SlidePlayer.org Inc.
All rights reserved.