Xenosystems Logo
Sascha Hess

Diplom-Biologe | Senior IT-Consultant

SH

Sascha Hess

xenosystems.de - IT-Consulting & Data Management

www.xenosystems.de

 

 

NOTFALL-KIT – SQL SERVER 2026

 

SQL Server

 

BI & Governance

 

Metadatenmanagement

 

Datenkataloge aufbauen, Metadaten pflegen, Transparenz schaffen — im Mittelstand

WAS SIE IN DIESEM KIT ERHALTEN:

 

1

Metadaten-Taxonomie

Technische, Business- und Operational-Metadaten — was gehört wo hin

 

 

2

10 Katalog-Fallen

Warum Datenkatalog-Projekte scheitern — und wie es gelingt

 

 

3

Datenkatalog ohne Enterprise-Tool

Vollständiger Katalog in SQL Server, dbt und Power BI — kostenlos

 

 

4

Datenlineage praktisch

Herkunft und Auswirkung jedes Feldes automatisch nachverfolgen

 

 

5

30-Tage-Katalog-Bootstrapplan

Vom leeren Feld zur gepflegten, durchsuchbaren Metadaten-Bibliothek

 


 

 

Rechtliche Hinweise und Haftungsausschluss

 

HAFTUNGSAUSSCHLUSS

 

Alle Skripte, Konzepte und Empfehlungen wurden sorgfältig erarbeitet. Da jede Systemlandschaft individuell ist, übernimmt der Autor keinerlei Haftung für Datenverlust, fehlerhafte Metadaten oder Compliance-Verstöße. Metadaten-Management berührt Kerndaten der Unternehmensarchitektur — testen Sie alle Skripte in einer Nicht-Produktionsumgebung.

 

KEIN ERSATZ FÜR RECHTSBERATUNG

 

Dieses Kit liefert Orientierung zu DSGVO-Anforderungen an Datenkataloge und -verzeichnisse. Es ersetzt keine rechtliche Beratung. Klären Sie konkrete Compliance-Anforderungen mit Ihrem Datenschutzbeauftragten.

 

VERSIONSHINWEIS

 

Die Inhalte beziehen sich auf SQL Server 2022/2025, Azure Purview, dbt Core 1.8+ und Power BI, Stand März 2026.

 

URHEBERRECHT

 

Dieses Dokument ist für den persönlichen oder betriebsinternen Gebrauch des Käufers lizenziert. Weiterverkauf, Weitergabe an Dritte und öffentliche Veröffentlichung sind ohne schriftliche Genehmigung nicht gestattet.

 

Eine ausführliche Version dieses Haftungsausschlusses befindet sich am Ende dieses Dokuments.

 


 

 

Inhaltsverzeichnis

 

 

01  Einleitung

Warum niemand weiß was die Daten bedeuten — und was das kostet

 

02  Metadaten-Taxonomie

Technisch, Business, Operational — die drei Metadaten-Klassen

 

03  Die 10 Katalog-Fallen

Typische Fehler bei Datenkatalog-Projekten — mit Gegenmethoden

 

04  Datenkatalog in SQL Server

Vollständiger Katalog ohne Enterprise-Tool — sofort einsetzbar

 

05  Automatische Metadaten-Extraktion

Schema, Statistiken und Nutzungsdaten aus SQL Server ziehen

 

06  Business-Glossar

KPI-Definitionen, Fachbegriffe und Data Dictionary pflegen

 

07  Datenlineage praktisch

Herkunft und Auswirkung von Feldern nachverfolgen

 

08  dbt als Katalog-Fundament

Dokumentation, Tests und Lineage als Nebenprodukt

 

09  Azure Purview für KMU

Wann das Enterprise-Tool sich lohnt — und wann nicht

 

10  30-Tage-Katalog-Bootstrapplan

Vom leeren Feld zur gepflegten Metadaten-Bibliothek

 

 


 

 

01

Einleitung

 

Warum niemand weiß was die Daten bedeuten — und was das kostet

 

In fast jedem mittelständischen Unternehmen gibt es eine Variante dieser Szene: Ein Controller öffnet einen Power-BI-Bericht und fragt seinen Kollegen: "Was bedeutet eigentlich die Spalte 'DB2' hier?" Der Kollege zuckt die Achseln: "Ich glaube Deckungsbeitrag 2, aber ich bin mir nicht sicher." Ein dritter Kollege ergänzt: "In meinem Bericht heißt die gleiche Kennzahl 'Contribution Margin' — aber ich glaube, da wird anders gerechnet."

 

Dieser Zustand — verschiedene Definitionen für dieselbe Kennzahl, niemand weiß woher die Daten kommen, Felder ohne Erklärung in Dutzenden von Tabellen — ist das Kernproblem, das Datenkataloge und Metadatenmanagement lösen.

 

Ein Datenkatalog ist ein geordnetes Verzeichnis aller Datenobjekte eines Unternehmens — Tabellen, Felder, Reports, KPIs, ETL-Prozesse — angereichert mit Metadaten: Was bedeutet dieses Feld? Wer ist verantwortlich? Woher kommt der Wert? Wie wird er berechnet? Wie aktuell ist er?

 

Ohne Datenkatalog zahlen Unternehmen täglich einen unsichtbaren Preis:

 

  Analysten verbringen 40–60 % ihrer Zeit damit, Daten zu suchen und zu verstehen statt sie zu analysieren.

 

  Dieselbe Kennzahl wird in verschiedenen Berichten unterschiedlich berechnet — niemand bemerkt es, bis Zahlen verglichen werden.

 

  Nach einem ERP-Update oder Schemaänderung bricht ein Bericht — niemand weiß, welche anderen Berichte noch betroffen sind.

 

  Die DSGVO verlangt ein Verzeichnis aller Verarbeitungstätigkeiten — ohne Datenkatalog ist das kaum erfüllbar.

 

Dieses Kit zeigt, wie ein funktionsfähiger Datenkatalog im KMU aufgebaut wird — ohne Collibra, ohne Informatica Catalog, ohne sechs Monate Implementierungsprojekt. Mit SQL Server, dbt und Power BI ist ein produktionstauglicher Katalog in 30 Tagen aufgebaut.

 

 

DREI SIGNALE DASS EIN DATENKATALOG FEHLT

  Derselbe Begriff bedeutet in verschiedenen Abteilungen verschiedene Dinge — und niemand hat das offiziell definiert.

  Wenn jemand das Unternehmen verlässt, ist unklar ob er "Wissen über Daten" mitgenommen hat.

  Eine Schemaänderung in der Datenbank hat unbeabsichtigte Auswirkungen auf Berichte entdeckt — zu spät.

 


 

 

02

Metadaten-Taxonomie

 

Technisch, Business, Operational — die drei Metadaten-Klassen

 

Metadaten sind "Daten über Daten". Aber nicht alle Metadaten sind gleich — sie haben unterschiedliche Quellen, Zielgruppen und Pflegeverantwortlichkeiten.

 

2.1 Technische Metadaten — automatisch aus dem System extrahierbar

 

Technische Metadaten beschreiben die physische Struktur der Daten: Schemas, Tabellen, Spalten, Datentypen, Indizes, Constraints, Partitionen, Speichergrößen.

 

  Quelle: Direkt aus dem Datenbanksystem — sys.tables, sys.columns, INFORMATION_SCHEMA, DMVs.

 

  Pflegeverantwortung: Datenbank-Administrator, Data Engineer.

 

  Automatisierbar: Vollständig — kein manueller Pflegeaufwand.

 

Beispiele: Tabellenname, Spaltenname, Datentyp, Nullable, Index-Coverage, Speichergröße, Zeilenanzahl, letztes Änderungsdatum.

 

2.2 Business-Metadaten — manuell gepflegt, höchster Wert

 

