SKET-Modeling #1: Warum einfach, wenn es auch schwierig geht

SKET-Modeling

1. Das Dilemma: Warum Data-Warehouse-Modelle aus dem Ruder laufen

Wir hatten die besten Absichten: Klar und wohl strukturiert sollte das neue DWH sein. Doch schon bald holte uns die Wirklichkeit ein. So könnten viele Data-Warehouse-Erzählungen beginnen.
Wie kommt es, dass DWH-Modelle trotz aller Bemühungen um Klarheit mit der Zeit in die Komplexität abdriften? Würde man sie ausdrucken, ließe sich damit problemlos ein ganzes Büro tapezieren. Diese Komplexität hat viele Ursachen. Eine zentrale lautet: Das Modell wird fortlaufend erweitert – ohne durchgehendes Konzept und ohne klar definierte Semantik.
So wächst es Schicht für Schicht: neue Tabellen, neue Joins, neue Abfragen. Alte Strukturen bleiben bestehen, obwohl sie längst überholt sind. Inkonsistenzen schleichen sich ein. Mit jeder Änderung wird es schwieriger, den Überblick zu behalten. Das Modell kann nicht mehr sinnvoll gepflegt werden, seine Komplexität steigt ungehindert weiter.
Für das DWH-Team wird es zunehmend unmöglich, die Struktur zu durchdringen. Für die Fachbereiche wird das Modell intransparent. Das Korrigieren architektonischer Fehlentscheidungen wird riskant, denn die Gefahr ist groß, funktionierende Berichte unbeabsichtigt zu beschädigen.

Die Folgen zeigen sich überall:
Informationen werden in mehreren Tabellen unterschiedlich dargestellt. Berichte widersprechen sich und ihre Abweichungen lassen sich, wenn überhaupt, nur durch langwierige Analysen erklären. Neue Daten einzubinden oder bestehende Auswertungen zu erweitern, wird zur mühsamen Fleißarbeit und teuer. Viele Fachbereiche bauen sich eigene Schattenlösungen und verlieren das Vertrauen ins zentrale DWH.
Wie entsteht dieser Wildwuchs? Oft wächst ein DWH organisch über Jahre hinweg. Anforderungen kommen stückweise, von verschiedenen Stellen, über unterschiedliche Kanäle, an wechselnde Entwickler oder Teams. Jeder löst sein konkretes Problem, aber niemand denkt an das große Ganze. Zeit für Modellpflege fehlt, und das konsolidierte Modell bleibt auf der Strecke.
Dabei gilt: Ein gutes DWH-Modell kann nicht von Anfang an perfekt sein. Das strukturierte Verständnis der tatsächlichen Nutzung – also welche Kennzahlen relevant sind, welche Drill-downs gebraucht werden, wie Attribute interpretiert werden – entsteht erst mit der Zeit. Doch dieses Verständnis muss genutzt werden, um das Modell zu konsolidieren, zu vereinfachen und architektonisch zu stabilisieren.
Genau hier setzt SKET-Modeling an. Es liefert eine Methode, um gewachsene Strukturen zu analysieren, das fachliche Nutzungsmuster herauszuarbeiten und daraus ein klares, konsistentes Star-Schema zu entwerfen.

2. Der blinde Fleck: Warum Modellpflege kein Thema ist

Ein gutes Datenmodell ist der Schlüssel zum Erfolg eines DWH – und doch wird in der Praxis wenig in die Modellpflege investiert. Woran liegt das?
In technischen Domänen richtet sich die Aufmerksamkeit stark auf neue Tools, Frameworks und Entwicklungsansätze. Modellierung hingegen gilt als statisch und wenig innovativ. Viele Entwickler beschäftigen sich lieber mit neuen Technologien, Testautomatisierung oder CI/CD-Konzepten. Die Modellpflege bleibt dabei auf der Strecke.
Hinzu kommt: Modelltheorie erscheint auf den ersten Blick simpel. Ihre Anwendung ist es nicht. Sie erfordert ein tiefes Verständnis der fachlichen Realität, Abstraktionsfähigkeit und Genauigkeit im Denken.
Ein weiterer Erfolgsfaktor ist die Zusammenarbeit mit dem Fachbereich. Doch die gestaltet sich schwierig. Viele Fachabteilungen sehen sich nicht in der Verantwortung, an der Modellierung mitzuwirken. Sie beschränken sich darauf, Anforderungen zu formulieren, und erwarten die Umsetzung durch das DWH-Team.
Nicht zuletzt hält sich hartnäckig die Annahme, ein gutes Modell entstehe als Nebenprodukt der Entwicklung. Doch das ist ein Trugschluss. Ohne eine klare Modellverantwortung und eine ordnende Hand entwickelt sich das Modell schleichend in Richtung Unübersichtlichkeit, Redundanz und Inkonsistenz.

3. Der Schlüssel: Von der Nutzung zum Modell

„Du machst ein Modell und bist ein großes Licht,
machst auch noch einen Zweitentwurf –
helfen tun sie beide nicht.“

