4.1 Relationale DB-Entwurfstheorie, Normalformen

Transkript

1 4 Relationaler Datenbankentwurf 4.1 Relationale DB-Entwurfstheorie, Normalformen Vorgaben des Relationalen Datenmodells: Attributwerte von Relationen sind atomar ( 1. Normalform ) Entities und Beziehungen zwischen Entities werden als Relationen modelliert Beziehungen zwischen Relationen werden ausschließlich über Wertebeziehungen (keine Pointer o.ä.) hergestellt Ansonsten: Hier bislang eher intuitive Datenmodellierung in relationaler Form In Informationsmanagement : Modellierung von Anwendungen mittels Entity-Relationship-Modell Abbildung ERM Relationenmodell Probleme nicht-adäquater Datenmodellierung ( Anomalien ). Funktionalabhängigkeiten, Normalformenlehre (1.-3. Normalform) Sonstige Ziele beim relationalen DB-Entwurf In diesem Kapitel: kurzes Resumée der Normalformen aus IM-Vorlesung weiterführende Normalformen auf der Basis weiterer Datenabhängigkeiten Objektorientierung in Datenbanken ( Postrelationale DBen ) c M. Scholl, 2001/02 Informationssysteme: 4. Relationaler Datenbankentwurf 4-1

2 4.2 Wiederholung: Funktionale Abhängigkeiten und Normalformen Hintergrund/Ausgangspunkt: Ursprünglich wurden von Codd (1971/72) drei Normalformen vorgeschlagen (1NF, 2NF, 3NF). Jede Stufe (1NF 2NF 3NF) stellt eine Verschärfung hinsichtlich der Anforderungen (und damit der Qualität des Schemas) bezogen auf die vorherige Stufe dar. Der Normalisierungsprozeß führt i.a. zur Aufspaltung von Relationen. Definition der 3. Normalform hatte einige Schwächen und wurde später (ca. 1974) revidiert ( Boyce-Codd-NF, (BCNF)). Später kamen einige weitere, speziellere Normalformen hinzu. Fagin führte 1977 eine neue Normalform (Fagin 1977) und 1979 eine projection-join normal form (Fagin 1979) ein, die heute überwiegend als 4. und 5. Normalform bezeichnet werden. c M. Scholl, 2001/02 Informationssysteme: 4. Relationaler Datenbankentwurf 4-2

3 Die Zusammenhänge zwischen den verschiedenen Normalformen lassen sich wie folgt (im Sinne von beinhaltet ) beschreiben: Wichtige Fragestellungen darüber hinaus (theoretische Grundlagen): Welche Zerlegungen sind verlustfrei? kein Verlust von Information (im engeren Sinne) keine neuen (falschen) Informationen Welche Zerlegungen sind abhängigkeitsbewahrend? kein Verlust an Integritätsbedingungen c M. Scholl, 2001/02 Informationssysteme: 4. Relationaler Datenbankentwurf 4-3

4 4.2.1 Funktionale Abhängigkeiten (functional dependencies, FD s) Definition 4-1: (Funktionale Abhängigkeit (FD)) Seien X, Y sch(r). Eine Funktionale Abhängigkeit (FD) X R für alle korrekten Ausprägungen val(r) gilt: Y ist in R erfüllt, wenn t 1, t 2 val(r) : t 1 (X) = t 2 (X) t 1 (Y ) = t 2 (Y ) Wir sagen dann X bestimmt Y (funktional) oder Y hängt von X ab FDs sind eine spezielle Form von Integritätsbedingungen. Schlüssel einer Relation werden über entsprechende FDs definiert! Alternative Schreibweise (als logische Schlußregel): statt A R B: A B a b 1 a b 2 b 1 = b 2 Equality Generating Dependency Lies: Wenn (a, b 1 ) val(r(a, B)) und (a, b 2 ) val(r(a, B)) dann gilt b 1 = b 2 Ableitungsregeln (Inferenzregeln, Armstrong-Axiome) erlauben uns die Ableitung aller gültigen FDs (der transitiven Hülle F + ) zu einer gegebenen Menge F bzw. der Hülle einer geg. Menge X von Attributen, X +, also aller Attribute, die von X funktional abhängen. c M. Scholl, 2001/02 Informationssysteme: 4. Relationaler Datenbankentwurf 4-4

