Konzeption und Realisierung eines Data Warehouses zur Analyse

Konzeption und Realisierung
eines Data Warehouses
zur Analyse chirurgischer Workflows
SS 07 Projekt-Praktikum
Universität Konstanz
Lehrstuhl: Datenbank & Informationssysteme
Prof. Dr. Marc H. Scholl
Betreuung: Svetlana Mansmann
Matthias Röger; Information Engineering
[email protected]
Gliederung
Einführung
Entwurf und Konzeption eines Schemas zur Aufnahme chirurgischer Workflows
•
Transformation Geschäftsprozess-Beschreibung in das OLAP-System
•
•
•
Strukturierung und multidimensionale Perspektiven eines Prozesses
Modellierung: Herausforderungen und Lösungen
Struktur des Workflow Schemas
Pentaho Business Intelligence Plattform
•
Vorstellung Business Intelligence Plattform Pentaho
Überblick Pentaho Komponenten / Cube Designer
•
Praktische Vorführung
•
Konkrete Umsetzungen
Fazit
2
Vorstellung Kooperations-Partner ICCAS
Innovationszentrum für computerassistierte Chirurgie (ICCAS)
an der medizinischen Fakultät der Universität Leipzig
•
Verfolgt die Vision einer möglichst perfekten Mensch-Maschine-Zusammenarbeit
•
Betreibt interdisziplinäre Forschung in den Disziplinen
o
Chirurgie
o
Informatik
o
Natur- u. Ingenieurwissenschaften
•
Unterziel ICCAS:
o
Analyse von chirurgischen Prozessen auf Basis von chirurgischen
Arbeitsabläufen (Surgical Workflows) um Operationsabläufe verstehen,
auswerten und optimieren zu können
3
Aufgabenstellung des Praktikums
•
Aufgabenstellung des Praktikums
o
Entwurf eines Data Warehouses zur Analyse chirurgischer Workflows
• Rohdaten werden während der OP aufgenommen
• Konzeption eines multidimensionales Datenmodells zur Datenanalyse
• Implementierung des Datenmodells und Überführung der Daten in die
Datenbanksysteme PostgreSQL bzw. DB2
o
Pentaho Business-Intelligence (BI) Plattform
• Administration der Pentaho-Plattform, des Cube Designers und des Reportings
zum Zugriff auf verschiedene Datenbanksysteme
• Erzeugung des zur Datenanalyse notwendigen Mondrian-Schemas
• Integration der erzeugten Solution in die Pentaho-Plattform
4
Datenaufzeichnung / Ablauf
•
Datenaufzeichnung einer Operation
o
Aufzeichner: Speziell geschulte Medizinstudenten
o
Erfolgt über ein graphischen Workflow-Editor auf einem Tablet-PC
o
o
o
Aufzeichnungen erfolgen im Normalfall während der OP
Daten werden nachbearbeitet, hierzu Unterstützung durch Video-Aufzeichnung
Aufzeichnung kann auch komplett auf Basis von Videos erfolgen
5
Datenaufzeichnung
•
Welche Daten werden aufgezeichnet •
o
o
Globale Daten, wie z.B.
• Ort
• Zeit
• Beteiligte Personen
• Patient
• Diagnose
• Therapie
• Disziplin
Typen von Queries
o
o
o
o
Quantitative (Vorkommen, Dauer..)
Wie oft wurde ein bestimmtes Instrument benutzt?
Qualitative (Beziehungen, Muster..)
An welcher Struktur wurde welches Instr. benutzt?
Ergonomische (OP-Einrichtung)
Blickrichtung des Chirurgen?
…
Die eigentliche OP betreffende Daten, wie z.B.
• OP-Besteck
• ausgeführte Aktionen
• von welcher Person
• an welcher Körperstruktur
• von wem mit welcher Hand
• sekundengenaue Aufzeichnung
• Hinweise des Chirurgen, z.B. fehlendes OP-Besteck
6
Anwendungsgebiet
Analyse chirurgischer Workflows
Anwendungsgebiete der Analyse chirurgischer Workflows:
•
Untersuchung vorausgegangener Referenz-Fälle / Unterstützung chirurgischer
Vorbereitungen
•
Suchen von Optimierungspotential hinsichtlich OP-Verfahren, -Besteck und -Geräte
•
Bewertung der operativen Leistungen und chirurgischen Fähigkeiten
•
Verifizierung von medizinischen Hypothesen
•
Bewertung des OP-Saal-Layouts
•
Verbesserung der chirurgischen Ausbildung und von Simulationssystemen
•
...
7
Bisheriger Datenfluss
Schaubild zeigt bisherigen Datenfluss bis zur Erzeugung des Protokolls als XML-File.
•
Multidimensionale Datenanalyse mit bisherigem Recording Schema nicht möglich
•
Recording Schema / XML-Protokoll wird durch Data Warehouse ersetzt
8
Bisheriger Datenfluss
XML-Protokoll
Aufzeichnungs-Ausschnitte aus dem Protokoll im XML-Format:
Allgemeine Informationen einer OP:
Informationen einer einzelnen Aktivität:
9
OLAP und multidimensionales Datenmodell
Konzeption eines Data Warehouses auf dessen Basis die mehrdimensionale Datenanalyse
erfolgt.
•
OLAP (OnLine Analytical Processing): Bezeichnung für die Analyse und Auswertung
von großen Datenbeständen, welche multidimensional aufbereitet wurden.
•
Durch Multidimensionalität können Daten aus verschiedenen Blickwinkeln betrachtet
und analysiert werden.
OLAP-Würfel:
•
Grundlage für das mehrdimensionale Datenmodell
•
Kanten des Würfels: Dimensionen
•
Zellen: Kennzahl(en) als Funktion der Dimension
10
OLAP und multidimensionales Datenmodell
OLAP-Funktionalität:
•
Pivotierung
Vertauschen der Dimensionen: Sicht aus verschiedenen Perspektiven
•
Roll-Up
Aggregation über vorgegebene Dimensionen
•
Drill-Down
Navigation von aggregierten Daten zu Detaildaten nach bestimmten
Dimensionen
•
Slicing
Herausschneiden einer „Hyper-Scheibe“: Verringerung der
Dimensionalität
•
Dicing
Dimensionalität
Herausschneiden eines „Teilwürfels“: Erhaltung der
11
Analyse chirurgischer Prozesse
Neu entstandenes interdisziplinäres Feld „Analyse chirurgischer Prozesse“
•
Intelligente Erfassung von Informationen von laufenden chirurgischen Eingriffen zur
klinischen und technischen Analyse.
•
Medizinischer Begriff ‚chirurgischer Workflow‘ bezieht sich auf die Beschreibung von
chirurgischen Eingriffen und stellt deren Abstraktion dar.
•
Recording-Schema: um die Nutzung der chirurgischen Workflows zu ermöglichen (z.B.
Analyse), wird eine wohldefinierte Beschreibung des Eingriffs benötigt.
12
Business Process Intelligence (BPI)
Neu entstandenes Feld „Business Process Intelligence“
Definition
Anwendung von performance-getriebener Management-Technik zwischen Business
Intelligence (BI) und Geschäfts-Prozessen.
Durch die Annäherung von BI- und BPM-Technologie soll ein Mehrwert erzielt
werden, der über die einzelnen jeweiligen Nutzen hinausgeht.
Problem
Zusammenführung der fluss-orientierten Prozess-Spezifikation und des snapshotbasierten multidimensionalen Designs zur quantitativen Analyse ist nicht trivial, da die
Voraussetzungen und Ziele sehr verschieden und z.T. sogar inkompatibel sind.
13
Transformation Geschäftsprozess-Beschreibung
in das OLAP-System
•
Um Zugang in ein OLAP-System zu erhalten, müssen die Beschreibungen der
Geschäftsprozesse eine Transformation durch das zugrunde liegende
multidimensionale Datenmodell durchleben.
•
Ein chirurgischer Prozess kann z.B. als Fakt-Eintrag Surgery modelliert werden, welcher
durch die Dimensionen Location, Surgeon, Patient und Discipline charakterisiert wird.
•
Die Werte innerhalb einer Dimension werden typischerweise als Hierarchie gespeichert
um multiple Granularitäten zu unterstützen.
14
Multidimensionale Perspektive eines Prozesses –
logische/zeitliche und technische Strukturierung
Zwei Ansatzarten zur Modellierung von chirurgischen Eingriffen:
Logische / zeitliche Strukturierung
•
Aktivitäten (Activities) beschreiben chirurgische Aufgaben oder Arbeitsschritte wie es ein
Beobachter aufnehmen würde:
o
o
Entfernung von Blut mit Tupfer
Schnitt mit Skalpell
Technische Strukturierung
•
•
•
Konzept von Event und State kommt zum Einsatz
Beschreibt die Status-Änderungen der entsprechenden Subsysteme zusammen mit dem
auslösenden Event
Zu den Subsystemen gehören z.B.: beteiligte Personen, ausführende Hand, Instrumente,
Akteure, Geräte..
15
Multidimensionale Perspektive eines Prozesses –
Vertikale Zerlegung
Gliederung der Prozess-Struktur: Vertikale / Horizontale Zerlegung
Vertikale Zerlegung in zwei Granularitätsstufen der Fakten:
•
Surgery: jede einzelne OP mit entsprechenden Attributen und Dimensionen stellen
einen Fakt-Typ der obersten Ebene dar.
•
Activity, State, Event: stellen drei Typen von Workflow-Komponenten dar.
Jede hat ihre eigene Dimensionen; Behandlung als unabhängige Fakt-Typen.
Abb.: vertikale Zerlegung des chirurgischen workflows in eine Fakt-Hierarchie
16
Multidimensionale Perspektive eines Prozesses –
Vertikale Zerlegung
Generelle Struktur eines chirurgischen Prozesses in UML-Klassen-Notation:
Die Eigenschaften eines
Prozesses sind entsprechend
einer vertikalen Zerlegung
angeordnet:
workflow level
Enthält charakteristische Beschreibung der OP als Ganzes.
work step level
Eigenschaften gehören zu einer
bestimmten Komponente
innerhalb eines Workflows.
17
Multidimensionale Perspektive eines Prozesses –
Horizontale Zerlegung
Horizontale Zerlegung in sachliche Perspektiven (analog zur Identifizierung von
Dimensionen eines OLAP-Würfels):
•
Tätigkeit (Definiert Sub-Prozesse: gruppiert z.B. Aktivitäten in Phasen)
•
Arbeitsgang (Aktionen mit entsprechenden Instrumenten)
•
Verlauf (Ausführungsfolge)
•
Information (behandelt Daten-Input/-Output der Komponenten, z.B. Bilder, Signale,
technische Parameter, Kommunikation..)
•
Organisation (welche Person / Ressource ist für welche Tätigkeit verantwortlich)
18
Modellierungs-Herausforderungen
Zusätzlich zu klassischen OLAP-Einschränkungen, wie z.B.:
•
•
Summierbarkeit von Dimensions-Hierarchien
Verbot von Nullwerten als Fakt-Einträge
bringt BPM folgende Herausforderungen mit:
•
Many-to-Many Beziehung zwischen Fakten und Dimensionen sind häufig
•
Variable Granularität infolge von Ungenauigkeiten
z.B. Dimension Diagnose: Bezeichnung kann auf einem mehr oder weniger
spezifischen Level erfolgen.
19
Modellierungs-Herausforderungen
•
Heterogenität von Fakt-Einträgen.
o
Prozesse bestehen aus unterschiedlichen Komponenten.
o
Modelliert man Komponenten als einen Fakt-Typ, führt dies zu einem Verlust
der Unterklassen-Eigenschaften.
o
Mappt man die Subklasse auf verschiedene Fakt-Typen, verliert man die
Fähigkeit, alle Komponenten wie eine einzige Klasse zu behandeln (bei den
gemeinsamen Eigenschaften).
•
Austauschbarkeit von Kennzahlen und Dimensions-Rollen.
o
Im konventionellen Data Warehousing: Measure-Attribute sind zur DesignZeit bekannt.
o
Geschäftsprozess-Daten als solche besitzen keine expliziten mengenmäßigen
Charakteristiken.
o
Measures variieren von Query zu Query.
 Wichtig: Möglichkeit, Measures während der Laufzeit von praktisch jedem
