Datenbankentwurf Abstraktionsebenen des Datenbankentwurfs Konzeptuelle Ebene Implementationsebene Physische Ebene

Phasen des Datenbankentwurfs Hardware/BS- Charakteristika Datenverarbeitungs- anforderungen Informations- physische Datenbankstruktur DBMS- Physischer Entwurf Implementations- entwurf Konzeptueller Enwurf Anforderungs- analyse logische Datenbankstruktur Informations-struktur Anforderungs-spezifikation ER Schema

Anforderungsanalyse (Pflichtenheft) Identifikation von Organisationseinheiten Identifikation der zu unterstützenden Aufgaben Anforderungs-Sammelplan Anforderungs-Sammlung Filterung Satzklassifikationen Formalisierung

Objektbeschreibung Uni-Angestellte Anzahl: 1000 Attribute PersonalNummer Typ: char Länge: 9 Wertebereich: 0...999.999.99 Anzahl Wiederholungen: 0 Definiertheit: 100% Identifizierend: ja Gehalt Typ: dezimal Länge: (8,2) Anzahl Wiederholung: 0 Definiertheit: 10% Identifizierend: nein Rang Typ: String Länge: 4 Definiertheit: 100%

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

Prozeßbeschreibungen Prozeßbeschreibung: Zeugnisausstellung Häufigkeit: halbjährlich benötigte Daten Prüfungen Studienordnungen Studenteninformation ... Priorität: hoch Zu verarbeitende Datenmenge 500 Studenten 3000 Prüfungen 10 Studienordnungen

Entity/Relationship-Modellierung Entity (Gegenstandstyp) Relationship (Beziehungstyp) Attribut (Eigenschaft) Schlüssel (Identifikation) Rolle Studenten hören Name MatrNr Hörer

Entity/Relationship-Modellierung MatrNr Name Semester Entity (Gegenstandstyp) Relationship (Beziehungstyp) Attribut (Eigenschaft) Schlüssel (Identifikation) Rolle Studenten Hörer hören Lehrveranstaltung Vorlesungen VorlNr Titel SWS

Universitätsschema voraussetzen Nach- folger VorlNr MatrNr Vorgänger Studenten Assistenten MatrNr PersNr Semester Name Fachgebiet Note hören prüfen arbeitenFür Professoren Vorlesungen lesen voraussetzen SWS VorlNr Titel Raum Rang Nach- folger Vorgänger Universitätsschema

Universitätsschema in „deutsch“ Studenten haben eine MatrNr, Name und Semester. Die MatrNr identifiziert einen Studenten eindeutig. Vorlesungen haben eine VorlNr, SWS und Titel. Die VorlNr identifiziert eine Vorlesung eindeutig. Professoren haben eine PersNr, Name, Rang und Raum. Die PersNr identifiziert einen Professor eindeutig. Assistenten haben eine PersNr, Name und Fachgebiet. Die PersNr identifizier einen Assistenten eindeutig. Studenten hören Vorlesungen. Vorlesungen setzen andere Vorlesungen voraus. Professoren lesen Vorlesungen. Assistenten arbeiten für Professoren. Studenten werden von Professoren über Vorlesungen geprüft. Sie erhalten hierbei eine Note.

Eigenschaften von ER Anforderungen ER Diagramme sind einfach zu erstellen ER Diagramme sind einfach zu ändern ER Diagramme sind intuitiv verständlich (auch vom Laien!) ER Diagramme drücken das Wesentliche aus Technische Anforderung Einfachheit Unterstützung durch Tools (z.B. Visio) Graphisch Informationstheoretische Mächtigkeit

Funktionalitäten E1 E2 R ... R  E1 x E2 E1 E2 1:N 1:1 N:1 N:M

Funktionalitäten bei n-stelligen Beziehungen P N M R En E2 1 Ek R : E1 x ... x Ek-1 x Ek+1 x ... x En  Ek

Beispiel-Beziehung: betreuen 1 Professoren N betreuen Studenten 1 Seminarthemen Note betreuen : Professoren x Studenten  Seminarthemen betreuen : Seminarthemen x Studenten  Professoren

