Programmierung und Datenbanken II

Transkript

1 Programmierung und Datenbanken II

2 Wiederholung Was haben wir bisher getan? Anwendungsbereich analysiert Datenobjekte + Beziehungen identifiziert Modelle erstellt Modellhafte Aufbereitung der Analyse (ERM/SERM) Überführung in Relationenschema Datenbankserver eingerichtet Server läuft Tabellenstruktur mithilfe von SQL angelegt 2

3 Agenda Das Relationenschema Schlüsselattribute Vom (S)ER-Modell zum Relationenmodell Schlüsselvererbung Motivation Funktionale Abhängigkeit 1. Normalform 2. Normalform 3. Normalform 3

4 Relationen-Schema Beispielrelation Städte Name Einwohner Land München Bayern Dresden Sachsen Düsseldorf NRW Name Einwohner Städte Land Leipzig Sachsen Als Relationenschema: Schema: Städte (Name, Einwohner, Land) Ausprägung: {(München, , Bayern), (Dresden, , Sachsen), (Düsseldorf, , NRW), (Leipzig, , Sachsen)} 4

5 Begriffe des Relationenmodells Städte Name Einwohner Land München Bayern Dresden Sachsen Düsseldorf NRW Leipzig Sachsen Attributwert oder Datum (Zelle) Meier Relationale und postrelationale Datenbanken Relationenenname (Tabellenname) Merkmal oder Attribut (Spalte) Tupel oder Datensatz (Zeile) 5

6 Formale Definition 6

7 Agenda Das Relationenschema Schlüsselattribute Vom (S)ER-Modell zum Relationenmodell Schlüsselvererbung Qualitätssicherung in Datenmodellen Motivation Funktionale Abhängigkeit 1. Normalform 2. Normalform 3. Normalform 7

8 Schlüsselattribute Tupel (Datensätze) müssen eindeutig identifiziert werden Warum? z.b. für Verweise PNR Name Vorname Fachgruppe 001 Günthe r 002 Buscher Udo Thomas 003 Esswein Werner FNR 01 BWL 02 WI 03 VWL Fachgruppennam e Im relationalen Modell werden Datensätze anhand von Attributwerten identifiziert Konsequenz: Attribut[e] als Schlüssel kennzeichnen à werden unterstrichen! 8

9 Schlüsselattribute Beispiel: PNR und FNR werden Primärschlüssel ihrer Relationen PNR Name Vorname Fachgruppe 001 Günthe r 002 Buscher Udo Thomas 003 Esswein Werner FNR 01 BWL 02 WI 03 VWL Fachgruppennam e Damit müssen die Werte dieser Attribute eindeutig sein! Verweis erfolgt durch den Wert des Schlüsselattributs: PNR Name Vorname Fachgruppe 001 Günthe r Thomas Buscher Udo 01 FNR 01 BWL 02 WI Fachgruppennam e 003 Esswein Werner VWL 9

10 Schlüsselattribute Oft ist ein einzelnes Attribut als Schlüssel nicht ausreichend, da es nicht eindeutig VNR Titel Semester 012 Einführung in die Wirtschaftsinformatik WS 10/ Einführung in die Wirtschaftsinformatik WS 11/ Jahresabschluss WS 10/

11 Schlüsselattribute Oft ist ein einzelnes Attribut nicht ausreichend, da nicht eindeutig LNR VNR Titel Semester 012 Einführung in die Wirtschaftsinformatik WS 10/ Einführung in die Wirtschaftsinformatik WS 11/ Jahresabschluss WS 10/ Alternative 1: Hinzufügen eines künstlichen, eindeutigen Attributs (ID) als Schlüssel 11

12 Schlüsselattribute Oft ist ein einzelnes Attribut nicht ausreichend, da nicht eindeutig VNR Titel Semester 012 Einführung in die Wirtschaftsinformatik WS 10/ Einführung in die Wirtschaftsinformatik WS 11/ Jahresabschluss WS 10/ Alternative 2: Kombination mehrerer Attribute unter Berücksichtigung der kombinierten Eindeutigkeit Im Beispiel: VNR, Semester 12

13 Schlüsselattribute 13

14 Schlüsselattribute Minimalität bedeutet nicht: Schlüssel mit den wenigsten Attributen Sondern: Schlüssel enthält keine überflüssigen Attribute (solche, die zur Eindeutigkeit nichts beitragen) Manchmal gibt es mehrere verschiedene Schlüssel {LNR} {VNR, Semester} à diese nennt man Schlüsselkandidaten 14

15 Agenda Das Relationenschema Schlüsselattribute Vom (S)ER-Modell zum Relationenmodell Schlüsselvererbung Motivation Funktionale Abhängigkeit 1. Normalform 2. Normalform 3. Normalform 15

