Datenbanken i
Download
1 / 100

Datenbanken I - PowerPoint PPT Presentation


  • 110 Views
  • Uploaded on

Datenbanken I. Aufbau von Datenbankmanagementsystemen Relationale Datenbanksysteme Normalisierung Entity- Relationship -Diagramme Praxis: Datenbanksystem MySQL SQL-Abfragen mit MySQL. 4. Quartal Einführung in Oracle komplexe SQL-Abfragen mit Oracle Einführung in Transaktionen

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Datenbanken I' - luke-owen


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Datenbanken i
Datenbanken I

  • Aufbau von Datenbankmanagementsystemen

  • Relationale Datenbanksysteme

  • Normalisierung

  • Entity-Relationship-Diagramme

  • Praxis: Datenbanksystem MySQL

  • SQL-Abfragen mit MySQL

Datenbanken I


Datenbanken folgequartale

4. Quartal

Einführung in Oracle

komplexe SQL-Abfragen mit Oracle

Einführung in Transaktionen

Optimierung von Abfragen

Datenzugriffsstrukturen

Trigger

Sicherheit

5. QuartalTransaktionen

Recoverymechanismen

Recovery und Datensicherheit in Oracle

Transaktionen

Probleme der parallelen Transaktionsausführung

Transaktionen in vernetzten Datenbanksystemen

2-Phasen-Commit

6. Quartal 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 Folgequartale

Datenbanken I


Literatur
Literatur

  • Kemper, A., Eickler, A.: Datenbanksysteme. Oldenbourg

  • Heuer, A.; Saake, G.: Datenbanken: Konzepte und Sprachen. mitp-Verlag

  • Vossen, Gottfried: Datenmodelle, Datenbanksprachen und Datenbankmanagementsysteme. Oldenbourg

  • Date, Chris J.: An Introductionto 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

Datenbanken I



Beispiele f r datenintensive anwendungen
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

Datenbanken I


Aufgaben von datenbank managementsystemen
Aufgaben von Datenbank-managementsystemen

  • 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

Datenbanken I


Datenbanksystem generationen
Datenbanksystem-Generationen

  • 50er J. Dateisystem auf Band, nur sequentieller Zugriff, Batchbetrieb

  • 60er J. Dateisystem auf Platte, Random Access, Dialogbetrieb, Indexdateien, Dateiverwaltungssystem

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

  • 80er J. Relationale Systeme

  • 90er J. objektbasierte Systeme

Datenbanken I


1 generation 50er j
1. Generation (50er J.)

Anwendung 1 –

Dateiorganisation 1

...

Anwendung n –

Dateiorganisation n

primitiveEin-/Ausgabe-Software

Datei 1...

Datei n

anwendungsspezifische Datenorganisation auf Bändern

Geräteabhängigkeit der Programme

Redundanz, Inkonsistenz der Daten

Datenbanken I


Bandlaufwerke bei der nasa
Bandlaufwerke bei der NASA

  • 1962

  • IBM 7090

  • Band:IBM 729

  • 730 m lang

  • 3 MByte

  • 2.95 m/s

Datenbanken I


50er jahre dateisysteme
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 I


Beispiel dateisystem
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 I


2 generation 60er j
2. Generation (60er J.)

Datei(en) 1

...

mit gemeinsamem Zugriff

Datei(en) n

Dateiverwaltungs-system

Anwendung 1

...

Anwendung n

Programmbibliothek

  • teilw. standardisierte Datenorganisation

  • Dienstprogramme wie z. B. Sortierer

  • Geräteunabhängigkeit

  • jedoch: Abhängigkeit von Speicherstruktur und Zugriffspfaden

Datenbanken I


Die erste festplatte ibm 350
Die erste Festplatte: IBM 350

  • 1956 vorgestellt

  • 5 MB Speicherplatz

  • 1 Tonne Gewicht

  • 50 Scheiben

  • 1 Schreib-/Lesekopf

Datenbanken I



Datenbanksysteme seit 70er j
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

Datenbanken I


Aufbau von datenbanksystemen
Aufbau von Datenbanksystemen

Anwendungs-programme

Benutzer, Administratoren

Benutzer-schnittstelle

Betriebssystem

Hauptspeicher

Sekundärspeicher

Datenbank-

management-

system

(DBMS)

Datenbank-system (DBS)

Daten-

bank (DB)

Datenbanken I


