fbi h_da Datenbanken Kapitel 2: Semantische Datenmodellierung Kapitel 2-1 Datenbanken 1 (Bachelor)

Transkript

1 Datenbanken Kapitel 2: Semantische Datenmodellierung Kapitel 2-1

2 Semantische Datenmodellierung Inhalte des Kapitels Die Rolle der Datenmodellierung im Lifecycle von Informationssystemen Das erweiterte Entity-Relationship Modell (eerm) Unterschiedliche Nomenklaturen für ER-Diagramme Lernziele Verständnis für den strategischen Stellenwert der semantischen Datenmodellierung mit Hilfe von ER-Diagrammen in der Analyse-Phase Analogien und Unterschiede zum OOA-Klassendiagramm kennen Sensibilisierung für unterschiedliche Nomenklaturen und die damit zusammenhängende Änderung der semantischen Aussage Unter Semantik (gr. σημαίνειν sēmainein bezeichnen ) versteht man die Lehre über die Bedeutung von Zeichen, also im Speziellen von allen sprachlichen Äußerungen. Insbesondere in der Analysephase ist es wichtig, bei der Beschreibung der Anforderungen, der Wahl der Bezeichner etc. vollständige semantische Klarheit zu erreichen! Kapitel 2-2

3 Die Rolle der Datenmodellierung im Lifecycle von Informationssystemen Vor der Einführung der OOA / OOD, mit UML als standardisierter Beschreibungssprache ab 1997, war die Sicht auf Daten und Prozesse getrennt auch hinsichtlich der eingesetzten Methodiken: eer-modell ER Diagramme, Chen 1976 Relationenmodell (für RDBMS, Codd 1970) SQL (für RDBMS, Codd 1970) James Martin, 1982 strukturierte Analyse de Marco 1979 strukturierter Entwurf Constantine, Jackson 1974/75 strukturierte Programmierung Dijkstra 1970 Kapitel 2-3

4 Lifecycle von Informationssystemen Evolutionäre Vorgehensmodelle entsprechen einem zyklischen, iterativen Durchlaufen der einzelnen Phasen Jede Phase liefert Ergebnisse, die als Input für die darauf folgende Phase Verwendung finden: Planungsphase Der Informationsbedarf der zu untersuchenden Organisation wird ermittelt und eine Informationsstrategie erarbeitet. Beispiel: CRUD-Matrix (Create Read Update Delete) Ergebnis: Informations-Projekte (=Zusammenfassung von Funktionen, die die gleichen Informationsobjekte verwenden) und Funktionsbereiche sind definiert, um den vorgegebenen Organisationsbereich zu strukturieren. Kapitel 2-4

5 Lifecycle von Informationssystemen Ausschnitt aus einer CRUD-Matrix Planungsphase Funktionen Kunden verwalten Auftrag abwickeln Bestellung erstellen Auftrag abrechnen Lieferanten verwalten Bestellung abrechnen Wareneingang überwa Entitäten Kundenaufträge Beschaffung Kunde CRUD R R Auftrag CRUD R Auftragsposition CRUD R Kundenrechnung CRU Kundenrechnungsposition CRUD Artikel R R R R R Lieferant CRUD R R R L-Bestellung CRUD R R L-Bestellungsposition CRUD R R L-Rechnung CRU L-Rechnungsposition CRUD Wareneingangbuch CRU Kapitel 2-5

6 Lifecycle von Informationssystemen Analysephase Die Informations-Projekte aus der Planung werden sowohl aus Daten- als auch aus Prozess-Sicht weiter detailliert. Zu jedem Zeitpunkt der Analyse- und auch der darauf folgenden Designphase muss darauf geachtet werden, dass Daten- und Prozessmodell zueinander konsistent sind. Ergebnis: Datenmodell (eer-diagramm) und Prozessmodell (Analysesicht) liegen vor. Kapitel 2-6

7 Lifecycle von Informationssystemen Designphase Während man sich in der Analysephase ausschließlich mit einer logischen Sicht auf die Daten beschäftigt, wird diese während der Designphase sowohl durch die Berücksichtigung des Datenbankmodells als auch der Implementierungsplattform (DBMS) ergänzt: Implementierung der Beziehungen durch Definition von Referenzen Festlegung der Datentypen (DBMS-spezifisch) Mit Hilfe von CASE-Tools *) können Datenmodelle der Designsicht aus Datenmodellen der Analysesicht generiert werden (und umgekehrt: Round-Trip-Engineering). Ergebnis: Datenmodell (z.b. Relationenmodell, ergänzt um Datentypen des Ziel- DBMS beim Einsatz von RDBMS) und Prozessmodell der Designsicht liegen vor. *) CASE = computer aided software engineering Kapitel 2-7

