Informationsmodellierung

Transkript

1 Herbstsemester 2013 CS261 Web Data Management Kapitel DB-2: Datenbankentwurf Informationsmodellierung H. Schuldt Informationsmodellierung Ziel der Informationsmodellierung (des konzeptuellen Datenbankentwurfs) Die Modellierung von Sachverhalten der realen Welt mit Hilfe weniger Grundkonzepte mit dem Zweck, eine computergestützte Datenbank aufzubauen Dazu sind notwendig: eine Modellierungssprache (ein semantisches Datenmodell) eine Entwurfsmethodologie computergestützte Entwurfswerkzeuge (für grosse Entwürfe) Rolle der Informationsmodellierung bei der Entwicklung von Informationssystemen: Informationssysteme werden in mehreren Stufen entwickelt: 1. Analyse der Anwendungswelt (Ermittlung des Informationsbedarfs, zu automatisierende Abläufe) 2. Informationsmodellierung (sowie Prozessmodellierung) 3. Abbildung des Informationsmodells auf ein (relationales) Datenbankschema DB-2-2 1

2 Einordnung des konzeptuellen DB-Entwurfs (I) Der konzeptuelle Datenbank-Entwurf ist wie folgt (grob) in Aktivitäten der Informationsmodellierung eingebunden: Ausschnitt der realen Welt (Miniwelt) konzeptuelles Schema Konzeptueller DB-Entwurf: manuelle/intellektuelle Modellierung halbautomatische Transformation relationales Schema Netzwerk- Schema... objektrelationales Schema DB-2-3 Abstraktionsebenen des Datenbankentwurfs Beim Entwurf einer Datenbankanwendung lassen sich drei Abstraktionsebenen unterscheiden: die konzeptuelle Ebene: diese ermöglicht die Strukturierung des Anwendungsbereichs (Miniwelt). Das Ergebnis des konzeptuellen Entwurfs (konzeptuelles Schema) ist unabhängig vom verwendeten Datenbanksystem. Der konzeptuelle DB-Entwurf ist Gegenstand dieses Kapitels. die Implementierungsebene: diese Ebene sieht die Modellierung mit Hilfe der Konzepte des verwendeten Datenbanksystems vor (d.h. verwendet das Datenmodell eines DBMS relational, objektorientiert, objektrelational, etc.). Das relationale Datenmodell wird Kapitel DB-3 eingeführt. die physische Ebene: diese Ebene hat zum Ziel, die Performanz der Datenbankanwendungen zu erhöhen, in dem besondere Speicherstrukturen, Indexstrukturen, etc. verwendet werden. Voraussetzung sind dabei Annahmen der zu erwartenden Datenmengen bzw. Zugriffscharakteristiken; zudem sind vertiefte Kenntnisse von Betriebssystemkonzepten nötig. In CS243 Datenbanken wird der physische Entwurf und dessen Grundlagen im Detail behandelt. DB-2-4 2

3 Datenbank-Entwurf: Übersicht Generelle Aufgabe: Finde eine formale Beschreibung (Modell) für einen zu modellierenden Teil der realen Welt Zwischenstufen: Beschreibung durch natürliche Sprache (Pflichtenheft): Beispiel: In der Datenbank sollen alle Studierenden mit den durch sie belegten Lehrveranstaltungen gespeichert sein Beschreibung durch abstrakte grafische Darstellungen: Studierender belegt Vorlesung Beschreibung im relationalen Modell: create table studierender (...) ; create table vorlesung (...) ; DB-2-5 Einordnung des konzeptuellen DB-Entwurfs (II) Anforderungsspezifikation (Pflichtenheft, Informations- & Prozessmodell) Hardware/OS- Eigenschaften Konzeptueller Entwurf Implementierungsentwurf (logischer Entwurf) logisches Schema (DBMS-abhängig) Physischer Entwurf konzeptuelles Schema (DBMS-unabhängig) Anforderungsanalyse Informationsanforderungen Datenverarbeitungsanforderungen DBMS- Eigenschaften Physisches (internes) Schema (DBMS-abhängig) DB-2-6 3

