Data Warehouse Consulting – solide Architektur, verlässliche Daten

Positionierung

Ein Data Warehouse ist das analytische Gedächtnis eines Unternehmens. Es bringt Daten aus unterschiedlichen Quellsystemen in eine einheitliche, verlässliche Form und stellt sie für Berichte, Analysen und Entscheidungsunterstützung bereit. Klingt einfach – ist es aber nicht. Ein DWH, das im Alltag trägt, erfordert eine durchdachte Architektur, sorgfältige Modellierung, robuste Ladeprozesse und eine Qualitätssicherung, die Fehler findet, bevor sie in Berichten auftauchen. Ohne diese Basis wird aus dem analytischen Gedächtnis schnell ein unübersichtliches Datenlager, dem niemand mehr vertraut.

Genau hier liegt mein Schwerpunkt. Ich baue Data Warehouses auf SQL Server, die auf bewährten Mustern basieren: Schichtenarchitektur für klare Verantwortlichkeiten, Kimball-Dimensionsmodelle für performante und verständliche Auswertungen, Data Vault für die robuste Historisierung und Entkopplung der Rohdaten, automatisierte ETL-Strecken mit SSIS und T-SQL sowie tSQLt für den automatischen Test der Ladelogik. Am Ende steht eine Auslieferung an SSAS Tabular und Power BI, die Endanwendern schnelle, selbsterklärende Berichte ermöglicht.

Ich arbeite mit SQL Server seit der Version 2000 – in Projekten bei öffentlichen Auftraggebern, in der Industrie, im Dienstleistungsbereich und in der Beratung. Diese Breite hilft: Ich kenne die typischen Wachstumsschmerzen eines DWH genauso wie die Fallstricke bei Neuaufbauten. Ich weiß, welche Kompromisse sich im Nachhinein rächen und welche Vereinfachungen legitim sind. Und ich kann beides – einen Neuaufbau auf der grünen Wiese ebenso wie die gezielte Modernisierung eines gewachsenen Systems.

Auftraggeber kommen zu mir, wenn ein bestehendes DWH an seine Grenzen gestoßen ist: wenn Ladezeiten zu lang werden, wenn Zahlen zwischen Berichten auseinanderlaufen, wenn niemand mehr weiß, was in einer gewachsenen ETL-Strecke wirklich passiert. Oder wenn ein neues DWH entstehen soll und von Anfang an richtig gemacht werden soll. In beiden Fällen beginnt die Arbeit mit dem Verstehen der fachlichen Anforderungen, der Quellsysteme und der vorhandenen Datenlandschaft – bevor auch nur eine Tabelle angelegt wird.

Was ein Data Warehouse ausmacht

Ein Data Warehouse ist mehr als eine Datenbank, in der Berichte laufen. Es ist ein System, das Daten aus verschiedenen Quellen in eine integrierte, konsistente und zeitlich nachvollziehbare Form bringt. Diese vier Eigenschaften – Integration, Konsistenz, Zeitbezug und Themenorientierung – hat William H. Inmon bereits in den 1990er Jahren formuliert, und sie gelten noch heute als Grundlage jedes ernsthaften DWH-Designs.

Integration: eine einheitliche Sicht auf alle Quellen

In den meisten Unternehmen existieren mehrere operative Systeme nebeneinander: ein ERP für Finanzen, ein CRM für Kunden, ein HR-System für Personaldaten, vielleicht noch Speziallösungen für einzelne Fachbereiche. Jedes System hat seine eigenen Schlüssel, seine eigenen Bezeichnungen und seine eigene Logik. Das Data Warehouse bringt diese Welten zusammen und sorgt dafür, dass ein Kunde in allen Quellen derselbe Kunde ist und ein Produkt in allen Systemen dasselbe Produkt. Diese Integration ist fachliche Arbeit, keine rein technische.

Historisierung: Veränderungen über Zeit nachvollziehen

Operative Systeme interessieren sich für den aktuellen Stand. Ein Data Warehouse interessiert sich für die Entwicklung über Zeit. Was kostete ein Produkt vor sechs Monaten? Wie hat sich der Umsatz je Monat entwickelt? Welche Kunden waren vor einem Jahr in welchem Segment? Diese Fragen lassen sich nur beantworten, wenn Veränderungen historisiert werden – mit Slowly Changing Dimensions, mit Insert-only-Schichten oder mit einem Data Vault. Welches Muster das richtige ist, hängt vom Anwendungsfall ab.

Themenorientierung: Fachliche Fragen, nicht technische Strukturen

Ein Data Warehouse ist nach fachlichen Themen strukturiert, nicht nach den technischen Strukturen der Quellsysteme. Statt Tabellen wie 'KDBZK' oder 'BWART' gibt es Dimensionen wie 'Kunde' und 'Material' sowie Faktentabellen wie 'Umsatz' und 'Einkauf'. Diese themenorientierte Struktur macht das DWH für Fachanwender lesbar und für Analysen direkt nutzbar – ohne umfangliches Wissen über die zugrunde liegenden Quellsysteme.

• Integration heterogener Quellsysteme über einheitliche Schlüssel und Konzepte
• Historisierung von Veränderungen für zeitliche Auswertungen
• Themenorientierte Struktur statt Abbildung technischer Quellstrukturen
• Konsistenz: eine Zahl, eine Definition, ein Ergebnis
• Trennung von operativen und analytischen Lasten (OLTP vs. OLAP)
• Nachvollziehbarkeit: jede Zahl lässt sich bis zur Quelle zurückverfolgen

Konsistenz: eine Wahrheit für alle Berichte

Einer der häufigsten Schmerzpunkte in Unternehmen ohne einheitliches DWH ist die 'Zahl des Monats'-Diskussion: Jede Abteilung hat ihren eigenen Umsatz, ihre eigene Kundenzahl, ihre eigene Definition von 'aktiv'. Das Data Warehouse beendet diese Diskussion, indem es eine einzige, gemeinsam verabschiedete Definition für jeden Kennwert festschreibt und alle Berichte aus derselben Quelle speist. Diese Konsistenz ist technisch erreichbar, setzt aber voraus, dass die fachlichen Definitionen zunächst geklärt werden.

Der Gewinn eines verlässlichen DWH zeigt sich nicht sofort in flashigen Dashboards, sondern in der täglichen Arbeit: Berichte laufen pünktlich durch, Zahlen stimmen überein, Anfragen aus dem Management lassen sich in Minuten statt in Tagen beantworten. Dieses Vertrauen in die Daten ist der eigentliche Wert eines gut gebauten Data Warehouse.