Was hat Bertolt Brecht mit unserer Modellierungsmisere zu tun? Er hatte erkannt, dass wir Menschen nicht besonders gut darin sind, zu planen. Noch schwieriger fällt es uns, die Wirklichkeit in ein sinnvolles Modell zu übersetzen.
In der Praxis stützen wir uns bei der Datenmodellierung meist auf theoretische Konzepte oder auf die Analyse von Quelldaten. Doch wer sich durch Quellsysteme gearbeitet hat, weiß: Die Komplexität ist hoch, die Strukturen sind historisch gewachsen, vieles ist unvollständig oder widersprüchlich. Man verliert sich leicht im Datenwald.
Sehr viel zielgerichteter ist es, bei der Nutzung anzusetzen. Wenn bereits Berichte vorliegen, zeigen sie klar, was für das Business wirklich relevant ist. Kennzahlen, Dimensionen, Filter – all das ist dort schon greifbar. Die Anforderungen sind nicht mehr hypothetisch, sondern konkret sichtbar.
Berichte machen deutlich, welche Informationen wie strukturiert und interpretiert werden. Genau darin liegt ihre Stärke: Sie bilden die fachliche Perspektive ab – und damit eine ideale Grundlage für die Modellbildung.
Berichte zeigen uns, was zählt. Wir müssen nur lernen, sie richtig zu lesen.

4. SKET-Modeling: Warum passiert das bis jetzt nicht?

Auf dem Papier klingt es ganz einfach: Man analysiert bestehende Berichte, leitet daraus ein Star-Schema ab – und hat ein fachlich fundiertes, klar verständliches Datenmodell. Warum also wird dieser Ansatz so selten verfolgt?
Ein Grund liegt im gewohnten Ablauf von DWH-Projekten. Datenmodelle entstehen meist zu Beginn, lange bevor aussagekräftige Berichte vorliegen. Sind diese später verfügbar, existiert bereits ein Modell – oft komplex, historisch gewachsen und kaum mehr auf die tatsächliche Nutzung abgestimmt. Es wird nur noch erweitert, selten hinterfragt.
Hinzu kommt: Die Ableitung eines Star-Schemas aus Berichten ist kein mechanischer Vorgang. Es braucht ein gutes Verständnis der fachlichen Logik, der Kennzahlen, Filterkriterien und ihrer Bedeutungen. Nicht alles, was im Bericht sichtbar ist, lässt sich direkt in Tabellen übersetzen. Vieles muss gedeutet, abstrahiert und strukturiert werden. Das erfordert Zeit, methodische Klarheit und die Zusammenarbeit von Entwicklung und Fachseite – Ressourcen, die im Projektalltag oft knapp sind.
Ein weiterer Faktor: Das Star-Schema wird von manchen als zu simpel wahrgenommen. Es wirkt nicht angemessen für die Komplexität der realen Datenlandschaft, schon gar nicht im Vergleich zum gewachsenen Netz aus Datenbankobjekten. Doch genau darin liegt die Stärke des Star-Schemas, indem es uns zur fachlichen Klarheit zwingt.
Nicht zuletzt gibt es das Dilemma des Zeitdrucks: Wer gerade neue Anforderungen umsetzt, will selten „zurück an den Anfang“. Modellrefactoring wirkt wie Stillstand, auch wenn es langfristig Stabilität schafft. Zudem schrecken viele vor den systemweiten Auswirkungen zurück, die Änderungen am Datenbankschema mit sich bringen.
Es gibt also viele nachvollziehbare Gründe, warum SKET-Modeling nicht einfach so passiert. Aber genau darin liegt auch seine Relevanz: Es bietet einen strukturierten Weg zurück zur Klarheit – wenn der Wildwuchs bereits da ist und der Bedarf an Orientierung wächst.

5. SKET-Modeling: Vom Bericht zum Modell?

Wie ist SKET-Modeling entstanden? Ganz unspektakulär und mitten in der Projektpraxis.
Als agiler Coach in DWH-Teams begegneten mir regelmäßig überladene, schwer wartbare Datenmodelle. Meine Architektenseele blutete. Doch ich war nicht als Architektin beauftragt, und das Modell war längst Realität: historisch gewachsen, kaum pflegbar, immer komplexer werdend. Die Komplexität von Umsetzung und Modell verstärkten sich wechselseitig – ein echter Teufelskreis.
In dem Versuch, das Team dennoch bei der Modellierung zu unterstützen, fiel mir etwas Entscheidendes auf: Das Wissen für ein gutes Star-Schema lag längst vor – in den Berichten. Der Fachbereich hatte seinen Informationsbedarf konkret formuliert und im Alltag validiert. Eine bessere Grundlage für eine Re-Modellierung konnten wir uns kaum wünschen.

So entstand das erste Star-Schema nach SKET. Die Vorgehensweise folgt zwei einfachen Prinzipien.

  • Top-down-Modellierung: Starte bei der Nutzung. Berichte machen sichtbar, welche Kennzahlen und Dimensionen tatsächlich gebraucht werden. Sie bieten eine klare, geprüfte Sicht auf das Business, deutlich zielgerichteter als klassische Quelldatenanalysen.
  • Bottom-up-Prüfung: Validiere das Modell gemeinsam mit dem Fachbereich. Dazu werden relevante Geschäftsprozesse identifiziert und synthetische Testdaten eingesetzt. So lässt sich der fachliche Fit systematisch überprüfen.

SKET steht für: Structured Knowledge Extraction and Transformation – strukturiertes Wissen wird gezielt herausgelöst und in ein verständliches, tragfähiges Modell überführt.

Wie sich dieses Modell weiterentwickeln und im Unternehmen verankern lässt und wie sich SKET-Modeling von anderen Modellierungsansätzen unterscheidet, ist Thema des nächsten Kapitels.

Weiterlesen in meiner Modellierungsreihe:

Über die Autorin:
Dr. Katharina Wirtz ist Beraterin mit dem Fokus auf BI, Datenmodellierung und Team-Enablement. Mit ihrer Firma SKET22 hilft sie Unternehmen, datengetriebene Entscheidungen auf ein solides Fundament zu stellen.
Mehr zu ihren Workshops: sket22.de
Vernetzen auf LinkedIn: linkedin.com/in/katharina-wirtz

Artikel teilen

Zum Data-Blog