Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Vorlesung: 1 BIS Unit II 2012 Prof. Dr. G. Hellberg Studiengang BWL FHDW Vorlesung: Betriebliche Informationssysteme II Datenbanken Teil 2 BI-U2 2. Quartal.

Ähnliche Präsentationen


Präsentation zum Thema: "Vorlesung: 1 BIS Unit II 2012 Prof. Dr. G. Hellberg Studiengang BWL FHDW Vorlesung: Betriebliche Informationssysteme II Datenbanken Teil 2 BI-U2 2. Quartal."—  Präsentation transkript:

1 Vorlesung: 1 BIS Unit II 2012 Prof. Dr. G. Hellberg Studiengang BWL FHDW Vorlesung: Betriebliche Informationssysteme II Datenbanken Teil 2 BI-U2 2. Quartal 2012

2 Vorlesung: 2 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I2 Aufbau von Datenbankmanagementsystemen Relationale Datenbanksysteme Normalisierung Entity-Relationship-Diagramme Praxis: Datenbanksystem MySQL SQL-Abfragen mit MySQL

3 Vorlesung: 3 BIS Unit II 2012 Prof. Dr. G. Hellberg Aufbau von Datenbankmanagement- Systemen Datenbanken I3

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

5 Vorlesung: 5 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I5Datenbanksystem-Generationen 1. 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

6 Vorlesung: 6 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I6 1. Generation (50er J.) Anwendung 1 – Dateiorganisation 1... Anwendung n – Dateiorganisation n primitive Ein-/Ausgabe- Software Datei 1... Datei n anwendungsspezifische Datenorganisation Geräteabhängigkeit der Programme Redundanz, Inkonsistenz der Daten

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

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

9 Vorlesung: 9 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I9 2. Generation (60er J.) Dateiverwaltungs- system Anwendung 1... Anwendung n Datei(en) 1... mit gemeinsamem Zugriff Datei(en) n Programmbibliothek teilw. standardisierte Datenorganisation teilw. standardisierte Datenorganisation Dienstprogramme wie z. B. Sortierer Dienstprogramme wie z. B. Sortierer Geräteunabhängigkeit Geräteunabhängigkeit jedoch: Abhängigkeit von Speicherstruktur und Zugriffspfaden jedoch: Abhängigkeit von Speicherstruktur und Zugriffspfaden

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

11 Vorlesung: 11 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I11 Aufbau von Datenbanksystemen Daten- bank (DB) Datenbank-management-system(DBMS) Datenbank- system (DBS) Benutzer- schnittstelle BetriebssystemHauptspeicherSekundärspeicher Anwendungs- programme Benutzer, Administratoren

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

13 Vorlesung: 13 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I13Datenmodelle Hierarchisches Datenmodell IMS (Information Management System) IBM Netzwerkmodell UDS von Siemens Relationales Datenmodell dBase, MySQL, Access, SQL-Server,... Objektorientiertes Datenmodell teilw. Oracle, O 2 von O 2 Technology

14 Vorlesung: 14 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I14 Hierarchisches Datenmodell 1960 entwickelt 1960 entwickelt Baumstruktur mit einem Ausgangselement (Root) Baumstruktur mit einem Ausgangselement (Root) Jedes Element hat maximal einen Vorgänger (Parent) Jedes Element hat maximal einen Vorgänger (Parent) Jedes Element hat beliebig viele Nachfolger (Children) Jedes Element hat beliebig viele Nachfolger (Children)

15 Vorlesung: 15 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I15 Beispiel Hierarchisches Modell

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

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

18 Vorlesung: 18 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I18 Netzwerkmodell Netzwerkmodell Ab etwa 1970 fand das hierarchische Datenmodell seine Erweiterung im Netzwerkmodell, das nun auch Querverbindungen zwischen Baumstrukturen zuließ. 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. Jeder Knoten kann mehrere übergeordnete Knoten haben. Jede Netzwerkstruktur lässt sich durch Einführung redundanter Knoten als hierarchische Baumstruktur darstellen. Jede Netzwerkstruktur lässt sich durch Einführung redundanter Knoten als hierarchische Baumstruktur darstellen.

