Buch: Data Warehouse Technologien

Als Lehrbuch konzipiert bringt „Data Warehouse Technologien“ aus dem mitp Verlag dem Leser das Thema Datenhaltung für Reporting und Datenanalyse in leicht verständlichen Abschnitten näher. Dabei konzentriert sich dieses Buch rein auf die technischen Aspekte und kümmert sich weniger um betriebswirtschaftliche Belange.


Über neun Kapitel geht der Themenkreis von den Grundlagen OLTP vs OLAP, Big Data und Data Warehosue über zur Architekturen eines Data Warehouses, der Modellierung und der Bewirtschaftung  bis hin zu Abfragen und Business Intelligence Anwendungen.Das so viel Stoff auf knapp 300 Seiten sich nicht erschöpfend behandeln lässt ist wohl jedem klar.
Und so liefert dieses Buch einen guten Durchgang durch die Themenvielfalt Data Warehouse, ohne Anspruch auf Vollständigkeit und doch werden alle wesentlichen Bereiche angesprochen.

Dabei liest sich das Buch angenehm, die Beschreibungen und Beispiele bleiben verständlich und mit den Übungen am Ende eines jeden Kapitels kann der Stoff vertieft werden. Literaturhinweise runden das Buch ab. Als begleitendes Lehrbuch ist es damit gut geeignet, erfahreneren ITlern kann es zum schnellen Nachlesen einzelner Stichpunkte dienen, für einen tieferen Zugang in die Materie Data Warehouse bietet das Buch dann doch zu wenig.
Aber das ist ja auch nicht der Anspruch dieses Werkes!

Veit Köppen, Gunter Saake, Kai-Uwe Sattler

Data Warehouse Technologien

2. Auflage Mai 2014, 352 Seiten

Buch 29,99 €
E-Book 32,99 €

Buch: Data Warehouse BluePrints - Business Intelligence in der Praxis

Dieses Buch ist die Weiterentwicklung des Buches "Data Warehousing mit Oracle - Business Intelligence in der Praxis" aus dem Jahr 2011 aus dem Carl Hanser Verlag. Die Zeit war reif, dieses gute Buch neu und erweitert neu aufzulegen.

Die erfahrenen Consultants von Trivadis haben hier vor allem viel Wert auf eine Ausweitung bei den Konzepten, den Architekturvorschlägen und genereller Vorgehensweisen gelegt. Die Spezialisierung auf Oracle ist dabei deutlich in den Hintergrund getreten. Damit gewinnt dieses Buch und wird mehr noch zu einem allgemeinen, aus der Praxis geborenen Nachschlagewerk.

Neben der allgemeinen Begriffserklärung, was ist ein Warehouse und warum betreiben ich ein solches, geht das Buch Kapitel für Kapitel durch die dazu notwendigen Archtekturen und Schichten eine Data Warehouses. Von der Datenmodellierung über die Vielzahl von Aspekten bei der Datenintegration führen die BluePrints den Leser von den Basics hin zu den BI-Anwendungen, die typischerweise in solchen Szenarien auf ein Data Warehouse aufsetzen. Der Betrieb eines Data Warehouse rundet dann das Buch ab.

Aus eigener Erfahrung weiß ich, dass die in diesem Buch beschriebenen Konzepte und Hinweise nicht aus der Theorie stammen, sondern über die Jahre und durch zahlreiche DWH-Projekte bestätigte Erkenntnisse sind. Alles was hier beschrieben steht, wurde und wird von den Trivadis Consultants täglich bei ihren Projekten angewendet.

Data Warehouse Blueprints
Business Intelligence in der Praxis

Dani Schnider, Claus Jordan, 
Peter Welker, Joachim Wehner

283 Seiten
ISBN-13: 978-3446450752

• Preis: 42 €
  eBook: 33,99 €

Dynamischer OWB

Oft sind es kleine, ehr alltägliche Aufgaben, für die man beim OWB dann die Lösung sucht. Irgendwie hat man das meistens schon einmal gemacht, aber nun kommt man gerade nicht mehr drauf. Wie ging das noch mal?
Oft sind die Antworten auch mit Google nicht einfach zu finden, liegen diese dann doch oft stückweise über diverse Blogs und Foreneinträge verteilt vor. Meistens findet man dann seine Antwort, aber das Suchen dauert halt. Deshalb notiere ich für mich selbst hier solche 'Alltäglichkeiten', als persönliche Notiz. Wenn ich damit anderen helfen kann, bitte bedient Euch. Feedback willkommen.

Dynamische Quelltabellen

