Datenbankschema-Entwurf & Abfrageoptimierung

Kleine Teams liefern Datenbanken oft mit ad hoc gewachsenen Schemas, fehlenden Indizes und ORM-generierten Abfragen aus, die niemand analysiert hat – und merken es erst, wenn die Produktion langsamer wird. KI-Assistenten können aus Anforderungen normalisierte Schemas vorschlagen, sichere Migrationen schreiben, Ausführungspläne lesen und Umschreibungen sowie Indizes empfehlen. Datenbankeigene Advisor-Werkzeuge und LLM-Agenten, die mit einer Nicht-Produktiv-Kopie verbunden sind, machen das Know-how eines Datenbankadministrators für Entwickler verfügbar; der Administrator gibt weiterhin jede Änderung frei.

Problem & Nutzen

• Heute: Schemas wachsen organisch; Entwickler kopieren Muster, ORMs erzeugen N+1-Abfragen, und das Tuning übernimmt ein knapper Datenbankadministrator, der EXPLAIN-Ausgaben liest. Migrationen großer Tabellen verursachen Sperren und Ausfälle.
• KI-Nutzen: schnellere erste Entwürfe (ER-Modell, DDL, Constraints, Namenskonventionen), Erläuterung von Ausführungsplänen in verständlicher Sprache, Vorschläge für Umschreibungen und Indizes sowie Prüfung von Migrationen (Sperrrisiko, Abwärtskompatibilität).
• Belege: Text-to-SQL-Benchmarks zeigen die Lücke zwischen Spielzeug- und echten Datenbanken. Spider 2.0 (Unternehmens-Workflows auf BigQuery/Snowflake) meldete in der Originalarbeit für den besten Code-Agenten nur rund 21 % Aufgabenerfolg, gegenüber 91 % bei Spider 1.0 [1]. BIRD ergänzt einen Valid Efficiency Score, der korrektes, aber langsames SQL abwertet [2]. Tuning-Advisor der Hersteller sind allgemein verfügbar, zum Beispiel das Index-Tuning in Azure Database for PostgreSQL auf Basis von Query Store [3]. Eine allgemeingültige Beschleunigungszahl gibt es nicht; die Gewinne hängen von der Last ab.

Varianten

• Schema-Entwurf auf der grünen Wiese: von Anforderungen über ER-Modell zu DDL, einschließlich mandantenfähiger und DSGVO-gerechter Entwürfe (getrennte Tabellen für personenbezogene Daten, Aufbewahrungsspalten, Löschpfade).
• Abfrage-Tuning: eine langsame Abfrage umschreiben, N+1-Muster beseitigen, Hinweise zur Join-Reihenfolge wählen, materialisierte Sichten einsetzen.
• Advisor für Index und physisches Design: lastbasierte Empfehlungen zu Indizes, Partitionierung und Statistiken.
• Migrationsassistent: Expand/Contract-Migrationen, Änderungen ohne Ausfallzeit, Rollback-Skripte; die Migration der Datenbank-Engine (Oracle nach PostgreSQL) überschneidet sich mit CODE-005.
• NoSQL-/Analytics-Modellierung: Dokumentmodelle, Sternschemas und dbt-Modelle (siehe CODE-022).
• Private/Hobby-Nutzung: ein SQLite- oder Postgres-Entwurf für ein persönliches Projekt mit einem Chat-Assistenten.

So funktioniert es

1. requirements / existing DDL / slow-query log
2. context assembly (schema, stats, row counts, EXPLAIN plans, pg_stat_statements)
3. LLM proposes schema, migration or rewritten query
4. automated checks on a clone (parse, lint, EXPLAIN, hypothetical indexes, result-equivalence test)
5. benchmark before/after on representative data
6. human review (developer + DBA)
7. migration pipeline
8. staged rollout

• Die Verankerung im Kontext ist entscheidend: Das Modell muss echte DDL, Kardinalitäten und Pläne sehen und darf nicht raten. Werkzeuge stellen diese über MCP-Server oder Funktionsaufrufe bereit.
• Überprüfen schlägt Vertrauen: Eine Umschreibung wird nur akzeptiert, wenn sie auf einem Testdatensatz identische Ergebnisse liefert und der gemessene Plan günstiger ist. Mit Werkzeugen für hypothetische Indizes lässt sich ein Index testen, ohne ihn zu bauen.
• Mensch-in-der-Schleife (Human-in-the-Loop): DDL und Änderungen an der Produktion führt der Agent nie direkt aus; er arbeitet nur lesend auf einem Replikat oder einem anonymisierten Klon und eröffnet einen Pull Request mit der Migration.

