Sie sind auf Seite 1von 19

 

 
 
 
 
 

Business Intelligence 
Thema 3:   
Konzepte des Online Analytical Processing 
 
 
Eingereicht von  Johannes Christian Nissen
  Adresse   
   
  Telefonnummer   
  Emailadresse  jcnissen79@googlemail.com 
 
Studiengang 
Semester 
Anzahl Seiten 
 
 

   
Inhaltsverzeichnis    Seite  II| 19 

Inhaltsverzeichnis 
 

Inhaltsverzeichnis ..................................................................................................................... II 
Abbildungsverzeichnis ............................................................................................................ III 
Tabellenverzeichnis ................................................................................................................. III 
Abkürzungsverzeichnis ............................................................................................................ IV 
1.  Einleitung ..................................................................................................................... 1 
1.1.  Einführung / Zielstellung .......................................................................................... 1 
1.2.  Abgrenzung .............................................................................................................. 1 
1.2.1.  OLTP und OLAP ................................................................................................ 1 
1.2.2.  OLAP und Datamining ...................................................................................... 2 
1.3.  Vorgehen .................................................................................................................. 3 
2.  Grundlagen................................................................................................................... 3 
2.1.  Begriffsdefinition...................................................................................................... 3 
2.2.  OLAP als Datenbereitstellungsebene ....................................................................... 4 
2.3.  Architektur Konzepte ............................................................................................... 5 
2.3.1.  Relationales OLAP (R‐OLAP) ............................................................................. 5 
2.3.2.  Multidimensionales OLAP (M‐OLAP) ............................................................... 6 
2.3.3.  Hybrides OLAP (H‐OLAP) .................................................................................. 7 
3.  Methoden zur Datenanalyse ........................................................................................ 7 
3.1.  Pivoting / Rotation ................................................................................................... 8 
3.2.  Slicing & Dicing ......................................................................................................... 9 
3.3.  Roll‐up & Drill‐down............................................................................................... 10 
3.4.  Drill‐through & Drill‐across .................................................................................... 11 
3.5.  Split & Merge ......................................................................................................... 12 
4.  Einführung und Entwicklung eines OLAP‐Systems .................................................... 13 
Literaturverzeichnis ................................................................................................................. V 
 

   

  Seite  II| 19 
Abbildungsverzeichnis    Seite  III| 19 

Abbildungsverzeichnis 
 

Abbildung 2‐1: Architektur eines Data‐Warehouse‐Systems .................................................. 5 
Abbildung 2‐2: Systemebenen eines M‐OLAP Systems ........................................................... 6 
Abbildung 2‐3: Systemebenen eines R‐OLAP Systems ............................................................ 6 
Abbildung 2‐4: Systemebenen eines H‐OLAP Systems ............................................................ 7 
Abbildung  3‐1:  Entwicklung  eines  Hypercubes  anhand  der  Fahlzahlen  in  einem 
Krankenhausverbund ............................................................................................................... 8 
Abbildung 3‐2: Pivoting bzw. Rotation eines Hypercubes ....................................................... 9 
Abbildung 3‐3: Slicing (vertikal) eines Hypercubes .................................................................. 9 
Abbildung 3‐4: Slicing (horizontal) eines Hpercubes ............................................................. 10 
Abbildung 3‐5: Dicing eines Hypercubes ............................................................................... 10 
Abbildung  3‐6:  Drill‐through  bzw.  OLAP‐join  über  zwei  Hypercubes  mit  Division,  zur 
Generierung neuer Kennzahlen ............................................................................................. 12 
 

Tabellenverzeichnis 
 

Tab. 1‐1: Eindimensionale Tabelle (OLTP) ............................................................................... 1 
Tab. 1‐2: Zweidimensionale Tabellen (OLAP) .......................................................................... 2 
Tab. 3‐1: Roll‐up und Drill‐down in einer 2‐dimensionalen Tabelle ...................................... 11 
Tab. 3‐2: Pivottabelle zur Demonstration von Split und Merge ............................................ 13 

  Seite  III| 19 
Abkürzungsverzeichnis    Seite  IV| 19 

Abkürzungsverzeichnis 
 

ADO    ActiveX Data Objects 

FASMI    Fast Analysis of Shared Multidimensional Information 

gGmbH   gemeinnützige Gesellschaft mit beschränkter Haftung 

MDX    Multidimensional Expressions 

ODBC    Open Database Connectivity 

OLAP    Online Analytical Processing 

OLE DB   Object Linking and Embedding (Database) 

OLTP    Online Transaction Processing

  Seite  IV| 19 
Einleitung    Seite  1| 19 

