Când începi un proiect de analiză, este foarte tentant să pornești de la ceea ce ai deja. Ai un Excel, un CSV, un export dintr-o aplicație sau poate chiar mai multe fișiere și te gândești că primul pas este să le aduci în Power BI. Așa am făcut și eu.
În AlpinHub, una dintre sursele importante a fost exportul de la StatsHunters. Aveam activitățile, distanțele, timpul, elevația și multe alte informații. Din punctul de vedere al utilizatorului, datele erau acolo și puteau fi citite. Puteam deschide fișierul, puteam vedea rândurile și coloanele și, la prima vedere, părea că tot ce mai aveam de făcut era să le pun într-un raport.
[IMAGINE – AlpinHub / StatsHunters: fragment anonimizat din fișierul exportat, cu structura sursei vizibilă, înainte de transformare. Imaginea să sugereze clar „date primite de la o sursă”, nu un model Power BI.]
Numai că sursa avea propria ei logică. Un export este construit pentru scopul aplicației sau serviciului care îl produce. Conține informațiile pe care acel serviciu alege să le ofere, în forma în care a decis să le ofere. Nu este obligat să țină cont de felul în care vreau eu să analizez datele peste câteva luni.
Asta a fost una dintre primele diferențe importante pe care le-am înțeles lucrând cu Power BI: sursa și modelul sunt două lucruri diferite.
Sursa îmi oferă materia primă. Modelul este structura pe care o construiesc pentru a putea lucra cu acea materie primă.
[IMAGINE – AlpinHub: comparație vizuală simplă între „Sursă” și „Model”. În stânga un export cu rânduri și coloane, în dreapta o structură organizată cu entități și relații. Fără interfață Power BI propriu-zisă.]
În cazul AlpinHub, acest lucru a devenit evident pe măsură ce am început să lucrez cu datele. Nu voiam doar să văd ce activități am făcut. Voiam să le pot grupa, compara, filtra și corela. Voiam să pot privi activitățile în timp, după tip, după dispozitiv, după distanță sau elevație și, mai târziu, în relație cu locația și alte informații.
Pentru asta, trebuia să am o structură proprie.
Aici a intrat în scenă Power Query. Nu ca un simplu loc în care „aranjez frumos Excelul”, ci ca etapa în care încep să transform ceea ce primesc de la sursă în ceva care poate intra în modelul meu. Am început să curăț datele, să stabilesc tipurile de date, să normalizez anumite informații, să creez câmpuri de care aveam nevoie și să elimin lucrurile care nu aveau sens în structura finală. Unele transformări erau foarte simple. Altele au apărut abia după ce am încercat să folosesc efectiv datele în model și am descoperit că ceva nu se potrivește.
[IMAGINE – AlpinHub / Power Query: fragment real sau reconstruit din etapa de transformare a datelor StatsHunters, cu câteva operații de curățare și standardizare evidențiate. Accent pe proces, nu pe interfața software în sine.]
Aici am început să înțeleg și de ce este atât de important să nu construiești direct raportul peste sursa brută. Dacă legi totul direct de forma în care ai primit datele, ajungi foarte ușor să construiești raportul în jurul sursei. Iar când sursa se schimbă, se schimbă și raportul, și logica lui, și uneori chiar modelul.
Eu voiam exact invers. Voiam ca sursa să poată fi schimbată sau completată fără să trebuiască să schimb de fiecare dată ceea ce am construit mai departe. De aici a început să capete sens ideea de standardizare.
[IMAGINE – AlpinHub: mai multe surse diferite reprezentate prin fișiere sau fluxuri distincte care ajung într-o structură standard comună. Exemplul poate sugera StatsHunters ca sursă actuală și alte surse posibile în viitor, fără a le prezenta ca fiind deja implementate.]
Pentru AlpinHub, structura standard a activității, SSA, a apărut tocmai din această nevoie. Nu mai voiam să mă gândesc la activitatea mea ca la „un rând venit din StatsHunters”. Voiam să fie o activitate în sensul modelului meu, indiferent de unde provenea informația.
Asta schimbă destul de mult perspectiva. Dacă mâine datele ar veni din altă aplicație, nu ar trebui să schimb ceea ce înseamnă o activitate în AlpinHub. Ar trebui, în primul rând, să găsesc o cale de a aduce noua sursă în aceeași logică standard.
[IMAGINE – AlpinHub / SSA: schemă simplificată în care două sau mai multe surse ajung la aceeași „Structură Standard a Activității”, apoi către FactActivities. Accent pe separarea dintre surse și model.]
În felul acesta, FactActivities nu mai este doar un tabel în care am pus datele după ce le-am importat. Devine locul în care activitatea are forma pe care am decis că trebuie să o aibă în AlpinHub.
Acolo începe să conteze și modelarea dimensională: data poate fi privită prin DimDate, activitatea prin DimActivity, dispozitivul prin DimDevice, echipamentul prin DimGear și, în timp, pot apărea și alte dimensiuni sau extensii tematice.
Nu am construit toate aceste lucruri pentru că „așa trebuie făcut un Power BI”. Le-am construit pentru că, pe măsură ce lucram cu datele, am început să am întrebări la care structura inițială nu mai era suficientă.
[IMAGINE – AlpinHub: reprezentare tehnică simplificată a modelului cu FactActivities în centru și câteva dimensiuni în jur. Poate fi inspirată din modelul real, dar suficient de simplificată pentru a fi ușor de urmărit.]
Și aici cred că este una dintre diferențele importante dintre un raport care funcționează și un model care poate crește.
Un raport poate fi construit foarte repede peste un tabel. Pui câteva grafice, adaugi niște filtre și începi să vezi lucruri interesante. Problema apare mai târziu, când vrei să mai adaugi o sursă, o altă categorie de informații sau o analiză pe care nu ai prevăzut-o de la început. Atunci descoperi dacă ai construit doar o prezentare a datelor sau ai construit o structură care poate susține întrebări noi.
În AlpinHub, am descoperit asta prin încercări, nu printr-un plan perfect făcut de la început. Am schimbat structuri, am mutat câmpuri, am refăcut transformări și am verificat relații. Uneori am construit ceva care părea corect și am descoperit abia în analiză că nu era. Alteori am adăugat o informație pentru că mi s-a părut utilă și abia mai târziu am înțeles unde trebuia să stea de fapt.
[IMAGINE – AlpinHub: o schiță de lucru cu o structură inițială simplă și o structură ulterioară mai bine organizată, sugerând evoluția modelului. Nu este nevoie să fie prezentat ca „versiunea veche versus versiunea corectă”, ci ca o construcție care se maturizează.]
Asta mi-a schimbat și felul în care privesc alte proiecte. Când am lucrat cu datele Potaissa, cu observațiile din iNaturalist, cu informațiile geografice din Valea Arieșului sau cu catalogul web AlpinHub, nu am mai pornit de la întrebarea „cum arată tabelul?”. Am început să mă întreb ce reprezintă informația, care este sursa ei, ce trebuie păstrat din forma originală și ce trebuie transformat pentru model.
În fiecare caz, sursa avea propria ei structură. Modelul trebuia să aibă însă logica proiectului.
[IMAGINE – comparație tehnică între trei surse din proiecte diferite: iNaturalist, Potaissa și AlpinHub Catalog, fiecare cu o structură proprie, dar toate trecând prin aceeași idee de „sursă → transformare → model”.]
Asta nu înseamnă că sursa trebuie ignorată sau modificată până când nu mai seamănă cu originalul. Dimpotrivă. Am ajuns să consider din ce în ce mai important să păstrez cât mai clar ceea ce vine din sursă și să separ această informație de ceea ce construiesc eu ulterior.
Sursa trebuie să rămână sursă. Transformarea trebuie să fie controlabilă. Iar modelul trebuie să aibă propria lui logică.
Această separare m-a ajutat inclusiv atunci când ceva nu a funcționat. Dacă un rezultat era greșit, puteam să mă întorc și să întreb: problema este în datele primite? În transformare? În clasificare? În relațiile dintre tabele? Sau în modul în care am construit analiza?
Fără această separare, toate aceste lucruri se amestecă foarte repede.
[IMAGINE – Data Quality / AlpinHub: o schemă tehnică simplă de diagnostic, cu trei niveluri „Sursă → Transformare → Model” și exemple de probleme care pot apărea la fiecare nivel.]
Poate că aceasta este una dintre cele mai utile idei pe care le-am scos din sertarul Power BI: nu trebuie să construiești modelul în funcție de cum arată sursa, ci să construiești drumul dintre sursă și model în funcție de ceea ce vrei să înțelegi.
În momentul în care am început să gândesc așa, Power BI a devenit mai puțin despre importul unui fișier și mai mult despre construirea unei structuri.
Iar structura aceea nu trebuie să fie neapărat perfectă de la început. Important este să fie suficient de clară încât să poată fi verificată, corectată și extinsă.
Pentru mine, AlpinHub a devenit tocmai un astfel de laborator. Am pornit de la o sursă concretă, am încercat să o folosesc, m-am lovit de limitele ei, am construit transformări, apoi o structură standard și, treptat, un model care nu mai depindea atât de mult de forma în care primisem datele.
Sursa mi-a dat datele. Modelul mi-a dat un loc în care să le pot înțelege. Și abia de aici începe să devină interesant ce pot face cu ele.
