Die zweitschönste Nebensache der Welt

Ich habe leider noch keinen einfachen Weg gefunden, um einen Operator auf dem Panel des Design Studios per Copy/Paste (mit dem Kontextmenü oder mit "Bearbeiten") oder per Drag-and-Drop zu kopieren.

Bei aufwändig gefüllten Operatoren wäre das schon eine große Hilfe. Es gibt aber da noch die XML-Dateien, die Daten-, Mining- oder Steuerungsflüsse beschreiben. Mit etwas Aufwand, lässt sich die XML-Darstellung des begehrten Operators aus der Quelldatei kopieren und in die Zieldatei einfügen.

Es gibt aber einen schnelleren Weg, wenn nur Operatoren aus einem Fluss kopiert werden sollen: Kopiere als Erstes den gesamten Fluss im Projektexplorer mit dem Kontextmenu und lösche alle nicht gebrauchten Operatoren.

Trotzdem: Copy, Cut und Paste für definierte Operatoren wären ein hübsches Feature für eine der 9.1-Nachfolgeversionen.

Diese Ankündigung habe ich noch nicht bei ibm.com gefunden. Daher gibt es hier auch keinen Link, und daher konnte ich keine Details nachsehen. Einige Fragen bleiben also offen, spätestens bis ich die Version 9.1.1 installiert habe.

Das wird dann auch nicht mehr solange auf sich warten lassen: am 1.12. steht der Refresh zum Download bereit, also noch im 4.Quartal, so wie prognostiziert.

Die wesentliche Neuerung dieser Hundertstel-Version ist die Einbindung der aktuellen DB2-Version 9.1. Dies hätte möglicherweise auch mit der DWE 9.1 funktioniert, aber mit der 9.1.1 ist es nun offiziell. Und man weiß ja nie, was so passieren kann.

Damit stehen nun der DWE alle neuen Features der DB2 9 wie

• Self-Tuning Memory Management
• Table (Range) Partitioning und
• Table (Row) Compression

zur Verfügung. So zu lesen in der Ankündigung. Mal sehen, wie sich dies im SQW niederschlägt.

Bei neuer Software sollte man schon mal ins Handbuch schauen. Das Design Studio der DWE ist neu, das "Handbuch" ist sehr umfangreich - ganz entsprechend der Funktionsvielfalt der dokumentierten Anwendung. Ich war eben wieder mal lesefaul. Also muss ich nun Abbitte leisten:

Da habe ich mich doch vor Zeiten beschwert, dass sich im Datenimport-Operator Feldtrenner und Zahlenformat nicht aus einer Liste bequem auswählen lassen.

So sind als Trenner unter Eigenschaften/Dateiformat STANDARD, TAB, ", %, das Komma und anderes selektierbar, wobei unter STANDARD das Komma verstanden wird. Eine Drop-down-Liste für Zahlenformate ist erst gar nicht vorgesehen. Also habe ich unwissend, wie ich nun mal war, die Quelldatei entsprechend aufbereitet - mit Komma als Feldtrenner und dem angelsächsischen Dezimalpunkt.

Hätte ich nur in der Doku oder im Tool-Tip nachgeschaut, was ich alles unter "Zusätzliche Dateitypmodifikatoren" eintragen kann. Das ist immerhin ein MLE mit viel Platz für alle möglichen Optionen, so z.B. für

modified by coldel; decpt,
(oder einfach: coldel; decpt, )

Und genau hätte mein Problem gelöst. Zwar nicht per Auswahl aus einer Drop-down-Liste, aber immerhin.

Dadurch wird der NLS nicht vollständig, aber ich hatte da tatsächlich was übersehen.

DB2 9 bringt viele spannende und teilweise einzigartige Neuerungen in die Datenbankwelt: den XML-Datentyp, Table Compression Zeilenkomprimierung, Range Partition, Self Tuning Memory u.v.m. Natürlich wollte ich meine DB2 sobald wie möglich auf die neue Version 9.1 upgraden. Das alleine sollte kein Problem sein.

Die Data Warehouse Edition (DWE), die ich vor kurzem installierte, wird zur Zeit noch standardmäßig mit DB2 Version 8.2 ausgeliefert. Ich wäre mutig genug gewesen, die DWE mit DB2 9.1 laufen zu lassen. Doch Martin riet mir zur Vorsicht: Lieber erst mal die 9.1 auf einem anderen Rechner installieren und sie als entferntes DBMS in der DWE zu nutzen.

Das klang vernünftig, obwohl ich mir immer noch nicht vorstellen kann, warum sich die DWE nicht mit DB2 9 vertragen sollte.

