Kommunikation und Datenhaltung

Transkript

1 Kommunikation und Datenhaltung Datenbankmodelle für den Entwurf

2 Überblick über den Datenhaltungsteil Motivation und Grundlagen Architektur von Datenbanksystemen Datenbankanfragen Relationenmodell und Relationenalgebra Relationale Datenbanksprachen (SQL) Datenbankentwurf ER- und E Abbildung von en auf das Relationenmodell Relationaler Entwurf Sprachen zur Datenbankdefinition Transaktionsverwaltung Anfrageoptimierung Datenbankanwendungsentwicklung 2

3 Überblick über dieses Kapitel Datenbankentwurf Semantik von E 3

4 Warum dieses Kapitel? I Institut für Programmstrukturen und Datenorganisation (IPD) E Bisher Anfragen auf ein gegebenes Schema Jetzt Entwurf: Wie Schema entwerfen? Wichtigkeit des Themas: Analogie zu Anwendungsentwicklung komplexes Problem strukturierte Herangehensweise 4

5 Warum dieses Kapitel? II Institut für Programmstrukturen und Datenorganisation (IPD) E Wichtigkeit des Themas (Fortsetzung): Es gibt standardisierte Notation für Entwurfsergebnisse auf hoher Ebene. Kommunikation mit anderen Beteiligten leichter, Werkzeug-Unterstützung bei Verfeinerung und Implementierung sowie Verwaltung der Entwurfsergebnisse. Es gibt Qualitätskriterien für Entwurf; Theorie hierzu basiert auf diesem und folgenden Kapiteln. 5

6 Motivation Institut für Programmstrukturen und Datenorganisation (IPD) E Elementare Fragen beim Datenbank- Entwurf: Welche Daten in die Datenbank? Wie strukturiert/ angeordnet? Was für Inhalte sind zulässig? Was für Anfragen sollten grundsätzlich möglich sein? Beantwortung dieser Fragen: bzw. DB-Modellierung. Es gibt unterschiedliche Sprachen hierfür. Sprachen mehr oder weniger eng an zu verwendender DB-Technologie orientiert. 6

7 Institut für Programmstrukturen und Datenorganisation (IPD) Überblick über dieses Kapitel Datenbankentwurf Semantik von E 7

8 Datenbankentwurf Anforderungen E Datenhaltung für mehrere Anwendungssysteme und mehrere Jahre Anforderungen an Entwurf Anwendungsdaten jeder Anwendung sollen aus Daten der Datenbank ableitbar sein (und zwar möglichst effizient) Nur vernünftige (wirklich benötigte) Daten sollen gespeichert werden Nicht-redundante Speicherung 8

9 Datenbankentwurf Entwurfsschritte E Anforderungsanalyse Konzeptioneller Entwurf (Verteilungsentwurf) Logischer Entwurf Datendefinition Physischer Entwurf (Implementierung & Wartung) 9

10 Eigenschaften der Entwurfsschritte Anforderungen an jeden Entwurfsschritt: E 1. Informationserhaltung In jeder nachfolgenden Phase werden dieselben Informationen dargestellt, wenn auch detaillierter und konkreter. 2. Konsistenzerhaltung Alle in einer Phase spezifizierten Regeln und Einschränkungen sind für die nachfolgenden Phasen verbindlich. 10

11 Anforderungsanalyse E Ausgangsbasis: Situationen und Sachverhalte eines Ausschnitts der realen Welt Vorgehensweise: Sammlung des Informationsbedarfs Bestimmung der relevanten Informationen Ergebnis: Informale Beschreibung des Fachproblems (z.b. Texte, Tabellen etc., eventuell in Pflichtenheft) Wichtige Unterscheidung: Information über Daten -> Diese Vorlesung Information über Funktionen -> Softwaretechnik 11

12 Konzeptioneller Entwurf E Erste formale Beschreibung des Fachproblems Vgl. Spezifikationsphase der Software-Entwicklung. Sprachmittel: Semantisches Datenmodell Ergebnis: Semantisches oder konzeptuelles Schema, z.b. als (E)ER-Diagramm oder als diagramm. Randbedingung: Semantisches Modell ist noch unabhängig von speziellem Datenmodell eines Datenbanksystems. Andererseits: Übergang zu den Datenmodellen der Datenbanksysteme soll einfach sein. 12