Business-Metadaten beschreiben die fachliche Bedeutung: Was bedeutet dieses Feld? Wie wird diese KPI berechnet? Welche Geschäftsregel liegt hinter dieser Transformation?

 

  Quelle: Fachexperten, Controlling, Data Stewards — nicht das Datenbanksystem.

 

  Pflegeverantwortung: Business-Glossar-Owner, Data Stewards je Domäne.

 

  Automatisierbar: Nicht — erfordert menschliche Expertise und Pflege.

 

Beispiele: Feldbezeichnung auf Deutsch, KPI-Definition, Berechnungsformel, Datenowner, Vertraulichkeitsklasse, DSGVO-Relevanz, Beispielwerte, Häufige Missverständnisse.

 

2.3 Operational-Metadaten — aus ETL-Protokollen und Monitoring

 

Operational-Metadaten beschreiben den Betriebszustand der Daten: Wann wurden sie zuletzt geladen? Wie viele Zeilen? Gab es Fehler? Wie aktuell sind sie?

 

  Quelle: ETL-Protokolle, SQL Agent Job History, Datenbank-Statistiken.

 

  Pflegeverantwortung: Data Engineer, IT-Betrieb.

 

  Automatisierbar: Weitgehend — aus vorhandenen Monitoring-Tabellen.

 

Beispiele: Letztes Ladedatum, Anzahl geladener Zeilen, ETL-Laufzeit, Fehlerquote, Freshness-Status, SLA-Einhaltung.

 

2.4 Die Metadaten-Matrix

 

Metadaten-Klasse

Wer pflegt

Wer nutzt

Tool

Aktualisierung

Technisch

DBA / Data Engineer

Entwickler, Analysten

SQL Server sys-Views

Automatisch bei Schemaänderung

Business

Data Steward / Fachbereich

Analysten, Controller, neue Mitarbeiter

Katalog-Datenbank, dbt, Confluence

Manuell bei Änderung

Operational

ETL-Monitoring

DBA, Data Engineer, SLA-Verantwortliche

ETL-Protokoll, Monitoring-Dashboard

Automatisch je ETL-Lauf

 


 

 

03

Die 10 Katalog-Fallen

 

Typische Fehler bei Datenkatalog-Projekten — mit Gegenmethoden

 

01 Den Katalog vollständig füllen wollen, bevor er genutzt wird

 

Das Team dokumentiert sechs Monate lang alle 2.000 Tabellen und 40.000 Felder, bevor der Katalog für Nutzer freigegeben wird. Am Tag der Freigabe ist ein Drittel der Informationen veraltet. Die Motivation des Teams ist erschöpft. Die Nutzer finden die Arbeit beeindruckend — und nutzen den Katalog trotzdem nicht.

 

LÖSUNG:

 

  Katalog frühzeitig mit wenigen, gut gepflegten Einträgen öffnen — "better done than perfect."

  Die 20 meistgefragten Tabellen zuerst vollständig dokumentieren — das sind meistens 80 % des Nutzungsbedarfs.

  Nutzer werden eingeladen, Ergänzungen beizutragen — Crowdsourcing statt Vollständigkeitsanspruch.

 

02 Technische Metadaten mit Business-Metadaten verwechseln

 

Der Katalog enthält für jede Spalte den Datentyp, die Nullable-Information und den technischen Feldnamen — aber keine Erklärung was das Feld bedeutet. Ein Analyst sieht "NVARCHAR(20), NOT NULL, Column: KL_STD" und weiß immer noch nicht, dass das die Kundenstandardlieferzeit in Werktagen ist.

 

LÖSUNG:

 

  Technische Metadaten sind automatisch — Business-Metadaten sind das eigentliche Produkt.

  Mindestanforderung je Katalogeintrag: deutschsprachige Bezeichnung + ein Satz Erklärung + Beispielwert.

  Priorität: Felder in Reports und Dashboards zuerst — da ist der Nutzen sofort spürbar.

 

03 Kein Data Owner je Eintrag

 

Der Katalog hat 500 Einträge — keiner hat einen namentlich benannten Owner. Wenn ein Analyst eine Frage hat, wohin fragt er? Wenn die Definition falsch ist, wer korrigiert sie? Nach sechs Monaten ist der Katalog voller Fragen, die niemand beantwortet hat — und veralteter Einträge, die niemand aktualisiert hat.

 

LÖSUNG:

 

  Jeder Katalogeintrag hat einen namentlich benannten Owner — mit echtem Zeitbudget.

  Für Tabellengruppen (z.B. alle Kunden-Tabellen): ein Steward, nicht ein Steward je Tabelle.

  Owner-Zuweisung vor der Katalogeröffnung — nicht als nachträglicher Schritt.

 

04 Katalog und Realität divergieren sofort

 

Am Tag der Eröffnung stimmt der Katalog. Drei Monate später hat jemand eine Spalte umbenannt, eine Tabelle hinzugefügt und eine KPI-Definition geändert — nichts davon steht im Katalog. Der Katalog ist vertrauenswürdiger als die Realität — er beschreibt eine Welt, die nicht mehr existiert.

 

LÖSUNG:

 

  Schemaänderungen lösen automatisch einen Katalog-Update-Alert aus (Kapitel 5).

  KPI-Definitionen ändern sich nur mit Katalog-Update — nicht umgekehrt.

  Vierteljährliches Review: alle Einträge werden auf Aktualität geprüft.

 

05 Zu viele Felder im Katalog pflegen — Overengineering

 

Jede Tabelle soll 25 Metadaten-Felder haben: technische Beschreibung, fachliche Beschreibung, historische Beschreibung, Datenqualitätsscore, Vertraulichkeitsklasse, DSGVO-Grundlage, Aufbewahrungsfrist, Löschkonzept, SLA, Owner, Stellvertreter, Ersetzt-durch, Verwandt-mit... Der Pflegeaufwand ist so hoch, dass nichts gepflegt wird.

 

LÖSUNG:

 

  Start mit fünf Pflichtfeldern: Bezeichnung, Beschreibung, Owner, Letzte Prüfung, Vertraulichkeit.

  Weitere Felder optional — werden bei Bedarf ergänzt, sind aber kein Freigabekriterium.

  Faustregel: Wenn ein Feld nicht von mindestens 10 % der Nutzer gelesen wird, ist es kein Pflichtfeld.

 

06 Katalog als separates System ohne Integration

 

Der Datenkatalog lebt in einem SharePoint-Excel. Die Berichte leben in Power BI. Die Transformationen leben in dbt. Der Analyst muss zwischen drei Systemen hin- und herspringen, um eine Frage zu beantworten. Der Katalog wird zugunsten von "schneller selbst suchen" ignoriert.

 

LÖSUNG:

 

  Katalog-Metadaten dort anzeigen, wo Nutzer arbeiten: in Power BI als Feldbezeichnung, in dbt als Modelldokumentation, in SSMS als Extended Properties.

  Extended Properties in SQL Server: Beschreibungen direkt an Tabellen und Spalten im System hinterlegen.

  dbt docs: automatisch generierte Dokumentations-Website aus Katalog-YAML-Dateien.

 

07 Lineage nur für neue Objekte dokumentieren

 

Alle neuen Tabellen und Views werden mit Lineage-Dokumentation erstellt. Die 300 bestehenden Tabellen ohne Lineage bleiben unberührt. In drei Jahren gibt es eine gut dokumentierte neue Schicht auf einem undurchsichtigen Legacy-Fundament.

 

LÖSUNG:

 

  Legacy-Lineage rückwärts erschließen: sys.sql_expression_dependencies gibt einen guten Startpunkt.

  Top-Down-Ansatz: von den Power-BI-Reports rückwärts alle Abhängigkeiten erschließen.

  Auch unvollständige Lineage ist besser als keine — "Quelle unbekannt" ist ein valider Katalog-Eintrag.

 

