Datenbankperformance: Ist-Analyse und Optimierungskonzept am Beispiel einer Datenbank zu Analysezwecken in einem Krankenhaus

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Anlagenverzeichnis

Abkürzungsverzeichnis

1 Einleitung
1.1 Ausgangssituation
1.2 Fragestellung
1.3 Vorgehensweise

2 Grundlagen
2.1 Business Intelligence
2.1.1 Definition und Aufgaben
2.1.2 Analytische Informationssysteme
2.1.3 Abgrenzung operativer und analytischer Informationssysteme
2.2 Datawarehouses
2.2.1 Definition
2.2.2 Extract-Transform-Load-Prozess
2.2.3 Der Performancebegriff im Datenbankumfeld
2.2.4 Indizes

3 Ist-Analyse
3.1 Das betrachtete Unternehmen
3.1.1 Unternehmensvorstellung
3.1.2 Vorstellung der Systemlandschaft des Unternehmens
3.2 Eingesetzte Methoden
3.2.1 Messung der Datenbankperformance
3.2.2 Voraussetzungen für die eingesetzte Methodik
3.3 Strukturierte Analyse
3.3.1 Messergebnisse
3.3.2 Analyse der Messergebnisse für Berichtsabfragen
3.3.3 Analyse der Messergebnisse für ETL-Abfragen
3.4 Beurteilung des Ist-Zustandes
3.4.1 Bewertung der Dauer der Abfragen
3.4.2 Stärken und Schwächen des derzeitigen Zustandes

4 Konzept
4.1 Zielsetzung
4.1.1 Ziele
4.1.2 Operationalisierung der Ziele
4.1.3 Gewichtung der Ziele
4.2 Lösungsansatz
4.2.1 Übersicht
4.2.2 Optimierung der Servereinstellungen
4.2.3 Indexüberprüfung und Abfrageoptimierung
4.2.4 Speicher-Engines
4.2.5 Denormalisierung
4.2.6 Prä-Aggregation
4.2.7 Table Exchange Loading
4.2.8 Optimierungsmodell
4.3 Beurteilung des Konzeptes
4.3.1 Bewertung der methodischen Vorgehensweise
4.3.2 Einschätzung
4.3.3 Betriebswirtschaftliche Bewertung
4.3.4 Empfehlung zur Umsetzung des Konzeptes

5 Kritische Schlussbetrachtung
5.1 Betrachtung des Konzeptes
5.2 Ausblick
5.3 Technische Entwicklungen

6 Zusammenfassung

Anlagen

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 1 - Entwicklung Krankenhäuser

Abbildung 2 - Konzept Datawarehouse

Abbildung 3 - ETL-Prozess

Abbildung 4 - Systemlandschaft in der Städt. Klinikum Görlitz gGmbH

Abbildung 5 - Beispiel für Probleme durch Nebenläufigkeit

Abbildung 6 - Vergleich Abfragedauer und Datensätze nach JOIN-Operation

Abbildung 7 - Vergleich Abfragedauer und Datensätze nach SELECT-Operation

Abbildung 8 - Vergleich Abfragedauer und Anzahl der JOIN-Operationen

Abbildung 9 - Anteil Abfragen nach Abfragedauer

Abbildung 10 - Gegenüberstellung Probleme und Lösungsansätze

Abbildung 11 - ANSI/X3/SPARC - Datenbankarchitekturmodell

Abbildung 12 - Modifiziertes Vorgehen bei der Nutzung der MEMORY-Engine

Abbildung 13 - Beispiel für Normalisierung

Abbildung 14 - Beispiel für Granularitätsstufen bei der Aggregation

Abbildung 15 - Partition Exchange Loading

Abbildung 16 - Table Exchange Loading

Abbildung 17 - Optimierungsmodell

Tabellenverzeichnis

Tabelle 1 - Gegenüberstellung operative und analytische Informationssysteme

Tabelle 2 - Gruppen dynamischer Berichte

Tabelle 3 - Stärken und Schwächen des bestehenden Systems

Tabelle 4 - Zielhierarchie

Tabelle 5 - Beispiel für den Vergleich der Abfragedauern mehrerer Alternativen

Tabelle 6 - Gewichtete Zielhierarchie

Tabelle 7 - Vergleich Speicherengines

Tabelle 8 - Beispiel für Redundanzen

Tabelle 9 - Vergleich Denormalisierung

Tabelle 10 - Vergleich Prä-Aggregation

Tabelle 11 - Vergleich Table Exchange Loading

Tabelle 12 - Evaluation Konzept

Anlagenverzeichnis

Anlage 1 - Detaillierte Messwerte ausgewählter Abfragen

Anlage 2 - Vereinfachtes Modell der Ermittlung von Abfrageergebnissmengen

Anlage 3 - Vereinfachtes Beispiel für einen Query-Execution-Plan

Anlage 4 - Wichtige Servervariablen

Anlage 5 - Vergleich Speicher-Engines (ausführlich)

Anlage 6 - Vergleich Speicher-Engines (Messwerte)

Anlage 7 - Vergleich Denormalisierung (ausführlich)

Anlage 8 - Vergleich Denormalisierung (Messwerte)

Anlage 9 - Vergleich Prä-Aggregation (ausführlich)

Anlage 10 - Vergleich Prä-Aggregation (Messwerte)

Anlage 11 - Vergleich Table Exchange Loading (ausführlich)

Anlage 12 - Vergleich Table Exchange Loading (Messwerte)

