Let the music play: Wie hängen Sachen eigentlich zusammen – inhaltlich und logisch? Das ERM

Dieser Beitrag ist Teil der Fallstudie „Let the music play“.

Inhaltliche Zusammenhänge aufschreiben statt Hörensagen

Am Anfang unserer Fallstudie (siehe hier) steht eine wild zusammengewürfelte Tabelle mit Alben, Artists und Tracks. Also alles steckt irgendwie in einem großen Haufen zusammen.

Wie häufig in der Realität auch: Jeder kennt vielleicht einen Teil des Gesamtbildes, es gibt keine Übersicht über die Daten, ihre Zusammenhänge und stattdessen wird über Abläufe diskutiert (in unserem Beispiel wären das Diskussionen über neue Alben ohne zu wissen ob da ein Künstler oder Tracks dazu da ist).

Um über die Zusammenhänge in den Daten zu sprechen, müssen wir uns diese bewusst machen.1 Im Beispiel unserer Fallstudie bedeutet das:

  • Es gibt Artists als Musikschaffende
  • Jeder Artist hat einen Namen und für den jeweiligen Lead Artist (bspw. bei einer Band) hat ein uns bekanntes Geburtsjahr
  • Ein Artist kann bereits ein Album oder mehrere Alben herausgebracht haben – muss aber nicht, wir könnten auch Artists ohne Album im Bestand haben
  • Jedes Album kommt von genau einem Artist (ja hier vereinfacht die Fallstudie gegenüber der Realität mit Kollaborationen) und hat einen Namen
  • Zu jedem Album gibt es irgendwann einen oder mehrere Tracks, am Anfang kann das Album aber auch nur eine Idee sein
  • Jeder Track kommt auf genau ein Album und hat einen Namen

Erste Erkenntnis: Es scheint verschiedene Dinge zu geben, die bestimmte Eigenschaften haben. Und dann stehen diese Dinge in Beziehungen zu einander. Die Dinge nennen wir ab jetzt Entitäten (wissenschaftlich präzise jeweils ein entity set als Menge von entities – in der Praxis wird das nicht unterschieden und hier sind wir praktisch unterwegs) und die Beziehungen bezeichnen wir als Relationen.

Zweite Erkenntnis: Ziemlich viel Text. Und das für ein einfaches Beispiel. Das wird irgendwann auch unübersichtlich beim Lesen und es heißt doch immer: Ein Bild sagt mehr als tausend Worte.

Vom Text zum Bild: Entity-Relationship-Diagram/Model (ERD/ERM)

Für das Beschreiben von Entitäten und Relationen hat sich ein De-Facto-Standard gebildet im Lauf der Zeit: das Entity-Relationship-Diagram (ERD) oder auch Entity-Relationship-Model (ERM). In der Praxis werden beide Begriffe synonym verwendet. Auch wenn das Diagram eigentlich nur der grafisch ausgedrückte Teil ist und das Model zusätzlich noch eine Beschreibung der Elemente im Diagram umfasst.2

Praktisch (und da sind sich alle einig) gelten folgende Regeln für das „Malen“ eines ERD/ERM:

  1. Entitäten sind Rechtecke (d.h. alle Dinge werden eckig 😉 )
  2. Für Beziehungen werden die Entitäten (Rechtecke) mit Linien verbunden (das sind dann Relationen)

Das würde dann in unserem Beispiel zu diesem Bild führen:

Vorstufe zum ERM mit drei Entitäten
Drei Entitäten sind da und verbunden – Relationen sind sichtbar aber noch nicht beschrieben

Mehr Details zu Beziehungen und Eigenschaften

Auf der Grundlage aus Entitäten und Relationen sind dann „nur“ noch diese Informationen zu ergänzen:

  1. Für jede Entität (also jedes „Ding“) sollte festgehalten welche Eigenschaften wir als Attribute festhalten möchten. In unserem Beispiel wäre das dann etwa der Name eines Albums.
  2. An bzw. mit den Linien sollte beschrieben werden wie oft jeder „Teilnehmer“ an der Beziehung teilhaben kann (die Kardinalität). Also wie viele Alben darf ein Künstler haben und wie viele Künstler hat ein Album müsste geklärt werden.

Und praktisch wird’s jetzt unterschiedlich

