Die verlorene Kunst der Datenmodellierung. Teil 2: Technischer und semantischer Kontext

Im ersten Teil haben wir Datenmodellierung als bewusste Überführung impliziten Wissens in eine explizite Struktur beschrieben. Daten stehen immer in Beziehungen. Solange diese Beziehungen nur im Erfahrungswissen einzelner Personen verankert sind, bleibt der Zusammenhang unsichtbar. Datenmodellierung macht diesen Zusammenhang explizit.

Dabei lassen sich zwei Ebenen unterscheiden.

Technischer Kontext beschreibt die strukturellen Beziehungen zwischen Daten. Er legt fest, wie Tabellen miteinander verbunden sind, auf welcher Granularität Fakten gespeichert werden und wie unterschiedliche Quellen integriert werden.

Semantischer Kontext beschreibt den Bedeutungsrahmen dieser Strukturen. Er definiert, wie Kennzahlen zu verstehen sind, welche Begriffe gelten und wer Verantwortung für ihre Auslegung trägt.

Technischer Kontext entsteht durch explizit modellierte Beziehungen. Er macht sichtbar, wie Datensätze zusammenhängen und in welchem Rahmen sie analysiert werden dürfen.

Eindeutige Schlüssel durch Surrogate Keys

Operative Systeme liefern häufig natürliche Schlüssel, die systemübergreifend nicht eindeutig sind oder sich im Zeitverlauf ändern. Durch Surrogate Keys wird eine stabile Referenz geschaffen, auf die sich alle weiteren Beziehungen im Modell stützen.

Eine Produktdimension, die aus mehreren ERP Systemen gespeist wird, verdeutlicht dieses Prinzip. Produktnummern sind jeweils nur innerhalb eines Systems eindeutig. Durch die Kombination aus Systemkennung und Produktnummer entsteht ein einheitlicher Identifikator. Der strukturelle Rahmen ist klar definiert, unabhängig von der Herkunft der Daten.

Konsolidierung verschiedener Datenquellen

In gewachsenen Systemlandschaften existieren mehrere Beziehungssysteme nebeneinander. Organisationsstrukturen, Produktgruppen oder Kundensegmente unterscheiden sich je nach Quelle. Ein analytisches Modell führt diese Strukturen zusammen und schafft einen gemeinsamen technischen Kontext.

Die hochspezifischen Transaktionslogiken einzelner ERP Systeme werden in eine einheitliche Faktentabelle überführt. Damit wird festgelegt, in welchem strukturellen Rahmen Ereignisse betrachtet werden. Vergleichbarkeit entsteht nicht durch Zufall, sondern durch bewusst gestaltete Beziehungen.

Aufbereitung komplexer fachlicher Logik

Kennzahlen wie DSO oder DIO kombinieren unterschiedliche Wertfelder mit verschiedenen Datumsbezügen. Werden solche Berechnungen im Frontend umgesetzt, entstehen leicht abweichende Definitionen. Durch die Verlagerung in das Datenmodell wird eine zentrale, konsistente Logik etabliert.

Die Berechnung wird Teil der strukturellen Architektur. Das Reporting greift auf klar definierte Kennzahlen zu, statt eigene Interpretationen zu entwickeln.

Anreicherung mit externen Daten

Analytische Fragestellungen erfordern häufig zusätzliche Informationen, die nicht in operativen Systemen enthalten sind. Die Ergänzung von Kundendaten um geografische Koordinaten für einen CO₂ Bericht ist ein typisches Beispiel.

Durch die Erweiterung der Kundendimension wird der Analyse ein zusätzlicher Bedeutungsrahmen hinzugefügt. Die Anreicherung ist nicht isoliert, sondern in die bestehende Struktur eingebettet. Damit wächst der technische Kontext gezielt und nachvollziehbar.

Erweiterbarkeit des Modells

Ein gut modelliertes System ist darauf ausgelegt, neue Anforderungen aufzunehmen. Zusätzliche Dimensionen können ergänzt werden. Neue Fakten, etwa für Planwerte oder Forecasts, lassen sich in separaten Tabellen bereitstellen.

Diese Erweiterbarkeit basiert auf klar definierten Beziehungen zwischen Fakten und Dimensionen. Der strukturelle Rahmen bleibt stabil, auch wenn Inhalte wachsen.

Optimierung für Reporting und Analyse

Dimensional modellierte Strukturen ermöglichen es, vollständige Analysesichten aufzubauen. Wenn geprüft werden soll, ob für alle Einheiten eines Zeitraums Daten vorliegen, reicht es nicht, nur vorhandene Fakten zu betrachten. Erst durch die explizite Beziehung zwischen vollständiger Dimension und zugeordneten Fakten entsteht ein konsistenter Analysekontext.

Sichtbar wird nicht nur, was vorhanden ist, sondern auch, wo Daten fehlen.

Gezielte Steuerung der Granularität

