Seit den 90er Jahren werden in vielen Unternehmen Data Warehouses mit nachgelagerten Data Marts aufgebaut. Hierfür werden Daten aus unterschiedlichen operationalen Datenbanken meist einmal täglich extrahiert, transformiert und entsprechend bereinigt in das Data Warehouse über unterschiedliche Mechanismen übertragen beziehungsweise repliziert. Auf der Grundlage dieser tagesaktuellen Daten erstellen Unternehmen Auswertungen und Reports aller Art, die in strategische Entscheidungen einfließen. Doch reicht es heute noch aus, Entscheidungen auf Basis "alter" Daten zu treffen? Sicher sind tagesaktuelle Daten nicht wirklich "alt", doch wenn es um unternehmenskritische Analysen geht, ist es erforderlich, auf die operativen Daten zuzugreifen. Dies kann entweder direkt oder über einen Operational Datastore (ODS) erfolgen.
Der pragmatische Ansatz
Viele Unternehmen setzen bereits auf ODS in ihrer einfachsten Form: als Excel-Tabellen. Dabei werden die Daten aus den OLTP-Datenbanken (Online Transaction Processing) gelesen und um weitere Informationen ergänzt. Die Abfragen, die an die operative Datenbank gestellt werden, finden zu dem Zeitpunkt statt, zu dem sie gebraucht werden, um die größtmögliche Aktualität zu gewährleisten.
Aus datenbanktechnischer Sicht ist eine solche Vorgehensweise jedoch sehr problematisch. Operative Datenbanken sind für die schnelle Verarbeitung von Transaktionen eingerichtet. Ständige unkontrollierte Abfragen können den operativen Betrieb stark beeinträchtigen. Zudem sind die Daten in den Datenbanken oft wenig "sprechend" abgelegt - ein unbedarfter Anwender ist meist nicht in der Lage, sofort von Tabellen auf Inhalte zu schließen. Erschwerend kommt hinzu, dass die Daten in der Regel nicht konsolidiert sind. Eine Abfrage, die den aktuellen Ersatzteilbestand in Bezug zum Verbrauch des letzten Monats setzen soll, dauert im operativen System unter Umständen Stunden und blockiert dabei viele Ressourcen.
Aus den genannten Gründen ist es erforderlich, ein Replikat der wichtigen Produktionsdaten zur Verfügung zu stellen. Doch entspricht das nicht einem Data Warehouse? Wo also liegt der Unterschied?
Die Antwort ist einfach: Durch eine permanente Replikation stehen die aktuellen Daten im ODS sofort zur Verfügung, sind aber nicht bereinigt (Transformation). Einzig zusätzliche Verdichtungsstufen sowie spezielle Indizierungen, Views oder zusätzliche Tabellen helfen, die geforderten Informationen für den Anwender transparenter und schneller zugänglich zu machen.
Ein Praxisbeispiel
Das folgende Beispiel zeigt, wie sich ein ODS kostengünstig für die Ad-hoc-Auswertung von Daten aufbauen lässt. Bei dem operativen System handelt es sich um eine Teilebevorratung, auf die rund 4000 Anwender im Zweischichtbetrieb zugreifen. Kern der Anwendung ist eine Oracle-Datenbank in einer älteren Version (9.2) auf AIX, die auf Grund von Anforderungen der Software zunächst nicht migriert werden kann. Mit 40 GB ist die Datenbank für heutige Verhältnisse überschaubar.
Als Zielsystem wird eine Oracle-Datenbank in der Version 10g als Standard Edition auf einem Linux-Rechner mit zwei Dual-Core-CPUs und 16 GB RAM aufgebaut. Der Einsatz der Standard Edition auf Linux empfiehlt sich aus Kostengründen. Generell kann man davon ausgehen, dass eher der Hauptspeicher einen Engpass bei der Verarbeitung der Datenmengen darstellt als die CPUs.
Um den Einfluss der Replikation auf die Produktion gering zu halten, wird eine Software verwendet, die die Daten aus den Oracle-Transaktionsprotokollen (den so genannten Redo-Log-Dateien) ausliest und auf das Zielsystem überträgt. Dort werden die ausgelesenen Transaktionen wieder in entsprechende Änderungsoperationen (DML) umgesetzt und als SQL-Befehle ausgeführt.
Sicher könnte ein versierter Excel-Experte auf dem Zielsystem entsprechende Abfragen direkt ausführen. Damit würde aber viel von der gewonnenen Freiheit wieder verloren gehen. Da nun keine Gefahr mehr besteht, das Produktionssystem zu belasten, können zum Beispiel auch Ad-hoc-Abfragen erlaubt werden. Deshalb empfiehlt sich an dieser Stelle ein Werkzeug, mit dem man grafisch entsprechende Abfragen zusammenstellen kann, die entweder an Excel weitergegeben oder direkt in entsprechende Reports eingebunden werden.
Sicher gibt es weitere Möglichkeiten für den Aufbau und die Nutzung eines ODS. Entscheidend für die Verwendung solcher Komponenten ist die Kosteneffektivität, die geringe Beeinflussung der Produktion und die Flexibilität bei der Auswertung. (ue)