Wer hat sich noch nie gefragt, wie aktuell die Daten sind, die er gerade sieht? Egal, wie frequentiert ein Data Warehouse aufbereitet ist, die Frage stellt man sich trotzdem, insbesondere dann, wenn man die Daten hinterfragt. Damit auch Berichtsempfänger sich diese Frage selbst schnell beantworten können, haben wir eine Möglichkeit in DeltaMaster geschaffen, die unterschiedliche Varianten der Implementierung zulässt.

Diese Implementierungsmöglichkeiten und deren Für und Wider schauen wir uns hier nun im Detail an.

Die Funktionalität in DeltaMaster 6

DeltaMaster 6 bietet ab Version 6.2.3 die Möglichkeit, den Datenstand im Dashboard anzeigen zu lassen. So kann man bei einer normalen Anwendungskachel den Datenstand oben anzeigen lassen:

In unserem Beispiel sehen wir, dass die Daten wohl vom 29.06.2019 von 08:46 Uhr sind, man aber auch nur das Datum ohne Zeit anzeigen lassen kann, wenn die Uhrzeit unwichtig ist.

Eingerichtet wird der Datenstand in DeltaMaster, indem man einen Rechtsklick auf die Kachel ausführt und dann die KPI konfigurieren möchte. Dort gibt es den Reiter Datenstand:

In diesem Dialog kann man einen Bezug angeben. Dieser wird im Tooltip der Kachel angezeigt, wenn man länger mit dem Mauszeiger auf der Anwendungskachel verweilt. Beispielweise könnte man „Rechnungsdatum“ eintragen, um als Tooltip „Rechnungsdatum: 29.06.2019“ angezeigt zu bekommen.

Für die Definition des angezeigten Werts hat man drei Möglichkeiten zur Auswahl:

1. Die manuelle Eingabe: Man hinterlegt eine Datumszeichenfolge, wie z.B. 26.09.2019 oder 26.09.2019 08:46.
2. SQL-Datenbankabfrage: Man definiert einen SQL-Ausdruck, dessen Ergebnis eine Datumszeichenfolge analog zu den Beispielen in der manuellen Eingabe zurückliefert (für Analyseanwendungen gegen relationale Datenbanken).
3. MDX-Datenbankabfrage: Man definiert einen MDX-Ausdruck, dessen Ergebnis eine Datumszeichenfolge analog zu den Beispielen in der manuellen Eingabe zurückliefert (für Analyseanwendungen gegen mehrdimensionale Datenbanken).

Was für Möglichkeiten ergeben sich aus dieser Option?

Wir entscheiden uns für eine Analyseanwendung gegen SQL Server Analysis Service (SSAS) im DeltaMaster Repository, da dies der häufigste Anwendungsfall ist.

Auf den ersten Blick ergibt eine manuelle Eingabe keinen Sinn, da wir diese händisch aktualisieren müssten. Also überspringen wir diese Option und widmen uns der MDX Datenbankabfrage, da wir den Stand gerne nur einmal einrichten wollen und er sich automatisch aktualisieren soll.

Variante 1: aktueller Zeitstempel

WITH MEMBER [Measures].[TimeStamp] as 'DATEVALUE(FORMAT(NOW(),"yyyy-
MM-dd"))' 
SELECT [Measures].[TimeStamp] ON AXIS (0)
FROM CHAIR

Das MDX liefert uns immer den aktuellen Tag zurück. Mit dem Datenstand hat dies nun nicht viel zu tun, da auch eine Datenaufbereitung mal ausgesetzt werden oder fehlgeschlagen sein kann. Da wir uns auf den Wert verlassen wollen, ist diese Variante für den Anwendungsfall ungeeignet.

Variante 2: Letzte OLAP-Aufbereitung