08 Glossar und Katalog getrennt pflegen

 

Das Business-Glossar mit KPI-Definitionen liegt in Confluence. Der technische Datenkatalog liegt in einer SQL-Datenbank. Die Verknüpfung zwischen "Deckungsbeitrag I" im Glossar und den Datenbankfeldern die ihn berechnen? Fehlt. Ein Analyst findet die Definition — aber nicht die Daten. Und umgekehrt.

 

LÖSUNG:

 

  Glossar-Einträge und Katalog-Einträge werden verknüpft: jede KPI-Definition referenziert die Felder, aus denen sie berechnet wird.

  Technisch: Fremdschlüssel oder Referenz-URL zwischen Glossar_ID und Katalog_ObjektID.

  Praktisch: dbt macht das implizit — Modell-Dokumentation enthält sowohl Technisches als auch Business-Kontext.

 

09 Kein Self-Service für Nutzer

 

Nur Data Engineers dürfen den Katalog bearbeiten. Analysten können schauen, aber nichts ergänzen. Ein Analyst hat ein Feld besser erklärt als im Katalog — er kann seinen Wissensvorsprung nicht einbringen. Wissen bleibt dezentralisiert.

 

LÖSUNG:

 

  "Suggest an edit"-Funktion: Analysten können Korrekturvorschläge einreichen, Data Steward genehmigt.

  Kommentarfunktion: Fragen und Anmerkungen je Katalogeintrag — ohne Freigabeprozess.

  Community-Beiträge valorisieren: wer gute Beschreibungen beigesteuert hat, wird öffentlich sichtbar.

 

10 Den Katalog starten ohne DSGVO-Anforderungen zu klären

 

Ein Datenkatalog ist nach DSGVO Art. 30 das Verarbeitungsverzeichnis — oder zumindest ein Teil davon. Wenn der Katalog personenbezogene Daten beschreibt (Kundentabellen, Mitarbeiterdaten), unterliegt er selbst dem Datenschutz. Wenn dieser Bezug nicht von Anfang an mitgedacht wird, muss nachträglich alles umgebaut werden.

 

LÖSUNG:

 

  DSGVO-Anforderungen von Anfang an im Katalog-Design berücksichtigen: Vertraulichkeitsklasse, DSGVO-Relevanz, Löschfrist als Pflichtfelder für personenbezogene Daten.

  Datenschutzbeauftragten in den Katalog-Aufbau einbinden.

  Zugriffsbeschränkung: wer sieht welche Katalog-Einträge? Personenbezogene Datenquellen nur für berechtigte Rollen.

 


 

 

04

Datenkatalog in SQL Server

 

Vollständiger Katalog ohne Enterprise-Tool — sofort einsetzbar

 

4.1 Das vollständige Katalog-Schema

 

-- Vollständiger Datenkatalog in SQL Server — kein externes Tool nötig

CREATE SCHEMA katalog;

 

-- Kern-Tabelle: Datenobjekte (Tabellen, Views, Pipelines, Reports, KPIs)

CREATE TABLE katalog.Objekte (

    ObjektID        INT IDENTITY PRIMARY KEY,

    ObjektTyp       NVARCHAR(20) NOT NULL,

    -- TABELLE / VIEW / PIPELINE / REPORT / KPI / SCHEMA / DATENBANK

    Schicht         NVARCHAR(20),

    -- QUELLE / STAGING / CORE / MART / REPORTING

    Schema_Name     NVARCHAR(100),

    Objekt_Name     NVARCHAR(200) NOT NULL,

    Vollname        AS ISNULL(Schema_Name+'.','') + Objekt_Name PERSISTED,

    -- Business-Metadaten (manuell gepflegt)

    Bezeichnung_DE  NVARCHAR(300),   -- deutschsprachiger Anzeigename

    Beschreibung    NVARCHAR(MAX),   -- was enthält dieses Objekt?

    Anwendungsfall  NVARCHAR(500),   -- wozu wird es verwendet?

    Owner_Name      NVARCHAR(100),

    Owner_Email     NVARCHAR(200),

    Stellvertreter  NVARCHAR(100),

    -- Vertraulichkeit und Compliance

    Vertraulichkeit NVARCHAR(20) DEFAULT 'INTERN',

    -- OEFFENTLICH / INTERN / VERTRAULICH / STRENG_VERTRAULICH

    DSGVO_Relevant  BIT DEFAULT 0,

    Loeschfrist_Monate INT,

    -- Technische Metadaten (automatisch befüllt)

    Datenbank_Name  NVARCHAR(100),

    Erstellt_DB_Am  DATETIME2,

    Geaendert_DB_Am DATETIME2,

    Zeilen_Anzahl   BIGINT,

    Groesse_MB      DECIMAL(10,2),

    -- Operational-Metadaten

    Letzte_Ladung   DATETIME2,

    SLA_Beschreibung NVARCHAR(200),

    Freshness_Status NVARCHAR(10),  -- GRUEN / GELB / ROT

    -- Katalog-Pflege

    Katalog_Status  NVARCHAR(20) DEFAULT 'ENTWURF',

    -- ENTWURF / GEPRUEFT / FREIGEGEBEN / VERALTET

    Letzte_Pruefung DATE,

    Naechste_Pruefung DATE,

    Erstellt_Am     DATETIME2 DEFAULT SYSUTCDATETIME(),

    Geaendert_Am    DATETIME2 DEFAULT SYSUTCDATETIME()

);

 

-- Felder-Tabelle: Spaltenebene-Metadaten

CREATE TABLE katalog.Felder (

    FeldID          INT IDENTITY PRIMARY KEY,

    ObjektID        INT NOT NULL REFERENCES katalog.Objekte(ObjektID),

    Spaltenname     NVARCHAR(200) NOT NULL,

    Ordnungsposition INT,

    -- Technisch (automatisch)

    Datentyp        NVARCHAR(50),

    Max_Laenge      INT,

    Ist_Nullable    BIT,

    Ist_Primaerschluessel BIT DEFAULT 0,

    Ist_Fremdschluessel   BIT DEFAULT 0,

    -- Business (manuell)

    Bezeichnung_DE  NVARCHAR(300),

    Beschreibung    NVARCHAR(MAX),

    Beispielwert    NVARCHAR(200),

    Erlaubte_Werte  NVARCHAR(500),  -- z.B. "A, B, C, D" für Klassifizierungsfelder

    Berechnungsformel NVARCHAR(MAX),

    Ist_Sensitiv    BIT DEFAULT 0,  -- personenbezogen?

    -- Katalog-Status

    Katalog_Status  NVARCHAR(20) DEFAULT 'UNDOKUMENTIERT'

);

 

-- Business-Glossar: KPI-Definitionen und Fachbegriffe

CREATE TABLE katalog.Glossar (

    GlossarID       INT IDENTITY PRIMARY KEY,

    Begriff         NVARCHAR(200) NOT NULL UNIQUE,

    Kategorie       NVARCHAR(50),   -- KPI / FACHBEGRIFF / ABKUERZUNG / PROZESS

    Definition      NVARCHAR(MAX) NOT NULL,

    Berechnungsformel NVARCHAR(MAX),

    Einheit         NVARCHAR(50),

    Beispiel        NVARCHAR(500),

    Abgrenzung      NVARCHAR(500),  -- was es NICHT ist

    Owner_Name      NVARCHAR(100),

    Gueltig_Ab      DATE,

    Synonyme        NVARCHAR(500),  -- kommasepariert

    Erstellt_Am     DATETIME2 DEFAULT SYSUTCDATETIME(),

    Geaendert_Am    DATETIME2 DEFAULT SYSUTCDATETIME()

);

 