Das hier beschriebene Vorgehen funktioniert nur, wenn alle betroffenen Quelltabellen die gleiche Datenstruktur haben! Nachteil dabei, dass Mapping kann nicht mehr parallel mehrfach aufgerufen werden!

Wie also nun machen?

Dem Mapping wird ein Parameter (P_ART) übergeben. Dieser Parameter enthält z.B. den Namen oder Namensteile der gewünschten Quelltabelle. Über den PRE-MAPPING-PROCESS wird der Wert dieses Parameters einer Funktion (F_RENAME_SYNONYM) übergeben. 

Diese Funktion erstellt bzw. ersetzt in einem Synonym (X_ AUFGABEN) den Verweis auf die gewünschte Quelltabelle. 

Das Synonym wurde als Metainformation in den OWB importiert und bei der Erstellung des Mappings als Quelltabelle verwendet. 

Zur Laufzeit des Mappings werden die Daten nun aus der jeweiligen Tabelle gelesen, auf das das Synonym zu der Zeit aktuell verweist. So kann dynamisch für jeden Lauf die Quelltabelle gewechselt werden.

Quellen hierzu:
OWB – Reuse Mapping for Different Data Sources
Thread: Dynamically passing the source table name to OWB mapping

Dynamischer Filter

Wird immer mal wieder benötigt, ein Filter für z.B. Aufgaben soll entsprechend eines Parameters (P_ART) sich dynamisch anpassen und so unterschiedlich filtern. 

Dazu wird im FILTER-Expression die Bedingung entsprechend angepasst. Hier geschieht das z.B. durch ein CASE Statement, in dem je nach Art (P_ART) unterschiedlich die Daten dann ausgefiltert werden. 

Weitere Filterbestandteile sind hier eine Eingrenzung auf den Zeitraum ab 2009, auf ein Land und auf ein FA. Die letzteren beiden wurden ebenfalls per Parameter dem Mapping übergeben.
Der gesamte Filter-Ausdruck wird im Joiner des Mappings dann der WHERE-Bedingung hinzugefügt. 

Zur Laufzeit werden die Daten nun dynamisch, je nach Parameterwert, ausgefiltert.

Quelle hierzu:
case expressions and statements in oracle 9i

Dynamische Dateinamen für Exportdateien

Der OWB ist ja in der Lage als Ziel auch eine Datei zu schreiben. Möchte man nun den Dateinamen nicht fest in der CONFIGURATION des Mappings eintragen, sondern dynamisch bilden - aber wie.
Auch hier wird dem Mapping ein Parameter (P_ART) übergeben. Dieser Parameter soll nun auch den Namen der Exportdatei in Teilen mitbestimmen. Da alle Exportdateien in das gleiche Verzeichnis geschrieben werden, reicht es hier die Dateinamen bei jedem Ladelauf anzupassen. 

