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)