Ein Spaltenname ist keine Definition

Einordnung im Metadaten-Pfad

Diese Serie ist nicht der allgemeine Metadaten-Einstieg. Dafür ist Was Metadaten wirklich sind besser. Hier geht es um die härtere Frage: Wann erzählt ein Metadatum die Wahrheit über ein Datenobjekt?

Lies diese Serie, wenn Spaltennamen, Katalogtexte oder Dashboardtitel zwar vorhanden sind, aber die eigentliche Entscheidung offen bleibt. Danach passt Metadata Quality Ops, wenn diese Aussagen dauerhaft gepflegt, gemessen und betrieben werden müssen.

Begriffe vor dem Lesen

• Metadata — Daten über Daten: Definition, verantwortliche Person, Quelle, Lineage, Qualität, Klassifikation und Nutzungskontext.
• Definition — Fachliche Bedeutung eines Feldes, Begriffs oder einer Kennzahl, inklusive Umfang und verantwortliche Person.
• fachliche Zählebene / Körnung — Die Einheit einer Aussage, zum Beispiel eine Bestellung, eine Position, ein Kunde oder ein Snapshot.
• Lineage — Nachvollziehbare Herkunft und Weitergabe von Daten über Quellen, Transformationen und Nutzung hinweg.
• Nachweis — Nachweis, welche Definition, Version, Quelle oder Regel eine Aussage trägt.

Ausgangslage

customer_id, revenue, status und created_at wirken selbsterklärend. Das sind sie nicht. Ein Name ist zunächst nur ein technischer Hinweis. Er sagt weder, welches fachliche Konzept gemeint ist, noch auf welcher Ebene ein Datensatz gilt. Er erklärt nicht, welche Personen oder Vorgänge fehlen, welcher Zeitpunkt maßgeblich ist, wer die Aussage verantwortet oder für welche Entscheidung sie verwendet werden darf.

Diese Lücke bleibt oft unsichtbar, solange Erzeuger und Nutzende dieselben stillen Annahmen teilen. Sie wird sichtbar, sobald ein Team wechselt, eine Kennzahl in einem anderen Bericht wiederverwendet oder ein Datenbestand mit einer zweiten Quelle verbunden wird. Dann können zwei technisch korrekte Abfragen zu widersprüchlichen Ergebnissen führen. Beide zählen customer_id; die eine zählt Vertragsparteien, die andere Rechnungsempfänger. Beide summieren revenue; die eine nutzt gebuchte, die andere fakturierte Beträge. Der Fehler liegt nicht im SQL, im Dashboard oder im Catalog. Er liegt in einer unvollständigen Behauptung über die Daten.

Eine Definition ist deshalb kein schöner Beschreibungstext. Sie ist eine kompakte Nutzungsvereinbarung. Sie verbindet fachliche Bedeutung, Abgrenzung, Verantwortung und bekannte Unsicherheit so, dass ein Nutzende eine Verwendung prüfen kann, bevor er Ergebnisse veröffentlicht.

Leitentscheidung

Ein Asset oder Feld gilt erst dann als definiert, wenn mindestens sieben Fragen beantwortet sind:

1. Zweck: Welche fachliche Frage unterstützt es?
2. Fachliche Zählebene: Wofür steht genau eine Zeile oder ein Wert?
3. Population: Welche Objekte, Ereignisse oder Zeiträume sind enthalten und ausgeschlossen?
4. Zeitbezug: Welcher Geschäftszeitpunkt, welches Intervall und welche Zeitzone gelten?
5. Verantwortung: Wer entscheidet verbindlich über Bedeutung und zulässige Änderung?
6. Erlaubte Nutzung: Für welche Entscheidungen ist die Aussage geeignet oder ausdrücklich nicht geeignet?
7. Bekannte Grenzen: Welche Lücken, Näherungen, Verzögerungen und Sonderfälle muss ein Nutzende berücksichtigen?

Diese Felder sind stackneutral. Sie können in einem Datenvertrag, einem Schema-Dokument, einem BI-Modell, einem Wiki, einem Catalog oder neben Transformationscode stehen. Entscheidend ist nicht der Speicherort, sondern dass dieselbe Aussage auffindbar, prüfbar und einer verantwortlichen Rolle zugeordnet ist.

Definitionen beschreiben eine Entscheidung, nicht nur ein Substantiv

„Umsatz des Kunden“ klingt wie eine Definition, benennt aber nur zwei Begriffe. Eine belastbare Definition beschreibt, welche Entscheidung mit dem Wert getroffen werden kann. Zum Beispiel:

Nettowarenwert bestätigter Bestellpositionen nach handelsüblichem Rabatt, ohne Steuer, Versand, Storno und Rückerstattung; dem Rechnungsempfänger zugeordnet; in Konzernwährung zum Buchungskurs des Bestelldatums. Geeignet für tägliche Vertriebssteuerung, nicht für den testierten Finanzabschluss.

Diese Formulierung macht mehrere Konflikte sichtbar: Brutto oder netto, Bestellung oder Rechnung, Kunde oder Rechnungsempfänger, Tageskurs oder Buchungskurs, operative oder bilanzielle Nutzung. Eine Definition muss nicht jede Transformationszeile wiedergeben. Sie muss die fachlich relevanten Entscheidungen offenlegen.

Ein guter Test lautet: Könnten zwei sachkundige Personen mit dieser Definition unabhängig dieselbe Ein- und Ausschlusslogik entwerfen? Falls nein, fehlen entscheidende Grenzen. Falls die Definition nur mit Blick in Code verständlich wird, ist der Code die faktische, aber schwer zugängliche Spezifikation.

Zweck setzt den Rahmen

Der Zweck beantwortet nicht „Was ist dieses Feld?“, sondern „Warum existiert diese Aussage?“. Derselbe Quellwert kann für verschiedene Zwecke unterschiedlich behandelt werden. Eine Lieferzeit für operative Disposition kann laufend aktualisiert werden. Für Lieferzuverlässigkeit muss dagegen möglicherweise der zum Bestellzeitpunkt zugesagte Termin eingefroren werden.

Formuliere den Zweck als unterstützte Entscheidung:

• „Priorisierung offener Servicefälle im täglichen Betrieb“
• „Monatliche Bewertung aktiver Abonnements“
• „Segmentierung für freigegebene Bestandskundenkommunikation“
• „Abstimmung fakturierter Erlöse mit dem Hauptbuch“

Vermeide kreisförmige Aussagen wie „für Reporting“, „für Analytics“ oder „zur Analyse“. Sie verschieben die Frage nur. Ein klarer Zweck begrenzt außerdem die Erwartung: Ein Datensatz für tägliche Tendenzen muss nicht automatisch für regulatorische Meldungen geeignet sein.

Die fachliche Zählebene verhindert falsches Zählen

Die fachliche Zählebene beschreibt die kleinste Einheit, die eine Zeile repräsentiert. Sie ist präziser als ein Primärschlüssel. Ein zusammengesetzter technischer Schlüssel kann eindeutig sein, ohne zu erklären, ob eine Zeile einen Zustand, ein Ereignis, eine Version oder eine Zuordnung darstellt.

Nützliche Formulierungen sind:

• „eine Zeile je Bestellposition in der aktuell bekannten Version“
• „eine Zeile je Konto und Kalendertag, einschließlich Tage ohne Bewegung“
• „ein Ereignis je tatsächlichem Statuswechsel; technische Wiederholungen entfernt“
• „eine Zeile je Mitarbeiter-Vertragsverhältnis und Gültigkeitsintervall“

Dokumentiere auch, wodurch mehrere Zeilen für dasselbe fachliche Objekt entstehen: Währung, Standort, Kanal, Version, Snapshot-Datum oder Gültigkeitsintervall. Sonst summiert eine Nutzerin Werte über eine Dimension, die eigentlich Teil der Zählebene ist, und erzeugt Doppelzählungen.

Auf Feldebene muss klar sein, auf welche Zählebene sich ein Wert bezieht. customer_status kann der aktuelle Status des Kunden, der Status beim Auftrag oder der täglich historisierte Status sein. Datentyp und Feldname unterscheiden diese Varianten nicht.

Population macht den Nenner sichtbar

Population beschreibt die Menge, über die eine Aussage gilt. Dazu gehören Einschluss, Ausschluss und Abdeckung. „Alle Kunden“ kann nur aktive Vertragspartner, auch Interessenten, gelöschte Profile, Gastkäufer oder zusammengeführte Dubletten meinen.

Eine brauchbare Populationsbeschreibung nennt:

• fachliches Objekt oder Ereignis,
• einschließende Kriterien,
• ausschließende Kriterien,
• räumliche und organisatorische Grenzen,
• frühestes verlässlich verfügbares Datum,
• bekannte Lücken oder Übergangsphasen.

Beispiel: „Enthält bestätigte B2C-Bestellungen der europäischen Shops ab 2023-01-01. Testshops, interne Bestellungen und vor Bestätigung abgebrochene Warenkörbe sind ausgeschlossen. Rückwirkend importierte Gastbestellungen vor 2024 enthalten keine stabile Kundenreferenz.“

