Grundlagen der Datenmodellierung: Wo fängt man eigentlich an?

In den meisten Projekten steht die erste Tabelle schneller als die erste Definition. Verständlich — eine Tabelle kann man zeigen, über eine Definition muss man sich erst einigen. Und an dieser Einigung hängt, ob am Ende Antworten herauskommen oder Zahlen, über die drei Abteilungen streiten.

Was ein Datenmodell eigentlich ist

Wenn ich in Coachings frage, was ein Datenmodell ist, kommt fast immer eine Antwort über Tabellen. Meine eigene ist eine andere: ein Modell, in dem wir alle Begriffe eines Unternehmens sammeln, die Beziehungen zwischen den Begriffen und die Regeln dazwischen — in der Sprache des Fachbereichs, nicht in der Sprache der Datenbank oder irgendeines operativen Systems.

Wie das Ding heißt, ist mir dabei ziemlich egal. Konzeptionelles Modell, fachliches Datenmodell, Business Terms Model, Informationsmodell: solange ihr euch im Projekt darauf geeinigt habt, ist der Name eine Geschmacksfrage. Die Sache selbst ist mir nicht egal.

Ein Informationsmodell ist übrigens kein ER-Diagramm mit acht Meter Länge und zwei Meter Höhe, wie wir es im Projekt ausgedruckt und voller Stolz aufgehängt haben. Es ist auch kein Tabellenlayout, kein dbt-Layer und kein Semantiklayer im BI-Tool — das sind Ausprägungen für eine Technologie, und sie ersetzen das Modell nicht. Und ganz sicher ist es kein einmal geschriebenes Dokument, das seitdem irgendwo auf SharePoint oder in Confluence liegt.

Im Grunde genommen ist es nicht nur die Definition an sich, sondern die Entstehung. Ein Informationsmodell ist eine verhandelte Einigung aus dem Fachbereich; der Wert steckt im Streit über die Definition, und das Diagramm ist am Ende nur das Protokoll davon. Warum ausgerechnet KI diese Einigung härter einfordert, als BI es je getan hat, steht in der KI-Serie vom Frühjahr. Fehlt die Semantik, rät die Maschine, und heraus kommt eine Vermutung mit gutem Sprachstil.

Die drei Ebenen — und die eine, die übersprungen wird

Die drei Ebenen kennt jeder, der einmal ein Modellierungsbuch aufgeschlagen hat. Konzeptionell: welche Begriffe gibt es im Unternehmen, wie hängen sie zusammen, was bedeuten sie. Logisch: Attribute, Schlüssel, Kardinalitäten, immer noch ohne Datenbank im Kopf. Physisch: Tabellen, Spalten, Indizes, Partitionierung — für eine konkrete Plattform.

Wo genau konzeptionell aufhört und logisch anfängt, verschwimmt in der Praxis, und ich halte wenig davon, die Grenze künstlich sauber zu ziehen. Fassen wir beide zusammen als das fachliche Modell: technologieunabhängig, in der Sprache derer, die das Geschäft betreiben. Genau das meine ich, wenn ich von Informationsmodellierung spreche.

In Projekten geht es ohnehin um etwas anderes als um diese Abgrenzung. Fast alle rennen direkt zur physischen Ebene (Implementierung), weil es dort etwas zu tun gibt: ein Schema, ein Ladeprozess, ein Deployment, etwas, das man im Sprint-Review zeigen kann. Die fachliche Arbeit sieht dagegen nach Reden aus. Sie ist aber der Teil, den kein Tool und keine KI abnimmt, und der einzige, bei dem am Ende jemand entscheiden muss.

→ Vertieft in Teil 1: Die drei Ebenen — und die eine, die übersprungen wird. Dort mit dem Weg, den ein Begriff von der ersten Definition bis zur Spalte nimmt. Erscheint am 9. September.

Warum das teuer wird

Jedes Unternehmen bewertet Computer, Gebäude, Fahrzeuge und Maschinen als Unternehmenswert. Daten sind halt irgendwie da. Für Gebäude gibt es eine Abteilung, weil Gebäudemanagement eben gemacht werden muss — ein Unternehmen mit einer Abteilung für die Informationslandkarte ist mir dagegen selten begegnet. Einer meiner Kunden hat einen CDO und ein Team, das Data Curators heißt; das ist die Ausnahme, die mir in Erinnerung geblieben ist.

Am deutlichsten sehe ich die Rechnung in Projektlaufzeiten. Wenn in jedem neuen Projekt erst wieder verstanden werden muss, was ein Kunde ist, dauert das Projekt ein Jahr. Liegt das Informationsmodell als Blaupause vor, sind es drei Monate. Ein Kunde hat es mir gegenüber einmal so formuliert: unsere Business-Datenmodelle sind unser Asset, unsere IP — nicht die Implementierungstechnologie.

