9. Normalformen / Erweiterungen 9.1 Vorbemerkung, Zielsetzung, Inhalt Datenmodellierung und Integritätsaspekte

Transkript

1 9. Normalformen / Erweiterungen 9.1 Vorbemerkung, Zielsetzung, Inhalt Datenmodellierung und Integritätsaspekte Hier betrachtet: Integritätsaspekte beim Entwurf eines relationalen Datenbankschemas (Tabellenentwurf); (noch) nicht: Definition weitergehender Konsistenzregeln ( rules, assertions...), Fragen des Zugriffschutzes & der Ablaufintegrität (Mehrbenutzerkontrolle, Fehlerbehandlung)... Bisher (rel. Datenbanken, bis Kap. 8) lediglich: - Attribute von Relationen sind atomar (1. Normalform) - Entities und Beziehungen zwischen Entities (Relationships) werden als Relationen dargestellt bzw. als Attribute (Fremdschlüssel) - Beziehungen zwischen Relationen werden ausschließlich über Wertebeziehungen hergestellt (keine Pointer o.ä.) - Ansonsten eher intuitive Datenmodellierung in relationaler Form Datenbanksysteme

2 Im folgenden: Probleme bei intuitiver, nichtadäquater Datenmodellierung Entwurfsregeln ( höhere Normalformen ) für den Entwurf relationaler DB-Schemata (DBVS-seitige) Gewährleistung von referentieller Integrität (Beziehungsintegrität) zw. Relationen Bemerkungen zur werkzeugunterstützten Datenmodellierung Grundsätzliche Vorgehensweisen beim Entwurf von guten DB-Schemata (Relationen) Normalisierung von Relationen Analytisches Vorgehen Funktionale Abhängigkeiten KursNr Titel TnNr Name TnNr Ort Ausgangsschemata Relationen in ( ) 1. Normal form Synthese von Relationen Synthetisierendes Vorgehen Attribute KursNr Titel TnNr Ort Funktionale Abhängigkeiten KursNr Titel TnNr Name TnNr Ort Zerlegungsprozess (Normalisierung) Syntheseprozess (Relationensynthese) steht im Vordergrund bei Vorlesung! Relationenschemata in (höherer) Normalform Datenbanksysteme

3 9.2 Normalformen Probleme nichtadäquater Datenmodellierung Beispiel: Datenbank Bildungswesen - Kurs (KursNr, Titel) - Kursleiter (PersNr, Name) - Teilnehmer (TnNr, Name, Ort) - Angebot (AngNr, KursNr, Datum, Ort) - Vorauss (VorNr, KursNr) - Nimmt-teil (AngNr, KursNr, TnNr) - Führt-durch (AngNr, KursNr, PersNr) - Gehalt (PersNr, Gehalt) Zusätzliche Anforderung sei wie folgt: Es sind Informationen über Personalsachbearbeiter im Schema darzustellen und in der DB zu speichern, wobei jeder Kursleiter von genau einem Personalsachbearbeiter (in der Personalabteilung) betreut wird. Datenbanksysteme

4 Denkbarer pragmatischer Ansatz: Die Sachbearbeiter-Information wird in der Kursleiter-Relation untergebracht, da sie in diesem Zusammenhang am häufigsten gebraucht wird: Kursleiter (PersNr, Name, PersSachb, PPersNr, TelNr) Meier Zander Schulze Merkle Huber Haller Müller Merkle Datenbanksysteme

5 Beobachtungen bei der Datenbanknutzung 1. Ein neuer Personalsachbearbeiter wird eingestellt, aber ihm wird noch kein Kursleiter zur Betreuung zugewiesen: Er kann nicht gespeichert werden, da Primärschlüssel (PersNr von Kursleiter) unbekannt! Einfügeanomalie (Insertion Anomaly) 2. Kursleiter Huber wird gekündigt, da zu wenig Teilnehmer in seinen Kursen (< 30): Information über Sachbearbeiter Haller würde mit verschwinden! Löschanomalie (Deletion Anomaly) 3. Die Telefonnummer von Sachbearbeiter Merkle ändert sich: Änderung in mehreren Tupeln von Kursleiter, obwohl nur 1 Sachverhalt der betreffenden Miniwelt geändert wird! Änderungsanomalie (Update Anomaly) offenbar war obige Modellierung nicht so toll! Aufstellung und Einhaltung von Entwurfsregeln ([höheren] Normalformen) erforderlich Datenbanksysteme

