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:
- Es gibt keine zwei völlig identischen Tupel. (Das heißt: Zwei Zeilen in einer Tabelle unterscheiden sich in mindestens einem Wert.)
- Die Reihenfolge der Tupel ist unwichtig, sie sind nicht geordnet. (Es ändert erst einmal nichts, wenn die Reifenfolge der Zeilen geändert wird.)
- Die Reihenfolge der Attribute ist unwichtig, sie sind nicht geordnet. (Es ändert sich erst einmal nichts, wenn die Reihenfolge der Spalten geändert wird.)
- 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
Gut zu wissen, dass die Reihenfolge der Attribute grundsätzlich irrelevant ist. Ich bin mit dem Modell meiner Datenbank unzufrieden und möchte grundlegende Veränderung vornehmen lassen. Dafür suche ich mir am besten ein professionelles IT-Consulting Unternehmen.