FAKULTÄT FÜR INFORMATIK

Transkript

1 FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN Bachelor s Thesis in Wirtschaftsinformatik Konzeption und prototypische Implementierung eines Überwachungscockpits für ein Data Warehouse Andreas Gerö

2

3 FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN Bachelor s Thesis in Wirtschaftsinformatik Design and prototypical implementation of a monitoring cockpit for a data warehouse Konzeption und prototypische Implementierung eines Überwachungscockpits für ein Data Warehouse Autor: Andreas Gerö Aufgabensteller: Prof. Dr. Florian Matthes Betreuer: Thomas Reschenhofer Abgabedatum: 15. September 2014

4

5 Ich versichere, dass ich diese Bachelor s Thesis selbständig verfasst und nur die angegebenen Quellen und Hilfsmittel verwendet habe. München, den 12. September 2014 Andreas Gerö

6

7 Danksagung Zunächst möchte ich all denjenigen meinen Dank aussprechen, die diese Bachelorarbeit ermöglicht und mich während der Bearbeitung fortlaufend motiviert und unterstützt haben. So gebührt mein Dank in erster Linie meinem Praxispartner, der ITERATEC GMBH, die mir ihre Infrastruktur zur Forschung bereitgestellt und durch die Fallstudie den Bezug zwischen Forschung und realem Projekt bei einem Unternehmen hergestellt hat. Meinen beiden fachlichen Betreuern, JOHANNES DIETERICH und NINA PAK, gebührt mein besonderer Dank, da sie stets ein offenes Ohr für meine Fragestellungen hatten und ihr kritischer Blick sowie ihre konstruktive Kritik wichtige Denkanstöße lieferten, um diese Arbeit so anfertigen zu können. Selbstverständlich bin ich auch allen anderen Kollegen dankbar, die nicht namentlich genannt sind und mit überragender Hilfsbereitschaft stets Zeit für mich fanden. Weiterhin bedanke ich mich bei meinem Betreuer von Seiten der Uni, THOMAS RESCHEN- HOFER, der mich ebenfalls unterstützt hat und mir ermöglicht hat, diese Abschlussarbeit am Lehrstuhl sebis zu schreiben. Schließlich gebührt meinen Eltern besonderer Dank. Sie sind es, die mich stets unterstützt haben und mich zu dem gemacht haben, was ich heute bin. Danke. vii

8

9 Zusammenfassung Mit zunehmendem Datenvolumen, komplexen Abläufen und steigenden Anforderungen an Schnelligkeit und Stabilität entsteht der Bedarf nach einer zentralen und benutzerfreundlichen Informationsquelle zur Unterstützung des Datenmanagements im Data Warehouse (DWH). Dies umfasst sowohl die Verwaltung der operativ anfallenden Datenmengen als auch bspw. das Management der Datenqualität. Die bislang bei Datenbanken mitgelieferte Funktionalität zur Überwachung der Daten deckt vor allem technische Detailaspekte, wie z.b. Speicherverbrauch oder die Anzahl neu geladener Datensätze ab. Darüber hinausgehende, auf die konkrete Architektur bezogene Fragen werden nicht in ausreichendem Maße adressiert. Für einen DWH-Administrator ist beispielsweise die Nachverfolgung des Ablaufs bzw. eine eventuelle Fehleranalyse bei kürzlich erfolgten Extract-Transform-Load (ETL)-Vorgängen von Interesse. So kann eine klassische Schichtenarchitektur auf die schichtenübergreifenden Anwendungsfälle hin untersucht werden. Durch die Identifizierung der Beziehungen und Abhängigkeiten zwischen einzelnen Datenbankobjekten und Anwendungsfällen können auf diese Weise die von einem fehlerhaften Datenbankobjekt betroffenen Anwendungsfälle und damit die entsprechenden Anwender ermittelt werden. So entsteht der Bedarf nach einer Methodik zur systematischen Analyse und Deckung des Informationsbedarfs typischer betrieblicher Stakeholder im Rahmen des Datenmanagements im Data Warehouse. In dieser Bachelorarbeit wird ein Überwachungskonzept erarbeitet, welches diese Lücke schließt. Die Forschungsergebnisse umfassen eine dreiteilige Methodik: 1. Für eine Auswahl typischer betrieblicher Stakeholder aus Datenmanagement und IT-Servicemanagement wurden Ziele für das Datenmanagement ermittelt. 2. Ein Kennzahlenkatalog ermöglicht es, die Erfüllung der Ziele der Stakeholder zu messen. 3. Ein Metamodell spezifiziert die Zusammenhänge zwischen Metriken, Messobjekten und fachlichen Entitäten und erlaubt die Modellierung des Datenflusses im DWH sowie Visualisierung von Kennzahlen in einem Datenflussgraphen. Zudem werden weitere Analysen vorgestellt, die durch den Datenflussgraphen ermöglicht werden. Hierzu zählen Abstammungs- und Auswirkungsanalyse sowie die Berechnung von kritischen Pfaden auf dem Graphen. ITIL und Data Management Body of Knowledge (DMBOK) liegen als Frameworks mit empfehlendem Charakter der Analyse von Stakeholdern und Zielen zugrunde. Die Metriken aus dem Kennzahlenkatalog wurden mithilfe von Goal-Question-Metric (GQM) aus den zuvor ermittelten Zielen abgeleitet. Das Konzept wurde im Rahmen einer Fallstudie als Monitoring-Cockpit für ein großes Carsharing-DWH prototypisch umgesetzt. Eine abschließende Evaluation durch Experten aus der IT Industrie hat die Eignung des Prototyps für die Anforderungen in der Fallstudie validiert. ix

10

11 Abstract With increasing amounts of data, complex processes, and rising demands regarding velocity and stability, the necessity for a central and user-friendly source of information in support of data management in the data warehouse has become apparent. This comprises management of operational data as well as, e.g., management of data quality. Currently, out-of-the-box data monitoring functionality of databases mostly covers technical details, such as space usage or number of recently loaded data records. Questions regarding the specific architecture are insufficiently dealt with. A data warehouse administrator, for instance, might be interested in tracing the course of recently finished ETL processes or debugging them. Thus, a conventional layer architecture may be analyzed with respect to the use cases spanning multiple layers. By identifying the relationships and dependencies among database objects and use cases, use cases affected by erroneous database objects and corresponding users can be determined. Hence, the need for a methodology to systematically analyze and cover the informational requirements of common business stakeholders in context of data management in the data warehouse has evolved. This Bachelor s Thesis develops a concept for monitoring data warehouses, which bridges this gap. The research results comprise a tripartite methodology: 1. Goals of common business stakeholders from data management and IT service management are determined. 2. The KPI catalog facilitates measurement of the accomplishment of the stakeholders goals. 3. A meta model defines relationships among technical components, metrics, and business entities, and enables modelling data flow in the data warehouse as well as visualization of metrics in a data flow graph. Additionally, the Thesis presents further analyses facilitated by the graph. Lineage and impact analysis as well as computation of critical paths count among them. ITIL and the Data Management Body of Knowledge (DMBOK) serve as the underlying frameworks of recommendatory nature for the analysis of stakeholders and identification of their goals. Metrics contained in the KPI catalog were deduced from those goals utilizing the Goal-Question-Metric approach. The concept was prototypically implemented in the scope of a case study involving a large carsharing data warehouse. A concluding evaluation by the experts from the IT industry validated the suitability of the prototype for the requirements of the case study. xi

12 xii

13 Inhaltsverzeichnis Danksagung Zusammenfassung Abstract vii ix xi 1 Einführung Motivation für diese Arbeit Zielsetzung der Forschung Vorgehensweise Stand der Forschung Data Warehousing Schichtenarchitektur Datenintegration zwischen den Schichten Datenfluss Datenmanagement Data Management Body of Knowledge Information Technology Infrastructure Library Metadaten Datenqualität Informationsaufbereitung und Cockpit-Bedienkonzept Entwicklung des Konzepts Identifizierung der Stakeholder Ausgewählte Funktionen des Datenmanagements Potentielle Stakeholder Ziele des Datenmanagements Data Operations Management Data Warehousing & Business Intelligence Management Metadatenmanagement Datenqualitätsmanagement Ziele in der weiteren Betrachtung Analyse der Stakeholder Zuordnung von Zielen zu DAMA-Rollen Zuordnung von Zielen zu ITIL-Rollen Informationsbedarfsanalyse Kennzahlen und notwendige Messungen Messpunkte für Datenqualität im Data Warehouse xiii

14 Inhaltsverzeichnis Ebenen der Messung von Kennzahlen Kennzahlenkatalog Datenflussanalyse und Datenflussgraph Metamodell der Messobjekte Analysen und Messungen am Datenflussgraphen Darstellung des Datenflussgraphen Fallstudie Systemkontext Projekt Architektur und Werkzeuge Spezifische Anforderungen Anwendung des Konzepts Kennzahlen und Visualisierung Datenmodell Dashboards Datenflussgraph im Projekt Evaluierung Fazit und Ausblick Fazit Ausblick Anhang 67 Interviews 67 Abkürzungsverzeichnis 69 Literaturverzeichnis 71 xiv

15 1 Einführung 1.1 Motivation für diese Arbeit Viele Unternehmen haben mittlerweile erkannt, dass Daten einen wichtigen und wertvollen Teil ihres Kapitals darstellen. Die Berechnung von Prognosen für die zukünftige Geschäftsperformance gehört heutzutage ebenso zu den betrieblichen Anforderungen wie Analysen und Auswertungen von Daten aus der Vergangenheit, sowohl auf Basis eigener Daten als auch angereichert mit Daten aus externen Quellen. In einer sehr schnelllebigen Welt, in der wenige Sekunden die Auswirkungen einer betrieblichen Entscheidung erheblich verändern können, sollte ein Unternehmen zur Unterstützung der Entscheider gemäß bestehender Anforderungen Qualitätskriterien für Daten definieren. Zu diesen gehören aus heutiger Sicht nicht mehr nur die klassischen Kriterien, die sich auf Korrektheit [Orr98] der Daten beziehen, sondern beispielsweise auch Kriterien für Aktualität oder Integrität. Stetig wachsende Datenmengen und steigende Komplexität erschweren es, den Überblick zu behalten und lassen ein effektives und möglichst automatisiertes Datenmanagement immer wichtiger erscheinen. Gerade der Einsatz eines Data Warehouse (DWH), der insbesondere durch die aufwändige Integration und Konsolidierung heterogener Datenquellen einen hohen Grad an Komplexität aufweist, profitiert stark von einer systematischen Überwachung. So entsteht der Bedarf nach einer Methode zur systematischen Abdeckung des Informationsbedarfs typischer betrieblicher Stakeholder im Kontext des Datenmanagements. In diesem Sinne soll festgestellt werden, welche betrieblichen Stakeholder typischerweise welchen Informationsbedarf zur Verfolgung ihrer Ziele im Rahmen des Datenmanagements haben und über welche Möglichkeiten dieser Informationsbedarf abgedeckt werden kann. Der Bedarf nach einer Lösung zum Monitoring im Kontext des Datenmanagements wird teilweise von bestehenden Werkzeugen abgedeckt. Insbesondere Systemüberwachung auf technischer Ebene ist mit vorhandenen Anwendungen möglich [Hav13, Man14]. Aber auch Werkzeuge, die eine Abstammungsanalyse im DWH durchführen können, sind verfügbar [Cor12]. Werkzeuge, die in der Lage sind, Metriken anhand eines Datenflussgraphen darzustellen, sind jedoch nicht vorhanden. So könnte für den DWH-Administrator beispielsweise die Darstellung des Durchsatzes für jeden Prozessschritt des ETL-Laufs direkt im Datenflussgraph (DFG) sinnvoll sein. Zudem gilt es nach [MBEH09] als Best Practice, ein Dashboard für Anwender zur Verfügung zu stellen, in dem auf höherem Abstraktionsniveau Details zur Datenauslieferung zu sehen sind, um das Vertrauen in die Prozesse im DWH zu erhöhen. Dieses Prinzip wird in der Fallstudie prototypisch umgesetzt. 1

16 1 Einführung 1.2 Zielsetzung der Forschung Folgende wissenschaftliche Fragestellungen sollen im im Kotext des Datenmanagements im Data Warehouse beantwortet werden: Q-1 Welchen Informationsbedarf haben typische betriebliche Stakeholder? Q-2 Welche Metriken eignen sich am besten dazu, die Ziele der Stakeholder zu überwachen? Q-3 Wie kann ein Datenflussgraph bei Analyse und Überwachung eines Data Warehouse unterstützen? Ziel dieser Arbeit ist die Entwicklung einer Methode zur systematischen Ermittlung und Deckung des Informationsbedarfs typischer betrieblicher Stakeholder im Rahmen des Datenmanagements sowie eines Konzepts für die Modellierung des Datenflusses im Data Warehouse. 1.3 Vorgehensweise Um ein Konzept erarbeiten zu können, welches Antworten auf die im vorhergehenden Abschnitt formulierten Fragestellungen geben kann, werden zunächst theoretische Grundlagen eingeführt. Der Stand der Forschung für die Themen Data Warehousing, Datenmanagement und Datenfluss sowie Cockpit-Bedienkonzept wird aufgezeigt. Damit das Konzept auf etablierten Praktiken und in der Praxis verbreiteten Rahmenwerken fundieren kann, werden die Information Technology Infrastructure Library (ITIL) [Nis12] sowie das DMBOK [MBEH09] der Data Management Association (DAMA) eingeführt. Auf diese Weise können Best Practices aus dem Datenmanagement auf empfohlene Organisationsstrukturen für das IT-Servicemanagement übertragen werden. Das Konzept hat die Entwicklung einer Methode zur Überwachung eines Data Warehouse zum Ziel und erreicht dies über die Definition geeigneter Metriken. Zur Ermittlung adäquater Metriken wird der GQM Ansatz [Bas92] herangezogen, der postuliert, dass Metriken den Grad der Erfüllung einer Zielsetzung messen. Die in dieser Arbeit verwendeten Ziele sind eine Teilmenge der Gesamtanzahl von Zielen, die im DMBOK definiert sind. Die Ziele sind nach Relevanz für die hier betrachtete Thematik so gewählt, dass der durch die wissenschaftlichen Fragestellungen vorgegebene Umfang eingehalten wird. Zu Beginn wird eine Auswahl von Funktionen des Datenmanagements nach [MBEH09] getroffen, die zu einer Menge potentieller Stakeholder für die zu entwickelnde Methode führt. Die diesen Funktionen zugeordneten Ziele werden werden daraufhin analysiert, ob sie bei GQM miteinbezogen werden. Aus der Menge der verwendeten Ziele wird die Menge der mit dieser Arbeit tatsächlich angesprochenen Stakeholder abgeleitet. Diesen Rollen des Datenmanagements nach DAMA werden entsprechende Rollen aus der ITIL zugeordnet. Mit den nun bekannten Informationen über die betrieblichen Stakeholder wird eine Informationsbedarfsanalyse durchgeführt. Im Rahmen von GQM werden passend zu den Zielen Fragestellungen aus Sicht der Stakeholder erarbeitet. Die Fragestellungen bilden die Grundlage zur Definition von Metriken, die diese Fragestellungen beantworten und den Informationsbedarf der Stakeholder decken. Der resultierende Kennzahlenkatalog ist 2

17 1.3 Vorgehensweise ein zentrales Artefakt dieser Arbeit und Basis für die Überwachung von DWHs. Es wird ein Metamodell entwickelt, welches die Modellierung des Datenflusses im DWH als gerichteten Graph ermöglicht. Das Metamodell spezifiziert die Zusammenhänge zwischen Messobjekten und Metriken im DWH. Hierzu werden die Metriken in verschiedene Klassen eingeteilt und erläutert, wie die Metriken am Graphen dargestellt werden können. Es werden weitere für Graphen spezifische Analysen vorgestellt, die anhand eines DFG durchgeführt werden können. So werden Abstammungs- und Auswirkungsanalyse sowie die Berechnung von kritischen Pfaden vorgestellt. Das Konzept zur Überwachung von Data Warehouses wird mit Unterstützung des Praxispartners iterativ entwickelt und in einer Fallstudie prototypisch umgesetzt sowie evaluiert. Eine mögliche Implementierung des DFG wird vorgeschlagen und anhand von Mockups aufgezeigt, wie die verschiedenen Analysen und Darstellung der Metriken konkret ausgestaltet werden können. Abschließend werden die Ergebnisse der Arbeit nochmals kritisch betrachtet und diskutiert. Ein Ausblick zeigt auf, an welchen Stellen weiterer Bedarf zur Forschung besteht. 3