6 Daumenregel: Information über verschiedene Entitytypen - Kursleiter - Personalsachbearbeiter nicht in 1 Relation packen Kursleiter (PersNr, Name, PPersNr) PersonalSB (PPersNr, Name, TelNr) o.g. Anomalien treten allesamt nicht auf! Zum Thema Normalformen Problemstellung bereits von Codd (Erfinder des relationalen DB- Modells) um 1970 erkannt (1.,) 2., 3. Normalform (Codd 1971/72) Weitere Normalformen in der Folgezeit aufgrund des Entdeckens weiterer (, teils spitzfindiger ) Anomalien: Jede Normalform i schränkt gegenüber Normalform i-1 die Menge der zulässigen rel. DB-Schemata weiter ein: Damit verbunden gesteigerte Qualität!(?) Höhere Normalformen größere Zahl von (kleinen) Relationen Datenbanksysteme

7 Höhere Normalformen setzen mehr Wissen über die Daten/die Miniwelt voraus (Bedeutung der Attribute, inhaltliche Abhängigkeiten und Zusammenhänge...) Höhere Normalformen nicht um jeden Preis anstreben, sondern auch Konsequenzen berücksichtigen: Übersicht: - Viele (kleine, schmale ) Relationen u.u. unhandlich/unübersichtlich (Beziehungen!) erfordern viele Join/ Navigieren Performance-Probleme!! - Was ist, wenn (Detail-)Wissen sich später ändert Schemaänderungen, da mitmodelliert! Gesamtheit der Relationen (normalisierte und nichtnormalisierte) 1NF-Relation * 2NF-Relation * 3NF-Relation * BCNF-Relation (Boyce/Codd) * 4NF-Relation 5NF-Relation Nur Abhängigkeiten von Schlüsselattr. Keine trans. Abh. zw. Schlüsselattr. und Nichtschlattr. Nichtschlüsselattribute voll funktional abh. von Schlüsselattr. Alle Attributwerte sind atomar Datenbanksysteme

8 Auf dem Weg zu Normalformen: Funktionale Abhängigkeiten (Functional Dependencies, FDs) Aussagen über Abhängigkeiten zwischen Attributen Aus der realen Welt (betr. Miniwelt) abgeleitet Allgemeingültig, d.h. nicht nur für bestimmte, zufällig vorliegende Datenkonstellation ( schemabestimmend) Formale Definition des Begriffs FD: Gegeben Relationenschema R (A 1, A 2,... A n ) n 1 X,YєA={A 1, A 2,... A n } (X Y) t= (a 1, a 2,... a n ) Tupel einer Relation vom Typ R x,y sind die Werte von X,Y für Tupel t Y ist funktional abhängig von X (X Y) X bestimmt Y, wenn es keine Relation vom Typ R gegen kann*, in der zwei Tupel t 1 und t 2 denselben Wert für X (x 1 =x 2 ), aber verschiedene Werte für Y (y 1 y 2 ) haben. M.a.W.: (für alle möglichen Tupel) (t 1, t 2 ): x 1 =x 2 y 1 y 2... X... Y... t t hier bestimmt X offensichtlich nicht Y! * d.h. wenn dies durch Eigenschaften der betr. Miniwelt gewährleistet ist Aber Vorsicht: Konkrete Datenkonstellation darf nur als Beleg für fehlende FD benutzt werden, keinesfalls als FD-Nachweis!! Datenbanksysteme

9 Weiteres/Erläuterungen zu FDs Obige FD-Definition übertragbar von Einzelattributen X,YєA auf beliebige E menge Attribut kombinationen X,Y A In einem Relationstyp sind alle Attribute und Attributkombinationen von den identifizierenden Attribut(kombination)en d.h. den B Schlüssel(kandidate)n funktional abhängig (selbstverständlich!) Beispiel: Kursleiter (PersNr, Name, PersSachb, PPersNr, TelNr) besitzt u.a. folgende FDs: PersNr Name PersNr PersSachb, PersNr PPersNr,... PersNr {PersSachb, PPersNr, TelNr}... {PersNr, Name} PPersNr... PPersNr PersSachb PPersNr TelNr...! Wissen über Miniwelt (Semantik) große Anteil der FD s Schlüssel haben immer bestimmende Eigenschaft im Sinne von FD trivialerweise kleine Anteil der FD s Datenbanksysteme

