Gliederung

GLIEDERUNG   II

ABBILDUNGSVERZEICHNIS   IV

ABK  ÜRZUNGSVERZEICHNIS  V

ABK  ÜRZUNGSVERZEICHNIS  V

1  EINLEITUNG.  1

2  GRUNDLAGEN UND DEFINITIONEN  2

2.1  DATA WAREHOUSES  2

2.2  METADATEN  4

2.2.1  Definition Metadaten.  5

2.2.2  Arten von Metadaten  6

2.2.3  Einsatzzwecke von Metadaten  8

2.2.4  Metadatenspeicherung  9

2.2.5  Metadatenaustausch  10

2.3  QUALITÄT UND DATENQUALITÄT  14

2.3.1  Definition Datenqualität.  15

2.3.2  Kriterien für Datenqualität.  16

2.3.3  Datenqualität von Informationssystemen  18

2.3.4  Allgemeine Methoden zur Verbesserung von Datenqualität  19

3  QUALITÄT VON DATA-WAREHOUSES  20

3.1  QUALITÄTSKRITERIEN VON DATA-WAREHOUSES  21

3.2  RISIKEN FÜR DIE QUALITÄT VON DATA-WAREHOUSES.  21

3.3  BEDEUTUNG VON METADATEN FÜR DATA-WAREHOUSE QUALITÄT  23

3.3.1  Bedeutung von Metadaten im Data-Warehouse  24

3.3.2  Speicherung und Verarbeitung der Metadaten im Data-Warehouse.  26

3.4  KONZEPTE ZUR STEIGERUNG VON DATA-WAREHOUSE QUALITÄT  29

3.4.1  Doppelte Entwicklung - Stockhammer und Kennel  30

3.4.2  Qualitätssteigerung als Optimierungsproblem - Ballou / Tayi.  31

3.4.3  CLIQ - Der Ansatz von Hinrichs  32

3.4.4  Terminologiemanagement - Der Ansatz von Lehmann / Jaszewski  35

3.4.5  Alles in einem - Der Ansatz des DWQ  38

4  UMSETZUNG DER KONZEPTE AM PRAKTISCHEN BEISPIEL  43

4.1  BESCHREIBUNG DER AUSGANGSSITUATION  43

II

4.2  BESCHREIBUNG DER UMSETZUNGSMAßNAHMEN  44

4.2.1  Metadata-Services - Das Repository  44

4.2.1.1  Aufbau der Metadata-Services  45

4.2.1.2  Füllen der Metadata-Services  47

4.2.2  Analysis Services - Der OLAP-Server  50

4.2.2.1  Metadaten in den Analysis Services  50

4.2.2.2  Analysis Manager als Anwendungsoberfläche  53

4.2.3  Arcplans inSight/dynaSight - Das Front-End  54

4.2.3.1  Zugriff auf das Data-Warehouse und die Metadaten  55

4.2.3.2  Implementierung von Metadaten  58

5  SCHLUSSBEURTEILUNG.  61

5.1  BEURTEILUNG DER MAßNAHMEN.  61

5.2  ZUKÜNFTIGER ENTWICKLUNGSBEDARF  63

LITERATURVERZEICHNIS.   64

III

Abbildungsverzeichnis   

ABB.  1 SCHEMATISCHE DARSTELLUNG EINES DATA-WAREHOUSES (BÖHNLEIN, 2001)  

ABB.  2 TABELLE MIT UND OHNE METADATEN (OHNE QUELLE)  

ABB.  3 METAEBENEN (OMG, 2003)  

ABB.  4 SPEICHERUNGSVARIANTEN FÜR METADATEN (QUITZSCH, 2000)  

ABB.  5 GEMEINSAMKEITEN UND ÜBERSCHNEIDUNGEN DES CWM UND OIM (STAUDT, .U A., XXXX)  

ABB.  6 PAKETSTRUKTUR DES OIM (VETTERLI, .U A., XXXX)  

ABB.  7 STRUKTUR DES CWM (OMG, 2003)  

ABB.  8 HIERARCHISCHES DATENQUALITÄTSMODEL (WANG, STRONG, 2000)  

