Datenbanksysteme - Homepage von Gunter Ohrner
Werbung
Zusammenfassung des Buches
Prof. Alfons Kempler
Dr. André Eickler
Datenbanksysteme
Eine Einführung
erstellt von
Gunter Ohrner
Klaus Ridder
letzte Überarbeitung
– 14. Mai 2004 –
Inhaltsverzeichnis
Über diese Zusammenfassung.........................................................................................................5
1 Einleitung und Übersicht..............................................................................................................5
1.1 Motivation für den Einsatz eines DBMS...............................................................................5
1.2 Datenabstraktion..................................................................................................................5
1.3 Datenunabhängigkeit............................................................................................................5
1.4 Datenmodelle........................................................................................................................5
1.5 Datenbankschema und –Ausprägung....................................................................................5
1.6 Datenmodelierungmöglichkeiten..........................................................................................5
1.7 Architekturübersicht.............................................................................................................6
2 Datenbankentwurf........................................................................................................................6
2.1 Abstraktionsebenen des Datenbankentwurfs.......................................................................6
2.2 Top-Down-Entwurf................................................................................................................6
2.5 Grundlagen des Entity-Relationship-Modells........................................................................6
2.7 Funktionalitäten....................................................................................................................7
Min- / Max-Notation....................................................................................................................7
2.8 Existenzabhängige Entitymodelle.........................................................................................7
2.9 Generalisierung: Klassenhierarchie: „ist ein“.......................................................................7
2.10 Aggregation: Objekthierarchie: „ist Teil von“.....................................................................7
2.12 Sichten-Integration.............................................................................................................7
2.13 Modellierung mit UML........................................................................................................7
3 Das relationale Modell..................................................................................................................8
3.2 Konzeptuelles Schema – relationales Schema......................................................................8
Darstellung von Beziehungen.................................................................................................8
Relationale Modellierung der Generalisierung......................................................................8
3.4 Relationale Algebra...............................................................................................................8
3.4.7 Definitionen der relationalen Algebra...........................................................................9
3.5 Relationenkalkül...................................................................................................................9
3.5.1 relationaler Tupelkalkül................................................................................................9
3.5.4 sichere Ausdrücke.........................................................................................................9
3.5.5 relationaler Domänenkalkül..........................................................................................9
3.6 Ausdruckskraft von Anfragesprachen............................................................................10
4 Relationale Anfragesprachen.....................................................................................................10
4.8 Aggregatfunktionen............................................................................................................10
4.9 geschachtelte Anfragen......................................................................................................10
4.10 Quantifizierte Anfragen....................................................................................................11
4.11 Nullwerte..........................................................................................................................11
4.14 Rekursion..........................................................................................................................11
4.15 Veränderungen am Datenbestand.....................................................................................11
4.16 Sichten..............................................................................................................................11
4.17 Sichten zur Modellierung von Generalisierung................................................................11
4.18 Characterisierung update-fähiger Sichten.......................................................................11
4.19 – 4.22 Einbettung von SQL...............................................................................................12
4.23 Query by Example.............................................................................................................12
5 Datenintegrität...........................................................................................................................12
5.1 Referentielle Integrität.......................................................................................................12
5.2 Gewährleistung der referentiellen Integrität.....................................................................12
5.3 Referentielle Integrität in SQL...........................................................................................13
5.4 Statische Integritätsbedingungen.......................................................................................13
5.6 Komplexe Integritätsbedingungen......................................................................................14
5.7 Trigger................................................................................................................................14
6 Relationale Entwurfstheorie.......................................................................................................14
6.1 Funktionale Abhängigkeiten...............................................................................................14
6.1.1 Konventionen zur Notation..........................................................................................14
6.1.2 Einhaltung der FD.......................................................................................................14
6.2 Schlüssel.............................................................................................................................14
6.3 Bestimmung funktionaler Abhängigkeiten..........................................................................15
6.3.1 Kanonische Überdeckung............................................................................................16
Seite 2
Algo zur Bestimmung der kanonischen Überdeckung einer FD-Menge F:......................16
6.4 Schlechte Relationenschemata...........................................................................................17
6.5 Zerlegung / Dekomposition von Relationen........................................................................17
6.5.1 Verlustlosigkeit............................................................................................................17
6.5.2 Kriterien für die Verlustlosigkeit einer Zerlegung......................................................17
6.5.3 Abhängigkeitsbewahrung............................................................................................17
6.6 Erste Normalform...............................................................................................................18
6.7 Zweite Normalform (2NF)..................................................................................................18
6.8 Dritte Normalform..............................................................................................................18
6.9 Boyce-Codd Normalform.....................................................................................................19
6.10 Mehrwertige Abhängigkeiten (MVD)................................................................................19
6.11 Vierte Normalform............................................................................................................20
6.12 Zusammenfassung............................................................................................................21
7 Physische Datenorganisation.....................................................................................................21
7.1 Speichermedien..................................................................................................................21
7.2 Speicherarrays: RAID.........................................................................................................21
7.3 Der Datenbankpuffer..........................................................................................................22
7.4 Abbildung von Relationen auf den Sekundärspeicher........................................................22
7.5 Indexstrukturen..................................................................................................................23
7.6 ISAM...................................................................................................................................23
7.7 B-Bäume..............................................................................................................................23
7.8 B+-Bäume (auch manchmal B*-Bäume genannt)..............................................................24
7.9 Präfix-B+-Bäume.................................................................................................................24
7.10 Hashing.............................................................................................................................24
7.11 Erweiterbares Hashing.....................................................................................................24
7.12 Mehrdimensionale Indexstrukturen..................................................................................25
7.13 Ballung logisch verwandter Datensätzen.........................................................................25
7.14 Unterstützung des Anwendungsverhaltens......................................................................25
7.15 Physische Datenorganisation in SQL................................................................................25
9 Transaktionsverwaltung.............................................................................................................25
9.1 Begriffsbildung....................................................................................................................26
9.2 Anforderungen an die Transaktionsverwaltung..................................................................26
9.3 Operationen auf Transaktions-Ebene.................................................................................26
9.4 Abschluss einer Transaktion...............................................................................................26
9.5 Eigenschaften von Transaktionen.......................................................................................26
9.6 Transaktionsverwaltung in SQL..........................................................................................26
9.7 Zustandsübergänge einer Transaktion...............................................................................27
13 Objektorientierte Datenbanken................................................................................................27
13.1 Bestandsaufnahme relationaler Datenbanksysteme.........................................................27
13.2 Vorteile der objektorientierten Datenmodellierung..........................................................27
13.3 Der ODMG-Standard.........................................................................................................28
13.4 Eigenschaften von Objekten.............................................................................................28
13.4.1 Objektidentität..........................................................................................................28
13.4.2 Typ eines Objekts......................................................................................................28
13.4.3 Wert eines Objekts....................................................................................................28
13.5 Definition von Objekttypen...............................................................................................28
13.5.1 Attribute....................................................................................................................29
13.5.2 Beziehungen..............................................................................................................29
13.5.3 Typeigenschaften: Extensionen und Schlüssel..............................................................30
13.6 Modellierung des Verhaltens: Operationen......................................................................30
13.7 Vererbung und Subtypisierung.........................................................................................30
13.7.2 Einfache und Mehrfachvererbung.................................................................................30
13.9 Verfeinerung (Spezialisierung) und spätes Binden von Operationen...............................30
13.10 Mehrfachvererbung........................................................................................................31
13.11 Die Abfragesprache OQL................................................................................................31
13.11.1 Einfache Anfragen...................................................................................................31
13.11.2 Geschachtelte Anfragen und Partitionierung..........................................................31
13.11.3 Pfadausdrücke.........................................................................................................31
13.11.4 Erzeugung von Objekten.........................................................................................31
13.11.5 Operationsaufruf.....................................................................................................31
Seite 3
13.12 C++-Einbettung.........................................................................................................31
13.12.1 Objektidentität........................................................................................................32
13.12.2 Objekterzeugung und Ballung.................................................................................32
13.12.3 Einbettung von Afragen...........................................................................................32
14 Erweiterbare und objekt-relationale Datenbanken..................................................................32
14.1 Übersicht über die objekt-relationalen Konzepte.............................................................32
14.2 Large Objects (LOBs)........................................................................................................33
14.3 Distinct Types: Einfache benutzerdefinierte Datentypen.................................................33
14.4 Table Functions.................................................................................................................33
14.4.1 Nutzung einer Table Function in Anfragen...............................................................34
14.4.2 Implementierung einer Table Function.....................................................................34
14.5 Benutzerdefinierte strukturierte Objekte.........................................................................34
14.6 Geschachtelte Objekt-Relationen......................................................................................34
14.7 Vererbung von SQL-Objekttypen......................................................................................35
14.8 Komplexe Attributtypen....................................................................................................35
15 Deduktive Datenbanken...........................................................................................................35
15.1 Terminologie.....................................................................................................................35
15.2 Datalog..............................................................................................................................35
15.3 Eigenschaften von Datalog-Programmen.........................................................................36
15.3.1 Rekursivität...............................................................................................................36
15.3.2 Sicherheit von Datalog-Regeln..................................................................................36
15.4 Auswertung von nicht-rekursiven Datalog-Programmen..................................................37
15.4.1 Auswertung eines Beispielprogramms......................................................................37
15.4.2 Auswertungs-Algorithmus.........................................................................................37
15.7 Top-Down-Auswertung.................................................................................................37
15.8 Negation im Regelrumpf..............................................................................................37
15.8.1 Stratifizierte Programme..........................................................................................37
15.8.2 Auswertung von Regeln mit Negation.......................................................................37
15.9 Ausdruckskraft von Datalog..............................................................................................38
16 Verteilte Datenbanken..............................................................................................................38
16.1 Terminologie und Abgrenzung..........................................................................................38
16.2 Entwurf verteilter Datenbanken.......................................................................................39
16.3 Horizontale und vertikale Fragmentierung......................................................................39
16.3.1 Horizontale Fragmentierung.....................................................................................39
16.3.2 Abgeleitete horizontale Fragmentierung..................................................................40
16.3.3 Vertikale Fragmentierung.........................................................................................40
16.3.4 Kombinierte Fragmentierung....................................................................................40
16.3.5 Allokation für unser Beispiel.....................................................................................40
16.4 Transparenz in verteilten Datenbanken...........................................................................40
16.4.1 Fragmentierungstransparenz....................................................................................40
16.4.2 Allokationstransparenz..............................................................................................41
16.4.3 Lokale Schema-Transparenz.....................................................................................41
16.5 Anfrageübersetzung und -optimierung in VDBMS...........................................................41
16.5.1 Anfragebearbeitung bei horizontaler Fragmentierung.............................................41
16.5.2 Anfragebearbeitung bei vertikaler Fragmentierung.................................................41
16.6 Join-Auswertung in VDBMS..............................................................................................41
16.6.1 Join-Auswertung ohne Filterung................................................................................41
16.6.2 Join-Auswertung mit Filterung..................................................................................41
16.7 Transaktionskontrolle in VDBMS......................................................................................42
16.8 Mehrbenbutzersynchronisation in VDBMS.......................................................................43
16.10 Synchronisation bei replizierten Daten..........................................................................43
Seite 4
Über diese Zusammenfassung
Diese Zusammenfassung wurde während der Vorbereitung auf die Praktische
Informatik-Prüfung „Einführung in Datenbanken“ bei Herr Prof. Seidl erstellt. Sie
umfasst damit „nur“ den für diese Prüfung relevanten Stoff1, d.h. es handelt sich nicht
um eine vollständige Zusammenfassung des Buches. Nichtsdestotrotz ist der
allergrößte Teil des Buches abgedeckt. Datenbank-Grundkenntnisse und Kenntnisse
der objektorientierten Programmierung sind allerdings hilfreich, da wir dank solider
Vorkenntnisse in diesem Bereichen ;) darauf nicht im Detail eingegangen sind.
1 Einleitung und Übersicht
1.1 Motivation für den Einsatz eines DBMS
Gründe für DBMS:
●
Redundanzen vermeiden
●
Inkonsistenzen vermeiden / Integritätsbedingungen einhalten
●
Kontrolle des Datenzugriffs / Datenzugriff ermöglichen.
●
Mehrbenutzerzugriff
●
Systematische Datensicherung
●
Entwicklugskosten reduzieren durch vorhandenes DBMS
1.2 Datenabstraktion
1. physische Ebene (Speicherung auf Platte)
2. logische Ebene (Datenbankschema)
3. Sichten (Endanwendersicht)
1.3 Datenunabhängigkeit
diese Schichten sind unabhängig und kommunizieren über definierte Schnittstellen.
1.4 Datenmodelle
Infrastruktur um Welt auf Datenbank abzubilden. (Modell bilden „Miniwelt“)
1. Datendefinitionssprache (Data Definition Language, DDL)
2. Datenmanipulationssprache (Data Manipulation Language, DML)
a) Anfragesprache
b) Datenänderungssprache
SQL deckt das alles ab
1.5 Datenbankschema und –Ausprägung
Schema = Tabellenstruktur
Ausprägung = Dateninhalt
1.6 Datenmodelierungmöglichkeiten
Entwurfsmöglichkeiten für die Datenbank:
1 http://www-i9.informatik.rwth-aachen.de/lehre/pruefungen
1 Einleitung und Übersicht
Seite 5
●
Entity-Relationship-Modell
●
semantisches Datenmodell
●
funktionales Datenmodell
●
objektorientierte Entwufsmodelle (UML)
Implementationsmodelle:
●
relationales Modell
●
objektorientiertes Modell
●
deduktives Datenmodell
●
(alt: Netzwerkmodell, hierarchisches Datenmodell)
1.7 Architekturübersicht
Ebenen:
1. Anwender- / Admin-Ebene (Benutzer, Anwendungsprogrammierer, Admins)
2. DBMS (DML- / DDL-Compiler, Compiler, Anfragebearbeitung, …)
3. Hintergrundspeichersystem (Dateiverwaltung, Indizes, …)
2 Datenbankentwurf
2.1 Abstraktionsebenen des Datenbankentwurfs
3 Ebenen:
1. konzeptuelle Ebene:
DB-Modell bauen (UML: Entity Relationship Model)
2. Implementationsebene:
Umsetzung auf konkretes DBMS
3. physische Ebene:
Leistungssteigerung: (z.B. Indexe)
2.2 Top-Down-Entwurf
1. Anforderungsanalyse (Interview alle zukünftigen Anwenderschichten)
Herausfiltern der notwendigen Features
2. konzeptueller Entwurf
3. Implementations-Entwurf
4. physischer Entwurf
2.5 Grundlagen des Entity-Relationship-Modells
Modellierung der Miniwelt (modellierter Ausschnitt der Realität) als miteinander in
Beziehung stehende Dinge, Darstellung in Diagrammform:
●
Entitäten (Gegenstände, Tabellen): Rechtecke
●
Attribute (Spalten): Ovale
●
Schlüsselattribute (Keys): Unterstrichen
Seite 6
2 Datenbankentwurf
●
Beziehungen: Rauten.
Beziehungen können auch Attribute haben, sie verbinden mehrere Gegenstände durch
Linien.
Beschriftungen der Linien: „Rollen“ der Beziehungen.
2.7 Funktionalitäten
1:1, 1:n, n:1, n:m
erweiterbar auf n-stellige Beziehungen.
Funktionalitäten helfen bei Einhaltung der Datenkonsistenz. Im Entity-RelationshipModell werden zur Darstellung die Nummern an die Verbinsungslinien geschrieben.
Min- / Max-Notation
Bei Verknüpfungen zwischen Beziehungen und Entitäten kann man auch min- / maxWerte angeben. [max. 5 Kugeln in 1 Eistüte]
2.8 Existenzabhängige Entitymodelle
Beispiele für schwache Entitätstypen:
●
eine Buchung exisistiert nur, wenn es einen Beleg dazu gibt
●
Student aus der Datenbank gelöscht -> Prüfungsdaten ebenfalls löschen
●
Haus abgerissen -> Räume im inneren existieren ebenfalls nicht mehr
2.9 Generalisierung: Klassenhierarchie: „ist ein“
Man fügt ein sechseckiges Bildchen ein in das Entity-Relationship-Modell.
(Assistent „is a“ Angestellter, Professor „is a“ Angestellter)
2.10 Aggregation: Objekthierarchie: „ist Teil von“
„Teil von“ – Beziehung: Raute (Beispiel: Vorderrad „ist Teil von“ Fahrrad)
2.12 Sichten-Integration
Bei größeren Anwendungen: getrennte Anforderungsanalyse / konzeptueller Entwurf
für verschiedene Benutzergruppen.
Die daraus resultierenden unterschiedlichen Modellen werden zu einem Großen
verschmolzen.
(z.B. „Campus“: Sicht der Studenten, Professoren, Verwaltung, …)
2.13 Modellierung mit UML
Ein Objekt kann Attribute und Operationen haben.
zusätzlich zum Entity-Relationship-Modell: Operationen (Methoden), die aus den Daten
„on the fly“ etwas berechnen.
Assoziationen zwischen Klassen entsprechen den Beziehungstypen des EntityRelationship-Modells; sind jedoch gerichtet.
Multiplizitäten: vgl. Min-/Max-Angabe. (nur 0..400 Studenten dürfen 1 Vorlesung
hören)
Aggregation: Raute an die Verbindungslinie an der Obertabelle.
2 Datenbankentwurf
Seite 7
(FIXME: Nicht ausgefüllte Raute: nachgucken.)
Anforderungsanalyse in UML
Interaktionsdiagramme
Kommunikation zwischen Objekten (Methodenaufrufe)
3 Das relationale Modell
Attribut = Spalte
Domäne = Menge gültiger Werte (Datentyp)
Relation = 1 Tabelle (Teilmenge des kartesischen Produktes)
Tupel = 1 Zeile
Relations-Schema = Struktur der Tabelle (Relation)
Telefonbuch : { [ Name: string, Adresse: string, Telefonnr: integer ] }
Ausprägung = Tabelleninhalt
Dom(A) = Domäne eines Attributes A
Schlüssel = Menge von Attributen, die ein Tupel (Datensatz) in einer Relation (Tabelle)
eindeutig kennzeichnen.
3.2 Konzeptuelles Schema – relationales Schema
Darstellung von Beziehungen
Beziehung: Fremdschlüssel + eigene Attribute.
Man kann Relationen verschmelzen, die den gleichen Schlüssel haben.
Also zunächst: jede Beziehung ist auch eine eigene Tabelle, auch bei 1:n!
Da sich 1:1-Beziehungen komplett zusammenfassen lassen (klar), kann man diese
zusätzlichen Tabellen bei 1:n Beziehungen mit der 1. Tabelle verschmelzen, bei n:m
natürlich nicht.
Nachteil des Zusammenfassens: ggf. viele NULL-Werte.
Relationale Modellierung der Generalisierung
Extra Tabellen mit 1:1-Beziehung für die speziellen Attribute „abgeleiteter“
Entitätstypen
Darstellung schwacher Entitätstypen (vgl. Löschweitergabe): Der Schlüssel der
Obertabelle wird mit in das Tupel aufgenommen.
3.4 Relationale Algebra
eher „prozeduraler Ansatz“
Operatoren:
●
Selektion ( Semester 10 Studenten , Select, in SQL: „WHERE“)
●
Projektion ( Rang Professoren , Project, in SQL: „SELECT x, y ...“)
●
Umbenennen von Relationen ( v1 voraussetzen , Rename, in SQL: „AS“)
●
Umbenennen von Attributen ( Voraussetzung Vorgänger voraussetzen , Rename)
Seite 8
3 Das relationale Modell
●
Vereinigung ( PersNr , Name Assistenten ∪ PersNr ,Name Professoren , in SQL:
„UNION“)
●
Mengendifferenz ( MatrNr Studenten − MatrNr prüfen )
●
Kreuzprodukt / kartesisches Produkt ( R ×S , sch R × S = sch R ∪ sch S )
3.4.7 Definitionen der relationalen Algebra
Basisausdrücke: Relationen der Datenbank und konstante Relationen.
zusammengesetzte Ausdrücke: Ausdrücke, kombiniert auf die oben aufgelisteten Arten
Zusätzliche, nicht notwendige (da durch die bereits bekannten abbildbare) Operatoren
der Relationenalgebra:
●
natürlicher Verbund ( R xx S )
●
Theta-Join ( R xx S ): Join über beliebiges Prädikat, in SQL: „A JOIN B ON “
●
Left Outer Join, Right Outer Join, Full Outer Join
●
Semi-Join von L mit R ( L n R = sch L L xx R ): Left Join, aber nur die Attribute aus
L bleiben übrig, Semi-Join von R mit L analog.
●
Mengendurchschnitt von R und S (erfordert sch R =sch S ) (Dann identisch zum
natürlichen Verbund?)
●
relationale Division (Buch Seite 92: Outer Join nur mit den Werten, die NICHT in der
zweiten Relation vorkommen)
3.5 Relationenkalkül
eher „deklarativer Ansatz“
3.5.1 relationaler Tupelkalkül
Quasi Mengenschreibweise, arbeitet auf und quantifiziert ganze Tupel:
{s ∣ s ∈Studenten ∧∃ h ∈ hören s.MatrNr =h.MatrNr
∧∃ v ∈ Vorlesungen h.VorlNr = v.NorlNr
∧∃ p ∈ Professoren p.PersNr = v.gelesenVon ∧p.Name = Curie }
Auf der linken Seite können Tupelkonstruktoren stehen:
{ [s.a1, t.a3, ...] | ... }
3.5.4 sichere Ausdrücke
{n ∣¬ n ∈Professoren } ist gar nicht gut: Ergebnis ist unendlich groß und umfasst
viele Tupel, die gar nicht in unserer DB sind -> nicht sicher!
Beheben: Alle Anfragen im Tupelkalkül müssen sicher sein, d.h.:
{n ∣n ∈Professoren∧ n.Rang=' C4' } hat die Domäne 'C4' und alle Professoren
(Vorkommende Relationen und Literale) und alle Ergebnisse der Anfrage müssen
Teilmenge der Domäne sein.
3.5.5 relationaler Domänenkalkül
Auch Mengenschreibweise, arbeitet aber auf und quantifiziert einzelne Attribute:
3 Das relationale Modell
Seite 9
{[ m , n ]∣ ∃ s [ m , n ,s ]∈Studenten
∧∃ v , p ,g [ m , v , p, g ]∈prüfen
∧m= m '∧∃ p' ,a ,r , b [ p' , a ,r , b ]∈Professoren
∧p = p'∧a =' Curie ' }
Hier sichere Anfragen analog.
3.6 Ausdruckskraft von Anfragesprachen
Relationale Algebra, Tupelkalkül eingeschränkt auf sichere Ausdrücke und
Domänenkalkül eingeschränkt auf sichere Ausdrücke sind gleichmächtig.
4 Relationale Anfragesprachen
SQL, hervorgegangen aus IBMs SEQUEL (DBMS „System R“), basiert auf
tupelorientiertem Relationenkalkül
●
vordefinierte Datentypen (character(n), char varying(n)/varchar(n),
numeric(p, s), integer, float, blob/raw)
●
DDL-Teil:
●
●
create table Professoren (PersNr integer not null, Name varchar(10) not null, Rang char(2));
●
alter table Professoren add (Raum integer);
DML-Teil:
●
insert into Professoren values (a, b, c);
●
select bla...;
4.8 Aggregatfunktionen
●
select avg(Semester) from Studenten;
●
group by
4.9 geschachtelte Anfragen
●
select * from prüfen where Note = (select avg(Note) from prüfen); (Schwachsinnige Anfrage... :-/ )
●
select PersNr, Name, (select sum(SWS) as Lehrbelastung from Vorlesungen where gelesenVon = PersNr) from Professoren;
●
select ... where exists (select ... from ...); <= „exists“ liefert „wahr“,
gdw. die Unterabfrage min. 1 Tupel zurückliefert)
●
(select Name from Assistenten) union (select Name from Professoren); //
intersect, except/minus
●
... where PersNr not in (select gelesenVon from Vorlesungen) ; <=
Professoren, die keine Vorlesungen lesen
●
... where Semester >= all (select Semester from Studenten); <= findet die
Studenten mit den höchsten Semesterzahlen
Seite 10
4 Relationale Anfragesprachen
4.10 Quantifizierte Anfragen
Keine Allquantifizierung in SQL, aber Existenzquantifizierung: Umwandlung von
Allquantoren in Existenzquantoren, Nach-Innen-Ziehung von Negationen, Übersetzung
in SQL.
Evtl. effizienter: Tupel zählen:
... group by h.MatrNr having count(*) = (select count(*) from Vorlesungen);
4.11 Nullwerte
Null = unbekannter Wert, sorgt für dreiwertige Logik in SQL: true, false, unknown: (1
> Null) == unknown
4.14 Rekursion
In SQL nicht möglich, es fehlt Berechnung transitiver Hüllen. Das Finden aller
„Vorgänger“ einer Vorlesung (Ahnen eines Menschen, übergeordnete Verzeichnisse
einer Datei, ...) erfordert beliebig lange Queries.
Oracle bietet hierzu „connect by“
4.15 Veränderungen am Datenbestand
●
insert into
●
delete from
●
update
Bsp:
delete from voraussetzen
where Vorgänger
in (select Nachfolger from voraussetzen);
4.16 Sichten
„Auswahlabfragen“ in MS Access: „eingefrorene Abfragen“, die sich wie Tabellen
verhalten, u.U. inkl. Updates:
create view prüfenSicht as select MatrNr, VorlNr, PersNr from prüfen;
4.17 Sichten zur Modellierung von Generalisierung
Erstelle einzelne Tabellen für „Basisklasse“ und „abgeleitete Klassen“, wobei sich in
den abgeleiteten Klassen keine identischen Attribute aus der Basisklasse wiederfinden.
Dann erstelle über Sichten den Datenbestand der abgeleitet Klasse durch einen Join
der Basisklassentabelle mit der Abgeleiteten-Klasse-Tabelle. Die Extension der
abstrakten Basisklasse (Menge aller Tupel der Basisklasse) wir dann durch eine Sicht
erzeugt, die die Tabellen / Extensionen der abgeleiteten Klassen passend projiziert und
dann vereint.
4.18 Characterisierung update-fähiger Sichten
Sichten sind i.A. veränderbar, wenn sie
●
keine Aggregatfunktionen / distinct / group by / having enthalten,
4 Relationale Anfragesprachen
Seite 11
●
in der „select“-Liste nur eindeutige Spaltennamen stehen und ein Schlüssel der
Basisrelation enthalten ist und
●
sie nur genau eine Tabelle (also Basisrelation oder Sicht) verwenden, die ebenfalls
änderbar sein muss.
Die gemäß SQL änderbaren Sichten sind eine Untermenge der theoretisch änderbaren
Sichten.
4.19 – 4.22 Einbettung von SQL
Embedded SQL: SQL-Statements im Code, wird z.B. durch einen Präprozessor dann in
„richtigen“ Programmcode umgewandelt. (z.B. SQLJ)
ODBC/JDBC: SQL-Statements als Strings innerhalb des Programms, Interpretation zur
Laufzeit.
4.23 Query by Example
basiert auf relationalem Domänenkalkül
geht auf Forschung von IBM in den 70er Jahren zurück, Einfluss in DB2
entspricht in etwa formularbasierten Filtern von MS Access
Bedingungen werden für jedes Attribut in ein Modell der Tabelle eingetragen
zusammen mit Befehlen und Variablen
Join mehrerer Tabellen durch gemeinsame Verwendung von Variablen in den Tabellen.
5 Datenintegrität
statische Integritätsbedingungen: müssen von einem bestimmten Zustand der
Datenbasis erfüllt werden
dynamische Inegritätsbedingungen: müssen von Zustandsänderungen erfüllt werden
Bereits bekannte/berücksichtigte Integritätsbedingungen:
●
eindeutige Schlüssel
●
Übername der Kardinalitäten von Beziehungen („1:n“ etc...) in das Datenmodell
●
bei Generalisierung ist jede Entät eines Untertyps auch Entät des Obertyps
●
Domänen für Attribute, die den gültigen Wertebereich spezifizieren (schwache
Einschränkung, da z.B. Vergleich zwischen MatrNr und Note möglich)
5.1 Referentielle Integrität
Eine Attributmenge a einer Relation S heißt Fremdschlüssel, wenn
●
alle Attribute aus a NULL oder alle nicht NULL sind
●
und im zweiten Fall a den Wert des Primärschlüssels einer Relation R repräsentiert
Erfüllung dieser Eigenschaft heißt referentielle Integrität.
5.2 Gewährleistung der referentiellen Integrität
(Eigentlich ist folgendes trivial...)
●
Bei Relationen mit Fremdschlüssel dürfen nur Tupel mit gültigen Schlüsselwerten
eingefügt werden.
●
Fremdschlüssel in Tupeln dürfen nur auf gültige Werte geändert werden.
Seite 12
5 Datenintegrität
●
Primärschlüsselwerte in Tupeln dürfen nur geändert werden, wenn sie von keinem
Fremdschlüssel referenziert werden.
●
Tupel dürfen nur gelöscht werden, wenn sie von keinem Fremdschlüssel
referenziert werden.
Sind diese Bedingungen verletzt, muss die dies verursachende Transaktion
rückgängug gemacht werden.
5.3 Referentielle Integrität in SQL
●
Schlüsselkandidaten sind unique-Indizes (bei Attributdeklaration)
●
Primärschlüssel ist der primary key
●
Fremdschlüssel ist ein foreign key, können auch NULL sein, unique foreign key spezifiziert 1:1 Beziehung
Verhalten bei Änderung von Verweisen oder referenzierten Daten:
●
create table S (..., a integer references R);
Ein noch von S referenziertes Tupel kann nicht aus R gelöscht werden.
●
create table S (..., a integer references R on update set null);
Beim Ändern des Primärschlüssels eines referenzierten Tupels aus R wird der
Fremdschlüssel in S auf NULL gesetzt.
●
create table S (..., a integer references R on update cascade);
Beim Ändern des Primärschlüssels eines referenzierten Tupels aus R wird der
Fremdschlüssel entsprechend angepasst.
●
create table S (..., a integer references R on delete set null);
Beim Löschen eines referenzierten Tupels aus R wird der Fremdschlüssel in S auf
NULL gesetzt.
●
create table S (..., a integer references R on delete cascade);
Beim Löschen eines referenzierten Tupels aus R werden die referenzierenden Tupel
in S ebenfalls gelöscht.
5.4 Statische Integritätsbedingungen
„check“-Anweisung (Teil der Attributdeklaration)
●
... check Semester between 1 and 20
●
... check Rang in ('C2','C3','C4')
●
... check ((S1 is NULL and S2 is NULL and ...) or (S1 is not NULL and S2 is not NULL and ...)) (Sx Attribute des Fremschlüssels) <= stellt sicher, dass
die erste Bedingung für „referentielle Integrität“ erfüllt ist)
5 Datenintegrität
Seite 13
5.6 Komplexe Integritätsbedingungen
create table ... (
... constraint BedingungsName check (exists (select * from bla where blubb()))
)
5.7 Trigger
Trigger = einer Relation zugeordnete benutzerdefinierte Prozedur, welche bei
Erfüllung einer bestimmten Bedingung ausgeführt werden (Quasi „Eventhandler“)
6 Relationale Entwurfstheorie
6.1 Funktionale Abhängigkeiten
Verallgemeinerung des Schlüsselbegriffs
Notation: funktional abhängig von (FD): , mit und Mengen von
Attributen
●
FD definiert, wenn und Teilmengen von sch(R)
●
FD erfüllt, wenn in allen Tupeln, in denen die -Attribute identische Werte haben
auch die -Attribute identische Werte haben
Sprechweise: „ -Werte bestimmen -Werte funktional eindeutig“, „ Determinante
von “
6.1.1 Konventionen zur Notation
{ A , B } {C,D }≡ A B C D
−{A }≡− A
6.1.2 Einhaltung der FD
Alternative Charakterisierung für FD:
FD erfüllt gdw. für alle mögl. Werte c von gilt, dass =c R max. ein
Tupel enthält
Algorithmus zum testen, ob Relation R die FD
erfüllt:
(Eigentlich auch trivial, oder?)
●
Eingabe: eine Relation R und eine FD
●
Ausgabe: ja, falls FD in R erfüllt, nein, sonst
●
Einhaltung(R,
)
-Werten
●
sortiere R nach
●
falls alle Gruppen bestehend aus Tupeln mit gleichen
Werte aufweise: Ausgabe „ja“, sonst Ausgabe „nein“
-Werten auch gleiche -
6.2 Schlüssel
●
⊂schR heißt „Superschlüssel“, falls die FD schR erfüllt ist
Seite 14
6 Relationale Entwurfstheorie
●
„Superschlüssel“, da damit nicht gesagt ist, dass minimal ist (Es gilt z.B. immer
schRschR
volle funktionale Abhängigkeit / voll funktional abhängig ( ̇ ):
1.
1. kann nicht weiter verkleinert werden, d.h.:
∀ A ∈ : −{A }/
Falls ̇schR gilt bezeichnet man als Kandidatenschlüssel von schR . i.A.
wird einer der Kandidatenschlüssel als Primärschlüssel ausgewählt. Dieser wird für
Fremdschlüssel verwendet. (Für Fremdschlüssel sollte immer derselbe
Kandidatenschlüssel einer Relation verwendet werden.)
6.3 Bestimmung funktionaler Abhängigkeiten
(schlechtes) Beispielschema:
ProfessorenAdr: {[PersNr, Name, Rand, Raum, Ort, Straße, PLZ, Vorwahl, BLand, EW,
Landesregierung]}
direkte FDs:
●
{PersNr} -> {PersNr, Name, Rand, Raum, Ort, Straße, PLZ, Vorwahl, BLand, EW,
Landesregierung}
●
{Ort, BLand} -> {EW, Vorwahl}
●
{PLZ} -> {BLand, Ort, EW}
●
{Ort, BLand, Strasse} -> {PLZ}
●
{BLand} -> {Landesregierung}
●
{Raum} -> {PersNr}
abgeleitete FDs (Beispiele):
●
{Raum } -> {PersNr, Name, Rand, Raum, Ort, Straße, PLZ, Vorwahl, BLand, EW,
Landesregierung}
●
{PLZ} -> {Landesregierung}
Bei einer gegebenen Menge FDs F interessant: Menge aller daraus herleitbaren FDs
F (Hülle der Menge F)
Armstrong-Axiome als Inferenzregeln:
●
Reflexivität: ⊆ ⇒ ≡ wahr
●
Verstärkung: Falls gilt, dann gilt auch , =∪ .
●
Transitivität: Falls und gilt, dann gilt auch
sind korrekt und vollständig
Hilfsaxiome (nicht notwendig, aber komfortabel):
●
Vereinigungsregel: Wenn und gelten, dann auch
●
Dekompositionsregel: Wenn gilt, dann gelten auch und
●
Pseudotransitivitätsregel: Wenn und gilt, dann auch .
6 Relationale Entwurfstheorie
Seite 15
Oft nicht die Hülle F interessant, sondern die Menge der von F aus
funktional bestimmten Attribute.
Algorithmus dafür:
●
Eingabe: eine Menge F von FDs und eine Menge von Attributen
●
Ausgabe: die vollständige Menge von Attributen , für die gilt
●
AttrHülle(F, )
Erg≝ ;
while(Änderungen an Erg) do
foreach FD in F do
if ⊆Erg then Erg≝Erg∪ ;
Ausgabe =Erg
Dann ist ein Superschlüssel von R, wenn AttrHülle F , =schR (mit F = die FDs
aus R) ist.
6.3.1 Kanonische Überdeckung
i.A. ex. viele verschiedene äquivalente Mengen von FDs
1. 2 FD-Mengen sind äquivalent gdw. ihre Hüllen gleich sind (= dieselben FDs aus
beiden Mengen herleitbar sind)
2. es ex. also eindeutige zu F äquivalente Menge von FDs (die Hülle)
3. Hülle i.A. sehr groß, Einhaltung aller FDs schwer zu überprüfen (vor allem bei
Datenbanksystemen)
4. also Suche nach der kleinsten äquivalenten Teilmenge [d.h. Abhängigkeiten, die sich
herleiten lassen, werfen wir raus]
„kanonische Überdeckung“ F c einer FD-Menge F:
1. F c ≡F
1. in F c ex. keine FDs mit „überflüssigen“ Attributen, d.h.
1. ∀ A∈ : F c − ∪ – A ≠F c
2. ∀ B ∈: F c − ∪ – B≠F c
2. Jede linke Seite einer FD in F c ist einzigartig.
Algo zur Bestimmung der kanonischen Überdeckung einer FD-Menge F:
1. Für jede FD in F Linksreduktion durchführen, d.h. testen, ob A∈
überflüssig und damit ⊆AttrHülleF , – A ist. Wenn ja, durch − A
ersetzen. [In jeder Regel so lange Attribute auf der linken Seite rausnehmen, wie die
Regel noch gültig ist.]
2. Für jede verbliebene FD Rechtsreduktion durchführen, d.h. prüfen ob ex. B
mit B∈AttrHülle F − ∪ −B , . Dann ist B rechts überflüssig und
wird aus der Regel entfernt.
[ Ausgangs-Abhängigkeit: ABC --> DEF. Wir nehmen D raus:
Seite 16
6 Relationale Entwurfstheorie
ABC --> EF. Frage: Gilt auch ABC --> D? Wenn ja, war D in DEF überflüssig und
kann entfernt werden. ]
3. Alle FDs mit leerer rechter Seite entfernen.
4. Alle Regeln mit identischer linker Seite vereinigen.
6.4 Schlechte Relationenschemata
●
Updateanomalien: Redundante Speicherung von Fakten, z.B. in einer Relation,
aktualisiert man sie an einer Stelle hat man Inkonsistenzen.
●
Einfügeanomalien: Speichern Daten zu unterschiedlichen Konzepten in einer
Relation (z.B. Professoren und Vorlesungen in einem Tupel, kann man beim
Einfügen einer Entität des einen Konzeptes das nur erreichen, wenn man die
Attribute des zweiten Konzeptes mit NULLwerten füllt.
●
Löschanomalien: Siehe vorherigen Punkt, löscht man ein Element eines Konzeptes,
muss man darauf achten, nicht versehentlich eines des anderen Konzeptes
mitzulöschen.
6.5 Zerlegung / Dekomposition von Relationen
Zerlegung eines Relationsschemas in mehrere verknüpfte Schemata
1. Verlustlosigkeit: Ursprüngliche Relation muss rekonstruierbar sein
2. Abhängigkeitserhaltung: Die für schR geltenden Abhängigkeiten müssen auf
schR1 , ,schR n übertragbar sein.
6.5.1 Verlustlosigkeit
Zerlegung von schR in sch R1 ∪sch R2 mit den Ausprägungen R1 := schR R
und R2 := sch R R .
1
2
Zerlegung ist verlustlos, wenn R=R1 xx R2 (natürlicher Verbund)
6.5.2 Kriterien für die Verlustlosigkeit einer Zerlegung
Verlustlosigkeit nicht auf den ersten Blick ersichtlich, deswegen formale Kriterien
notwendig.
Zerlegung verlustlos, wenn:
●
sch R1 ∩schR 2 schR1 ∈F sch R
●
sch R1 ∩schR 2 schR2 ∈F sch R
(Mit dem Schnitt der Attribute kann man noch Tupel in R1 oder R2 eindeutig
bestimmen.) [Der Schnitt der Schemata, d.h. die Attribute, die in beiden Tabellen
vorkommen, müssen in mind. einer der beiden neuen Tabellen ein Schlüssel sein. (da
man beim JOIN die Verknüpfung über die Schnittattribute vornimmt.]
6.5.3 Abhängigkeitsbewahrung
Überprüfung der funktionalen Abhängigkeiten (Konsistenzbedingungen) sollte auf den
zerlegten Relationen und ohne Join möglich sein.
Ri
Für jedes Ri ist F R die Menge der FDs aus F
R , deren Attribute alle in
enthalten sind.
i
6 Relationale Entwurfstheorie
Seite 17
F R ≡F R ∪∪F R
1
n
(abhängigkeitsbewahrende Zerlegung wird auch „hüllentreue Dekomposition“
genannt)
Nicht abhängigkeitsbewahrende Zerlegungen erlauben das Einfügen von Tupeln so,
dass die lokalen Abhängigkeiten in jedem F R erfüllt aber die globalen auf F R
verletzt sind.
i
6.6 Erste Normalform
Verlangt atomare Wertebereiche, d.h. z.B. keine mengenwertigen Attribute. Nach
unserer Definition immer erfüllt. Umwandlung erreicht man durch „Flachklopfen“.
6.7 Zweite Normalform (2NF)
Intuitiv: Verletzt, wenn in einer Relation Informationen über mehr als ein einziges
Konzept modelliert werden
[„Man darf nicht bereits mit einem Teil des Schlüssels Attribute eindeutig
identifizieren können.“ Genau das ist aber bei gejointen Tabellen der Fall!
MatNr
Student Name
VorlesungsID
1
Klaus
1
1
Klaus
2
2
Gunter
2
2
Gunter
3
2
Gunter
4
Der Gesamtschlüssel der Tabelle ist MatNr und VorlesungsID, MatNr reicht jedoch
bereits zur Identifizierung des Studenten aus. Daher ist diese Tabelle NICHT in 2.
Normalform!]
Seien 1 , , i die Kandidatenschlüssel von R und A∈R−1 ∪...∪ i (A: „nicht-prim“;
*: „prim“)
Dann muss für alle j gelten: j ̇ A ∈F (blöde Frage: gilt das nicht immer?!?
Nein!!! Es kann sein, dass j in dem Fall nicht mehr minimal ist!)
6.8 Dritte Normalform
Intuitiv: Verletzt, wenn ein Nicht-Schlüssel-Attribut einen Fakt einer Attributmenge
darstellt, welche keinen Schlüssel bildet => derselbe Fakt könnte mehrfach
gespeichert werden
[Kann z.B. wieder bei gejointen Tabellen passieren:
MatNr
Seite 18
Student Name
VorlesungsID
Vorlesungsname
1 Klaus
1 Datenbanken
1 Klaus
2 Compilerbau
2 Gunter
2 Compilerbau
2 Gunter
3 DatKomm
2 Gunter
4 Data Mining
6 Relationale Entwurfstheorie
Vorlesungsname ist Fakt des Attributes VorlesungsID, aber VorlesungsID ist kein
Superschlüssel. Daher ist diese Tabelle NICHT in 3. Normalform!]
Relation ist in 3NF, wenn für jede in R geltende FD B mit ⊆sch R und
B ∈sch R eine der folgenden Bedingungen erfüllt ist:
●
●
●
B ∈
B ist Element eines Kandidatenschlüssels von sch R (prim)
ist Superschlüssel von sch R
Synthesealgorithmus zur Zerlegung von sch R in sch R 1 , , sch R n , so dass:
●
Zerlegung verlustlos
●
abhängigkeitsbewahrend
●
alle sch R i in 3NF
Algo:
1. kanonische Überdeckung Fc zu F bestimmen
2. Für jede FD ∈F c :
●
Relationsschema sch R ≝∪ erstellen
●
und folgende FDs zuordnen: F ≝{ ' '∈ Fc∣ ' ∪ '⊆sch R }
3. Falls ein in Schritt 2 erzeugtes Schema sch R einen Kandidatenschlüssel von
sch R bezügl. Fc enthält fertig, sonst Kandidatenschlüssel ⊆sch R
auswählen und folg. Schema hinzufügen:
●
sch R ≝
●
F ≝∅
●
alle Schemata eliminieren, die in anderen enthalten sind
Beispiel Buch Seite 182
6.9 Boyce-Codd Normalform
Die BCNF verbietet 1:1-Beziehungen zwischen Teilen von Kandidatenschlüsseln, die
bei den anderen NFs noch erlaubt sind. (Siehe Beispiel im Buch Seite 183.)
Eine Relation R ist in BCNF, wenn für jede in R geltende FD B mit ⊆sch R
und B ∈ sch R eine der folgenden Bedingungen erfüllt ist:
●
B ∈
●
ist Superschlüssel von sch R
Man kann nicht immer eine abhängigkeitsbewahrende BCNF-Zerlegung finden! (Ist in
der Praxis aber selten.)
Zerlegungs-Algorithmus Buch Seite 183
6.10 Mehrwertige Abhängigkeiten (MVD)
Verallgemeinerung von FDs (jede FD ist auch MVD)
6 Relationale Entwurfstheorie
Seite 19
nennt man mehrwertig abhängig von (geschrieben: ), wenn man in jeder
Ausprägung der entsprechenden Relation zu zwei Tupel mit gleichen -Werten zwei
weitere Tupel mit denselben -Werten findet, bei denen die -Werte vertauscht sind.
(Formale Definition siehe Buch Seite 185.)
Seien , , ⊆sch R , sch R =∪∪ .
t1
a1 ai
ai 1 a j
a j1 a n
t2
a1 ai
bi 1 b j
b j1 bn
t3
a1 ai
bi 1 b j
a j1 a n
t4
a1 ai
ai 1 a j
b j1 bn
Diese Art von Redundanz bekommt man z.B. in Relationen, wenn man zwei
verschiedene Konzepte zu einem Schlüssel in einer Relation zusammenfasst (Beispiel
mit Fremdsprachen- und Programmiersprachen-Kenntnissen) und alle Kombinationen
(im Beispiel: <Sprache, ProgSprache>) für die Belegung dieser Konzepte aufzählt.
Triviale MVDs (gelten in jeder Ausprägung):
1. ⊆ oder
2. =sch R −
(FDs nur unter der ersten Bedingung trivial.)
Zerlegung eines Relationschemas sch R ist genau dann verlustlos in sch R 1 und
sch R 2 zerlegbar wenn eines der folgenden gilt:
1. sch R 1 ∩sch R 2 sch R 1 oder
2. sch R 1 ∩sch R 2 sch R 2
Folgende Regeln gelten bei MVDs:
●
Komplement: aus folgt sch R −−
●
mehrwertige Verstärkung: aus und ⊆ folgt
●
mehrwertige Transitivität: Aus und folgt −
●
Verallgemeinerung: Aus folgt
●
Koaleszenz: Gilt , ⊆ und ex. ⊆sch R mit ∩=∅ und , dann
folgt
Zusätzlich gelten noch: (ableitbar aus den obigen Regeln)
●
mehrwertige Vereinigung: aus und folgt
●
Schnittmenge: aus und folgt ∩
●
Differenz: aus und folgen − und −
6.11 Vierte Normalform
Die 4NF verbietet zwei voneinander unabhängige mehrwertige Fakten, wie im Beispiel
mit Sprache und ProgSprache vorhanden waren.
Seite 20
6 Relationale Entwurfstheorie
Eine Relation sch R mit zugeordneter Menge D von funktionalen und
mehrwertigen Abhängigkeiten ist in 4NF wenn für jede nicht-triviale MVD
∈D gilt, dass ein Superschlüssel von sch R ist.
(Zerlegungsalgorithmus im Buch auf Seite 188)
6.12 Zusammenfassung
●
Verlustlosigkeit bei allen NFs garantiert
●
Abhängigkeitserhaltung nur bis zur 3NF garantiert
Für „Feinabstimmung eines solide durchgeführten konzeptuellen Entwurfs“, keine
Ausrede um dabei zu schlampen (Motto: „Normalisierung wird's schon richten“).
7 Physische Datenorganisation
7.1 Speichermedien
●
Primärspeicher (idR. RAM): sehr teuer, sehr schnell, verhältnismäßig klein,
Direktzugriff mit sehr feiner Granularität (Worte), flüchtig
●
●
●
Pufferfunktionen in DBMSen
Sekundärspeicher (idR. Festplatte): Faktor 105 langsamer als RAM, aber wesentlich
größer, billiger, Direktzugriff mit gröberer Granularität (Blöcke), persistent
●
Speichert Seiten von DBMSen, eine Seite umfasst mehrere in einer Reihe
liegenden Blöcke
●
Zugriff auf einen Block 3-stufig: Seek, Wartezeit bis der Block vorbeirauscht,
Lesezeit
Archivspeicher (idR. Bandlaufwerke): sehr langsam, inzwischen kleiner als
Festplatten, etwas billiger, sequentieller Zugriff, persistent, lange Lebensdauer und
hohe Ausfallsicherheit
●
Datensicherungen, Protokollspeicherung
7.2 Speicherarrays: RAID
Große Geschwindigkeits-Diskrepanz zwischen Hauptspeicher- und
Festplattenzugriffen, wird auch bei neuer Hardware eher größer als kleiner.
Einsatz mehrerer Laufwerke parallel zur Erzielung höherer Geschwindigkeit und/oder
einer höheren Ausfallsicherheit.
Raid 0 bis 6 sowie Raid 0+1:
RAID 0: Striping auf Blockebene
●
höhere Geschwindigkeit durch Parallelverarbeitung
●
stark erhöhte Ausfallwahrscheinlichkeit
RAID 1: Spiegelung auf Blockebene
●
höhere Datensicherheit
●
Aufteilung von Lesezugriffen: höhere Geschwindigkeit, Schonung der Platten
●
nur halbe (bzw. weniger) Speicherkapazität
RAID 0+1:
●
Raid 0, nur doppelt vorhanden (gespiegelt)
7 Physische Datenorganisation
Seite 21
RAID 2: Striping auf Bitebene
●
in der Praxis selten eingesetzt
RAID 3: Striping auf Bitebene mit dedizierter Paritätsplatte
●
1 Lesezugriff fordert alle Festplatten
●
Paritätsplatte beim Lesezugriff nur in Fehlerfällen verwendet
RAID 4: Striping auf Blockebene mit dedizierter Paritätsplatte
●
Lesezugriffe verteilt auf alle Platten: effizienter als RAID 3
●
bei jedem Schreibzugriff ein notwendiger Lese- und ein Schreibzugriff auf die
Paritätsplatte zur Neuberechnung der Paritätsinformation (schlechter als bei
RAID 3)
RAID 5: Striping auf Blockebene mit verteilten Paritätsdaten
●
gleichmäßige Nutzung aller Platten bei Lese- und Schreibzugriffen
●
Beim Schreiben müssen immer noch der alte Paritätsblock und der alte
Datenblock gelesen werden, um mit dem neuen Datenblock die neuen
Paritätsinformationen zu berechnen.
RAID 6: wie RAID 5 aber mit verbesserten Fehlerkorrekturmöglichkeiten
●
RAID 3 und RAID 5 können nur jeweils höchsten einen Fehler erkennen und
korrigieren
Wahl des passendes RAID-Levels von der Nutzungsart des Plattenspeichersystems
abhängig
RAID verlängert höchstens den Zeitraum bis zu einem notwendigen Recovery, aber
macht Backups nicht überflüssig!
7.3 Der Datenbankpuffer
Cached Datenbankseiten und stellt sie für Bearbeitung zur Verfügung.
Cache nutzt Lokalität bei Zugriffen der Datenbankanwendung: Eine Anwendung
arbeitet häufig auf wechselnden, begrenzten Bereichen der Datenbasis anstatt auf
allen Daten auf einmal.
Enthält oft eine feste Anzahl Pufferrahmen, aus denen Seiten bei Platzmangel mittels
einer Ersetzungsstrategie verdrängt werden müssen. (Seiten entfernen, die möglichst
lange nicht mehr benötigt werden.)
7.4 Abbildung von Relationen auf den Sekundärspeicher
Orientierung an den Merkmalen des Speichermediums
Naheliegend: Zusammenfassung mehrerer Seiten zu einer Datei. Speicherung von
Tupel in jeder Seite so, dass sie nicht über Seitengrenzen hinausgehen. Jede Seite hat
interne Datensatztabelle, die Verweise auf enthaltene Tupel verwaltet
Adressierung eines Tupels über die TID (Tupel ID), bestehend aus Seitennummer und
Position in der Datensatztabelle der Seite
physikalische Umsortierung von Tupeln in einer Seite somit problemlos
Bei notwendiger Verschiebung eines Tupels in eine andere Seite wird in der
Heimatseite ein Verweis auf die neue eingefügt. (Führt zu vorher nicht notwendigem
Seitenzugriff.) Ändert sich die Seite des Tupels nochmals, wird der Verweis in der
Heimatseite aktualisiert.
Seite 22
7 Physische Datenorganisation
7.5 Indexstrukturen
Ausnutzung der Direktzugriffsmöglichkeit des Sekundärspeichers: Indexstrukturen,
kein sequentieller Scan aller Tupel notwendig
zusätzlicher Aufwand für Wartung des Indexes
Primärindex: legt die Speicherung der Tupel fest, Sekundärindexe kann es mehrere
geben
Schlüssel bei Indexen Suchkriterium, unabhängig vom Schlüsselbegriff bei Relationen
ISAM, B-Bäume: gut für Bereichsanfragen
Hashing: gut für Punktanfragen
7.6 ISAM
Index Sequential Access Method
(Daumenindex) Index auf mehreren sequentiell angeordneten Seiten, abwechselnd
Schlüsselwerte (sortiert: Binärsuche) und Verweise auf Datenseiten
Hilfreich zum Finden von Wertebereichen der Suchschlüssel: Lese ab der über Index
gefundenen ersten passenden Datenseite alle weiteren, bis Suchkriterium nicht mehr
erfüllt ist. (geht dank Sortierung auch in den Datenseiten)
Einfügen dadurch aber sehr aufwändig, Ausgleich mit anderen Datenseiten beim
Überlauf einer Seite, Reorganisation des kompletten Index ab dem Einfügepunkt
notwendig, falls ein neue Datenseite angelegt werden muss
Löschen auch nicht optimal: läuft eine Datenseite leer, wird sie aus dem Index entfernt
und dieser muss wieder ab dem Löschpunkt reorganisiert werden
Verbesserung des Update-Verhaltens durch weitere Indirektion: auch Index wird wie
Datenblöcke als verkettete Liste gespeichert und im RAM ein Array von zeigern auf die
Indexblöcke angelegt => Ähnlichkeit zu B-Bäumen
7.7 B-Bäume
Binärbäume wegen blockweisem/seitenweisem Zugriff als HintergrundspeicherStruktur ungeeignet
B-Bäume: Knotengröße auf Seitenkapazitäten abgestimmt
●
Seitenwechsel nur beim Verfolgen einer Kante notwendig (d.h. Seitenzugriffe durch
Baumhöhe begrenzt)
●
Eintrag besteht aus Schlüsselwert Si und Datensatznummer Di bei einem
Primärindex und aus Schlüsselwert und TID bei Sekundärindizes
●
alle Einträge verweisen auf Datenblöcke und die Schlüsselwerte der inneren Knoten
dienen zusätzlich als Wegweiser zu Kindknoten
Eigenschaften eines B-Baum vom Grad k:
1. Jeder Weg von Wurzel zu Blatt hat gleiche Länge.
2. Jeder normale Knoten hat min. k und höchstens 2k Einträge. Die Wurzel hat
zwischen einem und 2k Einträgen. Einträge sind in allen Knoten sortiert.
3. Alle inneren Knoten mit n Einträgen haben n+1 Kinder.
4. Zu den Schlüsselwerten S1 bis Sn in jedem Knoten gehören die Verweise V0 bis Vn,
hierbei bekannte Vorgehensweise.
7 Physische Datenorganisation
Seite 23
Einfügen/Löschen/Ändern im Buch ab Seite 208
7.8 B+-Bäume (auch manchmal B*-Bäume genannt)
hohler Baum: Verweise zu Datensätzen nur in den Blättern, in inneren Knoten nur
„Wegweiser“. Dadurch dort weniger Platzbedarf = höherer Verzweigungsgrad =
geringere Baumhöhe = weniger Seitenzugriffe
zusätzlich Speicherung der Blätter als verkettete Liste für sequentielle Suchen
Eigenschaften eines B+-Baum vom Typ(k, k*):
1. Jeder Weg von Wurzel zu Blatt hat gleiche Länge.
2. Jeder innere Knoten hat min. k und höchstens 2k Einträge. Jedes Blatt hat
mindestens k* und max. 2k* Knoten. Die Wurzel max. 2k Einträge oder ist ein Blatt
mit max. 2k* Einträgen. Einträge sind in allen Knoten sortiert.
3. Alle inneren Knoten mit n Einträgen haben n+1 Kinder.
4. Zu den Schlüsselwerten S1 bis Sn in jedem Knoten gehören die Verweise V0 bis Vn,
hierbei bekannte Vorgehensweise.
Weiterer Vorteil gegenüber B-Baum: Referenzschlüssel (Wegweiser) müssen nicht real
existierenden Schlüsselwerten entsprechen, dadurch weniger Aktualisierungen in der
Baumstruktur
7.9 Präfix-B+-Bäume
Bei großen Schlüssel, z.B. Zeichenketten, sinkt der Verzweigungsgrad bei B-Bäumen.
Dadurch in inneren Knoten Verwendung eindeutiger kurzer Schlüssel, auf denen eine
für die realen Schlüsselwerte passende Sortierung definiert werden kann, z.B. kurze
eindeutige Präfixe bei Zeichenketten
7.10 Hashing
Hash-Funktion ordnet jedem Schlüsselwert einen „Bucket“ zu. Passender Bucket kann
dann bei direkter Schlüsselwertanfrage idR. mit einem Seitenaufruf gefunden werden.
Gute Hashfuntkion verteilt mögliche Schlüsselwerte möglichst gleichmäßig auf alle
Buckets
Divisions-Rest-Verfahren mit Primzahl häufige Hashfunktion: h(x) = x mod p
offenes Hashing: „Überlaufbehälter“ für jeden Bucket
geschlossenes Hashing: ist ein Ziel-Bucket voll, wird nach festgelegtem Verfahren ein
anderer gewählt, und das so lange, bis ein freier gefunden wird.
7.11 Erweiterbares Hashing
Die Hashfunktion bildet hier auf einen deutlich größeren Bereich ab, als Buckets
vorhanden sind. Dabei wird jedem Bucket ein ganzer Hash-Wertebereich zugeordnet.
Läuft jetzt ein Bucket über, wird die Detaillierung des Index erhöht, d.h. es werden
Buckets dazugenommen (z.B. Anzahl verdoppeln) und jedem ein kleinerer
Wertebereich zugeordnet.
Mögliche Realisierung: Hashfunktion berechnet Binärzahlen, es wird nur das erste Bit
des Hash-Wertes für die Zuordnung zu 2 Buckets verwendet. Läuft einer über, wird
auch noch das zweite Bit der Hashwerte berücksichtigt und alle Daten werden auf 4
Buckets aufgeteilt, dann auf 8 usw...
Globale Tiefe: Anzahl der berücksichtigten Bits
Seite 24
7 Physische Datenorganisation
Lokale Tiefe: Anzahl der relevanten Bits innerhalb einer Behälters, ≤ globale Tiefe
7.12 Mehrdimensionale Indexstrukturen
oft Anfragen nach mehreren Attributen => mehrdimensionale Indexstrukturen
R-Baum: Speicherung sog. „Boxen“ in den Knoten (Begrenzungskästen), jeder BoxEintrag verweist dann auf den Baum-Knoten, welcher die „Inhalte“ der Box speichert
Schwierigkeiten beim Aufteilen von Knoten: Was ist die beste Aufteilungsstrategie?
Ziel: möglichst kleine Boxen, um den Index möglichst präzise zu halten
Suchen beschränken sich auf Kandidatenboxen, die die gesuchten Daten enthalten
könnten, nur deren Kinder werden verfolgt.
7.13 Ballung logisch verwandter Datensätzen
benachbarte Speicherung häufig zusammen benötigter Datensätze auf möglichst
wenigen Seiten
Kompatibilität zu Indexstrukturen mit zusätzlicher Indirektion:
Primärindex kann zur Ballung verwendet werden. Bei der Verwendung des TIDKonzeptes (Datensatz-ID in Primärindex, TIDs in Sekundärindizes)ergeben sich bei der
Aufspaltung eines Knotens allerdings viele Verweise: unakzeptabel
Lösung: auch in Primärindex nur TIDs speichern, und benachbarte Datensätze
trotzdem möglichst auf einer Seite platzieren
Alternative, falls schon „fast alle“ Datensätze vorhanden sind: den Primärindex auf die
vorhandene Datenbasis in einem Rutsch anlegen und hoffen, dass es bei den
„wenigen“ nachträglichen Update-Operationen nicht zu Knotensplits kommt.
Datenbasis sonst periodisch reorganisieren.
7.14 Unterstützung des Anwendungsverhaltens
Hashing: perfekt bei Punktanfragen
B-Bäume: „Gutes“ Verhalten „in allen Lebenslagen“
Achtung: viel IO bei Bereichsanfragen ohne geeignete Datensatzballung!
Indexe, beschleunigen Lesezugriffe und bremsen Updateoperationen (besonders krass:
ISAM)
7.15 Physische Datenorganisation in SQL
nicht standardisiert in SQL-92
herstellereigene Erweiterungen zur Verwaltung von Indizes usw.
9 Transaktionsverwaltung
Bündelung mehrerer Operationen zu einer nach außen hin atomaren Einheit
„Recovery“ bei Fehlersituationen, Synchronisation zwischen parallel laufenden
Transaktionen
9.1 Begriffsbildung
Abstrakt: Transaktion = Arbeitseinheit
9 Transaktionsverwaltung
Seite 25
Auf Datenbankebene: Folge von Datenverarbeitungsbefehlen, welche die Datenbasis
von einem konsistenten Zustand atomar in einen anderen überführen
(z.B. Überweisung zwischen Konten oder Geldabhebung am Automaten)
9.2 Anforderungen an die Transaktionsverwaltung
Parallelverarbeitung von Transaktionen: Synchronisation
Schutz vor Soft- und Hardwarefehlern: abgeschlossene Transaktionen müssen auch
nach einem Fehler erhalten bleiben, nicht abgeschlossene müssen vollständig
verworfen werden
9.3 Operationen auf Transaktions-Ebene
verwaltete Operationen: read und write
Steuerbefehle:
●
Begin Of Transaction (BOT)
●
Commit
●
Abort
in einigen Systemen auch noch:
●
Define Savepoint
●
Backup Transaction
9.4 Abschluss einer Transaktion
1. erfolgreicher Abschluss mittels Commit
2. erfolgloser Abschluss durch Abort (durch Benutzer oder durch Fehler /
Transaktionsverwaltung)
Möglichkeiten für unerwünschten Abbruch: Hardwarefehler, Stromausfall,
Programmfehler, Deadlock, der durch Abbruch der Transaktion beseitigt werden kann
oder Verletzung von Konsistenzbedingungen nach Abschluss der Transaktion
9.5 Eigenschaften von Transaktionen
ACID:
●
Atomicity
●
Consistency
●
Isolation (Ergebnis paralleler Transaktionen muss unabhängig voneinander sein)
●
Durability
Bestandteile der Transaktionsverwaltung:
●
Mehrbenutzersynchronisation
●
Recovery (Atomarität und Dauerhaftigkeit)
9.6 Transaktionsverwaltung in SQL
●
Transaktionen werden implizit begonnen (kein BOT)
●
Abschluss durch Commit Work oder Rollback Work
Seite 26
9 Transaktionsverwaltung
9.7 Zustandsübergänge einer Transaktion
●
potentiell (bereit, aber noch nicht gestartet)
●
aktiv (buhlt um Rechenzeit)
●
wartend (Pausiert durch Transaktionsverwalter, z.B. bei Überlast)
●
abgeschlossen (durch Commit beendet, aber Konsistenzprüfung folgt noch)
●
persistent (beendet und dauerhaft festgeschrieben)
●
gescheitert (Abort, Fehler)
●
wiederholbar (gescheitert, aber nicht kritisch, wartet auf neue Aktivierung)
●
aufgegeben (hoffnungslos, Komplettabbruch)
13 Objektorientierte Datenbanken
reines relationale Modell für Gebiet wie Multimedia-Datenbanken ungeeignet
evolutionärer Ansatz: Erweiterung des relationalen Modells um komplexe Objekte (z.B.
geschachteltes relationales Modell NF²)
revolutionärer Ansatz: objektorientierte Modellierung, Kombination der strukturellen
Repräsentation mit der verhaltensmäßigen Komponente und Strukturierung durch
Vererbung
13.1 Bestandsaufnahme relationaler Datenbanksysteme
(Polyederbeispiel, Buch Seite 354)
●
Segmentierung: ein einzelnes modelliertes Objekt wird auf mehrere Relationen
„verteilt“ bzw. zerlegt
●
künstliche Schlüsselattribute nötig
●
fehlendes Verhalten (nur Realisierung als Anwendungsprogramm außerhalb des
DBMS möglich, mehrfache Implementierungen derselben Funktionen)
●
Notwendigkeit einer externen Programmierschnittstelle: „Impedance Mismatch“
(mengenorientiertes Datenbankverhalten gegenüber satzorientierten imperativen
Programmiersprachen)
Zur Durchführung von Operationen muss ein externes Anwendungsprogramm also
häufig Daten aus diversen Tabellen zusammensuchen, Operationen darauf durchführen
und die Daten wieder zurückschreiben.
13.2 Vorteile der objektorientierten Datenmodellierung
●
Integration von Verhaltens- und Strukturbeschreibung in eine einheitliche
Objekttyp-Definition
●
Objektkapselung
●
erhöhte Wiederverwendbarkeit der Methoden
●
eindeutige Objektidentität
13.3 Der ODMG-Standard
Object Database Management Group = Herstellerkonsortium mit dem Ziel, einheitlich
festgelegtes Objektmodell zu implementieren, einfache Anbindung bestehender
Systeme und Sprachen
13 Objektorientierte Datenbanken
Seite 27
ODMG-Modell „umschließt“ existierendes ODBMS und bietet einheitliche
Programmierschnittstelle für bestehende Sprachen
Entwurf einer deklarativen Abfragesprache OQL (Object Query Language) (in
Anlehnung an SQL)
13.4 Eigenschaften von Objekten
relationales Modell: Darstellung als Tupel aus atomaren Werten
objektorientiertes Modell:
●
systemweit eindeutige Objekt-Identität
●
Objekttyp, legt Struktur und Verhalten fest
●
Zustand
13.4.1 Objektidentität
im relationalen Modell: Identität durch gleiche Attributwerte, problematisch, dadurch
häufig „künstliche“ Unterscheidungsattribute, welche manuell gewartet werden
müssen und bei versehentlicher Änderung zu Konsistenzproblemen führen
In OOP-Programmiersprachen: Identität durch Zeiger/Speicheradressen, Objekte
können nicht verschoben werden, „dangling references“ bei zerstörten Objekten
möglich
Lösung: Verwendung eindeutiger unveränderlicher Object-IDs (OIDs) in ODBMS
13.4.2 Typ eines Objekts
Klassen, Instanzen: Wie in OOP
(Typ-)Extension: Menge aller Objekte eines Typs, quasi wie Relation aus Tupeln im
relationalen Modell (Enthält auch Objekte abgeleiteter Klassen!)
13.4.3 Wert eines Objekts
aktuelle Belegung der Attribute, beliebige Objekte als Attribute möglich
13.5 Definition von Objekttypen
Festlegung von Strukturbeschreibung, Verhaltensbeschreibung und Typeigenschaften
(Superklasse(n), etc...)
Syntax in der ODL (Objekt Definition Language der ODMG):
13.5.1 Attribute
class <Name> {
attribute <typ> <Name>;
...
};
13.5.2 Beziehungen
1:1-Beziehungen:
Seite 28
13 Objektorientierte Datenbanken
class Professoren {
attribute long PersNr;
...
relationship Räume residiertIn;
};
class Räume {
attribute long RaumNr;
...
relationship Professoren beherbergt;
};
Garantiert aber nicht 1:1-Beziehung und Symmetrie. Dafür inverse-Schlüsselwort:
class Professoren {
attribute long PersNr;
...
relationship Räume residiertIn inverse Räume::beherbergt;
};
class Räume {
attribute long RaumNr;;
...
relationship Professoren beherbergt inverse Professoren::residiertIn;
};
1:N-Beziehungen:
class Professoren {
... relationship set<Vorlesungen> liest inverse Vorlesungen::gelesenVon;
} class Vorlesungen {
... relationship Professoren gelesenVon inverse Professoren::liest;
}
N:M-Beziehungen:
class Studenten {
... relationship set<Vorlesungen> hört inverse Vorlesungen::Hörer;
}
class Vorlesungen {
... relationship set<Studenten> Hörer inverse Studenten::hört;
}
(auch rekursiv)
Ternäre und mehrstellige Beziehungen durch einen zusätzlichen VerknüpfungsObjekttyp, ähnlich wie Verknüpfungstabellen bei relationalen Datenbanken
13.5.3 Typeigenschaften: Extensionen und Schlüssel
Wiederholung:
(Typ-)Extension: Menge aller Objekte eines Typs, quasi wie Relation aus Tupeln im
relationalen Modell (Enthält auch Objekte abgeleiteter Klassen!)
Schlüssel als Integritätsbedingung für Extension, nicht zur Referenzierung
13 Objektorientierte Datenbanken
Seite 29
class Studenten (extend AlleStudenten key MatNr) { ...
13.6 Modellierung des Verhaltens: Operationen
definierte Schnittstelle zur Beobachtung/Manipulation, interna gekapselt
Schnittstelle bietet Möglichkeiten für
●
Objekte erzeugen (Konstruktoren/Desktruktoren)
●
interessante Teile des Zustands erfragen (Beobachter)
●
Objekt konsistenzerhaltend manipulieren (Mutatoren)
●
Objekt zerstören (Konstruktoren/Desktruktoren)
class beschreibt nur die Signaturen von Operationen (Operationsnamen, ihre
Parameter, Rückgabetyp, Ausnahmen)
class Professoren {
exception hatNochNichtGeprüft {};
...
float wieHartAlsPrüfer() raises (hatNochNichtGeprüft);
};
13.7 Vererbung und Subtypisierung
Verhalten prinzipiell wie in OOP
●
(direkte) Obertypen, (direkte) Untertypen
●
Vererbung aller Attribute, Operationen und Relationships
●
jede Instanz einer abgeleiteten Klasse ist automatisch Instanz aller ihrer
Oberklassen [ Die Angestellten-Extension enthält auch alle Professoren und
Assistenten-Objekte. ]
●
dadurch Substituierbarkeit
13.7.2 Einfache und Mehrfachvererbung
Einfach- / Mehrfachvererbung
Vorteil bei Einfachvererbung: eindeutiger Pfad von der Wurzel der Typhierachie zu
jedem Objekttyp
class <bla> extends <blubb> { ...
13.9 Verfeinerung (Spezialisierung) und spätes Binden von
Operationen
Operationen werden von Supertypen geerbt, können aber überschreiben werden
Polymorphismus wird unterstützt („Professoren sind auch Angestellte“)
13.10 Mehrfachvererbung
Gibt es nicht im ODMG-Modell, nur interfaces. (Ähnlich Java)
Ebenfalls wie in Java basiert das gesamte Objektmodell auf einer Basisklasse. (Im
C++-Mapping d_Object genannt.)
Seite 30
13 Objektorientierte Datenbanken
13.11 Die Abfragesprache OQL
Syntax ähnlich zu SQL, aber man arbeitet auf beliebig strukturierten Objekten, deren
Operationen man aufrufen kann
13.11.1 Einfache Anfragen
select p.Name from p in AlleProfessoren where p.Rang = „C4“;
select struct(n: p.Name, r: p.Rang) from p in AlleProfessoren where p.Rang = „C4“;
13.11.2 Geschachtelte Anfragen und Partitionierung
Möglich:
select struct(n: p.Name, a: sum(select v.SWS from v in p.liest)) from p in AlleProfessoren where avg(select v.SWS from v in p.liest) > 2;
macht Gruppierungen wie z.B. „group by“ in SQL praktisch überflüssig
„group by“ existiert dennoch, aber sehr allgemein für beliebige Partitionierungen:
select * from v in AlleVorlesungen group by kurz: v.SWS <= 2, mittel: v.SWS = 3, lang: v.SWS > 4
Ergebnis besteht aus 3 Tupeln des Typs
struct(kurz: boolean, mittel: boolean, lang: boolean, partition: bag<struct(v: Vorlesungen)>)
13.11.3 Pfadausdrücke
select s.Name from s in AlleStudenten, v in s.hört where v.gelesenVon.Name = „Sokrates“;
quasi Dereferenzierung
13.11.4 Erzeugung von Objekten
Erzeugung neuer Objekte durch Verwendung des Objektkonstruktors in Abfragen statt
des Tupelkonstruktors struct
Beispiel zur Erzeugung eines Vorlesungs-Objektes:
Vorlesungen(VorlNr: 5555, Titel: „Ethik II“, SWS: 4, gelesenVon: (select p from p in AlleProfessoren where p.Name = „Sokrates“));
„Hörer“ und „abgeprüft“ werden auf Standardwerte gesetzt
13.11.5 Operationsaufruf
select a.Name from a in AlleAngestellten where a.Gehalt() > 100000;
AlleAngestellten enthält hierbei alle Professoren, Assistenten, ..., da Supertyp
13.12 C++-Einbettung
Möglichkeiten zur Implementierung der Operationen:
1. Entwurf einer neuen Sprache (perfekt zugeschnitten auf Anforderungen, aber mit
hohen Realisierungs- und Lernaufwand für die Benutzer verbunden)
2. Erweiterung einer bestehenden Sprache (Realisierungsaufwand ähnlich zu 1 und
evtl. unnatürlich wirkende Erweiterungen zu der „Wirtssprache“
13 Objektorientierte Datenbanken
Seite 31
3. Typbibliothek zu bestehender Sprache (einfachste Möglichkeit, aber Transparenz
leidet, „Reibungsverluste“)
ODMG-Modell entspricht der letzten Lösung, Übersetzung der ODL-Dateien in C++Header, welche implementiert, compiliert und gegen die ODBMS-Laufzeitbibliothek
gelinkt werden müssen
13.12.1 Objektidentität
Nicht in erforderlicher Form von C++ unterstützt, Realisierung durch die C++Klassen d_Rel_Ref und d_Rel_Set:
const char _liest[] = „liest“;
const char _gelesenVon[] = „gelesenVon“;
class Vorlesungen : public d_Object {
...
d_Rel_Ref<Professoren, _liest> gelesenVon;
};
class Professoren : public Angestellte {
...
d_Rel_Set<Vorlesungen, _gelesenVon> liest;
};
13.12.2 Objekterzeugung und Ballung
Objekterzeugung per new, dabei Angabe passender Allokatoren, z.B. die Datenbank
oder ein anderes existierendes Objekt, was bedeutet, dass das neue Objekt möglichst
nahe bei dem existierenden gespeichert wird.
13.12.3 Einbettung von Afragen
Als String im C++-Code, wird einem d_OQL_Query-Objekt übergeben, dabei sind
Parameter in der Abfrage , die später vom d_OQL_Query-Objekt ausgefüllt werden
möglich.
14 Erweiterbare und objekt-relationale Datenbanken
14.1 Übersicht über die objekt-relationalen Konzepte
Erweiterung des relationalen Modells um
●
LOBs (große Objekte)
●
mengenwertige Attribute
●
geschachtelte Relationen (Attribute, die Relationen sind)
●
benutzerdefinierte Datentypen
●
Referenzen
●
Objektidentität (nötig für Referenzen)
●
Pfadausdrücke (nötig für Referenzen)
●
Vererbung (Datentypen und Relationen)
●
Zuordnung von Operationen, dazu Erweiterungen von SQL und
Programmierschnittstellen des DBMS zu anderen Programmiersprachen
Seite 32
14 Erweiterbare und objekt-relationale Datenbanken
Teil der SQL:1999 Standardisierungsbemühungen
14.2 Large Objects (LOBs)
Dienen der Speicherung großer Rohdatenmengen, währen früher in separaten Dateien
gespeichert worden
Arten:
●
CLOB (Character Large Object, TEXT in MySQL)
●
BLOB (Binary Large Object)
●
NCLOB (National Character Large Object, Texte mit multi-byte Zeichen)
derzeit übliche LOB-Größen bis 2 oder 4 GB
LOB-Daten können und sollten so gespeichert werden, dass sie „abseits“ der häufig
verwendeten Attribute gespeichert werden
Zugriff auf LOB-Daten über Locator, Operationen auf LOBs werden vom DBMS nicht
sofort ausgeführt, sondern nur so repräsentiert „als ob“, erst wenn eine Ausführung
einer Operation unumgänglich ist, wird diese wirklich durchgeführt
14.3 Distinct Types: Einfache benutzerdefinierte Datentypen
Distinct Types: quasi typedefs mit strikter Typprüfung, Aliasnamen für eingebaute
Datentypen, die semantisch falsche Verwendung verhindern
create distinct type NotenTyp as decimal(3,2) with comparisons;
Vergleich von NotenTypen untereinander ist möglich, aber kein Vergleich mit anderen
decimal(3,2)-basierten Typen
dafür expliziter Cast notwendig:
... cast(Vordiplom.Note to decimal(3,2)) ...
noch keine Operationen auf NotenTyp definiert (Standardfunktionen für decimals auch
nicht anwendbar), also:
create function NotenDurchschnitt(NotenTyp) returns NotenTyp source avg(decimal());
Erzeugung eines NotenTyp-Wertes durch expliziten Konstruktor-Aufruf:
... NotenTyp(1.00) ...
Definition eigener Operationen auch sinnvoll bei Typen mit
vergleichbarer/äquivalenter Semantik aber anderem Wertebereich (z.B.
Temperaturangaben in Celsius, Fahrenheit, Kelvin; Zensuren in deutscher und
englischer Notation)
einfache Konvertierungsfunktionen dafür direkt in SQL, komplexere Funktionen in
externen Programmen realisiert
14.4 Table Functions
externe Funktionen, welche ganze Relationen als Ergebnis liefern, z.B. sehr hilfreich,
um „fremde“ Datenquellen an das DBMS anzubinden
14 Erweiterbare und objekt-relationale Datenbanken
Seite 33
14.4.1 Nutzung einer Table Function in Anfragen
Table Function „Biographien“ durchsucht das WWW nach Biographien zu gegebenem Professor und liefert Tabelle zurück.
select prof.Name, bio.URL, bio.Ranking from Professoren as prof, table(Biographien(prof.Name)) as bio where bio.Sprache = 'deutsch' order by prof.Name, bio.Ranking;
14.4.2 Implementierung einer Table Function
Buch Seite 400
14.5 Benutzerdefinierte strukturierte Objekte
„structs“ in SQL:
create or replace type ProfessorenTyp as object (
PersNr number,
Name varchar(20),
Rang char(2),
Raum number,
member function Notenschnitt return number,
member function Gehalt return number
);
...
create or replace type body ProfessorenTyp as
member function NotenSchnitt return number is
begin
/* blah */
end;
member function ...
end;
Professoren-Tabelle erstellen:
create table ProfessorenTab of ProfessorenTyp (PersNr primary key);
Verweise mit ref:
create or replace type VorlRefListenTyp as table of ref VorlesungenTyp;
create or replace type VorlesungenTyp as object (
...
gelesenVon ref ProfessorenTyp;
Voraussetzungen ref VorlRefListenTyp;
...
);
14.6 Geschachtelte Objekt-Relationen
„richtige“ Schaltelung von Objektrelationen (fehlendes „ref“!), bei 1:N-Beziehungen
sinnvoll:
Seite 34
14 Erweiterbare und objekt-relationale Datenbanken
create or replace type PrüfungenTyp as object ( ... );
create or replace type PrüfungsListenTyp as table of PrüfungenTyp;
create or replace type Studenten as object (
...
absolviertePrüfungen PrüfungsListenTyp;
...
);
...
14.7 Vererbung von SQL-Objekttypen
SQL:1999 definiert Einfachvererbung
create type AngestelltenTyp as (
PersNr int,
Name varchar(2))
instantiable /* nicht instantiable wäre abstrakte Klasse */
ref using varchar(13) for bit data /* ID wird extern gesetzt */
mode DB2SQL;
create type ProfessorenTyp under AngestelltenTyp as (
Rang char(2),
Raum int) mode DB2SQL;
create type AssistentenTyp under AngestelltenTyp as (
Fachgebiet varchar(20),
Boss ref ProfessorenTyp) mode DB2SQL;
create table AngestelltenTab of AngestelltenTyp (ref is OID user generated); /* AngestelltenTab ist KEINE Typextension! Sondern „normale“ Tabelle */
14.8 Komplexe Attributtypen
Man kann halt Attribute vom Typ bestimmter Objekte anlegen und dann auch Objekte
von Subtypen dort eintragen.
15 Deduktive Datenbanken
Erweiterung relationaler Datenbanken um eine Deduktionskomponente, basierend auf
Prädikatenlogik erster Ordnung
15.1 Terminologie
●
extensionale Datenbasis (EDB) = explizit gespeicherte Datenbankausprägung,
„normale“ Datenbasis
●
Deduktionskomponente = Menge von Herleitungsregeln in der Sprache DataLog
●
intensionale Datenbasis (IDB) = Menge von mit der Deduktionskomponente aus der
EDB hergeleiteten Relation / Relationsausprägung
Analogie zwischen herkömmlichen SQL-Datenbanken und deduktiven Datenbanken:
●
Basisrelationen <=> EDB
●
Sichten = IDB
15 Deduktive Datenbanken
Seite 35
15.2 Datalog
Angelehnt an Prolog (Data + Prolog = Datalog), Programm besteht aus Regeln der
Form:
sokLV(T, S) :­ vorlesungen(V, T, S, P), professoren(P, „Sokrates“, R, Z), >(S, 2)
definiert ein Prädikat bzw. eine Relation sokLV, Ausprägung definiert durch folgenden
relationalen Domänenkalkül-Ausdruck:
{[ t ,s ] ∣ ∃ v , p [ v , t ,s , p ]∈ Vorlesungen ∧
∃ n , r ,z [ p, n , r , z ]∈ Professoren∧
n =Sokrates ∧ s2 }
Regelgrundbausteine atomare Formeln der Art q A1 , , A m
Dabei q Name einer (abgeleiteten oder Basis-)Relation oder eingebautes Prädikat wie
>, <, =, usw.
Ai sind Variablen oder Konstanten
Allg. Form:
p X1 , ... , Xm:−q1 A11 , ... , A1m1 ,... , qn An1 , ... , Anmn
p = Kopf, rechte Seite = Rumpf, q i auf rechter Seite auch als „Subgoals“ bezeichnet
Bedeutung:
Wenn q1 und q2 und q3, ..., dann auch p (Hornklausel)
q 1∧q 2∧∧g n p bzw. ¬q1 ∨¬q 2∨∨¬gn ∨ p
IDB-Prädikat p besteht i.A. aus mehreren Regeln mit Kopf p(...) (Wie Prolog oder
Haskell)
Beispiel: Buch Seite 418
15.3 Eigenschaften von Datalog-Programmen
15.3.1 Rekursivität
Charakterisierung der Rekursivität durch Abhängigkeitsgraph:
●
jedes Prädikat ein Knoten im Graphen
●
gerichtete Kanten vom jedem Subgoal jeder Regel zu dem Kopf dieser Regel, falls
noch keine Kante existent
●
Programm ist rekursiv gdw. Graph zyklisch ist (klar)
●
Zyklus kann beliebig viele Knoten haben (indirekte Rekursion)
15.3.2 Sicherheit von Datalog-Regeln
Regeln können „unsicher“ sein, z.B. ungleich X , Y :− X ≠ Y
Probleme können auftreten, wenn
●
in Subgoals nur eingebaute Prädikate auftreten oder
●
im Kopf eine Variable auftritt, die im Körper nicht vorkommt.
Begriff der Eingeschränktheit einer Variablen X in einer Regel:
Seite 36
15 Deduktive Datenbanken
●
Variable kommt in min. einem nicht-eingebauten Prädikat in Rumpf der Regel vor
oder
●
ein Prädikat der Form X = c mit einer Konstanten c kommt im Rumpf vor oder
●
ein Prädikat der Form X = Y kommt im Rumpf vor und Y ist eingeschränkt.
Eine Regel ist sicher, wenn alle Variablen eingeschränkt sind.
15.4 Auswertung von nicht-rekursiven Datalog-Programmen
15.4.1 Auswertung eines Beispielprogramms
Vorgehensweise: (Buch Seite 420 ff.)
1. Abhängigkeitsgraph bilden
2. topologische Sortierung bilden, bestimmt dadurch, dass jeder Knoten nach den
Knoten einsortiert wird, von denen er abhängt (nicht eindeutig, aber bei nichtrekursiven Datalog-Programmen immer möglich)
3. Für jede Regel mit dem Kopf p(...) Relation bilden, in der alle Variablen des Körpers
als Attribute vorkommen. Diese wird im wesentlichen durch den natürlichen
Verbund der Relationen Q1, ..., Qn, die den Relationen der prädikate q1, ..., qn
entsprechen gebildet. (Benötigte Relationen aufgrund der Sortierung bereits
berechnet.)
4. Für alle Regeln mit p(...) als Kopf projiziere die Relation der rechten Seite auf die
vorkommenden Attribute und vereinige alle Relationen.
(...)
15.4.2 Auswertungs-Algorithmus
Siehe Beispiel 15.4.1
15.7 Top-Down-Auswertung
Wir fangen mit der Regel an, für die wir die Hülle bestimmen wollen. BEISPIEL: Wir
suchen alle (!) Vorgänger einer Vorlesung, auch über mehrere Ebenen.
Dazu suchen wir alle Regeln heraus, deren linke Seite eines der Teile der rechten Seite
unserer Ausgangsregel ist. Für all diese Regeln machen wir nun das gleiche, bis wir
keinen neuen Regeln mehr hinzubekommen.
So finden wir rekursiv alle Vor-vor-vor-(...)gänger einer Vorlesung.
15.8 Negation im Regelrumpf
15.8.1 Stratifizierte Programme
Stratifizierte Programme sind die Programme, bei denen sich alle negierten Literale
vollständig materialisieren lassen, bevor sie für die Auswertung weiterer Regeln
benötigt werden.
Negierte Literale helfen nicht bei der Einschränkung von Variablen.
15.8.2 Auswertung von Regeln mit Negation
Wenn wir 2 Literale haben, eines davon negiert, können wir
●
wenn beide das gleiche Schema haben, einfach die Differenz bilden
15 Deduktive Datenbanken
Seite 37
●
bei verschiedenen Schemata muss der JOIN mit dem Komplement gebildet werden.
Um unsichere Ausdrücke zu vermeiden bildet man die Domäne DOM der Datenbank
durch Vereinigung aller vorkommenden Konstanten und Werte aller Relationen. Es
werden nur Tupel des Komplementes betrachtet, die aus in DOM enthaltenen
Werten bestehen. [Für das Komplement wirft man alle in der Datenbank
vorkommenden Werte und Konstanten in einen Topf namens DOM und holt die in
der Tabelle vorkommenden Werte wieder raus.]
15.9 Ausdruckskraft von Datalog
Datalog¬non−rec , definiert als Datalog mit Negation und ohne Rekursion, hat genau die
gleiche Ausdruckskraft wie die relationale Algebra, relationales Domänen- und
Tupelkalkül, mit Rekursion sehr viel ausdrucksstärker (Definition der transitiven Hülle
der Voraussetzen-Relation möglich)
Umwandlung von nicht-rekursiven Datalog mit Negation in Relationenalgebra bereits
gezeigt.
Umgekehrte Richtung:
Selektion: kann einfach in Datalog-Regel formuliert werden: SWS3 Vorlesungen =
query(V,S,R) :­ vorlesungen(V,T,S,R), S>3
Konstanten direkt in den Rumpf schreiben:
query(V,S,R) :­ vorlesungen(V,T,3,R)
Projektion: Einfaches Weglassen von Variablen:
query(Name, Rang) :­ professoren(PersNr, Name, Rang, Raum)
Kreuzprodukt und Join: Titel , Name Vorlesungen xx gelesenVon= PersNr Professoren
entspricht
query(T, N) :­ vorlesungen(V, T, S, R), professor(R, N, Rg, Ra)
=> Join erfolgt über Verwendung derselben Variablen, hier R.
Kreuzprodukt durch Verwendung paarweise verschiedener Variablen:
query(V1, V2, V3, V4, P1, P2, P3, P4) :­ vorlesungen(V1, V2, V3, V4), professoren(P1, P2, P3, P4)
( Vorlesungen × Professoren )
Vereinigung: PersNr , Name Assistenten ∪ PersNr ,Name Professoren wird in Datalog
zu zwei Regeln:
query(PersNr, Name) :­ assistenten(PersNr, Name, F, B)
query(PersNr, Name) :­ professoren(PersNr, Name, Rg, Ra)
Projektion in einem erschlagen.
Mengendifferenz: Notwendig: Negation von Subgoals im Rumpf
VorlNr Vorlesungen − Vorgänger Voraussetzen
in Datalog:
vorlNr(V) :­ vorlesungen(V, T, S, R)
grundlagen(V) :­ voraussetzen(V, N)
query(V) :­ vorlNr(V), ¬ grundlagen(V)
16 Verteilte Datenbanken
verteilte Datenbankverwaltungssysteme (VDBMS)
Seite 38
16 Verteilte Datenbanken
16.1 Terminologie und Abgrenzung
VDB: „Sammlung von Informationseinheiten, die auf mehreren durch ein
Kommunikationsnetz verbundenen Rechnern verteilt sind“, jede Station kann auf
„ihren“ Daten lokal autonom arbeiten, nimmt aber zusätzlich an einer globalen
Aufgabe teil (VDBMS: Kooperation von transparent verbundenen lokalen Stationen, im
Ggs. zu Client/Server-Architektur = „degeneriertes VDBMS“)
16.2 Entwurf verteilter Datenbanken
(Schema im Buch S. 445)
●
globales Schema: „konsolidiertes relationales Implementationsschema des
zentralisierten Datenbankentwurfs“ => eigentlicher VDMBS-Entwurf bei
Fragmentierungs- und Zuordnungsschema
●
Fragmentierungsschema: Zerlegung von Relationen in weitgehend disjunkte
Fragmente auf Grundlage des Zugriffsverhaltens darauf (Zusammenfassung von
Daten mit ähnlichem Zugriffsmuster)
●
●
horizontale Fragmentierung: Zerlegung der Relationen in disjunkte Tupelmengen
●
vertikale Fragmentierung: Zerlegung der Relationen durch Projektion in neue
Relationen mit (weitgehend) disjunkten Attributmengen
●
kombinierte Fragmentierung: beides auf einer Relation
Zuordnungs-/Allokationsschema: Verteilung der Fragmente auf die einzelnen
Arbeitsstationen
●
redundanzfrei: kein Fragment doppelt
●
mit Replikation: einige Fragmente werden auf mehreren Stationen gespeichert
Ein dem Knoten S i zugeordnetes Fragment wird Rij bezeichnet.
Gute Zuordnung bei an mehreren Stationen verwendeten Fragmenten schwieriges
Problem, Ansätze zur globalen Kostenoptimierung nur auf kleine Anwendungsfälle
anwendbar => Einsatz von Heuristiken mit guten aber suboptimalem Ergebnis
Alternativ Redundanz, hilft aber nur bei Leseoperationen und verkompliziert
Schreiboperationen.
nach Fragmentierung Modellierung des lokalen Schemas für jede Station
16.3 Horizontale und vertikale Fragmentierung
Grundlegende Korrektheitsanforderungen:
1. Rekonstruierbarkeit (der Originalrelation aus den Fragmenten)
2. Vollständigkeit (es gehen keine Tupel verloren)
3. Disjunktheit (keine Überlappung)
Bei vertikaler Fragmentierung Abstriche an Disjunktheit zugunsten einfacher
Rekonstruierbarkeit.
16.3.1 Horizontale Fragmentierung
Zerlegung mittels Zerlegungsprädikaten:
●
1 Prädikat p
1
16 Verteilte Datenbanken
Seite 39
R 1 := p R
R 2 := ¬p R
1
1
●
Bei zwei Prädikaten ergeben sich entsprechend 4 Zerlegungen usw.
=> bei n Prädikaten max. 2n Fragmente, können allerdings leere dabei sein
16.3.2 Abgeleitete horizontale Fragmentierung
[Zerlegung der Tabelle A durch Join in Tabelle B nachschlagen]
oft sinnvoll, eine Relation abhängig von der Zerlegung einer anderen Relation
aufzuteilen
Beispiel: Professorentabelle zerlegt nach Fakultäten und Vorlesungstabelle, sollte auch
nach Fakultäten zerlegt werden um effiziente Anfragen zu ermöglichen, aber Fakultät
nicht Bestandteil der Vorlesungstabelle
Zerlegung per Semi-Join: InfoVorl :=Vorlesungen leftsemijoin gelesenVon= PersNr InfoProfs
Anfrage dann per
Titel , Name InfoProfs ' xx p InfoVorls∪ PhysikProfs xx p PhysikVorls ∪... mit
p≡PersNr =gelesenVon
=> zu erwartende Anfragen müssen beim DB-Entwurf berücksichtigt werden
16.3.3 Vertikale Fragmentierung
Zusammenfassung von Attributen mit ähnlichen Zugriffsmustern
Rekonstruierbarkeit durch Replikation des Primärschlüssels in jedem Fragment oder
durch Zuweisung eines eindeutigen Tupelidentifikators zu jedem Tupel, welcher mit
jedem Fragment repliziert wird (künstlicher Schlüssel)
zusätzlich hat sich gezeigt, dass selten geänderte Attribute sinnvollerweise in mehrere
Fragmente aufgenommen werden können/sollten (VDBMS muss Konsistenz bei
Änderungen sicherstellen)
Aufteilung der Professoren-Tabelle z.B. in für Uni-Verwaltung und für Lehre und
Forschung relevante Attributbereiche
Rekonstruktion durch Join über Primärschlüssel
16.3.4 Kombinierte Fragmentierung
beide Fragmentierungsarten lassen sich natürlich kombinieren, Rekonstruktion durch
Join und anschließende Vereinigung
16.3.5 Allokation für unser Beispiel
Fragmente dann sinnvoll auf die Rechner verteilen, je nach dort laufenden
Anwendungen
16.4 Transparenz in verteilten Datenbanken
wird erreicht durch das Speichern von PNG-Grafiken mit Alpha-Kanal
3 Stufen der Transparenz
Seite 40
16 Verteilte Datenbanken
16.4.1 Fragmentierungstransparenz
Idealsituation: Arbeit mit dem globalen Datenbankschema, Aufteilung auf
Einzelstationen völlig transparent für Benutzer.
16.4.2 Allokationstransparenz
Fragment mit den gewünschten Daten muss bekannt sein, aber nicht dessen Ort im
VDB-System.
Fragmente müssen bei Anfragen explizit angegeben werden und bei notwendiger
Rekonstruktion von Teilen der Originaltabellen muss dies manuell geschehen.
Auch Aufgabe des Benutzers, bei Datenänderungen ein Tupel in ein passendes neues
Fragment „umzuziehen“.
16.4.3 Lokale Schema-Transparenz
Es muss auch der Rechner bekannt sein, auf dem die Daten liegen. „Transparenz“ nur
noch in dem Sinne, dass der Zugriff auf die Daten gleich ist (Datenmodell,
Anfragesprache) (wäre z.B. bei Mischung von verschiedenen DBMSen auf den
einzelnen Stationen nicht gegeben)
Koppelung heterogener Datenbanksysteme kann sehr schwierig, in der Realität
allerdings manchmal notwendig sein
16.5 Anfrageübersetzung und -optimierung in VDBMS
16.5.1 Anfragebearbeitung bei horizontaler Fragmentierung
Bei Joins horizontal fragmentierter Relationen müssen normalerweise die Daten aller
Fragmente auf den joinenden Rechner kopiert werden. Dies kann man sich genau dann
ersparen, wenn die Daten von Relation A bereits nach einem Attribut aus Relation B
fragmentiert ist. („abgeleitete Fragmentierung“)
BEISPIEL: Die Professoren-Tabelle ist nach Fakultät der Professoren aufgeteilt, obwohl
diese Information gar nicht der Professorentabelle steckt.
16.5.2 Anfragebearbeitung bei vertikaler Fragmentierung
Einfach nur die Relationsfragmente betrachten, die für den Join benötigt werden.
16.6 Join-Auswertung in VDBMS
16.6.1 Join-Auswertung ohne Filterung
1. Nested Loops:
Für jedes Tupel in R die zugehörigen Tupel in S nachschlagen.
Vorraussetzung: Guter Index auf S, da viele Einzelanfragen; gutes Netzwerk.
2. Transfer einer Argumentrelation:
R zu S kopieren, dort joinen. Feddich.
3. Transfer beider Argumentrelationen:
beide Relationen auf den Join-Rechner kopieren, dort joinen. Indizes gehen verloren,
Sortierungen nicht.
16 Verteilte Datenbanken
Seite 41
16.6.2 Join-Auswertung mit Filterung
So, wie man es sinnvollerweise machen würde:
ID
P
P
1
1
1
2
1
3
2
4
99
5
99
6
99
7
ID
P
1
1
1
2
Zuerst die Schlüsselspalte von S nach R kopieren, die zutreffenden Tupel nach R
zurückkopieren, den Join dann zum Zielrechner kopieren.
Das Ganze macht natürlich nur dann Sinn, wenn die Kopieraktionen R-->S und S-->R
zusammen weniger Datentransfer benötigen, als die Relation S groß ist. Sonst würde
man einfach die Relation S zu R kopieren, dort joinen, und das Ergebnis auf den
Zielrechner kopieren.
Noch eine Alternative: R und S tauschen nur Schlüsselinformationen aus, und schicken
beide die jeweils für den Join benötigten Daten an den Zielrechner.
Seite 42
16 Verteilte Datenbanken
16.7 Transaktionskontrolle in VDBMS
Problem: COMMIT muss insgesamt atomar ablaufen, d.h. überall gleichzeitig.
2-Phasen-Sperrprotokoll:
1. Koordinator --> Agents: PREPARE: „Garantierst Du erfolgreichen commit?“
2. Agents --> Koordinator: READY: „Ja, kann ich garantieren. Daher verändere ich
jetzt erstmal keine dieser Daten und warte auf dich.“
(oder FAILED)
3. Koordinator --> Agents: (wenn alle READY gesagt haben):
COMMIT „OK, dann macht mal.“ (sonst: „Kommando zurück – ABORT.“)
4. Agents --> Koordinator: ACK: „OK, wir sind fertig.
5. Wenn ein Rückläufer fehlt, wiederholt der Koordinator die COMMIT-Anfrage an
diesen.
Mögliche Probleme hierbei:
●
Absturz des Koordinators nach / während PREPARE:
Alle Agents, die PREPARE erhalten haben und READY geschickt haben, dürfen bis
zu COMMIT oder ABORT nichts mehr machen, da sie garantiert haben, COMMITen
zu können.
●
Absturz eines Agenten:
Dieser schaut nach dem Wiederhochfahren in seine LOG-Datei, mit was er bereits
fertig war:
„READY geschickt“: „Koordinator, wurde die Transaktion ausgeführt?“ „Ja,
COMMIT“ / „Nein, Abort“
„COMMIT empfangen“: Transaktion durchführen, ohne nachzufragen.
„COMMIT durchgeführt, aber kein ACK geschickt“: ACK schicken.
●
verlorengegangene Nachricht:
... vom Agenten: Koordinator abortet
... vom Koordinator: „Erinnerungen“ schicken.
(wichtig, da sonst Agent handlungsunfähig ist, sobald er READY geschickt hat.)
16.8 Mehrbenbutzersynchronisation in VDBMS
vermutlich nicht relevant
16.10 Synchronisation bei replizierten Daten
Problem: wenn man erst ALLE Kopien schreiben muss, damit man weitermachen kann,
kann das ein Problem sein, wenn eine Datenbank gerade nicht verfügbar ist.
Wenn man NICHT alle Kopien erst schreiben muss, bekommt man jedoch
Inkonsistenzen.
Lösung als Kompromiss: Die Schreiboperationen müssen mindestens 51% der
Datenbanken aktualisiert haben, inkl. einem Timestamp. Dann ist gewährleistet, dass
eine Leseoperation, die mind. 50% aller Datenbanken befragt, mindestens einen
aktuellen Datensatz (den neuesten!) bekommt.
16 Verteilte Datenbanken
Seite 43
Statt „50% der Datenbanken“ kann man auch den Datenbanken Wertigkeitspunkte
geben, und dann so viele Datenbanken abfragen, dass man mindestens 50% der
Wertepunkte abgedeckt hat.
Seite 44
16 Verteilte Datenbanken
