Introduzione
La creazione di un modello semantico ottimale è una delle attività più importanti che un analista dei dati può eseguire in Microsoft Power BI. Ottenere questo risultato significa semplificare la comprensione dei dati per gli utenti, rendendo più semplice la creazione di report di Power BI di grande utilità.
Le pagine di questo modulo offrono solo istruzioni e non forniscono file di dati. È possibile lavorare con dati reali nei lab.
Un modello semantico valido offre i vantaggi seguenti:
L'esplorazione dei dati è più veloce.
Le aggregazioni sono più semplici da creare.
I report sono più accurati.
La scrittura di report richiede meno tempo.
I report sono più facili da gestire in futuro.
Fornire regole impostate per ciò che rende difficile un modello semantico valido perché tutti i dati sono diversi e l'utilizzo di tali dati varia. In genere, un modello semantico più piccolo è migliore perché esegue più velocemente e sarà più semplice da usare. Tuttavia, definendo ciò che un modello semantico più piccolo comporta è altrettanto problematico perché è un concetto euristico e soggettivo.
In genere, un modello semantico più piccolo è costituito da meno tabelle e meno colonne in ogni tabella che l'utente può visualizzare. Se si importano tutte le tabelle necessarie da un database delle vendite, ma il numero totale di tabelle è 30, l'utente non troverà tali dati intuitivi. Il confronto di tali tabelle in cinque tabelle rende il modello semantico più intuitivo per l'utente, mentre se l'utente apre una tabella e trova 100 colonne, potrebbe risultare travolgente. La rimozione di colonne non gestite per fornire un numero più gestibile aumenta la probabilità che l'utente legge tutti i nomi di colonna. Per riepilogare, è consigliabile puntare alla semplicità durante la progettazione dei modelli semantici.
L'immagine seguente è un modello semantico di esempio. I riquadri contengono le tabelle di dati, in cui ogni voce all'interno del riquadro è una colonna. Le linee che connettono i riquadri rappresentano le relazioni tra le tabelle. Queste relazioni possono essere complesse, anche in questo modello semplicistico. Il modello semantico può diventare facilmente disorganizzato e il numero totale di tabelle nel modello può aumentare gradualmente. Mantenere il modello semantico semplice, completo e accurato richiede un impegno costante.
Le relazioni vengono definite tra le tabelle tramite chiavi primarie ed esterne. Le chiavi primarie sono colonne che identificano ogni riga di dati univoca non Null. Ad esempio, per una tabella Clienti si potrebbe avere un indice che identifica ogni cliente univoco. La prima riga ha un ID pari a 1, la seconda riga un ID pari a 2 e così via. A ogni riga viene assegnato un valore univoco a cui è possibile fare riferimento tramite questo semplice valore: la chiave primaria. Questo processo diventa importante quando si fa riferimento a righe in una tabella diversa, come nel caso delle chiavi esterne. Le relazioni tra tabelle vengono create quando sono presenti chiavi primarie ed esterne in comune tra tabelle diverse.
Power BI consente di creare relazioni da tabelle con origini dati diverse, una funzione potente che permette di eseguire il pull di una tabella da Microsoft Excel e di un'altra da un database relazionale. Si creerebbe quindi la relazione tra queste due tabelle e considerarle come modello semantico unificato.
Dopo aver appreso le relazioni che costituiscono lo schema dei dati, è possibile esplorare un tipo specifico di progettazione dello schema, lo schema star, ottimizzato per prestazioni elevate e usabilità.
Schemi star
È possibile progettare uno schema star per semplificare i dati. Non è l'unico modo per semplificare i dati, ma si tratta di un metodo diffuso e tutti gli analisti di dati di Power BI dovrebbero conoscerlo. In uno schema star ogni tabella all'interno del modello semantico è definita come dimensione o tabella dei fatti, come illustrato nell'oggetto visivo seguente.
Le tabelle dei fatti contengono valori di dati osservazionali o di evento: ordini di vendita, numeri di prodotti, prezzi, date e ore transazionali e quantità. Le tabelle dei fatti possono contenere diversi valori ripetuti. Ad esempio, un prodotto può comparire più volte in più righe, per clienti diversi in date diverse. Questi valori possono essere aggregati per creare oggetti visivi. Ad esempio, un oggetto visivo degli ordini di vendita totali è un'aggregazione di tutti gli ordini di vendita nella tabella dei fatti. Con le tabelle dei fatti è comune vedere colonne riempite con numeri e date. I numeri possono essere unità di misura, ad esempio un importo di vendita, oppure possono essere chiavi, ad esempio un ID cliente. Le date rappresentano l'elemento temporale registrato, ad esempio data dell'ordine o data di spedizione.
Le tabelle delle dimensioni contengono informazioni dettagliate sui dati nelle tabelle dei fatti, ovvero prodotti, posizioni, dipendenti e tipi di ordine. Queste tabelle sono connesse alla tabella dei fatti tramite colonne chiave. Le tabelle delle dimensioni vengono usate per filtrare e raggruppare i dati nelle tabelle dei fatti. Le tabelle dei fatti, invece, contengono i dati misurabili, ad esempio vendite e ricavi, e ogni riga rappresenta una combinazione univoca di valori delle tabelle delle dimensioni. Per l'oggetto visivo del totale degli ordini di vendita, è possibile raggruppare i dati in modo da visualizzare il totale degli ordini di vendita per prodotto, in cui il prodotto corrisponde ai dati nella tabella delle dimensioni.
Le tabelle dei fatti sono molto più grandi delle tabelle delle dimensioni perché numerosi eventi si verificano in tabelle di fatto, ad esempio singole vendite. Le tabelle delle dimensioni sono in genere più piccole perché si è limitati al numero di elementi che è possibile filtrare e raggruppare. Ad esempio, un anno contiene solo molti mesi e il Stati Uniti sono costituiti solo da un certo numero di stati.
Considerando queste informazioni sulle tabelle dei fatti e le tabelle delle dimensioni, ci si potrebbe chiedere come è possibile creare questo oggetto visivo in Power BI.
I dati pertinenti risiedono in due tabelle, Employee and Sales, come illustrato nel modello semantico seguente. Poiché la tabella Sales contiene i valori degli ordini di vendita, che possono essere aggregati, viene considerata una tabella dei fatti. La tabella Employee contiene il nome del dipendente specifico, che filtra gli ordini di vendita, quindi si tratta di una tabella delle dimensioni. La colonna comune tra le due tabelle, ovvero la chiave primaria nella tabella Employee, è EmployeeID, pertanto è possibile stabilire una relazione tra le due tabelle in base a questa colonna.
Quando si crea questa relazione, è possibile creare l'oggetto visivo in base ai requisiti, come illustrato nella figura seguente. Se non si stabilisse questa relazione, pur tenendo presenti gli elementi in comune tra le due tabelle, sarebbe più difficile creare l'oggetto visivo.
Gli schemi star e il modello semantico sottostante sono la base dei report organizzati; più tempo si impiegano per creare queste connessioni e progettare, più facile sarà creare e gestire i report.