Schichtenarchitektur im Data Warehouse

Ein bewährtes Prinzip für jedes Data Warehouse ist die konsequente Trennung in Schichten. Jede Schicht hat eine klar definierte Aufgabe, und die Übergänge zwischen den Schichten folgen definierten Regeln. Diese Trennung macht das System verständlich, testbar und wartbar: Eine Änderung in der Quellstruktur betrifft idealerweise nur die unterste Schicht, nicht die fachliche Modellierung; eine neue Anforderung an die Auslieferung betrifft nur die oberste Schicht, nicht die Beladung.

Die Schichtenarchitektur eines Data Warehouse: Staging Area für die rohen Quelldaten, Core DWH mit Data-Vault- oder ODS-Schicht, Dimensionsmodell (Sternschema) als Reporting-Schicht und SSAS Tabular als semantische Auslieferungsschicht für Power BI.

Staging Area: die Pufferzone

Die Staging Area ist die erste Anlaufstelle für alle Quelldaten. Hier landen die Daten so, wie sie aus den Quellsystemen kommen – unverändert, ohne fachliche Transformation. Die Staging Area ist der Puffer zwischen der Außenwelt und dem eigentlichen DWH. Sie entkoppelt die Ladezeiten und ermöglicht es, Quelldaten mehrfach zu verarbeiten, ohne erneut auf die Quellsysteme zugreifen zu müssen. In der Praxis wird die Staging Area oft nach jedem Lauf geleert oder überschrieben – sie ist kein dauerhafter Speicher, sondern ein Arbeitsbereich.

Core DWH: die verlässliche Datenbasis

Der Core ist das Herzstück des Data Warehouse. Hier werden die Quelldaten bereinigt, integriert und historisiert. Je nach Architekturentscheidung kann der Core als Operational Data Store (ODS), als Data-Vault-Schicht oder als normalisiertes Modell aufgebaut sein. Gemeinsam ist allen Varianten, dass die Daten hier vollständig, historisiert und konsistent vorliegen – als die eine, verlässliche Version der Wahrheit. Aus dem Core wird die Reporting-Schicht befüllt; der Core selbst ist kein direktes Abfragemodell für Endanwender.

Reporting-Schicht: optimiert für Analysen

Die Reporting-Schicht enthält die Daten in einer für Analysen optimierten Form. Das klassische Muster dafür ist das Sternschema nach Kimball: eine zentrale Faktentabelle mit den Kennzahlen, umgeben von Dimensionstabellen mit den beschreibenden Merkmalen. Dieses Modell ist für relationale Abfragen effizient, für Endanwender lesbar und bildet die direkte Grundlage für SSAS Tabular und Power BI. In manchen Projekten ergänzen zusätzliche Aggregate oder vorverdichtete Sichten die Basisschicht, um besonders häufige Abfragen weiter zu beschleunigen.

Semantische Schicht: SSAS Tabular und Power BI

Über der Reporting-Schicht sitzt die semantische Schicht. In SQL-Server-basierten DWH-Projekten ist das typischerweise SSAS Tabular – ein in-memory-Analysemodell, das auf den Daten des Sternschemas aufbaut und über DAX-Measures fachliche Berechnungen zentralisiert. Power BI verbindet sich direkt mit dem Tabular-Modell oder importiert die Daten in ein eigenes Modell. Diese Trennung zwischen Datenhaltung und semantischer Schicht ist ein entscheidender Qualitätsfaktor: Fachliche Kennzahlen sind einmal definiert, werden einmal gewartet und sind in allen Berichten konsistent.

• Staging Area: rohe Quelldaten, täglich neu geladen, kein dauerhafter Speicher
• Core DWH: bereinigte, historisierte und integrierte Daten als verlässliche Basis
• Reporting-Schicht: Sternschema nach Kimball, optimiert für relationale Abfragen
• SSAS Tabular: in-memory-Semantikschicht mit zentralisierten DAX-Measures
• Power BI: Self-Service-Berichte und Dashboards auf Basis des Tabular-Modells

Kimball und Dimensionsmodellierung

Die Dimensionsmodellierung nach Ralph Kimball ist das am weitesten verbreitete Muster für die Reporting-Schicht eines Data Warehouse. Ihr Grundgedanke ist so einfach wie wirkungsvoll: Messbare Fakten – Umsätze, Mengen, Kosten – liegen in Faktentabellen; die beschreibenden Kontexte – Kunden, Produkte, Zeiten, Regionen – liegen in Dimensionstabellen. Die Verbindung beider ergibt das Sternschema, das nach zwei bis drei Joins eine beliebige Auswertung ermöglicht.

Der Charme des Kimball-Modells liegt in seiner Leistung und Verständlichkeit. Ein Sternschema mit gut gewählten Surrogate Keys ist für relationale Datenbanken gut optimierbar: Die Faktentabelle wächst linear, die Dimensionen sind vergleichsweise klein und können vollständig in den Buffer-Pool des SQL Servers passen. Abfragen, die Milliarden von Faktzeilen über wenige Dimensionen aggregieren, laufen damit auch auf großen Datenmengen in vertretbarer Zeit.

Ein klassisches Sternschema: die Faktentabelle 'Umsatz' in der Mitte, verknüpft mit den Dimensionstabellen Kunde, Produkt, Zeit und Region über Integer-Surrogate-Keys. Jede Dimension trägt beschreibende Attribute für Drill-down und Filterung.

Faktentabellen: was gemessen wird

Die Faktentabelle enthält die Kennzahlen des Geschäftsprozesses – Umsatz, Menge, Kosten, Anzahl – sowie Fremdschlüssel zu allen zugehörigen Dimensionen. Jede Zeile entspricht einem Ereignis oder einer Messung auf dem gewählten Granularitätsniveau. Die Wahl des richtigen Grains ist eine der wichtigsten Entscheidungen im DWH-Design: zu grob führt zu Informationsverlust, zu fein zu einer riesigen Tabelle mit kaum nutzbarem Detail. Surrogate Keys als Integer-Fremdschlüssel statt der originalen Business Keys halten die Faktentabelle schlank und unabhängig von Quellsystem-Änderungen.

