SH

Sascha Hess

xenosystems.de - IT-Consulting & Data Management

www.xenosystems.de

Strategische Wissens-Roadmap 2026

Datenmodellierung Grundlagen für BI

Star Schema, Data Vault, 3NF — das richtige Modell für Ihren Kontext

1

3 Modellierungsansätze

Star Schema, Data Vault, 3NF — verglichen und bewertet

2

Praxismuster & SQL

Fertige DDL-Skripte und Abfragevorlagen für jeden Ansatz

3

Entscheidungsmatrix

Welches Modell passt zu welchem Projekt?

4

10 Modellierungsfehler

Die teuersten Fehler — erkannt und vermieden

5

30-Tage-Umsetzungsplan

Vom leeren Schema zum ersten produktiven BI-Modell

WAS SIE IN DIESEM KIT ERWARTEN DÜRFEN

■  3 Modellierungsansätze — Star Schema, 3NF und Data Vault: Konzept, Aufbau, Stärken, Schwächen.

■  SQL-Praxismuster — Fertige DDL-Skripte für Fakten- und Dimensionstabellen, Hub/Link/Satellite.

■  Entscheidungsmatrix — Welches Modell für welches Projekt? 10 Kriterien, klar bewertet.

■  SCD-Guide — Slowly Changing Dimensions: Typen 0, 1, 2, 3 erklärt und implementiert.

■  30-Tage-Umsetzungsplan — Vom leeren Schema zum ersten produktiven Modell.

ZIEL DIESES KITS

Nach dem Lesen und Umsetzen dieses Kits kennen Sie die drei wichtigsten BI-Modellierungsansätze, können für Ihr Projekt den richtigen wählen — und haben konkrete SQL-Muster, mit denen Sie sofort beginnen können. Kein theoretisches Lehrbuch, sondern ein Praxishandbuch mit sofort kopierbarem Code.

-- Staging-Tabelle: Beispiel tägliche Auftragsschnappschuss

CREATE TABLE stg.Auftraege (

    AuftragNr        NVARCHAR(20)    NOT NULL,

    KundenNr         NVARCHAR(20)    NOT NULL,

    ArtikelNr        NVARCHAR(30)    NOT NULL,

    Auftragsdatum    DATE            NOT NULL,

    Lieferdatum_Soll DATE            NULL,

    Lieferdatum_Ist  DATE            NULL,

    Menge            DECIMAL(18,3)   NOT NULL,

    Preis_Netto      DECIMAL(18,2)   NOT NULL,

    Waehrung         CHAR(3)         NOT NULL DEFAULT 'EUR',

    Ladezeit         DATETIME2       NOT NULL DEFAULT SYSUTCDATETIME()

);

-- Richtig: Surrogatschlüssel + Business Key getrennt

CREATE TABLE dim.Kunde (

    KundeKey     INT IDENTITY(1,1)  NOT NULL PRIMARY KEY,  -- Surrogatschlüssel

    KundenNr     NVARCHAR(20)       NOT NULL,               -- Business Key (ERP)

    Kundenname   NVARCHAR(200)      NOT NULL,

    -- weitere Attribute ...

    CONSTRAINT uq_Kunde_KundenNr UNIQUE (KundenNr)

);

-- Platzhalterdatensatz für fehlende Kundenzuordnung

INSERT INTO dim.Kunde (KundeKey, KundenNr, Kundenname, Branche, Region)

VALUES (-1, 'UNBEKANNT', 'Kein Kunde zugeordnet', 'Unbekannt', 'Unbekannt');

-- ETL-Ladeprotokoll

CREATE TABLE meta.ETL_Protokoll (

    ProtokolID     INT IDENTITY(1,1) PRIMARY KEY,

    JobName        NVARCHAR(100)  NOT NULL,

    Startzeit      DATETIME2      NOT NULL DEFAULT SYSUTCDATETIME(),

    Endzeit        DATETIME2      NULL,

    Status         NVARCHAR(20)   NOT NULL DEFAULT 'LÄUFT',  -- LÄUFT | OK | FEHLER

    ZeilenGeladen  INT            NULL,

    Fehlermeldung  NVARCHAR(MAX)  NULL

);

TYP 1 — TRANSAKTIONSFAKTEN:

  Eine Zeile pro Geschäftsvorfall.

  Beispiel: Eine Zeile pro Auftragsposition, pro Buchung, pro Produktionsauftrag.

  Vorteil: Maximale Flexibilität bei der Auswertung.

  Nachteil: Kein eingebauter Periodenvergleich — muss über Aggregation berechnet werden.