4 Grundkonzepte semantischer Datenmodelle (I) Klassifikation (Synonym: Typisierung) Grundlage der Klassifikation ist die Unterscheidung zwischen dem Typ eines Objekts und einer Menge von Objekten dieses Typs (auch Extent des Typs genannt). Ein Objekt, also ein Element des Extents, wird auch Ausprägung des Typs genannt. Generalisierung/Spezialisierung: Beides beinhaltet die Anordnung der Typen in einer Typhierarchie, besser Typverbund (häufig auch Begriffshierarchie genannt). Generalisierung eines Typs: Übergang zu einem allgemeineren (Supertyp). Allgemeinster Typ ist Das Ding an sich Spezialisierung eines Typs: Übergang von einem allgemeinem zu einem oder mehreren speziellen Typen (Subtypen) DB-2-7 Grundkonzepte semantischer Datenmodelle (II) Ein weiteres Grundkonzept ist das Abstrahieren von Details. Dies stellt eine wesentliche Fähigkeit menschlicher Kommunikation dar und ist auch für die Repräsentation von Wissen essentiell. Man unterscheidet zwei Formen der Abstraktion: 1. Aggregation: Bildung von zusammengesetzten Objekttypen aus Einfacheren. (vergleichbar mit dem Bilden von struct- bzw. record-typen in Programmiersprachen und dem gesamthafte Ansprechen von structoder record-variablen) 2. Assoziation: Bildung von Mengentypen, also die Zusammenfassung von Objekten desselben Typs (vergleichbar dem set-konstruktor in Programmiersprachen) DB-2-8 4

5 Das (erweiterte) Entity-Relationship-Modell Das Entity-Relationship-Modell (ER-Modell) bzw. das erweiterte Entity-Relationship-Modell (EER-Modell) ist das am weitesten verbreitete Modell zur Unterstützung des konzeptuellen Datenbank-Entwurfs. Es dient dazu, ein konzeptuelles Schema für einen Ausschnitt der realen Welt zu erstellen Als grafische Darstellung werden E/R-Diagramme eingesetzt Gemäss den Anforderungen an den konzeptuellen Entwurf beschreibt das (E)ER-Modell ein maschinenfernes Datenmodell und erlaubt die Modellierung auf einem hohen Abstraktionsniveau, ohne dass dabei Überlegungen zur Effizienz eine Rolle spielen Das Modell muss danach über vorgegebene, grundlegende Transformationsregeln in ein logisches Schema überführt (und evtl. nachgebessert T Normalisierung) werden DB-2-9 Das (erweiterte) Entity-Relationship-Modell Ausgangspunkt der Modellierung sind Objekte (Entities, Entitäten) der realen Welt oder unserer Vorstellung (eine Person, ein Buch, ein Bankkonto, etc.). Die Modellierung umfasst folgende Schritte: Schritt 1: Anwendung der Klassifikation Welche verschiedenen Typen von Objekten soll es geben? Was sind deren Attribute? Schritt 2: Generalisierung Feststellen, ob es Objekttypen gibt, deren Merkmalsfunktionen als Teilmengen bei anderen Objekttypen vorkommen. Schritt 3: Beziehungen zwischen Objekten: Feststellen, welche Typen von Beziehungen ( Relationship Types ) es zwischen den Objekttypen geben soll. Schritt 4: Festlegung der Arten der Beziehungstypen DB

