Anforderungsanalyse und Konzeption einer RDF-basierten Metadaten-Verwaltung für Data-Warehouse-Systeme

Transkript

1 Anforderungsanalyse und Konzeption einer RDF-basierten Metadaten-Verwaltung für Data-Warehouse-Systeme Diplomarbeit im Studiengang Wirtschaftsinformatik in der Fakultät Wirtschaftsinformatik und Angewandte Informatik der Otto-Friedrich-Universität Bamberg vorgelegt von Martin Weber angefertigt am Lehrstuhl Wirtschaftsinformatik, insbesondere Systementwicklung und Datenbankanwendung Prüfer: Prof. Dr. Elmar J. Sinz Beginn der Arbeit: Abgabe der Arbeit:

2 Abstract Abteilungs- bzw. bereichsspezifische Data-Warehouse-Systeme (DWH-Systeme) haben sich in zahlreichen Unternehmen als bedeutende Informationssysteme etabliert. Diese Data-Warehouse (DWH)-Infrastruktur ist durch ein verschiedenartiges Verständnis der Fachbegriffe und durch unterschiedliche Datenschemata charakterisiert. Aufgrund struktureller und semantischer Heterogenität ist eine direkte Vergleichbarkeit von Berichten aus multiplen DWH-Systemen nicht gegeben. Bestehende Forschungsansätze versuchen dieser Problematik besonders auf struktureller Ebene entgegenzuwirken. Der in dieser Arbeit betrachtete Ansatz fokussiert vor allem semantische Aspekte bei der Beschreibung von DWH-Metadaten. Das Ziel dieser Diplomarbeit ist daher die Ermittlung von Metadaten-Kriterien für DWH- Systeme, welche eine semantisch homogene Beschreibung der Metadaten ermöglichen. Anschließend wird geprüft, ob das im Semantic Web etablierte Resource Description Framework (RDF) zur formalen und semantisch homogenen Beschreibung von DWH-Metadaten geeignet ist. Mit der RDF-Technologie kann ein Metadaten- Vokabular entwickelt werden, welches gemäß dem Kriterienkatalog neben syntaktischen vor allem semantische Aspekte einbezieht. Eine prototypische Realisierung dieses Metadaten-Vokabulars für DWH-Systeme zeigt die Funktionsfähigkeit des angefertigten RDF-Schemas (RDFS) anhand einer Fallstudie. Durch die eindeutige Definition von Klassen, Beziehungen und Built-in-Properties werden semantische Aspekte zum Ausdruck gebracht. Eine zentrale Ablage des RDFS unter einer öffentlichen Internetadresse führt dazu, dass beliebige Interessengruppen dieses nutzen können. Auf diese Weise können DWH-Metadaten syntaktisch standardisiert und semantisch modelliert als RDF-Dokument formuliert werden. Aufgrund der gemeinsamen Interpretationsgrundlage ist eine Vergleichbarkeit unterschiedlicher RDF-Dokumente gegeben. Die RDF-Technologie dient somit als wertvolles Instrument zur Unterstützung der Homogenisierung heterogener DWH-Systeme.

3 Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Abkürzungsverzeichnis iii v vi 1 Einleitung 1 2 Technologische Grundlagen der Metadaten-Verwaltung Grundlagen des Resource Description Framework Uniform Resource Identifier RDF-Datenmodell Serialisierung von RDF als XML Namespaces und QNames RDF-Typangabe RDF-Schema Dublin Core Data-Warehouse Grundlagen Metadaten im Data-Warehouse Anforderungen der Metadaten-Verwaltung in DWH-Systemen an das RDF Metadaten-Kriterien Der Kriterienkatalog Metadatenkategorie Terminologie Metadatenkategorie Datenstruktur und Datenbedeutung Metadatenkategorie Organisationsbezug Metadatenkategorie Datentransformation i

4 3.2.5 Metadatenkategorie Datenanalyse Metadatenkategorie Datenqualität Metadatenkategorie Metadatenhistorie Metadatenkategorie Systembezug Ein RDF-Schema zur semantisch homogenen Metadaten- Beschreibung eines DWH Das semantische Potential des RDF Beschreibung der Metadatenkategorie Datenanalyse im RDFS Beschreibung der Metadatenkategorie Organisationsbezug im RDFS Beschreibung der Metadatenkategorie Datentransformation im RDFS Beschreibung der Metadatenkategorie Datenstruktur und Datenbedeutung im RDFS Beschreibung der Metadatenkategorie Terminologie im RDF bzw. RDFS Beschreibung der Metadatenkategorie Datenqualität im RDFS Beschreibung der Metadatenkategorie Metadatenhistorie im RDFS Integrierte Gesamtsicht Prototypische Realisierung Fallstudie: DWH AZE AG RDF-Dokument RDF-Validierung Der RDF-Validator ICS-FORTH Validating RDF Parser Mindswap Convert To RDF Tool Framework Protégé Plugins Fazit Zusammenfassung und Ausblick 86 A Anhang 89 B Anhang 105 Literaturverzeichnis 120 ii

5 Abbildungsverzeichnis 2.1 RDF-Graph Überblick über die DWH-System-Architektur (Böhnlein & Ulbrich vom Ende, 2000, S. 17) Star Schema (Böhnlein & Ulbrich vom Ende, 2000) Snowflake Schema (Böhnlein & Ulbrich vom Ende, 2000) Die Gesamtsicht RDF-Schema RDF- und RDFS-Ebene SDWM-Notation: DWH AZE AG W3C RDF-Validator Ausschnitt aus dem Prüfungsergebnis des RDF-Dokuments ICS-FORTH VRP Bedienoberfläche VRP-Prüfungsergebnis Mindswap Convert To RDF Tool Protégé Projekt-Charakterisierung Protégé Hauptprogramm Reiter Classes Protégé Hauptprogramm Reiter Slots Reiter Instances Cube: DWH AZE AG Reiter Instances Dimension: Geographie Reiter Instances DHS: Zeit Tag Add Instance Protégé RDF-/RDFS-Dokument Export Aktivierung der Protégé Plugins Plugin TGViz: Bedienoberfläche Plugin OntoViz: Bedienoberfläche Plugin Jambalaya: Bedienoberfläche iii

6 A.1 Plugin TGViz: DWH AZE AG, Pfadtiefe A.2 Plugin TGViz: DWH AZE AG, Pfadtiefe A.3 Plugin TGViz: Sortiment, Pfadtiefe A.4 Plugin TGViz: Umsatzerloese, Pfadtiefe A.5 Plugin OntoViz: Kennzahlensystem A.6 Plugin OntoViz: Deckungsbeitrag A.7 Plugin OntoViz: Details zum Aufbau des DWH A.8 Plugin Jambalaya: Nested View A.9 Plugin Jambalaya: Nested Treemap A.10 Plugin Jambalaya: Class & Instance Tree A.11 Plugin Jambalaya: Class Tree A.12 Plugin Jambalaya: Kreisförmige Aufstellung der Klassen und ihrer Instanzen A.13 Plugin Jambalaya: Klassen geordnet nach der Anzahl ihrer Kinder A.14 Plugin Jambalaya: Klassen geordnet nach der Anzahl ihrer Beziehungen zu anderen Klassen A.15 Plugin Jambalaya: Klassen und Beziehungen zu anderen Klassen A.16 Plugin Jambalaya: Klassen und Instanzen mit ihren Beziehungen zu anderen Klassen bzw. Instanzen iv