Dadurch erzwungene Konsistenzbedingungen Studenten dürfen bei demselben Professor bzw. derselben Professorin nur ein Seminarthema "ableisten" (damit ein breites Spektrum abgedeckt wird). Studenten dürfen dasselbe Seminarthema nur einmal bearbeiten – sie dürfen also nicht bei anderen Professoren ein schon einmal erteiltes Seminarthema nochmals bearbeiten. Es sind aber folgende Datenbankzustände nach wie vor möglich: Professoren können dasselbe Seminarthema „wiederverwenden“ – also dasselbe Thema auch mehreren Studenten erteilen. Ein Thema kann von mehreren Professoren vergeben werden – aber an unterschiedliche Studenten.

Ausprägung der Beziehung betreuen Professoren p1 p2 p3 p4 t1 t2 t3 t4 s1 s2 s3 s4 b1 b2 b3 b4 b5 b6 Studenten Gestrichelte Linien markieren illegale Ausprägungen Seminarthemen

Funktionalitäten N M N M N N M 1 1 N 1 voraussetzen Nach- folger Studenten Assistenten MatrNr PersNr Semester Name Fachgebiet Note hören prüfen arbeitenFür Professoren Vorlesungen lesen voraussetzen SWS VorlNr Titel Raum Rang Nach- folger Vorgänger Funktionalitäten N M N M N N M 1 1 N 1

(min, max)-Notation E1 (min1 max1) (minn, maxn) (min2, max2) R En (mini, maxi) Ek R  E1 x ... x Ei x ... x En Für jedes ei  Ei gibt es Mindestens mini Tupel der Art (..., ei, ...) und Höchstens maxi viele Tupel der Art (..., ei, ...) R

Begrenungsflächendarstellung Polyeder PolyID Beispiel- Polyeder 1 Hülle N Flächen FlächenID N Begrenzung M Kanten KantenID N StartEnde X M Y Punkte Z

Begrenzungsflächendarstellung Polyeder PolyID Beispiel- Polyeder 1 (4, ) (1,1) (3, ) (2, 2) Hülle N Flächen FlächenID N Begrenzung M Kanten KantenID N StartEnde X M Y Punkte Z

Schwache, existenzabhängige Entities Höhe GebNr RaumNr Größe N 1 Gebäude liegt_in Räume Beziehung zwischen "starken" und schwachem Typ ist immer 1:N (oder 1:1 in seltenen Fällen) Warum kann das keine N:M-Beziehung sein? RaumNr ist nur innerhalb eines Gebäudes eindeutig Schlüssel ist: GebNr und RaumNr

Prüfungen als schwacher Entitytyp Note 1 N Studenten ablegen Prüfungen PrüfTeil N N MatrNr umfassen abhalten PersNr VorlNr M M Vorlesungen Professoren Mehrere Prüfer in einer Prüfung Mehrere Vorlesungen werden in einer Prüfung abgefragt

Grenzfall 1 Ein Herz kann ohne Mensch nicht leben. Ein Mensch kann ohne Herz nicht leben. Kein Problem mit ER Modellierung.

Grenzfall 2 Wie kann man ausdrücken, dass ein Mensch mit einer Niere leben kann, aber nicht ganz ohne? Das geht mit ER nicht! (Verletzung der Regel, dass existenzabhängige Beziehungen immer N:1 Beziehungen sein müssen.) N 1

Generalisierung Uni-Mitglieder Name is-a Studenten Angestellte PersNr MatrNr is-a Rang Fachgebiet Assistenten Professoren Raum

Universitätsschema mit Generalisierung und (min, max)-Markierung  Nächste Seite

voraussetzen (0,*) (0,*) VorlNr MatrNr Nach- folger Vorgänger hören Vorlesungen SWS Studenten Name (0,*) (3,*) (1,1) Titel (0,*) (0,*) Semester prüfen Note lesen (0,*) (0,*) Fachgebiet Rang (0,*) (1,1) arbeitenFür Professoren Assistenten Raum is-a PersNr Angestellte Name

Aggregation Fahrräder Teil-von Teil-von Rahmen Räder Teil-von Teil-von Rohre Lenker Felgen Speichen ... ... ... ...

Aggregation und Generalisierung ... Fahrzeuge is-a Unmot.-Fahrzeuge Segler Fahrräder Motorräder Automobile Teil-von Teil-von Rahmen Räder Teil-von Teil-von Teil-von Teil-von Rohre Lenker Felgen Speichen ... ... ... ...