1. Einleitung  
1.1. Einführung / Zielstellung 
Das  OLAP‐Konzept  wurde  1993  von  Edgar  F.  Codd  und  Mitautoren  durch  einen  Artikel  in 
der Computerworld als Begriff geprägt. Das Online Analytical Processing wurde als Konzept 
zur dynamischen Analyse in multidimensionalen Datenräumen vorgestellt.  
Es  ist  die  Antwort  auf  die  oft  geforderten  Analysemöglichkeiten  und  Reportingfunktionen 
von  Führungskräften.  Zur  Problemlösung  werden  Betrachtungen  bestimmter  Tatbestände 
aus unterschiedlichen Perspektiven notwendig, dies ermöglicht ein OLAP System. 
Typische Fragestellungen sind zum Beispiel: Bin ich mit meinem Unternehmen erfolgreich? 
Wie  viel  Umsatz  habe  ich  mit  bestimmten  Produkten  in  diesem  Monat  erzielt?  Wie  viel 
Umsatz habe ich im ersten Quartal mit allen Produkten erzielt? 
Diese  Beispiele  verdeutlichen  auch  die  unterschiedlichen  Verdichtungsstufen  der 
abgerufenen  Informationen.  So  kann  vom  gesamten  Sortiment  über  Produktgruppen  bis 
zum Produkt oder sogar Stücklisten aggregiert und separiert werden.  
 
Korth und Silberschatz definieren OLAP wie folgt: 
„Interactive analysis of data, allowing data to be summarized and viewed in different ways 
in an online fashion (with negligible delay)“1 

Diese Arbeit soll einen Überblick über die verschiedenen  Architekturmodelle eines OLAP‐
Systems geben und die Methoden/Funktionen aufzeigen und erklären.  

1.2. Abgrenzung 
1.2.1. OLTP und OLAP 
Das OLTP, also Online Transaction Processing, ist die transaktionsorientierte Datenhaltung 
in den operativen Datenbanken, die relational ausgelegt sind. 

Die  Darstellung  erfolgt  in  eindimensionaler  Sicht  (siehe  Tab.  1‐1).  Diese  Sichtweise 
ermöglicht  noch  keine  umfangreichen  Analysen.  Es  ist  die  einfache  Fortschreibung  eines 
Krankenhausaufenthalts,  wie  sie  zum  Beispiel  in  einem  Patientenadministrationssystem 
vorherrscht. 

lfd. Nr. Patient Klinik Fachrichtung Verlauf Datum


1 Muster, Max Husum Chirurgie Aufnahme 05.01.2008
2 Test, Testine Niebüll Chirurgie Aufnahme 05.01.2008
3 Hansen, Paul Tönning Innere Aufnahme 08.01.2008
4 Muster, Max Husum Innere Verlegung 10.01.2008
5 Hansen, Paul Tönning Chirurgie Entlassung 10.01.2008
6 Muster, Max Husum Innere Entlassung 15.01.2008
… … … … … …
Tab. 1‐1: Eindimensionale Tabelle (OLTP) 

   

                                                            
1
 Vgl: Korth, Silberschatz, Database System Concepts, 5th Edition, S. 725 ff 

  Seite  1| 19 
Einleitung    Seite  2| 19 

Die Daten aus den transaktionsorientierten Datenbanken werden durch das OLAP System in 
mehrdimensionale  Darstellungsformen  transformiert.  Die  Tabellen  Tab.  1‐2  verdeutlichen 
die Darstellung in zwei Dimensionen (zum einen Ort bzw. Klinik und Fachrichtung und zum 
anderen die Dimensionen Zeit, bzw. Tag und Verlauf). 

Chirurgie Innere
Husum Muster, Max Muster, Max
Niebüll Test, Testine -
Tönning - Hansen, Paul
 

Aufnahmen Verlegungen Entlassungen


05.01.2008 2 0 0
08.01.2008 1 0 0
10.01.2008 0 1 1
15.01.2008 0 0 1
Tab. 1‐2: Zweidimensionale Tabellen (OLAP) 

OLAP  Auswertungen  werden  nicht  auf  operativen  Datenbanken  ausgeführt,  weil  es  meist 
mehrere  operative  Systeme  gibt,  daher  ist  eine  Konsolidierung  in  einem  Data  Warehouse 
sinnvoll.    OLTP  Systeme  sind  aufgrund  einfacher  und  häufiger  Änderungstransaktionen 
logisch  und  physisch  anders  ausgelegt  als  OLAP  Systeme.  Sie  arbeiten  mit  begrenzten 
Datenmengen und geringerer Anzahl an Tabellen, die auf Update‐ und Insert‐Operationen 
optimiert sind.2 

OLAP  Systeme  dagegen  sind  für  große  aufwändige  Rechenoperationen  ausgelegt,  sie 
müssen schnell verschiedenste Daten auswerten. Oft liegen in OLAP Systemen Daten schon 
aggregiert vor. Dies ermöglicht schnellere Antwortzeiten.  

1.2.2. OLAP und Datamining 
Während  das  Datamining  durch  seine  datengesteuerte  Exploration,  Modellierung  und 
Suche  nach  Dimensionen  einen  Bottom‐Up  Ansatz  verfolgt,  widmet  sich  das  Online 
Analytical  Processing  eher  einem  Top‐Down  Ansatz.  Die  Ziele  des  OLAP  sind 
nutzergesteuerte  Reports  und  Analysen  mit  bekannten  Dimensionen.  Der  Anwender 
formuliert seine Abfragen an das OLAP System. 

Datamining  wird  zum  Beispiel  für  Regressionsanalysen,  Gruppenfindung  oder  Prognosen 


