Der Begriff Business Intelligence (BI) ist wie so viele andere in diesem Umfeld nicht eindeutig. Man versteht darunter den gesamten Data-Warehouse-Zyklus, da die Berichte, Analysen und Planungsanwendungen ohne eine ordentliche Informationsaufbereitung nicht existieren können. Laut Ursula Flade-Ruf, Geschäftsführerin der mip Management Informationspartner GmbH in München, besteht deshalb ein professionelles BI-Werkzeug aus ETL-Komponenten (Extraction, Transformation, Loading), Datenhaltung, Datenbank-Designwerkzeugen sowie Mitteln und Methoden, um die Informationen anwendungsgerecht aufzubereiten. Gegebenenfalls enthält es darüber hinaus entsprechende Frontends, um die Auswertungen zu gestalten.

Die IBM DB2 Warehouse Edition (DWE) umfasst im Kern die Datenbank DB2 UDB mit Erweiterungen für das SQL-Warehousing-Tool (ETL), Cube Views (Olap) und Data Mining, ein integriertes Design Studio mit Datenmodellierungskomponente sowie eine Administrations-Konsole.

Sämtliche Definitionen für die DWE-Komponenten werden grafisch in der Eclipse-Entwicklungsumgebung (Design Studio) erstellt. Von der relationalen Datenmodellierung über die Verknüpfung und Transformation von Datenbeständen, die Definition von multidimensionalen Olap-Strukturen bis zu den Mining-Prozessen erfolgt alles im Design Studio.

BI-Projekte müssen jedoch nicht nur erstellt, sondern auch verwaltet werden. Auch diese Aufgabe wird mit dem Design Studio wahrgenommen, da alle zu einem Projekt gehörenden Vorgänge hier dokumentiert und zusammengefasst werden. Als sehr hilfreich bezeichnet Flade-Ruf dabei auch die Teaming-Komponente, die es erlaubt, Entwicklungen und Definitionen als Team vorzunehmen. Anschließend werden diese Warehouse-Projekte an die Web-basierende Administrationskonsole übergeben, wo die Automatisierung und das Monitoring der definierten Prozesse erfolgen. Die Administrationskonsole ist jedoch nur für die Steuerung der Prozesse verantwortlich, der Ablauf erfolgt direkt in DB2.

Das SQL-Warehousing-Tool erlaubt den Zugriff auf alle gängigen Datenbanken auf den unterschiedlichsten Plattformen. Der gesamte Extraktionsvorgang sowie die notwendigen Berechnungen werden in so genannten Data Flows verwaltet, dokumentiert und zusammengefasst. Der dazugehörige SQL-Code wird automatisch generiert. Er kann direkt modifiziert werden. Die Zugriffe erfolgen über ODBC, JDBC oder DRDA. Es lassen sich aber auch Files einlesen. Ferner stehen alle Möglichkeiten zur Verarbeitung von XML zur Verfügung. Die einzelnen Verarbeitungsschritte werden in einem Flow Chart dokumentiert, darüber hinaus kann man Test Flows erstellen, mit denen die gesamte Verarbeitung gestestet werden kann. Durch die Einbindung des "Information Server", bestehend aus dem "Information Integrator" und "Datastage", sind weitere Extraktionsanforderungen wie virtueller Zugriff, "Near Real Time Warehousing" oder Zugriffe auf unstrukturierte Dokumente möglich.

Performance und Skalierung

Die DB2 UDB als Kernstück der Warehouse-Architektur bietet zahlreiche Möglichkeiten zur Skalierung und Performance-Optimierung. Genannt seien hier die Module Database-(Hash-) Partitioning, Range-Partitioning, Multidimensional-Clustering sowie Performance- und Storage-Optimization. Dabei wird durch die verschiedenen Kombinationsmöglichkeiten die Software auf Komplexität, Datenvolumen und Benutzeranzahl abgestimmt. Neben der Möglichkeit, die Performance von DB2 durch den Performance-Expert zu steigern oder durch den Einsatz entsprechender Hardware-Cluster einem hohen Workload gerecht zu werden, ist an dieser Stelle besonders die Funktionalität des Multidimensional Clustering (MDC) hervorzuheben.

