Normalisierungsprozess

Die nicht-normalisierte Datenstruktur

Durch den Prozess der Normalisierung können Datenredundanzen vermieden und die daraus resultierenden Speicheranomalien verhindert werden.

PersonalNr	Nachname	Vorname	AbteilungsNr	Bezeichnung	ProjektNr	Beschreibung	Stunden
1	Lorenz	Sophia	1	Personal	2	Verkaufspromotion	83
2	Hohl	Tatjana	2	Einkauf	3	Konkurrenzanalyse	29
3	Willschrein	Theodor	1	Personal	1, 2, 3	Kundenumfrage, Verkaufspromotion, Konkurrenzanalyse	140, 92, 110
4	Richter	Hans	3	Verkauf	2	Verkaufspromotion	67
5	Wiesenland	Brunhilde	2	Einkauf	1	Kundenumfrage	160

Nicht normalisierte Datenstruktur

Eine unnormalisierte Datenstruktur ist dadurch gekennzeichnet, dass sie mehrere Werte in einem Datenfeld aufweist. Beispielsweise sind für einen Mitarbeiter drei Projekte in einem Datenfeld gespeichert.
Aufgrund der redundanten Datenhaltung können mehrere Speicheranomalien beobachtet werden:

Einfügeanomalie	Beispielsweise kann eine neue Abteilung nur dann hinzugefügt werden, wenn diese einem Mitarbeiter zugeordnet wird.
Löschanomalie	Werden alle Mitarbeiterinformationen gelöscht, gehen auch die Informationen über die Projekte und über die Abteilungen verloren.
Änderungsanomalie	Wird beispielsweise die Projektbezeichnung geändert, dann muss diese Änderung bei allen Mitarbeitern, die ebenfalls in diesem Projekt arbeiten, gemacht werden. Ansonsten führt dies zu inkonsistenten Daten.

1. Normalform

=>	Entfernen Sie alle Mehrfacheinträge in einem Feld. Jedem Datenfeld eines Datensatzes darf höchstens ein Wert zugewiesen sein.

PersonalNr	Nachname	Vorname	AbteilungsNr	Bezeichnung	ProjektNr	Beschreibung	Stunden
1	Lorenz	Sophia	1	Personal	2	Verkaufspromotion	83
2	Hohl	Tatjana	2	Einkauf	3	Konkurrenzanalyse	29
3	Willschrein	Theodor	1	Personal	1	Kundenumfrage	140
3	Willschrein	Theodor	1	Personal	2	Verkaufspromotion	92
3	Willschrein	Theodor	1	Personal	3	Konkurrenzanalyse	110
4	Richter	Hans	3	Verkauf	2	Verkaufspromotion	67
5	Wiesenland	Brunhilde	2	Einkauf	1	Kundenumfrage	160

Daten in der 1. Normalform

Folgende Probleme weist die 1. Normalform weiterhin auf:

Redundanzen	Mitarbeiterdaten, Abteilungs- und Projektnamen treten mehrfach auf und müssen im Falle einer Änderung an mehreren Stellen geändert werden (Änderungsanomalie => Dateninkonsistenz).
Keine eindeutige Identifizierung	Es ist notwendig, den Identifikationsschlüssel zu erweitern. Eine eindeutige Identifikation ist nur durch eine Kombination aus Personalnummer und Projektnummer möglich.

2. Normalform

=>

Jedes Nicht-Schlüsselfeld muss vom ganzen Schlüssel (der auch aus mehreren Feldern bestehen kann) abhängig sein. Datenfelder dürfen nicht nur von einem Teilschlüsselfeld abhängig sein.

Aus der ursprünglichen Tabelle entstehen nun vier Tabellen:

Die Tabelle MITARBEITER enthält nur die Personaldaten sowie als Fremdschlüssel die Zuordnung zu einer Abteilung. Alle Daten können über das Schlüsselfeld (PersonalNr) identifiziert werden.

