Common Warehouse Metamodel und Imperfektion

Transkript

1 Universität Karlsruhe (TH) Fakultät für Informatik Institut für Programmstrukturen und Datenorganisation (IPD) Hauptseminar Imperfektion und erweiterte Konzepte im Data Warehousing Common Warehouse Metamodel und Imperfektion Seminararbeit von Christoph Goebel Sommersemester 2005

2

3 Inhaltsverzeichnis Abbildungsverzeichnis iii 5 Common Warehouse Metamodel und Imperfektion Einleitung Metadaten und Metadatenmanagement Bedeutung von Metadaten Metadatenmanagement Umsetzung des Metadatenmanagement Das Common Warehouse Metamodel (CWM) Die Schichten des CWM Der Austausch von Metadaten im CWM Erweiterungsmöglichkeiten Imperfektion in Datenbanken Der Begri der Imperfektion Theorien und Modelle zur Imperfektion Erweiterung des CWM zur Modellierung imperfekter Daten Erweiterung durch Stereotypes und TaggedValues Objektorientierte Erweiterung Fazit Literaturverzeichnis 19 i

4

5 Abbildungsverzeichnis 5.1 Metamodellarchitektur der OMG CWM-Schichtenmodell Erweiterung des Objekt-Modells durch Stereotypes und TaggedValues Zugehörigkeitsfunktionen a) scharf b) fuzzy Imperfekte Stereotypes Beispiel eines imperfekten Table-Objekts Ausschnitt des Core-Pakets Erweiterung des Core-Paketes um Möglichkeiten der Modellierung von Imperfektion iii

6

7 Christoph Goebel 5 Common Warehouse Metamodel und Imperfektion Die vorliegende Arbeit gibt einen Überblick über das Metadatenmanagement im Data Warehousing und stellt das von der Object Management Group (OMG) propagierte Common Warehouse Metamodel (CWM) vor. Ferner wird am Beispiel der Modellierung imperfekter Daten im Rahmen des OVID-Projektes der Universität Karlsruhe (TH) konkrekt demonstriert, inwieweit das CWM an neue Anforderungen angepasst werden kann. Dabei wird auf der Grundlage vorangegangener Arbeiten aufgebaut. 5.1 Einleitung Für alle Bereiche der Information Supply Chain (ISC) sind Metadaten von herausragender Bedeutung. Durch das Common Warehouse Model (CWM) der Object Management Group (OMG) ist ein neuer Standard für die Modellierung von Metadaten im Data Warehousing geschaen worden, der das Potential hat, die produktund herstellerübergreifende Integration der ISC entscheidend voranzubringen. In bestimmten Fällen reichen die grundsätzlichen Modellierungsmöglichkeiten des CWM jedoch nicht aus, um Metadaten hinreichend genau zu charakterisieren. Ein Beispiel hierfür ist die Modellierung imperfekter Daten, wie sie im Rahmen des OVID-Projektes der Universität Karlsruhe (TH) vorliegen. Imperfekte Daten sind unscharfe, unsichere oder ungenaue Daten, die im konventionellen Datawarehouseprozess gewöhnlich bereits durch die Extraktions-, Transformations- und Lade- Prozesse (ETL-Prozesse) bereinigt werden. In manchen Anwendungen ist jedoch der Erhalt der Imperfektion wünschenswert. Daher muss das CWM diesen Anforderungen entsprechend angepasst und erweitert werden. 1

8 5 Common Warehouse Metamodel und Imperfektion 5.2 Metadaten und Metadatenmanagement Bedeutung von Metadaten Der Prozess der Informationsgewinnung aus operativen, transaktionsorientierten Daten wird oft als Information Supply Chain (ISC) bezeichnet [PCTM03]. Dieser Begri stellt eine Analogie zum klassischen Forschungsbereich des Supply Chain Management her, der sich mit einer ezienten Organisation der Lieferkette, die der Produktion materieller Güter zugrunde liegt, befasst. Diese Analogie ist auch durchaus berechtigt, denn durch stete Verfeinerung und kontextbezogene Erweiterungen der ursprünglichen Rohdaten entstehen unter anderem durch die ETL- Prozesse und die gegebenenfalls später durchgeführten Data Mining-Prozesse und OLAP-Analysen Informationsgüter in Form von strategischen Geschäftsinformationen. Genau wie im Fall der klassischen Supply Chain ist eine reibungslose Erzeugung des Endprodukts nur dann möglich, wenn die unterschiedlichen Produktionsstufen miteinander kommunizieren können. Man stelle sich eine Endmontagelinie für Automobile vor: Es ist ein heiÿer Sommer und das Management beschlieÿt, fortan nur noch Cabriolets zu produzieren. Das Faltdach kann preiswert von einem polnischen Zulieferer bezogen werden, die polnischen Arbeiter können aber mit den Computerausdrucken, welche die Faltdachtechnik beschreiben, nicht viel anfangen. Beim letzten Faltdach-Zulieferer gab es diesbezüglich keine Probleme, da dieser die gleiche Entwurfssoftware einsetzte. In der Information Supply Chain kann es zu analogen Problemen kommen. Typischerweise werden für die verschiedenen Prozesse der ISC Werkzeuge verschiedener Hersteller verwendet. Die verschiedenen Reporting-Tools des einen Herstellers können aber eine vollkommen andere Sprache sprechen als der OLAP- Server eines anderen Herstellers. Alle Software-Tools, die Teil der ISC sein sollen, müssen demnach zunächst auf der Ebene der Metadaten integriert werden, bevor eine Integration auf Datenebene stattnden kann. Um die Struktur und semantische Bedeutung von Daten auf verschiedenen Stufen der ISC zu beschreiben, werden Metadaten verwendet. Metadaten sind bekanntlich Daten über Daten, in diesem Fall also jede Art von Information, die für den Entwurf, die Konstruktion und die Benutzung eines Informationssystems benötigt wird [BG04]. Sie können grundsätzlich auf drei unterschiedliche Arten genutzt werden: Passiv als konsistente Dokumentation aller Komponenten der Architektur des Data Warehouse für Anwender, Administratoren und Anwendungsentwickler. Aktiv, indem beispielsweise Transformationsregeln gespeichert werden, die von entsprechenden Werkzeugen interpretiert und ausgeführt werden. Semiaktiv, indem Metadaten beispielsweise zur Überprüfung von Strukturmerkmalen wie etwa Tabellendenitionen verwendet werden. 2

