XCube: Konzepte f¨ur eine XML-basierte Beschreibung von Datenw ...

XCube: Konzepte für eine XML-basierte
Beschreibung von Datenwürfeln zur Realisierung
eines föderativen Data-Warehouse-Netzwerkes
Gunnar Harde
Oldenburger Forschungs- und Entwicklungsinstitut
für Informatik-Werkzeuge und Systeme (OFFIS),
Escherweg 2, D-26121 Oldenburg, Germany,
gunnar.harde@OFFIS.DE,
WWW home page: http://www.OFFIS.DE
Zusammenfassung Das World Wide Web wurde bisher kaum als Datenquelle für Data-Warehouse-
Systeme verwendet. In diesem Beitrag1 wird ein Konzept vorgestellt, das die Potentiale des WWW und
des Data Warehouses durch die Einführung standardisierter, im Web abrufbarer Datenwürfel - sogenannte
” Web Cubes“ - zusammenführt. Die Einführung von Web Cubes ermöglicht den Aufbau eines föderativen
Data-Warehouse-Netzwerkes. Ein solches Netzwerk erlaubt den Austausch von ausgewählten Daten zwischen
Data-Warehouse-Systemen, die Online-Analyse von Webdaten mit Hilfe von OLAP-Technologie
und die Integration von Webdaten in ein Data Warehouse. Die geschäftlichen Anforderungen werden
durch Anwendungsfälle und diese unterstützende Konzepte beschrieben. Die technischen Anforderungen
werden daraus abgeleitet und die Verwendung von XML als Metaformat zur Beschreibung von Web Cubes
diskutiert. Schließlich wird der derzeitige Entwicklungsstand von XCube beschrieben. XCube stellt
eine Sammlung von XML-basierten Formaten dar, die sowohl Web Cubes selbst als auch Dokumente
zur Bearbeitung von Web Cubes spezifizieren. Als Basis für die Modellierung von XCube wurde die
Multidimensional Modeling Language (MML) verwendet.
1 Einleitung und Motivation
Data-Warehouse-Systeme haben in den letzten Jahren eine immer größere Verbreitung erlangt. In
vielen Unternehmen und anderen Institutionen sind sie inzwischen zum zentralen Bestandteil der
technologischen Unterstützung von Management-Entscheidungen geworden.
Die Ursprungsdaten für ein Data Warehouse stammen in der Regel aus den operativen Systemen
eines Unternehmens. Das World Wide Web (WWW) hingegen wurde bisher kaum als Datenquelle
genutzt.
Ein Grund dafür ist die unzureichende Struktur der im WWW abrufbaren Daten: Informationen
liegen dort in Form von HTML-Dateien ohne semantische Beschreibung oder aber als XML-
Dateien basierend auf unterschiedlichen Schemata vor; Informationen können ebenso in Bildern
unterschiedlicher Formate, Animationen oder sogar Geräuschen enthalten sein. Zudem unterscheidet
sich die Semantik der Daten im WWW im allgemeinen von der Semantik, wie sie im Data
Warehouse verwendet wird. Meint z. B. der Ausdruck ” Jahr“ ” Kalenderjahr“ oder ” Geschäftsjahr“?
Wenn es sich um ein Geschäftsjahr handelt, welche Geschäftsjahresvariante ist damit gemeint? Solange
es keine Referenz auf eine eindeutige Semantik gibt, ist das Laden der WWW-Daten in ein
Date Warehouse äußerst problematisch.
Aus diesen Gründen hätte eine Standardisierung des Datenformates von Daten, die von einem
Webserver zur Integration in ein Data-Warehouse-System herunterladbar sind, mehrere Vorteile:
• Der ETL-Prozess würde sich stark vereinfachen und entsprechende ETL-Werkzeuge wären
leichter zu realisieren. Anwender könnten sich somit auf die geschäftlichen Anforderungen konzentrieren;
technische Details zur Datenintegration würden in den Hintergrund treten.
1 Eingereicht und akzeptiert für den 5. Workshop ” Föderierte Datenbanken“ (FDBS 2001), Berlin, 11.-12.10.2001.

