20080708u Sybase Metadaten-Integration für Qualitätsmanagement in BI

»manage it« als

E-Paper 5-6 2011
E-Paper 3-4 2011
E-Paper 1-2 2011
E-Paper 11-12 2010
E-Paper 9-10 2010
E-Paper 7-8 2010
E-Paper 5-6 2010

Metadaten-Integration ist Grundlage für ein durchgängiges Qualitätsmanagement des BI-Prozesses

Vertrauen ist gut …

Mit der operativen BI erhalten immer mehr Benutzer auf der Business-Seite Zugriff auf BI-Tools. Doch aktuelle Untersuchungen zeigen, dass viele zweifeln, ob Business-Intelligence-Informationen tatsächlich richtig und vollständig sind. Der Grund: Der BI-Prozess – von der Extraktion der Daten aus verschiedenen operativen IT-Systemen bis zur Präsentation der Ergebnisse auf dem Frontend – ist undurchsichtig. Den Schlüssel für mehr Transparenz und Qualität liefert das einheitliche Management aller Metadaten.

ertrauen ist schön und gut – aber wo bleibt die Kontrolle? So fragt wohl mancher Verantwortliche, wenn er BI-Reports und KPIs betrachtet, auf deren Grundlage er Entscheidungen treffen soll. Beispielsweise sind nach einer Umfrage der Economist Intelligence Unit aus dem Jahr 2007 weniger als zehn Prozent der Spitzenmanager überzeugt, dass sie bei kritischen Entscheidungen wirklich über die notwendigen Informationen verfügen.

Diese Vertrauenskrise resultiert vor allem daraus, dass die Nutzer nicht nachvollziehen können, wie die Informationen letztendlich zustande kommen. Die Daten in BI-Reports sind »produzierte« Werte. Sie beziehen den »Rohstoff« aus einer Vielzahl operativer IT-Systeme und durchlaufen einen komplexen Prozess der Extraktion, Transformation, Aufbereitung und Anreicherung, bevor sie im Data Warehouse ausgewertet und auf einem BI-Frontend angezeigt werden können.

Neue Herausforderungen durch operationale BI.

Dieser Prozess ist immer komplexer geworden. Zunehmend werden die traditionellen strategischen und taktischen BI-Analysen durch operationale BI ergänzt. Diese zielt darauf ab, Entwicklungen möglichst zeitnah zu beobachten, um bei Problemen korrigierend eingreifen zu können. Ein Beispiel ist die Risikoanalyse im Wertpapiergeschäft der Banken: Hier werden große Mengen sekundenaktueller und historischer Daten gemeinsam analysiert, um blitzschnell Entscheidungen zu treffen. Deshalb werden immer mehr heterogene operative Anwendungen in die BI-Analysen einbezogen. Dadurch nehmen Komplexität und Datenmengen rapide zu.

Der BI-Prozess beginnt bei den operativen IT-Anwendungen wie Handelssystemen, Provisionsberechnung, Inventar, Finanzen, Auftragsverarbeitung usw., die meist auf heterogenen Rechnern und Datenbanken betrieben werden. In ihnen entstehen – vorwiegend durch Ereignisse, wie beispielsweise dem Eingang einer Bestellung im Auftragsverarbeitungs-System – Daten, die in BI-Reports einfließen. Im ETL-Prozess ist definiert, welche Tabellen dafür aus welchen operativen Systemen in das Data Warehouse übernommen werden. Die extrahierten Daten werden in einer Staging Area zwischengespeichert, aufbereitet und bei Bedarf auch angereichert. Sie werden dann idealerweise 1:1 in das Data Warehouse übernommen.

An Methoden und Instrumenten für das durchgängige Qualitätsmanagement dieses Prozesses hat es in der Vergangenheit gefehlt. Der Nutzer konnte deshalb kaum nachvollziehen, ob die BI-Reports, die er erhält, wirklich die Realität abbilden.

