In this article we will show you how to use counter records for change or delete practices in Data Vault 2.0. In January of this year, we published a piece detailing einen Ansatz für die Handhabung von Löschungen und Änderungen von Geschäftsschlüsseln in Data Vault, ohne dass ein Prüfpfad vorhanden ist.
This approach is an alternative to the Driving Key structure, which is part of the Data Vault standards and a valid solution.
Allerdings kann es manchmal schwierig sein, die Geschäftsschlüssel in einer Beziehung zu finden, die sich nie ändern und daher als Ankerschlüssel, Link Driving Key, bei Abfragen verwendet werden. Die vorgestellte Methode fügt Zählerdatensätze für geänderte oder gelöschte Datensätze ein, insbesondere für Transaktionsdaten, und ist ein unkomplizierter und pragmatischer Ansatz. Der Artikel hat jedoch eine Menge Fragen, Verwirrung und Unstimmigkeiten hervorgerufen.
In diesem Blogpost wollen wir uns daher mit der technischen Umsetzung befassen, die wir durch den Einsatz des Systems verbessern könnten.
In diesem Artikel:
Technical Implementation in Data Vault 2.0
Die folgende Tabelle zeigt eine leicht veränderte Zielstruktur des Links vom vorheriger Blogpost when using counter records in Data Vault 2.0.
In diesem Fall konzentrieren wir uns auf Transaktionen, die vom Quellsystem geändert wurden, ohne dass die Quelle selbst Prüfdaten über die Änderungen und Gegenbuchungen liefert.
It is important to note that the link stores the sales positions by referencing the customer and the product. Thus, the Link Hash Key as well as the Load Date are the primary keys as we are not able to gather a consistent singular record ID in this case. Being so, the Link Hash Key is calculated by the Customer Business Key, the Product Business Key, the sales price and the transaction timestamp.
Abbildung 1: Verknüpfung mit Zählersätzen
Um den Link zu laden, sind die folgenden Schritte erforderlich:
Fügen Sie zunächst ein und prüfen Sie, ob eine Zählerbuchung überhaupt notwendig ist, da im ersten Schritt neue Daten aus dem Staging-Bereich in den Link geladen werden. Bitte beachten Sie, dass die Ladelogik in diesem Schritt derjenigen des Standard-Ladevorgangs für Links ähnelt, mit einigen Unterschieden:
Abbildung 2: Einfüge-Logik
In Data Vault 2.0, the counter record should identify records, the most recent records by Link Hash Key, that exist in the link but don’t exist in the staging area due to deletion or changes made to record. Thus, query results will be “countered” with a value for “counter” set to -1, which indicates that these records are not able to be found in this stage. Note that in this query we selected the existing record from the link table in the raw vault, however, further note that the record’s time of arrival should be the LDTS of the actual staging batch. Therefore, within the shown statement, the LDTS is a variable with the load date of the staging batch:
Abbildung 3: Zählerlogik
In den Fällen, in denen er zum ursprünglichen Datensatz zurückkehrt, gilt das gleiche Verfahren: Der aktuelle fehlende Wert wird durch den neuen ersetzt, der wiederum mit einem neuen LDTS eingefügt wird.
Schlussfolgerung
Thus, we can conclude that this Data Vault approach works well for tables which are a hot-spot for measured values only as well as when changes are possible, although the data represents “transactions” and is to be used when CDC is not available.
Instead of a “get the most recent record per Hash Key (Driving Key)” it is possible to run calculations as well as aggregations directly on one table which results in a better performance in the end stage.
Falls noch Fragen offen sind, können Sie gerne einen Kommentar hinterlassen.
Wir freuen uns auf einen Austausch und Ihre Gedanken zu diesem Thema.
Updates und Support erhalten
Bitte senden Sie Anfragen und Funktionswünsche an [email protected].
Für Anfragen zu Data Vault-Schulungen und Schulungen vor Ort wenden Sie sich bitte an [email protected] oder registrieren Sie sich unter www.scalefree.com.
Zur Unterstützung bei der Erstellung von Visual Data Vault-Zeichnungen in Microsoft Visio wurde eine Schablone entwickelt, mit der Data Vault-Modelle gezeichnet werden können. Die Schablone ist erhältlich bei www.visualdatavault.com.
Tut mir leid, wenn ich es vielleicht zu sehr vereinfache, aber mir scheint, dass das Grundproblem darin besteht, dass man nicht wirklich eine Identität für die Zeilen hat, so dass man sie einfach als Ganzes behält oder entfernt.
Sie erstellen vollständige Zeilenschlüssel, indem Sie so gut wie die gesamte Zeile mit einem Hashwert versehen und prüfen, was sowohl im Stadium als auch im Ziel (unverändert) vorhanden ist, was neu ist (einzufügen) und was verschwunden ist (zu löschen).
Dies (Zusammenführen von stage mit destination und picking where dest is null) ist das einzige Änderungsmanagementverfahren, das in diesem Fall zur Verfügung steht, da es keine CDC gibt und man davon ausgehen kann, dass eine Zeile, die in stage verschwindet, für immer verschwunden ist (oder geändert wurde, was dasselbe ist, wenn man keine stabile Identität hat).
Dann beschließen Sie, dass Sie, anstatt das Verschwinden einfach mit einem Status zu verfolgen (in einer Gültigkeitsliste oder auf eine andere Weise, um eine binäre Information zu erhalten), eine neue Zeile eingeben, die die Zeile ausgleicht, die in der Stufe verschwunden ist.
Das gleicht natürlich nicht alles aus, sondern funktioniert hauptsächlich für Summen. Z.B. sind die Zählungen und Durchschnitte kaputt, es sei denn, sie werden mit komplexeren Regeln berechnet, um die gelöschten und ihre gegnerischen Freunde zu entfernen.
Während dies bei ereignisbasierten Systemen ein wohlbekanntes Muster ist (da man einen autorisierten Kreditkartenkauf oder ein Flugticket nicht löschen kann), bei dem die Semantik des Ereignisses und seiner Umkehrung von den Anwendungen verwaltet wird, die die erforderliche Logik einbetten, sehe ich viele Komplexitäten bei der Verwendung für BI, da BI-Tools alles andere als gut darin sind, eine nicht triviale Geschäftslogik anzuwenden (geschweige denn, dass ihre Geschäftsanwender sie kodieren können).
Daher sehe ich dies als eine praktische Lösung für ein sehr spezifisches Problem und eine sehr spezifische Art der Nutzung dieser Informationen. Keine allgemein nützliche Lösung für BI.
Ein Beispiel: Wenn einer Ihrer BI-Anwender versuchen würde, den Durchschnittspreis zu berechnen, käme er auf 500 statt auf 1500 (und doppelt so viel Glück, wenn er einem BI-Tool beibringen könnte, wie man das richtig berechnet).
Ich würde gerne wissen, was Sie darüber denken, und vor allem, ob dieses Muster generell für die Erstellung von "fertigen" BI-Tabellen geeignet ist.
BR, RZ
Hallo Roberto,
Marc hier von Scalefree.
Der Hauptgrund für diese Vorgehensweise ist die Leistung, um die zusätzliche Verknüpfung mit einem Gültigkeits-Satelliten (der deltabasiert ist) zu vermeiden, und sie funktioniert am besten, wenn man mit gemessenen Daten arbeitet. Denken Sie daran, dass dies immer noch Teil des Raw oder Business Vault ist. BI-Benutzern (nicht Power-Usern) können und sollten Sie einen (virtualisierten) Information Mart zur Verfügung stellen, in dem die Durchschnittslogik bereits angewendet wird, in diesem Fall durch Division durch eine bestimmte Zahl des Kunden-Hash-Schlüssels. In anderen Fällen, insbesondere wenn Sie beispielsweise mit vielen Zeichenketten arbeiten, ist der Effektivitätssatellit in der Regel die bessere Lösung. Bedenken Sie auch, dass dieser Ansatz die "Datenalterung" außer Acht lässt. Es handelt sich um Maßnahmen, die zwar einen Transaktionscharakter haben, aber nicht aus einer technischen/lieferungsbezogenen Perspektive.
BR
Marc Finger
Die Lösung für Zähler oder Durchschnitt ohne Verwendung des Operators distinct ist zu einfach @Roberto Zagni.
Wir graben sie nur ein wenig tiefer.
für Zähler Kunde: Anzahl der Kunden = [count(Kunde) mit Zähler = 1] - [count(Kunde) mit Zähler = -1] = 2 -1 = 1
für Zähler Produkt: Menge des Produkts= [count(Produkt) mit Zähler = 1] - [count(Produkt) mit Zähler = -1] = 2 -1 = 1
für den Durchschnittspreis pro Kunde: Summe(Preis)/Menge der Kunden = 1500/1 = 1
für den Durchschnittspreis nach Kunde: Summe(Preis)/Menge des Produkts = 1500/1 =1
Ich denke, dieses Muster von Marc Finger ist gut und wir können darüber nachdenken, wie wir es erweitern können, besonders in der Welt der großen Daten, einige Prozesse/Transformationen durchführen, um die Geschäftsfrage anzupassen.