Konzeption und Realisierung eines Data Warehouses zur Analyse chirurgischer Workflows

Inhaltsverzeichnis

1 Einführung
1.1 Einleitung
1.1.1 Aufgabenstellung und Zielsetzung
1.1.2 Aufbau dieser Arbeit
1.2 Kooperationspartner Innovation Center for Computer Assisted Surgery (ICCAS)
1.2.1 Vorstellung ICCAS
1.2.2 Workflow-Aufzeichnung
1.2.3 Anwendungsgebiete Analyse chirurgischer Workflows
1.2.3.1 Profiteure der chirurgischen Workflowanalyse
1.2.3.2 Typen möglicher Anfragen
1.2.3.3 Aufgezeichnete Datentypen
1.2.4 Datenfluss Workflow-Aufzeichnung

2 Grundlagen
2.1 Business Intelligence
2.2 Data Warehouse
2.2.1 Der Begriff Data Warehouse
2.2.2 Merkmale eines Data Warehouses
2.2.3 Das Data-Warehouse-System und seine Komponenten
2.2.3.1 Datenquellenebene
2.2.3.2 Datenhaltungsebene (DWH, Data Mart, Daten Ein- u. Ausgabe)
2.2.3.3 Analyseebene
2.2.3.4 Metadaten-Repository, Administration und Monitoring
2.2.3.5 Operational Data Store (ODS)
2.3 Online Analytical Processing
2.3.1 Abgrenzung OLAP versus OLTP
2.3.2 Codd’sche Grundregeln und FASMI-Definition für OLAP-Systeme
2.3.3 Multidimensionales Datenmodell
2.3.3.1 Multidimensionaler Datenwürfel (Cube)
2.3.3.2 Dimensionen und Dimensionshierarchien
2.3.3.3 Fakten
2.3.3.4 Kennzahlen
2.3.4 Standard OLAP-Operationen zur Datenanalyse
2.3.4.1 Roll-up und Drill-down
2.3.4.2 Slice und Dice
2.3.4.3 Pivotierung (Rotation)
2.3.5 Konzeptionelle Modellierung
2.3.5.1 Probleme herkömmlicher Modellierungstechniken beim konzeptionellen Entwurf
2.3.5.2 Vorstellung verschiedener Design-Notationen
2.3.5.3 Grundprinzip des Dimensional Fact Model und dessen Erweiterung
2.3.5.4 Modellbeschreibung mit X -DFM
2.3.6 Umsetzung des Multidimensionalen Datenmodells
2.3.6.1 Relationales OLAP (ROLAP)
2.3.6.2 Multidimensionales OLAP (MOLAP)
2.3.6.3 Hybrides OLAP (HOLAP)
2.4 Business Process Intelligence und chirurgische Workflows
2.4.1 Business Process Intelligence
2.4.2 Konzept der Chirurgischen Workflows

3 Strukturierung chirurgischer Workflows
3.1 Vertikale Strukturierung des Prozesses
3.1.1 Datenerfassungsstrategie
3.1.1.1 Aufgabengetriebene (logische) Strukturierung
3.1.1.2 Statusgetriebene (ereignisbasierte) Strukturierung
3.1.1.3 Einsatz von Aufgaben- bzw. Statusgetriebener Datenerfassung
3.1.2 Granularität der Analyse
3.1.2.1 Workflow-Ebene
3.1.2.2 Intra-Workflow-Ebene
3.2 Horizontale Gliederung des Prozesses
3.3 Erstellung des konzeptionellen Datenmodells
3.3.1 Bereich der Workflow-Ebene
3.3.2 Bereich Intra-Workflow-Ebene

4 Vom Workflow zum Datenwürfel: Herausforderungen und Lösungen
4.1 Phasen der konzeptionellen Modellierung
4.2 Faktschemata ohne Kennzahlen
4.2.1 Fakt-Identifikator
4.2.2 Kennzahlen dynamisch erzeugen
4.3 Entwicklung der grundlegenden Faktschemata
4.3.1 Ausgangslage
4.3.2 Fakt-Generalisierung
4.3.3 Modellierung von Satelliten-Fakttypen
4.3.4 Fakt-Hierarchie
4.4 Auflösung von „viele-zu-viele“-Beziehungen zwischen Fakten und Dimensionen
4.4.1 Ausgangslage
4.4.2 Das Problem und die Lösung
4.5 Austauschbarkeit von Fakt- und Dimensionsrollen
4.5.1 Ausgangslage
4.5.2 Das Problem und die Lösung
4.6 Austauschbarkeit von Kennzahl- und Dimensionsrollen
4.6.1 Ausgangslage
4.6.2 Das Problem und die Lösung
4.6.3 Realisierung Kennzahlspezifikation zur Laufzeit
4.7 Modellierung von Dimensionshierarchien
4.7.1 Typen von Hierarchien
4.7.2 Abgeleitete Kategorien und abgeleitete Dimensionen
4.7.3 Arten von gemeinsamen Dimensionen
4.7.3.1 Vollständige Dimensionsteilung
4.7.3.2 Eingeschlossene Dimension
4.7.3.3 Partielle Dimensionsteilung

5 Umsetzung des multidimensionalen Datenmodells
5.1 Abbildung des multidimensionalen Modells auf das relationale Modell
5.1.1 Abbildung von Fakttypen
5.1.2 Abbildung von Dimensionshierarchien
5.1.3 Auflösung der Dualität zwischen Fakten und Dimensionen
5.1.4 Abbildung von generalisierten Fakttypen
5.2 Datenimport

6 Business Intelligence Suite Pentaho
6.1 Einleitung
6.2 Modularer Aufbau und Anwendungsbereiche von Pentaho
6.3 Komponenten von Pentaho
6.3.1 BI-Plattform und Action Sequenzen
6.3.2 Pentaho BI-Server und dessen Architektur
6.3.3 Data Mining (WEKA)
6.3.4 Pentaho Data Integration (alias KETTLE)
6.3.5 Pentaho Dashboards
6.3.6 Reporting (JfreeReport)
6.4 Datenanalyse mit Pentaho
6.4.1 OLAP-Server Mondrian
6.4.2 JPivot OLAP-Frontend
6.4.3 Architektur des Analysemoduls von Pentaho
6.5 Konfigurationsdatei Mondrian Schema
6.6 Modellierungstool Cube Designer und Schema Workbench
6.7 Der Weg zur Pentaho-Lösung
6.7.1 Systemumgebung
6.7.2 Vorbereitung Pentaho PCI / PostgreSQL
6.7.3 Entwicklung einer Pentaho Solution mit dem Cube Designer
6.7.3.1 Verbindung zur relationalen Datenbank
6.7.3.2 Definition der Kennzahlen
6.7.3.3 Definition analytischer Dimensionen und Hierarchien
6.7.3.4 Veröffentlichung des Schemas für den Pentaho Server
6.8 Probleme mit dem Mondrian Server und dem Cube Designer

7 Anwendungsfälle
7.1 Verlauf einer bestimmten Operation nachvollziehen
7.2 Vergleich bestimmter Kennzahlen verschiedener Operationen
7.3 Analyse der Nutzungsarten bestimmter Instrumente
7.4 Erfassung mehrerer Workflows zur Qualitätssicherung

8 Zusammenfassung und Ausblick

9 Literaturverzeichnis

10 Anhang: Administration von Pentaho

Abbildungsverzeichnis

Abbildung 1-1 Protokollant während einer Aufzeichnung

Abbildung 1-2 Vielzahl möglicher Fragestellungen an den chirurgischen Workflow

Abbildung 1-3 Ausschnitte XML-Protokoll einer Workflow-Aufzeichnung

Abbildung 1-4 Darstellung des Datenflusses einer chirurgischen Workflow-Aufzeichnung

Abbildung 2-1 Unterschiedliche Facetten von Business Intelligence

Abbildung 2-2 Data-Warehouse-Architektur

Abbildung 2-3 Darstellung eines multidimensionalen Datenwürfels

Abbildung 2-4 Beispielstruktur einer Dimension im multidimensionalen Modell

Abbildung 2-5 Klassifikationsschema und Klassifikationshierarchie der Dimension "Einweisungsstruktur"

Abbildung 2-6 OLAP-Funktionen Roll-up und Drill-down

Abbildung 2-7 OLAP-Funktion Slice

Abbildung 2-8 OLAP-Funktion Pivotierung (Rotation)