5 4.2.2 FD-basierte Normalformen Definition 4-2: (1. Normalform) Eine Relation ist in 1. Normalform (1NF-Relation) genau dann, wenn alle ihre Attributwerte atomar sind. Beispiel für eine Nicht-1NF-Relation: Vorauss KursNr VorNrn P13 {G08, G10} I09 {G08, G10, P13} Definition 4-3: (2. Normalform) Relation R ist in 2. Normalform (2NF-Relation) genau dann, wenn (sie eine 1NF-Relation ist und) es keinen Schlüssel S und kein Nichtschlüssel-Attribut A gibt, für das gilt: S S, S S, mit S A. Ein Attribut A i, das die o.g. Bedingung erfüllt, heißt voll funktional abhängig von S. Bei einer 2NF-Relation sind also alle Nichtschlüsselattribute von (allen) Schlüsseln voll funktional abhängig. c M. Scholl, 2001/02 Informationssysteme: 4. Relationaler Datenbankentwurf 4-5

6 (Hilfs-)Definition 4-4: (Transitive Abhängigkeit) Ein Attribut B in R ist transitiv abhängig vom Schlüssel S, wenn gilt: 1. B / S 2. es gibt eine Menge A(B / A) von Attributen in R, so daß gilt: S A, A S, A B Definition 4-5: (3. Normalform) Relation R ist in 3. Normalform (3NF-Relation) genau dann, wenn (sie eine 2NF-Relation ist und) kein Nichtschlüsselattribut transitiv vom Schlüssel abhängt. Alternative Definition 3NF (äquivalent): R ist in 3NF, wenn für alle Y sch(r), A / Y, A Nichtschlüsselattribut in R, gilt: Y A = Y ist Schlüssel in R (d.h. Y sch(r)) Definition 4-6: (Boyce-Codd-Normalform (BCNF)) R ist in BCNF, wenn für alle Y sch(r), A / Y (A beliebiges Attribut von R) gilt: Y A = Y enthält einen Schlüssel c M. Scholl, 2001/02 Informationssysteme: 4. Relationaler Datenbankentwurf 4-6

7 4.2.3 Eigenschaften von Zerlegungen Definition 4-7: (Verlustfreiheit) Eine Zerlegung einer Relation R in Teile R 1,..., R n (mit R 1 R n = sch(r)) heißt verlustfrei (genauer: PJ-verlustfrei), wenn für alle gültigen Werte val(r) gilt: R = (π R1 R)... (π R nr) Definition 4-8: (Abhängigkeitsbewahrung) Eine Zerlegung einer Relation R in Teile R 1,..., R n (mit R 1 R n = sch(r)) heißt abhängigkeitsbewahrend, wenn gilt: F + = (F 1... F n ) +... mit F : Menge der FDs über sch(r) F i : Menge der FDs F + über sch(r i ) Satz 4-1: ( Zerlegung entlang einer FD ) Sei X Y F +, X, Y sch(r) und X Y =. Dann ist die folgende Zerlegung R von R PJ verlustfrei. R 1 = X Y R 2 = R Y c M. Scholl, 2001/02 Informationssysteme: 4. Relationaler Datenbankentwurf 4-7

8 Zusammenfassung Zerlegungseigenschaften: 1. Es gibt immer eine verlustfreie BCNF-Zerlegung. Diese ist: nicht immer abhängigkeitsbewahrend Ergebnis reihenfolgeabhängig Verfahren: Dekompositionsalgorithmus 2. Es gibt immer eine abhängigkeitsbewahrende 3NF-Zerlegung verlustfrei durch ursprünglichen Schlüssel zusätzlich möglich (siehe Literatur) Verfahren: Relationensythese 3. Allgemein gilt: Immer möglich: 3NF + verlustfrei + abhängigkeitsbewahrend Nicht immer möglich: BCNF + verlustfrei + abhängigkeitsbewahrend c M. Scholl, 2001/02 Informationssysteme: 4. Relationaler Datenbankentwurf 4-8

