Sie sind auf Seite 1von 9

Datenbankentwurf Allgemeiner „top-down Entwurf“

Enwurfsschritt 1
Abstraktionsebenen des Datenbankentwurfs Anforderungsanalyse

1. Konzeptuelle Ebene Enwurfsschritt 2


.
2. Implementationsebene Enwurfsschritt 3
. •
3. Physische Ebene
Entwurfsschritt 4
. .
.
Einsatz des Systems
. .
© A. Kemper / A. Eickler 1
. © A. Kemper / A. Eickler 2

Phasen des Datenbankentwurfs Anforderungsanalyse


Datenverarbeitungs-
Informations-
anforderungen
anforderungen 1. Identifikation von Organisationseinheiten
Anforderungs-
analyse 2. Identifikation der zu unterstützenden Aufgaben
Anforderungs
-spezifikation
3. Anforderungs-Sammelplan
Konzeptueller
Enwurf DBMS-
Informations- Charakteristika 4. Anforderungs-Sammlung
ER Schema struktur
Implementations- 5. Filterung
entwurf
logische 6. Satzklassifikationen
Datenbankstruktur
Physischer
7. Formalisierung
Entwurf Hardware/BS-
physische Charakteristika
© A. Datenbankstruktur
Kemper / A. Eickler 3 © A. Kemper / A. Eickler 4

Kapitel 2 1
Beziehungsbeschreibung: prüfen
Objektbeschreibung Beteiligte Objekte:
Uni-Angestellte ™Gehalt - Professor als Prüfer
- Anzahl: 1000 • Typ: dezimal - Student als Prüfling
- Attribute • Länge: (8,2)
™PersonalNummer • Anzahl Wiederholung: 0
- Vorlesung als Prüfungsstoff
• Typ: char • Definiertheit: 10%
Attribute der Beziehung:
• Länge: 9 • Identifizierend: nein
• Wertebereich: ™Rang - Datum
0...999.999.99 • Typ: String - Uhrzeit
• Anzahl • Länge: 4
Wiederholungen: 0 - Note
• Anzahl Wiederholung: 0
• Definiertheit: 100% • Definiertheit: 100%
• Identifizierend: ja • Identifizierend: nein Anzahl: 100 000 pro Jahr
© A. Kemper / A. Eickler 5 © A. Kemper / A. Eickler 6

Prozeßbeschreibungen
Prozeßbeschreibung: Zeugnisausstellung Entity/Relationship-Modellierung
- Häufigkeit: halbjährlich MatrNr Name Semester

- benötigte Daten Entity (Gegenstandstyp)


Studenten
∗ Prüfungen
Hörer
∗ Studienordnungen Relationship (Beziehungstyp)
∗ Studenteninformation
hören
∗ ... Attribut (Eigenschaft)
- Priorität: hoch Lehrveranstaltung

- Zu verarbeitende Datenmenge Schlüssel (Identifikation) Vorlesungen


∗ 500 Studenten
∗ 3000 Prüfungen Rolle
VorlNr Titel SWS
∗ 10 Studienordnungen
© A. Kemper / A. Eickler 7 © A. Kemper / A. Eickler 8

Kapitel 2 2
Universitätsschema voraussetzen Funktionalitäten
Nach- ... ...
MatrNr Vorgänger VorlNr E1 R E2
folger

Name Studenten hören Vorlesungen SWS R ⊆ E1 x E2


Semester Titel
E1 E2
c:c c:mc
Note prüfen lesen

PersNr
Rang
mc:
Name Assistenten arbeitenFür Professoren Raum c
mc:

Fachgebiet mc
PersNr
© A. Kemper / A. Eickler Name 9 © A. Kemper / A. Eickler 10

Funktionalitäten bei n-stelligen


Beziehungen Beispiel-Beziehung: betreuen
E1

P 1 Professoren
m
N M Studenten betreuen
En R E2 1
Seminarthemen

Note
1
Ek
betreuen : Professoren x Studenten → Seminarthemen
R : E1 x ... x Ek-1 x Ek+1 x ... x En → Ek betreuen : Seminarthemen x Studenten → Professoren

© A. Kemper / A. Eickler 11 © A. Kemper / A. Eickler 12

