Combinare dati provenienti da più tabelle è un’attività quotidiana per un data analyst, e in Power Query hai due strumenti concettualmente distinti: Append e Merge. Confonderli è uno degli errori più penalizzati all’esame, perché rispondono a esigenze diverse.

Append: impilare righe

L’operazione Append Queries unisce due o più tabelle impilando le righe una sotto l’altra. È l’equivalente di uno UNION: presuppone che le tabelle abbiano una struttura omogenea, cioè colonne con lo stesso nome e, idealmente, lo stesso tipo di dato.

Casi tipici: dodici file mensili di vendite (Sales_Jan, Sales_Feb, …) da consolidare in un’unica tabella Sales, oppure gli export di due filiali con lo stesso tracciato.

Punti da ricordare:

  • Le colonne vengono allineate per nome, non per posizione. Se una colonna si chiama Amount in una tabella e Total nell’altra, Power Query crea due colonne separate con valori null dove il dato manca.
  • Con Append Queries as New ottieni una nuova query senza alterare le sorgenti.
  • Per molte tabelle conviene raccoglierle da una cartella (connettore Folder) e usare la funzione di combinazione automatica.

Merge: join su chiavi

L’operazione Merge Queries affianca le colonne di due tabelle facendo corrispondere le righe in base a una o più colonne chiave. È l’equivalente di un JOIN SQL. Al termine ottieni una colonna di tipo Table che devi espandere (Expand) scegliendo quali campi importare.

Power Query espone sei tipi di join, ed è fondamentale saperli distinguere per scenario:

  • Left Outer: tutte le righe di sinistra + le corrispondenze di destra (il default, il più usato per gli arricchimenti/lookup).
  • Right Outer: tutte le righe di destra + le corrispondenze di sinistra.
  • Full Outer: tutte le righe di entrambe.
  • Inner: solo le righe con corrispondenza in entrambe le tabelle.
  • Left Anti: solo le righe di sinistra senza corrispondenza a destra.
  • Right Anti: solo le righe di destra senza corrispondenza a sinistra.

I join anti sono l’idioma per trovare gli orfani: prodotti venduti ma assenti in anagrafica, clienti senza ordini, chiavi che non matchano.

Merge in Power Query vs relazioni nel modello

Questa è la scelta architetturale che l’esame ama testare. Puoi collegare due tabelle fisicamente con un Merge in Power Query, oppure logicamente creando una relazione nel modello dati (vista Model).

  • Relazione nel modello: mantieni tabelle separate in uno schema a stella (fact + dimension). È l’approccio consigliato: preserva la granularità, riduce la ridondanza, comprime meglio (VertiPaq) e lascia che sia il motore a propagare i filtri. Preferiscilo quando servono lookup per fini analitici e vuoi misure DAX pulite.
  • Merge in Power Query: appiattisci i dati in un’unica tabella. Ha senso quando devi materializzare un attributo per una trasformazione a valle (es. calcolare una colonna che dipende da campi di due tabelle), o quando la tabella di lookup serve solo a portare uno o due campi e non merita un’entità propria. Ma denormalizzare troppo gonfia il modello e peggiora le performance.

Regola pratica: relazioni per l’analisi, merge solo quando la trasformazione lo richiede davvero.

Reference, duplicate e query di staging

Quando parti da una stessa origine per più elaborazioni, evita di riconnetterti più volte:

  • Duplicate: crea una copia indipendente con l’intera catena di passaggi ricopiata. Modifiche future non si propagano.
  • Reference: crea una query che parte dal risultato di un’altra. Modifichi la query a monte e tutte le referenze ne beneficiano.

Il pattern professionale è la query di staging: una query base (spesso con caricamento disabilitato, Enable load deselezionato) che si connette all’origine e applica le pulizie comuni. Da questa fai partire con Reference le query finali (una da caricare, una per un Merge, ecc.). Così l’origine viene interrogata una sola volta a livello logico e la manutenzione è centralizzata.

Trappole tipiche d’esame

  • Scenario: consolidare 12 file mensili con lo stesso tracciato → Append (non Merge): stai impilando righe, non cercando chiavi.
  • Scenario: trovare i clienti dell’anagrafica che non hanno mai effettuato un ordine → Merge con Left/Right Anti join, non un Inner filtrato.
  • Scenario: serve solo mostrare l’attributo di una dimension accanto ai fatti per l’analisi → relazione nel modello, non un Merge che denormalizza.
  • Scenario: due elaborazioni dalla stessa fonte senza ricaricarla due volte → query di staging con load disabilitato + Reference, non Duplicate.
  • Scenario: dopo il Merge le nuove colonne non compaiono → hai dimenticato di espandere (Expand) la colonna di tipo Table risultante.