Data Flow One® Engine V 3.1

© SCHUMACHER INFORMATIK AG

Data Flow One® Engine V3.1

01

Highlights• Automatische Übernahme� technischer Metadaten

• Flexibles Datenmodell

• Performance-optimiertes Metadatenmodell

• Erweiterbare Beschreibungen

• Metadaten von Liefer- applikationen und Datamarts

• Unterstützung der Datenqualitätssteigerung

Die Data Flow One® Engine ist ein ETL-Tool (Extract-, Transform-, Load-Tool) für das Laden von Daten (in der Regel aus operativen Systemen) in ein Data Warehouse und Extrahieren dieser Daten. Architektur und Ausprägung des Data Warehouse sind durch seine Funktion bestimmt, z.B. als Business Intelligence oder Operational Data Store. ��Die zum Laden und Entladen des Data Store erforderlichen Ströme, Transformationen, Abbildungen etc. werden als Metadaten definiert und von der Engine bei der Ausführung interpretiert. Das Data Flow One® Repository übernimmt die Speicherung und Auswertung der Metadaten, welche die Datenströme, Abbildungen und Prozesse des Data Warehouses beschreiben.

Data Flow One® Engine V3.1– Für eine gute Performance Data Flow One® ist eine Standardsoftware im EAI-Bereich, welche es dem Benutzer ermöglicht, auf �einfache, graphisch unterstützte Weise Data Warehouses und Datamarts aufzubauen und zu betreiben. �Data Flow One® (DFO) besteht aus zwei Komponenten: �

• Data Flow One® Engine�

• Data Flow One® Repository

Nutzen• Effiziente Datenbereitstellung für DataMart-Projekte

• Skalierbarer Einsatz

• Einfache Implementierung, Unterhalt und Ausbau

• Produktivitätssteigerung

• Kurze Lernphase für den Benutzer

© SCHUMACHER INFORMATIK AG

Abb.1Architektur Data Flow One® Engine am Beispiel eines OS/390 Data Warehouses

SchnittstelleSchnittstelle

DataMart Operative Systeme(Lieferapplikationen)

DFO Engine Client

Data Flow Metadaten

DFOEngineServer

DFOEngineServer

DSDataStore

Batch-/Ablaufsteuerung

Monitoring

OS/390

Technische Metadaten

Business InformationDFO Repository

FrontendData Modelling

Tools

Data Flow One® Engine V3.1

Abb.1 zeigt die Architektur eines DataWarehouses, welches durch die DFO Engine betrieben wird. Im Zentrum steht ein zentraler Data Store, dessen Aufbau durch ein unternehmensweites Daten-modell bestimmt wird. Unter-scheidet sich dieses erheblich von den Datenmodellen der Liefer-applikationen und Datamarts, gestalten sich die Lade- und Extraktprozesse sehr komplex.�Die Engine bietet die volle für Laden und Extrahieren erforder-liche Funktionalität. Insbesondere können beim Extrahieren beliebig komplexe Joins und Selektionen aus dem Data Store vorge-nommen werden.

Die von der Engine durchzu-führenden Abbildungen werden als Data Flow Metadaten

vorgegeben, wobei hierzu als Frontend der DFO Engine Client verwendet wird. Die Data Flow Metadaten werden vom DFO Engine Server zur Laufzeit inter-pretiert.

Die Data Flow Metadaten, die mittels der graphischen Ober-fläche des Clients generiert werden, sind in einer leicht lesbaren Sprache formuliert. Damit sind sie sehr kompakt und können beispielsweise für Analysezwecke per Email versandt werden.

Die Lade- und Extraktströme können als Batchverarbeitungen in die Tagesendverarbeitung integriert werden, indem logische und applikatorische Abhängig-

keiten für die Verarbeitung festgelegt werden.

Relevante Informationen über ausgeführte Verarbeitungen (Start und Ende, verbrauchte Ressourcen, Kennzahlen über Mengen, Return Codes) werden in Tabellen abgelegt und historisiert. Die Aufbereitung dieser Daten erfolgt über Funktionen des Repository.

Die Engine bietet formale und inhaltliche Überprüfungen von Feldinhalten der Schnittstellen-dateien als Funktion an. Warnungen und detaillierte Fehlermeldungen werden ebenfalls in Tabellen abgelegt.

02

© SCHUMACHER INFORMATIK AG

Data Flow One® Engine V3.1

03

Data Flow Computer Architekturals zugrundeliegendes Paradigma

