Reporting & BI

Fragen statt Tickets: Text-to-SQL für Ihre Datenbank

Fachbereiche sollen Daten fragen können, ohne jede Auswertung als IT-Ticket zu formulieren. Unsere Datenbank-KI übersetzt Fragen in kontrollierte read-only Abfragen und liefert Listen, Diagramme und fertige Berichte.

  • Read-only Zugriff
  • Schema-aware
  • Excel & PDF
  • Rollen & Rechte
Analystin stellt am Monitor eine Frage an ein Reporting-Dashboard mit Datenbankauswertungen

Kurzantwort

Was ist Text-to-SQL?

Text-to-SQL übersetzt Fragen in natürlicher Sprache – etwa „Welche Kunden haben offene Posten über 10.000 €?" – in geprüfte SQL-Abfragen, führt sie read-only auf der Datenbank aus und erklärt das Ergebnis verständlich.

D'Este Solutions setzt Datenbank-KI mit Schema-Katalog, Query-Validierung und Rollen um, damit Fachbereiche schneller Antworten bekommen, ohne Vollzugriff auf die Datenbank zu benötigen.

Das Problem

Warum Reporting oft zu langsam ist

Zwischen einer fachlichen Frage und ihrer Antwort liegt in vielen Unternehmen ein Umweg: Die Frage wird zum IT-Ticket, das Ticket zur SQL-Abfrage, die Abfrage zum Excel-Export – und bis das Ergebnis zurückkommt, hat sich die Frage oft schon geändert. Statische Reports helfen nur bedingt, denn sie beantworten, was gestern gefragt wurde, nicht was heute wichtig ist.

Die Folge kennen Controlling, Disposition und Geschäftsführung gleichermaßen: Fachbereiche behelfen sich mit veralteten Exporten, pflegen Schattenlisten in Excel oder verzichten ganz auf die Auswertung. Die IT wiederum arbeitet Anfragen ab, die eigentlich Self-Service sein könnten – Zeit, die für echte Entwicklungsarbeit fehlt.

Eine natürlichsprachliche Datenbankabfrage dreht diesen Ablauf um: Die Frage geht direkt an die Datenbank – auf Deutsch, nicht in SQL. Text-to-SQLübersetzt sie, führt sie kontrolliert aus und liefert das Ergebnis in Sekunden, wie im abgebildeten Dialog. Aus einer Warteschlange wird ein Gespräch.

Reporting-Assistentonline

Welche 10 Kunden hatten im März die höchsten offenen Posten?

Die zehn höchsten offenen Posten im März summieren sich auf 284.500 €. An der Spitze: Muster Logistik GmbH (48.200 €), Weber & Sohn KG (39.800 €) und Brandt Metallbau (31.400 €). Die vollständige Liste mit Fälligkeiten steht darunter.

Quelle: read-only SQL · 0,4 s

Als Excel bitte.

Der Export liegt bereit: offene-posten-maerz.xlsx mit allen zehn Kunden, Beträgen, Fälligkeitsdaten und der verwendeten Abfrage als Dokumentation.

Schutzplanken

Schnelle Antworten, kontrollierte Zugriffe

Eine KI auf der Produktivdatenbank braucht klare Grenzen. Diese sechs Schutzplanken stecken in jeder Datenbank-KI, die wir ausliefern.

Read-only per Architektur

Die KI arbeitet über ein eigenes Datenbankkonto mit reinen Leserechten. INSERT, UPDATE und DELETE sind technisch ausgeschlossen – nicht nur per Anweisung.

Schema-Katalog

Nur beschriebene und freigegebene Tabellen sind für die KI sichtbar – inklusive Beziehungen, Fachbegriffen und Synonymen aus Ihrem Arbeitsalltag.

Query-Validierung

Jede generierte Abfrage wird geparst und gegen Regeln geprüft, bevor sie läuft. Auf Wunsch wird das SQL vor der Ausführung angezeigt.

Rollen & Berechtigungen

Wer fragt, sieht nur seine Daten: Mandanten, Abteilungen und sensible Spalten folgen Ihrem bestehenden Rechtekonzept.

Limits & Performance

Zeilenlimits, Timeouts und Lastgrenzen schützen die Produktivdatenbank – auch bei unglücklich formulierten Fragen zur Stoßzeit.

Lückenloses Protokoll

Jede Frage, jedes generierte SQL und jedes Ergebnis wird protokolliert. Auswertungen bleiben nachvollziehbar – auch Monate später.

Ausgedruckte Berichte mit Diagrammen und Tabellen neben einem Laptop auf einem Schreibtisch

Ausgaben

Vom Ergebnis zum Bericht

Eine Trefferliste ist selten das Ende einer Auswertung. Deshalb formatiert die Datenbank-KI Ergebnisse direkt weiter: als Excel-Datei für die Weiterverarbeitung, als PDF-Bericht mit Diagrammen für Ablage und Verteiler oder als kurze Management-Zusammenfassung, die das Ergebnis in zwei Sätzen einordnet.

Wiederkehrende Auswertungen lassen sich terminieren: Der Wochenbericht entsteht dann automatisch und landet als PDF im Postfach. So fügt sich KI-Reporting in vorhandene Abläufe ein, statt ein weiteres Werkzeug zu erzwingen, das niemand öffnet.

  • Excel-Export mit Rohdaten und formatierten Tabellen
  • PDF-Berichte mit Diagrammen und Erläuterungstext
  • Management-Zusammenfassungen in verständlicher Sprache
  • Zeitgesteuerte Berichte per E-Mail oder Ablage

Einsatzbeispiele

Eine Frage, drei Abteilungen: Controlling, Logistik, HR

