Home » Articole » Articole » Afaceri » Știința datelor (Data Science) » Depozite de date – Data Vault – Huburi, legături, sateliți și referințe

Depozite de date – Data Vault – Huburi, legături, sateliți și referințe

Huburi

Huburile conțin o listă de chei unice de afaceri cu o tendință scăzută de schimbare. Huburile conțin, de asemenea, o cheie surogat pentru fiecare item hub și metadate care descriu originea cheii de afaceri. Atributele descriptive pentru informațiile din hub (cum ar fi descrierea cheii, eventual în mai multe limbi) sunt stocate în structuri numite tabele satelit, care vor fi discutate mai jos.

Hubul conține cel puțin următoarele câmpuri:

  • o cheie surogat, folosită pentru a conecta celelalte structuri la acest tabel.
  • o cheie de afaceri, motorul pentru acest hub. Cheia de afaceri poate consta din mai multe câmpuri.
  • sursa de înregistrare, care poate fi folosită pentru a vedea ce sistem a încărcat mai întâi fiecare cheie de afaceri.

Opțional, puteți avea și câmpuri de metadate cu informații despre actualizările manuale (utilizator/ora) și data extracției.

Un hub nu are permisiunea de a conține mai multe chei de afaceri, cu excepția cazului în care două sisteme furnizează aceeași cheie de afaceri, dar cu coliziuni care au semnificații diferite.

Huburile ar trebui să aibă în mod normal cel puțin un satelit.

Exemplu de hub

Acesta este un exemplu pentru un tabel-hub care conține mașini, numit „Car” (H_CAR). Cheia motoare este numărul de identificare a vehiculului.

Nume câmp Descriere Obligatoriu? Comentariu
H_CAR_ID ID-ul secvenței și cheia surogat pentru hub Nu Recomandat dar opțional
VEHICLE_ID_NR Cheia de afaceri care conduce acest hub. Poate fi mai mult de un câmp pentru o cheie de afaceri compozită Da
H_RSRC Sursa de înregistrare a acestei chei la prima încărcare Da
LOAD_AUDIT_ID Un ID într-un tabel cu informații de audit, cum ar fi timpul de încărcare, durata încărcării, numărul de linii etc. Nu

Legături

Asociațiile sau tranzacțiile dintre cheile de afaceri (legând, de exemplu, huburile pentru client și produs între ele prin tranzacția de cumpărare) sunt modelate folosind tabele de legături. Aceste tabele sunt, practic, tabele de unire multi-la-mulți, cu unele metadate.

Legăturile pot face legătura cu alte legături, pentru a face față modificărilor de granularitate (de exemplu, adăugarea unei noi chei la un tabel al bazei de date ar schimba granulația tabelului bazei de date). De exemplu, dacă aveți o asociere între client și adresă, puteți adăuga o referință la o legătură între huburile pentru produs și compania de transport. Acesta ar putea fi un link numit „Delivery”. Trimiterea unui link într-un alt link este considerată o practică proastă, deoarece introduce dependențe între linkuri care fac încărcarea paralelă mai dificilă. Deoarece un link către un alt link este același cu un nou link cu huburile de la celălalt link, în aceste cazuri crearea linkurilor fără a face referire la alte linkuri este soluția preferată.

Legăturile leagă uneori huburi la informații care nu sunt suficiente pentru a construi un hub. Acest lucru se întâmplă atunci când una dintre cheile de afaceri asociate de link nu este o cheie de afaceri reală. De exemplu, luați un formular de comandă cu „număr de comandă” ca cheie și linii de comandă care sunt tastate cu un număr semi-aleatoriu pentru a le face unice. Să spunem „unique number”. Ultima cheie nu este o cheie de afaceri reală, deci nu este un hub. Cu toate acestea, trebuie să-l folosim pentru a garanta granularitatea corectă pentru link. În acest caz, nu folosim un hub cu cheie surogat, ci adăugăm cheia de afaceri „unique number” în sine la link. Acest lucru se face numai atunci când nu există nicio posibilitate de a utiliza vreodată cheia de afaceri pentru o altă legătură sau ca cheie pentru atribute dintr-un satelit. Acest construct a fost numit de Dan Linstedt „legătură peg-legged” pe forumul său (acum dispărut).

