Kriterien f\u00fcr das Satellite<\/a>-Splitting spielen eine entscheidende Rolle f\u00fcr die Struktur eines Satelliten. Daher wird davon abgeraten, s\u00e4mtliche beschreibenden Daten<\/a> zu einem Business Key in einer einzigen Satellite-Struktur zu speichern. Stattdessen sollten Rohdaten vorzugsweise nach bestimmten Kriterien aufgeteilt werden. <\/span><\/p>\n In this article:<\/p> <\/p>\n Im Allgemeinen haben wir die folgenden Arten von Satellite-Splits definiert:<\/span><\/p>\n Dar\u00fcber hinaus haben wir zwei weitere Arten von Splits definiert:<\/span><\/p>\n Eine Aufteilung des Satelliten nach Quellsystem wird dringend empfohlen, um zwei wesentliche Probleme beim Laden der Daten in das Enterprise Data Warehouse<\/a> zu vermeiden: Wenn erstens zwei verschiedene Quellsysteme mit unterschiedlichen relationalen Strukturen in dieselbe Satellite-Entit\u00e4t geladen werden sollen, ist m\u00f6glicherweise eine Transformation der Struktur erforderlich. Eine solche strukturelle Transformation erfordert jedoch fr\u00fcher oder sp\u00e4ter Gesch\u00e4ftslogik (Business Logic). Diese sollte auf die Information-Delivery-Schicht verschoben werden, um vollst\u00e4ndig revisionssichere Umgebungen sowie die Anwendung mehrerer Gesch\u00e4ftsperspektiven zu unterst\u00fctzen. <\/span><\/p>\n Das zweite Problem besteht darin, dass das Laden von zwei Quellen in dieselbe Satellite-Entit\u00e4t zum sogenannten \u201eFlip-Flop-Effekt\u201c f\u00fchrt: Wenn beide Systeme widerspr\u00fcchliche Daten (z. B. asynchron oder nicht synchronisiert) bez\u00fcglich des zu beschreibenden Business Keys speichern, nimmt der Satellit zwei Deltas pro Tag auf und erfasst beide Beschreibungen. Dies f\u00fchrt zu einem hohen Speicherverbrauch und zu Dateninkonsistenzen. Daher hilft die Aufteilung eines Satelliten nach Quellsystem dabei, den Speicherverbrauch drastisch zu reduzieren. <\/span><\/p>\n Zu den Vorteilen der Aufteilung von Satelliten nach Quellsystem geh\u00f6rt auch die Verbesserung der Parallelisierung: Daten aus mehreren Quellsystemen k\u00f6nnen parallel geladen werden. Zudem erm\u00f6glicht dieser Ansatz die Integration von Echtzeitdaten<\/a>, ohne dass eine vorherige Abstimmung mit den Rohdaten aus einem Batch-Ladevorgang erforderlich ist. <\/span><\/p>\n Zus\u00e4tzlich zum Split nach Quellsystem kann der Speicherverbrauch weiter reduziert werden, indem der Satellit nach der \u00c4nderungsrate aufgeteilt wird:<\/span>[\/vc_column_text][divider line_type=“No Line“][image_with_animation image_url=“29601″ image_size=“medium_large“ animation_type=“entrance“ animation=“None“ animation_movement_type=“transform_y“ hover_animation=“none“ alignment=“center“ border_radius=“none“ box_shadow=“none“ image_loading=“lazy-load“ max_width=“75%“ max_width_mobile=“100%“][vc_column_text]\n Abbildung: Mehrere Satelliten (aufgeteilt nach Quellsystem) h\u00e4ngen von einem Hub ab<\/span><\/i><\/p>\n[\/vc_column_text][divider line_type=“No Line“][vc_column_text css=““ text_direction=“default“]Um einen Satelliten basierend auf der \u00c4nderungsrate aufzuteilen, wird die \u00c4nderungsh\u00e4ufigkeit aller Attribute bestimmt. Anschlie\u00dfend werden die Daten nach ihrem \u00c4nderungsverhalten gruppiert: solche, die sich nie \u00e4ndern, solche, die sich gelegentlich \u00e4ndern, und solche, die sich sehr h\u00e4ufig \u00e4ndern. Das Aufteilen eines Satelliten nach der \u00c4nderungsrate trennt sich schnell \u00e4ndernde Attribute von sich langsam \u00e4ndernden Attributen. Dies verhindert unn\u00f6tigen Speicherverbrauch, wenn sich ein dynamisches Attribut aktualisiert. <\/span><\/p>\n Der Satellite-Split nach Quellsystem sowie der technische Split nach der \u00c4nderungsrate der Daten (der bei aktivierter Seitenkomprimierung in der Datenbank eventuell entfallen kann) sind g\u00e4ngige und empfohlene Praktiken bei der Aufteilung beschreibender Attribute. Wir haben uns jedoch daf\u00fcr entschieden, Rohdaten sowohl aus technischer Sicht als auch nach ihrer fachlichen Bedeutung noch weiter aufzuteilen. <\/span><\/p>\n Im Rahmen unseres Prozesses gliedern sich die Sicherheitsstufen wie folgt:<\/span><\/p>\n Dar\u00fcber hinaus verteilt die fachlich getriebene Aufteilung (Business-driven Satellite Split) die Rohdaten unter Nutzung spezifischer fachlicher Bedeutungen des Dateninhalts auf verschiedene Satellite-Tabellen.<\/span><\/p>\n F\u00fcr diesen Zweck haben wir verschiedene Klassifizierungen definiert, wie etwa \u201eContact\u201c f\u00fcr Kontaktdaten oder \u201eActivity\u201c f\u00fcr Daten, die Nutzerinteraktionen mit dem Datensatz des Quellsystems nachverfolgen.<\/span><\/p>\n Zudem k\u00f6nnen Datenmodellierer benutzerdefinierte fachliche Klassifizierungen f\u00fcr spezifische, eindeutige Bedeutungen innerhalb von Gesch\u00e4ftsobjekten (Business Objects) festlegen.<\/span><\/p>\n Beispielsweise werden h\u00e4ufig alle Datenattribute einer Anwendung, die auf der CRM-Plattform Salesforce<\/a> installiert ist, in einer einzigen Satellite-Struktur gespeichert. Der Hauptvorteil von Business-driven Satellites besteht darin, dass sich Apps flexibel hinzuf\u00fcgen oder entfernen lassen, w\u00e4hrend die Auswirkungen von Struktur\u00e4nderungen auf das EDW auf ein Minimum reduziert werden. <\/span><\/p>\n Zusammenfassend zeigt das folgende Beispiel die Benennung eines Satelliten in unserer internen EDW<\/a>-L\u00f6sung:<\/span><\/p>\n customer_contact_sfdc_lcp_s<\/span><\/i><\/p>\n Bei dem obigen Beispiel handelt es sich um einen Satelliten eines Gesch\u00e4ftsobjekts namens \u201eCustomer\u201c, der die Kontaktinformationen von Kunden aus dem Quellsystem Salesforce enth\u00e4lt. Sein Inhalt weist eine geringe \u00c4nderungsrate sowie die Sicherheitsstufe C auf und umfasst personenbezogene Daten. <\/span><\/p>\nKriterien f\u00fcr das Aufteilen eines Satelliten<\/h2>\n
\n
\n
\n
Fazit<\/span><\/h2>\n