Quelle für diesen Abschnitt ist die aktuelle SAP Dokumentation (siehe Quellenangaben), abgerufen im Dezember 2021. Außerdem Modellfragmente, die in den 1990-er Jahren bei einer R/3-Version erhoben werden konnten. Da es nur um deren strukturelle Eigenschaften geht und nicht um die inhaltlichen, dürften sie ihre Relevanz auch behalten haben.

Im Übrigen: Jahrzehntelange Beschäftigung mit Datenbanken und Datenmodellen lehrten mich, dass die Grundlagen, z.B. die jeweiligen Modellierungsansätze, sich nur wenig über die Zeit ändern.

13.1 Das Grundkonzept

Das informationelle Gerüst eines Unternehmens wird in Datenbanken erfasst. Dem Ansatz von ERP-Software entsprechend ist es hier (oft) eine einzige, das gesamte Unternehmen und all seine Aktivitäten beschreibende Datenbank [Anmerkung] .

Eine zeitgemäße und zum Kontext dieses Textes passende Auffassung von Datenbanken ist daher die folgende: Datenbanken stellen die Informationen zur Verfügung, die für die Abwicklung der Geschäftsprozesse benötigt werden.

Beim Datenbankdesign hat man ein Modell eines bestimmten Ausschnitts der Realität zu erstellen. Dieser Weltausschnitt (in diesem Kontext wird auch oft von Anwendungsbereich gesprochen) wird in die Datenbank hinein abgebildet. Im Fall der ERP-Software von SAP besteht der Weltausschnitt somit aus dem gesamten (vorgedachten) Unternehmen.

Weltausschnitt

Die hier anstehende Frage ist die des Datenbankdesigns. Hier hat sich in den letzten Jahrzehnten in Datenbanktheorie und (eher zögerlich) Datenbankpraxis die Auffassung durchgesetzt, dass es sinnvoll ist, im ersten Schritt ein Semantisches Datenmodell zu erstellen, so wie es in den obigen Kapiteln vorgestellt wurde, und anschließend eines, das näheren Bezug zum ausgewählten Datenbanksystem hat, z.B. ein relationales.

Datenbank­design

Genauso geht auch die SAP vor, allerdings mit einer Besonderheit.

Vgl. für eine umfassende Darstellung der relationalen Theorie [Staud 2021]:

• Staud, Josef Ludwig: Relationale Datenbanken. Grundlagen, Modellierung, Speicherung, Alternativen. 2. Auflage 2021. Verlag tredition GmbH, Paperback: 978-3-347-35883-6 Hardcover: 978-3-347-35884-3 E-Book: 978-3-347-35885-0

Eine Alternative wäre die Übertragung des semantischen Modells in ein objektorientiertes. Vgl. hierzu und für eine umfassende Darstellung der objektorientierten Datenmodellierung [Staud 2019]:

• Staud, Josef Ludwig: Unternehmensmodellierung – Objektorientierte Theorie und Praxis mit UML 2.5. (2. Auflage). Berlin u.a. 2019 (Springer Gabler)

Eine solche Übertragung erfolgte aber nach Kenntnis des Verfassers nicht.

Im Kern erstellt die SAP Datenmodelle auf zwei Ebenen. Auf einer semantischen Ebene (die Methode wird SAP-SERM genannt) und auf der Ebene des Relationalen Datenmodells, im Data Dictionary.

Einordnung:
ERM
SERM
SAP-SERM

Ein Data Dictionary ist ein Verzeichnis aller Elemente einer Datenbank, sozusagen eine Metadatenbank. Zu diesen Elementen gehören, im Fall einer Relationalen Datenbank, die eingerichteten Relationen, die Attribute, die Sichten (views), die Semantischen Integritätsbedingungen (constraints) und alles andere, was das Datenmodell festlegt.

Während der relationale Ansatz bei der SAP dem Standard entspricht, weist der semantische Modellierungsansatz Besonderheiten auf. SAP-SERM ist eine Variante des oben vorgestellten SERM-Ansatzes von Sinz. SERM wiederum entstammt den Modellierungsansätzen, die zu den Entity Relationship Modellen führten. Der Entity Relationship - Ansatz wiederum ist der erfolgreichste Vertreter der Gruppe der Semantischen Datenmodelle, die in den 70er und 80er Jahren intensiv diskutiert wurden. Die wichtigste Methode davon ist die nach Chen, die in den Kapiteln 1 – 11 vorgestellt wurde.

Die folgende Abbildung verdeutlicht diesen Zusammenhang. Dabei bedeutet der erste Pfeil, dass ER-Modellierung ein Teilgebiet unter vielen der Semantischen Datenmodellierung war. Die beiden anderen Pfeile bedeuten jeweils eine Modifikation des darüber angegebenen Ansatzes.

Semantische Daten­modellierung

13.2 Die Methode SAP-SERM

Wie in der Datenbanktheorie üblich, unterscheiden auch die SAP-Modellierer eine logische und eine physische Ebene des Datenbank­designs. Mit der logischen Ebene ist (hier) das Relationale Datenmodell gemeint, die physische meint die konkreten Dateistrukturen.

Physische und
logische Ebene

Die logische Ebene wird im SAP-Sprachgebrauch mit dem Data Dictionary gleichgesetzt. In der Sprache der SAP stellt sich der Zusammenhang wie folgt dar:

„Im SAP-System wird die physische Organisation der Daten in der Datenbank überlagert durch eine logische Ebene, auf der alle Daten in einheitlicher Weise beschrieben werden. Diese logische Sicht der Daten wird im SAP Data Dictionary hergestellt und basiert auf dem relationalen Datenmodell.“ [SAP-BCDD, S. 2-1]