16 ER-Modell à Relationenmodell EntityTyp und Attribute Name Einwohner Land S-ID Städte Jedem E-Typ wird eine Relation zugeordnet Jedes Attribut des E-Typs wird ein Attribut der Relation Der Primärschlüssel (PK) des E-Typs wird Primärschlüssel der Relation Attribute können im weiteren Verlauf hinzukommen à Städte (S-ID, Name, Einwohner, Land) 16

17 ER-Modell à Relationenmodell RelationshipTyp Umsetzung ist abhängig von der Kardinalität 1:1 1:N } Zusätzliche Bez.-Attribute in bestehenden Relationen M:N Erzeugung einer zusätzlichen Relation Die ersten beiden Kardinalitäten sind Spezialfälle der dritten Deshalb ist es immer möglich, zusätzliche Relationen einzuführen Bei den ersten beiden kann man jedoch alternativ eine andere Überführung wählen 17

18 ER-Modell à Relationenmodell Beispiel: 1:N FNR PNR FNR PNR Fachgruppe 1 (0,*) beschäftigt N (1,1) Professor bzw. Fachgruppe Professor Der PK der Relation auf der 1-Seite kommt in die Relation auf der N-Seite (bei 1:1 kann die Seite beliebig gewählt werden): Fachgruppe (FNR,... ) FK-Vererbung Professor (PNR,..., FNR) 18

19 Schlüsselattribute Beispiel: PNR und FNR werden Primärschlüssel ihrer Relationen PNR Name Vorname Fachgruppe FNR Fachgruppenname 001 Günther Thomas 002 Buscher Udo 003 Esswein Werner 01 BWL 02 WI 03 VWL Damit müssen die Werte dieser Attribute eindeutig sein! Verweis zw. Relationen erfolgt durch den Wert des Schlüsselattributs: PNR Name Vorname Fachgruppe FNR Fachgruppenname 001 Günther Thomas Buscher Udo Esswein Werner BWL 02 WI 03 VWL 19

20 ER-Modell à Relationenmodell SNR SNR Beispiel: M:N Note PNR Student schreibt Note Student M (0,*) schreibt N (0,*) Prüfung bzw. Prüfung PNR Überführung des R-Typs in eine eigene Relation unter Vererbung der PK der beteiligten E-Typen Student (SNR,... ) Prüfung (PNR,... ) Schreibt (SNR, PNR, Note) PK-Vererbung 20

21 ER-Modell à Relationenmodell Student SNR Name Vorname Müller Thomas Meier Max Schulze Christian... Prüfung PNR Fach Datum EWI Programmierung II Mikro II Schreibt SNR PNR Note , , , ,0 21

22 Agenda Das Relationenschema Schlüsselattribute Vom ER-Modell zum Relationenmodell Schlüsselvererbung Motivation Funktionale Abhängigkeit 1. Normalform 2. Normalform 3. Normalform 22

23 Schlüsselvererbung Realisierung von Beziehungen zwischen Datenobjekttypen, durch Weitergabe der Primärschlüssel Richtung der Vererbung: SERM Leserichtung Arten der Schlüsselvererbung: Vererbungsart PK Schlüssel ist in erbendem DOT FK und gleichzeitig Bestandteil des PK Vererbungsart FK Schlüssel ist in erbendem DOT lediglich FK und nicht Bestandteil des PK Vererbungsart ist kontextabhängig, kann nicht formal bestimmt werden 23

24 Schlüsselvererbung im SERM 1/3 PKA A B PK PK C Schlüsselbeziehungen A(PKA,...) B(PKB,...) C(PKA,PKB,...) PKB 24

25 Schlüsselvererbung im SERM 2/3 PKA PKC A B PK PK C Schlüsselbeziehungen A(PKA,...) B(PKB,...) C(PKA,PKB,...) oder C(PKA,PKB,PKC,...) PKB 25

26 Schlüsselvererbung im SERM 3/3 PKA PKC A B FK FK C Schlüsselbeziehungen A(PKA,...) B(PKB,...) C(PKC,...,PKA,PKB) PKB 26

27 Agenda Das Relationenschema Schlüsselattribute Vom (S)ER-Modell zum Relationenmodell Schlüsselvererbung Motivation Funktionale Abhängigkeit 1. Normalform 2. Normalform 3. Normalform 27

28 Motivation Nicht immer liefert das ER-Modell ein redundanzfreies Datenbankschema: Kunde (KName, KAdr, Kto) Auftrag (KName, Ware, Menge) Lieferant (LName, LAdr, Ware, Preis) Nachteile des Schemas: Redundanz => Gefahr von Anomalien Für jede Ware wird die Adresse des Lieferanten gespeichert, d.h. die Adresse ist mehrfach vorhanden 28

