Was ist eine 1:n-Beziehung in einer Datenbank? Eine Erklärung mit Beispielen

Eins-zu-viele-Beziehungen sind eine der häufigsten Datenbankbeziehungen. Wenn Sie lernen möchten, wann und wie 1:n-Beziehungen verwendet werden, ist dieser Artikel ein guter Ausgangspunkt.

Sie werden sicherlich Eins-zu-Viele-Beziehungen verwenden, um Informationen in jeder relationalen Datenbank zu speichern, egal ob Sie Software auf Unternehmensebene entwerfen oder nur eine einfache Datenbank erstellen, um die Briefmarkensammlung Ihres Onkels zu verfolgen.

Eine kurze Einführung in das relationale Modell

Relationale Datenbanken sind eine Kernkomponente jeder modernen Transaktionsanwendung. Das relationale Modell besteht aus Tabellen (in Zeilen und Spalten organisierte Daten), die mindestens einen eindeutigen Schlüssel haben, der jede Zeile identifiziert. Jede Tabelle repräsentiert eine Entität. Dies wird im folgenden Beispiel gezeigt, einer sehr einfachen Version einer Tabelle, die Kundenaufträge darstellt:

Das obige Diagramm, das ich online mit Vertabelo erstellt habe, hat eine einzige Tabelle. Jede Zeile in der Tabelle stellt eine Bestellung dar und jede Spalte (auch bekannt als Attribut ) stellt jede einzelne Information dar, die in einer Bestellung enthalten ist.

Für diejenigen, die mit dem Vertabelo-Designtool noch nicht vertraut sind, ist der Artikel What Are the Symbols Used in ER Diagrams? erklärt die verwendeten Symbole und Konventionen. Vielleicht möchten Sie auch mehr über relationale Modelle und Datenbanken erfahren, indem Sie unseren Kurs zur Datenbankmodellierung verwenden.

Was sind Beziehungen und warum brauchen wir sie?

Wenn wir uns die im vorherigen Beispiel verwendete Tabelle genauer ansehen, werden wir feststellen, dass sie nicht wirklich eine vollständige Bestellung darstellt. Es enthält nicht alle Informationen, die Sie erwarten würden. Sie werden feststellen, dass es keine Daten über den Kunden enthält, der die Bestellung aufgegeben hat, noch etwas über die bestellten Produkte oder Dienstleistungen.

Was sollten wir tun, um dieses Design zum Speichern von Bestelldaten zu vervollständigen? Sollten wir der Bestellung Kunden- und Produktinformationen hinzufügen Tisch? Dazu müssten neue Spalten (Attribute) für Kundennamen, Steueridentifikationsnummern, Adressen usw. hinzugefügt werden, wie unten gezeigt:

Wenn wir das tun, werden wir bald auf Probleme stoßen. Die meisten Kunden geben mehr als eine Bestellung auf, daher speichert dieses System Kundeninformationen viele Male, einmal für jede Bestellung jedes Kunden. Das scheint kein kluger Schachzug zu sein.

Was passiert außerdem, wenn ein Kunde seine Telefonnummer ändert? Wenn jemand den Kunden anrufen muss, findet er möglicherweise die alte Nummer auf früheren Bestellungen – es sei denn, jemand aktualisiert Hunderte (oder sogar Tausende) bestehender Bestellungen mit den neuen Informationen. Und das Gleiche gilt für jede andere Änderung.

Ein relationales Modell erfordert, dass wir jede Entität als separate Tabelle definieren und Beziehungen zwischen ihnen herstellen. Alle Informationen in einer einzigen Tabelle zu speichern, funktioniert einfach nicht.

Es gibt verschiedene Arten von Beziehungen zwischen Tabellen, aber die wahrscheinlich häufigste ist die Eins-zu-Viele-Beziehung, die oft als 1:N geschrieben wird. Diese Art von Beziehung bedeutet, dass eine Zeile in einer Tabelle (normalerweise als übergeordnete Tabelle bezeichnet) eine Beziehung zu vielen Zeilen in einer anderen Tabelle (normalerweise als untergeordnete Tabelle bezeichnet) haben kann. Einige gängige Beispiele für 1:n-Beziehungen sind:

• Ein Autohersteller stellt viele verschiedene Modelle her, aber ein bestimmtes Automodell wird nur von einem einzigen Autohersteller gebaut.
• Ein Kunde kann mehrere Käufe tätigen, aber jeder Kauf wird von einem einzelnen Kunden getätigt.
• Ein Unternehmen kann viele Telefonnummern haben, aber eine Telefonnummer gehört nur einem Unternehmen.

