Tabellen verknüpfen

Um auch komplexere Abfragen durchführen zu können, insbesondere um über einen bestimmten Wert andere Werte ermitteln zu können, müssen Sie nun entsprechend zusammen gehörende Tabellen miteinander verknüpfen. Derzeit lässt sich beispielsweise nicht abbilden, welche Modelle zu einer Marke gehören, da Modelle und Marken sich in voneinander unabhängigen Tabellen befinden. Ein systematisches Durchsuchen der Tabelle Fahrzeuge würde für eine professionelle Anwendung nicht nur viel zu lange dauern, sondern zu einem unvollständigen Abfrage-Ergebnis führen, z.B. wenn kein Fahrzeug einer bestimmten Marke gelistet ist.

Eine Verknüpfung zwischen zusammen gehörenden Tabellen stellen Sie her, indem Sie eine Oberkategorie an die dazugehörige Unterkategorie anhängen, z.B. Marken an Modelle. Was Ober- und Unterkategorie ist, können Sie sehr leicht mit der Überprüfung folgender Aussagen herausfinden:

Da die erste Aussage zutrifft, ist die Marke die Oberkategorie, sodass die Tabelle Marken an die Tabelle Modelle angehängt wird. Die Verknüpfung erfolgt erneut mit Hilfe eines Schlüssels. Dazu müssen die Werte der Unterkategorie mit den dazugehörigen IDs der Oberkategorie erweitert werden. Dazu wird die Tabelle Modelle mit der Spalte Marken_ID erweitert und die IDs entsprechend übernommen.

Marken

clip0274

Modelle

clip0287

Hinweis: Da eine Marke viele Modelle haben kann, wird die Beziehung zwischen den Tabellen Marken und Modelle als 1:n Beziehung (1:viele) bezeichnet, während man bei den Beziehungen zwischen den Tabellen Fahrzeuge und Fahrzeuge_Extras, sowie Fahrzeuge_Extras und Extras, jeweils von einer n:m Beziehung (viele:viele) spricht .

Da Sie nun jederzeit über jedes Modell die jeweilige Marke ermitteln können, ist Spalte Marken in der Tabelle Fahrzeuge überflüssig und kann entfernt werden.

Welche Tabellen Sie miteinander verknüpfen hängt allein davon ab, welche Abfrage-Möglichkeiten Ihre Datenmodell bieten soll. Dabei sollten Sie genau analysieren, welche Auswirkungen Ihre Maßnahmen haben. Ein Ausgliedern bestimmter Daten kann beispielsweise in der Theorie korrekt sein, in der Praxis jedoch die Zugriffszeit unnötig verlängern oder einen unverhältnismäßig hohen Programmieraufwand nach sich ziehen. Wenn Sie beispielsweise ein Datum speichern, das Sie für die Darstellung im Formular jedes Mal in einzelne Zahlenwerte zerlegen müssen, um das Monat und das Jahr in einer Combobox darstellen zu können, dann ist es womöglich praktischer, Jahr und das Monat gleich als Zahlenwerte abzuspeichern. Das führt dazu, dass erfahrene Entwickler oftmals nicht nur Spalten in der Haupt-Tabelle belassen, die sie ebenso gut ausgliedern könnten, sondern unter bestimmten Umständen sogar Daten absichtlich redundant speichern. Denn über umso mehr Tabellen sich eine Abfrage erstreckt, desto länger und komplexer wird die Abfrage-Bedingungen (Join), die von der Datenbank verarbeitet werden muss und die durchschnittliche Zugriffszeit erhöht.

Hinweis: Bevor Sie die Entwicklung Ihres Datenmodells abschließen, sollten Sie testen, ob Sie mit entsprechenden Abfragen auf alle relevanten Datenfelder Zugriff haben, ob Sie entsprechend korrekte Ergebnisse erhalten und ob beim Ändern oder Löschen von Daten ggf. andere Daten ungewollt mit verändern werden. Bei auftretenden Inkonsistenzen müssen Sie unbedingt Ihr Datenmodell überarbeiten.

Hinweis: Datenmodelle werden in der Praxis selten perfekt und ebenso selten zu hundert Prozent korrekt nach Theorie erstellt, sondern i.d.R. an die individuellen Vorgaben und Voraussetzungen angepasst. Oftmals funktionieren verschiedene Lösungen, sodass bei vielen Entscheidungen die Sichtweise des Entwicklers ausschlaggebend ist.