În articolul anterior, am vorbit despre elementele de bază ale DATA VAULT, am descris principalele elemente ale DATA VAULT și scopul lor. Acesta nu poate fi considerat subiectul DATA VAULT ca fiind epuizat, este necesar să vorbim despre următorii pași în evoluția DATA VAULT.
Și în acest articol mă voi concentra pe dezvoltarea DATA VAULT și trecerea la BUSINESS DATA VAULT sau pur și simplu BUSINESS VAULT.
Motive pentru apariția BUSINESS DATA VAULT
Trebuie remarcat faptul că DATA VAULT, deși are anumite puncte forte, nu este lipsită de dezavantaje. Unul dintre aceste dezavantaje este dificultatea de a scrie interogări analitice. Interogările au un număr semnificativ de JOIN-uri, codul este lung și greoi. De asemenea, datele care intră în DATA VAULT nu suferă nicio transformare, prin urmare, din punct de vedere al afacerii, DATA VAULT în forma sa pură nu are valoare absolută.
Pentru a elimina aceste neajunsuri, metodologia DATA VAULT a fost extinsă cu elemente precum:
- tabele PIT (punct în timp);
- mese BRIDGE;
- DERIVAȚII PREDEFINITATE.
Să aruncăm o privire mai atentă asupra scopului acestor elemente.
tabele PIT
De obicei, o entitate comercială (HUB) poate conține date cu rate de actualizare diferite, de exemplu, dacă vorbim despre date care caracterizează o persoană, putem spune că informațiile despre un număr de telefon, adresă sau e-mail au o rată de actualizare mai mare decât să spunem, numele complet, detaliile pașaportului, starea civilă sau sexul.
Prin urmare, atunci când determinați sateliți, ar trebui să aveți în vedere frecvența lor de actualizare. De ce este important?
Dacă stocați atribute cu rate de actualizare diferite în același tabel, va trebui să adăugați un rând la tabel de fiecare dată când este actualizat atributul modificat cel mai frecvent. Rezultatul este o creștere a spațiului pe disc și o creștere a timpului de execuție a interogărilor.
Acum că am împărțit sateliții după frecvența de actualizare și că putem încărca date în ei independent, ar trebui să ne asigurăm că putem primi date actualizate. Mai bine, fără a utiliza JOIN-uri inutile.
Permiteți-mi să vă explic, de exemplu, trebuie să obțineți informații actuale (în funcție de data ultimei actualizări) de la sateliți care au rate de actualizare diferite. Pentru a face acest lucru, va trebui nu numai să faceți un JOIN, ci și să creați mai multe interogări imbricate (pentru fiecare satelit care conține informații) cu selectarea datei maxime de actualizare MAX (Update Date). Cu fiecare nou JOIN, un astfel de cod crește și devine foarte repede dificil de înțeles.
Tabelul PIT este conceput pentru a simplifica astfel de interogări; tabelele PIT sunt completate simultan cu scrierea datelor noi în DATA VAULT. Tabel PIT:
Astfel, avem informații despre relevanța datelor pentru toți sateliții la fiecare moment în timp. Folosind JOIN-uri la tabelul PIT, putem elimina complet interogările imbricate, desigur cu condiția ca PIT să fie umplut în fiecare zi și fără lacune. Chiar dacă există lacune în PIT, puteți obține cele mai recente date folosind doar o interogare imbricată către PIT în sine. O interogare imbricată va procesa mai rapid decât interogările imbricate către fiecare satelit.
POD
Tabelele BRIDGE sunt, de asemenea, folosite pentru a simplifica interogările analitice. Totuși, ceea ce diferă de PIT este un mijloc de simplificare și accelerare a cererilor între diverse hub-uri, legături ș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 comerciale cu hash pot fi completate cu chei sub formă de text dacă numele cheilor sunt necesare pentru analiză.
Cert este că, fără a utiliza BRIDGE, în procesul de primire a datelor localizate în sateliți aparținând unor hub-uri diferite, va fi necesar să se facă un JOIN nu numai a sateliților înșiși, ci și a legăturilor care leagă hub-urile.
Prezența sau absența BRIDGE este determinată de configurația de stocare și de necesitatea de a optimiza viteza de execuție a interogărilor. Este dificil să vină cu un exemplu universal de BRIGE.
DERIVAȚII PREDEFINITATE
Un alt tip de obiect care ne apropie de VOITUL DE DATE AFACERI sunt tabelele care conțin indicatori precalculați. Astfel de tabele sunt cu adevărat importante pentru afaceri; ele conțin informații agregate conform regulilor date și le fac relativ ușor de accesat.
Din punct de vedere arhitectural, DERIVAȚIILE PREDEFINIȚII nu sunt altceva decât un alt satelit al unui anumit hub. El, ca un satelit obișnuit, conține o cheie de afaceri și data creării înregistrării în satelit. Totuși, aici se termină asemănările. Compoziția ulterioară a atributelor unui astfel de satelit „specializat” este determinată de utilizatorii de afaceri pe baza celor mai populari indicatori precalculați.
De exemplu, un hub care conține informații despre un angajat poate include un satelit cu indicatori precum:
- Salariu minim;
- Salariul maxim;
- Salariu mediu;
- Totalul cumulat al salariilor acumulate etc.
Este logic să includeți DERIVAȚII PREDEFINIȚE în tabelul PIT al aceluiași hub, apoi puteți obține cu ușurință secțiuni de date pentru un angajat la o dată special selectată.
CONCLUZII
După cum arată practica, utilizarea DATA VAULT de către utilizatorii de afaceri este oarecum dificilă din mai multe motive:
- Codul de interogare este complex și greoi;
- Abundența JOIN-urilor afectează performanța interogărilor;
- Scrierea unor interogări analitice necesită cunoștințe remarcabile despre proiectarea stocării.
Pentru a simplifica accesul la date, DATA VAULT este extins cu obiecte suplimentare:
- tabele PIT (punct în timp);
- mese BRIDGE;
- DERIVAȚII PREDEFINITATE.
Următorul Plănuiesc să spun, după părerea mea, cel mai interesant lucru pentru cei care lucrează cu BI. Voi prezenta modalități de a crea tabele de fapte și tabele de dimensiuni bazate pe DATA VAULT.
Materialele articolului se bazează pe:
- Pe Kenta Graziano, care, pe lângă o descriere detaliată, conține diagrame model;
- Cartea: „Construirea unui depozit de date scalabil cu DATA VAULT 2.0”;
- articol .
Sursa: www.habr.com