Logischer DB-Entwurf
Entwurf eines relationalen DB-Schemas
• Ziel:
– Regeln für die Umsetzung eines ER-Modells in ein Relationenschema
– theoretische Grundlagen für den Entwurf eines “guten“
relationalen DB-Schemas
Normalisierungslehre
Entwurfstheorie
• Was macht einen schlechten DB-Entwurf aus?
– Redundanzen
– schlechte Handhabbarkeit – Löschanomalien
– Potentielle Inkonsistenz (Änderungsanomalien) – Einfügeanomalien
Oft hervorgerufen durch “Vermischung“ von Entities
• Normalisierung von Relationen
– Hilft, einen gegebenen Entwurf zu verbessern
Funktionale Abhängigkeiten
• Funktionale Abhängigkeit (Functional Dependency) FD Die FD X Y gilt (X bestimmt Y funktional), wenn für alle Relationen r des Relationenschemas R gilt: Zwei Tupel, deren Wert in X übereinstimmt, stimmen auch in Y
überein. X und Y sind Mengen von Attributen.
Formal: uR vR (u[X] = v[X]) (u[Y] = v[Y]) Graphische Notation Abhängigkeitsdiagramme:
PNR
NAME
BERUF PNR
PROJNR DAUER
Grundbegriffe bei funktionalen Abhängigkeiten
Triviale FD: X X
Volle funktionale Abhängigkeit:
A1, A2, ...., An B1, B2, ..., Bm
B = { B1, B2, ..., Bm } ist voll funktional abhängig von A = {A1, A2, ..., An}, wenn B funktional abhängig von A, aber nicht funktional abhängig von einer echten Teilmenge von A ist.
Beispiel:
PNR
PROJNR DAUER
A B ist eine partielle Abhängigkeit, wenn ein Attribut Ai in A existiert, so daß ( A - {Ai}) B gilt:
Beispiel:
PNR PROJNR
NAME
Ableiten von funktionalen Abhängigkeiten (Inferenz)
• Implikation: Aus einer einer Menge von gegebenen FDs F können meist weitere FDs f abgeleitet werden:
– angestellter stufe, stufe gehalt impliziert angestellter gehalt
– F+ = Hülle (closure) von F ist die Menge aller FDs, die durch F impliziert werden
• Armstrongsche Axiome (X, Y, Z sind Mengen von Attributen):
– Reflexivität: Wenn X Y, dann X Y
– Erweiterbarkeit: Wenn X Y, dann XZ YZ für beliebige Z
– Transitivität: Wenn X Y und Y Z, dann X Z
• Armstrongsche Axiome sind klare und vollständige Inferenzregeln für FDs!
Unnormalisierte Relation
• Beispiel:
ANG-U
(ANGNR, NAME, ORT, ABTNR, ABTNAME, PROJNR, PROJNAME, DAUER) 3740 Kunz K 35 Produktion 4711 MM-PC 8 4713 PII-BOARD 2
3817 Hinz M 40 Forschung 4711 MM- PC 12
4713 PII-BOARD 3 4715 Chipsatz 18
3819 Jansen B 35 Produktion 4711 MM-PC 6 4715 Chipsatz 12 enthält Attribute, die selbst aus Werten zusammengesetzt sind
• Vorteile:
– Clusterbildung
– Darstellung von komplexen Objekten (hierarchische Sichten)
• Nachteile
– hohe Redundanzen (bei n:m-Beziehungen) – erhöhter Speicherplatzbedarf
– erschwerte Handhabung durch unterschiedliche Anzahl von Elementen – Anomalien bei Aktualisierung
Anomalien
• Einfüge-Anomalie
Bei Einfügen neuer Projekte können Informationen darüber nicht gespeichert werden, solange es keine Angestellten zu diesem Projekt gibt; ANGRNR ist
Primärschlüssel in ANG-U
• Änderungs-Anomalie
Eine Abteilung erhält neue Aufgaben und wird daher umbenannt. Gesamte Relation muß durchsucht, und es müssen u.U. zahl-reiche Sätze geändert werden, obwohl sich nur eine Information ändert.
• Lösch-Anomalie
Bei Beendigung von Projekten (z.B. 4711, 4713) sollen die Informationen hierüber gelöscht werden. Wenn ein Angestellter (z.B. Kunz) nur an diesen Projekten beteiligt
1. Normalform
• Alle Attributwerte sind atomar (d.h. bestehen nicht aus mehreren Elementen).
ANG-1
(ANGNR, NAME, ORT, ABTNR, ABTNAME, PROJNR, PROJNAME, DAUER) 3740 Kunz K 35 Produktion 4711 MM-PC 8 3740 Kunz K 35 Produktion 4713 PII-Board 2 3817 Hinz M 40 Forschung 4711 MM- PC 12
3817 Hinz M 40 Forschung 4713 PII-BOARD 3
3817 Hinz M 40 Forschung 4715 Chipsatz 18
3819 Jansen B 35 Produktion 4711 MM-PC 6 3819 Jansen B 35 Produktion 4715 Chipsatz 12
• Vorteile:
– Wegfall mehrwertiger Attribute
• Nachteile
– gleiche Nachteile wie bei unnormalisierter Relation (Anomalien etc.)
2. Normalform (2NF)
• Eine Relation ist in 2. Normalform (2NF), wenn sie in 1NF ist und jedes Nicht-Schlüsselattribut voll funktional
abhängig ist vom Primärschlüssel.
• Beispiel:
ANGR NAME
(ANGR, PROJNR) PROJNAME /Projekt-Nr. allein bestimmt den Projektnamen, keine volle funktionale Abhängigkeit /
• Vorgehensweise:
1. Lagere alle Attribute aus der ursprünglichen Relation aus, die nicht voll funktional abhängig vom gesamten Primärschlüssel sind.
2. Definiere für jede logisch zusammengehörige
Attributkombination (idealerweise = Entity-Typ) eine neue
2. Normalform (Beispiel)
ANG-2
(ANGNR, NAME, ORT, ABTNR, ABTNAME) 3740 Kunz K 35 Produktion
3817 Hinz M 40 Forschung 3819 Jansen B 35 Produktion ANGPROJ
(ANGNR, PROJNR, DAUER) 3740 4711 8
3740 4713 2 3817 4711 12 3817 4713 3 3817 4715 18 3819 4711 6
3919 4715 ^^^^ 12 PROJEKT
(PROJNR, PROJNAME) 4711 MM-PC
4713 PII-BOARD 4715 Chipsatz
3. Normalform (3NF)
• Eine Relation ist genau dann in 3. Normalform (3NF), wenn sie in 2NF ist und keine transitiven Abhängigkeiten aufweist.
– 3NF ist verletzt, wenn es eine funktionale Abhängigkeit N A gibt, mit N, A = Nichtschlüsselattribut. Somit gilt auch X N A (mit X=Primärschlüssel), da Relation in 2 NF ist.
• Beispiel:
ANGNR ABTNR ABTNAME
• Vorgehensweise:
1. Lagere zunächst alle Nichtschlüsselattribute aus der ursprüng- lichen Relation aus, die funktional von Nichtschlüsselattributen abhängen.
2. Definiere für jedes Nichtschlüsselattribut, von dem andere Nichtschlüsselattribute abhängen, eine neue Relation.
3. Mache das Nichtschlüsselattribut, das die anderen
Nichtschlüssel-attribute bestimmt, zum Primärschlüssel der
3. Normalform (Beispiel)
ANG-3
(ANGNR, NAME, ORT, ABTNR) 3740 Kunz K 35
3817 Hinz M 40 3819 Jansen B 35
ABTEILUNG
(ABTNR, ABTNAME) 35 Produktion 40 Forschung
ANG-PROJ PROJEKT
(ANGNR, PROJNR, DAUER) (PROJNR, PROJNAME)
3740 4711 8 4711 MM-PC
3740 4713 2 4713 PII-BOARD 3817 4711 12 4715 Chipsatz
3817 4713 3
3817 4715 18
3819 4711 6
Abschließende Bemerkungen
• Rekonstruktion der ursprünglichen Daten und Beziehungen mittels Verbund (Join) möglich.
• Nachteil von Normalisierung: hoher
Verknüpfungsaufwand bei übergreifenden Anfragen (Performance).
• Weitere ^Normalformen in der Literatur beschrieben (z.B. Boyce-Codd-Normalform)
– höhere Normalformen in der Praxis nicht relevant