9 5.2 Metadaten und Metadatenmanagement Hierzu ein sehr einfaches Beispiel aus dem Bereich der relationalen Datenbanken: Eine Anwender möchte mit Hilfe eines OLAP-Tools die Umsatzentwicklung seines Unternehmens visualisieren und dazu auf eine relationale Datenbank zugreifen, in der er die Umsatzdaten der letzte Jahre vermutet. Er weiÿ aber nicht, ob die Daten wirklich vorhanden sind und wenn ja, wie sie strukturiert sind, insbesondere Bezeichnung der Relationen und Attribute sowie Datentypen. Zudem hat bereits ein Kollege vor ihm Berechnungsschemata für einige Umsatzkennzahlen erstellt, welche er wiederverwenden möchte. Solche Informationen können durch Metadaten beschrieben und über eine geeignete Kommunikationsinfrastruktur ausgetauscht werden Metadatenmanagement Das Metadatenmanagement beschäftigt sich mit der Frage, wie Metadaten sinnvoll beschrieben, gespeichert und verfügbar gemacht werden können. Durch die Integration nicht nur auf der Datenebene, sondern auch auf der Ebene der Metadaten soll letzlich der Entwicklungs- und Verwaltungsaufwand der ISC reduziert werden. 1 Dies kann durch kürzere Entwicklungszeiträume und die verbesserten Möglichkeiten zur Automatisierung von Prozessen erreicht werden. Ein weiterer potentiell positiver Aspekt eines konsequenten Metadatenmanagements kann die Erhöhung der Akzeptanz auch der Endanwender sein, da Transparenz und Qualität der Daten erhöht werden können. In [BG04] wird ferner der immer mehr an Bedeutung gewinnende Sicherheitsaspekt genannt: Benutzerrechte können ebenfalls als Metadaten abgelegt werden und zentral verwaltet werden Umsetzung des Metadatenmanagement Die verschiedenen Werkzeuge, die in der ISC Anwendung nden können, verwenden in der Regel bezüglich Syntax und Semantik heterogene Metadaten, schon aufgrund der Befürchtungen ihrer Hersteller, durch die Standardisierung Marktanteile zu verlieren [PCTM03]. In der Praxis werden daher oft sogenannte Meta Data Bridges konstruiert, die eine Art Übersetzungsmechanismus für Metadaten bei der Kommunikation zwischen jeweils zwei Anwendungen darstellt. Diese Form der Integration ist sehr aufwendig, da einerseits jede mögliche Kombination zweier Tools einer solchen Brücke bedarf und andererseits die Übersetzung der Metadaten bidirektional möglich sein muss. Um eine Standardisierung der Metadaten und deren eektive Verwaltung zu erreichen, muss zunächst die Modellierung von Metadaten vereinheitlicht werden, das heiÿt, für den Austausch von regelmäÿig vorkommenden Metadaten wie etwa Tabellendenitionen relationaler Datenbanken muss ein anwendungsübergreifendes Konstruktionsschema vorgegeben werden. Ein sol- 1 Betriebswirtschaftlich wird also eine Maximierung des Return on Investment (ROI) angestrebt. 2 Dieser Aspekt ist auch deshalb bedeutend, da ein Data Warehouse durchaus auch schützenswerte Einzeldaten enthalten kann, deren Aggregat allerdings wieder einem breiteren Publikum zur Verfügung gestellt werden soll. 3

10 5 Common Warehouse Metamodel und Imperfektion cher Standard ist das von der OMG propagierte Common Warehouse Meta Model (CWM), auf das in Abschnitt 5.3 näher eingegangen werden soll. Ferner ist auch die Architektur der Speicherung und Verwaltung von Metadaten von Bedeutung. Weitgehend Einigkeit besteht dahingehend, dass eine physikalische Abtrennung der Metadaten von den Daten in Form eines Metadaten-Repository Sinn macht. Für die Gewährleistung des Zugris der verschiedenen Warehouse-Anwendungen und die Sicherstellung der Konsistenz der vorgehaltenen Metadaten ist ein sogennanter Metadatenmanager verantwortlich. Die Zusammenfassung aller Metadaten einer ISC in einem einzigen Metadaten-Repository ist allerdings - obgleich häug vorgeschlagen - aus folgenden Gründen mit Vorsicht zu genieÿen: Die verschiedenen Data Warehouse-Komponenten werden in hohem Maÿe vom einwandfreien Funktionieren der zentralen Schnittstelle abhängig. Es wird gleichsam ein künstlicher Flaschenhals bei der Metadaten-Kommunikation geschaen. Die Realisierung des zentralen Metadaten-Repository und der entsprechenden Schnittstellen ist sehr aufwändig. 3 Eine komplett dezentralen Lösung, in der jedem Data Warehouse-Werkzeug sein eigenes Metadaten-Repository zugeordnet wird, birgt dagegen ein hohes Risiko bezüglich Inkonsistenzen. Zudem sind die einzelnen Repositorys zwar leichter zu realisieren, jedoch wird die Ausgestaltung der benötigten Kommunikationsinfrastruktur wiederum ungleich schwieriger. Zusammenfassend zeichnet sich also ein Tradeo zwischen beiden Modellen ab. In der Praxis ist daher oft die sogenannte föderierte Metadaten-Verwaltung anzutreen: Mehrere Metadatenspeicher werden unabhängig voneinander betrieben und verwaltet, jeweils auf der Grundlage eines allgemein gültigen Metadatenmodells wie dem CWM. Diese werden dann direkt miteinander verbunden. Basieren die Metadatenspeicher auf unterschiedlichen Metadatenmodellen, so stellen diese Verbindungen wiederum Meta Data Bridges dar. 5.3 Das Common Warehouse Metamodel (CWM) Das CWM stellt den Versuch dar, ein umfassendes Metamodell zur Beschreibung von Metadaten im Data Warehousing bereitzustellen. Bei der Spezikation des CWM hat sich die OMG an folgenden Richtlinien orientiert: Vollständigkeit Unabhängigkeit Kompatibilität 3 Insbesondere stellt jede ISC unterschiedliche Anforderungen an eine zentrale Metadaten- Speicherung, das heisst dass diese jeweils individuell konzipiert werden muss. Standardlösungen sind daher oft nicht einsetzbar. 4

11 5.3 Das Common Warehouse Metamodel (CWM) Erweiterbarkeit Verfügbarkeit Verständlichkeit Als abstraktes Modell ist das CWM vollkommen plattformunabhängig und kann so gleichsam als Übersetzungsreferenz für proprietäre Metadatenmodelle dienen (Unabhängigkeit, Kompatibilität): Sollen also Metadaten zwischen zwei Anwendungen innerhalb der ISC ausgetauscht werden, so kann Anwendung A ihre internen Metadaten in das durch das CWM vorgeschriebene Format übersetzen und Anwendung B die auf diese Weise standardisierten Metadaten wieder in ihr proprietäres Format rückübersetzen. Diese Übersetzung geschieht auf Anwendungsebene, das heiÿt die Metadaten-Kommunikation ndet direkt zwischen den verschiedenen CWM-kompatiblen Anwendungen oder gegebenenfalls durch den Umweg über ein Metadaten-Repository statt. Dies impliziert einerseits, dass das CWM eine hinreichend groÿe Menge von Konzepten, die im anwendungsübergreifenden Bereich vorkommen, beschreibt, und andererseits, dass ausreichende Erweiterungsmöglichkeiten bestehen, um semantische Lücken in einer ebenfalls standardisierten Art und Weise zu schlieÿen (Erweiterbarkeit). Um eine gewisse Übersichtlichkeit einerseits und auch eine Modularisierung 4 andererseits zu gewährleisten, ist das CWM je nach Art der zu beschreibenden konzeptuellen Domäne in verschiedene Pakete (die oftmals selbst als Metamodell bezeichnet werden) unterteilt worden, wobei die Anzahl der Verbindungen eines Pakets zu den anderen auf ein Minimum reduziert wurde. Jedes dieser Pakete enthält demnach ein Modell für ein Modell (Metamodell), welches zur Beschreibung von in bestimmten Bereichen der ISC auftretenden Daten verwendet werden kann. Beispielsweise ist ein Paket Relational entwickelt worden, welches Metakonzepte wie Table und Column deniert. Um einer Verwirrung ob der vielen Abstraktionsebenen vorzubeugen, sind diese noch einmal in übersichtlicher Art und Weise in Abbildung 5.1 dargestellt. Wie man sieht, existiert in der Terminologie der OMG oberhalb des UML- und CWM-Metamodells (M2) noch eine weitere Abstraktionsebene (M3). Auf dieser obersten Abstraktionsebene ist die Meta Object Facility (MOF) angesiedelt, welche eine gemeinsame abstrakte Sprache zur Spezikation von Metamodellen deniert. Die MOF ist sowohl Grundlage der UML als auch des CWM. Alle Metadaten-Modelle nutzen die durch die UML vorgegebenen Notationen (Syntax), wenn auch im Fall der MOF in sehr restriktiver Form. Die Aufteilung der Modelle auf verschiedene Abstraktionsebenen bezieht sich lediglich auf ihre Semantik. In Abschnitt 5.1 ist auch der Bereich des Datenaustauschs erfasst. Man sieht, dass sich die Beschreibung der serialisierten Metadaten auf ähnliche Weise 4 Diese Aufteilung kann unter anderem zur Optimierung der Architektur der Metadatenspeicher nützlich sein. Auf derselben Ebene einer hierarchischen Metadaten-Architektur kann so die Kommunikation auf bestimmte Pakete des CWM beschränkt werden. Näheres hierzu ndet sich in [PCTM03]. 5

12 5 Common Warehouse Metamodel und Imperfektion Abbildung 5.1: Metamodellarchitektur der OMG Abbildung 5.2: CWM-Schichtenmodell vollzieht wie die Beschreibung ihrer internen Repräsentation. Auch hier können die verwendeten Modelle den verschiedenen Abstraktionsebenen zugeordnet werden. Die Pakete des CWM sind in insgesamt fünf Schichten angeordnet, wobei die oberen Schichten auf den unteren aufbauen und deren Konzepte gegebenenfalls erweitern. Eine Modularisierung wird insofern erreicht, als dass der Entwickler einer ISC nur diejenigen Pakete des CWM benutzen muss, die auch wirklich benötigt werden. Abbildung 5.2 gibt einen Überblick über die verschiedenen Pakete Die Schichten des CWM Auf der untersten Ebene (Object Model) werden die grundlegenden Elemente, auf denen alle Konzepte der höheren Schichten aufbauen, festgelegt. Es ist aus den vier Paketen Core, Behavioral, Relationships und Instance aufgebaut. Das Core-Paket enthält die statischen Grundbausteine der UML, beispielsweise die Objekte Ele- 6

13 5.3 Das Common Warehouse Metamodel (CWM) ment, Attribute etc. Das Behavioral-Paket ergänzt diese statischen Elemente durch verhaltensbezogene Elemente wie etwa Methoden. Im Paket Relationships werden verschiedene Arten von Beziehungen modelliert, die Objekte des CWM eingehen können, beispielsweise Assoziationen und Generalisierungen. Das Instance-Paket schlieÿlich enthält Modellelemente, die dazu benutzt werden können, Instanzen bestimmter Klassen zu repräsentieren. Dieses Paket ist auch deshalb interessant, weil es später dazu verwendet werden kann, ausnahmsweise auch echte Daten im CWM zu transportieren. Ein typisches Beispiel für solche Daten wären feste Wertebereiche der Spalte einer Tabelle. Auf der nächsten Schicht (Foundation), die aus den sechs Paketen Business Information, Data Types, Expressions, Keys and Indexes, Software Deployment und Type Mapping besteht, werden aufbauend auf den einfacheren Elementen des Object Model allgemeine Konzepte deniert, die ebenfalls in allen Bereichen des CWM von Bedeutung sind. Das Paket Business Information bildet die Grundlage zur Einbeziehung beschreibender Informationen und Ansprechpartner. Durch das Data Types-Paket werden Elemente im Object Model so erweitert, dass gegebenenfalls neue Datentypen deniert werden können. Das Paket Expressions bietet die Möglichkeit, Ausdrücke wie sie zum Beispiel auch in Programmiersprachen vorkommen, auf der Modellebene zu beschreiben. Indizes und Schlüssel, die vor allem im relationalen, aber auch im multidimensionalen Modell eine entscheidende Rolle spielen, werden im Paket Keys and Indexes beschrieben. Das Paket Software Deployment ermöglicht die Beschreibung von Software aus Komponenten und deren Betrieb. Das Type Mapping-Paket gibt schlieÿlich die Mittel her, um Mappings zwischen unterschiedlichen Datentypen zu modellieren. Dies ist oensichtlich sehr wichtig, da ja gerade die Kompatibilität unterschiedlicher Software-Tools gewährleistet werden soll. Die nächsthöhere Schicht des CWM (Resource) enthält Modelle, die typische Datenquellen einer ISC beschreiben. Das Relational-, Record-, Multidimensionalund XML-Paket erweitern jeweils Konzepte der beiden darunterliegenden Schichten und modellieren Metadaten, die unter anderem relationale Datenbanken, multidimensionale Datenbanken und XML-basierte Datenquellen beschreiben. Das Object-Paket ist nur der Vollständigkeit halber in die Resource-Schicht des CWM aufgenommen worden, denn alle Konzepte, die für die Modellierung einer objektorientierten Datenquelle benötigt werden, sind bereits in den Schichten Foundation und Object Model vorhanden. Auf der Analysis-Schicht sind diejenigen Konzepte modelliert worden, die im OLAP-Bereich und Data Mining Verwendung nden (OLAP, Data Mining, Information Visualization, Business Nomenclature). Auÿerdem ist hier auch das Paket Transformation angesiedelt, welches dazu benutzt werden kann, um Quell- und Zielmappings zu modellieren und entsprechende Transformationsvorschriften zu beschreiben. Diese Transformationen können sowohl zwischen unterschiedlichen Datenquellen der darunterliegenden Schicht als auch zwischen der Resource- und der Analysis-Schicht stattnden. Ein typischer Anwendungsbereich ist die Verschiebung von Datenbeständen von einem Speicherbereich der ISC in einen anderen, bei- 7

14 5 Common Warehouse Metamodel und Imperfektion spielsweise das Laden von Daten aus dem Arbeitsbereich in das eigentliche Data Warehouse. Die Management-Schicht des CWM beschreibt Möglichkeiten zur Modellierung von Metadaten, welche die ISC als Ganzes betreen, insbesondere Servicefunktionen des Data-Warehouse-Systems zur Steuerung und Kontrolle des Analyseprozesses. Mit Hilfe des Warehouse Process-Pakets können zum Beispiel die Metadaten eines typischen ETL-Prozess modelliert werden. Im Paket Warehouse Operation benden sich Konstrukte zur Dokumentation von Ereignissen im Data Warehouse- Prozess Der Austausch von Metadaten im CWM Mit diesem gemeinsamen Gerüst zur Beschreibung der in der ISC kursierenden Metadaten ist der erste Schritt hin zu mehr Eektivität und Ezienz bei der Datenverarbeitung im Data-Warehouse-Prozess getan. Es muss jedoch auch die entsprechende Infrastruktur zur Verfügung gestellt werden, die einen tatsächlichen Austausch der gemäÿ den verschiedenen Metamodell-Paketen konstruierten Metadaten ermöglicht. Hierzu sind im CWM zwei Varianten vorgesehen. Einerseits können die Metadaten über eine spezielle durch die Interface Denition Language (IDL) denierte Schnittstelle ausgetauscht werden, das heiÿt eine an der ISC beteiligte Software greift auf die zentral verwalteten Metadaten des CWM über eine Programmier-Schnittstelle zu. Diese IDL-Schnittstellen beschreiben den Zugri auf die in den verschiedenen CWM-Paketen enthaltenen Metadatenobjekte. Andererseits besteht auch die Möglichkeit, Metadaten in Form von XML-Dateien auszutauschen. Hierzu bietet die OMG ein spezielles XML-basiertes Format zum Austausch von Metadaten in und zwischen Software-Systemen an, das XML Metadata Interchange (XMI). Dieses Format ist in entsprechenden Document Type Denitions (DTD) bzw. XML-Schemata festgelegt, das heiÿt es wird eine regelbasierte Erzeugung und Validierung von XMI-Dokumenten ermöglicht. Dabei werden die Metadaten derart serialisiert, dass jede Metadaten-Instanz als XML-Elementinhalt innerhalb eines entsprechenden Metamodel-Tags gespeichert wird (siehe auch Abbildung 5.1) Erweiterungsmöglichkeiten Das CWM erhebt den Anspruch, einen exiblen Rahmen für Spezikation und Austausch von Metadaten im Data Warehousing bereitzustellen. Daher sind auch standardisierte Formen der Erweiterung vorgegeben worden, die es ermöglichen, das CWM an die Anforderungen bestimmter Anwendungen anzupassen. Das CWM sieht zwei grundsätzlich verschiedene Erweiterungskonzepte vor: Den Einsatz von Stereotypes und TaggedValues sowie die objekt-orientierte Erweiterung. Stereotypes und TaggedValues Stereotypes sind spezielle Labels, die gleichsam an Klassen angehängt werden können, um deren Verwendung näher zu beschreiben. 8