Egal, sicher ist sicher, also verfolge ich Plan B: Ich habe da noch Number9, einen alten Thinkpad mit altem Windows XP (Service Pack 1) und einer DB2 Workgroup Server Edition (WSE) Version 8.1, genauer: 8.1.0.34. Alles recht alt.

Wie bekomme ich bloß meine Daten aus MS Access in mein Data Warehouse?

Fürs erste habe ich sie mühsam in eine CSV-Datei exportiert, um sie mit dem Dateiimportoperator in die dafür vorgesehen DB2-Datenbank zu importieren.

Um das ganze aber weniger händisch betreiben zu können, hatte ich vor, nach einer JDBC-ODBC-Bridge zu googlen. Aber auch das wäre viel zu kompliziert gewesen. Martin erinnerte mich daran, dass DB2-Tabellenfunktionen auch OLEDB unterstützen.

Die Umsetzung dauerte dann nur einige Minuten: In der DB2 Entwicklungszentrale mit dem Assistenten eine OLEDB-Tabellenfunktion erstellen und diese dann im DWE Design Studio mittels des Tebellenfunktionsoperators zum Ausgangspunkt eines Datenfluss machen.

Es geht sogar noch etwas einfacher.

Namen sind angeblich nur Schall und Rauch. Das sollte dann auch für Namen in Datenbanken gelten. Ob eine Tabelle nun "Umsatz" heißt oder "xxx" ist der Datenbank egal.

Ich mache aber immer wieder die Erfahrung, dass es zwar egal ist, welchen Namen das Datenbankkind bekommt, aber der sollte wenigstens groß geschrieben werden. Das gilt für Namen von Datenbanken selbst, sowie für Namen von Objekten in einer Datenbank.

Immer, wenn ich diesem Prinzip nicht gefolgt bin, hatte ich später irgendwo größeren Schreibaufwand. Manche Anwendungen gehen schon mal davon aus, dass Schema- oder Tabellennamen groß geschrieben sind.

Zumindest ist diese Regel besser als die blödsinnigen eckigen Klammern, die Access verwendet.

Was steht im Titel? Es ist untersagt hier weiter zu lesen.

Also raus jetzt.

...

Noch ein Wort zum Dateiimport-Operator des SQL-Warehousing-Tools der DB2 Datawarehouse Edition:

Das Semikolon scheint als Trenner zwischen Feldern nicht vorgesehen zu sein.

Einige Formate lassen sich definieren: Datum, Zeit und Zeitstempel. Unter den wählbaren Datumsformaten fehlt mir DD.MM.YYYY. Irgendwie konsequent ist daher, dass das kontinental-europäische Dezimalkomma nicht unterstützt wird.

Zahlenformate sind nicht wählbar. Beim Exportieren aus (z.B.) MS Access muss also das voreingestellte Dezimalzeichen von "," auf "." geändert werden. Entsprechendes wird für Datumstrennzeichen gelten.

Ist der NLS noch unvollständig oder habe ich da was übersehen?

Lesen bildet, manchmal selbst das Lesen von solch Meisterwerken wie Online-Hilfen. Ich bin stets freudig überrascht, wenn dies umgehend zu praktisch verwertbaren Erkenntnissen führt wie z.B. die prompte Beantwortung meiner "Dateiimport"-Frage .

Ich hätte diese Frage auch anders klären können: Durch einen Blick ins Log.

Dazu sollte man unter Datenfluss/Ausführen auf der Seite "Diagnose" eine Tracestufe auswählen. Aber Vorsicht: Die Tracestufe "Beides" kann ein sehr großes Logfile nach sich ziehen.

Die Tracemeldungen werden nach Beendigung der Ausführung im "Auführungsergebnis" präsentiert. Ungeduldige können sie ruhig mit "OK" wegklicken. Sie sind bereits unter ...\workspaces\[Projektname]\run-profiles\logs gespeichert.

Handbücher beschreiben die Theorie, Logfiles dagegen die Praxis.

Ich mag Handbücher, die meine Fragen bereits antizipiert haben.

Eigentlich vermeide ich die Konsultation von solchen Dokumenten, aber manchmal geht es nicht ohne. 2,5 GB bringen entsprechend viel Dokus und Tutorials mit sich - soweit ich gesehen habe mehrere 100 MB. Die werde ich nicht alle lesen.

Hier meine Frage, die unbürokratisch von der Online-Hilfe beantwortet wurde:

Mein Datenfluss hat einen Dateiimportoperator als Quelle und verzweigt sich danach sofort in drei Operatoren-Stränge. Da der Dateiimportoperator eine große CSV-Datei einliest und konvertiert, könnte es ja sein, dass dies möglicherweise dreimal durchgeführt wird - für jeden Zweig am Ausgabe-Port des Dateiimports einmal.

