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
Lasă un răspuns