18 1 Einführung 4

19 2 Stand der Forschung Dieses Kapitel legt den aktuellen Stand der Forschung dar und führt theoretische Grundlagen ein, die für das spätere Konzept die Basis bilden. Zu Beginn wird der Begriff des Data Warehouse (DWH) eingeführt und typische Charakteristika der Architektur aufgezeigt. Es folgt eine kurze Einführung in das Konzept des Datenflusses, auf dem der Datenflussgraph aufbaut. Ein Abschnitt über Datenmanagement zeigt die Struktur von DMBOK und ITIL auf und gibt einen Überblick über Metadatenmanagement und Datenqualität. 2.1 Data Warehousing Die Konsolidierung unterschiedlicher Datenquellen sowie der integrierte Zugang dazu in einer zentralen Datenbasis stellen wichtige Fragestellungen für Industrie und Forschung dar [Wid95]. Der bei der Auswertung und Analyse von Daten aus unterschiedlichen Quellen entstehenden Frage der Datenintegration kann man im Allgemeinen auf zweierlei Art begegnen: 1. Auswertung der Anfrage, Auflösung in geeignete Unteranfragen für die einzelnen Datenquellen und Berechnung des Ergebnisses 2. Extraktion, Transformation und Laden relevanter Daten aus den Quellsystemen in ein logisches Zielsystem und Ausführung aller Anfragen auf den so entstandenen Daten Letzterer Ansatz wird als Data Warehouse bezeichnet und wurde unter anderem von W. H. Inmon definiert: Definition 2.1 (Data Warehouse) Ein Data Warehouse (DWH) ist eine themenorientierte, integrierte, chronologisierte und persistente Sammlung von Daten, um das Management bei seinen Entscheidungsprozessen zu unterstützen. [Inm02] Für Inmon ist das unternehmensweite Datenmodell der zentrale Baustein des DWH. Die strategische Ausrichtung des DWH als Teil der übergeordneten Corporate Information Factory bei Inmon steht im Gegensatz zur benutzerorientierten Sicht Kimballs, der das Data Warehouse als eine Kopie von Transaktionsdaten, die zum Zwecke der Abfrage und Analyse strukturiert sind, sieht [KR02]. Für Kimball beginnt der Designprozess des DWH mit der Abdeckung des Informationsbedarfs von Stakeholdern über multidimensional modellierte Data Marts. Die Menge dieser spezifischen Sichten verkörpert für ihn das Data Warehouse. Dieses kann auch nachträglich um ein unternehmensweit integriertes Datenmodell erweitert werden. Das DWH wird oftmals auch als Single Point of Truth (SPOT) [WS04] charakterisiert. Diese Bezeichnung resultiert aus dem Ziel, keine widersprüchlichen Analysen aus unter- 5

20 2 Stand der Forschung schiedlichen Datenquellen erzeugen zu können. Beispielsweise soll durch eine einheitliche Datenbasis die Situation vermieden werden, dass Prognosen oder Statistiken von verschiedenen Abteilungen zur gleichen Fragestellung erstellt werden und widersprüchliche Ergebnisse durch die unterschiedlichen Datenbasen folgen. Eine unternehmensweit zentrale Stelle zur Pflege der Daten soll des Weiteren, durch gezielt gepflegte Datenqualität und verringerten Aufwand zur Datenpflege, den Informationsgrad der Daten im Allgemeinen und damit die Endanwenderproduktivität erhöhen. Durch eine Historisierung der operativen Daten im Data Warehouse verspricht man sich eine langfristig aussagekräftige Datenbasis, um z.b. durch Online Analytical Processing (OLAP) oder Data Mining neue Erkenntnisse aus den Daten gewinnen zu können. Operative Systeme würden nur noch für operative Zwecke genutzt und würden damit entlastet. Die geringere Last auf den operativen Systemen in Kombination mit der konzentrierten Last auf dem Data Warehouse bietet Potential zu finanziellen Optimierungen, wie einem effizienteren Controlling. Nicht zuletzt betrachtet man das DWH als zukunftssichere IT-Strategie. Bauer und Günzel [BG04] stellen einige Anforderungen an ein Data Warehouse-System. Dazu gehört die Unabhängigkeit zwischen Datenquellen und Analysesystemen. Dies bezieht sich auf Verfügbarkeit des DWH, unabhängige Belastung der einzelnen Systeme sowie Unabhängigkeit des DWH von laufenden Änderungen an den Quellsystemen. Die Daten sollen persistent gelagert sein und für verschiedene Zwecke verwertbar sein. Grundsätzlich sollen beliebige Auswertungen vorgenommen werden können und das Modell so flexibel sein, dass es z.b. auch auf die Integration neuer Datenquellen erweitert werden kann, aber gleichzeitig unterschiedliche individuelle Sichten unterstützten kann. Die Datenstrukturen, Zugriffsberechtigungen und Prozesse sollen eindeutig sein und am Zweck des DWH, nämlich der Analyse der Daten ausgerichtet sein. Schließlich sollen die Abläufe automatisierbar sein Schichtenarchitektur Im klassischen Sinne wird das Data Warehouse als dreischichtiges Informationssystem modelliert (vgl. Abbildung 2.1). Daten aus operativen Quellsystemen werden in die Staging Area, welche die Integrationsebene repräsentiert, geladen. Diese Ebene entkoppelt die Extraktion aus den Quellsystemen und die tatsächliche Datenintegration, die auf dem Weg zur Ebene der Datenhaltung durchgeführt wird. Anschließend werden die Daten in den Data Store geladen, wo sie meist in denormalisierter, multidimensionaler Form vorliegen. Oftmals werden bedarfsspezifische Data Marts modelliert, die auf spezielle Sichten maßgeschneidert und für voluminöse Lesezugriffe optimiert sind. Diese Daten werden zur Analyse eingesetzt und die Ergebnisse werden schließlich in einer Clientanwendung auf der Präsentationsebene dargestellt. Die Darstellung kann aber auch beispielsweise in Form eines Berichts auf Papier erfolgen. 6

21 2.1 Data Warehousing Abbildung 2.1: Typische Schichtenarchitektur eines DWH Datenintegration zwischen den Schichten Die Integration heterogener Datenquellen gehört zu den zentralen Aufgaben eines Data Warehouse. Dies geschieht im Rahmen des ETL-Prozesses. Der ETL-Prozess beschreibt den Vorgang, Daten aus bestehenden Datenquellen zu extrahieren, mittels geeigneter Transformationsregeln zu homogenisieren, nach bestimmten Vorschriften zu bereinigen und ggf. anzureichern und in ein separates Ziel zu laden. [Ros13] Bei der Extraktion werden für relevant befundene Daten aus den Quellen gelesen und in den Arbeitsbereich übertragen. Ein inkrementelles Laden überträgt nur die Änderungen seit der letzten Extraktion und kann somit ggf. hohe Datenvolumina bei der Extraktion minimieren (nach einem initialen Extraktionsvorgang). Die Transformationsschritte im Arbeitsbereich dienen der Konsolidierung der extrahierten Daten. Datenintegration [BG04] beinhaltet bspw. Konsolidierung von Datentypen, Einheiten und eindeutigen globalen Schlüsseln (globale Surrogatschlüssel). Die Datenbereinigung bzw. Data Cleaning soll einerseits fehlerhafte Werte herausfiltern und andererseits äquivalente Objekte auf Instanzebene ermitteln und Redundanzfreiheit gewährleisten. Bauer und Günzel [BG04] empfehlen zugunsten der Nachhaltigkeit eine in das Datenqualitätsmanagement eingebettete Datenbereinigung, da diese ansonsten eher symptomorientiert eingesetzt wird. Nach weiteren syntaktischen und semantischen Transformationen [Ros13] werden die Daten verdichtet und mit Informationen aus externen Quellen angereichert, um bspw. Plausibilitätskontrollen durchführen zu können. Bereits in der Extrak- 7

22 2 Stand der Forschung tionsphase können zahlreiche Transformationen unter Zuhilfenahme von SQL oder datenbankeigenen Mitteln durchgeführt werden [Ros13]. Andererseits kann die Extraktion auch ohne jegliche Transformation erfolgen und eine Kopie der Daten aus den operativen Systemen erzeugen. Dieses historisierte Abbild der operativen Daten kann bspw. zur Wiederherstellung nach einem Datenverlust herangezogen werden. Beim Laden in den Bereich für die Datenhaltung werden die Daten den Anforderungen entsprechend aggregiert und historisiert. An dieser Stelle kann der Einsatz eines Bulk Loaders [BG04] zum initialen Laden großer Datenmengen sinnvoll sein; danach können Daten inkrementell geladen werden. 2.2 Datenfluss Data Provenance auch bekannt als Data Lineage oder Data Pedigree [BKT01] ist ein Problem, das die Analyse der Herkunft und des Entstehungsprozesses von Daten in einem bestimmten Datenbankobjekt beschreibt. Derartige Analysen spielen eine wichtige Rolle, um beispielsweise Authentizität (bzw. Glaubwürdigkeit [PM08]) von Daten nachzuweisen, also Vertrauen in Daten zu schaffen. Gerade im Umfeld wissenschaftlicher Berechnungen ist das Wissen um den Entstehungsprozess von Daten essentiell, um Wiederholbarkeit zu gewährleisten, das Ergebnis einordnen zu können, Wiederholung der Bemühungen zur Berechnung zu vermeiden und Quelldaten aus Ausgabedaten wiederherstellen zu können [BT07]. [RL09] beschreibt die Herkunft von Daten als 7-Tupel (vgl. Abbildung 2.2). Zur Feststellung der Herkunft kann der Ansatz der verzögerten Auswertung 1 oder der sofortigen Auswertung 2 herangezogen werden [Tan04]. Die verzögerte Auswertung geht davon aus, dass Auswertungen erst vorgenommen werden, wenn man sie benötigt und geht auf Basis einer Abfrage Q vor, die invertiert wird, um die Daten d zu rekonstruieren. Die Variante der sofortigen Auswertung verwendet Metadaten über die Datenherkunft, die bei der Berechnung neuer Daten generiert und mitgeführt werden. Bezeichnungen für verschiedene Vorgehensweisen sind metadata-approach, source tagging, attribution approach oder annotations; vgl. [BB99, BCTV05, LBM98]. Abstammungs- und Auswirkungsanalysen Aufgrund verschiedener Fragestellungen interessiert also die Verfolgung und Auswertung des Datenflusses [ABEM09] innerhalb eines Data Warehouse. Bei [VSB09] wird eine einheitliche Taxonomie zur Diskussion über Operationen beim ETL-Vorgang erarbeitet. Eine Auswirkungsanalyse 3 betrachtet die Nachfolgerknoten eines Datenbankobjekts in einem Datenflussgraphen. Damit sollen die bei einer Änderung des betrachteten Datenbankobjekts betroffenen Objekte bzw. Use Cases ermittelt werden. Die Abstammungsanalyse 4 betrachtet die Vorgängerknoten eines Datenbankobjekts in einem Datenflussgraphen. So kann ein Endanwender beispielsweise bei einer ihm vorlie- 1 engl. lazy approach 2 engl. eager approach 3 engl. impact analysis 4 engl. provenance analysis 8

23 2.2 Datenfluss Abbildung 2.2: Semantik der Datenherkunft als 7-Tupel [RL09] genden Kennzahl oder einem aggregierten Wert erkennen, aus welchen Datenquellen die berechneten Werte stammen, welche anderen Datenbankobjekte auf dem Weg durchlaufen wurden und wie die Berechnungen zustande kamen. [Cui01, BT07] beschreiben diese Analyse auch als Data Lineage Problem (DLP) für relationale Views; in [CW03] wird das Problem auch für allgemeine Transformationen beschrieben. Ein Datenflussgraph kann auch dazu verwendet werden, aggregierte Kennzahlen auf ihre einzelnen Bestandteile herunterzubrechen und diese in variabler Granularität an den Kanten des Graphen zu visualisieren. Das Metamodell für einen entsprechenden Graphen liefert Abschnitt Eine Spezifikation möglicher Analysen am DFG wird von Abschnitt gegeben. Zielgruppe für derartige Analysen und Messungen sind sowohl Entwickler als auch Anwender. Cui et al. [CWW00, Cui01] beschreiben das Data Lineage Problem als Ermittlung der Quelldatensätze in einer View und geben einen Lösungsweg dafür an. Dabei betrachten sie formalisiert nicht nur den relationalen Fall, bei dem die Basisdaten aus der invertierten Definition der View selbst alleinig anhand der relationalen Algebra berechnet werden. Sie analysieren auch den Fall, dass die Basisdaten allgemeine DWH-Transformationen bis zum Endzustand durchlaufen haben. Hier ist nicht mehr allein die relationale Algebra anwendbar, sondern es kommen auch prozedurale Sprachelemente zum Einsatz. Dieser Fall ist zwar theoretisch komplexer und kostet auch mehr Rechenleistung in der Realität, kommt aber in der Praxis häufiger vor. Die Frage der Darstellung der Datenherkunft wird nicht behandelt. [VSS02, SVTS05] zeigen jedoch eine Möglichkeit auf, Aktivitäten in den ETL-Prozessen als Graph zu modellieren. Die Forschungsgruppe Datenbanken der Universität Stanford ist im Bereich der Abstammungsanalysen aktiv. So wird im Projekt Trio [Agg09, Wid04] die Uncertainty Lineage Database (ULDB) [BSH + 08, BSHW06] eingeführt, anhand derer aufgezeigt wird, wie Unsicherheit und Abstammung in einem relationalen Datenbanksystem integriert werden können. Mit dem Projekt Panda [ICF + 12] zeigen die Forscher eine mögliche Implementierung eines Datenflussgraphen bezogen auf eine Abstammungsanalyse an einem Datenbankobjekt. 9

24 2 Stand der Forschung 2.3 Datenmanagement Der Begriff der Daten hat noch keine einheitliche und allgemein akzeptierte Definition. Bei [ABEM09] wird der Begriff in Zusammenhang mit Information und Wissen betrachtet und in den Kontext der Semiotik gesetzt. Diese allgemeine Lehre über Zeichenfolgen wird auf die Informatik übertragen, um so die Konzepte zu erklären. Daten werden hierbei auf die syntaktische Ebene gestellt, die einzelne Zeichen sowie Zeichenfolgen betrachtet, diesen aber noch keinerlei Bedeutung zuordnet. Es können lediglich Beziehungen zwischen diesen Zeichen analysiert werden, wie etwa relative Häufigkeiten einzelner Zeichen in einer Zeichenkette. Sobald Daten in einem bestimmten Kontext gesehen werden und dadurch eine Bedeutung erlangen, spricht man von Information. Information ist auf der semantischen Ebene angesiedelt. Die nächsthöhere Ebene wird Pragmatik genannt und setzt ein Informationen verwendendes Individuum (Interpreter) in den Mittelpunkt. Damit aus Information Wissen werden kann, spielt die Wirkung der Information auf den Interpreter eine wichtige Rolle. Erst, wenn bekannt ist, welche Absichten mit einer Information verfolgt werden oder welchen Wert eine Information für den Benutzer hat, kann aus ihr Wissen werden. In dieser Arbeit werden zugunsten der besseren Lesbarkeit die Begriffe Daten und Information synonym verwendet Data Management Body of Knowledge Definition 2.2 (Datenmanagement) Das Datenmanagement befasst sich mit allen betrieblichen und technischen Aspekten der Datenmodellierung, Datenadministration, der Datentechnik und des datenbezogenen Benutzerservice. [Krc00] Die DAMA hat in ihrem Framework Data Management Body of Knowledge (DMBOK) [MBEH09] 10 verschiedene Teilfunktionen beim Datenmanagement identifiziert (vgl. Abbildung 2.3). Data Governance Planung, Überwachung und Stärkung des Datenmanagements auf hoher Abstraktionsebene Data Architecture Management Definition des betrieblichen Informationsbedarfs und Konzeption des unternehmensweiten Datenmodells im Kontext der Unternehmensarchitektur Data Development Umsetzung der datenzentrischen Aktivitäten im Rahmen des Systementwicklungslebenszyklus Data Operations Management Planung, Kontrolle und Unterstützung strukturierter Datenbestände über ihren Lebenszyklus hinweg Data Security Management Planung, Entwicklung und Umsetzung von geeigneten Sicherheitsrichtlinien Reference & Master Data Management Gewährleistung der Konsistenz mit einer goldenen Version kontextueller Datenwerte Data Warehousing & Business Intelligence Management Bereitstellung von entscheidungsunterstützenden Daten zur Unterstützung von Wissensarbeitern bei Reporting und Analyse 10

