Schlagwort-Archive: Relation

Daten und Datenmodellierung (3)

Zurück zu Teil 1
Zurück zu Teil 2

Teil 3: Daten modellieren mit ERM und Relationenmodell

Motivation für die Datenmodellierung

Im ersten Teil der Serie wurden Daten im Dateisystem vorgestellt. Insbesondere bei strukturierten Daten in RDBMS stellt sich aus betriebswirtschaftlich / fachlicher Sicht die Frage, wie die Konzeption einer Datenbank und ihr Bezug zu Objekten aus der realen Welt hergestellt werden kann. Der Start in die Entwicklung eines Betrieblichen Anwendungssystems umfasst 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. Ein Datenmodell visualisiert die Beziehungen zwischen den Objekten, beschreibt, durch welche Attribute die Objekte beschrieben werden und reduziert so die Komplexität. Während Anwendungsprogramme zuweilen schon nach wenigen Betriebsjahren erneuert werden, ändert sich die Struktur von Daten nur wenig und selten. Insbesondere bei den Stammdaten bei Banken und Versicherungen ist das zu beobachten. Da Datenmodelle so stabil und langlebig sind, verdienen sie besondere Aufmerksamkeit.

Bei einem bestehenden Anwendungssystem wird die Datenmodellierung zur Analyse  eingesetzt, um das (ggf. unzureichend dokumentierte) Anwendungssystem besser verstehen zu können.

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 das 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 am Beispiel

Grundsätzliches zum Relationenmodell

Eine Relation ist die Basis der von Edgar F. Codd entwickelten relationalen Algebra [1]. Eine Relation besteht aus Attributen und Tupeln. 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

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 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 Beziehungen zwischen Schrauben und Bauteilen

Auf diese Art und Weise könen alle Objekte eines Unternehmens und die Beziehungen zwischen den Objekten beschrieben werden. Das Relationenmodell kann direkt in einem relationalen Datenbankmanagementsystem umgesetzt werden.

Grundsätzliches zum 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 nur modellhaft die Klassen der Objekte. Für die Visualisierung sind Entity-Relationship-Diagramme (ERD) geeignet, eine modellhafte Erfassung eines Realweltausschnittes heißt Entity-Relationship-Modell (ERM). Diese Betrachtung der Daten wurde von Peter Chen [2] am MIT in 1976 entwickelt

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

Für die Beziehungen zwischen Schrauben und Bauteilen könnte ein ERD wie in Abb. 4 dienen. Hier sieht man 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

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

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 Schreibweise, die oft verwendet wird, 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, wäre die Kardinalität (0,*), wenn Schrauben zwingend vorausgesetzt werden, (1,*). Ebenso kann die Menge der Verbindungen begrenzt sein. Sind z. B maximal 30 Schrauben pro Bauteil möglich, lautet die Kardinalität am Entitätstyp bauteil (0,30), sind beliebig viele Schrauben möglich, (0,*) oder (0,n).

Eine 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, gibt es mehrere Möglichkeiten, das im Relationenmodell zu berücksichtigen. Keine Option ist, 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 im Hinzufügen einer weiteren Spalte für die Mobilnummer bestehen. Kommt aber dann ein Tablet mit mit einer weiteren Nummer hinzu, müsste wiederum das Datenmodell verändert werden. Um flexibel auf diese Anforderungen zu reagieren, wird die Tabelle telefonnr aufgeteilt in zwei Relationen „person“ und „telefon“ wie in Abb. 11. Die Relation Telefon erhält ein Attribut „eigenschaft“, mit dem festgelegt wird, 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 Relationen- und ER-Modellen

Mit den hier dargestellten Möglichkeiten wird man schon die die Daten der meisten (kleinen) Informationssysteme ausreichend beschreiben können. Hinsichtlich der Relationenmodelle wäre es für eine vollständige Theoretische Betrachtung erforderlich, die sogenannten Normalfomen zu besprechen. In der Praxis zeigt sich, dass die konsequente Berücksichtigung lediglich der ersten Normalform, namlich die Atomarität, zu brauchbaren Datenmodellen führt. Insbesonders Performanceoptimierung bedingen, dass von einer intensiven Normalisierung Abstand genommen wird. Im Bankenumfeld haben wir seinerzeit konsequent auf die dritte Normalform verzichtet, da sie zu einer Unzahl von Tabellen mit wenigen Spalten führt, die die Anwendungsprogrammierung sehr kompliziert macht.

ER-Modell können noch viel mehr. So gibt es noch Generalisierung, Spezialisierung, Aggregation und Zerlegung. Ebenso kann man zwischen starken und schwachen Entitätstypen unterscheiden. Das führt dann oft zu „esotherischen“ Modellen, die eine Implementierung stark erschweren (wie z.B. bei der Neuentwicklung der NRW Landesdatenbank und bei der Neuentwicklung des NRW Bezügeverfahrens zu beobachten war).

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:

[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.