29 Motivation Verbesserung Kunde (KName, KAdr, Kto) Auftrag (KName, Ware, Menge) Lieferant (LName, LAdr) Angebot (LName, Ware, Preis) Vorteile des Schemas Keine Redundanz Keine Anomalien Nachteil Um zu einer Ware die Adressen der Lieferanten zu finden, ist die Kombination mehrerer Tabellen (Join) notwendig à komplex, unperformant 29

30 Schema-Zerlegung Anomalien entstehen durch Redundanz Entwurfsziele: Vermeidung von Redundanz Vermeidung von Anomalien Evtl. Einbeziehung von Effizienzüberlegungen Vorgehen: Schrittweises zerlegen des gegebenen Schemas () in ein äquivalentes Schema ohne Redundanz und Anomalien Formalisierung von Redundanz und Anomalie: à Funktionale Abhängigkeit 30

31 Funktionale Abhängigkeit (FD) Formale Definition: Gegeben: Ein Relationenschema R A, B: zwei Mengen von Attributen von R(A,B R) Definition: B ist von A funktional Abhängig (A à B) gdw. für alle möglichen Ausprägungen von R gilt: Zu jedem Wert in A existiert genau ein Wert von B. Beispiel Lieferant (LName, LAdr, Ware, Preis): LName à LAdr LName, Ware à LAdr LName, Ware à Preis 31

32 Partielle und Volle FD Ist ein Attribut B funktional abhängig von A, dann auch von jeder Obermenge von A. Minimalität à Suche nach der minimalen Menge A, von der B abhängt (vgl. Schlüsseldefinition) Definition: Gegeben: Eine funktionale Abhängigkeit A à B Wenn es keine echte Teilmenge A A gibt, von der B ebenfalls funktional abhängt, Dann heißt A à B eine volle funktionale Abhängigkeit Andernfalls eine partielle funktionale Abhängigkeit 32

33 Partielle und Volle FD Beispiele: LName à LAdr volle FD LName, Ware à LAdr partielle FD Ware? Preis keine FD LName, Ware à Preis volle FD 33

34 Normalformen 1. NF - Alle Merkmalswerte sind atomar 2. NF - Nichtschlüsselmerkmale vom Schlüssel abhängig 3. NF - Es bestehen keine transitiven Abhängigkeiten BCNF (Boyce-Codd) - Nur Abhängigkeiten vom Schlüssel zulässig 4. NF - Keine Mehrwertabhängigkeiten 5. NF - Nur triviale Verbundabhängigkeiten 34

35 Erste Normalform Ein Relationstyp R ist in erster Normalform, falls die Wertebereiche aller Attribute elementar sind. Modellierungszweck gibt Granularität der Daten vor. Name Max Mustermann Anschrift Grundstraße 3, Dresden Name Vorname Anschrift Mustermann Max Grundstraße 3, Dresden Name Vorname PLZ Ort Straße Mustermann Max Dresden Grundstraße 3 35

36 Zweite Normalform Motivation: Man möchte verhindern, dass Attribute existieren, die nicht vom gesamten Schlüssel voll funktional abhängig sind, sondern nur von einem Teil davon. Beispiel: Lieferant (LName, LAdr, Ware, Preis) LName LAdr Ware Preis BackDat Dresden Brot 2,50 BackDat Dresden Brötchen 0,35 Beggor Pirna Brot 2,10 Mettmann Meißen Filet 5,50 Mettmann Meißen Wurst 3,80 Konsequenz: In den abhängigen Attributen muss dieselbe Information immer wiederholt werden 36

37 Zweite Normalform Ein Relationstyp R(A,F) ist in zweiter Normalform, falls er sich in erster NF befindet und jedes Nichtschlüsselattribut aus A von jedem Schlüsselkandidaten von R voll funktional abhängig ist. Daraus folgt: Relationen mit atomarem Schlüssel sind automatisch in 2. NF, sofern 1. NF gegeben 37

38 Zweite Normalform Zur Transformation in 2. Normalform spaltet man das Relationenschema auf: 1 Attribute, die voll funktional abhängig vom Schlüssel sind, bleiben in der Ursprungsrelation R 2 Für alle Abhängigkeiten A i à B i von einem Teil eines Schlüssels (A i S) geht man folgendermaßen vor: a) Lösche die Attribute B i aus R b) Gruppiere die Abhängigkeiten nach gleichen linken Seiten A i c) Für jede Gruppe führe eine neue Relation ein mit allen enthaltenen Attributen aus A i und B i d) A i wird Schlüssel in der neuen Relation 38

39 Zweite Normalform 1 Attribute, die voll funktional abhängig vom Schlüssel sind, bleiben in der Ursprungsrelation R LName LAdr Ware Preis BackDat Dresden Brot 2,50 BackDat Dresden Brötchen 0,35 Beggor Pirna Brot 2,10 Mettmann Meißen Filet 5,50 Mettmann Meißen Wurst 3,80 FDs: LName à LAdr LName, Ware à Preis 39

