Data Catalog: Wertschöpfung durch Metadaten

Photo by @Emmanuel_Appiah on Unsplash, abgerufen am 05.05.2025

Im Finanzsektor spielen Daten eine zentrale Rolle bei der Entscheidungsfindung, der Risikobewertung und der Einhaltung regulatorischer Vorgaben. Finanzdienstleistende stehen vor der stetigen Herausforderung, immense Datenmengen nicht nur effizient zu verwalten, sondern diese auch nutzbar zu machen. Dies erfordert ein effektives Datenmanagement, das eine strukturierte Übersicht über sämtliche im Unternehmen vorhandene Daten beinhaltet. Ein Data Catalog kann hierbei als Schlüsseltechnologie dienen, die es ermöglicht, Daten effizient zu organisieren, zu finden und zu nutzen.

Was sind Metadaten?

„Ein Data Catalog ist eine organisierte Inventarliste der Daten einer Organisation, die eine Übersicht auf Metadaten-Ebene bietet, ohne tatsächliche Datenwerte offenzulegen.“ [1]

Ein Data Catalog kann als Metadaten-Management-System verstanden werden. Das zentrale Element stellen hierbei die Metadaten dar. Metadaten sind Informationen über Merkmale anderer Daten, die in folgende Kategorien aufgeteilt werden können:

Fachliche Metadaten: Diese beschreiben den geschäftlichen Kontext von Daten. Dazu gehören unter anderem Beschreibungen, die Bedeutung einzelner Datenfelder und deren Verwendung in Geschäftsprozessen.

Technische Metadaten: Diese beziehen sich auf die technischen Spezifikationen der Daten, wie z. B. Datentypen, Formate, Strukturen oder auch Beziehungen zwischen Daten.

Operative Metadaten: Diese umfassen Informationen über die Nutzung und Verwaltung von Daten, wie z. B. Logdateien, die Zugriffe und Änderungen an den Daten dokumentieren.

Ein Data Catalog beinhaltet also nicht die Daten selbst, sondern ausschließlich Informationen über Daten, wie beispielhaft in Abbildung 1 dargestellt. Im Data Catalog sind beispielsweise die Tabellen- und Spaltennamen aufgeführt. Die Datenwerte, die in den einzelnen Spalten hinterlegt sind, werden nicht im Data Catalog gespeichert. Dies hat mehrere Gründe:

Ein Data Catalog soll für alle Mitarbeitenden in einer Organisation zugänglich sein. Deshalb dürfen hier keine sensiblen Daten (z. B. personenbezogene Daten von Kunden) hinterlegt sein.
Ein Data Catalog soll nicht die Suche in Daten, sondern die Suche nach Daten ermöglichen. Der Fokus liegt darauf, herauszufinden, welche Daten in der Organisation vorhanden sind und wo diese zu finden sind.
Ein Data Catalog soll die Daten einer Organisation nicht zentralisieren (wie z. B. in einem Data Warehouse), sondern einen Überblick über die verteilten Daten einer Organisation liefern.

Abbildung 1: Tabelle in der Datenquelle und im Data Catalog

Wie ist ein Data Catalog aufgebaut?

Ein Data Catalog ist in Domänen aufgeteilt. Die Domänen eines Data Catalogs sind an der Definition aus der Bibliotheks- und Informationswissenschaft ausgerichtet.

„Eine Domäne kann eine Gruppe von Menschen sein, die zusammenarbeiten, wenn sie das gleiche Wissen, die gleichen Ziele, die gleichen Arbeitsmethoden und die gleiche Kommunikationsweise haben.“ [2]

Wissen: Ein gemeinsames Verständnis von Konzepten und ihren Beziehungen.

Ziele: Die Ambitionen dessen, was eine Gruppe erreichen oder erhalten möchte.

Arbeitsmethoden: Hypothesen und Vorgehensweisen zur Prüfung und Erweiterung der Domänen.

Kommunikationsweise: Instrumente und Systeme, die von der Gruppe zur Kommunikation verwendet werden.

Besonders hervorzuheben ist dabei, dass bei diesem Ansatz eine Datenquelle mehreren Domänen zugeordnet werden kann. Dies ist ein wesentlicher Unterschied zum Ansatz des Domain Driven Designs.

Die Domänen können in Subdomänen unterteilt werden und orientieren sich an Prozessen oder Fähigkeiten. In Abbildung 2 ist beispielhaft eine Domänenarchitektur dargestellt, die sich an Prozessen orientiert. Prozesse beschreiben, wie ein Unternehmen seine Aufgaben erfüllt. Es geht darum, wie die Aufgaben erledigt werden.

