Übungsaufgabe: Eine ERP-Datenbank detailliert modellieren (konzeptuell/ERM und logisch/Relationenmodell)

Den größten Notationsumfang für ein konzeptuelles Modell bietet die Chen-Notation. Ich nutze hier die modifizierte Darstellung, die erweitert ist um Optionalitäten, abgeleitete Attribute, Schlüsselattribute, schwache Entitätstypen/Schlüssel, identifizierende Relationen und mehrwertige Attribute.

Entitätstypen:

Aus der Aufgabenstellung ergeben sich direkt die kursiv geschriebenen Entitätstypen Inventar, Ort, Person, Abteilung. Über Eigenschaften dieser Entitätstypen ergeben sich weiterhin InventarArt und OrtArt. Als Relationstyp mit Attributen muss auch Buchung wie ein Entitätstyp umgesetzt werden.

Kardinalitäten:

• eins-zu-viele: Es ergeben sich sechs Relationen mit einer Vielfachheit auf einer Seite.
• viele-zu-viele: Zweimal liegt diese Kardinalität vor: bei Inventar/Abteilungen sowie bei Inventar/Person über Buchung (sofern das nicht in zwei 1:n-Relationen aufgelöst wurde)
• eins-zu-eins: Zwischen der Abteilung und dem Abteilungsleitenden (Person) liegt eine direkte Verküpfung vor.

Optionalitäten:

In den Anforderungen sind hierzu einige Schlüsselbegriffe für Optionalität genannt (“kann”, “können”, …), bei anderen Anforderungen wird expizit auf fehlende Optionalität hingewiesen ( “muss”, “zwingend”, “jede/r”, “genau”…).

Optional ist die Ortszuweisung von Inventar in beiden Richtungen. Personen und Abteilungen müssen nicht zwingend ein zugewiesenes Inventar haben. Die hierarchische Zuordnung von Orten ist in beide Richtungen optional. OrtArten müssen nicht einem Ort zugeordnet werden (das ergibt aus der Berarbeitungslogik, nicht aus der Aufgabenstellung).

Mehrwertige Attribute:

Genannt wird die Anschrift als klassisches mehrwertiges Attribut von Person.

Abgeleitete Attribute:

Die Dauer eine Buchung berechnet sich aus der Start- und Endzeit und ist somit kein eigenständiges Attribut.

Schwache Entitätstypen, schwache Schlüssel und identifizierende Relationen:

Es wird genannt, dass Inventar immer über die InventarArt und eine je InventarArt laufende Nummer identifiziert wird. Diese Beziehung ist also eine identifizierende Relation, Inventar benötigt eine InventarArt - ist somit ein schwacher Entitätstyp und die laufende Nummer selbst reicht nicht, um ein Inventar zu identifizieren, weil noch die InventarArt benötigt wird: es handelt sich also um einen schwachen Schlüssel.

Bekannte Primärschlüssel:

Neben dem schwachen Schlüssel (s.o.) wird nur bei dem Abteilungsnamen von einem Schlüsselattribut gesprochen. Andere Schlüssel sind in dieser Planungsphase nicht auszuwählen.

Entity Relationship Diagramm nach Chen

Im ganzen ergibt sich das folgende ER-Diagramm:

Transformation der Entitätstypen:

Alle sechs Entitätstypen und der Relationstyp Buchung werden zu je einem Relationenschema. Die zugehörigen Attribute werden diesen Relationssschemata zugeordnet.

Auswahl der Primärschlüssel der unabhängigen Relationenschemata

Natürliche oder gegebene Primärschlüssel gibt es nur für Abteilung, für alle anderen müssen Schlüsselattribute oder -kombinationen bestimmt (natürliche Schlüssel) oder ergänzt (künstliche Schlüssel) werden.

Im Fall des Orts und der OrtArt entscheide ich mich für die natürlichen Schlüssel der Namen. Ich gehe davon aus, das diese sich nicht ändern.

Bei der InventarArt und den Personen wähle ich einen künstlichen Schlüssel, da ich hier im Verlauf der Datenbanknutzung mit Änderungen rechne. Im Datenbankbetrieb würde das erhöhten Administrationsaufwand über den Abgleich der Fremdschlüssel verursachen.

Auswahl der Primärschlüssel der abhängigen Relationenschemata

Für Inventare als schwachen Entitätstypen wähle ich einen zusammengesetzten Primärschlüssel: die laufende Nummer (die je InventarArt eindeutig ist) und die zugehörige InventarArt über deren ID. Somit muss der Primärschlüssel der InventarArt als Fremdschlüssel in Inventar vorhanden sein und ist dort Teil des Primärschlüssels.

Im Fall der Buchungen ergibt sich aus den bestehenden Attributen ebenso ein zusammengesetzter Schlüssel: jede Buchung ist eindeutig beschrieben durch die Person, das Inventar und den Zeitpunkt. Da Inventar selbst über einen zusammengesetzter Primärschlüssel verfügt, wären hier also vier Attribute Primärschlüssel: laufendeNummer, InventarArtID, PersonID, Startzeit.