Gemäss der Data Flow �Computer Architektur werden �die Abbildungen der Lade- und Extraktionsprozesse in zwei Verarbeitungsebenen zerlegt:

• Die Verarbeitung der Daten (z.B. Durchführen einer Transformation) erfolgt in speziell dafür programmierten Einheiten, „Processing Elements“.

• Der andere Teil der Verarbeitung besteht in der Verteilung und Weitergabe der Daten, „Routing“.

Die Engine umfasst die Implementierung einer wachsenden Zahl von Processing Elements, die jeweils für klar definierte und abgegrenzte Aufgaben entworfen wurden. Die Verbindung dieser Elemente erfolgt durch Warteschlangen, „Queues“. Bearbeitete Records werden von den Processing Elements in die vorgesehenen Queues gestellt. Die Processing Elements fangen an zu arbeiten, sowie Daten in den Eingabe-Warteschlangen bereit stehen.

Jedes Processing Element kann unabhängig von andern arbeiten. Die Vollständigkeit der bereit gestellten Daten ist die einzige

Voraussetzung für Processing Elements. Die Data Flow Computer Architektur braucht keine zentrale Steuerung: jedes Processing Element wird gestartet und wartet auf zu bearbeitende Daten, bis ein Signal „Datenende“ kommt.

Bei der Programmierung der Engine wird daher als Erstes eine Zerlegung des Abbildungs-prozesses in einzelne Schritte vorgenommen. Damit wird ein Graph definiert, dessen Knoten Processing Elements identifi-zieren. Kanten zwischen zwei Knoten werden als Warte-schlangen realisiert.

Der Graph mit den Processing Elements wird auf einer graphischen Oberfläche mit Mausklick festgelegt. In einem zweiten Schritt erfolgt die Parametrisierung der aktiven (Processing Elements) und passiven Elemente (Queues) durch die Definition von Objekten wie Strukturen, Transformationsregeln, SQL Statements, Filterregeln, Aggregationsregeln etc.

Der Client erzeugt aus den so definierten Elementen die Data Flow Metadaten und stellt sie für die Ausführung bereit.

Abb. 2 Beispiel eines Flows: Read, Transformation, Write.

Am linken Rand sind die Icons aller verfügbaren Processing Elements aufgelistet. Diese werden per Mausklick ausgewählt und auf der graphischen Oberfläche platziert und �mit anderen Elementen verbunden.

© SCHUMACHER INFORMATIK AG

Data Flow One® Engine V3.1

04

Funktionalität derProcessing Elemente

• Read aus sequentieller Datei: Der Aufbau der zu lesenden Datenrecords kann im einfachsten Fall von fest vorgegebener Struktur sein. Der Aufbau der einzelnen Records kann jedoch auch variieren und gemäss vorgegebenen Regeln interpretiert werden.

• Write in sequentielle Datei

• Select Rows aus Datenbank

• Insert Rows in Datenbank

• Delete Rows aus Datenbank

• Transformation von Daten

Die Werte der Ausgabefelder werden als Funktion der Eingabefelder definiert.

Es sind praktisch beliebig komplexe Ausdrücke zulässig.

• Filtern von Daten nach formalen und inhaltlichen Kriterien

• Delta Detection zwischen verschiedenen Generationen von Datenrecords

• Split/Separate von Records

• Merge/Recombine von Records

• Validierung von Daten

• Aggregation von Daten:�Mit dem Aggregations Process Element können bestimmte Aggregationsfunktionen ausgeführt werden (Zählen, Summen- und Durchschnitts-bildung, Minimum/ Maximum) und bei „Gruppenwechseln“ aggregierte Records erzeugt und zur Weiterverarbeitung bereitgestellt werden. Es können dabei mehrere, hierarchisch geordnete Aggregationen ausgeführt werden.

Abb. 3 zeigt den ClientEditor für die Parametrisierung von Transformations �Processing Elements.

© SCHUMACHER INFORMATIK AG

Data Flow One® Engine V3.1

05

Komplexe Funktionen

Überall wo logische, numerische oder Character Ausdrücke auftreten, können neben einer Vielzahl vordefinierter Funktionen auch komplexe Funktionen verwendet werden. Komplexe Funktionen benötigen eine Parametrisierung. Beispiele für komplexe Funktionen sind Table Lookups, prozedurale Abläufe von SQL Statement und speicherresidente Abbildungen.

Delta Verarbeitung

