Einführung in die Datenmodellierung
Dieser Artikel zeigt anhand konkreter Beispiele wie Datenmodellierung genutzt werden kann, um vorhandene Informationen zu analysieren und deren Struktur zu visualisieren und um Sachverhalte der Realität in Form von Daten zu beschreiben und festzuhalten.
Was haben wir denn da?
Als Data-Analystin erhalte ich folgende Daten, die ich auf Auffälligkeiten untersuchen muss.
Tabelle 1: Beispiel Kontobestände
| A | B | C | D |
| Tag | Konto | Kunde | Bestand |
| 02.02.17 | 47-235-12 | Anna Muster | 242.55 |
| 03.02.17 | 47-235-12 | Anna Muster | 642.55 |
| 06.02.17 | 47-235-12 | Anna Muster | 478.35 |
| 02.02.17 | 20-888-11 | Anna Muster | 1443.75 |
| 03.02.17 | 20-888-11 | Anna Muster | 1443.75 |
| 06.02.17 | 20-888-11 | Anna Muster | 1443.75 |
Bevor ich mit der zuständigen Person Kontakt aufnehme, schaue ich mir die Daten an und versuche diese zu beschreiben. Hier das Ergebnis: Es gibt Kunden und Konten sowie Bestände. Die Bestände können je nach Kalendertag variieren. Somit habe ich auch einen Faktor Zeit, der auf die Bestände einen Einfluss hat.
Als nächsten Schritt versuche ich, graphisch darzustellen, welche Information gegeben ist und wie diese zusammenhängt.
Ich sehe Konten, Kunden und Bestände, die an unterschiedlichen Tagen unterschiedlich sein können:
Was nun fehlt, sind die Zusammenhänge zwischen den Einträgen. Ich stelle fest, dass die Kundin mehrere Konten hat und ein Konto mehrere Beträge. Diese Einträge werden Entitäten genannt und können graphisch dargestellt werden. So erhalte ich folgendes Diagramm:
Schon habe ich mein erstes ERD. Das ist das Entity-Relationship-Diagram oder zu deutsch Entitäten-Beziehungen-Diagramm. Dieses beschreibt, welche Dinge ich habe und wie diese zusammenhängen.
Rücksprache mit dem Kunden
Mit meinem ersten Datenmodell gehe ich zum Kunden, um dieses zu besprechen. Es kommt die Frage, was die Eins und was das m bedeutet. So erkläre ich, dass ein Kunde mehrere – also m – Konten haben kann, ein Konto aber zu genau einem – also 1 – Kunden gehört. Ein Konto kann m Bestände haben und ein Bestand zu 1 Konto gehören. Die Entität Bestand besitzt auch das Attribut Tag, um anzugeben, an welchem Tag der Bestand gilt.
Der Kunde runzelt kurz die Stirn und erklärt, dass ein Konto auch zu mehreren Kunden gehören kann und dass beim Konto auch der Kontotyp wichtig ist, obwohl das im gegebenen Datenbeispiel nicht vorhanden ist.
Am Ende der Besprechung haben wir folgendes konsolidiertes ERD:
Wie wird ein Datenmodell geschrieben
Wie wir am Beispiel gesehen haben, erstellen wir ein Modell für Daten. Dabei halten wir fest, zu welchen Entitäten wir welche Daten haben. Die Daten beschreibend die Entitäten in Form von Werten für definierte Eigenschaften, die wir Attribut nennen. So hat die Entität Person das Attribut Name, der in unserem Beispiel den Wert Anna Muster hat.
Definition Entität
Der Begriff Entität leitet sich aus dem Lateinischen ab und bedeutet "Seiendes" oder "Ding". In der Informatik ist eine Entität ein eindeutig identifizierbares, einzelnes Informationsobjekt. Entitäten können sowohl reale Dinge oder Personen als auch abstrakte Objekte sein [1].
Neben den Entitäten mit ihren Attributen sind die Beziehungen zwischen den Entitäten wichtig. Diese Beziehungen werden im Englischen Relationship genannt. Erstellen wir ein Modell, das Entitäten und Beziehungen enthält, erhalten wir ein "Entity-Relationship-Model" oder kurz das ERM. Oft wird dies auch "Entity-Relationship-Diagram" oder kurz das ERD genannt.
Für ein ERD gibt es verschiedene Notationen. In einem ersten Schritt sind vor allem die Entitäten und Beziehungen wichtig. Die Attribute können noch weggelassen werden oder es werden nur die wichtigsten Attribute gezeichnet. Dazu eignet sich die Chen- Notationen, die in Abb. 1-3 verwendet wurden.
Wird das Modell weiter verfeinert und mit mehr Attributen ergänzt, so eignet sich die UML-Notation, die Attribute kompakter als Liste darstellt. Wenn wir unser Beispiel weiter analysieren, so können wir den Entitäten weitere Attribute zuordnen.
Vergleichen wir die Chen-Notation mit der UML-Notation, so stellen wir verschiedene Unterschiede fest. Bei den Attributen wird mit {ID} festgehalten, welches der eindeutige Schlüssel ist. Das ist ein Attribut oder die Kombination von Attributen, die für eine Ausprägung einer Entität einmalig ist und diese identifiziert. Dann kann bei den Attributen auch festgelegt werden, ob diese leer sein dürfen [0..1] oder gefüllt sein müssen [1]. In der eckigen Klammer steht links die minimale Anzahl und rechts die maximale Anzahl. Wenn beides 1 ist, so kann dies abgekürzt werden. Diese Notation wird auch bei den Beziehungen genutzt, um anzugeben, wie viele Dinge auf jeder Seite der Beziehung vorkommen können. Diese Anzahl wird auch Multiplizität oder Kardinalität einer Beziehung genannt.
Wenn wir nun beim Bestand genauer hinschauen, sehen wir, dass der Tag als Schlüssel markiert ist. Wenn wir unser Datenbeispiel anschauen, wird aber klar, dass der Tag einen Bestand nicht eindeutig identifiziert. Nur mit dem Konto zusammen ist der Tag ein eindeutiger Schlüssel. Dies wird mit dem {ID} in der Beziehung notiert.
Wie wird ein Datenmodell gelesen?
Damit kennen wir die Elemente und die UML-Notation eines ERD und können versuchen, ein weiteres Beispiel zu lesen.
Als Erstes lesen wir "nur" die Entitäten und wie diese zusammenhängen. Da haben wir Biere, Zutaten und Rezepte. Ein Rezept verwendet genau eine Zutat und wird für genau ein Bier verwendet. Ein Bier kann aber mehrere Rezepte haben. Das scheint verwirrend zu sein. Für mich sagt ein Rezept für ein Bier, wie viel Wasser, wie viel Malz, wie viel Hopfen und wie viel Hefe benötigt wird. In meiner Interpretation von Rezept hat dieses mehrere Zeilen, je Zutat eine. Das bedeutet also, dass hier das Rezept nicht das gesamte Rezept ist, sondern jede einzelne Rezeptzeile. Wir sehen, dass eine genaue Beschreibung einer Entität für das Verständnis wichtig ist. Hier bedeutet Rezept, dass wir die einzelnen Rezeptzeilen speichern wollen. Betrachten wir nun die Attribute, so macht das Sinn. In jeder Rezeptzeile wird angegeben, welche Menge der jeweiligen Zutat benötigt wird.
Als nächstes betrachten wir die weiteren Attribute. Ein Bier muss eine Nummer, einen Namen und den Alkoholgehalt haben. Der Stil, Kommentar und Preis sind fakultativ, kann aber angegeben werden. Bei der Zutat müssen wir neben der Nummer auch eine Bezeichnung und die Art angeben.
Wie sehen die eindeutigen Schlüssel aus? Beim Bier ist das die Nummer des Bieres, bei der Zutat die Nummer der Zutat. Beim Rezept haben wir kein Attribut, das als Schlüssel markiert ist. Dafür sind beide Beziehungen als {ID} markiert. Das bedeutet, dass für das Rezept respektive für die Rezeptzeile die Kombination von Bier und Zutat eindeutig sind.
Das Problem der Viele-zu-viele-Beziehung
Wenn wir das Beispiel Bierrezept ganz ohne Attribute zeichnen, so können wir das auf zwei Entitäten reduzieren.
Ein Bier hat mehrere Zutaten und eine Zutat kommt in mehreren Bieren vor. Die Beziehung kann auch direkt als Rezept bezeichnet werden, um das Modell aussagekräftiger zu zeichnen. Wir haben hier also eine N:N- oder Viele-zu-viele-Beziehung. Sobald diese Beziehung wie bei dem Rezept eigene Attribute hat, so macht man daraus normalerweise eine Entität. Wie sieht das aus, wenn die Beziehung keine Attribute hat? Können wir diese auch als Entität abbilden?
Betrachten wir dazu nochmals unser Beispiel mit Kunde und Konto. Ein Konto kann mehreren Kunden gehören, kann also mehrere Kontoinhaber haben. Ein Kunde kann mehrere Konten haben, kann also mehrfach Kontoinhaber sein. Kontoinhaber wird somit zur Entität, die festlegt, welcher Kunde Inhaber welches Kontos ist. Das ergibt folgendes ERD:
Entwurf von Datenbanken
In der Praxis kommt es häufig vor, dass wir basierend auf schriftlich festgehaltenen Anforderungen ein Datenmodell erstellen müssen. Betrachten wir ein Beispiel.
- Wir wollen eine Datenbank entwickeln, die Messwerte von Sensoren sammelt, um sie zu analysieren. Zuerst müssen wir überlegen, was wir genau unter einem Sensor verstehen. Das Problem ist, dass es Sensoren gibt, die genau einen Wert – wie die Temperatur – messen. Dann haben wir Sensoren, die mehrere Dinge gleichzeitig messen, und wir haben sogenannte Boxen, die mehrere Sensoren enthalten. Um eine einfache und flexible Möglichkeit zu haben, die Werte zu speichern, speichern wir jeden Messwert. Das bedeutet, dass wir den Sensor als die Einheit definieren, die jeweils einen einzelnen Wert misst. Oft sind mehrere verschiedene Sensoren in einer Box oder in einem komplexen Sensor zusammengefasst. Außerdem kann eine Box an einem bestimmten Ort platziert werden. Wir gehen davon aus, dass wir auch mobile Boxen haben, die zu unterschiedlichen Zeiten an unterschiedlichen Orten platziert sind. Wir wissen jeweils von wann (valid_from) bis wann (valid_to) eine Box an welchem Ort platziert ist.
Um aus dieser Beschreibung ein Datenmodell zu erstellen, müssen wir zuerst die Entitäten finden. Dazu lesen wir den Text nochmals und markieren uns die Hauptwörter. Das sind Kandidaten für Entitäten oder Attribute. Wir finden folgende Worte: Messwert oder Wert, Sensor, Temperatur, Box, Einheit, Ansammlung, Ort.
Messwert und Wert scheinen identisch zu sein und werden in einer Einheit gemessen, Temperatur ist ein Beispiel dafür. Diese Dinge gehören also zusammen und wir nennen dies Messwert. Dann haben wir Sensoren, die in einer Box zusammengefasst werden können. Das ergibt die Entität Box. Weiter gibt es den Ort, an dem Boxen platziert sein können. Wenn wir nun diese Entitäten aufzeichnen und die Beziehungen überlegen, kommen wir zum Datenmodell der Abb. 8 auf der linken Seite. Damit wir nun die Attribute definieren können, müssen wir weitere Angaben haben. Diese sind hier:
- Damit einfach überprüfbar wird, von wann bis wann eine Box an welchem Ort platziert war, hat jede Box und jeder Ort eine ID. Die Box muss weiter einen Namen haben. Bei Ort wollen wir neben dem Namen, der zwingend ist, auch die geographischen Koordinaten, den Typ des Ortes (Indoor, outdoor) und eine Beschreibung hinterlegen können.
Die Sensoren haben ebenfalls eine ID und einen Namen. Weiter müssen wir wissen, von welchem Typ der Sensor ist und in welcher Einheit dieser misst. Beispielsweise kann ein Temperatursensor in Celsius oder Fahrenheit messen. Der Messwert setzt sich aus dem gemessenen Wert und einem Zeitstempel zusammen. Damit ein Messwert sicher eindeutig ist, wird dieser mit einer ID versehen
Damit können wir unser vereinfachtes ERD erweitern und mit den Attributen ergänzen. Dies ergibt das vollständige ERD rechts in der Abb. 8.
Zusammenfassung
Datenmodelle zeigen auf, welche Informationen vorhanden sind und wie diese zusammenhängen. Datenmodelle werden genutzt, um vorhandene Datenquellen zu beschreiben und um Datenbanken zu modellieren. Datenmodelle helfen, festzulegen, welche Informationen überhaupt in einem entsprechenden Zusammenhang relevant sind und wie diese gruppiert und geordnet werden können.
Um ein Datenmodell zu verstehen oder ein Datenmodell zu erstellen, braucht es vor allem Wissen im Anwendungsgebiet. Wer Daten zu einem Orchester modellieren will, muss etwas über Orchester wissen. Gleichzeitig muss aber auch bekannt sein, was Entitäten sind und wie diese im Kontext gefunden und definiert werden können.
Daher braucht es zum Erstellen von Datenmodellen immer Fachpersonen der Anwendung als auch Fachpersonen der Informatik. Die Modellierung ist ein gemeinsamer Prozess, das Datenmodell als ERD eine Form der Darstellung, die für alle verständlich und nachvollziehbar ist.