eingesetzt,  wobei  die  Abfrage  nicht  direkt  vom  Anwender  formuliert  wird,  sondern 
lernende Algorithmen bestimmte Muster (Pattern) finden.3  

Die klassische OLAP Anwendung bezieht sich auf vergangenheitsbasierter Datenanalyse mit 
meist vorformulierten Fragestellungen. 

OLAP liefert dem Anwender Datenmaterial, aus dem er letztendlich Schlüsse zieht.  

                                                            
2
 Vgl. Manhart, K.: Ad‐hoc Analysen mit OLAP,  Universität Bamberg 
3
 Vgl. Mena, Jesus, Datamining your Website, Digital Press, 1999, S. 50 

  Seite  2| 19 
Grundlagen    Seite  3| 19 

1.3. Vorgehen 
Nach  der  kurzen  Entstehungsgeschichte  des  OLAP  und  einer  Abgrenzung  gegenüber  dem 
Online Transaction Processing , sowie auch dem Datamining folgt im zweiten Kapitel nach 
einer  Begriffsdefinition  die  Vorstellung  der  zur  Zeit  dominierenden  Architekturvarianten 
von OLAP‐Systemen. 

Im dritten Kapitel werden die Funktionen/Methoden eines OLAP‐Systems vorgestellt. Dies 
geschieht  anhand  von  Praxisbeispielen  aus  dem  Gesundheitswesen.  Das  Zahlenmaterial 
(Fallzahlen) stammt dabei aus der Klinikum Nordfriesland gGmbH.  Im letzten Kapitel wird 
kurz  auf  die  wichtigsten  Kriterien  bei  der  Auswahl  bzw.  Entwicklung    eines  OLAP‐Systems 
eingegangen. Es soll die Komplexität und  Individualität eines solchen Projekts aufzeigen. 

2. Grundlagen 

2.1. Begriffsdefinition 
Der  Begriff  OLAP  steht  für  „Online  Analytical  Processing“.  Dies  kann  wie  folgt  erklärt 
werden: 
 Online  bezeichnet  die  direkte  Zugriffsmöglichkeit  auf  den  Datenbestand  der 
zentralen  Datenbank.  Er  kann  betrachtet,  transformiert  und  in  der  Ansicht 
manipuliert werden. 
 Analytical steht für den analytischen Verwendungszweck der Daten, im Gegensatz 
zu  der  transaktionsorientierten  Datensicht,  die  in  den  operativen  Systemen 
vorherrscht.  Die Daten dienen der Analyse um zum Beispiel Entscheidungsträgern 
Informationen zu liefern.4 
 Processing  beschreibt  die  Möglichkeit  einer  ständigen  (Neu‐)Berechnung  der 
Sichten  und  schnelle  Bearbeitung  der  abgerufenen  Funktionen/Methoden  zur 
Datenanalyse. 
Edgar  F.  Codd  hat  1993  zwölf  Regeln  zur  Evaluation  von  OLAP‐Werkzeugen  entwickelt. 
Diese  können  jedoch  nicht  einwandfrei  zwischen  Anforderungen,  Fachkonzept  und 
technischer Realisierung abgegrenzt werden. 

1. Multidimensional Conceptual View 
2. Transparency 
3. Accessibility 
4. Consistent Reporting Performance 
5. Client‐Server Architecture 
6. Generic Dimensionality 
7. Dynamic Sparse Matrix Handling 
8. Multi‐User Support 
9. Unrestricted Cross‐dimensional Operations 
10. Intuitive Data Manipulation 
11. Flexible Reporting 

                                                            
4
 Vgl. Goeken, M: Entwicklung von Data‐Warehouse‐Systemen, Deuscher Universitäts‐Verlag S. 35 

  Seite  3| 19 
Grundlagen    Seite  4| 19 

12. Unlimited Dimensions and Aggregation Levels5  
 
Diese  zwölf  Regeln  wurden  1995  durch  sechs  weitere  ergänzt  (Batch  Extraction  vs 
Interpretive,  OLAP  Analysis  Models,    Treatment  of  Non‐Normalized  Data,  Storing  OLAP 
Results:  Keeping  Them  Separate  from  Source  Data,  Extraction  of  Missing  Values  und 
Treatment  of  Missing  Values)    und  in  vier  Gruppen  (Basic  Features,  Special  Features, 
Reporting Features und Dimension Control) eingeteilt.6 
 
Da die zwölf  Regeln von Codd und Kollegen zu sehr auf die Anforderungen an relationale 
Datenbanken zielen, haben Pendse und Creeth 1995 einen neuen Kriterienkatalog erstellt, 
der  die  wesentlichen  Merkmale  eines  OLAP  Systems  enthält.  Ihr  Anspruch  war  es,  eine 
einfache und einprägsame Definition zu erarbeiten. 7  
Ihre  Kriterien  lassen  sich  in  dem  Satz  „Fast  Analysis  of  Shared  Multidimensional 
Information“ zusammenfassen, häufig auch als FASMI abgekürzt. 
Im Einzelnen stehen die Kriterien für: 
 Fast:    Damit  der  Nutzer  seinen  aktuellen  Gedanken  nicht  verliert,  sollen  Abfragen 
