3. Relationales Modell
Werbung
Datenbanken Relationales Modell: 1 • beruht auf dem mathematischen Konzept der Relation • wurde von Edgar F. Codd 1970 bereits entwickelt • Alle relevanten Informationen der Datenbank sind in diesem Datenbank-Modell in Relationen abgelegt. Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Rückblick: Datenbank-Entwurfsprozess Semantische Datenmodellierung (vgl. Kapitel 2) Überführung des semantischen Datenmodells in das relationale Modell 2 Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Mathematische Grundlagen des relationalen Modells (1): Seien W1, W2, …, Wn die Wertebereiche der Attribute A1, A2, …, An. 3 • 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 in einer relationalen Datenbank wird ein Relationenschema festgelegt, durch Angabe des Namens des Schemas und der dazugehörigen Attribute. • Eine identifizierende Attributkombination einer Relation ist eine Menge von Attributen, durch die jedes Tupel der Relation identifiziert werden kann. • Eine identifizierende Kombination von Attributen K = (A1, A2, …, Aj) heißt Schlüssel der Relation, wenn keine echte Untermenge von K eine identifizierende Attributkombination der Relation ist. Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Mathematische Grundlagen des relationalen Modells (2): 4 • Jede Relation besitzt mindestens einen Schlüssel. • Falls eine Relation mehrere Schlüssel besitzt, wird ein Schlüssel als Primärschlüssel (primary key, PK) ausgezeichnet. • Der Wert des Primärschlüssels ist eindeutig, nicht änderbar und darf nicht leer sein. • Der Primärschlüssel wird im Relationenschema unterstrichen. • Aus der mathematischen Definition der Relation folgt, dass zwei Tupel einer Relation paarweise verschieden (Definition als Menge!) sind, d.h. sie unterscheiden sich mindestens in einem Attribut. • Tupel sind nicht geordnet, d.h. die Reihenfolge ist bedeutungslos. Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Beispielrelation: Attribut (Spalte) Name des Relationenschemas Markt: Relation (Tabelleninhalt) 5 Stephan Karczewski - Datenbanken Bezeichnung Standort Kategorie Internationaler Töpfermarkt Krefeld Töpfermarkt Töpfermarkt Sommerhausen Sommerhausen Töpfermarkt Internationaler Töpfermarkt Hanau Töpfermarkt Relationenschema Tupel (Zeile) 3. Relationales Modell Datenbanken Kritik am relationalen Modell: 6 • Einfacher Aufbau des Modells wird kritisiert, da die komplexe Welt auf flache Relationen herunter gebrochen werden muss. Es ist tatsächlich so, dass Dinge der realen Welt, die man z.B. in einer Excel-Tabelle darstellen kann in einem relationalen Datenbank-System aufgrund der Normalisierungs-Regeln in verschiedene Relationen abgelegt werden müssen. • Dieser Sachverhalt bedeutet neben der unnatürlichen Verteilung auch Performance-Verlust. • Aufgrund der Kritik wurden alternative Ideen entwickelt: Objektorientierte Datenbanken (ausgehend von den objektorientierten Programmiersprachen Objekt-relationale Datenbanken (ausgehend von den relationalen Datenbanken) Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Integritätsbedingungen: • Die Definition von Integritätsbedingungen dient dazu, dass das Datenbanksystem diese automatisiert prüfen und einhalten kann. Auch falls die Gefahr der Verletzung einer Integritätsbedingung besteht, kann das System angemessen reagieren. • Bereits die Einhaltung des Datentyps eines Attributs kann als Integritätsbedingung aufgefasst werden. Das System erlaubt dies nicht und meldet ggfs. einen Fehler bei der Eingabe. • Bei Datenbanken unterscheidet man insbesondere zwei Sorten von Integritätsbedingungen: intralrelationale und interrelationale. • Intrarelationale Integritätsbedingungen sind Abhängigkeiten zwischen Attributen einer Relation. Bekanntestes Beispiel ist die Schlüsselabhängigkeit. Ist ein Attribut (oder eine Kombination von Attributen) als Schlüssel definiert, kann das System für die Einhaltung der Schlüsselbedingung sorgen. • 7 Interrelationale Integritätsbedingungen existieren zwischen Relationen. Bekanntes Beispiel hierfür ist die Fremdschlüsselabhängigkeit. Ein Attribut, das in einer Relation als Schlüssel definiert wurde, kann in einer assoziierten Relation als Fremdschlüssel definiert werden. Die Assoziation legt fest, dass Tupel in den beiden Relationen, die den gleichen Wert in diesem Attribut haben, ein identisches (übergeordnetes) Objekt meinen. Des Weiteren gilt, dass Tupel in der in der assoziierten Relation nur solche Werte in dem Fremdschlüsselattribut haben dürfen, die in der referenzierten Relation auch vorhanden sind. 3. Relationales Modell Stephan Karczewski - Datenbanken Datenbanken Integritätsbedingungen: Beispiel: Markt: Bezeichnung Veranstalter: Name • • 8 Standort Adresse Name Bezeichnung Kategorie Typ Das Attribut Name in der Relation Veranstalter ist Primärschlüssel, d.h. in jedem Tupel muss sich dieses von den anderen im Namen unterscheiden. Die Attribute Bezeichnung und Standort sind Primärschlüssel der Relation Markt, d.h. die Kombination der beiden Attributwerte muss sich in jedem Tupel unterscheiden. • Das Attribut Name in Markt ist Fremdschlüssel, d.h. es korrespondiert zu dem Attribut Name in Veranstalter (hier ist es Schlüssel). Dies bedeutet, dass jeder Name in Markt auch in Veranstalter vorkommen muss. Alle Attribute des Veranstalters sind relevant für den korrespondierenden Markt. • Notation: Unterstrich: Schlüssel(-attribut), Oberstrich: Fremdschlüssel(-attribut) Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: 9 • Das EERM dient der Modellierung der Realwelt aus Sicht der Anwendung. • Das relationale Modell dient als Grundlage für die Realisierung in relationalen Datenbanken. • Die Transformation EERM Relationales Modell führt uns dazu, die Wünsche des Anwenders der Datenbank näher an die physische Realisierung zu bringen. • Die im Folgenden aufgestellten Regeln erlauben eine (halb-)automatisierte Implementation. • Diese Implementation ist mit entsprechenden Software-Tools möglich. • Trotz der aufgestellten Regeln muss der Datenbank-Spezialist am Ende des Prozesses überprüfen, ob die Umsetzung sinnvoll ist. Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Rückblick: Datenbank-Entwurfsprozess Überführung des semantischen Datenmodells in das relationale Modell 10 Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: Folgende Regeln werden verwendet: 1. Jeder Entity-Typ wird zu einem Relationenschema 2. Strukturierte Typen von Attributen müssen in „einfache“ Relationenschemata überführt werden. 3. m:n-Beziehungen werden zu drei Relationenschemata (2 für die Entity-Typen, 1 für den Relationship-Typ) 4. m:1-Beziehungen werden zu zwei Relationenschemata (für die Entity-Typen). 5. 1:1-Beziehungen werden zu zwei Relationenschemata. 6. Rekursive Beziehungen werden konsequent wie „normale“ Beziehungen behandelt. 7. Mehrstellige Beziehungen werden wie zweistellige Beziehungen umgesetzt unter Berücksichtigung des mehrstelligen Relationship-Typ. 8. Generalisierungen/Spezialisierungen können auf zweierlei Weise umgesetzt werden, je nachdem ob die Oberklasse abstrakt oder konkret ist. 11 Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: Entity-Typ 1. 12 • Jeder Entity-Typ wird zu einem Relationenschema. • Der Name des Entity-Typs wird zum Namen des Relationenschemas • Die Attribute des Entity-Typs werden zu den Attributen des Relationenschemas • Falls Entities komplexe Attribute haben, müssen diese aufgelöst werden: Listenartige/Arrayartige Attribute werden in ein neues Relationenschema ausgelagert, welches über eine Schlüssel-/Fremdschlüssel-Beziehung verbunden wird. Recordartige Attribute werden entweder ebenfalls ausgelagert oder als jeweils einzelne Attribute behandelt. • Ein Schlüssel (falls noch nicht im EERM geschehen) wird ausgezeichnet und unterstrichen. • Die Datentypen der Attribute müssen spätestens jetzt festgelegt werden und dürfen nicht komplex (z.B. Liste, Array, Record) sein. Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: Entity-Typ (Beispiel): Markt Bezeichnung Markt: Bezeichnung Standort Kategorie Standort Kategorie Datentypen: Bezeichnung varchar(), Standort varchar(), Kategorie Aufzählungstyp 13 Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: Vornamen Entity-Typ (Beispiel): Kunde Nachname Kd-Nummer Strasse Adresse Stadt PLZ Kunde: Adresse Vornamen Kd-Nummer Nachname Strasse PLZ Stadt Vorname_1 Vorname_2 . . . Vorname_n Dieses Relationenschema ist nicht gültig, da noch komplexe Attribute (Adresse ist recordartig, Vornamen ist listenartig/arryartig) enthalten sind. 14 Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: Vornamen Entity-Typ (Beispiel, Fortsetzung): Auflösung Adresse: Kunde Nachname Es werden nur die Subattribute genutzt. Kd-Nummer Strasse 2. Auflösung Vornamen: Ein zweites Relationenschema wird gebildet Adresse und über Schlüssel-/Fremdschlüssel verbunden. Kunde: Kd-Nummer Nachname Strasse PLZ Stadt Vorname: Kd-Nummer Vorname Stadt PLZ Datentypen: Kd-Nummer integer, Nachname, Vorname, Strasse, Stadt varchar(), PLZ integer oder varchar() 15 Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: 3. Relationship-Typ: m:n-Beziehung • Die beteiligten Entity-Typen werden wie zuvor behandelt. • Der Relationship-Typ wird zu einem eigenen Relationenschema. • Die Attribute des Relationship-Typs werden zu Attributen des neuen Relationenschemas. • Zusätzlich werden die Primärschlüssel-Attribute der beteiligten Entity-Typen als Attribute des neuen Relationenschemas hinzugefügt, wobei gilt: Diese Primärschlüssel-Attribute bilden gemeinsam den Primärschlüssel des neuen Relationenschemas. Diese sind gleichzeitig Fremdschlüssel bezogen auf das Relationenschema, aus dem sie hervorgegangen sind. Zusammengefasst: Es entstehen drei Relationenschemata, eines für den Relationship-Typ und zwei für die beiden Entity-Typen. Diese sind über Schlüssel-/Fremdschlüssel-Beziehungen miteinander verbunden. Hierzu werden die Schlüssel-Attribute der beteiligten Entity-Typen in das dritte Relationenschema übertragen und dort zum Primärschlüssel. 16 Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: (0,*) m:n-Beziehung (Beispiel): (0,*) 6 Produkt Markt Produkt (Nummer, Bezeichnung, Funktion) Markt (Bezeichnung, Standort, Kategorie) 6: wird angeboten auf (Anzahl) Produkt: Nummer Markt: Bezeichnung WirdAngebotenAuf: 17 Stephan Karczewski - Datenbanken Bezeichnung Standort Nummer Funktion Kategorie Bezeichnung Standort Anzahl 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: Exkurs – Anwendung mit einem Case-Tool (Power Designer): 18 1. Modellierung einer m:n-Beziehung (Entity-Typ + Attribute): Die Notation ist unterschiedlich zu der bisher gelernten, jedoch semantisch gleich mächtig. 2. Einfügen von Attributen bei dem Relationship-Typ (change to entity) 3. Check Modell ( Überprüfen auf syntaktische Fehler) 4. (Übersetzen des Modells in das relationale Modell) Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: Exkurs – Anwendung mit einem Case-Tool (Power Designer): 1. Modellierung einer m:n-Beziehung (Entity-Typ + Attribute): Die Notation ist unterschiedlich zu der bisher gelernten, jedoch semantisch gleich mächtig. a) Demonstration am Rechner b) Ergebnis („Krähenfußdiagramm“): 0 * <pi> 19 Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: Exkurs – Anwendung mit einem Case-Tool (Power Designer): 2. Einfügen von Attributen bei dem Relationship-Typ (change to entity) a) Demonstration am Rechner b) Ergebnis: * 20 Stephan Karczewski - Datenbanken 1 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: Exkurs – Anwendung mit einem Case-Tool (Power Designer): 21 3. Check Modell ( Überprüfen auf syntaktische Fehler) 4. (Übersetzen des Modells in das relationale Modell) a) Demonstration am Rechner b) Ergebnis: enthält die gleichen Informationen wie die Tabellendarstellung Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: Aufgabe (m:n-Beziehung): Setzen Sie das folgende EERM in ein äquivalentes relationales Modell um. a) Schreiben Sie direkt die Relationenschemata auf, die entstehen. b) Gehen Sie auf Papier so vor, wie es mit dem Power Designer funktioniert. (0,*) Produkt (0,*) 7 Kunde Produkt (Produktnummer, Bezeichnung, Preis) Kunde (Nummer, Name) 7: erhält geliefert (Anzahl, Lieferdatum) 22 Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: 4. Relationship-Typ: m:1-Beziehung • Die beteiligten Entity-Typen werden zunächst wie zuvor behandelt. • Der Relationship-Typ erhält kein eigenes Relationenschema. • Das Relationenschema, dessen Tupel nur maximal ein Mal in der Beziehung vorkommen dürfen, wird um eine Spalte ergänzt. Diese Spalte erhält den Namen des Primärschlüssel der anderen Relation und wird zum Fremdschlüssel. Zusätzlich werden bei diesem Relationship-Typ evtl. vorhandene Attribute des Relationship-Typs angebracht. Zusammengefasst: Es entstehen zwei Relationenschemata. Diese sind über die Schlüssel/Fremdschlüssel-Beziehung miteinander verbunden, die durch Ergänzung der „1“-Relation um den Schlüssel der „m“-Relation entsteht. 23 Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: (1,1) m:1-Beziehung (Beispiel): (0,*) 8 Markt Veranstalter Markt (Bezeichnung, Standort, Kategorie) Veranstalter (Name, Adresse, Bezeichnung, Typ) 8: Ansprechpartner Markt: Bezeichnung Veranstalter: Name Standort Adresse Name Bezeichnung Kategorie Typ (Veranstalter-) Name wird in der Markt-Relation ergänzt und zum Fremdschlüssel. 24 Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: Exkurs – Anwendung mit einem Case-Tool (Power Designer): 1. Modellierung einer m:1-Beziehung (Entity-Typ + Attribute): a) Demonstration am Rechner b) Ergebnis („Krähenfußdiagramm“): * 0 1 <pi> 25 Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: Exkurs – Anwendung mit einem Case-Tool (Power Designer): 2. Einfügen von Attributen bei dem Relationship-Typ (change to entity) entfällt! 3. Check Modell ( Überprüfen auf syntaktische Fehler) 4. (Übersetzen des Modells in das relationale Modell) a) Demonstration am Rechner b) Ergebnis: enthält die gleichen Informationen wie die Tabellendarstellung <pk> 26 Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: Aufgabe (m:1-Beziehung): Setzen Sie das folgende EERM in ein äquivalentes relationales Modell um. a) Schreiben Sie direkt die Relationenschemata auf, die entstehen. b) Gehen Sie auf Papier so vor, wie es mit dem Power Designer funktioniert. (0,1) Produkt (0,*) 5 Dekor Produkt (Produktnummer, Bezeichnung, Größe, Preis) Dekor (Bezeichnung, Foto) 5: ist versehen mit 27 Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: 5. Relationship-Typ: 1:1-Beziehung Vorbemerkung: Es können theoretisch alle Attribute in ein Relationenschema gebracht werden, d.h. aus 2 Entity-Typen wird 1 Relationenschema. Diese Variante ist jedoch praktisch nicht sinnvoll, da es aus Anwendungssicht gute Gründe gegeben hat, zwei Entity-Typen zu erstellen. Ansonsten geht man wiefolgt vor: • Die beteiligten Entity-Typen werden zunächst wie zuvor behandelt. • Der Relationship-Typ erhält kein eigenes Relationenschema. • Eines der beiden Relationenschemata wird um eine Spalte ergänzt. Diese Spalte erhält den Namen des Primärschlüssel der anderen Relation und wird zum Fremdschlüssel. Bei der 1:1-Beziehung ist es egal welche der beiden Relationen welche Rolle übernimmt. Zusammengefasst: Es entstehen zwei Relationenschemata. Diese sind über die Schlüssel/Fremdschlüssel-Beziehung miteinander verbunden, die durch Ergänzung um ein Attribut in einer der Relationen entsteht. 28 Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: 6. Relationship-Typ: Rekursive Beziehungen • Die beteiligten Entity-Typen werden wie zuvor behandelt. • Bei m:n-Beziehungen wird der Relationship-Typ zu einem eigenen Relationenschema, bei m:1-Beziehungen ist dies nicht notwendig. • Die Attribute des Relationship-Typs werden wie bei nicht-rekursiven Beziehungen gehandhabt.. • Da die beteiligten Entity-Typen identisch sind, wird auch nur ein Relationenschema daraus erstellt. Zusammengefasst: Es entstehen zwei Relationenschemata bei einer m:n-Beziehung und nur eines bei einer m:1-Beziehung. Die Attribute und Schlüssel-/Fremd-Schlüssel werden so behandelt wie bei Beziehungen ohne Rekursion. 29 Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: Relationship-Typ: Rekursive Beziehungen Rollen Teilprodukt Produkt (0,*) (0,*) Produktgruppe m:n 4 4: besteht aus NummerO und NummerU werden zur Unterscheidung der beiden Nummern eingeführt. Sie sind jeweils Fremdschlüssel zu Nummer in Produkt. 30 Stephan Karczewski - Datenbanken Produkt: Besteht_aus: Nummer Bezeichnung NummerO Funktion NummerU Anzahl 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: Relationship-Typ: Rekursive Beziehungen Rollen Teilprodukt Produkt (0,1) (0,*) Produktgruppe m:1 4 NummerU wird zur Unterscheidung von Nummer eingeführt. Sie ist praktisch Fremdschlüssel zu Nummer in Produkt. Durch diese Konstruktion kann eine Hierarchie der Produkte (nichts anderes ist die rekursive 1:n-Beziehung) dargestellt werden. 31 Stephan Karczewski - Datenbanken 4: besteht aus Produkt: Nummer Bezeichnung Funktion NummerU 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: Exkurs – Anwendung mit einem Case-Tool (Power Designer): 1. Modellierung einer rekursiven m:n-Beziehung (Entity-Typ + Attribute): a) Demonstration am Rechner b) Ergebnis („Krähenfußdiagramm“): 0 * 1 32 Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: Exkurs – Anwendung mit einem Case-Tool (Power Designer): 33 2. Einfügen von Attributen bei dem Relationship-Typ (change to entity) entfällt! 3. Check Modell ( Überprüfen auf syntaktische Fehler) 4. (Übersetzen des Modells in das relationale Modell) a) Demonstration am Rechner b) Ergebnis: enthält die gleichen Informationen wie die Tabellendarstellung Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: Aufgabe (rekursive Beziehung): Fach (0,1) (0,*) Setzen Sie das folgende EERM in ein äquivalentes relationales Modell um. a) Schreiben Sie direkt die Relationenschemata auf, die entstehen. b) Gehen Sie auf Papier so vor, wie es mit dem Power Designer funktioniert. c) Füllen Sie die Relation mit den folgenden Inhalten Fach: FNr FName SWS CP 1 Pr1 4 5 2 Pr2 4 5 3 DB 4 5 4 Fach (FNr, FName, SWS, CP) 4: ist Voraussetzung für und den Bedingungen Tupel mit FNr 1 ist Voraussetzung für Tupel mit FNr 2, Tupel mit FNr 2 ist Voraussetzung für Tupel mit FNr 3: 34 Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: 7. Relationship-Typ: mehrstellige Beziehung (n-stellig) • Die beteiligten Entity-Typen werden wie zuvor behandelt. • Der Relationship-Typ wird zu einem eigenen Relationenschema, bei Mehrstelligkeit i.d.R. unabhängig von den Kardinalitäten. • Die Attribute des Relationship-Typs werden zu Attributen des neuen Relationenschemas. • Zusätzlich werden die Primärschlüssel-Attribute aller (also mehr als 2) beteiligten EntityTypen als Attribute des neuen Relationenschemas hinzugefügt, wobei gilt: Diese Primärschlüssel-Attribute bilden gemeinsam den Primärschlüssel des neuen Relationenschemas. Diese sind gleichzeitig Fremdschlüssel bezogen auf das Relationenschema, aus dem sie hervorgegangen sind. Zusammengefasst: Es entstehen n+1 Relationenschemata (n = Anzahl der beteiligten EntityTypen, eines für den Relationship-Typ und n für die Entity-Typen. Diese sind über Schlüssel/Fremdschlüssel-Beziehungen miteinander verbunden. Hierzu werden die SchlüsselAttribute der beteiligten Entity-Typen in das n+1. Relationenschema übertragen und dort zum Primärschlüssel. 35 Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: Aufgabe (mehrstellige Beziehung): Setzen Sie das folgende EERM in ein äquivalentes relationales Modell um. Schreiben Sie direkt die Relationenschemata auf, die entstehen. Aufgabe: Setzen Sie das folgende ERM in Relationen um. Spediteur Händler (1,*) (1,*) 1 (1,*) Rohstoff 1: liefert (Bestelldatum, Menge) 36 Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: Lösung zur Aufgabe (mehrstellige Beziehung): 37 Händler Name Adresse Firmenbezeichnung Spediteur Name Adresse Firmenbezeichnung Rohstoff: Bezeichnung Liefert: HName Stephan Karczewski - Datenbanken Art SName Bezeichnung Bestelldatum Menge 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: Relationship-Typ: Generalisierung/Spezialisierung 8. Zwei Varianten der Realisierung bei der Generalisierung/ Spezialisierung sind möglich: 1. 2. 38 Sowohl für den Generalisten als auch für die Spezialisten wird jeweils ein Relationenschema erstellt. Diese Variante ist sinnvoll bei partieller Spezialiserung und wenn eine Überlappung der Spezialisten möglich ist. Vorteil dieser Variante: keine Redundanzen. Jedes Relationen-Schema erhält alle Attribute, die der korrespondierende Entity-Typ bereits hatte. Jeder Spezialist erhält den Primärschlüssel des Generalisten als zusätzliches Attribut. Dieser ist Fremdschlüssel zu der Generalisten-Relation. Er kann auch gleichzeitig als Primärschlüssel beim Spezialisten genutzt werden (muss nicht). Nur für die Spezialisten wird jeweils ein Relationenschema erstellt. Diese Variante ist nur möglich, wenn der Generalist eine abstrakte Klasse darstellt bzw. für den Generalisten keine Tupel existieren, was bedeutet, dass eine totale Spezialisierung vorliegen muss. Bei Überlappung liegt Redundanz vor. Vorteil bei der Abfrage: Nur eine Relation wird benötigt. Jedes Relationen-Schema (nur die Spzialisten) erhält alle Attribute, die der korrespondierende Entity-Typ bereits hatte. Jeder Spezialist erhält zusätzlich alle Attribute des Generalisten-Entity-Typs. Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: Geschäftspartner Relationship-Typ: Generalisierung/Spezialisierung (Beispiel) O Variante 1: Veranstalter Für alle Spezialisten und den Generalisten werden jeweils Relationenschemata erstellt. Die Spezialisten „erben“ den Primärschlüssel des Generalisten. Bei Abfragen zu allen Attributen müssen 2 Relationen angesprochen werden. 39 Geschäftspartner: Geschaeftspartner-Nr Veranstalter: Geschaeftspartner-Nr Kunde: Geschaeftspartner-Nr Stephan Karczewski - Datenbanken Kunde Generalist: Geschäftspartner (Geschäftspartner-Nr, Adresse, Telefonnummer) Spezialisten: Veranstalter (Bezeichnung, Typ) Kunde (Name) Adresse Telefonnummer Bezeichnung Typ Name 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: Geschäftspartner Relationship-Typ: Generalisierung/Spezialisierung (Beispiel) O Veranstalter Variante 2: Nur für die Spezialisten werden RelationenSchemata erstellt. Diese übernehmen alle Attribute des Generalisten. Bei overlapping entstehen Redundanzen (Adresse, Telefonnummer). 40 Kunde Generalist: Geschäftspartner (Geschäftspartner-Nr, Adresse, Telefonnummer) Spezialisten: Veranstalter (Bezeichnung, Typ) Kunde (Name) Veranstalter: Geschaeftspartner-Nr Adresse Telefonnummer Bezeichnung Kunde: Geschäftspartner-Nr Adresse Telefonnummer Name Stephan Karczewski - Datenbanken Typ 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: Aufgabe (Generalisierung/Spezialisierung): Setzen Sie folgende Generalisierung/Spezialisierung in ein äquivalentes relationales Modell um. 41 a) Wählen Sie Variante 1. b) Wählen Sie Variante 2. Generalist: Dokument (DokumentenID, Titel, Standort) Spezialisten: Buch (ISBN, Autor) Zeitschrift (Jahrgang, ISSN) Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: Aufgabe : Quelle: Stefan Rühl 42 Stephan Karczewski - Datenbanken 3. Relationales Modell Datenbanken Transformation EERM Relationales Modell: Lösung: Building (ID, Name) Janitor (ID, Name, Phone) Room (Number, Size, Building_ID, Janitor_ID) Is-Responsible-For (Janitor_ID, Building_ID, Position) Quelle: Stefan Rühl 43 Stephan Karczewski - Datenbanken 3. Relationales Modell