-- Faktentabelle fuer den Geschaftsprozess 'Umsatz'.
-- Surrogate Keys (SK) als INT-Fremdschluessel statt Business Keys.
-- Grain: eine Zeile pro Auftragsposition und Lieferdatum.
CREATE TABLE reporting.FactUmsatz
(
    -- Degenerate Dimension: Belegnummer direkt in der Faktentabelle
    AuftragNr         NVARCHAR(20)    NOT NULL,
    AuftragPosNr      SMALLINT        NOT NULL,

    -- Surrogate-Key-Fremdschluessel zu den Dimensionen
    KundeSK           INT             NOT NULL,
    ProduktSK         INT             NOT NULL,
    LieferdatumSK     INT             NOT NULL,   -- Verweis auf DimZeit (YYYYMMDD)
    RegionSK          INT             NOT NULL,
    VertriebsmitarbeiterSK INT        NOT NULL,

    -- Kennzahlen (additive Facts)
    MengeGeliefert    DECIMAL(12, 3)  NOT NULL DEFAULT 0,
    NettoUmsatz       DECIMAL(14, 2)  NOT NULL DEFAULT 0,
    RabattBetrag      DECIMAL(14, 2)  NOT NULL DEFAULT 0,
    Herstellkosten    DECIMAL(14, 2)  NOT NULL DEFAULT 0,

    -- Audit-Spalten
    ETL_LadeZeitstempel DATETIME2    NOT NULL DEFAULT SYSUTCDATETIME(),
    ETL_QuellSystem     NVARCHAR(50) NOT NULL,

    CONSTRAINT PK_FactUmsatz PRIMARY KEY NONCLUSTERED (AuftragNr, AuftragPosNr),
    CONSTRAINT FK_FactUmsatz_Kunde    FOREIGN KEY (KundeSK)    REFERENCES reporting.DimKunde   (KundeSK),
    CONSTRAINT FK_FactUmsatz_Produkt  FOREIGN KEY (ProduktSK)  REFERENCES reporting.DimProdukt (ProduktSK),
    CONSTRAINT FK_FactUmsatz_Zeit     FOREIGN KEY (LieferdatumSK) REFERENCES reporting.DimZeit (ZeitSK)
);

-- Clustered Columnstore Index fuer analytische Abfragen auf grossen Datenmengen
CREATE CLUSTERED COLUMNSTORE INDEX CCI_FactUmsatz
    ON reporting.FactUmsatz;

Der Clustered Columnstore Index ermöglicht analytische Abfragen über Millionen von Zeilen in Sekunden. Surrogate Keys halten die Faktentabelle unabhängig von Quellsystem-Schlüsseländerungen.

Dimensionstabellen: der Kontext

Dimensionstabellen beschreiben die Objekte, über die gemessen wird: Kunden mit Adresse und Segment, Produkte mit Kategorie und Lieferant, Zeitdimensionen mit Wochentag, Monat, Quartal und Geschäftsjahr. Eine gut ausgearbeitete Dimension ist breit – viele Attribute – und relativ flach: Statt tiefe Hierarchien zu normalisieren (Snowflake), werden sie in der klassischen Kimball-Welt denormalisiert in die Dimensionstabelle aufgenommen. Das vereinfacht Abfragen und steigert die Abfrageperformance, weil keine zusätzlichen Joins nötig sind.

In der Praxis ergänze ich das Stern- oder Schneeflockenschema je nach Anforderung durch Outrigger-Dimensionen und Brückentabellen für Viele-zu-viele-Beziehungen, etwa wenn ein Auftrag mehrere Kostenstellen oder ein Produkt mehrere Kategorien haben kann. Solche Sonderfälle verlangen sorgfältige Modellierung, damit doppelte Zählungen in Berichten vermieden werden.

-- Abfrage des monatlichen Nettoumsatzes je Produktkategorie und Region.
-- Star-Join ueber vier Dimensionen; der Columnstore-Index macht den Scan effizient.
SELECT
    z.Geschaeftsjahr,
    z.Monat,
    p.Produktkategorie,
    r.RegionName,
    SUM(f.NettoUmsatz)     AS NettoUmsatz,
    SUM(f.Herstellkosten)  AS Herstellkosten,
    SUM(f.NettoUmsatz)
        - SUM(f.Herstellkosten) AS Deckungsbeitrag,
    COUNT_BIG(*)           AS AnzahlPositionen
FROM  reporting.FactUmsatz          f
JOIN  reporting.DimZeit             z  ON f.LieferdatumSK   = z.ZeitSK
JOIN  reporting.DimProdukt          p  ON f.ProduktSK        = p.ProduktSK
JOIN  reporting.DimRegion           r  ON f.RegionSK         = r.RegionSK
JOIN  reporting.DimKunde            k  ON f.KundeSK          = k.KundeSK
WHERE z.Geschaeftsjahr = 2024
  AND k.KundenSegment   = 'Geschaeftskunde'
GROUP BY
    z.Geschaeftsjahr, z.Monat,
    p.Produktkategorie, r.RegionName
ORDER BY
    z.Monat, p.Produktkategorie;

Der Star-Join über vier Dimensionen ist SQL-Server-intern bestens optimierbar. Der Ausführungsplan nutzt Hash-Joins und den Columnstore-Index für einen schnellen, parallelen Scan der Faktentabelle.

Data Vault als Rohdaten- und Historisierungsschicht

Data Vault ist ein Modellierungsansatz für die Core-Schicht des Data Warehouse, den Dan Linstedt in den 1990er Jahren entwickelt hat. Er trennt die Rohdaten-Historisierung konsequent von der fachlichen Modellierung und macht das DWH damit agiler gegenüber Quellsystem-Änderungen. Wo ein klassischer ODS bei jeder Strukturänderung der Quelle angepasst werden muss, nimmt ein Data Vault neue Quellen und neue Attribute ohne Umstrukturierung auf.

Das Data-Vault-Modell besteht aus drei Tabellentypen. Hubs enthalten die Business Keys der fachlichen Entitäten – Kunden, Produkte, Buchungen – mit Hashkey, Business Key, Ladezeitstempel und Quellkennzeichen. Links verbinden Hubs und repräsentieren Beziehungen zwischen Entitäten. Satellites nehmen alle beschreibenden Attribute der Hubs und Links auf, mit vollständiger Historisierung: Jede Version eines Attributs wird mit Gültigkeitsbeginn gespeichert und nie überschrieben. Dieses Insert-only-Prinzip macht den Data Vault auditierbar bis zum ersten Ladetag.

