Blockseminar Data Warehousing Meta
Werbung
Blockseminar Data Warehousing Sommersemester 2005 Prof. Dr. Klaus Küspert Lehrstuhl für Datenbanken und Informationssysteme Blockseminar Data Warehousing Meta-Daten Marek Opuszko Student der Wirtschaftsinformatik 61332 Betreuer: Dipl.-Inf. David Wiese 1 Einleitung ......................................................................................................................... 1 2 Das Multidimensionale Datenmodell............................................................................. 1 2.1 Einleitung ................................................................................................................... 1 2.2 Elemente des multidimensionalen Datenmodells ...................................................... 2 3 Meta-Daten ...................................................................................................................... 3 3.1 Definition ................................................................................................................... 3 3.2 Klassifikation von MD ............................................................................................... 4 3.3 Wozu MD? ................................................................................................................. 5 3.4 MD-Modellierung ...................................................................................................... 6 3.5 Anforderungen an die Repositories............................................................................ 6 4 Modelle und Standards................................................................................................... 8 4.1 MD Referenzmodelle ................................................................................................. 8 4.2 Repository Standards................................................................................................ 10 4.3 Austausch-Standards ................................................................................................ 10 4.4 Kommerzielle MD Management Lösungen............................................................. 11 4.5 Forschungsansätze.................................................................................................... 12 5 Literatur......................................................................................................................... 14 -1- 1 Einleitung Um einen effizienten Betrieb eines komplexen Data-Warehouse zu gewährleisten sind qualitativ hochwertige Meta-Daten eine existenzielle Voraussetzung. Grund dafür ist die Tatsache, dass Meta-Daten alle Prozesse des Data-Warehouse umspannen. Meta-Daten werden nicht nur zur Datenbeschaffung, wie in den ETL Teilbereichen Extract, Transform und Load, benötigt sondern vor allem auch in der späteren Analyse, also der Informationsextraktion, sowie beim Datenzugriff, der Benutzerführung und der Dokumentation. Die rolle von Meta-Daten im Kontext eines Data-Warehouse näher zu betrachten, soll nun Ziel dieser Arbeit sein. Die Ausarbeitung ist wie folgt aufgebaut: Im zweiten Kapitel wird das multidimensionale Datenmodell vorgestellt und die Elemente, die selbiges charakterisieren, näher erläutert. In Kapitel drei wird der Begriff der Meta-Daten definiert, eine Klassifikation vorgenommen, die Gründe für Meta-Daten-Management und dessen Modellierung sowie eine Beleuchtung der Anforderungen an Meta-Daten Repositories aufgezeigt. Das letzte Kapitel befasst sich mit Modellen und Standards, die in diesem Zusammenhang eine Rolle spielen. Referenzmodelle, Repository-Standards und AustauschStandards werden vorgestellt. Darüber hinaus wird noch ein Überblick über kommerzielle Meta-Daten-Management-Lösungen gegeben und ein Fokus auf Forschungsaktivitäten in diesem Bereich gelenkt. 2 Das Multidimensionale Datenmodell 2.1 Einleitung Das multidimensionale Datenmodell ist in besonderem Maße an die Anforderungen der Datenanalyse (bzw. Data Mining) ausgerichtet, die ja einer der Hauptaufgabengebiete eines Data-Warehouse darstellt. Spezifische Anfragoperatoren und –techniken, die den Begriff OLAP charakterisieren, sind hier von großer Bedeutung. Das Multidimensionale Datenmodell (MDDM) wird meist anhand der „Würfel Metapher“ verdeutlicht wie Abbildung 1 zeigt. -2- Abbildung 1 – Ein Datenwürfel (oder auch Cube) Natürlich lässt diese Veranschaulichung nur einen „Würfel“ mit maximal drei Dimensionen zu. Das MDDM schränkt die Modellierungsmächtigkeit zu Gunsten einer leichteren Navigation durch den Datenbestand und einer adäquaten Unterstützung auf systemtechnischer Ebene ein[Leh03]. Im Mittelpunkt des MDDM stehen vor allem die Kennzahlen (wie Umsatz, Gewinn etc.), die für betriebwirtschaftliche Analysen eine immense Bedeutung einnehmen. Jeder Punkt (Idealfall) im Datenwürfel enthält eine solche Kennzahl wie „erzielter Umsatz“ für eine bestimmte Kombination aus beispielsweise Produkt, Zeit und Kunde (im obigen Beispiel). Die Kanten des Würfels ergeben die Dimensionen, welche eine Betrachtung der Kennzahlen aus unterschiedlichen Perspektiven darstellen. Darüber hinaus ist innerhalb dieser Dimensionen eine Hierarchienbildung möglich, auf welche im nächsten Abschnitt näher eingegangen wird. 2.2 Elemente des multidimensionalen Datenmodells Als erstes und wichtigstes Element ist die Kennzahl zu nennen. Häufig wird der Begriff Fakt synonym verwendet. Um eine genaue Klassifikation vorzunehmen kann man festhalten, dass aus Fakten oder Basiskennzahlen die eigentlichen Kennzahlen oder abgeleitete Kennzahlen entstehen. Kennzahlen beschreiben vor allem betriebswirtschaftliche Sachverhalte. Durch Anwendung arithmetischer Operatoren werden aus Fakten Kennzahlen gewonnen. Es können jedoch auch Kennzahlen wieder aus Kennzahlen entstehen. Zusammen mit einem Dimensionsschema ergeben Fakten und Kennzahlen einen multidimensionalen Datenwürfel. Eine Kennzahl ist wie folgt definiert [Leh03]: Eine Kennzahl M ist definiert durch eine Granularität G, durch eine Berechnungsvorschrift f() über eine nichtleere Teilmenge aller im Schema existierenden Fakten und wiederum durch einen Summationstyp: M = (G, f(f1, … , fk),SumTyp) Die Berechnungsvorschrift f() kann dabei durch verschiedene Funktionen gebildet werden. Da wären zum einem Skalarfunktionen wie *, +, /, -, mod etc., die aus einer Kombination von -3Fakten eine Kennzahl ergeben. Darüber hinaus existieren Aggregationsfunktionen welche eine Verdichtung des Datenbestandes vornehmen und ordnungsbasierte Funktionen, die Kennzahlen basierend auf einer zuvor definierten Ordnung definieren. Der qualifizierende Anteil des multidimensionalen Datenbankmodells wird durch das Konzept der Dimensionen bzw. Dimensionshierarchien verdeutlicht. Notwendig ist die Einführung von Dimensionen, da es möglich sein muss, Kenngrößen nach bestimmten Kriterien zu durchsuchen. Eine Dimension beschreibt die mögliche Sicht auf eine assoziierte Kennzahl. Dimensionen bilden also eher betriebswirtschaftliche Entscheidungsobjekte. Eine Dimension ist eine endliche Menge von n (n >= 2) Dimensionselementen, die eine semantische Beziehung aufweisen. Die Dimensionselemente dienen der orthogonalen Strukturierung des Datenraums. Dimensionen werden feingranular unterteilt durch Dimensionselemente. Diese Dimensionselemente bilden u.a. auch die Blätter eines Baums, der vollständig als Klassifikationshierarchie bezeichnet wird. Sie beschreiben also verschiedene Verdichtungsstufen einer Dimension. Da Klassifikationshierarchien schnell sehr umfangreich werden können, werden sie zu Klassifikationsschemata zusammengefasst. Man unterscheidet einfache und parallele Hierarchien. In einfachen Hierarchien ist nur eine Art der Gruppierung vorhanden bzw. implementiert. Die höheren Hierarchieebenen enthalten die aggregierten Werte der jeweils niedrigeren Hierarchiestufe. Im Gegensatz dazu bietet die parallele oder multiple Hierarchie die Möglichkeit, verschiedene Arten der Gruppierungen vorzunehmen. Der Datenbestand kann in verschiedene Hierarchien unterteilt werden. Diese verschiedenen parallelen Hierarchien im Klassifikationsschema berücksichtigen jeweils einen Aspekt, ignorieren dafür jedoch einen anderen. Parallelhierarchien werden auch als Pfade im Klassifikationsschema bezeichnet. Der Vorteil von parallelen Hierarchien ist vor allem der flexible Umgang mit den Daten. Die Analysen können nun viel weiträumiger gestaltet werden. Sie ermöglichen auf ganz unterschiedlichen Pfaden durch die Daten zu navigieren und diese unter sehr differenzierten Aspekten zu betrachten. 3 Meta-Daten 3.1 Definition Bauer, Günzel (2004) definiert Meta-Daten wie folgt: „Unter dem Begriff Metadaten versteht man gemeinhin jede Art von Information, die für den Entwurf, die Konstruktion und die Benutzung eines Informationssystems benötigt wird.“ -4Meta-Daten, kurz MD, werden in einem Repository gespeichert und über den MD-Manager verwaltet. Gerade bei einem Data-Warehouse sind MD von entscheidender Bedeutung für die Qualität des Data-Warehouse. MD umfassen hier nicht nur Schemainformationen zu den beteiligten Datenbanken sondern darüber hinaus auch Aktualisierungsdaten sowie jegliche Art von Zusatzinformation die in einem Data-Warehouse entstehen. MD sind notwendig, um Daten besser zu verstehen, zu verwalten und auswerten zu können. Oft werden MD auch als Daten über Daten bezeichnet. 3.2 Klassifikation von MD MD lassen sich in vielerlei Hinsicht kategorisieren. Nach der Art der Nutzung kann man MD in drei Kategorien unterscheiden [BaGü04]: - Passiv: Die Nutzung der MD dient hier der konsistenten Dokumentation. Passive MD werden von allen Akteuren eines Data-Warehouse genutzt - Aktiv: Die MD dienen vor allem zur Beschreibung von Prozessen. Dies umfasst u.a. Transformationsregeln, die dann zum Ausführungszeitpunkt eines Prozesses interpretiert und ausgeführt werden. - Semiaktiv: Bei dieser Form der Nutzung werden Strukturinformationen im Repository gespeichert. (Bsp.: Tabellendefinitionen) Die MD können dann zu Überprüfungszwecken verwendet werden, um beispielsweise zu verifizieren, ob ein Attribut tatsächlich existiert. Diese Form von MD dient also nicht direkt der Ausführung von Prozessen. Eine weitere typische Klassifizierung ist die Unterscheidung nach Anwendersicht. Hier ergeben sich zwei Arten von MD [Rah01]: - Technische MD: Dies sind MD, die vor allem für technische Nutzer des DataWarehouse wie Administratoren, Applikationsentwickler sowie ETL-Tools eine Rolle spielen. Hierzu zählen u.A. Transformationsregeln, Zugangsrechte oder auch Datenbankkataloge. - Business-MD: Ziel dieser Art von MD ist es, dem Nutzer die Möglichkeit zu bieten, alle Daten das Data-Warehouse zu verstehen, zu finden und auswerten zu können. Man fasst hier also auch Aussagen über die Datenqualität zusammen. Es spielen somit Fakten wie Korrektheit, Aktualität und Herkunft der Daten eine Rolle. Bei Business MD ist außerdem die Präsentation von großer Bedeutung. -5Auch lassen sich MD nach dem Typ differenzieren. Hier existieren ebenfalls zwei Unterscheidungen: - MD über Primärdaten: Datenbestände die von den Quellsystemen, dem DataWarehouse und der Basisdatenbank (diese existiert nicht zwangsläufig) verwaltet werden, bezeichnet man gemein hin als Primärdaten. MD umfassen in diesem Bereich demzufolge vor allem Strukturdefinitionen der eben genannten Systeme. Hier kann zwischen gesamtschemabezogenen MD (Schemabeschreibung, z.B. statistische Werte wie die Anzahl der Datensätze) und teilschemabezogenen MD (Bsp.: Qualitätsmerkmale, die sich auf einzelne Attribute beziehen) unterschieden werden. Ein Beispiel sind Codetabellen die zur textuellen Erklärung von Codes wie „0“ für männlich und „1“ für weiblich dienen. - Prozess-MD: In diese Kategorie fallen MD über Prozesse im Data-Warehouse. Als Beispiel können Regeln zur Datenextraktion, Transformation und zum Laden, die als ausführbare Spezifikationen definiert sind, genannt werden. Prozess-MD beinhalten darüber hinaus Protokolldateien und Ausführungspläne der Prozesse. 3.3 Wozu MD? Die Erfassung von MD dient vor allem zwei grundsätzlichen Zielen. Zum einen sollen MD den Aufwand des Betriebs eines Data-Warehouse minimieren. Hier spielen vor allem Punkte wie die Automatisierung von Prozessen eine Rolle, da Prozesse Scheduling- und Konfiguration-MD benötigen. Außerdem ist eine funktionierende Systemintegration nötig. Zur Schema- und Datenintegration sind Strukturinformationen und die Bedeutung der einzelnen Quellen und Zielsysteme nötig. Vor allem konsistente und einheitliche MD sind in diesem Zusammenhang gefordert. Ein weiterer Punkt ist, durch MD einen flexiblen Softwareentwurf zu gewährleisten. Sich häufig ändernde semantische Aspekte werden möglichst „außerhalb“ der Anwendung gespeichert um die Wartbarkeit und die Wiederverwendbarkeit zu erhöhen. Der letzte Punkt dieser Zielsetzung betrifft Schutz- und Sicherheitsaspekte. Alle Zugriffs- und Benutzerrechte sollen als MD behandelt werden. Dies ermöglicht die Vereinheitlichung und Konzentrierung dieser Daten. Für die Erreichung dieser Zielsetzung sind vor allem technische MD von Bedeutung. Die zweite Zielsetzung betrifft die effektive Beschaffung und die optimale Auswertung von Informationen. Datenqualität ist hier als erster Punkt zu nennen. Es kommt auf konsistente korrekte und vollständige Daten an. Damit dies gewährleistet werden kann, müssen -6Überprüfungsregeln definiert werden, die bei jedem Aktualisierungsprozess zur Ausführung gelangen. Es ist weiterhin nötig, Nachvollziehbarkeitsinformationen zu sammeln, um Daten eindeutig zuordnen zu können. Daten müssen bis zur Quelle zurückverfolgt werden können. Der zweite wichtige Punkt diese Ziels betrifft eine einheitliche Terminologie. Ist das MDManagementsystem die einzige Informationsquelle, so können Daten einheitlich interpretiert werden, was für die Qualität des Data-Warehouse außerordentlich wichtig ist. Der letzte Punkt betrifft Fragestellungen der Datenanalyse, es geht im Einzelnen darum, dem Anwender die Möglichkeit zu bieten, präzise Anfragen an das Data-Warehouse zu stellen. Zur Erfüllung der zweiten Zielsetzung dienen vor allem Business MD. 3.4 MD-Modellierung Es ist allgemein akzeptiert, dass komplexe Informationssysteme wie ein Data-Warehouse nur durch ein Modell mit mindestens vier Ebenen adäquat modelliert werden können. (Vgl. Abbildung 2) Ebene : 3 2 1 0 Abbildung 2 - Modellierungsebenen, in Anlehnung an [BaGü04] In jeder Ebene finden sich die Modellierungskonstrukte oder die Sprache zur Definition der darunter liegenden Ebenen. Ebene 0 umfasst die effektiven Daten (Objektdaten) wie einzelne Datensätze. Ab Ebene 1 enthalten die Ebenen dann Meta-Informationen. Ebene 1 umfasst die MD als Modell des zu modellierenden Informationssystems. Ebene 2 definiert Sprachelemente, die auf Ebene 1 zur Verfügung stehen. Ebene 3 fasst die Metamodelle der 2. Ebene zusammen. 3.5 Anforderungen an die Repositories Das Repository, also der Ort an dem die MD gehalten werden, muss natürlich einige Anforderungen erfüllen um Daten optimal speichern, verwalten und benutzen zu können. Die -7Haltung von MD unterliegt weitestgehend auch den Anforderungen welcher die Haltung „normaler“ Daten unterliegt. Es gibt jedoch einige markante Unterschiede. Ein umfangreiches, erweiterbares MD-Metamodell muss existieren, welches alle vorhandenen Klassen von MD unterstützt. Auch dem Austausch und der Integration von MD sollte dieses Modell dienen. Um eine noch feingranularere Spezifikation treffen zu können, kann man die Anforderungen grob in zwei Teilbereiche trennen. Zum einen gibt es Anforderungen an die Architektur und zum anderen Anforderungen an die Funktionalität. Die Anforderung an die Funktionalität kann man untergliedern in Anforderungen an den Anwenderzugriff, die Interoperabilität und das Änderungsmanagement. - Anwenderzugriff: Hauptaufgabe des Repository ist es, dem Anwender die Information zur Verfügung zu stellen, die er zur Erfüllung seiner Aufgaben benötigt. Die Benutzerführung muss sich dem Kenntnisstand des Anwenders anpassen. Die Steuerung der Navigation im Repository erfolgt durch das MD-Schema. Ausgehend von einem konkreten MD-Element soll der Anwender die Möglichkeit haben, sich anhand existierender Beziehungen zu anderen Elementen navigieren zu können. Die Struktur des Repository (MD-Schema) muss Anfragen nach bestimmten Kriterien unterstützen. Die Selektion der Aktivitäten, die einen bestimmten Ladeprozess definieren, wäre hier ein Beispiel. Beim Filtern von Metadaten wählt man die Elemente anhand von Suchkriterien aus, die nicht gezwungenermaßen durch die Struktur des Repository vorgegeben sein müssen. Ein Beispiel für Filter ist die Suche nach Schlüsselbegriffen innerhalb textueller Beschreibungen. Um eine manuelle Aktualisierung zu unterstützen, sind ausgefeilte Konzepte zur Benutzerführung von Nöten, um die Konsistenz des Repository zu jedem Zeitpunkt zu gewährleisten. Um beispielsweise die Eingabe langer Sequenzen von verbundenen Elementen zu ermöglichen, erweitert man das Metamodell um zusätzliche Teilmodelle, die die Prozesse der Eingabe formalisieren und damit die Generierung angepasster Eingabemasken ermöglichen. - Interoperabilität: Die Interaktion von Werkzeugen mit dem Repository sowie eine Interaktion der Repositories untereinander erfordert mehrere Eigenschaften. Zum einen eine umfassende Programmierschnittstelle (API). Dann die Definition eines umfassenden Austauschformates, in dem sich MD importieren und exportieren lassen. Wichtig ist aber auch ein erweiterbares Meta-Modell, dem ohne viel Aufwand domänenspezifische MD-Typen hinzugefügt werden können. -8- Änderungsmanagement: In diesen Punkt fallen eine Versions- und Konfigurationsverwaltung. Weiterhin benötigt man ein Notifikationsmanagement um die Verbreitung von Änderungshinweisen an alle potentiellen Zieladressaten zu gewährleisten. Außerdem sollen Auswirkungsanalysen es dem Administrator erlauben, geplante Änderungen am Repository ex ante zu evaluieren. Die Anforderungen an die Architektur des Repository sind sehr vielschichtig. Hier spielen vor allem Komponenten des Data-Warehouse eine Rolle, die mit dem Repository interagieren. Verwaltet wird das Repository durch den MD-Manager, welcher die Funktionalität eines Datenbankmanagementsystems bereitstellt. Alle Zugriffe auf das Repository erfolgen über die Schnittstellen des MD-Managers. Der Data-Warehouse-Manager benutzt das Repository als Ablage vielfältiger Steuerungsinformationen. Diese Informationen werden dann zur Laufzeit von den verschiedenen Werkzeugen wie Administrations- und Analysewerkzeugen übergeben und interpretiert. Natürlich können diese Werkzeuge auch selbst MD produzieren und diese im Repository ablegen. Zur Gesamtarchitektur des Repository existieren mehrere Ansätze. Generell bietet sich an MD zentral in einem Repository abzulegen, man sprich dann von der zentralisierten MDVerwaltung. Der Zugriff erfolgt somit einheitlich für alle Anwender. Leider ist diese Form der Architektur in der Realität kaum umsetzbar1. Daher existieren noch zwei weitere Ansätze für die Architektur. Zum einen die dezentrale MD-Verwaltung, die den einzelnen Repositories völlige Freiheit überlässt. Lediglich der Austausch von MD unterliegt Standards. Eine Mischform aus dezentraler und zentraler Metadatenverwaltung stellt schließlich die föderative MD-Verwaltung dar. Hier existiert eine globale konzeptuelle sicht auf die MD, die Repositories sind jedoch untereinander weiterhin autonom. 4 Modelle und Standards 4.1 MD Referenzmodelle Im Data-Warehouse Bereich spielen in Hinsicht auf Standardisierung zwei Gruppierungen eine herausragende Rolle. Zum einen ist das die Object Management Group (OMG) und zum anderen die Meta Data Coalition (MDC). Beide Parteien haben einen Standard für MD entwickelt, auf Grund der Ähnlichkeit zwischen beiden Standards wurden diese jedoch vereint, so dass nunmehr lediglich das Common Warehouse Metamodel (CWM) [cwm] der 1 Dies ist vor allem bedingt durch die oft unhomogene Ausbaustruktur von Unternehmen nach Fusionen. Die verschiedenen Softwaretypen der Einzelunternehmen basieren meist auf verschiedenen Datenmodellen. -9OMG existiert [cwm00]. Ein weiteres Modell ist die allgemeine Architektur von Informationssystemen von John A. Zachman [Zach87], das in dieser Arbeit jedoch nicht näher betrachtet wird. Der Hauptzweck von CWM ist die Unterstützung eines einfachen Austauschs von MD zwischen den verschiedenen Werkzeugen und Repositories. Eine erste Version dieses Standards wurde im September 1999 vorgestellt. CWM ist ein produktübergreifendes und herstellerunabhängiges Modell, das vor allem die Kommunikation zwischen den Werkzeugen vereinfachen soll um eine Integration verschiedenster Softwareprodukte möglichst einfach zu gestalten. Dies bietet ein großes Kosteneinsparungspotential für Betreiber von Data-Warehouse Systemen. Der Entwurf eines allgemeinen Meta-Modells erfordert im Allgemeinen einen Kompromiss aus Ausdrucksstärke und Allgemeingültigkeit. Das Meta-Modell muss zwar nicht alle denkbaren Details modellieren, es sollte dennoch in der Lage sein alle nötigen Aspekte zurepräsentieren. Um diese Herausforderung adäquat zu begegnen, ist das CWM in einer Ebenenhierarchie aufgebaut, die insgesamt 21 Pakete umfasst. Basis bildet die Schicht Object Model, in welcher die grundlegenden Modellkonzepte verankert sind. Die zweite Schicht ist die Grundlagen oder Foundation Schicht. In den Teilmodellen dieser Schicht werden Basiskonstrukte definiert, die die Grundlage „höherer“ Teilmodelle bilden. Unter anderem wird die Menge aller unterstützten Basistypen eingeführt oder formal spezifiziert. Diese weisen Eigenschaften, Schlüssel und Indexe auf. Die nächste Schicht ist die Ressourcen Schicht. Hier beschreiben die Teilmodelle eine konkrete Form der Datenmodellierung unter Rückgriff auf Konstrukte der Grundlagen. In der darüber liegenden Analyse Schicht werden analyseorientierte Szenarien, wie beispielsweise multidimensionale Datenwürfel oder Data-Mining-Szenarien beschrieben. Transformationsregeln werden im CWM-Kontext dieser Ebene zugeschrieben. D.h. bei Spezifikation einer konkreten Transformationsregel wird u.U. auf Konstrukte zur Repräsentation relationaler oder datensatzorientierter Datenbestände zurückgegriffen. Die letzte Schicht bildet die Verwaltung. Höherwertige Teilmodelle auf dieser Ebene ermöglichen unterschiedliche Szenarien hinsichtlich ihrer Abläufe zu spezifizieren. Die Schicht Verwaltung besteht aus den beiden Teilmodellen Geschäftsprozesse und Geschäftsoperationen, die die Beschreibung erlauben, wann welche Transformationen durchgeführt werden müssen, um bestimmte Analyseszenarien zu erzeugen. Die ebenenweise Strukturierung des CWM-Ansatzes gestattet es, sowohl das CWM-Szenario um Teilmodelle zu erweitern wie auch die Modellierung von Teilmodellen unabhängig von - 10 darauf basierenden Spezifikationen zu ändern. Es steht somit eine breite Plattform zur Beschreibung von Strukturen und Abläufen in einem Data-Warehouse zur Verfügung. 4.2 Repository-Standards Repository-Standards etablieren Referenzarchitekturen. Diese werden dann konkret von Herstellern der Repository-Systeme realisiert. Wichtigstes Ziel ist vor allem die universelle Einsetzbarkeit dieser Produkte. Information Resource Dictionary System (IRDS): Dieser Standard wurde 1990 von der ISO (International Organization for Standardization) definiert. Er behandelt die Anforderungen und die Architektur eines Repository. Das IRD dient hierbei als gemeinsames Repository zur Definition und Speicherung von Informationen über Daten. IRDS schlägt eine vier Ebenen Architektur wie oben beschrieben vor. Wichtige Punkte können sein: - Informationen über Daten die im Unternehmen gebraucht werden - Automatisierte und nicht automatisierte Prozesse, die verfügbar sind um Daten zu präsentieren und zu verwalten - Die verfügbare physikalische Hardwareumgebung, in welcher diese Daten gehalten, verwaltet und präsentiert werden - Organisationsstrukturen für die Generierung dieser Information Portable Common Tool Environment (PCTE): PCTE wurde 1990 von der ECMA (European Computer Manufactor’s Association standardisiert. Er beschreibt die Basis für eine standardisierte Software- entwicklungsumgebung. Diese umfasst ein Repository sowie die Unterstützung der Kommunikation der verschiedenen Werkzeuge. Der wichtigste Faktor ist die Objektbasis und Funktionen um diese Objekte zu manipulieren. Das Repository basiert auf dem E/R-Modell. Weiterhin sind alle Entitäten typisiert und für Entitäten, Beziehungen und Attribute sind Typisierungsregeln definiert. 4.3 Austausch-Standards Um die Interoperabilität zwischen Repositories bestmöglich zu gewährleisten, sind gute Austauschstandards unabdingbar. Folgende Standards existieren derzeit: [SVV99] CASE Data Interchange Format (CDIF): - 11 Vorgeschlagen wurde dieser Standard von der Electronic Industries Association und wurde dort ab 1987 entwickelt. CDIF deckt gängige Modellierungstechniken im Bereich der CASETools ab. Der Datentransfer geschieht über Dateien die auch über eine IDL (Interface Definition Language) definiert werden können. Es ist abzusehen, dass dieser Standard wohl zu Gunsten der XML basierten Standards aufgegeben wird. XML Metadata Interchange (XMI) XMI ist ein auf XML basierender Standard der OMG (Object Management Group). Der Standard besteht aus: - Einer Menge an DTD Erzeugungsregeln um MOF (Meta Object Facility) basierte Modelle in XML DTDs umzuwandeln - Einer Menge an XML- Dokument-Erstellungsregeln um MOF basierte Meta Daten zu kodieren und zu dekodieren - Design Prinzipien für XMI basierte DTDs und XML Streams - Konkrete DTDs für UML und MOF 4.4 Kommerzielle MD-Management Lösungen Im folgenden Abschnitt werden (kommerzielle) MD-Management bzw. Repository-Lösungen dargestellt. Die Auswahl ist weder vollständig noch findet eine Evaluierung statt. Microsoft Repository Das Microsoft Repository ist ein objektorientiertes, erweiterbares Repository, bestehend aus zwei Hauptkomponenten: - Eine Menge von APIs, basierend auf dem Component Object Modell von Microsoft um Information und Modelle zu beschreiben - Eine (relationale) Repository Engine, Bsp.: MS-SQL Server, Microsoft Jet Microsoft Repository zielt vor allem darauf ab, MD in einer Vielzahl an Szenarien verwenden zu können. Es arbeitet mit Microsoft SQL Server und Microsoft Visual Studio. In der Vergangenheit wurde eine Kollaboration mit Platinum eingegangen, um das Repository von Microsoft auch auf andere Plattformen zu portieren. Microsoft Repository ist ein weit verbreitetes Repository, es existiert bereits eine große Zahl an Werkzeugen die auf diesem Produkt aufbauen, um MD zu verarbeiten. - 12 - Platinum Repository Dieses Produkt wurde 1987 von Computer Associates entwickelt und basiert auf dem E/R Modell. Es bietet verschiedenste Schnittstellen zu CASE Werkzeugen aller Art. Weiterhin ermöglicht es den Import einer Vielzahl von Datenbanksprachen. Es übernimmt die automatische Generierung der technischen MD und bietet einen Browser zum Erkunden der Business-MD. Derzeit existiert das Repository in zwei Ausführungen, zum einen als Repository/MVS bei dem eine DB2 Datenbank als Datenspeicher dient und das Repository/OEE bei dem ein Oracle, Sybase oder Microsoft SQL Server zum Einsatz kommt. Wie eben bereits erwähnt, besteht eine Kollaboration mit Microsoft um deren Repository auf andere Plattformen zu portieren. Data Warehouse Builder – MetaBase Der Warehouse Builder von Oracle stellt mit dem Metadata-Repository und der MetaBase ein integriertes Metadaten-Management für alle Komponenten des Data-Warehouse zur Verfügung. Neben der Speicherung übernimmt der Warehouse-Builder auch die Aufgabe der Metadatensammlung, Überwachung der Aktualität, der Qualität und Vollständigkeit der Metadaten. Zur Visualisierung der Metadaten existiert eine webbasierte Umgebung. 4.5 Forschungsansätze Das Management und der Austausch von MD sind natürlich auch Ziel der Untersuchung in vielen Forschungsprojekten. Es sollen hier nun zwei konkrete Ansätze und ein kurzer Ausblick dargelegt werden. ConceptBase ConceptBase ist eine deduktive objektorientierte Datenbank und zugleich ein Managementsystem, das 1987 am Lehrstuhl für dialogorientierte Systeme der Universität Passau entstand. Seit 1991 wird ConceptBase am Lehrstuhl für Informationssysteme der RWTH Aachen weiterentwickelt. Konzeptuelle Modellierung und Systementwürfe sind das besondere Aufgabengebiet. ConceptBase arbeitet mit einem Dialekt der konzeptuellen Modellierungssprache Telos. Dieser bietet die Möglichkeit, Systeme in der Entwurfsphase zu modellieren und graphisch darzustellen. Eine besondere Stärke von ConceptBase ist die Metamodellierung. Durch die Möglichkeit zur Spezifizierung von so genannten - 13 Metamodellen können Modellierungssprachen definiert und bekannte Modellierungssprachen wie ER-Modellierung oder DATA FLOW Diagramme emuliert werden. Mit Hilfe von festgelegten Axiomen und einer so genannten Konsistensprüfung wird die Korrektheit der Modellierung in ConceptBase gewährleistet. Ein besonderes Merkmal ist der Versuch, die Begriffe Deduktivität und Objektorientierung zusammenzubringen. Die Deduktivität der Datenbank besteht darin, dass nicht nur Daten in der Datenbank gespeichert werden, sondern auch Regeln, aus denen man neue Daten und neue Integritätsbedingungen herleiten kann. H-PCTE H-PCTE ist die hochperformante Implementation von PCTE und wurde an der Universität Siegen entwickelt. Weiterhin bietet H-PCTE die explizite Unterstützung einer Objektversionisierung und das dynamische Erzeugen und Verändern von Typen. Das Datenmodell von H-PCTE basiert auf dem Entity-Relationship-Modell, d.h. eine Objektbank enthält Objekte, die durch Beziehungen verbunden sind, über die navigiert werden kann. HPCTE bietet eine mengenorientierte Abfragesprache sowie eine SQL-ähnliche Abfragesprache. Mit dem Java-API von H-PCTE können portable Frontends in Java realisiert werden. H-PCTE wurde hauptsächlich als Repository für den Software Engineering Bereich entwickelt. Ein interessantes Forschungsfeld auf dem Gebiet der MD ist sicherlich das „Generische MD Management“. Es handelt sich hierbei um eine datenbankgestützte, standardisierte und flexible Möglichkeit Applikationen und Services metadatenbasiert zu entwickeln. Der Ansatz wurde von Phil Bernstein [Ber] vorgeschlagen und behandelt die Verwaltung von Modellen. Es handelt sich um ein Meta-Modell, welches sich mit Modellen wie Schema, Ontologie und DTD (Dokumenttypdefinitionen) und deren Abbildung aufeinander beschäftigt. Ein Algebra wird eingeführt, die Operationen („Merge“, „Match“ , „Compose“) zur Manipulation dieser Modelle bereitstellt. Besonders Augenmerk im Hinblick auf Data-Warehouse liegt hier auf dem Match Operator. - 14 - 5 Literatur 1. [BaGü04] Andreas, Bauer; Holger Günzel: Data-Warehouse-Systeme, ArchitekturEntwicklung-Anwendung, dpunkt-Verlag, 2004. 2. [Ber] Phil Bernstein. Model Management. 06.07.2005 http://www.research.microsoft.com/~philbe/ . 3. [cwm] Common Warehouse Metamodel (CWM). 02.07.2005 http://www.omg.org/technology/cwm/ . 4. [cwm00] Competing Data Warehousing Standards to Merge in the OMG, September 2000, 05.07.2005 http://www.omg.org/news/releases/pr2000/2000-09-25a.htm . 5. [Leh03] Lehner, W.: Datenbanktechnologie für Data-Warehouse-Systeme. Konzepte und Methoden. Heidelberg: dpunkt.verlag, 2002. 6. [Rah01] Erhard Rahm. Metadata Management for Heterogeneous Information Systems, 2001, 07.07.2005 http://dbs.uni-leipzig.de/en/Research/metaDateien/meta2.pdf . 7. [SVV99] Martin Staudt, Anca Vaduva, Thomas Vetterli: The Role of Meta Data for Data-Warehousing, University of Zürich, 1999.