innerhalb  von  1  bis  20  Sekunden  erfolgt  sein.  Nur  wenige  komplexe  Abfragen 
sollten länger als 20 Sekunden dauern. 
 Analysis:  Um  einen  schnellen  Zugang  zu  Informationen  zu  bekommen,  sollte  das 
System Geschäftslogik und statistische Werkzeuge beherrschen.  Die Formulierung 
von  neuen  Abfragen  sollte  in  Formalsprache  möglich  sein,  damit  keine  spezielle 
Programmiersprache erlernt werden muss. 
 Shared:  Ein  Mehrbenutzerbetrieb  muss  gewährleistet  sein.  Dieser  ist  mit 
Sicherheitsmechanismen  auszustatten.    Um  auch  schreibende  Zugriffe  zu 
ermöglichen, muss das System über geeignete Locking‐Mechanismen verfügen und 
in einem konsistenten Zustand sein. 
 Multidimensional:    Die  Multidimensionalität  (meist  als  Würfel  dargestellt)  gilt 
vorrangig  für  die  Datensicht.  Weder  Codd  noch  Pendse/Creeth  verlangen  nach 
einem bestimmten Datenbanksystem als Datenbasis. 
 Information:  Informationen  sind  alle  für  das  System  und  dessen  Nutzung 
benötigten  Daten.  Es  ist  unabhängig  von  den  Datenbeständen  ein  stabiles 
Antwortzeitverhalten  zu  gewährleisten.  Eine  wichtige  Kennzahl  ist  das  Input‐/ 
Output‐Verhalten. 

Die Darstellung der Abfrageergebnisse wird in der Regel in Tabellen vorgenommen, da sich 
eine multidimensionale Darstellung schwer interpretieren lässt. 

2.2. OLAP als Datenbereitstellungsebene 
Die  Datenbereitstellungsebene  hat  den  Zweck,  Daten  aus  der  darunterliegenden  Ebene 
(Datenhaltungsebene)  so  aufzubereiten,  dass  sie  für  Entscheidungsträger  relevante 
Informationen  enthält.  Die  dazu  benötigte  technische  Komponente  ist  der  OLAP‐Server. 

                                                            
5
 Codd, E. F.: Providing OLAP to User‐Analysts: An IT Mandate, S. 12 
6
 Vgl. Pendse, N.: What is OLAP?, http://olapreport.com/fasmi.htm 
7
 Vgl. Pendse, Creeth: What is OLAP? , http://olapreport.com/fasmi.htm 

  Seite  4| 19 
Grundlagen    Seite  5| 19 

Dieser stellt die Daten in aufbereiteter Form der nächsten Ebene (Präsentationsebene) zur 
Verfügung. 
Gewöhnlicherweise  liegen  die  Daten  in  einer  harmonisierten  Form  in  einem 
Datawarehouse vor.  

 
Abbildung 2‐1: Architektur eines Data‐Warehouse‐Systems8 

 
Über  ein  Frontend  (zum  Beispiel:  Web,  Excel,  eigene  Client  Anwendung)  kann  der 
Anwender seine Fragestellung in Abfragen (Queries) an das System stellen und sich durch 
die Daten, die das OLAP‐System zurückliefert, bewegen. 
Die  zugrunde  liegende  Datenbasis  kann  in  relationaler,  multidimensionaler  oder  einer 
Mischform (hybrider) gespeichert sein.  
 

2.3. Architektur Konzepte  
2.3.1. Relationales OLAP (R­OLAP) 
Die  Architekturvariante  des  Relationalen  OLAP  sieht  es  vor,  die  Daten  erst  während  der 
Nutzung aus der relationalen Datenbank zu lesen und über eine OLAP‐Engine nur virtuell als 

                                                            
8
 Quelle:  Eigene  Darstellung  in  Anlehnung  an  Goeken,  M.:  Entwickung  von  Data‐Warehouse‐
Systemen, Universitäts‐Verlag, 2006, S. 27 

  Seite  5| 19 
Grundlagen    Seite  6| 19 

Würfel  zur  Verfügung  zu  stellen.  Die  multidimensionalen  Sichten  sind  nicht  physisch 
gespeichert, sondern werden dynamisch erzeugt.9 

Die Abbildung 2‐2 zeigt die verschiedenen Elemente und Ebenen der R‐OLAP Architektur: 

 
Abbildung 2‐2: Systemebenen eines M‐OLAP Systems10 

Vorteile des R‐OLAP sind, die geringere Komplexität des Systems und die höhere Flexibilität 
des relationalen Datenbanksystems. 

Nachteilig wirkt sich die ständige Neuberechnung des multidimensionalen Würfels auf die 
Antwortzeiten aus. Diese sind höher als bei Multidimensionalen Systemen. 

2.3.2. Multidimensionales OLAP (M­OLAP) 
Die  Multidimensionale  OLAP  Architektur  speichert  die  Daten  physisch  in 
mehrdimensionalen  Datenbanken.  Dies  erspart  rechenintensive  Berechnungen,  da  die 
Daten schon aggregiert und vorberechnet in der Datenbank liegen. Die Zeilen können direkt 
adressiert und abgerufen werden. Die Modellierung von Multidimensionalen Datenbanken 
muss  gut  überlegt  und  vorbereitet  sein,  die  Anforderungen  der  Nutzer  sind  früh  zu 
evaluieren um ein performantes ergebnisorientiertes System zu gestalten.  