Anlage 13 - Evaluation Konzept (ausführlich)

Anlage 14 - Evaluation Konzept (Geschätzte Messwerte)

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

1.1 Ausgangssituation

Die Krankenhäuser in der Bundesrepublik Deutschland sehen sich mit einem immer stärker werdenden Wettbewerb und wirtschaftlichen Druck konfrontiert. In der Abbildung 1 wird die Kostenentwicklung je Behandlungsfall, sowie die Anzahl der Krankenhäuser in der Bundesrepublik dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1 - Entwicklung Krankenhäuser (vgl. Statistisches Bundesamt, 2011)

Wie zu erkennen ist, sind die Behandlungskosten je Krankenhausfall in den letzten 20 Jahren massiv angestiegen. Hat ein Fall im Jahr 1991 durchschnittlich noch Kosten in Höhe von 2.567 € verursacht, waren es 2010 bereits 3.862 €. Dies entspricht einem Gesamtanstieg von 50,4 % innerhalb von 20 Jahren. Dieser Anstieg liegt primär in den steigenden Personalkosten, aber auch in der technischen Entwicklung begründet (z.B. bessere, aber teurere Medikamente und medizinische Geräte). In der Abbildung ist ebenfalls ein Rückgang der Anzahl der Krankenhäuser zu erkennen. Im Jahr 1991 gab es in der gesamten Bundesrepublik noch 2.411 Krankenhäuser, während es im Jahr 2010 nur noch 2.064 waren. Die Anzahl der Krankenhäuser hat also im Verlauf von 20 Jahren um 14,4% abgenommen. Dieser Rückgang liegt zu einem wesentlichen Teil in den gestiegenen Behandlungskosten je Fall begründet. Weiterhin wurden viele kleinere Krankenhäuser geschlossen, da die pauschalierte Vergütung von Krankenhausleistungen nicht kostendeckend ist, sofern ein Haus wenig Betten und somit einen hohen Fixkostenanteil hat.

Es ist daher nicht verwunderlich, dass den Krankenhäusern sehr viel an einer hohen Wirtschaftlichkeit liegt, um ihre Existenz nachhaltig sicherzustellen. Um dieses Ziel zu erreichen, bemühen sie sich, die Kosten- und Erlösstruktur zu optimieren. Hierfür stehen ihnen diverse Methoden zur Verfügung, wie z.B. die Folgenden:

- Effizientere Gestaltung des Leistungsportfolios, durch eine verstärkte Erbringung gewinnbringender Leistungen und Reduktion der Erbringung defizitärer Leistungen
- Effizientere Ressourcennutzung, z.B. durch Prozessoptimierung
- Steigerung der Qualität der Leistungserbringung und damit Vergrößerung des Marktanteils

Die genannten Beispiele setzen jedoch voraus, dass dem Unternehmen genug Informationen bereitstehen, um diese Methoden anwenden zu können. Eine Optimierung des Leistungsportfolios ist z.B. nicht möglich, wenn keine Informationen darüber vorliegen, welche Leistungen gewinnbringend und welche defizitär sind. Damit die Methoden optimal angewandt werden können, muss eine hohe Informationsdurchdringung im Unternehmen etabliert werden. Die Städtische Klinikum Görlitz gGmbH (SKGR), der Arbeitgeber des Autors und somit das betrachtete Unternehmen dieser Arbeit, verfolgt daher die Philosophie, ihre Mitarbeiter in allen Berufsgruppen mit konfektionierten Informationen zu versorgen, um ein besseres Verständnis für die wirtschaftlichen Auswirkungen ihres Handelns zu schaffen. Somit sollen die vorhandenen Ressourcen optimal genutzt werden, um ein möglichst gutes betriebswirtschaftliches Ergebnis zu erzielen. Dieser Ansatz hat sich in der Praxis als sehr nützlich erwiesen, da er sehr motivationssteigernd auf die Mitarbeiter wirkt und aufgezeigte Probleme konstruktiv und kooperativ angegangen werden. Auch in der Literatur wird er als positiv angesehen und daher, nicht nur im Krankenhausumfeld, branchenübergreifend eingesetzt (vgl. Krcmar, 2009, S. 1ff).

Eine wichtige Voraussetzung für diese umfangreiche Informationsbereitstellung besteht in der Verfügbarkeit von Daten, aus denen Informationen abgeleitet werden können. Diese Daten entstehen zu einem großen Teil aus den Datenbanken der operativen Anwendungssysteme (zum Teil aber auch aus statischen Informationen, die z.B. aus Tabellenkalkulationsprogrammen stammen). Der Einsatz von Datenbanken in den operativen Systemen hat den Vorteil, dass eine Trennung zwischen der Logik der Anwendungssysteme und der tatsächlichen Speicherung der Daten erfolgt. Hieraus ergibt sich die Möglichkeit, dass unterschiedliche Anwendungssysteme auf die gleiche Datenbasis zugreifen können (vgl. Mertens, 2010, S. 41f). Dieser Sachverhalt wird ausgenutzt, um die Daten der operativen Systeme auswerten und sie den Nutzern in einer strukturierten und konfektionierten Form bereitzustellen zu können. Diese strukturierte Bereitstellung ist jedoch sehr aufwendig, da der Datenumfang und die Komplexität der Datenstrukturen aufgrund der hohen IT-Durchdringung in den Unternehmen sehr hoch sind. Hierzu verwenden die Unternehmen Business-Intelligence (BI) Systeme, welche in den vergangenen Jahren branchenübergreifend an Popularität gewonnen haben (vgl. Simmank, 2012, S. 1f).