Der mip-Chefin zufolge ist das MDC eine sehr elegante Methode, um Daten flexibel, kontinuierlich und automatisch in mehreren Dimensionen zu clustern. Es ist daher besonders für Data Warehousing und andere große Datenbankumgebungen geeignet. Die Abfragen werden beschleunigt, Daten-Maintenance-Operationen wie zum Beispiel Reorganisation und Index-Maintenance werden durch INSERT, UPDATE und DELETE deutlich reduziert. MDC ermöglicht es, die Daten einer Tabelle physikalisch in mehr als einer Dimension gleichzeitig zu clustern - so als ob mehrere "clustered indexes" auf einer Tabelle möglich wären. Eine als MDC-Tabelle angelegte Tabelle stellt sicher, dass die einzelnen Sätze sich auf der Platte innerhalb eines Disk-Blocks (ein Block ist ein Vielfaches einer DB2-Page, zum Beispiel 32 DB2-Pages) befinden und alle Sätze irgendeines Blocks dieselben Dimensionswerte haben. Alle Blöcke haben die gleiche Anzahl von DB2-Pages, und mehrere Blöcke können dieselben Dimensionswerte beinhalten, falls es die Anzahl der Datensätze mit den gleichen Dimensionswerten erforderlich macht.

Umgang mit Dimensionen

Die Dimensionen einer MDC-Tabelle werden beim CREATE TABLE spezifiziert. Für jede der spezifizierten Dimensionen wird automatisch ein Block-Index erstellt sowie zusätzlich ein kombinierter Block-Index für die gesamten Dimensionen. Dimensionen sind nicht beschränkt auf Spalten oder Sequenzen von Spalten, sondern können auch einen Ausdruck mit einem arithmetischen Operator, eine Skalarfunktion etc. enthalten.

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.

Beschleunigte Abfragen

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.

Das Frontend Alphablox

DB2 Alphablox ist ein DHTML-gestütztes Frontend, mit dem man Berichte und Grafiken erstellen kann. Besondere Kennzeichen sind die nahtlose Einbindung in Applikations-Server und Portaltechnik sowie die Möglichkeit, Templates, sprich die "Blox" zu benutzen. Wenn man DHTML und in manchen Bereichen Java beherrscht, lassen sich mit Alphablox sehr schnell entsprechende Auswertungen erstellen. Es gibt zwei wesentliche Zweige: Die Entwicklungsumgebung erlaubt es, dem Anwender vorbereitete Berichte, Grafiken und Menüs zur Verfügung zu stellen. Hier benutzt man also vorhandene Blox beziehungsweise erstellt eigene, was zur Standardisierung eines Berichtswesens sehr nützlich ist. Für die interaktive Erstellung von Berichten durch den Nutzer steht der Alphablox Query Builder zur Verfügung. Hierbei ist laut Flade-Ruf kein Java-Know-how erforderlich, dafür kann man aber nur die vorgegebenen Standards nutzen.

Bisher unerwähnt geblieben sind die Mining-Funktionen. Auch diese können mit dem Design Studio verwendet und in entsprechende Prozesse eingebunden werden. Die Mining-Algorithmen sind vollständig in DB2 implementiert (Stored Procedures) und können so auch direkt in SQL-Statements eingebunden werden. Inklusive einer Visualisierungskomponente erhält man hier die Möglichkeit, Ergebnisse "welche weiteren Artikel werden zusammen mit einem bestimmten Artikel gekauft" (Assoziation), "welche typischen Kundengruppen gibt es" (Clustering), "welcher Kunde ist abwanderungsgefährdet" (Prediction), "welcher Produktionsprozess ist unter welchen Umständen fehleranfällig" in anderen Anwendungen weiterzuverwenden. (ue)