Am 14. September 2017 haben wir eine überarbeitete Fassung unserer Datenschutzrichtlinie veröffentlicht. Wenn Sie video2brain.com weiterhin nutzen, erklären Sie sich mit diesem überarbeiteten Dokument einverstanden. Bitte lesen Sie es deshalb sorgfältig durch.

Grundlagen der Programmierung: Datenbanken

Viele-zu-viele-Beziehungen

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Eine Viele-zu-viele-Beziehung kann nicht über den Primärschlüssel abgewickelt werden. Hierfür muss eine Verknüpfungstabelle erstellt werden, welche ausschließlich die für die Beziehung relevanten Informationen enthält.

Transkript

Während die gebräuchlichste Beziehung zwischen zwei Tabellen in einer relationalen Datenbank eine Eins-zu-viele-Beziehung ist, kommt es durchaus vor, dass Sie eine Viele-zu-viele-Beziehung beschreiben müssen. Hier tauchen zwei Probleme auf: Problem Nummer eins: Ein zugegebenermaßen etwas kleineres Problem, Eins-zu-viele-Beziehungen sind leicht zu beschreiben, und allgegenwärtig. Dem gegenüber sind Viele-zu-viele Szenarios etwas verzwickter und sie sind nicht so offensichtlich zu entdecken. Problem Nummer zwei, ein schon größeres Problem. In den meisten relationalen Datenbankmanagementsystemen können Sie keine Viele-zu-viele-Beziehung direkt ausdrücken. Das hört sich danach an, als ob wir kurzen Prozess machen könnten, doch obwohl Sie keine direkte Viele-zu-viele-Beziehung erstellen können, gibt es einen indirekten Weg, und den beschreibe ich jetzt. Wie immer konzentrieren wir uns auf das Geschäftsproblem, und nicht die technische Realisierung. Nehmen wir also an, wir betreiben einen Verlag. Wir haben eine Tabelle "Author", mit einer Liste einiger Autoren und ihrer Namen, Kontaktdaten, Informationen und einen Primärschlüssel, in dem Fall ist es dann hier die Author-ID. Und wir haben eine Tabelle für die Bücher, mit der Liste der Buchtitel, die mit 'Book ID' ebenfalls einen eigenen Primärschlüssel besitzt. Auf den ersten Blick könnten wir sagen, die sieht so aus wie eine Eins-zu-viele-Beziehung. Wir könnten den Autor Nummer 447, Jordan Winters, nehmen, und sagen, wir wollen darstellen, dass dieser Autor die beiden Bücher, 1145, Designing Databases, und 1147, Pocket Guide to SQL, geschrieben hat. Und wir würden sagen, dass Robert mit der Nummer 446 das Buch 1146, SQL Light Made Simple geschrieben hat. Wenn dies also eine klassische Eins-zu-viele-Beziehung ist, das heißt, ein Autor mit mehreren Titeln, dann könnten wir dies realisieren, indem wir eine neue Spalte, Author ID, in die Tabelle 'Book' einfügen. Es wäre ein Fremdschlüssel für die Tabelle Autoren, oder Author. So weit, so gut. Doch hier liegt das Problem. Was passiert, wenn wir in einem Tag oder in einer Woche, oder in einem Monat erfahren, dass das Buch "Designing Databases" von zwei verschiedenen Autoren neu aufgelegt werden sollte? Auf dem bisher beschriebenen Weg können wir das nicht bewerkstelligen, weil unser Spalte 'Author ID' nur einen einzigen Fremdschlüssel speichern kann, entweder zum Autor 447 oder zum Autor 445, sodass ich momentan eine Eins-zu-viele-Beziehung unterstützen kann, aber eine Viele-zu-viele-Beziehung brauche. Ein Autor kann viele Bücher haben, aber auch ein Buch kann viele Autoren haben. Nun könnte man dies dadurch modellieren, dass man eine weitere Spalte in die Tabelle 'Book' einfügt. Man fügt eine zweite Author ID-Spalte ein, und lässt beispielsweise 445 auf einen anderen Autor zeigen. Allerdings ist das Hinzufügen neuer Spalten in die Tabellen in der beschriebenen Art und Weise das, was ich als Wiederholende Gruppen oder Wiederholende Spalten bezeichne. Man bringt einfach die gleichen Informationen noch einmal. Das ist ein schlechtes Konzept, und wird im Datenbankdesign definitiv nicht empfohlen. Also werfen wir diese Technik über Bord. Manche glauben nun, dass man einfach etwas trickst, man schafft sich eine schnelle Behelfslösung, indem man zwei Werte in dieser Author-ID-Spalte unterbringt. Vielleicht verwendet man durch Komma getrennte Werte, und quetscht eine andere Referenz hinein, sodass die Spalte Author ID nun auf zwei Autoren verweist, doch auch das ist eine Trickserei. Und wie das Hinzufügen einer neuen Spalte ist dies ebenso verpönt. Wie lösen wir das nun? In der Tat lösen wir dieses Problem, indem wir diese Author ID-Spalte gänzlich entsorgen. Praktisch kehren wir zunächst zurück zu zwei vollkommen getrennten Tabellen mit keiner offiziellen Referenz zwischen ihnen. Und um eine Viele-zu-viele-Beziehung zu erstellen, fügen wir eine weitere Tabelle hinzu, eine sogenannte Verknüpfungstabelle. Diese Tabelle hat nun allein den Zweck, die Tabellenautoren und Bücher miteinander zu verbinden, und in der Tat lautet der Name dieser Verknüpfungstabelle per Konvention Autoren-Bücher. Prinzipiell spielt es keine Rolle, w ie sie heißt, denn wir verwenden sie nur, um Zwei-eins-zuviele-Beziehungen einzurichten. Wir definieren also eine Eins-zu-viele-Beziehung von Author zu Author-Book. Für den einen Autor mit der Author-ID 445 ist das hier der Primärschlüssel, aber dort der Fremdschlüssel. Dort ist er nicht eindeutig, er kann in dieser Tabelle einmal, zweimal, dreimal, ein Dutzend mal existieren. Und damit können wir von Author zu Author-Book gehen, eine Book-ID suchen, und diese der Tabelle 'Book' zuordnen. Und wir können das ganze auch in der anderen Richtung tun. Wir können die Identität eines Buches wie Nummer 1145 zurück zur Verknüpfungstabelle verfolgen, in diesem Fall zu zwei Zeilen, und von dort zur Tabelle Author gehen. Suchen Sie die Author-ID, verfolgen Sie sie zurück zur Tabelle Author, wir drücken nun also eine Viele-zu-viele-Beziehung aus. Ein Autor kann viele Bücher haben, und ein Buch kann viele Autoren haben. Der einzige Grund für die Existenz dieser Tabelle in der Mitte ist es, die beiden anderen miteinander zu verknüpfen. In einer großen Datenbank haben Sie letztlich eine ganze Menge Eins-zu-viele-Beziehungen zwischen Ihren Tabellen, nur bei einigen davon ist es wirklich notwendig, eine Viele-zu-viele-Beziehung zu erstellen. Offiziell gibt es noch eine dritte Art, eine Eins-zu-eins-Beziehung, die zwar möglich, aber wenig gebräuchlich ist. Praktisch verweist eine Zeile in der einen Tabelle auf eine, und nur eine Zeile in einer anderen Tabelle. Man kann diese Tabellen genauso gut zusammenfassen. Das sind die offiziellen Arten von Beziehungen, was man manchmal auch als die Kardinalität dessen bezeichnet, wie Tabellen zueinander in Beziehung stehen. Eins-zu-viele, das ist sehr häufig, Viele-zu-viele, wie diese hier, das ist gelegentlich erforderlich, und Eins-zu-eins, und das ist überhaupt nicht üblich. Nun gibt es in einer großen Datenbank auch einige Tabellen ohne formelle Beziehung zueinander. Einige brauchen Sie nicht, und manche Leute betrachten dieses nicht als die vierte Art der Kardinalität, oder die vierte Art der Beziehung. Ich sehe das nicht so, aber vielleicht denken Sie ja anders drüber. Sicherlich muss man nicht jede Tabelle mit jeder anderen Tabelle verbinden, doch die meisten Tabellen sind letztlich doch wenigstens mit einer anderen verknüpft.

Grundlagen der Programmierung: Datenbanken

Fangen Sie ganz von vorne an und erfahren Sie alles über die Grundlagen zu Datenbanken und deren Einsatzzwecke, um danach eigene Lösungen und Anwendungen zu entwickeln.

3 Std. 6 min (39 Videos)
Derzeit sind keine Feedbacks vorhanden...
 

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!