PersonalNr	AbteilungsNr	Nachname	Vorname
1	1	Lorenz	Sophia
2	2	Hohl	Tatjana
3	1	Willschrein	Theodor
4	3	Richter	Hans
5	2	Wiesenland	Brunhilde

Die Tabelle PROJEKT enthält die die Projektbeschreibungen, die sich mit den Projektnummern identifizieren lassen.

ProjektNr	Beschreibung
1	Kundenumfrage
2	Verkaufspromotion
3	Konkurrenzanalyse

Die Tabelle ABTEILUNG enthält die die Abteilungsbezeichnungen, die sich mit den Abteilungsnummern ermitteln lassen.

AbteilungsNr	Bezeichnung
1	Personal
2	Einkauf
3	Verkauf

Die Tabelle PROJEKTAUSWERTUNG entsteht, weil die Stundenzahl, die ein Mitarbeiter an einem Projekt gearbeitet hat, nur aus der Kombination von Projekt- und Personalnummer identifizieren lässt.

ProjektNr	PersonalNr	Stunden
1	3	140
1	5	160
2	1	83
2	3	92
2	4	67
3	2	29
3	3	110

Tabellen in der 2. Normalform

Die 3. Normalform

Eine Tabelle befindet sich in der 3. Normalform, wenn alle Datenfelder nur vom gesamten Schlüssel abhängig sind und untereinander keine Abhängigkeiten auftreten. Sobald ein Nicht-Schlüsselfeld nur über ein anderes Nicht-Schlüsselfeld identifizierbar ist, spricht man von transitiver Abhängigkeit. Auch transitive Abhängigkeiten ziehen Datenredundanz und gegebenenfalls -inkonsistenzen nach sich.

Die Tabellen der 2. Normalform befinden sich schon in der 3. Normalform, da keine transitiven Abhängigkeiten bestehen.

=>

Werden bei der Erstellung eines Entity-Relationship Diagramms n:m-Beziehungen in zwei hierarchische Beziehungen (1:n-Beziehungen) aufgespalten, so führt diese Vorgehensweise in der Regel zu Relationen in der 3. Normalform.

Aus der Tabelle PROJEKTAUSWERTUNG soll zusätzlich die Tätigkeit des einzelnen Mitarbeiters am Projekt hervorgehen. Die Art der Tätigkeit bestimmt den Stundenlohn. Damit ist der Stundenlohn nicht direkt, sondern transitiv vom Schlüsselfeld (ProjektNr, PersonalNr) abhängig.

ProjektNr	PersonalNr	Stunden	Tätigkeit	Stundenlohn
1	3	140	Betreuung	45,- €
1	5	160	Betreuung	45,- €
2	1	83	Koordination	55,- €
2	3	92	Koordination	55,- €
2	4	67	Durchführung	50,- €
3	2	29	Durchführung	50,- €
3	3	110	Durchführung	50,- €

Transitive Abhängigkeiten

=>

Für die 3. Normalform müssen alle transitiven Abhängigkeiten durch Teilen der Tabellen in mehrere Relationen beseitigt werden. Alle Nicht-Schlüsselfelder müssen direkt vom gesamten Schlüsselfeld abhängig sein.

Die Tabelle PROJEKTAUSWERTUNG enthält als Fremdschlüssel die Tätigkeitsnummer.

ProjektNr	PersonalNr	Stunden	TätigkeitNr
1	3	140	1
1	5	160	1
2	1	83	2
2	3	92	2
2	4	67	3
3	2	29	3
3	3	110	3

Die Tabelle TÄTIGKEIT enthält die Tätigkeiten, sowie die dazugehörigen Stundenlöhne. Sie können über das Schlüsselfeld (TätigkeitsNr) identifiziert werden. Ändert sich nun beispielsweise der Stundenlohn einer Tätigkeit, muss diese Änderung lediglich in dieser Tabelle an einer Stelle durchgeführt werden.

TätigkeitsNr	Tätigkeit	Stundenlohn
1	Betreuung	45,- €
2	Koordination	55,- €
3	Durchführung	50,- €

Tabellen in der 3. Normalform