7 Tabellenverzeichnis 3.1 RDF- und RDFS-Elemente in der Kategorie Terminologie RDF- und RDFS-Elemente in der Kategorie Datenstruktur und - bedeutung RDF- und RDFS-Elemente in der Kategorie Datenanalyse Abbildung von Datenqualitätsmerkmalen in der Kategorie Interpretierbarkeit auf der Ebene Datenschema im RDF bzw. RDFS (Helfert, 2002, S. 74) Abbildung von Datenqualitätsmerkmalen in der Kategorie Nützlichkeit (zweckbezogen) auf der Ebene Datenschema im RDFS (Helfert, 2002, S. 74) RDF- und RDFS-Elemente in der Kategorie Metadatenhistorie Eigenschaftstypen der Metadatenkategorie Datenanalyse im RDFS Eigenschaftstypen der Metadatenkategorie Datentransformation im RDFS Umsetzung der Metadatenkategorie Terminologie im RDF bzw. RDFS Umsetzung der Metadatenkategorie Datenanalyse im RDFS Abbildung der Metadatenkategorie Datenanalyse im RDFS Flatfile DWH-Metadaten Map File DWH-Metadaten v

8 Abkürzungsverzeichnis CHISEL Cube CWM DAML DBMS DC DHS DTD DWH DWH-System FORTH GUI ID OIL OKBC OWL RDF RDFS SDWM SHriMP SQL UML URI URL VRP W3C Computer Human Interaction & Software Engineering Lab Hypercube Common Warehouse Metamodel DARPA Agent Markup Language Datenbankmanagementsysteme Dublin Core Dimensionshierarchiestufe Dokumenttypdefinition Data Warehouse Data-Warehouse-System Foundation for Research and Technology - Hellas Graphical User Interface Identifier Ontology Inference Layer Open Knowledge Base Connectivity Web Ontology Language Ressource Description Framework RDF-Schema Semantisches Data-Warehouse-Modell Simple Hierarchical Multi-Perspective Structured Query Language Unified Modeling Language Uniform Resource Identifier Uniform Resource Locators Validating RDF Parser World Wide Web Consortium vi

9 XML World Wide Web Extensible Markup Language vii

10 1 Einleitung In vielen Unternehmen haben sich Data-Warehouse-Systeme (DWH-Systeme) zu einem wichtigen Bestandteil für die operative und strategische Planung sowie für die Steuerung zur Erlangung nachhaltiger Wettbewerbsvorteile etabliert. Bei Projekten zur Einführung eines unternehmensweiten DWH-Systems wird ein Unternehmen mit großen technischen und organisatorischen Herausforderungen konfrontiert. Ferner sind diese Projekte sehr zeit- und kostenintensiv. Aufgrund dieser Gegebenheiten entstanden in Unternehmen abteilungs- bzw. bereichsspezifische Ausprägungen von DWH-Systemen. Neben unterschiedlichen Datenschemata kennzeichnet vor allem ein differenziertes Verständnis der Fachbegriffe die gewachsene Data-Warehouse (DWH)-Infrastruktur (Jung & Winter, 2000, S. 4 ff.), (Winter, 2004, S. 317). Somit wird das eigentliche Ziel der DWH-Systeme die horizontale und vertikale Datenintegration an einer zentralen Stelle vernachlässigt. Vergleichbare und aussagekräftige Berichte zwischen multiplen DWH-Systemen können nur mit zeit- und ressourcenintensivem Abstimmungsaufwand erstellt werden. Als Konsequenz nimmt die Aktualität, Qualität und Flexibilität der Datenanalyse ab. Der Wert einer abgeleiteten Information für den Anwender sinkt (Mucksch & Behme, 1998, S. 22 ff.). Für die erfolgreiche Nutzung eines DWH-Systems sind die Anwender zwingend auf Metadaten angewiesen (Auth, 2004, S. 34 f.). In der Informationstechnologie werden alle Arten von Informationen, die zu Analyse, Entwurf und Implementierung verwendet werden, als Metadaten bezeichnet (Staudt et al., 1999, S. 1). Anschließend können diese Metadaten von Informationssystemen verwendet werden (Bauer & Günzel, 2004, S. 328). Sie beinhalten Informationen, die benötigt werden, um Daten aus Quellsystemen zu extrahieren, zu transformieren und in das produktive DWH zu laden. Weiterhin beschreiben Metadaten die Bedeutung oder Eigenschaften der Daten im DWH. Dadurch kann der Anwender die Daten besser verstehen, nach- 1

11 1 Einleitung vollziehen, verwalten und auch nutzen. Erst durch Metadaten werden aus den Daten Informationen generiert (Staudt et al., 1999, S. 1), (Pantelic & Nohr, 2000, S. 6). Eine Konsolidierung der Metadaten ist unerlässlich, um die Daten bestehender DWH-Systeme zusammenzuführen. Hierfür bedarf es geeigneter Strategien, die zu einer einheitlichen syntaktischen Darstellung und einer homogenen mit Semantik angereicherten Beschreibung der gespeicherten Daten führen. Lösungsansätze zu dieser Thematik werden in der Literatur nachhaltig diskutiert. Ein wichtiger Ursprung der Strategien findet sich in den Bestrebungen um das Schema-Management, welches in den letzten Jahren unter dem Namen Model-Management wieder verstärkt Aufmerksamkeit gefunden hat (Leser & Naumann, 2007, S. 81, S. 115 ff.), (Bernstein & Melnik, 2007). Das Schema-Management fokussiert sich in erster Linie auf die Überwindung struktureller Heterogenität. Einen weiteren Ansatz stellt das so genannte kollaborative Data-Warehousing dar. Es handelt sich dabei um einen kombinierten Ansatz, der Daten aus unterschiedlichen DWH-Systemen zusammenführt. Als technische Grundlage für die Realisierung dieses Ansatzes dient die zusicherungsbasierte Integration (Correspondence Assertation (Spaccapietra et al., 1992)). Weiterhin fundiert dieser Ansatz auf dem Grundgedanken föderierter Datenbanken (Conrad, 1997). Durch Einbeziehung der Korrespondenz-Zusicherung sowie die Anwendung vorgegebener Integrationsregeln kann ein integriertes, virtuelles Schema über DWH- Systeme konstruiert werden (Matheis et al., 2007). Für ein homogenes Verständnis der Objekte in einem DWH soll der Ansatz von Lehmann und Jaszwewski sorgen. Sie realisieren dies mit einem so genannten Informationsnavigator, der als zusätzliche Komponente zu einem DWH implementiert ist. Über eine angeschlossene Lexikonkomponente, die ein konsolidiertes Begriffssystem enthält, fungiert der Informationsnavigator als eine Art Hilfe- und Suchsystem (Lehmann & Jaszewski, 1999), (Lehmann, 2001, S. 160 ff.). Semantische Aspekte werden bei den genannten Ansätzen nur peripher betrachtet. Ziel dieser Diplomarbeit ist daher die Ermittlung von Metadaten-Kriterien für DWH-Systeme, welche eine semantisch homogene Beschreibung der Metadaten ermöglichen. Als Grundlage dient das im Semantic Web etablierte Resource Description Framework 1 (RDF), das auf seine Anwendbarkeit zur formalen und se- 1 Die W3C-Spezifikation des RDF ist unter abrufbar (letzter Abruf ). 2

