Zhvillimi i një depoje është një proces i gjatë dhe serioz.
Shumë në jetën e projektit varet nga sa mirë është menduar modeli objektor dhe struktura e bazës që nga fillimi.
Qasja e pranuar gjerĂ«sisht Ă«shtĂ« njĂ« kombinim i ndryshĂ«m i skemĂ«s 'yll' me formĂ«n e tretĂ« normale. Rregulli Ă«shtĂ«: tĂ« dhĂ«nat origjinale â 3NF, vitrinat â yll. Kjo qasje, e provuar me kalimin e kohĂ«s dhe e mbĂ«shtetur nga shumĂ« studime, Ă«shtĂ« e para (dhe ndonjĂ«herĂ« e vetmja) qĂ« i vjen nĂ« mendje njĂ« eksperti tĂ« DWH-sĂ« kur mendon se si duhet tĂ« duket njĂ« depo analitike.
Nga ana tjetĂ«r, biznesi nĂ« tĂ«rĂ«si dhe kĂ«rkesat e klientit nĂ« veçanti kanĂ« prirjen tĂ« ndryshojnĂ« shpejt, dhe tĂ« dhĂ«nat tĂ« rriten si ânĂ« thellĂ«siâ, ashtu edhe ânĂ« gjerĂ«siâ. Dhe kĂ«tu shfaqet mangĂ«sia kryesore e yllit â e kufizuar. fleksibiliteti.
Dhe nëse në jetën tuaj të qetë dhe komode si zhvillues i DWH-së papritmas:
- u shfaq njĂ« detyrĂ« âtĂ« bĂ«sh diçka shpejt, e mĂ« pas do tĂ« shohimâ;
- u paraqit një projekt në zhvillim të shpejtë, me lidhjen e burimeve të reja dhe riformulimin e modelit të biznesit të paktën një herë në javë;
- u shfaq një klient që nuk e di si duhet të duket sistemi dhe cilat funksione duhet të realizojë, por është i gatshëm për eksperimente dhe për të saktësuar gradualisht rezultatin e dëshiruar me një qasje të ngjashme;
- menaxheri i projektit erdhi me njĂ« lajm tĂ« lumtur: âTani kemi agjil!â
Ose nĂ«se thjesht jeni tĂ« interesuar tĂ« dini si ndryshe mund tĂ« ndĂ«rtohen depot â mirĂ« se erdhĂ«t poshtĂ«!
ĂfarĂ« do tĂ« thotĂ« «fleksibilitet»
Si fillim, le tĂ« pĂ«rcaktojmĂ« se cilat duhet tĂ« jenĂ« vetitĂ« qĂ« sistemi duhet tĂ« ketĂ« pĂ«r ta quajtur âfleksibĂ«lâ.
Veçmas duhet të saktësohet se vetitë e përshkruara duhet të lidhen saktësisht me sistemin, dhe jo me procesin e zhvillimit të tij. Prandaj, nëse kishit dëshirë të lexoni për Agile si një metodologji zhvillimi, është më mirë të njihni materiale të tjera. Për shembull, këtu në Habrë ka shumë materiale interesante (si dhe , ashtu edhe ).
Kjo nuk do të thotë që procesi i zhvillimit dhe struktura e depozitës së të dhënave nuk janë aspak të lidhura. Në përgjithësi, zhvillimi i një depozite me arkitekturë fleksibile duhet të jetë dukshëm më i lehtë duke ndjekur metodologjinë Agile. Megjithatë, në praktikë, janë më të zakonshme variantet që ndjekin metodologjinë Agile për një depozitë të dhënash klasike sipas Kimball dhe Data Vault - në mënyrë tradicionale, sesa përputhjet e lumtura të fleksibilitetit në dy format e tij në një projekt të vetëm.
Pra, cilat janë mundësitë që duhet të ketë një depozitë fleksibile?
- DĂ«rgesa e hershme dhe ripunimi i shpejtĂ« â do tĂ« thotĂ« se nĂ« mĂ«nyrĂ« ideale, rezultati i parĂ« biznesor (pĂ«r shembull, raportet e para funksionale) duhet tĂ« arrihet sa mĂ« shpejt, pra, para se sistemi tĂ« projektohet dhe implementohet plotĂ«sisht. NĂ« kĂ«tĂ« mĂ«nyrĂ«, çdo ripunim tjetĂ«r gjithashtu duhet tĂ« marrĂ« sa mĂ« pak kohĂ« tĂ« jetĂ« e mundur.
- Ripunimi iterativ â kjo do tĂ« thotĂ« se çdo pĂ«rmirĂ«sim i ardhshĂ«m idealisht nuk duhet tĂ« preki funksionalitetin ekzistues. Ky moment shpesh bĂ«het pesha mĂ« e madhe nĂ« projektet e mĂ«dha â atje, ndonjĂ«herĂ« objektet fillojnĂ« tĂ« mbushen me kaq shumĂ« lidhje, sa bĂ«het mĂ« e lehtĂ« tĂ« pĂ«rsĂ«ritni tĂ«rĂ« logjikĂ«n nĂ« njĂ« kopje pranĂ«, sesa tĂ« shtoni njĂ« fushĂ« nĂ« tabelĂ«n ekzistuese. Dhe nĂ«se ju befason fakti qĂ« analiza e ndikimit tĂ« pĂ«rmirĂ«simit nĂ« objektet ekzistuese mund tĂ« marrĂ« mĂ« shumĂ« kohĂ« se vetĂ« pĂ«rmirĂ«simi â me siguri nuk keni punuar ende me HD tĂ« mĂ«dha nĂ« banking ose telekomunikacion.
- Adaptimi i vazhdueshĂ«m ndaj kĂ«rkesave qĂ« ndryshojnĂ« tĂ« biznesit â struktura e pĂ«rgjithshme e objekteve duhet tĂ« projektohet jo vetĂ«m me mendimin pĂ«r zgjerimin e mundshĂ«m, por me llogaritjen se drejtimi i kĂ«tij zgjerimi tĂ« ardhshĂ«m nuk mund tĂ« ishte as nĂ« Ă«ndrrat tuaja nĂ« fazĂ«n e projektimit.
Dhe po, përputhja me të gjitha këto kërkesa në një sistem është e mundur (natyrisht, në raste të caktuara dhe me disa përjashtime).
MĂ« poshtĂ« do tĂ« shqyrtoj dy metodologjitĂ« mĂ« tĂ« njohura pĂ«r dizajnin e fleksibĂ«l nĂ« HD â Modeli Anchor dhe Data Vault. NĂ« prapavijĂ« mbeten teknika tĂ« tilla tĂ« shkĂ«lqyera si EAV, 6NF (nĂ« formĂ«n e saj tĂ« pastĂ«r) dhe gjithçka qĂ« ka tĂ« bĂ«jĂ« me zgjidhjet NoSQL - jo sepse janĂ« ndonjĂ«herĂ« mĂ« ndryshe, as sepse nĂ« kĂ«tĂ« rast artikulli do tĂ« kishte fituar volum tĂ« zakonshĂ«m pĂ«r njĂ« disertacion. Thjesht, tĂ« gjitha kĂ«to i pĂ«rkasin zgjidhjeve tĂ« njĂ« klase ndryshe - ose teknikave qĂ« mund t'i aplikoni nĂ« raste specifike, pavarĂ«sisht nga arkitektura e pĂ«rgjithshme e projektit tuaj (si EAV), ose paradigmat tjetĂ«r nĂ« ruajtjen e informacionit (siç janĂ« bazat e tĂ« dhĂ«nave grafike dhe opsionet e tjera NoSQL).
Problematika e qasjes âklasikeâ dhe zgjidhjet e saj nĂ« metodologjitĂ« fleksibĂ«l
NĂ«n qasjen âklasikeâ kuptoj yllin e vjetĂ«r tĂ« mirĂ« (pavarĂ«sisht nga realizimi konkret i niveleve tĂ« poshtme, le tĂ« mĂ« falin ndjekĂ«sit e Kimball, Inmon dhe CDM).
1. Kardinaliteti i ngurtë i lidhjeve
NĂ« themel tĂ« kĂ«tij modeli Ă«shtĂ« njĂ« ndarje e qartĂ« e tĂ« dhĂ«nave nĂ« dimensione (Dimension) dhe fakte (Fact). Dhe kjo, tĂ« lutem, ka kuptim â sepse analiza e tĂ« dhĂ«nave nĂ« shumicĂ«n e rasteve Ă«shtĂ« nĂ« thelb analiza e treguesve numerikĂ« tĂ« caktuar (fakteve) nĂ« dimensione tĂ« caktuara.
NĂ« tĂ« njĂ«jtĂ«n kohĂ«, lidhjet midis objekteve krijohen nĂ« formĂ«n e lidhjeve midis tabelave pĂ«rmes çelĂ«sit tĂ« jashtĂ«m. Kjo duket krejt natyrale, por menjĂ«herĂ« çon nĂ« kufizimin e parĂ« tĂ« fleksibilitetit â definimi rigoroz i kardinalitetit tĂ« lidhjeve.
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ë shumë-ndaj-shumë, apo vetëm 1-ndaj-shumë, dhe "në çfarë drejtimi". Kjo ka një ndikim të drejtpërdrejtë në cilën nga tabelat do të jetë çelësi primar dhe në cilën do të jetë çelësi i jashtëm. Ndryshimi i këtij marrëdhënieje me kërkesat e reja me probabilitet të madh do të sjellë një riprodhim të bazës.
PĂ«r shembull, nĂ« projektimin e objektit âfaturĂ« kasaforteâ ju, duke u mbĂ«shtetur nĂ« premtimet e forta tĂ« departamentit tĂ« shitjeve, keni parashikuar mundĂ«sinĂ« e veprimit tĂ« njĂ« promovimi nĂ« disa pozita faturale (por jo e kundĂ«rta):
Dhe pas një kohe të caktuar, kolegët lanë në fuqi një strategji të re marketingu, sipas së cilës në një pozicion të njëjtë mund të veprojnë më shumë promovime njëkohësisht. Dhe tani duhet të përmirësoni tabelat, duke e ndarë lidhjen në një objekt të veçantë.
(Të gjitha objektet derivat, në të cilat ndodhi lidhja e promovimeve, tani kërkojnë gjithashtu përmirësim).
Lidhjet në Data Vault dhe Anchor Model
Ishte mjaft e thjeshtë të shmangim një situatë të tillë: nuk duhet të besoni departamentin e shitjeve, për këtë është e mjaftueshme të ruani të gjitha lidhjet që në fillim në tabela të ndara dhe t'i procesoni si shumë-me-shumë.
Ky qasje u propozua nga Dan Linstedt si pjesë e paradigmës Data Vault dhe u mbështet plotësisht nga Lars RönnbÀck në Modeli Ankor (Anchor Model).
Si rezultat, ne kemi karakteristikën e parë dalluese të metodologjive fleksibile:
Lidhjet midis objekteve nuk ruhen në atributet e entiteteve prind, por përfaqësojnë një lloj të veçantë objekti.
NĂ« Data Vault kĂ«to tabela lidhĂ«se quhen Link, ndĂ«rsa nĂ« Modeli Ankor â Tie. NĂ« pamje tĂ« parĂ« ato duken shumĂ« tĂ« ngjashme, megjithĂ«se dallimet e tyre nuk pĂ«rfundojnĂ« vetĂ«m me emrin (pĂ«r kĂ«tĂ« do tĂ« flasim mĂ« poshtĂ«). NĂ« tĂ« dyja arkitekturave, tabelat lidhĂ«se mund tĂ« lidhin çdo numĂ«r entitetesh (nuk Ă«shtĂ« e domosdoshme tĂ« jenĂ« vetĂ«m 2).
Kjo duket si teprim nĂ« pamje tĂ« parĂ«, por ofron njĂ« fleksibilitet tĂ« konsiderueshĂ«m kur bĂ«het fjalĂ« pĂ«r pĂ«rmirĂ«sime. Kjo strukturĂ« bĂ«het tolerante jo vetĂ«m ndaj ndryshimeve tĂ« kardinalitetit tĂ« lidhjeve ekzistuese, por edhe ndaj shtimit tĂ« tĂ« rinjve â nĂ«se tani njĂ« pozite fature i shtohet gjithashtu njĂ« lidhje me kasierin qĂ« e ka regjistruar, krijimi i njĂ« lidhjeje tĂ« tillĂ« do tĂ« bĂ«het thjesht njĂ« shtesĂ« mbi tabelat ekzistuese, pa ndikuar nĂ« ndonjĂ« objekt ose proces ekzistues.
2. Dupnikimi i të dhënave
Problemi i dytë që zgjidhet nga arkitekturave fleksibile është më pak i dukshëm dhe është veçanërisht i lidhur me matjet e tipit SCD2 (matje që ndryshojnë ngadalë të tipit të dytë), megjithatë, nuk është vetëm për to.
Në një magazinë klasike, një masë zakonisht përfaqëson një tabelë që përmban një çelës surrogat (si PK) si dhe një grup çelësash biznesi dhe atributesh në kolona të ndara.
Nëse matja mbështet versionimin, një grup standard i fushave shtohet me kufij të kohës së vlefshmërisë së versionit, dhe në një rresht në burim shfaqen disa versione në magazinë (një për çdo ndryshim të atributeve të versionit).
NĂ«se matja pĂ«rmban tĂ« paktĂ«n njĂ« atribut versioni qĂ« ndryshohet shpesh, numri i versioneve tĂ« tillĂ« tĂ« matjes do tĂ« jetĂ« mbresĂ«lĂ«nĂ«s (edhe nĂ«se atributet e tjera nuk janĂ« versionuese, ose kurrĂ« nuk ndryshojnĂ«), dhe nĂ«se ka disa tĂ« tillĂ« â numri i versioneve mund tĂ« rritet nĂ« mĂ«nyrĂ« geometrike nga numri i tyre. NjĂ« matje e tillĂ« mund tĂ« zĂ«rĂ« njĂ« hapĂ«sirĂ« tĂ« konsiderueshme nĂ« disk, ndonĂ«se pjesa mĂ« e madhe e tĂ« dhĂ«nave tĂ« ruajtura nĂ« tĂ« janĂ« thjesht kopje tĂ« vlerave tĂ« atributeve tĂ« pandryshueshme nga rreshta tĂ« tjerĂ«.
NĂ« kĂ«tĂ« rast, shpesh pĂ«rdoret gjithashtu denormalizimi â disa atribute qĂ«llimisht ruhet si vlerĂ«, e jo si lidhje me njĂ« referencĂ« ose njĂ« matje tjetĂ«r. Ky qasje pĂ«rshpejton qasjen nĂ« tĂ« dhĂ«na, duke reduktuar numrin e bashkimeve kur aksesohen matjet.
Si rregull, kjo çon nĂ« atĂ« qĂ« informacioni i njĂ«jtĂ« ruhet njĂ«kohĂ«sisht nĂ« vendet e ndryshme. PĂ«r shembull, informacioni mbi rajonin e banimit dhe pĂ«rkatĂ«sinĂ« e kategorisĂ« sĂ« klientit mund tĂ« ruhet njĂ«kohĂ«sisht nĂ« dimensionet âKlientiâ, dhe faktet âBlerjaâ, âDĂ«rgimiâ dhe âKontaktet me qendrĂ«n e thirrjeveâ, si dhe nĂ« tabelĂ«n lidhĂ«se âKlienti â Menaxheri i klientitâ.
NĂ« pĂ«rgjithĂ«si, e pĂ«rshkruar mĂ« sipĂ«r i pĂ«rket gjithashtu dimensioneve tĂ« zakonshme (jo versionuese), por nĂ« versionet mund tĂ« ketĂ« njĂ« shkallĂ« tĂ« ndryshme: shfaqja e njĂ« versioni tĂ« ri tĂ« objektit (sidomos retrospektivisht), çon jo vetĂ«m nĂ« pĂ«rditĂ«simin e tĂ« gjithĂ« tabelave tĂ« lidhura, por nĂ« shfaqjen kaskadĂ« tĂ« versioneve tĂ« reja tĂ« objekteve tĂ« lidhura â kur Tabela 1 pĂ«rdoret pĂ«r ndĂ«rtimin e TabelĂ«s 2, dhe Tabela 2 â pĂ«r ndĂ«rtimin e TabelĂ«s 3 dhe kĂ«shtu me radhĂ«. Edhe nĂ«se asnjĂ« atribut i TabelĂ«s 1 nuk merr pjesĂ« nĂ« ndĂ«rtimin e TabelĂ«s 3 (pĂ«rveç se atributet e tjera tĂ« TabelĂ«s 2, tĂ« marra nga burime tĂ« tjera), pĂ«rditĂ«simi versionues i kĂ«saj ndĂ«rtese do tĂ« sjellĂ« sĂ« paku shpenzime tĂ« shtuara, dhe nĂ« maksimum â versionet e pajustifikuara nĂ« TabelĂ«n 3, e cila kĂ«tu Ă«shtĂ« âjashtĂ«â, dhe kĂ«shtu me radhĂ«.
3. Kompleksiteti jo linear i përmirësimit
Kështu, çdo vitrinë e re që ndërtohet mbi një tjetër rrit numrin e vendeve ku të dhënat mund të "shkërmoqen" kur bëhen ndryshime në ETL. Kjo, nga ana tjetër, çon në rritjen e kompleksitetit (dhe, kohëzgjatjes) së çdo përmirësimi tjetër.
NĂ«se pĂ«rshkrimi mĂ« sipĂ«r i referohet sistemeve me procese ETL qĂ« modifikohen rrallĂ«, Ă«shtĂ« e mundur tĂ« jetosh nĂ« kĂ«tĂ« paradgim â mjafton tĂ« kujdesesh qĂ« pĂ«rmirĂ«simet e reja tĂ« pĂ«rfshihen nĂ« mĂ«nyrĂ« korrekte nĂ« tĂ« gjitha objektet e lidhura. Por nĂ«se pĂ«rmirĂ«simet ndodhin shpesh, probabiliteti pĂ«r tĂ« "humbur" disa lidhje rritet dukshĂ«m.
Dhe duke marrë parasysh se ETL "me version" është dukshëm më i komplikuar se ETL "pa version", shmangia e gabimeve gjatë përmirësimeve të shpeshta të këtij sistemi bëhet mjaft e vështirë.
Ruajtja e objekteve dhe atributeve në Data Vault dhe Modelin Anchor
Qasja e propozuar nga autorët e arkitekturave fleksible mund të formulohet kështu:
Duhet të ndahen ato që ndryshojnë nga ato që mbeten të pandryshuara. Prandaj, duhet të ruhen çelësat veçmas nga atributet.
MegjithatĂ«, nuk duhet tĂ« ngatĂ«rrohet ETL pa version atributi me tĂ« pandryshueshĂ«m: i pari nuk e ruan historinĂ« e ndryshimeve tĂ« tij, por mund tĂ« ndryshojĂ« (pĂ«r shembull, kur korrigjohet njĂ« gabim-inputi ose merrni tĂ« dhĂ«na tĂ« reja) i dyti â nuk ndryshon kurrĂ«.
Pikëpamjet mbi atë se çfarë mund të konsiderohet si të pandryshueshme në Data Vault dhe Modelin Anchor janë të ndryshme.
Nga kĂ«ndvĂ«shtrimi arkitekturor Data Vault, e pandryshueshme mund tĂ« konsiderohet i gjithĂ« seti i çelĂ«save â natyralĂ« (NIPT i organizatĂ«s, kodi i produktit nĂ« sistemin burimor etj.) dhe surrogate. NĂ« tĂ« njĂ«jtĂ«n kohĂ«, atributet e tjera mund tĂ« ndahen nĂ« grupe sipas burimit dhe/ose frekuencĂ«s sĂ« ndryshimeve dhe pĂ«r çdo grup tĂ« mbahet njĂ« tabelĂ« e veçantĂ« me njĂ« set tĂ« pavarur versionesh.
MegjithatĂ«, nĂ« paradigmat Modeli Anchor e pandryshueshme konsiderohet vetĂ«m çelĂ«si surrogate i entitetit. E gjithĂ« e tjera (pĂ«rfshirĂ« çelĂ«sat natyralĂ«) â Ă«shtĂ« thjesht njĂ« rast i veçantĂ« i atributeve tĂ« tij. NĂ« tĂ« njĂ«jtĂ«n kohĂ« tĂ« gjitha atributet janĂ« nĂ« parim tĂ« pavarura nga njĂ«ra-tjetra, prandaj pĂ«r çdo atribut duhet tĂ« krijohet njĂ« tabelĂ« tĂ« veçantĂ«.
Në Data Vault tabelat që përmbajnë çelësat e entiteteve quhen Haba (Hub). Hubat gjithmonë përmbajnë një set fikse fushash:
- ĂelĂ«sat natyralĂ« tĂ« entitetit
- ĂelĂ«si surrogate
- Referenca në burim
- Koha e shtimit të regjistrimit
Regjistrimet në Haba kurr pavarësisht dhe nuk kanë versione. Ndërsa htet janë shumë të ngjashme me tabelat e llojit ID-map, të përdorura në disa sisteme për të gjeneruar surrogates, në Data Vault rekomandohet të përdoren jo një skeden integeri, por një hash nga grupi i çelësave të biznesit. Ky qasje thjeshton ngarkimin e lidhjeve dhe atributeve nga burimet (nuk është e nevojshme të bashkohemi me htet për të marrë një surrogate, mjafton të llogarisim hashin nga çelësi natyral), por mund të shkaktojë probleme të tjera (të lidhura, për shembull, me kolizionet, regjistrin dhe karakteret e padukshme në çelësat string etj.), prandaj nuk është praktikë e zakonshme.
Të gjitha atributet e tjera të entiteteve ruhen në tabela speciale, të quajtura Satelitë (Satellit). Një hët mund të ketë disa satelitë që ruajnë grupe të ndryshme atributesh.
ShpĂ«rndarja e atributeve nĂ« satelitĂ« ndodh sipas parimit tĂ« ndryshimit tĂ« pĂ«rbashkĂ«t â nĂ« njĂ« satelit mund tĂ« ruhen atribute jo versionale (p.sh., data e lindjes dhe SNILS pĂ«r individĂ«t), nĂ« njĂ« tjetĂ«r â atribute versionale me ndryshime tĂ« rralla (p.sh., mbiemri dhe numri i pasaportĂ«s), nĂ« njĂ« tĂ« tretĂ« â atribute qĂ« ndryshojnĂ« shpesh (p.sh., adresa e dĂ«rgimit, kategoria, data e porosisĂ« sĂ« fundit etj.). Versionaliteti mbahet nĂ« nivelin e satelitĂ«ve tĂ« veçantĂ«, jo tĂ« entitetit nĂ« tĂ«rĂ«si, prandaj shpĂ«rndarja e atributeve duhet bĂ«rĂ« nĂ« mĂ«nyrĂ« qĂ« pĂ«rputhja e versioneve brenda njĂ« sateliti tĂ« jetĂ« minimale (çka redukton numrin e pĂ«rgjithshĂ«m tĂ« versioneve tĂ« ruajtura).
Gjithashtu, për të optimizuar procesin e ngarkesës së të dhënave, atribute të marra nga burime të ndryshme shpesh vendosen në satelite të veçanta.
SatelitĂ«t lidhen me Hubin pĂ«rmes çelĂ«sit tĂ« jashtĂ«m (e cila pĂ«rkon me kardinalitetin 1-mĂ« shumĂ«). Kjo do tĂ« thotĂ« qĂ« vlera tĂ« shumta atribute (p.sh., disa numra kontakti pĂ«r njĂ« klient tĂ« vetĂ«m) mbĂ«shtetet nga kjo arkitekturĂ« âpĂ«r defaultâ.
Në Modeli i Ankorës (Anchor Model) tabelat që ruajnë çelësat quhen Ankora (Anchor). Dhe ato ruajnë:
- Vetëm çelësa surrogat
- Referenca në burim
- Koha e shtimit të regjistrimit
ĂelĂ«sat natyrorĂ« sipas Modelit tĂ« AnkorĂ«s konsiderohen atribute tĂ« zakonshme. Ky variant mund tĂ« duket mĂ« i komplikuar pĂ«r tu kuptuar, por ofron shumĂ« mĂ« tepĂ«r hapĂ«sirĂ« pĂ«r identifikimin e objektit.
Për shembull, nëse të dhënat për një entitet të njëjtë mund të vijnë nga sisteme të ndryshme, të cilat përdorin secila çelësin e saj natyror. Në Data Vault, kjo mund të çojë në konstruksione mjaft të ndërlikuara me disa qendra (një për burimin + një version master bashkues), ndërsa në modelin e Ankorës çelësi natyror i secilit burim bie në atributin e tij dhe mund të përdoret gjatë ngarkimit, pavarësisht nga të tjerët.
Por këtu ndodhet një moment i trukosur: nëse në një entitet bashkohen atribute nga sisteme të ndryshme, me siguri ekzistojnë disa rregulla "bashkimit", sipas të cilave sistemi duhet të kuptojë se regjistrimet nga burime të ndryshme i përkasin një shembulli të vetëm të entitetit.
Në Data Vault këto rregulla ndoshta do të përcaktojnë formimin "qendrës surrogate" të entitetit master dhe nuk do të ndikojë aspak në Hubs, që ruajnë çelësat natyrorë të burimeve dhe atributet e tyre origjinale. Nëse në ndonjë moment rregullat e bashkimit ndryshojnë (ose vjen një përditësim i infrastrukturës, në të cilin kryhet), do të mjaftonte të riformatohej hub-i surrogat.
Në Modeli i ankorës kjo entitet do të ruhet më shumë në një ankorë të vetme. Kjo do të thotë se të gjitha atributet, pavarësisht se nga cili burim janë marrë, do të jenë të lidhura me të njëjtin surrogat. Të ndajmë regjistrimet e bashkuara gabimisht dhe të ndjekim në përgjithësi aktualitetin e bashkimit në një sistem të tillë mund të jetë dhimbje më e madhe, sidomos nëse rregullat janë mjaft komplekse dhe ndryshojnë shpesh, dhe i njëjti atribut mund të merret nga burime të ndryshme (ndonëse është e mundur saktësisht, pasi çdo version atributi ruan një lidhje me burimin e tij).
Sidoqoftë, nëse sistemi juaj parashikon realizimin e funksionaliteteve të dedublikimit, bashkimit të regjistrimeve dhe elementeve të tjera MDM, është veçanërisht e rëndësishme të bëni kujdes me aspektet e ruajtjes së çeljeve natyrore në metodologjitë fleksibile. Ndoshta, një konstrukcion më i komplikuar Data Vault do të rezultojë të jetë më i sigurt në pikëpamje të gabimeve të bashkimit.
Modeli Yll po ashtu parashikon një lloj objekti shtesë, të quajtur Knot është thelbësisht një formë e veçantë e yllit, i cili mund të përmbajë vetëm një atribut. Nodet parashikohen të përdoren për ruajtjen e listave të sheshta (p.sh., plaku, stati civil, kategoria e shërbimit të klientëve etj.). Ndryshe nga Ylli, Node nuk ka tabela të lidhura mbi atributet, dhe atributi i tij i vetëm (emri) gjithmonë ruhet në një tabelë me çelësin. Node lidhën me Yllin përmes tabelave të lidhjeve (Tie) ashtu si yjet me njëri-tjetrin.
Nuk ka një mendim të qartë në lidhje me përdorimin e Nodeve. Për shembull, , që promovon aktivisht përdorimin e Modelit Yll në Rusi, mendon (pa argumente të pabazuara) se asnjë përfaqësues nuk mund të pranohet se ai përherë do të jetë statik dhe njënivelësh, prandaj për të gjitha objektet është më mirë të përdoret menjëherë një Ankor i plotë.
Një tjetër ndryshim i rëndësishëm midis Data Vault dhe modelit Ankor është prania e atributeve te lidhjeve:
Në Data Vault Lidhjet janë objekte të plota, ashtu si Hubs, dhe mund të kenë atributet e tyre. Në Modeli i ankorës Lidhjet përdoren vetëm për të lidhur Ankorët dhe nuk mund të kenë atribute të tyre. Ky ndryshim ofron qasje të ndryshme në modelimin e fakteve, për të cilat do të flasim më poshtë.
Ruajtja e fakteve
Derisa deri tani kemi folur kryesisht për modelimin e dimensioneve, për faktet gjërat janë pak më pak të qarta.
Në Data Vault objekti tipik për ruajtjen e fakteve është Lidhja (Link), në Satalitët e së cilës grumbullohen treguesit real.
Ky qasje duket intuitivisht e kuptueshme. Ofron akses tĂ« thjeshtĂ« nĂ« treguesit e analizuar dhe pĂ«rgjithĂ«sisht Ă«shtĂ« e ngjashme me tabelĂ«n tradicionale tĂ« fakteve (vetĂ«m se treguesit nuk ruhen nĂ« tabelĂ«n e vet, por nĂ« 'fqinjin'). Por ka edhe pengesa: njĂ« nga pĂ«rmirĂ«simet e zakonshme tĂ« modelit â zgjerimi i çelĂ«sit tĂ« faktit â shkakton nevojĂ«n pĂ«r tĂ« shtuar njĂ« çelĂ«s tĂ« ri tĂ« jashtĂ«m nĂ« Link. Kjo, nga ana tjetĂ«r, "prish" modularitetin dhe potencialisht shkakton nevojĂ«n pĂ«r korrigjime tĂ« objekteve tĂ« tjera.
NĂ« Modeli i ankorĂ«s Lidhja nuk mund tĂ« ketĂ« atributet e saj, prandaj ky qasje nuk funksionon â tĂ« gjitha atributet dhe treguesit duhet tĂ« jenĂ« tĂ« lidhur me njĂ« ankorĂ« tĂ« caktuar. Konkluzioni Ă«shtĂ« i thjeshtĂ« â pĂ«r çdo fakt nevojitet njĂ« ankorĂ« e tij.. PĂ«r disa nga ato qĂ« ne i percekojmĂ« si fakte, kjo mund tĂ« duket natyrale â pĂ«r shembull, fakti i blerjes lidhet pĂ«rkryer me objektin "porosi" ose "cek", vizita nĂ« sit â me sesionin etj. Por ka edhe fakte pĂ«r tĂ« cilat nuk Ă«shtĂ« aq e lehtĂ« tĂ« gjejmĂ« njĂ« "objekt-mbajtĂ«s" natyral â pĂ«r shembull, mbetjet e produkteve nĂ« magazinat nĂ« fillim tĂ« çdo dite.
Prandaj, nuk ka probleme me modularitetin kur zgjerohet çelĂ«si i faktit nĂ« Modelin Ankor â mjafton tĂ« shtosh njĂ« Lidhje tĂ« re me ankorĂ«n pĂ«rkatĂ«se, por projektimi i modelit pĂ«r paraqitjen e fakteve Ă«shtĂ« mĂ« pak e qartĂ«, mund tĂ« shfaqen "ankora artificiale", qĂ« paraqesin modelin objektor tĂ« biznesit nĂ« mĂ«nyrĂ« tĂ« paqartĂ«.
Si arrihet fleksibiliteti
Struktura e krijuar nĂ« tĂ« dy rastet pĂ«rmban nĂ« mĂ«nyrĂ« tĂ« konsiderueshme mĂ« shumĂ« tabela, sesa matja tradicionale. Por mund tĂ« marrĂ« nĂ« mĂ«nyrĂ« tĂ« konsiderueshme mĂ« pak hapĂ«sirĂ« diskore me tĂ« njĂ«jtin set atributesh versioni si matja tradicionale. Natyrisht, nuk ka magji â Ă«shtĂ« çështje normalizimi. Duke shpĂ«rndarĂ« atributet nĂ« SatelitĂ« (nĂ« Data Vault) ose tabela tĂ« veçanta (Modeli Anchor), ne zvogĂ«lojmĂ« (ose pĂ«rjashtojmĂ« krejtĂ«sisht) dyfishimin e vlerave tĂ« disa atributeve kur ndryshojnĂ« tĂ« tjerĂ«.
PĂ«r Data Vault fitimi do tĂ« varet nga shpĂ«rndarja e atributeve nĂ« SatelitĂ«, dhe pĂ«r Modeli i ankorĂ«s â nĂ« praktikĂ« Ă«shtĂ« proporcional me numrin mesatar tĂ« versioneve pĂ«r objektin e matjes.
Megjithatë, fitimi në hapësirën e marrë është një përfitim i rëndësishëm, por jo kryesor i ruajtjes së veçantë të atributeve. Së bashku me ruajtjen e veçantë të lidhjeve, ky qasje e bën magazinën një konstruksion modular. Kjo do të thotë se shtimi i atributeve të veçanta, si dhe i tërë zonave të reja tematike në një model të tillë duket si një shtesë mbi setin ekzistues të objekteve pa i ndryshuar ato. Dhe kjo është pikërisht ajo që bën metodologjitë e përshkruara fleksibël.
Kjo gjithashtu i ngjan kalimit nga prodhimi artesanal nĂ« atĂ« masiv â nĂ«se nĂ« qasjen tradicionale çdo tabelĂ« modeli Ă«shtĂ« unikale dhe kĂ«rkon vĂ«mendje tĂ« veçantĂ«, nĂ« metodologjitĂ« fleksibile, ato janĂ« tashmĂ« njĂ« grup âdetajeshâ standarde. Nga njĂ«ra anĂ«, numri i tabelave rritet, proceset e ngarkimit dhe nxjerrjes sĂ« tĂ« dhĂ«nave duhet tĂ« duken mĂ« tĂ« komplikuara. Nga ana tjetĂ«r, ato bĂ«hen standard. Pra, ato mund tĂ« jenĂ« tĂ« automatizuara dhe tĂ« menaxhuara nga metadat. Pyetja âsi do t'i vendosim?â, pĂ«rgjigja e sĂ« cilĂ«s mund tĂ« zinte njĂ« pjesĂ« tĂ« rĂ«ndĂ«sishme tĂ« punĂ«s nĂ« projektimin e ndryshimeve, tani thjesht nuk egziston (ashtu si pyetja nĂ«se ndryshimi i modelit do tĂ« ndikojĂ« nĂ« proceset nĂ« funksion).
Kjo nuk do tĂ« thotĂ« se analistĂ«t nĂ« njĂ« sistem tĂ« tillĂ« nuk janĂ« tĂ« nevojshĂ«m fare â dikush ende duhet tĂ« pĂ«rpunojĂ« njĂ« grup objektesh me atribute dhe tĂ« kuptojĂ« se nga ku dhe si do tĂ« ngarkohet gjithĂ« kjo. Por volumi i punĂ«s, si dhe probabiliteti dhe kostoja e gabimit, zvogĂ«lohen ndjeshĂ«m. Si nĂ« fazĂ«n e analizĂ«s, ashtu edhe nĂ« zhvillimin e ETL, i cili nĂ« pjesĂ«n mĂ« tĂ« madhe mund tĂ« reduktohet nĂ« redaktimin e metadatas.
Anija e errët
E gjithë ajo që u përmend më sipër e bën të dyja qasjet vërtet fleksibile, teknologjike dhe të përshtatshme për përmirësim iterativ. Natyrisht, ka dhe një "barrelë katran", për të cilën, mendoj, tashmë jeni duke u menduar.
Dekompilimi i të dhënave, që është bazë e modularitetit të arkitekturave fleksibile, çon në rritjen e numrit të tabelave dhe, për pasojë, kostos së mbulimit për bashkëveprimin gjatë tërheqjes. Për të marrë thjesht gjitha atributet e matjes, në një magazinë klasike mjafton një selektim, ndërsa arkitektura fleksibile kërkon një seri të tërë bashkëveprimesh. Kjo është veçanërisht e vështirë për analistët që janë të zakonshëm në shkrimin e SQL-it me dorë.
Ka disa fakte që lehtësojnë këtë situatë:
Gjatë punës me përmasa të mëdha, pothuajse kurrë nuk përdoren të gjitha atributet e saj njëkohësisht. Kjo do të thotë se numri i bashkimeve mund të jetë më i vogël se sa duket në pamje të parë në model. Në Data Vault mund të merret parasysh gjithashtu frekuenca e supozuar e bashkëpërdorimit kur shpërndahen atributet në satellite. Megjithatë, Habbat ose Ankorët kanë nevojë kryesisht për gjenerimin dhe mapimin e zëvendësuesve në fazën e ngarkimit dhe përdoren rrallë në pyetje (veçanërisht kjo e vlen për Ankorët).
Të gjitha bashkimet janë sipas çelësit. Për më tepër, një mënyrë më "e ngjeshur" e ruajtjes së të dhënave ul kostot e skanimit të tabelave atje ku është e nevojshme (p.sh., kur filtrohet sipas vlerës së atributit). Kjo mund të rezultojë në mënyrë që tërheqja nga një bazë e normalizuar me shumë bashkime të jetë edhe më e shpejtë sesa skanimi i një dimensioni të rëndë me shumë versione në rresht.
Për shembull, këtu është në artikullin ka një test të detajuar krahasimi të performancës së modelit Ankor me tërheqjen nga një tabelë.
Shumë varet nga motori. Shumë nga platformat moderne kanë mekanizma të brendshëm për optimizimin e bashkimeve. Për shembull, MS SQL dhe Oracle dinë të "kalojnë" bashkimet me tabela, nëse të dhënat e tyre nuk përdoren askund tjetër, përveç bashkimeve të tjera dhe nuk ndikojnë në zgjedhjen përfundimtare (eliminimi i tabelave/bashkimeve), ndërsa MPP Vertica, në , e ka treguar vetveten si një motor të shkëlqyer për Modelin Anker me disa optimizime manuale të planit të kërkesës. Nga ana tjetër, ruajtja e Modelit Anker, për shembull, në Click House, i cili ka mbështetje të kufizuar për bashkime, deri tani duket si një ide jo shumë e mirë.
Për më tepër, për të dyja arkitekturën ekzistojnë trika të veçanta, që lehtësojnë qasjen në të dhëna (si nga këndvështrimi i performancës së kërkesave, ashtu edhe për përdoruesit të fundit). Për shembull, tabelat Point-In-Time në Data Vault ose funksionet e veçanta të tabelave në Modelin Anker.
Në përfundim
Essenca kryesore e arkitekturave fleksibile të shqyrtuara është modulariteti i "ndërtimeve" të tyre.
Ky të qenit lejon:
- Pas një përgatitjeje fillestare, e lidhur me shpërndarjen e metadatan dhe shkruarjen e algoritmave bazë ETL, të ofrohet shpejt rezultati i parë për klientin në formën e disa raporteve që përmbajnë të dhëna nga disa objekte burimesh. Nuk është e nevojshme të mendosh plotësisht (edhe në një nivel të lartë) për modelin e të gjitha objekteve për këtë.
- Modeli i të dhënave mund të fillojë të funksionojë (dhe të sjellë përfitime) me vetëm 2-3 objekte, dhe pastaj të rritet gradualisht (në lidhje me modelin e ankorimit, Nikolai një krahasim të bukur me myshkun).
- Shumica e përmirësimeve, duke përfshirë zgjerimin e fushës së subjektit dhe shtimin e burimeve të reja nuk prek funksionalitetin ekzistues dhe nuk paraqet rrezik për të prishur diçka që tashmë funksionon..
- Falë dekompozimit në elemente standarte, proceset ETL në këto sisteme duken uniforme, shkrimi i tyre është i përshtatshëm për algoritmizim dhe, në fund, automatik..
Kostoja e një fleksibiliteti të tillë është performanca. Kjo nuk do të thotë se arritja e një performancë të pranueshme në këto modele është e pamundur. Shpesh, thjesht mund t'ju nevojitet më shumë përpjekje dhe vëmendje ndaj detajeve për të arritur metrikat e dëshiruara.
Aplikacionet
Llojet e entiteteve Data Vault
Më shumë mbi Data Vault:
Llojet e entiteteve Modeli Anchor
Më shumë rreth Modelit Anchor:
Tabela përmbledhëse me karakteristikat dhe dallimet e qasjeve të shqyrtuara:
Burimi: habr.com
