Friedrich-Schiller-Universität Jena Fakultät für Mathematik und Informatik Institut für Informatik Prof. Dr. Klaus Küspert, Dipl.-Math. Katharina Büchse Seminararbeit zum Thema Referenzarchitektur von Data-Warehouse-Systemen Eingereicht: Mario Jandeck Matr.Nr.: 122122 Abgabedatum: 16.12.2011
I Inhalt Inhalt... I Abbildungsverzeichnis... II Tabellenverzeichnis... II Abkürzungsverzeichnis... III 1. Einführung... 1 2. Notwendigkeit einer Referenzarchitektur... 2 3. Komponenten des Data-Warehouse-Systems... 3 3.1. Grundaufbau... 3 3.2. Der Data-Warehouse-Manager... 4 3.3. Komponenten des Datenbeschaffungsbereich... 5 3.4. Komponenten des Auswertungsbereiches... 7 3.5. Metadatenmanager und Repositorium... 9 4. Datenquellen... 11 4.1. Datenbeschaffung... 11 4.2. Datenqualität... 11 5. Analyse im Data-Warehouse... 13 6. Fazit... 14 Quellenverzeichnis... IV
II Abbildungsverzeichnis Abb. 1 Referenzarchitektur für ein Data-Warehouse-System... 3 Abb. 2 Nabe-Speiche-Architektur mit Basisdatenbank... 8 Abb. 3 Taxonomie von Datenqualitätsmerkmalen nach [Hinr02]... 12 Abb. 4 Zusammenhang zwischen Anwenderzahl und zunehmender Komplexität.... 13 Tabellenverzeichnis Tabelle 1: Extraktion in Abhängigkeit von der Monitoring-Strategie... 6 Tabelle 2: Voraussetzungen der Datenbeschaffung und Klassifikation... 11
III Abkürzungsverzeichnis API BIT DBMS ETL ODBC OLAP Application Programming Interface Business Intelligence Tools Datenbankmanagementsystem Extract Transform Load Open Database Connectivity Online Analytical Processing
1 1. Einführung Betrachtet man die Architektur eines komplexen Systems, so sollte man sich zunächst klar darüber werden, was genau unter Architektur in diesem Kontext zu verstehen ist. Im klassischen Sinne beschreibt eine Architektur den Aufbau und die Struktur von Gegenständen oder Gebäuden. Dabei muss die Struktur nach [Ency87] die geforderten Anforderungen erfüllen, möglichst robust gegen Änderungen sein, sowie eine gewisse Ästhetik aufweisen. Weiterhin kann davon ausgegangen werden, dass eine Struktur durch ein Zusammenspiel ihrer statischen Elemente geprägt ist. Genau diese Aspekte lassen sich auch auf ein Data-Warehouse-System übertragen. Betrachtet man dieses im Ganzen, so sieht man ein komplexes Gebilde, welches Daten verarbeitet und analysiert. Im Detail sorgen jedoch verschiedenste Komponenten und Steuermechanismen, welche sinnvoll miteinander verknüpft sind, für diese umfassende Funktionalität. Da für ein Data-Warehouse-System nicht nur eine Architektur existiert, sondern vielfältige Möglichkeiten bestehen, ein solches aufzubauen, soll eine idealtypische Referenzarchitektur vorgestellt werden. Dabei wird im Kapitel zwei zunächst die Notwendigkeit dieser dargelegt. Im darauf folgenden Kapitel werden dann die einzelnen Komponenten der Referenzarchitektur vorgestellt und deren Aufgabe und Funktionsweise beschrieben. Hierbei wird, ausgehend vom allgemeinen Grundaufbau (Kap. 3.1), zunächst näher auf den Data-Warehouse-Manager (Kap. 3.2) eigegangen, worauf im Anschluss die Erläuterung zu den Komponenten des Datenbeschaffungsbereiches (Kap. 3.3) und des Auswertungsbereiches (Kap. 3.4) folgt. Nachdem auf diese Weise ein grundlegendes Verständnis über die Funktionen und das Zusammenwirken der Komponenten geschaffen wurde, wird sich der Fokus auf die Betrachtung der Datenbeschaffung und auf die Qualität (Kap. 4) der Daten richten. Schlussendlich soll in dieser Arbeit noch auf die eigentliche Analyse (Kap. 5) im Data-Warehouse eigegangen werden. Alle Aussagen, die dabei in dieser Arbeit getroffen werden, basieren auf der Quelle [BaGu04] (Seite 3 bis 71). Inhalte die aus anderen Quellen stammen, werden dabei gesondert ausgewiesen.
2 2. Notwendigkeit einer Referenzarchitektur Eine Referenzarchitektur beschreibt nicht nur den Aufbau eines Data-Warehouse- Systems, sondernd dient gleichermaßen auch als Kommunikationsmittel. Die Zerlegung dieses monolithischen Gebildes in seine statischen Bestandteile und dynamischen Informationsflüsse sorgt dann wiederum für ein besseres Verständnis. Bezogen auf den Einsatz in der Praxis werden dann der Aufbau und die Wartbarkeit eines Systems erheblich erleichtert. Dabei wird gefordert, dass die Referenzarchitektur die mögliche Realität korrekt wiedergeben muss. Natürlich wird nie alles, was hier beschrieben wird, in der Praxis umgesetzt, vielmehr beabsichtigt die Referenzarchitektur, ein objektiver Ausgangspunkt zu sein, um bestehende Systeme zu vergleichen und um Empfehlungen für geplante Data-Warehouse-Systeme geben zu können. Im Detail ist sie zweckdienlich, um Vergleiche zwischen den Werkzeugen für das Data- Warehousing aufzuzeigen, oder aber auch um Stärken und Schwächen einer bestehenden Implementierung zu demonstrieren. Zudem sorgt die Zerlegung in Komponenten für eine bessere Übersicht und dient so der Komplexitätsverringerung einer bestehenden Implementierung. Folglich müssen gewisse Anforderung an die Referenzarchitektur gestellt werden, damit sie ihrem Zweck gerecht wird. Im Allgemeinen muss sie idealtypisch und primär funktionsorientiert entworfen sein. Dies bedeutet, dass für die notwendigen Funktionen der Datenfluss abgebildet wird. Ebenso wird auch der für die Prozesssteuerung notwendige Kontrollfluss dargestellt. Dabei ist zu beachten, dass zwischen diesen Flüssen nur eine Beziehung welche sich aus dem Sachverhalt ergibt besteht, jedoch keine Abhängigkeit.
3 3. Komponenten des Data-Warehouse-Systems 3.1. Grundaufbau In Abb. 1 ist der gesamte Aufbau der Referenzarchitektur mit allen Komponenten sowie dem Daten- und Kontrollfluss ersichtlich, wobei die durchgehenden Linien den Daten- und die gestrichelten Linien den Kontrollfluss darstellen. Im Folgenden soll kurz Abb. 1 Referenzarchitektur für ein Data-Warehouse-System der Weg der Daten sowie das Wirken der einzelnen Komponenten beschrieben werden. Die Daten werden zunächst durch die Extraktionskomponente extrahiert und in den Arbeitsbereich geladen. Hier werden die Daten transformiert, um sie anschließend dauerhaft speichern zu können. Der Monitor überwacht und unterstützt dabei die Auswahl der relevanten Daten. Dieser Vorgang wird auch als Datenbeschaffungsprozess bezeichnet und die beteiligten Komponenten werden dem Datenbeschaffungsbereich zugeordnet. Durch die Ladekomponente werden die transformierten Daten in eine Basisdatenbank geladen, welche die Daten dauerhaft vorhält. Das eigentliche Data-Warehouse lädt dann die zur Analyse benötigten Daten aus der Basisdatenbank. Die Analysekomponente, welche durch den jeweiligen Analysezweck bestimmt ist, bildet am Ende die Schnittstelle zum Anwender. Die Komponenten zur Analyse werden im Auswertungsbereich zusammengefasst.
4 Das Repositorium enthält alle Informationen über das Data-Warehouse in Form von Metadaten und wird ausschließlich durch den Metadatenmanager bestückt und verwaltet. Der Data-Warehouse-Manager steuert letztendlich über die Kontrollflüsse alle ablaufenden Prozesse und sorgt so für eine weitestgehende Automatisierung. 3.2. Der Data-Warehouse-Manager Der Data-Warehouse-Manger ist die zentrale Komponente der Referenzarchitektur und ist für die Initiierung, Steuerung und Überwachung der einzelnen Prozesse, vom Laden der Daten bis hin zur Analyse, verantwortlich, wobei die wichtigste Aufgabe in der Initiierung des Datenbeschaffungsprozesses besteht. Der Datenbeschaffungsprozess kann dabei auf verschiedene Art und Weise ausgelöst werden. Am häufigsten geschieht die Initiierung in regelmäßigen Zeitintervallen. Beispielsweise können monatlich die aktuellen Umsatzzahlen geladen werden. Eine andere Variante ist die Auslösung des Prozesses bei Datenänderung in den Quelldaten, welche vom Monitor entdeckt werden können. Die letzte Möglichkeit der Initiierung besteht im explizierten Anfordern des Anwenders. Das Laden der Daten erfolgt dabei meist nicht nur aus einer bestimmten Quelle, vielmehr handelt es sich oftmals um viele verschiedene und auch verteilte Datenquellen. In diesem Fall ist der Data-Warehouse-Manager für die Koordination dieser Systeme zuständig, wobei meist eine sequentielle Abarbeitung der Datenquellen erfolgt. Wenn es sich jedoch um Quellen handelt, die keinen Bezug und keine Abhängigkeit zueinander aufweisen, wird eine parallele Abarbeitung in jedem Fall bevorzugt. Das Vorgehen setzt sich auch bei der weiteren Verarbeitung der Daten fort. So kann auch die Transformation je nach Fall sequentiell oder parallel erfolgen. Nach der Datenbeschaffung sorgt der Data-Warehouse-Manager dafür, dass alle weiteren Prozesse, wie das Laden der Daten in die jeweiligen Datenbanken oder der Analyseprozess, korrekt und in der richtigen Reihenfolge ausgeführt werden. Treten Fehler während der Ausführung der einzelnen Prozesse auf, so werden diese zentral vom Data-Warehouse-Manager dokumentiert und dem Administrator bereitgestellt. Zudem besteht auch die Möglichkeit, dass Wiederanlaufmechanismen angeboten werden. Zur Realisierung dieser umfassenden Steuerung kommuniziert der Data-Warehouse-
5 Manager stets über den Metadatenmanager mit dem Repositorium, wobei er gleichzeitig die Schnittstelle aller Komponenten zum Repositorium hin bildet. 3.3. Komponenten des Datenbeschaffungsbereich Die Komponenten des Datenbeschaffungsbereiches sind funktional zwischen den Datenquellen und der Basisdatenbank des Data-Warehouse-System angesiedelt. Monitor Wie genau ein Monitor funktioniert, hängt von der jeweiligen Datenquelle ab. Aus diesem Grund existiert meist ein Monitor pro Datenquelle. Die Hauptaufgabe des Monitors besteht darin, Datenänderungen in der Datenquelle auszumachen und die Basisdatenbank stets aktuell zu halten. Um diese Funktionalität zu gewährleisten existieren verschiedene Monitoring Strategien: triggerbasierte Strategie: Jede Datenmanipulation löst einen Trigger aus, welcher dann das geänderte Tupel beispielsweise in einer Datei oder einer anderen Datenstruktur ablegt. replikationsbasierte Strategie: Die geänderten Daten werden anhand der Differenz zweier Replikate identifiziert und in eine neue Tabelle geschrieben. zeitstempelbasierte Strategie: Die Datensätze erhalten bei jeder Datenmanipulation einen Zeitstempel. logbasierte Strategie: Alle Transaktionen werden in einer Log-Datei festgehalten, deren Analyse geänderte Datensätze aufzeigt. snapshotbasierte Strategie: Es werden vom gesamten Datensatz Snapshots erstellt. Durch einen Vergleich der verschieden Snapshots können dann die Änderungen identifiziert werden. Die ersten vier Strategien können mit allen gängigen Datenbankmanagementsystemen (DBMS) standardmäßig umgesetzt werden, da die DBMS die nötigen Funktionen bereitstellen. Die snapshotbasierte Strategie stellt eine Ausnahme dar. Sie sollte nur dann zum Einsatz kommen wenn es keine andere Möglichkeit gibt geänderte Datensätze zu identifizieren. Welches dieser Verfahren letztendlich zum Einsatz kommt, hängt immer von den Gegebenheiten der Quelldaten und den Möglichkeiten die das DBMS bietet, ab.
6 Arbeitsbereich Der Arbeitsbereich ist die zentrale Datenhaltungskomponente des Datenbeschaffungsbereichs. In diesem Bereich werden die meist heterogenen Daten der verschiedenen Quellen temporär zwischengespeichert. Hier werden dann diese Daten aufgearbeitet und transformiert, um sie anschließend in die Basis-Datenbank laden zu können. Wie in Abb. 1 zu sehen ist, wird so gewährleistet, dass die Daten ohne Einfluss auf die Quellen oder auf die Basisdatenbank bearbeitet werden können. ETL-Komponenten Als ETL-Komponenten werden die Komponenten bezeichnet, die eine direkte Verbindung zum Arbeitsbereich haben. ETL steht dabei für Extraktion, Transformation und Laden. Die Extraktionskomponente ist für die Übertragung der Daten aus den Datenquellen in den Arbeitsbereich verantwortlich. Die Implementierung dieser Komponente ist dabei abhängig von der eingesetzten Monitoring-Strategie. In der Tabelle 1 wird ein kurzer Überblick über den Zusammenhang zwischen Monitoring-Strategie und Extraktionskomponente gegeben. Monitoring-Strategie Trigger-basiert Replikationsbasiert Zeitstempel-basiert Log-basiert Snapshot-basiert Extraktions-Prozess Geänderte Datensätze werden aus einer Datei gelesen. Selektion via SQL aus der Replikationstabelle. Selektion anhand des Zeitstempels. Selektion anhand der Analyse der Log-Dateien. Selektion anhand des Snapshot Vergleiches. Tabelle 1: Extraktion in Abhängigkeit von der Monitoring-Strategie Die Entscheidung, wann eine Extraktion durchgeführt werden soll, ist stark abhängig von den zu extrahierenden Daten. So werden beispielsweise Umsatzzahlen bestimmter Bereiche periodisch extrahiert, wohingegen die Extraktion spezifischer Daten nur auf Anfrage geschieht. Weiterhin ist auch eine ereignisgesteuerte Extraktion oder auch eine sofortige Extraktion bei Datenänderungen denkbar. Die technische Umsetzung erfolgt dabei über Gateways und Standard-Datenbankschnittstellen, wie etwa der Open Database Connectivity (ODBC).
7 Die Aufgabe der Transformationskomponente besteht darin, die extrahierten Daten in ein einheitliches Format zu bringen. Dies betrifft zum einen strukturelle und zum anderen inhaltliche Aspekte. Geht es um strukturelle Anpassungen, so spricht man auch von Datenmigration, welche beispielsweise die Schemaintegration betrifft. Typische Transformationen sind hier die Anpassung von Datentypen, Vereinheitlichung von Zeichenketten und Datumsangaben oder aber auch die Kombination bzw. Separierung von Attributwerten. Bei der inhaltlichen Anpassung spricht man von Datenbereinigung. Hierbei geht es darum, fehlerhafte, redundante oder veraltete Datensätze zu beseitigen bzw. zu korrigieren. Nach der Extrahierung und Transformation der Daten müssen die aufbereiteten Daten in die Basisdatenbank geladen werden. Hierfür ist die Ladekomponente zuständig. Realisiert wird dieses Laden typischerweise über das Ladewerkzeug des jeweils zu Grunde liegenden Datenbankmanagementsystems (DBMS). In der Referenzarchitektur sind zwei Ladekomponenten enthalten, wobei die des Datenbeschaffungsbereiches analyseunabhängige Daten in die Basisdatenbank lädt und die des Auswertungsbereiches analyseabhängige Daten aus der Basisdatenbank in das Data-Warehouse lädt. 3.4. Komponenten des Auswertungsbereiches Basisdatenbank Die Basisdatenbank ist die integrierte Datenbasis für die spätere Analyse und gewährleistet eine flexible Mehrfachverwendung der Daten. Sie ist dadurch charakterisiert, dass eine integrierte View vorliegt, was bedeutet, dass sowohl die Schemata der Datenquellen, wie auch die Daten an sich, integriert sind. Weiterhin umfasst sie nicht nur den aktuellen Datenbestand, sondern hält auch historische Daten vor, wobei Detaildaten in der niedrigsten geforderten Granularität vorhanden sind. Die Modellierung der Basisdatenbank ist noch nicht auf Analysen ausgelegt, dazu werden die Daten von ihr zu definierten Zeitpunkten in die Data-Warehouse Komponente übertragen. Die Basisdatenbank kann also als logisch zentrales Datenlager gesehen werden, welches in seiner Verteilungsfunktion alle Data-Warehouses mit Daten zu versorgen hat. Diese Sammel- und Distributionsfunktion lässt sich gut in der Nabe-Speiche-Architektur visualisieren, wie in Abb. 2 ersichtlich wird. Hierbei können die Datenquellen und Data- Warehouses als Speichen und die Basisdatenbank als Nabe angesehen werden. Dies
8 reduziert die Anzahl der Schnittstellen auf eine zentrale Stelle. In der Praxis wird jedoch oft auf die Verwendung einer Basisdatenbank verzichtet, da deren Aufbau und Pflege aufwändig und teuer werden können. Die Vorteile der Basisdatenbank sind allerdings nicht von der Hand zu weisen, so dass sie in der Referenzarchitektur vorgesehen ist. Abb. 2 Nabe-Speiche-Architektur mit Basisdatenbank Data-Warehouse 1 Das Data-Warehouse ist die zugrunde liegende Datenbank für Analysezwecke. An dieser Stelle soll angemerkt werden, dass in einem gewissen Umfang bereits auf der Basisdatenbank Analysen durchgeführt werden können, womit das Data-Warehouse umgangen wird. In diesem Fall besitzt die Basisdatenbank dann auch eine Auswertungsfunktion. Die Hauptaufgabe des Data-Warehouses besteht darin, die Daten, welche die Anwender zur Analyse benötigen, dauerhaft zu verwalten und dem Analyseprozess in geeigneter Form zur Verfügung zu stellen. So richtet sich die Modellierung der Daten im Data-Warehouse ausschließlich nach den Analysebedürfnissen des Anwenders. Daraus ergibt sich gleichzeitig die Hauptproblematik im Design eines geeigneten logischen Schemas. Zur technischen Umsetzungen kommen meist Datenbankmanagementsysteme zum Einsatz, da man sich so deren Eigenschaften wie Mehrbenutzerbetrieb, Wiederanlauffähigkeit, Datenneutralität und Datenunabhängigkeit zu nutzen macht. Eine weitere Problematik besteht in der Aktualisierung der Daten. Da oftmals große Datenmengen aus der Basisdatenbank in das Data-Warehouses geladen werden müssen, reichen die herkömmlichen Schnittstellen des DBMS nicht aus. Um möglichst viele Datensätze pro Zeiteinheit in das Data-Warehouse einzubringen, kommen so genannte Massenlader zum Einsatz. Diese erreichen eine höhere Geschwindigkeit durch das Deaktivieren von Funktionen, wie etwa die Konsistenzprüfung oder das Erstellen von Transaktions-Logs, für die Dauer des Lade-Prozesses.
9 Aus der Aufgabe heraus, Daten zu verwalten und bereitzustellen, ergibt sich die Problematik, dass die Daten oft nicht in der Form zur Analyse verwendet werden können, wie sie im Data-Warehouse vorliegen. Vielmehr ist es erforderlich, dass die Daten auf unterschiedliche, komplexe Art und Weise weiterverarbeitet werden (z.b. die Bildung von Mittelwert oder Varianz). Das Problem ist dabei eine Frage der Architektur, ob die Verarbeitungsschritte nur auf der Analyseebene oder bereits im Data-Warehouse vorgenommen werden sollen. Für die Referenzarchitektur gilt, dass Berechnungen auch im Data-Warehouse selbst möglich sind. Des Weiteren soll angemerkt werden, dass die Data-Warehouse Komponente im Modell nicht zwingend nur ein Data-Warehouse verkörpert. Das Ziel ist zwar eine anwendungsbezogene, logische Integration der Datenbestände des Unternehmens, was aber nicht eine physische Integration des Datenbestandes bedeuten muss. Vielmehr ist es oftmals für verschiedene Teile des Unternehmens sinnvoll, voneinander getrennte Data-Warehouses zu betreiben, um so den gesamten Datenbestand aufzuteilen. Dies kann beispielsweise aus Gründen der Performance oder des Datenschutzes erfolgen. In diesem Zusammenhang spricht man auch von Data-Marts. Ein Data-Mart ist im Grunde nichts anderes als ein Data-Warehouse. Der Begriff des Data-Marts wurde vielmehr durch verschieden Marketingabteilungen großer Hersteller geprägt, weswegen eine Abgrenzung für die Referenzarchitektur keine Rolle spielt. 3.5. Metadatenmanager und Repositorium Das Repositorium des Data-Warehouse beinhaltet sämtliche Informationen über Aufbau und Struktur des Data-Warehouse, der Datenquellen und aller Inhalte. Diese Informationen werden als Metadaten bezeichnet. Beschreibende Metadaten enthalten dabei Informationen über Inhalt, Struktur, Kontext und Bedeutung der Daten, wohingegen die prozessbezogenen Metadaten Informationen über die Verarbeitung der Daten enthalten. Bezugnehmend auf den Hauptnutzen von Metadaten wird zwischen fachlichen und technischen Metadaten unterschieden. Fachlichen Metadaten sind: anwendungsspezifische Dokumentationen über Anfragen und Berichte Fachbegriffe und Kontextinformationen Thesauri und domänenspezifisches Wissen
10 Diese Metadaten helfen in erster Linie dem Endanwender, die Daten zu verstehen und zu interpretieren, um Analyseanwendungen effektiver einzusetzen zu können. Zu den technischen Metadaten zählen beispielsweise: logische und physische Datenbankschemata sowie Integritätsbedingungen Implementierungsinformationen der verschiedenen Skripte für Extraktion, Transformation und Analyse der Daten Diese Metadaten sind in erster Linie für Administratoren und Softwareentwickler bestimmt und vereinfachen Wartung und Betrieb des Data-Warehouses. Der Metadatenmanager wird als Datenbankanwendung definiert, welche Integrations-, Zugriffs-, Anfrage- und Navigationsmöglichkeiten auf die Metadaten bietet, sowie ein Versions- und Konfigurationsmanagement ermöglicht. Der Großteil der Metadaten entsteht dabei in den Datenquellen, dem Arbeitsbereich, der Basisdatenbank sowie dem Data-Warehouse. Daraus ergibt sich eine Vielzahl von Lese- und Schreibzugriffen unterschiedlichster Werkzeuge von der Administration bis hin zu Analyse. Dies wiederum setzt eine leistungsfähige API für den Zugriff auf das Repositorium voraus, sowie ein Repositoriumsschema, welches den Zugriff bzw. die beinhalteten Daten des Repositoriums vereinheitlicht und ebenfalls vom Metadatenmanager verwaltet wird. Neben dem reinen Datenfluss ist in Abb. 1 auch ein Kontrollfluss zwischen Data- Warehouse-Manager, Metadatenmanager und Repositorium ersichtlich. Dieser Kontrollfluss ist im Zusammenhang mit metadatengesteuerten Prozessen und dem Einsatz metadatengesteuerter Werkzeuge von Bedeutung. Denn so können die Metadaten vom Metadaten Manager an den Data-Warehouse-Manager übergeben werden, welcher dann den Einsatz der Werkzeuge steuert und evtl. daraus neu entstandene Metadaten (z.b. Log-Dateien) wieder zurückliefert.
11 4. Datenquellen 4.1. Datenbeschaffung Für die Datenbeschaffung müssen verschiedene Voraussetzungen erfüllt sein, welche in organisatorische und technische Voraussetzungen unterteilt werden können. Im Allgemeinen geht es dabei um die Verfügbarkeit der Daten, wobei Verfügbarkeit nicht als Qualitätsmerkmal von Daten gesehen werden darf, da sie keine inhärente Eigenschaft dieser darstellt. Zusätzlich ist es zweckmäßig, die Quelldaten im Vorfeld zu klassifizieren. Dies dient einer besseren Strukturierung sowie einer gewissen Sensibilisierung für auftretende Probleme. In Tabelle 2 ist eine Zusammenstellung möglicher Voraussetzungen und Klassifikationen zu sehen, welche jedoch nicht in einem Zusammenhang stehen. Organisatorische Voraussetzungen der Datenbeschaffung Rechtlich zulässig Erhebung personenbezogener Daten oft kritisch Erlaubnis des Besitzers Vertraulichkeit von Daten Zeitliche Verfügbarkeit Aktualität Technische Voraussetzungen der Datenbeschaffung Rechner-, Netzverfügbarkeit Schutz vor unberechtigtem Zugriff Übertragungsgeschwindigkeit der Daten Tabelle 2: Voraussetzungen der Datenbeschaffung und Klassifikation 4.2. Datenqualität Klassifikationen Herkunft: intern oder extern Zeit: Aktualität der Daten Nutzungsebene: Primär- oder Metadaten Inhalt/Datentyp: Zahl, Grafik, Darstellung/Datentyp: numerisch, boolean, Zeichensatz: Sprache (westeuropäisch), Technisch(ASCII) Schreiborientierung: links nach rechts, bidirektional, Schutzwürdigkeit: vertraulich, geheim, Die Qualität der Daten ist von zentraler Bedeutung für das Data-Warhouse und kann entscheidend sein für das Bestehen oder Scheitern eines konkreten Data-Warehousing Projektes. Wenn man mangelhafte Daten in das Data-Warhouse lädt, erhält man auch nur minderwertige Analyseergebnisse. Typische Qualitätsmängel sind beispielsweise
12 inkorrekte, veraltete, ungenaue oder doppelt vorhandene Daten. Aus solchen Mängeln ergeben sich für das betreffende Unternehmen unter Umständen erhebliche Zusatzkosten. Das können beispielsweise die Kosten für eine nachträgliche Bereinigung sein. Aber auch Kosten, die aus einer Mitarbeiterunzufriedenheit und aus Fehleinschätzungen in Folge der Datenanalys entstehen, dürfen nicht unterschätzt werden. Aus diesen Gründen ist es von vornherein wichtig anhand von bestimmten Merkmalen eine Mindestqualität zu definieren, die die Daten erreichen müssen. Die Abb. 3 zeigt dabei eine mögliche, beispielhafte Einteilung üblicher Qualitätsmerkmale, an denen Qualität gemessen werden kann. Der Erfüllunggrad der Daten im Hinblick auf diese Merkmale entscheidet dann über die Qualität der Daten. Abb. 3 Taxonomie von Datenqualitätsmerkmalen nach [Hinr02]
13 5. Analyse im Data-Warehouse Nach [BaGu04] umfasst die Analyse im Data-Warehouse als Oberbegriff alle Operationen, die mit den Daten des Data-Warehouses durchgeführt werden. Daher soll in diesem Kapitel die Bedeutung der Analyse im Data-Warehouse näher betrachtet werden. Aber auch Darstellungsformen, Funktionalitäten und die Realisierung der Analyse sollen Eingang finden. Im Vordergrund steht die Anwendung von Analysefunktionen auf ausgewählte Daten, wie etwa komplexe statistische Untersuchungen des Data-Mining. Aus solchen Analysen entstehen wiederum neue Informationen, welche wiederum in das Data-Warehouse zurückgeführt werden können, um die Qualität zukünftiger Analysen zu verbessern. Diese Analysefunktionen werden dem Endanwender über Bussines-Intelligence-Tools (BIT) bereitgestellt, welche die verschiedensten Darstellungsformen anbieten und so ausschlaggebend für die Nutzerakzeptanz und Zufriedenheit sind. Bei den Darstellungsformen ist grundsätzlich zwischen Tabellen, Grafiken und multimedialen Inhalten zu unterscheiden. Die häufigste Verwendung finden dabei Tabellen, beispielsweise als Pivot-Tabelle. Sehr komplexe Inhalte können dagegen in Form von Grafiken visualisiert werden, da diese vom Menschen wesentlich besser verarbeitet werden können. Multimediale Inhalte, wie etwa Audio- oder Videodateien werden eher zur Ergänzung genutzt, um dem Anwender zusätzliche Informationen, beispielsweise in Form eines Produktvideos, bereitzustellen. Die Analyse bietet verschiedene Funktionen, welche nach Komplexitätsstufen unterteilt werden können. Die einfachste Stufe ist dabei der Data-Access. Die Funktionalität beschränkt sich hier auf die Berichtserstattung, bzw. auf das Lesen der Daten. Die nächste Stufe ist das Online Analytical Processing (OLAP), wobei eine interaktive Datenanalyse stattfindet deren Berichte quantitativ verdichtete Werte in multidimensionaler Sichtweise enthalten. Die komplexeste Stufe stellt das Data-Mining dar, wo man versucht Vorhersagen aus dem Datenbestand abzuleiten oder Assoziationsregeln aufzudecken. Wie letztendlich die Funktionalitäten realisiert werden ist stark abhängig von der Anwenderzahl und der Komplexität einer bestimmten Realisierung, wie in Abb. 4. ersichtlich Abb. 4 Zusammenhang zwischen Anwenderzahl und zunehmender Komplexität.
14 wird. So wird eine breite Anwenderzahl Standardberichte oder auch Berichtshefte nutzen, wohingegen nur wenige Mitarbeiter eine eigene Entwicklungsumgebung nutzen, um beispielsweise einen Algorithmus des Data-Mining zu implementieren. 6. Fazit Abschließend soll festgehalten werden, dass die Referenzarchitektur Möglichkeiten aufzeigt, ein Data-Warehouse aufzubauen und zu betreiben. Auch andere Publikationen wie etwa [Fark11] oder [MuBe98] verweisen auf die Referenzarchitektur von [BaGu04] und bauen darauf weiter auf. Das zeigt auch, dass diese Referenzarchitektur in der Literatur breite Anerkennung findet. Jedoch ist diese nur eine Empfehlung, die an einigen Stellen auch anders umgesetzt werden kann und kein verpflichtendes Konzept darstellt. Jede konkrete Implementierung eines Data-Warehouses hat seine Besonderheiten und erfordert im Detail auch oft eine Anpassung der Referenzarchitektur.
IV Quellenverzeichnis [BaGu04] [Hinr02] [MuBe98] [Fark11] Bauer, A., Günzel H. (Hrsg.): Data-Warehouse-Systeme: Architektur, Entwicklung, Anwendung, dpunkt.verlag, 2. Auflage, Heidelberg, 2004 Hinrichs, H.: Datenqualitätsmanagement in Data-Warehouse-Systemen. Dissertation, Carl-von-Ossietzky-Universität Oldenburg, http://docser ver.bis.uni-oldenburg.de/publikationen/dissertation/2002/hindat02/ hindat02.html, 2002 Mucksch, H.; Behme, W. (Hrsg.): Das Data-Warehouse-Konzept: Architektur Datenmodelle Anwendungen, 3. Auflage. Gabler, Wiesbaden, 1998 Farkisch, K. (Hrsg.): Data-Warehouse-Systeme kompakt, Aufbau, Architektur, Grundfunktionen, Springer Heidelberg Dordrecht London New York, 2011
V Eidesstattliche Erklärung Hiermit erkläre ich, dass ich die Seminararbeit ohne fremde Hilfe angefertigt und nur die erlaubten Hilfsmittel benutzt habe. Mario Jandeck Ort, Datum