Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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.

Ähnliche Präsentationen


Präsentation zum Thema: "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."—  Präsentation transkript:

1 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 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 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 5 Normalformen Ziel: Gute von schlechten Datenbank- Schemata unterscheiden können! Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

6 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 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 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 9 Normalformen Gute Datenbankschemata Unvermeidbarer Zielkonflikt zwischen der Forderung nach guter Performance und Redundanzfreiheit!!! Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

10 Mutationsanomalien

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

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

13 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 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 15 Mutationsanomalien Update in SQL UPDATE Abteilungsmitarbeiter SET Bezeichnung = 'Finance' WHERE Bezeichnung ='Finanz'; Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

16 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 17 Mutationsanomalien DELETE DELETE FROM Abteilungsmitarbeiter WHERE M# = M1; Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

18 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 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 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 21 Mutationsanomalien Beispiel 2 Update-Anomalie Beim Ä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 23 Funktionale Abhängigkeiten Definition Seien R(A 1,..., A n ) ein Relationenschema und und X,Y {A 1,..., A n }. 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(A 1,..., A n ). Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

24 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 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 26 Funktionale Abhängigkeiten Für Relationenschemata, die aus dem E/R- Design entstanden sind, ergeben sich folgende FDs: Repräsentiere R(A 1,..., A n ) den Entity-Typ R und sei X Schlüsselkandidat von R. dann gilt: X Y für alle Y {A 1,..., A n } Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

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

28 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 29 Funktionale Abhängigkeiten Beispiele für FDs triviale FD: {LName} aber auch: {LName, ArtName} {LAdresse, Preis} Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

30 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 31 Funktionale Abhängigkeiten Definition Erfüllung funktionaler Abhängigkeiten (extensional): Seien r eine Instanz von R(A 1,..., A n ), X,X {A 1,..., A n }. Die Instanz r erfüllt X Y, wenn für alle Tupel r gilt: [X] = [X] impliziert [Y] = [Y]. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

32 32 Funktionale Abhängigkeiten Bemerkung: Falls X Y für R gilt, so muß X Y in jedem r erfüllt sein. Falls X Y nicht gilt, kann X Y durch ein r erfüllt sein oder auch nicht. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

33 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.} Von Ausnahmefällen, wie z.B. {München, Dachauerstr } {München, Dachauerstr } wollen wir im folgenden abstrahieren. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

34 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 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 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 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 38 Funktionale Abhängigkeiten Volle Funktionale Abhängigkeit Eine Menge von Attributen B ist von einer Attributmenge A voll funktional abhängig, wenn gilt: 1)A B 2)es gibt kein A' mit A' A, A' A, mit: A' B Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

39 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 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 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 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 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 45 Normalformen (Beispiel) M#NameOrtP M7 M1 Huber Meier Basel Liestal {P1,P9} {P7,P11,P9} Projektmitarbeiter (unnormalisiert) M#NameOrtP# M7 M1 Huber Meier Basel Liestal P1 P9 P7 P11 P9 Projektmitarbeiter (in erster Normalform) 1NF

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

47 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 48 Normalformen (2NF) Zerlegung durch 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 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 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

51 51 Normalformen (3 NF) Dritte Normalform (3NF): Eine Tabelle ist in dritter Normalform, falls sie in 2NF ist und kein Nichtschlüsselattribut von irgendeinem Schlüsselkandidaten transitiv abhängig ist. Transitive Abhängigkeit heisst über Umwege funktional abhängig sein: A B und B C A C Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

52 52 Normalformen (3 NF) Dritte Normalform (3NF): Die dritte Normalform kann nur verletzt werden, wenn eine Relation neben dem Schlüssel (einfach oder zusammengesetzt) mindestens zwei zusätzliche Attribute hat, die keine Attribute eines Schlüsselkandidaten sind. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