Ziel dieser Systeme ist es, dem Management der Unternehmen einen möglichst schnellen Zugriff auf eine flexible Informationsquelle zu geben. Dies setzt jedoch voraus, dass die BI-Systeme sehr leistungsfähig sind und trotz der hohen Komplexität der Daten schnell aussagekräftige Daten liefern. Müssen die Nutzer eines derartigen Systems lange auf Auswertungen warten, kann dies zu einer negativen Haltung gegenüber dem System führen, welche darin mündet, dass das System nicht, bzw. nicht im ausreichenden Maße genutzt wird. Aufgrund dessen wird auch in der EN ISO 9241-110, welche Qualitätsrichtlinien für dialoggesteuerte Anwendungen definiert, eine möglichst kurze Antwortzeit für Anwendungen gefordert (vgl. Handbuch Usability, 2007). Eine Verletzung dieses Grundsatzes ist gefährlich, da eine Nichtinanspruchnahme des Informationssystems dazu führen kann, dass das Management wichtige Chancen oder Risiken nicht bemerkt, welche im Informationssystem sofort ersichtlich gewesen wären.

Die SKGR setzt ebenfalls ein BI-System ein, welches vom Autor dieser Arbeit entwickelt worden ist. Dieses stellt dem Management viele Berichte zur Unternehmenssteuerung bereit. Allerdings stößt es hierbei an seine Leistungsgrenzen, da Datenmenge und Datenkomplexität sehr hoch sind. Aufgrund dessen sind auch die Abfragezeiten für einige Berichte sehr hoch. Dies ist auch der Grund dafür, dass im BI-System nicht alle Daten in einer dynamischen Form präsentiert werden. Einige Berichte werden den Nutzern periodisch in Form von statischen Berichten bereitgestellt, welche aufgrund ihrer fehlenden Aktualität nicht zwangsläufig ihren Anspruch erfüllen den Nutzern hilfreich zu sein, da Problemsituationen meist erst viel zu spät erkannt werden. Dadurch ist auch die Akzeptanz der Nutzer für dieses System gefährdet.

1.2 Fragestellung

Zielstellung dieser Arbeit ist es, der Städtischen Klinikum Görlitz gGmbH (SKGR) eine Methodik vorzuschlagen, die zur Optimierung der Datenbankperformance ihrer bestehenden Lösung dient. Dies soll dazu führen, dass allen Nutzern des Systems alle Berichte in einer akzeptablen Abfragezeit bereitgestellt werden und dass alle benötigten Berichte bereitgestellt werden können - auch solche, die bisher aufgrund ihrer Komplexität nicht erstellt werden konnten. Somit soll die Akzeptanz der Nutzer für das System gesteigert werden. Hierzu soll eine Methodik gefunden werden, mit welcher das bestehende System strukturiert analysiert und optimiert werden kann. Ziel der Optimierung ist es, alle bestehenden und zukünftigen Abfragen an die Datenbank so zu gestalten, dass sie den Bedürfnissen der SKGR genügen. Konkret soll hierbei die Abfragezeit für alle Abfragen in einer ausreichend kurzen Zeit erfolgen und es soll ebenfalls ermöglicht werden, auch sehr große und komplexe Abfragen auszuführen. Trotzdem soll das System keine unverhältnismäßig hohen Kosten verursachen, was den Anspruch an die BI-Software, die Wirtschaftlichkeit des Hauses zu verbessern, nivellieren würde. Um dies zu erreichen wird im Rahmen dieser Arbeit ein konzeptionelles Modell erarbeitet, welches von der SKGR zur Optimierung der Performance des bestehenden Systems genutzt werden kann. Weiterhin soll dieses Modell auch zur fortlaufenden Kontrolle der Performance des Systems genutzt werden können, sodass auch zukünftige Änderungen an der Datenbankstruktur zu keiner negativen Beeinflussung der Performance führen.

Es ist nicht Anspruch dieser Arbeit zu analysieren, inwiefern die verwendete Methodik auch für andere Branchen bzw. Unternehmen geeignet ist. Auch das Konzept wird konkret für die Situation in der SKGR erstellt. Grund für diese Einschränkung ist, dass aufgrund der unterschiedlichen Struktur und Implementierung der Anwendungssysteme in anderen Branchen bzw. Unternehmen die hier vorgestellten Optimierungsansätze evtl. völlig andere Ergebnisse aufweisen. Inwiefern diese Annahme tatsächlich zutrifft, kann aufgrund fehlenden Datenmaterials im Rahmen dieser Arbeit nicht untersucht werden.

Weiterhin wird kein Anspruch darauf erhoben, alle erdenklichen Performanceprobleme mit dem Konzept abzudecken, sondern nur solche, die für die Situation der SKGR relevant sind. Auch hier besteht das Problem, dass ohne entsprechendes Datenmaterial keine konkrete Aussage über den Nutzwert von Lösungsmöglichkeiten getroffen werden kann.

Ebenfalls ist es nicht Zielstellung dieser Arbeit, die Zweckmäßigkeit des Einsatzes einer Individuallösung in der SKGR zu diskutieren, da sie aufgrund bestimmter Anforderungen den Einsatz von Standardsoftware ablehnt. Vielmehr soll das Niveau der bestehenden Lösung durch den Einsatz moderner Techniken, welche dem Stand der Wissenschaft entsprechen, erhöht werden.

