Aufteilung einer Satellite-Entität
Kriterien für das Satellite-Splitting spielen eine entscheidende Rolle für die Struktur eines Satelliten. Daher wird davon abgeraten, sämtliche beschreibenden Daten zu einem Business Key in einer einzigen Satellite-Struktur zu speichern. Stattdessen sollten Rohdaten vorzugsweise nach bestimmten Kriterien aufgeteilt werden.
In this article:
Kriterien für das Aufteilen eines Satelliten
Im Allgemeinen haben wir die folgenden Arten von Satellite-Splits definiert:
- Aufteilung nach Quellsystem
- Aufteilung nach Änderungsrate
Darüber hinaus haben wir zwei weitere Arten von Splits definiert:
- Aufteilung nach Sicherheits- und Datenschutzstufe
- Fachlich getriebene Aufteilung (Business-driven Split)
Eine Aufteilung des Satelliten nach Quellsystem wird dringend empfohlen, um zwei wesentliche Probleme beim Laden der Daten in das Enterprise Data Warehouse zu vermeiden: Wenn erstens zwei verschiedene Quellsysteme mit unterschiedlichen relationalen Strukturen in dieselbe Satellite-Entität geladen werden sollen, ist möglicherweise eine Transformation der Struktur erforderlich. Eine solche strukturelle Transformation erfordert jedoch früher oder später Geschäftslogik (Business Logic). Diese sollte auf die Information-Delivery-Schicht verschoben werden, um vollständig revisionssichere Umgebungen sowie die Anwendung mehrerer Geschäftsperspektiven zu unterstützen.
Das zweite Problem besteht darin, dass das Laden von zwei Quellen in dieselbe Satellite-Entität zum sogenannten „Flip-Flop-Effekt“ führt: Wenn beide Systeme widersprüchliche Daten (z. B. asynchron oder nicht synchronisiert) bezüglich des zu beschreibenden Business Keys speichern, nimmt der Satellit zwei Deltas pro Tag auf und erfasst beide Beschreibungen. Dies führt zu einem hohen Speicherverbrauch und zu Dateninkonsistenzen. Daher hilft die Aufteilung eines Satelliten nach Quellsystem dabei, den Speicherverbrauch drastisch zu reduzieren.
Zu den Vorteilen der Aufteilung von Satelliten nach Quellsystem gehört auch die Verbesserung der Parallelisierung: Daten aus mehreren Quellsystemen können parallel geladen werden. Zudem ermöglicht dieser Ansatz die Integration von Echtzeitdaten, ohne dass eine vorherige Abstimmung mit den Rohdaten aus einem Batch-Ladevorgang erforderlich ist.
Zusätzlich zum Split nach Quellsystem kann der Speicherverbrauch weiter reduziert werden, indem der Satellit nach der Änderungsrate aufgeteilt wird:
Abbildung: Mehrere Satelliten (aufgeteilt nach Quellsystem) hängen von einem Hub ab
Um einen Satelliten basierend auf der Änderungsrate aufzuteilen, wird die Änderungshäufigkeit aller Attribute bestimmt. Anschließend werden die Daten nach ihrem Änderungsverhalten gruppiert: solche, die sich nie ändern, solche, die sich gelegentlich ändern, und solche, die sich sehr häufig ändern. Das Aufteilen eines Satelliten nach der Änderungsrate trennt sich schnell ändernde Attribute von sich langsam ändernden Attributen. Dies verhindert unnötigen Speicherverbrauch, wenn sich ein dynamisches Attribut aktualisiert.
Der Satellite-Split nach Quellsystem sowie der technische Split nach der Änderungsrate der Daten (der bei aktivierter Seitenkomprimierung in der Datenbank eventuell entfallen kann) sind gängige und empfohlene Praktiken bei der Aufteilung beschreibender Attribute. Wir haben uns jedoch dafür entschieden, Rohdaten sowohl aus technischer Sicht als auch nach ihrer fachlichen Bedeutung noch weiter aufzuteilen.
Im Rahmen unseres Prozesses gliedern sich die Sicherheitsstufen wie folgt:
- Von der niedrigsten Vertraulichkeitsstufe (Stufe 0, 1: keine Sicherheitsmaßnahme erforderlich, für öffentliche Daten)
- über beschränkten Zugriff für bestimmte interne Stellen (Stufe A, R, C, F)
- bis hin zur höchsten Vertraulichkeitsstufe (Stufe S: streng geheim)
Darüber hinaus verteilt die fachlich getriebene Aufteilung (Business-driven Satellite Split) die Rohdaten unter Nutzung spezifischer fachlicher Bedeutungen des Dateninhalts auf verschiedene Satellite-Tabellen.
Für diesen Zweck haben wir verschiedene Klassifizierungen definiert, wie etwa „Contact“ für Kontaktdaten oder „Activity“ für Daten, die Nutzerinteraktionen mit dem Datensatz des Quellsystems nachverfolgen.
Zudem können Datenmodellierer benutzerdefinierte fachliche Klassifizierungen für spezifische, eindeutige Bedeutungen innerhalb von Geschäftsobjekten (Business Objects) festlegen.
Beispielsweise werden häufig alle Datenattribute einer Anwendung, die auf der CRM-Plattform Salesforce installiert ist, in einer einzigen Satellite-Struktur gespeichert. Der Hauptvorteil von Business-driven Satellites besteht darin, dass sich Apps flexibel hinzufügen oder entfernen lassen, während die Auswirkungen von Strukturänderungen auf das EDW auf ein Minimum reduziert werden.
Zusammenfassend zeigt das folgende Beispiel die Benennung eines Satelliten in unserer internen EDW-Lösung:
customer_contact_sfdc_lcp_s
Bei dem obigen Beispiel handelt es sich um einen Satelliten eines Geschäftsobjekts namens „Customer“, der die Kontaktinformationen von Kunden aus dem Quellsystem Salesforce enthält. Sein Inhalt weist eine geringe Änderungsrate sowie die Sicherheitsstufe C auf und umfasst personenbezogene Daten.
Fazit
In diesem Blogbeitrag wurde die Data-Vault-Entität Satellite vorgestellt. Wir haben unsere grundlegenden Empfehlungen zur Aufteilung eines Satelliten nach verschiedenen Kriterien sowie deren jeweilige Vorteile erläutert. Darüber hinaus haben wir weitere Ansätze zum Satellite-Splitting empfohlen, die bei Scalefree auf Basis von Quelldaten angewendet werden. In unserem nächsten Blogbeitrag beleuchten wir die Satellite-Modellierung im Hinblick auf etwaige Strukturänderungen im Quellsystem genauer.
