Daten und Datenmodellierung (3)

Datenmodellierung ist wichtig bei der Konzeptionierung einer Systemarchitektur. Dieser Artikel behandelt die Datenmodellierung mit ERM (Fachkonzept) und Relationenmodellen (DV-Konzept). Das gehört zum Grundwissen der Wirtschaftsinformatik  und der Digitalisierung.

NEU 22.05.2021: Datenmodellierung mit der Coddschen Relationentheorie

Zurück zu Teil 1 der Artikelserie zur Datenhaltung und Datenmodellierung
Zurück zu Teil 2 der Artikelserie zur Datenhaltung und Datenmodellierung

Überblick: Methoden der Wirtschaftsinformatik

Teil 3: Daten modellieren mit ERM und Relationenmodell

Motivation für die Datenmodellierung

Datenmodellierung ist nicht nur für IT-ler

Im ersten Teil der Serie dreht es sich um Daten im Dateisystem, aber insbesondere bei strukturierten Daten in RDBMS (Relationalen Datenbank-Management-Systemen) stellt sich aus betriebswirtschaftlich / fachlicher Sicht die Frage, wie Sie eine Datenbank konzipieren und ihr Bezug zu Objekten aus der realen Welt herstellen. Der Start in die Entwicklung eines Betrieblichen Anwendungssystems umfasst daher neben der Analyse der Anforderungen (z. B. mit Use-Case-Diagrammen) und dem Design der Oberflächen (z.B. mit Mockups)  die Modellierung der Fakten in der realen Welt mit Hilfe eines Datenmodells. Dabei visualisiert ein Datenmodell die Beziehungen zwischen den Objekten, beschreibt, durch welche Attribute die Objekte beschrieben werden und reduziert so die Komplexität.

Datenmodelle sind beständig

Während Anwendungsprogramme zuweilen schon nach wenigen Betriebsjahren erneuert werden, ändert sich die Struktur von Daten nur wenig und selten, was man z.B. bei den Stammdaten bei Banken und Versicherungen beobachten kann. Da Datenmodelle so stabil und langlebig sind, verdienen sie besondere Aufmerksamkeit.

Datenmodelle dienen der Analyse

Haben Sie ein bestehendes Anwendungssystem, das unzureichend dokumentiert ist, setzen Sie die Datenmodellierung zur Analyse  ein, um das Anwendungssystem besser verstehen zu können.

Wie gehen wir vor … ?

Im Gegensatz zu dem im Ordnungsrahmen ARIS sonst üblichen Top-Down-Ansatz soll hier aus didaktischen Gründen eine anderer Ansatz verfolgt werden: Ausgehend von bestehenden Datenmengen und einfachen Datensammlungen wird zunächst die Datenmodellierung mit dem Relationenmodell erklärt und dann aus den Relationen das Entity-Relationship-Diagramm (ERD) abgeleitet. Das ERD visualisiert dann das sogenannte Entity-Relationship-Model ERM.

Relationenmodell und Entity-Relationship-Modell – Datenmodellierung am Beispiel

Relationen sind wie Tabellen

Eine Relation ist die Basis der von Edgar F. Codd entwickelten relationalen Algebra [1]. Darin besteht eine Relation aus Attributen (vgl. Spaltenüberschriften in Excel-Tabellen) und Tupeln (vgl. Zeilen in einer Excel-Tabelle). Ein Attribut beschreibt den Typ eines möglichen Attributwertes und bezeichnet ihn mit einem Attributnamen. Ein Tupel stellt eine konkrete Kombination von Attributwerten dar (ein Datensatz). Das Relationenmodell beschreibt Daten also in Form von Tabellen. Dabei wird ein Tabellenname angegeben und die Bezeichnungen der Spalten der Datentabellen.  In der Übersicht in Tab.1 sind die Begriffe der Relationentheorie lebensweltlichen Begriffen gegenübergestellt:

Relationentheorie	kann verdeutlichte werden durch
Relation	Tabelle
Tupel	Menge der Zellen in einer Zeile
Attribut	Spaltenüberschrift

Tab. 1: Begriffe aus der Relationentheorie

Definition „Relation“