Population ist nicht dasselbe wie ein aktueller Filter. Sie beschreibt die konzeptionelle Grundgesamtheit des Assets. Ein Dashboard-Filter wählt daraus eine Teilmenge. Wenn diese Ebenen vermischt werden, bleibt unklar, ob fehlende Datensätze absichtlich ausgeschlossen wurden oder technisch nie ankamen.

Zeit ist mehr als ein Timestamp

Jedes entscheidungsrelevante Datum braucht eine Rolle. Typische Rollen sind Ereigniszeit, Wirksamkeitsbeginn, Buchungszeit, Quelländerungszeit, Ladezeit und Berichtsperiode. Ein Feld namens created_at verrät nicht, welches System etwas erzeugte und ob spätere Korrekturen rückwirkend gelten.

Eine Zeitdefinition hält fest:

• welches Ereignis der Zeitpunkt bezeichnet,
• ob der Wert fachlich oder technisch erzeugt wurde,
• verwendete Zeitzone und Kalenderregeln,
• Präzision und Rundung,
• Umgang mit verspäteten Ereignissen und Korrekturen,
• ob Auswertungen den aktuellen oder historisch bekannten Stand zeigen.

Beispiel: „order_date ist der Zeitpunkt der erfolgreichen Bestellbestätigung in der Zeitzone des Shops. Tageszuordnung erfolgt vor Umrechnung nach UTC. Nachträgliche Migrationen behalten das ursprüngliche Bestelldatum; die technische Importzeit steht separat.“

Für Intervalle müssen Start- und Endsemantik explizit sein. [valid_from, valid_to) verhindert Überlappungen anders als beidseitig inklusive Grenzen. Für Snapshots muss der Stichtag erklären, ob er Tagesanfang, Tagesende oder den letzten erfolgreichen Lauf repräsentiert.

Verantwortung bedeutet Entscheidungsrecht

Eine verantwortliche Person ist nicht automatisch die Person, die eine Pipeline betreibt. Technische Betreuung, fachliche Verantwortung und Datenschutzfreigabe können bei verschiedenen Rollen liegen. Für die Definition braucht es eine Rolle, die Konflikte über Bedeutung, Population und zulässige Verwendung entscheidet.

Dokumentiere möglichst eine stabile Gruppe oder Funktion statt einer einzelnen Person. Ergänze einen Kontaktweg und einen Eskalationspfad. Für operative Fragen kann ein Steward oder Maintainer zuständig sein; das Entscheidungsrecht bleibt dennoch eindeutig.

Eine hilfreiche Trennung ist:

• Business Owner: entscheidet Bedeutung, Zweck und fachliche Änderungen,
• Data Steward: pflegt Kontext, koordiniert Review und beantwortet Nutzungsfragen,
• Data technischer Betreiber: verantwortet Bereitstellung, Lauf und technische Verträge,
• verantwortliche Person aus Risk oder Privacy: entscheidet spezielle rechtliche oder sicherheitsbezogene Nutzung.

Nicht jedes Asset braucht vier verschiedene Namen. Es braucht jedoch Klarheit darüber, welche Rolle welche Frage entscheidet. „Team Data“ ohne Mandat ist kein belastbares Verantwortung-Modell.

Erlaubte Nutzung ist Teil der Wahrheit

Technisch verfügbar bedeutet nicht fachlich oder rechtlich geeignet. Eine Definition muss deshalb positive und negative Nutzungshinweise enthalten. „Für interne Analyse“ ist zu breit. Besser sind konkrete Entscheidungsklassen und Bedingungen.

Beispiele:

• geeignet für aggregierte wöchentliche Kapazitätsplanung,
• nur nach regionaler Aggregation für externe Kommunikation,
• nicht für individuelle Leistungsbewertung,
• nicht als alleinige Grundlage für Kredit-, Preis- oder Zugangsentscheidungen,
• vor Monatsabschluss vorläufig; danach für Management-Reporting freigegeben,
• nur gemeinsam mit dem dokumentierten Ausschluss von Testkonten verwenden.

Diese Hinweise ersetzen keine Plattformberechtigungen oder rechtliche Prüfung. Sie machen aber die fachliche Nutzungsgrenze sichtbar, bevor ein Nutzende aus Zugriffsrecht eine Freigabe ableitet. Durchsetzung und Beschreibung sind zwei verschiedene Kontrollen, die sich ergänzen.

Grenzen dokumentieren, ohne Vertrauen zu zerstören