Es gibt auch andere Arten von Beziehungen zwischen Tabellen; Wenn Sie mehr darüber erfahren möchten, lesen Sie diesen Artikel über viele-zu-viele-Beziehungen.

Zurück zu unserem ursprünglichen Bestellbeispiel, dem Customer table wäre die übergeordnete Tabelle und die Order Tisch das Kind; Ein Kunde kann viele Bestellungen haben, während eine Bestellung zu einem einzigen Kunden gehören kann.

Bitte beachten Sie, dass die Eins-zu-Viele-Definition ermöglicht, dass eine Zeile in der übergeordneten Tabelle mit vielen Zeilen in jeder untergeordneten Tabelle verknüpft wird, dies jedoch nicht erforderlich ist. Tatsächlich erlaubt das Design einem Kunden, null Bestellungen (d. h. ein neuer Kunde, der noch nicht seinen ersten Kauf getätigt hat), eine Bestellung (ein relativ neuer Kunde, der einen einzigen Kauf getätigt hat) oder viele Bestellungen (ein Stammkunde) zu haben /P>

Eins-zu-Viele-Beziehungen in einem ER-Diagramm anzeigen

Werfen wir einen Blick auf ein vollständigeres Beispiel eines einfachen Kundenbestellsystems, das ein ER-Diagramm (oder Entity Relationship) verwendet. (Wenn Sie mehr über diese Diagramme erfahren möchten, ist Vertabelo Features:Logical Diagrams ein guter Ausgangspunkt.) Hier ist das Modell:

Dies ist ein realistischeres Design. Sie werden feststellen, dass es neue Entitäten (Tabellen) im Diagramm gibt, das jetzt die Tabellen Customer enthält , Order , Order Detail und Product . Das Wichtigste, was Sie bemerken, ist jedoch, dass es jetzt Beziehungen gibt zwischen den Tischen .

In einem Datenbankmodell werden Beziehungen durch Linien dargestellt, die zwei Entitäten verbinden. Die Eigenschaften dieser Beziehungen werden durch verschiedene Konnektoren repräsentiert:

• Wenn es eine einzelne vertikale Linie gibt, hat die Entität, die diesem Verbinder am nächsten liegt, nur eine Zeile, die von der Beziehung betroffen ist. Es ist das „Eins“ in Eins-zu-Vielen.
• Wenn es einen mehrzeiligen Verbinder gibt, der wie ein Krähenfuß aussieht, hat die Entität, die diesem Verbinder am nächsten liegt, mehrere Zeilen, die von der Beziehung betroffen sind; es sind die „vielen“.

Wenn man sich das Bild ansieht und die Notation kennt, ist es einfach zu verstehen, dass das Diagramm jeden Order definiert kann viele Order Detail enthalten und dass jedes Order Detail gehört zu einer einzigen Order .

Eine 1:n-Beziehung zwischen Tabellen implementieren

Um eine 1:n-Beziehung zwischen zwei Tabellen zu definieren, muss die untergeordnete Tabelle auf eine Zeile in der übergeordneten Tabelle verweisen. Die zur Definition erforderlichen Schritte sind:

1. Fügen Sie der untergeordneten Tabelle eine Spalte hinzu, die den Wert der primären Kennung speichert. (Tatsächlich erlauben die meisten Datenbank-Engines jeden eindeutigen Schlüssel aus der übergeordneten Tabelle, nicht nur den Primärschlüssel.) Die Spalte kann abhängig von Ihren Geschäftsanforderungen als obligatorisch definiert werden; Trotzdem werden normalerweise Fremdschlüsselspalten erstellt

Hinweis: Es empfiehlt sich, den Namen der referenzierenden Spalten so zu belassen wie in der referenzierten (übergeordneten) Tabelle. Dies macht es noch einfacher, die Beziehung zu verstehen.

2. Fügen Sie einen Fremdschlüssel hinzu Einschränkung für die untergeordnete Tabelle. Dies zeigt an, dass jeder in dieser neuen Spalte gespeicherte Wert auf eine Zeile in der übergeordneten Tabelle verweist.

Fremdschlüsseleinschränkungen sind eine Funktion, die in relationalen Datenbanken verfügbar ist und Folgendes erzwingt:

1. Wenn Sie der untergeordneten Tabelle eine Zeile hinzufügen, muss der Wert der referenzierenden Spalte mit einem (und nur einem) Wert in der übergeordneten Tabelle übereinstimmen. (Deshalb muss auf eine Spalte oder einen Satz von Spalten verwiesen werden, die einen Primärschlüssel oder eindeutigen Schlüssel bilden).
2. Wenn jemand versucht, eine Zeile aus der übergeordneten Tabelle zu löschen oder versucht, die Werte des eindeutigen/primären Schlüssels zu ändern, der als Referenz und verwendet wird es eine untergeordnete Tabelle gibt, die auf diese Zeile verweist, schlägt die Operation fehl.