15 5.3 Das Common Warehouse Metamodel (CWM) Abbildung 5.3: Erweiterung des Objekt-Modells durch Stereotypes und TaggedValues Ihre Klasse ist in der Vererbungshierarchie des Core-Pakets direkt unterhalb der zentralen Klasse ModelElement angesiedelt, das heiÿt, alle Klassen des CWM erben die Eigenschaft, als Anhängsel Stereotype-Objekte haben zu können. Abbildung 5.3 zeigt die Beziehungen zwischen ModelElement, Stereotype und TaggedValue. TaggedValues sind Name-Wert-Paare, die in beliebiger Anzahl mit einem Stereotype assoziiert werden können. Sie können dazu benutzt werden, anwendungsspezische Attribute zu speichern. Ein gewichtiger Nachteil der TaggedValues ist, dass sie die in ihnen gespeicherten Werte nur das String-Format besitzen können. Das bedeutet, dass speziellere Datenformate bei der Metadatenübertragung im Warehouse-Prozess ohne zusätzliche Kommunikation der Komponenten verloren gehen. Objektorientierte Erweiterung Grundsätzlich stehen zur Erweiterung des CWM auch alle OO-Techniken wie Vererbung, Spezialisierung, das Hinzufügen von Attributen und Assoziationen zur Verfügung. Ein typisches Beispiel hierzu wäre die Modellierung einer eigenen Metaklasse, die von einer Standard-Metaklasse des CWM erbt. Diese neue Metaklasse kann dann beliebig durch spezielle Attribute erweitert und mit anderen neuen Metaklassen assoziiert werden. Dieser Erweiterungsmechanismus erscheint auf den ersten Blick sehr mächtig. In der Tat kann man das CWM dadurch auf beliebige Art und Weise erweitern, ohne dabei dessen ursprüngliche Struktur, welche Grundlage des standardisierten Austauschs von Metadaten ist, zu verändern. Trotzdem sollte man sich vergegenwärtigen, dass alle Metadaten einer Anwendung, die auf einer objekt-orientierten Erweiterung des CWM basiert, von anderen Anwendungen, auch wenn diese den CWM-Standard unterstützen, nicht verstanden werden können. Echte Kompatibilität kann dann nur dann erreicht werden, wenn all diese Anwendungen dieselbe Erweiterung einsetzen. Natürlich reicht es in den Fällen, in denen das erweiterte Metamodell nur anwendungsintern genutzt wird aus, wenn zum Beispiel Speziali- 9

16 5 Common Warehouse Metamodel und Imperfektion sierungen rückgängig gemacht werden (Upcasting), also nur das CWM-kompatible Eltern-Objekt an andere Anwendungen übertragen wird. Es kann davon ausgegangen werden, dass im Zuge der Umstellung von UML 1.3 auf UML 2.0 auch die Konzeption des CWM angepasst werden wird. Insbesondere werden davon auch die Erweiterungsmechanismen betroen sein. In UML 2.0 können anwendungsspezische Konstrukte durch das neu eingeführte UML-Proling modelliert werden. Details hierzu können der Studienarbeit von Nils Hilt [Hil05] entnommen werden. 5.4 Imperfektion in Datenbanken Dieser Abschnitt führt kurz in die Problematik von imperfekten Daten deren Speicherung in Datenbanken ein. Er ist gröÿenteils den Arbeiten von Erik Koop [Koo04], Andreas Merkel [Mer04], Alexander Haag [Haa04] und Nils Hilt [Hil05] entnommen Der Begri der Imperfektion Imperfekte Information ist Information, die einen Sachverhalt nur unvollständig oder unvollendet beschreibt. In [Koo04] wird imperfekte Information in drei Kategorien wie folgt eingeteilt. Unsichere Information Eine Information ist unsicher, wenn aufgrund der verfügbaren Daten nicht festgestellt werden kann, ob sie wahr oder falsch ist. Unscharfe Information Eine Information wird als unscharf bezeichnet, wenn sie nicht eindeutig klassiziert werden kann. Dies setzt voraus, dass der Übergang zwischen den denierten Klassen ieÿend sein kann. Ungenaue Imformation Eine Information ist ungenau, wenn sie nur mittels eines Intervalls oder ähnlich grober Klassizierungsarten angegeben werden kann Theorien und Modelle zur Imperfektion Zur Darstellung imperfekter Informationen existieren zwei grundsätzlich verschiedene formale Ansätze: Die klassische Wahrscheinlichkeitstheorie und die etwas neuere Fuzzy-Theorie. Wahrscheinlichkeitstheorie Die Wahrscheinlichkeitstheorie hat die Aussagenlogik zur Grundlage, derzufolge eine Aussage nur entweder wahr oder falsch sein kann bzw. ein bestimmtes Ereignis nur entweder vollständig oder gar nicht eintreten kann, das heiÿt, an der grundsätzlichen Qualität eines Ereignisses wird nicht gerüttelt. Wirft man eine Münze, so kann man, nachdem die Münze liegengeblieben ist, mit Sicherheit sagen, ob die Aussage Münze zeigt Kopf wahr oder falsch 10