10 Spezifizierte FDs können zu einer FD-Menge F zusammengefasst werden, im obigen Beispiel: F={PersNr Name, PersNr PersSachb, PersNr PPersNr, PersNr {PersSachb, PPersNr, TelNr},... } F kann weitere (neue) FDs implizieren (u.a.) aufgrund vorhandener Transitivität (X Y und Y Z X Z), im o.g. Beispiel etwa PersNr TelNr [ kann automatisch abgeleitet werden] weil PersNr Schüssel ist Die Menge F + aller FDs, die von F impliziert werden (inkl. F selbst), heißt closure von F (transitive Hülle) Datenbanksysteme

11 1. Normalform Eine Relation ist in 1. Normalform (1NF) genau dann, wenn all ihre Attributwerte atomar sind. Bsp.: Relation, die nicht im 1NF ist (NF 2 -Relation, Non First Normal Form) Vorrauss KursNr {VorNrn} P13 I09 {G08, G10} {G08, G10, P13} mengenwertiges Attribut (Wiederholungsgruppe, Subrelation) oder (nur andere Darstellungsform): geschachtelte Relationen ( nested relations ) Vorrauss KursNr {VorNrn} 1 Tupel P13 G08 G10 1 Tupel I09 G08 G10 P13 sind enf 2 -Relationen und damit Codd Datenbanksysteme

12 in 1NF: (normalisiert) Flache Relationen Vorrauss KursNr VorNrn P13 P13 I09 I09 I09 G08 G10 G08 G10 P13 Alle Nichtschlüsselattribute sind vom Schlüssel funktional abhängig Schreibweise: für R (S, A, B, C...) S B, S C... R R auch weglassen, falls eindeutig entsprechend bei Schlüsseln, die aus einer Attributkombination bestehen 2. Normalform Seien - S (irgend)ein Schlüssel einer Relation R - S1, S2,..., Sn die zu S gehörenden Attribute n 1 - A1, A2,..., Am die Nichtschlüsselattribute von R m 0 Datenbanksysteme

13 Eine Relation R ist in 2. Normalform (2NF) genau dann, wenn sie (1) in 1NF ist und (2) es keinen Schlüssel S und kein Attribut Aє{A1, A2,..., Am} gibt, für das gilt: S S mit S A Ein Attribut A, das Bedingung 2 erfüllt, heißt voll funktional abhängig von S Bei einer 2NF-Relation sind also alle Nichtschlüsselattribute von allen Schlüsseln (Primärschlüssel und alle Schlüsselkandidaten) jeweils voll funktional abhängig Weiterhin ist zu beobachten: - 1NF-Relation mit nur einem Schlüsselattribut (auch im Fall mehrerer solcher einattributiger Schlüsselkandidaten) sind stets auch in 2NF - 1NF-Relation, die nur aus Schlüsselattributen bestehen (A={}), sind ebenfalls stets auch in 2NF Beispiele: neu - Angebot mit anschl. atom. Attr. (AngNr, KursNr, Datum, Ort, Titel) ist minimal! nicht in 2NF, weil KursNr Titel (d.h. Titel als Nichtschlüsselattribut ist nicht voll funktional abhängig vom Schlüssel {AngNr, KursNr}) Separierung in Angebot und Kurs wie oben angegeben (beseitigt hier auch Änderunganomalie) (siehe auch Einfügeanomalie) Datenbanksysteme

14 ! Kursleiter (PersNr, Name, PersSachb, PPersNr, TelNr) ist in 2NF, besitzt aber wie oben gezeigt alle Anomalien 2NF-Konformität bedeutet noch nicht unbedingt Anomaliefreiheit siehe höhere NFs unten Die zweite Normalform bewirkt lediglich, dass Schlüssel (in gewissem Sinn) minimal sind, verhindert aber nicht, dass ein Tupel (ein Entity) entitätsfremde Informationen enthält Ansatzpunkt für 3NF!! nicht als formale Definition zu verstehen, sondern als Merk- und Verständnishilfe! 3. Normalform (Hilfs-)Definition Transitive Abhängigkeit : Eine Menge B von Attributen in R (B={B1, B2,..., Bt}) t 1 ist transitiv abhängig von einer Menge S von (Schlüssel-)Attributen in R (S={S1, S2,..., Sr}) r 1, wenn 1. S und B disjunkt sind 2. eine Menge A von Attributen in R existiert (A={A1, A2,..., An}) n 1 mit S A, A B, A S Datenbanksysteme