40 Zweite Normalform 2 Für alle Abhängigkeiten A i à B i von einem Teil eines Schlüssels (A i S) geht man folgendermaßen vor: a) Lösche die Attribute B i aus R LName LAdr Ware Preis BackDat Dresden Brot 2,50 BackDat Dresden Brötchen 0,35 Beggor Pirna Brot 2,10 Mettmann Meißen Filet 5,50 Mettmann Meißen Wurst 3,80 FDs: LName à Ladr LName, Ware à Preis LName Ware Preis BackDat Brot 2,50 BackDat Brötchen 0,35 Beggor Brot 2,10 Mettmann Filet 5,50 Mettmann Wurst 3,80 40

41 Zweite Normalform 2 Für alle Abhängigkeiten A i à B i von einem Teil eines Schlüssels (A i S) geht man folgendermaßen vor: b) Gruppiere die Abhängigkeiten nach gleichen linken Seiten A i Nur eine Gruppe mit LName auf der linken Seite es könnten aber noch weitere Attribute von LName abhängig sein (selbe Gruppe) es könnten Attribute von Ware abh. (2. Gruppe) FDs: LName à Ladr LName, Ware à Preis LName Ware Preis BackDat Brot 2,50 BackDat Brötchen 0,35 Beggor Brot 2,10 Mettmann Filet 5,50 Mettmann Wurst 3,80 41

42 Zweite Normalform 2 Für alle Abhängigkeiten A i à B i von einem Teil eines Schlüssels (A i S) geht man folgendermaßen vor: c) Für jede Gruppe führe eine neue Relation ein mit allen enthaltenen Attributen aus A i und B i FDs: d) A i wird Schlüssel in der neuen Relation LName à Ladr LName, Ware à Preis LName BackDat Beggor Mettmann LAdr Dresden Pirna Meißen LName Ware Preis BackDat Brot 2,50 BackDat Brötchen 0,35 Beggor Brot 2,10 Mettmann Filet 5,50 Mettmann Wurst 3,80 42

43 Zweite Normalform Grafische Darstellung Schlüssel Schlüssel A A B nach Heuer, Saake, Sattler 43 B

44 Dritte Normalform Motivation: Man möchte zusätzlich verhindern, dass Attribute von Nicht-Schlüsselattributen funktional abhängig sind. Beispiel: Bestellung(AuftrNr, Datum, KName, KAdresse ) AuftrNr Datum KName KAdresse Müller Dresden Müller Dresden Müller Dresden Meier Leipzig Meier Leipzig Redundanz: Kundenadresse mehrfach gespeichert à Anomalien!? 44

45 Dritte Normalform Ein Relationstyp R(A,F) ist in dritter Normalform, falls er sich in zweiter NF befindet und kein Nichtschlüsselattribut aus A transitiv von einem Schlüsselkandidaten von R abhängt. Transitive Abhängigkeit: AutrNr à KName à KAdresse 45

46 Dritte Normalform Zur Transformation in 3. Normalform spaltet man das Relationenschema auf (ähnlich 2.NF): 1 Attribute, die voll funktional und nicht transitiv abhängig vom Schlüssel sind, bleiben in der Ursprungsrelation R 2 Für alle Abhängigkeiten A i à B i von einem Teil eines Schlüssels (A i S) oder einem Nicht-Schlüsselattribut geht man folgendermaßen vor: a) Lösche die Attribute B i aus R b) Gruppiere die Abhängigkeiten nach gleichen linken Seiten A i c) Für jede Gruppe führe eine neue Relation ein mit allen enthaltenen Attributen aus A i und B i d) A i wird Schlüssel in der neuen Relation 46

47 Dritte Normalform FDs: AuftrNr à Datum, KName, KAdresse KName à KAdresse AuftrNr Datum KNam e KAdresse Müller Dresden Müller Dresden Müller Dresden AuftrNr Datum KNam e Müller Müller Müller Meier Meier KName KAdresse Meier Leipzig Meier Leipzig Müller Meier Dresden Leipzig 47

48 Dritte Normalform Schlüssel Grafische Darstellung Schlüssel X X A nach Heuer, Saake, Sattler 48 X A

49 Zum Abschluss Ein gut durchdachtes ER-Modell liefert bereits weitgehend normalisierte Tabellen ist in gewisser Weise eine Alternative zum ER-Modell Extrem-Ansatz: Universal Relation Assumption: Modelliere alles zunächst in einer Tabelle Ermittle die funktionalen Abhängigkeiten Zerlege das Relationenschema entsprechend kann schädlich für die Performanz sein, weil Joins sehr teuer auszuwerten sind 49