Kardinalität und Optionalität ternärer Beziehungen

Die Kardinalität und Optionalität binärer Beziehungen kann mit Hilfe der KaMe- und MuMi-Modellierungsfragen bestimmt werden. Mit einer Erweiterung der Fragen gelingt dies auch bei ternären Beziehungen.

Beispiel 1: Projekte

Hersteller liefern Artikel für Projekte. Ein Hersteller muss mindestens einen Artikel liefern. Ein Artikel aus Eigenproduktion muss nicht für ein Projekt geliefert werden, kann aber für viele Projekte geliefert werden. Ein Projekt verwendet mindestens einen Artikel. Ein Artikel wird für ein Projekt nur von einem Hersteller geliefert.

KaMe-Frage – für binäre Beziehungen

Kann eine Entität des Typs A mit mehreren Entitäten des Typs B in Beziehung stehen?

Ja    →  Kardinalität ist n
Nein  →  Kardinalität ist 1

Erweiterung für ternäre Beziehungen

Kann eine Entität des Typs A und eine Entität B mit mehreren Entitäten des Typs C in Beziehung stehen?

Ja    →  Kardinalität ist n
Nein  →  Kardinalität ist 1 

Die Kardinalitätsangabe wird an das Ende der Beziehung also an C geschrieben.

Beispiele:

• Kann ein Artikel für ein Projekt von mehreren Herstellern geliefert werden? Nein, also 1 an Hersteller
• Kann ein Hersteller für ein Projekt mehrere Artikel liefern? Ja, also m an Artikel
• Kann ein Artikel von einem Lieferanten an mehrere Projekte geliefert werden? Ja, also n an Projekte

Entfällt die Bedingung „Ein Artikel wird für ein Projekt nur von einem Hersteller geliefert.“ wird aus der n:m:1-Beziehung eine n:m:p-Beziehung.

MuMi-Frage für binäre Beziehungen

Muss eine Entität des Typs A mit mindestens einer Entität des Typs B in Beziehung stehen?

Ja     →   nicht optional, obligatorisch, muss-Beziehung
Nein   →   optional, nicht obligatorisch, kann-Beziehung

Erweiterung für ternäre Beziehungen

Muss eine Entität des Typs A mit mindestens einer Entität des Typs B und einer Entität des Typs C in Beziehung stehen?

Ja     →   nicht optional, obligatorisch, muss-Beziehung
Nein   →   optional, nicht obligatorisch, kann-Beziehung

Die Optionalitätsangabe wird an den Anfang der Beziehung also an A geschrieben.

Beispiele:

• Muss ein Artikel von mindestens einem Hersteller für ein Projekt geliefert werden? Nein, also kann an Artikel.
• Muss für ein Projekt mindestens ein Artikel von einem Hersteller geliefert werden? Ja, also muss an Projekt
• Muss ein Hersteller mindestens ein Artikel für ein Projekt liefern? Ja, also muss an Hersteller

Beispiel 2: Seminarthemen

Damit Studenten sich nicht auf einen Professor konzentrieren, dürfen sie bei einem Professor nur ein Seminarthema bearbeiten. Außerdem kann ein Student ein Seminarthema nur bei einem Professor bearbeiten. Ein Professor kann aber ein Seminarthema mehrmals vergeben. Studenten müssen Seminare besuchen, Seminarthemen müssen aber nicht gewählt werden.

Kardinalität

• Kann ein Student ein Seminarthema bei mehreren Professoren bearbeiten? Nein, also 1 an Professor
• Kann ein Student bei einem Professor mehrere Seminarthemen bearbeiten? Nein, also 1 an Seminarthema
• Kann ein Professor ein Seminarthema von mehreren Studenten bearbeiten lassen? Ja, also n an Student

Optionalität

• Muss ein Student mindestens ein Seminarthema bei einem Professor bearbeiten? Ja, also muss an Student.
• Muss ein Professor mindestens einen Studenten ein Seminarthema bearbeiten lassen? Nein, also kann an Professor
• Muss ein Seminarthema mindestens von einem Studenten bei einem Professor bearbeitet werden? Nein, also kann an Seminarthema

Primärschlüssel

Bei der Abbildung einer ternären Beziehung ins Relationenmodell besteht die Beziehungsrelation aus den Primärschlüsseln der beteiligten Entitätstypen. Gegebenenfalls kommen Beziehungsattribute hinzu. Die drei Primärschlüssel bilden zusammen einen Schlüssel der Beziehungsrelation, aber nicht unbedingt einen Primärschlüssel, da dieser aus einer minimalen Anzahl von Attributen bestehen muss.

In Beispiel 1 seien Artikel_ID, Hersteller_ID und Projekt_ID die Primärschlüssel der beteiligten Entitätstypen. Handelt es sich bei liefert um eine n:m:p-Beziehung so bilden alle drei IDs den Primärschlüssel des liefert-Beziehungstyps: liefert(↑Artikel_ID, ↑Hersteller_ID, ↑Projekt_ID)

In der Variante n:m:1 ist der Hersteller bei gegebenem Artikel und Projekt eindeutig bestimmt. Daher wird der Fremdschlüssel der 1-Seite aus den Schlüsselattributen entfernt.
liefert(↑Artikel_ID, ↑Hersteller_ID, ↑Projekt_ID)

In Seminarthemen-Beispiel seien Professor_ID, Student_ID und Seminarthema_ID die Primärschlüssel der beteiligten Entitätstypen. Die Kombination der drei Primärschlüssel ist kein Primärschlüssel der Beziehungstyps bearbeitet, weil sie nicht minimal ist. Wir können nicht beide Primärschlüssel der 1-Seiten aus dem Schlüssel entfernen, denn dann bleibt übrig:
bearbeitet(↑Professor_ID, ↑Student_ID, ↑Seminarthema_ID)
Da ein Student aber mehrere Seminarthemen bearbeiten können muss, muss man entweder den Primärschlüssel von Professor oder von Seminarthema zum Primärschlüssel von bearbeitet hinzunehmen:

bearbeitet(↑Professor_ID, ↑Student_ID, ↑Seminarthema_ID)  oder
bearbeitet(↑Professor_ID, ↑Student_ID, ↑Seminarthema_ID)