Reines SQL als Output
ETL-Prozesse automatisch aus Metadaten. Der erzeugte Code ist der Vertrag - versioniert, diffbar, ohne zusätzliche Abstraktionsschicht.
Über michDI²
DI2
Data Integration² Platform
ETL-Strecken aus Metadaten erzeugen - wartbar, lesbar, auditierbar.
Ein eigenes Produkt, von der Spec über die UX bis zum produktiven Deploy selbst gebaut. Diese Seite zeigt nicht nur, was DI² ist - sondern auch wie es entwickelt wird.
Was DI² in einer halben Minute ist
Vision, Output-Format, Methoden-Herkunft und Datenqualitäts-Philosophie - komprimiert auf vier Absätze.
DI² erzeugt wartbare, lesbare und auditierbare ETL-Prozesse aus den Metadaten deines Quellsystems - automatisch, in reinem SQL. Der Output läuft heute auf PostgreSQL und SQL Server.
Ausgangspunkt sind Tabellen, Spalten, Typen und Beziehungen - sie werden zum Modell, angereichert um fachliches Wissen wie zulässige Werte, Business Keys und Historisierungsregeln. Aus diesem Modell entstehen automatisch Extraktion und SCD2-Historisierung; die Transformation in DWH oder OLTP bleibt bewusst Handarbeit - DI² liefert das Gerüst, ihr schreibt die fachliche Logik.
Datenqualität ist das Produkt, nicht ein Feature. Fachliche Regeln als WHERE-Klauseln in den Metadaten; fehlerhafte Datensätze landen in einer Fehler-Tabelle statt still im DWH. Drei Protokoll-Ebenen - Prozess, Schritt, Stacktrace - auswertbar per SELECT.
Keine Neuerfindung: Die Methode existiert seit 2015 in ständiger Iteration - initial als VBA/Excel-basierter Codegenerator, heute als PostgreSQL-native Engine mit Next.js-Web-Layer. DI² ist die Re-Implementation einer über 10 Jahre erprobten Vorgehensweise auf modernem Stack.
Wie DI² Entscheidungen trifft
Jedes Tool macht Annahmen über das, was wichtig ist. Diese sind die unsrigen - explizit, damit sie diskutierbar bleiben.
Tabellen statt Klicks
Der Prozess entsteht direkt aus Tabellen, Spalten, Typen, Beziehungen - datenmodell-getrieben statt klick-getrieben.
Zwei RDBMS heute, portierbar
Versioniertes SQL läuft heute auf PostgreSQL und SQL Server. Eine Portierung auf andere Dialekte (Snowflake, BigQuery, Oracle, DuckDB) ist überschaubar, weil der Output reines SQL bleibt.
Jede Prozedur eine Datei
Jeder Code-Change als Git-Diff sichtbar. Reines SQL ohne DSL - Engineers und Analysten verstehen es ohne Einarbeitung.
Jeder Lauf belegbar
Drei Protokoll-Ebenen - Prozess, Schritt, Stacktrace - alles auswertbar per SELECT. Nicht spürbar, sondern messbar.
Regeln werden Metadaten
Zulässige Werte, Wertebereiche, Business und Alternate Keys, Historisierungsregeln leben im Modell - nicht als Kommentare im Code.
Drei generierte Stages
Extraktion und SCD2-Historisierung werden automatisch erzeugt; die DWH/OLTP-Transformation bleibt Handarbeit - bewusst.
Qualität ist das Produkt
Fachliche Regeln als WHERE-Klauseln. Fehlerhafte Datensätze landen in einer Fehler-Tabelle - nicht still im DWH.
Fünf Schritte
Von Metadaten zur Produktion
- 01Quelle anbindenMSSQL · PostgreSQL · MySQL
- 02Schema scanneninformation_schema
- 03AnreichernBK · DQ · Historisierung
- 04SQL generierenDDL · Staging · SCD2
- 05OrchestrierenSQL synchron · Python async
Vier Environments, ein VPS, eigene Identity
Self-hosted auf Hetzner (EU-Rechenzentrum, Deutschland) - kein Vercel, kein Supabase, kein US-Managed-Service für sensible Layer. Daten-, Auth- und Mail-Stack durchgängig im EU-Raum, DSGVO-konform. Docker Compose mit Multi-App-Layout, Nginx als Reverse Proxy, Let's Encrypt für SSL.
Browser
HTTPS
All-Inkl DNS
A-Record → VPS
GitHub Actions
SSH Deploy
↓ ↓ ↓
Hetzner Cloud VPS
Docker Compose · Multi-App-Layout · /home/fupi/app/di2/<env>
Nginx Reverse Proxy · Let's Encrypt SSL
Application
Next.js DEV
:3000
Application
Next.js INT
:3001
Application
Next.js TEST
:3002
LIVE
Application
Next.js PROD
:3003
PostgreSQL 17
di2_postgres
App-Daten · Audit · Stored Procedures
Self-hosted · pg-Client mit Connection-Pooling
Self-hosted · pg-Client mit Connection-Pooling
Keycloak 26
di_keycloak
OIDC IdP · eigene Postgres-Instanz · Custom Theme
Auth.js v5 · JWT-Sessions (8h) · rollenbasiert
Auth.js v5 · JWT-Sessions (8h) · rollenbasiert
Stack
- Next.js 16 / React 19 / TypeScript
- PostgreSQL 17 (self-hosted)
- Tailwind 3 + shadcn/ui
- Auth.js v5 (NextAuth) + Keycloak OIDC
Auth & Identity
- Keycloak als zentraler IdP
- JWT-Sessions (8h), rollenbasiert
- Lokaler User-Schatten + Reconcile-Job
- Custom Theme (DI²) für Login & Mails
CI/CD
- GitHub Actions → SSH → Hetzner
- 4 Environments parallel auf 1 VPS
- schema_apply_log Audit-Trail
- Security-Gate vor Prod-Deploy
Acht Phasen, ein Skill pro Phase, Human-in-the-Loop
AI-driven Development heißt nicht „Claude schreibt allein Code“. Es heißt: spezialisierte Skills pro Workflow-Schritt, klare Checkpoints, und an jeder Phase wartet das System auf eine Entscheidung.
Phase 1 · Spec
Requirements
/requirements
Feature-Spec mit User Stories, Acceptance Criteria, Edge Cases.
Phase 2 · Design
Architecture
/architecture
Technische Architektur, PM-tauglich, ohne Code.
Phase 3 · UX
UX & Mockups
/ux
UX-Kritik + Mockups (HTML / React + shadcn) als Vorlage.
Phase 4 · Build
Backend
/backend
API-Routen, DB-Schema, Stored Procedures, RLS-Policies.
Phase 4 · Build
Frontend
/frontend
UI mit shadcn/ui - gegen echte APIs, keine Mocks.
Phase 5 · Test
QA
/qa
Acceptance + Edge Cases + feature-scoped Security-Checks.
Phase 6 · Review
Code Review
/review
Diff gegen Spec & Conventions; Approve / Request Changes.
Phase 7 · Deploy
Deploy
/deploy <env>
GitHub Actions: dev → int → test → prod, jede Stufe mit Gate.
Phase 8 · Audit
Security
/security
Pflicht-Gate vor prod: OWASP, Auth, Headers, Dependencies.
Cross-cutting · Always-on
Skills, die quer zum Workflow laufen
Bug-Loop
/bug - docs/bugs/bug-NNNN-<slug>.md
Jederzeit triggerbar - Doku, gezielter Fix, QA-Re-Test, Close. Bugs werden nie reopened; Regression bekommt neue ID.
Maintenance-Checks
/check-updates · npm · Docker · Actions · VPS
Periodische Wartung: Dev-Dependencies und VPS-Komponenten - read-only Befunde, kein Auto-Apply.