|
fit 2002 > Wissensakquisition
> Konzepte und Techniken > Datawarehousing |
|
Überblick |
|
Einer der wichtigsten und dadurch auch am sorgfältigsten durchzuführende Arbeitsschritt beim Design eines Data Warehouses ist die Übertragung der Daten aus dem laufenden Geschäftsprozess in das Data Warehouse. Eine logische Transformation der Daten ist in diesem Arbeitsschritt meist unumgänglich und von großer Bedeutung, denn das Data Warehouse kann aus mehreren Gründen nicht das konzeptuelle Datenmodell der zu analysierenden Geschäftsprozesse übernehmen. Zum einen muss das Datenmodell des Data Warehouses unabhängig von den Datenstrukturen der einzelnen Teile des Gesamtsystems sein. Eine Applikation zum Beispiel, die alle Geschäftsprozesse einer Firma abdecken soll, die spezielle Artikel sowohl produziert als auch verkauft, wird für die jeweiligen Benutzergruppen andere Sichtweisen ihrer Produkte darstellen müssen. So wird für den Verkäufer wohl eher Preis, verfügbare Stückzahl usw. von Bedeutung sein, für den Erzeuger jedoch viel mehr spezielle Details bezüglich des Designs. Das Modell des Data Warehouses hingegen sollte alle, für die Analyse relevanten, Daten aus allen beteiligten Geschäftsprozessen enthalten. Da wie schon erwähnt, für eine aussagekräftige Analyse oftmals Daten von verschiedenen Systemen des gleichen Geschäftsbereiches zusammengeführt werden müssen, kann man von vorn hinein nicht fordern, dass alle Systeme das gleiche zugrundeliegende Datenmodell verwenden, da in verschiedenen Organisationen unterschiedliche Applikationen und Plattformen verwendet werden. Die Datenstruktur des Data Warehouses sollte für das jeweilige Aufgaben Gebiet optimiert sein, die verwendeten Applikationen jedoch bieten dies oftmals nicht: Angekaufte Anwendungen sind meist allgemeiner gehalten, um in den verschiedensten Bereichen eingesetzt zu werden bzw. unterliegen sie Plattform spezifischen Einschränkungen. Dies macht eine Transformation der Daten vor dem einfügen in das Data Warehouse unumgänglich. Weiters kann der hohe Normalisierungsgrad des Datenmodells, der in den Echtsystemen zielführend ist, im Data Warehouse zu Problemen führen. Hoher Normalisierungsgrad bedeutet hohe Flexibilität. Im Data Warehouse ist es jedoch aus Performancegründen und auch aus Gründen der Korrektheit meist sinnvoller, den Grad der Normalisierung zu vermindern. Ein Produkt sei zum Beispiel ein Monat lang in einer Produktgruppe A und im nächsten Monat in einer Produktgruppe B. In einer Bestellung würde in einem Echtsystem mit einem gut entwickelten Datenmodell nur die Produkt-ID gespeichert, die Produktgruppe wäre dann über joins heraus findbar. Im Data Warehouse wäre es sinnvoller, die Produktgruppe, sofern sie relevant ist, gleich in der Bestellung zu speichern, weil joins bei den großen Datenmengen sehr aufwendig sind und bei jedem Snapshot der Original Daten auch ein Snapshot aller Produktgruppen gespeichert werden müsste, obwohl sich diese Daten nicht ändern würden. Auch aus diesem Beispiel ist ersichtlich, dass das Design des Datenmodells für die Auswertungsmöglichkeiten und die Performance des Data Warehouses entscheidend ist. Physikalische Transformation der Daten des operativen Systems Neben der logischen Transformation der Daten bei der Übernahme aus dem operativen System in das Data Warehouse, ist natürlich auch die physikalische Daten Transformation von großer Bedeutung. Diese Transformationsprozesse sind bekannt als "data scrubbing" und "date staging". Bei zentralisierten Data Warehouses, die die Daten aus mehreren operativen
System (z.B. mehreren Geschäftsstellen einer Organisation) beinhalten,
aber noch mehr natürlich bei verteilten Data Warehouses treten Probleme
mit inkonsistenten Bezeichnung für ein und das selbe Objekt auf.
Verschiedene Anwendungen verwenden unterschiedliche oft leicht verwirrende
Ausdrücke für dieselben Objekte, oft bezieht sich der Unterschied
auch nur auf die Sprache. Jedoch nicht nur die Bezeichnung kann von System zu System verschiedenen sein: Auch das Datenformat bzw. die Datentypen, die zur Speicherung der Attribute verwendet werden, können sich untereinander unterscheiden und müssen auf ein einheitliches klar definiertes Format angepasst werden. Gerade bei verteilten Data Warehouses (siehe ...) besteht überdies die Gefahr, dass die einzelnen lokalen Data Warehouses auf unterschiedlichen Plattformen realisiert sind und selbst "gleiche" Datentypen intern unterschiedlich dargestellt werden. Oft noch kritischer als unterschiedliche Bezeichnung und physikalische Repräsentation sind fehlende Daten. Während der Übernahme der Daten aus dem operativen System ist es aus mehreren Gründen möglich, dass die Datensätze im Sinne des Data Warehouses unvollständig sind. Zum einen könnten aufgrund von Übertragungsfehlern Daten verloren gehen. Diese Probleme sind jedoch mit den verschiedensten Methoden zu beheben. Komplizierter wird es hingegen jedoch, wenn die Daten aus den einzelnen Systemen gewisse Attribute nicht enthalten, weil sie zum Beispiel im Kontext dieses einen Systems selbstverständlich sind. Für diese Art von Daten muss überlegt werden, welche Art von Defaultwerte angenommen werden kann und darf. Noch schwieriger zu erkennen, aber ebenso wichtig zu beheben, sind Datenfehler, die von Fehleingaben der Benutzer herführen. Hierfür müssen meist relativ komplexe Abfragen konstruiert werden, die eine Fehlererkennung ermöglichen. Bereitstellung häufig verwendeter Diagramme und Abfragen Neben den Grundkonzepten, die die Speicherung und Korrektheit der Daten behandeln, ist es beim Design eines Data Warehouses auch wichtig gewisse, relative einfache dafür aber sehr schnelle und flexible, Methoden zur Aufbereitung der Daten zur Verfügung zu stellen. Vorallem sollte es möglich sein, verschiedene "`views"' der Daten zu erstellen, mit denen eine Art Filterung der Daten vorgenommen werden kann, um spätere Analysen zu beschleunigen. Die genaueren Möglichkeiten zur Auswertung und Verknüpfung der Daten wird in (Link zu Data Mining) behandelt. Gerade Zusammenfassungen von Daten können aufgrund der Abstraktion von gewissen Details gerade für erste Analysen sehr wichtig sein, da sie den Analysevorgang stark beschleunigen und - sofern korrekt erstellt - alle relevanten Daten enthalten. Diese Regeln, die zur Zusammenfassung der Daten angewandt werden, können sehr komplex werden und es bedarf an viel Know-How diese zu erstellen. Umgekehrt kann es auch von Bedeutung sein, ein und das selbe Detail mehrmals von verschiedenen Sichtweisen zu betrachten. So ist es zum Beispiel auf jeden Fall interessant Rechnungen oder Vertragsabschlüsse jeweils nach Kunde, Verkäufer oder Verkaufsstandort aufzuschlüsseln, um daraus gewisse Trends herauslesen zu können. Diese hier angesprochenen Analysen und das endgültige Treffen einer Aussage ist wiederum Sache des Data Minings, durch das zur Verfügung stellen von Zusammenfassungen, wird die Anwendung der Algorithmen des Data Minings jedoch einfacher und effizienter. Technische Voraussetzungen für den Betrieb eines Data Warehouses Die hier im Folgenden behandelten Problemstellungen, stellten vorallem im früheren Zeitalter des Data Warehousings große Hindernisse für einen erfolgreichen Einsatz eines Data Warehouses dar. Trotz moderner Datenbanksysteme, die heutzutage eine Vielzahl der unten angeführten Voraussetzungen erfüllen, sind diese technischen Grundvoraussetzungen immer noch wichtig und keines falls als selbstverständlich zu erachten. Vorallem durch den rasanten Anstieg des zu behandelnden Daten-Volumens und dem immer größer werdenden Grad an Vernetzung von Organisationen rund um die Welt. Verwalten von großen Datenmengen auf verschiedenen Speichermedien Bestand früher das Hauptproblem bei großen Datenmengen (Datenvolumen im dreistelligen Megabyte-Bereich) grundsätzlich überhaupt in der Möglichkeit das auftretende und über die Jahre angehäufte Datenvolumen zu speichern, so hat sich dies heutzutage mehr in ein Problem des effizienten Zugriffs verschoben. Obwohl heutzutage die Datenmengen von großen Data Warehouses von hunderten Terrabyte bis zu Pentabyte reichen können, ist nicht so sehr die Speicherung dieser Daten, als eine Möglichkeit des effizienten Zugriffs die Hauptschwierigkeit. Dies ist natürlich von der Art und Struktur des darunterliegenden Datenbanksystems abhängig. Eine genauere Darstellung der Möglichkeiten, die hierfür existieren ist aus der Ausarbeitung des Themas "`Datenbanken"' (Link zu DB) ersichtlich. Aufgrund der Menge an Daten, die im Data Warehouse gespeichert werden sollen, ist es notwendig über eine gut entwickelte Methodik zum Einfügen der Daten in das Data Warehouse zu verfügen. Das Einlesen bzw. Empfangen der Daten, sowie die logischen, sowie physikalischen Transformationen müssen mit minimaler Beteiligung der Administratoren des Data Warehouses geschehen. Wird der Overhead des Einfügens der Daten zu groß, ist das betreffende Data Warehouse unbrauchbar. Aufgrund der enormen Datenmenge, die im Data Warehouse verwaltet werden muss, ist eine Partitionierung der Daten in aktive und inaktive Daten unumgänglich. Inaktiv kann in diesem Fall zum Beispiel Archivierung auf Backup-Bändern oder anderen externen Speichermedien bedeuten. Das heißt eine weitere Grundvoraussetzung eines Data Warehouse ist ein Zugang zu ein oder mehreren externen Speichermedien zur kompakten Archivierung der inaktiven Daten. Welcher Teil der Daten interessant und damit aktiv zugreifbar bleibt und welcher nicht, kann von Analyse zu Analyse variieren. So haben zum Beispiel Auswertungen von Verkauftrends des letzten Jahres aller Geschäftsbereiche einer Organisation und die Entwicklung einer speziellen organisatorischen Einheit über zwei Jahrzehnte nur einen sehr geringen Bereich überlappender Daten, die für beide interessant und somit aktiv gehalten werden sollten. Aus diesem Grund sind effiziente Mechanismen für die Wiederherstellung von Daten von externen Speichermedien unumgänglich. Flexibler Zugriff auf die gespeicherten Daten Ein wichtiges Merkmal eines Data Warehouses ist, sehr flexible und vorallem oft unvorhersagbare Datenzugriffe zu ermöglichen. Nur wenn sehr effiziente und schnelle Abfragen aus dem Datenbestand gewonnen werden können, können nachfolgende, auf die Struktur des Data Warehouses aufbauende, Data Mining Prozesse erfolgreich und in vertretbarer Zeit, Analysen durchführen. Ein dabei unvermeidliches und äußerst wichtiges Designkriterum
ist die Möglichkeit der Indizierung der Daten. Natürlich erhöht
auch eine intelligente, dem Geschäftsbereich angepasste Partitionierung
der Daten, die Performance beim Zugriff auf das Data Warehouse. Diese
Methoden alleine wären jedoch bei der heutigen Menge an Daten mehr
als unzureichend. Um etwaige Änderungen an der Datenstruktur frühzeitig erkennen zu können, ist ein gut durchdachtes Überwachungssystem der Daten ebenfalls notwendig. Es werden die meisten noch so sorgfältig überlegten Datenstrukturen und Zugriffsstrategien nutzlos und ineffizient, wenn das Datenvolumen für welches das Design des Systems ausgelegt ist, überstiegen wurde. Sicher eines der grundlegendsten, aber nicht desto trotz sehr wichtige
Forderung an das Design des Data Warehouses ist ein hochentwickeltes \textit{lock-management}.
Da gerade bei großen Organisationen relativ viele gleichzeitige
Zugriffe auf das Data Warehouse erfolgen können und eben gleichzeitig
das Einfügen neuer Daten ohne Störung des Benutzers erfolgen
soll, sind auch hohe Anforderungen an das \textit{lock-management} zu
stellen.
|
|
Weiterführende Informationen |
|
|
|
Verweise auf Arbeiten anderer gruppen |
|
|
|
>Entstehungskontext | Konzepte und Techniken | Entwicklung und Auswirkungen | Praxis | Bewertung |