Datenmodellierung: Wie Sie das Optimum aus Ihren Daten herausholen

Steve Hoberman ist Autor mehrerer Bücher über Datenmodellierungstechniken, darunter befindet sich auch seine jüngste Buchpublikation: Data Modeling for MongoDB: Building Well-Designed and Supportable MongoDB Databases. Neben seiner Tätigkeit als Autor arbeitet Hoberman als Berater, Referent und Ausbilder für Datenmodellierung. 

In diesem Interview erläutert Hobermann zum einen die allgemeinen Herausforderungen, vor denen Unternehmen bei der Erstellung von Datenmodellen stehen. Zum anderen gibt er Tipps zu Datenmodellierungstechniken, die Unternehmen bei der Entwicklung präziser Datenmodelle für operative und Business Intelligence (BI) -Anwendungen unterstützen können. Darunter sind auch Anwendungen, die auf Basis von NoSQL-Datenbanken wie MongoDB laufen.

Wie können Unternehmen entscheiden, welche der verschiedenen Formen von Datenmodellen für ihre Zwecke am besten geeignet sind? Sie sagen, das Modell sollte auf die Zielgruppe ausgerichtet sein – können Sie erklären, welche Modelle für welche Zielgruppen passen?

Steve Hoberman: Eine der Schlüsselaussagen in meinem Buch „Data Modeling for MongoDB“ ist, dass der Modellbauer flexibel sein sollte, was die visuelle Form des Modells betrifft. Zweifellos erfordert es manchmal Mühe, nicht mit den traditionellen Begrifflichkeiten der Datenmodellierung zu hantieren. 

Steve Hoberman,
Autor und Experte im Bereich
Datenmodellierungstechniken

Wenn Sie mit beruflichen Rollen für die Anwendungsentwicklung arbeiten – mit Rollen, die etwa „Daten“, „Entwickler“ oder „Datenbank“ in ihren Berufsbezeichnungen haben – dann ist es okay, traditionelle Datenmodellierungstechniken wie Rahmen und Linien zu verwenden. 