Dazu wird in der CONFIGURATION des Mappings bei den FlatFile Einstellungen der Eintrag `||P_ART||‘ vor dem allgemeinen Teil des Dateinamens eingetragen. 
Zur Laufzeit wird dieser Parameter dann durch seinen Wert ersetzt und bildet so den entsprechenden Dateinamen, ganz einfach also (sic!)

Quelle hierzu:
Thread: Export Data from Database Table into CSV File with OWB Mapping
Thread: OWB: Flat File Name - Can you use an input parameter

Alle Teile wurden mit dem OWB Version 11.2.0.3 erstellt.

Interessantes zum OWB 11.2

Oracle war beim Wechseln von Produktnamen schon immer recht kreativ.
Nun gibt es beim OWB die nächste Umbenennung, die OWB Standard Edition ist inzwischen ja ein Bestandteil der Oracle Datenbank. Nun bekommt diese Version den Arbeitstitel "InDatabase ETL". Mit dieser Version steht dem Anwender ein großer Teil der OWB Funktionalitäten über seine Datenbank-Lizenz mit zur Verfügung.

Warum das ganze? Oracle hat inzwischen seine Roadmap für die beiden ETL Tools OWB und ODI bekannt gegeben. Bis zum Jahre 2012 soll eine Zusammenführung erfolgen und dann wird es mit Oracle 12 nur noch ein ETL Produkt geben.


Bis es soweit ist, werden beide Tools als ein Produkt im Bundle als 'ODI EE' verkauft. Mit dem Bundle erwirbt man das Recht den ODI und den OWB in der 'Enterprise ETL Option' zu nutzen.
Eine reine Marketinglösung also.

Bevor aber Oracle 12 erscheinen wird, gibt es mit der kommenden Version OWB 11gR2 noch ein paar nette neue Möglichkeiten:

• Die ODI-Knowledge Module sollen nun doch als kostenpflichtige Zusatzoptionen enthalten sein. Mit diesen Modulen ist man dann in der Lage heterogene Quellen und Ziele (eben auch Nicht Oracle Datenbanken) native anzusprechen.
• Unterstützung für Tabellen DDL
• Advanced Compression für Tabellen
• Virtual Columns
• Unterstützung für alle Partition Optionen
  
• Data Pump
• Cube MVs für die OLAP Option 11.2
• Neue Funktionalität beim Mapping-Editor
• WebServices Support
• JDBC Unterstützung

Der OWB bleibt ein spannendes, gutes Produkt und Oracle zeigt mit seiner Roadmap, dass es auch zukünftig eine wichtige Rolle in seiner Produktstrategie spielen wird.

OWB Converter nach ODI

Wer die DOAG News liest, dem ist vielleicht die Anzeige der ID&T, IT-Beratungs- und Servicegesellschaft, mit Sitz in Mailand aufgefallen. Dort hat man einen OWB2ODI Converter entwickelt.

Nun frag ich mich, wozu brauche ich so ein Tool? Der OWB und der ODI sind beides gute Produkte und Oracles Roadmap zeigt den Weg auf, wie aus diesen zwei Produkten einmal ein neues Produkt werden soll.
Warum sollte also ein Anwender seine Prozesse vom OWB mittels dieses Converters auf den ODI bringen, wenn in ein paar Jahren diese Zusammenführung quasi automatisch erfolgt? Diese doppelte Migration macht für einen OWB Anwender einfach keinen Sinn!

Der Hersteller spricht von ‚semi automatic conversion‘. Was meiner Meinung bedeutet, dass es bei sehr einfachen OWB Projekten einigermaßen klappen kann. Je komplexer dann die Mappings werden, um so größer wird der manuellen Aufwand bei der Konvertierung sein. Das Tool wird dann nur Rumpfteile eines Mappings im ODI liefern können und diese Teile gilt es dann mühsam manuell zusammen zu führen. Keine Berücksichtigung findet bei dem Tool der gesamte Workflow, der muss im ODI komplett neu erstellt werden. Und testen muss man das neue System im ODI dann sowieso. Da liefert einem der Converter keine Hilfe.

"Ich halte das für eine "Katastrophe", weil es suggeriert OWB sein ein Auslaufmodell."

So äußerte sich Alfred Schlaucher mir gegenüber. Die Interessen sind aus seiner Sicht klar, in Frankreich und Italien hat der ODI eine größere Verbreitung als z.B. in Deutschland und

"dort agiert man massiv gegen den OWB"

Seine Empfehlung für OWB Anwender sieht so aus:

"Von den vielen OWB Installationen die ich kenne, wüsste ich gegenwärtig nicht, für wen das interessant sein sollte. Das hat auch nichts mit der künftigen Erwartung für ein gemeinsames Tool OWB/ODI zu tun.
Denn künftig (ab Version 12+) wird es ein sehr stark an das OWB-Repository angelehntes gemeinsames Repository geben. Ein heutiger OWB-Nutzer müsste dann gleich 2 mal seine Metadaten migrieren.
Für alle heutigen OWB-Nutzer empfehle ich zunächst das Release 11.2 einzusetzen. Das wird zusammen mit dem DB-Release 11.2 wahrscheinlich von LE im Julie announced und steht sicherlich zur nächsten Open World zur Verfügung.
Da ist eine Nähe zum SQL-Developer zu finden. Alle Heterogenitäts-Themen lassen sich schon heute gut lösen, sofern wir wirklich solche haben."

Dem kann ich mich nur anschließen, eine funktionsfähige OWB Anwendung einfach nur so zum ODI zum jetzigen Zeitpunkt zu migrieren halte ich für Unsinn. Die Oracle Roadmap ist in ihrer Aussage klar, es wird zu einer Verschmelzung beider Produkte kommen. Bis dahin kann jeder OWB Anwender in Ruhe seine Prozesse weiter mit dem OWB betreiben und weiter entwickeln. Wenn es dann soweit ist und es gibt nur noch ein ETL Produkt von Oracle, dann migriert er einmal (!) seine OWB Prozesse. Und ich bin sicher, dass es dann entsprechende Unterstützung durch Oracle geben wird.
Ansonsten unterstützen wir unsere Oracle Kunden natürlich auch in diesen Fragen. Wer mag, kann sich gerne an mich wenden.

Future of the OWB

Etwas spät berichtet auch der Oracle OWB-Blog über die Zukunft des Warehouse Builders und die ODI Enterprise Edition. Ich hatte ja bereits über die Oracle Data Integrator Enterprise Edition berichtet.

Die beiden Produkte werden in dieser Enterprise Editon von Oracle als ein Produkt mit einer Lizenz angesehen.
Daneben wird in dem Beitrag auf die folgenden Punkte für OWB Nutzer hingewiesen:

• All of the features of Oracle Warehouse Builder 11.1 as you’ve known it are still available, and will continue to be available going forward. (The features that were in OWB Enterprise ETL are now only available in the ODI-EE product. Essentially you get both, and then whichever product better fits your business and technical needs, you can implement.)
• Oracle Warehouse Builder 11.2 is still on track to be released with Oracle Database 11gR2.
• Support, training, and other resources (like this blog) for Oracle Warehouse Builder will continue to be available, Oracle University classes will be updated for 11.2, and so on.
• As stated above, “Customers can safely choose either component [i.e. either Warehouse Builder with Enterprise ETL features or Oracle Data Integrator] as the basis for implementations today”, with a smooth migration path going forward.
• Oracle Warehouse Builder data quality features are still available, but are now packaged as the Oracle Data Profiling and Data Quality option to the Oracle Database Enterprise Edition. (This is essentially just a name change for the data quality features.)
• OWB Application Connectors are still available, but are now re-named as Application Adapters for Warehouse Builder.
• The core OWB features that have been included with all Oracle database licenses (except XE) are still included with every Oracle database license.

Es ist also in diesem ersten Schritt lediglich eine Namens- und Lizenzefrage und die Anwender können sich sicher sein, dass der OWB auch in den nächsten Jahren ihnen zur Verfügung stehen wird.
Das Oracle Data Integrator - Statement of Direction zeigt die weiteren Schritte der Entwicklung beider Produkte zum heutigen Stand auf.

Oracle Data Integrator Enterprise Edition

Nun ist es offiziell, Oracle bringt ein neues Bundle zur Datenintegration heraus. In der Oracle Data Integrator Enterprise Edition verschmelzen der ODI und der OWB zu einem Produkt.

"Today Oracle includes Oracle Data Integrator (ODI) and Oracle Warehouse Builder (OWB) as the two components of ODI-EE and will merge them into a single unified data integration technology platform."
Oracle Data Integrator - Statement of Direction

Aktuell ist das Bundle ehr ein Verkaufsargument, der Kunde kann zwischen beiden Produkten wählen und benötigt nur eine Lizenz. In der nächsten OWB Version sollen dann die Knowledge Module unterstützt werden und 2011/2012 sollen dann beide zu einem Produkt vereint sein.

"All existing ODI and OWB customers will be able to upgrade to ODI-EE and the
merged data integration platform on a schedule that makes sense for their own
Data Integration Statement of Direction Page 5
businesses. There will not be any forced migrations and Oracle will provide an easy
upgrade path onto the new platform once it is generally available."

Hier die geplante Roadmap:

• Oracle Data Integrator 11g Calendar Year 2009
• Oracle Warehouse Builder 11g R2 Calendar Year 2009
• Oracle Data Integrator 11 R2 Calendar Year 2010
• Converged data integration platform Calendar Year 2011

Weitere Infos zur Oracle Data Integrator Enterprise Edition

Oracle Warehouse Builder Produkt Roadmap

Nun beginnt Oracle also doch die Zusammenführung seiner beiden ETL Produkte, dem Oracle Warehouse Builder (OWB) und dem Oracle Data Integrator (ODI).

Ursprünglich hatte Oracle beide Produkte getrennt vermarktet und sah den ODI im Rahmen seiner Fusion Strategie als Integrationswerkzeug in heterogenen Datenbank Umfeld. Den OWB sah man als bewährtes Werkzeug um DWH Projekte auf Oracle Basis zu erstellen. Laut Roadmap sollen in 2007 bereits über 10.000 Firmen den OWB im Einsatz haben.

Nach der aktuellen Roadmap für den OWB erfolgt die Zusammenführung in mehreren Schritten.
So unterstützt die neue Version 11g R1 den Oracle Business Intelligence Enterprise Editon Server (OBI EE), hat einen Connector für Siebel, unterstützt SOA Architekturen und enthält nun in seiner Installation den Oracle Workflow (!). Weiter gibt es eine Reihe von Verbesserungen, Details hier (Powerpoint).

In kommenden Releases wird der OWB dann die mit dem ODI entwickelte "Knowledge Module Framework" unterstützt. Damit ist er dann in der Lage Code für nicht Oracle Umgebungen zu erzeugen und auszuführen.
Die beiden Produkte integrieren so immer mehr Teile des anderen und wachsen zusammen. Bis am Ende ein Produkte mit einer einheitlichen Oberfläche herauskommen soll.

Damit ist auch die beliebte Kundenfrage 'Hat der OWB überhaupt eine Zukunft' eindeutig beantwortet - ja !

[via Computerwoche]

ETL Tool nutzen?

Die Kimball University fragt "Should You Use An ETL Tool?"

Der Artikel stellt die Vor- und Nachteile beim Einsatz von ETL-Tools dem selbstgeschrieben Programmcode gegenüber.

Im Fazit empfehlen sie den Einsatz, auch wenn erfahrene Experten ETL-Prozesse per Programm super erstellen könnten. Oft sind diese Leute externe Berater und was macht die Firma nachdem diese Berater nicht mehr im Hause sind?! Eben da kommt ein großer Vorteil von Tools ins Spiel. Oder im weiteren Lebenszyklus des Projektes, wenn Änderungen und Erweiterungen gemacht werden müssen. Da spielen ETL-Tools ihre Vorteile dann aus und rechtfertigen auch ihre Lizenzkosten.

"You can still hand-code an extract, transform and load system, but in most cases the self-documentation, structured development path and extensibility of an ETL tool is well worth the cost."

[gefunden via Duncan Lamb]

Oracle Data Integration Suite

Durch einen Artikel im Blog von Peter Scott bin ich auf den Artikel von Vincent McBurney gestoßen.

Er beschreibt in seinem Artikel sehr schön die von Oracle neu vorgestellte Oracle Data Integration Suite. In dieser Suite führt Oracle jetzt Teile von Sunopsis, Hyperion und Trillium zusammen und packt noch ein wenig BPEL und SOA hinzu.

Damit steht Oracle Kunden nun eine dritte Lösung zur Datenintegration zur Verfügung. Fragt sich was aus Produkten wie ODI und OWB wird. Wo gehen bei diesem Thema die Wege von Oracle?

OWB Objekttransport ...

Das Problem kennt jeder der mit dem Oracle Warehouse Builder (OWB) arbeitet. Wie in größeren Projekten üblich habe ich eine Entwicklungs-, eine Test- und eine Produktionsumgebung. Und damit habe ich auch drei OWB Repositorys.
Der Weg ist immer aus der Entwicklung über Test zur Produktionsumgebung hin. Abweichend kann es vorkommen, dass z. B. auf Test ein Fehler der Produktion behoben wird, während auf Entwicklung bereits das nächste Release in Arbeit ist. Dann ist der Entwickler aber auch gefordert die Änderung von Test auf der Entwicklung nachzuziehen!
Um nun die OWB Objekte von einer Umgebung in die nächste zu transportieren erzeugt man sogenannte Exportdateien (MDL). Diese Dateien können dann auf der Zielumgebung entsprechend wieder importiert werden.
Nun transportiert man ja nicht immer alles aus einem Repository in das nächste. Was ist z. B. bei kleineren Bugfixen oder Erweiterungen in Teilen des Systems?
Bewährt haben sich dafür die 'Collections' im OWB. Hier kann ich bereits während der Entwicklung alle bearbeiteten Objekte eintragen. Beim späteren Export wird dann keines vergessen. Denn eine Collection kann exportiert werden und, da hier nur Referenzen auf die OWB Objekte hinterlegt werden, exportiere ich über die Collection alle eingetragenen Objekte! Klasse Sache, vorallem wenn das dann noch per OMB Skript automatisiert wird.
Aber das ist ein anderes Thema...

OWB Runtime Infos einfacher einsehen

Jeder der mit dem Oracle Warehouse Builder (OWB) arbeitet kennt das Problem. Man möchte der Ursache eines Laufzeitproblems auf die Schliche kommen und dafür in das Runtime Repository schauen. Startet also den Warehouse Builder Browser, meldet sich an und ... wartet.
Das Teil ist einfach nur langsam, belastet mit seinen Abfragen die Datenbank und unterbindet ein zügiges arbeiten.

Als mir nun dieses Verhalten in einem Projekt zu extrem wurde, habe ich ein wenig im Internet gesucht und bin auf folgenden Beschreibung gestoßen.
Diese View basiert auf der API des OWB Repositorys und erlaubt damit einen schnelleren Zugriff auf die Runtime Informationen.
In der nächsten Zeit werde ich damit ein wenig probieren und die Erfahrungen gibts dann in einen neuen Eintrag.