13 Logischer Entwurf Institut für Programmstrukturen und Datenorganisation (IPD) E (Automatische) Übersetzung des semantischen Schemas in logisches Schema, das Datenmodell des ausgewählten Realisierungs -DBMS Z.B. (E)ER in Relationenmodell Verbesserung des Datenbankschemas anhand von Gütekriterien wie Redundanzvermeidung. Z.B. Normalisierung des relationalen Schemas (relationaler Entwurf) 13

14 Datendefinition Institut für Programmstrukturen und Datenorganisation (IPD) E Umsetzung des logischen Schemas in Sprache einer eines realen DBMS Realisierung der Integritätssicherung durch Sprachkonstrukte des DBMS Definition der Benutzersichten Abwägung wie intensiv die speziellen Möglichkeiten des DBMS ausgenutzt werden sollen: Verbleiben im Standard ( Portierbarkeit) Ausnutzung von Besonderheiten ( Effizienz) 14

15 Physischer Entwurf Institut für Programmstrukturen und Datenorganisation (IPD) E Klärung von Fragestellungen, die mit Leistungsoptimierung hinsichtlich der speziellen Anwendung zu tun haben. Möglichkeiten: Parametereinstellungen Auswahl von Implementierungstechniken Beispiele: Beschreibungen der physischen Datenorganisation Etablierung von Indexstrukturen 15

16 Institut für Programmstrukturen und Datenorganisation (IPD) Überblick über dieses Kapitel Datenbankentwurf Semantik von E 16

17 E Ein Datenbankmodell legt fest statische Eigenschaften für a) Objekte, b) inklusive der Standard-Datentypen, die Daten über die und Objekte darstellen können, 2. dynamische Eigenschaften für a) Operationen, b) zwischen Operationen, 3. Integritätsbedingungen für a) Objekte b) Operationen 17

18 E Entity-Relationship-Modelle Ursprung: P. P. Chen, 1976 Entity: Objekt, über das Informationen zu speichern sind, z. B. Vorlesung, Buch, Lehrperson; auch Informationen über Ereignisse: Prüfungen; Relationship: Beziehung zwischen Entities, z. B. eine Lehrperson hält eine Vorlesung, Attribut: Eigenschaft von Entities oder, z. B. die ISBN eines Buchs, der Titel einer Vorlesung, Semester, in dem Vorlesung gehalten wird. 18

19 Ein einfaches Beispiel Institut für Programmstrukturen und Datenorganisation (IPD) Titel Zeitplan E Professor Name Fach Telefon # Iiest Semester Autor Titel Vorlesung Empfehlung Buch ISBN 19

20 ierungskonzepte I E Im folgenden Vorstellung der Modellierungskonzepte des s. Werte: (int) der Wertebereich Z (die ganzen Zahlen) mit +,,,, =, <, (string) der Wertebereich C* (Folgen von Zeichen aus der Menge C) mit +, =, <,... Allgemein: (D) Interpretation von D, mögliche Werte einer Entity-Eigenschaft. 20

21 E ierungskonzepte II Entities:, etwa E1, E2 E (E) Menge der möglichen Entities vom Typ E; wird hier nicht festgelegt (etwa Menge isomorph zu natürlichen Zahlen), 21

22 E ierungskonzepte III Entities:, etwa E1, E2 E i (E) Menge der aktuellen Entities vom Typ E in einem Zustand i (, Sigma, für state (Zustand); Index i im folgenden weglassen, wenn eindeutig.) Aktuelle Entities müssen mögliche Elemente sein: (E) (E); ferner gefordert: (E) endlich. 22

23 E ierungskonzepte IV : Beziehungstypen Notation n-stelliger Beziehungstypen: E 1 R E I E n 23

24 ierungskonzepte V E mögliche Ausprägungen: (R) = (E 1 )... (E n ) aktuelle nur zwischen aktuellen Entities: (R) (E 1 )... (E n ) 24

25 ierungskonzepte VI E Textuelle Notation: R(E 1,, E n ) Rollennamen: verheiratet(frau:person, Mann:Person) Reihenfolge (verheiratet(person,person)) wäre ausreichend für Festlegung, wer Mann und wer Frau, aber fehleranfällig. Stattdessen Rollennamen. In Grafik entspr. Beschriftung der Kanten. 25

