Von Erwartungen zu Regeln

Begriffe vor dem Lesen

• Data Quality / DQ — Eignung von Daten für einen konkreten Zweck, nicht ein allgemeiner Schönheitswert.
• Regel — Prüfbare Erwartung an Daten mit Umfang, verantwortliche Person, Schwelle und Konsequenz.
• Quality Prüfpunkt — Entscheidungspunkt, der Daten nur bei erfüllter Erwartung weitergibt oder veröffentlicht.
• Vereinbarung / Vertrag — Vereinbarung zwischen Anbieter und Nutzer über Bedeutung, Qualität, Aktualität und Änderung.
• Incident — Vorfall, bei dem eine vereinbarte Erwartung verletzt wurde und daraus gelernt werden muss.

Ausgangslage

Nach der Definition von Zweck, Grain und Population folgt häufig der nächste Kurzschluss: Das Team sammelt möglichst viele Tests. Jede Spalte erhält not_null, jeder vermutete Schlüssel unique, einige Zahlen bekommen Min-/Max-Grenzen, und ein Generator produziert weitere Regeln. Die Anzahl der Checks wächst, aber ihre Aussagekraft bleibt unklar.

Dieser Testzoo entsteht stackübergreifend. In Snowflake oder BigQuery liegen ähnliche SQL-Prüfungen in mehreren Repositories. Fabric- und Databricks-Notebooks enthalten harte Grenzwerte ohne Owner. dbt-Tests, Great-Expectations-Suites und Soda-Checks prüfen dieselbe Erwartung unterschiedlich. Airflow meldet einen Task als fehlgeschlagen, obwohl die Daten noch nutzbar wären. Ein Catalog zeigt rote Badges, ohne zu erklären, welche Entscheidung betroffen ist.

Die Ursache ist selten mangelnde Technik. Zwischen einer Consumer-Erwartung und ausführbarem Code fehlen strukturierte Entscheidungen:

• Worauf gilt die Erwartung genau?
• Welche Grundgesamtheit und welches Zeitfenster werden geprüft?
• Ist eine einzelne Verletzung kritisch oder erst ein Anteil?
• Wer verantwortet die Regel und wer behebt die Ursache?
• Soll die Verarbeitung blockieren, warnen oder nur Evidenz sammeln?
• Welche Ausnahmen sind fachlich erlaubt?
• Wann muss die Regel überprüft werden?

Ohne diese Angaben ist ein fehlgeschlagener Test nur ein Signal. Er sagt weder, ob Umsatz falsch ist, noch ob ein Dashboard abgeschaltet werden soll.

Leitentscheidung

Übersetze jede relevante Consumer-Erwartung in eine versionierte Qualitätsregel mit mindestens Behauptung, Scope, Messung, Schwelle, Schweregrad, Owner und Reaktion. Implementiere erst danach den Check im gewählten Stack.

Eine Erwartung beschreibt die benötigte Eigenschaft in Geschäftssprache: „Jede umsatzwirksame Auftragsposition besitzt eine Währung.“ Die Regel macht sie entscheidbar: „Für produktive B2C-Positionen mit revenue_relevant = true und Buchungsdatum ab 2025-01-01 muss currency_code in 100 Prozent der Fälle gefüllt und ISO-4217-konform sein; Verletzung blockiert die tägliche Revenue-Veröffentlichung; Owner ist Revenue Operations.“

Der ausführbare Test ist nur ein Adapter dieser Regel. Er kann in SQL, dbt, Spark, Great Expectations, Soda, einer Warehouse-Constraint oder einem nativen DQ-Dienst laufen. Die fachliche Regel bleibt stabil, wenn das Tool wechselt.

Von der Aussage zur ausführbaren Regel

1. Erwartung in beobachtbarer Sprache formulieren

Beginne mit dem Consumer, nicht mit einer Testfunktion. Gute Erwartungen verbinden Objekt, Bedingung und Bedeutung:

• „Jede veröffentlichte Rechnung lässt sich einem existierenden Auftrag zuordnen.“
• „Der Tagesbestand enthält alle aktiven Filialen bis 07:00 Uhr lokaler Zeit.“
• „Stornierte Positionen tragen nicht zum gebuchten Nettoumsatz bei.“
• „Kundensegmente verwenden ausschließlich die freigegebene Klassifikation.“

