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

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

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

Beispielrelation Attribut (Spalte) Name des Relationenschemas Markt: Bezeichnung Standort Kategorie Internationaler Töpfermarkt Krefeld Töpfer- markt Sommerhausen Sommer- hausen Hanau Relationenschema Relation (Tabelleninhalt) Tupel (Zeile) Karczewski Datenbanken I

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

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

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 Markt: Bezeichnung Standort Name Kategorie Veranstalter Name Adresse Bezeichnung Typ Karczewski Datenbanken I

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

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

Entity-Typen (Beispiel) Markt Bezeichnung Standort Kategorie Markt: Bezeichnung Standort Kategorie Karczewski Datenbanken I

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

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

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

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

m:n-Beziehung (Beispiel, Forts.) 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

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: Logischer Datenentwurf Produkt: Nummer Bezeichnung Funktion Markt: Bezeichnung Standort Kategorie WirdAngebotenAuf: Nummer Bezeichnung Standort Anzahl Karczewski Datenbanken I

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

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

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

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> Markt: Bezeichnung Standort Name Kategorie Veranstalter Name Adresse Bezeichnung Typ Karczewski Datenbanken I

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

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

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

Rekursive Beziehung (Beispiel) Realisierung erfolgt analog zu einer zweistelligen Beziehung graphische Darstellung in Krähenfußdarstellung: b. graphische Darstellung als Bachmanndiagramm: c. Tabellendarstellung: Produkt: Nummer Bezeichnung Funktion Besteht_aus: NummerO NummerU Anzahl Karczewski Datenbanken I

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

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

Mehrstellige Beziehung (Lösung) Händler Name Adresse Firmenbezeichnung Spediteur Name Adresse Firmenbezeichnung Rohstoff: Bezeichnung Art Liefert: HName SName Bezeichnung Bestelldatum Menge Karczewski Datenbanken I

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

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

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

Generalisierung/Spezialisierung (Beispiel) Geschäftspartner Beispiel: 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 Typ Kunde: Geschäftspartner-Nr Adresse Telefonnummer Name Bei overlapping redundante Speicherung Karczewski Datenbanken I

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

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

Anomalien INSERT Gar nicht möglich, Schlüssel muss gefüllt sein Einührung Anomalien 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: Neues Tonprodukt einführen, aber noch nicht auf den (= Insert-Anomalie) Markt bringen. Welches Problem entsteht? INSERT Gar nicht möglich, Schlüssel muss gefüllt sein Dummy-Wert für Schlüssel dann Dummies überschreiben oder „Dummy-Tupel“ vergessen wenn Produkt noch mal eingefügt wenn Markt bekannt Viele Null / Dummy-Felder = Performanzprobleme bei Integritätsbed.prüfung UPDATE Gefahr von Vergessen eines Tupels (Inkonsistenz) Viel Ändern obwohl nur 1 Sachverhalt sich ändert -> Performanz DELETE Mit Löschen verschwindet auch ein Markt ganz. Markt-Existenz darf nicht von Produkt-Existenz abh. sein ==> Anomalien resultieren immer aus Redundanz ! ==> Redundanz resultiert aus funkt. Abh. innerhalb einer Tabelle Nicht-Trennung von “Konzepten“ Ziel: Trennung von Konzepten Redundanzfreiheit -> Anomaliefreiheit Ergebnis: Sachverhalte genau einmal repräsentiert Es ist immer nur 1 Operation nötig Ä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? Karczewski Datenbanken I

Einfüge-Anomalie INSERT Gar nicht möglich, Schlüssel muss gefüllt sein Einührung 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 INSERT Gar nicht möglich, Schlüssel muss gefüllt sein Dummy-Wert für Schlüssel dann Dummies überschreiben oder „Dummy-Tupel“ vergessen wenn Produkt noch mal eingefügt wenn Markt bekannt Viele Null / Dummy-Felder = Performanzprobleme bei Integritätsbed.prüfung UPDATE Gefahr von Vergessen eines Tupels (Inkonsistenz) Viel Ändern obwohl nur 1 Sachverhalt sich ändert -> Performanz DELETE Mit Löschen verschwindet auch ein Markt ganz. Markt-Existenz darf nicht von Produkt-Existenz abh. sein ==> Anomalien resultieren immer aus Redundanz ! ==> Redundanz resultiert aus funkt. Abh. innerhalb einer Tabelle Nicht-Trennung von “Konzepten“ Ziel: Trennung von Konzepten Redundanzfreiheit -> Anomaliefreiheit Ergebnis: Sachverhalte genau einmal repräsentiert Es ist immer nur 1 Operation nötig Karczewski Datenbanken I