Legăturile conțin cheile surogat pentru huburile care sunt conectate, propria lor cheie surogat pentru link și metadate care descriu originea asocierii. Atributele descriptive pentru informațiile despre asociere (cum ar fi ora, prețul sau suma) sunt stocate în structuri numite tabele satelit, care sunt discutate mai jos.

Exemplu de legătură

Acesta este un exemplu pentru un tabel de legături între două huburi pentru mașini (H_CAR) și persoane (H_PERSON). Legătura se numește „Driver” (L_DRIVER).

Nume câmp Descriere Obligatoriu? Comentariu
L_DRIVER_ID ID-ul secvenței și cheia surogat pentru legătură Nu Recomandat dar opțional
H_CAR_ID Cheie surogat pentru hubul car, prima ancoră a legăturii Da
H_PERSON_ID Cheie surogat pentru hubul car, a doua ancoră a legăturii Da
L_RSRC Sursa de înregistrare a acestei asociații la prima încărcare Da
LOAD_AUDIT_ID Un ID într-un tabel cu informații de audit, cum ar fi timpul de încărcare, durata încărcării, numărul de linii etc. Nu

Sateliți

Huburile și legăturile formează structura modelului, dar nu au atribute temporale și nu dețin atribute descriptive. Acestea sunt stocate în tabele separate numite sateliți. Acestea constau în metadate care le conectează la hubul sau linkul lor părinte, metadate care descriu originea asocierii și atributelor, precum și o cronologie cu datele de început și de sfârșit pentru atribut. Acolo unde huburile și legăturile furnizează structura modelului, sateliții oferă „carnea” modelului, contextul proceselor de afaceri care sunt capturate în huburi și legături. Aceste atribute sunt stocate atât în ceea ce privește detaliile problemei, cât și cronologia, și pot varia de la destul de complexe (toate câmpurile care descriu un profil complet al unui client) până la destul de simple (un satelit pe o legătură cu doar un indicator valid și o cronologie).

De obicei, atributele sunt grupate în sateliți după sistemul sursă. Cu toate acestea, atributele descriptive, cum ar fi dimensiunea, costul, viteza, cantitatea sau culoarea se pot schimba la rate diferite, așa că puteți împărți aceste atribute în diferiți sateliți în funcție de rata lor de modificare.

Toate tabelele conțin metadate, care descriu cel puțin sistemul sursă și data la care această intrare a devenit valabilă, oferind o imagine istorică completă a datelor pe măsură ce intră în depozitul de date.

Exemplu de satelit

Acesta este un exemplu pentru un satelit pe legătura șoferilor dintre huburile pentru mașini și persoane, numit „Driver insurance” (S_DRIVER_INSURANCE). Acest satelit conține atribute care sunt specifice asigurării relației dintre mașină și persoana care o conduce, de exemplu un indicator dacă acesta este șoferul principal, numele companiei de asigurări pentru această mașină și persoana (ar putea fi, de asemenea, un hub) și un rezumat al numărului de accidente care implică această combinație de vehicul și șofer. De asemenea, este inclusă o referință la un tabel de căutare sau de referință numit R_RISK_CATEGORY care conține codurile pentru categoria de risc în care se consideră că se încadrează această relație.