TYP 2 — PERIODISCHER SCHNAPPSCHUSS:

  Eine Zeile pro Objekt pro Periode (z.B. Lagerbestand je Artikel je Tag).

  Vorteil: Periodenvergleiche direkt aus der Tabelle.

  Nachteil: Großes Datenvolumen auch bei unverändertem Bestand.

TYP 3 — KUMULIERTER SCHNAPPSCHUSS:

  Eine Zeile pro Prozessinstanz mit mehreren Datumsspalten für Meilensteine.

  Beispiel: Auftrag → Produktion → Versand → Rechnung — je ein Datum in einer Zeile.

  Vorteil: Durchlaufzeiten und Prozessanalysen ohne komplexe Joins.

  Nachteil: Zeile wird mehrfach aktualisiert — aufwendiger im ETL.

-- ══════════════════════════════════════════════

-- DIMENSIONSTABELLEN

-- ══════════════════════════════════════════════

CREATE TABLE dim.Datum (

    DatumKey       INT            NOT NULL PRIMARY KEY,  -- YYYYMMDD

    Datum          DATE           NOT NULL,

    Jahr           SMALLINT       NOT NULL,

    Quartal        TINYINT        NOT NULL,              -- 1–4

    Monat          TINYINT        NOT NULL,              -- 1–12

    MonatName      NVARCHAR(20)   NOT NULL,

    Kalenderwoche  TINYINT        NOT NULL,

    Wochentag      TINYINT        NOT NULL,              -- 1=Mo, 7=So

    IstArbeitstag  BIT            NOT NULL DEFAULT 1,

    IstFeiertag    BIT            NOT NULL DEFAULT 0,

    Geschaeftsjahr SMALLINT       NOT NULL,             -- bei abweich. GJ

    CONSTRAINT uq_Datum UNIQUE (Datum)

);

CREATE TABLE dim.Kunde (

    KundeKey       INT IDENTITY(1,1) NOT NULL PRIMARY KEY,

    KundenNr       NVARCHAR(20)   NOT NULL,

    Kundenname     NVARCHAR(200)  NOT NULL,

    Branche        NVARCHAR(100)  NOT NULL DEFAULT 'Unbekannt',

    Region         NVARCHAR(100)  NOT NULL DEFAULT 'Unbekannt',

    Land           CHAR(2)        NOT NULL DEFAULT 'DE',

    Kundensegment  NVARCHAR(50)   NOT NULL DEFAULT 'Unbekannt',

    GueltigVon     DATE           NOT NULL,

    GueltigBis     DATE           NOT NULL DEFAULT '9999-12-31',

    IstAktuell     BIT            NOT NULL DEFAULT 1,

    CONSTRAINT uq_Kunde_BK UNIQUE (KundenNr, GueltigVon)

);

CREATE TABLE dim.Artikel (

    ArtikelKey     INT IDENTITY(1,1) NOT NULL PRIMARY KEY,

    ArtikelNr      NVARCHAR(30)   NOT NULL,

    Artikelname    NVARCHAR(300)  NOT NULL,

    Produktgruppe  NVARCHAR(100)  NOT NULL DEFAULT 'Unbekannt',

    Produktlinie   NVARCHAR(100)  NOT NULL DEFAULT 'Unbekannt',

    Einheit        NVARCHAR(10)   NOT NULL,

    GueltigVon     DATE           NOT NULL,

    GueltigBis     DATE           NOT NULL DEFAULT '9999-12-31',

    IstAktuell     BIT            NOT NULL DEFAULT 1,

    CONSTRAINT uq_Artikel_BK UNIQUE (ArtikelNr, GueltigVon)

);

CREATE TABLE dim.Vertriebskanal (

    KanalKey       INT IDENTITY(1,1) NOT NULL PRIMARY KEY,

    KanalCode      NVARCHAR(10)   NOT NULL UNIQUE,

    Kanalname      NVARCHAR(100)  NOT NULL,

    Kanaltyp       NVARCHAR(50)   NOT NULL  -- Direkt | Handel | Online | Partner

);

-- ══════════════════════════════════════════════

-- FAKTENTABELLE (Transaktionsfakten)

-- ══════════════════════════════════════════════