„Daten sollen korrekt und vollständig sein“ ist nicht prüfbar. „Spalte darf nicht null sein“ ist zwar prüfbar, aber ohne fachliche Bedingung oft falsch. Die Erwartung muss zwischen beiden Ebenen liegen: fachlich verständlich und grundsätzlich beobachtbar.

2. Scope präzisieren

Scope beantwortet wo, wann und für wen die Regel gilt. Dazu gehören Asset und Version, Spalten oder Entitäten, Population, Ausschlüsse, Zeitfenster, Region, Mandant und gegebenenfalls Verarbeitungsstufe.

Ein Nullverbot für customer_id könnte nur für registrierte B2B-Aufträge gelten, nicht für Gastbestellungen. Eine Freshness-Regel könnte werktags gelten, aber nicht an regionalen Feiertagen. Eine Reconciliation kann nur abgeschlossene Buchungsperioden betreffen. Scope ist keine lästige SQL-Klausel, sondern Teil der fachlichen Aussage.

Unterschiedliche Scopes sollten getrennte Regeln erhalten, wenn Owner, Schweregrad oder Reaktion abweichen. Eine komplexe Regel mit vielen Ausnahmen ist schwerer zu erklären und zu betreiben als zwei klare Regeln.

3. Messgröße und Nenner festlegen

Jede Regel braucht eine eindeutige Metrik. Bei Vollständigkeit kann das die Anzahl verletzender Zeilen, der Anteil gültiger Werte oder die Abdeckung erwarteter Entitäten sein. Bei Freshness kann es die Differenz zwischen erwarteter und letzter fachlicher Ereigniszeit sein. Bei Reconciliation ist es absolute oder relative Abweichung zwischen zwei definierten Summen.

Besonders wichtig ist der Nenner. „99 Prozent vollständig“ klingt präzise, aber 99 Prozent von welcher Population? Werden stornierte Datensätze, technische Duplikate oder verspätete Quellen mitgezählt? Bei kleinen Populationen können Prozentwerte täuschen; bei großen Populationen kann ein kleiner Prozentsatz erhebliche Schäden bedeuten. Speichere daher Anteil und absolute Zahl.

4. Schwelle aus Risiko ableiten

Nicht jede Regel verlangt 100 Prozent. Identifikatoren für gebuchte Finanztransaktionen können strikt sein; optionale Marketingattribute nicht. Eine Toleranz ist aber keine beliebige Zahl aus historischem Verhalten. Sie braucht eine fachliche Begründung.

Geeignete Grundlagen sind Entscheidungswirkung, regulatorische Pflicht, Kosten einer Fehlentscheidung, natürliche Prozessvarianz und Zeit bis zur Korrektur. Historische Profile helfen bei der Kalibrierung, definieren aber nicht automatisch Akzeptanz. Wenn bisher fünf Prozent der Länder fehlen, macht das fünf Prozent nicht zulässig.

Nutze gegebenenfalls zwei Schwellen: Warnung bei beginnender Verschlechterung und Fehler bei nicht mehr akzeptabler Nutzung. Dokumentiere Richtung, Einheit, Aggregation und Mindestpopulation.

5. Schweregrad und Reaktion trennen

Schweregrad beschreibt die Geschäftsauswirkung; Reaktion beschreibt die operative Handlung. „Kritisch“ muss nicht immer einen Pipeline-Abbruch bedeuten. Ein Abbruch kann bei einer nachgelagerten regulatorischen Datei richtig sein, bei einem Rohdaten-Load aber Beweise vernichten oder die Wiederherstellung erschweren.

Typische Reaktionen sind:

• Beobachten: Ergebnis speichern, noch ohne Benachrichtigung.
• Warnen: Owner und betroffene Nutzer informieren.
• Kennzeichnen: Asset oder Partition als eingeschränkt nutzbar markieren.
• Degradieren: Fallback oder letzten bestätigten Stand verwenden.
• Quarantänisieren: fehlerhafte Datensätze isolieren.
• Blockieren: Veröffentlichung oder Weiterverarbeitung stoppen.
• Reconciliieren: manuelle Freigabe oder Gegenprüfung verlangen.

Lege die Reaktion dort fest, wo der Schaden am besten begrenzt wird, nicht dort, wo der Test technisch am einfachsten läuft.

6. Owner, Betreiber und Empfänger benennen

Der Rule Owner verantwortet Bedeutung, Schwelle und Risikoakzeptanz. Der technische Betreiber verantwortet Ausführung und Zuverlässigkeit des Checks. Ein Resolver untersucht oder behebt Verstöße. Notification-Empfänger müssen die Information nutzen können.