Den Begriff „Relation“ kann man über seine Eigenschaften definieren:

Eine Relation ist eine Tabelle  bestehend aus einem Kopf und einem Rumpf (vgl. Abb. 1) mit folgenden vier Eigenschaften:

1. Es gibt keine zwei völlig identischen Tupel. (Das heißt: Zwei Zeilen in einer Tabelle unterscheiden sich in mindestens einem Wert.)
2. Die Reihenfolge der Tupel ist unwichtig, sie sind nicht geordnet. (Es ändert erst einmal nichts, wenn die Reifenfolge der Zeilen geändert wird.)
3. Die Reihenfolge der Attribute ist unwichtig, sie sind nicht geordnet. (Es ändert sich erst einmal nichts, wenn die Reihenfolge der Spalten geändert wird.)
4. Alle Attribute sind atomar, d. h. dass in jeder Tabellenzelle nur ein Eintrag einer Sorte stehen darf. (Heißt: In ein Tabellenfeld gehört nur ein Wert.)

 

Abb. 1: Beispiel für eine einfache Relation am Beispiel Schrauben.

Relationen und Beziehungen

Relationen können untereinander in Beziehung stehen – so wie Objekte in der realen Welt auch. Im Relationenmodell wird das durch gleiche Spalten / Attribute ausgedrückt. Abb. 2 zeigt ein Beispiel, das die Relation Schraube nutzt und darstellt, welche Schrauben zu welchem Bauteil gehören. Dabei kann eine bestimmte Schraube zu mehreren verschiedenen Bauteilen gehören. Ein Bauteil kann auch mehrere Schrauben enthalten. Die eigentliche „Intelligenz“ des Relationenmodells liegt dabei in der Relation „zugeordnet“, die die beiden Relationen „schraube“ und „bauteil“ verknüpft.

Abb. 2: Beispiel eines Relationenmodells für die Datenmodellierung der Beziehungen zwischen Schrauben und Bauteilen

Auf diese Art und Weise können alle Objekte eines Unternehmens und die Beziehungen zwischen den Objekten beschrieben werden. Das Relationenmodell lässt sich direkt in eine relationales Datenbankmanagementsystem umsetzen, das wäre dann die Implementierung der Ergebnisses der Datenmodellierung.

Ein einfaches Entity-Relationship-Modell

In der Beschreibungsebene Fachkonzept der Perspektive Daten im Ordnungsrahmen ARIS interessiert man sich noch nicht für die konkreten Ausprägungen der Datensätze und betrachtet daher nur modellhaft die Klassen der Objekte. Für die Visualisierung sind Entity-Relationship-Diagramme (ERD) geeignet, und eine modellhafte Erfassung eines Realweltausschnittes heißt Entity-Relationship-Modell (ERM). Diese Betrachtung der Daten entwickelte Peter Chen [2] am MIT in 1976.

Für das Beispiel der Schrauben sähe ein ERD wie in Abb. 3 aus.

Abb. 3: Beispiel für ein einfaches Entity-Relationship-Modell am Beispiel Schrauben

Ein nicht ganz so einfaches ER-Modell

Für die Beziehungen zwischen Schrauben und Bauteilen könnte ein ERD wie in Abb. 4 dienen. Hier sehen Sie eine einfache eins-zu-eins-Zuordnung von Entitätstypen und Relationentypen zu den Relationen. Das ist möglich, da Relationentypen des ERD auch als Tabellen bzw. als Relationen dargestellt werden können. Es gibt durchaus Situationen, in denen einen einfache eins-zu-eins-Zuordnung nicht sinnvoll ist.

Abb. 4: Beispiel für ein Entity-Relationship-Modell für die Beziehung zwischen Schrauben und Bauteilen

Umsetzung in ein Relationenmodell

Relationentypen (Achtung, nicht mit den Codd’schen Relationen verwechseln) sind neben den Entitätsytypen der zweite Knotentyp in ER-Modellen. Relationentypen bezeichnen, in welcher Beziehung Entitätstypen stehen und haben meist die Ids der beteiligten Entitätstypen als Attribute (in Abb. 4 der Übersichtlichkeit halber nicht eingezeichnet). Überraschend ist, dass Relationentypen auch eigene Attribute haben können.