Abbildung 2-9 Ein 3-dimensionales Faktschema HOSPITALIZATION in X-DFM-Notation

Abbildung 2-10 Star-Schema

Abbildung 2-11 Snowflake-Schema

Abbildung 2-12 Galaxy-Schema

Abbildung 3-1 Vertikale Struktur: Einordnung chirurgischer Prozess (feine Granularität)

Abbildung 3-2 Vertikale Struktur: Einordnung chirurgischer Prozess (hohe Granularität)

Abbildung 3-3 Wichtige Aspekte eines Prozesses

Abbildung 3-4 Darstellung eines Modells zur Erfassung chirurgische Prozesse als E/R-Diagramm

Abbildung 4-1 Nichtmessbare Faktschemata: Typ "event-tracking" (links) und Typ "coverage" (rechts)

Abbildung 4-2 Faktschema-Kandidaten: SURGERY und WORKFLOW

Abbildung 4-3 Faktkandidaten: Workflow-Komponenten ACTIVITY, STATE und EVENT

Abbildung 4-4 Einführung der Fakt-Generalisierung durch COMPONENT

Abbildung 4-5 Auflösung von M:N-Beziehungen zwischen Fakten und Dimensionen in Satelliten-Fakten

Abbildung 4-6 Übersicht der grundlegenden Fakttypen und ihre Beziehungen zueinander

Abbildung 4-7 Klassische 1:N-Beziehung zwischen einer Faktentabelle und ihren Dimensionstabellen

Abbildung 4-8 Problematische M:N-Beziehung zwischen einer Faktentabelle und ihren Dimensionstabellen

Abbildung 4-9 Extraktion von M:N-Beziehungen in Satelliten- (Brücken-) Fakten

Abbildung 4-10 Faktschema SURGERY: Isolierte Sichtweise

Abbildung 4-11 Faktschema SURGERY (links) nimmt die Rolle einer Dimension (rechts) ein

Abbildung 4-12 Transformation des Faktschemas SURGERY durch Anwendung des PUSH-Operators

Abbildung 4-13 Interaktive Definition einer neuen Kennzahl durch PUSH-Operation

Abbildung 4-14 Navigation in einem OLAP-Würfel

Abbildung 4-15 Faktschema mit verschiedenen Hierarchietypen

Abbildung 4-16 Faktschema mit multiplen Hierarchien

Abbildung 4-17 Faktschema mit abgeleiteter Dimension

Abbildung 4-18 Faktschema mit gemeinsamen Dimensionskategorien

Abbildung 4-19 Multidimensionales Schema zur Erfassung chirurgischer Workflows

Abbildung 5-1 Multidimensionales Fragment in X-DFM-Notation

Abbildung 5-2 Fakten- und Dimensionstabellen nach der logischen Abbildung

Abbildung 5-3 Implementierung einer Generalisierung

Abbildung 6-1 Anwendungsgebiete Pentaho BI Suite

Abbildung 6-2 BI-Server mit verschiedenen Engines

Abbildung 6-3 WEKA: Data-Mining als Prozess

Abbildung 6-4 Modellierung eines Datenflusses mit Spoon

Abbildung 6-5 Darstellung eines Dashboards

Abbildung 6-6 Darstellung eines Berichtes

Abbildung 6-7 Ausschnitt: In Würfeln navigieren und Analysen anzeigen

Abbildung 6-8 Ausschnitt JPivot-Tabelle mit einem Drill-down in die Dimension Ort

Abbildung 6-9 Architektur und Arbeitsweise ausgewählter Komponenten von Pentaho

Abbildung 6-10 Datenbankfragment: Fakt Surgery mit Dimensionen patient und room

Abbildung 6-11 Faktentabelle surgery mit Dimensionen patient und room

Abbildung 6-12 Ausschnitt Startbildschirm der Analyse

Abbildung 6-13 Analyse mit Attribut patient_sex und erfolgtem Drill-down in dim_location

Abbildung 6-14 Schema Workbench

Abbildung 6-15 Erzeugung einer JNDI-Verbindung zur PostgreSQL-Datenbank

Abbildung 6-16 Auswahl notwendiger Tabellen und Attribute

Abbildung 6-17 Erzeugung von Dimensionen und Hierarchiestufen

Abbildung 6-18 Darstellung der modellierten Pentaho Solution durch JPivot

Abbildung 7-1 Zeitlicher Ablauf durchgeführter Arbeitsschritte einer bestimmten OP

Abbildung 7-2 Vergleich dreier OPs hinsichtlich durchgeführter Aktivitäten auf aggregierter Ebene

Abbildung 7-3 Statistik zur Verwendung von Instrumenten als Pivot-Tabelle

Abbildung 7-4 Balkendiagramm zeigt Verwendungsstatistik eines Shavers

Abbildung 7-5 Vergleich der erfassten Aktivitäten verschiedener Workflows zur gleichen OP

Listingverzeichnis

Listing 1 Anfrage gegen ein Snowflake-Schema

Listing 2 Anfrage gegen ein Star-Schema

Listing 3 Ausschnitt XML-Datei Mondrian Schema

Listing 4 Dimension dim_patient

Listing 5 Dimension dim_location

Listing 6 MDX-Anfrage an den Mondrian OLAP-Server

Listing 7 SQL-Anfrage wird auf das DWH abgesetzt

Listing 8 SQL-Befehl zur Statistik über die Instrumentenverwendun

1 Einführung

1.1 Einleitung

Die Einsatzfelder der Data-Warehouse-Technologie sind weit gestreut und reichen von betriebswirtschaftlichen Aufgabenstellungen über wissenschaftliche Analysen bis hin zu technischen Belangen, wobei die Analyse von Geschäftsprozessen in Unternehmen den häufigsten Einsatzbereich darstellt.

Eine wachsende Zahl von Unternehmen integrieren und automatisieren ihre Geschäftsprozesse und verfolgen dabei das Ziel, dass sie neben der Effizienzsteigerung und der Verbesserung der Qualität auch eine Reduktion der Kosten sowie der menschlichen Fehlleistungen erreichen. In diesem Zusammenhang werden Geschäftsprozess-managementsysteme (Business Process Management System, BPMS) eingesetzt, um das Prozessdesign und die Prozessausführung zu optimieren. Dabei nehmen diese Systeme große Datenmengen über die ausgeführten Geschäftsprozesse auf. Herkömmliche BPMS setzen ihren Schwerpunkt auf die Unterstützung des Designs und führen Simulationen durch, um Engpässe in den Abläufen zu identifizieren. Dabei spielen nach [Dayal/Hsu/Ladin 2001] Analysefähigkeiten, um Durchführungen hinsichtlich bestimmter Geschäftsmetriken zu quantifizieren, kaum eine Rolle. Auch wurden die zugrunde liegenden Geschäftsprozessmodelle nicht dafür entworfen, diese Art der Analyse von Prozessdaten zu unterstützen. Allerdings können diese Möglichkeiten der Datenanalyse einen wesentlichen Beitrag dazu leisten, notwendige Informationen im Verlauf von Entscheidungsprozessen zur Verfügung zu stellen.

Aus diesem Hintergrund heraus entwickelt sich gegenwärtig das neue Gebiet Business Process Intelligence. Dieses überwindet die Defizite solcher Standard-BPMS durch die Anwendung von Analysetechniken aus dem Business-Intelligence-Umfeld auf Geschäftsprozesse. So erfolgt z.B. die Speicherung der Prozessausführungsdaten in einem DWH, worauf eine Analyse mit OLAP- bzw. Data-Mining-Anwendungen möglich ist, bzw. Wissensextraktionen in verschiedenen Bereichen durchgeführt werden können.

Diese Problematik lässt sich auch auf die medizinische Domäne übertragen. So entwickelt sich zur Zeit im Umfeld der Medizintechnik das vielversprechende Konzept der Chirurgischen Workflows. Dabei handelt es sich um die intelligente Erfassung von Prozessbeschreibungen chirurgischer Eingriffe, um auf deren Basis sowohl klinische wie auch technische Analysen zu ermöglichen. Wurden bereits im Vorfeld vom ICCAS der Einsatz verschiedener BPMS untersucht und in dieser Domäne für nicht zweckmäßig befunden, hat diese Arbeit zur Aufgabe, ein Modell zur Erfassung chirurgischer Workflows in Form eines Data Warehouses zu konzipieren, auf dessen Grundlage eine multidimensionale Datenanalyse chirurgischer Eingriffe erfolgen kann.