ABB.  9 DATENQUALITÄTSMÄNGEL (XXXX)  

ABB.  10 ARTEN VON METADATEN AUF DEN VERSCHIEDENEN DATA-WAREHOUSE EBENEN (QUITZSCH, 2000)  

ABB.  11 DATENFLÜSSE ZWISCHEN DER METADATENBANK UND DEN DATA-WAREHOUSE WERKZEUGEN  

  (STAUDT, .U A., XXX)  

ABB.  12 METADATENFLÜSSE IM DATA-WAREHOUSE (QUITZSCH, 2000 / OHNE QUELLE)  

ABB.  13 INTEGER PROGRAMMIERUNGS MODEL (BALLOU, TAYI, 1999)  

ABB.  14 DATENQUALITÄTSFRAMEWORK (HINRICHS, XXXX)  

ABB.  15 ORGANISATION DER BEGRIFFSDEFINITION (LEHMANN, JASZEWSKI, 1999)  

ABB.  16 CLIQ PROZESS (OHNE QUELLE)  

ABB.  17 METADATA FRAMEWORK DES DWQ (JARKE, .U A.,1999)  

ABB.  18 DATA-QUALITY METAMODEL (JARKE, .U A., 1999)  

ABB.  20 VERSIONSMETADATEN EINES DTS-PAKETES IM XML FORMAT  

ABB.  23 ARCHITEKTUR DER ANALYSIS SERVICES (MICROSOFT, 2000)  

ABB.  24 STAR SCHEMA EINES OLAP CUBES IM CUBE-EDITOR DER ANALYSIS SERVICES  

ABB.  25 DYNASIGHT ARCHITEKTUR (ARCPLAN, 2003)  

ABB.  26 BEZIEHUNGEN ZWISCHEN ELEMENTEN IN INSIGHT.  

ABB.  27 MAPPING DER TABELLENÜBERSCHRIFTEN IN INSIGHT  

IV

Abkürzungsverzeichnis

Abb. .............................................. Abbildung

API ................................................ Application Programming Interface Aufl. .............................................. Auflage bzw. ............................................... beziehungsweise COM ............................................. Component Object Model CORBA ........................................ Common Object Request Broker Architecture CWM ............................................ Common Warehouse Metamodel CWMI ........................................... Common Warehouse Metadata Interchange DBDWM ...................................... Database and Data Warehousing Model d. h. ............................................... das heißt Diss. .............................................. Dissertation DTD .............................................. Document Type Definition DTS ............................................... Data-Transformation-Services DW ................................................ Data-Warehouse DWQ ............................................. Data-Warehouse Quality Projekt ERM .............................................. Entity Relationship Model ETL ............................................... Extraktion Transformation Laden f. .................................................... folgende ff. ................................................... fort folgende ggf. ................................................ gegebenenfalls GQM ............................................. Goal-Question-Metric HOLAP ......................................... Hybrid Online Analytical Processing Hrsg. ............................................. Herausgeber HTML ........................................... Hypertext Mark-Up Language IEC................................................. International Electrotechnical Comission IS ................................................... Informationssystem ISO ................................................ International Standard Organization MD ................................................ Metadata MDC ............................................. Metadata Coalition MDX ............................................. Multidimensional Expression

V

MIT ............................................... Massachusetts Institute of Technology MMC ............................................ Microsoft Management Console MOF .............................................. Meta Object Facility MOLAP ........................................ Multidimensional Online Analytical Processing Nr. ................................................. Nummer OCLC ............................................ Online Cataloging Library Center ODBC ........................................... Open Database Connectivity OLAP ............................................ Online Analytical Processing OLE DB......................................... Object Link Embedding Database OLTP ............................................ Online Transaction Processing OIM .............................................. Open Information Model OMG ............................................. Object Management Group RDBMS ........................................ Relationales Datenbank Management System ROLAP ......................................... Relational Online Analytical Processing RW ................................................ Reale Welt S. ................................................... Seite

