Upload
claus-schiefer
View
107
Download
3
Embed Size (px)
Citation preview
Vorlesung: 1 BIS Unit II 2012 Prof. Dr. G. Hellberg
Studiengang BWL FHDWStudiengang BWL FHDW
Vorlesung:
Betriebliche
Informationssysteme II
Datenbanken
Teil 2 BI-U2
3. Quartal 2012
Vorlesung: 2 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 22
Datenbanken IDatenbanken I
Aufbau von Datenbankmanagementsystemen
Relationale Datenbanksysteme
Normalisierung
Entity-Relationship-Diagramme
Praxis: Datenbanksystem MySQL
SQL-Abfragen mit MySQL
Vorlesung: 3 BIS Unit II 2012 Prof. Dr. G. Hellberg
Aufbau von Datenbankmanagement-Aufbau von Datenbankmanagement-SystemenSystemen
Datenbanken IDatenbanken I 33
Vorlesung: 4 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 44
Beispiele für datenintensive Beispiele für datenintensive AnwendungenAnwendungen
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: 5 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 55
Datenbanksystem-GenerationenDatenbanksystem-Generationen1. 50er J. Dateisystem auf Band, nur
sequentieller Zugriff, Batchbetrieb
2. 60er J. Dateisystem auf Platte, Random Access, Dialogbetrieb, Indexdateien, Dateiverwaltungssystem
3. 70er J. Prärelationale Systeme (Netzwerk-, hierarchische Systeme)
4. 80er J. Relationale Systeme
5. 90er J. objektbasierte Systeme
Vorlesung: 6 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 66
1. Generation (50er J.)1. Generation (50er J.)
Anwendung 1 –Anwendung 1 –
Dateiorganisation 1Dateiorganisation 1
......
Anwendung n –Anwendung n –
Dateiorganisation nDateiorganisation n
primitiveprimitiveEin-/Ausgabe-Ein-/Ausgabe-
SoftwareSoftware
Datei 1Datei 1......
Datei nDatei n
anwendungsspezifische Datenorganisationanwendungsspezifische Datenorganisation
Geräteabhängigkeit der ProgrammeGeräteabhängigkeit der Programme
Redundanz, Inkonsistenz der DatenRedundanz, Inkonsistenz der Daten
Vorlesung: 7 BIS Unit II 2012 Prof. Dr. G. Hellberg
50er Jahre: Dateisysteme50er Jahre: DateisystemeDaten speichern in einzelne Dateien
Dateiorganisation ist anwendungsspezifisch:Öffnen von Dateien zum Lesen und/oder SchreibenPositionieren innerhalb von Dateien auf bestimmte Sätze mit Hilfe von DateizeigernLesen von Sätzen aus einer DateiSchreiben von Sätzen in eine DateiErkennen des DateiendesSchließen von Dateien.
Datenbanken IDatenbanken I 77
Vorlesung: 8 BIS Unit II 2012 Prof. Dr. G. Hellberg
Beispiel DateisystemBeispiel 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
Datenbanken IDatenbanken I 88
Vorlesung: 9 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 99
2. Generation (60er J.)2. Generation (60er J.)
Dateiverwaltungs-Dateiverwaltungs-systemsystem
Anwendung 1Anwendung 1
......
Anwendung nAnwendung n
Datei(en) 1Datei(en) 1
... ...
mit gemeinsamem mit gemeinsamem ZugriffZugriff
Datei(en) nDatei(en) n
ProgrammbibliothekProgrammbibliothek
• teilw. standardisierte Datenorganisation teilw. standardisierte Datenorganisation • Dienstprogramme wie z. B. SortiererDienstprogramme wie z. B. Sortierer
• Geräteunabhängigkeit Geräteunabhängigkeit • jedoch: Abhängigkeit von Speicherstruktur und jedoch: Abhängigkeit von Speicherstruktur und
ZugriffspfadenZugriffspfaden
Vorlesung: 10 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 1010
Datenbanksysteme (seit 70er J.)Datenbanksysteme (seit 70er J.)Datenbanksystem (DBS) besteht aus:
Datenbankmanagementsystem (DBMS)Software zur Verwaltung von DatenbeständenSchnittstelle zwischen Benutzer und Datenbank, hierzu DB-Sprache, z.B. SQLrealisiert Konsistenz und Datenunabhängigkeit
Datenbank (DB)integrierter Datenbestandeinheitlich gemäß Datenmodell strukturiert
Vorlesung: 11 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 1111
Aufbau von DatenbanksystemenAufbau von Datenbanksystemen
Daten-Daten-bank (DB)bank (DB)
Datenbank-Datenbank-management-management-
system system (DBMS)(DBMS)
Datenbank-Datenbank-system system (DBS)(DBS)
Benutzer-Benutzer-schnittstelleschnittstelle
BetriebssystemBetriebssystem
HauptspeicherHauptspeicher
SekundärspeicherSekundärspeicher
Anwendungs-Anwendungs-programmeprogramme
Benutzer, Benutzer, AdministratorenAdministratoren
Vorlesung: 12 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 1212
Aufgaben von DBMSAufgaben 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 Datenmehrere Benutzer gleichzeitig aktiv Zugriffe über Netz oder auf mehrere Datenbankenmit Anwendungs-Software koppelbar
Vorlesung: 13 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 1313
DatenmodelleDatenmodelleHierarchisches DatenmodellIMS (Information Management System) IBM
NetzwerkmodellUDS von Siemens
Relationales DatenmodelldBase, MySQL, Access, SQL-Server, ...
Objektorientiertes Datenmodellteilw. Oracle, O2 von O2 Technology
Vorlesung: 14 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 1414
Hierarchisches DatenmodellHierarchisches Datenmodell
• 1960 entwickelt1960 entwickelt
• Baumstruktur mit einem Baumstruktur mit einem Ausgangselement (Root) Ausgangselement (Root)
• Jedes Element hat Jedes Element hat maximal einen maximal einen
Vorgänger (Parent)Vorgänger (Parent)
• Jedes Element hat Jedes Element hat beliebig viele Nachfolger beliebig viele Nachfolger
(Children)(Children)
Vorlesung: 15 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 1515
Beispiel Hierarchisches ModellBeispiel Hierarchisches Modell
Vorlesung: 16 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 1616
Ausprägung Hierarchisches ModellAusprägung Hierarchisches Modell
Vorlesung: 17 BIS Unit II 2012 Prof. Dr. G. Hellberg
Hierarchisches Modell heuteHierarchisches Modell heuteLDAP (Lightweight Directory Access Protocol) organisiert Verzeichnisdienst
Verzeichnis- und Dateistrukturen von Betriebssystemen
HTML / XML
IMS (Information Management System) von IBM
Datenbanken IDatenbanken I 1717
Vorlesung: 18 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 1818
NetzwerkmodellNetzwerkmodell
• Ab etwa 1970 fand das Ab etwa 1970 fand das hierarchische Datenmodell hierarchische Datenmodell
seine Erweiterung im seine Erweiterung im Netzwerkmodell, das nun Netzwerkmodell, das nun auch Querverbindungen auch Querverbindungen
zwischen Baumstrukturen zwischen Baumstrukturen zuließ.zuließ.
• Jeder Knoten kann mehrere Jeder Knoten kann mehrere übergeordnete Knoten übergeordnete Knoten
haben. haben.
• Jede Netzwerkstruktur lässt Jede Netzwerkstruktur lässt sich durch Einführung sich durch Einführung
redundanter Knoten als redundanter Knoten als hierarchische Baumstruktur hierarchische Baumstruktur
darstellen.darstellen.
Vorlesung: 19 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 1919
Beispiel Netzwerk-ModellBeispiel Netzwerk-Modell
StudentStudent
SVSV
VorlesungVorlesung
ssss
vsvs
MustermannMustermann WackerWacker
JavaJava StochastikStochastik ZahlentheorieZahlentheorie
Vorlesung: 20 BIS Unit II 2012 Prof. Dr. G. Hellberg
Relationale DatenbanksystemeRelationale Datenbanksysteme
Datenbanken IDatenbanken I 2020
Vorlesung: 21 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 2121
3-Ebenen-Architektur3-Ebenen-ArchitekturNach ANSI-SPARCNach ANSI-SPARC
Views, Nutzerzugriffsrechte. Zugriff über Views, Nutzerzugriffsrechte. Zugriff über DB-Anwendung oder AbfragespracheDB-Anwendung oder Abfragesprache
logische Struktur der DB: Tabellen, logische Struktur der DB: Tabellen, Integritätsbedingungen, Prozeduren...Integritätsbedingungen, Prozeduren...
Wird vom Admin mittels Abfragesprachen Wird vom Admin mittels Abfragesprachen verwaltetverwaltet
physikalische Struktur der DB: Dateien, physikalische Struktur der DB: Dateien, Ablageort. Wird verwaltet vom DBMS, Ablageort. Wird verwaltet vom DBMS,
nicht vom Admin.nicht vom Admin.
Ziel: Erfüllung der Codd-Regeln, Ziel: Erfüllung der Codd-Regeln, Trennung DB-Anwendung und DatenbankTrennung DB-Anwendung und Datenbank
Vorlesung: 22 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 2222
Beispiel 3-Ebenen-ArchitekturBeispiel 3-Ebenen-ArchitekturBundesbahn:
externe Ebene Städteverbindungen
konzeptionelle Ebene Kursbuch
interne Ebene Abbildung auf Dateisystem
Personaldatei:
externe Ebene Angestellte mit Namen, Wohnorten und Geburtstag
konzeptionelle Ebene Geburtstagsliste mitName, Datum, Alter
interne Ebene Abbildung auf Dateisystem
Vorlesung: 23 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 2323
DatenunabhängigkeitDatenunabhängigkeitPhysische Datenunabhängigkeit:
keine Änderung des externen Schemas (auf der externen Ebene) bei Änderung des internen Schemas
Logische Datenunabhängigkeit:
keine Änderung des externen Schemasbei Änderungen des konzeptionellen Schemas
Vorlesung: 24 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 2424
Codds 12 Regeln für relationale DBSCodds 12 Regeln für relationale DBS
1.1. InformationsregelInformationsregel Daten in TabellenDaten in Tabellen
2.2. ZugriffsgarantieZugriffsgarantie Jedes Feld eindeutig adressierbarJedes Feld eindeutig adressierbar
3.3. NULL-WerteNULL-Werte unabh. vom Datentyp existiert Wert f. nichtvorh. Datenunabh. vom Datentyp existiert Wert f. nichtvorh. Daten
4.4. MetadatenMetadatenMetadaten in TabellenMetadaten in Tabellen
5.5. Allumfassende SpracheAllumfassende Sprache für alle User einheitlich, z. B. DML, DDL, DCL, TCLfür alle User einheitlich, z. B. DML, DDL, DCL, TCL
6.6. Datenänderung in ViewsDatenänderung in Views7.7. Mengenorientierte ÄnderungsoperationenMengenorientierte Änderungsoperationen
Mengenoperationen nicht nur für AbfragenMengenoperationen nicht nur für Abfragen
Vorlesung: 25 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 2525
Codds 12 Regeln für relationale DBSCodds 12 Regeln für relationale DBS
8.8. Physische DatenunabhängigkeitPhysische Datenunabhängigkeit Anwendungsprogramme unabh. vom SpeicherortAnwendungsprogramme unabh. vom Speicherort
9.9. Logische DatenunabhängigkeitLogische DatenunabhängigkeitAnwendungsprogramme logisch unabhängig v. Tabellen, Anwendungsprogramme logisch unabhängig v. Tabellen,
ermöglicht durch Viewsermöglicht durch Views
10.10. Deklarative DatenintegritätDeklarative DatenintegritätFür Einhaltung der Integritätsregeln sorgt DBMS, nicht Für Einhaltung der Integritätsregeln sorgt DBMS, nicht
AnwendungsprogrammAnwendungsprogramm
11.11. VerteilungsunabhängigkeitVerteilungsunabhängigkeitDatenbank kann physikalisch auf mehrere Speicherorte Datenbank kann physikalisch auf mehrere Speicherorte verteilt sein. Für Anwendungsprogramme unabhängig.verteilt sein. Für Anwendungsprogramme unabhängig.
12.12. UnterwanderungsverbotUnterwanderungsverbotZugriff auf Daten nur über eine relationale SpracheZugriff auf Daten nur über eine relationale Sprache
Vorlesung: 26 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 2626
Gemeinsame Merkmale RDBMSGemeinsame Merkmale RDBMSErfü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: 27 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 2727
Aufbau relationaler DatenbankenAufbau relationaler DatenbankenDie 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: 28 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 2828
Relationale DatenbanktabelleRelationale Datenbanktabelle
id name strasse plz ort
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
PrimärschlüsselPrimärschlüsselZeileZeile FeldFeld
SpalteSpalte
TabelleTabelle
Vorlesung: 29 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 2929
SchlüsselSchlü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: 30 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 3030
PrimärschlüsselPrimärschlüsselDer 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: 31 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 3131
FremdschlüsselFremdschlü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: 32 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 3232
1:n-Beziehung1:n-BeziehungEine 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: 33 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 3333
m:n-Beziehungm:n-BeziehungEine 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: 34 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 3434
RelationenmodellRelationenmodellRelation ~ Tabelle
Tupel ~ Datensatz
Attribut ~ Feld
Vorlesung: 35 BIS Unit II 2012 Prof. Dr. G. Hellberg
NormalisierungNormalisierung
Datenbanken IDatenbanken I 3535
Vorlesung: 36 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 3636
AnomalienAnomalien
LöschanomalieLöschanomalie
EinfügeanomalieEinfügeanomalie
ÄnderungsanomalieÄnderungsanomalie
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
Vorlesung: 37 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 3737
Anomalien vermeidenAnomalien vermeidenUm Anomalien zu vermeiden, wurden
– Normalformen, – Entwurfstheorie und – Entwurfsregeln
formuliert.
Vorlesung: 38 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 3838
NormalisierungNormalisierung
Normalformen: Regeln des Tabellenentwurfs.
Beim Normalisierungsprozess werden die Daten auf mehrere Tabellen verteilt.
Ziel ist eine
konsistente Datenhaltung
ohne Redundanzen
ohne Anomalien.
Vorlesung: 39 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 3939
Normalformen-HistorieNormalformen-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: 40 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 4040
Normalformen beinhalten einanderNormalformen beinhalten einander
Vorlesung: 41 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 4141
Anforderungen an NFAnforderungen an NFAufspaltung in Relationen muss verlustfrei geschehen
kein Verlust von Informationenkeine falschen Informationenkein Verlust an Integritätsbedingungen
Vorlesung: 42 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 4242
Hinweise zur NormalisierungHinweise zur NormalisierungNF sind Richtlinien für guten DB-Entwurf. Sie sind kein Zwang!Strikte Normalisierung führt zu größerer Anzahl von RelationenNormalisierung nie losgelöst vom konkreten Kontext der DB betreiben!Je weiter normalisiert werden soll, desto größer die Anforderung an das Hintergrundwissen über die DatenNormalisierung
nicht immer erforderlichnicht immer machbar (-> Performanz)nicht immer sinnvoll (zu viele Relationen...)
Vorlesung: 43 BIS Unit II 2012 Prof. Dr. G. Hellberg
Erste NormalformErste Normalform
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.
Datenbanken IDatenbanken I 4343
Eine Relation ist dann in der ersten Normal-Eine Relation ist dann in der ersten Normal-form, wenn alle ihre Attribute atomar sind.form, wenn alle ihre Attribute atomar sind.
Vorlesung: 44 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 4444
Erste Normalform BeispielErste Normalform Beispiel
Spalten mit gleichartigem Inhalt eliminierenVerboten sind mengenwertige Attribute:
VaterVater MutterMutter Kinder Kinder
JohannJohann MarthaMartha {Else, Lucia}{Else, Lucia}
JohannJohann MariaMaria {Theo, Josef}{Theo, Josef}
HeinzHeinz MarthaMartha {Cleo}{Cleo}
VaterVater MutterMutter KindKind
JohannJohann MarthaMartha ElseElse
JohannJohann MarthaMartha LuciaLucia
JohannJohann MariaMaria TheoTheo
JohannJohann MariaMaria JosefJosef
HeinzHeinz MarthaMartha CleoCleo
Verlangt werden atomare Attribute:Verlangt werden atomare Attribute:
Vorlesung: 45 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 4545
Funktionale AbhängigkeitenFunktionale 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: 46 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 4646
Definition funktionale AbhängigkeitDefinition funktionale Abhängigkeit
[X] ist der Wert von Attribut X im Tupel [X] ist der Wert von Attribut X im Tupel
z.B. Datensatz12[Kundennr]=123z.B. Datensatz12[Kundennr]=123
Vorlesung: 47 BIS Unit II 2012 Prof. Dr. G. Hellberg
Beispiel funktionale AbhängigkeitBeispiel funktionale Abhängigkeit
Mitarbeiter(MitarbeiterID, Nachname, Vorname, AbteilungID, Abteilungsleiter, Unternehmen, Unternehmensanschrift, Berufsgruppe, Gehaltsklasse)
Datenbanken IDatenbanken I 4747
Vorlesung: 48 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 4848
Ableitung von funkt. AbhängigkeitenAbleitung von funkt. Abhängigkeiten
A B C
a1 b1 c1
a2 b1 c1
a3 b2 c1
a4 b1 c1
Vorlesung: 49 BIS Unit II 2012 Prof. Dr. G. Hellberg
volle funktionale Abhängigkeitvolle 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, Ortaber KundenID, Nachname ≠> PLZ, Ort , daKundenID PLZ, Ort
Datenbanken IDatenbanken I 4949
Vorlesung: 50 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 5050
SchlüsselSchlüssel
KundenID KundenID Vorname, Nachname, PLZ, OrtVorname, Nachname, PLZ, Ortes gilt auch KundenID →KundenID, es gilt auch KundenID →KundenID,
damit ist das gesamte Schema auf rechter Seite der FAdamit ist das gesamte Schema auf rechter Seite der FA
Wenn linke Seite minimal: Wenn linke Seite minimal: SchlüsselSchlüsselFormal: Eine Attributmenge X ist Schlüssel von R, wenn das Formal: Eine Attributmenge X ist Schlüssel von R, wenn das
Relationenschema R voll funktional abhängig von X ist (X => R) und X Relationenschema R voll funktional abhängig von X ist (X => R) und X minimal ist. minimal ist.
Gibt es mehrere mögliche Schlüssel, so heißen diese Gibt es mehrere mögliche Schlüssel, so heißen diese Schlüsselkandidat.Schlüsselkandidat.
Ziel des Datenbankentwurfs:Ziel des Datenbankentwurfs: alle gegebenen funktionalen alle gegebenen funktionalenAbhängigkeiten in Abhängigkeiten in SchlüsselabhängigkeitenSchlüsselabhängigkeiten umformen, umformen,
ohne dabei semantische Information zu verlierenohne dabei semantische Information zu verlieren
KundenID Vorname Nachname PLZ Ort
1 Martha Muster 12345 Norddorf
2 Heinz Huber 45678 Weststadt
Vorlesung: 51 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 5151
Definition SchlüsselDefinition Schlüssel
Sei R eine Attributmenge, X Sei R eine Attributmenge, X R. R.
X heißt X heißt SchlüsselSchlüssel für Tupelmenge für Tupelmenge r r Rel(R), falls gilt: Rel(R), falls gilt:
1. (1. ( Tupel Tupel , , r) r) [X] = [X] = [X] [X] ==Für alle Tupel der Relation gilt: sind die Schlüsselwerte Für alle Tupel der Relation gilt: sind die Schlüsselwerte
gleich, so handelt es sich gleich, so handelt es sich um die gleichen Tupel. um die gleichen Tupel.
2. für keine echte Teilmenge X‘ 2. für keine echte Teilmenge X‘ X gilt (1) X gilt (1)
Vorlesung: 52 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 5252
Zweite NormalformZweite 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: 53 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 5353
BeispielBeispielMatrNrMatrNr VorlNr NameVorlNr Name SemesterSemester
2612026120 50015001 FichteFichte 1010
2755027550 50015001 SchopenhauerSchopenhauer 6 6
2755027550 40524052 SchopenhauerSchopenhauer 6 6
2810628106 50415041 CarnapCarnap 3 3
2810628106 50525052 CarnapCarnap 3 3
2810628106 52165216 CarnapCarnap 3 3
2810628106 52595259 CarnapCarnap 3 3
. . .. . . . . . . . . . . . . . . . . .. . .
StudentenbelegungStudentenbelegung
MatrNrMatrNr
VorlNrVorlNr
NameName
SemesterSemester
Schlüsselkandiaten:Schlüsselkandiaten:
{MatrNr, VorlNr}{MatrNr, VorlNr}
Nichtprimärattribute:Nichtprimärattribute:
{Name, Semester}{Name, Semester}
NameName ist nicht ist nicht voll funktional abhängig voll funktional abhängig
von {MatrNr, VorlNr}von {MatrNr, VorlNr}
keine 2. Normalformkeine 2. Normalform
Vorlesung: 54 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 5454
BeispielBeispiel
Schlüsselkandidaten:Schlüsselkandidaten:
{Vorlesung, Termin}{Vorlesung, Termin}
{Dozent, Termin}{Dozent, Termin}
{Raum, Termin}{Raum, Termin}
VorlesungVorlesung DozentDozent TerminTermin Raum Raum
Backen ohne FettBacken ohne Fett KantKant Mo, 10:15Mo, 10:15 32/10232/102
Selber AtmenSelber Atmen SokratesSokrates Mo, 14:15Mo, 14:15 31/44931/449
Selber AtmenSelber Atmen SokratesSokrates Di, 14:15Di, 14:15 31/44931/449
Schneller BetenSchneller Beten SokratesSokrates Fr, 10:15Fr, 10:15 31/44931/449
HörsaalHörsaal
Es gibt keine Es gibt keine Nicht-PrimärattributeNicht-Primärattribute
2. Normalform2. Normalform
Vorlesung: 55 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 5555
BeispielBeispiel
MatrNrMatrNr NameName Fachbereich DekanFachbereich Dekan
2955529555 Feuerbach Feuerbach 66 MatthiesMatthies
2755027550 Schopenhauer Schopenhauer 66 MatthiesMatthies
2612026120 Fichte Fichte 44 KapphanKapphan
2540325403 Jonas Jonas 66 MatthiesMatthies
2810628106 Carnap Carnap 77 WeingartenWeingarten
StudentStudent
• StudentStudent in zweiter Normalform in zweiter Normalform
aberaber
• Abhängigkeiten zwischen den Abhängigkeiten zwischen den Nichtprimärattributen: Nichtprimärattributen: Fachbereich → DekanFachbereich → Dekan
Vorlesung: 56 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 5656
Transitive AbhängigkeitTransitive Abhängigkeit
MatrNr MatrNr Fachbereich Fachbereich Dekan Dekan
Gegeben Attributmenge Gegeben Attributmenge UU mit Teilmengen mit Teilmengen X,Y,ZX,Y,Z
ZZ heißt transitiv abhängig heißt transitiv abhängig von Xvon X, falls gilt, falls gilt
XX ZZ = = YY UU : : X X YY = = , , YY ZZ = =
//XX YY Z Z, , YY XX
Beispiel:Beispiel:
Vorlesung: 57 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 5757
Dritte NormalformDritte Normalform
Die Relation Die Relation RR ist in dritter Normalform, wenn gilt: ist in dritter Normalform, wenn gilt:
• RR ist in zweiter Normalform ist in zweiter Normalform
• Jedes Nichtprimärattribut ist nicht-transitiv abhängig Jedes Nichtprimärattribut ist nicht-transitiv abhängig von jedem Schlüsselkandidatenvon jedem Schlüsselkandidaten
Praktische Anwendung: Attribute, die nicht in Praktische Anwendung: Attribute, die nicht in unmittelbarer Abhängigkeit zum Primärschlüssel einer unmittelbarer Abhängigkeit zum Primärschlüssel einer
Tabelle stehen, müssen in eine eigene Tabelle Tabelle stehen, müssen in eine eigene Tabelle ausgelagert werden.ausgelagert werden.
Vorlesung: 58 BIS Unit II 2012 Prof. Dr. G. Hellberg
Beispiel 3. NormalformBeispiel 3. NormalformMitarbeiterID ProjektID Aufgabe Anz_Stunden Stundensatz
1 1 Entwicklung 70 50
2 1 Assistenz 30 35
3 2 Entwicklung 45 50
Datenbanken IDatenbanken I 5858
Primärschlüssel ist {MitarbeiterID, ProjektID}Primärschlüssel ist {MitarbeiterID, ProjektID}2. Normalform ist erfüllt.2. Normalform ist erfüllt.
Jedoch ist MitarbeiterID → Aufgabe → StundensatzJedoch ist MitarbeiterID → Aufgabe → Stundensatzsomit ist die Relation nicht in der 3. Normalformsomit ist die Relation nicht in der 3. Normalform
Aufteilung in 2 Tabellen:Aufteilung in 2 Tabellen:ProjektMit(ProjektMit(MitarbeiterID, ProjektIDMitarbeiterID, ProjektID, , AufgabeIDAufgabeID, Stunden), Stunden)
Aufgabe(Aufgabe(AufgabeIDAufgabeID, Bezeichnung, Stundensatz), Bezeichnung, Stundensatz)
Vorlesung: 59 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 5959
ProfessorenAdrProfessorenAdr
PersNrPersNr { {OrtOrt, , BLandBLand} } VorwahlVorwahl
PersNrPersNr
RaumRaum
RangRang
NameName
StraßeStraße
OrtOrt
BLandBLand
LandesregierungLandesregierung
VorwahlVorwahl
PLZPLZ
nicht in 3. Normalformnicht in 3. Normalform
Alle Nichtprimärattribute sind Alle Nichtprimärattribute sind voll funktional abhängig von voll funktional abhängig von jedem Schlüsselkandidaten.jedem Schlüsselkandidaten.
ProfessorenAdr(ProfessorenAdr(PersNrPersNr, Rang, Name, Straße, PLZ, Ort, , Rang, Name, Straße, PLZ, Ort, Bundesland, Vorwahl, Landesregierung, Raum)Bundesland, Vorwahl, Landesregierung, Raum)
Vorlesung: 60 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 6060
Normalformen (einfach)Normalformen (einfach)
1. NormalformJedem Feld einer Tabelle darf höchstens ein Wert zugewiesen werden. 2. NormalformDie Tabelle ist in der 1. Normalform und jedes Nicht-Schlüsselfeld ist durch den Gesamtschlüssel identifizierbar.3. NormalformDie Tabelle ist in der 2. Normalform und alle Datenfelder sind nur vom gesamten Schlüssel abhängig und haben keine Abhängigkeiten untereinander.
Vorlesung: 61 BIS Unit II 2012 Prof. Dr. G. Hellberg
The key,
the whole key,
and nothing but the key,
so help me Codd.
Datenbanken IDatenbanken I 6161
Der Schlüssel, Der Schlüssel, der gesamte Schlüssel, der gesamte Schlüssel,
und nichts als der Schlüssel, und nichts als der Schlüssel, so wahr mir Codd helfe.so wahr mir Codd helfe.
Vorlesung: 62 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 6262
Normalisierung-BeispielNormalisierung-Beispiel
Vorlesung: 63 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 6363
Bsp: vor NormalisierungBsp: vor Normalisierung
KundeID
Nachname Telefon AuftragID Auftrag-datum
Bearbeiter Abteilung
1 Meier 0511-12345,0179-222222
200 10.1.12 Mirka Einkauf
2 Müller NULL 201 11.1.12 Mirka Einkauf
3 Schulze 0211-12345
202 11.1.12 Erik Versand
Vorlesung: 64 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 6464
Bsp.: erste NormalformBsp.: erste Normalform
KundeID
Nachname AuftragID Auftrag-datum
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
TelefonID KundeID Telefonnr
100 1 0511-12345
101 1 0179-222222
102 3 0211-12345
Kunde:Kunde:
Telefon:Telefon:
Vorlesung: 65 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 6565
Bsp.: zweite NormalformBsp.: zweite Normalform
KundeID
Nachname
1 Meier
2 Müller
3 Schulze
TelefonID KundeID Telefonnr
100 1 0511-12345
101 1 0179-222222
102 3 0211-12345
Kunde:Kunde: Telefon:Telefon:
AuftragID Auftrag-datum
Bearbeiter Abteilung KundeID
200 10.1.12 Mirka Einkauf 1
201 11.1.12 Mirka Einkauf 2
202 11.1.12 Erik Versand 3
Auftrag:Auftrag:
Vorlesung: 66 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 6666
Bsp.: dritte NormalformBsp.: dritte Normalform
KundeID
Nachname
1 Meier
2 Müller
3 Schulze
TelefonID KundeID Telefonnr
100 1 0511-12345
101 1 0179-222222
102 3 0211-12345
Kunde:Kunde: Telefon:Telefon:
AuftragID Auftrag-datum
BearbeiterID
KundeID
200 10.1.12 1000 1
201 11.1.12 1000 2
202 11.1.12 1001 3
Auftrag:Auftrag:BearbeiterID
Bearbeiter Abteilung
1000 Mirka Einkauf
1001 Erik Versand
Bearbeiter:Bearbeiter:
Vorlesung: 67 BIS Unit II 2012 Prof. Dr. G. Hellberg
ENDEENDE
Fragen?Fragen?
Vorlesung: 68 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 6868
LiteraturLiteratur
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: 69 BIS Unit II 2012 Prof. Dr. G. Hellberg
QuellenQuellenTannenbaum, Andrew, Moderne BetriebssystemeH. Bethge, Vorlesungsskript DB, FHDWR. Walther, Vorlesungsskript BIS, FHDW 2011G. Hellberg, Vorlesungsskripte BIS, FHDW 2003G. Hellberg, diverse Vorlesungsskripte Betriebssysteme, FHDW 2000-2011G. Hellberg, Vorlesungsskripte Netzwerke, FHDW 2000-2011G. Hellberg, Vorlesungsskripte Technische Grundlagen, FHDW 2007-2011Microsoft WhitepapersDiverse Quellen Internet (Wikipedia)