Daten- und Informationsmodellierung

Transkript

1 Web Science & Technologies University of Koblenz Landau, Germany Grundlagen der Datenbanken Daten- und Informationsmodellierung Dr. Gerd Gröner Wintersemester 2013/14

2 Lernziele Kenntnis der Vorgehensweise beim DB-Entwurf Grundkonzepte von ER Modell und UML Klassendiagrammen für Kenntnis der Abstraktionskonzepte (Generalisierung, Aggregation) Fähigkeit zur praktischen Anwendung folgender Aspekte: Erstellung von Modellen für gegebene Anwendungsszenarien Festlegung der Primärschlüssel, Beziehungstypen, Kardinalitäten, Existenzabhängigkeiten etc. Interpretation gegebener Modelle 2

3 Wiederholung: Abstraktionsebenen des Datenbankentwurfs Konzeptuelle Ebene Wir sind hier! Wie sieht die Welt aus? Logische Ebene Physische Ebene Welche Strukturen werde von der Anwendung manipuliert? (Implementationsmodell) Wie wird gespeichert? 3

4 Datenbankentwurf 4

5 Allgemeine Vorgehensweise Design & Modellierung Implementierung Reales System Anforderungsermittlung und Analyse Konzeptioneller Entwurf (Informationsmodellierung) Logischer Entwurf (DB-Schema, externes Schema) Physischer Entwurf (internes Schemas) Anwendungserstellung, Systemintegration Informationssystem Auswertung Modifikationen Tests Evaluationen Verwendung 5

6 Informationsmodellierung Miniwelt Objekte Attribute Zusammenhänge Sachverhalte Informationen Gegenstände Personen Tatsachen Formalisierung Veränderungen, Vorgänge Beziehungen Darstellungselemente + Regeln: - Objekte und Beziehungen (Relationships) - Klassen von Objekten / Beziehungen - Eigenschaften (Attribute) Informationen über Objekte und Beziehungen nur wenn: - relevant - unterscheidbar und identifizierbar, selektiv beschreibbar 6

7 Anforderungsanalyse Vorgehen zur Erstellung einer Anforderungsspezifikation Diskussion mit zukünftigen Anwendern Ziel: Erstellung eines strukturierten Dokuments Bestandteile: Informationsstrukturanforderungen: mit Beschreibungen über Objekte (abstrahiert zu Objekttypen) Attribute (beschreiben Objekte) Beziehungen (zwischen Objekten, abstrahiert zu Beziehungstypen) Datenverarbeitungsanforderung Prozessbeschreibung (betrifft die Datenverarbeitung) 7

8 Anforderungsanalyse am Beispiel Szenario: Schönes UNiversitäRes InformationsSystEm (SUNRISE) Universität Angestellte Professoren Assistenten Studenten Vorlesungen Räume Bibliotheken Prüfungen Zeugnisse Welche Objekte? Welche Eigenschaften? Welche Beziehungen? Welche Prozesse? 8

9 Objektbeschreibung Uni-Angestellte Anzahl: 100 Attribute PersonalNummer Typ: char Länge: 9 Wertebereich Anzahl Wiederholungen: 0 Definiertheit: 100 % Identifizierend: ja Gehalt Typ: dezimal Länge: 8,2 Anzahl Wiederholungen: 0 Definiertheit: 10 % Identifizierend: nein Rang Typ: char Länge: 32 Anzahl Wiederholungen: 9 Definiertheit: 100 % Identifizierend: nein 9

10 Beziehungsbeschreibung: prüfen Beteiligte Objekte: Professor als Prüfer Student als Prüfling Vorlesung als Prüfungsstoff Attribute der Beziehung Datum Uhrzeit Note Anzahl: pro Jahr 10

11 Prozessbeschreibungen: Zeugniserstellung Häufigkeit: halbjährlich Benötigte Daten Prüfungen Studienordnungen Studenteninformation Priorität: hoch Zu verarbeitende Datenmenge 500 Studenten 3000 Prüfungen 10 Studienordnungen 11

