BIS 2. Quartal 2012 Datenbanken TEIL 2

Werbung
Studiengang BWL FHDW
Vorlesung:
Betriebliche
Informationssysteme II
Datenbanken
Teil 2 BI-U2
2. Quartal 2012
Vorlesung: 1 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
Aufbau von
Datenbankmanagementsystemen
Relationale Datenbanksysteme
Normalisierung
Entity-Relationship-Diagramme
Praxis: Datenbanksystem MySQL
SQL-Abfragen mit MySQL
Vorlesung: 2 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
2
Aufbau von DatenbankmanagementSystemen
Vorlesung: 3 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
3
Beispiele für datenintensive
Anwendungen
Auftragsabwicklung in einem Unternehmen,
Erfassen von Bestellungen, Angeboten,
Warenaussendungen, Lagerhaltung
Universitätsverwaltung erfasst Studenten,
Lehrkräfte, Räume, Vorlesungen, Angestellte
Bibliothek: Verwalten von Büchern,
verliehenen Büchern, Nutzern
Vorlesung: 4 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
4
Datenbanksystem-Generationen
1.
2.
3.
4.
5.
50er J. Dateisystem auf Band, nur
sequentieller Zugriff, Batchbetrieb
60er J. Dateisystem auf Platte, Random
Access, Dialogbetrieb, Indexdateien,
Dateiverwaltungssystem
70er J. Prärelationale Systeme (Netzwerk-,
hierarchische Systeme)
80er J. Relationale Systeme
90er J. objektbasierte Systeme
Vorlesung: 5 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
5
1. Generation (50er J.)
Anwendung 1 –
primitive
Ein-/Ausgabe...
Software
Anwendung n –
Dateiorganisation 1
Datei 1
...
Datei n
Dateiorganisation n
anwendungsspezifische Datenorganisation
Geräteabhängigkeit der Programme
Redundanz, Inkonsistenz der Daten
Vorlesung: 6 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
6
50er Jahre: Dateisysteme
Daten speichern in einzelne Dateien
Dateiorganisation ist anwendungsspezifisch:
Öffnen von Dateien zum Lesen und/oder Schreiben
Positionieren innerhalb von Dateien auf bestimmte
Sätze mit Hilfe von Dateizeigern
Lesen von Sätzen aus einer Datei
Schreiben von Sätzen in eine Datei
Erkennen des Dateiendes
Schließen von Dateien.
Vorlesung: 7 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
7
Beispiel Dateisystem
begin
maxgehalt = 0
öffne Datei Personal
solange nicht Dateiende
lies nächsten Satz
falls (Abteilung = 20 und gehalt > maxgehalt)
maxgehalt = gehalt
schließe Datei Personal
gib maxgehalt aus
end
Vorlesung: 8 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
8
2. Generation (60er J.)
Datei(en) 1
Anwendung 1
...
Dateiverwaltungs...
mit gemeinsamem
system
Anwendung n
Zugriff
Datei(en) n
Programmbibliothek
teilw. standardisierte Datenorganisation
•
Dienstprogramme wie z. B. Sortierer
•
Geräteunabhängigkeit
jedoch: Abhängigkeit von Speicherstruktur und
Zugriffspfaden
•
•
Vorlesung: 9 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
9
Datenbanksysteme (seit 70er J.)
Datenbanksystem (DBS) besteht aus:
Datenbankmanagementsystem (DBMS)
Software zur Verwaltung von Datenbeständen
Schnittstelle zwischen Benutzer und Datenbank,
hierzu DB-Sprache, z.B. SQL
realisiert Konsistenz und Datenunabhängigkeit
Datenbank (DB)
integrierter Datenbestand
einheitlich gemäß Datenmodell strukturiert
Vorlesung: 10 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
10
Aufbau von Datenbanksystemen
Anwendungsprogramme
Datenbanksystem
(DBS)
Benutzer,
Administratoren
Datenbankmanagementsystem
(DBMS)
Datenbank (DB)
Benutzerschnittstelle
Betriebssystem
Hauptspeicher
Sekundärspeicher
Vorlesung: 11 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
11
Aufgaben von DBMS
Speicherung u. Verwaltung großer Datenbestände
Speicherung dauerhaft, frei von Redundanzen,
Konsistenzbedingungen genügend
Daten vor unberechtigtem Zugriff geschützt
Anfragen sowie Aktualisierungen möglich
effizienter / schneller Zugriff auf die Daten
mehrere Benutzer gleichzeitig aktiv
Zugriffe über Netz oder auf mehrere Datenbanken
mit Anwendungs-Software koppelbar
Vorlesung: 12 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
12
Datenmodelle
Hierarchisches Datenmodell
IMS (Information Management System) IBM
Netzwerkmodell
UDS von Siemens
Relationales Datenmodell
dBase, MySQL, Access, SQL-Server, ...
Objektorientiertes Datenmodell
teilw. Oracle, O2 von O2 Technology
Vorlesung: 13 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
13
Hierarchisches Datenmodell
•
1960 entwickelt
Baumstruktur mit einem
Ausgangselement
(Root)
•
•
Jedes Element hat
maximal einen
Vorgänger (Parent)
Jedes Element hat
beliebig viele Nachfolger
(Children)
•
Vorlesung: 14 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
14
Beispiel Hierarchisches Modell
Vorlesung: 15 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
15
Ausprägung Hierarchisches Modell
Vorlesung: 16 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
16
Hierarchisches Modell heute
LDAP (Lightweight Directory Access
Protocol) organisiert Verzeichnisdienst
Verzeichnis- und Dateistrukturen von
Betriebssystemen
HTML / XML
IMS (Information Management System) von
IBM
Vorlesung: 17 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
17
Netzwerkmodell
•
•
•
Ab etwa 1970 fand das
hierarchische Datenmodell
seine Erweiterung im
Netzwerkmodell, das nun
auch Querverbindungen
zwischen Baumstrukturen
zuließ.
Jeder Knoten kann mehrere
übergeordnete Knoten
haben.
Jede Netzwerkstruktur lässt
sich durch Einführung
redundanter Knoten als
hierarchische Baumstruktur
darstellen.
Vorlesung: 18 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
18
Beispiel Netzwerk-Modell
Student
Wacker
Mustermann
ss
SV
vs
Vorlesung
Java
Stochastik
Zahlentheorie
Vorlesung: 19 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
19
Relationale Datenbanksysteme
Vorlesung: 20 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
20
3-Ebenen-Architektur
Nach ANSI-SPARC
Views, Nutzerzugriffsrechte. Zugriff über
DB-Anwendung oder Abfragesprache
logische Struktur der DB: Tabellen,
Integritätsbedingungen, Prozeduren...
Wird vom Admin mittels Abfragesprachen
verwaltet
physikalische Struktur der DB: Dateien,
Ablageort. Wird verwaltet vom DBMS,
nicht vom Admin.
Ziel: Erfüllung der Codd-Regeln,
Trennung DB-Anwendung und Datenbank
Vorlesung: 21 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
21
Beispiel 3-Ebenen-Architektur
Bundesbahn:
externe Ebene
Städteverbindungen
konzeptionelle Ebene Kursbuch
interne Ebene
Abbildung auf Dateisystem
Personaldatei:
externe Ebene
Angestellte mit Namen,
Wohnorten und Geburtstag
konzeptionelle Ebene Geburtstagsliste mit
Name, Datum, Alter
interne Ebene
Abbildung auf Dateisystem
Vorlesung: 22 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
22
Datenunabhängigkeit
Physische Datenunabhängigkeit:
keine Änderung des externen Schemas (auf
der externen Ebene) bei Änderung des internen
Schemas
Logische Datenunabhängigkeit:
keine Änderung des externen Schemas
bei Änderungen des konzeptionellen Schemas
Vorlesung: 23 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
23
Codds 12 Regeln für relationale DBS
1. Informationsregel
Daten in Tabellen
2.
Zugriffsgarantie
Jedes Feld eindeutig adressierbar
3.
NULL-Werte
unabh. vom Datentyp existiert Wert f. nichtvorh. Daten
4.
Metadaten
Metadaten in Tabellen
5. Allumfassende Sprache
für alle User einheitlich, z. B. DML, DDL, DCL, TCL
6. Datenänderung in Views
7. Mengenorientierte Änderungsoperationen
Mengenoperationen nicht nur für Abfragen
Vorlesung: 24 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
24
Codds 12 Regeln für relationale DBS
8. Physische Datenunabhängigkeit
Anwendungsprogramme unabh. vom Speicherort
Logische Datenunabhängigkeit
Anwendungsprogramme logisch unabhängig v. Tabellen,
ermöglicht durch Views
9.
10. Deklarative Datenintegrität
Für Einhaltung der Integritätsregeln sorgt DBMS, nicht
Anwendungsprogramm
11. Verteilungsunabhängigkeit
Datenbank kann physikalisch auf mehrere Speicherorte
verteilt sein. Für Anwendungsprogramme unabhängig.
12. Unterwanderungsverbot
Zugriff auf Daten nur über eine relationale Sprache
Vorlesung: 25 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
25
Gemeinsame Merkmale RDBMS
Erfüllung der Codd-Regeln
3-Ebenen-Architektur
standardisierte Datenbanksprache SQL
(structured query language)
Einbettung von SQL in kommerzielle
Programmiersprachen
Werkzeuge für interaktive Definition, Anfrage
und Darstellung von Daten, Entwurf von
Benutzeroberflächen
Vorlesung: 26 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
26
Aufbau relationaler Datenbanken
Die grundlegende Struktur einer relationalen
Datenbank ist die Tabelle. Eine Tabelle ein
Objekt, das Daten in Datensätzen (Zeilen) und
Feldern (Spalten) speichert. In der Regel
besteht eine relationale Datenbank aus
mehreren voneinander unabhängigen Tabellen,
die über Relationen verknüpft werden.
Vorlesung: 27 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
27
Relationale Datenbanktabelle
Tabelle
id name
strasse
plz
1 Kiosk Fröhlich
Karl-Kraut-Straße 25
20680 Hamburg
2 Café Köstlich
Am Hugendubl 14
80100 München
3 Casino am
Naschsee
Promenade 1-3
30012 Hannover
4 Zugspitzblick
Bergweg 84
90405 Hintermwald
Zeile
ort
Feld
Spalte
Primärschlüssel
Vorlesung: 28 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
28
Schlüssel
Schlüssel dienen der Beschleunigung von
Zugriffen auf die Daten. Nur mit Hilfe von
Schlüsseln ist eine relationale Verknüpfung
von Tabellen möglich. Schlüssel
ermöglichen eine Überwachung von
Integritätsregeln.
Vorlesung: 29 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
29
Primärschlüssel
Der Primärschlüssel ermöglicht die eindeutige
Identifizierung eines Datensatzes dadurch,
dass sein Wert in einer Tabelle nur ein einziges
Mal vorkommt. Er setzt sich aus einem oder
mehreren Datenfeldern zusammen. Jede
Tabelle sollte einen Primärschlüssel besitzen.
Vorlesung: 30 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
30
Fremdschlüssel
Ein oder mehrere Tabellenfelder, das auf das
Primärschlüsselfeld in einer anderen Tabelle
Bezug nehmen. Ein Fremd-schlüssel gibt an, in
welcher Beziehung die Tabellen zueinander
stehen; die Daten des Fremdschlüssels
müssen mit denen der Primärschlüsselfelder
übereinstimmen.
Vorlesung: 31 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
31
1:n-Beziehung
Eine Beziehung zwischen zwei Tabellen, bei
der gilt:
1. Der Primärschlüsselwert jedes Datensatzes
in der Mastertabelle („1“) entspricht dem Wert
des jeweiligen Feldes bzw. der jeweiligen
Felder in einem oder mehreren Datensätzen
der Detailtabelle.
2. Der Primärschlüsselwert jedes Datensatzes
in der Detailtabelle („n“) entspricht dem Wert
des jeweiligen Feldes bzw. der jeweiligen
Felder in genau einem Datensatz der
Mastertabelle.
Vorlesung: 32 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
32
m:n-Beziehung
Eine Beziehung zwischen zwei Tabellen, bei
der gilt:
1. Der Primärschlüsselwert jedes Datensatzes
in der Tabelle M entspricht dem Wert des
jeweiligen Feldes bzw. der jeweiligen Felder in
einem oder mehreren Datensätzen der Tabelle
N.
2. Der Primärschlüsselwert jedes Datensatzes
in der Tabelle N entspricht dem Wert des
jeweiligen Feldes bzw. der jeweiligen Felder in
einem oder mehreren Datensätzen der Tabelle
M.
Vorlesung: 33 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
33
Relationenmodell
Relation ~ Tabelle
Tupel
~ Datensatz
Attribut ~ Feld
Vorlesung: 34 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
34
Normalisierung
Vorlesung: 35 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
35
Anomalien
KursNr
Kurs_Bez
Dozent
Anrede
Vorname
Nachname
Telefon
2
Englisch I
LL
Frau
Lisa
Lustig
563567
15
Algebra
HM
Herr
Hugo
Meier
5673456
27
Buchführung
SS
Frau
Susi
Sorglos
68723
51
Englisch II
LL
Frau
Lisa
Lustig
563567
78
Excel
MM
Herr
Martin
Schulze
256254
Löschanomalie
Einfügeanomalie
Änderungsanomalie
Vorlesung: 36 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
36
Anomalien vermeiden
Um Anomalien zu vermeiden, wurden
– Normalformen,
– Entwurfstheorie
und
– Entwurfsregeln
formuliert.
Vorlesung: 37 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
37
Normalisierung
Normalformen:
Regeln des Tabellenentwurfs.
Beim Normalisierungsprozess werden die Daten auf
mehrere Tabellen verteilt.
Ziel ist eine
konsistente Datenhaltung
ohne Redundanzen
ohne Anomalien.
Vorlesung: 38 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
38
Normalformen-Historie
Ursprünglich wurden 1973 von Edgar F. Codd
3 Normalformen (1NF, 2NF, 3NF)
vorgeschlagen.
Jede Stufe beinhaltet die vorhergehende 1NF>2NF->3NF
3NF wurde 1974 revidiert -> Boyce-Codd-NF
(BCNF)
Später weitere (4NF, 5NF) Normalformen,
eher weniger bedeutend
Weg: Aufspaltung in Relationen
Vorlesung: 39 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
39
Normalformen beinhalten einander
Vorlesung: 40 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
40
Anforderungen an NF
Aufspaltung in Relationen muss verlustfrei
geschehen
kein Verlust von Informationen
keine falschen Informationen
kein Verlust an Integritätsbedingungen
Vorlesung: 41 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
41
Hinweise zur Normalisierung
NF sind Richtlinien für guten DB-Entwurf. Sie sind kein
Zwang!
Strikte Normalisierung führt zu größerer Anzahl von
Relationen
Normalisierung nie losgelöst vom konkreten Kontext der DB
betreiben!
Je weiter normalisiert werden soll, desto größer die
Anforderung an das Hintergrundwissen über die Daten
Normalisierung
nicht immer erforderlich
nicht immer machbar (-> Performanz)
nicht immer sinnvoll (zu viele Relationen...)
Vorlesung: 42 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
42
Erste Normalform
Eine Relation ist dann in der ersten Normalform, wenn alle ihre Attribute atomar sind.
atomar: Der Wert eines Attributs lässt sich
nicht weiter teilen oder muss (für diesen
Anwendungsfall) nicht weiter geteilt werden.
Mengenwertige Attribute sind verboten.
Spalten mit gleichartigem Inhalt müssen
zusammengefasst werden.
Vorlesung: 43 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
43
Erste Normalform Beispiel
Spalten mit gleichartigem Inhalt eliminieren
Verboten sind mengenwertige Attribute:
Vater
Mutter
Kinder
Johann Martha {Else, Lucia}
Johann Maria
Heinz
{Theo, Josef}
Martha {Cleo}
Verlangt werden atomare Attribute:
Vater
Mutter Kind
Johann Martha Else
Johann Martha Lucia
Johann Maria
Theo
Johann Maria
Josef
Heinz
Martha Cleo
Vorlesung: 44 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
44
Funktionale Abhängigkeiten
sind eine Form der Integritätsbedingungen.
A und B seien Attribute. B ist von A funktional
abhängig ( A -> B), genau dann, wenn für jeden
Wert von A genau ein Wert von B existiert.
Gleiche A-Werte ergeben somit gleiche B-Werte.
Sprechweise: B hängt von A ab.
(oder: B ist funktional abhängig von A)
Die Schlüsselabhängigkeit ist ein Spezialfall von
funktionaler Abhängigkeit. Der Wert von B muss
jedoch nicht nur einmal in einer Relation
vorkommen.
Abkürzung: FD (functional dependency)
Vorlesung: 45 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
45
Definition funktionale Abhängigkeit
[X] ist der Wert von Attribut X im Tupel 
z.B. Datensatz12[Kundennr]=123
Vorlesung: 46 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
46
Beispiel funktionale Abhängigkeit
Mitarbeiter(MitarbeiterID, Nachname, Vorname,
AbteilungID, Abteilungsleiter, Unternehmen,
Unternehmensanschrift, Berufsgruppe,
Gehaltsklasse)
Vorlesung: 47 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
47
Ableitung von funkt. Abhängigkeiten
A
a1
a2
a3
a4
B
b1
b1
b2
b1
C
c1
c1
c1
c1
Vorlesung: 48 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
48
volle funktionale Abhängigkeit
 ist voll funktional abhängig von  ( =>), falls gilt

 A   :  – {A}  
