Grundlagen der Datenbanknormalisierung in Access 2000

Dieser Artikel beschreibt Terminologie zur Datenbanknormalisierung für Anfänger. Ein grundlegendes Verständnis dieser Terminologie ist für die Erstellung relationaler Datenbanken äußerst hilfreich.

Hinweis: Microsoft bietet auch einen WebCast an, auf dem die Grundlagen der Datenbanknormalisierung behandelt werden. Sie finden dieses WebCast auf der folgenden Microsoft-Website: Weitere Informationen zu diesem Thema in Bezug auf eine frühere Version von Access finden Sie im folgenden Artikel der Microsoft Knowledge Base:

Beschreibung der Normalisierung

Als Normalisierung wird der Prozess der Organisation von Daten in einer Datenbank bezeichnet. Dazu gehört das Erstellen von Tabellen und das Herstellen von Beziehungen zwischen diesen Tabellen gemäß Regeln, die dazu dienen, die Daten zu schützen und die Flexibilität der Datenbank durch Eliminieren von Redundanz und inkonsistenter Abhängigkeit zu verbessern.

Redundante Daten belegen unnötig Speicherplatz und verursachen Wartungsprobleme. Wenn Daten, die mehrfach und an verschiedenen Speicherorten existieren, geändert werden müssen, müssen alle Vorkommen dieser Daten auf exakt die gleiche Weise geändert werden. Eine Kundenadresse ist viel einfacher zu ändern, wenn die entsprechenden Daten nur in der Tabelle "Kunden" und an keiner anderen Stelle der Datenbank gespeichert sind.

Was ist unter "inkonsistenter Abhängigkeit" zu verstehen? Während der Benutzer intuitiv in der Tabelle "Kunden" nach der Adresse eines bestimmten Kunden suchen wird, ist es wahrscheinlich nicht sinnvoll, dort nach dem Gehalt des Mitarbeiters zu suchen, der diesen Kunden betreut. Das Gehalt des Mitarbeiters bezieht sich auf den Mitarbeiter und sollte deshalb in die Tabelle "Personal" verschoben werden. Inkonsistente Abhängigkeiten können den Zugriff auf Daten erschweren, weil der Pfad zu den Daten möglicherweise fehlt oder beschädigt ist.

Es gibt einige Regeln für die Datenbanknormalisierung. Jede Regel wird als "Normalform" bezeichnet. Wenn die erste Regel beachtet wird, weist die Datenbank die "erste Normalform" auf. Wenn die ersten drei Regeln beachtet werden, weist die Datenbank die "dritte Normalform" auf. Es sind zwar weitere Stufen der Normalisierung möglich, es wird jedoch allgemein davon ausgegangen, dass die dritte Normalform die Stufe ist, die für die meisten Anwendungen ausreicht.

Wie bei vielen formalen Regeln und Spezifikationen stehen die Verhältnisse in der Praxis einer strikten Einhaltung solcher Regeln häufig im Weg. Im Allgemeinen erfordert die Normalisierung zusätzliche Tabellen, was einige Kunden als umständlich empfinden. Wenn Sie sich entscheiden, eine der ersten drei Regeln der Normalisierung nicht zu beachten, stellen Sie sicher, dass Ihre Anwendung auf möglicherweise auftretende Probleme wie redundante Daten und inkonsistente Abhängigkeiten vorbereitet ist.

In den folgenden Beschreibungen sind Beispiele enthalten.

Erste Normalform

• Eliminieren Sie sich wiederholende Gruppen in Einzeltabellen.
• Erstellen einer separaten Tabelle für jeden Satz von Daten, die in einer Beziehung zueinander stehen.
• Kennzeichnen Sie jeden Satz von verwandten Daten mit einem Primärschlüssel.

Verwenden Sie nicht mehrere Felder in einer einzelnen Tabelle, um gleichartige Daten zu speichern. Um beispielsweise eine Bestandsposition nachzuverfolgen, die aus zwei möglichen Quellen stammen kann, enthält ein Bestandsdatensatz möglicherweise Felder für Lieferantencode 1 und Lieferantencode 2.

Was passiert, wenn Sie einen dritten Lieferanten hinzufügen? Das Hinzufügen eines Felds ist keine Lösung; es erfordert Änderungen des Programms und der Tabelle und kann eine dynamische Anzahl von Lieferanten nicht aufnehmen, ohne dass es Probleme gibt. Stellen Sie stattdessen alle Lieferantendaten in eine separate Tabelle namens "Lieferanten" und verknüpfen Sie anschließend den Bestand über einen Positionsnummernschlüssel mit den Lieferanten oder die Lieferanten über einen Lieferantencode-Schlüssel mit dem Bestand.

Zweite Normalform

• Erstellen Sie separate Tabellen für Sätze von Werten, die sich auf mehrere Datensätze beziehen.
• Setzen Sie diese Tabellen in Beziehung zu einem Fremdschlüssel.

Datensätze sollten nur vom Primärschlüssel einer Tabelle abhängig sein (falls erforderlich, ein zusammengesetzter Schlüssel). Nehmen wir beispielsweise eine Kundenadresse in einem Buchhaltungssystem. Die Adresse wird von der Tabelle "Kunden", aber auch von den Tabellen "Bestellungen", "Versand", "Rechnungen", "Forderungen" und "Inkasso" benötigt. Statt die Kundenadresse als separaten Eintrag in jeder dieser Tabellen zu speichern, speichern Sie sie an einer Stelle, entweder in der Tabelle "Kunden" oder in einer separaten Tabelle "Adressen".

Dritte Normalform

• Eliminieren Sie Felder, die nicht von dem Schlüssel abhängig sind.

Werte in einem Datensatz, die nicht Teil des Schlüssels dieses Datensatzes sind, gehören nicht in die Tabelle. Im Allgemeinen sollten Sie immer dann, wenn der Inhalt einer Gruppe von Feldern auf mehr als einen Datensatz in der Tabelle zutreffen kann, diese Felder in einer separaten Tabelle zusammenfassen.

Beispielsweise kann in einer Tabelle "Personalbeschaffung" der Name und die Adresse der Universität eines Kandidaten enthalten sein. Sie benötigen jedoch eine vollständige Liste von Universitäten für Serienbriefe. Wenn Universitätsdaten in der Tabelle "Kandidaten" gespeichert sind, besteht keine Möglichkeit, Universitäten aufzulisten, ohne dass aktuelle Kandidaten vorhanden sind. Erstellen Sie eine separate Tabelle "Universitäten" und verknüpfen Sie sie über einen Universitätscode-Schlüssel mit der Tabelle "Kandidaten".

AUSNAHME: Das Beachten der dritten Normalform ist zwar in der Theorie wünschenswert, in der Praxis jedoch nicht immer durchführbar. Wenn Sie eine Tabelle "Kunden" haben und alle möglichen Abhängigkeiten zwischen Feldern eliminieren möchten, müssen Sie separate Tabellen für Städte, Postleitzahlen, Vertreter, Kundenklassen und jeden weiteren Faktor erstellen, der in mehreren Datensätzen doppelt vorkommen kann. Theoretisch lohnt es sich, in die Normalisierung zu investieren. Viele kleine Tabellen können jedoch zu einer Leistungsminderung führen oder die Kapazität hinsichtlich der geöffneten Dateien und des verfügbaren Speichers überschreiten.

Es ist möglicherweise sinnvoller, die dritte Normalform nur auf Daten anzuwenden, die sich häufig ändern. Bleiben einige abhängige Felder erhalten, gestalten Sie Ihre Anwendung so, dass der Benutzer alle Felder überprüfen muss, wenn eines der zueinander in Beziehung stehenden Felder geändert wird.

Weitere Normalisierungsformen

