Implementierung von Data Vault 2.0 Zero Keys
Erfahren Sie mehr über Zero Keys, "das andere" Konzept, das oft mit Ghost Records gleichgesetzt wird und das wir in einem vorherigen Blogbeitrag diskutiert haben.
In diesem Artikel:
Warum Zero Keys implementieren?
Wie in dem vorherigen Teil dieser Reihediskutiert, ist ein Ghost Record ein Dummy-Datensatz in Satelliten-Entitäten, der Standardwerte enthält. Einfach ausgedrückt sind Zero Keys der Eintrag in jeder Hub- und Link-Entität, der ein Gegenstück zum Ghost Record des Satelliten ist und dessen Hash-Schlüssel enthält. Auf diese Weise wird der Begriff "Zero Key" oft verwendet, um den Hash Keyeines Ghost Records zu beschreiben, der auch bei anderen Data Vault-Entitäten auftreten kann, wie etwa bei Point-in-Time (PIT)-Tabellen oder Links. Zusammen mit dem Zero Hash Key wird, ähnlich wie bei einem Ghost Record, ein Standardwert für den Geschäftsschlüssel angegeben. Oder, im Falle eines zusammengesetzten Geschäftsschlüssels, mehrere Standardwerte für jede seiner Komponenten.
Mit dem Hub- und Link-Eintrag für den Zero Key hat dann jeder Eintrag in seinem zugehörigen Satelliten einen übergeordneten Hash-Schlüssel, wodurch sogenannte verwaiste Hash Keys vermieden werden.
Wie sieht ein Zero Key aus?
Unter Data Vault 2.0, ist es nur erforderlich, einen einzigen Ghost Record in jeden Satelliten einzufügen. Es ist jedoch möglich, dass mehrere Zero Keys vorhanden sind. Bei Scalefree intern und in vielen unserer Projekte unterscheiden wir zwei Arten von fehlenden Objekten durch unterschiedliche Zero Keys in Hubs.
Bitte beachten Sie, dass der verwendete Hash-Algorithmus MD5 ist:
- 00000000000000000000000000000000 (32-mal die Ziffer '0') für allgemeine "unbekannte" Fälle, in denen ein Geschäftsschlüssel fehlt.
- ffffffffffffffffffffffffffffffffffffff (32 Mal der Buchstabe "f"): ein spezieller Zero Key für das "fehlerhafte" Fehlen von Business Keys.
Ein gutes Beispiel für die Verwendung des "Fehler"-Nullschlüssels ist eine fehlerhafte oder defekte obligatorische Objektbeziehung in der Quelle. In diesem Fall wird der Zero Key ffffffffffffffffffffffffffffffffffffff in der Link-Entität gefunden werden, was auf eine unerwartet fehlende Hub-Referenz hinweist. Sollten Sie sich für die Implementierung des Fehler-Zero Keys entscheiden, ist es nicht erforderlich, einen Ghost Record mit dem Fehler-Zero Key als übergeordneten Hash-Schlüssel in Satellitenentitäten einzufügen.
Was den Zero Key in Link-Entitäten betrifft, so ist nur ein Eintrag erforderlich, der den Zero Key sowohl als Link-Hash-Schlüssel als auch als Hub-Referenz enthält.
Es ist auch wichtig, darauf hinzuweisen, dass alle Beispiele, die wir in dieser Blogserie anführen, den Hash-Algorithmus MD5 verwenden, der 32-hexadezimale Ziffernfolgen ausgibt. Bei Data Vault 2.0-Projekten, die andere Hash-Algorithmen wie SHA256 verwenden, ändern Sie einfach die Länge der von uns vorgeschlagenen Nullschlüssel ("0000..." / "ffff...") auf die gewünschte Hash-Ausgangslänge.
Fazit
Wir hoffen, dass dieser Blogbeitrag dazu beigetragen hat, die Implementierung von Zero Keys in einer Data Vault 2.0-Lösung und die Unterschiede zwischen den Konzepten von Ghost Records und Zero Keys zu verdeutlichen. Teilen Sie uns Ihre Erfahrungen mit der Implementierung dieser Konzepte in den Kommentaren unten mit!
- von Trung Ta (Scalefree)
Before hashkeys became a thing I used the Kimball error codes as surrogate keys for precisely this purpose. It allowed us to monitor the movement from records with missing keys, into complete records (a case of late arriving keys, usually) and also enabled us to set reporting on the volume of active satellite records for the “missing key” hub item. This was supposed to stay under a certain level, because otherwise the load had probably not loaded all it should have been loading.
Hello Ronald,
Thank you for sharing the neat idea!
Cheers!
Trung
Thanks for this article. Very informative!
Would like to ask how would you handle incase of composite business key?
Let’s say a composite business key with 3 columns in a hub. Bk1 + Bk2 + Bk3
If the value of all of the 3 business keys comes as Null from source, then ofcourse, i think can apply the replacement for all 3 to be (unknown) or (error).
How about if only part of bk comes null?
Bk1 =123
Bk2=abc
Bk3=NULL
What i can think of is that
Replace Bk3 with (unknown) and put it as part of normal hash process
Any thoughts on this?
Hi Nikunj,
in case of composite business key:
– If the source delivers all BK parts with NULL values, then it is quite clearly that the BK is simply missing, which is a case for ‘(unknown)’ and the 0000 zero key. You can argue that for example a master data record must not miss the BK, and you’d be right – in that case, we recommend writing this record to an Error mart, and you’ll have to handle this record separately. Either way, that record will not be inserted into the target Hub and Satellite, as your loading pattern should deny zero keys from incoming data feed.
– If the source delivers one/some part(s) with NULL values, then the business key is erroneous, meaning even in the source, the business key you’d expect cannot be fully constructed as per your BK definition. In that case, you can ouput ‘(error)’ as default value and the ffff zero key to indicate the fact that the business key was not delivered properly.
Hope this helps – let us know if we can assist you further on this!
Trung Ta