XCube: Konzepte für ein Data-Warehouse-Netzwerk
• Der Standard könnte an die Anforderungen an ein Data Warehouse angepasst werden. Der
Parsing- und Transformationsaufwand würde sich verringern und somit die Performance verbessern.
• Der Standard könnte sicher stellen, dass semantisch gleiche Daten aus unterschiedlichen Quellen
vergleichbar sind.
• Der Standard könnte andere Formate wie z. B. zur Zahlungsabwicklung oder zur redaktionellen
Qualitätssicherung durch ein Zertifizierungssystem mit integrieren.
• Der Standard könnte zur Vernetzung von unterschiedlichen Data-Warehouse-Sytemen verwendet
werden.
Durch die Verwendung eines solchen Standards für einen Data-Warehouse-optimierten Datenaustausch
wären eine Reihe von Anwendungen denkbar:
Beispiel 1. Der Betreiber eines elektronischen Marktplatzes bietet neben der Plattform für den Austausch
von Wirtschaftsgütern und Dienstleistungen auch eine Plattform zur Analyse von unternehmensübergreifenden
Daten an. Hierzu werden die Daten der einzelnen Data-Warehouse-Systeme
der Marktteilnehmer auch den anderen Teilnehmern in aggregierter Form zur Verfügung gestellt.
Einerseits wird dabei sichergestellt, dass die Unternehmen keine sensiblen Daten nach außen geben,
andererseits so viel Informationen zur Verfügung stellen, dass eine Optimierung des Supply-Chain-
Managements ermöglicht wird.
Beispiel 2. Nach der Fusion zweier Unternehmen soll das Topmanagement die Möglichkeit haben,
auf die bereits existierenden Data-Warehouse-Systeme beider Unternehmen zuzugreifen und die
dort abgelegten Daten zu analysieren. Dazu wird ein weiteres Data-Warehouse-System aufgebaut,
das mit den beiden vorhandenen Systemen vernetzt ist.
Beispiel 3. Ein Unternehmen beabsichtigt seine Produktpalette zu erweitern und möchte vorher das
Potential des neuen Marktsegments näher untersuchen. Dazu werden im Internet Marktdaten sowohl
zum bisherigen als auch zum neuen Markt eingekauft, die bisherigen Unternehmensdaten mit
diesen Markteinschätzungen abgeglichen und schließlich eine Prognose für das neue Marktsegment
erstellt.
Beispiel 4. Eine medizinische Forschungseinrichtung möchte die Ausbreitung von Epedemien untersuchen
und entschließt sich, ein Data-Warehouse-System als Basis für die Datenbestände zu
verwenden. Bei der Analyse werden diese Daten durch Daten über Bevölkerungszahlen, Klimabedingungen,
Einkommensverhältnisse, Statistiken über die ärztliche Versorgung in den einzelnen
Regionen etc. ergänzt. Diese Daten werden über das Internet von öffentlichen Stellen und anderen
Forschungseinrichtungen bereitgestellt.
Im Abschnitt 2 werden verschiedene Anwendungsfälle und unterstützende Konzepte für ein
föderatives Data-Warehouse-Netzwerk vorgestellt. Dieser Abschnitt spezifiziert die Anforderungen
an ein föderatives Data-Warehouse-Netzwerk aus geschäftlicher Sicht.
Im Abschnitt 3 werden die technischen Anforderungen aus den zuvor in Abschnitt 2 beschriebenen
Anwendungsfällen hergeleitet. Insbesondere wird die Verwendung von XML als Metaformat
zur Spezifizierung von Web Cubes diskutiert.
Der derzeitige Entwicklungsstand von XCube, einer XML-Spezifikation von Web Cubes, wird
in Abschnitt 4 vorgestellt.
2 Anwendungsfälle und unterstützende Konzepte
In diesem Abschnitt werden mehrere Anwendungsfälle sowie Konzepte, die eine praktikable Nutzung
dieser Anwendungsfälle unterstützen, vorgestellt. Diese Liste stellt eine Art Standbild der
derzeitigen Arbeiten dar; Erweiterungen und Detaillierungen sind in Zukunft möglich.
An dieser Stelle sei der Begriff ” Web Cube“ eingeführt:
c○ Gunnar Harde 2001 2

XCube: Konzepte für ein Data-Warehouse-Netzwerk
Definition 1. Ein Web Cube ist ein multidimensionaler Datenwürfel, der in einem standardisierten
Format vorliegt und über das WWW zugreifbar und herunterladbar ist. Ein Web Cube beinhaltet
sowohl die Schemabeschreibung als auch die Stamm- und Bewegungsdaten des Datenwürfels.
Stammdaten definieren die Klassifikationsknoten des Datenwürfels und die Einheiten der Kenngrößen,
während Bewegungsdaten aus Kenngrößenwerte bestehen, die den Dimensionen zugewiesen
sind. Die Schemabeschreibung stellt einen Teil der Metadaten des Data Warehouses dar (siehe
auch [11]).
2.1 Anwendungsfall ” Download“: Laden und Integrieren von Web Cubes
Ein Web Cube soll von einem Webserver geladen und in ein bestehendes Data Warehouse integriert
werden (siehe Abb. 1).
web server
1. schema
2. master data
initial
regular
3. transaction data
data warehouse
Abbildung 1. Anwendungsfall ” Download“.
Zunächst werden Schemabschreibung und Stammdaten heruntergeladen und in das Metadaten-
Repository bzw. in Stammdatentabellen abgelegt. Danach werden die Bewegungsdaten heruntergeladen
und in das Data Warehouse gespeichert.
Dieses Vorgehen ist unproblematisch, solange der geladene Web Cube nicht mit bereits existierenden
Datenwürfeln des Data Warehouses zusammengeführt oder verglichen werden soll. Andernfalls
müssen die Entitäten des Web Cubes mit denen des vorhandenen Datenwürfels gematched
werden oder die semantischen Beschreibungen der Entitäten beider Würfel können über einen eindeutigen
Bezeichner wie in Abschnitt 2.5 beschrieben referenziert werden.
Das Herunterladen und Integrieren des gesamten Web Cubes einschließlich der Bewegungsdaten
gewährleistet eine gute Performance beim Analysieren der Daten. Nachteilig hingegen ist, dass die
Daten des Web Cubes redundant vorliegen und somit bei der Datenanalyse nicht mehr aktuell sein
müssen. Zudem kann beim initialen Herunterladen aller Daten die Netzauslastung für bestimmte
Anwendungen unakzeptabel hoch sein.
Um eine einfache Integration des Web Cubes in ein Data Warehouse zu unterstützen, sollte der
Web Cube eine multidimensionale Datenstruktur aufweisen, da das Datenmodel des Data Warehouses
zumindest aus konzeptueller Sicht 2 ebenfalls multidimensional ist. Somit ist eine neuerliche
Datenmodellierung nicht erforderlich.
Von einem logischen bzw. physischen Betrachtungsstandpunkt aus gibt es ein breites Spektrum
an Speichermöglichkeiten in einem Data-Warehouse-System: Logisch kann das Datenmodell
z. B. relational (ROLAP 3 ) oder multidimensional (MOLAP 4 ) sein; für relationale Datenbanken kann
z. B. ein Snowflake-, Stern- oder erweitertes Sternschema verwendet werden (siehe [12]). Physisch
können verschiedenste DBMS-Technologien eingesetzt werden.
2 Die Unterscheidung zwischen konzeptueller, logischer und physischer Betrachtung von Datenmodellen im Data Warehouse ist u.
a. beschrieben in [2].
3 ROLAP = Relational OnLine Analytical Processing.
4 MOLAP = Multidimensional OnLine Analytical Processing.
c○ Gunnar Harde 2001 3

