Üzleti és technikai historizáció az adattárházakban

Az adattárházakban historizáltan tároljuk az adatokat. Ez azt jelenti, hogy ha egy vevőnek megváltozik a címe, akkor felülírás helyett eltároljuk, hogy mettől meddig lakott Tatabányán és mettől meddig Miskolcon.

A kérdés csak az, hogy az új címe mikortól érvényes? Attól az időponttól, amikor betöltöttük a vevő rekordokat az adattárházba (mondjuk reggel 05:30), vagy akkortól amikor a vevő rekordja megváltozott a forrásrendszerben (tegnap 15:36)

Kézenfekvőnek tűnik, hogy 15:36-tól, hiszen ez sokkal jobban közelíti a valóságot, mint a reggel 05:30, amikor az változást az adattárház észrevette. Kit érdekel, hogy mikor került az adattárházba? Az a fontos, amikor megváltozott. Nem?

Hááát, attól függ, hogy mi a célunk a historizációval…

• Ha elemzői céllal építjük az adattárházat, akkor a változás tényleges dátuma lesz a fontos, ez dátum lesz a historizáció alapja (15:36)
• ha auditálható adattárházat szeretnénk, azaz ha egy tavaly előállított mutatószámot ismét elő kell tudnunk állítani más bontásban is, akkor a bekerülés dátuma lesz a fontos (05:30). Pénzintézeteknél, biztosítóknál ez alapkövetelmény, náluk a bekerülés dátumát használjuk a historizációhoz.

De miért bukjuk az auditálhatóságot, ha az üzleti dátumot (változás dátumát) használjuk a historizációhoz?

• Késve kapjuk az adatokat: Ha egy extraktumot késve kapunk, azaz később érkezik meg egy korábbi extraktum, akkor az abban szereplő változás dátumát be kell szúrnunk visszamenőleg a históriába, ami odavág az auditálhatóságnak. (Visszamenőleges történelemhamisítás)
• A dátum nem pontos: Ha lemerül az IoT eszköz eleme és elemcsere után elfelejtik beállítani az órát, vagy rosszul állítják be, akkor azt vesszük majd észre, hogy évekkel korábbi események jönnek a rendszerbe… A probléma ugyanaz mint a késve érkező adatoknál: megváltoztatjuk a múltat.
• Óraátállítás (téli/nyári időszámítás): Ha a forrásrendszerben az óra visszaállítás idejében történik a változás, akkor az későbbi esemény megelőzheti a korábbit.
• Javítás, korrekció, újratöltés: Ezt csak a múlt felülírásával tudjuk megoldani…

Mindezek miatt, ha auditálható adattárházat szeretnénk, akkor a beérkezés dátuma alapján kell historizálnunk. Ha nem fontos az auditálhatóság, akkor historizálhatunk üzleti dátum alapján is. Ha pedig egyszerre szeretnénk auditálható és elemzői céllal is használható adattárházat, akkor kétrétegű architektúrát építünk:

• Az alsó réteget technikailag historizáljuk (Auditálható réteg)
• a felső réteget üzletileg historizáljuk. (Elemzői réteg)

Nagyvállalati szinten ma már szinte kizárólag ilyen kétrétegű architektúrákat tervezünk. Ennek legfőbb oka, hogy az alsó, technikailag historizált réteg lefejlesztése a big data hozta technológiákkal egyre gyorsabb, egyszerűbb és olcsóbb...