6 Elemente des ER-Modells Entitätstypen (Entity Types): Objekttypen Student Attribute: Eigenschaften der Objekttypen Name Beziehungstypen (Relationship Types): Beziehungen zwischen Entitäten belegt Entscheidende Aufgabe des Datenbank-Entwurf: Das Auffinden geeigneter Entitäten, Attribute und Beziehungen DB-2-11 Anwendung der Klassifikation Schritt 1: Anwendung der Klassifikation als erstes Ordnungsprinzip des Entwurfs: Welche verschiedenen Typen (Entitätstypen) von Objekten soll es geben? Durch welche Merkmale (= Attributwerte) sollen sie beschrieben werden und wie sollen sie daher später in der DB repräsentiert sein? Ein Entitätstyp E bezeichnet eine Menge von Merkmalsfunktionen (=Attribute) Eine Entitätsmenge, abgekürzt durch ext(e) bezeichnet eine Menge von Objekten die vom gleichen Typ sind, d.h. die durch die gleichen Attribute beschrieben werden (sollen). Manchmal wird die Entitätsmenge auch aktiver Domain von E bezeichnet. Ein Attribut (Merkmalsfunktion) ist eine Funktion, die einer (realen) Entität einen Merkmalswert aus einem bestimmten Wertebereich (Domain) zuordnet. Beispiele: Bücher Attribute: ISBN, Titel, Autoren, Verlag, Erscheinungsjahr Bankkonten Attribute: Kontonummer, Kontoinhaber, Kontostand, Zinssatz Studenten Attribute: Matrikel-Nummer, Name, Adresse, Prüfungen DB

7 Identifikationsschlüssel Ein Identifikationsschlüssel eines Entitätstyps E ist eine Menge K von (einwertigen) Attributen, für die folgendes gilt: Zu jedem Zeitpunkt unterscheiden sich zwei verschiedene Objekte e 1 und e 2 aus E bezüglich K, und es gibt keine echte Teilmenge von K, die diese Eigenschaft besitzt. Beispiele: Kontonummer bei Bankkonten einer bestimmten Bank, IBAN und BIC bei internationalen Bankkonten AHV-Nummer bei Angestellten Es empfiehlt sich, als Identifikationsschlüssel künstliche Schlüssel zu verwenden, die sich während der Lebensdauer der identifizierten Objekte nie ändern, z.b. Kontonummern und Angestelltennummern. Ein Objekt der realen Welt kann als eigenständiges Objekt oder nur als Wert eines Attributs modelliert werden. Beispiel: Farbe kann eine Attribut eines Entitätstyps sein (z.b. die Farbe eines Autos) oder ein eigenständiger Entitätstyp mit Attributen wie chemische Zusammensetzung, Preis oder auch Wellenlänge DB-2-13 Wertebereiche und Graphische Darstellung von Entitätstypen Die Wertebereiche von Attributen sind prinzipiell nicht auf elementare Datentypen beschränkt, sondern können tupelwertig sein (z.b. Datum =TT.MM.JJ). Ebenfalls sind einfache Mengen als Attributwerte zugelassen Allerdings wird beides in der Praxis recht selten angewandt Department.No ist Identifikationsschlüssel Symbole: Beispiele: No Entity-Type Department Name Locations Department.Locations ist ein mehrwertiges Attribut Entity-Type A 1... A n No First Employee Name last... Employee.Name ist ein strukturiertes Attribut DB

8 Generalisierung/Spezialisierung Schritt 2: Generalisierung: Ordnung schaffen bei den Typen durch Anordnen der Typen in eine Typhierarchie : Feststellen, ob es Entitätstypen gibt, deren Merkmalsfunktionen als Teilmengen bei anderen Entitätstypen vorkommen. Generalisierung, Spezialisierung, Vererbung: Zwei Entitätstypen E und F stehen in einer ISA-Beziehung, man sagt F is a E, wenn 1. die Attributmenge von F eine Obermenge der Attributmenge von E ist und 2. die Objektmenge von F eine Teilmenge der Objektmenge von E ist ( jedes f ist-ein e ) Man bezeichnet F als Spezialisierung von E (F ist Subtyp) und E als Generalisierung von F (E ist Supertyp). Man sagt auch, dass F die Attribute von E erbt. E F DB-2-15 Generalisierung/Spezialisierung: Beispiel Die Vererbungsbeziehungen sind Bestandteil des erweiterten ER-Modells Beispiel: Ein Lehrender kann entweder ein Professor, ein Assistent oder ein externer Lehrbeauftragter sein Charakteristik und Bedeutung: Sämtliche Attribute und Beziehungen werden in der Typhierarchie nach unten vererbt DB