Um festzulegen, mit wie vielen Entitäten des anderen Entitäststyps (hier bauteil) ein Entitästtyp des einen Entitätstyps (hier schraube) verbunden sein kann, sind die sogenannten Kardinalitäten in der ISO-min-max-Schreibweise angegeben. Eine andere, oft verwendete Schreibweise, ist die Chen-Notation für Kardinalitäten. Die Angabe der Kardinalitäten zwingt zu einer intensiven Befassung mit den fachlichen Fragestellungen, z. B. ob ein Bauteil noch zum Entitätstyp Bauteil gehört, wenn es keine Schrauben benötigt. Wenn es keine Schrauben benötigt, so wäre die Kardinalität gleich (0,*). Im Falle dass Schrauben zwingend vorausgesetzt werden, wäre die Kardinalität gleich (1,*). Ebenso kann auch die Menge der Verbindungen begrenzt sein. Sind z. B maximal 30 Schrauben pro Bauteil möglich, lautet die Kardinalität am Entitätstyp bauteil gleich (0,30). Bei beliebig vielen Schrauben ist die Kardinalität gleich (0,*) oder gleichbedeutend (0,n).

Datenmodellierung einer einfache Liste

Eine einfache Liste aus Zahlen wie im ersten Teil der Serie „Daten aus einfachen Zahlen als txt-Dateien“ soll als Beispiel dienen (Abb. 5).

021514 6782453
021541 6254273
015772 62444902

Abb. 5: Beispiel Liste mit Telefonnummern in eine Textdatei mit Namen telefonnummern.txt

Für eine einfache Liste gibt es nur eine Spaltenbezeichnung, das könnte z.B. „telefonnr“ sein, da eine Liste eine Tabelle mit nur einer Spalte ist.

Die Relation könnte „telefonnr“ heißen. Die Relation hat nur ein Attribut „nr“. Das Relationenmodell für die einfache Liste sähe dann wie in Abb. 6 aus.

Abb. 6: Relationenmodell für eine einfache Telefonliste

Das Entity-Realtionship-Modell für die Telefonliste ist, wie Abb. 7 zeigt, ebenfalls sehr einfach. Es gibt nur eine Klasse von Objekten entsprechend dem Entitätstyp „telefonnr“. Ein Objekt (eine Entität) hat nur eine Eigenschaft ausgedrückt durch das Attribut „nr“.

Abb. 7: ER-Modell für eine einfache Telefonliste

Eine einfache Tabelle

Aus der Liste wird eine einfache Tabelle, wenn eine Spalte hinzukommt. So kann der jeweiligen Telefonnummer auch ein Name zugeordnet werden. Um dem Dilemma zu entgehen, dass, wenn zwei Personen mit gleichem Namen in gleichem Haushalt mit derselben Telefonnummer leben und es somit zwei identische Datensätze gäbe, kann man eine eindeutige id vergeben wie in Abb. 8.

001;Kurt;0215187837
002;Kurt;0215187837
003;Emma;021387215
004;Karl;02431478372
…

Abb. 8. Beispiel tabellenartige Sammlung von Telefonnummern mit Namen

Die Umsetzung in ein Relationenmodell ist in Abb. 9 gezeigt.

Abb. 9 Relationenmodell für eine Telefonnummernsammlung in Tabellenform

Das ER-Modell besteht wiederum nur aus dem einen Entitätstypen telefonnr. Es sind nun als Attribute die id und der Namen hinzugekommen.

Abb. 10: ER-Modell für eine Telefonnummernsammlung in Tabellenform

Zwei Tabellen verknüpfen

