Analyse der BI-Lösung von Pentaho

Aus Winfwiki

Namen der Autoren:	Xin Fu, Arne Holzapfel
Titel der Arbeit:	"Analyse der BI-Lösung von Pentaho"
Hochschule und Studienort:	FOM Hamburg

Inhaltsverzeichnis 1 Abkürzungsverzeichnis 2 Abbildungsverzeichnis 3 Tabellenverzeichnis 4 Einleitung 5 Grundlagen 5.1 Business Intelligence 5.1.1 Data Warehouse 5.1.2 OLAP 5.1.3 Data Mining 5.1.4 Reporting 5.2 Open Source 5.3 Unternehmen und Produkt 5.4 Markübersicht 6 Analyse 6.1 Bewertungskriterien 6.1.1 Qualitätsanforderungen 6.1.2 Kosten 6.2 Softwaretest 6.3 Testszenario 6.4 Pentaho Data Integration 6.4.1 Funktionsumfang 6.4.2 Bedienungsfreundlichkeit 6.4.3 Interoperabilität 6.5 BI Server und Dashboard 6.5.1 Funktionsumfang 6.5.2 Wartungsfreundlichkeit 6.6 OLAP mit Pentaho Analysis 6.6.1 Funktionsumfang 6.6.2 Bedienungsfreundlichkeit 6.6.3 Interoperabilität 6.7 Pentaho Reporting 6.7.1 Funktionsumfang 6.7.2 Bedienungsfreundlichkeit 6.7.3 Interoperabilität 6.8 Pentaho Data Mining 6.9 Kosten für Einrichtung und Betrieb 7 Fazit und Ausblick 8 Fußnoten 9 Literatur- und Quellenverzeichnis

1 Abkürzungsverzeichnis

Abkürzung	Bedeutung
API	Application Programming Interface
BI	Business Intelligence
DB	Datenbank
EPL	Eclipse Public License
ERP	Enterprise Resource Planning
ETL	Extract Transform Load
GPL	GNU General Public License
HTML	Hypertext Markup Language
IDE	integrated development environment
JDBC	Java Database Connectivity
LGPL	GNU Lesser General Public License
MDX	Multidimensional Expression
MOLAP	Multidimensional On-Line Analytical Processing
MSS	Management Support Systeme
OLAP	On-Line Analytical Processing
OLE	Object Linking and Embedding
OLTP	Online Transactional Processing
OSS	Open Source Software
PDF	Portable Document Format
PDI	Pentaho Data Integration
ROI	Return on Investment
ROLAP	Relational On-Line Analytical Processing
RSS	Really Simple Syndication
XML	Extensible Markup Language

2 Abbildungsverzeichnis

Abb. 1:	BI-Übersicht
Abb. 2:	Datenmodell Testszenario ERP-System
Abb. 3:	Screenshot Pentaho Data Integration (Spoon)
Abb. 4:	Dimensionales Modell als Zielstruktur
Abb. 5:	Definition Cube-Schema mit Schema Workbench
Abb. 6:	OLAP mit JPivot - Ertrag Manager je Quartal
Abb. 7:	Berichtserstellung mit Pentaho Report Designer
Abb. 8:	Visualisierung Entscheidungsbaum mit Weka

3 Tabellenverzeichnis

Tabelle 1:	Pentaho Community & kommerzielle Editionen im Vergleich
Tabelle 2:	Klassifizierung der Kostenarten
Tabelle 3:	Zusammenstellung Testdaten

4 Einleitung

Der Markt für Lösungen im Umfeld des Business Intelligence (BI) wächst stetig und soll weiter wachsen.^[1] Dies gilt auch oder besonders in Zeiten eines konjunkturellen Abschwungs, da sich die Bedeutung der Entscheidungsqualität verstärkt. Vor diesem Hintergrund nimmt allgemein die Nachfrage nach Software-Lösungen zur Entscheidungsunterstützung zu. Der generelle Kostendruck und die Unwägbarkeit von Erfolg oder Misserfolg eines BI-Projekts kann aber auch die Investitionsbereitschaft in entsprechende Systeme hemmen.
Anbieter kostengünstiger Alternativen eröffnen sich somit besondere Chancen.^[2] Open Source-Lösungen versprechen den Einsatz von BI-Systemen mit einem geringen Budget. Als einer der Anbieter von Open Source Business Intelligence hat sich das Unternehmen Pentaho mit seinem Produkt in diesem Segment etabliert.
Die Lösung von Pentaho deckt dabei ein breites Spektrum an Werkzeugen ab, die typischerweise für Analysezwecke zum Einsatz kommen.
Hierunter sind zu nennen

• geeignete Werkzeuge zur Befüllung einer Analyse-orientierten Datenhaltung,
• das On-Line Analytical Processing (OLAP), Reporting und Data Mining,
• ein webbasiertes Frontend für eine komprimierte Darstellung der Analyseergebnisse (Dashboards).

Die Architektur der einzelnen Komponenten folgt dabei einem modularen Ansatz. Die Software ist als Open Source (Community Edition) und kommerzielle Variante erhältlich. Neben professionellem Support stellt die kommerzielle Edition zusätzliche Funktionalitäten bereit.
Mit dem Einsatz der Open Source-Variante sind keine Lizenzgebühren verbunden. Hierdurch ergibt sich eine besondere Eignung für die Evaluierung mit einem knappen Budget.
Das Kapitel Grundlagen soll einen Überblick über BI Konzepte und Techniken verschaffen sowie einen kurzen Blick auf die Spezifika des Produkts und die Gegebenheiten des Marktes werfen. Aus den Grundlagen abgeleitet ergeben sich Anforderungen an bestimmte Kriterien zur Bewertung der BI-Lösung. Im Rahmen eines Testszenarios werden dann die einzelnen Komponenten des Systems unter Berücksichtigung der entwickelten Kriterien untersucht. Ziel der Analyse soll die Erarbeitung von Chancen und Risiken sein, die mit dem Einsatz der Software verbunden sind. Hierbei soll der Kostenaspekt neben den technischen Stärken und Schwächen des Systems Berücksichtigung finden.

5 Grundlagen

5.1 Business Intelligence

Nach Kemper kann Business Intelligence (BI) als „integrierter, unternehmensspezifischer, IT-basierter Gesamtansatz zur betrieblichen Entscheidungsunterstützung verstanden“ werden. Zielgruppe des Systems sind Entscheidungsträger aus allen Ebenen des Managements.^[3] Für die Anforderung der Entscheidungsunterstützung stellt das System „tragfähige und miteinander verknüpfte Lösungen“ bereit.^[4]
Die Entwicklung von IT-gestützten Systemen zur Entscheidungsfindung reichen bis in die 1960er Jahre zurück. Informationssysteme für das Management stellen einen ersten Ansatz dar. In den 1980ern werden unter dem Sammelbegriff Management Support Systeme (MSS) die Möglichkeiten der Entscheidungsunterstützung, die sich aus der Informations- und Telekommunikationstechnologie ergeben, zusammengefasst. Seit den 1990ern ist der Begriff BI gebräuchlich, der von der Gartner Group geprägt wurde und zunächst als Sammelbegriff für Frontend-Werkzeuge diente.^[5]

BI umfasst die Datenbereitstellung, Datennutzung und Präsentation der Daten. Die in diesem Zusammenhang anfallenden Aufgaben werden von unterschiedlichen Werkzeugen übernommen. Die Werkzeuge sollen reibungslos zusammenarbeiten.^[7]
Im Zuge der Datenbereitstellung werden die Daten aus operativen Vorsystemen und externen Quellen in eine dispositive Speicherhaltung überführt. Diese Aufgabe wird von ETL-Werkzeugen (Extract, Transform, Load) übernommen. Nach der Extraktion der Daten aus den Vorsystemen erfolgt die Transformation. In diesem Schritt werden die Daten auf Integrität geprüft und ggf. gefiltert, über Aggregation verdichtet oder um berechnete Werte angereichert. Die aufbereiteten und vereinheitlichten Daten werden dann in dispositive Speicher geladen. Für die Speicherhaltung wird eine spezielle Datenbank, das sog. Data Warehouse, genutzt.^[8]
Die Datennutzung kann einerseits in der Verwendung der durch die BI-Lösung bereitgestellten Werkzeuge (generisches Basissystem) und andererseits in der Abbildung betriebswirtschaftlicher Konzepte (z.B. Balanced Scorecard) bestehen. Zu den Werkzeugen der Basissysteme zählen nach Kemper Berichtssysteme, modellgestützte Analysesysteme (u.a. Data Mining), freie Datenrecherchen und Systeme für das On-Line Analytical Processing (OLAP).^[9]
Die Prozesse von der Integration über die Analyse der Daten bis zur Präsentation stützen sich auf Metadaten. Die Metadaten enthalten Informationen über Ausgestaltung und Zusammenhang der zugrundeliegenden Datenstruktur.^[10]
Für den Zugriff auf die von den BI-Lösungen bereitgestellten Ergebnisse eignen sich webbasierte Portale, in denen den Anwendern die individuell zugeschnittenen Inhalte in einer einheitlichen Form präsentiert werden. Die Anbindung unterschiedlicher Kanäle (z.B. RSS, Widgets) und Endgeräte (z.B. Smartphones) sowie die Personalisierung des Inhalts lassen sich so auf Basis von Techniken der Webprogrammierung (z.B. Webservices) realisieren.^[11] Als vergleichbares Instrument zur Darstellung von Inhalten auf Basis von Web-Technologien sind ebenfalls sog. Dashboards etabliert. In dieser Darstellungsform steht die Verdichtung der Daten in Form von Kennzahlen und Visualisierungen (z.B. Tachometer) im Vordergrund.^[12]

5.1.1 Data Warehouse

Nach der Definition von Bauer/Günzel^[13] lässt sich ein Data Warehouse als Datenbank zu "Analysezwecken" beschreiben, das seine Daten aus "unterschiedlichen Quellen" bezieht.
Im Data Warehouse bleiben die Daten unverändert bestehen. Es kommen nur neue Datensätze hinzu. Für operative Systeme sind auf Transaktionen gestütze Modifikationen der Daten typisch. Um diesen Unterschied zu verdeutlichen, werden die operativen Systeme auch „Online Transactional Processing (OLTP)“ genannt^[14].
Die Architekturansätze der Data Warehouse-Lösungen stellen sich sehr heterogen dar. Einerseits sind die Lösungen historisch gewachsen, andererseits für die spezifischen Bedürfnisse der Unternehmen gestaltet.^[15] So existieren teilweise unabhängige, auf eine bestimmte Anwendung ausgerichtete Datenpools (sog. Data Marts). Durch die fehlende Integration der Data Marts entstehen sog. Datensilos, die für zentrale Analysen ungeeignet sind. Eine weitere Architekturvariante besteht in dem Verzicht auf Data Marts und dem Aufbau eines zentralen (Core-)Data Warehouses. Der von Kemper präferierte Ansatz sieht eine integrierte Lösung vor, in der die Data Marts über Transformationsprozesse aus einem zentralen Data Warehouse aufgebaut werden.^[16]
Den Ansätzen gemein ist die Aufgabe der Überführung der Daten aus den verschiedenen operativen Quellsystemen in eine dispositive Datenhaltung (ETL-Prozess).
Als Zielstruktur des ETL-Prozesses empfiehlt Kimball^[17] ein dimensionales Modell (dimensional modelling) für das Data Warehouse. Das dimensionale Modell kennzeichnet eine Aufteilung der Daten in Measurements und Dimensions.
Measurements sind Daten, die aus den Geschäftsprozessen des Unternehmens entstehen und durch die unterstützenden IT-Systeme erfasst werden. Es handelt sich um Zahlenwerte, die auch als Fakten (facts) bezeichnet werden. Die Zahlen stehen im Kontext mit Zu- oder Umständen, die zum Zeitpunkt der Erfassung gegolten haben. Der informationstechnische Kontext wird als Dimension bezeichnet. Umgesetzt in ein Datenbankmodell entsteht ein dimensionales Modell. Die Assoziation mit einem Stern, die sich aus dem Aufbau einer Faktentabelle und den referenzierten Dimensionstabellen ergibt, ist Namensgeber für das Star-Schemata ("star schema"). Die Verbindung von Fakten- mit Dimensionstabellen werden über Foreign-Keys abgebildet. Die Schlüsselverbindungen gewähren bei Joins der Tabellen einen Performance-Gewinn und dienen der Datenintegrität.^[18]
Ein weiterer Unterschied neben der Lagerdauer der Daten besteht zwischen dispositiver und operativer Datenhaltung in dem Grad der Normalisierung. Das Datenmodell operativer Systeme ist zur Optimierung von Transaktionen normalisiert. Das dimensionale Modell verzichtet zu Gunsten der Verständlichkeit und der Optimierung für Analyse-Abfragen auf eine Normalisierung bis zur 3. Normalform. Das dimensionale Modell wird auch als denormalisiert bezeichnet.^[19]
Wenn funktionale Abhängigkeiten zwischen Attributen einer Dimensionstabelle wieder aufgelöst werden (Reduzierung der Denormalisierung), entsteht ein Snowflake-Schema. Werden mehrere Star-Schemata über gemeinsame Dimensionen referenziert, spricht man von einer Galaxie.^[20]
Die Struktur des dimensionalen Modells ist Grundlage für On-Line Analytical Processing (OLAP). OLAP-Werkzeuge setzen auf multidimensionalen Datenstrukturen auf, die cubes (Würfel) genannt werden. Die cubes werden aus dem dimensionalen Modell abgeleitet^[21] (dies gilt zumindest für relationale OLAP Architekturen^[22]).

5.1.2 OLAP

Das On-Line Analytical Processing unterstützt Informationstechnisch die „Hypothesenverifizierung“. Der Anwender überprüft mit Hilfe des Systems im Vorhinein getroffene Annahmen. Im Gegensatz dazu dient das Data Mining der „Hypothesengenerierung“. Die Konzepte und Methoden des Data Mining decken Zusammenhänge und Entwicklungen der zugrundeliegenden Daten auf, die im Vorhinein nicht offensichtlich sind.^[23]
OLAP-Systeme bieten einen multidimensionalen Blick (OLAP-Cube) auf die zugrundeliegenden Datenbestände. Die Gestaltung der Systeme soll eine flexible und intuitive Informationsgewinnung gewähren. Die Dimensionen strukturieren hierbei quantitative Größen wie betriebswirtschaftliche Kennzahlen. Dimensionen der Betrachtung sind z.B. Kunden, Artikel, Ort und Zeit. Anhand der Dimensionen können die Kennzahlen verdichtet werden. Die Dimensionen weisen dabei eine hierarchische Struktur auf.^[24]
Nach Codd sind zwölf Regeln für die Evaluierung^[25] von OLAP-Systemen anzuwenden. Die dort geforderte intuitive Datenmanipulation soll es erlauben, die Daten für die gewünschte Analyse per Mausklick miteinander in Beziehung zu setzen.
Die Konzepte des Drill-Down, Roll-Up, Slicing, Dicing und die Rotation des Würfels setzen diese Forderung um. Das Drill-Down erlaubt das Hinzufügen einer weiteren Konsolidierungsstufe in die Analysebetrachtung. Wohingegen das Roll-Up den Wechsel in eine höhere Aggregationsebene beschreibt.^[26] Das Slicing schränkt die Datenmenge, die dem Würfel zugrunde liegt, nach bestimmten Kriterien ein. Das Dicing bildet eine Projektion von bestimmten Elementen einer Dimension ab.^[27] Der Anwender soll die Operationen interaktiv und komfortabel im OLAP-System durchführen können.
Die OLAP-Systeme unterscheiden sich durch ihre Konzepte der Datenspeicherung. Das Relationale OLAP (ROLAP) hält die Daten in relationalen Datenbanken vor. Das multidimensionale OLAP (MOLAP) legt die Daten in einer multidimensionalen Struktur ab. MOLAP bietet Performance-Vorteile bei der interaktiven Aggregation durch den Anwender. ROLAP kann sich auf die umfangreichen Managementsysteme der relationalen Datenbanken stützen. Die von Pentaho verwendete OLAP-Engine Mondrian basiert auf einer ROLAP-Architektur.^[28]

5.1.3 Data Mining

Data Mining dient der Mustererkennung in Datenmengen, die vorzugsweise in Data Warehouses oder Data Marts abgelegt sind. Für die Analyse der Daten werden allgemeine und effiziente Methoden bereitgestellt. Die Systeme sollen dabei in der Lage sein, die geeigneten Methoden selbstständig auszuwählen, die Daten zu analysieren und zu visualisieren. In einem weiteren Begriffsverständnis entwickelt der Anwender eine bestimmte Hypothese und lässt bestimmte Daten mit Hilfe des Systems daraufhin analysieren. In einem engeren Verständnis des Begriffs obliegen diese Aufgaben ebenfalls dem Data Mining-Werkzeug.^[29]
Die Methoden des Data Mining stützen sich auf Erkenntnisse aus der Statistik und aus der Forschung zu Künstlicher Intelligenz.^[30] Die Anwendungsgebiete für Data Mining sind vielfältig. Eingesetzt werden die Verfahren z.B. zur Analyse des Kaufverhaltens von Kunden (Warenkorbanalyse), um interessante Informationen für das Marketing zu gewinnen.^[31]
Als gängige Verfahren des Data Mining sind Clustering, Visualisierungen, Entscheidungsbäume, Assoziationsanalysen und Neuronale Netze zu nennen.^[32]
Das Clustering versucht mit Hilfe geeigneter mathematischer Verfahren und Algorithmen den Datenbestand in möglichst homogene Gruppen oder Segmente zu unterteilen. Die Daten eines Segments weisen dabei bestimmte Ähnlichkeiten auf, die sie von den Ausprägungen anderer Gruppen unterscheiden.^[33]
Entscheidungsbäume beruhen auf der Vorgabe bestimmter Klassen mit bestimmten Ausprägungen. Anhand der vorgegebenen Klassifizierung werden die Datensätze den Klassen zugeordnet, zu denen sie die größte Ähnlichkeit aufweisen. Für die Bestimmung der Klassifizierung wird zunächst eine Trainingsmenge ausgewählt, aus der die Regeln für die Klassen abgeleitet werden. Die Regeln werden durch Anwendung auf eine Testmenge geprüft. Ergebnis der Prüfung ist eine Fehlerquote von nicht passenden Datensätzen, die Aufschluss über die Gültigkeit der aufgestellten Regeln gibt.^[34]
Künstliche Neuronale Netze sind in der Lage verdeckte Muster im Datenbestand zu erkennen und aufgrund dessen Klassifizierungen oder Prognosen vorzunehmen. Die Neuronalen Netze setzen sich aus einzelnen Verarbeitungselementen (sog. Neuronen) zusammen, die mit einander verknüpft ein Netz darstellen. Nach bestimmten Regeln ist das Netz in der Lage sich selbst zu organisieren (machine learning).^[35]
Die Assoziationsanalyse versucht Beziehungen zwischen Datensätzen zu finden. Mit Hilfe des Verfahrens können z.B. Erkenntnisse über das Kaufverhalten von Kunden gewonnen werden. So können z.B. Abhängigkeiten von Artikelgruppen erkannt werden, die im Verbund gekauft werden.^[36]

5.1.4 Reporting

Die Reporting-Systeme dienen der Darstellung von betrieblichen Sachverhalten. Berichte können sich aus graphischen und textuellen Elemente zusammensetzen.
Unterschieden werden können periodische und aperiodische Berichte. Aperiodische Berichte werden auf bestimmte Ereignisse hin generiert und dienen z.B. als Frühwarnsystem. Periodische Berichte (Standardberichte) unterliegen einer festen Form. Bei Abweichungen können die Berichte jedoch Ausnahmemeldungen enthalten.^[37]
Die Reporting-Lösungen stellen eine Reportschablone bereit, mit welcher der spätere Inhalt und das Layout des Berichts definiert werden. Das Ergebnis des Berichts ergibt sich dann durch die Befüllung der Vorlage mit aktuellen Daten. Graphische Werkzeuge erlauben die Erstellung der Schablone ohne programmiertechnische Kenntnisse. Per Drag and Drop können dann die Gestaltungselemente in die Schablone aufgenommen werden.^[38]
Neben den Standardberichten stellen BI-Lösungen häufig die Möglichkeit der Erzeugung von Ad-Hoc-Berichten bereit. Der Anwender kann über Navigationselemente die Daten für den Bericht selbstständig selektieren und zur Anzeige bringen.^[39]

