DATENBANKEN Normalisierungsprozess. Normalisierung des DB-Schemas Ziel der Normalisierung des...
-
Upload
gamhard-kelber -
Category
Documents
-
view
111 -
download
1
Transcript of DATENBANKEN Normalisierungsprozess. Normalisierung des DB-Schemas Ziel der Normalisierung des...
DATENBANKEN
Normalisierungsprozess
Normalisierung des DB-Schemas Ziel der Normalisierung des relationalen
Datenbankschemas:Anomalien verhindernRedundanzen vermeidenÜbersichtlich und einfacher Aufbau der
Relationen
Anomalien
Probleme beim Ändern, Einfügen und Löschen Für jeden Mitarbeiter werden seine Personal-, Abteilungs- und
Projektdaten gespeichert Da eine Person an mehreren Projekten arbeiten kann, ist die
Personalnummer nicht mehr eindeutig (kein Primärschlüssel)
Anomalien Das Relationsschema weist erhebliche
Schwachstellen auf: Werden Tupel geändert, eingefügt oder gelöscht, können fehlerhafte Zustände auftreten. Diese werden durch die Datenredundanz hervorgerufen und führen zu Inkonsistenzen
Diese Fehler werden auch als Anomalien bezeichnet
Anomalien Einfüge-Anomalie: neue Mitarbeiter erzeugen leere
Datenfelder, da noch kein Projekt vorhanden ist. Ein Teil des Primärschlüssels ist nicht befüllt! (ProjNr)
Anomalien Lösch-Anomalie: ein Mitarbeiter wird gelöscht. Falls
die Projektdaten nur bei diesem Tupel gespeichert waren, gehen diese Daten verloren
Anomalien Änderungs-Anomalie: geänderte Mitarbeiter. (z.B. Hohl
auf Schumann) Es müssen alle Datensätze geändert werden, die diesen Wert enthalten. Ansonsten kann die Relation inkonsistent werden.
Abhängigkeiten
Funktionale Abhängigkeiten:Eine Relation R(A1,A2,…,An)
XR, YR, X→Y (z.B: X(A1), Y(A8) )
Eine funktionale Abhängigkeit liegt vor, wenn es keine zwei Tupel geben kann, in denen für gleiche X-Werte verschiedene Y-Werte auftreten können
Vergleiche: y=x2
Abhängigkeiten
Funktionale Abhängigkeiten: Beispiel: Name ist von der Personalnummer abhängig
PersonalNr→Name PersonalNr→Vorname
Beispiele: Projekt, Tätigkeit
ProjNr→Projektbeschreibung PersonalNr, ProjNr→Tätigkeit
Abhängigkeiten
Transitive Abhängigkeiten: Wenn der Wert eines Nicht-Schlüssel-Attributs von einem oder mehreren Nicht-Schlüssel-Attributen abhängt
Abhängigkeiten Transitive Abhängigkeiten: Wenn der Wert eines Nicht-Schlüssel-
Attributs von einem oder mehreren Nicht-Schlüssel-Attributen abhängt
Beispiel: Die Abteilungsbezeichnung ist vom Nicht-Schlüssel-Attribut abhängig(PersonalNr,ProjNr)→AbtNr→AbtBezeichnung
Normalisierungsprozess
Die Normalisierung im RDB-Schema wird in mehreren Schritten vollzogen
In jeder Stufe müssen gewisse Regeln erfüllt sein
Das Ergebnis wird als Normalform des Relationsschemas bezeichnet
1NF – 5NF: In der Praxis wird die Normalisierung nur bis zur 3. NF durchgeführt.
Nicht normalisierte Datenstruktur Nicht-normalisiert:
In einem Tupel ist für ein Attribut eine Werteliste eingetragen Die Relation ist schwer auszuwerten Zuordnungen sind teilweise nicht möglich (z.B.: In welchem
Projekt die Mitarbeiterin Hohl ihre Tätigkeit ausübt)
1. Normalform (1NF) Eine Relation befindet sich in der ersten
Normalform, wenn sie zweidimensional ist, d.h. ein Gebilde aus
Zeilen und Spalten sich in jedem Datensatz nur Daten befinden, die
zu einem Objekt der realen Welt gehören, und jeder
Datensatz nur einmal vorkommt sich in jeder Spalte nur Daten befinden, die einem
Attribut entsprechen, und das Attribut nur einmal in der Relation vorkommt
für jedes Attribut nur ein Wert eingetragen ist
1. Normalform (1NF)
Gehen Sie bei der Transformation einer nicht normalisierten Datenstruktur in die 1 Normalform wie folgt vor:
Probleme der 1NF
Die Relation weist Redundanzen auf, z.B. treten Mitarbeiterdaten, Abteilungsnamen und Projektnamen im Beispiel mehrfach auf.
Die Relation enthält voneinander unabhängige Sachgebiete, wie zum Beispiel Mitarbeiter, Abteilungen, Projekte.
Daten können nicht eindeutig identifiziert werden. Beispielsweise kann der Abteilungsname Einkauf nur (über eine Personal- und Projektnummer ermittelt werden.
2. Normalform (2NF) Eine Relation befindet sich in zweiter Normalform,
wenn jedes Nicht-Schlüsselfeld vom ganzen Primärschlüssel abhängig ist. Wichtig hierbei ist, dass Datenfelder nicht nur von einem Teilschlüsselfeld, sondern vom gesamten Schlüsselfeld abhängig sind.
Gehen Sie bei der Transformation von der 1NF in die 2NF wie folgt vor:
Zerlegen Sie die Relation in kleinere Relationen, sodass alle Nichtschlüsselfelder vom Primärschlüssel abhängig sind
(Jedes Nichtschlüssel Attribut ist vom gesamten Primärschlüssel abhängig!)
2. Normalform (2NF) Folgende Attribute sind nur
von Personalnummer abhängig (Teil des Primärschlüssels)
Die Abteilungsbezeichnung ist nur von der AbtNr abhängig
Die Projektbezeichnung ist nur von der ProjNr abhängig
Die Funktion (arbeitet_als) erfordert eine eigene Relation
3. Normalform (3NF)
Eine Tabelle befindet sich in 3NF, wenn alle Datenfelder nur vom Gesamtschlüssel abhängig sind und untereinander keine Abhängigkeiten auftreten.
Beispiel: arbeitet_als enthält die Attribute Stunden und Stundenlohn. Stundenlohn ist nicht direkt sondern transitiv vom Schlüsselfeld abhängig
3. Normalform (3NF)
Gehen Sie bei der Transformation von der 2NF in die 3NF wie folgt vor:
Entfernen Sie alle transitiven Abhängigkeiten, sodass alle Attributedirekt (funktional) vom Primärschlüssel abhängig sind.
z.B.: Der Stundenlohn ist von der Tätigkeit(snummer) und nicht von Personalnummer und Projektnummer abhängig!
(Jedes Nichtschlüssel Attribut ist vom gesamten Primärschlüssel funktional abhängig!)
3. Normalform (3NF) Lange Textfelder sind als Schlüssel ungeeignet, da sie mehr
Speicher im Index benötigen. Zusätzlich wird durch Änderung des Textfeldes auch die Relation geändert
Abhilfe bietet ein neues Schlüsselfeld (TätigkeitsNr)
Weitere Normalformen
Boyce-Codd-Normalform 4. Normalform (4NF) 5. Normalform (5NF)