IS: Datenbanken, © Till Hänisch 2000 Entwurfstheorie Normalisierung oder "Wie man sich Ärger erspart"

Präsentation zum Thema: "IS: Datenbanken, © Till Hänisch 2000 Entwurfstheorie Normalisierung oder "Wie man sich Ärger erspart""—  Präsentation transkript:

1 IS: Datenbanken, © Till Hänisch 2000 Entwurfstheorie Normalisierung oder "Wie man sich Ärger erspart"

2 IS: Datenbanken, © Till Hänisch 2000 Hintergrund Vermeidung von Anomalien Redundanzen Ursprünglich von Codd (1971) 3 Normalformen später mehr Jede Stufe ist Verschärfung Normalisierung führt i.A. zur Aufspaltung von Relationen Verlustfreie Zerlegung, abhängigkeitsbewahrend,... z.B. [Elmasri]

3 IS: Datenbanken, © Till Hänisch 2000 Übersicht Alle Relationen 1. Normalform 2. Normalform 3. Normalform BCNF

4 IS: Datenbanken, © Till Hänisch 2000 Normalformen Regeln für guten DB-Entwurf kein "Kochbuch" "strenge" Normalisierung -> viele Relationen erfordert Wissen über Bedeutung der Attribute als Selbstzweck nicht erforderlich nicht (immer) sinnvoll (Performance, Aufwand bei Applikationsentwicklung, Zahl der Relationen,...) 1. Normalform Alle Attribute sind atomar

5 IS: Datenbanken, © Till Hänisch 2000 Functional dependencies B heißt funktional abhängig von A, wenn Beispiel: EMP(eno,ename,dno,dname) FDs: B voll funktional abhängig von A, wenn 1T42CS 2H42CS 3X42CS 4Y42CS

6 IS: Datenbanken, © Till Hänisch 2000 2. Normalform Alle Nicht-Schlüssel-Attribute sind voll funktional abhängig vom Schlüssel Beispiel: Angebot(Lieferant#,Artikel#, LieferantName) ist nicht in 2. NF, da Lieferant#  LieferantName NB: Wenn R in 1. NF und PK aus einem Attribut besteht, ist R immer in 2. NF NB: Zusätzlicher "künstlicher" Key sichert zwar immer 2. NF, löst aber nicht das Problem, Angebot(ID,Lieferant#,Artikel#, LieferantName) ist zwar in 2.NF, aber trotzdem problematisch, deshalb 3.NF

7 IS: Datenbanken, © Till Hänisch 2000 3. Normalform B heißt transitiv abhängig von A, wenn Keine transitiven Abhängigkeiten von Nicht-Schlüssel-Attributen alternative Formulierung

8 IS: Datenbanken, © Till Hänisch 2000 BCNF 3. NF betrifft nur Nicht-Schlüssel- Attribute, deshalb BCNF: Beispiel: Angebot(Lief#,LiefName,Artikel#,Menge) Annahme: LiefName sei eindeutig (LiefName,Artikel#) und (Lief#,Artikel#) sind candidate keys wir wählen (LiefName,Artikel#) als PK FDs:... Lief#  LiefName, Lief# ist aber nicht Teil des PK !! exotisch Höhere Normalformen (4., 5., MVD,...): Literatur

9 IS: Datenbanken, © Till Hänisch 2000 Zerlegung (decomposition) Wie erhält man normalisierte Relationen ? R(X,Y) R 1 (X)R 2 (Y) |X| R'(X,Y) XX YY R=R' ? Wenn ja, dann verlustfrei (lossless) i.A. nicht, d.h. R  R' !!! i.A. R'  R, es entstehen neue Tupel

10 IS: Datenbanken, © Till Hänisch 2000 Beispiel R(A,B,C) a b c a' b c' a bb c a' b b c' |X| a b c a b c' a' b c a' b c'  AB  BC ??? R  R' !!!

11 IS: Datenbanken, © Till Hänisch 2000 Wie soll zerlegt werden ? Behauptung: Beispiel: EMP(eno,ename,dno,dname) FDs: eno  ename eno  dno dno  dname (verletzt 3. NF, also Zerlegung da dno  dname, sollte X  Y=dno sein, also EMP'(eno,ename,dno), DEPT(dno,dname) "Zerlegung entlang FDs"

12 IS: Datenbanken, © Till Hänisch 2000 Normalisierung NormalformTestAbhilfe 1. NFRelation sollte keine mehrwertigen Attribute haben Neue Relation für jedes mehrwertige Attribut 2. NFBei Relationen mit zusammengesetztem PK sollte kein Attribut von einem Teil des Schlüssels funktional abhängig sein Zerlegung, neue Relation für jeden Teil des Schlüssels mit den abhängigen Attributen. (Achtung: Beziehung zum PK der ursprünglichen Relation und allen abhängigen Attributen muß erhalten bleiben) 3. NFKein Nicht-Schlüsselattribut sollte von einem anderen Nicht-Schlüsselattribut funktional abhängig sein Zerlegung, neue Relation mit den Nicht- Schlüsselattributen und ihren abhängigen Attributen

13 IS: Datenbanken, © Till Hänisch 2000 Zusammenfassung "Your attributes shall depend on the key, the whole key and nothing but the key so help me Codd" (Usenet, comp.databases.oracle, Autor unbekannt)