Razvoj TREŽA PODATAKA i prelazak na TRŽIŠTE POSLOVNIH PODATAKA

U prethodnom članku govorio sam o osnovama DATA VAULT-a, opisao glavne elemente DATA VAULT-a i njihovu svrhu. Ovo se ne može smatrati iscrpljenom temom DATA VAULT-a, potrebno je govoriti o narednim koracima u evoluciji DATA VAULT-a.

A u ovom članku ću se fokusirati na razvoj SREŽA PODATAKA i prelazak na POSLOVNI TRŽIŠTE ili jednostavno POSLOVNI TRŽIŠTE.

Razlozi za pojavu SREZA POSLOVNIH PODATAKA

Treba napomenuti da DATA VAULT, iako ima određene prednosti, nije bez svojih nedostataka. Jedan od ovih nedostataka je teškoća u pisanju analitičkih upita. Upiti imaju značajan broj JOIN-ova, kod je dug i glomazan. Takođe, podaci koji ulaze u TRŽIŠTE PODATAKA ne prolaze nikakve transformacije, tako da sa poslovne tačke gledišta DATA VAULT u svom čistom obliku nema apsolutnu vrednost.

Da bi se eliminisali ovi nedostaci, metodologija DATA VAULT je proširena elementima kao što su:

• PIT (tačka u vremenu) tabele;
• BRIDGE stolovi;
• UNAPREĐENE DERIVACIJE.

Pogledajmo bliže svrhu ovih elemenata.

PIT tabele

Tipično, jedan poslovni subjekt (HUB) može sadržavati podatke s različitim stopama ažuriranja, na primjer, ako govorimo o podacima koji karakteriziraju osobu, možemo reći da informacije o broju telefona, adresi ili emailu imaju veću stopu ažuriranja nego recimo, puno ime, podaci o pasošu, bračni status ili spol.

Stoga, prilikom određivanja satelita, treba imati na umu njihovu učestalost ažuriranja. Zašto je to važno?

Ako pohranjujete atribute s različitim stopama ažuriranja u istoj tablici, morat ćete dodati red u tablicu svaki put kada se ažurira atribut koji se najčešće mijenja. Rezultat je povećanje prostora na disku i povećanje vremena izvršenja upita.

Sada kada smo podijelili satelite po učestalosti ažuriranja i možemo samostalno učitavati podatke u njih, trebali bismo osigurati da možemo primati ažurirane podatke. Bolje, bez upotrebe nepotrebnih JOIN-ova.

Dozvolite mi da objasnim, na primjer, trebate dobiti trenutne (prema datumu posljednjeg ažuriranja) informacije sa satelita koji imaju različite stope ažuriranja. Da biste to učinili, morat ćete ne samo napraviti JOIN, već i kreirati nekoliko ugniježđenih upita (za svaki satelit koji sadrži informacije) uz odabir maksimalnog datuma ažuriranja MAX (Datum ažuriranja). Sa svakim novim JOIN-om takav kod raste i vrlo brzo postaje težak za razumijevanje.

PIT tabela je dizajnirana da pojednostavi takve upite; PIT tabele se popunjavaju istovremeno sa upisom novih podataka u DATA VAULT. PIT tabela:

Dakle, imamo informacije o relevantnosti podataka za sve satelite u svakom trenutku. Koristeći JOIN-ove na PIT tablicu, možemo potpuno eliminirati ugniježđene upite, naravno uz uvjet da se PIT popunjava svaki dan i bez praznina. Čak i ako postoje praznine u PIT-u, najnovije podatke možete dobiti samo pomoću jednog ugniježđenog upita za sam PIT. Jedan ugniježđeni upit će se obraditi brže od ugniježđenih upita za svaki satelit.

MOST

BRIDGE tabele se takođe koriste za pojednostavljenje analitičkih upita. Međutim, ono što se razlikuje od PIT-a je sredstvo za pojednostavljivanje i ubrzavanje zahtjeva između različitih čvorišta, linkova i njihovih satelita.

Tabela sadrži sve potrebne ključeve za sve satelite, koji se često koriste u upitima. Osim toga, ako je potrebno, heširani poslovni ključevi mogu biti dopunjeni ključevima u tekstualnom obliku ako su imena ključeva potrebna za analizu.

Činjenica je da će bez korištenja BRIDGE-a, u procesu prijema podataka koji se nalaze na satelitima koji pripadaju različitim čvorištima, biti potrebno izvršiti JOIN ne samo samih satelita, već i linkova koji povezuju čvorišta.

Prisustvo ili odsustvo BRIDGE-a određeno je konfiguracijom skladišta i potrebom da se optimizira brzina izvršavanja upita. Teško je doći do univerzalnog primjera BRIGE-a.

UNAPREĐENE DERIVACIJE

Druga vrsta objekata koji nas približava TRZU POSLOVNIH PODATAKA su tabele koje sadrže unaprijed izračunate indikatore. Takve tabele su zaista važne za poslovanje, sadrže informacije agregirane prema datim pravilima i čine im relativno lakim pristup.

Arhitektonski gledano, PREDEFINIRANE DERIVacije nisu ništa drugo do još jedan satelit određenog čvorišta. On, kao i običan satelit, sadrži poslovni ključ i datum kreiranja zapisa u satelitu. Međutim, tu se sličnosti završavaju. Dalji sastav atributa takvog „specijaliziranog“ satelita određuju poslovni korisnici na osnovu najpopularnijih, unaprijed izračunatih pokazatelja.

Na primjer, čvorište koje sadrži informacije o zaposleniku može uključivati ​​satelit s indikatorima kao što su:

• Minimalna zarada;
• Maksimalna plata;
• Prosječna plata;
• Kumulativni ukupan iznos obračunatih plata, itd.

Logično je uključiti PREDEFINIRANE DERIVACIJE u PIT tabelu istog čvorišta, tada možete lako dobiti isječke podataka za zaposlenog na posebno odabrani datum.

ZAKLJUČCI

Kao što pokazuje praksa, korištenje DATA VAULT-a od strane poslovnih korisnika je donekle otežano iz nekoliko razloga:

• Kôd upita je složen i glomazan;
• Obilje JOIN-ova utiče na performanse upita;
• Pisanje analitičkih upita zahtijeva izvanredno poznavanje dizajna skladišta.

Da bi se pojednostavio pristup podacima, DATA VAULT je proširen dodatnim objektima:

• PIT (tačka u vremenu) tabele;
• BRIDGE stolovi;
• UNAPREĐENE DERIVACIJE.

Sljedeći članak Planiram da ispričam, po mom mišljenju, ono najzanimljivije za one koji rade sa BI. Predstaviću načine za kreiranje tabela činjenica i tabela dimenzija na osnovu DATA VAULT-a.

Materijali članka zasnovani su na:

• U publikacije Kenta Graziano, koji pored detaljnog opisa sadrži modelske dijagrame;
• Knjiga: “Izgradnja skalabilnog skladišta podataka sa DATA VAULT 2.0”;
• Članak Osnove trezora podataka.

izvor: www.habr.com