Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Dr. Brigitte Mathiak Kapitel 7 Relationale Entwurfstheorie.

Ähnliche Präsentationen


Präsentation zum Thema: "Dr. Brigitte Mathiak Kapitel 7 Relationale Entwurfstheorie."—  Präsentation transkript:

1 Dr. Brigitte Mathiak Kapitel 7 Relationale Entwurfstheorie

2 Teil 1: Normalisierung Datenbanken, SS 12Kapitel 7: Relationale Entwurfstheorie2

3 Datenbanken, SS 12Kapitel 7: Relationale Entwurfstheorie3 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

4 Erste Beispiel: Schlechtes Datenbankschema Warum ist das eine schlechte Idee? Jeder für sich mit Zettel und Stift; 5 min Datenbanken, SS 12Kapitel 7: Relationale Entwurfstheorie4 ProfVorl PersNrNameTitel 2125SokratesEthik, Mäeutik, Logik 2126 RusselErkenntnistheorie, Wissenschaftstheorie, Bioethik 2127Kopernikusn.a. ………

5 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 12Kapitel 7: Relationale Entwurfstheorie5

6 Datenbanken, SS 12Kapitel 7: Relationale Entwurfstheorie6 Wie komme ich in die Erste Normalform? Beispiel (falsch): In 1 NF Eltern VaterMutterKinder JohannMartha{Else, Lucie} JohannMaria{Theo, Josef} HeinzMartha{Cleo} Eltern VaterMutterKind JohannMarthaElse JohannMarthaLucie JohannMariaTheo JohannMariaJosef HeinzMarthaCleo

7 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 12Kapitel 7: Relationale Entwurfstheorie7

8 Datenbanken, SS 12Kapitel 7: Relationale Entwurfstheorie8 Exkurs: NF 2 -Relationen Non-First Normal-Form-Relationen Geschachtelte Relationen (Oracle: Nested Tables) Eltern VaterMutterKinder KNameKAlter JohannMarthaElse5 Lucie3 JohannMariaTheo3 Josef1 HeinzMarthaCleo9

9 Datenbanken, SS 12Kapitel 7: Relationale Entwurfstheorie9 Beispiel 2: "Schlechte" Relationenschemata ProfVorl PersNrNameRangRaumVorlNrTitelSWS 2125SokratesC Ethik4 2125SokratesC Mäeutik2 2125SokratesC Logik PopperC Der Wiener Kreis2 2137KantC474630Die 3 Kritiken4

10 Datenbanken, SS 12Kapitel 7: Relationale Entwurfstheorie10 Beispiel 2: "Schlechte" Relationenschemata Update-Anomalien Sokrates zieht um, von Raum 226 in R Was passiert? Einfüge-Anomalien Neue/r Prof ohne Vorlesungen? Löschanomalien Letzte Vorlesung einer/s Profs wird gelöscht? Was passiert? ProfVorl PersNrNameRangRaumVorlNrTitelSWS 2125SokratesC Ethik4 2125SokratesC Mäeutik2 2125SokratesC Logik SchlickC Der Wiener Kreis2 2137KantC474630Die 3 Kritiken4

11 Beispiel 2: Bessere" Relationenschemata Sokrates zieht um, von Raum 226 in R 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? Datenbanken, SS 12Kapitel 7: Relationale Entwurfstheorie11 Professoren PersNrNameRangRaum 2125SokratesC RusselC KopernikusC PopperC AugustinusC3309 Vorlesungen VorlNrTitelSWSgelesen Von 5001Grundzüge Ethik Erkenntnistheorie Mäeutik Logik42125

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

13 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 12Kapitel 7: Relationale Entwurfstheorie13

14 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 12Kapitel 7: Relationale Entwurfstheorie14

15 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 12Kapitel 7: Relationale Entwurfstheorie15

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

17 Datenbanken, SS 12Kapitel 7: Relationale Entwurfstheorie17 Beispiel Stammbaum KindVaterMutterOpaOma SofieAlfonsSabineLotharLinde SofieAlfonsSabineHubertLisa NiklasAlfonsSabineLotharLinde NiklasAlfonsSabineHubertLisa... LotharMartha …………… Was ist das Problem?

18 Datenbanken, SS 12Kapitel 7: Relationale Entwurfstheorie18 Beispiel 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 Stammbaum KindVaterMutterOpaOma SofieAlfonsSabineLotharLinde SofieAlfonsSabineHubertLisa NiklasAlfonsSabineLotharLinde NiklasAlfonsSabineHubertLisa... LotharMartha ……………

19 Datenbanken, SS 12Kapitel 7: Relationale Entwurfstheorie19 Beispiel Stammbaum KindVaterMutterOpaOma SofieAlfonsSabineLotharLinde SofieAlfonsSabineHubertLisa NiklasAlfonsSabineLotharLinde NiklasAlfonsSabineHubertLisa... LotharMartha …………… Wie kann man die Relation verändern, dass die Probleme nicht mehr auftreten?

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

21 Datenbanken, SS 12Kapitel 7: Relationale Entwurfstheorie21 Verlustlose Zerlegung – Die Informationen bleiben erhalten Eltern VaterMutterKind JohannMarthaElse JohannMariaTheo HeinzMarthaCleo SELECT Vater, Kind FROM Eltern VaterKind JohannElse JohannTheo HeinzCleo SELECT Mutter, Kind FROM Eltern MutterKind MarthaElse MariaTheo MarthaCleo Natural Join VaterMutterKind JohannMarthaElse JohannMariaTheo HeinzMarthaCleo