Und wie jetzt genau mit den Relationen, ihren Kardinalitäten und den Attributen umgegangen wird: Darüber besteht keine Einigkeit bzw. gibt es in der Praxis unterschiedliche Ansätze:

  1. Wo und wie werden eigentlich Eigenschaften der Entitäten – die Attribute (bspw. der Name eines Albums) – aufgeschrieben?
  2. Werden Beziehungen/Relationen „benannt“ oder bekommen sie ein eigenes Symbol spendiert zwischen den Entitäten-Rechtecken?
  3. Und wie werden diese Kardinalitäten jetzt genau beschrieben? Durch grafische Symbole (Pfeile, Rechtecke, ausgefüllte oder nicht ausgefüllte Pfeilenden, usw.) oder numerisch? Und wenn numerisch, in welche Richtung beschrieben und unter Angabe einer Mindest- und Maximalanzahl?

In diesem Artikel wird für diese Punkte an die Notation von Chen (der Erfinder dieser Modelle) angelehnt. Diese Notation ist recht leicht zu verstehen und kann auch mit PowerPoint (oder einem anderen Präsentationsprogramm) oder mit einer Vielzahl von Online-Werkzeugen (beispielsweise Creatly) schnell erstellt werden.

Attribute braucht’s – sonst sind es leere Hüllen

Für jede Entität werden die notwendigen (und relevanten) Eigenschaften als Attribut aufgeschrieben. Dabei haben sich zwei Ansätze für die Darstellung rausgebildet:

  • Darstellung als Sprechblasen: jeweils ein Attribut wird in ein Oval geschrieben und mit einer Linie an die Entität „gehängt“
  • Alles im Entitäten-Kasten: Der Entitätenkasten wird in die Überschrift (den Namen der Entität) und eine Liste der Attribute unterteilt

In beiden Fällen werden die Bestandteile des Primärschlüssels (über den ein Eintrag später eindeutig wiedergefunden wird, siehe auch hier bei der Normalisierung) unterstrichen. Das sieht dann im Beispiel für das Album so aus:

Links: Darstellung mit ovalen „Sprechblasen“ // rechts: Darstellung im Entitäten-Kasten

Beide Darstellungen haben ihre Vorteile: Die Darstellung mit Sprechblasen ist praktischer für interaktive Diskussionen und kann beispielsweise auch über Post-Its an einer Wand dargestellt werden (dann sind die vielleicht mal nicht oval sondern einfach eine andere Farbe oder kleiner). Die Kasten-Darstellung kann einfacher um technische Informationen wie Datentypen ergänzt werden und so einfacher in eine technische Darstellung überführt werden. Daher finden sich in der Praxis beide Darstellungen, wobei Entwicklerwerkzeuge für Software in der Regel die Darstellung mit Kästen anbieten.

Gestaltung der Relationen – oder was machen wir hier miteinander?

Um die Zusammenhänge zwischen Entitäten darzustellen, ergänzen wir die Striche zwischen den Entitäten um die Information wie viele Entitäten (präzise wie viele Instanzen der Entitäten) jeweils miteinander in Beziehung stehen. Also die Frage ist es 1 zu 1 oder 1 mit vielen oder viele mit vielen oder eine bestimmte Mindest- und Höchstanzahl auf jeder Seite.

Und was ist jetzt die richtige Darstellung dafür? Die kurze Antwort: Es gibt nicht die eine richtige. Daher heißt es immer sich zu einigen und im Zweifelsfall vorher nachzufragen wie die jeweilige Darstellung gemeint ist.

Der Urform von Chen folgend werden Relationen (präzise jedes relationship set) als Raute (auch Rhombus) zwischen den Entitäten dargestellt. Auf bzw. mit der Verbindung zwischen der Raute und den Entitäten wird jeweils die Kardinalität angegeben. Hierfür empfiehlt der TabellenDoktor folgende Notation:

  • Kardinalitäten werden immer, wie schon in der Urform, numerisch angegeben (nicht durch das Format der Striche oder Strich-Enden) – danach passen wir die Urform etwas an
  • Die Angabe erfolgt in einer min…max-Notation, also es gibt eine Mindestanzahl und eine Höchstgrenze
    • Bei der Mindestanzahl gilt: 0 = kann in der Beziehung sein, muss nicht; 1 = muss mindestens einmal drin sein, usw.
    • Bei der Höchstgrenze bedeuten n oder m beliebig viele; ansonsten gilt die jeweilige Zahl
  • Kardinalitäten werden ausgehend angegeben, d.h. so oft geht diese Entität bei der die min..max-Angabe steht diese Beziehung ein – das ist der häufigste Streitpunkt in der Praxis in welche Richtung das zu lesen ist

In unserem Beispiel darf jeder Artist kein (0) Album bis hin zu beliebig vielen (n) Alben kreieren. Jedes Album wird durch mindestens und höchsten einen Artist hergestellt – also genau einer. Das sieht dann als Ergebnis in der hier gewählten Notation so aus:

Relation zwischen Artist und Albums dargestellt – einmal mit den Attributen in ovalen Sprechblasen, einmal im Kasten; rechts folgt dann jeweils die Verbindung zu Tracks

Kann nicht alleine stehen: Eine schwache Entität

So und jetzt fehlen uns noch die Tracks zu den Alben im Beispiel. Und das ist ein gutes Beispiel für eine weitere interessante Sache: Die schwache Entität. Das ist eine Entität die alleine nicht stehen kann.

Warum? Weil die Inhalte nur mit der Hilfe einer anderen Entität auseinandergehalten werden können. Oder etwas präziser: Der Primärschlüssel der schwachen Entität besteht sowohl aus dem Primärschlüssel der starken, identifizierenden Entität als Fremdschlüssel und einem oder mehreren eigenen Attribut(en). Der Fremdschlüssel wird in einem ERM nicht doppelt eingezeichnet, daher nicht wundern.

In unserem Beispiel gilt das für Tracks: Hier kann der Datensatz für einen Track nur über Album ID und Track eindeutig identifiziert werden. Gleichzeitig ist der Track nur auf genau einem Album. Insgesamt ergibt sich damit als Ergebnis folgendes Entity-Relationship-Diagram (wieder in den beiden Varianten für die Attribute):

Das fertige ERM in beiden Varianten (Box unten, Sprechblasen oben)

Wenn schwache Entitäten zunächst nicht als solche erkannt und modelliert werden ist das übrigens in der Praxis oft nicht so schlimm. Das „entfallene“ Attribut (in unserem Beispiel Album ID) muss am Ende trotzdem in der Datenbank angelegt werden.

Fertig!

Für die Praxis in Beruf, Teams, Schule oder Studium gilt: Vorher absprechen oder nachfragen welche Darstellung gewählt werden soll. Und auch ob es ein Standardwerkzeug gibt. Das Prinzip bleibt gleich, nur die Symbole oder die Position für eine Information ändert sich.

Also das Wichtigste noch einmal in Kürze:

  • Jedes abzubildende „Ding“ wird ein Rechteck eine Entität
  • Beziehungen zwischen Entitäten werden über Relationen (Rauten) dargestellt
  • An die Linie zwischen Rechteck und Raute kommt wie oft ein „Ding“ in Beziehung stehen kann

Viel Erfolg beim Modellieren von Daten! Und immer dran denken: Vorher, dabei und nachher miteinander reden (oder schreiben).

Weitere Beiträge in der Fallstudie drehen sich um Normalisieren von Tabellen und die Umsetzung in SQL.

Fußnoten zum Weiterlesen

  1. Passend dazu habe ich auch einen Artikel (mit)geschrieben, in dem wir argumentieren, dass genau dieses Auseinandersetzten mit den Daten die Grundlage für vieles andere ist: Der Artikel (auf Englisch) findet sich hier auf LinkedIn oder im Medium-Profil meines Co-Autors hier.
  2. Siehe auch die Beschreibung in Wikipedia: „Entity-Relationship-Modell“. Bearbeitungsstand: 3. Februar 2021, 22:41 UTC. URL: https://de.wikipedia.org/w/index.php?title=Entity-Relationship-Modell&oldid=208409620 (Abgerufen: 28. Februar 2021, 13:55 UTC)
  3. Das originale Paper von Chen findet sich hier https://doi.org/10.1145/320434.320440 (leider nicht direkt offen für alle verfügbar) in den ACM Transactions on Database Systems