Data Vault 2.0 Pitfalls

Ik ben een grote fan van het toepassen van Data Vault bij organisaties. Vooral Data Vault 2.0. Binnen mijn 5 jaar Data Vault-ervaring heb ik gemerkt hoe dit framework organisaties helpt om op te schalen wanneer de vraag groeit (zonder technische schulden te creëren). Vooral de kracht van het gebruik van automatiseringstools en het berekenen van tijdlijnen verkort de time-to-market en verwijdert de datalogistiek en afhankelijkheden. Dus, is er een keerzijde aan al dit voordeel? Ja dat is er…

Tijdlijnen zijn een belangrijk aspect van een datawarehouse. Ze vormen de hoeksteen van de historisering van beschrijvende gegevens. Binnen Data Vault 2.0 worden de tijdlijnen niet afgehandeld door een invoeg- en updateproces, maar worden ze berekend op basis van de volgende laaddatum (batch) die het Data Warehouse heeft ontvangen. Maar hoe zit het met verwijderingen in bronsystemen? Dit is geen eigenschap die is ingesteld bij het laden van de gegevens in de gegevenskluis.

De grote vraag is; Moet u verwijderingen afhandelen wanneer Data Vault elke wijziging verwerkt als een invoeging in de Raw Vault?

Binnen het Data Vault 2.0 framework wordt de “Last Seen Date” beschreven als een methode om verwijderingen van records binnen bronsystemen te detecteren. Deze methode vult een optioneel datumveld (LastSeenDate) in de hub-entiteit en maakt deel uit van de Raw Vault. Deze methode om dit datumveld in te vullen resulteert niet in een gesloten tijdlijn (bijgewerkte einddatum) in het Enterprise Data Warehouse (EDW) wanneer de bedrijfssleutel uit de bron wordt verwijderd.

De grote vraag is; Moet u verwijderingen afhandelen wanneer Data Vault elke wijziging verwerkt als een invoeging in de Raw Vault? Dit artikel beschrijft verschillende aspecten van verwijderingsdetectie en het patroon dat kan worden toegepast op de Raw Vault om er zeker van te zijn dat u een gesloten tijdlijn heeft in het Enterprise Data Warehouse.

Wat is een verwijderingsdetectie?

Verwijderingsdetectie is het patroon waarbij een verwijderde bedrijfssleutel uit het bronsysteem wordt gemarkeerd terwijl het record nog beschikbaar is in het datawarehouse. In het traditionele Kimball Data Warehouse zal dit resulteren in een update van het veld “EndDate” dat de afsluitende data van de levenscyclus van een record beschrijft.

Het draait allemaal om vereisten

Waarom zou u de records in uw datawarehouse sluiten? Wat is de waarde van het sluiten van een tijdlijn van een klant, product of referentie als dit record niet bestaat in de bron? Voegt dit proces waarde toe aan uw corebusiness of klantbeleving? Het antwoord is ja … Het verbetert niet alleen de kwaliteit van de historische gegevens. Klanten of producten die uit de bronsystemen zijn verwijderd, worden bijvoorbeeld niet weergegeven in uw rapport van de huidige datum. De klant bestaat alleen in die periode.

Regelgevers en controleerbaarheid

Vanuit het oogpunt van regelgeving en controleerbaarheid is het alleen nodig om de verschillende berekening van de verschillende tijdstippen te reproduceren. Dat betekent dat u de verschillende belastingen die u van de bronnen ontvangt, moet historiseren en de verschillende bedrijfsregels die u op de gegevens toepast, moet historiseren.

Wat betekent dat volgens de verwijderingsdetectie? Dit betekent dat u alleen een referentie nodig heeft wanneer u gegevens heeft ontvangen van het bronsysteem (LoadDate) en de verschillende versies van de zachte bedrijfsregels die u hebt toegepast en dat het niet nodig is om de verwijderingen vast te leggen.

Oplossing voor verwijderingsdetectie in Data Vault 2.0 (Full Loads)

Een groot voordeel van het gebruik van Data Vault 2.0 is dat het geen records in de Raw Vault bijwerkt, wat resulteert in een goed presterende historische kluis. Het patroon dat wordt beschreven volgt die regel en daarom behouden we hetzelfde voordeel. De enige beperking voor dit patroon is dat dit alleen telt als u een volledige kopie van de brontabellen heeft ontvangen.

Voor de delete-detectie voegen we een extra metaveld toe aan de satelliet genaamd “isDeleted”.

Standaardgedrag

Stel eerst de standaard binding in de satelliet voor het veld “isDeleted” in op “N”. Dit geeft aan dat elke reguliere wijziging resulteert met de waarde “N” in dit veld. De betekenis van de waarde “N” legt uit dat het record niet in de bron wordt verwijderd.

Detectie verwijderen

Om verwijderingen te detecteren, vergelijken we de volledige kopie van de bron (staging) met de records die in Enterprise Data Warehouse bestaan. Wanneer er verwijderingen zijn in de bron, is het resultaat (delta) van de vergelijking de ontbrekende bedrijfssleutels in de bron

We voegen een nieuw record in op basis van het bovenstaande patroon met het veld “isDeleted” ingesteld op “Y” en zetten alle andere velden leeg. Figuur 2 toont het resultaat van deze oplossing.

Effectieve satelliet

De effectieve satelliet is de virtuele vervanging van de Type 2-dimensie in het traditionele datawarehouse. Figuur 2 laat zien dat de tijdlijnen worden berekend met de analytische functie (lead) om de volgende laaddatum van een bedrijfssleutel te kiezen. Het voordeel van het berekenen van de tijdlijn in plaats van fysiek onderhoud zijn:

1. Historisatie is 100% invoeging en dus lichtgewicht transacties in de database
2. Een tijdlijn is een berekening en wordt uitgevoerd door het Data Warehouse en bestaat niet fysiek
3. Geen lastafhankelijkheid
4. Geen planning voor ladingen

Conclusie

Het traditionele datawarehouse en de Data Vault bieden geen ondersteuning voor deletes out of the box. Dit betekent dat het niet wordt beschreven en dat we er meestal niet genoeg aandacht aan hebben besteed. Als u verwijderingen niet afhandelt, kunt u een onnauwkeurig beeld krijgen wanneer u in de tijd reist omdat uw rapport uw datamart in beslag neemt.

Wilt u een modern Data Warehouse hebben waarbij verwijderingen als een insert behandelt worden, zonder update-statements? Gebruik dan de insert-methode samen met een effective satelliet.