In einem Projekt bei einem öffentlichen Auftraggeber im Forschungsbereich haben wir eine Data-Vault-Importschicht parallel zu einem Kimball-basierten Reporting-Modell betrieben. Der Data Vault übernahm dabei die Rohdaten-Historisierung: Jede Änderung in den Quellsystemen wurde im Vault dokumentiert, unabhängig davon, ob sie fachlich relevant war oder nicht. Aus dem Vault wurden dann die Kimball-Dimensionen nach fachlichen Regeln abgeleitet – eine saubere Trennung zwischen 'was wurde geliefert' und 'was bedeutet es fachlich'.

Hubs, Links und Satellites in der Praxis

Ein Hub für den Entitätstyp 'Kunde' enthält genau eine Zeile pro Business Key – unabhängig davon, wie viele Quellsysteme diesen Kunden kennen. Der Hashkey ist ein SHA-1- oder MD5-Hash über den Business Key und dient als effizienter, stabiler Surrogate Key im gesamten Vault. Der Satellite zum Kunden-Hub speichert alle beschreibenden Attribute – Name, Adresse, Segment – mit Load-Datum, End-Datum und Quellkennzeichen. Ändert sich ein Attribut, wird eine neue Zeile eingefügt, die alte bleibt erhalten. So lässt sich für jeden Zeitpunkt rekonstruieren, wie der Datensatz damals aussah.

• Hubs: Business Keys und Hashkeys, eine Zeile pro Entität und Quelle
• Links: Beziehungen zwischen Hubs, historisiert und quellübergreifend
• Satellites: beschreibende Attribute, vollständig historisiert, Insert-only
• Hash-Diff: effizienter Änderungsvergleich ohne spaltenweise Prüfung
• Parallelladung: Hubs, Links und Satellites können unabhängig beladen werden
• Agile Erweiterbarkeit: neue Quellen und Attribute ohne Umstrukturierung

ETL-Beladung: Daten verlässlich in das Data Warehouse bringen

ETL – Extract, Transform, Load – ist der operative Kern eines Data Warehouse. Hier werden Quelldaten abgeholt, in die DWH-Strukturen überführt und geladen. Klingt mechanisch, ist es aber nicht: Eine verlässliche ETL-Strecke muss idempotent sein (wiederholbarer Lauf ohne Nebenwirkungen), wiederanlauffähig nach Fehlern, nachvollziehbar durch Logging, und sie muss mit realen Quelldaten umgehen können – also mit Nullwerten, Duplikaten, Kodierungsfehlern und unerwarteten Werten.

Meine bevorzugte Kombination für SQL-Server-basierte DWH ist SSIS für die Orchestrierung und den physischen Datentransport sowie T-SQL Stored Procedures für die fachliche Transformation. SSIS ist gut darin, Daten aus verschiedenen Quellen zu lesen, zu transformieren und verlässlich zu laden. Die fachliche Logik – Mappings, Schlüssel-lookup, Bereinigungsregeln – ist aber in T-SQL besser lesbar, testbar und wartbar als in SSIS-Datenflusskonfigurationen. Wo große Datenmengen ohne komplexe Transformation bewegt werden müssen, ersetze ich SSIS-Strecken auch durch direkte T-SQL-Befehle über einen SQL-Server-Agent-Job.

Ein wiederkehrendes Muster in meinen Projekten ist die Steuerungstabelle: Eine Metadaten-Tabelle enthält alle zu ladenden Objekte mit Quell- und Zielinformation, inkrementeller Wasserscheide, Status und letztem Laufzeitstempel. Eine generische SSIS-Strecke oder eine Stored Procedure iteriert über diese Tabelle und führt den Lade-Schritt für jedes Objekt aus. Neue Quellen werden durch einen neuen Eintrag in der Steuerungstabelle ergänzt – ohne Änderung an der ETL-Strecke selbst.

-- Stored Procedure als Einstiegspunkt fuer den Nacht-Ladelauf.
-- Steuerung ueber eine Metadaten-Tabelle; Fehler werden protokolliert.
CREATE OR ALTER PROCEDURE etl.usp_StarteLadelauf
    @LadelaufID     INT,
    @AbDatum        DATE = NULL   -- NULL = Watermark aus ctrl.Watermark
AS
BEGIN
    SET NOCOUNT ON;
    DECLARE @v_AbDatum      DATE;
    DECLARE @v_StartZeit    DATETIME2 = SYSUTCDATETIME();

    -- Fallback auf gespeicherte Watermark, falls kein Datum uebergeben
    IF @AbDatum IS NULL
        SELECT @v_AbDatum = MAX(LetzterLadestand)
        FROM   ctrl.Watermark
        WHERE  LadelaufID = @LadelaufID;
    ELSE
        SET @v_AbDatum = @AbDatum;

    BEGIN TRY
        -- 1) Staging-Area beladen (generisch ueber Steuertabelle)
        EXEC etl.usp_LadeStaging @LadelaufID = @LadelaufID, @AbDatum = @v_AbDatum;

        -- 2) Core / Data-Vault-Schicht aus Staging befuellen
        EXEC etl.usp_LadeCore    @LadelaufID = @LadelaufID;

        -- 3) Reporting-Dimensionen und Faktentabellen aktualisieren
        EXEC etl.usp_LadeReporting @LadelaufID = @LadelaufID;

        -- Watermark nach erfolgreichem Lauf fortschreiben
        UPDATE ctrl.Watermark
        SET    LetzterLadestand = SYSUTCDATETIME(),
               LetzterStatus    = 'OK',
               LetzterStart     = @v_StartZeit
        WHERE  LadelaufID = @LadelaufID;

    END TRY
    BEGIN CATCH
        -- Fehler protokollieren, ohne den Ladelauf-Status zu korrumpieren
        INSERT INTO ctrl.FehlerLog (LadelaufID, FehlerZeit, FehlerMeldung, Prozedur)
        VALUES (@LadelaufID, SYSUTCDATETIME(), ERROR_MESSAGE(), ERROR_PROCEDURE());

        UPDATE ctrl.Watermark
        SET    LetzterStatus = 'FEHLER'
        WHERE  LadelaufID = @LadelaufID;

        THROW;   -- Fehler weiterleiten fuer Alerting
    END CATCH;
END;