Mit diesem Hintergrund gehen wir einen Schritt weiter und wollen gerne das letzte Verarbeitungsdatum des OLAP Cubes abfragen. Da dies mit MDX nicht so ohne weiteres funktioniert, installieren wir die ASSP Assembly auf der SSAS-Instanz und können dann das Datum mit folgendem MDX abfragen:

SELECT LAST_DATA_UPDATE FROM $SYSTEM.MDSCHEMA_CUBES
WHERE CUBE_NAME = 'Chair'

Damit wird uns nun stets angezeigt, wann die letzte Verarbeitung des OLAP Cubes durchgeführt wurde und man könnte dies als Datenstand nutzen. Jedoch ist man auf diesen Wert beschränkt und der Datumswert der OLAP-Verarbeitung ist zu ungenau, da z.B. stark frequentiert oder die Daten sehr lange  aufbereitet werden und man doch eigentlich lieber den Zeitstempel der importierten Daten haben möchte. Natürlich könnte man von dem Zeitstempel auch noch eine gewisse Zeit abziehen, um in den Wert korrigierend einzugreifen.

Variante 3: Modellanpassung

Um im Datumswert flexibel zu bleiben, erweitern wir in dieser Variante unser OLAP-Modell um eine Dimension TimeStamp mit einem Element, welches als Namen den entsprechenden Datumswert beinhaltet. Diese Dimension muss mit keiner Measuregruppe verbunden, aber im Cube vorhanden sein. Mit diesem Element können wir nun wie folgt den Wert per MDX abfragen:

WITH MEMBER [Measures].[TimeStamp] as 'DATEVALUE([TimeStamp]. [TimeStamp].
[TimeStamp].&[1].Properties("Name"))'
SELECT [Measures].[TimeStamp] ON AXIS(0) 
FROM CHAIR

Wie man den Namen des Elements ermittelt, steht dabei völlig offen. Man kann diesen z.B. mit dem Zeitstempel des Beginns oder Endes des Importprozesses versehen, aber auch in Bezug der Materialisierung von Views setzen oder direkt vor der OLAP-Verarbeitung mit dessen Zeitstempel befüllen. Wir sind nun also sehr flexibel, haben aber eine zusätzliche Dimension im OLAP-Modell, die wir nur für den Datenstand gebrauchen können. Mit Anpassungen am Modell sind natürlich auch weitere Szenarien denkbar wie z.B. über eine Eigenschaft in der Periodendimension, die man ausliest, oder eine Measuregruppe, in der der Datumswert als Analysewert enthalten ist. Letztlich ist damit aber immer eine Anpassung an der OLAP-Datenbank notwendig.

Variante 4: Repository-Datenbank

Werfen wir doch einen zweiten Blick auf die manuelle Eingabe. Auch wenn diese sehr statisch erscheint, können wir diese dynamisieren. Da die Anwendung im DeltaMaster Repository liegt, wird die Definition des Datenstands in der Repository-Datenbank gespeichert: In der Tabelle ApplicationKPI befindet sich in den Spalten KPITimeStamp, KPITimeStampDefinition, KPITimeStampDefinitionType und KPITimeStampReference die Definition des DeltaMaster Dialogs. Da wir mit der manuellen Eingabe arbeiten wollen, interessieren uns nur die Spalten KPITimeStamp, in der der Datumswert eingetragen wird, und KPITimeStampDefinitionType, die festlegt, dass wir den manuellen Eingabetyp benutzen.

Folgendes SQL Statement ist somit prinzipiell denkbar:

Update [DeltaMaster_Repository].[dbo].[ApplicationKPI]
SET KPITimeStamp = Cast(GetDate() as Date)
, KPITimeStampDefinitionType = 0
WHERE AppID = 1

In diesem Fall würden wir den Datumswert auf den aktuellen Tag für die Anwendung mit AppID 1 setzen. Wir empfehlen in dieser Variante im SSIS Paket für den ETL-Prozess den aktuellen Zeitstempel an einer geeigneten Stelle, z.B. direkt vor oder nach dem Import der Quelldaten, in einer Tabelle festzuhalten und mit diesem Zeitstempel nach der OLAP-Verarbeitung den Datenstand zu aktualisieren.