26 ierungskonzepte VII Attribute: E E A : D Semantik einer Attributdeklaration: Ein Attribut A eines E ist im Zustand eine Abbildung (A): (E) (D) Anders ausgedrückt: Attributwert eines Entities abhängig vom Zustand. Attributwerte nur für aktuelle Entities. 26

27 ierungskonzepte VIII Beziehungsattribute: E Semantik: (A): (R) (D) Textuelle Notation für mit Attributen: E(A 1 : D 1,..., A m : D m ) (Wertebereiche werden oft weggelassen) für Beziehungstypen mit Attributen: R(E 1,..., E n ; A 1,..., A p ) R A : D 27

28 Semantik eines ER-Schemas E Jeder Zustand eines ER-Schemas ist eine Zuordnung E (E) (E) R(E 1,..., E n ;...) (R) (E 1 )... (E n ) E(..., A i : D,...) (A i ): (E) (D),... R(...;..., A i : D,...) (A i ): (R) (D),... bei gegebener fester Interpretation der Datentypen durch Wertebereiche und der durch vorgegebene Mengen möglicher Entities. 28

29 E Institut für Programmstrukturen und Datenorganisation (IPD) Zwei- vs. mehrstellige I Dreistellige Beziehung: Professor Name Fach Titel empfiehlt ISBN Vorlesung Buch 29

30 E Institut für Programmstrukturen und Datenorganisation (IPD) Zwei- vs. mehrstellige II Mögliche Umwandlung in zweistellige wirklich das gleiche modelliert? Professor Name Fach P-V P-B Titel Vorlesung V-B Buch ISBN 30

31 E Institut für Programmstrukturen und Datenorganisation (IPD) Ausprägungen im Beispiel I Korrekte Ausprägung der dreistelligen Beziehung. empfiehlt Professor Vorlesung ISBN Heuer DB Heuer DB Saake DB Saake DB Ausprägungen der drei 2-stelligen : P-V Professor Heuer Heuer Saake Saake Vorlesung DB1 DB2 DB1 DB2 P-I Professor ISBN Heuer Heuer Saake V-I Vorlesung ISBN DB DB DB

32 Ausprägungen im Beispiel II E Ausprägungen der drei 2-stelligen Beziehungstypen P-V Professor Heuer Heuer Saake Saake Vorlesung DB1 DB2 DB1 DB2 entsprechen aber auch: P-I Professor ISBN Heuer Heuer Saake V-I Vorlesung ISBN DB DB DB Professor Vorlesung ISBN Heuer DB Heuer DB Heuer DB Saake DB Saake DB

33 E Ausprägungen im Beispiel III Jetzt außerdem möglich: P-V Professor Heuer Heuer Saake Saake Vorlesung DB1 DB2 DB1 DB2 P-I Professor ISBN Heuer Heuer Saake V-I Empfehlung für Buch liegt vor, ohne zu sagen, von wem Vorlesung ISBN DB DB DB DB

34 Funktionale E Textuell: R: E 1 E 2 Graphisch: Professor Fach Telefon# Name sitzt-in Zimmer Zimmer # Gebäude Jedem Professor lässt sich maximal ein Zimmer zuordnen, nicht aber umgekehrt. Bedeutung: (R): (E 1 ) (E 2 ) 34

35 Identifizierung durch I E Für Entity-Typ E(A 1,..., A m ) sei Teilmenge {S 1,..., S k } der Attribute gegeben, die attribute. Es gilt: {S 1,..., S k } {A 1,..., A m } In jedem Datenbankzustand identifizieren die aktuellen Werte der attribute eindeutig Instanzen des Entity-Typs E: e 1, e 2 (E): ( (S 1 )(e 1 ) = (S 1 )(e 2 )... (S k )(e 1 ) = (S k )(e 2 )) (e 1 = e 2 ) Notation: Markieren durch Unterstreichung: E(..., S 1,..., S i,...) 35

36 Identifizierung durch II E vs. kandidaten. Beispiel: Buch(ISBN, Titel, Autor, Verlag, Preis, Erscheinungsjahr), Buch(ISBN, Titel, Autor, Verlag, Preis, Erscheinungsjahr) Eine ausgewählte Alternative ist Primärschlüssel. 36

37 Abhängige I Institut für Programmstrukturen und Datenorganisation (IPD) E Abhängiger Entity-Typ: Identifikation über funktionale Beziehung. Buch Exemplar InventarNr Ausleiher Rückgabe gehört-zu Buch Titel ISBN Szenario: Bibliothek Abhängige Entities im : funkt. Beziehung ist Bestandteil des. Jedem Exemplar lässt sich genau ein Buch zuordnen. 37

