Datenbank –
Datenbanksystem
Datenbanksystem
Datenbank
Menge von zentral
gespeicherten Datenbeständen (Data Base)
Datenbankverwaltungssystem
Zusammenfassung aller
Programme und Prozeduren
zur Handhabung der
gespeicherten Daten (Data
Base Management System)
Zielsetzungen
- Vermeidung von Redundanz
- Sicherung gegen Datenverlust
- Schutz vor unberechtigtem Zugriff
- Mehrfachnutzung von Datenbeständen
- schnelle Antwortzeiten
- einfache Handhabung
LV: SE
2001/2002 Zilahi
Datenbank
1
Relationale Datenbank
Speicherung der Daten in relationaler Form
Beispiel
:Folgender Zusammenhang soll gespeichert werden:
Mandant
Auftrag
Ein Mandant kann mehrere Aufträge erteilen.
Jeder Auftrag stammt jedoch von genau einem
Mandanten.
Es soll gespeichert werden, welcher Mandant
welche Aufträge aufgegeben hat bzw. von welchem
Mandanten ein bestimmter Auftrag stammt.
LV: SE
2001/2002 Zilahi
Datenbank
2
Relationale Datenbank
Beispiel
Annahme:
Es gibt 2 Mandanten M1 und M2.
Es gibt 3 Aufträge A1, A2 und A3.
M := {M1, M2} Menge der Mandanten
A := {A1, A2, A3} Menge der Aufträge
Für die Produktmenge MxA gilt:
MxA := {(M1,A1),(M1,A2),(M1,A3),(M2,A1),(M2,A2),(M2,A3)}
Eine Relation R der Mengen M und A
ist eine Teilmenge von MxA, d.h. R MxA
'Bestell' - Relation R
R = {(M1,A1), (M2,A2), (M2,A3)}
LV: SE
2001/2002 Zilahi
Datenbank
3
Relationale Datenbank
Tabellenform
'Bestell' - Relation:
R = {(M1, A1), (M2, A2), (M2,A3)}
Mandant
Auftrag
M1
M2
M2
LV: SE
2001/2002 Zilahi
A1
A2
A3
Datenbank
4
Entity Sets
Relation-Darstellung
Nicht nur Beziehungen (s. Beziehung zwischen
Mandanten und Aufträge), sondern auch Entity Sets
lassen sich als Relation darstellen!
Entity Set: Mandant
Attribute:
- Nummer
- Name
- Adresse
Es sei: Nr := Menge aller Nummern
Na := Menge aller Namen
Ad := Menge aller Adressen
Mandant - Relation M mit:
M Nr x Na x Ad
Nr
1
2
3
4
5
LV: SE
2001/2002 Zilahi
Name
Adresse
Hans Otto
Klaus Meyer
Adele Schmitz
Rainer Ochs
Gisela Simon
35390 Giessen
35392 Giessen
35396 Giessen
35398 Giessen
35390 Giessen
Datenbank
5
Normalform
entwickelt von E.F. Codd in den 70er Jahren
Ausgangsbasis:
Entity Relationship Model
Entity Set -, Attribut-, Beziehungsbeschreibungen
Ziel: Aufbereitung der Daten für eine effiziente
Speicherung im Rahmen relationaler
Datenbanksysteme
Grundsätze:
Jedes Attribut sollte nur einmal gespeichert werden.
Ein Attribut sollte dem Entity Set zugeordnet werden,
mit dem es die engste Beziehung hat.
Aufdecken von fehlenden Entity Sets und fehlenden
Beziehungen.
LV: SE
2001/2002 Zilahi
Datenbank
6
1. Normalform
Definition:
Beispiel:
Ein Entity Set befindet sich in der
1. Normalform, falls
- das Entity Set einen eindeutigen
Schlüssel enthält und
- kein Attribut bzw. Attributgruppe
je Entity mehr als einen Wert enthält
Mandant
Attribute:
- Mandant-Nr.
- Name
- Adresse
etc.
Falls ein Mandant mehr als eine Adresse
hat, befindet sich das Entity Set Mandant
nicht in der 1. Normalform
LV: SE
2001/2002 Zilahi
Datenbank
7
1. Normalform - Vorgehen
Entferne wiederholt vorkommende Attribute bzw.
Attributgruppen (repeating attribut; repeating
group)
Definiere ein neues Entity Set für die wiederholt
vorkommenden Attribute bzw. Attributgruppen
Übernehme zur Kennzeichnung den Primärschlüssel
des 'alten' Entity Sets in das neue Entity Set
Unnormalisierte Form:
1. NF:
Mandant
Mandant
Mandant-Nr.
Name
Adresse 1
Adresse 2
...
Mandant-Nr.
Name
Adresse
Mandant-Nr.
Adresse
LV: SE
2001/2002 Zilahi
Datenbank
8
1. Normalform – Beispiel 1
Unnormalisierte Form
Projekt
Projekt- Projekt- Projekt- Mitarbei- Mitarbeiter- Abt.- Abt.Nr.
Name Art
ter-Nr.
Name
Nr.
Name
234
Bsys
E
111
344
565
Schmitz
Karl
Hinz
255
Einsys
E
444
765
344
299
Sens
Arnheim
Karl
Unger
LV: SE
2001/2002 Zilahi
Datenbank
4
2
2
6
2
2
2
Biblio
DV
DV
Einkauf
DV
DV
DV
9
1. Normalform – Beispiel 2
1. Normalform
ProjektMitarbeiter
Projekt
Projekt- Projekt- ProjektNr.
Name
Art
234
255
Bsys
Einsys
E
E
Projekt- Mitarbei- Mitarbeiter- Abt.- Abt.Nr.
ter-Nr.
Name
Nr.
Name
234
234
234
255
255
255
255
LV: SE
2001/2002 Zilahi
111
344
565
444
765
344
299
Schmitz
Karl
Hinz
Sens
Arnheim
Karl
Unger
Datenbank
4
2
2
6
2
2
2
Biblio
Dv
Dv
Einkauf
DV
DV
DV
10
Attribut
Ein Attribut, oder eine Attributkombination ist
von einem anderen Attribut B, oder einer Attributkombination voll funktional abhängig, falls das
Attribut A vom gesamten Attribut B, oder Attributkombination und nicht nur von einem Teil von B abhängt.
Ein Attribut, oder eine Attributkombination ist von
einem anderen Attribut oder einer Attributkombination funktional abhängig, falls der Wert des 1. Attributes,
oder Attributkombination durch den Wert des 2.
Attributes, oder die Attributkombination bestimmt wird.
Attributkombination: Projekt-Nr. + Mitarbeiter-Nr.
Das Attribut Mitarbeiter-Name hängt nur
von einem Teil der Attributkombination
(nämlich von Mitarbeiter-Nr.) funktional ab.
Mitarbeiter-Nr. hängt nicht voll von der
Attributkombination Projekt-Nr. + Mitarbeiter-Nr. ab.
Abt.-Nr.
Abt.-Name
Die Abt.-Nr. bestimmt den Abt.-Namen
Der Abt.-Name ist von der Abt.-Nr.
funktional abhängig
Mitarbeiter-Nr.
Mitarbeitername
Projekt-Nr.
Projektname
LV: SE
2001/2002 Zilahi
Datenbank
11
2. Normalform
aus der 1. Normalform
Ein Entity Set befindet sich in der 2. Normalform
(2. NF), wenn es sich in der 1. NF befindet und
zusätzlich jedes Attribut vom Primärschlüssel voll
funktional abhängt.
Vorgehensweise:
Entferne Attribute, die nicht voll funktional
abhängig sind.
Definiere ein neues Entity Set.
Der Schlüsselteil, von dem das Attribut abhängig
ist, wird zum Primärschlüssel des neuen Entity
Sets.
LV: SE
2001/2002 Zilahi
Datenbank
12
2. Normalform – Beispiel 1
Beispiel:
Projekt-Mitarbeiter
Projekt- Mitarbei- Mitarbeiter- Abt.- Abt.Nr.
ter-Nr.
Name
Nr.
Name
234
234
234
255
255
255
255
111
344
565
444
765
344
299
Schmitz
Karl
Hinz
Sens
Arnheim
Karl
Unger
4
2
2
6
2
2
2
Biblio
DV
DV
Einkauf
DV
DV
DV
Primärschlüssel ist: Projekt-Nr. + Mitarbeiter-Nr.
Die Nicht-Schlüssel-Attribute
- Mitarbeiter-Name
- Abt.-Nr.
- Abt.-Name
hängen nur von der Mitarbeiter-Nr. ab
und nicht vom gesamten
Primärschlüssel!
LV: SE
2001/2002 Zilahi
Datenbank
13
2. Normalform – Beispiel 2
statt:
Projekt-Mitarbeiter
Projektzugehörigkeit
Projektzugehörigkeit:
Mitarbeiter:
Projekt-Nr. Mitarbeiter-Nr.
234
11
234
344
234
565
255
444
255
765
255
344
255
299
Mitarbeiter- Mitarbeiter- Abt.- Abt.Nr.
Name
Nr. Name
111
344
565
444
765
299
LV: SE
2001/2002 Zilahi
Mitarbeiter
Schmitz
Karl
Hinz
Sens
Arnheim
Unger
Datenbank
4
2
2
6
2
2
Biblio
DV
DV
Einkauf
DV
DV
14
3. Normalform
Ein Entity Set befindet sich in der 3. Normalform
(3. NF) falls jedes Attribut vom Primärschlüssel
voll funktional abhängig und von jedem Nichtschlüsselattribut funktional unabhängig ist.
Hinweis:
Hängt ein Nichtschlüsselattribut C von einem
anderen
Nichtschlüsselattribut B funktional ab (beide hängen
funktional von einem Primärschlüssel A ab!), so
ergibt sich auch eine sog. transitive Abhängigkeit
der Attribute.
A
B
C
Beispiel:
Mitarbeiter-Nr.
LV: SE
2001/2002 Zilahi
Abt.-Nr.
Datenbank
Abt.-Name
15
3. Normalform
aus der2. Normalform
Entferne aus dem Entity Set alle Attribute, die von
Nichtschlüsselattributen abhängen.
Definiere ein neues Entity Set.
Das Nichtschlüsselattribut, von dem andere Nichtschlüssel abhängen, wird zum neuen Primärschlüssel.
Der Primärschlüssel des neuen Entity Sets bleibt als
'Fremdschlüssel' im ursprünglichen Entity Set.
LV: SE
2001/2002 Zilahi
Datenbank
16
3. Normalform - Übersicht
Entity Sets
Projekt
Projektzugehörigkeit
Mitarbeiter
Abteilung
LV: SE
2001/2002 Zilahi
Attribute
- Projekt-Nr.
- Projektname
- Projektart
Schlüssel
- Projekt-Nr.
- Mitarbeiter-Nr.
Schlüssel
Schlüssel
- Mitarbeiter-Nr.
- Mitarbeitername
- Abt.-Nr.
Schlüssel
- Abt.-Nr.
- Abt.-Name
Schlüssel
Datenbank
17
3. Normalform – Beispiel 1
Ausgangstabelle
Mitarbeiter: Mitarbei- Mitarbeiter- Abt.- Abt.ter-Nr.
Name
Nr. Name
111
344
565
444
765
299
Schmitz
Karl
Hinz
Sens
Arnheim
Unger
4
2
2
6
2
2
Biblio
DV
DV
Einkauf
DV
DV
Das Nichtschlüsselatribut 'Abt.-Name' ist von dem
Nichtschlüsselattribut 'Abt.Nr. funktional
abhängig.
Mitarbeiter-Nr.
Abt.-Nr.
Abt.-Name
LV: SE
2001/2002 Zilahi
Datenbank
18
3. Normalform – Beispiel 2
Mitarbeiter
Abteilung
Mitarbeiter: Mitarbeiter-Nr. Mitarbeiter-Name Abt.-Nr.
111
344
565
444
765
299
Abteilung:
Abt.-Nr.
2
4
6
LV: SE
2001/2002 Zilahi
Schmitz
Karl
Hinz
Sens
Arnheim
Unger
4
2
2
6
2
2
Abt.-Name
DV
Biblio
Einkauf
Datenbank
19
Physikalische Umsetzung
Es gibt keine festen Regeln für die Umsetzung eines
logischen Datenmodells in einen Datenbankentwurf.
Es gibt mehr als nur eine Umsetzungsmöglichkeit!
Kriterien für die physikalische Umsetzung:
- Änderungshäufigkeit
- Zugriffshäufigkeit
- Speicherplatzrestriktionen
- Zugriffszeitrestriktionen
etc.
LV: SE
2001/2002 Zilahi
Datenbank
20
Physikalische Umsetzung
Beispiel 1
Beispiel:
Mandant
erteilt
Mandant-Nr.
M_name
M_adresse
Auftrag
Auftrags-Nr.
Datum
Kategorie
Umsetzungsalternativen:
1. Kunden-Nr. M_name M_adresse Auftrags-Nr. DatumKategorie
1
Hugo Astadt
1
Hugo Astadt
1
Hugo Astadt
2
Adam Bstadt
2
Adam Bstadt
Mandant-Nr. M_name M_adresse
1
2
3
4
5
1.1.96
1.6.96
1.1.97
1.5.97
1.8.98
E
E
E
I
I
1
Hugo Astadt
2
Adam Bstadt
2. Auftrags-Nr. Mandant-Nr. Datum Kategorie
1
2
3
4
5
LV: SE
2001/2002 Zilahi
1
1
1
2
2
1.1.96
1.6.96
1.1.97
1.5.97
1.8.97
Datenbank
E
E
E
I
I
21
Physikalische Umsetzung
Beispiel 2
Mandant-Nr. M_name M_adresse
1
2
Hugo
Adam
Astadt
Bstadt
Auftrags-Nr. Datum Kategorie
1
2
3
4
5
1.1.96
1.6.96
1.197
1.5.97
1.8.97
E
E
E
I
I
Mandant-Nr. Auftrags-Nr.
1
1
1
2
2
1
2
3
4
5
Welche Vor- und Nachteile haben die Umsetzungsalternativen?
Bei welcher Alternative sind die Normalformen erfüllt?
LV: SE
2001/2002 Zilahi
Datenbank
22

Datenbank – Datenbanksystem