Business Intelligence

Hier die letzten beiden Punkte aus der Liste der "Data flow enhancements":

"Sampling data: For operators that provide table properties, you can view sample data directly from the data flow editor."

Auch dieses Feature ist dem Mining-Fluss-Editor entlehnt, und das zu recht. In einem Mining-Fluss findet man es in Kontext-Menü eines geeigneten Operators unter "Daten" und "Beispielinhalt ...". Im Datenfluss-Editor heißt der Eintrag "Stichprobe des Datenbanktabelleninhalts entnehmen".

"Background flow execution in the Design Studio: You can run data flows and control flows in the background, and you can cancel control flows between operators. The new Execute Status view displays execution results."

Dies ist neu für Datenflüsse, für Mining-Flüsse konnte und musste ich diese Option bereits nutzen, da Mining manchmal etwas länger braucht.

Bei letzten drei Erweiterungen für Datenflüsse wurden Funktionalitäten aus den Mining Flows übernommen. Das sollte aber nicht das Ende sein: Ich vermisse auf jeden Fall noch "Bis zu diesem Schritt ausführen ...".

Dies ist die Nummer 7 in der Liste der "Data flow enhancements":

"Creating suitable tables: Like the mining flow editor, the data flow editor now allows you to automatically create a suitable table for the data that is passing through operator output ports."

Das ist eine der Besonderheiten, die das Arbeiten mit Mining-Fluss-Editor so bequem machen. Nach rechtem Mausklick auf den Ausgabeport eines geeigneten Operators und Auswahl von "Geeignete Tabelle erstellen ..." erscheint der bekannte hilfreiche Assistent.

Auch wenn das Vorgehen für beide Flüsse auf den ersten Blick gleich aussieht, gibt es doch kleine, aber feine Unterschiede. Das geht gleich auf der ersten Seite des Dialogs los:

Aus einem Mining-Fluss aufgerufen findet man dort die Check-Box "Tabellenzieloperator automatisch erstellen und verbinden", in einem Datenfluss erscheint dort "Wählen Sie diese Option, um die Tabelle im Datenmodell und in der Ausführungsdatenbank zu erstellen. Nehmen Sie".

Ich wüsste gerne, was ich nehmen soll oder kann. Da hilft sicher ein Blick in die englische Version, die Online-Hilfe tut's nicht.

Und noch mehr "Data flow enhancements":

"Saving flows as images: You can save flow diagrams (data flows, control flows, and so on) as image files."

Einfach rechter Mausklick auf dem Panel (dem "Erstellungsbereich" des Daten- oder Steuerungsflusses), "Datei" und "Als Imagedatei speichern ..." auswählen, ausfüllen und los.

Ein hilfreiches Feature für Dokumentationswütige und Leute, die ihre Elaborate gerne publizieren. Im Ernst: wenn es diese Möglichkeit ab jetzt nicht geben würde, hätte ich sie sicher demnächst schmerzlich vermisst.

"Expanded variable support: In data flows and control flows, several new properties can be set as variables, and the SQL Expression Builder includes a Variables section."

In den Eigenschaften eines Datenflusses gilt dies für die zwei (evtl.) neuen Felder für "Tabellenbereiche" sowie für Felder einiger Operatoren. Im Steuerungfluss trifft das wohl auf den einen oder anderen Operator zu. Zu einer sicheren Aussage über solche Erweiterungen fehlt mir der Vergleich mit der Version 9.1. Die habe ich ja hier mit dem Refresh überbügelt.

Offensichtlich ist der erweiterte "variable support" im SQL Expression Builder. Dieser kommt als "SQL Code Builder", "SQL Condition Builder" oder anders überall dort zum Einsatz, wo SQL-Ausdrücke erstellt werden sollen. Hier gibt es jetzt auf der rechten Seite eine neue Box unter der Überschrift "Variablen".

Dies sind drei weitere Neuerungen aus dem Bereich "Data flow enhancements":

"Table source filtering: You can apply a WHERE clause condition to the data that is read in from a source table."

Einfach praktisch, das erspart einen gesonderten Operator auf der Arbeitsfläche. Im Tabellenquelle-Operator gibt es dazu in der Markmalsicht die neue Seite "Bedingung WHERE".

"Commit intervals: For SQL Insert operations, you can specify a commit interval in the table target operator."

Dahinter verbirgt sich das neue Eingabefeld "Commitintervall" auf der "allgemeinen" Eigenschaftenseite des Tabellenziel-Operators. Hier kann die Anzahl eingefügter Zeilen spezifiziert werden, nach denen ein Commit ausgeführt wird.

Da musste aber einiges an der Code-Generierung für das Insert geändert werden.

