1 / 56

3. Relationales Modell

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.

hateya
Download Presentation

3. Relationales Modell

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 Datenbanken I

  2. 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. Datenbanken I

  3. 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. Datenbanken I

  4. Beispielrelation Attribut (Spalte) Name des Relationenschemas Relationenschema Relation (Tabelleninhalt) Tupel (Zeile) Datenbanken I

  5. 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) Datenbanken I

  6. 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. Datenbanken I

  7. 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 Datenbanken I

  8. 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. Datenbanken I

  9. 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) Datenbanken I

  10. Entity-Typen (Beispiel) Markt Bezeichnung Standort Kategorie Markt: BezeichnungStandort Kategorie Datenbanken I

  11. Strukturierte Attribute (Beispiel) Vornamen 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! Datenbanken I

  12. Strukturierte Attribute (Beispiel) Vornamen Vornamen • Auflösen (“Flachdrücken“) des strukturierten Attributs Adresse • Auslagern der beliebig vielen Vornamen in eine eigene Relation Kunde Nachname Kd-Nummer Strasse Adresse Stadt PLZ Kunde: Kd-Nummer Nachname Strasse PLZ Stadt Vorname: Kd-NummerVorname Datenbanken I

  13. 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 Datenbanken I

  14. m:n-Beziehung (Beispiel) (0,*) (0,*) Produkt 6 Markt Produkt (Nummer, Bezeichnung, Funktion) Markt (Bezeichnung, Standort, Kategorie) 6: wird angeboten auf (Anzahl) Konzeptioneller Datenentwurf eERM-Darstellung mit dem Power-Designer von Sybase: <pi> Datenbanken I

  15. 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) Datenbanken I

  16. 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: m:n-Beziehung (Beispiel, Forts.) Logischer Datenentwurf Datenbanken I

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

  18. 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. Datenbanken I

  19. m:1-Beziehung (Beispiel) (1,1) (0,*) Markt 8 Veranstalter Markt (Bezeichnung, Standort, Kategorie) Veranstalter (Name, Adresse, Bezeichnung, Typ) 8: Ansprechpartner ERD-Darstellung mit Power-Designer: <pi> Datenbanken I

  20. 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: <pk> Datenbanken I

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

  22. 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 nicht-gefüllte Tupel vorkommen. Datenbanken I

  23. Rekursive Beziehung (Beispiel) Rollen Teilprodukt Produkt (0,*) (0,*) Produktgruppe 4 4: besteht aus Datenbanken I

  24. Realisierung erfolgt analog zu einer zweistelligen Beziehung Rekursive Beziehung (Beispiel) • graphische Darstellung in Krähenfußdarstellung: • b. graphische Darstellung als Bachmanndiagramm: • c. Tabellendarstellung: Datenbanken I

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

  26. 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. Händler Spediteur (1,*) (1,*) 1 (1,*) Rohstoff • 1: liefert (Bestelldatum, Menge) Datenbanken I

  27. Mehrstellige Beziehung (Lösung) Datenbanken I

  28. Generalisierung/Spezialisierung Es gibt zwei Varianten der Realisierung: • 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. Datenbanken I

  29. Generalisierung/Spezialisierung • 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. Datenbanken I

  30. Generalisierung/Spezialisierung (Beispiel) Geschäftspartner Generalist: Geschäftspartner (Geschäftspartner-Nr, Adresse, Telefonnummer) Spezialisten: Veranstalter (Bezeichnung, Typ) Kunde (Name) Beispiel: O Veranstalter Kunde Umsetzung Variante 1: Für alle Spezialisten und den Generalisten werden Relationenschemata erstellt: Datenbanken I

  31. Generalisierung/Spezialisierung (Beispiel) Geschäftspartner Generalist: Geschäftspartner (Geschäftspartner-Nr, Adresse, Telefonnummer) Spezialisten: Veranstalter (Bezeichnung, Typ) Kunde (Name) Beispiel: O Veranstalter Kunde Umsetzung Variante 2: Nur für die Spezialisten werden Relationenschemata erstellt: Bei overlapping redundante Speicherung Datenbanken I

  32. 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) Datenbanken I

  33. 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 Datenbanken I

  34. 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 € Anomalien Einfüge-Anomalie: Neues Tonprodukt einführen, aber noch nicht auf den(= Insert-Anomalie) Markt bringen. Welches Problem entsteht? Ä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? Datenbanken I

  35. Einfüge-Anomalie 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 € • Produkt (33033, Schüssel, Gebrauch) soll neu aufgenommen werden. • Problem: • Teilschlüssel Verkaufsmarkt ist nicht füllbar • Zeile ist nur zum Teil gefüllt Datenbanken I

  36. Änderungs-Anomalie 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 € • 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. Datenbanken I

  37. Lösch-Anomalie 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 € • 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 Datenbanken I

  38. 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 Datenbanken I

  39. 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. Datenbanken I

  40. 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. Datenbanken I

  41. Lehrbücher ISBN Titel Autoren 3-2304-0619-3 UML Distilled Fowler Kendall 3-8273-1282-5 Refactoring Fowler 3-8266-0619-1 Datenbanken Heuer Saake Nicht-atomareAttributwerte sindverboten ! Verletzung der ersten Normalform Das Attribut Autoren erlaubt pro Lehrbuch mehr als einen Eintrag, daher Verletzung der 1NF. Datenbanken I

  42. Auflösung zur 1NF Autor_Buch ISBNAutor 3-2304-0619-3 Fowler 3-2304-0619-3 Kendall 3-8273-1282-5 Fowler 3-8266-0619-1 Heuer 3-8266-0619-1 Saake Lehrbücher ISBN Titel 3-2304-0619-3 UML Distilled 3-8273-1282-5 Refactoring 3-8266-0619-1 Datenbanken 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. Datenbanken I

  43. Name VL Weber 30.4110, Pr.1, 4 30.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? Datenbanken I

  44. 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. Datenbanken I

  45. Verletzung der 2NF 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 € 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? Datenbanken I

  46. Töpferprodukt Prod-Nr Produktart Funktion 11022 Tee-Service Gebrauch 10622 Kaffee-Service Gebrauch 20131 Schale Deko 40030 Krug Deko 40031 Krug Deko Töpferprodukt Markt_2 Prod-NrVerkauftsmarkt 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 Strasbourg Rheinischer Töpfermarkt Mainz Odenwälder Töpferwelt Erbach Auflösung zur 2NF 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 € Datenbanken I

  47. 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. Datenbanken I

  48. Töpferprodukt Prod-Nr Produktart Funktion 11022 Tee-Service Gebrauch 10622 Kaffee-Service Gebrauch 20131 Schale Deko 40030 Krug Deko 40031 Krug Deko Töpferprodukt Markt_2 Prod-NrVerkauftsmarkt 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 Strasbourg Rheinischer Töpfermarkt Mainz Odenwälder Töpferwelt Erbach Verbundtreue 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 € ? Datenbanken I

  49. Aufgabe 2NF F_g_S: F_NameFb_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? Datenbanken I

  50. Dritte Normalform (3NF) • Eine Relationenschema ist in dritter Normalform, • wenn esin 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. Datenbanken I

More Related