In DWH-Landschaften werden naturgemäß aus unterschiedlichsten Quellsystemen Daten zur Verarbeitung herangezogen. In diesem Beitrag werden wir uns mit einigen Problemen von indirekten Datenzugriffen und im Vergleich dazu den Vorteilen von direkten Datenzugriffen (auch virtualisierter Datenzugriff) befassen.
Nicht selten handelt es sich bei den unterschiedlichen Quellsystemen um heterogene Datenbanken. Diese Datenbanklandschaften bestehen häufig aus den Lösungen unterschiedlicher Hersteller, die sich gegenseitig Daten bereitstellen sollen, auch über ihre physischen und herstellerspezifischen Grenzen hinweg. Häufig werden dafür File-Schnittstellen eingesetzt, um Daten über die Datenbank/-instanz/-en hinweg auszutauschen. Dadurch findet die initiale Extraktion der Daten außerhalb der ETL-/ELT-Tools des DWH statt. Dieser Typ der Datenlieferung kann als indirekter Datenzugriff bezeichnet werden.
Mögliche Probleme von indirektem Datenzugriff
Durch den Einsatz indirekter Datenzugriffe ergeben sich in der Praxis einige Probleme. Diese Probleme beziehen sich auf die Verarbeitung der Daten im Zielsystem. Aber vor allem mit Hinblick auf die immer stärkere Forderung nach Agiler BI lassen sich im indirekten Datenzugriff, im Vergleich zum direkten Datenzugriff, Schwachstellen identifizieren. Häufige Probleme eines indirekten Datenzugriffes sind:
- Erweiterungskosten: Eine Erweiterung der Datenlieferung erfordert erst eine häufig aufwendige Verhandlungs- und Spezifikationsphase mit dem Datenlieferanten bzgl. der Schnittstelle. Auch vermeintlich kleine Änderungen können in so komplexen Strukturen wie denen eines DWHs sehr oft zu ungeahnt heftigen Seiteneffekten führen, ohne eine entsprechend genau durchgeführte Voranalyse
- Asynchrone Entwicklung: Die Weiterentwicklung der Schnittstelle läuft meistens nicht in einem synchronen Prozess, bei allen Beteiligten. Dabei führen aber bereits kleine nicht kommunizierte Umbauten und Erweiterungen für alle Beteiligten häufig zu hohem Mehraufwand
- Datengültigkeit: Durch indirekten Datenzugriff verarbeitete Daten können immer nur einen stichpunktartigen Gültigkeitsbereich besitzen
- Datenqualität: Die Datenqualität kann vom Empfänger häufig erst nach einem Ladeversuch beurteilt werden. Frühzeitige Gegenmaßnahmen können so nicht getroffen werden, um die Datenqualität zu steigern/sichern
- Datenkorrektur: Notwendige Datenkorrekturen benötigen häufig eine Nachlieferung aus dem Quellsystems. Besonders bei monolithischen ETL-/ELT-Abläufen kann das, neben der Wartezeit, auch erhöhten Korrekturaufwand bedeuten, je nach Zeitpunkt des Fehlers
- Sicherheitskontext: Der Sicherheitskontext der Daten geht verloren, wenn keine Gegenmaßnahmen auf der Empfängerseite existieren um diesen bereitzustellen
Virtualisierter Datenzugriff als Lösungsansatz
Als Lösungsansatz für all diese Problemstellungen kann der virtualisierte Datenzugriff herangezogen werden. Als virtualisierter Datenbankzugriff kann ein direkter Zugriff auf die Datenquelle verstanden werden, der aus dem verarbeitenden System heraus stattfindet. Somit ergibt sich bei einer Gegenüberstellung der Verfahren folgendes Bild, bezogen auf die genannten Probleme:
- Erweiterungskosten: Durch den direkten Datenzugriff, kann nach einer kurzfristigen Absprache eine Änderung rasch umgesetzt und getestet werden. Seiteneffekte können somit früh aufgedeckt und Änderungswünsche wesentlich schneller umgesetzt werden
- Asynchrone Entwicklung: Ein solches Szenario ist bei einem virtuellen Datenzugriff gar nicht realisierbar. Jede Änderung fällt beim nächsten Datenzugriff auf der Empfängerseite auf, der Zugriff des Zielsystemes findet unmittelbar statt
- Datengültigkeit: Die Daten sind aus Sicht beider Systeme immer in einem äquivalenten Zustand. Es kann also im Vergleich zu einem indirekten Datenzugriff kein veralteter Stand existieren. Hier ist es aber sehr wichtig, die Daten aus der Quelle bzgl. ihrer technischen und inhaltlichen zeitlichen Gültigkeitsabgrenzung differenzieren zu können. Microsoft bietet mit dem SQL Server 2016 eine interessante Lösung die dieser Forderung gerecht werden kann, in Form von Temporal Tables
- Datenqualität: Die Datenqualität ist bereits früh bekannt im Zielsystem und entsprechende Gegenmaßnahmen können bei schlechter Qualität somit frühzeitig eingeleitet werden. Gemäß der 10er Regel für die Fehlerkosten, können hier im Vergleich immense Kostenersparnisse realisiert werden. Diese Aussage kann im Grunde genommen auf alle hier angeführten Punkte reflektiert werden
- Datenkorrekturen: Notwendige Datenkorrekturen in dem Quellsystem sind im Empfangssystem direkt sichtbar. Wichtig ist hier nochmal die Anmerkung unter „Datengültigkeit“ bzgl. der Temporal Tables
- Sicherheitskontext: Der Sicherheitskontext aus dem Quellsystem kann 1:1 übernommen werden
Unterschiedliche Datenbankhersteller bieten hierfür Lösungen. Dabei existieren sicherlich herstellerspezifische Einschränkungen, die es zu beachten gilt. Diese werden hier aber im einzelnen nicht näher besprochen. Oracle bietet beispielsweise Database Links an und unter SQL Server existiert ein Pendant, der sich Linked Server nennt.