Granularität ist eine bewusste Kontextentscheidung. Sie legt fest, auf welcher Ebene ein Ereignis gespeichert wird und wie es aggregiert werden darf. Wird sie nicht explizit definiert, entstehen Mehrfachzählungen oder missverständliche Auswertungen.

Die Kombination von Belegkopf und Position in einer Faktentabelle ist eine architektonische Festlegung des Analysehorizonts. Sie bestimmt, in welchem Detailgrad Fragen beantwortet werden können.

Während technischer Kontext die formalen Beziehungen ordnet, legt semantischer Kontext fest, wie diese Beziehungen fachlich zu interpretieren sind.

Fachliche Benennung

Operative Systeme verwenden häufig technische Spaltennamen, die nur für Eingeweihte verständlich sind. Durch fachliche Benennung wird der Bedeutungsrahmen direkt im Modell verankert. Tabellen und Spalten beschreiben ihren Inhalt in natürlicher Sprache.

Das Modell wird zur Referenz für Interpretation. Kontext muss nicht mehr implizit mitgeführt werden.

Entkopplung von der Systemlogik

Wenn sich ein Quellsystem ändert oder ein weiteres System hinzukommt, bleibt die fachliche Sicht stabil. Die Benennung orientiert sich an inhaltlichen Begriffen, nicht an technischen Implementierungen.

Diese Entkopplung sorgt dafür, dass der Bedeutungsrahmen nicht bei jedem Systemwechsel neu verhandelt werden muss.

Direkte Wiederverwendbarkeit im Reporting

Durch die fachliche Ausgestaltung können Tabellen und Spalten unmittelbar im Reporting genutzt werden. Zusätzliche Umbenennungen im Frontend werden reduziert. Fachbegriffe bleiben konsistent, unabhängig davon, wer eine Auswertung erstellt.

Das Modell übernimmt damit eine dokumentierende Funktion.

Semantische Konsolidierung von Werten

In vielen Quellsystemen existieren unterschiedliche Ausprägungen desselben Sachverhalts. Schreibweisen variieren, Codes werden historisch weitergeführt. Durch Konsolidierung werden diese Werte in einen gemeinsamen Bedeutungsrahmen überführt.

Erst dadurch wird fachliche Vergleichbarkeit möglich. Unterschiedliche Ursprungslogiken werden auf eine einheitliche Interpretation zurückgeführt.

Hierarchien als fachliche Ordnungslogik

Analytische Auswertungen benötigen klar definierte Hierarchien. Produktstrukturen, Organisationshierarchien oder Kontenpläne werden explizit modelliert. Diese Hierarchien bilden den Rahmen für Aggregationen und Detailanalysen.

Sie legen fest, in welchem fachlichen Zusammenhang Einzelwerte zu Gesamtwerten verdichtet werden dürfen.

Ownership und Kennzahlenhoheit

Semantischer Kontext umfasst auch die Festlegung fachlicher Verantwortung. In einem internationalen Konzern wurde ein konsolidiertes Einkaufsreporting aufgebaut. In den einzelnen Gesellschaften wurden unterschiedliche Datengrundlagen genutzt, etwa Lagereingänge, Einkaufsrechnungen oder Bestellungen. Jede Sicht war für sich nachvollziehbar, führte jedoch zu nicht vergleichbaren Ergebnissen.

Die Kennzahlenhoheit der Holding definierte eine führende Datenbasis. Einkaufsrechnungen wurden als primäre Quelle festgelegt, Lagereingänge ergänzend berücksichtigt. Gleichzeitig wurde transparent gemacht, auf welcher Datengrundlage Kennzahlen beruhen. Der fachliche Rahmen wurde explizit bestimmt.

Dokumentierbarkeit und Übergabefähigkeit

Ein fachlich benanntes und strukturiertes Modell erleichtert die Übergabe an neue Teams. Wenn Tabellen, Spalten und Beziehungen ihre Bedeutung transportieren, reduziert sich der Bedarf an separaten Beschreibungen. Das Modell dokumentiert einen großen Teil seiner Logik selbst.

Technischer und semantischer Kontext sichern die Nutzbarkeit von Daten für Menschen. Sie machen Beziehungen sichtbar, definieren Bedeutungen und reduzieren implizite Annahmen. Diese Qualität wird im nächsten Schritt zur Voraussetzung.

Mit dem Einsatz von KI Systemen arbeiten neue Akteure mit denselben Daten. Maschinen verfügen über kein implizites Erfahrungswissen. Sie können nur auf das zugreifen, was explizit modelliert und dokumentiert ist. Damit erweitert sich die Aufgabe der Datenmodellierung erneut.

Im dritten Teil geht es daher um Datenmodellierung 2.0. Wenn LLMs auf Datenmodelle zugreifen, muss auch der Kontext des Modells selbst explizit gemacht werden. Metadaten, Beschreibungen, Klassifikationen und technische Dokumentation werden zu einem integralen Bestandteil der Architektur.