12 1 Einleitung mantisch homogenen Beschreibung von DWH-Metadaten untersucht wird. Mit der RDF-Technologie soll ein Metadaten-Vokabular für DWH-Systeme erstellt werden, welches gemäß dem Kriterienkatalog neben syntaktischen besonders auch semantische Aspekte berücksichtigt. Auf diese Weise kann eine Homogenisierung heterogener DWH-Systeme unterstützt werden. Eine Überprüfung auf Funktionalität soll mit einer prototypischen Realisierung des entwickelten Metadaten-Vokabulars für DWH-Systeme stattfinden. Zunächst werden in Kapitel 2 die für diese Arbeit benötigten technologischen Grundlagen erläutert. Anschließend werden prinzipielle Anforderungen der DWH- Metadaten-Verwaltung anhand eines Kriterienkatalogs ermittelt und auf ihre Umsetzung im RDF geprüft (Kapitel 3). Basierend auf diesen Ergebnissen wird in Kapitel 4 ein prototypisches RDF-Schema (RDFS) zur semantisch homogenen Metadaten- Beschreibung in DWH-Systemen entwickelt. Die Anwendbarkeit dieses RDFS wird in Kapitel 5 gezeigt. Den Abschluss dieser Arbeit bildet eine Zusammenfassung der gewonnenen Ergebnisse sowie ein Ausblick auf weitere Forschungsfragen (Kapitel 6). 3

13 2 Technologische Grundlagen der Metadaten-Verwaltung Ziel dieses Kapitels ist es, einen Überblick über die verwendeten Technologien und Theorien zu geben, um die notwendigen Grundlagen für die folgenden Kapitel zu vermitteln. Dafür wird zunächst auf das RDF eingegangen (Kapitel 2.1) und anschließend das DWH (Kapitel 2.2) und die Metadaten im DWH-Kontext (Kapitel 2.3) beschrieben. 2.1 Grundlagen des Resource Description Framework Das vom World Wide Web Consortium (W3C) standardisierte RDF stellt ein Metadaten-Rahmenwerk dar, um Ressourcen, insbesondere im World Wide Web (WWW), einheitlich zu annotieren (Geroimenko, 2004, S. 131), (Mintert, 2002, S. 24, S. 31), (Lux, 2006, S. 68) sowie diese in einer maschinenlesbaren und interpretierbaren Form zu speichern (Antoniou & van Harmelen, 2004, S. 63). Durch den Einsatz des RDF wird eine formale Semantik und Syntax erreicht. Zusätzlich werden Mechanismen bereitgestellt, welche die Informationen über die erfassten Ressourcen (Metadaten) miteinander in Beziehung setzen. Hierfür greift das RDF auf etablierte Strukturen für den Extensible Markup Language (XML)-basierten Datenaustausch zurück (Powers, 2003, S. 1 ff.), (Leser & Naumann, 2007, S. 259 ff.), (Antoniou & van Harmelen, 2004, S. 17). 4

14 2 Technologische Grundlagen der Metadaten-Verwaltung Uniform Resource Identifier Ein Uniform Resource Identifier 1 (URI) stellt eine standardisierte Schreibweise dar, um ein Objekt eindeutig zu identifizieren. Uniform Resource Locators 2 (URL) bilden eine Teilmenge des URI. Sie stellen eine bestimmte Instanz einer URI dar. Eine URL kann entweder eine komplette oder eine relative Pfadangabe beinhalten. Der URI kann optional einen Fragmentbezeichner enthalten, welcher durch # von dem eigentlichen URI abgetrennt ist. Somit dient ein URI als ID und muss weder eine Angabe bezüglich des verwendeten Protokolls enthalten, noch muss die identifizierte Ressource physikalisch im Web existieren. Der grundsätzliche Unterschied zwischen einer URL und einem URI liegt darin, dass eine URL nur einen bestimmten Ort eines Objekts beschreibt, während der URI neben diesem auch einen Namen angeben kann (Powers, 2003, S. 22). Im RDF wird jede Ressource durch einen URI identifiziert (Uriref). Diese Urirefs sind entweder absolut oder relativ spezifiziert. Eine absolute Angabe sieht zum Beispiel folgendermaßen aus: Eine relative hingegen lautet lediglich: #RDF-Paper.htm. Falls keine Referenz zur Basis einer relativen Ortsangabe angegeben ist, stellt die Ortsangabe des Dokuments die Basis dar (Powers, 2003, S. 22). Kann im RDF eine Ressource noch nicht identifiziert werden, so wird diese als Blank Node bezeichnet und muss nicht zwingend eine ID besitzen. Aus folgenden zwei Gründen kann eine solche Knotenart resultieren (Powers, 2003, S. 41): Einerseits kann der Wert der URI unbedeutend sein und existiert daher überhaupt nicht. Andererseits existiert der Wert, fehlt aber noch im RDF-Dokument. Ein Blank Node wird durch eine automatisch generierte ID identifiziert. Auf diese Weise können Blank Nodes innerhalb eines Graphen unterschieden werden. 1 Der URI-Standard ist unter abrufbar (letzter Abruf ). 2 Die URL-Spezifikation ist unter abrufbar (letzter Abruf ). 5

15 2 Technologische Grundlagen der Metadaten-Verwaltung RDF-Datenmodell Die Informationen über Ressourcen werden im RDF durch RDF-Tripel repräsentiert (Stuckenschmidt & van Harmelen, 2003, S. 6), (Daconta et al., 2003, S. 87). Dessen drei Elemente werden im RDF als Subjekt, Prädikat und Objekt bezeichnet und formen eine RDF-Aussage (Antoniou & van Harmelen, 2004, S. 64), (Daconta et al., 2003, S. 88), (Hitzler et al., 2007, S. 40). Das Subjekt ist die Ressource, über die eine Aussage getroffen wird (Antoniou & van Harmelen, 2004, S. 63). Prädikate sind Eigenschaften, die das Subjekt näher charakterisieren. Hierbei handelt es sich zum Beispiel um ein Verhalten, eine Beziehung oder eine bestimmte Kennzeichnung (Antoniou & van Harmelen, 2004, S. 64). Die dritte Komponente, das Objekt, enthält den Wert einer Eigenschaft. Dieser Eigenschaftswert kann wie im Beispiel (Abbildung 2.1) ein Literal sein oder erneut eine Ressource beinhalten. So ist es möglich, komplexe RDF-Aussagen zu konzipieren (Powers, 2003, S. 17). Folgende vier Merkmale besitzt jedes RDF-Tripel: Ein RDF-Tripel besteht immer aus einem Subjekt, Prädikat und Objekt. Jedes RDF-Tripel muss vollständig und seine Aussage einzigartig sein. Die einzelnen Bestandteile des RDF-Tripel sind folgendermaßen charakterisiert: Das Subjekt ist entweder ein Blank Node oder ein Knoten mit einem Uriref. Das Prädikat ist stets ein Uriref. Als Objekt kann ein Blank Node, ein Knoten mit einem Uriref oder auch ein Literal verwendet werden. Jedes RDF-Tripel kann mit anderen RDF-Tripeln kombiniert werden. Trotz der Komplexität des Modells, in dem ein RDF-Tripel eingeschlossen ist, behält es jeweils seine individuelle, einzigartige und eindeutige Aussage. Der letzte Punkt ist besonders für das Verständnis von RDF-Tripeln wichtig. Unabhängig davon, wie komplex ein RDF-Graph ist, besteht dieser lediglich aus einer Gruppierung von einzigartigen, einfachen RDF-Aussagen (Powers, 2003, S. 18). RDF-Aussagen (RDF-Tripel) werden durch einen gerichteten Graphen visualisiert (Geroimenko, 2004, S. 132), (Hitzler et al., 2007, S. 36 f.) und können durch RDF/XML serialisiert werden (Davies et al., 2003, S. 13), (Lux, 2006, S. 69). 6