9 Generalisierung/Spezialisierung Mit der Generalisierung lassen sich ganze Hierarchien aufbauen, die häufig die morphologische Gliederung eines Anwendungsfeldes modellieren. Beispiele: Wirbeltiere Säugetiere Katzen Tiger Säbelzahntiger Bankkonten Sparkonten Jugendsparkonten Generalisierungshierarchien müssen nicht notwendigerweise Bäume sein. Beispiel: Personen Angestellte Studenten Praktikanten DB-2-17 Zusatzbedingungen bei Spezialisierung/Generalisiserung Verfeinerungen bei Generalisierung/Spezialisierung Seien F 1,..., F n Spezialisierungen des Entitätstyps E. E heisst disjunkt partitioniert, wenn je zwei Objektmengen O j und O k der Typen F j und F k disjunkt sind. E heisst vollständig-überdeckend partitioniert wenn die Vereinigung der speziellen Objektmengen die Objektmenge von E ergibt DB

10 Beziehungstypen Schritt 3: Ausgangspunkt: Objekte der realen Welt. Diese stehen in vielerlei Beziehungen zueinander (z.b. manche Personen sind Kunden einer Bank, manche Personen sind verheiratet). Feststellen, welche Typen von Beziehungen ( Relationship Types ) es zwischen den Objekttypen geben soll. Beziehungstyp, Beziehungsmenge, Beziehung Ein Beziehungstyp B zwischen Entitätstypen T 1, T 2,..., T n mit n 2 ist eine Folge von Paaren B= R 1 :T 1, R 2 :T 2,..., R n :T n Ú mit R i als Rollennamen zur Bezeichnung der Rolle, die Entitätstyp T i in der Beziehung B spielt. Eine Beziehungsmenge (relationship set) des Typs B, abgekürzt mit ext(b) ist eine Teilmenge des kartesischen Produkts der betroffenen Objektmengen ext(b) Œ ext(t 1 ) ä... ä ext(t n ) Eine einzelne Beziehung b ist ein n-tupel b = id(e 1 ),..., id(e n ) Ú mit id(e i ) als Identifikationsschlüssel des Objektes e i vom Typ T i, also e i aus ext(t i ) DB-2-19 Beispiel 1: Beziehungstypen: Beispiele Studierender belegt Vorlesung Beziehungsmenge: belegt (Wirth, Algorithmen und Datenstrukturen) belegt (Wirth, Programmieren I) belegt (Kant, Grundlagen der Philosophie) belegt (Bernoulli, Mathematik I) Beispiel 2: Beziehungstyp Einkauf: Einkauf = Kunde:Person, Kauf:Ware, Verkäufer:Händler Ú Ausprägungsbeispiele: Ueli, Milch, Migros Ú Christoph, Käse, Coop Ú Beispiel 3: Beziehungstyp verheiratet_mit: verheiratet_mit = Ehefrau:Person, Ehemann:Person Ú Ausprägungsbeispiele Regula, Urs Ú Regula, Beat Ú DB

11 Beziehungsattribute Beispiel 3 zeigt, dass Verfeinerungen von Beziehungen nötig sind (weitere Arten von Beziehungen) Beziehungsattribut: Zusätzlich zur Angabe der beteiligten Entitätstypen können weitere Merkmalsfunktionen (Attribute) wie bei Entitätstypen zur näheren Beschreibung einer Beziehung herangezogen werden (z.b. die Vorratsmenge, die von einem Produkt in einem Lager vorhanden ist, oder die Note, die ein Student in einem Prüfungsfach erreicht hat). Beispiel 3*: Beziehungstyp verheiratet_mit*: verheiratet_mit = Ehefrau:Person, Ehemann:Person, Hochzeit:Datum, Scheidung:Datum Ú Ausprägungsbeispiele Regula, Urs, , Ú Regula, Beat, , Ú DB-2-21 Graphische Darstellung von Beziehungen Symbol: Entity-Type 1 RoleName1 Relship-Type RoleName2 Entity-Type 2 A 1... A n Beispiel Employee Manager Manages Department StartDate DB

