Le categorie di connettori

Power BI Desktop espone centinaia di connettori tramite Get data, raggruppati per tipologia. Riconoscere la categoria giusta è il primo passo per scegliere l’origine corretta:

  • File: Excel, CSV/Text, JSON, XML, PDF e la connessione a Folder, che combina in un’unica query tutti i file con la stessa struttura contenuti in una cartella (ideale per export ricorrenti che si accumulano nel tempo).
  • Database relazionali: SQL Server, Azure SQL Database, PostgreSQL, Oracle, Snowflake. Espongono tipicamente sia Import sia DirectQuery.
  • Servizi online / SaaS: Dynamics 365, Salesforce, SharePoint Online, Google Analytics. L’autenticazione è quasi sempre OAuth, gestita dal connettore.
  • Piattaforma dati Azure: Azure Synapse, Azure Data Lake Storage e i vari elementi di Microsoft Fabric (Lakehouse, Warehouse, semantic model).
  • Generici — OData / Web / ODBC / OLE DB: il connettore Web legge tabelle HTML o risposte di API REST; OData interroga feed standardizzati esponendo entità già tabellari.

Quando esiste un connettore nativo per la sorgente, preferiscilo sempre a ODBC/OLE DB generici: gestisce meglio i tipi di dato, l’autenticazione e il query folding.

Import, DirectQuery e Live Connection

La modalità di connessione (storage mode) si sceglie nel momento in cui ci si collega e determina dove risiedono i dati e come vengono eseguite le query.

  • Import: i dati vengono copiati e compressi nel motore VertiPaq in memoria. È la modalità più performante e sblocca l’intero linguaggio DAX e Power Query. Richiede refresh pianificati e ha limiti di dimensione del modello.
  • DirectQuery: nessun dato viene importato; ogni interazione dell’utente genera query verso la sorgente in tempo reale. Adatto a dataset molto grandi, requisiti di near-real-time o vincoli di conformità che impediscono la copia dei dati. In cambio si perdono funzionalità DAX/M e le prestazioni dipendono dalla sorgente.
  • Live Connection: caso particolare per Power BI semantic model, Analysis Services e i modelli Fabric. Non crei un modello locale: ti connetti a uno esistente e costruisci solo la visualizzazione, ereditando misure e sicurezza a livello di riga (RLS) centralizzate.

Con Import e DirectQuery insieme si ottiene un modello Composite (mix di storage mode per tabella), argomento che approfondirai nel modulo di modellazione.

Parametri di connessione, privacy e credenziali

Parametri e origini dinamiche

I dettagli di connessione (server, database, percorso file) vanno parametrizzati con i Power Query parameters anziché codificati nelle query. Questo permette di promuovere un modello da dev a produzione, o di riutilizzare la stessa logica su ambienti diversi, cambiando un solo valore. Nel servizio, per le origini DirectQuery/Import, i parametri sono aggiornabili anche senza riaprire Desktop.

Credenziali e livelli di privacy

L’autenticazione si configura per origine dati e viene memorizzata separatamente dal file .pbix. Le opzioni tipiche sono Windows, Database (Basic), Microsoft account / OAuth, Key e Anonymous.

I privacy levels proteggono i dati impedendo che informazioni riservate vengano inviate ad altre sorgenti durante il folding delle query:

  • Private: mai combinata con altre origini.
  • Organizational: condivisibile solo con origini dello stesso confine di fiducia.
  • Public: liberamente combinabile.

Impostare tutto su Public accelera l’esecuzione ma può causare fughe di dati; livelli incoerenti tra due sorgenti generano l’errore di “Formula.Firewall”. La regola d’esame: i privacy levels servono alla sicurezza, non alle prestazioni.

Trappole tipiche d’esame

  • Scenario: dataset da 5 GB, refresh notturno accettabile, servono misure DAX complesse → scegli Import, non DirectQuery per abitudine: VertiPaq è molto più veloce e non impone i limiti di DAX. DirectQuery si giustifica solo con volumi che eccedono il modello, near-real-time o vincoli sul non copiare i dati.
  • Scenario: ti connetti a un Power BI semantic model già certificato e ti serve solo creare report riutilizzando misure e RLS esistenti → Live Connection, non Import (importare duplicherebbe modello e sicurezza).
  • Scenario: molti file Excel con struttura identica generati ogni mese in una directory → connettore Folder, non l’import file-per-file.
  • Scenario: combinando una tabella SQL riservata con un feed Web compare l’errore Formula.Firewall → correggi i privacy levels, non disattivarli globalmente per “farlo funzionare”.
  • Scenario: la stessa soluzione deve puntare a server dev e prod → usa un parameter per il nome server/database, evitando di modificare la query M a mano.