TIQM ............................................ Total Information Quality Management TQM ............................................. Total Quality Management u. ................................................... und u. a. ............................................... unter anderem u. A. .............................................. und Andere usw. ............................................... und so weiter UML ............................................. Unified Modeling Language vgl. ................................................ vergleiche Vol. ............................................... Volume WWW ........................................... World Wide Web XIF ................................................ XML Interchange Format XMI .............................................. XML Metadata Interchange XML ............................................. Extensible Mark-Up Language z. B. ............................................... zum Beispiel

VI

1 Einleitung

Data-Warehouses stellen eine wichtige Grundlage für die Analyse von betrieblichen Daten dar. Sie liefern zeitnahe Entscheidungsgrundlagen und befreien damit den Entscheidungsträger von der Notwendigkeit zur intuitiven Entscheidung. Abgesehen von der strategischen Bedeutung für ein Unternehmen, ist ein Data-Warehouse-Projekt normalerweise zeitaufwendig und kostspielig. „Unzählige Beispiele aus der betrieblichen Praxis belegen, dass Informationssysteme zwar meist technisch funktionieren, von den Anwendern jedoch nicht angenommen werden und deshalb bereits nach kurzer Zeit scheitern.“ ¹ Die Anwenderakzeptanz bei einem Data-Warehouse ist neben verschiedenen anderen Aspekten besonders von der Datenqualität abhängig. Dabei ist nicht die objektive Datenqualität das ausschlaggebende Kriterium, sondern die subjektive Qualität, die der einzelne Benutzer den Daten zumisst.

Im Folgenden soll untersucht werden, welche Möglichkeiten es gibt, die Datenqualität aus Benutzersicht zu steigern. Eine besondere Stellung nehmen hier Metadaten ein, da sie Informationen enthalten, die es dem Benutzer ermöglichen, die vorhandenen Daten besser verstehen und einschätzen zu können. Es scheint möglich, die Datenqualität für den Endbenutzer dadurch zu steigern, dass man ihm Zugriff auf diese Metadaten verschafft, so dass er die Bedeutung der Daten besser einschätzen kann und ihnen auf Grund seiner genaueren Kenntnisse über Herkunft und Aggregation mehr Vertrauen schenkt. Nach einer Erläuterung der für die Arbeit maßgeblichen Begriffe Data-Warehouse, Metadaten und Datenqualität wird im Abschnitt 3 dargestellt, welche Bedeutung Metadaten für die Datenqualität in Data-Warehouses haben und welche Ansätze es gibt, die Datenqualität speziell in Data-Warehouses zu steigern. Dabei werden sowohl generelle als auch metadatenbezogene Ansätze vorgestellt. Im Abschnitt 4 wird dann untersucht, wie sich die vorgestellten Ansätze an einem Praxisbeispiel realisieren lassen. Dabei sollen vor allem die Maßnahmen und Werkzeuge dargestellt werden, die notwendig sind, um dem Endbenutzer Zugriff auf die Metadaten des Data-Warehouse zu verschaffen. Den Abschluss bildet eine Zusammenfassung der Ergebnisse mit einer Darstellung des zukünftigen Entwicklungsbedarfs.

¹ Arcplan(WWW)/1999/”dynaSight Whitepaper”/S. 8.

1

2 Grundlagen und Definitionen

Im Folgenden sollen die für diese Arbeit wesentliche Begriffe des Data-Warehouse, der Metadaten und der Datenqualität erläutert und definiert werden. Dabei beschränken sich besonders die Ausführungen zum Data-Warehouse auf die für diese Arbeit notwendigen Grundaspekte, da eine ausführliche Beschreibung der einzelnen Einsatzmöglichkeiten, Techniken und möglichen Varianten den Rahmen der Arbeit sprengen würde.

2.1 Data Warehouses