Die dreistufige Stored Procedure orchestriert Staging, Core und Reporting in einem Transaktionsrahmen. Die Watermark wird erst nach erfolgreichem Abschluss aller Stufen fortgeschrieben – so ist der Lauf sicher wiederanlauffähig.

Inkrementelle Beladung ist in nahezu jedem Produktions-DWH Pflicht. Ein Full Load aller Quelldaten bei jeder Ausführung ist für kleine Datenmengen praktikabel, für große Tabellen aber weder zeitlich noch ressourcenseitig vertretbar. Die Watermark-Steuerung – eine Marke, die den Stand des letzten erfolgreichen Laufs festhält – ist das einfachste und robusteste Muster für inkrementelle Beladung. Sie lässt sich mit einer Änderungsdatum-Spalte in der Quelle oder mit CDC (Change Data Capture) in SQL Server kombinieren.

• Idempotenz: jeder Lauf liefert dasselbe Ergebnis, egal wie oft er ausgeführt wird
• Wiederanlauffähigkeit: Unterbrechung und Neustart ohne manuelle Korrekturen
• Watermark-Steuerung für inkrementelle Beladung
• Zentrales Fehler-Logging und Alerting bei Abbruch
• Steuerungstabelle für metadatengetriebene, generische Ladeprozesse
• SSIS für Datentransport, T-SQL für fachliche Transformation

SCD und Historisierung: Veränderungen über Zeit bewahren

Stammdaten verändern sich. Ein Kunde zieht um, ändert sein Segment oder bekommt einen neuen Betreuer. Ein Produkt wechselt seine Kategorie oder seinen Preis. Wie das Data Warehouse mit solchen Änderungen umgeht, ist eine der wichtigsten architektonischen Entscheidungen – und sie hat direkten Einfluss darauf, welche historischen Fragen beantwortbar sind.

Das Standardmuster für die Historisierung von Dimensionen ist die Slowly Changing Dimension (SCD) in ihren verschiedenen Typen. SCD Type 1 überschreibt den alten Wert einfach – keine Historisierung, der aktuelle Stand gilt immer. SCD Type 2 fügt eine neue Zeile ein und schreibt die alte ab: So lässt sich für jeden historischen Umsatz rekonstruieren, in welchem Segment der Kunde zum damaligen Zeitpunkt war. SCD Type 3 speichert den vorherigen Wert in einer zusätzlichen Spalte – nützlich für genau eine Generationstiefe, aber nicht für beliebige Historienabfragen.

In den meisten meiner DWH-Projekte dominiert SCD Type 2 für die fachlich relevanten Attribute. Die Implementierung folgt einem bewährten Muster: Jede Dimensionszeile hat ein Gültigkeits-Von-Datum, ein Gültigkeits-Bis-Datum (für die aktuelle Zeile oft ein fernes Stichdatum wie '9999-12-31') und ein Kennzeichen für die aktuelle Zeile. Der MERGE-Befehl in T-SQL ist für diese Aktualisierung das effizienteste Werkzeug.

-- SCD-Type-2-Aktualisierung der Kundendimension per MERGE.
-- Neue Kunden werden eingefuegt; geaenderte Attribute erzeugen eine neue Version.
-- Unveraenderte Zeilen werden nicht angefasst (kein unnoetigesUpdate).
MERGE reporting.DimKunde AS tgt
USING (
    -- Quelle: bereinigte Staging-Daten mit Hash-Diff fuer effizienten Vergleich
    SELECT
        KundeID,
        KundeName,
        KundenSegment,
        RegionCode,
        -- Hash ueber alle SCD-2-Attribute fuer effizienten Vergleich
        HASHBYTES('SHA1',
            CONCAT_WS('|', UPPER(TRIM(KundeName)),
                            UPPER(TRIM(KundenSegment)),
                            UPPER(TRIM(RegionCode)))
        ) AS HashDiff
    FROM staging.Kunden
) AS src
ON tgt.KundeID_BK = src.KundeID
AND tgt.IstAktuell = 1   -- nur gegen die aktuelle Version pruefen

-- Unveraenderter Datensatz: nichts tun (kein WHEN MATCHED ohne Bedingung!)
WHEN MATCHED AND tgt.HashDiff = src.HashDiff THEN
    UPDATE SET tgt.ETL_LetztesPruefDatum = SYSUTCDATETIME()   -- reiner Heartbeat

-- Geaenderter Datensatz: alte Version abschliessen
WHEN MATCHED AND tgt.HashDiff <> src.HashDiff THEN
    UPDATE SET
        tgt.GueltigBis    = CAST(GETDATE() AS DATE),
        tgt.IstAktuell    = 0

-- Neuer Datensatz: direkt einfuegen
WHEN NOT MATCHED BY TARGET THEN
    INSERT (KundeID_BK, KundeName, KundenSegment, RegionCode,
            GueltigAb, GueltigBis, IstAktuell, HashDiff)
    VALUES (src.KundeID, src.KundeName, src.KundenSegment, src.RegionCode,
            CAST(GETDATE() AS DATE), '9999-12-31', 1, src.HashDiff);

-- Neue Version fuer geaenderte Datensaetze einfuegen (zweiter Schritt)
INSERT INTO reporting.DimKunde
    (KundeID_BK, KundeName, KundenSegment, RegionCode,
     GueltigAb, GueltigBis, IstAktuell, HashDiff)
SELECT
    src.KundeID, src.KundeName, src.KundenSegment, src.RegionCode,
    CAST(GETDATE() AS DATE), '9999-12-31', 1, src.HashDiff
FROM staging.Kunden src
JOIN reporting.DimKunde tgt
    ON tgt.KundeID_BK = src.KundeID
    AND tgt.IstAktuell = 0                  -- gerade abgeschlossen
    AND tgt.GueltigBis = CAST(GETDATE() AS DATE);  -- heute abgeschlossen

Der zweistufige MERGE mit nachfolgendem INSERT ist das bewährteste T-SQL-Muster für SCD Type 2. Der Hash-Diff-Vergleich vermeidet spaltenweise Prüfungen und ist bei breiten Dimensionen erheblich schneller.

Historisierung in der Faktentabelle

Faktentabellen sind typischerweise Insert-only: Neue Ereignisse werden hinzugefügt, bestehende nicht verändert. Das gilt aber nicht für alle Fakttypen. Periodische Snapshot-Fakten – etwa monatliche Bestände oder Kontostände – werden bei jedem Lauf neu geschrieben oder über Upsert aktualisiert. Transaktionsfakten hingegen sind abgeschlossene Ereignisse und werden nie geändert, höchstens durch eine Storno-Buchung korrigiert. Diese Unterscheidung ist fundamental für die Korrektheit historischer Auswertungen.