Vor- und Nachteile der vorgestellten Varianten

Nachdem wir die vier Varianten erarbeitet haben, um den Datenstand in DeltaMaster anzuzeigen, vergleichen wir nun die Ergebnisse.

Variante 1: aktueller Zeitstempel steht nicht in Verbindung des ETL-Prozesses, dafür ist es die einzige dynamische Variante, die nur DeltaMaster benötigt. Um die Funktionalität zu präsentieren, ist diese Variante gut geeignet. Vom aktuellen Zeitstempel kann man noch einen Tag abziehen, sodass man auf den Vortag kommt, was i.d.R. dem Normalfall entspricht.

Variante 2 dagegen orientiert sich am Zeitstempel der letzten Verarbeitung des OLAP Cube. Diese Variante benötigt aber einmal einen Administrator, der die SSAS Assembly ASSP einrichtet. Danach kann dies bei der Analyseanwendung in DeltaMaster eingerichtet werden. Diese Variante bietet sich an, wenn wir den Datenstand auf Basis der letzten OLAP-Verarbeitung anzeigen möchten.

Mit Variante 3: Modellanpassung haben wir die aufwendigste der vier Varianten. Sie muss in jeder OLAP-Datenbank eingebaut werden, in der man den Datenstand anzeigen lassen möchte. Dafür können wir den Datumswert frei an jeden Prozessschritt des ETL-Prozesses koppeln. Nach Einrichtung im Backend findet die Pflege ausschließlich in DeltaMaster statt.

Über Variante 4: Repository-Datenbank erhalten wir analog zu Variante 3 die Flexibilität des Datumswerts. Sie benötigt keine Anpassung an den Datenmodellen und ist damit sehr schnell implementiert. Die Einrichtung erfolgt aber vollständig außerhalb von DeltaMaster und diese Variante ist nur für Analyseanwendungen im Repository einsetzbar.

Fazit

Somit erscheint die Repository-Datenbank-Variante am überzeugendsten. Sie beinhaltet die Flexibilität, die wir haben möchten, ist mit sehr geringem Aufwand implementiert und man kann sich auch auf den Wert verlassen. Die Modellanpassungs-Variante käme für uns in Frage, wenn ohne das Repository gearbeitet wird. Man investiert mehr Zeit als in der zuvor genannten Variante, bleibt aber weiterhin flexibel und kann diese auch innerhalb von Analyseanwendungen nutzen, damit man z.B. bei einem Export den Datenstand als Information erhält. Besonders wichtig ist die Flexibilität, wenn auch die Zeit und nicht nur das Datum relevant ist.
Man sollte sich am Importieren der Daten aus dem Quellsystem orientieren, sodass die Variante mit dem letzten Aufbereitungszeitstempel des OLAP-Würfels nicht besonders ansprechend erscheint. Zum Einsatz kann sie eventuell kommen, wenn die Zeit keine Rolle spielt, sondern nur der Tag. Diesen kann man aus der OLAP-Verarbeitung ableiten, sofern das OLAP-Modell nur verarbeitet wird, wenn die Daten aktualisiert wurden. Ansonsten ist diese Variante schnell implementiert. Nachfolgend finden Sie noch die Links, hinter denen Sie die ASSP Assembly und Informationen zur Installation erhalten:

https://asstoredprocedures.github.io/ASStoredProcedures/downloads/

https://asstoredprocedures.github.io/ASStoredProcedures/Installation-Instructions/

Sich am aktuellen Zeitstempel der Abfrage zu orientieren, halten wir für den produktiven Gebrauch in diesem Anwendungsfall als ungeeignet, da hier jegliche Form von ETL-Fehler missachtet wird. Lieber keine Anzeige eines Datenstandes, statt einer im Sinne der Endanwender falschen Datenstandsanzeige.