2. Datenmodellierung mit ERM. Motivation für Datenmodellierung. Begriffsklärung. Kardinalität/Komplexität von Beziehungstypen

Transkript

1 2. Datenmodellierung mit ERM Motivation für Datenmodellierung Begriffsklärung Kardinalität/Komplexität von Beziehungstypen Erweiterungen des E/R-Modells Darstellung von Attributen/Beziehungen als Entitytypen Seite 47

2 2.1 Motivation für Datenmodellierung Zielsetzung dieses Kapitels: - Einführung von Begriffen wie Entity, Entitytyp, Wertebereich, Attribut, Schlüssel(-kandidat), Beziehung, Beziehungstyp, Kardinalität von Beziehungstypen - Einführung von E/R-Diagramm, d.h. der graphischen Darstellungsform von E/R-Modellen: Verstehen/Lesen von Syntax und Semantik - Verdeutlichung anderer E/R-Modellierungsmethodiken (erweiterte E/R- Modelle, semantische Datenmodelle) Literatur zur Modellierungsmethodik: - P.P.Chen: The Entity-Relationship Model - Toward a Unified View of Data. ACM Transactions on Database Systems (TODS), Bd. 1, Nr. 1, März 1976, S (Original vom "Erfinder" der Modellierungsmethodik Link!) - Praktisch in jedem Datenbanklehrbuch, "Urschleim" der DB-Forschung Seite 48

3 2.1 Motivation für Datenmodellierung Wozu Modellierung auf abstrakter Ebene statt direkt in der Datenbank? E/R-Modellierung vs. relationale Tabellendarstellung - E/R-Modell unabhängig von späterer Umsetzung im konkreten Datenbankmodell (relational, hierarchisch,...) und erst recht konkreten Datenbanksystem (DB2, Oracle,...) Flexibilität/Portabilität - E/R-Modell leichter verständlich/übersichtlicher, auch wegen graphischer Notation, als z.b. relationale (tabellarische) Darstellung - Mehr Semantik in offensichtlicher Weise im E/R-Modell darstellbar (Entity-Typen, Beziehungstypen, Kardinalitäten...), in relationalem Modell teils nur "auf Umwegen" möglich (siehe auch nächste Folie) - E/R-Modell kann viel besser als relationales Modell ("Tabellensammlung") Gesprächsgrundlage zwischen Anwendern/Fachabteilung und Informatikern bilden "anwendungsnah und trotzdem schon nah an der Datenbank" hängt natürlich mit vorangegangenen Eigenschaften zusammen Seite 49

4 2.1 Motivation für Datenmodellierung Beispiel für ein E/R-Modell, Ausschnitt aus der realen Mini-Welt - Darstellung von Entitytypen, Attributen und Beziehungen - Unvollständige Beziehungstypen (fehlende Kardinalitäten) Titel Zeitplan Professor liest/wird gelesen Vorlesung Fach Telefon# Name Semester Autor Titel ISBN empfiehlt/wird empfohlen zu Buch Seite 50

5 2.1 Motivation für Datenmodellierung Hinweis für die Verwendung: - E/R-Modell in Realität andere Dimensionen ("Tapeten") - unterstützen in aller das Regel E/R-Modell nicht direkt ("E/R-Sprache" als Datenbanksprache) - Umsetzung des E/R-Modell in konkretes Datenbankmodell erforderlich Relationales Modell "war schon da", als das E/R-Modell Mitte der 1970er erfunden wurde "E/R-Sprache" unter Umständen schwierig zu erlernen, da komplex Allerdings: Forschung hat in vielfältiger Weise "E/R-Sprachen" vorgeschlagen (meist sogar für erweitertes E/R-Modell) - selten (prototypisch) implementiert - noch seltener in Produkten realisiert Seite 51

6 2.2 Begriffsklärung Entity / Entitytyp - Attribute - Attributwerte/Domänen Schlüssel - Schlüsselkandidaten - Künstliche Schlüssel Beziehung / Beziehungstyp - Kardinalität/Komplexität - Notationsformen E/R-Diagramm Seite 52

