Metadatenverwaltung für das Datawarehouse Metadata

Metadaten-Repository Framework
Metadatenverwaltung für das Datawarehouse
Metadata Repository Framework
Alfred Schlaucher, Oracle Hamburg
Detlef Schroeder, Oracle Düsseldorf
Schlüsselworte: Data Warehouse, Repository, Metadaten, Datenchaos, Apex, PL/SQL,SQL
Die Herausforderung
Wer erinnert sich noch an seinen letzten Besuch in einer Bibliothek, um ein Buch oder ein anderes
Medium auszuleihen? Zur Orientierung ging man meist zunächst zu einem zentralen Katalog oder
Verzeichnis aller Medien. Und wenn man den Titel des gewünschten Buchs nicht wusste, suchte man
mit Hilfe von Schlagworten und anderen Beschreibungsmitteln die zu dem gesuchten Objekt
hinführten. Ein ähnliches Vorgehen gilt auch für den Umgang mit Daten in einem Data Warehouse.
Die Bücher und Medien sind die einzelnen Berichte, Tabellen oder konkrete Kennzahlen und der
zentrale Katalog ist ein Metadaten-Repository. Nur, was für gut geführte Bibliotheken eine
Selbstverständlichkeit war und ist, gilt heute für Data Warehouse-Systeme noch lange nicht.
Ohne Frage Data Warehouse Systeme gehören heute mit zu den wichtigsten Steuerungsinstrumenten
moderner Unternehmen.
Durch die immer enger werdende Verflechtung mit operativen
Anwendungen (OLTP) kann der Ausfall des Data Warehouse sogar zu kritischen Situationen führen.
Kurz: Data Warehouse-Systeme werden gebraucht und fast jedes größere Unternehmen hat sie.
Aber warum sind Anwender und Warehouse-System-Verantwortliche dennoch unzufrieden mit ihren
Systemen? Warum gehen heute selbst große Unternehmen hin und planen ihr Data Warehouse
komplett neu, nachdem sie bereits 10 Jahre und länger ein zentrales unternehmensweites Data
Warehouse betreiben?
Der Grund ist leicht zu verstehen: In den Jahren der Weiterentwicklung der Systeme hat sich in den
Datenstrukturen ein Wildwuchs eingeschlichen, der dazu führt, dass man zum einen Informationen
kaum wiederfindet und zum anderen (als Folge davon) Strukturen redundant oft sogar mehrfach
redundant angelegt wurden. Diese Redundanz ist dann wieder Ursache für nicht stimmige Daten und:
•
•
•
•
Es fehlt die einheitliche Sicht auf wichtige Geschäftsobjekte (Kunden, Produkte..)
Die Pflege des Systems wird immer aufwendiger, weil die notwendige Datenharmonisierung
nachträglich und manuell gemacht werden muss
Fachgebietsübergreifende Informationen stehen nicht bereit.
Reaktionszeiten bei Neuanforderungen werden länger mit der Folge unzufriedener Anwender
(Diese Liste könnte fortgeführt werden. Sie besteht letztlich aus einer Sammlung von konkreten
Berichten von Beteiligten aus Kundenprojekten).
Lösungen
Wer glaubt diese Probleme mit technischen Mitteln oder schlicht mit mehr Hardware zu lösen, der irrt.
Anstatt der Ursache nachzugehen verwaltet man mit mehr Technik- und Hardwareeinsatz nur die
Folgen von schlechtem Datenmanagement und die Menge ungenutzter Daten steigt1.
Die in einer zentralen Data Warehouse-Schicht gesammelten und vereinten Daten sollten nicht nur
von einer besonderen Datenqualität geprägt sein, sondern ihre Ablage sollte auch in einer besonders
1
Es kann nur vermutet werden wie hoch der Anteil ungenutzter Daten liegt.
1
Metadaten-Repository Framework
systematisierten Art und Weise erfolgen. Schichtenarchitektur und Datenmodellierung alleine reichen
nicht aus. Benötigt wird die Verwaltung von Dateninhalten nach semantischen Gesichtspunkten. Die
Datenmodellierung löst die Datenobjekte nur nach ihrer Struktur auf. Sie hat aber keinen Einfluss auf
die Inhalte der Daten. Verhindert wird nicht, dass eine bestimmte Information mehrfach unter
geänderten Namen vorkommen kann. Man spricht von Homonymen und Synonymen. Diese
Problematik kann den Nutzen eines Data Warehouse Systems erheblich schmälern. In einigen Fällen
sind durch die unkoordinierte Verwendung von Inhalten mehrjährige Investitionen im MillionenUmfang gefährdet.
Gelöst wird die Problematik durch eine Reihe von zusätzlichen Maßnahmen in der Data Warehouse Schicht bzw. bei dem Übergang von der Stage - in die Kern-Warehouse-Schicht. Hilfsmittel sind:
•
•
•
•
•
Repository-System als Sammelwerkzeug für Metadaten
Informationskatalog oder Inventar
o Metadaten-gestütztes Verzeichnis aller Datenobjekte in einem Data Warehouse
o Mehrere Zugriffs- / Suchstrategien auf bestehende Objekte
o Deskriptoren-Verfahren zum qualifizieren von Objektnamen und Erleichtern der
Suchstrategien
Beschreibungen über den Zustand, Alter und Zuständigkeiten zu den Informationen
Datenqualitätsstandards und Prüfregeln
Namenskonventionen
Metadaten Repository zur Dokumentation der Inhalte und Zusammenhänge
Eines der wichtigsten Hilfsmittel für die zu lösende Dokumentationsaufgabe ist ein Metadaten
Repository. Ein solches Hilfsmittel ist bei den heute genutzten Data Warehouse Systemen wichtiger
denn je, auch wenn es in der Praxis bislang kaum in der gewünschten Art eingesetzt wird. Hier ist kein
Tool-bezogenes Repository gemeint, also ein Repository, das ein ETL-, Daten- oder
Prozessmodellierungstool mitbringt.
Es ist ein Werkzeug gemeint, das übergreifend Strukturen und inhaltliche Zusammenhänge in
dem gesamten Data Warehouse beschreibt.
•
•
•
Ein solches Werkzeug verhindert die mehrfache Modellierung von gleichen ETL-Strecken,
Tabellen- und View- Definitionen, redundante Dimensionen und Kennzahlen.
Ein solches Werkzeug hilft bestehende Informationen schnell wiederzufinden.
Ein solches Werkzeug ist der einzige Garant für kontrollierte Zustände in einem Data
Warehouse.
Man benötigt ein generisches Repository, in dem die Definitions-Hilfsmittel in Form von MetadatenTypen, Metadaten-Attributen und Metadaten-Beziehungen individuell definiert werden können.
Der Einsatz von neutralen (toolunabhängigen) Metadaten-Repositories hat eine Historie in
Unternehmen. Bereits in den 1980er Jahren wurden solche Systeme eingesetzt. Ihrem Einsatz standen
aber immer Kosten und zusätzlicher Organisationsaufwand entgegen, den sich einzelne Teilprojekte
nicht auferlegen wollten. Angesichts der gravierenden Probleme in unternehmensweiten Data
Warehouse-Systemen, akzeptiert man solche Aufwende heute eher.
Benötigt wird ein einfaches System, das:
•
•
•
•
•
Ohne besonderen technischen Aufwand unternehmensweit einsetzbar ist,
Offen und leicht zugänglich ist ,
Flexibel beliebige Metadaten speichern und abfragen lässt,
sich in bestehende IT-Verfahren mit Programmiermitteln einbinden lässt,
und kostenneutral ist
2
Metadaten-Repository Framework
3
Repository-Framework oder „Business Information Catalogue”
Vor diesem Hintergrund entstand in Oracle Consulting Projekten ein Repository-Werkzeug das genau
diese Anforderungen erfüllt:
•
•
•
•
•
•
Abbilden durchgängiger Metadaten über alle Aspekte des DWH-Einsatzes hinweg
(technische und fachliche Beschreibungen).
Es zeigt die nötige Flexibilität, um alle Informationsarten dokumentieren zu können, d. h.
seine Informationsstruktur ist erweiterbar.
Es ist leicht beherrschbar. Die bereits bestehende Funktionalität ist einfach realisiert. Die
Einarbeitung ist in wenigen Stunden möglich.
Das Repository kann mit PL/SQL, SQL und einer APEX-Entwicklungsumgebung
weiterentwickelt werden und ist daher extrem offen für eine individuelle Ausgestaltung mit
allgemein bekannten Programmiermitteln.
Die Metadaten können auch mit anderen Werkzeugen (also nicht nur mit APEX) gelesen und
geschrieben werden.
Die Verwendung der Sourcen und Beispiele ist frei und nicht an Urheberrechte gebunden.
Ziel ist die Hürden eines Repository-Einsatzes im Data Warehouse so gering wie möglich zu
halten.
Wie funktioniert das System
Mit Hilfe von frei definierbaren sog. Metadaten-Typen können alle Objekte (Strukturen, Programme,
Regel, Tabellen, Views, Kennzahlen, Berichte usw.) aber auch deren Beziehungen untereinander
beschrieben werden. Diese Metadaten-Typen sind beispielhaft in einem Informationsmodell
zusammengefasst2. Ein Beispiel für ein solches Informationsmodel wird als „Warehouse Information
Model“ mit ausgeliefert. Man kann dieses Modell als Startpunkt für ein eigenes firmenspezifisches
Informationsmodell nutzen. Das „Warehouse Information Model“ besteht aus Teilmodellen mit ihren
jeweiligen Metadaten-Typen.
•
•
•
2
Business/Logical Model
o Unternehmensbereich
o Business Question
o Prozess
o Geschäftsobjekt
o
Attribute
Governance Model
o Business Rule
o Glossar / Definition
Physical Model
o System/Anwendung
o Synonym
o Physical Model Area
o Tabelle
o Column
o Technical Rule
o Functional Layer
o Mapping Programm
o Transformation
o Mview
Warehouse Information Model
•
•
•
•
Dimension Model
o Transactional Data/Fact
o Dimension
o Aggregation
Organisation Model
o Data Owner/User
o Stakeholder Departement
o Org_Unit
Reporting Model
o Bericht
o Kennzahl
Operational Model
o Load Process
o Check Process
Metadaten-Repository Framework
Warehouse Information Model (Beispielmodell)
Die Oberfläche und die Bedienung
Die Bedienung des Repositories ist denkbar einfach und erfolgt über die in jeder Oracle-Datenbank
verfügbaren APEX-Oberfläche. Hierüber kann man Objekte mit ihren Attributen und Beziehungen
erfassen und auch auswerten. Dabei dienen die Metadaten-Typen als ein Einstieg für mögliche
Suchstrategien. Jeder, der APEX bedienen kann, ist in der Lage zusätzliche Funktionalität in das
Repository hineinzubringen.
Objekt-Sichten und Suchstrategien
Für das erste Kennenlernen der Oberfläche ist das Laden des mitgelieferten Data Warehouse
Informationsmodells und der zugehörigen Beispieldaten sinnvoll. Die Oberfläche teilt sich in zwei
Bereiche.
•
•
Ein Bereich zum Pflegen und Auswerten der Metadaten (Objekte mit ihren Beschreibungen
und Beziehungen)
Ein zweiter Bereich zum Verwalten der Metadaten-Typen, Attributierung und Beziehungen
(Das ist der Administrationsbereich, der von den Benutzern normalerweise nicht bedient
wird).
Änderungen sind natürlich auch alle über einen Batch-Modus möglich. Dadurch kann man die Pflege
der Repository-Einträge automatisieren.
4
Metadaten-Repository Framework
Abfragen und Suchen nach Objekten
Für die Suche nach bestimmten Objekten bieten sich mehrere Suchstrategien an:
•
•
•
•
•
Suchen über Namen bzw. Namensbestandteilen: (auch mit Wildcards)
Suchen über Object-Typen
Typen (Angezeigt
(
werden nur die Objekte des jeweiligen
ligen Typen
Typen)
3
Suche über Scope : (Scopes
copes oder auch Object Type Groups sind eine Zusammenfassung von
Object-Typen
Typen nach bestimmten Kriterien, z. B. alle Objekt-Typen
Objekt Typen des Ausschnitts
Dimensional Model aus dem Data Warehouse Informationsmodell.)
Suche über Strings in Standard
Standard-Attributen
Suche über Beziehungen (z. B. Strukturauflösungen)
Anzeigen einzelner Objekte mit Attributen und Beziehungen
Über den Reiter Attributes können Objekte zusammen mit Ihren Attributen angezeigt werden:
3
Scope wird
ird in künftigen Erweiterungen des Frameworks durch Meta Type Groups ersetzt.
5
Metadaten-Repository Framework
Anzeige des Objekts R_F_P_Kunde vom Type RULE
Erfassungs-Dialog für neue Objekte. Hier ist zunächst der Objekt-Typ festzulegen.
Die Erfassung neuer Objekte wird durch das Anzeigen möglicher Eingaben unterstützt, Z. B. „welche
Typen lassen sich durch welche Beziehungsarten miteinander verknüpfen“.
Externe Referenzen verwalten
Eine interessante Verwendungsvariante bietet die Möglichkeit externe Referenzen in die Attribute
von Objekten mit aufzunehmen. Damit können Beschreibungen oder Dokumente auch auf einen FileServer ausgelagert werden und müssen nicht in dem Repository gespeichert sein. Damit ist es auch
möglich Programme und Anwendungen über den Typ des Dokuments aufzurufen (z. B. MS Word für
DOCx-Dateien).
Strukturauflösungen
Eine wichtige Funktion ist die zusammenhängende Darstellung von Objekten, die über Beziehungen
miteinander verbunden sind.
Hierzu gibt es zwei Vorgehensweisen:
•
•
Einstieg über den Tab Resolution und die Auswahl von Objekt-Typ und Name.
Einstieg über den Tab Objects und die kleine Lupe
im rechten Bereich in den jeweiligen
Listen-Zeilen.
6
Metadaten-Repository Framework
Strukturauflösung / Auswertung über Beziehungen
Zusätzliche Generierung von HTML-Berichten
HTML
zu einzelnen Objekten
Das aktuelle Framework verfügt bereits über einen Berichte-Generator,
Berichte Generator, mit dem man Objekte
zusammen mit Attributen und Beziehungen zu anderen Objekten
Objekten als Bericht in einem HTML
HTML-Format
darstellen kann.
Mit Klassifikationen arbeiten
Suchstrategien über Attribut-Inhalte
Inhalte sind schon sehr hilfreich. Sie erlauben bereits eine Suche nach
Repository-Inhalten,
Inhalten, wie sie z. B. mit Suchmaschinen im Internet möglich ist. Diese Such
Suche kann
jedoch immer noch zufällig sein, weil die Treffermenge von den zufällig durch den Erfasser
gewählten Begrifflichkeit abhängt.
7
Metadaten-Repository Framework
Sicherer und methodisch korrekter ist die Implementierung eines Klassifikationsverfahrens. Hierzu
legt man Beschreibungskategorien (Klassen) fest und definiert für jede Kategorie (Klasse) ein festes
Set von gültigen Werten. Angewendet auf das Repository bedeutet das:
Man definiert für die gewünschten Metadaten-Typen für jede Kategorie einen neuen Attribut-Typ und
legt gültige Werte fest, die für diese Attribute eingetragen werden können.
Ein Beispiel: Der Metadaten-Typ Tabellen (oder Table) verfügt bereits über die beschreibenden
Attribute: Description, Note, External_Reference, Last_Update, Version und Variant. Man kann
jedoch z. B. folgende Attribute mit den entsprechenden gültigen Werten (in eckigen Klammern)
hinzufügen:
Herleitung [Berechnung / Aggregat / Definiert / Basiswert]
Kategorie [Stamm / Referenz / Kennzahl]
Status [geplant / in_Arbeit / im Einsatz / obsolet]
Sachgebiet [Liste Sachgebiete]
Themengebiet [Liste Themengebiete]
…
Empfehlungen für den Repositoryeinsatz
An dieser Stelle sind praktische Empfehlungen für den Einsatz eines Repositories aufgelistet, wie sie
bereits aus dem Einsatz von anderen Repository-Systemen aus den letzten Jahren bekannt sind:
•
•
•
•
•
•
Die Aktualisierung und Pflege von Repository-Einträgen sollte für das Gros der Daten
automatisiert stattfinden. Manuelle Erfassung ist nur in überschaubarem Masse und auch nur
für Administratoren sinnvoll.
Die Pflege sollte in die Betriebsprozesse des Data Warehouse organisatorisch eingebettet sein.
Man sollte mit nur wenigen Informationen beginnen. D. h. mit wenigen Metadaten-Typen aus
einem bestimmten Umfeld.
Daten sollten nicht zu detailliert beschrieben werden. Eine große Detailtiefe gehört in
spezielle Tools-Repositories oder Datenbank-Kataloge.
Die Namen von Objekttypen, Attributtypen und Beziehungstypen sollten sprechend gewählt
werden.
(Weitere Empfehlungen vom Autor)
Bezug und Installation
Man kann die Installations-Sourcen und die Dokumentation zu dem Repository, sowie Beispieldaten
und das erwähnte Informationsmodell downloaden unter
www.oracledwh.de
Das ist die Download-Seite für die Oracle-Data Warehouse Community über die man sich auch
registrieren kann, um weitere Informationen zu erhalten.
Rückfragen: [email protected] / [email protected]
8