17 5.4 Imperfektion in Datenbanken ist. Allerdings wird die Wahrscheinlichkeit des Eintritts eines Ereignisses bzw. der Grad der Überzeugung, dass eine bestimmte Aussage zutrit, gleichsam separat durch das sogenannte Wahrscheinlichkeitsmaÿ gemessen. Im Fall der Münze kann man normalerweise annehmen, dass die Wahrscheinlichkeit für das Ereignis Münze zeigt Kopf bei 50% liegt. Die Wahrscheinlichkeitstheorie eignet sich somit ideal für die Modellierung von unsicherer Information: Es genügt die Angabe der möglichen Aussagen bzw. Ereignisse und des zugehörigen Wahrscheinlichkeitsmaÿes, um die unsichere Information hinreichend genau zu charakterisieren. Fuzzy-Theorie Die Fuzzy-Theorie setzt in ihrer Charakterisierung einer Aussage bereits auf der Stufe der tatsächlichen Ausprägung an. Sie erweitert die Aussagenlogik um Zwischenstufen zu wahr und falsch beziehungsweise teilt Ereignisse in unscharfe Mengen, die sogenannten Fuzzy-Mengen ein [Hil05]. In der klassischen Mengenlehre wird eine Menge durch eine ihr zugeordnete charakteristische Funktion beschrieben. Für ein beliebiges Element gibt diese gewöhnlich an, ob es zur beschriebenen Menge gehört oder nicht. 5 Die Bildmenge der klassischen charakteristischen Funktion ist also binär. Der Fuzzy-Theorie zufolge ist die Bildmenge einer normalisierten charakteristischen Funktion zur Denition einer Fuzzy-Menge das gesamte kontinuierliche Einheisintervall [0,1]. Die Fuzzy- Menge gibt demnach den Zugehörigkeitsgrad eines Elements zu einer Menge an [Hil05]. Beispiel: Bekanntlich kann man aus den drei Primärfarben Gelb, Rot und Blau alle anderen Farben durch Mischen herstellen. Angenommen wir wollen die Farb- ächen eines Bildes (farblich) klassizieren, aber wegen der groÿen Anzahl der möglichen Farben nicht eine Klasse für jeden Farbton bereithalten. Hier könnte man einfach die drei Primärfarben als Klassen angeben und die ihnen zugeordneten Mengen von Farbächen als Fuzzy-Mengen mit entsprechenden Zugehörigkeitsfunktionen beschreiben. Für eine reine grüne Farbäche würde dann sowohl die Zugehörigkeitsfunktion der Fuzzy-Menge Gelb als auch die der Fuzzy-Menge Blau eine Zugehörigkeit von 0,5 ergeben, da sich ein reines Grün aus jeweils gleichen Anteilen der Primärfarben Gelb und Blau zusammensetzt. Vergleicht man den Begri der unscharfen Information mit den Aussagen der Fuzzy-Theorie, so kann man sehen, dass sich unscharfe Informationen gut durch die charakteristische Funktion von Fuzzy-Mengen beschreiben lassen. Linguistische Variable Eine linguistische Variable hat als Wertebereich verbale Begrie, sogenannte Terme. Bezeichnet x eine linguistische Variable, T (x) die Menge der möglichen Ausprägungen von x und e ein bestimmtes Ereignis aus der Grundmenge U, so kann für jedes Element e U und jeden Term t T (x) der Zugehörigkeitsgrad von e zu t bestimmt werden. 5 Diese Beziehung entspricht dem Begri des Enthaltenseins aus der klassischen Mengenlehre 11

18 5 Common Warehouse Metamodel und Imperfektion Abbildung 5.4: Zugehörigkeitsfunktionen a) scharf b) fuzzy scharf Äquivalenzklasse scharfe Klasse Enthaltensein scharfe Zugehörigkeitsfunktion unscharf Term unscharfe Klasse Zugehörigkeit unscharfe Zugehörigkeitsfunktion Tabelle 5.1: Gegenüberstellung der korrespondierenden Begrie für scharfe und unscharfe Einteilungen Bei der Modellierung von ungenauen Informationen mit Hilfe von linguistischen Variablen kann es grundsätzlich zu zwei Fällen kommmen. Entweder kann man einen Wert immer genau einem Term zuordnen, d. h. der normalisierte Zugehörigkeitsgrad dieses einen Terms ergibt für diesen Wert 1 und der aller anderen Terme 0. In diesem Fall spricht man auch von scharfen Klassen. Oder der Wert wird jeweils zu einem gewissen Grad mehreren Termen zugeordnet, das heiÿt die Zuordnung ist unscharf oder fuzzy (unscharfe Klassen). Die aus [Haa04] entnommene Abbildung 5.4 zeigt in a) den Fall einer scharfen Zugehörigkeitsfunktion und in b) eine einfache Fuzzy-Zugehörigkeitsfunktion, die graphisch durch einen Trapezoiden dargestellt werden kann. In Tabelle 5.1 werden die in diesem Abschnitt eingeführten Begrie der Übersichtlichkeit zuliebe einander noch einmal direkt gegenübergestellt. 5.5 Erweiterung des CWM zur Modellierung imperfekter Daten In diesem Abschnitt sollen kurz die Ergebnisse der Arbeiten von Alexander Haag [Haa04] und Nils Hilt [Hil05] bezüglich Erweiterungsmöglichkeiten des CWM zur Modellierung imperfekter Daten zusammengefasst werden. Bezüglich der objektorientierten Erweiterung wird ein auf UML 1.3 basierender Ansatz vorgestellt, der eine möglichst einfache Modellierung der Imperfektion für alle relevanten Konzepte 12