Wenn nun Smartphones Einzug halten und eine Person mehrere Telefone hat, so gibt es mehrere Möglichkeiten, diesen Sachverhalt im Relationenmodell zu berücksichtigen. Es ist keine Option, die zweite Telefonnummer einfach hinter die erste mit in die gleiche Tabellenzelle zu schreiben, da damit die Atomarität verletzt wäre. Die Lösung könnte jedoch im Hinzufügen einer weiteren Spalte für die Mobilnummer bestehen. Kommt aber dann ein Tablet mit mit einer weiteren Telefonnummer hinzu, müsste Sie wiederum das Datenmodell ändern. Um flexibel auf diese Anforderungen zu reagieren, teilen Sie besser die  Tabelle telefonnr  in zwei Relationen „person“ und „telefon“ wie in Abb. 11. Die Relation Telefon erhält ein Attribut „eigenschaft“, mit dem Sie festelegen, ob es sich um eine Festnetznummer oder um eine Mobilnetznummer handelt.

Abb. 11: Relationenmodell für den Fall mehrer Telefonnumern je Person

Abb. 12: ER-Modell für den Fall mehrerer Telefonnummern je Person

Weitere Möglichkeiten von Datenmodellierung mit  Relationen- und ER-Modellen

Mit den hier dargestellten Möglichkeiten können Sie schon die Daten der meisten (kleinen) Informationssysteme ausreichend beschreiben. Hinsichtlich der Relationenmodelle wäre es für eine vollständige theoretische Betrachtung erforderlich, die sogenannten Normalfomen zu besprechen. In der Praxis zeigt sich jedoch, dass die konsequente Berücksichtigung lediglich der ersten Normalform, nämlich die Atomarität, schon zu brauchbaren Datenmodellen führt. Insbesondere Performance-Optimierung führen dazu, dass Entwickler auf eine intensive Normalisierung verzichten Im Bankenumfeld haben wir seinerzeit konsequent die dritte Normalform vermieden, da sie zu einer Unzahl von Tabellen mit wenigen Spalten führt, die die Anwendungsprogrammierung sehr kompliziert macht.

ER-Modelle können noch viel mehr, so gibt es noch Generalisierung, Spezialisierung, Aggregation und Zerlegung. Ebenso kann man zwischen starken und schwachen Entitätstypen unterscheiden. Eine „Übermodellierung“ sollten Sie jedoch vermeiden, weil sie die Umsetzung in ein Datenbanksystem erschwert.

Auch bei der Datenmodellierung soll die Faustformel gelten: Am Besten ist es so einfach, dass es gerade noch nicht gänzlich falsch ist.

Quellen:

Videos auf youtube

ERM Entity Relationship Modellierung am Beispiel – Überblick: https://youtu.be/8NTAq8N_jQc

ERM Entity Relationship Modellierung am Beispiel 1 –  Grundbegriffe: https://youtu.be/d2tWsd_AbHo

ERM Entity Relationship Modellierung am Beispiel 2 – 1:1 Beziehung Tanzkurs: https://youtu.be/O9LbBo012wE

ERM Entity Relationship Modellierung am Beispiel 3 – 1:n Beziehung Schulklasse: https://youtu.be/FEuzVIyGb_M

ERM Entity Relationship Modellierung am Beispiel 4 – m:n Beziehung Kursverwaltung: https://youtu.be/BABMI69NSx0

ERM Entity Relationship Modellierung am Beispiel 5 – komplizierteres Modell der Kursverwaltung: https://youtu.be/Y-GIspXg3TE

Literatur zur Datenmodellierung:

[1] Codd, E. (1970): A Relational Model of Data for Large Shared Data Banks” Communications of the ACM, San Jose, CA, USA, 1970. ACM, New York, USA, 1970; S. 377-387.  IBM Research Laboratory, San Jose, California. Online Ressource: https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf

[2] Chen Pin-Shan, Peter (1976) The Entity-relationship Model—Toward a Unified View of Data. In: ACM Trans. Database Syst. Band 1, Nr. 1, 03.1976, S. 9–36, doi:10.1145/320434.320440.

Andere Modellierungsnotationen

Geschäftsprozessmodellierung mit eEPK (erweiterte Ereignisgesteuerte Prozessketten)

Fallstudien für die Anwendung der Datenmodellierung

Kaffeemanufaktur „Kleiner Schwarzer“ – Eine Fallstudie für die Wirtschaftsinformatik

Baumeister7x24 – Eine Fallstudie für die Wirtschaftsinformatik

Tabakgarage – Eine Fallstudie für die Wirtschaftsinformatik