CREATE TABLE fakt.Auftragsposition (

    AuftragsPosKey  BIGINT IDENTITY(1,1) NOT NULL PRIMARY KEY,

    -- Dimensionsreferenzen

    DatumKey        INT            NOT NULL REFERENCES dim.Datum(DatumKey),

    KundeKey        INT            NOT NULL REFERENCES dim.Kunde(KundeKey),

    ArtikelKey      INT            NOT NULL REFERENCES dim.Artikel(ArtikelKey),

    KanalKey        INT            NOT NULL REFERENCES dim.Vertriebskanal(KanalKey),

    -- Business Keys (für Rückverfolgung ins Quellsystem)

    AuftragNr       NVARCHAR(20)   NOT NULL,

    PosNr           SMALLINT       NOT NULL,

    -- Kennzahlen (Measures)

    Menge           DECIMAL(18,3)  NOT NULL,

    Umsatz_Netto    DECIMAL(18,2)  NOT NULL,

    Wareneinsatz    DECIMAL(18,2)  NOT NULL,

    Deckungsbeitrag AS (Umsatz_Netto - Wareneinsatz) PERSISTED,

    Rabatt_Pct      DECIMAL(6,3)   NOT NULL DEFAULT 0,

    -- Metadaten

    Ladezeit        DATETIME2      NOT NULL DEFAULT SYSUTCDATETIME()

);

-- Index für häufigste Abfragemuster

CREATE NONCLUSTERED INDEX ix_Fakt_Datum

    ON fakt.Auftragsposition (DatumKey) INCLUDE (Umsatz_Netto, Deckungsbeitrag);

CREATE NONCLUSTERED INDEX ix_Fakt_Kunde

    ON fakt.Auftragsposition (KundeKey) INCLUDE (DatumKey, Umsatz_Netto);

-- Umsatz und Deckungsbeitrag nach Monat, Produktgruppe und Region

SELECT

    d.Jahr,

    d.MonatName,

    a.Produktgruppe,

    k.Region,

    SUM(f.Umsatz_Netto)    AS Umsatz,

    SUM(f.Deckungsbeitrag) AS DB_I,

    SUM(f.Deckungsbeitrag) / NULLIF(SUM(f.Umsatz_Netto), 0) * 100 AS DB_Quote_Pct

FROM      fakt.Auftragsposition f

JOIN      dim.Datum             d ON f.DatumKey   = d.DatumKey

JOIN      dim.Kunde             k ON f.KundeKey   = k.KundeKey

JOIN      dim.Artikel           a ON f.ArtikelKey = a.ArtikelKey

WHERE     d.Jahr = 2026

  AND     k.IstAktuell = 1   -- nur aktuelle Dimensionsversion

GROUP BY  d.Jahr, d.MonatName, d.Monat, a.Produktgruppe, k.Region

ORDER BY  d.Monat, a.Produktgruppe;

WANN STAR SCHEMA WÄHLEN

■  Reporting und Dashboards sind der primäre Anwendungsfall.

■  Das BI-Team ist klein — Einfachheit hat Vorrang vor Flexibilität.

■  Performance bei großen Datenmengen ist kritisch.

■  Power BI oder DeltaMaster ist das Frontend — beide sind für Star Schema optimiert.

■  Quellsysteme sind stabil und ändern sich selten strukturell.

INMONS ARCHITEKTUR (3NF-zentriert):

  Quellsysteme

      ↓ ETL

  Staging (Rohdaten, unverändert)

      ↓ ETL

  Enterprise DWH (3NF — "Single Source of Truth")

      ↓ ETL

  Data Marts (Star Schema — je Fachbereich)

      ↓

  BI-Tools / Reports

KIMBALLS ARCHITEKTUR (Star-Schema-zentriert):

  Quellsysteme

      ↓ ETL

  Staging

      ↓ ETL

  Dimensional Warehouse (Star Schema — Bus-Architektur)

      ↓

  BI-Tools / Reports

-- 3NF-Modell: Normalisiert, ohne Redundanzen

CREATE TABLE core.Kunden (

    KundenNr     NVARCHAR(20)  NOT NULL PRIMARY KEY,

    Kundenname   NVARCHAR(200) NOT NULL,

    BrancheID    INT           NOT NULL REFERENCES core.Branchen(BrancheID),

    RegionID     INT           NOT NULL REFERENCES core.Regionen(RegionID)

    -- Keine Redundanz: Branchenname nur einmal in core.Branchen

);

CREATE TABLE core.Branchen (

    BrancheID    INT IDENTITY(1,1) PRIMARY KEY,

    Branchename  NVARCHAR(100) NOT NULL UNIQUE

);

CREATE TABLE core.Regionen (

    RegionID     INT IDENTITY(1,1) PRIMARY KEY,

    Regionname   NVARCHAR(100) NOT NULL,

    Land         CHAR(2)       NOT NULL

);