-- Verknüpfung: Glossar-Begriff → Datenbankfeld(er)

CREATE TABLE katalog.Glossar_Felder (

    GlossarFeldID   INT IDENTITY PRIMARY KEY,

    GlossarID       INT REFERENCES katalog.Glossar(GlossarID),

    FeldID          INT REFERENCES katalog.Felder(FeldID),

    Beziehungstyp   NVARCHAR(50)    -- DIREKT / BERECHNET_AUS / BEEINFLUSST

);

 

-- Lineage: Datenflüsse zwischen Objekten

CREATE TABLE katalog.Lineage (

    LineageID       INT IDENTITY PRIMARY KEY,

    Quelle_ObjektID INT REFERENCES katalog.Objekte(ObjektID),

    Ziel_ObjektID   INT REFERENCES katalog.Objekte(ObjektID),

    Transformationstyp NVARCHAR(50),  -- DIREKT / AGGREGIERT / GEFILTERT / BERECHNET

    Transformationsbeschreibung NVARCHAR(MAX),

    Pipeline_Name   NVARCHAR(200),

    Erstellt_Am     DATETIME2 DEFAULT SYSUTCDATETIME()

);

 

-- Änderungshistorie für alle Katalog-Einträge

CREATE TABLE katalog.Aenderungshistorie (

    HistorieID      INT IDENTITY PRIMARY KEY,

    Tabelle         NVARCHAR(50),

    ObjektID        INT,

    Feldname        NVARCHAR(100),

    AlterWert       NVARCHAR(MAX),

    NeuerWert       NVARCHAR(MAX),

    GeaendertVon    NVARCHAR(100) DEFAULT SUSER_SNAME(),

    GeaendertAm     DATETIME2 DEFAULT SYSUTCDATETIME(),

    Kommentar       NVARCHAR(500)

);

 

 

4.2 Katalog-Suche — die wichtigste Nutzerfunktion

 

-- Volltext-Suche im Datenkatalog

CREATE OR ALTER PROCEDURE katalog.SP_Suche

    @Suchbegriff    NVARCHAR(200),

    @ObjektTyp      NVARCHAR(20) = NULL,   -- Filter optional

    @NurFreigegeben BIT = 1

AS

BEGIN

    SET NOCOUNT ON;

 

    SELECT

        o.ObjektTyp,

        o.Schicht,

        o.Vollname,

        o.Bezeichnung_DE,

        LEFT(o.Beschreibung, 200)   AS Beschreibung_Kurz,

        o.Owner_Name,

        o.Freshness_Status,

        o.Katalog_Status,

        -- Relevanzscore: Treffer im Namen > Treffer in Beschreibung

        CASE

            WHEN o.Objekt_Name LIKE '%' + @Suchbegriff + '%' THEN 100

            WHEN o.Bezeichnung_DE LIKE '%' + @Suchbegriff + '%' THEN 80

            WHEN o.Beschreibung LIKE '%' + @Suchbegriff + '%' THEN 50

            ELSE 0

        END +

        CASE

            WHEN EXISTS (SELECT 1 FROM katalog.Felder f

                WHERE f.ObjektID = o.ObjektID

                AND (f.Spaltenname LIKE '%' + @Suchbegriff + '%'

                  OR f.Bezeichnung_DE LIKE '%' + @Suchbegriff + '%'))

            THEN 30

            ELSE 0

        END                         AS Relevanz

    FROM katalog.Objekte o

    WHERE (

        o.Objekt_Name    LIKE '%' + @Suchbegriff + '%'

     OR o.Bezeichnung_DE LIKE '%' + @Suchbegriff + '%'

     OR o.Beschreibung   LIKE '%' + @Suchbegriff + '%'

     OR EXISTS (

            SELECT 1 FROM katalog.Felder f

            WHERE f.ObjektID = o.ObjektID

            AND (f.Spaltenname  LIKE '%' + @Suchbegriff + '%'

              OR f.Bezeichnung_DE LIKE '%' + @Suchbegriff + '%'

              OR f.Beschreibung   LIKE '%' + @Suchbegriff + '%')

        )

    )

    AND (@ObjektTyp IS NULL OR o.ObjektTyp = @ObjektTyp)

    AND (@NurFreigegeben = 0 OR o.Katalog_Status = 'FREIGEGEBEN')

    ORDER BY Relevanz DESC, o.Objekt_Name;

END

 

-- Beispielaufruf

EXEC katalog.SP_Suche @Suchbegriff = 'Umsatz', @ObjektTyp = 'KPI';

 

 


 

 

05

Automatische Metadaten-Extraktion

 

Schema, Statistiken und Nutzungsdaten aus SQL Server ziehen

 

5.1 Technische Metadaten automatisch aus sys-Views befüllen

 

-- Tägliche Synchronisation: technische Metadaten aus SQL Server → Katalog

CREATE OR ALTER PROCEDURE katalog.SP_Sync_Technische_Metadaten AS

BEGIN

    SET NOCOUNT ON;

 

    -- Neue Tabellen und Views in Katalog aufnehmen

    INSERT INTO katalog.Objekte

        (ObjektTyp, Schema_Name, Objekt_Name, Datenbank_Name,

         Erstellt_DB_Am, Geaendert_DB_Am)

    SELECT

        CASE o.type_desc

            WHEN 'USER_TABLE' THEN 'TABELLE'

            WHEN 'VIEW'       THEN 'VIEW'

            ELSE o.type_desc

        END,

        SCHEMA_NAME(o.schema_id),

        o.name,

        DB_NAME(),

        o.create_date,

        o.modify_date

    FROM sys.objects o

    WHERE o.type IN ('U','V')

      AND NOT EXISTS (

        SELECT 1 FROM katalog.Objekte k

        WHERE k.Schema_Name = SCHEMA_NAME(o.schema_id)

          AND k.Objekt_Name = o.name

          AND k.Datenbank_Name = DB_NAME()

      );

 

    -- Zeilenanzahl und Größe aktualisieren

    UPDATE k SET

        k.Zeilen_Anzahl = p.rows,

        k.Groesse_MB    = ROUND(

            (SUM(a.total_pages) * 8192.0) / 1048576, 2),

        k.Geaendert_Am  = SYSUTCDATETIME()

    FROM katalog.Objekte k

    JOIN sys.objects o

        ON k.Objekt_Name = o.name

        AND k.Schema_Name = SCHEMA_NAME(o.schema_id)

    JOIN sys.indexes i ON o.object_id = i.object_id

    JOIN sys.partitions p ON i.object_id = p.object_id

        AND i.index_id = p.index_id

    JOIN sys.allocation_units a ON p.partition_id = a.container_id

    GROUP BY k.ObjektID, k.Zeilen_Anzahl, k.Groesse_MB, p.rows;

 

    -- Spalten synchronisieren

    MERGE katalog.Felder AS ziel

    USING (

        SELECT

            k.ObjektID,

            c.name                  AS Spaltenname,

            c.column_id             AS Ordnungsposition,

            tp.name                 AS Datentyp,

            c.max_length            AS Max_Laenge,

            c.is_nullable           AS Ist_Nullable,

            CASE WHEN ic.column_id IS NOT NULL THEN 1 ELSE 0 END AS Ist_PK

        FROM katalog.Objekte k

        JOIN sys.objects o ON k.Objekt_Name = o.name

            AND k.Schema_Name = SCHEMA_NAME(o.schema_id)

        JOIN sys.columns c ON o.object_id = c.object_id

        JOIN sys.types tp ON c.user_type_id = tp.user_type_id

        LEFT JOIN sys.index_columns ic

            ON o.object_id = ic.object_id AND c.column_id = ic.column_id

            AND ic.index_id = 1

    ) AS quelle

    ON ziel.ObjektID = quelle.ObjektID AND ziel.Spaltenname = quelle.Spaltenname

    WHEN NOT MATCHED THEN

        INSERT (ObjektID, Spaltenname, Ordnungsposition, Datentyp,

                Max_Laenge, Ist_Nullable, Ist_Primaerschluessel)

        VALUES (quelle.ObjektID, quelle.Spaltenname, quelle.Ordnungsposition,

                quelle.Datentyp, quelle.Max_Laenge, quelle.Ist_Nullable,

                quelle.Ist_PK);