XCube: Konzepte für ein Data-Warehouse-Netzwerk
2.2 Anwendungsfall ” Query“: Online-Analyse von Web Cubes
Anstatt den gesamten Web Cube einschließlich aller Bewegungsdaten herunterzuladen, sollte es
auch möglich sein, Web Cubes online zu analysieren.
In diesem Fall würden lediglich die Schemabeschreibung und die Stammdaten vom Webserver
heruntergeladen werden, um so sicherzustellen, dass die gewünschten Datenanfragen an den Web
Cube effektiv generiert werden können (siehe Abb. 2).
web server
1. schema
2. master data
3. query
4. transaction data
Abbildung 2. Anwendungsfall ” Query“.
data warehouse
Auch hier ist der kritische Punkt das Anpassen der Entitäten wie bereits in Abschnitt 2.1 beschrieben
(siehe auch Abschnitt 2.5).
Das Ergebnis einer erfolgreichen Anfrage ist eine Untermenge der Bewegungsdaten, die auf dem
Webserver gespeichert sind; das Datenformat der Anfrage ist identisch mit dem der gespeicherten
Bewegungsdaten.
Haben sich die Stamm- und die entsprechenden Bewegungsdaten, die auf dem Webserver abgelegt
sind, nach dem initialen Herunterladen der Schemabeschreibung geändert, so kann der Konflikt,
der aus der Abfrage nicht mehr gültiger Daten resultiert, abgefangen und ein Update der clientseitig
gespeicherten Stammdaten angestoßen werden.
Durch die Generierung von Anfragen und dem Laden nur der gerade benötigten Daten wird sowohl
die Netzlast als auch die Datenredundanz verringert und die Daten sind jederzeit aktuell. Demgegenüber
kann eine Datenanalyse nur online erfolgen, womit sich die Performance verschlechtert.
Insbesondere wenn komplexe Analyseverfahren wie Data Mining zum Einsatz kommen sollen, wäre
die Download-Variante ggf. vorzuziehen.
Die obige Beschreibung bezieht sich primär auf den Fall, bei dem die extrahierten Daten direkt
von einem Analyse-Tool (z. B. Reporting-, OLAP- oder Data Mining-Tools) ausgewertet werden.
Wenn das Anfrageergebnis in einem Data Warehouse gespeichert werden soll, so ist das Vorgehen
äquivalent zu dem des Anwendungsfalls ” Download“, wobei jedoch nur die angefragten Bewegungsdaten
heruntergeladen und integriert werden. Der Anwendungsfall ” Query“ kann somit als
Verallgemeinerung der Download-Variante betrachtet werden, bei dem sich das Datenvolumen skalieren
lässt.
2.3 Anwendungsfall ” Generation“: Konvertieren von Daten in einen formatierten Web
Cube
Der Anwendungsfall ” Generation“ konvertiert Daten, die in einem beliebigen Format und in einem
beliebigen Speichermedium vorliegen, in einen Web Cube. Der generierte Web Cube kann dann auf
einem Webserver abgelegt und von dort heruntergeladen (siehe Abschnitt 2.1) und/oder analysiert
(siehe Abschnitt 2.2) werden.
Die zu konvertierenden Daten können in jeder Art von Datenbank oder Datei gespeichert sein;
ebenso kann ein beliebiges Datenschema zugrunde liegen.
Eine Konvertierung solcher Daten in eine Repräsentation, die auf einem multidimensionalen
Datenmodell beruht, erfordert dasselbe aufwendige Vorgehen für die Modellierung und Integration
wie bei einer Datenmigration in ein konventionelles Data Warehouse.
c○ Gunnar Harde 2001 4