Die Engine enthält als Feature eine sehr effiziente Delta

Detection, mit der es möglich ist, zwei Generationen eines DataSets auf Änderungen, Hinzufügungen und Löschungen von Records hin zu untersuchen. Damit können die Datamarts entweder mit dem vollen Datenumfang oder lediglich mit Deltas versorgt werden.

Das Delta Processing Element verarbeitet über zwei Eingabe Queues zwei geordnete Ströme von Datenrecords gleicher Struktur und vergleicht deren Inhalt. Das Processing Element gibt nur die Records weiter, die in

wenigstens einem der fest-gelegten Felder Änderungen erfahren haben. Die Information, welche Felder sich geändert haben, wird festgehalten und kann später in der weiteren Verarbeitung verwendet werden. Ferner werden Records weiter-gegeben und markiert, die neu hinzugekommen sind oder gelöscht wurden.

Abb.4 zeigt einen Flow, in dem ein Datenstrom aus dem Data Store extrahiert und mit dem des Vortages verglichen wird. Der aktuell gültige Datenstrom wird für den Vergleich am nächsten Tag in einer sequentiellen Datei gespeichert.

© SCHUMACHER INFORMATIK AG

Data Flow One® Engine V3.1

06

Künstliche Schlüsselund Object Identifier

Die Vorteile, künstliche Schlüssel anstelle von natürlichen Schlüsseln zu verwenden, sind allgemein anerkannt. Für die Realisierung werden gewöhnlich Integerwerte als künstliche Schlüssel vorgeschlagen, wobei die äquivalenten natürlichen Schlüssel in Lookup-Tabellen abgelegt werden. ��Die Engine bietet zur Generierung von künstlichen Schlüsseln eine Methode an, die vollständig auf die Verwendung von Lookup-Tabellen verzichtet. Als künstliche Schlüssel werden eindeutige 160 Bits umfassende Strings aus den natürlichen Schlüsseln heraus generiert, die auch als unternehmensweit eindeutige Object Identifier verwendet werden können.

Plattformen

• Implementierung für OS/390,

AIX, LINUX und Windows.

• Optimiert für Ausführung auf OS/390.

• Für relationale Datenbank DB2.

Hinweise zu Marken

Microsoft, Windows und Windows NT sind eingetragene Marken oder Marken der Microsoft Corporation in den USA und anderen Ländern.

IBM, AIX, DB2, MQ und OS/390 sind ein-getragene Marken oder Marken von IBM.

Wiederverwendbarkeit

�Objekte, die definiert sind, können in weiteren Flows verwendet werden. Hierzu genügt eine Referenz auf das Objekt (z.B. auf eine Struktur, eine Abbildungsregel, ein SQL Statement). Die Auflösung von Referenzen zu Objekten, die nicht lokal definiert sind, erfolgt automatisch durch die Engine. Es empfiehlt sich, diese Auflösung nicht erst in produktiven Läufen, sondern in einem vorgezogenen Schritt auszuführen.

�Abb. 6 zeigt einen speziellen Editor des Engine Client, mit dem eine Übersicht aller definierten und zugreifbaren Objekte ermöglicht wird.

Batch- und Realtime Verarbeitung

Im Allgemeinen wird die DFO Engine in Batchverarbeitungen innerhalb der Tagesendver-arbeitung eingesetzt. Hierbei �sind ein- und ausgabeseitig die Schnittstellen entweder sequentielle Dateien oder relationale Datenbanken.��Der Einsatz der Engine in Realtime-Umgebungen und deren Einbindung in MQ Series Netzwerke ist geplant. Dabei werden anstelle von Read Processing Elements und Write Processing Elements die noch zu schaffenden MQ Get Processing Elements und MQ Put Processing Elements verwendet.

Abb. 6 Tree View des Client: Übersicht aller definierten Objekte

© SCHUMACHER INFORMATIK AG

Data Flow One® Engine V3.1

07

Schumacher Informatik AG�Burgklinge 15�D-70839 Gerlingen��Tel. +(49)-7156-270520�Fax +(49)-7156-270521�info@schumacher-informatik.de

Service- & VertriebspartnerSoftwaretechnik undInformationsmanagement -stim- GmbHAnsprechpartnerHerr Peter Bauer Beelitzer Strasse 127D-14797 Kloster LehninGERMANY Email   : Peter.Bauer@stim.deTelefon : +49 (0) 3382-701775Fax      : +49 (0) 3382-702958