END

 

 

5.2 Extended Properties — Metadaten direkt im Datenbankobjekt

 

-- Extended Properties: Beschreibungen direkt an Tabellen und Spalten hängen

-- Diese erscheinen in SSMS, Azure Data Studio und können von Tools gelesen werden

 

-- Beschreibung zu einer Tabelle hinzufügen

EXEC sys.sp_addextendedproperty

    @name       = 'MS_Description',

    @value      = 'Enthält alle aktiven Kundenbeziehungen aus dem ERP. Historisiert via SCD Typ 2.',

    @level0type = 'SCHEMA', @level0name = 'dwh',

    @level1type = 'TABLE',  @level1name = 'Dim_Kunden';

 

-- Beschreibung zu einer Spalte hinzufügen

EXEC sys.sp_addextendedproperty

    @name       = 'MS_Description',

    @value      = 'ABC-Umsatzklassifizierung basierend auf Nettoumsatz der letzten 12 Monate. A >= 100.000 EUR, B >= 25.000 EUR, C >= 5.000 EUR, D < 5.000 EUR. Gem. Controlling-Handbuch §4.1.',

    @level0type = 'SCHEMA', @level0name = 'dwh',

    @level1type = 'TABLE',  @level1name = 'Dim_Kunden',

    @level2type = 'COLUMN', @level2name = 'Umsatzklasse';

 

-- Alle Extended Properties auslesen (für Katalog-Import)

SELECT

    SCHEMA_NAME(o.schema_id)    AS Schema_Name,

    o.name                      AS Tabelle,

    c.name                      AS Spalte,

    ep.value                    AS Beschreibung

FROM sys.extended_properties ep

JOIN sys.objects o ON ep.major_id = o.object_id

LEFT JOIN sys.columns c ON ep.minor_id = c.column_id

    AND ep.major_id = c.object_id

WHERE ep.name = 'MS_Description'

ORDER BY Schema_Name, Tabelle, Spalte;

 

-- Extended Properties in Katalog importieren

UPDATE f SET f.Beschreibung = ep.Beschreibung

FROM katalog.Felder f

JOIN katalog.Objekte o ON f.ObjektID = o.ObjektID

JOIN (

    SELECT SCHEMA_NAME(obj.schema_id) AS Schema_Name,

           obj.name AS Tabelle, c.name AS Spalte,

           CAST(ep.value AS NVARCHAR(MAX)) AS Beschreibung

    FROM sys.extended_properties ep

    JOIN sys.objects obj ON ep.major_id = obj.object_id

    JOIN sys.columns c ON ep.minor_id = c.column_id AND ep.major_id = c.object_id

    WHERE ep.name = 'MS_Description'

) ep ON o.Schema_Name = ep.Schema_Name

     AND o.Objekt_Name = ep.Tabelle

     AND f.Spaltenname  = ep.Spalte;

 

 

5.3 Nutzungsstatistiken aus DMVs

 

-- Welche Tabellen werden wie häufig genutzt?

SELECT TOP 50

    SCHEMA_NAME(o.schema_id)        AS Schema_Name,

    o.name                          AS Tabelle,

    SUM(ius.user_seeks)             AS Seeks,

    SUM(ius.user_scans)             AS Scans,

    SUM(ius.user_lookups)           AS Lookups,

    SUM(ius.user_updates)           AS Updates,

    SUM(ius.user_seeks + ius.user_scans + ius.user_lookups) AS Lesezugriffe_Gesamt,

    MAX(ius.last_user_seek)         AS Letzter_Lesezugriff,

    -- Beliebtheitsscore für Katalog-Priorisierung

    SUM(ius.user_seeks + ius.user_scans) AS Popularitaet

FROM sys.dm_db_index_usage_stats ius

JOIN sys.objects o ON ius.object_id = o.object_id

WHERE ius.database_id = DB_ID()

  AND o.type = 'U'

GROUP BY SCHEMA_NAME(o.schema_id), o.name

ORDER BY Popularitaet DESC;

 

-- Populärste Tabellen zuerst im Katalog dokumentieren (Priorität setzen)

UPDATE katalog.Objekte SET Naechste_Pruefung = DATEADD(DAY, 7, GETDATE())

WHERE Vollname IN (

    -- Top-20-Tabellen nach Nutzung

    SELECT TOP 20 SCHEMA_NAME(o.schema_id) + '.' + o.name

    FROM sys.dm_db_index_usage_stats ius

    JOIN sys.objects o ON ius.object_id = o.object_id

    WHERE ius.database_id = DB_ID()

    GROUP BY SCHEMA_NAME(o.schema_id), o.name

    ORDER BY SUM(ius.user_seeks + ius.user_scans) DESC

);

 

 


 

 

06

Business-Glossar

 

KPI-Definitionen, Fachbegriffe und Data Dictionary pflegen

 

6.1 KPI-Definitionen — das wichtigste Element jedes Glossars

 

-- KPI-Definitionen mit vollständigem Kontext

INSERT INTO katalog.Glossar

    (Begriff, Kategorie, Definition, Berechnungsformel, Einheit, Beispiel,

     Abgrenzung, Owner_Name, Gueltig_Ab, Synonyme)

VALUES (

    'Deckungsbeitrag I',

    'KPI',

    'Differenz zwischen dem Nettoumsatz und den direkt zurechenbaren variablen Kosten (Wareneinsatz). Misst den Beitrag jedes Produkts oder Auftrags zur Deckung der Fixkosten.',

    'DB I = Nettoumsatz - Wareneinsatz. Nettoumsatz = Bruttoverkaufspreis × Menge × (1 - Rabatt/100). Wareneinsatz = EK-Preis × Menge.',

    'EUR',

    'Artikel A: VK 100 EUR, EK 60 EUR, 50 Stk, 10% Rabatt → DB I = (100×50×0,9) - (60×50) = 4.500 - 3.000 = 1.500 EUR',

    'Nicht zu verwechseln mit Deckungsbeitrag II (DB I abzgl. Einzelkosten) oder der DB-Marge (DB I in % des Umsatzes). Enthält keine Fixkosten, Gemeinkosten oder Vertriebskosten.',

    'Controlling',

    '2024-01-01',

    'DB1, DB-I, Contribution Margin I'

),

(

    'Aktiver Kunde',

    'FACHBEGRIFF',

    'Kunde der im letzten Geschäftsjahr (rollierend 12 Monate) mindestens eine bezahlte Rechnung hatte. Stornierte oder unbezahlte Aufträge zählen nicht.',

    'Aktiv = MAX(Rechnungsdatum) >= DATEADD(YEAR,-1,GETDATE()) AND Status = ''BEZAHLT''',

    'Anzahl',

    'Kunde 4711 hat zuletzt am 15.03.2025 bezahlt → aktiv bis 15.03.2026',

    'Nicht zu verwechseln mit "registrierter Kunde" (hat Kundenkonto aber noch nie bestellt) oder "Interessent" (noch kein Auftrag). Kunden mit ausschließlich stornierten Aufträgen gelten als inaktiv.',

    'Vertriebscontrolling',

    '2023-06-01',

    'Bestandskunde, Aktivkunde'

);

 

-- Glossar-Such-View für Power BI und SSMS