38 Abhängige II Alternative Notation. Institut für Programmstrukturen und Datenorganisation (IPD) E Buch Exemplar InventarNr Ausleiher Rückgabe N 1 gehört-zu Erläuterungen: N 1 bedeutet funktionale Beziehung in angegebener Richtung. InventarNr ist partieller. Buch Titel ISBN 38

39 Die IST-Beziehung I Institut für Programmstrukturen und Datenorganisation (IPD) E Prüfer IST Mitarbeiter Fach Personal # Jeder Prüfer-Instanz Institut ist genau einer Mitarbeiter-Instanz zugeordnet: Spezialfall eines abhängigen Entity-Typs. (Nur Beziehung ist ; zwei Prüfer, die gleichem Mitarbeiter zugeordnet sind, sind identisch.) 39

40 Die IST-Beziehung II Institut für Programmstrukturen und Datenorganisation (IPD) E Prüfer IST Mitarbeiter Fach Institut Personal # Nicht jeder Mitarbeiter ist zugleich Prüfer. Englisch: is-a, Spezialisierungsbeziehung. 40

41 Die IST-Beziehung III Institut für Programmstrukturen und Datenorganisation (IPD) E Prüfer IST Mitarbeiter Fach Was ist, wenn ein Mitarbeiter mehrere Fächer prüft? Institut Personal # 41