25 2.3 Datenmanagement Abbildung 2.3: Teilfunktionen des Datenmanagement [MBEH09] Document & Content Management Haltung, Sicherung und Zugriff auf Daten in Dateien und physischen Speichern Meta Data Management Bereitstellung von einfachem Zugriff auf hochqualitative und integrierte Metadaten Data Quality Management Anwendung von Maßnahmen Messung, Beurteilung, Verbesserung der Datenqualität im Rahmen eines Qualitätsmanagements Abschnitt 3.2 selektiert für diese Arbeit relevante Unterfunktionen und greift deren von der DAMA definierten Ziele für die weitere Verwendung im Konzept auf Information Technology Infrastructure Library Die Information Technology Infrastructure Library (ITIL) ist ein prozessorientiertes Best Practice Framework zur Bereitstellung von IT Services mit dem Ziel, bei hoher Servicequalität das betriebliche Risiko und Kosten zu minimieren [Lim13]. Da die im Laufe dieser Arbeit aus dem DMBOK entnommenen Ziele auf Rollen in der ITIL abgebildet werden, wird im Folgenden die Grundstruktur des Frameworks betrachtet. Der ITIL-Lifecycle (vgl. Abbildung 2.4) besteht aus fünf Phasen: Service Strategy definiert Rahmenbedingungen für Service Provider und soll ein allgemeines Verständnis von Strategie vermitteln und Services sowie deren Zielgruppe und Mehrwert definieren. Zur strategischen Planung gehören ebenfalls die Identifikation neuer potentieller Services, Finanzierung und Service Asset Management. 11

26 2 Stand der Forschung Abbildung 2.4: ITIL Lifecycle [iti07] Service Design ist zuständig für das Design von IT Practices sowie IT-Governance Practices, Prozesse und Richtlinien, um die Strategie des Service Providers zu realisieren. Zum Zwecke der Konzeption hocheffektiver IT Services wird insbesondere auf Qualität, Kundenzufriedenheit und kosteneffektive Servicebereitstellung geachtet. Service Transition verantwortet Planung und Verwaltung effizienter und effektiver Servicewechsel sowie Deployment von Service Releases und die Sicherstellung richtiger Erwartungen an Performance und Nutzung neuer Services. Bei Änderungen von Services wird sichergestellt, dass der erwartete Mehrwert geschaffen wird und notwendiges Wissen über die Service Assets bereitgestellt wird. Service Operation koordiniert und führt Aktivitäten aus, die zur Bereitstellung und Verwaltung von Services zu vereinbarten Service Levels für Nutzer und Kunden notwendig sind. Im täglichen Geschäft wird zudem die Zufriedenheit der Nutzer in die IT durch effektive und effiziente Bereitstellung der Services unter Minimierung der Auswirkungen von Störungen auf den Betrieb gesteigert. Continual Service Improvement ist zuständig für die Ausrichtung von IT Services an sich verändernde Geschäftsanforderungen durch Identifizierung und Implementierung von Verbesserungen zur Unterstützung von Geschäftsprozessen Metadaten Der Erfolgsfaktor zur Hebung der beschriebenen Nutzenpotenziale ist die übergreifende Verwaltung aller Metadaten über System-, Werkzeug- und Schichtengrenzen hinweg. Aufgabe dieses Metadatenmanagements ist es, die Metadaten zu erfassen, zu generieren, zu speichern, zu verwalten und den Benutzern zur Verfügung zu stellen. [ABEM09] 12

27 2.3 Datenmanagement Definition 2.3 (Metadaten) Unter dem Begriff Metadaten versteht man gemeinhin jede Art von Information, die für den Entwurf, die Konstruktion und die Benutzung eines Informationssystems benötigt wird. [BG04] Diese sehr umfassende Definition lässt darauf schließen, dass bspw. das Schlüssel-Management betreffende Informationen zu den Metadaten gehören. So muss auch nach der Datenintegration gewährleistet sein, dass jeder Datensatz über einen global eindeutigen Primärschlüssel identifiziert werden kann. Die Mappings von Schlüsseln der Datensätze in den Quellen zu globalen Surrogatschlüsseln sowie Integritätsbedingungen bei Fremdschlüsselbeziehungen gehören also ebenfalls zu den Metadaten. Semistrukturierte oder nicht strukturierte Daten wie Dokumentation vorhandener Datenstrukturen, Datenflüsse und Prozesse und anwendungsbezogene Daten, wie z.b. Geschäftsregeln zur Prüfung der Datenqualität, sind jedoch ebenfalls Teil der Metadaten. Benachrichtigungsregeln nach dem Schema (Kennzahl, Schwellwert, Kontaktperson) können eine hohe Akzeptanz beim Nutzer erlangen, vor allem, wenn die Benachrichtigungen proaktiv versendet werden und auch eine Zeitangabe mit der voraussichtlichen Verfügbarkeit der korrigierten Daten vorhanden ist [ABEM09]. Alle Metadaten werden in einem gemeinsamen Repository gespeichert, um den Aufwand für den Betrieb zu minimieren und den Informationsgewinn für das Data Warehouse zu optimieren Datenqualität In der ISO Norm 9000:2005 wird Qualität als Grad, in dem ein Satz inhärenter Merkmale Anforderungen erfüllt, definiert. Nachdem in Abschnitt 2.3 der Begriff der Daten eingeführt wurde und Qualität im Allgemeinen definiert ist, kann der zusammengesetzte Begriff der Datenqualität definiert werden. Definition 2.4 (Datenqualität) Datenqualität (DQ) ist ein mehrdimensionales Maß für die Eignung von Daten, den an ihre Erfassung/Generierung gebundenen Zweck zu erfüllen. Diese Eignung kann sich über die Zeit ändern, wenn sich die Bedürfnisse ändern. [Wü03] Für das Management der Datenqualität existieren verschiedene Geschäftstreiber [ABEM09], die oftmals den initialen Anstoß zur Verbesserung der Datenqualität liefern. Das Management muss sich bspw. bei der Entscheidungsfindung auf eine hohe Qualität der Daten verlassen können. Gerade bei strategischen Fragestellungen, wie der Entwicklung neuer Produkte, der Expansion auf neue Standorte oder der Planung von Kampagnen kann hohe Datenqualität einen entscheidenden Wettbewerbsvorteil bedeuten. Weiterhin können Mindestmaße für die Qualität der Daten durch Compliance gegeben sein; externe regulatorische Vorgaben sowie eine interne Revision können minimale Standards definieren. Durch höhere Datenqualität kann das operative Risiko minimiert werden und damit Kosten eingespart werden. 13

28 2 Stand der Forschung Das Verständnis des einzelnen Benutzers von der Semantik der Daten ist oftmals nicht stark ausgeprägt. Insbesondere, wenn der Datennutzer nicht für die Datenintegrität bzw. Datenpflege im Allgemeinen zuständig ist, kann ein fehlendes Interesse an der Semantik der Daten zu einer niedrigen Priorisierung der Datenqualität und zu Fehlinterpretationen führen. [TB98] Zur Messung und damit zur Überwachung der Datenqualität sind objektiv messbare Merkmale, Qualitätskriterien, erforderlich. So kann der jeweilige Erfüllungsgrad der Anforderungen durch den Datennutzer ermittelt werden [ABEM09]. Abbildung 2.5 zeigt eine Taxonomie von Kriterien für die Datenqualität in Anlehnung an [Hin02], deren einzelne Kriterien von Bauer und Günzel [BG04] beschrieben worden sind. Obwohl Integritätskriterien oftmals zu den Datenqualitätskriterien gezählt werden (vgl. Abbildung 2.5), zählt die Sicherung der Integrität bei der DAMA zum Data Operations Management (vgl. Abschnitt 3.2.1, DOM-1). Metadaten spielen eine wichtige Rolle für die Messung der Datenqualität [Hel02] und können selbst nach den Datenqualitätskriterien bewertet werden. Hinrichs definiert die Eindeutigkeit von Daten über die Auswertung bestimmter Datenqualitätskriterien auf die zugehörigen Metadaten: Definition 2.5 (Eindeutigkeit) Die Eigenschaft, dass ein Datenprodukt eindeutig interpretiert werden kann, d. h. zum Datenprodukt Metadaten hoher Qualität vorliegen, die dessen Semantik festschreiben. Metadatenqualität ist wiederum im Hinblick auf die genannten Datenqualitätsmerkmale zu bewerten [Hin02]. Hinrichs selektiert die Datenqualitätskriterien anhand dieser Definition und kommt zu dem Ergebnis, dass Konsistenz, Vollständigkeit und Genauigkeit der Metadaten die Eindeutigkeit bestimmen. Methoden zur Verbesserung der Datenqualität Vorgehensweisen zur Verbesserung der Datenqualität können in zwei Kategorien unterteilt werden [BCFM09]. Datengetriebene Strategien zielen auf eine Veränderung der Daten ab. Dies kann bspw. bedeuten, neue, aktuelle Daten bei mangelhafter Datenqualität zu akquirieren und die alten Daten zu ersetzen. Standardisierung (z.b. Erweiterung von Abkürzungen: Bob Robert) und probabilistische Record Linkage Algorithmen sind Möglichkeiten, Datensätze zu finden, die dasselbe Realweltobjekt unterschiedlich beschreiben. Prozessgetriebene Strategien verfolgen Änderungen an denjenigen Prozessen, welche Daten erzeugen. Auf diese Weise sollen durch process control Prozeduren zur Erstellung, Aktualisierung und Zugriff auf Daten überprüft und kontrolliert werden. Process redesign soll die Ursachen für schlechte Datenqualität beseitigen und Aktivitäten zur Erzeugung hoher Qualität definieren. Dies kann im Rahmen von Business Process Reengineering durchgeführt werden. Orr postuliert mit seiner Theorie über das Feedback-Control System (FCS) [Orr98], dass Datenqualität nicht von der Sammlung der Daten selbst, sondern deren Nutzung abhängt. Durch geringe Nutzung von Daten, beispielsweise aufgrund von niedriger Relevanz, Glaub- 14

29 2.3 Datenmanagement Abbildung 2.5: Datenqualitätskriterien - Taxonomie und Beschreibung [Hin02] 15

30 2 Stand der Forschung würdigkeit oder sonstigen Qualitätskriterien, entsteht eine Spirale von sinkendem Interesse an den Daten (bedingt durch eben beschriebene schwache Qualitätserfüllung) und konsekutiv einer noch geringeren Nutzung. 5 Die so entstehende Menge an Daten von minderwertiger Qualität bläht das DWH auf und dient nicht mehr den vorgesehenen Zwecken. Damit es nicht erst zu sinkender Datenqualität kommt, empfiehlt Orr mit seinem Motto use it or lose it! das Entfernen von länger nicht genutzten Daten. Falls seine Hypothese der Wahrheit entspricht, sind ernsthafte Probleme mit der Qualität von vertraulichen Daten aufgrund des beschränkten Nutzerkreises eine mögliche Folge. Orr [Orr98] begründet mit seiner These einen erhöhten Nutzen von der Durchführung von Nutzungsanalysen. Datenqualitätsmonitoring Im Mittelpunkt von Datenqualitätsmonitoring steht die laufende Überwachung der Datenqualität im Data Warehouse. Dies kann einerseits mittels definierter Kennzahlen und Berichte durchgeführt werden, andererseits lässt sich die Wirksamkeit von Maßnahmen zur Verbesserung der Datenqualität auch durch regelmäßiges Data Profiling verifizieren. [ABEM09] Das Datenqualitätsmonitoring ist ein Instrument zur Feststellung der Dynamik der Datenqualität, also der Entwicklung im Laufe der Zeit. Bei in ausreichendem Maße vorhandener Datenbasis können Prognosen für die zukünftige Datenqualität erstellt werden und frühzeitig korrektive Maßnahmen bei negativen Abweichungen von Sollwerten veranlasst werden. Es ermöglicht die Quantifizierung von Verbesserungen in der Datenqualität und erleichtert die Argumentation für das Kosten-Nutzen Verhältnis im DWH. Regelmäßiges Datenqualitätsmonitoring erhöht das Vertrauen in die vorhandenen Daten [ABEM09], was Voraussetzung für fundierte Entscheidungen und unter Umständen auch die Erfüllung von Compliancekriterien ist. Der Data Quality Monitoring Cycle [ABEM09] besteht aus drei Phasen und beginnt mit der Erkennung von Problemen im Rahmen des Monitoring. Relevante Informationen werden an die Stakeholder kommuniziert und die erkannten Probleme gelöst. Der Zyklus beginnt wieder bei der Erkennung neuer Probleme. Abbildung 2.6: Data Quality Monitoring Cycle [ABEM09] Es gibt zahlreiche weitere Ansätze zum Datenqualitätsmanagement, wie z.b. Use-Based 5 [SLW97] beschreibt eine abnehmende Nutzung bei niedriger Glaubwürdigkeit und somit Datenqualität. 16

31 2.4 Informationsaufbereitung und Cockpit-Bedienkonzept Data Quality [Orr98] oder Total Data Quality Management [PLW02]. Viele davon basieren auf dem Plan-Do-Check-Act (PDCA)-Zyklus von Deming. Im Wesentlichen setzt sich das Datenqualitätsmonitoring zum Ziel [ABEM09], eine periodische, allgemeine Überwachung der Datenqualität im Rahmen des laufenden Berichtwesens zu etablieren und die Nachvollziehbarkeit der Wirksamkeit von Datenqualitätsmaßnahmen zu gewährleisten. Trendanalyse und frühzeitige Identifikation von Risiken in Bezug auf Datenqualität sowie Initiierung von steuernden Maßnahmen gehören ebenfalls zu den Zielen. Diese versucht man im Rahmen der betrieblichen Berichterstattung durch Data Profiling zu erreichen. 2.4 Informationsaufbereitung und Cockpit-Bedienkonzept Ein Cockpit wird im Rahmen dieser Arbeit als Zusammenfassung mehrerer Dashboards mit ggf. zusätzlicher Funktionalität, wie z.b. ausführlicher Analysefunktionen zur Identifikation von Fehlern und Ursachen, verstanden. Stephen Few definiert den Begriff des Dashboards und legt damit einige zentrale Eigenschaften fest. Definition 2.6 (Dashboard) Ein Dashboard ist eine Anzeige der wichtigsten Informationen zum Erreichen einer oder mehrerer Zielvorgaben. Diese Informationen sind derartig auf einer einzigen Bildschirmgröße konsolidiert und angeordnet, dass sie auf einen Blick überwacht werden können. [Few06] Zur Erstellung eines Dashboards sind nach Few definierte Zielsetzungen notwendig, deren Erreichung durch geeignete Kennzahlen überwacht werden sollen. Im Zuge dieser Arbeit wurden bereits Stakeholder und ihre Zielvorstellungen identifiziert. Ein Monitoring- Cockpit bildet über mehrere Dashboards die Sichten der verschiedenen Stakeholder ab. Jedes einzelne Dashboard beinhaltet Metriken und Visualisierungen zur Unterstützung der Tätigkeiten und Interessen bestimmter Stakeholder. Dabei müssen die kommunizierten Informationen anhand ihrer Relevanz für den jeweiligen Stakeholder gefiltert werden. Letztendlich darf das Informationsangebot eines einzelnen Monitoring-Dashboards nach Few nicht den Platz überschreiten, den eine Bildschirmgröße liefert. Edward Tufte definiert den Begriff Data-Ink als den nicht löschbaren Kern einer Grafik bzw. die nicht redundante Tinte, die zur Darstellung der Variation in den repräsentierten Zahlenwerten verwendet wird [Tuf83]. Auf dieser Grundlage definiert er die Data-Ink Ratio als Kennzahl zur Messung der Effizienz bzw. der Informationsdichte einer Grafik. Diese setzt die zur Darstellung von Daten verwendete Tinte ins Verhältnis zur insgesamt verwendeten Menge an Tinte. Data-Ink Ratio = data-ink total ink used to print the graphic Das Bedienkonzept kann zur Optimierung der Informationsversorgung die Prinzipien des information push 6 und information pull 7 miteinander kombinieren. 6 etwa automatische Informationsversorgung 7 etwa selbstständige Informationsbeschaffung 17