Derart viele Teilschlüssel sind in der Praxis aber sehr hinderlich. Ich entscheide mich hier also für einen künstlichen Schlüssel BuchungsID. Jedoch muss ich dann beachten, dass alle oben genannten Teilschlüsselkandidaten jeweils eingabepflichtig (NOT NULL) und in ihrer Kombination einzigartig (UNIQUE) sind.

Transformation der Relationen

• 1:n (ohne Optionalität)
  • InventarArt-Inventare (1:n)
  • Abteilung-Person (“ist in” 1:n) Der Primärschlüssel der 1-Seite wird als Fremdschlüssel in der n-Seite eingetragen. Da keine Optionalität vorliegt, muss hier der NOT NULL-Constraint ergänzt werden, damit der Fremdschlüssel nicht leer bleibt. Sofern der Fremdschlüssel wie im Fall der InventarArtID Teil des Primärschlüssels ist, ist der NOT NULL-Constraint ohnehin gegeben und muss nicht explizit genannt werden. Die zwingende Zuordnung auf der n-Seite kann im Datenmodell nicht umgesetzt werden und muss auf Applikationsseite realisiert werden. Sie ist hier nur durch die Krähenfuß-Darstellung sichtbar gemacht.
• c:nc (mit Optionalität)
  • OrtArt-Ort (1:nc)
  • Ort-Inventar (c:nc)
  • Person-Inventar (“verantwortet” 1:nc) Der Primärschlüssel der 1-Seite wird als Fremdschlüssel in der n-Seite eingetragen. Wenn auf der 1-Seite keine Optionalität vorliegt, muss hier der NOT NULL-Constraint ergänzt werden, damit der Fremdschlüssel nicht leer bleibt. Läge eine zwingende Zuordnung auf der n-Seite vor, so könnte diese im Datenmodell nicht umgesetzt werden und müsste auf Applikationsseite realisiert werden.
• nc:mc (mit Optionalität)
  • Inventar-Abteilung (nc:m)
  • Person-Inventar (“bucht” nc:mc) Hier werden jeweils neue Relationenschemata benötigt. Im Fall der Buchung wurde dies bereits oben erläutert. Bei Inventar und Abteilungen ist darauf zu achten, dass beide Teilschlüssel von Inventar in das neue Relationenschema übernommen werden und gemeinsam mit dem Abteilungsnamen den Primärschlüssel (und jeweils Fremdschlüssel) bilden. Auch hier gilt: die zwingende Zuordnung eines Invantars zu einer Abteilung kann in diesem Modell nicht gelöst werden. Sie ist hier nur durch die Krähenfuß-Darstellung sichtbar gemacht.
• 1:1 (mit und ohne Optionalität)
  • Abteilung-Person (“leitet” c:1) Da in diesem Fall auf einer Seite eine Optionalität gegeben ist, entfällt die Realisierung der 1:1-Beziehung in einem Relationenschema. Es muss also ein Fremdschlüssel bei Abteilungen eingetragen werden, der nun aber zwingend eingegeben werden muss (NOT NULL) und einzigartig sein muss (UNIQUE).

Normalisierung der Relationenschemata

• 1NF: Sind alle Attribute atomar? Das Attribut “Anschrift” ist eine Menge aus Straße, Hausnummer, PLZ, Ort. In Ausnahmefällen könnte man argumentieren, dass der Anwendungsfall lediglich einen Adressaufklebertext benötigt, daher die Aufteilung nicht weiter nötig ist. Dies ist aber eine bewusste, zu dokumentierende Entscheidung. Im Regelfall sollten die Attribute aufgeteilt werden.

• 2NF: Sind im Fall von zusammengesetzten Primärschlüssel alle Nichtschlüsselattribute vom gesamten Schlüssel abhängig? Zusammengesetzte Schlüssel existieren in den Relationsschemata Inventare und Inventare2Abteilungen. In beiden Fällen sind jedoch alle Attribute vom gesamten Primärschlüssel abhängig.

• 3NF: Folgen aus Nichtschlüsselattributen weitere Nichtschlüsselattribute? Eine solche Abhängigkeit ist nicht gegeben. Es gibt Meinungen, dass eine solche Abhängigkeit zwischen PLZ und Ort gegeben ist - aber dies trifft nicht in jedem Einzelfall zu und wird daher bewusst nicht normalisiert.

Relationenmodell

Das sich daraus ergebene logische Modell sieht wie folgt aus. Es wurden zusätzlich zu den nötigen Fremdschlüsselbeziehungen noch die Martin-(“Krähenfuß”)-notierten Beziehungen angegeben und einige Constraints per Kommentar ergänzt, da sie sich im Modell in gewohnter Darstellung nicht haben anzeigen lassen.