Datenbanken
PostgreSQL und MySQL mit KI abfragen.
Eine Datenbank für KI-Abfragen zu erschließen heißt nicht, sie umzubauen. Es heißt, ihre Eigenheiten zu verstehen – und genau davon hat eine über Jahre gewachsene Datenbank viele.
Der Zugang
Ein eigener Benutzer, ausschließlich mit Leserechten.
Eingerichtet wird ein separater Datenbankbenutzer, der ausschließlich lesen darf. Er wird auf Ihrer Seite angelegt, gehört Ihnen und ist jederzeit entziehbar – das ist die einfachste Form von Kontrolle, die es für diesen Zugriff gibt.
Dieser Zugang ist die einzige Verbindung zu Ihren Daten. Das Sprachmodell erhält ihn nicht: Zwischen Modell und Datenbank liegt immer eine Vermittlungsschicht in Ihrer Infrastruktur, und nur diese Schicht spricht mit der Datenbank.
Wer den Datenbankbenutzer entzieht, beendet den Zugriff – ohne Rückbau in Ihrer Software.
Anforderungen
Was der Datenbankzugang braucht.
Bewusst knapp gehalten: Je kleiner die Anforderung, desto einfacher die Freigabe.
- Rechte
- Ausschließlich lesend. Keine schreibenden Rechte, keine Schemaänderungen, keine Rechte zum Anlegen von Objekten.
- Umfang
- Auf die fachlich benötigten Bereiche begrenzbar. Was ein Zugang nicht lesen darf, kann auch keine Abfrage liefern – die Begrenzung wirkt unterhalb des semantischen Modells.
- Produktiv oder Replik
- Beides möglich. Wenn die Last auf dem Produktivsystem eine Rolle spielt, ist eine lesende Replik der naheliegende Weg. Was im konkreten Fall sinnvoll ist, gehört in die technische Sichtung.
- Netzwerk
- Die Verbindung besteht zwischen Ihrer Datenbank und der Vermittlungsschicht. Läuft diese Schicht in Ihrer Infrastruktur, verlässt die Datenbankverbindung Ihr Netz nicht.
- Schemaänderungen
- Keine. Es werden keine Tabellen, Spalten, Views oder Trigger angelegt, die Ihr System betreffen.
Realität gewachsener Datenbanken
Sechs Eigenheiten, an denen naive Abfragen scheitern.
Jede davon führt zu Zahlen, die plausibel aussehen und falsch sind. Genau deshalb reicht ein Blick auf das Schema nicht aus.
Kryptische Tabellen- und Spaltennamen
Namen wie KD_STAT_2 oder FLAG_B sind für ein Sprachmodell bedeutungslos. Was sie bedeuten, steht nicht im Schema, sondern in dem Code, der sie schreibt und liest.
Fehlende Fremdschlüssel
In gewachsenen Systemen sind Beziehungen häufig nur in der Anwendungslogik abgebildet, nicht als Constraint. Aus dem Schema allein lässt sich dann nicht ableiten, welche Spalte auf welche Tabelle zeigt.
Soft Deletes
Gelöschte Datensätze sind oft noch vorhanden und nur als gelöscht markiert – über ein Kennzeichen, einen Status oder ein Datum. Wer das übersieht, zählt Daten mit, die es fachlich nicht mehr gibt.
Historisierung und Gültigkeitszeiträume
Mehrere Versionen desselben Datensatzes mit Gültigkeitsspannen. Eine Auswertung ohne Stichtagslogik summiert dieselbe Sache mehrfach – oder greift die falsche Version.
Mehrere Datumsspalten pro Vorgang
Angelegt, gestellt, gebucht, geändert, valutiert: Welches Datum eine fachliche Frage meint, ist eine fachliche Entscheidung. Ein Modell, das raten muss, rät irgendwann falsch.
Redundante und tote Felder
Spalten, die einmal befüllt wurden und heute nicht mehr gepflegt werden, oder zwei Felder mit derselben Bedeutung. Ohne Kennzeichnung liefert eine Auswertung Werte aus dem Feld, das seit Jahren stillsteht.
Deshalb wird das semantische Modell nicht aus dem Schema abgeleitet, sondern aus Schema und Sourcecode gemeinsam – und danach fachlich validiert.
Zweite Quelle
Was die Datenbank nicht verrät, steht im Sourcecode.
Ein Schema zeigt Strukturen. Es zeigt nicht, welche Regel hinter einem Status steckt, wie ein Storno verrechnet wird oder unter welcher Bedingung ein Kunde in Ihrem Haus als aktiv gilt. Diese Regeln liegen im Code, der die Daten schreibt.
Deshalb werden beide Quellen ausgewertet: das Datenmodell für Strukturen und Beziehungen, der Sourcecode für Bedeutungen und Berechnungen. Aus beidem entsteht das fachliche Modell – KI-gestützt, weil dieselbe Arbeit von Hand Wochen dauern würde.
Das Ergebnis ist ein Vorschlag, keine Wahrheit – und wird deshalb fachlich validiert.
Diese Validierung ist der Kern der Pilotphase: Ihre Fachanwender stellen echte Fragen, die Antworten werden gemeinsam geprüft, falsch benannte Regeln werden korrigiert. Was einmal korrigiert ist, gilt für jede gleichartige Frage danach.
Datenbanksysteme
Was umgesetzt ist – und was pro Projekt bewertet wird.
Hier steht der Stand, nicht die Absicht. Eine Liste unterstützter Systeme, die eine Absicht mitaufführt, ist eine Falschaussage.
- PostgreSQL
- Umgesetzt und im Einsatz.
- MySQL
- Umgesetzt und im Einsatz.
- Andere relationale Systeme
- Werden pro Projekt bewertet. Der Ansatz ist nicht an ein Datenbanksystem gebunden, eine belastbare Aussage zu Ihrem System entsteht aber erst in der technischen Sichtung – nicht durch einen Eintrag in einer Kompatibilitätsliste.
- Nicht-relationale Datenquellen und Dokumente
- In Arbeit und heute nicht Teil des Leistungsstands.
Häufige Fragen
Fehlt Ihnen eine Frage? Ausführliche Antworten zu Betrieb und Datenzugriff stehen auf der Sicherheitsseite.
- Müssen wir unser Datenbankschema anpassen oder Views anlegen?
Nein. Es werden keine Tabellen, Spalten, Views oder Trigger angelegt, die Ihr System betreffen. Die Eigenheiten des Schemas werden im semantischen Modell beschrieben, nicht in der Datenbank bereinigt.
Das ist auch der Grund, warum der Ansatz auf gewachsenen Systemen funktioniert: Ein Schema aufzuräumen wäre ein eigenes Projekt mit eigenem Risiko – und für die Beantwortung der Fragen nicht nötig.
- Greift das System auf die Produktivdatenbank zu?
Beides ist möglich. Ein lesender Zugriff auf das Produktivsystem ist der einfachste Weg und liefert aktuelle Zahlen; eine lesende Replik ist der Weg, wenn die Last auf dem Produktivsystem kritisch ist.
Welcher Weg passt, hängt von Datenmenge, Abfragemuster und Ihren Betriebsvorgaben ab. Eine pauschale Empfehlung wäre an dieser Stelle nicht seriös.
- Und wenn wir Oracle oder SQL Server einsetzen?
Umgesetzt und im Einsatz sind derzeit PostgreSQL und MySQL. Andere relationale Systeme werden pro Projekt bewertet – hier steht dazu bewusst keine Zusage, solange sie nicht umgesetzt ist.
Für ein Gespräch ist das kein Ausschlusskriterium: Die technische Sichtung klärt, was Ihr System bedeutet, statt die Frage über eine Kompatibilitätsliste zu beantworten.
- Funktioniert das auch bei großen Datenmengen?
Die Abfragen sind lesend und werden vom System aus einem geprüften Plan erzeugt, nicht vom Sprachmodell – sie lassen sich damit wie andere Auswertungsabfragen behandeln: begrenzen, auf eine Replik legen, mit den vorhandenen Indizes abstimmen.
Belastbare Aussagen zu Laufzeiten bei Ihrer Datenmenge und Ihrem Schema entstehen in der technischen Sichtung. Zahlen dazu auf einer Website wären geraten.
Verwandte Themen
Angrenzende Fragen, jeweils auf einer eigenen Seite beantwortet.
Datenbank mit KI abfragen
Der Weg einer Frage bis zur belegten Zahl – und warum geprüft wird, bevor gelesen wird.
KI für Legacy- und Individualsoftware
Wenn das Fachwissen im Sourcecode steckt und die Dokumentation veraltet ist.
KI in bestehende Software integrieren
Was in Ihrer Systemlandschaft angepasst werden muss – und was ausdrücklich unverändert bleibt.
Ein Blick auf Datenmodell und Sourcecode reicht für eine ehrliche Einschätzung von Aufwand und Grenzen.