32 2 Stand der Forschung Reporting und Benachrichtigungen Die erste Komponente in der Informationsversorgung von Stakeholdern durch eine Überwachungslösung besteht in einem Reporting-System. Dieses System implementiert das information push-prinzip durch den Versand von vorab konstruierten Berichten in regelmäßigen Intervallen, die jeweils nur noch mit zwischenzeitlich geänderten Daten aktualisiert werden. Neben derartigen Standardberichten leisten insbesondere Abweichungsberichte eine Hilfestellung zur effektiven Benachrichtigung und Ermöglichung schneller Reaktionen auf Geschäftsvorfälle. Hierbei werden für bestimmte Kennzahlen und Messungen Grenzwerte definiert. Falls diese oder andere Geschäftsregeln bei einer Messung nicht eingehalten werden, wird der Versand eines Abweichungsberichts ausgelöst, der eine Ursachenanalyse durch eine definierte Person oder Rolle initiieren soll. Zur strukturierten Spezifikation aller zu benachrichtigender Stakeholder kann eine Betroffenheitsmatrix [ABEM09] verwendet werden. Benachrichtigungen können über verschiedene Kanäle versendet werden, so zum Beispiel per oder SMS oder aber als Benachrichtigung in einem zentralen Informationsportal. Der Eingriff in einen Prozessablauf erst bei Fehlern wird auch als Management by Exception [DW99] bezeichnet. Interaktive Analyse Der zweite und für diese Arbeit namensgebende Teil des Bedienkonzepts ist das Monitoring-Cockpit, welches dem information pull-prinzip entspricht. Diese Sammlung verschiedener Dashboards mit Analysefunktionalität dient als zentrale Anlaufstelle zur individuellen Informationsbeschaffung über den Zustand des zu überwachenden Objekts. Zur Unterstützung der analytischen Funktionalität sind insbesondere Werkzeuge geeignet, die die interaktive und explorative Navigation durch Daten und somit Gewinnung von Erkenntnissen erlauben. Datenhaltung im Hauptspeicher unterstützt Operationen wie interaktive Filterung oder drill-down großer Datenmengen mit ausreichend geringen Reaktionszeiten, um nicht auf die Verwendung statischer Berichte oder langwieriger Auswertungen per OLAP angewiesen zu sein. Dashboards können nach Few [Few06] strategisch, analytisch oder operativ sein. Derartige Eigenschaften sind insbesondere für analytische Dashboards, die beispielsweise zur Fehlerdiagnose eingesetzt werden, von Bedeutung. 18

33 3 Entwicklung des Konzepts Zunächst wird eine Auswahl von relevanten Funktionen des Datenmanagements aus dem DMBOK getroffen. Domänenspezifischen Rollen des Datenmanagements, die für die Erfüllung von Zielen verantwortlich sind, werden Rollen der ITIL zugeordnet, um auf diese Weise nicht nur für das Datenmanagement spezifische Stakeholder im Konzept einordnen zu können, sondern auch Stakeholder aus dem IT-Servicemanagement. So profitiert das Konzept von der weitläufigen Implementierung des ITIL-Standards in Unternehmen und stärkt seinen empfehlenden Charakter. Die den bereits gewählten Funktionen zugeordneten Ziele bilden die Grundlage für die Entwicklung von Metriken gemäß Goal-Question-Metric (GQM) Ansatz [Bas92]. GQM ist als Top-Down Ansatz zur Ableitung von Metriken über Fragestellungen zu Zielen für das Vorgehen in dieser Arbeit geeignet. Zur Ermittlung des Informationsbedarfs der Stakeholder werden Fragestellungen zu ihren Zielen erarbeitet, die später durch Kennzahlen und andere Analysen beantwortet werden sollen. Die so entwickelten Metriken werden Komponenten und Abläufen im Data Warehouse zugeordnet und bilden einen Kennzahlenkatalog. Ein Metamodell für einen Datenflussgraphen beschreibt die Zusammenhänge zwischen einzelnen Elementen des Graphen und darzustellenden Kennzahlen. So entsteht eine Methode, mit deren Hilfe für bestimmte Rollen aus dem Datenmanagement oder aus der IT-Organisation über die entsprechenden Ziele Metriken zur Überwachung dieser Ziele sowie Visualisierungen dafür empfohlen werden können. 3.1 Identifizierung der Stakeholder Ausgewählte Funktionen des Datenmanagements Im Kontext des in dieser Arbeit zu konzipierenden Monitoring-Cockpits für Data Warehouses werden im Folgenden vier Funktionen des DMBOK näher betrachtet. Die vier Funktionen setzen sich zusammen aus: Data Operations Management (DOM) Data Warehousing & Business Intelligence Management (DW-BIM) Metadatenmanagement (MDM) Datenqualitätsmanagement (DQM) DOM sichert den operativen Betrieb und hat die Überwachung der Datenbankperformance zur Aufgabe. Metriken bezüglich Verfügbarkeit und Performance der Datenbank ermöglichen dem DOM die effektive Durchführung der zugewiesenen Tätigkeiten. DW-BIM konzipiert und setzt eine Umgebung zur Unterstützung von Business Intelligence (BI)- Aktivitäten um und soll dabei Prozesse im DWH sowie BI-Aktivität überwachen und ver- 19

34 3 Entwicklung des Konzepts bessern. Hierbei werden insbesondere Messungen zur Analyse von Nutzung, Antwortperformance und Benutzerzufriedenheit angewandt. Die Datenqualität als kritischen Erfolgsfaktor des DWH verwaltet das DQM. Dieses definiert Metriken zur Beurteilung der Datenqualität und nimmt kontinuierliche Messungen zur Erkennung von Änderungen vor. Statistiken zu den Datenwerten und Geschäftsregeln für gültige Daten helfen bei der Erkennung von Daten minderer Qualität. Das MDM als Funktionseinheit zur Verwaltung von zur Konstruktion und Benutzung des DWH benötigten Daten spielt eine zentrale Rolle für Monitoring-Aktivitäten jeder Art, da beispielsweise Vergleichswerte für Kennzahlen oder Geschäftsregeln für gültige Wertebereiche zu den Metadaten gezählt werden. Die DAMA spezifiziert im DMBOK zu jeder Funktion Ziele, Aktivitäten und Rollen, die diese Aktivitäten durchführen Potentielle Stakeholder Aus dem DMBOK [MBEH09] werden grundsätzlich alle mit den ausgewählten Funktionen in Verbindung stehende Rollen als potentielle Zielgruppe für die in dieser Arbeit entwickelte Methode identifiziert. Der folgende Abschnitt analysiert die Ziele der Funktionen und wählt geeignete Ziele aus, sodass anhand dieser Auswahl die Menge der potentiellen Stakeholder auf die Menge der tatsächlich zu adressierenden Stakeholder eingeschränkt werden kann. So wird gewährleistet, dass nur diejenigen Stakeholder berücksichtigt werden, die mindestens eines der Ziele verfolgen, die in dieser Arbeit analysiert werden. 3.2 Ziele des Datenmanagements Im Folgenden werden die ausgewählten Funktionen des Datenmanagements mit ihren Zielen kurz vorgestellt sowie in diesem Kontext interessante Aktivitäten und verantwortliche Rollen genannt. Die Ziele der Funktionen sind von der DAMA [MBEH09] spezifiziert und werden dahingehend ausgewählt, ob sie im Zusammenhang mit einem operativanalytischen Monitoring-Cockpit stehen und im Umfang der wissenschaftlichen Fragestellungen dieser Arbeit enthalten sind Data Operations Management Definition 3.1 (Data Operations Management) Data Operations Management beschreibt Entwicklung, Wartung und Unterstützung strukturierter Daten, um den Wert von Datenressourcen für das Unternehmen zu erhöhen [MBEH09]. Aktivitäten und verantwortliche Rollen Die Schlüsselrolle nimmt hier der Datenbankadministrator (DBA) ein [MBEH09]. Dieser ist insbesondere für die Einhaltung der Datenbankperformance Service Levels und die Überwachung und Verbesserung der Datenbankperformance verantwortlich. Zu den Aufgaben des DBA gehört auch jede Tätigkeit zur Gewährleistung der Verfügbarkeit und Funktionstüchtigkeit der Datenbank. 20

35 3.2 Ziele des Datenmanagements Ziele des Data Operations Management DOM-1 Schutz und Gewährleistung der Integrität strukturierter Daten. DOM-2 Verwaltung der Verfügbarkeit von Daten über ihren Lebenszyklus. DOM-3 Optimierung der Performance von Datenbanktransaktionen Data Warehousing & Business Intelligence Management Definition 3.2 (DW-BIM) Data Warehousing & Business Intelligence Management (DW-BIM) ist die Sammlung, Integration und Präsentation von Daten für Wissensarbeiter zum Zwecke der Geschäftsanalyse und Entscheidungsfindung. DW-BIM besteht aus Aktivitäten, die alle Phasen des Lebenszyklus der Entscheidungsfindung unterstützen. In diesem Lebenszyklus werden die Daten im Kontext betrachtet, von Quellen an ein zentral bekanntes Ziel verschoben und transformiert und anschließend den Wissensarbeitern zur Einsicht, Veränderung und Berichterstattung zur Verfügung gestellt [MBEH09]. Aktivitäten und verantwortliche Rollen Für Monitoring und Verbesserung der Prozesse im DWH sind DBA und Data Integration Specialist (DIS) zuständig. Monitoring und Verbesserung der BI-Aktivitäten verantworten DBA, Business Intelligence Specialist (BIS) und Business Intelligence Analyst (BIA). Dazu gehören beispielsweise die Feststellung der Nutzerzufriedenheit mit den BI- Lösungen sowie die Erhebung von Benutzungsstatistiken. Ziele des Data Warehousing & Business Intelligence Management DW-BIM-1 Unterstützung und Ermöglichung effektiver Geschäftsanalysen und Entscheidungsfindung durch Wissensarbeiter. DW-BIM-2 Konstruktion und Instandhaltung der Umgebung bzw. Infrastruktur zur Unterstützung von BI-Aktivität, insbesondere durch den wirksamen Einsatz aller anderen Datenmanagement (DM)-Funktionen zur kosteneffektiven Lieferung konsistenter und integrierter Daten für alle BI-Aktivitäten Metadatenmanagement Definition 3.3 (Metadatenmanagement) Metadatenmanagement ist die Menge der Prozesse, die eine geeignete Erstellung, Lagerung, Integration und Kontrolle zur Unterstützung der verknüpften Nutzung von Metadaten gewährleisten [MBEH09]. Aktivitäten und verantwortliche Rollen Metadatenmanagement stellt eine wichtige Funktion für das Datenmanagement dar, liefert aber aufgrund der strategischen Natur der zugehörigen Ziele keine Aspekte, die der 21

36 3 Entwicklung des Konzepts Überwachung im Rahmen eines operativ-analytischen Monitoring-Cockpits bedürfen. Abschnitt liefert eine weitergehende Ausführung dazu, weshalb die Ziele des Metadatenmanagements in dieser Arbeit nicht weiter betrachtet werden. Ziele des Metadatenmanagement MDM-1 Gewährung von Verständnis für Begriffe des Metadatenmanagements und deren Verwendung im Unternehmen. MDM-2 Integration von Metadaten aus verschiedenen Quellen. MDM-3 Gewährleistung eines einfachen und integrierten Zugangs zu Metadaten. MDM-4 Sicherstellung der Qualität und Sicherheit von Metadaten Datenqualitätsmanagement Definition 3.4 (Datenqualitätsmanagement) Datenqualitätsmanagement besteht aus aufeinander abgestimmten Tätigkeiten zur Leitung und Lenkung einer Organisation bezüglich Datenqualität [Hin02]. Aktivitäten und verantwortliche Rollen Beim Datenqualitätsmanagement finden sich insbesondere die Rollen des Data Quality Analyst (DQA) und Data Quality Manager (DQMan). Unter die Zuständigkeit des DQA fällt die Analyse und Beurteilung der Datenqualität. Für Management und Monitoring der Datenqualität ist der DQMan verantwortlich. Beide Rollen übernehmen gemeinsam die Überwachung der Prozeduren und Performance des operativen Datenqualitätsmanagements. Ziele des Datenqualitätsmanagements DQM-1 Messbare Verbesserung der Datenqualität in Bezug auf definierte Geschäftserwartungen. DQM-2 Definition von Anforderungen und Spezifikationen zur Integration von Datenqualitätsmanagement in den Systementwicklungslebenszyklus. DQM-3 Bereitstellung definierter Prozesse zur Messung, Überwachung und Meldung von Konformität zu angemessenen Levels von Datenqualität Ziele in der weiteren Betrachtung Im weiteren Verlauf dieser Arbeit werden nicht alle vorgestellten Ziele des Datenmanagements als Grundlage für Metriken verwendet. Da nicht alle Ziele in gleicher Weise geeignet sind, den Grad ihrer Erfüllung im Rahmen eines operativ-analytischen Überwachungscockpits festzustellen, folgt eine Auswahl von relevanten Zielen, auf der der Fokus in dieser Arbeit liegt. 22

37 3.2 Ziele des Datenmanagements Die Ziele des Data Operations Management betreffen den operativen Betrieb der Datenbank und der Grad ihrer Erfüllung ist im Hinblick auf bestehende Service Level Agreements zu überwachen. Metriken zur Überprüfung von Datenintegrität, Verfügbarkeit und Performance unterstützen bei der Fehleranalyse und können Hinweise auf Störungen zugrunde liegenden Ursachen liefern. Überwachung und optimale Ausrichtung der Infrastruktur an die geschäftlichen Bedürfnisse im Sinne des Data Warehousing & Business Intelligence Management sowie Datenintegration gehören ebenfalls zu den operativen Tätigkeiten und bedürfen einer kontinuierlichen Überwachung und Beseitigung von Fehlern. BI Applikationen gehören zur Anwendungsschicht, unter der das DWH die Ebene der Datenhaltung darstellt. Die BI-Schicht als zentrale Schnittstelle zum Benutzer dient als wichtiger Punkt zur Messung des Erfolgs des Gesamtsystems und damit als Ausgangspunkt für Argumentationen in Bezug auf das Aufwand-Nutzen-Verhältnis. An dieser Stelle sind Messungen zur Nutzerzufriedenheit und zu den Nutzerzahlen von besonderer Bedeutung. Die Datenqualität kann großen Einfluss auf den Erfolg eines solchen Gesamtsystems haben. Aus diesem Grunde sollte die Entwicklung der Datenqualität über die Zeit überwacht werden. Die so entstehenden Messdaten können einen Beitrag zur Ermittlung der Ursachen für eine geringe Nutzerzufriedenheit mit dem System leisten. Ein effizientes operatives Datenqualitätsmanagement soll die effektive Aufnahme, Bearbeitung und Nachverfolgung von Problemen mit der Datenqualität gewährleisten und passt ebenfalls in das Konzept des operativ-analytischen Monitoring-Cockpits. Von der weiteren Betrachtung ausgeschlossene Ziele Von der weiteren Betrachtung im Zuge dieser Arbeit sind sämtliche Ziele des Metadatenmanagements ausgeschlossen. Einer Überwachung der Erreichung der Ziele des MDM stehen verschiedene Schwierigkeiten entgegen, deren Überwindung den Rahmen dieser Arbeit sprengen würde. Des Weiteren übersteigen nicht-operative Ziele dem Umfang der Forschungsfragen bzw. der Ziele dieser Arbeit. Zunächst stellt ein weit verbreitetes Verständnis von Begrifflichkeiten, Abläufen und Bedeutung des Metadatenmanagements im Unternehmen das Fundament für die erfolgreiche Verwaltung von Metadaten. Die Erhebung der Informationen hierzu hat jedoch einen strategischen Charakter für das Unternehmen und ist nicht im Rahmen eines operativen Cockpits zu überwachen. Ebenso gehören integrierte, gut zugängliche und hochqualitative Metadaten zu strategisch wertvollen Zielen, da insbesondere die Datenqualität von hoher Metadatenqualität profitiert (vgl. Abschnitt 2.3.3). Der Grad der Erreichung dieser Ziele soll jedoch ebenfalls nicht in einem operativen Cockpit überwacht werden. Einerseits erfordern diese Ziele aufgrund ihrer strategischen Natur eine geringere Periodizität bei der Erhebung zugehöriger Kennzahlen. So scheint es sinnfrei, auf einer täglichen Basis zu analysieren, welche neuen Quellen zur Integration von Metadaten verwendet werden können. Es existieren aber auch ganz praktische Probleme, wie zum Beispiel in dem Falle, dass Metadaten in nicht oder nur semistrukturierter Form vorliegen. Diese können, im Gegensatz zu strukturierten Metadaten, nur mit erheblichem Aufwand oder gar nicht automatisiert analysiert werden. Ferner wird die Überwachung der Integration des Datenqualitätsmanagements in den 23

