Entwicklung eines Kennzahlen-Monitors als Managementunterstützung im Non-Profit Unternehmen

Inhaltsverzeichnis

1. Einleitung
1.1. Unternehmen
1.2. Problemstellung
1.3. Ziele

2. Business Intelligence
2.1. Begriffsklärung
2.2. Data Warehouse
2.3. Online Analytical Processing (OLAP)
2.3.1. Datenhaltung
2.3.2. Datenmodellierung
2.3.3. Historisierung
2.3.4. Navigation im multidimensionalen Datenraum
2.4. Transformationsprozess
2.5. Reporting

3. Webanwendungen
3.1. Technologie
3.2. Serverstruktur
3.2.1. Webcontainer
3.2.2. Multi-Tier-Modell
3.2.3. Datenbankanbindung
3.3. Software-Architektur
3.4. Java Webanwendungen
3.4.1. Deployment Descriptor
3.4.2. Servlets
3.4.3. Filter
3.4.4. Java Server Pages
3.4.5. Session-Tracking
3.4.6. Sicherheit
3.5. JFreeChart

4. Planung
4.1. Datenquellen
4.1.1. Fahrdienst
4.1.2. Rettungsdienst
4.2. Datenintegration
4.3. Datenbank
4.3.1. Datenmodell
4.3.2. Datenanalyse
4.4. Berichtssystem
4.4.1. Zeitbezug
4.4.2. Gruppierungen & Filter
4.4.3. Startseite
4.4.4. Sicherheit

5. Entwicklung
5.1. ETL-Prozess
5.1.1. Filterung
5.1.2. Harmonisierung
5.1.3. Aggregation
5.1.4. Historisierung
5.1.5. Faktentabelle
5.1.6. Anreicherung
5.2. Datenanalyse
5.3. Webanwendung
5.3.1. Model
5.3.2. Controller
5.3.3. View

6. Ergebnisse
6.1. Datenintegration
6.2. Data Warehouse
6.3. Berichtssystem
6.4. Zusammenfassung
6.5. Ausblick

Literaturverzeichnis

Abbildungsverzeichnis

Abkürzungsverzeichnis

1 Einleitung

Business Intelligence ist ein Begriff, der aus der modernen Unternehmensführung nicht mehr wegzudenken ist. Um sinnvoll wirtschaften zu können benötigen Manager einen um­fassenden Uberblick über das komplette Unternehmen. Diesen Uberblick kann man sich nur verschaffen, indem Systeme entwickelt und eingeführt werden, die aus einer Vielzahl von Datenquellen Informationen sammeln, auswerten und dynamisch präsentieren. Um Unternehmensziele festlegen und diese erreichen zu künnen benotigt die Geschaftsführung valide Zahlen und Daten aus allen Teilen der Organisation. Mit anderen Worten: Um nachhaltige Entscheidungen treffen zu künnen, braucht man mehr als nur reine Intui­tion.¹ Als Grundgerust und Teil einer erweiterbaren Business Intelligence Lüsung soll in dieser Arbeit anhand einer konkreten Implementation ein Konzept diskutiert werden, nach dem Daten im Unternehmen gesammelt und ausgewertet werden künnen um der Geschüftsführung diesen besagten Uberblick zu verschaffen. Tatsache ist allerdings auch, dass innerhalb dieser Arbeit kein vollstaündiges System entwickelt werden kann, das alle Anspruüche, die unternehmensweit an ein Auswertesystem interner Informationen gestellt werden, erfüllen kann. Dennoch besteht die Moglichkeit, einen Ansatz zu schaffen, der durch ein kontinuierliches Fortführen des Gesamtprojekts in naher Zukunft zu einem weitreichenden System ausgebaut werden kann. Dies erfordert jedoch die Einhaltung der Grundsütze der Business Intelligence und die Zuhilfenahme von Technologien und Ent­wicklungsinstrumenten, die dem aktuellen Stand der Technik entsprechen, aber für die Große des Unternehmens und die Komplexität der geplanten Auswertungen angemessen sind. Die Nutzung von OpenSource Implementationen bietet hierfür eine geeignete Alter­native zu kommerziellen Produkten und lüsst zudem einen Kostenrahmen für das Projekt zu, der nicht uüberproportional zum Ergebnis steht.