Und trotzdem taucht der Nutzen nirgends auf. Ein gutes Datenmodell verhindert ein Problem, und verhinderte Probleme stehen in keinem Statusbericht. Heute ist alles super gelaufen — deshalb hat in dem Projekt, an das ich dabei denke, auch niemand das Modell gefeiert.

→ Vertieft in Teil 2: Was heißt „Employee"? Das konzeptionelle Modell. Dort an einer einzigen Zahl, die ein Kunde wochenlang nicht liefern konnte. Erscheint am 16. September.

Erst dann die Methodenfrage

In Workshops kommt fast immer zuerst eine andere Frage: 3NF, Data Vault oder dimensional? Ich verstehe das gut, denn sie klingt nach einer Entscheidung, die man treffen und dann abhaken kann. Nur ist sie die zweite Frage. Die Methode leitet sich aus der Anforderung ab, nicht aus der Technologie, und sie setzt voraus, dass ihr wisst, was ihr modelliert.

Dazu kommt ein Missverständnis, das sich hartnäckig hält: dimensional sei gleich Star Schema und damit physisch. Dimensionales Denken ist fachlich, lange bevor eine Tabelle entsteht. Ähnlich beim Fact-Oriented Modeling, wo das konzeptuelle Modell bewusst vom physischen gelöst wird und die Transformation danach automatisch läuft.

Und ein Teil dessen, was in Projekten als Modellierung durchgeht, ist bei genauem Hinsehen eine Geschäftsregel. Diese Unterscheidung habe ich 2014 schon einmal am 1:M-Link durchgespielt; sie ist seitdem nicht einfacher geworden.

→ Vertieft in Teil 3: Vom Modell zur Implementierung — und die Checkliste. Dort mit einem Entscheidungsbaum je Layer und der Frage, was nach zwei bis drei Jahren aus der Entscheidung geworden ist. Erscheint am 23. September.

Woran du ein gutes Modell erkennst

Es gibt einen Test, der ohne Werkzeug auskommt. Nimm eine Zahl, über die bei euch gestritten wird — den Headcount zum Beispiel. Kann jemand Fachfremdes, oder eine KI, allein aus eurem Modell dieselbe Zahl bauen wie der Fachbereich? Wenn nein, dann fehlt euch nicht die Technologie und auch kein weiteres fancy Add-on, sondern das Informationsmodell.

Dass ein Begriff schwammig wird, sobald man genau hinsieht, habe ich am Kunden schon für Versicherung, E-Commerce und B2B SaaS durchgespielt. Wie teuer die zweite Frage werden kann, hat George McGeachie neulich unter einem meiner Beiträge erzählt. Eine Bank wurde von der Aufsicht belangt, nachdem drei Abteilungen drei verschiedene Zahlen aktiver Kreditkartenkonten geliefert hatten. Unklar war dabei nicht nur, was aktiv bedeutet, sondern auch, ob von Konten oder von Karten die Rede ist. Über beide Begriffe hatte im Haus nie jemand entschieden.

→ Ebenfalls Thema von Teil 3, dort als ausformulierte Checkliste entlang der Kategorien der Data Model Scorecard®.

Diese Frage ist elf Jahre alt

Im März 2015 habe ich hier schon einmal gefragt, ob bei Data Vault überhaupt noch Datenmodellierung nötig ist. Die Antwort war damals ja, und sie ist es heute noch. Geändert hat sich nur, wer das Gegenargument liefert: damals war es Data Vault, heute ist es die KI. Der Artikel steht noch da, keine 500 Wörter lang, und ich würde keinen Satz zurücknehmen.

Wenn du anfangen willst, dann bitte nicht mit der Initiative, alles zu modellieren. Nimm fünf bis zwanzig Begriffe, um die bei euch täglich gestritten wird oder die der aktuelle Use Case braucht — Kunde, Vertrag, Standort, oder etwas scheinbar Harmloses wie aktiv oder storniert. Pro Begriff drei Dinge: eine Definition, auf die ihr euch einigt, einen Verantwortlichen und die Beziehungen zu den anderen Begriffen. Dokumentiert an einem Ort, an dem ihr versionieren könnt. Ein Modellierungswerkzeug ist natürlich ein Traum, aber ein Obsidian Vault mit Git tut es auch.

Alle Experten da draußen mögen mir verzeihen, wenn das so vereinfacht klingt. Wer es anders sieht, darf mir gerne widersprechen — ich finde die Diskussion jedes Mal spannend.

So long,
Dirk