An approximation of Edgar Codd's definition of 3NF:

Transkript

1 4 Datenbank-Entwurf Informationssysteme für Ingenieure Herbstsemester Normalisierung An approximation of Edgar Codd's definition of 3NF: Every non-key attribute must provide a fact about the key, the whole key, and nothing but the key. -- William Kent Every non-key attribute must provide a fact about the key, the whole key, and nothing but the key, so help me Codd. -- unknown R. Marti

2 Relationaler DB-Entwurf ohne ER-Modell: Normalisierung Relationen können auch ohne "Umweg" über das ER Modell definiert werden. Bei (zu-) wenig Erfahrung beim DB-Entwurf können Relationen entstehen, die Attribute enthalten, die nicht in diese Relation gehören. Dies kann zu Problemen bei DB-Mutationen führen (vor bei allem UPDATEs) Diese Probleme bei DB-Mutationen ( Mutationsanomalien) können durch Zerlegung der Relationen vermieden werden. Ziele der Normalisierungstheorie Charakterisierung guter relationaler Schemata Ziel oft 3. Normalform (3NF) oder besser Elimination von Redundanzen und Vermeidung von Mutationsanomalien Überprüfbarkeit vieler Integritätsbedingungen durch (Primär-) Schlüssel automatischer Datenbankentwurf aufgrund von "Beziehungen" auf Stufe Attribut R. Marti 2

3 Funktionale Abhängigkeit Seien U die Menge der Attributnamen einer Relation R, X = { A 1,..., A m } (m > 0) und Y = { B 1,..., B n } (n > 0) Teilmengen von U (wobei X und Y nicht wie in der Illustration unten disjunkt sein müssen) Die funktionale Abhängigkeit (functional dependency) X Y besteht, sofern zu jedem Zeitpunkt für zwei beliebige Tupel r, s ext(r) folgendes gilt: (r.a 1 = s.a 1 Ù... Ù r.a m = s.a m ) Þ (r.b 1 = s.b 1 Ù... Ù r.b n = s.b n ) bzw., in Kurznotation, r.x = s.x Þ r.y = s.y. ¾¾¾¾¾¾¾¾¾¾¾ U ¾¾¾¾¾¾¾¾¾¾¾ R ¾¾¾¾ X ¾¾¾¾ ¾¾¾¾ Y ¾¾¾¾ A 1 A m B 1 B n r.a1 r.am r.b1 r.bn s.a1 s.am s.b1 s.bn R. Marti 3

4 Beispiele funktionaler Abhängigkeiten StudExam SNo SName Address DNo DName Course Grade I Meier Basel IIIC Informatik Informatik I Meier Basel IIIC Informatik Analysis I Meier Basel IIIC Informatik Physik I Schmid Bern IIIC Informatik Informatik I Schmid Bern IIIC Informatik Analysis I Anderegg Zürich IIIC Informatik Informatik P Imboden Luzern IX Mathematik Algebra 3 Unter den Attributen der Relation StudExam gelten (u.a.) die funktionalen Abhängigkeiten SNo SName, Address, DNo SNo, Course Grade DNo DName DName DNo R. Marti 4

5 Beispiele für Abhängigkeiten, die nicht-funktional sind StudExam SNo SName Address DNo DName Course Grade I Meier Basel IIIC Informatik Informatik I Meier Basel IIIC Informatik Analysis I Meier Basel IIIC Informatik Physik I Schmid Bern IIIC Informatik Informatik I Schmid Bern IIIC Informatik Analysis I Anderegg Zürich IIIC Informatik Informatik P Imboden Luzern IX Mathematik Algebra 3 Die folgenden funktionalen Abhängigkeiten zwischen Attributen der Relation StudExam gelten jedoch nicht: SNo Grade (sonst bekäme ein Student immer die gleiche Note, unabhängig vom Fach!) Course Grade (sonst würde in einem Fach allen die gleiche Note erteilt!) R. Marti 5

6 Bemerkungen zur Schreibweise funktionaler Abhängigkeiten Seien U die Menge der Attributnamen einer Relation R, X und Y = { B 1, B 2,..., B n } disjunkte Teilmengen von U Dann sind die folgenden Aussagen äquivalent: 1) Es gilt X B 1, B 2,..., B n 2) Es gelten X B 1, X B 2,..., X B n 3) Es gilt X X, B 1, B 2,..., B n (weil X X trivialerweise gilt). Tendentiell verwende ich Darstellung (1), da so am wenigsten geschrieben werden muss. Darstellung (2) ist insbesondere zur Implementierung gewisser Algorithmen geeignet. Darstellung (3) verwende ich praktisch nur, wenn die rechte Seite der funktionalen Abhängigkeit alle Attribute der Relation R umfasst, also die Attributmenge U : X U I.A. bemühe ich mich auch, auf der linken Seite einer funktionalen Abhängigkeit eine minimale Attributmenge zu verwenden: Bei X Y sollte es kein Z X geben, so dass Z Y gilt. R. Marti 6