Diese beiden Funktionen stellen sicher, dass die Datenbank ihre Integrität behält. Es besteht keine Möglichkeit, Bestellungen zu erstellen, die auf einen nicht vorhandenen Kunden verweisen, oder einen Kunden zu löschen, der bereits Bestellungen hat.

Erstellen eines Fremdschlüssels

Die Fremdschlüsselsyntax hängt normalerweise von der Zieldatenbank-Engine ab. Sobald Sie Ihr logisches Modell definiert haben, können Sie die Funktion „Physisches Modell generieren…“ in logischen Diagrammen von Vertabelo verwenden, um Ihr (datenbankunabhängiges) Modell in ein physisches Modell umzuwandeln, das zu Ihrem Datenbankanbieter passt. Vertabelo generiert auch das erforderliche SQL-Skript, mit dem Sie die Tabellen und Beziehungen in Ihrer Zieldatenbank erstellen können.

Einige praktische Beispiele für 1:N-Beziehungen

Sehen wir uns nun einige Beispiele für reale 1:n-Beziehungen an.

Eins-zu-Viele-Beziehung mit Primärschlüsseln

Dies ist wahrscheinlich das häufigste Szenario beim Definieren einer 1:n-Beziehung. Die untergeordnete Tabelle verwendet den Primärschlüsselwert der übergeordneten Tabelle, um die Beziehung herzustellen.

Dieses Beispiel beschreibt einen einfachen Online-Streaming-Dienst. Sehen wir uns an, was in den einzelnen Tabellen gespeichert ist und wie sie sich auf die anderen Tabellen in unserem Modell beziehen:

1. Jeder ServiceType definiert, wie sich ein Konto „verhält“ (z. B. wie viele Benutzer sich gleichzeitig mit dem System verbinden können, wenn für das Konto Full HD aktiviert ist usw.). Es hat eine Beziehung zu anderen Entitäten:
   • Eine Eins-zu-Viele-Beziehung mit Account , was bedeutet, dass jeder Diensttyp viele Konten dieses Typs haben kann.
2. Jedes Account speichert Informationen über einen Kunden. Es hat zwei direkte Beziehungen zu anderen Entitäten:
   • Jedes Konto gehört zu einem einzigen ServiceType , wie oben erklärt.
   • Diese Tabelle hat eine 1:n-Beziehung mit dem Profile Tabelle, was bedeutet, dass mehr als ein Benutzer sich mit demselben Konto mit unserem System verbinden kann.
3. Jedes Profile repräsentiert einen Benutzer in unserem System. Es hat zwei Beziehungen zu anderen Entitäten:
   • Jedes Profil gehört zu einem einzigen Account . Dadurch können alle Familienmitglieder (oder vielleicht eine Gruppe von Freunden) dasselbe Konto teilen, während jedes seine eigenen persönlichen Attribute hat (z. B. einen Profilnamen).
   • Jedes Profil hat einen einzigartigen Avatar .
4. Jeder Avatar ist ein Bild, mit dem wir jeden Kontobenutzer schnell identifizieren können. Es hat eine Beziehung zu einer anderen Entität:
   • Eine Eins-zu-Viele-Beziehung mit Profile , was bedeutet, dass ein einzelner Avatar Profilen auf verschiedenen Konten zugewiesen werden kann.

Eins-zu-Viele-Beziehungen mit natürlichen oder eindeutigen Ersatzschlüsseln

Die Verwendung von Ersatz-Primärschlüsseln ist eine weithin akzeptierte Methode zur Modellierung von Tabellen. (Ersatz-Primärschlüssel werden von der Datenbank generiert und haben keinen tatsächlichen geschäftlichen Wert.) Diese Methode erzeugt Schlüssel, die einfacher zu verwenden sind, und fügt eine gewisse Flexibilität hinzu, wenn Änderungen erforderlich sind.

Es gibt jedoch Situationen – z.B. wenn wir mit externen Systemen interagieren müssen – wo die Verwendung eines in unserer Datenbank generierten Schlüssels ein schlechter Ansatz ist. Für diese Szenarien ist es normalerweise besser, natürliche Schlüssel zu verwenden, bei denen es sich um eindeutige Werte handelt, die Teil der zu speichernden Entität sind und nicht automatisch von unserer Datenbank generiert werden.

