olivlawolivlaw

Din cărți

Lecția 1 · Un depozit de date nu e o bază de date mai mare, ci una construită pentru altă întrebare.

W. H. Inmon · Building the Data Warehouse · 1992 · Building the Data Warehouse (1992), cap. 2 — definiția depozitului de date1 minut de citit
„Un depozit de date este o colecție de date orientată pe subiect, integrată, variabilă în timp și nevolatilă, în sprijinul procesului decizional al conducerii.”W. H. Inmon · Building the Data Warehouse · 1992 · Building the Data Warehouse (1992), cap. 2 — definiția depozitului de date

Orientat pe subiect, integrat, variabil în timp, nevolatil: patru adjective, o arhitectură.

Cele patru adjective ale lui Inmon sunt, de fapt, patru decizii de proiectare. Orientat pe subiect: datele sunt organizate pe client, produs, comandă — nu pe aplicațiile care le-au produs. Integrat: aceleași coduri de țară, aceleași unități, aceleași chei, oricâte surse ar fi în spate; integrarea e cea mai scumpă parte a muncii și motivul pentru care depozitul există. Variabil în timp: fiecare rând e o fotografie datată, iar istoricul se păstrează, nu se suprascrie. Nevolatil: se încarcă și se citește; nu se corectează pe loc, ca într-un sistem de tranzacții. Sistemul de producție răspunde la „care e adresa clientului acum?”. Depozitul răspunde la „cum s-a mutat valoarea comenzilor pe județe în ultimii cinci ani?”. Prima întrebare cere un rând, repede și consistent. A doua cere milioane de rânduri, comparabile între ele. Sunt două sarcini diferite, și lecțiile care urmează arată de ce nu le rezolvă bine același motor.

Integrarea nu e o treabă făcută o dată. E o practică continuă. Fiecare sistem sursă vine cu obiceiurile lui: un magazin scrie „RO”, altul „România”, altul cod numeric. Depozitul alege o singură formă și o păstrează, pentru fiecare încărcare nouă. De aceea munca reală nu e copierea, ci traducerea — hotărârea ce înseamnă „același client” sau „aceeași vânzare” peste surse diferite. Gândește-te la două sucursale care țin evidența acelorași clienți cu nume scrise altfel. Fără o regulă comună, numărul clienților se dublează pe hârtie. Când traducerea devine disciplină zilnică, apare o întrebare nouă: ce facem cu rândurile vechi când regula se schimbă?

Pasajul anterior s-a oprit la întrebarea firească: ce facem cu rândurile vechi când regula de integrare se schimbă? Răspunsul lui Inmon e o decizie de proiectare, nu un accident: depozitul nu le șterge. El e nevolatil — datele se încarcă și se citesc, dar nu se corectează pe loc, ca într-un sistem de tranzacții. Dacă magazinul îți schimbă adresa, sistemul de producție suprascrie rândul vechi și gata. Depozitul păstrează ambele versiuni, fiecare datată. Apare astfel istoricul comparabil: poți vedea nu doar unde locuiește clientul acum, ci unde locuia când s-a făcut fiecare comandă. Gândește-te la un abonat care se mută din Cluj în București la mijlocul anului. Raportul pe județe are sens doar dacă comenzile din prima jumătate rămân legate de Cluj. Dar dacă nimic nu se șterge, depozitul crește neîncetat — și atunci apare o altă întrebare: cum găsești repede ce căutare într-o grămadă atât de mare?

De ce contează Fără un depozit, fiecare raport își face propria integrare — și fiecare o face puțin altfel. Deciziile cer istoric comparabil, iar istoricul comparabil e exact ce sistemele de producție nu păstrează.

Surse(aplicații)IntegrareDepozit cuistoricDecizii
Drumul datelor: de la aplicații la o singură versiune comparabilă a trecutului.
Deschide pe YouTube ↗

← Vezi tot fluxul