7 Funktionale Abhängigkeiten und Superschlüssel Die Existenz einer funktionalen Abhängigkeit X Y in einer Relation R bedeutet Attribut (bzw. Attributkombination) X ist ein Superschlüssel der Relation p X,Y R. Falls X und Y Identifikationsschlüssel von Entitätstypen E X und E Y sind, dann gibt es eine m:1 Beziehung (oder, falls auch Y X gilt, sogar eine 1:1 Beziehung) zwischen E X und E Y. s. Unterkapitel 4-1, Kardinalitäten von Beziehungen: Jedem x X ist 1 y Y zugeordnet. Wie Superschlüssel bzw. Schlüsselkandidaten sind funktionale Abhängigkeiten Integritätsbedingungen, die auch für zukünftige Ausprägungen gelten sollen. Eigentlich kann aus einer Ausprägung nur geschlossen werden, welche funktionale Abhängigkeiten definitiv nicht gelten. Eine "typische" Ausprägung liefert jedoch Anhaltspunkte für funktionale Abhängigkeiten. R. Marti 7

8 Beispiel: Mutationsanomalien in Relation StudExam StudExam (in 1NF) Update-Anomalie: Meier zieht nach Zürich um Þ es müssen in 3 Tupeln Änderungen vorgenommen werden Every non-key attribute must provide a fact about the whole key. SNo SName Address DNo DName Course Grade I Meier Basel IIIC Informatik Informatik I Meier Basel IIIC Informatik Analysis I Meier Basel IIIC Informatik Physik I Schmid Bern IIIC Informatik Informatik I Schmid Bern IIIC Informatik Analysis I Anderegg Zürich IIIC Informatik Informatik P Imboden Luzern IX Mathematik Algebra 3 Delete-Anomalie: Imboden verlässt ETH Þ Fakt, dass Departement Nr. IX das Mathematik-Departement ist geht verloren Insert-Anomalie: Student Kunz hat noch keine Prüfung in einem Fach (Course) abgelegt Þ Fakt, dass sie/er in Aarau wohnt kann nicht eingefügt werden (da Primärschlüsselattribute null!) R. Marti 8

9 Beispiel: Zerlegung der vorherigen Relation StudExam StudInfo (in 2NF) SNo SName Address DNo DName I Meier Basel IIIC Informatik I Meier Basel IIIC Informatik I Meier Basel IIIC Informatik I Schmid Bern IIIC Informatik I Schmid Bern IIIC Informatik I Anderegg Zürich IIIC Informatik P Imboden Luzern IX Mathematik Exam (in 3NF) SNo Course Grade I Informatik I Analysis I Physik I Informatik I Analysis I Informatik P Algebra 3 Tabelle StudInfo hat nun noch folgende "Probleme": Every non-key attribute must provide a fact about nothing but the key. Update-Anomalie: Informatik wird umbenannt in Information Technology Þ es müssen in 3 Tupeln Änderungen vorgenommen werden Delete-Anomalie: Imboden verlässt ETH Þ Fakt, dass Departement Nr. IX das Mathematik-Departement ist geht verloren R. Marti 9

10 Beispiel: Zerlegung der vorherigen Relation StudInfo Exam (in 3NF) SNo Course Grade I Informatik I Analysis I Physik 4 StudInfo Stud (in 3NF) SNo SName Address DNo I Meier Basel IIIC I Schmid Bern IIIC I Anderegg Zürich IIIC P Imboden Luzern IX Dept DNo IIIC IIIC IIIC IX (in 3NF) DName Informatik Informatik Informatik Mathematik R. Marti 10

