SH

Sascha Hess

xenosystems.de - IT-Consulting & Data Management

www.xenosystems.de

NOTFALL-KIT – SQL SERVER 2026

SQL Server

Data Lineage & Datenherkunft

Woher kommen Ihre Daten — und welchen können Sie vertrauen?

1

10 Lineage-Fallen

Die häufigsten Fehler bei der Datenherkunftsdokumentation — mit Sofort-Lösungen

2

Lineage-Dokumentation

Vorlage und Schichtenmodell für jede Datenpipeline im KMU

3

SQL-Diagnose-Toolkit

7 Skripte zur automatischen Abhängigkeitsanalyse in SQL Server

4

Tool-Vergleich 2026

Purview, OpenMetadata, dbt — was passt zu welcher Umgebung?

5

30-Tage-Lineage-Plan

Von Null zu einer vollständig dokumentierten Datenpipeline

WAS SIE IN DIESEM BUCH ERWARTEN DÜRFEN

■  10 Lineage-Fallen — Die häufigsten Fehler bei der Datenherkunftsdokumentation mit konkreten Gegenmaßnahmen.

■  Schichtenmodell — Vollständige Lineage-Dokumentationsvorlage für jede Datenpipeline vom Quellsystem bis zum Report.

■  SQL-Diagnose-Toolkit — 7 DMV- und Systemkatalog-Skripte zur automatischen Abhängigkeitsanalyse in SQL Server.

■  Tool-Vergleich — Purview, OpenMetadata, dbt und Atlan im ehrlichen Vergleich für KMU.

■  30-Tage-Lineage-Plan — Von der ersten Bestandsaufnahme zur vollständig dokumentierten Datenpipeline.

DEFINITION: WAS IST DATA LINEAGE?

Data Lineage dokumentiert für jeden Datenpunkt: Woher stammt er (Quelle)? Welche Transformationen hat er durchlaufen (Herkunftspfad)? Wer oder was verwendet ihn heute (Abhängigkeiten)? Und: Was passiert downstream, wenn er sich ändert (Impact)? Vollständige Lineage macht Daten nachvollziehbar, vertrauenswürdig und änderungssicher.

DAS 5-SCHICHTEN-LINEAGE-MODELL:

══════════════════════════════════════════════════════════════

SCHICHT 1 — QUELLSYSTEM (Source)

  Was:    Produktive Anwendungsdatenbank, ERP, CRM, API, Datei

  Wer:    System-Owner (ERP-Team, IT)

  Risiko: Schemaänderungen, Verfügbarkeit, Zugriffsrechte

      ↓  [Extraktion: CDC, Full Load, API-Pull, File Drop]

SCHICHT 2 — STAGING / LANDING ZONE

  Was:    Rohdaten, unverändert aus der Quelle

  Wer:    Data Engineer / DBA

  Risiko: Vollständigkeit, Latenzen, Fehlerbehandlung

      ↓  [Transformation: Bereinigung, Typisierung, Anreicherung]

SCHICHT 3 — DATA WAREHOUSE / DATA MART

  Was:    Bereinigt, modelliert, historisiert (Fakten + Dimensionen)

  Wer:    Data Architect / BI-Entwickler

  Risiko: Modellierungsfehler, fehlerhafte KPI-Logik

      ↓  [Semantic Layer: Views, Measures, Berechnungen]

SCHICHT 4 — SEMANTIC LAYER

  Was:    Power BI Dataset, Analysis Services Cube, SQL Views

  Wer:    BI-Entwickler / Controlling

  Risiko: DAX-Fehler, falsche RLS, veraltete Measures

      ↓  [Visualisierung: Reports, Dashboards, Exports]

SCHICHT 5 — REPORT / DASHBOARD / EXPORT

  Was:    Power BI Report, Excel, PDF, API-Endpunkt

  Wer:    BI-Entwickler / Fachbereich

  Risiko: Falsche Filterung, Missverständnisse beim Leser

══════════════════════════════════════════════════════════════

LINEAGE-DOKUMENT — VOLLSTÄNDIGE VORLAGE:

══════════════════════════════════════════════════════════════

KPI / DATENPUNKT:    Umsatz Netto (monatlich, je Kunde)

Fachlicher Owner:    CFO / Controlling-Leitung

Technischer Owner:   BI-Entwickler / DBA

Dokument-Version:    1.3 — 2026-02-15

Review-Termin:       2026-08-15

──────────────────────────────────────────────────────────────

SCHICHT 1 — QUELLSYSTEM:

  System:      ERP (MACH MBS), SQL Server: srv-erp01

  Datenbank:   ERP_Prod

  Tabelle:     dbo.Belege

  Schlüsselfelder: BelegNr, BelegDatum, KundenID, Betrag_Netto

  Filter:      Belegart IN ('RE','GS','ST')

               AND Storniert = 0

  Aktualisierung: Real-time OLTP

  Owner:       ERP-Adminteam, IT-Abteilung

──────────────────────────────────────────────────────────────

SCHICHT 2 — STAGING:

  Prozess:     SQL Agent Job: ETL_Umsatz_Daily

  Zeitplan:    Täglich 03:00 Uhr

  Methode:     CDC (Changed Data Capture) auf Belege

  Zieldatenbank: DWH_Staging, Tabelle: stg.Belege_Delta

  Fehler-Log:  DWH_Staging.dbo.ETL_Fehler_Log

  Alert:       E-Mail an dba@firma.de bei Job-Fehler

──────────────────────────────────────────────────────────────

SCHICHT 3 — DATA WAREHOUSE:

  Datenbank:   DWH_Prod

  Faktentabelle: dbo.Fact_Umsatz

  Dimensionen: Dim_Zeit, Dim_Kunde, Dim_Artikel, Dim_Region

  Transformationslogik:

    - Währung: Fremdwährung → EUR (Tageskurs aus Dim_Kurs)

    - Stornos: negative Einträge, reduzieren Perioden-Umsatz

    - Datum:   Buchungsdatum (nicht Zahlungsdatum, nicht Lieferdatum)

  Historisierung: SCD Typ 2 auf Dim_Kunde (Adressänderungen)

──────────────────────────────────────────────────────────────

SCHICHT 4 — SEMANTIC LAYER:

  Tool:        Power BI (Dataset: "Umsatz KMU v4")

  Workspace:   Produktion / Controlling

  Measure:     [Umsatz Netto] = SUM(Fact_Umsatz[Betrag_Netto])

  RLS:         Aktiv — Vertriebsregion = USERPRINCIPALNAME()

  Refresh:     Täglich 06:00 (nach ETL-Abschluss)

──────────────────────────────────────────────────────────────

SCHICHT 5 — REPORTS / DASHBOARDS:

  Report 1:    "Monats-Cockpit Vertrieb" → Seite 1, KPI-Card

  Report 2:    "Jahresabschluss-Report" → Seite 3, Tabelle

  Report 3:    "CFO-Dashboard" → Seite 1, Trend-Chart

  Export:      Monatlicher Excel-Export via Power Automate

──────────────────────────────────────────────────────────────

MANUELLE SCHRITTE:   Keine

BEKANNTE ABWEICHUNGEN:

  - ERP-Umsatz weicht von Faktura-Umsatz um ~0,3 % ab (Rundung)

  - Konzernumsatz (konsolidiert) liegt in separatem Prozess

──────────────────────────────────────────────────────────────

ABHÄNGIGE SYSTEME:   Power BI Service, Power Automate, Excel

LETZTE ÄNDERUNG:     2026-02-15 — Währungsumrechnung ergänzt

══════════════════════════════════════════════════════════════

LINEAGE ALS MERMAID-DIAGRAMM (für Git/Wiki):

──────────────────────────────────────────────────────────────