CREATE TABLE core.Auftraege (

    AuftragNr    NVARCHAR(20)  NOT NULL PRIMARY KEY,

    KundenNr     NVARCHAR(20)  NOT NULL REFERENCES core.Kunden(KundenNr),

    Auftragsdatum DATE         NOT NULL,

    KanalCode    NVARCHAR(10)  NOT NULL REFERENCES core.Kanaele(KanalCode)

);

CREATE TABLE core.Auftragspositionen (

    AuftragNr    NVARCHAR(20)  NOT NULL REFERENCES core.Auftraege(AuftragNr),

    PosNr        SMALLINT      NOT NULL,

    ArtikelNr    NVARCHAR(30)  NOT NULL REFERENCES core.Artikel(ArtikelNr),

    Menge        DECIMAL(18,3) NOT NULL,

    Preis_Netto  DECIMAL(18,2) NOT NULL,

    PRIMARY KEY (AuftragNr, PosNr)

);

STÄRKEN 3NF:

  ✓ Kein Redundanzproblem: Änderungen an einem Wert an genau einer Stelle

  ✓ Flexibel bei neuen Quellsystemen — kein Umbau des Gesamtmodells

  ✓ Geeignet als "Core Layer" zwischen Staging und Marts

  ✓ Historisierung sauber modellierbar ohne Denormalisierungs-Overhead

SCHWÄCHEN 3NF FÜR REPORTING:

  ✗ Komplexe Abfragen: Viele JOINs für einfache Reports

  ✗ Schlechtere Performance als Star Schema bei großen Aggregationen

  ✗ Für BI-Frontend-Entwickler schwerer verständlich

  ✗ Power BI und ähnliche Tools arbeiten schlechter mit stark normalis. Modellen

WANN 3NF WÄHLEN

■  Als Core-Schicht zwischen Staging und Presentation Layer (Inmon-Architektur).

■  Wenn sehr viele heterogene Quellsysteme integriert werden müssen.

■  Wenn die Datenstruktur der Quellsysteme sich häufig ändert.

■  Als Grundlage, aus der dann spezifische Star-Schema-Marts aufgebaut werden.

■  Wenn operative Berichte (kein reines BI) aus derselben Datenbasis laufen sollen.

DATA VAULT STRUKTUR (KONZEPT):

  HUB_Kunde ←─── LNK_KundeAuftrag ───→ HUB_Auftrag

      │                                      │

  SAT_Kunde_Stamm                      SAT_Auftrag_Details

  SAT_Kunde_Segment                    SAT_Auftrag_Lieferstatus

  SAT_Kunde_Klassifikation

-- ══════════════════════════════════════════════

-- HUBS

-- ══════════════════════════════════════════════

CREATE TABLE dv.HUB_Kunde (

    HUB_KundeKey   BINARY(16)     NOT NULL PRIMARY KEY, -- HASHBYTES('SHA2_256', KundenNr)

    KundenNr       NVARCHAR(20)   NOT NULL UNIQUE,       -- Business Key

    Ladedatum      DATETIME2      NOT NULL DEFAULT SYSUTCDATETIME(),

    Quelle         NVARCHAR(50)   NOT NULL               -- Quellsystem-Kennung

);

CREATE TABLE dv.HUB_Artikel (

    HUB_ArtikelKey BINARY(16)     NOT NULL PRIMARY KEY,

    ArtikelNr      NVARCHAR(30)   NOT NULL UNIQUE,

    Ladedatum      DATETIME2      NOT NULL DEFAULT SYSUTCDATETIME(),

    Quelle         NVARCHAR(50)   NOT NULL

);

-- ══════════════════════════════════════════════

-- LINK

-- ══════════════════════════════════════════════

CREATE TABLE dv.LNK_Auftragsposition (

    LNK_AuftrPosiKey BINARY(16)   NOT NULL PRIMARY KEY, -- Hash aus AuftragNr+PosNr

    HUB_KundeKey   BINARY(16)     NOT NULL REFERENCES dv.HUB_Kunde(HUB_KundeKey),

    HUB_ArtikelKey BINARY(16)     NOT NULL REFERENCES dv.HUB_Artikel(HUB_ArtikelKey),

    AuftragNr      NVARCHAR(20)   NOT NULL,

    PosNr          SMALLINT       NOT NULL,

    Ladedatum      DATETIME2      NOT NULL DEFAULT SYSUTCDATETIME(),

    Quelle         NVARCHAR(50)   NOT NULL

);

-- ══════════════════════════════════════════════

-- SATELLITES

-- ══════════════════════════════════════════════

