Zusammenfassung - Hu

Prüfungsvorbereitung
DBS I
Grundlagen von Datenbanksystemen
Niels Lohmann
Wintersemester 2004/2005
nlohmann@informatik.hu-berlin.de
http://www.informatik.hu-berlin.de/∼nlohmann
Inhaltsverzeichnis
1. Architektur und Eigenschaften
1.1. Eigenschaften . . . . . . .
1.2. Transaktionen . . . . . . .
1.3. Vor- und Nachteile . . . .
1.4. Architektur . . . . . . . .
von Datenbanksystemen
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
2. Das
2.1.
2.2.
2.3.
2.4.
Entity-Relationship-Modell
Entwurfsprozess . . . . . . .
Definitionen . . . . . . . . .
Grafische Darstellung . . .
Vor-/Nachteile . . . . . . .
3. Das
3.1.
3.2.
3.3.
3.4.
3.5.
Relationenmodell
Regeln . . . . . . . . . . . . . . . . . . . . . .
Definitionen . . . . . . . . . . . . . . . . . . .
Schlüssel . . . . . . . . . . . . . . . . . . . . .
Grundsätzliche Eigenschaften von Relationen
Konvertierung von ER-Diagrammen . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
4
5
5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
7
8
8
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10
10
10
11
11
11
4. Entwurf relationaler Datenbanken
4.1. Funktionale Abhängigkeiten (FDs) . . . .
4.2. Armstrong-Kalkül . . . . . . . . . . . . .
4.3. Algorithmen . . . . . . . . . . . . . . . . .
4.4. Zerlegungen . . . . . . . . . . . . . . . . .
4.5. Normalformen . . . . . . . . . . . . . . . .
4.6. Zusicherungen und Integritätsbedingungen
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12
12
12
13
13
14
15
5. Relationale Anfragesprachen
5.1. Relationale Algebra . .
5.2. Relationenkalkül . . . .
5.3. Domänenkalkül DRC . .
5.4. Tupel-Kalkül TRC . . .
5.5. Datalog . . . . . . . . .
5.6. QBE . . . . . . . . . . .
5.7. SQL . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
17
19
20
21
22
22
22
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Inhaltsverzeichnis
3
6. Anfragebearbeitung in relationalen Datenbanksystemen
6.1. Einführung . . . . . . . . . . . . . . . . . . . . . . .
6.2. Optimierungsregeln . . . . . . . . . . . . . . . . . . .
6.3. Joins . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4. Views . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
24
24
24
25
26
7. Speicherstrukturen für Datenbanken
7.1. Sequentielle Datei . . . . . . . .
7.2. Index-Sequentielle Datei . . . . .
7.3. B-Baum . . . . . . . . . . . . . .
7.4. B*-Baum . . . . . . . . . . . . .
7.5. Hashing . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
28
28
28
29
29
29
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8. XML
31
A. Prüfungsfragen
A.1. Entity-Relationship-Modell
A.2. Funktionale Abhängigkeiten
A.3. Normalformen . . . . . . . .
A.4. Relationale Algebra . . . .
A.5. SQL . . . . . . . . . . . . .
A.6. Joins . . . . . . . . . . . . .
A.7. B-Bäume . . . . . . . . . .
A.8. XML . . . . . . . . . . . . .
A.9. Transaktionen . . . . . . . .
32
32
32
32
32
33
33
33
33
34
DBS I – Grundlagen von Datenbanksystemen
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25. Februar 2005
1. Architektur und Eigenschaften von
Datenbanksystemen
1.1. Eigenschaften
• Informationen (inhaltliche Form des Wissens) und Daten (Materialisierung der
Information)
• Definition eines Datenbanksystems (DBS)
– Datenbank (DB): zu speichernde Daten und Metadaten
– Datenbankmanagementsystem (DBMS): Softwarekomponente zum Zugriff auf
die Datenbank (effizient, sicher)
– Datenbanksystem: DB+DBMS
• DB-Sprache
– Data Definition Language (DDL): Datendefinition
– Data Manipulation Language (DML): Datenmanipulation und Datenzugriff
– Zugangskontrolle
– Sprachen sind meist deklarativ, d.h. das wie“ tritt in den Hintergrund
”
• Zugangskontrolle
• Datenintegrität: Wahrung der Datenkonsistenz und -korrektheit
• Robustheit: Wahrung eines konsistenten Zustandes trotz Fehler etc.
• Zugriffskoordination bei mehreren Datenbankbenutzern
• Effizienter Datenzugriff und Datenmanipulation
1.2. Transaktionen
• ACID-Prinzip
– Atomicity: Unteilbarkeit ( alles oder nichts“)
”
– Consistency: Konsistenz (Eine Transaktion überführt die Datenbank von einem konsistenten Zustand in einen anderen.)
Kapitel 1. Architektur und Eigenschaften von Datenbanksystemen
5
– Isolation: (bei Mehrbenutzerbetrieb führt die Transaktion ihre Aktionen so
aus, als ob sie alleine auf der DB arbeitet.)
– Durability: Dauerhaftigkeit (Die Wirkung einer abgeschlossenen Transaktion
bleibt dauerhaft — auch trotz eventueller Fehler und Ausfälle des Systems —
in der Datenbank erhalten.)
• Aufbau: BEGIN_TA, COMMIT_TA, ABORT_TA
• Im Fehlerfalle müssen Transaktionen zurückgesetzt werden (wegen Atomicity). Dabei müssen zuletzt gültige Versionen wiederhergestellt werden. Fehlererholungskomponente im DBS notwendig.
• Probleme
– Lost-Update Problem: Während eines Updates wird eine zuvor gelesene Variable von einer anderen Transaktion verändert. Beispiel: Statt zweimal Geld
auf einem Konto zu erhöhen (neuer Werte = alter Wert + 1000) geht zweite
Aktualisierung verloren.
– Inconsistent-Read: Während eines Updates wird eine geänderte Variable von
einer anderen Transaktion gelesen, d.h. es wird Aktion auf alten und neuen
Daten ausgeführt. Beispiel: Während Überweisung von einem Konto auf ein
anderes könnte Geld doppelt“ gezählt werden.
”
• Da Überlappung Probleme bereitet, muss diese kontrolliert werden: Schedule, Serialisierbarkeit, Concurrency Control
1.3. Vor- und Nachteile
+ weite Unterstützung
+ Vereinfachung der Anwendungsprogrammierung
+ Möglichkeiten des Datenschutzes
− erhöhter Betriebsmittelbedarf/Kosten
− eine weitere Programmiersprache“
”
1.4. Architektur
Standard ANSI/X3/SPARC
• externe Schicht: Sicht des Anwendungsprogramms auf nur notwendige/wichtige
Daten; Objekt: View
• konzeptuelle Schicht: Gesamtheit aller gespeicherten Daten, wird definiert durch
das Datenmodell (unabhängig von der internen Repräsentation); Objekt: Relation
DBS I – Grundlagen von Datenbanksystemen
25. Februar 2005
Kapitel 1. Architektur und Eigenschaften von Datenbanksystemen
6
• interne/physische Schicht: Wo und wie sind die Daten gespeichert? Sequentielle
Dateien/Indexdateien; Objekt: Datei
DBS I – Grundlagen von Datenbanksystemen
25. Februar 2005
2. Das Entity-Relationship-Modell
2.1. Entwurfsprozess
1. systematische Analyse ; Anforderungen
Was sind die relevanten Objekte, deren Eigenschaften und Zusammenhänge?
2. konzeptueller Datenbankentwurf ; konzeptuelles Schema (meist ERM)
Wichtig zur Kommunikation und zur Überprüfung der 1. Schrittes.
3. Überführung des Schemas in DB-Schema ; konzeptuelles DB-Schema
Abbildung des entworfenen konzeptuellen Schemas in ein konkretes DB-Modell
und ein konkretes DBMS
4. physikalischer DB-Entwurf ; internes Schema
Schlüsseldefinitionen, Operationen/Transaktionen auf den Relationen
2.2. Definitionen
• Entity: Gegenstand, Repräsentant für die Objekte der realen Welt
– Attribute: Eigenschaften der Entitäten
– jede Entität besitzt Werte für seine Eigenschaften
– Attributtypen: atomar/einfach, zusammengesetzt, mehrwertig
– Entitytypen (Entity, Schlüssel, schwach)
• Relationship: Beziehung, semantischer Zusammenhang zwischen Entitäten
– Grad: Anzahl der beteiligten Enititätstypen
– Rolle: z.B. Manager/Chef vs. Arbeiter
– Kardinalitätsverhältnis: mögliche Anzahl der an einer Beziehung beteiligten
Gegenstände (1:1, 1:n, m:n, etc.)
– Beteiligungseinschränkung (total, partiell)
• Generalisierung, Spezialisierung, IS-A Beziehung
– Einschränkung für die Generalisierung: Disjointness/Overlapping-Bedingung
– Einschränkung für die Generalisierung: Completeness/Incompleteness
• Wichtig: Unterscheidung zwischen Entitätstyp/Relationship (Schema) und Entität/Relationship-Instanz (Instanz)
Kapitel
2. Das Entity-Relationship-Modell
holger@kreissl.info
8
Das ER-Modell
2.3. Grafische Darstellung
Entity
Attribut
Mehrwertiges Attribut
Schlüsselattribut
Zusammengesetztes Attribut
T oder P
Relationship
T oder P
IS-A Beziehung disjunkt und nichtdisjunkt (Total und Partiell)
Abbildung entnommen aus dem Skript DBMS-Einführung“ von Holger Kreißl
”
(http://www.kreissl.info/diggs/db 01.php.)
2.4. Vor-/Nachteile
Rekursive Beziehung
• Modellierungshilfe:
– Erkennen und Zusammenfassen von Objekten zu Entitäten durch Abstraktion
„Eine Einzelobjekten
Relation entspricht einem
Entity-Set“
Vossen
Seite Die
115 unten
von
zu einer
Entität
(z.B.
Kollegen Fritz Maier und Paul
Eine Relation ist partiell, wenn sie partielle Tupel enthält, d.h. nicht jedes Attribut einen Wert haben
Lehmann
und viele weitere zu der Entität Angestellter“).
muß.
”
•– Erkennen
Datenabhängigkeiten
sind semantischer Natur
und Beziehungen
müssen zusätzlichzwischen
betrachtet werden.
und Zusammenfassen
von
je zwei Objekten
• Entity Integrität ist die Forderung, daß Nullwerte auf Attribute ausgeschlossen werden.
zu
einem
Relationship
(z.B.
der
Angestellte
Paul
Lehmann
leitet
das Projekt
• Intraregionale Abhängigkeiten beziehen sich nur auf eine Attributmenge.
desAttribute
Betriebsklimas
der aus
Angestellte
Fritzzusammengesetzt
Maier leitet das
• Verbesserung
1NF bedeutet, daß alle
elementar sindund
und nicht
Sets oder Mengen
sind,
Projekt
Effizienzsteigerung in der Verwaltung). Dies führt zu dem Relationship Angestellter leitet Projekt“.
”
Transformation
des ERD
ins Relationenmodelld.h. der Häufigkeit des Auftretens (z.B. wird
– Bestimmung
der Kardinalitäten,
Projekt
immer von
genau
Angestellten
geleitet
und eininAngestellter
Das ein
„flache“
Relationenmodell
erlaubt
keineeinem
zusammengesetzten
Attribute
und Relationen
1NF.
darf höchstens drei Projekte leiten.)
•
•
• implementationsunabhängig
DBS ITU-Chemnitz
– Grundlagen von Datenbanksystemen
9 von
30
25. Seite
Februar
2005
Kapitel 2. Das Entity-Relationship-Modell
9
• es fehlen Operationen (dynamische Modellierung)
DBS I – Grundlagen von Datenbanksystemen
25. Februar 2005
3. Das Relationenmodell
3.1. Regeln
• Jede Relation ist eine zweidimensionale Tabelle und entspricht einem Entity-Typ.
• Jede Zeile dieser Tabelle wird Tupel genannt und beschreibt ein konkretes Entity
des Entity-Typs, den die Tabelle darstellt.
• Jede Spalte der Tabelle entspricht einem Attribut des Entity-Typs. Die konkreten
Entities werden somit durch die entsprechenden Attributwerte beschrieben.
• Der Grad einer Relation ist die Anzahl der Attribute.
• Existiert für ein Attribut eine begrenzte Anzahl von Attributwerten, so wird die
Zusammenfassung aller Attributwerte für dieses Attribut Domäne genannt.
• Die Existenz zweier identischer Zeilen ist ungültig.
• Es ist nicht relevant, in welcher Reihenfolge Zeilen bzw. Spalten der Tabelle angeordnet sind.
• Attribute sind atomar.
3.2. Definitionen
• Wertemengen: Domäne (intensional (Integer, String), extensional (Aufzählung))
D1 , . . . , Dn
• Relation R ⊆ D1 × . . . × Dn
• Attribut: Spalte einer Relation (eindeutig)
• Relationenschema: R(A1 : D1 , . . . , An : Dn ) (endliche Menge von Attribut(namen)
mit Domänen)
• Elemente der Relationen heißen Tupel (Abbildung von {A1 , . . . , An } nach D).
• Die Kardinalität einer Relation ist die Anzahl ihrer Elemente (Tupel).
• Extension: Menge der Instanzen (Tabelle)
• Datenbankschema: Menge von Relationenschemata (Menge von Tabellen)
• Sei R(A1 , . . . , An ) eine Relation und S ⊆ {A1 , . . . , An } eine Attributmenge. µ[S]
bezeichnet die Werte des Tupels µ in den Attributen S.
Kapitel 3. Das Relationenmodell
11
3.3. Schlüssel
• Schlüsselkandidat: Menge von Attributen K ⊆ {A1 , . . . , An }, die eindeutig und
minimal ist
• Primärschlüssel: vom Designer ausgezeichneter Schlüssel aus den Schlüsselkandidaten
• Superschlüssel: alle Mengen K 0 mit K ⊆ K 0 , K Schlüsselkandidat (eindeutig, aber
nicht minimal)
• Fremdschlüssel: Seien R und S Relationenschemata und KS ein Schlüsselkandiat
für S. Wenn KS in den Attributen von R enthalten ist, ist KS ein Fremdschlüssel
von S in R.
• Schlüsseleigenschaften sind Metainformationen, die nicht aus der Instanz hergeleitet werden können!
• Integritätsregeln
1. Eindeutigkeit von Schlüsseln
2. Referentielle Integrität: Sei KS Fremdschlüssel von S in R. Dann gilt für jede
Extension von S: µ1 ∈ R ⇒ ∃µ2 ∈ S mit µ2 [KS ] = µ1 [KS ].
Wikipedia: Die Datenbank stellt sicher, dass der Primärschlüssel existiert
”
und nur gemeinsam mit dem Fremdschlüssel geändert oder gelöscht werden
kann.“
3. Null“-freie Schlüsselwerte
”
3.4. Grundsätzliche Eigenschaften von Relationen
1. Relationen sind Mengen: es sind keine Duplikate erlaubt!
2. Tupel werden durch Attributwerte identifiziert: Das Relationenmodell (RM) ist
werteorientiert!
3. Es gibt keine Ordnung der Tupel innerhalb einer Relation: Reihenfolge ist irrelevant: keine first, next, last Operationen.
4. In der Tupel-als-Abbildung“-Auffassung (jedes Tupel ist Abbildung der Attribute
”
in die Domänen) gibt es keine Ordnung der Attribute.
5. Attributwerte sind atomar.
3.5. Konvertierung von ER-Diagrammen
siehe Praktikumsfolien
DBS I – Grundlagen von Datenbanksystemen
25. Februar 2005
4. Entwurf relationaler Datenbanken
• Kriterien für ein gutes“ konzeptuelles Schema
”
• Problem: Redundanz – dadurch Inkonsistenzen (Update-, Insert-, Delete-Anomalie)
• Ziel: Entwurf relationaler Datenbankschemata ohne Datenredundanz
4.1. Funktionale Abhängigkeiten (FDs)
• informale Definition: Werte einer Attributmenge bestimmen eindeutig eine andere
Attributmenge (P LZ → Ort)
• Definition: Sei F ein Relationsschema und X, Y ⊆ F . X → Y , falls für je zwei
Tupel t1 , t2 gilt: t1 [X] = t2 [X] ⇒ t1 [Y ] = t2 [Y ].
• X → X heißt triviale FD
• Funktionale Abhängigkeiten sind
– Aussagen über die Semantik der Daten, deshalb Metainformation (Schema)
– abgeleitet aus der Anwendungswelt ; a-priori-Wissen
– nicht beweisbar (!)
– nicht aus einer aktuellen DB-Instanz ableitbar
– Integritätsbedingungen
4.2. Armstrong-Kalkül
1. Reflexivität
X → X, bzw. X → Y , falls Y ⊆ X
2. Augmentation (Erweiterung)
aus X → Y folgt XZ → Y Z für jede Teilmenge Z ⊆ R
3. Transitivität
aus X → Y und Y → Z folgt X → Z
4. Vereinigung (Additivität)
aus X → Y und X → Z folgt X → Y Z
Kapitel 4. Entwurf relationaler Datenbanken
13
5. Pseudo-Transitivität
aus X → Y und W Y → Z folgt XW → Z
6. Zerlegung (Projektivität)
aus X → Y und Z ⊆ Y folgt X → Z
• Das Armstrong-Kalkül ist vollständig und korrekt bzgl. dem Ableitungsoperator |=,
d.h., alles mit den Deduktionsregeln hergeleitete ist korrekt, und alle FDs können
mit den Axiomen hergeleitet werden.
• Alle Deduktionsregeln können aus der Reflexivität, der Augmentation und der
(Pseudo-)Transitivität hergeleitet werden.
4.3. Algorithmen
• Hüllenberechnung
– Die Hülle von F ist die kleinste Menge, die alle FDs enthält, die mit dem
Armstrong-Kalkül abgeleitet werden können.
Definition: F + := {X → Y | F |= X → Y }
– Hüllenberechnung durch Aufzählung ist zu teuer (exponentiell in Attributanzahl)
– CLOSURE(X, F ): Gegeben eine Attributmenge X und eine Menge von FDs
F finden wir X + , die Hülle von X unter F in O(|F |2 · p). (p: Anzahl der
verschiedenen Attribute in F )
• minimale Überdeckung
– Grund: Laufzeit vieler Algorithmen hangt von |F | ab. Überwachung von FDs
kann bei kleinerer Menge effizienter gestaltet werden
– Ein Menge an FDs heißt genau dann minimal, falls jede FD von der Form
X → A ist (A ist Attribut), keine FD in F überflüssig ist und kein Attribut
auf der linken Seite einer FD überflüssig ist.
– Satz: Zu jeder Menge F gibt es eine minimale Überdeckung. Diese muss nicht
eindeutig sein.
4.4. Zerlegungen
• Bei Zerlegungen kann es zu Informationsverlust kommen. Beispiel: Originalrelation
enthält weniger Tupel als Natural Join der Zerlegung.
• Lossless-Join-Zerlegung: Test einer Zerlegung auf Informationsverlust
DBS I – Grundlagen von Datenbanksystemen
25. Februar 2005
Kapitel 4. Entwurf relationaler Datenbanken
14
• Beispiel Lossless-Join: Gegeben die Relation R(ABCD) mit den funktionalen Abhängigkeiten A → B, B → C und C → D. Für die Zerlegung R1 (AB), R2 (BC) und
R3 (CD) ergibt durch den Algorithmus sich die Tabellen (von links nach rechts):
R1
R2
R3
A
a1
b12
b13
B
a2
a2
b23
C
b31
a3
a3
D
b41
b42
a4
;
R1
R2
R3
A
a1
b12
b13
B
a2
a2
b23
C
a3
a3
a3
D
b41
b42
a4
;
R1
R2
R3
A
a1
b12
b13
B
a2
a2
b23
C
a3
a3
a3
D
a4
b24
a4
Da es eine Zeile der Form (a1 , a2 , a3 , a4 ) gibt, ist die Ausgabe des Algorithmus
true, d.h. es handelt sich um eine Lossless-Join-Zerlegung.
• abhängigkeitserhaltende Zerlegungen: alle Abhängigkeiten der Originalrelation gelten.
• Definition: Sei F eine Menge von FDs. Die Projektion von F auf Z ⊆ U ist definiert
als: πZ (F ) = {X → Y ∈ F + |X ∪ Y ⊆ Z}
• Definition: Sei R = {A1 , . . . , An } ein Relationenschema, ρ = {R1 , . . . , Rk } eine
ZerlegungSund F eine Menge von FDs über R. ρ erhält die Abhängigkeiten von F ,
falls gilt: ki=1 πRi (F ) ist äquivalent zu F .
• Bemerkung: Es gibt Lossless-Join Zerlegungen die nicht abhängigkeitserhaltend
sind und umgekehrt.
4.5. Normalformen
Definitionen:
• Definition: Ein Attribut heißt Primeattribut, wenn es Teil eines Schlüsselkandidaten
ist.
Normalformen:
• Erste Normalform (1NF)
Alle Attribute sind atomar.
• Zweite Normalform (2NF)
Kein Nicht-Primeattribut darf von einer echten Teilmenge eines Schlüsselkandidaten abhängen. Rechte Seite einer Regel ist also Primeattribut oder linke Seite ist
keine echte Teilmenge eines Schlüsselkandidaten.
• Dritte Normalform (3NF)
Alle Attribute sind nur von Superschlüsseln abhängig. Entweder ist linke Seite
einer Regel Superschlüssel oder rechte Seite Primeattribut.
• Boyce-Codd-Normalform (4NF)
Alle Attribute sind direkt(!) von Schlüsseln abhängig. Linke Seite einer Regel ist
Superschlüssel.
DBS I – Grundlagen von Datenbanksystemen
25. Februar 2005
Kapitel 4. Entwurf relationaler Datenbanken
15
Für jede Regel der Form X → Y (Y ∈
/ X) muss gelten:
Normalform
2NF
3NF
BCNF
linke Seite
keine echte Teilmenge eines SK
Superschlüssel
Superschlüssel
rechte Seite
Primeattribut
Primeattribut
—
Bemerkungen:
• Relationen aus dem RM enthalten per Definition nur atomare Werte, sind deswegen
stets in 1NF.
• Falls alle Schlüssel einelementig sind, ist R in 2NF.
• Falls alle Attribute Schlüsselelemente sind, ist R in 3NF.
• Es gilt: BCNF ⊂ 3NF ⊂ 2NF ⊂ 1NF
Umformungen:
• Satz: Jedes 1NF-Schema R kann bzgl. einer Menge F einfacher FDs verlustfrei in
BCNF zerlegt werden (Dekompositionsalgorithmus).
• Nicht jedes Schema R kann abhängigkeitserhaltend in BCNF zerlegt werden.
• Satz: Es existiert ein Algorithmus zur verlustfreien, abhängigkeitserhaltende Zerlegung in 3NF für jedes Relationenschema R (Synthesealgorithmus).
• Falls F eine minimale Überdeckung ist, können Schemata, die aus FDs mit gleicher
linken Seite entstanden sind, ohne Verletzung der 3NF zusammengefasst werden.
Nachteile:
• Zur Anfragezeit viele Joins notwendig.
4.6. Zusicherungen und Integritätsbedingungen
Anwendungsabhängige Integritätsregeln
• dynamisch (keine Gehaltserhöhung liegt über 10 Prozent)
• statisch (Gehalt des Managers ist höher als das seiner Untergebenen)
Assertions (Zusicherung): beschreibt konsistente DB-Zustände
• referenzielle Integrität
• statische/dynamische Integrität
Constraints
DBS I – Grundlagen von Datenbanksystemen
25. Februar 2005
Kapitel 4. Entwurf relationaler Datenbanken
16
• Primary key constraint: Definition des Primary Key. Beispiel:
ALTER TABLE PFLANZE ADD
PRIMARY KEY(ART_CODE)
• unique-constraint: Sicherung der Einzigartigkeit/Nullwertfreiheit von Attributen.
Beispiel:
ALTER TABLE GEHALT
ADD UNIQUE (Autor) NOT NULL
• referential-constraint: Sicherung der Beziehungen zu anderen Tabellen. Beispiel:
ALTER TABLE GEHALT
ADD FOREIGN KEY (Autor) REFERENCES Diplomarbeit (Autor)
• check-constraint: Prüfung semantischer Integritätsregeln, z.B. Wertebereichsprüfung von Attributen. Beispiel:
ALTER TABLE GEHALT ADD CONSTRAINT min_gehalt
CHECK (GEHALT > 2000)
Trigger
• Datenbankmechanismus zur automatischen Überprüfung von Konsistenzbedingungen (ECA: event–condition–action)
• notwendige Überprüfung bei Veränderungsoperationen
• nicht bei jeder Operation muss jede Zusicherung überprüft werden
• Probleme: Aufwendig zu überprüfen; Rekursion möglich, d.h. Trigger rufen sich
evtl. gegenseitig auf
• Beispiel:
CREATE TRIGGER BUDGET_INSERT AFTER INSERT ON GEHALT
FOR EACH ROW MODE DB2SQL
WHEN ((SELECT SUM(GEHALT) FROM GEHALT) > 50000)
SIGNAL SQLSTATE ’75001’ (’Budget von 50.000 überschritten’)
DBS I – Grundlagen von Datenbanksystemen
25. Februar 2005
5. Relationale Anfragesprachen
5.1. Relationale Algebra
Grundoperationen der Relationalen Algebra (RA)
• (Mengen-) Vereinigung: R ∪ S
– R und S müssen über den gleichen Domänen definiert sein
– Das Ergebnis hat die gleiche Struktur wie R bzw. S
– Das Ergebnis enthält keine Duplikate (Menge!), muss im DBMS explizit durchgeführt werden
• (Mengen-) Differenz R\S bzw. R − S
– R und S müssen über den gleichen Domänen definiert sein
– Das Ergebnis hat die gleiche Struktur wie R bzw. S
• Kartesisches Produkt R × S
– entspricht Konkatenation
– Bei Attributnamenskonflikten muss Eindeutigkeit wiederhergestellt werden!
– Beispiel: R(A, B) × S(B, C) = R× (A, BR , BS , C)
• Projektion πP roj (R)
– Definition: πP roj (R) = {µ[P roj] | µ ∈ R}
– Das Ergebnis enthält keine Duplikate (Menge!), muss im DBMS explizit durchgeführt werden
– Beispiel: πA (R(A, B)) = Rπ (A)
• Selektion σCond (R)
– Definition: σCond (R) = {µ | Cond[µ] ist wahr}. Dabei ist Cond[µ] eine Formel, bei der alle Attributnamen durch die Tupelwerte von µ ersetzt.
– σCond (R) ⊆ R
• (Mengen-) Durchschnitt R ∩ S
– R und S müssen über den gleichen Domänen definiert sein
– Das Ergebnis hat die gleiche Struktur wie R bzw. S
– kann auf Basisoperator zurückgeführt werden: R ∩ S = R\(R\S)
Weitere Operationen der RA (cont.):
Relationale
Algebra
(cont.)
Natural Join: R
S :
̈
̈
Beispiel:
̈
Weitere Operationen der RA (cont.):
̈
Natural Join: R
̈
S :
R A B
Kapitel
5. Relationale Anfragesprachen
18
̈ Beispiel:
1 a
A B
C
2 d
1 a
3
R A B 3 d
• Join R 1Cond SR S
Weitere
Operationen der RA (cont.):
2̈ d
4
1 a 4 e
̈ Natural
Join: R
S :
A
B
C
3
d
4
2 d
S B– Ckann auf Basisoperator zurückgeführt werden: R 1Cond S = σCond (R × S)
̈ Beispiel:
1 a
3
3 d
R S
a – 3Ergebnis
hat die Struktur
R
2 von
d
4 ×S
4 e
d 4
3 d muss
4 REindeutigkeit
– Bei Attributnameskonflikten
wiederhergestellt werden!
A B
S B C
© Prof. J.C. Freytag, Ph.D.
6.21
1 a
a 3
– Θ-Join: Θ ist der Operator in der Join-Bedingung
A B
C
2 d
d 4
– Equi-Join: Θ ist die Identität, z.B. R 1B=C S
1
a
3
3 d
R S
© Prof. J.C. Freytag, Ph.D.
6.21
2 d
4
4
e
• Natural Join R 1 S
3 d
4
S B C
– Join über gemeinsame Attribute
a 3
d 4
– gemeinsame Spalten müssen gleich sein
Relationale Algebra (cont.)
© Prof. J.C. Freytag, Ph.D.
– kann auf Basisoperator zurückgeführt
werden: Sei Att(R) und Att(S) die Attribute der Relation R bzw. S. Dann gilt:
R 1 S = π{Att(A),Att(B)\Att(A)} (R 1Att(R)∩Att(S) in R und S gleich S)
– Beispiel: R(A, B) 1 S(B, C) = RS(A, B, C)
6.21
Relationale Algebra (cont.)
̈ Weitere Operationen
RA (cont.):
Relationale
Algebrader(cont.)
Semi-Join R 魁 S :
•̈ Semi-Join
̈
Seien R, S Schemata mit R { A1 : D1 ,…, An : Dn }
Weitere Operationen
der RAMöglichkeiten,
(cont.):
–und
ZielS {des
Semi-Join:
den Existenzquantor (∃) zu erfassen:
B : E ,…, B : E }
̈
̈
Semi-Join R 魁 S =
: {µ ∈ R | ∃ν ∈ S : µ[Att(R) ∩ Att(S)] = ν[Att(R) ∩ Att(S)]}
̈ R
S = R { A1, ..., An} (R S )
̈ Seien –
R, entfernt
S Schemata
{ A1 :Tupel,
D1 ,…, Adie
ausmitRR alle
den mit S gemeinsamen Spalten keinen
n : Dauf
n }
des
Ergebnisses:
und ̈SSchema
{ BJoin-Partner“
:
E
,…,
B
:
E
}
1
1
m
m in S haben
” { A1:D1 ,…,An:Dn }
̈ R
S –=Ergebnis
R { A1, ..., An}hat
(R die
S )Struktur von ̈
R Weitere Operationen der RA (cont.):
̈ Eigenschaft:
̈ Schema des Ergebnisses:
̈ Semi-Join
S =: R 1 πAtt(R)∩Att(S) (S)
– kann
werden: R 魁 S
̈ R
S =auf
R Basisoperator
R ( S ) zurückgeführt
1
1
m
m
Relationale Algebra (cont.)
̈
̈
{ A1:D1 ,…,An:Dn } F
•Eigenschaft:
Division
mit F R
=÷
{ A1S ,…, An } ̨""{ B1 ,…, Bm }
̈
Seien R, S Schemata mit R { A1 : D1 ,…, An : Dn }
und S { B1 : E1 ,…, Bm : Em }
R S –=Ziel
R der
R Division:
F ( S)
Möglichkeiten, den ̈Allquantor
zuAn}erfassen:
R S6.22= R(∀)
(R S )
{ A1, ...,
R
÷
S
=
{µ
|
∀ν
∈
S
:
µν
∈
R}
mit F = { A1 ,…, An } ̨""{ B1 ,…, Bm }
̈ Schema des Ergebnisses:
{ A1:Ddie
– Erfordert, dass für jedes Tupel im Ergebnis R÷S
Konkatenation
mit allen
1 ,…,A
n:Dn }
© Prof. J.C. Freytag, Ph.D.
© Prof. J.C. Freytag, Ph.D.
6.22
̈ Eigenschaft:
Tupeln aus S ein Tupel in R zu finden
ist
̈
R
S = R R F ( S)
– kann auf Basisoperator zurückgeführt werden:
R ÷ S = π{Att(R)\Att(S)} (R)\π{Att(R)\Att(S)}
(R)
S)\R)
11
mit F((π={Att(R)\Att(S)}
{ A1 ,…, An } ̨""
{ B×
1 ,…, Bm }
Operator
Vereinigung
Differenz
karthesisches Produkt
Projektion
Selektion
Durchschnitt
Join/Θ-Join/Equi-Join
Natural Join
Semi-Join
Division
DBS I – Grundlagen von Datenbanksystemen
Stelligkeit
Basisoperator
© Prof. J.C. Freytag,
Ph.D.
binär
ja
binär
ja
binär
ja
unär
ja
unär
ja
binär
nein
binär
nein
binär
nein
binär
nein
binär
nein
Schema
R
11
R
R×S
µ[P roj]
R
R
R×S
Att(R) ∪ Att(S)
R
R
25. Februar 2005
6.22
Kapitel 5. Relationale Anfragesprachen
19
Eigenschaften
• Abgeschlossenheit: Operationen bilden Relationen auf Relationen ab
• Zusammensetzung – Bildung von Ausdrücken bzw. Termen
• ∪, \, σ, π, × sind Basisoperationen, mit denen weitere Operationen gebildet werden
können
• Basis: ∪, \, σ, π, × oder ∪, ÷, σ, π, ×
• Komplementoperator R fehlt, da bei unendlichen Domäne Dom(R) das Komplement auch unendlich wäre.
5.2. Relationenkalkül
Alphabet
• Variablen
• Konstanten
• arithmetische Vergleiche =, ≤, <, >, ≥, 6=
• logische Junktoren ∧, ∨, ¬ und Quantoren ∃, ∀
• Klammern
Freie und gebundene Variablen
• freie Variablen (FV): nicht durch Quantoren eingeschränkt“
”
• gebundene Variablen (BV): durch Quantoren eingeschränkt“
”
• Definition: F heißt geschlossen, falls F V (F ) = ∅. Ansonsten heißt F offen.
• Uns interessieren nur offene Formeln, da geschlossene keine Tupel, sondern nur die
booleschen Werte wahr oder falsch zurückgeben können.
Well-Formed Formulas (WFF) (Formeln des RC):
• Jede atomare Formel des RC ist eine WFF.
• Konjunktion, Disjunktion, Negation und Klammerung von WFF ergeben WFF.
• Ist F eine WFF und X ∈ F V (F ), so ist auch ∃X(F ) und ∀X(F ) eine WFF.
Wahrheitswert
• Wahrheitswerte der Formeln entsprechend der Standardsemantik:
DBS I – Grundlagen von Datenbanksystemen
25. Februar 2005
Kapitel 5. Relationale Anfragesprachen
20
– Variablen durch Werte aus Domäne ersetzen
– Konjunktion, Disjunktion, Negation: Standard
– Allquantor: Konjunktion über Domänenenwerte
– Existenzquantor: Disjunktion über Domänenenwerte
– geschlossene Formeln werden auf {wahr, falsch} abgebildet.
• Wahrheitswert W (F ) einer WFF F kann von der zugrunde liegenden Domäne
abhängen!
5.3. Domänenkalkül DRC
Einführung:
• Anfragen der relationalen Algebra können in WFF übersetzt werden.
• Sei F (X1 , . . . , Xn ) eine WFF. Die durch F definierte Relation rF ist definiert als
rF = {(a1 , . . . , an ) | W (F (a1 , . . . , an )) = wahr}
• Der Ausdruck {(X1 , . . . , Xn ) | F (X1 , . . . , Xn )} ist eine Domänenkalkülanfrage
(oder auch DRC-Query) mit Antwortrelation rF .
• Die Anfragesprache, die aus DRC-Queries besteht heißt Domänenkalkül oder auch
Domain Relational Calculus.
• Problem: Ergebnisse können unendlich oder unsinnig sein.
Definitionen, sichere WFF:
• Definition: Sei F = F1 ∧ . . . ∧ Fn eine konjunktive WFF. X heißt beschränkt, falls
es ein 1 ≤ i ≤ n gibt, so dass eine der folgenden drei Bedingung erfüllt ist:
1. X ∈ F V (Fi ) und Fi ist eine atomare Formel der Form p(t1 , . . . , X, . . . , tn )
(die nicht (!) negiert ist).
2. Es gilt Fi ≡ (X = a) oder Fi ≡ (a = X) mit a als Konstante.
3. Es gilt Fi ≡ (X = Y ) oder Fi ≡ (Y = X) für eine beschränkte Variable
Y ∈ F V (F )
• Definition: Eine WFF F heißt sicher (safe), falls gilt:
1. Es tritt kein Allquantor in F auf.
Anmerkung: ∀ durch ¬∃¬ ersetzen
2. Bei jeder in F auftretenden Disjunktion zweier Teilausdrücke F1 und F2 , muss
gelten: F V (F1 ) = F V (F2 ).
Anmerkung: verhindert erfundene“ Attributwerte (d.h. nicht an Domänen
”
bzw. Relationentupel gebunden), da so F1 und F2 nicht unabhängig voneinander sind
DBS I – Grundlagen von Datenbanksystemen
25. Februar 2005
Kapitel 5. Relationale Anfragesprachen
21
3. Die freien Variablen jeder maximalen konjunktiven Teilformel F1 ∧ . . . ∧ Fn
von F sind beschränkt.
Anmerkung: verhindert unendliche Antwortrelationen
4. Die Negation darf nur in Konjunktionen gemäß 3. auftreten, in denen mindestens ein Fi nicht negiert ist.
• Definition: Eine maximale konjunktive Teilformel ist die (rein syntaktische!) Kette
von konjugierten Teilformeln. Beispiel: (a ∨ b) ∧ (c ∨ d)
|
{z
}
max. konj. Teilformel
• Definition: Sichere Negation: Eine negierte Teilformel (¬G) mit freien Variablen
darf nur in beschränkten konjunktiven Teilformeln auftreten
• In F1 ∧ . . . ∧ Fn muss mindestens eine nicht-negierte Teilformel Fi auftreten, sonst
nicht sicher!
• Definition: Eine DRC-Query heißt sicher, falls ihre WFF sicher ist. Die Teilmenge
der sicheren DRC-Quieries heißt sicheres Domänenkalkül oder sicheres DRC.
• Satz: Jede sichere DRC-Query kann in einen äquivalenten Ausdruck der relationalen Algebra überführt werden, der die gleiche Antwortmenge berechnet. Dazu
können z.B. nicht beschränkte Formeln durch zusätzliche Formeln beschränkt werden.
5.4. Tupel-Kalkül TRC
• weitere Variante der Relationenkalkuls: Variablen stehen fur Tupel in WFFs
• Definition: Seien µ = (a1 , . . . , an ) und ν = (b1 , . . . , bm ) Tupel. Dann bezeichnet
µ ∗ ν die Konkatenation der Tupel µ und ν: (a1 , . . . , an , b1 , . . . , bm ).
• Definition: Sei p ein n-stelliges Prädikat und µ ein n-stelliges Tupel. Dann ist p(µ)
wahr, falls µ in der Relation p enthalten ist, d.h. W (p(µ)) = wahr gdw. µ ∈ p.
• Die Anfragesprache, die aus TRC-Queries besteht heißt Tupelkalkül oder auch
Tupel Relational Calculus.
• Satz: Jeder Ausdruck der relationalen Algebra mit Ergebnisrelation R lässt sich
durch eine TRC-Query mit gleichem Ergebnis berechnen.
Ergebnis: Die relationale Algebra, das sichere Domänenkalkül und das sichere
Tupelkalkül sind gleichmächtig.
DBS I – Grundlagen von Datenbanksystemen
25. Februar 2005
Kapitel 5. Relationale Anfragesprachen
22
5.5. Datalog
• logikbasierte Sprache, ähnlich zu PROLOG
• wird für deduktive Datenbanken benutzt
• Semantik: Formeln werden als Regeln“ interpretiert:
”
p <- q,r ≡ (q ∧ r) ⇒ p ≡ ¬(q ∧ r) ∨ p ≡ ¬q ∨ ¬r ∨ p
• der Regelkopf gibt Abfragen einen Namen
• Rekursion ist möglich, z.B. ancestor(X, adam) (mehr als relationale Algebra)!
5.6. QBE
• QBE: Query by Example
• Design-Ziele: Einfache Bedienung für den interaktiven Gebrauch, Intuitive Verständlichkeit auch für den ungeübten Benutzer
• Inthalte der Tabellen:
– Variablen: beginnen mit _.
– Variablen, die nur ein Mal auftreten, können weggelassen werden.
– Freie Variable werden mit P. gekennzeichnet. Dies sind die Ergebnisse (P=print).
– Existenz-Quantoren werden unterdrückt. Es gibt keine Allquantoren.
• Implementation: Graphische Oberfläche. Revolutionär für damaligen Standard!
• Satz: QBE ist relational vollstandig!
5.7. SQL
Einführung
• SQL: Structured Query Language“
”
• Standardisierung durch ANSI/ISO
• basierend auf TRC (gleichmächtig)
korrelierte Subqueries
• Semantik:
1. bestimme ein Tupel t des auseren Query-Blocks
2. substituiere die Werte in der Subquery
DBS I – Grundlagen von Datenbanksystemen
25. Februar 2005
Kapitel 5. Relationale Anfragesprachen
23
3. evaluiere die Subquery fur diesen Tupel t
• Achtung:
– Ausführung ist aufwendig (teuer)!
– Diese Semantik ist prozedural, verläßt die deklarative Semantik!!
– Interne Bearbeitung kann anders als die Semantik verlaufen!
Aggregation
• Operatoren auf einer Menge von Tupel: AVG, COUNT, SUM, MIN, MAX
• Semantik: SELECT E1 , . . . , En FROM R1 , . . . , Rg WHERE Cond1 GROUP BY
Ri1 .A1 , Ri2 .A2 , . . . , Rim .Am HAVING Cond2 ORDER BY F1 , . . . , Fh
1. Auswahl der Tupel aus R1 , . . . , Rg mit Cond1
2. Gruppierung nach Ri1 .A1 , Ri2 .A2 , . . . , Rim .Am in der GROUP BY-Klausel
3. Selektion auf den Gruppen entsprechend Cond2 in der HAVING Klausel
4. Sortieren nach F1 , . . . , Fh in der ORDER BY-Klausel
• Achtung: Semantik ist prozedural (Sequenz an Schritten). Impliziert nicht unbedingt Ordnung für die Auswertung (d.h. Berechnung des Ergebnisses)
• Anmerkungen: Wichtige Gruppe von Anfragen für den kommerziellen Bereich. Zeitintensive Auswertung bei großen Datenmengen.
Null-Werte
• sind in SQL erlaubt
• dreiwertige Logik: wahr, falsch, ?
?
• (Null = Null) wird zu ? ausgewertet
• erfordert drei-wertige Semantik für die Auswertung
• Tupel qualifizieren sich nur mit Wahrheitswert wahr: Null-Werte joinen nicht“!
”
• Null-Werte werden untereinander und von Nicht-Null-Werten verschieden interpretiert.
• Null-Werte werden vor der Aggregation entfernt.
DBS I – Grundlagen von Datenbanksystemen
25. Februar 2005
6. Anfragebearbeitung in relationalen
Datenbanksystemen
6.1. Einführung
Problem: deklarative Anfragen müssen in eine ausführbare Form übersetzt“ werden Ziel:
”
Bestmögliche“ Übersetzung (Geschwindigkeit, Ressourcen) ; Optimierungsproblem!
”
Vorgehen:
1. Syntaxüberprüfung und Übersetzung in Interndarstellung ; Operatorbaum
2. Algebraische Optimierung
3. Algorithmenauswahl und Zugriffsoptimierung ; QEP (query execution plan)
zum 1. Schritt:
• interne Darstellungsform: relationaler Algebra
• Überprüfung der syntaktischen Korrektheit
• Überprüfung der semantischen Korrektheit: Existenz Relation/Attribute, korrekte
Typen bei Vergleichen
zum 2. Schritt
• effizienter bedeutet hier kleinere Teilergebnisse
• Definition: Seien E1 und E2 Ausdrücke der relationalen Algebra. E1 und E2 heißen äquivalent, falls E1 und E2 die gleichen Operanden R1 . . . Rn haben und für
beliebige Instanziierungen von R1 . . . Rn die gleiche Antwortrelation berechnen.
6.2. Optimierungsregeln
Mit den folgenden Regeln kann der Operatorbaum hinsichtlich kleinerer Zwischenergebnisse optimiert werden:
1. Joins und kartesische Produkte sind kommutativ.
2. Joins und kartesische Produkte sind assoziativ.
3. Projektionen können kaskadiert werden. Wenn eine Projektion Obermenge der
anderen ist, kann sie weggelassen werden.
Kapitel 6. Anfragebearbeitung in relationalen Datenbanksystemen
25
4. Selektionen können kaskadiert werden. Die Bedingungen können konjugiert werden, sodass eine Selektion entsteht.
5. Projektion und Selektion können vertauscht werden, falls nur über Projektionsattribute selektiert wird.
6. Selektion und Join können vertauscht werden, falls nur über Attributen der linken
Join-Relation selektiert wird.
7. Selektion und Vereinigung bzw. Differenz können vertauscht werden.
8. Selektion und Natural Join können vertauscht werden.
9. Joins und kartesische Produkte können evtl. vertauscht werden.
10. Projektion und Vereinigung können vertauscht werden, falls nur auf die Attribute
der beiden Seiten projiziert wird.
11. Selektionen und kartesische Produkt können evtl. zu einem Join zusammengefasst
werden.
12. Kartesische Produkte mit n Operanden können in n − 1 kartesische Produkte
umgeschrieben werden.
6.3. Joins
Join-Reihenfolge
• Bei n Relationen gibt es theoretisch n! Möglichkeiten für die Joinreihenfolge. Nicht
realistisch, da meist nicht jede Relation mit jeder verknüpft wird.
• Durch Joingraphen entstehen drei verschiedene Muster: Kettenanfrage, Sternanfrage, Ringanfrage und Mischformen.
• Daraus wird Baum erzeugt, indem linke Operanden die äußere Relation und rechter
Operanden die innere Relation beschreiben.
• Bei Einzelprozessoren: Links-linearer Baum; bei Multiprozessoren: Bushy Tree“,
”
der längere Parallelität ermöglicht.
Join-Methoden:
• Nested-Loop Join: Sucht nach gleichen Werten der gemeinsamen Attribute in den
zu verbindenden Relationen. Dabei muss für jedes Tupel der Relation R jedes
Tupel der Relation S verglichen werden. Optimiert wird hier durch blockweißes
Lesen der Daten. Somit entsteht ein quadratischer Aufwand.
DBS I – Grundlagen von Datenbanksystemen
25. Februar 2005
Kapitel 6. Anfragebearbeitung in relationalen Datenbanksystemen
26
• Sort-Merge-Join: Sortiert erst die Operanden anhand der Verbund-Attribute aufsteigend und mischt anschließend die gleichwertigen Attribute zur Ergebnisrelation.
Aufwand: |S| log |S| + |R| log |R| +|S| + |R|
|
{z
}
Sortieren
• Hash-Join: Berechnung eines Equi-Joins zwischen zwei Tupelmengen durch Abbilden beider Mengen auf eine Hash-Tabelle (mit einer für beide Tupelmengen
identischen Hash-Funktion über dem Join-Attribut), so daß Tupel mit gleichem
Attributwert auf denselben Eintrag (bzw. Bucket) der Hash-Tabelle abgebildet
werden. Mit Hash-Basiertem-Join kann man nur den Equi-Join ausführen (kein
Θ-Join).
Konstenbetrachtung beim Nested-Loop Join:
• Gesucht werden die Seitenzugriffe beim Join R 1 S.
• TR , TS : Anzahl der Tupel in R bzw. in S
• PR , PS : Anzahl der Seiten in R bzw. in S
• βR = PR /TR , βS = PS /TS (Größe der Tupel in R bzw. S relativ zur Seitengröße)
• Anzahl der Tupel, die gelesen werden: TR · TS
• Anzahl der zugegriffenen Seiten:
– R ist äußere Relation: PR + TR · PS = PR + βS · TR · TS ≈ βS · TR · TS
– S ist äußere Relation: PS + TS · PR = PS + βR · TR · TS ≈ βR · TR · TS
• Falls βS < βR , dann R äußere Relation, sonst S äußere Relation.
6.4. Views
• Views sind nichtmaterialisierte Relationen
• Problem: nicht alle Views können aktualisiert werden.
• Hat man zwei Spalten A und B mit Zahlen, so kann man sich eine weitere Spalte
definieren, die A · B enthält. Ändert man einen Wert in dieser Spalte, so kann
daraus nicht der Wert der Spalten A und B bestimmt werden, da im allgemeinen
aus dem Produkt zweier Zahlen diese zwei Zahlen nicht bestimmt werden können.
Dieses View kann also theoretisch nicht aktualisiert werden.
• Faustregeln: Nur Projektion; View muss Schlüssel enthalten; Falls Joins, dann nur
über Schlüssel; kein Distinct, keine Schachtelung, keine Aggregate
• Beispiel:
DBS I – Grundlagen von Datenbanksystemen
25. Februar 2005
Kapitel 6. Anfragebearbeitung in relationalen Datenbanksystemen
27
CREATE VIEW Test_in_HS1 (Student_Name, Test) AS
SELECT StName, Pr#
FROM Beteiligt, Prüfung
WHERE Beteiligt.Pr# = Prüfung.Pr# and Hörsaal = HS1
DBS I – Grundlagen von Datenbanksystemen
25. Februar 2005
7. Speicherstrukturen für Datenbanken
Übersicht Speicherstrukturen:
• Sequentielle Datei
• Index-Sequentielle Datei
• B-Baum
• B*-Baum
• Hashing
7.1. Sequentielle Datei
• Sätze werden in der Reihenfolge des Einfügens in der Datei (Seiten) gespeichert
• Problem: Alternieren zwischen Einfügen und Löschen erzeugt Fragmentierung der
Datei
• Suche: keine andere Wahl als sequentielle alle Tupel zu lesen
7.2. Index-Sequentielle Datei
• Datenteil: Sätze in nach Schlüsselwerten k geordnet
• Indexteil mit Index-Seiten und Index-Sätzen
• Indexsatz (ki , bi ) mit ki als Schlüsselwert und bi als Seitenpointer
• Suchen nach Schlüssel k:
1. Suche in der Indexdatei (ki , bi ) mit ki ≤ k < ki+1
2. Suchen in Seite bi der Datendatei
• beim Einfügen muss (falls entsprechende Seite voll) evtl. ein neuer Index bzw. eine
neue Seite erzeugt werden
• analog Änderung und Löschen
Kapitel 7. Speicherstrukturen für Datenbanken
29
7.3. B-Baum
• B-Baum: Balancierter Baum“
”
• Verallgemeinerung der index-sequentiellen Datei: Mehrschichten-Index“
”
• Eigenschaft: Trotz Einfüge-/Löschoperationen bleibt die Höhe des Baumes für alle
Pfade von der Wurzel zu den Blättern gleich
• jeder Knoten hat einen Verweis (Pointer) mehr, als er Werte (Values) hat
• ein Knoten entspricht einer Seite (4 bis 32 KB)
• Beispiel: pro Pointer und Value werden 4 Bytes benötigt. Bei einer Seitengröße von
16 KB ergeben sich ungefähr 211 = 2048 Werte und 2048 Verweise.
7.4. B*-Baum
• Trennung von Datenteil und Indexteil
• Sätze des B* -Baumes sind reine Indexsätze
• Nur die Indextupel in den Blättern beinhalten Verweise (Zeiger) auf die Tupel in
der sequentiellen Datei
• Vorteile:
– Nur Schlüssel in der Indexdatei: mehr Indexsätze pro Seite and damit bessere
Speicherausnutzung; stärkere Verzweigung des Baumes und damit eventuell
geringere Tiefe; Schlüssel werden jedoch redundant gespeichert
– Geringere Komplexität für Veränderungsoperationen
– Blätter garantieren sortierten“ Zugriff
”
7.5. Hashing
• Idee: Verteilung von Schlüssel auf Speicherplätze
• Definition einer Funktion die für jeden Schlüssel die Position des Tupels in der
Hashtabelle berechnet ( Hashfunktion“)
”
• Satz: Ist Werteverteilung des Schlüssels bekannt, lässt sich eine optimale“ Hash”
funktion definieren.
• Problem: Vergrößerung der Hashtabelle ist oft nicht dynamisch möglich und führt
auch zu neuen Position für alle bisherigen Eintrage
• Anwendung bei Datenbanken: Hashdatei besteht aus
DBS I – Grundlagen von Datenbanksystemen
25. Februar 2005
Kapitel 7. Speicherstrukturen für Datenbanken
30
– einer Menge von Buckets (eine oder mehrere Seiten): B0 , B1 , . . . , Bm−1
– einer Hashfunktion h(K) = {0, . . . , m−1} auf der Menge K der Schlüsselwerte
– einer Hashtabelle, das Bucketdirectory, als Array der Größe m mit Pointer
auf Buckets
• Definition: Füllfaktor = (# gespeicherter Tupel) / (# möglicher Tupel)
• Grundsätzliches: Hash-Join last sich einfach parallelisieren. Hashfunktion sollte
dynamisch sein!
DBS I – Grundlagen von Datenbanksystemen
25. Februar 2005
8. XML
Hier werden nur die klausurrelevanten Dinge beschrieben. Mehr dazu in den Vorlesungsfolien oder überall anders.
• ein vollständiges XML Dokument
<?xml version="1.0"?>
<person>
<name> J.C. Freytag </name>
<tel> +49 30 2093 3009 </ tel>
<email> freytag@informatik.hu-berlin.de </email>
</person>
</xml>
• das passende Document Type Definition
<!DOCTYPE addressbook [
<!ELEMENT addressbook (project* )>
<!ELEMENT project
(name, greet?, address* , (fax | tel)* , email* )>
<!ELEMENT name (# PCDATA)>
<!ELEMENT greet (# PCDATA)>
<!ELEMENT address (# PCDATA)>
<!ELEMENT tel (#PCDATA)>
<!ELEMENT fax (# PCDATA)>
<!ELEMENT email (# PCDATA)>
]>
A. Prüfungsfragen
A.1. Entity-Relationship-Modell
Vor lesung DBI S I ( WS 2004/ 2005)
Teil 5:ein
Relat
Anf
achen
• Gegeben
paarionale
Instanzen
undr agespr
vorgegebenen
Entitys sollten die Relationships mit
Kardinalitäten und sonstigen Constraints (partiell, total) eingezeichnet werden.
Eine Generalisierung war auch dabei.
• Anschließend aus diesem ER-Modell wieder ein relationales Modell (mit Primärund Fremdschlüsseln) erstellen.
Relationale Algebra (cont.)
A.2.
Funktionale Abhängigkeiten
̈ Weitere Operationen der RA (cont.):
̈
Natural Join: R
S :
• Gegeben
ein paar funktionale Abhängigkeiten sollten Schlüsselkandidaten hergeBeispiel:
leitet werden.
̈
R A B
• Gegeben
ein paar FDs sollten nur unter Anwendung der Armstrong-Regeln Erwei1 a
terung, Reflexivität und Transitivität eine
andere
FD hergeleitet werden.
A B
C
•
2 d
3 d
Gegeben
ein
4 e
1
2
3
den.
S
a
d
d
3
4
4
R Ssollten diese mit dem Basisalgorithmus minimalisiert werpaar FDs
B C
a 3
d 4
A.3. Normalformen
© Prof. J.C. Freytag, Ph.D.
6.21
• Gegeben ein Relationsschema mit FDs: welche Schlüsselkandidaten, welche Normalform und wegen welcher FD nicht eine Normalform höher? (Auch Grund angeben, z.B. linke Seite echte Teilmenge eines Schlüsselkandidaten“ etc.
”
• Gegeben ein Relationsschema mit FDs: welche Normalform, lossless-join Zerlegung
zu 2NF. Dann lossless-join Zerlegung zu 3NF. Warum ist Ergebnis noch nicht
BCNF?
Algebra
A.4. Relationale
Relationale Algebra
(cont.)
Weitere
Operationen
derzuRA
(cont.):
• ̈Viele
Multiple-Choice
Fragen
den
einzelnen Operatoren.
̈ Semi-Join
R 魁 S)
S :1 S) oder gilt (R 1true S) = (R × S)? Auch dabei z.B.: die
Beispiel:
gilt ((R
genau ̈Definition
Division.
Seien R, S der
Schemata
mit R { A1 : D1 ,…, An : Dn }
und S { B1 : E1 ,…, Bm : Em }
• Was versteht man im Hinblick auf die relationale Algebra unter minimalen Men̈ R
S = R { A1, ..., An} (R S )
gen?
̈
Schema des Ergebnisses:
̈
Eigenschaft:
̈
R S =
{ A1:D1 ,…,An:Dn }
R
R
F
mit F = { A1 ,…, An }
© Prof. J.C. Freytag, Ph.D.
( S)
̨""{ B1 ,…, Bm }
6.22
11
Anhang A. Prüfungsfragen
33
• Geben Sie eine Minimale Menge von Operatoren für die relationale Algebra an!
A.5. SQL
• Gegeben eine SQL-Beschreibung (DDL) eines Relationsschematas. Was kann aus
Primary-/Foreignkeybeziehungen geschlossen werden?
• Nach Einfügen von gegebenen Tupeln, wie sieht Reihenfolge der Ausgabe auf
SELECT * FROM tabelle aus?
• Anfrage als Text gegeben: wie sieht SQL-Abfrage dazu aus?
• Multiple-Choice-Frage zu korrellierten Anfragen
• Formulieren einer korrellierten SQL-Anfrage bei gegebenem Text, was die Anfrage
zu leisten hat
A.6. Joins
• Gegeben ein Algorithmus im Pseudocode zum Nested-Loop-Join. Leiten Sie den
entsprechenden Algorithmus für den Nested-Loop-Semijoin“ her!
”
• Herleiten der Join-Bäume bei verschiedenen Join-Reihenfolgen (bushy-tree etc.)
• Was sind die Vorteile des bushy-trees bei Multi-CPU-Systemen?
• Gegeben TS , PS , TR und PR , wie viele Seitenzugriffe sind nötig, wenn R (bzw. S)
die äußere Relation ist? (Herleiten des Ergebnisses)
• Wie kann generell bestimmt werden, welche Relation die äußere und welche die
innere sein sollte.
A.7. B-Bäume
• Geben Sie zwei Eigenschaften des B-Baumes an!
• Verändert sich beim Löschen zunächst Tiefe oder Breite des B-Baumes?
• Gegeben ein B-Baum mit Füllung. Wie sieht B-Baum nach Einfügen aus?
• Gegeben ein B-Baum mit Füllung. Wie sieht B-Baum nach Löschen aus?
A.8. XML
• Gegeben zwei Relationsschema mit Instanzen: wie sieht XML-Version davon aus?
• Wie sieht die entsprechende DTD aus?
• Wie müssen die Schlüsselbeziehungen eingebunden werden?
DBS I – Grundlagen von Datenbanksystemen
25. Februar 2005
Anhang A. Prüfungsfragen
34
A.9. Transaktionen
• Was bedeutet ACID?
• Welche ACID-Eigenschaft sichert der Concurrency-Manager, welche der ErrorRecovery-Manager des Transaktionsmanagers zu?
• Was ist ein Schedule?
• Was versteht man unter Serialisierbarkeit?
• Kann ein gegebener Schedule serialisiert werden?
DBS I – Grundlagen von Datenbanksystemen
25. Februar 2005