"Exploitation of the DB2 Database Partitioning Feature (DPF): To improve the performance of data flows and certain data flow operators (such as distinct and splitter operators), the SQL Warehousing Tool generates partition-aware code based on properties specified in the data flow."

Ich denke, dazu ist die Check-Box "DB2-Datenbankpartitionierungsfunktion (DPF) verwenden" vorgesehen.

Das gleiche gilt für die Merkmalsicht-Seite "Einstellungen für die Zwischenspeichertabelle" der Operatoren "Eindeutig" (Distinct), "Verteilerprozess" (Splitter) und "Schlüsselsuche" sowie die Seite "Partitionierungsoptionen" der Operators "Massenladeziel" und "Dateiimport" (wobei sich mir nicht erschließt, was genau unter dem Feldnamen "Partitionierungspartitionen" zu verstehen ist).

Dies wird die lange Antwort zu dieser kurzen Frage. Lang, da die Liste der Neuerungen und Änderungen recht umfangreich ist mit 34 Einträgen. Wie obiger Titel vermuten lässt, wird sich die Antwort wohl auf mehrere Blogeintäge verteilen.

Die meisten Änderungen findet man unter der Überschrift "SQL Warehousing Tool features" und dort zum Thema "Data flow enhancements". Und hier geht es gleich mit einer sehr sinnvollen und hilfreichen Erweiterung los:

"Flat file discovery: You can sample a file in the file import operator and automatically generate its schema, instead of manually defining columns and data types."

Konkret ist hier der neue Knopf "Dateiformat generieren" auf der Dateiformat-Seite des Dateiimport-Operators gemeint. Damit wird ein Dialog gestartet, in dessen Verlauf die Liste der zu importierenden Felder mit wenigen Eingaben komfortabel generiert werden kann.

Diese Erweiterung ist ohne Frage sehr hilfreich. Ich hatte einen solche Unterstützung bereits vermisst, da z.B. Access seit langem über einen solchen Assistenten zur Erstellung von csv-Dateien verfügt.

Hier die kurze Antwort auf die kurze Frage: Sehr viel für ein hundertstel Upgrade.

Wie bereits an anderer Stelle ausgeführt, ist der wichtigste Grund für den Refresh die Einbindung einiger neuen Features der DB2 9. Im DB2 Magazine heißt es dazu:

"A DWE 9.1.1 refresh available this quarter upgrades the DWE package to DB2 9 and addresses requests from early DWE 9.1 adopters. DB2 9 includes a number of critical enhancements in its role as the underlying engine for DWE, including self-tuning memory management, range partitioning, and row compression."

Laut "What's New in DWE 9.1.1" in den Release Notes (Seite 2-4) werden neben der DB2 9-Unterstützung Verbesserungen in folgenden Bereichen ausgeliefert:

• Installation and configuration features
• SQL Warehousing Tool features
• Administration Console features
• Data mining features

Hinter diesen Überschriften verstecken sich insgesamt 34 einzelne Neuerungen und Verbesserungen.

Das ist doch nicht normal für ein ein Refresh.

... der DWE auf die 9.1.1 bleibt neben den Post-Installationsaufgaben noch die Aktualisierung einiger Tabellen der SQW-Steuerdatenbank. Bei einer Neuinstallation der DWE 9.1.1 braucht dieser Migrationsschritt natürlich nicht durchgeführt werden.

Diese "erforderliche Migrationstask" besteht aus der Ausführung zweier SQL-Scripts: addConstraints.sql und upd_unitsum.sql.

Diese Dateien wurden von der Installationsroutine für die DWE-Verwaltungskonsole in das Verzeichnis DWE\DWEAdmin kopiert und sollten dort auch im DB2-Befehlsfenster ausgeführt werden.

Es ist eigentlich eine triviale Bemerkung, dass man sich vorher mit der betreffenden Datenbank verbinden muss (db2 connect to SQWCTRL). Es war auch keine Überraschung, dass ich danach erst mal folgenden freundlichen Hinweis bekam:

"SQL5035N Die Datenbank muss auf das aktuelle Release umgestellt werden.
SQLSTATE=55001"

Also doch! Zum Upgrade der DWE von Version 9.1 auf 9.1.1 sollte man auch die "Anwendungsserverkomponenten" einbeziehen. Als zu installierende Komponente braucht nur die "DWE-Verwaltungskonsole" ausgewählt werden. Die Zusammenfassung zeigt daraufhin, dass damit auch die neuen Miningblox installiert werden.

Während der folgenden Installation werden unterhalb des DWE-Verzeichnisses zwei neue Verzeichnisse angelegt: "Miningblox" und "config".