38 3 Entwicklung des Konzepts DM-Ziel DOM-1 DOM-2 DOM-3 DW-BIM-1 DW-BIM-2 DQM-1 DQM-3 Kurze Erläuterung der Wahl Datenintegrität als operatives Ziel soll in einem operativen Cockpit überwacht werden. Daten- und Systemverfügbarkeit als operative Ziele sollen in einem operativen Cockpit überwacht werden. Datenbankperformance als operatives Ziel soll in einem operativen Cockpit überwacht werden. Hohe Akzeptanz eines BI-Systems bei Wissensarbeitern deutet auf die Möglichkeit zur Durchführung effektiver Geschäftsanalysen hin. Diese soll im Cockpit gemessen und überwacht werden. Die Überwachung und optimale Ausrichtung der Infrastruktur an die geschäftlichen Bedürfnisse sollen in einem Cockpit überwacht werden. Der Zustand und die Dynamik der Datenqualität als frühzeitige Indikatoren für Störungen und Probleme im BI-Gesamtsystem sollen in einem operativen Cockpit überwacht werden. Die Überwachung des operativen Datenqualitätsmanagements soll in einem operativen Cockpit überwacht werden. Tabelle 3.1: Kurzdarstellung der Wahl der Datenmanagement-Ziele Systementwicklungslebenszyklus von der weiteren Betrachtung ausgeschlossen. Dies ist ebenfalls ein strategisches Ziel und soll nicht Teil einer operativen Überwachungslösung werden. Zusammenfassung Tabelle 3.1 zeigt eine zusammenfassende Übersicht über die aus der ursprünglichen Liste der Ziele des Datenmanagements gewählten Ziele. So verbleiben nach der Auswahl lediglich sieben Ziele für die weitere Behandlung in dieser Arbeit. 3.3 Analyse der Stakeholder In diesem Abschnitt werden Ziele und Rollen [MBEH09] des Datenmanagements in Zusammenhang gesetzt. Verantwortliche Rollen nach Modell der DAMA werden Rollen aus der ITIL zugeordnet, um später eine Anforderungsanalyse aus Sicht des IT Service Managements betreiben zu können. Die Analyse der Stakeholder ist ein notwendiger Schritt zur Entwicklung von Metriken gemäß GQM, da der zweite Schritt bei GQM die Ableitung von Fragestellungen aus der Sicht von bestimmten Stakeholdern vorsieht [Bas92]. Rollen, die in Abschnitt 3.1 eingeführt wurden und keinem Ziel zugeordnet werden, werden in dieser Arbeit nicht weiter berücksichtigt. In Abschnitt 3.4 werden die Ziele aufgegriffen und Fragestellungen dazu entwickelt. Die Beantwortung dieser Fragen soll Erkenntnisse über den Grad der jeweiligen Zielerreichung liefern. 24

39 3.3 Analyse der Stakeholder Zuordnung von Zielen zu DAMA-Rollen Abbildung 3.1 veranschaulicht die Zuordnung von DM-Zielen zu Rollen der DAMA nach [MBEH09]. Die vertikale Achse ist dabei den drei betrachteten Funktionen entsprechend unterteilt. Im Folgenden wird erläutert wie die Zuordnung von Zielen zu Aktivitäten und anschließend von Aktivitäten zu Rollen begründet ist. Abbildung 3.1: Zuordnung von DM-Zielen zu DM-Rollen Data Operations Management Datenbankperformance besteht aus den beiden grundlegenden Komponenten Verfügbarkeit und Performance [MBEH09]. Für die Einhaltung der Service Levels in Bezug auf Datenbankperformance sind DBAs zuständig. Durch diese Tätigkeit unterstützt der DBA die Umsetzung der Ziele Integrität (DOM-1) und Verfügbarkeit (DOM-2). Eine Optimierung der Performance (DOM-3) erreicht der DBA durch Überwachung und Ermittlung von Verbesserungspotential. 25

40 3 Entwicklung des Konzepts Data Warehousing & Business Intelligence Management Das DMBOK empfiehlt die Überwachung und Verbesserung von DWH-Prozessen. Dadurch unterstützen DBA und Data Integration Specialist Konstruktion und Instandhaltung der BI-Infrastruktur und tragen zum Erreichen des Ziels DWH (DW-BIM-2) bei. Zudem sollen BI-Aktivitäten überwacht und verbessert werden. Dies kann durch einige nutzerorientierte Metriken erfolgen und trägt zum Erreichen des Ziels Analyse (DW- BIM-1) bei. Beispiele hierfür sind die durchschnittliche Antwortzeit für Anfragen oder die Anzahl der Nutzer in einem bestimmten Zeitintervall. Zusätzlich können regelmäßige Befragungen der Benutzer wertvolle Erkenntnisse liefern. Datenqualitätsmanagement Nach vorhergehender Filterung der Ziele des Datenqualitätsmanagements ist die Integration des DQM in den Systementwicklungslebenszyklus (DQM-2) weggefallen. Zu den anderen beiden Zielen empfiehlt die DAMA [MBEH09] drei für ein Monitoring-Cockpit relevante Aktivitäten. Analyse und Beurteilung der Datenqualität durch den Data Quality Analyst gehören zum Ziel Datenqualität (DQM-1). In Zusammenarbeit mit dem Data Quality Manager wird die Datenqualität jedoch auch über die Zeit überwacht, um so Aussagen über die Dynamik treffen zu können. Die Überwachung der Prozesse des operativen Datenqualitätsmanagements stellt sicher, dass die Erfüllung des Ziels operatives Datenqualitätsmanagement (DQM-3) eingehalten und überprüft werden kann Zuordnung von Zielen zu ITIL-Rollen Data Operations Management Die Datenbankadministration versteht sich als zentraler Sammelpunkt von Fachwissen über Datenbankdesign [HJ10]. Übertragen auf ITIL überschneidet sich dies mit mehreren Rollen. Zielübergreifend wird der DBA als Incident Manager und als Problem Manager tätig und verwaltet somit die Lebenszyklen aller Störungen und deren zugrunde liegender Probleme in seiner fachlichen Domäne. Bezogen auf das Ziel Integrität (DOM-1) setzt der DBA seine Fachkenntnisse ein und tritt als technischer Analyst zur Wahrung der Datenintegrität auf. Dazu gehören physische sowie logische Datenintegrität. Verfügbarkeit (DOM-2) zählt zu den Verantwortlichkeiten des Availability Managers und müssen an die vereinbarten Service Levels angepasst, überwacht und optimiert werden. Der DBA handelt auch im Interesse des Capacity Managers, um insbesondere die Optimierung der Performance (DOM-3) zu erreichen. Die Infrastruktur soll derartig angepasst werden, dass sie vereinbarte Anforderungen an die Performance kosteneffizient und zeitnah erfüllt. Derartige Optimierungen können auch einen positiven Einfluss auf die Verfügbarkeit des Services haben [MBEH09], sodass das Capacity Management auch die Erfüllung des Ziels Verfügbarkeit (DOM-2) unterstützt. Data Warehousing & Business Intelligence Management Beim DWH-Monitoring zum Erreichen des Ziels DWH (DW-BIM-2) ist nach [MBEH09] insbesondere der Data Integration Specialist (DIS) beteiligt. Dieser entspricht nach ITIL-Nomenklatur ver- 26

41 3.4 Informationsbedarfsanalyse schiedenen Rollen. So ist dieser am Incident und Problem Management beteiligt, da er über das nötige Fachwissen verfügt, um Störungen und zugrunde liegende Ursachen bei der Datenintegration zu beseitigen. Ähnlich wie der DBA beim DOM tritt auch der DIS im Interesse von Availability Manager und Capacity Manager zur Überwachung und Verwaltung von Verfügbarkeit und Performance der DWH Services auf. Entwicklung der nötigen Prozesse und Konfiguration des DWH übernimmt der DIS als technischer Analyst. BI-Spezialisten und Analysten ermöglichen durch ihre Tätigkeit effektive Analysen im Rahmen des Ziels Analyse (DW-BIM-1). Sie treten als technische Analysten auf, da sie durch ihr spezifisches Wissen bspw. die BI-Nutzerumgebung konzipieren und die effektive Nutzung von BI Daten durch Fachanwender ermöglichen. Die Messung von Nutzerzufriedenheit und Effektivität der Analysen liegt im Interesse des Continual Service Improvement (CSI) Managers. Datenqualitätsmanagement CSI beruht im Wesentlichen, wie viele DQM Methoden, auf dem PDCA-Zyklus von Deming [ABEM09]. Diese Verwandtschaft im Prozess und die Forderung nach einer kontinuierlichen Überwachung und Verbesserung der Datenqualität (DQM-1) lassen eine Zuordnung von Data Quality Analyst und Data Quality Manager zu CSI Manager zu. Zur Erfüllung des Ziels operatives Datenqualitätsmanagement (DQM-3) wirken Incident und Problem Management zur Störungserkennung und Störungsbeseitigung mit. Die Rolle des technischen Analysten wirkt bei der Konzeption der Prozesse mit. Abbildung 3.2 zeigt eine graphische Übersicht über die Zuordnungen der Ziele zu Rollen. 3.4 Informationsbedarfsanalyse Tabelle 3.2 zeigt eine Sammlung von Fragestellungen zu den bereits definierten Zielen. Diese Sammlung wurde in Zusammenarbeit mit dem Praxispartner entwickelt und dient im Rahmen des GQM-Ansatzes als Zwischenschritt zur späteren Entwicklung von Metriken. Fragestellungen im Sinne von GQM verstehen sich als konkreter Informationswunsch eines Stakeholders, um den Grad der Erreichung einer Zielvorgabe bestimmen zu können. Die Fragestellungen zu den Zielen des Bereichs DOM beziehen sich insbesondere auf die technischen Gegebenheiten in der Datenbankumgebung. Zur Überprüfung der Integrität (DOM-1) gehören Fragestellungen zu logischen Integritätsbedingungen und Integritätsverletzungen. Zur Messung der Verfügbarkeit (DOM-2) muss sowohl die Daten- als auch die Systemverfügbarkeit erhoben und ausgewertet werden. Die dritte Komponente des operativen Datenmanagements beinhaltet die Optimierung der Performance (DOM-3) der Datenbank und fragt einerseits nach von außen messbaren Daten, wie Antwortzeiten auf eine Anfrage. Aber auch interne Daten wie die Auslastung des Database Management System (DBMS) spielen eine Rolle. DW-BIM setzt sich aus der Anwendungsschicht und der zugrunde liegenden Infrastruktur zusammen. Zur Ermittlung der Erfüllung von Analyse (DW-BIM-1) dienen insbesondere Fragestellungen nach der Nutzerzufriedenheit sowie nach den Nutzerzahlen. Informationen über die angeforderten Berichte können bei unerwartet niedriger oder sinkender 27

42 3 Entwicklung des Konzepts Abbildung 3.2: Zuordnung von DM-Zielen zu ITIL-Rollen 28

43 3.4 Informationsbedarfsanalyse Ziel Nr. Fragestellung DOM-1 Q-1 Zu welchem Grad ist Integrität der Primärschlüssel gegeben? (Integrität) Q-2 Zu welchem Grad ist referenzielle Integrität gegeben? Q-3 Wie oft werden Integritätsbedingungen bei Schreibvorgängen verletzt? DOM-2 Q-4 Zu welchen Betriebszeiten ist die Datenbank verfügbar? (Verfügbarkeit) Q-5 Zu welchen Antwortzeiten sind die Daten verfügbar? Q-6 Sind die Daten zu den vereinbarten Betriebszeiten verfügbar? DOM-3 Q-7 Wie viele Anfragen werden verarbeitet? (Performance) Q-8 Wie lange dauert die Verarbeitung einer Anfrage im Schnitt? Q-9 Wie stark ist das System (in Phasen niedriger und hoher Auslastung) ausgelastet? DW-BIM-1 Q-10 Wie zufrieden sind die Nutzer mit dem Data Warehouse? (BI) Q-11 Wie entwickeln sich die Nutzerzahlen des Data Warehouse? Q-12 Wie viele der geplanten Anwender nutzen die DWH-Services? Q-13 Sind die Berichte (Daten) fehlerfrei? Q-14 Liegen die Antwortzeiten innerhalb eines vereinbarten Rahmens? Q-15 Welche Daten werden nicht (mehr) verwendet? DW-BIM-2 Q-16 In welchem Zeitrahmen laufen die ETL-Prozesse ab? (DWH) Q-17 Laufen die ETL-Prozesse im vereinbarten Zeitrahmen ab? Q-18 Sind die DWH Services gemäß Service Levels verfügbar? Q-19 Wie lange dauert die Wiederherstellung des DWH-Betriebs nach einem Fehler durchschnittlich? Q-20 Ist die Hardware für die heutige und zukünftige Verwendung optimal dimensioniert? Q-21 Besteht Handlungsbedarf beim ETL-Prozess? DQM-1 Q-22 Sind die betrachteten Daten plausibel? (Datenqualität) Q-23 Sind die betrachteten Daten glaubwürdig? Q-24 Sind die betrachteten Daten vollständig? Q-25 Sind die betrachteten Daten redundanzfrei? Q-26 Wie genau sind die betrachteten Daten? Q-27 Wie aktuell sind die betrachteten Daten? Q-28 Entsprechen die Daten den Kriterien für Schlüsselintegrität? Q-29 Sind die betrachteten Daten eindeutig interpretierbar? Q-30 Findet eine kontinuierliche Verbesserung der Datenqualität statt? DQM-3 Q-31 Besteht Handlungsbedarf beim DQM-Prozess? (Datenqualitäts- Q-32 Wie viele Fälle ungenügender Datenqualität sind festzustellen? management) Q-33 Wie viele Fälle ungenügender Datenqualität wurden behoben? Q-34 Wie lange dauert die Behebung von im DWH gemeldeten Datenqualitätsmängeln durchschnittlich? Q-35 Wie lange dauert die Behebung von bekannten Datenqualitätsfehlern im DWH durchschnittlich? Tabelle 3.2: Fragen zu Zielen des Datenmanagements 29

