Relationale Entwurfstheorie Kapitel 7 Relationale Entwurfstheorie

Teil 1: Normalisierung Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

 Lernziele Charakterisierung "guter" relationaler Schemata: jede Relation entspricht genau einer Objektmenge - eventuell unter Einbezug von N:1- oder 1:1-Relationships - oder genau einer Relationship-Menge zwischen Objekten - Redundanz ist eliminiert, alle Informationen sind repräsentierbar, und es treten keinerlei "Änderungsanomalien" auf a) Änderungen können bei Beachtung der Primärschlüssel- und Fremdschlüsselbedingung keine Inkonsistenzen hervorrufen b) alle Informationen lassen sich unter Wahrung der Primärschlüssel- und Fremdschlüsselbedingung (ohne "Kunstgriffe") einfügen c) Informationen können einzeln wieder gelöscht werden, ohne die Primärschlüssel oder Fremdschlüsselbedingung zu verletzen Ausnahmen wenn „schlechte“ Schemata sinnvoll sind Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Erste Beispiel: „Schlechtes“ Datenbankschema Warum ist das eine schlechte Idee? Jeder für sich mit Zettel und Stift; 5 min ProfVorl PersNr Name Titel 2125 Sokrates Ethik, Mäeutik, Logik 2126 Russel Erkenntnistheorie, Wissenschaftstheorie, Bioethik 2127 Kopernikus n.a. … Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Zu wenig Struktur Pro Zelle darf immer nur ein Fakt stehen, sonst können diese nicht einzeln abgefragt werden. … sonst können sie nicht einzeln referenziert werden. … sonst können keine Zusatzinformationen zu den Fakten gespeichert werden. … sonst werden Einfüge- und Löschoperationen einzelner Fakten zu komplexen Stringoperationen. (Siehe auch die Probleme, die bei Aufgabenblatt 1 entstanden sind) Wenn in jeder Zelle nur ein Fakt steht, heißt das 1. Normalform Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Wie komme ich in die Erste Normalform? Beispiel (falsch): In 1 NF Eltern Vater Mutter Kinder Johann Martha {Else, Lucie} Maria {Theo, Josef} Heinz {Cleo} Eltern Vater Mutter Kind Johann Martha Else Lucie Maria Theo Josef Heinz Cleo Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Die einzelnen Fakten stehen getrennt gar nicht zur Verfügung Aber … … manchmal kann es sinnvoll sein, die Daten doch einfach so zu speichern. Zum Beispiel: Die einzelnen Fakten stehen getrennt gar nicht zur Verfügung müssten erst aufwändig getrennt werden werden getrennt nicht benötigt (Achtung!!! Könnte sich ändern) Weiterhin: Im letzten Kapitel haben wir gesehen, dass es einen Mismatch zwischen relationalem Datenmodell und objektorientierten Datenmodell besteht. Es gibt Datenbanken (objektrelationale), die es erlauben direkt Objekte und Listen zu speichern und dann auch darauf zuzugreifen. Nachteil: Unterobjekte können nicht mehr direkt zugegriffen werden, es muss über die Oberobjekte navigiert werden. Das Schema wird komplexer, Anfragen werden schwieriger... Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Exkurs: NF2-Relationen Non-First Normal-Form-Relationen Geschachtelte Relationen (Oracle: Nested Tables) Eltern Vater Mutter Kinder KName KAlter Johann Martha Else 5 Lucie 3 Maria Theo Josef 1 Heinz Cleo 9 Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Beispiel 2: "Schlechte" Relationenschemata ProfVorl PersNr Name Rang Raum VorlNr Titel SWS 2125 Sokrates C4 226 5041 Ethik 4 5049 Mäeutik 2 4052 Logik ... 2132 Popper C3 52 5259 Der Wiener Kreis 2137 Kant 7 4630 Die 3 Kritiken Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Beispiel 2: "Schlechte" Relationenschemata ProfVorl PersNr Name Rang Raum VorlNr Titel SWS 2125 Sokrates C4 226 5041 Ethik 4 5049 Mäeutik 2 4052 Logik ... 2132 Schlick C3 52 5259 Der Wiener Kreis 2137 Kant 7 4630 Die 3 Kritiken Update-Anomalien Sokrates zieht um, von Raum 226 in R. 338. Was passiert? Einfüge-Anomalien Neue/r Prof ohne Vorlesungen? Löschanomalien Letzte Vorlesung einer/s Profs wird gelöscht? Was passiert? Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Beispiel 2: „Bessere" Relationenschemata Sokrates zieht um, von Raum 226 in R. 338. Was passiert? Neue/r Prof ohne Vorlesungen? Letzte Vorlesung einer/s Profs wird gelöscht? Was passiert? Mit den aufgeteilten Relationen treten die Anomalien nicht mehr auf. Woher kann man wissen wann man aufteilen muss und wie und wann nicht? Professoren PersNr Name Rang Raum 2125 Sokrates C4 226 2126 Russel 232 2127 Kopernikus C3 310 2133 Popper 52 2134 Augustinus 309 Vorlesungen VorlNr Titel SWS gelesenVon 5001 Grundzüge 4 2137 5041 Ethik 2125 5043 Erkenntnistheorie 3 2126 5049 Mäeutik 2 4052 Logik Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Erste, zweite und dritte Normalform The key, the whole key and nothing but the key. Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Jede Relation braucht einen Primärschlüssel 1. Normalform Neben der eben gelernten Definition gibt es noch eine andere Jede Relation braucht einen Primärschlüssel Eine einfache Lösung für dieses Problem ist es in jeder Tabelle einen Schlüssel künstlich zu erzeugen Das greift aber zu kurz Wichtig ist, dass es semantisch Sinn macht, die Attribute unter einem Primärschlüssel zu führen, weil Sie zu einer Sinneinheit gehören Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Jedes Attribut hängt vom ganzen Primärschlüssel ab. 2. Normalform Jedes Attribut hängt vom ganzen Primärschlüssel ab. Gegenbeispiel: PersNr, Name, Gehalt, Dienstwagennr, Kennzeichen, Kilometer PersNr und Dienstwagennr sind zwar ein legitimer Primärschlüssel, aber stehen für zwei verschiedene Entitäten Formal kann man das Problem wieder dadurch lösen, dass ,man künstliche einspaltige Primärschlüssel erzeugt Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Attribute müssen direkt vom Primärschlüssel abhängen 3. Normalform Attribute müssen direkt vom Primärschlüssel abhängen Gegenbeispiel: PersNr, Name, Gehalt, Dienstwagennr, Kennzeichen, Kilometer Es entsteht dasselbe Problem wie bei der zweiten Normalform, nur subtiler. Hier hilft nur scharfes Hingucken und Verstehen, was die Daten bedeuten. Fragen Sie sich für jedes Attribut: Gibt es für einen gegebenen Schlüssel nur eine sinnvolle Möglichkeit für den Wert des Attributs? (funktionale Abhängigkeit) Beschreibt das Attribut dasselbe Objekt wie der Schlüssel? Möchten Sie vielleicht in anderem Kontext dieses Attribut referenzieren ohne den Schlüssel? Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Erste, zweite und dritte Normalform The key, the whole key and nothing but the key. Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Beispiel Was ist das Problem? Stammbaum Kind Vater Mutter Opa Oma Sofie Alfons Sabine Lothar Linde Hubert Lisa Niklas ... Martha … Was ist das Problem? Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Problem 3: Ein künstlicher Primärschlüssel hätte dasselbe Problem Beispiel Stammbaum Kind Vater Mutter Opa Oma Sofie Alfons Sabine Lothar Linde Hubert Lisa Niklas ... Martha … Problem 1: Keine Spalte ist eindeutig und damit als einfacher Primärschlüssel geeignet Problem 2: {Kind, Opa} wäre ein eindeutiger Primärschlüssel, aber Kind allein bestimmt bereits Vater und Mutter Problem 3: Ein künstlicher Primärschlüssel hätte dasselbe Problem Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Beispiel Stammbaum Kind Vater Mutter Opa Oma Sofie Alfons Sabine Lothar Linde Hubert Lisa Niklas ... Martha … Wie kann man die Relation verändern, dass die Probleme nicht mehr auftreten? Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Zerlegung (Dekomposition) von Relationen Korrektheitskriterien für die Zerlegung von Relationenschemata: Verlustlosigkeit Die in der ursprünglichen Relationenausprägung Q des Schemas R enthaltenen Informationen müssen aus den Ausprägungen Q1, ..., Qn der neuen Relationenschemata R1, .., Rn rekonstruierbar sein. Abhängigkeitserhaltung Die für R geltenden Anhängigkeiten müssen auf die Schemata R1, ..., Rn übertragbar sein. Satz: Jede Relation kann durch verlustlose und abhängigkeitserhaltende Zerlegung in 3 NF gebracht werden. Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Verlustlose Zerlegung – Die Informationen bleiben erhalten Eltern Vater Mutter Kind Johann Martha Else Maria Theo Heinz Cleo SELECT Vater, Kind FROM Eltern Vater Kind Johann Else Theo Heinz Cleo SELECT Mutter, Kind FROM Eltern Mutter Kind Martha Else Maria Theo Cleo Natural Join Vater Mutter Kind Johann Martha Else Maria Theo Heinz Cleo Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Abhängigkeiten bleiben erhalten Jedes Kind hat genau eine Mutter und genau einen Vater Eltern können jedoch auch mehrere verschiedene Kinder haben Ein Vater kann mit mehreren verschiedenen Müttern Kinder haben. Und umgekehrt. Es bestimmt keine Bindung im Sinne der Relation Vater 1 * Mutter Kind Kind Vater 1 * Mutter Kind * 1 Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Biertrinker-Beispiel Lokal Gast Bier Einstein Gniffke Pils Anders Hefeweizen Mephisto Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Biertrinker-Beispiel: Informationsverlust Lokal Gast Bier Einstein Gniffke Pils Anders Hefeweizen Mephisto SELECT Lokal, Gast FROM Biertrinker Lokal Gast Einstein Gniffke Anders Mephisto SELECT Gast, Bier FROM Biertrinker Gast Bier Gniffke Pils Anders Hefeweizen Natural Join Lokal Gast Bier Einstein Gniffke Pils Hefeweizen Anders Mephisto Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Erläuterung des Biertrinker-Beispiels Es gibt keine festen Abhängigkeiten zwischen den Attributen. Jeder kann in jedem beliebigen Lokal das Bier bestellen, das er will. Damit kann diese Relation nicht zerlegt werden ohne Informationsverlust. Es können aber auch keine Abhängigkeiten verletzt werden. Wie bringt man die Biertrinker in 3. Normalform? Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Verlustige Zerlegung – Die Informationen sind weg! Eltern Vater Mutter Kind Johann Martha Else Maria Theo Heinz Cleo SELECT Vater, Kind FROM Eltern Vater Kind Johann Else Theo Heinz Cleo SELECT Mutter FROM Eltern Mutter Martha Maria Natural Join Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Abhängigkeiten bleiben nicht erhalten In der neuen Mutterrelation fehlt die Verbindung zum Kind! Vater 1 * Mutter Kind Kind Vater 1 * Mutter Kind * 1 Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Aber… … manchmal möchte man doch, dass die Fakten in einer Relation zusammen stehen. Warum??? Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Data Warehouse (ganz kurz)  Das Data Warehouse dient dem Reporting von wirtschaftsrelevanten Daten an z.B. das Management. Ziel: Zu bestimmten Zeitpunkten alle relevanten Daten aus der Datenbank zu ziehen und dann für statistische Untersuchungen zur Verfügung zu stellen Diese Daten werden typischerweise in nur ganz wenige Relationen geschrieben (Stichwort Sternschema), da sie sich nicht ändern werden da man sich so Joins bei den Abfragen spart da man so automatisch statische Analysen laufen lassen kann Aus Wikipedia (Stern_Schema) Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Triplifizierung (vereinfacht)  TripleStore Subjekt Prädikat Objekt Professor hatPrädikat hatRaum Sokrates istInstanzVon 226 hatObjektTyp integer hältVorlesung Ethik hatSWS 4 hört hatSubjektTyp Mensch istEin Student Vorlesung Carnap … Vor- und Nachteile? Es ist alles in einer Tabelle Es ist alles maximal normalisiert Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Triplifizierung (vereinfacht)  Woher weiß ich, ob die Daten überhaupt stimmen? Woher weiß ich, was Daten sind und was zur Struktur gehört? TripleStore Subjekt Prädikat Objekt Professor hatPrädikat hatRaum Sokrates istInstanzVon 226 hatObjektTyp integer hältVorlesung Ethik hatSWS 4 hört hatSubjektTyp Mensch istEin Student Vorlesung Carnap … TripleStore Subjekt Prädikat Objekt Professor istInstanz nein Sokrates istInstanzVon ??? Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Triplifizierung (und verwandte Methoden z.B. DOM)  Wird eingesetzt, wenn die Datenstruktur nicht bekannt ist oder sich noch ändern kann Eindeutiger Vorteil ist die Vernetzbarkeit. Jemand anders kann seinen eigenen TripleStore einfach ankoppeln und schon hat man doppelt so viele Daten Ein Nachteil ist die Überprüfung von Konsistenz Was ist in dem Zusammenhang überhaupt eine Inkonsistenz? A istInstanzVon B und B istInstanzVon A (schwierig) A istKindVon B und B istKindVon C und C istKindVon A (schwierig zu berechnen) Das Problem ist verwandt mit Logik Weiterer Nachteil ist die Navigierbarkeit: Beispiel: Gib alle Personen aus (erfordert transitive Hülle) Es ist deutlich einfacher, wenn man die Prädikate und Typen von vornherein festlegt, leider auch weniger flexibel Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Vorteile der Normalisierung Es können keine Anomalien auftreten Zwischenfazit Vorteile der Normalisierung Es können keine Anomalien auftreten Nachteil der Normalisierung Unter Umständen werden Anfragen langsamer, da mehr Joins notwendig sind Es gibt verschiedene Standardmodelle, die nicht normalisiert oder sogar übernormalisiert sind Vor- und Nachteile sind im Einzelfall abzuwägen Im Normalfall (z.B. in der Prüfung) gilt: 3 NF ist am Besten Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Teil 2: Entwurfsmuster  Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Lernziel  Komplexe Datentypen wie Listen, Bäume und Graphen in SQL effizient darstellen Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Motivation  Bei der Umsetzung von UML haben wir bisher nur Assoziation, Generalisierung und Attribute betrachtet, doch was ist mit komplexen Datentypen wie: Listen, Stacks, Heaps, Bäumen, Graphen, Maps, …? Diese werden nativ nicht von relationalen Datenbanken unterstützt (mit Ausnahmen, wie etwa XML), können aber dargestellt werden. Allerdings haben diese Darstellungen verschiedene Vor- und Nachteile. Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Listen  TODOs ID Titel next 1 aufräumen 2 Zur Uni gehen 3 Party null Darstellung als verkettete Liste: Hauptproblem ist die Ineffizienz der transitiven Hülle Beispiel: Wie viele TODOs kommen noch nach ‚aufräumen‘`? Gib mir alle Titel in der Listenreihenfolge aus. Weiteres Problem ist die Datenintegrität. (next sollte unique sein) Darstellung wie Array: Hauptproblem ist die Verwaltung von Inserts und Deletes Beispiel: Lösche ‚aufräumen‘. Füge ‚Hausaufgaben‘ zwischen ‚Uni‘ und ‚Party‘ ein. Vorteil: Anfragen gehen meist schnell und unproblematisch. Im Idealfall kann die Reihenfolge aus den Werten mit ORDER BY berechnet werden (z.B. aus ID oder einem Timestamp) TODOs ID Titel Index 1 aufräumen 2 Zur Uni gehen 3 Party Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Bäume  simplifiedDOM ID type content parent next 1 element html null 2 head 3 body 4 text Test! DOM: Problem ist wieder die schlechte Performanz von Abfragen wie: Welchen Text enthält Element x? Auf welcher Hierarchieebene ist Element x? Was sind die Vorgänger? Leider sind diese Art Abfragen äußerst typisch für Operationen mit XML-Dokumenten. Dasselbe Problem tritt auf für andere Baumstrukturen, z.B. Bauteile eines Autos Auto -> Motor -> Einspritzpumpe -> Kurbelwelle Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Bäume (Forts.) – Pre-post-table  Statt parent und next wird die Pre- und Postorder gespeichert. Aus Implementing Filesystems by Tree-aware DBMSs.  Alexander Holupirek, and Marc H. Scholl. In Proc. VLDB 2008 PhD Workshop. pp. 1623-1630, 2008.  Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Bäume (Forts.) – Pre-post-table  Nachfolger Elternknoten Vorgänger Kindknoten Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Bäume (Forts.) – Pre-post-table  Wenn man noch die Höhe (level) im Baum dazu nimmt, kann man fast alle sinnvollen Anfragen nativ in effizientem SQL stellen. Beispiel: Welcher Text steht unter Element x? SELECT n.content FROM nodes n, nodes x WHERE x.ID = ‘x‘ AND x.post < n.post AND x.pre> n.pre AND n.type = text ORDER BY n.post; Welcher ist der Vaterknoten? SELECT p.ID FROM nodes p, nodes x WHERE x.ID = ‘x‘ AND x.post > p.post AND x.pre < p.pre AND x.level = p.level + 1; Wie viele Knoten kommen noch nach x? Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Careting (ORDPATH)  Im das Einfügeproblem in den Griff zu bekommen, kann man Carets benutzen. Regel 1: Ein Kindknoten verlängert den Code des Elternknoten Beispiel: 1.5.3.9. ist der Elternknoten von 1.5.3.9.1 Regel 2: Geschwister sind in der korrekten Reihenfolge abgelegt Beispiel: 1.5.3.9.1 kommt vor 1.5.3.9.3 Regel 3: Gerade Indexzahlen werden für Generationen ignoriert Beispiel: 1.5.3.9. ist der direkte Elternknoten von 1.5.3.9.2.4.3 Geschwister können so immer dazwischen kopiert werden Regel 4: Root heißt 1 und alle Knoten enden auf Ungerade Leider kann man das nicht mehr nativ in SQL abfragen. Siehe auch [ORDPATHs: insert-friendly XML node labels. A. O'Neil, et al. Proc. ACM SIGMOD Management of data, pp. 903-908, 2004] wird eingesetzt von SQL Server Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie

Fazit – Teil 2  Es gibt mehrere Möglichkeiten komplexe Datenstrukturen in Datenbanken abzubilden. Wir haben hier Listen und Bäume betrachtet (andere Datenstrukturen funktionieren ähnlich) Man hat (vereinfacht gesagt) die Auswahl zwischen schnellen Anfragen mit Indexzahlen und schnellen Änderungsoperationen mit Zeigern. Es kommt also auf die Anwendung an. Datenbanken, SS 12 Kapitel 7: Relationale Entwurfstheorie