Änderungs-Anomalie INSERT Einührung Ä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. INSERT Gar nicht möglich, Schlüssel muss gefüllt sein Dummy-Wert für Schlüssel dann Dummies überschreiben oder „Dummy-Tupel“ vergessen wenn Produkt nochmal eingefügt wenn Markt bekannt Viele Null / Dummy-Felder = Performanzprobleme bei Integritätsbed.prüfung UPDATE Gefahr von Vergessen eines Tupels (Inkonsistenz) Viel Ändern obwol nur 1 Sachverhalt sich ändert -> Performanz DELETE Mit Löschen verschwindet auch ein Markt ganz. Markt-Existenz darf nicht von Produkt-Existenz abh. sein ==> Anomalien resultieren immer aus Redundanz ! ==> Redundanz resultiert aus funkt. Abh. innerhalb einer Tabelle Nicht-Trennung von “Konzepten“ Ziel: Trennung von Konzepten Redundanzfreiheit -> Anomaliefreiheit Ergebnis: Sachverhalte genau einmal repräsentiert Es ist immer nur 1 Operation nötig Karczewski Datenbanken I

Lösch-Anomalie INSERT Gar nicht möglich, Schlüssel muss gefüllt sein Einührung 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 INSERT Gar nicht möglich, Schlüssel muss gefüllt sein Dummy-Wert für Schlüssel dann Dummies überschreiben oder „Dummy-Tupel“ vergessen wenn Produkt nochmal eingefügt wenn Markt bekannt Viele Null / Dummy-Felder = Performanzprobleme bei Integritätsbed.prüfung UPDATE Gefahr von Vergessen eines Tupels (Inkonsistenz) Viel Ändern obwohl nur 1 Sachverhalt sich ändert -> Performanz DELETE Mit Löschen verschwindet auch ein Markt ganz. Markt-Existenz darf nicht von Produkt-Existenz abh. sein ==> Anomalien resultieren immer aus Redundanz ! ==> Redundanz resultiert aus funkt. Abh. innerhalb einer Tabelle Nicht-Trennung von “Konzepten“ Ziel: Trennung von Konzepten Redundanzfreiheit -> Anomaliefreiheit Ergebnis: Sachverhalte genau einmal repräsentiert Es ist immer nur 1 Operation nötig Karczewski Datenbanken I

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

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

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

Verletzung der ersten Normalform Einührung Verletzung der ersten Normalform 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-atomare Attributwerte sind verboten ! Lehrbücher, Autoren dazu -> Warum nicht in einer Relation speicherbar? -> Weil es 2 sind! -> 1:n-Beziehung Probleme mit oberer Dozent-Relation: nach HW könnte nicht sortiert werden Tupel hätten unterschiedl. Länge Wie Hinzufügen oder Löschen von HW Wie wäre ein JOIN möglich? -> Neue Relation mit neuem PK (“Verbundtreue“) mit Fremdschlüssel NFNF (NF2) - Nicht-1NF zugelassen (macht Sinn) Das Attribut Autoren erlaubt pro Lehrbuch mehr als einen Eintrag, daher Verletzung der 1NF. Karczewski Datenbanken I

Einührung Auflösung zur 1NF Autor_Buch ISBN Autor 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 werden für solche Bücher mehrere Zeilen in der neuen Relation nötig. Lehrbücher, Autoren dazu -> Warum nicht in einer Relation speicherbar? -> Weil es 2 sind! -> 1:n-Beziehung Probleme mit oberer Dozent-Relation: nach HW könnte nicht sortiert werden Tupel hätten unterschiedl. Länge Wie Hinzufügen oder Löschen von HW Wie wäre ein JOIN möglich? -> Neue Relation mit neuem PK (“Verbundtreue“) mit Fremdschlüssel NFNF (NF2) - Nicht-1NF zugelassen (macht Sinn) Karczewski Datenbanken I

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

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