8 Lifecycle von Informationssystemen Implementierungsphase Die Güte von Analyse und Design zeigen sich in einer relativ problemlosen Implementierung. Im Falle eines RDBMS erfolgt die Implementierung eines Datenbankschemas durch die deklarative Sprachkomponente von SQL (SQL DDL). Beim Einsatz von CASE-Tools ist es möglich, das SQL-Skript für ein spezifisches RDBMS direkt aus den Informationen des Relationenmodells zu generieren. Welche Diagrammtypen der UML können Sie im Fall eines objektorientierten Systems den einzelnen Phasen zuordnen? Kapitel 2-8

9 Semantische Datenmodellierung Die Rolle der Datenmodellierung im Lifecycle von Informationssystemen Das erweiterte Entity-Relationship Modell (eerm) Unterschiedliche Nomenklaturen für ER-Diagramme Kapitel 2-9

10 Das Entity-Relationship Modell ERM Das Entity-Relationship Modell wurde von Chen*) erstmals 1976 vorgestellt. CODASYL Oracle (1979) IMS/VS seit 1968 (IBM) System R (1977) DB2 (1983 unter MVS) Hierarchisches Datenbankmodell Netzwerk Datenbankmodell (1971, Data Base Task Group) Relationales Datenbankmodell (1970, Edgar F. Codd) UML Unified Modeling Language wird 1997 von der OMG als Standard akzeptiert *) Chen P. P-S. The Entity-Relationship Model Towards a Unified View of Data. ACM Transactions of Database Systems (March 1976), 1(1):9-36 Kapitel 2-10

11 Das Entity-Relationship Modell ERM A data model, called the entity-relationship model, is proposed. This model incorporates some of the important semantic information about the real world. A special diagrammatic technique is introduced as a tool for database design. An example of database design and description using the model and the diagrammatic technique is given. Some implications for data integrity, information retrieval, and data manipulation are discussed. The entity-relationship model can be used as a basis for unification of different views of data: the network model, the relational model, and the entity set model. Semantic ambiguities in these models are analyzed. Possible ways to derive their views of data from the entity-relationship model are presented. Anfang des Abstracts zu o.g. Artikel von P.P-S. Chen, 1976 Kapitel 2-11

12 Das Entity-Relationship Modell ERM Ziele des von Chen 1976 vorgestellten ERM: Modellierbarkeit semantischer Informationen aus der realen Welt Schaffung einer Grundlage zur Analyse von Netzwerkmodell Relationenmodell und Entity-Set Model. Das ERM von Chen zeichnet sich aus durch seine Unabhängigkeit von spezifischen Datenbankmodellen. Der Entwurf eines ER-Modells findet in der Analysephase des SW-Lifecycle statt. Kapitel 2-12

13 ERM Der Entity-Typ (Entity-Type) Zur visuellen Beschreibung der Struktur von Objekten der realen Welt und der Beziehungen dieser Objekte untereinander verwendet man Diagramme, in denen die entsprechenden Komponenten graphisch dargestellt werden: Eine Entität (entity) ist ein Objekt der realen Welt. Der Entity-Typ (entity type) ist der Repräsentant aller Objekte gleichen Typs. Grafische Notation: Rechteck, das den Namen des Entity-Typs enthält: Produkt Produkte Der Name eines Entity-Typs ist stets ein Substantiv, das im Singular verwendet wird. Ein Entity-Typ, der die Struktur einer Produkt-Instanz repräsentieren soll, erhält also den Namen Produkt (und nicht Produkte!). Kapitel 2-13

14 ERM Der Entity-Typ (Entity-Type) Hinweis: Der Begriff Entity-Typ entspricht der Schemadeklaration einer Klasse in der UML und wird bei der Datenmodellierung, auch bei CASE- Tools, häufig dem Begriff Entität (Entity) gleichgesetzt. Genau genommen entspricht der Begriff der Entität jedoch einer einzelnen Instanz eines Enitity-Typs, so wie ein Objekt einer einzelnen Instanz einer Klasse entspricht. Toolbar und Zeichencanvas zur Modellierung eines konzeptionellen Datenmodells Power Designer 12.5 Kapitel 2-14

