Zeitgeist ZMS V3.0
 

Modellieren von Beziehungen (1:n, n:m)
26.05.2010, Fertig

Einleitung

Um im ZMS Beziehungen abzubilden können die Featurestyle Includes genutzt werden. Um komplexere Beziehungen zu realisieren können die Featurestyle Includes zusätzlich mit den Auswahl-Feldtypen (select, radio oder checkbox) kombiniert werden.

Die gewählte Abbildung einer Beziehung hat direkt Einfluss auf:

  • Den Prozess beim Editieren der Daten
  • Die Erweiterbarkeit der Applikation

Oft muss man sich zwischen diesen zwei Punkten entscheiden: Bessere Editierbarkeit (Usability) oder bessere Erweiterbarkeit. Im Zweifel sollte die bessere Editierbarkeit gewählt werden, da ein nachträglicher Umbau keine grossen Probleme bereitet.

Beziehungstypen

1:1

1:1 Beziehungen müssen in der Regel nicht abgebildet werden, da der entfernte Wert direkt zum Basiseintrag gespeichert werden kann. So könnte zum Beispiel bei einer 1:1 Beziehung zwischen Person und Adresse, die Adresse direkt in den Datensatz der Person gespeichert werden.

1:n

Zur Umsetzung von 1:n Beziehungen gibt es zwei Ansätze:

  • Ein Featurestyle mit Includes
  • Zwei Featurestyles die aufeinander zugreifen

Bei der Lösung mit einem Featurestyle entsteht eine Liste mit den Haupteinträgen. Beim Editieren eines Haupteintrages können Untereinträge zugefügt und editiert werden.
Vorteil: Sehr intuitive Bedienung.
Nachteil: Die Untereinträge können nur schwer in weiteren Beziehungen verwendet werden.

Die Lösung mit zwei Featurestyles erzeugt zwei Listen mit Einträgen: Eine für die Haupteinträge und eine für die Untereinträge. Die Untereinträge können über ein Feld mit einem Auswahl-Typ (select, radio oder checkbox) den Haupteinträgen zugeteilt werden.
Vorteil: Sauber getrennte Daten die gut in weiteren Beziehungen verwendet werden können.
Nachteil: Komplizierte Bedienung mit zwei Listen.

Zur konkreten Umsetzung siehe Beispiel 1: Mannschaften und Spieler.

n:m

Eine n:m Beziehung kann als Kombination von zwei 1:n Beziehungen angesehen werden, womit alle Möglichkeiten zur Umsetzung von 1:n Beziehungen (zweimal angewendet) genutzt werden können. Weiter können zur Umsetzung von n:m Beziehungen folgende zwei Ansätze gewählt werden:

  • Ein Featurestyle mit Includes, die auf einen zweiten Featurestyle zugreifen
  • Ein Featurestyle mit Checkboxen, die auf einen zweiten Featurestyle zugreifen

 Alle Lösungen für das Abbilden von n:m Beziehungen brauchen eine separate Datenquelle (Featurestyle), welcher die Daten, die zugeordnet werden können, liefert. Dieser Featurestyle kann selber wieder in vollem Masse mit Includes und Components ausgebaut werden.

Die erste und einfachste Lösung ist das Abbilden von zwei 1:n Beziehungen. Dazu muss ein Zwischen-Featurestyle (wie beim Datenbankdesign die Zwischentabelle) erstellt werden, der anschliessend die Zuordnung der zwei Teile ermöglicht.
Vorteil: Sehr flexibel bezüglich eines weiteren Ausbaus (sauber getrennte Daten).
Nachteil: Sehr komplizierte Bedienung mit 3 Listen.

Die zweite Lösungsmöglichkeit nutzt die Includes um den weiteren Freiheitsgrad zu erreichen. Dazu wird im Featurestyle der inkludiert wird ein Auswahlfeld (select oder radio) integriert, das die Werte aus dem anderen Featurestyle ausliest.
Vorteil: Intuitive Bedienung innerhalb eines Featurestyles.
Nachteil: Die Zuweisungen können nur schwer in weiteren Beziehungen verwendet werden.

Die dritte Möglichkeit nutzt das Verhalten von Checkboxen, wobei ja mehrere Werte angewählt werden können. In einem Featurestyle wird dabei eine Checkbox-Auswahl integriert, welche die Werte aus einem anderen Featurestyle liest.
Vorteil: Sehr intuitive und übersichtliche Bedienung innerhalb eines Featurestyles.
Nachteil: Die Checkboxwerte können kaum weiterverwendet werden (kommasepariert gespeichert).

Zur konkreten Umsetzung siehe Beispiel 2: Schüler und Fächer.