Die besondere Herausforderung liegt darin, dass sich Business-Definitionen auf der technischen Ebene widerspiegeln müssen. Zum Beispiel kann die geschäftliche Größe »Umsatz« unterschiedlich zusammengesetzt sein – mit oder ohne Mehrwertsteuer, vor oder nach Steuer usw. Davon hängt ab, welche Tabellen beziehungsweise Spalten aus den operativen Anwendungen extrahiert werden. Wann wurden die Daten zuletzt aktualisiert? Welche Prozesse sind letzte Nacht gelaufen? Sind dabei Fehler aufgetreten, wenn ja: welche? Fragen wie diese kann der Nutzer kaum überprüfen. Auch kann er zusätzliche Informationen benötigen, für die aus operativen Systemen neue Tabellen entnommen werden und in den ETL-Prozess einfließen müssen. Ist all dies auch wirklich passiert? Wenn in einer operativen Datenbank eine neue Tabelle hinzugefügt oder eine Spalte umbenannt wird, hat dies Auswirkungen auf den ETL-Prozess. Wurden die entsprechenden SQL-Statements angepasst?

Einheitliches Management aller Metadaten notwendig.

Den Schlüssel für mehr Qualität und Transparenz im BI-Prozess liefert das einheitliche Management der Metadaten. Solche »Daten über Daten«, die Inhalte, Qualität und andere Charakteristika beschreiben, fallen auf jeder Station an. So ist in den operativen Datenbanken definiert, welche Tabellen es gibt, welche Namen und Struktur diese haben etc. Im ETL-Prozess ist beschrieben, welche Tabellen (oder Spalten davon) übernommen werden; im Übernahmeprozess selbst wird unter anderem berichtet, ob ein Job gelaufen ist und wie lange er gedauert hat. Für die Staging Area gibt es Transformationsregeln, zum Beispiel auf welche Weise Tabellen zusammengeführt werden. Im Data Warehouse selbst ist beschrieben, welche Tabellen, Spalten, Zugriffsberechtigungen und vordefinierten Reports existieren, welcher Nutzer welche Reports starten darf und vieles mehr. Data Marts wiederum geben Auskunft, wer welche Reports wann ausgeführt hat und ob sie erfolgreich waren.

Wir haben es dabei mit drei Kategorien zu tun:

§ Technische Metadaten, die Strukturen (wie etwa Tabellen) und Abhängigkeiten zwischen den Objekten beschreiben. In der Regel werden sie von den Tools beziehungsweise Datenbanksystemen selbst zur Verfügung gestellt. Sie sind relativ statisch und vor allem für Entwickler und Data-Warehouse-Manager interessant.

§ Business-Metadaten mit Erläuterungen, was bestimmte Objekte bedeuten (wie etwa die erwähnte Umsatzdefinition). Sie können mit Hilfe von Query-Tools abgefragt werden. Sie sind ebenfalls statischer Natur. Von Interesse sind sie für Endbenutzer und Entscheider.

§ Operationale Metadaten, die beschreiben, wie ein System eingesetzt wird, wie lange es aktiv war, welche Batch-Läufe erfolgreich waren, ob alle notwendigen Jobs erfolgreich durchgelaufen wurden; außerdem bieten sie vielfältige Statistiken über die Nutzung von Informationen. Sie werden mit Hilfe spezieller Tools zur Prozesskontrolle erhoben. Diese Daten sind dynamisch und für alle Gruppen relevant.

Die Entwicklung des Metadaten-Managements wird heute in drei Generationen eingeteilt: Die erste deckte die technischen Datenbeschreibungen ab, in der zweiten kamen die geschäftlichen hinzu, und die dritte Generation befasst sich mit allen drei Kategorien gemeinsam.

Framework verschiedener Tools.

Erst die durchgehende, transparente Darstellung und Auswertung aller Metadaten von der geschäftlichen bis zur operativ-technischen Ebene ist Voraussetzung für mehr Transparenz und Qualität der BI-Informationen. Dabei ist ein modellgestützter Ansatz sinnvoll. Zur Umsetzung empfiehlt sich der Einsatz eines Frameworks, das unterschiedliche Werkzeuge kombiniert.