19 Vorlesung: 19 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I19 Beispiel Netzwerk-Modell Student SV Vorlesung ss vs Mustermann Wacker JavaStochastik Zahlentheorie

20 Vorlesung: 20 BIS Unit II 2012 Prof. Dr. G. Hellberg Relationale Datenbanksysteme Datenbanken I20

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

22 Vorlesung: 22 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I22 Beispiel 3-Ebenen-Architektur Bundesbahn: externe Ebene Städteverbindungen konzeptionelle EbeneKursbuch interne EbeneAbbildung auf Dateisystem Personaldatei: externe Ebene Angestellte mit Namen, Wohnorten und Geburtstag konzeptionelle EbeneGeburtstagsliste mit Name, Datum, Alter interne EbeneAbbildung auf Dateisystem

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

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

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

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

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

28 Vorlesung: 28 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I28 Relationale Datenbanktabelle Primärschlüssel ZeileFeld Spalte Tabelle

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

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

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

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

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

34 Vorlesung: 34 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I34Relationenmodell Relation~ Tabelle Tupel ~ Datensatz Attribut~ Feld

35 Vorlesung: 35 BIS Unit II 2012 Prof. Dr. G. Hellberg Normalisierung Datenbanken I35

36 Vorlesung: 36 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I36AnomalienLöschanomalieEinfügeanomalieÄnderungsanomalie KursNrKurs_BezDozentAnredeVornameNachnameTelefon 2Englisch ILLFrauLisaLustig AlgebraHMHerrHugoMeier BuchführungSSFrauSusiSorglos Englisch IILLFrauLisaLustig ExcelMMHerrMartinSchulze256254

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

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

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

40 Vorlesung: 40 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I40 Normalformen beinhalten einander

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

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

43 Vorlesung: 43 BIS Unit II 2012 Prof. Dr. G. Hellberg Erste 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 I43 Eine Relation ist dann in der ersten Normal- form, wenn alle ihre Attribute atomar sind.

44 Vorlesung: 44 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I44 Erste Normalform Beispiel Spalten mit gleichartigem Inhalt eliminieren Verboten sind mengenwertige Attribute: VaterMutter Kinder JohannMartha{Else, Lucia} JohannMaria{Theo, Josef} HeinzMartha{Cleo} VaterMutterKind JohannMarthaElse JohannMarthaLucia JohannMariaTheo JohannMariaJosef HeinzMarthaCleo Verlangt werden atomare Attribute:

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

46 Vorlesung: 46 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I46 Definition 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]=123

47 Vorlesung: 47 BIS Unit II 2012 Prof. Dr. G. Hellberg Beispiel funktionale Abhängigkeit Mitarbeiter(MitarbeiterID, Nachname, Vorname, AbteilungID, Abteilungsleiter, Unternehmen, Unternehmensanschrift, Berufsgruppe, Gehaltsklasse) Datenbanken I47

48 Vorlesung: 48 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I48 Ableitung von funkt. Abhängigkeiten ABC a1a1 b1b1 c1c1 a2a2 b1b1 c1c1 a3a3 b2b2 c1c1 a4a4 b1b1 c1c1

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

50 Vorlesung: 50 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I50 Schlüssel 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 KundenIDVornameNachnamePLZOrt 1MarthaMuster12345Norddorf 2HeinzHuber45678Weststadt

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

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

53 Vorlesung: 53 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I53Beispiel MatrNrVorlNr NameSemester Fichte Schopenhauer Schopenhauer Carnap Carnap Carnap Carnap Studentenbelegung MatrNr VorlNr Name Semester Schlüsselkandiaten: {MatrNr, VorlNr} Nichtprimärattribute: {Name, Semester} Name ist nicht voll funktional abhängig von {MatrNr, VorlNr} keine 2. Normalform keine 2. Normalform

54 Vorlesung: 54 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I54BeispielSchlüsselkandidaten: {Vorlesung, Termin} {Dozent, Termin} {Raum, Termin} VorlesungDozentTermin Raum Backen ohne FettKantMo, 10:1532/102 Selber AtmenSokratesMo, 14:1531/449 Selber AtmenSokratesDi, 14:1531/449 Schneller BetenSokratesFr, 10:1531/449 Hörsaal Es gibt keine Nicht-Primärattribute 2. Normalform 2. Normalform

55 Vorlesung: 55 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I55Beispiel MatrNrNameFachbereich Dekan Feuerbach6Matthies Schopenhauer6Matthies Fichte4Kapphan Jonas6Matthies Carnap7Weingarten Student Student in zweiter Normalform Student in zweiter Normalformaber Abhängigkeiten zwischen den Nichtprimärattributen: Fachbereich Dekan Abhängigkeiten zwischen den Nichtprimärattributen: Fachbereich Dekan

56 Vorlesung: 56 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I56 Transitive Abhängigkeit MatrNr Fachbereich Dekan Gegeben Attributmenge U mit Teilmengen X,Y,Z Z heißt transitiv abhängig von X, falls gilt X Z = X Z = Y U : X Y =, Y Z = Y U : X Y =, Y Z = / X Y Z, Y X Beispiel:

57 Vorlesung: 57 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I57 Dritte Normalform Die Relation R ist in dritter Normalform, wenn gilt: R ist in zweiter Normalform R ist in zweiter Normalform Jedes Nichtprimärattribut ist nicht-transitiv abhängig von jedem Schlüsselkandidaten 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.

58 Vorlesung: 58 BIS Unit II 2012 Prof. Dr. G. Hellberg Beispiel 3. Normalform MitarbeiterIDProjektIDAufgabeAnz_StundenStundensatz 11Entwicklung Assistenz Entwicklung4550 Datenbanken I58 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)

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

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

61 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 I61 Der Schlüssel, der gesamte Schlüssel, und nichts als der Schlüssel, so wahr mir Codd helfe.

62 Vorlesung: 62 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I62Normalisierung-Beispiel

63 Vorlesung: 63 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I63 Bsp: vor Normalisierung KundeI D NachnameTelefonAuftragIDAuftrag- datum BearbeiterAbteilung 1Meier , MirkaEinkauf 2MüllerNULL MirkaEinkauf 3Schulze ErikVersand

64 Vorlesung: 64 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I64 Bsp.: erste Normalform KundeI D NachnameAuftragIDAuftrag- datum BearbeiterAbteilung 1Meier MirkaEinkauf 2Müller MirkaEinkauf 3Schulze ErikVersand TelefonIDKundeIDTelefonnr Kunde: Telefon:

65 Vorlesung: 65 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I65 Bsp.: zweite Normalform KundeI D Nachname 1Meier 2Müller 3Schulze TelefonIDKundeIDTelefonnr Kunde: Telefon: AuftragIDAuftrag- datum BearbeiterAbteilungKundeID MirkaEinkauf MirkaEinkauf ErikVersand3 Auftrag:

66 Vorlesung: 66 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken I66 Bsp.: dritte Normalform KundeI D Nachname 1Meier 2Müller 3Schulze TelefonIDKundeIDTelefonnr Kunde: Telefon: AuftragIDAuftrag- datum Bearbeiter ID KundeID Auftrag: BearbeiterI D BearbeiterAbteilung 1000MirkaEinkauf 1001ErikVersand Bearbeiter:

67 Vorlesung: 67 BIS Unit II 2012 Prof. Dr. G. HellbergENDE Fragen?

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

69 Vorlesung: 69 BIS Unit II 2012 Prof. Dr. G. HellbergQuellen 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 G. Hellberg, Vorlesungsskripte Netzwerke, FHDW G. Hellberg, Vorlesungsskripte Technische Grundlagen, FHDW Microsoft Whitepapers Diverse Quellen Internet (Wikipedia)


Herunterladen ppt "Vorlesung: 1 BIS Unit II 2012 Prof. Dr. G. Hellberg Studiengang BWL FHDW Vorlesung: Betriebliche Informationssysteme II Datenbanken Teil 2 BI-U2 2. Quartal."

Ähnliche Präsentationen


Google-Anzeigen