1.1. Unternehmen

Das Bayerische Rote Kreuz (BRK), das als einziger deutscher Rotkreuz-Landesverband keinen eingetragenen Verein, sondern eine Korperschaft des offentlichen Rechts darstellt, ist organisiert in 5 Bezirksverbünde, die sich weiterhin in 73 Kreisverbande unterteilen. Der Kreisverband Neuburg-Schrobenhausen besteht aus der Kreisgeschüaftsstelle, zwei Ret­tungswachen, einem Seniorenheim sowie zwei Kindergüarten und diversen weiteren Ein­richtungen, die von der Auslandshilfe für Rumanien bis zu einem Mobelmarkt reichen. Der Kreisverband stellt durch jeweils eine 24 Stunden besetzte Rettungswache in Neu­burg und Schrobenhausen mit insgesamt drei Rettungswagen, zwei Notarztstandorten und vier Krankenwagen den öffentlich-rechtlichen Rettungsdienst für den kompletten Land­kreis und bietet einen betreuten Patientenfahrdienst an.

1.2. Problemstellung

Die Notwendigkeit für ein managementunterstützendes ]System und damit die Aufgaben­stellung für diese Arbeit ergibt sich aus mehreren Gründen. Zum einen stellt sich das Problem eines sehr geringen Informationsflusses ausgehend von den Fachbereichen zur Geschaftsleitung dar. Dieses resultiert vor allem aus der Tatsache, dass Ergebnisse und Daten aus den Geschaftsprozessen oft nicht direkt an die Führung weitergegeben werden, sondern bedingt durch eine Zentralisierung von Informationssystemen, über den Umweg zentraler Einrichtungen der Landesgeschaftsstelle ausgewertet und erst zeitversetzt und konsolidiert an die untergeordneten Organisationen zurückgemeldet werden. Eine strate­gische Planung und die Steuerung des Kreisverbands erfordert allerdings aktuelle Zahlen, die bisher von den Abteilungen in dieser Form nicht zur Verfügung gestellt werden können. Als zweiter Ansatzpunkt ist die von der Geschaüftsleitung gewuünschte umfassende Auswer­tung von internen Informationen zu nennen, die unter anderem aus dem Blickwinkel eines unternehmensweiten Qualitütsmanagements, einen detaillierten Uberblick über die wirt­schaftliche Lage des Unternehmens hervorbringen soll.

1.3. Ziele

Die Ziele für das Gesamtprojekt ergeben sich aus den Anforderungen, die vom Manage­ment an das Business Intelligence System gestellt werden. Diese Gesamtziele lassen sich auch für diese Arbeit ableiten, mit der Einschränkung, dass das System zunachst aus­schließlich für die Bereiche Fahrdienst und Rettungsdienst entwickelt wird. Die primaren Ziele sind, neben dem Anspruch, dass der Informationsfluss moglichst ohne Aufforde­rung ausgehend von den Fachbereichen zur Geschaftsleitung stattfindet, die Aktualitat und Validitüat der Informationen. Um die Auswertungen mit aktuellem Zahlenmaterial durchführen zu konnen, muss ein Mechanismus entworfen werden, der die Datensatze aus den Informationssystemen der Abteilungen in regelmüaßigen Abstüanden erfasst und in ein Datenmodell einfließen lüsst, welches den Mittelpunkt des Systems darstellt. Diese Peri­oden sollten den Zeitraum eines Monats nicht uüberschreiten, um zu gewüahrleisten, dass aktuelle Veränderungen frühzeitig ausgewertet und erkannt werden künnen. Die Validitat soll durch einen stabilen und fehlerfreien Transformationsprozess garantiert werden, der flexibel an Anderungen angepasst werden kann. Grundsützliche Prämissen für das Sys­tem sind seine Erweiterbarkeit und die Müglichkeit Veränderungen flexibel einarbeiten zu künnen.

