Datenbanken i
This presentation is the property of its rightful owner.
Sponsored Links
1 / 100

Datenbanken I PowerPoint PPT Presentation


  • 70 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Datenbanken I

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


Aufbau von datenbankmanagement systemen

Aufbau von Datenbankmanagement-Systemen

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


Festplatten gr envergleich

Festplatten-Größenvergleich

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


Beispiel hierarchisches modell

Beispiel Hierarchisches Modell

Datenbanken I


Auspr gung hierarchisches modell

Ausprägung Hierarchisches Modell

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


Relationale datenbanksysteme

Relationale Datenbanksysteme

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 EbeneKursbuch

interne EbeneAbbildung auf Dateisystem

Personaldatei:

externe Ebene Angestellte mit Namen, Wohnorten und Geburtstag

konzeptionelle EbeneGeburtstagsliste mitName, Datum, Alter

interne EbeneAbbildung 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

VaterMutter Kinder

JohannMartha{Else, Lucia}

JohannMaria{Theo, Josef}

HeinzMartha{Cleo}

VaterMutterKind

JohannMarthaElse

JohannMarthaLucia

JohannMariaTheo

JohannMariaJosef

HeinzMarthaCleo

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

MatrNrVorlNr NameSemester

Studentenbelegung

261205001Fichte10

275505001Schopenhauer 6

275504052Schopenhauer 6

281065041Carnap 3

281065052Carnap 3

281065216Carnap 3

281065259Carnap 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

VorlesungDozentTermin Raum

Backen ohne FettKantMo, 10:1532/102

Selber AtmenSokratesMo, 14:1531/449

Selber AtmenSokratesDi, 14:1531/449

Schneller BetenSokratesFr, 10:1531/449

Beispiel

Schlüsselkandidaten:

{Vorlesung, Termin}

{Dozent, Termin}

{Raum, Termin}

Es gibt keine Nicht-Primärattribute

 2. Normalform

Datenbanken I


Beispiel2

Student

MatrNrNameFachbereich Dekan

29555 Feuerbach6Matthies

27550 Schopenhauer6Matthies

26120 Fichte4Kapphan

25403 Jonas6Matthies

28106 Carnap7Weingarten

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


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


Normalisierung beispiel

Normalisierung-Beispiel

Datenbanken I


Bsp vor normalisierung

Bsp: vor Normalisierung

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


Entity relationship diagramme

Entity-Relationship-Diagramme

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 modelle

Entity-Relationship-Modelle

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


Beziehung zwischen b chern und lesern

Beziehung zwischen Büchern und Lesern

n

1

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


Totale disjunkte spezialisierung

Totale, disjunkte Spezialisierung

Datenbanken I


Partielle nicht disjunkte spezialisierung

partielle, nicht disjunkte Spezialisierung

Datenbanken I


Partielle disjunkte spezialisierung

partielle, disjunkte Spezialisierung

Datenbanken I


Totale nicht disjunkte spezialisierung

totale, nicht disjunkte Spezialisierung

Datenbanken I


Entity relationship konstrukte

Entity-Relationship-Konstrukte

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


Erstes teildiagramm fluggesellschaft

Erstes Teildiagramm Fluggesellschaft

Datenbanken I


Zweites teildiagramm fluggesellschaft

Zweites Teildiagramm Fluggesellschaft

Datenbanken I


Drittes teildiagramm fluggesellschaft

Drittes Teildiagramm Fluggesellschaft

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


  • Login