L’ecosistema Power BI: tre strumenti, un flusso

Power BI non è un singolo prodotto ma un ecosistema di componenti che si scambiano gli stessi artefatti. Capire “chi fa cosa” è il primo passo per rispondere correttamente alle domande architetturali del PL-300, dove spesso ti viene chiesto in quale strumento eseguire una certa operazione.

Power BI Desktop — l’ambiente di authoring

Power BI Desktop è l’applicazione Windows gratuita dove si costruisce. È qui che avvengono le tre attività fondanti:

  • Connessione e trasformazione dei dati tramite Power Query (motore M), con operazioni di pulizia, unpivot, merge/append e profiling.
  • Modellazione: definizione di relazioni, gerarchie, misure DAX, colonne calcolate, formattazione e Row-Level Security (RLS).
  • Progettazione dei report: pagine, visual, interazioni, bookmark.

Desktop produce un file .pbix (o il formato progetto .pbip). L’authoring del modello e la logica di business vivono qui: il Service non consente di ricostruire un modello da zero con la stessa profondità.

Il semantic model — il cuore riutilizzabile

Il concetto centrale è il semantic model (nome attuale di quello che si chiamava dataset). È l’insieme di tabelle, relazioni, misure DAX e regole RLS: il “cervello” analitico, separato dai report che lo consumano.

Questa separazione abilita un pattern chiave d’esame: i thin report (report “sottili”) che si collegano in Live connection a un semantic model condiviso e certificato. Un solo modello ben governato alimenta decine di report, evitando duplicazione di logica e discrepanze nei KPI. La storage mode del modello (Import, DirectQuery, Dual) determina dove risiedono i dati e come vengono interrogati.

Power BI Service — pubblicazione, collaborazione, distribuzione

Power BI Service (app.powerbi.com) è la piattaforma cloud SaaS. Dopo il Publish dal Desktop, gli artefatti vivono in un workspace e qui si:

  • pianifica il refresh dei dati e si gestiscono le credenziali;
  • collabora nei workspace e si distribuisce ai consumatori tramite Power BI Apps;
  • applica governance: endorsement (Promoted/Certified), sensitivity label, deployment pipeline.

Il Service è anche dove si consuma: dashboard, Q&A in linguaggio naturale e sottoscrizioni. Le app Mobile (iOS/Android) sono principalmente client di consumo del contenuto pubblicato, non strumenti di authoring.

Dove si colloca il data gateway

Il data gateway (nella variante on-premises data gateway, modalità standard/enterprise) è il ponte tra il Service in cloud e le origini dati che vivono on-premises o in reti private. Serve quando:

  • si esegue lo scheduled refresh di un modello Import basato su un database aziendale on-prem;
  • si usa DirectQuery / Live connection verso una sorgente non raggiungibile dal cloud.

Punto cruciale spesso frainteso: Power BI Desktop non usa il gateway. In authoring ti connetti direttamente alla sorgente. Il gateway entra in gioco solo dopo la pubblicazione, per il traffico dal Service verso i dati. La modalità personal serve refresh individuali; quella standard è condivisibile fra più utenti e sorgenti ed è la scelta enterprise.

Il workflow PL-300 mappato ai domini d’esame

Il ciclo di lavoro Connetti → Trasforma → Modella → Visualizza → Pubblica → Gestisci si allinea direttamente ai quattro domini misurati:

  • Prepare the data → Connetti e Trasforma (Power Query, profiling, storage mode).
  • Model the data → Modella (relazioni, star schema, DAX, RLS).
  • Visualize and analyze the data → Visualizza (visual, interazioni, AI visual).
  • Manage and secure Power BI → Pubblica e Gestisci (workspace, app, gateway, refresh, sicurezza).

Tenere a mente questa mappa aiuta a collocare ogni funzionalità nel dominio corretto e nello strumento giusto.

Trappole tipiche d’esame

  • Scenario: devi aggiornare automaticamente un modello Import che legge da un SQL Server on-premises. → Configura un on-premises data gateway (standard mode) nel Service; il gateway non serve in Desktop.
  • Scenario: più team creano report divergenti sugli stessi KPI. → Pubblica un semantic model condiviso e certificato e crea thin report in Live connection, invece di duplicare il modello in ogni .pbix.
  • Scenario: la domanda chiede dove definire una misura DAX o la RLS. → In Power BI Desktop (modellazione), non nel Service.
  • Scenario: un dirigente deve solo consultare i report dallo smartphone. → Distribuisci tramite Power BI App; l’app Mobile è client di consumo, non di authoring.
  • Scenario: “dataset” in una domanda datata. → Interpretalo come semantic model; è lo stesso oggetto rinominato, cuore riutilizzabile separato dai report.