CREATE OR ALTER VIEW katalog.V_Glossar_Suche AS

SELECT

    g.Begriff,

    g.Kategorie,

    g.Definition,

    g.Berechnungsformel,

    g.Einheit,

    g.Beispiel,

    g.Abgrenzung,

    g.Owner_Name,

    g.Synonyme,

    g.Gueltig_Ab,

    g.Geaendert_Am,

    -- Verknüpfte Felder

    STRING_AGG(

        k.Vollname + '.' + f.Spaltenname, ' | '

    ) WITHIN GROUP (ORDER BY k.Vollname) AS Verknuepfte_Felder

FROM katalog.Glossar g

LEFT JOIN katalog.Glossar_Felder gf ON g.GlossarID = gf.GlossarID

LEFT JOIN katalog.Felder f ON gf.FeldID = f.FeldID

LEFT JOIN katalog.Objekte k ON f.ObjektID = k.ObjektID

GROUP BY g.GlossarID, g.Begriff, g.Kategorie, g.Definition,

         g.Berechnungsformel, g.Einheit, g.Beispiel, g.Abgrenzung,

         g.Owner_Name, g.Synonyme, g.Gueltig_Ab, g.Geaendert_Am;

 

 


 

 

07

Datenlineage praktisch

 

Herkunft und Auswirkung von Feldern automatisch nachverfolgen

 

7.1 Automatische Lineage aus SQL Server-Abhängigkeiten

 

-- sys.sql_expression_dependencies als Lineage-Quelle

-- Zeigt welches Objekt welches andere referenziert

CREATE OR ALTER VIEW katalog.V_Lineage_Automatisch AS

SELECT

    SCHEMA_NAME(ref.schema_id) + '.' + ref.name    AS Referenzierendes_Objekt,

    ref.type_desc                                   AS Ref_Typ,

    d.referenced_schema_name + '.' +

        d.referenced_entity_name                   AS Referenziertes_Objekt,

    d.is_caller_dependent,

    d.is_ambiguous

FROM sys.sql_expression_dependencies d

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

WHERE d.referenced_entity_name IS NOT NULL

  AND d.referenced_schema_name IS NOT NULL

ORDER BY Referenzierendes_Objekt;

 

-- Impact-Analyse: was ist betroffen wenn Tabelle X geändert wird?

CREATE OR ALTER PROCEDURE katalog.SP_Impact_Analyse

    @Schema_Name    NVARCHAR(100),

    @Objekt_Name    NVARCHAR(200),

    @Tiefe          INT = 5   -- max. Rekursionstiefe

AS

BEGIN

    WITH Abhaengigkeiten AS (

        -- Ausgangsobjekt

        SELECT

            SCHEMA_NAME(o.schema_id) + '.' + o.name AS Objekt,

            o.type_desc AS Typ,

            0 AS Ebene,

            CAST(SCHEMA_NAME(o.schema_id) + '.' + o.name AS NVARCHAR(MAX)) AS Pfad

        FROM sys.objects o

        WHERE o.name = @Objekt_Name

          AND SCHEMA_NAME(o.schema_id) = @Schema_Name

 

        UNION ALL

 

        -- Rekursiv: was hängt davon ab?

        SELECT

            SCHEMA_NAME(ref.schema_id) + '.' + ref.name,

            ref.type_desc,

            a.Ebene + 1,

            a.Pfad + ' → ' + SCHEMA_NAME(ref.schema_id) + '.' + ref.name

        FROM Abhaengigkeiten a

        JOIN sys.sql_expression_dependencies d

            ON d.referenced_entity_name = PARSENAME(a.Objekt, 1)

            AND d.referenced_schema_name = PARSENAME(a.Objekt, 2)

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

        WHERE a.Ebene < @Tiefe

    )

    SELECT DISTINCT

        Ebene,

        REPLICATE('  ', Ebene) + Objekt AS Abhaengiges_Objekt,

        Typ,

        Pfad

    FROM Abhaengigkeiten

    WHERE Ebene > 0

    ORDER BY Ebene, Abhaengiges_Objekt;

END

 

-- Beispielaufruf: was ist betroffen wenn dbo.Kunden geändert wird?

EXEC katalog.SP_Impact_Analyse 'dbo', 'Kunden';

 

 

7.2 Lineage für ETL-Prozesse manuell erfassen

 

-- ETL-Lineage: Quelle → Transformation → Ziel für jede Pipeline

INSERT INTO katalog.Lineage

    (Quelle_ObjektID, Ziel_ObjektID, Transformationstyp,

     Transformationsbeschreibung, Pipeline_Name)

SELECT

    q.ObjektID,   -- ERP.dbo.Auftraege

    z.ObjektID,   -- dwh.Fact_Auftraege

    'BERECHNET',

    'Inkrementelles Laden täglich 06:00 Uhr. Transformation: KundenKey via SCD-Typ-2-Lookup, DatumKey via Dim_Datum-Join. Business-Logik: Nettobetrag = Bruttopreis × Menge × (1-Rabatt). Status STORNO und ENTWURF werden gefiltert.',

    'ETL_Tagesladung'

FROM katalog.Objekte q, katalog.Objekte z

WHERE q.Vollname = 'dbo.Auftraege'

  AND z.Vollname = 'dwh.Fact_Auftraege';

 

-- Lineage-Visualisierung: vollständiger Datenfluss von Quelle bis Report

WITH LineageKette AS (

    SELECT

        l.Quelle_ObjektID, l.Ziel_ObjektID,

        q.Vollname AS Von, z.Vollname AS Nach,

        l.Transformationstyp, l.Pipeline_Name,

        1 AS Ebene

    FROM katalog.Lineage l

    JOIN katalog.Objekte q ON l.Quelle_ObjektID = q.ObjektID

    JOIN katalog.Objekte z ON l.Ziel_ObjektID = z.ObjektID

    WHERE q.Vollname = 'dbo.Auftraege'   -- Startpunkt

 

    UNION ALL

 

    SELECT

        l.Quelle_ObjektID, l.Ziel_ObjektID,

        q.Vollname, z.Vollname,

        l.Transformationstyp, l.Pipeline_Name,

        lk.Ebene + 1

    FROM LineageKette lk

    JOIN katalog.Lineage l ON lk.Ziel_ObjektID = l.Quelle_ObjektID

    JOIN katalog.Objekte q ON l.Quelle_ObjektID = q.ObjektID

    JOIN katalog.Objekte z ON l.Ziel_ObjektID = z.ObjektID

    WHERE lk.Ebene < 10

)

SELECT Ebene, Von, Transformationstyp, Nach, Pipeline_Name

FROM LineageKette

ORDER BY Ebene, Von;

 

 


 

 

08

dbt als Katalog-Fundament

 

Dokumentation, Tests und Lineage als automatisches Nebenprodukt

 

8.1 dbt schema.yml — Katalog und Tests in einem

 

-- dbt schema.yml: ein YAML-File ist gleichzeitig Katalog, Testdefinition und Dokumentation

 

-- models/marts/schema.yml (Auszug)

-- version: 2

-- models:

--   - name: fact_auftraege

--     description: >

--       Täglich geladene Auftragsfacts aus dem ERP. Granularität: eine Zeile pro

--       Auftragsposition. Wird täglich um 07:00 Uhr aus dem ERP extrahiert und

--       via SCD Typ 2 mit aktuellen Dimensionen verknüpft. Nur Status GEBUCHT

--       und GELIEFERT enthalten.

--     meta:

--       owner: controlling@unternehmen.de

--       sla: täglich bis 07:30 Uhr

--       quellsystem: ERP SQL Server

--       power_bi_dataset: Umsatz-Dashboard

--     columns:

--       - name: auftrags_nr

--         description: "Eindeutige Auftragsnummer aus dem ERP-System"