Diese Arbeit lieferte auch einen Beitrag zu einem Buchkapitel über konzeptionelles Data-Warehouse-Design für Business Process Intelligence [Mansmann et al. 2008].

1.1.1 Aufgabenstellung und Zielsetzung

Die Zielsetzung dieser Arbeit besteht in erster Linie darin, ein multidimensionales Datenmodell zu konzipieren, welches in der geforderten Art und Weise die Charakteristiken von chirurgischen Eingriffen erfassen und abbilden kann, um so eine Datenbasis zur Verfügung stellen zu können, worauf die Analyse der chirurgischen Workflows erfolgt.

Zunächst sind daher die Anforderungen zu klären, welche die späteren Anwender an das Data Warehouse hinsichtlich möglicher Fragestellungen bzw. einzusetzender Analyseverfahren stellen. Auf dieser Grundlage muss eine Strukturierung der chirurgischen Prozesse erfolgen, um eine geeignete Gestaltung des Aufzeichnungsschemas ableiten zu können. So stellt sich z.B. die Frage nach der Granularität der Analyse oder aus welchen Perspektiven die Workflows später zu analysieren sind. Des Weiteren ist die Datenerfassungsstrategie festzulegen. Die Modellierung der Fakt- und Dimensionsschemata muss in einer geeigneten Weise erfolgen (durch sie wird die Transformation der Workflows in den Datenwürfel vorgegeben) und wo nötig das standardmäßige multidimensionale Modell angepasst bzw. erweitert werden, um den unterschiedlichen Anforderungen der späteren Anwender gerecht werden zu können. Nach der konzeptionellen Phase der multidimensionalen Datenmodellierung erfolgt die Realisierung des entstandenen Modells auf Grundlage eines relationalen OLAP-Systems. Auf diesem System findet im Zusammenspiel mit der Business Intelligence Suite Pentaho eine OLAP-Analyse der chirurgischen Workflows statt. Zu deren Durchführung müssen die Workflow-Daten in die Datenbank geladen, Pentaho entsprechend konfiguriert und die gewünschten OLAP-Würfel modelliert werden.

1.1.2 Aufbau dieser Arbeit

Im ersten Kapitel wird die im Rahmen dieser Masterarbeit behandelte Anwendung sowie der Kooperationspartner Innovation Center Computer Assisted Surgery (ICCAS) vorgestellt. Es werden die zu analysierenden Daten beschrieben und die Anwendungsgebiete der Analyse chirurgischer Workflows aufgezeigt.

Das zweite Kapitel liefert die Grundlagen zum Thema Business Intelligence (BI), Data Warehouse (DWH), multidimensionales Datenmodell und Online Analytical Processing (OLAP) sowie Business Process Intelligence (BPI). Insbesondere die Themen DWH und OLAP werden ausführlich behandelt, um auch dem auf diesem Gebiet unerfahrenen Leser ein grundlegendes Verständnis zu ermöglichen; Leser, welche bereits Kenntnisse auf diesem Gebiet besitzen, können durch dieses Kapitel ihre Kenntnisse auffrischen oder es überspringen.

Das dritte Kapitel stellt dar, wie man chirurgische Workflows strukturieren kann und geht dabei auf die umgesetzte Erfassungsstrategie sowie die Granularität der Analyse ein. Als Ergebnis wird auf konzeptioneller Ebene ein Modell zur Erfassung chirurgischer Workflows in Form eines E/R-Diagramms geliefert.

Im vierten Kapitel erfolgt die Transformation des Workflow in eine Datenwürfeldarstellung. Dabei werden die Herausforderungen und Lösungen aufgezeigt, welche die Transformation vom Workflow zum Datenwürfel mit sich bringt. Aufbauend auf den Erkenntnissen des dritten Kapitels erfolgt hier nun die Modellierung eines dimensionalen Fakt-Modells.

Kapitel fünf beschreibt die logische und physische Umsetzung des dimensionalen Fakt-Modells. Dabei werden die eingesetzten Erweiterungen des Galaxy-Schemas dargestellt. Ein weiteres Thema ist der durchgeführte ETL-Prozess der zu analysierenden Daten.

Das Kapitel sechs gibt zunächst einen allgemeinen Überblick über die Business Intelligence Suite Pentaho, auf welcher das DWH realisiert wurde und auch die OLAP-Analyse erfolgt. Im ersten Teil werden der Aufbau und die Anwendungsgebiete von Pentaho gezeigt und die verfügbaren Komponenten kurz vorgestellt, wobei der Fokus auf den OLAP-Server Mondrian gerichtet ist. Im zweiten Teil erfolgt eine Beschreibung der Konfigurationsdatei des Mondrian Schemas, welches den OLAP-Würfel abbildet und den Zugriff auf die Datenbank während der Analyse regelt. Zudem wird das Vorgehen gezeigt, wie mit Hilfe eines Modellierungstools ein OLAP-Würfel erstellt und zur Analyse in die Pentaho Suite integriert wird.

In Kapitel sieben werden beispielhaft Anwendungsfälle aus dem OLAP-Bereich der Analyse chirurgischer Workflows gezeigt. Das Kapitel acht enthält eine kurze Zusammenfassung und schließt mit einem Ausblick.

1.2 Kooperationspartner Innovation Center for Computer Assisted Surgery (ICCAS)

1.2.1 Vorstellung ICCAS

Das vom Bundesministerium für Bildung und Forschung (BMBF) geförderte ICCAS^[1] befasst sich mit der Entwicklung und Umsetzung eines strategischen Konzepts für die zukünftige Gestaltung der computerassistierten Chirurgie und ist der Medizinischen Fakultät der Universität Leipzig zugeordnet (s.a. [ICCAS 2006; ICCAS 2007]). Bei dieser interdisziplinären Forschungsarbeit, welche in verschiedene Forschungsgruppen gegliedert ist, arbeiten Informatiker, Mediziner und Ingenieure eng mit Kliniken der Hals-Nasen-Ohren-, Herz- und Neurochirurgie zusammen. Hierbei wird die Vision einer möglichst perfekten Mensch-Maschine-Zusammenarbeit verfolgt, mit dem Ziel, dem Chirurgen die bestmögliche Unterstützung beim Operieren seines Patienten anzubieten.

Themen der Forschungsgruppe „Wissenschaftliche Methodik“ sind die Entwicklung einer Aufnahme- u. Analysemethodik für die Chirurgischen Workflows sowie deren Nutzung, um chirurgische Eingriffe im Detail zu analysieren und zu bewerten. Dieser Entwicklungsprozess umfasst die Schwerpunkte ontologische Strukturierung, chirurgische Prozesse, Datenakquisition sowie Datenvisualisierung und -analyse. Ein Bereich dieser Forschungstätigkeit konzentriert sich auf die Analyse von chirurgischen Prozessen anhand von chirurgischen Arbeitsabläufen, die es ermöglichen, chirurgische Eingriffe im Detail zu bewerten. Die aufgenommenen Vorgänge werden formal durch Ontologien^[2] und chirurgische Workflows^[3] beschrieben und bilden die Grundlage für die Entwicklung zukünftiger computerassistierter chirurgischer Komponenten. Darüber hinaus werden computerassistierte Systeme und deren Wirkung auf Patienten, Chirurgen und Kosten systematisch bewertet. Evaluiert werden die technischen, psychologisch-wissenschaftlichen und wirtschaftlichen Aspekte.

Besonders hervorzuheben ist hierbei nach [Adams 2005] die methodische Vorgehensweise des ICCAS. Wurde bisher computergestützte Technik angeboten und der Chirurg konnte sie nutzen oder auch nicht (dies führte im Ergebnis auch zu teuren Fehlentwicklungen), stellt das ICCAS das Verfahren auf den Kopf, indem nun das tatsächliche Handeln des Chirurgen die Grundlage für die Entwicklung technischer Systeme ist. Hierzu werden, ausgehend von der exakten Analyse und Erfassung jedes einzelnen chirurgischen Handgriffs, computergestützte Operationssysteme entwickelt. So wird sichergestellt, dass nur das tatsächlich benötigte entwickelt wird.

Der folgende Abschnitt 1.2.2 beschreibt, wie die Daten, welche die Vorgänge im Operationssaal beschreiben, aufgenommen werden.

1.2.2 Workflow-Aufzeichnung

Im Operationssaal erfasst ein Protokollant, dabei handelt es sich um speziell geschulte Medizinstudenten, den detaillierten Verlauf der Operation, wobei die einzelnen Schritte vom Operateur sowie vom instrumentierenden Personal jeweils kommentiert werden.