Im Controlling entstehen die meisten Ad-hoc-Fragen: offene Posten je Kunde, Umsätze je Kostenstelle, Materialbewegungen der letzten Wochen. Wo eineWarenwirtschaft Bestands- und Auftragsdaten sauber führt, macht die Datenbank-KI daraus Antworten – ohne dass für jede Monatsfrage ein neuer Report gebaut werden muss.

In der Logistik ändern sich Fragen mit jeder Tour: Welche Fahrzeuge stehen morgen zur Verfügung? Welche Lieferungen hängen, welche Kosten je Kilometer laufen aus dem Ruder? Flottenkennzahlen aus einer Fuhrparksoftware wieLOGAS lassen sich so per Frage auswerten – der Disponent bleibt in seinem Ablauf, statt zwischen Auswertungsmasken zu wechseln.

Im Personalbereich geht es um Fristen und Nachweise: Wessen G26-Untersuchung läuft in den nächsten sechzig Tagen ab, wer ist für das anstehende Projekt einsatzfähig? Daten aus der DESTE Qualifikationsmatrixwerden per Frage geprüft. Weil Personaldaten sensibel sind, kombinieren viele Kunden die Abfrage mit lokaler KI – dann verlassen weder Fragen noch Ergebnisse das Haus.

Vorgehen

In drei Schritten zur sicheren Datenbank-KI

Der Aufwand liegt nicht im Sprachmodell, sondern im sauberen Fundament: Datenmodell beschreiben, Zugriffe absichern, Ausgaben gestalten.

  1. 01

    Schritt 1

    Datenmodell verstehen

    Tabellen, Beziehungen, Fachbegriffe und typische Fragen aus dem Fachbereich werden dokumentiert. Daraus entsteht der Schema-Katalog, mit dem die KI arbeitet – je präziser er ist, desto besser die Abfragen.

  2. 02

    Schritt 2

    Abfragen absichern

    Read-only-Konto, freigegebene Tabellen, Zeilenlimits und Validierungsregeln werden eingerichtet. Echte Testfragen aus Controlling, Disposition oder HR zeigen, ob die Ergebnisse fachlich stimmen.

  3. 03

    Schritt 3

    Ausgaben gestalten

    Ergebnisse werden als Liste, Diagramm, Excel-Datei, PDF-Bericht oder Management-Zusammenfassung aufbereitet – und auf Wunsch zeitgesteuert per E-Mail oder Ablage verteilt.

FAQ

Häufige Fragen zu Text-to-SQL und Datenbank-KI

Antworten auf die Fragen, die IT-Leiter und Fachbereiche in Erstgesprächen am häufigsten stellen.

Wie funktioniert Text-to-SQL?

Ein Sprachmodell erhält eine Beschreibung des Datenmodells – Tabellen, Beziehungen, Fachbegriffe – und übersetzt eine Frage wie „Umsatz je Kunde im letzten Quartal“ in eine SQL-Abfrage. Diese wird validiert, read-only ausgeführt und das Ergebnis als Liste, Diagramm oder Bericht aufbereitet. Die Qualität hängt vor allem davon ab, wie gut das Datenmodell für die KI beschrieben ist.

Ist Text-to-SQL sicher für unsere Produktivdatenbank?

Ja, wenn die Architektur stimmt: Der Zugriff läuft über ein eigenes Datenbankkonto mit reinen Leserechten, nur freigegebene Tabellen sind sichtbar, jede generierte Abfrage wird vor der Ausführung validiert, und Zeilenlimits sowie Timeouts schützen die Performance. Schreiboperationen sind technisch ausgeschlossen, nicht nur organisatorisch verboten.

Ersetzt Datenbank-KI unser BI-Tool oder bestehende Reports?

Nein, sie ergänzt sie. Standardberichte und Dashboards bleiben sinnvoll für wiederkehrende Kennzahlen; die Datenbank-KI beantwortet die spontanen Fragen dazwischen, für die sich kein eigener Report lohnt. Häufig gestellte Fragen lassen sich später in feste Berichte überführen.

Welche Datenbanken lassen sich anbinden?

Grundsätzlich alle gängigen relationalen Datenbanken, etwa Microsoft SQL Server, PostgreSQL, MySQL/MariaDB oder Oracle. Entscheidend ist weniger das Datenbanksystem als das Datenmodell: Tabellen, Beziehungen und Fachbegriffe müssen je Datenbank individuell beschrieben werden, die Architektur dahinter bleibt wiederverwendbar.

Was passiert, wenn die KI eine Frage falsch versteht?

Da alle Abfragen read-only laufen, kann eine falsch verstandene Frage keine Daten verändern. Das generierte SQL lässt sich vor der Ausführung anzeigen, Ergebnisse enthalten eine Erklärung, welche Tabellen und Filter verwendet wurden, und jede Abfrage wird protokolliert. Unplausible Ergebnisse fallen so schnell auf, und die Frage kann präziser gestellt werden.

Können auch sensible Daten wie Personaldaten abgefragt werden?

Ja, mit passenden Schutzmaßnahmen: Rollen und Berechtigungen steuern, wer welche Tabellen und Spalten abfragen darf; sensible Felder können ausgeblendet oder pseudonymisiert werden. Auf Wunsch läuft das Sprachmodell lokal auf eigener Infrastruktur, sodass weder Fragen noch Ergebnisse an externe Dienste gehen.

Kontakt

Erstgespräch zur Datenbank-KI

Schildern Sie kurz Datenbank, Systemlandschaft und typische Auswertungen – wir antworten in der Regel innerhalb eines Werktags mit einer ersten Einschätzung.