9 4.3 Weitergehende Normalformen Bisher betrachtet: Funktionale Abhängigkeiten der Form A B bzgl. einer Relation R, mit A, B R, wobei für einen gegebenen Wert von A der Wert von B ebenfalls eindeutig bestimmt ist. Damit sind noch nicht alle Arten von unerwünschten Abhängigkeiten erfaßt einige Formen von vermeidbaren Redundanzen noch möglich noch Einfüge- und Lösch-Anomalien möglich. Also: durch funktionale Abhängigkeiten können nicht alle Probleme beim Datenbankentwurf beschrieben werden. Beispiel: Jeder Lieferant bietet eine Menge von Produkten und eine Menge von Lieferarten an. schlechtes Datenbankschema: c M. Scholl, 2001/02 Informationssysteme: 4. Relationaler Datenbankentwurf 4-9

10 4.3.1 Mehrwertige Abhängigkeiten und 4NF Beispiel 4-1: AngInfo PersNr Hobbies Kinder 2733 Kochen Susanne 2733 Kochen Horst 2733 Malen Susanne 2733 Malen Horst 5176 Lesen Maria 5176 Lesen Klara 5176 Basteln Maria 5176 Basteln Klara Obwohl Relation AngInfo in BCNF ist, enthält sie redundante Informationen. Es gilt hier offensichtlich: 2733 {Kochen, Malen} sowie 2733 {Susanne, Horst} 5176 {Lesen, Basteln} sowie 5176 {Maria, Klara} Man bezeichnet dies als mehrwertige Abhängigkeiten (multi-valued dependencies, MVDs), in Symbolen: PersNr Hobbies bzw. PersNr Kinder. c M. Scholl, 2001/02 Informationssysteme: 4. Relationaler Datenbankentwurf 4-10

11 Probleme dieser Art treten durch die Normalisierung ( Flachklopfen ) beim Zusammenfassen mehrerer, voneinander unabhängiger 1:n-Beziehungen in einer Relation auf: AngInfo-NF2 PersNr {Hobbies} {Kinder} 2733 Kochen Susanne Malen Horst 5176 Lesen Maria Basteln Klara AngInfo PersNr Hobbies Kinder 2733 Kochen Susanne 2733 Kochen Horst 2733 Malen Susanne 2733 Malen Horst 5176 Lesen Maria 5176 Lesen Klara 5176 Basteln Maria 5176 Basteln Klara Lösung: Aufspalten von AngInfo: PersNr Hobbies = AngHobbies (PersNr, Hobby) PersNr Kinder = AngKinder (PersNr, Kinder) c M. Scholl, 2001/02 Informationssysteme: 4. Relationaler Datenbankentwurf 4-11

12 Definition 4-9: (Mehrwertige Abhängigkeit (multi-valued dependency (MVD))) Sei sch(r) = X Y Z. Eine mehrwertige Abhängigkeit (MVD) X Y (X Z) ist in R erfüllt, wenn für alle korrekten Ausprägungen val(r) gilt: t 1, t 2 val(r): t 1 (X) = t 2 (X) s 1, s 2 val(r): s 1 (X) = s 2 (X) = t 1 (X) s 1 (Y ) = t 1 (Y ) s 1 (Z) = t 2 (Z) s 2 (Y ) = t 2 (Y ) s 2 (Z) = t 1 (Z)... zu einem X-Wert treten die Y - und Z-Werte über Kreuz kombiniert auf Bemerkungen: MVDs treten immer paarweise auf X Y X R Y X Es gibt triviale MVDs, die immer gelten: X, X R X X Y mit Y X FDs sind spezielle MVDs: X A = X A (nicht jedoch umgekehrt) eingebettete MVDs (EMVD) X Y Z für X Y Z R sinngemäß c M. Scholl, 2001/02 Informationssysteme: 4. Relationaler Datenbankentwurf 4-12

