Optimale Zeitabhängigkeit in SAP HANA SQL Data Warehouses: SV und ATT im Detail

Im Bereich der Data Warehouses (DWH) gehört die Unterstützung der Zeitabhängigkeit für Stammdaten oft zu den fundamentalen funktionalen Anforderungen. Stellen Sie sich vor, ein Vertriebsleiter wechselt im Laufe der Zeit seinen Wohnort. Gemäß dem DWH-Datenmodell ist die Stadt ein Attribut des Vertriebsleiters. Es ist unerlässlich, nachvollziehen zu können, welcher Stadt der Vertriebsleiter zu einem bestimmten Datum zugeordnet war. In solchen Fällen muss die Stadt ein zeitabhängiges Attribut des Vertriebsleiters sein.

Wer ein DWH mit SAP BW aufbauen möchte, muss sich darüber keine Gedanken machen. SAP BW bietet umfassende und bewährte Unterstützung für zeitabhängige Stammdaten “out-of-the-box”. Doch wie verhält es sich, wenn Sie ein SAP HANA SQL Data Warehouse aufbauen möchten? Unterstützt SAP HANA zeitabhängige Szenarien wie in SAP BW?

Die klare Antwort lautet: Ja. Und in diesem Bereich bietet SAP HANA sogar noch wesentlich mehr als SAP BW. In diesem Artikel tauchen wir tief in die Möglichkeiten der Sap Sv Hana ein, um Datenversionierung und Zeithistorisierung zu managen.

Alle Beispiele in diesem Blogbeitrag wurden in der SAP HANA 2.0 SP04 Express Edition erstellt. Für die Definition der Tabellen (Entitäten), das Befüllen mit Beispieldaten und die Ausführung von Abfragen verwende ich die SAP Web IDE für SAP HANA. Im Folgenden betrachten wir zwei zentrale Szenarien:

Systemversionierung (SV): HANA registriert den Zeitstempel (definiert vom HANA-Server) der Datenänderung in einer HANA-Tabelle. Der Benutzer hat die Möglichkeit, den Zustand der Daten in der HANA-Tabelle zu jedem beliebigen, in der Vergangenheit definierten Zeitstempel einzusehen.
Anwendungszeitreisen (ATT): HANA registriert den Zeitpunkt (Datum oder Zeitstempel, definiert von der Anwendung) der Datenänderung in einer HANA-Tabelle. Der Benutzer hat die Möglichkeit, zu jedem beliebigen Zeitpunkt (Datum oder Zeitstempel) in der Vergangenheit zu sehen, welche Daten von der Anwendung geändert wurden.

Lassen Sie uns mit dem Szenario der Systemversionierung (SV) beginnen, das für die Verwaltung von Datenänderungen auf Systemebene unerlässlich ist. Es ist wichtig, eine robuste Grundlage für die Datenverwaltung zu haben, die auch die komplexen Anforderungen moderner c4 sap Architekturen unterstützen kann.

Szenario 1: Systemversionierung (SV) in SAP HANA

Die Systemversionierung ist eine leistungsstarke Funktion in SAP HANA, die es ermöglicht, automatisch eine Historie von Datenänderungen aufzuzeichnen. Das System verwaltet dabei die Zeitstempel, wann Daten geändert wurden, sodass jederzeit frühere Zustände wiederhergestellt oder eingesehen werden können.

Für die Implementierung erstellen wir eine .hdbcds-Datei mit zwei Entitäten: info (dies ist die primäre Entität) und info_hist (dies ist die verknüpfte Entität zur Speicherung der Systemversionen der Daten aus der primären Entität). Bitte beachten Sie, dass die primäre Entität die folgenden Kriterien erfüllen muss:

Sie muss einen Primärschlüssel besitzen.
Sie muss zwei Spalten vom Datentyp UTCTimestamp (nicht null) enthalten, um die SV-Funktionalität zu unterstützen.

Im Folgenden sehen Sie die Datei manager.hdbcds, die diese Entitäten definiert:

namespace cvodata.db.tt;