15 Graphische Veranschaulichung: S A x B Trans. Anmerkungen: B S A S S A und A B impliziert S B A S bewirkt, dass A nicht Schlüssel in R sein kann, da für zwei Schlüssel in einer Relation stets " " gilt (und transitive Abhängigkeit somit für B trivialerweise gegeben wäre) Daraus folgt, dass bestimmte Attributwerte von A in R mehrfach auftreten können B Wegen A B folgt: Attributwertpaare von A,B in R können mehrfach auftreten Redundanz, Anomalie Beispiel: Kursleiter (PersNr, Name, PersSachb, PPersNr, TelNr) PersNr PPersNr TelNr: Trans. Abh. der TelNr von PersNr ebenso PersNr PPersNr PersSachb: Trans. Abh. des PersSachb von PersNr "S" "A" "B" Änderungen der Telefonnummer oder des Namens des Personalsachbearbeiters (d.h. eines Sachverhalts der Miniwelt) erfordern u.u. mehrere Tupeländerungen in Kursleiter x warum? R(S, A, B) mit S und A Schlüsselkandidaten soll erlaubt sein (d.h. soll keine Trans Ab. warum? beinhalten) bedeutet: ist erlaubt Datenbanksysteme

16 Sei S (irgend)ein Schlüssel von R und A eine Menge von Nichtschlüsselattr. Eine Relation R ist in 3. Normalform (3NF) genau dann, wenn sie (1) in 2NF ist und (2) es zwischen Schlüsselattributen und Nichtschlüsselattributen keine transitiven Abhängigkeiten gibt. Kursleiter ist wegen mindestens zweier transitiver Abhängigkeiten nicht in 3NF! Unzulänglichkeiten der 3NF-Definition: - Betrachtet werden nur transitive Abhängigkeiten ( Redundanzprobleme, Anomalien) bzgl. Nichtschlüsselattributen - Transitive Abhängigkeiten können aber auch unter Einbeziehung von Schlüsselattributen auftreten, wenn mehrere Schlüssel existieren in R (die zudem aus jeweils mehreren Attributen zusammengesetzt und nicht notwendigerweise disjunkt sein müssen; siehe Bsp. auf Folie 85) Datenbanksysteme

17 BCNF (Boyce-Codd-Normalform) (Hilfs-)Definition Determinant : Ein Attribut (oder eine Menge von Attributen) einer Relation R, von dem (der) andere Attribute in R voll funktional abhängen, ist ein Determinant (bzgl. R) (Das best. Attribut kann beliebig sein, d.h. z.b. auch ein Nichtschlüsselattribut.) Synonym für Determinant: menge Bestimmendes Attribut bzw. bestimmende Attribut gruppe Eine Relation R ist in Boyce-Codd-Normalform (BCNF) genau dann, wenn sie (1) in 1NF ist und (2) jeder Determinant in R auch ein Schlüssel in R ist Überlegungen: a) BCNF impliziert 2NF (BCNF 2NF)? Widerspruchsbeweis: 2NF S S mit S A S ist ein Determinant Da S aber nicht Schlüssel sein kann (Minimalität!) BCNF b) BCNF impliziert 3NF (BCNF 3NF)? Widerspruchsbeweis: 3NF S A B (A kein Schlüssel) A Determinant, ohne Schlüssel zu sein BCNF (1) macht BCNF-Untersuchung einfacher als bei 3NF-Vorauss. Datenbanksysteme

18 Beispiel: LNr LName LIEFERANT (0,*) Annahme: LName ist, wie LNr, Schlüssel in Lieferant. m:n- Beziehungstyp liefert TEIL (1,*) Menge TNr Anomalie? Relation Lieferung (LNr, TNr, LName, Menge) steht für Schlüssel(kandidat) Datenbanksysteme

19 1NF? offensichtlich sofern Domänen atom. Werte nur umfassen 2NF? alle Schlüssel: {LNr, TNr} Primärschlüssel {LName, TNr} Schlüssel(kandidat) Nichtschlüsselattribute: {Menge} "Menge" ist von allen Schlüsseln voll funktional abhängig 2NF 3NF? Vom (einzigen) Nichtschlüsselattribut "Menge" ist nichts anderes funktional abhängig insbesondere keine transitiven Abhängigkeiten vorhanden 3NF BCNF? Determinants: {LNr, TNr} weil Schlüssel ( Menge) 1. LNr und LName allein ist jeweils kein Schlüssel nicht in BCNF! Konsequenz? {LNr, TNr} weil Schlüssel ( Menge) 2. {LNr} ( LName) 3. {Name} ( LNr) 4. Datenbanksysteme