Datenbanken I Aufbau von Datenbankmanagementsystemen Relationale Datenbanksysteme Normalisierung
Datenbanken I • Aufbau von Datenbankmanagementsystemen • Relationale Datenbanksysteme • Normalisierung • Entity-Relationship-Diagramme • Praxis: Datenbanksystem My. SQL • SQL-Abfragen mit My. SQL Dr. Heidrun Bethge Datenbanken I 1
Datenbanken Folgequartale • 4. Quartal • Einführung in Oracle • komplexe SQL-Abfragen mit My. SQL und Oracle • Optimierung von Abfragen • Datenzugriffsstrukturen • Trigger • Einführung in Transaktionen • Sicherheit • 5. Quartal Informatik: Transaktionen • Recoverymechanismen • Recovery und Datensicherheit in My. SQL und Oracle • Transaktionen Dr. Heidrun Bethge • Probleme der parallelen Transaktionsausführung • Transaktionen in vernetzten Datenbanksystemen • 2 Phase Commit • 5. Quartal Wirtschaftsinformatik: Data Warehouses • Was ist ein Data Warehouse? • Prinzipien und Abgrenzungen zu transaktionsgesteuerten Datenbanksystemen • Datenstrukturen in Data Warehouses • Optimierung der Datenzugriffe • Data Warehouses mit SAP BW • Data Mining Datenbanken I 2
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 Dr. Heidrun Bethge Datenbanken I 3
Aufbau von Datenbankmanagement. Systemen Dr. Heidrun Bethge Datenbanken I 4
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 Dr. Heidrun Bethge Datenbanken I 5
Datenbanksystem. Generationen 1. 50 er J. Dateisystem auf Band, nur sequentieller Zugriff, Batchbetrieb 2. 60 er J. Dateisystem auf Platte, Random Access, Dialogbetrieb, Indexdateien, Dateiverwaltungssystem 3. 70 er J. Prärelationale Systeme (Netzwerk-, hierarchische Systeme) 4. 80 er J. Relationale Systeme 5. 90 er J. objektbasierte Systeme Dr. Heidrun Bethge Datenbanken I 6
1. Generation (50 er J. ) Anwendung 1 – Dateiorganisation 1. . . primitive Ein-/Ausgabe. Software Anwendung n – Datei 1. . . Datei n Dateiorganisation n anwendungsspezifische Datenorganisation Geräteabhängigkeit der Programme Redundanz, Inkonsistenz der Daten Dr. Heidrun Bethge Datenbanken I 7
50 er 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. Dr. Heidrun Bethge Datenbanken I 8
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 Dr. Heidrun Bethge Datenbanken I 9
2. Generation (60 er J. ) Datei(en) 1 Anwendung 1 Dateiverwaltungssystem . . . Anwendung n . . . mit gemeinsamem Zugriff Datei(en) n Programmbibliothek • • teilw. standardisierte Datenorganisation Dienstprogramme wie z. B. Sortierer Geräteunabhängigkeit jedoch: Abhängigkeit von Speicherstruktur und Zugriffspfaden Dr. Heidrun Bethge Datenbanken I 10
Datenbanksysteme (seit 70 er 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 Dr. Heidrun Bethge Datenbanken I 11
Aufbau von Datenbanksystemen Anwendungsprogramme Datenbanksystem (DBS) Benutzer, Administratoren Benutzerschnittstelle Datenbankmanagementsystem (DBMS) Datenbank (DB) Dr. Heidrun Bethge Datenbanken I Betriebssystem Hauptspeicher Sekundärspeicher 12
Aufgaben von Datenbankmanagementsystemen • 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 Dr. Heidrun Bethge Datenbanken I 13
Datenmodelle • Hierarchisches Datenmodell IMS (Information Management System) IBM • Netzwerkmodell UDS von Siemens • Relationales Datenmodell d. Base, My. SQL, Access, SQL-Server, . . . • Objektorientiertes Datenmodell teilw. Oracle, O 2 von O 2 Technology Dr. Heidrun Bethge Datenbanken I 14
Hierarchisches Datenmodell • 1960 entwickelt • Baumstruktur mit einem Ausgangselement (Root) • Jedes Element hat maximal einen Vorgänger (Parent) • Jedes Element hat beliebig viele Nachfolger (Children) Dr. Heidrun Bethge Datenbanken I 15
Beispiel Hierarchisches Modell Dr. Heidrun Bethge Datenbanken I 16
Ausprägung Hierarchisches Modell Dr. Heidrun Bethge Datenbanken I 17
Hierarchisches Modell heute • LDAP (Lightweight Directory Access Protocol) organisiert Verzeichnisdienst • Verzeichnis- und Dateistrukturen von Betriebssystemen • HTML / XML • IMS (Information Management System) von IBM Dr. Heidrun Bethge Datenbanken I 18
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. Dr. Heidrun Bethge Datenbanken I 19
Beispiel Netzwerk-Modell Student Wacker Mustermann ss SV vs Vorlesung Dr. Heidrun Bethge Java Stochastik Datenbanken I Zahlentheorie 20
Relationale Datenbanksysteme Dr. Heidrun Bethge Datenbanken I 21
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. Dr. Heidrun Bethge Ziel: Erfüllung der Codd-Regeln, Trennung DB-Anwendung und Datenbanken I 22
Beispiel 3 -Ebenen. Architektur Bundesbahn: externe Ebene konzeptionelle Ebene interne Ebene Personaldatei: externe Ebene konzeptionelle Ebene interne Ebene Dr. Heidrun Bethge Städteverbindungen Kursbuch Abbildung auf Dateisystem Angestellte mit Namen, Wohnorten und Geburtstagsliste mit Name, Datum, Alter Abbildung auf Dateisystem Datenbanken I 23
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 Dr. Heidrun Bethge Datenbanken I 24
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 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 Dr. Heidrun Bethge Datenbanken I 25
Codds 12 Regeln für relationale DBS 8. Physische Datenunabhängigkeit Anwendungsprogramme unabh. vom Speicherort 9. Logische Datenunabhängigkeit Anwendungsprogramme logisch unabhängig v. Tabellen, ermöglicht durch Views 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 Dr. Heidrun Bethge Datenbanken I 26
Gemeinsame Merkmale relationaler DBMS • 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 Dr. Heidrun Bethge Datenbanken I 27
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. Dr. Heidrun Bethge Datenbanken I 28
Relationale Datenbanktabelle Tabelle Zeile Feld Primärschlüssel Dr. Heidrun Bethge Datenbanken I Spalte 29
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. Dr. Heidrun Bethge Datenbanken I 30
Primärschlüssel Der Primärschlüssel ermöglicht die eindeutige Identifizierung eines Datensatzes dadurch, dass sein Wert in einer Tabelle nur einziges Mal vorkommt. Er setzt sich aus einem oder mehreren Datenfeldern zusammen. Jede Tabelle sollte einen Primärschlüssel besitzen. Dr. Heidrun Bethge Datenbanken I 31
Fremdschlüssel Ein oder mehrere Tabellenfelder, das auf das Primärschlüsselfeld in einer anderen Tabelle Bezug nehmen. Ein Fremdschlüssel gibt an, in welcher Beziehung die Tabellen zueinander stehen; die Daten des Fremdschlüssels müssen mit denen der Primärschlüsselfelder übereinstimmen. Dr. Heidrun Bethge Datenbanken I 32
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. Dr. Heidrun Bethge Datenbanken I 33
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. Dr. Heidrun Bethge Datenbanken I 34
Relationenmodell • Relation ~ Tabelle • Tupel ~ Datensatz • Attribut ~ Feld Dr. Heidrun Bethge Datenbanken I 35
Normalisierung Dr. Heidrun Bethge Datenbanken I 36
Anomalien Kurs. Nr 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 Dr. Heidrun Bethge Datenbanken I 37
Anomalien vermeiden Um Anomalien zu vermeiden, wurden – Normalformen, – Entwurfstheorie und – Entwurfsregeln formuliert. Dr. Heidrun Bethge Datenbanken I 38
Normalisierung Normalformen: Regeln des Tabellenentwurfs. Beim Normalisierungsprozess werden die Daten auf mehrere Tabellen verteilt. Ziel ist eine • konsistente Datenhaltung • ohne Redundanzen • ohne Anomalien. Dr. Heidrun Bethge Datenbanken I 39
Normalformen-Historie • Ursprünglich wurden 1973 von Edgar F. Codd 3 Normalformen (1 NF, 2 NF, 3 NF) vorgeschlagen. • Jede Stufe beinhaltet die vorhergehende 1 NF ->2 NF->3 NF • 3 NF wurde 1974 revidiert -> Boyce-Codd-NF (BCNF) • Später weitere (4 NF, 5 NF) Normalformen, eher weniger bedeutend • Weg: Aufspaltung in Relationen Dr. Heidrun Bethge Datenbanken I 40
Normalformen beinhalten einander Dr. Heidrun Bethge Datenbanken I 41
Anforderungen an NF • Aufspaltung in Relationen muss verlustfrei geschehen – kein Verlust von Informationen – keine falschen Informationen – kein Verlust an Integritätsbedingungen Dr. Heidrun Bethge Datenbanken I 42
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. . . ) Dr. Heidrun Bethge Datenbanken I 43
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. Dr. Heidrun Bethge Datenbanken I 44
Erste Normalform Beispiel Spalten mit gleichartigem Inhalt eliminieren Verboten sind mengenwertige Attribute: Vater Mutter Kinder Johann Martha {Else, Lucia} Johann Maria {Theo, Josef} Heinz {Cleo} Martha Verlangt werden atomare Attribute: Vater Mutter Kind Johann Martha Else Johann Martha Lucia Johann Maria Theo Johann Maria Josef Heinz Cleo Dr. Heidrun Bethge Martha Datenbanken I 45
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) Dr. Heidrun Bethge Datenbanken I 46
Definition funktionale Abhängigkeit [X] ist der Wert von Attribut X im Tupel z. B. Datensatz 12[Kundennr]=123 Dr. Heidrun Bethge Datenbanken I 47
Beispiel funktionale Abhängigkeit Mitarbeiter(Mitarbeiter. ID, Nachname, Vorname, Abteilung. ID, Abteilungsleiter, Unternehmen, Unternehmensanschrift, Berufsgruppe, Gehaltsklasse) Dr. Heidrun Bethge Datenbanken I 48
Ableitung von funktionalen Abhängigkeiten A a 1 a 2 a 3 a 4 Dr. Heidrun Bethge B b 1 b 2 b 1 C c 1 c 1 Datenbanken I 49
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(Kunden. ID, Nachname, PLZ, Ort) Kunden. ID, Nachname PLZ, Ort aber Kunden. ID, Nachname ≠> PLZ, Ort , da Kunden. ID PLZ, Ort Dr. Heidrun Bethge Datenbanken I 50
Schlüssel Kunden. ID Vorname Nachname PLZ Ort 1 Martha Muster 12345 Norddorf 2 Heinz Huber 45678 Weststadt Kunden. ID Vorname, Nachname, PLZ, Ort es gilt auch Kunden. ID →Kunden. ID, 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 Dr. Heidrun Bethge Datenbanken I 51
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) Dr. Heidrun Bethge Datenbanken I 52
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. Dr. Heidrun Bethge Datenbanken I 53
Beispiel Studentenbelegung Schlüsselkandiaten: Matr. Nr Vorl. Nr 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 28106 5259 Carnap 3 . . . {Matr. Nr, Vorl. Nr} Nichtprimärattribute: Matr. Nr Name Vorl. Nr Semester {Name, Semester} Name ist nicht voll funktional abhängig von {Matr. Nr, Vorl. Nr} keine 2. Normalform Dr. Heidrun Bethge Datenbanken I 54
Beispiel Hörsaal Vorlesung Dozent Termin Raum Backen ohne Fett Kant 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} Dr. Heidrun Bethge Datenbanken I 55
Beispiel Student • Matr. Nr Name Fachbereich Dekan 29555 Feuerbach 6 Matthies 27550 Schopenhauer 6 Matthies 26120 Fichte 4 Kapphan 25403 Jonas 6 Matthies 28106 Carnap 7 Weingarten Student in zweiter Normalform aber • Abhängigkeiten zwischen den Nichtprimärattributen: Fachbereich → Dekan Dr. Heidrun Bethge Datenbanken I 56
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: Matr. Nr Fachbereich Dekan Dr. Heidrun Bethge Datenbanken I 57
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. Dr. Heidrun Bethge Datenbanken I 58
Beispiel 3. Normalform Mitarbeiter. ID Projekt. ID Aufgabe Anz_Stundensatz 1 1 Entwicklung 70 50 2 1 Assistenz 30 35 3 2 Entwicklung 45 50 Primärschlüssel ist {Mitarbeiter. ID, Projekt. ID} 2. Normalform ist erfüllt. Jedoch ist Mitarbeiter. ID → Aufgabe → Stundensatz somit ist die Relation nicht in der 3. Normalform Aufteilung in 2 Tabellen: Projekt. Mit(Mitarbeiter. ID, Projekt. ID, Aufgabe. ID, Stunden) Aufgabe(Aufgabe. ID, Bezeichnung, Stundensatz) Dr. Heidrun Bethge Datenbanken I 59
Professoren. Adr(Pers. Nr, Rang, Name, Straße, PLZ, Ort, Bundesland, Vorwahl, Landesregierung, Raum) Rang Name Pers. Nr Straße PLZ Ort Raum Alle Nichtprimärattribute sind voll funktional abhängig von jedem Schlüsselkandidaten. BLandesregierung Pers. Nr {Ort, BLand} Vorwahl Dr. Heidrun Bethge Vorwahl nicht in 3. Normalform Datenbanken I 60
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 Nicht-Schlü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. Dr. Heidrun Bethge Datenbanken I 61
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. Dr. Heidrun Bethge Datenbanken I 62
Normalisierung-Beispiel Dr. Heidrun Bethge Datenbanken I 63
Bsp: vor Normalisierung Kunde. ID Nachname Telefon Auftrag. ID 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 Dr. Heidrun Bethge Datenbanken I 64
Bsp. : erste Normalform Kunde: Kunde. ID Nachname Auftrag. ID 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: Telefon. ID Kunde. ID Telefonnr 100 1 0511 -12345 101 1 0179 -222222 102 3 0211 -12345 Dr. Heidrun Bethge Datenbanken I 65
Bsp. : zweite Normalform Kunde: Telefon: Kunde. ID Nachname Telefon. ID Kunde. ID Telefonnr 1 Meier 100 1 0511 -12345 2 Müller 101 1 0179 -222222 3 Schulze 102 3 0211 -12345 Auftrag: Auftrag. ID Auftragdatum Bearbeiter Abteilung Kunde. ID 200 10. 1. 12 Mirka Einkauf 1 201 11. 1. 12 Mirka Einkauf 2 202 11. 1. 12 Erik Versand 3 Dr. Heidrun Bethge Datenbanken I 66
Bsp. : dritte Normalform Kunde: Telefon: Kunde. ID Nachname Telefon. ID Kunde. ID Telefonnr 1 Meier 100 1 0511 -12345 2 Müller 101 1 0179 -222222 3 Schulze 102 3 0211 -12345 Auftrag: Bearbeiter: Auftrag. ID Auftragdatum Bearbeiter ID Kunde. ID 200 10. 1. 12 1000 201 11. 1. 12 202 11. 1. 12 Dr. Heidrun Bethge Bearbeiter. ID Bearbeiter Abteilung 1 1000 Mirka Einkauf 1000 2 1001 Erik Versand 1001 3 Datenbanken I 67
Boyce-Codd-Normalform • Eine Relation R ist in der Boyce-Codd. Normalform (BCNF), falls für jede funktionale Abhängigkeit α→β mindestens eine der folgenden Bedingungen gilt: – β α, d. h. die Abhängigkeit ist trivial. – α ist Superschlüssel von R. • Superschlüssel: In der Relation R ist α R ein Superschlüssel, falls gilt: α → R Dr. Heidrun Bethge Datenbanken I 68
Bsp. : vierte Normalform unnormalisiert Methode Autor Begriff Struktogramm Nassi Sequenz Shneiderman Iteration Verzweigung Datenmodell Chen Entitätsmenge Beziehungsmenge Dr. Heidrun Bethge Datenbanken I 69
vierte Normalform Ein Attribut C ist mehrwertig abhängig vom Attribut A (ausgedrückt durch die Schreibweise A C), falls zu jeder Kombination eines bestimmten Wertes aus A mit einem beliebigen Wert aus B eine identische Menge von Werten aus C erscheint. Eine mehrwertige Abhängigkeit A C heißt nicht trivial, wenn außer A und C noch weitere Attribute in der Relation enthalten sind. Die vierte Normalform lässt es nicht zu, dass in einer Relation zwei nicht triviale voneinander verschiedene mehrwertige Abhängigkeiten vorliegen. Dr. Heidrun Bethge Datenbanken I 70
Entity-Relationship. Diagramme Dr. Heidrun Bethge Datenbanken I 71
Datenbankentwurf Die Aufgabe des Datenbankentwurfs ist der Entwurf der logischen und physischen Struktur einer Datenbank so, dass die Informationsbedürfnisse der Benutzer in einer Organisation für bestimmte Anwendungen adäquat befriedigt werden können. Dr. Heidrun Bethge Datenbanken I 72
Aspekte der Qualitätssicherung • Vollständigkeit (Sind alle relevanten Aspekte erfasst? Wird jedes erstellte Konzept verlangt? ) • Korrektheit (Richtige Verwendung der Konzepte des Datenmodells) • Minimalität (Jede Anforderung kommt nur einmal im Schema vor. Redundanzvermeidung) • Lesbarkeit (Schema sollte selbsterklärend sein und gut dokumentiert. ) • Modifizierbarkeit (Nachträgliche Schema. Modifikation soll möglich sein) Dr. Heidrun Bethge Datenbanken I 73
Phasen des DBEntwurfsprozesses ER-Modell logische DBStruktur physische DBStruktur Dr. Heidrun Bethge Datenbanken I 74
Entity. Relationship. Modelle Dr. Heidrun Bethge Datenbanken I 75
Entity-Relationship Buch Entity(-Set) Dr. Heidrun Bethge Datenbanken I Attribute besitzen Wertebereich (Domain) 76
Detaillierteres Entity. Diagramm Buch mehrwertiges Attribut Primärschlüssel Dr. Heidrun Bethge zusammengesetztes Attribut Datenbanken I 77
Beziehung zwischen Büchern und Lesern n 1 Dr. Heidrun Bethge Datenbanken I 78
m: 1 -Beziehung Person-Stadt Dr. Heidrun Bethge Datenbanken I 79
m: n-Beziehung Dr. Heidrun Bethge Datenbanken I 80
Rekursive Beziehung zwischen Personen Angestellter. Person Chef ist Chef von Dr. Heidrun Bethge Datenbanken I Vater. Sohn ist Vater von 81
Dreistellige Beziehung Dr. Heidrun Bethge Datenbanken I 82
IS-A Beziehung Dr. Heidrun Bethge Datenbanken I 83
Totale, disjunkte Spezialisierung Dr. Heidrun Bethge Datenbanken I 84
partielle, nicht disjunkte Spezialisierung Dr. Heidrun Bethge Datenbanken I 85
partielle, disjunkte Spezialisierung Dr. Heidrun Bethge Datenbanken I 86
totale, nicht disjunkte Spezialisierung Dr. Heidrun Bethge Datenbanken I 87
Entity-Relationship-Konstrukte Dr. Heidrun Bethge Datenbanken I 88
Konzeptioneller Entwurf mit dem ER-Modell • Beispiel: top-down-Vorgehensweise • Detaillierung durch Anwendung von Transformationen wie: – Entity-Verfeinerung – Relationship-Verfeinerung – Attribut-Verfeinerung Dr. Heidrun Bethge Datenbanken I 89
Erstes Teildiagramm Fluggesellschaft Dr. Heidrun Bethge Datenbanken I 90
Zweites Teildiagramm Fluggesellschaft Dr. Heidrun Bethge Datenbanken I 91
Drittes Teildiagramm Fluggesellschaft Dr. Heidrun Bethge Datenbanken I 92
Transformation ER -> Relationen • Jeder Entity-Typ wird in ein Relationenschema (Tabelle) transformiert. • Jeder Relationship-Typ wird in ein Relationenschema transformiert. Ausnahme: 1: 1 und 1: n-Beziehungen; hier reicht die Einführung von Fremdschlüsseln. • IS-A-Beziehungen werden durch Inklusionsabhängigkeiten ausgedrückt. • Zusammengesetzte Attribute werden entweder durch ihre Komponenten ersetzt oder die Komponenten werden weggelassen. • Mehrwertige Attribute erfordern Einführung neuer Relationenschemata. Dr. Heidrun Bethge Datenbanken I 93
- Slides: 93