Kapitel 2 3
Dadurch erzwungene
Ausprägung der Beziehung betreuen
Konsistenzbedingungen Professoren
1. Studenten dürfen bei demselben Professor bzw. derselben p1
Professorin nur ein Seminarthema "ableisten" (damit ein
breites Spektrum abgedeckt wird). b1 p2
Studenten
2. Studenten dürfen dasselbe Seminarthema nur einmal b2 p3
bearbeiten – sie dürfen also nicht bei anderen Professoren s1
ein schon einmal erteiltes Seminarthema nochmals p4
bearbeiten. s2 b3

Es sind aber folgende Datenbankzustände nach wie vor möglich: s3 b4


t1
s4 b5
Professoren können dasselbe Seminarthema t2
„wiederverwenden“ – also dasselbe Thema auch mehreren
Studenten erteilen. b6 t3
Gestrichelte Linien
Ein Thema kann von mehreren Professoren vergeben markieren illegale Ausprägungen t4
werden – aber sollte an unterschiedliche Studenten gehen.
© A. Kemper / A. Eickler 13 © A. Kemper / A. Eickler Seminarthemen 14

Funktionalitäten voraussetzen (min, max)-Notation


Nach-
MatrNr Vorgänger folger VorlNr
mc mc
hören Vorlesungen SWS
Name Studenten mc mc
m mc
Semester m Titel besprechen wir nicht!!

Note prüfen lesen

PersNr
1 1 Rang
Name Assistenten arbeitenFür Professoren Raum
m 1
Fachgebiet
PersNr
© A. Kemper / A. Eickler Name 15 © A. Kemper / A. Eickler 16

Kapitel 2 4
Begrenungsflächendarstellung Schwache, existenzabhängige
Polyeder PolyID
Entities
1 Höhe GebNr RaumNr
Hülle Größe
Beispiel- mc
m Polyeder 1
Gebäude liegt_in Räume
Flächen FlächenID
m
Begrenzung
•Beziehung zwischen "starken" und schwachem Typ ist immer
m 1:mc(oder 1:c in seltenen Fällen)
Kanten KantenID
m •Warum kann das keine m:mc-Beziehung sein?
StartEnde X
m •RaumNr ist nur innerhalb eines Gebäudes eindeutig
Y
Punkte
Z •Schlüssel ist: GebNr und RaumNr
© A. Kemper / A. Eickler 17 © A. Kemper / A. Eickler 18

Prüfungen als schwacher Entitytyp Generalisierung


1 mc Note
Studenten ablegen Prüfungen
Name Uni-Mitglieder
PrüfTeil
mc mc
MatrNr is-a
umfassen abhalten
VorlNr m m PersNr Studenten Angestellte PersNr

Vorlesungen Professoren MatrNr is-a


Rang
Fachgebiet Assistenten Professoren
•Mehrere Prüfer in einer Prüfung Raum
•Mehrere Vorlesungen werden in einer Prüfung
abgefragt © A. Kemper / A. Eickler 19 © A. Kemper / A. Eickler 20

Kapitel 2 5
voraussetzen

MatrNr
mc mc
Nach- VorlNr Unsere Notation
Vorgänger folger
Nur funktionale 2er Beziehungen
Studenten hören Vorlesungen SWS
Name m mc Bei 3er und höheren Beziehungen: es wird eine Beziehungsentität
1 1 mc eingeführt
Titel
Semester mc Immer mit den Unterscheidungen (Information Engineering Standard):
mc
c can, 0..1, entspricht 1 im Buch
Note Prüfung
prüfen lesen 1 one oder eins, 1..1,
entspricht existenzabhängig im Buch
mc 1
mc multiple can, 0..*,
1
Fachgebiet 1 Rang entspricht N oder M im Buch
mc m multiple, 1..*,
Assistenten arbeitenFür Professoren
Raum

is-a
PersNr

Name Angestellte
© A. Kemper / A. Eickler 21 © A. Kemper / A. Eickler 22

Aggregation und
Aggregation Fahrzeuge
Generalisierung
is-a
Fahrräder Unmot.-Fahrzeuge mot.-Fahrzeuge

is-a is-a
Teil-von Teil-von
Segler Fahrräder Motorräder Automobile
Rahmen Räder
Teil-von Teil-von

Teil-von Teil-von Teil-von Teil-von Rahmen Räder

Teil-von Teil-von Teil-von Teil-von


Rohre Lenker Felgen Speichen

... ... ... Rohre Lenker Felgen Speichen


...
© A. Kemper / A. Eickler 23 ... ... ...
© A. Kemper / A. Eickler ... 24