13 Definition 4-10: (4. Normalform) Eine Relation R ist eine 4NF-Relation dann und nur dann, wenn für jede mehrwertige Abhängigkeit A B, mit A, B R, gilt: R Entweder A enthält einen Schlüssel von R oder A B = R ). )... und damit ist A R B eine (einfache) FD A R B Anmerkungen: AngInfo (PersNr, Hobbies, Kinder) ist nicht in 4NF, da gilt: PersNr Hobbies, PersNr aber kein Schlüssel in AngInfo ist. Für 4NF-Relationen gibt es eine Reihe äquivalenter Definitionen 1. Eine äquivalente Definition wäre z.b.: Eine Relation ist in 4NF, wenn sie in BCNF ist und keine nicht-trivialen mehrwertigen Abhängigkeiten enthält. Die 4NF-Definition entspricht der BCNF-Definition, nur daß jetzt mehrwertige anstelle einfacher Abhängigkeiten betrachtet werden. 1 Vgl. z.b. die Definitionen in (Elmasri und Navathe 1994), (Vossen 1994), (Schlageter und Stucky 1983), (Vetter 1991), (Date 1992),... c M. Scholl, 2001/02 Informationssysteme: 4. Relationaler Datenbankentwurf 4-13

14 MVDs sind tuple generating dependencies : Als logische Schlußregel (vgl. bei FDs): statt X R Y : X Y Z x 1 y 1 z 1 x 1 y 2 z 2 R x1 y 1 z 2 [ x 1 y 2 z 1 ]... der zweite Teil der Schlußfolgerung ist (wegen der Symmetrie) redundant! Axiome für MVDs: X, Y U M1: (Komplement) X Y = X U X Y. M2: (Erweiterung) X Y V W = W X V Y. M3: (Transitivität) X Y Y Z = X (Z Y ). Axiome für MVDs und FDs: FM1: X Y X Y. FM2: X Y, Z Y, W Y =, W Z = X Z. c M. Scholl, 2001/02 Informationssysteme: 4. Relationaler Datenbankentwurf 4-14

15 Satz 4-2: Diese und die Armstrong-Axiome sind korrekt (sound) und vollständig (complete). Weitere Axiome: Vereinigung: X Y, X Z = X Y Z Pseudotransitivität: X Y, W Y Z = XW Z gemischte Pseudotransitivität: X Y, XY Z X Z Y Dekomposition: X Y, X Z = X Y X X Y Z X Z Y Satz 4-3: ( Verlustfreier Join ) π xy R π xz R = π xyz R X Y oder X Z Zur Erinnerung: X Y oder X Z = π xy R π xz R = π xyz R... eine MVD charakterisiert genau eine verlustfreie (2er-) Zerlegung! c M. Scholl, 2001/02 Informationssysteme: 4. Relationaler Datenbankentwurf 4-15

16 4.3.2 Join Dependency und 5NF Selbst bei 4NF-Relationen können in seltenen Fällen noch Speicheranomalien auftreten. Ursache: Zwischen den Schlüsselattributen bestehen zyklische Abhängigkeiten. Beispiel 4-2: Mehrere Firmen arbeiten in unterschiedlicher Zusammensetzung in verschiedenen Projekten in Arbeitsgemeinschaften zusammen. Werden in einem Projekt Teile eines bestimmten Typs benötigt, so wird jede beteiligte Firma an der Lieferung beteiligt, sofern sie diese Teile im Lieferprogramm hat. Angenommen, dieser Sachverhalt werde durch die folgende Relation beschrieben: L-T-P (LiefNr, TeileNr, ProjNr) Bei Einfügungen, Änderungen und Löschungen muß die folgende, komplexe Integritätsregel beachtet werden: Wenn (l 1, t 1, p 2 ) und (l 2, t 1, p 1 ) und (l 1, t 2, p 1 ) in L-T-P enthalten sind, dann muß auch (l 1, t 1, p 1 ) in L-T-P enthalten sein. Folge der zyklischen Abhängigkeit: Verlustfreie Zerlegung erfordert mehr als zwei Relationen! c M. Scholl, 2001/02 Informationssysteme: 4. Relationaler Datenbankentwurf 4-16

17 Beispiel 4-3: 2 2 In leicht abgewandelter Form entnommen aus: (Date 1992) c M. Scholl, 2001/02 Informationssysteme: 4. Relationaler Datenbankentwurf 4-17