Ein besonderer Fall ist der Late-Arriving Fact: Eine Buchung trifft im DWH ein, nachdem die Dimension bereits weitergeführt wurde. In diesem Fall muss der ETL-Prozess sicherstellen, dass der korrekte historische Dimensionsschlüssel verwendet wird – also die Version der Dimension, die zum Zeitpunkt des Buchungsvorgangs gültig war, nicht die aktuelle. Dieser Lookup auf den historisch gültigen SK ist in einem SCD-Type-2-Modell über das Gültigkeitsdatum-Intervall lösbar, erfordert aber bewusste Implementierung.

Datenqualität und automatische Tests mit tSQLt

Datenqualität ist kein nettes Extra, sondern eine Grundvoraussetzung. Ein Data Warehouse, dem die Fachabteilungen nicht vertrauen, wird schlicht nicht genutzt – egal wie elegant die Architektur und wie schön die Berichte sind. Vertrauen entsteht durch Verlässlichkeit, und Verlässlichkeit entsteht durch systematische Qualitätssicherung, die Fehler findet, bevor sie in Berichten auftauchen.

Mein Werkzeug der Wahl für automatische Tests der ETL-Logik ist tSQLt – ein Open-Source-Unit-Test-Framework für SQL Server, das Tests als Stored Procedures in der Datenbank selbst ablegt. tSQLt ermöglicht es, einzelne Transformationsschritte isoliert zu testen, indem Abhängigkeiten wie Quelltabellen durch Fake-Tabellen ersetzt werden. So lassen sich Randwerte, Nullwerte, Duplikate und Sonderfälle systematisch abdecken – ohne Produktionsdaten anfassen zu müssen.

In einem umfangreichen DWH-Projekt bei einem öffentlichen Forschungsauftraggeber habe ich tSQLt für fachliche Tests und Regressionstests aufgebaut und in eine Jenkins-CI/CD-Pipeline integriert. Das Ergebnis: Jede Änderung an der ETL-Logik wurde automatisch gegen die bestehende Testbatterie geprüft. Regressionsfehler – versehentliche Änderungen an Kennzahlen durch Umbauten in unscheinbaren Transformationsschritten – wurden so zuverlässig vor dem Produktivgang erkannt.

-- tSQLt-Unit-Test: prueft, ob ein geaendertes Kundenattribut korrekt
-- als neue SCD-Type-2-Version in DimKunde eingefuegt wird.
EXEC tSQLt.NewTestClass 'TestDimKunde';
GO

CREATE OR ALTER PROCEDURE TestDimKunde.[test SCD2 erzeugt neue Version bei Segmentwechsel]
AS
BEGIN
    -- Arrange: Fake-Tabellen anlegen, um Produktionsdaten zu isolieren
    EXEC tSQLt.FakeTable 'staging.Kunden';
    EXEC tSQLt.FakeTable 'reporting.DimKunde';

    -- Ausgangszustand: ein Kunde im Segment 'KMU'
    INSERT INTO reporting.DimKunde
        (KundeSK, KundeID_BK, KundeName, KundenSegment, GueltigAb, GueltigBis, IstAktuell)
    VALUES
        (1, 'K-001', 'Muster GmbH', 'KMU', '2023-01-01', '9999-12-31', 1);

    -- Staging-Eingang: Kunde wechselt in Segment 'Konzern'
    INSERT INTO staging.Kunden (KundeID, KundeName, KundenSegment, RegionCode)
    VALUES ('K-001', 'Muster GmbH', 'Konzern', 'DE-NRW');

    -- Act: SCD-Ladeprozedur ausfuehren
    EXEC etl.usp_LadeDimKunde;

    -- Assert: zwei Versionen vorhanden; alte Version abgeschlossen, neue aktiv
    DECLARE @AnzahlVersionen INT;
    SELECT @AnzahlVersionen = COUNT(*) FROM reporting.DimKunde WHERE KundeID_BK = 'K-001';
    EXEC tSQLt.AssertEquals 2, @AnzahlVersionen, 'Erwartet: 2 Versionen fuer K-001';

    DECLARE @AktuellesSegment NVARCHAR(50);
    SELECT @AktuellesSegment = KundenSegment
    FROM   reporting.DimKunde
    WHERE  KundeID_BK = 'K-001' AND IstAktuell = 1;
    EXEC tSQLt.AssertEquals 'Konzern', @AktuellesSegment, 'Neues Segment muss Konzern sein';
END;
GO

-- Test ausfuehren
EXEC tSQLt.Run 'TestDimKunde';

tSQLt isoliert jeden Test vollständig: Die Fake-Tabellen enthalten nur die für den Test relevanten Zeilen, Produktionsdaten bleiben unberührt. Die Tests laufen in einer Transaktion und werden nach dem Test automatisch zurückgerollt.

Datenqualitätsregeln im ETL

Neben Unit-Tests für die ETL-Logik gehören Datenqualitätsregeln in den Ladeprozess selbst. Vor der Übergabe an den Core prüfe ich typischerweise: Pflichtfelder vorhanden, Datentypen korrekt, Referenzen auf gültige Schlüssel auflösbar, Mengengerüste im erwarteten Bereich. Datensätze, die diese Regeln verletzen, werden in eine Quarantänetabelle verschoben, mit Fehlerkennzeichen und Meldung. So beeinträchtigen qualitativ schlechte Quelldaten den restlichen Lauf nicht, sind aber nachvollziehbar dokumentiert.

In Projekten mit hohen Qualitätsanforderungen – etwa im öffentlichen Sektor, wo Daten für Forschung und Berichterstattung genutzt werden – ergänze ich technische Tests durch fachliche Plausibilitätsregeln: Stimmt die Summe der Detailpositionen mit dem Kopfbetrag überein? Liegt die Stückzahl in einem realistischen Bereich? Ist das Lieferdatum nicht vor dem Bestelldatum? Diese Regeln sind einfach zu formulieren und fangen reale Datenprobleme zuverlässig ab.

