Zusammenfassung - Hu
Transcription
Zusammenfassung - Hu
Prüfungsvorbereitung DBS I Grundlagen von Datenbanksystemen Niels Lohmann Wintersemester 2004/2005 [email protected] 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 [email protected] 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> [email protected] </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