DATA VAULTi areng ja üleminek BUSINESS DATA VAULT'ile

Eelnevas artiklis rääkisin DATA VAULT põhialustest, tutvustasin DATA VAULT peamisi elemente ja nende eesmärke. Kuid teema DATA VAULT ei ole veel ammendatud; on aeg rääkida DATA VAULT järgmiste arenguetappide üle.

Selles artiklis keskendun DATA VAULT arengule ja üleminekule BUSINESS DATA VAULT-ile ehk lihtsalt BUSINESS VAULT-ile.

BUSINESS DATA VAULTi tekkimise põhjused.

Pean märkima, et kuigi DATA VAULT'il on oma tugevused, pole tal ka puudusi. Üks selline puudus on keerukus analüütiliste päringute koostamisel. Päringud sisaldavad oluliste JOIN'ide arvu, mistõttu koodist saab pikk ja kohmakas. Samuti ei toimu DATA VAULT'i sattuvate andmete osas ühtegi transformatsiooni, seega ei oma DATA VAULT puhtal kujul äri seisukohalt absoluutselt väärtust.

Just nende puuduste kõrvaldamiseks on DATA VAULT metodoloogia täiendatud selliste elementidega nagu:

• PIT (point in time) tabelid;
• BRIDGE tabelid;
• PREDEFINED DERIVATIONS.

Vaatame lähemalt nende elementide eesmärke.

PIT tabelid.

Reeglina võib üks äriobjekt (HUB) sisaldada andmeid erineva värskendussagedusega. Näiteks, kui räägime inimesega seotud andmetest, võime öelda, et telefoninumbri, aadressi või e-posti kohta olev teave värskendatakse sagedamini kui näiteks nimi, passinumber, perekonnaseis või sugu.

Seetõttu tuleb satelliitide määramisel arvestada nende värskendussagedusega. Miks see on oluline?

Kui ühes tabelis hoida erineva värskendussagedusega atribuute, tuleb iga kord, kui kõige sagedamini muudetud atribuudi andmeid värskendatakse, tabelisse uus rida lisada. Selle tulemusena – suureneb kettaruumi maht ja suureneb päringute täitmise aeg.

Nüüd, kui oleme satelliidid värskendussageduse järgi jaganud ja saame andmeid neisse sõltumatult laadida, tuleb tagada võimalus saada ajakohaseid andmeid. Parema tulemuse saavutamiseks, ilma liigsete JOIN'ideta.

Selgitame näiteks, et tuleb saada ajakohast (viimase uuendamise kuupäeva järgi) teavet satelliitidelt, millel on erinev uuendamise sagedus. Selleks on vaja teha mitte ainult JOIN, vaid ka luua mitu sisemist päringut (igaühe jaoks, mis sisaldab teavet), valides maksimaalse uuendamise kuupäeva MAX(Uuendamise kuupäev). Iga uue JOIN-iga kasvab selline kood ja muutub kiiresti arusaamatuks.

PIT-tabel on mõeldud selliste päringute lihtsustamiseks, PIT-tabelid täidetakse samaaegselt uute andmete salvestamisega DATA VAULT’i. PIT-tabel:

Nii et meil on teave andmete asjakohasuse kohta kõigi satelliitide osas igal ajahetkel. Kasutades JOIN-e PIT-tabelile, saame täielikult välistada sisepäringud, tingimusel et PIT täidetakse iga päev ja ilma vahejuhtumiteta. Isegi kui PITis esinevad vahejuhtumid, on võimalik saada ajakohaseid andmeid ainult ühe sisemise päringu abil PITile endale. Üks sisemine päring töötab kiiremini kui sisemised päringud iga satelliidi kohta.

BRIDGE

BRIDGE-tüüpi tabeleid kasutatakse samuti analüütiliste päringute lihtsustamiseks. Siiski erineb see PIT-st, kuna see lihtsustab ja kiirendab päringuid erinevate keskuspunktide, linkide ja nende satelliitide vahel.

Tabel sisaldab kõiki vajalikke võtmeid kõigi satelliitide jaoks, mida sageli kasutatakse päringutes. Lisaks võivad vajadusel räsi (hash) ärivõtmed olla täiendatud tekstivormis võtmetega, kui võtmete nimetused on analüüsi jaoks vajalikud.

Asi on selles, et ilma BRIDGE'i kasutamiseta, kui saadakse andmeid, mis asuvad satelliitides, mis kuuluvad erinevatesse keskpunktidesse, tuleb teostada JOIN mitte ainult satelliitide vahel, vaid ka linkide vahel, mis seovad keskpunktid.

BRIDGE'i olemasolu või puudumine määratakse andmehoidla konfigureerimise ja päringute täitmise kiirusoptimeerimise vajaduse järgi. Üksnes ühtset BRIDGE'i näidet on raske välja mõelda.

EELNEVALT MÄÄRATUD TULETUSED

Veel üks objektide tüüp, mis viib meid lähemale BUSINESS DATA VAULT'ile, on tabelid, mis sisaldavad eelnevalt arvutatud näitajaid. Sellised tabelid on tõeliselt olulised äri jaoks, need sisaldavad teavet, mis on kokku koondatud määratud reeglite järgi ja võimaldavad sellele suhteliselt lihtsalt juurde pääseda.

Arhitektuursed PREDEFINED DERIVATIONS on mitte midagi muud kui veel üks satelliit teatud keskuses. See, nagu tavaline satelliit, sisaldab ärivõtme ja kirje loomise kuupäeva satelliidis. Sellega, siiski, sarnasused lõpevad. Sellise 'spetsialiseeritud' satelliidi atribuutide kogumit määratlevad ärikasutajad, tuginedes kõige nõutumatele, eelnevalt arvutatud näitajatele.

Näiteks, keskus, mis sisaldab teavet töötaja kohta, võib sisaldada satelliiti selliste näitajatega nagu:

• Minimaalne palk;
• Maksimaalne palk;
• Keskmine palk;
• Kogusumma arvestatud palgast jne.

On loogiline lisada PREDEFINED DERIVATIONS selle sama keskuse PIT-tabelisse, siis saab hõlpsasti saada andmeproovisid konkreetse kuupäeva kohta töötaja kohta.

KOKKUVÕTE

Praktika näitab, et DATA VAULT'i kasutamine ärikasutajate poolt on mitmel põhjusel veidi keeruline:

• Päringute kood on keeruline ja mahukas;
• Arvukus JOIN’e mõjutab päringute kiirus;
• Aanalüütiliste päringute kirjutamiseks on vajalik suurepärane teadlikkus andmehoidla struktuurist.

Andmete ligipääsu lihtsustamiseks laieneb DATA VAULT täiendavate objektidega:

• PIT (point in time) tabelid;
• BRIDGE tabelid;
• PREDEFINED DERIVATIONS.

Järgmises artiklis plaanin rääkida, minu arvates, kõige huvitavamast, neile, kes töötavad BI-ga. Tutvustan meetodeid faktitabelite ja mõõtmetabelite loomisel DATA VAULT'i põhjal.

Artikli materjalid põhinevad:

• Pealehe väljaandmise Kent Graziiano, millel on lisaks detailsele kirjeldamisele ka mudeli skeemid;
• Raamatul: „Building a Scalable Data Warehouse with DATA VAULT 2.0“;
• Artikkel Data Vaulti alused.

Allikas: habr.com