Dieser Blogbeitrag zeigt, wie dem DeltaMaster-Anwender eine Möglichkeit zur Überwachung der Datenaktualität mit an die Hand gegeben werden kann. Dabei wird in jeder Measuregroup pro Wertart der maximale Datumswert gesucht.
Es wird dargestellt, wie diese Informationen über eine SQL-Prozedur ermittelt, ans Datenmodell angebunden und anschließend vom Anwender genutzt werden können. Hinsichtlich der Nutzung werden Anwendungsfälle für das DeltaMaster Tickerportal, DeltaMaster Ordnerkacheln und für Grafische Tabellen gezeigt.
Daten von vorgestern
„Von wann sind diese Daten?“ – Stellt ein Anwender diese Frage, so möchte er die Daten, die er gerade vor sich hat, in einen zeitlichen Kontext einordnen können. Häufig steckt in dieser Frage auch unterschwellig der Zweifel, ob die Daten tatsächlich wie z. B. vermutet vom Vortag, oder nicht doch schon einige Tage älter sind.
Das wird besonders dann relevant, wenn z. B. auf Tagesebene gelieferte Daten nur auf Monatsebene betrachtet werden.
Abbildung 1: Monatsbericht für den laufenden Monat – enthält dieser schon die Daten des Vortages oder sehen wir noch die Daten von vorgestern?
Daher ist die Idee naheliegend, dem Anwender eine solche Information mitzugeben. Dafür muss für jede Measuregroup geprüft werden, was das maximale, an die Periodendimension angebundene Datum ist. Schnell wird man feststellen, dass diese Information alleine nicht zielführend ist, da eine Measuregroup z. B. auch Planwerte enthalten kann, die ja in der Zukunft liegen. Daher ist eine Unterscheidung nach Wertart notwendig.
Der folgende Blogbeitrag zeigt, wie es in einem mit DeltaMaster Modeler erstellten Modell möglich ist, die-se Information dem Anwender komfortabel verfügbar zu machen.
Das Konzept
Die Grundidee dieses Ansatzes ist es, eine Prozedur anzulegen, die über sämtliche Faktentabellen, die an die Periodendimension angebunden sind, iteriert und für jede Measuregroup in Kombination mit den in ihr vorkommenden Wertarten das maximale Datum ausliest und diese in einer Tabelle protokolliert.
Diese Tabelle wird wiederum als eigene Measuregroup im Datenmodell angebunden. Die Prozedur wird dann im Anschluss des Transformationsprozesses, also wenn alle Faktentabellen befüllt sind, ausgeführt.
Somit stehen die Informationen dann direkt in der Analysesitzung zur Verfügung.
Um diese Logik implementieren zu können, machen wir uns die standardisierten Namensräume, Standarddimensionen und die Tabellen des Metamodells von DeltaMaster Modeler zu Nutze.
Im ersten Schritt der Prozedur wird die Tabelle, in der die Ergebnisse protokolliert werden sollen, gelöscht (falls vorhanden) und neu erstellt. Hintergrund ist, dass unterschiedliche Measuregroups auf un-terschiedlichen Ebenen an die Periodendimension angebunden sein können und neue Ebenen hinzukommen können (z. B. zusätzliche Halbjahresebene). Somit bleibt die Prozedur dynamisch.
Zur Erstellung unserer Zieltabelle (T_D_MsrGrpDate) werden aus der Metamodelltabelle T_Model_Dimension_Levels die Ebenen der Periodendimension ausgelesen. Dabei wird davon ausgegangen, dass die Periodendimension die ID „1“ hat. Dies kann jedoch innerhalb der Prozedur über eine Variable angepasst werden. Für jede Ebene wird in der Zieltabelle eine weitere Spalte mit dem entsprechenden Ebenennamen hinzugefügt. Außerdem gibt es in dieser Tabelle noch die Spalten FactID zur Verknüpfung mit der jeweiligen Measuregroup und ValueTypeID zur Angabe der Wertart.
Als Ergebnis entsteht z. B. eine solche Tabelle:
Abbildung 2: Zieltabelle T_D_MsrGrpDate zur Protokollierung der Datenaktualität
Im zweiten Schritt werden alle Measuregroups, an denen die Periodendimension angebunden ist, in einen Cursor aufgenommen. Dieser Cursor wird dann durchlaufen, wobei zunächst geprüft wird, auf welcher Ebene die Periodendimension an die aktuell betrachtete Measuregroup angebunden ist. Dadurch kann durch die DeltaMaster-Modeler-Namenskonvention („<Ebenenname> + ‚ID‘ ist Spaltenname der angebunden Dimensionen in der T_FACT-Tabelle“) der Spaltenname ermittelt werden.
Mithilfe der MeasuregroupID werden jetzt aus der Systemtabelle sys.objects alle T_FACT_-Tabellen der Measuregroup ausgelesen. Dabei wird auf den Namensraum T_FACT_<MeasuregroupID>_<Measuregroup-Name>% geprüft. Eventuell existierende Kommentarta-bellen werden ausgeschlossen.
Achtung: Ist die Option „Create table“ im DeltaMaster Modeler Bericht „Measure groups“ deaktiviert, werden keine T_FACT-Tabellen von DeltaMaster Modeler angelegt. Als Quelltabellen werden dann direkt die im Bericht „Measure group source table“ angebundenen Tabellen und Views genutzt. Diese werden von der Prozedur nicht berücksichtigt!
Über die ausgelesenen T_FACT-Tabellen der Measuregroup wird jetzt wiederum ein Cursor gestartet, der aus jeder Tabelle das maximale Datum pro Wertart ausliest. Am Ende wird aus diesen Maxima aller T_FACT-Tabellen der Measuregroup noch das absolute Maximum pro Wertart ermittelt und dieses in die zu Beginn erstellte T_D_MsrGrpDate-Tabelle geschrieben. Der Code der Prozedur liegt diesem Blogbeitrag als Anhang bei.
Führt man die Prozedur jetzt aus, dann sieht die befüllte T_D_MsrGrpDate-Tabelle z. B. so aus:
Abbildung 3: Befüllte T_D_MsrGrpDate-Tabelle nach Ausführung der Prozedur
Diese Tabelle enthält jetzt alle Informationen, die uns interessieren. Es wäre damit bereits möglich, eine relationale DeltaMaster-Anwendung zu bauen, um die Aktualität der einzelnen Measuregroups zu prüfen.
Noch komfortabler wird es, wenn diese Tabelle als eigene Measuregroup an unser Datenmodell angebunden wird. Dafür wird eine weitere Dimension benötigt, die alle Measuregroups unseres Datenmodells, die die Periodendimension verwenden, auflistet.
Abbildung 4: Neue Measuregroup “Measuregroups” mit Quelltabelle “T_D_MsrGrpDate”
Die Parameter „Create table“ und „Create proc“ für die Measuregroup werden deaktiviert. Ebenso die Parameter „Del. Table“ und „Fill table“ für die Quelltabelle. Dies ist nötig, da die Prozedur erst im Anschluss an den Transform laufen soll und die Quelltabelle T_D_MsrGrpDate dabei jeweils neu erstellt wird.
Neben der neuen Dimension „Measuregroups“ wird die Dimension Wertart angebunden.
Abbildung 5: Angebundene Dimensionen Wertart und Measuregroup
Abbildung 6: Kennzahlen für die einzelnen Ebenen der Periodendimension
Die einzelnen Periodenebenen, die in der T_D_MsrGrpDate-Tabelle als Spalte aufgenommen wurden, werden als Kennzahlen der Measuregroup aufgenommen. Beim Datentyp muss zunächst „Integer“ gewählt werden.
Sind auch Tageswerte dabei (vgl. Kennzahl „Tag“), dann können diese mit folgender Ergänzung im Cubeskript in eine Datumskennzahl umgewandelt werden, die sich in DeltaMaster anschließend schöner formatiert darstellen lässt:
CREATE MEMBER CURRENTCUBE.[Measures].[MsrGrpTagDate]
AS
iif ([Measures].[Tag] <> NULL,
CDate(Left([Measures].[Tag],4)
+ "-" + Mid([Measures].[Tag], 5, 2)
+ "-" + Right([Measures].[Tag], 2)),
NULL),
VISIBLE = 1 , ASSOCIATED_MEASURE_GROUP = 'Measuregroups';
Die ursprüngliche Tageskennzahl kann dann auf unsichtbar gesetzt werden, um Verwechslungen zu vermeiden.
Die Anwendungsfälle
Denkbar ist zum Beispiel eine Anwendung in einem DeltaMaster Tickerportal:
Abbildung 7: Datumsinformation in einem DeltaMaster Tickerportal eingesetzt
Gerade im Vorbeigehen hat ein Betrachter oft nicht die Möglichkeit zu prüfen, ob der Ticker z. B. bereits die Daten des Vortages enthält oder noch den Stand von vorgestern zeigt. Hier hilft diese zusätzliche Information, um für Klarheit zu sorgen.
Auch eine Anwendung zum Überwachen der Datenaktualität ist denkbar. Dabei kann die Datenaktualität noch visuell durch die Ordnerkacheln in DeltaMaster 6 unterstützt werden:
Abbildung 8: Nutzung der Aktualitätsinformation in einer Monitoring Anwendung
Dafür kann man in DeltaMaster noch eine benutzerdefinierte Kennzahl anlegen, die den Abstand in Tagen seit der letzten Datenlieferung bis zum aktuellen Datum errechnet:
IIF
(#1 = NULL,
NULL,
DATEDIFF("d", now(), #1)
)
--#1 = im Cube-Skript angelegten Kennzahl [Measures].[MsrGrpTagDate]So kann mit einem Blick gesehen werden, in welchen Measuregroups keine aktuellen Daten vorliegen.
Natürlich können auch alle Measuregroups mit ihren einzelnen Wertarten in einem einzigen Bericht überwacht werden. Dabei wird nochmals deutlich, warum für jede Ebene der Periodendimension eine eigene Kennzahl nötig ist. Die Measuregroup Deckungsbeitrag ist lediglich auf Monatsebene angebunden, während die Measuregroup Lagerbestand auf Tagesebene vorliegt. Auch wird die Unterscheidung zwischen den Wertarten deutlich. Die Planung liegt bereits bis Dezember 2016 vor, während die Istzahlen bis zum September 2015 vorliegen.
Abbildung 9: Gesamtübersichtsbericht
Diese Anwendungsfälle sind natürlich nur erste Ideen und können beliebig verfeinert werden. Auch ob und in welcher Form die Aktualitätsdaten in das Datenmodell mit aufgenommen werden, kann natürlich frei entschieden werden. Als Ausgangspunkt kann in jedem Fall die diesem Blogbeitrag beigefügte Prozedur dienen.
