KarczewskiDatenbanken I1 3. Relationales Modell entwickelt von Codd (1970) beruht auf dem mathematischen Begriff der Relation, den man anschaulich mit

Karczewski Datenbanken I 1

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


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.


• 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.

Grundlagen


Markt: Bezeichnung Standort Kategorie

Internationaler Töpfermarkt

Krefeld Töpfer-markt

Töpfermarkt Sommerhausen

Sommer-hausen

Töpfer-markt

Internationaler Töpfermarkt

Hanau Töpfer-markt

Beispielrelation

Name des Relationenschemas Attribut (Spalte)

Relationenschema

Tupel (Zeile)

Relation (Tabelleninhalt)


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 OO- Sprachen• Objektrelationale Datenbanksysteme (kommend von relationalen Datenbanksystemen)


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.

Integritätsbedingungen


Integritätsbedingungen

Beispiel:

Name des Veranstalters ist Primärschlüssel in Veranstalter und Fremdschlüssel in Markt.

Notation:Schlüssel: Unterstreichung der Bezeichnung des AttributsFremdschlüssel: Strich über Bezeichnung

Veranstalter Name Adresse Bezeichnung Typ

Markt: Bezeichnung Standort Name Kategorie


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.


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)


Entity-Typen (Beispiel)

Markt

Bezeichnung Standort Kategorie

Bezeichnung Standort KategorieMarkt:


Strukturierte Attribute (Beispiel)

Kunde Nachname

Adresse

Strasse

Stadt

PLZ

Kd-Nummer

Vornamen

Kunde:

Adresse VornamenKd-Nummer Nachname Strasse PLZ Stadt Vorname_1 Vorname_2 . . . Vorname_n

Vornamen

Keine Lösung, da strukturierte Attribute in der Relation nicht erlaubt!


Kunde Nachname

Adresse

Strasse

Stadt

PLZ

Kd-Nummer

Vornamen

Kunde: Kd-Nummer Nachname Strasse PLZ Stadt

Vorname: Kd-Nummer Vorname

Vornamen

• Auflösen (“Flachdrücken“) des strukturierten Attributs Adresse

• Auslagern der beliebig vielen Vornamen in eine eigene Relation

Strukturierte Attribute (Beispiel)


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


m:n-Beziehung (Beispiel)

Produkt Markt6

Produkt (Nummer, Bezeichnung, Funktion)

Markt (Bezeichnung, Standort, Kategorie)

6: wird angeboten auf (Anzahl)

(0,*) (0,*)

eERM-Darstellung mit dem Power-Designer von Sybase:

<pi>

Konzeptioneller Datenentwurf


<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):

steht für die Kardinalität (1,1)

Die Symbole am Kasten WirdAngebotenAuf bedeuten: (o,*), aus Beziehungstyp entstanden

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:

b) Tabellendarstellung:Produkt: Nummer Bezeichnung Funktion

WirdAngebotenAuf:

Nummer

Bezeichnung

Standort

Anzahl

Markt: Bezeichnung

Standort Kategorie

Logischer Datenentwurf

m:n-Beziehung (Beispiel, Forts.)


Setzen Sie das folgende ERM in Relationen um.

Wie sehen die Krähenfußdiagramme aus?

Wie sehen die Relationenschemata aus?

Produkt Kunde7(0,*) (0,*)

Produkt (Produktnummer, Bezeichnung, Preis)Kunde (Nummer, Name)7: erhält geliefert (Anzahl, Lieferdatum)

Aufgabe


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.


m:1-Beziehung (Beispiel)

Markt Veranstalter8(1,1) (0,*)

Markt (Bezeichnung, Standort, Kategorie)

Veranstalter (Name, Adresse, Bezeichnung, Typ)

8: Ansprechpartner

ERD-Darstellung mit Power-Designer:

<pi>


m:1-Beziehung (Beispiel)

• nur 2 Tabellen entstehen

• Hinzufügen des Fremdschlüssels (Veranstalter-)Name in Markt

a) Design-Sicht des Power-Designers:

b) Tabellendarstellung:

Veranstalter Name Adresse Bezeichnung Typ

Markt: Bezeichnung Standort Name Kategorie

<pk>



Produkt Dekor5(0,1) (0,*)

Produkt (Produktnummer, Bezeichnung, Größe, Preis)Dekor (Bezeichnung, Foto)5: ist versehen mit

Aufgabe


• 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 nicht-gefüllte Tupel vorkommen.

1:1-Beziehung


Produkt

4

(0,*)(0,*) Produktgruppe

Teilprodukt

Rollen

4: besteht aus

Rekursive Beziehung (Beispiel)


Realisierung erfolgt analog zu einer zweistelligen Beziehung

Produkt: Nummer Bezeichnung Funktion

Besteht_aus: NummerO NummerU Anzahl

a. graphische Darstellung in Krähenfußdarstellung:

b. b. graphische Darstellung als Bachmanndiagramm:

c. c. Tabellendarstellung:

Rekursive Beziehung (Beispiel)


Fach

4

(0,*)(0,*)

4: ist vorausgesetzt

Aufgabe



• 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.

Rohstoff

1

(1,*) (1,*)

(1,*)

Händler SpediteurAufgabe: Setzen Sie das folgende ERM in Relationen um.

1: liefert (Bestelldatum, Menge)

Mehrstellige Beziehung


Händler Name Adresse Firmenbezeichnung

Rohstoff: Bezeichnung Art

Liefert: HName SName Bezeichnung Bestelldatum Menge

Spediteur Name Adresse Firmenbezeichnung

Mehrstellige Beziehung (Lösung)


Generalisierung/SpezialisierungEs 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.


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.

Generalisierung/Spezialisierung


Geschäftspartner

Veranstalter Kunde

O

Beispiel:

Veranstalter: Geschaeftspartner-Nr Bezeichnung Typ

Geschäftspartner: Geschaeftspartner-Nr Adresse Telefonnummer

Umsetzung

Variante 1: Für alle Spezialisten und den Generalisten werden Relationenschemata erstellt:

Kunde: Geschaeftspartner-Nr Name

Generalisierung/Spezialisierung(Beispiel)

Generalist: Geschäftspartner (Geschäftspartner-Nr, Adresse, Telefonnummer)Spezialisten: Veranstalter (Bezeichnung, Typ) Kunde (Name)


Geschäftspartner

Veranstalter Kunde

O

Beispiel:

Veranstalter: Geschaeftspartner-Nr Adresse Telefonnummer Bezeichnung Typ

Kunde: Geschäftspartner-Nr Adresse Telefonnummer Name

Generalisierung/Spezialisierung(Beispiel)

Generalist: Geschäftspartner (Geschäftspartner-Nr, Adresse, Telefonnummer)Spezialisten: Veranstalter (Bezeichnung, Typ) Kunde (Name)

Umsetzung

Variante 2: Nur für die Spezialisten werden Relationenschemata erstellt:

Bei overlapping redundante Speicherung


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)

Aufgabe


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ösch-Anomalie


Anomalien

Änderungs-Anomalie: Für Prod-Nr 20131 sei nicht mehr „Deko“ die Funktion(= Update-Anomalie) sondern “Gebrauch“. Welches Problem entsteht?

Lösch-Anomalie: Produkt 20131 ganz aus Programm nehmen. Welches(Delete-Anomalie) Problem entsteht?

Einfüge-Anomalie: Neues Tonprodukt einführen, aber noch nicht auf den(= Insert-Anomalie) Markt bringen. Welches Problem entsteht?

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öpferwelt Erbach 50 €20131 Schale Deko Internat. Tonmarkt Strasbourg 120 €40030 Krug Deko Internat. Tonmarkt Strasbourg 100 €40031 Krug Deko Odenwälder Töpferwelt Erbach 80 €


Einfüge-Anomalie

Produkt (33033, Schüssel, Gebrauch) soll neu aufgenommen werden.

Problem:

• Teilschlüssel Verkaufsmarkt ist nicht füllbar

• Zeile ist nur zum Teil gefüllt





Änderungs-Anomalie




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.





Lösch-Anomalie

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


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


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.


Erste Normalform (1NF)

Eine Relationenschema ist in erster Normalform, wenn alle Attributedes Schemas elementar sind.

Nur einfache Datentypen für Attributwerte sind erlaubt, wie z.B. integer, real, string etc.

Listenartige, mengenwertige oder relationenartige Attribute sindnicht erlaubt, wie z.B. record- oder array-Typen.


Lehrbücher

ISBN Titel Autoren

3-2304-0619-3 UML Distilled FowlerKendall

3-8273-1282-5 Refactoring Fowler3-8266-0619-1 Datenbanken Heuer

Saake

Verletzung der ersten Normalform

Nicht-atomareAttributwerte sind

verboten !

Das Attribut Autoren erlaubt pro Lehrbuch mehr als einen Eintrag,daher Verletzung der 1NF.


Auflösung zur 1NF

Eine neue Relation wird erzeugt, in der der Schlüssel der Ursprungs-Relation und das nicht normalisierte Attribut aufgenommen wird.

Haben mehrere Autoren an einem Buch mitgeschrieben, so werdenfür solche Bücher mehrere Zeilen in der neuen Relation nötig.

Lehrbücher

ISBN Titel

3-2304-0619-3 UML Distilled

3-8273-1282-5 Refactoring 3-8266-0619-1 Datenbanken

Autor_Buch

ISBN Autor

3-2304-0619-3 Fowler3-2304-0619-3 Kendall3-8273-1282-5 Fowler3-8266-0619-1 Heuer3-8266-0619-1 Saake


Name VL

Weber 30.4110, Pr.1, 430.4304, DB 1, 2

Karczewski 30.4304, DB 1, 2…

Aufgabe zur 1NF

Ist dieses Relationenschema in 1. Normalform?

Wie sieht das ER-Diagramm aus?

Wie sehen die Relationen aus?


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 zusammen-gesetzten Schlüsseln) führt zur Anomalie.

Relationenschemata, die in 1NF sind und deren Schlüssel aus einem Attribut bestehen, sind in 2NF.





Welche Attribute sind von welchen funktional abhängig?

Welche Attribute sind von Schlüsselteilen funktional abhängig?



Können die obigen Anomalien nach der Normalisierung noch auftreten?

Verletzung der 2NF





Töpferprodukt

Prod-Nr Produktart Funktion

11022 Tee-Service Gebrauch10622 Kaffee-Service Gebrauch20131 Schale Deko40030 Krug Deko40031 Krug Deko

Töpferprodukt Markt_2

Prod-Nr Verkauftsmarkt marktspez.Preis

11022 Internat. Tonmarkt 200 € 10622 Internat. Tonmarkt 200 € 20131 Rheinischer Töpfermarkt 80 € 20131 Odenwälder Töpferwelt 50 € 20131 Internat. Tonmarkt 120 € 40030 Internat. Tonmarkt 100 € 40030 Odenwälder Töpferwelt 80 €

Töpfermarkt

Verkauftsmarkt Marktstandort

Internat. Tonmarkt StrasbourgRheinischer Töpfermarkt MainzOdenwälder Töpferwelt Erbach

Auflösung zur 2NF


Auflösung zur 2NF

Funktionale Abhängigkeiten dürfen bei der Aufteilung in neueRelationen 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 Attributewird ggfs. ein eigenes Relationenschema eröffnet.Wird dies nicht gemacht, spricht man von dem Verlust der Verbundtreue.


VerbundtreueTöpferprodukt Markt



Töpferprodukt




Prod-Nr Verkauftsmarkt marktspez.Preis


Töpfermarkt

Verkauftsmarkt Marktstandort


?


Aufgabe 2NF

F_g_S: F_Name Fb_Name Sem F_Kurz Digitaltechnik Elektro_T 3 DT

Digitaltechnik Informatik 2 DT


Wie sieht ein geeignetes ER-Diagramm aus?



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üssel-attribute 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.

Dritte Normalform (3NF)


Töpferprodukt



Welche Attribute sind von welchen funktional abhängig?



Können die obigen Anomalien nach der Normalisierung noch auftreten?

Verletzung der 3NF


Töpferprodukt_2

Prod-Nr Produktart

11022 Tee-Service10622 Kaffee-Service20131 Schale40030 Krug40031 Krug

Töpferprodukt Art Produktart Funktion

Tee-Service GebrauchKaffee-Service GebrauchSchale DekoKrug Deko

Töpferprodukt



Auflösung der 3NF


Welche funktionalen Abhängigkeiten gibt es?




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

Aufgabe 3NF


Gesamtlösung


Prod-Nr Verkaufsmarkt marktspez.Preis


Töpfermarkt

Verkaufsmarkt Marktstandort


Töpferprodukt_2

Prod-Nr Produktart

11022 Tee-Service10622 Kaffee-Service20131 Schale40030 Krug40031 Krug

Töpferprodukt Art Produktart Funktion

Tee-Service GebrauchKaffee-Service GebrauchSchale DekoKrug Deko





Normalisierung: Pro und Contra

• Häufige Einwände gegen Normalisierung:

„Erfordert mehr Speicherplatz !“

„Umständlicher zu handhaben !“

„Reduziert Laufzeit-Performanz !“

Daher: In der Praxis meist 3NF üblich

Bei zu hohem Performanz-Verlust: Denormalisieren!

nicht korrekt

nicht korrekt wenn View-Konzept(Sichten) unterstützt

Empfehlung + Erfahrung: bereits in konzeptionellem Entwurf (ERM) „normalisiert denken“

korrekt


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.

Aufgabe Normalformen

Documents

KarczewskiDatenbanken I1 3. Relationales Modell entwickelt von Codd (1970) beruht auf dem mathematischen Begriff der Relation, den man anschaulich mit