5.2 Open Source

Open Source Software (OSS) steht jedem zur freien Nutzung zur Verfügung. Eine Definition für den Begriff liefert die Open Source Initiative (http://www.opensource.org). Charakteristika sind der Verzicht auf Lizenzgebühren durch den Rechteinhaber und der offene Sourcecode, d.h. jeder darf den Sourcecode einsehen, kompilieren und debuggen. Im Gegensatz dazu wird Closed Source oder proprietäre Software als Begriff für Programme verwendet, die diese Merkmale nicht aufweisen.^[40]
Das zentrale Unterscheidungsmerkmal von OSS-Lizenzen ist der Grad der Umsetzung des Copyleft-Gedankens. Wird in einem Programm Open Source Software verwendet, die ein Copyleft vorsieht, muss dieses Programm ebenfalls unter die Lizenz der OSS gestellt werden. Die GNU General Public License (GPL) und die Eclipse Public License (EPL) sehen ein strenges Copyleft vor. Software, die GPL-lizensierte Komponenten verwendet, muss ebenfalls unter der GPL stehen. Die GNU Lesser General Public License (LGPL) stellt die Wahl der Lizenz frei, wenn in einem Software-Bundle der LGPL-lizensierte Programmcode unverändert bleibt.^[41] Damit eignet sich Software unter der LGPL auch zur Einbindung in proprietäre Anwendungen.
Die jeweiligen Open Source-Komponenten der Pentaho-Suite werden unter der GPL, EPL und LGPL veröffentlicht. Neben den erwähnten Lizenzen gibt es noch eine Vielzahl weiterer Modelle in diversen Spielarten.^[42]

5.3 Unternehmen und Produkt

Pentaho ist einer der führenden Anbieter von Open Source BI-Lösungen. Das Produktangebot des Unternehmens umfasst eine breite Sammlung an Werkzeugen für die unterschiedlichen Themengebiete des Business Intelligence. Hierunter fallen ETL, OLAP, Reporting, Data Mining und Dashboards.^[43]
Pentaho bietet die BI-Suite als Community und als kommerzielle Versionen an. Die Community Edition basiert auf Open Source. Die kommerziellen Versionen sind in der Basic, Professional und Enterprise Edition erhältlich. Mit einer kommerziellen Edition erwirbt man zusätzlichen Funktionsumfang und professionellen Support.^[44]

Tabelle 1: Pentaho Community & kommerzielle Editionen im Vergleich, in Anlehnung an Dietrich/Kagba 2011, S. 17

ETL	Community Edition	Basic Edition	Professional Edition	Enterprise Edition
Grafischer Designer	X	X	X	X
Konnektoren	X	X	X	X
Job Scheduler		X	X	X
Parallele Ausführung	X	X	X	X
Datenbrowser			X	X
Reporting & Dashboards	Community Edition	Basic Edition	Professional Edition	Enterprise Edition
Grundlegends Reporting	X	X	X	X
Grafischer Report-Designer	X	X	X	X
Interaktive Reports		X	X	X
Reiche Visualisierungen			X	X
Mobile-Unterstützung			X	X
Reporting-API	X	X	X	X
Dashboard-Designer		X	X	X
Analyse	Community Edition	Basic Edition	Professional Edition	Enterprise Edition
Ad-hoc-Analyse		X	X	X
OLAP			X	X
Data Mining	X			X
Enterprise	Community Edition	Basic Edition	Professional Edition	Enterprise Edition
Security-Integration	X	X	X	X
Zentrale Administration	X	X	X	X

Die Kunden der Software sind Unternehmen unterschiedlicher Größe und aus unterschiedlichen Branchen.^[45] Zu dem Kundenkreis zählt OTTO International, Brussels Airport, Mainzer Volksbank eG und Swissport.^[46]

5.4 Markübersicht

Nach einer Gartner Studie aus dem Jahr 2010 entfielen 2009 zweidrittel des Anteils am Markt für BI-Lösungen auf Anbieter, die zu den Großkonzernen der IT-Branche zählen. Hier sind u.a. Oracle, IBM, Microsoft und SAP zu nennen. Reine BI-Anbieter erfreuen sich einer wachsenden Beliebtheit beim Kunden. Innovative Technologien und eine schnellere Einführungszeit werden hierfür angeführt. Open Source-Lösungen stellen bei noch geringer Marktpräsenz eine günstige Alternative dar. Die größten Anbieter für Open Source BI-Lösungen sind JasperSoft und Pentaho.^[47]
Auf dem nationalen Markt ist Jedox mit seinem Produkt Palo laut einer Studie von BARC aus 2009 mit einem Marktanteile von 0,1% das verbreitetste Open Source BI-Produkt.^[48]

Jaspersoft
Die JasperSoft-BI-Suite ist modular aufgebaut.
Zu den Kernkomponenten zählen die Report-Engine JasperReports, der JasperReports Server, Jaspersoft OLAP und JaspersoftETL.^[49]

• Für die Anforderungen des Berichtswesens kommt die verbreitete Report-Engine JasperReports zum Einsatz.
• Der JasperReports Server integriert die verschiedenen Ressourcen und verfügt über Dashboards zur Darstellung der Ergebnisse.
• JasperSoft OLAP basiert auf der selben ROLAP-Engine „Mondrian“^[50] wie Pentaho Analysis.
• Zur Definition des ETL-Prozesses bietet JasperETL eine graphische Benutzeroberfläche und unterstützt diverse Schnittstellen.

Jedox
Die Jedox AG bietet mit Palo eine Lösung im Bereich Business Intelligence. Das Angebot umfasst OLAP- und ETL-Werkzeuge.^[51]

• Mit Palo OLAP legt der Hersteller ein auf Performanz ausgerichtetes Analyse-Werkzeug vor.
• Palo ETL unterstützt verschiedene Schnittstellen zur Befüllung der OLAP-Würfel. Hierunter fallen Konnektoren zu SAP.
• Palo Web integriert die BI-Funktionalitäten in einer Web-Oberfläche.

6 Analyse

6.1 Bewertungskriterien

Eine BI-Lösung stellt einen Produktionsfaktor dar und unterliegt damit einer Bewertung des Nutzens, den sie erbringt, und der Kosten, die sie verursacht.^[52]
Die Bewertung des Nutzens der BI-Lösung ist abhängig von der Qualität der Ergebnisse, die sie liefert. Für die Erfüllung dieser Aufgabe ist die Qualität der Software ausschlaggebend.^[53] Die Software soll daher unter Qualitätskriterien und dem Kostenaspekt betrachtet werden.

6.1.1 Qualitätsanforderungen

Für die Beurteilung von BI-Lösungen sind besonders die Kriterien Funktionsfähigkeit und Benutzungsfreundlichkeit relevant.^[54]
Neben dem reinen Funktionsumfang soll die Interoperabilität beurteilt werden. Unter Interoperabilität wird zum einen die reibungslose Zusammenarbeit der einzelnen Komponenten und zum anderen die Integration oder der Austausch von Komponenten verstanden. Letzteres ist bei der Verfolgung einer „best of breed“-Strategie bedeutsam. D.h. die Lösung wird aus Komponenten (von unterschiedlichen Herstellern), die am geeignetsten erscheinen, zusammengestellt. Voraussetzung hierfür ist eine entsprechend gestaltete Architektur der Software und Unterstützung geeigneter Schnittstellen.^[55]. Die Anforderung an den Funktionsumfang besteht zum einen in der grundsätzlichen Fähigkeit der Software, die behandelten Konzepte abbilden zu können. Zum anderen soll die Funktionsweise eine möglichst effiziente Umsetzung gewähren. Befördert wird dies durch eingängige und konsistente Mittel, die zur Herbeiführung der gewünschten Ergebnisse bereit stehen.
Der Bedienungskomfort ist hierbei differenziert zu gewichten. An die Bedienungsfreundlichkeit von Frontends für Anwender sind verständlicherweise höhere Maßstäbe anzulegen als an Entwicklungstools. Die beiden Werkzeugkategorien werden i.d.R. von unterschiedlichen Personengruppen genutzt, die über unterschiedliche EDV-Kenntnisse verfügen.

6.1.2 Kosten

Die Ermittlung des Nutzens von BI-Systemen gestaltet sich schwierig. Das System soll die Qualität von Entscheidungen verbessern. Bei der Untersuchung des Nutzens anderer EDV-Systeme kann z.B. die Zeiteinsparung durch Automatisierung dem Zeitaufwand einer manuellen Bearbeitung gegenübergestellt werden. Durch die Komplexität des Prozesses der Entscheidungsfindung lässt sich der damit verbundene Aufwand und die Optimierung durch BI-Lösungen nicht ohne Schwierigkeiten quantifizieren. Die Kostenseite, die mit Einführung und Betrieb der BI-Lösung verbunden ist, lässt sich hingegen relativ leicht Wertmäßig ausdrücken.^[56]
Die Kosten gliedern sich einerseits in einmalige und laufende Kosten und andererseits in Kapitalkosten und Betriebskosten. Die Kapitalkosten fallen durch Anschaffung von Aktiva an, d.h. im vorliegenden Fall die Investition in Software-Lizenzen und Hardware. Die Betriebskosten beziehen sich vorrangig auf den Personaleinsatz für Entwicklung und Wartung der Lösung.^[57]. Hieraus ergibt sich eine Matrix zur Klassifizierung der Kostenarten.

Tabelle 2: Klassifizierung der Kostenarten, in Anlehnung an Inmon 2000, S. 3

	laufende Kosten	einmalige Kosten
Kapitalkosten	Wartung, Pflege Hard- und Software	Anschaffung Hard- und Software
Betriebskosten	Laufende Aktualisierung, Pflege Datenmodell/Metadaten	Datenmodellierung, Implementierung ETL

Inmon empfiehlt ein iteratives Verfahren zur Entwicklung des Systems. Die hohen initialen Kosten bei Einführung des Systems stehen einer sinkenden Kostenentwicklung für jeden weiteren Entwicklungsdurchlauf gegenüber (economy of scale). Ebenso sinken mit der Zeit durch einen Lernkurveneffekt die Kosten für Wartung und Betrieb.^[58]
Die Untersuchung soll sich auf die Kosten für den Erwerb sowie Betriebskosten im Zusammenhang mit der Wartung der BI-Lösung beschränken. Hierbei wird einerseits der Unterschied zwischen Community und kommerzieller Edition betrachtet und andererseits das Angebot im Vergleich zur Konkurrenz.

6.2 Softwaretest

Die Bewertung des Systems erfolgt anhand einer Simulation. Die Untersuchung umfasst den Aufbau einer Datenbank, die ein ERP-System darstellen soll (operatives System), und die Überführung der Daten in eine für die Analyse optimierte Struktur (Data Warehouse). Der ETL-Prozess soll mit den von Pentaho bereitgestellten Mitteln erfolgen (Pentaho Data Integration). Die aufbereiteten Daten dienen als Basis für die weitere Untersuchung der Analyse- und Reporting-Konzepte des Systems.
Zur Entwicklung und Durchführung des Tests kommt MySQL als Datenbanksystem zum Einsatz. Genutzt wird die Community Edition der Datenbank, die in dem Produkt-Bundle „MySQL Installer 5.5“ enthalten ist. Die Datenmodellierung erfolgt mit Hilfe von „MySQL Workbench 5.2 GA“^[59]. Für den Test wurde auf die Komponenten der Community Edition von Pentaho zurückgegriffen.

• Version „Pentaho Data Integration Stable Release 4.2.0“
  • Lizenz LGPL
  • Hervorgegangen aus Kettle-Projekt
• Schema Workbench 3.2.2 (Lizenz EPL)
• Pentaho BI Server CE 3.7.0
  • Lizenz BI Platform GPL^[60]
  • integriert Mondrian, JPivot und Report-Engine
• Design Studio CE 4.0
  • Lizenz BI Platform GPL
  • Eclipse Plugin^[61]
• Pentaho Report Designer 3.8.2 (Lizenz LGPL)
• Pentaho Metadata Editor 4.0.0 (Lizenz LGPL)
• Weka Workbench 3.5.6 (Lizenz GPL)

Die verwendeten Komponenten stehen über die Internetseite der Pentaho Community^[62] zum Download bereit.
Wenn die kommerzielle Version zu der verwendeten Community Edition Unterschiede aufweist, werden diese in den jeweiligen Abschnitten diskutiert. Die Komponenten, die exklusiv den Anwendern der kommerziellen Version zur Verfügung stehen, werden jedoch keinem separaten Test unterzogen.

6.3 Testszenario

In dem Testszenario ist das operative System als Vermögensverwaltung angelegt, aus dem die Daten extrahiert und in das Data Warehouse überführt werden. Die Testdaten sollen eine möglichst praxisnahe Grundlage für BI-Analysen bieten. Dies bezieht sich zum einen auf das Datenvolumen und zum anderen auf die Datenmodellierung.

Das in dem Beispiel zu verwaltende Vermögensportfolio setzt sich aus den 30 DAX Titeln (Stand 26.11.2011) zusammen. Auf Grundlage der historischen Kurse der Aktien werden Kauf und Verkaufstransaktionen (order_tab) in zufälliger Stückzahl und zu einem zufälligen Kursdatum generiert. Die Kursdaten werden von Yahoo Finanzen^[63] bezogen. Die zufälligen Transaktionen werden auf generierten, separaten Konten (wp_konten) geführt. Die Verkäufe, die zu einem Bestand kleiner 0 führen, werden reduziert oder eliminiert. Den Konten ist ein Betreuer (account_manager) zugeordnet, um eine weitere Auswertungsebene zu schaffen. Um die Testdaten einerseits realistisch und andererseits nicht zu komplex zu gestalten, werden bestimmte Annahmen getroffen.

• Es existiert maximal nur ein Kurs pro Aktie und Tag
• An einem Tag kann nur eine Kauf und/oder Verkaufstransaktion einer Aktie auf einem Konto stattfinden.
• Wenn auf einem Konto ein Kauf und ein Verkauf einer bestimmten Aktie am selben Tag erfolgt, findet der Kauf vor dem Verkauf statt.

Eine Order zieht einen Buchungssatz nach sich. Der Kauf stellt einen Zugang und der Verkauf einen Abgang in Höhe der Anschaffungskosten dar. Beim Verkauf kann die Differenz zwischen Anschaffungskosten und Verkaufserlös direkt als Aufwand oder Ertrag zum Zeitpunkt des Anfalls verbucht werden^[64]. Die Rechenregeln zur Ermittlung der Buchungsbeträge ergeben sich dann aus den generierten Werten der Order.

• Zugehender Buchwert = Stück * Preis
• Abgehender Buchwert = Vortrag Buchwert / Vortrag Stück * zu verkaufende Stück
• Aufwand oder Ertrag = abgehender Buchwert - Verkaufserlös (Stück * Preis)

Der Aufbau des Testsystems wurde mit Hilfe von SQL-Skripten und Pentaho Data Integration (PDI) Transformationen realisert.

Tabelle 3: Zusammenstellung Testdaten

Tabelle	Anzahl Datensätze	Datenquelle	Technische Realisierung
kurse	66.199	Historische DAX Kurse als CSV-Dateien von Yahoo Finanzen	Import per PDI-Transformation
order_tab	64.688	Tabelle "kurse"	Generierung per SQL-Skript
stocks	30	Manuell erstellte CSV-Datei; Informationsquelle Yahoo Finanzen	Import per PDI-Transformation
wp_buchungen	64.688	Tabelle "order_tab"	Generierung per PDI-Transformation
wp_konten	42	Tabelle "order_tab"	Generierung mit fixer Anzahl per SQL-Skript
account_manager	5	Tabelle "wp_konten"	Per SQL-Insert-Statements mit fiktiven Namen; Fixe Referenz zu Konten

6.4 Pentaho Data Integration

Das Werkzeug „Pentaho Data Integration“ (PDI) ist für die Implementierung des ETL-Prozesses vorgesehen.
Grundlegendes Gestaltungselement des Werkzeugs ist eine Transformation. Die Transformation wird in einer Datei im XML-Format gespeichert. Das Design erfolgt über eine graphische Oberfläche (Spoon).
Die Transformation wird als Abfolge von Prozessschritten (sog. Steps) aufgebaut. Die Steps stehen in einer Baumstruktur zur Auswahl. Per Drag and Drop wird ein Step in die Transformation aufgenommen. Durch Doppelklick können die Eigenschaften des Steps aufgerufen und konfiguriert werden. Der Ablauffluss des Transformationsprozesses ergibt sich über die Verbindung der Steps durch sog. Hops.
Die Transformationsdateien können entweder direkt ausgeführt werden oder über einen Ablaufplan (sog. Jobs) zu einer sequentiellen Ausführung verkettet werden^[65].

6.4.1 Funktionsumfang

Als Datenquelle (Input) und Datenausgabe (Output) stehen unterschiedliche Steps zur Verfügung, die u.a. Datenbanken und verschiedene Dateiformate (z.B. CSV, Excel, XML, Dateien mit fester Satzlänge) unterstützen.

Die Filterung der Daten kann entweder direkt über SQL-Abfragen, wenn eine Datenbank als Datenquelle zum Einsatz kommt, oder über einen Step „filter rows“ vorgenommen werden. Für die Aggregation („Group by“) und die Anreicherung von Daten mit berechneten Werten („Calculator“) stehen ebenfalls Verarbeitungsschritte zur Verfügung.
Mit dem Step „Dimension lookup/update“ vereinfacht das Tool die Transformation in eine Zielstruktur, der ein dimensionales Modell zugrunde liegt. Das Aktualisierungsverhalten für eine Dimension kann so konfiguriert werden, dass geänderte Werte zum Einfügen einer neuen Zeile in die Dimensionstabelle und nicht zum Überschreiben bestehender Inhalte führen. Die Gültigkeit der bestehenden Zeile in der Dimensionstabelle wird über einen entsprechenden Zeitstempel beendet.
Das gewählte Testbeispiel lässt sich mit dem Werkzeug realisieren. Für komplexere Problemstellungen sind jedoch genauere Kenntnisse der zugrundeliegenden Konzepte von Nöten. Ohne professionellen Support, der nur Anwendern der kommerziellen Edition zur Verfügung steht, bleibt die Frage offen, ob der technisch günstigste Ansatz zur Problemlösung gewählt wurde. In dem Testbeispiel muss für die Buchungstabelle der Aufwand bzw. Ertrag ermittelt werden, der aus einem Verkauf resultiert^[66]. Der Aufwand bzw. Ertrag ergibt sich als Differenz aus dem Buchwert des Aktienbestandes und dem Verkaufserlös. Der Buchwert ist die Differenz aus zu- und abgehendem Buchwert. Die abgehenden Buchwerte vorheriger Verkäufe müssen bereits um den Aufwand erhöht bzw. den Ertrag verringert sein. Das zu lösende Problem lässt sich abstrakt formulieren als Aggregation von berechneten Feldern, wobei die Berechnung auf der Aggregation der vorherigen Zeilen beruht. Die Logik wäre in der Praxis im operativen System abgebildet. In dem Testbeispiel übernimmt diese Aufgabe das ETL-Werkzeug. Die Problemstellung ist nach eingehender Untersuchung mit den vorgefertigten Prozessschritten nicht umsetzbar. Die Verarbeitung der einzelnen Prozessschritte erfolgt asynchron^[67]. D.h. jeder Prozessschritt verarbeitet nur eine begrenzte Anzahl an Daten und nicht zwangsweise die gesamte Datenmenge bevor die Ergebnisse an den nächsten Step weitergereicht werden. Der Prozess des ersten Steps läuft unterdessen weiter bis das Ende des Datenstroms oder eine bestimmte Cache-Größe erreicht ist. Der zweite Step liest den Cache, der von dem ersten Step gefüllt wird und blockiert ggf. den ersten Step, wenn die bereitgestellten Daten nicht schnell genug verarbeitet werden können. Die in einem vorgelagerten Schritt durchgeführte Aggregation eines Felds bis zu der aktuell verarbeiteten Zeile in einem nachgelagerten Prozess ist somit nicht konsistent. Für derartige Fälle bietet sich die Verwendung des Steps „User Defined Java Class“ an. Hier kann Java-Sourcecode eingebunden werden, der zur Laufzeit kompiliert und ausgeführt wird. Über Instanzvariablen kann die gewünschte Aggregation abgebildet werden. Die Verwendung von eingebettetem Sourcecode verringert jedoch den Effekt, dass die Implementierung der Transformation von Entwicklern ohne Kenntnisse der spezifischen Programmiersprache gewartet oder erweitert werden kann.
Allgemein kann jedoch gesagt werden, dass durch die parallele Verarbeitung von einem positiven Effekt auf die Skalierbarkeit des Systems auszugehen ist.

6.4.2 Bedienungsfreundlichkeit

Die Verwendung der einzelnen Steps gestaltet sich weitestgehend intuitiv. Soll ein weiterer Prozessschritt zwischen zwei Steps eingefügt werden, so ist es möglich den einzufügenden Prozessschritt auf die Verbindungslinie (Hop) zwischen die bestehenden Schritte per Maus zu ziehen. Das Werkzeug fragt dann, ob der Step an dieser Stelle eingefügt werden soll.
Benötigt man Hilfe zu den Schritten, muss das Wiki der Pentaho community^[68] durchsucht werden. Hier ist eine Sammlung der Step-Beschreibungen verfügbar. Eine integrierte Online-Hilfe fehlt.
Teilweise fehlen hilfreiche Prüfungen oder Warnungen. Die Suche nach Fehlern gestaltet sich so unnötig langwierig. Bei der Konfiguration eines Table-Outputs kann z.B. ein Mapping zwischen Quellfeldern und Tabellenattributen angegeben werden. Es muss allerdings explizit eine Option „specify databse fields“ aktiviert werden, damit das definierte Mapping berücksichtigt wird. Die Verarbeitung bricht in dem Fall mit einem Fehler ab, der keinen direkten Rückschluss auf die Fehlerursache zulässt. Es wird lediglich ein Datenbankfehler durchgereicht, dass ein Pflichtfeld mit „null“ angegeben ist.
Weitere Sorgfalt ist bei der Definition einer Zuordnung zwischen Quell- und Zielfeldern hinsichtlich des Typs geboten. Wenn der Typ des Quellfeldes inkompatibel zu dem des Zielfeldes ist, bricht die Verarbeitung mit einer Fehlermeldung ab, das Quellfeld existiere nicht. Fehlerursache ist jedoch die nicht zulässige Konvertierung der Datentypen.
In den Eigenschaften der Steps müssen an unterschiedlichen Stellen Quell- oder Zielfelder ausgewählt werden. Die Felder können i.d.R. über eine Dropdown-Liste ausgewählt werden. Dieses Feature ist nicht durchgängig verfügbar. Bei manchen Kontext-Eigenschaften (z.B. „row denormaliser“) steht keine Auswahl der Felder zur Verfügung.

6.4.3 Interoperabilität

Das Werkzeug ist in Java implementiert. Die Anbindung der gängigen (relationalen) Datenbanksysteme ist durch die Verwendung der JDBC-Schnittstelle möglich. Des Weiteren existiert mit den Steps „Palo Cell Input“ und „Palo Cell Output“ eine Schnittstelle zu dem Datenbanksystem eines Mitbewerbers.
Als Ergebnis des ETL-Prozesses liegen aktualisierte dispositive Datenbanktabellen vor. Die Datenbanktabellen stellen eine Schnittstelle für weitere Analysevorhaben dar. Ein potenzieller Austausch des ETL-Werkzeugs oder die Integration in eine andere BI-Lösung, welche auf die bereitgestellten Daten aufsetzt, ist somit denkbar.
Als weitere Option bietet sich die Integration in andere Software über die Java-API^[69] an. Durch die Veröffentlichung unter der LGPL besteht überdies die Möglichkeit der Einbindung in proprietäre Software.

6.5 BI Server und Dashboard

Abweichend von dem Schema für die Bewertung der anderen Komponenten soll in diesem Abschnitt neben dem Funktionsumfang der Fokus auf der Wartungsfreundlichkeit liegen. Die anfallenden administrativen Aufgaben, die mit Einrichtung und Betrieb des Systems verbunden sind, erstrecken sich über die Integration der verschiedenen Ressourcen in das Serversystem.

6.5.1 Funktionsumfang

Die Server-Komponenten bestehen aus BI Server und Administration Console.^[70] Beide Server werden separat gestartet. Die Verwaltung von Benutzern, ihren Rollen und Datenbankverbindungen erfolgt über die Administration Console. Hierzu stehen entsprechende graphische Oberflächen zur Verfügung.
Ein authentifizierter Benutzer gelangt über die Oberfläche des BI Servers auf sein Dashboard. Über die Oberfläche bindet der Benutzer neue Datenquellen (Data Source) ein und kann neue OLAP-Analysen sowie Reports erzeugen. Neben diesen Möglichkeiten können über Skripte (sog. xactions) Reports und OLAP-Analysen direkt in das Dashboard integriert werden. Die Entwicklung der Skripte erfolgt über ein Client-Werkzeug, das Design Studio. In der Community Edition kann der Anwender sein Dashboard nicht selbstständig anpassen. Die Option der benutzerfreundlichen Gestaltung des Dashboards steht nur in den kommerziellen Editionen zur Verfügung.^[71]

6.5.2 Wartungsfreundlichkeit

Dem BI Server liegt der verbreitete Apache Tomcat Server zugrunde.^[72] Die Konfiguration von Tomcat als auch des BI Servers erstreckt sich über mehrere Schritte. Bei der Verwendung alternativer Plugins für die Darstellung von OLAP-Analysen (vgl. Kapitel „OLAP mit Pentaho Analysis“) müssen die Datenquellen direkt in das entsprechende Konfigurationsskript eingetragen werden.^[73]
Die Definition der Datenquellen für Reports und OLAP-Analysen erfolgt über Entwicklerwerkzeuge. Die Datenquellen müssen dann in den BI Server eingebunden werden. Dies kann entweder über die Wahl des Speicherorts der Datenquellenbeschreibungen oder die Veröffentlichungsfunktion (Publish) erfolgen. Die Veröffentlichungsfunktion stellt einen Remote-Zugriff auf das Serversystem bereit. Der Zugriff erfolgt als authentifizierter Benutzer des BI Servers mit einem separaten Publishing-Passwort, das in der Konfiguration des Servers angegeben werden muss. Diese Lösung konnte nach eingehender Untersuchung und Konsultation der Dokumentation nicht realisiert werden.
Durch die Verwendung der Community Edition kann man nicht auf den professionellen Support zurückgreifen. Für Betrieb und Einrichtung des Servers muss also ein entsprechender administrativer Aufwand einkalkuliert werden, der durch Verwendung der kommerziellen Edition geringer einzuschätzen ist.

6.6 OLAP mit Pentaho Analysis

Voraussetzung für den Betrieb von OLAP ist die Definition eines Cube-Schemas. Hierbei handelt es sich um Metadaten, die im XML-Format gespeichert werden. Die Definition erfolgt entweder direkt in einem Texteditor oder über eine grafische Oberfläche, die sog. „Schema Workbench“. Die ROLAP-Engine (Relational OLAP) „Mondrian“ führt die Aggregation der Daten des spezifizierten Würfels durch. Der Benutzer stellt die Analyse-Anfragen mittels eines Frontends, das die Anfrage übersetzt, an die OLAP-Engine weiterreicht und die Ergebnisse visualisiert. Mondrian nimmt die Anfragen in MDX-Syntax entgegen^[74].
Die Spezifikation von MDX (Multidimensional Expression) geht auf die Firma Microsoft zurück. Der Sprachumfang ist in dem Konzept „OLE-DB for OLAP“ beschrieben. Die MDX-Syntax lehnt sich an die Sprachmittel von SQL an und dient der Abfrage von multidimensionalen Strukturen. So sind die Projektionen der Abfragemenge den Achsen eines Würfels zugeordnet. Das Ergebnis der Abfrage kann als Kreuztabelle dargestellt werden. MDX hat sich durch die weite Verbreitung als de facto-Standard etabliert^[75].
Das OLAP-Frontend ist als Web-Anwendung in den BI-Server integriert. Als Frontends der Community und kommerziellen Edition kommen unterschiedliche Softwarekomponenten zum Einsatz. Die Community Edition verwendet „JPivot“. Wohingegen „Clearview“ in der kommerziellen Edition „JPivot“ abgelöst hat^[76]. Die Software steht nicht unter Open Source-Lizenz^[77].
Die Werkzeuge lassen sich in die zwei Kategorien Entwickler-Werkzeuge und Anwender- bzw. Server-Anwendungen einteilen. Zu den Client-Werkzeugen gehört noch der Aggregate Designer^[78], der eine Performance-Steigerung bei Abfragen verspricht. Das Werkzeug wurde jedoch nicht weiter untersucht.

6.6.1 Funktionsumfang

Die Elemente der Cube-Definition sind „Dimension“, „Hierarchy“, „Levels“ und „Measures“. Die Attribute der Dimensionen stellen Levels dar. Die Levels können als hierarchische Struktur (Hierarchy) organisiert werden. Die Measures sind die zu aggregierenden Werte.^[79]. Das Mapping zwischen zugrundeliegender Datenstruktur und OLAP-Cube gestaltet sich einfacher, wenn ein dimensionales Modell gewählt wurde. Der Cube-Dimension ist dann direkt eine Datenbanktabelle zugeordnet. Die Faktentabelle liefert die zu aggregierenden Werte (Measures). Zum Betrieb der Schema Workbench muss eine Verbindung über JDBC mit der zugrundeliegenden Datenbank hergestellt werden.
Das in die Workbench integrierte MDX-Abfrage-Werkzeug kann als erster Test der Definition des Würfels dienen. Es erfolgt zunächst eine syntaktische Prüfung des erstellten Cube-Schemas. Die Abfrage selbst muss dann als Texteingabe vorgenommen werden. Durch fehlende Autovervollständigung und die reine Textausgabe der Ergebnisse ist das Tool für weitere Analysezwecke nicht geeignet.

Die OLAP-Analyse aufgrund des definierten Würfels erfolgt über den BI-Server. In der Community Edition gelangt das Analyse-Frontend JPivot zum Einsatz. Neben der Visualisierung als OLAP-Cube kann das Ergebnis als Chart dargestellt werden (Balken-, Kreisdiagramme u.a.). Die Ergebnissen können nach Excel exportiert werden.

Die Attribute einer Dimension werden grundsätzlich hierarchisch aufgebaut, auch wenn dies durch die Schema-Beschreibung nicht vorgesehen ist. Die Aggregationsebenen der Ergebnismatrix können geöffnet werden (Drilldown). Es erscheinen dann die Ausprägungen des Attributs der Dimension. Unterhalb der Attributwerte kann das nächste Attribut mit seinen Ausprägungen betrachtet werden. Da die Abhängigkeiten der Attribute der Dimension nicht zwangsweise hierarchisch sind, ist die Aggregation ggf. identisch zu der vermeintlichen nächsthöheren Ebene. Das Problem ist in den Konfigurationsmöglichkeiten begründet. Die Konfigurationsmöglichkeiten sehen lediglich vor Dimensionen und nicht einzelne Attribute auf die Achsen zu legen. Die Attribute und Werte der Dimensionen können nur gefiltert werden. Eine beliebige Bildung von Schnittpunkten zwischen Attributen (Dicing) ist dann nur sehr unkomfortabel (durch Filterung der auszublendenden Werte und Attribute) oder gar nicht möglich.
In dem Testbeispiel soll die Ertragsentwicklung je Quartal des laufenden Jahres nach den Account-Managern erfolgen. Das Quartal ist ein Attribut der Time-Dimension. Der Manager ist ein Attribut der Account-Dimension. Die Account-Dimension wird jedoch fest vorgegeben vom System durch das zuerst definierte Attribut der Dimension dargestellt. In diesem Fall die Kontobezeichnung. Um das gewünschte Ergebnis komfortabler zu erreichen, muss die Schema-Definition so angepasst werden, dass der Würfel um eine virtuelle Dimension „Manager“ erweitert wird. Die Schwächen des Systems wurden von Pentaho erkannt. Der Austausch des Frontends ist zumindest für die kommerzielle Version der Software vollzogen. Als Nachfolger von JPivot in der Community Edition bietet sich das Open Source Projekt Saiku Analytics an, das bereits auf der Community Homepage verlinkt ist^[80]. Saiku kann als Plugin in den Pentaho BI-Server integriert werden^[81]. Neben der klassischen steht dann die Analyse-Sicht von Saiku zur Verfügung. Die Integration des Frontends ist noch nicht abgeschlossen. Die Ansteuerung der Visualisierung per xaction kann z.B. noch nicht vorgenommen werden^[82]. Die Achsen der Kreuztabelle können mit beliebigen Attributen der Dimensionen belegt werden (Dicing). Es ergeben sich so beliebige Schnittpunkte zwischen den Attributen. Die Software ist jedoch in einem Reifegrad, der einen Produktionseinsatz fraglich erscheinen lässt. Der Funktionsumfang entspricht noch nicht dem von JPivot. Es fehlt z.B. die Möglichkeit das Ergebnis als Chart darzustellen. Die Navigation durch den Cube (Drilldown, Rollup) ist nur durch Hinzufügen bzw. Entfernen einer Aggregationszeile oder eines weiteren Attributs per Drag and Drop realisiert. Die weitere Entwicklung der Software und die strategischen Entscheidungen des Unternehmens Pentaho, inwieweit eine adäquate OLAP-Lösung in der Community Edition notwendig erscheint, bleiben abzuwarten.

6.6.2 Bedienungsfreundlichkeit

Der „Schema Editor“ stellt die Cube-Definition in einer Baumstruktur dar. Die Konfiguration der einzelnen Elemente erfolgt durch Auswahl eines Knotens aus der Baumstruktur. Datenbanktabellen und Attribute können durch Dropdown-Listen in den Eigenschaften der Elemente gesetzt werden. Eine integrierte Online-Hilfe fehlt. Hilfe zu der Bedienung erhält man in dem Wiki der Community.

Mit JPivot gestaltet sich die Zusammenstellung des Würfels durch fehlendes Drag and Drop nicht durchgängig intuitiv. Zur Gestaltung der Analyse muss eine separate Konfigurationsbox (OLAP Navigator) eingeblendet werden. Über den OLAP Navigator werden die Dimensionen auf Zeilen und Spalten verteilt. Die Definition der Achsen, die Auswahl der zu aggregierenden Kennzahlen und Filterbedingungen stellen die Grundlage der Visualisierung dar. Nach Bestätigung der Konfiguration wird die Abfrage ausgeführt und das Ergebnis als Kreuztabelle angezeigt. Das Ein- und Ausblenden des Navigators sowie die explizite Bestätigung der Konfiguration trägt nicht zu einer intuitiven Bedienung bei.

Optisch präsentiert sich das Frontend Saiku wesentlich ansprechender als JPivot. Die Attribute einer Dimension können per Drag and Drop auf die Achsen (Columns, Rows) des Würfels gezogen werden.

6.6.3 Interoperabilität

Die Mondrian-Engine unterstützt neben der MDX-Syntax ebenfalls Anfragen über HTTP und fungiert so als Webservice.^[83] Dies erleichtert den Austausch der Client- bzw. Server-Komponenten.
Die Integration in den BI-Server erfolgt über die Metadaten-Definition. Die Metadaten können entweder als Datenquelle oder direkt in das Dashboard eingebunden werden. Die Datenquelle ist Grundlage für die Erzeugung neuer Berichte. Der Benutzer muss diesen Vorgang aktiv initiieren und die Cube-Datenquelle für seine Analyse aus einer Dropdown-Liste auswählen.

6.7 Pentaho Reporting

Für die Gestaltung von Berichten steht zum einen der „Report Designer“ und zum anderen ein Werkzeug zur Gestaltung von Ad-Hoc-Berichten zur Verfügung.^[84] Die Generierung des Reports wird in beiden Fällen über den BI Server zur Ausführung gebracht. In einer rudimentären Integration in das Dashboard wird der Bericht in einem entsprechenden Verzeichnis des Serversystems abgelegt.
Als Datenquelle des Berichts empfiehlt sich die Verwendung von Metadaten.^[85] Das Reporting-System verarbeitet die Metadaten in einem speziellen XML-Format. Die Definition erfolgt über den Pentaho Metadata Editor. Die Metadaten können als Datenquelle im BI Server publiziert werden und dienen dann als Grundlage für Ad-Hoc-Berichte. Die Metadaten definieren die zugrunde liegenden Tabellen mit ihren Attributen und Schlüsselverbindungen.

6.7.1 Funktionsumfang

Mit Hilfe des Report Designers können Schablonen für Standardberichte erzeugt werden. Als Datenquelle stehen Datenbankabfragen, die Pentaho Metadaten und Cube-Definitionen zur Verfügung. Aufgrund der Datenquelle lässt sich eine Abfrage der Daten formulieren, die dann als Basis des Berichts fungiert. Die Datenfelder können pixelgenau in den unterschiedlichen Bereichen des Reports ausgerichtet werden. Über Ausdrücke lassen sich berechnete Werte abbilden. Der Report kann nach unterschiedlichen Attributen gruppiert werden. Aufgrund der Gruppierung lassen sich Summierungen bilden. Der Report Designer deckt somit die grundlegenden technischen Anforderungen an die Erstellung einer Berichtsschablone ab. In dem Testbeispiel sollen Werte aus der Faktentabelle aggregiert nach bestimmten Attributen der Dimension abgebildet werden. Die Gruppen enthalten Summierungen der einzelnen Aggregationen. Das Beispiel konnte mit den Mitteln des Werkzeugs realisert werden.
Die Berichte können in unterschiedlichen Ausgabeformaten generiert werden. Zur Auswahl stehen u.a. PDF, HTML und Excel.
Nach Bekanntgabe der Metadaten im BI Server besteht die Möglichkeit einen Ad-Hoc-Bericht über das Web-Frontend zu erstellen. Das Werkzeug erlaubt die Auswahl eines Standard-Layouts und der Attribute, die durch die Metadaten zur Verfügung stehen. Das Vorgehen entspricht weitestgehend dem im nächsten Abschnitt vorgestellten Wizard-Modus.
Durch die Erreichbarkeit über das Dashboard, die Bereitstellung vorgefertigter Layouts und die Auswahl der Datenattribute ist die Verwendung für versierte Anwender geeignet.

6.7.2 Bedienungsfreundlichkeit

Der Report Desinger bietet einen Wizard-Modus. In diesem Modus erfolgt eine geführte Auswahl eines Standard-Layouts und der zugrundeliegenden Datenquelle. Die Abfrage der Daten lässt sich komfortabel gestalten, wenn als Datenquelle die Pentaho Metadaten zum Einsatz kommen. Der Entwickler des Reports kann dann per Drag and Drop die Attribute der Datenquelle aus einer Baumstruktur in den Report einbinden. Die Metadaten-Definition sieht für Attribute eine Standard-Aggregation vor, die sich für die Felder der Faktentabelle anbietet. Bei der Gestaltung des Berichts sind allerdings die Aggregationsregeln erneut vorzugeben.

6.7.3 Interoperabilität

Das Zusammenspiel der Komponenten erleidet durch die unterschiedlichen Metadaten-Definitionen für OLAP-Analyse einerseits (Cube-Schema) und Reporting andererseits (Pentaho Metadaten) einen Bruch. Hier sind entweder Maßnahmen zur Konvertierung, der Verzicht auf Funktionalität oder die Führung unterschiedlicher Datenquellen in Kauf zu nehmen. Die Integration des Berichts ließ sich nur über die rudimentäre Ablage im Dateisystem realisieren. In diesem Zusammenhang sei noch einmal auf die Komplexität, die sich aus der Integration der einzelnen Ressourcen ergibt, verwiesen und den daraus resultierenden administrativen Aufwand.

6.8 Pentaho Data Mining

Die Entwicklung des Data Mining-Werkzeugs Weka geht auf die Universität von Waikato in Neu Seeland zurück. Die Entwicklung startete 1993 und seit Version 3 liegt die Implementierung in Java vor. Die Weka Workbench besteht aus einer Werkzeug Sammlung die eine Anwendung der zugrundeliegenden Methoden auf Datenquellen erlaubt.^[86]
Eine Unterteilung des Abschnitts nach den Qualitätskriterien entfällt wegen der Kürze der Darstellung.
Die Workbench enthält Werkzeuge zur Zusammenstellung der Daten und Methoden. Des Weiteren können die Ergebnisse dargestellt werden. Die Integration der Ergebnisse in den BI Server ist der kommerziellen Edition der Software vorbehalten.
Die Workbench unterstützt als Datenquelle die Ergebnisse von SQL-Abfragen und unterschiedliche Dateiformate.^[87] Weka enthält Methoden zu Klassifizierung (Classify), Clustering (Cluster) und Assoziation (Associate) (vgl. Abschnitt Data Mining in Grundlagen). Nach Einbindung der Datenquelle können über eine Vorverarbeitungsseite (Preprocess) Attribute gefiltert werden. Unter den anzuwendenden Methoden auf die Datenmenge stehen verschiedene Algorithmen zur Verfügung. Diese speisen sich vor allem aus den öffentlich verfügbaren Algorithmen, die aus der wissenschaftlichen Forschung entstanden sind.^[88]

Als Test wurde ein Entscheidungsbaum erzeugt, der durch das mitgelieferte Visualisierungswerkzeug zur Anzeige kam. Die Anzeige ist nur rudimentär. Die Navigation im Ergebnisbaum ist nur über Tastenkürzel möglich. Zur weiteren Analyse ist die Aufbereitung durch andere Komponenten notwendig. Diese Aufgabe verspricht die kommerzielle Version zu lösen.
Das durchgeführte Beispiel ist nicht geeignet, die zugrundeliegenden Methoden zu beurteilen. Die wissenschaftliche Fundierung des Systems legt jedoch eine gewisse Leistungsfähigkeit nahe.

6.9 Kosten für Einrichtung und Betrieb

Pentaho bietet die BI-Lösung in der Community Edition und in kommerziellen Versionen an. Für die Community Edition, die ausschließlich auf Open Source basiert, fallen keine Lizenz oder Wartungsgebühren an. Die kommerziellen Versionen weisen einen größeren Funktionsumfang auf und der Anwender erhält professionellen Support. Die kommerzielle Version ist mit einer jährlichen Subskriptionsgebühr verbunden (annual subscription).^[89].
Die Gebühr wird für den Support und die Benutzung der nicht unter Open Source stehenden Komponenten erhoben. Das Lizenzmodell der Anbieter proprietärer Produkte sieht i.d.R. eine initiale Zahlung für den Erwerb der Software und laufende Wartungskosten vor. Durch die geringeren Anschaffungskosten ergibt sich gegenüber proprietären Produkten somit ein Kostenvorteil zum Beginn des BI-Projekts. Hierdurch ist mit einem schnellerer Return on Investment (ROI) zurechnen.^[90]
Als weitere Option bietet sich der Start in ein BI Projekt mit der Community Edition an. Die sinkenden Kosten für den Betrieb der Software durch einsetzende Lernkurveneffekte können dann ein Upgrade auf eine kommerzielle Edition kompensieren. In diesem Zusammenhang sei auch auf die Interoperabilität des Systems durch die Verwendung von freien Schnittstellen hingewiesen, die den Austausch von Komponenten durch Produkte anderer Anbieter erleichtert.
Auf einen Vergleich von Subskriptionsgebühr mit den Wartungsgebühren proprietärer Anbieter soll verzichtet werden, da sich die Gestaltung der jeweiligen Preismodelle sehr intransparent gestaltet.^[91]
Einschränkend muss gesagt werden, dass die Anschaffungskosten nur einen geringen Teil der initialen Kosten ausmachen. Der größte Teil des Aufwands entsteht durch die Implementierung des Systems. Dem oben angeführten Kostenvorteil liegt die Annahme zugrunde, dass sich die Funktionsfähigkeit der Systeme entsprechen.^[92]

7 Fazit und Ausblick

Die Software bietet umfangreiche Funktionalitäten und deckt damit ein breites Spektrum des Anforderungskatalogs an BI-Lösungen ab. Die kommerzielle Version der Software verspricht Unzulänglichkeiten der Community Edition zu beheben. Das Optimierungspotenzial der kommerziellen Edition ist im Folgenden zusammengefasst.

• Der professionelle Support reduziert den Aufwand für Implementierung und Wartung.
• Als OLAP-Frontend kommt ein leistungsfähiges Werkzeug zum Einsatz.
• Die Gestaltung des Dashboards ist auch für Endanwender geeignet.
• Ergebnisse des Data Minings gelangen in eine benutzerfreundliche Darstellungsform.

Generell spricht für die Lösung, die Verwendung freier Schnittstellen, der Funktionsumfang und die Anschaffungskosten.

• Zum Funktionsumfang zählen Dashboards auf Basis von Web-Technologie, Reporting, OLAP, Data Mining, Metadaten und ein ETL-Werkzeug.
• Der Austausch von Komponenten ist durch einen modularen Aufbau erleichtert.
• Komponenten, die unter der LGPL stehen, können auch in proprietären Produkten über eine Java-API integriert werden.
• Es ergibt sich ein Kostenvorteil gegenüber proprietärer Software zum Beginn des Projekts durch Einsparung von Lizenzgebühren.

Schwächen des Systems sind im Zusammenspiel der einzelnen Werkzeuge und dem Funktionskomfort auszumachen.

• Als Grundlage für OLAP und Reporting empfehlen sich unterschiedliche Metadaten (Cube-Schema und Pentaho Metadaten).
• Komplexere ETL-Prozesse lassen sich ggf. nur durch Einbindung anderer Techniken realisieren.
• Die Entwicklerwerkzeuge sind teilweise sehr rudimentär und stehen nicht über eine integrierte Umgebung (IDE) zur Verfügung.

Zur Bestimmung des Nutzens für BI-Systeme bieten sich Verfahren an, die qualitative Merkmale in den Vordergrund stellen, da die Quantifizierung des Nutzens mit Problemen behaftet ist. Anhand einer Skala lässt sich dann eine Bewertung vornehmen, die der Erreichung einer Qualitätsanforderung Ausdruck verleiht.^[93] Die vorliegende Arbeit begnügt sich mit der Identifizierung von Stärken und Schwächen des Systems. Zur weiteren Evaluierung müsste die Software aufgrund gewichteter Kriterien mit anderen Produkten verglichen werden. Hierfür bieten sich die Produkte von JasperSoft und Jedox an, falls eine BI-Lösung auf Basis von Open Source in Betracht kommt.
Die Herausforderung, mit der sich Pentaho konfrontiert sieht, liegt in der Integration der aus unterschiedlichen Projekten stammenden Werkzeuge zu einem homogenen Gesamtsystem. Den Anbietern proprietärer Systeme sollte durch die Entwicklung aus einer Hand die Vereinheitlichung der Komponenten leichter fallen. Ein Alleinstellungsmerkmal gegenüber anderen Anbietern von Open Source BI besteht in dem gebotenen Funktionsumfang. Dieser Wettbewerbsvorteil kann sich durch eine konsequente Integration der Komponenten verstärken. Fraglich ist jedoch, ob diese Entwicklungen unter Open Source-Lizenzen veröffentlicht werden.

8 Fußnoten

1. ↑ Vgl. Sallam 2010
2. ↑ Vgl. Sallam 2010
3. ↑ Vgl. Kemper 2009, S. 9f
4. ↑ Vgl. Gluchowski/Kemper 2006, S. 12f
5. ↑ Vgl. Kemper 2009, S. 1f
6. ↑ http://www.bwi.uni-stuttgart.de/index.php?id=1635
7. ↑ Vgl. Gluchowski/Kemper 2006, S. 14-16
8. ↑ Vgl. Gluchowski/Kemper 2006, S. 14-16
9. ↑ Vgl. Kemper 2009, S. 89f
10. ↑ Vgl. Kemper 2009, S. 47
11. ↑ Vgl. Kemper 2009, S. 152f
12. ↑ Vgl. Gluchowski/Gabriel 2007, S. 214f
13. ↑ Vgl. Bauer/Günzel 2009, S. 8
14. ↑ Vgl. Bauer/Günzel 2009, S. 8f
15. ↑ Vgl. Kemper 2009, S. 21
16. ↑ Vgl. Kemper 2009, S. 22-24
17. ↑ Vgl. Kimball 2008, S. 235
18. ↑ Vgl. Kimball 2008, S. 235-238
19. ↑ Vgl. Kimball 2008, S. 235-238
20. ↑ Vgl. Kemper 2009, S. 69f
21. ↑ Vgl. Kimball 2008, S. 235-238
22. ↑ Vgl. Analyse_der_BI-Lösung_von_Pentaho#OLAP
23. ↑ Vgl. Gluchowski/Gabriel 2007, S. 143
24. ↑ Vgl. Gluchowski/Gabriel 2007, S. 143f
25. ↑ Vgl. Codd 1993
26. ↑ Vgl. Gluchowski/Gabriel 2007, S. 147
27. ↑ Vgl. Kemper 2009, S. 104f
28. ↑ Vgl. Haneke 2010, S. 122f
29. ↑ Vgl. Kemper 2009, S. 113-115
30. ↑ Vgl. Gluchowski/Gabriel 2007, S. 191
31. ↑ Vgl. Gluchowski/Gabriel 2007, S. 194
32. ↑ Vgl. Gluchowski/Gabriel 2007, S. 195
33. ↑ Vgl. Gluchowski/Gabriel 2007, S. 196f
34. ↑ Vgl. Gluchowski/Gabriel 2007, S. 197f
35. ↑ Vgl. Gluchowski/Gabriel 2007, S. 198-201
36. ↑ Vgl. Gluchowski/Gabriel 2007, S. 202
37. ↑ Vgl. Gluchowski/Gabriel 2007, S. 205-210
38. ↑ Vgl. Gluchowski/Gabriel 2007, S. 211f
39. ↑ Vgl. Kemper 2009, S. 86
40. ↑ Vgl. http://www.ifross.org/faq-haeufig-gestellte-fragen
41. ↑ Vgl. http://www.ifross.org/lizenz-center
42. ↑ Eine Übersicht und Kategorisierung bietet das Institut für Rechtsfragen der Freien und Open Source Software (vgl. http://www.ifross.org/lizenz-center).
43. ↑ Vgl. Bange 2011, S. 119
44. ↑ Vgl. Pentaho 2011b
45. ↑ Vgl. Bange 2011, S. 119
46. ↑ Vgl. http://www.pentaho.com/customers/success-stories
47. ↑ Vgl. Sallam 2010
48. ↑ Vgl. Bange 2009
49. ↑ Vgl. Bange 2011, S. 108
50. ↑ Vgl. Wiki der JasperSoft Community http://jasperforge.org/plugins/mwiki/index.php/Jasperserver/JasperAnalysis
51. ↑ Vgl. Bange 2011, S. 109
52. ↑ Vgl. Gluchowski/Gabriel 2007, S. 351f
53. ↑ Vgl. Gluchowski/Gabriel 2007, S. 353
54. ↑ Vgl. Gluchowski/Gabriel 2007, S. 353
55. ↑ Vgl. Gluchowski/Gabriel 2007, S. 186
56. ↑ Vgl. Gluchowski/Gabriel 2007, S. 351-353
57. ↑ Vgl. Inmon 2000, S. 3
58. ↑ Vgl. Inmon 2000, S. 4f
59. ↑ Vgl. mysql-Introduction 2011
60. ↑ Vgl. Community 2011b
61. ↑ Vgl. http://www.eclipse.org/
62. ↑ Vgl. Community 2011a
63. ↑ Vgl. finance.yahoo 2011
64. ↑ Vgl. Gabele 2003, S. 158f
65. ↑ Vgl. Pentaho-Wiki 2011
66. ↑ Vgl. Analyse_der_BI-Lösung_von_Pentaho#Testszenario
67. ↑ Vgl. Pentaho-Wiki 2011
68. ↑ Vgl. Pentaho-Wiki 2011
69. ↑ Vgl. Pentaho-Wiki 2011
70. ↑ Vgl. Pentaho 2009, S. 6
71. ↑ Vgl. Bouman/Dongen 2009, S. 530
72. ↑ Vgl. Bouman/Dongen 2009, S. 39 und http://tomcat.apache.org/
73. ↑ Vgl. Saiku 2011b
74. ↑ Vgl. Bouman/Dongen 2009, S. 442-444 und Hyde 2006
75. ↑ Vgl. Gluchowski/Gabriel 2007, S. 186f
76. ↑ Vgl. Pentaho 2011a
77. ↑ Vgl. itnovum 2011
78. ↑ Vgl. Bouman/Dongen 2009, S. 442-444
79. ↑ Vgl. Bouman/Dongen 2009, S. 446f
80. ↑ Vgl. Community 2011a
81. ↑ Vgl. Saiku 2011a
82. ↑ Vgl. Saiku 2011b
83. ↑ Vgl. Bouman/Dongen 2009, S. 123
84. ↑ Vgl. Pentaho 2009
85. ↑ Vgl. Bouman/Dongen 2009, S. 347-350
86. ↑ Vgl. Bouman/Dongen 2009, S. 510
87. ↑ Vgl. Bouman/Dongen 2009, S. 511-519
88. ↑ Vgl. Bouman/Dongen 2009, S. 508
89. ↑ Vgl. Pentaho 2011b
90. ↑ Vgl. Haneke 2010, S. 99-101
91. ↑ In der Studie von Madsen werden die unterschiedlichen Preismodelle verglichen (Vgl. hierzu Madsen 2009)
92. ↑ Vgl. Madsen 2009
93. ↑ Vgl. Gluchowski/Gabriel 2007, S. 353

9 Literatur- und Quellenverzeichnis

Bange 2009	Bange, Carsten et al. (2009): BARC-Marktstudie. BI-Softwaremarkt Deutschland 2008/2009.
BARC 2011	BARC (2011): BARC-Guide Business Intelligence 2011/2012.
Bauer/Günzel 2009	Bauer, Andreas; Günzel, Holger (Hg.) (2009): Data-Warehouse-Systeme. Architektur, Entwicklung, Anwendung. 3. Aufl. Heidelberg: dpunkt.
Bouman/Dongen 2009	Bouman, Roland; Dongen, Jos van (2009): Pentaho solutions. Business intelligence and data warehousing with Pentaho and MySQL. Indianapolis, IN: Wiley.
Codd 1993	Codd E.F., Codd S.B. Salley C.T (1993): Providing OLAP (On-line Analytical Processing) to User-Analysts: An IT Mandate. Online verfügbar unter http://www.minet.uni-jena.de/dbis/lehre/ss2005/sem_dwh/lit/Cod93.pdf.
Community 2011a	Welcome to the Pentaho Community. Online verfügbar unter http://community.pentaho.com/, zuletzt geprüft am 27.12.2011.
Community 2011b	Kommerzielle Open Source Business Intelligence von Pentaho. Online verfügbar unter http://community.pentaho.com/faq/platform_licensing.php, zuletzt geprüft am 22.12.2011.
Dietrich/Kagba 2011	Dietrich, Johannes; Kagba, Hüseyin (2011): Pentaho und Jaspersoft. Open Source BI-Suiten im Vergleich. In: BI-Spektrum 2011 (04), S. 16–20.
finance.yahoo 2011	DAX Stock - Yahoo! Finanzen. Online verfügbar unter http://de.finance.yahoo.com/q/cp?s=%5EGDAXI, zuletzt geprüft am 26.11.2011.
Gabele 2003	Gabele, E.; Mayer, H. (2003): Buchführung: Oldenbourg. Online verfügbar unter http://books.google.de/books?id=u1PfL0izGa0C.
Gluchowski/Gabriel 2007	Gluchowski, P.; Gabriel, R.; Chamoni, P.; Dittmar, C. (2007): Management Support Systeme und Business Intelligence: Computergestützte Informationssysteme für Fach- und Führungskräfte: Springer.
Gluchowski/Kemper 2006	Peter Gluchowski, Hans-Georg Kemper (2006): Quo Vadis Business Intelligence? In: BI-Spektrum 2006 (06), S. 12–19.
Haneke 2010	Haneke, Uwe (2010): Open Source Business Intelligence. Möglichkeiten, Chancen und Risiken quelloffener BI-Lösungen. München: Hanser.
Hyde 2006	Hyde, Julian (2006): Mondrian Documentation - Architecture. Online verfügbar unter http://mondrian.pentaho.com/documentation/architecture.php, zuletzt geprüft am 14.01.2012.
Inmon 2000	William H. Inmon (2000): The Data Warehouse Budget. Online verfügbar unter http://www.datawarehouse.inf.br/Papers/inmon%20budget-1.pdf
itnovum 2011	Ruth Heidingsfelder: Pentaho: ClearView löst jPivot ab - itnovum. Online verfügbar unter http://www.it-novum.com/news-list/blog-single-view/article/pentaho-clearview-loest-jpivot-ab-28.html, zuletzt geprüft am 22.12.2011.
Kemper 2009	Kemper, H.G; Baars, H.; Mehanna, W. (2009): Business Intelligence. Grundlagen und praktische Anwendungen: Eine Einführung in die IT-basierte Managementunterstützung: Vieweg+Teubner Verlag.
Kimball 2008	Kimball, Ralph: The data warehouse lifecycle toolkit, 2008, 2. Aufl. Indianapolis, IN: Wiley Pub.
Madsen 2009	Madsen, Mark (2009): Lowering the Cost of Business Intelligence With Open Source. A Comparison of Open Source and Traditional Vendor Costs. Online verfügbar unter http://www.pentaho.com/resources/pdf-stream/23/lowering-the-cost-of-business-intelligence-with-open-source, zuletzt aktualisiert am 09.05.2010, zuletzt geprüft am 02.01.2012.
mysql-Introduction 2011	MySQL :: Introducing the MySQL Installer for Windows. Online verfügbar unter http://dev.mysql.com/tech-resources/articles/mysql-installer-for-windows.html, zuletzt geprüft am 27.11.2011.
Pentaho 2009	Pentaho (2009): Introducing the Pentaho BI Suite 3.5 Community Edition. Hg. v. Pentaho
Pentaho 2011a	Business analytics and business intelligence leaders - Pentaho. Online verfügbar unter http://www.pentaho.com/press-room/releases/20091005_pentaho_announces_strategic_technology_acquisition/, zuletzt geprüft am 27.12.2011.
Pentaho 2011b	Pentaho (2011): Pentaho Business Analytics Packages. Online verfügbar unter http://www.pentaho.com/explore/packages/, zuletzt geprüft am 27.12.2011.
Pentaho-Wiki 2011	Latest Pentaho Data Integration (aka Kettle) Documentation - Pentaho Wiki. Online verfügbar unter http://wiki.pentaho.com/display/EAI/Latest+Pentaho+Data+Integration+%28aka+Kettle%29+Documentation, zuletzt geprüft am 07.12.2011.
Saiku 2011a	Saiku - Next Generation Open Source Analytics (2011). Online verfügbar unter http://analytical-labs.com/, zuletzt aktualisiert am 25.10.2011, zuletzt geprüft am 27.12.2011.
Saiku 2011b	A labs QA. Online verfügbar unter http://ask.analytical-labs.com/questions/, zuletzt geprüft am 27.12.2011.
Sallam 2010	Sallam, Rita L. et al. (2010): Magic Quadrant for Business Intelligence Platforms. Gartner RAS Core Research Note G00173700.