Datenmodelle
Datenmodelle

  • Hierarchisches DatenmodellIMS (Information Management System) IBM

  • NetzwerkmodellUDS von Siemens

  • Relationales DatenmodelldBase, MySQL, Access, SQL-Server, ...

  • Objektorientiertes Datenmodellteilw. Oracle, O2 von O2 Technology

Datenbanken I


Hierarchisches datenmodell
Hierarchisches Datenmodell

  • 1960 entwickelt

  • Baumstruktur mit einem Ausgangselement (Root)

  • Jedes Element hat maximal einen Vorgänger (Parent)

  • Jedes Element hat beliebig viele Nachfolger (Children)

Datenbanken I




Hierarchisches modell heute
Hierarchisches Modell heute

  • LDAP (Lightweight Directory Access Protocol) organisiert Verzeichnisdienst

  • Verzeichnis- und Dateistrukturen von Betriebssystemen

  • HTML / XML

  • IMS (Information Management System) von IBM

Datenbanken I


Netzwerkmodell
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.

Datenbanken I


Beispiel netzwerk modell

Wacker

Student

Mustermann

ss

SV

vs

Vorlesung

Java

Stochastik

Zahlentheorie

Beispiel Netzwerk-Modell

Datenbanken I



3 ebenen architektur
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

Datenbanken I


Beispiel 3 ebenen architektur
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

Datenbanken I


Datenunabh ngigkeit
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 Schemasbei Änderungen des konzeptionellen Schemas

Datenbanken I


Codds 12 regeln f r relationale dbs
Codds 12 Regeln für relationale DBS

  • 1. InformationsregelDaten in Tabellen

  • ZugriffsgarantieJedes Feld eindeutig adressierbar

  • NULL-Werteunabh. vom Datentyp existiert Wert f. nichtvorh. Daten

  • MetadatenMetadaten in Tabellen

  • 5. Allumfassende Sprachefür alle User einheitlich, z. B. DML, DDL, DCL, TCL

  • 6. Datenänderung in Views

  • 7. Mengenorientierte ÄnderungsoperationenMengenoperationen nicht nur für Abfragen

Datenbanken I


Codds 12 regeln f r relationale dbs1
Codds 12 Regeln für relationale DBS

  • 8. Physische Datenunabhängigkeit Anwendungsprogramme unabh. vom Speicherort

  • Logische DatenunabhängigkeitAnwendungsprogramme logisch unabhängig v. Tabellen, ermöglicht durch Views

  • 10. Deklarative DatenintegritätFür Einhaltung der Integritätsregeln sorgt DBMS, nicht Anwendungsprogramm

  • 11. VerteilungsunabhängigkeitDatenbank kann physikalisch auf mehrere Speicherorte verteilt sein. Für Anwendungsprogramme unabhängig.

  • 12. UnterwanderungsverbotZugriff auf Daten nur über eine relationale Sprache

Datenbanken I


Gemeinsame merkmale relationaler dbms
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

Datenbanken I


Aufbau relationaler datenbanken
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.

Datenbanken I


Relationale datenbanktabelle
Relationale Datenbanktabelle

Tabelle

Zeile

Feld

Spalte

Primärschlüssel

Datenbanken I


Schl ssel
Schlü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.

Datenbanken I


Prim rschl ssel
Primä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.

Datenbanken I


Fremdschl ssel
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.

Datenbanken I


1 n beziehung
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.

Datenbanken I


M n beziehung
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.

Datenbanken I


Relationenmodell
Relationenmodell

  • Relation ~ Tabelle

  • Tupel ~ Datensatz

  • Attribut ~ Feld

Datenbanken I


Normalisierung

Normalisierung

Datenbanken I


Anomalien
Anomalien

Löschanomalie

Einfügeanomalie

Änderungsanomalie

Datenbanken I


Anomalien vermeiden
Anomalien vermeiden

Um Anomalien zu vermeiden, wurden

  • Normalformen,

  • Entwurfstheorie und

  • Entwurfsregeln

    formuliert.

Datenbanken I


Normalisierung1
Normalisierung

Normalformen: Regeln des Tabellenentwurfs.

Beim Normalisierungsprozess werden die Daten auf mehrere Tabellen verteilt.

Ziel ist eine

  • konsistente Datenhaltung

  • ohne Redundanzen

  • ohne Anomalien.

Datenbanken I


Normalformen historie
Normalformen-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

Datenbanken I


Normalformen beinhalten einander
Normalformen beinhalten einander