16 2 Technologische Grundlagen der Metadaten-Verwaltung RDF-Graph Als Darstellungsmethode für das RDF-Datenmodell legte die RDF Core Working Group 3 den RDF-Graphen fest. Folgende zwei Motive begründen die Wahl der visuellen Darstellungsmethode (Powers, 2003, S. 19): 1. Die einfache Lesbarkeit der Graphen. Das Subjekt, die zugehörigen Eigenschaften sowie deren Eigenschaftswerte sind klar erkennbar. 2. Die Tatsache, dass es RDF-Datenmodelle gibt, die nicht in einer RDF/XML- Notation abgebildet werden können. Ein gerichteter RDF-Graph besteht aus einer Menge von Knoten, die über Pfeile gemäß dem Knoten-Pfeil-Knoten-Pattern miteinander verbunden sind (Powers, 2003, S. 19), (Hitzler et al., 2007, S. 36), (Geroimenko, 2004, S. 132), (Hammersley, 2003, S. 47). Es gibt drei Typen von Knoten: Uriref-Knoten, Blank Node und Literal. Ein Uriref-Knoten besteht aus einer URI-Referenz, die den Knoten eindeutig identifiziert aber nicht notwendigerweise auf eine Web-Ressource verweisen muss. Ist die Identifikation einer Ressource bedeutungslos, so wird diese graphisch als Blank Node gekennzeichnet. In einem RDF-Graphen werden Ressourcen durch Ellipsen dargestellt, welche mit einem URI beschriftet sind (Antoniou & van Harmelen, 2004, S. 63), (Powers, 2003, S. 19 f.). Besitzt eine Ellipse keinen Inhalt, so repräsentiert diese einen Blank Node (Hitzler et al., 2007, S. 38). Die zugehörigen Eigenschaften der Ressourcen werden durch Kanten ausgedrückt. Ein entsprechendes Rechteck beschreibt den Wert dieser Eigenschaft (Koschmider et al., 2004). Mit steigender Anzahl der RDF-Aussagen wird ein spezifischer Sachverhalt immer präziser erfasst. Abbildung 2.1 zeigt eine einfache RDF-Aussage visualisiert als RDF-Graph. Semantisch homogene Beschreibung von Data-Warehouse-Metadaten mit RDF hatautor Martin Weber Abbildung 2.1 RDF-Graph Das Subjekt wird durch die Ellipse abgebildet und eindeutig durch den URI Semantisch homogene Beschreibung von Data-Warehouse-Metadaten mit RDF identi- 3 Informationen über die RDF Core Working Group sind unter RDFCore/ abrufbar (letzter Abruf ). 7

17 2 Technologische Grundlagen der Metadaten-Verwaltung fiziert. Das Prädikat ist durch die gerichtete Kante mit der Eigenschaft hatautor versehen. Das Objekt mit dem Eigenschaftswert Martin Weber wird durch das Rechteck repräsentiert. Die Richtung des Pfeils zeigt immer vom Subjekt zum Objekt. Dessen Beschriftung ist durch die Benennung der Eigenschaft gegeben (Antoniou & van Harmelen, 2004, S. 65), (Powers, 2003, S. 20). Wird ein RDF-Graph beispielsweise durch den RDF-Validator 4 maschinell erzeugt, bekommen Blank Nodes einen automatisch generierten eindeutigen URI zugeteilt. Somit können sie in der aktuell geöffneten Instanz unterschieden werden (Powers, 2003, S. 20). Diese Art von Knoten, auch als bnodes oder anonymous nodes betitelt, können sich jedoch bei einer maschinellen Verarbeitung als problematisch erweisen, da bei jeder Instanz eine neue, veränderte ID erzeugt wird. Deshalb kann der Benutzer bei einer automatisch generierten ID nicht darauf schließen, dass es sich um ein und dasselbe Objekt handelt. Jedoch ist dieser Sachverhalt als unkritisch einzustufen, da es sich bei einem Blank Node nur um einen Platzhalter handelt. Eine Instanz eines RDF-Datenmodells wird in einem RDF-Graphen ausschließlich durch die Bestandteile Uriref-Knoten, Blank Node, Literal und Pfeil beschrieben. Das Literal ist stets ein Objekt. Die Pfeile der Prädikate sind gerichtet und beschriftet (Powers, 2003, S. 21) Serialisierung von RDF als XML Eine Serialisierung transformiert komplexe Datenobjekte in lineare Zeichenketten (Hitzler et al., 2007, S. 40). Die RDF/XML-Syntax bietet die Möglichkeit, ein RDF-Datenmodell als XML-Dokument in textbasierter Form zu persistieren (Powers, 2003, S. 30). Dabei muss das XML-Dokument wohlgeformt sein (Mintert, 2002, S. 45), gleichzeitig müssen alle Einschränkungen des RDF eingehalten werden (Powers, 2003, S. 30). Als Beispiel wird folgende Aussage in RDF- Statements zerlegt und mit dem RDF in einem XML-Dokument beschrieben: 4 Der RDF-Validator befindet sich unter (letzter Abruf ). 8

18 2 Technologische Grundlagen der Metadaten-Verwaltung Das Dokument Semantisch homogene Beschreibung von Data-Warehouse- Metadaten mit RDF, welches sich unter http: // www. sem-metadata. com/ SMDDWH. pdf befindet, hat als Autoren Martin Weber und Stefan Hartmann und stammt aus dem Jahr Somit werden die aufgeführten RDF-Statements getrennt nach Subjekt, Prädikat und Objekt identifiziert: Das Subjekt ist eindeutig durch seinen URI SMDDWH.pdf bestimmt. Das Dokument hat als Autoren Martin Weber und Stefan Hartmann hatautor bildet das Prädikat, der zugehörige Eigenschaftswert ist jeweils Martin Weber und Stefan Hartmann. und stammt aus dem Jahr 2007 stammtausjahr ist das Prädikat und beinhaltet den Eigenschaftswert Die Notation der RDF-Aussagen in XML sieht wie folgt aus: 1 <? xml version =" 1.0 "?> 2 < rdf:rdf 3 xmlns:rdf =" http: // /1999/02/22 - rdf - syntax -ns#" 4 xmlns:daexamp =" http: // - metadata. com / elements /1.0/ "> 5 < rdf:description 6 rdf:about =" http: // - metadata. com / SMDDWH. pdf "> 7 < daexamp:hatautor > Martin Weber </ daexamp:hatautor > 8 < daexamp:hatautor > Stefan Hartmann </ daexamp:hatautor > 9 < daexamp:stammtausjahr >2007 </ daexamp:stammtausjahr > 10 < rdf:type rdf:resource = 11 " http: // - metadata. com / elements /1.0/ Article "/> 12 </ rdf:description > 13 </ rdf:rdf > Codebeispiel 2.1 RDF/XML Die erste Zeile formt die traditionelle XML Deklaration und macht deutlich, dass es sich um ein XML-Dokument handelt (Antoniou & van Harmelen, 2004, S. 66). Jedes neue Element wird durch den öffnenden XML-Tag ( < ) gekennzeichnet (Mintert, 2002, S. 58). Das rdf:rdf umschließt den kompletten RDF-basierten Inhalt. Nachfolgend sind die verwendeten Namespaces (Namensräume) angegeben, die für jedes 9