44 3 Entwicklung des Konzepts Nachfrage nach BI-Services Hinweise darauf liefern, ob eine ausreichende Servicequalität geliefert wurde. Seit längerer Zeit nicht mehr verwendete Daten, die auch keine zukünftige Nutzung mehr erwarten lassen, sollten zugunsten eines effizienten Umgangs mit den vorhandenen Ressourcen aus der Ebene der Datenhaltung gelöscht werden. Das Ziel DWH (DW-BIM-2) erfordert eine Überwachung ebendieser Ressourcen und eine optimale Anpassung der verfügbaren Kapazitäten an die benötigten. Messungen in Bezug auf Kapazität von Speichermedien, Rechenleistung und Netzwerkanbindung können bei der Beantwortung dieser Frage helfen. Die Analyse der ETL-Prozesse trägt zur Sicherstellung des korrekten Betriebs des DWH bei und sichert die gewünschten Funktionalitäten auf der Anwendungsebene. Das Datenqualitätsmanagement interessiert sich in erster Linie für die Messung der Datenqualität (DQM-1) und die Entwicklung dieser über die Zeit. Eine Taxonomie für Datenqualitätskriterien wurde bereits mit Abbildung 2.5 eingeführt und liefert die Grundlage für Fragestellungen. Diese Messungen müssen über die Zeitdimension analysiert werden, um feststellen zu können, ob die gewünschte Verbesserung in der Datenqualität erreicht worden ist. Durch die exakte Definition der Verantwortlichkeiten soll mithilfe von Systemen zur Verfolgung von Incidents sichergestellt werden, dass das operative Datenqualitätsmanagement (DQM-3) schnell handeln kann und auf Dauer alle erkannten Fehler abgearbeitet werden können [MBEH09]. Hier sind beispielsweise Fragestellungen in Bezug auf noch nicht behobene Fehler oder durchschnittliche Reparaturzeiten von Interesse. 3.5 Kennzahlen und notwendige Messungen Zur Vervollständigung der Vorgehensweise im Rahmen des GQM-Ansatzes müssen nun zu den entwickelten Fragestellungen passende Metriken entwickelt werden. Gerade für den Bereich der Datenqualität veranschaulichen Apel et al. [ABEM09] einige mit Kennzahlen verbundene Problemstellungen. So sind nicht alle Datenqualitätskriterien messbar, einige sind nur zu einem bestimmten Grad messbar. Kennzahlen sollen Indikatoren für Probleme bzw. Problembereiche sein und der Erstanalyse dienen, nicht jedoch einer Fehleranalyse. Dies kann beispielsweise durch Betrachtung von historischen Änderungen oder Warnungen bei Abweichung von Planwerten erfolgen. Sie führen ebenfalls Argumente an, um die Nutzung von Kennzahlen zu begründen: Kennzahlen werden zu Beginn ihres Einsatzes grundsätzlich als geeignet zur Messung eines bestimmten Sachverhalts eingestuft und eignen sich somit im späteren Verlauf zur Argumentation auf Basis von anerkannten Fakten. Sie können Abweichungen des Istzustands von Planwerten veranschaulichen und die Veränderung von Kriterien über die Zeit aufzeigen. Im betrieblichen Kontext können Metriken ein Bewusstsein für die Datenqualität schaffen und Mitarbeiter zur Optimierung animieren. Definition und Erhebung von Kennzahlen sollte kein Selbstzweck, sondern Ausgangspunkt für Verbesserungen sein [ABEM09] und stets der Erfüllung von übergeordneten Zielen dienen. Diesem Anspruch wird im Rahmen dieser Arbeit durch den Goal-Question-Metric-Ansatz Genüge getan. Im Folgenden werden Messpunkte sowie Messebenen für Kennzahlen im DWH-Kontext definiert, um eine Möglichkeit zur Klassifikation der Kennzahlen zu schaffen. Diese wird im Metamodell des Datenflussgraphen (vgl. Abschnitt 3.6) wieder aufgegriffen. Abschnitt 30

45 3.5 Kennzahlen und notwendige Messungen beinhaltet den Kennzahlenkatalog, der die Grundlage für das zu entwickelnde Monitoring-Cockpit liefert. Eine Metrik-Ziel-Matrix stellt Kennzahlen und die Ziele, deren Grad der Erreichung diese messen, übersichtlich dar und geht dem detaillierten Katalog voraus Messpunkte für Datenqualität im Data Warehouse An den fünf verschiedenen Ebenen der klassischen DWH-Architektur können Messungen bezüglich der Datenqualität [ABEM09] vorgenommen werden: Quellsysteme Messung ist abhängig von der Machbarkeit und der Kosten im Einzelfall und kann zu einem operationalen Risiko (Performanceeinbußen) führen. Ein sinnvoller Messpunkt, um bereits bei Erfassung der Daten z.b. auf einheitliche Formate oder Wertebereiche zu achten. Staging Area Ein geeigneter Messpunkt für einfache Messungen im Rahmen von ETL- Läufen, z.b. Anzahl an NULL-Werten oder erste Integritätsprüfungen. Es besteht die Möglichkeit zum Vergleich mit Sollwerten aus dem Metadaten-Repository oder zum automatisierten Vergleich der aktuellen Fehlerliste mit der vom letzten ETL-Lauf. DWH Im Datenhaltungsbereich können automatisierte Berechnungen durch Prozeduren implementiert werden. Die Kennzahlen auf dieser Ebene bauen auf der unternehmensweiten Geschäftslogik und sind insbesondere für Datenbereichs- und Quellsystemübergreifende Messungen geeignet, wie z.b. Konsistenzprüfungen. Data Marts Auf dieser Ebene sind meist aggregierte Daten bzw. fachbereichspezifische Logik und Kennzahlen angesiedelt. Die Kennzahlen auf dieser Ebene beantworten primär fachliche Fragestellungen, wie z.b. den Umsatz einer Vertriebsabteilung. DWH-Anwendung In der einfachsten Form sind Berechnungen in den Berichten aufzufinden. Definierte Summengrößen können automatisiert an Verantwortliche der Quellsysteme rückgemeldet werden und mit den Daten in den operativen Systemen abgeglichen werden. Diese Schicht wird in [ABEM09] ursprünglich als Schicht der BI Anwendungen benannt. Da die Daten im DWH aber auch von anderen Applikationen verwendet werden können, wurde die Schicht in dieser Arbeit umbenannt. Letztendlich muss der Ort der Implementierung der Kennzahlen nach technischen Kriterien, Kosten und Verfügbarkeit der Daten abgewogen und entschieden werden [ABEM09]. Die Angaben im Kennzahlenkatalog (vgl. Abschnitt 3.5.3) zum Messpunkt einer Kennzahl verstehen sich als eine Empfehlung für einen möglichst frühen Messpunkt in der Datenverarbeitungskette, um Fehler möglichst früh aufzudecken und eine mögliche Verbreitung in nachfolgende Systeme zu vermeiden [ABEM09] Ebenen der Messung von Kennzahlen Kennzahlen können auf verschiedenen Aggregationsebenen in der Datenbank erhoben werden [Hin02]. Die folgende Liste beschreibt diese Ebenen, aufsteigend geordnet nach dem Grad der Aggregation. Attributebene Metriken, denen der Wert eines einzelnen Attributs zur Berechnung zugrunde liegt. 31

46 3 Entwicklung des Konzepts Tupelebene Metriken, denen ein einzelner Datensatz mit den Ausprägungen mehrerer Attribute zur Berechnung zugrunde liegt. Relationenebene Metriken, denen eine Relation mit den enthaltenen Datensätzen zur Berechnung zugrunde liegt. Datenbankebene Metriken, denen eine Datenbank mit den enthaltenen Relationen zur Berechnung zugrunde liegt. Grundsätzlich können Metriken, die auf einer Ebene geringer Aggregation erhoben werden, auch auf eine höhere Ebene aggregiert werden. Umgekehrt ist dies im Allgemeinen nicht möglich. Die Angaben im Kennzahlenkatalog (vgl. Abschnitt 3.5.3) zur Ebene einer Kennzahl verstehen sich somit als Hinweis auf die minimale Aggregationsebene, auf der die entsprechende Kennzahl dargestellt werden kann. Da jedoch im weiteren Verlauf auch Metriken definiert werden, die nicht innerhalb der Datenbank bzw. innerhalb des Data Warehouse, sondern in der äußeren Anwendungsschicht gemessen werden, wird noch eine zusätzliche Messebene eingeführt: Systemebene Metriken, denen ein DBMS als Gesamtsystem aus Sicht der DWH-Anwendungsschicht zugrunde liegt. Die Erhebung von prozessbezogenen Kennzahlen erfordert die Erfassung entsprechender Metadaten über den Prozess selbst sowie über seine Performance während der Ausführung, da eine Prozessinstanz, im Gegensatz zu herkömmlichen Daten, selbst nicht persistent ist. Prozessmetadaten sind keine Informationen, die in den Daten intrinsisch vorliegen, sondern liefern Informationen über den Kontext von Daten [SEW06]. Die Zuordnung von Prozessmetriken zu einer der bereits eingeführten Ebenen ist aufgrund ebendieser Eigenschaften nicht sinnvoll. Es wird eine neue Messebene speziell für Prozesse im DWH eingeführt: Prozessebene Metriken, denen explizite prozessbezogene Metadaten zugrunde liegen Kennzahlenkatalog Tabelle 3.3 liefert eine Übersicht darüber, welche Kennzahlen es ermöglichen, den Grad der Erfüllung bestimmter Ziele zu messen. So kann bei bereits gewählten Zielen (vgl. Abbildung 3.2 zur Wahl von Zielen bei bekannten Rollen) eine schnelle Auswahl der passenden Metriken zur Deckung des Informationsbedarfs vorgenommen werden. Im Anschluss zur Übersicht folgt der Kennzahlenkatalog, dem Detailinformationen zu jeder Metrik entnommen werden können. 32

47 3.5 Kennzahlen und notwendige Messungen Metrik Name DOM-1 Integrität DOM-2 Verfügbarkeit DOM-3 Performance DW-BIM-1 BI DW-BIM-2 DWH DQM-1 Datenqualität M-1 Schlüsseleindeutigkeit X X M-2 Referenzielle Integrität X X M-3 Systemverfügbarkeit X X M-4 MTBF X X M-5 MTTR X X X M-6 Datenverfügbarkeit X X M-7 Anfragen-Wachstumsrate X X M-8 Anfragedauer X X M-9 Ressourcenauslastung X X M-10 Benutzerzufriedenheit X M-11 Benutzerwachstum X M-12 Akzeptanz X M-13 Ungenutzte Datensätze X M-14 ETL-Dauer X M-15 ETL-Zeilendurchsatz X M-16 ETL-Datendurchsatz X M-17 Datensatz-Filterquote X X M-18 Robustheit X X M-19 Korrektheit X X M-20 Konsistenz X M-21 Vollständigkeit X M-22 Redundanzfreiheit X M-23 Genauigkeit X M-24 Alter X M-25 Aktualitätsrate X M-26 Eindeutigkeit X Tabelle 3.3: Zuordnung von Kennzahlen zu Zielen DQM-3 Datenqualitätsmanagement 33

48 3 Entwicklung des Konzepts M-1 Schlüsseleindeutigkeit [Hin02] Erläuterung DM-Ziel(e) Frage(n) Messpunkt Ebene Anzahl eindeutiger Primärschlüssel im Verhältnis zur Anzahl Datensätze. DOM-1: Integrität DQM-1: Datenqualität Q-1: Zu welchem Grad ist Integrität der Primärschlüssel gegeben? Q-28: Entsprechen die Daten den Kriterien für Schlüsselintegrität? Q-30: Findet eine kontinuierliche Verbesserung der Datenqualität statt? Staging Area Relationenebene M-2 Referenzielle Integrität [Hin02] Erläuterung DM-Ziel(e) Frage(n) Messpunkt Ebene Anzahl der Verstöße gegen definierte Multiplizitäten in Fremdschlüsselbeziehungen im Verhältnis zur Anzahl der insgesamt referenzierten Fremdschlüssel. DOM-1: Integrität DQM-1: Datenqualität Q-2: Zu welchem Grad ist referenzielle Integrität gegeben? Q-28: Entsprechen die Daten den Kriterien für Schlüsselintegrität? Q-30: Findet eine kontinuierliche Verbesserung der Datenqualität statt? DWH Relationenebene M-3 Systemverfügbarkeit [Leu01] Erläuterung DM-Ziel(e) Frage(n) Messpunkt Ebene Zeit, in der das System verfügbar ist, im Verhältnis zur Zeit, in der das System verfügbar sein soll. DOM-2: Verfügbarkeit DW-BIM-2: DWH Q-4: Zu welchen Betriebszeiten ist die Datenbank verfügbar? Q-18: Sind die DWH Services gemäß Service Levels verfügbar? DWH-Anwendung Systemebene M-4 MTBF [SVD + 09] Erläuterung DM-Ziel(e) Frage(n) Messpunkt Ebene Durchschnittliche zwischen Fehlern verstreichende Zeit. DOM-2: Verfügbarkeit DW-BIM-2: DWH Q-4: Zu welchen Betriebszeiten ist die Datenbank verfügbar? Q-18: Sind die DWH Services gemäß Service Levels verfügbar? Staging Area Relationenebene 34

49 3.5 Kennzahlen und notwendige Messungen M-5 MTTR [SVD + 09] Erläuterung DM-Ziel(e) Frage(n) Messpunkt Ebene Durchschnittliche Zeit zur Fehlerbehebung. Unterscheidung nach Fehlertyp. DOM-2: Verfügbarkeit DW-BIM-2: DWH DQM-3: Datenqualitätsmanagement Q-4: Zu welchen Betriebszeiten ist die Datenbank verfügbar? Q-18: Sind die DWH Services gemäß Service Levels verfügbar? Q-19: Wie lange dauert die Wiederherstellung des DWH-Betriebs nach einem Fehler durchschnittlich? Q-31: Besteht Handlungsbedarf beim DQM-Prozess? Q-34: Wie lange dauert die Behebung von im DWH gemeldeten Datenqualitätsmängeln durchschnittlich? Q-35: Wie lange dauert die Behebung von bekannten Datenqualitätsfehlern im DWH durchschnittlich? Staging Area Relationenebene M-6 Datenverfügbarkeit [BCFM09] Erläuterung DM-Ziel(e) Frage(n) Messpunkt Ebene Tatsächliche Antwortzeit auf eine Anfrage im Verhältnis zu einer festgelegten maximalen Antwortzeit. DOM-2: Verfügbarkeit DW-BIM-1: Analyse Q-5: Zu welchen Antwortzeiten sind die Daten verfügbar? Q-6: Sind die Daten zu den vereinbarten Betriebszeiten verfügbar? Q-14: Liegen die Antwortzeiten innerhalb eines vereinbarten Rahmens? DWH-Anwendung Systemebene M-7 Anfragen-Wachstumsrate Erläuterung DM-Ziel(e) Frage(n) Messpunkt Ebene Anzahl der Anfragen in der aktuellen Periode im Verhältnis zur Anzahl der Anfrage in der vorhergehenden Periode. DOM-3: Performance DW-BIM-2: DWH Q-7: Wie viele Anfragen werden verarbeitet? Q-20: Ist die Hardware für die heutige und zukünftige Verwendung optimal dimensioniert? Staging Area Relationenebene 35

50 3 Entwicklung des Konzepts M-8 Anfragedauer Erläuterung DM-Ziel(e) Frage(n) Messpunkt Ebene Durchschnittliche Dauer zur Verarbeitung einer Anfrage in der Datenbank aus einer Referenzmenge von Anfragen. DOM-3: Performance DW-BIM-2: DWH Q-8: Wie lange dauert die Verarbeitung einer Anfrage im Schnitt? Q-20: Ist die Hardware für die heutige und zukünftige Verwendung optimal dimensioniert? Staging Area Relationenebene M-9 Ressourcenauslastung Erläuterung DM-Ziel(e) Frage(n) Messpunkt Ebene Auslastung einzelner Hardware-Ressourcen. Unterscheidung nach CPU, Arbeitsspeicher und persistentem Speicher. DOM-3: Performance DW-BIM-2: DWH Q-9: Wie stark ist das System (in Phasen niedriger und hoher Auslastung) ausgelastet? Q-20: Ist die Hardware für die heutige und zukünftige Verwendung optimal dimensioniert? Staging Area Relationenebene M-10 Benutzerzufriedenheit [Küt11] Erläuterung DM-Ziel(e) Frage(n) Messpunkt Ebene Zufriedenheit der Benutzer mit den DWH-Services. Erhebung über Umfragen und Interviews, z.b. im Rahmen von Mitarbeitergesprächen. [Küt11]. DW-BIM-1: Analyse Q-10: Wie zufrieden sind die Nutzer mit dem Data Warehouse? DWH-Anwendung Systemebene M-11 Benutzerwachstum [Küt11] Erläuterung DM-Ziel(e) Frage(n) Messpunkt Ebene Anzahl der Nutzer in der betrachteten Periode im Verhältnis zur Anzahl der Nutzer in der vorhergehenden Periode. DW-BIM-1: Analyse Q-11: Wie entwickeln sich die Nutzerzahlen des Data Warehouse? DWH-Anwendung Systemebene 36