11 Non-3NF Resultat bei Transformation aus ER-Modell Bei einem Entwurf via ER-Modell mit anschliessender Transformation kann im Prinzip eine Relation erzeugt werden, die nicht in 3NF ist. Dies ist aber selten. Beispiel ER-Modell: Attribut, welches einem falschen Entitätstyp zugeordnet ist. Airport AptCode AptName CityName CountryCode Resultierende Relation (mit Beispiel-Ausprägung) AptCode AptName CityName CountryCode JFK John F Kennedy Intl New York USA LGA La Guardia New York USA Es gilt: CityName CountryCode, Primärschlüssel ist jedoch AptCode. Mutationsanomalie: falls Stadt zu neuem Land gehört J R. Marti 11

12 Ableitung funktionaler Abhängigkeiten (FAs) aus anderen FAs Aus einer Menge F vorgegebener funktionaler Abhängigkeiten, in welchen Attribute aus einer Menge U (typischerweise ist U die Menge aller Attribute einer Relation R) vorkommen dürfen, können meist weitere funktionale Abhängigkeiten abgeleitet werden, die ebenfalls gelten müssen (sog. Hülle, F + ). Anwendungen davon sind z.b. Bestimmen von Schlüsselkandidaten einer (gegebenen) Relation aufgrund von FAs. Finden einer guten Zerlegung einer (gegebenen) Relation, die nicht mindestens in 3NF ist. Feststellen, ob das Resultat einer (SQL-)Anfrage - eine Tabelle - keine Duplikate enthalten kann. Letzteres würde in etwa so funktioneren: 1. Falls X PRIMARY KEY / UNQUE in Relation R mit Attributen R.U ist, erzeugt dies FA R.X R.U. 2. Eine Join-Bedingung der Form S.B = R.A erzeugt FAs der Form S.B R.A und R.A S.B. 3. Es wird gesucht, ob die Attributmenge Z des Resultats (s. SELECT-Klausel) einen Schlüsselkandidaten W enthält, d.h. ob W Z (W Z) gilt. R. Marti 12

13 Hülle einer Menge funktionaler Abhängigkeiten Sei U die Menge der Attributnamen einer Relation R, F eine Menge funktionaler Abhängigkeiten auf U Die Hülle (closure) F + ist die Menge aller aus F ableitbaren funktionalen Abhängigkeiten. Ableitungsregeln zur Berechnung von F + (sog. Armstrong Axioms) 1. Wenn Y Í X gilt, dann gilt X Y. (Reflexivität) 2. Wenn X Y gilt, dann gilt XZ YZ. (Erweiterung) 3. Wenn X Y und Y Z gelten, dann gilt X Z. (Transitivität) Bem.: XZ YZ ist eine Kurznotation für X È Z Y È Z. R. Marti 13

14 Herleitung funktionaler Abhängigkeiten: Beispiel R = StudExam(SNo, SName, Address, DNo, DName, Course, Grade) F = { SNo SName Address DNo, DNo DName, } SNo Course Grade Daraus können z.b. folgende funktionale Abhängigkeiten hergeleitet werden: SNo Course SNo SNo DNo SNo DName SNo DName SNo Course Address Reflexivität (SNo Í SNo Course) Erweiterung Transitivität (via DNo: SNo DNo, DNo DName) Transitivität (via SNo) + Erweiteung R. Marti 14

15 Schlüsselkandidat, Schlüsselattribut Sei U die Menge der Attributnamen einer Relation R, F eine Menge funktionaler Abhängigkeiten auf U X Í U eine Attributmenge und F + die Menge aller aus F ableitbaren funktionalen Abhängigkeiten (die Hülle von F). Def.: X heisst Schlüsselkandidat (candidate key), wenn 1) X U Î F + (d.h. alle Attribute in R hängen funktional von X ab ) 2) Es gibt keine echte Teilmenge von X, die diese Eigenschaft hat. Def.: X heisst Schlüsselattribut (prime attribute), wenn es in mindestens einem Schlüsselkandidaten von R vorkommt. Bem.: Die obige Definition des Begriffs Schlüsselkandidat ist konsistent mit derjenigen in Kapitel 2. R. Marti 15

16 Normalformen: BCNF, 3NF Sei U die Menge der Attributnamen einer Relation R, F eine Menge funktionaler Abhängigkeiten auf U X Í U eine Attributmenge A Î U ein (einzelnes) Attribut Def.: R ist in Boyce-Codd Normalform (BCNF), wenn für jede funktionale Abhängigkeit X A Î F + X enthält einen Schlüsselkandidaten. mit A Ï X gilt: Def.: R ist in 3. Normalform (3NF), wenn für jede funktionale Abhängigkeit X A Î F + mit A Ï X gilt: X enthält einen Schlüsselkandidaten oder A ist ein Schlüsselattribut. Satz: Jede Relation, die in BCNF ist, ist auch in 3NF (nicht aber umgekehrt). (Mit anderen Worten: BCNF ist strenger als 3NF.) Pro Memoria: Ziel der Normalformen ist die Vermeidung von Update-Anomalien. R. Marti 16