12 Mehrstellige Relationen Relationen können auch mehrstellig sein, d.h. mehr als zwei Entitätstypen verbinden (ternäre Relationen, vierstellige Relationen, etc.) Dozent Buch empfiehlt Vorlesung Ausprägung: empfiehlt (Schuldt, Kemper&Eickler-Datenbanksysteme, Datenbanken) empfiehlt (Vetter, Mössenböck-Sprechen Sie Java?, Programmieren I) empfiehlt (Kant, Kritik der reinen Vernunft, Philosophie I) DB-2-23 Schlüssel in Beziehungstypen Schlüssel eines Beziehungstyps: Eine Teilmenge K der Vereinigung K i der Identifikationsschlüssel K 1,..., K n der betroffenen Entitätstypen T 1,..., T n heisst Schlüssel(-kandidat) des Beziehungstyps B, wenn sich zu jedem Zeitpunkt je zwei verschiedene Beziehungen b und b von ext(b) bezüglich K unterscheiden müssen, und es keine echte Teilmenge von K gibt, die diese Eigenschaft hat. Falls mehrere Schlüsselkandidaten existieren, wird einer zum Identifikationsschlüssel von B erklärt. DB

13 Schlüssel in Beziehungstypen Beispiel 1: Beziehungstyp: Lagerung = Lagerprod:Produkt, Lagerort:Ort Ú PNr ist ein Schlüsselkandidat von Lagerung, falls ein Produkt immer nur an einem Ort gelagert wird. Andernfalls ist {PNr,OrtNr} ein Schlüsselkandidat von Lagerung. Beispiel 2: Schlüssel? Studierender Prüfling Prüfung Prüfer Professor Mat.-Nr. Note Vorlesung Prüfungsfach Name Nummer DB-2-25 Objekttyp oder Beziehungstyp? Grundsätzlich gilt, dass jeder Beziehungstyp mit Attributen auch als Entitätstyp eingeführt werden könnte. Beispiel: Kunden (KNr) bestellen Produkte (PNr) zu einem bestimmten Datum in einer bestimmten Menge. Es sollen fortlaufend die Bestellungen nummeriert werden (BestNr) Variante 1: Kunde Bestellung Produkt Datum Menge BestNr Nachteile/Fehler? DB

14 Beziehungstyp wird Objekttyp Variante 2: Einführung eines Entitätstyps Bestellungen Regel: Eine komplizierter, durch viele Attribute beschriebener Beziehungstyp sollte besser in einen Entitätstyp überführt werden; dann werden nur einfache binäre Beziehungen zwischen den ursprünglichen Entitätstypen und dem neuen Entitätstyp benötigt DB-2-27 Kardinalitätsrestriktionen Schritt 4: Festlegung der Arten der Beziehungstypen, also zusätzliche einfache Integritätsbedingungen Kardinalitätsbedingungen: Eine Kardinalitätsbedingung (cardinality constraint) für die Teilnahme eines Entitätstyps E in einem Beziehungstyp B legt fest, wie häufig eine Entität vom Typ E in B mindestens vorkommen muss (minimale Kardinalität) und/oder wie häufig sie höchstens vorkommen darf (maximale Kardinalität). In einem ER-Diagramm wird die Kante zwischen einem Entitätstyp E und einem Beziehungstyp B mit (min,max) annotiert, wobei min die minimale und max die maximale Kardinalität bezeichnen. Wenn die maximale Kardinalität nicht spezifiziert wird, steht für max das Symbol * ( don t care ). DB

15 Beispiel zu Kardinalitätsrestriktionen (1,1) works-for (2,*) Employee Department (0,1) manages (1,1) DB-2-29 Beispiel zu Kardinalitätsrestriktionen Beispielausprägung zu ERM-Diagramm der vorigen Seite: works-for Employee Department manages DB