Es gibt zwar auch die vierte Normalform, auch als Boyce Codd-Normalform (BCNF) bezeichnet, und die fünfte Normalform, diese werden in der Praxis jedoch nur selten angewendet. Werden diese Regeln nicht beachtet, kann das Datenbankdesign zwar nicht als theoretisch perfekt bezeichnet werden, die Funktionalität leidet jedoch in der Regel nicht darunter.

Normalisieren einer Beispieltabelle

Die folgenden Schritte demonstrieren den Prozess der Normalisierung einer fiktiven Tabelle "Studenten".

1. Nicht normalisierte Tabelle:
   Tabelle minimierenTabelle vergrößern

   Studentennr.:	Berater	Beraterzimmer	Klasse1	Klasse2	Klasse3
   1022	Jones	412	101-07	143-01	159-02
   4123	Smith	216	201-01	211-02	214-01

2. Erste Normalform: Keine sich wiederholenden Gruppen
   
   Tabellen sollten nur zwei Dimensionen aufweisen. Da ein Student mehrere Kurse hat, sollten diese Kurse in einer separaten Tabelle aufgelistet sein. Die Felder Kurs1, Kurs2 und Kurs3 in den obigen Datensätzen deuten auf Entwurfsprobleme hin.
   
   In Kalkulationstabellen wird häufig die dritte Dimension verwendet, bei anderen Tabellen sollte diese jedoch vermieden werden. Dieses Problem lässt sich auch über die 1:n-Beziehung betrachten: Setzen Sie die Seite "1" und die Seite "n" nicht in die gleiche Tabelle. Erstellen Sie stattdessen eine andere Tabelle in der ersten Normalform, indem Sie die sich wiederholende Gruppe (Kursnr.) wie unten dargestellt eliminieren:
   Tabelle minimierenTabelle vergrößern

   Studentennr.:	Berater	Beraterzimmer	Klassennr.
   1022	Jones	412	101-07
   1022	Jones	412	143-01
   1022	Jones	412	159-02
   4123	Smith	216	201-01
   4123	Smith	216	211-02
   4123	Smith	216	214-01

3. Zweite Normalform: Redundante Daten eliminieren
   
   Beachten Sie die mehrfachen Kursnr.-Werte für jeden Studentennr.-Wert in der obigen Tabelle. Es besteht keine funktionale Abhängigkeit zwischen "Kurs-Nr." und "Stud.-Nr." (Primärschlüssel), daher weist diese Beziehung nicht die zweite Normalform auf.
   
   Die beiden folgenden Tabellen zeigen die zweite Normalform:

   Studenten

   Tabelle minimierenTabelle vergrößern

   Studentennr.:	Berater	Beraterzimmer
   1022	Jones	412
   4123	Smith	216

   Registrierung

   Tabelle minimierenTabelle vergrößern

   Studentennr.:	Klassennr.
   1022	101-07
   1022	143-01
   1022	159-02
   4123	201-01
   4123	211-02
   4123	214-01

4. Dritte Normalform: Daten eliminieren, die nicht vom Schlüssel abhängig sind
   
   Im dritten Beispiel ist Beraterbüro (die Büronummer des Studienberaters) funktionell abhängig vom Attribut "Berater". Die Lösung besteht darin, dieses Attribut von der Tabelle "Studenten" in die Tabelle "Fachbereich" zu verschieben, wie unten dargestellt:

   Studenten

   Tabelle minimierenTabelle vergrößern

   Studentennr.:	Berater
   1022	Jones
   4123	Smith

   Fachbereich

   Tabelle minimierenTabelle vergrößern

   Name	Zimmer	Abt.
   Jones	412	42
   Smith	216	42

Ahlo, Hamilton M., Randy Brown und Peter Colclough. FoxPro 2: A Developer's Guide: Expert Guidance for Industrial-Strength Programming. John Wiley & Sons, Oktober 1991. Seiten 220-225.

Jennings, Roger. Using Access 1.1 for Windows. Que Corporation, Juli 1993. Seiten 799-800.