Stammdaten können sich über die Zeit verändern. Solche Änderungen lassen sich mit Hilfe von Slowly Changing Dimensions (SCD) erfassen und dokumentieren. In diesem Beitrag betrachten wir ein Beispiel dazu: Kostenstellen mit Parent-Child-Strukturen. Die Kostenstellen können von Jahr zu Jahr innerhalb der Parent-Child-Struktur umziehen. Zusätzlich zu den SCD-Eigenschaften muss das Modell weitere besondere Anforderungen erfüllen. Die Bewegungsdaten eines Jahres müssen mit den Parent-Child-Strukturen eines anderen Jahres analysiert werden können. Dabei sollen die Daten nicht vervielfältigt werden. In diesem Blog wird ein Lösungsvorschlag für dieses Problem vorgestellt.

In bestimmten Fällen können sich Stammdaten über die Zeit verändern. Dies bringt viele Herausforderungen mit sich. Zum Beispiel müssen Bewegungsdaten zu jedem Zeitpunkt den richtigen Stammdaten zugeordnet werden können. Zusätzlich sollte auch eine Historisierung der Daten möglich sein.

In diesem Blog beschäftigen wir uns mit diesem Problem anhand eines Beispiels mit Kostenstellen, die jeweils einer Abteilung im Unternehmen zugeordnet sind. Die Kostenstellen können ihre Abteilung von Jahr zu Jahr wechseln. Dieser Wechsel der Abteilungen führt zu einer Veränderung der Stammdaten. Würde man dafür die bisherigen Stammdaten einfach überschreiben, wären alle Kosten, die in der Vergangenheit auf dieser Kostenstelle erfasst wurden, fälschlicherweise der neuen Abteilung zugeordnet. Zusätzlich zu diesem Problem hat unser Beispiel ein paar Besonderheiten und Anforderungen, die erfüllt werden müssen.

Besonderheiten: Die Kostenstellen besitzen eine Parent-Child-Struktur (PC). Des Weiteren gibt es zwei Sichtweisen auf die Kostenstellen: Leistungsempfänger und Leistungserbringer. Beide Besonderheiten müssen im Modell abgebildet werden.

Anforderungen: Die PC-Kostenstellenstrukturen aller Jahre müssen gleichzeitig verfügbar sein, da es sonst etwa vorkommen kann, dass Planwerte für Folgejahre auf falschen bzw. ungültigen Kostenstellen erfasst werden, sobald sich die PC-Struktur der Kostenstellen ändert. Diese Anforderung soll erfüllt werden, ohne dass Daten vervielfältigt werden müssen.

Zusammengefasst ist das Ziel, für jedes Jahr, für das Bewegungsdaten vorhanden sind, die zu diesem Zeitpunkt aktuelle Parent-Child-Struktur in DeltaMaster zur Verfügung zu stellen. Gleichzeitig soll es auch möglich sein, ältere bzw. zukünftige Parent-Child-Strukturen der Kostenstellen darzustellen. Außerdem sollen die Bewegungsdaten jedes Jahres auch mit den Parent-Child-Strukturen eines jeden anderen Jahres analysiert werden können.

Relationale Modellierung

Im ersten Schritt zur Lösung des beschriebenen Problems archivieren wir die Stammdaten. Wir müssen zu jedem Zeitpunkt wissen, welche Kostenstelle welcher Abteilung zugeordnet ist. Zur Archivierung wird eine Kombination aus Typ 1 und Typ 2 der Slowly Changing Dimensions verwendet (eine kompakte Erklärung beider Typen findet sich hier). Somit wird für jedes Jahr immer der aktuelle Primärschlüssel einer jeden Kostenstelle als gültig markiert.

Nachdem die Stammdaten archiviert wurden, beginnen wir mit der relationalen Modellierung. Zunächst kümmern wir uns um die Kostenstellen. Hierzu werden zwei Tabellen oder Views benötigt. Eine enthält die PC-Struktur der Kostenstellen. Für jedes Jahr gibt es einen Ast. Das Jahr ist immer der Top-Knoten über der eigentlichen Hierarchie. Die Schlüssel (IDs) der Elemente sind immer mit dem Jahr des entsprechenden Astes verkettet (Abbildung 1).

Abbildung 1: View Parent-Child-Struktur

Als Bezeichnung werden die Elemente ohne das Jahr verwendet, um in DeltaMaster eine bessere Übersicht zu gewährleisten. In Abbildung 2 sieht man die PC-Struktur grafisch in DeltaMaster dargestellt. Hier kann man auch unser Problem beobachten. Die Kostenstelle 133 zieht vom Knoten F im Jahr 2021 zum Knoten G im Jahr 2022 um.

Abbildung 2: PC-Struktur 2021 (links) versus 2022 (rechts)