• tSQLt Unit-Tests für jede ETL-Transformationsstufe
• Regressionstests sichern bestehende Logik gegen unbeabsichtigte Änderungen ab
• CI/CD-Integration: Tests laufen automatisch bei jedem Deployment (z. B. Jenkins)
• Quarantänetabellen für qualitativ unzureichende Quelldaten
• Plausibilitätsregeln: fachliche Konsistenzprüfungen im ETL
• Vollständigkeitsprüfungen: Mengengerüste im erwarteten Bereich?

Auslieferung an SSAS Tabular und Power BI

Das analytische Modell ist der letzte Meter zwischen dem Data Warehouse und dem Endanwender. SQL Server Analysis Services Tabular ist für SQL-Server-basierte DWH die bewährteste Wahl: ein In-memory-Analysemodell, das auf den Daten des relationalen Sternschemas aufbaut, über DAX fachliche Kennzahlen zentralisiert und sich nahtlos in Power BI integriert. Der große Vorteil des Tabular-Modells gegenüber einem direkten Power-BI-Import ist die Zentralisierung: Measure-Definitionen, Beziehungen, Hierarchien und Sicherheitsregeln sind einmal definiert und in allen Berichten konsistent.

In einem DWH-Neuaufbauprojekt bei einem Engineering- und Beratungsunternehmen habe ich SSAS Tabular über den Bereichen Finance, Controlling und HR aufgebaut. Das Tabular-Modell übersetzte die relationalen Strukturen des Sternschemas in ein für Endanwender lesbares Semantikmodell: benannte Measures für alle KPIs, sinnvolle Hierarchien in den Dimensionen, Role-Level-Security für die Einschränkung auf relevante Datenbereiche. Power BI verbindet sich über Live Connection direkt mit diesem Modell – Berichte nutzen immer die zentrale, geprüfte Logik.

DAX – Data Analysis Expressions – ist die Formelsprache von SSAS Tabular und Power BI. Gut geschriebene DAX-Measures sind performant, klar benannt und fachlich ausdrucksstark. Schlecht geschriebene DAX-Measures können ein Tabular-Modell auch bei moderaten Datenmengen zum Kriechen bringen. Ich lege Wert auf sparsamen Einsatz von CALCULATE, auf die Vermeidung unnötiger Kontexttransitionen und auf den Einsatz von Storage-Mode-Optionen wie DirectQuery für Live-Daten und Import für historische Aggregate.

Partitionierung und Refresh-Strategie

Für große Tabular-Modelle ist eine durchdachte Partitionierungs- und Refresh-Strategie entscheidend. Statt das gesamte Modell bei jeder Aktualisierung neu zu laden, teile ich große Fakten in zeitliche Partitionen auf. Nur die aktuellen Partitionen werden bei jedem Nachtlauf neu geladen; historische Partitionen bleiben unberührt. Das verkürzt die Verarbeitungszeit erheblich und hält das Modell auch bei Hunderten von Millionen Zeilen in einem beherrschbaren Refresh-Fenster.

• SSAS Tabular als zentrale Semantikschicht: ein Modell, alle Berichte
• DAX-Measures für alle fachlichen KPIs: einmal definiert, überall konsistent
• Hierarchien, Anzeigeordner und Benennungen für Endanwender-Lesbarkeit
• Row-Level-Security für rollenbasierte Datenzugangsbeschränkung
• Partitionierung für kurze Refresh-Zeiten bei großen Datenmengen
• Power BI Live Connection für direkte Nutzung des zentralen Tabular-Modells

Performance im Data Warehouse

Performance ist im Data Warehouse immer ein Thema – früher oder später. Ein frisch gebautes DWH läuft oft problemlos; nach zwei Jahren Wachstum, fünf zusätzlichen Quellen und hundert neuen Berichten kann sich das schnell ändern. Performance-Probleme im DWH entstehen auf mehreren Ebenen: in der Datenbankstruktur (fehlende oder falsche Indizes, zu breite Faktentabellen), in der ETL-Logik (unnötige Full Loads, teure Row-by-Row-Operationen), in den Abfragen (ineffiziente Joins, fehlende Filter) und im Tabular-Modell (teure DAX-Measures, fehlendes Partitionierungskonzept).

Auf Datenbankebene sind Columnstore-Indizes das wirksamste Instrument für analytische Abfragen. Ein Clustered Columnstore Index auf der Faktentabelle komprimiert die Daten spaltenweise, ermöglicht Batch-Verarbeitung und nutzt moderne CPU-Parallelität optimal. Abfragen, die über Milliarden von Zeilen aggregieren, sind damit um Größenordnungen schneller als mit klassischen Row-Store-Indizes. Ergänzend helfen partitionierte Tabellen, um sehr große Tabellen in handhabbare Segmente zu unterteilen und Scans auf die relevanten Partitionen zu begrenzen.

ETL-Performance ist eine eigene Disziplin. Die häufigsten Ursachen langsamer Ladezeiten sind: unnötige Cursor und RBAR-Operationen (Row by Agonizing Row) statt mengenorientierter SQL-Operationen, fehlende Indizes auf Staging-Tabellen für MERGE-Operationen, unnötige Logging-Aktivität in Massentransaktionen und zu granulare Transaktionssteuerung. In meinen Projekten habe ich ETL-Strecken von mehrstündigen Laufzeiten auf unter eine Stunde gebracht, schlicht durch die Umstellung von Cursor-Logik auf set-basierte T-SQL-Operationen und durch das Hinzufügen gezielter temporärer Indizes während des Ladens.

Query-Tuning und Ausführungsplan-Analyse

Bei konkreten Performance-Problemen beginne ich mit dem Ausführungsplan. Der tatsächliche Ausführungsplan (nicht der geschätzte) zeigt, wo SQL Server Zeit und Ressourcen aufwendet: welche Operatoren teuer sind, wo Schätzfehler durch veraltete Statistiken entstehen, ob ein Join-Typ optimal ist und wo die kritischen Wartestatistiken liegen. Häufige Muster sind key lookups, die durch das Hinzufügen weniger Spalten zu einem Covering Index vermieden werden können, und Table Spools, die auf fehlende Indizes für MERGE-Quellen hinweisen.

Statistiken sind die Grundlage, auf der der Query Optimizer seine Entscheidungen trifft. Veraltete Statistiken führen zu Planentscheidungen, die auf falschen Annahmen über Datenmengen und Werteverteilungen basieren – mit teils dramatischen Performance-Einbrüchen. In produktiven DWH-Umgebungen sorge ich für regelmäßige Statistik-Updates im Wartungsfenster, kombiniert mit einem automatisierten Monitoring, das auf Pläne mit hohen Schätzfehlern aufmerksam macht.