16 Gegenüberstellung üblicher Sprechweisen In der Praxis sind für die minimale Kardinalität meist nur die Werte 0 ( optional participation ) und 1 ( mandatory participation ) relevant, für die maximale Kardinalität nur die Werte 1 und *. Die Teilnahme von E 1 in R heisst optional, falls die minimale Kardinalität von E 1 in R null ist und obligatorisch sonst. Gegenüberstellung: Art der Beziehung R zwischen E 1 und E 2 (Kurzform) Kardinalität von E 1 in R Kardinalität von E 2 in R 1 : 1 Beziehung (0,1) oder (1,1) (0,1) oder (1,1) 1 : N Beziehung (0,*) oder (1,*) (0,1) oder (1,1) N : 1 Beziehung (0,1) oder (1,1) (0,*) oder (1,*) M : N Beziehung (0,*) oder (1,*) (0, *) oder (1,*) DB :1-Beziehung (one-to-one-relationship) Angestellter leitet (0,1) (1,1) Abteilung Charakteristik: Jedes Objekt aus dem linken Entitätstyp steht in Beziehung zu keinem oder genau einem Objekt aus dem rechten Entitätstyp und umgekehrt. Im Beispiel hat jede Abteilung genau einen Leiter und kein Angestellter leitet mehrere Abteilungen DB

17 m:1-beziehung (many-to-one-relationship) Angestellter arbeitet_in (1,1) (2,*) Abteilung Charakteristik: Jedes Objekt auf der "many"-seite steht in Beziehung zu höchstens einem Objekt auf der "one"-seite (im Allgemeinen nicht umgekehrt) Jeder Angestellte arbeitet in genau einer Abteilung; in jeder Abteilung arbeiten beliebig viele Angestellte (aber mindestens zwei) DB-2-33 m:n-beziehung (many-to-many-relationship) Studierender belegt (1,*) (1,*) Vorlesung Charakteristik: Jedes Objekt auf der linken Seite kann zu mehreren Objekten auf der rechten Seite in Beziehung stehen (d.h. keine Einschränkung) Beispiel-Ausprägung: belegt (Wirth, Algorithmen und Datenstrukturen) belegt (Wirth, Programmieren I) belegt (Kant, Grundlagen der Philosophie) belegt (Bernoulli, Mathematik I) belegt (Euler, Mathematik I) DB

18 Umwandlung Beziehungstyp in Objekttyp & binäre Beziehungstypen Ein n-ärer Beziehungstyp R zwischen n Entitätstypen E 1,..., E n kann immer als eigenständiger Entitätstyp R und n binären Beziehungstypen zwischen R und E i (1 i n) dargestellt werden, wobei für R ein neuer künstlicher Identifikationsschlüssel eingeführt wird. (0,*) (0,*) Buyer Trade Commodity (0,*) Seller DB-2-35 Umwandlung Beziehungstyp in Objekttyp & binäre Beziehungstypen (0,*) (1,1) (1,1) (0,*) Buyer buys Trade what Commodity (1,1) sells (0,*) Seller DB

19 Rekursive Beziehungstypen Ein Beziehungstyp kann auch zwei oder mehr gleiche Entitätstypen verbinden. Er heisst dann oft rekursiver Beziehungstyp. Hierzu muss man Rollennamen für die jeweilige Rolle des Entitätstyps einführen. Rekursive Beziehungstypen können ebenfalls Attribute besitzen Angestellter Bauteil (0,1) (0,*) (0,*) (0,*) Untergebener Vorgesetzter Oberteil Unterteil Dienstverhältnis Stückliste Anzahl UT DB-2-37 Beispiel Rekursive Beziehungstypen welche Vorlesung wofür (0,*) (0,*) Voraussetzung Ausprägung: Voraussetzung (Programmieren I, Algorithmen und Datenstrukturen) Voraussetzung (Programmieren II, Programmieren I) Voraussetzung (Programmieren II, Algorithmen und Datenstrukturen) Voraussetzung (Logik, Grundlagen der Philosophie) DB