53 53 Normalformen (3NF) Beispiel: (S1#, S2#, A, B) Voraussetzung: S1#, S2# sind die beiden Schlüsselattribute Falls S2# A ist die Relation nicht 2NF Falls A B ist die Relation nicht in 3NF Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

54 54 Normalformen (3NF) Beispiel: R ( S1#, S2#, A, B) Prof. Dr. Fabian Glasen, Datenbanken, Februar NF 2NF

55 55 Normalformen (3NF) Beispiel 2: mitarbeiter(emp_nr, name, ort, abt_nr, abt_name) Verletzt 3NF, wegen funktionaler Abhängigkeit zwischen abt_nr und abt_name Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

56 56 Normalformen (4NF / 5NF) Die Normalformen 4 und 5 sind in der Praxis von geringer Bedeutung und werden deshalb hier nicht behandelt. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

57 Zerlegungen

58 58 Zerlegung Durch eine geeignete Zerlegung eines schlechten Schemas kann man die bekannten Design-Anomalien beseitigen. Im folgenden identifizieren wir dazu ein Schema R(A 1,... A n ) mit der Menge seiner Attribute R={A 1, A 2,..., A n }. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

59 59 Zerlegung Definition (Zerlegung): Die Zerlegung eines Relationenschemas R = {A 1... A n } ist dessen Ersetzung durch eine Menge von Relationenschemata = {R 1,..., R k } mit R i R und R = R 1... R k. Die R i müssen dabei nicht disjunkt sein. Für eine gute Zerlegung sollte aber bestimmte Eigenschaften aufweisen Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

60 60 Zerlegung Beispiel (Zerlegung): L_INFO = {LName, LAdresse, ArtName, Preis}, LIEFERANT = {LName, LAdresse} und liefert = {LName, ArtName, Preis}. Offensichtlich ist = {LIEFERANT, liefert} eine Zerlegung von L_INFO. Diese Zerlegung bereinigte einige der in L_INFO aufgetretenen Anomalien. Umgekehrt stellt sich die Frage, ob man L_INFO eindeutig aus der Zerlegung zurückgewinnen kann? Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

61 61 Zerlegung Beispiel (Zerlegung mit Verlusten): Daß dies im allgemeinen nicht der Fall ist, zeigt folgendes Beispiel: Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002 AABBBCC r r1r2 Die Instanz r ist durch einen Natural Join aus den Projektionen r1 und r2 nicht rekonstruierbar.

62 62 Zerlegung Es gilt: = {R 1, R 2 } ist eine Zerlegung von R. r 1 = A,B (r), r 2 = B,C (r) Jedoch gilt: r r 1 |x| r1.B =r2.B r 2 Die Instanz r ist demnach im allgemeinen durch einen Natural Join aus den Projektionen r1 und r2 nicht rekonstruierbar. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

63 63 Zerlegung Definition (Verlustfreie Zerlegung bzgl. F): Sei = {R 1,..., R k } eine Zerlegung von R und F eine Menge von FDs auf R. Die Zerlegung besitzt einen verlustfreien Join bezüglich F, wenn für jede Instanz r von R, die F erfüllt, gilt: r = R1 (r) |x|... |x| Rk (r) Die Wiedergewinnung der ursprünglichen Information aus der Zerlegung ist also für solche möglich, die einen verlustfreien Join besitzen. heißt dann auch verlustfreie Zerlegung bzgl. F. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

64 64 Zerlegung Eine verlustfreie Zerlegung für jede Instanz r, die F erfüllt, erfordert: –keine dangling Tupel in den Projektionen, –vollständige Kombinationen in R. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

65 65 Zerlegung Beispiel 2 (Dangling Tupel): Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002 r AABBBCC r1r2 Ausgangspunkt: r1 und r2; r ist natural join von r1 und r2. Die anschliessende Zerlegung führt wieder zu einem Verlust. Ursache für den Verlust bei der Zerlegung sind in diesem Fall Tupel ohne natürlichen Joinpartner in r 2. Solche Tupel ((50,69) in r2) heissen auch dangling Tupel

66 Sichten / Views

67 67 Sichten (Views) Eine (Daten)Sicht ist eine virtuelle Tabelle. In Sichten werden Informationen aus mehreren Tabellen zusammen geführt. Eine Sicht wird nicht physikalisch langfristig gespeichert, sondern bei jeder Nutzung neu mittels einer zugeordneten Abfrage aus den aktuellen Daten der involvierten Tabellen neu berechnet. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

68 68 Sichten (Views) Eine Datensicht verhält ich bei Abfragen wie eine reale Tabelle. Abfragen an Sichten können genau so formuliert werden wie Abfragen an Tabellen. Es sind Verbünde (Joins) mit anderen Tabellen oder Datensichten möglich. Sichten erlauben auch Datenmanipulationen Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

69 69 Sichten (Views) (Daten)Sichten gehören zum externen Schema des ANSI-SPARC-Architektur. Sie ermöglichen es zusammengehörige Daten für den Benutzer wieder zusammenhängend zugänglich zu machen, so dass sich dieser nicht um das redundanzarme konzeptionelle Schema kümmern muss. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

70 70 Sichten (Views) Resultate von Berechnungen werden nicht in die Basisrelationen des logischen (konzeptionellen) Datenbankschemas aufgenommen. Sie können aber sinnvoll in Sichten eingebracht und so auch weiter verarbeitet werden – solche Sichten erlauben allerdings keine Updates Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

71 71 Sichten (Views) Datensichtdefinition in SQL (Syntax): CREATE VIEW viewname [(spaltenliste)] AS abfrage [WITH [CASCADED | LOKAL] CHECK OPTION] abfrage ist dabei eine beliebige Abfrage. Die ORDER BY-Klausel ist darin nicht zulässig. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

72 72 Sichten (Views) Die Angabe der Spaltennamen (spaltenliste) kann entfallen, wenn die Spaltennamen der abfrage übernommen werden sollen. WITH CHECK OPTION formuliert Integritätsregeln für UPDATE- Operationen. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

73 73 Sichten (Views) Beispiel: CREATE VIEW kundenadr AS SELECT kundennr, name, strasse, plz,ort FROM kunde; SELECT * FROM kundenadr ORDER BY kundennr Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

74 74 Sichten (Views) CREATE VIEW rechnung AS SELECT be.bestellnr, be.lieferdatum AS datum, po.bestellmenge, po.liefermenge AS menge, po.mwst,po.gesamtpreis AS preis, ku.kundennr,ku.name,ku.strasse, ku.plz, ku.ort, ar.artikelnrar.verpackkung AS packung, ar.bezeichnungar.lagerplatz AS lager FROM bestellung be JOIN kunde ku ON be.kundennr = ku.kundennr JOIN position po ON be.bestellnr = po.bestellnr Join artikel ar ON po.artikelnr = ar.artikelnr WHERE be.lieferdatum IS NOT NULL; Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

75 75 Sichten (Views) Mit der View rechnung lässt sich sehr einfach eine Rechnung drucken" z.B.: SELECT bestellnr, datum, menge, preis, name, artikelnr FROM rechnung WHERE bestellnr = 4711; Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

76 76 Sichten (Views) CHECK OPTION Änderung von Daten mittels Sichten CREATE VIEW kunden_freiburg AS SELECT kundennr, name, strasse, plz, ort FROM kunde WHERE ort = Freiburg; UPDATE kunden_freiburg SET ort=Offenburg WHERE kundennr = 3612; Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

77 77 Sichten (Views) CHECK OPTION Die UPDATE-Anweisung führt dazu, dass Kunde 3612 nicht mehr in der Sicht kunden_freiburg auftaucht. Durch die CHECK OPTION kann ein solches Update verhindert werden. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

78 78 Sichten (Views) CHECK OPTION CREATE VIEW kunden_freiburg AS SELECT kundennr, name, strasse, plz,ort FROM kunde WHERE ort = Freiburg WITH CHECK OPTION; Ein Update wie vorher geschildert, wird dadurch zurück gewiesen. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

79 79 Sichten (Views) Aus Normalisierungsgründen werden beim logischen Datenbankentwurf meist keine Spalten in den Basisrelationen aufgenommen, die durch Berechnungen aus vorhandenen Attributwerten einzelner Tupel abzuleiten sind. Beispiel: Wert des Lagerbestandes pro Artikel bestandswert = listenpreis * bestand Mit Sichten ist dies jedoch sinnvoll möglich! Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

80 80 Sichten (Views) Folgende Sicht zeigt den berechnetenbestandswert an. CREATE VIEW artikel_bestandswert AS SELECT artikelnr, listenpreis, bestand, listenpreis * bestand AS bestandswert FROM artikel; In der Spaltebestandswert sind automatisch keine Update und INSERT-Operation zulässig. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002

81 Bibliotheks- anwendung

82 82 BuchAutor Buch- auflage Buch- exemplar Benutzer hat vorgemerkt leiht aus Autor von Schlagwort von ISBNTitel Verlag ANrName Vorname SNr Wort BNrName Adresse Vorname BibNr Auflage Preis hatAufl hatExemp n m n m 1 n 1 nm 1 n m Standort Ort Jahr Datum ?

83 83 Tabellenmodell Autor(Anr, Name, Vorname) Buch(ISBN, Titel, Verlag, Ort) Autor-von(Anr, ISBN) Schlagwort(SNr, Wort) Schlagwort-von(SNr, ISBN) Buchauflage(Auflage, Preis, Jahr, ISBN) Buchexemplar(BibNr, Standort, ISBN, Auflage) Benutzer(BNr, Name, Vorname, Adresse) Leiht-aus(BibNr, BNr, Datum) Hat-vorgemerkt(BNr, BibNr, Datum)

84 84 Autor CREATE TABLE Autor ( ANr INTEGER PRIMARY KEY, Name CHAR(30) NOT NULL, Vorname CHAR(30) );

85 85 Buch CREATE TABLE Buch ( ISBN INTEGER PRIMARY KEY, Verlag CHAR(30) NOT NULL, Titel CHAR(30) NOT NULL, Ort CHAR(30) );

86 86 Autor-von CREATE TABLE Autor-von ( ISBNINTEGER, ANrINTEGER, PRIMARY KEY ( ISBN, ANr), FOREIGN KEY ISBN REFERENCES Buch ON DELETE CASCADE ON UPDATE CASCADE, FOREIGN KEY ANr REFERENCES Autor ON DELETE CASCADE ON UPDATE CASCADE );

87 87 Schlagwort CREATE TABLE Schlagwort ( SNr INTEGER PRIMARY KEY, Wort CHAR(30) NOT NULL );

88 88 Schlagwort von CREATE TABLE Schlagwort-von ( ISBN INTEGER FOREIGN KEY REFERENCES Buch, SNr INTEGER FOREIGN KEY REFERENCES Schlagwort, PRIMARY KEY ( ISBN, SNr) );

89 89 Buchauflage CREATE TABLE Buchauflage ( ISBNINTEGER, Auflage INTEGER, Preis NUMERIC(8,2), Jahr CHAR(4), PRIMARY KEY(ISBN, Auflage), FOREIGN KEY ISBN REFERENCES Buch ON DELETE CASCADE ON UPDATE CASCADE);

90 90 Buchexemplar CREATE TABLE Buchexemplar ( BibNR INTEGER PRIMARY KEY, Standort CHAR(10), ISBNINTEGER NOT NULL, AuflageINTEGER NOT NULL, FOREIGN KEY ISBN REFERENCES Buchauflage ON DELETE CASCADE ON UPDATE CASCADE, FOREIGN KEY Auflage REFERENCES Buchauflage ON DELETE CASCADE ON UPDATE CASCADE );

91 91 Benutzer CREATE TABLE Benutzer ( BNr INTEGER PRIMARY KEY, Name CHAR(30) NOT NULL, Vorname CHAR(30) NOT NULL, Adresse CHAR(60) NOT NULL );

92 92 Leiht-aus CREATE TABLE leiht-aus ( BibNr INTEGER FOREIGN KEY REFERENCES Buchexemplar, BNr INTEGER FOREIGN KEY REFERENCES Benutzer, PRIMARY KEY (BNr, BibNr) );

93 93 Hat-vorgemerkt CREATE TABLE hat-vorgemerkt ( BibNr INTEGER FOREIGN KEY REFERENCES Buchexemplar, BNr INTEGER FOREIGN KEY REFERENCES Benutzer, DatumDATE, PRIMARY KEY (BNr, BibNr) );

94 94 Bibliothek SQL-Aufgaben Buch einfügen: (Andreas Meier, Relationale Datenbanken, Springer, Berlin, 4. Auflage, 2001, ISBN= , (Schlagworte: Datenbank, Informatik), Preis DM, Bibliotheksnr 111) Buch updaten Ändern Sie das zugeordnete Schlagwort "Datenbank" des eingegebenen Buches mit einem SQL-Kommando in "Relationale Datenbank" ab

95 95 Bibliothek SQL-Aufgaben INSERT INTO Buch (ISBN, Titel, Verlag, Ort) VALUES ( , 'Relationale Datenbanken', 'Springer', 'Berlin'); INSERT INTO Buchauflage (ISBN, Auflage, Preis, Jahr) VALUES ( , 4, 45.90, '2001'); INSERT INTO Buchexemplar (ISBN, Auflage, BibNr, Standort) VALUES ( , 4, 111, NULL);

96 96 Bibliothek SQL-Aufgaben INSERT INTO Schlagwort (SNr,Wort) VALUES (1, 'Datenbank'), (2, 'Informatik'); INSERT INTO Schlagwort-von (SNr,ISBN) VALUES (1, ), (1, ); Update Schlagwort SET Wort = 'Relationale Datenbank' WHERE SNr =1

97 97 Bibliothek SQL-Aufgaben Benutzer erfassen: (Peter Georgi, Konstanz Inselgasse 25) Benutzer updaten (Peter Georgi Konstanz Obere Laube 22) Benutzer löschen (Peter Georgi Konstanz Obere Laube 22) Buch löschen (Andreas Meier...)

98 98 Bibliothek SQL-Aufgaben Benutzer erfassen: (Peter Georgi, Konstanz Inselgasse 25) INSERT INTO Benutzer (BNr, Name, Vorname, Adresse) VALUES (1, ' Georgi ', ' Peter ' ' Konstanz Inselgasse 25 ' );

99 99 Bibliothek SQL-Aufgaben Benutzer updaten: (Peter Georgi, Konstanz Obere Laube 22) UPDATE Benutzer SET Adresse = ' Konstanz Obere Laube 22 ' WHERE BNr=1;

100 100 Bibliothek SQL-Aufgaben Benutzer / Buch löschen: DELETE FROM Benutzer WHERE BNr = 1; DELELTE FROM Buch WHERE ISBN= ;

101 101 Bibliothek SQL-Aufgaben Ausleihe Benutzer Peter Georgi leiht das erfasste Buch von Andreas Meier am aus. Vormerkung Marianne Weber merkt das erfasste Buch am vor. Rückgabe Peter Georgi gibt das Buch am zurück.

102 102 Bibliothek SQL-Aufgaben Ausleihe Benutzer Peter Georgi leiht das erfasste Buch von Andreas Meier am aus. INSERT INTO leiht-aus (BibNr, BNr, Datum) VALUES (111,1,DATE ' ' );

103 103 Bibliothek SQL-Aufgaben Vormerkung Marianne Weber merkt das bereits erfasste Buch am vor. INSERT INTO Benutzer (BNr,Name, Vorname,Adresse) (2, ' Weber ', ' Marianne ', ' Konstanz Konradigasse 7 ' ); INSERT INTO hat-vorgemerkt (BibNr,BNr,Datum) VALUES (111,2,DATE ' ' );

104 104 Bibliothek SQL-Aufgaben Rückgabe Peter Georgi gibt das Buch am zurück. DELETE FROM leiht-aus WHERE BibNr=111;


Herunterladen ppt "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."

Ähnliche Präsentationen


Google-Anzeigen