Die zweitschönste Nebensache der Welt

Was bisher geschah:

• Die Tabellen einer MS-Access-Anwendung sind zu groß geworden für die Jet-Engine. DB2 ist die Wahl der Stunde für die Datenhaltung als skalierbare, performante und vertrauenswürdige Basis.
  
• Tabellendefinitionen und Daten lassen sich manuell oder per VBA-Routine nach DB2 transportieren.
  
• Auch die Anlage von Indizes und Schlüssel in der Zieldatenbank kann automatisiert werden.
  

Es bleibt die Aufgabe, die DB2-Tabellen an die Anwendung anzubinden. Dies geht unter Access natürlich nach rechtem Mausklick unter Tabellen mit "Tabellen verknüpfen ..." für jede einzelne Tabelle. Bei vielen Tabellen gerät das zu einer gesundheitsgefährdenden Klickerei. Aber auch hier lässt sich der Prozess wie folgt automatisieren

Beim Abbilden von Indizes und Integritätsbedingungen aus Tabellen, die unter Access mit der Jet-Engine erstellt wurden, sind leider noch folgende Unebenheiten zu beachten:

Unter Access ist es möglich, Spalten als Primärschlüsseln zu erklären, die laut Definition Nullwerte enthalten können. Das ist schon was Besonderes, denn nicht mal der SQL-Server erlaubt das. Keine vernünftige Datenbank lässt diesen Unsinn zu, also auch DB2 nicht.

Das hat allerdings die unangenehme Konsequenz, dass der Versuch der beschriebenen automatischen Anlage eines Primärschlüssels auf eine Spalte, die laut Definition im Access Nullwerte enthalten darf, nicht möglich ist. Am Besten definiert man die Tabellen gleich standardgemäß oder korrigiert diese Nachlässigkeit noch vor dem Export der Tabelle.

Falls dies aus irgendeinem Grunde nicht möglich ist, bleibt noch die Möglichkeit, in der DB2 Steuerzentrale die Definition solch einer Spalte zu ändern bevor sie zum Primärschlüssel erhoben wird. Bei vielen Änderungen dieser Art geht das auch per Script, die Änderungsanweisung ist allerdings recht unhandlich.

Übrigens: Auch Access kann keine Wunder vollbringen und aus sinnvollen Einschränkungen sinnlose Erweiterungen machen. Jeder Versuch, einen Nullwert in einen Primärschlüssel einzugeben, wird mit einer Fehlermeldung bestraft. Warum man allerdings bei der Definition einer Tabelle solche einen Quatsch zulässt, bleibt mir unerschlossen.

Per Mausklicks, Makro oder VBA-Routine lassen sich in der Jet-Engine unter MS Access gespeicherte Tabellen wie beschrieben leicht nach DB2 migrieren. Eine Datenbank besteht aber nicht nur aus einer zusammenhanglosen Ansammlung von Tabellen. Die Access-Exportfunktion transportiert eigentlich nur Struktur und Daten von A nach B, ignoriert aber Indizes, Primär- und Fremdschlüssel.

Ohne ihn jemals angewandt zu haben, bin ich mir sicher, dass MS mit seinen Upsizing-Agenten auch diese Datenbank-Objekte migriert. Leider eben nur auf den SQL-Server. Als Strafe dafür, dass ich die schöne neue MS-Welt frevelhaft verlassen will, muss ich leider eine Extrarunde programmieren. Aber danach lassen sich auch Indizes und Schlüssel nach DB2 portieren.

Dazu muss ich nur die TableDef-Objekte ausbeuten, so wie ich es für die Export-Routine für alle Tabellen meiner Access-Anwendung getan habe - eigentlich nur eine Schleife um "DoCmd.TransferDatabase". Mit diesem Kommando übertrage ich Struktur und Daten einer Tabelle, das ist dann aber auch schon alles. Beim Transfer von Indizes oder Integritätsbedingungen helfen wieder die TableDef-Objekte. Hier finde ich die Eigenschaften, die ich zur Erstellung geeigneter "create index" oder "alter table" benötige.

Für meine VBA-Exportroutine sieht das im Wesentlichen so aus:

MS Access wird gern als Prototyping-Werkzeug oder als Umgebung für die schnelle Entwicklung von Datenbankanwendungen unter Windows genutzt. Aber oft bleibt es nicht beim Prototyp und die schnell entwickelte Einzelplatzanwendung hat urplötzlich viele Nutzer. Wenn einem dann die Anwendung um die Ohren fliegt, erfährt man, dass Access keine solides Basis für skalierbare Anwendungen bietet.

Das gilt vor allem für die einer Access-Anwendung zugrunde liegenden Datentabellen, soweit sie in der Jet-Engine verwaltet werden. Je größer die benötigten Tabellen, je mehr darauf zugreifende Nutzer, desto notwendiger wird ein Wechsel auf eine solide Datenbank.

Wenn es nach Microsoft ginge, führte der Upsizing-Pfad geradewegs zum SQL Server. Es gibt aber bessere Alternativen, die MS natürlich nicht mit einem Upsizing-Agenten (Extras/Datenbank Dienstprogramme) unterstützt. Trotzdem ist eine Migration der Daten nach DB2 mittels ODBC oder OLE DB eine einfache, gut automatisierbare Aufgabe. Die wesentlichen Schritte werden bestens in "Migrating a Microsoft Access 2000 Database to IBM DB2 Universal Database 7.2" beschrieben. Auch wenn "2000" und "7.2" nicht gerade up-to-date klingt, es funktioniert auch mit aktuelleren Versionen.

Abstürzende Software ist ärgerlich. Aber das kommt selbst bei den besten Exemplaren dieser Spezies vor. Keine einigermaßen komplexe Anwendung ist fehlerfrei - solange Menschen ihre Finger im Spiel haben. Irren ist eben menschlich. Ich bin gespannt, wann wir endlich in der Lage sind, die Fehlerfreiheit von Programmen maschinell nachzuweisen.

Solange das nicht möglich ist, müssen wir mit allzu menschlichen Fehlern leben. Selbst APL ist davor nicht gefeit. Gerade beim Test neuer Features bringe ich ab und zu eine APL-Sitzung zum Absturz. Es passiert auch schon mal, dass ich durch wochenlange intensive Entwicklung einer APL2-Anwendung den dazugehörigen Workspace zerraspelt vorfinde. Aber stets hilft hier die )clear- )copy - )save - Sequenz.

Das alles kommt so selten vor, dass man getrost APL-Systeme als äußerst zuverlässig und stabil bezeichnen kann.

Auch gängige Anforderungen an die Kompatibilität innerhalb der APL-Versionen eines Herstellers werden zufriedenstellend erfüllt. Selbst eine Migration von APL-Anwendungen auf Vorversionen ist mit den üblichen Einschränkungen möglich.

Ganz anders bei MS Access. Ich habe selten eine Anwendung so schnell wegen simpelster Probleme komplett abstürzen sehen. Es genügte schon, eine mdb mit einem ins leere gehenden Verweis zu übernehmen. Auch bei der Aufwärtskompatibilität von Version 10 nach 11 liegt offensichtlich einiges im Argen.

Ich will nicht wissen, wie viele Entwickler bei Kleinstweich an Access rumentwickeln, es werden garantiert mehr sein als alle Entwickler von APL-Systemen zusammengenommen. Ich kann mich des Eindrucks nicht erwehren, dass in den vorliegenden Fällen die Softwarequalität umgekehrt proportional zur Größe der Programmierteams ist.

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.

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?

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.