20 Schwacher Entitätstyp (Weak Entity Type) Ein Entitätstyp W heisst schwach (weak), wenn er in einer strengen hierarchischen Beziehung zu einem Entitätstyp S steht, d.h. bei Kardinalität (1,1), und wenn zur Identifikation der Entitäten von W der Primärschlüssel des Entitätstyps S herbeigezogen wird (er nicht allein existenzfähig ist). Gebäude Geb.Nr. Gebäude Geb.Nr. (1,*) liegt_in (1,1) Raum RaumNr. Raum RaumNr. Ursprüngliche Notation nach Chen vereinfachte Notation DB-2-39 Beispiel (die etwas vereinfachte Universität) Die Mitglieder einer Universität setzen sich aus Studierenden und Angestellten zusammen. Angestellte sind entweder Professoren oder Assistierende. Die Fakultätsbibliotheken (charakterisiert durch den Namen der Fakultät) besitzen mehrere Dokumente. Dies können entweder Master-Arbeiten, Dissertationen oder Lehrbücher sein. Alle Dokumente besitzen eine eindeutige Signatur, einen Titel und ein Erscheinungsjahr. Dokumente werden natürlich von Personen verfasst und können von Universitäts-Mitgliedern entliehen werden (mit einem Ausleih- und Rückgabedatum). Jede Fakultätsbibliothek wird von genau einem Uni-Mitglied geleitet Master-Arbeiten werden von mindestens einem Assistierenden betreut; es gibt aber auch Assistierende ohne Betreuungsaufgaben. Dissertationen werden von Professoren betreut und bewertet. Zu jeder Dissertation gibt es genau einen Betreuer und zwei bis fünf Professoren, welche die Arbeit bewerten. Lehrbücher werden von Professoren im Rahmen ihrer Vorlesungen empfohlen DB

21 Beispiel: Modellierung in EERM DB-2-41 UML In den letzten Jahren hat sich UML als Modellierungssprache durchgesetzt, hauptsächlich wegen der ganzheitlichen Modellierung von Software (durch die Unterstützung der unterschiedlichen Diagrammtypen) Unterschiede zum ERM (EERM): Attribute werden direkt im Entity-Kasten notiert Es existiert kein eigenes Symbol für Relationships (nur eine Kante zwischen den Kästchen) Ausnahme: ternäre/mehrstellige Relationships mit Raute Verschiedene Vererbungsbeziehungen Notation der Kardinalitäten (an gegenüberliegender Seite) (Methoden: Nicht gebraucht bei DB-Modellierung) Angestellter Personalnr: int Name: string arbeitet in 0..* 1 Abteilung Abteilungsnr: int Bezeichn: string DB

22 UML: Komplette Spezifikation von Attributen In der vollständigen Form lautet die Syntax eines Attributs in UML wie folgt (eckige Klammern bezeichnen dabei optionale Angaben) [Sichtbarkeit] Name [Multiplizität] [: Typ] [= Anfangswert] [{Änderbarkeit}] [{Zusicherung}] Beispiel (Rechteck): Rechteck + Name : String {frozen} Farbe : {rot, gruen, blau} = gruen # Eckpunkt [4.. 4] {ordered} : Punkt - Kante_x : Integer {changeable} {Kante_x > 0} - Kante_y : Integer {changeable} {Kante_y > 0} / Flaecheninhalt : Integer { Flaecheninhalt = Kante_x * Kante_y} DB-2-43 UML: Assoziationen und reflexive Assoziationen UML-Notation für Assoziationen Reflexive Assoziation (auch als rekursive Assoziation bezeichnet) DB