--         tests:

--           - unique

--           - not_null

--       - name: nettobetrag

--         description: >

--           Nettoumsatz dieser Position in EUR. Berechnung: Einzelpreis × Menge ×

--           (1 - Rabatt). Ohne MwSt. Deckungsbeitrag I = nettobetrag - (ek_preis × menge).

--           Gem. Controlling-Handbuch §4.2.

--         meta:

--           kpi_relevant: true

--           nicht_additiv: false

--           glossar_id: DB_I

--         tests:

--           - not_null

--           - dbt_utils.accepted_range:

--               min_value: 0

 

-- dbt docs generate → automatische Katalog-Website

-- dbt docs serve    → lokaler Webserver mit Suche und Lineage-Graph

 

 

8.2 dbt Lineage-Graph — visuell und automatisch

 

dbt generiert automatisch einen vollständigen Lineage-Graph für alle Modelle — von den Quellsystemen bis zu den finalen Marts. Kein manuelles Pflegen nötig: die Lineage entsteht aus den Modell-Referenzen ({{ ref(...) }} und {{ source(...) }}).

 

  dbt docs serve: öffnet einen Browser mit vollständigem Lineage-Graphen, Modell-Dokumentation und Test-Ergebnissen.

 

  Column-level Lineage: mit dbt + Paketen wie dbt-column-lineage auch auf Spaltenebene.

 

  Integration: dbt-Metadaten können via dbt Cloud API oder dbt Artifacts (catalog.json, manifest.json) in eigene Katalog-Lösungen importiert werden.

 

-- dbt Artifacts in SQL Katalog importieren (via Python-Skript)

-- Die manifest.json enthält vollständige Modell-Metadaten und Lineage

-- Die catalog.json enthält Schema-Informationen

 

-- Python-Schnipsel (zur Referenz, nicht als SQL):

-- import json

-- with open('target/manifest.json') as f:

--     manifest = json.load(f)

-- for node_name, node in manifest['nodes'].items():

--     # Modell-Metadaten in katalog.Objekte schreiben

--     name = node['name']

--     description = node.get('description','')

--     owner = node.get('meta',{}).get('owner','')

--     # Abhängigkeiten → katalog.Lineage

--     for dep in node.get('depends_on',{}).get('nodes',[]):

--         # Lineage-Eintrag für jede Abhängigkeit erstellen

 

 


 

 

09

Azure Purview für KMU

 

Wann das Enterprise-Tool sich lohnt — und wann nicht

 

9.1 Was Azure Purview leistet

 

Azure Purview (seit 2024 Teil von Microsoft Purview) ist der Enterprise-Datenkatalog von Microsoft. Er bietet automatische Metadaten-Extraktion, Klassifizierung sensibler Daten, Lineage-Visualisierung und ein Business-Glossar — für eine breite Palette von Quellen: SQL Server, Azure SQL, Azure Data Lake, Power BI, SAP, Oracle und viele mehr.

 

Stärken gegenüber der SQL-Server-Eigenentwicklung:

 

  Automatische Klassifizierung sensibler Daten (IBAN, Sozialversicherungsnummer, E-Mail) via KI.

 

  Power BI-Integration: Lineage von der Datenquelle bis zum Report-Visual automatisch.

 

  Unified Interface: eine Oberfläche für alle Datenquellen — auch Nicht-SQL-Quellen.

 

  DSGVO-Unterstützung: Datensubjekt-Auskunft, Löschanträge über Katalog steuerbar.

 

Einschränkungen für KMU:

 

  Kosten: Azure Purview Data Map wird nach Dateneinheiten (Capacity Units) abgerechnet — ab ~500 EUR/Monat für sinnvolle Nutzung.

 

  Komplexität: Konfiguration und Betrieb erfordert Azure-Expertise.

 

  Overkill: für eine SQL-Server-only-Umgebung mit < 500 Tabellen ist die eigene Lösung aus Kapitel 4 ausreichend und deutlich günstiger.

 

9.2 Entscheidungsmatrix: SQL-Katalog vs. Azure Purview

 

Kriterium

SQL Server Eigenentwicklung

Azure Purview

Kosten

0 EUR (nur Entwicklungszeit)

Ab ~500 EUR/Monat

Quellen

SQL Server + manuell andere

200+ Quelltypen automatisch

Automatisierung

Manuell per Skript

Automatische Scans

Power BI Lineage

Manuell oder via REST-API

Automatisch, visuell

DSGVO-Tools

Selbst bauen

Integriert

Empfohlen für

1–3 SQL-Server-Datenbanken

5+ heterogene Systeme

Lernaufwand

Niedrig (SQL bekannt)

Hoch (Azure-spezifisch)

 

 

KMU-EMPFEHLUNG 2026

  Bis 5 Datenbanken, ausschließlich SQL Server: eigene Lösung aus Kapitel 4 + dbt.

  Microsoft Fabric bereits lizenziert: Fabric Data Catalog ist inklusive — vor Purview-Kauf prüfen.

  Mehr als 5 heterogene Quellen (SQL + Oracle + SAP + Webshop-API): Azure Purview evaluieren.

  Strenge DSGVO-Anforderungen mit vielen personenbezogenen Datenquellen: Azure Purview rechtfertigt die Investition.

 


 

 

10

30-Tage-Katalog-Bootstrapplan

 

Vom leeren Feld zur gepflegten, durchsuchbaren Metadaten-Bibliothek

 

 

VOR DEM START

Benennen Sie einen Katalog-Owner mit echtem Zeitbudget (mindestens 4 Stunden pro Woche). Identifizieren Sie die 20 am häufigsten genutzten Tabellen — das sind Ihre ersten Einträge. Klären Sie mit dem Datenschutzbeauftragten: welche Felder sind DSGVO-relevant und müssen besonders geschützt dokumentiert werden?

 

WOCHE 1: INFRASTRUKTUR UND PRIORITÄTEN

 

■ TAG 1-2: KATALOG-SCHEMA ANLEGEN

 

  Schema und alle Tabellen aus Kapitel 4.1 in der Zieldatenbank anlegen

  Automatische Metadaten-Synchronisation aus Kapitel 5.1 einrichten und testen

  Extended Properties für die 5 wichtigsten Tabellen händisch nachtragen

  SQL Agent Job: tägliche Synchronisation technischer Metadaten um 05:00 Uhr

 

■ TAG 3-4: PRIORITÄTEN FESTLEGEN

 

  Nutzungsstatistik-Abfrage aus Kapitel 5.3 ausführen: welche Tabellen werden am häufigsten genutzt?

  Top-20-Tabellen als erstes Dokumentationsziel festlegen

  Power BI-Reports analysieren: welche Felder erscheinen in den wichtigsten Berichten?

  Owner-Zuweisung: für jede der Top-20-Tabellen einen verantwortlichen Steward benennen

 

■ TAG 5-7: ERSTE BUSINESS-METADATEN ERFASSEN

 

  Beschreibung und Bezeichnung_DE für die Top-5-Tabellen eintragen

  Für jede Tabelle: die drei wichtigsten Spalten mit Beschreibung versehen

  Extended Properties für dokumentierte Felder setzen (erscheinen dann in SSMS)

  Erste Glossar-Einträge: die 10 wichtigsten KPIs aus dem Controlling erfassen

 

WOCHE 2: GLOSSAR UND LINEAGE

 

■ TAG 8-10: BUSINESS-GLOSSAR AUFBAUEN

 

  Workshop mit Controlling und Vertrieb: welche KPIs werden am häufigsten diskutiert?

  KPI-Definitionen nach Template aus Kapitel 6.1 erfassen — mindestens 15 Einträge

  Synonyme-Feld befüllen: wie werden Begriffe in verschiedenen Abteilungen genannt?

  Verknüpfung Glossar-Einträge ↔ Datenbankfelder: welches Feld berechnet welchen KPI?

 