Konsolidierung von Teilschemata oder Sichtenintegration Globales Schema Redundanzfrei Widerspruchsfrei Synonyme bereinigt Homonyme bereinigt Sicht 3 Sicht 1 Sicht 4 Konsoli- Sicht 2 dierung

Möglicher Konsolidierungsbaum Mögliche Konsolidierungs-bäume zur Herleitung des globalen Schemas S1,2,3,4 aus 4 Teilschemata S1, S2, S3, und S4 Oben ein maximal hoher Konsolidierungsbaum „links-tief“ (left-deep) Unten ein minimal hoher Konsolidierungsbaum Balanciert Beide Vorgehensweisen haben Vor- und Nachteile S1,2,3, S4 S1,2 S3 S1 S2 S1,2,3,4 S1,2 S3,4 S1 S2 S3 S4

Drei Sichten einer Universitäts-Datenbank erstellen Titel Studenten Diplomarbeiten betreuen Assistenten Dissertationen verfassen Titel bewerten Professoren Sicht 1: Erstellung von Dokumenten als Prüfungsleistung

Sicht 2: Bibliotheksverwaltung Fakultät besitzen Bibliotheken Signatur Dokumente leiten Autoren entleihen Titel UniMitglieder Jahr Datum Sicht 2: Bibliotheksverwaltung

Sicht 3: Buchempfehlungen für Vorlesungen Bücher Autoren empfehlen Titel Jahr Dozenten Verlag Sicht 3: Buchempfehlungen für Vorlesungen

Beobachtungen Die Begriffe Dozenten und Professoren sind synonym verwendet worden. Der Entitytyp UniMitglieder ist eine Generalisierung von Studenten, Professoren und Assistenten. Fakultätsbibliotheken werden sicherlich von Angestellten (und nicht von Studenten) geleitet. Insofern ist die in Sicht 2 festgelegte Beziehung leiten revisionsbedürftig, sobald wir im globalen Schema ohnehin eine Spezialisierung von UniMitglieder in Studenten und Angestellte vornehmen. Dissertationen, Diplomarbeiten und Bücher sind Spezialisierungen von Dokumenten, die in den Bibliotheken verwaltet werden.

Wir können davon ausgehen, dass alle an der Universität erstellten Diplomarbeiten und Dissertationen in Bibliotheken verwaltet werden. Die in Sicht 1 festgelegten Beziehungen erstellen und verfassen modellieren denselben Sachverhalt wie das Attribut Autoren von Büchern in Sicht 3. Alle in einer Bibliothek verwalteten Dokumente werden durch die Signatur identifiziert.

Signatur Bibliotheken besitzen Titel Fakultät Jahr Dokumente Verlag Autoren Diplomarbeiten Dissertationen Bücher entleihen betreuen bewerten empfehlen leiten Assistenten Professoren Studenten Angestellte Datum UniMitglieder Vorlesungen Personen

Datenmodellierung mit UML Unified Modelling Language UML De-facto Standard für den objekt-orientierten Software-Entwurf Zentrales Konstrukt ist die Klasse (class), mit der gleichartige Objekte hinsichtlich Struktur (~Attribute) Verhalten (~Operationen/Methoden) modelliert werden Assoziationen zwischen Klassen entsprechen Beziehungstypen Generalisierungshierarchien Aggregation

Datenmodellierung mit UML Klassendiagramme Ähnliche Notation wie ER Klassen entsprechen Entities Spezielle Symbole für Aggregation, existenzabhängige Aggregation, Generalisierung Funktionalitäten und Rollen: praktisch wie gewohnt Objektdiagramme Beschreiben spezielle Instanzen von Klassen und ihre Beziehungen Allgemein: UML kann noch sehr viel mehr

Klasse: Professor

Beziehungen

Aggregation

Generalisierung

Objektdiagramm

Multiplizität Jedes Element von KlasseA steht mit mindestens i Elementen der KlasseB in Beziehung ... und mit maximal j vielen KlasseB-Elementen Analoges gilt für das Intervall k..l Multiplizitätsangabe ist analog zur Funktionalitätsangabe im ER-Modell Nicht zur (min,max)-Angabe: Vorsicht!

Klassen und Assoziationen

Aggregation

Begrenzungsflächenmodellierung von Polyedern in UML

Anwendungsfälle (use cases)

Interaktions-Diagramm: Modellierung komplexer Anwendungen

Interaktions-Diagramm: Prüfungsdurchführung