Die folgende Abbildung zeigt die Komplexität eines M‐OLAP Systems,  

 
Abbildung 2‐3: Systemebenen eines R‐OLAP Systems11 

                                                            
9
 Vgl. Goeken, M.: Entwickung von Data‐Warehouse‐Systemen,Deutscher Universitäts‐Verlag, 2006, 
S. 40 
10
 Quelle: Eigene Darstellung in Anlehnung an Gluchowski, P.: Folien Management Support Systems, 
Ruhr‐Universität Bochum 
11
 Quelle: Eigene Darstellung in Anlehnung an Gluchowski, P.: Folien Management Support Systems, 
Ruhr‐Universität Bochum 

  Seite  6| 19 
Methoden zur Datenanalyse    Seite  7| 19 

Vorteil  des  M‐OLAP  ist  das  gute  Antwortverhalten,  da  kaum  rechenintensive  Operationen 
anfallen. 

Nachteile  sind  die  zum  Teil  deutlich  höheren  Datenvolumen,  die  mit  der  Anzahl  der 
Dimensionen und Tiefe der Hierarchie polynominal ansteigen und die geringere Flexibilität, 
da nur eine begrenzte Anzahl von Dimensionen dargestellt und angezeigt werden kann. 

Ein  weiterer  Nachteil  kann  die  mangelnde  Aktualität  der  Daten  sein,  da  sie  auf 
vorberechneten Daten besteht, die eventuell nur einmal am Tag aktualisiert wird. 

2.3.3. Hybrides OLAP (H­OLAP) 
Das  hybride  OLAP  soll  die  Vorteile  des  R‐OLAP  und  M‐OLAP  vereinen.  Oft  genutzte 
Kennzahlen  und  Verdichtungen  werden  wie  beim  M‐OLAP  vorberechnet  und 
multidimensional  gespeichert.  Die  Detaildaten  aus  den  operativen  Systemen  werden 
weiterhin in einer relationalen Datenbank gespeichert.  Je nach Abfrage werden die Daten 
der Datenbanken entnommen und eventuell noch zusätzlich aggregiert. 

 
Abbildung 2‐4: Systemebenen eines H‐OLAP Systems12 

3. Methoden zur Datenanalyse 
Die  zu  analysierenden  Daten  bestehen  aus  Fakten‐  und  Dimensionstabellen,  die  in 
verschiedenen  Hierarchien  vorhanden  sind.  Theoretisch  ist  die  Anzahl  der  Dimensionen 
unbegrenzt.  In  der  Praxis  beschränkt  man  sich  allerdings  meist  auf  Dimensionen  im 
einstelligen  und  niedrigen  zweistelligen  Bereich 13 .    Die  kognitiven  Fähigkeiten  des 
Menschen  und  die  typischen  betriebswirtschaftlichen  Fragestellungen  sind  hier  die 
beschränkenden Elemente.  

                                                            
12
 Quelle: Eigene Darstellung in Anlehnung an Gluchowski, P.: Folien Management Support Systems, 
Ruhr‐Universität Bochum 
13
 Vgl.  Kemper,  H.G.  et  al.,  Business  Intelligence  –  Grundlagen  und  praktische  Anwendung,  Vieweg 
Verlag, S. 95 

  Seite  7| 19 
Methoden zur Datenanalyse    Seite  8| 19 

Korth, Silberschatz definieren Fakten als „Measure attributes“, also numerische Werte die 
Etwas  in  Mengen  ausdrücken  zum  Beispiel  die  Anzahl  belegter  Betten  in  einem 
Krankenhaus zu einem bestimmten Zeitpunkt. 

Dimensionen bzw. „Dimension attributes“ dienen der Beschreibung eines Faktenwertes. Sie 
werden  dazu  genutzt,  die  Faktendaten  unterschiedlich  zu  gruppieren  und  zu  aggregieren, 
um  eine  betriebswirtschaftliche  Fragestellung  zu  beantworten. 14  Für  das 
Krankenhausbeispiel wären Fachrichtung, Ort und  Zeit denkbare Dimensionen. 

Um  die  Multidimensionalität  verständlich  zu  erklären  wird  das  Bild  des  Würfels  genutzt. 
Dieser wird als „Hypercube“ bezeichnet. 

 
Abbildung 3‐1: Entwicklung eines Hypercubes anhand der Fahlzahlen in einem Krankenhausverbund15 

Die  Hierarchien  ermöglichen  eine  Betrachtung  von  Fakten  in  unterschiedlichen 


Ausprägungen  und  Verdichtungsstufen.  Im  Beispiel  der  Fallzahlen  in  einem  Krankenhaus 
wären  Hierarchiestufen  wie  Fachrichtung,  Klinik  und  Gesamtunternehmen  mögliche 
Ausprägungen.  

