Transformationsflüsse werden in SAP Datasphere verwendet, um Daten aus einer oder mehreren Quellen zu laden und das transformierte Ergebnis in die Zieltabelle zu speichern. Dabei können Sie auch nur die geänderten Sätze laden und müssen nicht ständig den vollen Datensatz extrahieren. Wie die Transformationsflüsse im Detail funktionieren und welche Einschränkungen Sie beachten müssen, erfahren Sie in diesem Artikel.
Im Gegensatz zu Views, die es erlauben, verschiedene Tabellen on the fly zu kombinieren und die Ausgabe anzupassen, werden Tranformationsflüsse eingesetzt, wenn das Ergebnis auf der Datenbank persistiert werden soll und ein Delta-Mechanismus erforderlich ist. Sie funktionieren ähnlich wie Transformationen in SAP Business Warehouse, daher auch der Name.
Zur Implementierung der Transformationslogik können Sie eine benutzerfreundliche grafische Oberfläche verwenden. Falls Sie fortgeschrittenere Anforderungen umsetzen möchten, können Sie nur SQL oder SQL-Skripte für Transformationsabläufe verwenden. Wenn Sie Python einsetzen möchten, müssen Sie Datenflüsse nutzen. Als Quelle können neben lokalen Tabellen und Views, die im Space verfügbar sind, auch Open-SQL-Schemas und Remote-Tabellen, die sich in BW-Bridge-Spaces befinden, genutzt werden. Diese müssen vorher in den jeweiligen Space integriert werden.
Bemerkenswert ist die Fähigkeit, Daten im Delta-Modus laden zu können. Voraussetzung dafür ist, dass sowohl in der Quell- als auch in der Zieltabelle die Delta-Erfassung aktiviert ist. Dabei müssen Sie bereits vor der Implementierung der Tabelle entscheiden, ob die Delta-Erfassung aktiviert werden soll. Ist die Tabelle erstmal implementiert, können Sie diese Einstellung nicht mehr ändern.
Wenn die Delta-Erfassung aktiv ist, werden zwei neue Spalten zur Tabelle hinzugefügt: Change_Type vom Typ String und Change_Date vom Typ Timestamp. Diese sind nicht veränderbar. Außerdem können Sie die neuen Spalten nicht als Schlüssel definieren. Darüber hinaus rät SAP davon ab, diese Spalten in Transformationslogiken zu verwenden. Da es sich bei der Delta-Erfassungstabelle um eine interne Tabelle handelt, deren Struktur sich jederzeit ändern kann, ist sie für externen Datenzugriff nicht zulässig.
Intern sind die Spalten Change_Type und Change_Date nicht Teil der aktiven Tabelle, sondern der Tabelle für die Delta-Erfassung, die mit dem Suffix _Delta angelegt wird. Technisch gesehen handelt es sich bei der aktiven Tabelle, um einen View, der die gelöschten Werte exkludiert.
Eine Tabelle mit aktivierter Delta-Erfassung bietet im Vergleich zu normalen Tabellen einige Vorteile. So müssen bei Ladeprozessen und Transformationen nicht immer alle Daten verarbeitet werden. Die Datenmenge der prozessierten Daten wird verringert.
So können Sie bei den Einstellungen des Transformationsflusses zwischen den Ladetypen Nur Initial sowie Initial und Delta wählen. Bei der ersten Option wird der gesamte Datensatz in die Zieltabelle geladen. Bei der Option Initial und Delta wird bei der ersten Ausführung der gesamte Datensatz in die Zieltabelle transferiert. Bei den darauffolgenden Ausführungen werden nur die Delta-Änderungen in die Zieltabelle geladen.
Neben der Verringerung des Volumens erlaubt es die Delta-Erfassung auch gelöschte Datensätze zu identifizieren. Wenn ein Datensatz von einer nicht Delta-fähigen Quelltabelle in die Zieltabelle geladen wird und anschließend in der Quelle gelöscht wird, bleibt er standardmäßig in der Zieltabelle stehen. Dank des Delta-Mechanismus werden in der Quelle gelöschte Datensätze auch im Ziel gelöscht.
Allerdings gelten einige Einschränkungen, die Sie beachten müssen. So kann zurzeit nur eine Delta-fähige Tabelle als Quelle genutzt werden. Es ist nicht möglich, mehrere Delta-fähige Tabelle in einer View zu kombinieren. Es handelt sich dabei jedoch um eine häufige Anforderung bei komplexeren Data Warehousing Szenarien.
Zudem ist die Datenvorschau nur in der grafischen Ansicht oder bei SQL-Transformationen verfügbar. Wenn Sie SQL Script für Ihre Transformationslogik verwenden, ist die Datenvorschau nicht verfügbar.
Darüber hinaus können keine Views für den Delta-Mechanismus genutzt werden. Denn bei einem View stehen die Spalten Change_Type und Change_Date nicht zur Verfügung. Ein View kann in Kombination mit einer Delta-Fähigen Tabelle verwendet werden. Für einen Ladeprozess ohne Delta können auch Views als Quelle verwendet werden.
Außerdem kann die Spalte Change_Date im Rahmen des Transformationsflusses nicht in berechneten Spalten verwendet werden. Das schränkt die Modellierungsmöglichkeiten ein.
Neben den grafischen Views können auch SQL Views für Transformationen verwendet werden. Allerdings wird bei zu komplexen Kalkulationen mit Verwendung von lokalen Tabellen der Delta-Mechanismus abgeschaltet.
Transformationsflüsse decken die häufigsten Anforderungen ab und erlauben es Ihnen, Delta-Fähigkeiten zu nutzen. So können Sie SQL Logiken für Transformationen nutzen und mit Delta-Tabellen arbeiten.
Allerdings vermissen wir die Möglichkeit, Python für anspruchsvollere Transformationen zu nutzen. Darüber hinaus kann zurzeit nur eine Delta-fähige Tabelle als Quelle genutzt werden. Wir würden uns wünschen, dass in der Zukunft mehrere Tabellen mit Delta-Mechanismus verwendet werden könnten.
Darüber hinaus wünschen wir uns die Möglichkeit, einen eigenen CDC (Change Data Capture) Mechanismus einzusetzen. Im Moment können eigene Delta-Objekte in CDS Views eingesetzt werden, die anschließend als Quelle in SAP Datasphere genutzt werden können. Diese Möglichkeit fehlt momentan in SAP Datasphere.
Haben Sie Fragen zu SAP Datasphere? Versuchen Sie das nötige Know-how in Ihrer Abteilung aufzubauen oder benötigen Sie Unterstützung bei einer konkreten Fragestellung? Wir helfen Ihnen gerne dabei. Nehmen Sie einfach Kontakt zu uns auf!