Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

1 Datenbankentwurf Abstraktionsebenen des Datenbankentwurfs 1.Konzeptuelle Ebene 2.Implementationsebene 3.Physische Ebene.

Ähnliche Präsentationen


Präsentation zum Thema: "1 Datenbankentwurf Abstraktionsebenen des Datenbankentwurfs 1.Konzeptuelle Ebene 2.Implementationsebene 3.Physische Ebene."—  Präsentation transkript:

1 1 Datenbankentwurf Abstraktionsebenen des Datenbankentwurfs 1.Konzeptuelle Ebene 2.Implementationsebene 3.Physische Ebene

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

3 3 Anforderungsanalyse (Pflichtenheft) 1.Identifikation von Organisationseinheiten 2. Identifikation der zu unterstützenden Aufgaben 3.Anforderungs-Sammelplan 4.Anforderungs-Sammlung 5.Filterung 6.Satzklassifikationen 7.Formalisierung

4 4 Objektbeschreibung  Uni-Angestellte -Anzahl: Attribute  PersonalNummer Typ: char Länge: 9 Wertebereich: 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 Anzahl Wiederholung: 0 Definiertheit: 100% Identifizierend: nein

5 5 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

6 6 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

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

8 8 Entity/Relationship-Modellierung  Entity (Gegenstandstyp)  Relationship (Beziehungstyp)  Attribut (Eigenschaft)  Schlüssel (Identifikation)  Rolle Studenten Vorlesungen hören VorlNrTitelSWS MatrNrNameSemester Hörer Lehrveranstaltung

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

10 10 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.

11 11 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

12 12 Funktionalitäten E1E1 E2E2 R... R  E 1 x E 2 1:N N:MN:M E1E1 E 2 1:1 N:1

13 13 Funktionalitäten bei n -stelligen Beziehungen E1E1 EnEn E2E2 EkEk R P MN 1 R : E 1 x... x E k-1 x E k+1 x... x E n  E k

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

15 15 Dadurch erzwungene Konsistenzbedingungen 1.Studenten dürfen bei demselben Professor bzw. derselben Professorin nur ein Seminarthema "ableisten" (damit ein breites Spektrum abgedeckt wird). 1.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.

16 16 Ausprägung der Beziehung betreuen Professoren Seminarthemen p1p1 p2p2 p3p3 p4p4 t1t1 t2t2 t3t3 t4t4 s1s1 s2s2 s3s3 s4s4 b1b1 b2b2 b3b3 b4b4 b5b5 b6b6 Studenten Gestrichelte Linien markieren illegale Ausprägungen

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

18 18 (min, max)-Notation E2E2 R  E 1 x... x E i x... x E n E1E1 EnEn EkEk R (min 1 max 1 ) (min 2, max 2 ) (min i, max i ) (min n, max n ) Für jedes e i  E i gibt es Mindestens min i Tupel der Art (..., e i,...) und Höchstens max i viele Tupel der Art (..., e i,...)  R

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

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

21 21 Schwache, existenzabhängige Entities 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 Gebäude liegt_in Räume HöheGebNr Größe RaumNr 1 N

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

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

24 24 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

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

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

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

28 28 Aggregation Fahrräder Teil-von RahmenRäder Teil-von RohreLenkerFelgenSpeichen...

29 29... Rohre... Fahrräder Teil-von RahmenRäder Teil-von Lenker FelgenSpeichen Segler Motorräder Automobile is-a Unmot.-Fahrzeuge mot.-Fahrzeuge is-a Fahrzeuge Aggregation und Generalisierung

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

31 31 Möglicher Konsolidierungsbaum  Mögliche Konsolidierungs- bäume zur Herleitung des globalen Schemas S 1,2,3,4 aus 4 Teilschemata S 1, S 2, S 3, und S 4  Oben ein maximal hoher Konsolidierungsbaum  „links-tief“ (left-deep)  Unten ein minimal hoher Konsolidierungsbaum  Balanciert  Beide Vorgehensweisen haben Vor- und Nachteile S1S1 S 1,2,3,4 S 1,2,3, S4S4 S 1,2 S3S3 S2S2 S 1,2,3,4 S 1,2 S 3,4 S1S1 S2S2 S3S3 S4S4

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

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

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

35 35 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.

36 36  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.

37 37 betreuen bewertenempfehlen DiplomarbeitenDissertationenBücher AssistentenProfessoren AngestellteStudenten UniMitglieder Personen Vorlesungen leiten entleihen Dokumente besitzen Bibliotheken Autoren Fakultät Signatur Titel Jahr Verlag Datum

38 38 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

39 39 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

40 40 Klasse: Professor

41 41 Beziehungen

42 42 Aggregation

43 43 Generalisierung

44 44 Objektdiagramm

45 45 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!

46 46 Klassen und Assoziationen

47 47 Aggregation

48 48 Begrenzungsflächenmodellierung von Polyedern in UML

49 49

50 50 Anwendungsfälle (use cases)

51 51 Interaktions-Diagramm : Modellierung komplexer Anwendungen

52 52 Interaktions-Diagramm: Prüfungsdurchführung


Herunterladen ppt "1 Datenbankentwurf Abstraktionsebenen des Datenbankentwurfs 1.Konzeptuelle Ebene 2.Implementationsebene 3.Physische Ebene."

Ähnliche Präsentationen


Google-Anzeigen