Eelmises artiklis rääkisin DATA VAULT põhitõdedest, kirjeldasin DATA VAULT põhielemente ja nende eesmärki. Seda ei saa pidada DATA VAULT teemaks ammendatuks, tuleb rääkida järgmistest sammudest DATA VAULTi arengus.
Ja selles artiklis keskendun DATA VAULTi arendamisele ja üleminekule BUSINESS DATA VAULTile või lihtsalt BUSINESS VAULTile.
ÄRIANDMETE VAULT ilmumise põhjused
Tuleb märkida, et kuigi DATA VAULTil on teatud tugevused, pole sellel ka puudusi. Üks neist puudustest on analüütiliste päringute kirjutamise raskus. Päringutel on märkimisväärne arv JOIN-e, kood on pikk ja tülikas. Samuti ei toimu DATA VAULT sisestatavates andmetes mingeid transformatsioone, mistõttu ärilisest seisukohast pole DATA VAULTil puhtal kujul absoluutväärtust.
Just nende puuduste kõrvaldamiseks laiendati DATA VAULT metoodikat selliste elementidega nagu:
- PIT (point in time) tabelid;
- BRIDGE lauad;
- ETTEMÄÄRATUD TULETUSED.
Vaatame lähemalt nende elementide eesmärki.
PIT tabelid
Tavaliselt võib üks äriüksus (HUB) sisaldada erineva värskendussagedusega andmeid, näiteks kui me räägime isikut iseloomustavatest andmetest, siis võib öelda, et telefoninumbri, aadressi või e-posti teabel on suurem uuendusmäär kui näiteks täisnimi, passi andmed, perekonnaseis või sugu.
Seetõttu peaksite satelliitide määramisel silmas pidama nende värskendamise sagedust. Miks see oluline on?
Kui salvestate samasse tabelisse erineva värskendussagedusega atribuudid, peate iga kord, kui kõige sagedamini muudetud atribuuti värskendatakse, tabelisse rea lisama. Tulemuseks on kettaruumi suurenemine ja päringu täitmise aja pikenemine.
Nüüd, kui oleme jaganud satelliidid uuendussageduse järgi ja saame neisse iseseisvalt andmeid laadida, peaksime tagama, et saame vastu võtta ajakohaseid andmeid. Parem, ilma tarbetuid JOIN-e kasutamata.
Lubage mul selgitada, näiteks peate hankima jooksvat (vastavalt viimase värskenduse kuupäevale) teavet satelliitidelt, millel on erinev uuendussagedus. Selleks ei pea te tegema mitte ainult LIITUMIST, vaid ka looma mitu pesastatud päringut (iga teavet sisaldava satelliidi kohta), valides maksimaalseks värskenduskuupäevaks MAX (Update Date). Iga uue JOIN-iga selline kood kasvab ja muutub väga kiiresti raskesti mõistetavaks.
PIT-tabel on loodud selliste päringute lihtsustamiseks; PIT-tabelid täidetakse samaaegselt uute andmete kirjutamisega DATA VAULT-i. PIT tabel:
Seega on meil teavet kõigi satelliitide andmete asjakohasuse kohta igal ajahetkel. Kasutades PIT-tabeliga JOIN-e, saame täielikult välistada pesastatud päringud, loomulikult tingimusel, et PIT-i täidetakse iga päev ja ilma lünkadeta. Isegi kui PIT-is on lünki, saate uusimaid andmeid ainult ühe PIT-i enda pesastatud päringu abil. Üks pesastatud päring töötleb kiiremini kui iga satelliidi pesastatud päring.
BRIDGE
BRIDGE tabeleid kasutatakse ka analüütiliste päringute lihtsustamiseks. PIT-ist erineb aga vahend, mis lihtsustab ja kiirendab päringuid erinevate jaoturite, linkide ja nende satelliitide vahel.
Tabelis on kõik vajalikud võtmed kõikide satelliitide jaoks, mida sageli päringutes kasutatakse. Lisaks saab vajadusel räsistatud ärivõtmeid täiendada tekstikujuliste võtmetega, kui võtmete nimesid on analüüsiks vaja.
Fakt on see, et ilma BRIDGE'i kasutamata tuleb erinevatesse jaoturitesse kuuluvates satelliitides asuvate andmete vastuvõtmise protsessis teha JOIN mitte ainult satelliitide endi, vaid ka jaotureid ühendavate linkide vahel.
BRIDGE olemasolu või puudumise määrab salvestuse konfiguratsioon ja vajadus optimeerida päringu täitmise kiirust. Universaalset näidet BRIGE'ist on raske välja tuua.
ETTEMÄÄRATUD TULETUSED
Teine objektitüüp, mis toob meid ÄRIANDMETE VAULT lähemale, on tabelid, mis sisaldavad eelarvutatud näitajaid. Sellised tabelid on ettevõtluse jaoks väga olulised, need sisaldavad etteantud reeglite järgi koondatud teavet ja muudavad selle suhteliselt lihtsaks.
Arhitektuuriliselt ei ole ETTEDEFINITEERITUD TULETUSED midagi muud kui teatud sõlmpunkti järjekordne satelliit. See, nagu tavaline satelliit, sisaldab ärivõtit ja satelliidis oleva kirje loomise kuupäeva. Siin aga sarnasused lõpevad. Sellise "spetsialiseerunud" satelliidi atribuutide edasise koostise määravad ärikasutajad kõige populaarsemate, eelnevalt arvutatud näitajate põhjal.
Näiteks võib töötaja kohta teavet sisaldav jaotur sisaldada satelliiti, millel on järgmised näitajad:
- Miinimumpalk;
- Maksimaalne töötasu;
- Keskmine palk;
- Kogunenud töötasude kumulatiivne kogusumma jne.
Loogiline on lisada sama jaoturi PIT-i tabelisse EELMÄÄRATUD TULETUSED, siis saate hõlpsalt hankida töötaja andmelõike konkreetselt valitud kuupäeval.
KOKKUVÕTE
Nagu praktika näitab, on DATA VAULT kasutamine ärikasutajate jaoks mõnevõrra keeruline mitmel põhjusel:
- Päringu kood on keeruline ja tülikas;
- JOIN-ide rohkus mõjutab päringute toimivust;
- Analüütiliste päringute kirjutamine nõuab suurepäraseid teadmisi salvestusruumi kujundamisest.
Andmetele juurdepääsu lihtsustamiseks on DATA VAULT laiendatud täiendavate objektidega:
- PIT (point in time) tabelid;
- BRIDGE lauad;
- ETTEMÄÄRATUD TULETUSED.
Edasi Kavatsen rääkida minu arvates kõige huvitavama asja neile, kes BI-ga töötavad. Tutvustan DATA VAULTi baasil faktitabelite ja dimensioonitabelite loomise viise.
Artikli materjalid põhinevad:
- Edasi Kenta Graziano, mis sisaldab lisaks üksikasjalikule kirjeldusele mudelskeeme;
- Raamat: “Skaleeritava andmelao ehitamine DATA VAULT 2.0 abil”;
- Artikkel .
Allikas: www.habr.com