Normalisierung von Datenmodellen

Über Normalisierung ein Datenmodell optimieren

Auf dem Weg von der real existierenden Plattensammlung bis hin zu einem funktionsfähigen relationalen Datenmodell wurden am Rande bereits einige Normalisierungsvorgänge unternommen. Sie standen allerdings bewusst unter dem Blickwinkel der Übertragung von einem semantischen Modell zu den notwendigen Tabellen, die dann die DB konstituieren. In dieser Lektion wird dieser Prozess noch einmal durchlaufen, wobei als neue Perspektive dieses Mal der Algorithmus der Normalisierung dient.

Die in diesem Algorithmus ablaufenden Regeln und die ihn begründenden Gesetze haben folgende Ziele:

• Der Aufwand für die Weiterentwicklung der Anwendungsprogramme soll gesenkt werden.
• Die einzelnen Datenstrukturen sind logisch so weit wie möglich entflochten, sodass die Daten möglichst flexibel verwaltet werden können und Änderungen sowohl bei einzelnen Objekten als auch in der Anwendungssoftware leicht durchführbar bleiben.
• Eine fast redundanzfreie Speicherung von Daten verkleinert den Speicherplatz und nutzt Rechenzeit besser aus.

Folgendes Anti-Beispiel erfüllt kein einziges der der oben genannten Merkmale, sodass es mit den folgenden Abschnitten als durchgehendes Beispiel schrittweise in ein geeignetes Datenmodell überführt werden kann. In einer Firma, die sich mit Seminaren und der Lösung von E-Commerce-Problemen beschäftigt, sind verschiedene Mitarbeiter abteilungsübergreifend in Projekten eingesetzt. Jeder Mitarbeiter hat eine Personalnummer (PersNr), einen Namen (Name) und ein Einstiegsjahr (Jahr). Die Mitarbeiter arbeiten in Abteilungen, die eine Abteilungsnummer (AbtNr), einen Abteilungsnamen (AbtName), eine Mitarbeiterzahl (MaZahl) und einen Abteilungsleiter (AbtLeit) besitzen. Die Projekte haben verschiedene Nummern (ProjNr) und einen Projektleiter (LeitNr). Die Mitarbeiter beschäftigen sich unterschiedlich intensiv (Zeit) mit den aktuellen Projekten.

PersNr	ProjNr	LeitNr	Zeit	Name	Jahr	AbtNr	AbtName	MaZahl	AbtLeit
1020	C13	1020	15%	Ralf Tauzieh	1995	2	Medien	4	1020
1020	B12	1042	30%	Ralf Tauzieh	1992	2	Medien	4	1020
1035	C13	1020	50%	Jana Grün	2001	3	FiBu	2	1035
1042	B12	1042	25%	Tom Schnell	1993	1	Seminare	3	1042
1042	D10	1049	30%	Tom Schnell	1990	1	Seminare	3	1042
1048	D10	1049	15%	Fritz Bachler	1999	4	Programmierung	5	1048
1049	C13	1020	40%	Tanja Sieben	1996	4	Programmierung	5	1048

Das Konzept der funktionellen Abhängigkeit

Zwischen Daten können unterschiedliche Abhängigkeiten bestehen. Mit ihrer Hilfe können Daten in eine vernünftige relationale Form gebracht werden, wenn man die Daten entsprechend analysiert.

Im nebenstehenden Beispiel werden Schiffe und Kabinen erfasst. Typischerweise werden Kabinen auf Schiffen oder Zimmer in Hotels nicht mit einem komplizierten Code gezählt, sondern einfach in Ganzzahlen von 1 bis zu einer bestimmten anderen Zahl. Innerhalb eines Schiffs reicht es vollkommen aus, seine eigene Kabinennummer zu kennen, um seine Kabine wiederzufinden bzw. zumindest einen Steward zu bitten, den Weg zu der so eindeutig identifizierten Kabine zu beschreiben. üro für die nächste große Weltreise die gleiche Kabine zu buchen. Nicht einmal innerhalb der gleichen Flotte wird eine Nummer wie 112 aushelfen können. Vielmehr ist dieser Primärschlüssel abhängig von der Schiffnummer, die als weiteres Kriterium die einzelne Kabine einem bestimmten Schiff zuordnet. Damit gehört das Objekt KABINE zu den schwachen Einheiten, da ihre eindeutige Bestimmung von einem weiterem Objekt abhängt.