22 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 Datenbanken, SS 12Kapitel 7: Relationale Entwurfstheorie22 Vater 1 * Mutter Kind * 1 Vater 1 * Mutter Kind * 1

23 Datenbanken, SS 12Kapitel 7: Relationale Entwurfstheorie23 Biertrinker-Beispiel Biertrinker LokalGastBier EinsteinGniffkePils EinsteinAndersHefeweizen MephistoGniffkeHefeweizen

24 Datenbanken, SS 12Kapitel 7: Relationale Entwurfstheorie24 Biertrinker-Beispiel: Informationsverlust Biertrinker LokalGastBier EinsteinGniffkePils EinsteinAndersHefeweizen MephistoGniffkeHefeweizen SELECT Lokal, Gast FROM Biertrinker LokalGast EinsteinGniffke EinsteinAnders MephistoGniffke SELECT Gast, Bier FROM Biertrinker GastBier GniffkePils AndersHefeweizen GniffkeHefeweizen Natural Join LokalGastBier EinsteinGniffkePils EinsteinGniffkeHefeweizen EinsteinAndersHefeweizen MephistoGniffkePils MephistoGniffkeHefeweizen

25 Datenbanken, SS 12Kapitel 7: Relationale Entwurfstheorie25 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?

26 Datenbanken, SS 12Kapitel 7: Relationale Entwurfstheorie26 Verlustige Zerlegung – Die Informationen sind weg! Eltern VaterMutterKind JohannMarthaElse JohannMariaTheo HeinzMarthaCleo SELECT Vater, Kind FROM Eltern VaterKind JohannElse JohannTheo HeinzCleo SELECT Mutter FROM Eltern Mutter Martha Maria Martha Natural Join

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

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

29 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 Datenbanken, SS 12Kapitel 7: Relationale Entwurfstheorie29 Aus Wikipedia (Stern_Schema)

30 Triplifizierung (vereinfacht) Vor- und Nachteile? Es ist alles in einer Tabelle Es ist alles maximal normalisiert Datenbanken, SS 12Kapitel 7: Relationale Entwurfstheorie30 TripleStore SubjektPrädikatObjekt ProfessorhatPrädikathatRaum SokratesistInstanzVonProfessor SokrateshatRaum226 hatRaumhatObjektTypinteger SokrateshältVorlesungEthik hatSWS4 hörthatSubjektTypMensch ProfessoristEinMensch StudentistEinMensch hörthatObjektTypVorlesung CarnaphörtEthik CarnapistInstanzVonStudent ………

31 Triplifizierung (vereinfacht) Woher weiß ich, ob die Daten überhaupt stimmen? Woher weiß ich, was Daten sind und was zur Struktur gehört? Datenbanken, SS 12Kapitel 7: Relationale Entwurfstheorie31 TripleStore SubjektPrädikatObjekt ProfessorhatPrädikathatRaum SokratesistInstanzVonProfessor SokrateshatRaum226 hatRaumhatObjektTypinteger SokrateshältVorlesungEthik hatSWS4 hörthatSubjektTypMensch ProfessoristEinMensch StudentistEinMensch hörthatObjektTypVorlesung CarnaphörtEthik CarnapistInstanzVonStudent ……… TripleStore SubjektPrädikatObjekt ProfessoristInstanznein SokratesistInstanzVonProfessor SokratesistInstanz???

32 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 12Kapitel 7: Relationale Entwurfstheorie32

33 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 12Kapitel 7: Relationale Entwurfstheorie33

34 Teil 2: Entwurfsmuster Datenbanken, SS 12Kapitel 7: Relationale Entwurfstheorie34

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

36 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 12Kapitel 7: Relationale Entwurfstheorie36

37 Listen 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) Datenbanken, SS 12Kapitel 7: Relationale Entwurfstheorie37 TODOs IDTitelnext 1aufräumen2 2Zur Uni gehen3 3Partynull TODOs IDTitelIndex 1aufräumen1 2Zur Uni gehen2 3Party3

38 Bäume 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 12Kapitel 7: Relationale Entwurfstheorie38 simplifiedDOM IDtypecontentparentnext 1elementhtmlnull 2elementhead13 3elementbody1null 4textTest!3null

39 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 , Datenbanken, SS 12Kapitel 7: Relationale Entwurfstheorie39

40 Bäume (Forts.) – Pre-post-table Datenbanken, SS 12Kapitel 7: Relationale Entwurfstheorie40 KindknotenVorgänger Nachfolger Elternknoten

41 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.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 12Kapitel 7: Relationale Entwurfstheorie41

42 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: ist der Elternknoten von Regel 2: Geschwister sind in der korrekten Reihenfolge abgelegt Beispiel: kommt vor Regel 3: Gerade Indexzahlen werden für Generationen ignoriert Beispiel: ist der direkte Elternknoten von 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 , 2004] wird eingesetzt von SQL Server Datenbanken, SS 12Kapitel 7: Relationale Entwurfstheorie42

43 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 12Kapitel 7: Relationale Entwurfstheorie43


Herunterladen ppt "Dr. Brigitte Mathiak Kapitel 7 Relationale Entwurfstheorie."

Ähnliche Präsentationen


Google-Anzeigen