Realtionale Abfrage reicht nicht

Typische relationale Speicherformen sind sehr gut für OLTP-Anforderungen geeignet. Die Anfragen, die an die Datenbank gerichtet werden, erfolgen nach den im Vorfeld gut absehbaren Kriterien und Suchpfaden. Doch im Data-Warehouse-Umfeld gelten weitere Bedingungen, weiß Flade-Ruf aus der Praxis zu berichten: Anwender wollen ihre Auswertungen sehr flexibel über die verschiedenen Kriterien zusammenstellen. Die möglichen Abfragekombinationen sind dabei sehr vielfältig, und die Antwortzeiten müssen besonders gut sein. Ein einzelner Bericht soll sehr häufig in der Lage sein, zum Beispiel die Verkaufszahlen für Artikel und Produkte nach Kunden und Regionen sortiert auszugeben, mal als Monats-, mal als Wochenübersicht und dann in unterschiedlichen Vergleichen über die Zeitdimensionen. Gleichzeitig ist aber gewünscht, dass zu Vergleichszwecken die Regionen oder Kunden nebeneinander stehen sollen. Dies würde in einer rein relationalen, SQL-getriebenen Abfragetechnik zu mehrfach geschachtelten SQLs führen, bei denen ein Skript jeweils auf den Ergebnissen des vorhergehenden aufbaut. Dem versucht die Olap-Technik eine elegante Lösung entgegenzusetzen, bei der die typischen Abfragepfade der Anwender vordefiniert und gewisse Informationen voraggregiert sind.

Um die Flexibilität noch auszubauen, können Materialized Query Tables (MQTs) für schnelle Abfragen in multidimensionalen Umgebungen anlegt werden. Man kann diese Strukturen selbst entwerfen und mit entsprechenden Aggregationstabellen arbeiten. Wesentlich bequemer geht dies aber mit Cube Views, dem Olap-Werkzeug von DB2, so die mip-Expertin. Mit Hilfe von Cube Views lassen sich die Strukturen definieren, in denen der Anwender später auswerten will. Dazu gehören beispielsweise Kennzahlen, Dimensionen, Attribute und Berechnungen. Diese Olap-Definitionen werden als Systemtabellen direkt in DB2 verwaltet. Dann schlägt das System entsprechende MQTs vor und erstellt die Indizes. Diese werden dann von DB2 automatisch verwendet, damit bei den Queries möglichst wenig Aggregationen "on the fly" stattfinden müssen, was je nach Strukturtiefe und Ausprägungsanzahlen große Einsparungen bei den Laufzeiten bringen kann. Letztlich entstehen an dieser Stelle die mehrdimensionalen Modelle für die Olap-Anwendungen. Dadurch definiert man die Metadaten wie zum Beispiel Kennzahlen und Dimensionen nur einmal, um sie später an den unterschiedlichen Stellen zu benutzen.

Nun gibt es zwei prinzipielle Wege der Weiterverarbeitung: Entweder man greift direkt mit einem Frontend auf dieses so erstellte Datenmodell zu, zum Beispiel mit DB2 Alphablox, Arcplan Enterprise, Cognos 8 oder Microstrategy, oder aber man erzeugt mit Hilfe dieses Datenmodells Molap-Cubes. Wenn man daraus zum Beispiel Hyperion-Essbase-Cubes, Business-Objects-Universen oder Cognos-Powerplay-Cubes erstellen will, werden diese auf Basis der in Cube Views festgelegten Dimensionen, Attribute und Kennzahlen erzeugt.