Die Datenaufzeichnung kann direkt während einer laufenden Operation erfolgen oder im Anschluss daran auf Basis von Videoaufnahmen, welche den Verlauf der Operation aufzeichneten. Zur Protokollierung der chirurgischen Eingriffe steht dem Beobachter, wie in Abbildung 1-1 gezeigt, ein portabler Tablet-PC mit einem Touchscreen-Bildschirm zur Verfügung, worauf ein von der ICCAS entwickelter graphischer Workflow-Editor in Form einer Web-Anwendung läuft.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1-1 Protokollant während einer Aufzeichnung.^[4]

Die Software lässt sich durch die zugrunde liegende Ontologie, welche über eine Web-Datenbank geladen wird, auf die jeweiligen Anforderungen der unterschiedlichen Eingriffe anpassen. Vor Aufnahme der eigentlichen Operation werden allgemeine Daten über den Eingriff aufgenommen (vgl. Abschnitt 3.1.2.1). Während oder nach der OP werden die ausgeführten intraoperativen Aktivitäten hinsichtlich Start- und Endzeitpunkt sekundengenau erfasst. Über die GUI (Graphical User Interface) des Workflow-Editors wählt der Protokollant dann aus den entsprechenden Listen die Punkte aus, mit denen eine durchgeführte Aktivität beschrieben wird (vgl. Abschnitt 3.1.2.2). Hierzu gehören beispielsweise die beteiligten Personen (Chirurg/Assistent), die Bezeichnung der ausgeführten Aktion, mit welcher Hand sie ausgeführt wurde, die benutzten Instrumente, sowie der behandelte Körperteil des Patienten. Dieses Vorgehen wiederholt sich so für jede einzelne Aktivität. Auch parallel ablaufende bzw. sich überschneidende Aktivitäten werden so erfasst.

Um eine möglichst hohe Datenqualität der aufgezeichneten Daten zu gewährleisten, hat der Protokollant die Möglichkeit, auch nach der OP die Daten (z.B. mit Unterstützung der Video-Aufzeichnung) nachzubearbeiten.

1.2.3 Anwendungsgebiete Analyse chirurgischer Workflows

Die möglichen Anwendungsgebiete der Analyse chirurgischer Workflows sind vielfältig und umfassen ganz verschiedene Bereiche. Diese reichen von der Unterstützung der Planung im Vorfeld durchzuführender Operationen über die klinischen sowie technischen Analysen bis hin zur medizinischen Lehre. Zudem können Daten über die Verwendung von chirurgischen Instrumenten bzw. Assistenzsystemen ausgewertet oder auch Nutzungsanalysen von OP-Sälen durchgeführt werden. Nachfolgend werden einige generelle Anwendungsgebiete nach [Burgert 2007; Neumuth et al. 2006a] stichwortartig dargestellt:

- Voroperative Planung: Untersuchung vorausgegangener Referenzfälle, um die chirurgische Vorbereitung zu unterstützen.
- OP-Evaluierung: Suchen von Optimierungspotential hinsichtlich OP-Verfahren,-Bestecke und -Geräte. Vergleich verschiedener Strategien, Analyse der OP nach Assistenzbedarf und einer objektiven Effizienzbetrachtung der eingesetzten Ressourcen.
- Klinische Dokumentation: Nutzungsanalyse von Operationssälen, Verwendung von chirurgischenInstrumenten / mechatronischen Assistenzsystemen.
- Wissensextraktion und Formalisierung von chirurgischem Know-how.
- Instrument für den Vergleich von chirurgischen Schulen sowie zur Qualitätssicherung .
- Verifizierung von medizinischen Hypothesen: Die Workflowanalyse wird als Instrument zur Evaluation von chirurgischen Techniken und Instrumentarien verwendet.
- Ableitung und Evaluierung von chirurgischen Assistenz-Systemen.
- Bewertung des OP-Saal-Layouts: Durch die Analyse des intraoperativen Geräteeinsatzes können Anforderungsprofile für zukünftige OP-Säle abgeleitet werden und somit zu ergonomischen Verbesserungen führen.
- Bewertung der operativen Leistungen und chirurgischen Fähigkeiten .
- Verbesserung der chirurgischen Ausbildung und von Simulationssystemen.

Workflowanalysen sind wertvolle Hilfsmittel zur Analyse chirurgischer Techniken und können an unterschiedliche Fragestellungen angepasst werden. Durch eine detaillierte Aufnahme der Workflows werden auch Auswertungen nach vorher nicht definierten Kriterien ermöglicht^[5]. Aus den genannten Anwendungsgebieten ergeben sich eine Reihe von Profiteuren der chirurgischen Workflowanalyse.

1.2.3.1 Profiteure der chirurgischen Workflowanalyse

Hierzu gehören in erster Linie die Patienten selbst (z.B. durch eine verkürzte Dauer der operativen Eingriffszeit) sowie die behandelnden Chirurgen. Aber auch die Geldgeber sowie die Klinikbetreiber (z.B. Einsparungen infolge kürzerer Liegezeiten) ziehen einen Nutzen daraus. Medizinstudenten kommen die Ergebnisse der Analysen in der Lehre zugute und es können bessere Simulationssysteme betrieben werden. Nicht zuletzt stellt die Analyse für Hersteller medizinischer Geräte bzw. Medizintechniker eine wesentliche Grundlage dar, um ihre Geräte zu entwickeln und den zukünftigen tatsächlichen Nutzen durch konkretes Zahlenmaterial untermauern zu können.

1.2.3.2 Typen möglicher Anfragen

Aus dem weit gefächerten Bereich potentieller Anwendungen der Analyse chirurgischer Workflows ergeben sich eine ganze Reihe unterschiedlich zu erwartender Typen von Anfragen, welche an das DWH gestellt werden können. Neben klinischen Fragestellungen (z.B. Auslastung der OP-Säle) lassen sich mögliche chirurgische Fragestellungen nach [Burgert 2007; Neumuth et al. 2006a] folgenden Hauptkategorien zuordnen:

- Quantitative Anfragen

behandeln sogenannte Performance-Indikatoren und andere Messungen, wie z.B.Vorkommen, Häufigkeit, Dauer, Vorhandensein verschiedener Ereignisse oderObjekte.

Bsp.: Wie oft wurde ein bestimmtes Instrument benutzt? Wie viel Zeit wurde füreine bestimmte Technik benötigt? Wie viele Instrumentenwechsel erfolgtenwährend eines bestimmten Eingriffs?

- Qualitative Anfragen

zielen darauf ab, Beziehungen, Muster, Trends oder andere Arten von zusätzlichemWissen in den Daten zu entdecken bzw. abzuleiten.

Bsp.: An welchen anatomischen Strukturen wird mit Instrument X gearbeitet?Wasist die typische Prozedur für Eingriff Y? Ergibt sich durch die Verwendung einesmechatronischen Assistenzsystems eine Zeitersparnis?

- Ergonomische Anfragen

bewerten die Gestaltung des Arbeitsbereiches, ergonomische Einschränkungen,Positionen und Ausrichtungen der beteiligten Personen und Gegenstände(Apparate).

Bsp.: Welche Blickrichtung hat der Chirurg? Gibt es ergonomischeEinschränkungen?

- Kognitive Anfragen

versuchen Themen wie Nutzen, Relevanz, Zufriedenheit etc. zu beurteilen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1-2 Vielzahl möglicher Fragestellungen an den chirurgischen Workflow.^[6]

Hier wird deutlich, dass es nicht möglich bzw. zweckmäßig ist, bereits im Vorfeld der Datenanalyse festzulegen, welche Anfragen später genau an das DWH zu stellen sind, da eine unbekannte Anzahl und Art von Fragestellungen an den chirurgischen Workflow zu erwarten sind. Dem Anwender des DWH muss es also möglich sein, erst während der Analyse die Kennzahlen, auf welche die einzelnen Anfragen abzielen, festzulegen.

1.2.3.3 Aufgezeichnete Datentypen

Um später eine möglichst breite Datenbasis zu besitzen, worauf analytische Auswertungen ausgeführt werden können, werden u.a. die nachfolgenden Daten aufgenommen. Diese stellen nicht die vollständig aufgezeichneten Daten dar. Sie sollen lediglich dem Leser die wesentlichen Bereiche der Datenerfassung aufzeigen (und werden in Kapitel 1 ausführlich behandelt). Die aufgezeichneten Daten lassen sich nach [Neumuth et al. 2006a] in die beiden Hauptebenen Workflow und Intra-Workflow (vgl. Abschnitt 3.1.2) gliedern:

Datenerfassung Workflow-Ebene: Diese Daten erfassen den Kontext der durchgeführten Operation, betrachten also den chirurgischen Eingriff als Ganzes. Hierzu gehören z.B. Informationen über den Ort und die Zeit des Eingriffs, die agierenden Personen, der Patient, die chirurgische Disziplin sowie die entsprechende Diagnose und Therapie (vgl. Abschnitt 3.3.1).

Datenerfassung Intra-Workflow-Ebene: Diese Daten gehören zu einer feineren Granularitätsstufe und werden während des Verlaufes einer einzelnen OP aufgenommen. Dabei beziehen sie sich auf die Eigenschaften der verschiedenen Prozesskomponenten wie z.B. Aktivitäten, Ereignisse und Status (vgl. Abschnitte 3.1.1 und 3.3.2).

Für den Bereich Aktivitäten , welcher die einzelnen Arbeitsschritte beschreibt, werden u.a. Daten aufgezeichnet, womit sich z.B. folgende Frage für jede Aktivität beantworten lässt: Welche Aktion wurde von welcher Person, an welchem Körperteil, mit welchem OP-Besteck, von wann bis wann, in welcher Phase der OP und mit welchem aktiven Körperteil (z.B. rechter/linker Arm) durchgeführt?

Das Konzept Status wird eingesetzt, um die Statusänderungen unterschiedlicher Subsysteme (z.B. Apparat, Chirurg) darstellen zu können. Hierzu werden Daten gespeichert, die den Status sowie die entsprechenden Werte beschreiben, welches Subsystem betroffen war und wann eine Änderung des Status erfolgte.

Beim Konzept Ereignis handelt es sich um ein verwandtes Konzept. Dabei werden vordefinierte Ereignisse (z.B. Meldung eines Assistenzsystems, Anweisung eines Chirurgen) betrachtet, welche während der OP auftreten. Diese sind im Gegensatz zum Status nicht an ein Subsystem gebunden und können also unabhängig auftreten. Um Ereignisse zu beschreiben, werden u.a. die Bezeichnung des Ereignisses, die Zugehörigkeit zu einer Disziplin und zu einem übergeordneten Eventtyp, die entsprechenden Ereignisdaten (z.B. Meldung eines Apparates) sowie dessen Eintrittszeitpunkt aufgenommen.

Um das Zusammenspiel dieser Konzepte zu ermöglichen (um Fragen beantworten zu können, wie z.B.: „Welches Ereignis hat einen bestimmten Statuswechsel verursacht?“), werden auch die Beziehungen untereinander aufgenommen.

1.2.4 Datenfluss Workflow-Aufzeichnung

Dieser Abschnitt beschreibt den Datenfluss während einer Workflow-Aufzeichnung und geht dabei auch auf die Änderungen ein, die sich durch die Einführung des Data Warehouses ergeben. Das bisherige Erfassungsschema wird durch ein neues Schema ersetzt, womit eine multidimensionale Datenanalyse ermöglich wird.

Vor der Nutzung des DWH erfolgte die Speicherung des chirurgischen Workflows in Form eines Protokolls im XML-Format wie unter Abbildung 1-3 ausschnittsweise gezeigt wird [Neumuth et al. 2006b]. Auf der linken Seite werden die „globale Daten“ und auf der rechten eine einzelne Aktivität gezeigt (vgl. Abschnitt 3.1.2):

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1-3 Ausschnitte XML-Protokoll einer Workflow-Aufzeichnung.

Da das Aufnahmeschema nach [Neumuth et al. 2006a] während seiner Entwicklung vom ICCAS häufigen Anpassungen unterlag, wurde es in Form eines XML-Schemas realisiert, auf dessen Basis als Ergebnis der Erfassung des Workflows ein XML-Protokoll generiert wurde. Dies hatte u.a. den Vorteil, dass man es leicht an geänderte Aufnahmeschemas anpassen konnte. Auch werden die Vereinfachung der Entwicklung von Transformationen, die Transformationsfähigkeit und das Wissensmanagement vom ICCAS genannt.

Durch die Einführung des neu entwickelten Datenmodells für das Data Warehouse, welches nun eine multidimensionale Datenanalyse ermöglicht und die Basis für weitere Anwendungen darstellt, wurde zum einen das bisher verwendete Erfassungsschema ersetzt und zum anderen erfolgt die Datenhaltung nun nicht mehr in Form von XML-Protokollen, sondern die aufgenommenen Daten werden in das DWH überführt.

Nachfolgende Abbildung 1-4 skizziert den Datenfluss der Workflow-Aufzeichnung. Die anschließenden Erläuterungen gehen darauf ein und zeigen auch die Änderungen, welche sich zwischen dem alten und dem neuen Datenfluss ergeben:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1-4 Darstellung des Datenflusses einer chirurgischen Workflow-Aufzeichnung.^[7]

Vor Beginn der eigentlichen Aufzeichnung erfolgt die Anpassung des ICCAS Workflow-Editors an die jeweils durchgeführte OP. Hierzu werden zunächst in der Vorbereitungsphase aus einer online erreichbaren Ontologie-Datenbank aus einem Glossar die speziell bei diesem Eingriff zu erwartenden Bezeichnungen in den Workflow-Editor geladen. Diese beschreiben z.B. bestimmte Instrumente, Aktionen oder Körperstrukturen. Damit wird eine einheitliche Beschreibung der ausgeführten Aktivitäten gewährleistet, die auch eine Erleichterung für den Protokollanten darstellt, da er auf diese Weise nur die wirklich benötigten Fachbegriffe aus einer Liste auswählen kann, welche während der OP auch tatsächlich auftreten können.

Des Weiteren wird das definierte Erfassungsschema in Form eines XML-Schemas (welches durch die Einführung des DWH entsprechend neu konzipiert wurde) in den Workflow-Editor geladen. Nun erfolgt die eigentliche Aufzeichnung der OP-Daten. Diese wird während der OP oder im Anschluss daran, auf Basis von mitgeschnittenen Video-Sequenzen, durchgeführt.

Nach Beendigung der Aufzeichnung durch den Workflow-Editor wird der Workflow in Form eines XML-Protokolls gespeichert. Um dem Protokollanten die Möglichkeit eines Reviews seiner Aufzeichnung zu geben und somit nachträgliche Korrekturen zu ermöglichen, steht hierfür ein Tool zur Verfügung. Im nächsten Schritt erfolgt eine Versionierung und es können weitere Anpassungen vorgenommen werden, bevor die Endversion des XML-Protokolls generiert wird. Ab diesem Punkt ergibt sich durch die Einführung des DWH eine Änderung des Datenflusses.

Vor der Verwendung des DWH wurde das XML-Protokoll in einer Workflow-Datenbank abgelegt. Innerhalb dieser Datenbasis, in welcher die XML-Dateien also bisher gespeichert wurden, konnten Transformationen durchgeführt und so an weitere Anwendungen, wie z.B. Visualisierungs- oder Reporting-Tools, weitergegeben werden.

Nach der Einführung des DWH werden die Daten durch den ETL-Prozess (vgl. Abschnitt2.2.3.2.1) in das DWH geladen. Hierzu werden die Daten des Workflow-Editors in einem ersten Schritt extrahiert und in eine relationale DB überführt. Dabei verbleiben die aufgenommenen Daten des Workflows zunächst in dieser Datenbank, welche dem Arbeitsbereich^[8] (Staging Area) des DWH zugeordnet ist. In dieser Phase kann der Protokollant nachträglich Anpassungen seiner Aufzeichnungen vornehmen und die Daten bereinigen. Auch können durchaus mehrere verschiedene Workflows, welche die gleiche Operation beschreiben, gehalten werden. Auf diese Weise hat nun der Workflow-Spezialist die Möglichkeit, den „optimalen“ Workflow aus den verschiedenen Versionen, welche die gleiche OP beschreiben, vorzugeben und kann somit zur Erhöhung der Datenqualität beitragen. Dieser wird dann, ergänzt mit weiteren Daten, z.T. aus anderen (Ontologie-) Datenbanken (z.B. Daten verschiedener Hierarchieebenen, welche nicht direkt während der Aufzeichnung erfasst wurden, Beziehungen zwischen den Daten usw.), in einem weiteren Vorgang in die zentrale DWH-Datenbank geladen.