Inzwischen wird das SAP Data Dictionary ABAP Dictionary genannt und leistet noch einiges mehr (vgl. SAP Dokumentation, Stichwort ABAP Dictionary (https://help.sap.com/erp2005_ehp_06/helpdata/­de/cf/21ea0b446011d189700000­e8322d00/frameset.htm), Stand 8.12.2021).

Insgesamt ergeben sich damit drei Ebenen: die Semantische Ebene mit einem SAP-SERM, die logische Ebene mit einem Relationalen Datenmodell und die physische Ebene der konkreten Dateiorganisation.

Drei Ebenen

In diesem Kapitel wird im Folgenden die erste dieser Ebenen, die semantische, in ihrer SAP-spezifischen Ausprägung erläutert.

Wie in allen Entity Relationship - Ansätzen werden auch hier für die Methode SAP-SERM im ersten Schritt Objekte und Beziehungen unterschieden. Oftmals werden dafür die englischen Begriffe entity und relationship verwendet, einige Autoren des deutschsprachigen Raumes verwenden für Objekte den Begriff Entität.

Objekt,
entity,
Entität

Der Objektbegriff wird hier im allgemeinsten Sinne verwendet: alles was für die Datenbank durch Informationen beschrieben wird. Da letzteres heute noch in der Regel [Anmerkung] Attribute sind, kann obige Definition damit so formuliert werden:

Objekt im datenbanktechnischen Sinn sind alle Phänomene der Realwelt, die für die Datenbank durch Attribute beschrieben werden.

Die zentralen Begriffe für diese SAP-Variante der Datenmodellierung sind damit Entität, Beziehung und Attribut.

Attribute
Für die Zwecke dieses Abschnitts genügt folgende Definition: Ein Attribut besteht aus einer Bezeichnung und der Definition der möglichen Werte für das Attribut (Attributausprägungen). Ein einfaches Beispiel ist das Attribut Farbe mit den Ausprägungen weiß, schwarz, gelb, usw. Attribute werden irgendwelchen Informationsträgern (sie werden unten Objekte bzw. Entitäten genannt) zugeordnet. Attribute sind somit eine formale Fassung des umgangssprachlichen Eigenschafts- bzw. Merkmalsbegriffs. Vgl. für eine ausführliche allgemeine Darstellung dazu [Staud 2021, Kapitel 2] und für die ERM-spezifische hier oben Abschnitt 2.5.

In der SAP-Dokumentation finden sich folgende Definitionen:

„Eine Entität ist ein konkretes oder abstraktes Objekt (z. B. Herr Meyer, das Projekt ‘Vertriebsinformationssystem’), das sich eindeutig identifizieren lässt und für das Informationen gespeichert werden sollen. Entitäten werden nach ihren Eigenschaften in Entitätstypen eingeteilt.

Entität

Einem Entitätstyp sind Attribute zugeordnet, mit denen die Entitäten dieses Entitätstyps beschrieben werden. Die Eigenschaften von Entitäten werden durch konkrete Werte für die Attribute beschrieben.

Ein Attribut besteht aus einer Bezeichnung und der Definition der möglichen Werte für das Attribut (z. B. das Attribut Farbe mit den Werten weiß, schwarz, gelb, usw.). Ein oder mehrere Attribute sind als Schlüsselattribute ausgezeichnet. Die Werte der Schlüsselattribute identifizieren eindeutig eine Entität innerhalb eines Entitätstyps.“

Quelle: SAP-Dokumentation, Stichwort Entitätstypen (https://help.sap.com/doc/saphelp_autoid70/7.0/de-DE/22/­bd178e­460a11d188fe0000e8323d3a/content.htm?no_cache=true), abgerufen am 8.12.2021.

Auch die Beispiele, die in der Quelle angegeben werden, sind durchweg stimmig:

Der Schritt von den Entitäten zu den Entitätstypen entspricht einer Klassenbildung, wie sie oben in Kapitel 3 beschrieben wurde. Dies beschreibt die folgende Definiton besser:

Entitätstypen

„Ein Entitätstyp beschreibt eine Menge von Entitäten gleicher Eigenschaften (Attribute), besitzt einen Namen, hat Bedeutung“ [SAP-BC030, S. 3-9].

Beziehungen

Wie im ER-Ansatz üblich werden hier – neben Entitäten – auch Beziehungen betrachtet. Allerdings – gemäß dem SERM-Ansatz – in einer gegenüber dem allgemeinen ER-Ansatz eingeschränkten Form. Geht es um die Beziehungen zwischen Entitätstypen, wird von Beziehungstyp gesprochen. Dabei wird, wie in der klassischen Entity Relationship - Theorie, die Klassenbildung der Entitäten für die Beziehungen nachvollzogen.

Im Vergleich zur klassischen ER-Modellierung und entsprechend dem Ausgangspunkt SERM sind Beziehungen in diesem Ansatz wesentlich genauer gefasst und enger definiert. Sie bestehen ausschließlich zwischen jeweils zwei Entitätstypen, nicht zwischen drei oder mehr, wie es ansonsten auch möglich ist. Sie sind gerichtet und die Richtung drückt eine Hierarchie aus, was in der konventionellen ER-Modellierung nicht üblich ist. Demzufolge werden Beziehungen durch die beiden beteiligten Entitätstypen definiert. Den „vorgestellten“ nennt die SAP Start-Entitätstyp bzw. existenzunabhängigen oder referierten Entitätstyp, den nachfolgenden zweiten Ziel-Entitätstyp oder existenzabhängigen Entitätstyp.

Enge Definition von Beziehungen

In der Komponente der ERP-Software, mit der die Bearbeitung der Datenmodelle möglich ist, dem Data Modeler wird zwischen den eingehenden und ausgehenden Beziehungen eines Entitätstyps unterschieden:

Eingehende und ausgehende Beziehungen

• Eingehende Beziehung: der gewählte Entitätstyp ist in diesem Fall der Ziel-Entitätstyp (abhängige Entitätstyp) und der andere der Start-Entitätstyp (der unabhängige oder referierte Entitätstyp).
• Ausgehende Beziehung: der gewählte Entitätstyp ist in diesem Fall der Start-Entitätstyp (der unabhängige oder referierte Entitätstyp) und der andere der Ziel-Entitätstyp (abhängige Entitätstyp).

Beziehungen in SAP-SERM haben drei Eigenschaften:

• Kardinalität
• Art
• und eine betriebswirtschaftliche Bedeutung.

Mit Kardinalität der Beziehung ist das gemeint, was auch ansonsten in den attributbasierten Ansätzen gemeint ist, allerdings gibt es im SAP-SERM keine n:m - Beziehungen. Konkret werden folgende Kardinalitäten unterschieden:

Kardinalitäten – Übersicht

• 1:M - Beziehungen in der üblichen Festlegung: Eine Entität des einen Entitätstyps steht mit mehreren des anderen in Beziehung.
• 1:CM - Beziehung: Eine Entität des einen Entitätstyps steht mit keinem einem oder mehreren des anderen in Beziehung.
• 1:1 - Beziehung in der üblichen Notation: Eine Entität des einen Entitätstyps steht mit einem des anderen in Beziehung.
• 1:C - Beziehung: Eine Entität des einen Entitätstyps steht mit keinem oder einem des anderen in Beziehung.

Folgende weitere Abkürzungen werden hier benutzt: Der Buchstabe "M", der üblicherweise nur "mehr als eins" bzw. "viele" bedeutet, soll hier auch noch Pflichtfeld (mandatory), der Buchstabe "C" Optionalität (conditional) und T Zeitabhängigkeit (temporary) signalisieren.

Mandatory, Conditional, Temporary

Die folgende Abbildung zeigt die grafische Darstellung der Beziehungen. Zwischen je zwei durch Rechtecke repräsentierten Entitätstypen (vgl. unten) wird jeweils einer dieser Pfeile eingefügt:

Entitätstypen werden in SAP-SERM wie üblich durch Rechtecke mit Beschriftung dargestellt. Die Attribute der Entitätstypen werden nicht angegeben, sie können aber bei Bedarf eingesehen werden. Beziehungstypen haben hier keine Attribute im modelltechnischen Sinn. Dies ist auch naheliegend, da sie ja den Beziehungstypen der SER –Modelle entsprechen.

Die Art einer Beziehung bzw. eines Beziehungstyps kann hierarchisch, aggregierend, referentiell oder extern sein.

Art einer Beziehung

Hierarchischer Beziehungstyp

Mit dem Begriff hierarchischer Beziehungstyp ist in SAP-SERM eine Beziehung zwischen zwei Entitätstypen gemeint, bei der der Ziel-Entitätstyp existenzabhängig ist vom Start-Entitätstyp. Konkret meint dies, dass die Existenz einer Entität des Ziel-Entitätstyps abhängt von einer Entität des Start-Entitätstyps. Das folgende Beispiel mit der Kardinalität 1:CM zeigt die grafische Darstellung.

In der Sprache des SAP-SERM ist hier der Entitätstyp Fachbereiche der Start-Entitätstyp und Kurse der Ziel-Entitätstyp.

Die SAP Dokumentation gibt folgende Definition:

„Ein hierarchischer Beziehungstyp zwischen zwei Entitätstypen liegt vor, wenn gilt:

- Der Ziel-Entitätstyp ist vom Start-Entitätstyp existenzabhängig, d.h. die Lebensdauer einer Ausprägung des Ziel-Entitätstyps ist kleiner oder gleich der Lebensdauer der Ausprägung des Start-Entitätstyps.

- Der Ziel-Entitätstyp wird vom Start-Entitätstyp erzeugt, d.h. der Start-Entitätstyp hat direkten Einfluss auf die Merkmalsausprägung.

. Der Ziel-Entitätstyp stellt eine semantische Verfeinerung dar, d.h. der Ziel-Entitätstyp ist eine Gliederung des Start-Entitätstyps, die den Start-Entitätstyp näher beschreibt.

- Der Schlüssel des Start-Entitätstyps wird Teil des Schlüssels des Ziel-Entitätstyps. Die Beziehung zwischen zwei Entitäten darf nicht geändert werden.“

Quelle: SAP Dokumentation, Stichwort Beziehungen (https://help.sap.com/doc/saphelp_autoid70/7.0/de-DE/22/bd178e460a11d188fe0000e8323d3a/frameset.htm), abgerufen am 8.12.2021.

Modellierungstechnisch äußert sich dies also so, dass der Schlüssel des Start-Entitätstyps zu einem Teil des Schlüssels des Ziel-Entitätstyps wird.

Alle im Folgenden angeführten Beispiele wurden sprachlich leicht verändert (Mehrzahl bei Bezeichnungen von Entitätstypen, Länge der Attributsbezeichnungen).

Als Beispiel bringt die SAP-Dokumentation die Beziehung veranstaltet mit dem Start-Entitätstyp Fachbereiche und dem Ziel-Entitätstyp Kurse.

Der Start-Entitätstyp Fachbereiche besitzt (im Universitätsbeispiel der SAP-Dokumentation) die Attribute

Attribute

• Fachbereichsnummer (FachbNr; dieses dient auch als Schlüsselattribut) und Fachbereichsname.

Der Ziel-Entitätstyp Kurse besitzt die Attribute

• FachbNr, Kursnummer (KursNr), KursLNr (Nummer des/der KursleiterIn), Kursname. FachbNr und KursNr dienen zusammen als Schlüssel dieses Entitätstyps.

Aufpassen: In der Dokumentation wird hier Schlüssel mit Schlüsselattribut verwechselt. FachbNr und KursNr sind Teil eines zusammengesetzten Schlüssels, also Schlüsselattribute.

Die Existenzabhängigkeit wird dann in der relationalen Umsetzung durch den Fremdschlüssel FachbNr ausgedrückt (vgl. zu Fremdschlüsseln [Staud 2021, Kapitel 5.9]). Wegen der Nähe der SER-Modellierung und damit auch der SAP-SER-Modellierung zum relationalen Ansatz kann der Zusammenhang sehr anschaulich mit der relationalen textlichen Notation dargestellt werden:

Fachbereiche (#FachbNr, Fachbereichsname)

Kurse (#(FachbNr, KursNr), KursLNr, Kursname)

Dieses Beispiel erlaubt auch, nochmals den Begriff der Existenzabhängigkeit zu betrachten, der in der SAP-Terminologie eine bedeutende Rolle spielt. Hier ist die Tatsache gemeint, dass jede Ziel-Entität zu ihrer Identifikation eine Start-Entität benötigt. Im obigen Beispiel: Jeder Kurs benötigt einen Fachbereich, was durch den zusammengesetzten Schlüssel festgelegt wird.

Existenz­abhängigkeit

Die große Bedeutung ist berechtigt. Wird diese Existenzabhängigkeit modelltechnisch nicht ausreichend beachtet, gibt es datentechnische Defizite. Unverknüpfte evtl. redundante Daten „bevölkern“ die Datenbank. Die Datenbank verliert ihre Integrität.

Aggregierender Beziehungtyp

Die folgende Struktur wird Aggregierender Beziehungstyp genannt. Hier sind immer drei Entitätstypen im Spiel, zwei Start-Entitätstypen und ein Ziel-Entitätstyp. Wieder wird die Existenzabhängigkeit des Ziel-Entitätstyps vom Start-Entitätstyp als Definitionsmerkmal genannt. Hier besteht sie sogar bezüglich zweier Start-Entitätstypen. Der Ziel-Entitätstyp wird vom Start-Entitätstyp erzeugt, d.h. der Start-Entitätstyp hat direkten Einfluss auf die Merkmalsausprägung. In der SAP-Sprache:

„Ein Entitätstyp geht aus der Begriffsverknüpfung von mindestens zwei Ausgangsentitäten hervor.“ [SAP-BC030, S. 3-14]

Betrachten wir ergänzend die aktuelle Definition der SAP Dokumentation:

„Ein aggregierender Beziehungstyp zwischen zwei Entitätstypen liegt vor, wenn gilt:

- Der Ziel-Entitätstyp ist vom Start-Entitätstyp existenzabhängig, d.h. die Lebensdauer einer Ausprägung des Ziel-Entitätstyps ist kleiner oder gleich der Lebensdauer der Ausprägung des Start-Entitätstyps.

- Der Ziel-Entitätstyp wird vom Start-Entitätstyp erzeugt, d.h. der Start-Entitätstyp hat direkten Einfluss auf die Merkmalsausprägung.

- An der Bildung des Ziel-Entitätstyps ist mindestens ein zweiter Start-Entitätstyp beteiligt, der sich vom ersten Start-Entitätstyp unterscheidet.

- Die Schlüssel der Start-Entitätstypen werden Teile des kanonischen Schlüssels des Ziel-Entitätstyps.“

Quelle: SAP Dokumentation, Stichwort Beziehungen (https://help.sap.com/doc/saphelp_autoid70/7.0/de-DE/22/bd178e460a11d188fe0000e8323d3a/frameset.htm), abgerufen am 8.12.2021

Im folgenden Beispiel kann somit ein Student mehrere Kurse besuchen und ein Kurs kann mehrere Studierende haben. Zusätzlich drücken die Pfeilspitzen aus, dass die Teilnahme an den Beziehungen konditional ist.

Beispiel

In einer solchen Konstellation wird die eigentliche Beziehung, die zwischen Studenten und Kursen, durch den Schlüssel des Entitätstyps Kursbescheinigungen erfasst, der die Schlüssel von Studenten und Kurse enthält.

Hier wieder die Angabe der Entitätstypen in relationaler Notation (die Punkte deuten die Liste weiterer Attribute an):

Studierende (#StudNr, ...)

Kurse (#KursNr, ...)

Kursbescheinigung (#(StudNr, KursNr), …)

Die Schlüssel der Start-Entitätstypen werden Teile des Schlüssels des Ziel-Entitätstyps. Der einzige Unterschied zwischen dem aggregierenden und dem hierarchischen Beziehungstyp ist, dass bei letzterem zwei Start-Entitätstypen vorliegen.

Referentieller Beziehungstyp:

Beim sogenannten Referentiellen Beziehungstyp geht es um die Situation, dass im Ziel-Entitätstyp auf den Start-Entitätstyp verwiesen wird, ohne dass die Existenz des Zielentitätstyps davon abhängt. Im folgenden Prozessfragment soll z.B. erfasst werden, dass Professoren Kurse halten.

Betrachten wir die Definition der SAP-Dokumentation:

„Ein referentieller Beziehungstyp liegt vor, wenn gilt:

- Der Ziel-Entitätstyp ist vom Start-Entitätstyp existenzabhängig.

- Der Start-Entitätstyp legt den Kontext des Ziel-Entitätstyps fest, d.h. eine Attributgruppe des Start-Entitätstyps ist im Ziel-Entitätstyp vorhanden, die den Ziel-Entitätstyp jedoch nicht erzeugt.

- Die Schlüsselattribute des Start-Entitätstyps werden als Nicht-Schlüsselattribute in den Ziel-Entitätstyps übernommen. Eine Beziehung zwischen zwei Entitäten darf geändert werden.

Beispiel

- Zwischen den Entitätstypen Professoren (Start-Entitätstyp) und Kurse (Ziel-Entitätstyp) besteht die Beziehung ist Leiter von mit der Kardinalität 1:CN.

- Der Start-Entitätstyp Professoren besitzt die Attribute Nummer (Schlüsselattribut), Name, Adresse und Besoldungsklasse.

- Der Ziel-Entitätstyp Kurse besitzt die Attribute Fachbereichsnummer (Schlüsselattribut), Kursnummer (Schlüsselattribut), Nummer des/der KursleiterIn und Kursname.“

Quelle: SAP Dokumentation, Stichwort Beziehungen (https://help.sap.com/doc/saphelp_autoid70/7.0/de-DE/22/bd178e460a11d188fe0000e8323d3a/frameset.htm), abgerufen am 8.12.2021.

Die Schlüsselattribute des Start-Entitätstyps werden also als Nicht-Schlüsselattribute in den Ziel-Entitätstyp übernommen.

Zur Verdeutlichung die Umsetzung des Zitatbeispiels in die relationale Notation (mit angepassten Bezeichnungen).

Professoren (#ProfNr, Name, Adresse, Besoldungsklasse)

Kurse (#(FachbNr, KursNr), KursLNr, Kursname)

Anmerkung: Kurse gab es bereits, siehe oben. Das „neue Thema“ betrifft nur die Kursleitung (ist Leiter von). Die Relation wird also ergänzt.

Die Beziehung ist_Leiter_von drückt sich darin aus, dass das Attribut KursLNr (Kursleiter/in-Nummer) Fremdschlüssel ist. Die Realisierung der Beziehung im Beispiel bedeutet, dass jeder Kurs eine/n Kursleiter/in hat, dass aber die Professoren nicht unbedingt Kurse abhalten müssen.

Die folgende Abbildung stellt den Zusammenhang „Beziehungstypen und Existenzabhängigkeit“ dar.

Quelle: SAP Dokumentation, Stichwort Beziehungen (https://help.sap.com/doc/saphelp_autoid70/7.0/de-DE/22/bd178e460a11d188fe0000e8323d3a/frameset.htm), abgerufen am 9.12.2021

Bei der Existenzabhängigkeit wird in der SAP-SER-Modellierung somit unterschieden zwischen starker und schwacher Existenzabhängigkeit. Bei der starken Existenzabhängigkeit wird gefordert, dass für jede Ausprägung des Ziel-Entitätstyps eine Zuordnung zu genau einer Ausprägung des Start-Entitätstyp vorhanden sein muss. Gilt diese Bedingung nur für eine (zeitabhängige) Teilmenge des Ziel-Entitätstyps, so spricht man von schwacher Existenzabhängigkeit [ebenda].

Starke und schwache Existenz­abhängigkeit

Mit dem nun eingeführten Begriff der Abhängigkeit zwischen den Entitätstypen bzw. Entitäten können die Kardinalitäten neu formuliert werden. Die n:m - Beziehungen ergeben sich damit wie folgt:

Neu­interpretation

• n = 1, also 1:m
  Zu jeder abhängigen Entität gibt es genau eine unabhängige Entität.
• n = C, also C:m
  Es kann Entitäten des abhängigen Entitätstyps geben, die keine Beziehung zu einer Entität des Start-Entitätstyps besitzen.
• m = 1, also n:1
  Zu jeder Entität des Start-Entitätstyps gibt es genau eine abhängige Entität.
• m = C, also n:C
  Zu jeder Entität des Start-Entitätstyps gibt es höchstens eine abhängige Entität.
• m = N, also n:N
  Zu jeder Entität des Start-Entitätstyps gibt es mindestens eine abhängige Entität.
• m = CN, also m:CN
  Zu jeder Entität des Start-Entitätstyps gibt es beliebig viele abhängige Entitäten.

Die Kardinalitäten C:1, C:C, C:CN und C:N sind vor allem bei referentiellen Beziehungen sinnvoll. Möglich sind sie auch bei aggregierenden Beziehungen, nicht aber bei hierarchischen, da hier verlangt ist, dass alle abhängigen Entitäten eine Entität des Start-Entitätstyps referieren müssen, d.h., dass es zu jedem Entitätstyp des abhängigen Entitätstyp eines im unabhängigen Entitätstyp gibt.

Externe Beziehungen. Eine Beziehung wird in SAP-SERM extern genannt, wenn sie zwischen einem Entitätstyp innerhalb eines Datenmodells und einem Entitätstyp außerhalb dieses Datenmodells besteht.

Generalisierung / Spezialisierung

Alle attributbasierten Datenbankansätze tun sich schwer mit folgender (oben schon besprochener) Situation (in der Sprache des SAP-SERM-Ansatzes): Ein Entitätsyp ET1 hat bestimmte Attribute, sagen wir A1, ..., A5. Andere Entitätstypen haben dieselben Attribute aber zusätzlich noch einige mehr. ET2 z.B. A6 und A7 und ET3 die Attribute A8, A9, A10. Insgesamt also:

Vgl. auch Abschnitt 5.1

ET1: A1, A2, A3, A4, A5

ET2: A1, A2, A3, A4, A5, A6, A7

ET3: A1, A2, A3, A4, A5, A8, A9, A10

Wie soll eine solche Situation modelliert werden? Sie drückt ja eigentlich Ähnlichkeit im Sinne des attributbasierten Ansatzes aus: Die Entitätstypen haben viele Attribute gemeinsam, einige wenige nicht.

In den ER-Ansätzen wurde für diese Situation schon sehr früh das Konzept der Generalisierung / Spezialisierung entwickelt (vgl. Abschnitt 5.1). Es gibt einen „allgemeinen“ Entitätstyp, die Generalisierung, (im obigen Beispiel ET1) und die Spezialisierungen (im obigen Beispiel ET2 und ET3). ET1 ist dann die Generalisierung der beiden Spezialisierungen. Die semantische Datenmodellierung, zu der ja auch SAP-SERM gehört, drückt sich damit um die Frage der konkreten Speicherung solcherart erfasster Daten (ist ja auch nicht ihre Aufgabe) und verlagert diese in die logische Modellierung und physischepn Speicherung.

Doch nun hierzu ein Beispiel aus dem Universitätsdatenmodell der SAP, der Anschaulichkeit wegen auch in relationaler Notation. Der allgemeine Entitätstyp seien alle Hochschulangehörige. Ihre Attribute seien eine MitarbNr, ihr Name und weitere. Eine der Spezialisierungen seien Studierende mit den Attributen StudNr, BetrProf (BetreuenderProfessor) und Studienbeginn. Eine andere Spezialisierung seien die Professoren mit folgenden Attributen:

Universitäts­datenmodell

#ProfNr, Name, Adresse, Besoldungsklasse.

Ein zugegeben einfaches Modell, das aber ausreicht, dieses Konzept nochmals zu verdeutlichen. Insgesamt ergeben sich damit folgende Attribute (in relationaler Notation), wenn bei den Spezialisierungen die Attribute der Generalisierung weggelassen werden:

Hochschulangehörige (#MitarbNr, Name, …)

Studierende (#StudNr, BetrProf, Studienbeginn)

Professoren (#ProfNr., Name, Adresse, Besoldungsklasse)

Wegen der Generalisierung / Spezialisierung gilt: Die Menge der Ausprägungen von MitarbNr umfasst die Ausprägungen von StudNr und ProfNr und kann noch weitere Ausprägungen enthalten.

Die grafische Notation in SAP-SERM zeigt die folgende Abbildung. Der Schlüssel der Generalisierung wird, wie auch im obigen Beispiel, in die Spezialisierungen übernommen. Dabei kann er umbenannt werden.

Spezialisierungen können unterschiedlich strukturiert sein. Liegt eine Situation vor, in der sich die Spezialisierungen nicht überlappen, keine Entität also in mehr als einer Spezialisierung vorkommt, dann spricht man von einer disjunkten Spezialisierung. Die obige dürfte mit Sicherheit disjunkt sein, da eine Person üblicherweise entweder Studierender oder Professor/in ist.

Eigenschaften einer Spezialisierung

Eine weitere Eigenschaft von Spezialisierungen betrifft die Frage, ob alle Entitäten der Generalisierung in die Spezialisierungen eingehen. Ist dies der Fall, bezeichnet man die Spezialisierung als vollständig. Obige Spezialisierung ist mit Sicherheit nicht vollständig, da es noch andere Personen außer Studierenden und Professoren an einer Universität gibt.

Generalisierungen/Spezialisierungen müssen im Übrigen weder disjunkt noch vollständig sein. Diese beiden Eigenschaften von Spezialisierungen sind keine Besonderheit des SAP-SERM, sondern entstammen der allgemeinen ER-Modellierung (vgl. Abschnitt 5.1)

13.3 Zusammen­fassendes Modellierungs­beispiel

Die folgende Abbildung zeigt ein Beispiel, das weitgehend dem Universitäts-Beispiel der SAP-Unterlagen entstammt und das die oben angeführten Modellfragmente enthält. Es wurde nach den Data Dictionary-Modellfragmenten in [SAP-BC030] und den Hinweisen in der aktuellen SAP Dokumentation erstellt.

Die einzelnen Beziehungen wurden mit Nummern markiert. (1) und (2) stellen eine Generalisierung / Spezialisierung dar (wie oben schon gesehen). Sie bedeutet: Hochschulangehörige sind (hier) entweder Professoren oder Studierende. Konkrete Bedeutung: Hochschulangehörige haben bestimmte Attribute gemeinsam, die im gleichnamigen Entitätstyp erfasst werden. Professoren und Studierende haben jeweils noch spezifische Attribute, die bei ihrem Entitätstyp angeordnet sind.

Vgl. Abbildung 13.3-2 für das entsprechende relationale Modell

Bei der späteren Übertragung in relationale Strukturen (vgl. Abbildung 13.3-2) bedeutet ein Generalisierungs-/Spezialisierungsverhältnis, dass die Relationen durch 1:1 - Beziehungen verknüpft sind, so dass die Beziehung (1) konkret bedeutet:

• Ein Universitätsangehöriger kann ein Professor sein, muss es aber nicht.
  Auf Datenebene: Ein Tupel der Relation Mitarbeiter kann mit höchstens einem Tupel von Professoren verknüpft sein, muss es aber nicht.

Entsprechend bedeutet die Beziehung (2):

• Ein Mitarbeiter kann ein Studierender sein, muss es aber nicht.
  Auf Datenebene: Ein Tupel der Relation Mitarbeiter kann mit höchstens einem Tupel von Professoren verknüpft sein, muss es aber nicht.

Solche 1:1 - Beziehungen werden in Relationalen Datenmodellen dadurch gelöst, dass der Schlüssel der „übergeordneten“ Relation auch als Schlüssel in der „untergeordneten“ benutzt wird. In der Sprache der relationalen Theorie wird hier sozusagen der Fremdschlüssel zum Schlüssel, was ja üblicherweise nicht der Fall ist. Vgl. die ausführliche Darstellung hierzu in [Staud 2021, Kapitel 5].

Doch nun zurück zur semantischen Modellierung. Die Beziehung (3) zwischen Professoren und Studierende drückt in diesem Datenmodell ein Betreuungsverhältnis aus. Ein Professor kann keinen oder mehrere Studierende betreuen. Im relationalen Sinn handelt es sich dabei um eine 1:n - Beziehung, die durch einen Fremdschlüssel (hier ProfNr) in Studierende erfasst wird. In der SAP-Notation wird allerdings dieser Fremdschlüssel noch näher spezifiziert. Die Angabe OPT legt ihn als optionalen Fremdschlüssel fest, was hier bedeutet, dass der Fremdschlüssel in Studierende keinen Eintrag haben muss, z.B. wenn der jeweilige Studierende gerade nicht betreut wird. Hier müssen also bewusst semantisch bedingte Leereinträge in Kauf genommen werden.

Betreuung

In der korrekten relationalen Notation müsste dies durch eine eigene Relation Betreuungsverhältnis gelöst werden, die nur konkrete Betreuungsverhältnisse erfasst. Vgl. [Staud 2021, Kapitel 5].

Die Beziehung (4) drückt aus, dass ein Professor keinen, einen oder mehrere Kurse hält. Wieder handelt es sich um eine 1:n - Beziehung, die erfasst wird, indem in Kurse als Fremdschlüssel die ProfNr genommen wird. Aber auch hier spezifiziert dieser Ansatz etwas genauer: OBL macht den Fremdschlüssel zu einem obligatorischen, was hier bedeutet, dass bei jedem Kurs ein Professor eingetragen sein muss.

Lehre

Nach der relationalen Theorie wäre dieser Fremdschlüssel auf jeden Fall zu befüllen („referentielle Integrität“).

Beziehung (5) legt fest, dass Professoren Publikationen (die in der Datenbank erfasst sind) haben oder auch nicht. Der Zusatz ID legt wiederum fest, dass es sich in Publikationen um einen identifizierenden Fremdschlüssel handelt. Diese Beziehung kann auch anders herum beschrieben werden: Eine Publikation kann dann in die Datenbank aufgenommen werden, falls sie von einem in ihr erfassten Professor stammt und dann muss dieser auch angegeben werden.

Publikationen

Die Beziehungen (6) und (7) zeigen, wie in diesem Ansatz n:m - Beziehungen (Verbindungsrelationen im relationalen Sinn, vgl. [Staud 2021, Kapitel 5]) erfasst werden. Die n:m - Beziehung besteht zwischen Kurse und Studierende: Ein Kurs kann mehrere Studierende haben, ein Studierender kann mehrere Kurse besuchen.

n:m - Beziehungen

Standardmäßig wird im Entity Relationship - Ansatz eine solche Beziehung als Beziehungstyp angelegt, kann mit Attributen versehen werden und taucht in der grafischen Notation als Raute auf. Im Relationalen Modell muss eine solche Beziehung mit drei Relationen gelöst werden, wovon eine die eigentliche Verknüpfung widerspiegelt (die Verbindungsrelation).

Im SAP-SERM wird die gesamte Beziehung in zwei 1:n - Beziehungen aufgelöst. Kursteinahme stellt die eigentliche Verknüpfung dar. Dieser Entitätstyp muss die Schlüssel aus Kurse (KursNr) und Studierende (StudNr) enthalten. Diese beiden sind dort zusammen Schlüssel, vgl. das relationale Modell unten. Dieses Beispiel macht deutlich, dass SAP-SERM, genauso wie SERM, näher am Relationalen Ansatz ist als an der klassischen Entity Relationship - Modellierung.

SAP-SERM: nahe an RM

Doch zurück zum SAP-Sprachgebrauch: Beziehung (6) hält fest welcher Studierende an welchem Kurs teilnimmt, indem in Kursteilnahme der Schlüssel des Studierenden als Fremdschlüssel auftaucht. ID legt wiederum fest, dass dieser Fremdschlüssel eingetragen werden muss (identifizierender Fremdschlüssel). Entsprechendes gilt für Beziehung (7), nur dass hier verlangt wird, dass jeder Kurs tatsächlich auch in Kursteilnahme erscheint: Jeder Kurs muss in mindestens einem Tupel von Kursteilnahme erscheinen. Seine KursNr erscheint dort in der relationalen Umsetzung als Fremdschlüssel und Teil des Schlüssels.

Kursbesuch

Beziehung (8) beschreibt den Zusammenhang zwischen Fachbereiche und Kurse. Jeder Fachbereich muss bei mindestens einem Kurs auftreten und wird dort als identifizierender Fremdschlüssel erfasst. Es werden also z.B. Fachbereiche erst erfasst, wenn dort mindestens ein Kurs veranstaltet wird.

Organisation

Beziehung (9) hält fest, dass es zu Kursen auch Kursbeschreibungen gibt. Ein Kurs kann keine, eine oder mehrere Kursbeschreibungen haben.

Beschreibung

Auf die Darstellung der Abhängigkeiten durch Anordnung der Entitätstypen wurde hier verzichtet.

Zum Vergleich nun dasselbe Datenmodell in der standardmäßigen relationalen Notation mit den oben angeführten Attributen. Zuerst die textliche Notation:

Fachbereiche (#FachbNr, Fachbereichsname)

Hochschulangehörige (#MitarbNr, Name, …)

Kursbescheinigung (#(StudNr, KursNr), …)

Kursbeschreibung (#KursbeschrNr, …)

Kurse (#(FachbNr, KursNr), KursLNr, Kursname)

Kursteilnahme (#(StudNr, KursNr), …)

Professoren (#ProfNr, Name, Adresse, Besoldungsklasse)

Publikationen (#PublikNr, …)

Studierende (#StudNr, BetrProf, Studienbeginn)

Damit ergibt sich das folgenden Abbildung graphische Datenmodell. Die Nummern an den relationalen Beziehungen entsprechen denen in der obigen Abbildung.

Es gilt:

ProfNr ist Teilmenge von MitarbNr

StudNr ist Teilmenge von MitarbNr

Wie durch den direkten Vergleich zu erkennen ist, kann die Übertragung – nicht überraschend – sehr direkt vorgenommen werden. Je Entitätstyp entsteht eine Relation, die Beziehungstypen geben Hinweise auf die notwendigen relationalen Verknüpfungen. Die konkrete Realisierung hängt auch von den Angaben zu Pflicht- und optionalen Attributen ab (OPT, OBL, ID; vgl. oben).

Zur Abrundung zeigt die folgende Abbildung nun noch das Datenmodell in der klassischen ER-Notation. Als Schlüssel wurden die des relationalen Datenmodells genommen. Die Ellipsen mit Punkten deuten die zusätzlichen deskriptiven Attribute an.

Soweit die Darstellung der SAP-Technik zur Semantischen Datenmodellierung (SAP-SERM), auch im Vergleich mit relationaler und ER-Modellierung. Im folgenden Abschnitt werden einige (sehr kleine) Ausschnitte aus konkreten SAP SERM - Datenmodellen angegeben.

13.4 Beispiele mit Erläuterungen

Die Kennzeichnung des Ansatzes mit dem Begriff strukturiert geht auf den SERM Ansatz von Sinz (vgl. Kapitel 12) zurück. Die Eigenschaft „strukturiert“ bedeutet, dass die Anordnung der Entitätstypen auf der Grafik durch ihren Abhängigkeitsgrad vorgegeben ist. Sind zwei Entitätstypen über eine Beziehung oder eine Spezialisierung miteinander verbunden, so steht der Start-Entitätstyp (der unabhängige) immer links vom Ziel-Entitätstyp (dem abhängigen).

Aufbau der Grafiken

Entsprechend der ER-Modellierung werden auch hier Entitätstypen durch Rechtecke dargestellt, in deren Mitte die Bezeichnung des Entitätstyps steht (vgl. die folgende Abbildung). Attribute werden in der Grafik nicht angegeben, sie können aber jederzeit durch Zugriff auf das Data Dictionary ausgegeben werden. Im Gegensatz dazu wird eine eventuelle Zeitabhängigkeit eines Entitätstyps durch ein Oval an der linken unteren Ecke des Entitätstyps direkt in der Grafik angegeben [SAP Hilfe 1]. Vgl. hierzu die Abbildungen 13.4-3 und 13.4-4.

Entitätstypen

Jeder Entitätstyp hat zusätzlich noch eine identifizierende Nummer. Diese steht im linken oberen Feld des Rechtecks. Rechts oben im Rechteck befinden sich zwei kleinere Felder, die nichts direkt mit der Modellierung zu tun haben. Links steht das Customizing-Kennzeichen, das rechte gibt Auskunft über die Art der Zuordnung zum Data Dictionary.

Das Feld für das Customizing-Kennzeichen kann die folgenden Werte annehmen:

Customizing

Das Feld für die Art der Dictionary-Zuordnung kann die folgenden Werte annehmen:

Die folgende Abbildung zeigt ein Beispiel, den Entitätstyp Einkaufskontrakt, nach dem auch das gesamte Datenmodell benannt ist, aus dem er stammt. Dieses ist weiter unten angegeben (vgl. Abbildung 13.4-2.3-2).

Beziehungen werden in den Grafiken als Linien angegeben. Die Bezeichnung der Beziehung ist unter der Linie angeordnet, die Art der Beziehung über der Linie. Folgende Beziehungsarten können angegeben werden:

Beziehungen

Kardinalitäten werden, wie oben schon gesehen, durch die Gestaltung der Pfeilspitzen verdeutlicht. Unterschieden wird die rechte und die linke Seite der Kardinalität. Da es sich immer um Beziehungen vom Start-Entitätstyp zu einem Ziel-Entitätstyp handelt, genügt die Festlegung der rechten Seite. Folgende Symbole werden verwendet:

Kardinalitäten

Die Positionierung in der Abbildung gibt ebenfalls Hinweise auf die Art der Beziehung: „Hierarchische und aggregierende Beziehungen münden von links ein, referentielle Beziehungen von oben oder von unten“ [SAP Hilfe 1].

Für die grafische Darstellung einer Generalisierung / Spezialisierung gilt: Der generalisierte Entitätstyp wird immer links von den spezialisierten Entitätstypen angeordnet. Von der Generalisierung führt eine blaue Linie zu jeder der Spezialisierungen. Ein blaues Dreieck (im Original, hier wurde die Farbgebung beseitigt), sozusagen links von allen Spezialisierungen, signalisiert die Generalisierung / Spezialisierung. Vgl. hierzu die Beispiele in den Abbildungen unten.

Generalisierung/ Spezialisierung

Die Datenmodelle einer umfassenden ERP-Software müssen naturgemäß sehr groß sein. Deshalb werden, um auch bei Ausgabe mehrerer Datenmodelle den Überblick zu bewahren, die einzelnen Datenmodelle in farbig gekennzeichnete Rechtecke gepackt. Diese musste aus grafischen Gründen bei der Nachbearbeitung der SAP-SERM-Datenmodelle für diese Arbeit beseitigt werden. In diesen Rechtecken steht in der linken oberen Ecke die Kurzbeschreibung des Datenmodells (hier immer angegeben).

Das erste Beispiel in der folgenden Abbildung zeigt ein sehr kleines Datenmodell zum Thema Einkaufskontrakt.

Bedeutung der Abkürzungen an den Beziehungen:

A: aggregierende Beziehung

H: hierarchische Beziehung

Es verdeutlicht die im Datenmodell vorgedachte Strukturierung (Aufteilung der Information) in Einkaufskontrakte, Einkaufskontrakt­positionen und Abrufdokumentationen. Wie zu sehen ist, muss es Einkaufskontraktpositionen geben, was für die Abrufdokumentationen nicht gilt. Außerdem ist in diesem Fragment angedeutet, dass der Entitätstyp Einkaufskontraktposition eine Generalisierung anderer Entitätstypen ist.

Die folgende Abbildung zeigt ein wiederum sehr einfaches Datenmodell zum Thema Qualifikation, bei dem der Zeitaspekt mitmodelliert wurde.

Bedeutung der Abkürzung an den Beziehungen:

A: aggregierende Beziehung

Ein etwas größeres Datenmodell zeigt die folgende Abbildung zum Weltausschnitt Bestellung. Hier sind auch Generalisierungen integriert. Zum einen zum Entitätstyp Bestellung selbst, der in Lieferantenbestellung und Umlagerungs­bestellung spezialisiert wird. Zum anderen zum Entitätstyp Bestellpositionskondition(en), die in solche mit den Zusätzen „mit Stamm“ und „individuell“ differenziert werden.

Customizing der Datenstrukturen

Bedeutung der Abkürzungen an den Beziehungen:

CR: konditionell-referentiell

H: hierarchische Beziehung

Neben den Beziehungen mit optionalem Charakter gibt es in diesen Datenmodellen durchaus auch welche, die vorliegen müssen. Wie der Abbildung entnommen werden kann, kann es zu einer Bestellung Gesamtkonditionen geben, während zu einer Bestellgesamtkondition einzelne Bestellpositionskonditionen vorhanden sein müssen. Außerdem muss es zu einer Bestellung Bestellpositionen geben (ist ja auch naheliegend) und zu letzteren Bestellpositions-Einteilungen.

Vgl. für weitere Beispiele von SAP SERM – Modellen [Staud 2005, Abschnitt 6.3].

Soweit die kurze Betrachtung der SAP-spezifischen Semantischen Mo­dellierung. Solche Semantischen Datenmodelle beschreiben in der Regel recht gut den jeweiligen Weltausschnitt. Sie müssen aber, geht es um die Realisierung konkreter Datenbanken, in Strukturen abgebildet werden, die näher an der physischen Datenorganisation [Anmerkung] in Dateien liegen. Im Datenbankbereich wird dies sehr häufig mit einer Abbildung des Semantischen Datenmodells in ein Relationales Datenmodell realisiert. Der Grund ist, dass Relationale Datenmodelle näher an der konkreten Dateiorganisation sind: Bei vielen Datenbanksystemen entspricht eine Relation einer Datei, zumindest aber sind Relationale Datenbanksysteme in der Lage, Relationen aufzunehmen und so zu verwalten, dass die Nutzer mit der kon­kreten physischen Datenstruktur nur noch wenig zu tun haben.

Physische Ebene

Deshalb kommen auch bei SAP an dieser Stelle in der Dokumentation die relationalen Datenbanken und ihre Terminologie mit ins Spiel. Die konkrete Datenbank, auf der die Datenbanksysteme der ERP-Systeme von SAP agieren, ist immer relational. Dies gilt natürlich unabhängig davon, welches Datenbanksystem gewählt wurde. Konkret geht es an dieser Stelle dann immer darum, Semantische Datenmodelle in relationale abzubilden, ganz allgemein (das wird hier betrachtet) und auch zugeschnitten auf die spezifischen Besonderheiten des jeweils gewählten Datenbanksystems (dies ist nicht Gegenstand dieses Textes).

ERP mit Relationalen Datenbanken

Wie oben schon angemerkt, sehen die SAP-Modellierer diese physische Datenbankebene in einem engen Zusammenhang mit dem Data Dictionary der Datenbank:

Data Dictionary

„Das Data Dictionary ist eine zentrale Informationsquelle über die Daten eines Unternehmens“ [SAP-BCDD, S. 1-1].

Die SAP bezeichnet ihr Data Dictionary darüber hinaus als ein integriertes, womit sie ausdrücken möchte, dass ihr Data Dictionary vollständig in die Entwicklungsumgebung eingebettet ist. Es ist weiterhin ein aktives, weil es automatisch erfasste oder geänderte Informationen bereitstellt für „aktuelle Laufzeitobjekte, Datenintegrität, Datenkonsistenz und Datensicherheit“ [SAP-BCDD, S. 1-3].

Vgl. für eine umfassende Darstellung der SAP-Sicht auf das Thema Data Dictionary den Text von Tanmaya Gupta: An Overview on Data Dictionary, abrufbar mit:

https://archive.sap.com/kmuuid2/20472533-1846-2d10-77a0-c2ab8cdb78ed/­An%­20Overview%20on­%20Data%20Dictionary.pdf. Zuletzt abgerufen im Dezember 2021.

Als Funktionen des Data Dictionary werden angegeben [SAP-BCDD, S. 1-4]:

• Verwaltung von Datendefinitionen (Metadefinitionen). Zentrale Beschreibung der im Informationssystem verwendeten Daten.
• Bereitstellung von Informationen für Auswertungen. Es liefert Informationen über die Beziehungen zwischen den Datenobjekten.
• Unterstützung der Softwareentwicklung
• Performance-Optimierung

Insgesamt liegt hier somit, was die Beschreibung und Erfassung der informationellen Struktur der Unternehmen angeht, die in der folgenden Abbildung skizzierte Situation vor.

Vom Modell zu den Daten

Zuerst entsteht das oben beschriebene Semantische Datenmodell. Dieses wird in relationale Strukturen abgebildet, was zu einem Meta-Datenmodell im Data Dictionary führt, das umfassend das gesamte informationelle Gerüst beschreibt. Dieses wird dann in einem konkreten Datenbanksystem in eine Datenbank umgesetzt.

Gesamt­einschätzung SAP SERM

In diesem Abschnitt konnten die semantischen Modellierungstechniken der SAP nur skizziert werden. Trotzdem sollte deutlich geworden sein, dass es sich um sehr ausgefeilte Techniken handelt, die eine den hohen Anforderungen entsprechende semantische Modellierung erlauben. Man merkt diesen Ansätzen die wohltuende Wirkung der hohen praktischen Anforderung an.

Dass diese Methode, aufbauend auf der Methode SERM von Sinz, sehr stark von der relationalen Theorie geprägt ist und eigentlich zwischen semantischer und relationaler Modellierung angesiedelt ist, kann man den Autoren nicht übelnehmen. Erstens weil das letztendlich zu realisierende logische Datenmodell ein relationales ist und zweitens, weil sie ein Ergebnis vorlegen mussten, das in der Praxis effizient eingesetzt werden kann.

Auch nach den Erfahrungen des Verfassers ist ein SERM oder SAP SERM leichter in eine logische (hier: relationale) Datenbank umsetzbar, als ein ERM. Insbesondere die Möglichkeit der Anordnung nach Abhängigkeiten (von links nach rechts) und die damit erfolgte Klärung der Fremdschlüsselarchitektur ist sehr hilfreich. Sie erlaubt eine rasche Übernahme und die Vermeidung von Fehlern.

Vgl. dazu den Unterpunkt Diskussion beim Wikipedia-Eintrag Structured-Entity-Relationship-Modell.