vorheriger Artikel
Große Teile an bisher manueller Programmierung können durch DWA-Tools abgelöst oder zumindest stark vereinfacht werden. Welche Teile der Entwicklung dabei genau automatisiert werden können, kann von Tool zu Tool stark differieren. So gibt es Ansätze von reinen Code-Generatoren, mithilfe derer Datenbankstrukturen und ETL-/ELT-Prozesse automatisch generiert werden können („design-time“). Auf der anderen Seite existieren umfangreiche Integrationssuiten, die den gesamten DWH-Lebenszyklus, von der Bereitstellung der Daten in den Quellen bis hin zu den Data Marts, generieren, aber auch verwalten können („run-time“).
Bei der Entwicklung gibt es eine Reihe von Aufgaben, bei denen ein DWA-Tool unterstützen kann. Im Folgenden wird insbesondere auf die Bereiche Reverse Engineering und Kompatibilität, Analyse, Implementierung und Rahmenbedingungen eingegangen.
Reverse Engineering und Kompatibilität
DWA kann in unterschiedlichen Projektszenarien eingesetzt werden. Mögliche Szenarien reichen von der Erweiterung über die Modernisierung eines DWH bis hin zu einer (Teil-)Neuerstellung.
Mögliche DWH-Projektszenarien
In den meisten Fällen existiert bereits eine DWH-Lösung. Dementsprechend kann es für die Auswahl eines DWA-Tools entscheidend sein, inwieweit eine Kompatibilität mit dem alten DWH gegeben ist. Wo einige Tools das bestehende DWH lediglich als Quelle nutzen, können andere an dem bereits entwickelten Datenmodell anknüpfen und dieses weiterentwickeln.
Bestimmte DWA-Tools fahren den Ansatz, ausschließlich auf einer bereits vorbereiteten Datenbasis aufzusetzen („Pre“-Stage). Dadurch wird eine systematische Trennung zwischen der Datenbereitstellung und der Datenverarbeitung verfolgt. Die Stage fungiert somit als Schnittstelle, bei der alle notwendigen Vorbereitungen bereits getroffen wurden. Hier kann die Notwendigkeit weiterer, externer Tools zur Datenmanipulation und zur Beladung der Stage-Tabellen bestehen.
Andere DWA-Tools bieten einen ganzheitlicheren Ansatz. Dazu gehören spezifische Konnektoren, mit denen direkt auf Quellsysteme zugegriffen werden kann, sowie Möglichkeiten nachträglicher Datenmanipulationen. Dadurch wird die Chance erhöht, die gesamte Datenverwaltung allein über ein DWA-Tool abbilden zu können.
Beim Bereitstellen von Daten aus den Quellsystemen können DWA-Tools gewissen Einschränkungen unterliegen, wie:
- ausschließlich Standardtreiber wie ODBC verfügbar
- keine Delta-Ermittlung möglich
- keine Realtime-Verarbeitung möglich
- keine Anbindung an Cloud-Plattformen oder Big-Data-Anwendungen möglich
Mithilfe einer vorgelagerten Bestandsaufnahme bestehender sowie potentieller Quellsysteme sollten DWA-Tools vorab auf mögliche Kompatibilitätsprobleme und weitere Einschränkungen geprüft werden.
Analyse
Damit Datenbankstrukturen und Datenbewirtschaftungsprozesse automatisiert erstellt werden können, muss die Beschaffenheit von abgebenden Quellsystemen analysiert werden. DWA-Tools bieten zumeist ein Reverse Engineering von Datenbankstrukturen an, bei dem Basisinformationen gesammelt werden können. Dabei muss auch hier wieder die Kompatibilität mit verschiedenen Datenbanken geprüft werden. Die Basis dabei bilden übliche Metainformationen von DBMS wie Spaltentypen, Integritätsbedingungen, Beziehungen, aber auch erweiterte Objektstatistiken. Jedoch existieren in der betrieblichen Praxis nur selten Quellsysteme, die über eine lückenlose und allumfassende Datenbasis verfügen. Sowohl plattformabhängige Optimierungen als auch nutzergetriebene Modifikationen können die automatisierte Analyse von Quellsystemen erschweren. Die Qualität des erzeugten DWH-/ETL-Codes ist jedoch maßgeblich davon abhängig, wie detailliert Metainformationen dem DWA-Tool zur Verfügung stehen. Hier muss das DWA-Tool dem Entwickler möglichst praktikable Werkzeuge an die Hand geben, um fehlende Informationen in die Metadaten nachzutragen. Ein Großteil der gefühlten Usability ist von diesem Aufgabenfeld abhängig, da es sich hierbei um eine der wichtigsten Stellschrauben handelt, über die der Entwickler das Verhalten des Tools beeinflussen kann. So kann die fehlende Berücksichtigung der Bedeutung einzelner Objekte und ihrer Beziehungen zur späteren Restrukturierung ganzer Systemausschnitte führen.
Neben der strukturellen Analyse können Datenbestände durch Profiling-Funktionalitäten vorab analysiert werden. Die Unterstützung der DWA-Tools reicht hier vom reinen automatisierten Absetzen verschiedener Abfragen über die anschließende Ausgabe der Ergebnisse bis hin zu Designvorschlägen. So bietet es sich möglicherweise an, Objekte mit großen Datenaufkommen und hoher Änderungsrate im Deltaverfahren und in (Near-)Realtime von den Quellen zu transferieren und andere hingegen als Vollabzug auf Tagesbasis.
Weiterhin sollte ein Data Lineage auf DWH-Seite vereinfacht möglich sein, da alle hierfür notwendigen Metainformationen dem Tool bereits vorliegen. Den entscheidenden Unterschied machen dabei die Form der Visualisierung des Lineages und die Möglichkeit des Entwicklers zur Interaktion. Erschwert wird ein lückenloses Lineage durch bestimmte Freiheitsgrade des Entwicklers. Wird an einer bestimmten Stelle des ETL-Prozesses beispielsweise dynamisches SQL oder externer Code prozessiert, ist es für das DWA-Tool (und nebenbei in einigen Fällen auch für Menschen) nahezu unmöglich, den Prozessfluss lückenlos nachzuvollziehen. An dieser Stelle ist es Aufgabe des DWA-Tools und des Entwicklers, ein gesundes Mittelmaß an Freiheitsgraden und Standardisierung zu finden.
Implementierung
DWA-Tools sind bis dato noch nicht in der Lage, das eigentliche DWH vollständig zu abstrahieren, sodass es dem Entwickler/Fachanwender wie eine Blackbox vorkommt. Die eigentliche Entwicklertätigkeit innerhalb der verschiedenen DWA-Tools kann sich je nach Grad der Automatisierung in Umfang und Komplexität stark unterscheiden. Je breiter der Einsatz des DWA-Tools gewählt wird, desto mehr nicht- oder teilautomatisierte Eingriffe des Entwicklers können durchgeführt werden:
Manuelles Coding bei Data-Warehouse-Automatisierungs-Tools
Wie in der Abbildung zu sehen, können über die gesamte DWH-Schichtenarchitektur hinweg manuelle Eingriffe notwendig sein. Beim Übergang von den Quellsystemen in die Abstraktionsschicht müssen sog. „Hard Rules“ definiert werden. Quellspezifische Datentypen müssen möglicherweise konvertiert und harmonisiert werden, oder eine für das DBMS ungeeignete Struktur muss vorstrukturiert werden. Hier können spezifische Fragestellungen und Trade-offs eine Rolle spielen, die eine menschliche Entscheidung unabdingbar machen. Im Optimalfall müssen Hard Rules nur einmal je Quellsystem definiert werden und das DWA-Tool bietet bereits vordefinierte Lösungswege an.
Während des Übergangs von Abstraktionsschicht zu Integrationsschicht werden hingegen typischerweise „Soft Rules“ angewandt. Hier finden die eigentlichen Integrationsaufwände statt, die für eine einheitliche und konzernweite Datenbasis, das Core DWH, notwendig sind. Dazu zählt u. a. das Harmonisieren von Business Keys.[1] Wird eine Teilung des Core DWH verfolgt, wie es bspw. mit dem RAW- und Business-Vault bei der Data-Vault-Modellierung vorkommen kann, verlagern sich die Soft Rules auf den Übergang vom RAW-Vault in den Business-Vault. Aufgaben wie die technische Historisierung der Daten können hingegen vereinfacht mithilfe des DWA-Tools gelöst werden.
Für die Präsentationsschicht werden die Daten so aufbereitet, dass sie in Form und Darstellungsweise den Wünschen des Fachbereichs entsprechen. Ergeben sich Aufgabenstellungen, die die einfache technische Generierung eines Star-Schemas oder einer einfachen View übersteigen, muss auch hier eingegriffen werden. Einige Tools gehen noch einen Schritt weiter und können Datenstrukturen für gängige Reporting-Werkzeuge vorgenerieren.
Bei manuellen Eingriffen ist das Synchronisieren dieser mit dem DWA-Tool entscheidend. Eingriffe müssen nicht nur ermöglicht oder vereinfacht werden, sondern in die Arbeitsweise des DWA-Tools eingebettet werden. Andernfalls könnten diese bei erneuter Codegenerierung überschrieben werden oder sogar zu weitreichenderen Komplikationen wie inkonsistenten Daten führen. Beschränkt sich das Tool lediglich auf das Generieren des Codes zum Erzeugen der Datenbankobjekte sowie der Datenbewirtschaftungsprozesse eines bestimmten Systemausschnitts (bspw. das Staging), so müssen wenige Eingriffe getätigt werden. Jedoch muss ein Großteil der notwendigen Schritte mit separater Software, wie einem Datenbankentwicklungswerkzeug, erstellt werden.
Rahmenbedingungen
Im Projektgeschäft kann es vorkommen, dass nicht nur mehrere Entwickler eines Unternehmens, sondern weitere Entwicklerteams anderer Unternehmen an denselben Datenbankstrukturen arbeiten. Dabei sind Metadaten des DWA-Tools genauso betroffen wie die Datenbankstrukturen der DWH-DB, wodurch sich gewisse Anforderungen ergeben. Es muss sichergestellt werden, dass Änderungen eines Entwicklers nicht die Änderungen eines anderen Entwicklers konterkarieren. Um dies zu erreichen, nutzen einige DWA-Tools die Funktionen von Version Control Systems (VCS). Nutzt das DWA-Tool OS-basierte Konfigurationsdateien, können die VCS-typischen Funktionalitäten wie das Ein- und Auschecken von Objekten sowie MERGE genutzt werden, um die verteilte Entwicklung zu erleichtern. Andere DWA-Tools speichern ihre Metainformationen ausschließlich in Datenbankschemata. Hier kann das mehrfache Editieren desselben Objekts durch die GUI des DWA-Tools sowie durch die Transaktionssicherheit der Datenbank reglementiert werden. Über DB-Backups und Flashbacks kann zusätzlich zu einem früheren konsistenten Stand zurückgerollt werden, was jedoch nur bedingt auf Einzelsatzbasis funktioniert.
Zusammenfassung
Zu Beginn einer DWA-Initiative sollte feststehen, welche Teilbereiche der Entwicklung vom DWA-Tool abgedeckt werden sollen. Werden über die reine (Teil-)Generierung von Code hinaus bspw. erweiterte Profiling-Funktionalitäten benötigt, macht eine umfangreiche Integrationssuite mehr Sinn, als verschiedene Tools mit teils überlappendem Funktionsumfang zu nutzen. Je allumfassender ein DWA-Tool jedoch ausgestattet wird, desto stärker muss der Entwickler auch mit dem Tool interagieren können. Die wesentliche Herausforderung für DWA-Tools ist dabei, trotz einer immer breiteren Abdeckung an Funktionalitäten eine intuitive und eingängige Haptik zu bieten, sodass Vorteile der Automatisierung überhaupt flächendeckend und konsistent genutzt werden können. Besonders in der Art und Weise, in der die unterschiedlichen DWA-Tools den Entwickler bei der Definition von Soft Rules unterstützen, existiert noch viel Luft nach oben; das könnte in Zukunft zu einem wichtigen Differenzierungsmerkmal werden.
Es wäre falsch anzunehmen, dass mit dem Einsatz von DWA-Tools weniger fachspezifisches Know-how für die Entwicklung eines DWH notwendig sein wird. Wie zuvor beschrieben sind weiterhin viele Entscheidungen während der DWH-Entwicklung zu treffen und viele Problemstellungen zu lösen. Dagegen findet eher eine Verschiebung der Aufgabenstellungen statt, weg von technischen Detailfragen wie der Historisierung von Datenbankstrukturen hin zu konzeptuellen Fragestellungen. Die Entwicklungstätigkeit mit einem DWA-Tool ist somit verstärkt davon bestimmt, neue Standards einzuführen sowie bestehende konstant in Frage zu stellen, um die besten Lösungen für ein individuelles DWH-System zu entwickeln. Die Praxis zeigt jedoch auch, dass DWA-Tools gewisse Standards auch hart einfordern, wodurch der Handlungsspielraum beschränkt werden kann. So kann u. a. eine gewisse Layer-Architektur, Modellierungsvariante, Namenskonvention oder auch Beladungsstrategie vorgegeben werden. Nicht selten führt dies zu einem Alignment von Prozessen und Entwicklerverhalten an das DWA-Tool, was besonders von Unternehmen mit bestehenden DWH-Lösungen oder stark ausgeprägter Standardisierung berücksichtigt werden sollte.
[1] Wird Data-Vault für die Modellierung des Core DWH verwendet, wird dieser Schritt typischerweise während des Übergangs vom RAW-Vault in den Business-Vault vollzogen.