Die Auswertungen sollen innerhalb einer ansprechenden, grafischen Benutzeroberflüche darstellt werden, die durch uübersichtlich gestaltete und leicht zu bedienende Navigati­onselemente dynamisch gesteuert werden kann. Die wichtigste Groüße in den Auswer­tungen stellt der Zeitbezug dar. Analysen sollen, gruppiert nach der Zeitdimension, in Diagrammen dargestellt werden, die durch die Visualisierung eine intuitivere Beurteilung der Informationen ermöglichen. Jedoch sollen diese zusätzlich durch exakte Wertetabel­len zu einem Gesamtüberblick vervollständigt werden. Der Bezug zur Zeitdimension soll zusätzlich durch die Moglichkeit realisiert werden, aktuelle Zahlen mit den Werten des Vorjahres zu vergleichen. Um den Überblick, der durch die aktuellen und vergangenen Informationen geschaffen wird, auch auf die Planung des Unternehmens auszuweiten, ist ein weiteres Ziel die Berechnung von Erwartungswerten, bzw. Forecasts für die Zeiträume in nächster Zukunft. Eine wichtige Aufgabe ist die Umsetzung von Sicherheitsaspekten, die die unternehmenskritischen Daten vor unberechtigtem Zugriff schutzen. Ansatzpunkt hierbei ist die Implementierung einer Login Funktionalitat, die unterschiedliche Berechti­gungsstrukturen unterstützt.

2 Business Intelligence

2.1. Begriffsklärung

Unter Business Intelligence (BI) versteht man in „Wissenschaft und Praxis [eine] neue Be- grifflichkeit für innovative IT-Lösungen der Unternehmenssteuerung.“¹ Erste Ansatze von Informationssystemen rein für die Geschaftsführung gab es bereits in den 60er Jahren. Um 1980 etablierte sich für diese Art von Software, bestehend aus einem „Konglomerat von Informations- und Kommunikationssystemen [erstmals] der Sammelbegriff Management Support Systems (MSS)“ ², der auch heute noch vor allem in der Wissenschaft gebräuchlich ist.

Die modernere Bezeichnung Business Intelligence, die aus den Grundsötzen der MSS- Systeme hervorging, beschreibt somit allerlei Softwaresystemen, die im weitesten Sinne mit der Unterstützung des Managements in Verbindung stehen. Zielsetzung ist die „Auf­bereitung von Daten und Informationen zur Verbesserung von betriebswirtschaftlichen Entscheidungen.“³ Entsprechende Losungen sind also auf die Analyse von vorhandenen Informationen ausgerichtet, die aus den operativen Datenbestünden extrahiert und über verschiedene Transformationsschritte in das Zielsystem geladen werden. Betrachtet man im engeren Sinne jedoch nur die Grundlage, auf dem ein BI-System aufgebaut ist, die al­so „die Entscheidungsfindung unmittelbar unterstützt“⁴, stüßt man vor allem auf Online Analytical Processing (OLAP). Der eigentliche Kern von Business Intelligence und ent­sprechenden Softwarelüosungen ist somit ein solides und durchdachtes Datenmodell, das darauf ausgelegt ist, in einer effizienten Art und Weise Informationen zu liefern, die durch den Menschen bewertet werden können.

2.2. Data Warehouse

Das Data Warehouse (DWH) ist das Datenhaltungssystem, das hinter der kompletten, unternehmensweiten BI-Lüsung steht. In der Regel ist das DWH durch ein logisch zen­tralisiertes Datenbankmanagementsystem (DBMS) implementiert, das die dispositiven Informationen getrennt von operativen Datenbestüanden bereitstellt. Hierbei ist eine kom­plette physikalische Zentralisierung nicht immer empfehlenswert, da mit wachsenden Da­tenvolumina und steigenden Benutzerzahlen vor allem Probleme bei der Performance zu erwarten sind. Jedoch stellt diese für kleinere Unternehmen mit überschaubaren Daten­mengen durchaus eine sinnvolle Losung dar. Ein dezentrales DWH kann über zweckorien- tierte, isolierte Data Marts realisiert werden, die als autonome Datenbanken innerhalb der einzelnen Fachabteilungen jeweils den spezifischen Teil des Data Warehouses darstellen. Diese Losung birgt, vergleichbar mit der Problematik der heterogenen operativen Daten­bestände, ebenfalls das Problem, dass fär unternehmensweite Analysen die Informationen zunachst aus mehreren Data Marts abgefragt und konsolidiert werden mässen.