19 2 Technologische Grundlagen der Metadaten-Verwaltung RDF-Element den zugehörigen Namespace identifizieren (Mintert, 2002, S. 100 f.). Der erste mit dem Präfix rdf verweist auf die RDF-Syntax, der zweite hingegen mit der Vorsilbe daexamp beschreibt die Elemente, welche für das vorliegende Beispiel erstellt wurden. Ein Namespace referenziert eine existierende Schema-Definition (siehe Kapitel 2.1.6), (Antoniou & van Harmelen, 2004, S. 71). Diese muss jedoch nicht zwingend im Web existieren, weil ein RDF-Dokument nicht automatisch gegen ein Schema validiert wird. Die Beschreibung einer Ressource leitet das Element rdf:description ein. Es enthält das Attribut rdf:about. Dies identifiziert die Ressource (Subjekt) eindeutig. Der Wert des Attributs kann entweder eine Referenz auf ein im Dokument definiertes Element sein oder, wie in diesem Fall, der URI des Subjekts (Powers, 2003, S. 32), (Antoniou & van Harmelen, 2004, S. 66). Die folgenden Attribute daexamp:hatautor, daexamp:stammtausjahr sind Prädikate (Eigenschaften) und beschreiben durch den Eigenschaftswert (Objekt) das Subjekt näher (Antoniou & van Harmelen, 2004, S. 71). Im Beispiel sind die Werte der Objekte jeweils Literale. Ein Subjekt kann beliebig viele Prädikate besitzen. Der Typ dieser Resource wird durch das Element rdf:type festgelegt (siehe Kapitel 2.1.5). Abschließend werden die geöffneten XML- Tags durch > wieder geschlossen (Mintert, 2002, S. 59), um das Dokument wohl zu formen (Antoniou & van Harmelen, 2004, S. 29). Sind all diese Bedingungen erfüllt, sind die RDF-Aussagen in Form einer RDF/XML-Notation serialisiert und es handelt sich um ein wohlgeformtes RDF/XML-Dokument Namespaces und QNames Ein Ziel des RDF ist es unter anderem, Wissen in maschinenverarbeitbarer Form zu erfassen und die Verknüpfung verschiedener Daten zu vereinfachen (Antoniou & van Harmelen, 2004, S. 24). Aufgrund der Kombination mehrerer RDF-Schemata können im Nachhinein Ergänzungen hinzugefügt werden ohne ein bestehendes Schema zu verändern. Um sicherzustellen, dass RDF/XML-Daten aus unterschiedlichen Dokumenten und Spezifikationen erfolgreich zusammengeführt werden können, unterstützt der RDF-Standard Namespaces. Der Einsatz von Namespaces vermeidet eine Überschneidung bezüglich der einzelnen Elemente (Daconta et al., 2003, S. 104). Ein solcher Konflikt bei Elementen entsteht beispielsweise dann, wenn diese inner- 10

20 2 Technologische Grundlagen der Metadaten-Verwaltung halb eines Dokuments in zwei unterschiedlichen Schemata mit demselben Namen identifiziert werden (Powers, 2003, S. 38). Im Codebeispiel 2.1 ist der Namespace der RDF/XML-Syntax (xmlns:rdf) und der des Beispiel-Vokabulars (xmlns:daexamp) definiert. Die Angabe der Namespaces für RDF-Vokabulare, verweist durch einen URI auf das zugehörige RDFS. Obwohl im Gegensatz zu XML und einer Dokumenttypdefinition (DTD) im RDF/XML keine automatische Validierung gegenüber dem Schema durchgeführt wird, sollte das RDFS zumindest als Dokumentation existieren (Powers, 2003, S. 39). Dadurch kann die syntaktische Korrektheit eines Dokuments geprüft werden. Qualifizierte Namen werden durch einen QName angegeben (Hitzler et al., 2007, S. 41). Hierbei handelt es sich um eine Namespace-Vorsilbe, der ein Doppelpunkt folgt (Antoniou & van Harmelen, 2004, S. 44). Den Abschluss bildet ein lokaler XML-Name (z. B.: daexamp:hatautor) (Mintert, 2002, S. 101 f.). Verbal ausgedrückt bedeutet diese Symbolik, dass daexamp der QName für das Element hatautor ist. Als Vorsilbe für das RDF-Syntax-Schema wird in der Regel rdf angeführt. Die Bezeichnung rdfs steht als Präfix für das RDFS und dc ist kennzeichnend für Dublin Core (siehe Kapitel 2.1.7) (Powers, 2003, S. 39) RDF-Typangabe Neben der URI, die eine Ressource eindeutig identifiziert, besitzt jede Ressource zusätzlich eine konsistente Typangabe. Die Typisierung einer Ressource beginnt mit einem Großbuchstaben und die eines Prädikats mit einem Kleinbuchstaben. Um diese explizit anzugeben, wird die RDF-Eigenschaft rdf:type verwendet. Der Wert dieser Eigenschaft ist ein URI, welcher auf eine RDFS-Klasse deutet (siehe Kapitel 2.1.6). Das Codebeispiel 2.1 spezifiziert durch rdf:type die Art des Dokuments. Der Wert definiert den Ort, an dem sich das zugehörige Schemaelement für die Klasse Article befindet. Anstatt einer ausführlichen Beschreibung einer Ressource durch rdf:description und rdf:type, kann auch eine RDF/XML-Kurzschreibweise verwendet werden (Powers, 2003, S. 47), (Antoniou & van Harmelen, 2004, S. 74). Dabei wird der Typ der Res- 11

21 2 Technologische Grundlagen der Metadaten-Verwaltung source direkt nach dem QName spezifiziert und der rdf:description -Tag entfällt (siehe Codebeispiel 2.2). 1 <? xml version =" 1.0 "?> 2 < rdf:rdf 3 xmlns:rdf =" http: // /1999/02/22 - rdf - syntax -ns#" 4 xmlns:daexamp =" http: // - matadata. com / elements /1.0/ "> 5 < daexamp:article 6 rdf:id =" http: // - matadata. com / article / SMDDWH. pdf "> 7 < daexamp:author > Martin Weber </ daexamp:author > 8 < daexamp:author > Stefan Hartmann </ daexamp:author > 9 < daexamp:year >2007 </ daexamp:year > 10 </ daexamp:article > 11 </ rdf:rdf > Codebeispiel 2.2 RDF/XML-Kurzschreibweise RDF-Schema Das RDF bietet die Möglichkeit, einfache Aussagen über bestimmte Ressourcen mit Hilfe definierter Eigenschaften und Werte zu beschreiben (W3C Recommendation, 2004a). Darüber hinaus offeriert ein RDFS die Möglichkeit, ein zusätzliches Vokabular zu definieren (Antoniou & van Harmelen, 2004, S. 80), (Geroimenko, 2004, S. 133). Notwendig wird dies, wenn die vorgegebenen Aussagen nicht ausreichen, um Ressourcen in einem bestimmten Anwendungsgebiet eindeutig zu beschreiben. Domänenspezifische Klassen und Eigenschaften können mit dem RDF selbst nicht definiert werden (Antoniou & van Harmelen, 2004, S. 80). Zur Spezifikation wird daher ein eigenes RDF-Vokabular, das RDFS, benötigt (Antoniou & van Harmelen, 2004, S. 62), (Daconta et al., 2003, S. 104). Das RDFS verfügt über ein Typsystem für das RDF, welches den objektorientierten Programmiersprachen zum Beispiel Java 5 ähnlich ist (Daconta et al., 2003, S. 104). Gewisse Ressourcen lassen sich deshalb als Instanzen einer oder mehrerer Klassen 5 Nähere Informationen zu Java sind unter abrufbar (letzter Abruf ). 12