Beispiele

Beispiel 1: Mannschaften und Spieler (1:n)

In diesem Beispiel sollen Spieler Mannschaften zugeteilt werden, wobei ein Spieler nur in einer Mannschaft sein kann. Das konzeptionelle Datenmodell sieht somit so aus:

Datenmodell für Spieler und Mannschaften
Datenmodell für Spieler und Mannschaften

In einer ersten Variante wird mit Includes gearbeitet. Innerhalb einer Mannschaft sollen die Spieler erfasst werden können. Dazu werden folgende zwei Featurestyles erstellt:

MANNSCHAFT

  • Name: text(50)

SPIELER (include)

  • Name: text(50)
  • Vorname: text(50)
  • (feature_id): int
  • (sort): int

Die Spieler werden anschliessend als Include der die Mannschaft eingetragen. Die Felder in Klammern sind für das Speichern der Includedaten.

Es resultierten folgende Editierseiten:
 

Variante 1: Liste der Mannschaften
Variante 1: Liste der Mannschaften
Variante 1: Editieren einer Mannschaft/Spieler
Variante 1: Editieren einer Mannschaft/Spieler

Eine zweite Umsetzungsvariant arbeitet ohne Includes. Die Spieler und die Mannschaften werden separat erfasst, wobei die Spieler über ein Auswahlfeld den bestehenden Mannschaften zugeordnet werden können. Es werden folgende Featurestyles erstellt:

MANNSCHAFT

  • Name: text(50)

SPIELER

  • Mannschaft: select
  • Name: text(50)
  • Vorname: text(50)

Die Abfrage für das Auswahlfeld lautet:
Als Resultat entstehen zwei Listen mit separatem Editierbereich:

Variante 2: Liste und Edit für die Mannschaften
Variante 2: Liste und Edit für die Mannschaften
Variante 2: Liste und Edit für die Spieler
Variante 2: Liste und Edit für die Spieler

Beispiel 2: Fächer und Schüler (n:m)

In diesem Beispiel sollen Schüler Fächern zugeteilt werden, wobei ein Schüler mehrere Fächer besuchen kann und ein Fach von mehreren Schülern besucht wird. Das konzeptionelle Datenmodell sieht wie folgt aus:

Datenmodell für SChüler und Fächer
Datenmodell für SChüler und Fächer

Die erste Variante ist das separate Erfassen der Schüler und der Fächer. Zusätzlich wird mit einem Zwischen-Featurestyle die Zuweisung der Schüler zu den Fächern. Es braucht also folgende Featurestyles:

SCHUELER

  • Name: text(50)
  • Vorname: text(50)

FACH

  • Name: text(20)

SCHUELER2FACH

  • Schueler: select
  • Fach: select

Die Abfragen für die Auswahlfelder lauten:
Als Resultat entstehen zwei Listen mit Editiermaske für die Schüler und die Fächer (nicht abgebildet) sowie die Liste und die Editiermaske für den Zwischen-Featurestyle.

Variante1: Liste und Edit des Zuweisungs-Feature
Variante1: Liste und Edit des Zuweisungs-Feature

Als zweite Lösungsmöglichkeit wird mit Includes gearbeitet, wobei dem Featurestyle der Schüler ein Include verpasst wird, dass die Zuweisung der Fächer ermöglicht. Es braucht also folgende Featurestyles:

SCHUELER

  • Name: text(50)
  • Vorname: text(50)

FACH

  • Name: text(20)

FACHZUWEISUNG (include)

  • fach: select
  • (feature_id): int
  • (sort): int

Das Resultat ergibt eine Liste und eine Editiermaske für die Fächer (nicht abgebildet) sowie die Liste und Editiermaske für die Schüler mit den Includes für die Fächer.

Variante 2: Liste und Schüler mit Fächer-Include
Variante 2: Liste und Schüler mit Fächer-Include

Die dritte Lösung ist sehr ähnlich wie die zweite, wobei aber die Fächerauswahl nicht über Includes sondern über Checkboxen gelöst wird. Die Abfrage für die Checkboxen ist aber dieselbe wie beim Auswahlfeld. Es resultiert wieder eine Liste und ein Editierformular für die Fächer (nicht abgebildet) und die Liste/Editiermaske für die Schüler.

Variante 3: Edit der Schüler mit Fächer-Checkboxen
Variante 3: Edit der Schüler mit Fächer-Checkboxen

Die letzte Lösung sieht vom Usability-Aspekt betrachtet sicher sehr gut aus, da in der Liste alles ersichtlich und das Auswählen der Fächer sehr einfach ist. Allerdings ist das Abfragen der gewählten Fächer sehr schwierig.