19 5.5 Erweiterung des CWM zur Modellierung imperfekter Daten Abbildung 5.5: Imperfekte Stereotypes des CWM beschreibt Erweiterung durch Stereotypes und TaggedValues Die Erweiterung durch Stereotypes und TaggedValues hat wie oben beschrieben den Vorteil, dass sie auch dann erhalten bleibt, wenn bestimmte Anwendungen der ISC nicht explizit an die Erweiterung angepasst worden sind. Alexander Haag hat in seiner Arbeit beispielhaft die Klasse Table des Relational-Pakets des CWM als Ansatzpunkt für die Erweiterung herausgegrien. Wie aus Abbildung 5.3 ersichtlich, müssen neue Stereotypes und TaggedValues im Core- Paket modelliert werden. Zunächst wird eine Klasse ImperfectionStereotype erstellt, von der alle Klassen erben, die im Rahmen der Erweiterung durch imperfekte Daten hinzugefügt werden. Um anzuzeigen, dass eine Tabelle imperfekte Daten erhält wird sie mit dem Stereotype Imperfect Table gekennzeichnet. Die entsprechende Klasse ist ImperfectTableStereotype. Jede Form der Imperfektion wird jeweils durch eine Klasse modelliert: die Klassen UncertainStereotype, FuzzyStereotype und ImpreciseStereotype erben von der Klasse ImperfectionStereotype. Abbildung 5.5 stellt diese Beziehungen graphisch dar. Abbildung 5.6 zeigt ein Table-Objekt der Relation Verkehrsmeldung, die im Rahmen des OVID-Projekts verwendet werden soll. Die Spalten Start- und Endkilometer sowie Fluss und Störungstyp sind jeweils mit einem Stereotype versehen, um anzuzeigen, dass die in ihnen abgelegten Daten imperfekt sind. In den angehängten TaggedValues wird auf die jeweiligs anzuwendende Zugehörigkeits- oder 13

20 5 Common Warehouse Metamodel und Imperfektion Abbildung 5.6: Beispiel eines imperfekten Table-Objekts Wahrscheinlichkeitsfunktion verwiesen. Der Nachteil dieser Methode zur Modellierung von imperfekten Daten liegt auf der Hand: Die jeweilige Qualität der Imperfektion kann nur in textueller Form durch die TaggedValues beschrieben werden, eine explizite Modellierung, die auch eine automatisierte Verarbeitung imperfekter Daten ermöglichen würde, kann mit diesem Ansatz nicht erreicht werden. Im folgenden Abschnitt wird daher die Möglichkeit der expliziten Erweiterung des CWM zur Modellierung von imperfekten Daten untersucht Objektorientierte Erweiterung Erster Schritt in Richtung einer objektorientierten Erweiterung des CWM muss immer die Spezikation der an die Erweiterung gestellten Anforderungen sein. Die Modellierung imperfekter Daten soll im gesamten Warehouse-Prozess möglich sein, da die Imperfektion durchgängig von der Erhebung der Daten bis zur analytischen Auswertung durch OLAP-Tools erhalten bleiben soll. Würde man wie in [Haa04] als Ansatzpunkt das Relational-Paket wählen, so könnte man Imperfektion nur im Umfeld relationaler Datenquellen beschreiben. Informationen sind jedoch imperfekt unabhängig davon, durch welches Datenmodell sie beschrieben werden [Hil05]. Sucht man nun ausgehend von der Resource-Schicht des CWM nach dem nächsthöheren Ansatzpunkt zur Beschreibung von Imperfektion, so stöÿt man durchgängig auf die (Meta-)Klasse Attribute aus dem Core-Paket, welches in Abbildung 5.7 dargestellt ist. Dies hängt auch mit der systematischen Konstruktion der Resource-Schicht zu- 14

21 5.5 Erweiterung des CWM zur Modellierung imperfekter Daten Abbildung 5.7: Ausschnitt des Core-Pakets 15