graph LR

  ERP[(ERP: dbo.Belege)] -->|CDC täglich 03:00| STG

  STG[(Staging: stg.Belege_Delta)] -->|ETL Transform| DWH

  DWH[(DWH: Fact_Umsatz)] -->|Power BI Import 06:00| DS

  DS[Dataset: Umsatz KMU v4] -->|RLS aktiv| R1

  DS --> R2

  DS --> R3

  R1[Monats-Cockpit Vertrieb]

  R2[Jahresabschluss-Report]

  R3[CFO-Dashboard]

──────────────────────────────────────────────────────────────

-- Was referenziert Tabelle / View / Procedure X?

-- Gibt alle Objekte zurück, die von einem bestimmten Objekt abhängen

SELECT

    OBJECT_SCHEMA_NAME(d.referencing_id)    AS Referenzierendes_Schema,

    OBJECT_NAME(d.referencing_id)            AS Referenzierendes_Objekt,

    o.type_desc                              AS Objekttyp,

    COALESCE(d.referenced_schema_name, 'dbo') AS Ref_Schema,

    d.referenced_entity_name                 AS Referenziertes_Objekt,

    d.is_caller_dependent

FROM sys.sql_expression_dependencies d

JOIN sys.objects o ON d.referencing_id = o.object_id

WHERE d.referenced_entity_name = 'Fact_Umsatz'  -- Hier Objektname eintragen

  AND OBJECTPROPERTY(d.referencing_id, 'IsMsShipped') = 0

ORDER BY o.type_desc, OBJECT_NAME(d.referencing_id);

-- Rekursive Abhängigkeitskette: vollständige Upstream/Downstream-Ansicht

WITH DepChain AS (

    -- Startknoten

    SELECT

        OBJECT_NAME(d.referencing_id)    AS Quelle,

        d.referenced_entity_name          AS Ziel,

        1                                 AS Tiefe,

        CAST(OBJECT_NAME(d.referencing_id)

             + ' → ' + d.referenced_entity_name

             AS NVARCHAR(MAX))            AS Pfad

    FROM sys.sql_expression_dependencies d

    WHERE d.referenced_entity_name = 'Belege'  -- Startobjekt

    UNION ALL

    SELECT

        OBJECT_NAME(d.referencing_id),

        d.referenced_entity_name,

        dc.Tiefe + 1,

        dc.Pfad + ' → ' + d.referenced_entity_name

    FROM sys.sql_expression_dependencies d

    JOIN DepChain dc

        ON OBJECT_NAME(d.referencing_id) = dc.Ziel

    WHERE dc.Tiefe < 10   -- Maximaltiefe, verhindert Endlosrekursion

)

SELECT DISTINCT Quelle, Ziel, Tiefe, Pfad

FROM DepChain

ORDER BY Tiefe, Quelle;

-- Zirkuläre Referenzen zwischen Datenbankobjekten aufdecken

SELECT

    OBJECT_NAME(d1.referencing_id)   AS Objekt_A,

    d1.referenced_entity_name         AS Objekt_B,

    OBJECT_NAME(d2.referencing_id)   AS Objekt_B_Verify,

    d2.referenced_entity_name         AS Rueck_zu_A

FROM sys.sql_expression_dependencies d1

JOIN sys.sql_expression_dependencies d2

    ON  d1.referenced_entity_name

        = OBJECT_NAME(d2.referencing_id)

   AND  d2.referenced_entity_name

        = OBJECT_NAME(d1.referencing_id)

WHERE OBJECT_NAME(d1.referencing_id) IS NOT NULL

  AND OBJECTPROPERTY(d1.referencing_id,  'IsMsShipped') = 0

  AND OBJECTPROPERTY(d2.referencing_id,  'IsMsShipped') = 0;

-- Alle Objekte die DIREKT von einer Tabelle/Spalte abhängen

-- Ausführen BEVOR eine DDL-Änderung an der Quelltabelle

SELECT

    ref.name                              AS Betroffenes_Objekt,

    ref.type_desc                         AS Objekttyp,

    ref.create_date                       AS Erstellt_am,

    ref.modify_date                       AS Zuletzt_geaendert,

    SCHEMA_NAME(ref.schema_id)            AS Schema_Name,

    -- Letzter Aufruf aus Query-Stats (falls vorhanden):

    qs.last_execution_time                AS Zuletzt_ausgefuehrt