Dazu gehört zunächst ein »Linker«, der alle Metadaten auf den verschiedenen Stationen erfasst und verknüpft. Sie werden dann in einem Repository gespeichert. Dessen technische Grundlage sollte eine leistungsfähige analytische Datenbank wie etwa Sybase IQ sein, damit die Datenmengen – oft im Terabyte-Bereich – effizient gespeichert und ausgewertet werden können. So erhält man ein Data Warehouse, in dem sich die nunmehr in Daten transformierten Metadaten mit einem Modellierungs-Tool bearbeiten lassen. Dieses Werkzeug sollte offen sein für unterschiedliche Modelle.

Mit einer solchen offenen, integrierten Umgebung können die Endnutzer und Data-Warehouse-Manager den gesamten BI-Prozess sowohl designen als auch kontrollieren. Zum Beispiel können sie ihn von der Extraktion der Daten aus den operativen Systemen bis zur Präsentation der Information auf dem BI-Frontend grafisch darstellen, wobei verschiedene Symbole die beteiligten Komponenten und Teilprozesse repräsentieren: Datenbanken, Applikationen, Batch-Läufe, ETL-Prozesse usw. Die Nutzer können verfolgen, wo eine Information wie die erwähnte Business-Größe »Umsatz« herkommt, aus welchen Komponenten sie sich zusammensetzt, welche Regeln dabei angewandt wurden, aus welchen operativen Systemen diese Daten stammen und wie der dahinter stehende ETL-Prozess genau aussieht.

Zusammenhänge werden transparent.

Entscheidend ist, dass wechselseitige Abhängigkeiten aufgezeigt werden. Mit Hilfe von Impact-Analysen erkennt dann ein Nutzer, welche Auswirkungen geplante Änderungen nach sich ziehen und welche Teilkomponenten des BI-Prozesses er sich dazu näher ansehen muss.

So kann er etwa definieren oder nachprüfen, wie die geschäftliche Größe »Bestellung« zustande kommt, indem er verschiedene logische Sichten betrachtet: Zunächst die grafische Modellierung des Geschäftsprozesses »Create Order« (Business Process Modelling – BPM) sowie eine verbale Beschreibung in einem Word-Dokument. Das Modellierungs-Tool strukturiert dieses Dokument und verknüpft einzelne Aussagen mit den entsprechenden Komponenten der BPM-Grafik. Auf der nächsten Ebene wird ein logisches Modell der Datenbank angezeigt, das die einzelnen Komponenten dieses Prozesses enthält (Conceptual Data Modelling – CDM). Mit Hilfe des Entity-Relationship-Modells werden die Entitäten mit ihren Attributen (zum Beispiel »Kunde« mit Kunden-Nummer, Name, Adresse) und deren Beziehungen (1:n, 1:1, 0:n usw.) angezeigt. Aus diesem abstrakten Modell erzeugt das Modellierungs-Tool wiederum automatisch das physische Modell für das installierte RDBMS. Dabei werden aus Entitäten Tabellen, aus Beziehungen entstehen referenzielle Integrität, Index- und Regel-Definitionen. Die Tabellen spiegeln damit den Geschäftsprozess.

Legt die Geschäftsseite zum Beispiel im Word-Dokument fest: »Bei Zahlung mit Kreditkarte ist zuerst prüfen, ob diese gültig ist«, muss sich diese Aufforderung in einer entsprechenden Geschäftsprozess-Modellierung, den Entitäten und Beziehungen sowie schließlich in den Datenbank-Tabellen widerspiegeln. Mit einem solchen Ansatz können Entscheider, Data-Warehouse-Manager und andere Nutzer Informationsgrößen eindeutig definieren, sie grafisch modellieren und manipulieren, ihre Struktur nachvollziehen und überprüfen. Sie überschauen die Auswirkungen von Änderungen, erkennen Prozessstörungen und können gezielt eingreifen, um die Qualität der Resultate zu sichern.

Theo Ruland

_____________________________________________________________________

Theo Ruland ist Geschäftsführer der Sybase GmbH, Düsseldorf.

Auf jeder Stufe des BI-Prozesses fallen Metadaten an. In einem eigenen Metadaten-Warehouse gespeichert, dienen sie dem Qualitätsmanagement des gesamten Prozesses.

Folgen Sie »manage it«

auf Google+

Copyright © 2003-2012 ap Verlag GmbH