Um  die  Daten  zu  analysieren,  gibt  es  verschiedene  Operationen,  auf  die  im  Folgenden 
näher eingegangen werden soll. 

3.1. Pivoting / Rotation 
Bei der Pivotierung bzw. Rotation wird der Würfel um eine seiner Achsen gedreht. Dadurch 
richtet  sich  der  Blick  der  Analyse  auf  eine  andere  Dimension,  was  die  Interpretation 
vereinfachen kann. 

Die Abbildung zeigt eine Drehung um 90° (eine Dimension des Würfels) um die horizontale 
Achse.  
                                                            
14
 Vgl: Korth, Silberschatz, Database System Concepts, 5th Edition, S. 726 
15
 Quelle: Eigene Darstellung 

  Seite  8| 19 
Methoden zur Datenanalyse    Seite  9| 19 

Rotationsachse

Ort

Ort

g
un
ht
it
Ze

ric
Fach
richt Zeit

ch
u ng

Fa
     
Abbildung 3‐2: Pivoting bzw. Rotation eines Hypercubes16 

3.2. Slicing & Dicing 
Da  es  sich  bei  Hypercubes  um  große  Datenmengen  handelt  gibt  es  auch  Methoden  um 
Daten zu filtern, denn es sind meistens nicht alle Daten interessant. Bei dem Slicing werden 
Auswertungen auf bestimmte Dimensionen beschränkt. Im ersten Bild werden zum Beispiel 
nur eine Fachrichtung, aber alle Monate (Zeit) und alle Kliniken (Ort) ausgewählt. 

 
Abbildung 3‐3: Slicing (vertikal) eines Hypercubes17 

Dieser  vertikale  Filter  kann  ebenso  horizontal  genutzt  werden,  wobei  immer  zu  beachten 
ist, dass es sich in diesem Beispiel um einen einfachen dreidimensionalen Würfel handelt. 
Die Filterung in multidimensionalen Räumen ist kaum visuell darstellbar. 

Das  horizontale  Beispiel  beschränkt  den  Filter  auf  einen  bestimmten  Ort,  während  alle 
Zeiten und Fachrichtungen angezeigt werden.  

                                                            
16
 Quelle: Eigene Darstellung 
17
 Quelle: Eigene Darstellung 

  Seite  9| 19 
Methoden zur Datenanalyse    Seite  10| 19 

 
Abbildung 3‐4: Slicing (horizontal) eines Hpercubes18 

Das  Dicing  ist  dem  Slicing  sehr  ähnlich,  hier  werden  aber  statt  einer  Dimension  gleich 
mehrere  Dimensionen  beschränkt/gefiltert.  Dadurch  erhält  man  einen  neuen  Hypercube, 
bzw. einen Ausschnitt des ungefilterten Hpercubes. 

Im Beispiel werden alle drei Dimensionen beschränkt, so dass nur die Fallzahl für eine Klinik 
(Ort) in einem Fachbereich in einem bestimmten Monat (Zeit) angezeigt wird.  

 
Abbildung 3‐5: Dicing eines Hypercubes19 

Oft  wird  das  Dicing  auch  als  Ranging  bezeichnet,  da  aus  den  Dimensionen  nur  ein 
bestimmter Bereich bzw. Raum ausgewählt wird. 

3.3. Roll­up & Drill­down 
Die  Methoden  Roll‐up  und  Drill‐down  werden  verwendet  um  zwischen  verschiedenen 
Hierarchiestufen zu wechseln. Bei einem Drill‐down wird von einem Aggregationsniveau auf 
das  nächste  darunterliegende,  mehr  detailierte  Niveau  gewechselt.  Die  Tabellen  Tab.  3‐1 
stellen den Unterschied zweier  Hierarchiestufen  dar.   Einmal die  aggregierte  Sicht auf ein 
Quartal  und  nach  dem  Drill‐down  die  Fallzahlen  auf  die  Monate  Januar  bis  März 
aufgeschlüsselt. 

   

                                                            
18
 Quelle: Eigene Darstellung 
19
 Quelle: Eigene Darstellung 

  Seite  10| 19 
Methoden zur Datenanalyse    Seite  11| 19 

Chirurgie Gyn/Geb Innere


1. Quartal 810 659 1.335
 
Drill‐down  Roll‐up
 

Chirurgie Gyn/Geb Innere


Jan 263 212 465
Feb 282 222 447
Mrz 265 225 423
Tab. 3‐1: Roll‐up und Drill‐down in einer 2‐dimensionalen Tabelle20 

Schon bei der Modellierung des Data‐Warehouse muss überdacht werden, bis auf welchen 
Detailierungsgrad die Daten aufgelöst werden sollen. Eine detailliertere Darstellung als die 
Basisdaten besitzen ist im Nachhinein nicht mehr möglich. 

3.4. Drill­through & Drill­across 
Der  Drill‐through,  oder  die  oft  auch  als  „OLAP  Join“  bezeichnete  Operation stellt 
beispielsweise  analog  zur  Verbund‐Operation  bei  der  Verknüpfung  von  Tabellen  in 
relationalen  Datenbanksystemen  eine  Verbindung  zwischen  mehreren  Hypercubes  her. 
Voraussetzung  hierfür  sind  gemeinsame  Dimensionen  zwischen  den  zu  verknüpfenden 
Datenwürfeln. 

                                                            
20
 Quelle:  Eigene  Darstellung  in  Anlehnung  an  Goeken,  M.:  Entwickung  von  Data‐Warehouse‐