Datenbanken I


Anforderungen an nf
Anforderungen an NF

  • Aufspaltung in Relationen muss verlustfrei geschehen

    • kein Verlust von Informationen

    • keine falschen Informationen

    • kein Verlust an Integritätsbedingungen

Datenbanken I


Hinweise zur normalisierung
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...)

Datenbanken I


Erste normalform
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.

Eine Relation ist dann in der ersten Normal-form, wenn alle ihre Attribute atomar sind.

Datenbanken I


Erste normalform beispiel

Vater Mutter Kinder

Johann Martha {Else, Lucia}

Johann Maria {Theo, Josef}

Heinz Martha {Cleo}

Vater Mutter Kind

Johann Martha Else

Johann Martha Lucia

Johann Maria Theo

Johann Maria Josef

Heinz Martha Cleo

Erste Normalform Beispiel

Spalten mit gleichartigem Inhalt eliminierenVerboten sind mengenwertige Attribute:

Verlangt werden atomare Attribute:

Datenbanken I


Funktionale abh ngigkeiten
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)

Datenbanken I


Definition funktionale abh ngigkeit
Definition funktionale Abhängigkeit

[X] ist der Wert von Attribut X im Tupel 

z.B. Datensatz12[Kundennr]=123

Datenbanken I


Beispiel funktionale abh ngigkeit
Beispiel funktionale Abhängigkeit

Mitarbeiter(MitarbeiterID, Nachname, Vorname, AbteilungID, Abteilungsleiter, Unternehmen, Unternehmensanschrift, Berufsgruppe, Gehaltsklasse)

Datenbanken I


Ableitung von funktionalen abh ngigkeiten
Ableitung von funktionalen Abhängigkeiten

Datenbanken I


Volle funktionale abh ngigkeit
volle funktionale Abhängigkeit

  • ist voll funktional abhängig von ( =>), falls gilt

      

     A   :  – {A}  

  • Ein Attribut  istvollfunktionalabhängig von einerAttributmenge  falls

    •  funktionalabhängigist von 

    • und  nichtfunktionalabhängigist von einerechtenTeilmenge von .

  • Bsp: Kunde(KundenID, Nachname, PLZ, Ort)KundenID, Nachname  PLZ, OrtaberKundenID, Nachname ≠> PLZ, Ort , daKundenID PLZ, Ort

Datenbanken I


Schl ssel1
Schlüssel

KundenID Vorname, Nachname, PLZ, Ortes 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

Datenbanken I


Definition schl ssel
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)

Datenbanken I


Zweite normalform
Zweite Normalform

Ein Attribut heißt Primärattribut, wenn es in mindestens einem Schlüsselkandidaten vorkommt, andernfalls heißt es Nichtprimärattribut.

Eine Relation 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.

Datenbanken I


Beispiel

MatrNr VorlNr Name Semester

Studentenbelegung

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

. . . . . . . . . . . .

MatrNr

Name

VorlNr

Semester

Beispiel

Schlüsselkandiaten:

{MatrNr, VorlNr}

Nichtprimärattribute:

{Name, Semester}

Name ist nicht voll funktional abhängig von {MatrNr, VorlNr}

 keine 2. Normalform

Datenbanken I


Beispiel1

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

Beispiel

Schlüsselkandidaten:

{Vorlesung, Termin}

{Dozent, Termin}

{Raum, Termin}

Es gibt keine Nicht-Primärattribute

 2. Normalform

Datenbanken I


Beispiel2

Student

MatrNr Name Fachbereich Dekan

29555 Feuerbach 6 Matthies

27550 Schopenhauer 6 Matthies

26120 Fichte 4 Kapphan

25403 Jonas 6 Matthies

28106 Carnap 7 Weingarten

Beispiel

  • Student in zweiter Normalform

  • aber

  • Abhängigkeiten zwischen den Nichtprimärattributen: Fachbereich → Dekan

Datenbanken I


Transitive abh ngigkeit

X Y  Z, Y  X

/

MatrNr  Fachbereich  Dekan

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 = 

Beispiel:

Datenbanken I


Dritte normalform
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.

Datenbanken I


Beispiel 3 normalform
Beispiel 3. Normalform

Primärschlüssel ist {MitarbeiterID, ProjektID}

2. Normalform ist erfüllt.

Jedoch ist (MitarbeiterID, ProjektID) → AufgabeID → Aufgabename

somit ist die Relation nicht in der 3. Normalform