Datenaufbereitung

Die KI braucht Kontext statt Trainingsdaten: DDL und Migrationshistorie (Git, ORM-Modelle), Slow-Query-Logs und Statistiken (pg_stat_statements, Query Store), EXPLAIN-Pläne und repräsentative Zeilenzahlen. In einem KMU liegen diese im Anwendungs-Repository, auf dem Datenbankserver und in den Köpfen einiger weniger Personen; Dokumentation fehlt oft.

Typische Lücken: undokumentierte Tabellen und Spalten, kein Nicht-Produktiv-Klon, Produktionsdaten mit personenbezogenen Daten, die nicht an ein LLM gelangen dürfen, kein Testdatensatz, der belegt, dass eine umgeschriebene Abfrage identische Ergebnisse liefert, und viel zu weit gefasste Datenbank-Zugangsdaten.

Schritte der Aufbereitung: - Das Schema mit Kommentaren exportieren und für kryptische Tabellen und Spalten kurze Beschreibungen ergänzen (PREP-012 für ein gemeinsames Glossar). - Einen maskierten oder synthetischen Klon mit realistischen Kardinalitäten aufbauen (PREP-022); den Agenten nie mit der Produktion verbinden. - Eine reine Leserolle anlegen, die auf den Klon und auf Statistik-Sichten beschränkt ist. - 20-50 repräsentative Abfragen mit erwarteten Ergebnissen als Regressionstests sammeln (PREP-018). - Prüfen, ob die Logs wörtliche personenbezogene Werte enthalten, und diese entfernen (PREP-025).

Aufwandsanteil: gering bis mittel, etwa 20-30 % des Projekts, vor allem für Klon und Dokumentation. Siehe auch GUIDE-003 für einen Reifegrad-Check und DATA-001 für verwandte Data-Engineering-Arbeiten.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg B, weil ein kleines Team einen lesenden Agenten braucht, der an das eigene Schema und einen Klon angebunden ist, und kein Produkt ohne Integration zu jeder Datenbank passt.
• Großunternehmen: Weg B, weil ein zentrales Datenbankadministrations-Team auf einer verwalteten API ein geprüftes Gerüst (Klon, EXPLAIN-Prüfungen, CI) aufbauen und für viele Datenbanken wiederverwenden kann.
• Entwickler: Weg C, weil Schemas und Slow-Query-Logs interne Strukturen offenlegen und ein Code-Modell mit offenen Gewichten auf HW2 sie lokal hält.

Weg A — Kaufen (Standardsoftware)

• Datenbankeigene Advisor: Azure Database for PostgreSQL Index-Tuning und autonomes Tuning [3]; Amazon RDS/Aurora Performance Insights und DevOps Guru for RDS; Google Cloud SQL / AlloyDB Insights und Index Advisor; automatische Indizierung der Oracle Autonomous Database; automatisches Tuning über den SQL Server Query Store.
• Drittanbieter: Percona Monitoring and Management (Open Core), pganalyze, EverSQL, Datadog Database Monitoring, SolarWinds DPA; JetBrains DataGrip AI Assistant und Navicat für Hilfe in der IDE. Aus der EU: Percona hat seinen Hauptsitz in den USA, daher das Hosting prüfen; Scaleway, OVHcloud, IONOS und STACKIT bieten verwaltetes PostgreSQL in EU-Rechenzentren an (das Tuning erfolgt überwiegend manuell).
• A wählen, wenn: Sie bereits eine verwaltete Datenbank betreiben und mit geringem Aufwand Empfehlungen wünschen.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Modelle: führende Code-/Reasoning-Modelle (Claude, GPT, Gemini) oder Mistral (EU-Anbieter, Codestral) über EU-Regionen, für Schema-Entwürfe und Planerläuterungen.
• Integration: ein Agent in der IDE oder in CI (siehe CODE-001, CODE-002) mit einem lesenden MCP-Datenbankserver; Azure hat PostgreSQL-Skills und ein MCP-Plugin für Abfrage- und Index-Tuning veröffentlicht, nutzbar mit Assistenten wie GitHub Copilot und Claude Code [4].
• Leitplanken: Leserolle, Statement-Timeouts, keine Produktions-Zugangsdaten, zeilenweises Maskieren personenbezogener Daten, Allow-List per SQL-Parser (kein DDL/DML außerhalb von Migrations-Pull-Requests).
• B wählen, wenn: Sie Flexibilität wünschen und Entwickler, aber keinen eigenen Datenbankadministrator haben.

