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

[PPT]Studiengang Informatik FHDW · Web viewStudiengang BWL FHDW Vorlesung: Betriebliche Informationssysteme II Datenbanken Teil 2 BI-U2 3. Quartal 2012 Datenbanken I * Bsp.: dritte

Embed Size (px)

Citation preview

Vorlesung: 1 BIS Unit II 2012 Prof. Dr. G. Hellberg

Studiengang BWL FHDWStudiengang BWL FHDW

Vorlesung: Betriebliche Informationssysteme IIDatenbankenTeil 2 BI-U23. Quartal 2012

Vorlesung: 2 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 22

Datenbanken IDatenbanken I

Aufbau von DatenbankmanagementsystemenRelationale DatenbanksystemeNormalisierungEntity-Relationship-DiagrammePraxis: 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, Batchbetrieb2. 60er J. Dateisystem auf Platte, Random

Access, Dialogbetrieb, Indexdateien, Dateiverwaltungssystem

3. 70er J. Prärelationale Systeme (Netzwerk-, hierarchische Systeme)

4. 80er J. Relationale Systeme5. 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 DateienDateiorganisation 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 ausend

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) IBMNetzwerkmodellUDS von SiemensRelationales 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 BetriebssystemenHTML / XMLIMS (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ädteverbindungenkonzeptionelle Ebene Kursbuchinterne Ebene Abbildung auf Dateisystem

Personaldatei:externe Ebene Angestellte mit Namen,

Wohnorten und Geburtstagkonzeptionelle Ebene Geburtstagsliste mit

Name, Datum, Alterinterne 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-Regeln3-Ebenen-Architekturstandardisierte Datenbanksprache SQL (structured query language)Einbettung von SQL in kommerzielle ProgrammiersprachenWerkzeuge 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 ~ TabelleTupel ~ DatensatzAttribut ~ 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->3NF3NF wurde 1974 revidiert -> Boyce-Codd-NF (BCNF)Später weitere (4NF, 5NF) Normalformen, eher weniger bedeutendWeg: 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ängigkeitensind 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 Ca1 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,ZZZ 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?

Vorlesung: 68 BIS Unit II 2012 Prof. Dr. G. Hellberg Datenbanken IDatenbanken I 6868

LiteraturLiteratur

Heuer, A.; Saake, G.: Datenbanken: Konzepte und Sprachen. mitp-VerlagKemper, A., Eickler, A.: Datenbanksysteme. OldenbourgVossen, 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. mitpCordts, 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)