Töpferprodukt Markt

3. Relationales Modell
• entwickelt von Codd (1970)
• beruht auf dem mathematischen Begriff der Relation,
den man anschaulich mit dem der Begriff Tabelle
vergleichen kann
• alle Informationen sind in Relationen abgelegt
Karczewski
Datenbanken I
1
Grundlagen
Seien W1, W2, ..., Wn die Wertebereiche von Attributen A1, A2, ... An.
•
Das kartesische Produkt der Mengen W1, W2, ..., Wn ist die Menge aller n-Tupel
(w1,w2,...,wn), wi є Wi und wird geschrieben als W1 X W2 X ... X Wn.
•
Jede Untermenge des kartesischen Produkts W1 X W2 X ... X Wn ist eine
(n-stellige) Relation. Der Grad der Relation ist n.
•
Für jede Relation einer Relationalen Datenbank wird ein Relationenschema
festgelegt, durch Angabe eines Namens der Relation und der dazugehörigen
Attribute.
•
Identifizierende Attributkombination einer Relation ist eine Menge von Attributen,
durch die jedes Tupel der Relation identifiziert werden kann.
•
Eine identifizierende Attributkombination K = (A1, A2, ..., Aj) heißt Schlüssel der
Relation, wenn keine echte Untermenge von K identifizierende Attributkombination
der Relation ist.
Karczewski
Datenbanken I
2
Grundlagen
•
Jede Relation besitzt mindestens einen Schlüssel.
•
Falls eine Relation mehrere Schlüssel besitzt, wird ein Schlüssel als Primärschlüssel
(primary key) ausgezeichnet.
•
Der Wert des Primärschlüssels ist eindeutig, nicht änderbar und darf nicht leer sein.
•
Der Primärschlüssel wird im Relationsschema unterstrichen (im Beispiel: Nummer)
•
Aus der mathematischen Definition von Relation folgt, dass zwei Tupel der Relation
paarweise verschieden (da Menge!) sind, d. h. sie unterscheiden sich mindestens in
einem Attribut.
•
Tupel sind nicht geordnet, d. h. die Reihenfolge ist bedeutungslos.
Karczewski
Datenbanken I
3
Beispielrelation
Attribut (Spalte)
Name des Relationenschemas
Markt:
Relation
(Tabelleninhalt)
Karczewski
Bezeichnung
Standort
Kategorie
Internationaler
Töpfermarkt
Krefeld
Töpfermarkt
Töpfermarkt
Sommerhausen
Sommerhausen
Töpfermarkt
Internationaler
Töpfermarkt
Hanau
Töpfermarkt
Datenbanken I
Relationenschema
Tupel (Zeile)
4
Kritik am relationalen Modell
Einfacher Aufbau des Modells wird kritisiert, da die komplexe Welt
auf flache Relationen heruntergebrochen werden muss.
Zusammenhängende Inhalte müssen daher häufig auf mehrere
Tabellen verteilt werden -> Performanzverlust
Entwicklung alternativer Ideen:
• Objektorientierte Datenbanksysteme (kommend von OOSprachen
• Objektrelationale Datenbanksysteme (kommend von relationalen
Datenbanksystemen)
Karczewski
Datenbanken I
5
Integritätsbedingungen
Integrationsbedingungen sind Abhängigkeiten innerhalb einer
Relation oder zwischen Relationen.
•
Eine Abhängigkeit innerhalb einer Relation nennt man
funktionale Abhängigkeit zwischen Attributen. Ein Spezialfall
der funktionalen Abhängigkeit ist der Schlüssel.
•
Abhängigkeiten zwischen Relationen:
Ein Attribut einer Relation A, das in einer anderen Relation
Primärschlüssel ist, wird in A Fremdschlüssel (foreign key)
genannt, wenn dieses Attribut eine Beziehung zwischen den
Relationen herstellt.
Karczewski
Datenbanken I
6
Integritätsbedingungen
Beispiel:
Markt:
Bezeichnung
Veranstalter
Name
Standort
Adresse
Name
Bezeichnung
Kategorie
Typ
Name des Veranstalters ist Primärschlüssel in Veranstalter
und Fremdschlüssel in Markt.
Notation:
Schlüssel: Unterstreichung der Bezeichnung des Attributs
Fremdschlüssel: Strich über Bezeichnung
Karczewski
Datenbanken I
7
Transformation eERM -> Relationales Modell
eERM dient zur Modellierung der Realität aus Sicht der Anwendung
Relationales Modell dient als Grundlage für die Realisierung in
relationalen Datenbanken
Transformation erfolgt durch eindeutige Regeln, mit deren Hilfe
jedes eERM eindeutig in ein gleichbedeutendes Relationales Modell
überführt werden kann.
Mit Hilfe von Case-Tools kann diese Transformation automatisiert
werden.
Karczewski
Datenbanken I
8
Entity-Typen
• jeder Entity-Typ wird zu einem Relationenschema
• Attribute des Entity-Typs werden die Attribute des
Relationenschemas
• falls Entities komplexe Attribute (z.B. record-, array-artig)
aufweisen, müssen diese aufgelöst
werden
• ein Schlüssel (falls noch nicht im eERM geschehen) ist als
Primärschlüssel des Relationenschemas auszuzeichnen
(Unterstreichung), alternativ ist ein zusätzliches
Schlüsselattribut hinzuzufügen
• die Datentypen zu den Attributen müssen definiert werden (falls
noch nicht im eERM geschehen)
Karczewski
Datenbanken I
9
Entity-Typen (Beispiel)
Markt
Bezeichnung
Markt:
Karczewski
Standort
Kategorie
Bezeichnung Standort Kategorie
Datenbanken I
10
Strukturierte Attribute (Beispiel)
Vornamen
Kunde
Nachname
Kd-Nummer
Strasse
Adresse
Stadt
PLZ
Kunde:
Adresse
Vornamen
Kd-Nummer Nachname Strasse PLZ Stadt Vorname_1 Vorname_2
...
Vorname_n
Keine Lösung, da strukturierte Attribute in der Relation nicht erlaubt!
Karczewski
Datenbanken I
11
Strukturierte Attribute (Beispiel)
Vornamen
Kunde
Nachname
Strasse
Adresse
Kd-Nummer
Stadt
PLZ
• Auflösen (“Flachdrücken“)
des strukturierten Attributs
Adresse
• Auslagern der beliebig
vielen Vornamen in eine
eigene Relation
Kunde:
Kd-Nummer Nachname Strasse PLZ Stadt
Vorname:
Kd-Nummer Vorname
Karczewski
Datenbanken I
12
m:n-Beziehung
• Jeder Relationship-Typ wird zu einem Relationenschema.
• Beteiligte Entity-Typen werden wie zuvor behandelt.
• Attribute des Relationship-Typs werden die Attribute des
Relationenschemas.
• Zusätzlich werden die Primärschlüssel der beteiligten Entity-Typen
als Attribute hinzugefügt
• diese bilden zusammen den Primärschlüssel
• und sind jeweils Fremdschlüssel bezogen auf die beiden aus den
Entities entstandenen Relationenschemata
Karczewski
Datenbanken I
13
m:n-Beziehung (Beispiel)
(0,*)
Produkt
(0,*)
6
Markt
Produkt (Nummer, Bezeichnung, Funktion)
Markt (Bezeichnung, Standort, Kategorie)
Konzeptioneller Datenentwurf
6: wird angeboten auf (Anzahl)
eERM-Darstellung mit dem Power-Designer von Sybase:
<pi>
Karczewski
Datenbanken I
14
m:n-Beziehung (Beispiel, Forts.)
<pi>
steht für * ;
steht für 0 ; <pi> heißt Primärschlüssel; I, A20 sind die Typangaben.
Alternativ-Darstellung (mit Attribut im Beziehungstyp):
Die Symbole am Kasten WirdAngebotenAuf bedeuten: (o,*), aus Beziehungstyp entstanden
steht für die Kardinalität (1,1)
Karczewski
Datenbanken I
15
m:n-Beziehung (Beispiel, Forts.)
•
•
Einführung der Schlüssel und
Fremdschlüssel
3 Relationen entstehen (2 aus den
beteiligten Entity-Typen, 1 aus dem
Relationship-Typ)
a) Design-Sicht des Power-Designer:
Logischer Datenentwurf
b) Tabellendarstellung:
Produkt:
Nummer
Markt:
Bezeichnung
WirdAngebotenAuf:
Karczewski
Datenbanken I
Bezeichnung
Standort
Nummer
Funktion
Kategorie
Bezeichnung
Standort
Anzahl
16
Aufgabe
Setzen Sie das folgende ERM in Relationen um.
Wie sehen die Krähenfußdiagramme aus?
Wie sehen die Relationenschemata aus?
(0,*)
Produkt
(0,*)
7
Kunde
Produkt (Produktnummer, Bezeichnung, Preis)
Kunde (Nummer, Name)
7: erhält geliefert (Anzahl, Lieferdatum)
Karczewski
Datenbanken I
17
m:1-Beziehung
• Es wird kein zusätzliches Relationenschema angelegt!!!!
• In das Relationenschema, dessen Tupel nur maximal ein Mal in der
Beziehung erscheinen dürfen, wird der Primärschlüssel des anderen
Relationenschemas als Fremdschlüssel hinzugefügt.
• Attribute der Beziehung werden ebenfalls in dem Relationenschema
hinzugefügt, dessen Tupel nur ein Mal in der Beziehung erscheinen
dürfen.
Karczewski
Datenbanken I
18
m:1-Beziehung (Beispiel)
(1,1)
(0,*)
8
Markt
Veranstalter
Markt (Bezeichnung, Standort, Kategorie)
Veranstalter (Name, Adresse, Bezeichnung, Typ)
8: Ansprechpartner
ERD-Darstellung mit Power-Designer:
<pi>
Karczewski
Datenbanken I
19
m:1-Beziehung (Beispiel)
•
•
nur 2 Tabellen entstehen
Hinzufügen des Fremdschlüssels
(Veranstalter-)Name in Markt
a) Design-Sicht des Power-Designers:
<pk>
b) Tabellendarstellung:
Markt:
Bezeichnung
Veranstalter
Name
Karczewski
Standort
Adresse
Name
Bezeichnung
Datenbanken I
Kategorie
Typ
20
Aufgabe
Setzen Sie das folgende ERM in Relationen um.
(0,1)
Produkt
(0,*)
5
Dekor
Produkt (Produktnummer, Bezeichnung, Größe, Preis)
Dekor (Bezeichnung, Foto)
5: ist versehen mit
Karczewski
Datenbanken I
21
1:1-Beziehung
• Es können (theoretisch) alle Attribute in ein Relationenschema
aufgenommen werden, d. h. aus 2 Entities wird ein
Relationenschema.
• Es ist aber oft doch sinnvoll beide Entities als getrennte Relationen
zu definieren. Dann ist in einem der Relationenschemas der
Schlüssel des anderen als Fremdschlüssel aufzunehmen:
• Sollten z.B. die beteiligten Entity-Typen jeweils unterschiedliche
Beziehungen zu anderen Entity-Typen haben, müssen zwei
Relationenschemata definiert werden.
• Insbesondere bei (0,1):(1,1)- oder (0,1):(0,1)-Beziehungen ist es oft
sinnvoll zwei Relationenschemas zu definieren, da sonst häufig nichtgefüllte Tupel vorkommen.
Karczewski
Datenbanken I
22
Rekursive Beziehung (Beispiel)
Rollen
Teilprodukt
(0,*)
Produkt
(0,*) Produktgruppe
4
4: besteht aus
Karczewski
Datenbanken I
23
Rekursive Beziehung (Beispiel)
Realisierung erfolgt analog zu einer
zweistelligen Beziehung
a. graphische Darstellung
in Krähenfußdarstellung:
b. b. graphische
Darstellung als
Bachmanndiagramm:
Produkt:
c. c. Tabellendarstellung:
Karczewski
Nummer
Besteht_aus:
Datenbanken I
Bezeichnung
NummerO
Funktion
NummerU
Anzahl
24
Aufgabe
Setzen Sie das folgende ERM in Relationen um.
Fach
(0,*)
(0,*)
4
4: ist vorausgesetzt
Karczewski
Datenbanken I
25
Mehrstellige Beziehung
•
•
•
•
Es wird für den Beziehungstyp ein eigenes Relationenschema angelegt.
Verbindung der Schemata mit Hilfe der Primärschlüssel der beteiligten Entities als
Fremdschlüssel in dem aus dem Beziehungstyp entstandenen Relationsschema.
Bei einfacher Kardinalität (0,1) bzw. (1,1) zu einen der beteiligten Entity-Typen können dessen
Attribute in dieses Relationenschema mit aufgenommen werden.
Attribute der Beziehung werden ebenfalls in dem Relationenschema hinzugefügt.
Aufgabe: Setzen Sie das folgende
ERM in Relationen um.
Spediteur
Händler
(1,*)
(1,*)
1
(1,*)
Rohstoff
1: liefert (Bestelldatum, Menge)
Karczewski
Datenbanken I
26
Mehrstellige Beziehung (Lösung)
Karczewski
Händler
Name
Adresse
Firmenbezeichnung
Spediteur
Name
Adresse
Firmenbezeichnung
Rohstoff:
Bezeichnung
Liefert:
HName
Art
SName
Bezeichnung
Datenbanken I
Bestelldatum
Menge
27
Generalisierung/Spezialisierung
Es gibt zwei Varianten der Realisierung:
1. Für jeden Spezialisten und für den Generalisten wird ein eigenes
Relationsschema erstellt.
•
Die Spezialisten erhalten zusätzlich den Primärschlüssel des
Generalisten.
•
Die Primärschlüssel der Spezialisten sind Fremdschlüssel zum
Generalisten.
•
Variante ist sinnvoll,
• wenn der Generalist nicht unbedingt einem Spezialisten zugeordnet
ist (partielle Spezialisierung),
• wenn die Spezialisten überlappen.
Karczewski
Datenbanken I
28
Generalisierung/Spezialisierung
2.
Nur die Subtypes haben ein Relationenschema.
•
Zusätzlich zu den Spezialisten-Attributen werden in
allen Spezialisten alle Generalisten-Attribute
aufgenommen.
•
Nur möglich, wenn jede Instanz des Generalisten
gleichzeitig Instanz eines Spezialisten ist (totale
Spezialisierung).
•
Falls überlappend: Redundante Speicherung!
•
Vorteil: Bei Abfragen müssen Spezialist und Generalist
nicht zusammengeführt werden.
Karczewski
Datenbanken I
29
Generalisierung/Spezialisierun
g
(Beispiel)
Beispiel:
Generalist:
Geschäftspartner (Geschäftspartner-Nr, Adresse,
Telefonnummer)
Spezialisten:
Veranstalter (Bezeichnung, Typ)
Kunde (Name)
Geschäftspartner
O
Veranstalter
Kunde
Umsetzung
Variante 1: Für alle Spezialisten und den Generalisten werden Relationenschemata erstellt:
Karczewski
Geschäftspartner:
Geschaeftspartner-Nr
Veranstalter:
Geschaeftspartner-Nr
Kunde:
Geschaeftspartner-Nr
Datenbanken I
Adresse
Telefonnummer
Bezeichnung
Typ
Name
30
Generalisierung/Spezialisierun
g
(Beispiel)
Beispiel:
Geschäftspartner
Generalist:
Geschäftspartner (Geschäftspartner-Nr, Adresse,
Telefonnummer)
Spezialisten:
Veranstalter (Bezeichnung, Typ)
Kunde (Name)
O
Veranstalter
Kunde
Umsetzung
Variante 2: Nur für die Spezialisten werden Relationenschemata erstellt:
Veranstalter:
Geschaeftspartner-Nr
Adresse
Telefonnummer
Bezeichnung
Kunde:
Geschäftspartner-Nr
Adresse
Telefonnummer
Name
Typ
Bei overlapping redundante Speicherung
Karczewski
Datenbanken I
31
Aufgabe
Setzen Sie folgende Subtype-Beziehung gemäß Variante 1 und
Variante 2 in Relationenschemata um.
Bibliotheksverwaltung:
Generalist: Dokument (DokumentenId, Titel, Standort)
Spezialisten: Buch (ISBN, Autor)
Zeitschrift (Jahrgang, ISSN)
Karczewski
Datenbanken I
32
4. Normalisierung von
Relationenschemata
Ziel:
• Vermeidung von Anomalien in Relationenschemata wird erreicht durch
systematische Vorgehensweise beim Datenentwurf vom eERM zum
Relationalen Modell (s. voriges Kapitel)
• Entfernung von Anomalien ist nötig, wenn nicht systematisch
modelliert wurde
Anomalien:
• Zustände in relationalen Datenbanken, in denen die Veränderung
von Daten zu Datenbankzuständen führt, die nicht die gewünschte
Realität darstellt.
• Unterscheidung zwischen Einfüge-, Änderungs- und LöschAnomalie
Karczewski
Datenbanken I
33
Anomalien
Töpferprodukt Markt
Prod-Nr
Produktart
Funktion
Verkaufsmarkt
11022
10622
20131
20131
20131
40030
40031
Tee-Service
Kaffee-Service
Schale
Schale
Schale
Krug
Krug
Gebrauch
Gebrauch
Deko
Deko
Deko
Deko
Deko
Internat. Tonmarkt
Internat. Tonmarkt
Rheinischer Tonmarkt
Odenwälder Töpferwelt
Internat. Tonmarkt
Internat. Tonmarkt
Odenwälder Töpferwelt
Marktstandort marktspez.Preis
Strasbourg
Strasbourg
Mainz
Erbach
Strasbourg
Strasbourg
Erbach
200 €
200 €
80 €
50 €
120 €
100 €
80 €
Einfüge-Anomalie:
(= Insert-Anomalie)
Neues Tonprodukt einführen, aber noch nicht auf den
Markt bringen. Welches Problem entsteht?
Änderungs-Anomalie:
(= Update-Anomalie)
Für Prod-Nr 20131 sei nicht mehr „Deko“ die Funktion
sondern “Gebrauch“. Welches Problem entsteht?
Lösch-Anomalie:
(Delete-Anomalie)
Produkt 20131 ganz aus Programm nehmen. Welches
Problem entsteht?
Karczewski
Datenbanken I
34
Einfüge-Anomalie
Töpferprodukt Markt
Prod-Nr
Produktart
Funktion
Verkaufsmarkt
11022
10622
20131
20131
20131
40030
40031
Tee-Service
Kaffee-Service
Schale
Schale
Schale
Krug
Krug
Gebrauch
Gebrauch
Deko
Deko
Deko
Deko
Deko
Internat. Tonmarkt
Internat. Tonmarkt
Rheinischer Tonmarkt
Odenwälder Töpferwelt
Internat. Tonmarkt
Internat. Tonmarkt
Odenwälder Töpferwelt
Marktstandort marktspez.Preis
Strasbourg
Strasbourg
Mainz
Erbach
Strasbourg
Strasbourg
Erbach
200 €
200 €
80 €
50 €
120 €
100 €
80 €
Produkt (33033, Schüssel, Gebrauch) soll neu aufgenommen werden.
Problem:
•
Teilschlüssel Verkaufsmarkt ist nicht füllbar
•
Zeile ist nur zum Teil gefüllt
Karczewski
Datenbanken I
35
Änderungs-Anomalie
Töpferprodukt Markt
Prod-Nr
Produktart
Funktion
Verkaufsmarkt
11022
10622
20131
20131
20131
40030
40031
Tee-Service
Kaffee-Service
Schale
Schale
Schale
Krug
Krug
Gebrauch
Gebrauch
Deko
Deko
Deko
Deko
Deko
Internat. Tonmarkt
Internat. Tonmarkt
Rheinischer Tonmarkt
Odenwälder Töpferwelt
Internat. Tonmarkt
Internat. Tonmarkt
Odenwälder Töpferwelt
Marktstandort marktspez.Preis
Strasbourg
Strasbourg
Mainz
Erbach
Strasbourg
Strasbourg
Erbach
200 €
200 €
80 €
50 €
120 €
100 €
80 €
Für Prod-Nr 20131 sei nicht mehr „Deko“ die Funktion, sondern “Gebrauch“.
Problem:
•
Obwohl sich nur ein Faktum ändert, muss an mehreren Stellen geändert werden.
•
Informationen sind redundant gespeichert.
Karczewski
Datenbanken I
36
Lösch-Anomalie
Töpferprodukt Markt
Prod-Nr
Produktart
Funktion
Verkaufsmarkt
11022
10622
20131
20131
20131
40030
40031
Tee-Service
Kaffee-Service
Schale
Schale
Schale
Krug
Krug
Gebrauch
Gebrauch
Deko
Deko
Deko
Deko
Deko
Internat. Tonmarkt
Internat. Tonmarkt
Rheinischer Tonmarkt
Odenwälder Töpferwelt
Internat. Tonmarkt
Internat. Tonmarkt
Odenwälder Töpferwelt
Marktstandort marktspez.Preis
Strasbourg
Strasbourg
Mainz
Erbach
Strasbourg
Strasbourg
Erbach
200 €
200 €
80 €
50 €
120 €
100 €
80 €
Produkt 20131 aus Programm nehmen.
Problem:
•
Obwohl nur ein Produkt gelöscht werden soll wird mit diesem ein Markt gelöscht.
•
Abhängigkeit des Marktes vom Produkt entspricht nicht der Realität
Karczewski
Datenbanken I
37
Ursache von Anomalien
• Redundante Datenhaltung:
Beispiel: Produkt 20131 ist mehrfach mit allen Attributen
abgespeichert.
• Ungünstige funktionale Abhängigkeiten:
Beispiel: Produktart hängt funktional nur von der Produkt-Nr ab
Karczewski
Datenbanken I
38
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 Element aus A gibt es genau ein b Element aus 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} Element aus A gibt es genau ein {b1, b2, … bn } aus 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.
Karczewski
Datenbanken I
39
Erste Normalform (1NF)
Eine Relationenschema ist in erster Normalform, wenn alle Attribute
des Schemas elementar sind.
Nur einfache Datentypen für Attributwerte sind erlaubt, wie z.B.
integer, real, string etc.
Listenartige, mengenwertige oder relationenartige Attribute sind
nicht erlaubt, wie z.B. record- oder array-Typen.
Karczewski
Datenbanken I
40
Verletzung der ersten Normalform
Lehrbücher
ISBN
Titel
Autoren
3-2304-0619-3
UML Distilled
3-8273-1282-5
3-8266-0619-1
Refactoring
Datenbanken
Fowler
Kendall
Fowler
Heuer
Saake
Nicht-atomare
Attributwerte sind
verboten !
Das Attribut Autoren erlaubt pro Lehrbuch mehr als einen Eintrag,
daher Verletzung der 1NF.
Karczewski
Datenbanken I
41
Auflösung zur 1NF
Lehrbücher
Autor_Buch
ISBN
Titel
ISBN
Autor
3-2304-0619-3
3-8273-1282-5
3-8266-0619-1
UML Distilled
Refactoring
Datenbanken
3-2304-0619-3
3-2304-0619-3
3-8273-1282-5
3-8266-0619-1
3-8266-0619-1
Fowler
Kendall
Fowler
Heuer
Saake
Eine neue Relation wird erzeugt, in der der Schlüssel der UrsprungsRelation und das nicht normalisierte Attribut aufgenommen wird.
Haben mehrere Autoren an einem Buch mitgeschrieben, so werden
für solche Bücher mehrere Zeilen in der neuen Relation nötig.
Karczewski
Datenbanken I
42
Aufgabe zur 1NF
Name
VL
Weber
30.4110, Pr.1, 4
30.4304, DB 1, 2
Karczewski
…
30.4304, DB 1, 2
Ist dieses Relationenschema in 1. Normalform?
Wie sieht das ER-Diagramm aus?
Wie sehen die Relationen aus?
Karczewski
Datenbanken I
43
Zweite Normalform (2NF)
Eine Relationenschema ist in zweiter Normalform, wenn
• es in erster Normalform ist und
• jedes Nichtschlüsselattribut voll funktional von jedem Schlüssel
abhängt (und nicht nur von einem Teilschlüssel).
Abhängigkeiten von einem Teil des Schlüssels (bei zusammengesetzten Schlüsseln) führt zur Anomalie.
Relationenschemata, die in 1NF sind und deren Schlüssel aus
einem Attribut bestehen, sind in 2NF.
Karczewski
Datenbanken I
44
Verletzung der 2NF
Töpferprodukt Markt
Prod-Nr
Produktart
Funktion
Verkaufsmarkt
11022
10622
20131
20131
20131
40030
40031
Tee-Service
Kaffee-Service
Schale
Schale
Schale
Krug
Krug
Gebrauch
Gebrauch
Deko
Deko
Deko
Deko
Deko
Internat. Tonmarkt
Internat. Tonmarkt
Rheinischer Tonmarkt
Odenwälder Töpferwelt
Internat. Tonmarkt
Internat. Tonmarkt
Odenwälder Töpferwelt
Marktstandort marktspez.Preis
Strasbourg
Strasbourg
Mainz
Erbach
Strasbourg
Strasbourg
Erbach
200 €
200 €
80 €
50 €
120 €
100 €
80 €
Welche Attribute sind von welchen funktional abhängig?
Welche Attribute sind von Schlüsselteilen funktional abhängig?
Wie sieht das ER-Diagramm aus?
Wie sehen die Relationen aus?
Können die obigen Anomalien nach der Normalisierung noch auftreten?
Karczewski
Datenbanken I
45
Auflösung zur 2NF
Töpferprodukt Markt
Prod-Nr
Produktart
Funktion
Verkaufsmarkt
11022
10622
20131
20131
20131
40030
40031
Tee-Service
Kaffee-Service
Schale
Schale
Schale
Krug
Krug
Gebrauch
Gebrauch
Deko
Deko
Deko
Deko
Deko
Internat. Tonmarkt
Internat. Tonmarkt
Rheinischer Tonmarkt
Odenwälder Töpferwelt
Internat. Tonmarkt
Internat. Tonmarkt
Odenwälder Töpferwelt
11022
10622
20131
40030
40031
Produktart
Tee-Service
Kaffee-Service
Schale
Krug
Krug
Strasbourg
Strasbourg
Mainz
Erbach
Strasbourg
Strasbourg
Erbach
200 €
200 €
80 €
50 €
120 €
100 €
80 €
Töpferprodukt Markt_2
Töpferprodukt
Prod-Nr
Marktstandort marktspez.Preis
Funktion
Prod-Nr
Verkauftsmarkt
marktspez.Preis
Gebrauch
Gebrauch
Deko
Deko
Deko
11022
10622
20131
20131
20131
40030
40030
Internat. Tonmarkt
Internat. Tonmarkt
Rheinischer Töpfermarkt
Odenwälder Töpferwelt
Internat. Tonmarkt
Internat. Tonmarkt
Odenwälder Töpferwelt
200 €
200 €
80 €
50 €
120 €
100 €
80 €
Töpfermarkt
Verkauftsmarkt
Karczewski
Marktstandort
Internat. Tonmarkt
Strasbourg
Rheinischer Töpfermarkt Mainz
Datenbanken IErbach
Odenwälder Töpferwelt
46
Auflösung zur 2NF
Funktionale Abhängigkeiten dürfen bei der Aufteilung in neue
Relationen nicht zerteilt werden.
Der ursprüngliche Schlüssel der Relation darf nicht getrennt werden,
d.h. für die zum ursprünglichen Schlüssel gehörenden Attribute
wird ggfs. ein eigenes Relationenschema eröffnet.
Wird dies nicht gemacht, spricht man von dem Verlust der
Verbundtreue.
Karczewski
Datenbanken I
47
Verbundtreue
Töpferprodukt Markt
Prod-Nr
Produktart
Funktion
Verkaufsmarkt
11022
10622
20131
20131
20131
40030
40031
Tee-Service
Kaffee-Service
Schale
Schale
Schale
Krug
Krug
Gebrauch
Gebrauch
Deko
Deko
Deko
Deko
Deko
Internat. Tonmarkt
Internat. Tonmarkt
Rheinischer Tonmarkt
Odenwälder Töpferwelt
Internat. Tonmarkt
Internat. Tonmarkt
Odenwälder Töpferwelt
11022
10622
20131
40030
40031
Produktart
Tee-Service
Kaffee-Service
Schale
Krug
Krug
Strasbourg
Strasbourg
Mainz
Erbach
Strasbourg
Strasbourg
Erbach
200 €
200 €
80 €
50 €
120 €
100 €
80 €
Töpferprodukt Markt_2
Töpferprodukt
Prod-Nr
Marktstandort marktspez.Preis
Funktion
Prod-Nr
Verkauftsmarkt
marktspez.Preis
Gebrauch
Gebrauch
Deko
Deko
Deko
11022
10622
20131
20131
20131
40030
40030
Internat. Tonmarkt
Internat. Tonmarkt
Rheinischer Töpfermarkt
Odenwälder Töpferwelt
Internat. Tonmarkt
Internat. Tonmarkt
Odenwälder Töpferwelt
200 €
200 €
80 €
50 €
120 €
100 €
80 €
Töpfermarkt
Verkauftsmarkt
Karczewski
Marktstandort
Internat. Tonmarkt
Strasbourg
Rheinischer Töpfermarkt Mainz
Datenbanken IErbach
Odenwälder Töpferwelt
?
48
Aufgabe 2NF
F_g_S:
F_Name
Digitaltechnik
Digitaltechnik
Fb_Name
Sem
Elektro_T
3
Informatik
2
F_Kurz
DT
DT
Ist dieses Relationenschema in 2. Normalform?
Wie sieht ein geeignetes ER-Diagramm aus?
Wie sehen die Relationen aus?
Karczewski
Datenbanken I
49
Dritte Normalform (3NF)
Eine Relationenschema ist in dritter Normalform,
• wenn es in zweiter Normalform ist und
• wenn kein Nichtschlüsselattribut transitiv von einem Schlüssel
abhängt.
Indirekte Abhängigkeiten vom Schlüssel über Nichtschlüsselattribute führen zu Anomalien.
C hängt von A transitiv ab, wenn man zwischen A und C
beispielsweise die Abhängigkeiten A -> B und B -> C identifiziert
hat.
Karczewski
Datenbanken I
50
Verletzung der 3NF
Töpferprodukt
Prod-Nr
11022
10622
20131
40030
40031
Produktart
Tee-Service
Kaffee-Service
Schale
Krug
Krug
Funktion
Gebrauch
Gebrauch
Deko
Deko
Deko
Welche Attribute sind von welchen funktional abhängig?
Wie sieht das ER-Diagramm aus?
Wie sehen die Relationen aus?
Können die obigen Anomalien nach der Normalisierung noch auftreten?
Karczewski
Datenbanken I
51
Auflösung der 3NF
Töpferprodukt
Prod-Nr
11022
10622
20131
40030
40031
Funktion
Tee-Service
Kaffee-Service
Schale
Krug
Krug
Gebrauch
Gebrauch
Deko
Deko
Deko
Töpferprodukt_2
Töpferprodukt Art
Prod-Nr
Produktart
Funktion
Tee-Service
Kaffee-Service
Schale
Krug
Gebrauch
Gebrauch
Deko
Deko
11022
10622
20131
40030
40031
Karczewski
Produktart
Produktart
Tee-Service
Kaffee-Service
Schale
Krug
Krug
Datenbanken I
52
Aufgabe 3NF
LTAOK:
LNR
4711
4712
4712
4713
TNR
T1
T1
T2
T1
Anzahl
55
44
33
22
Ort
KM-Entf.
Darmstadt
62
Darmstadt
62
Darmstadt
62
Frankfurt
42
Welche funktionalen Abhängigkeiten gibt es?
Ist dieses Relationenschema in 3. Normalform?
Wie sieht das ER-Diagramm aus?
Wie sehen die Relationen aus?
Karczewski
Datenbanken I
53
Gesamtlösung
Töpferprodukt Markt
Prod-Nr
Produktart
Funktion
Verkaufsmarkt
11022
10622
20131
20131
20131
40030
40031
Tee-Service
Kaffee-Service
Schale
Schale
Schale
Krug
Krug
Gebrauch
Gebrauch
Deko
Deko
Deko
Deko
Deko
Internat. Tonmarkt
Internat. Tonmarkt
Rheinischer Tonmarkt
Odenwälder Töpferwelt
Internat. Tonmarkt
Internat. Tonmarkt
Odenwälder Töpferwelt
Marktstandort marktspez.Preis
Strasbourg
Strasbourg
Mainz
Erbach
Strasbourg
Strasbourg
Erbach
Töpferprodukt_2
Töpferprodukt Markt_2
Prod-Nr
Prod-Nr
Verkaufsmarkt
11022
10622
20131
20131
20131
40030
40030
Internat. Tonmarkt
Internat. Tonmarkt
Rheinischer Töpfermarkt
Odenwälder Töpferwelt
Internat. Tonmarkt
Internat. Tonmarkt
Odenwälder Töpferwelt
11022
10622
20131
40030
40031
Produktart
Tee-Service
Kaffee-Service
Schale
Krug
Krug
200 €
200 €
80 €
50 €
120 €
100 €
80 €
marktspez.Preis
200 €
200 €
80 €
50 €
120 €
100 €
80 €
Töpferprodukt Art
Produktart
Funktion
Tee-Service
Kaffee-Service
Schale
Krug
Gebrauch
Gebrauch
Deko
Deko
Töpfermarkt
Verkaufsmarkt
Karczewski
Internat. Tonmarkt
Rheinischer Töpfermarkt
Odenwälder Töpferwelt
Datenbanken I
Marktstandort
Strasbourg
Mainz
Erbach
54
Normalisierung: Pro und Contra
•
Häufige Einwände gegen Normalisierung:
 „Erfordert mehr Speicherplatz !“
nicht korrekt
 „Umständlicher zu handhaben !“
nicht korrekt wenn View-Konzept
(Sichten) unterstützt
 „Reduziert Laufzeit-Performanz !“
korrekt
 Daher: In der Praxis meist 3NF üblich
 Bei zu hohem Performanz-Verlust: Denormalisieren!
 Empfehlung + Erfahrung:
bereits in konzeptionellem Entwurf (ERM) „normalisiert denken“
Karczewski
Datenbanken I
55
Aufgabe Normalformen
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.
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.
Karczewski
Datenbanken I
56