CREATE TABLE dv.SAT_Kunde_Stamm (

    HUB_KundeKey   BINARY(16)     NOT NULL REFERENCES dv.HUB_Kunde(HUB_KundeKey),

    Ladedatum      DATETIME2      NOT NULL DEFAULT SYSUTCDATETIME(),

    Enddatum       DATETIME2      NULL,       -- NULL = aktueller Datensatz

    HashDiff       BINARY(16)     NOT NULL,   -- Hash aller Attributwerte — für Änderungserkennung

    Kundenname     NVARCHAR(200)  NOT NULL,

    Strasse        NVARCHAR(200)  NULL,

    PLZ            NVARCHAR(10)   NULL,

    Ort            NVARCHAR(100)  NULL,

    Land           CHAR(2)        NULL,

    Quelle         NVARCHAR(50)   NOT NULL,

    PRIMARY KEY (HUB_KundeKey, Ladedatum)

);

CREATE TABLE dv.SAT_Auftragsposition_Kennzahlen (

    LNK_AuftrPosiKey BINARY(16)  NOT NULL REFERENCES dv.LNK_Auftragsposition(LNK_AuftrPosiKey),

    Ladedatum      DATETIME2     NOT NULL DEFAULT SYSUTCDATETIME(),

    Enddatum       DATETIME2     NULL,

    HashDiff       BINARY(16)    NOT NULL,

    Menge          DECIMAL(18,3) NOT NULL,

    Preis_Netto    DECIMAL(18,2) NOT NULL,

    Rabatt_Pct     DECIMAL(6,3)  NOT NULL DEFAULT 0,

    Waehrung       CHAR(3)       NOT NULL DEFAULT 'EUR',

    Quelle         NVARCHAR(50)  NOT NULL,

    PRIMARY KEY (LNK_AuftrPosiKey, Ladedatum)

);

SCHICHTENMODELL DATA VAULT:

  Quellsysteme → Raw Vault (Hub/Link/Satellite, roh)

                     ↓

               Business Vault (Geschäftsregeln, berechnete Felder)

                     ↓

               Information Mart (Star Schema für Reporting)

                     ↓

               BI-Tools (Power BI, DeltaMaster, Excel)

WANN DATA VAULT WÄHLEN

■  Viele heterogene Quellsysteme — und neue kommen regelmäßig dazu.

■  Vollständige, lückenlose Historisierung aller Änderungen ist Pflicht (Audit, Compliance).

■  Das Datenmodell der Quellsysteme ändert sich häufig — Agilität ist wichtiger als Einfachheit.

■  Großes, erfahrenes BI-Team — Data Vault erfordert mehr Disziplin und Lernkurve.

■  Langfristiger Aufbau eines unternehmensweiten Data Warehouse über viele Jahre.

KRITERIUM                | STAR SCHEMA | 3NF (CORE) | DATA VAULT

─────────────────────────|─────────────|────────────|───────────

Einstiegshürde           |     ★★★     |    ★★      |     ★

Query-Komplexität        |     ★★★     |    ★★      |     ★

Abfrage-Performance      |     ★★★     |    ★★      |    ★★

Historisierung           |    ★★       |    ★★      |    ★★★

Flexibilität bei Änder.  |     ★       |    ★★      |    ★★★

Mehrquellen-Integration  |    ★★       |    ★★      |    ★★★

Redundanzfreiheit        |     ★       |    ★★★     |    ★★★

Tool-Kompatibilität BI   |    ★★★      |    ★★      |     ★

Teamkompetenz benötigt   |     ★★★     |    ★★      |     ★

Projektgröße KMU         |    ★★★      |    ★★      |     ★

★★★ = sehr gut geeignet / einfach

★★  = geeignet mit Einschränkungen

★   = eher ungeeignet / aufwendig

SZENARIO 1 — KLEINES KMU, ERSTES BI-PROJEKT:

  → Star Schema

  Begründung: Schnellster Einstieg, beste Tool-Unterstützung,

  überschaubare Komplexität, kleines Team beherrschbar.

SZENARIO 2 — MITTELSTÄNDLER, 2–4 QUELLSYSTEME, ERFAHRENES TEAM:

  → Staging → 3NF Core → Star-Schema-Marts

  Begründung: 3NF als stabile Mitte, Star Schema für Reporting,

  gute Balance aus Flexibilität und Performance.

SZENARIO 3 — GROSSUNTERNEHMEN / KONZERN, VIELE QUELLSYSTEME:

  → Data Vault als Raw+Business Vault → Information Mart (Star Schema)

  Begründung: Maximale Agilität bei Quellsystemänderungen,

  lückenlose Historisierung, parallele Entwicklung möglich.

SZENARIO 4 — COMPLIANCE-KRITISCHE UMGEBUNG (Revision, Banken):

  → Data Vault (Raw Vault als unveränderliches Archiv)

  Begründung: Jede Änderung nachvollziehbar, kein Löschen,

  vollständige Auditierbarkeit aller Datenflüsse.