XCube: Konzepte für ein Data-Warehouse-Netzwerk
Ein besonderer Fall ist die Konvertierung von Daten, die bereits in einem Data Warehouse
gespeichert sind. Aus konzeptueller Sicht liegen die Daten bereits in einem multidimensionalen
Datenschema vor; eine erneute Modellierung ist somit nicht erforderlich. Jedoch muss das
Konvertierungs-Tool an das logische Datenschema und das DBMS des Data Warehouses angepasst
werden.
Oftmals dürfte es erforderlich sein, dass nicht alle Daten, die in einem Datenwürfel des Data-
Warehouse-Systems gespeichert sind, sondern nur eine Teilmenge von einem Webserver als Web
Cube abrufbar sein sollen. Eine praktikable Lösung wäre die Erstellung eines Data Marts, der genau
die selektierten Daten enthält (siehe Abb. 3).
data warehouse
data mart
1. selection
2. schema
3. master data
4. transaction data
web server
Abbildung 3. Beispiel des Anwendungsfalls ” Generation“.
Eine Alternative zum Übertragen der Bewegungsdaten vom Data Warehouse zum Webserver
wäre die Generierung von Anfragen (z. B. in SQL, falls die Daten in einer relationalen Datenbank
gespeichert sind), die die angeforderten Bewegungsdaten direkt vom Date Warehouse oder Data
Mart lesen.
2.4 Konzept ” Naming“: Identifizieren und Benennen von Web-Cube-Entitäten
Jede Entität eines Web Cubes (wie Fakten, Dimensionen oder der Web Cube selbst) erfordert eine
textuelle Beschreibung, damit sie von einem (menschlichen) Anwender interpretiert werden kann.
Im allgemeinen unterscheiden sich diese Beschreibungen für dieselbe Entität in den verschiedenen
Sprachen, Branchen und Institutionen (so könnten z. B. die Begriffe ” Einkommen“ und ” Einkünfte“
in unterschiedlichen Unternehmen dasselbe meinen); oder ein Begriff hat unterschiedliche Bedeutungen
(z. B. kann ” Jahr“ ” Geschäftsjahr“ oder ” Kalenderjahr“ bedeuten).
Für eine erfolgreiche Integration der Daten eines Web Cubes in ein existierendes Data Warehouse
kann weder die textuelle Beschreibung noch der systemabhängige technische Name der Web-
Cube-Entitäten verwendet werden. Statt dessen muss eine öffentliche Bezeichnung eingeführt werden.
Dies würde ein aufwendiges Abgleichen der Entitäten bei der Integration überflüssig machen.
Durch das Setzen von Attributen für jede textuelle Beschreibung, in denen Sprache, Branche und
Institution definiert sind, lässt sich eine automatische Einspielung der clientseitig verwendeten Texte
realisieren, falls eine Ressource 5 für das Anpassen referenziert werden kann (siehe Abschnitt 2.5).
Diese Attributierung und die Einführung eines öffentlichen Bezeichners erlauben zudem eine
effektive Suche von Web-Cube-Entitäten.
2.5 Konzept ” Reference“: Referenzieren und Verknüpfen von Web-Cube-Entitäten
Ein entwickeltes System von Bezeichnern für Web-Cube-Entitäten würde das Referenzieren und
Verknüpfen dieser Entitäten ermöglichen. Der Datenaustausch zwischen einem Server und einem
5 Eine Ressource ist definiert als ein bestimmtes Informationsobjekt im Internet.
c○ Gunnar Harde 2001 5

XCube: Konzepte für ein Data-Warehouse-Netzwerk
Client könnte somit zu einem föderativen System, bei dem die Entitäten eines Web Cubes auf mehreren
Ressourcen verteilt sind, erweitert werden. Eine solche Föderation würde das essentielle Konzept
für ein Data-Warehouse-Netzwerk bilden; die oben beschriebenen Anwendungsfälle könnten
durch weitere Funktionen erweitert werden.
Insbesondere eine Institution (wie z. B. eine Organisation für Standardisierung, die Holding
mehrerer Tochterunternehmen oder der Anbieter von Data-Warehouse- oder ERP-Sytemen) könnte
über eine URI vorkonfigurierte Web-Cube-Entitäten für Schemabeschreibung und/oder Stammdaten
zur Verfügung stellen, die von anderen Web Cubes referenziert werden könnten.
2.6 Anwendungsfall ” Initiation“: Aufbau eines Web Warehouses
Ein standardisiertes System für öffentliche Bezeichner von Web-Cube-Entitäten könnte auch für den
Aufbau von konventionellen Data-Warehouse-Systemen verwendet werden. Die Schemabeschreibungen
werden aus dem Internet heruntergeladen und in das Data Warehouse integriert. Ebenso
könnten Stammdaten aus dem Internet bezogen und ggf. angepasst, oder aber aus dem eigenen
operativen System geladen werden. Die dazugehörigen Bewegungsdaten werden schließlich aus
operativen Systemen geladen (siehe Abb. 4).
web server
1. schema
2. master data
data warehouse
3. transaction data
2. master data
operative system
Abbildung 4. Anwendungsfall ” Initiation“.
Ein solches Vorgehen beim Aufbau eines Data Warehouses hätte zwei wichtige Vorteile:
1. Entwickler könnten beim Aufbau eines Data Warehouses auf bereits existierendes Wissen im
WWW zurückgreifen. So könnten z. B. gerade ERP-Anbieter Web-Cube-Schemata über das
WWW anbieten, die den Geschäftsinhalten ihrer ERP-Systeme entsprechen würden.
2. Die Datenwürfel des Data Warehouses würden dem Web-Cube-Standard entsprechen. Später
heruntergeladene Web Cubes könnten leicht in das Data Warehouse integriert werden. Ebenso
leicht wäre die Generierung von Web Cubes aus dem Data Warehouse heraus.
2.7 Weitere Anwendungsfälle
Weitere Anwendungsfälle könnten die oben beschriebenen Anwendungsfälle sinnvoll ergänzen.
Denkbar wären Zahlungssysteme für das Herunterladen und/oder Abonnieren von Web Cubes; redaktionelle
Zertifizierungssysteme, die die Richtigkeit der Daten bewerten; Zugriffsverwaltungssysteme;
oder die Spezifikation der Policy eines Web-Cubes-Anbieters.
3 Technische Anforderungen an ein Web-Cube-Format und XML
Im vorhergehenden Abschnitt 2 wurden die konzeptionellen Anforderungen an ein föderatives Data-
Warehouse-Netzwerk beschrieben. Die technischen Anforderungen an das Web-Cube-Format lassen
sich daraus ableiten:
1. Das Format soll ein multidimensionales Datenschema unterstützen können.
c○ Gunnar Harde 2001 6

