Normalisierungsprozess DATENBANKEN Normalisierungsprozess

Normalisierung des DB-Schemas Ziel der Normalisierung des relationalen Datenbankschemas: Anomalien verhindern Redundanzen 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) XR, YR, 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 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 Attribute direkt (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)