Dazu gehören beispielsweise informationstechnische Begriffe wie die Krähenfußnotation oder die Unified Modeling Language. (Anmerkung: Die Krähenfußnotation; engl. crow's foot notation, ist eine Notation zur semantischen Datenmodellierung, um vereinfachte Entity-Relationship-Modelle darzustellen). Für diese Rollen benutze ich oft konsequent diese Notation – und zwar auf allen drei Modellebenen – der konzeptionellen, der logischen und der physischen Ebene.

Anders ist es bei Rollen, die ein „Business“ in ihrer Berufsbezeichnung haben. Hier ist es zunächst wichtig, herauszufinden, wie wohl sich dieses Publikum mit der traditionellen Notation für Datenmodellierung fühlt. Manchmal kennen Business-Anwender, Business Analysten und ähnliche Experten bereits die herkömmliche Form der Datenmodellierung oder möchten sie lernen. 

Manchmal ist es aber besser, diese Darstellung zu vermeiden, und stattdessen eine Notation zu verwenden, die sie auf jeden Fall verstehen. Wenn Sie mit Financial Business Experten zusammenarbeiten, sollten Sie beispielsweise Tabellenkalkulation als Modellierungsnotation verwenden und manchmal sogar Bilder von den Konzepten (wie das Bild eines Lagerhauses, das das Konzept eines Data Warehouses darstellen kann).

Was sind die größten Herausforderungen, vor denen Unternehmen bei der Generierung eines Datenmodells stehen? Und wie lassen sich diese Herausforderungen in Ihren Augen bewältigen?

Hoberman: Die größte Herausforderung ist es, die Anforderungen an das Datenmodell korrekt zu erfassen. Wenn ein Projekt startet, gibt es oft nur vage Anforderungen, falls Anforderungen überhaupt existieren, und das Datenmodell muss diese Anforderungen vollständig und präzise abbilden. 

Es ist daher eine sehr anspruchsvolle Aufgabe, von Mehrdeutigkeiten und Ungenauigkeiten zu präzisen Definitionen und Konzepten zu kommen. Viele Fragen müssen bei diesem Prozess gestellt und die Ergebnisse müssen dokumentiert werden. 

Das kostet Zeit und vor allem ist dazu Wissen darüber erforderlich, welche Fragen überhaupt gestellt werden müssen. In der Praxis fehlt es den Projekten oft an Zeit und Know-how, um diese Fragen zu beantworten. Datenmodellierung heißt schließlich auch, über das Business etwas zu lernen. Und das ist ein zeitraubender und anspruchsvoller Prozess.

Modelle werden heute für viele verschiedenen Zwecke verwendet wie Risikobegrenzung und Reverse Engineering. Wie hat sich die Rolle des Modellbauers geändert, was muss er heute leisten?

Hoberman: Statt sauber von vorne zu beginnen und Datenmodelle von Grund auf neu zu entwickeln, organisieren wir beim Reverse Engineering Attribute und Regeln auf Basis der Systeme, wie sie heute arbeiten. Der Denkprozess und die zu erbringenden Leistungen sind bei neuen Entwicklungen die gleichen wie beim Reverse Engineering, aber die Ausgangspunkte sind verschieden. 

Bei Risikobegrenzung und Reverse Engineering spielen wir oft die Rolle des „Daten-Archäologen“. Damit ist gemeint, dass wir detektivische Fähigkeiten brauchen, um die Bedeutung eines bestehenden Systemfeldes und die Beziehung des Feldes zu anderen Feldern zu bestimmen.

Wie soll man Präzision erzielen können, wenn es Streit um Definitionen und Spezifikationen gibt? Was würden Sie hier empfehlen?

Hoberman: Es gibt eine Reihe von Techniken, die gut funktionieren, und ich werde kurz zwei vorstellen, die mir am besten gefallen. Eine mir bekannte Modelliererin schreibt alle ihre eigenen Definitionen, und sie schreibt diese Definitionen so präzise, dass sie weiß: Sie sind alle falsch. 

Dann gibt sie ihre Definitionen zur Korrektur ans Business. Warum macht sie das? Nun, sie ist überzeugt, dass es für einen Business-Anwender einfacher ist, eine vorhandene Definition zu korrigieren, als mit einer neuen Definition von Grund auf zu starten. 

Von einem anderen Modellierer weiß ich, dass er darauf besteht, dass Entwicklungsteams erst Terme definieren, bevor sie dem Term einen Namen geben. Um ein Konzept zu benennen, müssen wir erst wissen, was es genau sein soll. Deshalb sollten Sie es erst definieren, und dann benennen. Beide Ansätze sind in meinen Augen sehr effektiv, um präzise Definitionen zu erhalten.

Was sind die Hauptunterschiede bei der Modellierung mit einer relationalen versus einer NoSQL Datenbank?

Hoberman: Bei einem relationalen Datenbank-Managementsystem (RDBMS) ähnelt das Datenbankdesign bezüglich der Struktur oft dem logischen Datenmodell. Die Bereiche, in denen ein RDBMS Datenbank-Design sich von seinem logischen Datenmodell unterscheidet, haben ihre Ursache in erster Linie in den Leistungsänderungen oder den Auswirkungen von Werkzeugen. Ist die Datenbank hingegen eine NoSQL Datenbank, kann das Datenbankdesign hinsichtlich der Struktur dramatisch vom logischen Datenmodell abweichen.

Wie beeinflussen die „Schema-less“ oder „Schema lite“ Merkmal der NoSQL-Datenbanken den Datenmodellierungsprozess?

Hoberman: NoSQL-Datenbanken ermöglichen es uns, neue Felder genauso problemlos einzufügen wie wir Daten einfügen. Das nennt sich „Schema-less“ oder „Schema lite“, und dies ermöglicht es uns, Datenbanken leichter und iterativ aufzubauen, bevor wir das Datenmodell abschließen (und manchmal sogar bevor wir es starten). 

Wenn das Datenbank-Design mit etwas Arbeitsaufwand abgeschlossen ist, dann wird das logische und konzeptionelle Design für Dokumentations- und Support-Zwecke gebaut. Eine schemalose Umgebung macht also manchmal einen Bottom-up-Ansatz möglich, ausgehend von der physikalischen Ebene.

Ein Datenmodell zu erstellen kostet Zeit. Welche Vorteile hat ein Unternehmen davon und welche Komplikationen sollten vermieden werden?

Hoberman: Der entscheidende Vorteil bei der Erstellung eines Datenmodells ist, dass die Daten überhaupt erst verständlich werden, so dass andere sie lesen und daraus etwas lernen können. 

Wenn man so ein präzises Dokument hat, das die Daten erklärt, führt das zu handfesten Geschäftsvorteilen. Beispielsweise werden bei Entwicklung und Support-Kosten gespart und es können leichter höherwertige Systeme aufgebaut werden, die bei hoher Performance die Anforderungen besser erfüllen.

Folgen Sie SearchEnterpriseSoftware.de auch auf Facebook, Twitter und Google+!