Weg C — Selbst betreiben (Open Source)

• Modelle: Code-Modelle mit offenen Gewichten (Qwen3-Coder-Familie, DeepSeek-Coder/V3-Familie, offene Codestral-Varianten, Granite Code), bereitgestellt über vLLM oder Ollama; ein quantisiertes Modell der 30B-Klasse passt auf eine GPU mit 24-32 GB (HW2).
• Datenbank-Werkzeuge: PostgreSQL mit pg_stat_statements [5], HypoPG (hypothetische Indizes), Dexter (automatischer Indexer), pgMustard/explain.dalibo.com zur Visualisierung von Plänen, pgTAP für Tests, Atlas, Liquibase, Flyway oder Alembic für Migrationen, SQLFluff fürs Linting.
• Aufwand: überschaubarer Betrieb; der Wert liegt im Prüfgerüst, nicht im Modell.

Weg D — Eigenes Training

Selten gerechtfertigt. Feintuning auf die eigenen Schema-Konventionen, Namensregeln und frühere Paare von Abfrage-Umschreibungen kann in großen Beständen oder für Nischen-Dialekte (PL/SQL, T-SQL) helfen. Es braucht Hunderte bis Tausende geprüfter Beispiele. Lernende Optimierer und Kardinalitätsschätzer bleiben überwiegend Forschung oder herstellerinterne Entwicklung.

Stand der Technik (2026)

• Plan-bewusste Agenten: Modelle, die EXPLAIN (ANALYZE, BUFFERS) aufrufen, den Plan lesen und iterieren, schneiden besser ab als einmaliges Umschreiben; Reasoning-Modelle sind bei Join- und Prädikatslogik spürbar besser als frühere Generationen.
• Text-to-SQL ist auf sauberen Benchmarks stark, bei Unternehmensschemas aber weiterhin schwach: Spider 2.0 und BIRD sind unter realen Bedingungen weit von der Sättigung entfernt [1][2]. Aktuelle Platzierungen finden Sie in den Live-Ranglisten.
• Autonomie der Hersteller: Verwaltete Datenbanken legen Indizes zunehmend automatisch anhand von Lasttelemetrie an und löschen sie wieder [3].
• Grenzen und Fehlerbilder: erfundene Spalten, semantisch abweichende Umschreibungen (NULL-Behandlung, Duplikate, Sortierung), Indizes, die eine Abfrage beschleunigen und Schreibvorgänge verlangsamen, Ratschläge, die auf winzige Testdaten abgestimmt sind, Verwechslung von Dialekten, unsichere Migrationen (Tabellen-Neuaufbau, lange Sperren) sowie Pläne, die sich mit den Produktionsstatistiken ändern.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack (llm-code, agent-framework): CODE-001 IDE-Assistenten, CODE-002 Coding-Agenten (eröffnen den Migrations-Pull-Request), CODE-009 Infrastructure as Code für die Bereitstellung, CODE-005 für Engine-Migrationen.
• Angrenzend: DATA-001 natürlichsprachliche Abfragen (Natural-Language-to-SQL) für Fachanwender (Abfrageerzeugung ohne Tuning), DATA-022 Schema-/EDI-Mapping, CODE-022 Analytics Engineering, CODE-023 Performance-Optimierung, CODE-010/CODE-011 für Observability-Signale.
• Ein selbst betriebenes Code-Modell (HW2/HW3) bedient alle diese Anwendungsfälle.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage; überwiegend Lizenz-/Nutzungskosten der Plattform.
• Weg B: 2-6 Wochen für einen Agenten samt Prüfgerüst und CI-Integration; die API-Kosten sind klein gegenüber der Arbeitszeit des Administrators.
• Weg C: 1-3 Monate inkl. GPU-Server und Testdaten-Pipeline.
• Kennzahlen: p95-/p99-Latenz der häufigsten oder teuersten N Abfragen, gesamte Datenbank-CPU/-IO, Anteil der nach Prüfung akzeptierten KI-Vorschläge, durch Vorschläge verursachte Regressionen (Ziel: null), Migrationsfehler und Sperr-Vorfälle, Zeit von der Slow-Query-Warnung bis zur Behebung.

Menschen & Veränderung

Früh einbinden: die Geschäftsleitung (Budget, Regel, dass der Agent nie in die Produktion schreibt), die Abteilungsleitung oder den Datenbankadministrator als Prozessverantwortliche(n), die IT für Klon und Konten, die Dateneigner der Quelldatenbanken und die IT-Sicherheit für Zugangsdaten. Die Datenschutzbeauftragte bzw. der Datenschutzbeauftragte kommt hinzu, wenn der Klon personenbezogene Daten enthalten könnte; eine DSFA ist bei maskierten Daten normalerweise nicht nötig, ein AVV (Art. 28 DSGVO) ist jedoch mit jedem API-Anbieter erforderlich.

