Grundlagen des Datenbankdesigns
Eine richtig gestaltete Datenbank bietet Ihnen Zugriff auf aktuelle, genaue Informationen. Da ein korrektes Design unerlässlich ist, um Ihre Ziele bei der Arbeit mit einer Datenbank zu erreichen, ist es sinnvoll, die Zeit zu investieren, die zum Erlernen der Prinzipien eines guten Designs erforderlich ist. Am Ende ist es viel wahrscheinlicher, dass Sie eine Datenbank haben, die Ihren Anforderungen entspricht und Änderungen problemlos aufnehmen kann.
Dieser Artikel enthält Richtlinien zum Planen einer Desktopdatenbank. Sie lernen, wie Sie entscheiden, welche Informationen Sie benötigen, wie Sie diese Informationen in die entsprechenden Tabellen und Spalten aufteilen und wie diese Tabellen miteinander in Beziehung stehen. Sie sollten diesen Artikel lesen, bevor Sie Ihre erste Desktop-Datenbank erstellen.
Wichtig: Access bietet Designerfahrungen, mit denen Sie Datenbankanwendungen für das Web erstellen können. Viele Designüberlegungen sind anders, wenn Sie für das Web entwerfen. In diesem Artikel wird das Design von Webdatenbankanwendungen nicht behandelt. Weitere Informationen finden Sie im Artikel Erstellen einer Datenbank für die gemeinsame Nutzung im Web .
In diesem Artikel
Einige Datenbankbegriffe, die Sie kennen sollten
Access organisiert Ihre Informationen in Tabellen : Listen von Zeilen und Spalten, die an den Block eines Buchhalters oder eine Tabellenkalkulation erinnern. In einer einfachen Datenbank haben Sie möglicherweise nur eine Tabelle. Für die meisten Datenbanken benötigen Sie mehr als eine. Beispielsweise könnten Sie eine Tabelle haben, die Informationen zu Produkten speichert, eine andere Tabelle, die Informationen zu Bestellungen speichert, und eine weitere Tabelle mit Informationen zu Kunden.
Jede Zeile wird korrekterweise als Datensatz und jede Spalte als Feld bezeichnet. Ein Datensatz ist eine sinnvolle und konsistente Möglichkeit, Informationen über etwas zu kombinieren. Ein Feld ist ein einzelnes Informationselement – ein Elementtyp, der in jedem Datensatz erscheint. In der Tabelle „Produkte" enthält beispielsweise jede Zeile oder jeder Datensatz Informationen zu einem Produkt. Jede Spalte oder jedes Feld enthält Informationen zu diesem Produkt, z. B. seinen Namen oder Preis.
Was ist gutes Datenbankdesign?
Bestimmte Prinzipien leiten den Datenbankentwurfsprozess. Das erste Prinzip ist, dass doppelte Informationen (auch als redundante Daten bezeichnet) schlecht sind, da sie Speicherplatz verschwenden und die Wahrscheinlichkeit von Fehlern und Inkonsistenzen erhöhen. Der zweite Grundsatz ist, dass die Richtigkeit und Vollständigkeit der Informationen wichtig ist. Wenn Ihre Datenbank falsche Informationen enthält, enthalten alle Berichte, die Informationen aus der Datenbank abrufen, ebenfalls falsche Informationen. Infolgedessen werden alle Entscheidungen, die Sie auf der Grundlage dieser Berichte treffen, falsch informiert.
Ein gutes Datenbankdesign ist daher eines, das:
Unterteilt Ihre Informationen in themenbasierte Tabellen, um redundante Daten zu reduzieren.
Versorgt Access mit den erforderlichen Informationen, um die Informationen in den Tabellen nach Bedarf zusammenzuführen.
Hilft, die Genauigkeit und Integrität Ihrer Informationen zu unterstützen und sicherzustellen.
Erfüllt Ihre Datenverarbeitungs- und Berichterstellungsanforderungen.
Der Designprozess
Der Designprozess besteht aus den folgenden Schritten:
Bestimmen Sie den Zweck Ihrer Datenbank
Dies hilft Ihnen, sich auf die verbleibenden Schritte vorzubereiten.
Suchen und organisieren Sie die erforderlichen Informationen
Sammeln Sie alle Arten von Informationen, die Sie möglicherweise in der Datenbank aufzeichnen möchten, z. B. Produktname und Bestellnummer.
Teilen Sie die Informationen in Tabellen auf
Unterteilen Sie Ihre Informationselemente in Haupteinheiten oder Themen wie Produkte oder Bestellungen. Jedes Thema wird dann zu einer Tabelle.
Verwandeln Sie Informationselemente in Spalten
Entscheiden Sie, welche Informationen Sie in jeder Tabelle speichern möchten. Jedes Element wird zu einem Feld und wird als Spalte in der Tabelle angezeigt. Beispielsweise kann eine Tabelle "Mitarbeiter" Felder wie "Nachname" und "Einstellungsdatum" enthalten.
Primärschlüssel angeben
Wählen Sie den Primärschlüssel jeder Tabelle aus. Der Primärschlüssel ist eine Spalte, die verwendet wird, um jede Zeile eindeutig zu identifizieren. Ein Beispiel könnte Produkt-ID oder Bestell-ID sein.
Richten Sie die Tabellenbeziehungen ein
Sehen Sie sich jede Tabelle an und entscheiden Sie, in welcher Beziehung die Daten in einer Tabelle zu den Daten in anderen Tabellen stehen. Fügen Sie bei Bedarf Felder zu Tabellen hinzu oder erstellen Sie neue Tabellen, um die Beziehungen zu verdeutlichen.
Verfeinern Sie Ihr Design
Analysieren Sie Ihr Design auf Fehler. Erstellen Sie die Tabellen und fügen Sie einige Datensätze mit Beispieldaten hinzu. Prüfen Sie, ob Sie mit Ihren Tabellen die gewünschten Ergebnisse erzielen können. Nehmen Sie bei Bedarf Anpassungen am Design vor.
Wenden Sie die Normalisierungsregeln an
Wenden Sie die Datennormalisierungsregeln an, um zu sehen, ob Ihre Tabellen richtig strukturiert sind. Nehmen Sie bei Bedarf Anpassungen an den Tabellen vor.
Bestimmung des Zwecks Ihrer Datenbank
Es ist eine gute Idee, den Zweck der Datenbank auf Papier festzuhalten – ihren Zweck, wie Sie sie voraussichtlich verwenden werden und wer sie verwenden wird. Für eine kleine Datenbank für ein Geschäft von zu Hause aus könnten Sie beispielsweise etwas Einfaches schreiben wie „Die Kundendatenbank enthält eine Liste mit Kundeninformationen zum Zweck der Erstellung von Mailings und Berichten." Wenn die Datenbank komplexer ist oder von vielen Personen verwendet wird, wie dies häufig in einer Unternehmensumgebung vorkommt, kann der Zweck leicht einen Absatz oder mehr umfassen und sollte beinhalten, wann und wie jede Person die Datenbank verwendet. Die Idee ist, ein gut entwickeltes Leitbild zu haben, auf das während des gesamten Designprozesses Bezug genommen werden kann. Eine solche Aussage hilft Ihnen, sich auf Ihre Ziele zu konzentrieren, wenn Sie Entscheidungen treffen.
Suchen und Organisieren der erforderlichen Informationen
Um die erforderlichen Informationen zu finden und zu organisieren, beginnen Sie mit Ihren vorhandenen Informationen. Beispielsweise können Sie Bestellungen in einem Hauptbuch aufzeichnen oder Kundeninformationen auf Papierformularen in einem Aktenschrank aufbewahren. Sammeln Sie diese Dokumente und listen Sie alle angezeigten Informationen auf (z. B. jedes Feld, das Sie in einem Formular ausfüllen). Wenn Sie keine vorhandenen Formulare haben, stellen Sie sich stattdessen vor, Sie müssten ein Formular entwerfen, um die Kundeninformationen aufzuzeichnen. Welche Informationen würden Sie in das Formular eintragen? Welche Füllfelder würden Sie erstellen? Identifizieren und listen Sie jedes dieser Elemente auf. Angenommen, Sie führen die Kundenliste derzeit auf Karteikarten. Die Untersuchung dieser Karten könnte zeigen, dass jede Karte den Namen, die Adresse, die Stadt, das Bundesland, die Postleitzahl und die Telefonnummer eines Kunden enthält. Jedes dieser Elemente repräsentiert eine mögliche Spalte in einer Tabelle.
Machen Sie sich bei der Erstellung dieser Liste keine Gedanken darüber, dass sie am Anfang perfekt ist. Listen Sie stattdessen jeden Punkt auf, der Ihnen in den Sinn kommt. Wenn jemand anderes die Datenbank verwendet, fragen Sie auch nach seinen Ideen. Sie können die Liste später verfeinern.
Überlegen Sie als Nächstes, welche Arten von Berichten oder Mailings Sie möglicherweise aus der Datenbank erstellen möchten. Beispielsweise möchten Sie möglicherweise, dass ein Produktverkaufsbericht die Verkäufe nach Region anzeigt, oder ein Bestandszusammenfassungsbericht, der die Produktbestandsniveaus anzeigt. Möglicherweise möchten Sie auch Serienbriefe generieren, die Sie an Kunden senden, die ein Verkaufsereignis ankündigen oder eine Prämie anbieten. Gestalten Sie den Bericht in Gedanken und stellen Sie sich vor, wie er aussehen würde. Welche Informationen würden Sie in den Bericht aufnehmen? Liste jeden Artikel auf. Machen Sie dasselbe für den Serienbrief und für jeden anderen Bericht, den Sie erstellen möchten.
Wenn Sie über die Berichte und Mailings nachdenken, die Sie möglicherweise erstellen möchten, können Sie die Elemente identifizieren, die Sie in Ihrer Datenbank benötigen. Angenommen, Sie geben Kunden die Möglichkeit, sich für (oder gegen) regelmäßige E-Mail-Updates anzumelden, und Sie möchten eine Liste derjenigen drucken, die sich angemeldet haben. Um diese Informationen aufzuzeichnen, fügen Sie ein „E-Mail senden" hinzu. mail"-Spalte in die Kundentabelle. Für jeden Kunden können Sie das Feld auf Ja oder Nein setzen.
Die Anforderung, E-Mail-Nachrichten an Kunden zu senden, schlägt ein weiteres aufzuzeichnendes Element vor. Sobald Sie wissen, dass ein Kunde E-Mail-Nachrichten erhalten möchte, müssen Sie auch die E-Mail-Adresse kennen, an die er sie senden soll. Daher müssen Sie für jeden Kunden eine E-Mail-Adresse hinterlegen.
Es ist sinnvoll, einen Prototyp jedes Berichts oder jeder Ausgabeliste zu erstellen und zu überlegen, welche Elemente Sie zur Erstellung des Berichts benötigen. Wenn Sie beispielsweise einen Serienbrief untersuchen, fallen Ihnen möglicherweise einige Dinge ein. Wenn Sie eine angemessene Anrede einfügen möchten – zum Beispiel „Herr", „Frau". oder "Frau." Zeichenfolge, die eine Begrüßung einleitet, müssen Sie ein Begrüßungselement erstellen. Außerdem beginnen Sie einen Brief normalerweise mit „Dear Mr. Smith" und nicht mit „Dear. Herr Sylvester Smith". Dies deutet darauf hin, dass Sie normalerweise den Nachnamen getrennt vom Vornamen speichern möchten.
Ein wichtiger Punkt, den Sie sich merken sollten, ist, dass Sie jede Information in ihre kleinsten nützlichen Teile zerlegen sollten. Im Falle eines Namens teilen Sie den Namen in zwei Teile auf, um den Nachnamen leicht verfügbar zu machen – Vorname und Nachname. Um einen Bericht beispielsweise nach Nachnamen zu sortieren, ist es hilfreich, den Nachnamen des Kunden separat zu speichern. Wenn Sie auf der Grundlage eines Informationselements sortieren, suchen, berechnen oder berichten möchten, sollten Sie dieses Element im Allgemeinen in ein eigenes Feld einfügen.
Denken Sie über die Fragen nach, die die Datenbank möglicherweise beantworten soll. Wie viele Verkäufe Ihres vorgestellten Produkts haben Sie beispielsweise letzten Monat abgeschlossen? Wo leben Ihre besten Kunden? Wer ist der Lieferant für Ihr meistverkauftes Produkt? Wenn Sie diese Fragen antizipieren, können Sie sich auf zusätzliche Elemente konzentrieren, die Sie aufzeichnen müssen.
Nachdem Sie diese Informationen gesammelt haben, sind Sie bereit für den nächsten Schritt.
Aufteilung der Informationen in Tabellen
Um die Informationen in Tabellen aufzuteilen, wählen Sie die wichtigsten Entitäten oder Themen aus. Nachdem Sie beispielsweise Informationen für eine Produktverkaufsdatenbank gefunden und organisiert haben, könnte die vorläufige Liste wie folgt aussehen:
Die hier gezeigten Haupteinheiten sind die Produkte, die Lieferanten, die Kunden und die Bestellungen. Daher ist es sinnvoll, mit diesen vier Tabellen zu beginnen: eine für Fakten zu Produkten, eine für Fakten zu Lieferanten, eine für Fakten zu Kunden und eine für Fakten zu Bestellungen. Obwohl dies die Liste nicht vervollständigt, ist es ein guter Ausgangspunkt. Sie können diese Liste weiter verfeinern, bis Sie ein Design haben, das gut funktioniert.
Wenn Sie die vorläufige Liste der Elemente zum ersten Mal überprüfen, könnten Sie versucht sein, sie alle in einer einzigen Tabelle zu platzieren, anstatt der vier in der vorherigen Abbildung. Warum das keine gute Idee ist, erfahren Sie hier. Betrachten Sie für einen Moment die hier gezeigte Tabelle:
In diesem Fall enthält jede Zeile Informationen über das Produkt und seinen Lieferanten. Da Sie viele Produkte von demselben Lieferanten haben können, müssen der Name und die Adressinformationen des Lieferanten viele Male wiederholt werden. Dadurch wird Speicherplatz verschwendet. Die Lieferanteninformationen nur einmal in einer separaten Tabelle „Lieferanten" aufzuzeichnen und diese Tabelle dann mit der Tabelle „Produkte" zu verknüpfen, ist eine viel bessere Lösung.
Ein zweites Problem bei diesem Design tritt auf, wenn Sie Informationen über den Lieferanten ändern müssen. Angenommen, Sie müssen die Adresse eines Lieferanten ändern. Da es an vielen Stellen erscheint, könnten Sie versehentlich die Adresse an einer Stelle ändern, aber vergessen, sie an den anderen zu ändern. Das Erfassen der Adresse des Lieferanten an nur einer Stelle löst das Problem.
Versuchen Sie beim Entwerfen Ihrer Datenbank immer, jeden Fakt nur einmal zu erfassen. Wenn Sie feststellen, dass Sie dieselben Informationen an mehr als einer Stelle wiederholen, z. B. die Adresse eines bestimmten Lieferanten, platzieren Sie diese Informationen in einer separaten Tabelle.
Angenommen, es gibt nur ein Produkt, das von Coho Winery geliefert wird, und Sie möchten das Produkt löschen, aber den Lieferantennamen und die Adressinformationen beibehalten. Wie würden Sie den Produktdatensatz löschen, ohne auch die Lieferanteninformationen zu verlieren? Du kannst nicht. Da jeder Datensatz sowohl Fakten zu einem Produkt als auch zu einem Lieferanten enthält, können Sie den einen nicht löschen, ohne den anderen zu löschen. Um diese Fakten getrennt zu halten, müssen Sie die eine Tabelle in zwei Teile aufteilen: eine Tabelle für Produktinformationen und eine weitere Tabelle für Lieferanteninformationen. Das Löschen eines Produktdatensatzes sollte nur die Fakten über das Produkt löschen, nicht die Fakten über den Lieferanten.
Sobald Sie das Thema ausgewählt haben, das durch eine Tabelle dargestellt wird, sollten die Spalten in dieser Tabelle nur Fakten über das Thema speichern. Beispielsweise sollte die Produkttabelle nur Fakten über Produkte speichern. Da die Lieferantenadresse eine Tatsache über den Lieferanten und keine Tatsache über das Produkt ist, gehört sie in die Lieferantentabelle.
Informationen in Spalten umwandeln
Um die Spalten in einer Tabelle zu bestimmen, entscheiden Sie, welche Informationen Sie über das in der Tabelle aufgezeichnete Thema nachverfolgen müssen. Für die Kundentabelle beispielsweise bilden Name, Adresse, Stadt-Staat-PLZ, E-Mail senden, Anrede und E-Mail-Adresse eine gute Startliste von Spalten. Jeder Datensatz in der Tabelle enthält die gleichen Spalten, sodass Sie Name, Adresse, Stadt-Bundesland-PLZ, E-Mail senden, Anrede und E-Mail-Adresse für jeden Datensatz speichern können. Beispielsweise enthält die Adressspalte Kundenadressen. Jeder Datensatz enthält Daten über einen Kunden, und das Adressfeld enthält die Adresse für diesen Kunden.
Nachdem Sie den anfänglichen Spaltensatz für jede Tabelle festgelegt haben, können Sie die Spalten weiter verfeinern. Beispielsweise ist es sinnvoll, den Kundennamen in zwei separaten Spalten zu speichern: Vorname und Nachname, damit Sie nur nach diesen Spalten sortieren, suchen und indizieren können. Ebenso besteht die Adresse tatsächlich aus fünf separaten Komponenten, Adresse, Stadt, Bundesland, Postleitzahl und Land/Region, und es ist auch sinnvoll, sie in separaten Spalten zu speichern. Wenn Sie beispielsweise nach Bundesland suchen, filtern oder sortieren möchten, müssen Sie die Bundeslandinformationen in einer separaten Spalte speichern.
Sie sollten auch überlegen, ob die Datenbank nur Informationen aus dem Inland oder auch internationale Informationen enthält. Wenn Sie beispielsweise internationale Adressen speichern möchten, ist es besser, eine Regionsspalte anstelle von Bundesstaat zu haben, da eine solche Spalte sowohl inländische Bundesstaaten als auch die Regionen anderer Länder/Regionen enthalten kann. Ebenso ist die Postleitzahl sinnvoller als die Postleitzahl, wenn Sie internationale Adressen speichern möchten.
Die folgende Liste zeigt einige Tipps zur Bestimmung Ihrer Spalten.
Schließen Sie keine berechneten Daten ein
In den meisten Fällen sollten Sie das Ergebnis von Berechnungen nicht in Tabellen speichern. Stattdessen können Sie Access die Berechnungen ausführen lassen, wenn Sie das Ergebnis sehen möchten. Angenommen, es gibt einen Bericht „Produkte auf Bestellung", der die Zwischensumme der bestellten Einheiten für jede Produktkategorie in der Datenbank anzeigt. Es gibt jedoch in keiner Tabelle eine Zwischensummenspalte für bestellte Einheiten. Stattdessen enthält die Tabelle „Produkte" eine Spalte „Bestellte Einheiten", in der die bestellten Einheiten für jedes Produkt gespeichert werden. Anhand dieser Daten berechnet Access jedes Mal, wenn Sie den Bericht drucken, die Zwischensumme. Die Zwischensumme selbst sollte nicht in einer Tabelle gespeichert werden.
Speichern Sie Informationen in ihren kleinsten logischen Teilen
Sie könnten versucht sein, ein einzelnes Feld für vollständige Namen oder für Produktnamen zusammen mit Produktbeschreibungen zu haben. Wenn Sie mehr als eine Art von Informationen in einem Feld kombinieren, ist es schwierig, einzelne Fakten später wiederzufinden. Versuchen Sie, Informationen in logische Teile zu zerlegen; Erstellen Sie beispielsweise separate Felder für Vor- und Nachname oder für Produktnamen, Kategorie und Beschreibung.
Nachdem Sie die Datenspalten in jeder Tabelle verfeinert haben, können Sie den Primärschlüssel jeder Tabelle auswählen.
Angabe von Primärschlüsseln
Jede Tabelle sollte eine Spalte oder eine Gruppe von Spalten enthalten, die jede in der Tabelle gespeicherte Zeile eindeutig identifiziert. Dies ist häufig eine eindeutige Identifikationsnummer, wie z. B. eine Mitarbeiter-ID-Nummer oder eine Seriennummer. In der Datenbankterminologie werden diese Informationen als Primärschlüssel der Tabelle bezeichnet. Access verwendet Primärschlüsselfelder, um Daten aus mehreren Tabellen schnell zuzuordnen und die Daten für Sie zusammenzuführen.
Wenn Sie bereits eine eindeutige Kennung für eine Tabelle haben, z. B. eine Produktnummer, die jedes Produkt in Ihrem Katalog eindeutig identifiziert, können Sie diese Kennung als Primärschlüssel der Tabelle verwenden – aber nur, wenn die Werte in dieser Spalte immer unterschiedlich sind Aufzeichnung. Ein Primärschlüssel darf keine doppelten Werte enthalten. Verwenden Sie beispielsweise nicht die Namen von Personen als Primärschlüssel, da Namen nicht eindeutig sind. Sie könnten leicht zwei Personen mit demselben Namen in derselben Tabelle haben.
Ein Primärschlüssel muss immer einen Wert haben. Wenn der Wert einer Spalte irgendwann nicht mehr zugewiesen oder unbekannt (ein fehlender Wert) werden kann, kann er nicht als Komponente in einem Primärschlüssel verwendet werden.
Sie sollten immer einen Primärschlüssel wählen, dessen Wert sich nicht ändert. In einer Datenbank, die mehr als eine Tabelle verwendet, kann der Primärschlüssel einer Tabelle als Referenz in anderen Tabellen verwendet werden. Wenn sich der Primärschlüssel ändert, muss die Änderung auch überall dort angewendet werden, wo auf den Schlüssel verwiesen wird. Die Verwendung eines Primärschlüssels, der sich nicht ändert, verringert die Wahrscheinlichkeit, dass der Primärschlüssel nicht mehr mit anderen Tabellen synchronisiert ist, die auf ihn verweisen.
Als Primärschlüssel wird häufig eine beliebige eindeutige Zahl verwendet. Beispielsweise können Sie jeder Bestellung eine eindeutige Bestellnummer zuweisen. Die Bestellnummer dient ausschließlich der Identifizierung einer Bestellung. Einmal zugewiesen, ändert es sich nie.
Wenn Sie keine Spalte oder keinen Satz von Spalten im Sinn haben, die einen guten Primärschlüssel abgeben könnten, sollten Sie eine Spalte mit dem Datentyp „AutoWert" verwenden. Wenn Sie den AutoWert-Datentyp verwenden, weist Access Ihnen automatisch einen Wert zu. Eine solche Kennung ist faktenlos; es enthält keine sachlichen Informationen, die die Zeile beschreiben, die es darstellt. Tatsachenlose Identifikatoren sind ideal für die Verwendung als Primärschlüssel, da sie sich nicht ändern. Ein Primärschlüssel, der Fakten zu einer Zeile enthält – beispielsweise eine Telefonnummer oder einen Kundennamen – ändert sich eher, da sich die Fakteninformationen selbst ändern können.
1. Eine auf den Datentyp „AutoWert" festgelegte Spalte ist häufig ein guter Primärschlüssel. Keine zwei Produkt-IDs sind gleich.
In einigen Fällen möchten Sie möglicherweise zwei oder mehr Felder verwenden, die zusammen den Primärschlüssel einer Tabelle bereitstellen. Beispielsweise würde eine Tabelle mit Bestelldetails, die Einzelposten für Bestellungen speichert, zwei Spalten in ihrem Primärschlüssel verwenden: Bestell-ID und Produkt-ID. Wenn ein Primärschlüssel mehr als eine Spalte verwendet, wird er auch als zusammengesetzter Schlüssel bezeichnet.
Für die Produktverkaufsdatenbank können Sie für jede der Tabellen eine AutoWert-Spalte erstellen, die als Primärschlüssel dient: ProductID für die Products-Tabelle, OrderID für die Orders-Tabelle, CustomerID für die Customers-Tabelle und SupplierID für die Suppliers-Tabelle.
Erstellen der Tabellenbeziehungen
Nachdem Sie Ihre Informationen nun in Tabellen aufgeteilt haben, brauchen Sie eine Möglichkeit, die Informationen sinnvoll wieder zusammenzuführen. Das folgende Formular enthält beispielsweise Informationen aus mehreren Tabellen.
1. Die Informationen in diesem Formular stammen aus der Kundentabelle...
2. ... die Mitarbeitertabelle ...
3. ... die Orders-Tabelle ...
4. ... die Produkttabelle ...
5. ... und die Tabelle mit den Bestelldetails.
Access ist ein relationales Datenbankverwaltungssystem. In einer relationalen Datenbank teilen Sie Ihre Informationen in separate, themenbasierte Tabellen auf. Anschließend verwenden Sie Tabellenbeziehungen, um die Informationen nach Bedarf zusammenzuführen.
Erstellen einer Eins-zu-Viele-Beziehung
Betrachten Sie dieses Beispiel: die Tabellen Suppliers und Products in der Datenbank für Produktbestellungen. Ein Lieferant kann beliebig viele Produkte liefern. Daraus folgt, dass für jeden Lieferanten, der in der Tabelle „Lieferanten" dargestellt wird, viele Produkte in der Tabelle „Produkte" dargestellt werden können. Die Beziehung zwischen der Tabelle Suppliers und der Tabelle Products ist daher eine Eins-zu-Viele-Beziehung.
Um eine Eins-zu-Viele-Beziehung in Ihrem Datenbankdesign darzustellen, nehmen Sie den Primärschlüssel auf der „Eins"-Seite der Beziehung und fügen ihn als zusätzliche Spalte oder Spalten zur Tabelle auf der „Viele"-Seite der Beziehung hinzu. In diesem Fall fügen Sie beispielsweise die Spalte „Lieferanten-ID" aus der Tabelle „Lieferanten" zur Tabelle „Produkte" hinzu. Access kann dann die Lieferanten-ID-Nummer in der Tabelle Produkte verwenden, um den richtigen Lieferanten für jedes Produkt zu finden.
Die Spalte „Lieferanten-ID" in der Tabelle „Produkte" wird als Fremdschlüssel bezeichnet. Ein Fremdschlüssel ist der Primärschlüssel einer anderen Tabelle. Die Spalte „Lieferanten-ID" in der Tabelle „Produkte" ist ein Fremdschlüssel, da sie auch der Primärschlüssel in der Tabelle „Lieferanten" ist.
Sie schaffen die Grundlage für das Zusammenführen verwandter Tabellen, indem Sie Paare von Primärschlüsseln und Fremdschlüsseln erstellen. Wenn Sie sich nicht sicher sind, welche Tabellen eine gemeinsame Spalte gemeinsam nutzen sollten, stellen Sie durch die Identifizierung einer 1:n-Beziehung sicher, dass die beiden beteiligten Tabellen tatsächlich eine gemeinsam genutzte Spalte benötigen.
Erstellen einer Viele-zu-Viele-Beziehung
Betrachten Sie die Beziehung zwischen der Tabelle „Products" und der Tabelle „Orders".
Eine einzelne Bestellung kann mehr als ein Produkt enthalten. Andererseits kann ein einzelnes Produkt auf vielen Bestellungen erscheinen. Daher können für jeden Datensatz in der Tabelle „Bestellungen" viele Datensätze in der Tabelle „Produkte" vorhanden sein. Und für jeden Datensatz in der Tabelle „Products" können viele Datensätze in der Tabelle „Orders" vorhanden sein. Diese Art von Beziehung wird Viele-zu-Viele-Beziehung genannt, weil es für jedes Produkt viele Bestellungen geben kann; und für jede Bestellung kann es viele Produkte geben. Beachten Sie, dass es zum Erkennen von Viele-zu-viele-Beziehungen zwischen Ihren Tabellen wichtig ist, dass Sie beide Seiten der Beziehung berücksichtigen.
Die Themen der beiden Tabellen – Bestellungen und Produkte – haben eine Viele-zu-Viele-Beziehung. Dies stellt ein Problem dar. Um das Problem zu verstehen, stellen Sie sich vor, was passieren würde, wenn Sie versuchen würden, die Beziehung zwischen den beiden Tabellen herzustellen, indem Sie das Feld „Produkt-ID" zur Tabelle „Bestellungen" hinzufügen. Um mehr als ein Produkt pro Bestellung zu haben, benötigen Sie mehr als einen Datensatz in der Orders-Tabelle pro Bestellung. Sie würden Bestellinformationen für jede Zeile wiederholen, die sich auf eine einzelne Bestellung bezieht – was zu einem ineffizienten Design führt, das zu ungenauen Daten führen könnte. Sie stoßen auf das gleiche Problem, wenn Sie das Feld „Bestell-ID" in die Tabelle „Produkte" einfügen – Sie hätten mehr als einen Datensatz in der Tabelle „Produkte" für jedes Produkt. Wie lösen Sie dieses Problem?
Die Antwort besteht darin, eine dritte Tabelle zu erstellen, die oft als Verbindungstabelle bezeichnet wird und die Viele-zu-Viele-Beziehungen in zwei Eins-zu-Viele-Beziehungen aufteilt. Sie fügen den Primärschlüssel aus jeder der beiden Tabellen in die dritte Tabelle ein. Als Ergebnis zeichnet die dritte Tabelle jedes Auftreten oder jede Instanz der Beziehung auf.
Jeder Datensatz in der Tabelle „Bestelldetails" stellt einen Einzelposten einer Bestellung dar. Der Primärschlüssel der Tabelle „Bestelldetails" besteht aus zwei Feldern – den Fremdschlüsseln aus den Tabellen „Bestellungen" und „Produkte". Die Verwendung des Auftrags-ID-Felds allein funktioniert nicht als Primärschlüssel für diese Tabelle, da ein Auftrag viele Einzelposten haben kann. Die Bestell-ID wird für jede Position einer Bestellung wiederholt, sodass das Feld keine eindeutigen Werte enthält. Die Verwendung des Produkt-ID-Felds allein funktioniert auch nicht, da ein Produkt in vielen verschiedenen Bestellungen erscheinen kann. Aber zusammen erzeugen die beiden Felder immer einen eindeutigen Wert für jeden Datensatz.
In der Produktverkaufsdatenbank stehen die Tabelle "Bestellungen" und die Tabelle "Produkte" nicht direkt miteinander in Beziehung. Stattdessen sind sie indirekt über die Tabelle „Bestelldetails" verbunden. Die Viele-zu-Viele-Beziehung zwischen Bestellungen und Produkten wird in der Datenbank durch zwei Eins-zu-Viele-Beziehungen dargestellt:
Die Tabellen „Bestellungen" und „Bestelldetails" haben eine 1:n-Beziehung. Jede Bestellung kann mehr als eine Werbebuchung haben, aber jede Werbebuchung ist nur mit einer Bestellung verbunden.
Die Tabellen „Products" und „Order Details" haben eine 1:n-Beziehung. Jedem Produkt können viele Werbebuchungen zugeordnet sein, aber jede Werbebuchung bezieht sich nur auf ein Produkt.
In der Tabelle Bestelldetails können Sie alle Produkte einer bestimmten Bestellung ermitteln. Sie können auch alle Bestellungen für ein bestimmtes Produkt ermitteln.
Nach dem Einbinden der Tabelle „Bestelldetails" könnte die Liste der Tabellen und Felder etwa so aussehen:
Erstellen einer Eins-zu-Eins-Beziehung
Eine andere Art von Beziehung ist die Eins-zu-eins-Beziehung. Angenommen, Sie müssen einige spezielle ergänzende Produktinformationen aufzeichnen, die Sie selten benötigen oder die nur für wenige Produkte gelten. Da Sie die Informationen nicht oft benötigen und weil das Speichern der Informationen in der Products-Tabelle zu leerem Platz für jedes Produkt führen würde, auf das sie nicht zutreffen, platzieren Sie sie in einer separaten Tabelle. Wie bei der Products-Tabelle verwenden Sie die ProductID als Primärschlüssel. Die Beziehung zwischen dieser Zusatztabelle und der Produkttabelle ist eine Eins-zu-Eins-Beziehung. Für jeden Datensatz in der Produkttabelle existiert ein einziger passender Datensatz in der Ergänzungstabelle. Wenn Sie eine solche Beziehung identifizieren, müssen beide Tabellen ein gemeinsames Feld verwenden.
Wenn Sie die Notwendigkeit einer Eins-zu-eins-Beziehung in Ihrer Datenbank erkennen, überlegen Sie, ob Sie die Informationen aus den beiden Tabellen in einer Tabelle zusammenfassen können. Wenn Sie dies aus irgendeinem Grund nicht tun möchten, vielleicht weil es zu viel Leerraum führen würde, zeigt die folgende Liste, wie Sie die Beziehung in Ihrem Design darstellen würden:
Wenn die beiden Tabellen dasselbe Thema haben, können Sie die Beziehung wahrscheinlich einrichten, indem Sie in beiden Tabellen denselben Primärschlüssel verwenden.
Wenn die beiden Tabellen unterschiedliche Subjekte mit unterschiedlichen Primärschlüsseln haben, wählen Sie eine der Tabellen (jede) aus und fügen ihren Primärschlüssel als Fremdschlüssel in die andere Tabelle ein.
Durch die Bestimmung der Beziehungen zwischen Tabellen können Sie sicherstellen, dass Sie über die richtigen Tabellen und Spalten verfügen. Wenn eine 1:1- oder 1:n-Beziehung besteht, müssen die beteiligten Tabellen eine oder mehrere gemeinsame Spalten verwenden. Wenn eine Viele-zu-Viele-Beziehung besteht, wird eine dritte Tabelle benötigt, um die Beziehung darzustellen.
Verfeinerung des Designs
Sobald Sie über die benötigten Tabellen, Felder und Beziehungen verfügen, sollten Sie Ihre Tabellen erstellen und mit Beispieldaten füllen und versuchen, mit den Informationen zu arbeiten: Abfragen erstellen, neue Datensätze hinzufügen und so weiter. Dadurch können potenzielle Probleme hervorgehoben werden – Sie müssen beispielsweise möglicherweise eine Spalte hinzufügen, die Sie während der Entwurfsphase vergessen haben, einzufügen, oder Sie haben möglicherweise eine Tabelle, die Sie in zwei Tabellen aufteilen sollten, um Duplikate zu vermeiden.
Sehen Sie, ob Sie die Datenbank verwenden können, um die gewünschten Antworten zu erhalten. Erstellen Sie grobe Entwürfe Ihrer Formulare und Berichte und prüfen Sie, ob sie die erwarteten Daten enthalten. Suchen Sie nach unnötigen Duplizierungen von Daten und ändern Sie, wenn Sie welche finden, Ihr Design, um sie zu beseitigen.
Wenn Sie Ihre anfängliche Datenbank ausprobieren, werden Sie wahrscheinlich Raum für Verbesserungen entdecken. Hier sind ein paar Dinge, die Sie überprüfen sollten:
Haben Sie Spalten vergessen? Wenn ja, gehören die Informationen in die bestehenden Tabellen? Wenn es sich um Informationen zu etwas anderem handelt, müssen Sie möglicherweise eine weitere Tabelle erstellen. Erstellen Sie eine Spalte für jedes Informationselement, das Sie nachverfolgen müssen. Wenn die Informationen nicht aus anderen Spalten berechnet werden können, benötigen Sie wahrscheinlich eine neue Spalte dafür.
Sind irgendwelche Spalten unnötig, weil sie aus vorhandenen Feldern berechnet werden können? Wenn ein Informationselement aus anderen vorhandenen Spalten berechnet werden kann – beispielsweise ein ermäßigter Preis, der aus dem Einzelhandelspreis berechnet wird – ist es normalerweise besser, genau das zu tun und das Erstellen einer neuen Spalte zu vermeiden.
Geben Sie wiederholt doppelte Informationen in eine Ihrer Tabellen ein? Wenn dies der Fall ist, müssen Sie die Tabelle wahrscheinlich in zwei Tabellen aufteilen, die eine Eins-zu-Viele-Beziehung haben.
Haben Sie Tabellen mit vielen Feldern, einer begrenzten Anzahl von Datensätzen und vielen leeren Feldern in einzelnen Datensätzen? Wenn ja, denken Sie darüber nach, die Tabelle so umzugestalten, dass sie weniger Felder und mehr Datensätze enthält.
Wurde jedes Informationselement in seine kleinsten nützlichen Teile zerlegt? Wenn Sie ein Informationselement melden, sortieren, suchen oder berechnen müssen, platzieren Sie dieses Element in einer eigenen Spalte.
Enthält jede Spalte eine Tatsache über das Thema der Tabelle? Wenn eine Spalte keine Informationen zum Thema der Tabelle enthält, gehört sie in eine andere Tabelle.
Werden alle Beziehungen zwischen Tabellen dargestellt, entweder durch gemeinsame Felder oder durch eine dritte Tabelle? 1:1- und 1:n-Beziehungen erfordern gemeinsame Spalten. Viele-zu-viele-Beziehungen erfordern eine dritte Tabelle.
Verfeinern der Produkttabelle
Angenommen, jedes Produkt in der Produktverkaufsdatenbank fällt unter eine allgemeine Kategorie, wie z. B. Getränke, Gewürze oder Meeresfrüchte. Die Tabelle Produkte könnte ein Feld enthalten, das die Kategorie jedes Produkts anzeigt.
Angenommen, Sie entscheiden sich, nachdem Sie das Design der Datenbank untersucht und verfeinert haben, eine Beschreibung der Kategorie zusammen mit ihrem Namen zu speichern. Wenn Sie der Tabelle „Produkte" ein Feld „Kategoriebeschreibung" hinzufügen, müssen Sie jede Kategoriebeschreibung für jedes Produkt wiederholen, das unter die Kategorie fällt – das ist keine gute Lösung.
Eine bessere Lösung besteht darin, Kategorien zu einem neuen Thema zu machen, das von der Datenbank verfolgt werden kann, mit einer eigenen Tabelle und einem eigenen Primärschlüssel. Anschließend können Sie den Primärschlüssel aus der Tabelle „Kategorien" als Fremdschlüssel zur Tabelle „Produkte" hinzufügen.
Die Tabellen „Kategorien" und „Produkte" haben eine Eins-zu-Viele-Beziehung: Eine Kategorie kann mehr als ein Produkt enthalten, aber ein Produkt kann nur zu einer Kategorie gehören.
Wenn Sie Ihre Tabellenstrukturen überprüfen, achten Sie auf sich wiederholende Gruppen. Stellen Sie sich beispielsweise eine Tabelle vor, die die folgenden Spalten enthält:
Produkt ID
Name
Produkt-ID1
Name1
Produkt-ID2
Name2
Produkt-ID3
Name3
Hier ist jedes Produkt eine sich wiederholende Gruppe von Spalten, die sich von den anderen nur durch das Hinzufügen einer Zahl am Ende des Spaltennamens unterscheidet. Wenn Sie auf diese Weise nummerierte Spalten sehen, sollten Sie Ihr Design überdenken.
Ein solches Design hat mehrere Mängel. Zunächst einmal zwingt es Sie dazu, die Anzahl der Produkte nach oben zu begrenzen. Sobald Sie diese Grenze überschreiten, müssen Sie der Tabellenstruktur eine neue Spaltengruppe hinzufügen, was eine große administrative Aufgabe darstellt.
Ein weiteres Problem besteht darin, dass diejenigen Lieferanten, die weniger als die maximale Anzahl von Produkten haben, etwas Platz verschwenden, da die zusätzlichen Spalten leer sind. Der schwerwiegendste Fehler bei einem solchen Design besteht darin, dass es viele Aufgaben erschwert, z. B. das Sortieren oder Indizieren der Tabelle nach Produkt-ID oder Name.
Wann immer Sie sich wiederholende Gruppen sehen, überprüfen Sie das Design genau und achten Sie darauf, den Tisch in zwei Teile zu teilen. Im obigen Beispiel ist es besser, zwei Tabellen zu verwenden, eine für Lieferanten und eine für Produkte, die durch die Lieferanten-ID verknüpft sind.
Anwendung der Normalisierungsregeln
Sie können die Datennormalisierungsregeln (manchmal auch nur als Normalisierungsregeln bezeichnet) als nächsten Schritt in Ihrem Design anwenden. Sie verwenden diese Regeln, um zu sehen, ob Ihre Tabellen richtig strukturiert sind. Das Anwenden der Regeln auf Ihr Datenbankdesign wird als Normalisieren der Datenbank oder einfach als Normalisierung bezeichnet.
Die Normalisierung ist am nützlichsten, nachdem Sie alle Informationen dargestellt haben und zu einem vorläufigen Entwurf gelangt sind. Die Idee ist, Ihnen dabei zu helfen sicherzustellen, dass Sie Ihre Informationselemente in die entsprechenden Tabellen eingeteilt haben. Was die Normalisierung nicht leisten kann, ist sicherzustellen, dass Sie von Anfang an alle korrekten Datenelemente haben.
You apply the rules in succession, at each step ensuring that your design arrives at one of what is known as the "normal forms." Five normal forms are widely accepted — the first normal form through the fifth normal form. This article expands on the first three, because they are all that is required for the majority of database designs.
First normal form
First normal form states that at every row and column intersection in the table there, exists a single value, and never a list of values. For example, you cannot have a field named Price in which you place more than one Price. If you think of each intersection of rows and columns as a cell, each cell can hold only one value.
Second normal form
Second normal form requires that each non-key column be fully dependent on the entire primary key, not on just part of the key. This rule applies when you have a primary key that consists of more than one column. For example, suppose you have a table containing the following columns, where Order ID and Product ID form the primary key:
Order ID (primary key)
Product ID (primary key)
Product Name
This design violates second normal form, because Product Name is dependent on Product ID, but not on Order ID, so it is not dependent on the entire primary key. You must remove Product Name from the table. It belongs in a different table (Products).
Third normal form
Third normal form requires that not only every non-key column be dependent on the entire primary key, but that non-key columns be independent of each other.
Another way of saying this is that each non-key column must be dependent on the primary key and nothing but the primary key. For example, suppose you have a table containing the following columns:
ProductID (primary key)
Name
SRP
Rabatt
Assume that Discount depends on the suggested retail price (SRP). This table violates third normal form because a non-key column, Discount, depends on another non-key column, SRP. Column independence means that you should be able to change any non-key column without affecting any other column. If you change a value in the SRP field, the Discount would change accordingly, thus violating that rule. In this case Discount should be moved to another table that is keyed on SRP.
No comments:
Post a Comment