FROM sys.sql_expression_dependencies dep

JOIN sys.objects ref

    ON dep.referencing_id = ref.object_id

LEFT JOIN sys.dm_exec_procedure_stats qs

    ON ref.object_id = qs.object_id

WHERE dep.referenced_entity_name = 'Belege'  -- Zu ändernde Tabelle

  AND OBJECTPROPERTY(dep.referencing_id, 'IsMsShipped') = 0

ORDER BY ref.type_desc, ref.name;

-- Alle Views mit ihrer vollständigen Spalten-Herkunft

SELECT

    v.name                                  AS View_Name,

    SCHEMA_NAME(v.schema_id)                AS Schema_Name,

    c.name                                  AS Spalten_Name,

    c.column_id,

    TYPE_NAME(c.user_type_id)               AS Datentyp,

    c.max_length,

    c.is_nullable,

    -- Herkunft der Spalte:

    COALESCE(

        COL_NAME(dep.referenced_major_id,

                 dep.referenced_minor_id), '—') AS Quell_Spalte,

    OBJECT_NAME(dep.referenced_major_id)    AS Quell_Tabelle

FROM sys.views v

JOIN sys.columns c

    ON v.object_id = c.object_id

LEFT JOIN sys.sql_dependencies dep

    ON  v.object_id = dep.object_id

   AND  c.column_id = dep.column_id

WHERE SCHEMA_NAME(v.schema_id) <> 'sys'

ORDER BY v.name, c.column_id;

-- Welche Tabellen liest/schreibt welche Stored Procedure?

SELECT

    OBJECT_NAME(d.referencing_id)           AS Prozedur,

    d.referenced_entity_name                 AS Tabelle_oder_View,

    o_ref.type_desc                          AS Ref_Objekttyp,

    -- Zugriffsmuster aus Query-Plänen (approximativ):

    SUM(qs.total_logical_reads)              AS Reads_Gesamt,

    SUM(qs.total_logical_writes)             AS Writes_Gesamt,

    MAX(qs.last_execution_time)              AS Zuletzt_ausgefuehrt

FROM sys.sql_expression_dependencies d

JOIN sys.objects o

    ON d.referencing_id = o.object_id

   AND o.type = 'P'  -- Nur Stored Procedures

LEFT JOIN sys.objects o_ref

    ON d.referenced_entity_name = o_ref.name

LEFT JOIN sys.dm_exec_procedure_stats qs

    ON o.object_id = qs.object_id

WHERE OBJECTPROPERTY(d.referencing_id, 'IsMsShipped') = 0

GROUP BY OBJECT_NAME(d.referencing_id),

         d.referenced_entity_name,

         o_ref.type_desc

ORDER BY Prozedur, Tabelle_oder_View;

-- Objekte, auf die kein anderes Objekt mehr verweist

-- (Kandidaten für Bereinigung oder fehlende Dokumentation)

SELECT

    SCHEMA_NAME(o.schema_id)    AS Schema_Name,

    o.name                       AS Objekt_Name,

    o.type_desc                  AS Objekttyp,

    o.create_date                AS Erstellt_am,

    o.modify_date                AS Zuletzt_geaendert

FROM sys.objects o

WHERE o.type IN ('V','P','FN','IF','TF')  -- Views, Procs, Functions

  AND OBJECTPROPERTY(o.object_id, 'IsMsShipped') = 0

  AND NOT EXISTS (

      SELECT 1

      FROM sys.sql_expression_dependencies d

      WHERE d.referenced_entity_name = o.name

  )

  AND NOT EXISTS (

      SELECT 1

      FROM sys.sql_expression_dependencies d2

      WHERE d2.referencing_id = o.object_id

  )

ORDER BY o.type_desc, o.name;

# Python: Power BI Dataset-Abhängigkeiten über XMLA auslesen

# Bibliothek: msal + requests (pip install msal requests)

import requests, msal

TENANT_ID    = "your-tenant-id"

CLIENT_ID    = "your-app-id"       # Azure AD App mit Power BI Leserechten

CLIENT_SECRET = "your-secret"

WORKSPACE_ID  = "your-workspace-id"

# Token holen

app = msal.ConfidentialClientApplication(

    CLIENT_ID,

    authority=f"https://login.microsoftonline.com/{TENANT_ID}",

    client_credential=CLIENT_SECRET

)

token = app.acquire_token_for_client(

    scopes=["https://analysis.windows.net/powerbi/api/.default"]

)

# Alle Datasets im Workspace mit Datenquellen abrufen

headers = {"Authorization": f"Bearer {token['access_token']}"}

# Datasets auflesen

datasets_url = (

    f"https://api.powerbi.com/v1.0/myorg/groups/"

    f"{WORKSPACE_ID}/datasets"

)

datasets = requests.get(datasets_url, headers=headers).json()

# Je Dataset: Datenquellen (Lineage Upstream) ermitteln

for ds in datasets.get("value", []):

    ds_id = ds["id"]

    src_url = (

        f"https://api.powerbi.com/v1.0/myorg/groups/"

        f"{WORKSPACE_ID}/datasets/{ds_id}/datasources"

    )

    sources = requests.get(src_url, headers=headers).json()

    print(f"\nDataset: {ds['name']}")

    for src in sources.get("value", []):

        print(f"  Quelle: {src.get('datasourceType')} — "

              f"{src.get('connectionDetails', {})}")

ZERTIFIZIERUNGSANFORDERUNGEN (Best Practice für KMU):

──────────────────────────────────────────────────────────────

Voraussetzungen für "Certified":

■ Vollständige Lineage-Dokumentation vorhanden (Kapitel 3 Vorlage)

■ Datenquelle und Refresh-Zeitplan dokumentiert

■ Data Owner und technischer Owner benannt

■ KPI-Definitionen im Business Glossar verankert

■ Row-Level Security geprüft und dokumentiert

■ Letzter vollständiger Test nicht älter als 3 Monate

──────────────────────────────────────────────────────────────

EMPFOHLENE dbt-VERZEICHNISSTRUKTUR:

──────────────────────────────────────────────────────────────

models/

├── staging/          ← Schicht 2: Rohdaten bereinigt

│   ├── stg_erp__belege.sql

│   ├── stg_crm__kunden.sql

│   └── schema.yml    ← Dokumentation + Tests

│

├── intermediate/     ← Schicht 3a: Zwischenberechnungen

│   ├── int_umsatz_bereinigt.sql

│   └── schema.yml

│

├── marts/            ← Schicht 3b: Business-ready

│   ├── finance/

│   │   ├── fact_umsatz.sql

│   │   ├── dim_kunde.sql

│   │   └── schema.yml

│   └── sales/

│       └── ...

│

tests/                ← Eigene Datentests

seeds/                ← Referenzdaten (CSV → DB-Tabelle)

macros/               ← Wiederverwendbare SQL-Makros

──────────────────────────────────────────────────────────────

-- models/marts/finance/fact_umsatz.sql

{{

  config(

    materialized = 'incremental',

    unique_key   = 'umsatz_id',

    on_schema_change = 'fail'   -- Schemaänderung erfordert explizite Migration

  )

}}

WITH belege AS (

    SELECT * FROM {{ ref('stg_erp__belege') }}

    WHERE belegart IN ('RE', 'GS', 'ST')

      AND storniert = FALSE

),

kunden AS (

    SELECT * FROM {{ ref('dim_kunde') }}

),

final AS (

    SELECT

        {{ dbt_utils.surrogate_key(['b.beleg_nr', 'b.beleg_datum']) }}

                                   AS umsatz_id,

        b.beleg_datum              AS buchungsdatum,

        b.kunden_id,

        k.kunde_name,

        k.region,

        b.betrag_netto             AS umsatz_eur,

        b.waehrung,

        CURRENT_TIMESTAMP          AS dbt_updated_at

    FROM belege b

    LEFT JOIN kunden k USING (kunden_id)

)

