DetailPage-MSS-KB

Knowledge Base

Artikel-ID: 283878 - Geändert am: Montag, 6. November 2006 - Version: 5.4

Dieser Artikel wurde zuvor veröffentlicht unter D283878
Dieser Artikel ist eine Übersetzung des folgenden englischsprachigen Artikels der Microsoft Knowledge Base:
283878  (http://support.microsoft.com/kb/283878/EN-US/ ) Description of the database normalization basics
Anfänger: Erfordert Kenntnisse der Benutzeroberfläche auf Einzelplatzrechnern.

In Artikel 209534  (http://support.microsoft.com/kb/209534/DE/ ) wird dieses Thema für Microsoft Access 2000 behandelt.
In Artikel 100139  (http://support.microsoft.com/kb/100139/DE/ ) wird dieses Thema für Microsoft Access 95 bzw. Microsoft Access 97 behandelt.
Bitte beachten Sie: Bei diesem Artikel handelt es sich um eine Übersetzung aus dem Englischen. Es ist möglich, dass nachträgliche Änderungen bzw. Ergänzungen im englischen Originalartikel in dieser Übersetzung nicht berücksichtigt sind. Die in diesem Artikel enthaltenen Informationen basieren auf der/den englischsprachigen Produktversion(en). Die Richtigkeit dieser Informationen in Zusammenhang mit anderssprachigen Produktversionen wurde im Rahmen dieser Übersetzung nicht getestet. Microsoft stellt diese Informationen ohne Gewähr für Richtigkeit bzw. Funktionalität zur Verfügung und übernimmt auch keine Gewährleistung bezüglich der Vollständigkeit oder Richtigkeit der Übersetzung.

Auf dieser Seite

Zusammenfassung

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 behandelt werden. Sie finden diesen WebCast auf der folgenden Microsoft-Website:
http://support.microsoft.com/servicedesks/webcasts/wc060600/wc060600.asp?fr=1 (http://support.microsoft.com/?scid=http%3a%2f%2fsupport.microsoft.com%2fservicedesks%2fwebcasts%2fwc060600%2fwc060600.asp%3ffr%3d1)

Weitere Informationen

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.:BeraterBeraterzimmerKurs1Kurs2Kurs3
    1022Jones412101-07143-01159-02
    4123Smith216201-01211-02214-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.:BeraterBeraterzimmerKursnr.
    1022Jones412101-07
    1022Jones412143-01
    1022Jones412159-02
    4123Smith216201-01
    4123Smith216211-02
    4123Smith216214-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.:BeraterBeraterzimmer
    1022Jones412
    4123Smith216


    Registrierung:

    Tabelle minimierenTabelle vergrößern
    Studentennr.:Kursnr.
    1022101-07
    1022143-01
    1022159-02
    4123201-01
    4123211-02
    4123214-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
    1022Jones
    4123Smith


    Fachber.:

    Tabelle minimierenTabelle vergrößern
    NameZimmerAbt.
    Jones41242
    Smith21642

Die Informationen in diesem Artikel beziehen sich auf:
  • Microsoft Office Access 2003
  • Microsoft Access 2002 Standard Edition
Keywords: 
kbinfo kbdesign kbdatabase kbhowto KB283878
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.
Freigeben
Weitere Supportoptionen
Microsoft Community-Supportforen
Kontaktieren Sie uns direkt
Zertifizierten Partner finden
Microsoft Store