Für den Begriff des Data-Warehouse gibt es in der Literatur eine Reihe von unterschiedlich weit gefassten Definitionen. ² Das Data-Warehouse-Quality-Project definiert ein Data-Warehouse als eine Ansammlung von Technologien, die es dem Anwender ermöglichen, bessere und schnellere Entscheidungen zu treffen. ³ In der Realität verteilen sich diese Technologien auf die folgenden, in Abbildung 1 dargestellten, drei Ebenen: Die unterste Ebene bilden Werkzeuge zum extrahieren, transformieren und laden von Daten aus operativen Systemen und externen Quellen (ETL-Prozess) in das Data-Warehouse. Ergänzt werden diese Werkzeuge durch Monitore, die die Datenquellen nach neuen bzw. geänderten Daten durchsuchen. ⁴ Bei der Extraktion werden die durch die Monitore identifizierten Daten aus den heterogenen Quellsystemen in einen Zwischenspeicher des Data-Warehouse kopiert. Im Anschluss daran werden bei der Transformation die Rohdaten um Fehler und Redundanzen bereinigt und in ihren Formaten und Detailebenen angeglichen. Als letzter Schritt erfolgt das Laden der bereinigten und harmonisierten Daten in die Datenhaltungskomponente. ⁵ Der Einsatz des Zwischenspeichers reduziert die Beanspruchung der operativen Systeme und sorgt für eine zeitliche Entkopplung der ETL-Schritte.

Den Kern eines Data-Warehouse bildet eine normalerweise ⁶ nicht operative Datenbank, in der entscheidungsrelevante, homogene, aktuelle und historische Daten aus heterogenen

² Vgl. Anahory, Murray/1997/”DW: Planung, Implementierung u. Administration”/S. 19.

³ Vgl. Jarke, Vassiliou (WWW)/1997/“Review DWQ Projekt“/S.1.

⁴ Zu den verschiedenen Monitoring - Konzepten siehe Herden/2001/“Entwurfsmethodik für DW“/S. 10.

⁵ Vgl. Herden/2001/“Entwurfsmethodik für DW“/S. 11 f. u. Böhnlein/2001/“Konstruktion semantischer DW-

Schemata“/S. 46 ff.

⁶ Eine Ausnahme stellt das Konzept des virtuellen DW dar. Hier verbleiben die Daten in ihren Quellsystemen.

Mehr dazu bei Böhnlein/2001/“Konstruktion semantischer DW-Schemata“/S. 58 ff.

2

Quellen hinterlegt sind. Im Gegensatz zu operativen Datenbanken werden die Datenbestände von Data-Warehouses in der Regel nicht verändert, sondern nur erweitert. Teilweise wird diese zentrale Datenbank durch Data-Marts ergänzt. ⁷ „Unter einem Data-Mart wird dabei meist ein spezieller, betrieblich sinnvoll abgegrenzter Teil eines Data-Warehouse verstanden.“ ⁸ Da sich die in operativen Systemen üblichen, normalisierten Datenstrukturen nur begrenzt für flexible Auswertungen und Analysen, wie sie in einem Data-Warehouse üblich sind, eignen, werden für Data-Warehouses regelmäßig multidimensionale Datenstrukturen, in der Regel mit Hilfe von Star Schemata und deren Unterarten, modelliert. ⁹ In der Praxis werden für Data-Warehouses meistens relationale Datenbanken verwendet.

Abb. 1 Schematische Darstellung eines Data-Warehouses (Böhnlein, 2001)

Die oberste Ebene, die Datenbereitstellungsebene, wird in der Regel durch ein OLAP-System realisiert. Dieses ermöglicht dem Benutzer eine explorative, multidimensionale und

⁷ Es existieren auch Ansätze, die auf eine zentrale Datenbank verzichten und das DW nur aus Data Marts

aufbauen. Davon raten ab Anahory, Murray/1997/”DW: Planung, Implementierung u. Administration”/S.

71.

⁸ Böhnlein/2001/“Konstruktion semantischer DW-Schemata“/S. 61.

⁹ Siehe hierzu Schelp, Chamoni/2000/“Modellierung mehrdimensionaler Datenstrukturen“/S. 1132 ff.

3