Attribut spezifizieren zu können.
20
Modellierungs-Herausforderungen
•
Austauschbarkeit von Fakt und Dimensions-Rollen
o
Surgery hat selbst einen dimensionellen Charakter (Location, Patient) und
kann daher als Fakt-Typ behandelt werden.
o
Hinsichtlich einer einzelnen Aktivität spielt Surgery jedoch die Rolle einer
Dimension (z.B. Event rolls-up to Surgery).
•
Fakt-Schema ohne Measures
o
Die Measures können dynamisch definiert werden, d.h. es werden lediglich
die Einträge der qualifizierenden Fakt-Einträge gezählt.
21
Modellierungs-Lösungen
Schema eines chirurgischen Workflows
Darstellung ist an das „Dimensional Fact Model“ angelehnt:
Fakten
Rechtecke
Dimensions-Hierarchie
Gerichtete Graphen mit runden
Kategorie-Knoten
„roll-up“-Beziehung
Durchgezogene Pfeile
„is-a“-Beziehung zwischen
Fakten
Gestrichelte Linien
22
Modellierungs-Lösungen
Schema eines chirurgischen Workflows
Fact constellation
Fakt-Tabellen besitzen gemeinsame Dimensionen.
Fact hierarchy
Vertikale Zerlegung component
rolls-up zu surgery.
Satellite fact
Extraktion jeder m:n-Beziehung
zwischen Fakt und Dimension
in eine sog. bridge-Tabelle, z.B.
surgery_discipline.
Fact generalization
Gleichbehandlung von Fakt-Typen
activity, state, event
in gemeinsamer Superklasse component
hinsichtlich gemeinsamer Eigenschaften.
23
Relationale Implementierung
•
•
•
•
Star und Snowflake Schema sind die beiden Optionen des relationalen Data
Warehouse Designs.
Star Schema: Platzierung der gesamten Dimensions-Hierachie in eine einzelne
Relation durch pre-joining aller Aggregations-Level.
Snowflake Schema: Normalisierte Dimensions-Hierarchien.
 Einzige Option, wenn dimensionale Hierarchien zu Irregularien führen, wie z.B.
