Die Festlegung der Informationen in den einzelnen Tabellen sowie deren Beziehungen untereinander

Suche nach möglichen Vereinfachungen der Daten(-bank-)struktur

Nachdem wir alle n:m-Beziehungen durch das Einfügen von Zwischenrelationen aufgelöst haben, fällt auf, dass Informationen in den verschiedenen Zwischenrelationen redundant sind:

Logisches Datenbankmodell (ER-Modell) mit aufgelösten n:m-Beziehungen
Sowohl die Klasse als auch der Raum, das Fach und die Lehrkraft kommen mehrmals vor. Das birgt die Notwendigkeit als auch die Chance, das Modell nochmals zu vereinfachen: Fasst man die Informationen von Klasse, Lehrkraft, Fach und Raum zusammen, lassen sich diese Informationen in einer neuen Relation „tbl_unterricht“ (eigentlich müsste die neue Relation gem. den Ausführungen im Kapitel „Abbildungsregeln“  „tbl_klasse/raum/fach/lehrkraft“ genannt werden, was jedoch relativ umständlich wäre) aufnehmen. Das Ergebnis könnte folgendermaßen aussehen:

Vereinfachtes logisches ER-Modell „Schule“ mit aufgelösten n:m-Beziehungen

Nachdem wir nun das logische ER-Modell durch das Auflösen der n:m-Beziehungen soweit entwickelt haben, dass alle Beziehungen bereit für die digitale Übernahme sind, werden wir uns in einem nächsten Schritt darüber Gedanken machen, welche Informationen die einzelnen Relation konkret enthalten sollen.

Die Zwischenrelationen wurden zu der einzigen verbleibenden Zuordnungstabelle „Unterricht“ zusammengefasst.

Im nächsten Schritt werden wir uns um die Struktur der einzelnen Relationen auseinandersetzen: Wir werden festlegen, welche Informationen darin gespeichert werden sollen und in welchem Format dies erfolgen soll. Das Ergebnis soll ein Modell sein, welches 1:1 mit Hilfe eines DBMS im PC realisiert werden kann. Folgende Frage steht hierbei im Mittelpunkt:

Welche Informationen sollen die einzelnen Tabellen jeweils enthalten?

Betrachten wir zunächst einmal die Relation tbl_schüler. Diese könnte wie folgt aussehen:

Beachten wir hierbei, dass nach Möglichkeit keine Bindestriche in den Bezeichnungen vorkommen, da diese in Programmieranweisungen als mathematisches (Subtraktions-) Zeichen interpretiert werden. Verwenden wir stattdessen stets einen Unterstrich. Um Groß- und Kleinschreibung müssen wir uns an dieser Stelle nicht kümmern. Aus Gründen der Vereinfachung und Vereinheitlichung schreiben wir alle Merkmalsbezeichnungen klein.

Bearbeiten Sie Aufgabe 1, bevor Sie weiterlesen.

Wie können die einzelnen Relationen miteinander verbunden werden?

Wie wir bereits festgestellt haben, macht die Anordnung der Daten innerhalb einer Datenbank nur dann Sinn und entfaltet nur dann ihre Vorteile gegenüber den anderen eingangs diskutierten Möglichkeiten der Datenspeicherung in einzelnen Dateien, wenn die Relationen miteinander verbunden sind. Nachdem wir die Inhalte der einzelnen Relationen festgelegt haben, machen wir uns daran, diese zu einem Gesamtkonstrukt zu verbinden, in welchem alle Relationen und damit alle Informationen miteinander in Verbindung stehen.

Wir haben jetzt alle Attribute der Relationen festgelegt. In einem weiteren Schritt gilt es nun, die Relationen miteinander zu verbinden. Wir wollen uns die (mögliche aber noch nicht realisierte) Verbindung von zwei Relationen am Beispiel von „tbl_schüler“ und „tbl_klasse“ ansehen:

tbl_schüler und tbl_klasse mit ihrem jeweiligen Primärschlüsselattribut

Primär- und Fremdschlüssel in Vater- und Sohntabelle

Beide Relationen haben eine ID, welche (in Microsoft Access) jeweils mit einem Schlüsselsymbol gekennzeichnet ist. Das Symbol bedeutet, dass es sich hierbei um ein Schlüsselattribut handelt, welches gewährleistet, dass jeder Datensatz (auch für den Fall, dass mehrere Datensätze in allen anderen Attributswerten exakt übereinstimmen) in der jeweiligen Relation einmalig ist. Das Schlüsselattribut bezeichnet man auch als Primärschlüssel (Primarykey). Auch hier vereinheitlichen wir die Bezeichnung, indem wir jedem Primäschlüsselattribut das Suffix „_id“ geben.

In der Relation „tbl_schüler“ sehen wir an unterster Stelle das Attribut „klassen_nr“. Dieses Attribut dient dazu, im Datensatz eines jeden Schülers die ID der Klasse aufzunehmen, welcher der Schüler zugeteilt ist. Das aufnehmende Attribut ist der sog. Fremdschlüssel (Secondarykey). Die Bezeichnung rührt daher, dass der Schlüsselwert nicht in der aktuellen Relation generiert wurde, sondern in einer „fremden“ – im vorliegenden Fall in der Relation „tbl_klasse“. Alle Fremdschlüssel erhalten durchgängig das Suffix „_nr“.