interaktive Datenanalyse der im Data-Warehouse gespeicherten Daten. ¹⁰ Üblicherweise verwendet man für die Datenanalyse mit einem OLAP-System die Metapher von einem Datenwürfel, den man aus allen Richtungen betrachten und in einzelne Scheiben bzw. Teilwürfel zerlegen kann. „Der Zugriff [durch die Front-End Werkzeuge] auf die Datenbereitstellungsebene erfolgt wahlweise über eine Datenbanksprache oder eine spezielle Programmierschnittstelle.“ ¹¹ Man unterscheidet zwischen drei OLAP Arten. Beim relationalen OLAP (ROLAP) werden für jede Anfrage die benötigten multidimensionalen Datenstrukturen erzeugt. Diese Variante benötigt wenig Speicherplatz, weist jedoch im Gegenzug längere Antwortzeiten auf. Das Gegenteil zu ROLAP ist das multidimensionale OLAP (MOLAP). Hier werden multidimensionale Datenstrukturen physisch in einer entsprechenden Datenbank vorgehalten. Diese Variante ist entsprechend

ressourcenintensiver, bietet jedoch ein besseres Antwortverhalten. Das hybride OLAP (HOLAP) versucht, die Vorteile beider Ansätze zu vereinen. ¹² Neben den Komponenten dieser drei Ebenen benötigt ein Data-Warehouse ebenenübergreifend die Möglichkeit, Metadaten zu speichern bzw. auf Metadaten zuzugreifen. Der Begriff Metadaten wird im folgenden Abschnitt erläutert. Auf die Bedeutung von Metadaten im Data-Warehouse wird in Abschnitt 3.3 eingegangen.

2.2 Metadaten

Der folgende Abschnitt bezieht sich auf Metadaten in Informationssystemen im Allgemeinen und ist nicht speziell auf den Bereich Data-Warehouses begrenzt. Neben einem Überblick über die mit Metadaten verbundenen Themen sollen jedoch speziell die für die Ausführungen der Abschnitte 3 und 4 relevanten Aspekte von Metadaten erläutert werden.

¹⁰ Vgl. Herden/2001/“Entwurfsmethodik für DW“/S. 15.

¹¹ Böhnlein/2001/“Konstruktion semantischer DW-Schemata“/S. 61. Besonders relevant ist die OLE DB für

OLAP Schnittstelle.

¹² Hierzu und zu weiteren Vor- u. Nachteilen der genannten Varianten vgl. Brosius/2001/“DW u. OLAP mit

Microsoft“/S.32 u. Kennel/1999/“Wie viele Dimensionen hat ein Würfel“/S. 5 ff.

4

2.2.1 Definition Metadaten

„Das Wort meta stammt aus dem Griechischen und bedeutet ursprünglich unter, neben oder danach. Im Zusammenhang mit Metadaten bezeichnet es Daten über andere Daten.“ ¹³ Obwohl dies die wahrscheinlich am weitesten verbreitete Definition für Metadaten ist, gibt sie für sich alleine genommen nur begrenzt Aufschluss darüber, was Metadaten sind. Dies liegt daran, dass sie zu kaum einer Eingrenzung der relevanten Datenmenge führt. 14

Abb. 2 Tabelle mit und ohne Metadaten (ohne Quelle)

Hilfreicher scheint es, kontextbezogen nur solche Daten als Metadaten zuzulassen, die die Verwaltung und Auswertung der zugrunde liegenden Daten erleichtern. ¹⁵ In einer Bibliothek z. B. würde dies dazu führen, dass das Erscheinungsjahr und der Autor eines Buches sehr wohl Metadaten darstellen, die Qualität des Papiers oder die Farbe des Einbands jedoch nicht, obwohl es sich in beiden Fällen um Daten über die verwalteten Daten (die Bücher) handelt. Weiter lässt sich eingrenzen, dass nur solche Informationen als Metadaten brauchbar sind, die konsistent verwaltet werden und für die Benutzer zugänglich

¹³ Anahory, Murray/1997/”DW: Planung, Implementierung u. Administration”/ S. 155.

¹⁴ Auch dieser Meinung Hymmen/2000/”Datentransformation über MD”/S. 35.

¹⁵ Vgl. Vetterli, Vaduva, Staudt/2000/“MD Standards for DW”/ S. 1.

5

sind. Solange sich Informationen nur im Kopf eines Benutzers oder Datenbankadministrators befinden, sind sie folglich nicht als Metadaten zu gebrauchen. ¹⁶ Es lässt sich also zusammenfassend feststellen, dass Metadaten Daten über andere Daten sind, die die Verwaltung und Auswertung dieser Daten erleichtern und außerdem konsistent verwaltet werden und den Benutzern, Administratoren, Entwicklern und ggf. Softwaretools in einer adäquaten Form zugänglich sind.