Abbildung 2: Domänenarchitektur basierend auf Prozessen

Alternativ kann die Domänenarchitektur, wie in Abbildung 3 dargestellt, auf Fähigkeiten aufsetzen. Fähigkeiten beschreiben, welche Aufgaben ein Unternehmen erfüllt – wozu das Unternehmen fähig ist. Um eine robuste Domänenarchitektur zu gewährleisten, ist es wichtig, dass zu Beginn eine klare Entscheidung getroffen wird, welche Domänenarchitektur gewählt wird und keine Mischform aus Prozessen und Fähigkeiten entsteht.

Abbildung 3: Domänenarchitektur basierend auf Fähigkeiten

Den einzelnen Domänen werden Datenquellen zugeordnet. Dies können z. B. Datenbanken, Data Warehouses, Data Lakes, Reports oder operative Anwendungen sein. Die Datenquellen werden in allgemeine und spezifische Datenquellen unterteilt. Bei den allgemeinen Datenquellen handelt es sich um die Systeme, die die Daten bereitstellen. Eine spezifische Datenquelle ist eine Instanz der allgemeinen Datenquelle. Dies kann z. B. eine Data Mart in einem Data Warehouse sein oder eine bestimmte Datenbankinstanz. Innerhalb der spezifische Datenquellen befinden sich die Assets, wie in Abbildung 4 dargestellt. Assets können jede beliebige Entität darstellen, die in der unternehmensweiten IT-Landschaft vorhanden ist. Es kann z. B. eine Datei, ein Ordner oder eine Tabelle sein. Ein Asset besteht aus Metadaten, die eine Entität in ihrer spezifische Datenquellen beschreiben.

Abbildung 4: Domänenarchitektur basierend auf Fähigkeiten mit Datenquellen und Assets

Wie kommen die Assets in den Data Catalog?

Die Integration der Assets in einen Data Catalog kann durch zwei Hauptmethoden erfolgen. Den Pull- und den Push-Ansatz:

Pull-Ansatz: Automatisiertes Einlesen von Metadaten aus den Quellsystemen mittels standardisierter Konnektoren, APIs (Application Programming Interfaces) oder RDS (Read-Only Data Stores). Hierbei zieht sich der Data Catalog die Metadaten aus den Quellsystemen.

Push-Ansatz: Automatisiertes Eintragen von Metadaten aus den Quellsystemen mittels Streaming-Plattformen, APIs oder automatischer Metadaten-Extraktion. Hierbei sendet das Quellsystem die Metadaten an den Data Catalog.

Viele Data Catalogs bringen standardisierte Konnektoren mit, die eine einfache Integration von Quellsystemen ermöglichen. Am weitesten verbreitet sind Konnektoren für:

Datenbanken: SAP HANA, Amazon RDS, Postgres, MySQL, MS SQLServer, Teradata etc.

Data Warehouses: Amazon Redshift, Big Query, Hive, IBM DB2, Oracle, Parquet, Snowflake etc.

Data Lakes: Amazone S3, Apache Iceberg, AWS Glue, Azure Data Lake Storage, Databricks, Delta Lake etc.

BI-Tools: Azure Synapse, Looker, Power BI, Qlik Sense, Tableau etc.

Ist für ein Quellsystem kein standardisierter Konnektor vorhanden, so kann auf APIs zurückgegriffen werden. Sollte das Quellsystem keine API haben, kann ein RDS genutzt werden. Hierbei werden die Daten aus dem Quellsystem in einer Datenbank gespiegelt und zum Lesen bereitgestellt. Die Beladung des RDS kann z. B. durch ETL/ELT-Tools (Extract, Transform, Load / Extract, Load, Transform) erfolgen. Die Integration des RDS zum Data Catalog erfolgt in der Regel über Standardkonnektoren.

Wie werden Assets erweitert?

Bei Metadaten, die direkt aus den Quellsystemen abgeleitet werden können, handelt es sich überwiegend um technische und operative Metadaten. Damit Assets schnell auffindbar und verständlich sind, müssen diese um fachliche Metadaten, wie Beschreibungen, Glossarbegriffe, Personen und Klassifizierungen erweitert werden.

Beschreibungen: Eine Beschreibung besteht aus zwei Elementen. Die primäre Verwendung und die sekundäre Verwendung. Die primäre Verwendung ist eine Erklärung, wofür das Asset in der Datenquelle verwendet wird. Die sekundäre Verwendung ist ein Vorschlag, wofür das Asset verwendet werden kann.