42 Die IST-Beziehung IV Institut für Programmstrukturen und Datenorganisation (IPD) E Prüfer IST Mitarbeiter Fach Attribute des Entity-Typs Mitarbeiter treffen auch auf Prüfer zu: vererbte Attribute. Prüfer(Name, Personal#, Fach) von Mitarbeiter Nicht nur Deklarationen vererben sich, auch aktuelle Werte. Bedeutung: (Prüfer) (Mitarbeiter) Institut Personal # 42

43 Die IST-Beziehung: Alternative Notation E Prüfer Fach Mitarbeiter Institut Personal # 43

44 Motivation E Man will einschränken, an wievielen Entität teilnehmen kann/muß. Quantitative Aussagen hilfreich/sinnvoll. Beispiel: Fußballmannschaft besteht aus 11 Spielern. Zwei alternative Notationen: Standardkardinalität, Teilnehmerkardinalität 44

45 Teilnehmerkardinalität I Institut für Programmstrukturen und Datenorganisation (IPD) E Mannschaft besteht-aus [11, 11] bestehtaus [1, 1] Mannschaft Spieler FCB Kahn FCB Ballack VfB Meira Spieler 45

46 Teilnehmerkardinalität II Weitere Beispiele: Institut für Programmstrukturen und Datenorganisation (IPD) E Klasse Lehrer [28, 35] bestehtaus [1, 1] [4, 8] unterrichtet [7, 10] Was bedeutet das Zweite? Schüler Klasse 46

47 Teilnehmerkardinalitäten III E [min_1, max_1] [min_n, max_ n] R E 1 Notation für Kardinalitätsangaben an einem Beziehungstyp: R(E 1,..., E i [min i, max i ],..., E n ) Kardinalitätsbedingung: min i {r r R r.e i =e j } max i Spezielle Wertangabe für max i ist. Standardannahme ist [0, *] E n 47

48 Teilnehmerkardinalität Beispiele E arbeitet_in(mitarbeiter[0,1],raum[0,3]) Jedem Mitarbeiter ist in der Regel ein Raum zugeordnet, aber einige (externe) Mitarbeiter haben kein Arbeitszimmer. Pro Zimmer arbeiten maximal drei Mitarbeiter. benutzt(mitarbeiter[0,*],rechner[1,1]) Jedem Rechner ist genau ein Mitarbeiter zugeordnet. Jeder Mitarbeiter benutzt beliebige Rechner. 48

49 Übersicht und (Partielle) Funktionale Beziehung: E E 1 ( Einem E 1 ist max. ein E 2 zugeordnet, jedem E 2 beliebige E 1. ) Abhängiger Entity-Typ (totale funktionale Beziehung): E 1 ( Jedem E 1 ist genau ein E 2 zugeordnet, jedem E 2 beliebige E 1. ) IST-Beziehung (Spezialfall vom abhängigem Entity-Typ): E 1 R R IST E 2 E 2 E 2 R(E 1 [0, 1], E 2 [0, *]) R(E 1 [1, 1], E 2 [0, *]) R(E 1 [1, 1], E 2 [0, 1]) ( Jedem E 1 ist genau ein E 2 zugeordnet, jedem E 2 max. ein E 1. ) 49

50 Standardkardinalität I Institut für Programmstrukturen und Datenorganisation (IPD) E Mannschaft 1 bestehtaus 11 Spieler Kardinalitätsangabe genau 'andersherum' wie bei der Teilnehmerkardinalität Anschaulich: Eine Mannschaft steht mit 11 Spielern in Beziehung. 50

51 Vereinfachte Kardinalitätsangaben Für binären Beziehungstyp: E E_1 ist äquivalent zu E_1 1 N R [0, *] [1, 1] R Die Angabe N entspricht. E_2 E_2 Nicht dasselbe wie funktionale Beziehung: E_1[0, *] -> E_2[0, 1] 51

52 Standardkardinalität II Institut für Programmstrukturen und Datenorganisation (IPD) E Mannschaft 1 bestehtaus 11 In der Literatur auch: 'lookup constraint' Wie kommt die Kardinalitätsangabe zu einer an der Beziehung beteiligten Entität E1 zustande? Instanzen der anderen an Beziehung beteiligten Entities fixieren. Wieviele Instanzen von E1 stehen hiermit in Verbindung? Spieler 52

53 Standardkardinalität III Institut für Programmstrukturen und Datenorganisation (IPD) E Mannschaft Beispiele: 1 bestehtaus 11 Spieler Spieler fixieren (genau) eine Mannschaft Kardinalitätsangabe 1. dto. Mannschaft 11 Spieler. 53

54 Spezielle Kardinalitätsangaben E Bezeichnungen für spezielle Kardinalitätsangaben: m:n-beziehung, 1:n-Beziehung, 1:1-Beziehung. 54

55 E Institut für Programmstrukturen und Datenorganisation (IPD) Standard- vs. Teilnehmerkardinalität Anderswo auch Intervallangaben für Standardkardinalität. In dieser Vorlesung: Teilnehmerkardinalität Intervallangaben in eckigen Klammern. Standardkardinalität eine Zahl bzw. Konstante. In Prüfung bitte explizit angeben, welche Notation Sie verwenden. Standard- und Teilnehmerkardinalität unterscheiden sich in den Ausdrucksmöglichkeiten nur bei mehrwertigen. 55

56 E Weitere Überlegungen I Dreistellige Beziehung: Professor Fach Name (Teilnehmerkard.) [1; 3] Titel empfiehlt ISBN Vorlesung Buch Keine Aussage möglich, wie Buch-Empfehlungen sich auf Vorlesungen verteilen! 56

57 E Weitere Überlegungen II Dreistellige Beziehung: Professor Fach Name Jetzt Standard- Kardinalität. 1 Titel empfiehlt ISBN Vorlesung Buch Entity mit 1 an Kante von anderen Entities funktional abhängig. 57

58 Optionalität von Attributen Institut für Programmstrukturen und Datenorganisation (IPD) E Professor Name Fach Telefon # Iiest Semester Vorlesung Zeitplan Titel 58

59 E Weitere Konzepte I Strukturierte Attributwerte im Person Adresse Name Vorname Telefon # Straße Nummer Ort Mengenwertiges Attribut 59

60 E Weitere Konzepte II Abgeleitete Attributwerte im. Monatsgehalt Angestellter Gehaltsmonate Name Vorname Jahresgehalt Jahresgehalt = Monatsgehalt * Gehaltsmonate 60

61 Institut für Programmstrukturen und Datenorganisation (IPD) Überblick über dieses Kapitel Datenbankentwurf Semantik von E 61

62 Erweiterungen des s I E Spezialisierung und Generalisierung Spezialisierung entspricht IST-Beziehung: Prüfer Spezialisierung von Mitarbeiter. ( Prüfer ist stets Mitarbeiter. ) Prüfer IST Mitarbeiter Fach Personal # Institut 62

63 Erweiterungen des s II E Spezialisierung und Generalisierung (Forts.) Partitionierung: Spezialfall der Spezialisierung, mehrere disjunkte. Partitionierung von Büchern in Monographien und Sammelbändern. Monographie Sammelband IST IST Buch Anm.: Das ist keine richtige Partitionierung! 63

64 Erweiterungen des s III E Spezialisierung und Generalisierung (Forts.) Generalisierung: Entities in einen allgemeineren Kontext. Person oder Institut als Ausleiher. ( Ausleiher ist stets Person oder Institut ; Person muß kein Ausleiher sein.) Ausleiher hat nur Ausleiher-mäßige Attribute. 64

65 Erweiterungen des s IV E Komplexe Objekte Aggregierung: Entity aus einzelnen Instanzen anderer zusammengesetzt. Fahrzeug zusammengesetzt aus Motor, Karosserie,... Sammlung oder Assoziation: Mengenbildung. Team als Gruppe von Personen. 65

66 Erweiterungen des s V E höheren Typs Spezialisierung und Generalisierung auch für Beziehungstypen. Beispiel: Beziehung Ausleihe zu Kurzausleihe spezialisiert. zwischen Beziehungsinstanzen: zweiter und höherer Ordnung. 66

67 Institut für Programmstrukturen und Datenorganisation (IPD) Überblick über dieses Kapitel Datenbankentwurf Semantik von E 67

68 E Ein Erweitertes (EER) Übernommene Grundkonzepte des ER- Modells: Werte: Standard-Datentypen des s. Entities bzw.. bzw. Beziehungstypen. Attribute: unverändert. Funktionale : unverändert. : erweitertes Konzept, neue Notation. Nicht übernommen: IST-Beziehung ersetzt durch Typkonstruktor. Abhängige durch erweitertes konzept sowie objektwertige Attribute ersetzt. 68

69 notation im E E Buch Exemplar Ausleiher Rückgabe Nummer gehört-zu Buch Titel ISBN Anmerkung: veränderte notation erforderlich, da bei objektwertigen Attributen nicht mehr durch Unterstreichen darstellbar 69

70 Objektwertige Attribute im E I E Buch Titel ISBN Von: Ein objektwertiges Attribut kann sein: für den Entity-Typ, für den es deklariert wird, für den Entity-Typ, der Bildbereich des Attributes ist. BuchExemplar Nummer Ausleiher Rückgabe 70

71 Objektwertige Attribute im E II Buch BuchExemplar E Titel ISBN Exemplare: list Ein objektwertiges Attribut kann sein: für den Entity-Typ, für den es deklariert wird, für den Entity-Typ, der Bildbereich des Attributes ist. Nummer Ausleiher Rückgabe Alternativen zu list (Liste): set (Menge), bag (Multimenge) 71

72 E Typkonstruktor Ein einziges Modellierungskonzept für Spezialisierung / IST-Beziehung, Generalisierung, Partitionierung. Eingabetypen verbunden mit Basis des Dreiecks. Ausgabetypen verbunden mit Spitze. Eingabetypen bei Spezialisierung, Partitionierung: Der (oder die) allgemeinere(n) Typ(en). Eingabetypen bei Generalisierung: Die spezielleren Typen. 72

73 Allgemeiner Typkonstruktor E Ausgabetypen sind Spezialisierungen der Eingabetypen i (InTyp i ) j (OutTyp j ) InTyp InTyp n OutTyp 1 OutTyp n 73

74 Spezialisierung mit Typkonstruktor E Mitarbeiter Institut Personal # Spezialisierung (IST-Beziehung) notiert mit dem Typkonstruktor des EER- Modells. Prüfer Fach 74

75 Mehrfache Spezialisierung E Person Adresse Name Vorname Mitarbeiter ist eine spezielle Person Student ist eine spezielle Person beide erben die Attribute von Person Kann Person Mitarbeiter & Student sein? Mitarbeiter Student Zimmer MatrikelNr. 75

76 Mehrfachspezialisierung Institut für Programmstrukturen und Datenorganisation (IPD) E Person Adresse Name Vorname Mitarbeiter Student Zimmer MatrikelNr. Mehrfachspezialisierung zu StudHilfskraft: (StudHilfskraft) (Student) (Mitarbeiter) Mehrfachspezialisierungen sind nur erlaubt, wenn die Eingabe-Typen direkt oder indirekt aus einer gemeinsamen Ausgangsklasse konstruiert wurden. StudHilfskraft Stundenzahl 76

77 Generalisierung I Institut für Programmstrukturen und Datenorganisation (IPD) E LKW PKW Kennzeichen Nutzlast Verantwortlicher Stellplatz Kennzeichen #Personen Verantwortlicher Stellplatz 77

78 Generalisierung II Institut für Programmstrukturen und Datenorganisation (IPD) LKW Kennzeichen E Nutzlast PKW #Personen Kennzeichen Fahrzeug Verantwortlicher Stellplatz Eigenschaften dieser Modellierung: Weniger fehleranfällig, unübersichtlich. Beispiel: Fahrzeug ist Generalisierung von LKW, PKW Warum nicht Mehrfachspezialisierung? 78

79 E Generalisierung III Notation: Typkonstruktor für Generalisierung. In Typ 1 In Typ n Out Typ Bedeutung: i (InTyp i ) (OutTyp) 79

80 Beispiel für Generalisierung E Mitarbeiter Personal # Institut Institut Warum ist hier Generalisierung besser als mehrfache Spezialisierung? Ausleiher berechtigt-bis Institutsname 80

81 Partitionierung I Institut für Programmstrukturen und Datenorganisation (IPD) E Bücher ISBN Monographien Thema Sammelbände Autorenliste Beispiel: Bücher können Monographien oder Sammelbände sein, aber auch etwas ganz anderes 81

82 Partitionierung II Institut für Programmstrukturen und Datenorganisation (IPD) E Semantik: In Typ Teilmengenbeziehung: (InTyp) i (OutTyp i ) Disjunktheit der Partitionen: i, j: i j (OutTyp i ) (OutTyp j )= Out Typ 1 Out Typ n 82

83 Totale Partitionierung Institut für Programmstrukturen und Datenorganisation (IPD) E Ist die totale Partitionierung hier sinnvoll? Ausleiher Ausleiher-ID berechtigt-bis = Mitarbeiter Personal # Institut Institut Institutsname Mengenbeziehung hier: (InTyp) = i (OutTyp i ) 83

84 Partitionierung vs. Spezialisierung E Partitionierung: Buch ISBN Titel Verlag Mehrfache Spezialisierung: Person Name Vorname Monographie Autor Sammelband Herausgeber Mitarbeiter Zimmer Student Adresse MatrikelNr. 84

85 Partitionierung vs. Generalisierung I E Dokument DokID Titel Standort a) Partitionierung Dokument DokID Titel Buch ISBN Autor Zeitschrift Jahrgang ISSN Buch ISBN Autor Zeitschrift Standort b) Generalisierung Jahrgang ISSN 86