Ein Attribut  ist voll funktional abhängig von einer Attributmenge  falls
 funktional abhängig ist von 
und  nicht funktional abhängig ist von einer echten Teilmenge von
.
Bsp: Kunde(KundenID, Nachname, PLZ, Ort)
KundenID, Nachname  PLZ, Ort
aber KundenID, Nachname ≠> PLZ, Ort , da
KundenID  PLZ, Ort
Vorlesung: 49 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
49
Schlüssel
KundenID
Vorname
Nachname
PLZ
Ort
1
Martha
Muster
12345
Norddorf
2
Heinz
Huber
45678
Weststadt
KundenID Vorname, Nachname, PLZ, Ort
es gilt auch KundenID →KundenID,
damit ist das gesamte Schema auf rechter Seite der FA
Wenn linke Seite minimal: Schlüssel
Formal: Eine Attributmenge X ist Schlüssel von R, wenn das
Relationenschema R voll funktional abhängig von X ist (X => R) und X
minimal ist.
Gibt es mehrere mögliche Schlüssel, so heißen diese
Schlüsselkandidat.
Ziel des Datenbankentwurfs: alle gegebenen funktionalen
Abhängigkeiten in Schlüsselabhängigkeiten umformen,
ohne dabei semantische Information zu verlieren
Vorlesung: 50 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
50
Definition Schlüssel
Sei R eine Attributmenge, X  R.
X heißt Schlüssel für Tupelmenge
r  Rel(R), falls gilt:
1. ( Tupel ,   r) [X] = [X]  =
Für alle Tupel der Relation gilt: sind die Schlüsselwerte
gleich, so handelt es sich
um die gleichen Tupel.
2. für keine echte Teilmenge X‘  X gilt (1)
Vorlesung: 51 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
51
Zweite Normalform
Ein Attribut heißt Primärattribut, wenn es in mindestens
einem Schlüsselkandidaten vorkommt, andernfalls heißt es
Nichtprimärattribut.
Ein Relationenschema R ist in zweiter Normalform falls
gilt:
R ist in der ersten Normalform
und jedes Nichtprimär-Attribut A  R
ist voll funktional abhängig
von jedem Schlüsselkandidaten.
Vorlesung: 52 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
52
Beispiel
Studentenbelegung
MatrNr VorlNr
Name
Semester
26120
5001
Fichte
10
27550
5001
Schopenhauer
6
27550
4052
Schopenhauer
6
28106
5041
Carnap
3
28106
5052
Carnap
3
28106
5216
Carnap
3
Schlüsselkandiaten:
28106
5259
Carnap
3
{MatrNr, VorlNr}
...
...
...
...
Nichtprimärattribute:
{Name, Semester}
MatrNr
Name
Name ist nicht
voll funktional abhängig
von {MatrNr, VorlNr}
VorlNr
Semester
 keine 2. Normalform
