Vgl. zu dieser Methode auch den Wikipedia-Eintrag „Structured-Entity-Relationship-Modell“. |
|
Sinz schlägt in seiner Erweiterung des Entity Relationship - Ansatzes (vgl. [Sinz 1990]) einige Veränderungen vor, die praktische Bedeutung gewannen und die zu sog. Strukturierten Entity Relationship - Datenmodellen (SERM) führten. Besondere Bedeutung gewann dieser Ansatz, weil die semantische Datenmodellierung der SAP auf diesem Ansatz aufbaut(e). |
Von ERM zu SERM |
|
|
12.1 Grundkonzepte |
|
Dieser Modellierungsansatz geht von den üblichen ER-Konzepten aus, wie sie oben dargestellt wurden. Es entstehen also graphisch ausgedrückte semantische Modelle mit Elementen (die Informationen erfassen) und Beziehungen zwischen diesen. Die Beziehungen haben ebenfalls Wertigkeiten, dafür werden aber hauptsächlich die Min-/Max-Angaben und nicht die Kardinalitäten genutzt. |
|
Für dieses Kapitel gilt: Wenn es um ER-Modelle geht, wird die in den obigen Kapiteln eingeführte Begrifflichkeit und grafische Notation verwendet, wenn es um strukturierte ER-Modelle geht, die von Sinz. |
Hinweis |
Die Begriffe |
|
ER-Modellierung |
Strukturierte ER-Modellierung |
Entitätstyp |
Entity-Typ (E-Typ) |
Kombinierter Typ 1 |
Relationship-Typ (R-Typ) |
Kombinierter Typ 2 |
Entity Relationship - Typ (ER-Typ): Entity-Typ + Relationship-Typ |
|
|
Min-/Max-Angabe |
Komplexitätsgrad |
| |
Für die Schreibweise einer Min-/Max-Angabe gilt: 0,n in Entity Relationship - Modellen, (0,*) in der SER-Modellierung.
|
|
Unter Hinweis auf die gegenüber Kardinalitäten höhere Aussagekraft der Min-/Max-Angaben definiert Sinz vier Grundtypen von Komplexitätsgraden: (0,1), (0,*), (1,1), (1,*). Der Stern steht in dieser Notation für „mehrere“. |
|
N:m - Beziehungen werden in zwei 1:n - Beziehungen aufgelöst, so dass er in Bezug auf ein Universitätsbeispiel schreiben kann: |
Zwei mal
1:n
statt n:m |
"Zwischen Studierenden und Vorlesungen liegt sicherlich – z.B. in einem Universitätsdatenmodell – eine n:m - Beziehung vor, da ein Studierender mehrere Vorlesungen besucht und eine Vorlesung von mehreren Studierenden besucht wird." [Sinz 1990] |
|
Betrachten wir ein Beispiel. |
|
|
|
|
Abbildung 12.1-1: |
Min-/Max-Angaben mit der Methode SERM |
|
|
|
Hier wurde festgelegt, dass ein Studierender tatsächlich auch mal (in einem Semester) keine Vorlesungen hören, dass er aber auch beliebig viele besuchen kann. Umgekehrt wird festgelegt, dass eine Vorlesung von mindestens 5 Studierenden besucht werden muss, dass diese Zahl aber auch höher sein kann. |
|
Jede solche n:m - Beziehung wird in diesem Ansatz in zwei 1:n - Beziehungen zerlegt, was im Folgenden gezeigt wird. |
|
Sinz weist richtig darauf hin, dass alle "normalen" Varianten und Erweiterungen des ERM "bipartite Graphen" darstellen, während sein Ansatz SERM einen "quasi-hierarchischen Graph" darstellt. Auch dies wird im weiteren erläutert. Die Begriffe Knoten und Kanten, die hier hin und wieder benutzt werden, stammen aus der Graphentheorie. |
Vgl. für eine Einführung in die Graphentheorie [Diestel 2017] |
Gehen wir für die weiteren Ausführungen von der Darstellung und Notation in [Sinz 1990] aus, wie sie die folgende Abbildung zeigt. |
|
|
|
|
Abbildung 12.1-2: |
Darstellung und Notation bei Sinz |
|
|
|
Sinz bezeichnet die Kardinalität zwischen A und B mit b(A,B) und die Min-/Max-Angaben mit Komplexitätsgrad comp(A,b) bzw. comp(B,b). Er kommt dann bezüglich der möglichen Komplexität der Beziehung b(A,B) zu folgender Tabelle: |
|
Komplexitätsgrade und Kardinalitäten |
|
b(A,B) |
comp(A,b) |
comp(B,b) |
1:1 |
(0,1) oder (1,1) |
(0,1) oder (1,1) |
1:N |
(0,*) oder (1,*) |
(0,1) oder (1,1) |
N:1 |
(0,1) oder (1,1) |
(0,*) oder (1,*) |
M:N |
(0,*) oder (1,*) |
(0,*) oder (1,*) |
| |
Betrachten wir als Beispiel die zweite Zeile genauer unter Bezugnahme auf die obige Grafik. Die Kardinalität 1:n umfasst tatsächlich die angegebenen Fälle:
|
|
- comp(A,b)=(0,*) bedeutet, dass ein Objekt von A nicht an der Beziehung teilhaben muss, dass es aber auch an mehreren Beziehungen teilhaben kann.
- comp(A,b)=(1,*) bedeutet, dass jedes Objekt von A mindestens eine Beziehung eingeht, dass es aber auch an mehreren Beziehungen teilhaben kann.
- comp(B,b)=(0,1) bedeutet, ein Objekt von B nicht an der Beziehung teilhaben muss und falls dies doch der Fall ist, mit maximal einer Beziehung.
- comp(B,b)=(1,1) bedeutet, dass jedes Objekt von B genau eine Beziehung eingeht.
|
|
12.2 Existenzabhängigkeit |
|
Mit Hilfe dieses Konzepts definiert er nun Existenzabhängigkeiten. Er greift dabei auf das Konzept der referentiellen Integritätsbedingungen (vgl. [Staud 2021, Abschnitt 5.2]) der relationalen Datenmodellierung zurück. Dabei werden |
|
"... in einer Beziehung b(A,B) Existenzabhängigkeiten nicht zwischen den Entity-Typen A und B, sondern zwischen dem Relationship-Typ b und einem Entity-Typ angegeben. Während A und B nicht notwendig voneinander abhängen, hängt b stets von A und B ab." [Sinz 1990] |
|
Damit kommt er zu zwei Formen der Existenzabhängigkeit eines Relationship-Typs b von einem Entity-Typ E (vgl. die folgende Grafik): |
|
- Einseitige Existenzabhängigkeit (b hängt von E ab): comp(E,b)=(0,1) oder comp(E,b)=(0,*)
- Wechselseitige Existenzabhängigkeit (b und E sind wechselseitig abhängig): comp(E,b)=(1,1) oder comp(E,b)=(1,*).
|
|
|
|
|
Abbildung 12.2-1: |
Einseitige und wechselseitige Existenzabhängigkeiten |
|
|
|
Von zentraler Bedeutung für den Ansatz ist nun folgende Festlegung: |
|
"Ein Entity-Typ wird mit denjenigen Relationship-Typen, mit denen er durch eine (1,1) - Beziehung verbunden ist, zu einem Entity-Relationship-Typ (ER-Typ) zusammengefasst. Gegenüber dem ERM entsteht dadurch ein dritter Objekttyp. Im SER-Diagramm ist ein ER-Typ sowohl Zielknoten (R-Anteil) als auch Startknoten (E-Anteil) von Kanten." [Sinz 1990, S. 26] |
|
Ein „dritter Objekttyp“ entsteht, weil er noch einen Relationship-Typ (R-Typ) einführt, der durch den entsprechenden Typ der ER-Modellierung motiviert ist. Er ist allerdings anders definiert, dazu unten mehr. |
|
Insgesamt führt Sinz damit drei verschiedene Knoten ein: den normalen Entity-Typ, den Entity-Relationship-Typ (ER-Typ) und den Relationship-Typ (R). Die grafische Darstellung der beiden neuen Grafikelemente ist wie folgt: |
|
|
|
|
|
Betrachten wir zur Verdeutlichung das Beispiel aus [Sinz 1990]. Zuerst in der ganz normalen ERM-Darstellung, wie in den ersten Kapiteln dargestellt. Das Beispiel sollte weitgehend selbsterklärend sein. |
|
|
|
|
Abbildung 12.2-2: |
ER-Modell Kunden - Aufträge - Artikel Quelle: [Sinz 1990, S. 21]. |
|
|
|
Der Entitätstyp Forderungen erfasst Forderungen, die gegenüber Kunden bzgl. bestimmter Auftragspositionen bestehen: |
|
- Eine Forderung bezieht sich auf eine Auftragsposition oder mehrere.
- Zu einer Auftragsposition gibt es keine oder eine („maximal eine“) Forderung.
|
|
Umwandlung: ERM zu SERM |
|
Wir wandeln nun dieses ERM in ein SERM um, wobei gleichzeitig auch die relationale Umsetzung angegeben wird. |
|
Für die Pfeilspitzen gilt: |
|
- Einfache Pfeilspitze: Bezug auf eine Entität des Ziels
- Doppelte Pfeilspitze: Bezug auf mehrere Entitäten des Ziels
- Senkrechter Strich vor den Pfeilspitzen: Beziehung ist – vom Start aus gesehen, optional.
- Kein senkrechter Strich: Eine Entität des Startelements muss teilhaben
|
|
Beginnen wir mit dem Fragment Kunden / Forderungen. Gemäß den Min-/Max-Angaben bleibt Kunden als Entity-Typ erhalten. Wegen der Min-/Max-Angabe 1,1 bei Forderungen wird aus KD-FO und Forderungen der ER-Typ Forderungen. Vgl. dazu die folgende Abbildung. In dieser ist auch die relationale Form dieses Fragments angegeben: Die Relation Forderungen erhält den Fremdschlüssel KundenNr. Es gibt also keine Forderungen, die nicht mit einem Kunden verknüpft sind. |
Kunden / Forderungen |
Wegen der Forderung nach referentieller Integrität, wie sie in der relationalen Theorie (sinnvollerweise) gefordert wird. Vgl. [Staud 2021, Abschnitte 5.2 und 5.9]. |
|
Die Pfeilspitze beim SERM-Fragment drückt aus, dass zu einem Kunden keine, eine oder mehrere Forderungen bestehen. Die 1,1-Angabe im ERM ist im SERM durch die Verschmelzung, die zum ER-Typ geführt hat, eingebaut. |
|
|
|
|
Abbildung 12.2-3: |
Vom ERM zum SERM - Fragment Kunden / Forderungen |
|
|
|
Die graphische Anordnung der SERM-Elemente erfolgt bewusst so wie in der obigen Abbildung. In SER-Modellen werden, wie weiter unten gezeigt wird, die E-, ER- und R-Typen von links nach rechts in Spalten angeordnet, gemäß ihrem Abhängigkeitsgrad. |
|
Nun das Fragment Kunden / Auftragsköpfe. Hier liegen dieselben Min-/Max-Angaben vor, wie im vorigen Fragment. Kunden liegt ja schon als Entity-Typ vor, Auftragsköpfe wird zum ER-Typ. Vgl. die folgende Abbildung, auch wiederum mit der relationalen Umsetzung. |
Kunden / Auftragsköpfe |
|
|
|
Abbildung 12.2-4: |
Vom ERM zum SERM - Fragment Kunden / Auftragsköpfe |
|
|
|
Betrachten wir nun das Fragment Auftragsköpfe / -positionen /Artikel. Hier liegt bei den Auftragspositionen zweimal die Min-/Max-Angabe 1,1 vor, so dass Auftragspositionen ein ER-Typ mit Verknüpfungen zu Auftragsköpfe und Artikel wird. Da Auftragsköpfe von Kunden abhängig ist, denken wir dafür eine weitere Spalte an. Artikel ist unabhängig und bekommt deshalb in der Abbildung einen Platz ganz links, sozusagen in Spalte 1. Auftragsköpfe in Spalte 2 und Auftragspositionen in Spalte 3. Die folgende Abbildung zeigt das SERM-Fragment. In diesem sind die auch Wertigkeiten angegeben: |
Auftragsköpfe / -positionen /Artikel |
- Ein Auftragskopf muss mindestens eine Auftragsposition haben.
- Ein Artikel kann in keiner, einer oder mehreren Auftragspositionen vorhanden sein
|
|
Das relationale Fragment zeigt die Umsetzung in relationale Strukturen. In Auftragspositionen wird die ArtikelNr als Fremdschlüssel übernommen. Als Schlüssel nehmen wir die AuftrNr und wegen der Differenzierung nach Positionen noch die Positionsnummer (PosNr), womit die Min-/Max-Angaben erfüllt sind: Jede Auftragsposition muss eine Auftragsnummer haben und zu jedem Auftragskopf gibt es mindestens eine Auftragsposition. |
|
|
|
|
Abbildung 12.2-5: |
Vom ERM zum SERM - Fragment Auftragsköpfe / -positionen /Artikel |
|
|
|
Nun zum Fragment Forderungen / Auftragspositionen. Nach dem Entity Relationship - Modell gilt: Eine Forderung bezieht sich auf mindestens eine Auftragsposition. Zu einer Auftragsposition kann es maximal eine einzige Forderung geben. |
Forderungen / Auftragspositionen |
Forderungen gibt es schon als ER-Typ, Auftragspositionen ebenfalls. Es gibt keine 1,1-Angabe, so dass kein ER-Typ entstehen kann. Dafür ist der Relationship-Typ (R-Typ) gedacht. Dies wird auch anhand der relationalen Umsetzung klar. Eine solche Struktur (0 als Min-Angabe) erfordert eine eigene Relation. |
|
Die Pfeilspitzen beim R-Typ drücken die Beziehungswertigkeiten korrekt aus: |
|
- Zu jeder Forderungsauftragsposition gibt es mindestens eine Forderung.
- Zu jeder Forderungsauftragsposition gibt es keine oder maximal eine Auftragsposition.
|
|
Der untere Teil der Abbildung zeigt wiederum die relationale Umsetzung. FO-AP erhält einen zusammengesetzten Schlüssel, bestehend aus der ForderungsNr und dem wiederum zusammengesetzten Schlüssel (AuftrNr, PosNr). Zusammengesetzte Schlüssel signalisieren höchste Abhängigkeit. Wegen der elementaren Forderung nach Vollständigkeit des Schlüssels („Objektintegrität“, vgl. [Staud 2021, Abschnitt 5.9]) gibt es in FO-AP nur einen Eintrag, wenn es entsprechende Forderungen und Auftragspositionen gibt. |
|
|
|
|
Abbildung 12.2-6: |
Vom ERM zum SERM - Fragment Forderungen / Auftragspositionen |
|
|
|
Fügt man damit die entstandenen Elemente zusammen, entsteht das SER-Modell der folgenden Abbildung. In dieser sind nun auch die oben erwähnten Spalten für die Abhängigkeitsgrade angegeben. Dazu unten mehr. |
|
|
|
|
Abbildung 12.2-7: |
SER-Modell Kunden - Aufträge - Artikel |
|
|
|
Sinz verwendet für die gerichteten Beziehungen etwas andere Pfeile. Hier wurde die Pfeilnotation der SAP verwendet (vgl. den nächsten Abschnitt), was inhaltlich keine Bedeutung hat. |
|
Die Quelle für die obige Abbildung ist [Sinz 1990, S. 27]. Lediglich die Verbindungslinien wurden leicht verändert und nach der inzwischen gebräuchlicheren SAP-SERM-Notation gestaltet. Außerdem wurden die Spalten eingefügt. Mit ihnen werden unten die Abhängigkeitsgrade diskutiert. |
|
Verdeutlichung |
„1,1 – Verschmelzung“ |
Für die Min-/Max-Angaben 1,1 gilt also: Es wird jeweils ein Entity-Typ mit den Relationship-Typen zu einem Entity-Relationship-Typ (ER-Typ) zusammengefasst, die durch 1:1 - Beziehungen verbunden sind. Dem entspricht – bei der Übertragung in ein relationales Datenmodell – die Situation, dass dem Entity-Typ ein Fremdschlüssel hinzugefügt wird, der Schlüssel des anderen Entity-Typs. Er ist sozusagen Repräsentant des Relationship-Typs. Somit gilt hier, dass aus dem Beziehungstyp KD-AK zusammen mit dem Entitätstyp Auftragskopf der Entity-Relationship-Typ (ER-Typ) Auftragskopf wird (vgl. Abbildung unten). |
|
|
|
|
Abbildung 12.2-8: |
Von Entitätstyp und 1:1 - Beziehung zu ER-Typ |
|
|
|
Genau dasselbe geschieht mit dem Entitätstyp Forderung und dem Beziehungstyp KD-FO. |
|
|
|
|
Abbildung 12.2-9: |
Von Entitätstyp und 1:1 - Beziehung zu ER-Typ |
|
|
|
Im Falle des Entity-Typs Auftragsposition werden die beiden Beziehungstypen AK-AP und AR-AP hinzugenommen und in einen ER-Typ Auftragsposition verwandelt. |
|
|
|
|
Abbildung 12.2-10: |
Von Entitätstyp und 1:1 - Beziehung zu ER-Typ |
|
|
|
Zwei der Entitätstypen von Abbildung 12.2-2 erweisen sich als unabhängig von den anderen: Kunde und Artikel. Sie bleiben also Entitätstypen, bzw., in der Begrifflichkeit von Sinz Entity-Typen. |
|
Zwischen den damit erzeugten E-, ER- und R-Typen besteht nun eine Abhängigkeit im Sinne dieses Ansatzes. Diese Abhängigkeit hat eine Richtung und wird deshalb durch gerichtete Pfeile ausgedrückt. Folgende gerichteten(!) Beziehungen liegen in dem entstehenden SERM nun vor: |
Abhängigkeit mit Richtung |
- 0,* zwischen E-Typ Kunden und ER-Typ Forderungen
- 0,* zwischen E-Typ Kunde und ER-Typ Auftragsköpfe
- 0,* zwischen E-Typ Artikel und ER-Typ Auftragspositionen
- 1,* zwischen ER-Typ Forderungen und R-Typ FO-AP
- 1,* zwischen ER-Typ Auftragsköpfe und ER-Typ Auftragspositionen
- 0,1 zwischen ER-Typ Auftragspositionen und R-Typ FO-AP
|
|
Von den Startelementen (den jeweils links angeordneten) aus gesehen, geht es somit nur noch um die Frage, ob jede Entität an der Beziehung teilnehmen muss oder nicht (optional oder nicht). |
|
Von den Zielelementen aus gesehen geht es nur noch darum, ob maximal eine Entität oder mehrere an der Beziehung teilhaben. |
|
Nun die Abhängigkeiten: Völlig unabhängig sind Artikel und Kunde (Spalte 1). Diese beiden Entity-Typen benötigen keine anderen für ihre Existenz. Die durch sie repräsentierten Daten entstehen im Weltausschnitt bzw. Anwendungsbereich. Sie werden ganz links eingeordnet. |
Von links nach rechts immer abhängiger. |
Forderungen und Auftragsköpfe dagegen können nur existieren, falls es zugehörige Kunden gibt. Sie sind also von Kunden abhängig und werden deshalb in einer zweiten Spalte auf der rechten Seite angeordnet. |
|
Für Auftragspositionen gilt, dass sie nur existieren können, falls in Artikel und in Auftragsköpfe entsprechende Entitäten vorhanden sind. Dabei gilt: Einen Auftragskopf muss es geben, die Artikelangabe ist optional. Die Auftragspositionen sind deshalb in einer dritten Spalte. |
|
Forderungsauftragspositionen (FO-AP) wiederum benötigen Entitäten in Forderungen und in Auftragspositionen und landen deshalb in Spalte 4. |
|
Dieser Ansatz sorgt durch Berücksichtigung der Abhängigkeiten zwischen den Modellelementen und durch Visualisierung dieses Tatbestandes für mehr Übersicht im Datenmodell. Das Mittel, um dies zu erreichen ist letztendlich die Schlüssel-/Fremdschlüssel – Architektur der relationalen Theorie. |
|
Somit ist der SERM-Ansatz zwischen der standardmäßigen ER-Modellierung und der relationalen Modellierung angesiedelt. |
|
Zur Verdeutlichung hier das Relationale Modell zu den obigen beiden Modellen. Die Anordnung wurde ähnlich der im SER-Modell gewählt. |
|
|
|
|
Abbildung 12.2-11: |
Relationales Datenmodell Kunden - Aufträge - Artikel |
|
|
|
Die Übertragung ist – ausgehend von den obigen zwei Modellen (ERM und SERM) nicht schwierig. Folgende Schlüssel wurden eingeführt, die übrigen eventuellen Attribute sind hierfür ohne Belang: |
Von ERM und SERM nach RM |
- KundenNr als Schlüssel von Kunden
- ArtikelNr als Schlüssel von Artikel
- AuftrNr als Schlüssel von Auftragsköpfe
- ForderungsNr als Schlüssel von Forderungen
- (AuftrNr, PosNr) als Schlüssel von Auftragspositionen
|
|
Mit den Min-/Max-Angaben zwischen Kunden und Auftragsköpfe muss der Kunde in jedem Auftragskopf vermerkt werden. KundenNr wird also Fremdschlüssel in Auftragsköpfe. Bei der Beziehung zwischen Artikel und Auftragspositionen führen die Min-/Max-Angaben dazu, dass die ArtikelNr Fremdschlüssel in Auftragspositionen wird. Genau gleich wird die Beziehung zwischen Forderungen und Kunden verarbeitet. |
|
Etwas weniger klar ist die Beziehung FO-AP zwischen Auftragspositionen und Forderungen. Die Min-/Max-Angaben drücken aus, dass es für jede Forderung mindestens eine Entität in FO-AP gibt. Eine Auftragsposition muss aber nicht zu einer Forderungsauftragsposition führen, falls ja, höchstens zu einer. Dies kann nur durch eine eigene Relation modelliert werden. Die Schlüssel- und Fremdschlüsselsituation ist dann wie folgt: |
|
- Der Gesamtschlüssel besteht aus #(ForderungsNr, (AuftrNr, PosNr)).
- ForderungsNr alleine ist auch Fremdschlüssel.
- Die Attributkombination (AuftrNr, PosNr) ist ebenfalls Fremdschlüssel.
|
|
Ein Fremdschlüssel, der aus zwei Attributen besteht, ist durchaus ungewöhnlich, hier aber unvermeidlich. |
|
So entstand das obige relationale Datenmodell. Der Vergleich mit dem SER-Modell macht deutlich, dass die definierte Existenzabhängigkeit mit dem Gewicht der Fremdschlüssel einhergeht: |
Fremdschlüssel und Abhängigkeit |
Gibt es keine Fremdschlüssel, ist der Entitätstyp unabhängig. Gibt es in Ergänzung des Schlüssels einen Fremdschlüssel, ist die erste Stufe der Existenzabhängigkeit gegeben. Liegt, wie hier in FO-AP, ein zusammengesetzter Schlüssel vor, der nur aus Fremdschlüsseln besteht, ist die höchste Form der Abhängigkeit erreicht. |
|
SERM sind in mehrfacher Hinsicht von großem Nutzen. |
Nutzen |
- Erstens verdeutlichen sie diesen Zweig der semantischen Modellierung, sie helfen beim Verständnis.
- Zweitens ist diese Methode präziser. Sie führt zu eindeutigeren Ergebnissen. Deshalb ist der Ansatz in der praktischen semantischen Modellierung von großem Nutzen.
- Drittens wird die Umsetzung des Modells in eine konkrete Datenbank erleichtert und weniger fehleranfällig.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|