Betriebsrat: In der Regel keine Mitbestimmung für das Werkzeug selbst, weil es die Datenbanklast analysiert und nicht Personen. Es kommt darauf an, ob die Aktivität einzelner Entwickler protokolliert oder bewertet wird (Akzeptanzquoten je Person); dann greift § 87 Abs. 1 Nr. 6 BetrVG, und § 90 Abs. 1 Nr. 3 verlangt die rechtzeitige Unterrichtung über KI-gestützte Arbeitsprozesse. Öffentliche Stellen: Personalrat.

KI-Kompetenz: Entwickler mit einer kurzen Schulung zur Überprüfung von SQL-Vorschlägen unterstützen (Art. 4 KI-Verordnung (AI Act) in der Fassung der Verordnung (EU) 2026/1744; GUIDE-006).

Kommunikation und Pilot: Mit einem freiwilligen Team und einigen bekannten langsamen Abfragen beginnen; Vorher-/Nachher-Benchmarks zeigen. Die typische Sorge, „die KI ersetzt den Datenbankadministrator“, wird ausgeräumt, indem der Administrator die Freigabe jeder Migration behält. Der Mensch behält die Kontrolle: Pull Requests, Review und gestufter Rollout. Siehe GUIDE-009 und GUIDE-008.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): minimales Risiko; Entwicklerwerkzeuge fallen unter keine Kategorie nach Anhang III. Die KI-Kompetenz (Art. 4) gilt. Speist die Datenbank später ein Hochrisiko-System (Kredit, Personal), trägt dieses System die Pflichten, nicht der Tuning-Assistent [6].
• DSGVO: Schema und Plankontext enthalten selten personenbezogene Daten, Abfrage-Logs, Beispielzeilen und Literale in Slow-Query-Logs dagegen oft. Literale maskieren oder normalisieren, Produktionszeilen nie ohne Auftragsverarbeitungsvertrag und Rechtsgrundlage an Drittanbieter-APIs senden; EU-Regionen bevorzugen. Der Schema-Entwurf sollte Datenminimierung, Aufbewahrung und Löschung umsetzen (Art. 5, 17, 25).
• Sicherheit: Prompt-Injection über Daten oder Kommentare (z. B. ein Spaltenkommentar, der den Agenten anweist), zerstörerisches SQL, durchgesickerte Zugangsdaten. Gegenmaßnahmen: Leserollen, Replikate, Allow-Lists und verpflichtendes Review.
• Betrieb: KI-vorgeschlagene Indizes wirken sich auf Schreibdurchsatz und Speicherbedarf aus; immer benchmarken und gestuft ausrollen.

Erste Schritte

1. pg_stat_statements (oder das Pendant Ihrer Engine, etwa Query Store) aktivieren und die 10 Abfragen mit der höchsten Gesamtzeit auflisten.
2. Ein anonymisiertes Replikat oder einen Klon mit realistischen Zeilenzahlen anlegen; dem KI-Assistenten dort eine Leserolle geben.
3. Einen Assistenten den Plan einer langsamen Abfrage erläutern und eine Umschreibung vorschlagen lassen; Ergebnisgleichheit und Laufzeit selbst überprüfen.
4. Eine CI-Prüfung ergänzen, die Migrationen lintet und sperrintensives DDL markiert; für jede Schemaänderung ein Review durch Datenbankadministrator oder Senior verlangen.
5. Die Kennzahlen monatlich verfolgen und auf Schema-Design-Reviews für neue Funktionen ausweiten.

Quellen

1. Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows — https://arxiv.org/abs/2411.07763
2. Spider2 benchmark repository (leaderboards) — https://github.com/xlang-ai/Spider2
3. Microsoft — Index tuning in Azure Database for PostgreSQL Flexible Server — https://learn.microsoft.com/azure/postgresql/flexible-server/concepts-index-tuning
4. Microsoft message centre summary — PostgreSQL skills and MCP plugin for Azure Database for PostgreSQL — https://mc.merill.net/message/AZ569664
5. PostgreSQL documentation — pg_stat_statements — https://www.postgresql.org/docs/current/pgstatstatements.html
6. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
7. HypoPG — hypothetical indexes for PostgreSQL — https://github.com/HypoPG/hypopg