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 |
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.
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
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 sind "Daten über Daten". Aber nicht alle Metadaten sind gleich — sie haben unterschiedliche Quellen, Zielgruppen und Pflegeverantwortlichkeiten.
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.
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.
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.
|
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
|
-- 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) ); |
|
-- 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
|
-- 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 |
|
-- 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; |
|
-- 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
|
-- 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
|
-- 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'; |
|
-- 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 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 |
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 (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.
|
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
|
|
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? |
■ 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
■ 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
■ 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?
■ 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. |
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.
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.
SQL Server 2022/2025, Azure Purview / Microsoft Purview, dbt Core 1.8+, Microsoft Fabric, Stand März 2026.
© 2026 Sascha Hess, xenosystems.de. Alle Rechte vorbehalten.
Deutsches Recht. Gerichtsstand Weimar, Thüringen.
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
Strategische Wissens-Roadmap · Checklisten · Praxisbeispiele
49,90 €
Sichere Zahlung über PayPal · Sofort-Download nach Zahlungseingang