Für die funktionale Abhängigkeit gilt, dass zwei Attribute eines Objekts dann funktional voneinander abhängen, wenn zu jedem Wert von A nur ein Wert von B gehört. In obiger Tabelle besteht also bspw. eine solche Abhängigkeit zwischen PersNr und Name, da über die Personalnummer (1020) sofort auf den zugehörigen Namen (Ralf Tauzieh) geschlossen werden kann. ängig ist von der Personalnummer. Wenn Sie mit so häufigen Namen wie Ralf Müller oder Ralf Schmidt den gleichen Test machen, könnte es sein, dass auch noch ein Anderer im Betrieb den gleichen Namen hat und deswegen die Personalnummer nicht vom Namen abhängt.

Von der Universal Relation zum RDM

1. Analysieren Sie die vorliegende Datenstruktur.

2. Richten Sie die Tabelle MITARBEITER ein.

Ganz deutlich fällt auf, dass ein besonders einfach zu modellierendes Objekt der einzelne Mitarbeiter ist. Er wird in der Übersichtstabelle hauptsächlich durch seine PersNr, seinen Namen und sein Eintrittsjahr gekennzeichnet. Die Aufnahme der anderen Attribute verbietet sich deswegen schon, weil sie u.a. die Datenredundanz hervorgerufen haben. Sobald ja ein Mitarbeiter an zwei Projekten teilnimmt, taucht er mit zwei Datensätzen und seinen gesamten anderen Daten in der Übersichtstabelle auf.

PersNr	Name	Jahr
1020	Ralf Tauzieh	1995
1035	Jana Grün	2001
1042	Tom Schnell	1990
1048	Fritz Bachler	1999
1049	Tanja Sieben	1996

Bringen Sie die Tabelle MITARBEITER in die 1. Normalenform. Für die 1. Normalenform gilt, dass sie einen Schlüssel besitzt und alle Attribute atomisiert sind. Ein Schlüssel ist durch die Personalnummer vorhanden. Die Atomisierung muss noch umgesetzt werden, da im Attribut Name sowohl der Vorname als auch der Nachname eingetragen sind. Atomisiert sind Attribute also dann, wenn sie nicht weiter aufgeteilt werden können.

PersNr	Vorname	Name
1020	Ralf	Tauzieh
1035	Jana	Grün
1042	Tom	Schnell
1048	Fritz	Bachler
1049	Tanja	Sieben

Klassische Beispiele sind das vorliegende Namensproblem und das Adressproblem mit einer Straße und einer Hausnummer in einer Zelle, die dann in jeweils eigene Spalten gebracht werden. Diskussionswürdig und eigentlich nur in Spezialfällen umgesetzt sind Atomisierungen bei z.B. Zeitdaten wie ein Datum in der Form Tag/Monat/Jahr. Sofern nicht Abfragen zu diesen einzelnen Informationen ausgeführt werden, begnügt man sich damit, diese Daten in einer Spalte zu speichern. Anders dagegen verläuft diese Überlegung insbesondere für Namen. Da Vornamen wesentlich häufiger auftreten als Nachnamen, werden sie vermutlich in einer Mitarbeitertabelle nur sehr selten (falls überhaupt jemals) abgefragt. Dagegen ist allein die alphabetische Sortierung für ein Firmenadressbuch über diese Atomisierung sehr einfach zu bewerkstelligen.

3. Analysieren Sie erneut die vorliegende Datenstruktur.

Die Tabelle MITARBEITER ist bereits in der 1. Normalenform und kann durch weitere Attribute leicht erweitert werden. Diese Erweiterungen wie z.B. Informationen über die Adresse, die zugehörige Abteilung, Gehaltsstufe oder Ausbildung beeinflussen nicht wie in der Übersichtstabelle auch die anderen Datensätze. Sie beschränken sich dagegen auf jeweils einen Datensatz, der über die Personalnummer identifiziert wird.

PersNr	Vorname	Name
1020	Ralf	Tauzieh
1035	Jana	Grün
1042	Tom	Schnell
1048	Fritz	Bachler
1049	Tanja	Sieben

