Studiengang BWL FHDW Vorlesung Betriebliche Informationssysteme II Datenbanken

Studiengang BWL FHDW Vorlesung: Betriebliche Informationssysteme II Datenbanken Teil 2 BI-U 2 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 My. SQL-Abfragen mit My. SQL Vorlesung: 2 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 2

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 Vorlesung: 3 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 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 3

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: 4 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 4

Aufbau von Datenbankmanagement. Systemen Vorlesung: 5 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 5

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: 6 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 6

Datenbanksystem-Generationen 1. 2. 3. 4. 5. 50 er J. Dateisystem auf Band, nur sequentieller Zugriff, Batchbetrieb 60 er J. Dateisystem auf Platte, Random Access, Dialogbetrieb, Indexdateien, Dateiverwaltungssystem 70 er J. Prärelationale Systeme (Netzwerk-, hierarchische Systeme) 80 er J. Relationale Systeme 90 er J. objektbasierte Systeme Vorlesung: 7 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 7

1. Generation (50 er 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: 8 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 8

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. Vorlesung: 9 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 9

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: 10 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 10

2. Generation (60 er 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: 11 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 11

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 Vorlesung: 12 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 12

Aufbau von Datenbanksystemen Anwendungsprogramme Datenbanksystem (DBS) Benutzer, Administratoren Datenbankmanagementsystem (DBMS) Datenbank (DB) Vorlesung: 13 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I Benutzerschnittstelle Betriebssystem Hauptspeicher Sekundärspeicher 13

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: 14 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 14

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 Vorlesung: 15 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 15

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: 16 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 16

Beispiel Hierarchisches Modell Vorlesung: 17 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 17

Ausprägung Hierarchisches Modell Vorlesung: 18 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 18

Hierarchisches Modell heute LDAP (Lightweight Directory Access Protocol) organisiert Verzeichnisdienst Verzeichnis- und Dateistrukturen von Betriebssystemen HTML / XML IMS (Information Management System) von IBM Vorlesung: 19 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 19

Netzwerkmodell • • • Vorlesung: 20 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 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. 20

Beispiel Netzwerk-Modell Student Wacker Mustermann ss SV vs Vorlesung: 21 BIS Unit II 2012 Prof. Dr. G. Hellberg Java Datenbanken I Stochastik Zahlentheorie 21

Relationale Datenbanksysteme Vorlesung: 22 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 22

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: 23 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 23

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: 24 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 24

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: 25 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 25

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 Vorlesung: 26 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 26

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: 27 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 27

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: 28 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 28

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: 29 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 29

Relationale Datenbanktabelle Tabelle Zeile Primärschlüssel Vorlesung: 30 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I Feld Spalte 30

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: 31 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 31

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. Vorlesung: 32 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 32

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: 33 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 33

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: 34 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 34

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: 35 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 35

Relationenmodell Relation ~ Tabelle Tupel ~ Datensatz Attribut ~ Feld Vorlesung: 36 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 36

Normalisierung Vorlesung: 37 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 37

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 Vorlesung: 38 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 38

Anomalien vermeiden Um Anomalien zu vermeiden, wurden – Normalformen, – Entwurfstheorie und – Entwurfsregeln formuliert. Vorlesung: 39 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 39

Normalisierung Normalformen: Regeln des Tabellenentwurfs. Beim Normalisierungsprozess werden die Daten auf mehrere Tabellen verteilt. Ziel ist eine konsistente Datenhaltung ohne Redundanzen ohne Anomalien. Vorlesung: 40 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 40

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 wurde 1974 revidiert -> Boyce-Codd-NF (BCNF) Später weitere (4 NF, 5 NF) Normalformen, eher weniger bedeutend Weg: Aufspaltung in Relationen Vorlesung: 41 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 41

Normalformen beinhalten einander Vorlesung: 42 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 42

Anforderungen an NF Aufspaltung in Relationen muss verlustfrei geschehen kein Verlust von Informationen keine falschen Informationen kein Verlust an Integritätsbedingungen Vorlesung: 43 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 43

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: 44 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 44

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: 45 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 45

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: 46 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 46

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: 47 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 47

Definition funktionale Abhängigkeit [X] ist der Wert von Attribut X im Tupel z. B. Datensatz 12[Kundennr]=123 Vorlesung: 48 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 48

Beispiel funktionale Abhängigkeit Mitarbeiter(Mitarbeiter. ID, Nachname, Vorname, Abteilung. ID, Abteilungsleiter, Unternehmen, Unternehmensanschrift, Berufsgruppe, Gehaltsklasse) Vorlesung: 49 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 49

Ableitung von funkt. Abhängigkeiten A a 1 a 2 a 3 a 4 Vorlesung: 50 BIS Unit II 2012 Prof. Dr. G. Hellberg B b 1 b 2 b 1 Datenbanken I C c 1 c 1 50

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 Vorlesung: 51 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 51

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 Vorlesung: 52 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 52

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: 53 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 53

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: 54 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 54

Beispiel Studentenbelegung Schlüsselkandiaten: {Matr. Nr, Vorl. Nr} 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 . . . Nichtprimärattribute: {Name, Semester} Matr. Nr Name ist nicht voll funktional abhängig von {Matr. Nr, Vorl. Nr} Vorl. Nr Semester keine 2. Normalform Vorlesung: 55 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 55

Beispiel Hörsaal Vorlesung Dozent 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 Backen ohne Fett Kant Schlüsselkandidaten: {Vorlesung, Termin} {Dozent, Termin} Es gibt keine Nicht-Primärattribute 2. Normalform {Raum, Termin} Vorlesung: 56 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 56

Beispiel Student Matr. Nr Fachbereich Dekan 29555 Feuerbach 6 Matthies 27550 Schopenhauer 6 Matthies 26120 Fichte 4 Kapphan 25403 Jonas 6 Matthies 28106 • Name Carnap 7 Weingarten Student in zweiter Normalform aber • Abhängigkeiten zwischen den Nichtprimärattributen: Fachbereich → Dekan Vorlesung: 57 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 57

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 Vorlesung: 58 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 58

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: 59 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 59

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) Vorlesung: 60 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 60

Professoren. Adr(Pers. Nr, Rang, Name, Straße, PLZ, Ort, Bundesland, Vorwahl, Landesregierung, Raum) Rang Name Pers. Nr Straße PLZ Ort Raum BLand Alle Nichtprimärattribute sind voll funktional abhängig von jedem Schlüsselkandidaten. Landesregierung Pers. Nr {Ort, BLand} Vorwahl Vorlesung: 61 BIS Unit II 2012 Prof. Dr. G. Hellberg Vorwahl Datenbanken I nicht in 3. Normalform 61

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. Vorlesung: 62 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 62

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: 63 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 63

Normalisierung-Beispiel Vorlesung: 64 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 64

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 Vorlesung: 65 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 65

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 Vorlesung: 66 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 66

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 Vorlesung: 67 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I 67

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: Auftrag. ID Auftragdatum Bearbeiter ID Kunde. ID 200 10. 1. 12 1000 1 201 11. 1. 12 1000 2 202 11. 1. 12 1001 3 Vorlesung: 68 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I Bearbeiter: Bearbeiter. I D Bearbeiter Abteilung 1000 Mirka Einkauf 1001 Erik Versand 68

ENDE Fragen? Vorlesung: 69 BIS Unit II 2012 Prof. Dr. G. Hellberg

Quellen Tannenbaum, Andrew, Moderne Betriebssysteme 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: 70 BIS Unit II 2012 Prof. Dr. G. Hellberg