XCube: Konzepte für ein Data-Warehouse-Netzwerk
2. Die konzeptionelle Unterscheidung zwischen Schemabeschreibung, Stamm- und Bewegungsdaten
soll technisch unterstützt werden.
3. Das Format für diese Entitäten soll via Internet übertragen werden können.
4. Das Format soll aufgrund des Referenz-Konzeptes Linking-Technologien unterstützen.
5. Das Format soll eine einfache Erweiterung um andere Konzepte, wie in Abschnitt 2.7 aufgelistet,
ermöglichen.
6. Ein einfacher und flexibler Konvertierungsmechanismus zur Verarbeitung der Web-Cube-Daten
durch einen Anwender und zur visuellen Darstellung dieser Daten soll bereitgestellt werden 6 .
7. Das Format soll sich einfach aus bestehende Datenbanken extrahieren bzw. in eine Datenbank
ablegen lassen.
8. Es soll eine Online-Analyse der Web Cubes möglich sein, d. h. OLAP-Funktionalität soll unterstützt
werden.
Aufgrund der Anforderungen eins bis sechs bietet sich die Extensible Markup Language (XML)
als Metaformat an (siehe [5]): XML ist für das Internet entwickelt worden; die XLink- und XPointer-
Konzepte erlauben eine Verknüpfung von Ressourcen (siehe [8] und [7]); XML erlaubt die Kombination
verschiedener Schemata; und in Kombination mit einer Stylesheet-Sprache wie XSL kann
das Format in modernen Web-Browsern dargestellt bzw. einfach in HTML oder ein anderes Format
konvertiert werden (siehe [1]). Um das Einbinden von Web Cubes in eine HTML-Seite zu ermöglichen
ohne das HTML-Layout im Browser zu verändern, sollte jedoch sichergestellt werden, dass
die Elemente keine Texte als Kindknoten besitzen. Die Erfüllung der ersten beiden Anforderungen
ist durch XML ohnehin gewährleistet.
Die Anbindungsmöglichkeit von XML an eine Datenbank hängt von dem Datenmodell der Datenbank
ab. Verschiedene Ansätze dazu sind in [4] beschrieben. Da es sich bei einer XML-Repräsentation
des Web Cubes um ein datenzentrisches (engl. data-centric) Dokument handelt 7 und sowohl
das Schema der Datenbank als auch das Schema des XML-Dokuments bekannt sind, wäre das Datenmapping
modellgetrieben.
Um die achte Anforderung - das Analysieren der Web Cubes online - zu erfüllen, sind mehrere
Ansätze möglich: Erstens, für die Anfragen werden Queries in einem Format generiert, die keine
OLAP-spezifischen Anfragekonstrukte erlauben. Dafür würden mehrere XML-Anfragesprachen
wie z. B. XQuery (siehe [6]), die jedoch derzeit alle nicht den Status einer Recommendation haben,
in Frage kommen. Zweitens, ein Format zur Definition von OLAP-spezifischen Queries auf
Basis von XML wird definiert. Diese Query wird dann mit Hilfe von XSLT z. B. in XQuery konvertiert
oder aber, drittens, direkt vom Webserver interpretiert und verarbeitet. Hierzu sind weitere
Untersuchungen notwendig.
4 XCube
4.1 XCube-Konzeption
XCube stellt eine Sammlung verschiedener XML-basierter Datenformate zur Umsetzung der in
den Abschnitten 2 und 3 beschriebenen Anforderungen dar. Im vorliegenden Abschnitt wird der
derzeitige Stand der Entwicklung von XCube erläutert; die Spezifizierung ist zum jetzigen Zeitpunkt
noch nicht abgeschlossen. Die aktuelle Version ist 0.3.
XCube umfasst die XML-Formate XCubeSchema zur Beschreibung des multidimensionalen
Schemas, XCubeMaster zur Beschreibung der Stammdaten sowie XCubeData zur Beschreibung
der Bewegungsdaten.
6
Diese Anforderung ist notwendig, wenn z. B. Informationen über einen Web Cube in einem Web-Browser angezeigt werden
sollen.
7
Die textuelle Beschreibungen der Web-Cube-Entitäten sind dokumentzentrisch (engl. document-centric) und können gemischten
Inhalt (engl. mixed content) enthalten. Dennoch bleibt der generelle datenzentrische Charakter des gesamten XML-Dokumentes
erhalten, da jeder Textbaustein opak (engl. opaquely) in die relationale Datenbank gespeichert werden kann.
c○ Gunnar Harde 2001 7

XCube: Konzepte für ein Data-Warehouse-Netzwerk
Als Modell zur Beschreibung des multidimensionalen Schemas durch XCubeSchema liegt die
Multidimensional Modeling Language (MML) zugrunde, die ausführlich in [10] beschrieben ist.
Weiterhin gehört zu XCube das XML-Format XCubeText, das die textuellen Beschreibungen
der Entitäten von XCubeSchema und XCubeMaster enthält. Durch die Auslagerung der Texte in
XCubeText soll sichergestellt werden, dass die Daten der Web Cubes zwischen unterschiedlichen
Sprachen, Branchen, Institutionen und einzelnen Anwendern ausgetauscht werden können, ohne
dass die Anwender auf die Verwendung der eigenen Sprache und Sprachgewohnheiten verzichten
müssen.
Geplant ist die Entwicklung weiterer XCube-Formate wie XCubeQuery zur Generierung von
XCubeData-Dateien, die die angefragten Daten als Teilmenge des Web Cubes enthalten, und
XCubeAccess zur (client- und/oder serverseitigen) Beschreibung der Zugriffsrechte und des Monitorings
des Web Cubes.
4.2 XCube-Basis
Der Aufbau eines einfachen Web Cubes ist schematisch in Abb. 5 skizziert.
(a)
*
*
*
*
*
*
(b) (c)
*
*
*
*
*
(MML: MML-Diagramm)
(MML: Fact-Class)
(MML: Fact-Attribute)
(MML: Additivity)
(MML: Dimension)
(MML: Dimensional-Class)
(MML: Roll-Up)
(MML: Dimensional-Attribute)
*
*
*
Abbildung 5. XCube-Aufbau zur Beschreibung eines einfachen Web Cubes. Die Beschreibung erfolgt in den XML-
Formaten XCubeSchema (a), XCubeMaster (b) und XCubeData (c). Attribute der XML-Elemente sind in dieser und
den folgenden Abbildungen nicht enthalten. Die Sterne an den Kanten zur Darstellung einer Eltern-Kind-Beziehung
zeigen eine 1:n-Kardinalität an. Neben der XCubeSchema-Struktur sind in Klammern die Namen der entsprechenden
Schemaobjekte angegeben, wie sie in der MML verwendet werden.
c○ Gunnar Harde 2001 8