Da die Anwendung des Optimierungsmodells sehr viel Zeit in Anspruch nimmt, soll es auch nicht Ziel dieser Arbeit sein, eine vollständig optimierte Datenbank vorzustellen, sondern lediglich den potentiellen Nutzen des Modells zu evaluieren.

1.3 Vorgehensweise

Um die, in Kapitel 1.2 vorgestellte Fragestellung zu beantworten, werden zunächst in Kapitel 2 die notwendigen Grundlagen für diese Arbeit definiert. Zunächst wird hierzu erläutert, was im Rahmen dieser Arbeit unter dem Begriff Business Intelligence (BI) verstanden wird und welche Anwendungssysteme hierfür verwendet werden. Diese Systeme werden weiterhin von anderen Systemen abgegrenzt, in denen sich eine ähnliche Fragestellung ergeben könnte, die jedoch nicht Betrachtungsgegenstand dieser Arbeit sind. Im Anschluss wird die Datenquelle für die analytischen Informationssysteme vorgestellt (sog. Datawarehouses). Es wird erläutert, wie ein Datawarehouse seine Daten erhält und der Performancebegriff, welcher das Thema dieser Arbeit darstellt, wird erläutert. Abschließend wird in diesem Kapitel eine zentrale Technik zur Performancesteigerung erläutert, welche sich durch eine gewisse Omnipräsenz in dieser Arbeit auszeichnet.

In Kapitel 3 wird der aktuelle Ist-Zustand detailliert und strukturiert analysiert. Hierzu wird in Kapitel 3.1 zunächst das betrachtete Unternehmen vorgestellt, um ein besseres Verständnis für die angewandte Systematik zu schaffen. Im Anschluss wird in Kapitel 3.2 die angewandte Analyse-Methodik vorgestellt, mit deren Hilfe die Schwachstellen des Systems nachvollziehbar gemacht werden sollen. Hierzu werden auch diverse Voraussetzungen der angewandten Methodik erläutert. In Kapitel 3.3 wird die vorgestellte Methodik anschließend angewandt, um die Schwachstellen des Systems aufzufinden. Nachfolgend findet im Rahmen des Kapitels 3.4 eine strukturierte Beurteilung des Ist-Zustandes statt, in welcher die Stärken und Schwächen des bestehenden Systems zusammengefasst werden.

Basierend auf den Ergebnissen der Ist-Analyse, wird in Kapitel 4 ein Konzept entworfen, welches die ermittelten Schwächen eliminiert, ohne dabei die Stärken des bestehenden Systems zu sehr zu verletzen. Hierzu wird in Kapitel 4.1 zunächst eine detaillierte Zielhierarchie vorgestellt, in welcher die einzelnen Ziele quantifiziert und priorisiert erläutert werden. In Kapitel 4.2 wird anhand der ermittelten Zielhierarchie strukturiert nach Lösungsansätzen gesucht, mit denen die vorgestellte Zielstellung erreicht werden kann. Diese Lösungsansätze werden anschließend in Kapitel 4.3 nach verschiedenen Gesichtspunkten beurteilt. Basierend auf dieser Beurteilung wird abschließend eine Handlungsempfehlung an das Unternehmen bzgl. der Umsetzung des Konzeptes gegeben.

Nach der Vorstellung des Konzeptes wird in Kapitel 5 eine kritische Schlussbetrachtung durchgeführt. Hierzu findet zunächst in Kapitel 5.1 eine Betrachtung der kritischen Erfolgsfaktoren des Konzeptes statt. Anschließend wird in Kapitel 5.2 ein Ausblick gegeben, dessen Ziel es ist, die Übertragbarkeit des vorgestellten Konzeptes auf andere Situationen zu analysieren. In Kapitel 5.3 wird abschließend ein Überblick über zukünftige technologische Entwicklungen gegeben, welche im Rahmen zukünftiger Arbeiten zu dieser Thematik von Interesse sein könnten.

Abschließend wird in Kapitel 6 eine Zusammenfassung aller wesentlichen Aspekte dieser Arbeit gegeben.

2 Grundlagen

2.1 Business Intelligence

2.1.1 Definition und Aufgaben

Wie bereits in der Einleitung erwähnt, ist das BI-System der SKGR Hauptbetrachtungsgegenstand dieser Arbeit. Um ein besseres Verständnis für diverse Eingrenzungen zu geben welche in dieser Arbeit getroffen werden, wird im Rahmen dieses Kapitels zunächst definiert, was unter dem Begriff der BI verstanden wird, und welche Aufgaben die BI erfüllen muss. In der Wissenschaft existieren viele unterschiedliche Definitionen für diesen Begriff, welche ihm unterschiedliche Aufgaben zuordnen.

„Ein Grundkonsens besteht dabei darin, dass die Techniken und Anwendungen der Business Intelligence entscheidungsunterstützenden Charakter aufweisen sowie zur besseren Einsicht in das eigene Geschäft und damit zum besseren Verständnis in die Mechanismen relevanter Wirkungsketten führen sollen.“ (Gluchowski, Gabriel, & Dittmar, 2008, S. 9)