22 2 Technologische Grundlagen der Metadaten-Verwaltung erzeugen. Außerdem können zwischen einzelnen Klassen Hierarchien errichtet werden (Antoniou & van Harmelen, 2004, S. 81), (Davies et al., 2003, S. 15). Die Elemente des RDFS sind in RDF-Notation beschrieben und bilden eine spezialisierte Menge vordefinierter RDF-Ressourcen. Ein RDFS kann als valider RDF-Graph visualisiert werden. Die Ressourcen im RDFS sind durch Urirefs mit der Vorsilbe charakterisiert und werden durch den QName rdfs gekennzeichnet (W3C Recommendation, 2004a). Im Weiteren werden nun die RDFS Hauptbestandteile rdfs:class und rdf:property detailliert beschrieben. rdfs:class Eine Klasse im RDFS basiert auf dem allgemeinen Konzept der Kategorisierung und der Typisierung. Die RDF-Klassen können verschiedene Kategorien, wie zum Beispiel Webseiten, Menschen, Dokumente, Metadaten oder Datenbanken repräsentieren. Sie werden durch die RDFS-Ressourcen rdfs:class und rdfs:resource, sowie die Eigenschaften rdf:type und rdfs:subclassof spezifiziert. Im RDFS sind alle Klassen als Unterklassen der Klasse rdfs:resource definiert (Geroimenko, 2004, S. 137), (W3C Recommendation, 2004a). Eine Spezialisierungsbeziehung zwischen zwei Klassen kann durch die Eigenschaft rdfs:subclassof ausgedrückt werden. Jede Instanz der Unterklasse ist ebenfalls eine Instanz der Oberklasse (Antoniou & van Harmelen, 2004, S. 81 f.). Da RDFS-Klassen RDF-Ressourcen darstellen, kann die in Kapitel eingeführte Kurzschreibweise verwendet werden. Das Codebeispiel 2.3 definiert einzelne Ressourcen (Klassen) und identifiziert diese durch rdf:id eindeutig. Ist der Wert von rdf:id einmalig, handelt es sich um ein gültiges RDFS. Instanzen einer Klasse (Ressourcen) werden unter Angabe der ID referenziert und im RDF-Dokument verwendet (Antoniou & van Harmelen, 2004, S. 67). Die Notation dafür ist ein vorgestelltes # gefolgt von der ID (z. B.: rdf:resource="#person") (W3C Recommendation, 2004a). 13

23 2 Technologische Grundlagen der Metadaten-Verwaltung 1 <? xml version =" 1.0 "?> 2 < rdf:rdf xmlns:rdf =" http: // /1999/02/22 - rdf - syntax -ns#" 3 xmlns:rdfs =" http: // /2000/01/ rdf - schema #" 4 xml:base =" http: // - matadata. com / elements /1.0/ Lebewesen "> 5 < rdfs:class rdf:id =" Person "/> 6 < rdfs:class rdf:id =" Student " > 7 < rdfs:subclassof rdf:resource ="# Person "/ > 8 </ rdfs:class > 9 < rdfs:class rdf:id =" Dozent " > 10 < rdfs:subclassof rdf:resource ="# Person "/ > 11 </ rdfs:class > 12 < rdfs:class rdf:id =" Name "/> 13 < rdf:property rdf:id =" hatname " > 14 < rdfs:domain rdf:resource ="# Person "/ > 15 < rdfs:range rdf:resource ="# Name "/> 16 </ rdf:property > 17 </ rdf:rdf > Codebeispiel 2.3 RDFS Um sicherzustellen, dass die Referenzen immer konsistent sind, kann eine xml:base explizit angegeben werden. Der zugehörige Wert ist der Base-URI, welcher sich von der eigentlichen Adresse des Schemas unterscheiden kann (Hitzler et al., 2007, S. 46), (Mintert, 2002, S. 732). rdf:property Mit Hilfe von Eigenschaften werden die beschriebenen Klassen detaillierter charakterisiert. Alle Eigenschaften im RDF werden durch die RDF-Klasse rdf:property beschrieben. Durch die Built-in-Properties rdfs:range, rdfs:domain und rdfs:subpropertyof können diese weiter eingeschränkt werden. Erstere stellt sicher, dass der Wertebereich lediglich Instanzen enthält, die durch rdfs:range angegeben wurden. Das Attribut rdfs:domain beschränkt eine bestimmte Eigenschaft auf die Verwendung ausschließlich mit den spezifizierten Klassen. Das Attribut rdfs:subpropertyof drückt eine Unter-/Oberklasse-Beziehung einer Eigenschaft aus (Antoniou & van Harmelen, 2004, S. 83). Jede Eigenschaft kann keine bis beliebig viele Einschränkungen haben (W3C Recommendation, 2004a). Im Codebeispiel 2.3 ist die Eigenschaft hatname definiert. 14

24 2 Technologische Grundlagen der Metadaten-Verwaltung Built-in-Properties Built-in-Properties geben zusätzliche Informationen über ein RDFS und dessen Instanzen. Eine solche Eigenschaft ist zum Beispiel rdfs:comment und rdfs:label. Erstere enthält eine Beschreibung für eine Ressource in natürlicher Sprache. Diese Eigenschaft behebt somit etwaige Unklarheiten über das Vokabular und trägt so zu dessen konsistenter Verwendung bei. Letztere stellt den Namen einer Ressource in menschenlesbarer Form dar. Dadurch können Programme, die das RDF-Dokument lesen und visualisieren, anstatt einer kryptischen URI den Wert der Eigenschaft label für die Benennung von Subjekt, Objekt oder einer Eigenschaft verwenden (Hitzler et al., 2007, S. 81 f.). Die Built-in-Properties rdfs:seealso und rdfs:isdefinedby verweisen jeweils auf eine Ressource, die möglicherweise zusätzliche Informationen über das Subjekt enthält. Die Eigenschaft rdfs:isdefinedby ist eine Untereigenschaft von rdfs:seealso (W3C Recommendation, 2004a), (Hitzler et al., 2007, S. 81 f.). Ferner existiert noch rdfs:subclassof, welche transitiv eine Ober-/Unterklassen Beziehung signalisiert. Analog hierzu gibt es das Built-in-Property rdfs:subpropertyof, welches eine Spezialisierungsbeziehung zwischen zwei Eigenschaften darstellt. Der genaue Typ einer Ressource wird durch die Eigenschaft rdf:type angegeben und bedeutet, dass die Ressource eine Instanz der spezifizierten Klasse ist. Die Built-in-Properties rdfs:domain und rdfs:range werden im nächsten Kapitel näher beschrieben (W3C Recommendation, 2000). Weitere RDFS-Charakteristika Das RDFS hat in Grundzügen Gemeinsamkeiten mit objektorientierten Programmiersprachen, unterscheidet sich jedoch von diesen in wesentlichen Punkten (Antoniou & van Harmelen, 2004, S. 83). Im Gegensatz zu herkömmlichen Programmiersprachen, die Klassen mit bestimmten Eigenschaften definieren, beschreibt das RDFS spezielle Eigenschaften, die durch rdfs:range und rdfs:domain auf bestimmte Klassen eingeschränkt sind (Stuckenschmidt & van Harmelen, 2003, S. 24). In objektorientierten Programmiersprachen wird beispielsweise eine Klasse Person definiert, welche die Eigenschaft hatname besitzt. Das zugehörige RDFS führt die Klasse daexamp:person und die Eigenschaft daexamp:hatname getrennt auf. Die Domäne (rdfs:domain) wäre in diesem Fall Person mit dem zugehörigen Wertebereich 15