12 Abstraktionskonzepte Informations- und Datenmodelle basieren auf drei grundlegenden Abstraktionskonzepten: Klassifikation: fasst Objekte (Entities, Instanzen) mit gemeinsamen Eigenschaften zu einem neuen (Mengen-) Objekt (Entity-Menge, Klasse, Objekttyp) zusammen. Instanzen/Objekte einer Klasse unterliegen gleicher Struktur (Attribute), gleichen Integritätsbedingungen, gleichen Operationen Mathematisch: Mengenbildungen Aggregation: Zusammenfassung potentiell unterschiedlicher Teilobjekte (Komponenten) zu einem neuen Objekt Mathematisch: Bildung von kartesischen Produkten Generalisierung: Teilmengenbeziehungen zwischen Elementen verschiedener Klassen Mathematisch: Bildung von Potenzmengen (bzw. Teilmengen) Wesentlich: Vererbung von Eigenschaften an Teilmengen 12

13 Entity-Relationship-Modell 13

14 ER-Modell Peter P-S. Chen (1976) The Entity-Relationship Model Toward a Unified View of Data, ACM TODS Elemente Entity: Gegenstände / Objekte Relationships: Beziehungen zwischen Entities Attribute: Eigenschaften Rollen: von Entities in Relationships Enitty vs. Enitätstyp Beziehung vs. Beziehungstyp Klassifikation 14

15 Grundlagen ER-Modell Entity Studenten Vorlesungen Dozenten Relationship hört liest Attribute Verbindungen Name MatNr Titel Schlüsselattribut Studenten hört Vorlesungen MatNr Name VorlNr Titel 15

16 Schlüssel Minimale Menge von identifizierenden Attributen eines Objekts {Matrikelnummer} {Vorname, Name, Geburtsdatum, Geburtsort} Oft künstlicher Schlüssel bestehend aus einem Attribute (Vorlesungsnummer, Kundennummer, Personalausweisnummer, ) Mehrere Schlüssel möglich; dann Auswahl eines Primärschlüssels 16

17 Relationships Binär: Studenten hört Vorlesungen Mehrstellig: Studenten Mit Eigenschaften: Dozenten prüft Dozenten Vorlesungen Studenten prüft Vorlesungen Note 17

18 Relationships Rollen Dozenten Studenten Prüfling prüft Prüfer Thema Vorlesungen Note Manchmal notwendig zur Klärung von Sachverhalten: voraus setzen Vorgänger Nachfolger Vorlesungen 18

19 Beispiel Bibliothek Bücher Standort Nutzer Ausleihe Entitäten, Beziehungen, Attribute, Rollen? 19

20 Relationships Formal E Menge aller Entity(typen) Ein n-stelliger Beziehungstyp R kann als Relation definiert werden: Wobei Bsp.: Rollen: Gilt E i = E j in einer Beziehung, so charakterisiert man die Entitäten durch Rollen: voraus setzen (Vorgänger: v 1, Nachfolger v 2 ) Vorgänger Nachfolger Vorlesungen 21

21 Funktionalität von Beziehungen Einschränkung der Zahl von Beziehungen eines Beziehungstyps, an der eine Entität beteiligt sein kann. (Funktions-) Eigenschaften der Relation Total vs. partiell Rechtseindeutig (sonst keine Funktion) Linkseindeutig (injektiv) Inverse (R -1 ) 22

22 1:1 Beziehungen Jeden Element aus E 1 ist höchstens einem Element aus E 2 zugeordnet und umgekehrt Rechtseindeutig, linkseindeutig, partiell Beispiel: 1:1 Beziehung hatpass Studenten 1 hatpass 1 Reisepass Studenten Reisepass 23

23 1:N Beziehungen Jeden Element aus E 1 kann beliebig viele Elemente aus E 2 zugeordnet sein, aber jedes Element aus E 2 nur einem Element aus E 1 (keine Funktion), linkseindeutig, partiell Beispiel: 1:N Beziehung leiht (Buchausleihe) Studenten leiht 1 N Buch Studenten Buch 24