Diese Rollen können identisch sein, sollten aber im Artefakt getrennt benannt werden. Sonst landet jeder Alarm beim Data Engineering, auch wenn die Ursache ein fachlicher Prozess oder ein verspäteter Quellabschluss ist.

7. Evidenz und Versionierung sichern

Ein Ergebnis sollte Regel-ID und -Version, Ausführungszeit, geprüften Scope, gemessenen Wert, Schwelle, Status und Verweis auf verletzende Beispiele enthalten. Für sensible Daten genügen sichere Referenzen oder aggregierte Beispiele.

Wenn eine Schwelle geändert wird, darf das alte Ergebnis nicht rückwirkend seine Bedeutung wechseln. Versionierung macht nachvollziehbar, welche Zusage zu welchem Zeitpunkt galt. Das ist für Audits, Incident Reviews und Trendanalysen wichtiger als ein perfekt gestaltetes Dashboard.

Regeltypen als stack-neutrale Muster

Struktur und Contract

Schema, Datentyp, Pflichtfelder, erlaubte zusätzliche Spalten und Kompatibilität. Diese Regeln erkennen unerwartete Schnittstellenänderungen. Ein Schema-Check beweist jedoch keine fachliche Korrektheit.

Identität und Eindeutigkeit

Geschäftsschlüssel, zusammengesetzte Schlüssel und Historisierungslogik. Prüfe am erklärten Grain und berücksichtige gültige Mehrfachversionen. Technische Surrogate Keys können eindeutig sein, obwohl fachliche Duplikate bestehen.

Domäne und bedingte Gültigkeit

Erlaubte Werte, Formate, Wertebereiche und Wenn-dann-Beziehungen. Ein Betrag kann nur für bestimmte Status positiv sein; ein Enddatum muss nach Startdatum liegen; eine Währung ist nur bei monetären Positionen Pflicht.

Referentielle Integrität und Abdeckung

Referenzen müssen in einer definierten Master-Population existieren. Die Regel braucht Latenz- und Orphan-Policy: Darf ein Fakt vor seiner Dimension eintreffen? Wie lange? Ein sofortiger harter Foreign-Key-Check ist in verteilten Pipelines nicht immer fachlich richtig.

Freshness und Vollständigkeit einer Lieferung

Prüfe nicht nur den letzten Zeitstempel. Erwartete Partitionen, Quellen, Länder oder Filialen müssen eingetroffen sein. Ein aktueller Datensatz mit nur einer von zehn Quellen ist frisch, aber unvollständig.

Reconciliation und fachliche Invarianten

Vergleiche kontrollierte Summen, Zählungen oder Salden über Systemgrenzen. Definiere Bewertungslogik, Zeitbezug, Währung und Toleranz. Invarianten wie „Eröffnungsbestand plus Bewegungen gleich Schlussbestand“ sind oft aussagekräftiger als Spaltenchecks.

Durchgängiges Beispiel: Revenue-KPI

Aus Teil 1 liegt der Kontext für gebuchten Nettoumsatz vor. Im Workshop sagt Finance: „Der tägliche Umsatz soll alle gebuchten Positionen der angebundenen Länder enthalten und mit dem Finanzsystem übereinstimmen.“

Das Team zerlegt diese Aussage in Regeln.

Regel REV-01 – Positionsidentität. Scope: produktive B2C-Auftragspositionen ab dem vollständigen Startdatum je Land. Behauptung: Kombination aus order_id, line_id und booking_version ist eindeutig. Schwelle: null Duplikate. Schweregrad: kritisch. Reaktion: Veröffentlichung der betroffenen Partition blockieren, Rohdaten nicht löschen. Owner: Revenue Operations. Resolver: Commerce Data Team.

Regel REV-02 – Währungsabdeckung. Scope: umsatzwirksame Positionen ohne Storno. Behauptung: Währung vorhanden und in der freigegebenen ISO-Domäne. Schwelle: 100 Prozent; getrennte Warnung, falls ein neuer unbekannter Code auftaucht. Reaktion: Position quarantänisieren und KPI als unvollständig markieren.

Regel REV-03 – Länderlieferung. Scope: erwartete aktive Länder je Geschäftstag. Messung: eingetroffene Länder geteilt durch erwartete Länder sowie absolute Liste fehlender Länder. Warnung um 05:30 Uhr, Fehler um 06:00 Uhr. Regionale Feiertage werden über einen kontrollierten Kalender berücksichtigt.

Regel REV-04 – Reconciliation. Scope: abgeschlossene Buchungsperiode, gleiche Währungsumrechnung und gleicher Stornozustand. Messung: absolute und relative Differenz zur Finance-Summe. Warnung ab 0,2 Prozent, kritisch ab 0,5 Prozent oder 50.000 Euro. Reaktion: Monatsfreigabe blockieren, tägliche Trendansicht sichtbar als vorläufig kennzeichnen.

Regel REV-05 – zulässige Nutzung. Das ist keine reine SQL-Regel: Vorläufige Daten dürfen nicht als gesetzlicher Abschluss exportiert werden. Evidenz kann aus Zertifizierungsstatus, Workflow-Freigabe und Zugriffspfad bestehen.

Die Regeln zeigen, warum ein Testzoo nicht genügt. Manche Erwartungen brauchen Zeilenchecks, andere Lieferkalender, Reconciliation oder Prozesskontrollen.

Betriebsmodell

Regelportfolio statt Regelablage

Verwalte Regeln als Portfolio nach Datenprodukt und Entscheidung. Jede Regel muss auf eine Erwartung und einen Consumer-Impact verweisen. Reviews betrachten nicht nur neue Tests, sondern veraltete, redundante und dauerhaft ignorierte Regeln.

Ein kleines Quality Council oder die bestehende Product-Runde kann kritische Regeln freigeben. Für niedrige Kritikalität genügt Peer Review. Die Governance sollte Entscheidungen beschleunigen, nicht jede Regex zentral genehmigen.

Lebenszyklus

Eine Regel durchläuft Entwurf, Beobachtung, aktiv, Ausnahme, außer Betrieb. Im Beobachtungsmodus wird die Messung kalibriert, ohne Produktion zu blockieren. Aktivierung erfordert Owner und Reaktion. Ausnahmen laufen ab. Außer Betrieb gesetzte Regeln bleiben für Historie auffindbar.

Incident-Verknüpfung

Nicht jeder Fehler ist ein Incident. Bündele zusammenhängende Verletzungen nach Ursache, Asset und Zeitfenster. Eine fehlende Quelle kann hundert nachgelagerte Regeln brechen; hundert Tickets verschlechtern die Reaktion. Root-Cause-Nähe und Lineage helfen bei der Deduplizierung.

Einfachste tragfähige Umsetzung

Wählt einen kritischen Consumer-Pfad und höchstens fünf Erwartungen. Erstellt pro Erwartung eine Karte mit:

1. verständlicher Behauptung,
2. explizitem Scope,
3. Messgröße und Schwelle,
4. Schweregrad,
5. Owner und Resolver,
6. Reaktion und Ausnahmeweg.

Lasst jede Regel zunächst zwei bis vier Wochen im Beobachtungsmodus laufen, sofern das Risiko dies erlaubt. Prüft Fehlalarme, Population und Kosten. Aktiviert nur Regeln, deren Ergebnis ein Team tatsächlich behandeln wird. Veröffentlicht Status und bekannte Ausnahmen beim Datenprodukt, nicht nur im Orchestrator.

Anti-Patterns

Jede Spalte gleich behandeln

Vollabdeckung erzeugt Kosten und Rauschen. Kritische Geschäftsregeln und Schlüssel verdienen mehr Aufmerksamkeit als optionale Attribute.

Historische Verteilung als Wahrheit

Anomaliegrenzen aus Vergangenheit beschreiben Gewohnheit, nicht Akzeptanz. Eine dauerhaft falsche Quote bleibt falsch.

Schweregrad aus Testtyp ableiten

Ein Nullwert kann harmlos oder regulatorisch kritisch sein. Wirkung entsteht aus Scope und Nutzung, nicht aus der Funktion not_null.

Blockieren als Standard

Blindes Fail-fast kann Rohdaten, Debugging und weniger kritische Consumer unnötig stoppen. Definiere den geeigneten Kontrollpunkt.

Dauerhafte Ausnahmen

Ein stummgeschalteter Alarm ohne Ablauf ist eine gelöschte Zusage. Ausnahmen brauchen Risikoentscheidung und Rückkehrplan.

Toolnamen in fachlichen Regeln

„dbt accepted_values muss grün sein“ beschreibt eine Implementierung. „Statuswerte entsprechen der freigegebenen Auftragsdomäne“ bleibt auch nach einem Plattformwechsel verständlich.