SELECT * FROM final

{% if is_incremental() %}

WHERE buchungsdatum > (SELECT MAX(buchungsdatum) FROM {{ this }})

{% endif %}

# models/marts/finance/schema.yml — Inline-Dokumentation

models:

  - name: fact_umsatz

    description: >

      Faktentabelle: alle fakturierten Umsätze, netto, in EUR.

      Stornos sind als negative Einträge enthalten.

      Buchungsdatum = Rechnungsdatum (nicht Zahlungs- oder Lieferdatum).

    meta:

      owner: controlling@firma.de

      data_source: ERP (MACH MBS)

      refresh: täglich 03:00 Uhr

    tests:

      - dbt_utils.equal_rowcount:

          compare_model: ref('stg_erp__belege')

    columns:

      - name: umsatz_id

        description: Surrogate Key (Beleg-Nr + Datum)

        tests: [unique, not_null]

      - name: umsatz_eur

        description: Nettobetrag in EUR nach Währungsumrechnung

        tests: [not_null]

      - name: kunden_id

        description: Fremdschlüssel auf dim_kunde

        tests:

          - not_null

          - relationships:

              to: ref('dim_kunde')

              field: kunden_id

# Lineage-Graph und Dokumentation generieren:

dbt docs generate

# Lokale Dokumentationsseite starten (Port 8080):

dbt docs serve

# Im Browser: vollständiger Lineage-Graph, Modell-Beschreibungen,

# Spalten-Dokumentation, Testergebnisse — alles auf einer Seite.

# Für den dauerhaften Betrieb: dbt-Docs auf internem Webserver

# oder in dbt Cloud hosten (ab 50 $/Monat für Teams).

Automatische Lineage

★★★★★ (Azure-Stack)

★★★★ (SQL, dbt, Airflow)

★★★★★ (SQL-Modelle)

★★★★

Power BI Integration

★★★★★ nativ

★★★

★★★ (Metadaten)

★★★★

SQL Server Integration

★★★★★

★★★★★

★★★★★

★★★★

Manuelle Lineage ergänzen

★★★

★★★★

★★

★★★★★

Business Glossar

★★★★★

★★★★

★★ (via docs)

★★★★★

DSGVO / PII-Tagging

★★★★★

★★★

★★

★★★★

Einstiegskosten (KMU)

~50–200 €/Monat

Infrastruktur

Kostenlos

Ab 500 $/Monat

Betriebsaufwand

Niedrig (SaaS)

Mittel (Self-hosted)

Niedrig

Niedrig (SaaS)

Empfehlung für KMU

Microsoft-Stack

IT-affine Teams

Alle mit SQL/dbt

Budget vorhanden

EMPFOHLENER LINEAGE-STACK FÜR KMU (2026):

══════════════════════════════════════════════════════════════

STUFE 1 — Minimal (0 € Zusatzkosten):

  ■ Manuelle Lineage-Dokumentation nach Vorlage (Kapitel 3)

  ■ SQL-Diagnose-Toolkit aus Kapitel 4 (ad hoc)

  ■ Power BI eingebaute Lineage-Ansicht (im Service kostenlos)

STUFE 2 — Automatisiert (SQL Server + Power BI):

  ■ Power BI Lineage-Ansicht + Endorsement

  ■ Microsoft Purview (ab ~50 €/Monat für kleinen Scan-Scope)

  ■ dbt Core für Transformations-Layer (kostenlos)

STUFE 3 — Enterprise-grade:

  ■ Purview als zentrales Lineage-Hub (alle Systeme gescannt)

  ■ dbt Cloud für Team-Kollaboration und CI/CD

  ■ OpenMetadata als Datenkatalog-Frontend (optional)

══════════════════════════════════════════════════════════════

IMPACT-ANALYSIS-CHECKLISTE VOR JEDER ÄNDERUNG:

══════════════════════════════════════════════════════════════

SCHRITT 1: Betroffenes Objekt identifizieren

  → Tabelle / View / Spalte / ETL-Job / Dataset

