3. Relationales Modell

Transkript

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

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

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

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 Hanau Sommerhausen Töpfermarkt Töpfermarkt Tupel (Zeile) Karczewski Datenbanken I 4

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

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

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

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

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

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

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

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

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

14 m:n-beziehung (Beispiel) Produkt (0,*) (0,*) 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 14

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

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

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

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

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

20 m:1-beziehung (Beispiel) nur 2 Tabellen entstehen Hinzufügen des Fremdschlüssels (Veranstalter-)Name in Markt a) Design-Sicht des Power-Designers: <pk> b) Tabellendarstellung: Markt: Bezeichnung Standort Name Kategorie Veranstalter Name Adresse Bezeichnung Typ Karczewski Datenbanken I 20

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

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

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

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

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

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

27 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 27

28 Generalisierung/Spezialisierung Es gibt zwei Varianten der Realisierung: 1. Für jeden Spezialisten und für den Generalisten wird ein eigenes Relationsschema erstellt. Die Spezialisten erhalten zusätzlich den Primärschlüssel des Generalisten. Die Primärschlüssel der Spezialisten sind Fremdschlüssel zum Generalisten. Variante ist sinnvoll, wenn der Generalist nicht unbedingt einem Spezialisten zugeordnet ist (partielle Spezialisierung), wenn die Spezialisten überlappen. Karczewski Datenbanken I 28

29 Generalisierung/Spezialisierung 2. Nur die Subtypes haben ein Relationenschema. Zusätzlich zu den Spezialisten-Attributen werden in allen Spezialisten alle Generalisten-Attribute aufgenommen. Nur möglich, wenn jede Instanz des Generalisten gleichzeitig Instanz eines Spezialisten ist (totale Spezialisierung). Falls überlappend: Redundante Speicherung! Vorteil: Bei Abfragen müssen Spezialist und Generalist nicht zusammengeführt werden. Karczewski Datenbanken I 29

30 Generalisierung/Spezialisierung (Beispiel) Beispiel: Geschäftspartner O Generalist: Geschäftspartner (Geschäftspartner-Nr, Adresse, Telefonnummer) Spezialisten: Veranstalter (Bezeichnung, Typ) Kunde (Name) 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 30

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

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