XCube: Konzepte für ein Data-Warehouse-Netzwerk
Die Schemabeschreibung enthält das Würfelschema mit den dazugehörigen Kenngrößen sowie
das Klassifikationsschema mit den Klassifikationsstufen und deren Roll-Up-Beziehungen und Attribute.
Die Zuordnung des Würfelschemas zu den basisgranularen Klassifikationsstufen erfolgt über
das 〈dimension〉-Tag.
In XCubeMaster sind die verwendeten Einheiten und Währungen in den 〈entry〉-Tags definiert.
Die Klassifikationsknoten und Instanzen der dimensionalen Attribute werden in 〈node〉 bzw.
〈attribute〉 festgelegt.
Schließlich werden die Würfelzellen mit den Werten für die Kenngrößen und den basisgranularen
Klassifikationsknoten der dazugehörigen Dimensionen in XCubeData definiert. 8
4.3 XCube-Erweiterungen
Multi-Cube
In XCube können mehrere Datenwürfel und Beziehungen zwischen diesen Datenwürfeln spezifiziert
werden (siehe Beispiel in Abb. 6). So kann ein Datenwürfel aus weiteren Datenwürfeln bestehen,
ein Würfelschema kann Eigenschaften von einem anderen Würfelschema erben und ein
Würfelschema kann abstrakt sein.
(a)
(b)
*
Abbildung 6. Beispiel für XCubeSchema (a) und XCubeData (b) mit einem Multi-Cube. Ein ” sale“-Würfel enthält als
Unterwürfel den ” soldProduct“-Würfel, der wiederum aus dem abstrakten ” product“-Würfel ererbte Kenngrößen und
Beziehungen besitzt.
Vererbte und abstrakte Klassifikationsstufen
Ebenso wie Würfelschemata können Klassifikationsstufen vererbt und/oder abstrakt sein. Dies
ermöglicht z. B. das Hinzufügen von Attributen, die lediglich für eine Teilmenge der zur Klassifikationsstufe
gehörigen Knoten relevant ist.
8 Die Zuordnung der Kenngrößen zu den Knoten ohne Angabe der Dimensionen wäre nicht immer eindeutig, da derselbe Knoten
mehreren Dimensionen zugewiesen sein könnte.
c○ Gunnar Harde 2001 9
*

XCube: Konzepte für ein Data-Warehouse-Netzwerk
Datentypen und Einheiten
Zur Festlegung der Datentypen für die Kenngrößen, den Klassifikationsknoten und Attributen werden
die Datentypen, wie sie in XML-Schema spezifiziert sind (siehe [3]), verwendet. Zudem können
beliebige Datentypen in XCubeSchema durch die Verwendung von XML-Schema-〈simpleType〉 definiert
werden (siehe Beispiel in Abb. 7).
Die Definition der bzgl. eines Einheitentyps erlaubten Einheiten bzw. Währungen erfolgt ebenfalls
mit Hilfe des 〈simpleType〉-Elements von XML-Schema.
Abbildung 7. Beispiel einer XCubeSchema-Datei, in dem eine Währungskenngröße mit zwei Nachkommastellen deklariert
wird.
Additivität
Für jede Kenngröße kann in XCubeSchema angegeben werden, welche Aggregationsoperatoren
bzgl. jeder einzelnen Dimension und ggf. Komposition erlaubt sind. Da oftmals die Additivität für
alle oder die meisten Dimensionen (und Kompositionen) identisch ist, wird eine dimensions- bzw.
kompositionsunabhängige Additivität definiert, die dann von den Angaben in 〈dimAdditivity〉 bzw.
〈compAdditivity〉 überschrieben werden kann (siehe Abb. 8(a)).
Abgeleitete Kenngrößen
XCubeSchema erlaubt die Definition von Kenngrößen, deren Werte aus denen anderer Kenngrößen
berechnet werden (siehe Abb. 8(b)). Die Werte solcher Kenngrößen sind in XCubeData nicht enthalten.
Fehlende Datensätze
In XCubeSchema kann festgelegt werden, wie fehlende Datensätze zu interpretieren sind, indem ein
missingData-Attribute des 〈fact〉-Tags entsprechend gesetzt wird. Erlaubt sind die Werte ” nonEvent“
für nicht eingetretene Ereignisse (Default-Wert), ” eventNotApplicable“ für nicht mögliche Ereignisse
und ” eventNotKnown“ für nicht erfasste Ereignisse. Die in XCubeSchema festgelegten Werte
können in XCubeData überschrieben werden.
c○ Gunnar Harde 2001 10