SZENARIO 5 — AGILES PROJEKT MIT SICH ÄNDERNDEN ANFORDERUNGEN:

  → Data Vault oder Staging → Star Schema (iterativ ausgebaut)

  Begründung: Neue Quellen können ohne Umbau des Bestandsmodells

  angebunden werden.

EMPFOHLENE SCHICHTENARCHITEKTUR FÜR KMU:

  Schema stg  → Rohdaten (1:1 aus Quellsystem, mit Ladezeitstempel)

  Schema core → Integriert, historisiert, bereinigt (3NF oder vereinfacht DV)

  Schema mart → Star Schema je Fachbereich (Vertrieb, Finanzen, Produktion)

  Schema meta → ETL-Protokoll, Konfiguration, Datenqualitäts-Logs

Beschreibung: Attribut wird nie aktualisiert — ursprünglicher Wert bleibt.

Verwendung:   Geburtstag, Erstbestelldatum, unveränderliche Klassifikationen.

SQL:          Kein Update nötig — Wert wird nur einmalig beim INSERT gesetzt.

Beschreibung: Aktueller Wert überschreibt alten Wert — keine Historie.

Verwendung:   Tippfehler-Korrekturen, technische Attribute ohne historische Relevanz.

Vorteil:      Einfach. Kein Platzbedarf für Historisierung.

Nachteil:     Historische Auswertungen zeigen immer den aktuellen Wert.

-- SCD Typ 1: Einfaches UPDATE

UPDATE dim.Kunde

SET    Kundenname = 'Mustermann GmbH & Co. KG',

       Branche    = 'Maschinenbau'

WHERE  KundenNr   = 'K-10042'

  AND  IstAktuell = 1;

Beschreibung: Jede Änderung erzeugt eine neue Zeile. Alte Zeile bleibt erhalten

              mit Enddatum. Vollständige Historie aller Zustände.

Verwendung:   Alle historisch relevanten Dimensionsattribute (Region, Segment,

              Produktgruppe, Abteilung, Preis).

Vorteil:      Vollständige historische Korrektheit — Fakten zeigen immer den

              zum Zeitpunkt gültigen Dimensionswert.

Nachteil:     Größere Tabellen. Komplexerer ETL. JOIN-Logik beachten.

-- SCD Typ 2: Alte Zeile schließen, neue Zeile einfügen

BEGIN TRANSACTION;

-- 1. Alte Zeile schließen

UPDATE dim.Kunde

SET    GueltigBis = CAST(GETDATE() AS DATE),

       IstAktuell = 0

WHERE  KundenNr   = 'K-10042'

  AND  IstAktuell = 1;

-- 2. Neue Zeile einfügen (neues Segment)

INSERT INTO dim.Kunde

    (KundenNr, Kundenname, Branche, Region, Kundensegment, GueltigVon, GueltigBis, IstAktuell)

VALUES

    ('K-10042', 'Mustermann GmbH', 'Maschinenbau', 'Bayern', 'KEY ACCOUNT',

     CAST(GETDATE() AS DATE), '9999-12-31', 1);

COMMIT;

Beschreibung: Aktuelle und exakt ein vorheriger Wert werden in separaten Spalten

              gespeichert. Nur begrenzte Historisierung.

Verwendung:   Wenn nur "aktuell vs. direkt davor" relevant ist (z. B. letzter Verkaufspreis).

Nachteil:     Nur ein historischer Wert — ältere Zustände gehen verloren.

-- SCD Typ 3: Vorherigen Wert in Extra-Spalte sichern

ALTER TABLE dim.Artikel ADD Produktgruppe_Vorher NVARCHAR(100) NULL;

UPDATE dim.Artikel

SET    Produktgruppe_Vorher = Produktgruppe,

       Produktgruppe        = 'Präzisionswerkzeuge'

WHERE  ArtikelNr = 'A-2089';

-- Datumsdimension befüllen (SQL Server — für 10 Jahre)

WITH Dates AS (

    SELECT CAST('2020-01-01' AS DATE) AS Datum

    UNION ALL

    SELECT DATEADD(DAY, 1, Datum) FROM Dates WHERE Datum < '2030-12-31'

)

INSERT INTO dim.Datum

    (DatumKey, Datum, Jahr, Quartal, Monat, MonatName, Kalenderwoche,

     Wochentag, IstArbeitstag, Geschaeftsjahr)

SELECT

    CAST(FORMAT(Datum, 'yyyyMMdd') AS INT),

    Datum,

    YEAR(Datum),

    DATEPART(QUARTER, Datum),

    MONTH(Datum),

    FORMAT(Datum, 'MMMM', 'de-DE'),

    DATEPART(ISO_WEEK, Datum),

    DATEPART(WEEKDAY, Datum),                          -- 1=So (SQL Server Standard)

    CASE WHEN DATEPART(WEEKDAY, Datum) IN (1,7) THEN 0 ELSE 1 END,

    YEAR(Datum)                                        -- ggf. abweichendes GJ anpassen

FROM  Dates

OPTION (MAXRECURSION 4000);

FULL LOAD:

  Beschreibung: Alle Daten werden jedes Mal vollständig neu geladen.

  Vorteil:      Einfach zu implementieren. Keine Deltalogik notwendig.

  Nachteil:     Langsam bei großen Tabellen. Hohe Last auf Quellsystem.

  Geeignet:     Kleine Tabellen (< 100.000 Zeilen), Stammdaten, Konfiguration.

DELTA LOAD:

  Beschreibung: Nur neue oder geänderte Datensätze seit dem letzten Lauf laden.

  Vorteil:      Schnell, schonend für Quellsystem, skalierbar.

  Nachteil:     Erfordert zuverlässiges Änderungsmerkmal im Quellsystem.

  Geeignet:     Große Transaktions- und Bewegungsdatentabellen.

ÄNDERUNGSMERKMALE IM QUELLSYSTEM (DELTA-ERKENNUNG):

  ✓ Änderungstimestamp (UpdDatum, ModifiedAt) — am zuverlässigsten

  ✓ SQL Server Change Data Capture (CDC) — automatisch, ohne Quelleingriff

  ✓ Sequenznummern oder Auto-Increment-IDs — nur für neue Zeilen (keine Updates)

  ✗ Trigger auf Quelltabellen — vermeiden: Performance-Risiko im Quellsystem

-- MERGE: Upsert für Dimensionstabellen (SCD Typ 1)

-- Kann beliebig oft ausgeführt werden — gleiches Ergebnis (Idempotenz)

MERGE dim.Vertriebskanal AS Ziel

USING (

    SELECT KanalCode, Kanalname, Kanaltyp

    FROM   stg.Vertriebskanaele              -- Staging-Quelle

) AS Quelle ON Ziel.KanalCode = Quelle.KanalCode

WHEN MATCHED AND (

    Ziel.Kanalname <> Quelle.Kanalname OR

    Ziel.Kanaltyp  <> Quelle.Kanaltyp

) THEN

    UPDATE SET

        Ziel.Kanalname = Quelle.Kanalname,

        Ziel.Kanaltyp  = Quelle.Kanaltyp

WHEN NOT MATCHED BY TARGET THEN

    INSERT (KanalCode, Kanalname, Kanaltyp)

    VALUES (Quelle.KanalCode, Quelle.Kanalname, Quelle.Kanaltyp);

ZWINGEND EINZUHALTENDE LADEREIHENFOLGE:

  1. Staging (aus allen Quellsystemen parallel ladbar)

       ↓

  2. Dimensionstabellen (parallel ladbar, keine Abhängigkeiten untereinander)

       ↓

  3. Faktentabellen (erst nach allen Dimensionen — wegen Foreign Keys)

       ↓

  4. Aggregations- und Hilfstabellen (optional, nach Fakten)

WICHTIG: Faktentabellen dürfen erst geladen werden, wenn alle referenzierten

Dimensionszeilen bereits existieren — sonst Foreign-Key-Verletzungen.

Unbekannte Dimensionswerte → Platzhalterdatensatz (Surrogatschlüssel = -1).

-- FAKTENTABELLE: Clustered Index auf häufigste Filterspalte

-- (meist DatumKey — da zeitbasierte Abfragen dominieren)

CREATE CLUSTERED INDEX cix_Fakt_Datum

    ON fakt.Auftragsposition (DatumKey);

-- Non-Clustered Indizes für weitere häufige Filterkombinationen

CREATE NONCLUSTERED INDEX ix_Fakt_KundeArtikel

    ON fakt.Auftragsposition (KundeKey, ArtikelKey)

    INCLUDE (Umsatz_Netto, Deckungsbeitrag, Menge);

-- COLUMNSTORE INDEX für Aggregationsabfragen (BI-typisch)

-- Massive Performance-Gewinne bei GROUP BY über Millionen Zeilen

CREATE NONCLUSTERED COLUMNSTORE INDEX csi_Fakt_Auftrag

    ON fakt.Auftragsposition

    (DatumKey, KundeKey, ArtikelKey, KanalKey,

     Umsatz_Netto, Deckungsbeitrag, Menge, Rabatt_Pct);

