Teil 2. Warum Bankdaten Spezifikationen erfordern

Bankdaten vertragen „ungefähr richtig" besonders schlecht. Bei einem Web-Feature ist der Fehler oft für den Benutzer sichtbar. Bei einem Datenprodukt kann ein Fehler wie eine normale Tabelle aussehen: Zeilen sind vorhanden, Felder sind vorhanden, Tests sind grün, aber die Bedeutung ist bereits gebrochen. Genau deshalb eignet sich die Bankendomäne für das Lernen von SDD Data: Sie zwingt dazu, Versprechen, Einschränkungen und Beweise explizit zu formulieren.

Wo das Risiko höher als gewöhnlich ist

In der Lehrbank interessieren uns fünf Risikoklassen:

• PII und direkte Identifikatoren;
• Zahlungen und Risikosignale;
• Einwilligungen zum Datenzugriff;
• Kreditportfolio und Überfälligkeit;
• Berichterstattung und Reproduzierbarkeit von Berechnungen.

Jede Risikoklasse erfordert nicht nur SQL, sondern auch eine überprüfbare Regel. „Personenbezogene Daten nicht offenlegen" ist zu weit gefasst. Eine funktionierende Regel lautet: models/marts/ enthält keine Spalten wie pii_email, phone, passport_number und andere direkte Identifikatoren, und der Reviewer überprüft dies vor dem Release.

Warum dbt-Tests nicht ausreichen

dbt-Tests erkennen not_null, unique, akzeptierte Werte und einen Teil benutzerdefinierter Invarianten gut. Aber sie wissen nicht, dass customer_360 als „eine Zeile pro Kunde" versprochen wurde, wenn Sie dies nicht in der Spezifikation festgehalten haben. Sie wissen nicht, dass das Hinzufügen von product_code den Verbrauchervertrag ändert. Sie wissen nicht, dass risk_flag ein Lehrsignal und keine endgültige Entscheidung des Kredit-Scorings ist.

Deshalb gibt es in SDD Data mehrere Schichten:

• dbt-Tests prüfen die Form und einen Teil der Fakten;
• ODCS dokumentiert den technischen Vertrag;
• ODPS beschreibt das Datenprodukt und den Verbraucher;
• die Modellspezifikation beschreibt den Grain und die Abnahmefakten;
• der Reviewer-Bericht verbindet die Änderung mit den Versprechen.

Beispiel einer schlechten Spezifikation

Erstellen Sie ein Kunden-Mart für Analysten. Fügen Sie nützliche Felder zu Konten und
Transaktionen hinzu. Überprüfen Sie die Datenqualität.

Probleme:

• der Grain ist nicht angegeben;
• es wird nicht gesagt, ob PII offengelegt werden dürfen;
• „nützliche Felder" sind nicht definiert;
• es gibt kein SLA und keine Datenaktualität;
• „Datenqualität" ist nicht in Fakten übersetzt;
• es gibt keinen Eigentümer, der den Drift akzeptiert.

Gute Version

Datenprodukt: customer_360.
Verbraucher: Analysten des Kundenportfolios und des Filialnetzes.
Mart: mart_customer_360.
Granularität: eine Zeile pro `customer_id`.
PII: im Mart sind keine direkten PII vorhanden.
Datenaktualität: 24 Stunden.

Erforderliche Fakten: `customer_id` unique/not_null, `total_balance_rub` not_null,
`risk_event_count_7d` ist vorhanden, die Prüfung der Liste der verbotenen direkten PII besteht.

Eine solche Spezifikation löst nicht das gesamte Produkt, aber sie setzt Grenzen, die der Agent nicht erraten sollte.

Analyse für den Leser

Das Bankbeispiel wurde nicht wegen seines dramatischen Effekts gewählt. Es ist praktisch, weil fast jede Annahme Konsequenzen hat. In einem Online-Shop kann ein fehlerhaftes Mart ebenfalls schaden, aber in einer Bank zwingen sogar Lehrentitäten sofort zu Fragen: Darf dieses Feld angezeigt werden, wer darf die Methodik ändern, wie kann die Reproduzierbarkeit bewiesen werden, was passiert mit dem Bericht in der nachgelagerten Kette. Diese Fragen disziplinieren den Leser besser als ein abstraktes Verkaufsbeispiel.

Besonders wichtig ist die Unterscheidung zwischen „die Tabelle wurde erstellt" und „die Daten sind verwendbar". Ein grüner dbt build sagt, dass der Graph ausführbar ist und die erklärten Prüfungen bestanden wurden. Er sagt nicht, dass die richtige Granularität gewählt wurde. Er weiß nicht, dass in einem Mart Kunde und Konto nicht vermischt werden dürfen. Er sieht nicht, dass ein Feld wie eine Scoring-Ausgabe aussieht, obwohl es tatsächlich ein Lehr-Flag der Quelle ist. Das ist kein Mangel von dbt; das ist die Grenze des Werkzeugs.

Es ist nützlich für den Leser, an schlechten Spezifikationen zu üben. Eine schlechte Spezifikation klingt normalerweise selbstbewusst: „ein nützliches Mart erstellen", „Qualität hinzufügen", „Risiken berücksichtigen". Sie enthält wenige offensichtliche Fehler, weil sie fast nichts verspricht. Eine gute Spezifikation sieht dagegen enger aus. Sie sagt: eine Zeile pro Kunde, direkte PII verboten, Freshness 24 Stunden, Pflichtfelder so und so, Prüfungen so und so. Die Enge ist hier keine Schwäche, sondern eine Möglichkeit, die Arbeit überprüfbar zu machen.

In diesem Kapitel ist es wichtig, sich nicht an die Liste der Bankrisiken zu erinnern, sondern sich an die Frage zu gewöhnen „wie wird dies bewiesen?". Wenn eine Regel nicht in einen Befehl, eine SQL-Abfrage, einen manuellen Reviewer-Schritt oder eine menschliche Bestätigung umgewandelt werden kann, ist sie noch nicht bereit für den Agenten. Ein guter Agent sollte nicht raten, was „korrekt" bedeutet; er sollte ein Kriterium erhalten, nach dem seine Arbeit abgelehnt werden kann.

Praxis

Nehmen Sie ein Mart aus dem README und schreiben Sie dafür drei Risiken: Grain, PII und Vertragsdrift. Formulieren Sie für jedes Risiko kein Schlagwort, sondern eine überprüfbare Regel. Wenn die Regel nicht überprüft werden kann, schreiben Sie sie als Befehl oder manuellen Reviewer-Schritt um.

Minimale Ausgabe

Erstellen Sie nach dem Kapitel eine kurze Notiz:

# Notizen zu Datenrisiken

## PII
## Grain
## Freshness
## Vertragsdrift
## Menschliche Bestätigungen

Füllen Sie in jeden Abschnitt eine Regel ein. Wenn die Regel nicht überprüft werden kann, schreiben Sie sie als Befehl, SQL, Schema-Review oder menschliche Bestätigung um.

Typischer Fehler

In AGENTS.md schreiben: „halte die Bankanforderungen ein". Für den Agenten ist dies nahezu nutzlos. Er benötigt konkrete Verbote, zulässige Eingabemodelle, Vertragsfelder und Prüfungen.

Kontrollfragen

1. Warum beweist ein grüner dbt build nicht die Korrektheit eines Datenprodukts?
2. Welcher Defekt ist gefährlicher: ein SQL-Syntaxfehler oder eine unbemerkte Änderung des Grains?
3. Wo sollte die PII-Richtlinie am besten dokumentiert werden: im Chat, in einem SQL-Kommentar oder in der Spezifikation?