Glücklicherweise gibt es den Datenstationsoperator. Dieser speichert jede Tabelle zwischen - als Datei, als View, als temporäre oder als permanente Datenbank-Tabelle. Dieser Operator wäre also in der Lage, ein mögliches mehrfaches Einlesen zu verhindern.

Aber ist das explizite Einbauen eines Datenstationsoperators wirklich notwendig. Oder ist das SQL Warehousing-Tool (SQW) der DWE schlau genug und baut so einen Operator selbstständig ein?

Das ist wahre Begeisterung: Nachdem ich den Plan für mein eigenes DWE-Tutorial niedergeschrieben hatte, konnte ich bis 4 Uhr morgens nicht mehr die Finger davon lassen. Die erste Etappe habe ich auch tatsächlich erfolgreich beendet. Der Rest ist dann OLAP.

Zugegeben: Es ist nicht immer alles glatt verlaufen. Aber das sind die typischen Probleme in der Kennenlernphase einer neuen Software. Immerhin habe ich keine Dokumentation zu Rate ziehen müssen und auch nicht wollen. Fast alles erklärt die Software selbst. Eigentlich überraschend.

Ok, ich habe ein, zwei mal im offiziellen DWE Tutorial nachgeschaut.

Hier in Überschriften das Protokoll dieses famosen Projektstarts:

1. Anlegen einer leere Datenbank mit DB2-Bordmitteln
2. Anlegen eines "Data-Warehouse-Projekts" im Design Studio (ich mag das DWE Design Studio, denn das Design Studio basiert auf Eclipse)
3. Importieren der Metadaten der unter 1. angelegten DatenbankAnlegen eines "Datenfluss" zum Importieren der Daten aus MS Access
4. Definieren eines "Dateiimport"-ObjektesOperators
5. Erstellen des Modells für die Zieltabelle
6. Definieren eines "Massenladeziel"-ObjektesOperators zum Befüllen der Zieltabelle mit den importierten Daten
7. Prüfen des Datenflusses
8. Erstellen der neuen Tabelle (siehe 6.) in der Datenbank
9. Ausführen des Datenflusses

Nachdem 10. erfolgreich war, wurde ich mutig und habe noch zwei weitere, ein wenig längere Datenflüsse gebaut.

Hier noch einige Details zu den Überschriften:

... oder zu neuschwäbisch: Business Intelligence. Das soll mit der DB2 Datawarehouse Edition erreicht werden können. Nun gut, lasst es uns testen!

Dazu nehme ich eine alte MS-Access-Anwendung her, um sie beispielhaft zu portieren und zu verbessern. Dies ist mein Tutorial zum Einstieg in die Data Warehouse Edition.

Nachdem ich hier die Installation der DWE beschrieben und kommentiert habe, werde ich dies teilweise für dieses kleine DWE-Projekt tun. Dies soll der Dokumentation und der Wiederverwendbarkeit dienen.

Und hier die Aufgabe: Einlesen der Daten aus einer Access-Tabelle, Erstellung eines OLAP-Modells für diese Daten, Erstellung des Würfels und Implementierung der wichtigsten Reports und Analysen mit Alphablox.

Anders als meine Access-Anwendung, kann ich dann alle Prozesse und Analysen auf einem Server ausführen und auf die Ergebnisse mit einem Browser zugreifen. Dies fördert die Klugheit eines Unternehmens.

... würde Franz Ferdinand sagen.

Es war einfacher, als ich anfänglich dachte. Mal so eben 2,5 GB Software installieren und konfigurieren, und es läuft. Tatsächlich.

Ich schreibe hier über die DB2 Data Warehouse Edition (DWE). Ein umfangreiches Software-Bundle mit Business Intelligence (BI) Anwendungen. Die DWE Enterprise Edition besteht aus folgenden Komponenten:

• die Datenbank DB2 Enterprise Edition
• das Data Warehouse Design Studio
• das SQL Warehousing Tool
• OLAP Acceleration
• Data Mining
• Alphablox Analytics
• und viele andere nette Tools inkl. dem Websphere Application Server

Viel Software für viel Geld. Die gibt es auf CDs oder per Download aus dem Netz.

Ich habe mich für zweiteres entschieden. Also habe ich über Nacht die IBM um 4,4 GB gezippte Dateien erleichtert, das komplette Rundum-fühl-dich-wohl-Paket.

Der Plan war nun alles, d.h. Client- und Server-Komponenten auf meinem Thinkpad zu installieren. Das ist untypisch, aber zum Entwickeln, Prototypen und Testen sehr praktisch.