Glossarbegriffe: Mit Hilfe von Glossarbegriffen können Assets gekennzeichnet werden. Dadurch wird die Auffindbarkeit der Assets erhöht, wenn Nutzer:innen nach Themen suchen, für die das Asset relevant sein könnte. In einem Data Catalog werden Glossare, wie in Abbildung 5 dargestellt, in drei verschiedene Kategorien klassifiziert:

Freies Glossar: Hierbei handelt es sich um eine Folksonomie, auch bekannt als „Social Tagging“. Es ist ein System zur Klassifizierung von Inhalten, das von Nutzer:innen gemeinsam erstellt wird. Nutzer:innen können Assets mit Tags versehen, ähnlich wie bei Social-Media-Inhalten. Dabei gibt es keine formalen Regeln. Jeder kann Tags erstellen und nutzen.

Domänenglossar: Bei einem Domänenglossar handelt es sich um eine Taxonomie. Assets werden durch ein einheitliches Verfahren bzw. Modell, innerhalb einer Domäne, nach bestimmten Kriterien klassifiziert. Taxonomien werden von einer kleinen Gruppe von Personen innerhalb einer Domäne erstellt und stellen eine formale Sprache dar. Bei Taxonomien werden Hierarchien aufgebaut, die Begriffe in enge und weite Kategorien einordnen. Eine Transaktion kann beispielsweise eine weite Kategorie darstellen. Die konkretere Form SEPA-Überweisung kann die enge Kategorie darstellen.

Globales Glossar: Das globale Glossar stellt einen Thesaurus dar. Hierbei handelt es sich um eine geordnete Zusammenstellung von Begriffen eines Fachgebietes. Die Fachbegriffe werden gesammelt und in Beziehungen gesetzt. Der bevorzugte Begriff (z. B. Alternative Reference Rate) ist hierbei das Zentrum. Um das Zentrum herum werden Beziehungen zu weiten Begriffen (z. B. Referenzzinsen), engen Begriffen (z. B. SOFR), verwandten Begriffen (z. B. Zinskonditionen) und Begriffsvariationen (z. B. ARR) gebildet.

Personen: Hierbei handelt es sich um alle relevanten Personen, die einen Bezug zu den Daten haben. Diese können z. B. folgende Rollen haben:

Domain owner: Hat die Gesamtverantwortung für die Daten innerhalb der Domäne. Ein Domain owner legt fest, welche Assets in die Domäne gehören und wer die verschiedenen Rollen innerhalb dieser Domäne ausfüllt.

Domain steward: Ist zuständig für die operative Umsetzung der Governance in der Domäne. Führt die Koordination mit den Stakeholdern aus und verwaltet die Domänenarchitektur.

Data source owner: Ist verantwortlich für die Verwaltung und Pflege einer bestimmten Datenquelle.

Asset owner: Ist verantwortlich für Inhalt, Qualität, Nutzung und Freigabe von Assets. Ein Asset owner verwaltet Assets aus mehreren Datenquellen.

Asset steward: Pflegt die Metadaten, führt Qualitätssicherungen durch und klassifiziert Assets aus einer bestimmten Datenquelle bzw. aus einem Teil einer Datenquelle.

Term owner: Ist verantwortlich für die fachliche Definition von Begriffen im Domänenglossar und im globalen Glossar. Die Begriffe können einer oder mehreren Domänen zugeordnet sein. Für Begriffe aus dem freien Glossar gibt es keine Term owner, da diese von allen Nutzer:innen verwaltet werden.

Term steward: Verwaltet die Lifecycles von Begriffen im Domänenglossar und im globalen Glossar. Ein Term steward kann u. a. Begriffe ändern, ersetzen oder archivieren.

Klassifizierungen: Kategorisierung der Daten nach Inhalt, Vertraulichkeit und Sensibilitätsgrad (z. B. öffentlich, intern, eingeschränkt).

Wie kann nach Assets gesucht werden?

Um die richtigen Daten zu finden kann es von Vorteil sein, wenn unterschiedliche Instrumente für die Suche vorhanden sind. Ein Data Catalog stellt folgende Möglichkeiten der Suche zur Verfügung:

Schlüsselwortsuche: Ermöglicht den Nutzer:innen die Suche nach Schlüsselwörtern, die sich auf die von ihnen benötigten Daten beziehen.

Domain-Suche: Ermöglicht es den Nutzer:innen, durch Domänen und Subdomänen zu blättern, um relevante Datenbestände zu finden.

Data Lineage: Ermöglicht es den Nutzer:innen, die Herkunft von Daten rückwärts oder vorwärts zu verfolgen, um ihre Ursprünge, Transformationen und Abhängigkeiten zu verstehen.