SCHRITT 2: SQL-Diagnose-Toolkit ausführen (Kapitel 4)

  → DMV 4: Direkte Abhängigkeiten

  → DMV 2: Vollständige rekursive Abhängigkeitskette

  → Ergebnis: Liste aller betroffenen Objekte je Schicht

SCHRITT 3: Power BI Lineage-Ansicht prüfen (Kapitel 5)

  → Welche Datasets nutzen die betroffene Datenquelle?

  → Welche Reports nutzen diese Datasets?

SCHRITT 4: Lineage-Dokumentation abgleichen (Kapitel 3)

  → Stimmen die automatisch gefundenen Abhängigkeiten mit

    der Dokumentation überein? Abweichungen dokumentieren.

SCHRITT 5: Betroffene Owner benachrichtigen

  → Je Schicht: Owner der abhängigen Objekte informieren

  → Abnahmeplan: Wer testet nach der Änderung was?

SCHRITT 6: Test-Deployment auf Nicht-Produktionsumgebung

  → Änderung auf Test einspielen

  → Alle dokumentierten Testfälle der Abhängigkeiten prüfen

SCHRITT 7: Produktions-Deployment + sofortiger Smoke-Test

  → Alle kritischen Downstream-Reports nach Änderung prüfen

══════════════════════════════════════════════════════════════

-- Automatisierter Impact-Report: alle Objekte downstream einer Tabelle

-- Mit Kontaktinformationen aus einer Owner-Mapping-Tabelle

SELECT

    dep_chain.Tiefe,

    dep_chain.Ziel                          AS Betroffenes_Objekt,

    o.type_desc                              AS Objekttyp,

    own.owner_email                          AS Owner_Email,

    own.owner_name                           AS Owner_Name,

    o.modify_date                            AS Zuletzt_geaendert,

    qs.last_execution_time                   AS Zuletzt_ausgefuehrt

FROM (

    -- Rekursive Kette aus DMV 2 (vereinfacht):

    SELECT referenced_entity_name AS Ziel, 1 AS Tiefe

    FROM sys.sql_expression_dependencies

    WHERE referenced_entity_name = 'Belege'  -- Zu ändernde Tabelle

) dep_chain

JOIN sys.objects o

    ON dep_chain.Ziel = o.name

LEFT JOIN dbo.Lineage_Owner_Mapping own  -- Eigene Mapping-Tabelle

    ON dep_chain.Ziel = own.object_name

LEFT JOIN sys.dm_exec_procedure_stats qs

    ON o.object_id = qs.object_id

ORDER BY dep_chain.Tiefe, dep_chain.Ziel;

**Lineage Owner**

Fachliche Verantwortung für eine Datenpipeline — stellt sicher, dass das Lineage-Dokument aktuell ist

1–2 Std./Quartal je Pipeline

**Lineage Steward**

Technische Pflege — aktualisiert Dokumente bei Pipeline-Änderungen, führt SQL-Diagnose-Skripte aus

Bei jeder Pipeline-Änderung

**Lineage Admin**

Verwaltet Tool-Konfiguration (Purview/OpenMetadata), koordiniert Scan-Zyklen, moderiert Quarterly Review

2–4 Std./Monat

PFLEGE-TRIGGER FÜR LINEAGE-DOKUMENTE:

──────────────────────────────────────────────────────────────

TRIGGER: DDL-Änderung an Quelltabelle

  → Sofortige Benachrichtigung des Lineage Steward

  → Lineage-Dokument innerhalb von 5 Arbeitstagen aktualisieren

  → Impact-Analyse ausführen und dokumentieren

TRIGGER: ETL-Job-Änderung (Deployment)

  → Deployment-Pipeline triggert Lineage-Dokument-Review

  → In dbt: automatisch durch schema.yml-Änderung

TRIGGER: Neues Power BI Dataset / Report

  → Vor Veröffentlichung: Lineage-Dokument als Pflichtbedingung

  → Endorsement (Promoted) nur mit vollständiger Lineage

