Konzeption und Realisierung eines Data Warehouses zur Analyse chirurgischer Workflows

Transkript

1 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

2 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

3 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

4 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

5 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

6 Datenaufzeichnung Welche Daten werden aufgezeichnet o Globale Daten, wie z.b. Ort Zeit Beteiligte Personen Patient Diagnose Therapie Disziplin Typen von Queries o Quantitative (Vorkommen, Dauer..) Wie oft wurde ein bestimmtes Instrument benutzt? o Qualitative (Beziehungen, Muster..) An welcher Struktur wurde welches Instr. benutzt? o Ergonomische (OP-Einrichtung) Blickrichtung des Chirurgen? o o 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

7 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

8 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

9 Bisheriger Datenfluss XML-Protokoll Aufzeichnungs-Ausschnitte aus dem Protokoll im XML-Format: Allgemeine Informationen einer OP: Informationen einer einzelnen Aktivität: 9

10 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

11 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 Herausschneiden eines Teilwürfels : Erhaltung der Dimensionalität 11

12 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

13 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

14 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

15 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 Entfernung von Blut mit Tupfer o 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

16 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

17 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

18 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

19 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

20 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 Design- Zeit 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

21 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

22 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

23 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

24 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

25 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

26 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

27 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

28 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

29 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

30 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 Daten- Transformationen. 30

31 Pentaho Komponente Reporting Reporting - Eigenschaften Basiert auf JFreeReport (freie Java Reporting Bibliothek) Flexibler Einsatz o Standalone desktop reporting o Interaktives webbasiertes Reporting Zugriff auf unterschiedliche Datenquellen: o Relationale Datenbanksysteme o XML-basierte Datenquellen o OLAP u.a. Zusammenfassung der Daten aus diversen Quellen 31

32 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

33 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

34 Pentaho Komponente Dashboards Interaktive visuelle Displays o Nutzer erkennt sofort, welche Geschäftszahlen im grünen Bereich sind bzw. eine besondere Aufmerksamkeit erfordern. Integration in Pentaho Plattform o Zusammenspiel mit Reporting und Analysis o Steht einer großen Menge von Nutzern zur Verfügung o Integrierte Security, Scheduling Integrierte Alarmierung falls Ausnahmen auftreten sollten. 34

35 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

36 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

37 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

38 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

39 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

40 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

41 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

42 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

43 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

44 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

45 Pentaho Mondrian Schema Mondrian Schema Beschreibung der multidimensionalen Zusammenhänge von Daten. Beinhaltet ein logisches Modell, bestehend aus o Cubes o Hierarchien o 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

46 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

47 Pentaho Cube Designer Modellierungswerkzeug "Cube Designer" Unterstützung beim Design von OLAP-Anwendungen Wizzard führt Schritt für Schritt durch den Modellierungs-Vorgang: o Verbindung zum relationalen Datenbanksystem o Festlegung der analytischen Dimensionen o Bestimmen von Measures und Angabe der Fakt-Tabelle Bietet graphische Oberfläche, keine Programmierung notwendig 47

48 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

49 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

50 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

51 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

52 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

53 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

54 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

55 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

56 Fragen? Besten Dank für Ihre Aufmerksamkeit. 56