17 3NF Relation, die nicht in BCNF ist: Beispiel (1) R = Course (Subject, Time, Room) F = { Subject Room, Time Room Subject } Schlüsselkandidaten { Subject, Time } { Time, Room } Fach immer im gleichen Raum zu einem gegebenen Zeitpunkt wird in einem Raum nur ein Fach unterrichtet Details zu den Schlüsselkandidaten (benütze Ableitungsregeln S. 48 und Def. Schlüsselkandidat S. 50): Subject Subject, Room Subject: Regel (1), Room: vorgegeben Subject Time Time Subject and Room Time Time Time Time: Regel (1) Room Room Room: Regel (1) Subject, Time Subject, Time, Room Subject, Time: Regel (1), Room: Regel (1) Time, Room Subject, Time, Room Subject: vorgegeben, Time, Room: Regel (1) Subject, Room Subject, Room Subject: Regel (1), Room: vorgegeben R. Marti 17

18 3NF Relation, die nicht in BCNF ist: Beispiel (2) R = Course (Subject, Time, Room) F = { Subject Room, Time Room Subject } Fach immer im gleichen Raum zu einem gegebenen Zeitpunkt wird in einem Raum nur ein Fach unterrichtet FD Subject Room verletzt BCNF, nicht aber 3NF, da Room Schlüsselattribut ist [ Bem.: Subject ist kein Schlüsselkandidat! ] Subject Time Room Datenbanken Di 9-11 A36 Datenbanken Do 9-11 A36 Compilerbau Di 9-11 A32 Compilerbau Mi A32 Neuronale Netze Mi A36 Mutationsanomalie bei Wechsel des Raums eines Fachs R. Marti 18

19 Zerlegung einer Relation Nicht-normalisierte Relationen werden in schrittweise in jeweils 2 Relationen zerlegt. Dabei stellt sich die Frage, welche Zerlegungen "gut" sind und welche nicht. Ein wichtiges Ziel ist es, bei der Zerlegung keine funktionale Abhängigkeit zu verlieren, denn diese stellen Integritätsbedingungen dar. Zudem können bei geeigneter Zerlegung funktionale Abhängigkeiten in SQL durch PRIMARY KEY bzw. UNIQUE Bedingungen dargestellt (und überprüft) werden. Formal sieht eine Zerlegung einer Relation R in Relationen R 1 und R 2 wie folgt aus: Seien U die Menge der Attributnamen einer Relation R, F die Menge funktionaler Abhängigkeiten auf U, R 1 (X), R 2 (Y) zwei Relationen wobei ¾¾ X ¾¾¾¾¾¾¾¾ X Í U, Y Í U, X È Y = U ¾¾¾¾¾¾¾¾¾ U ¾¾¾¾¾¾¾¾¾ ¾¾¾¾¾¾¾¾ Y ¾¾ A 1 A n R. Marti 19

20 Abhängigkeitserhaltung von Zerlegungen Definition: Eine Zerlegung R 1 (X), R 2 (Y) von R(U) heisst abhängigkeitserhaltend, sofern die Vereinigung der Mengen aller funktionaler Abhängigkeiten in R 1 und aller funktionaler Abhängigkeiten in R 2 die Menge aller funktionalen Abhängigkeiten in R ergibt. Formal: ( F + X È F + Y ) + = F +, wobei z.b. F + X diejenigen funktionalen Abhängigkeiten der Form Z W aus F + sind, deren linke und rechte Seiten in X enthalten sind, also Z Í X und W Í X gilt. (F + Y ist analog definiert.) Intuitiv: Falls die Attribute einer bestehenden (oder allenfalls abgeleiteten) funktionalen Abhängigkeit nicht entweder alle in X (bzw. alle in Y) enthalten sind, dann verlieren wir bei der Zerlegung diese funktionale Abhängigkeit. R. Marti 20

21 Abhängigkeitserhaltung von Zerlegungen: Beispiel StudExam(SNo, SName, Address, DNo, DName, Course, Grade) F = { SNo Course Grade, SNo SName Address DNo, DNo DName } ß StudInfo(SNo, SName, Address, DNo, DName) Exam(SNo, Course, Grade) ist abhängigkeitserhaltend Course(Subject, Time, Room) F = { Subject Room, Time Room Subject } ß CourseLoc(Subject, Room) CourseTime(Subject, Time) ist nicht abhängigkeitserhaltend weil Time Room Subject weder in CourseLoc noch in CourseTime repräsentiert werden kann R. Marti 21