Systemen, Universitäts‐Verlag, 2006, S. 97 
 

  Seite  11| 19 
Methoden zur Datenanalyse    Seite  12| 19 

 
Abbildung  3‐6:  Drill‐through  bzw.  OLAP‐join  über  zwei  Hypercubes  mit  Division,  zur  Generierung  neuer 
Kennzahlen21 

Der Drill‐across  erweitert die horizontalen Recherchemöglichkeiten, indem er den Wechsel 
zwischen Hypercubes ermöglicht. Damit ist es möglich, eine Kennzahl über mehrere Würfel, 
die  eine  Wertkette  bilden,  zu  verfolgen.  Dabei  ist  zu  beachten,  dass  die  Dimensionen  der 
einzelnen Würfel die gleiche Granularität aufweisen müssen.  

3.5. Split & Merge 
Der Split ist eine Methode um die Werte (Daten) nach weiteren Dimensionen aufzuspalten.  
So  kann  der  aggregierten  Sicht  eine  weitere  Dimension  hinzugefügt  werden  um 
detailliertere Informationen zu erhalten. 

                                                            
21
 Quelle: Eigene Darstellung in Anlehnung an Manhart, K.: Ad‐hoc Analysen mit OLAP,  Universität 
Bamberg 

  Seite  12| 19 
Einführung und Entwicklung eines OLAP‐Systems    Seite  13| 19 

Im  Krankenhausbeispiel  werden  in  der  ersten  Tabelle  die  Fallzahlen  anhand  des  Monats 
und  der  Fachrichtung  summiert.  In  der  zweiten  Tabelle  wird  noch  die  Dimension  Ort  mit 
einbezogen; nun ergeben sich detailliertere Informationen zu den Fallzahlen.  

Daten
Summe von Summe von Summe von
Fachrichtung Jan Feb Mrz
Chirurgie 518 534 508
Gyn/Geb 271 265 300
Innere 816 753 728
Gesamtergebnis 1605 1552 1536
 
Split  Merge
 

Daten
Summe von Summe von Summe von
Ort Fachrichtung Jan Feb Mrz
Husum Chirurgie 263 282 265
Gyn/Geb 212 222 225
Innere 465 447 423
Niebüll Chirurgie 169 165 163
Gyn/Geb 59 43 75
Innere 260 237 232
Tönning Chirurgie 86 87 80
Gyn/Geb 0 0 0
Innere 91 69 73
Gesamtergebnis 1605 1552 1536
Tab. 3‐2: Pivottabelle zur Demonstration von Split und Merge22 

Wenn  man  den  umgekehrten  Weg  geht,  also  Dimensionen  entfernt  um  eine  höher 
aggregierte  Sicht  zu  erhalten,  nennt  man  dies  Merge.  Die  Daten  werden  wieder 
zusammengeführt. 

4. Einführung und Entwicklung eines OLAP­Systems 
Damit  alle  genannten  Funktionen  zielführend  genutzt  werden  können,  ist  es  unerlässlich 
einen großen Teil der Arbeitszeit bei der Erstellung und Einführung eines OLAP‐Systems in 
die  Anforderungsanalyse  zu  investieren.  Da  ein  OLAP‐System  die  unterschiedlichsten 
Adressaten  hat  (z.B.  Abteilungsleiter,  Vorstand,  Controller)  muss  ein  solches  Projekt 
interdisziplinär angegangen und abgestimmt werden. Die Schaffung einer guten Datenbasis, 
die  sich  nach  den  Anforderungen  der  Anwender  auswerten  lässt  ist  ein  wesentlicher 
Grundstein.  

Um  eine  Entscheidung  für  ein  bestimmtes  Produkt  zu  treffen,  gibt  es  wesentliche 
Auswahlkriterien,  denen  größere  Beachtung  geschenkt  werden  sollte.  Das  erste  Kriterium 
ist  die  Architekturvariante,  die  schon  in  Kapitel  2.3  vorgestellt  wurden.  Soll  also  ein 
relationales,  ein  proprietär  multidimensionales  oder  hybrides  Modell  genutzt  werden?23  

                                                            
22
 Quelle: Eigene Darstellung 
23
 Vgl.  Bauer,  A.  und  Günzel,  H.,  Data‐Warehouse‐Systeme,  Architektur‐Entwicklung‐Anwendung, 
dpunkt Verlag, 2001, S. 403 

  Seite  13| 19 
Einführung und Entwicklung eines OLAP‐Systems    Seite  14| 19 