TRIGGER: ERP-Versionsupdate

  → Vor Update: Impact-Analyse für alle ERP-nahen Lineage-Dokumente

  → Nach Update: Regressionstest aller Downstream-Objekte

TRIGGER: Jährlicher Audit (Data Council)

  → Alle Lineage-Dokumente auf Aktualität prüfen

  → Verwaiste Objekte aus DMV 7 bereinigen

──────────────────────────────────────────────────────────────

-- DDL-Trigger: Benachrichtigung bei Schemaänderungen an überwachten Tabellen

CREATE OR ALTER TRIGGER trg_Schema_Change_Alert

ON DATABASE

FOR ALTER_TABLE, DROP_TABLE, RENAME

AS

BEGIN

    SET NOCOUNT ON;

    DECLARE @EventData XML = EVENTDATA();

    DECLARE @ObjName  NVARCHAR(256) =

        @EventData.value('(/EVENT_INSTANCE/ObjectName)[1]', 'NVARCHAR(256)');

    DECLARE @EventType NVARCHAR(100) =

        @EventData.value('(/EVENT_INSTANCE/EventType)[1]', 'NVARCHAR(100)');

    DECLARE @LoginName NVARCHAR(256) =

        @EventData.value('(/EVENT_INSTANCE/LoginName)[1]', 'NVARCHAR(256)');

    -- Nur überwachte Tabellen auslösen:

    IF @ObjName IN ('Belege', 'Kunden', 'Artikel', 'Bestellungen')

    BEGIN

        -- Ereignis in Audit-Log schreiben:

        INSERT INTO dbo.Schema_Change_Log

            (ChangeDate, ObjectName, EventType, LoginName, EventData)

        VALUES

            (GETDATE(), @ObjName, @EventType, @LoginName, @EventData);

        -- E-Mail-Benachrichtigung (erfordert Database Mail):

        EXEC msdb.dbo.sp_send_dbmail

            @profile_name = 'DBA-Alerts',

            @recipients   = 'lineage-owner@firma.de',

            @subject      = 'LINEAGE ALERT: Schemaänderung an ' + @ObjName,

            @body         = 'Tabelle ' + @ObjName

                          + ' wurde durch ' + @LoginName

                          + ' geändert (' + @EventType + ').'

                          + CHAR(13) + 'Bitte Lineage-Dokument prüfen.';

    END

END;

VOR DEM START

Identifizieren Sie die drei kritischsten Datenpipelines Ihres Unternehmens — diejenigen, bei denen falsche oder unvollständige Daten die größten Geschäftsauswirkungen hätten. Diese drei Pipelines werden im 30-Tage-Plan vollständig dokumentiert. Alle anderen folgen danach nach demselben Muster.

ERGEBNIS NACH 30 TAGEN

Ihr Ergebnis nach 30 Tagen: Drei vollständig dokumentierte, End-to-End-Datenpipelines mit Lineage-Vorlagen, automatischer Schemaänderungs-Benachrichtigung, validiertem Power-BI-Lineage-Graph, Impact-Analyse-Workflow und einem Governance-Modell, das Lineage dauerhaft aktuell hält — als Basis für alle weiteren Pipelines.

Lineage-Quickstart

Strukturierter 2-Tages-Workshop: Systemkartierung, SQL-Abhängigkeitsanalyse, vollständige Lineage-Dokumentation Ihrer kritischsten Datenpipeline und Einrichtung des Governance-Modells.

Data Architecture Review

Vollständige Analyse Ihrer Datenpipelines: Lineage-Lücken, Impact-Risiken, manuelle Zwischenschritte, Tool-Empfehlung und priorisierter Dokumentationsplan. Scope: 2–3 Tage.

dbt-Einführung

Einführung von dbt Core in Ihre SQL-Transformationsumgebung — Projektstruktur, Modellierung, Dokumentation, Tests und Lineage-Graph. Scope: 3–5 Tage.

Data Governance Quickstart

Governance-Rollen, KPI-Glossar, DSGVO-Check und Data-Council-Prozess — in 3 Tagen einsatzbereit.

SQL Server DB Health Check

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