Ho ripreso Power BI dopo oltre un anno in cui non lo avevo praticamente toccato. La domanda che mi sono posto subito è stata: come riprendo? Con un tutorial YouTube? Con la documentazione Microsoft? Alla fine ho scelto una strada diversa : usare Claude come guida tecnica interattiva, passo passo, su un dataset reale e complesso. Non per farmi scrivere il codice, ma per avere qualcuno con cui ragionare su ogni decisione, in tempo reale. Il risultato mi ha sorpreso abbastanza da volerlo documentare.
Una nota metodologica: l’AI che ho usato come guida in questo progetto è Claude di Anthropic, accessibile tramite claude.ai con la funzionalità Projects. Non è un articolo sponsorizzato , ho scelto Claude per la sua capacità di mantenere contesti tecnici complessi e per la qualità del ragionamento su problemi di modellazione dati ed è lo strumento che uso quotidianamente nel mio lavoro.
Come ho gestito la memoria tra le sessioni
Questo è il primo aspetto che vale la pena spiegare, perché è quello che rende possibile usare Claude su un progetto lungo che si estende su più sessioni di lavoro.
Claude non ha memoria nativa tra sessioni diverse:ogni volta che apri una nuova chat riparte da zero. Per un progetto come questo, che ha richiesto varie sessioni distribuite su più giorni, questo è un problema reale. La soluzione che ho adottato è stata strutturare una memoria esplicita attraverso un set di file .md caricati nel Project di Claude.
I file erano quattro:
CLAUDE.md — il file di configurazione generale: chi sono, cosa stiamo costruendo, le convenzioni di naming che voglio rispettare, le cose da non fare.
PBI_PROGRESS.md — il diario di avanzamento: stato di ogni fase, tabelle caricate, misure DAX create con i valori attesi, pagine report completate.
DAX_LIBRARY.md — il catalogo completo delle misure DAX scritte, con il codice, i valori attesi e le note d’uso.
DECISIONS.md — il log delle decisioni architetturali: perché ho scelto Import invece di DirectQuery, perché la relazione sellers-geolocation è inattiva, come ho gestito customer_unique_id.
A fine di ogni sessione aggiornavo i file con quello che avevamo fatto. All’inizio della sessione successiva Claude leggeva i file e ripartiva esattamente da dove avevamo lasciato : con il contesto completo del modello, le misure già scritte, i problemi già risolti. Questo ha trasformato uno strumento con memoria zero in qualcosa di simile a un collaboratore con continuità di progetto.
È un lavoro iniziale di circa 15 minuti per impostare i file ampiamente ripagato dalla qualità delle sessioni successive.
Perché Olist e non un dataset banale
La prima scelta importante è stata il dataset. Avrei potuto usare qualcosa di semplice, un foglio Excel con vendite e prodotti, schema a stella pulito, nessuna ambiguità. Ma avrei imparato poco.
Ho scelto il dataset Olist: un e-commerce brasiliano disponibile su Kaggle con dati reali dal 2016 al 2018. Nove file CSV, circa 100.000 ordini, dati geografici, recensioni, pagamenti. Una complessità molto più vicina a quello che si trova nei progetti reali.
Lo schema ha subito presentato tre sfide interessanti.
La prima è che ci sono due tabelle fatti collegate — olist_orders con gli ordini e olist_order_items con le righe prodotto. In SAP BW sei abituato a InfoCube separati con granularità diverse. In Power BI la logica è analoga ma la gestione è diversa — non puoi collegare due fact table direttamente senza conseguenze sui filtri.
La seconda è che olist_geolocation ha circa un milione di righe con coordinate GPS multiple per la stessa zip code. Non è una dimensione pulita — è una tabella di staging geografica che va deduplicata prima di poterla usare nel modello.
La terza è il caso di customer_id vs customer_unique_id — ogni ordine genera un customer_id diverso per lo stesso cliente fisico. Se non lo capisci subito, tutte le analisi di retention sono sbagliate e i numeri sembrano plausibili, quindi non te ne accorgi.
La Fase 1: caricare i dati senza fidarsi del metodo automatico
La prima sessione di lavoro è stata quasi interamente dedicata al caricamento e alla verifica dei dati in Power Query. Sembrava una fase banale …apri i CSV, Power BI li importa, vai avanti. Non è andata così.
Il primo problema si è presentato subito su olist_order_items. Le colonne price e freight_value mostravano valori assurdi: 58.90 diventava 5890. Il motivo è semplice ma insidioso: Power BI installato in italiano usa la virgola come separatore decimale, e il dataset brasiliano usa il punto. Il cambio tipo automatico applicava la cultura it-IT e trasformava ogni valore numerico in un intero moltiplicato per cento.
La soluzione non è nella UI grafica: bisogna andare nell’Advanced Editor di Power Query e aggiungere manualmente il parametro “en-US” allo step di cambio tipo:
= Table.TransformColumnTypes(
#"Promoted Headers",
{{"price", type number}, {"freight_value", type number}},
"en-US"
)
Quel “en-US” alla fine dice esplicitamente a Power Query quale cultura usare per interpretare i valori numerici. Senza di esso, la “cultura” del sistema operativo sovrascrive tutto.
Lo stesso problema si è ripresentato su olist_geolocation con latitudine e longitudine: le coordinate diventavano numeri in notazione scientifica tipo -2.35456E+15 invece di -23.54. Stesso fix, stesso parametro.
La lezione: non fidarti mai del cambio tipo automatico su dataset di provenienza estera. Forza sempre la cultura esplicitamente nell’Advanced Editor.
La Fase 2: le tre trasformazioni che cambiano il modello
Prima di costruire le relazioni, tre trasformazioni erano obbligatorie in Power Query.
Il consolidamento di geolocation: da un milione di righe a circa 19.000. Lo stesso zip code aveva coordinate GPS multiple — misurazioni diverse della stessa area. Un Group By su zip_code_prefix con Average su latitudine e longitudine ha prodotto una riga per zip code con le coordinate medie. Il risultato è una dimensione geografica pulita con una riga per zip code, indispensabile per costruire la relazione con customers e sellers senza ambiguità.
Il merge della traduzione categorie: olist_products ha i nomi delle categorie in portoghese, ma esiste un file separato con la traduzione in inglese. Un Merge Query con Left Outer Join incorpora la traduzione direttamente su products. Attenzione: il join falliva silenziosamente con il 93% di null a causa di spazi nascosti nei valori testuali. La soluzione è applicare Trim su entrambe le colonne prima del merge. Dopo il Trim i null scendono al 3%, quelli residui sono prodotti senza categoria nel sistema sorgente, non un problema di join.
La gestione di customer_unique_id: la più concettuale delle tre. customer_id è una surrogate key a livello di ordine: ogni ordine genera un ID diverso anche per lo stesso cliente fisico. Per il modello Power BI usiamo customer_id come chiave di relazione verso orders, ma per tutte le analisi di retention e repeat purchase usiamo customer_unique_id nelle misure DAX. È una distinzione che se non capisci all’inizio produce analisi sbagliate per tutta la durata del progetto.
La Fase 3: il modello dati
Con i dati puliti la costruzione del modello è stata più lineare. Power BI ha rilevato automaticamente sei relazioni corrette al momento del caricamento. Ne mancavano due — quelle verso geolocation da customers e da sellers — aggiunte manualmente.
Una cosa che vale la pena notare: la relazione sellers → geolocation è inattiva, Power BI non accetta due percorsi di filtro attivi verso la stessa tabella quando creano ambiguità nel modello. Non è un problema : la relazione inattiva si gestisce in DAX con USERELATIONSHIP quando serve analizzare i venditori per area geografica.
La Dim_Date è stata creata con CALENDARAUTO() in DAX, due righe di codice e Power BI genera automaticamente il calendario coprendo l’intero intervallo di date presente nel modello, dal 2016 al 2018.
La validazione finale è stata semplice: una Card con COUNTROWS(orders) deve mostrare 99.441. Se il numero torna, il modello è corretto.
Cosa ho imparato
Ripartire da uno strumento dopo un anno di pausa con un dataset complesso è stato più produttivo di quanto mi aspettassi. Il valore dell’AI come guida non è stato nel codice (la maggior parte del codice Power Query e DAX lo conosco) ma nel ragionamento preventivo. Sapere prima che geolocation va aggregata, che il punto decimale sarà un problema, che customer_unique_id è una trappola concettuale, tutto questo ha evitato ore di debug su numeri che sembravano giusti ma non lo erano.
Nella seconda parte racconterò le misure DAX, la costruzione delle pagine report con la mappa geografica degli stati brasiliani, e alcune riflessioni più ampie su come usare l’AI in modo strutturato su progetti BI reali.