Bevor wir nun die beiden Relationen miteinander verbinden, kommen wir nicht umhin, ihre jeweilige Rolle innerhalb dieser Beziehung zu klären: Die Relation „tbl_klasse“ gibt an die Relation „tbl_schüler“ die Werte der Primärschlüssel entsprechend der Schülerzuteilung in die Klassen weiter. Sie nimmt – in Anlehnung an die Generationenrollen bei Lebewesen – die Rolle des Vaters ein und wird daher innerhalb dieser Beziehung als Vaterrelation bezeichnet. Die Relation „tbl_schüler“ bekommt die Information des Primärschlüssels als Fremdschlüssel. Sie nimmt innerhalb der Beziehung die Rolle des Sohnes ein, weswegen sie – allerdings nur für diese Beziehung betrachtet – als Sohnrelation bezeichnet wird.

Künstlicher  vs. sprechender Primärschlüssel

Access und andere DBMS sind in der Lage, die Datensätze automatisch zu numerieren und jedem Datensatz damit einen eindeutigen Schlüssel in Form einer ID zuzuweisen. Dabei gewährleistet das DBMS, dass innerhalb einer Relation ein ID-Wert stets einmalig ist. Diese Form der IDs nennt man auch künstlichen Schlüssel, weil sie keinerlei Informationen aus der Realtität enthalten, wie das bei sog. sprechenden Schlüsseln der Fall wäre.
Die Anwendung sprechender Schlüssel hätte zur Folge, dass die Funktion der Datenbank durch Änderungen in der Realität nicht mehr gewährleistet wäre.

Ein Beispiel: In einer Spedition ist es aus den genannten Gründen ratsam, jedem Kfz eine ID in Form einer Nummer zu geben. Natürlich könnte man stattdessen einen sprechenden Schlüssel in Form des jeweiligen amtlichen Kennzeichens vergeben – auch hier wäre die Einmaligkeit gewährleistet. Würden jedoch – aus welchen Gründen auch immer – die Gültigkeitsbereiche der Kennzeichen neu zugeschnitten werden, müsste bei jedem Kfz-Datensatz der Primärschlüssel geändert werden. Zudem müssten auch noch in allen damit zusammenhängenden Sohntabellen die Werte der Fremdschlüssel entsprechend aktualisiert werden, weil sonst die korrekten Zuordnungen nicht mehr gewährleistet werden könnten.
Im Falle der Verwendung von künstlichen Schlüsseln wäre lediglich das Attribung „kfz_kennzeichen“ in der Relation „tbl_fahrzeuge“ abzuändern.

Wir fassen zusammen:

• Innerhalb einer Beziehung zwischen zwei Relationen hat immer eine Relation die Rolle des Vaters (Vaterrelation, Mastertabelle) und eine die Rolle des Sohnes (Sohnrelation, Detailtabelle).
• Die Vaterrelation gibt die Information ihres Primärschlüssels an die Sohnrelation weiter, wo er als Fremdschlüssel aufgenommen wird.
• Bei der Wahl der Primäschlüssel achten wir darauf, dass grundsätzlich keine sprechenden Schlüssel, sondern stattdessen nur künstliche Schlüssel vergeben werden.

Da die Rollen der beiden Relationen und die Anknüpfungspunkte der Beziehung geklärt sind, können wir die beiden Relationen verbinden:

tbl_schüler und tbl_klasse mit Beziehung

Soeben haben wir unser erstes kleines relationales Datenbankmodell erstellt, indem wir für die beiden Relationen die Attribute sowie die Schlüssel festgelegt und zuletzt beide verbunden haben. Die Kardinalitäten als Zusatzinformation sind an dieser Stelle nicht mehr notwendig, weil sich durch die Beziehung zwischen Primär- und Fremdschlüssel die Art der Beziehung quasi „von alleine“ ergibt. MS Access wird die Kardinalitäten später wieder anzeigen.

Lösen Sie jetzt die Aufgabe 2. Beachten Sie hierbei folgendes:

Aus Gründen der Redundanzvermeidung wurden

• die Geschlechter (m/w/d) in einer gesonderten Tabelle mit ID hinterlegt und
• anstelle von Ort und PLZ in den Personendatensätzen nur eine plz_nr hinterlegt, welche ihrerseits die Information über Ort und zugehöriger als Fremdschlüssel bekommt:

Die einzelnen Relationen sind jetzt im relationalen Datenbankmodell miteinander verbunden.

Die eigentliche Entwicklungsarbeit mit Papier und (Blei-) Stift ist nun erst einmal getan.
Bevor wir das Modell als (leere) Datenbank mit Hilfe von MS Access implementieren, wollen wir das Modell auf Redundanzen hin untersuchen.
Hierfür gibt es eine systematische Vorgehensweise, welche wir im nächsten Kapitel kennenlernen wollen.