Resiliente und temporal korrekte Dimension-Ids für Fakten- und Dimensionstabellen bei FastChangeCo
Sind in einem dimensionalen Datenmodell, aufbauend auf einem Data-Vault-Datenmodell, Integer-Werte als Dimension-Ids immer noch notwendig?
Und wenn ja, wie können die Dimension-Ids korrekt bereitgestellt werden? Diese Frage stellt sich das Data Management Center of Excellence (DMCE) bei FastChangeCo™. FastChangeCo™ ist eine fiktive Firma, die mit den alltäglichen Herausforderungen in und mit der Welt der Daten zu kämpfen hat. Das DMCE-Team hat sich zum Ziel gesetzt, FastChange-Co™ mit neuen Ideen und Lösungen fit für die Zukunft zu machen – mit all den Unsicherheiten, die die Zukunft mit sich bringt. In einem neuen Use-Case, der zur Umsetzung ansteht, sieht sich das DMCETeam mit der eingangs gestellten Frage konfrontiert, denn abhängig von der für die Applikationen im Frontend eingesetzten Technologien zum Zugriff auf die qualitativ hochwertigen und temporalen Daten in ihrem Data Warehouse sind unterschiedliche – technologieabhängige – Strukturen für eine ausgehende Schnittstelle notwendig.
Strukturen in Form einer OASI-Tabelle, eines Snowflake-Schemas oder der 3. Normalform sind nur einige Beispiele, die bei FastChangeCo™ als ausgehende Schnittstellen aktuell verwendet werden. Eine weitere, oft vom DMCE-Team verwendete Variante sind Strukturen in Form eines Star-Schemas. Dabei sind Dimension-Ids (auch Surrogate Keys oder Primary Keys genannt) in den Dimensionen elementare Bestandteile, um Fakten (Faktentabellen– zum Beispiel Einzelhandelsumsätze) mit dem zugehörigen beschreibenden Kontext (Dimensionstabellen– zum Beispiel Produkt, Datum, Ladengeschäft oder Kunde) zu verknüpfen [KiR13]. Die bei FastChangeCo™ [TED] üblicherweise erstellten dimensionalen Datenmodelle (Star-Schemas) enthalten Dimensionen mit unterschiedlichen Variationen derselben Daten – wie zum Beispiel Kontextinformationen über Produkte aus der aktuellen, heutigen Sicht (SCD1, As-Is) – oder mit einer Historie über die Produkte (SCD2, As-Was).
Dimension-Ids für FastChangeCo?
Bei FastChangeCo™ wurde zu Beginn des aktuellen Data-Warehouse-Projekts entschieden, Hash-Werte als Surrogate Keys bei der Implementierung von Data Vault zu verwenden. Im weiteren Projektverlauf entschloss sich das DMCE-Team, dass auch für ausgehende Schnittstellen Hash-Werte als Surrogate Keys in der Umsetzung zur Anwendung kommen [LiO16].
Das DMCE-Team stellte sich immer wieder die Frage, ob das Verwenden von Hash-Werten, abgeleitet aus dem Geschäftsschlüssel und eventuell einem Zeitstempel, die einzige Möglichkeit ist, um Dimension-Ids zu generieren. Zum Beispiel hat das DMCE-Team mit den bei FastChangeCo™ eingesetzten vielfältigen Tools für Frontend-Applikationen Tests zur Performance durchgeführt. Die Testergebnisse zeigten, dass Integer-Werte für Dimension-Ids in einigen Szenarien geeigneter sind als Hash-Werte oder natürliche Geschäftsschlüssel, um nachgelagerte Applikationen mit Daten zu versorgen.
Ein neuer Use-Case
Michael Müller, Head of Data Management bei FastChangeCo™, fragt sich allerdings: „Woher nehmen, wenn nicht stehlen?“ – und meint damit, im metaphorischen Sinn, die Integer-Werte für die Dimension-Ids.Michael möchte zur Umsetzung des anstehenden Use-Case mit Xuefang Kaya, einer jungen und ambitionierten Datenmodelliererin im DMCE-Team, sowie mit Philomena Pavlovic, einer erfahrenen Applikationsentwicklerin und Business-Analystin, zuerst die Anforderungen für eine adäquate Lösung für die dafür notwendige neue ausgehende Schnittstelle gemeinsam entwickeln.
Zusammen erarbeiten sie eine Übersicht der Anforderungen, die sowohl für die im Use-Case eingesetzten Technologien ‚Bedürfnisse‘ als auch die fachlichen Ansprüche erfüllen – gänzlich davon losgelöst, ob die Daten im Data Warehouse bereits vorhanden sind oder nicht.
Ein Auszug:
- Inhaltliche Attribute und Datenformate für die Schnittstellenstruktur
- Temporale Konsistenz (As-Is und As-Was) als Basis für die Auditfähigkeit
- Definierte Grenzwerte zur Aktualisierungsdauer der Daten in der Applikation
- Integer-Werte als Dimension-Ids (aus technischen Gründen zur Performance in der Applikation)
- Resiliente (das heißt stabile und widerstandsfähige) Dimension-Ids, denn einmal vergebene Integer-Werte dürfen sich im Lebenszyklus eines Datensatzes nicht verändern
Aus den Anforderungen ergeben sich für das DMCE-Team die wesentlichen neuen Anforderungen, dass in diesem Use-Case mit einem Star-Schema als ausgehende Schnittstelle die Integer-Werte resilient, nachverfolgbar, wiederverwendbar und temporal korrekt für Fakten- sowie Dimensionstabellen aufbereitet sein müssen. Nur: Die dafür notwendigen Integer-Werte existieren bis dato nicht in der implementierten Datenlösung.Die Ausgangssituation für den umzusetzenden Use-Case ist die Verwaltung der bei FastChange-Co™ arbeitenden Studenten. Für die Studenten soll anhand der Anforderungen eine Dimension Dim-Student erstellt werden – als Teil der ausgehenden Schnittstelle [Ler19]. Die fachlichen Attribute und Datenformate haben Philomena, Xuefang und Michael gemeinsam in Abbildung 1 dokumentiert.
Abb. 1: Definition der Struktur einer Dimension – ausgehende Schnittstelle
Eine adäquate Lösung
Bis auf die Dimension-Ids sind alle Daten bereits in den Rohdaten vorhanden. Hier ist kein weiterer Aufwand zur Bereitstellung der Daten zu erwarten. Um eine adäquate Lösung für Dimension-Ids zu finden, möchte sich das Team auf wenige Data- Vault-Tabellen (Abbildung 2) konzentrieren. Damit ist es einfacher, Ideen zu entwickeln, ohne sich mit der Komplexität eines physischen Datenmodells auseinanderzusetzen zu müssen. Zur Vereinfachung des Beispiels nimmt das Trio bewusst die komplette Zeitperiode (Ldts – Ledts, closedopen) in die Beispielskizzen und -daten auf. Daserleichtert allen Beteiligten das Verständnis über die Daten wie auch deren Erklärung und Zusammenhänge.
Abb. 2: Data-Vault-Ausgangsdatenmodell (Quelle: [Ler19])
As-Is Dimension-Ids
Als Erstes, überlegt sich Xuefang, sollten wir eine Lösung für die Dimension-Ids zur As-Is-Sicht – der aktuellen Sicht – auf die Daten finden. Im Anschluss daran beschäftigen wir uns damit, wie eine Umsetzung der historischen Sicht umsetzbar ist. Ihren Vorschlag findet Michael gut – zum einen, um Schritt für Schritt vorzugehen, und zum anderen, da damit für Philomena bereits der erste Teil des Use-Case umgesetzt ist und sie mit ihrer Applikation in die Umsetzung und deren Tests gehen kann.
Die Grundüberlegung für eine Dimension-Id im Falle der As-Is-Dimension ist, dass eine 1:1-Beziehung zwischen dem Geschäftsschlüssel (Registration No.) und der Dimension-Id existiert. Hätten wir unsere Data-Vault-Strukturen mit einer Sequence statt Hash-Werten für den Surrogate Key (DV-SK) erstellt, wäre die Lösung vorhanden. Daraus leitet sich ab, dass wir ein zusätzliches Data Object benötigen, das für uns die Sequencen – Dimension-Ids – 1:1 in Bezug zum Geschäftsschlüssel abspeichert, sinniert Xuefang. Wäre ein Satellit nur für die Dimension-Ids, ohne Historisierung, die Lösung?
Michael ist mit dieser Lösung einverstanden, da dadurch eine stabile Verbindung zwischen dem Geschäftsschlüssel und einem Integer-Wert für die Dimension-Id entsteht, die unveränderlich ist, wie die von ihnen erstellte Skizze in Abbildung 3 zeigt. Zusätzlich skizziert Xuefang die passende Dimension mit Beispieldaten in den Entwurf, exakt so, wie sie die Schnittstelle zuvor gemeinsam definiert hatten. Die Spalte AsIsDimId speist sich aus den Daten, die der Satellite sStudentAsIsDimId enthält.
Ein kurzfristig vom DMCE-Team umgesetzter beispielhafter Prototyp bestätigt erfolgreich die in der skizzierten Lösung getroffenen Annahmen.
Damit hat das DMCE-Team die Anforderungen an die ausgehende Schnittstelle, Integer-Werte für die Dimension-Ids resilient, nachverfolgbar, wiederverwendbar und temporal korrekt abzubilden, erfüllt.
As-Was Dimension-Ids
Für die As-Was-Dimension ist die Umsetzung nicht ganz so einfach. Xuefang skizziert unterschiedliche Varianten, aber keine erfüllt auch nur annähernd die gestellten Anforderungen. In zwei ihrer zahlreichen Fachbücher ([Gil19] und [Hul12]) liest sie über die Möglichkeiten von Point-In-Time-(PIT-)Tabellen, sogenannter Performance-Tuning-Tabellen.
Der Ansatz scheint Xuefang vielversprechend, da eine PIT-Tabelle die Zeitlinien der an einem Hub beteiligten Satelliten bereits zu einer gemeinsamen Zeitlinie „verschmelzt“: genau das, was für eine As-Was-Dimension notwendig ist.
Xuefang fügt eine zusätzliche Spalte AsWasDimID in die PIT-Tabelle PitStudentAsWasDimId ein, um temporal korrekte Dimension-Ids zu erhalten. Wie sie aus [KiR13] weiß, gilt hier für die Dimension-Id: Bei der Historisierung von beschreibenden Daten eines Geschäftsschlüssels ist es sehr wahrscheinlich, dass dieser in mehreren Zeilen vorkommt. Es ist ein fortlaufender Surrogate Key notwendig, um die Daten je Geschäftsschlüssel in der Dimension eindeutig zu halten.
Michael merkt an, dass die Data-Vault-Performance-Objekte als nicht beständig definiert sind. Sie können gelöscht und wieder neu aufgebaut werden ([Hul12]; [LiO16]. Damit wären die Anforderungen nach einer resilienten und wiederverwendbaren Dimension-Id nicht gegeben.
Abb. 3: As-Is Dimension-Ids und daraus abgeleitete Dimension
Philomena erklärt noch einmal die Notwendigkeit für diese Anforderung: Eine andere Dimension-Id für den gleichen Geschäftsschlüssel kann in einigen der verwendeten Applikationen zu Inkonsistenzen führen. Hintergrund ist, führt sie aus, dass die Applikationen die Geschäftsschlüssel mit den zugehörigen Dimension-Ids zwischenspeichern, aber nicht kontinuierlich mit den Daten der Schnittstelle abgleichen bzw. aktualisieren – zum Beispiel wenn durch eine neu vergebene Dimension-Id Umsätze plötzlich anderen Produkten zugeordnet sind, da die Dimension-Ids zwischen Schnittstelle und Applikation oder Dimension und Fakten nicht synchron und übereinstimmend sind.Mit dieser Information von Philomena überlegt sich Xuefang eine neue Variante (Abbildung 5), in der die PIT-Tabelle zur Generierung der Dimension-Ids keine Rolle mehr spielt. Daher hat sie die PITTabelle aus der Skizze entfernt. Aus Gründen der Performance ist eine PIT-Tabelle hier jedoch nach wie vor denkbar.
Mit der neuen Variante ist eine stabile As-Was Dimension-Id möglich – unabhängig von der Anzahl an Satelliten, die Daten für die Dimension liefern. Jetzt wäre sogar eine As-Was-Dimension nur mit den Daten aus sStudent möglich, genauso wie die geforderte Kombination der Daten aus den beiden Satelliten sStudent und sAddress. Die Formel Serial Id * 100 + Serial Id zeigt vereinfacht die Art und Weise zur Erzeugung einer gemeinsamen As-WasDimId.
Das Hinzufügen einer Serial Id in jedem Satelliten macht jede historisierte Version der Kontextdaten zu einem Geschäftsschlüssel eindeutig. Eine geschickte Kombination der in den Satelliten vorhandenen Serial Ids ergibt eine resiliente, nachverfolgbare, wiederverwendbare und temporal korrekte Dimension-Id für alle Geschäftsschlüssel, erklärt Xuefang den beiden.
Abb. 4: As-Was Dimension-Ids in PIT und daraus abgeleitete Dimension
Philomena ist fasziniert. Das würde doch bedeuten: Wenn wir diese Idee mit unserem Ansatz der As-Is Dimension-Ids kombinieren, hätten wir für unsere Anforderungen an den Use-Case alle Bedingungen erfüllt, oder? Eine gegen Änderungen der Dimension-Ids gleichermaßen widerstandsfähige Schnittstelle sowohl für die As-Is- als auch für die As-Was-Dimension!
Michael und Xuefang stimmen Philomena zu und entwerfen das gemeinsame Design-Konzept für diesen Use-Case, um es dem DMCE-Team vorzustellen (Abbildung 6). Während der Präsentation des Design-Konzepts hat das DMCE-Team eine Frage: Warum nehmen wir nicht die Serial Id als AsIsDimId in der Dimension DimStudentAsIs? Ist diese nicht ausreichend?
Xuefang und Michael hatten sich diese Frage ebenfalls gestellt und bereits mit ihrem Datenmodellierungs- Coach besprochen: Im Falle der As-Is- Dimension ist immer der neueste, aktuelle Datensatz zu verwenden. Die zugehörige AsIsDimId darf sich aber nicht verändern – was jedoch bei der Verwendung der Serial Id der Fall wäre. Das entspricht nicht unseren Anforderungen an die Schnittstelle mit einer resilienten Dimension-Id. Denn bei jeder Historisierung entsteht zwangsläufig eine neue Nummer in der Spalte Serial Id.
Abb. 5: As-Was Dimension-Ids in Satelliten, kombiniert in der Dimension
Die finale Schnittstelle
Aus Sicht des DMCE-Teams ist für den gegebenen Use-Case die gefundene Lösung – mit dem zusätzlichen Satelliten sStudentAsIsDimId und der zusätzlichen Spalte Serial Id in den bestehenden Satelliten – der richtige Ansatz. Sie sind sich bewusst, dass in einem anderen fachlichen Kontext, unter anderen Voraussetzungen bei den physischen Datenmodellen oder gar einer anderen eingesetzten Technologie gänzlich andere Ansätze notwendig sind.
Für das Team ist es daher sehr wichtig, ein regelmäßiges Coaching mit einer dritten, unabhängigen Person durchzuführen. Das ermöglicht es dem Team zum einen, seine eigenen Ideen und unter Umständen festgefahrenen Ansichten zu hinterfragen, und zum anderen, Wissen im Team weiter aufzubauen oder zu vertiefen – um fit zu sein für eine Zukunft, die bekannterweise unsicher ist.
Zum Beispiel hat auch Roelant Vos das Problem im Blogpost Deterministic dimension keys in a virtual Data Vault beschrieben.
Die beiden Ideen kombiniert könnten für eines der kommenden Projekte bei FastChangeCoTM eine mögliche Lösung sein.
Philomena Pavlovic ist mit dem Ergebnis, das das DMCE-Team ihr für ihr neues Dashboard geliefert hat, mehr als zufrieden. Die Nutzer des Dashboards haben die Möglichkeit, zwischen einer aktuellen und einer historischen Sicht auf die Ereignisse zu wählen, und die Abfragen sind dank der neuen Methode zur Verwendung von Zahlen als Dimension-Ids resilient gegenüber Veränderungen in den Daten und für die gegebenen Anforderungen ausreichend performant.
Die Zusammenarbeit mit dem DMCE-Team, das Eingehen auf die Anforderungen, fachlicher und technischer Art, sind für Philomena der Schlüssel – wenn nicht sogar der ausschlaggebende Erfolgsfaktor – zur gelungenen Umsetzung dieses Use-Case.
Abb. 6: Das finale Design-Konzept zur Umsetzung der ausgehenden Schnittstelle
Literatur
[Gil19] Giles, J.: The elephant in the fridge. TechnicsPub 2019 [Hul12] Hultgren, H.: Modeling the agile data warehouse, New Hamilton 2013 [KiR13] Kimball, R. / Roos, M.: The Data Warehouse Toolkit. 3. Aufl., Wiley 2013 [Ler19] Lerner, D.: TEDAMOH Academy – Temporal data in a fast-changing world. 2019 [LiO16] Linstedt, D. / Olschimke, M.: Building a scalable Data Warehouse. MK 2016 [TED] FastChangeCo – a fictitious company. https://tedamoh.com/de/tedamoh/238-tedamoh/88-fastchangeco-afictitious-company, abgerufen am 19.7.2022