86 Partitionierung vs. Generalisierung II E Fortsetzung des Beispiels: Partitionierung es gibt Dokumente, die weder Buch noch Zeitschrift sind. (Z. B. Video); Generalisierung Nicht jedes Buch muß Dokument sein. Hier im Beispiel Dokument muß in Bibliothek vorhanden sein. Man beachte die im vorangegangenen Beispiel. 87

87 Partitionierung vs. Generalisierung III E Vergleich: Partitionierung: (Dokument) (Buch) (Zeitschrift) Generalisierung: (Dokument) (Buch) (Zeitschrift) 88

88 Diskussion Institut für Programmstrukturen und Datenorganisation (IPD) E Warum überhaupt? Historische Entwicklung, didaktische Gründe. Darstellung, daß es mehrere Modelle mit unterschiedlichen Daseinsberechtigungen geben kann. 89

89 Institut für Programmstrukturen und Datenorganisation (IPD) Überblick über dieses Kapitel Datenbankentwurf Semantik von E 90

90 Objektorientierte Entwurfsmodelle E Seit Beginn der 90er Jahre: Ansätze zur objektorientierten Analyse und zum objektorientierten Entwurf. Ansätze der ersten Generation: Object Modelling Technique (OMT) von Rumbaugh Methoden von Jacobson, Booch, u.a. Ab Mitte der 90er Jahre: Vereinheitlichung zur Unified Modeling Language () (Booch, Jacobson, Rumbaugh). 91