22 5 Common Warehouse Metamodel und Imperfektion sammen: Alle grundlegenden Klassen eines Pakets auf dieser Ebene haben eine korresondierende Klasse in einem anderen Paket. 6 Eine spezielle Anforderung bei der Modellierung von Unsicherheit ist, dass Unsicherheit auf unterschiedlichen Granularitätsstufen auftreten kann. Beispielsweise kann im Fall einer Staumeldung der Meldung pauschal misstraut werden oder nur einer einzelnen in ihr enthaltenen Information wie etwa der Staulänge. 7 Daher muss eine objekt-orientierte Erweiterung ausreichend hoch in der Vererbungshierarchie des Core-Pakets ansetzen, um insbesondere unsichere Daten auf allen Granularitätsstufen der Informationsmodellierung beschreiben zu können. In [Hil05] wird zunächst die Classier-Klasse des Core-Pakets als höchster Ansatzpunkt für die Modellierung von Unsicherheit verwendet. Damit soll erreicht werden, dass auch ganze Tabellen als unsicher eingestuft werden können. Es ist jedoch fraglich, ob dieser Fall in der Realität überhaupt vorkommt, da eine relationale Tabelle lediglich ein Konstrukt zur Datenhaltung ist und keine Entsprechung in der realen Welt ndet. Weiter wird die Klasse Datatype des Core-Pakets erweitert, um spezielle Datentypen zu spezizieren, welche die Speicherung imperfekter Daten ermöglicht. Es ist beispielsweise denkbar, ungenau Daten gleich in Form von Intervallen zu speichern. Obgleich dieser Ansatz natürlich sehr interessant ist, unterscheidet er sich grundsätzlich von dem in [Haa04] dargestellten Vorgehen, wo Daten in herkömmlicher Form abgespeichert werden und gleichsam nachträglich einem semantischen Kontext zugeordnet werden. Der jeweilige Ansatz sollte einer einheitlichen Modellierung zuliebe konsequent verfolgt werden. In dieser Arbeit soll der von [Haa04] vorgeschlagene Ansatz weitergeführt werden: Ziel dabei ist es, nicht nur das Relational-Paket, sondern alle Pakete der Resource-Schicht durch Imperfektion erweiterbar zu machen. Als allgemeiner Anknüpfungspunkt kommt die Attribute- Klasse in Betracht. Im Falle der Unsicherheit beispielsweise eines ganzen Tupels kann dies durch ein zusätzliches Attribut modelliert werden. Wie in [Haa04] vorgestellt, kann die Konkretisierung der verschiedenen Formen der Imperfektion durch die Assoziierung der entsprechenden Klassen (beispielsweise der Column-Klasse im relationalen Datenmodell) mit Funktionen erfolgen. Die verschiedenen zur Beschreibung imperfekter Daten geeigneten Funktionen müssen ebenfalls in Form von Klassen modelliert und dem CWM hinzugefügt werden. Es ergibt sich wiederum eine Hierarchie, die als Ursprung die Klasse ModelElement des Core-Pakets hat. Durch die Erweiterung der Attribute-Klasse des Core-Pakets und eine entsprechende Assoziierung mit beschreibenden Funktionen könnte Imperfektion in die Modellierung aller relevanten Konzepte des CWM miteinbezogen werden. Abbildung 5.8 fasst diese Ideen zusammen. Natürlich müsste die Assoziation Dened- ByFunction noch mit geeigneten Restriktionen versehen werden, die sicherstellen, dass beispielsweise ein UncertainAttribute nur durch eine ProbabilityFunction be- 6 Beispielsweise korrespondiert die Klasse Table des Relational-Pakets mit der Klasse Dimension des Multidimensional-Pakets 7 Übertragen auf das relationale Modell bedeutet dies, dass sowohl eine ganzes Tupel als auch einzelne Attributwerte einer Relation als unsicher angesehen werden können. 16

23 5.6 Fazit Abbildung 5.8: Erweiterung des Core-Paketes um Möglichkeiten der Modellierung von Imperfektion schrieben werden kann. 5.6 Fazit Der Nutzen einer semantischen Integration der Information Supply Chain ist durch obige Ausführungen umrissen worden. Die OMG propagiert mit dem Common Warehouse Metamodel und entsprechenden Vorschlägen für die Systemarchitektur einen potentiell mächtigen Standard für das Metadatenmanagement. Aus obigen Ausführungen lassen sich jedoch bereits einige Schwachstellen des Entwurfs erkennen. So legt die OMG explizit wert auf die Vollständigkeit der Modellierung. Dieses Kriterium erscheint deshalb so wichtig, da ein einheitlicher Standard zum Metadatenaustausch erst dann interessant wird, wenn auch möglichst viele Konzepte durch diesen Standard beschrieben werden können. Eine vollständige und ausgewogene Berücksichtigung aller Konzepte im Data Warehousing ist jedoch äuÿerst schwierig, da die Anforderungen in diesem Bereich sehr stark variieren und sich ständig weiterentwickeln. Von Experten wird beispielsweise bemängelt, dass wichtige Bereiche wie Berechtigungen, Semantik von Inhalten, Qualitätsmanagement, Berichtswesen und Unterstützung organisatorischer Prozesse ausspart werden. Auch im Hinblick auf das Kriterium der Erweiterbarkeit ergeben sich Probleme. Wie bereits dargestellt ist der einfache Erweiterungsmechanismus basierend auf Stereotypes und TaggedValues nur sehr eingeschränkt einsetzbar. Die objekt-orientierte Erweiterung dagegen muss von allen an dem entsprechenden Metadatenaustausch beteiligten Anwendungen implementiert werden. Dies ist insbesondere in solchen Fällen problematisch, in denen eine bestimmte Semantik den gesamten Warehouse- 17

24 5 Common Warehouse Metamodel und Imperfektion Prozess hindurch erhalten bleiben soll, wie beispielsweise die Imperfektion von Daten. Die im Rahmen des OVID-Projektes der Universität Karlsruhe (TH) thematisierte Imperfektion von Daten ist durch beide Erweiterungsmöglichkeiten des CWM darstellbar, allerdings erönet lediglich die objekt-orientierte Erweiterung die Möglichkeit, mit imperfekten Daten zu rechnen, also beispielsweise Aggregationen über Fuzzy-Attributwerte durchzuführen. 18

25 Literaturverzeichnis [BG04] A. Bauer and H. Günzel. Data Warehouse Systeme. dpunkt.verlag, [Haa04] A. Haag. Konzeption und Umsetzung einer Erweiterung des Common Warehouse Metamodels (CWM) zur Beschreibung von imperfekten Daten. Studienarbeit, IPD, Universität Karlsruhe (TH). http: // [Hil05] N. Hilt. Anpassung eines Metamodells zur Beschreibung imperfekter Informationen in einem Data-Warehouse-System. Studienarbeit, IPD, Universität Karlsruhe (TH). Public/, [Koo04] E. Koop. Datenbankunterstützung für imperfekte Daten im Verkehrsumfeld. Diplomarbeit, IPD, Universität Karlsruhe (TH). http: // [Mer04] A. Merkel. Konzeption und Umsetzung einer Schemaerweiterung durch Kontexte unter Berücksichtigung von Aggregierungsanfragen. Studienarbeit, IPD, Universität Karlsruhe (TH). ~ovid/public/, [PCTM03] J. Poole, D. Chang, D. Tolbert, and D. Mellor. Common Warehouse Metamodel, Developer's Guide. OMG Press,