15 ERM Der Beziehungstyp (Relationship-Type) Eine Beziehung (Relationship, Assoziation) beschreibt, ob und wie Entitäten untereinander assoziiert sind. Der Beziehungstyp (relationship type) ist der Repräsentant aller Beziehungen gleichen Typs. Grafische Notation (in CASE-Tools eher selten unterstützt): Raute, die den Namen des Beziehungstyps oder eine (numerische) Referenz auf den Bezeichnertext enthält. Bestellung oder 1 1 = Bestellung Produkt Bestellung Kunde Kapitel 2-15

16 ERM Der Beziehungstyp (Relationship-Type) Hinweis: Der Begriff Beziehungstyp entspricht dem Begriff der Beziehung zwischen Klassen in der UML und wird bei der Datenmodellierung, auch bei CASE-Tools, häufig dem Begriff Beziehung (Relationship bzw. Association) gleichgesetzt. Im allgemeinen Fall wird eine Beziehung in den meisten CASE-Tools zunächst als Verbindungslinie zwischen zwei Entity-Typen dargestellt. Produkt Bestellung Kunde Toolbar und Zeichencanvas zur Modellierung eines konzeptionellen Datenmodells Power Designer 12.5 Kapitel 2-16

17 ERM Attribute Attribute beschreiben die Eigenschaften von Entity- oder Beziehungstypen. Grafische Notation: Abgerundetes Rechteck oder Oval, das den Attributnamen enthält. Produkt Bestellung Kunde Bestelldatum Vorname Nachname Attribute, die in dieser Form in ER-Diagrammen dargestellt werden, zeigt man aus Übersichtlichkeitsgründen oft nur optional mit an. Kapitel 2-17

18 ERM n-äre Beziehungen Entsprechend der Anzahl n der an einer Beziehung beteiligten Entity-Typen spricht man von n-stelligen oder auch n-ären Beziehungen, n 2. Im Fall n = 2 nennt man die Beziehung 2-stellig oder auch binäre Beziehung und spezialisiert den Fall, dass die Beziehung rekursiv sein kann. 3-stellige Beziehungen nennt man auch ternäre Beziehungen. Die Raute als Symbol für eine Beziehung ist besonders gut geeignet, n-äre Beziehungen für n 3 darzustellen. Produkt Bestellung Kunde 1 1 = Komponentenbeziehung Lieferung Wie stellen Sie ternäre Beziehungen in der UML dar? Kapitel 2-18

19 ERM Kardinalitäten Mit der Kardinalität*) min:max kennzeichnet man die minimal und maximal mögliche Anzahl von Instanzen eines Entity-Typ, die mit einer bestimmten Instanz eines anderen Entity-Typ in Beziehung stehen. Als Wert für beliebig viele verwendet man Buchstaben wie m und n. Ursprünglich verwendete Chen in seinen Diagrammen bei der Angabe von Kardinalitäten nur die Obergrenze! 1 Kunde bestellt mindestens 1, aber beliebig viele Produkte Produkt N oder 1:N Bestellung 0:M oder M Kunde 1 Produkt wird von möglicherweise keinem aber beliebig vielen Kunden bestellt. *) Die Zuordnung der Kardinalitäten (in der UML auch Multiplizitäten genannt) zu den Entitäten wird u. U. auch in umgekehrter Reihenfolge vorgenommen. Vgl. hierzu den Abschnitt Unterschiedliche Nomenklaturen zu ER-Diagrammen. Kapitel 2-19

20 ERM Kardinalitäten Hinweis: In vielen CASE-Tools zur ER-Modellierung werden die Kardinalitäten mit der Krähenfuß-Nomenklatur nach James Martin bezeichnet (engl. crawfood-darstellung): Entität = maximal ein Entität = genau ein kein oder ein ein und nur ein Entität kein oder mehrere = beliebig viele Entität = mindestens ein ein oder mehrere Kapitel 2-20

21 ERM Kardinalitäten im Power Designer In vielen CASE-Tools wird die binäre Darstellung zwischen zwei Entity- Typen ohne ein explizites Assoziationssymbol dargestellt. Die Kardinalitäten werden häufig mit der Krähenfuß-Notation angezeigt: Im Power Designer wird bei der 0:1-Notation auf die Darstellung der 1 verzichtet! Haben Assoziationen eigene Attribute, so werden sie als eigene (schwache) Entity-Typen dargestellt (s. 2/23). Kapitel 2-21