91 E Entwurf mit I Bestandteile der Modellierung: Objektmodell: Anreicherung von Een um objektorientierte Konzepte (Unterstützte Konzepte:,, Generalisierung, Aggregation, statische Integritätsbedingungen, abgeleitete Informationen). Außerdem: Methoden, Modellierung von Objekt-Instanzen. Dynamikmodell: Beschreibung des dynamischen Verhaltens eines Objektes in Form von Übergangsautomaten (Übergänge entsprechen Systemereignissen). 92

92 Entwurf mit II Institut für Programmstrukturen und Datenorganisation (IPD) E Bestandteile der Modellierung (Fortsetzung): Funktionenmodell: Datenflußdiagramme zur Darstellung globaler Berechnungsabläufe (elementare Konzepte: Datentransformation, agierende Objekte, Datenspeicher), Anwendungsfälle, Implementierungsdiagramme, weitere hier nicht genannte. 93

93 E Objektmodell von Geht über E hinaus hier insbesondere wichtig: diagramm: Entspricht Datenbankschema-Notation, ~> beschreibt Typen von Kollektionen von Instanzen. Objektdiagramm: Beschreibt Einzelobjekte. Beschreibung von strukturellen Aspekten (Attribute, ) und Operationen. Formulierung von Integritätsbedingungen und Ableitungsregeln (textuell, Object Constraint Language). 95

