Modellierung eines Satelliten im Falle struktureller Veränderungen innerhalb des Quellsystems
Over time, a source system can change. The question is how to absorb these changes into a Data Vault 2.0 data warehouse, especially when considering the satellites?
It is necessary to find a balance between the reengineering effort and performance when the source table structure changes. To better help those who find structural changes in the source system, this article will present our recommendations, based upon our knowledge base, for various types of changes in a source.
This article describes features embodied in the Data Vault 2.0 model: the foundation of hub, link, and satellite entities can adjust to changes in the source data easily, thus reducing the cost of reengineering the Enterprise Data Warehouse.
In diesem Artikel:
New columns in the source system: when any new columns or attributes are added to the source
Es gibt zwei Möglichkeiten, neue Attribute von der Quelle in den data warehouse zu übernehmen. Erstens könnte der bestehende Satellit geändert werden.
Dies ist ein pragmatischer Ansatz, der jedoch die Änderung von bestehendem Code erfordert.
Andererseits ist es auch möglich, einen neuen Satelliten für das neue Attribut bzw. die neuen Attribute zu erstellen, ohne die bestehenden Satelliten zu ändern. Dies hat den Vorteil, dass es keine Auswirkungen auf den Code hat, erfordert aber mehr Verbindungen in einem Teil des Data Vault für die Informationsübermittlung.
Bei der ersten Option ist diese Verknüpfung nicht erforderlich, da das neue Attribut dem vorhandenen Satelliten hinzugefügt wird. Am besten ist es, die Vor- und Nachteile der beiden Optionen in der jeweiligen Situation zu vergleichen, wie sie auf Ihre Situation zutrifft. Automatisierungswerkzeuge beispielsweise können die Anweisung "alter table" in der Regel automatisch und ohne manuellen Codierungsaufwand verarbeiten, erfordern aber Änderungen in der Datenbank.
Removing columns in the source system from source column deletion
Eine Möglichkeit ist, den "alten" Satelliten zu schließen, d.h. nicht weiter zu laden, da die ETL Code ausgeschaltet ist, und einen neuen Satelliten erstellen, der geladen werden soll. Der gleiche Ansatz wird verwendet, wenn die zugrunde liegenden Datenstrukturen aus der Quelle in einer größeren Perspektive geändert werden.
Alte Satelliten werden abgeschaltet, neue Satelliten mit der neuen Struktur werden dann geladen.
Eine andere Option wäre sinnvoller, wenn nur geringfügige Änderungen erforderlich sind, z. B. das Entfernen einer Spalte. Dann wäre das "Simulieren" dieser Spalte mit einem NULL-Wert oder einem Wert, der mehr Sinn ergibt, für Prüfungszwecke hilfreicher.
Wenn ein neuer Satellit erstellt wird, ergeben sich daraus zwei neue Spalten in der zugehörigen PIT-Tabelle (Hash Key + LDTS).
Das Schließen eines Satelliten und das Anlegen eines neuen Satelliten ist auch bei größeren Änderungen im Quellsystem möglich, z. B. bei einer neuen Release-Version des Quellsystems, bei der Spalten gelöscht, umbenannt und neu angelegt werden. Bei kleinen Änderungen, insbesondere wenn Spalten verschwinden, empfiehlt es sich, den Satelliten zu ändern.
Creating a Virtual Dimension table from a PIT table having multiple satellites
When a new satellite for the new attribute, or attributes, is created by not modifying the existing satellite, a new virtual dimension is required to fetch information from PIT tables using both the satellites accordingly based on the required timestamp.
Es gibt zwei Ansätze, wie die Informationen aus den beiden Satelliten gewonnen werden können:
- Der erste Ansatz verwendet einen berechneten Satelliten, bei dem Sie alle Satelliten mit dem jüngsten Datensatz pro Hash Key und derselben Struktur kombinieren. Dies kann jedoch eine komplizierte Abfrage sein, da sie von der Menge der Daten und der Anzahl der zu verbindenden Satelliten abhängt.
- Der zweite Ansatz besteht darin, eine PIT-Tabelle für alle Satelliten zu verwenden und bei der Abfrage der Daten, z. B. für eine Dimensionstabelle, den Datensatz des führenden Satelliten zu nehmen, z. B. mit einer IIF-Anweisung oder COALESCE Funktion.
Schlussfolgerung
Auch wenn jede Situation einen Ansatz erfordert, der die individuelle Natur der Aufgabe berücksichtigt, haben sich die oben genannten Lösungen bei der Umsetzung in unseren eigenen Projekten als unerlässlich erwiesen.
Wir bieten sie an, damit auch andere von dem profitieren können, was wir durch unsere Tests, Anwendung und Umsetzung gelernt haben.
Fragen? Kommentare? Wir würden uns freuen, von Ihnen zu hören!