Nume câmp Descriere Obligatoriu? Comentariu
S_DRIVER_INSURANCE_ID ID-ul secvenței și cheia surogat pentru satelitul de pe legătură Nu Recomandat dar opțional
L_DRIVER_ID Cheie primară (surogat) pentru legătura cu driverul, părintele satelitului Da
S_SEQ_NR Numărul de ordine sau secvență, pentru a impune unicitatea dacă există mai mulți sateliți valid pentru o cheie părinte Nu(**) Acest lucru se poate întâmpla dacă, de exemplu, aveți un hub COURSE și numele cursului este un atribut, dar în mai multe limbi diferite.
S_LDTS Load Date (data de începere) pentru valabilitatea acestei combinații de valori de atribut pentru cheia părinte L_DRIVER_ID Da
S_LEDTS Load End Date (data de încheiere) pentru valabilitatea acestei combinații de valori de atribut pentru cheia părinte L_DRIVER_ID Nu
IND_PRIMARY_DRIVER Indicator dacă șoferul este șoferul principal pentru această mașină Nu(*)
INSURANCE_COMPANY Numele companiei de asigurări pentru acest vehicul și acest șofer Nu(*)
NR_OF_ACCIDENTS Numărul de accidente ale acestui șofer în acest vehicul Nu(*)
R_RISK_CATEGORY_CD Categoria de risc pentru șofer. Aceasta este o referință la R_RISK_ CATEGORY Nu(*)
S_RSRC Sursa de înregistrare a informațiilor din acest satelit la prima încărcare Da
LOAD_AUDIT_ID Un ID într-un tabel cu informații de audit, cum ar fi timpul de încărcare, durata încărcării, numărul de linii etc. Nu

(*) cel puțin un atribut este obligatoriu. (**) numărul de secvență devine obligatoriu dacă este necesar pentru a impune unicitatea pentru mai mulți sateliți valizi pe același hub sau legătură.

Tabele de referință

Tabelele de referință sunt o parte normală a unui model sănătos de seif de date (data vault). Acestea sunt acolo pentru a preveni stocarea redundantă a datelor de referință simple, la care se referă foarte mult. Mai formal, Dan Linstedt definește datele de referință după cum urmează:

Orice informații considerate necesare pentru a rezolva descrierile din coduri sau pentru a traduce cheile  într-un (sic) mod consecvent. Multe dintre aceste câmpuri sunt de natură „descriptivă” și descriu o stare specifică a altor informații mai importante. Ca atare, datele de referință se află în tabele separate de tabelele brute Data Vault.

Tabelele de referință sunt referite din sateliți, dar nu sunt niciodată legate cu chei străine fizice. Nu există o structură prescrisă pentru tabelele de referință: utilizați ceea ce funcționează cel mai bine în cazul dvs. specific, variind de la simple tabele de căutare la seifuri mici de date sau chiar stele. Acestea pot fi istorice sau nu au istoric, dar este recomandat să rămâneți la cheile naturale și să nu creați chei surogat în acest caz. În mod normal, seifurile de date au o mulțime de tabele de referință, la fel ca orice alt depozit de date.

Exemplu de referință

Acesta este un exemplu de tabel de referință cu categorii de risc pentru șoferii de vehicule. Poate fi referit de la orice satelit din seiful de date. Deocamdată îl referim de la satelitul S_DRIVER_IN-SURANCE. Tabelul de referință este R_RISK_CATEGORY.

Nume câmp Descriere Obligatoriu?
R_RISK_CATEGORY_CD Codul pentru categoria de risc Da
RISK_CATEGORY_DESC O descriere a categoriei de risc Nu(*)

(*) cel puțin un atribut este obligatoriu.

Practici de încărcare

ETL pentru actualizarea unui model de seif de date este destul de simplu. Mai întâi trebuie să încărcați toate huburile, creând ID-uri surogat pentru orice chei de afaceri noi. După ce ați făcut asta, acum puteți rezolva toate cheile de afaceri pentru a identifica ID-uri surogat dacă interogați hubul. Al doilea pas este să rezolvați legăturile dintre huburi și să creați ID-uri surogat pentru orice asociații noi. În același timp, puteți crea toți sateliți atașați huburilor, deoarece puteți rezolva cheia unui ID surogat. După ce ați creat toate noile linkuri cu cheile lor surogat, puteți adăuga sateliți la toate linkurile.

