Dezvoltarea DATA VAULT și tranziția către BUSINESS DATA VAULT.

În articolul anterior, am discutat despre fundamentele DATA VAULT, am descris elementele de bază ale DATA VAULT și scopul fiecăruia dintre acestea. Totuși, subiectul DATA VAULT nu este pe deplin epuizat, așa că este necesar să vorbim despre etapele următoare ale evoluției DATA VAULT.

În acest articol, mă voi concentra pe dezvoltarea DATA VAULT și trecerea la BUSINESS DATA VAULT sau, pur și simplu, BUSINESS VAULT.

Motivele apariției BUSINESS DATA VAULT

Este important de menționat că, deși DATA VAULT are anumite puncte forte, nu este lipsit de slăbiciuni. Una dintre aceste slăbiciuni este dificultatea în scrierea interogărilor analitice. Interogările conțin un număr semnificativ de JOIN-uri, ceea ce face ca codul să devină lung și complicat. De asemenea, datele care ajung în DATA VAULT nu sunt supuse niciunei transformări, astfel că, din perspectiva afacerii, DATA VAULT în forma sa pură nu are o valoare absolută.

Pentru a elimina aceste deficiențe, metodologia DATA VAULT a fost extinsă cu elemente precum:

• tabele PIT (point in time);
• tabele BRIDGE;
• DEFINIții PREDEFINITE.

Haideți să analizăm mai în detaliu scopul acestor elemente.

Tabelele PIT

În general, un singur obiect de afaceri (HUB) poate include date cu frecvențe diferite de actualizare; de exemplu, când vorbim despre date care caracterizează o persoană, putem spune că informațiile despre numărul de telefon, adresă sau email au o frecvență de actualizare mai mare decât, să zicem, numele complet, datele pașaportului, situația familială sau sexul.

Prin urmare, atunci când definim sateliții, trebuie să avem în vedere frecvența actualizărilor acestora. De ce este important acest lucru?

Dacă într-o singură tabelă sunt stocate atribute cu frecvențe diferite de actualizare, va trebui să adăugăm o înregistrare în tabelă la fiecare actualizare a celui mai frecvent modificat atribut. Ca urmare, se va crește volumul de spațiu pe disc și timpul de execuție al interogărilor.

Acum, când am împărțit sateliții în funcție de frecvența actualizării, și putem încărca datele în mod independent, este necesar să asigurăm posibilitatea de a obține date actualizate. Mai bine, fără a utiliza JOIN-uri excesive.

De exemplu, este necesară obținerea de informații actualizate (în funcție de data ultimei actualizări) din sateliți care au frecvențe de actualizare diferite. Pentru aceasta, este necesar nu doar să facem un JOIN, ci și să creăm mai multe interogări imbricate (pentru fiecare satelit ce conține informații) cu alegerea datei maxime a actualizării MAX(Data actualizării). Cu fiecare nou JOIN, astfel de coduri devin mai complexe și foarte repede devin greu de înțeles.

Tabelul PIT are rolul de a simplifica astfel de interogări, iar tabelele PIT se completează simultan cu înscrirea de noi date în DATA VAULT. Tabelul PIT:

Astfel, avem informații despre actualitatea datelor pentru toți sateliții la fiecare moment în timp. Folosind JOIN-uri la tabelul PIT, putem exclude complet interogările imbricate, evident cu condiția ca PIT-ul să fie completat zilnic și fără omisiuni. Chiar și în cazul în care sunt omisiuni în PIT, datele actuale pot fi obținute doar folosind un singur interogare imbricată spre însuși PIT-ul. O singură interogare imbricată va funcționa mai repede decât interogările imbricate către fiecare satelit.

BRIDGE

Tabelele de tip BRIDGE sunt folosite și pentru a simplifica interogările analitice. Totuși, spre deosebire de PIT, acestea servesc la simplificarea și accelerarea interogărilor între diferite hub-uri, link-uri și sateliții acestora.

Tabelul conține toate cheile necesare pentru toți sateliții, care sunt adesea folosite în interogări. În plus, dacă este necesar, cheile de afaceri hash-uite pot fi completate cu chei sub formă de text, dacă denumirile cheilor sunt necesare pentru analiză.

Faptul este că, fără utilizarea BRIDGE, în procesul de obținere a datelor din sateliți aparținând unor hub-uri diferite, va fi nevoie să efectuezi JOIN nu doar între sateliți, ci și între link-urile care leagă hub-urile.

Prezența sau absența BRIDGE este determinată de configurația depozitului, necesitatea optimizării vitezei de execuție a interogărilor. Este dificil să se gândească la un exemplu universal pentru BRIDGE.

PREDEFINED DERIVATIONS

Un alt tip de obiecte care ne apropie de BUSINESS DATA VAULT sunt tabelele care conțin indicatori calculați în prealabil. Aceste tabele sunt cu adevărat importante pentru afaceri, conțin informații agregate în conformitate cu reguli date și permit accesul la acestea relativ simplu.

Derivările PREDEFINED reprezintă, de fapt, un alt satelit al unui anumit hub. La fel ca un satelit obișnuit, conține cheia de afaceri și data de formare a înregistrării în satelit. Totuși, aici se încheie asemănările. Componența ulterioară a atributelor unui astfel de satelit „specializat” este determinată de utilizatorii de afaceri pe baza indicatorilor cei mai solicitați și calculați anterior.

De exemplu, un hub care conține informații despre un angajat poate include un satelit cu astfel de indicatori, cum ar fi:

• Salariul minim;
• Salariul maxim;
• Salariul mediu;
• Totalul salariului acumulat etc.

Este logic să includem DERIVĂRILE PREDEFINED în structura tabelului PIT al acestui hub, astfel încât să putem obține cu ușurință datele despre angajat la o dată specifică.

CONCLUZII

După cum arată experiența, utilizarea DATA VAULT de către utilizatorii de afaceri este puțin complicată din mai multe motive:

• Codul interogărilor este complex și voluminos;
• Abundența JOIN-urilor afectează viteza interogărilor;
• Pentru a scrie interogări analitice este necesară o cunoaștere excelentă a structurii magazinului.

Pentru a simplifica accesul la date, DATA VAULT se extinde cu obiecte suplimentare:

• tabele PIT (point in time);
• tabele BRIDGE;
• DEFINIții PREDEFINITE.

În următoarea pe care l-ați citit Voi prezenta, în opinia mea, cele mai interesante aspecte pentru cei care lucrează cu BI. Voi arăta metodele de creare a tabelelor – fapte și tabele – dimensiuni pe baza DATA VAULT.

Materialele articolului se bazează pe:

• Pe publicației Centa Graziano, care conține, pe lângă descrierea detaliată, schemele modelului;
• Cartea: „Building a Scalable Data Warehouse with DATA VAULT 2.0”;
• Articol Bazele Data Vault.

Sursa: habr.com