94 Darstellung von I Institut für Programmstrukturen und Datenorganisation (IPD) E Attribute name: typ = initwert { Zusicherung } Beispiel: Alter: integer = 0 {Alter >= 0 and Alter < 125} Operationen name(parameterliste) 96

95 E Darstellung von II Verschiedene Arten von, speziell abstrakte (Notation: { abstract }), Metaklassen und parametrisierte. Sichtbarkeit von Attributen (private, protected, public) sowie readonly-attribute. Abgeleitete (berechnete) Attribute durch vorangestelltes /-Symbol. attribute durch Unterstreichung. 97

96 E I Standardfall: Binäre (Assoziationen) Professor name:string fach:string telefonnr:number = 4242 * ist zugeordnet 1 Lehrkraft beschäftigt Lehreinheit Institut name:string fachbereich:string Bezeichner der Beziehung mit Leserichtung (keine funktionale Beziehung), Rollennamen für Implementierung von Referenzattributen. 98

97 II Institut für Programmstrukturen und Datenorganisation (IPD) E Fortsetzung: analog zu Standardkardinalitäten ( 1 Institut beschäftigt Professoren. ). Auch Angaben 0..1 oder 0..3 möglich, sowie zusammengesetzte Angaben wie z.b. 0..2, 6, 10..*. 99

98 E mit Attributen mit Attributen als degenerierte. 100

99 E Qualifizierende Zugriffsschlüssel für spätere Implementierung. 101

100 Weitere Institut für Programmstrukturen und Datenorganisation (IPD) E Abgeleitete Beispiel: berechnete Referenz zur Abkürzung mehrstufiger Referenzpfade. Notation: Bezeichner mit vorangestelltem /-Symbol. n-stellige Notation wie im durch Raute. 102

101 E Aggregation in I Aggregation über binäre Assoziation mit besonderer Notation. Ganzes Komposition: Abhängige Objekte als Spezialfall. Ganzes 0..1 besteht aus * 1..1 besteht aus * Teil existenzabhängiges Teil 103

102 Aggregation in II Aggregation Institut für Programmstrukturen und Datenorganisation (IPD) E PC Monitor Drucker Maus Tastatur Tower Schnittstelle Hauptplatine CD Laufwerk Komposition Diskettenlaufwerk Festplatte Gehäuse Tower existenzabhängig von PC, Drucker jedoch nicht. 105

103 E Aggregation in III Baumdarstellung für mehrere aggregierte Teile. Ganzes 1..* * Teil A Teil B Teil C 106

104 E Spezialisierung in I Spezialisierung mit Vererbung. Unterklasse A Oberklasse Angabe von Zusicherungen (overlapping, disjoint, complete, incomplete) möglich. Unterklasse B 107

105 E Beispiel: Spezialisierung in II {disjoint} A {incomplete} {overlapping} {overlapping} B C D E 108

106 Spezialisierung mit Diskriminator I E Geschlecht Person Status Mann Frau Professor Student Diskriminator Begriff Spezialisierung hat hier andere, allgemeinere Bedeutung als im EER- Kontext steht für alle semantischen. 109

107 E Spezialisierung mit Diskriminator II Spezielle Form der Spezialisierung. Aufzählungsattribut (Diskriminator) teilt Instanzen in Unterklassen auf. Wertebereich des Diskriminators: Beteiligte namen. Unterklasse A Oberklasse Diskriminator Unterklasse B 110