Grundsätzlich lässt sich sagen, dass eine Datenverwaltung ohne Metadaten eigentlich nicht denkbar ist. Eine Tabelle ohne Erläuterungen zum Inhalt der einzelnen Spalten und Feldern, ist nicht zu gebrauchen. Besonders deutlich wird dies, wenn man sich eine Tabelle vorstellt, in der nur numerische Werte gespeichert sind. Ohne eine Definition, welche Größe diese Zahlen ausdrücken, bleibt eine derartige Tabelle unverwertbar.

2.2.2 Arten von Metadaten

Abb. 3 Metaebenen (OMG, 2003)

Die durch oben stehende Definition eingegrenzten Metadaten können anhand verschiedener Kriterien weiter kategorisiert werden. Diese Kriterien stellen wiederum Metadaten der

¹⁶ Vgl. Vaduva, Dittrich/2001/“MD Management for DW“/ S. 2.

6

Metadaten dar (Metametadaten). Häufig wird davon ausgegangen, dass zur Verwaltung von Daten und Metadaten vier Modellierungsebenen benötigt werden. Abbildung 3 zeigt diese Ebenen. Die Ebene Null wird durch die eigentlichen Daten gebildet. Ebene Eins ist die Metadatenebene. Hier ist die Struktur der Daten beschrieben und hier werden Bezeichner und andere Attribute der Datenklasse definiert. Die Ebene Zwei enthält Metametadaten. Hier wird die Struktur der Metadaten abgebildet und definiert, welche Klassen von Metadaten es gibt. Es handelt sich hier um das Model eines Models. Theoretisch ist dieser Hierarchie nach oben hin keine Grenze gesetzt. Jedes Schema kann durch ein übergeordnetes Schema beschrieben werden. Die bestehenden Beschreibungs- und Modellierungskonzepte beschränken sich jedoch auf maximal vier Ebenen. ¹⁷ Die folgenden Unterscheidungskriterien sind alle auf der zweiten Metaebene anzuordnen. Die erste Unterscheidungsmöglichkeit ist eine Trennung in technische und geschäftsbezogene Metadaten. ¹⁸ In die Kategorie der technischen Metadaten fallen dabei jene, die zur Verwaltung der eigentlichen Daten von Administratoren und Systemkomponenten benötigt werden. Geschäftsbezogene Metadaten hingegen werden vom Benutzer benötigt, um die zugrunde liegenden Daten richtig einordnen und verstehen zu können. ¹⁹ Es ist durchaus möglich, dass Metadaten anhand dieser Kriterien beiden Kategorien gleichzeitig zuzuordnen sind. Um die Kriterien nicht aufzuweichen, scheint es jedoch grundsätzlich sinnvoll, zu versuchen, Metadaten nur der Kategorie zuzuordnen, der sie von ihren Eigenschaften her am ehesten angehören.

Alternativ zu dieser Zweiteilung der Metadaten schlägt Hummeltenberg eine Dreiteilung vor. ²⁰ Die erste Kategorie wird durch Metadaten für die Generierung gebildet. Hierunter fallen Daten über den Generierungszeitpunkt, die Datenquellen und deren Struktur. Die zweite Gruppe wird durch Metadaten mit Kontrollfunktion gebildet. Hierzu gehören vor allem Zugriffsrechte und Gültigkeitsregeln. Die dritte Sparte bilden die für die Nutzung relevanten Anwenderinformationen. Hierzu zählen die Semantik der Daten, Informationen über das Schema des Data-Warehouse und Berechnungsregeln. Im Gegensatz zu der

¹⁷ Vgl. zu den Metaebenen Lehmann, Ortner/2000/”Entwurf einer Beschreibungskomponente”/S. 374 ff.

¹⁸ Vgl. zu dieser Einteilung u. a. Vaduva, Dittrich/2001/“MD Management for DW“/S. 4.

¹⁹ Teilweise wird statt geschäftsbezogen auch der Begriff semantisch verwendet. Zu technischen und

