Fahrradbauer Redinger plant den Aufbau seiner fertigen Fahrradmodelle zu digitalisieren. Dazu möchte er sich mit deiner Hilfe eine Datenbank anlegen.

Für seine Datenbank möchte er zum Beispiel wissen, welche Bauteile (Lenker, Reifen, Bremsen,...) in einem fertigen Fahrradmodell verwendet wurden. So kann er leichter abschätzen, wie viel und was er demnächst nachbestellen muss.

Herr Redinger weiß schon, dass es in der Datenbank mehr als eine Tabelle geben wird und auch die Beziehungen der Klassen im Klassendiagramm sind für ihn kein Problem. Trotzdem ist er sich noch nicht sicher, wie er die Tabellen in der Datenbank anlegen soll - na klar, es fehlt ja auch noch eine wichtige Sache, die du in diesem Kurs kennenlernst: Die Kardinalitäten.

Im objektorientierten Datenmodell findest du nicht nur die Klassenkarten mit ihren Attributen, sondern auch die Beziehungen, die es zwischen den Objekten der Klassen geben kann.

Für die Umsetzung in einer Datenbank ist aber nicht nur wichtig, ob es eine solche Beziehung gibt, sondern auch, wie viele Objekte der einen Klasse mit einem Objekt der anderen Klasse verbunden sein können.

Diese Information lässt sich mithilfe von Kardinalitäten darstellen.

Im Klassendiagramm siehst du die Kardinalitäten am Ende der Beziehungslinien. Es sind entweder Zahlen oder Buchstaben.

Doch was schreibst du wann auf die Linie? Das lernst du Stück für Stück auf den nächsten Seiten.

Herr Redinger legt los: "Der leichte Fall zuerst. Natürlich hat jedes Fahrrad genau einen Lenker und zwei Räder. Sondermodelle, zum Beispiel Liegefahrräder, können wir außen vor lassen, die stelle ich nicht her."

Die allgemeine Aussage von Herr Redinger kannst du jetzt zu einem Standardsatz umbauen, der dir hilft, das Klassendiagramm zu erstellen und zu lesen.

Starte immer mit "Ein Objekt der Klasse ...":

• Ein Objekt der Klasse FAHRRAD hat ein Objekt der Klasse LENKER.

• Ein Objekt der Klasse FAHRRAD hat zwei Objekte der Klasse REIFEN.

"Jetzt wird es komplizierter. Die Anzahl der Reflektoren hängt von verschiedenen Faktoren wie der Reifengröße oder der angedachten Nutzung ab. Es sind mal 6, mal 10, mal 12...", erklärt Herr Redinger mit Blick aufs Regal.

Natürlich hat jedes Objekt, also jedes fertige Fahrrad, eine feste Anzahl von verbauten Reflektoren. Aber die Klasse ist der allgemeine "Bauplan" für alle Fahrräder und deshalb kann man die Reflektorenzahl noch nicht genau angeben. Trotzdem muss die Beziehung natürlich erfasst werden, damit Herr Redinger sehen kann, welche Reflektoren benutzt wurden. Als Platzhalter schreibt man hier ein n (später auch: m), wobei das n ein Platzhalter für eine beliebige positive Ganzzahl ist (0,1,2,...).

Gesprochen: Ein Objekt der Klasse FAHRRAD hat kein, ein oder mehrere (n) Objekte der Klasse REFLEKTOR.

Ganz am Anfang hat Herr Redinger begonnen, alle Beziehungen aus der Sicht des Fahrrads zu beschreiben: Das Fahrrad hat Reifen, Das Fahrrad hat einen Lenker,...

Doch für dich als Datenbankadministrator ist es immer auch wichtig, sich die andere Richtung anzuschauen, denn manche Beziehungen sind schwerer in der Datenbank umzusetzen als andere (mehr dazu später).

Deshalb ergänzt du bei allen Beziehungen auch noch die "Gegenrichtung" aus der Sicht des Reifens, des Lenkers und des Reflektors. Das Ergebnis ist auf den ersten Blick ziemlich langweilig:

Oder gelesen als "Standardsatz":

• Ein Objekt der Klasse LENKER gehört zu einem Objekt der Klasse FAHRRAD.

• Ein Objekt der Klasse REIFEN gehört zu einem Objekt der Klasse FAHRRAD.

• Ein Objekt der Klasse REFLEKTOR gehört zu einem Objekt der Klasse FAHRRAD.

(Beginne deinen Satz IMMER mit ein! Du schaust dir immer nur eine Leserichtung an und ignorierst die andere Kardinalität)

Natürlich kann ein Bauteil nur zu einem Fahrrad gehören! Stell dir mal vor, du teilst deinen Lenker mit jemand anderem...

Aber ist das immer so, auf einer Seite steht eine 1? Nein!

Auf der nächsten Seite findest du ein Beispiel.

Für eventuelle Rückfragen möchte Herr Redinger wissen, welches seiner Teammitglieder an dem jeweiligen Fahrradmodell mitgearbeitet hat. Natürlich arbeitet aber auch jedes Teammitglied im Laufe der Anstellung an mehr als einem Rad:

Ein Objekt der Klasse FAHRRAD wird gebaut von keinem, einem oder mehreren (n) Objekten der Klasse TEAMMITGLIED.

Ein Objekt der Klasse TEAMMITGLIED baut an keinem, einen oder mehreren (m) Objekten der Klasse FAHRRAD.

Diese Beziehung nennt man auch m:n-Beziehung, sie ist die aufwändigste Beziehungsart zwischen Klassen.

Der Name einer Beziehung wird durch seine Kardinalitäten festgelegt. Steht an einem Ende eine 1, am anderen ein n, so ist es eine 1:n-Beziehung (Sprich: 1 zu n).

Entscheidend für deine Datenbank sind folgende drei Arten:

1:1-Beziehung

1:n-Beziehung

m:n-Beziehung

Diese "Modellierungs-Arbeit" machst du dir, damit deine Datenbank später rund läuft, möglichst einfach aufgebaut ist und natürlich, damit möglichst wenige Fehler bei der Nutzung passieren.

Was die Beziehungsarten für die Umsetzung bedeuten, ist ein anderes, sehr spannendes Thema. Du kannst es dir im Kurs Beziehungen in Datenbanken anschauen. Kleiner Teaser: Dort geht es auch um die Lieblingshose von Michael Jordan.