In der nun vorliegenden, geschrumpften Übersichtstabelle liegen noch weitere Datenredundanzen vor wie die oben schon erwähnte Abteilungsnummer. Sie kann einfach aus der Tabelle entfernt und in die Tabelle MITARBEITER eingebettet werden.
Als weitere Besonderheit der jetzt existierenden Übersichtstabelle muss man die funktionale Abhängigkeit zwischen den Attributen Projektleiternummer (LeitNr) und Projektnummer (ProjNr) betrachten. In dieser Konstellation hängt LeitNr ausschließlich von ProjNr ab. Ähnliche Überlegungen gelten für die Zusammenstellung der Projekte sowie der Zeitverteilung pro Mitarbeiter.

PersNr	ProjNr	LeitNr	Zeit	AbtNr	AbtName	MaZahl	AbtLeit
1020	C13	1020	15%	2	Medien	4	1020
1020	B12	1042	30%	2	Medien	4	1020
1035	C13	1020	50%	3	FiBu	2	1035
1042	B12	1042	25%	1	Seminare	3	1042
1042	D10	1049	30%	1	Seminare	3	1042
1048	D10	1049	15%	4	Programmierung	5	1048
1049	C13	1020	40%	4	Programmierung	5	1048

 

4. Bringen Sie die Übersichtstabelle in die 2. Normalenform.

Gemäß Definition ist ein Objekt in der 2. Normalenform, wenn es in der 1. Normalenform ist und die funktionalen Abhängigkeiten zwischen Schlüssel und den anderen Attributen elementar sind. Nebenstehende Abbildung zeigt also den Zustand einer Modellierung, die gerade wegen dieser nicht elementaren funktionalen Abhängigkeit nicht in der 2. Normalenform ist. Es besteht neben dem Schlüssel ein weiteres Attribut, das ein anderes bestimmt.
Eine Aufspaltung wird also folgende Tabellen ergeben:

Tabelle	Spalten
PROJEKTE	PersNr, Name, Jahr, AbtNr, AbtName, MaZahl, AbtLeit
ZEITEN	PersNr, ProjNr, Zeit
PROJEKTLEITER	ProjNr, LeitNr

Konkret erhält man neben der neuen Struktur der Tabelle MITARBEITER folgende Einzeltabellen:

PersNr	Zeit	Vorname	Name	Jahr	AbtNr	AbtName	MaZahl	AbtLeit
1020	15%	Ralf	Tauzieh	1995	2	Medien	4	1020
1020	30%	Ralf	Tauzieh	1992	2	Medien	4	1020
1035	50%	Jana	Grün	2001	3	FiBu	2	1035
1042	25%	Tom	Schnell	1993	1	Seminare	3	1042
1042	30%	Tom	Schnell	1990	1	Seminare	3	1042
1048	15%	Fritz	Bachler	1999	4	Programmierung	5	1048
1049	40%	Tanja	Sieben	1996	4	Programmierung	5	1048

Tabellen PROJEKTLEITER und ZEITEN:

ProjNr	LeitNr
C13	1020
B12	1042
B12	1042
D10	1049

PersNr	ProjNr	Zeit
1020	C13	15%
1020	B12	30%
1035	C13	50%
1042	B12	25%
1042	D10	30%
1048	D10	15%
1049	C13	40%

Ganz deutlich sehen Sie schon an der Struktur der letzten Tabellen, wie sich langsam ein relationales Datenmodell aus der ehemaligen Übersichtstabelle entwickelt. Die Tabellen PROJEKTLEITER und ZEITEN sind nämlich bereits durch die Spalte ProjNr verbunden.

5. Analysieren Sie die neue Datenstruktur.

Ein weiteres Problem ergibt sich danach sofort aus der Struktur der erneut verkleinerten Übersichtstabelle. Zwischen den Nichtschlüssel-Attributen (was in der 2. Normalenform gegenteilig war) bestehen nun weiterhin funktionale Abhängigkeiten, die behoben werden können.
Der Abteilungsleiter kann direkt aus der Abteilungsnummer ermittelt werden. Obwohl dieses Attribut kein Schlüssel-Attribut ist, kann es dennoch ein weiteres Attribut identifizieren. Dies steht im Gegensatz zur oberen Untersuchung, wobei das Schlüssel-Attribut ProjektNr das Nicht-Schlüssel-Attribut LeitNr identifizierte. Damit ist die funktionale Abhängigkeit zwischen dem Schlüssel- Attribut und den anderen Attributen nicht direkt.

6. Erzeugen Sie die 3. Normalenform.

Damit ein Datenmodell in der 3. Normalenform ist, muss es zunächst in der 2. Normalenform sein und die Eigenschaft besitzen, dass die funktionalen Abhängigkeiten zwischen dem Schlüssel und den anderen Attributen direkt ist. Daher muss einerseits die Tabelle MITARBEITER erneut geändert und um die Abteilungsnummer ergänzt werden und andererseits eine letzte neue Tabelle namens ABTEILUNGEN eingerichtet werden, die alle Informationen zu den einzelnen Abteilungen der Firma aufnimmt, die nicht den anderen Spalten zugeordnet werden dürfen. Nach diesem Schritt ist das Datenmodell in der 3. Normalenform und könnte in einem DBS umgesetzt werden.
In einer rückblickenden Analyse kann man feststellen, dass im Hintergrund für die Erzeugung der Tabellen auch der in der vorherigen Lektion gezeigte Weg über die Tätigkeits- oder die Objektanalyse gelungen wäre. Die Objektanalyse hätte für die ersten drei Tabellen MITARBEITER, ABTEILUNGEN und PROJEKTE als in der Realität beobachtbare Objekte Pate stehen können. Sogar ein stofflich nicht direkt vorhandenes Objekt wie verschiedene Projekte in dieser Firma könnten indirekt repräsentiert werden über entsprechende Ordner und Projektbeschreibungen. Im Gegensatz dazu steht die Tabelle ZEITEN für eine Tätigkeit, die die Tätigkeitsanalyse ans Tageslicht gezerrt hätte. Sie beschreibt die Tätigkeit, dass Mitarbeiter in Abteilungen an Projekten arbeiten und stellt als Relationstabelle die direkte Verbindung zu MITARBEITER über PersNr und zu PROJEKTE über ProjNr her. Die Abteilungen werden dann indirekt über die Tabelle MITARBEITER referenziert. Das macht auch insoweit Sinn, als dass ja gerade die Projekte von den Abteilungen unabhängig sind und von Mitarbeitern verschiedener Abteilungen bearbeitet werden.
Folgende Tabellen sind also das endgültige Ergebnis:

Tabelle	Spalten
MITARBEITER	PersNr, Vorname, Name, Jahr, AbtNr
ABTEILUNGEN	AbtNr, AbtName, AbtLeiter, MaZahl
PROJEKTE	ProjNr, LeitNr
ZEITEN	PersNr, ProjNr, Zeit

Folgende Daten können endgültig in den Tabellen untergebracht werden:

Tabelle PROJEKTE	Tabelle ZEITEN
ProjNr LeitNr C13 1020 B12 1042 B12 1042 D10 1049	PersNr ProjNr Zeit 1020 C13 15% 1020 B12 30% 1035 C13 50% 1042 B12 25% 1042 D10 30% 1048 D10 15% 1049 C13 40%
Tabelle MITARBEITER	Tabelle ABTEILUNGEN
PersNr Vorname Name Jahr AbtNr 1020 Ralf Tauzieh 1995 2 1035 Jana Grün 2001 3 1042 Tom Schnell 1990 1 1048 Fritz Bachler 1999 4 1049 Tanja Sieben 1996 4	AbtNr AbtName MaZahl AbtLeit 2 Medien 4 1020 3 FiBu 2 1035 1 Seminare 3 1042 4 Programmierung 5 1048

Die drei hier vorgestellten Normalenformen stellen nicht die einzigen dar. Weitere Aufspaltungen der Datenstruktur sind z.B. mit der Boyce-Codd-Normalenform möglich. Für die allermeisten Fälle genügt jedoch der hier gezeigte Umwandlungsprozess. Je weiter die Datenstruktur in einzelne Tabellen zerlegt wird, desto komplizierter können sich dann Abfragen gestalten, die permanent komplex sind und mehrere Tabellen verknüpfen müssen.

DB-Anomalien und Redundanzen

Mögliche Schwierigkeiten mit ungünstig bzw. sogar falsch strukturierten Datenmodellen schimmerten bereits im Laufe der Überlegungen zur Normalisierung der oben verwendeten DB hindurch. Abschließend sollen die wichtigsten Probleme noch einmal am oberen Beispiel erläutert und zusammengefasst werden. Es bietet sich an, diese Ausführungen nach der erledigten Normalisierungsarbeit zu geben, weil Sie die hergeleitete Datenstruktur jetzt kennen und daher sicherlich die einzelnen Punkte besser zu deuten wissen:

Redundanz

Mit Redundanz ist das Auftreten von doppelten Informationen in Datensätzen gemeint. Dies lässt sich nicht immer ganz vermeiden: Wenn 100 Leute ein Buch kaufen, ist klar, dass irgendwo die Zahl 100 auftaucht wie z.B. in Form von 100 Bestellungen mit unterschiedlichen Bestellnummern und 100 gleichen ISBN-Nummern. In diesem Datenmodell existiert aber bereits eine offenbar irgendwie normalisiert Form, da die Tätigkeit Bestellen mit Hilfe einer Tabelle BESTELLUNGEN erfasst wurde. Die Projektverwaltung aus dem vorherigen Beispiel jedoch startete mit einer großen Übersichtstabelle, die vor Redundanzen förmlich überquoll. Die unten folgenden Anomalien sollen die Gefahren mit Redundanzen zeigen. Ziel sollte immer sein, Redundanzen weitestgehend zu vermeiden. Je größer eine Datenbank wird, desto mehr Speicherplatz fressen unnötige Informationsdoppelgänger. Wirkt sich dies bei 100 Datensätzen noch nicht dramatisch aus, so können Abfragen bei über 10.000 Datensätzen jedoch erheblich beschleunigt werden, wenn gerade keine unnötigen Wiederholungen in den Tabellen zu finden sind. Eine der vielen verzichtbaren Redundanzen im obigen Beispiel bestand darin, dass für jedes neue Projekt, das ein Mitarbeiter beginnt, sämtliche verfügbaren Mitarbeiter-, Abteilungs- und Leitungsdaten wiederholt werden mussten. Dieses Problem ist durch den Normalisierungsvorgang vollkommen behoben worden.

Abfrage-Anomalie

Wenn das Datenmodell, mit dem der Normalisierungsprozess startete, in aller Konsequenz so eingerichtet worden wäre, hätte es sein können, dass nur Mitarbeiter, die an einem Projekt teilnehmen, auch in der Übersichtstabelle erfasst werden. Sollte aber der vermutlich nicht lange auf sich warten lassende Fall eintreten, dass ein Mitarbeiter nicht an einem Projekt teilnimmt, könnte er gar nicht gefunden werden.

Einfüge-Anomalie

Die Abfrage-Anomalie aus der gegenüber liegenden Perspektive betrachtet, zeigt zusätzlich, dass es eigentlich gar nicht möglich ist, einen neuen Mitarbeiter zu erfassen, der nicht an einem Projekt teilnimmt. Würde man ihn dennoch erfassen, dann müssten sämtliche Felder, die eigentlich mit Projekten zusammenhängen, leer bleiben.

Lösch-Anomalie

Den aktuellen Gedanken weitergesponnen, muss man sich darüber hinaus vorstellen, was mit dem Datensatz eines Mitarbeiters nach dem Ausscheiden aus einem Projekt geschieht. Zwar konnte er hervorragend eingetragen werden, weil er ja an einem Projekt teilnahm, doch nun sinkt seine Zeit für die Projektarbeit auf 0 %. Entweder verschwindet sein Datensatz komplett aus der Übersichtstabelle und er ist gar nicht mehr als Mitarbeiter vorhanden, oder man führt notgedrungen einen Erinnerungswert in Form von 0 % für das ehemalige Projekt ein. Sollte dieses dann wiederum irgendwann einmal abgeschlossen sein, stünde es dennoch mit 0 % für diesen Mitarbeiter in der Tabelle.

Aktualisierungs-Anomalie

Auf den allgemeinen Fall übertragen, meint der letzte Gedanke, dass jegliche Aktualisierung in Zusammenhang mit Projekten für die Mitarbeiter bedeuten können, dass sie aus der Tabelle ausgetragen werden. Andersherum kann es aber ebenso passieren, dass Änderungen an Mitarbeitern wie Ausscheiden aus der Firma im ungünstigsten Fall heißen können, dass ein Projekt nicht mehr in der Tabelle erscheint. Gerade bei Projekten, die nur mit zwei Mitarbeitern durchgeführt werden, könnte dies sofort passieren, wenn beide die Firma verlassen. In diesem Fall wäre eine erneute Eintragung des Projekts z.B. nach zwei Wochen möglich, aber vielleicht waren die Daten so miteinander verquickt, dass gleichzeitig die gesamte Abteilung mit Nummer, Name und Chef durch den Abgang des Mitarbeiters verschwunden sind...