Deoarece huburile nu sunt conectate între ele decât prin legături, puteți încărca toate huburile în paralel. Deoarece linkurile nu sunt atașate direct unele la altele, puteți încărca toate linkurile în paralel. Deoarece sateliții pot fi atașați numai la huburi și legături, le puteți încărca și în paralel.

ETL este destul de simplu și se pretează automatizării sau modelării ușoare. Problemele apar numai cu linkurile referitoare la alte linkuri, deoarece rezolvarea cheilor de afaceri din link duce doar la un alt link care trebuie rezolvat. Datorită echivalenței acestei situații cu o legătură la mai multe huburi, această dificultate poate fi evitată prin remodelarea unor astfel de cazuri și aceasta este de fapt practica recomandată.

Datele nu sunt niciodată șterse din seiful de date, cu excepția cazului în care aveți o eroare tehnică la încărcarea datelor.

Data Vault și modelarea dimensională

Stratul modelat Data Vault este utilizat în mod normal pentru stocarea datelor. Nu este optimizat pentru performanța interogărilor și nici nu este ușor de interogat prin instrumentele de interogare bine-cunoscute, cum ar fi Cognos, SAP Business Objects, Pentaho și al. Deoarece aceste instrumente de calcul pentru utilizatorii finali se așteaptă sau preferă ca datele lor să fie conținute într-un model dimensional, o conversie este de obicei necesară.

În acest scop, huburile și sateliții aferenți de pe acele huburi pot fi considerate dimensiuni, iar legăturile și sateliții aferenți de pe acele linkuri pot fi vizualizate ca tabele de fapte într-un model dimensional. Acest lucru vă permite să prototipați rapid un model dimensional dintr-un model seif de date folosind vizualizări. Din motive de performanță, modelul dimensional va fi de obicei implementat în tabele relaționale, după aprobare.

Rețineți că, deși este relativ simplu să mutați datele dintr-un model de seif de date într-un model dimensional (curățat), inversul nu este la fel de ușor.

Metodologia Data Vault (a seifului de date)

Metodologia seifului de date se bazează pe cele mai bune practici SEI/CMMI Nivelul 5. Include mai multe componente ale CMMI Level 5 și le combină cu cele mai bune practici de la Six Sigma, TQM și SDLC. În special, se concentrează pe metodologia agilă a lui Scott Ambler pentru construire și implementare. Proiectele seifului de date au un ciclu de lansare scurt, controlat de domeniul de aplicare, și ar trebui să conțină o lansare de producție la fiecare 2 până la 3 săptămâni.

Echipele care utilizează metodologia seifului de date vor adopta automat proiectele repetabile, consecvente și măsurabile care sunt așteptate la CMMI Nivelul 5. Datele care circulă prin sistemul seifului de date EDW vor începe să urmeze ciclul de viață TQM (managementul calității totale) care a lipsit mult timp din proiectele BI (business intelligence).

Sursa: Drew Bentley, Business Intelligence and Analytics. © 2017 Library Press, Licență CC BY-SA 4.0. Traducere și adaptare: Nicolae Sfetcu

Introducere în inteligența artificială
Introducere în inteligența artificială

Pășește în era digitală pregătit să înțelegi și să aplici conceptele care schimbă lumea!

Nu a fost votat 14.32 lei25.09 lei Selectează opțiunile Acest produs are mai multe variații. Opțiunile pot fi alese în pagina produsului.
Lucrul cu baze de date
Lucrul cu baze de date

Descoperă puterea bazelor de date cu acest ghid complet.

Nu a fost votat 19.11 lei38.26 lei Selectează opțiunile Acest produs are mai multe variații. Opțiunile pot fi alese în pagina produsului.
Tehnologia Blockchain - Bitcoin
Tehnologia Blockchain – Bitcoin

Transformă-ți perspectiva asupra tehnologiei blockchain și începe să descoperi oportunitățile digitale de mâine!

Nu a fost votat 23.89 lei57.41 lei Selectează opțiunile Acest produs are mai multe variații. Opțiunile pot fi alese în pagina produsului.

Lasă un răspuns

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *