Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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

Ähnliche Präsentationen


Präsentation zum Thema: "KarczewskiDatenbanken I1 3. Relationales Modell entwickelt von Codd (1970) beruht auf dem mathematischen Begriff der Relation, den man anschaulich mit."—  Präsentation transkript:

1 KarczewskiDatenbanken I1 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

2 KarczewskiDatenbanken I2 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.

3 KarczewskiDatenbanken I3 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

4 KarczewskiDatenbanken I4 Markt:BezeichnungStandortKategorie Internationaler Töpfermarkt KrefeldTöpfer- markt Töpfermarkt Sommerhausen Sommer- hausen Töpfer- markt Internationaler Töpfermarkt HanauTöpfer- markt Beispielrelation Name des Relationenschemas Attribut (Spalte ) Relationenschema Tupel (Zeile) Relation (Tabelleninhalt)

5 KarczewskiDatenbanken I5 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)

6 KarczewskiDatenbanken I6 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

7 KarczewskiDatenbanken I7 Integritätsbedingungen Beispiel: 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 VeranstalterNameAdresseBezeichnungTyp Markt:BezeichnungStandortNameKategorie

8 KarczewskiDatenbanken I8 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.

9 KarczewskiDatenbanken I9 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)

10 KarczewskiDatenbanken I10 Entity-Typen (Beispiel) Markt BezeichnungStandortKategorie Bezeichnung Standort Kategorie Markt:

11 KarczewskiDatenbanken I11 Strukturierte Attribute (Beispiel) KundeNachname Adresse Strasse Stadt PLZ Kd-Nummer Vornamen Kunde: Adresse Vornamen Kd-Nummer Nachname Strasse PLZ Stadt Vorname_1 Vorname_2... Vorname_n Vornamen Keine Lösung, da strukturierte Attribute in der Relation nicht erlaubt!

12 KarczewskiDatenbanken I12 KundeNachname 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)

13 KarczewskiDatenbanken I13 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

14 KarczewskiDatenbanken I14 m:n-Beziehung (Beispiel) ProduktMarkt 6 Produkt (Nummer, Bezeichnung, Funktion) Markt (Bezeichnung, Standort, Kategorie) 6: wird angeboten auf (Anzahl) (0,*) eERM-Darstellung mit dem Power-Designer von Sybase: Konzeptioneller Datenentwurf

15 KarczewskiDatenbanken I15 steht für * ;steht für 0 ; 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.)

16 KarczewskiDatenbanken I16 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:NummerBezeichnungFunktion WirdAngebotenAuf:NummerBezeichnungStandortAnzahl Markt:BezeichnungStandortKategorie Logischer Datenentwurf m:n-Beziehung (Beispiel, Forts.)

17 KarczewskiDatenbanken I17 Setzen Sie das folgende ERM in Relationen um. Wie sehen die Krähenfußdiagramme aus? Wie sehen die Relationenschemata aus? ProduktKunde 7 (0,*) Produkt (Produktnummer, Bezeichnung, Preis) Kunde (Nummer, Name) 7: erhält geliefert (Anzahl, Lieferdatum) Aufgabe

18 KarczewskiDatenbanken I18 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.

19 KarczewskiDatenbanken I19 m:1-Beziehung (Beispiel) MarktVeranstalter 8 (1,1) (0,*) Markt (Bezeichnung, Standort, Kategorie) Veranstalter (Name, Adresse, Bezeichnung, Typ) 8: Ansprechpartner ERD-Darstellung mit Power-Designer:

20 KarczewskiDatenbanken I20 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: VeranstalterNameAdresseBezeichnungTyp Markt:BezeichnungStandortNameKategorie

21 KarczewskiDatenbanken I21 Setzen Sie das folgende ERM in Relationen um. Produkt Dekor 5 (0,1) (0,*) Produkt (Produktnummer, Bezeichnung, Größe, Preis) Dekor (Bezeichnung, Foto) 5: ist versehen mit Aufgabe

22 KarczewskiDatenbanken I22 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

23 KarczewskiDatenbanken I23 Produkt 4 (0,*) Produktgruppe Teilprodukt Rollen 4: besteht aus Rekursive Beziehung (Beispiel)

24 KarczewskiDatenbanken I24 Realisierung erfolgt analog zu einer zweistelligen Beziehung Produkt:NummerBezeichnungFunktion Besteht_aus:NummerONummerUAnzahl a.graphische Darstellung in Krähenfußdarstellung: b.b. graphische Darstellung als Bachmanndiagramm: c.c. Tabellendarstellung: Rekursive Beziehung (Beispiel)

25 KarczewskiDatenbanken I25 Fach 4 (0,*) 4: ist vorausgesetzt Aufgabe Setzen Sie das folgende ERM in Relationen um.

26 KarczewskiDatenbanken I26 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,*) Händler Spediteur Aufgabe: Setzen Sie das folgende ERM in Relationen um. 1: liefert (Bestelldatum, Menge) Mehrstellige Beziehung

27 KarczewskiDatenbanken I27 HändlerNameAdresseFirmenbezeichnung Rohstoff:BezeichnungArt Liefert:HNameSNameBezeichnungBestelldatumMenge SpediteurNameAdresseFirmenbezeichnung Mehrstellige Beziehung (Lösung)

28 KarczewskiDatenbanken I28 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.

29 KarczewskiDatenbanken I29 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

30 KarczewskiDatenbanken I30 Geschäftspartner VeranstalterKunde O Beispiel: Veranstalter:Geschaeftspartner-NrBezeichnungTyp Geschäftspartner:Geschaeftspartner-NrAdresseTelefonnummer Umsetzung Variante 1: Für alle Spezialisten und den Generalisten werden Relationenschemata erstellt: Kunde:Geschaeftspartner-NrName Generalisierung/Spezialisierun g (Beispiel) Generalist: Geschäftspartner (Geschäftspartner-Nr, Adresse, Telefonnummer) Spezialisten: Veranstalter (Bezeichnung, Typ) Kunde (Name)

31 KarczewskiDatenbanken I31 Geschäftspartner VeranstalterKunde O Beispiel: Veranstalter:Geschaeftspartner-NrAdresseTelefonnummerBezeichnungTyp Kunde:Geschäftspartner-NrAdresseTelefonnummerName Generalisierung/Spezialisierun g (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

32 KarczewskiDatenbanken I32 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

33 KarczewskiDatenbanken I33 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

34 KarczewskiDatenbanken I34 Anomalien Änderungs-Anomalie:Für Prod-Nr sei nicht mehr Deko die Funktion (= Update-Anomalie)sondern Gebrauch. Welches Problem entsteht? Lösch-Anomalie:Produkt 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 Tee-Service Gebrauch Internat. Tonmarkt Strasbourg Kaffee-Service Gebrauch Internat. Tonmarkt Strasbourg Schale Deko Rheinischer Tonmarkt Mainz Schale Deko Odenwälder Töpferwelt Erbach Schale Deko Internat. Tonmarkt Strasbourg Krug Deko Internat. Tonmarkt Strasbourg Krug Deko Odenwälder Töpferwelt Erbach 80

35 KarczewskiDatenbanken I35 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 Töpferprodukt Markt Prod-Nr Produktart Funktion Verkaufsmarkt Marktstandort marktspez.Preis Tee-Service Gebrauch Internat. Tonmarkt Strasbourg Kaffee-Service Gebrauch Internat. Tonmarkt Strasbourg Schale Deko Rheinischer Tonmarkt Mainz Schale Deko Odenwälder Töpferwelt Erbach Schale Deko Internat. Tonmarkt Strasbourg Krug Deko Internat. Tonmarkt Strasbourg Krug Deko Odenwälder Töpferwelt Erbach 80

36 KarczewskiDatenbanken I36 Änderungs-Anomalie Töpferprodukt Markt Prod-Nr Produktart Funktion Verkaufsmarkt Marktstandort marktspez.Preis Tee-Service Gebrauch Internat. Tonmarkt Strasbourg Kaffee-Service Gebrauch Internat. Tonmarkt Strasbourg Schale Deko Rheinischer Tonmarkt Mainz Schale Deko Odenwälder Töpferwelt Erbach Schale Deko Internat. Tonmarkt Strasbourg Krug Deko Internat. Tonmarkt Strasbourg Krug Deko Odenwälder Töpferwelt Erbach 80 Für Prod-Nr 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.

37 KarczewskiDatenbanken I37 Töpferprodukt Markt Prod-Nr Produktart Funktion Verkaufsmarkt Marktstandort marktspez.Preis Tee-Service Gebrauch Internat. Tonmarkt Strasbourg Kaffee-Service Gebrauch Internat. Tonmarkt Strasbourg Schale Deko Rheinischer Tonmarkt Mainz Schale Deko Odenwälder Töpferwelt Erbach Schale Deko Internat. Tonmarkt Strasbourg Krug Deko Internat. Tonmarkt Strasbourg Krug Deko Odenwälder Töpferwelt Erbach 80 Lösch-Anomalie Produkt 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

38 KarczewskiDatenbanken I38 Ursache von Anomalien Redundante Datenhaltung: Beispiel: Produkt ist mehrfach mit allen Attributen abgespeichert. Ungünstige funktionale Abhängigkeiten: Beispiel: Produktart hängt funktional nur von der Produkt-Nr ab

39 KarczewskiDatenbanken I39 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.

40 KarczewskiDatenbanken I40 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.

41 KarczewskiDatenbanken I41 Lehrbücher ISBN Titel Autoren UML DistilledFowler Kendall Refactoring Fowler DatenbankenHeuer Saake Verletzung der ersten Normalform Nicht-atomare Attributwerte sind verboten ! Das Attribut Autoren erlaubt pro Lehrbuch mehr als einen Eintrag, daher Verletzung der 1NF.

42 KarczewskiDatenbanken I42 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 werden für solche Bücher mehrere Zeilen in der neuen Relation nötig. Lehrbücher ISBN Titel UML Distilled Refactoring Datenbanken Autor_Buch ISBN Autor Fowler Kendall Fowler Heuer Saake

43 KarczewskiDatenbanken I43 Name VL Weber , Pr.1, , DB 1, 2 Karczewski , DB 1, 2 … Aufgabe zur 1NF Ist dieses Relationenschema in 1. Normalform? Wie sieht das ER-Diagramm aus? Wie sehen die Relationen aus?

44 KarczewskiDatenbanken I44 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.

45 KarczewskiDatenbanken I45 Töpferprodukt Markt Prod-Nr Produktart Funktion Verkaufsmarkt Marktstandort marktspez.Preis Tee-Service Gebrauch Internat. Tonmarkt Strasbourg Kaffee-Service Gebrauch Internat. Tonmarkt Strasbourg Schale Deko Rheinischer Tonmarkt Mainz Schale Deko Odenwälder Töpferwelt Erbach Schale Deko Internat. Tonmarkt Strasbourg Krug Deko Internat. Tonmarkt Strasbourg Krug Deko Odenwälder Töpferwelt Erbach 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? Verletzung der 2NF

46 KarczewskiDatenbanken I46 Töpferprodukt Markt Prod-Nr Produktart Funktion Verkaufsmarkt Marktstandort marktspez.Preis Tee-Service Gebrauch Internat. Tonmarkt Strasbourg Kaffee-Service Gebrauch Internat. Tonmarkt Strasbourg Schale Deko Rheinischer Tonmarkt Mainz Schale Deko Odenwälder Töpferwelt Erbach Schale Deko Internat. Tonmarkt Strasbourg Krug Deko Internat. Tonmarkt Strasbourg Krug Deko Odenwälder Töpferwelt Erbach 80 Töpferprodukt Prod-Nr Produktart Funktion Tee-Service Gebrauch Kaffee-Service Gebrauch Schale Deko Krug Deko Krug Deko Töpferprodukt Markt_2 Prod-Nr Verkauftsmarkt marktspez.Preis Internat. Tonmarkt Internat. Tonmarkt Rheinischer Töpfermarkt Odenwälder Töpferwelt Internat. Tonmarkt Internat. Tonmarkt Odenwälder Töpferwelt 80 Töpfermarkt Verkauftsmarkt Marktstandort Internat. Tonmarkt Strasbourg Rheinischer Töpfermarkt Mainz Odenwälder Töpferwelt Erbach Auflösung zur 2NF

47 KarczewskiDatenbanken I47 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.

48 KarczewskiDatenbanken I48 Verbundtreue Töpferprodukt Markt Prod-Nr Produktart Funktion Verkaufsmarkt Marktstandort marktspez.Preis Tee-Service Gebrauch Internat. Tonmarkt Strasbourg Kaffee-Service Gebrauch Internat. Tonmarkt Strasbourg Schale Deko Rheinischer Tonmarkt Mainz Schale Deko Odenwälder Töpferwelt Erbach Schale Deko Internat. Tonmarkt Strasbourg Krug Deko Internat. Tonmarkt Strasbourg Krug Deko Odenwälder Töpferwelt Erbach 80 Töpferprodukt Prod-Nr Produktart Funktion Tee-Service Gebrauch Kaffee-Service Gebrauch Schale Deko Krug Deko Krug Deko Töpferprodukt Markt_2 Prod-Nr Verkauftsmarkt marktspez.Preis Internat. Tonmarkt Internat. Tonmarkt Rheinischer Töpfermarkt Odenwälder Töpferwelt Internat. Tonmarkt Internat. Tonmarkt Odenwälder Töpferwelt 80 Töpfermarkt Verkauftsmarkt Marktstandort Internat. Tonmarkt Strasbourg Rheinischer Töpfermarkt Mainz Odenwälder Töpferwelt Erbach ?

49 KarczewskiDatenbanken I49 Aufgabe 2NF F_g_S: F_Name Fb_Name Sem F_Kurz Digitaltechnik Elektro_T 3 DT Digitaltechnik Informatik 2 DT Ist dieses Relationenschema in 2. Normalform? Wie sieht ein geeignetes ER-Diagramm aus? Wie sehen die Relationen aus?

50 KarczewskiDatenbanken I50 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)

51 KarczewskiDatenbanken I51 Töpferprodukt Prod-Nr Produktart Funktion Tee-Service Gebrauch Kaffee-Service Gebrauch Schale Deko Krug Deko Krug 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? Verletzung der 3NF

52 KarczewskiDatenbanken I52 Töpferprodukt_2 Prod-Nr Produktart Tee-Service Kaffee-Service Schale Krug Krug Töpferprodukt Art Produktart Funktion Tee-Service Gebrauch Kaffee-Service Gebrauch Schale Deko Krug Deko Töpferprodukt Prod-Nr Produktart Funktion Tee-Service Gebrauch Kaffee-Service Gebrauch Schale Deko Krug Deko Krug Deko Auflösung der 3NF

53 KarczewskiDatenbanken I53 Welche funktionalen Abhängigkeiten gibt es? Ist dieses Relationenschema in 3. Normalform? Wie sieht das ER-Diagramm aus? Wie sehen die Relationen aus? LTAOK: LNR TNR Anzahl Ort KM-Entf T1 55 Darmstadt T1 44 Darmstadt T2 33 Darmstadt T1 22 Frankfurt 42 Aufgabe 3NF

54 KarczewskiDatenbanken I54 Gesamtlösung Töpferprodukt Markt_2 Prod-Nr Verkaufsmarkt marktspez.Preis Internat. Tonmarkt Internat. Tonmarkt Rheinischer Töpfermarkt Odenwälder Töpferwelt Internat. Tonmarkt Internat. Tonmarkt Odenwälder Töpferwelt 80 Töpfermarkt Verkaufsmarkt Marktstandort Internat. Tonmarkt Strasbourg Rheinischer Töpfermarkt Mainz Odenwälder Töpferwelt Erbach Töpferprodukt_2 Prod-Nr Produktart Tee-Service Kaffee-Service Schale Krug Krug Töpferprodukt Art Produktart Funktion Tee-Service Gebrauch Kaffee-Service Gebrauch Schale Deko Krug Deko Töpferprodukt Markt Prod-Nr Produktart Funktion Verkaufsmarkt Marktstandort marktspez.Preis Tee-Service Gebrauch Internat. Tonmarkt Strasbourg Kaffee-Service Gebrauch Internat. Tonmarkt Strasbourg Schale Deko Rheinischer Tonmarkt Mainz Schale Deko Odenwälder Töpferwelt Erbach Schale Deko Internat. Tonmarkt Strasbourg Krug Deko Internat. Tonmarkt Strasbourg Krug Deko Odenwälder Töpferwelt Erbach 80

55 KarczewskiDatenbanken I55 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

56 KarczewskiDatenbanken I56 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


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

Ähnliche Präsentationen


Google-Anzeigen