Metadaten und Datenqualität in Data Warehouses

Gliederung

ABKÜRZUNGSVERZEICHNIS

ABKÜRZUNGSVERZEICHNIS

1 EINLEITUNG

2 GRUNDLAGEN UND DEFINITIONEN
2.1 DATA WAREHOUSES
2.2 METADATEN
2.2.1 Definition Metadaten
2.2.2 Arten von Metadaten
2.2.3 Einsatzzwecke von Metadaten
2.2.4 Metadatenspeicherung
2.2.5 Metadatenaustausch
2.3 QUALITÄT UND DATENQUALITÄT
2.3.1 Definition Datenqualität
2.3.2 Kriterien für Datenqualität
2.3.3 Datenqualität von Informationssystemen
2.3.4 Allgemeine Methoden zur Verbesserung von Datenqualität

3 QUALITÄT VON DATA-WAREHOUSES
3.1 QUALITÄTSKRITERIEN VON DATA-WAREHOUSES
3.2 RISIKEN FÜR DIE QUALITÄT VON DATA-WAREHOUSES
3.3 BEDEUTUNG VON METADATEN FÜR DATA-WAREHOUSE QUALITÄT
3.3.1 Bedeutung von Metadaten im Data-Warehouse
3.3.2 Speicherung und Verarbeitung der Metadaten im Data-Warehouse
3.4 KONZEPTE ZUR STEIGERUNG VON DATA-WAREHOUSE QUALITÄT
3.4.1 Doppelte Entwicklung - Stockhammer und Kennel
3.4.2 Qualitätssteigerung als Optimierungsproblem - Ballou / Tayi
3.4.3 CLIQ - Der Ansatz von Hinrichs
3.4.4 Terminologiemanagement - Der Ansatz von Lehmann / Jaszewski
3.4.5 Alles in einem - Der Ansatz des DWQ

4 UMSETZUNG DER KONZEPTE AM PRAKTISCHEN BEISPIEL
4.1 BESCHREIBUNG DER AUSGANGSSITUATION
4.2 BESCHREIBUNG DER UMSETZUNGSMAßNAHMEN
4.2.1 Metadata-Services - Das Repository
4.2.1.1 Aufbau der Metadata-Services
4.2.1.2 Füllen der Metadata-Services
4.2.2 Analysis Services - Der OLAP-Server
4.2.2.1 Metadaten in den Analysis Services
4.2.2.2 Analysis Manager als Anwendungsoberfläche
4.2.3 Arcplans inSight/dynaSight - Das Front-End
4.2.3.1 Zugriff auf das Data-Warehouse und die Metadaten
4.2.3.2 Implementierung von Metadaten

5 SCHLUSSBEURTEILUNG
5.1 BEURTEILUNG DER MAßNAHMEN
5.2 ZUKÜNFTIGER ENTWICKLUNGSBEDARF