23 UML: Kardinalitäten von Assoziationen... Die Kardinalität einer Assoziation gibt an, mit wie vielen Objekten des gegenüberliegenden Entitätstyps ein Objekt assoziiert sein kann. Diese Angabe ist auf beiden Seiten einer Assoziation möglich. Hierzu wird dieselbe Notation wie für die Multiplizität von Attributen verwendet UML-Notation für Kardinalitäten Anzahl der Klasse_1-Objekte, die ein Klasse_2-Objekt kennt Anzahl der Klasse_2-Objekte, die ein Klasse_1-Objekt kennt DB UML: Kardinalitäten von Assoziationen... Arten von Assoziationen: Beispiele: Zwischen einem beliebigen B-Objekt und einem Objekt der Klasse A gibt es: Genau eine Beziehung (Muss-Beziehung) null, eine oder beliebig viele Beziehungen (Kann-Beziehung) Null oder eine Beziehung (Kann-Beziehung) Eine oder mehrere Beziehungen (Muss-Beziehung) DB

24 ... UML: Kardinalitäten von Assoziationen... Beispiele (Fortsetzung): Zwischen einem beliebigen B-Objekt und einem Objekt der Klasse_A gibt es: Drei oder mehr als drei Beziehungen (Muss-Beziehung) Null bis fünf Beziehungen (Kann-Beziehung) Genau vier Beziehungen (Muss-Beziehung) Eine, drei oder fünf Beziehungen (Muss-Beziehung) Nicht keine, nicht fünf, sechs oder acht Beziehungen (Muss-Beziehung) DB UML: Kardinalitäten von Assoziationen Beispiel Ein Kunde kann mehrere Zahlungsverzüge besitzen, aber jeder Zahlungsverzug gehört zu genau einem Kunden DB

25 UML: Assoziationsnamen Assoziationen können benannt werden; dies ist in jeder Richtung mit einem unterschiedlichen Bezeichner möglich Zusätzlich zum Namen der Assoziation wird dann mittels eines bzw. angegeben, in welcher Richtung dieser Name angewandt werden muss Beispiel: benannte Kann-und Muss-Assoziationen Ein Kunde kann beliebig viele Aufträge erteilen, ein Auftrag gehört jedoch zu genau einem Kunden DB-2-49 UML: Rollen... Eine Rolle beschreibt, welche Funktion ein Objekt in einer Assoziation übernimmt Die Rolle wird an die Assoziation, auf der Seite der jeweiligen Entität geschrieben Beispiel: Eine Firma besitzt als Arbeitgeber mehrere Mitarbeiter (Arbeitnehmer). Jeder Mitarbeiter kann einen PKW als Dienstwagen fahren. DB

26 ... UML: Rollen Rollennamen können natürlich auch in einer reflexiven Assoziation angegeben werden Zusätzlich sind immer auch (nicht nur bei reflexiven Assoziationen) Zusicherungen (assertions) möglich, die an die Assoziation geheftet werden Beispiel: Sowie Chef als auch Mitarbeiter sind Angestellte; allerdings besitzt der Chef ein höheres Gehalt als der Mitarbeiter DB-2-51 Ternäre Assoziationen, n-gliedrige Assoziationen... Neben den (normalen) binären Assoziationen, die zwei Entitätstypen verbinden, gibt es auch Assoziationen, die drei oder mehrere Entitätstypen verbinden (ternäre bzw. n-gliedrige Assoziationen). Als grafisches Element für n-gliedrige Assoziationen steht eine Raute zur Verfügung, die mit den beteiligten Entitätstypen durch Linien verbunden ist DB

27 ... Ternäre Assoziationen, n-gliedrige Assoziationen Beispiel für eine ternäre Assoziation: Reservierung eines Sitzplatzes in einem Zug. Reservierung besteht aus einem Fahrgast, einem Zug und einem Platz in diesem Zug. Ein Platz in einem Zug kann (nacheinander) von mehreren Fahrgästen reserviert werden, ein Fahrgast hat in einem Zug genau eine Platzreservierung und ein Fahrgast kann einen Platz in mehreren Zügen reservieren. DB-2-53 Beispielmodell (Folien #DB-2-40 und #DB-2-41) in UML DB