context manager {
  entity info {
    key Id : Integer not null;
    surname : String(100);
    city : String(51);
    revenue : Integer;
    TidFrom : LocalDate not null;
    TidTo : LocalDate not null;
    SysValidFrom : UTCTimestamp not null;
    SysValidTo : UTCTimestamp not null;
  };

  entity info_hist {
    Id : Integer not null;
    surname : String(100);
    city : String(51);
    revenue : Integer;
    TidFrom : LocalDate not null;
    TidTo : LocalDate not null;
    SysValidFrom : UTCTimestamp not null;
    SysValidTo : UTCTimestamp not null;
  };
};

Anschließend müssen wir die Verbindung zwischen den Entitäten info und info_hist definieren. Hierfür verwenden wir die Datei manager.hdbsystemversioning. Diese Konfigurationsdatei teilt SAP HANA mit, welche Tabelle systemversioniert werden soll und welche Tabelle als Historientabelle dient.

SYSTEM VERSIONING "cvodata.db.tt::manager.info"("SysValidFrom", "SysValidTo") HISTORY TABLE "cvodata.db.tt::manager.info_hist" NOT VALIDATED

Praktische Beispiele zur Systemversionierung

Um die Funktionalität zu demonstrieren, löschen wir zunächst eventuell vorhandene Datensätze und fügen dann Beispieldatensätze in die primäre Entität info ein.

DELETE FROM "CVODATA_HDI_DB"."cvodata.db.tt::manager.info";
DELETE FROM "CVODATA_HDI_DB"."cvodata.db.tt::manager.info_hist";

INSERT INTO "CVODATA_HDI_DB"."cvodata.db.tt::manager.info" VALUES(
  1, 'Smith', 'Moscow', 100, TO_DATE('2000-01-01','YYYY-MM-DD'), TO_DATE('9999-12-31','YYYY-MM-DD')
);

INSERT INTO "CVODATA_HDI_DB"."cvodata.db.tt::manager.info" VALUES(
  2, 'Ivanov', 'Pskov', 10, TO_DATE('2000-01-01','YYYY-MM-DD'), TO_DATE('9999-12-31','YYYY-MM-DD')
);

Ein einfacher SELECT-Befehl zeigt uns den aktuellen Zustand der Daten in der Tabelle manager.info:

SELECT * FROM "CVODATA_HDI_DB"."cvodata.db.tt::manager.info" ORDER BY "Id" ASC;

Initialdaten in der SAP HANA Info-Tabelle

Nun aktualisieren wir die Stadt für den Datensatz mit der Id = 2.

UPDATE "CVODATA_HDI_DB"."cvodata.db.tt::manager.info" SET "city" = 'Sankt Petersburg' WHERE "Id" = 2;

Nach der Aktualisierung überprüfen wir die aktuellen Daten in der Tabelle. Wir sehen, dass die zweite Zeile aktualisiert wurde. Die Felder city und SysValidFrom haben ihre Werte geändert, wobei SysValidFrom den Zeitstempel der aktuellen Systemänderung anzeigt.

Weiterlesen >> Adobe Illustrator CC 2018: Das Skalierungswerkzeug und der fehlende Begrenzungsrahmen

Anzeige der aktualisierten Daten in der info-Tabelle nach der Änderung der Stadt für ID 2, inklusive des neuen SysValidFrom-Zeitstempels.

Um Daten für einen Zeitpunkt vor der Ausführung des UPDATEs auf ‘Sankt Petersburg’ abzurufen, verwenden wir SELECT mit FOR SYSTEM_TIME AS OF. Dieser Befehl ist entscheidend, um die Historie über die sap sv hana zu navigieren.

SELECT * FROM "CVODATA_HDI_DB"."cvodata.db.tt::manager.info" FOR SYSTEM_TIME AS OF '2020-02-24 11:39:27.077257300' ORDER BY "Id" ASC, "SysValidFrom" ASC;

Diese Abfrage gibt die Daten zu dem definierten Zeitpunkt in der Vergangenheit zurück. Die zugehörige Historientabelle wird intern dafür verwendet; wir fragen die Historientabelle nicht direkt ab.