Data Catalog Query Language (DCQL): Standardisierte Abfragesprache, um den Nutzer:innen eine flexible Möglichkeit zu bieten, Daten aus dem Katalog zu suchen und abzurufen.

Warum ist der Einsatz eines Data Catalogs sinnvoll?

Besonders hervorzuheben ist die Bedeutung des Data Catalogs für die Steigerung der betrieblichen Effizienz. Durch die umfangreichen Suchfunktionen und die Kategorisierung von Daten, können benötigte Informationen schneller gefunden werden. Dies ermöglicht es den Mitarbeitenden sich auf die Analyse und Interpretation der Daten zu konzentrieren, anstatt wertvolle Zeit mit der Suche nach Daten zu verbringen. Hierdurch können auch Fragen, die z. B. bei Wirtschaftsprüfungen auftreten schneller beantwortet werden.

Ein häufiges Problem in großen Organisationen sind Datensilos – isolierte Datenbestände, die schwer zugänglich sind. Diese Silos entstehen oft aufgrund von historischen Systemen oder spezifischen Anforderungen einzelner Abteilungen. Ein Data Catalog kann diese Silos aufbrechen, da er Transparenz über die vorhandenen Daten schafft. Dies erleichtert die unternehmensweite Zusammenarbeit und unterstützt eine einheitliche Datenstrategie.

Redundante Daten können durch einen Data Catalog identifiziert und eliminiert werden. Dies reduziert Dateninkonsistenzen und kann zu Kosteneinsparungen führen, wenn es sich um extern angeschaffte Daten, wie z. B. Marktdaten handelt.

Personen, die Daten nutzen, kennen oft nur eine begrenzte Anzahl an Datenquellen und nutzen diese für verschiedene Fragestellungen, was nicht immer optimal ist. Ein Data Catalog unterstützt dabei, die besten verfügbaren Datenquellen für spezifische Problemstellungen zu identifizieren.

Ein weiterer wesentlicher Vorteil eines Data Catalogs ist die Unterstützung von Self-Service-Ansätzen. Fachabteilungen können selbst nach den benötigten Daten suchen, ohne umfangreiche Anfragen an die IT-Abteilung stellen zu müssen.

Datenexpert:innen können beispielsweise, statt Fragen zu ihren Daten direkt zu beantworten, einfach einen Link zur Dokumentation im Data Catalog versenden.

Durch fachliche Beschreibungen, Informationen zur Datenaktualität und -herkunft kann das Vertrauen in die Daten gesteigert werden.

Die Einhaltung von Datenschutzbestimmungen ist ebenfalls von entscheidender Bedeutung. Ein Data Catalog hilft dabei, diese Anforderungen zu erfüllen, indem er die Klassifizierung von Daten nach Sensibilität und Vertraulichkeit unterstützt.

Ein Data Catalog trägt außerdem zur Verbesserung der Datenqualität bei, indem er klare Verantwortlichkeiten definiert. Die Verantwortung für die Überwachung der Datenqualität und die Einhaltung der Datenrichtlinien ist konkreten Rollen zugewiesen.

Auch die Analyse des Einflusses von Veränderungen in IT-Systemen lässt sich durch die Möglichkeit zur Darstellung der Datenherkunft vereinfachen.

Eine gründliche Datendokumentation durch Metadaten kann zusätzlich dazu führen, den Einfluss von Personalfluktuation zu dämpfen, da Datenkontext, -geschichte und -ursprung stets leicht nachvollziehbar sind. [3]

Ebenfalls erwähnenswert ist, dass dezentrale Architekturansätze wie z. B. Data Mesh immer mehr an Bedeutung gewinnen. Je umfangreicher, verteilter und diverser die vorhandenen Daten sind, desto relevanter ist der Data Catalog. Wenn Sie mehr über Data Mesh erfahren möchten, lesen Sie auch unseren Artikel Data Mesh: Eine dezentrale Datenarchitektur.

Wie Finbridge Sie unterstützt

Finbridge unterstützt Sie bei der Entwicklung Ihrer zukunftssicheren Datenstrategie und der entsprechenden IT-Architektur. Durch unsere umfassende technische Expertise und unser fachliches Know-how in der Banken- und Finanzdienstleistungsbranche können wir flexibel auf die spezifischen Bedürfnisse Ihres Unternehmens eingehen und Sie bei der Umsetzung einer zukunftsorientierten IT- und Datenlandschaft begleiten, die auch allen regulatorischen Anforderungen gerecht wird.