Aufteilung einer Satellitenentität
Satelliten profitieren maßgeblich von klar definierten Aufteilungskriterien – sie bestimmen die Struktur und Effizienz der Satelliten. Es ist daher nicht empfehlenswert, sämtliche beschreibende Daten die sich auf einen Business Key beziehen in einem einzigen Satelliten zu speichern. Stattdessen sollten die Rohdaten anhand bestimmter Kriterien aufgeteilt werden.
In diesem Artikel:
Kriterien für die Aufteilung eines Satelliten
Grundsätzlich lassen sich Satelliten auf folgende Weise aufteilen:
- Aufteilung nach Quellsystem
- Aufteilung nach Änderungsrate
Zusätzlich haben wir zwei weitere Aufteilungstypen definiert:
- Aufteilung nach Sicherheits- und Datenschutzanforderungen
- Business-getriebene Aufteilung
Eine Aufteilung der Satelliten nach Quellsystemen wird dringend empfohlen, um zwei zentrale Probleme beim Laden von Daten ins Enterprise Data Warehouses zu vermeiden: Zunächst könnte eine Transformation der Struktur erforderlich sein, wenn zwei verschiedene Quellsysteme mit unterschiedlichen relationalen Strukturen in denselben Satelliten geladen werden sollen. Eine solche strukturelle Anpassung erfordert jedoch früher oder später Geschäftslogik – diese sollte idealerweise erst in der Phase der Informationsbereitstellung angewendet werden, um eine vollständig prüfbare Umgebung zu ermöglichen und verschiedene geschäftliche Perspektiven sauber abzubilden.
Das zweite Problem besteht darin, dass zwei Quellen, in den selben Satelliten geladen werden, zum sogenannten „Flip-Flop-Effekt“ führen: Wenn beide Systeme widersprüchliche Daten zum gleichen Business Key liefern (z. B. weil sie nicht synchronisiert sind), verarbeitet der Satellit zwei Deltas pro Tag, die jeweils unterschiedliche Beschreibungen erfassen. Das resultiert in hohem Speicherverbrauch und Dateninkonsistenzen. Daher hilft die Aufteilung eines Satelliten nach Quellsystem, den Speicherverbrauch deutlich zu reduzieren.
Zu den Vorteilen der Aufteilung von Satelliten nach Quellsystemen gehört die Verbesserung der Parallelisierung, da Daten aus mehreren Quellsystemen gleichzeitig geladen werden können. Zudem lässt sich die Integration von Echtzeit- Daten ermöglichen, ohne dass diese mit Rohdaten aus Batch-Ladevorgängen kombiniert werden müssen.
Neben der Aufteilung nach Quellsystemen kann der Speicherverbrauch zusätzlich reduziert werden, indem Satelliten nach Änderungsrate aufgeteilt werden:
Abbildung: Mehrere Satelliten (aufgeteilt nach Quellsystem) sind einem Hub zugeordnet
Bei der Aufteilung eines Satelliten auf Basis der Änderungsrate sollte zunächst die Häufigkeit der Änderungen pro Attribut bestimmt werden. Anschließend lassen sich die Attribute in Gruppen einteilen: in solche, die sich nie, gelegentlich oder sehr häufig ändern. So werden häufig wechselnde von stabilen Attributen getrennt, was unnötigen Speicherverbrauch vermeidet, wenn sich beispielsweise nur ein einzelnes Attribut häufig ändert.
Die Aufteilung nach Quellsystem sowie die technisch motivierte Aufteilung nach Änderungsrate sind gängige und empfohlene Verfahren für die Handhabung beschreibender Attribute. Letztere ist allerdings nicht zwingend erforderlich, wenn in der Datenbank sogenannte Page Compression aktiv ist. Wir haben uns dennoch entschieden, die Rohdaten sowohl technisch als auch fachlich (nach geschäftlicher Bedeutung) weiter aufzuteilen.
Im Rahmen unseres Vorgehens reichen die Sicherheitsstufen von:
- Der niedrigste Vertraulichkeitsstufe – Stufe 0, 1: keine Sicherheitsmaßnahmen erforderlich, für öffentliche Daten
- Eingeschränkter Zugriff für bestimmte interne Parteien - Stufen A, R, C, F.
- Bis zur höchsten Vertraulichkeitsstufe – Stufe S: streng vertraulich bzw. „Top Secret“
Im nächsten Schritt werden die Rohdaten durch eine geschäftsorientierte Aufteilung in separate Satellitentabellen verteilt – basierend auf der fachlichen Bedeutung des jeweiligen Dateninhalts.
Zu diesem Zweck haben wir mehrere Klassifikationen definiert, darunter zum Beispiel „Kontakt“ für Kontaktdaten und „Aktivität“ für Daten, die Nutzerinteraktionen mit dem Quelldatensatz erfassen.
Darüber hinaus können Datenmodellierer auch benutzerdefinierte Klassifikationen für spezifische fachliche Bedeutungen innerhalb von Geschäftsobjekten definieren.
Beispielsweise werden alle Datenattribute einer Anwendung, die auf der CRM-Plattform Salesforce installiert ist, häufig in einer einzigen Satellitenstruktur gespeichert. Der Hauptvorteil geschäftsorientierter Satelliten besteht darin, dass sich Anwendungen hinzufügen oder entfernen lassen, ohne dabei erhebliche strukturelle Änderungen am EDW vornehmen zu müssen.
Setzt man alles zusammen, ergibt sich zum Beispiel folgender Satellitenname in unserer internen EDW-Lösung::
customer_contact_sfdc_lcp_s
Das oben genannte Objekt ist ein Satellit des Geschäftsobjekts „Kunde“ (Customer) und enthält die Kontaktinformationen von Kunden aus dem Quellsystem Salesforce. Seine Inhalte weisen eine niedrige Änderungsrate auf, unterliegen der Sicherheitsstufe C und enthalten personenbezogene Daten.
Fazit
In diesem Blogbeitrag haben wir die Data Vault -Entität „Satellit“ vorgestellt und unsere grundlegenden Empfehlungen zur Aufteilung eines Satelliten auf verschiedene Arten sowie deren jeweilige Vorteile erläutert. Außerdem haben wir zusätzliche Aufteilungsmöglichkeiten vorgestellt, die bei Scalefree auf Grundlage der Quelldaten angewendet werden. Im nächsten Blogbeitrag werfen wir einen genaueren Blick auf die Satellitenmodellierung im Hinblick auf strukturelle Änderungen im Quellsystem.
- von Samatha Balla (Scalefree)