Der Anwender hat nun die Möglichkeit, mit bestimmten Methoden die bereinigten und multidimensional aufbereiteten Daten zu analysieren und auch graphisch darzustellen. Diese sind z.B. dem Reporting, dem OLAP oder dem Data Mining zuzuordnen.

2 Grundlagen

2.1 Business Intelligence

Der Begriff „ Business Intelligence “ (BI) wurde von Howard Dresner^[9] im Jahr 1989 geprägt und hat viele Facetten, so dass sich die inhaltlichen Vorstellungen von BI nicht einheitlich darstellen lassen.

Zu BI werden nach [Gluchowski/Kemper 2006; Schrödl 2006, S.12 ff.] sämtliche Systemkomponenten gezählt, womit entscheidungsrelevante Daten gesammelt, aufbereitet, dauerhaft und nutzungsorientiert gespeichert, sowie analysiert und geeignet dargestellt werden können. Während in der ersten Zeit BI mehr aus der technischen Perspektive betrachtet wurde (hierzu gehören Themen wie z.B. die Nutzung von Datenbankmanagementsystemen, Data Warehouses, ETL-Werkzeuge, Datenbankschemata usw.), geht der Fokus mehr und mehr auf eine anwendungsorientierte Sichtweise über.

Eine umfassende, auch von einschlägigen Beratungshäusern genannte Definition lautet nach [Gluchowski/Kemper 2006]:

„Unter Business Intelligence wird ein integriertes IT-Gesamtkonzept verstanden, das für die unterschiedlichen Ausprägungen der Anforderungen an geeignete Systeme zur Entscheidungsunterstützung tragfähige und miteinander verknüpfte Lösungen anbietet.“

Eine anwendungsorientierte Beschreibung liefert [Felden 2006]:

„Als Business Intelligence (BI) wird der analytische Prozess bezeichnet, der Unternehmens- und Wettbewerbsdaten in handlungsgerichtetes Wissen über die Fähigkeiten, Positionen, Handlungen und Ziele der betrachteten internen oder externen Handlungsfelder wandelt.“

Der Einsatz von BI erfolgt in der Praxis nicht starr, sondern wird an den jeweils notwendigen Erfordernissen ausgerichtet. Das Zusammenspiel von Komponenten der heute verfügbaren BI-Funktionalitäten muss also vor dem Hintergrund der jeweiligen Anforderungen der Unternehmen untersucht werden.

Die Abbildung 2-1 zeigt nach [Gluchowski 2001] und modifiziert nach [Kemper/Mehanna/Unger 2006]die verschiedenen Facetten von BI und strukturiert die unterschiedlichen Sichtweisen mit Hilfe eines zweidimensionalen Ordnungsrahmens:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-1 Unterschiedliche Facetten von Business Intelligence.^[10]

Auf der vertikalen Achse werden die Phasen des analytischen Datenverarbeitungsprozesses aufgetragen, beginnend mit der Bereitstellung der Daten bis zu deren Auswertung. Die horizontale Achse gibt vor, ob der Schwerpunkt in Richtung Technik oder Anwendung zu sehen ist. Nach [Kemper/Mehanna/Unger 2006] können durch die räumliche Positionierung der Anwendungsklassen drei Definitionsansätze abgegrenzt werden:

Enges BI-Verständnis

Hierzu werden nur die Kernanwendungen, welche eine Entscheidungsfindung direkt unterstützen, gezählt. Dazu gehören neben dem OLAP auch die Management Information Systems (MIS) bzw. die Executive Information Systems (EIS).

Analyseorientiertes BI-Verständnis

Zur analyseorientierten Sichtweise von BI werden sämtliche Anwendungen gezählt, mit denen der Nutzer direkt kommunizieren, also interaktiv arbeiten kann. Neben den bereits aufgeführten Anwendungen des engen BI-Verständnisses gehören hierzu auch Systeme des Text Mining, des Data Mining, des Ad-hoc-Reporting sowie Kennzahlsysteme, Planungs- bzw. Konsolidierungsanwendungen oder auch der Bereich des analytischen Customer Relationship Managements (CRM).

Weites BI-Verständnis

Unter BI i.w.S. werden neben den direkt auch die indirekt eingesetzten Anwendungen für die Entscheidungsunterstützung verstanden. Diese kommen zum einen zur Datenaufbereitung und –speicherung (in Form von ETL-Tools bzw. Data Warehouses) zum Einsatz und bieten zum anderen Auswertungs- und Präsentationsfunktionalitäten.

2.2 Data Warehouse

2.2.1 Der Begriff Data Warehouse

Der amerikanische Berater W.H. Inmon, welcher den Begriff Data Warehouse prägte, definierte ihn folgendermaßen [Inmon 1996]:

„A data warehouse is a subject-oriented, integrated, non-volatile, and time-variant collection of data in support of management’s decisions“.

Da sich das Data-Warehouse-Konzept im Laufe der Zeit weiterentwickelte, wurden demzufolge auch weitere Definitionen vorgeschlagen. So fasst Ralph Kimball, ein sehr geschätzter Autor auf dem Gebiet des DWH, das Wesen eines DWH kurz und präzise wie folgt zusammen [Kimball 1996]:

„A data warehouse is a copy of transactional data specifically structured for querying and analysis“.

Eine aktuelle und allgemein akzeptierte Definition nach [Mucksch/Behme 2000; Gabriel/Chamoni/Gluchowski 2000], modifiziert von [Kemper/Mehanna/Unger 2006, S.17], lautet:

„Data Warehouses (DWHs) sind von den operativen Datenbeständen getrennte, logisch zentralisierte dispositive Datenhaltungs-systeme. Idealtypischerweise dienen sie unternehmensweit als einheitliche und konsistente Datenbasis für alle Arten von Managementunterstützungssystemen“.

2.2.2 Merkmale eines Data Warehouses

Nachfolgend werden die wesentlichen Merkmale dargestellt, welche, basierend auf der Definition von [Inmon 2002, S.29 f.], ein Data Warehouse charakterisieren (s.a. [Kemper/Mehanna/Unger 2006, S.17-20; Mucksch/Behme 1997a, S.37-40; Wieken 1999, S.16 f.]):

Themenorientierung („subject-oriented“)

Sämtliche entscheidungsrelevanten Informationen werden so gespeichert, dass sie sich an den Subjekten eines Unternehmens, also z.B. an Kunden, Produkten usw. orientieren, da auf deren Basis Entscheidungen getroffen werden. Entscheidungsträger haben somit die Möglichkeit, direkt Informationen zu den jeweiligen Kerngebieten zu recherchieren und diese aus unterschiedlichen Blickwinkeln zu analysieren. Im Gegensatz dazu haben innerbetriebliche Abläufe und Funktionen nur einen geringen Einfluss auf die Struktur der Datenbasis, da Informationen über die innerbetrieblichen Abläufe nicht der Entscheidungsfindung dienen und somit nicht gespeichert werden.

Integration („integrated“)

Gleiche Informationen, z.B. über Kunden oder Produkte, müssen in ein einheitliches Format überführt werden. Hierzu ist es notwendig, dass die entscheidungsrelevanten Daten aus ganz unterschiedlichen operativen und externen Quellen zusammengeführt werden, so dass sie auch inhaltlich eine widerspruchsfreie Datensammlung darstellen. Diese Integration erweist sich als sehr zeitaufwendig und komplex, da die operativen Systemlandschaften, welche im Laufe der Jahre in den Unternehmen gewachsen sind, oftmals neben semantischen Widersprüchen auch Datenredundanzen und Inkonsistenzen aufweisen.

Zeitorientierung („time-variant“)

Im Gegensatz zu den operativen Systemen, in denen eine zeitpunktbezogene Betrachtung der Daten vorgenommen wird, sind für die Managementunterstützung zeitraumbezogene Daten und Informationen notwendig. Daher stellt ein Data Warehouse also keine Momentaufnahme des Unternehmens dar, sondern enthält Beschreibungen zu verschiedenen Zeitpunkten, welche in Abhängigkeit ihres Alters in unterschiedlichen Aggregationsstufen gespeichert werden. So ist es möglich, Entwicklungen der Unternehmenssituation über einen bestimmten Zeitraum zu verfolgen und die Daten und Informationen z.B. zur Untersuchung von Trends heranzuziehen.