Das folgende Beispiel stellt ein grundlegendes Datenmodell einer Organisation dar, die Fahrzeuge (d. h. Marke, Modell, Farbe und Baujahr des Autos), ihre Besitzer und alle damit verbundenen Verkehrsverstöße verfolgt. Bei der Definition haben wir Ersatz-Primärschlüssel verwendet, um die Beziehungen zwischen den Fahrzeugen und Marken, Modellen und Besitzern herzustellen, da all diese Informationen intern von unserem System verarbeitet werden.

Wie kann in diesem System ein Polizist in einer anderen Stadt ein falsch geparktes Auto mit unserem Fahrzeug-Primärschlüssel (VehicleID )? Am geparkten Fahrzeug sind solche Informationen natürlich nicht vorhanden, aber das Nummernschild ist vorhanden. Das bedeutet, dass der einfachste Weg, Informationen von einer externen Quelle (in diesem Beispiel jede Polizeidienststelle im Land) zu erhalten und zuzuordnen, darin besteht, einen natürlichen eindeutigen Schlüssel anstelle eines Ersatz-Primärschlüssels zu verwenden.

Die physische Implementierung dieses logischen Diagramms für SQL Server ist hier verfügbar:

Eins-zu-Viele-Beziehungen auf derselben Tabelle

Die vorherigen Beispiele konzentrierten sich auf Beziehungen zwischen zwei oder mehr Tabellen, aber es gibt auch Szenarien, in denen die Beziehung zwischen Zeilen derselben Tabelle auftritt. Diese Art von 1:n-Beziehung wird auch hierarchische Beziehung genannt; Es wird in vielen Systemen verwendet, um baumartige Strukturen darzustellen, z. B. ein Organigramm, ein Hauptbuchkonto oder ein Produkt und seine Bestandteile.

Wenn Sie diese Art von Struktur zum ersten Mal erstellen müssen, werden Sie versucht sein, eine Tabelle für jede der Ebenen in Ihrer Hierarchie zu definieren, wie im folgenden Diagramm gezeigt:

Dieser Ansatz ist mit vielen Problemen verbunden:

• Alle Tabellen sind nahezu identisch und speichern identische Informationen.
• Wenn Ihre Organisation eine neue Ebene hinzufügt, müssen Sie das Datenmodell ändern und eine neue Tabelle, neue Fremdschlüssel usw. hinzufügen.
• Wenn ein Mitarbeiter befördert wird, müssen Sie ihn aus einer Tabelle löschen und in eine andere einfügen.

Daher ist der beste Weg, diese Art von Struktur zu modellieren, die Verwendung einer einzelnen Tabelle, die auf sich selbst verweist, wie in diesem Diagramm gezeigt:

Hier sehen wir einen einzelnen Employee Tabelle und eine Spalte namens EmployeeID_Manager . Diese Spalte verweist auf einen anderen Mitarbeiter in derselben Organisation, der der Vorgesetzte/Manager des aktuellen Mitarbeiters ist.

Ich habe den _Manager hinzugefügt Suffix, um zwischen der ID der aktuellen Zeile und der ID des Managers zu unterscheiden. (Wir könnten ManagerID verwenden stattdessen, aber ich ziehe es vor, den ursprünglichen Namen der referenzierten Spalte beizubehalten und in den Fällen, in denen sich beide in derselben Tabelle befinden, ein Suffix hinzuzufügen, das die Rolle erklärt, die sie tatsächlich hat).

Das Verständnis hierarchischer Beziehungen ist komplexer als andere 1:n-Beziehungen. Aber wenn Sie die Tabelle vergessen, in der alle Informationen gespeichert sind, und sich vorstellen, dass es tatsächlich verschiedene Tabellen gibt, von denen jede eine Ebene in der Hierarchie darstellt, ist es etwas einfacher, sich das vorzustellen. Stellen Sie sich vor, Sie stellen die Beziehung zwischen zwei Entitäten her und kombinieren sie dann zu einer Entität.

Was kommt als Nächstes?

Die bereitgestellten Beispiele helfen Ihnen, verschiedene Szenarien zu identifizieren, die eine 1:n-Beziehung erfordern. Sie können mit dem Entwurf Ihrer eigenen Datenbankstruktur beginnen, indem Sie den Vertabelo Database Modeler verwenden, ein webbasiertes Tool, mit dem Sie nicht nur ein logisches Modell generieren, sondern auch eine physische Version davon für den von Ihnen benötigten Datenbankanbieter erstellen können.

Jetzt sind Sie an der Reihe – verwenden Sie den Kommentarbereich, um uns Ihre Gedanken zu diesem Artikel mitzuteilen, zusätzliche Fragen zu stellen oder Ihre Erfahrungen mit der Datenbankmodellierung mitzuteilen.