24 N:1 Beziehungen Umgekehrter Fall zu 1:N rechtseindeutig, partiell Beispiel: N:1 Beziehung gehörtzu (Übungsgruppen) Studenten N gehörtzu 1 Gruppe Studenten Gruppe 25

25 N:M Beziehungen Keine Einschränkung Beispiel: N:M Beziehungen hört (Vorlesung) liest (Vorlesung) Studenten hört N M Vorlesung Studenten Vorlesung 26

26 Funktionalität mehrstelliger Beziehungen N-stellige Beziehung Steht an E i eine 1, so ist eine partielle Funktion, d.h. die Relation ist rechtseindeutig Dies gilt für alle Entitytypen mit einer 1 27

27 Beispiel 1 Bedeutung? Dozenten Studenten N 1 prüft M Vorlesungen Note Funktionen (Studenten, Vorlesungen) Dozenten Studenten werde für eine Vorlesung nur von einem Dozenten geprüft 28

28 Beispiel 2 Bedeutung? Studenten Dozenten M N prüft 1 Vorlesungen Note Funktionen (Studenten, Dozenten) Vorlesungen Dozent prüft einen Studenten in höchstens einer Vorlesung 29

29 Beispiel 3 Bedeutung? Studenten Dozenten 1 N prüft 1 Vorlesungen Note Funktionen (Studenten, Vorlesungen) Dozenten (Studenten, Dozenten) Vorlesungen Studenten werden von einem Dozenten nur einmal und für nur eine Vorlesung geprüft 30

30 Beispiel 4 Bedeutung? Studenten Dozenten 1 1 prüft 1 Vorlesungen Note Funktionen (Studenten, Vorlesungen) Dozenten (Studenten, Dozenten) Vorlesungen (Dozenten, Vorlesungen) Studenten Ein Dozent prüft eine Vorlesung für höchstens einen Studenten 31

31 Min-Max Notation Bisher: Funktionalitäten von Beziehungstypen Wichtig ist max. Anzahl: 1 oder N ( viele ) Geht das noch genauer? Min-Max Notation Gibt Unter- und Obergrenze an 32

32 Min-Max Notation (2) Genauere Spezifikation, wie viele Entitäten an einer Beziehung mindestens / höchstens teilnehmen dürfen 0: keine Entität erforderlich 1,2,3,4, : Zahlwert vorgegeben *: keine Einschränkung Studenten (0,*) (1,*) hört Vorlesungen 33

33 ERM-Beispiel: Begrenzungsflächendarstellung Polyeder 1 (4,*) Hülle N (1,1) Flächen N (3,*) Begrenzung PolyID FlächenID Fläche gehört zu 1 Polyeder, Polyeder hat mehrere Flächen Beispiel Polyeder (mit 6 Flächen) M (2,2) Kanten N (2,2) KantenID StartEnde M (3,*) Punkte X Y Z Tetraeder (4 Flächen) 34

34 Min-ERM-Beispiel: Begrenzungsflächendarstellung Hinweis zu Min-Max Notation: Notation ist kontra-intuitiv Polyeder 1 (4,*) Hülle N (1,1) Flächen PolyID FlächenID 35

35 Existenzabhängige Entitäten Entitäten, die in ihrer Existenz von einer anderen Entität abhängig sind (Oft) nur zusammen mit Schlüssel der übergeordneten Entität eindeutig identifizierbar übergeordnetes Entity Artikel N umfasst Kunde 1 N beauftragt M Bestellung KundenNr Beziehung entweder 1:1 oder 1:N (nie M:N) Datum 36

36 Darstellung Aggregation (part-of) Buch part-of part-of part-of Inhaltsverzeichnis Kapitel Index part-of part-of part-of Überschrift Abbildung Absatz 37

37 Darstellung Generalisierung (is-a) Name Menschen is-a Studenten Angestellte PersNr MatrNr is-a Wiss. Mitarbeiter Professoren Nichtwiss. MA 38