25 2 Technologische Grundlagen der Metadaten-Verwaltung (rdfs:range) Name. In einer Programmiersprache ist die Eigenschaft hatname also Teil der Klassendefinition. Standardmäßig wird in einem RDFS der Eigenschaft globale Gültigkeit eingeräumt. Dies ist auf die Unabhängigkeit der Eigenschaft von einer bestimmten Klasse zurückzuführen. Sie besitzt daher in allen Klassen den gleichen Wertebereich (Antoniou & van Harmelen, 2004, S. 83). Ein weiterer Unterschied ist in der Klassenbeschreibung zu finden, die nicht zwingend präskriptiv ist. Im RDFS sind Eigenschaften lediglich zusätzliche Informationen zu Ressourcen, legen aber nicht deren Verwendung fest. Die RDF-Aussagen können somit nur präskriptive Beschreibungen sein, wenn ein Programm sie als solche behandelt. Das RDFS bietet im Wesentlichen die Möglichkeit, diese Informationen zu repräsentieren. Ferner kann das RDFS zur Beschreibung einfacher Ontologien benutzt werden (W3C Recommendation, 2004a), (Antoniou & van Harmelen, 2004, S. 111), (McBride, 2004, S. 63). Im Rahmen dieser Diplomarbeit werden Ontologien jedoch nicht tiefer betrachtet Dublin Core Dublin Core 6 (DC) stellt eine Menge von Elementen zur Verfügung, um Dokumente detaillierter zu beschreiben. Dieses Vokabular wurde ursprünglich im März 1995 in einem Workshop in Dublin, Ohio entwickelt. Anschließend wurde das DC durch Workshops weiter modifiziert und wird gegenwärtig von der Dublin Core Metadata Initiative 7 gewartet. Das DC verfolgt das Ziel, eine minimale Menge an Elementen bereitzustellen, welche eine Beschreibung und die automatische Indizierung von Dokumenten erleichtert (W3C Recommendation, 2004a). Nachfolgend werden einige ausgewählte Elemente aufgeführt: Creator: Eine Person, die für den Inhalt des Dokuments verantwortlich ist. Contributor: Name einer weiteren Person, die zur Erstellung des Dokuments beigetragen hat. 6 Das Dublin Core-Vokabular ist unter beschrieben (letzter Abruf ). 7 Nähere Informationen sind unter verfügbar (letzter Abruf ). 16

26 2 Technologische Grundlagen der Metadaten-Verwaltung Rights: Informationen über den Rechteinhaber der Ressource. Language: Die Sprache, in welcher das Dokument geschrieben ist. Date: Ein charakteristisches Datum im Lebenszyklus des Dokuments. Dublin Core Elemente werden in der Regel für eine exakte Beschreibung von Webseiten genutzt. Neben diesem Standard existiert noch Qualified Dublin Core 8, welches eine Erweiterung des DC-Vokabulars darstellt und über den Namespace dcterms referenziert wird. 2.2 Data-Warehouse Grundlagen Ein DWH-System ermöglicht einen effizienten Zugriff auf integrierte und historische Daten aus heterogenen und autonomen Datenquellen, um Führungskräfte bei der Entscheidungsfindung zu unterstützen (Böhnlein & Ulbrich vom Ende, 2000, S. 1). Es bietet Zugang zu einer Sammlung von Informationen, die durch die folgenden vier Eigenschaften eines DWH charakterisiert werden: (Inmon, 1993, S. 29), (Schinzer & Bange, 2002), (Jung & Winter, 2000, S. 4f.), (Stock & Büttner, 2005, S. 5). Die Daten unterliegen einer zeitlichen Varianz (time-varying). Alle Anfragen an das DWH sind zeitbezogen. Ein DWH ist themenorientiert (subject-oriented) nach Objekten (Produkte, Kunden, Märkte etc.) aufgebaut. Die verteilten Informationen sind in einem einheitlichen homogenen Datenbestand integriert (integrated). Es handelt sich um eine dauerhafte (non-volatile) Informationssammlung. Der Aufbau eines DWH-Systems besteht aus den nachstehenden drei Ebenen (Böhnlein & Ulbrich vom Ende, 2000, S. 17), (Stock & Büttner, 2005, S. 15): Eine Datenerfassungsebene mit der Schnittstelle zu den operativen Systemen, der Datenhaltungsebene (DWH) und der Datenbereitstellungsebene mit der Schnittstelle zu den Endanwendungen und Präsentationswerkzeugen (Abbildung 2.2). Um ein DWH mit 8 Nähere Informationen zu Qualified Dublin Core sind unter 0/modules/dcterms/ abrufbar (letzter Abruf ). 17

27 2 Technologische Grundlagen der Metadaten-Verwaltung Daten zu versorgen, sind komplexe Prozesse der Extraktion, Transformation und des Ladens nötig (ETL-Prozess). Die Basisdatenbanken beinhalten einen integrierten und bereinigten Datenbestand. Aus diesen Datenbanken füllt der Ladeprozess das eigentliche DWH (Böhnlein & Ulbrich vom Ende, 2000, S. 20). Der in der Datenbereitstellungsebene stattfindende Analyseprozess operiert direkt auf dem DWH. Somit besitzt ein DWH-System Schnittstellen (in der Abbildung mit der Farbe Rot gekennzeichnet) zu den Analyse- und Ladeprozessen (Abbildung 2.2) (Schinzer & Bange, 2002). Abbildung 2.2 Überblick über die DWH-System-Architektur (Böhnlein & Ulbrich vom Ende, 2000, S. 17) Allen Ebenen des DWH sind Administrationsfunktionen zugeordnet. Sie werden durch ein Metadaten-Repository unterstützt, welches Informationen über die im DWH gespeicherten Daten enthält (Böhnlein & Ulbrich vom Ende, 2000, S. 18). Ein Metadatenmanager organisiert die Metadatenverwaltung des DWH-Systems und bietet eine Schnittstelle für den Lese- und Schreibzugriff auf das Repository (z. B. ein application programming interface) (Stock & Büttner, 2005). Dadurch erhalten die verschiedenen Komponenten Zugriff auf die Metadaten und können diese unterein- 18