Heterogenität, non-strictness, missing values, mixed granularität…
Realisiert: Galaxy-Schema analog Snowflake Schema; jedoch sind mehrere
Faktentabellen vorhanden, die mit denselben Dimensionstabellen verknüpft sind.
 Erweiterung des herkömmlichen Galaxy-Schema um zusätzliche Tabellen-Typen:
Generalisierte Tabellen:
Satellite Fact:
24
Pentaho – Vorstellung
Open Source Pentaho Business Intelligence Plattform:
•
Bündelt Open Source BI-Projekte.
•
Stellt breites und integriertes Portfolio unterschiedlicher Open Source BI-Tools
zusammen.
•
Zählt zu den 100 populärsten Open Source-Projekten; Marktführer in Open Source BI.
•
Gründung: 2004, Orlando (USA)
•
Gründungsteam: Zusammenschluss ehemaliger Manager und Branchenkenner auf dem
BI-Gebiet verschiedener führender BI-Hersteller.
•
Zusätzlich zur Open Source – Version wird eine „professional edition“ angeboten.
25
Pentaho – Vorstellung
Software unterstützt flexible Einsatzmöglichkeiten:
•
Komponenten für Entwickler
o
Nutzung einzelner Komponenten durch Web Service Interfaces.
o
BI-Funktionalitäten können z.B. in bestehende Applikationen integriert werden.
o
Auf Kundenbedarf zugeschnittene BI-Lösungen.
•
Out-of-the-box Produkte
o
Ready-to-deploy Applikationen für Reporting, Analyse, Dashboards, Data Mining
und Workflow stehen zur Verfügung.
o
Können im Paket oder als stand-alone-Anwendungen genutzt werden.
•
Komplettes BI-Framework
o
Alle Ressourcen sind in einem umfassenden BI-Framework mit zentralen
Repository, Security und anderen plattformweiten Features integriert.
26
Pentaho – Open BI Suite
Pentaho BI-Projekt umfasst folgende
Applikationsbereiche:
•
Reporting (JFreeReport)
•
Analyse
o
OLAP-Server (Mondrian)
o
Data Mining (Weka)
•
Dashboards
•
Prozess Management
o
Datenintegration (Kettle)
•
BI Plattform (Pentaho)
27
Pentaho – Komponente KETTLE
Datenintegration
Pentaho Datenintegration: KETTLE
•
Akronym KETTLE: „Kettle Extraction, Transformation, Transportation and Loading Environment“.
•
In Java geschriebenes ETL-Tool.
•
Enthält eine GUI-Komponente zur Konfiguration von Transformations- und Ladeprozessen.
•
Datenfluss kann mittels drag-and-drop über eine graphische Oberfläche gestaltet werden. Es
wird spezifiziert WAS gemacht werden soll, jedoch nicht WIE.
•
Transformations-Bibliothek mit über 70 out-of-the-box Mapping-Objekten.
28
Pentaho – Komponente KETTLE
Datenintegration
KETTLE – besteht aus mehreren Komponenten:
•
Graphisches Tool zum Erstellen von Transformationen und Jobs.
•
Transformations-Engine, um Daten aus verschiedenen Quellen zu laden, zu transformieren und an
das gewünschte Ziel auszugeben.
•
Komponente zur Verwaltung von Jobs, die zu bestimmten Zeiten ausgeführt werden sollen.
29
Pentaho – Komponente KETTLE
Datenintegration
Anwendungen
•
Import von Daten in Datenbanken. Quellen reichen von Text-Dateien bis Excel-Tabellen.
•
Export von Datenbanken in Text-Dateien oder andere Datenbanken.
•
Datenmigration zwischen Datenbank-Applikationen.
•
Exploration von Daten in vorhandenen Datenbanken (Tabellen, Views..).
•
Datenbereinigung durch Hinzufügen von komplexen Bedingungen in die DatenTransformationen.
30
Pentaho – Komponente Reporting
Reporting - Eigenschaften
•
Basiert auf JFreeReport
(freie Java Reporting Bibliothek)
•
Flexibler Einsatz
o
o
•
Zugriff auf unterschiedliche
Datenquellen:
o
o
o
•
Standalone desktop reporting
Interaktives webbasiertes Reporting
Relationale Datenbanksysteme
XML-basierte Datenquellen
OLAP u.a.
Zusammenfassung der Daten aus
diversen Quellen
31
Pentaho – Komponente Reporting
•
Exportmöglichkeit in verschiedenen
Formaten:
o
PDF, HTML, Excel, Word…
•
Design Studio
o
Unterstützung durch Wizzard
o
Report Layout
o
Verteilung der Reports (Mail,
Durchführungszeit..)
o
Berichte mit statischen /
dynamischen Selektionen
•
Integration in nächste Entwicklerversion von OpenOffice.
32
Pentaho – Komponente Dashboards
Pentaho Dashboards
•
Visuelle Bereitstellung wichtiger
Kennzahlen
•
Sofortiger Einblick in individuelle,
Abteilungs- oder
Unternehmensleistungen
•
Versorgt Unternehmen mit kritischen
Informationen
•
Möglichkeit zur Definition und
Verfolgung von kritischen
Geschäftsmetriken
33
Pentaho – Komponente Dashboards
•
Interaktive visuelle Displays
o
•
Integration in Pentaho Plattform
o
o
o
•
Nutzer erkennt sofort, welche
Geschäftszahlen “im grünen Bereich” sind
bzw. eine besondere Aufmerksamkeit
erfordern.
Zusammenspiel mit Reporting und
Analysis
Steht einer großen Menge von Nutzern
zur Verfügung
Integrierte Security, Scheduling
Integrierte Alarmierung falls Ausnahmen
auftreten sollten.
34
Pentaho – Komponente WEKA
Data Mining
Pentaho übernimmt 2006 Data Mining Projekt WEKA
•
WEKA wurde an der University of Waikato,
Neuseeland, entwickelt.
•
Quelloffenes Data-Mining-Framework
•
Sammlung von Java-Klassen zur
o
Datenaufbereitung
o
Datensammlung
o
Klassifizierung
o
Visualisierung
35
Pentaho – Komponente WEKA
Data Mining
Unterstützte Data Mining-Verfahren:
•
•
•
•
•
Clustering
Segmentierung
Entscheidungsbäume
PCA-Analyse
Neuronale Netze
Unterstützung durch graphische Tools:
•
•
•
Data Mining Design
Administration
Unterstützt neben verschiedenen Data
Mining-Verfahren auch das Präprozessing
36
Pentaho – Komponente MONDRIAN
OLAP-Server
Einführung
•
Mondrian ist ein OS OLAP-Server.
•
Bietet multidimensionale Sicht der Daten.
•
Programmiert in Java.
•
Zugriff via JDBC auf fast alle relationale Datenbanksysteme.
•
Auswertung erfolgt im Kern mit MDX (Multidimensional
Expressions).
•
Die Abfragen werden via HTTP/Tomcat an den Java-Mondrian
Server geleitet und ausgeführt.
•
Mit der Bibliothek JPIVOT kann man Mondrian-Abfragen
über JSP (Java Server Pages) in Weblösungen integrieren.
37
Pentaho – Komponente MONDRIAN
OLAP-Server
Anwendung / Navigation und Datenexploration:
•
Ermöglicht interaktive Analyse großer Datenmengen.
•
Für Analyse in der Pentaho-Plattform muss Anwender
kein SQL beherrschen.
•
Webbasierte Frontends oder Excel
38
Pentaho – Komponente MONDRIAN
OLAP-Server
Funktionalität
•
Standard-OLAP-Funktionen
o
Slicing
o
Dicing
o
Drill-Down/Roll-up
o
Pivot
•
Auswahl gewünschter members zur Analyse
•
Filterung / Sortierung von Daten
•
Diagramm-Erzeugung
•
Export aktueller Daten in verschiedenen Formaten
•
Reportingmöglichkeiten (PDF Generierung..)
39
Pentaho – Komponente MONDRIAN
OLAP-Server
Realisiert in einer 4-Schichten-Architektur:
•
•
•
•
Präsentationsschicht (Presentation layer)
Kalkulationsschicht (Dimensional layer)
Aggregationsschicht (Star layer)
Speicherschicht (Storage layer)
Mondrian Server
1. Schicht: Präsentationsschicht
•
•
•
•
Bestimmt was der Nutzer auf dem Bildschirm sieht.
Interaktionsmöglichkeiten zur Formulierung von Anfragen.
Große Anzahl an Möglichkeiten zur Darstellung von multidimensionalen Daten, z.B.
Pivottabellen, verschiedene Diagramm-Arten, fortgeschrittene Visualisierungen.
Gemeinsam ist allen das zugrunde liegende Schema in Form von Dimensionen,
Measures und Zellen. Auf dieser Basis werden Anfragen an den OLAP-Server
gestellt und von diesem beantwortet.
40
Pentaho – Komponente MONDRIAN
OLAP-Server
2. Schicht: Kalkulationsschicht
•
Parst, validiert und führt MDX-Queries aus.
•
Aus Effizienz-Gründen werden Zellen-Anfragen an die Aggregations-Schicht
gesendet.
•
Ein Query-Transformer erlaubt der Anwendung, jede eingehende Query
umzuschreiben und von Grund auf neue MDX-Statements zu formulieren.
•
Metadaten beschreiben das dimensionale Modell und wie es auf das relationale
Modell gemappt wird („Mondrian-Schema“).
41
Pentaho – Komponente MONDRIAN
OLAP-Server
3. Schicht: Aggregationsschicht
•
Pflegt die Aggregations-Caches.
•
Eine Aggregation ist ein Satz von Measure-Werten (Zellen) im Speicher.
•
Die Kalkulationsschicht prüft zunächst, ob die von ihr benötigten aggregierten Werte
im Cache gehalten werden.
•
Falls Werte nicht im Cache bzw. auch nicht hergeleitet werden können, sendet der
Aggregations-Manager eine Anfrage an die Speicherschicht.
4. Schicht: Speicherschicht
•
Ist ein RDBMS und der Zugriff kann über JDBC erfolgen.
42
Pentaho – Komponente MONDRIAN
OLAP-Server
Zugriff auf Mondrian
•
Mondrian bietet eine proprietäre API an, damit Client-Applikationen Queries
ausführen können.
•
Die Query Language ist MDX (MultiDimensional eXpressions), um Queries zu
spezifizieren.
•
MDX ist in der gleichen Weise eine Anfragesprache für multidimensionale
Datenbanken wie SQL für relationale Datenbanken.
43
Pentaho – Komponente MONDRIAN
OLAP-Server
MDX-Bestandteile
•
•
•
•
•
Measures und Dimensions (analog Fakten und Dimensionen im DWH)
Dimensionen bestehen aus einer Menge von Members (Klassifikationsknoten)
Diese sind in verschiedenen Levels (Klassifikationsstufen)
über Multiple Hierarchien (Klassifikationspfade) miteinander verbunden,
worüber aggregiert werden kann.
MDX-Anfrage (allgemein)
SELECT axis ON COLUMNS,
axis ON ROWS
FROM
cube
WHERE slice
From:
Auswahl des Cubes
Select:
Auswahl Dimensionen u. Klassifikationsstufen
Columns/Rows:
Abbildung auf verschiedene Achsen der
Ergebnis-Tabelle
Slice:
Auswahl innerhalb der Fakten
44
Pentaho – Mondrian Schema
Mondrian Schema
•
Beschreibung der multidimensionalen Zusammenhänge von Daten.
•
Beinhaltet ein logisches Modell, bestehend aus
o
o
o
•
Cubes
Hierarchien
Members
Mappt das logische Modell auf ein physisches.
Logisches Modell
•
Besteht aus den Konstrukten, mit welchen Queries in MDX geschrieben werden:
cubes, dimensions, hierarchies, levels und members.
Physisches Modell
•
ist eine Datenquelle, welche durch das logische Modell repräsentiert wird.
•
Bsp.: Star-Schema oder Snowflake-Schema (Satz von Tabellen in einer relationalen
Datenbank)
45
Pentaho – Mondrian Schema
Schema-Files
•
Mondrian Schema Files werden durch ein XML-File dargestellt.
•
Können „von Hand“ in einem gewöhnlichen Editor erstellt werden.
•
Mit Hilfe des Tools „Pentaho Cube Designer“ wird die Erzeugung dieses Schemas
graphisch unterstützt.
46
Pentaho – Cube Designer
Modellierungswerkzeug
"Cube Designer"
•
Unterstützung beim Design von
OLAP-Anwendungen
•
Wizzard führt Schritt für Schritt
durch den Modellierungs-Vorgang:
Verbindung zum relationalen
Datenbanksystem
Festlegung der analytischen
Dimensionen
Bestimmen von Measures und
Angabe der Fakt-Tabelle
o
o
o
•
Bietet graphische Oberfläche,
keine Programmierung notwendig
47
Pentaho – Cube Designer
•
Erzeugt Mondrian Schema, worauf der Mondrian-OLAP-Server zugreift.
•
Befindet sich noch im Entwicklungs-Prozess
•
Einschränkungen vorhanden
o
Keine geteilten Dimensionen
o
Keine multiplen Hierarchien
o
Keine nachträglichen Änderungen
o
Snowflake-Schema wird nur mangelhaft unterstützt
o
Erzeugt z.T. fehlerhaften Output
o
..
 Nachbearbeitung der erzeugten Solution notwendig.