• Clustered Columnstore Index auf Faktentabellen für analytische Abfragen
• Tabellenpartitionierung für sehr große Fakten und ETL-Effizienz
• Mengenorientierte T-SQL-Operationen statt Cursor und RBAR
• Covering Indexes auf Staging-Tabellen für effiziente MERGE-Operationen
• Ausführungsplan-Analyse: tatsächlicher Plan, Wartestatistiken, Kostentreiber
• Regelmäßige Statistik-Updates und Index-Pflege im Wartungsfenster

Vorgehen in der Zusammenarbeit

Ein Data-Warehouse-Projekt beginnt nicht mit dem ersten CREATE TABLE, sondern mit dem Verstehen der fachlichen Anforderungen. Welche Fragen sollen beantwortet werden? Welche Quellsysteme gibt es, und wie zuverlässig und vollständig sind ihre Daten? Welche historischen Daten sind vorhanden, und welche Historientiefe ist tatsächlich nötig? Diese Fragen klingen selbstverständlich, werden in der Praxis aber oft übersprungen – mit dem Ergebnis, dass Monate nach dem Projektstart ein Modell umgebaut werden muss, weil eine übersehene Anforderung die ursprüngliche Designentscheidung obsolet macht.

• Analyse: Quelldaten sichten, Datenqualität bewerten, fachliche Anforderungen verstehen
• Architektur: Schichtenmodell, Modellierungsansatz und ETL-Strategie festlegen
• Umsetzung: iterativer Aufbau, beginnend mit den geschäftskritischen Themengebieten
• Qualitätssicherung: tSQLt-Tests, Plausibilitätsregeln, Ergebnisabgleich
• Auslieferung: SSAS Tabular oder Power BI, mit dokumentierten Measure-Definitionen
• Betrieb: Monitoring, Fehler-Alerting, Wartungskonzept und Dokumentation

Ich arbeite remote, hybrid oder vor Ort – je nach Projektbedarf und Kundenpräferenz. In Projekten, die bereits ein Team haben, arbeite ich eingebettet: als zusätzliche Kapazität, als Spezialist für bestimmte Themenbereiche oder als technischer Lead, der Architektur und Richtung vorgibt, während das Team die Umsetzung trägt. In Projekten ohne bestehendes DWH-Team übernehme ich die vollständige Konzeption und Umsetzung, von der Schichtenarchitektur bis zur ersten produktiven Auslieferung.

Dokumentation ist für mich kein Anhang, sondern Teil der Lieferung. Architekturentscheidungen, Modell-Glossare, ETL-Beschreibungen und Betriebsanleitungen werden mitgeliefert – so, dass ein Team das DWH nach Projektende eigenständig weiterentwickeln und betreiben kann. Ein Data Warehouse, das nur sein Erbauer versteht, ist kein Asset, sondern ein Risiko.

Typische Einstiegssituationen: Ein Unternehmen hat ein gewachsenes DWH, das zunehmend wartungsintensiv ist und dessen ETL-Zeiten überhandnehmen. Oder ein DWH existiert gar nicht, und Reporting läuft direkt auf Produktionsdatenbanken – mit allen damit verbundenen Performance- und Qualitätsproblemen. Oder ein bestehendes DWH soll um neue Themengebiete erweitert werden, und es gibt niemanden im Haus, der das strukturiert aufbauen kann. In allen diesen Situationen schaffe ich Klarheit: Was ist vorhanden, was fehlt, und was ist der sinnvolle nächste Schritt.

Typische Leistungen rund um das Data Warehouse

Mein Angebot deckt den gesamten Lebenszyklus eines Data Warehouse ab – von der Konzeption über den Aufbau bis zur laufenden Weiterentwicklung und Modernisierung. Je nach Projektphase und Bedarf überbringe ich unterschiedliche Schwerpunkte.

• Konzeption und Architektur: Schichtenmodell, Modellierungsansatz, ETL-Strategie
• Dimensionsmodellierung nach Kimball: Sternschema, Faktentabellen, Dimensionen, Hierarchien
• Data-Vault-Modellierung: Hubs, Links, Satellites, Hashkeys, Ladelogik
• ETL-Entwicklung mit SSIS und T-SQL: Staging, Core, Reporting, inkrementell und idempotent
• SCD-Type-2-Historisierung: MERGE-basiert, Hash-Diff, vollständige Versionierung
• Datenqualitätssicherung: tSQLt-Unit-Tests, Quarantäne-Mechanismen, Plausibilitätsregeln
• CI/CD-Integration: Deployment über Jenkins oder Azure DevOps, automatische Testausführung
• SSAS Tabular: Modellaufbau, DAX-Measures, RLS, Partitionierung, Refresh-Strategie
• Performance-Analyse und -Optimierung: Indizes, Partitionierung, ETL-Tuning, Query-Optimierung
• Modernisierung gewachsener DWH: Architektur-Review, Konsolidierung, Dokumentation
• Anbindung und Migration nach Azure: ADF, Synapse, SSAS Tabular on Azure, Power BI Premium

Ich liefere keine Standardprojekte nach Schema F, sondern passe meine Arbeit an das konkrete Vorhaben an. Das beginnt mit dem Verständnis dessen, was tatsächlich gebraucht wird – und beinhaltet explizit auch das ehrliche Gespräch darüber, was nicht gebraucht wird und welchen Aufwand eine bestimmte Entscheidung nach sich zieht. Ein DWH muss proportional zur fachlichen Anforderung sein; die beste Architektur ist die einfachste, die die Anforderung zuverlässig erfüllt.

Meine Erfahrung reicht von kleinen mittelständischen Unternehmen mit einer Handvoll Quellsystemen bis zu großen Organisationen mit komplexen, heterogenen Datenlandschaften. Ich kenne die typischen Wachstumsschmerzen beider Welten: das mittelständische DWH, das zu einem Netz aus Excel-Exporten und manuellen Korrekturen geworden ist, ebenso wie das Konzern-DWH, das unter seinem eigenen Gewicht an Schnittstellen, Sonderfalllogik und technischen Schulden leidet. In beiden Fällen ist der Weg nach vorn ähnlich: Analyse, Priorisierung, strukturierter Aufbau, Qualitätssicherung.

Ausgewählte anonymisierte Referenzprojekte

Häufige Fragen zum Data Warehouse Consulting