Când am început să lucrez cu Power BI, mă gândeam mai ales la ce aș putea face cu datele pe care le aveam. Cum să le aduc într-un singur loc, cum să le compar, cum să văd lucruri care nu erau atât de evidente în tabelele obișnuite.
Destul de repede am descoperit însă că există un pas înainte de toate acestea: să înțeleg ce sunt, de fapt, datele cu care lucrez.
Pare simplu. Ai un tabel, ai niște coloane, ai niște rânduri și, la prima vedere, lucrurile sunt clare. Numai că un tabel care este ușor de citit pentru un om nu este neapărat și un tabel bun pentru analiză.
[IMAGINE – AlpinHub / StatsHunters: fragment anonimizat dintr-un export de activități, înainte de transformare. Accent pe diferența dintre o sursă care „arată bine” la prima vedere și informația care trebuie pregătită pentru modelare.]
Aici am început să observ una dintre diferențele importante dintre lucrul cu datele și simpla lor afișare. Pentru mine, un rând putea să însemne o activitate, o factură, o observație din natură, un articol, o cheltuială sau o locație. Forma tabelului putea fi asemănătoare, dar sensul era complet diferit.
Și tocmai sensul acesta a început să conteze tot mai mult.
În AlpinHub, de exemplu, un rând din datele de activități trebuia să reprezinte o activitate. Nu doar o înregistrare importată dintr-un fișier, ci o entitate pe care să o pot corela cu o dată, un tip de activitate, un dispozitiv, o distanță, o diferență de nivel sau, mai târziu, cu o locație.
[IMAGINE – AlpinHub: schiță simplificată a unei activități și a informațiilor care îi dau context: dată, tip, distanță, elevație, dispozitiv, locație.]
Asta m-a făcut să privesc altfel și sursele. Fișierul primit de la un serviciu extern nu era modelul meu de date. Era doar sursa din care trebuia să construiesc ceva potrivit pentru ceea ce voiam să analizez.
Experiența cu exporturile StatsHunters a fost foarte bună pentru a înțelege acest lucru. Datele veneau într-o formă care era suficientă pentru sursa respectivă, dar nu neapărat în forma în care aveam nevoie de ele în AlpinHub. A trebuit să curăț, să transform, să standardizez și să stabilesc ce înseamnă fiecare informație înainte să ajung la analiza propriu-zisă.
[IMAGINE – AlpinHub / StatsHunters: exemplu de flux simplificat „sursă → transformare → model → analiză”, cu accent pe faptul că sursa și modelul nu sunt același lucru.]
Din această experiență a apărut treptat și ideea de SSA, Structura Standard a Activității. Nu a fost o idee apărută dintr-o dată și nici o schemă desenată înainte să încep proiectul. A apărut pentru că, lucrând cu datele, am început să mă lovesc de aceleași întrebări: ce reprezintă o activitate, ce informații sunt esențiale, ce informații țin de context și cum pot păstra o structură care să nu depindă de o singură sursă.
[IMAGINE – AlpinHub / SSA: reprezentare simplificată a structurii standard a unei activități, cu câteva câmpuri esențiale și separarea dintre informația de bază și informația de context.]
Apoi am întâlnit o altă situație, într-un proiect complet diferit.
În datele administrative ale Potaissa, lucrurile nu mai semănau deloc cu activitățile outdoor. Aveam facturi și cheltuieli, furnizori, sume și proiecte. Dar am descoperit aceeași problemă: datele existente nu spuneau întotdeauna singure toată povestea.
O factură putea fi identificată foarte clar, însă categoria, subcategoria sau proiectul căruia îi aparținea nu rezultau întotdeauna în mod sigur din informația brută. Acolo am învățat că automatizarea nu este întotdeauna soluția cea mai bună. Unele lucruri sunt repetitive și pot fi automatizate fără probleme. Altele au nevoie de context și de o decizie umană.
[IMAGINE – Potaissa: fragment anonimizat de tabel cu facturi/cheltuieli, în care informația brută este separată vizual de Categoria, Subcategoria și Proiectul atribuite ulterior.]
Este o diferență care mi se pare importantă. Un model bun nu înseamnă neapărat că trebuie să automatizezi tot ce se poate automatiza. Uneori un câmp completat manual, după o regulă clară, este mai valoros decât o clasificare automată care pare elegantă, dar poate greși tocmai acolo unde contextul contează.
Pe măsură ce am lucrat și cu alte tipuri de date, am început să observ că aceleași principii se repetă.
În iNaturalist, de exemplu, o observație nu înseamnă doar o specie și o fotografie. Încep să conteze data, locația și taxonomia. O observație capătă alt sens atunci când o poți privi în timp și în spațiu sau când o poți raporta la structura biologică din care face parte.
[IMAGINE – iNaturalist: o observație reală sau reconstruită vizual, în care sunt evidențiate separat fotografia/specia, data, locația și elementele de taxonomie.]
În proiectele legate de Valea Arieșului, locația și contextul geografic au început să aibă un rol mult mai important. Nu mai era suficient să știu că există o informație. Trebuia să știu unde se află, cărei zone îi aparține și în ce context poate fi folosită.
[IMAGINE – Valea Arieșului: hartă simplificată sau fragment de structură geografică în care o informație este legată de localitate, zonă sau microregiune.]
Iar în AlpinHub Catalog am ajuns la o altă categorie de date: pagini, URL-uri, structuri de site și categorii. Din nou, alt domeniu, altă sursă, altă formă de tabel. Dar aceeași întrebare în spate: ce reprezintă fiecare înregistrare și cum se leagă informațiile între ele?
[IMAGINE – AlpinHub Catalog: fragment anonimizat din catalogul URL-urilor WordPress, cu pagini, URL-uri și categorii, sugerând relația dintre conținut și structura site-ului.]
Aici am început să înțeleg mai bine că modelarea datelor nu este doar despre Power BI. Power BI este locul în care modelul ajunge să fie folosit, dar modelul începe mult mai devreme, atunci când încerc să stabilesc ce reprezintă datele, care sunt entitățile importante, ce relații există între ele și ce informații trebuie păstrate.
Și mai există ceva ce am învățat pe parcurs: un raport poate să arate foarte bine și totuși datele din spatele lui să fie greșite.
Am întâlnit situații cu dispozitive necunoscute, locații neatribuite, duplicate sau clasificări care trebuiau verificate. Uneori problema nu era vizibilă în graficele finale. Trebuia să cobor din nou în date și să verific ce se întâmplă acolo.
[IMAGINE – AlpinHub / Data Quality: exemplu simplificat și anonimizat cu „Unknown Device”, „Unassigned Location” sau duplicate, pentru a sugera diferența dintre un raport care arată bine și date care sunt efectiv curate.]
De aici a apărut și ideea că partea de Data Quality nu este o etapă neplăcută pe care o faci doar când ceva nu funcționează. Este o parte normală a proiectului.
Cu timpul, toate aceste experiențe au început să se lege între ele. Activitățile din AlpinHub, cheltuielile din Potaissa, observațiile din iNaturalist, informațiile geografice din Valea Arieșului sau structura unui catalog web sunt foarte diferite ca domeniu, dar m-au făcut să mă uit la date într-un mod asemănător.
Am început să caut entități, relații, clasificări, timp, spațiu și reguli. Am început să mă întreb ce trebuie să rămână în sursă, ce trebuie transformat și ce trebuie construit în model. Și, poate cel mai important, am început să mă gândesc la reutilizare: dacă mâine apare o altă sursă, cât de mult din modelul construit astăzi poate rămâne neschimbat?
[IMAGINE – AlpinHub: diagramă conceptuală simplă care arată mai multe surse diferite alimentând aceeași structură de date, fără a sugera că toate sursele trebuie să aibă aceeași formă.]
Cred că aici s-a produs schimbarea cea mai importantă în felul în care privesc Power BI.
La început îl vedeam mai ales ca pe un instrument în care pot aduce date și construi rapoarte. Acum îl văd mai degrabă ca pe una dintre etapele unui proces mai lung. Înainte de grafice există sursa. Între sursă și raport există transformarea și modelul. Iar între model și ceea ce văd pe ecran există toate acele decizii, unele tehnice, altele de logică și uneori chiar de bun-simț.
Datele nu vin cu povestea gata scrisă. Trebuie mai întâi să înțelegi ce spun fiecare dintre ele, cum se leagă între ele și ce poți avea încredere să întrebi.
Abia atunci începe să apară povestea pe care o poți spune cu ele.