Grenzen

Regeln können bekannte Erwartungen prüfen, aber keine vollständige Korrektheit beweisen. Sie erkennen keine unbekannten fachlichen Veränderungen, wenn kein Signal dafür existiert. Sampling kann Kosten senken, reduziert aber Evidenz. Constraints können Schreiben verhindern, nicht zwangsläufig semantisch falsche Werte. Manuelle Freigaben schaffen Verantwortung, sind aber nicht automatisch objektiv.

Deshalb ergänzt ein Regelportfolio Profiling, Observability, Lineage, Reconciliation und Incident Reviews. Die Grenze muss sichtbar bleiben: Ein grüner Regelstatus bedeutet, dass definierte Behauptungen im gemessenen Scope bestanden haben.

Hilfe beim Umsetzen

Beginnt in Workshops mit Sätzen aus Sicht des Consumers: „Ich kann diese Entscheidung nur treffen, wenn …“. Fragt danach fünfmal konkret: Für welche Fälle? Bis wann? Wie messen wir das? Ab wann ist Nutzung gefährlich? Wer entscheidet bei Abweichung?

Bei bestehenden Checks erstellt ein Mapping Check → Erwartung → Entscheidung. Checks ohne Erwartung werden Kandidaten für Entfernung oder Beobachtung. Erwartungen ohne Check erhalten eine Evidenzstrategie. Mehrere Checks für dieselbe Erwartung werden bewusst als gestaffelte Kontrollen oder als Duplikate klassifiziert.

Checkliste

• Ist die Regel in Geschäftssprache verständlich?
• Verweist sie auf eine dokumentierte Nutzer-Erwartung?
• Sind Asset, Grundgesamtheit, Ausschlüsse und Zeitfenster eindeutig?
• Sind Metrik, Nenner, Einheit und Aggregation festgelegt?
• Ist die Schwelle fachlich begründet und versioniert?
• Sind Warn- und Fehlergrenze sinnvoll getrennt?
• Beschreibt der Schweregrad die Geschäftswirkung?
• Ist die operative Reaktion ausdrücklich definiert?
• Sind Rule verantwortliche Person, technischer Betreiber und Resolver benannt?
• Enthält das Ergebnis Regelversion, Umfang, Messwert und Zeitpunkt?
• Gibt es einen befristeten Ausnahmeprozess?
• Wird die Regel bei Definition-, Source- oder Nutzungsänderungen überprüft?
• Ist die Regel unabhängig vom Implementierungswerkzeug?
• Kann das Team einen Fehler behandeln, bevor es die Regel aktiviert?

Artefakt

Ein wiederverwendbarer Quality Rule Record enthält:

• stabile Rule-ID, Name, Version und Status
• verknüpfte Erwartung und betroffene Entscheidung
• fachliche Behauptung
• Asset, fachliche Ebene, Grundgesamtheit, Filter und Ausschlüsse
• Zeitfenster, Kalender, Zeitzone und Verspätung
• Messgröße, Nenner, Einheit und Aggregation
• Warn-, Fehler- und Mindestpopulationsschwelle
• Schweregrad und begründeter Business Impact
• Rule verantwortliche Person, Betreiber, Resolver und Empfänger
• Ausführungsfrequenz und Kontrollpunkt
• Reaktion: warnen, markieren, quarantänisieren oder blockieren
• Evidenzspeicher, Aufbewahrung und sensible Beispieldaten
• Ausnahme mit Begründung, Genehmiger und Ablauf
• Abhängigkeiten, Kostenhinweis und Reviewdatum
• Implementierungsadapter je Plattform

Die technische Konfiguration darf daraus generiert oder damit verknüpft werden. Der Record bleibt die lesbare Entscheidungsschicht.

Tools

Der dbt DQ Rules Generator unterstützt die strukturierte Abbildung klarer Regeln, der dbt DQ Macro Generator wiederverwendbare Prüfungen und der Schema YML Editor die Pflege in YAML. Fabric-, Databricks- oder Lakehouse-Generatoren können dieselbe Regel optional in plattformspezifische Syntax übersetzen. Keine dieser Zuordnungen ändert das stack-neutrale Regelartefakt.

Ressourcen

Nutzt reale Incident-Berichte, KPI-Abnahmen, Source-SLAs und Abschlusskontrollen als Input. Sie liefern bessere Schwellen und Reaktionen als generische Listen „wichtiger DQ-Tests“.