Die Miningblox sind damit allerdings noch nicht endgültig installiert. Gemäß Installation Guide bzw. der readme.txt im Verzeichnis "Miningblox" ist hier noch eine Post-Installations-Aufgabe zu erledigen.

Was das "config"-Verzeichnis angeht, steckt hinter seiner Existenz eine Verbesserung des Konfigurationstools:

"DWE configuration tool is installed: The configuration tool is now installed on the DWE application server so you can run it anytime to update the initial configuration." (s. "What's New in DWE 9.1.1" in readme911.pdf)

Mit der Version 9.1 musste der Konfigurationsdialog noch aus dwecd\config heraus gestartet werden. Aus der config.exe wurde nun eine config.bat, die während der Installation erstellt wird.

Der DWE Integrated Install erledigt fast die komplette Installation der Data Warehouse Edition seit Version 9.1. Aber eben nur fast:

Auf der Seite "DB2 Data Warehouse Edition 9.1.1, downloading Developer/Enterprise Ed. (Windows)" findet man zur "Part number" C95YUML folgenden sinnvollen Hinweis:

"DB2 Data Warehouse Edition V9.1 Quick Start. This image contains the Quick Start Guide, which provides a high-level overview of the installation process. This image also contains DWE books in PDF format. The integrated installation program does not install this image."

Also habe ich die Dateien manuell installiert. Dazu habe ich 16 Dateien aus 13 Verzeichnissen kopiert, soweit vorhanden die deutsche Version eines pdf. Eine Solche gibt es in den meisten Fällen, aber ausgerechnet bei den Dokumenten zum Mining fehlt eine deutsche Übersetzung - und nicht nur diese: Mining auf chinesisch lässt auch noch auf sich warten.

Der manuelle Aufwand lohnt sich: Das Image C95YUML enthält Handbücher zur Installation, zum Design Studio, zur Administrationskonsole, zum Mining sowie zu den neue Miningblox, das Tutorial und weitere Dokumentationen.

Das gab es auch schon für die DWE Version 9.1: die "Post-Installation tasks". Dazu gehört die Konfiguration diverser DWE-Komponenten: Intelligent Miner, Alphablox, Application Server und das Information Center (s.a. DWE Installation Guide, Chapter 7).

Ich habe mir bisher diese Tätigkeiten geschenkt, da ich sie bereits bei der Installation der Version 9.1 erledigt habe, und sich durch die neuen 9.1.1-Komponenten an der Konfiguration von Alphablox und dem WAS nichts verändert haben sollte. Die "Post-Installation Task" für den Miner besteht unter Windows sowieso nur im "Enabling" von Datenbanken für das Mining.

Zusätzlich zu diesen Aufgaben kommt noch für die 9.1.1 die Installation der Miningblox und das Upgrading der DWE Control Datenbank.

Als weitere "Post-Installation task" kann man auch die folgende Empfehlung aus dem Installation Guide (S.39) betrachten:

"To verify that the installation was successful, check the log files listed in Appendix B, “Log file locations,” on page 53. In the main installation log file dweinstall.log, check the lines that contain keywords such as err, Exception, wrn for errors and warnings."

Dem bin ich ausnahmsweise mal nachgekommen, da mein Upgrade nicht ganz perfekt war. Im logs-Verzeichnis meiner DWE-Installation war tatsächlich nur dweinstall.log mit einem aktualisierten Zeitstempel versehen. Die anderen Installationslogs waren - wie zu erwarten war - unverändert.

Die eigentliche Rechtfertigung für die seit Anfang dieses Monats verfügbare Data Warehouse Edition 9.1.1 ist die Unterstützung einiger Neuerungen der DB2 9. Aber nicht nur deshalb habe ich meine Datenbankversion unabhängig und als Erstes aktualisiert.

Da sich außerdem bei Alphablox und dem Websphere Application Server nichts verändert hat, müssen nur noch zum Upgrade auf die DWE Version 9.1.1 die neuen Komponenten des SQW, des Intelligent Miner und der DWE Administration installieren werden. Das erledigt die aktuelle Variante des Integrated Installers.

Hier brauchen also unter "Implementierungsoptionen" die "Anwendungsserverkomponenten" nicht ausgewählt werden ( 01.01.2006: tatsächlich muss eine Anwendungsserverkomponente - die DWE Verwaltungskonsole - aktualisiert werden). Die sind ja bereits installiert. Das gleiche gilt in diesem Fall für DB2, es kann daher eine "vorhandene DB2-Kopie" verwendet werden.

In der Auswahl der DWE-Komponenten können dementsprechend serverseitig DB2 und der Query Patroller abgewählt werden. Das Gleiche gilt für den Client. Unter Dokumentation kann man auf die "Alphablox Informationszentrale" verzichten. Eigentlich kann man das auch für die Cube Views-Komponenten abwählen, sicherheitshalber habe ich sie aber mitgenommen.