18 Angenommen, ein neuer Lieferant stoße zur Arbeitsgemeinschaft hinzu, der a. an beiden Projekten mitwirkt und b. Teile t1 und t2 zu liefern vermag. Angenommen, es gebe nur die L-T-P-Relation. Frage: Welche(s) Tupel ist (sind) einzufügen? ( ) Korrekte Einfügung erfordert einiges an Überlegung. Entscheidung über Einfügungen in L-T, T-P und P-L hingegen trivial: aus a) folgt: Einfügungen in L-P: (l3, p1), (l3, p2) aus b) folgt: Einfügungen in L-T: (l3, t1), (l3, t2) Antwort auf Frage ( ): Es wären einzufügen (l3, t1, p1) (l3, t1, p2) (l3, t2, p1) Definition 4-11: ( Join Dependency (JD)) Relation R erfüllt JD (X, Y,..., Z) : R = π X (R) π Y (R)... π Z (R) c M. Scholl, 2001/02 Informationssysteme: 4. Relationaler Datenbankentwurf 4-18

19 Triviale JD: Eines der X,..., Z enthält alle Attribute von R. Darstellung JD als logische Schlußregel: Beispiel: (AB, BC, AC) A B C R a 1 b 1 c 2 a 2 b 1 c 1 a 1 b 2 c 1 a 1 b 1 c 1 = auch JD ist eine tuple generating dependency. Definition 4-12: (5NF/PJNF) Eine Relation R ist in 5NF, wenn für alle nicht-trivialen JDs in R von der Form gilt: Jedes R i enthält einen Schlüssel von R. (R 1,..., R n ) Aussage: Betrachtete Relationen sind (ohne Informationsverlust) nur noch dadurch weiter zerlegbar, daß jeweils der gesamte Schlüssel mitgegeben wird. Bemerkung: es gilt i : R i sch(r) und i R i = sch(r) c M. Scholl, 2001/02 Informationssysteme: 4. Relationaler Datenbankentwurf 4-19

20 Abschließende Bemerkungen: Es gibt noch eine ganze Reihe weiterer Dependencies und Normalformen ( theoretische Spielwiese, eher wenig praktische Bedeutung) Eine weitere, auch praktisch relevante Dependency: Inclusion Dependency ID : R(X) S(Y ) : π x (R) π y (S)... drückt u.a. Fremdschlüssel-Bedingung aus. Generelles Ziel Normalformen-Lehre: Möglichst alle Dependencies als Schlüsselbedingung darstellen! Eindeutigkeit leicht zu prüfen (z.b. unique index) Verbleibendes Problem: Fremdschlüsselbedingung muß ebenfalls geprüft werden ( referential integrity, Kap. 3) c M. Scholl, 2001/02 Informationssysteme: 4. Relationaler Datenbankentwurf 4-20

21 4.4 Zusätzliche Literaturhinweise Date, C.J. (1992). An Introduction to Database Systems. Addison-Wesley, 5 Aufl. Elmasri, R. und S. Navathe (1994). Fundamentals of Database Systems. The Benjamin/Cummings Publ. Comp., Redwood City, CA., 2 Aufl. Fagin, R. (1977). Multivalued Dependencies and a New Normal Form for Relational Databases. ACM Transactions on Database Systems, 2(3). Fagin, R. (1979). Normal Forms and Relational Database Operators. In: Proc. ACM SIGMOD Conference on Management of Data. ACM, New York. Fahrner, Chr. und G. Vossen (1995). A Survey of Database Design Transformations Based on the Entity-Relationship Model. dke, 15: Heuer, A. und G. Saake (1995). Datenbanken: Konzepte und Sprachen. Int l Thompson Publishing, Bonn. Maier, D. (1983). The Theory of Relational Databases. Computer Science Press. Schlageter, G. und W. Stucky (1983). Datenbanksysteme: Konzepte und Modelle. Teubner-Verlag. Ullman, J. (1988/1989). Principles of Database and Knowledge-Base Systems I & II. Computer Science Press. Vetter, M. (1991). Aufbau betrieblicher Informationssysteme. Teubner-Verlag. Vossen, G. (1994). Datenmodelle, Datenbanksprachen und Datenbank-Management-Systeme. Addison-Wesley, 2 Aufl. c M. Scholl, 2001/02 Informationssysteme: 4. Relationaler Datenbankentwurf 4-21