Ergebnis einer FOR SYSTEM_TIME AS OF-Abfrage, die den Zustand der Daten vor dem letzten Update zeigt.

Wenn wir die Abfrage für einen Zeitpunkt in der fernen Vergangenheit ausführen, zum Beispiel als die primäre Entität noch leer war:

SELECT * FROM "CVODATA_HDI_DB"."cvodata.db.tt::manager.info" FOR SYSTEM_TIME AS OF '2019-02-24 11:39:27.077257300' ORDER BY "Id" ASC, "SysValidFrom" ASC;

Erhalten wir eine leere Ergebnismenge, da die primäre Entität am 24.02.2019 leer war.

Das System gibt keine Daten zurück, da die Tabelle zum angegebenen sehr frühen Zeitpunkt noch nicht existierte oder leer war.

Eine ähnliche SELECT-Abfrage mit FOR SYSTEM_TIME FROM … TO gibt alle Daten zurück, die für den ausgewählten Zeitraum relevant sind. Dies ermöglicht eine detaillierte Analyse der Datenentwicklung über eine bestimmte Periode.

SELECT * FROM "CVODATA_HDI_DB"."cvodata.db.tt::manager.info" FOR SYSTEM_TIME FROM '2020-02-24 11:39:27.077257300' TO '2020-02-24 13:10:12.739263800' ORDER BY "Id" ASC, "SysValidFrom" ASC;

Abfrage von Daten über einen Zeitbereich in SAP HANA

