Zhvillimi i një depoje të dhënash është një proces i gjatë dhe serioz.
Shumë gjëra në jetën e një projekti varen nga sa mirë janë menduar modeli i objekteve dhe struktura e bazës së të dhënave që në fillim.
Qasja e pranuar gjerĂ«sisht ka qenĂ« dhe mbetet kombinimi i varianteve tĂ« ndryshme tĂ« skemĂ«s âyllâ me formĂ«n e tretĂ« normale. Zakonisht, sipas parimit: tĂ« dhĂ«nat burimore â 3NF, data mart-et â yll. Kjo qasje, e provuar me kohĂ«n dhe e mbĂ«shtetur nga njĂ« numĂ«r i madh studimesh, Ă«shtĂ« gjĂ«ja e parĂ« (dhe ndonjĂ«herĂ« e vetmja) qĂ« i vjen nĂ« mendje njĂ« specialisti me pĂ«rvojĂ« tĂ« DWH kur mendon se si duhet tĂ« duket njĂ« depo analitike e tĂ« dhĂ«nave.
Nga ana tjetĂ«r, biznesi nĂ« tĂ«rĂ«si dhe kĂ«rkesat e klientit nĂ« veçanti priren tĂ« ndryshojnĂ« shpejt, ndĂ«rsa tĂ« dhĂ«nat tĂ« rriten si ânĂ« thellĂ«siâ, ashtu edhe ânĂ« gjerĂ«siâ. PikĂ«risht kĂ«tu del nĂ« pah mangĂ«sia kryesore e skemĂ«s yll â fleksibiliteti i kufizuar.
Dhe nëse në jetën tuaj të qetë e komode si zhvillues DWH papritur:
- u shfaq detyra âtĂ« bĂ«jmĂ« shpejt tĂ« paktĂ«n diçka, pastaj do tĂ« shohimâ;
- u shfaq një projekt me zhvillim të vrullshëm, me lidhjen e burimeve të reja dhe rishikimin e modelit të biznesit të paktën një herë në javë;
- u shfaq një klient që nuk e ka të qartë si duhet të duket sistemi dhe cilat funksione duhet të kryejë në fund, por është i gatshëm për eksperimente dhe për saktësimin gradual të rezultatit të dëshiruar, duke iu afruar atij hap pas hapi;
- hyri menaxheri i projektit me lajmin e gĂ«zueshĂ«m: âDhe tani kemi Agile!â.
Ose nĂ«se thjesht ju intereson tĂ« mĂ«soni se si tjetĂ«r mund tĂ« ndĂ«rtohen depot e tĂ« dhĂ«nave â mirĂ« se vini mĂ« poshtĂ«!
ĂfarĂ« do tĂ« thotĂ« «fleksibilitet»
SĂ« pari, le tĂ« pĂ«rcaktojmĂ« se çfarĂ« vetish duhet tĂ« ketĂ« njĂ« sistem qĂ« tĂ« mund tĂ« quhet âfleksibĂ«lâ.
MĂ« vete vlen tĂ« theksohet se vetitĂ« e pĂ«rshkruara duhet tâi referohen pikĂ«risht sistemit, dhe jo procesit tĂ« zhvillimit tĂ« tij. Prandaj, nĂ«se donit tĂ« lexonit pĂ«r Agile si metodologji zhvillimi, mĂ« mirĂ« shihni artikuj tĂ« tjerĂ«. PĂ«r shembull, po kĂ«tu, nĂ« Habr, ka shumĂ« materiale interesante (si dhe , ashtu edhe ).
Kjo nuk do të thotë se procesi i zhvillimit dhe struktura e DW nuk kanë fare lidhje mes tyre. Në përgjithësi, ndërtimi i një depoje të dhënash me arkitekturë fleksibile sipas Agile duhet të jetë dukshëm më i lehtë. Megjithatë, në praktikë më shpesh hasen kombinime si zhvillimi sipas Agile i një DWH klasik sipas Kimball dhe Data Vault sipas waterfall, sesa përputhje të lumtura të fleksibilitetit në të dyja format e tij brenda të njëjtit projekt.
Pra, çfarë aftësish duhet të ketë një depo fleksibile e të dhënave? Këtu mund të veçohen tre pika:
- DorĂ«zim i hershĂ«m dhe pĂ«rmirĂ«sim i shpejtĂ« â kjo do tĂ« thotĂ« se, nĂ« rastin ideal, rezultati i parĂ« i biznesit (pĂ«r shembull, raportet e para funksionale) duhet tĂ« merret sa mĂ« herĂ«t tĂ« jetĂ« e mundur, pra ende pĂ«rpara se sistemi tĂ« projektohet dhe tĂ« zbatohet plotĂ«sisht nĂ« tĂ«rĂ«si. NĂ« tĂ« njĂ«jtĂ«n kohĂ«, çdo pĂ«rmirĂ«sim pasues duhet gjithashtu tĂ« marrĂ« sa mĂ« pak kohĂ«.
- PĂ«rmirĂ«sim iterativ â kjo do tĂ« thotĂ« se çdo pĂ«rmirĂ«sim i radhĂ«s, nĂ« rastin ideal, nuk duhet tĂ« ndikojĂ« funksionalitetin qĂ« tashmĂ« Ă«shtĂ« nĂ« punĂ«. PikĂ«risht kjo pikĂ« shpesh kthehet nĂ« makthin mĂ« tĂ« madh nĂ« projektet e mĂ«dha â herĂ«t a vonĂ«, objektet e veçanta fillojnĂ« tĂ« mbingarkohen me aq shumĂ« lidhje, sa bĂ«het mĂ« e lehtĂ« tĂ« pĂ«rsĂ«ritet plotĂ«sisht logjika nĂ« njĂ« kopje pranĂ« saj, sesa tĂ« shtohet njĂ« fushĂ« nĂ« tabelĂ«n ekzistuese. Dhe nĂ«se ju habit fakti qĂ« analiza e ndikimit tĂ« njĂ« pĂ«rmirĂ«simi mbi objektet ekzistuese mund tĂ« marrĂ« mĂ« shumĂ« kohĂ« se vetĂ« pĂ«rmirĂ«simi, ka shumĂ« tĂ« ngjarĂ« qĂ« ende tĂ« mos keni punuar me DW tĂ« mĂ«dha nĂ« sektorin bankar ose nĂ« telekom.
- PĂ«rshtatje e vazhdueshme ndaj kĂ«rkesave tĂ« biznesit qĂ« ndryshojnĂ« â struktura e pĂ«rgjithshme e objekteve duhet tĂ« projektohet jo thjesht duke marrĂ« parasysh zgjerimin e mundshĂ«m, por duke llogaritur qĂ« drejtimi i zgjerimit tĂ« ardhshĂ«m mund tĂ« jetĂ« diçka qĂ« as nuk do tâju shkonte nĂ« mendje nĂ« fazĂ«n e projektimit.
Dhe po, përmbushja e të gjitha këtyre kërkesave në një sistem të vetëm është e mundur (natyrisht, në raste të caktuara dhe me disa kufizime).
MĂ« poshtĂ« do tĂ« shqyrtoj dy metodologjitĂ« mĂ« tĂ« njohura tĂ« projektimit fleksibil pĂ«r DW â Anchor model dhe Data Vault. JashtĂ« kĂ«tij materiali mbeten teknika kaq tĂ« mira si, pĂ«r shembull, EAV, 6NF (nĂ« formĂ«n e pastĂ«r) dhe gjithçka qĂ« lidhet me zgjidhjet NoSQL â jo sepse janĂ« disi mĂ« tĂ« dobĂ«ta, madje as sepse nĂ« kĂ«tĂ« rast artikulli do tĂ« rrezikonte tĂ« merrte pĂ«rmasat e njĂ« disertacioni mesatar. Thjesht, tĂ« gjitha kĂ«to i pĂ«rkasin zgjidhjeve tĂ« njĂ« klase disi tjetĂ«r â ose teknikave qĂ« mund tâi pĂ«rdorni nĂ« raste specifike, pavarĂ«sisht nga arkitektura e pĂ«rgjithshme e projektit tuaj (si EAV), ose paradigmave thelbĂ«sisht tĂ« ndryshme tĂ« ruajtjes sĂ« informacionit (si, pĂ«r shembull, bazat e tĂ« dhĂ«nave grafike dhe variante tĂ« tjera tĂ« NoSQL).
Problemet e qasjes âklasikeâ dhe zgjidhjet e tyre nĂ« metodologjitĂ« fleksibile
Me qasjen âklasikeâ kam parasysh modelin e vjetĂ«r tĂ« mirĂ« me yll (pavarĂ«sisht nga implementimi konkret i shtresave mĂ« poshtĂ«, mĂ« falshin adhuruesit e Kimball, Inmon dhe CDM).
1. Kardinaliteti i ngurtë i marrëdhënieve
NĂ« bazĂ« tĂ« njĂ« modeli tĂ« tillĂ« vendoset njĂ« ndarje e qartĂ« e tĂ« dhĂ«nave nĂ« dimensione (Dimension) dhe fakte (Fact). Dhe kjo, dreqi ta hajĂ«, Ă«shtĂ« logjike â sepse analiza e tĂ« dhĂ«nave nĂ« shumicĂ«n dĂ«rrmuese tĂ« rasteve reduktohet pikĂ«risht nĂ« analizĂ«n e treguesve tĂ« caktuar numerikĂ« (fakteve) sipas prerjeve tĂ« caktuara (dimensioneve).
NdĂ«rkohĂ«, lidhjet midis objekteve pĂ«rcaktohen si lidhje midis tabelave pĂ«rmes çelĂ«sit tĂ« huaj. Kjo duket krejt e natyrshme, por menjĂ«herĂ« sjell kufizimin e parĂ« tĂ« fleksibilitetit â pĂ«rcaktimin e ngurtĂ« tĂ« kardinalitetit tĂ« marrĂ«dhĂ«nieve.
Kjo do tĂ« thotĂ« qĂ« nĂ« fazĂ«n e projektimit tĂ« tabelave duhet tĂ« pĂ«rcaktoni saktĂ«sisht pĂ«r çdo çift objektesh tĂ« lidhura nĂ«se ato mund tĂ« jenĂ« nĂ« marrĂ«dhĂ«nie shumĂ«-me-shumĂ«, apo vetĂ«m njĂ«-me-shumĂ«, dhe ânĂ« cilin drejtimâ. Nga kjo varet drejtpĂ«rdrejt se nĂ« cilĂ«n prej tabelave do tĂ« jetĂ« çelĂ«si primar dhe nĂ« cilĂ«n â çelĂ«si i huaj. Ndryshimi i kĂ«saj marrĂ«dhĂ«nieje pas marrjes sĂ« kĂ«rkesave tĂ« reja me shumĂ« gjasa do tĂ« çojĂ« nĂ« ripunimin e bazĂ«s sĂ« tĂ« dhĂ«nave.
PĂ«r shembull, duke projektuar objektin âkupon fiskalâ, ju, duke u mbĂ«shtetur te garancitĂ« solemne tĂ« departamentit tĂ« shitjeve, keni parashikuar mundĂ«sinĂ« e veprimit tĂ« njĂ« promocioni mbi disa rreshta tĂ« kuponit (por jo anasjelltas):
Dhe pas njëfarë kohe, kolegët prezantuan një strategji të re marketingu, në të cilën mbi të njëjtin rresht mund të veprojnë disa promocione njëkohësisht. Dhe tani duhet të përpunoni tabelat më tej, duke e veçuar marrëdhënien në një objekt më vete.
(Të gjitha objektet derivuese ku bëhet join i çekut me promon tani gjithashtu kërkojnë përpunim shtesë).
Lidhjet në Data Vault dhe Anchor Model
Shmangia e një situate të tillë doli të ishte mjaft e thjeshtë: mjafton të mos i besohet departamentit të shitjeve dhe të gjitha lidhjet të ruhen që në fillim në tabela të veçanta dhe të trajtohen si many-to-many.
Kjo qasje u propozua nga Dan Linstedt si pjesë e paradigmës së Data Vault dhe u mbështet plotësisht nga Lars RönnbÀck në Anchor Model.
Si rezultat, marrim veçorinë e parë dalluese të metodologjive fleksibël:
Lidhjet midis objekteve nuk ruhen në atributet e entiteteve prind, por përfaqësojnë një lloj më vete objektesh.
NĂ« Data Vault kĂ«to tabela ndĂ«rlidhĂ«se quhen Link, ndĂ«rsa nĂ« Anchor Model â Tie. NĂ« pamje tĂ« parĂ« ato janĂ« shumĂ« tĂ« ngjashme, megjithĂ«se dallimet e tyre nuk kufizohen vetĂ«m te emri (pĂ«r çka do tĂ« flasim mĂ« poshtĂ«). NĂ« tĂ« dy arkitekturat, tabelat ndĂ«rlidhĂ«se mund tĂ« lidhin çfarĂ«do numri entitetesh (jo domosdoshmĂ«risht 2).
Kjo tepricĂ«, qĂ« nĂ« pamje tĂ« parĂ« duket e panevojshme, jep fleksibilitet tĂ« konsiderueshĂ«m gjatĂ« ndryshimeve. Kjo strukturĂ« bĂ«het tolerante jo vetĂ«m ndaj ndryshimit tĂ« kardinaliteteve tĂ« lidhjeve ekzistuese, por edhe ndaj shtimit tĂ« tĂ« rejave â nĂ«se tani njĂ« pozicion çeku do tĂ« ketĂ« edhe njĂ« referencĂ« te arkĂ«tari qĂ« e ka regjistruar, shfaqja e njĂ« lidhjeje tĂ« tillĂ« do tĂ« jetĂ« thjesht njĂ« shtresĂ« shtesĂ« mbi tabelat ekzistuese, pa ndikuar nĂ« asnjĂ« objekt apo proces ekzistues.
2. Dublikimi i të dhënave
Problemi i dytë që zgjidhet nga arkitekturat fleksibël është më pak i dukshëm dhe është karakteristik kryesisht për dimensionet e tipit SCD2 (dimensione me ndryshim të ngadaltë të tipit 2), megjithëse jo vetëm për to.
Në një depo klasike të të dhënave, dimensioni zakonisht përfaqëson një tabelë që përmban një çelës zëvendësues (si PK), si edhe një grup çelësash biznesi dhe atributesh në kolona të veçanta.
Nëse dimensioni mbështet versionim, grupit standard të fushave i shtohen kufijtë kohorë të vlefshmërisë së versionit, dhe për një rresht në burim krijohen disa versione në depo (nga një për çdo ndryshim të atributeve të versionuara).
Nëse dimensioni përmban të paktën një atribut versionues që ndryshon shpesh, numri i versioneve të këtij dimensioni do të jetë i konsiderueshëm (edhe nëse atributet e tjera nuk janë versionuese ose nuk ndryshojnë kurrë), ndërsa nëse ka disa atribute të tilla, numri i versioneve mund të rritet në progresion gjeometrik në varësi të numrit të tyre. Një dimension i tillë mund të zërë hapësirë të konsiderueshme në disk, megjithëse pjesa më e madhe e të dhënave të ruajtura në të janë thjesht dublikatë të vlerave të atributeve të pandryshueshme nga rreshta të tjerë.
PĂ«r mĂ« tepĂ«r, shumĂ« shpesh pĂ«rdoret edhe denormalizimi â njĂ« pjesĂ« e atributeve ruhen qĂ«llimisht si vlerĂ« dhe jo si referencĂ« ndaj njĂ« klasifikuesi ose dimensioni tjetĂ«r. Kjo qasje pĂ«rshpejton qasjen nĂ« tĂ« dhĂ«na, duke ulur numrin e join-eve gjatĂ« aksesimit tĂ« dimensionit.
Si rregull, kjo çon nĂ« faktin qĂ« i njĂ«jti informacion ruhet njĂ«kohĂ«sisht nĂ« disa vende. PĂ«r shembull, informacioni pĂ«r rajonin e banimit dhe pĂ«rkatĂ«sinĂ« nĂ« kategorinĂ« e klientit mund tĂ« ruhet njĂ«kohĂ«sisht nĂ« dimensionin âKlientâ dhe nĂ« faktet âBlerjeâ, âDorĂ«zimâ dhe âKontakte me call centerâ, si edhe nĂ« tabelĂ«n ndĂ«rlidhĂ«se âKlient â Menaxher i klientitâ.
NĂ« pĂ«rgjithĂ«si, sa u pĂ«rshkrua mĂ« sipĂ«r vlen edhe pĂ«r dimensionet e zakonshme (jo versionuese), por te dimensionet versionuese kjo mund tĂ« marrĂ« pĂ«rmasa tĂ« tjera: shfaqja e njĂ« versioni tĂ« ri tĂ« objektit (sidomos nĂ« mĂ«nyrĂ« retroaktive) nuk sjell thjesht pĂ«rditĂ«simin e tĂ« gjitha tabelave tĂ« lidhura, por edhe shfaqjen kaskadĂ« tĂ« versioneve tĂ« reja tĂ« objekteve tĂ« lidhura â kur Tabela 1 pĂ«rdoret pĂ«r ndĂ«rtimin e TabelĂ«s 2, ndĂ«rsa Tabela 2 pĂ«rdoret pĂ«r ndĂ«rtimin e TabelĂ«s 3, e kĂ«shtu me radhĂ«. Edhe nĂ«se asnjĂ« atribut i TabelĂ«s 1 nuk merr pjesĂ« nĂ« ndĂ«rtimin e TabelĂ«s 3 (dhe nĂ« tĂ« marrin pjesĂ« atribute tĂ« tjera tĂ« TabelĂ«s 2, tĂ« marra nga burime tĂ« tjera), pĂ«rditĂ«simi versionues i kĂ«saj strukture, tĂ« paktĂ«n, do tĂ« sjellĂ« kosto shtesĂ« operative, ndĂ«rsa nĂ« rastin mĂ« tĂ« keq â versione tĂ« panevojshme nĂ« TabelĂ«n 3, e cila kĂ«tu nĂ« fakt ânuk ka lidhje fareâ, dhe mĂ« tej pĂ«rgjatĂ« gjithĂ« zinxhirit.
3. Kompleksitet jolinear i përpunimeve
PĂ«r mĂ« tepĂ«r, çdo data mart i ri qĂ« ndĂ«rtohet mbi bazĂ«n e njĂ« tjetri rrit numrin e pikave ku tĂ« dhĂ«nat mund tĂ« âdalin nga sinkroniâ gjatĂ« ndryshimeve nĂ« ETL. Kjo, nga ana tjetĂ«r, sjell rritje tĂ« kompleksitetit (dhe kohĂ«zgjatjes) sĂ« çdo pĂ«rpunimi tĂ« mĂ«passhĂ«m.
NĂ«se sa mĂ« sipĂ«r vlen pĂ«r sisteme me procese ETL qĂ« pĂ«rpunohen rrallĂ«, mund tĂ« punohet nĂ« njĂ« paradigmĂ« tĂ« tillĂ« â mjafton thjesht tĂ« kontrollohet qĂ« pĂ«rmirĂ«simet e reja tĂ« aplikohen saktĂ« nĂ« tĂ« gjitha objektet e lidhura. Por nĂ«se pĂ«rmirĂ«simet bĂ«hen shpesh, gjasat pĂ«r tĂ« âharruarâ rastĂ«sisht disa lidhje rriten ndjeshĂ«m.
NĂ«se, pĂ«r mĂ« tepĂ«r, merret parasysh se ETL âme versionimâ Ă«shtĂ« dukshĂ«m mĂ« i ndĂ«rlikuar se ai âpa versionimâ, shmangia e gabimeve gjatĂ« pĂ«rpunimeve tĂ« shpeshta tĂ« gjithĂ« kĂ«tij sistemi bĂ«het mjaft e vĂ«shtirĂ«.
Ruajtja e objekteve dhe atributeve në Data Vault dhe Anchor Model
Qasja e propozuar nga autorët e arkitekturave fleksibile mund të formulohet kështu:
Duhet të ndahet ajo që ndryshon nga ajo që mbetet e pandryshueshme. Pra, çelësat duhen ruajtur veçmas nga atributet.
Megjithatë, nuk duhet ngatërruar pa versionim atributi me të pandryshueshëm: i pari nuk ruan historinë e ndryshimeve të veta, por mund të ndryshojë (për shembull, gjatë korrigjimit të një gabimi në futje ose pas marrjes së të dhënave të reja), ndërsa i dyti nuk ndryshon kurrë.
Pikëpamjet mbi atë se çfarë saktësisht mund të konsiderohet e pandryshueshme në Data Vault dhe Anchor Model ndryshojnë.
Nga pikĂ«pamja e arkitekturĂ«s Data Vault, i pandryshueshĂ«m mund tĂ« konsiderohet i gjithĂ« grupi i çelĂ«save â natyrorĂ« (NIPT-i i organizatĂ«s, kodi i produktit nĂ« sistemin burimor etj.) dhe surrogate. NdĂ«rkohĂ«, atributet e tjera mund tĂ« ndahen nĂ« grupe sipas burimit dhe/ose shpeshtĂ«sisĂ« sĂ« ndryshimeve dhe pĂ«r secilin grup tĂ« mbahet njĂ« tabelĂ« mĂ« vete me njĂ« grup versionesh tĂ« pavarura.
Ndërsa në paradigmën e Anchor Model i pandryshueshëm konsiderohet vetëm çelësi surrogate i entitetit. Gjithçka tjetër (përfshirë çelësat natyrorë) është thjesht një rast i veçantë i atributeve të tij. Në të njëjtën kohë, të gjitha atributet janë të pavarura nga njëri-tjetri si parazgjedhje, prandaj për secilin atribut duhet të krijohet një tabelë më vete.
Në Data Vault tabelat që përmbajnë çelësat e entiteteve quhen Hub-e (Hub). Hub-et përmbajnë gjithmonë një grup fushash fikse:
- ĂelĂ«sat natyrorĂ« tĂ« entitetit
- ĂelĂ«si surrogate
- Referenca te burimi
- Koha e shtimit të regjistrimit
Regjistrimet në Hub-e nuk ndryshojnë kurrë dhe nuk kanë versione. Nga ana e jashtme, hub-et janë shumë të ngjashëm me tabelat e tipit ID-map që përdoren në disa sisteme për gjenerimin e surrogateve, megjithatë në Data Vault rekomandohet që si surrogate të përdoret jo një sekuencë me numra të plotë, por një hash i grupit të çelësave të biznesit. Kjo qasje thjeshton ngarkimin e lidhjeve dhe atributeve nga burimet (nuk ka nevojë të bëhen join me hub-in për të marrë surrogate-in, mjafton të llogaritet hash-i nga çelësi natyror), por mund të sjellë probleme të tjera (të lidhura, për shembull, me kolizionet, regjistrin e shkronjave dhe karakteret e paprintueshme në çelësat tekstualë etj.), prandaj nuk konsiderohet si praktikë universalisht e pranuar.
Të gjitha atributet e tjera të entiteteve ruhen në tabela të posaçme, të quajtura Satelitë (Satellit). Një hub mund të ketë disa satelitë që ruajnë grupe të ndryshme atributesh.
ShpĂ«rndarja e atributeve ndĂ«rmjet satelitĂ«ve bĂ«het sipas parimit tĂ« ndryshimit tĂ« pĂ«rbashkĂ«t â nĂ« njĂ« satelit mund tĂ« ruhen atribute jo-versionale (pĂ«r shembull, data e lindjes dhe numri personal pĂ«r njĂ« person fizik), nĂ« njĂ« tjetĂ«r atribute versionale qĂ« ndryshojnĂ« rrallĂ« (pĂ«r shembull, mbiemri dhe numri i pasaportĂ«s), ndĂ«rsa nĂ« njĂ« tĂ« tretĂ« atribute qĂ« ndryshojnĂ« shpesh (pĂ«r shembull, adresa e dorĂ«zimit, kategoria, data e porosisĂ« sĂ« fundit etj.). Versionimi nĂ« kĂ«tĂ« rast mbahet nĂ« nivelin e satelitĂ«ve individualĂ«, jo tĂ« entitetit nĂ« tĂ«rĂ«si, ndaj shpĂ«rndarja e atributeve Ă«shtĂ« e arsyeshme tĂ« bĂ«het nĂ« mĂ«nyrĂ« qĂ« mbivendosja e versioneve brenda njĂ« sateliti tĂ« jetĂ« minimale (gjĂ« qĂ« ul numrin e pĂ«rgjithshĂ«m tĂ« versioneve tĂ« ruajtura).
Gjithashtu, për të optimizuar procesin e ngarkimit të të dhënave, atributet e marra nga burime të ndryshme shpesh ndahen në satelitë të veçantë.
SatelitĂ«t lidhen me Hub-in pĂ«rmes çelĂ«sit tĂ« jashtĂ«m (qĂ« korrespondon me kardinalitetin 1-me-shumĂ«). Kjo do tĂ« thotĂ« se vlerat e shumĂ«fishta tĂ« atributeve (pĂ«r shembull, disa numra telefoni kontakti pĂ«r njĂ« klient) mbĂ«shteten nga kjo arkitekturĂ« âsi parazgjedhjeâ.
Në Modelit Anchor (Anchor Model) tabelat që ruajnë çelësat quhen Anchors (Anchor). Dhe ato ruajnë:
- Vetëm çelësa surrogate
- Referenca te burimi
- Koha e shtimit të regjistrimit
ĂelĂ«sat natyrorĂ«, nga kĂ«ndvĂ«shtrimi i Modelit Anchor, konsiderohen si atribute tĂ« zakonshme. Ky variant mund tĂ« duket mĂ« i vĂ«shtirĂ« pĂ«r tâu kuptuar, por ofron shumĂ« mĂ« tepĂ«r hapĂ«sirĂ« pĂ«r identifikimin e objektit.
Për shembull, nëse të dhënat për të njëjtin entitet mund të vijnë nga sisteme të ndryshme, ku secili përdor çelësin e vet natyror. Në Data Vault kjo mund të çojë në struktura mjaft të rënda me disa hub-e (nga një për çdo burim + një version master që i bashkon), ndërsa në Anchor Model çelësi natyror i çdo burimi vendoset në atributin e vet dhe mund të përdoret gjatë ngarkimit pavarësisht nga të gjithë të tjerët.
Por kĂ«tu fshihet edhe njĂ« moment delikat: nĂ«se nĂ« njĂ« entitet bashkohen atribute nga sisteme tĂ« ndryshme, me shumĂ« gjasa ekzistojnĂ« disa rregulla tĂ« âbashkimitâ, sipas tĂ« cilave sistemi duhet tĂ« kuptojĂ« se regjistrimet nga burime tĂ« ndryshme i pĂ«rkasin tĂ« njĂ«jtit instancĂ« tĂ« entitetit.
NĂ« Data Vault KĂ«to rregulla, me shumĂ« gjasa, do tĂ« pĂ«rcaktojnĂ« formimin e âhub-it surrogateâ tĂ« entitetit master dhe nuk do tĂ« ndikojnĂ« aspak te Hub-et qĂ« ruajnĂ« çelĂ«sat natyrorĂ« tĂ« burimeve dhe atributet e tyre fillestare. NĂ«se nĂ« njĂ« moment rregullat e bashkimit ndryshojnĂ« (ose vjen njĂ« pĂ«rditĂ«sim i atributeve mbi tĂ« cilat ai kryhet), do tĂ« mjaftojĂ« tĂ« riformohen hub-et surrogate.
Në Anchor Model ndërkaq një entitet i tillë, me shumë gjasa, do të ruhet në një ankorë të vetme. Kjo do të thotë se të gjitha atributet, pavarësisht nga cili burim janë marrë, do të lidhen me të njëjtin surrogate. Ndarja e regjistrimeve të bashkuara gabimisht dhe, në përgjithësi, ndjekja e vlefshmërisë së bashkimit në një sistem të tillë mund të rezultojë dukshëm më e vështirë, sidomos nëse rregullat janë mjaft komplekse dhe ndryshojnë shpesh, ndërsa i njëjti atribut mund të merret nga burime të ndryshme (edhe pse kjo është plotësisht e mundur, pasi çdo version i atributit ruan referencën te burimi i vet).
Në çdo rast, nëse në sistemin tuaj parashikohet zbatimi i funksionalitetit për deduplikim, bashkim regjistrimesh dhe elemente të tjera të MDM, ia vlen të analizohen me kujdes të veçantë aspektet e ruajtjes së çelësave natyrorë në metodologjitë fleksibile. Ka gjasa që struktura më e rëndë e Data Vault të dalë papritur më e sigurt nga këndvështrimi i gabimeve të bashkimit.
Anchor Model gjithashtu parashikon një lloj shtesë objekti, të quajtur Nyja (Knot) në thelb, kjo është një formë e degjeneruar e ankorës, i cili mund të përmbajë vetëm një atribut. Nyjet supozohet të përdoren për ruajtjen e referencave të thjeshta (për shembull gjinia, statusi martesor, kategoria e shërbimit të klientit etj.). Ndryshe nga Anchor, Nyja nuk ka tabela atributesh të lidhura, ndërsa atributi i saj i vetëm (emri) ruhet gjithmonë në të njëjtën tabelë me çelësin. Nyjet lidhen me Anchor përmes tabelave të lidhjes (Tie), njësoj si lidhen anchorët me njëri-tjetrin.
Nuk ka një mendim të vetëm për përdorimin e Nyjeve. Për shembull, , i cili promovon në mënyrë aktive përdorimin e modelit Anchor në Rusi, konsideron (me të drejtë) se për asnjë referencë nuk mund të thuhet me siguri se ajo të ashpër në do të jetë statike dhe me një nivel të vetëm, prandaj për të gjitha objektet është më mirë të përdoret menjëherë një Anchor i plotë.
Një tjetër dallim i rëndësishëm midis Data Vault dhe modelit Anchor është prania e atributeve te lidhjet:
Në Data Vault Lidhjet janë objekte po aq të plota sa edhe Hub-et dhe mund të kenë atributet e tyre. Në Anchor Model Lidhjet përdoren vetëm për të bashkuar Anchor-et dhe nuk mund të kenë atribute të tyre. Ky ndryshim sjell qasje thelbësisht të ndryshme ndaj modelimit të fakteve, për të cilat do të flasim më tej.
Ruajtja e fakteve
Deri tani kemi folur kryesisht për modelimin e dimensioneve. Me faktet, situata është disi më pak e qartë.
Në Data Vault objekti tipik për ruajtjen e fakteve është Lidhja (Link), në Satellite-et e së cilës ruhen treguesit numerikë.
Kjo qasje duket intuitive. Ajo ofron qasje tĂ« thjeshtĂ« te treguesit qĂ« analizohen dhe nĂ« pĂ«rgjithĂ«si i ngjan njĂ« tabele tradicionale faktesh (vetĂ«m se treguesit nuk ruhen nĂ« vetĂ« tabelĂ«n, por nĂ« njĂ« âfqinjeâ). Por ka edhe vĂ«shtirĂ«si: njĂ« nga zgjerimet tipike tĂ« modelit â zgjerimi i çelĂ«sit tĂ« faktit â sjell nevojĂ«n pĂ«r shtimin e njĂ« çelĂ«si tĂ« ri tĂ« jashtĂ«m nĂ« Link. Kjo, nga ana tjetĂ«r, âe thyenâ modularitetin dhe potencialisht krijon nevojĂ«n pĂ«r ndryshime edhe nĂ« objekte tĂ« tjera.
NĂ« Anchor Model Lidhja nuk mund tĂ« ketĂ« atribute tĂ« veta, prandaj kjo qasje nuk funksionon â absolutisht tĂ« gjitha atributet dhe treguesit duhet tĂ« lidhen me njĂ« anchor konkret. PĂ«rfundimi Ă«shtĂ« i thjeshtĂ« â edhe pĂ«r çdo fakt nevojitet anchor-i i vet. PĂ«r njĂ« pjesĂ« tĂ« asaj qĂ« jemi mĂ«suar ta perceptojmĂ« si fakte, kjo mund tĂ« duket e natyrshme â pĂ«r shembull, fakti i blerjes pĂ«rfaqĂ«sohet lehtĂ«sisht nga objekti âporosiâ ose âfaturĂ«â, vizita nĂ« sajt â nga sesioni, e kĂ«shtu me radhĂ«. Por ka edhe fakte pĂ«r tĂ« cilat nuk Ă«shtĂ« aq e lehtĂ« tĂ« gjendet njĂ« âobjekt bartĂ«sâ i tillĂ« natyror â pĂ«r shembull, gjendja e stokut nĂ« magazina nĂ« fillim tĂ« çdo dite.
PĂ«rkatĂ«sisht, probleme me modularitetin gjatĂ« zgjerimit tĂ« çelĂ«sit tĂ« faktit nĂ« modelin Anchor nuk lindin (mjafton thjesht tĂ« shtohet njĂ« Lidhje e re te Anchor-i pĂ«rkatĂ«s), por projektimi i modelit pĂ«r tĂ« pasqyruar faktet Ă«shtĂ« mĂ« pak i njĂ«kuptimtĂ« dhe mund tĂ« shfaqen Anchor-e âartificialeâ, qĂ« e pasqyrojnĂ« modelin objektor tĂ« biznesit jo nĂ« mĂ«nyrĂ« tĂ« dukshme.
Si arrihet fleksibiliteti
Struktura e pĂ«rftuar nĂ« tĂ« dyja rastet pĂ«rmban dukshĂ«m mĂ« shumĂ« tabela, sesa njĂ« dimension tradicional. Por mund tĂ« zĂ«rĂ« dukshĂ«m mĂ« pak hapĂ«sirĂ« nĂ« disk me tĂ« njĂ«jtin grup atributesh tĂ« versionuara si njĂ« dimension tradicional. Natyrisht, kĂ«tu nuk ka asnjĂ« magji â e gjitha lidhet me normalizimin. Duke i shpĂ«rndarĂ« atributet nĂ«pĂ«r Satellite (nĂ« Data Vault) ose nĂ« tabela tĂ« veçanta (nĂ« Anchor Model), ne zvogĂ«lojmĂ« (ose e eliminojmĂ« plotĂ«sisht) dyfishimin e vlerave tĂ« disa atributeve kur ndryshojnĂ« tĂ« tjerat.
PĂ«r Data Vault pĂ«rfitimi do tĂ« varet nga shpĂ«rndarja e atributeve nĂ«pĂ«r Satellite, ndĂ«rsa pĂ«r Anchor Model â Ă«shtĂ« pothuajse drejtpĂ«rdrejt proporcional me numrin mesatar tĂ« versioneve pĂ«r objekt dimensioni.
Megjithatë, përfitimi në hapësirën e zënë është një avantazh i rëndësishëm, por jo kryesori i ruajtjes së veçuar të atributeve. Së bashku me ruajtjen e veçuar të lidhjeve, një qasje e tillë e bën magazinën e të dhënave një strukturë modulare. Kjo do të thotë se shtimi si i atributeve të veçanta, ashtu edhe i fushave krejtësisht të reja lëndore në një model të tillë, paraqitet si një shtresëzim mbi grupin ekzistues të objekteve pa i ndryshuar ato. Dhe pikërisht kjo i bën fleksibile metodologjitë e përshkruara.
Kjo ngjan edhe me kalimin nga prodhimi artizanal te ai masiv â nĂ«se nĂ« qasjen tradicionale çdo tabelĂ« e modelit Ă«shtĂ« unike dhe kĂ«rkon vĂ«mendje tĂ« veçantĂ«, atĂ«herĂ« nĂ« metodologjitĂ« fleksibile kemi tashmĂ« njĂ« grup âpjesĂ«shâ tipike. Nga njĂ«ra anĂ«, tabelat bĂ«hen mĂ« tĂ« shumta dhe proceset e ngarkimit e tĂ« marrjes sĂ« tĂ« dhĂ«nave duhet tĂ« duken mĂ« komplekse. Nga ana tjetĂ«r, ato bĂ«hen tipike. Dhe kjo do tĂ« thotĂ« se mund tĂ« jenĂ« janĂ« tĂ« automatizuara dhe tĂ« menaxhohen nga metadatat. Pyetja âsi do ta organizojmĂ«?â, pĂ«rgjigjja e sĂ« cilĂ«s mund tĂ« zinte njĂ« pjesĂ« tĂ« konsiderueshme tĂ« punĂ«s gjatĂ« projektimit tĂ« pĂ«rmirĂ«simeve, tani thjesht nuk shtrohet mĂ« (ashtu si edhe pyetja pĂ«r ndikimin e ndryshimit tĂ« modelit mbi proceset qĂ« janĂ« nĂ« funksion).
Kjo nuk do tĂ« thotĂ« se analistĂ«t nĂ« njĂ« sistem tĂ« tillĂ« nuk nevojiten fare â dikush ende duhet tĂ« pĂ«rpunojĂ« grupin e objekteve me atributet pĂ«rkatĂ«se dhe tĂ« kuptojĂ« se nga dhe si do tĂ« ngarkohen tĂ« gjitha kĂ«to. Por vĂ«llimi i punĂ«s, si edhe gjasat dhe kostoja e gabimit, ulen ndjeshĂ«m. Si nĂ« fazĂ«n e analizĂ«s, ashtu edhe gjatĂ« zhvillimit tĂ« ETL, i cili nĂ« njĂ« pjesĂ« tĂ« madhe mund tĂ« reduktohet nĂ« redaktimin e metadatave.
Ana e errët
Gjithçka e pĂ«rshkruar mĂ« sipĂ«r i bĂ«n tĂ« dyja qasjet vĂ«rtet fleksibile, teknologjikisht tĂ« avancuara dhe tĂ« pĂ«rshtatshme pĂ«r pĂ«rmirĂ«sime iterative. Natyrisht, ekziston edhe âana negativeâ, pĂ«r tĂ« cilĂ«n besoj se tashmĂ« e merrni me mend.
Dekompozimi i të dhënave, që qëndron në bazë të modularitetit të arkitekturave fleksibile, çon në rritjen e numrit të tabelave dhe, për rrjedhojë, të kostove shtesë për join-et gjatë marrjes së të dhënave. Për të marrë thjesht të gjitha atributet e një dimensioni, në një depo klasike mjafton një SELECT i vetëm, ndërsa një arkitekturë fleksibile do të kërkojë një varg të tërë join-esh. Madje, nëse për raportet të gjitha këto join-e mund të shkruhen paraprakisht, analistët që janë mësuar ta shkruajnë SQL me dorë do ta ndiejnë këtë dyfish më shumë.
Ka disa fakte që e lehtësojnë këtë situatë:
Gjatë punës me dimensione të mëdha, pothuajse kurrë nuk përdoren njëkohësisht të gjitha atributet e tyre. Kjo do të thotë se join-et mund të jenë më pak nga sa duket në shikim të parë të modelit. Në Data Vault mund të merret parasysh edhe frekuenca e pritshme e përdorimit të përbashkët gjatë shpërndarjes së atributeve nëpër satelitë. Ndërkohë, vetë Hub-et ose Anchor-ët nevojiten kryesisht për gjenerimin dhe mapimin e surrogate-ve në fazën e ngarkimit dhe përdoren rrallë në pyetje (kjo vlen veçanërisht për Anchor-ët).
TĂ« gjitha join-et janĂ« sipas çelĂ«sit. PĂ«r mĂ« tepĂ«r, mĂ«nyra mĂ« âe ngjeshurâ e ruajtjes sĂ« tĂ« dhĂ«nave ul kostot shtesĂ« tĂ« skanimit tĂ« tabelave aty ku kjo Ă«shtĂ« e nevojshme (pĂ«r shembull, gjatĂ« filtrimit sipas vlerĂ«s sĂ« atributit). Kjo mund tĂ« sjellĂ« qĂ« pĂ«rzgjedhja nga njĂ« bazĂ« e normalizuar me shumĂ« join tĂ« jetĂ« madje mĂ« e shpejtĂ« sesa skanimi i njĂ« dimensioni tĂ« vetĂ«m tĂ« rĂ«ndĂ« me shumĂ« versione pĂ«r rresht.
Për shembull, në artikullin ka një test krahasues të detajuar të performancës së modelit Anchor kundrejt përzgjedhjes nga një tabelë e vetme.
Shumëçka varet nga engine-i. ShumĂ« platforma moderne kanĂ« mekanizma tĂ« brendshĂ«m pĂ«r optimizimin e join. PĂ«r shembull, MS SQL dhe Oracle dinĂ« tâi âanashkalojnĂ«â join-et me tabela nĂ«se tĂ« dhĂ«nat e tyre nuk pĂ«rdoren askund tjetĂ«r pĂ«rveç join-eve tĂ« tjera dhe nuk ndikojnĂ« nĂ« pĂ«rzgjedhjen pĂ«rfundimtare (table/join elimination), ndĂ«rsa MPP Vertica, sipas , Ă«shtĂ« treguar si njĂ« engine i shkĂ«lqyer pĂ«r modelin Anchor, me kushtin e njĂ« optimizimi tĂ« caktuar manual tĂ« planit tĂ« query-t. Nga ana tjetĂ«r, ruajtja e modelit Anchor, pĂ«r shembull, nĂ« Click House, i cili ka mbĂ«shtetje tĂ« kufizuar pĂ«r join, pĂ«r momentin nuk duket si ide shumĂ« e mirĂ«.
Përveç kësaj, për të dyja arkitekturat ekzistojnë teknika të posaçme, që lehtësojnë qasjen në të dhëna (si nga këndvështrimi i performancës së query-ve, ashtu edhe për përdoruesit fundorë). Për shembull, tabelat Point-In-Time në Data Vault ose funksione të posaçme tabelare në modelin Anchor.
Përveç kësaj
Thelbi kryesor i arkitekturave fleksibile tĂ« shqyrtuara qĂ«ndron te modulariteti i ândĂ«rtimitâ tĂ« tyre.
Pikërisht kjo veçori bën të mundur:
- Pas njĂ« pĂ«rgatitjeje fillestare, tĂ« lidhur me vendosjen e metadata-ve dhe shkrimin e algoritmeve bazĂ« ETL, tâi ofrohet shpejt klientit rezultati i parĂ« nĂ« formĂ«n e disa raporteve qĂ« pĂ«rmbajnĂ« tĂ« dhĂ«na vetĂ«m nga disa objekte tĂ« burimeve. PĂ«r kĂ«tĂ« nuk Ă«shtĂ« e domosdoshme tĂ« mendohet plotĂ«sisht (madje as nĂ« nivel tĂ« lartĂ«) e gjithĂ« modeli i objekteve.
- Modeli i të dhënave mund të fillojë të funksionojë (dhe të sjellë vlerë) vetëm me 2-3 objekte, e më pas të zgjerohet gradualisht (sa i përket modelit Anchor, Nikolai një krahasim të bukur me micelin).
- Shumica e përmirësimeve, përfshirë zgjerimin e fushës së biznesit dhe shtimin e burimeve të reja, nuk prekin funksionalitetin ekzistues dhe nuk krijojnë rrezik për të prishur diçka që tashmë funksionon.
- Falë dekompozimit në elemente standarde, proceset ETL në sisteme të tilla duken të njëjta, shkrimi i tyre i nënshtrohet algoritmizimit dhe, në fund të fundit, automatizimit.
Kostoja e kĂ«saj fleksibiliteti Ă«shtĂ« e pĂ«rmirĂ«suar. Kjo nuk do tĂ« thotĂ« se Ă«shtĂ« e pamundur tĂ« arrihet njĂ« performancĂ« e pranueshme me modele tĂ« tilla. MĂ« shpesh, thjesht mund tâju nevojiten mĂ« shumĂ« pĂ«rpjekje dhe vĂ«mendje ndaj detajeve pĂ«r tĂ« arritur metrikat e kĂ«rkuara.
Aplikacionet
Llojet e entiteteve Data Vault
Më shumë rreth Data Vault:
Llojet e entiteteve Anchor Model
Më shumë rreth Anchor Model:
Tabelë përmbledhëse me tiparet e përbashkëta dhe dallimet e qasjeve të shqyrtuara:
Burimi: habr.com