Kapitel 2 6
Konsolidierung von Teilschemata Möglicher Konsolidierungsbaum
oder Sichtenintegration S1,2,3,4 ƒ Mögliche Konsolidierungs-
bäume zur Herleitung des
Sicht 3 S1,2,3, S4 globalen Schemas S1,2,3,4 aus
4 Teilschemata S1, S2, S3,
Globales Schema und S4
Sicht 1 Konsoli- •Redundanzfrei S1,2 S3
•Widerspruchsfrei ƒ Oben ein maximal hoher
dierung
Sicht 4 •Synonyme bereinigt S1 S2 Konsolidierungsbaum
•Homonyme bereinigt ƒ „links-tief“ (left-deep)
Sicht 2
S1,2,3,4 ƒ Unten ein minimal hoher
Konsolidierungsbaum
S1,2 S3,4 ƒ Balanciert

ƒ Beide Vorgehensweisen
S1 S2 S3 S4 haben Vor- und Nachteile
© A. Kemper / A. Eickler 25 © A. Kemper / A. Eickler 26

Drei Sichten einer Universitäts-


Datenbank Fakultät
Titel
erstellen
Bibliotheken besitzen Signatur
Studenten Diplomarbeiten Dokumente
betreuen
leiten Autoren
Assistenten Dissertationen entleihen Titel
verfassen
UniMitglieder Jahr
Titel
Professoren bewerten Datum

Sicht 2: Bibliotheksverwaltung
Sicht 1: Erstellung von Dokumenten als Prüfungsleistung
© A. Kemper / A. Eickler 27 © A. Kemper / A. Eickler 28

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

© A. Kemper / A. Eickler 29 © A. Kemper / A. Eickler 30

Wir können davon ausgehen, dass alle an der Universität Bibliotheken


Signatur
erstellten Diplomarbeiten und Dissertationen in Bibliotheken besitzen
Titel
verwaltet werden.
Fakultät Jahr
Die in Sicht 1 festgelegten Beziehungen erstellen und verfassen Dokumente
modellieren denselben Sachverhalt wie das Attribut Autoren
von Büchern in Sicht 3. Verlag
Autoren Diplomarbeiten Dissertationen Bücher
Alle in einer Bibliothek verwalteten Dokumente werden durch
die Signatur identifiziert. entleihen betreuen bewerten empfehlen
leiten
Assistenten Professoren

Datum Studenten Angestellte

UniMitglieder Vorlesungen

© A. Kemper / A. Eickler 31 Personen


© A. Kemper / A. Eickler 32

Kapitel 2 8
Datenmodellierung mit UML Multiplizität
Unified Modelling Language UML KlasseA KlasseB
Assoziation
De-facto Standard für den objekt-orientierten Software-Entwurf +Att1 +Att1
Zentrales Konstrukt ist die Klasse (class), mit der gleichartige +Att2
k..l
1 i..j
1..*
+Att2
Objekte hinsichtlich +op() +op()
Struktur (~Attribute)
Verhalten (~Operationen/Methoden) Jedes Element von KlasseA steht mit mindestens i Elementen
modelliert werden der KlasseB in Beziehung
Assoziationen zwischen Klassen entsprechen Beziehungstypen ... und mit maximal j vielen KlasseB-Elementen
Generalisierungshierarchien
Aggregation Analoges gilt für das Intervall k..l

Multiplizitätsangabe ist analog zur Funktionalitätsangabe im ER-


Modell
Nicht zur (min,max)-Angabe: Vorsicht!
© A. Kemper / A. Eickler 33 © A. Kemper / A. Eickler 34

Klassen und Assoziationen Aggregation (bes.: Komposition)

Studenten
+Hörer +MatrNr : int Prüfungen
Studenten +Prüfling *
voraussetzen +Name : String +Note : Decimal
+MatrNr : int +Nachfolger * +Semester : int 1 absolviert * +Datum : Date
+Name : String 1..*
+Notenschnitt() : float +verschieben()
+Semester : int +SummeWochenstunden() : short
Vorlesungen *
+Notenschnitt() : float hören * +Prüfungsstoff 1
+SummeWochenstunden() : short +VorlNr : int 1
* +Titel : String ...
+SWS : int +Prüfer
...
+AnzHörer() : int
+DurchfallQuote() : float

© A. Kemper / A. Eickler 35 © A. Kemper / A. Eickler 36

Kapitel 2 9