Bekannte Grenzen sind kein Makel. Verschweigen erzeugt falsches Vertrauen; pauschale Warnungen machen ein Asset unbrauchbar. Eine gute Grenze ist konkret, bewertbar und mit einem Umgang versehen.

Statt „Datenqualität eingeschränkt“ schreibe: „Etwa 6–9 % der Gastbestellungen besitzen keine stabile Kunden-ID; Umsatzanalysen sind vollständig, kundenbezogene Wiederkaufraten unterschätzen diese Population. Quote wird monatlich geprüft.“ Die Aussage nennt Umfang, Auswirkung und Review.

Typische Kategorien sind:

• fehlende Populationen oder Attribute,
• Mess- und Zuordnungsfehler,
• verspätete oder rückwirkende Änderungen,
• Schätzungen, Imputationen und Modellwerte,
• historische Definitionswechsel,
• manuelle Korrekturen,
• nicht unterstützte Detailgrade,
• Abhängigkeit von einer Quelle ohne vollständige Kontrolle.

Eine Grenze sollte nicht mit einer Roadmap verwechselt werden. Manche Grenzen sind dauerhaft akzeptiert. Kennzeichne, ob eine Einschränkung akzeptiert, in Behebung, zeitlich befristet oder noch zu entscheiden ist.

Definition auf Asset- und Feldebene

Asset-Metadaten erklären gemeinsamen Zweck, Bezugs- und Detailebene, Population, Zeitmodell, Owner und Nutzungsrahmen. Feld-Metadaten erklären die Bedeutung eines einzelnen Attributs innerhalb dieses Rahmens. Wiederhole nicht den gesamten Asset-Kontext an jeder Spalte. Verweise auf ihn und dokumentiere nur feldspezifische Abweichungen.

Für ein Feld sind mindestens relevant:

• fachlicher Begriff und präzise Bedeutung,
• Einheit, Skala oder Format,
• Bezug zum fachliche Zählebene,
• zulässige und besondere Werte,
• Null-Semantik,
• Herleitung oder maßgebliche Quelle,
• feldspezifische Nutzungsgrenze.

Beispiel: net_amount — „Nettowarenwert dieser Bestellposition nach Positionsrabatt, vor Steuer und Versand, in currency_code; negative Werte stehen ausschließlich für bestätigte Gutschriften.“ Damit werden Einheit, Bezugs- und Detailebene und Ausnahme verbunden.

Beispiele als Tests, nicht als Ersatz

Beispiele helfen, Grenzfälle zu verstehen. Sie dürfen eine Definition aber nicht ersetzen. „A = aktiv, I = inaktiv“ erklärt weder, wann der Wechsel erfolgt, noch ob ein reaktivierter Datensatz wieder A erhält. Ergänze typische, negative und Grenzbeispiele.

Ein robustes Set enthält:

• einen normalen zulässigen Fall,
• einen Fall, der ähnlich aussieht, aber ausgeschlossen ist,
• einen Grenzfall an Zeit- oder Populationsgrenzen,
• einen bekannten Ausnahmefall,
• falls sinnvoll ein Gegenbeispiel für unzulässige Nutzung.

Beispiele werden besonders wertvoll, wenn sie als Akzeptanzfälle für Transformationen, semantische Modelle oder Datenqualitätsregeln wiederverwendet werden. Dennoch bleibt die fachliche Aussage führend. Ein einzelnes Sample beweist keine allgemeine Bedeutung.

Definitionen ändern sich kontrolliert

Eine geänderte Definition kann bestehende Berichte brechen, selbst wenn das Schema identisch bleibt. Behandle deshalb semantische Änderungen wie Vertragsänderungen. Dokumentiere alten und neuen Wortlaut, Grund, Wirksamkeitsdatum, betroffene Population, erwartete Auswirkung und verantwortliche Freigabe.

Änderungen an Rechtschreibung oder Kontaktwegen sind nicht gleichbedeutend mit einer neuen Semantik. Dagegen sind neue Ausschlüsse, ein anderer Bezugs- und Detailebene, eine geänderte Zeitbasis oder eine neue erlaubte Nutzung materiell. Nutzende brauchen für solche Änderungen Vorlauf oder eine versionierte Alternative.

Ein Review-Datum bedeutet nicht, dass eine Definition dann abläuft. Es ist der Termin, an dem Owner und Steward prüfen, ob Zweck, Grenzen und Nutzungsrahmen noch stimmen. Ereignisse wie Quellmigration, Organisationsänderung oder neue Regulierung können ein früheres Review auslösen.

Hilfe

