DW werden häufig als fertige Lösungen angepriesen, mit denen sich nahezu beliebige Daten auswerten lassen. Tatsächlich ist jedoch auch nach der Implementierung eines unternehmensweiten DW eine ständige Anpassung und Weiterentwicklung des Systems der Normalfall. Dies führt erfahrungsgemäß zu Gesamtkosten, die, über einen Zeitraum von drei und fünf Jahren betrachtet, je nach Systemumfang Beträge in zwei- bis dreistelliger Millionenhöhe verschlingen. Eine Faustregel besagt dabei, dass 20 Prozent der Ausgaben für Hardware und Tools, 80 Prozent für Entwicklung und Wartung zu veranschlagen sind.
Die Implementierung der Software ist heutzutage weniger das Problem, zeitaufwendiger und schwieriger ist vielmehr die Umsetzung, Etablierung und das Leben der dazugehörigen Prozesse im Unternehmen. Diese Daueraufgabe sollte relativ hoch im Unternehmens-Management etabliert werden. Trotzdem muss natürlich auch das technische DW-Konzept stimmen: So muss beispielsweise zwischen der Speicherung der Daten in einer relationalen oder einer multidimensionalen Datenbank gewählt werden. Hauptkriterium ist, ob die Ladezeiten oder die Auswertungszeiten kritischer sind. Als erfolgreich hat sich auch eine Kombination erwiesen, bei der die einzelnen Data Marts multidimensional abgelegt sind, sich aber aus einem zentralen relationalen Warehouse speisen. Eine entscheidende Bedeutung kommt ferner der Datenmodellierung zu. Soll eine relationale Datenbank genutzt werden, gibt es keine Alternative zum Stern-Schema-Aufbau, da sich sonst Ad-hoc-Reporting nicht performant umsetzen lässt. Beim Aufbau eines DW können zudem so genannte ETL-Tools helfen, die die Schritte zur Datenaufbereitung und Speicherung unterstützen (Extraktion, Transformation, Laden). Hier ist kritisch zu prüfen, wie weit sich die Werkzeuge an die individuellen Anforderungen anpassen lassen oder ob stattdessen ein eigenes Framework entwickelt werden sollte (weitere Ratschläge zur Modernisierung und Leistungssteigerung einer DW-Lösung im Kasten "Tipps").
Soll nun ein bestehendes System an neue Einsatzgebiete angepasst werden, so liegt die Herausforderung weniger in der technischen Umsetzung der neuen Anwendung. Vielmehr besteht die Arbeit darin, aus den vielen, meistens sehr wertvollen Daten, die sich mit der Zeit im DW angesammelt haben, die richtigen für die künftigen Benutzer herauszufiltern. Diese sollen in die Lage versetzt werden, sich nicht länger durch umfangreiche Datenansammlungen hindurcharbeiten zu müssen, sondern stattdessen möglichst schnell und effizient ihre Aufgaben erledigen zu können. Ein DW wird aber nur dann genutzt, wenn intuitiv zu bedienende, individuell angepasste Oberflächen vorhanden sind beziehungsweise eine schrittweise Erweiterung bestehender Oberflächen erfolgt.
Anwender sollten zudem mehr Möglichkeiten zur Informationsgewinnung und -aufbereitung erhalten. Hierbei ist zu überlegen, um welche Anwendungen die datenführende Schicht des DW erweitert werden sollte. Der direkte Zugriff auf die Daten, also Ad-hoc-Reports, wird beispielsweise immer nur einem kleinen Anwenderkreis vorbehalten sein, da man die Daten grundsätzlich gut verstehen muss, um dem DW die richtigen Fragen stellen zu können. Künftigen Benutzern sollte deshalb mit vorab standardisierten Auswertungsmöglichkeiten die Arbeit mit dem DW schmackhaft gemacht werden. Entsprechende Anwendungen lassen nur eine begrenzte Zahl von Auswahlmöglichkeiten für Abfragen zu oder liefern vorkonfigurierte Berichte im HTML-Format. Die Erstellung solcher Lösungen wird durch marktgängige Tools bereits sehr gut unterstützt. Problematisch ist hierbei allerdings in vielen Fällen das Berechtigungskonzept.
Ebenso können Java-basierte Oberflächen (Thin Clients) statt lokal laufender Anwendungen (Fat Clients) eingesetzt werden. Diese Lösung wird mittlerweile von fast allen Tool-Herstellern unterstützt. So bieten heutige Produkte für Online Analytical Processing (Olap) neben proprietärer Client-Software meist auch Web-Technik für den Zugriff auf die Daten. Dabei ist zu prüfen, ob sich die vom Tool gebotenen Möglichkeiten in die vorhandene Infrastruktur einbetten lassen: Wird vom Olap-Tool der Zugriff über Java-Applets ermöglicht, oder sind es Plug-ins, die unter Umständen nicht von allen Browsern korrekt verarbeitet werden? Auch Sicherheitsanforderungen können die Nutzbarkeit dieser Lösungen einschränken.
Thin-Client-Lösungen bieten zwar in der Praxis bisher meistens weniger Funktionalität als ihre "fetten" Gegenstücke, die Unterschiede werden aber kontinuierlich geringer, und auch der Realisierungsaufwand ist in der Regel überschaubar. Derartige Lösungen eröffnen neue Wege, Daten zu verteilen und Applikationen zur Verfügung zu stellen. Der Browser verbindet sich mit dem Web-Server, eine explizit auf dem Client zu installierende Middleware ist dann nicht mehr erforderlich. Durch Einwahl ins Intranet ergibt sich so auch die Möglichkeit, dass Mitarbeiter unterwegs via Laptop und Browser auf das DW zugreifen.
*Ralf Biermanns und Uwe Schauer sind Mirarbeiter der sd&m AG in München.
Tipps- Erweitern Sie den Anwenderkreis durch den Bau von anforderungsgerechten Frontend-Lösungen.
- Nutzen Sie zur Performance-Steigerung moderne Datenbanktechniken wie Bitmap-Indizes, Parallel Query und Partitionierung.
- Prüfen Sie das Datenmodell, setzen Sie bei relationalen Datenbanken konsequent auf Stern-Schemata.
- Teilen Sie den Gesamtdatenbestand in abteilungsbezogene Data Marts auf.
- Überprüfen Sie regelmäßig die Datenlieferungen der Quellsysteme (Erhöhung der Qualität und Anpassung an aktuelle Anforderungen).
- Nutzen Sie Thin Clients (Browser-Oberfläche).
- Heben Sie unnötige Berechtigungseinschränkungen auf.
- Bauen Sie neue Aggregate und Verknüpfungen auf.
- Nehmen Sie auch unternehmensexterne Daten, zum Beispiel aus dem Internet, auf.
- Prüfen Sie, ob sich für Olap eventuell der zusätzliche Einsatz einer multidimensionalen Datenbank lohnt.
Abb: Existierende Data-Warehouse-Lösungen lassen sich durch neue Frontend-Anwendungen und Thin Clients für neue Einsatzgebiete modernisieren. Quelle: sd&m