-
Die Erfindung betrifft ein Verfahren zur Erstellung eines Metadaten-Datenmodells für eine BI-Infrastruktur bestehend aus mehreren heterogenen operativen Quellsystemen und unterschiedlichen ETL-Werkzeugen zur Ladung der Daten.
-
Das Business Intelligence (BI) Umfeld eines Unternehmens besteht in der Regel aus einer Vielzahl unterschiedlicher operativer Datenbanksystemen. Begründet ist diese Heterogenität meist durch die unterschiedlichen Geschäftsfelder eines Unternehmens, die zumeist durch unterschiedliche Datenbanksysteme bedient werden.
-
Die operativen Geschäftsdaten der einzelnen Quellsysteme werden in verschiedenen Verdichtungsschritten bzw ETL-Prozessen (Extracting, Tranforming, Loading) aufbereitet und in einem Data-Warehouse bzw. separaten Datamarts gespeichert, um diese für die Erstellung von Kundenprofilen und zur Prognostizierung von Kundenverhalten verwenden zu können, bspw. zur Erstellung einer Marktanalyse bzw. für das Marktmanagement. In der Praxis benötigen unterschiedliche Quellsysteme aufgrund ihrer oftmals individuellen Datenstrukturen speziell zugeschnittene ETL-Prozesse für das Laden und Transferieren der Daten ins Data Warehouse bzw. die Datamarts. Damit einhergehend sind folglich individuelle ETL-Werkzeuge notwendig.
-
Die technische Heterogenität der operativen Quellsysteme und die damit einhergehende Diversität der verwendeten Datenladestrecken bis in die Datamartzielsysteme stellen für jedes große Unternehmen eine Herausforderung dar, denn die Nachvollziehbarkeit des Datenflusses kann in der Regel nur so lange gewährleistet werden, wie ein einheitliches ETL-Werkzeug für die Ladestrecken verwendet wird. Eine vollständige Transparenz des Datenflusses über alle Ladestrecken ist für ein valides Berichtswesen und Nachvollziehbarkeit jedoch unverzichtbar. Bisher konnte jedoch keine passende Lösung gefunden werden, die auch einen ETL-Werkzeug übergreifenden Ansatz für eine vollständige Transparenz des Datenflusses ermöglicht.
-
Die Aufgabe der vorliegenden Erfindung besteht darin, ein geeignetes Verfahren bzw. System zur entwickeln, das eine vollständige Transparenz des Datenflusses über die gesamte BI-Infrastruktur erlaubt.
-
Gelöst wird diese Aufgabe durch ein Verfahren gemäß den Merkmalen des Anspruchs 1. Vorteilhafte Ausgestaltungen des Verfahrens sind Gegenstand der sich an den Hauptanspruch anschließenden Unteransprüche.
-
Gemäß Anspruch 1 wird ein Verfahren zur Erstellung eines Metadaten-Datenmodells für eine BI-Infrastruktur bestehend aus mehreren heterogenen operativen Quellsystemen vorgeschlagen. Das Verfahren kommt bei solchen BI-Infrastrukturen zum Einsatz, bei denen ein Data-Warehouse bzw. ein oder mehrere Datamarts mittels unterschiedlicher ETL-Prozesse aus den heterogenen operativen Quellsystemen versorgt werden. Erfindungsgemäß wird vorgeschlagen, ein unabhängiges Metadaten-Datenmodell zu generieren, um eine vollständige Übersicht über den Datenfluss der geamten BI-Infrastruktur zu erhalten, die sich nicht nur auf eine Ladestrecke beschränkt, sondern stattdessen alle verwendeten Ladestrecken abdeckt.
-
Das Metadaten-Datenmodell wird generiert, indem verfügbare Metadaten aus den Datenbank-Repositorien der operativen Quellsysteme importiert werden. Zusätzlich werden Umbauregeln der einzelnen unterschiedlichen ETL-Prozesse anhand der verwendeten DDL- und/oder DML-SQL-Statements (Data Definition Language-/Data Manipulation Language-Structured Query Language Befehle) rekonstruiert, um ein eigenständiges relationales Metadaten-Datenmodell zu erhalten.
-
Unter Metadaten werden alle Informationen zu Entitäten, vorzugsweise Tabellen, Views, und ihre Attribute mit den beschreibenden Eigenschaften, wie insbesondere Name, Format, Beschreibung, verstanden. Ferner werden als Metadaten Umbaufunktionen zwischen den verschiedenen ETL-Schichten verstanden. Die extrahierbare Quelle-Ziel-Beziehung auf Ebene der Tabellenattribute erlaubt zusätzlich die Zusammensetzung der verschiedenen ETL-Schritte zu einer Gesamtsicht über den Datenfluss in der BI-Landschaft. Die elementaren Bausteine dieser Statements und ihre Beziehungen zueinander werden bereits während des Zerlegungsprozesses im relationalen Datenmodell der Metadaten-Datenbank abgelegt.
-
Ein wesentlicher Vorteil der Erfindung ist die Unabhängigkeit der Datenhaltung im Datenmodell. Gemäß einer vorteilhaften Ausführungsform basiert das relationale Datenmodell für die genannten Metadaten auf Oracle-Basis. Ein weiterer wesentlicher Vorteil der Erfindung besteht auch darin, dass für das Laden des neuen Metadaten-Datenmodells nicht auf existierende Schnittstellen der verwendeten ETL-Tools zurückgegriffen wird, sondern relationale Zusammenhänge der resultierenden technischen Datenbank-Prozesse stattdessen durch das Zerlegen der angewendeten SQL-Statements der eingesetzten ETL-Prozesse innerhalb der BI-Infrastruktur erfolgt. Das Verfahren wird dadurch universal einsetzbar unabhängig vom konkreten Aufbau bzw. der Arbeitsweise unterschiedlichster ETL-Werkzeuge. Ein Rückgriff auf verfügbare Schnittstellen der ETL-Werkzeuge würde demgegenüber stets eine Anpassung des Verfahrens auf die jeweilige Schnittstelle notwendig machen, was insbesondere eine nachträgliche Einbindung weiterer Ladestrecken erschweren würde.
-
Gemäß einer vorteilhaften Ausgestaltung der Erfindung besteht die Möglichkeit, dass nicht nur Repositorien der operativen Quellsysteme in das Metadaten-Datenmodell importiert werden, sondern zudem ausgewählte ETL-Repositorien ergänzend an das Metadaten-Datenmodell angebunden werden. Aus diesen ETL-Repositorien können fachliche Vorgaben zu Attributabhängigkeiten ebenfalls in die unabhängige Metadaten-Datenbank importiert werden. Derartige fachliche Vorgaben können beispielsweise in Form von technischen Formaten, wie Word-, Excel-, pdf- oder sonstige Dateien vorliegen. In diesem Zusammenhang besteht die Möglichkeit, diese technischen Formate vorzugsweise durch einen zumindest teilweise automatisierten Analyseschritt zu interpretieren und die daraus gewonnenen Attributabhängigkeiten in das Datenmodell umzusetzen. Ferner besteht die Möglichkeit, technische Formate mittels peripherer Tabellen in das Datenmodell einzubinden.
-
Der Aufbau des relationalen Datenmodells kann ein stabiles Kerndatenmodell mit mehreren zentralen Tabellen umfassen. Als besonders geeignet erweist sich eine Ausgestaltung mit mindestens vier Tabellen als Metadaten-Kerndatenmodell. Die Verwendung von zentralen Tabellen als Kern des Modells dient zur Vermeidung von Redundanzen bei der Attributbeschreibung.
-
Ferner kann sich das relationale Metadaten-Datenmodell durch weitere Teildatenmodelle auszeichnen. Derartige Teildatenmodelle dienen beispielsweise zur Hinterlegung der Auswerteergebnisse von DDL- und/oder DML-SQL-Statements und/oder Auswertungsergebnissen von Word/Excel-Daten. Weiterhin kann optional ein Working-Datenmodell für die Speicherung und Historisierung neu entwickelter ETL-Objekte vorgesehen sein.
-
Durch Zerlegen der DDL/DML-SQL-Statements kann vorzugsweise eine Master-Detail-Beziehung der Bestandteile der Statements aufgebaut und in einem Mapping-Modell der Datenbank zusammengefasst werden. Vorzugsweise kann eine Umwandlung der Master-Detail-Beziehung in ein Komponentenmodell erfolgen, welches wiederum an das Kerndatenmodell der Metadaten-Datenbank angebunden ist. Damit verbunden ist in bevorzugter Weise eine Speicherung des kompletten DDL/DML-SQL-Statements und der zugehörigen Attributliste im Metadaten-Datenmodell. Dies ermöglicht eine vollständige Analyse und Auswertung einer End-to-End-Beziehung von Daten beginnend von dem jeweiligen Quelldatensystem bis hin zu den einzelnen Datamarts. Folglich lässt sich der komplette Datenfluss zwischen diesen Instanzen nachverfolgen.
-
Ferner kann es vorgesehen sein, dass ein oder mehrere Versionstabellen für eine Historisierung der Metadaten implementiert werden. Anhand dieser Versionstabellen lässt sich ebenfalls eine vollständige Abbildung des Datenflusses zwischen dem Quellsystem und Zielsystem erstellen. Ein oder mehrere Protokolltabellen dienen beispielsweise für das Aufzeichnen bzw. Logging technischer Metadaten-Prozesse.
-
Durch ein flexibles Ebenen-Konzept des Metadaten-Datenmodells kann die Integration neuer Verarbeitungsschichten, insbesondere weiterer Datamarts oder Kennzahlenreports, vereinfacht werden.
-
Das Zerlegen der SQL-Statements und deren vollständige Ablage innerhalb des Datenbankmodells vergrößert das Potenzial von weitergehenden Verarbeitungsschritten. Beispielsweise besteht die Möglichkeit, hinterlegte DDL- und/oder DML-Statements datenbankbasiert auszuwerten. Darin schließt sich eine Möglichkeit an, über eine Anwenderschnittstelle der Metadaten-Datenbank gespeicherte DDL- und/oder DML-Statements auf dem Metadaten-Datenmodell zu modifizieren. Ergeben sich beispielsweise aus einer Betrachtung des Datenflusses fehlerhafte Strukturen innerhalb der BI-Infrastruktur, so kann mithilfe des Metadaten-Datenmodells eine Korrektur des Datenflusses erfolgen, in dem gezielt hinterlegte DDL- und/oder DML-Statements modifiziert und korrigiert werden. Das generierte Metadaten-Datenmodell bietet im Entwicklerprozess eine Optimierung der BI-Infrastruktur mit herkömmlichen SQL-Mitteln.
-
Ebenfalls denkbar ist eine standardisierte und automatisierbare Generierung von allgemeinen DDL- und/oder DML-PLSQL-Skripten.
-
Um die Handhabung des generierten Metadaten-Datenbankmodells für den Anwender benutzerfreundlich zu gestalten, kann über eine Anwenderschnittstelle des Metadaten-Datenmodells eine visuelle Darstellung des anwendungsübergreifenden Datenflusses von den operativen Quellsystem bis hin zu den jeweiligen Datamarts unabhängig vom eingesetzten ETL-Prozess erfolgen.
-
Die Implementierung eines derartigen Visualisierungsmittels kann mittels Java-, SQL- und PLSQL-basierter Anwendung erfolgen. Die Visualisierung des Datenflusses ermöglicht verschiedene Varianten der Datenherkunftsanfrage (Data-Lineage Funktion) und/oder einer Wirkungsanalyse (Data Impact-Analyse) mit dynamischem Aufbau, dies gilt gleichermaßen für eine Attribut-bezogene Datenflussanzeige als auch für eine Tabellen-bezogene Datenflussanzeige. Insbesondere ermöglicht die Visualisierung eine Anzeige von Attribut-Beschreibungen und Wertausprägungen, vorzugsweise in eigenen GUI-Masken (Graphical User Interface Maske) der Anwendung. Darüber hinaus kann eine Anzeige der Transformationsregeln in einer eigenen GUI-Maske vorgesehen sein.
-
Bei einer Attribut-bezogener Herkunftsanfrage kann eine Auswahl der Start-Ebene und/oder der Start-Tabelle und/oder eines Start-Attributes erfolgen. Im Rahmen der interaktiven Verwendung lassen sich neue Startwerte mittels Markierung eines eingeblendeten Objektes eingeben. Ebenfalls denkbar ist eine Attribut-Suche über Wertausprägungen. Ferner ermöglicht die Visualisierung eine simulierte Hyperlink-Funktionalität, durch Verweis auf auf hochgeladene technische Formate bei der Anzeige von Transformationsregeln, insbesondere PDF-Dateien.
-
Bei einer tabellen-bezogenen Herkunftsanfrage wird eine Analyse mit Anzeige von allen Objekt-Abhängigkeiten erreicht. Auch hier besteht die Möglichkeit, die Start-Ebene und/oder eine Start-Tabelle auszuwählen. Im Rahmen der interaktiven Verwendung lassen sich idealerweise neue Startwerte über Markierung eines Objektes in der Graphik eingeben. Auch ist ein Wechsel in die Detailsicht für Attribut-Abhängigkeiten über Markierung eines Objektes in der Graphik denkbar.
-
Neben dem erfindungsgemäßen Verfahren betrifft die vorliegende Erfindung ebenfalls ein System zur Generierung und Visualisierung eines Metadaten-Datenmodells mit Mitteln zur Durchführung des Verfahrens gemäß der vorliegenden Erfindung. Bezüglich des Systems gelten damit dieselben Vorteile und Eigenschaften, wie sie bereits vorstehend anhand des erfindungsgemäßen Verfahrens erläutert wurden. Auf eine wiederholende Beschreibung wird aus diesem Grund verzichtet.
-
Weitere Vorteile und Eigenschaften der Erfindung sollen im nachfolgenden Teil anhand eines in den einzelnen Figuren gezeigten Ausführungsbeispiels näher erläutert werden. Es zeigen:
-
1: eine Übersicht über den geschlossenen Workflow des erfindungsgemäßen Verfahrens,
-
2: eine stark vereinfachte Darstellung einer BI-Landschaft eines großen Unternehmens,
-
3; eine Darstellung des implementierten Kern-Datenmodells des erfindungsgemäßen Metadaten-Datenmodells,
-
4: eine Darstellung der verschiedenen Import-Prozesse und Output-Formate das Metadaten-Datenmodell,
-
5: eine Darstellung des Parsing-Analyse-Datenmodells als Master-Detail-Beziehung in dem Metadaten-Datenmodell,
-
6: eine Darstellung des Parsing-Komponenten-Datenmodells der Metadaten-Lösung,
-
7: ein Screenshot der dynamisch erzeugten Visualisierung einer exemplarisch ausgewählten Attribut-bezogenen Impact-Analyse,
-
8: ein Screenshot der dynamisch erzeugten Visualisierung einer Attribut-Beschreibung incl. Wertausprägungen zu einer exemplarisch ausgewählten Attribut-bezogenen Lineage-Analyse (aufgeteilt auf die Figurendarstellungen (8(1/4)–8(4/4)),
-
9: einen Screenshot der Anwendung mit einer dynamisch erzeugten Visualisierung einer fachlichen Transformationsregel als Pseudo-Code zu einer exemplarisch ausgewählten Attribut-bezogenen Lineage-Analyse (aufgeteilt auf die Figurendarstellungen (9(1/4)–9(4/4)),
-
10: einen Screenshot der Anwendung mit dynamisch erzeugter Visualisierung eines Dokument-Verweises als Umbauregel incl. Hyperlink-Funktionalität zu einer exemplarisch ausgewählten Attribut-bezogenen Lineage-Analyse (aufgeteilt auf die Figurendarstellungen (10(1/4)–10(4/4)),
-
11: ein Screenshot der GUI-Maske für eine Bestimmung von Attribut-Namen auf Basis ausgewählter Wertausprägungen (aufgeteilt auf die Figurendarstellungen (11(1/4)–11(4/4)),
-
12: ein Screenshot der Anwendung mit dynamisch erzeugter Visualisierung einer exemplarisch ausgewählten Tabellen-bezogenen Lineage-Analyse,
-
13: einen Screenshot der Anwendung mit dynamisch erzeugter Visualisierung einer Attribut-Detailsicht zu einer exemplarisch ausgewählten Tabellen-bezogenen Herkunfts-Analyse (aufgeteilt auf die Figurendarstellungen (13(1/4)–13(4/4)),
-
14: einen Screenshot der Anwendung mit dynamisch aufgebauter Visualisierung eines exemplarisch ausgewählten SQL-DDL-Statements mit Quelle-Ziel-Markierung eines ausgewählten Ziel-Attributs (,VSB-Report'),
-
15: einen Screenshot der Editor-GUI-Maske in der Java-Metadaten-Anwendung für das SQL-Engineering (,VSB-Editor') (aufgeteilt auf die Figurendarstellungen (15(1/4)–15(4/4)) und,
-
16: eine Darstellung des Entwicklungs-Workflow für Objekte im Parser-Komponenten-Datenmodell.
-
Das erfindungsgemäße Verfahren umfasst die Erzeugung und Anwendung eines (für Anwender) offenen, relationalen Datenmodells für die fachlichen BI-Metadaten jedes Unternehmens, das über ein geeignetes Ebenen-Konzept die Integration beliebiger BI-Anwendungsgebiete ermöglicht. Die Realisierung kann auf Oracle-Basis erfolgen. Unter fachlichen Metadaten im ,Business-Intelligence'(BI)-Umfeld eines Unternehmens werden die beschreibenden Daten der Datenhaltung zusammengefasst, also Informationen zu Datenbank-Entitäten wie Tabellen oder Views, sowie die enthaltenen Datenelemente (Attribute) und Attribut-bezogenen Transformationen/Umbauregeln zwischen den verschiedenen Schichten/Ebenen des BI-Verarbeitungsprozesses. Im ,Business Intelligence'(BI)-Umfeld eines Unternehmens werden in der Regel operative Geschäftsdaten in verschiedenen Verdichtungs-Schritten (,ETL-Prozess') aufbereitet, so dass Kundenprofile erstellt und das Kundenverhalten prognostiziert werden kann (,Markt-Analyse', 'Markt-Management'). Die technische Heterogenität der operativen Quellsysteme und die Diversität der verwendeten Daten-Ladestrecken bis in die Datamart-Zielsysteme stellen dabei für jedes große Unternehmen eine Herausforderung dar, denn die Nachvollziehbarkeit des Datenflusses kann in der Regel nur solange gewährleistet werden, wie ein einheitliches ETL-Tool für die Ladestrecken verwendet wird.
-
Eine Übersicht des geschlossenen Workflows des Verfahrens ist in 1 dargestellt. Die BI-Infrastruktur ist hier mit dem Bezugszeichen 10 gekennzeichnet. Ein wesentlicher Bestandteil des Verfahrens ist die Möglichkeit, im Rahmen eines eigenen, geschlossenen Workflows die bestehende technische Realisierung der BI-Prozesse 10 unabhängig vom physikalisch genutzten ETL-Lade-Tool in ein Metadaten-Repositorium 20 zu überführen. Im Weiteren kann der Datenfluss auf Basis dieses Repositoriums 20 über die gesamte BI-Landschaft 10 hinweg visualisiert (GUI Data-Lineage) und schließlich SQL- oder PLSQL-Code auf dieser Basis in einem standardisierten Format exportiert werden. Die Flexibilität des zugrundeliegenden Metadaten-Datenmodells 20 ermöglicht zusätzlich die Überarbeitung (GUI Mapping Editor 40) der einzelnen SQL-Bausteine mit Datenbank-Mitteln und schließt damit den Kreis für die Nutzung der BI-Metadaten-Anwendung als integriertes Entwickler-Tool für die Erstellung von standardisierten DDL- und DML-Skripten 32.
-
2 zeigt die BI-Landschaft 10 im Detail inklusive der Datenströme zur Füllung des Metadaten-Datenmodells 20. Die exemplarisch dargestellte BI-Landschaft 20 ist stark vereinfacht, in der Praxis ist diese gerade bei großen Unternehmen deutlich komplexer aus einer Vielzahl unterschiedlicher Datenbanksystemen 11a–11d aufgebaut. Zur Erläuterung des erfindungsgemäßen Verfahrens ist diese vereinfachte Version jedoch ausreichend. Durch Import und Historisierung der Tabellenstrukturen aus allen beteiligten BI-Datenbank-Repositorien der Datenbanksysteme 11a, 11b, 11c, 11d wird das Metadaten-Datenmodell 20 inhaltlich gefüllt. Der Import-Prozess aus den einzelnen Repositorien ist mit dem Bezugszeichen 18 gekennzeichnet.
-
Darüber hinaus kann ebenfalls ein Import von Metadaten aus den Repositorien der Zwischenschichten 15, des Data-Warehouse 16 sowie der einzelnen Datamarts 17 erfolgen. Diese Importprozesse sind ebenfalls mit dem Bezugszeichen 18 gekennzeichnet.
-
Der gesamte Weg von den Datenquellen 11 bis hin zu den Datamarts 17 stellt die ETL-Ladestrecke dar. Die Datentransformationen 12 zwischen den einzelnen Schichten 11a–11d, 15, 16, 17 erfolgt nach unterschiedlichen Umbauregeln, die insbesondere abhängig vom eingesetzten ETL-Werkzeug sind. Durch Nutzung eines neu entwickelten SQL-Parsing-Prozesses auf Basis von Java und PLSQL, sowie durch Auswertung und Integration diverser fachlicher Beschreibungen im Word- oder Excel-Format, wird zudem ein Reverse-Engineering-Prozess ermöglicht, um die Attribut-Abhängigkeiten anhand der erfolgten Datentransformationen 12 nachvollziehen zu können. Dieser Prozess des sogenannten „Reverse-Engineerings” ist mit dem Bezugszeichen 19 gekennzeichnet.
-
Im Folgenden sollen Details der wesentlichen Komponenten des Systems bzw. des eingesetzten Verfahrens erläutert werden.
-
Relationales Metadaten-Datenmodell
-
Die Ablage der Metadaten-Informationen ist aktuell in einem relationalen Datenmodell 20 für die Attributbeschreibung auf Oracle-Basis umgesetzt. Durch Datenbank-interne Constraints auf den Metadaten-Tabellen und eigenentwickelte Abgleichs-Funktionalitäten zu den produktiven Datenbank-Repositorien wird die Sicherung der Datenqualität technisch unterstützt. Das Metadaten-Datenmodell 20 für die BI-Metadaten ist als (für Anwender) offenes und flexibles relationales Datenmodell aufgebaut, dessen Ebenen-Konzept die einfache Aufnahme neuer ETL-Verarbeitungs-Schichten erlaubt und dessen Rollenkonzept die Mandanten-Fähigkeit der Anwendung sicherstellt.
-
Eine einheitliche Schnittstelle zu den Datenbank-Repositorien der Quelldatensysteme 11a, 11b, 11c, 11d der physischen Datenverarbeitungs-Welt erlaubt eine qualitätsgesicherte Spiegelung dieser Struktur-Daten in dem Metadaten-Repositorium 20. Dieses Vorgehen ermöglicht nicht nur eine einheitliche Sicht auf die Datenbank-Strukturen der gesamten BI-Landschaft 10, sondern reduziert auch wesentlich die Laufzeit/Performance von Struktur-bezogenen Nutzer-Abfragen in den Datenbanken 11a, 11b, 11c, 11d, da hierfür anstelle auf deren Repositorien der produktiven Datenbanken 11a, 11b, 11c, 11d nur auf das Metadaten-Repositorium 20 zugegriffen werden muss.
-
Kernkomponente des Metadaten-Datenmodells 20 ist ein stabiles Kern-Datenmodell mit vier zentralen Tabellen für die Vermeidung von Redundanzen bei der Attribut-Beschreibung. Eine beispielhafte Aufteilung in vier Kern-Datenmodelle lässt sich der 3 entnehmen.
-
Das eingesetzte flexible Ebenen Konzept erleichtert die Integration neuer Verarbeitungsschichten, wie bspw. die Einbindung weiterer Datamarts 17 oder Kennzahlen-Reports. Durch die Verwendung von peripheren Tabellen lassen sich Dokument-Verweise, Import-Schnittstellen, Attribut-Wertausprägungen und ähnliche Inhalte verwalten. Die Ergebnisse („Select-Parsing-Resultate”) der ausgewerteten Transformationen 12 sowie der ausgewerteten technischen Formate wie Word/Excel werden als Teil-Datenmodelle eingebunden. Ein eingebundenes Working-Datenmodell dient zudem zur Speicherung und Historisierung neu entwickelter ETL-Objekte.
-
Das Metadaten-Datenmodell 20 erlaubt zudem Views für die Erzeugung einer einheitlichen Reporting-Sicht auf den gesamten BI-Datenfluss. Zusätzliche Versionierungs-Tabellen dienen zur Historisierung der Metadaten. Über Protokoll-Tabellen wird ein Logging technischer Metadaten-Prozesse vorgenommen.
-
Import/Befüllungs-Prozesse für BI-Metadaten
-
Eine Übersicht über den Importvorgang ist der 4 zu entnehmen. Eine große Herausforderung bei dem Aufbau einer BI-übergreifenden Datenfluss-Analyse besteht darin, die bereits im Unternehmen bestehende Dokumentation von Attribut-Abhängigkeiten über die verschiedenen Verarbeitungsschichten 11, 15, 16, 17 hinweg in das Metadaten-Datenmodell 20 zu überführen. Fachliche Vorgaben für die ETL-Verarbeitungs-Schritte 12 werden in der Regel in verschiedenen technischen Formaten wie Word, Excel oder ähnlichen Formaten zur Verfügung gestellt.
-
Für alle Import-Prozesse 18 wird eine einheitliche Datenbank-Schnittstelle im Metadaten-Datenmodell 20 genutzt (siehe 4). Der konsequente Import 18 aller Datenbank-Strukturen 22 über die produktiven Datenbank-Repositorien in das Metadaten-Repositorien 20 sichert die Datenqualität des Metadaten-Kern-Datenmodells. Die zusätzliche Anbindung ausgewählter ETL-Tool-Repositorien (z. B. Oracle-Warehouse-Builder) dient zur Dokumentation der technisch umgesetzten Attribut-Abhängigkeiten 21.
-
Gleichzeitig wird über einen technischen Prozess 19 zum Zerlegen der DDL- und DML-Statements 12, die die Weitergabe der Daten im Lade-Prozess steuern, die technische Umsetzung des Lade-Prozesses analysiert und mit allen Komponenten im Metadaten-Datenmodell 20 gespeichert (,SQL-Parsing'). Eine spätere Visualisierung der Attribut-Abhängigkeiten 21 als Ergebnis dieses Parsing-Prozesses 19 verlangt zusätzlich ein transparentes, auswertbares Datenmodell für die Parsing-Komponenten (Expressions, Joins, u. a.).
-
Die Überführung bereits bestehender fachlicher Dokumentation 23 von Attribut-Abhängigkeiten 21 in seinen diversen technischen Formaten wie Word, Excel oder aus anderen Quellen in das Metadaten-Datenmodell 20 wird in dieser Metadaten-Anwendung über einen halb-automatisierten Auslese-Prozess 24 ermöglicht. Damit wird die Möglichkeit geschaffen, die fachlichen Vorgaben 23 zu Attribut-Transformationen und die tatsächliche technische Umsetzung 12 im Lade-Prozess in einer integrierten Metadaten-Anwendung miteinander zu vergleichen und so Fehlerquellen bei der Ladung wesentlich schneller als bisher aufzuspüren.
-
Die zerlegten ausgewählten DDL/DML-SQL-Statements werden in einem VSB-Teil-Datenmodell mit der Bezeichnung VSB = V(iew)-S(elect)-B(uilder) abgespeichert. Die dabei ausgeführte kaskadierende Zerlegung der SQL-DDL/DML-Statements 12 basiert auf einer Java-basierten String-Analyse. Es wird dadurch eine Master-Detail-Beziehung für Select-Bestandteile in einem eigenen Teil-Datenmodell 30 der Metadaten aufgebaut, die wiederum in einem „VSB-Mapping” zusammengefasst wird. Ein mögliches Beispiel des Teil-Datenmodells 30 ist in 5 wiedergegeben.
-
Für die spätere Weiterverarbeitung erfolgt eine Umwandlung der Master-Detail-Beziehung in ein Komponenten-Datenmodell (VSB-Komponenten-Datenmodell 31) mit Anbindung an das Kern-Datenmodell. Siehe hierzu 6. Im Ergebnis erfolgt eine Abspeicherung des kompletten DDL/DML-Statements 12 und der zugehörigen Ziel-Attributliste im Metadaten-Datenmodell 20.
-
BI-übergreifende Datenfluss-Visualisierung
-
Durch die einheitliche Datenhaltung im Metadaten-Datenmodell 20 ist es möglich, eine graphische Darstellung des gesamten BI-Datenflusses von den operativen Quell-Systemen 11a, 11b, 11c, 11d bis zu den Reports auf Basis der Datamart-Schichten 17 anzubieten. Diese Visualisierung wird über eine mit Java-Swing-Mitteln entwickelte Anwender-Schnittstelle (GUI) 40 erreicht. Damit wird zusätzlich eine Herkunfts-Analyse (,Data-Lineage', ,Impact-Analyse') auf Tabellen- oder auf Attribut-Granularität ermöglicht, wobei verschiedene Varianten der Lineage- und Impact-Analyse mit dynamischem Aufbau existieren. Graphische Bird's-Eye-View-Komponenten sichern den Gesamt-Überblick über die Graphiken bei komplexen Abhängigkeits-Netzen. Eine interaktive Nutzung durch den Anwender ist möglich, d. h. eine Art des „Browsen” durch die Graphik wird anwendungsseitig angeboten.
-
In der graphischen Darstellung der Tabellen-bezogenen Abhängigkeiten ist zusätzlich neben verschiedenen Auswahl- und Verzweigungsmöglichkeiten innerhalb der GUI-Masken auch ein Wechsel auf die Detailsicht zu den Attribut-Abhängigkeiten möglich. Eine Attribut-bezogene Markierungs-Funktionalität gewährleistet auch bei komplexen Objekt-Abhängigkeits-Netzen eine Übersicht über den Datenfluss zu jedem Datenelement in der BI-Landschaft 10.
-
Speziell bei der Attribut-bezogenen Datenfluss-Anzeigefunktion können bei einer Attribut-bezogenen Lineage-/Impact-Analyse zusätzliche Attribut-Informationen eingeblendet werden. Als Beispiel wird auf den Screenshot der 7 verwiesen, die die Visualisierung des Datenflusses durch die Java-Anwendung zeigt. Als Ausgangswert für die Lineage- oder Impact-Analyse kann eine Start-Ebene, eine Start-Tabelle und/oder ein Start-Attributs ausgewählt werden, auf deren Basis die Visualisierung des Datenflusses erfolgt.
-
Die Anzeige von Attribut-Beschreibungen und Wertausprägungen kann aus Gründen der besseren Übersichtlichkeit in eigenen GUI-Masken der Java-Anwendung erfolgen, wie dies beispielsweise der Screenshot gemäß 8 zeigt.
-
Die Fähigkeit der graphischen Darstellung zu Interaktivität zeichnet sich dadurch aus, dass der Nutzer neue Startwerte für die Lineage-/Impact-Analyse mittels Markierung eines Objektes in der Graphik auswählen kann. Auch eine Verschiebung der Einzelobjekte in der Graphik und Rückkehr zur Start-Konfiguration ist möglich. Ebenfalls ist eine Unterdrückung technischer Objekte in der Graphik möglich.
-
Die Einblendung der jeweilig angewendeten Transformationsregeln 12 zwischen den Schichtübergängen des Datenflusses kann ebenfalls in einer eigenen GUI-Maske angezeigt werden, wie dies in 9 verdeutlich ist. 10 zeigt die Einbindung von technischen Formaten, die die Unternehmensvorgaben zum Umbau der Daten beinhalten. Hierbei wird eine simulierte Hyperlink-Funktionalität verwendet, um auf hochgeladene PDF-Dokumente im eigenen Wiki der Java-Anwendung bei der Anzeige der Transformationsregeln zu verweisen.
-
Die Java-Anwendung erlaubt zudem eine Attribut-Suche über die Wertausprägungen. Ein beispielhafter Screenshot, der diese Suchfunktionalität zeigt, ist der 11 zu entnehmen.
-
Unterschiedliche Ziel/Nutzrgruppen der Java-Anwendung benötigen unter Umständen eine unterschiedliche Detaillierungs-Tiefe in der Datenfluss-Sicht. So sind bwps. Technische Zwischenschritte im ETL-Prozess für Endanwender der Fachbereiche meist nicht wichtig/interessant. Grundsätzlich wurde deshalb eine individuelle Unterdrückung technischer Objekte bzw. technischer ETL-Schichtn in der graphischen Darstellung ermöglicht.
-
Ein Wechsel in die Vollbild-Anzeige öffnet größere GUI-Masken der Java-Anwendung und jede generierte und angezeigte Graphik lässt sich in einem bestimmten Bildformat, bspw. JPEG-Format, abspeichern.
-
Wird eine Tabellen-bezogene Datenfluss-Anzeige mit Attribut-Mapping-Detailsicht in der Java-Anwendung gewählt, stehen dem Nutzer folgende Funktionen zur Verfügung. Bei einem Aufruf einer Lineage-/Impact-Analyse erfolgt eine Anzeige von allen Objekt-Abhängigkeiten, wie dies in 12 gezeigt ist. Auch hier ist eine Auswahl einer Start-Ebene oder einer Start-Tabelle möglich. Die ebenfalls zur Verfügung stehende Benutzerinteraktivität der eingeblendeten Graphik erlaubt die Auswahl neuer Startwerte durch gezielte Markierung eines Objektes in der Graphik. Ferner kann ein Wechsel in die Detailsicht für Attribut-Abhängigkeiten über Markierung eines Objektes in der Graphik erfolgen. Genauso ist eine farbliche Markierung des Datenflusses einzelner Quell- oder Ziel-Attribute in der Detailsicht möglich (13).
-
Eine Unterdrückung technischer Objekte in der Graphik ist möglich, ebenso eine Unterdrückung technischer Ebenen in der Graphik. Die Anwendung bietet dem Nutzer ferner die Möglichkeit für einen Wechsel zu Icon-Sicht oder Schließung einzelner Attribut-Gruppen in der Detailsicht. Auch ein Wechsel zwischen Datenbank-orientierter und alphabetischer Sortierung in allen Attribut-Gruppen kann ausgeführt werden. Der Nutzer kann zudem eine Auflistung aller Quell-Attribute in der Detailsicht anfordern.
-
Aus Gründen besserer Übersichtlichkeit öffnet ein Wechsel in die Vollbild-Anzeige eine größere GUI-Maske mit allen genannten Detail-Funktionalitäten. Auch hier ist eine Abspeicherung jeder Graphik in einem Bildformat, insbesondere JPEG-Format möglich.
-
Neben den beiden zuvor beschriebenen Visualisierungsformen ermöglicht die Anwendung zudem eine Graphische Visualisierung der Select-Komponenten und Attribut-Abhängigkeiten, auch als „VSB-Reporting” bezeichnet. Folgende Merkmale/Funktionalitäten zur graphischen Visualisierung der zerlegten SQL-Objekte zeichnen die Erfindung aus:
Die Auswahl des VSB-Mappings über die Ziel-Tabelle ermöglicht die graphische Visualisierung in der Java-Anwendung. Das graphische Ergebnis wird in 14 eingeblendet. Auch hier ist eine Markierung des Datenflusses einzelner Quell- oder Ziel-Attribute in der Detailsicht und ein Wechsel zur Icon-Sicht oder Schließung einzelner Attribut-Gruppen in der Detailsicht möglich. Ferner bietet die Anwendung die Möglichkeit, zwischen Datenbank-orientierter und alphabetischer Sortierung in allen Attribut-Gruppen zu wechseln und als Erweiterung alle Quell-Attribute (incl. nicht weiter verwendeter) in der Detailsicht aufzulisten.
-
Auch bei dieser Visualisierungsform führt ein Wechsel in die Vollbild-Anzeige zum Öffnen größere GUI-Masken. Eine Speichermöglichkeit der angezeigten Graphiken in einem Bildformat wie dem JPEG-Format wird auch hier angeboten.
-
Ferner bietet die Anwendung eine Anzeige-Möglichkeit für das der Graphik zugrunde liegende DDL/DML-Statement in einer eigenen GUI-Maske an. End-to-End-Beziehungen für Quell- und Ziel-Attribute der VSB-Mappings lassen sich schließlich in die BI-übergreifende Datenfluss-Analyse einbinden.
-
Generierung von standardisierten DDL/DML-SQL-Skripten
-
Das Potential der Metadaten-Anwendung geht über QS-Prozesse der Entwicklung und das Visualisieren der Datenflüsse hinaus, da die SQL-Grund-Bausteine eines Select-Statements 12 und ihre Beziehungen zueinander bei der Zerlegung vollständig in dem relationalen Datenmodell 20 abgelegt werden. Dies erlaubt nicht nur eine flexible Analyse der Select-Strukturen über SQL-Abfragen, sondern auch eine gezielte Manipulation dieser Informationen mit Datenbank-Mitteln.
-
Durch die Flexibilität des Metadaten-Datenmodells 20 lassen sich beliebige DDL/DML-Statements für Views oder andere SQL-Datenbank-Objekte aus dem Datenmodell 20 heraus in standardisierter Form generieren. Dadurch schließt sich der Kreis für die Nutzung der BI-Metadaten-Anwendung sowohl als generelles Entwicklungs- und Metadaten-Tool, wie auch als Migrations-Tool für die Ablösung eines ETL-Umfeldes.
-
Konkret erlaubt die Anwendung eine automatisierte Erstellung standardisierter DDL/DML-Skripte 30 für Select-Statements ohne komplexe Transformationen. Im Ergebnis ermöglicht dies einen fehlerfreien Releasebau auf Basis des Metadaten-Datenmodells 20. Komplexe Views im Releasebau werden über Reverse-Engineering 19 in das Metadaten-Datenmodell 20 oder über direkte Änderungen im VSB-Datenmodell der Metadaten aktualisiert. Eine spezielle Editor-GUI-Maske der Java-Metadaten-Anwendung 40 bietet dem Nutzer die Funktion des SQL-Engineering mit graphischen Funktionalitäten und dynamischer Aktualisierung des VSB-Datenmodells (,VSB-Editor'). Diese spezielle GUI-Maske zeigt 15.
-
Für eine Versionierung des neu entwickelten VSB-Mappings zu jedem Entwickler ist ein eigener Workflow mit VSB-Working-Tabellen eingerichtet, wie dies 16 andeutet. Die Verwaltung aller VSB-Mappings incl. einer Möglichkeit zur Löschung veralteter Versionen wird in einer eigenen GUI-Maske (,VSB-Client-Manager') gemäß 17 ermöglicht.
-
Gezielte Auswertung und Manipulation im VSB-Datenmodell
-
Die Ablage aller Details zu einem zerlegten SQL-Select-Statement ermöglicht nicht nur Datenbank-basierte Auswertungen, d. h. eine SQL-Analyse mit SQL-Mitteln, sondern auch die gezielte Modifikation bzw. Manipulation der gespeicherten DDL/DML-Statements über SQL-Operationen auf dem Metadaten-Datenmodell 20. So lassen sich beispielsweise Datenbank-Hints für die Select-Statements über gruppenorientiertes SQL in den Metadaten-Tabellen einfügen.
-
Hierin verbirgt sich ein großes Potential für die beschriebene BI-Metadaten-Anwendung hinsichtlich einer einheitlichen und automatisierbaren Optimierung beliebiger SQL-Statements. So lassen sich im Prinzip bspw. stark performanceintensive Inline-Abfragen in Attribut-Expressions automatisiert in eine fachliche äquivalente Join-Variante überführen und so hinsichtlich ihrer Laufzeit wesentlich optimieren.
-
Weiterhin erlaubt diese Implementierung im Prinzip auch die Umwandlung von SQL-Select-Statements in einen vorgegebenen alternativen ,SQL-Dialekt' (z. B. von Oracle-SQL nach SAS-SQL-Syntax) und damit die gezielte Unterstützung einer Migration von DDL/DML-Skripten in eine anderes ETL-Tool.
