Metadatenmanagement

5 Standardisierungsbestrebungen In früheren Generationen von Data Warehouse-Architekturen waren Systementwickler routinemäßig gezwungen, für die Dokumentation der zentralen Programmabläufe oder für die Einlage in das zentrale Informations-Repository individuelle Metadaten „manuell“ zu schreiben. Normalerweise ließen sich Metadaten nicht zwischen Produkten bzw. Decision-Support-Werkzeugen verschiedener Hersteller austauschen. Das führte zwangsläufig zur Umschreibung der Dokumentationsdaten und damit zum Ergebnis der Redundanz und des Risikos inkonsistenter Metadatenbestände [DIEF00]. Durch die Speicherung einer breiten Schicht unterschiedlicher Produkte aus unterschiedlichen Systemen und der damit verbundenen Dokumentation durch die jeweiligen Back Room Metadaten, wobei hier wiederum ein Metadatenformat durch ein Metamodell für verschiedene Produkte definiert werden muss, entsteht der Bedarf, den Metadatenmanagement-Prozess zu automatisieren und ein Sharing zwischen unterschiedlichen Metadatenstrukturen zu erreichen. Dadurch soll sowohl Konsistenz als auch Integrität der Metadaten im Data Warehouse erreicht werden, um dadurch spätere Metadatenveränderungen verfolgen zu können [WHIT00]. [...]

Die Generic Metadaten Sources liegen in einem gemeinsamen Format, wie z. B. einem Standardformat wie CWMI (siehe Kapitel 5.3) oder durch abgrenzende Tabs, Kommata etc., vor, die durch Tools direkt gelesen werden können. Der Unterschied zu den Certified Sources liegt in den Programmieranforderungen begründet, die für das Mapping der Metadaten in die korrekten Attribute des Metamodells nötig sind. Dadurch ist es relevant, dass die Repository-Tool-Schnittstelle leicht anpassbar ist, um das Mapping durchführen zu können. Beispiele sind solche Back Room sowie Front Room Metadaten in Datenbanken und Spreadsheets, die sich relativ einfach in die gemeinsamen Formate übertragen lassen [MARC98a]. In der letzten Gruppe sind Metadaten, die weder im Certified noch im Generic Format vorliegen, sondern als Non-Supported Sources anspruchsvolle Analysen und Programmierungen erfordern, um in die Metamodell Attribute gemappt werden zu können. Darunter fallen hauptsächlich Front Room Metadaten, die unstrukturiert bzw. in einem proprietären Format vorliegen und daher nicht ohne Schwierigkeit bearbeitet werden können [MARC98a]. [...]

Mit Hilfe von XML wird es in absehbarer Zeit möglich sein, unterschiedliche Komponenten von verschiedensten Herstellern innerhalb eines Data Warehouse-Systems über den Metadatenaustausch kommunizieren zu lassen, wodurch das Konzept des herstellerübergreifenden zentralen Repository, das alle Informationsobjekte im Data Warehouse zentral und toolunabhängig verwaltet, durchsetzbar wird [KURZ99, S. 201]. 4.7 Metadatenintegration Für die Konsistenz und Homogenität der Metadaten ist deren Integration in das Repository von fundamentaler Bedeutung. Derzeit existiert eine Vielzahl von Metadata-Repository-Tools. Jedes für sich beansprucht, alle Metadaten von allen Quellen in die Repository-Struktur integrieren zu können. Die Realität sieht dagegen anders aus. Zwar sind die derzeit am Markt erhältlichen Tools durchaus in der Lage, die formalen Metadatenquellen, wie z. B. CASE Tools, ETL-Werkzeuge und andere Repositories, demnach die strukturierten Back Room Metadaten über unterschiedliche Schnittstellen zu integrieren, dennoch ist es der Mehrheit dieser Tools nicht möglich, eine adäquate Basis für die Integration der häufig unstrukturiert vorliegenden Front Room Metadaten bzw. des gesamten Administrationsprozess durch ein einheitliches Metamodell zu schaffen [MARC98a]. Die vorhandenen Tools können aus unterschiedlichen Quellen über verschiedene Schnittstellen Metadaten integrieren. Dabei wird in drei Hauptkategorien, in Certified Sources, Generic Sources und in Non-Supported Sources differenziert, um die Vorgehensweise der Integration der Metadaten aus unterschiedlichen Quellen über Schnittstellen zu klassifizieren. Jede dieser Kategorien benötigt dafür eine variierbare Komplexität der Integrationslevel und der Metamodell-Modifikation, um die verschiedenen Metamodelle der unterschiedlichen Werkzeuge an die Metadaten-Anforderungen anzupassen [MARC98a]. Unter Metadaten aus den Certified Sources versteht man solche, die von Tools direkt gelesen, interpretiert und in die korrekten Attribute des Metamodells geladen werden können, ohne dass vorher zusätzliche Analysen oder Programmiertätigkeiten vorgenommen werden müssen. Als Beispiel kommen Back Room Metadaten von CASE Tools oder Transformationsregeln des ETL-Prozesses in Betracht, welche Repository-Tools, die für die direkte Akzeptanz dieser Metadaten konzipiert wurden, automatisch bearbeiten können [MARC98a]. [...]