51 3.5 Kennzahlen und notwendige Messungen M-12 Akzeptanz Erläuterung DM-Ziel(e) Frage(n) Messpunkt Ebene Anzahl der tatsächlichen Nutzer der DWH-Services im Verhältnis zur Anzahl der geplanten Nutzer. DW-BIM-1: Analyse Q-12: Wie viele der geplanten Anwender nutzen die DWH-Services? DWH-Anwendung Systemebene M-13 Ungenutzte Datensätze [Orr98, KC04] Erläuterung DM-Ziel(e) Frage(n) Messpunkt Ebene Anteil ungenutzter Datensätze. Bemessungsgrundlage ist der Zeitpunkt des letzten Zugriffs verglichen mit einem festgelegten Schwellwert für veraltete Daten. DW-BIM-1: Analyse Q-15: Welche Daten werden nicht (mehr) verwendet? DWH Relationenebene M-14 ETL-Dauer [SVD + 09, SWCD09, KC04] Erläuterung DM-Ziel(e) Frage(n) Messpunkt Ebene Durchschnittliche Dauer eines ETL-Laufs. Unterscheidung nach ETL- Schritten. DW-BIM-2: DWH Q-16: In welchem Zeitrahmen laufen die ETL-Prozesse ab? Q-17: Laufen die ETL-Prozesse im vereinbarten Zeitrahmen ab? Q-21: Besteht Handlungsbedarf beim ETL-Prozess? Staging Area Prozessebene M-15 ETL-Zeilendurchsatz [SVD + 09, SWCD09, KC04] Erläuterung DM-Ziel(e) Frage(n) Messpunkt Ebene Anzahl verarbeiteter Datensätze pro Zeiteinheit. DW-BIM-2: DWH Q-16: In welchem Zeitrahmen laufen die ETL-Prozesse ab? Q-20: Ist die Hardware für die heutige und zukünftige Verwendung optimal dimensioniert? Q-21: Besteht Handlungsbedarf beim ETL-Prozess? Staging Area Prozessebene 37

52 3 Entwicklung des Konzepts M-16 ETL-Datendurchsatz [KC04] Erläuterung DM-Ziel(e) Frage(n) Messpunkt Ebene ETL-Zeilendurchsatz multipliziert mit der Größe einer Zeile. DW-BIM-2: DWH Q-16: In welchem Zeitrahmen laufen die ETL-Prozesse ab? Q-20: Ist die Hardware für die heutige und zukünftige Verwendung optimal dimensioniert? Q-21: Besteht Handlungsbedarf beim ETL-Prozess? Staging Area Prozessebene M-17 Datensatz-Filterquote [ABEM09] Erläuterung DM-Ziel(e) Frage(n) Messpunkt Ebene Anteil der angelieferten und nicht übernommenen Datensätze. Unterscheidung nach ETL-Job und Fehlercode. DOM-1: Integrität DW-BIM-2: DWH Q-3: Wie oft werden Integritätsbedingungen bei Schreibvorgängen verletzt? Q-21: Besteht Handlungsbedarf beim ETL-Prozess? Staging Area Prozessebene M-18 Robustheit [SVD + 09] Erläuterung DM-Ziel(e) Frage(n) Messpunkt Ebene Anteil der nach einem Fehler erfolgreich wieder aufgenommenen ETL Steps. Unterscheidung nach Fehlercode. DW-BIM-2: DWH DQM-3: Datenqualitätsmanagement Q-31: Besteht Handlungsbedarf beim DQM-Prozess? Q-33: Wie viele Fälle ungenügender Datenqualität wurden behoben? Q-21: Besteht Handlungsbedarf beim ETL-Prozess? Staging Area Prozessebene 38

53 3.5 Kennzahlen und notwendige Messungen M-19 Korrektheit [Hin02] Erläuterung DM-Ziel(e) Frage(n) Messpunkt Ebene Grad der Übereinstimmung des betrachteten Wertes mit dem Realweltzustand. DW-BIM-1: Analyse DQM-1: Datenqualität Q-13: Sind die Berichte (Daten) fehlerfrei? Q-23: Sind die betrachteten Daten glaubwürdig? Q-30: Findet eine kontinuierliche Verbesserung der Datenqualität statt? Q-32: Wie viele Fälle ungenügender Datenqualität sind festzustellen? Staging Area Attributebene M-20 Konsistenz [Hin02, SVD + 09] Erläuterung DM-Ziel(e) Frage(n) Messpunkt Ebene Grad der Konformität des betrachteten Wertes mit den Geschäftsregeln. DQM-1: Datenqualität Q-22: Sind die betrachteten Daten plausibel? Q-23: Sind die betrachteten Daten glaubwürdig? Q-30: Findet eine kontinuierliche Verbesserung der Datenqualität statt? Q-32: Wie viele Fälle ungenügender Datenqualität sind festzustellen? DWH Attributebene M-21 Vollständigkeit [Hin02] Erläuterung DM-Ziel(e) Frage(n) Messpunkt Ebene Anteil der Werte, die nicht unbekannt sind, an der Gesamtzahl der Werte. Ein nullable-attribut ist genau dann bekannt, wenn es nicht null ist. DQM-1: Datenqualität Q-24: Sind die betrachteten Daten vollständig? Q-30: Findet eine kontinuierliche Verbesserung der Datenqualität statt? Q-32: Wie viele Fälle ungenügender Datenqualität sind festzustellen? Staging Area Attributebene 39

54 3 Entwicklung des Konzepts M-22 Redundanzfreiheit [Hin02] Erläuterung DM-Ziel(e) Frage(n) Messpunkt Ebene Anzahl in der Datenbank repräsentierter Entitäten im Verhältnis zur Anzahl tatsächlich existierender Entitäten in der Realwelt. DQM-1: Datenqualität Q-24: Sind die betrachteten Daten vollständig? Q-25: Sind die betrachteten Daten redundanzfrei? Q-30: Findet eine kontinuierliche Verbesserung der Datenqualität statt? Q-32: Wie viele Fälle ungenügender Datenqualität sind festzustellen? DWH Relationenebene M-23 Genauigkeit [Hin02] Erläuterung DM-Ziel(e) Frage(n) Messpunkt Ebene M-24 Alter Erläuterung DM-Ziel(e) Frage(n) Messpunkt Ebene Tatsächliche Stelligkeit eines Wertes im Verhältnis zur optimalen Stelligkeit. Bei Dezimalzahlen kann die Stelligkeit (Genauigkeit) aus der Anzahl der geltenden Ziffern gebildet werden. Bei einer mehrstufigen Klassifikationshierarchie [Hin02] ist die optimale Stelligkeit die spezifischste Bezeichnung für eine Entität. 1 DQM-1: Datenqualität Q-26: Wie genau sind die betrachteten Daten? Q-30: Findet eine kontinuierliche Verbesserung der Datenqualität statt? Q-32: Wie viele Fälle ungenügender Datenqualität sind festzustellen? Staging Area Attributebene Zeit, die seit der letzten Änderung eines Datums vor der letzten Extraktion in das DWH bis hin zum Zeitpunkt der Abfrage abgelaufen ist. DQM-1: Datenqualität Q-27: Wie aktuell sind die betrachteten Daten? Q-30: Findet eine kontinuierliche Verbesserung der Datenqualität statt? Q-32: Wie viele Fälle ungenügender Datenqualität sind festzustellen? Staging Area Attributebene 1 Beispiel: Automobil und Motorrad hätten beide in einer Vererbungshierarchie mit Fahrzeug und Kraftfahrzeug als Vorgänger die Stelligkeit 3. Fahrzeug als Wurzel der Vererbung hätte die Stelligkeit 1. Eine Entität, die als Kraftfahrzeug beschrieben wurde hätte somit nicht die optimale Stelligkeit, da sie genauer hätte beschrieben werden können. 40

55 3.6 Datenflussanalyse und Datenflussgraph M-25 Aktualitätsrate [BP04] Erläuterung DM-Ziel(e) Frage(n) Messpunkt Ebene Anteil der aktuellen Werte an der Gesamtanzahl der Werte. Ein Wert ist aktuell, wenn er im Quellsystem seit der Extraktion noch nicht aktualisiert worden ist. DQM-1: Datenqualität Q-27: Wie aktuell sind die betrachteten Daten? Q-30: Findet eine kontinuierliche Verbesserung der Datenqualität statt? Q-32: Wie viele Fälle ungenügender Datenqualität sind festzustellen? Staging Area Relationenebene M-26 Eindeutigkeit [Hin02] Erläuterung DM-Ziel(e) Frage(n) Messpunkt Ebene Eindeutigkeit von Daten wird bestimmt über Konsistenz, Vollständigkeit und Genauigkeit (M-20, M-21, M-23) der zugehörigen Metadaten (vgl. Abschnitt 2.3.4). DQM-1: Datenqualität Q-29: Sind die betrachteten Daten eindeutig interpretierbar? Q-30: Findet eine kontinuierliche Verbesserung der Datenqualität statt? Q-32: Wie viele Fälle ungenügender Datenqualität sind festzustellen? DWH Attributebene 3.6 Datenflussanalyse und Datenflussgraph Auf dem in Abschnitt 2.2 eingeführten Konzept des Datenflusses bzw. der Data Provenance aufbauend wird im Folgenden das Konzept des Datenflussgraphen erläutert. Es wird ein Metamodell für den Graphen entwickelt, das alle für den weiteren Verlauf relevanten Komponenten enthält. Eine mögliche Darstellungsform für einen DFG führt Abschnitt ein Metamodell der Messobjekte Abbildung 3.3 zeigt ein auf die wesentlichen Elemente eines DFG abstrahiertes Metamodell. Ein DataObject ist diejenige Entität, welche die zu messenden Datensätze enthält die DataRows. Ein Process ist eine geordnete Menge einzelner Ausführungsschritte (Steps) und muss über mindestens ein DataObject als Ein- oder Ausgabe verfügen. Diese Eigenschaft wird über die Assoziationsklasse DataFlow spezifiziert, jedoch im den folgenden Metamodellen aufgrund des hohen Detailgrades ausgeblendet. Dasselbe DataObject kann sowohl Eingabe als auch Ausgabe für einen Prozess sein. 41

56 3 Entwicklung des Konzepts Abbildung 3.3: Grundlegendes Metamodell für den Datenflussgraphen Erweiterung des grundlegenden Metamodells Zur Modellierung des Datenflusses wird das grundlegende Metamodell um einige technische und fachliche Elemente erweitert. So müssen für die Betrachtung der Auswirkungen von Änderungen oder Beschädigungen an bestimmen Datenbankobjekten sowie zur Ermittlung derjenigen Datenbankobjekte, aus denen Daten für eine bestimmte Endansicht bzw. einen bestimmten Anwendungsfall gesammelt wurden beispielsweise interessierte Rollen hinzugefügt werden (vgl. Abbildung 3.4). Jedes Datenbankobjekt (DataObject) kann nun beliebig vielen Anwendungsfällen (Use- Case) als Datenquelle zugeordnet sein und jeder Anwendungsfall kann aus beliebig vielen Quelle Daten beziehen. An einem Anwendungsfall ist mindestens eine Rolle (Role) interessiert und jede Rolle ist an mindestens einem Anwendungsfall interessiert. Jedes DataObject gehört zu genau einer Schicht (DWHLayer) in der Architektur des Data Warehouse. Die Datenbank (Database) besteht aus einer Aggregation von Datenbankobjekten (DataObject), die ihrerseits wiederum Datensätze (DataRow) aggregieren. Datensätze bestehen jeweils aus mindestens einem Attribut (DataAttribute). Ein Datenbankobjekt ist in genau einer Datenbank enthalten, die von mindestens einem DBMS (DBMSystem) verwaltet wird. Ein DBMS kann mehrere Datenbanken verwalten Analysen und Messungen am Datenflussgraphen Anhand des Datenflussgraphen lassen sich verschiedene Messungen und Analysen durchführen. Dazu gehören nicht quantifizierbare Erkenntnisse, wie z.b. die bereits eingeführten Konzepte der Abstammungs- und Auswirkungsanalyse sowie quantifizierbare Messungen, wie Metriken. Zur Vorbereitung der Visualisierung von Kennzahlen am DFG muss zunächst ermittelt werden, welche Arten von Metriken anhand der verschiedenen Messobjekte unterschieden werden können und wie diese den Elementen des DFG zugeordnet werden können. Es können drei verschiedene Typen von Metriken unterschieden werden: Metriken, die Eigenschaften von Daten messen Metriken, die Eigenschaften des DBMS messen 42

57 3.6 Datenflussanalyse und Datenflussgraph Abbildung 3.4: Erweiterung des grundlegenden Metamodells Metriken, die Eigenschaften von Prozessen messen Die Basis für alle Messungen bilden diese drei Messobjekte, wobei die Daten unterschiedlich granular dargestellt werden können. Den Ebenen der Granularität entsprechen die in Abschnitt definierten Messebenen. Diese Einteilung wird als Grundlage für die folgende Modellierung verwendet. Abbildung 3.5 zeigt ein integriertes Metamodell der Zusammenhänge zwischen Kennzahlen und deren Messobjekten im Metamodell des DFG. Es ergeben sich gemäß Abschnitt sechs Messebenen zur Modellierung: Attribute werden durch das DataAttribute repräsentiert und von der DataAttribute- Metric gemessen. Datensätze werden durch die DataRow repräsentiert und von der DataRowMetric gemessen. Relationen werden durch das DataObject repräsentiert und von einer DataObjectMetric gemessen. Datenbanken werden durch die Database repräsentiert und von einer DatabaseMetric gemessen. DBMSs werden durch das DBMSystem repräsentiert und von einer SystemMetric gemessen. Prozesse werden durch den Process repräsentiert und von der ProcessMetric gemessen. 43

58 3 Entwicklung des Konzepts Abbildung 3.5: Erweitertes Datenflussgraph-Metamodell 44

