Im thinkBI Podcast ging es zuletzt darum, wie Dashboards geführt werden sollten. Der nächste Schritt liegt darunter: im Datenmodell. Genau dort wird es oft stiller, technischer und für viele zugleich diffuser. Vielleicht auch deshalb wird an dieser Stelle in vielen Projekten zu früh losgebaut.
Dann beginnt Datenmodellierung mit Tabellen, Feldnamen und Beziehungen im Tool. Man schaut in Quellsysteme, verbindet, was sich verbinden lässt, und hofft, dass daraus ein auswertbares Modell entsteht. Das eigentliche Problem liegt aber früher. Bevor ein Datenmodell technisch werden kann, muss es fachlich klar werden.
Denn ein Datenmodell ist nicht zuerst eine Anordnung von Tabellen. Es ist eine Entscheidung darüber, welche Objekte in einer fachlichen Welt überhaupt relevant sind, wie sie benannt werden, woran sie erkannt werden und in welcher Beziehung sie zu Kennzahlen stehen.
Das sichtbare Problem ist technische Modellierung ohne fachliche Klärung
Viele Teams springen beim Thema Datenmodell direkt in die Implementierung. Das ist verständlich. Tabellen sind sichtbar. Felder sind greifbar. Beziehungen lassen sich im Tool relativ schnell ziehen. Aber genau diese Sichtbarkeit verführt dazu, die fachliche Vorarbeit zu unterschätzen.
Dann wird aus einer bestehenden Kundentabelle scheinbar automatisch die Kundendimension. Aus einer Artikelstruktur scheinbar automatisch das Produkt. Und aus Datum wird einfach irgendein Kalender. Was dabei übersehen wird: Die Datenbank liefert noch kein stabiles Begriffsverständnis. Sie zeigt nur, wie etwas technisch abgelegt wurde.
Für Analyse reicht das nicht. Analyse braucht Objekte, die fachlich belastbar sind. Sie braucht Begriffe, die im Unternehmen wirklich etwas meinen. Und sie braucht ein Modell, das nicht nur Daten speichert, sondern Bedeutung ordnet.
Fachliche Objekte sind der eigentliche Anfang
Ein hilfreicher Ausgangspunkt ist deshalb nicht die Tabelle, sondern das Objekt. Welche Dinge kommen in der Anforderungsbeschreibung eigentlich vor? Kunde, Produkt, Verkäufer, Datum, Auftrag, Rechnung. Solche Begriffe sind mehr als Hauptwörter in einem Gespräch. Sie markieren die Elemente, aus denen sich eine betriebliche Wirklichkeit für Analyse zusammensetzt.
Interessant wird es dort, wo diese Objekte nicht so stabil sind, wie sie zunächst wirken. Datum scheint einfach. Aber schon dort beginnt die Modellierungsarbeit. Geht es um Jahre, Monate, Tage, Perioden oder Geschäftsjahre? Nennen wir das Objekt Datum, Kalender oder Periodenmodell? Welche Hierarchie ist für das Unternehmen wirklich relevant?
Noch deutlicher wird es beim Kunden. Im Alltag klingt der Begriff eindeutig. In der Modellierung ist er das oft nicht. Ist ein Kunde jemand mit Kundennummer? Jemand mit erstem Angebot? Jemand mit erstem Auftrag? Und wann ist jemand kein aktiver Kunde mehr? Sobald solche Fragen auftauchen, wird sichtbar, dass ein Begriff nicht einfach übernommen werden kann. Er muss definiert werden.
Hinzu kommt, dass dieselbe Person oder Organisation fachlich unterschiedliche Rollen einnehmen kann. Der Kunde, der bestellt, muss nicht derselbe sein wie der Kunde, der die Rechnung erhält. Wer diese Unterscheidung nicht modelliert, vermischt Bedeutungen, die in der Auswertung später getrennt gebraucht werden.
Das ist keine Formalität. Das ist der Punkt, an dem Datenmodellierung entscheidet, ob Analyse später sauber möglich ist oder ob Begriffe nur technisch vorhanden, aber fachlich unscharf bleiben.
Modellierung heißt benennen, unterscheiden und zuschneiden
Damit wird auch klar, warum gute Datenmodelle nicht an maximaler Vollständigkeit gewinnen. Sie gewinnen an Klarheit. Nicht jedes verfügbare Feld muss sofort in ein Modell. Wichtiger ist die Frage, welche Attribute für die Analyse tatsächlich gebraucht werden.
Zu einem Objekt gehört zunächst ein Identifier. Beim Kunden kann das die Kundennummer sein, beim Produkt eine Artikelnummer, beim Datum das Tagesdatum. Dazu kommen Bezeichner, Beschreibungen, Gruppen, Hierarchien und weitere Attribute. Aber auch hier gilt: weniger ist oft mehr. Ein Modell wird nicht besser, wenn es alles sammelt. Es wird besser, wenn es die relevanten Eigenschaften so ordnet, dass spätere Auswertungen verständlich und wiederverwendbar werden.
Genau deshalb ist auch Naming keine Nebensache. Wenn ein Unternehmen von Perioden statt Monaten spricht, dann sollte das Modell diese Sprache ernst nehmen. Wenn aus einem allgemeinen Kundenbegriff mehrere Kundenrollen werden, dann sollten diese Rollen im Modell sichtbar benannt sein. Modellierung ist immer auch Sprachdisziplin.
Dasselbe zeigt sich beim Produktbegriff. In manchen Systemen verkauft ein Unternehmen nicht nur Artikel, sondern auch Dienstleistungen oder direkte Buchungen auf Konten. Wer all das gedanklich unter Produkt zusammenfasst, ohne genauer zu prüfen, was in den Verkaufszeilen tatsächlich steht, baut schnell eine bequeme, aber fachlich schwache Kategorie. Ein gutes Modell fragt genauer: Was ist hier eigentlich das gemeinsame Analyseobjekt?
Dimensionen und Fakten bringen Ordnung in die Analyse
An dieser Stelle hilft die Unterscheidung zwischen Dimensionen und Fakten. Die fachlichen Objekte werden zu Dimensionen. Sie beschreiben die Perspektiven, nach denen ausgewertet wird: Kunde, Produkt, Datum, Verkäufer und andere. Die Kennzahlen werden zu Fakten. Sie enthalten das, was gemessen, aggregiert und verglichen werden soll.
Diese Unterscheidung ist so nützlich, weil sie das Modell für Fachanwender bedienbar macht. Wer Umsatz nach Produkt sehen will, erwartet eine Produktdimension mit verständlichen Eigenschaften. Wer nach Zeit auswertet, braucht eine Datumsdimension, die den tatsächlichen Kalenderlogiken des Unternehmens folgt. Wer Kennzahlen analysiert, braucht eine Faktentabelle, in der diese Kennzahlen sauber mit den relevanten Objekten verknüpft sind.
Der eigentliche Gewinn liegt aber noch tiefer. Wenn Objekte wie Datum, Kunde oder Verkäufer einmal sauber modelliert sind, lassen sie sich in weiteren Modellen wiederverwenden. Damit entsteht nicht nur ein einzelnes funktionierendes Modell, sondern ein konsistenteres System von Modellen. Wiederverwendbarkeit ist dann kein technischer Bonus, sondern Ausdruck begrifflicher Stabilität.
Auch Hinweise wie die Bus-Matrix bekommen hier ihren Sinn. Sie helfen nicht primär als Technikartefakt, sondern als Denkwerkzeug: Welche Kennzahlen gehören zu welchen Objekten? Welche Perspektiven sind für welche Sachverhalte relevant? Welche Dimensionen lassen sich übergreifend nutzen?
Gute Datenmodelle schaffen Erkenntnisfähigkeit
Am Ende führt die Folge zu einer einfachen, aber weitreichenden Verschiebung: Datenmodellierung beginnt nicht mit Tabellenbeziehungen, sondern mit fachlicher Klärung. Wer nur technisch modelliert, übernimmt oft unbemerkt die Unschärfen der Quellsysteme. Wer dagegen Objekte, Rollen, Hierarchien, Attribute und Kennzahlen bewusst ordnet, schafft ein Modell, das Analyse wirklich trägt.
Gerade im BI-Kontext ist das entscheidend. Denn Dashboards, Berichte und Kennzahlenmodelle sind nur so gut wie die Begriffe, auf denen sie stehen. Wenn Kunde, Produkt oder Datum fachlich nicht sauber modelliert sind, wird auch die Visualisierung später nur scheinbar präzise sein.
Vielleicht ist genau das die ruhigste Zuspitzung dieser Folge: Ein gutes Datenmodell beschreibt nicht zuerst Daten. Es beschreibt die Struktur, in der ein Unternehmen seine Wirklichkeit für Analyse verständlich macht.
🎧 Die komplette Folge findest du im thinkBI Podcast.
Musik: Great Podcast Intro (short & long) von Lundstroem
Quelle: freemusicarchive.org (Creative Commons) – https://freemusicarchive.org/music/lundstroem/songs-for-leona/great-podcast-intro-both-short-and-long-version-included/