48
Praktische Vorführung Pentaho
Anwendung Pentaho Cube Designer
•
•
Design eines OLAP-Würfels (Zugriff PostgreSQL)
Erzeugung des Mondrian-Schemas
Anwendung Pentaho BI-Plattform
•
•
Integration des Mondrian-Schemas in die Pentaho-Plattform
Mehrdimensionale Datenanalyse
49
Konkrete Umsetzungen
Datenbankentwurf
•
Aufgezeichnete Daten standen im XML-Format ohne Schema zur Verfügung.
•
Auf dieser Basis und weiteren Anforderungen von ICCAS wurden während der
konzeptionellen Entwurfsphase Objekte, deren Attribute und Beziehungen sowie
entsprechende Kardinalitäten herausgearbeitet.
•
Logischer Entwurf und Umsetzung in das relationale Datenbankschema (Snowflake)
•
Datenbank-Implementierung: PostgreSQL / DB2
•
Datenbankentwurf erfolgte iterativ und wurde schrittweise neuen Erkenntnissen /
Anforderungen angepasst.
50
Konkrete Umsetzungen
Programmierung Übersetzungsroutine
•
SAX-Parser wurde in Java programmiert und jeweils angepasst, um XML-Daten in
entsprechende DB zu transformieren.
ETL-Prozess
•
Basis: Simulationsdaten von OPs im CSV-Format
•
Korrektur fehlerhafter Daten
•
Programmierung Java-Routine zur Transformation und zum Ladevorgang in die DB
Pentaho
•
Installation / Konfiguration Pentaho (z.B. Treiber, Pfade setzen, Probleme mit neuer
jdk-Version, Dateien in falschen Verzeichnissen..)
•
Erstellung/Anpassung von XML-Daten zur JNDI Datenbank-Konfiguration für
Datenbanksysteme PostgreSQL und DB2
•
Einrichtung Remote-Zugang
51
Konkrete Umsetzungen
Cube Designer (CD) und Mondrian Server (MS): Probleme / Lösungen
•
CD unterliegt Einschränkungen und liefert teilweise fehlerhaften Code des
Mondrian-Schemas  Nachbearbeitung notwendig.
•
CD nicht für Snowflake-Schema geeignet. Liefert z.B. ab dritter Hierarchie-Stufe
falschen Code. Lösung: Fehlende Alias-Namen hinzufügen.
•
Ab bestimmten Hierarchie-Ebenen erzeugt CD keine Join-Anweisungen der
Tabellen. Lösung: Fehlende Join-Anweisungen ergänzen.
•
Probleme mit Tabellen bei geteilten Dimensionen (MS). Lösung: Für jede mögliche
Mehrfachnutzung separate Views erzeugen.
52
Konkrete Umsetzungen
•
Verwendung des Datentyps integer anstatt von string bei members führt zu Fehlern
während des SQL-Zugriffs. (Kurzfristige) Lösung: Anpassen des Datentyps.
•
Kleinere Probleme: übernimmt man z.B. die vom CD vorgeschlagene
Standardbezeichnung eines Levelnamens, führt dies zu einem Fehler beim späteren
Zugriff auf die zugrunde liegenden Daten.
Dokumentation
•
Vorgehensweise zur Administration der Pentaho-Plattform und des Cube Designers
zur Solution-Erzeugung auf Basis einer PostgreSQL-Datenbank
•
Hinweise und Lösungen zu Problemen des Cube Designers bzw. des Mondrian
Schemas
53
Fazit
Modellierung
•
Großer Lernerfolg während der Entwicklung des Datenbank-Entwurfs
•
Interessant, sich mit dem Umfeld der Chirurgie auseinanderzusetzen.
•
Abwechslungsreiche Herausforderungen hinsichtlich der Transformation:
Prozesse  OLAP
Pentaho BI-Plattform
•
Einstieg wird durch die schlechte Dokumentation sehr erschwert, jedoch hilfreiche
Community.
•
Sind die vorhandenen Probleme jedoch gelöst, lässt sich mit Pentaho gut arbeiten.
•
OLAP-Server Mondrian stellt einen Großteil der gewünschten Funktionalität zur
Verfügung.
•
Zur Modellierung von größeren OLAP-Würfeln ist die Weiterentwicklung des Cube
Designers wünschenswert.
•
Pentaho ist für das Kennenlernen einer BI-Plattform auf jeden Fall empfehlenswert.
54
Fazit
Allgemein
•
Zusätzlich zum Datenbankentwurf konnten zahlreiche praktische Erfahrungen
gesammelt werden in den Bereichen
•
Anwendung Datenbanksysteme DB2 und PostgreSQL
•
Modellierung von OLAP-Würfeln
•
Anwendung BI-Plattform
•
SAX-Parser Programmierung
•
Betreuung und Unterstützung während des gesamten Praktikums war sehr gut.
•
Projekt-Praktikum machte großen Spaß und findet Fortsetzung in meiner
Masterarbeit.
55
Fragen? Besten Dank für Ihre Aufmerksamkeit.
56