7 2.2.1 Entity/Entitytyp Definition nach A. Meier [Relationale Datenbanken (1995), S. 14]: - "Unter Entität (engl. entity) versteht man ein bestimmtes, d.h. von anderen wohlunterscheidbares Objekt der realen Welt oder unserer Vorstellung. Dabei kann es sich um ein Individuum, einen Gegenstand, um einen abstrakten Begriff oder um ein Ereignis handeln." - Entitäten werden zu Entitätstypen (entity types) zusammengefasst - Entitytyp E = Menge aller möglichen Entities e mit gleichen charakteristischen Merkmalen Beispiele: - Angestellter Meier und Müller sind Entities mit gleichen Merkmalen (PNr, Name, Vorname, Anschrift,...) Entitytyp ANGEST für die Menge aller möglichen Angestellten (Individuen) - Entitytypen ABTEILUNG (Abstrakter Begriff), GEBÄUDE (Gegenstand) Verschiedene Entitytypen müssen inhaltlich nicht unbedingt disjunkt sein Seite 53

8 2.2.1 Entity/Entitytyp Entitytypen besitzen Attribute, d.h. dem Entitytyp E wird eine nichtleere, endliche Attributmenge A zugeordnet (E:A) - Allgemein: A = {a 1, a 2, a 3..., a n }, n endlich (n 1), a i sind die Attribute - Bsp: ANGEST:{PNR, NAME, VORNAME, GEHALT, ANR...} Einzelnem Entity e sind entsprechende Attributwerte zugeordnet - Auf der Entityebene (Ausprägungsebene) beschreiben die Attributwerte das Entity - Bsp: Meier:{17, Meier, Alfons, 5000, 4...} Jedem Attribut a ist ein Wertebereich (Domain, Domäne) zugeordnet, der als dom(a) bezeichnet wird - Wertebereichsdefinitionen stellen (einfache) semantische Integritätsbedingungen dar - Bsp: dom(pnr) = INTEGER; dom(gehalt) = {g 1000 g 10000} Seite 54

9 2.2.2 Schlüssel Ziel: Eindeutige Identifizierung eines Entity e innerhalb seines Entitytyps E, also innerhalb der möglichen Entities gleichen Typs - Allgemein: Gegeben ist E:A Gesucht ist Schlüssel K A, K nicht leer, so dass die Schlüsselattributwerte ein Entity eindeutig identifizieren - Beispiel: ANGEST:{PNR, NAME, VORNAME, GEHALT, ANR} K={PNR} d.h. Personalnummer identifiziert ein Entity, wenn die Personalnummer eindeutig im gesamten Unternehmen ist! K={PNR, ANR} als zweiattributiger Schlüssel, wenn Personalnummer nicht unternehmensweit eindeutig ist, aber innerhalb einer Abteilung Schlüsseleigenschaft für eine Attributmenge - Entscheidung darf nicht aufgrund konkreter Entities getroffen werden - Festlegung "zukunftssicher" anhand der Semantik des Entitytyps Seite 55

10 2.2.2 Schlüssel Forderung nach Schlüsselminimalität, d.h. K' K : K' Schlüssel - Schlüsselkandidaten = alle Schlüssel mit dieser Eigenschaft - Primärschlüssel = Festlegung auf einen der Schlüsselkandidaten, beispielsweise aufgrund der Bedeutung (Bsp: PNr vs. SVNr) Verwendung künstlicher Primärschlüssel häufig anzutreffen - Sind keine "natürlichen Attribute" von Entitytypen - Beispiel: Personalnummer, Auftragsnummer, Teilenummer - Gründe für die Einführung: "natürlicher" Schlüssel existiert nicht oder setzt sich aus sehr vielen Attributen zusammen, Kompaktheit und "Handlichkeit" erwünscht, Bsp: {NAME, VORNAME, GEBURTSDATUM, GEBURTSORT...} "natürlicher" Schlüssel existiert aus heutiger Sicht, aber es fehlt die Zukunftssicherheit, Bsp: {NAME, VORNAME} in "5-Mann-Firma" Schlüssel soll auch als Medium für Referenzierung zwischen Entities benutzt werden kompakter Schlüssel wichtig Seite 56