22 ERM schwache Entitäten Entitäten, die nicht alleine, sondern nur in Abhängigkeit von der Existenz anderer Entitäten existieren können, nennt man schwache Entitäten weak entities und spricht auch von abhängigen Beziehungen dependent Relationships. Die Entity-Typen schwacher Entitäten werden in der Nomenklatur nach Chen durch ein Rechteck mit doppelter Linie gezeichnet. Von der Raute auf den schwachen Entity-Typ deutet ein Pfeil: Student 1 Nachweis Bewertung Student Nachweis Bewertung Im Power Designer ändert sich bei Abhängigkeit (= Dependency) die grafische Darstellung der entsprechenden Kardinalität! Analogie zu schwachen Entitäten im UML-Klassendiagramm (Analysesicht)? Kapitel 2-22

23 Assoziationen mit eigenen Attributen Assoziationen, die selbst Attribute besitzen oder Beziehungen zu anderen Entity-Typen haben, werden als schwache Entitäten dargestellt: Produkt ProduktNr ProduktBezeichner Preis <pi> I VA20 MN8,2 Kunde KundenNr KundenNachname <pi> I VA20 ProduktToBestellung Bestellung BestellDatum D KundeToBestellung Wie nennt man die Analogie hierzu im UML-Klassendiagramm (Analysesicht)? Kapitel 2-23

24 ERM Hörsaalübung Zeichnen Sie ein ER-Diagramm, das die angegebenen Entity-Typen und deren Beziehungen untereinander darstellt. Verwenden Sie zur Darstellung der Beziehungstypen das Rautensymbol. Entity-Typen Klassen Mitarbeiter Abteilung Projekt Beziehungstypen Beziehungen Jeder Mitarbeiter arbeitet in genau einer Abteilung, in jeder Abteilung arbeiten mehrere Mitarbeiter. Jede Abteilung hat genau einen Mitarbeiter, der der Leiter dieser Abteilung ist. Jeder Mitarbeiter arbeitet in keinem, einen oder mehreren Projekten mit. Für einen Mitarbeiter ist seine Rolle in jedem Projekt bekannt, an dem er beteiligt ist. Jedes Projekt ist genau einer Abteilung zugeordnet. Gibt es Unterschiede zur objekt-orientierten Modellierung von Klassen und Beziehungen (UML-Klassendiagramm)? Kapitel 2-24

25 Das erweiterte ER Modell eerm Vererbung Die spezielle Beziehungsstruktur einer Vererbungshierarchie Inheritance wurde als Erweiterung der ursprünglichen ERM in Anlehnung an entsprechende objektorientierte Konzepte ergänzt. Man spricht auch von Generalisierung / Spezialisierung oder von ist-ein Beziehung Ein Wurzel-Entity-Typ stellt jeweils den Supertyp dar, der diejenigen Attribute und Beziehungen enthält, die alle seine Subtypen (Spezialisierungen) gemeinsam haben. Alle Subtypen werden dann nur noch durch spezifische Attribute oder auch durch spezifische Beziehungen zu anderen Entity-Typen beschrieben, die sie von den anderen Subtypen unterscheiden. Welche constraints der UML kennen Sie im Zusammenhang mit der Darstellung von Vererbungshierarchien? Kapitel 2-25

26 eerm Vererbung Geschäftspartner Händler Spediteur Kunde Veranstalter Man unterscheidet zwischen den folgenden Spezialisierungsformen: Totale Spezialisierung: Jede Instanz des Supertyps entspricht mindestens einem Subtyp. Insbesondere überdeckt die Menge aller Subtypen alle Instanzen des Supertyps (Darstellung: Doppelstrich, s.o.). Partielle Spezialisierung: Nicht jede Ausprägung des Supertyps wird notwendig spezialisiert (Darstellung: einfacher Strich ). Kapitel 2-26

27 eerm Vererbung Disjunkte Spezialisierung: Die Teilmengen der Instanzen aller Spezialisierungen sind disjunkt (Darstellung: D = disjoint im Dreickessymbol), andernfalls erlaubt man Überlappende Spezialisierung (Darstellung: O = overlapping im Dreieckssymbol) D O Toolbar und Zeichencanvas zur Modellierung einer Vererbungshierarchie im konzeptionellen Datenmodell Power Designer 12.5 Die Unterschiedung zwischen totaler und. partieller Spezialisierung bzw. zwischen disjunkten und überlappenden Spezialisierungen ist hier möglich durch Setzen der beiden folgenden Eigenschaften: mutually exclusive disjoint complete Kapitel 2-27