38 Arten von Spezialisierung X Superklasse is-a Y Z Subklassen disjunkte Spezialisierung (Partitionierung) Überlappende Spezialisierung X Y Z Y Z vollständig, disjunkt (complete, disjoint) Y Z X Y Z X vollständig, überlappend (complete, overlapping) X partiell, disjunkt (incomplete, disjoint) partiell, überlappend (incomplete, overlapping) 39

39 ER-Modell Ein ER-Modell für alles oft zu komplex Einzelne Sichten des Szenarios modellieren und dann schrittweise integrieren Entfernung von Redundanzen Entfernung von Widersprüchen Behandlung von Synonymen (Dozent, Lehrender) oder Homonymen (betreut Diplomarbeit, Doktorarbeit) 40

40 Sichtenintegration Konzeptueller Entwurf in einem Guss schwierig Mehrere Sichten, dann Integration zu globalem Schema Mögliche Sichten im Universitätsbeispiel Professorensicht Studentensicht Sicht der Universitätsleitung Sichten nicht notwendigerweise disjunkt Sicht 1 Sicht 2 Sicht 4 Sicht 3 Konsolidierung globales Schema 41

41 UML 42

42 Unified Modeling Language (UML) Standardisierte graphische Notation / Sprache zur Beschreibung objektorientierter Software und Software-Entwicklung Kombination unterschiedlicher Modelle bzw. Notationen, u.a. Booch Rumbaugh (OMT) Jacobson (Use Cases) Standardisierung durch Herstellervereinigung OMG (Object Management Group): 1997: UML : UML : UML 2.0 Infos: Literatur: J. Rumbaugh, I. Jacobson, Grady Booch:The Unified Modeling Language Reference Manual (2nd Edition) Addison-Wesley,

43 UML Bestandteile UML umfasst Modellelemente (Klassen, Interfaces, Anwendungsfälle,...) Beziehungen (Assoziationen, Generalisierung, Abhängigkeiten, ) Diagramme Software-Entwicklung Anwendungsfälle Anforderungen Aktivitäten Klassendiagramme Modularisierung Analyse Szenarien Sequenzdiagramme für uns wichtig Klassendiagramme verfeinert Entwurf Kooperations-, Zustandsdiagramme Komponentendiagramme Code (Klassendefinition) Implementierung Verteilungsdiagramme, Code (Methoden) Objektstruktur Objektverhalten 44

44 UML Diagrammtypen UML unterscheiden zwischen zwei wesentlichen Diagrammtypen Strukturdiagramme Verhaltensdiagramme Unter den Verhaltensdiagrammen gibt es noch einen speziellen Diagrammtyp, die Interaktionsdiagramme. Diagramm Strukturdiagramm Verhaltensdiagramm Interaktionsdiagramm 45

45 Übersicht Strukturdiagramme Zeigen die statische Struktur der Objekte des Systems Dargestellte Elemente sind unabhängig von der Zeit Elemente repräsentieren wichtige Konzepte des Systems Strukturdiagramm Klassendiagramm Objektdiagramm Paketdiagramm Kompositionsstrukturdiagramm Verteilungsdiagramm Komponentendiagramm Objektstruktur Modellstruktur Applikationsarchitektur 46

46 UML: Darstellung von Klassen und Objekten Klassensymbol: Angabe von Klassenname Attribute (optional) Methoden (optional) i.a. werden nur relevante Details gezeigt! Sichtbarkeit i.d.r. alles sichtbar beim Entwurf Student Student +MatNr: int +Name: String Student +semester(): int +sumsws(): short Student +MatNr: int +Name: String +semester(): int +sumsws(): short 47

47 UML Assoziationen Entspricht Beziehungen (relationships) im ER-Modell Optional Assoziationsnamen Leserichtung ( bzw. ), sonst bidirektional Rollennamen Sichtbarkeit von Rollen (+,-,#) Kardinalitätsrestriktionen Klasse 1 Assoziationsname Rolle 1 Rolle 2 Klasse 2 Student +Hörer hört +Veranstaltung Vorlesung 48

48 UML Assoziationen (2) Anzahl der Klassen in einer Assoziation ist nicht beschränkt Meistens aber nur binäre Assoziationen Die Beschreibung bei n-ären Assoziationen ist komplex Student +Hörer hört +Veranstaltung Vorlesung 49

49 Beispiel: ER vs. UML Raum N Studenten hört Vorlesungen M MatNr Name VorlNr Titel Student +MatNr: int +Name: String 0..* hört 0..* Vorlesung +VorlNr: int +Titel: String +Raum: String 50

50 UML: Assoziationsklassen Notwendig für Beziehungen mit eigenen Attributen Gestrichelte Linie Name der Assoziationsklasse entspricht dem der Assoziation Studenten * Prüfung * Vorlesung Studenten * * Vorlesung Prüfung +Datum:String 51

51 UML Kardinalitätsrestriktionen Verfeinerung der Semantik eines Beziehungstyps durch Kardinalitätsrestriktionen x..y 0.. * 1.. * mindestens x, maximal y Objekte nehmen an der Beziehung teil optionale Teilnahme an der Beziehung (alternativ * ('many')) obligatorische Teilnahme an der Beziehung 0..1 es kann nur einen geben (oder keinen) 1 genau 1 52

52 UML Kardinalitätsrestriktionen (2) Für binäre Assoziationen Multiplizität min 1..max 1 (min 2..max 2 ) bedeutet, dass zu jedem E 2 (E 1 ) Element wenigstens min 1 (min 2 ) und höchstens max 1 (max 2 ) Instanzen von E 1 (E 2 ) enthalten sein müssen (mit 0 <= min i <= max i, max i >= 1) Bezugnahme zur gegenüberliegenden Klasse Erlaubt Unterscheidung, ob Beziehungsteilnahme Optional (Mindestkardinalität = 0) oder Obligatorisch (Mindestkardinalität >= 1) ist min E 1..max 1 min 2..max 2 1 E 2 R e 1 nimmt an [min 2..max 2 ] Beziehungen vom Typ R teil e 2 nimmt an [min 1..max 1 ] Beziehungen vom Typ R teil 53

53 UML part-of Beziehung part-of Beziehung (Teil-von Beziehung) zwischen Komponenten und Aggregatobjekten Elemente einer Subkomponenten sind auch Elemente aller Superkomponenten dieser Subkomponente Referenzsemantik ermöglicht, dass ein Objekt gleichzeitig Element verschiedener Komponenten bzw. Subkomponenten von mehreren Superkomponenten sein kann (Netzwerk, (n,m) Beziehungen möglich) Wertesemantik (Komposition): Teil-Objekt gehört genau zu einem Aggregatobjekt; Existenzabhängigkeit! Aggregatklasse Aggregatklasse Komp.Klasse 1 Komp.Klasse 2 Komp.Klasse 1 Komp.Klasse 2 54

54 UML: is-a Beziehung is-a Beziehung zwischen Klassen (Entity-Mengen) E 1 is-a E 2 bedeutet, dass jedes Objekt aus E 1 auch ein Objekt aus E 2 ist, jedoch mit zusätzlichen strukturellen Eigenschaften Substitutionsprinzip (Ersetzungsprinzip): alle Instanzen einer Subklasse sind auch Instanzen der Superklasse d.h. Objekt der Subklasse kann immer auch als Objekt der Superklasse verwendet werden Vererbung von Eigenschaften (Attribute, Integritätsbedingungen, Methoden,..) der Superklasse an alle Subklassen Wiederverwendbarkeit, Erweiterbarkeit Keine Wiederholung von Beschreibungsinformation, Fehlervermeidung Superklasse Superklasse Subklasse 1 Subklasse 2 Subklasse 1 Subklasse 2 55

55 Zusammenfassung DB-Entwurf umfasst Informationsanalyse Konzeptioneller Entwurf ( Informationsmodell) Logischer Entwurf ( logisches DB-Schema) Physischer Entwurf ( physisches DB-Schema) Formale Darstellung ER-Modell UML-Klassendiagramme Keine festen Regeln zur eigentlichen Informationsmodellierung (i.a. mehrere Modellierungsmöglichkeiten einer Miniwelt) 56