11 2.2.3 Beziehungstypen Definition: - Beziehungen r (relationships) bestehen zwischen einzelnen Entities e und e' verschiedener oder gleicher Entitytypen E und E' - Beziehungstyp R (relationship type) ist die Menge aller möglichen Beziehungen r zwischen je einem Entity e i der Entitytypen E i (i = 1,...,k) R = E 1 E 2... E k (kartesisches Produkt) R = {r = (e 1, e 2,...,e k ) e 1 є E 1,...,e k єe k } - Beziehungstypen können k-stellig sein (k 2), Stelligkeit heißt grad(r) - Beziehungstypen/Beziehungen können Attribute/Attributwerte besitzen Hinweis für die Ablage in der Datenbank - Nur die tatsächlich vorhandenen Entitymengen (ES = entity set) und Beziehungsmengen (RS = relationship set) sind von Interesse - ES und RS sind endliche Untermengen von E bzw. R: entity set: relationship set: ES E RS R Seite 57

12 2.2.3 Beziehungstypen Beispiel: - Menge der Entitytypen ANGEST (Angestellte) PROJ (Projekte) MATERIAL (Materialien) LIEFERANT (Lieferanten) - Mögliche 2-stellige Beziehungstypen: Beziehung r 1, wenn ein Angestellter a an einem Projekt p arbeitet: r 1 = ARBEITET_AN = ANGEST PROJ Beziehung r 2, wenn ein Angestellter a Chef von Angestelltem a' ist: r 2 = IST_CHEF = ANGEST ANGEST - Möglicher 3-stelliger Beziehungstyp: Beziehung r 3, wenn ein Lieferant l ein Material m zum Projekt p liefert: r 3 = LIEFERT = LIEFERANT MATERIAL PROJ - Mögliche Attribute an Beziehungstypen: ARBEITET_AN (r 1 ): ZEITLICHER_ANTEIL IST_CHEF (r 2 ): SEIT LIEFERT (r 3 ): MENGE, PREIS (z.b. für konkrete Lieferung) Seite 58

13 2.2.3 Beziehungstypen 1:1-Beziehungstyp (1:1 relationship type) - Jedem Entity aus Entitytyp E1 ist eineindeutig ein Entity aus Entitytyp E2 über den Beziehungstyp R zugeordnet - Beispiel für E1 = ANGEST, E2 = PERSONALAKTE, R = HAT ANGEST HAT PERSONALAKTE a 1 a 2 a 3 a 4 a 5 a 6 Entities Beziehungen Entities r 1 r 2 r 3 r 4 r 5 p 1 p 2 p 3 p 4 p 5 p 6 r 6 entity set entity set relationship set Seite 59

14 2.2.3 Beziehungstypen n:1-beziehungstyp (n:1 relationship type) - Jedem Entity aus Entitytyp E1 ist eindeutig Entity aus Entitytyp E2 über den Beziehungstyp R zugeordnet, Rückrichtung ist nicht eindeutig! - Beispiel für E1 = ANGEST, E2 = ABTEILUNG, R = ARBEITET_IN ANGEST ARBEITET_IN ABTEILUNG a 1 a 2 a 3 a 4 a 5 a 6 a 7 Entities Beziehungen Entities r 1 r 2 r 3 r 4 r 5 r 6 d 1 d 2 d 3 d 4 entity set relationship set entity set Seite 60

15 2.2.3 Beziehungstypen n:m-beziehungstyp (n:m relationship type, many-to-many relationship type) - Jedes Entity aus Entitytyp E1 kann beliebig vielen (0,...,m) Entities aus Entitytyp E2 über den Beziehungstyp R zugeordnet sein - Beispiel für E1 = ANGEST, E2 = PROJ, R = ARBEITET_AN ANGEST ARBEITET_AN PROJ a 1 a 2 a 3 a 4 a 5 a 6 a 7 Entities Beziehungen Entities r 1 r 2 r 3 r 4 r 5 r 6 r 7 r 8 r 9 r 10 p 1 p 2 p 3 p 4 p 5 entity set relationship set entity set Seite 61