28 Primärschlüssel Um einzelne Entitäten voneinander unterscheiden und identifizieren zu können, wird ein so genannter Primärschlüssel (Primary Key) eingeführt: Ein Attribut oder eine Kombination von Attributen heißt Primärschlüssel p, wenn gilt: 1. Der Wert von p definiert die Attributwerte aller anderen Attribute der Entität eindeutig. 2. Man kann (im zusammengesetzten Fall) kein Attribut aus p entfernen, ohne dass 1. verletzt wird. Besteht der Schlüssel aus einer Kombination mehrerer Attribute, so spricht man von einem zusammengesetzten Schlüssel - concatinated key. Graphische Notation: Der Primärschlüssel ist einfach (oder doppelt) unterstrichen in der Attributliste: Buch (ISBN, Titel, ) Buch ISBN Kapitel 2-28

29 Candidate Key Gibt es in einem Entity-Typ mehrere Schlüssel, von denen jeder die Rolle des Primärschlüssels übernehmen kann, so nennt man diese candidate keys (alternative Primärschlüssel) und wählt einen von ihnen als Primärschlüssel des Entity-Typs aus. Der Begriff concatinated gilt analog für candidate keys. Beispiel: Personalstammdaten in einem Entity-Typ Person Person Sozialversicherungsnummer Gehalt Steuerklasse Personalnummer candidate key: Sozialversicherungsnummer primary key: Personalnummer Kapitel 2-29

30 Unterschiedliche Nomenklaturen für ER-Diagramme Erste Schema-Diagramme wurden in den 60er Jahren von Charles Bachmann 1) formalisiert: Er benutzte Rechtecke, um so genannte Record-Typen zu kennzeichnen, und Linien bzw. gerichtete Pfeile von einem Record-Typ zu einem anderen, um eine 1:1- bzw. 1:N-Beziehung unter den Instanzen des jeweiligen Typs zu kennzeichnen: Bachmann-Notation A B A B Vergleich: Chen-Notation A 1 1 B A 1 N B 1) Bachmann, C.W. Data Structure Diagrams. Databases 1, 2 (1969), pp Kapitel 2-30

31 Unterschiedliche Nomenklaturen (2) Bei jeder Schreibweise stellt sich die Frage nach Lesrichtung und Interpretation der Kardinalitäten (Multiplizitäten): Chen-Notation (analog UML-Lesrichtung und -Interpretation) Jede Instanz der Entität A ist zu 1 Instanz der Entität B assoziiert bzgl. R. A N 1 R B Jede Instanz der Entität B ist zu N Instanzen der Entität A assoziiert bzgl. R. min,max-notation Jede Instanz der Entität A ist in maximal 1 Beziehung vom Typ R zu Instanzen der Entität B enthalten. A (0,1) (0,n) R B Jede Instanz der Entität B ist in maximal n Beziehungen vom Typ R zu Instanzen der Entität A enthalten. Während die erste Notation die Anzahl der bzgl. R assoziierten Entitäten zählt, wird in der zweiten Notation die Anzahl der Beziehungen R gezählt, in denen eine Entität enthalten ist. Kapitel 2-31

32 Zusammenfassung Die ER-Modellierung legte bereits in den 60er Jahren die Grundlagen für das UML-Klassendiagramm in der Analysesicht (OOA). Neben zahlreichen Analogien zum UML-Klassendiagramm der OOA gibt es neben Unterschieden in der Nomenklatur den Begriff der schwachen Entität, sowie den Begriff des Primärschlüssels und der Candidate Keys. Das erweiterte ER-Modell eerm ermöglicht es, analog zur UML, Vererbungshierarchien zu beschreiben. Im Gegensatz zur standardisierten UML findet man in Diagrammen zur Datenmodellierung unterschiedliche Lesrichtungen bzgl. der Kardinalitäten. Hier stehen im direkten Gegensatz die Lesrichtung von ER-Diagrammen nach Chen und UML gegenüber der min,max-notation. Kapitel 2-32

33 Datenbanken Einführung Semantische Datenmodellierung 3. Relationenmodell 4. Interne Datenorganisation 5. SQL - Structured Query Language 6. Prozedurale Spracherweiterungen von SQL, Stored Procedure und Trigger, JDBC 7. Transaktionsmanagement Kapitel 2-33