KI Data Warehouse Alternative
Kein Data Warehouse, keine Modellierungs
Wer eine KI-Data-Warehouse-Alternative sucht, hat meist schon ein Angebot auf dem Tisch: erst Daten zusammenführen, dann modellieren, dann auswerten. Diese Reihenfolge ist nicht falsch – sie ist nur teuer erkauft, wenn das Ziel eine Antwort auf eine Fachfrage ist und nicht eine Plattform.
Die übliche Reihenfolge
Das Projekt beginnt nicht mit der Frage, sondern mit dem Umzug.
Ein klassisches Vorhaben für auswertbare Daten arbeitet von unten nach oben: Quellen anbinden, Daten regelmäßig übertragen, Historie aufbauen, Kennzahlen modellieren, Berichte bauen. Erst am Ende dieser Kette steht die erste Antwort auf eine Fachfrage – und bis dorthin sind Monate vergangen, in denen niemand im Fachbereich etwas davon hat.
Der Aufwand entsteht dabei nicht durch das Auswerten, sondern durch das Verschieben und Nachbilden: Dieselbe Geschäftslogik, die in Ihrer Anwendung längst implementiert ist, wird im Zielmodell ein zweites Mal beschrieben. Ab diesem Moment gibt es sie zweimal – und sie kann auseinanderlaufen.
Ein Data-Warehouse-Projekt verschiebt Daten. Es erklärt sie nicht.
Genau diese Erklärung ist aber der Teil, der für eine KI gebraucht wird. Ob eine Rechnung als offen gilt, welche der drei Datumsspalten die fachlich richtige ist und was in Ihrem Haus ein Neukunde ist – das ist Bedeutung, nicht Datenbewegung. Und Bedeutung lässt sich beschreiben, ohne vorher einen einzigen Datensatz zu kopieren.
Der kürzere Weg
Beschreiben statt umziehen.
Der Ansatz setzt an der anderen Seite an: nicht bei den Daten, sondern bei ihrer Bedeutung. Die Datenbank bleibt, wo sie ist.
- 1
Erschließen, was schon da ist
Datenmodell und Sourcecode Ihrer bestehenden Anwendung werden gelesen und daraus ein Vorschlag für das Fachmodell erzeugt: Begriffe, Beziehungen, Regeln. Der Sourcecode ist dabei die ergiebigste Quelle, weil die Geschäftslogik dort tatsächlich steht – und nicht in einer Dokumentation, die veraltet ist.
- 2
Fachlich bestätigen
Der Vorschlag ist ein Vorschlag und kein Ergebnis. Ihr Fachbereich geht die Begriffe durch, korrigiert Definitionen und ergänzt, was im Code nicht steht. Dieser Schritt ist der einzige, der unabhängig vom Werkzeug ohnehin fällig wäre – auch ein Data-Warehouse-Projekt kommt nicht ohne ihn aus, es nennt ihn nur anders.
- 3
Auf dem Bestand auswerten
Gefragt wird anschließend gegen die bestehende Datenbank, ausschließlich lesend. Kein zweiter Datenbestand, keine Synchronisation, keine Pipeline, die nachts durchlaufen muss – und damit auch keine Frage, wie aktuell die Auswertung ist.
Gegenüberstellung
Zwei Wege zur auswertbaren Zahl.
Die Spalten beschreiben keine besseren und schlechteren Werkzeuge, sondern zwei unterschiedliche Reihenfolgen – mit unterschiedlichen Kosten und unterschiedlichen Stärken.
Wann das Warehouse richtig bleibt
Vier Fälle, in denen die Vorstufe die richtige Antwort ist.
Ein Data Warehouse ist kein Umweg, sondern ein Werkzeug mit einem klaren Zweck. Trifft einer dieser Fälle auf Sie zu, ist es die bessere Wahl – und dann sagen wir das im Gespräch auch so.
Historie, die die Quelle nicht hat
Wenn Sie Zustände über Jahre vergleichen müssen, die Ihr Produktivsystem überschreibt, muss jemand diese Historie aufbauen. Aus einer Datenbank, die nur den aktuellen Stand kennt, lässt sich kein Rückblick lesen – gleich mit welchem Werkzeug.
Viele Quellen, die wirklich zusammengeführt werden müssen
Bei einer Handvoll Systemen mit klaren Zuständigkeiten genügt es, sie einzeln lesbar zu machen. Wenn dagegen Kundenstämme aus zehn Systemen zu einer Wahrheit verschmolzen werden sollen, ist das eine eigene Aufgabe – und eine Auswertungsschicht löst sie nicht.
Last, die vom Produktivsystem weg muss
Wenn schwere Auswertungen den laufenden Betrieb beeinträchtigen würden, ist eine getrennte Kopie ein triftiger Grund. In der Praxis lässt sich das häufig auch mit einer Leseinstanz lösen – aber es ist eine ernst zu nehmende Frage und keine Ausrede.
Regulatorische Nachweispflichten auf Datenstand
Wenn ein aufsichtsrechtlich festgelegter Stand zu einem Stichtag unveränderlich vorgehalten werden muss, ist eine archivierte Ablage keine Option, sondern eine Auflage.
In allen vier Fällen schließen sich die Wege nicht aus: Eine semantische Schicht kann auf einem vorhandenen Warehouse genauso aufsetzen wie auf einem Produktivschema. Wer schon eines betreibt, wirft es nicht weg.
Einordnung
Wo verbreitete Werkzeuge in diesem Bild stehen.
Sachliche Zuordnung, keine Bewertung: Die genannten Werkzeuge lösen Aufgaben, die hier nicht gelöst werden – und umgekehrt. Wenn Sie eines davon schon einsetzen, ist das kein Widerspruch: Bereits gepflegte Kennzahlendefinitionen sind eine gute Vorlage für das Fachmodell und ersparen einen Teil der Abstimmung.
- dbt und vergleichbare Transformationswerkzeuge
- Beschreiben Transformationen zwischen Datenstufen und machen sie versionierbar und testbar. Sie setzen voraus, dass die Daten im Zielsystem vorliegen – die Frage, wer sie dorthin bringt, bleibt davor.
- Cube und vergleichbare Semantic Layer
- Beschreiben Kennzahlen und Dimensionen über einem bereits aufbereiteten Modell. Die Aufbereitung ist Voraussetzung, und die Definitionen werden von Hand gepflegt.
- Werkzeuge zur Datenübertragung
- Bringen Daten aus Quellsystemen in ein Ziel. Sie übertragen Werte, nicht Bedeutung: Was eine Spalte fachlich heißt, ist danach genauso unbeschrieben wie vorher.
- Dieser Ansatz
- Erschließt die Bedeutung aus Datenmodell und Sourcecode und fragt lesend gegen den Bestand. Umgesetzt für PostgreSQL und MySQL, MySQL zusätzlich in der Alpha erprobt; das Produkt ist in der Pilot- und Validierungsphase.
Grenzen
Was dieser Weg nicht leistet.
Er baut keinen Datenbestand auf. Was in Ihren Quellen nicht steht, lässt sich auch nicht auswerten – eine fehlende Historie entsteht nicht dadurch, dass man anders fragt.
Er ersetzt die fachliche Abstimmung nicht. Der Vorschlag für das Fachmodell wird maschinell erzeugt, aber er muss bestätigt werden; dieser Schritt ist Arbeit in Ihrem Haus und wird hier nicht kleingeredet. Er fällt nur einmal an statt bei jeder neuen Frage.
Und er ersetzt kein Berichtswesen. Für eine Zahl, die jede Woche in derselben Form gebraucht wird, bleibt ein aufgebauter Report das bessere Mittel. Der Gewinn liegt bei den Fragen dazwischen – denen, für die sich ein eigener Report nie gelohnt hat.
Häufige Fragen
Fehlt Ihnen eine Frage? Ausführliche Antworten zu Betrieb und Datenzugriff stehen auf der Sicherheitsseite.
- Sind Auswertungen ohne Data Warehouse genauso verlässlich?
Die Verlässlichkeit hängt nicht daran, wo die Daten liegen, sondern daran, ob die fachlichen Regeln richtig beschrieben sind. Ein Warehouse macht eine falsch nachgebaute Kennzahl nicht richtig – es macht sie nur an einer zentralen Stelle falsch.
Der Unterschied hier ist die Prüfbarkeit: Zu jeder Antwort gehören die angewandten Regeln und die ausgeführte Abfrage im Wortlaut. Eine Abweichung ist damit nicht nur sichtbar, sondern auch erklärbar – und die Korrektur wirkt anschließend für jede vergleichbare Frage.
- Wir haben schon ein Data Warehouse. War das umsonst?
Nein, und es muss auch nicht ersetzt werden. Eine semantische Schicht kann genauso auf einem Warehouse aufsetzen wie auf einem Produktivschema; in vielen Häusern ist die Kombination die naheliegende – historische Fragen gegen das Warehouse, tagesaktuelle gegen die Quelle.
Vorhandene Kennzahlendefinitionen sind dabei ein Vorteil: Sie sind bereits abgestimmt und ersparen einen Teil der fachlichen Klärung.
- Wie verhält sich der Aufwand zu einem Data-Warehouse-Projekt?
Ehrliche Antwort: Das lässt sich nicht als Faktor angeben, und jede Zahl dazu auf einer Website wäre geraten. Was sich benennen lässt, ist die Verschiebung der Arbeit – es entfällt der Aufbau von Übertragung, Zielmodell und Historie, es bleibt die fachliche Klärung der Begriffe.
Belastbares dazu entsteht in der technischen Sichtung Ihres Systems: Größe und Zustand des Schemas und die Verfügbarkeit des Sourcecodes entscheiden über den Aufwand. Das Produkt ist in der Pilot- und Validierungsphase, und Zahlen aus Pilotprojekten gehören erst hierher, wenn sie freigegeben sind.
- Müssen die Daten vorher zusammengeführt werden?
Für eine Frage, die ein System betrifft, nicht: Dort genügt es, dieses eine System beschreibbar zu machen – und das ist auch der empfohlene Anfang.
Für eine Frage über Systemgrenzen hinweg braucht es eine fachliche Zuordnung zwischen ihnen, etwa welche Kundennummer im einen System welcher im anderen entspricht. Diese Zuordnung wird beschrieben, nicht durch einen Umzug hergestellt – vorhanden sein muss sie aber, und wenn sie nirgends existiert, ist das eine eigene Aufgabe.
Verwandte Themen
Angrenzende Fragen, jeweils auf einer eigenen Seite beantwortet.
Semantische Schicht
Was in der Schicht beschrieben ist, wie sie entsteht und warum ein Prompt sie nicht ersetzt.
Unternehmens-KI im Mittelstand
Der kleinste sinnvolle Einstieg ohne Datenabteilung: Aufwand, Reihenfolge, Risiko, Ausstieg.
Conversational BI
Auswertungen im Dialog statt im Report – und was mit dem vorhandenen BI-Werkzeug passiert.
KI für Unternehmens
Welche Ansätze es gibt, KI auf eigene Unternehmensdaten zu bringen – und woran sie in der Praxis scheitern.
Die belastbarste Prüfung ist eine Frage, für die heute ein Warehouse-Projekt vorgeschlagen wurde. Daran lässt sich zeigen, ob die Vorstufe dafür wirklich nötig ist.