Dieser Konsens ist zwar sehr allgemein gehalten, bietet jedoch eine gute Basis für diese Arbeit, da er die primäre Zielstellung wiederspiegelt, welche auch die SKGR mit der BI verfolgt. Es ist jedoch wichtig, diese grob formulierte Zielstellung detaillierter darzustellen, um daraus die Aufgaben der BI ableiten zu können. Mertens fand in einer 2002 durchgeführten Untersuchung sieben verschiedene Eingrenzungen für den Begriff BI:

1. BI als Fortsetzung der Daten- und Informationsverarbeitung (IV): IV für die Unternehmensleitung
2. BI als Filter in der Informationsflut: Informationslogistik
3. BI = Management Informationssysteme, aber besonders schnelle / flexible Auswertungen
4. BI als Frühwarnsystem („Alerting“)
5. BI = Data Warehouse
6. BI als Informations- und Wissensspeicherung
7. BI als Prozess: Symptomerhebung à Diagnose à Therapie à Prognose à Therapiekontrolle (vgl. Mertens, 2002, S. 4)

Diese Auflistung möglicher Definitionen ist wahrscheinlich nicht vollständig, doch bietet sie einen guten Überblick über mögliche Aufgaben, die mit dem Begriff der BI assoziiert werden können. Primäre Aufgabe der BI ist die schnelle Bereitstellung von flexiblen Informationen, welche die Führungskräfte eines Unternehmens zur Entscheidungsvorbereitung nutzen können. Diese Informationen müssen an die Bedürfnisse der jeweiligen Empfänger angepasst sein, um einen Informations-Overflow zu vermeiden, durch den mögliche, brisante Informationen übersehen werden könnten. Weiterhin muss die BI auch die Kontrolle von operativen und strategischen Entscheidungen ermöglichen und als Frühwarnsystem dienen.

Die oben genannten Aufgaben verdeutlichen, dass die Fragestellung dieser Arbeit nicht trivial ist, da das betrachtete System nicht alle Kriterien zufriedenstellend erfüllt. Wie eingangs bereits erwähnt, werden nicht alle Abfragen an das System schnell ausgeführt. Weiterhin werden einige Berichte nur in statischer Form bereitgestellt, was der Forderung nach Flexibilität widerspricht.

Laut Mertens wird der Begriff häufig auch synonym mit den Systemen verwendet, welche die oben genannten Aufgaben erfüllen sollen. Dies ist nach Meinung des Autors jedoch nicht zweckmäßig, da somit keine klare Abgrenzung existiert. Im Rahmen dieser Arbeit werden daher die Systeme, welche diese Aufgaben erfüllen, als BI-Systeme bzw. analytische Informationssysteme bezeichnet.

2.1.2 Analytische Informationssysteme

Um die Aufgaben der BI (vgl. Kapitel 2.1.1) zu erfüllen, müssen Daten verarbeitet werden. Je nach Aufgabenstellung und geforderter Qualität, können die Quelldaten für die Berichte und Statistiken ein sehr großes Volumen annehmen. Aufgrund dessen ist eine manuelle Verarbeitung dieser Daten in den meisten Fällen nicht möglich. Unternehmen setzen daher meist Rechner ein, um eine automatisierte Verarbeitung der Daten zu ermöglichen. Je nach Unternehmensgröße und Anforderungen an die BI, werden hierzu häufig Tabellenverarbeitungsprogramme (wie z.B. Microsoft Excel) eingesetzt. Diese zeichnen sich jedoch dadurch aus, dass sie große Datenvolumen nur bedingt verarbeiten und auch die Zusammenhänge zwischen den Daten nicht sonderlich gut darstellen können. Daher setzen Unternehmen meist analytische Informationssysteme ein.

„Das Ziel analytischer Informationssysteme ist es, den adäquaten Zugang von Fach- und Führung­skräften zum Produktionsfaktor Information sicherzustellen und dadurch Führungs­­entscheidungen zu unterstützen und zu verbessern.“ (Rommelspacher, 2011, S. 95)

Diese Zieldefinition verdeutlicht, dass diese Systeme die Entscheidung lediglich unterstützen. Es ist nicht ihre Aufgabe, den Fach- und Führungskräften Entscheidungen abzunehmen. Rommelspacher geht weiterhin davon aus, dass den unterschiedlichen Managementebenen in einem Betrieb unterschiedliche Informationen zugänglich gemacht werden müssen (vgl. Rommelspacher, 2011, S. 95). Dies deckt sich auch mit der Ansicht der SKGR, welche nach Berufsgruppen differenzierte Berichte mit ihrem analytischen Informationssystem bereitstellt.

Analytische Informationssysteme entnehmen ihre Daten aus einer Vielzahl verschiedener Quellen und speichern sie i.d.R. in einer einzigen Datenbank. Diese wird als Data-Warehouse bezeichnet und in Kapitel 2.2 detailliert vorgestellt.

2.1.3 Abgrenzung operativer und analytischer Informationssysteme

Analytische Informationssysteme haben andere Anforderungen an ihre zugrunde liegenden Datenbanken, als operative Systeme. Dies liegt primär in den Unterschieden begründet, welche sich aus der Art der Systemverwendung ergeben. Operative Systeme zeichnen sich zumeist dadurch aus, dass sie die Nutzer bei der Verrichtung ihres Tagesgeschäftes unterstützen (vgl. Jung, 2006, S. 211f). Dabei arbeiten meist sehr viele Nutzer mit dem System, welche ein hohes Maß wenig komplexer Abfragen an das DBMS stellen. Analytische Informationssysteme unterstützen den Nutzer hingegen bei der Entscheidungsfindung, sowie bei der Kontrolle der operativen Entscheidungsqualität (vgl. Jung, 2006, S. 211f). Meist arbeiten deutlich weniger Nutzer mit den analytischen Informationssystemen, als mit den operativen und es werden daher auch weniger Abfragen an das System gestellt. Allerdings haben diese Abfragen meist eine deutlich höhere Komplexität und benötigen daher deutlich mehr Ressourcen. Die Charakteristika der beiden Systemtypen werden nebst Beispielabfragen in der Tabelle 1 dargestellt.

