Business Glossary vs. Data Catalog vs. Data Dictionary: Unterschiede und Zusammenspiel
Welche Lösung beantwortet fachliche, organisatorische oder technische Fragen – und wann braucht ein Team alle drei?
Business Glossary, Data Catalog und Data Dictionary lösen unterschiedliche Metadatenprobleme. Das Business Glossary erklärt fachliche Begriffe. Der Data Catalog schafft einen übergreifenden Bestand technischer und organisatorischer Metadaten. Das Data Dictionary beschreibt die Struktur konkreter Tabellen und Felder.
Die Funktionen können in einem Werkzeug zusammenkommen. Für die Auswahl hilft deshalb eine einfache Unterscheidung: Bedeutung klären, Daten finden oder Struktur verstehen? Dieser Vergleich beschreibt die Aufgaben der drei Ebenen; der tatsächliche Funktionsumfang hängt von der jeweiligen Umsetzung ab.
Der direkte Vergleich
| Kriterium | Business Glossary | Data Catalog | Data Dictionary |
|---|---|---|---|
| Zweck | Gemeinsame fachliche Sprache schaffen | Datenbestände auffindbar und bewertbar machen | Technische Struktur eines Datenbestands erklären |
| Leitfrage | Was bedeutet dieser Geschäftsbegriff? | Welche Datenobjekte gibt es und wie hängen sie zusammen? | Welche Tabellen, Felder und Datentypen enthält dieses Modell? |
| Hauptzielgruppe | Fachbereiche, BI, Analytics, Governance | Data Engineers, Analytics Engineers, Stewards, Analysten | Entwickler, Data Engineers, BI-Entwickler |
| Typische Inhalte | Definition, Synonyme, Owner, Status, Regeln, Beziehungen | Assets, Systeme, Owner, Klassifikation, Lineage, Nutzungskontext | Tabellen, Spalten, Datentypen, Schlüssel, Constraints, Beschreibungen |
| Ownership | Fachliche Domänen und Data Stewards | Data Platform, Governance und Asset Owner | Technische Teams oder Modellverantwortliche |
| Beispiel | „Aktiver Kunde“ und seine Abgrenzung | Vertriebsmodell, CRM-Quelle und zugehörige Dashboards | dim_customer.status_code ist varchar(20) |
| Änderungsauslöser | Fachliche Regel oder Organisationsentscheidung | Neue Quelle, neues Asset oder geänderte Beziehung | Schemaänderung oder neue Spalte |
Keine der drei Lösungen ersetzt automatisch die anderen. Eine Feldbeschreibung erklärt nicht die gesamte Bedeutung des Begriffs „aktiver Kunde“. Eine fachliche Definition verrät umgekehrt nicht, in welcher Tabelle der Status gespeichert ist.
Was ist ein Business Glossary?
Ein Business Glossary dokumentiert die Sprache des Unternehmens. Typische Einträge sind Kunde, Vertrag, Umsatz, Region oder Kampagne. Neben der Definition gehören Synonyme, Domäne, Owner, Status und Beziehungen dazu.
Ein KPI-Glossar ergänzt diese fachliche Ebene um Kennzahlen mit Formel, Einheit, Zeitraum und Datenquellen. Ein Geschäftsbegriff wie „aktiver Kunde“ und die Kennzahl „Anzahl aktiver Kunden“ sind dabei verknüpft, aber keine identischen Einträge.
Das Business Glossary ist erfolgreich, wenn Fachbereich und Data Team dieselben Konzepte gleich verstehen und bei Konflikten wissen, wer entscheidet. Wie du eines aufbaust, beschreibt der Leitfaden Business Glossary erstellen.
Was ist ein Data Catalog?
Ein Data Catalog inventarisiert Datenobjekte über Systeme hinweg. Dazu können Datenbanken, Tabellen, Dateien, semantische Modelle, Datenprodukte und Berichte gehören.
Ein Catalog beantwortet Fragen wie:
- Wo finde ich Daten zu Kundenverträgen?
- Wer verantwortet dieses Modell?
- Welche Quelle speist die Tabelle?
- Welche weiteren Assets hängen davon ab?
- Wie sensibel oder aktuell ist der Datenbestand?
Viele Data Catalogs bieten zusätzlich Glossar- oder Dictionary-Funktionen. Entscheidend ist, ob fachliche und technische Metadaten wirklich verknüpft oder nur nebeneinander angezeigt werden.
Was ist ein Data Dictionary?
Ein Data Dictionary beschreibt die technische Struktur eines konkreten Datenbestands. Es enthält zum Beispiel:
- Tabellen- und Spaltennamen,
- Datentypen und erlaubte Werte,
- Primär- und Fremdschlüssel,
- Nullability und Constraints,
- technische Beschreibungen,
- Schema- und Modellbeziehungen.
Ein Dictionary kann direkt aus einem Schema erzeugt oder manuell ergänzt werden. Es ist besonders nützlich für Implementierung, Datenmodellierung und Fehleranalyse.
Ein Begriff durch alle drei Ebenen
Nehmen wir „aktiver Kunde“ als Beispiel.
Im Business Glossary steht beispielsweise: Ein Kunde gilt am Monatsende als aktiv, wenn zu diesem Zeitpunkt mindestens ein bezahlter Vertrag läuft; Testkonten sind ausgeschlossen. Dies ist eine fiktive Stichtagsdefinition, keine allgemeingültige Regel.
Im Data Catalog sind das CRM-System, das Vertragsmodell, die verantwortlichen Teams und abhängige Datenprodukte auffindbar.
Im Data Dictionary steht, dass contract.status die Werte active, trial, cancelled und expired annehmen kann und wie contract.customer_id mit der Kundentabelle verbunden ist.
Der technische Status active allein genügt dafür nicht. Für die Stichtagsregel werden zusätzlich Laufzeit, bezahlter Vertragsstatus und Kundenidentität benötigt. Die Verbindung der Ebenen zeigt also auch, welche Felder oder Regeln noch fehlen.
Was ändert sich, wenn die Definition geändert wird?
Soll künftig jeder Kunde mit mindestens einem aktiven Tag im Monat zählen, bleibt der Datentyp des Statusfeldes gleich. Trotzdem ändert sich die fachliche Aussage. Im Glossar werden Definition und Gültigkeit angepasst; über die verknüpften Assets lassen sich betroffene Kennzahlen und Berichte ermitteln. Im Dictionary müssen nur tatsächlich geänderte Strukturen oder technische Regeln nachgezogen werden.
Umgekehrt verändert eine Umbenennung von status in contract_status zunächst die technische Beschreibung. Sie ist kein Grund, die fachliche Definition neu zu erfinden. Diese Trennung hält die Dokumentation wartbar.
Wann reicht eine der drei Lösungen?
Nur ein Business Glossary
Ein Glossar kann zunächst reichen, wenn das Hauptproblem uneinheitliche Fachsprache ist und die technische Landschaft überschaubar bleibt. Das gilt etwa für einen einzelnen BI-Bereich mit wenigen stabilen Modellen.
Nur ein Data Dictionary
Ein Dictionary reicht für ein technisches Projekt, wenn Entwickler ein klar abgegrenztes Schema verstehen müssen und keine bereichsübergreifenden Begriffsfragen bestehen.
Nur ein Data Catalog
Ein Catalog kann als erster Schritt genügen, wenn das größte Problem Auffindbarkeit und Ownership vieler Datenobjekte ist. Fachliche Definitionen sollten trotzdem folgen, sobald Nutzer Daten unterschiedlich interpretieren.
Wann braucht ein Team zwei Lösungen?
Business Glossary plus Data Dictionary eignet sich für BI-Teams, die fachliche Definitionen direkt mit einem überschaubaren Datenmodell verbinden wollen.
Business Glossary plus Data Catalog ist sinnvoll, wenn viele Fachdomänen und Systeme eine gemeinsame Sprache sowie einen auffindbaren Asset-Bestand benötigen.
Data Catalog plus Data Dictionary unterstützt technische Discovery und Implementierung, löst aber nicht automatisch fachliche Bedeutungsunterschiede.
Wann sind alle drei erforderlich?
Alle drei Ebenen sind sinnvoll, wenn:
- mehrere Fachbereiche dieselben Daten nutzen,
- viele Systeme und Datenprodukte existieren,
- regulatorische oder Governance-Anforderungen gelten,
- Lineage und Auswirkungsanalysen wichtig sind,
- neue Nutzer Daten selbstständig finden und verstehen sollen.
Die Umsetzung muss nicht mit drei getrennten Tools erfolgen. Eine Plattform kann mehrere Ebenen abbilden. Das fachliche Modell sollte aber klar zwischen Term, Asset und technischem Feld unterscheiden.
Wo sich MetricsMap einordnet
MetricsMap deckt vor allem die fachliche Ebene ab: ein Business Glossary aus Fachbegriffen und Kennzahlen mit Definition, Synonymen, Owner und Status. Fachbegriffe und das KPI-Glossar sind dabei eigenständige, aber verknüpfbare Einträge. Ergänzend dokumentiert MetricsMap Datenmodelle mit Tabellen, Feldern und Beziehungen und verbindet beide Ebenen über stabile Referenzen – fachliche Bedeutung und ein leichtgewichtiges Data Dictionary in einem Werkzeug.
Kein Schwerpunkt ist der breite, automatisierte Data Catalog über viele Systeme hinweg. MetricsMap erfasst Metadaten manuell und fokussiert Bedeutung, Verantwortung und Nachvollziehbarkeit von Kennzahlen, statt die technische Discovery ganzer Datenlandschaften abzubilden.
Ein Werkzeug anhand einer echten Frage prüfen
Nutze für einen Vergleich denselben Anwendungsfall: „Welche Definition aktiver Kunden verwendet unser Monatsbericht?“ Prüfe, ob du vom Begriff zur Kennzahl, zu ihren Quellfeldern und zum verantwortlichen Team gelangst. Eine lange Funktionsliste sagt wenig darüber aus, ob diese Verbindung im Alltag funktioniert.
Halte pro Ebene außerdem fest, wo die verbindliche Information gepflegt wird. Wenn die Definition im Glossar geführt wird, sollte das Dictionary darauf verweisen, statt einen zweiten unabhängig gepflegten Definitionstext zu enthalten. Automatisch ausgelesene Datentypen und manuell formulierte Geschäftsregeln haben unterschiedliche Pflegeprozesse.
Entscheidungshilfe für Teams
Beantworte diese Fragen:
- Streiten Teams vor allem über die Bedeutung von Begriffen? Dann priorisiere das Business Glossary.
- Finden Nutzer vorhandene Datenquellen und Modelle nicht? Dann priorisiere Catalog-Funktionen.
- Fehlen Beschreibungen von Tabellen, Feldern und Schlüsseln? Dann beginne mit dem Data Dictionary.
- Sind KPI-Formeln und Verantwortliche unklar? Dann starte mit einem KPI-Glossar.
- Müssen Änderungen bis zu Reports oder Datenprodukten nachvollziehbar sein? Dann braucht ihr verknüpfte Assets und Lineage.
- Sind mehrere Probleme gleichzeitig kritisch? Definiere ein gemeinsames Metadatenmodell, aber rolle es domänenweise aus.
Typische Fehlentscheidungen
Ein Toolkauf ersetzt die Begriffsklärung
Automatisch erkannte Tabellen liefern noch keine fachliche Definition. Owner und Domänen müssen Bedeutungen aktiv entscheiden.
Das Glossar wird aus Spaltennamen erzeugt
Technische Namen können Kandidaten liefern, sind aber keine verlässlichen Business Terms. cust_actv_flg erklärt weder Regel noch Ausnahme.
Der Catalog bleibt ein technisches Inventar
Wenn Fachanwender nur Schemanamen sehen, verbessert sich ihre Datenkompetenz kaum. Fachliche Definitionen und verständliche Beziehungen sind nötig.
Das Dictionary soll Governance lösen
Datentypen und Schlüssel sind wichtig, beantworten aber nicht, ob eine Kennzahl zertifiziert oder wer fachlich verantwortlich ist.
Häufige Fragen
Ist ein Business Glossary Teil eines Data Catalogs?
Oft ja, weil Plattformen beide Funktionen anbieten. Konzeptionell bleibt das Glossary die fachliche Ebene und der Catalog das Inventar der Datenassets.
Ist ein Data Dictionary automatisch aktuell?
Nur wenn es aus dem technischen Schema erzeugt und regelmäßig synchronisiert wird. Manuelle Beschreibungen und fachliche Erläuterungen brauchen weiterhin Pflege.
Wo gehören KPIs hin?
KPIs gehören in ein spezialisiertes Glossar mit Definition, Formel, Einheit, Owner und Status. Ihre technischen Quellen sollten mit Catalog- oder Dictionary-Objekten verknüpft werden.
Muss ein kleines BI-Team alle drei aufbauen?
Nein. Beginne beim größten Schmerz. Häufig liefert ein KPI-Glossar mit dokumentierten Datenmodellen den schnellsten Nutzen und schafft eine Basis für den späteren Ausbau.
Fazit
Business Glossary, Data Catalog und Data Dictionary sind keine austauschbaren Begriffe. Sie verbinden fachliche Bedeutung, organisatorische Auffindbarkeit und technische Struktur. Entscheidet zuerst, welche Fragen heute unbeantwortet bleiben, und baut anschließend Beziehungen zwischen den Ebenen auf.