Das Data Warehouse ist, um sich in den Komplex der Managementunterstätzung ein- zufägen, auch auf diese Art von Informationsbedarf ausgerichtet. Aufgrund der hohen Komplexitat stellt der Aufbau eines Data Warehouses mitunter die schwerste Aufgabe dar. Die „Integration der entscheidungsrelevanten Daten aus den unterschiedlichen operativen und externen Datenquellen“⁵ muss sorgfaltig durchgefährt werden um einen konsistenten und inhaltlich widerspruchsfreien Datenraum zu erlangen. Im Gegensatz zur operativen Datenhaltung, die sich durch ihre standige Veränderung auszeichnet, sind Informatio­nen im DWH dauerhaft gespeichert und stehen in ihrer Gesamtheit fär die Analyse zur Verfägung. Um dies zu gewahrleisten muss zum einen die notige Infrastruktur geschaffen werden, zum anderen mässen aber auch sinnvolle Historisierungsansatze gewahlt wer­den. Es sollte zudem in Betracht gezogen werden, ältere Daten beispielsweise aggregiert abzulegen um einen gewissen Grad an Komprimierung zu erreichen.⁶

2.3. Online Analytical Processing (OLAP)

OLAP bezeichnet ein Konzept der Datenhaltung, das „benutzerfreundlichen, flexiblen Ab­fragesystemen“ ⁷ zugrundeliegt. Operative Daten aus internen Geschaftsprozessen werden in einem multidimensionalen Datenraum bereitgestellt, der dynamische Analysen zulaässt. Im Gegensatz dazu steht das Online Transaction Processing (OLTP), dessen Architektur auf die hochperformante Abwicklung von Transaktionsprozessen ausgerichtet ist und oft­mals die Datenquelle fär BI-Applikationen darstellt. Eine mögliche Definition des Online Analytical Processing ist die Charakterisierung anhand von fänf grundsatzlichen Kriteri­en, die ein derartiges System erfällen muss:

- Reaktionszeit fär regulare Anfragen kleiner gleich 5 Sekunden.
- Die Ausrichtung auf Analyse und somit die Möglichkeit fär beliebige Benutzeran­fragen.
- Gleichzeitige Nutzung durch mehrere Benutzer, sowie unterschiedliche Berechti­gungsprofile.
- Multidimensionalität.
- Stabilitat von Auswertungen und Antwortzeiten auch bei großen Datenmengen.

Konsolidierend hat sich das Akronym FASMI für die kurze, prägnante Beschreibung „Fast analysis of shared multidimensional information“ etabliert. Unabhüngig von der tatsächlichen Anzahl an Dimensionen wird der Datenraum meist als OLAP-Würfel oder Hypercube, wie in Abbildung 2.1. dargestellt, bezeichnet.⁸ Die Notwendigkeit eines der­artigen Datenraums ergibt sich aus der Tatsache, dass auf dem Bildschirm stets nur zwei Dimensionen dargestellt werden küonnen. Die Wuürfelstruktur bietet verschiedene Naviga­tionsoperationen um durch manuelles, interaktives Umschalten alle Daten analysieren zu können.“⁹

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.: Hypercube und Dimensionen (aus [KMU06])

2.3.1. Datenhaltung

Die Multidimensionalitüat des Datenraums beschreibt grundsüatzlich nur die Draufsicht auf das Datenmodell, also die Sicht des Benutzers, der von oben auf den Entwurf des Analyse­modells blickt. Sie sagt aber nichts über die eigentliche, physikalische Datenhaltung aus. Abhaüngig von der verwendeten Technologie unterscheidet man zwischen einer relationa­ler Datenstruktur (R-OLAP), basierend auf einer herkommlichen relationalen Datenbank und einer multidimensionalen Struktur (M-OLAP), die von speziellen, proprietaren Da­tenbanksystemen implementiert wird. Die relationale Datenbank zeichnet sich vor allem durch ein hohes Maß an Stabilitat aus, die auch bei großen Datenvolumina und hohen Benutzerzahlen gewahrleistet ist. Im Gegensatz dazu sind multidimensionale Ansatze auf hohe Performance ausgelegt und erreichen deutlich bessere Abfragezeiten. Um die Vorzuge beider Varianten auszunutzen, kann man auch ein hybrides System (H-OLAP) verwenden. Dieses greift in hochaggregierten Datenbereichen auf ein multidimensionales Datenbank­ managementsystem zurück und geht bei der Navigation in detailliertere Bereiche in ein relationales DBMS über.¹⁰

