In Power BI, la qualità di un modello dati nasce nell’editor Power Query, molto prima delle misure DAX. Un dataset “sporco” (tipi errati, valori nulli, errori di conversione) produce relazioni instabili e aggregazioni scorrette. Per un data analyst di livello associate l’obiettivo non è “ripulire a occhio”, ma diagnosticare prima di trasformare, usando gli strumenti di profiling nativi e assegnando i tipi in modo esplicito e difendibile.
Profilare i dati prima di modellarli
Power Query offre tre strumenti di profiling nella scheda View. Attivali sempre e, punto cruciale, imposta il profiling su entire data set anziché sui top 1000 rows (default): su tabelle grandi le prime 1000 righe mentono spesso sulla reale distribuzione.
- Column quality: mostra le percentuali di valori Valid / Error / Empty. È il primo semaforo per capire dove intervenire con l’error handling.
- Column distribution: evidenzia distinct e unique count. Serve per scegliere la granularità e la chiave: una colonna candidata a chiave di relazione deve avere distinct = unique (nessun duplicato).
- Column profile: apre statistiche dettagliate (min, max, media, conteggi) e l’istogramma dei valori per una singola colonna. È lo strumento per stanare outlier e categorie inattese (“N/D”, “-”, stringhe vuote mascherate).
Questa fase guida le decisioni: quale colonna è affidabile come chiave, dove servono trasformazioni, quali errori tollerare.
Assegnare i data types in modo esplicito
Il data type non è cosmetica: è la base per relazioni, ordinamento, aggregazioni e time intelligence. Una colonna data tipizzata come Text non alimenta correttamente una tabella Date, non consente DATEDIFF e rompe le funzioni di intelligence temporale. Regola d’esame: tipizza esplicitamente ogni colonna alla fine delle trasformazioni, non affidarti al riconoscimento automatico.
Il tranello del cambio tipo con locale
In dataset internazionali, date e numeri hanno formati regionali diversi (31/12/2026 vs 12/31/2026; 1.234,56 vs 1,234.56). Un semplice Change Type usa il locale del file/report e può interpretare male i valori. La scelta corretta è Change Type → Using Locale…, che consente di dichiarare esplicitamente la cultura di origine (es. English (United States)) per convertire senza ambiguità. Ignorarlo genera errori silenziosi o date invertite.
Gestione degli errori e dei valori nulli
Dopo la tipizzazione compaiono spesso errori (valori non convertibili). Power Query offre tre strategie, con impatti diversi:
- Remove Errors: elimina l’intera riga contenente l’errore. Attenzione: perdi anche i dati validi delle altre colonne di quella riga.
- Replace Errors: sostituisce il valore in errore con un valore definito (0, “N/D”, null), mantenendo la riga. È la scelta quando la riga resta utile.
- Keep Errors: isola solo le righe con errori, ideale per investigare la fonte del problema prima di decidere.
I null vanno distinti dagli errori. Non sono un difetto in sé: rappresentano assenza di dato e influenzano le aggregazioni DAX (SUM ignora i null, COUNT no come si crede — conta i non-null). Usa Replace Values per normalizzare (es. null → 0 su una colonna di importi), oppure Remove Empty/filtri per scartare righe non significative. La scelta dipende dalla semantica: un null in “Sconto” spesso significa 0, un null in “DataOrdine” no.
Il rischio dei type change impliciti
Power Query aggiunge automaticamente uno step Changed Type che referenzia i nomi di colonna. Se l’origine dati cambia (una colonna rinominata a monte, o un CSV con header diverso), quello step si rompe e propaga errori a valle. Buone pratiche: consolidare la tipizzazione in un unico step controllato e, dove possibile, riferirsi alle colonne in modo robusto invece di accumulare Changed Type impliciti a ogni operazione.
Trappole tipiche d’esame
- Scenario: CSV americano con date che diventano errori/valori invertiti dopo Change Type → risposta: usa Change Type → Using Locale con la cultura di origine, non il Change Type standard.
- Scenario: righe con un errore in una colonna ma dati validi altrove → risposta: Replace Errors (mantiene la riga), non Remove Errors che scarta tutto.
- Scenario: devi individuare la causa degli errori di conversione → risposta: Keep Errors per isolarli e analizzarli.
- Scenario: il profiling mostra pochi distinct sospetti su tabella grande → risposta: passa da top 1000 rows a entire data set prima di trarre conclusioni.
- Scenario: la report page si rompe dopo un aggiornamento sorgente con colonna rinominata → risposta: causa probabile lo step Changed Type implicito che referenzia il vecchio nome colonna.