16 2.2.3 Beziehungstypen Integritätsregeln für Beziehungstypen/-mengen - Von jeder Beziehung r i geht genau eine Kante aus beim 2-stelligen Beziehungstyp "nach links und nach rechts", da r i = (e j, e k ) - Nicht von jedem Entity e muss eine Kante ausgehen innerhalb eines bestimmten Beziehungstyps R, dann steht e aktuell (für diesen Beziehungstyp R!) in keiner Beziehung r zu einem e' Bsp: Angestellter a i arbeitet an keinem Projekt Bsp: Projekt p i hat keine Mitarbeiter - Mehrere Beziehungen r i innerhalb einer Beziehungsmenge RS zwischen gleichen Entitäten in ES1 und ES2 sind verboten! Mengeneigenschaft von RS wäre verletzt, weil r 1 = (e, e') = r 2 Sachverhalt wäre zweimal dargestellt (Redundanz unerwünscht!) RS e r 1 r 2 r 1 ok e' r 2 RS' Seite 62

17 2.2.3 Beziehungstypen Bemerkungen zu mehrstelligen Beziehungstypen (k 3) - Bsp: Lieferant l 1 liefert Artikel a 1 für Projekt p 1 LIEFERANT Entities LIEFERT relationship set r 1r2 Beziehungen PROJ Entities l 1 l 2 l 3 l 4 unzulässig r 3 Entities p 1 p 2 p 3 a 1 a 2 a 3 entity set ARTIKEL entity set entity set - Information, welche Artikel ein Lieferant liefert (projektübergreifend), ist implizit enthalten und braucht nicht zusätzlich dargestellt werden LIEFERT' = ARTIKEL LIEFERANT möglich, aber redundant LIEFERFÄHIGKEIT = ARTIKEL LIEFERANT notwendig, um anderen Sachverhalt darzustellen ("Artikelkatalog" eines Lieferants) Seite 63

18 2.2.4 E/R-Diagramm Notation: - Entitytyp mit Substantiven als Namen E - Beziehungstyp Verben als Namen (von links nach rechts bzw. oben nach unten) "Aliasnamen" für umgekehrte Leserichtung für Klarheit/Verständnis - Attribut A A - Schlüsselattribut R (k-stellig) A A Im E/R-Diagramm müssen Entitytyp- und Beziehungstypnamen eindeutig sein Beispiel: ABT-NR Name ANGEST arbeitet_in ABTEILUNG Alias: besteht_aus ANGEST arbeitet_an Zeitanteil Budget PROJ Seite 64

19 2.3 Kardinalität/Komplexität von Beziehungstypen Definition: - Komplexität/Kardinalität von Beziehungstypen drückt aus, zu wie vielen Entities e j є E' ein Entity e i є E minimal in Beziehung stehen muss bzw. maximal in Beziehung stehen darf - Ausdrucksmittel ist die (min,max)-notation, min max Was gilt es zu beachten/unterscheiden? - Zwingende Beziehung (mandatory relationship) R = E E', betrachte e 1 є E dann gibt es mindestens ein e 2 є E', mit dem e 1 innerhalb von R in Beziehung steht (r=(e 1,e 2 )) Bsp: Angestellter gehört stets einer Abteilung an, steht also mit einer Abteilung in Beziehung (Beziehungstyp ARBEITET_IN) - Optionale Beziehung (optional relationship) Entity e 1 darf in E existieren, ohne dass es über R zu einem Entity e 2 є E' in Beziehung steht Bsp: Projekte müssen nicht zwingend einen Mitarbeiter haben ("tote Projekte"?) Seite 65

20 2.3 Kardinalität/Komplexität von Beziehungstypen Vergleich der drei Beziehungstypen mit der (min,max)-notation - 1:1-Beziehungstyp entspricht der (1,1) (1,1)-Notation - n:1-beziehungstyp entspricht der (1,1) (0,*)-Notation - n:m-beziehungstyp entspricht der (0,*) (0,*)-Notation Beispiel: - Bücherei mit Entitytypen LESER und BUCH, Beziehungstyp LEIHT_AUS - Jeder Leser kann beliebig viele Bücher ausgeliehen haben - Jedes Buch kann entweder an einen oder keinen Leser ausgeliehen sein, also LEIHT_AUS ist ein 1:n-Beziehungstyp zwischen LESER und BUCH l 1 l 2 l 3 b 1 b 2 (0,*) (0,1) LESER leiht_aus BUCH b 3 b 4 Seite 66

21 2.3 Kardinalität/Komplexität von Beziehungstypen Für 2-stellige Beziehungstypen (binäre Beziehungstypen) wird oft die 1:n-Notation als Vereinfachung/Abkürzung vorgeschlagen - 1:n-Notation ist semantisch ungenauer (ärmer) als (min,max)-notation - Bsp: Entitytypen ANGEST und ABTEILUNG, Beziehungstyp ARBEITET_IN Sachverhalt, dass jeder Angestellte einer Abteilung angehören muss geht bei der Überführung in die 1:n-Notation verloren! Unklar, ob das "n" aus (0,1) oder aus (1,1) heraus entstanden ist, Rücküberführung somit nicht eindeutig möglich! ARBEITET_IN ANGEST (1,1) (0,1) (0,*) (1,*) ABTEILUNG Überführung in ARBEITET_IN ANGEST n 1 ABTEILUNG Seite 67

22 2.3 Kardinalität/Komplexität von Beziehungstypen Die 1:n-Notation umfasst den Spezialfall der 1:1-Beziehung und kann zur n:m-beziehung erweitert werden - Bei der Herleitung aus der (min,max)-notation tritt wieder ein Informationsverlust auf - Bsp: in folgenden Beispielen ist nicht mehr zu erkennen, ob Angestellte erlaubt sind, die an keinem Projekt mitarbeiten ob "leere Projekte" erlaubt sind (keine Angestellten zugeordnet) ob Angestellte ohne Personalakte bzw. Personalakten ohne Angestellte erlaubt sind ARBEITET_AN ANGEST n m PROJ many-to-many ANGEST 1 1 HAT PERSONALAKTE 1:1 Seite 68

23 2.3 Kardinalität/Komplexität von Beziehungstypen Definition der (1,c,m)-Notation für Kardinalitäten - "c" steht für choice/conditional, "m" steht für multiple - Beschränkung der (min,max)-notation auf vier (wesentliche) Fälle - Übersicht: (min,max)-notation (1,1) (0,1) (1,*) (0,*) (1,c,m)-Notation 1 c m mc - Informationsverlust bei der Überführung von (min,max)-notation in die (1,c,m)-Notation bezüglich exakter Kardinalitäten, siehe nächste Folie Hinweise bei der Verwendung von Notationen - Literatur bietet unterschiedlichste Darstellungen, Semantik genau prüfen! - Empfehlung bei der Erstellung von E/R-Modellen: Verwendung der (min,max)-notation wegen Ausdrucksmächtigkeit Verwendung der 1:n-Notation, falls genaue Kardinalitäten unbekannt Seite 69

24 2.3 Kardinalität/Komplexität von Beziehungstypen Beispiel: Darstellung vorangegangener Beispiele in der (1,c,m)-Notation - Ein Angestellter muss genau einer Abteilung zugeordnet sein, eine Abteilung kann beliebig viele ( 0) Angestellte umfassen: ANGEST 1 mc ARBEITET_IN ABTEILUNG - Jeder Angestellte muss mindestens in einem Projekt mitarbeiten, ein Projekt kann beliebig viele ( 0) Angestellte umfassen: ANGEST m ARBEITET_AN mc PROJ - Jeder Angestellte hat genau eine Personalakte, es gibt keine "leeren" Personalakten ohne Angestellte ANGEST 1 1 HAT PERSONALAKTE Seite 70