Wie zu erkennen ist, werden weniger komplexe Abfragen im Rahmen dieser Arbeit als Mikro- und komplexere Abfragen als Makrotransaktionen bezeichnet. Mikrotransaktionen spielen in der Praxis eine wichtige Rolle (z.B. bei einer Internetseite, welche zeitgleich von tausenden Benutzern besucht wird). In analytischen Informationssystemen haben sie nur einen geringen Einfluss auf das System, weswegen sie im Rahmen dieser Arbeit nur in Ausnahmefällen betrachtet werden.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1 - Gegenüberstellung operative und analytische Informationssysteme (in Anlehnung an Rommelspacher, 2011, S. 97)

Diese Einschränkung ist wichtig, da operative Anwendungssysteme aufgrund der beschriebenen Problematik meist dahingehend optimiert werden, dass sie viele Mikrotransaktionen verarbeiten können, während analytische Informationssysteme für wenige Makrotransaktionen optimiert werden. Diese beiden Optimierungsansätze schließen sich häufig gegenseitig aus.

2.2 Datawarehouses

2.2.1 Definition

Analytische Informationssysteme beziehen ihre Daten zu einem großen Teil aus den Datenbanken der operativen Anwendungssysteme eines Unternehmens. Diese sind in der Art und Weise ihrer Datenhaltung jedoch meist sehr heterogen, was eine Verarbeitung der Daten in einem gemeinsamen Kontext stark erschwert. Weiterhin ist auch die Art der Datenhaltung aufgrund der unterschiedlichen Anforderungen an operative und analytische Informationssysteme meist nicht zur Erstellung von Analysen geeignet (vgl. Kapitel 2.1.3). Daher werden sogenannte Datawarehouses (DWHs) eingesetzt, deren Aufgabe es ist, die Daten verschiedener operativer Systeme und zusätzlicher Quellen (z.B. Tabellen aus Tabellenkalkulationsprogrammen) in einer homogenen Datenbank vorzuhalten. Analysen jedweder Art können dann auf das DWH ausgeführt werden. (vgl. Prabhu, 2006, S. 1f)

In der Abbildung 2 wird der Zusammenhang zwischen dem DWH, seinen Datenquellen sowie den möglichen Analyseinstrumenten schematisch dargestellt.

Abbildung in dieser Leseprobe nicht enthaltenAbbildung in dieser Leseprobe nicht enthalten

Abbildung 2 - Konzept Datawarehouse (in Anlehnung an Prabhu, 2006, S. 1f)

Das DWH bezieht seine Daten periodisch aus den verschiedenen Datenquellen über den sogenannten ETL-Prozess (vgl. Kapitel 2.2.2). Auf die Daten im DWH kann nun mithilfe diverser Auswertungswerkzeuge zugegriffen werden, ohne dabei die operativen Systeme zu belasten. Dies können z.B. Tabellenkalkulationsprogramme oder analytische Informationssysteme sein. Im Falle der SKGR setzt auf das DWH eine Individualsoftware auf, welche vom Autor dieser Arbeit entwickelt wurde (vgl. Simmank, 2012, S. 1ff). Bei dem DWH selbst handelt es sich um ein Datenbanksystem (DBS).

„Ein DBS besteht aus einer Software, dem Datenbankmanagementsystem (DBMS), und einer Anzahl von Datenbanken. Das DBMS ist - grob gesehen - ein spezielles Programm, welches ganz oder teilweise im Hauptspeicher des Betriebssystems ausgeführt wird. Eine Datenbank ist eine Sammlung von Daten, welche Fakten über einen speziellen Ausschnitt der realen Welt repräsentiert.“ (vgl. Vossen, 2008, S. 10)

Die Aufgabe des DBMS besteht hierbei darin, eine Schnittstelle zwischen den Anwendern bzw. Anwendungssystemen und den eigentlichen Daten zu bilden. Somit kann in einer komfortablen Weise auf die Daten zugegriffen werden, ohne dass den Nutzer hierbei die tatsächliche physische Speicherung der Daten tangiert (eine detailliertere Beschreibung dieses Sachverhaltes wird in Kapitel 4.2.1 gegeben).

2.2.2 Extract-Transform-Load-Prozess

Wie in Kapitel 2.2.1 beschrieben, werden die Daten im DWH periodisch aktualisiert. Hierzu wird ein Prozess eingesetzt, der im Wesentlichen aus 3 Schritten besteht. Dieser Prozess hat einen massiven Einfluss auf die Datenbankperformance und spielt auch in der SKGR eine wichtige Rolle, weswegen er im Folgenden vorgestellt wird. Die einzelnen Prozessschritte werden in der Abbildung 3 vorgestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 - ETL-Prozess