Beginne nicht mit allen Spalten. Wähle ein häufig wiederverwendetes Asset und drei entscheidungsrelevante Felder. Bitte einen Nutzende, ohne Code zu erklären, was eine Zeile bedeutet, wer enthalten ist und welcher Zeitpunkt gilt. Jede unterschiedliche Antwort zeigt ein fehlendes Metadatum.

Nutze anschließend ein kurzes Review mit Business Owner, technischer Betreuung und einem tatsächlichen Nutzende. Der Owner bestätigt Bedeutung und Nutzung, die technische Rolle prüft die Übereinstimmung mit der Bereitstellung, der Nutzende testet Verständlichkeit. Wo keine Einigung möglich ist, dokumentiere die offene Entscheidung sichtbar statt einen scheinbar präzisen Text zu erfinden.

Formuliere knapp, aber nicht kryptisch. Kontrollierte Felder eignen sich für wiederkehrende Kategorien; Freitext erklärt fachliche Besonderheiten. Automatisch erkannte Typen, Lineage oder Profile sind Evidenz, aber keine autoritative Definition. Generierte Vorschläge müssen als Entwurf gekennzeichnet und fachlich bestätigt werden.

Checkliste

• Der Zweck benennt eine konkrete Entscheidung oder einen Arbeitsprozess.
• Der fachliche Zählebene erklärt exakt, wofür eine Zeile oder ein Wert steht.
• Einschluss, Ausschluss und historische Abdeckung der Grundgesamtheit sind sichtbar.
• Geschäftszeit, Ladezeit, Zeitzone und Korrekturverhalten sind unterscheidbar.
• Eine benannte Rolle besitzt das fachliche Entscheidungsrecht.
• Erlaubte und untersagte Nutzungen sind konkret formuliert.
• Grenzen nennen Auswirkung, Größenordnung und Umgang.
• Felddefinitionen ergänzen den Asset-Kontext, statt ihn widersprüchlich zu kopieren.
• Einheiten, Null-Bedeutung und besondere Werte sind erklärt.
• Beispiele decken Normalfall, Ausschluss und Grenzfall ab.
• Materielle Definitionsänderungen werden versioniert und kommuniziert.
• Ein Review-Termin oder Review-Auslöser ist festgelegt.

Artefakt

Das folgende stackneutrale Template kann als YAML, Formular, Tabelle, Datenvertrag oder Catalog-Feldgruppe abgebildet werden:

• asset_name: stabiler fachlicher oder technischer Bezeichner
• definition: präzise fachliche Aussage
• purpose: unterstützte Entscheidung oder Prozess
• grain: eine Zeile je …
• population_included: explizit enthaltene Menge
• population_excluded: explizit ausgeschlossene Menge
• coverage: Region, Organisation und historischer Zeitraum
• business_time: maßgeblicher fachlicher Zeitpunkt oder Zeitraum
• system_time: Lade-, Änderungs- oder Beobachtungszeit
• timezone_calendar: Zeitzone, Geschäftskalender und Intervallgrenzen
• business_owner: Rolle mit fachlichem Entscheidungsrecht
• steward_contact: Pflege- und Rückfragekanal
• technical_owner: Verantwortung für Bereitstellung
• permitted_uses: freigegebene Entscheidungsklassen
• prohibited_uses: nicht geeignete oder untersagte Verwendungen
• known_limitations: Einschränkung, Auswirkung, Umfang und Umgang
• examples: Normalfall, Gegenbeispiel und Grenzfall
• effective_from: fachlicher Beginn dieser Definition
• review_due: nächster Review oder auslösendes Ereignis
• evidence_links: Regeln, Tests, Lineage oder Freigaben

Für ein Feld ergänze:

• field_name
• business_term
• field_definition
• unit_or_format
• value_domain
• null_meaning
• derivation_or_source
• field_level_limitations

Tools

Die Felder bleiben unabhängig vom Zielsystem. Optional kann der /tools/schema-yml-editor das Artefakt als portables Schema strukturieren. Der /tools/meta-export-generator hilft, vorhandene technische Metadaten als Ausgangspunkt zu exportieren; sie ersetzen nicht die fachliche Bestätigung. Für Kennzahlen kann der /tools/kpi-definition Zweck, Bezugs- und Detailebene, Population und Zeitlogik in eine Metrikdefinition übertragen. Begriffe und Verantwortlichkeiten lassen sich mit dem /tools/openmetadata-glossary-generator in ein importierbares Glossarformat abbilden; die Prinzipien gelten ebenso für andere Catalogs oder Dokumentationssysteme.