59 3.6 Datenflussanalyse und Datenflussgraph Entsprechend den verschiedenen Ebenen der Datenaggregation lassen sich Metriken auf verschiedenen Ebenen definieren. Unter der Bedingung, dass aus jeder Metrik auf einer niedrigen Aggregationsstufe eine entsprechende Metrik höherer Aggregationsstufe definiert werden kann (z.b. über ein gewichtetes Mittel [Hin02]), ist jede Metrik auf Attributebene (DataAttributeMetric) zugleich Basis für eine Metrik auf Tupelebene (DataRowMetric) sowie transitiv für eine Metrik auf Relationenebene (DataObjectMetric) und Datenbankebene (DatabaseMetric). Diese Beziehungen werden im Metamodell durch die Assoziationen zum Ausdruck gebracht, die den Attribut-, Tupel-, Relationen- und Datenbankmetriken zugrunde liegen. Prozessmetriken messen einen Aspekt der Gesamtperformance eines Prozesses und erfordern Erhebung und persistente Speicherung von entsprechenden Metadaten (vgl. Abschnitt 3.5.2) Darstellung des Datenflussgraphen Die Struktur des DFG ist durch das Metamodell (vgl. Abbildung 3.5) spezifiziert. Im Folgenden wird ein Konzept erarbeitet, auf welche Weise Messungen am DFG dargestellt werden können und wie verschiedene Aggregationsstufen berücksichtigt werden können. Es werden verschiedene durch den DFG ermöglichte Analysen vorgestellt und Vorschläge zur Visualisierung gegeben. Grundstruktur Abbildung 3.6 zeigt die vorgeschlagene Grundstruktur für einen Datenflussgraphen auf der Stufe höchster Granularität. Datenbankobjekte werden durch rechteckige Knoten repräsentiert (z.b. DataObject3), die auch enthaltene Datensätze darstellen können (z.b. DataObject1). Falls Metriken auf Tupelebene dargestellt werden sollen, muss die Anzeige von Datensätzen an einer Relation aktiviert sein. Dann können TupleMetrics an jedem Datensatz angezeigt werden, wie ein zusätzliches berechnetes Attribut. Bei Auswahl eines bestimmten Datensatzes können auch auf die einzelnen Attribute bezogenen Metriken dargestellt werden (Attribute Metrics). Metriken auf Relationenebene können unter dem Namen des entsprechenden Datenbankobjekts jeweils in einer eigenen Zeile dargestellt werden. Metriken auf Datenbankebene sowie Metriken auf Systemebene sind im Knoten Global Metrics, der mit den restlichen Knoten durch keine Kante verbunden ist, zu finden. Die Darstellung von Datenbank- und Systemmetriken verläuft analog zur Darstellung von Metriken auf der Relationenebene jeweils in einer eigenen Zeile des Knotens. Die Zugehörigkeit der Datenbankobjekte zu einer Schicht des DWH wird im DFG durch eine Gruppierung zum Ausdruck gebracht. Metriken auf Relationenebene können analog zur Aggregation auf die Datenbankebene unter dem Aspekt aggregiert werden, dass nur Datenbankobjekte einer bestimmten Schicht zur Berechnung herangezogen werden. Die resultierenden Kennzahlen können im DWHLayer dargestellt werden (vgl. Abbildung 3.7). Falls der Vergleich mehrerer Kennzahlen gewünscht ist, können die Metriken auch in einer Tabelle aufgeführt werden. Die Kanten im DFG stellen die Input- / Output-Beziehung zwischen Datenbankobjekten und Prozessen dar und verlaufen in Richtung des Datenflusses. Prozesse werden durch dreieckige Knoten repräsentiert (z.b. P2) und zeigen mit ihrer Dreiecksspitze in Richtung 45

60 3 Entwicklung des Konzepts Abbildung 3.6: Grundstruktur des Datenflussgraphen 46

61 3.6 Datenflussanalyse und Datenflussgraph Abbildung 3.7: Aggregierte DWH-Schicht 47

62 3 Entwicklung des Konzepts des Outputs. Prozessmetriken können an der Inputkante des Prozessdreiecks dargestellt werden. Jede Metrik wird in einer eigenen Zeile gelistet. Use Cases und Rollen sind Knoten außerhalb einer Schicht. Use Cases werden durch Blätter repräsentiert, die über eingehende Kanten mit den Prozessen verbunden sind, die ihnen die nötigen Daten liefern und über ausgehende Kanten mit den interessierten Rollen verbunden sind. Rollen stellen den Endpunkt des Datenflusses im Graphen dar und verfügen nur über eingehende Kanten aus den relevanten Use Cases. Quellsysteme können grundsätzlich wie Datenbankobjekte behandelt werden und werden deshalb durch eigene Knoten repräsentiert. Diese Knoten können beispielsweise je nach Art der Quelle in ihrer symbolischen Darstellung variieren. Der Übergang von Quellsystem zum Datenbankobjekt geschieht über einen Prozess. Benutzerinteraktion Die Anzahl darzustellender DFG-Elemente kann insbesondere bei großen DWHs derartige Größenordnungen erreichen, dass eine Darstellung des vollständigen DFG in seiner feingranularen Grundstruktur auf einer Bildschirmgröße nur unter extremer Verkleinerung der grafischen Elemente möglich wäre. So besteht der Bedarf nach Darstellungsformen, die die angezeigte Menge an Informationen reduzieren. Eine Möglichkeit besteht darin, die minimal angezeigte Aggregationsebene im Vergleich zur Grundform zu erhöhen (bzw. die Granularität zu verringern). Dieser Vorgang, bei dem nicht durch Verkleinerung der grafischen Bildelemente, sondern vielmehr durch Aggregation einfacher Elemente in zusammengesetzte Elemente aus einem Bild herausgezoomt wird, wird als semantischer Zoom bezeichnet. Weaver beschreibt den semantischen Zoom als eine Form von details on demand 2, bei der der Benutzer durch Herein- und Herauszoomen unterschiedliche Detailmengen sehen kann [Wea04]. [SVTS05] zeigt eine mögliche Darstellungsform für ETL-Graphen auf verschiedenen Ebenen. Die hier vorgestellte Grundstruktur entspricht der Schemaebene in [SVTS05]. Ein weiteres Instrument zur Beherrschung der Informationsflut besteht in der Nutzung von Filtern [YaKSJ07]. So sollte es möglich sein, bestimmte Elemente des DFG anhand von Filterkriterien hervorzuheben bzw. auszublenden. Denkbare Szenarien bestehen bspw. in der Filterung der angezeigten Objekte nach denjenigen Objekten, die bestimmten Qualitätskriterien nicht genügen oder in der Markierung des kritischen Pfades im Sinne der Prozessdauer. Auswirkungsanalyse Abbildung 3.8 zeigt eine mögliche Darstellung für eine Auswirkungsanalyse am DFG. Ausgangspunkt für die Analyse ist DataObject8, welches durch eine grüne Umrandung markiert ist. Alle Knoten und Kanten, die keine Nachfolger von DataObject8 sind, sind kontrastarm eingefärbt, um eine schnelle Unterscheidung von den relevanten Elementen des Graphen zu gewährleisten. So kann bspw. aus dieser Ansicht abgelesen werden, dass 2 etwa Details auf Abruf, also die aktive Anforderung eines höheren Detailgrades durch den Nutzer 48

63 3.6 Datenflussanalyse und Datenflussgraph Daten aus DataObject8 nur in UseCase2 verwendet werden und im Falle von Problemen mit der Datenqualität Role2 benachrichtigt werden muss. Abstammungsanalyse Abbildung 3.9 zeigt ein Szenario für eine Abstammungsanalyse am DFG. DataObject4 bildet den Ausgangspunkt für diese Analyse und ist durch eine blaue Umrandung gekennzeichnet. Alle Knoten und Kanten, die keine Vorgänger von DataObejct4 sind, sind wie der Auswirkungsanalyse blass eingefärbt, um die schnelle Unterscheidung von den relevanten Elementen des Graphen zu gewährleisten. Aus solch einer Ansicht kann bspw. abgelesen werden, dass die Daten in DataObject4 aus den Quellen DataObject6 und Data- Object7 stammen und diese Daten in DWHLayer1, respektive DataObject1 und DataObject2 zwischengespeichert wurden. Kritischer Pfad Abbildung 3.10 zeigt eine mögliche Darstellung für die Analyse des kritischen Pfades eines Anwendungsfalls. Es wird derjenige Pfad vom Ausgangsobjekt zu den Datenquellen visualisiert, bei dem die Menge von Prozessen mit maximaler Gesamtdauer traversiert wird. Das Ausgangsobjekt sowie alle auf dem Pfad befindlichen Elemente des Graphen werden rot markiert. Nicht relevante Objekte werden auch bei dieser Analyse kontrastarm eingefärbt, um die Elemente auf dem kritischen Pfad hervorzuheben. Die Berechnung und Darstellung des kritischen Pfades bezüglich der Prozessdauer ist jedoch nur ein Beispiel, da grundsätzlich auch andere Prozessmetriken mit einer geeigneten Aggregation verwendet werden können. So ist bspw. ein kritischer Pfad im Sinne des minimalen Datendurchsatzes vorstellbar. 49

64 3 Entwicklung des Konzepts Abbildung 3.8: Beispielhafte Darstellung einer Auswirkungsanalyse. Das Ausgangsobjekt (DataObject8) ist grün umrandet. 50

65 3.6 Datenflussanalyse und Datenflussgraph Abbildung 3.9: Beispielhafte Darstellung einer Abstammungsanalyse. Das Ausgangsobjekt (DataObject4) ist blau umrandet. 51

66 3 Entwicklung des Konzepts Abbildung 3.10: Beispielhafte Darstellung des kritischen Pfads zu einem Use Case. Das Ausgangsobjekt (UseCase1) ist rot umrandet. 52

67 4 Fallstudie Der Kennzahlenkatalog sowie das Konzept zum Datenflussgraphen wurden in einer Fallstudie prototypisch implementiert. Dazu wird der Systemkontext beim Praxispartner beschrieben, die konkreten Stakeholder ermittelt und ihre Anforderungen analysiert. Der Abschnitt Anwendung des Konzepts beschreibt, welche Maßnahmen zur Deckung des Informationsbedarfs der Stakeholder umgesetzt werden und wie die Informationen dargestellt werden. Eine Evaluation durch Experten des Praxispartners validiert den Prototyp für die Fallstudie. 4.1 Systemkontext Projekt Die Fallstudie ist in einem Projekt der iteratec GmbH einzuordnen, das die Weiterentwicklung der Softwarelösung eines Carsharing-Dienstes für einen deutschen Automobilhersteller zum Ziel hat. Das in diesem Kontext entwickelte Data Warehouse soll um ein Monitoring-Cockpit zum Zwecke des Datenmanagements ergänzt werden. Eine Datenbank mit einem momentanen Datenvolumen der Größenordnung eines Terabyte sowie die Erwartung, dass die Datenmenge in Zukunft aufgrund von größerer Servicebeliebtheit und Expansion noch schneller wachsen wird, verpflichten zum systematischen Datenmanagement. Das DWH dient der Historisierung der Daten aus den operativen Systemen und vor allem der Aufbereitung für die Analyse der technischen Fahrzeugdaten sowie der Integration von Daten aus verschiedenen Quellen. So werden die aufbereiteten Daten wesentlich zur qualitativen Verbesserung der eingesetzten Soft- und Hardware und auch zur Unterstützung und Optimierung der Supportprozesse genutzt. Durch diese konsequente Datenanalyse soll gerade im noch jungen Bereich des Carsharing das Gesamtangebot für den Nutzer des Carsharing Systems fortlaufend verbessert werden Architektur und Werkzeuge Das Data Warehouse ist in einer Oracle 11g Datenbank implementiert und folgt der klassischen Schichtenarchitektur (vgl. Abschnitt 2.1.1). Die Daten werden bei der Extraktion in den Arbeitsbereich (Staging Area) geladen, von dem aus die nötigen Transformationen durchgeführt werden. Die Spezifikation der ETL-Prozesse liegt in SQL vor und wurde ohne Unterstützung dedizierter Werkzeuge für die Erstellung von ETL-Workflows geschrieben. Die Haltung der integrierten Daten geschieht in der Catalog-Schicht. Zur Implementierung des Monitoring-Cockpits wird die In-Memory-Datenbank QlikView (QV) gewählt, 53

68 4 Fallstudie die auch die Aufgaben der Präsentationsschicht übernimmt und das Data Discovery Bedienkonzept durch hohe Interaktivität unterstützt. Der QV-Entwickler stellt Dashboards zusammen, die den Anwendern über geeignete Steuerelemente und Visualisierungen die Daten zur Verfügung stellen. Über ein Ladeskript können Datenquellen sowie Transformationen definiert werden, um das QV-interne Datenmodell zu spezifizieren. Auf diese Weise werden Data Marts modelliert und die entsprechende Schicht in den Speicher von QlikView ausgelagert. Die Interaktivität wird bspw. durch Filter ermöglicht, die aufgrund der Datenhaltung im Arbeitsspeicher vergleichsweise kurze Reaktionszeiten gewährleisten sollen. Abbildung 4.1 zeigt einen Überblick über die Architektur in der Fallstudie. Abbildung 4.1: Architekturskizze in der Fallstudie Spezifische Anforderungen Die in ITIL und DMBOK spezifizierten Rollen für Servicemanagement und Datenmanagement decken sich mit den im Projekt vorhandenen Rollen. Zur Erhebung der projektspezifischen Anforderungen werden zunächst die konkreten Stakeholder (vgl. [MBEH09]) für eine Monitoring-Anwendung identifiziert: Datenbankadministrator Data Integration Specialist 54

69 4.2 Anwendung des Konzepts Diese Rollen verfolgen (vgl. Abschnitt 3.3.1) die operativen Ziele zur Sicherung von Integrität (DOM-1), Verfügbarkeit (DOM-2) und Performance (DOM-3) sowie die Bereitstellung einer für effektive und effiziente Geschäftsanalysen geeigneten DWH (DW-BIM-2). Damit kommen gemäß der in Kapitel 3 entwickelten Methode, insbesondere der Zuordnung von Zielen zu Metriken (vgl. Tabelle 3.3) für die Implementierung grundsätzlich die Metriken M-1 bis M-9 sowie die Metriken M-14 bis M-18 infrage. 4.2 Anwendung des Konzepts Kennzahlen und Visualisierung Aus den Kennzahlen, die aufgrund der ermittelten Stakeholder und deren Ziele als geeignet befunden wurden, wird eine Auswahl getroffen, die in einer ersten Iteration in einem Prototyp implementiert wird. Unter Berücksichtigung der Prioritäten der Stakeholder sowie der momentanen Datenverfügbarkeit im DWH werden folgende Kennzahlen exemplarisch als Proof of Concept umgesetzt (die Einheit wird in eckigen Klammern angegeben): M-4 Mean Time Between Failures bzw. Anzahl Fehler Auf Wunsch der Stakeholder kommt anstelle einer Darstellung der MTBF eine Darstellung der Fehlerhäufigkeiten pro Tag zum Einsatz. Dazu wird eine Tabelle sowie ein Boxplot mit Statistiken zu den Häufigkeiten pro Tag eingesetzt. Bei den Darstellungen wird nach Fehlerstatus unterschieden. In einem Blasendiagramm wird zusätzlich, über die Dimensionen Fehlerstatus und Objektname die Anzahl der Fehler angezeigt, um die Fehleranalyse zu vereinfachen. M-9 Ressourcenauslastung: Persistenter Speicher [Prozent, GiB] Die anteilige Speicherauslastung wird als Kuchendiagramm visualisiert. Die historische Speicherauslastung wird mithilfe eines Liniendiagramms dargestellt. Ein Balkendiagramm zeigt diejenigen zehn Datenbankobjekte geordnet an, die den meisten Speicher belegen. Die Diagramme werden als Small Multiples realisiert, wobei eine Unterscheidung nach Tablespace stattfindet. Eine zusätzliche Tabelle, erlaubt die zügige Informationsgewinnung über die persistente Größe auf detaillierter Ebene. M-14 ETL-Dauer [Stunden:Minuten:Sekunden] Ein Liniendiagramm visualisiert die Entwicklung der Dauer von ETL-Prozessen über die Zeit und stellt auch den Verlauf von Teilprozessen grafisch dar. Statistiken zur Dauer einzelner Steps werden in einem Boxplot darstellt, wobei eine absteigende Sortierung nach nach Dauer verwendet wird. M-15 ETL-Zeilendurchsatz [Zeilen pro Sekunde] Ein Balkendiagramm visualisiert den Durchsatz einzelner ETL-Steps anhand des Objekts, das als Output für den entsprechenden Prozessschritt diente. Die Darstellung ist nach Durchsatz absteigend geordnet. 55

70 4 Fallstudie Datenmodell Das assoziative [qli14] Datenmodell ordnet gleichnamige Attribute einander zu und soll damit intuitive Analysen ermöglichen. QlikView bietet eine spezielle Ansicht, die das geladene Datenmodell visualisiert (Data Mart Ansicht). Abbildung 4.2 zeigt das Datenmodell für den Prototyp. Abbildung 4.2: Datenmodell in QlikView Dashboards Die Abbildungen 4.3 und 4.4 zeigen die beiden Dashboards zu Speicherauslastung und ETL-Analyse. Auf der linken Seite eines jeden Dashboards befinden sich Steuerelemente, die die Filterung der angezeigten Daten ermöglichen. 56

71 4.2 Anwendung des Konzepts Abbildung 4.3: Dashboard zur Analyse der Nutzung des persistenten Speichers 57