Data Warehouses bestehen aus zwei Hauptkomponenten: einer flexiblen Anfrageschnittstelle zur Datenanalyse (OLAP) und einer relativ starren ETL-Komponente zum Laden der Daten ins Data Warehouse. In diesem Artikel soll vorgestellt werden, wie die Datenintegration bedarfsabha¨ngig zu flexibilisieren ist, welche Vorteile sich daraus ergeben und welche Herausforderungen bei der Entwicklung eines solchen interaktiven ETL (iETL)-Prozesses bestehen.
Institutionen des o¨ffentlichen Sektors sehen sich mehr noch
als industrielle Verwaltungen einer Vielzahl von
Softwarelo¨sungen zur Unterstu¨tzung ihrer Prozesse gegenu¨ber.
Wa¨hrend in Industrien wie dem Automobilbau oder dem
Bankenbereich fu¨nf bis zehn Kernkompetenzen in der IT
dargestellt werden, finden sich im Kerngescha¨ft o¨ffentlicher
Verwaltungen leicht zwischen 100 und 150 Prozesse
verschiedener Dienstleistungskomplexe [
Anpassung Datenintegration Datenbereinigung
OLAP-‐Anfragen f e Anfrageergebnisse
Data Mart Data Warehouse
Selection Abbildung 1: Interaktiver ETL-Prozess eines DW formationsfu¨lle spiegelt sich in der Heterogenita¨t der vorzuhaltenden Lo¨sungen, der Vielfalt der Schnittstellen zum Informationsaustausch sowie der Menge vorzufindender Datenbanklo¨sungen und Datenablagen in Excel und a¨hnlichen Formaten wider. Dem gegenu¨ber steht der zunehmende Bedarf an zentralen Beobachtungs- und Steuerungsinstrumenten der Bereiche Business- und Geo-Intelligence. Der Verbreitung fachu¨bergreifender Systeme steht oft der sehr hohe Datenbeschaffungsaufwand (sowohl initial als auch prozessbegleitend) im Weg. Insbesondere die Erschließung neuer Datenquellen bei der Ausweitung von Kennzahlensystemen auf neue Fachgebiete oder bei Auftreten tagesaktueller ad-hoc-Abfragen mit teils ”exotischen“ Fragestellungen geht stets mit großem manuellen Aufwand bei der Informationssuche und -transformation einher. Es geht also um eine Lo¨sung zur Identifizierung und Integration heterogener Datenquellen im Data Warehouse (DW)-Umfeld, die den Anwender in verschiedensten Datenquellen enthaltene Informationen finden und in seinen Bestand u¨bernehmen la¨sst. Nicht im Fokus stehen von technischem Personal eingerichtete turnusma¨ßige Beladungen oder Real-Time-Data-Warehousing sondern die zuna¨chst einmalige Integration aus Quellen mit u¨berwiegend statischem Inhalt und geringer Komplexita¨t durch den Anwender. Kapitel 2 illustriert dies anhand zweier Szenarien aus der Anforderungsanalyse. Abb. 1 zeigt in durchgezogenen Pfeilen bestehende Daten- und Kontrollflu¨sse und in unterbrochenen Linien die zu entwickelnden Verbindungen. Interessant dabei ist, wie der Prozess aus Nutzersicht verlaufen kann und mehr noch, mittels welcher Architekturen und Datenstrukturen die daraus ermittelten Anforderungen am besten umzusetzen sind.
In der Anforderungsanalyse dieses Projektes sind
Szenarien ([
Szenario 1 – Kontext: Die Klassifikationshierarchie des DW mit ihren Attributen ist dem System bekannt. Ebenso wurden die mo¨glichen Datenquellen (Web-Services, Suchpfade im Dateisystem) bereits konfiguriert. Die drei Dimensionen der Daten im DW sind: Zeitraum, Geo-Objekte (Hierarchie geographischer Bezugselemente) und Kenngro¨ßen.
Situation: Wenige Tage vor der Jahresversammlung des Gaststa¨tten- und Hotelverbandes wird Herr B. im Amt fu¨r Ausbildungsfo¨rderung mit dem Zusammenstellen einer Statistik beauftragt. Sie soll die Entwicklung der Auszubildendenzahlen der vergangenen Jahre in diesem Bereich aufzeigen. Dazu fragt er die dafu¨r relevanten Informationen in einem DW-System an und erkennt an der grauen Einfa¨rbung des entsprechenden Knotens in seiner DW-Anwendung, dass sdciheaDfta“tefu¨nrzduernKSetnandgtrto¨eßile””NAourdszsutabdiltd“enimdeJianhdre2r0H08aufeswhliernt-. Dass sie nicht wie sonst automatisch u¨bermittelt wurden, liegt seiner Meinung nach an der Umbenennung des Stadtteils (fru¨her: ”Neustadt“) im Vorjahr.
Lo¨sungsausblick: U¨ ber einen Rechtsklick auf den ausgegrauten Knoten la¨sst Herr B. eine Anfrage an das Suchsystem generieren, was ihn zur Eingabemaske (Abb. 2) fu¨hrt. Die Suchfelder fu¨r die drei Dimensionen sind schon vorbelegt; per direkter Texteingabe oder u¨ber die Schaltfla¨chen ”Variablen auswa¨hlen“ und ”Objekte auswa¨hlen“ ko¨nnte Herr B. die Suchkriterien vera¨ndern; die jeweiligen Dialoge stellen die mo¨glichen Werte der jeweiligen Dimension zur Auswahl. Er tippt in das Suchfeld der Ortsbezeichnungen ”Neustadt“ ein und bekommt nach Abschluss der Suche als Ergebnis eine Liste von Datenquellen zu sehen (Abb. 3). Das erste Ergebnis ist offenbar ein Bericht eines konkreten Hotels und damit nicht relevant. Herr B. wa¨hlt also den zweiten Treffer und betrachtet ihn in der Voransicht. Er erkennt, dass die gesuchten Daten (eine Auflistung der Auszubildenen mit Wohn- und Ausbildungsadresse) in dem Suchergebnis enthdaulltefun¨rsiEndxcuenl-dDwateecihense.ltDvoirat”kImanpnoretriereeinn“zezlnuemSIpmapltoernt-MunodBereiche der Excel-Tabelle als Werte der drei Dimensionen markieren und den Import in sein DW-Systems anstoßen. Anschließend widmet er sich der Aufbereitung der Statistiken.
Szenario 2 – Kontext: Die Konfiguration entspricht der von Szenario 1. Hier wird jedoch die Anfrage nicht vom DWSystem vorbelegt.
Situation: Vor dem Beitritt zu einem Verband zur Fo¨rderung von Solarenergieanlagen an privaten Immobilien sollen fu¨r 2010 Anzahl, Verteilung und Ho¨he der Landesfo¨rderung von Anlagen ermittelt werden. Frau B. ist damit beauftragt und stellt fest, dass zu den Fo¨rderungen bislang keine Daten im DW existieren, jedoch hat sie ku¨rzlich davon geho¨rt, dass ein Mitarbeiter einem anderen per Mail eine solche U¨ bersicht schicken wollte.
Lo¨sungsausblick: Sie startet das Suchsystem und spezi-figzeiewretrbihlirceh“An(sfrieahgee:A”bsobl.a4r)a.nDlaegrenB2eg0r1i0ff+”fso¨orladrearnulnagge+n“pruivnadt f”dwu¨faio¨rrsrkddJeeinaerhusdrnoalg”ls“.20K”u1+no0“dm“”emspiontrlelihevniaentr“gihm,eo¨gdheiEtenerig”hPegrbreibnwoeiressirtobea¨nnltditcehdhrae“srltiwneFniudchnestrdeiisgFntu.eslinElneddbnsetunebnlseldoevor, soll die Priorita¨t des Ergebnisses sinken. Als Suchort schließt Frau B. die Datenquelle ”StarDepot“ aus, dann startet sie die Suche. In einer Ansicht a¨hnlich zu Abb. 3 nutzt sie die Vorschau, um die Datei mit den gesuchten Informationen zu identifizieren. Anschließend bereitet sie die Daten fu¨r den Import vor und u¨bernimmt sie in den eigenen Datenbestand.
In Abschnitt 2 wurden Anwendungsszenarien und mo¨gliche Lo¨sungsausblicke vorgestellt, die eine Anpassung des ETL-Prozesses notwendig machen. In diesem Abschnitt stellen wir dafu¨r eine erweiterte DW-Architektur vor.
3.1
Der Anwender soll bei der Quellenidentifikation und
Datenintegration im ETL-Prozess in einem DW unterstu¨tzt
werden. Dafu¨r mu¨ssen die verfu¨gbaren Datenquellen so
aufbereitet werden, dass eine Recherche und eine
anschließende Auswahl von geeigneten Datenquellen mo¨glich ist. Die
Heterogenita¨t der Datenquellen erschwert die automatische
Integration in das DW. In fo¨derierten Datenbanken gab es
umfangreiche Untersuchungen zu Heterogenita¨ten der
einzelnen Datenquellen bzgl. Syntax und Semantik von Werten,
Attributen, Relationen und Modellen [
Der Prozess des Fu¨llens eines DW mit Daten wird als
ETL-Prozess bezeichnet, ETL steht hierbei fu¨r Extract,
Transform und Load. Die Basisdaten in den meisten
Anwendungen sind heterogene Daten, die in ein einheitliches Format,
das multidimensionale Modell des DW integriert werden
sollen. Bei diesem Prozess werden die neuen oder vera¨nderten
Daten aus den Basisdatenquellen ausgewa¨hlt (Extraction),
in eine einheitliche Darstellung umgewandelt
(Transformation), dabei vervollsta¨ndigt, Duplikate bereinigt und eventuell
voraggregiert. Anschließend erfolgt das Laden in die
Datenbank (Load) [
Wir schlagen deshalb vor, das Referenzmodell fu¨r die
Architektur von DW aus [
Die zentrale Komponente in der vorgestellten Architektur
bildet der Data Warehouse Manager (DWM) (siehe Abb. 5).
Der DWM steuert in einem klassischen DW nach [
Die Wissenskomponente (knowledge component) stellt Informationen u¨ber Klassifikations- und Dimensionshierachien, semantische Verknu¨pfungen und die Typisierung sowie Metadaten einzelner Attribute bereit (siehe Abb. 5). Das doma¨nenspezifische Wissen wird durch Quellenangaben, Synonyme und Muster (Format- bzw. Modell-Pattern) erga¨nzt. Die Wissenskomponente ist fu¨r die Prozesse der Quellenidentifikation und Datenintegration neuer Datenquellen unabdingbar.
• Der Metadata Manager stellt eine Schnittstelle bereit, u¨ber die andere Komponenten Anfragen an die Wissensbasis und das Metadaten-Repository stellen und Antworten anfordern ko¨nnen. • Die Knowledge Base beinhaltet ein Wissensmodell fu¨r die Speicherung und Verwaltung der semantischen und ontologischen Informationen. • Das Metadata Repository beinhaltet alle weiteren
Metadaten, die vom DWM beno¨tigt werden.
Die Umsetzung einer Wissenskomponente erfordert den Aufbau einer Wissensbasis zum Anwendungsgebiet des DW, womit je nach Anwendungsszenario ein hoher manueller Aufwand verbunden ist. Ein Teil der Wissensbasis kann aus den hierarchischen Klassifikationsattributen der Dimensionen des DW u¨bernommen werden.
Zusa¨tzlich zu diesen hierarchischen Informationen werden Wo¨rterbu¨cher beno¨tigt, die die Verbindung zwischen Konzepten der Wissensbasis und Suchbegriffen herstellen. Diese Wo¨rterbu¨cher sind initial zur erstellen und sollen beim Einsatz des i ETL-Tools von einer lernenden Komponente erweitert und anpasst werden. analysis
BI-Tool Repository load
Base Repository load Staging
Area extraction knowledge component Metadata Manager
Metadata Repository
Knowledge
Base Data Warehouse Manager Response Manager
Query Manager data integration source identification Integration Layer
Index applications documents databases
portable disks control flow data flow Abbildung 5: Architektur fu¨r den flexiblen ETL-Prozess Search Engine 3.3
Liegt in einem klassischen DW die Auswahl der Datenquellen bzw. der Quelldaten vorrangig bei den zusta¨ndigen Administratoren, so soll in diesem Ansatz der Anwender des DW in die Quellenidentifikation einbezogen und dabei unterstu¨tzt werden.
Eine Suchkomponente soll bei der Quellenidentifikation im
ETL-Prozess dem Anwender die Auswahl weiterer
Datenquellen erleichtern. Dafu¨r soll ein Index u¨ber alle
verfu¨gbaren Datenquelle aufgebaut werden, die u¨ber den
Integration Layer verfu¨gbar sind. Der Prozess der
Quellenidentifikation (source identification) ist in Abbildung 5 rechts
dargestellt. Die Komponenten sind an die Architektur
einer Web-Suchmaschine angelehnt, wie sie beispielsweise in
[
• Der Query Manager stellt u¨ber eine Schnittstelle einfache oder erweiterte Suchmasken bereit. Fu¨r die Suche werden vorerst die existierenden Dimensionen aus dem DW als Suchparameter verwendet: – Was: Kenngro¨ßen, die in einer Datenquelle enthalten sein mu¨ssen. – Wo: Geo-Objekte, die durch die Werte beschrieben werden.
– Wann: Datumsangaben und Zeitbereiche. • Das Query Processing beschreibt eine Vorverarbeitung der Anfrage unter Verwendung der Wissensbasis. Dabei soll eine Anpassung der Anfrage hinsichtlich der Struktur (Ort, Zeit, Schlu¨sselwo¨rter), die Expansion der Anfrage mit Hilfe der Wissensbasis sowie ein Vokabularmapping und weitere Vorverarbeitungsschritte wie eine lexikografische Analyse oder Stoppworteleminierung stattfinden. • Die Search Engine soll die Indizierung von Datenquellen, eine Anfrageverarbeitung und die Bereitstellung von Ergebnislisten u¨bernehmen. Die Indizierung (mit gleichen Methoden wie bei der Anfrageverarbeitung) soll durch eine Strukturanalyse auf Basis von Mapping-Mustern (die wa¨hrend der Datenintegration erzeugt werden) umgesetzt werden. Neben dem Bereitstellen von Anfrageergebnissen aus heterogenen Datenquellen sollen Suchergebnisse mit Informationen u¨ber den Fundort innerhalb der Datenquellen angereichert werden, wofu¨r doma¨nenspezifische Informationen und Musteranalysen aus der Wissensbasis zum Einsatz kommen sollen. • Das Crawling beschreibt den Schritt, in dem verfu¨gbare Datenquellen durchsucht und fu¨r die Indizierung bereitgestellt werden. In diesem Schritt ist die Nutzung vorhandener Mapping-Muster zu Strukturanalysen und semantischen Auswertungen geplant. • Der Response Manager wird fu¨r die Pra¨sentation der Anfrageergebnisse genutzt. Dem Nutzer soll eine Vorauswahl von Datenquellen durch eine vereinfachte Datenvorschau ermo¨glicht werden, eine semiautomatische Identifizierung mo¨glicher Indikatoren, Variablen und Zeitra¨ume in den Anfrageergebnissen soll dabei erfolgen (siehe Abb. 3). Die ausgewa¨hlten Quellen werden hier an den DWM u¨bergeben, der in einem na¨chsten Schritt die Datenintegration anstoßen kann.
Eine Herausforderung ist das Design des Anfrageinterfaces und der Ergebnisdarstellung. Hierfu¨r mu¨ssen die Anforderungen der Anwender bestimmt werden.
• Anfrageinterfaces: Wie ko¨nnen Suchanfragen auf Ordner, Datenquellen oder Dateitypen eingegrenzt werden und welche der Anfragetypen Context (Phrase, Boolean, etc.), Pattern Matching oder strukturierte Anfragen (formularbasiert) ko¨nnen genutzt werden. Außerdem ist zu kla¨ren, ob die Klassifizierung der Anfrage durch vorhandene Kategorien der Wissensbasis mo¨glich und sinnvoll ist. • Ergebnisdarstellung: Wie muss eine zielgerichtete Pra¨sentation der Anfrageergebnisse unter Verwendung der Wissensbasis umgesetzt werden und wie ist dabei eine semiautomatische Identifizierung potentieller Indikatoren, Variablen und Zeitra¨ume mo¨glich. Daneben sollen relevante Elemente der Ergebnismenge hervorgehoben und die Identifizierung von Strukturen innerhalb eines Treffers durch Anwendung von MappingMustern mo¨glich sein. • Query Processing (basierend auf der Wissensbasis): Wie kann die Wissensbasis fu¨r die Anfrageerweiterung in Form einer facettierten Suche genutzt und wie ko¨nnen Methoden des Relevance Feedback zur Verbesserung der Qualita¨t der Ergebnisse genutzt werden. • Search Engine: Wie kann die Integration externer Anwendungen (Enterprise Search, ERP, CRM, etc.) umgesetzt werden, wenn die bereitgestellte Anfrageschnittstellen nur Teilergebnisse liefern oder der Umfang der Datenbasen zu groß ist. Die Integration unterschiedlicher Datenformate soll ebenso unterstu¨tzt werden, wie die Duplikaterkennung, wenn Inhalte und Daten aus unterschiedlichen Quellen genutzt werden. Weiterhin sollen Mapping-Muster fu¨r den Prozess der Indizierung und Extraktion genutzt werden und Klassifikation durch die Mapping-Muster unterstu¨tzt werden. 3.4
Die Datenintegration muss bedarfsabha¨ngig und flexibel angepasst werden, wenn durch die Quellenidentifikation neue Datenquellen zu integrieren sind. Die Flexibilisierung soll durch Anwendung von semantischen und ontologischen Konzepten erreicht werden, wodurch doma¨nenspezifisches Wissen ausgenutzt wird. Die Architektur in Abbildung 5 ist dabei an die Referenzarchitektur angelehnt.
• Mit extraction wird die U¨ bertragung von Daten aus externen Quellen in den Arbeitsbereich (staging area) beschrieben. Die Auswahl der Datenquellen wurde im Vorfeld durch den Anwender (Quellenidentifikation) durchgefu¨hrt. Der Prozess muss um semiautomatische Methoden des Schema Matchings und Mappings erweitert werden (pattern matching).
Die bei der Datenextraktion und -transformation
erzeugten Mapping-Mustern sollen fu¨r eine spa¨tere
Wiederverwendung in der Wissensbasis vorgehalten
werden und bei jeder Datenintegration auf ihre
Anwendbarkeit hin u¨berpru¨ft werden. Passende Muster fu¨r die
Extraktion einer Datenquellen werden dem Anwender
angeboten. Die Schritte der Extraktion und
Transformation mu¨ssen durch angepasste, graphische Tools
unterstu¨tzt werden.
• Mit transformation wird die Abbildung der Daten
hinsichtlich struktureller und inhaltlicher Aspekte
beschrieben. Neben der Datentransformation (z. B.
Konvertierung von Kodierungen, Vereinheitlichung von
Datumsangaben, etc.) sollen hier auch eine
Datenbereinigung, Duplikaterkennung und eine Datenfusion
stattfinden (siehe auch [
Die Herausforderungen bei der Datenintegration liegen bei der Tool-Unterstu¨tzung des Anwenders, sowie bei der semantischen Unterstu¨tzung des Transformationsprozesses. Das Schema einer Datenquelle ist in der Regel unbekannt, weshalb es mit Hilfe geeigneter Werkzeuge extrahiert werden muss.
• Transformation: Die Datentransformation aus dem Format der Basisdatenquelle ins Zielformat kann nicht vollsta¨ndig automatisiert werden. Herausforderung ist hier die Entwicklung von Nutzerinterfaces zur Eingabe der beno¨tigten Informationen durch den Fachanwender. Die dabei entstehenden Transformationsmuster sollen gespeichert werden, damit sie fu¨r andere Datenquellen verwendet werden ko¨nnen.
Welche vorhandenen Ansa¨tze der Datenintegration ko¨nnen fu¨r die Datenbereinigung, Duplikaterkennung und Datenfusion angewendet werden und wie kann eine Plausibilita¨tspru¨fung der Daten unterstu¨tzt werden. Fu¨r eine Plausibilita¨tspru¨fung ko¨nnen z. B. Regeln definiert werden, die die Wissensbasis einbeziehen. Ein mo¨glicher Ansatzpunkt ist hier die Angabe von checkconstraints.
Das im Projekt zu entwickelnde Verfahren wird sich nicht auf alle DW anwenden lassen. Voraussetzung ist, dass es eine Wissensbasis zu dem Anwendungsgebiet des DW gibt. Da diese Wissensbasis eine zentrale Rolle beim Finden der relevanten Datenquellen und bei der Transformation der Daten ins DW spielt, muss eine solche Wissensbasis fu¨r einen flexiblen ETL-Prozess vorhanden sein. Teile der Wissensbasis lassen sich aus den Klassifikationsattributen der Dimensionen des DW generieren; die Zuordnung dieser Klassifikationshierarchie zu den korrespondierenden Suchbegriffen fu¨r die Datenquellen muss fu¨r das jeweilige Anwendungsgebiet erga¨nzt werden.
Jede Datenintegration bewirkt das Zusammenfu¨hren von
Daten aus heterogenen Datenbanken und
Informationssystemen. Es gibt Klassifikationen, die die Heterogenita¨ten der
einzelnen Datenquellen systematisieren. Heterogenita¨ten
ko¨nnen bzgl. Syntax und Semantik von Werten, Attributen,
Relationen, Modellen existieren ([
Eine dabei bestehende Aufgabe ist Matching und
Mapping heterogener Datenbanken. Es gibt mehrere
MappingTools, die eine intuitiv bedienbare Oberfla¨che anbieten, um
dem Benutzer das Entwickeln von
Datentransformationskomponenten zu erleichtern (wie Altova MapForce1, oder
IBM Data Integrator), dieser Prozess ist jedoch nicht
automatisierbar. Einen U¨ berblick u¨ber Forschungsansa¨tze in
dieser Richtung findet man in [
ETL
Beim ETL-Prozess in einem DW werden die Basisdaten
(meist heterogene Daten) in ein einheitliches Format, das
multidimensionale Modell des DW integriert [
Die Idee, Ontologien zur Beschreibung von Objekten
einzusetzen, ist weit verbreitet. Im DW-Bereich gibt es einen
Vorschlag, Ontologien zu verwenden, um die Metadaten des
Data Warehouses daraus abzuleiten [
Die flexible, durch situativ entstandenen Datenbedarf initiierte Integration bislang unerschlossener Datenquellen in ein Data Warehouse erfordert eine Anreicherung des ETLProzesses um interaktive Schritte. Um diesen Prozess fu¨r den Fachanwender handhabbar zu halten, bedarf es zusa¨tzlicher Komponenten zur Speicherung und Nutzung von doma¨nenspezifischem Wissen (knowledge component), die das Finden (source identification) und Integrieren (data integration) neuer Daten erleichtern bzw. erst ermo¨glichen.
Geleitet von Anwendungsszenarien wurde ein Konzept zur Architektur eines solchen Systems vorgestellt. Die Herausarbeitung technischer Herausforderungen zeigt den zu gehenden Weg: Die Details der einzelnen Komponenten sind zu konkretisieren, bislang nicht kombinierte Techniken zu verbinden und eine angemessene Nutzerschnittstelle zu entwickeln.