olivlawolivlaw

Din cărți

Lecția 5 · Data Vault separă ce e stabil (cheile), ce leagă (relațiile) și ce se schimbă (atributele).

Dan Linstedt · Data Vault Series 1 — Data Vault Overview · 2002 · Dan Linstedt, Data Vault Series 1 — Data Vault Overview (2002), definiția modelului2 minute de citit
„Modelul Data Vault este un set de tabele normalizate, orientat pe detaliu, cu urmărire istorică și legături unice, care susține una sau mai multe arii funcționale ale afacerii.”Dan Linstedt · Data Vault Series 1 — Data Vault Overview · 2002 · Dan Linstedt, Data Vault Series 1 — Data Vault Overview (2002), definiția modelului

Hub, link, satellite: chei, relații, atribute cu istoric — trei tipuri de tabele, un depozit auditabil.

Schema stea e rapidă de citit și ușor de înțeles, dar rigidă: o sursă nouă sau o coloană nouă înseamnă rescrierea dimensiunii. Fulgul de zăpadă normalizează dimensiunile — mai puține duplicate, mai multe join-uri — și de obicei nu merită. Data Vault răspunde la altă problemă: cum integrezi douăzeci de surse care se schimbă des, fără să rescrii nimic și cu audit complet. Trei tipuri de tabele: hub (cheile de business — un client, un produs), link (relațiile dintre chei — clientul a cumpărat produsul) și satellite (atributele descriptive, cu data încărcării și sursa, deci cu istoric complet). Costul e că un vault nu se citește direct: are prea multe tabele. Arhitectura tipică e staging, apoi vault (brut și de business), apoi marts în stea deasupra, pentru rapoarte. Alegerea nu e ideologică. Surse puține și stabile: stea direct. Surse multe, schimbătoare, cerințe de audit: vault dedesubt, stea deasupra.

Pasajul de față privește ce se întâmplă când sursele nu doar se schimbă, ci se contrazic. Două sisteme pot da același client cu nume scrise diferit. În Data Vault, hub-ul păstrează o singură cheie pentru client, iar sateliții păstrează ambele versiuni, fiecare cu sursa ei. Nimeni nu șterge nimic ca să rezolve conflictul. Adevărul devine o alegere făcută târziu, la raport, nu devreme, la încărcare. Gândește-te la două facturi de la aceeași adresă, cu nume scrise altfel: le păstrezi pe ambele și decizi mai târziu care e cea corectă. Asta mută decizia acolo unde are context. Dar cum se leagă practic cheile între surse, când niciuna nu e sursa adevărului? Asta deschide pasul următor.

Pasajul de față răspunde la întrebarea de dinainte: cine leagă cheile când niciun sistem nu e sursa adevărului. Răspunsul e că nimeni nu e proprietar. Hub-ul e o ancoră neutră: el recunoaște un client indiferent de sistemul care l-a trimis. Link-ul înregistrează relația de fiecare dată când o sursă o afirmă, cu sursa ei. Deci legătura nu e o opinie a unui sistem, ci o colecție de afirmații. E ca o agendă de contacte în care scrii că Ana cunoaște pe Ion pentru că trei prieteni ți-au spus asta, fiecare cu numele lui lângă. Nicio sursă nu dictează, dar toate lasă urmă. Asta face cheile stabile chiar dacă sistemele se schimbă. Dar dacă cheile sunt stabile, atributele din jur nu sunt. Cum se schimbă ele fără să piardă istoria? Asta e pasul următor.

De ce contează Un depozit care se rescrie la fiecare sursă nouă nu ajunge niciodată la a zecea sursă. Alegerea modelului decide cât de ieftină e schimbarea.

Surse normalizate(3NF)Data Vault:integrare,Marts în stea:citire
Fiecare treaptă e optimizată pentru altceva: scriere, integrare, citire.
Deschide pe YouTube ↗

← Vezi tot fluxul