Die Auswahl des Datenbanktyps hangt also davon ab, auf welchem Level von Granula- ritüt die Auswertungen stattfinden sollen, wie viel Datenvolumen einfließt und wie hoch die Komplexitüt der erwarteten oder geplanten Abfragen ist.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2.: R-OLAP, M-OLAP und H-OLAP (aus [KMU06])

2.3.2. Datenmodellierung

Das Ziel eines multidimensionalen Datenraums ist es, bereits in den Rohdaten für eine „Analyseausrichtung“¹¹ zu sorgen, um die Stabilitüt und Performance der spateren Ab­fragen zu gewahrleisten. Den Abfragen liegen in der Regel gleichartige Fragestellungen zugrunde:¹²

- „Wie hoch war der Umsatz von Produkt X in der Region Sud im ersten Quartal 2009?“
- „Welche Stückzahl von Produkt Y wurde dieses Jahr an einen bestimmten Kunden verkauft?“
- Wie hoch ist der durchschnittliche Umsatz durch den Krankentransport eines Pri­vatpatienten?“

Um die Antwort auf diese Fragestellungen moüglichst zielgerichtet und innerhalb einer angemessenen Reaktionszeit berechnen zu können, findet in den meisten Füllen das soge­nannte Star-Schema Verwendung. Dieses untergliedert sich in Fakten und Dimensionen. Fakten sind das Abbild der grundlegenden Informationen eines Prozesses, wie beispielswei­se eine Transaktion im Online-Shop, oder ein Einsatz des Rettungsdienstes. Dimensionen hingegen bilden die unterschiedlichen Sichtweisen auf die Fakten ab. Sie ermöglichen die Untergliederung von Kennzahlen, wie Umsatz öder Absatzmenge, aus der Faktentabelle in Teilmengen. Beispiele für gangige Dimensionen sind Zeit, Mitarbeiter, Abteilungen, Regionen, Patienten, Fahrzeuge, öder Ähnliches. Aufgrund der relativen Einfachheit der Abfragen aus betriebswirtschaftlicher Sicht, bewegt sich die Anzahl der benütigten Di­mensionen, um ein umfassendes Datenmodell zu erstellen, meist im einstelligen Bereich. Die Tabellen werden nicht in die Normalformen überführt, woraus sich diverse Vorteile ergeben:¹³

- Die Datenmodellierung wird intuitiver, das Datenmodell übersichtlicher und leichter verstüandlich.
- Durch die geringere Anzahl an Tabellen verringern sich auch die Join-Operationen in der Datenbankabfrage.
- Erleichterte Wartung, ebenfalls bedingt durch die einfachere Strukturierung des Datenmodells und der Data Warehouse Tabellen.

Eine Alternative ist das Snowflake-Schema, das seinen Namen aufgrund der optischen Ahnlichkeit des Datenmodells mit einer Schneeflocke tragt. Hier sind im Gegensatz zum Star-Schema die Dimensionstabellen teilweise oder auch vollstandig normalisiert. Vor al­lem bei sehr großen Datenmengen, und dementsprechend großen Tabellen, die die Di­mensionen abbilden, spielt dieser Unterschied eine tragende Rolle. Durch die Redundanz innerhalb der nicht normalisierten Daten wird viel zusaützlicher Speicherplatz belegt, den man durch die Überführung in eine der Normalformen sparen kann und der bei hohen Datenvolumina auch zu Geschwindigkeitseinbußen führen kann. Die Auswahl des passen­den Schemas sollte allerdings nicht zwanghaft auf theoretischen Fakten basieren, sondern viel mehr eine geeignete Lösung für die vorliegende Problematik darstellen.¹⁴

2.3.3. Historisierung

