Relationales Modell: 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. 1
Rückblick: Datenbank-Entwurfsprozess Semantische Datenmodellierung (vgl. Kapitel 2) Überführung des semantischen Datenmodells in das relationale Modell 2
Mathematische Grundlagen des relationalen Modells (1): Seien W 1, W 2,, W n die Wertebereiche der Attribute A 1, A 2,, A n. Das kartesische Produkt der Mengen W 1, W 2,, W n ist die Menge aller n-tupel (w 1, w 2,, w n ), w i W i und wird geschrieben als W 1 X W 2 X X W n. Jede Untermenge des kartesischen Produkts W 1 X W 2 X X W n 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 = (A 1, A 2,, A j ) heißt Schlüssel der Relation, wenn keine echte Untermenge von K eine identifizierende Attributkombination der Relation ist. 3
Mathematische Grundlagen des relationalen Modells (2): 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. 4
Beispielrelation: Name des Relationenschemas Attribut (Spalte) Markt: Bezeichnung Standort Kategorie Relationenschema Internationaler Töpfermarkt Krefeld Töpfermarkt Relation (Tabelleninhalt) Töpfermarkt Sommerhausen Internationaler Töpfermarkt Sommerhausen Hanau Töpfermarkt Töpfermarkt Tupel (Zeile) 5
Kritik am relationalen Modell: 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) 6
Integritätsbedingungen: 7 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. 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.
Integritätsbedingungen: Beispiel: Markt: Bezeichnung Standort Name Kategorie Veranstalter: Name Adresse Bezeichnung 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) 8
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. 9
Rückblick: Datenbank-Entwurfsprozess Überführung des semantischen Datenmodells in das relationale Modell 10
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
1. Entity-Typ 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. 12
Entity-Typ (Beispiel): Markt Bezeichnung Standort Kategorie Markt: Bezeichnung Standort Kategorie Datentypen: Bezeichnung varchar(), Standort varchar(), Kategorie Aufzählungstyp 13
Entity-Typ (Beispiel): Kunde Vornamen Nachname Strasse Kd-Nummer 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
Vornamen Entity-Typ (Beispiel, Fortsetzung): Auflösung Adresse: Kunde Nachname 2. Es werden nur die Subattribute genutzt. Auflösung Vornamen: Ein zweites Relationenschema wird gebildet Adresse Strasse Stadt Kd-Nummer und über Schlüssel-/Fremdschlüssel verbunden. PLZ Kunde: Kd-Nummer Nachname Strasse PLZ Stadt Vorname: Kd-Nummer Vorname 15 Datentypen: Kd-Nummer integer, Nachname, Vorname, Strasse, Stadt varchar(), PLZ integer oder varchar()
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
m:n-beziehung (Beispiel): Produkt (0,*) (0,*) 6 Markt Produkt (Nummer, Bezeichnung, Funktion) Markt (Bezeichnung, Standort, Kategorie) 6: wird angeboten auf (Anzahl) Produkt: Nummer Bezeichnung Funktion Markt: Bezeichnung Standort Kategorie WirdAngebotenAuf: Nummer Bezeichnung Standort Anzahl 17
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. 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) 18
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
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: * 1 20
Exkurs Anwendung mit einem Case-Tool (Power Designer): 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 21
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. Produkt (0,*) (0,*) 7 Kunde Produkt (Produktnummer, Bezeichnung, Preis) Kunde (Nummer, Name) 7: erhält geliefert (Anzahl, Lieferdatum) 22
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
m:1-beziehung (Beispiel): Markt (1,1) (0,*) 8 Veranstalter Markt (Bezeichnung, Standort, Kategorie) Veranstalter (Name, Adresse, Bezeichnung, Typ) 8: Ansprechpartner Markt: Bezeichnung Standort Name Kategorie Veranstalter: Name Adresse Bezeichnung Typ (Veranstalter-) Name wird in der Markt-Relation ergänzt und zum Fremdschlüssel. 24
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
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
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. Produkt (0,1) (0,*) 5 Dekor Produkt (Produktnummer, Bezeichnung, Größe, Preis) Dekor (Bezeichnung, Foto) 5: ist versehen mit 27
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
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
Relationship-Typ: Rekursive Beziehungen m:n Teilprodukt (0,*) 4 Produkt Rollen (0,*) Produktgruppe 4: besteht aus NummerO und NummerU werden zur Unterscheidung der beiden Nummern eingeführt. Sie sind jeweils Fremdschlüssel zu Nummer in Produkt. Produkt: Nummer Bezeichnung Funktion Besteht_aus: NummerO NummerU Anzahl 30
Relationship-Typ: Rekursive Beziehungen m:1 Teilprodukt (0,1) Produkt Rollen (0,*) Produktgruppe 4 31 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. 4: besteht aus Produkt: Nummer Bezeichnung Funktion NummerU
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
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 33
Aufgabe (rekursive 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. c) Füllen Sie die Relation mit den folgenden Inhalten Fach (0,1) (0,*) 4 Fach (FNr, FName, SWS, CP) 4: ist Voraussetzung für Fach: FNr FName SWS CP 1 Pr1 4 5 2 Pr2 4 5 3 DB 4 5 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
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 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. 35 Zusammengefasst: Es entstehen n+1 Relationenschemata (n = Anzahl der beteiligten Entity- Typen, 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üssel- Attribute der beteiligten Entity-Typen in das n+1. Relationenschema übertragen und dort zum Primärschlüssel.
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. Händler Spediteur (1,*) (1,*) 1 (1,*) Rohstoff 1: liefert (Bestelldatum, Menge) 36
Lösung zur Aufgabe (mehrstellige Beziehung): Händler Name Adresse Firmenbezeichnung Spediteur Name Adresse Firmenbezeichnung Rohstoff: Bezeichnung Art Liefert: HName SName Bezeichnung Bestelldatum Menge 37
8. Relationship-Typ: Generalisierung/Spezialisierung Zwei Varianten der Realisierung bei der Generalisierung/ Spezialisierung sind möglich: 1. 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). 2. 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. 38
Relationship-Typ: Generalisierung/Spezialisierung (Beispiel) Geschäftspartner O Variante 1: 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. Veranstalter Kunde Generalist: Geschäftspartner (Geschäftspartner-Nr, Adresse, Telefonnummer) Spezialisten: Veranstalter (Bezeichnung, Typ) Kunde (Name) Geschäftspartner: Geschaeftspartner-Nr Adresse Telefonnummer Veranstalter: Geschaeftspartner-Nr Bezeichnung Typ Kunde: Geschaeftspartner-Nr Name 39
Relationship-Typ: Generalisierung/Spezialisierung (Beispiel) Geschäftspartner O Variante 2: Nur für die Spezialisten werden Relationen- Schemata erstellt. Diese übernehmen alle Attribute des Generalisten. Bei overlapping entstehen Redundanzen (Adresse, Telefonnummer). Veranstalter Kunde Generalist: Geschäftspartner (Geschäftspartner-Nr, Adresse, Telefonnummer) Spezialisten: Veranstalter (Bezeichnung, Typ) Kunde (Name) Veranstalter: Geschaeftspartner-Nr Adresse Telefonnummer Bezeichnung Typ Kunde: Geschäftspartner-Nr Adresse Telefonnummer Name 40
Aufgabe (Generalisierung/Spezialisierung): Setzen Sie folgende Generalisierung/Spezialisierung in ein äquivalentes relationales Modell um. a) Wählen Sie Variante 1. b) Wählen Sie Variante 2. Generalist: Dokument (DokumentenID, Titel, Standort) Spezialisten: Buch (ISBN, Autor) Zeitschrift (Jahrgang, ISSN) 41
Aufgabe : Quelle: Stefan Rühl 42
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