So funktioniert die Systemversionierung (SV). Die Implementierung von stabilen Systemversionierungsprozessen kann auch die Grundlage für erweiterte Sicherheitsfunktionen bilden, die beispielsweise mit [sap su24](https://shocknaue.com/sap-su24/) oder anderen Autorisierungsobjekten in SAP verknüpft sind, um sicherzustellen, dass nur berechtigte Benutzer auf historische Daten zugreifen können.

Wichtige Hinweise zur Systemversionierung

Hier sind einige wichtige Punkte bezüglich der primären und der systemversionierten (Historien-)Entitäten:

Wenn Sie denselben Update-Befehl (z.B. für “Id” = 2) zweimal ausführen, fügt HANA zwei Datensätze in die SV-Entität ein. Sie können nacheinander Einfüge-, Aktualisierungs- und Löschvorgänge ausführen und den Datensatz erneut einfügen; die SV-Entität enthält dann Datensätze für alle entsprechenden Änderungen (außer für den ursprünglichen Einfügevorgang).
Sie können jederzeit Daten aus der SV-Entität löschen.
Wenn Sie einen Datensatz aus der primären Entität löschen, wird ein neuer Datensatz in der SV-Entität erstellt, der den Zustand vor der Löschung festhält.
Es gibt keine Informationen in der SV-Entität darüber, was genau sich gegenüber dem vorherigen Zustand geändert hat. Die SV-Entität enthält lediglich die Werte kurz vor den Änderungen. Daher erstellt ein Einfügevorgang keinen Datensatz in der SV-Entität.
Es ist möglich, Spalten zu beiden Entitäten in einem einzigen Build-Vorgang hinzuzufügen, selbst wenn beide Entitäten bereits Zeilen enthalten.
Es ist möglich, den Datentyp von Spalten in beiden Entitäten in einem einzigen Build-Vorgang zu ändern (sofern die Entitäten Zeilen enthalten, sind nicht alle Datentypänderungen erlaubt).
Es ist möglich, (Nicht-PK- und Nicht-System-Datums-) Spalten aus beiden Entitäten zu entfernen, selbst wenn die Entitäten Zeilen enthalten.

Weiterlesen >> SOLIDWORKS auf Mac M2: Geht das wirklich? Die umfassende Anleitung

Nicht unterstützte Funktionen für Systemversionierung

Folgende Funktionen werden derzeit nicht unterstützt:

Einfügen oder Aktualisieren in die SV-Entität: (aber solange die Entität nicht als SV betrachtet wird, könnte sie eingefügt/aktualisiert werden).
Die SV-Entität muss leer sein, wenn die Option VALIDATED in hdbsystemversioning definiert ist. Wenn die Option NOT VALIDATED definiert ist, darf die SV-Entität während des Builds von .hdbsystemversioning Datensätze enthalten.
SV-Entität und primäre Entität dürfen keine unterschiedliche Anzahl von Spalten haben.
SV-Entität und primäre Entität dürfen keine Spalte mit demselben Namen, aber unterschiedlichem Typ oder unterschiedlicher Länge haben.

Szenario 2: Anwendungszeitreisen (ATT) in SAP HANA

Das Szenario der Anwendungszeitreisen (ATT) bietet eine andere Perspektive auf die Verwaltung zeitabhängiger Daten, indem es der Anwendung die Kontrolle über die Gültigkeitszeiträume überlässt. Im Gegensatz zur Systemversionierung, bei der der HANA-Server die Zeitstempel verwaltet, definiert hier die Anwendung die Zeitpunkte von Änderungen. Dies ist besonders nützlich für Geschäftsszenarien, in denen die Gültigkeit von Daten über bestimmte Anwendungszeiträume gesteuert werden muss, beispielsweise bei der Verwaltung von Assets mit sap sam oder in der Logistik, wie bei der sap lagerverwaltung.

Für dieses Szenario verwenden wir die primäre Entität aus dem SV-Szenario, jedoch mit einigen Anpassungen und den gleichen Anfangsdaten, aber mit folgenden Unterschieden:

Eine separate info_hist-Entität ist für ATT nicht erforderlich. Es wird nur die primäre Entität benötigt.
Die primäre Entität muss zwei Felder (vom Typ Datum/Datum-Uhrzeit) für den Gültigkeitszeitraum enthalten.
Der Primärschlüssel muss eines der Datumsfelder enthalten, das den Gültigkeitszeitraum definiert.
Eine Konfigurationsdatei .hdbapplicationtime ist zwingend erforderlich.
Die Konfigurationsdatei .hdbsystemversioning wird für ATT nicht benötigt.

Hier ist die aktualisierte Definition der Entität info in der Datei manager.hdbcds für das ATT-Szenario:

namespace cvodata.db.tt;

context manager {
  entity info {
    key Id : Integer not null;
    surname : String(100);
    city : String(51);
    revenue : Integer;
    key TidFrom : LocalDate not null;
    TidTo : LocalDate not null;
  };
}

Die Datei manager.hdbapplicationtime definiert die Felder TidFrom und TidTo, die den Gültigkeitszeitraum (aus Anwendungsperspektive) für einen bestimmten Datensatz definieren. Dies ist der Kern der Funktionalität für sap sv hana im Kontext der Anwendungszeitreisen.

APPLICATION TIME "cvodata.db.tt::manager.info"("TidFrom", "TidTo")

Laden der Initialdaten für ATT

Wir laden die Initialdaten in die primäre Entität info wie folgt:

DELETE FROM "CVODATA_HDI_DB"."cvodata.db.tt::manager.info";

INSERT INTO "CVODATA_HDI_DB"."cvodata.db.tt::manager.info" VALUES(
  1, 'Smith', 'Moscow', 100, TO_DATE('2000-01-01','YYYY-MM-DD'), TO_DATE('9999-12-31','YYYY-MM-DD')
);

INSERT INTO "CVODATA_HDI_DB"."cvodata.db.tt::manager.info" VALUES(
  2, 'Ivanov', 'Pskov', 10, TO_DATE('2000-01-01','YYYY-MM-DD'), TO_DATE('9999-12-31','YYYY-MM-DD')
);

Eine übliche SELECT-Abfrage zeigt uns den ursprünglichen Datenbestand:

SELECT * FROM "CVODATA_HDI_DB"."cvodata.db.tt::manager.info" ORDER BY "Id" ASC, "TidFrom" ASC;

Der initiale Datenbestand in der info-Tabelle vor den Anwendungszeitreisen-Updates.

Aktualisierung mit `FOR PORTION OF APPLICATION_TIME`

Jetzt aktualisieren wir das Attribut city für Id = 2 mit der folgenden Abfrage. Hierbei verwenden wir FOR PORTION OF APPLICATION_TIME, um eine spezifische Gültigkeitsperiode für die Änderung zu definieren.

UPDATE "CVODATA_HDI_DB"."cvodata.db.tt::manager.info" FOR PORTION OF APPLICATION_TIME FROM '2015-08-20' TO '2015-12-31' SET "city" = 'Hamburg' WHERE "Id" = 2;

Das Ergebnis dieser Abfrage ist beeindruckend:

Ergebnis des ersten ATT Updates in SAP HANA

Sie sehen, dass HANA die Zeile “Id” = 2 und “city” = Pskov (automatisch) aufgeteilt und eine Zeile mit derselben “Id” und “city” = Hamburg hinzugefügt hat. Der Gültigkeitszeitraum wurde entsprechend angepasst.

Hier ist ein weiteres Beispiel für die Aufteilung der Zeile “Id” = 2:

UPDATE "CVODATA_HDI_DB"."cvodata.db.tt::manager.info" FOR PORTION OF APPLICATION_TIME FROM '2015-10-20' TO '2015-12-31' SET "city" = 'Amsterdam' WHERE "Id" = 2;

Und wir erhalten:

Ergebnis des zweiten ATT Updates in SAP HANA

Abfragen mit `FOR APPLICATION_TIME AS OF`

Nun überprüfen wir die Daten, die zum 20.11.2016 gültig sind. Wir verwenden hierfür FOR APPLICATION_TIME AS OF.

SELECT * FROM "CVODATA_HDI_DB"."cvodata.db.tt::manager.info" FOR APPLICATION_TIME AS OF '2016-11-20';

Und wir erhalten:

Die Abfrage liefert die Datensätze, die zum 20.11.2016 gültig waren, basierend auf den von der Anwendung definierten Gültigkeitszeiträumen.

… welche zum 20.11.2015 gültig sind:

SELECT * FROM "CVODATA_HDI_DB"."cvodata.db.tt::manager.info" FOR APPLICATION_TIME AS OF '2015-11-20';

Und wir erhalten:

Weiterlesen >> Bitdefender Auto-Renewal: So funktioniert der digitale Fluss und wie Sie ihn steuern

Das Ergebnis zeigt die Datenversionen, die am 20.11.2015 gültig waren und die verschiedenen Städtezuordnungen für ID 2 widerspiegeln.

… welche zum 20.11.1999 gültig sind:

Wir erhalten eine leere Ergebnismenge, da die Daten erst ab 2000 gültig sind.

Eine Abfrage für einen Zeitpunkt vor der Gültigkeit der Daten liefert erwartungsgemäß kein Ergebnis.

Wichtige Hinweise zu Anwendungszeitreisen (ATT)

Hier sind einige Punkte bezüglich ATT:

Wenn Sie UPDATE ohne FOR PORTION OF APPLICATION_TIME verwenden, werden lediglich alle Zeilen aktualisiert, die durch die WHERE-Klausel (falls definiert) eingeschränkt sind. Es findet keine Aufteilung oder automatische Historisierung statt.
Sie können in einer Entität sowohl Systemversionierung (SV) als auch Anwendungszeitreisen (ATT) kombinieren. Dies bietet maximale Flexibilität für komplexe Historisierungsanforderungen.
In meinem Beispiel habe ich den Typ LocalDate für die Gültigkeitszeitraumfelder verwendet. ATT unterstützt jedoch auch DATETIME-Felder. Dies ist ein entscheidender Unterschied zu SAP BW, das für dasselbe Szenario nur den Datentyp DATE unterstützt.
Das Hinzufügen/Entfernen von Spalten ist für ATT-Entitäten sowohl mit Daten als auch bei leeren Entitäten möglich.

Allgemeine Einschränkungen für beide Szenarien in SAP HANA SQL DWH

Obwohl SAP HANA mächtige Funktionen für die Zeitabhängigkeit von Daten bietet, gibt es auch einige Einschränkungen, die bei der Implementierung beachtet werden müssen, insbesondere im Zusammenhang mit der Integration in andere Entwicklungstools und -konzepte. Die Infrastruktur, auf der SAP HANA läuft, wie z.B. suse sap für geschäftskritische Anwendungen, muss ebenfalls stabil und optimal konfiguriert sein, um diese komplexen Funktionen effizient zu unterstützen.

Erweiterte SQL DML-Syntax in Flowgraphs: Die erweiterte SQL DML-Syntax (z.B. UPDATE ... FOR PORTION OF APPLICATION_TIME FROM ...) wird (noch) nicht direkt in Flowgraphs unterstützt. Sie müssen eine Stored Procedure mit dem entsprechenden SQL DML erstellen, um diese Operationen auszuführen.
Erweiterte SQL-SELECT-Syntax in HANA Calculation Views (Graph-Modus): Die erweiterte SQL-SELECT-Syntax für SV und ATT (z.B. FOR SYSTEM_TIME AS OF und/oder FOR APPLICATION_TIME AS OF) wird (noch) nicht im Graph-Modus von HANA Calculation Views unterstützt. Sie müssen stattdessen eine Tabellenfunktion mit den entsprechenden SELECT-Abfragen als Datenbasis für Ihre Calculation Views erstellen.

Diese Einschränkungen erfordern ein gewisses Umdenken bei der Designentscheidung und der Implementierung von Datenflüssen und -modellen, insbesondere wenn man die volle Leistungsfähigkeit von sap sv hana nutzen möchte.

Fazit: Die Stärke der Zeitabhängigkeit in SAP HANA

Die Fähigkeit, Daten über die Zeit hinweg nachzuverfolgen und zu analysieren, ist für moderne Data Warehouses von unschätzbarem Wert. SAP HANA beweist mit der Systemversionierung (SV) und den Anwendungszeitreisen (ATT) nicht nur, dass es die bewährten Funktionen von SAP BW im Bereich der zeitabhängigen Stammdaten vollumfänglich unterstützt, sondern diese sogar übertrifft.

Durch die detaillierte Darstellung der beiden Szenarien haben wir gesehen, wie flexibel und leistungsstark SAP HANA bei der Handhabung historischer Daten ist. Ob es sich um systemgenerierte Zeitstempel für Audit-Zwecke handelt oder um anwendungsdefinierte Gültigkeitszeiträume für komplexe Geschäftsprozesse – sap sv hana bietet die notwendigen Werkzeuge, um diese Anforderungen präzise und effizient zu erfüllen. Die Möglichkeit, SV und ATT in einer Entität zu kombinieren, eröffnet zudem neue Dimensionen der Datenmodellierung.

Auch wenn es noch kleinere Einschränkungen bei der Integration mit bestimmten Entwicklungstools gibt, sind die gebotenen Funktionalitäten ein klares Zeichen für die Überlegenheit von SAP HANA in diesem Bereich. Für Unternehmen, die ein leistungsstarkes und zukunftssicheres DWH aufbauen möchten, ist SAP HANA eine exzellente Wahl, um die Herausforderung der zeitabhängigen Datenverwaltung zu meistern und einen tiefen Einblick in die Entwicklung ihrer Geschäftsinformationen zu gewinnen.

Wir hoffen, dieser detaillierte Einblick in die Zeitabhängigkeit in SAP HANA war aufschlussreich. Ihr Feedback ist uns sehr wichtig!

Szenario 1: Systemversionierung (SV) in SAP HANA

Praktische Beispiele zur Systemversionierung

Wichtige Hinweise zur Systemversionierung

Nicht unterstützte Funktionen für Systemversionierung

Szenario 2: Anwendungszeitreisen (ATT) in SAP HANA

Laden der Initialdaten für ATT

Aktualisierung mit FOR PORTION OF APPLICATION_TIME

Abfragen mit FOR APPLICATION_TIME AS OF

Wichtige Hinweise zu Anwendungszeitreisen (ATT)

Allgemeine Einschränkungen für beide Szenarien in SAP HANA SQL DWH

Fazit: Die Stärke der Zeitabhängigkeit in SAP HANA

Aktualisierung mit `FOR PORTION OF APPLICATION_TIME`

Abfragen mit `FOR APPLICATION_TIME AS OF`