Analyse von großen Datenmenge mit Hilfe von - RWTH

Analyse von großen Datenmengen
mit Hilfe von Datacubes
Seminararbeit im Studiengang
Scientific Programming
WS 2012 / 2013
Autor:
David Schweer
Matrikelnummer:
843901
1. Betreuer:
2. Betreuer:
Prof. Dr. rer. nat. Bodo Kraft
Alexander Trieb
Datum:
20. Dezember 2012
Eidesstattliche Erklärung
Hiermit versichere ich, dass ich die Seminararbeit mit dem Thema
„Analyse von großen Datenmengen mit Hilfe von Datacubes“
Selbstständig verfasst und keine anderen als die angegebenen Quellen und
Hilfsmitte benutzt habe, alle Ausführungen, die anderen Schriften wörtlich oder
sinngemäß entnommen wurden, kenntlich gemacht sind und die Arbeit in gleicher
oder ähnlicher Fassung noch nicht Bestandteil einer Studien- oder Prüfungsleistung
war.
Name: David Schweer
Aache, den 20.12.2012
Unterschrift des Studenten
Inhalt
1 Einleitung .............................................................................................................................................. 1
2 Data-Warehouse .................................................................................................................................. 2
2.1 Definition ....................................................................................................................................... 2
2.2 ETL-Prozess .................................................................................................................................... 4
2.2.1 Extraktion ............................................................................................................................... 5
2.2.2 Transformation ....................................................................................................................... 5
2.2.3 Laden ...................................................................................................................................... 6
3 Data-Mart ............................................................................................................................................. 8
3.1 Definition ....................................................................................................................................... 8
3.2 Abhängige Data-Marts .................................................................................................................. 8
3.2.1 Data-Mart-Extraktionen ......................................................................................................... 9
3.2.1.1 Strukturelle Extraktion: ................................................................................................... 9
3.2.1.2 Inhaltliche Extraktion: ..................................................................................................... 9
3.2.1.3 Aggregierte Extraktion: ................................................................................................... 9
3.3 Unabhängige Data-Marts ............................................................................................................ 10
3.4 Vergleich der 2 Data-Mart Konzepte........................................................................................... 11
4 OLAP ................................................................................................................................................... 12
4.1 12 Regeln nach Codd (Bauer & Holger, 2009) ............................................................................. 12
4.2 OLAP-Würfel ................................................................................................................................ 14
4.2.1 Grundoperationen (OLAP-Würfel) ....................................................................................... 15
5 Pentaho .............................................................................................................................................. 16
5.1 Erstellen von Schemadateien ...................................................................................................... 16
5.1.1 Beispiel Schemadatei (Mondrian) ........................................................................................ 18
6 Zusammenfassung und Ausblick ........................................................................................................ 19
6.1 Zusammenfassung ....................................................................................................................... 19
6.2 Ausblick........................................................................................................................................ 19
1 Einleitung
1 Einleitung
Business Intelligence spielt in der heutigen Zeit eine wichtige Rolle in Unternehmen.
Daten in elektronischer Form werden durch verschiedene Verfahren gesammelt,
ausgewertet und dargestellt. Anhand dieser Verfahren ist es für das Unternehmen
möglich, bessere operative und strategische Entscheidungen zu treffen.
Travelaudience schaltet Reisewerbung auf reiserelevanten Webseiten. In diesem
Bereich
ist
es
essential
wichtig,
auf
Grund
der
gesammelten
Daten
Unternehmenskritische Entscheidungen zu treffen. Zum Beispiel einem Kunden die
Performance seiner Werbeannonce zu nennen und somit eventuelle Schwachstellen
zu beseitigen. Da gerade bei der freien Nutzung von Internet-basierten
Informationsplattformen eine sehr große Datenmenge anfällt, werden anhand
verschiedener Verfahren, die Daten aufbereitet, analysiert und dargestellt.
Anhand dieser Arbeit, werden Aufbereitung, Analyse und die Darstellung der Daten
erklärt. Dabei wird genauer auf die Prinzipien der grundlegenden Methoden der
Datenhaltung (zum Beispiel ein Datawarehouse) sowie der weiteren Verfahren zum
vorselektieren der relevanten Daten, auf Basis von Datamarts eingegangen. Letzteres
dient dazu eine höhere Performance für die Darstellung der gewünschten
Information zu erreichen. Die eigentliche Darstellung der Informationen geschieht
durch das Erstellen von Datacubes, welche der Schwerpunkt dieser Arbeit sind.
Außerdem wird in dieser Arbeit auf die Business Intelligence Software Pentaho
eingegangen.
Seite 1
2 Data-Warehouse
2 Data-Warehouse
2.1 Definition
Ein
Data-Warehouse
unterschiedlichsten
ist
eine
Datenquellen
Datenbank,
in
einem
welche
Informationen
gemeinsamen
aus
Datenformat
zusammenführt und für eine spätere Auswertung vorhält. Die Daten werden anhand
ihres Informationsgehaltes ausgewählt, also nur die Daten, die relevanten
Informationen für die Analyse und somit für die Entscheidungsfindung beinhalten.
Um die Daten analysieren zu können, müssen sie alle in einem einheitlichen Format
vorliegen. Der Prozess des Umwandelns der Daten bezeichnet man als ETL-Prozess
(Extract, Transform, Load). Da bei Analysen meistens nicht nur ein gewisser
Zeitpunkt betrachtet wird, sondern ein Zeitraum um auch zeitliche Entwicklungen
analysieren zu können, ist es wichtig, dass die Daten mit entsprechenden
Zeitinformationen gespeichert werden. Zudem müssen die Daten auch dauerhaft
gespeichert werden. Sind die Daten in einem Data-Warehouse gespeichert,
verbessert sich der Zugang zu den Informationen, da diese bereits zusammen
geführt sind.
Abbildung 1: Grafischer Überblick – Data Warehousing (DataWarehouse4u)
Die Abbildung stellt schematisch den Informationsfluss von den Quelldaten zu den
Auswertungsinformationen dar. Das Data-Warehouse erhält die Daten von dem
Seite 2
2 Data-Warehouse
ETL-Prozess der wiederum diese aus den verschiedenen Datenquellen ermittelt. Der
ETL-Prozess wird in Kapitel 2 näher beschrieben. Sind die Daten einmal im DataWarehouse abgelegt, ist es möglich durch verschiedene Analyseverfahren, wie zum
Beispiel OLAP Analysen siehe Kapitel x durchzuführen, Berichte zu erstellen und
Data Mining zu betreiben.
Eine einheitliche Definition für ein Data-Warehouse existiert nicht.
Eine erste Definition aus dem Jahre 1996 von Immon, die sehr einschränkend ist und
somit nicht alle Fälle abdeckt, lautet folgendermaßen:
“A data warehouse is a subject oriented, integrated, non-volatile, and time variant
collection of data in support of management’s decisions.”
Eine weitere Definition, die nicht so restriktiv ist, lautet folgendermaßen:
“A data warehouse is a copy of transaction data specifically structured for querying
and reporting.”
Anhand dieser beiden Aussagen wird deutlich, wie unterschiedlich die Definition für
ein Data-Warehouse ist. Während die erste Definition den Fokus auf die
Charakteristik der Informationen legt, stellt die zweite eher die technische
Ausprägung dar.
Seite 3
2 Data-Warehouse
2.2 ETL-Prozess
Der ETL-Prozess sorgt dafür, dass die Daten aus den unterschiedlichen Quellen in
ein einheitliches Format, das Format des Data-Warehouse, vereint werden. Dabei
besteht der Prozess aus drei Teilschritten:
-
Extraktion
(Extract)
-
Transformation
(Transform)
-
Laden
(Load)
Die Extraktion liest die gewünschten Daten aus den verschiedenen Quellen in einen
Arbeitsbereich. Im Arbeitsbereich werden die Daten transformiert. Zum Schluss
werden die transformierten Daten in das Data-Warehouse geladen.
Der gesamte Prozess sollte dabei sehr effizient ab laufen, da in der Regel sehr große
Datenmengen verarbeitet werden. Zudem stehen zumindest das Data-Warehouse
zum Teil auch die Quelldaten während des Vorganges dem Anwender oder anderen
Anwendungen nicht zu Verfügung.
Auch die Qualität, die Konsistenz und die
Vollständigkeit der Daten spielt eine wichtige Rolle, da diese trotz Änderung von
Stammdaten, vollständig und nachvollziehbar im Data-Warehouse vorliegen sollen.
Ein ETL-Prozess kann durch ein eigenes Programm in einer beliebigen
Programmiersprache umgesetzt werden. Meistens werden Standardprogramme und
deren Funktionalitäten benutzt, die bereits sämtliche Datenbanksysteme und
Dateisysteme unterstützen. Außerdem beinhalten sie auch bereits Verfahren, die den
Transformationsprozess qualitativ hochwertig machen, zum Beispiel Visualisierung
der Daten, Fehlerbehandlung und Scheduling. Meist sind diese Programme speziell
ausgelegt, arbeiten hocheffizient und minimieren die Speerzeiten an Startquelle und
Zielquelle.
Folgende Beispiele sind im kommerziellen Bereich zu benennen: IBM, SAP, Oracle.
Im Open Source-Bereich gibt es unter anderem Pentaho und Scriptella.
Seite 4
2 Data-Warehouse
2.2.1 Extraktion
Die Extraktion holt die Daten aus den unterschiedlichen Quellen in den
Arbeitsbereich. Dabei werden in der Regel nicht alle Daten aus den Quellen
entnommen, sondern nur die Daten selektiert, die für die spätere Auswertung
relevant sind. Um geänderte Daten aus einer Quelle zu ermitteln und damit nicht
immer den gesamten Datenbestand neu zu extrahieren, gibt es verschiedene
Monitoring-Strategien.
Bei Trigger-basierten Verfahren, kann man die geänderten Daten einfach aus der
entsprechenden Datei entnehmen. Geänderte Daten werden bei einem zeitbasierten
Verfahren über den sogenannten Timestamp eines Datensatzes ermittelt. Dabei sorgt
die Anwendungsapplikation welche die Quelldaten erzeugt, dafür dass sowhl das
Erstellungs als auch ein Aktualisierungsdatum mit abgespeichert wird. Bei
Replikationstabellen müssen über SQL-Abfragen nur die richtigen Tabellen selektiert
werden.
Aber auch der der Aktualitätsgrad des Data-Warehouse spielt eine wichtige Rolle.
Hierfür gibt es verschiedene Varianten. Ist eine geforderte Mindestaktualität der
Daten gefordert, lässt sich das Ganze über eine periodische Extraktion umsetzen. Es
wird eine Zeitspanne festgelegt, in dem die Daten mindestens einmal zu
aktualisieren sind. Hierüber gesteuert läuft der ETL-Prozess selbständig immer in
regelmäßigen Abständen (Scheduling). Es ist auch möglich den Prozess nur auf
Anfrage zu starten (manuelle Steuerung) oder wenn ein bestimmtes Ereignis eintritt
(Trigger). Ein mögliches Ereignis könnte hierbei eine Mindestanzahl an geänderten
Daten sein. Sind dagegen sogenannte Echtzeitdaten im Data-Warehouse gefordert,
dann sollte der Prozess bei Änderung an den Quelldaten unmittelbar anlaufen und
das Ergebnis des ETL-Prozesses ins Data-Warehouse schreiben.
Die technische Realisierung des Zugriffs und der Extraktion ist dabei recht einfach
und erfolgt über meist vorhandenen Standardschnittstellen zu den QuellDatenbanken, wie zum Beispiel ein ODBC-Zugriff (Open Database Connectivity)
2.2.2 Transformation
Da die durch den Extraktionsprozess geladen Daten im Arbeitsbereich alle noch ein,
in Abhängigkeit der Quelldaten, unterschiedliches Format haben können, werden in
Transformationsschritten die Daten strukturell als auch inhaltlich aufgearbeitet. Vor
Seite 5
2 Data-Warehouse
allem Daten, die aus heterogenen Quellen stammen, durchlaufen dieses Verfahren,
um ein einheitliches Format zu bekommen und somit vergleichbar zu sein. Hierbei
werden zum Beispiel die Datentypen angepasst, die Kodierung vereinheitlicht,
eventuelle Attribute zusammengefasst oder getrennt.
Ein sehr anschauliches Beispiel wären zwei Informationen aus unterschiedlichen
Quellen, die beide ein Attribut mit einem Datumswert beinhalten. In dem einen
Datensatz steht das Datum im Format yyyy-MM-dd (2012-12-10), im anderen
Datensatz ist das Format aber dd-MM-yy (10-12-12). Um beide Datumsangaben
vergleichen zu können, müssen sie das gleiche Format haben.
Zudem besteht die Wahrscheinlichkeit das Daten fehlerhaft, redundant oder veraltet
sind. Auch hierfür kann der Transformationsprozess weitere Verfahren bereitstellen,
welche eventuelle Fehlersituationen erkennen und beheben wird.
In einem modernen flexiblen ETL-Prozess kann der Transformationsprozess mit
eigenen Verfahren und ergänzenden Routinen erweitert werden.
2.2.3 Laden
Nachdem der Transformationsprozess erfolgreich durchlaufen ist, liegen die
ausgewählten Daten in dem genormten Format im Arbeitsbereich. Nun können die
Daten durch die Ladekomponente in das eigentliche Data-Warehouse übertragen
und somit abgespeichert werden. Da im klassischen ETL-Prozess keine Daten
konsolidiert und komprimiert werden, ist auch aufgrund des zeitintensiven
Schreibvorgans auf das Speichermedium für den Ladevorgangs eine effiziente
Umsetzung des Prozesses notwendig um das Data-Warehouse, sowenig wie möglich
für die eigentliche Nutzung zu blockieren.
Desweitern ist es sinnvoll eine Versionierung des Data-Warehouse anzulegen. Jede
Aktualisierung des Data-Warehouse wird protokolliert und die Vorgänger-Zustände
im Repositorium archiviert. Dann kann auch auf älteren Datenbeständen problemlos
zugegriffen werden, um bei auftretenden Fehlern eine ältere und somit
funktionsfähige Variante zu zurück zu holen.
Seite 6
2 Data-Warehouse
Abbildung 2: ETL-Prozess (ETL-Prozess)
Seite 7
3 Data-Mart
3 Data-Mart
3.1 Definition
Ein Data-Mart ist eine vereinfachte Form beziehungsweise ein Auszug eines
komplexen Data-Warehouse. Ein Data-Warehouse fasst verschiedene Informationen
aus unterschiedlichen Quellen zusammen. Ein Data-Mart hingegen baut auf einem
Data-Warehouse auf und verdichtet die gesammelten Informationen des DataWarehouse weiter. Somit wird ein beschränkter inhaltlicher Fokus auf die Daten
gegeben. Durch diese Teilsicht auf die Daten werden verschiedene Ziele verfolgt und
umgesetzt.
Als ein Motivator zur Bildung von Data-Marts ist der Aspekt der Datensicherheit. Da
in einem Data-Warehouse alle Informationen granular zugänglich sind, müssen über
zusätzliche Funktionen, bestimmte Daten für eine bestimmte Gruppe an Benutzern
ausgeblendet sein, um den Datenschutz gerecht zu werden. Stellt man allerdings
Data-Marts für die unterschiedlichen Benutzern zur Verfügung, ist es sehr wohl
möglich, dass bestimmte Gruppen nur bestimmte Daten sehen. Der jeweiligen
Gruppe wird dabei nicht mehr die Sicht auf das gesamte Data-Warehouse, sondern
nur noch auf ein zugeschriebenes Data-Mart gewährt. Des Weiteren wird somit auch
direkt das Datenvolumen für die Benutzergruppen reduziert, was auch dazu führt
das die Performance steigt. Dadurch das ein Data-Mart die Daten zurückliefert, ist es
nicht mehr nötig auf dem Data-Warehouse zu arbeiten, wodurch Last vom DataWarehouse und dem Server genommen wird und auf die Rechner der Benutzer, also
dem Client, verlegt wird. Mit Hilfe von Data-Marts lässt sich auch die
Unternehmens-Organisation sehr gut nachbilden, indem zum Beispiel jede Abteilung
ihr eigenes Data-Mart bekommt.
In der Theorie unterscheidet man grundsätzlich zwischen 2 Data-Mart Konzepten.
Den abhängigen Data-Marts und den unabhängigen Data-Marts.
3.2 Abhängige Data-Marts
Abhängige Data-Marts werden auf ein existierendes Data-Warehouse aufgebaut.
Dabei gruppieren sich die Data-Marts um das Data-Warehouse und beinhalten nur
Datenbestände aus diesem. Diese Daten werden gegebenenfalls aggregiert, aber
Seite 8
3 Data-Mart
nicht mehr normiert oder bereinigt. Dadurch führt die Auswertung eines Data-Marts
genau zu dem gleichen Ergebnis wie eine Auswertung, die direkt auf dem DataWarehouse durchgeführt würde. Um eine Data-Mart zu erstellen, sollte die
Problemstellung genau analysiert werden und genau bekannt sein welche Daten zur
Lösung benötigt werden.
Es gibt 3 Möglichkeiten, um die Datenmenge des Data-Warehouse in einem DataMart zu reduzieren. Die strukturelle Extraktion, die inhaltliche Extraktion und die
aggregierte Extraktion. Alle 3 Möglichkeiten könne kombiniert verwendet werden.
3.2.1 Data-Mart-Extraktionen
3.2.1.1 Strukturelle Extraktion:
Die strukturelle Extraktion selektiert nur die Daten aus dem Data-Warehouse die für
die Analyse notwendig sind.
Besteht ein Data-Warehouse zum Beispiel aus 3 Tabellen von denen im Data-Mart
nur 2 genutzt werden, oder von 20 Spalten der Tabelle nur 5 Spalten ausgewählt
werden, so basiert der Data-Mart auf eine strukturelle Extraktion des DataWarehouse.
3.2.1.2 Inhaltliche Extraktion:
Wie der Name schon sagt, werden hier die Daten auf der inhaltlichen Ebene weiter
zusammengefasst.
Bei der inhaltlichen Extraktion erfolgt die Reduzierung des Data-Warehouse in das
Data-Mart aus einer Analyse bestimmter Feldinhalte.
3.2.1.3 Aggregierte Extraktion:
Häufig passiert es in der Praxis, dass die Daten nicht in der gewünschten
Genauigkeit vorliegen. Mit Hilfe der aggregierten Extraktion kann das Data-Mart für
die nachfolgende Nutzung aufgewertet werden.
Reicht zum Beispiel die Darstellung der Daten auf einer Tagesbasis aus, die Daten
liegen im Data-Warehouse allerdings stündlich vor, so wird im Data-Mart die
Granularität verringert und alle stündlichen Daten zu einem Datensatz auf
Tagesebenen verdichtet.
Seite 9
3 Data-Mart
Abbildung 3: Abhängige Data-Marts (Bauer & Holger, 2009)
3.3 Unabhängige Data-Marts
Abhängige Data-Marts bilden ihren Datenbestand auf Basis eines Data-Warehouses,
fehlt
dieses
können
die
einzelnen
Data-Marts
auf
die
ursprünglichen
unterschiedlichen Datenquellen aufbauen. In der Regel sind dies kleinere
Datenbestände in Form von Datenbanken oder sonstige Datenspeicherquellen, die
jede Abteilung für sich zur Verfügung hat. Auf diese Quellen werden die Data-Marts
aufgebaut.
Seite
10
3 Data-Mart
Abbildung 4: Unabhängige Data-Marts (Bauer & Holger, 2009)
3.4 Vergleich der 2 Data-Mart Konzepte
Beim abhängigen Data-Mart Konzept ist ein mehr Aufwand von Nöten, da schon zu
Beginn ein Data-Warehouse existieren muss, welches alle Daten zusammenfasst.
Dies ist bei den unabhängigen Data-Marts nicht der Fall. Hier kann direkt mit den
vorliegenden Daten gestartet werden. Jedoch kann es hier zu Überschneidungen der
Data-Marts kommen. Außerdem ist es nur unter Mehraufwand möglich, Analysen
über die Grenzen eines Data-Marts hinaus zu erstellen. Dafür müsste aus den
existierenden Data-Marts ein Data-Warehouse erstellt werden, worauf dann die
Analysen abgefragt werden. Das kann aber dazu führen, dass Informationen, die in
mehreren Data-Marts stehen und die gleiche Bedeutung haben, nicht mehr
konsistent sind. Dies ist jedoch bei abhängigen Data-Marts ohne Probleme möglich,
da die gesamten Daten im Data-Warehouse vereint sind.
Seite
11
4 OLAP
4 OLAP
OLAP (Online Analytical Processing) unterstützt dabei Analysen, Auswertungen
und Abfragen dynamisch flexibel und interaktiv auf vergleichsweise große
Datenbestände zu ermöglichen. Dabei ist zu beachten, dass OLAP nicht
zwangsläufig ein Data-Warehouse voraussetzt. OLAP soll dabei helfen, die immer
größer werdenden Datenmenge und die steigende Komplexität der Fragestellung an
die Daten zu bewältigen. Es gibt grundsätzlich 2 Arten von OLAP. ROLAP, welches
sich die Daten aus einer relationalen Datenbank holt und MOLAP, das hingegen auf
eine multidimensionale Datenbank (OLAP-Würfel) zugreift. In dieser Arbeit wird
der Begriff MOLAP anhand von Data-Cubes (OLAP-Würfel) erläutert. Der Begriff
OLAP wurde im Jahre 1993 von Edgar F. Codd geprägt. Er formulierte zuerst 12
Regeln, die später jedoch erweitert wurden.
4.1 12 Regeln nach Codd (Bauer & Holger, 2009)
1. Multidimensionale konzeptionelle Sichtweise: Die konzeptionelle Sicht auf die
Daten soll für den Anwender multidimensional sein.
2. Transparenz: Dem Anwender muss deutlich werden woher die entnommen
Informationen stammen
3. Zugriffsmöglichkeit: Es soll möglich sein auf interne Datenquellen als auch auf
externe Datenquellen zuzugreifen
4. Gleichbleibende Antwortzeit bei der Berichterstellung: Die Zeit, die benötigt wird
um eine Analyse zu erstellen darf nicht von der Anzahl der Dimensionen und
der Menge der gespeicherten Daten abhängen
5. Client/Server-Architektur:
Es
soll
eine
eindeutige
Trennung
zwischen
Speicherung, Verarbeitung und Darstellung geben. Dabei muss der Server
eine offene Schnittstelle bereitstellen
6. Generische Dimensionalität: Alle Dimensionen sollen einheitlich sein und somit
ist keine Vorbelegung von Dimensionen möglich.
7. Dynamische Behandlung dünn besetzter Matrizen: Es wird gefordert, dass das
physische Schema des Modells automatisch an die gegebene Dimensionalität
und die Verteilung jedes spezifischen Modells angepasst wird. Somit wird
verhindert, dass das Schema größer wird als die Menge der Daten.
Seite
12
4 OLAP
8. Mehrbenutzerunterstützung: Es muss möglich sein, dass gleichzeitig mehrere
Benutzer die gleichen Daten analysieren. Damit das möglich ist, müssen
Sicherheits- und Integritätsmechanismen eingebaut werden.
9. Uneingeschränkte kreuzdimensionale Operationen: Das OLAP-Werkzeug ist für
Berechnung innerhalb einzelner Dimensionen selbst zuständig. Dem
Anwender wird zudem die Möglichkeit geben über Dimensionen hinweg
Berechnungen zu definieren.
10. Intuitive
Datenbearbeitung:
Oberfläche
soll
einfach
zu
erlernen
und
Benutzerfreundlich sein.
11. Flexible Berichterstellung: Der Bericht soll die Daten beliebig anordnen können
12. Unbegrenzte Anzahl von Dimensionen und Klassifikationsebenen: Es gibt für OLAP
keine Beschränkung was die Anzahl der Dimensionen angeht. Jeder
Dimension
ist
es
zudem
gestattet,
Aggregationsebenen zu erstellen.
Seite
13
eine
beliebige
Anzahl
an
4 OLAP
4.2 OLAP-Würfel
Ein OLAP-Würfel ist eine Datenspeicherstruktur, für die Anwendung in
Analyseapplikationen (ITWissen). Ein Würfel setzt sich dabei aus Dimensionen und
Kennzahlen zusammen. Die Dimensionen sind Eigenschaften und die Kennzahlen
die Werte zu den Eigenschaften. Die Dimensionen spannen dabei die Würfelkanten
auf und die Länge des Würfels beschreibt die Anzahl der Elemente. Ein
geometrischer Würfel entsteht, sobald drei Dimensionen vorhanden sind. Allerdings
sind bezüglich der Dimensionen keine Einschränkungen gegeben. Ein OLAP-Würfel
kann somit n-dimensional aufgebaut werden. OLAP stellt dabei Funktionen zu
Verfügung um den Würfel analysieren zu können.
Abbildung 5: Beispiel eines OLAP-Würfels (MSDN)
In Abbildung 4 sieht man einen drei Dimensionalen Würfel. Dabei beschreiben die 3
Dimensionen die Regionen, die Tage und die Produkte. Die Region-Dimension
besteht aus 5 Kennzahlen; Region 1 bis Region 5. Die Tag-Dimension hat 4
verschiedene Tage als Kennzahlen und die Produkt-Dimension beschreibt die
Produkte 1, 2 und 3. Anhand dieses Würfels ist es sehr einfach komplexe
Fragestellungen zu beantworten wie zum Beispiel:
-
Welches Produkt wurde am Tag 4 in Region 2 am meisten verkauft (rote
Markierung)?
-
Wie viele Produkte wurden von Produkt 1 in Region 5 am dritten Tag
verkauft (gelbe Markierung)?
Seite
14
4 OLAP
4.2.1 Grundoperationen (OLAP-Würfel)
Slicing: Ausschneiden von Scheiben aus dem Datenwürfel.
Dicing: Gleichzeitige Slicing-Vorgänge in unterschiedlichen Dimensionen. Hierbei
wird ein kleinerer Würfel erzeugt, der einen Teilbereich des Gesamtwürfels enthält.
Pivoting: Drehen des Datenwürfels, so dass mindestens eine andere Dimension
sichtbar wird.
Drill-Down:
Aggregationen
eines
Informationsobjekts
auf
detaillierte
Werte
herunterbrechen.
Drill-Up: Gegenoperation zu Drill-Down; Verdichten auf höhere Hierarchiestufe.
Drill-Across: Dimension auf der
gleichen Hierarchiestufe;
Betrachtung
der
benachbarten Dimensionselemente.
Drill-Through: Verfeinerung bis auf höchsten Detaillierungsgrad.
Split: Der Split Operator ermöglicht es, einen Wert nach weiteren Dimensionen
weiter aufzuteilen, um weitere Detailstufen zu erreichen.
Merge: Im Gegensatz zu Split wird hier die Granularität durch das Entfernen
zusätzlicher Dimensionen verringert.
Seite
15
5 Pentaho
5 Pentaho
Pentaho ist eine Sammlung von Business-Intelligence-Werkzeuge, die seit dem Jahre
2004 von der Pentaho Corporation entwickelt wird. Die Sammlung deckt den ETLProzess, den Reporting Bereich, OLAP und Data-Mining ab. Die Software in Java
geschrieben und ist somit auch komplett plattformunabhängig. Die Software gibt es
in verschieden Versionen. Es werden auch Open Source-Varianten zu Verfügung
gestellt. Allerdings beinhalten diese nicht den kompletten Funktionsumfang. Die
Software lässt sich in Server- und Client-Anwendungen aufteilen.
5.1 Erstellen von Schemadateien
Eine Schemadatei ist die Beschreibung einer multidimensionalen Datenbank. Die
Daten für diese Datenbank kommen aus der physischen Datenbank. Dabei wird das
physische Modell in ein logisches umgewandelt. In Pentaho wird mit Mondrian
Schema Dateien gearbeitet. Diese Schemadateien werden in XML dargestellt.
Die
wichtigsten
Komponenten
einer
Schemadatei
sind
der
„Cube“,
die
„Measure“und die „Dimension“. Dabei besteht der „Cube“, wie schon erwähnt aus
Dimensionen und Kennzahlen.
Das Element „Cube“ hat die zugehörigen Elemente „Measure“ und „Dimension“.
Außerdem ein weiteres Element „Table“. Das Table-Element verweist dabei auf die
Tabelle, aus der der Würfel seine Informationen bekommt. Hier kann auch auf eine
andere Schemadatei verwiesen werden oder auf ein Data-Mart. Es muss also nicht
zwangsläufig eine Datenbanktabelle angegeben werden.
Das Element „Measure“ bezieht sich direkt auf die Tabelle, die ausgewählt wurde.
Hier wird festgelegt, welche Spalten aus der ausgewählten Tabelle genommen
werden sollen. Sinnvollerweise werden nur die Spalten selektiert, welche für die
Analyse von Bedeutung sind. Zudem muss eine Aggregation als Attribut angegeben
werden; zum Beispiel analog zu einer Datenbankabfrage „sum“, „count“, „min“,
max“, „avg“. Zusätzlich kann noch festgelegt werden, welcher Datentyp
zurückgeliefert werden soll. Auch ist es möglich, den Rückgabewert zu formatieren.
Dies geschieht über das Attribut formatString. Hier kann man zum Beispiel angeben,
mit wie vielen Nachkommastellen die Ausgabe angezeigt wird.
Das Element „Dimension“ beschreibt die Würfelkante. Über das Element
„Hierarchy“ wird der Blick auf die Daten festgelegt. So kann man mit den OLAPSeite
16
5 Pentaho
Operationen durch die Hierarchie-Ebenen navigieren. Somit ist es möglich
detailliertere Informationen zu den selektierten Daten zu bekommen. Durch die
Hierarchie-Ebenen ist es möglich die Daten so zu filtern wie sie gebraucht werden.
Als klassisches Beispiel sei auf die Zeitdimension verwiesen. Auf der obersten
Hierarchieebene sind die Daten in Jahren zusammengefasst. Mit einem Drill-In ist es
möglich auf Monate, Tag und so weiter herunter zu gehen. Ein Aggregieren und
Bilden von Zwischensummen ist nur über Hierarchien möglich. Das HierarchieElement hat die zugehörigen Elemente „Table“ und „Level“. Das Table-Element ist
wieder der Ort der gespeicherten Daten und das Level-Element ist die Sicht auf die
Daten.
Beispiel für eine Dimension (Mondrian):
<Dimension name="Time" foreignKey="time_id">
<Hierarchy hasAll="false" primaryKey="time_id">
<Table name="time_by_day"/>
<Level name="Year" column="the_year" type="Numeric" uniqueMembers="true"/>
<Level name="Quarter" column="quarter" uniqueMembers="false"/>
<Level name="Month" column="month_of_year" type="Numeric" uniqueMembers="false"/>
</Hierarchy>
</Dimension>
Es gibt noch wesentlich mehr Möglichkeiten eine Schemadatei genauer zu definieren
und genauere Analysen zu erstellen, die allerdings in dieser Arbeit nicht näher
beschrieben werden.
Seite
17
5 Pentaho
5.1.1 Beispiel Schemadatei (Mondrian)
<Schema>
<Cube name="Sales">
<Table name="sales_fact_1997"/>
<Dimension name="Gender" foreignKey="customer_id">
<Hierarchy hasAll="true" allMemberName="All Genders" primaryKey="customer_id">
<Table name="customer"/>
<Level name="Gender" column="gender" uniqueMembers="true"/>
</Hierarchy>
</Dimension>
<Dimension name="Time" foreignKey="time_id">
<Hierarchy hasAll="false" primaryKey="time_id">
<Table name="time_by_day"/>
<Level name="Year" column="the_year" type="Numeric" uniqueMembers="true"/>
<Level name="Quarter" column="quarter" uniqueMembers="false"/>
<Level name="Month" column="month_of_year" type="Numeric" uniqueMembers="false"/>
</Hierarchy>
</Dimension>
<Measure name="Unit Sales" column="unit_sales" aggregator="sum" formatString="#,###"/>
<Measure name="Store Sales" column="store_sales" aggregator="sum" formatString="#,###.##"/>
<Measure name="Store Cost" column="store_cost" aggregator="sum" formatString="#,###.00"/>
<CalculatedMember name="Profit" dimension="Measures" formula="[Measures].[Store Sales] [Measures].[Store Cost]">
<CalculatedMemberProperty name="FORMAT_STRING" value="$#,##0.00"/>
</CalculatedMember>
</Cube>
</Schema>
In diesem Beispiel wird ein Würfel „Sales“ erstellt. Dieser baut auf die Tabelle
„sales_fact_1997“ auf. Der Würfel besteht aus der Dimension Zeit und der
Dimension Geschlecht. Insgesamt hat der Würfel außerdem 4 Kennzahlen;
„unit_sales“, „store_sales“; „store_cost“ und „Profit“. Somit ist es möglich Daten in
Abhängigkeit
vom
Geschlecht
und
vom
Verkaufszahlen zu ermitteln.
Seite
18
Datum
für
die
verschiedenen
6 Zusammenfassung und Ausblick
6 Zusammenfassung und Ausblick
6.1 Zusammenfassung
In dieser Seminararbeit wurde dem Leser ein Grundwissen über Data-Warehouse,
Data-Marts und OLAP-Würfel vermittelt. Es ist nun bekannt, wie die Daten aus den
unterschiedlichen Quellen mittels ETL-Prozess in ein Data-Warehouse kommen. Auf
die Daten im Data-Warehouse können die Daten weiter extrahiert werden mit Hilfe
von Data-Marts. Dem Leser ist bekannt, dass es 2 Arten von Data-Marts gibt; die
abhängigen Data-Marts und die unabhängige Data-Marts. Dabei sollte darauf
geachtet werden, dass wenn möglich abhängige Data-Marts benutzt werden. Zudem
wurde der Begriff OLAP eingeführt und erklärt. Dem Leser ist OLAP-Würfel
einbegriff und er kennt die Grundoperationen die mit einem Würfel möglich sind.
Desweiteren sind die Grundlagen zum erstellen einer Mondrian Schemadatei
bekannt, welche in Pentaho eingelesen und verarbeitet werden.
6.2 Ausblick
Wie schon in dieser Arbeit erwähnt, gibt es wesentlich mehr Möglichkeiten eine
Schemadatei aufzusetzen. Diese weiteren Möglichkeiten könnten näher analysiert
werden und somit noch genauere Problemstellungen zu lösen. Außerdem gibt es
verschiedene Cube-Arten auf die auch eingegangen werden wie zum Beispiel
„Virtual Cubes“ und dann miteinander verglichen werden könnten. Da Pentaho eine
sehr umfassende Software ist und viele verschiedene Analysewerkzeuge zur
Verfügung stellt, wäre es auch hier sinnvoll dem Leser einen näheren Einblick über
die verschiedenen Möglichkeiten zu geben.
Seite
19
<Literaturverzeichnis
Literaturverzeichnis
Bauer, A., & Holger, G. (2009). Data Warehouse Systeme. Heidelberg: dpunkt.verlag.
DataWarehouse4u. (kein Datum). Abgerufen am 2. 12 2012 von
http://datawarehouse4u.info/index_en.html
ETL-Prozess. (kein Datum). Abgerufen am 13. 12 2012 von http://de.wikipedia.org/wiki/ETL-Prozess
Hägele, C. (kein Datum). Uni Ulm. Abgerufen am 6. 12 2012 von http://www.mathematik.uniulm.de/sai/ws03/dm/vortrag/haegele.pdf
ITWissen. (kein Datum). Abgerufen am 28. 11 2012 von
http://www.itwissen.info/definition/lexikon/OLAP-Wuerfel-OLAP-cube.html
Mondrian. (kein Datum). Abgerufen am 29. 10 2012 von
http://mondrian.pentaho.com/documentation/schema.php
MSDN. (kein Datum). Abgerufen am 18. 12 2012 von http://msdn.microsoft.com/enus/library/office/aa140038(v=office.10).aspx
OLAP-Würfel. (kein Datum). Abgerufen am 10. 12 2012 von http://de.wikipedia.org/wiki/OLAPW%C3%BCrfel
Oracle. (kein Datum). Oracle® Business Intelligence Standard Edition One Tutorial. Abgerufen am 2.
12 2012 von http://docs.oracle.com/html/E10312_01/dm_concepts.htm
Seite
20