XCube: Konzepte für ein Data-Warehouse-Netzwerk
(a) (b)
*
*
*
Abbildung 8. (a) Die Default-Additivität einer Kenngröße kann für einzelne Dimensionen bzw. Kompositionen in XCubeSchema
überschrieben werden. (b) Die Berechnungsvorschrift zur Ermittlung von Kenngrößenwerte kann in XCube-
Schema definiert werden.
Schlüsselvergabe
Um die Eindeutigkeit von Klassifikationsknoten zu gewährleisten, müssen ggf. die Schlüssel von
Knoten höherer Stufe mit berücksichtigt werden. So könnte z. B. die Artikelnummer nur eindeutig
innerhalb einer Produktkategorie sein. Um die globale Eindeutigkeit zu gewährleisten, müssen die
zusätzlich benötigten Schlüssel durch das 〈addKey〉-Tag angegeben werden (siehe Abb. 9).
(a) (b) (c)
*
*
*
*
Abbildung 9. Weitere benötigte Schlüssel werden in XCubeSchema deklariert (a) und müssen dann in XCubeMaster
(b) und XCubeData (c) entsprechend referenziert werden.
Verteiltes Roll-Up
Um Daten aufzuaggregieren, die mehr als einem Knoten der höheren Klassifikationsstufe zuzuordnen
sind, gibt es neben dem 〈rollUp〉-Element das 〈sharedRollUp〉-Element (siehe Abb. 10). Die
Gewichtungen werden für jeden Knoten im 〈to〉-Element durch das weight-Attribute festgelegt; bezogen
auf die Klassifikationsstufe muss die Summe aller Gewichtungen 1.0 ergeben.
(a) (b)
*
*
*
Abbildung 10. Verteilte Roll-Up-Beziehungen werden analog zu normalen Roll-Up-Beziehungen in XCubeSchema
deklariert (a) und in XCubeMaster mit den entsprechenden Gewichtungen definiert (b).
c○ Gunnar Harde 2001 11

XCube: Konzepte für ein Data-Warehouse-Netzwerk
Zeitdimension
Die Zeitdimension erfordert eine gesonderte Betrachtung. Während Klassifikationsknoten anderer
Dimensionen explizit definiert und mit Knoten der nächsthöheren Klassifikationsstufe explizit verknüpft
sind, erfolgt dies für die Zeitdimension algorithmisch.
Wird für die basisgranulare Klassifikationsstufe des 〈dimension〉-Elements in XCubeSchema
z. B. der XML-Schema-Datentyp mit ” date“ deklariert, so sind die Klassifikationsstufen ” Monat“
und ” Jahr“ und deren Roll-Up-Beziehungen implizit mit deklariert; ein explizites Deklarieren und
Definieren dieser Stufen in XCubeSchema bzw. XCubeMaster ist nicht erforderlich.
Komplizierter ist die Definition von zeitlichen Klassifikationsstufen, deren Datentyp nicht in
XML-Schema vorgegeben sind. Solche Stufen müssen explizit in XCubeSchema deklariert und
deren Knoten und Roll-Up-Beziehungen mit Hilfe von Berechnungsvorschriften in XCubeMaster
beschrieben werden (siehe Abb. 11).
*
*
*
Abbildung 11. Die Definition einer Roll-Up-Beziehung in XCubeMaster erfolgt bei zeitlichen Klassifikationsstufen im
Gegensatz zu anderen Stufen über die Zuweisung von Knotenbereichen und der Angabe einer Berechnungsvorschrift.
Klassifikationsänderungen
Um das Hinzufügen, Umhängen und Löschen von Klassifikationsknoten zu ermöglichen, können
für das 〈rollUp〉- und 〈sharedRollUp〉-Tag Werte der Attribute validSince und validUntil gesetzt
werden.
Weitere geplante Erweiterungen
Neben den hier genannten Erweiterungen ist die Entwicklung eines Linking-Konzeptes von XCube-
Entitäten zur Unterstützung einer föderativen Datenhaltung einzelner XCube-Dateien vorgesehen
und geplant. Die Entwicklung von XCubeText und deren Verknüpfung zu XCubeSchema und XCubeMaster
ist derzeit noch nicht abgeschlossen.
5 Verwandte Arbeiten
Die Beschäftigung mit föderativen Data-Warehouse-Netzwerken und der dafür benötigten Beschreibung
von Datenwürfel in XML, wie es in XCube geschieht, stellt nach dem Wissensstand des Autors
einen bisher noch kaum untersuchten Forschungsgegenstand dar.
Eine ähnliche Zielsetzung wie XCube hat lediglich das Format MetaCube-X (siehe [13]).
MetaCube-X unterscheidet sich jedoch von der hier vorgestellten XCube-Formulierung durch folgende
Punkte:
• Bewegungsdaten werden nicht beschrieben;
• es erfolgt keine Trennung zwischen Schemabeschreibung und Stammdaten;
c○ Gunnar Harde 2001 12

XCube: Konzepte für ein Data-Warehouse-Netzwerk
• es erfolgt keine Trennung zwischen technischer und textueller Beschreibung;
• es gibt Tags zur Spezifizierung von Klassifikationshierarchien, die Klassifikationsstufen enthalten,
wodurch die Wiederverwertbarkeit dieser Stufen erschwert wird;
• die in Abschnitt 4.3 vorgestellten Erweiterungen werden nicht unterstützt.
Das Thema föderatives Data-Warehouse-Netzwerk steht zudem in Beziehung zu zwei aktuellen
Forschungsgebieten im Data-Warehouse-Kontext:
Um die Nutzung des Internets als Datenquelle für Data-Warehouse-Systeme geht es auch beim
sogenannten ” Web Farming“, das ausführlich in [9] beschrieben ist. Im Gegensatz zum hier vorgestellten
Ansatz sollen beim Web Farming sämtliche Daten des WWW als Daten für ein Data
Warehouse genutzt werden können, d. h. das Ziel ist die Integrationsmöglichkeit sämtlicher im
WWW existierender Formate. Die Vorteile eines standardisierten Formates für WWW-Daten, die
in ein Data Warehouse geladen werden sollen, gegenüber dem Web-Farming-Ansatz sind bereits in
Abschnitt 1 dargelegt.
Eine Standardisierung der Data-Warehouse-Daten ist auch Ziel des Common Warehouse Metamodel
(CWM) der Object Management Group (OMG) (siehe [14]). Basierend auf der UML-
Notation wird ein standardisiertes Modell zur Beschreibung von Data-Warehouse-Metadaten definiert.
Stamm- und Bewegungsdaten werden nicht mit berücksichtigt. Hingegen gilt der CWM-
Standard für alle Metadaten, die für ein Data Warehouse relevant sein können, also z. B. auch für
Metadaten zur Beschreibung der Hard- und Software, des relationalen Datenmodells, der Transformationsvorschriften
und der Datenextraktion. Das CWM beschreibt das Metamodell auf logischer
Ebene. Zudem lässt sich das CWM um systemspezifische Module aus physischer Modellsicht
ergänzen. Der Fokus von CWM ist somit eine systemnahe Beschreibung des Metamodells; der standardisierte
Austausch von Datenwürfel ist hingegen nicht Gegenstand des CWMs.
6 Zusammenfassung
In diesem Beitrag wurden mehrere Anwendungsfälle zur Nutzung eines föderativen Data-
Warehouse-Netzwerkes sowie unterstützende Konzepte beschrieben. Dabei wurde der Begriff ” Web
Cube“ eingeführt und definiert.
Die geschäftlichen Anforderungen an ein föderatives Data-Warehouse-Netzwerk wurden
erläutert und als Basis für die Herleitung der technischen Anforderungen herangezogen. Dabei zeigte
sich, dass sich XML als Metaformat zur Spezifizierung von Web Cubes und weiteren Dokumenten
zur Bearbeitung von Web Cubes sehr gut eignet.
Schließlich wurde der derzeitige Entwicklungsstand von XCube, einer Realisierung der oben
genannten Anforderungen in XML, vorgestellt.
Literatur
1. Adler, S., Berglund, A., Caruso, J., Deach, S., Grosso, P., Gutentag, E., Milowski, A., Parnell, S., Richman, J., Zilles,
S.: Extensible Stylesheet Language (XSL) Version 1.0.
http://www.w3.org/TR/2000/CR-xsl-20001121/. Rev. 2000-11-21.
2. Bauer, A., Günzel, H. (Hrsg.): Data Warehouse Systeme: Architektur, Entwicklung, Anwendung. (2001)
3. Biron, P. V., Malhotra, A.: XML Schema Part 2: Datatypes.
http://www.w3.org/xmlschema-2/. Rev. 2001-05-02.
4. Bourret, R.: XML Database Products.
http://www.rpbourret.com/xml/XMLAndDatabases.htm. Rev. 2000-11-29.
5. Bray, T., Paoli, J., Sperberg-McQueen, C. M., Maler, E.: Extensible Markup Language (XML) 1.0 (Second Edition).
http://www.w3.org/TR/2000/REC-xml-20001006. Rev. 2000-10-06.
6. Chamberlin, D., Florescu, D., Robie, J., Siméon, J., Stefanescu, M.: XQuery: A Query Language for XML.
http://www.w3.org/TR/2001/WD-xquery-20010215. Rev. 2001-02-15.
7. DeRose, S., Maler, E., Daniel, R.: XML Pointer Language (XPointer) Version 1.0.
http://www.w3.org/TR/2001/WD-xptr-20010108. Rev. 2001-01-08.
c○ Gunnar Harde 2001 13

XCube: Konzepte für ein Data-Warehouse-Netzwerk
8. DeRose, S., Maler, E., Orchard, D.: XML Linking Language (XLink) Version 1.0.
http://www.w3.org/TR/2000/PR-xlink-20001220. Rev. 2000-12-20.
9. Hackathorn, R. D.: Web Farming for the Data Warehouse. Morgan Kaufmann Publishers (1999)
10. Harren, A.: Konzeptionelles Data Warehouse-Design. Diplomarbeit, Uni Oldenburg (Mai 1999).
11. Kimball, R., Reeves, L., Ross, M., Thornthwaite, W.: The Data Warehouse Lifecycle Toolkit: Expert Methods for
Designing, Developing, and Deploying Data Warehouses. Wiley (1998)
12. Kurz, A.: Data Warehousing Enabling Technology. (1999)
13. Nguyen, T. B., Tjoa, A M., Mangisengi, O.: MetaCube-X: An XML Metadata Foundation for Interoperability
Search among Web Warehouses. Proceedings of the International Workshop on Design and Management of Data
Warehouses (DMDW’2001).
14. Object Management Group (OMG): Data Warehousing, CWM And MOF Resource Page.
http://www.omg.org/technology/cwm/index.htm. Rev. 2001-07-10.
15. Scott, W. A.: Mapping objects to relational databases: What you need to know and why.
http://www-106.ibm.com/developerworks/library/mapping-to-rdb/. Rev. 2000-08-01.
c○ Gunnar Harde 2001 14