sport

Mit dem folgenden Beispiel soll der Entstehungsprozess eines Datenmodells gezeigt werden – seine Entwicklung „Schritt um Schritt“. In vollem Umfang, mit allen Einzelschritten und an einem realen Beispiel, ist dies aus Platzgründen nicht möglich. Trotzdem sollte das Beispiel einen Eindruck davon geben, wie Datenmodelle entstehen.

Aus vielen Diskussionen mit Teilnehmern von Schulungen und Studierenden in Vorlesungen weiß ich, dass reale Sportvereine eine viel reichere und tiefere Semantik haben. Ich bitte daher vor allem alle Sportvereinsmitglieder um Verzeihung für die Einfachheit des Beispiels, denke aber, dass es trotzdem seine Aufgabe erfüllen kann.

1.1 Ziel

Ein Sportverein beschließt, seine Aktivitäten (Mitgliederverwaltung, Sportveranstaltungen, usw. ) in Zukunft computergestützt abzuwickeln. Dazu soll im ersten Schritt eine einfache Datenbank aufgebaut werden, für die folgende Spezifikationen festgehalten werden:

• Der Sportverein ist in Abteilungen gegliedert. Eine für Handball, eine für Fußball. Weitere können in der Zukunft dazukommen.
• Jede Abteilung hat einen Leiter.
• Jede Abteilung hat mehrere Mannschaften.
• Von jeder Mannschaft werden die Spieler, der Kapitän und die Liga festgehalten, in der sie spielt (Bundesliga, usw.)
• Jede Mannschaft hat einen Trainer.
• Die Begegnungen von Mannschaften des Vereins mit Datum, gegnerischer Mannschaft und Ergebnis sollen festgehalten werden.
• Die Mitglieder des Vereins werden durch Name, Vorname, PLZ, Ort, Straße, Telefon, Geburtstag, Alter und eine Mitgliedsnummer festgehalten.

Außerdem wird für die Mitglieder erfasst, ob es sich um ein passives oder ein aktives Mitglied handelt. Für jedes aktive Mitglied wird dann noch festgehalten, welche Sportart es in welcher Leistungsstufe betreibt; für die passiven Mitglieder wird erfasst, für welche ehrenamtliche Tätigkeit sie zur Verfügung stehen.

1.2 Erste Schritte

Wie sehen nun die konkreten Modellierungsschritte aus? Sinnvoll ist es, zuerst die Entitätstypen zu suchen. Dies ist dann allerdings keine endgültige Festlegung, sondern eine, die im Verlauf der Modellierung auch wieder korrigiert werden kann.

Beginnen wir also mit Entitäten und Entitätstypen. Diese erkennt man im modellierungstechnischen Sinne daran, dass es sich erstens um Objekte im allgemeinen Sinn handelt und dass zweitens diese Objekte durch Attribute beschrieben werden. Zweiteres ist von zentraler Bedeutung, denn sonst kann es sich auch um ein Attribut handeln, wie auch dieses Beispiel gleich zeigen wird.

Entitäten und Entitätstypen erkennen

Natürlich etablieren auch andere nicht-konventionelle Attribute einen Entitätstyp. Z.B. Grafiken, Bilder, Videos, usw. Allerdings sind diese nur Ergänzungen der Basisbeschreibung durch Attribute, die auf jeden Fall vorhanden sein muss.

Hier ist ein Entitätstyp sofort erkennbar, die Mitglieder. Die Vereinsmitglieder existieren - auch im allgemeinen Sinn - und sie werden durch Attribute beschrieben:

Offen bleibt nun noch die Frage, wie die Eigenschaft, aktives oder passives Vereinsmitglied zu sein, erfasst wird. Ginge es nur um diese Eigenschaft, würde einfach ein Attribut „aktiv/passiv“ mit diesen zwei Eigenschaften an den Entitätstyp Mitglieder angefügt. Nun ist es hier aber so, dass für die aktiven und passiven Mitglieder jeweils unterschiedliche Attribute festgehalten werden sollen. Deshalb müssen diese Teilgruppen der Mitglieder getrennt erfasst und - da sie ja als Mitglieder auch gemeinsame Attribute haben - in der im ersten Teil vorgestellten Notation als Generalisierung/Spezialisierung angelegt werden:

aktiv / passiv

Soweit der erste Entitätstyp Mitglieder. Hinzugenommen wurde ein Attribut Status mit den Ausprägungen passiv und aktiv, mit dem es möglich ist, die allgemeinen Attribute (Adressen) der beiden Gruppen gezielt anzusprechen.

Differenzierung

Das Attribut mit den Punkten soll oben und im folgenden die schon vorher eingeführten Attribute andeuten.

Hinweis:

Die aktiven Mitglieder erhalten die Attribute Sportart (derzeit nur Handball oder Fußball) und Leistungsstand. Es wird davon ausgegangen, dass ein Spieler nur eine Sportart betreibt. Das Attribut ehrenamtliche Tätigkeit der passiven Mitglieder erfasst in einer irgendwie verkodeten Form, für was das Mitglied zur Verfügung steht. Es handelt sich um ein mehrwertiges Attribut.

Oftmals möchte man bei einer Spezialisierung ausdrücken, dass alle Entitäten des übergeordneten Typs an der Spezialisierung teilnehmen müssen. Dies geschieht, wie in der obigen Abbildung, durch einen Doppelstrich zwischen dem übergeordneten Typ und dem d-Kreis. Er signalisiert hier, dass alle Mitglieder entweder aktive oder passive Mitglieder sein müssen. Eine andere Mitgliedschaft gibt es somit modelltechnisch nicht. Alternativ könnten hier statt der Spezialisierung passive Mitglieder nur die ehrenamtlich tätigen Mitglieder erfasst sein. Dann müsste der Doppelstrich beseitigt werden, da es dann Mitglieder gäbe, die in keine der beiden Spezialisierungen eingehen (die passiven, die nicht ehrenamtlich tätig sind).

Totale
Beteiligung

Bei Beziehungen wird „totale Beteiligung“ durch die Min-/Max-Angaben festgelegt. Steht als Mindestwert ein Wert größer 0 da, müssen alle Entitäten des Entitätstyps an der Verbindung teilhaben.

1.3 Die Mannschaften

Betrachten wir nun die Mannschaften. Sie tauchen mit folgenden Beschreibungen auf:

• Jede Abteilung hat mehrere Mannschaften, insofern könnte „Mannschaft“ ein Attribut von Abteilung sein.
• Von jeder Mannschaft werden Spieler, Kapitän, Liga, Trainer und Begegnungen festgehalten.

Letzteres macht die Mannschaften zu Entitätstypen, da sie durch weitere Attribute beschrieben werden. Die Klärung der Frage, ob sie evtl. ein Beziehungstyp sein können, wird auf eine spätere Phase des Modellierungsvorgangs verschoben. Damit ergibt sich folgender erster Entwurf:

Hinzugefügt wurde ein Attribut Name, mit der Bezeichnung der Mannschaften. Das Attribut Spieler ist mehrwertig, da jede Mannschaft mehrere Spieler hat.

Auf die Aufnahme eines Attributs Begegnung wurde verzichtet, da die Begegnungen durch weitere Attribute zu einer eigenständigen Existenz kommen.

1.4 Begegnungen

Im beschreibenden Text wurde festgelegt, dass alle Begegnungen von Mannschaften des Vereins mit Tagesdatum, Gegner und Ergebnis festgehalten werden sollen. Damit entsteht ein entsprechender Entitätstyp. Gleichzeitig wird hier der erste Beziehungstyp deutlich, der mit M_B bezeichnet werden soll und schlicht die Tatsache beschreibt, dass die Mannschaften des Vereins an den Begegnungen teilnehmen. Da auch nur solche Begegnungen erfasst werden, handelt es sich um einen singulären Entitätstyp, der durch ein Rechteck mit Doppellinie dargestellt wird. Der zugehörige Beziehungstyp erhält ebenfalls eine solche.

Das Attribut Beginn wurde zusätzlich aufgenommen, um mehrere Begegnungen an einem Tag, z.B. im Rahmen eines Turniers, unterscheiden zu können. Schlüssel für diesen Entitätstyp sind die Attribute Tag, Beginn und Gegner zusammen.

Zu beachten ist, dass es nur um die Spiele des betrachteten Vereins geht, nicht um alle Spiele einer Liga, was die Situation verändern würde.

Als Schlüssel wurde hier ein zusammengesetzter genommen, der bei der Überführung in konkretere Strukturen (Z.B. in Relationen) um den Schlüssel von Mannschaften ergänzt werden müsste. Dies ist typisch für singuläre Entitätstypen. Ihre Existenzabhängigkeit zeigt sich auch darin, dass ihr Schlüssel um den des anderen Entitätstyps ergänzt werden muss.

1.5 Abteilungen

Jetzt müssen noch die Abteilungen betrachtet werden. Für sie wurde oben festgehalten, dass der Verein in Abteilungen gegliedert ist (Handball und Fußball), dass jede Abteilung eine/n Leiter/in und mehrere Mannschaften hat.

In Konfrontation mit den schon erstellten Modellfragmenten lässt sich damit festhalten, dass Abteilungen ein Entitätstyp mit den Attributen Leiter und Sportart ist. Die Tatsache, welche Mannschaft zu welcher Abteilung gehört, wird nicht durch ein Attribut festgehalten, sondern durch einen Beziehungstyp M_A zwischen Mannschaften und Abteilungen:

1.6 Zusammenstellung

Damit sind die wichtigsten Komponenten des zu erstellenden Datenmodells realisiert. In der folgenden Abbildung werden sie zusammengestellt.

Die Min-/Max-Angaben in der Abbildung haben folgende Bedeutung:

• 1,1 bei Mannschaften zu Abteilungen (M_A): Eine Mannschaft gehört zu genau einer Abteilung.
• 0,n bei Mannschaften zu Begegnungen (M_B): Eine Mannschaft hat an keiner (z.B., wenn sie neu aufgestellt wurde) oder an mehreren Begegnungen teilgenommen.
• 1,1 bei Begegnungen zu Mannschaften (M_B): Eine Begegnung wird nur dann als solche aufgenommen, wenn genau eine Mannschaft „unseres“ Vereins teilgenommen hat. Wir schließen hier also bewusst Begegnungen zwischen zwei Mannschaften des Vereins aus.
• 1,n bei Abteilungen zu Mannschaften (M_A): Eine Abteilung hat mindestens eine Mannschaft.

Dieses Gesamtmodell ist nun aber in einem wichtigen Punkt fehlerhaft: Eine Trennung eines Datenmodells in zwei unverbundene Teile ist nicht möglich. So etwas gibt es nicht, da ein Datenmodell ja gerade dadurch ausgezeichnet ist, dass zusammengehörige Informationen über einen Weltausschnitt verwaltet werden. Sonst sind es zwei Datenmodelle mit zwei verschiedenen Datenbanken.

Defizit: Trennung

1.7 Verschmelzung

Bei genauerer Betrachtung zeigt sich nun aber, dass natürlich die Mitglieder mit den organisatorischen Aspekten des Vereins auf vielfältige Weise verknüpft sind. Insbesondere sind dies folgende Aspekte:

• Aktive Mitglieder spielen in Mannschaften
• Aktive Mitglieder können Kapitän einer Mannschaft sein
• Aktive Mitglieder trainieren die Mannschaften (wir gehen davon aus, dass die Trainer als aktive Mitglieder zum Verein gehören)
• Aktive Mitglieder leiten die Abteilungen

Alle diese Informationen wurden im obigen ersten Entwurf - herrührend von den Modellkomponenten - als Attribute von Entitätstypen definiert. Dies muss nun geändert werden.

Beginnen wir mit den Spielern der Mannschaften. Diese Information sollte nicht als mehrwertiges Attribut von Mannschaften erfasst werden, sondern als Beziehungstyp zwischen Mannschaften und Aktive Mitglieder: AM_S. Damit ist nicht nur die Information der Mannschaftszugehörigkeit eindeutig erfasst, sondern es stehen auch die Adressen der Mannschaftsmitglieder zur Verfügung und die Namen der Spieler werden nur einmal erfasst, im Mitgliederverzeichnis, wo sie hingehören.

Verschmelzung

Ganz ähnlich bei der Erfassung der Trainer. Bisher als Attribut von Mannschaft erfasst, werden sie nun zu einer Beziehung zwischen Trainern und Mannschaften: AM_T.

Die Kapitäne der Mannschaften werden ebenfalls durch eine Beziehung zwischen Mannschaften und Aktive Mitglieder erfasst, AM_K, denn die Kapitäne sollen in unserem Datenmodell aktive Mitglieder sein.

Die Leiter der Abteilungen werden dementsprechend als Beziehung zwischen Abteilungen und Aktive Mitglieder erfasst: AM_A.

In der folgenden Abbildung nun das Gesamtmodell mit den besprochenen Korrekturen. Weggefallen sind nun die diversen Attribute, mit denen vorher die Beziehungen festgelegt wurden. Die weiteren Min-/Max-Angaben sind ebenfalls angegeben. Sie bedeuten:

• 0,1 bei Aktive Mitglieder zu Mannschaften und Beziehung AM_S: Ein aktives Mitglied spielt in maximal einer Mannschaft. Selbstverständlich wäre an der zweiten Position auch ein höherer Wert möglich, falls die Semantik es erfordert. Ebenso ein Wert größer Null an der ersten Position.
• 0,1 bei Aktive Mitglieder zu Mannschaften und Beziehung AM_T: Ein aktives Mitglied kann in maximal einer Mannschaft Trainer sein[1].
• 0,1 bei Aktive Mitglieder zu Mannschaften und Beziehung AM_K: Ein aktives Mitglied ist in maximal einer Mannschaft Kapitän.
• 0,1 bei Aktive Mitglieder zu abteilungen und Beziehung AM_A: Ein aktives Mitglied leitet maximal eine Abteilung.
• 1,1 bei Mannschaften zu Aktive Mitglieder und Beziehung AM_T: Eine Mannschaft wird von genau einem aktiven Mitglied trainiert.
• 11,15 bei Mannschaften zu Aktive Mitglieder und Beziehung AM_S: Eine Mannschaft besteht aus mindestens 11 und maximal 15 Spielern (aktive Mitglieder).
• 0,1 bei Mannschaften zu Aktive Mitglieder und Beziehung AM_K: Eine Mannschaft hat maximal einen Kapitän.