XCube: Konzepte f¨ur eine XML-basierte Beschreibung von Datenw
Werbung
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, [email protected], WWW home page: http://www.OFFIS.DE Zusammenfassung Das World Wide Web wurde bisher kaum als Datenquelle für Data-WarehouseSysteme 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 XMLDateien 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-ChainManagements 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 data warehouse initial regular 3. transaction data Abbildung 1. Anwendungsfall Download“. ” Zunächst werden Schemabschreibung und Stammdaten heruntergeladen und in das MetadatenRepository 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 Sicht2 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 (ROLAP3 ) oder multidimensional (MOLAP4 ) 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 3 4 Die Unterscheidung zwischen konzeptueller, logischer und physischer Betrachtung von Datenmodellen im Data Warehouse ist u. a. beschrieben in [2]. ROLAP = Relational OnLine Analytical Processing. 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 data warehouse 3. query 4. transaction data Abbildung 2. Anwendungsfall Query“. ” 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 Bewe” gungsdaten 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 DataWarehouse-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). 2. schema 3. master data data mart 4. transaction data web server 1. selection data warehouse 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 WebCube-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 Ressource5 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 2. master data 3. transaction 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 DataWarehouse-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 werden6 . 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 XPointerKonzepte 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 handelt7 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 7 Diese Anforderung ist notwendig, wenn z. B. Informationen über einen Web Cube in einem Web-Browser angezeigt werden sollen. 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) <multidimensionalSchema> (MML: MML-Diagramm) <cubeSchema> * (MML: Fact-Class) (MML: Fact-Attribute) <fact> (MML: Additivity) <defaultAdditivity> * * <aggregation> (MML: Dimension) <dimension> <classSchema> * (MML: Dimensional-Class) <classLevel> * <rollUp> (MML: Roll-Up) * <attribute> (MML: Dimensional-Attribute) (b) (c) <cubeData> <masterData> <cube> <units> * * <entry> <classification> * <level> * <cell> * <dimension> * <fact> <node> * <attribute> * <rollUp> Abbildung 5. XCube-Aufbau zur Beschreibung eines einfachen Web Cubes. Die Beschreibung erfolgt in den XMLFormaten 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) <multidimensionalSchema> <multiCubeSchema> <cubeSchema id=„sale“> <isComposedBy cubeSchema=„soldProduct“/> <cubeSchema id=„soldProduct“ inheritedFrom=„product“> <cubeSchema id=„product“ abstract=„true“> (b) <cubeData> <cube id=„sale“> * <cell> <cube id=„soldProduct“> * <cell> 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. <multidimensionalSchema> <cubeSchema> <fact dataType=„decimalF2“ unitType=„currency“> <dataTypes> <dataType name=„decimalF2“ xmlns:xs=„http://www.w3.org/2001/XMLSchema“> <xs:restriction base=„xs:decimal“> <xs:fractionDigits value=„2“/> <unitTypes> <unitType name=„currency“ xmlns:xs=„http://www.w3.org/2001/XMLSchema“> <xs:restriction base=„xs:string“> <xs:enumeration value=„EUR“/> <xs:enumeration value=„USD“/> 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 Ereig” nisse 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) <fact> <fact> <defaultAdditivity> * <computation> * <parameter> <dimAdditivity> <defaultAdditivity> * <compAdditivity> 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 XCubeSchema 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) <classLevel> (c) <node> <dimension> * * * <addKey> * <rollUp> <addKey> <addKey> 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) <classLevel> * <sharedRollUp> <node> * <sharedRollUp> * <to node weigth> 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). <classification> * <timeLevel> * <rollUp> * <nodeRange> <computation> 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 XCubeEntitä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 vor” gestellten 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 UMLNotation wird ein standardisiertes Modell zur Beschreibung von Data-Warehouse-Metadaten definiert. Stamm- und Bewegungsdaten werden nicht mit berücksichtigt. Hingegen gilt der CWMStandard 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 DataWarehouse-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