Dieser Punkt des Zeitraum-Bezuges relativiert sich jedoch mehr und mehr, was nicht zuletzt eine Folge der Durchdringung des E-Business und den damit in Verbindung stehenden Analysemöglichkeiten ist. So werden in bestimmten Konzepten, wie z.B. dem kundenorientierten DWH, nicht mehr voraggregierte Daten über einen längeren Zeitraum gespeichert, sondern die so genannte Granularität. Dabei handelt es sich um die unterste Granularitätsstufe von betriebswirtschaftlich relevanten Detail-Daten. Die dargestellten Zeiträume werden also immer enger gefasst.

Beständigkeit („non-volatile“)

Die Volatilität beschreibt den Grad, welcher die Häufigkeit von Änderungen der Daten misst. In operativen Systemen zeichnen sich Daten durch eine kontinuierliche Veränderung aus. Im Gegensatz dazu werden die integrierten Daten in einem DWH nur in Ausnahmefällen (z.B. der Korrektur fehlerhaft übernommener Daten) geändert und dauerhaft abgelegt, wodurch sie auch für zukünftige Analysen zur Verfügung stehen. Daten im DWH werden also grundsätzlich nicht verändert, so dass nahezu alle Datenzugriffe lesend erfolgen können. Um jedoch dem enormen Datenwachstum entgegenzutreten, können im Zuge von sinnvoll ausgeführten Historisierungskonzepten Daten ab einem bestimmten Alter verdichtet oder archiviert werden.

2.2.3 Das Data-Warehouse-System und seine Komponenten

Ein Data-Warehouse-System umfasst neben dem eigentlichen Data Warehouse noch weitere Komponenten. Hierzu zählen neben den vorgelagerten Datenquellen z.B. ETL-Werkzeuge, Metadaten, das Repository, Werkzeuge zur Administration, Data Marts, OLAP Server sowie verschiedene Anwendungen, welche zur Datenanalyse und -präsentation dem Endanwender zur Verfügung stehen. Es gibt je nach vorhandener Infrastruktur und Verwendungszweck verschiedene Varianten von DWH-Architekturen. Abbildung 2-2 zeigt eine typische DWH-Architektur, wie sie auch von [Chaudhuri/Dayal 1997] vorgeschlagen wird.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-2 Data-Warehouse-Architektur.^[11]

Nachfolgend werden die verschiedenen Ebenen der Data-Warehousing-Architektur auf Grundlage von Abbildung 2-2 von links nach rechts beschrieben.

2.2.3.1 Datenquellenebene

Auf der Ebene der Datenquellen sind neben den firmeninternen Datenquellen, wie z.B. ERM-Systeme oder sonstige operationale Datenbanken, auch externe Datenquellen angesiedelt. Diese Quellen können in ganz unterschiedlichen Formen, wie z.B. als relationale Datenbanken, im XML-Format, als Textdateien oder auch in Form von Tabellenkalkulationen vorliegen und liefern die primären Daten, welche es mit Hilfe des Data Warehouses auszuwerten gilt. Sie fallen in der Regel bei der Verarbeitung von Transaktionen während des Tagesgeschäftes an und verwenden gewöhnlich sogenannte Online-Transaction-Processing (OLTP)-Datenbanken, welche den OLAP-Datenbanken entgegen stehen (vgl. Abschnitt 2.3.1).

2.2.3.2 Datenhaltungsebene (DWH, Data Mart, Daten Ein- u. Ausgabe)

Die Datenhaltungsebene lässt sich wiederum in die drei Bereiche Datenerfassungsebene, Datenhaltungsebene und Datenbereitstellungsebene gliedern:

2.2.3.2.1 Datenerfassungsebene (ETL-Prozess)

Die Datenerfassungsebene stellt die Schnittstelle des DWH-Systems zu den Quelldaten, also den operativen Systemen, dar. Hierfür werden verschiedene Tools zur Verfügung gestellt, um die Daten im DWH in periodischen Abständen zu aktualisieren. Da dieser Vorgang ein wesentlicher Bestandteil des Data Warehousing ist und in der Praxis den aufwendigsten Teil der Umsetzung darstellt, wird er nachfolgend näher beleuchtet.

ETL-Prozess : In einem Data-Warehouse-System findet nach [Bauer/Günzel 2004, S.48-52; Gluchowski/Kemper 2006] ein Integrationsprozess der Daten statt, der sich in die folgenden drei Hauptkomponenten gliedert: die Extraktion, die Transformation und das Laden. Aus den Anfangsbuchstaben dieser Komponenten ergibt sich der Begriff der ETL-Komponenten , welche zugleich auch die Reihenfolge des Prozessablaufes darstellen.

Mit Hilfe der Extraktionskomponente werden die Daten aus den verschiedenen Datenquellen in den Arbeitsbereich^[12] (Staging Area) übertragen und dort temporär gehalten. Des Weiteren bestimmt sie die hierzu benötigten Datenquellen bzw. die benötigten Ausschnitte daraus. Für die Ausführungszeitpunkte der Extraktion gibt es verschiedene Vorgehensweisen, z.B. die periodische oder ereignisgesteuerte Extraktion. Die Transformationskomponente hat nun die Aufgabe, die Daten im Arbeitsbereich in ein einheitliches internes Format zu überführen, was sowohl die Struktur wie auch den Inhalt betrifft. Hierzu zählen z.B. die Anpassung unterschiedlicher Datentypen, die Konvertierung von Zeichenketten sowie die Umrechnung einzelner Währungen. Dieser Schritt ist notwendig, um die Daten vergleichbar zu machen. Neben diesen Transformationen, welche durch den Begriff Datenmigration beschrieben werden, ist die Datenbereinigung ein weiterer wesentlicher Schritt, in dem z.B. fehlerhafte, fehlende, redundante oder veraltete Werte korrigiert werden. Durch die Ladekomponente werden nun die aufbereiteten Daten weitergeleitet, wobei hier zwei unterschiedliche Komponenten bestehen. Eine davon ist für die Übertragung der Daten aus dem Arbeitsbereich in die Datenbasis zuständig, wobei es sich um analyseunabhängige Daten handelt. Die andere überträgt analysespezifische Daten aus der Datenbasis in das eigentliche DWH.

2.2.3.2.2 Datenhaltungsebene (DWH, Data Marts)

Das eigentliche Data Warehouse (also die zentrale Data-Warehouse-Datenbank) ist nach [Bauer/Günzel 2004, S.526] eine physische Datenbank, die eine integrierte Sicht auf beliebige Daten zu Analysezwecken ermöglicht . Darin werden also Informationen und Daten des Unternehmens in einer sinnvollen Struktur gespeichert, um die Wertschöpfung in Form von neuem Wissen aus den heterogenen Quelldaten überhaupt erst zu ermöglichen. Die Datenspeicherung erfolgt dabei anwendungs- bzw. auswertungsorientiert und ist hinsichtlich relevanter Themen organisiert, wobei das Datenmaterial beliebige Verdichtungsstufen von Kennzahlen umfasst. Das Data Warehouse besitzt zum einen Verbindungen zu den relevanten Datenquellen, welche die Ursprungsdaten beinhalten und stellt zum anderen Verbindungen zu Systemen bereit, welche die Datenanalyse sowie die Datenaufbereitung ermöglichen.

Ein Problem, welches häufig bei einem zentralen und organisationsweit angelegten Data Warehouse auftritt, ist durch das große Volumen der dort abgelegten Daten gegeben: es ist zu wenig performant, um die umfangreichen Datenbestände schnell und flexibel genug analysieren zu können. Abhilfe schaffen hierbei die sogenannten Data Marts. Die Grundidee des Data Mart Konzeptes besteht darin, nur einen inhaltlich beschränkten Bereich des Unternehmens oder einer Abteilung als Teilsicht eines Data Warehouses abzubilden (s.a. [Bauer/Günzel 2004, S.59 f.; Gluchowski/Kemper 2006]). Dadurch kann die Komplexität und das Datenvolumen verringert, sowie durch Aggregationen ein deutlicher Performancegewinn erzielt werden. Zudem bieten Data Marts noch weitere Vorteile, welche z.B. in der eigenständigen Behandlung oder im Bereich des Datenschutzes liegen.

2.2.3.2.3 Datenbereitstellungsebene

