Fortschritt

Teil B · Das Consumer-Aligned Data Product

Übung 5 · Datenprodukt implementieren

Rote Tests grün machen, mit einem KI-Coding-Agenten oder von Hand.

~25 Min.0 von 5 Schritten erledigt

In der vorigen Übung hast du den Kontrakt entworfen. Jetzt erfüllst du ihn: eine SQL-View analytics.sku_sales_per_year auf den orders_v2-Tabellen, mit der deine Kontrakt-Tests grün werden.

Eine perfekte Aufgabe für einen KI-Coding-Agenten: Der Kontrakt legt genau fest, was gebaut wird, und mit datacontract test prüft der Agent seine Arbeit selbst.

In dieser Übung: die SQL-View hinter SKU Sales, die aus orders_v2 liest, bis alle Kontrakt-Tests grün sind.

Das lernst du

Ein Datenprodukt aus seinem Kontrakt heraus implementieren
Einen KI-Coding-Agenten gegen Kontrakt und Test-Feedback-Schleife arbeiten lassen
Verstehen, warum Datentypen Teil des Kontrakts sind
Ein Verified Statement aus dem KI-Kontext des Kontrakts prüfen
Ein Datenprodukt live schalten

Implementieren

Die View-Definition kommt nach sql/sku_sales_per_year.sql. So ist sie mit dem Kontrakt versioniert, und die CI-Pipeline in Teil C kann sie automatisch anwenden.

Mit einem KI-Coding-Agenten implementieren

Starte deinen KI-Coding-Agenten (Claude Code, Codex, Copilot, …) im Repository und gib ihm zum Beispiel diesen Prompt:

Implement a PostgreSQL view that fulfills the data contract in sku_sales_per_year.odcs.yaml. The source data is described by the contract orders_v2.odcs.yaml. Write the SQL to sql/sku_sales_per_year.sql. It must be idempotent (CREATE SCHEMA IF NOT EXISTS, CREATE OR REPLACE VIEW). Apply it to the database via docker compose exec -T postgres psql -U workshop -d workshop. Then verify with datacontract test sku_sales_per_year.odcs.yaml and iterate until all tests pass.

Beobachte, was der Agent tut:

Liest er beide Kontrakte (deinen für das Ziel, orders_v2 für die Quelle)?
Nutzt er ihren context? Die Instructions sagen, wie die Tabellen zu joinen sind, die Verified Statements zeigen funktionierende Abfragen.
Führt er die Tests aus und reagiert er auf Fehler?
Das Repository weist Agenten an, nicht in solutions/ zu schauen. Er muss aus dem Kontrakt heraus arbeiten, wie ein Engineer.

Kein KI-Agent zur Hand? Dann mach es im nächsten Schritt von Hand.

…oder von Hand implementieren

Lege den Ordner sql und darin die Datei sku_sales_per_year.sql an und ergänze die Transformation:

sql/sku_sales_per_year.sql

CREATE SCHEMA IF NOT EXISTS analytics;

CREATE OR REPLACE VIEW analytics.sku_sales_per_year AS
SELECT
    -- your transformation here
FROM orders_v2.line_items li
JOIN orders_v2.orders o ON li.order_id = o.order_id
GROUP BY ...;

Wende sie auf die Datenbank an:

docker compose exec -T postgres psql -U workshop -d workshop < sql/sku_sales_per_year.sql

CREATE SCHEMA
CREATE VIEW

Live gehen

Tests grün machen

Testen, SQL korrigieren, erneut anwenden, wiederholen, bis alles grün ist:

datacontract test sku_sales_per_year.odcs.yaml

Testing sku_sales_per_year.odcs.yaml
Server: postgres (type=postgres, host=localhost, port=5433, database=workshop, schema=analytics)
╭────────┬──────────────────────────────────────────────────────────┬────────────────┬─────────╮
│ Result │ Check                                                    │ Field          │ Details │
├────────┼──────────────────────────────────────────────────────────┼────────────────┼─────────┤
│ passed │ Ensure the view has data                                 │                │         │
│ passed │ Check that field 'order_count' is present                │ order_count    │         │
│ passed │ Check that field order_count has physical type bigint    │ order_count    │         │
│ passed │ Ensure order_count is positive                           │ order_count    │         │
…
│ passed │ Check that field year has physical type integer          │ year           │         │
│ passed │ Check that field year has no missing values              │ year           │         │
│ passed │ Ensure year is plausible                                 │ year           │         │
╰────────┴──────────────────────────────────────────────────────────┴────────────────┴─────────╯
🟢 data contract is valid. Run 15 checks. Took 0.588051 seconds.

Verified Statement prüfen

Der context deines Kontrakts verspricht eine Antwort auf „Which three SKUs sold the most units in 2024?“. Führ sie aus:

docker compose exec -T postgres psql -U workshop -d workshop -c "SELECT sku, total_quantity FROM analytics.sku_sales_per_year WHERE year = 2024 ORDER BY total_quantity DESC LIMIT 3;"

      sku      | total_quantity
---------------+----------------
 D3KT74L5EV46T |            146
 IWMJ3ZX164    |             62
 TFH11HYOR     |             46
(3 rows)

Stell deinem KI-Agenten jetzt dieselbe Frage, nur mit dem Kontrakt als Input. Kommt er auf diese Abfrage?

Datenprodukt auf active setzen

Dein Datenprodukt ist live. Setze status auf active in sku_sales_per_year.odcs.yaml und sku_sales_per_year.odps.yaml und prüfe beide:

datacontract lint sku_sales_per_year.odcs.yaml
dataproduct lint sku_sales_per_year.odps.yaml

╭────────┬────────────────────────────────────────────┬───────┬─────────╮
│ Result │ Check                                      │ Field │ Details │
├────────┼────────────────────────────────────────────┼───────┼─────────┤
│ passed │ Data contract is valid against ODCS v3.2.0 │       │         │
╰────────┴────────────────────────────────────────────┴───────┴─────────╯
🟢 data contract is valid. Run 1 checks. Took 0.12012 seconds.
✅ Data product is valid against ODPS v1.1.0
🟢 Data product is valid.

Kurzer Check

Deine View liefert die richtigen Zahlen, aber der Check für den physischen Typ der Spalte year schlägt fehl. Wahrscheinlichster Grund?