{"id":174,"date":"2018-10-14T20:01:22","date_gmt":"2018-10-14T18:01:22","guid":{"rendered":"https:\/\/cbrell.de\/blog\/?p=174"},"modified":"2021-10-04T00:00:01","modified_gmt":"2021-10-03T22:00:01","slug":"daten-und-datenmodellierung-3","status":"publish","type":"post","link":"https:\/\/cbrell.de\/blog\/daten-und-datenmodellierung-3\/","title":{"rendered":"Daten und Datenmodellierung (3)"},"content":{"rendered":"

Datenmodellierung ist wichtig bei der Konzeptionierung einer Systemarchitektur. Dieser Artikel behandelt die Datenmodellierung mit ERM (Fachkonzept) und Relationenmodellen (DV-Konzept). Das geh\u00f6rt zum Grundwissen der Wirtschaftsinformatik\u00a0\u00a0<\/a>und der Digitalisierung.<\/em><\/p>\n

NEU 22.05.2021: Datenmodellierung mit der Coddschen Relationentheorie<\/a><\/p>\n

Zur\u00fcck zu Teil 1 der Artikelserie zur Datenhaltung und Datenmodellierung<\/a>
\nZur\u00fcck zu Teil 2 der Artikelserie zur Datenhaltung und Datenmodellierung<\/a><\/p>\n

\u00dcberblick: Methoden der Wirtschaftsinformatik<\/a><\/p>\n

Teil 3: Daten modellieren mit ERM und Relationenmodell<\/strong><\/p>\n

Motivation f\u00fcr die Datenmodellierung<\/h2>\n

Datenmodellierung ist nicht nur f\u00fcr IT-ler<\/h3>\n

Im ersten Teil der Serie<\/a> 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\u00e4chen (z.B. mit Mockups)\u00a0 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\u00e4t.<\/p>\n

Datenmodelle sind best\u00e4ndig<\/h3>\n

W\u00e4hrend Anwendungsprogramme zuweilen schon nach wenigen Betriebsjahren erneuert werden, \u00e4ndert 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.<\/p>\n

Datenmodelle dienen der Analyse<\/h3>\n

Haben Sie ein bestehendes Anwendungssystem, das unzureichend dokumentiert ist, setzen Sie die Datenmodellierung zur Analyse\u00a0 ein, um das Anwendungssystem besser verstehen zu k\u00f6nnen.<\/p>\n

Wie gehen wir vor … ?<\/h3>\n

Im Gegensatz zu dem im Ordnungsrahmen ARIS sonst \u00fcblichen Top-Down-Ansatz soll hier aus didaktischen Gr\u00fcnden eine anderer Ansatz verfolgt werden: Ausgehend von bestehenden Datenmengen und einfachen Datensammlungen wird zun\u00e4chst die Datenmodellierung mit dem Relationenmodell erkl\u00e4rt und dann aus den Relationen das Entity-Relationship-Diagramm (ERD) abgeleitet. Das ERD visualisiert dann das sogenannte Entity-Relationship-Model ERM.<\/p>\n

Relationenmodell und Entity-Relationship-Modell – Datenmodellierung am Beispiel<\/h2>\n

Relationen sind wie Tabellen<\/h3>\n

Eine Relation ist die Basis der von Edgar F. Codd entwickelten relationalen Algebra [1]. Darin besteht eine Relation aus Attributen (vgl. Spalten\u00fcberschriften in Excel-Tabellen) und Tupeln (vgl. Zeilen in einer Excel-Tabelle). Ein Attribut beschreibt den Typ eines m\u00f6glichen 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.\u00a0 In der \u00dcbersicht in Tab.1 sind die Begriffe der Relationentheorie lebensweltlichen Begriffen gegen\u00fcbergestellt:<\/p>\n\n\n\n\n\n\n
Relationentheorie<\/th>\nkann verdeutlichte werden durch<\/th>\n<\/tr>\n
Relation<\/td>\nTabelle<\/td>\n<\/tr>\n
Tupel<\/td>\nMenge der Zellen in einer Zeile<\/td>\n<\/tr>\n
Attribut<\/td>\nSpalten\u00fcberschrift<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Tab. 1: Begriffe aus der Relationentheorie<\/em><\/p>\n

Definition „Relation“<\/h3>\n

Den Begriff „Relation“ kann man \u00fcber seine Eigenschaften definieren:<\/p>\n

Eine Relation ist eine Tabelle\u00a0 bestehend aus einem Kopf und einem Rumpf (vgl. Abb. 1) mit folgenden vier Eigenschaften:<\/p>\n

    \n
  1. Es gibt keine zwei v\u00f6llig identischen Tupel. (Das hei\u00dft: Zwei Zeilen in einer Tabelle unterscheiden sich in mindestens einem Wert.)<\/li>\n
  2. Die Reihenfolge der Tupel ist unwichtig, sie sind nicht geordnet. (Es \u00e4ndert erst einmal nichts, wenn die Reifenfolge der Zeilen ge\u00e4ndert wird.)<\/li>\n
  3. Die Reihenfolge der Attribute ist unwichtig, sie sind nicht geordnet. (Es \u00e4ndert sich erst einmal nichts, wenn die Reihenfolge der Spalten ge\u00e4ndert wird.)<\/li>\n
  4. Alle Attribute sind atomar, d. h. dass in jeder Tabellenzelle nur ein Eintrag einer Sorte stehen darf. (Hei\u00dft: In ein Tabellenfeld geh\u00f6rt nur ein Wert.)<\/li>\n<\/ol>\n

     <\/p>\n

    \"Relation<\/a><\/p>\n

    Abb. 1: Beispiel f\u00fcr eine einfache Relation am Beispiel Schrauben.<\/em><\/p>\n

    Relationen und Beziehungen<\/h3>\n

    Relationen k\u00f6nnen untereinander in Beziehung stehen – so wie Objekte in der realen Welt auch. Im Relationenmodell wird das durch gleiche Spalten \/ Attribute ausgedr\u00fcckt. Abb. 2 zeigt ein Beispiel, das die Relation Schraube nutzt und darstellt, welche Schrauben zu welchem Bauteil geh\u00f6ren. Dabei kann eine bestimmte Schraube zu mehreren verschiedenen Bauteilen geh\u00f6ren. 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\u00fcpft.<\/p>\n

    \"Relationenmodell<\/a><\/p>\n

    Abb. 2: Beispiel eines Relationenmodells f\u00fcr die Datenmodellierung der Beziehungen zwischen Schrauben und Bauteilen<\/em><\/p>\n

    Auf diese Art und Weise k\u00f6nnen alle Objekte eines Unternehmens und die Beziehungen zwischen den Objekten beschrieben werden. Das Relationenmodell l\u00e4sst sich direkt in eine relationales Datenbankmanagementsystem umsetzen, das w\u00e4re dann die Implementierung der Ergebnisses der Datenmodellierung.<\/p>\n

    Ein einfaches Entity-Relationship-Modell<\/h3>\n

    In der Beschreibungsebene Fachkonzept der Perspektive Daten im Ordnungsrahmen ARIS interessiert man sich noch nicht f\u00fcr die konkreten Auspr\u00e4gungen der Datens\u00e4tze und betrachtet daher nur modellhaft die Klassen der Objekte. F\u00fcr die Visualisierung sind Entity-Relationship-Diagramme (ERD) geeignet, und eine modellhafte Erfassung eines Realweltausschnittes hei\u00dft Entity-Relationship-Modell (ERM). Diese Betrachtung der Daten entwickelte Peter Chen [2] am MIT in 1976.<\/p>\n

    F\u00fcr das Beispiel der Schrauben s\u00e4he ein ERD wie in Abb. 3 aus.<\/p>\n

    \"sehr<\/a><\/p>\n

    Abb. 3: Beispiel f\u00fcr ein einfaches Entity-Relationship-Modell am Beispiel Schrauben<\/em><\/p>\n

    Ein nicht ganz so einfaches ER-Modell<\/h3>\n

    F\u00fcr die Beziehungen zwischen Schrauben und Bauteilen k\u00f6nnte ein ERD wie in Abb. 4 dienen. Hier sehen Sie eine einfache eins-zu-eins-Zuordnung von Entit\u00e4tstypen und Relationentypen zu den Relationen. Das ist m\u00f6glich, da Relationentypen des ERD auch als Tabellen bzw. als Relationen dargestellt werden k\u00f6nnen. Es gibt durchaus Situationen, in denen einen einfache eins-zu-eins-Zuordnung nicht sinnvoll ist.<\/p>\n

    \"ER-Diagramm<\/a><\/p>\n

    Abb. 4: Beispiel f\u00fcr ein Entity-Relationship-Modell f\u00fcr die Beziehung zwischen Schrauben und Bauteilen<\/em><\/p>\n

    Umsetzung in ein Relationenmodell<\/h3>\n

    Relationentypen (Achtung, nicht mit den Codd’schen Relationen verwechseln) sind neben den Entit\u00e4tsytypen der zweite Knotentyp in ER-Modellen. Relationentypen bezeichnen, in welcher Beziehung Entit\u00e4tstypen stehen und haben meist die Ids der beteiligten Entit\u00e4tstypen als Attribute (in Abb. 4 der \u00dcbersichtlichkeit halber nicht eingezeichnet). \u00dcberraschend ist, dass Relationentypen auch eigene Attribute haben k\u00f6nnen.<\/p>\n

    Um festzulegen, mit wie vielen Entit\u00e4ten des anderen Entit\u00e4ststyps (hier bauteil) ein Entit\u00e4sttyp des einen Entit\u00e4tstyps (hier schraube) verbunden sein kann, sind die sogenannten Kardinalit\u00e4ten in der ISO-min-max-Schreibweise angegeben. Eine andere, oft verwendete Schreibweise, ist die Chen-Notation f\u00fcr Kardinalit\u00e4ten. Die Angabe der Kardinalit\u00e4ten zwingt zu einer intensiven Befassung mit den fachlichen Fragestellungen, z. B. ob ein Bauteil noch zum Entit\u00e4tstyp Bauteil geh\u00f6rt, wenn es keine Schrauben ben\u00f6tigt. Wenn es keine Schrauben ben\u00f6tigt, so w\u00e4re die Kardinalit\u00e4t gleich (0,*). Im Falle dass Schrauben zwingend vorausgesetzt werden, w\u00e4re die Kardinalit\u00e4t gleich (1,*). Ebenso kann auch die Menge der Verbindungen begrenzt sein. Sind z. B maximal 30 Schrauben pro Bauteil m\u00f6glich, lautet die Kardinalit\u00e4t am Entit\u00e4tstyp bauteil gleich (0,30). Bei beliebig vielen Schrauben ist die Kardinalit\u00e4t gleich (0,*) oder gleichbedeutend (0,n).<\/p>\n

    Datenmodellierung einer einfache Liste<\/h2>\n

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

    021514 6782453
    \n021541 6254273
    \n015772 62444902<\/p>\n

    Abb. 5: Beispiel Liste mit Telefonnummern in eine Textdatei mit Namen telefonnummern.txt<\/em><\/p>\n

    F\u00fcr eine einfache Liste gibt es nur eine Spaltenbezeichnung, das k\u00f6nnte z.B. „telefonnr“ sein, da eine Liste eine Tabelle mit nur einer Spalte ist.<\/p>\n

    Die Relation k\u00f6nnte „telefonnr“ hei\u00dfen. Die Relation hat nur ein Attribut „nr“. Das Relationenmodell f\u00fcr die einfache Liste s\u00e4he dann wie in Abb. 6 aus.<\/p>\n

    \"Sehr<\/a><\/p>\n

    Abb. 6: Relationenmodell f\u00fcr eine einfache Telefonliste<\/em><\/p>\n

    Das Entity-Realtionship-Modell f\u00fcr die Telefonliste ist, wie Abb. 7 zeigt, ebenfalls sehr einfach. Es gibt nur eine Klasse von Objekten entsprechend dem Entit\u00e4tstyp „telefonnr“. Ein Objekt (eine Entit\u00e4t) hat nur eine Eigenschaft ausgedr\u00fcckt durch das Attribut „nr“.<\/p>\n

    \"sehr<\/a><\/p>\n

    Abb. 7: ER-Modell f\u00fcr eine einfache Telefonliste<\/em><\/p>\n

    Eine einfache Tabelle<\/h3>\n

    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\u00e4tze g\u00e4be, kann man eine eindeutige id vergeben wie in Abb. 8.<\/p>\n

    001;Kurt;0215187837
    \n002;Kurt;0215187837
    \n003;Emma;021387215
    \n004;Karl;02431478372
    \n…<\/p>\n

    Abb. 8.<\/em>\u00a0Beispiel tabellenartige Sammlung von Telefonnummern mit Namen<\/em><\/p>\n

    Die Umsetzung in ein Relationenmodell ist in Abb. 9 gezeigt.<\/p>\n

    \"\"<\/a><\/p>\n

    Abb. 9 Relationenmodell f\u00fcr eine Telefonnummernsammlung in Tabellenform<\/em><\/p>\n

    Das ER-Modell besteht wiederum nur aus dem einen Entit\u00e4tstypen telefonnr. Es sind nun als Attribute die id und der Namen hinzugekommen.<\/p>\n

    \"\"<\/a><\/p>\n

    Abb. 10: ER-Modell f\u00fcr eine Telefonnummernsammlung in Tabellenform<\/em><\/p>\n

    Zwei Tabellen verkn\u00fcpfen<\/h3>\n

    Wenn nun Smartphones Einzug halten und eine Person mehrere Telefone hat, so gibt es mehrere M\u00f6glichkeiten, diesen Sachverhalt im Relationenmodell zu ber\u00fccksichtigen. Es ist keine Option, die zweite Telefonnummer einfach hinter die erste mit in die gleiche Tabellenzelle zu schreiben, da damit die Atomarit\u00e4t verletzt w\u00e4re. Die L\u00f6sung k\u00f6nnte jedoch im Hinzuf\u00fcgen einer weiteren Spalte f\u00fcr die Mobilnummer bestehen. Kommt aber dann ein Tablet mit mit einer weiteren Telefonnummer hinzu, m\u00fcsste Sie wiederum das Datenmodell \u00e4ndern. Um flexibel auf diese Anforderungen zu reagieren, teilen Sie besser die\u00a0 Tabelle telefonnr\u00a0 in zwei Relationen „person“ und „telefon“ wie in Abb. 11. Die Relation Telefon erh\u00e4lt ein Attribut „eigenschaft“, mit dem Sie festelegen, ob es sich um eine Festnetznummer oder um eine Mobilnetznummer handelt.<\/p>\n

    \"Datenmodellierung<\/a><\/p>\n

    Abb. 11: Relationenmodell f\u00fcr den Fall mehrer Telefonnumern je Person<\/em><\/p>\n

    \"Datenmodellierung<\/a><\/p>\n

    Abb. 12: ER-Modell f\u00fcr den Fall mehrerer Telefonnummern je Person<\/em><\/p>\n

    Weitere M\u00f6glichkeiten von Datenmodellierung mit\u00a0 Relationen- und ER-Modellen<\/span><\/h2>\n

    Mit den hier dargestellten M\u00f6glichkeiten k\u00f6nnen Sie schon die Daten der meisten (kleinen) Informationssysteme ausreichend beschreiben. Hinsichtlich der Relationenmodelle w\u00e4re es f\u00fcr eine vollst\u00e4ndige theoretische Betrachtung erforderlich, die sogenannten Normalfomen zu besprechen. In der Praxis zeigt sich jedoch, dass die konsequente Ber\u00fccksichtigung lediglich der ersten Normalform, n\u00e4mlich die Atomarit\u00e4t, schon zu brauchbaren Datenmodellen f\u00fchrt. Insbesondere Performance-Optimierung f\u00fchren 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\u00fchrt, die die Anwendungsprogrammierung sehr kompliziert macht.<\/p>\n

    ER-Modelle k\u00f6nnen noch viel mehr, so gibt es noch Generalisierung, Spezialisierung, Aggregation und Zerlegung. Ebenso kann man zwischen starken und schwachen Entit\u00e4tstypen unterscheiden. Eine „\u00dcbermodellierung“ sollten Sie jedoch vermeiden, weil sie die Umsetzung in ein Datenbanksystem erschwert.<\/p>\n

    Auch bei der Datenmodellierung soll die Faustformel gelten: Am Besten ist es so einfach, dass es gerade noch nicht g\u00e4nzlich falsch ist.<\/p>\n

    Quellen:<\/h2>\n

    Videos auf youtube<\/h3>\n

    ERM Entity Relationship Modellierung am Beispiel – \u00dcberblick:\u00a0https:\/\/youtu.be\/8NTAq8N_jQc<\/a><\/p>\n

    ERM Entity Relationship Modellierung am Beispiel 1 –\u00a0 Grundbegriffe:\u00a0https:\/\/youtu.be\/d2tWsd_AbHo<\/a><\/p>\n

    ERM Entity Relationship Modellierung am Beispiel 2 –\u00a01:1 Beziehung Tanzkurs:\u00a0https:\/\/youtu.be\/O9LbBo012wE<\/a><\/p>\n

    ERM Entity Relationship Modellierung am Beispiel 3 – 1:n Beziehung Schulklasse:\u00a0https:\/\/youtu.be\/FEuzVIyGb_M<\/a><\/p>\n

    ERM Entity Relationship Modellierung am Beispiel 4 – m:n Beziehung Kursverwaltung:\u00a0https:\/\/youtu.be\/BABMI69NSx0<\/a><\/p>\n

    ERM Entity Relationship Modellierung am Beispiel 5 – komplizierteres Modell der Kursverwaltung:\u00a0https:\/\/youtu.be\/Y-GIspXg3TE<\/a><\/p>\n

    Literatur zur Datenmodellierung:<\/h3>\n

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

    [2] Chen Pin-Shan, Peter (1976) The Entity-relationship Model\u2014Toward a Unified View of Data.<\/em> In: ACM Trans. Database Syst. Band 1, Nr. 1, 03.1976, S. 9\u201336, doi:10.1145\/320434.320440.<\/p>\n

    Andere Modellierungsnotationen<\/h3>\n

    Gesch\u00e4ftsprozessmodellierung mit eEPK (erweiterte Ereignisgesteuerte Prozessketten<\/a>)<\/p>\n

    Fallstudien f\u00fcr die Anwendung der Datenmodellierung<\/h3>\n

    Kaffeemanufaktur \u201eKleiner Schwarzer\u201c \u2013 Eine Fallstudie f\u00fcr die Wirtschaftsinformatik<\/a><\/p>\n

    Baumeister7x24 \u2013 Eine Fallstudie f\u00fcr die Wirtschaftsinformatik<\/a><\/p>\n

    Tabakgarage \u2013 Eine Fallstudie f\u00fcr die Wirtschaftsinformatik<\/a><\/p>\n

    <\/p>\n

    Teile diesen Beitrag.<\/div>