28 2 Technologische Grundlagen der Metadaten-Verwaltung ander austauschen. Voraussetzung für die Werkzeugintegration und die Repository- Navigation ist ein entsprechendes Repository-Schema. Dieses Schema vereinheitlicht sämtliche Metadaten (fachliche, technische, datenbeschreibende oder prozessbezogene) und stellt sie in geeigneter Form für Werkzeuge bereit. Die Verwaltung erfolgt mit Hilfe des Metadatenmanagers (Bauer & Günzel, 2004, S. 70), (Stock & Büttner, 2005, S. 21 f.). Zur Realisierung eines DWH-Systems können ein oder mehrere Datenbankmanagementsysteme (DBMS) eingesetzt werden. Diese müssen für ein konkretes Projekt individuell konfiguriert werden. Eine große Herausforderung liegt dabei im Entwurf des logischen Schemas, welches sich ausschließlich an den Analysebedürfnissen der Anwender orientiert. Ihre Anforderungen wurden zuvor in Form eines konzeptuellen Schemas spezifiziert. Die Datenstruktur wird in einem multidimensionalen Datenmodell (Bauer & Günzel, 2004, S. 57), dem sogenannten Hypercube abgebildet (Böhnlein & Ulbrich vom Ende, 2000, S. 4). In multidimensionalen Datenstrukturen wird zwischen qualitativen und quantitativen Daten unterschieden (Shoshani, 1982). Die Daten werden entweder in multidimensionaler oder relationaler Form gespeichert. In relationalen Datenbanken werden die Daten durch ein Star- (Abbildung 2.3) oder ein Snowflake-Schema (Abbildung 2.4) persistiert (Böhnlein & Ulbrich vom Ende, 2000, S. 8), (Schinzer & Bange, 2002, S. 3 f.), (Bauer & Günzel, 2004, S. 203 ff.). Das Star-Schema besitzt zwei Arten von Tabellen (Böhnlein & Ulbrich vom Ende, 2000, S. 12), (Bauer & Günzel, 2004, S. 205 f.): 1. Die Faktentabelle, die zur Speicherung der quantitativen Daten dient. 2. Die Dimensionstabelle, die qualitative Daten zur Visualisierung von Dimensionen und Dimensionshierarchien des Würfels beinhaltet. Jede einzelne Spalte der Faktentabelle enthält ein Dimensionselement bzw. eine Kennzahl des DWH. Mit Hilfe von Dimensionselementen wird die Verknüpfung zu den Dimensionstabellen hergestellt (Schinzer & Bange, 2002). Das Snowflake-Schema besitzt mindestens eine Faktentabelle und mehrere Dimensionstabellen. Der Unterschied zu den Tabellen des Star-Schemas zeichnet sich in der hierarchischen Struktur ab. Somit besitzt jedes Attribut einer Di- 19

29 2 Technologische Grundlagen der Metadaten-Verwaltung mension eine eigene Relation (Böhnlein & Ulbrich vom Ende, 2000, S. 13), (Bauer & Günzel, 2004, S. 203 f.). Die Dimensionstabelle enthält lediglich noch die Attributsschlüssel und befindet sich in dritter Normalform (Schinzer & Bange, 2002). Auf diese Weise wird eine geringere Redundanz gegenüber dem Star-Schema erreicht. Aufgrund der normalisierten Dimensionen benötigt das Snowflake-Schema weniger Speicherplatz und bietet gewisse Vorteile bei der Abbildung komplexer Modelle. Als Nachteil ist die längere Antwortzeit des Systems zu nennen, die aus der höheren Verknüpfungstiefe resultiert (Böhnlein & Ulbrich vom Ende, 2000, S. 13), (Schinzer & Bange, 2002), (Bauer & Günzel, 2004, S. 203 ff.). Abbildung 2.3 Star Schema (Böhnlein & Ulbrich vom Ende, 2000) 20

30 2 Technologische Grundlagen der Metadaten-Verwaltung Abbildung 2.4 Snowflake Schema (Böhnlein & Ulbrich vom Ende, 2000) 2.3 Metadaten im Data-Warehouse Im Umfeld der Wirtschaftsinformatik deutet die Verwendung der Vorsilbe Meta (aus dem Alt-Griechischen u. a. für danach, darüber hinaus ) darauf hin, dass Erkenntnisse über ein Erkenntnisobjekt verallgemeinert und auf eine höhere Abstraktionsstufe übertragen werden (Auth, 2004, S. 27), (Melchert et al., 2002, S. 6). Nach Ferstl und Sinz legt ein Metamodell das zur Spezifikation von Modellsystemen verfügbare Begriffssystem fest (Ferstl & Sinz, 2006, S. 125). Erst in Ver- bindung mit Metadaten gewinnen Daten an Bedeutung. Metadaten tragen insbesondere bei DWH-Systemen zu einem effizienten Betrieb und einer erfolgreichen Nutzung bei (Melchert et al., 2002, S. 10). Sie beschreiben den Inhalt und die Struktur eines DWH, sorgen für eine korrekte Interpretation und Verarbeitung der Daten und ermöglichen den Anwendern ein schnelles und sicheres Auffinden der benötigten Daten (Melchert et al., 2002, S. 1), (Auth, 2004, S. 34 f.). Um eine effektive und effiziente Nutzung eines DWH sicherzustellen, müssen die Daten in einer für den Anwender verständlichen Form vorliegen und organisiert sein. Somit wird die Wartung, Administration und Informationsgewinnung vereinfacht. Metadaten des DWH-Systems werden im so genannten Metadaten-Repository abgelegt 21

31 2 Technologische Grundlagen der Metadaten-Verwaltung (Melchert et al., 2003), (Bauer & Günzel, 2004, S. 68), (Melchert et al., 2002, S. 16), (Staudt et al., 1999, S. 7). Sie sind für Angaben über die Daten aus den Datenquellen der Basisdatenbank und dem DWH verantwortlich. Hierbei handelt es sich zum Beispiel um konzeptuelle und logische Datenbankschemata inklusive der zugehörigen Dokumentation, physische Speicherinformationen, Informationen über Zugriffsrechte und Datenqualität (Bauer & Günzel, 2004, S. 68 f.), (Melchert et al., 2002, S. 8). Neben den Angaben über Inhalt, Struktur und Kontext enthalten Metadaten auch prozessbezogene Informationen über die Verarbeitung der Daten. Somit kann der ETL-Prozess der Daten (z. B.: Woher kommen die Daten? Wann wurden diese geladen?) nachvollzogen werden. Darüber hinaus kann eine Qualitätssicherung bezüglich der Auswertung und der Richtigkeit der Daten sichergestellt werden (Bauer & Günzel, 2004, S. 69). Die einheitliche Beschreibung von Metadaten im DWH-Kontext stellt eine signifikante Herausforderung dar, um ein konsistentes Datenverständnis zu gewährleisten (Kemper et al., 2004, S. 42 ff.). Im DWH-Umfeld wird hinsichtlich des Hauptnutzens zwischen fachlichen und technischen Metadaten unterschieden (Marco, 2000, S. 49 ff.), (Bauer & Günzel, 2004, S. 69), (Wieken, 1996, S. 275 ff.), (Auth, 2004, S. 39). Erstgenannte dienen vorwiegend dazu, den Endanwender bei seinen Analyseanwendungen zu unterstützen, letztere sind an Administratoren, Anwendungsentwickler und Softwarewerkzeuge gerichtet (Melchert et al., 2002, S. 9). Fachliche Metadaten Fachliche Metadaten stellen verwendungsnotwendiges, betriebswirtschaftliches Wissen über die Daten im DWH-System dar und entstehen vor allem im Zusammenhang mit der Nutzung des DWH-Systems. Der Benutzer erhält somit neben Informationen über die Bedeutung, Herkunft, Struktur und Qualität der mit den analytischen Applikationen verarbeiteten Daten auch Unterstützung beim Verstehen und Interpretieren der Resultate. Gleiches gilt für das Auffinden von relevanten Daten (Auth, 2004, S. 40), (Bauer & Günzel, 2004, S. 69). Hierzu gehören z. B. anwendungsspezifische Dokumentationen über vordefinierte Anfragen, Fachbegriffe, Terminologien, Thesauri und domänenspezifisches Wissen. Darüber hinaus sind dieser Rubrik auch 22