Folie 1

Datenbanken
Rückblick:
Datenbank-Entwurfsprozess
Semantische Datenmodellierung
(vgl. Kapitel 2)
Überführung des semantischen
Datenmodells in das relationale
Modell (vgl. Kapitel 3)
Das relationale Modell wird in
eine normalisierte Form
gebracht.
1
Stephan Karczewski - Datenbanken
4. Normalisierung
Datenbanken
Normalisierung von relationalen Datenbanken
Anomalien:
Datenbanken ändern ihren Zustand ständig durch Einfügen, Ändern oder Löschen von Tupeln.
Wie wir im 1. Kapitel gesehen haben, sind Inkonsistenzen von Datenbanken, also Zustände, die
die Realität nicht richtig wiedergeben, unerwünscht. So führen z.B. Redundanzen häufig zu
Inkonsistenzen. Nur bei den genannten Zustandsänderungen können nicht gewünschte
Zustände entstehen, die man mit dem Begriff Anomalie bezeichnet. Hingegen braucht das Lesen
(also Informieren) nicht im Bezug auf Anomalien betrachtet werden, da Leseoperationen den
Datenbank-Zustand nicht verändern.
Normalisierung:
Die Normalisierung ist ein Vorgehen, das auf vorhandene relationale Datenbanken angewendet
werden kann. Das Verfahren garantiert – angewendet auf Relationen – im Ergebnis eine Menge
von Relationen mit der gleichen Semantik wie zu vor, die jedoch normalisiert sind. Die Menge der
Relationen nimmt durch den Normalisierungsprozess zu.
Mit der Kenntnis der Normalisierung und durch den Prozess der guten Modellierung können
Anomalien zu einem großen Teil bereits beim Entstehungsprozess des Datenmodells vermieden
werden. Insofern empfiehlt es sich, den Datenmodellierungs-Prozess richtig zu durchlaufen.
2
Stephan Karczewski - Datenbanken
4. Normalisierung
Datenbanken
Anomalien (Beispiel):
Töpferprodukt Markt
Prod-Nr.
Produktart
Funktion
Verkaufsmarkt
Marktstandort
Marktspez. Preis
11022
Tee-Service
Gebrauch
Internat. Tonmarkt
Strasbourg
200 €
10622
Kaffee-Service
Gebrauch
Internat. Tonmarkt
Strasbourg
200 €
20131
Schale
Deko
Rheinischer Tonmarkt
Mainz
80 €
20131
Schale
Deko
Odenwälder Töpfermarkt
Erbach
50 €
20131
Schale
Deko
Internat. Tonmarkt
Strasbourg
120 €
40030
Krug
Deko
Internat. Tonmarkt
Strasbourg
100 €
40031
Krug
Deko
Odenwälder Töpfermarkt
Erbach
80 €
Die Einfüge-Anomalie beschreibt eine Anomalie, die auftritt, wenn ein Tupel eingefügt
wird.
Was passiert, wenn ein neuer Verkaufsmarkt eingefügt werden soll, für den noch keine
Produkte existieren?
Was passiert, wenn ein neues Produkt erzeugt wird, das noch auf keinem Markt existiert?
3
Stephan Karczewski - Datenbanken
4. Normalisierung
Datenbanken
Anomalien (Beispiel):
Töpferprodukt Markt
Beispiel: Einfügen des Produktes (33033, Schüssel, Gebrauch) in die Tabelle ohne zugehörigen Markt:
Prod-Nr.
Produktart
Funktion
Verkaufsmarkt
Marktstandort
Marktspez. Preis
11022
Tee-Service
Gebrauch
Internat. Tonmarkt
Strasbourg
200 €
10622
Kaffee-Service
Gebrauch
Internat. Tonmarkt
Strasbourg
200 €
20131
Schale
Deko
Rheinischer Tonmarkt
Mainz
80 €
20131
Schale
Deko
Odenwälder Töpfermarkt
Erbach
50 €
20131
Schale
Deko
Internat. Tonmarkt
Strasbourg
120 €
40030
Krug
Deko
Internat. Tonmarkt
Strasbourg
100 €
40031
Krug
Deko
Odenwälder Töpfermarkt
Erbach
80 €
33033
Schüssel
Gebrauch
???
???
???
Problematik (Einfüge-Anomalie):
•
Die neue (letzte) Zeile ist nicht vollständig.
•
Der Teilschlüssel Verkaufsmarkt erhält keinen Wert (nicht zulässig).
•
Angenommen es existiert noch kein Markt, aber sehr viele Produkte:
Der benötigte Speicher ist etwa doppelt so hoch wie die Menge der Daten.
4
Stephan Karczewski - Datenbanken
4. Normalisierung
Datenbanken
Anomalien (Beispiel):
Töpferprodukt Markt
Prod-Nr.
Produktart
Funktion
Verkaufsmarkt
Marktstandort
Marktspez. Preis
11022
Tee-Service
Gebrauch
Internat. Tonmarkt
Strasbourg
200 €
10622
Kaffee-Service
Gebrauch
Internat. Tonmarkt
Strasbourg
200 €
20131
Schale
Deko
Rheinischer Tonmarkt
Mainz
80 €
20131
Schale
Deko
Odenwälder Töpfermarkt
Erbach
50 €
20131
Schale
Deko
Internat. Tonmarkt
Strasbourg
120 €
40030
Krug
Deko
Internat. Tonmarkt
Strasbourg
100 €
40031
Krug
Deko
Odenwälder Töpfermarkt
Erbach
80 €
Die Änderungs-Anomalie beschreibt eine Anomalie, die auftritt, wenn ein Tupel geändert
wird.
Was passiert, wenn der Marktstandort eines Verkaufsmarktes (z.B. Odenwälder
Töpfermarkt) geändert werden soll?
Was passiert, wenn die Funktion eines Produktes (z.B. 20131 von Deko zu Gebrauch)
geändert werden soll?
5
Stephan Karczewski - Datenbanken
4. Normalisierung
Datenbanken
Anomalien (Beispiel):
Töpferprodukt Markt
Beispiel: Ändern des Produktes mit Nummer 20131: Funktion ist jetzt „Gebrauch“
Prod-Nr.
Produktart
Funktion
Verkaufsmarkt
Marktstandort
Marktspez. Preis
11022
Tee-Service
Gebrauch
Internat. Tonmarkt
Strasbourg
200 €
10622
Kaffee-Service
Gebrauch
Internat. Tonmarkt
Strasbourg
200 €
20131
Schale
Deko
Rheinischer Tonmarkt
Mainz
80 €
20131
Schale
Deko
Odenwälder Töpfermarkt
Erbach
50 €
20131
Schale
Deko
Internat. Tonmarkt
Strasbourg
120 €
40030
Krug
Deko
Internat. Tonmarkt
Strasbourg
100 €
40031
Krug
Deko
Odenwälder Töpfermarkt
Erbach
80 €
Problematik (Änderungs-Anomalie):
•
Die zu ändernde Information ist redundant gespeichert, weil jedes Produkt so häufig
vorkommt wie es auf Märkten existiert.
•
Obwohl nur eine Änderung in der Realität durchgeführt werden soll, sind hier mehrere (3)
Änderungen vorzunehmen.
6
Stephan Karczewski - Datenbanken
4. Normalisierung
Datenbanken
Anomalien (Beispiel):
Töpferprodukt Markt
Prod-Nr.
Produktart
Funktion
Verkaufsmarkt
Marktstandort
Marktspez. Preis
11022
Tee-Service
Gebrauch
Internat. Tonmarkt
Strasbourg
200 €
10622
Kaffee-Service
Gebrauch
Internat. Tonmarkt
Strasbourg
200 €
20131
Schale
Deko
Rheinischer Tonmarkt
Mainz
80 €
20131
Schale
Deko
Odenwälder Töpfermarkt
Erbach
50 €
20131
Schale
Deko
Internat. Tonmarkt
Strasbourg
120 €
40030
Krug
Deko
Internat. Tonmarkt
Strasbourg
100 €
40031
Krug
Deko
Odenwälder Töpfermarkt
Erbach
80 €
Die Lösch-Anomalie beschreibt eine Anomalie, die auftritt, wenn ein Tupel gelöscht wird.
Was passiert, wenn ein Produkt gelöscht wird?
Was passiert, wenn ein Produkt gelöscht wird, das das einzige (aktuelle) auf einem Markt ist?
Was passiert, wenn ein Markt gelöscht wird?
Was passiert, wenn ein Markt gelöscht wird, auf dem ein Produkt angeboten wird, das auf
keinem anderen angeboten wird?
7
Stephan Karczewski - Datenbanken
4. Normalisierung
Datenbanken
Anomalien (Beispiel):
Töpferprodukt Markt
Beispiel: Löschen des Produktes mit Nummer 20131.
gelöschte
Zeilen
Prod-Nr.
Produktart
Funktion
Verkaufsmarkt
Marktstandort
Marktspez. Preis
11022
Tee-Service
Gebrauch
Internat. Tonmarkt
Strasbourg
200 €
10622
Kaffee-Service
Gebrauch
Internat. Tonmarkt
Strasbourg
200 €
20131
Schale
Deko
Rheinischer Tonmarkt
Mainz
80 €
20131
Schale
Deko
Odenwälder Töpfermarkt
Erbach
50 €
20131
Schale
Deko
Internat. Tonmarkt
Strasbourg
120 €
40030
Krug
Deko
Internat. Tonmarkt
Strasbourg
100 €
40031
Krug
Deko
Odenwälder Töpfermarkt
Erbach
80 €
Problematik (Lösch-Anomalie):
•
Nur ein Produkt soll gelöscht werden, aber 3 Zeilen müssen dafür wegfallen.
•
Obwohl nur ein Produkt zu löschen ist, wird ein Markt (Rheinischer Tonmarkt) komplett
verschwinden, weil dieses Produkt das einzige auf dem Markt war.
8
Stephan Karczewski - Datenbanken
4. Normalisierung
Datenbanken
Ursachen der Anomalien
9
•
Die Ursache von Anomalien liegt in der Redundanz der Daten. Sobald ein Faktum mehrfach
(also redundant) gespeichert ist, läuft man Gefahr, bei Änderungen (Löschungen,
Einfügungen) Fehler zu machen.
•
Die Tatsache, dass man ein Faktum mehrfach abspeichert (bzw. wie in dem Beispiel
abspeichern muss), liegt darin begründet, dass die Relationen ungünstig gewählt werden.
So erscheint es bei näherer Betrachtung unsinnig, dass man Produkte und Märkte in einer
Relation unterbringt.
•
Das Erkennen von ungünstigen Relationen sollte nicht nur intuitiv erfolgen. Das Konzept der
funktionalen Abhängigkeit ermöglicht es, systematisch solche Relationen zu finden.
Stephan Karczewski - Datenbanken
4. Normalisierung
Datenbanken
Funktionale Abhängigkeit
Funktion zwischen einer Menge A und B:
Abbildung einer Menge A auf eine Menge B, für die gilt:
Für alle a  A gibt es genau ein b  B.
Funktionale Abhängigkeit:
Eine Menge B von Attributen B1, B2, … Bn ist funktional abhängig von einer Menge A von
Attributen A1, A2, … An, wenn eine Funktion zwischen A und B besteht,
d. h. für alle {a1,a2, … an}  A gibt es genau ein {b1, b2, … bn }  B.
Mit anderen Worten:
In einer Relation ist Attribut(-kombination) B ist funktional abhängig
von Attribut(-kombination) A,
wenn für gleiche A-Werte jeweils gleiche B-Werte vorhanden sind.
Darstellung:
A  B bedeutet: B hängt funktional von A ab, wobei A und B jeweils ein(e) Attribut(-menge) ist.
10
Stephan Karczewski - Datenbanken
4. Normalisierung
Datenbanken
Funktionale Abhängigkeit (Beispiel):
A
B
C
1
2
3
1
2
2
3
2
2
Mögliche Aussagen:
•
A  B gilt aktuell. Jedoch könnte zu einem anderen Zeitpunkt eine Zeile (1, 3, 3) eingefügt
•
•
•
•
werden, so dass A  B nicht mehr gelten würde.
B  C gilt nicht, da es für den gleichen B-Wert (2) verschiedene C-Werte (3 und 2) gibt.
C  B gilt aktuell. Jedoch könnte zu einem anderen Zeitpunkt eine Zeile (1, 3, 2) eingefügt
werden, so dass C  B nicht mehr gelten würde.
A, B  C gilt nicht, weil es für eine gleiche A,B-Kombination (1, 2) zwei verschiedene CWerte (3 und 2) gibt.
A  A gilt immer (trivial).
Der Primärschlüssel einer Relation kann über die funktionale Abhängigkeit wie folgt spezifiziert
werden: Ein Attribut (oder eine Kombination von Attributen) K heißt Schlüssel einer Relation,
wenn für alle Attribute X aus der Relation gilt: K  X. Zusätzlich muss gelten, dass keine echte
Teilmenge von K diese Bedingung erfüllt (Minimalitätsbedingung).
Die funktionale Abhängigkeit wird aktiv definiert (so wie der Schlüssel), d.h. es wird vor
Eintragung von Tupeln festgelegt, welche funktionale Abhängigkeiten gelten und anschließend
wird bei jedem Eintrag geprüft, ob diese eingehalten werden kann. Falls nicht, wird der Eintrag
nicht akzeptiert.
11
Stephan Karczewski - Datenbanken
4. Normalisierung
Datenbanken
1. Normalform (1NF)
Ein Relationenschema ist in 1. Normalform (1NF), wenn alle Attribute des Schemas elementar
(atomar) sind.
Dies bedeutet, dass für die Attribute nur einfache, unstrukturierte Attribute erlaubt sind.
Listenartige, mengenwertige oder relationenartige Attribute sind nicht erlaubt.
Erlaubte Datentypen: integer, real, string (=char(), =varchar()), enum.
Nicht erlaubte Datentypen: array, record, list.
Nicht erlaubte Datentypen sind ohne Probleme in erlaubte zu überführen:
12
•
Ein record ist selbst als Relation der record-Elemente zu definieren.
•
Ein array oder eine Liste kann durch eine Einführung einer Relation, die über den Schlüssel
der Ursprungsrelation verbunden wird, zu erreichen.
Stephan Karczewski - Datenbanken
4. Normalisierung
Datenbanken
1. Normalform (Beispiel)
Lehrbücher
ISBN
Titel
Autor
3-2304-0619
UML Distilled
Fowler
Nicht-atomare
Attributwerte sind
verboten !
Kendall
3-8273-1282-5
Refactoring
Fowler
3-8266-0619-1
Datenbanken
Heuer
Saake
Das Attribut Autor erlaubt pro Tupel (also pro Lehrbuch) für die 1NF nur einen Autor.
Jedoch sind mehr Autoren pro Buch in der Realität erwünscht.
Es ist nicht erlaubt, etwa den Attribut-Typ array () of string zu wählen, da sonst die
1NF-Eigenschaft verletzt wird.
13
Stephan Karczewski - Datenbanken
4. Normalisierung
Datenbanken
1. Normalform (Beispiel)
Lehrbücher
Buchautoren
ISBN
Titel
ISBN
Autor
3-2304-0619
UML Distilled
3-2304-0619
Fowler
3-8273-1282-5
Refactoring
3-2304-0619
Kendall
3-8266-0619-1
Datenbanken
3-8273-1282-5
Fowler
3-8266-0619-1
Heuer
3-8266-0619-1
Saake
Die Lösung liegt in der Ausgliederung des Attributs, das array-artig war.
14
•
Ein neues Relationenschema wird erzeugt, in der dieses Attribut zusammen mit dem
Primärschlüssel aufgenommen wird.
•
Beide Attribute zusammen bilden den Primärschlüssel des neuen
Relationenschemas.
•
Der Schlüssel des ursprünglichen Relationenschemas wird in dem neuen
Relationenschema Fremdschlüssel.
•
Haben mehrere Autoren an einem Buch mitgeschrieben, so werden
für solche Bücher mehrere Zeilen in der neuen Relation aufgenommen.
Stephan Karczewski - Datenbanken
4. Normalisierung
Datenbanken
1. Normalform (Aufgabe)
Gegeben sei das folgende Relationenschema:
ProfName
Vorlesung
Weber
30.4110, Programmieren 1, 6 SWS
30.4304, Datenbanken, 4 SWS
Karczewski
15
30.4304, Datenbanken, 4 SWS
1.
Ist dieses Relationenschema in 1. Normalform? Erläutern Sie hierzu kurz die Inhalte
des o.a. Schemas.
2.
Wenn nicht: Erstellen Sie 1NF-Schemata mit gleicher Semantik.
3.
Nachdem Sie die Inhalte identifiziert und die Schamta normalisiert haben: Erstellen
Sie ein EERM, das den Sachverhalt ausdrückt.
Stephan Karczewski - Datenbanken
4. Normalisierung
Datenbanken
2. Normalform (2NF)
Ein Relationenschema ist in 2. Normalform (2NF), wenn
•
es in 1. Normalform ist und
•
jedes Nichtschlüsselattribut voll funktional von jedem Schlüssel abhängt (und nicht nur von
einem Teil des Schlüssels)
Abhängigkeiten von einem Teilschlüssel führen zu Anomalien.
Es gilt: Besteht der Schlüssel nur aus einem Attribut und 1NF ist gegeben, dann liegt stets 2NF
vor, weil Teilschlüssel-Abhängigkeit nicht möglich ist.
16
Stephan Karczewski - Datenbanken
4. Normalisierung
Datenbanken
2. Normalform (Beispiel)
Gegeben sei das Anfangsbeispiel
Töpferprodukt Markt
Prod-Nr.
Produktart
Funktion
Verkaufsmarkt
Marktstandort
Marktspez. Preis
11022
Tee-Service
Gebrauch
Internat. Tonmarkt
Strasbourg
200 €
10622
Kaffee-Service
Gebrauch
Internat. Tonmarkt
Strasbourg
200 €
20131
Schale
Deko
Rheinischer Tonmarkt
Mainz
80 €
20131
Schale
Deko
Odenwälder Töpfermarkt
Erbach
50 €
20131
Schale
Deko
Internat. Tonmarkt
Strasbourg
120 €
40030
Krug
Deko
Internat. Tonmarkt
Strasbourg
100 €
40031
Krug
Deko
Odenwälder Töpfermarkt
Erbach
80 €
Bei einem komplexen Relationenschema sollte man zunächst analysieren, welche Inhalte
dargestellt werden. Man muss die Sicht der Anwendung (des Kunden) annehmen, um die
Schemata anschließend richtig (normalisiert) zu formen.
Dieser Prozess des Re-Engineering funktioniert nur über das Verstehen, was gemeint war.
Folgende Schritte eignen sich, um zum Ergebnis zu gelangen:
17
Stephan Karczewski - Datenbanken
4. Normalisierung
Datenbanken
2. Normalform (Beispiel)
1.
Schritt: Identifizieren der funktionalen Abhängigkeiten:
Man erkennt, dass in diesem Schema zwei voneinander unabhängige Entitäten abgebildet sind:
Produkte und Märkte. Produkte besitzen eine Nummer, eine Art und eine Funktion. Märkte
besitzen einen Namen (Verkaufsmarkt) und einen Standort. Der marktspezifische Preis bezieht
sich auf Produkt und Markt gleichermaßen.
Hieraus ergeben sich folgende funktionalen Abhängigkeiten:
Prod-Nr  Produktart; Produktart  Funktion; Verkaufsmarkt  Marktstandort;
Prod-Nr, Verkaufsmarkt  marktspez. Preis
2.
Schritt: Überprüfen auf die Normalformen
1NF ist gegeben, denn jedes Attribut ist atomar (elementar, keine Listen oder Records).
2NF ist nicht gegeben, denn es gibt einige Attribute, die nicht vom ganzen Schlüssel (voll)
funktional abhängen, sondern nur von einem Teil, z.B.
Produktart und Funktion hängen nur von Prod-Nr, nicht von Verkaufsmarkt ab,
Marktstandort hängt nur von Verkaufsmarkt, nicht von Prod-Nr ab.
18
Stephan Karczewski - Datenbanken
4. Normalisierung
Datenbanken
2. Normalform (Beispiel)
3.
Schritt: Auflösen der Teilabhängigkeiten durch Aufteilen des Relationenschemas
Das Relationenschema muss so aufgetrennt werden, dass die gefundenen Teilabhängigkeiten
(2. Schritt) nicht mehr auftreten können.
Wir definieren ein Schema mit den vom Teilschlüssel Prod-Nr abhängigen Attributen, ein
zweites mit den von Verkaufsmarkt abhängigen Attributen und ein drittes mit den von beiden
Teilschlüsseln abhängigen Attributen. Also:
Ursprungsschema:
Töpferprodukt Markt
Prod-Nr.
Produktart
Funktion
Verkaufsmarkt
Marktstandort
Marktspez. Preis
Normalisierte Schemata (2NF):
Töpferprodukt
Prod-Nr.
Markt
Produktart
Funktion
Verkaufsmarkt
Marktstandort
TöpferproduktMarkt
Prod-Nr.
19
Stephan Karczewski - Datenbanken
Verkaufsmarkt
Marktspez. Preis
4. Normalisierung
Datenbanken
2. Normalform (Beispiel)
4.
Schritt: Überprüfen auf die Verbindungen zwischen den neuen Relationenschemata, so dass
gewährleistet ist, dass die Informationen im ursprünglichen Relationenschema noch
vorhanden sind. In diesem Schritt muss untersucht werden, dass kein neues Schema
isoliert ohne Verbindung zum Rest der Schemata exisitert. Ggfs. muss eine solche
Verbindung nachträglich hergestellt werden.
Im Beispiel ist in jedem Schema wenigstens eines der beiden Schlüsselattribute des
Ursprungsschemas vorhanden. Es ist nur noch dafür zu sorgen, dass entsprechende
Fremdschlüssel eingeführt werden.
Die Produkt-Nr. in TöpferproduktMarkt wird Fremdschlüssel zur Produkt-Nr. in Töpferprodukt
und
der Verkaufsmarkt in TöpferproduktMarkt wird Fremdschlüssel zu Verkaufsmarkt in Markt.
Töpferprodukt
Prod-Nr.
Markt
Produktart
Funktion
Verkaufsmarkt
Marktstandort
TöpferproduktMarkt
Prod-Nr.
20
Stephan Karczewski - Datenbanken
Verkaufsmarkt
Marktspez. Preis
4. Normalisierung
Datenbanken
2. Normalform (Beispiel)
Folgende Regeln müssen bei diesem Vorgehen zur Normalisierung beachtet werden:
21
•
Funktionale Abhängigkeiten dürfen bei der Aufteilung in verschiedene Relationenschemata
nicht zerlegt werden, d.h. es muss nach der Aufteilung jedes Attribut einer funktionalen
Abhängigkeit des Ursprungsschemas in einer der zerteilten Schemata komplett vorhanden
sein, also müssen z.B. die Attribute Prod-Nr. und Funktion in einem Schema sein, weil sie
gemeinsam in der funktionalen Abhängigkeit Prod-Nr.  Funktion vorkommen.
•
Der ursprüngliche Schlüssel des Relationenschemas muss in einem der zerteilten
Schemata komplett vorkommen. Der Schlüssel darf also nicht selbst zerteilt werden. Man
spricht hier von Verbundtreue. Bei Verletzung der Verbundtreue entstehen isolierte
Schemata bei der Zerteilung. Im Beispiel ist in dem Schema TöpferproduktMarkt der
ursprüngliche Schlüssel vorhanden (Prod-Nr., Verkaufsmarkt ).
Stephan Karczewski - Datenbanken
4. Normalisierung
Datenbanken
2. Normalform (Beispiel – Verlust der Verbundtreue)
Ursprungsschema:
Töpferprodukt Markt (ohne das Attribut Markspez. Preis )
Prod-Nr.
Produktart
Funktion
Verkaufsmarkt
Marktstandort
Marktspez. Preis
Mit dem Attribut Marktspez. Preis entfällt auch die funktionale Abhängigkeit
Prod-Nr., Verkaufsmarkt  Marktspez.Preis
Normalisierte Schemata (2NF):
Markt
Töpferprodukt
Prod-Nr.
Produktart
Funktion
Verkaufsmarkt
Marktstandort
TöpferproduktMarkt
Prod-Nr.
Verkaufsmarkt
Marktspez. Preis
Das Schema TöpferproduktMarkt wird nicht mehr benötigt wegen der verlorenen funktionalen
Abhängigkeit. Der ursprüngliche Schlüssel ist nicht mehr komplett in einem Schema vorhanden.
Die Schemata Töpferprodukt und Markt sind nicht mehr miteinander verbunden. Man kann also
nicht mehr abbilden, welches Produkt auf welchem Markt angeboten wird.
22
Stephan Karczewski - Datenbanken
4. Normalisierung
Datenbanken
2. Normalform (Beispiel)
Alternativ kann man das Reengineering auch so gestalten, dass man aus dem
Ursprungsschema versucht ein EERM zu entwickeln, das den Sachverhalt wiedergibt.
In unserem Beispiel kann man vermuten, dass es Produkte gibt, die auf Märkten verkauft
werden.
Produkt
(0,*)
1
(1,*)
Markt
Produkt (Prod-Nr., Produktart, Funktion)
Markt (Verkaufsmarkt, Standort)
wirdAngebotenAuf (Marktspez. Preis)
Das EERM wird nach den gelernten Regeln (Kap. 3) überführt in ein relationales Datenmodell.
Produkt
Prod-Nr.
Markt
Produktart
Funktion
Verkaufsmarkt
Marktstandort
wirdAngebotenAuf
Prod-Nr.
23
Stephan Karczewski - Datenbanken
Verkaufsmarkt
Marktspez. Preis
4. Normalisierung
Datenbanken
2. Normalform (Aufgabe)
Gegeben sei das folgende abstrakte Relationenschema, das nicht in 2NF ist.
A
B
C
D
E
F
Schlüssel ist A,B.
Es gelten: A,B  C; A  D; B  E; B  F
Überführen Sie das 2NF-Schema in Schemata, die in 2NF sind.
24
Stephan Karczewski - Datenbanken
4. Normalisierung
Datenbanken
3. Normalform (3NF)
Ein Relationenschema ist in 3. Normalform (3NF), wenn
•
es in 2. Normalform ist (und somit auch in 1. Normalform) und
•
wenn kein Nichtschlüssel-Attribut transitiv von einem Schlüssel abhängt bzw. alle
Nichtschlüssel-Attribute direkt vom Schlüssel abhängen.
Indirekte Abhängigkeiten vom Schlüssel über Nichtschlüssel-Attribute führen zu Anomalien.
Transitive Abhängigkeiten sind Abhängigkeiten über andere Attribute, also z.B.
C hängt transitiv von A ab, wenn es ein B gibt, so dass gilt: A  B und B  C.
25
Stephan Karczewski - Datenbanken
4. Normalisierung
Datenbanken
3. Normalform (Beispiel)
Gegeben sei vom Anfangsbeispiel die Relation
Töpferprodukt
Prod-Nr.
Produktart
Funktion
11022
Tee-Service
Gebrauch
10622
Kaffee-Service
Gebrauch
20131
Schale
Deko
20131
Schale
Deko
20131
Schale
Deko
40030
Krug
Deko
40031
Krug
Deko
Auch hier (wie bei 2NF) kann man systematisch die 3. Normalform herstellen.
26
Stephan Karczewski - Datenbanken
4. Normalisierung
Datenbanken
3. Normalform (Beispiel)
1.
Schritt: Identifizieren der funktionalen Abhängigkeiten:
Prod-Nr.  Produktart; Produktart  Funktion
ergibt sich aus der bereits bei 2NF vorgenommenen Analyse.
2.
Überprüfen auf die Normalformen
1NF ist gegeben, denn jedes Attribut ist atomar (elementar, keine Listen oder Records).
2NF ist gegeben, denn es gibt keine Attribute, die nur von einem Teil des Schlüssels abhängen.
Dies ist in diesem Beispiel nicht möglich, da der Schlüssel nur aus einem Attribut besteht.
3NF ist nicht gegeben, da Funktion transitiv von dem Schlüssel Prod-Nr. abhängt.
27
Stephan Karczewski - Datenbanken
4. Normalisierung
Datenbanken
3. Normalform (Beispiel)
3.
Schritt: Auflösen der transitiven Abhängigkeit(en)
Das Relationenschema muss so aufgetrennt werden, dass die gefundene(n) transitive
Abhängigkeit(en) (2. Schritt) nicht mehr auftreten können.
Wir definieren ein zusätzliches Relationenschema mit dem Attribut, über das die Transitivität
entsteht (Produktart ) und dem Attribut, das transitiv vom Schlüssel abhängt (Funktion ).
Ersteres wird Schlüssel des neuen Relationenschemas. Das ursprüngliche Relationenschema
wird reduziert um das transitiv abhängige Attribut. Das die Transitivität auslösende Attribut wird
Fremdschlüssel zu dem neuen Schema. Also:
Ursprungsschema:
Töpferprodukt
Prod-Nr.
Produktart
Funktion
Normalisierte Schemata (3NF):
Töpferprodukt
Prod-Nr.
4.
28
Produktart
ProduktFunktion
Produktart
Funktion
Überprüfung: Keines der Schemta ist isoliert (also nicht erreichbar).
Stephan Karczewski - Datenbanken
4. Normalisierung
Datenbanken
3. Normalform (Beispiel)
Gesamtlösung für das Anfangsmodell
Töpferprodukt Markt (nicht normalisiert)
Prod-Nr.
Produktart
Funktion
Verkaufsmarkt
Marktstandort
Marktspez. Preis
Normalisierte Schemata (3NF):
Töpferprodukt
Prod-Nr.
29
Markt
Produktart
Verkaufsmarkt
ProduktFunktion
TöpferproduktMarkt
Produktart
Prod-Nr.
Funktion
Stephan Karczewski - Datenbanken
Verkaufsmarkt
Marktstandort
Marktspez. Preis
4. Normalisierung
Datenbanken
3. Normalform (Aufgabe)
Ein Lieferant (L) liefert Teile (T) in einer bestimmten Anzahl (A). Die Teile sind zu liefern an einen
Ort (O) des Kunden, der eine Entfernung in Kilometern (K) vom Standort des Lieferanten entfernt
ist.
LTAOK
LNR
TNR
Anzahl
Ort
KM-Entf.
4711
T1
55
Darmstadt
62
4712
T1
44
Darmstadt
62
4712
T2
33
Darmstadt
62
4713
T1
22
Frankfurt
42
Fragen:
30
•
Welche funktionalen Abhängigkeiten ergeben sich aus dem Text?
•
Ist das Relationenschema in 3NF?
•
Wenn nein: Zerlegen Sie das Schema so, dass anschließend ausschließlich 3NF-Schemata
vorhanden sind.
•
Alternative Vorgehensweise: Erstellen Sie ein ER-Diagramm, das den gleichen Sachverhalt
ausdrückt und entwickeln Sie daraus Relationenschemata.
Stephan Karczewski - Datenbanken
4. Normalisierung
Datenbanken
Normalformen (Kritik und praktische Relevanz)
Es gibt noch weitere Normalformen (4., 5., Boyce-Codd, konjunktive, Projektion-Verbund), die
jedoch in der Praxis weniger relevant sind.
Kritik an der Normalisierung wird mitunter geübt. Es wird behauptet:
„Normalisierung erfordert mehr Speicherplatz“. Diese Aussage ist falsch, auch wenn mehr
Relationen benötigt werden. Diese sind jedoch kleiner.
„Normalisierte Relationen sind umständlicher zu handhaben, weil man die Inhalte über so viele
Tabellen verteilt“. Diese Aussage ist falsch, da es gute Konzepte gibt (z.B. Views), die es
ermöglichen, dem Anwender eine einfache Handhabung mit der Menge der Tabellen zu
ermöglichen.
„Normalisierte Tabellen reduzieren die Laufzeit-Performance, da man häufiger einen Vebund
zwischen vielen Tabellen vornehmen muss.“ Dies Aussage ist korrekt, so dass man nach
kompletter Normalisierung mitunter eine gezielte Denormalisierung vornimmt, bei der
diejenigen Relationen, für die die negativen Auswirkungen der Nicht-Normalisierung (nahezu)
ausgeschlossen werden können, wieder zusammengefasst werden.
In der Regel wird heute die 3. Normalform verwendet, um die Anomalien zu vermeiden. Bei zu
hohem Performance-Verlust, der auf die Normalisierung zurückzuführen ist, wird in seltenen
Fällen denormalisiert. Bei Neu-Entwicklungen von Datenbanken versucht man, die Anomalien
dadurch zu vermeiden, dass man ein gutes EERM entwirft, bevor man die Relationenschemata
erstellt.
31
Stephan Karczewski - Datenbanken
4. Normalisierung
Datenbanken
3. Normalform (Aufgabe)
Die folgenden Attribute seien alle in einem Relationenschema zusammengefasst:
Kontonummer (K), PLZ (P), Ort (O), Filialnummer (F), Bankname (N), Bankleitzahl (L).
Die Attribute hängen folgendermaßen voneinander ab.
Durch die Bankleitzahl wird der Bankname festgelegt. Die Postleitzahl legt den Ort fest.
Die Filialnummer und die Kontonummer hängen vom Banknamen ab.
32
1.
Zeichnen Sie alle funktionalen Abhängigkeiten auf. Benutzen Sie dabei
die Buchstaben in Klammern.
2.
Ermitteln Sie den Schlüssel zu dem Relationenschema
3.
Begründen Sie, warum das Relationenschema nicht in 2.
und nicht in 3. Normalform ist.
4.
Zerlegen Sie das Relationenschema in Relationenschemata so,
dass diese alle in 3. Normalform sind.
Stephan Karczewski - Datenbanken
4. Normalisierung