Vorlesung: 53 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
53
Beispiel
Hörsaal
Vorlesung
Dozent
Backen ohne Fett Kant
Termin
Raum
Mo, 10:15
32/102
Selber Atmen
Sokrates Mo, 14:15
31/449
Selber Atmen
Sokrates Di, 14:15
31/449
Schneller Beten
Sokrates Fr, 10:15
31/449
Schlüsselkandidaten:
{Vorlesung, Termin}
{Dozent, Termin}
Es gibt keine
Nicht-Primärattribute
 2. Normalform
{Raum, Termin}
Vorlesung: 54 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
54
Beispiel
Student
MatrNr
Name
29555
Feuerbach
6
Matthies
27550
Schopenhauer
6
Matthies
26120
Fichte
4
Kapphan
25403
Jonas
6
Matthies
28106
•
Carnap
Fachbereich
7
Dekan
Weingarten
Student in zweiter Normalform
aber
•
Abhängigkeiten zwischen den
Nichtprimärattributen:
Fachbereich → Dekan
Vorlesung: 55 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
55
Transitive Abhängigkeit
Gegeben Attributmenge U mit Teilmengen X,Y,Z
Z heißt transitiv abhängig von X, falls gilt
XZ=
 Y  U : X Y = , Y  Z = 
X  Y  Z, Y 
/ X
Beispiel:

MatrNr  Fachbereich  Dekan
Vorlesung: 56 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
56
Dritte Normalform
Die Relation R ist in dritter Normalform, wenn gilt:
•
•
R
ist in zweiter Normalform
Jedes Nichtprimärattribut ist nicht-transitiv abhängig
von jedem Schlüsselkandidaten
Praktische Anwendung: Attribute, die nicht in
unmittelbarer Abhängigkeit zum Primärschlüssel einer
Tabelle stehen, müssen in eine eigene Tabelle
ausgelagert werden.
Vorlesung: 57 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
57
Beispiel 3. Normalform
MitarbeiterID
ProjektID
Aufgabe
Anz_Stunden
Stundensatz
1
1
Entwicklung
70
50
2
1
Assistenz
30
35
3
2
Entwicklung
45
50
Primärschlüssel ist {MitarbeiterID, ProjektID}
2. Normalform ist erfüllt.
Jedoch ist MitarbeiterID → Aufgabe → Stundensatz
somit ist die Relation nicht in der 3. Normalform
Aufteilung in 2 Tabellen:
ProjektMit(MitarbeiterID, ProjektID, AufgabeID, Stunden)
Aufgabe(AufgabeID, Bezeichnung, Stundensatz)
Vorlesung: 58 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
58
ProfessorenAdr
ProfessorenAdr(PersNr, Rang, Name, Straße, PLZ, Ort,
Bundesland, Vorwahl, Landesregierung, Raum)
Rang
Name
PersNr
Straße
PLZ
Ort
Raum
Alle Nichtprimärattribute sind
voll funktional abhängig von
jedem Schlüsselkandidaten.
BLand
Landesregierung