Ein  weiteres  Kriterium  ist  die  Präsentationsschicht.  Hier  gibt  es  unterschiedlichste 
Ausprägungen.  Der  OLAP‐Würfel  kann  direkt  am  Client  oder  auf  einem  Server  erzeugt 
werden. Das Frontend kann ein Fat‐ oder Thinclient sein, es gibt webbasierte Systeme oder 
eigene Clientsoftware. Eventuell wird auch ein Standardprogramm wie Microsoft Excel oder 
SPSS genutzt.24   Drittens sind die möglichen Schnittstellen zu beachten. Hier stellt sich die 
Frage, welche Subsysteme angeschlossen werden sollen und wie ein performanter Zugriff 
erfolgen  kann.  Standard  Schnittstellen  wie  ODBC,  ADO  oder  OLE  DB  bieten  dabei  meist 
nicht  die  gewünschte  Zugriffsgeschwindigkeit,  wie  zum  Beispiel  spezielle  native  SQL 
Schnittstellen oder herstellerbedingte Abfragesprachen wie MDX von Microsoft.25 

Als  viertes  Kriterium  ist  die  Definition  des  multidimensionalen  Datenmodells  zu  nennen, 
hier  stehen  viele  Branchenlösungen  zur  Auswahl.  Ein  großer  Vorteil  ist  die  Bereitstellung 
von  Hierarchien,  die  branchenspezifisch  vordefiniert  sind.  Dem  gegenüber  gibt  es  auch 
Hersteller  von  branchenunabhängigen  Systemen,  bei  denen  der  Entwicklungsaufwand 
höher ist, aber eventuell ein größerer Spielraum bei Definition und Skalierung besteht. 

Entscheidungsrelevant  sind  auch  die  Analysefunktionalitäten,  die  schon  in  Kapitel  3 


erläutert wurden und Reportingfunktionen, die meist in die Präsentationsschicht bzw. das 
Frontend  integriert  sind.  Abschließend  seien  noch  die  Kriterien  des 
Berechtigungskonzepts 26  und  der  Entwicklungsumgebung 27  genannt.  Die  Kriterien  eines 
OLAP‐Systems  und  die  eines  Datawarehouses  sind  nicht  trennscharf  voneinander 
abzugrenzen, da sie voneinander abhängen und sich gegenseitig beeinflussen. 

Die  Auswahl  der  zugrunde  liegenden  Hardware  sollte  immer  erst  nach  der  Produktwahl 
erfolgen.  Bei  einer  vorzeitigen  Festlegung  der  Hardware  wird  die  Flexibilität  bei  der 
Auswahl eines passenden OLAP‐Systems zu sehr eingeschränkt.  

Dies ist nur ein grober Überblick über die verschiedenen Kriterien, die bei einer Entwicklung 
und  Einführung  eines  OLAP‐Systems  beachtet  werden  sollten.  In  der  Literatur  finden  sich 
darüber  hinaus  unzählige  Kriterienkataloge,  Best‐Practices  und  Projektpläne,  die  bei  einer 
Umsetzung zu Rate gezogen werden können.  

                                                            
24
 Vgl.  Bauer,  A.  und  Günzel,  H.,  Data‐Warehouse‐Systeme,  Architektur‐Entwicklung‐Anwendung, 
dpunkt Verlag, 2001, S. 402 
25
 Vgl. Microsoft Developer Network, MDX,  
http://msdn.microsoft.com/en‐us/library/aa216767(SQL.80).aspx 
26
 Vgl. Kemper, H.G. et al., Business Intelligence – Grundlagen und praktische Anwendung, S. 50 
27
 Vgl.  Bauer,  A.  und  Günzel,  H.,  Data‐Warehouse‐Systeme,  Architektur‐Entwicklung‐Anwendung, 
dpunkt Verlag, 2001, S. 407 

  Seite  14| 19 
Literaturverzeichnis    Seite  V| 19 

Literaturverzeichnis 
H. F. Korth, A. Silberschatz, S. Sudarshan, Database System Concepts, 5th Edition, McGraw‐
Hill, 2005 

K.  Manhart,    Ad‐hoc  Analysen  mit  OLAP,    Universität  Bamberg, 


http://www.tecchannel.de/server/sql/1751285/bi_methoden_teil_1_ad_hoc_analysen_mit
_olap/ (aufgerufen am 20.12.2008) 

J. Mena, Datamining your Website, Digital Press, 1999 

M.  Goeken,    Entwicklung  von  Data‐Warehouse‐Systemen,  Deutscher  Universitäts‐Verlag, 


2006 

E.  F.  Codd  et  al.,  Providing  OLAP  to  User‐Analysts:  An  IT  Mandate,  Hyperion  Solutions, 
1993 

N. Pendse,  What is OLAP?, http://olapreport.com/fasmi.htm (aufgerufen am 24.11.2008) 

P. Gluchowski, Foliensatz Management Support Systems, Ruhr‐Universität Bochum 

H.  G.  Kemper  et  al.,  Business  Intelligence  –  Grundlagen  und  praktische  Anwendung, 
Vieweg Verlag, 2. Auflage, 2006 

A.  Bauer,  H.  Günzel,  Data‐Warehouse‐Systeme,  Architektur‐Entwicklung‐Anwendung, 


dpunkt Verlag, 2001 

Microsoft  Developer  Network,  MDX,  http://msdn.microsoft.com/en‐


us/library/aa216767(SQL.80).aspx (aufgerufen am 15.12.2008) 

  Seite  V| 19