Einührung 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? Wo liegen hier fkt. Abhängigkeiten? Lösung: “Äpfel und Birnen“ trennen ! (Trennung von Konzepten) --> überleiten übernä. Folie Karczewski Datenbanken I

Auflösung zur 2NF Töpferprodukt Markt Töpferprodukt Einührung 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 € 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-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 Strasbourg Rheinischer Töpfermarkt Mainz Odenwälder Töpferwelt Erbach Wo liegen hier fkt. Abhängigkeiten? Lösung: “Äpfel und Birnen“ trennen ! (Trennung von Konzepten) --> überleiten übernä. Folie Karczewski Datenbanken I

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

Verbundtreue ? Töpferprodukt Markt Töpferprodukt Töpferprodukt Markt_2 Einührung 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 € 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-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 Strasbourg Rheinischer Töpfermarkt Mainz Odenwälder Töpferwelt Erbach Wo liegen hier fkt. Abhängigkeiten? Lösung: “Äpfel und Birnen“ trennen ! (Trennung von Konzepten) --> überleiten übernä. Folie ? Karczewski Datenbanken I

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

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

Einührung Verletzung der 3NF Töpferprodukt Prod-Nr Produktart Funktion 11022 Tee-Service Gebrauch 10622 Kaffee-Service Gebrauch 20131 Schale Deko 40030 Krug Deko 40031 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? Insert- u. Update-Anomalien beseitigt. Aber immer noch in “Töpferprodukte“ Update-Anomalie Delete-Anomalie (wenn Schale und Krug gelöscht) Wo liegen hier fkt. Abhängigkeiten? Karczewski Datenbanken I

Auflösung der 3NF Töpferprodukt Töpferprodukt_2 Töpferprodukt Art Einührung Auflösung der 3NF 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_2 Prod-Nr Produktart 11022 Tee-Service 10622 Kaffee-Service 20131 Schale 40030 Krug 40031 Krug Töpferprodukt Art Produktart Funktion Tee-Service Gebrauch Kaffee-Service Gebrauch Schale Deko Krug Deko Insert- u. Update-Anomalien beseitigt. Aber immernoch in “Töpferprodukte“ Update-Anomalie Delete-Anomalie (wenn Schale und Krug gelöscht) Wo liegen hier fkt. Abhängigkeiten? Karczewski Datenbanken I

Aufgabe 3NF 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 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

Gesamtlösung Töpferprodukt Markt Töpferprodukt_2 Töpferprodukt Markt_2 Einührung Gesamtlösung 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 € Töpferprodukt_2 Prod-Nr Produktart 11022 Tee-Service 10622 Kaffee-Service 20131 Schale 40030 Krug 40031 Krug Töpferprodukt Markt_2 Prod-Nr Verkaufsmarkt 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öpferprodukt Art Produktart Funktion Tee-Service Gebrauch Kaffee-Service Gebrauch Schale Deko Krug Deko Töpfermarkt Verkaufsmarkt Marktstandort Internat. Tonmarkt Strasbourg Rheinischer Töpfermarkt Mainz Odenwälder Töpferwelt Erbach Karczewski Datenbanken I

Normalisierung: Pro und Contra Einührung Normalisierung: Pro und Contra Häufige Einwände gegen Normalisierung: „Erfordert mehr Speicherplatz !“ „Umständlicher zu handhaben !“ „Reduziert Laufzeit-Performanz !“ nicht korrekt nicht korrekt wenn View-Konzept (Sichten) unterstützt korrekt Ab 3NF meist wesentliche Konsistenzregeln abgebildet. 3NF wird bei Datenmodell-Design gefordert. Z.B. Performanzverlust bei 1 NF --> begegnen durch Speicherung auf selber/benachbarter Speicherseite (Physischer Entwurf) Trotzdem: Denormalisierung - wie Konsistenz erhalten / Update-Anomalien verhindern bei <3NF ? --> Trigger + Stored Procedures 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

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. Zeichnen Sie alle funktionalen Abhängigkeiten auf. Benutzen Sie dabei die Buchstaben in Klammern. Ermitteln Sie den Schlüssel zu dem Relationenschema Begründen Sie, warum das Relationenschema nicht in 2. und nicht in 3. Normalform ist. Zerlegen Sie das Relationenschema in Relationenschemata so, dass diese alle in 3. Normalform sind. Karczewski Datenbanken I