22 Verlustfreiheit von Zerlegungen Ebenso wichtig ist, dass bei einer Zerlegung einer Relation R in die Relationen R 1 und R 2 immer die gleiche Information gespeichert werden kann. Insbesondere soll durch einen natürlichen Join der Relationen R 1 und R 2 über die gemeinsamen Attribute die Attribute in X Y genau die ursprüngliche Relation R entstehen. Definition: Eine Zerlegung R 1 (X), R 2 (Y) von R(U) heisst verlustfrei (lossless), sofern p X (R) p Y (R) = R gilt. Bemerkung: Bei nicht verlustfreien ( lossy ) Zerlegungen gilt: p X (R) p Y (R) R (!) R. Marti 22

23 Verlustfreiheit von Zerlegungen: Beispiel Ursprüngliche Relation: Order Date CNo PNo Descr Price Weight Qty Papier Disketten Nicht-verlustfreie Zerlegung: OrderQty Date CNo PNo Qty OrderDescr Date Descr Price Weight Papier Disketten Test durch Join: OrderQty x OrderDescr Date CNo PNo Descr Price Weight Qty Papier Disketten Papier Disketten R. Marti 23

24 Zerlegungen und Normalformen Kann immer eine "vernünftige" Zerlegung in 3NF oder gar BCNF erreicht werden? Satz: Zu jeder Relation R existiert eine Zerlegung in 3NF-Relationen, die verlustfrei und abhängigkeitserhaltend ist. Satz: Zu jeder Relation R existiert eine Zerlegung in BCNF-Relationen, die verlustfrei ist. Satz: Sei U die Menge der Attributnamen einer Relation R, F eine Menge funktionaler Abhängigkeiten auf U, X Y Î F + mit X Ç Y = Æ Dann gilt: Die Zerlegung von R in R 1 (X È Y) und R 2 (U Y) ist verlustfrei. Der letzte Satz bildet die Grundlage für eine iterative BCNF Zerlegung. ¾¾¾¾¾¾¾¾¾ U ¾¾¾¾¾¾¾¾¾ ¾ ( U Y ) ¾¾¾¾¾¾¾ ¾¾ X ¾¾ ¾¾ Y ¾¾ A 1 A n R. Marti 24

25 BCNF Zerlegung: Beispiel Geg.: R(FlightNo, Date, DepTime, TicketNo, SeatNo, Name, BagClaimNo, Weight) F = { FlightNo Date DepTime, FlightNo Date TicketNo SeatNo, TicketNo Name, BagClaimNo TicketNo Weight } Zerlegung von R entlang FlightNo Date DepTime: Flight R 1 (FlightNo, Date, DepTime) R 2 (FlightNo, Date, TicketNo, SeatNo, Name, BagClaimNo, Weight) Zerlegung von R 2 entlang FlightNo Date TicketNo SeatNo: Reservation R 21 (FlightNo, Date, TicketNo, SeatNo) R 22 (FlightNo, Date, TicketNo, Name, BagClaimNo, Weight) Zerlegung von R 22 entlang TicketNo Name: Ticket R 221 (TicketNo, Name) R 222 (FlightNo, Date, TicketNo, BagClaimNo, Weight) Zerlegung von R 222 entlang BagClaimNo TicketNo Weight: Baggage R 2221 (BagClaimNo, TicketNo, Weight) CheckIn R 2222 (FlightNo, Date, BagClaimNo) R. Marti 25

26 Zusammenfassung der Normalisierung Normalisierung ist formaler als ER-Modellierung, basiert aber letztlich auf ähnlichen Ueberlegungen, nämlich Schlüsselkandidaten und Kardinalitäten von Beziehungen Weder Normalisierung noch ER-Modellierung geben die Garantie, keine Fehler zu machen... Gibt es noch weitere Abhängigkeiten? mehrwertige Abhängigkeiten (Multi-Valued Dependencies) im wesentliche m:m-beziehungen Join Dependencies Inclusion Dependencies im wesentlichen Foreign Key Bedingungen Gibt es noch weitere Normalformen? 4NF (nicht mehrere Multi-Valued Dependencies in einer Relation) 5NF und mehr... R. Marti 26