■ TAG 11-13: LINEAGE FÜR TOP-PIPELINES

 

  Impact-Analyse-Procedure aus Kapitel 7.1 testen: für die meistgenutzte Tabelle

  ETL-Lineage für die Top-5-Pipelines manuell in katalog.Lineage erfassen

  dbt installieren (falls noch nicht vorhanden): erste schema.yml-Dateien für bestehende Modelle

  Automatische Lineage aus sys.sql_expression_dependencies in Katalog importieren

 

■ TAG 14: SUCHE UND FIRST-USER-TEST

 

  Katalog-Suche aus Kapitel 4.2 testen: 5 typische Analyst-Suchanfragen durchführen

  Ersten Nutzer (Analyst, der den Katalog nicht kennt) bitten, 3 Fragen mit dem Katalog zu beantworten

  Feedback auswerten: welche Information fehlt? Was ist unklar?

  Fehlende Einträge priorisieren und in Woche 3 ergänzen

 

WOCHE 3: QUALITÄT UND SELF-SERVICE

 

■ TAG 15-17: QUALITÄTSSICHERUNG EINRICHTEN

 

  Katalog-Vollständigkeits-Report erstellen: wie viele Felder haben noch keine Beschreibung?

  Schema-Monitoring aus ETL-Kit aktivieren: Alert wenn neue Tabellen entstehen ohne Katalog-Eintrag

  Vierteljährliches Review einplanen: welche Einträge müssen wann geprüft werden?

  DSGVO-Audit: alle Tabellen mit personenbezogenen Daten als DSGVO_Relevant = 1 markieren

 

■ TAG 18-20: SELF-SERVICE AKTIVIEREN

 

  Berechtigungen einrichten: wer darf lesen, wer darf bearbeiten, wer darf freigeben?

  "Suggest an edit"-Mechanismus implementieren: Tabelle für Korrekturvorschläge

  Power BI Katalog-Dashboard aufbauen: Vollständigkeit, Top-fehlende Einträge, Freshness

  Kommunikation an alle Analysten: Katalog ist verfügbar — Demo-Session einplanen

 

■ TAG 21: ONBOARDING-INTEGRATION

 

  Katalog in Onboarding-Prozess neuer Mitarbeiter integrieren: "Das ist, wo wir Daten erklären"

  Hilfeanleitung: wie suche ich im Katalog, wie schlage ich Änderungen vor?

  Ersten Glossar-Owner-Meeting einplanen: monatlich 30 Minuten, Glossar-Pflege als Tagesordnungspunkt

  Feedback-Kanal einrichten: wie können Nutzer fehlende oder falsche Einträge melden?

 

WOCHE 4: AUTOMATISIERUNG UND AUSBLICK

 

■ TAG 22-25: AUTOMATISIERUNG AUSBAUEN

 

  Täglichen Katalog-Gesundheits-Report als SQL Agent Job einrichten

  Alert bei neuen Tabellen ohne Katalog-Eintrag: wöchentlicher Report an Katalog-Owner

  Extended Properties vollständig syncen: alle manuell erfassten Beschreibungen als EP setzen

  dbt docs generate + dbt docs serve testen: automatisch generierte Dokumentations-Website

 

■ TAG 26-28: INTEGRATION IN BESTEHENDE WORKFLOWS

 

  Power BI: Feldbeschreibungen aus Katalog als Tooltip-Text in Reports einbauen

  SSMS: Extended Properties erscheinen automatisch als Tooltip beim Hover über Spalten

  Confluence/SharePoint: Katalog-Glossar als eingebettete Tabelle in Dokumentationen referenzieren

  Glossar-Verlinkungen: in Prozessdokumentationen auf Glossar-Einträge verweisen

 

■ TAG 29-30: ABSCHLUSS UND ROADMAP

 

  Abschlussmessung: wie viele Objekte, Felder und Glossar-Einträge sind dokumentiert?

  Vollständigkeits-Score: welcher Anteil der meistgenutzten Tabellen ist dokumentiert?

  Roadmap: welche weiteren Quellsysteme sollen als nächstes in den Katalog aufgenommen werden?

  Entscheidung Azure Purview: lohnt sich der Wechsel auf Basis der Erfahrungen aus 30 Tagen?

  Ergebnis feiern — ein gepflegter Datenkatalog ist das Gedächtnis Ihrer Datenarchitektur! ■

 

 

ERGEBNIS NACH 30 TAGEN

Ihr Ergebnis nach 30 Tagen: Ein automatisch befüllter technischer Katalog für alle Datenbankobjekte, vollständig dokumentierte Top-20-Tabellen mit Business-Beschreibungen und Ownern, ein Business-Glossar mit mindestens 15 KPI-Definitionen, eine Lineage-Dokumentation für die wichtigsten ETL-Pipelines, ein Power-BI-Monitoring-Dashboard und eine Katalog-Suche die Analysten tatsächlich nutzen.

 


 

 

Ausführlicher Haftungsausschluss und Lizenzbestimmungen

 

1. Allgemeiner Haftungsausschluss

 

Die in diesem Dokument enthaltenen Informationen, Skripte und Konzepte wurden nach bestem Wissen und Gewissen erarbeitet. Der Autor übernimmt keinerlei Haftung für Datenverlust, fehlerhafte Metadaten, Compliance-Verstöße oder sonstige Schäden aus der Anwendung der beschriebenen Methoden.

 

2. DSGVO und Datenschutz

 

Datenkataloge beschreiben personenbezogene Datenquellen und können selbst als Teil des Verarbeitungsverzeichnisses nach Art. 30 DSGVO gelten. Klären Sie Umfang und Anforderungen mit Ihrem Datenschutzbeauftragten.

 

3. Versionsabhängigkeit

 

SQL Server 2022/2025, Azure Purview / Microsoft Purview, dbt Core 1.8+, Microsoft Fabric, Stand März 2026.

 

4. Urheberrecht

 

© 2026 Sascha Hess, xenosystems.de. Alle Rechte vorbehalten.

 

5. Anwendbares Recht und Gerichtsstand

 

Deutsches Recht. Gerichtsstand Weimar, Thüringen.

 


 

 

Über den Autor

 

Sascha Hess ist Diplom-Biologe und IT-Professional mit über 20 Jahren Erfahrung in der Administration von ERP-, BI- und Datenbanksystemen. Er hat mehr als 300 Oracle- und SQL-Server-Instanzen administriert und betreut — von mittelständischen KMU bis zu Universitäten und Energieversorgern.

 

Web: www.xenosystems.de | E-Mail: info@xenosystems.de | Standort: Weimar, Thüringen / Remote

 

Service

Beschreibung

Datenkatalog-Aufbau

Implementierung eines produktionsfertigen Datenkatalogs mit SQL Server, automatischer Metadaten-Extraktion, Business-Glossar und Lineage-Dokumentation.

MDM-Readiness Assessment

Analyse Ihrer Stammdatenlandschaft — Reifegradbestimmung, Katalog-Priorisierung und Umsetzungsfahrplan. Scope: 3-5 Tage.

BI-Dashboard-Aufbau

Power BI Dashboards inkl. Datenkatalog-Integration und strukturiertem Data-Governance-Fundament.

SQL Server DB Health Check

Professioneller Audit — Performance, Metadaten-Analyse, Dokumentationsstand. Scope: 3-5 Tage.

Interim IT-Management

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

 

Vollständiges Dokument

konzept kit datenkataloge metadaten 2026

Strategische Wissens-Roadmap · Checklisten · Praxisbeispiele

49,90 €

Sichere Zahlung über PayPal · Sofort-Download nach Zahlungseingang