PersNr  {Ort, BLand}  Vorwahl
Vorlesung: 59 BIS Unit II
2012 Prof. Dr. G. Hellberg
Vorwahl
Datenbanken I
 nicht in 3. Normalform
59
Normalformen (einfach)
1. Normalform
Jedem Feld einer Tabelle darf höchstens ein Wert
zugewiesen werden.
2. Normalform
Die Tabelle ist in der 1. Normalform und jedes NichtSchlüsselfeld ist durch den Gesamtschlüssel identifizierbar.
3. Normalform
Die Tabelle ist in der 2. Normalform und alle Datenfelder
sind nur vom gesamten Schlüssel abhängig und haben
keine Abhängigkeiten untereinander.
Vorlesung: 60 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
60
The key,
the whole key,
and nothing but the key,
so help me Codd.
Der Schlüssel,
der gesamte Schlüssel,
und nichts als der Schlüssel,
so wahr mir Codd helfe.
Vorlesung: 61 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
61
Normalisierung-Beispiel
Vorlesung: 62 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
62
Bsp: vor Normalisierung
KundeI
D
Nachname
Telefon
AuftragID
Auftragdatum
Bearbeiter Abteilung
1
Meier
051112345,
0179222222
200
10.1.12
Mirka
Einkauf
2
Müller
NULL
201
11.1.12
Mirka
Einkauf
3
Schulze
021112345
202
11.1.12
Erik
Versand
Vorlesung: 63 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
63
Bsp.: erste Normalform
Kunde:
KundeI
D
Nachname
AuftragID
Auftragdatum
Bearbeiter Abteilung
1
Meier
200
10.1.12
Mirka
Einkauf
2
Müller
201
11.1.12
Mirka
Einkauf
3
Schulze
202
11.1.12
Erik
Versand
Telefon:
TelefonID
KundeID
Telefonnr
100
1
0511-12345
101
1
0179-222222
102
3
0211-12345
Vorlesung: 64 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
64
Bsp.: zweite Normalform
Kunde:
KundeI
D
Nachname
1
Meier
2
Müller
3
Schulze
Telefon:
TelefonID
KundeID
Telefonnr
100
1
0511-12345
101
1
0179-222222
102
3
0211-12345
Auftrag:
AuftragID
Auftragdatum
Bearbeiter Abteilung
KundeID
200
10.1.12
Mirka
Einkauf
1
201
11.1.12
Mirka
Einkauf
2
202
11.1.12
Erik
Versand
3
Vorlesung: 65 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
65
Bsp.: dritte Normalform
Kunde:
KundeI
D
Nachname
1
Meier
2
Müller
3
Schulze
Telefon:
TelefonID
KundeID
Telefonnr
100
1
0511-12345
101
1
0179-222222
102
3
0211-12345
Auftrag:
Bearbeiter:
AuftragID
Auftragdatum
Bearbeiter
ID
KundeID
200
10.1.12
1000
1
201
11.1.12
1000
2
202
11.1.12
1001
3
BearbeiterI
D
Bearbeiter Abteilung
1000
Mirka
Einkauf
1001
Erik
Versand
Vorlesung: 66 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
66
ENDE
Fragen?
Vorlesung: 67 BIS Unit II
2012 Prof. Dr. G. Hellberg
Literatur
Heuer, A.; Saake, G.: Datenbanken: Konzepte und
Sprachen. mitp-Verlag
Kemper, A., Eickler, A.: Datenbanksysteme. Oldenbourg
Vossen, Gottfried: Datenmodelle, Datenbanksprachen und
Datenbankmanagementsysteme. Oldenbourg
Date, Chris J.: An Introduction to Database Systems.
Addison Wesley
einfachere Einführungen, diese decken den Lehrstoff
jedoch nicht vollständig ab:
Geisler, Frank: Datenbanken. Grundlagen und Design. mitp
Cordts, Sönke: Datenbankkonzepte in der Praxis. Addison
Wesley
Vorlesung: 68 BIS Unit II
2012 Prof. Dr. G. Hellberg
Datenbanken I
68
Quellen
Tannenbaum, Andrew, Moderne Betriebssysteme
H. Bethge, Vorlesungsskript DB, FHDW
R. Walther, Vorlesungsskript BIS, FHDW 2011
G. Hellberg, Vorlesungsskripte BIS, FHDW 2003
G. Hellberg, diverse Vorlesungsskripte Betriebssysteme,
FHDW 2000-2011
G. Hellberg, Vorlesungsskripte Netzwerke, FHDW 20002011
G. Hellberg, Vorlesungsskripte Technische Grundlagen,
FHDW 2007-2011
Microsoft Whitepapers
Diverse Quellen Internet (Wikipedia)
Vorlesung: 69 BIS Unit II
2012 Prof. Dr. G. Hellberg
Herunterladen