Ridurre la cardinalità
Il termine cardinalità viene usato per descrivere l'univocità dei valori in una colonna. Nel contesto delle relazioni tra due tabelle descrive invece la direzione della relazione.
Identificare i livelli di cardinalità nelle colonne
Quando prima si è usato l'editor di Power Query per analizzare i metadati, l'opzione Colonna distribuzione nella scheda Visualizza mostrava le statistiche sul numero di elementi distinti e univoci presenti in ogni colonna nei dati.
Distinct values count (Conteggio valori distinti): numero totale di valori diversi trovati in una determinata colonna.
Unique values count (Conteggio valori univoci): numero totale di valori visualizzati una sola volta in una determinata colonna.
Una colonna con molti valori ripetuti nel relativo intervallo (conteggio univoco è basso) avrà un basso livello di cardinalità. Al contrario, una colonna con numerosi valori univoci nell'intervallo (il conteggio dei valori univoci è elevato) avrà un livello di cardinalità elevato.
Una cardinalità inferiore comporta prestazioni più ottimizzate, pertanto potrebbe essere necessario ridurre il numero di colonne cardinali elevate nel modello semantico.
Ridurre la cardinalità di una relazione
Quando si importano più tabelle, è possibile che vengano eseguite analisi usando i dati inclusi nelle tabelle. Le relazioni tra le tabelle sono necessarie per calcolare con precisione i risultati e visualizzare le informazioni corrette nei report. Power BI Desktop semplifica la creazione di tali relazioni. Nella maggior parte dei casi, in effetti, tutte le operazioni verranno eseguite automaticamente dalla funzionalità Rilevamento automatico. In alcuni casi potrebbe tuttavia essere necessario creare relazioni o apportare modifiche a una relazione. È quindi importante comprendere le relazioni in Power BI Desktop e capire come crearle e modificarle.
Quando si crea o si modifica una relazione, è possibile configurare opzioni aggiuntive. Per impostazione predefinita, Power BI Desktop configura automaticamente le opzioni aggiuntive in base all'ipotesi migliore, che può essere diversa per ogni relazione a seconda dei dati nelle colonne.
Le relazioni possono avere una cardinalità diversa. La cardinalità è la direzione della relazione e ogni relazione del modello deve essere definita con un tipo di cardinalità. Le opzioni di cardinalità in Power BI sono:
Molti-a-uno (
*
:1): questo è il tipo di relazione più comune, predefinito. Significa che la colonna in una tabella può avere più istanze di un valore e l'altra tabella correlata, spesso nota come tabella di ricerca, include solo un'istanza di un valore.Uno-a-uno (1:1): in questo tipo di relazione la colonna in una tabella include solo un'istanza di un valore specifico e l'altra tabella correlata include solo un'istanza di un valore specifico.
Uno a molti (1:
*
): in questo tipo di relazione la colonna in una tabella ha solo un'istanza di un valore specifico e l'altra tabella correlata può avere più di un'istanza di un valore.Molti-a-molti (:): con i modelli compositi, è possibile stabilire una relazione molti-a-molti tra le tabelle, che elimina la necessità di valori univoci nelle tabelle, oltre a eliminare le soluzioni alternative precedenti, ad esempio l'introduzione di nuove tabelle solo per stabilire relazioni.
Durante lo sviluppo si creano e si modificano le relazioni nel modello, quindi quando si creano nuove relazioni nel modello, indipendentemente dalla cardinalità scelta, assicurarsi sempre che entrambe le colonne che si sta usando per partecipare a una relazione conosevidano lo stesso tipo di dati. Il modello non potrà funzionare se si prova a creare una relazione tra due colonne, in cui una colonna ha un tipo di dati testo e un'altra colonna ha un tipo di dati Integer.
Nell'esempio seguente il campo ProductID ha il tipo di dati Numero intero nelle tabelle Product e Sales. Le colonne con tipo di dati Integer hanno prestazioni migliori delle colonne con tipo di dati Testo.
Migliorare le prestazioni riducendo i livelli di cardinalità
Power BI Desktop offre diverse tecniche che è possibile usare per ridurre i dati caricati in modelli semantici, ad esempio il riepilogo. La riduzione dei dati caricati nel modello consentirà di migliorare la cardinalità delle relazioni del report. Per questo motivo, è importante cercare di ridurre al minimo i dati che verranno caricati nei modelli, soprattutto con i modelli di grandi dimensioni o i modelli che si prevede diventeranno sempre più grandi nel tempo.
La tecnica più efficace per ridurre le dimensioni di un modello consiste forse nell'usare una tabella di riepilogo proveniente dall'origine dati. Una tabella dettagliata potrebbe contenere ogni transazione, invece una tabella di riepilogo conterrà un record per ogni giorno, settimana o mese. Potrebbe trattarsi di una media di tutte le transazioni giornaliere, ad esempio.
Una tabella dei fatti di vendita di origine, ad esempio, archivia una riga per ogni riga dell'ordine. Per ridurre in modo significativo i dati, è possibile riepilogare tutte le metriche di vendita raggruppandole per data, cliente e prodotto. In questo modo i dettagli relativi alle singole transazioni non saranno necessari.
Si consideri quindi che una riduzione dei dati ancora più significativa può essere ottenuta raggruppando per data a livello di mese. È possibile raggiungere una riduzione del 99% delle dimensioni del modello, ma la creazione di report giornalieri o a livello di singolo ordine non sarà più possibile. Decidere di riepilogare i dati di tipo fatto richiederà sempre un compromesso con i dettagli dei dati. Uno svantaggio è che si potrebbe perdere la possibilità di eseguire il drill-in dei dati perché i dettagli non esistono più. Questo compromesso può essere limitato progettando un modello misto.
In Power BI Desktop la progettazione in modalità mista genera un modello composito. In pratica, consente di determinare una modalità di archiviazione per ogni tabella. Ogni tabella può quindi avere la proprietà Modalità di archiviazione impostata su Importazione o DirectQuery.
Una tecnica efficace per ridurre le dimensioni del modello consiste nell'impostare la proprietà Modalità di archiviazione per le tabelle di tipo fatto più grandi su DirectQuery. Questo approccio di progettazione può funzionare bene insieme alle tecniche usate per riepilogare i dati. Ad esempio, i dati di vendita riepilogati possono essere usati per ottenere report di "riepilogo" con prestazioni elevate. È possibile creare una pagina drill-through per visualizzare le vendite granulari per il contesto di filtro specifico (e ristretto), visualizzando tutti gli ordini di vendita nel contesto. La pagina drill-through includerà gli oggetti visivi in base a una tabella DirectQuery per recuperare i dati degli ordini di vendita (dettagli degli ordini di vendita).
Per altre informazioni, vedere Tecniche di riduzione dei dati per i modelli di importazione.