Eine elementare Aufgabe bei der Datenmodellierung stellt die Historisierung der Dimensi­onsdaten dar. Das Ziel der Historisierung ist es, „Anderungen von Attributsauspragungen, Beziehungen und Entitüten im Zeitablauf115 zu dokumentieren. Konzepte zur Historisie­rung betreffen aufgrund der Tatsache, dass in die Faktentabelle neue Daten im Prinzip nur hinzugefuügt werden und es kaum den Fall einer Aktualisierung gibt, nur die Dimensionen. In der Praxis bedeutet dies, dass wenn sich ein Eintrag in einer Dimensionstabelle andert, für die alteren Daten immer noch der vorherige Eintrag gültig sein muss, um die Auswer­tungen nicht zu verfüalschen. Güangiges Beispiel zu diesem Problem ist die Adressüanderung eines Kunden: Würde in der Dimension bei solch einem Fall nur die Adresse aktualisiert ohne jegliche Form der Historisierung, und man wertet zu einem spüteren Zeitpunkt die Umsatzentwicklung, unterteilt nach bestimmten Absatzregionen aus, würden alle Trans­aktionen die diesen Kunden betreffen, der neuen Adresse angerechnet werden, auch wenn sie zu einem früheren Zeitpunkt getatigt wurden und eigentlich der vorherigen Adresse und somit unter Umstanden einer anderen Region zugehürig würen.

Aufgrund der geringen Häufigkeit der Änderungen, die sich in den Dimensionen ereignen, spricht man auch von slowly changing dimensions. Grundsatzlich werden die Attribute in den Dimensionstabellen in zwei Typen unterteilt. Typ 1 bedeutet hierbei, dass keine Historisierung des Attributs durchgeführt werden muss. Typ 2 entspricht der Notwen­digkeit, die aktualisierten Attributsauspragungen zeitlich zu dokumentieren. Diese Unter­scheidung muss bei der Erstellung des Datenmodells für jedes Attribut einzeln getroffen werden. Es empfiehlt sich, nur bei Attributen, die unzweifelhaft eine Historisierung erfor­dern, den zweiten Typ zu waühlen, da in die Dimensionstabellen ansonsten bei jeglicher kleinen Veränderung des Inhalts eine neue Zeile eingefügt wird und diese dann relativ schnell sehr umfangreich werden küonnen. Zur Realisierung einer solchen Historisierung gibt es verschiedene Ansatze, wie im Folgenden beschrieben:¹⁵

Update-Verfahren

Das Update-Verfahren entspricht der bloßen Aktualisierung von Attributsauspragungen. Die vorhergehenden Werte werden hierbei durch neue Werte überschrieben. Diese Metho­de bietet keine Historisierungsfunktionalitat und wird somit nur für Attribute des ersten Typs angewendet.

Snapshot-Historisierung

Für Attribute vom Typ 2 kann das sogenannte Snapshot-Verfahren angewendet wer­den. Dieses sieht vor, dass bei jedem Laden von neuen Dimensionswerten, sowohl die geanderten, als auch die unveränderten Datensatze an die existierende Tabelle angehangt und mit einem Zeitstempel, der Datum und Uhrzeit vom Moment des Einfuügens beinhal­tet, versehen werden. Anhand dieses Zeitstempels kann anschließend die Zuordnung zu den jeweils guültigen Auspraügungen erfolgen. Ein Vorteil dieser Vorgehensweise ist, dass bei einer Gruppierung nach einer bestimmten Ausprüagung, aufgrund des gleichbleiben­den ID-Attributs, alle Versionen des Datensatzes automatisch mit einbezogen werden. Nachteilig auf die Performance wirkt sich jedoch die Schlüsselkombination aus ID und Timestamp aus, da diese bei Join-Operationen zu einem erhöhten Rechenaufwand führt. Diese Methode ist also nur zu empfehlen, wenn aus den Quelldaten keine „Information über Veränderungen [...] gewonnen werden konnen.“¹⁶

Delta-Historisierung

Eine etwas komplexere Methode stellt die Delta-Historisierung dar, die aber trotz ei­nem gewissen Mehraufwand zu bevorzugen ist. Neue Datensatze werden hierbei nur für die tatsächlich geänderten Daten eingefügt. Dies spart nicht nur Speicherplatz, sondern sorgt auch für eine lückenlose Nachvollziehbarkeit des Anderungsverlaufs. Für die Um­setzung dieses Konzeptes gibt es wiederum mehrere Möglichkeiten. Die gangigste An­wendung stellt die Current-Flag-Variante in Verbindung mit Datumsattributen, auch Gültigkeitsfelder genannt, dar. Diese dokumentiert den Zeitraum, in dem ein Datensatz gültig ist oder war. Die Current-Flag ist ein Boolescher Wert, der die Auspragungen gültig oder nicht gültig annehmen kann. Wie daraus ersichtlich wird, erhält jeweils der aktuell gültige Datensatz eine positive Current-Flag, alle vergangenen eine negative. Zusatzlich oder alternativ kann eine künstliche Schlüsselerweiterung eingesetzt werden, die dem primaren Schlüsselattribut der Dimensionstabelle eine Versionsnummer anhangt, oder ein zusützliches Attribut mit der Versionsnummer als Inhalt einfügt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3.: Delta-Historisierung mit Gültigkeitsfeldern (aus [KMU06])