semantischen Metadaten speziell vor dem DW Hintergrund siehe Stöhr, Müller, Rahm/1999/“Uniform

Model for MD Management“.

²⁰ Vgl. hierzu Hummeltenberg/1998/“Management des Produktionsfaktors Information“/S. 58.

7

Zweiteilung in technische und geschäftsbezogenen Metadaten ist die Dreiteilung nach Hummeltenberg spezieller auf den Data-Warehouse Kontext ausgerichtet. Allerdings ist auch im Data-Warehouse Bereich die Zweiteilung die weiter verbreitete. Ein weiteres Kriterium ist die Einteilung in passive, aktive und semiaktive Metadaten. ²¹ Passive Metadaten liefern eine Dokumentation über die zugrunde liegenden Daten und ihre Verhältnisse zur Umwelt. Sie müssen nur insoweit strukturiert sein, als es die Verwaltung und Zuordnung zu den eigentlichen Datenobjekten erfordert. Aktive Metadaten sind Methoden, die im Systembetrieb auf die Daten ausgeführt werden. Sie bestehen in der Regel aus interpretierbarem Code bzw. aus fertig kompilierten Routinen, die beim Zugriff ausgeführt werden. In diesem Sinne stellen die Methoden eines Objektes einer objektorientierten Datenbank aktive Metadaten dar. Semiaktive Metadaten sind statische Informationen. Von den passiven Metadaten unterscheiden sie sich darin, dass sie auf Grund ihrer Struktur auch durch andere Systemkomponenten gelesen und verarbeitet werden können. Im Gegensatz zu den aktiven Metadaten werden semiaktive jedoch nicht selbst ausgeführt, sondern dienen lediglich als Auslöser von Werkzeugfunktionen. Weiter lassen sich Metadaten nach ihrem Entstehungszeitpunkt und ihrer Entstehungsquelle unterscheiden. Als Quelle kommen drei Möglichkeiten in Frage. Entweder die Metadaten wurden von einem Entwickler, Administrator oder sonstigem Benutzer eingepflegt, oder sie wurden von einer Systemkomponente automatisch erzeugt. Die dritte Möglichkeit ist, dass sie von einem anderen System übernommen wurden. Letztendlich müssten sie dann jedoch dort auf eine der erstgenannten Arten entstanden sein. Als Entstehungszeitpunkt gibt es die Möglichkeiten, dass die Metadaten beim Systemdesign, bei der Systementwicklung oder beim Systembetrieb entstanden sind.

2.2.3 Einsatzzwecke von Metadaten

Derzeit werden der Einsatz und die Verwaltung von Metadaten in der Literatur vor allem im Zusammenhang mit dem Internet, wissensbasierten Systemen sowie Data-Warehouse-Systemen behandelt. Die Hauptziele sind dabei meist die Verbesserung der Datenqualität

²¹ Vgl. zu diesen Kriterien Staudt, Vaduva, Vetterli(FTP)/1999/“The Role of MD for DW“/S. 5 f.

8

bzw. die Möglichkeit, den Benutzer beim Verständnis und der Auswahl von relevanten Daten zu unterstützen und Metadaten zur Automatisierung zu verwenden. ²² Mit dem Metadateneinsatz im Internet beschäftigen sich z. B. die Dublin Core Metadata Workshops der OCLC ²³ . Der Schwerpunkt liegt hier auf der Frage, wie durch mit Metadaten angereicherte Dokumente eine qualitativ höherwertige Suche mittels Suchmaschinen und Robotern durchgeführt werden kann. ²⁴ Im Bereich der Automatisierung wird versucht, Web-Seiten unter Zuhilfenahme von Metadaten automatisch aus Datenbanken zu generieren. 25

Welche Möglichkeiten Metadaten im Bereich von Data-Warehousing bieten, wird ausführlich in Abschnitt 3.3 und 3.4 behandelt.

2.2.4 Metadatenspeicherung

Damit Metadaten, wie oben gefordert, nicht nur in den Köpfen von Benutzern existieren, müssen sie in irgendeiner Form im System gespeichert werden. Für die Speicherung und Verwaltung von Metadaten bieten sich grundsätzlich die drei in Abbildung 4 dargestellten Möglichkeiten der lokalen, zentralen oder föderalen Speicherung an. 26

Abb. 4 Speicherungsvarianten für Metadaten (Quitzsch, 2000)

Bei der lokalen bzw. dezentralen Speicherung werden die Metadaten lokal bei der Systemkomponente gespeichert, der sie unmittelbar zugehören. Bei HTML-Dokumenten ist dies direkt im Dokument, in anderen Fällen kann es sich um eine lokale Datenbank oder

²² Weitere Einsatzzwecke von Metadaten schildert Hymmen/2000/”Datentransformation über MD”/S. 44 f.

²³ Mehr zur Dublin Core Metadata Initiative unter DCMI(WWW)/2003/“Homepage“.

²⁴ Siehe hierzu u. A. Rusch-Feja/1997/“4. Dublin Core Metadata Workshop“ u. Weitzer/2000/”Verwendung

von Qualitäts-MD”.

²⁵ Siehe hierzu Sommer/2000/“Management großer Web-Sites“.

²⁶ Vgl. zu den folgenden Absätzen Vetterli, Vaduva, Staudt/2000/“MD Standards for DW”/S. 2. Speziell zu

den Vor und Nachteilen den zentralen bzw. lokalen Speicherung siehe Frie,

Strauch/1999/“Kriterienkatalog“/S. 17.

9

Datei handeln. Folge einer lokalen Metadatenhaltung sind die üblichen Probleme mangelnder Integration, wie Redundanz, mangelnde Integrität etc. Weiterhin ist das Metadatenmodell in der Regel wesentlich weniger komplex als bei zentralen Lösungen. Lokale Dateisysteme sind deshalb zwar meist leichter zu implementieren, aber dadurch, dass dabei meist kein Metadatenbankmanager vorhanden ist, muss auch auf dessen Hilfe bei der Verwaltung der Metadaten verzichtet werden. ²⁷ Bei der zentralen Speicherung hingegen werden alle Metadaten in einer zentralen Metadatenbank ²⁸ abgelegt. Der Vorteil hierbei ist eine einheitliche Sicht auf alle Metadaten eines Systems bzw. eines Unternehmens und die Möglichkeit, Beziehungen und Abhängigkeiten unter den Metadaten abzubilden. Weiterhin wird die zentrale Metadatenspeicherung meist durch einen Repository Manager unterstützt. Außerdem erleichtert eine einzige zentralisierte Metadatenbank die Verwaltung der Metadaten. „Im Idealfall arbeitet ein Repository unternehmensweit und ist somit „single point of control“, in welchem die Metadaten aller Tools zusammenfließen, von allen Tools abgefragt werden können und von dem aus auch deren Steuerung erfolgt.“ ²⁹ Ein entscheidender Vorteil bei der zentralen Speicherung von Metadaten ist, dass in der Regel keine Konsistenzprobleme auftreten. Technisch werden Metadatenbanken meist in relationaler Form realisiert, seltener auch in objektrelationaler oder objektorientierter Form.

Die föderale Speicherung von Metadaten versucht die Vorteile der zentralen und der lokalen Methode zu verbinden. Zwar wird zumindest ein Teil der Metadaten bei den jeweiligen Komponenten gespeichert, es gibt jedoch eine übergeordnete Komponente, in der gespeichert ist, wo sich welche Metadaten befinden und in welchem Zusammenhang sie zueinander stehen.

2.2.5 Metadatenaustausch

Unabhängig davon, welche der drei oben beschriebenen Speicherformen gewählt wird, ist es fast immer notwendig, dass Metadaten zwischen den Systemkomponenten oder

²⁷ Vgl. Quitzsch/2000/“Metadatennutzung von kommerziellen DW-Werkzeugen“/S. 41.

²⁸ Häufig wird diese Metadatenbank auch als Repositorium oder Datenkatalog bezeichnet. Vgl. hierzu

Hymmen/2000/”Datentransformation über MD”/S. 53.

²⁹ Quitzsch/2000/“Metadatennutzung von kommerziellen DW-Werkzeugen“/S. 43.

10