ACC: Grundlagen der Datenbanknormalisierung

SPRACHE AUSWÄHLEN SPRACHE AUSWÄHLEN
Artikel-ID: 100139 - Produkte anzeigen, auf die sich dieser Artikel bezieht
Dieser Artikel wurde zuvor veröffentlicht unter D100139
Dieser Artikel ist eine Übersetzung des folgenden englischsprachigen Artikels der Microsoft Knowledge Base:
100139 ACC: Database Normalization Basics
Anfänger: Erfordert Kenntnisse der Benutzeroberfläche auf Einzelplatzrechnern.

Alles erweitern | Alles schließen

Auf dieser Seite

Zusammenfassung

Dieser Artikel erläutert die Terminologie der 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:
http://support.microsoft.com/servicedesks/webcasts/wc060600/wc060600.asp?fr=1
Hinweis: Informationen zu diesem Thema für Microsoft Access 2000 finden Sie in folgendem Artikel der Microsoft Knowledge Base:
209534 ACC2000: Database Normalization Basics

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 Redundanzen und inkonsistenten Abhängigkeiten zu erhöhen.

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, da 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.

Hinweis: Die folgenden Beschreibungen enthalten Beispiele.

Erste Normalform

  • Eliminieren sich wiederholender Gruppen in einzelnen Tabellen.
  • Erstellen einer separaten Tabelle für jeden Satz von Daten, die in einer Beziehung zueinander stehen.
  • Kennzeichnen jedes Satzes mit zueinander in Beziehung stehenden 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 jedoch, 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 separater Tabellen für Sätze von Werten, die auf mehrere Datensätze zutreffen.
  • Herstellen einer Beziehung zwischen diesen Tabellen mit 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 von Feldern, die nicht vom 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 wollen, 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. In der Theorie ist die Normalisierung wünschenswert. 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.
               **********************************
                 Beispiele für normalisierte Tabellen
               **********************************

 Normalisierungsbeispiele:

 Nicht normalisierte Tabelle:

    Student#   Berater   Ber-Raum  Kurs1    Kurs2    Kurs3
    -------------------------------------------------------
    1022       Jones      412      101-07   143-01   159-02
    4123       Smith      216      201-01   211-02   214-01
  1. 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 Designprobleme hin.

    In Kalkulationstabellen wird häufig die dritte Dimension verwendet, bei anderen Tabellen sollte diese jedoch vermieden werden. Eine andere Vorgehensweise bei diesem Problem: Stellen Sie bei einer 1:n-Beziehung die 1-Seite und die n-Seite nicht in dieselbe Tabelle. Erstellen Sie stattdessen eine andere Tabelle in der ersten Normalform, indem Sie die sich wiederholende Gruppe (Kursnr.) wie unten dargestellt eliminieren:
           Stud.-Nr.  Berater   Ber-Raum    Kurs-Nr.
           ---------------------------------------
           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
  2. Zweite Normalform: ELIMINIEREN REDUNDANTER DATEN

    Beachten Sie, dass in der vorstehenden Tabelle mehrere Werte des Typs "Kurs-Nr." für jeden Wert des Typs "Stud.-Nr." vorhanden sind. 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:  Student Nr. Berater   Ber-Raum
                    ------------------------------
                    1022        Jones       412
                    4123        Smith       216
    
        Registrierung:  Stud.-Nr.   Kurs-Nr.
                        ------------------
                        1022        101-07
                        1022        143-01
                        1022        159-02
                        4123        201-01
                        4123        211-02
                        4123        214-01
  3. Dritte Normalform: ELIMINIEREN VON DATEN, DIE NICHT VON EINEM 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:   Stud.-Nr.   Berater
                    -------------------
                    1022        Jones
                    4123        Smith
    
        Fachber.:    Name    Raum    Abt.
                    --------------------
                    Jones   412     42
                    Smith   216     42

Informationsquellen

Weitere Informationen zum Entwerfen einer Datenbank finden Sie in folgendem Artikel der Microsoft Knowledge Base:
234208 ACC2000: "Understanding Relational Database Design" Document Available in Download Center
"FoxPro 2 A Developer's Guide," Hamilton M. Ahlo Jr. et al., pages 220-225, M & T Books, 1991

"Using Access for Windows," Roger Jennings, pages 799-800, Que Corporation, 1993

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.

Eigenschaften

Artikel-ID: 100139 - Geändert am: Dienstag, 19. August 2003 - Version: 2.1
Die Informationen in diesem Artikel beziehen sich auf:
  • Microsoft Access 1.0 Standard Edition
  • Microsoft Access 1.1 Standard Edition
  • Microsoft Access 2.0 Standard Edition
  • Microsoft Access 95 Standard Edition
  • Microsoft Access 97 Standard Edition
Keywords: 
kbinfo kbusage KB100139
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.
Disclaimer zu nicht mehr gepflegten KB-Inhalten
Dieser Artikel wurde für Produkte verfasst, für die Microsoft keinen Support mehr anbietet. Der Artikel wird deshalb in der vorliegenden Form bereitgestellt und nicht mehr weiter aktualisiert.

Ihr Feedback an uns

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com