1 / 104

Rückblick

Rückblick. SELECT mit mehreren Relationen Inner Join CROSS JOIN NATURAL JOIN CONDITION JOIN COLUMN NAME JOIN Self Join Outer Join LEFT OUTER JOIN RIGHT OUTER JOIN FULL OUTER JOIN. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002. Rückblick. ORDER BY (asc / desc)

sinead
Download Presentation

Rückblick

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Rückblick SELECT mit mehreren Relationen • Inner Join • CROSS JOIN • NATURAL JOIN • CONDITION JOIN • COLUMN NAME JOIN • Self Join • Outer Join • LEFT OUTER JOIN • RIGHT OUTER JOIN • FULL OUTER JOIN Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  2. Rückblick • ORDER BY (asc / desc) • NULL-Werte und 3wertige Logik • IS NULL • IS NOT NULL • Wahrheitswerte für Terme • Wahrheitswerte für Vergleichsausdrücke • Wahrheitswerte für logische Ausdrücke • Wahrheitstabellen (Wahrheitstafeln) Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  3. Ausblick • Funktionale Abhängigkeiten • Normalformen • Zerlegungen • Sichten / Views • Übungen Bibliothek Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  4. Normalformen Funktionale Abhängigkeiten Zerlegungen

  5. Normalformen Ziel: Gute von schlechten Datenbank-Schemata unterscheiden können! Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  6. Normalformen Gesucht: ein zuverlässiges Verfahren zur Erkennung eines schlechten Schemadesigns ein zuverlässiges Verfahren zur Erzeugung eines guten Schemadesigns Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  7. Normalformen Gute Datenbankschemata • ermöglichen die Herleitung aller benötigten Daten aus den Basisrelationen • schränken die Möglichkeit inkonsistente Daten darzustellen weitgehend ein • stellen die Daten möglichst redundanzfrei dar • ermöglichen gute Performance bei Zugriffen • verhindern Mutationsanomalien Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  8. Normalformen Durch die Zerlegung von Tabellen wird für manche Queries ein zusätzlicher Join notwendig. Dies beeinträchtigt die Performance!!! Folglich müssen triftige Gründe für eine Zerlegung vorliegen, um die potentiellen Performanceverluste aufzuwiegen. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  9. Normalformen Gute Datenbankschemata Unvermeidbarer Zielkonflikt zwischen der Forderung nach guter Performance und Redundanzfreiheit!!! Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  10. Mutationsanomalien

  11. Mutationsanomalien • Einfügeanomalien (Insert-Anomalie) • Änderungsanomalien (Update-Anomalie) • Löschanomalien (Delete-Anomalie) Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  12. M# Name Strasse Ort A Bezeichnung Zürich Liestal Basel Liestal A6 A3 A5 A6 Finanz Informatik Personal Finanz M19 M1 M7 M4 Schweizer Meier Huber Becker Hauptstrasse Lindenstrasse Mattenweg Wasserweg Mutationsanomalien (Beispiel 1) Abteilungsmitarbeiter Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  13. Mutationsanomalien Einfügeanomalie Falls man eine neue Abteilung z.B. A9 mit dem Namen „Marketing“ erfassen will, ist dies nur möglich, wenn man auch einen Mitarbeiter dafür erfasst, auch wenn es noch keinen gibt. Ein NULL-Wert für Mitarbeiter ist nicht möglich, da M# Teil des Schlüssels ist. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  14. Mutationsanomalien Änderungsanomalie Soll z.B. die Bezeichnung der Abteilung A6 von „Finanz“ in „Finance“ geändert werden, muss die Änderung bei sämtlichen Mitarbeitertupeln der Abteilung vollzogen werden, obwohl sich nur ein einziger Sachverhalt ändert. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  15. Mutationsanomalien Update in SQL UPDATE Abteilungsmitarbeiter SET Bezeichnung = 'Finance' WHERE Bezeichnung ='Finanz'; Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  16. Mutationsanomalien Löschanomalie eine Löschanomalie liegt vor, wenn eine Information ungewollt verloren geht. Wenn man z.B: in der Tabelle „Abteilungsmitarbeiter“ Mitarbeiter M1 löscht, geht die Abteilung „Informatik mit der Abteilungsnummer „A3“ verloren. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  17. Mutationsanomalien DELETE DELETE FROM Abteilungsmitarbeiter WHERE M# = M1; Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  18. Mutationsanomalien Um Probleme der Redundanz und die dabei auftretenden Änderungsanomalien in den Griff zu bekommen, bietet sich folgende Lösung an: • Es wird eine Überführung des Ausgangsschemas in spezielle andere Schemata vorgenommen, die die genannten Probleme nach Möglichkeit vermeiden. Dies entspricht einer Zerlegung in Normalformen. (Normalisierung) Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  19. Mutationsanomalien Beispiel 2 Angenommen, wir hätten LIEFERANT(LName, LAdresse) liefert(LName, ArtName, Preis) zusammengefaßt in L_INFO(LName, LAdresse, ArtName, Preis) Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  20. Mutationsanomalien Beispiel 2 Die Lieferantenadresse „LAdresse“ muß dann für jede Lieferung wiederholt werden. Dies führt zu potentiellen Inkonsistenzen infolge von Redundanz. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  21. Mutationsanomalien Beispiel 2 • Update-AnomalieBeim Ändern der Adresse LAdresse muß dies in jedem Tupel geschehen, in dem der zugehörige Lieferant vorkommt. • Insert-Anomalie:Ein Lieferant mit Adresse kann nicht erfaßt werden, wenn er momentan noch nichts liefert. NULL für ArtName ist nicht erlaubt, da ArtName Teil des Schlüssels ist • Delete-Anomalie:Falls man die Artikel eines Lieferanten löscht, verliert man ungewollt auch dessen Adresse Bei einer Zerlegung von „L_INFO“ in „Lieferant“ und „liefert“ verschwinden diese Probleme. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  22. Funktionale Abhängigkeit Zwischen Attributen einer Tabelle

  23. Funktionale Abhängigkeiten Definition Seien R(A1, ..., An) ein Relationenschema und und X,Y  {A1, ..., An}. Y heißt funktional abhängig von X (geschrieben X  Y) genau dann, wenn gleiche Attributwerte für X auch gleiche Attributwerte für Y erzwingen. X  Y heißt dann FD (functional dependency) für R(A1, ..., An). Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  24. Funktionale Abhängigkeiten Die Definition ist „identisch“ mit der mathematischen Definition einer Funktion: f: X Y / f  X x Y ( x  X,  y, z  Y: (x,y)  f und (x,z)  f )  y = z (Zu einem Zeitpunkt / in einem DB-Zustand) Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  25. Funktionale Abhängigkeiten Beispiel (L_INFO) LName LAdresse ArtName Preis 'Kahn' 'Seestr. 9' 'Käse' 1.99 'Kahn' ??? 'Wurst' 1.19 Ist der Attributwert ??? irgendwie herleitbar? Da LName Primärschlüssel in LIEFERANT ist, wissen wir, daß „LAdresse“ von LName funktional abhängig ist. Folglich muß ??? gleich Seestr. 9 sein. Die Redundanz wurde durch die FD {Lname}  {LAdresse} bewirkt. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  26. Funktionale Abhängigkeiten Für Relationenschemata, die aus dem E/R-Design entstanden sind, ergeben sich folgende FDs: Repräsentiere R(A1, ..., An) den Entity-Typ R und sei X Schlüsselkandidat von R. dann gilt: X  Y für alle Y  {A1, ..., An } Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  27. Funktionale Abhängigkeiten Für Relationenschemata, die aus dem E/R-Design entstanden, ergeben sich folgende FDs: Repräsentiere R(A1, ..., An) eine N:1-Relationship zwischen E1 und E2 und habe E1 den SchlüsselkandidatenX. dann gilt: X  Y für alle Y  {A1, ..., An } Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  28. Funktionale Abhängigkeiten Beispiele für FDs • In LIEFERANT gilt:{LName}  {LAdresse}. • In liefert gilt:{LName, ArtName}  {Preis}. • In KUNDE gilt:{KName}  {KAdresse, Saldo}. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  29. Funktionale Abhängigkeiten Beispiele für FDs triviale FD: {LName}  {LName} aber auch: {LName, ArtName}  {LAdresse, Preis} Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  30. Funktionale Abhängigkeiten Bemerkung: • FDs sind Zusicherungen über die Semantik der ,,realen Welt``, d.h. sie sind nicht beweisbar. (intensional) • Manche FDs werden automatisch vom DBS überwacht, wie z.B. der Primärschlüssel Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  31. Funktionale Abhängigkeiten Definition Erfüllung funktionaler Abhängigkeiten (extensional): Seien r eine Instanz von R(A1, ..., An), X,X  {A1, ..., An}. Die Instanz rerfüllt X  Y , wenn für alle Tupel    r gilt: [X] =[X] impliziert [Y] = [Y]. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  32. Funktionale Abhängigkeiten Bemerkung: • Falls X  Yfür R gilt, so muß X  Yin jedemr erfüllt sein. • Falls X  Ynicht gilt, kann X  Ydurch ein r erfüllt sein oder auch nicht. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  33. Funktionale Abhängigkeiten Beispiel (Postleitzahlen): Wir betrachten die deutschen Postleitzahlen. In den meisten Fällen ist die Postleitzahl durch Stadt und Straße eindeutig bestimmt, z.B. {München, Dachsteinstr.}  81825 Von Ausnahmefällen, wie z.B. {München, Dachauerstr. 1-147} 80335 {München, Dachauerstr. 149-181} 80636 wollen wir im folgenden abstrahieren. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  34. Funktionale Abhängigkeiten Sei PLZBUCH(Stadt,Straße,PLZ) gegeben mit den nicht-trivialen FDs F= { {Stadt,Straße}  {PLZ}, {PLZ}  {Stadt} }. wir können von folgenden Mengen von Schlüsselkandidaten ausgehen: schlüsselkand(PLZBUCH) = {{Stadt,Straße},{PLZ}} Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  35. Funktionale Abhängigkeiten Für die funktionale Abhängigkeit gelten für Attributmengen A, B einer Relation R folgende Regeln: A  B   bB A  {b} Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  36. Funktionale Abhängigkeiten Für die funktionale Abhängigkeit gelten für Attributmengen A, B, C einer Relation R folgende Regeln: A  B  B  A (triviale FD) A  B  A  C  B  C A  B und B  C  A  C (Armstrongsche Regeln) Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  37. Funktionale Abhängigkeiten Wenn S ein Schlüssel von R ist, dann gilt für alle B: S  B Wenn S  S' dann gilt: S'  B Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  38. Funktionale Abhängigkeiten Volle Funktionale Abhängigkeit Eine Menge von Attributen B ist von einer Attributmenge A voll funktional abhängig, wenn gilt: • A B • es gibt kein A'mit A' A, A'  A, mit: A'  B Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  39. Funktionale Abhängigkeiten Mit Hilfe der vollen Funktionalen Abhängigkeit lässt sich der Begriff des Schlüsselkandidaten präzise definieren: Eine Menge von Attributen A einer Relation R ist Schlüsselkandidat der Relation R, wenn für jede Menge B von Attributen von R gilt: B ist voll funktional abhängig von A. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  40. Normalformen

  41. Normalformen (1NF) erste Normalform Eine Relation ist in erster Normalform (1NF), wenn alle ihre Attribute nur atomare (elementare) Attributwerte besitzen. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  42. Normalformen (2NF) Zweite Normalform (2NF): Eine Tabelle ist in zweiter Normalform, wenn jedes nicht dem Schlüssel angehörende Attribut funktional abhängig ist vom Gesamtschlüssel nicht aber von den Schlüsselteilen d.h: es gibt kein Attribut ausserhalb des Schlüssels, das schon von einem Teil des Schlüssels funktional abhängig ist. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  43. Normalformen Zweite Normalform (2NF): Eine Tabelle ist in zweiter Normalform, wenn sie in erster Normalform ist und wenn jedes Nichtschlüsselattribut von jedem Schlüsselkandidaten voll funktional abhängig ist. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  44. Normalformen (2NF) Ein Attribut ist voll funktional abhängig von einem zusammengesetzten Schlüsselkandidaten, falls es nicht funktional abhängig ist von einem Teil des Schlüsselkandidaten. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  45. M# Name Ort P M7 M1 Huber Meier Basel Liestal {P1,P9} {P7,P11,P9} Projektmitarbeiter (unnormalisiert) M# Name Ort P# M7 M7 M1 M1 M1 Huber Huber Meier Meier Meier Basel Basel Liestal Liestal Liestal P1 P9 P7 P11 P9 Projektmitarbeiter (in erster Normalform) Normalformen (Beispiel) 1NF

  46. M# Name Ort P# M7 M7 M1 M1 M1 Huber Huber Meier Meier Meier Basel Basel Liestal Liestal Liestal P1 P9 P7 P11 P9 Projektmitarbeiter (in erster Normalform) M# P# M# Name Ort M7 M7 M1 M1 M1 P1 P9 P7 P11 P9 M7 M1 Huber Meier Basel Liestal Mitarbeiter (2NF) Zugehörigkeit (2NF) Normalformen (1 NF) (2 NF)

  47. Normalformen (2NF) Zweite Normalform (2NF):die 2 NF kann nur verletzt werden • wenn eine Relation einen zusammengesetzten Schlüssel hat • und die Relation mindestens ein Attribut besitzt, das nicht zum Schlüssel gehört Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  48. Normalformen (2NF) Zerlegungdurch Zerlegung der Ausgangsrelation in eine Relation mit voll funktional abhängigen Attributen und eine weitere Relation mit teilabhängigen Attributen können Relationen in der 2. NF gewonnen werden. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  49. Normalformen (2NF) Alternative Formulierung A ist ein Primattribut, wenn A Element eines Schlüsselkandidaten ist. R ist in 2 NF, wenn es keine nicht-trivialen funktionalen Abhängigkeiten T  A gibt, wobei T eine echte Untermenge eines Schlüsselkandidaten ist und A kein Primattribut enthält. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

  50. Normalformen (3 NF) Dritte Normalform (3NF):Eine Tabelle ist in dritter Normalform, wenn sie in zweiter Normalform ist und keine funktionalen Abhängigkeiten zwischen Attributen erlaubt, die keine Schlüsselattribute sind. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

More Related