LITERATURVERZEICHNIS

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)25 ABB. 11 DATENFLÜSSE ZWISCHEN DER METADATENBANK UND DEN DATA-WAREHOUSE (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

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

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.

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 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.

Abbildung in dieser Leseprobe nicht enthalten

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 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.

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.¹⁴

Abbildung in dieser Leseprobe nicht enthalten

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 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

Abbildung in dieser Leseprobe nicht enthalten

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 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 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 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.²⁵

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.²⁶

Abbildung in dieser Leseprobe nicht enthalten

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 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 zwischen unterschiedlichen Systemen ausgetauscht werden können.³⁰ Um dies zu erleichtern oderüberhaupt erst zu ermöglichen, müssen verschiedene Vorraussetzungen erfüllt werden. Auf der einen Seite ist das ein systemweit einheitliches Schema für Metadaten. Hier gab es neben einer Reihe von herstellerspezifischen Ansätzen und Vorschlägen aus der Forschung zwei bedeutende Standardbemühungen, die von Herstellerzusammenschlüssen vorangetrieben wurden. Zu nennen ist hier das Open Information Model der Metadata Coalition, der unter anderem Microsoft angehörte. Inzwischen wurde das OIM jedoch aufgegeben und die Metadata Coalition aufgelöst.³¹ Bei dem anderen Standard handelt es sich um das Common Warehouse Metamodel, das unter anderem von IBM und Oracle entworfen und an die Object Management Groupübergeben wurde. Abbildung 5 stellt die

Abbildung in dieser Leseprobe nicht enthalten

Abb. 5 Gemeinsamkeiten undÜberschneidungen des CWM und OIM (Staudt, u. A., xxxx)

Schnittstellen der beiden Standards dar. Die Abbildungen 6 und 7 zeigen die grobe Architektur der beiden Schemata. Das CWM greift zum Teil auf bereits bestehende Standards, wie MOF und XMI, der OMG zurück. „The Meta Object Facility (MOF) is the OMG’s adopted technology for defining metadata and representing it as objects.”³² XMI ist ein XML orientierter Austauschstandard der OMG. Zwar ist die aufgelöst bzw. in die ONGüberführt worden, allerdings ist das OIM immer noch in verschiedenen aktuellen Anwendungssystemen implementiert. Außerdem verweist Microsoft immer noch auf seiner Homepage auf die inzwischen stillgelegte Seite der MDC und auf den Einsatz des OIM. Auch die Version 1.1 des CWM vom März 2003 enthält keine Hinweise auf die Integration des OIM, sondern bietet lediglich einen Vergleich der beiden Modelle.³³ Da das OIM weder in das CWM integriert wurde noch seine Bedeutung für aktuelle Anwendungen verloren hat, wird es, auch wenn eine Weiterentwicklung nicht stattfinden wird, im folgenden Verlauf der Arbeit als aktuelle Alternative zum CWM betrachtet. Ein ausführlicher Vergleich der beiden Standards würde den Rahmen dieser

Abbildung in dieser Leseprobe nicht enthalten

Abb. 6 Paketstruktur des OIM (Vetterli, u. A., xxxx)

Arbeit sprengen. Daher sei an dieser Stelle nur auf einige grundlegende Gemeinsamkeiten und Differenzen hingewiesen, die Vetterli u. A. bei einem Vergleich herausgearbeitet haben:³⁴

- Beide Standards verwenden UML³⁵ und XML³⁶ als Grundlage und verfügenüber eine Paketstruktur, die es ermöglicht, einzelne Data-Warehouse Teile abzugrenzen.
- CWM ist hauptsächlich auf Data-Warehouses ausgerichtet, während OIM einen weitergehenden Anspruch stellt.
- Beide Standards unterstützen bisher hauptsächlich technische Metadaten und sind weniger auf geschäftsbezogene Metadaten ausgerichtet.
- Im Gegensatz zum CWM ist das OIM auf relational organisierte Daten beschränkt. Neben einem Standard-Schema ist eine weitere Voraussetzung die Existenz von entsprechenden Schnittstellen oder Austauschformaten. Ein Metadatenschema beschreibt die Beziehungen der Metadaten untereinander und zu den zugrunde liegenden Daten. Außerdem enthält es Informationenüber die Metadatentypen und die verwendeten Formate. Im Gegensatz zu einem Schema beschreibt ein Austauschformat weniger die Beziehungen der Daten zueinander, sondern eher in welcher Art die Daten zum Austausch mit einer externen Komponente strukturiert werden müssen. Ein Schema kann theoretisch in verschiedenen Austauschformatenübertragen werden. Auf der anderen Seite können Metadatenüber eine entsprechende Schnittstelle bzw. ein gemeinsames Austauschformat in verschiedenen Schemata dargestellt werden.³⁷ Ein Austauschformat führt in der Regel zu einer einzelnen Datei, in der die auszutauschenden Metadaten in einer durch das Austauschformat definierten Reihenfolge abgelegt sind. Sowohl OIM als auch CWM nutzen den XML Standard zum Datenaustausch und definieren APIs. Eine API ist eine programmierbare, dokumentierte Schnittstelle, die es den Anbietern erlaubt auf die Metadaten der verschiedenen Werkzeuge direkt zuzugreifen, ohne die Daten vorher zu exportieren. „Auch für den Fall, dass verschiedene Produkte verschiedene dokumentierte APIs anbieten, ist es dem Anwender noch möglich, selbst so genannte Bridges zu programmieren, welche die APIs verbinden.“³⁸ Im Bereich der herkömmlichen

Abbildung in dieser Leseprobe nicht enthalten

Abb. 7 Struktur des CWM (OMG, 2003)

Datenbanken ist die ODBC-Schnittstelle, die wahrscheinlich bekannteste API. Für den Metadatenaustausch ist sie nur insofern geeignet, als dass sich die Datenbankkataloge der jeweiligen Datenbank abfragen lassen. Um unterschiedliche APIs oder Austauschformate trotzdem miteinander zu verbinden, werden von verschiedenen Herstellern Gateways angeboten. Ein Gateway ist eine allgemeinere Form einer Bridge. Er verbindet zwei unterschiedliche APIs, Austauschformate oder Austauschformate und APIs miteinander. Jedoch ist zu beachten, dass es sich bei Gateways in der Regel um proprietäre, individuelle Verbindungen zwischen zwei Systemen handelt. Die allgemeine Integrationsfähigkeit wird hierdurch nicht gesteigert.

2.3 Qualität und Datenqualität

Nach einer Definition des Begriffs der Datenqualität soll im folgenden Abschnitt dargestellt werden, welche verschiedenen Kriterien es für Datenqualität gibt. Im Anschluss daran werden einige generelle Voraussetzungen zur Erreichung von Datenqualität kurz vorgestellt.

2.3.1 Definition Datenqualität

Für den Begriff Qualität gibt es nach Garvin fünf Definitionsansätze.³⁹ Der produktbezogene Ansatz geht davon aus, dass Qualität eine objektive, präzise messbare Eigenschaft des Produktes ist. Der prozessbezogene Ansatz bewertet Qualität nach der Einhaltung von Spezifikationen beim Produktionsprozess. Der wertbezogene Ansatz sieht Qualität als Preis-Leistungs-Verhältnis an. Der transzendente Ansatz betrachtet Qualität als eine angeborene Eigenschaft eines Produktes, die nicht messbar sondern nur erfahrbar sei. Der anwenderbezogene Ansatz geht davon aus, dass die Qualität eines Produktes nicht alleine durch das Produkt bestimmt wird, sondern auch durch den Benutzer und seine Anforderungen, sowie seine Kenntnisseüber die Eigenschaften des Produkts. Beim anwenderbezogenen Ansatz gibt es also zwei Faktoren, die die Qualität bestimmen: Einmal die tatsächlichen objektiven Eigenschaften des Produkts und zum anderen die Eigenschaften, die der Anwender subjektiv dem Produkt zuordnet.

In der vorliegenden Arbeit wird Datenqualität, der Mehrheit der Literatur folgend, nach dem anwenderbezogenen Ansatz definiert.⁴⁰ Demnach haben Daten dann eine hohe Qualität, wenn sie die Bedürfnisse des Benutzers erfüllen. D. h. allerdings auch, dass Datenqualität nur individuell bewertet werden kann. „Qualität ist eine relative und keine absolute Eigenschaft. Die Qualität der Daten kann daher nur relativ zu ihrer jeweiligen Verwendung beurteilt werden.“⁴¹ Als nicht aussagekräftig kritisiert wird diese Definition hingegen von Naumann, dessen Ziel es ist, aus mehreren Qualitätskennzahlen eine einzige, vergleichbare Qualitätskennzahl für jede Datenquelle zu aggregieren.⁴²

In der Literatur findet man neben dem Begriff Datenqualität häufig auch den Begriff Informationsqualität. Da in der Regel durch beide Begriffe die selbe Thematik behandelt wird⁴³ und es bisher keine einheitliche Abgrenzung der Begriffe Daten und Information gibt⁴⁴, scheint es erlaubt, die Begriffe als weitestgehend synonym zu betrachten. Im weiteren Verlauf der Arbeit wird der Begriff Datenqualität verwendet.

2.3.2 Kriterien für Datenqualität

Die Tatsache, dass Datenqualität nur individuell beurteilt werden kann, bedeutet nicht, dass man keine generellen Kriterien zur Qualitätsbeurteilung finden und messen kann. Nur muss jeder Benutzer dann für sich selbst entscheiden, welchen Wert die Kennzahlen der Kriterien annehmen müssen, damit die Daten für ihn eine hohe Qualität haben. Um Qualitätskriterien abzuleiten, gibt es drei verschiedene Ansätze.⁴⁵ Beim intuitiven Ansatz werden die Kriterien auf Grund von persönlicher Erfahrung und Intuition ausgewählt. Beim systematischen Ansatz werden die Quellen möglicher Datenqualitätsdefizite ermittelt und aus diesen dann Qualitätskriterien abgeleitet. Die dritte Möglichkeit ist der empirische Ansatz. Hierbei werden die Kriterien durch Befragung der Benutzer ermittelt. Für die Ermittlung von Datenqualitätskriterien nach einem anwenderbezogenen Ansatz scheint die empirische Methode als einzige angemessen, da sie schon bei der Erstellung des Kriterienkatalogs den Anwender mit einbezieht und auf diese Weise auch Kriterien Eingang finden, denen der Entwickler keine Bedeutung zugemessen hätte.⁴⁶

In der Vergangenheit sind eine Vielzahl von Kriterienkatalogen für Datenqualität aufgestellt worden.⁴⁷ Wang und Strong haben als einzige auf Basis einer umfangreichen empirischen Studie ein hierarchisches Datenqualitätsmodell erstellt. Dieses Modell teilt Datenqualität in vier Kategorien ein, die sich wiederum aus insgesamt 15 Dimensionen zusammensetzen.⁴⁸ Diese 15 Dimensionen lassen sich weiter einteilen in objektiv ermittelbare Dimensionen und Dimensionen, die nur subjektiv unter Einbeziehung des jeweiligen Anwenders bzw. Anwendungsfalls ermittelt werden können.⁴⁹ Zu den objektiv

Abbildung in dieser Leseprobe nicht enthalten

Abb. 8 Hierarchisches Datenqualitätsmodel (Wang, Strong, 2000)

Aktualität. Obwohl sich für diese Dimensionen objektive Kennzahlen ermitteln lassen, liegt es immer noch im Ermessen des Anwenders, zu beurteilen, ob z. B. eine Genauigkeit von 80% eine hohe oder niedrige Qualität darstellt. Um dies zu beurteilen, ist es nicht nur wichtig, dass der Anwender den Grad der Genauigkeit kennt, sondern auch, dass er die verwendete Definition von Genauigkeit kennt. Die subjektiven Dimensionen hingegen können nicht durch einen neutralen Dritten gemessen werden. So ist es einem Dritten sehr wohl möglich, durch Vergleich mit der Wirklichkeit eine allgemeingültige Kennzahl für die Genauigkeit zu ermitteln. Es ist jedoch grundsätzlich nicht möglich, eine allgemeingültige Kennzahl für die Relevanz von Daten zu ermitteln, da diese Kennzahl direkt vom Anwendungsfall abhängt.

Naumann u. A. haben für alle Qualitätsdimensionen Kennzahlen aufgestellt. Dabei ist jedoch speziell für die subjektiven Kriterien anzumerken, dass diese Kennzahlen zum einen vor einem speziellen Anwendungshintergrund aufgestellt wurden und zum anderen von jedem Benutzer individuelle Bewertungen der Kriterien eingeholt werden.⁵⁰

[...]

---

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

² 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 DWSchemata“/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.

⁷ 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.

¹⁰ 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.

¹³ 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.

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

¹⁷ 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.

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

²² 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.

²⁷ 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.

³⁰ Vgl. Hymmen/2000/”Datentransformationüber MD”/S. 72 f.

³¹ Vgl. XMLResource.de(WWW)/2000/”Microsoft gibt OIM auf” und OMG(WWW)/2000/“DW-Standards to merge in the OMG”.

³² OMG(WWW)/2003/“CWM Specification“/S. 26.

³³ Vgl. OMG(WWW)/2003/“CWM Specification“/S. 517 ff.

³⁴ Vgl. zu den folgenden Punkten Vetterli, Vaduva, Staudt/2000/“MD Standards for DW”/S. 8. Eine ausführliche Beschreibung des CWM ist bei OMG(WWW)/2003/“CWM Specification“ zu finden. Für eine Beschreibung des OIM siehe Hymmen/2000/”Datentransformationüber MD”/S. 38 ff. Leider war eine vollständige OIM Spezifikation nicht mehr auffindbar.

³⁵ Mehr zu UML bei Fowler, Scott/1999/“UML konzentriert“.

³⁶ Mehr zu XML bei North, Hermans/2000/“XML in 21 Tagen“.

³⁷ So wäre es denkbar, dass nach XML exportierte Metadaten des OIM in das CWM importiert warden können, sofern Sie die selbe DTD verwenden. Rosenthal, Sciore(WWW)/1999/“Helping Negotiate the Details“ beschäftigen sich mit dem Austausch von Metadaten zwischen verschiedenen Schemata.

³⁸ Quitzsch/2000/“Metadatennutzung von kommerziellen DW-Werkzeugen“/S. 51.

³⁹ Vgl. Garvin/1998/“What does Product Quality really mean?“/S. 40.

⁴⁰ Vgl. Helfert, Hermann, Strauch(WWW)/2001/„Datenqualitätsmanagement“/S. 6. Einen produktbezogenen Ansatz hingegen verwendet Hinrichs/2002/“Datenqualitätsmanagement in DW“/S. 26.

⁴¹ Schwinn/1999/“Datenqualität durch Teamarbeit“/S. 1.

⁴² Vgl. Naumann/“From Databases to Information Systems“/S. 8.

⁴³ In Eppler/2000/“Review of Information Quality Frameworks“ werden verschiedene Qualitäts-Frameworks verglichen, in denen sowohl der Begriff Informationsqualität als auch der Begriff Datenqualität im selben Zusammenhang verwendet wird.

⁴⁴ Vgl. Helfert/2001/“Datenqualitätsmanagement“/S. 3. Es ist jedoch unbestritten, dass eine Unterscheidung zwischen Daten und Informationen möglich ist und je nach Kontext auch sinnvoll sein kann.

⁴⁵ Vgl. Eppler/2003/“Managing Information Quality“/S. Hinrichs/2002/“Datenqualitätsmanagement in DW“/S. 28. 62. Mehr bzw. andere Ansätze nennt

⁴⁶ Vgl. zu diesem Absatz Wang, Strong/1996/“Beyond Accuracy“/S. 7.

⁴⁷ Für einen Vergleich dieser Kataloge siehe Eppler/2000/“Review of Information Quality Frameworks“.

⁴⁸ Vgl. Wang, Strong/1996/“Beyond Accuracy“/S. 20 ff. Siehe hierzu auch Abb. 8. Dieses Modell wird auch von Naumann, Leser, Freytag/1999/“Quality-driven Integration“ verwendet.

⁴⁹ Vgl. Kahn, Strong, Wang/2002/“Information Quality Benchmarks“/S. 187 f.

⁵⁰ Vgl. Naumann, Leser, Freytag/1999/“Quality-driven Integration“/S. 9 ff.