XCube: Konzepte f¨ur eine XML-basierte Beschreibung von Datenw ...
XCube: Konzepte f¨ur eine XML-basierte Beschreibung von Datenw ...
XCube: Konzepte f¨ur eine XML-basierte Beschreibung von Datenw ...
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
<strong>XCube</strong>: <strong>Konzepte</strong> für <strong>eine</strong> <strong>XML</strong>-<strong>basierte</strong><br />
<strong>Beschreibung</strong> <strong>von</strong> <strong>Datenw</strong>ürfeln zur Realisierung<br />
<strong>eine</strong>s föderativen Data-Warehouse-Netzwerkes<br />
Gunnar Harde<br />
Oldenburger Forschungs- und Entwicklungsinstitut<br />
für Informatik-Werkzeuge und Systeme (OFFIS),<br />
Escherweg 2, D-26121 Oldenburg, Germany,<br />
gunnar.harde@OFFIS.DE,<br />
WWW home page: http://www.OFFIS.DE<br />
Zusammenfassung Das World Wide Web wurde bisher kaum als Datenquelle für Data-Warehouse-<br />
Systeme verwendet. In diesem Beitrag1 wird ein Konzept vorgestellt, das die Potentiale des WWW und<br />
des Data Warehouses durch die Einführung standardisierter, im Web abrufbarer <strong>Datenw</strong>ürfel - sogenannte<br />
” Web Cubes“ - zusammenführt. Die Einführung <strong>von</strong> Web Cubes ermöglicht den Aufbau <strong>eine</strong>s föderativen<br />
Data-Warehouse-Netzwerkes. Ein solches Netzwerk erlaubt den Austausch <strong>von</strong> ausgewählten Daten zwischen<br />
Data-Warehouse-Systemen, die Online-Analyse <strong>von</strong> Webdaten mit Hilfe <strong>von</strong> OLAP-Technologie<br />
und die Integration <strong>von</strong> Webdaten in ein Data Warehouse. Die geschäftlichen Anforderungen werden<br />
durch Anwendungsfälle und diese unterstützende <strong>Konzepte</strong> beschrieben. Die technischen Anforderungen<br />
werden daraus abgeleitet und die Verwendung <strong>von</strong> <strong>XML</strong> als Metaformat zur <strong>Beschreibung</strong> <strong>von</strong> Web Cubes<br />
diskutiert. Schließlich wird der derzeitige Entwicklungsstand <strong>von</strong> <strong>XCube</strong> beschrieben. <strong>XCube</strong> stellt<br />
<strong>eine</strong> Sammlung <strong>von</strong> <strong>XML</strong>-<strong>basierte</strong>n Formaten dar, die sowohl Web Cubes selbst als auch Dokumente<br />
zur Bearbeitung <strong>von</strong> Web Cubes spezifizieren. Als Basis für die Modellierung <strong>von</strong> <strong>XCube</strong> wurde die<br />
Multidimensional Modeling Language (MML) verwendet.<br />
1 Einleitung und Motivation<br />
Data-Warehouse-Systeme haben in den letzten Jahren <strong>eine</strong> immer größere Verbreitung erlangt. In<br />
vielen Unternehmen und anderen Institutionen sind sie inzwischen zum zentralen Bestandteil der<br />
technologischen Unterstützung <strong>von</strong> Management-Entscheidungen geworden.<br />
Die Ursprungsdaten für ein Data Warehouse stammen in der Regel aus den operativen Systemen<br />
<strong>eine</strong>s Unternehmens. Das World Wide Web (WWW) hingegen wurde bisher kaum als Datenquelle<br />
genutzt.<br />
Ein Grund dafür ist die unzureichende Struktur der im WWW abrufbaren Daten: Informationen<br />
liegen dort in Form <strong>von</strong> HTML-Dateien ohne semantische <strong>Beschreibung</strong> oder aber als <strong>XML</strong>-<br />
Dateien basierend auf unterschiedlichen Schemata vor; Informationen können ebenso in Bildern<br />
unterschiedlicher Formate, Animationen oder sogar Geräuschen enthalten sein. Zudem unterscheidet<br />
sich die Semantik der Daten im WWW im allgem<strong>eine</strong>n <strong>von</strong> der Semantik, wie sie im Data<br />
Warehouse verwendet wird. Meint z. B. der Ausdruck ” Jahr“ ” Kalenderjahr“ oder ” Geschäftsjahr“?<br />
Wenn es sich um ein Geschäftsjahr handelt, welche Geschäftsjahresvariante ist damit gemeint? Solange<br />
es k<strong>eine</strong> Referenz auf <strong>eine</strong> eindeutige Semantik gibt, ist das Laden der WWW-Daten in ein<br />
Date Warehouse äußerst problematisch.<br />
Aus diesen Gründen hätte <strong>eine</strong> Standardisierung des Datenformates <strong>von</strong> Daten, die <strong>von</strong> <strong>eine</strong>m<br />
Webserver zur Integration in ein Data-Warehouse-System herunterladbar sind, mehrere Vorteile:<br />
• Der ETL-Prozess würde sich stark vereinfachen und entsprechende ETL-Werkzeuge wären<br />
leichter zu realisieren. Anwender könnten sich somit auf die geschäftlichen Anforderungen konzentrieren;<br />
technische Details zur Datenintegration würden in den Hintergrund treten.<br />
1 Eingereicht und akzeptiert für den 5. Workshop ” Föderierte Datenbanken“ (FDBS 2001), Berlin, 11.-12.10.2001.
<strong>XCube</strong>: <strong>Konzepte</strong> für ein Data-Warehouse-Netzwerk<br />
• Der Standard könnte an die Anforderungen an ein Data Warehouse angepasst werden. Der<br />
Parsing- und Transformationsaufwand würde sich verringern und somit die Performance verbessern.<br />
• Der Standard könnte sicher stellen, dass semantisch gleiche Daten aus unterschiedlichen Quellen<br />
vergleichbar sind.<br />
• Der Standard könnte andere Formate wie z. B. zur Zahlungsabwicklung oder zur redaktionellen<br />
Qualitätssicherung durch ein Zertifizierungssystem mit integrieren.<br />
• Der Standard könnte zur Vernetzung <strong>von</strong> unterschiedlichen Data-Warehouse-Sytemen verwendet<br />
werden.<br />
Durch die Verwendung <strong>eine</strong>s solchen Standards für <strong>eine</strong>n Data-Warehouse-optimierten Datenaustausch<br />
wären <strong>eine</strong> Reihe <strong>von</strong> Anwendungen denkbar:<br />
Beispiel 1. Der Betreiber <strong>eine</strong>s elektronischen Marktplatzes bietet neben der Plattform für den Austausch<br />
<strong>von</strong> Wirtschaftsgütern und Dienstleistungen auch <strong>eine</strong> Plattform zur Analyse <strong>von</strong> unternehmensübergreifenden<br />
Daten an. Hierzu werden die Daten der einzelnen Data-Warehouse-Systeme<br />
der Marktteilnehmer auch den anderen Teilnehmern in aggregierter Form zur Verfügung gestellt.<br />
Einerseits wird dabei sichergestellt, dass die Unternehmen k<strong>eine</strong> sensiblen Daten nach außen geben,<br />
andererseits so viel Informationen zur Verfügung stellen, dass <strong>eine</strong> Optimierung des Supply-Chain-<br />
Managements ermöglicht wird.<br />
Beispiel 2. Nach der Fusion zweier Unternehmen soll das Topmanagement die Möglichkeit haben,<br />
auf die bereits existierenden Data-Warehouse-Systeme beider Unternehmen zuzugreifen und die<br />
dort abgelegten Daten zu analysieren. Dazu wird ein weiteres Data-Warehouse-System aufgebaut,<br />
das mit den beiden vorhandenen Systemen vernetzt ist.<br />
Beispiel 3. Ein Unternehmen beabsichtigt s<strong>eine</strong> Produktpalette zu erweitern und möchte vorher das<br />
Potential des neuen Marktsegments näher untersuchen. Dazu werden im Internet Marktdaten sowohl<br />
zum bisherigen als auch zum neuen Markt eingekauft, die bisherigen Unternehmensdaten mit<br />
diesen Markteinschätzungen abgeglichen und schließlich <strong>eine</strong> Prognose für das neue Marktsegment<br />
erstellt.<br />
Beispiel 4. Eine medizinische Forschungseinrichtung möchte die Ausbreitung <strong>von</strong> Epedemien untersuchen<br />
und entschließt sich, ein Data-Warehouse-System als Basis für die Datenbestände zu<br />
verwenden. Bei der Analyse werden diese Daten durch Daten über Bevölkerungszahlen, Klimabedingungen,<br />
Einkommensverhältnisse, Statistiken über die ärztliche Versorgung in den einzelnen<br />
Regionen etc. ergänzt. Diese Daten werden über das Internet <strong>von</strong> öffentlichen Stellen und anderen<br />
Forschungseinrichtungen bereitgestellt.<br />
Im Abschnitt 2 werden verschiedene Anwendungsfälle und unterstützende <strong>Konzepte</strong> für ein<br />
föderatives Data-Warehouse-Netzwerk vorgestellt. Dieser Abschnitt spezifiziert die Anforderungen<br />
an ein föderatives Data-Warehouse-Netzwerk aus geschäftlicher Sicht.<br />
Im Abschnitt 3 werden die technischen Anforderungen aus den zuvor in Abschnitt 2 beschriebenen<br />
Anwendungsfällen hergeleitet. Insbesondere wird die Verwendung <strong>von</strong> <strong>XML</strong> als Metaformat<br />
zur Spezifizierung <strong>von</strong> Web Cubes diskutiert.<br />
Der derzeitige Entwicklungsstand <strong>von</strong> <strong>XCube</strong>, <strong>eine</strong>r <strong>XML</strong>-Spezifikation <strong>von</strong> Web Cubes, wird<br />
in Abschnitt 4 vorgestellt.<br />
2 Anwendungsfälle und unterstützende <strong>Konzepte</strong><br />
In diesem Abschnitt werden mehrere Anwendungsfälle sowie <strong>Konzepte</strong>, die <strong>eine</strong> praktikable Nutzung<br />
dieser Anwendungsfälle unterstützen, vorgestellt. Diese Liste stellt <strong>eine</strong> Art Standbild der<br />
derzeitigen Arbeiten dar; Erweiterungen und Detaillierungen sind in Zukunft möglich.<br />
An dieser Stelle sei der Begriff ” Web Cube“ eingeführt:<br />
c○ Gunnar Harde 2001 2
<strong>XCube</strong>: <strong>Konzepte</strong> für ein Data-Warehouse-Netzwerk<br />
Definition 1. Ein Web Cube ist ein multidimensionaler <strong>Datenw</strong>ürfel, der in <strong>eine</strong>m standardisierten<br />
Format vorliegt und über das WWW zugreifbar und herunterladbar ist. Ein Web Cube beinhaltet<br />
sowohl die Schemabeschreibung als auch die Stamm- und Bewegungsdaten des <strong>Datenw</strong>ürfels.<br />
Stammdaten definieren die Klassifikationsknoten des <strong>Datenw</strong>ürfels und die Einheiten der Kenngrößen,<br />
während Bewegungsdaten aus Kenngrößenwerte bestehen, die den Dimensionen zugewiesen<br />
sind. Die Schemabeschreibung stellt <strong>eine</strong>n Teil der Metadaten des Data Warehouses dar (siehe<br />
auch [11]).<br />
2.1 Anwendungsfall ” Download“: Laden und Integrieren <strong>von</strong> Web Cubes<br />
Ein Web Cube soll <strong>von</strong> <strong>eine</strong>m Webserver geladen und in ein bestehendes Data Warehouse integriert<br />
werden (siehe Abb. 1).<br />
web server<br />
1. schema<br />
2. master data<br />
initial<br />
regular<br />
3. transaction data<br />
data warehouse<br />
Abbildung 1. Anwendungsfall ” Download“.<br />
Zunächst werden Schemabschreibung und Stammdaten heruntergeladen und in das Metadaten-<br />
Repository bzw. in Stammdatentabellen abgelegt. Danach werden die Bewegungsdaten heruntergeladen<br />
und in das Data Warehouse gespeichert.<br />
Dieses Vorgehen ist unproblematisch, solange der geladene Web Cube nicht mit bereits existierenden<br />
<strong>Datenw</strong>ürfeln des Data Warehouses zusammengeführt oder verglichen werden soll. Andernfalls<br />
müssen die Entitäten des Web Cubes mit denen des vorhandenen <strong>Datenw</strong>ürfels gematched<br />
werden oder die semantischen <strong>Beschreibung</strong>en der Entitäten beider Würfel können über <strong>eine</strong>n eindeutigen<br />
Bezeichner wie in Abschnitt 2.5 beschrieben referenziert werden.<br />
Das Herunterladen und Integrieren des gesamten Web Cubes einschließlich der Bewegungsdaten<br />
gewährleistet <strong>eine</strong> gute Performance beim Analysieren der Daten. Nachteilig hingegen ist, dass die<br />
Daten des Web Cubes redundant vorliegen und somit bei der Datenanalyse nicht mehr aktuell sein<br />
müssen. Zudem kann beim initialen Herunterladen aller Daten die Netzauslastung für bestimmte<br />
Anwendungen unakzeptabel hoch sein.<br />
Um <strong>eine</strong> einfache Integration des Web Cubes in ein Data Warehouse zu unterstützen, sollte der<br />
Web Cube <strong>eine</strong> multidimensionale Datenstruktur aufweisen, da das Datenmodel des Data Warehouses<br />
zumindest aus konzeptueller Sicht 2 ebenfalls multidimensional ist. Somit ist <strong>eine</strong> neuerliche<br />
Datenmodellierung nicht erforderlich.<br />
Von <strong>eine</strong>m logischen bzw. physischen Betrachtungsstandpunkt aus gibt es ein breites Spektrum<br />
an Speichermöglichkeiten in <strong>eine</strong>m Data-Warehouse-System: Logisch kann das Datenmodell<br />
z. B. relational (ROLAP 3 ) oder multidimensional (MOLAP 4 ) sein; für relationale Datenbanken kann<br />
z. B. ein Snowflake-, Stern- oder erweitertes Sternschema verwendet werden (siehe [12]). Physisch<br />
können verschiedenste DBMS-Technologien eingesetzt werden.<br />
2 Die Unterscheidung zwischen konzeptueller, logischer und physischer Betrachtung <strong>von</strong> Datenmodellen im Data Warehouse ist u.<br />
a. beschrieben in [2].<br />
3 ROLAP = Relational OnLine Analytical Processing.<br />
4 MOLAP = Multidimensional OnLine Analytical Processing.<br />
c○ Gunnar Harde 2001 3
<strong>XCube</strong>: <strong>Konzepte</strong> für ein Data-Warehouse-Netzwerk<br />
2.2 Anwendungsfall ” Query“: Online-Analyse <strong>von</strong> Web Cubes<br />
Anstatt den gesamten Web Cube einschließlich aller Bewegungsdaten herunterzuladen, sollte es<br />
auch möglich sein, Web Cubes online zu analysieren.<br />
In diesem Fall würden lediglich die Schemabeschreibung und die Stammdaten vom Webserver<br />
heruntergeladen werden, um so sicherzustellen, dass die gewünschten Datenanfragen an den Web<br />
Cube effektiv generiert werden können (siehe Abb. 2).<br />
web server<br />
1. schema<br />
2. master data<br />
3. query<br />
4. transaction data<br />
Abbildung 2. Anwendungsfall ” Query“.<br />
data warehouse<br />
Auch hier ist der kritische Punkt das Anpassen der Entitäten wie bereits in Abschnitt 2.1 beschrieben<br />
(siehe auch Abschnitt 2.5).<br />
Das Ergebnis <strong>eine</strong>r erfolgreichen Anfrage ist <strong>eine</strong> Untermenge der Bewegungsdaten, die auf dem<br />
Webserver gespeichert sind; das Datenformat der Anfrage ist identisch mit dem der gespeicherten<br />
Bewegungsdaten.<br />
Haben sich die Stamm- und die entsprechenden Bewegungsdaten, die auf dem Webserver abgelegt<br />
sind, nach dem initialen Herunterladen der Schemabeschreibung geändert, so kann der Konflikt,<br />
der aus der Abfrage nicht mehr gültiger Daten resultiert, abgefangen und ein Update der clientseitig<br />
gespeicherten Stammdaten angestoßen werden.<br />
Durch die Generierung <strong>von</strong> Anfragen und dem Laden nur der gerade benötigten Daten wird sowohl<br />
die Netzlast als auch die Datenredundanz verringert und die Daten sind jederzeit aktuell. Demgegenüber<br />
kann <strong>eine</strong> Datenanalyse nur online erfolgen, womit sich die Performance verschlechtert.<br />
Insbesondere wenn komplexe Analyseverfahren wie Data Mining zum Einsatz kommen sollen, wäre<br />
die Download-Variante ggf. vorzuziehen.<br />
Die obige <strong>Beschreibung</strong> bezieht sich primär auf den Fall, bei dem die extrahierten Daten direkt<br />
<strong>von</strong> <strong>eine</strong>m Analyse-Tool (z. B. Reporting-, OLAP- oder Data Mining-Tools) ausgewertet werden.<br />
Wenn das Anfrageergebnis in <strong>eine</strong>m Data Warehouse gespeichert werden soll, so ist das Vorgehen<br />
äquivalent zu dem des Anwendungsfalls ” Download“, wobei jedoch nur die angefragten Bewegungsdaten<br />
heruntergeladen und integriert werden. Der Anwendungsfall ” Query“ kann somit als<br />
Verallgem<strong>eine</strong>rung der Download-Variante betrachtet werden, bei dem sich das Datenvolumen skalieren<br />
lässt.<br />
2.3 Anwendungsfall ” Generation“: Konvertieren <strong>von</strong> Daten in <strong>eine</strong>n formatierten Web<br />
Cube<br />
Der Anwendungsfall ” Generation“ konvertiert Daten, die in <strong>eine</strong>m beliebigen Format und in <strong>eine</strong>m<br />
beliebigen Speichermedium vorliegen, in <strong>eine</strong>n Web Cube. Der generierte Web Cube kann dann auf<br />
<strong>eine</strong>m Webserver abgelegt und <strong>von</strong> dort heruntergeladen (siehe Abschnitt 2.1) und/oder analysiert<br />
(siehe Abschnitt 2.2) werden.<br />
Die zu konvertierenden Daten können in jeder Art <strong>von</strong> Datenbank oder Datei gespeichert sein;<br />
ebenso kann ein beliebiges Datenschema zugrunde liegen.<br />
Eine Konvertierung solcher Daten in <strong>eine</strong> Repräsentation, die auf <strong>eine</strong>m multidimensionalen<br />
Datenmodell beruht, erfordert dasselbe aufwendige Vorgehen für die Modellierung und Integration<br />
wie bei <strong>eine</strong>r Datenmigration in ein konventionelles Data Warehouse.<br />
c○ Gunnar Harde 2001 4
<strong>XCube</strong>: <strong>Konzepte</strong> für ein Data-Warehouse-Netzwerk<br />
Ein besonderer Fall ist die Konvertierung <strong>von</strong> Daten, die bereits in <strong>eine</strong>m Data Warehouse<br />
gespeichert sind. Aus konzeptueller Sicht liegen die Daten bereits in <strong>eine</strong>m multidimensionalen<br />
Datenschema vor; <strong>eine</strong> erneute Modellierung ist somit nicht erforderlich. Jedoch muss das<br />
Konvertierungs-Tool an das logische Datenschema und das DBMS des Data Warehouses angepasst<br />
werden.<br />
Oftmals dürfte es erforderlich sein, dass nicht alle Daten, die in <strong>eine</strong>m <strong>Datenw</strong>ürfel des Data-<br />
Warehouse-Systems gespeichert sind, sondern nur <strong>eine</strong> Teilmenge <strong>von</strong> <strong>eine</strong>m Webserver als Web<br />
Cube abrufbar sein sollen. Eine praktikable Lösung wäre die Erstellung <strong>eine</strong>s Data Marts, der genau<br />
die selektierten Daten enthält (siehe Abb. 3).<br />
data warehouse<br />
data mart<br />
1. selection<br />
2. schema<br />
3. master data<br />
4. transaction data<br />
web server<br />
Abbildung 3. Beispiel des Anwendungsfalls ” Generation“.<br />
Eine Alternative zum Übertragen der Bewegungsdaten vom Data Warehouse zum Webserver<br />
wäre die Generierung <strong>von</strong> Anfragen (z. B. in SQL, falls die Daten in <strong>eine</strong>r relationalen Datenbank<br />
gespeichert sind), die die angeforderten Bewegungsdaten direkt vom Date Warehouse oder Data<br />
Mart lesen.<br />
2.4 Konzept ” Naming“: Identifizieren und Benennen <strong>von</strong> Web-Cube-Entitäten<br />
Jede Entität <strong>eine</strong>s Web Cubes (wie Fakten, Dimensionen oder der Web Cube selbst) erfordert <strong>eine</strong><br />
textuelle <strong>Beschreibung</strong>, damit sie <strong>von</strong> <strong>eine</strong>m (menschlichen) Anwender interpretiert werden kann.<br />
Im allgem<strong>eine</strong>n unterscheiden sich diese <strong>Beschreibung</strong>en für dieselbe Entität in den verschiedenen<br />
Sprachen, Branchen und Institutionen (so könnten z. B. die Begriffe ” Einkommen“ und ” Einkünfte“<br />
in unterschiedlichen Unternehmen dasselbe m<strong>eine</strong>n); oder ein Begriff hat unterschiedliche Bedeutungen<br />
(z. B. kann ” Jahr“ ” Geschäftsjahr“ oder ” Kalenderjahr“ bedeuten).<br />
Für <strong>eine</strong> erfolgreiche Integration der Daten <strong>eine</strong>s Web Cubes in ein existierendes Data Warehouse<br />
kann weder die textuelle <strong>Beschreibung</strong> noch der systemabhängige technische Name der Web-<br />
Cube-Entitäten verwendet werden. Statt dessen muss <strong>eine</strong> öffentliche Bezeichnung eingeführt werden.<br />
Dies würde ein aufwendiges Abgleichen der Entitäten bei der Integration überflüssig machen.<br />
Durch das Setzen <strong>von</strong> Attributen für jede textuelle <strong>Beschreibung</strong>, in denen Sprache, Branche und<br />
Institution definiert sind, lässt sich <strong>eine</strong> automatische Einspielung der clientseitig verwendeten Texte<br />
realisieren, falls <strong>eine</strong> Ressource 5 für das Anpassen referenziert werden kann (siehe Abschnitt 2.5).<br />
Diese Attributierung und die Einführung <strong>eine</strong>s öffentlichen Bezeichners erlauben zudem <strong>eine</strong><br />
effektive Suche <strong>von</strong> Web-Cube-Entitäten.<br />
2.5 Konzept ” Reference“: Referenzieren und Verknüpfen <strong>von</strong> Web-Cube-Entitäten<br />
Ein entwickeltes System <strong>von</strong> Bezeichnern für Web-Cube-Entitäten würde das Referenzieren und<br />
Verknüpfen dieser Entitäten ermöglichen. Der Datenaustausch zwischen <strong>eine</strong>m Server und <strong>eine</strong>m<br />
5 Eine Ressource ist definiert als ein bestimmtes Informationsobjekt im Internet.<br />
c○ Gunnar Harde 2001 5
<strong>XCube</strong>: <strong>Konzepte</strong> für ein Data-Warehouse-Netzwerk<br />
Client könnte somit zu <strong>eine</strong>m föderativen System, bei dem die Entitäten <strong>eine</strong>s Web Cubes auf mehreren<br />
Ressourcen verteilt sind, erweitert werden. Eine solche Föderation würde das essentielle Konzept<br />
für ein Data-Warehouse-Netzwerk bilden; die oben beschriebenen Anwendungsfälle könnten<br />
durch weitere Funktionen erweitert werden.<br />
Insbesondere <strong>eine</strong> Institution (wie z. B. <strong>eine</strong> Organisation für Standardisierung, die Holding<br />
mehrerer Tochterunternehmen oder der Anbieter <strong>von</strong> Data-Warehouse- oder ERP-Sytemen) könnte<br />
über <strong>eine</strong> URI vorkonfigurierte Web-Cube-Entitäten für Schemabeschreibung und/oder Stammdaten<br />
zur Verfügung stellen, die <strong>von</strong> anderen Web Cubes referenziert werden könnten.<br />
2.6 Anwendungsfall ” Initiation“: Aufbau <strong>eine</strong>s Web Warehouses<br />
Ein standardisiertes System für öffentliche Bezeichner <strong>von</strong> Web-Cube-Entitäten könnte auch für den<br />
Aufbau <strong>von</strong> konventionellen Data-Warehouse-Systemen verwendet werden. Die Schemabeschreibungen<br />
werden aus dem Internet heruntergeladen und in das Data Warehouse integriert. Ebenso<br />
könnten Stammdaten aus dem Internet bezogen und ggf. angepasst, oder aber aus dem eigenen<br />
operativen System geladen werden. Die dazugehörigen Bewegungsdaten werden schließlich aus<br />
operativen Systemen geladen (siehe Abb. 4).<br />
web server<br />
1. schema<br />
2. master data<br />
data warehouse<br />
3. transaction data<br />
2. master data<br />
operative system<br />
Abbildung 4. Anwendungsfall ” Initiation“.<br />
Ein solches Vorgehen beim Aufbau <strong>eine</strong>s Data Warehouses hätte zwei wichtige Vorteile:<br />
1. Entwickler könnten beim Aufbau <strong>eine</strong>s Data Warehouses auf bereits existierendes Wissen im<br />
WWW zurückgreifen. So könnten z. B. gerade ERP-Anbieter Web-Cube-Schemata über das<br />
WWW anbieten, die den Geschäftsinhalten ihrer ERP-Systeme entsprechen würden.<br />
2. Die <strong>Datenw</strong>ürfel des Data Warehouses würden dem Web-Cube-Standard entsprechen. Später<br />
heruntergeladene Web Cubes könnten leicht in das Data Warehouse integriert werden. Ebenso<br />
leicht wäre die Generierung <strong>von</strong> Web Cubes aus dem Data Warehouse heraus.<br />
2.7 Weitere Anwendungsfälle<br />
Weitere Anwendungsfälle könnten die oben beschriebenen Anwendungsfälle sinnvoll ergänzen.<br />
Denkbar wären Zahlungssysteme für das Herunterladen und/oder Abonnieren <strong>von</strong> Web Cubes; redaktionelle<br />
Zertifizierungssysteme, die die Richtigkeit der Daten bewerten; Zugriffsverwaltungssysteme;<br />
oder die Spezifikation der Policy <strong>eine</strong>s Web-Cubes-Anbieters.<br />
3 Technische Anforderungen an ein Web-Cube-Format und <strong>XML</strong><br />
Im vorhergehenden Abschnitt 2 wurden die konzeptionellen Anforderungen an ein föderatives Data-<br />
Warehouse-Netzwerk beschrieben. Die technischen Anforderungen an das Web-Cube-Format lassen<br />
sich daraus ableiten:<br />
1. Das Format soll ein multidimensionales Datenschema unterstützen können.<br />
c○ Gunnar Harde 2001 6
<strong>XCube</strong>: <strong>Konzepte</strong> für ein Data-Warehouse-Netzwerk<br />
2. Die konzeptionelle Unterscheidung zwischen Schemabeschreibung, Stamm- und Bewegungsdaten<br />
soll technisch unterstützt werden.<br />
3. Das Format für diese Entitäten soll via Internet übertragen werden können.<br />
4. Das Format soll aufgrund des Referenz-<strong>Konzepte</strong>s Linking-Technologien unterstützen.<br />
5. Das Format soll <strong>eine</strong> einfache Erweiterung um andere <strong>Konzepte</strong>, wie in Abschnitt 2.7 aufgelistet,<br />
ermöglichen.<br />
6. Ein einfacher und flexibler Konvertierungsmechanismus zur Verarbeitung der Web-Cube-Daten<br />
durch <strong>eine</strong>n Anwender und zur visuellen Darstellung dieser Daten soll bereitgestellt werden 6 .<br />
7. Das Format soll sich einfach aus bestehende Datenbanken extrahieren bzw. in <strong>eine</strong> Datenbank<br />
ablegen lassen.<br />
8. Es soll <strong>eine</strong> Online-Analyse der Web Cubes möglich sein, d. h. OLAP-Funktionalität soll unterstützt<br />
werden.<br />
Aufgrund der Anforderungen eins bis sechs bietet sich die Extensible Markup Language (<strong>XML</strong>)<br />
als Metaformat an (siehe [5]): <strong>XML</strong> ist für das Internet entwickelt worden; die XLink- und XPointer-<br />
<strong>Konzepte</strong> erlauben <strong>eine</strong> Verknüpfung <strong>von</strong> Ressourcen (siehe [8] und [7]); <strong>XML</strong> erlaubt die Kombination<br />
verschiedener Schemata; und in Kombination mit <strong>eine</strong>r Stylesheet-Sprache wie XSL kann<br />
das Format in modernen Web-Browsern dargestellt bzw. einfach in HTML oder ein anderes Format<br />
konvertiert werden (siehe [1]). Um das Einbinden <strong>von</strong> Web Cubes in <strong>eine</strong> HTML-Seite zu ermöglichen<br />
ohne das HTML-Layout im Browser zu verändern, sollte jedoch sichergestellt werden, dass<br />
die Elemente k<strong>eine</strong> Texte als Kindknoten besitzen. Die Erfüllung der ersten beiden Anforderungen<br />
ist durch <strong>XML</strong> ohnehin gewährleistet.<br />
Die Anbindungsmöglichkeit <strong>von</strong> <strong>XML</strong> an <strong>eine</strong> Datenbank hängt <strong>von</strong> dem Datenmodell der Datenbank<br />
ab. Verschiedene Ansätze dazu sind in [4] beschrieben. Da es sich bei <strong>eine</strong>r <strong>XML</strong>-Repräsentation<br />
des Web Cubes um ein datenzentrisches (engl. data-centric) Dokument handelt 7 und sowohl<br />
das Schema der Datenbank als auch das Schema des <strong>XML</strong>-Dokuments bekannt sind, wäre das Datenmapping<br />
modellgetrieben.<br />
Um die achte Anforderung - das Analysieren der Web Cubes online - zu erfüllen, sind mehrere<br />
Ansätze möglich: Erstens, für die Anfragen werden Queries in <strong>eine</strong>m Format generiert, die k<strong>eine</strong><br />
OLAP-spezifischen Anfragekonstrukte erlauben. Dafür würden mehrere <strong>XML</strong>-Anfragesprachen<br />
wie z. B. XQuery (siehe [6]), die jedoch derzeit alle nicht den Status <strong>eine</strong>r Recommendation haben,<br />
in Frage kommen. Zweitens, ein Format zur Definition <strong>von</strong> OLAP-spezifischen Queries auf<br />
Basis <strong>von</strong> <strong>XML</strong> wird definiert. Diese Query wird dann mit Hilfe <strong>von</strong> XSLT z. B. in XQuery konvertiert<br />
oder aber, drittens, direkt vom Webserver interpretiert und verarbeitet. Hierzu sind weitere<br />
Untersuchungen notwendig.<br />
4 <strong>XCube</strong><br />
4.1 <strong>XCube</strong>-Konzeption<br />
<strong>XCube</strong> stellt <strong>eine</strong> Sammlung verschiedener <strong>XML</strong>-<strong>basierte</strong>r Datenformate zur Umsetzung der in<br />
den Abschnitten 2 und 3 beschriebenen Anforderungen dar. Im vorliegenden Abschnitt wird der<br />
derzeitige Stand der Entwicklung <strong>von</strong> <strong>XCube</strong> erläutert; die Spezifizierung ist zum jetzigen Zeitpunkt<br />
noch nicht abgeschlossen. Die aktuelle Version ist 0.3.<br />
<strong>XCube</strong> umfasst die <strong>XML</strong>-Formate <strong>XCube</strong>Schema zur <strong>Beschreibung</strong> des multidimensionalen<br />
Schemas, <strong>XCube</strong>Master zur <strong>Beschreibung</strong> der Stammdaten sowie <strong>XCube</strong>Data zur <strong>Beschreibung</strong><br />
der Bewegungsdaten.<br />
6<br />
Diese Anforderung ist notwendig, wenn z. B. Informationen über <strong>eine</strong>n Web Cube in <strong>eine</strong>m Web-Browser angezeigt werden<br />
sollen.<br />
7<br />
Die textuelle <strong>Beschreibung</strong>en der Web-Cube-Entitäten sind dokumentzentrisch (engl. document-centric) und können gemischten<br />
Inhalt (engl. mixed content) enthalten. Dennoch bleibt der generelle datenzentrische Charakter des gesamten <strong>XML</strong>-Dokumentes<br />
erhalten, da jeder Textbaustein opak (engl. opaquely) in die relationale Datenbank gespeichert werden kann.<br />
c○ Gunnar Harde 2001 7
<strong>XCube</strong>: <strong>Konzepte</strong> für ein Data-Warehouse-Netzwerk<br />
Als Modell zur <strong>Beschreibung</strong> des multidimensionalen Schemas durch <strong>XCube</strong>Schema liegt die<br />
Multidimensional Modeling Language (MML) zugrunde, die ausführlich in [10] beschrieben ist.<br />
Weiterhin gehört zu <strong>XCube</strong> das <strong>XML</strong>-Format <strong>XCube</strong>Text, das die textuellen <strong>Beschreibung</strong>en<br />
der Entitäten <strong>von</strong> <strong>XCube</strong>Schema und <strong>XCube</strong>Master enthält. Durch die Auslagerung der Texte in<br />
<strong>XCube</strong>Text soll sichergestellt werden, dass die Daten der Web Cubes zwischen unterschiedlichen<br />
Sprachen, Branchen, Institutionen und einzelnen Anwendern ausgetauscht werden können, ohne<br />
dass die Anwender auf die Verwendung der eigenen Sprache und Sprachgewohnheiten verzichten<br />
müssen.<br />
Geplant ist die Entwicklung weiterer <strong>XCube</strong>-Formate wie <strong>XCube</strong>Query zur Generierung <strong>von</strong><br />
<strong>XCube</strong>Data-Dateien, die die angefragten Daten als Teilmenge des Web Cubes enthalten, und<br />
<strong>XCube</strong>Access zur (client- und/oder serverseitigen) <strong>Beschreibung</strong> der Zugriffsrechte und des Monitorings<br />
des Web Cubes.<br />
4.2 <strong>XCube</strong>-Basis<br />
Der Aufbau <strong>eine</strong>s einfachen Web Cubes ist schematisch in Abb. 5 skizziert.<br />
(a)<br />
<br />
<br />
*<br />
*<br />
<br />
<br />
*<br />
<br />
<br />
*<br />
*<br />
<br />
<br />
*<br />
<br />
(b) (c)<br />
<br />
<br />
*<br />
<br />
*<br />
<br />
<br />
*<br />
<br />
*<br />
*<br />
<br />
<br />
<br />
<br />
<br />
(MML: MML-Diagramm)<br />
(MML: Fact-Class)<br />
(MML: Fact-Attribute)<br />
(MML: Additivity)<br />
(MML: Dimension)<br />
(MML: Dimensional-Class)<br />
(MML: Roll-Up)<br />
(MML: Dimensional-Attribute)<br />
*<br />
<br />
*<br />
*<br />
<br />
Abbildung 5. <strong>XCube</strong>-Aufbau zur <strong>Beschreibung</strong> <strong>eine</strong>s einfachen Web Cubes. Die <strong>Beschreibung</strong> erfolgt in den <strong>XML</strong>-<br />
Formaten <strong>XCube</strong>Schema (a), <strong>XCube</strong>Master (b) und <strong>XCube</strong>Data (c). Attribute der <strong>XML</strong>-Elemente sind in dieser und<br />
den folgenden Abbildungen nicht enthalten. Die Sterne an den Kanten zur Darstellung <strong>eine</strong>r Eltern-Kind-Beziehung<br />
zeigen <strong>eine</strong> 1:n-Kardinalität an. Neben der <strong>XCube</strong>Schema-Struktur sind in Klammern die Namen der entsprechenden<br />
Schemaobjekte angegeben, wie sie in der MML verwendet werden.<br />
c○ Gunnar Harde 2001 8<br />
<strong>XCube</strong>: <strong>Konzepte</strong> für ein Data-Warehouse-Netzwerk<br />
Die Schemabeschreibung enthält das Würfelschema mit den dazugehörigen Kenngrößen sowie<br />
das Klassifikationsschema mit den Klassifikationsstufen und deren Roll-Up-Beziehungen und Attribute.<br />
Die Zuordnung des Würfelschemas zu den basisgranularen Klassifikationsstufen erfolgt über<br />
das 〈dimension〉-Tag.<br />
In <strong>XCube</strong>Master sind die verwendeten Einheiten und Währungen in den 〈entry〉-Tags definiert.<br />
Die Klassifikationsknoten und Instanzen der dimensionalen Attribute werden in 〈node〉 bzw.<br />
〈attribute〉 festgelegt.<br />
Schließlich werden die Würfelzellen mit den Werten für die Kenngrößen und den basisgranularen<br />
Klassifikationsknoten der dazugehörigen Dimensionen in <strong>XCube</strong>Data definiert. 8<br />
4.3 <strong>XCube</strong>-Erweiterungen<br />
Multi-Cube<br />
In <strong>XCube</strong> können mehrere <strong>Datenw</strong>ürfel und Beziehungen zwischen diesen <strong>Datenw</strong>ürfeln spezifiziert<br />
werden (siehe Beispiel in Abb. 6). So kann ein <strong>Datenw</strong>ürfel aus weiteren <strong>Datenw</strong>ürfeln bestehen,<br />
ein Würfelschema kann Eigenschaften <strong>von</strong> <strong>eine</strong>m anderen Würfelschema erben und ein<br />
Würfelschema kann abstrakt sein.<br />
(a)<br />
(b)<br />
<br />
<br />
<br />
<br />
*<br />
<br />
<br />
<br />
<br />
<br />
<br />
Abbildung 6. Beispiel für <strong>XCube</strong>Schema (a) und <strong>XCube</strong>Data (b) mit <strong>eine</strong>m Multi-Cube. Ein ” sale“-Würfel enthält als<br />
Unterwürfel den ” soldProduct“-Würfel, der wiederum aus dem abstrakten ” product“-Würfel ererbte Kenngrößen und<br />
Beziehungen besitzt.<br />
Vererbte und abstrakte Klassifikationsstufen<br />
Ebenso wie Würfelschemata können Klassifikationsstufen vererbt und/oder abstrakt sein. Dies<br />
ermöglicht z. B. das Hinzufügen <strong>von</strong> Attributen, die lediglich für <strong>eine</strong> Teilmenge der zur Klassifikationsstufe<br />
gehörigen Knoten relevant ist.<br />
8 Die Zuordnung der Kenngrößen zu den Knoten ohne Angabe der Dimensionen wäre nicht immer eindeutig, da derselbe Knoten<br />
mehreren Dimensionen zugewiesen sein könnte.<br />
c○ Gunnar Harde 2001 9<br />
*<br />
<strong>XCube</strong>: <strong>Konzepte</strong> für ein Data-Warehouse-Netzwerk<br />
Datentypen und Einheiten<br />
Zur Festlegung der Datentypen für die Kenngrößen, den Klassifikationsknoten und Attributen werden<br />
die Datentypen, wie sie in <strong>XML</strong>-Schema spezifiziert sind (siehe [3]), verwendet. Zudem können<br />
beliebige Datentypen in <strong>XCube</strong>Schema durch die Verwendung <strong>von</strong> <strong>XML</strong>-Schema-〈simpleType〉 definiert<br />
werden (siehe Beispiel in Abb. 7).<br />
Die Definition der bzgl. <strong>eine</strong>s Einheitentyps erlaubten Einheiten bzw. Währungen erfolgt ebenfalls<br />
mit Hilfe des 〈simpleType〉-Elements <strong>von</strong> <strong>XML</strong>-Schema.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Abbildung 7. Beispiel <strong>eine</strong>r <strong>XCube</strong>Schema-Datei, in dem <strong>eine</strong> Währungskenngröße mit zwei Nachkommastellen deklariert<br />
wird.<br />
Additivität<br />
Für jede Kenngröße kann in <strong>XCube</strong>Schema angegeben werden, welche Aggregationsoperatoren<br />
bzgl. jeder einzelnen Dimension und ggf. Komposition erlaubt sind. Da oftmals die Additivität für<br />
alle oder die meisten Dimensionen (und Kompositionen) identisch ist, wird <strong>eine</strong> dimensions- bzw.<br />
kompositionsunabhängige Additivität definiert, die dann <strong>von</strong> den Angaben in 〈dimAdditivity〉 bzw.<br />
〈compAdditivity〉 überschrieben werden kann (siehe Abb. 8(a)).<br />
Abgeleitete Kenngrößen<br />
<strong>XCube</strong>Schema erlaubt die Definition <strong>von</strong> Kenngrößen, deren Werte aus denen anderer Kenngrößen<br />
berechnet werden (siehe Abb. 8(b)). Die Werte solcher Kenngrößen sind in <strong>XCube</strong>Data nicht enthalten.<br />
Fehlende Datensätze<br />
In <strong>XCube</strong>Schema kann festgelegt werden, wie fehlende Datensätze zu interpretieren sind, indem ein<br />
missingData-Attribute des 〈fact〉-Tags entsprechend gesetzt wird. Erlaubt sind die Werte ” nonEvent“<br />
für nicht eingetretene Ereignisse (Default-Wert), ” eventNotApplicable“ für nicht mögliche Ereignisse<br />
und ” eventNotKnown“ für nicht erfasste Ereignisse. Die in <strong>XCube</strong>Schema festgelegten Werte<br />
können in <strong>XCube</strong>Data überschrieben werden.<br />
c○ Gunnar Harde 2001 10
<strong>XCube</strong>: <strong>Konzepte</strong> für ein Data-Warehouse-Netzwerk<br />
(a) (b)<br />
<br />
*<br />
*<br />
<br />
<br />
<br />
<br />
<br />
*<br />
<br />
<br />
Abbildung 8. (a) Die Default-Additivität <strong>eine</strong>r Kenngröße kann für einzelne Dimensionen bzw. Kompositionen in <strong>XCube</strong>Schema<br />
überschrieben werden. (b) Die Berechnungsvorschrift zur Ermittlung <strong>von</strong> Kenngrößenwerte kann in <strong>XCube</strong>-<br />
Schema definiert werden.<br />
Schlüsselvergabe<br />
Um die Eindeutigkeit <strong>von</strong> Klassifikationsknoten zu gewährleisten, müssen ggf. die Schlüssel <strong>von</strong><br />
Knoten höherer Stufe mit berücksichtigt werden. So könnte z. B. die Artikelnummer nur eindeutig<br />
innerhalb <strong>eine</strong>r Produktkategorie sein. Um die globale Eindeutigkeit zu gewährleisten, müssen die<br />
zusätzlich benötigten Schlüssel durch das 〈addKey〉-Tag angegeben werden (siehe Abb. 9).<br />
(a) (b) (c)<br />
<br />
*<br />
<br />
<br />
*<br />
<br />
*<br />
<br />
<br />
*<br />
<br />
Abbildung 9. Weitere benötigte Schlüssel werden in <strong>XCube</strong>Schema deklariert (a) und müssen dann in <strong>XCube</strong>Master<br />
(b) und <strong>XCube</strong>Data (c) entsprechend referenziert werden.<br />
Verteiltes Roll-Up<br />
Um Daten aufzuaggregieren, die mehr als <strong>eine</strong>m Knoten der höheren Klassifikationsstufe zuzuordnen<br />
sind, gibt es neben dem 〈rollUp〉-Element das 〈sharedRollUp〉-Element (siehe Abb. 10). Die<br />
Gewichtungen werden für jeden Knoten im 〈to〉-Element durch das weight-Attribute festgelegt; bezogen<br />
auf die Klassifikationsstufe muss die Summe aller Gewichtungen 1.0 ergeben.<br />
(a) (b)<br />
<br />
*<br />
<br />
<br />
*<br />
<br />
*<br />
<br />
Abbildung 10. Verteilte Roll-Up-Beziehungen werden analog zu normalen Roll-Up-Beziehungen in <strong>XCube</strong>Schema<br />
deklariert (a) und in <strong>XCube</strong>Master mit den entsprechenden Gewichtungen definiert (b).<br />
c○ Gunnar Harde 2001 11
<strong>XCube</strong>: <strong>Konzepte</strong> für ein Data-Warehouse-Netzwerk<br />
Zeitdimension<br />
Die Zeitdimension erfordert <strong>eine</strong> gesonderte Betrachtung. Während Klassifikationsknoten anderer<br />
Dimensionen explizit definiert und mit Knoten der nächsthöheren Klassifikationsstufe explizit verknüpft<br />
sind, erfolgt dies für die Zeitdimension algorithmisch.<br />
Wird für die basisgranulare Klassifikationsstufe des 〈dimension〉-Elements in <strong>XCube</strong>Schema<br />
z. B. der <strong>XML</strong>-Schema-Datentyp mit ” date“ deklariert, so sind die Klassifikationsstufen ” Monat“<br />
und ” Jahr“ und deren Roll-Up-Beziehungen implizit mit deklariert; ein explizites Deklarieren und<br />
Definieren dieser Stufen in <strong>XCube</strong>Schema bzw. <strong>XCube</strong>Master ist nicht erforderlich.<br />
Komplizierter ist die Definition <strong>von</strong> zeitlichen Klassifikationsstufen, deren Datentyp nicht in<br />
<strong>XML</strong>-Schema vorgegeben sind. Solche Stufen müssen explizit in <strong>XCube</strong>Schema deklariert und<br />
deren Knoten und Roll-Up-Beziehungen mit Hilfe <strong>von</strong> Berechnungsvorschriften in <strong>XCube</strong>Master<br />
beschrieben werden (siehe Abb. 11).<br />
<br />
*<br />
<br />
*<br />
<br />
*<br />
<br />
<br />
Abbildung 11. Die Definition <strong>eine</strong>r Roll-Up-Beziehung in <strong>XCube</strong>Master erfolgt bei zeitlichen Klassifikationsstufen im<br />
Gegensatz zu anderen Stufen über die Zuweisung <strong>von</strong> Knotenbereichen und der Angabe <strong>eine</strong>r Berechnungsvorschrift.<br />
Klassifikationsänderungen<br />
Um das Hinzufügen, Umhängen und Löschen <strong>von</strong> Klassifikationsknoten zu ermöglichen, können<br />
für das 〈rollUp〉- und 〈sharedRollUp〉-Tag Werte der Attribute validSince und validUntil gesetzt<br />
werden.<br />
Weitere geplante Erweiterungen<br />
Neben den hier genannten Erweiterungen ist die Entwicklung <strong>eine</strong>s Linking-<strong>Konzepte</strong>s <strong>von</strong> <strong>XCube</strong>-<br />
Entitäten zur Unterstützung <strong>eine</strong>r föderativen Datenhaltung einzelner <strong>XCube</strong>-Dateien vorgesehen<br />
und geplant. Die Entwicklung <strong>von</strong> <strong>XCube</strong>Text und deren Verknüpfung zu <strong>XCube</strong>Schema und <strong>XCube</strong>Master<br />
ist derzeit noch nicht abgeschlossen.<br />
5 Verwandte Arbeiten<br />
Die Beschäftigung mit föderativen Data-Warehouse-Netzwerken und der dafür benötigten <strong>Beschreibung</strong><br />
<strong>von</strong> <strong>Datenw</strong>ürfel in <strong>XML</strong>, wie es in <strong>XCube</strong> geschieht, stellt nach dem Wissensstand des Autors<br />
<strong>eine</strong>n bisher noch kaum untersuchten Forschungsgegenstand dar.<br />
Eine ähnliche Zielsetzung wie <strong>XCube</strong> hat lediglich das Format MetaCube-X (siehe [13]).<br />
MetaCube-X unterscheidet sich jedoch <strong>von</strong> der hier vorgestellten <strong>XCube</strong>-Formulierung durch folgende<br />
Punkte:<br />
• Bewegungsdaten werden nicht beschrieben;<br />
• es erfolgt k<strong>eine</strong> Trennung zwischen Schemabeschreibung und Stammdaten;<br />
c○ Gunnar Harde 2001 12
<strong>XCube</strong>: <strong>Konzepte</strong> für ein Data-Warehouse-Netzwerk<br />
• es erfolgt k<strong>eine</strong> Trennung zwischen technischer und textueller <strong>Beschreibung</strong>;<br />
• es gibt Tags zur Spezifizierung <strong>von</strong> Klassifikationshierarchien, die Klassifikationsstufen enthalten,<br />
wodurch die Wiederverwertbarkeit dieser Stufen erschwert wird;<br />
• die in Abschnitt 4.3 vorgestellten Erweiterungen werden nicht unterstützt.<br />
Das Thema föderatives Data-Warehouse-Netzwerk steht zudem in Beziehung zu zwei aktuellen<br />
Forschungsgebieten im Data-Warehouse-Kontext:<br />
Um die Nutzung des Internets als Datenquelle für Data-Warehouse-Systeme geht es auch beim<br />
sogenannten ” Web Farming“, das ausführlich in [9] beschrieben ist. Im Gegensatz zum hier vorgestellten<br />
Ansatz sollen beim Web Farming sämtliche Daten des WWW als Daten für ein Data<br />
Warehouse genutzt werden können, d. h. das Ziel ist die Integrationsmöglichkeit sämtlicher im<br />
WWW existierender Formate. Die Vorteile <strong>eine</strong>s standardisierten Formates für WWW-Daten, die<br />
in ein Data Warehouse geladen werden sollen, gegenüber dem Web-Farming-Ansatz sind bereits in<br />
Abschnitt 1 dargelegt.<br />
Eine Standardisierung der Data-Warehouse-Daten ist auch Ziel des Common Warehouse Metamodel<br />
(CWM) der Object Management Group (OMG) (siehe [14]). Basierend auf der UML-<br />
Notation wird ein standardisiertes Modell zur <strong>Beschreibung</strong> <strong>von</strong> Data-Warehouse-Metadaten definiert.<br />
Stamm- und Bewegungsdaten werden nicht mit berücksichtigt. Hingegen gilt der CWM-<br />
Standard für alle Metadaten, die für ein Data Warehouse relevant sein können, also z. B. auch für<br />
Metadaten zur <strong>Beschreibung</strong> der Hard- und Software, des relationalen Datenmodells, der Transformationsvorschriften<br />
und der Datenextraktion. Das CWM beschreibt das Metamodell auf logischer<br />
Ebene. Zudem lässt sich das CWM um systemspezifische Module aus physischer Modellsicht<br />
ergänzen. Der Fokus <strong>von</strong> CWM ist somit <strong>eine</strong> systemnahe <strong>Beschreibung</strong> des Metamodells; der standardisierte<br />
Austausch <strong>von</strong> <strong>Datenw</strong>ürfel ist hingegen nicht Gegenstand des CWMs.<br />
6 Zusammenfassung<br />
In diesem Beitrag wurden mehrere Anwendungsfälle zur Nutzung <strong>eine</strong>s föderativen Data-<br />
Warehouse-Netzwerkes sowie unterstützende <strong>Konzepte</strong> beschrieben. Dabei wurde der Begriff ” Web<br />
Cube“ eingeführt und definiert.<br />
Die geschäftlichen Anforderungen an ein föderatives Data-Warehouse-Netzwerk wurden<br />
erläutert und als Basis für die Herleitung der technischen Anforderungen herangezogen. Dabei zeigte<br />
sich, dass sich <strong>XML</strong> als Metaformat zur Spezifizierung <strong>von</strong> Web Cubes und weiteren Dokumenten<br />
zur Bearbeitung <strong>von</strong> Web Cubes sehr gut eignet.<br />
Schließlich wurde der derzeitige Entwicklungsstand <strong>von</strong> <strong>XCube</strong>, <strong>eine</strong>r Realisierung der oben<br />
genannten Anforderungen in <strong>XML</strong>, vorgestellt.<br />
Literatur<br />
1. Adler, S., Berglund, A., Caruso, J., Deach, S., Grosso, P., Gutentag, E., Milowski, A., Parnell, S., Richman, J., Zilles,<br />
S.: Extensible Stylesheet Language (XSL) Version 1.0.<br />
http://www.w3.org/TR/2000/CR-xsl-20001121/. Rev. 2000-11-21.<br />
2. Bauer, A., Günzel, H. (Hrsg.): Data Warehouse Systeme: Architektur, Entwicklung, Anwendung. (2001)<br />
3. Biron, P. V., Malhotra, A.: <strong>XML</strong> Schema Part 2: Datatypes.<br />
http://www.w3.org/xmlschema-2/. Rev. 2001-05-02.<br />
4. Bourret, R.: <strong>XML</strong> Database Products.<br />
http://www.rpbourret.com/xml/<strong>XML</strong>AndDatabases.htm. Rev. 2000-11-29.<br />
5. Bray, T., Paoli, J., Sperberg-McQueen, C. M., Maler, E.: Extensible Markup Language (<strong>XML</strong>) 1.0 (Second Edition).<br />
http://www.w3.org/TR/2000/REC-xml-20001006. Rev. 2000-10-06.<br />
6. Chamberlin, D., Florescu, D., Robie, J., Siméon, J., Stefanescu, M.: XQuery: A Query Language for <strong>XML</strong>.<br />
http://www.w3.org/TR/2001/WD-xquery-20010215. Rev. 2001-02-15.<br />
7. DeRose, S., Maler, E., Daniel, R.: <strong>XML</strong> Pointer Language (XPointer) Version 1.0.<br />
http://www.w3.org/TR/2001/WD-xptr-20010108. Rev. 2001-01-08.<br />
c○ Gunnar Harde 2001 13
<strong>XCube</strong>: <strong>Konzepte</strong> für ein Data-Warehouse-Netzwerk<br />
8. DeRose, S., Maler, E., Orchard, D.: <strong>XML</strong> Linking Language (XLink) Version 1.0.<br />
http://www.w3.org/TR/2000/PR-xlink-20001220. Rev. 2000-12-20.<br />
9. Hackathorn, R. D.: Web Farming for the Data Warehouse. Morgan Kaufmann Publishers (1999)<br />
10. Harren, A.: Konzeptionelles Data Warehouse-Design. Diplomarbeit, Uni Oldenburg (Mai 1999).<br />
11. Kimball, R., Reeves, L., Ross, M., Thornthwaite, W.: The Data Warehouse Lifecycle Toolkit: Expert Methods for<br />
Designing, Developing, and Deploying Data Warehouses. Wiley (1998)<br />
12. Kurz, A.: Data Warehousing Enabling Technology. (1999)<br />
13. Nguyen, T. B., Tjoa, A M., Mangisengi, O.: MetaCube-X: An <strong>XML</strong> Metadata Foundation for Interoperability<br />
Search among Web Warehouses. Proceedings of the International Workshop on Design and Management of Data<br />
Warehouses (DMDW’2001).<br />
14. Object Management Group (OMG): Data Warehousing, CWM And MOF Resource Page.<br />
http://www.omg.org/technology/cwm/index.htm. Rev. 2001-07-10.<br />
15. Scott, W. A.: Mapping objects to relational databases: What you need to know and why.<br />
http://www-106.ibm.com/developerworks/library/mapping-to-rdb/. Rev. 2000-08-01.<br />
c○ Gunnar Harde 2001 14