Die Datenbereitstellungsebene des DWH oder der Data Marts stellt die Schnittstelle zur Präsentationsebene dar. Hierbei kommen ein oder mehrere OLAP-Server (im Falle von Data-Mining-Anwendungen auch sog. Data-Mining-Engines) zum Einsatz, wodurch ein interaktiver Zugriff der verschiedenen Anwendungen auf die multidimensionalen Daten des DWH ermöglicht wird. Der OLAP-Server greift dabei nicht nur auf das DWH zu, sondern beinhaltet auch die entsprechende Verarbeitungslogik, um den anfragenden Anwendungen die gewünschten Daten zur Verfügung stellen zu können.

2.2.3.3 Analyseebene

Zur Analyseebene, welche auf die Datenbereitstellungsebene aufsetzt, zählt ein breites Spektrum von Anwendungen, wobei die Einsatzgebiete weit gefächert sind. So gehören neben den beiden bedeutendsten generischen Analysesystemen OLAP und Data Mining, z.B. auch Managementinformationssysteme, Früherkennungs- bzw. Warnsysteme oder auch die Berichtssysteme dazu.

2.2.3.4 Metadaten-Repository, Administration und Monitoring

Die Metadaten aller Ebenen des DWH-Systems werden nach [Bauer/Günzel 2004, S.68]zentral in einem Metadaten-Repository gehalten, wobei man unter Metadaten alle Informationen versteht, die den Aufbau, die Wartung und auch die Administration des DWH-Systems vereinfachen und zusätzlich die Gewinnung der gewünschten Informationen aus dem DWH ermöglichen. Hierzu gehören neben beschreibenden Informationen, (z.B. über Inhalt, Struktur und Bedeutung der Daten) auch prozessbezogene Informationen (z.B. über die Verarbeitung der Daten).

Des Weiteren stehen Tools zur Administration des DWHs sowie zum Monitoring zur Verfügung. Das Monitoring hat die Aufgabe, die Quelldaten hinsichtlich Änderungen zu überwachen und bei Bedarf den Datenbeschaffungsprozess, also den ETL-Prozess, wie in diesem Kapitel bereits beschrieben, anzustoßen [Bauer/Günzel 2004, S.75].

2.2.3.5 Operational Data Store (ODS)

Mit dem Begriff „Operational Data Store“ bezeichnet [Bauer/Günzel 2004, S.54] eine Datenbank, die im Umfeld des DWH-Systems Anwendung findet, sich jedoch deutlich von einem DWH unterscheidet. So nimmt ein ODS die operationalen Daten in den verschiedenen Vorsystemen direkt auf und führt sie zeitlich befristet in einer physischen Datenbank zusammen. Zweck dieser Datenbank ist es, aktuelle Daten schnell verfügbar zu machen (z.B. um aktuelle Reports zu generieren oder um zeitnah auf bestimmte Vorkommnisse reagieren zu können). Da für diese Anwendung keine Integration und Transformation der Daten notwendig ist (ganz im Gegensatz zum DWH), wird es nicht dem eigentlichen DWH-System zugeordnet.

2.3 Online Analytical Processing

Der Begriff OLAP wurde von E.F. Codd^[13] ganz bewusst zur Abgrenzung zum bekannten OLTP gebildet. Er definierte ihn in [Codd/Codd/Salley 1993] wie folgt:

„ ... the name given to the dynamic enterprise analysis required to create, manipulate, animate and synthesize information from ´Enterprise Data Models´. This includes the ability to discern new or unanticipated relationships between variables, the ability to identify the parameters necessary to handle large amounts of data, to create an unlimited number of dimensions (consolidation paths) and to specify cross-dimensional conditions and expressions.“

Die aktuell gängigste Definition von OLAP nach Nigel Pendse^[14] lautet:

„On-Line Analytical Processing. A category of applications and technologies for collecting, managing, processing and presenting multidimensional data for analysis and management purposes.”

Mit OLAP bezeichnet man also die Analyse und Auswertung von multidimensional aufbereiteten Daten, um - meist im Rahmen eines Data Warehouses - Informationen schnell und interaktiv für Unternehmensentscheidungen zu gewinnen. Um mit der wachsenden Menge und der zunehmenden Komplexität der gespeicherten Unternehmensdaten sowie dem steigenden Analysebedarf umgehen zu können, wurde OLAP konzipiert [Bauer/Günzel 2004, S.98]. Es lässt sich innerhalb von Entscheidungs- u. Managementinformationssystemen den hypothesengestützten Analysemethoden zuordnen. Der Anwender (z.B. Führungskräfte auf allen Ebenen, qualifizierte Mitarbeiter aus den Fachabteilungen) hat bereits vor der Untersuchung eine Hypothese, welche durch das Analyse-Ergebnis bestätigt oder abgelehnt wird.

Im Vordergrund stehen dabei dynamische, interaktive und multidimensionale Analysen auf historischen und konsolidierten Datenbeständen, welche sich in einem konsistenten Zustand befinden [Mucksch/Behme 1997b, S.394]. Durch interaktive Zugriffe auf verschiedene Sichten und Darstellungsarten der Daten bekommt der Nutzer schnell einen Überblick über die für ihn relevanten Informationen und kann so gezielt bestimmte Zusammenhänge aufdecken bzw. analysieren.

2.3.1 Abgrenzung OLAP versus OLTP

In diesem Abschnitt wird eine allgemeine Abgrenzung zwischen den beiden Datenbankanwendungen OLAP und OLTP vorgenommen (s.a. [Bauer/Günzel 2004, S.8 ff.; Kemper/Eickler 2004, S.489 f.; Messerschmidt/Schweinsberg 2003, S.28 f.]).

OLTP ist das zentrale Merkmal herkömmlicher relationaler Datenbanken und ist typisch für die Informationsverarbeitung im Bereich der operativen Systeme. Hierzu zählen Anwendungen wie z.B. die „Buchung eines Urlaubes“ bei einem Reiseunternehmen oder die „Verarbeitung eines Auftrages“ in einem Handelsunternehmen. Diese OLTP-Anwendungen, welche das operationale Tagesgeschäft umsetzen, verarbeiten nur eine begrenzte Menge an Daten und nutzen dazu den jüngsten, aktuell gültigen Datenbestand. Bei OLTP-Anwendungen ist es erforderlich, dass Zugriffe bzw. Änderungen der Daten in einer kontrollierten Umgebung, also transaktionsorientiert, erfolgen.

[...]

^[1] Homepage ICCAS: http://www.iccas.de/

^[2] Eine Ontologie beschreibt die Wirklichkeit mit Hilfe einer vereinbarten Terminologie sowie Beziehungen und Ableitungsregeln zwischen den dort definierten Begriffen und Aktivitäten mit dem Ziel, gemeinsame Eigenschaften und Relationen von Objekten darzustellen [Hesse 2002].

^[3] Die Aufgabe des Workflows liegt neben der Erfassung und Darstellung der Ontologie in der Analyse der aufgezeichneten Daten [Strauß et al. 2005].

^[4] Vgl. [Burgert 2007, S.2].

^[5] Vgl. Meeting Abstract: Workflowanalysen als objektives Beschreibungsmittel in der HNO-Chirurgie .

Burgert et al., 2006

URL: http://www.egms.de/en/meetings/hnod2006/06hnod016.shtml

^[6] Vgl. [Burgert 2007, S.9].

^[7] Vgl. [Burgert 2007, S.35].

^[8] Im Arbeitsbereich finden also die Transformationen der Daten statt, welche dort nur temporär gehalten werden.

^[9] Howard Dresner wird als Vater von „Business Intelligence“ angesehen und arbeitete 1989 als Analyst bei der Gartner Group. Diese verließ er 2005 als Vize-Präsident und wechselte zu Hyperion als Chefstratege.

^[10] Vgl. [Kemper/Mehanna/Unger 2006, S.4].

^[11] Modifziert nach [Chaudhuri/Dayal 1997].

^[12] Im Arbeitsbereich finden die erforderlichen Transformationen statt und erst nachdem alle Transformationen abgeschlossen sind, werden die Daten in die Datenbasis geschrieben. Dies hat den Vorteil, dass weder die Datenquellen noch die Basisdatenbank im laufenden Betrieb gestört werden.

^[13] Das OLAP Konzept wurde 1993 von dem Mathematiker und Wissenschaftlicher Dr. Edgar Frank Codd (1923-2003), dem Begründer der relationalen Datenbanktechnologie, eingeführt, um Schwächen der relationalen Datanbankmanagementsysteme (RDBMS) zur Datenanalyse zu umgehen.

^[14] Vgl. http://www.olapreport.com/glossary.htm