Einträge von Axel Holzmüller

... verlässt das Microsoft-Schiff. Nicht, weil es sinkt, es sinkt nämlich nicht. Einige würden hier schreiben "leider". Aber bleiben wir realistisch und auch fair.

Apropos "fair". Den Beitrag zu Gates' Abschied von Microsoft im CW Notizblog halte ich für angemessen und auch fair. Dazu zwei Zitate aus dem Blog:

"Ohne die Produkte seines Hauses würden wahrscheinlich nur ein Bruchteil der heutigen Nutzer mit IT und Internet umgehen. Was auch bedeutet, dass die IT-Industrie eine kleinere Rolle einnehmen würde als sie heute spielt"

Natürlich ist das reine Spekulation, aber man kann das so sehen. Das waren dann die Good News.

"Die Monopole in den Bereichen Betriebssysteme und Büroanwendungen hat Gates rücksichtslos ausgenutzt, um für sein Unternehmen neue Märkte zu erobern. Das hält er heute noch so, kaum gebremst von den Kartell-wächtern dieser Welt."

Das sind offensichtlich die Bad News. Das gehört sich auch so bei einer ausgewogenen Berichterstattung.

Gates und Microsoft haben möglicherweise tatsächlich einen beträchtlichen Anteil am Erfolg der IT in der näheren Vergangenheit. Inzwischen erweist sich Microsoft eher als Bremser des IT-Fortschritts.

Das ist typisch für ein Monopol.

Diese "Empfehlung" kann man in Oracles SQL-Referenz finden:

VARCHAR Datatype

Do not use the VARCHAR datatype. Use the VARCHAR2 datatype instead. Although the VARCHAR datatype is currently synonymous with VARCHAR2, the VARCHAR datatype is scheduled to be redefined as a separate datatype used for variable-length character strings compared with different comparison semantics.

Leider wird ihr mehr oder weniger fröhlich gefolgt. Man gebe nur "VARCHAR2" als Google-Suchbegriff ein und staune.

Glücklicherweise ist SQL eine standardisierte Sprache. Dazu gehört die Definition von Standard-Datentypen. VARCHAR ist einer. VARCHAR2 ist Oracles Erfindung und hat nichts mit dem Standard zu tun.

Was könnte Oracle veranlassen, seine zahlenden Kunden aufzufordern vom Standard abzuweichen? Der angegebene Grund kling doch sehr ominös. Will Oracle in Sachen VARCHAR auch vom Standard abrücken? Warum wird VARCHAR2 nicht für die geplanten Erweiterungen verwendet?

Jacques Roy zitierte am 19.10.2005 aus Oracles "Oracle Database 10g: The Self-Managing Database". Dieses Papier ist nicht mehr aktuell. Es gibt nun seit Juni dieses Jahres "Oracle Database 10g Release 2: The Self-Managing Database". Dort heißt es im Original:

"The Oracle database server provides a number of initialization parameters to optimize its operation in diverse environments. Only a few of these parameters need to be explicitly set as the default values for the rest of them are adequate in vast majority of cases. In Oracle Database 10g the parameters have been categorized into basic and advanced categories. Administrators will be able to restrict their day-to-day interaction with about 30 basic parameters. ..."

Mit Release 2 sind also 2 Parameter dazugekommen. So sieht Fortschritt a la Oracle aus.

"In Oracle Database 10g wurden die Parameter in Basiskategorien und erweiterte Kategorien unterteilt. Die Administratoren können sich bei ihren täglichen Interaktionen auf 28 Basisparameter beschränken. Die erweiterten Parameter sind speziell geschulten Datenbankadministratoren vorbehalten und dienen dazu, das Verhalten der Oracle Datenbank an besondere Anforderungen anzupassen ..."
(aus "Oracle Database 10g: The Self-Managing Database", zitiert nach Jacques Roy: "IDS 10.0 und Oracle 10g im Vergleich, 19.Oktober 2005)

Dazu Jacques Roy:

"Dass Datenbankadministratoren jeden Tag Interaktionen mit 28 Basisparametern ausführen müssen, klingt nicht gerade nach einer verwaltungsfreundlichen Datenbank, die obendrein noch als "selbstverwaltend" angepriesen wird, doch für Oracle 10g ist dies bereits eine große Verbesserung"
(Jacques Roy: "IDS 10.0 und Oracle 10g im Vergleich, 19.Oktober 2005)

Dem ist nichts hinzuzufügen außer diese kleine, wahre Geschichte, die mir Dirk gestern erzählte:

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.

... ist ein weitreichendes und komplexes Unterfangen. Deshalb habe ich bisher tunlichst nur handverlesene Teilbereiche betrachtet.

Man suche z.B. einige Funktionen aus, die eine Datenbank bieten sollte, und vergleiche die Qualität der Unterstützung für ausgesuchte Datenbanken. So geschehen in "Die zweitbeste Datenbank der Welt". Man sollte auch die verglichenen Funktionen nennen, was ich dort offensichtlich nicht getan habe.

Das hole ich hier nach, nicht vollständig und auch nicht in der Reihenfolge des Vergleichs: Partitionierung, XML-Unterstützung, "Self Tuning" und Komprimierung.

Es müssen ja nicht nur Funktionen oder Features sein, es können auch Lizenzbedingungen sein. Das ist oft nicht weniger interessant, wie "Freie Datenbanken von unfreien Anbietern" zeigt.

Aber alles beleuchtet nur einen kleinen Ausschnitt. Ich denke, man kann ... wo ich das gerade schreibe, kommt auf meinem Rechner der RSS zu einem CW-Artikel zu einem DB-Benchmark-Tools herein. So ein Zufall.

Bernd hat den zweiten Vergleich getrackbackt. Dort wünschte sich ein Kommentator einen Vergleich der "Performance und Leistungsfähigkeit". Das ist nun ein schwierigeres Unterfangen, dem ich auch hier nicht nachkommen werde.

Doch einige Bemerkungen zu diesem Thema möchte ich hier loswerden:

Warum migrierte Quelle von Oracle auf den SQL-Server? Schade für Oracle, eigentlich egal für den Rest der Welt.

Denn nicht alle Datenbanken wurden migriert, sondern nur die einer Anwendung für Außendienstmitarbeiter. Ich habe keine Ahnung, warum dies der CW eine ganze gedruckte Seite wert war (immerhin erstreckt sich die digitale Ausgabe über 4 Seiten).

Kurz zusammengefasst: Die bisherige Außendienst-Software erschien zukünftigen Ansprüchen nicht mehr erfüllen zu können. Man fand bei Neckermann (gehört wie Quelle auch zum KarstadtQuelle-Konzern) die Basis für ein neues System. Das Neckermann-System nutze den SQL-Server als Datenbank. Das scheint der unspektakuläre Hintergrund der Geschichte zu sein.

Aber mein Lieblingsredakteur ue wäre nicht ue, wenn er sich nicht aufgrund seiner hervorragenden Kenntnis der Datenbankszene erlauben würde, mehr daraus macht. Was er denn auch tat.