-- DIMENSIONSTABELLEN: Index auf Business Key (für ETL-Lookups)

CREATE NONCLUSTERED INDEX ix_Dim_Kunde_BK

    ON dim.Kunde (KundenNr) INCLUDE (KundeKey)

    WHERE IstAktuell = 1;    -- Gefilterter Index: nur aktuelle Zeilen

-- Partitionierungsfunktion: nach Jahr (für Faktentabellen mit DatumKey YYYYMMDD)

CREATE PARTITION FUNCTION pf_JahrDatum (INT)

AS RANGE RIGHT FOR VALUES (

    20220101, 20230101, 20240101, 20250101, 20260101, 20270101

);

-- Partitionsschema auf Filegroups verteilen

CREATE PARTITION SCHEME ps_JahrDatum

AS PARTITION pf_JahrDatum

ALL TO ([PRIMARY]);   -- Produktiv: je Partition eigene Filegroup auf separater SSD

-- Faktentabelle mit Partitionierung erstellen

CREATE TABLE fakt.Auftragsposition_Part (

    -- gleiche Spalten wie oben ...

    DatumKey     INT NOT NULL

) ON ps_JahrDatum (DatumKey);   -- Partitionierungsspalte

POWER BI INKREMENTELLE AKTUALISIERUNG (KONZEPT):

  ■ Parameterpaar RangeStart / RangeEnd in Power Query definieren

  ■ Tabelle nach diesen Parametern filtern

  ■ Im Dataset-Dialog: "Inkrementelle Aktualisierung" aktivieren

  ■ Historische Daten (z.B. > 2 Jahre): Nur einmalig laden, dann eingefroren

  ■ Aktueller Rollierende Zeitraum (z.B. 30 Tage): Täglich neu geladen

  Ergebnis: Tägliches Refresh dauert Minuten statt Stunden

-- Statistiken aktualisieren (täglich, nach ETL-Abschluss)

-- Für alle Tabellen im mart-Schema

DECLARE @sql NVARCHAR(MAX) = '';

SELECT @sql += 'UPDATE STATISTICS ' + QUOTENAME(s.name) + '.' + QUOTENAME(t.name)

               + ' WITH FULLSCAN;' + CHAR(13)

FROM   sys.tables t

JOIN   sys.schemas s ON t.schema_id = s.schema_id

WHERE  s.name IN ('fakt', 'dim', 'mart');

EXEC sp_executesql @sql;

-- Columnstore-Index-Reorganisation (wöchentlich)

-- Schließt offene Delta-Stores und komprimiert Rowgroups

ALTER INDEX csi_Fakt_Auftrag ON fakt.Auftragsposition REORGANIZE

WITH (COMPRESS_ALL_ROW_GROUPS = ON);

VOR DEM START

Klären Sie vor dem ersten Tag zwei Voraussetzungen: (1) Read-only-Zugang zum ERP-Quellsystem ist vorhanden und genehmigt. (2) Ein dedizierter SQL-Server oder eine Datenbankinstanz für das DWH ist bereitgestellt. Ohne diese beiden Punkte verzögert sich jedes Projekt um Wochen.

ERGEBNIS NACH 30 TAGEN

Sie haben ein produktives BI-Datenmodell: eine Staging-Schicht, ein befülltes Star Schema mit Datums- und Stammdatendimensionen, eine erste Faktentabelle, automatisierten ETL-Job mit Monitoring — und ein angebundenes BI-Tool mit ersten validierten KPIs. Das Fundament für alle weiteren Ausbaustufen ist gelegt.

Data-Warehouse-Aufbau

Konzeption und Implementierung von DWH-Architekturen (Star Schema, Data Vault, Hybrid) — inkl. ETL, Staging und Präsentationsschicht. Ab 5 Tage.

BI-Dashboard-Aufbau

Power BI / DeltaMaster GF-Dashboards inkl. KPI-Definition, Datenmodell und ETL-Strecken — für KMU ab 1 Woche Projektumfang.

SQL Server DB Health Check

Professioneller Audit Ihres SQL Servers — Managementreport, Risikobewertung und Maßnahmenplan. Scope: 3–5 Tage.

ERP-Einführungsberatung

Begleitung von ERP-Projekten (MACH, Dynamics NAV/BC, APplus) — Datenmigration, Schulung, Go-Live-Support.

Interim IT-Management

Übernahme der IT-Steuerung auf Zeit — Budgetplanung, Dienstleister-Management, strategische IT-Ausrichtung.