Modellierung von Salesforce-History-Tabellen
Salesforce erfasst Änderungen an konfigurierten Attributen in sogenannten History-Tabellen. Diese Daten – darunter Record-ID, Feldname, vorheriger und neuer Wert sowie der Zeitstempel – stellen eine besondere Herausforderung für die Data-Vault-Modellierung dar. In diesem Artikel untersuchen wir, wie sich diese Daten unter Berücksichtigung der Data-Vault-Prinzipien optimal modellieren lassen.
In this article:
Salesforce-History-Tabellen verstehen
Salesforce ermöglicht die Nachverfolgung bestimmter Attributänderungen innerhalb von Objekten wie Contacts. Diese Änderungen werden in History-Tabellen wie beispielsweise ContactHistory gespeichert. Jeder Eintrag protokolliert:
- Record-ID (z. B. Contact-ID)
- Feldname
- Alter Wert
- Neuer Wert
- Zeitstempel
Herausforderungen bei der Modellierung von Salesforce-Historiedaten
Bei der Entwicklung eines Data-Vault-Modells für diese Historiedaten gilt es zentrale Herausforderungen zu beachten:
- Verarbeitung mehrerer Änderungen desselben Datensatzes innerhalb eines kurzen Zeitraums
- Gewährleistung der referenziellen Integrität
- Effizientes Abfragen und Pivotieren von Daten für das Reporting
Ansatz: Multi-Active-Satellite
Ein gängiger erster Ansatz besteht darin, die History-Tabelle als Multi-Active-Satellite an einen Contact-Hub anzubinden, wobei der Feldname als Dependent-Key dient. Dieser Ansatz birgt jedoch Fallstricke:
- Duplikate können entstehen, wenn mehrere Änderungen desselben Feldes innerhalb desselben Batches auftreten
- Auf Zeitstempeln basierende Schlüssel sind unzuverlässig, da identische Zeitstempel vorkommen können
Um dem entgegenzuwirken, sollte in der Staging-Area eine eindeutige Sequenznummer vergeben und als Dependent-Key genutzt werden.
Optimierter Ansatz: Non-Historized-Link
Anstelle eines Multi-Active-Satellites kann ein Non-Historized-Link genutzt werden, um Salesforce-Historiedaten effizienter zu modellieren. So funktioniert es:
- Erstellen Sie einen Non-Historized-Link, der den Contact-Hub und den User-Hub verbindet.
- Speichern Sie änderungsbezogene Attribute (Feldname, alter Wert, neuer Wert, Zeitstempel) direkt in diesem Link.
- Verwenden Sie den Zeitstempel als ereignisbasiertes Attribut und nicht als Teil des Primary-Keys.
Dieser Ansatz vermeidet komplexe Joins und vereinfacht die Abfragen spürbar.
Effizienter Datenabruf: Pivoting
Da History-Tabellen in einem Key-Value-Format strukturiert sind, erfordern Abfragen häufig ein Pivoting. Durch den Einsatz nativer Pivot-Funktionen der Datenbank lassen sich die Daten ohne übermäßige Joins in ein Format überführen, das für das Reporting optimal nutzbar ist.
Alternative Überlegung: JSON-Speicherung
Ein weiterer Ansatz besteht darin, Änderungsdaten als JSON-Objekt in einem Standard-Satellite zu speichern. Diese Methode bietet Flexibilität, insbesondere bei einer großen Anzahl von Attributen. Allerdings verkompliziert sie Abfragen und sollte nur dann eingesetzt werden, wenn es technisch zwingend erforderlich ist.
Fazit
In den meisten Fällen ist ein Non-Historized-Link die optimale Lösung, um Salesforce-History-Tabellen im Data Vault zu modellieren. Er vereinfacht die Datenspeicherung, reduziert den Bedarf an aufwendigen Joins und verbessert die Abfrageleistung. Multi-Active-Satellites stellen eine Alternative dar, erfordern jedoch einen sorgfältigen Umgang mit doppelten Zeitstempeln und wiederholten Feldänderungen.
