Abhängigkeiten zwischen Tabellen in einer Datenbank

4.1 Einführung

Durch die Konvertierung der Datenbanktabellen in reguläre Tabellen können Sie nun die Beziehungen zwischen ihnen analysieren. Die Anzahl der Elemente, die zwischen zwei verwandten Tabellen interagieren, wird als Kardinalität bezeichnet. Mithilfe der Kardinalität können Sie steuern, wie effizient Sie Ihre Daten in Tabellen partitioniert haben.

Theoretisch können alle Entitäten Beziehungen zueinander pflegen, in der Praxis gibt es jedoch drei Arten von Beziehungen zwischen Entitäten:

• Eins zu eins
• Eins zu viele
• viel zu viel

4.2 Eins-zu-eins-Kommunikation

Wenn es für jede Instanz von Entität B nur eine Instanz von Entität A gibt, spricht man von einer Eins-zu-eins-Beziehung (oft als „1:1“ bezeichnet). In ER-Diagrammen wird eine solche Beziehung durch eine Linie mit einem kleinen Balken an jedem Ende angezeigt:

Eine 1:1-Beziehung bedeutet im Allgemeinen, dass die Daten der beiden Tabellen am besten zu einer einzigen kombiniert werden, es sei denn, Sie haben einen guten Grund, sie getrennt zu halten.

Unter bestimmten Umständen ist es jedoch sinnvoll, Tabellen mit 1:1-Beziehungen zu verwenden. Wenn Ihre Tabellen Felder mit optionalen Daten wie Beschreibungen enthalten und diese in vielen Fällen leer sind, ist es sinnvoll, alle Beschreibungen in eine separate Tabelle zu verschieben. Dadurch können Sie häufige Lücken beseitigen und die Effizienz Ihrer Datenbank steigern .

Um die Daten richtig zuzuordnen, müssen Sie dann in jede Tabelle mindestens eine identische Spalte einfügen (am besten wählen Sie hierfür einen Primärschlüssel).

4.3 Eins-zu-viele-Beziehung

Diese Art von Beziehung tritt auf, wenn ein Datensatz in einer Tabelle mit mehreren Entitäten in einer anderen Tabelle verknüpft ist. Beispielsweise könnte derselbe Kunde mehrere Bestellungen aufgeben oder ein Bibliotheksbesucher könnte bei einem Besuch mehrere Bücher ausleihen. Eins-zu-viele-Beziehungen (oder kurz 1:M) werden in einem Diagramm in Krähenfußschreibweise ausgedrückt, wie im folgenden Beispiel gezeigt:

Um beim Planen einer Datenbank eine 1:M-Beziehung anzuwenden, fügen Sie einfach den Primärschlüssel aus der „Eins“-Tabelle als Attribut zur „Viele“-Tabelle hinzu. Befindet sich der Primärschlüssel in einer anderen Tabelle, spricht man von einem „Fremdschlüssel“. Die „Eins“-Tabelle wird als übergeordnete Tabelle betrachtet, während die „Viele“-Tabelle als untergeordnete Tabelle betrachtet wird.

4.4 Viele-zu-viele-Beziehung

Wenn mehrere Entitäten in einer Tabelle mit mehreren Entitäten in einer anderen Tabelle verbunden werden können, wird davon ausgegangen, dass sie eine Viele-zu-Viele-Beziehung (oder M:M-Beziehung) haben. Eine solche Beziehung besteht beispielsweise zwischen Schülern und Klassen, da jeder Schüler mehrere verschiedene Klassen besuchen kann und dementsprechend viele Schüler zu jeder Klasse kommen können.

Im ER-Diagramm wird diese Art von Beziehung wie folgt dargestellt:

Leider ist es nicht möglich, eine solche Beziehung direkt in der Datenbank zu implementieren. Daher muss es in zwei Eins-zu-viele-Beziehungen aufgeteilt werden.

Dazu müssen Sie eine neue Entität zwischen den beiden Tabellen erstellen. Wenn eine M:M-Beziehung zwischen Verkäufen und Produkten hergestellt wird, kann die neue Einheit als „verkaufte Produkte“ bezeichnet werden, da sie den Inhalt jedes Verkaufs darstellt.

Mit „Verkaufte Ware“ und der Tabelle „Umsatz“ wird mit der Tabelle „Ware“ nach Typ 1:M verknüpft. In verschiedenen Modellen werden solche Zwischeneinheiten unterschiedlich bezeichnet – „Verbindungstabellen“, „assoziative Einheiten“ oder „Knotentabellen“.

