Im thinkBI Podcast wandert der Dashboard Creation Cycle weiter von der Planungsseite in die Umsetzung. Nachdem geklärt wurde, welche Daten fachlich relevant sind und wo ihre Herkunft liegt, stellt sich nun eine sehr konkrete Frage: Wie greifen wir auf diese Daten zu?
Eine naheliegende Antwort lautet oft: direkt auf die SQL-Datenbank. Das klingt effizient. Und technisch ist es das häufig auch. Aber genau darin liegt die Spannung. Denn eine operative Datenbank ist nicht einfach ein neutraler Speicher, aus dem BI beliebig lesen kann. Sie ist Teil eines laufenden Systems. Oft ist sie sogar dessen Herz.
Direkter Zugriff wirkt einfacher, als er ist
SQL-Datenbanken sind für BI attraktiv, weil viele Vorsysteme ihre Daten dort speichern. Wenn Tabellen, Spalten und relevante Filterbedingungen bekannt sind, lässt sich eine Abfrage sehr gezielt formulieren. Man kann bestimmte Spalten laden, Zeilen über Bedingungen eingrenzen und Daten vergleichsweise effizient in eine BI- oder Datenplattform übernehmen.
In den ersten Iterationen wird dabei häufig mit einem Full Load gearbeitet. Das bedeutet: Bei jedem Ladevorgang werden alle relevanten Daten erneut geladen. Für den Anfang ist das oft pragmatisch. Man bekommt Änderungen mit, muss noch keine differenzierte Änderungslogik bauen und kann den Prozess schneller stabilisieren.
Aber Full Loads skalieren nicht beliebig. Je größer die Tabellen werden, desto stärker stellt sich die Frage, ob wirklich jedes Mal alles gelesen werden muss. Dann kommen inkrementelle Ladeprozesse ins Spiel. Sie laden nur noch das, was seit dem letzten Lauf hinzugekommen ist oder sich verändert hat.
Damit beginnt allerdings eine neue Verantwortung. Das System muss erkennbar machen, was sich geändert hat. Es braucht Zeitstempel, Änderungskennzeichen, Change-Log-Mechanismen oder Verfahren wie Change Data Capture. Besonders schwierig wird es bei Löschungen. Ein Datensatz, der nicht mehr vorhanden ist, meldet sich nicht von selbst. Ohne Soft Delete, Löschkennzeichen oder technische Änderungsprotokolle kann BI nur schwer erkennen, dass etwas verschwunden ist.
Lesen ist nicht folgenlos
In vielen BI-Projekten klingt Lesen zunächst harmlos. Man verändert ja nichts. Man schreibt keine Daten in das operative System zurück. Also müsste der Zugriff unkritisch sein.
Diese Annahme ist zu einfach.
Auch lesende Prozesse können ein operatives System beeinflussen. Große Abfragen nutzen Ressourcen. Sie berühren Indizes. Sie füllen Caches mit Daten, die für den operativen Betrieb vielleicht gerade nicht relevant sind. Wenn ein Nachtlauf sehr große Datenmengen liest, kann er den Speicher mit historischen oder selten genutzten Datensätzen belegen. Am nächsten Morgen muss das operative Geschäft relevante Daten erst wieder neu in den Cache bringen.
Das ist keine theoretische Feinheit. Es zeigt, dass BI nicht außerhalb des Systems steht. BI nutzt dieselben technischen Grundlagen, auf denen operative Prozesse laufen. Deshalb ist die Frage nicht nur, ob ein Zugriff möglich ist. Die Frage ist, ob er in der konkreten Lastsituation verantwortbar ist.
Der klassische Ausweg ist der Nachtlauf. Tagsüber läuft das operative Geschäft, nachts übernimmt BI die Daten und stellt am nächsten Morgen vortagesaktuelle Informationen bereit. Dieses Muster ist nachvollziehbar und in vielen Organisationen weiterhin sinnvoll. Aber es ist nicht mehr überall selbstverständlich. E-Commerce, Internationalisierung und durchgängige digitale Prozesse haben die Vorstellung eines ruhigen Nachtfensters stark relativiert. Manche Systeme haben keinen echten Feierabend mehr.
Konsistenz hat einen Preis
Ein weiteres Risiko entsteht dort, wo BI einen konsistenten Stand lesen möchte, während das operative System weiterarbeitet. Datenbanken müssen laufend lesen, schreiben, ändern und löschen. Wenn ein BI-Prozess eine große Tabelle liest, kann er je nach Isolation und Zugriffsmuster Bereiche blockieren oder selbst von anderen Transaktionen blockiert werden.
Daraus können Deadlocks entstehen. Zwei Prozesse warten dann gegenseitig auf Ressourcen, die der jeweils andere hält. Irgendwann entscheidet die Datenbank, welcher Prozess abgebrochen wird. Für BI ist das besonders unangenehm, wenn ein langer Ladeprozess kurz vor dem Ende beendet wird, weil ein operativer Schreibprozess Vorrang bekommt.
Auch hier zeigt sich: Der direkte Datenbankzugriff ist nicht nur eine technische Bequemlichkeit. Er ist ein Eingriff in einen laufenden Betriebszusammenhang. Ein Ladeprozess muss deshalb so entworfen werden, dass er das operative Geschäft möglichst wenig behindert und zugleich selbst stabil genug ist, um nicht ständig an operativen Transaktionen zu scheitern.
Replikate schaffen Abstand
Eine mögliche Antwort ist die Arbeit mit Replikaten. Das operative System schreibt auf die primäre Datenbank. Änderungen werden auf einen zweiten Server repliziert, der für lesende Zugriffe genutzt werden kann. BI greift dann nicht direkt auf das aktive Herz des operativen Systems zu, sondern auf eine Kopie, die speziell für Auswertungs- oder Ladeprozesse bereitsteht.
Das löst nicht alle Fragen. Replikation muss betrieben, überwacht und verstanden werden. Verzögerungen, Konsistenz und technische Architektur bleiben relevant. Aber das Prinzip ist wichtig: Gute BI-Architektur schafft Abstand zwischen operativer Belastung und analytischem Zugriff, wo dieser Abstand notwendig ist.
Damit wird auch verständlich, warum Applikationsverantwortliche direkten Datenbankzugriff oft kritisch sehen. Aus BI-Perspektive wirkt die Datenbank wie eine wertvolle Quelle. Aus Sicht des Applikationsbetriebs ist sie ein zentraler Nerv des operativen Geschäfts. Wer dort zugreift, muss erklären können, warum, wie oft, mit welcher Last und mit welchem Sicherheitskonzept.
Datenzugriff ist Betriebsverantwortung
Der eigentliche Perspektivwechsel liegt darin, Datenaufnahme nicht nur als technische Beschaffung zu sehen. Sobald BI operative Systeme anzapft, übernimmt sie Mitverantwortung für deren Stabilität. Die SQL-Abfrage ist dann nicht nur Mittel zum Zweck. Sie ist Teil einer Architekturentscheidung.
Deshalb genügt es nicht, eine Tabelle zu finden und erfolgreich zu laden. Man muss verstehen, welche Änderungslogik vorliegt, welche Last der Zugriff erzeugt, wann das System belastbar ist, wie Konsistenz hergestellt wird und wann eine entkoppelte Bereitstellung sinnvoller ist.
Gute BI will Daten verfügbar machen. Reife BI tut das, ohne die Systeme zu beschädigen, aus denen diese Daten stammen.
Vielleicht ist das die nüchterne Kernthese dieser Phase im Dashboard Creation Cycle: Datenzugriff ist nicht erst dann kritisch, wenn geschrieben wird. Auch Lesen braucht Architektur, Timing und Verantwortung.
🎧 Die komplette Folge findest du im thinkBI Podcast.
Musik: Great Podcast Intro (short & long) von Lundstroem
Quelle: freemusicarchive.org (Creative Commons) – https://freemusicarchive.org/music/lundstroem/songs-for-leona/great-podcast-intro-both-short-and-long-version-included/