Im ersten Schritt werden die Daten aus den operativen Systemen und sonstigen Datenquellen extrahiert und in eine sogenannte Staging-Area eingelesen. Hierbei handelt es sich um eine Datenbank, die zwar Teil des DWH ist, jedoch nicht für Analysezwecke genutzt wird. Zur Übertragung der Daten nutzt der ETL-Prozess geeignete Schnittstellen, um auf die entsprechenden Datenquellen zuzugreifen. Beim Extrahieren der Daten werden mithilfe geeigneter Überleitungstabellen bereits erste Schritte zur Homogenisierung vorgenommen, wie z.B. das Anpassen von Datumsformaten. Die Staging-Area dient dazu, dass im zweiten Schritt (dem Transform-Schritt), diverse Aktivitäten ausgeführt werden können um die Daten aus den heterogenen Datenquellen weiter zu homogenisieren. Hierunter fallen z.B. Arbeiten wie die Eliminierung von Synonymen und Homonymen oder das Ermittelten von statistischen Daten, welche mithilfe von Algorithmen direkt aus den Daten der operativen Systeme abgeleitet werden können (z.B. Ermittlung des Alters eines Patienten aus seinem Geburtsdatum und dem Aufnahmedatum im Krankenhaus). Auf eine detaillierte Auflistung der Schritte, welche beim Transform-Schritt durchgeführt werden, wird an dieser Stelle verzichtet, da dies keine direkte Relevanz für diese Arbeit hat. Wurden die Daten homogenisiert, findet im letzten Schritt eine Übertragung von der Staging-Area in die Produktivdatenbank des DWH statt. Dieser Schritt wird als Load-Schritt bezeichnet. (vgl. Schütte, Rotthowe, & Holten, 2001, S. 125f)

Da nur während des Load-Schrittes auf die produktiven Daten des DWH zugegriffen wird, hat dieser Schritt eine besondere Bedeutung. Während dieser Zeit kann i.d.R. nicht auf das DWH zugegriffen werden, da hierbei die Daten aktualisiert werden. Die meisten Unternehmen führen daher den ETL-Prozess außerhalb der Hauptarbeitszeiten aus. Nicht zuletzt auch, da der gesamte ETL-Prozess einen negativen Einfluss auf die Auslastung der operativen Systeme und das DWH hat.

2.2.3 Der Performancebegriff im Datenbankumfeld

Im Folgenden wird erläutert, was im gegebenen Kontext unter dem Begriff Datenbank-Performance (kurz: Performance) verstanden wird. Allgemein gibt es keine Übersetzung für das Wort Performance, welche dessen Inhalt widerspiegelt. Gemeinhin wird in der IT unter dem Begriff Performance die Leistung verstanden, welche ein System erbringt, und sich gemeinhin in Form der Bearbeitungszeit für eine Anfrage zeigt. Mullins geht hier einen Schritt weiter. Er vergleicht die Abfragen, welche an ein DBMS gestellt werden und die Leistung des Servers, diese Abfragen zu beantworten, mit einer Marktsituation, in der Angebot und Nachfrage existieren.

“… database performance can be defined as the optimization of resource use to increase throughput and minimize contention, enabling the largest possible workload to be processed.” (Mullins, 1998)

Er geht also von 5 Faktoren aus, welche die Performance des Systems beschreiben. Diese werden im Folgenden kurz vorgestellt und als Basis für die Ist-Analyse verwendet (vgl. Mullins, 1998).

- Workload
Der gesamte Arbeitsaufwand, welcher von den Clients beim DBMS nachgefragt wird. Dies schließt alle Abfragen ein, die dem DBMS übergeben werden.
- Throughput
Die allgemeine Leistungsfähigkeit des Systems im Hinblick auf die Fähigkeit, Daten zu verarbeiten (z.B. Prozessor-Geschwindigkeit).
- Ressources
Weitere Soft- und Hardware Ressourcen, die dem System zur Verfügung stehen (z.B. der benötigte Festplattensppeicher).
- Optimization
Die Optimierung der Abfragen im Hinblick auf ihre effiziente Ausführung. Diese wird zu einem großen Teil bereits vom DBMS selber durchgeführt, ohne einen Eingriff durch den Datenbankadministrator zu erfordern.
- Contention
Ist die Möglichkeit der Nebenläufigkeit. Nutzt eine Abfrage ein bestimmtes Datum (bzw. eine bestimmte Ressource), ist dieses für andere Abfragen blockiert. Auch dies kann Einfluss auf die Abfragegeschwindigkeit haben.

Das System muss also so aufgebaut sein, dass ein möglichst großes Abfragepensum mit einem Minimum an Soft- und Hardwareressourcen so schnell wie möglich bearbeitet werden kann. Hierbei muss auch gewährleistet sein, dass die Nebenläufigkeit mehrerer Abfragen die Geschwindigkeit nicht zu negativ beansprucht. Aus Sicht des Autors ist es daher zweckmäßig, die Performance von mehreren Alternativen mithilfe der folgenden 3 Kriterien zu evaluieren:

- Abfragedauer
- Speicherverbrauch
- Behinderung der Nebenläufigkeit

Eine Abfrage ist also nur dann performant, wenn sie schnell abgearbeitet wird, ohne dabei zu viel Speicher zu verbrauchen. Sollte eine Abfrage länger dauern als einen Sekundenbruchteil, muss zumindest gewährleistet sein, dass sie andere Abfragen nicht durch die Blockade anderer Ressourcen behindert.