Die zweite Tabelle oder View enthält eine flache Liste aller Kostenstellen ohne Jahresbezug (Abbildung 3). Sie fungiert als Hilfsdimension und ist für die multidimensionale Modellierung relevant.

Abbildung 3: Flache Liste der Kostenstellen

Anschließend werden für unser Beispiel noch Bewegungsdaten benötigt (vgl. Abbildung 4). In den Bewegungsdaten kann man direkt erkennen, dass die Fremdschlüssel nicht verändert werden – hier sind weiterhin nur die Kostenstellen vorhanden. Das Jahr wird nicht mit den Kostenstellen konkateniert.

Abbildung 4: Bewegungsdaten

Wie man sieht, kann die Parent-Child-Struktur auf diese Art und Weise nicht direkt an die Bewegungsdaten angebunden werden. Man würde den konkatenierten Schlüssel in den Bewegungsdaten benötigen. Dies würde jedoch dazu führen, dass die Bewegungsdaten eines Jahres nicht mit der PC-Struktur eines anderen Jahres analysiert werden können, da die Kostenstellen mit konkateniertem Schlüssel nur unter der PC-Struktur des jeweiligen Jahres angebunden wären. Eine mögliche Lösung dafür läge in der Vervielfältigung der Daten. Eine Datenvervielfältigung soll in unserem Fall jedoch vermieden werden. Daher lösen wir das Problem multidimensional.

Multidimensionale Modellierung der Slowly Changing Dimensions

Zuerst modellieren wir die Sichtweisen auf die Kostenstellen: Leistungserbringer und Leistungsempfänger. Die PC-Struktur ist für beide Sichtweisen immer exakt gleich. Das heißt, dass die beiden Sichtweisen als Role Playing Dimensions modelliert werden können.

Nun binden wir die Kostenstellen an die Bewegungsdaten an. Dies geschieht über eine Many-to-Many-Bridge. Als Erstes werden die Kostenstellen aus der flachen Liste an die Bewegungsdaten angebunden. Nun brauchen wir zwei Measure Groups, die als Bridge fungieren. Diese enthalten jeweils die Zuordnung von Kostenstelle zu Kostenstelle mit konkateniertem Schlüssel (Abbildung 5).

Abbildung 5: Bridge

Über die Bridges kann nun die PC-Hierarchie der Kostenstellen angebunden werden. In Abbildung 6 sieht man das Modell. Die PC-Struktur ist über zwei Bridges an die Hilfskostenstellen und somit an die Bewegungsdaten angebunden. Es sind zwei Bridges, da für jede Sichtweise auf die Kostenstellen (Leistungserbringer bzw. Leistungsempfänger) jeweils eine Bridge angelegt wird, die der anderen gleicht. Da nun über die Bridge alle Kostenstellen mit allen Jahren verbunden sind, können die Kosten nun auch mit den Strukturen aller Jahre analysiert werden. Damit wurden die Daten nicht vervielfältigt.

Abbildung 6: Modell

Ergebnis in DeltaMaster

Nach der Modellierung können nun die Ergebnisse in DeltaMaster betrachtet werden (Abbildung 7). Als erstes sollte in DeltaMaster nach Jahren gefiltert werden, um die jeweiligen Daten der Jahre zu erhalten. Wir filtern auf das Jahr 2022. Auf den Zeilenachse befinden sich die Kostenstellen aus der Sicht der Leistungsempfänger. Als Kennzahl auf der Spaltenachse verwenden wir die Kosten.

Abbildung 7: Ergebnis in DeltaMaster

Wie man sehen kann, ist es möglich, die Parent-Child-Struktur der Kostenstellen der Jahre 2021 und 2022 anzuzeigen. Für beide Strukturen werden durch den Filter in der Periode die Bewegungsdaten des Jahres 2022 angezeigt. Dies funktioniert, da über die Many-to-Many-Bridges nun die Kostenstellen mit konkatenierten Schlüsseln über die Hilfsdimension angebunden sind. Das heißt, dass zum Beispiel die Filterung auf das Jahr 2021 in DeltaMaster nicht nur die Kostenstelle 2021_114, sondern auch die Kostenstelle 2022_114 ausgibt und somit beide Kostenstellen unter beiden Jahresknoten der Parent-Child Struktur angezeigt werden. In unserem Fall sind alle Kostenstellen in der Parent-Child- Struktur über die Bridge mit jedem Jahr verknüpft. So können trotz der Filterung auf ein Jahr die Parent-Child-Strukturen aller Jahre in DeltaMaster angezeigt werden. Die Anforderung, die Daten eines jeden Jahres mit den PC-Strukturen eines jeden Jahres analysieren zu können ist somit erfüllt. Durch die Kombination aus Role Playing Dimensions und Many-to-Many-Bridge wurden die Daten nicht vervielfältigt.