2.3.4. Navigation im multidimensionalen Datenraum

Die Navigation im Datenraum wird nach den Grundsaützen der Business Intelligence durch wenige definierte Operationen beschrieben, die „den gezielten Ubergang von einem Bericht zum nüchsten“¹⁷ ermoglichen:¹⁸

Pivotierung

Pivotierung, oder auch Rotation, beschreibt das bildlich gesprochene Drehen des Würfels. Dies hat die Auswirkung, dass eine andere Kombination von Dimensionen, unter Beibe­haltung der sonstigen Gruppierungen und Filterungen, sichtbar wird. Dies eröffnet also den Blickwinkel auf die Fakten ausgehend von einer anderen Position. In der Praxis, wo meist nur ein „zweidimensionaler Ausschnitt aus dem Hypercube“ ¹⁹ zur Analyse betrach­tet wird, bewirkt diese Operation den Austausch einer Dimensionsgruppierung durch eine andere.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.4.: Pivotierung des Hypercubes (aus [KMU06])

Drill-down & Roll-up

Diese beiden Operationen ermöglichen die Navigation innerhalb einer Dimension des OLAP-Wurfels. Drill-down bedeutet, dass ein hoheres Maß an Granularitat bereitgestellt wird. Roll-up ist die inverse Operation, die den "Übergang zur nachst hoheren Stufe an Aggregation verursacht. Am Beispiel der Zeitdimension ware ein Drill-down, bei der aktu­ellen Darstellung von Quartalssummen, der Wechsel zur Anzeige von Monatssummen. In entgegengesetzter Richtung würde ein Roll-up die Daten auf die Jahreswerte aggregieren.

Drill-through & Drill-across

Eine erweiterte Navigation „uber den originüren multidimensionalen Datenraum hinaus“²⁰ ermüglichen die Operatoren Drill-through und Drill-across. Ein Drill-through kann ange­wendet werden, wenn durch Drill-down Navigation die hoüchste Stufe an Detaillierung erreicht wurde. Sie ermüoglicht an diesem Punkt den benutzertransparenten Üübergang auf eine andere Datenquelle und erweitert somit die „vertikale Recherche“²¹. Am Beispiel ei­nes Online-Shops ware dies eine Verfeinerung ausgehend von der Tagesebene, wenn diese die hoüchste Detaillierung im multidimensionalen Analysemodell darstellt, auf die Ebene der einzelnen Transaktionen. Transparent fur den Benutzer bedeutet in diesem Fall, dass dieser vom Wechsel der Datenquelle nichts mitbekommt, sich also die Oberfläche nicht merklich verändert.

[...]

¹ Vgl. [KMU06], S. 2

¹ [KMU06], S. V

² [KMU06], S. 1f.

³ [Eng09], S. 1

⁴ [KMU06], S. 3

⁵ [KMU06], S. 18

⁶ Vgl. [KMU06], S. 17-21

⁷ [KMU06], S. 93

⁸ Vgl. [KMU06], S. 94f.

⁹ [Eng09], S. 61f.

¹⁰ Vgl. [KMU06], S. 100

¹¹ [KMU06], S. 61

¹² Vgl. [KMU06], S. 61ff.

¹³ Vgl. [Eng09], S. 129ff.

¹⁴ Vgl. [KMU06], S. 62-65

¹⁵ [KMU06], S. 66

¹⁶ Vgl. [KMU06], S. 66-72

¹⁷ [KMU06], S. 70

¹⁸ [Eng09], S. 63

¹⁹ Vgl. [KMU06], S. 96-99

²⁰ [KMU06], S. 96

²¹ [KMU06], S. 97

²² [KMU06], S. 97