Aufteilung in 2 Tabellen:ProjektMit(MitarbeiterID, ProjektID, AufgabeID, Stunden)

Aufgabe(AufgabeID, Aufgabename)

Datenbanken I


Professorenadr

Rang

Name

PersNr

Straße

PLZ

Ort

Raum

BLand

Vorwahl

Landesregierung

PersNr {Ort, BLand} Vorwahl

ProfessorenAdr

ProfessorenAdr(PersNr, Rang, Name, Straße, PLZ, Ort, Bundesland, Vorwahl, Landesregierung, Raum)

Alle Nichtprimärattribute sind voll funktional abhängig von jedem Schlüsselkandidaten.

 nicht in 3. Normalform

Datenbanken I


Normalformen einfach
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.

Datenbanken I


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.

Datenbanken I




Bsp erste normalform
Bsp.: erste Normalform

Kunde:

Telefon:

Datenbanken I


Bsp zweite normalform
Bsp.: zweite Normalform

Kunde:

Telefon:

Auftrag:

Datenbanken I


Bsp dritte normalform
Bsp.: dritte Normalform

Kunde:

Telefon:

Auftrag:

Bearbeiter:

Datenbanken I


Superschl ssel
Superschlüssel

  • In der Relation R ist α R ein Superschlüssel, falls gilt: α→ R

  • Ein Superschlüssel von R ist eine Menge von Attributen einer Relation R. Eine Teilmenge des Superschlüssels ist immer ein Schlüsselkandidat.

Datenbanken I


Boyce codd normalform
Boyce-Codd-Normalform

  • Eine Relation R ist in der Boyce-Codd-Normalform (BCNF), falls R in der 3. NF ist und für jede funktionale Abhängigkeit α→β mindestens eine der folgenden Bedingungen gilt:

    • β α, d.h. die Abhängigkeit ist trivial.

    • α ist Superschlüssel von R.

  • Damit: keine transitive Abhängigkeit eines (Primär- oder Nichtprimär-)Attributs von jedem Schlüsselkandidat.

  • 3. NF fordert nur: keine transitive Abhängigkeit eines Nichtprimär-Attributs von jedem Schlüsselkandidat.

Datenbanken I


Bsp vierte normalform
Bsp.: vierte Normalform

unnormalisiert

Datenbanken I


Vierte normalform
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.

Datenbanken I



Datenbankentwurf
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.

Datenbanken I


Aspekte der qualit tssicherung
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)

Datenbanken I


Phasen des db entwurfsprozesses
Phasen des DB-Entwurfsprozesses

ER-Modell

logische DB-Struktur

physische DB-Struktur

Datenbanken I



Entity relationship buch
Entity-Relationship Buch

Attributebesitzen Wertebereich (Domain)

Entity(-Set)

Datenbanken I


Detaillierteres entity diagramm buch
Detaillierteres Entity-Diagramm Buch

mehrwertiges Attribut

Primärschlüssel

zusammengesetztes Attribut

Datenbanken I



M 1 beziehung person stadt
m:1-Beziehung Person-Stadt

Datenbanken I


M n beziehung1
m:n-Beziehung

Datenbanken I


Rekursive beziehung zwischen personen
Rekursive Beziehung zwischen Personen

Vater-Sohn

Ange-stellter-Chef

Person

ist Chef von

ist Vater von

Datenbanken I


Dreistellige beziehung
Dreistellige Beziehung

Datenbanken I


Is a beziehung
IS-A Beziehung

Datenbanken I







Konzeptioneller entwurf mit dem er modell
Konzeptioneller Entwurf mit dem ER-Modell

  • Beispiel: top-down-Vorgehensweise

  • Detaillierung durch Anwendung von Transformationen wie:

    • Entity-Verfeinerung

    • Relationship-Verfeinerung

    • Attribut-Verfeinerung

Datenbanken I





Min max notation
Min-Max-Notation

Min-Max: Wie oft nimmt ein Objekt mindestens (min) und wie oft höchstens (max) an einer Beziehung teil?

Datenbanken I


Er modell vs uml
ER-Modell vs. UML

Kardinalitäten werden in ERM mit Min-Max-Notation andersherum geschrieben als in UML.

Datenbanken I


Kr henfu notation
Krähenfuß-Notation

Auch: Martin-Notation (James Martin, Bachmann und Odell)

Datenbanken I


Transformation er relationen
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.

Datenbanken I


ad