Eine der Hauptneuerungen des SQL:2011 Standards war die breitere Unterstützung für temporale Datenbanken. Einige dieser Konzepte wurden peu à peu in den Funktionsumfang der SAP HANA Datenbank übernommen.
Seit SPS 03 unterstützt HANA 2 “system-versioned tables”. Mit SPS 04 kommt das Feature für “application-versioned tables” hinzu. Mit diesen beiden Konzepten lässt sich eine bi-temporale Versionierung auf Datenbankebene ohne extensive Applikationslogik realisieren.
Am besten lässt sich die neue Funktionalität mit einem Beispiel verdeutlichen.
Als erstes legen wir eine Tabelle an, in der die Änderungen an den Daten historisiert werden.
CREATE TABLE PartnerHistory(
ID INTEGER,
FirstName VARCHAR(64),
LastName VARCHAR(64),
City VARCHAR(64),
BusinessValidFrom DATE CS_DAYDATE NOT NULL,
BusinessValidTo DATE CS_DAYDATE NOT NULL,
SystemValidFrom LONGDATE CS_LONGDATE NOT NULL,
SystemValidTo LONGDATE CS_LONGDATE NOT Null
);Danach legen wir die eigentliche Datenbanktabelle an, die die aktuellsten Datensätze bereithält.
CREATE TABLE Partner(
ID INTEGER,
FirstName VARCHAR(64),
LastName VARCHAR(64),
City VARCHAR(64),
BusinessValidFrom DATE CS_DAYDATE NOT NULL,
BusinessValidTo DATE CS_DAYDATE NOT NULL,
SystemValidFrom LONGDATE CS_LONGDATE NOT NULL GENERATED ALWAYS AS ROW START,
SystemValidTo LONGDATE CS_LONGDATE NOT Null GENERATED ALWAYS AS ROW END,
PERIOD FOR SYSTEM_TIME ( SystemValidFrom, SystemValidTo ),
PERIOD FOR APPLICATION_TIME ( BusinessValidFrom, BusinessValidTo ),
PRIMARY KEY( ID, BusinessValidFrom, BusinessValidTo )
)
WITH SYSTEM VERSIONING HISTORY TABLE "PARTNERHISTORY"
;Schauen wir uns einige der Deklarationen genauer an:
- PERIOD FOR SYSTEM_TIME : Spezifizieren der Felder für die Systemzeit
- FOR PORTION OF APPLICATION_TIME: Spezifiezieren der Felder für die betriebswirtschaftliche Gültigkeit eines Tabelleneintrages
- WITH SYSTEM VERSIONING HISTORY TABLE “PARTNERHISTORY”
- GENERATED ALWAYS AS ROW START: Das System updated automatisch den Timestamp
- GENERATED ALWAYS AS ROW END: Das System updated automatisch den Timestamp
- WITH SYSTEM VERSIONING HISTORY TABLE xxx: Verlinkung der Historisierungstabelle
Im nächsten Schritt füllen wir die Tabelle mit zwei Beispieldatensätzen.
INSERT INTO PARTNER SELECT 1, 'Jon', 'Doe', 'San Francisco', TO_DATE('2012-04-23') , TO_DATE('9999-12-31') FROM DUMMY; INSERT INTO PARTNER SELECT 2, 'Max', 'Mustermann', 'Berlin', TO_DATE('2014-03-01') , TO_DATE('9999-12-31') FROM DUMMY;
Tabelle “Partner” nach dem ersten INSERT
Anschließend testen wir, was bei einem standartmäßigem UPDATE passiert.
UPDATE PARTNER SET CITY = 'Stuttgart' WHERE ID = 2;
Tabelle “Partner” nach dem ersten Update
Tabelle “PartnerHistory” nach dem ersten Update
Die eigentliche Datenbanktabelle wurde in der Spalte “City” aktualisiert. Automatisch wurde der alte Eintrag in die Historisierungstabelle mit aktualisiertem Systemzeitstempel verschoben.
Als nächstes testen wir, was bei einem Update für eine bestimmte betriebswirtschaftliche Periode passiert. Dies erreichen wir durch den Zusatz “FOR PORTION OF APPLICATION_TIME”
UPDATE PARTNER FOR PORTION OF APPLICATION_TIME FROM '2015-08-20' TO CURRENT_DATE SET CITY = 'Hamburg' WHERE ID = 2;
Tabelle “Partner” nach dem APPLICATION_PERIOD UPDATE
Tabelle “PartnerHistory” nach dem APPLICATION_PERIOD UPDATE
Wie man sehen kann, wird die Datentabelle in der richtigen Zeitperiode um den “Hamburg” Eintrag ergänzt. Aus einem Eintrag für Max Mustermann sind drei generiert worden. Nach dem Ende der Gültigkeit für den temporären Ortswechsel nach Hamburg gilt wieder der Eintrag für Stuttgart.
Natürlich funktioniert nicht nur das Update oder Insert, auch ein SELECT lässt sich um temporale Zusätze erweitern. Betrachten wir z.B. einen bestimmten Systemstempelzeitraum, werden die korrekten Einträge aus der Datenbanktabelle und der Historiesierungstabelle gelesen. In folgendem Fall werden die ursprünglichen Einträge nach dem ersten INSERT rekonstruiert.
SELECT * FROM PARTNER FOR SYSTEM_TIME FROM '2010-04-17 19:48:09.853765500' TO '2019-04-17 19:48:09.853765500';
Entsprechende SELECT * FROM <table> FOR APPLICATION_TIME AS OF ‘<timestamp> oder eine Kombination mit der Systemzeit sind auch möglich. Hier wird auf die HANA SQL Referenz für weitere Details verwiesen.
In HANA XSA HDI containern können die entsprechenden Features durch die CDS Dateien mit den Endungen .hdbapplicationtime und .hdbsystemversioning verwendet werden.
Im Hinblick auf SAP Financial Services Data Management (FSDM) wird es spannend, ob die SAP Entwicklung die Read/Write Interfaces auf die neuen SPS 04 Funktionen anpassen wird.
Weitere Referenzen über temporale Tabellen in HANA finden sich unter dem angegebenen Link.
Ein Gedanke zu „SAP HANA 2.0 SPS 04 – Bi-temporale Versionierung“
Pingback: FSDM Data Management: SAP PowerDesigner und SAP EAD als Duo
0 Kommentare