Jeder Verknüpfungstabelleneintrag verbindet zwei verschiedene Entitäten benachbarter Tabellen (und kann auch zusätzliche Informationen enthalten). Eine Verknüpfungstabelle zwischen Schülern und Klassen könnte beispielsweise so aussehen:

4.5 Obligatorisch oder nicht?

Ein weiterer Ansatz zur Linkanalyse besteht darin, zu bestimmen, welche der verbundenen Entitäten eine Voraussetzung für das Vorhandensein einer anderen Entität ist. Die optionale Verbindungsseite ist mit einem Kreis auf dem Stamm gekennzeichnet.

Damit beispielsweise ein Staat einen eigenen Vertreter bei den Vereinten Nationen hat, muss er auf der Weltkarte existieren, aber die gegenteilige Aussage wäre falsch:

Zwei Entitäten können voneinander abhängig sein (das heißt, das eine kann nicht ohne das andere existieren).

Rekursive Links

Manchmal kann eine Tabelle auf sich selbst verweisen. Beispielsweise könnte eine Mitarbeitertabelle über das Attribut „Manager“ verfügen, das uns auf einen anderen Mitarbeiter in derselben Tabelle verweisen würde. Dies ist die rekursive Beziehung.

Zusätzliche Verbindungen

Links gelten als redundant, wenn sie mehr als einmal vorkommen. In der Regel kann eine davon gelöscht werden, ohne dass wichtige Informationen verloren gehen. Wenn beispielsweise die Entität „Schüler“ nicht nur direkt, sondern auch indirekt über „Klassen“ mit der Entität „Lehrer“ verbunden ist, ist es sinnvoll, die Beziehung zwischen den Entitäten „Schüler“ und „Lehrer“ zu entfernen. Begründet wird diese Entscheidung damit, dass eine Zuordnung von Schülern zu Lehrern nur über Klassen möglich sei.

4.6 Referenzielle Integrität von Daten

Bei der Änderung von Primär- und Fremdschlüsseln sollte man einen Aspekt wie die referenzielle Integrität der Daten beachten . Seine Hauptidee besteht darin, zwei Tabellen in einer Datenbank, die dieselben Daten speichern, konsistent zu halten.

Die Datenintegrität stellt ordnungsgemäß aufgebaute Beziehungen zwischen Tabellen mit korrekter Verknüpfung zwischen ihnen dar. In welchen Fällen kann die Datenintegrität verletzt werden:

• Löschanomalie . Tritt auf, wenn eine Zeile aus der Haupttabelle gelöscht wird. In diesem Fall verweist der Fremdschlüssel aus der abhängigen Tabelle weiterhin auf die gelöschte Zeile aus der Mastertabelle.
• Einfügungsanomalie . Tritt auf, wenn eine Zeile in eine abhängige Tabelle eingefügt wird. In diesem Fall stimmt der Fremdschlüssel aus der abhängigen Tabelle nicht mit dem Primärschlüssel einer der Zeilen aus der Mastertabelle überein.
• Update -Anomalie. Bei einer solchen Anomalie können mehrere Zeilen einer Tabelle Daten enthalten, die zum selben Objekt gehören. Wenn Sie die Daten in einer Zeile ändern, kann es zu Konflikten mit den Daten einer anderen Zeile kommen.

Anomalie beim Löschen

Um die Löschanomalie zu beheben, sollte der Fremdschlüssel auf eine von zwei Einschränkungen festgelegt werden:

Wenn eine Zeile aus einer abhängigen Tabelle unbedingt eine Zeile aus der Mastertabelle erfordert, wird der Fremdschlüssel auf Kaskadenlöschung gesetzt. Das heißt, wenn eine Zeile aus der Mastertabelle gelöscht wird, werden die zugehörigen Zeilen aus der abhängigen Tabelle gelöscht.

Wenn eine Zeile aus einer abhängigen Tabelle keine Beziehung zu einer Zeile aus der Haupttabelle zulässt (d. h. eine solche Beziehung ist optional), wird der Fremdschlüssel auf NULL gesetzt, wenn die zugehörige Zeile aus der Haupttabelle gelöscht wird. Die Fremdschlüsselspalte muss nullfähig sein.

Einfügungsanomalie

Um die Einfügeanomalie beim Hinzufügen zu einer abhängigen Datentabelle zu beheben, muss die Spalte, die den Fremdschlüssel darstellt, nullfähig sein. Wenn also das hinzugefügte Objekt keine Verbindung zur Haupttabelle hat, hat die Fremdschlüsselspalte einen NULL-Wert.

Anomalien aktualisieren

Um das Update-Anomalie-Problem zu lösen, wird die zuvor besprochene Normalisierung angewendet.