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

Beziehungen

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Mehrere Tabellen einer Datenbank können über einen vorhandenen Primärschlüssel miteinander verknüpft werden. Dadurch besteht die Möglichkeit, Daten aus verschiedenen Tabellen zusammenzufassen.

Transkript

Während Sie bei jeder Datenbank mit der Definition Ihrer Tabellen beginnen, ist ein nächster lebenswichtiger Schritt, die Fähigkeit, die Beziehungen von der einen Tabelle zu einer anderen hinzuzufügen, weil ein großer Teil Ihrer Daten natürlich irgendwie verknüpft ist. Versuchen Sie dabei, nicht willkürliche Beziehungen zu erfinden, die nicht existieren, sondern beschreiben Sie, was bereits da ist. So könnten Sie zuerst eine eigenständige Kundentabelle oder eine Tabelle für Bestellungen oder eine Produkttabelle anlegen. Doch Bestellungen werden von einem Kunden ausgelöst und zwar als Bestellung für spezifische Produkte. Die Informationen über eine Bestellung unterscheiden sich von Informationen über einen Kunden und doch sind sie miteinander irgendwie verknüpft. Deshalb müssen wir formal die Beziehung zwischen unseren Tabellen beschreiben und auf welche Art und Weise wir Beziehungen beschreiben, das beruht auf unseren Schlüsseln. Gehen wir mal ein Bespiel durch. Ich habe hier eine Tabelle "Kunden" und sie hat am Anfang die Spalte "CustomerID". In den meisten Fällen schreibt man auch im Deutschen die Spaltennamen auf Englisch. Diese Spalte CustomerID, die ist eingerichtet worden, um automatisch eine eindeutige Nummer für jeden Kunden zu generieren, wenn er in die Datenbank aufgenommen wird. Das hier ist unser sogenannter Primärschlüssel oder "Primary Key". Einer der Vorzüge diesen Schlüssel zu haben, ist, dass wir ihn auch an anderer Stelle wiederverwenden können. Ich habe also eine andere einfache Tabelle namens "Order" oder zu Deutsch "Bestellungen". Hier stellt jede Zeile eine Bestellung dar. Deshalb hat auch sie ihren eigenen Primärschlüssel, in dem Beispiel heißt das Ganze "OrderID", der ebenfalls als automatische Zahl generiert wird. Nun stelle ich mir vor, dass wir solch ein einfaches Geschäft haben, dass wir nur ein einziges Produkt verkaufen. Deshalb brauche ich nur noch die Bestellmenge zu kennen und den Gesamtbetrag. Doch jede Bestellung ist eine Bestellung für einen bestimmten Kunden. Und um eine Bestellung zu verarbeiten, müssen Sie wissen, auf wen sie sich bezieht. Wie kommen wir nun zu diesen Daten? Wir können Spalten an die Tabelle "Order" anfügen und alle relevanten Daten von der Tabelle "Costumer", der Kundentabelle, in diese Tabelle der Bestellungen, "Order" in unserem Beispiel, kopieren, wenn eine Bestellung eingeht. Doch würde das erstens die Daten duplizieren, was man im Allgemeinen vermeiden sollte und zweitens gibt es dafür keinen Grund. Stattdessen fügen wir eine Spalte "CustomerID" in unsere Tabelle für die Bestellungen ein. Wir nehmen den Schlüssel auf eine Zeile in der Customer-Tabelle und verwenden ihn erneut in der Order-Tabelle, um die Verbindung zwischen den beiden zu beschreiben. Das tun wir aber nicht einfach so. Praktisch weisen wir das Datenbank-Management-System an, dass dies eine formelle Beziehung zwischen diesen Tabellen ist, sodass jede Bestellung jetzt über eine CustomerID verfügt. Doch während die Tabelle "Customer" eine CustomerID enthält, die eindeutig sein muss, braucht diese Spalte in der Order-Tabelle nicht eindeutig zu sein; dieselbe CustomerID kann zwei-, drei- oder auch ein dutzendmal vorkommen. In diesem Fall tritt die 367 zweimal auf. Das heißt, mehrere Bestellungen stammen vom selben Kunden. Weil hier diese Nummer nicht eindeutig eine Zeile in der Order-Tabelle identifiziert, haben wir dafür eine OrderID. In der Customer-Tabelle ist CustomerID also unser Primärschlüssel, doch wenn er in der Bestellungstabelle verwendet wird, ist es nicht der Primärschlüssel, obwohl er immer noch ein Schlüssel ist. Man bezeichnet ihn als Fremdschlüssel und er ist nicht eindeutig. Diese Beziehung in der Datenbank zu definieren, hat den Vorteil, dass wir in beide Richtungen gehen können. Wir können in der Kundenzeile beginnen und dann diese CustomerID nehmen und alle Bestellungen für diesen Kunden zusammensuchen. Oder wir können von der Bestellzeile ausgehen, die CustomerID suchen und herausfinden, welcher Kunde mit dieser konkreten Bestellung verbunden ist. Eine derartige Beziehung ist als "Eins zu N" oder "Eins zu viele" definiert. Ein Kunde kann viele Bestellungen haben. In einem Datenbankdiagramm würde man dies auf unterschiedliche Art und Weise darstellen können. Manche Systeme verwenden das Krähenfußsymbol, um zu zeigen, wie die Beziehung verläuft. Bei anderen sehen Sie vielleicht das Eins-zu-Unendlichsymbol. Nun hat der eine Kunde viele Bestellungen, eine Kategorie hat viele Produkte, eine Abteilung hat viele Mitarbeiter, ein Klassenzimmer hat viele Studenten usw. Und derartige Beziehungen kommen recht häufig zwischen Ihren Tabellen vor. Die meisten Tabellen in gut konzipierten Datenbanken besitzen Beziehungen zu einer oder zu mehreren anderen Tabellen. Denken Sie aber daran, wenn Sie eine Eins-zu-viele-Beziehung in einer Datenbank beschreiben, dass [eine] Tabelle nicht unbedingt viele Zeilen haben muss. Ein Kunde muss nicht viele Bestellungen aufgegeben haben; es kann auch nur eine einzige Bestellung oder überhaupt gar keine Bestellung sein. Doch die internen Regeln der Datenbank unterstützen das Konzept, dass ein Kunde viele Bestellungen haben kann, eine Kategorie viele Produkte umfasst, eine Abteilung viele Mitarbeiter beschäftigt. in dieser Aussage trifft allerdings nicht zu, zumindest in einem fiktiven Unternehmen, das ich beschreibe. Während also jeder Kunde viele Bestellungen haben kann, ist jede Bestellung nur einem einzigen Kunden zugeordnet. Ich kann nicht sagen, dass eine Bestellung viele Kunden hat, das geht nicht. Eine Abteilung hat viele Mitarbeiter, doch ein Mitarbeiter gehört immer genau zu einer einzigen Abteilung. Ein Produkt ist nur einer Kategorie zugeordnet. Ich versuche hier, einfache Unternehmensbeispiele zu beschreiben, die zwar ein wenig banal sein können, aber leichter zu fassen sind. Wenn Ihre aktuellen Geschäftsregeln eine flexiblere Situation unterstützen, in der vielleicht eine Bestellung mehreren Kunden zugeordnet sein kann oder ein Mitarbeiter für mehrere Abteilungen gleichzeitig arbeitet, müssen Sie eine andere Art von Beziehung definieren; anstelle einer Eins-zu-viele-Beziehung eine Viele-zu-viele-Beziehung. Diese steht als nächstes auf der Tagesordnung.

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)
Datenbank planen
Liliane D.

Einfach Genial. Unkompliziert und so Verständlich! Vielen Dank und freundliche Grüsse

 

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!