La început a fost un Excel. Nu era nevoie de ceva complicat. Informațiile despre Valea Arieșului puteau fi adunate și administrate într-o structură relativ simplă, iar principiul de bază a fost stabilit de la început: Excelul rămâne sursa de adevăr, iar Power BI este locul în care datele pot fi modelate, legate, verificate și analizate.
Doar că, atunci când începi să construiești modelul, apare o diferență importantă între a avea informații și a le putea reprezenta corect. În Excel poți pune într-un tabel aproape orice informație. Într-un model de date, însă, începi să te întrebi ce reprezintă fiecare lucru, cu ce se leagă, unde ar trebui să existe și ce se întâmplă atunci când aceeași informație apare în mai multe locuri.
Așa a început să crească proiectul de Destination Management pentru Valea Arieșului.
De la câteva tabele la primele relații
Primele structuri au fost destul de intuitive: locații, atracții, trasee, puncte de interes, infrastructură. Pe măsură ce am încercat să le folosesc împreună în Power BI, au apărut însă probleme care nu erau evidente în sursa inițială.
A trebuit să apară chei, nomenclatoare, clasificări și reguli mai clare despre ce informații sunt obligatorii și care pot lipsi. Unele lucruri care păreau simple în Excel nu mai erau la fel de simple atunci când trebuiau legate de alte tabele. A fost una dintre primele lecții ale proiectului: o structură care arată bine într-un tabel nu este neapărat și o structură bună pentru un model de date.
Când geografia a devenit infrastructură
La început, locația putea fi privită pur și simplu ca o informație asociată unei înregistrări. Pe măsură ce proiectul a crescut, a devenit evident că geografia trebuie să aibă propriul loc în model.
Locatii_Geografie a început să adune lucruri precum KeyLoc, localitatea, județul, microregiunea, coordonatele, unitatea de relief, aria protejată și alte informații geografice. În paralel, Dim_Microregiune a devenit o dimensiune distinctă, care putea fi folosită pentru filtrarea și analiza teritoriului. Schimbarea este mai importantă decât pare. Locația nu mai este doar un atribut al unei atracții sau al unui traseu, ci o parte din infrastructura prin care informațiile despre destinație pot fi puse în relație. În momentul în care pot să plec de la o microregiune și să ajung la locațiile, atracțiile sau traseele asociate ei, geografia începe să lucreze în model, nu doar să fie afișată într-un tabel.
Traseele, atracțiile și POI-urile
Traseele au venit cu propriile particularități. Au propriile chei, caracteristici și coordonate de start și final, în timp ce atracțiile se leagă de geografia destinației prin KeyLoc. Pentru punctele de interes a fost nevoie de o structură separată, iar asocierea dintre trasee și POI-uri a fost făcută prin Trasee_POI. Nu toate informațiile trebuiau copiate dintr-un tabel în altul doar pentru că aveam nevoie de ele într-o analiză. Aici s-a conturat un principiu care a devenit important și în alte proiecte: dacă o relație poate furniza informația de care am nevoie, nu are rost să o duplic. Cu cât modelul începea să crească, cu atât devenea mai important să știu nu doar unde se află o informație, ci și de ce se află acolo.
Când activitatea nu a mai fost doar activitate
Una dintre schimbările interesante a apărut în jurul tabelului Activitati.
La început, termenul putea sugera foarte ușor un calendar. Dar lucrul efectiv cu modelul a arătat că sunt două lucruri diferite. Activitati descrie ceea ce poate face turistul în destinație. Este un catalog de activități și experiențe. Calendar_ActivitatiTuristice descrie ceea ce este programat efectiv: data, furnizorul, prețul, numărul de locuri și celelalte informații operaționale. Diferența aceasta nu a apărut pentru că modelul trebuia să aibă încă un tabel. A apărut pentru că trebuia să clarificăm ce înseamnă, de fapt, o activitate în contextul destinației. Catalogul descrie potențialul. Calendarul descrie activarea lui. Și, dintr-o dată, modelul începea să spună ceva mai clar despre realitatea pe care încercam să o reprezint.
Când a trebuit să definim mai bine activitățile
Odată cu catalogul au apărut și alte întrebări. Nu era suficient să avem un nume de activitate. Era nevoie să putem diferenția experiența concretă de tipul și categoria în care aceasta se încadrează. Astfel, NumeActivitate descrie experiența concretă, TipActivitate descrie forma specifică, iar CategorieActivitate reprezintă familia mai largă. A apărut și o regulă simplă, dar importantă: un TipActivitate aparține unei singure CategorieActivitate. Conceptul Junior Ranger a fost un exemplu bun pentru această delimitare. Este un tip de activitate în zona activităților pentru copii, dar activitățile pentru copii nu se reduc la Junior Ranger. Modelul a trebuit să permită această diferență fără să forțeze realitatea într-o categorie prea îngustă.
Modelul nu a fost doar construit. A fost testat.
La un moment dat, modelul putea să pară corect. Tabelele erau acolo, relațiile erau definite, iar raportul începea să arate rezultatele așteptate.
Dar asta nu era suficient. Am început să verific relațiile direct în Power BI, să urmăresc filtrele, valorile, cardurile și vizualizările și să văd dacă rezultatele obținute din datele reale corespund cu ceea ce ar trebui să reprezinte modelul. Unele lucruri au funcționat din prima. Altele au arătat că structura trebuia schimbată. Au existat și situații în care o soluție aparent logică s-a dovedit nepotrivită atunci când a fost testată efectiv. Un exemplu bun este relația încercată între Dim_Calendar[AnLuna] și Date_Statistice[Perioada]. La prima vedere părea o asociere firească, dar AnLuna nu este o valoare unică la nivelul zilelor din calendar. Relația a trebuit eliminată. Nu era o problemă de sintaxă și nici o eroare pe care Power BI să o poată rezolva în locul nostru. Era o problemă de structură, pe care testarea a făcut-o vizibilă. Aici am început să privesc testarea altfel: nu ca pe ultima etapă a proiectului, ci ca pe o parte a proiectării lui.
DQ începe să facă parte din model
Pe măsură ce modelul a devenit mai serios, a devenit evident că nu putem trata calitatea datelor doar ca pe o problemă a fișierului Excel.
Au apărut chei lipsă sau duplicate, nume lipsă, coordonate lipsă, capacități care nu erau completate, relații care trebuiau validate, website-uri invalide și intervale de date care nu respectau regulile stabilite. În loc să încerc să ascund toate aceste situații înainte ca datele să ajungă în raport, am început să le tratez ca pe informații care trebuie să poată fi văzute și controlate. Așa a devenit DQ o parte a modelului. Cardurile, indicatorii, tabelele și vizualizările de control nu sunt acolo doar ca să arate că există probleme. Ele ajută la identificarea lor și, mai ales, la urmărirea lor pe măsură ce datele sunt corectate.
Pentru mine, acesta a fost un pas important. Un model de date nu trebuie să arate doar ceea ce este bine. Uneori trebuie să arate și ceea ce încă nu este bine.
Și Excelul a trebuit să se maturizeze
Pe măsură ce modelul a devenit mai clar, am început să văd și lucruri care țineau de sursa Excel.
Unele foi erau Excel Tables, altele erau simple foi citite direct de Power Query. Pentru un proiect care trebuie să poată fi administrat și extins în timp, diferența aceasta nu mai era justificată. Structurile operaționale au fost uniformizate și transformate în tabele Excel explicite, iar Power Query a fost făcut să lucreze consecvent cu acestea. Este un lucru aparent minor, dar spune ceva important despre relația dintre sursă și model: faptul că Excelul este Single Source of Truth nu înseamnă că sursa trebuie să rămână neschimbată indiferent de ce descoperim în model. Pe măsură ce înțelegem mai bine ce vrem să facem cu datele, putem îmbunătăți și felul în care sursa este organizată, fără să schimbăm principiul de bază.
De fapt, ce s-a construit?
La început era o colecție de informații despre Valea Arieșului.
Acum există un model în care începe să fie posibilă o reprezentare coerentă a teritoriului, locațiilor, atracțiilor, traseelor, punctelor de interes, infrastructurii, activităților, experiențelor, calendarului, datelor statistice și calității datelor. Nu înseamnă că modelul este terminat sau că este modelul perfect pentru orice situație. Înseamnă doar că a ajuns suficient de coerent încât să poată crește odată cu proiectul.
Și aici cred că este una dintre diferențele importante dintre început și etapa actuală. La început aveam date despre destinație. Acum avem un model care începe să reprezinte destinația. Complexitatea nu a venit din datele inițiale. A venit din nevoia de a le reprezenta corect.
Ce am învățat din proiect
Poate cea mai importantă lecție nu este despre Power BI. Este despre felul în care un model de date te obligă să clarifici lucruri pe care, în afara modelului, le poți lăsa neclare.
Ce este o activitate? Ce este o experiență? Ce este o locație? Ce aparține unei microregiuni? Ce trebuie să fie în catalog și ce trebuie să fie în calendar? Ce informație poate fi obținută printr-o relație și ce informație trebuie păstrată explicit? Uneori răspunsurile existau deja. Alteori au devenit clare abia după ce am încercat să le pun în model.
Asta este partea care mi se pare cea mai interesantă în proiectul acesta. Power BI nu a fost doar instrumentul în care am construit raportarea. A fost și mediul în care am putut testa dacă felul în care înțelegeam datele despre Valea Arieșului putea fi transformat într-o structură coerentă.Modelul nu a rezultat dintr-un plan perfect. A crescut prin întrebări, teste, corecții și câteva soluții care au trebuit reconsiderate.
Iar proiectul continuă. Vor apărea date noi, vor apărea alte întrebări și probabil vor mai exista lucruri care vor trebui schimbate. Diferența este că acum există o structură de la care pot porni și o experiență care îmi permite să văd mai repede unde apare problema și ce trebuie clarificat. Poate că acesta este, până la urmă, cel mai interesant lucru pe care îl lasă un astfel de proiect în urmă: nu doar un raport Power BI, ci un mod mai clar de a privi informațiile despre o destinație și de a le transforma, pas cu pas, într-un model care poate crește odată cu ea.