Në artikullin e kaluar, unë përshkrova bazat e DATA VAULT, përmenda elementet kryesore të DATA VAULT dhe qëllimin e tyre. Megjithatë, ky temë nuk duhet të mbyllet këtu; është e nevojshme të flasim për shkallët e ardhshme të evolucioneve të DATA VAULT.
Në këtë artikull do të përqendrohem në zhvillimin e DATA VAULT dhe kalimin në BUSINESS DATA VAULT, ose thjesht BUSINESS VAULT.
Arsyet që çojnë në shfaqjen e BUSINESS DATA VAULT.
Duhet tĂ« theksohet se, edhe pse DATA VAULT ka disa pĂ«rparĂ«si, ai nuk Ă«shtĂ« pa disavantazhet e tij. NjĂ« nga kĂ«to disavantazhe Ă«shtĂ« vĂ«shtirĂ«sia nĂ« shk writing me kĂ«rkesat analitike. KĂ«to kĂ«rkesa kanĂ« njĂ« numĂ«r tĂ« konsiderueshĂ«m JOINâesh, çka e bĂ«n kodin tĂ« gjatĂ« dhe tĂ« ngarkuar. PĂ«r mĂ« tepĂ«r, tĂ« dhĂ«nat qĂ« hynĂ« nĂ« DATA VAULT nuk kalojnĂ« asnjĂ« transformim, prandaj nga pikĂ«pamja e biznesit, DATA VAULT nĂ« formĂ«n e tij tĂ« pastĂ«r nuk ka vlerĂ« absolute.
Pikërisht për të eliminuar këto disavantazhe, metodologjia e DATA VAULT është zgjeruar me elemente të tilla si:
- Të dhënat PIT (point in time);
- Të dhënat BRIDGE;
- DERIVATIONS të PARAPREGATITURA.
Le të shqyrtojmë më në detaje qëllimin e këtyre elementeve.
Të dhënat PIT
Në përgjithësi, një objekt biznesi (HUB) mund të përmbajë të dhëna me frekuenca të ndryshme për përditësim; për shembull, nëse flasim për të dhënat që karakterizojnë një person, ne mund të themi se informacioni mbi numrin e telefonit, adresën ose emailin ka një frekuencë më të lartë për përditësim sesa, për shembull, emri dhe mbiemri, të dhënat e pasaportës, statusi martesor ose gjinia.
Prandaj, kur përcaktojmë satelitët, duhet të kemi parasysh frekuencën e tyre të përditësimit. Pse është kjo e rëndësishme?
NĂ«se ruajmĂ« atributet me frekuenca tĂ« ndryshme pĂ«r pĂ«rditĂ«sim nĂ« njĂ« tabelĂ«, do tĂ« duhet tĂ« shtojmĂ« njĂ« rresht nĂ« tabelĂ« me çdo pĂ«rditĂ«sim tĂ« atributit qĂ« ndryshon mĂ« shpesh. Si pasojĂ« â rritje e volumit tĂ« hapĂ«sirĂ«s nĂ« diskut, rritje e kohĂ«s sĂ« ekzekutimit tĂ« kĂ«rkesave.
Tani që kemi ndarë satelitët sipas frekuencës së përditësimit, dhe mund të ngarkojmë të dhënat në to në mënyrë të pavarur, duhet të sigurojmë mundësinë për të marrë të dhëna të sakta. Më mirë, pa përdorur JOIN të tepërta.
Le të shpjegojmë: për të marrë informacionin e saktë (sipas datës së përditësimit të fundit) nga satelitët me frekuenca të ndryshme për përditësim. Për këtë, do të nevojitet jo vetëm të bëjmë JOIN, por edhe të krijojmë disa kërkesa të ngulitura (për çdo satelit që përmban informacion) me zgjedhjen e datës maksimale të përditësimit MAX(Data e përditësimit). Me çdo JOIN të ri, ky kod zgjeron dhe bëhet shpejt i vështirë për t'u kuptuar.
Tabela PIT është e destinuar për të thjeshtuar këto kërkesa; tabelat PIT mbushen njëkohësisht me regjistrimin e të dhënave të reja në DATA VAULT. Tabela PIT:
Kështu, ne kemi informacion mbi aktualitetin e të dhënave për të gjithë satelitët për çdo moment në kohë. Duke përdorur JOIN në tabelën PIT, ne mund ta përjashtojmë plotësisht nevojën për kërkesa të ngulitura, natyrisht me kushtin që PIT të mbushet çdo ditë dhe pa ndërprerje. Edhe nëse ka ndërprerje në PIT, ne mund të marrim të dhëna të sakta duke përdorur vetëm një kërkesë të ngulitur ndaj PIT vetë. Një kërkesë e ngulitur do të punojë më shpejt se kërkesat e ngulitura për çdo satelit.
BRIDGE
Tabela të tipit BRIDGE gjithashtu përdoren për të thjeshtuar kërkesat analitike. Megjithatë, dallimi nga PIT është se ajo ndihmon në thjeshtimin dhe përshpejtimin e kërkesave midis HUBEVE të ndryshme, lidhjeve dhe satelitëve të tyre.
Tabela përmban të gjitha çelësat e nevojshëm për të gjithë satelitët, të cilët shpesh përdoren në kërkesa. Për më tepër, nëse është e nevojshme, çelësat e biznesit të hashëruara mund të plotësohen me çelësa në formë tekstuale, nëse emrat e çelësave janë të nevojshme për analizë.
E vërteta është se, pa përdorimin e BRIDGE, gjatë procesit të marrjes së të dhënave që ndodhen në satelitët që i përkasin HUBEVE të ndryshme, do të nevojitet të kryhet JOIN jo vetëm i satelitëve, por edhe i lidhjeve që lidhin HUBE.
Prania ose mungesa e BRIDGE pĂ«rcaktohet nga konfigurimi i depozitĂ«s, nevoja pĂ«r optimizimin e shpejtĂ«sisĂ« sĂ« ekzekutimit tĂ« kĂ«rkesave. ĂshtĂ« e vĂ«shtirĂ« tĂ« imagjinosh njĂ« shembull universale pĂ«r BRIDGE.
DERIVATIONS TĂ PARAPREGATITURA
Një tjetër tip objektesh që na afron me BUSINESS DATA VAULT janë tabelat që përmbajnë tregues të llogaritur paraprakisht. Të tilla tabela janë të rëndësishme për biznesin; ato përmbajnë informacion të agreguar sipas rregullave të caktuara dhe lejojnë akses në të në mënyrë relativisht të thjeshtë.
Arkitekturat PREDEFINED DERIVATIONS përbëjnë, asgjë tjetër veçse një satelit tjetër i një qendre të caktuar. Ai, sikurse satelitët e zakonshëm, përmban çelësin e biznesit dhe datën e krijimit të regjistrimit në satelit. Megjithatë, këtu mbaron ngjashmëria. Struktura e mëtejshme e atributeve të këtij "sateliti të specializuar" përcaktohet nga përdoruesit e biznesit në bazë të treguesve më të kërkuar dhe të llogaritur paraprakisht.
Për shembull, qendra që përmban informacion mbi punonjësit mund të përfshijë një satelit me tregues të tillë si:
- Pagë minimale;
- Pagë maksimale;
- Pagë mesatare;
- Shuma e akumuluar e pagës së ndarë, etj.
ĂshtĂ« logjike tĂ« pĂ«rfshijmĂ« PREDEFINED DERIVATIONS nĂ« tabelĂ«n PIT tĂ« kĂ«saj qendre, kĂ«shtu qĂ« mund tĂ« marim lehtĂ«sisht skedarĂ«t e tĂ« dhĂ«nave pĂ«r punonjĂ«sin nĂ« njĂ« datĂ« tĂ« caktuar.
KONKLUDIMET
Siç tregon praktika, përdorimi i DATA VAULT nga përdoruesit e biznesit është disi i vështirë për disa arsye:
- Kodi i pyetjeve është kompleks dhe i ngarkuar;
- Numri i madh i JOIN-eve ndikon në shpejtësinë e pyetjeve;
- Për të shkruar pyetje analitike kërkohet njohuri e shkëlqyer e strukturës së depozitës.
Për të thjeshtuar aksesin në të dhëna, DATA VAULT zgjerohet me objekte shtesë:
- Të dhënat PIT (point in time);
- Të dhënat BRIDGE;
- DERIVATIONS të PARAPREGATITURA.
NĂ« tĂ« ardhmen UnĂ« planifikoj tĂ« flas pĂ«r, sipas mendimit tim, mĂ« interesante, pĂ«r ata qĂ« punojnĂ« me BI. Do tĂ« paraqes mĂ«nyrat e krijimit tĂ« tabelave â tĂ« faktit dhe tabelave â tĂ« matjeve mbi bazĂ«n e DATA VAULT.
Materialet e artikullit janë të bazuara në:
- Në Kenta Graziano, e cila përveç përshkrimit të detajuar përmban skema të modelit;
- Libri: "Building a Scalable Data Warehouse with DATA VAULT 2.0";
- Artikulli .
Burimi: habr.com