Weiterhin muss bei der Bewertung des Speicherverbrauchs nach der Art des Speichers differenziert werden. Es gibt zwei wesentliche Kategorien von Speichermedien, welche für den Datenbankserver eine hohe Relevanz haben. Dies sind der externe Speicher und der Arbeitsspeicher des Servers. Der Grund für diese Trennung besteht in den unterschiedlichen Eigenschaften der jeweils verwendeten Speichermedien. Der externe Speicher (i.d.R. Festplatten) dient zur permanenten Speicherung der Daten. Er zeichnet sich v.a. dadurch aus, dass die Kosten pro Kapazitätseinheit deutlich geringer sind, als die des Arbeitsspeichers. Der Arbeitsspeicher hingegen ist i.d.R. ein flüchtiger Speicher, welcher temporär zur Bearbeitung von Abfragen genutzt wird. Diese Bearbeitung umfasst z.B. Tätigkeiten wie das Sortieren oder Aggregieren von Daten. Hierfür wird der Arbeitsspeicher verwendet, da dieser um ein vielfaches schneller ist, als eine Festplatte, da er keine beweglichen Teile einsetzt. Die Zugriffzeit des Arbeitsspeichers beträgt ca. 60 bis 70 Nanosekunden, während die einer Festplatte bei ca. 9 Millisekunden liegt - dies entspricht ca. der 150.000-fachen Zugriffszeit des Arbeitsspeichers. Zur permanenten Speicherung von Daten wird er jedoch nicht genutzt, da er spätestens beim Ausschalten des Servers seinen Inhalt „vergisst“. Des Weiteren sind die Kosten pro Kapazitätseinheit auch deutlich höher, als z.B. bei Festplatten. (vgl. Falkowski, 2002, S. 28f)

2.2.4 Indizes

Einen wesentlichen Bestandteil von DBMS, stellt die Indizierung von Tabellen dar. Da das Verständnis dieser Technik eine zentrale Rolle in allen Bereichen dieser Arbeit spielt, wird an dieser Stelle kurz erläutert, was unter diesem Begriff zu verstehen ist.

Datenbanksysteme speichern ihre Daten i.d.R. in sequentiellen Dateien auf einem Datenträger (meist auf einer Festplatte). D.h., dass das DBMS für jede Tabelle eine Datei im Dateisystem anlegt, in welcher die einzelnen Datensätze der Tabelle sequentiell (in einer vom DBMS vorgegebenen Reihenfolge) abgespeichert werden. Problematisch wird dies, wenn ein bereits gespeicherter Datensatz wieder abgefragt werden soll. Hat eine Tabelle sehr viele Datensätze und der gesuchte Datensatz steht beispielsweise ganz am Ende der Datei, müsste das DBMS alle Datensätze durchsuchen, bis es den gewünschten Datensatz gefunden hat. Dies wird auch als vollständiger Tabellenscan bezeichnet. Bedingt durch die Tatsache, dass die Zugriffsgeschwindigkeit gerade auf externen Speichermedien wie der Festplatte sehr langsam ist, kann dieser Vorgang u.U. sehr lange dauern. Aufgrund dessen werden Indizes eingesetzt, welche einen schnellen Zugriff auf die einzelnen Datensätze ermöglichen und vollständige Tabellenscans vermeiden sollen. (vgl. Geisler, 2011, S. 119f)

Es werden verschiedene Arten von Indizes eingesetzt, welche im Folgenden nicht näher erläutert werden sollen. Allen gemein ist, dass diese einen konkreten Datensatz in einem Bruchteil der Zeit auffinden können, die für einen vollständigen Tabellenscan nötig wäre. Hierzu verwenden sie sehr effiziente Algorithmen, die, sehr abstrakt gesehen, ähnlich funktionieren wie der Index in einem Buch. Sucht man als Leser eines Buches Informationen zu einem bestimmten Thema, kann mithilfe des Index sehr schnell die Seite gefunden werden, auf der diese Information steht. (vgl. Schwartz et al., 2009, S. 103f)

Ähnlich einem Buch müssen auch für Indizes in Datenbanken zusätzliche Informationen gespeichert werden, die nicht Teil der eigentlichen Daten in den Tabellen sind. Dies können z.B. hierarchische Strukturen sein, anhand derer ein Datensatz aufgefunden werden kann. Diese zusätzlichen Informationen werden in sogenannten Index-Dateien gespeichert, die neben den eigentlichen Datendateien abgelegt werden. Die Verwaltung dieser Index-Dateien nimmt das DBMS automatisch vor. Dem DBMS muss jedoch mitgeteilt werden, welche Attribute einer Tabelle überhaupt indiziert werden sollen. Standardmäßig wird der Primärschlüssel^[1] jeder Tabelle indiziert, doch es kann sinnvoll sein, auch andere Attribute zu indizieren, auf welche häufig Suchvorgänge durchgeführt werden. Hat eine Tabelle zur Mitarbeiterverwaltung z.B. die Attribute „Personalausweisnummer“, „Name“ und „Geburtsdatum“, macht es durchaus Sinn, die Personalausweisnummer als Primärschlüssel zu verwenden, da nur sie einen konkreten Mitarbeiter eindeutig identifizieren kann. In der Praxis werden konkrete Datensätze aus dieser Tabelle jedoch meist über das Attribut „Name“ gesucht, weswegen eine zusätzliche Indizierung dieses Attributs sehr nutzbringend sein kann.

[...]

---

^[1] Der Primärschlüssel ist das Attribut einer Tabelle, welches dazu dient, einen Datensatz eindeutig zu identifizieren.