Die folgende Installation dauert eine Weile, immerhin werden 823 MB Daten bewegt.

... dass eine DB2-Datenbank erst für Data Mining vorbereitet werden muss, um Data-Mining-Algorithmen auf die Tabellen der Datenbank ausführen zu können.

Richtig ist auch, dass dies mit einem einfachen Befehl im DB2-Befehlsfenster geschehen kann. So beschrieben im der DWE-Hilfe oder im DWE-Tutorial (S.82).

Er ist glücklicherweise falsch, dass dies im Design Studio nicht durch eine Option in einem Kontextmenu unterstützt wird. Diese findet man zwar nicht im Datenprojektexplorer - wie bereits bemerkt -, sondern unter links im Datenbankexplorer:

Einfach die Verbindung zur vorzubereitende Datenbank herstellen, den entsprechenden Datentenbank-Ordner öffnen, per rechtem Mausklick auf das blaue Plattensymbol (oder auf den darauf folgenden Datenbanknamen) das Kontextmenü öffnen und die Option "Datenbank für Data Mining aktivieren".

Es ist weiterhin richtig, dass das Vorbereiten einer Datenbank - genauer: eines Datenbankmodells - für OLAP im Datenprojektexplorer angeboten wird: rechter Mausklick auf eine Datenbank unter "Datenbanken", Option "OLAP-Objekte implementieren".

Da war ich doch etwas voreilig mit meinem Wunsch nach einer Möglichkeit, Mining-Modelle im Design Studio zu verwalten.

Der Wunsch ist wohl berechtigt gewesen, war aber bereits erfüllt. Hätte ich mal vorher die Hilfe zum Mining in der DWE zu Rate gezogen. Denn dort steht, dass Mining-Modelle, die von diversen Operatoren erzeugt werden, im Datenbankexplorer unter der jeweiligen Datenbank und dort unter "Data-Mining-Modelle" aufgeführt werden.

Und nicht nur das: Ein rechter Mausklick auf ein Modell öffnet ein Menü mit den Einträgen "Öffnen", "Löschen", "Umbenennen" und "Exportieren".

Noch mehr zum Thema "Jeder Fluss ist anders".

Gleicher Namen heißt nicht gleicher Inhalt. Das gilt auf jeder Fall für den Tabellenziel-Operator im Daten- und im Mining-Fluss.

In einem Daten-Fluss kann dieser Operator die Daten aus dem Eingabeport in die Zieltabelle einfügen, oder Daten in der Zieltabelle aktualisieren oder löschen - aber nur eines zur Zeit. Dahinter stecken die SQL-Anweisungen INSERT, UPDATE oder DELETE.

Der Tabellenziel-Operator im Mining-Fluss kann dagegen Daten nur einfügen, dafür besitzt er aber die Check-Box "Vorherigen Inhalt löschen".

Diese Option wäre IMO auch für den gleichnamigen Operator im Daten-Fluss sinnvoll. Dann muss ich nicht im Falle eines Inserts bereits exsistierende Daten explizit per Operator löschen. Dies würde unter Umständen zur Synchronisation sogar einen Steuerungs-Fluss erfordern.

Dafür könnte im Gegenzug der Operator im Mining-Fluss die Check-Box "NOT LOGGED INITIALLY" erhalten oder gar den Tab "Zuordnen". Give 'n Take.

Von Mining-Operatoren wie z.B. dem "Clusterer" werden automatisch Mining-Modelle erstellt und in der Datenbank gespeichert. So ein Modell kann dann im Scorer ausgewählt werden. Bei dieser Auswahl kann man dann sehen, welche Modelle überhaupt erstellt wurden. Da war dann in meinem Fall noch das eine oder andere experimentelle Modell darunter.

Nur, wo kann ich solche nicht verwendete Modelle löschen. Oder allgemeiner: Wo kann ich Mining-Modelle verwalten?

Einfache Frage, einfache Antwort: In der Ausführungsdatenbank und dort in der Tabelle IDMMX.CLUSTERMODELS. Dies ist übrigens eine der Tabellen, die beim "Enable for Data Mining" angelegt werden.

Zur Verwaltung der Modelle steht also der komplette SQL-Funktionsumfang zur Verfügung.

Trotz alles SQL-Möglichkeiten wäre es sicher sinnvoll, wenn Mining-Modelle direkt im Design Studio in bewährter Art und Weise verwaltet werden könnten (23.11.2006: was auch tatsächlich angeboten wird, wenn auch an etwas unerwarteter Stelle).