Eventi
31 mar, 23 - 2 apr, 23
L'ultimo evento guidato dalla community di Microsoft Fabric, Power BI, SQL e intelligenza artificiale. Dal 31 marzo al 2 aprile 2025.
Iscriviti oggi stessoQuesto browser non è più supportato.
Esegui l'aggiornamento a Microsoft Edge per sfruttare i vantaggi di funzionalità più recenti, aggiornamenti della sicurezza e supporto tecnico.
Questo articolo è destinato a esperti di modellazione di dati in Power BI Desktop. Descrive la progettazione dello schema star e la relativa rilevanza per lo sviluppo di modelli semantici di Power BI ottimizzati per prestazioni e usabilità.
Importante
I modelli semantici di Power BI dipendono da Power Query per importare o connettersi ai dati. Ciò significa che è necessario usare Power Query per trasformare e preparare i dati di origine, che potrebbero essere difficili quando si dispone di volumi di dati di grandi dimensioni o è necessario implementare concetti avanzati come dimensioni a modifica lenta (descritto più avanti in questo articolo).
Quando si presentano queste problematiche, è consigliabile sviluppare prima di tutto un data warehouse e processi ETL (Extract, Transform e Load) per caricare periodicamente il data warehouse. Il modello semantico può quindi connettersi al data warehouse. Per altre informazioni, vedere Modellazione dimensionale in Microsoft Fabric Warehouse.
Suggerimento
Questo articolo non intende fornire una trattazione completa sulla progettazione di uno schema a stella. Per altre informazioni, vedere direttamente il contenuto pubblicato ampiamente adottato, ad esempio The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (terza edizione, 2013) di Ralph Kimball e altri.
Lo schema a stella è un approccio maturo alla modellazione, ampiamente adottato dai data warehouse relazionali. In base a questo schema, gli esperti di modellazione devono classificare le tabelle del modello come dimensione o fatto.
Date
chiave della dimensione e ProductKey
. È evidente che la tabella ha due dimensioni. Non è tuttavia possibile determinare la granularità senza considerare i valori chiave di dimensione. In questo esempio si consideri che i valori archiviati nella Date
colonna sono il primo giorno di ogni mese. In questo caso, la granularità è a livello di mese-prodotto.In genere, le tabelle delle dimensioni contengono un numero relativamente piccolo di righe. Le tabelle dei fatti, d'altra parte, possono contenere un numero elevato di righe e continuare a crescere nel tempo.
Per comprendere alcuni concetti relativi allo schema star descritti in questo articolo, è importante conoscere due termini: normalizzazione e denormalizzazione.
Normalizzazione è il termine usato per descrivere i dati archiviati in modo da ridurre i dati ripetitivi. Si consideri una tabella di prodotti con una colonna chiave univoca, ad esempio il codice Product Key e altre colonne che descrivono le caratteristiche del prodotto, ad esempio il nome del prodotto, la categoria, il colore e le dimensioni. Una tabella sales viene considerata normalizzata quando archivia solo le chiavi, ad esempio il codice Product Key. Nell'immagine seguente si noti che solo la ProductKey
colonna registra il prodotto.
Se, tuttavia, la tabella sales archivia i dettagli del prodotto oltre la chiave, viene considerato denormalizzato. Nell'immagine seguente si noti che le ProductKey
e altre colonne correlate al prodotto registrano il prodotto.
Quando si estraggono dati da un file di esportazione o da un'estrazione di dati, è probabile che rappresenti un set di dati denormalizzato. In questo caso, usare Power Query per trasformare e modellare i dati di origine in più tabelle normalizzate.
Come descritto in questo articolo, è consigliabile cercare di sviluppare modelli semantici di Power BI ottimizzati con tabelle che rappresentano dati di fatti e dimensioni normalizzati. Tuttavia, esiste un'eccezione in cui una dimensione snowflake potrebbe essere denormalizzata per produrre una singola tabella del modello.
La progettazione di schemi a stella e molti concetti correlati introdotti in questo articolo sono particolarmente pertinenti allo sviluppo di modelli di Power BI ottimizzati per le prestazioni e l'usabilità.
Si consideri che ogni oggetto visivo report di Power BI genera una query inviata al modello semantico di Power BI. In genere, le query filtrano, raggruppano e riepilogano i dati del modello. Un modello ben progettato è quindi un modello che fornisce tabelle per il filtraggio e il raggruppamento e tabelle per il riepilogo dei dati. Questo tipo di progettazione si adatta bene ai principi dello schema a stella:
Non esiste alcuna proprietà di tabella impostata dai modellatori per impostare il tipo di tabella come dimensione o fatto. È infatti determinata dalle relazioni del modello. Una relazione di modello stabilisce un percorso di propagazione dei filtri tra due tabelle ed è la proprietà cardinalità della relazione che determina il tipo di tabella. Una cardinalità di relazione comune è uno-a-molti o il relativo inverso molti-a-uno. Il lato "uno" è sempre una tabella delle dimensioni, mentre il lato "molti" è sempre una tabella dei fatti.
Una struttura di modelli ben strutturata include tabelle che sono tabelle delle dimensioni o tabelle dei fatti. Evitare di combinare i due tipi per una singola tabella. È anche consigliabile cercare di fornire il numero corretto di tabelle con le relazioni corrette. È anche importante che le tabelle dei fatti carichino sempre i dati in base a una granularità coerente.
Infine, è importante capire che la progettazione di un modello ottimale è una combinazione di scienza e arte. A volte è ammissibile ignorare una buona indicazione se è più sensato procedere in modo diverso.
Esistono molti concetti correlati alla progettazione dello schema star che possono essere applicati a un modello semantico di Power BI. Essi includono:
Nella progettazione di uno schema a stella, una misura è una colonna della tabella dei fatti in cui vengono archiviati i valori da riepilogare. In un modello semantico di Power BI una misura ha una definizione diversa, ma simile. Un modello supporta misure esplicite e implicite.
SUM
, MIN
MAX
, AVERAGE
, e altre per produrre un risultato di valore scalare in fase di query (i valori non vengono mai archiviati nel modello). Un'espressione di misura può variare da semplici aggregazioni di colonne a formule più sofisticate che sostituiscono la propagazione di relazioni e/o contesti di filtro. Per altre informazioni, vedere Nozioni di base su DAX in Power BI Desktop.Sales Amount
Adventure Works può essere riepilogata in diversi modi (somma, conteggio, mediano, mediano, min, max e altri), senza la necessità di creare una misura per ogni tipo di aggregazione possibile.Nel riquadro Dati le misure esplicite sono rappresentate dall'icona della calcolatrice mentre le misure implicite sono rappresentate dal simbolo sigma (∑).
Esistono tuttavia tre motivi interessanti per cui è possibile creare misure, anche per semplici riepiloghi a livello di colonna:
Quando si sa che gli autori di report eseguiranno una query sul modello semantico usando MDX (Multidimensional Expressions), il modello deve includere misure esplicite. Questo perché MDX non è in grado di ottenere il riepilogo dei valori di colonna. In particolare, MDX viene usato durante l'esecuzione di Analyze in Excel perché le tabelle pivot eseguono query MDX.
Quando si è certi che gli autori di report creeranno report impaginati di Power BI usando progettazione query MDX, il modello semantico deve includere misure esplicite. Solo lo strumento di progettazione di query MDX supporta gli aggregati di server. Pertanto, se gli autori di report devono disporre di misure valutate da Power BI, anziché dal motore dei report impaginati, devono usare lo strumento di progettazione di query MDX.
Quando si vuole controllare il modo in cui gli autori di report riepilogano le colonne in modi specifici. Ad esempio, la colonna reseller sales Unit Price
(che rappresenta un tasso unitario) può essere riepilogata, ma solo usando funzioni di aggregazione specifiche. Non deve mai essere sommato, ma è opportuno riepilogare usando altre funzioni di aggregazione come min, max o average. In questo caso, il modeler può nascondere la Unit Price
colonna e creare misure per tutte le funzioni di aggregazione appropriate.
Questo approccio di progettazione è adatto ai report creati nel servizio Power BI e per Domande e risposte. Tuttavia, le connessioni dinamiche di Power BI Desktop consentono agli autori di report di visualizzare i campi nascosti nel riquadro Dati, che può comportare l'aggirare questo approccio di progettazione.
Una chiave sostitutiva è un identificatore univoco che viene aggiunto a una tabella per supportare la modellazione dello schema a stella. Per definizione, non è definito né archiviato nei dati di origine. Le chiavi sostitutive vengono in genere aggiunte alle tabelle delle dimensioni di un data warehouse relazionale per fornire un identificatore univoco per ogni riga di tabella delle dimensioni.
Le relazioni tra modelli semantici di Power BI si basano su una singola colonna univoca in una tabella, che propaga i filtri a una singola colonna in una tabella diversa. Quando una tabella delle dimensioni nel modello semantico non include una singola colonna univoca, è necessario aggiungere un identificatore univoco per diventare il lato "uno" di una relazione. In Power BI Desktop è possibile ottenere questo requisito aggiungendo una colonna di indice di Power Query.
È necessario unire questa query alla query sul lato "molti" in modo che sia possibile aggiungervi anche la colonna indice. Quando si caricano queste query nel modello semantico, è quindi possibile creare una relazione uno-a-molti tra le tabelle del modello.
Una dimensione a fiocco di neve è un set di tabelle normalizzate per una singola entità aziendale. Adventure Works, ad esempio, classifica i prodotti per categoria e sottocategoria. I prodotti vengono assegnati alle sottocategorie e le sottocategorie vengono assegnate a loro volta alle categorie. Nel data warehouse relazionale Adventure Works la dimensione del prodotto viene normalizzata e archiviata in tre tabelle correlate: DimProductCategory
, DimProductSubcategory
e DimProduct
.
Usando l'immaginazione, è possibile rappresentare le tabelle normalizzate all'esterno della tabella dei fatti, organizzate in base a uno schema a forma di fiocco di neve.
In Power BI Desktop è possibile scegliere di simulare una progettazione di dimensioni snowflake (ad esempio, perché i dati di origine lo fanno) o combinare le tabelle di origine per formare una singola tabella modello denormalizzata. I vantaggi offerti da una singola tabella del modello sono in genere maggiori rispetto all'uso di più tabelle. La decisione ottimale può dipendere dai volumi di dati e dai requisiti di usabilità per il modello.
Quando si sceglie di simulare una progettazione delle dimensioni a fiocco di neve:
Quando si sceglie di eseguire l'integrazione in una singola tabella del modello, è anche possibile definire una gerarchia che includa la granularità massima e minima della dimensione. È possibile che l'archiviazione dei dati denormalizzati ridondanti possa comportare un aumento delle dimensioni di archiviazione del modello, in particolare per le tabelle delle dimensioni di grandi dimensioni.
Una dimensione a modifica lenta (o SCD) è una dimensione che gestisce in modo appropriato la modifica dei membri della dimensione nel tempo. Si applica quando i valori delle entità aziendali cambiano lentamente nel tempo in modo non pianificato. Un buon esempio di scD è una dimensione del cliente, perché le colonne dei dettagli del contatto, ad esempio l'indirizzo di posta elettronica e il numero di telefono, cambiano raramente. Al contrario, alcune dimensioni vengono considerate rapidamente mutevoli quando un attributo di dimensione cambia spesso, come il prezzo di mercato di un titolo. L'approccio di progettazione comune in queste istanze consiste nell'archiviare i valori degli attributi a modifica rapida in una misura della tabella dei fatti.
La teoria della progettazione dello schema star si riferisce a due tipi comuni di scD: tipo 1 e tipo 2. Una tabella delle dimensioni può essere di tipo 1 o di tipo 2 oppure supportare entrambi i tipi contemporaneamente per colonne diverse.
Una dimensione a modifica lenta di tipo 1 riflette sempre i valori più recenti e, quando vengono rilevate modifiche nei dati di origine, i dati della tabella delle dimensioni vengono sovrascritti. Questo approccio di progettazione è comune per le colonne in cui vengono archiviati valori supplementari, ad esempio l'indirizzo di posta elettronica o il numero di telefono di un cliente. Quando viene modificato l'indirizzo di posta elettronica o il numero di telefono di un cliente, la tabella della dimensione aggiorna la riga del cliente con i nuovi valori. È come se il cliente avesse sempre avuto queste informazioni di contatto.
Un aggiornamento non incrementale di una tabella delle dimensioni del modello di Power BI ottiene il risultato di una scD di tipo 1. Aggiorna i dati della tabella per verificare che vengano caricati i valori più recenti.
Una dimensione a modifica lenta di tipo 2 supporta il controllo delle versioni dei membri della dimensione. Se il sistema di origine non archivia le versioni, in genere è il processo di caricamento del data warehouse che rileva le modifiche e gestisce in modo appropriato la modifica in una tabella delle dimensioni. In questo caso, la tabella delle dimensioni deve usare una chiave sostitutiva per fornire un riferimento univoco a una versione del membro della dimensione. Include anche colonne che definiscono la validità dell'intervallo di date della versione (ad esempio, StartDate
e EndDate
) ed eventualmente una colonna flag (ad esempio, IsCurrent
) per filtrare facilmente in base ai membri della dimensione corrente.
Ad esempio, Adventure Works assegna ogni venditore a un'area di vendita. Quando un venditore si sposta in un'altra area, è necessario creare una nuova versione del venditore per assicurarsi che i fatti cronologici rimangano associati all'area precedente. Per supportare un'analisi cronologica accurata delle vendite per venditore, è necessario che nella tabella delle dimensioni vengano archiviate le versioni dei venditori e le aree associate. La tabella deve includere anche i valori delle date di inizio e di fine per definire la validità a livello temporale. Le versioni correnti possono definire una data di fine vuota (o 31/12/9999), che indica che la riga è la versione corrente. La tabella deve anche avere una chiave surrogata perché la chiave business (in questa istanza, ID dipendente) non sarà univoca.
È importante comprendere che, quando nei dati di origine non vengono archiviate le versioni, è necessario usare un sistema intermedio (ad esempio un data warehouse) per rilevare e archiviare le modifiche. Il processo di caricamento della tabella deve conservare i dati esistenti e rilevare le modifiche. Quando viene rilevata una modifica, il processo di caricamento della tabella deve determinare la scadenza della versione corrente. Registra queste modifiche aggiornando il EndDate
valore e inserendo una nuova versione con il StartDate
valore che inizia dal valore precedente EndDate
. Inoltre, i fatti correlati devono usare una ricerca basata sul tempo per recuperare il valore della chiave della dimensione pertinente alla data del fatto. Un modello semantico di Power BI usa Power Query e quindi non può produrre questo risultato. Può tuttavia caricare i dati da una tabella delle dimensioni a modifica lenta di tipo 2 precaricata.
Suggerimento
Per informazioni su come implementare una tabella delle dimensioni A SCD di tipo 2 in un magazzino di Fabric, vedere Gestire la modifica cronologica.
Il modello semantico di Power BI deve supportare l'esecuzione di query sui dati cronologici per un membro, indipendentemente dalla modifica e per una versione del membro, che rappresenta uno stato specifico del membro nel tempo. Nel contesto di Adventure Works, questa progettazione consente di eseguire query sul venditore, indipendentemente dall'area di vendita assegnata, o per una particolare versione del venditore.
Per ottenere questo requisito, la tabella delle dimensioni del modello semantico di Power BI deve includere una colonna per filtrare il venditore e una colonna diversa per filtrare una versione specifica del venditore. È importante che la colonna version fornisca una descrizione non ambigua, ad esempio David Campbell (12/15/2008-06/26/2019)
o David Campbell (06/27/2019-Current)
. È inoltre importante istruire gli autori e gli utenti dei report sulle nozioni di base relative alle dimensioni a modifica lenta di tipo 2 e mostrare loro come ottenere strutture di report appropriate applicando filtri corretti.
È consigliabile includere una gerarchia che consente agli oggetti visivi di eseguire il drill-down a livello di versione.
Una dimensione con ruoli multipli è una dimensione che può filtrare i fatti correlati in modo diverso. Ad esempio, in Adventure Works la tabella delle dimensioni data ha tre relazioni con i fatti di vendita rivenditore. La stessa tabella delle dimensioni può essere usata per filtrare i fatti per data dell'ordine, data di spedizione o data di consegna.
In un data warehouse, l'approccio di progettazione accettato consiste nel definire una singola tabella delle dimensioni data. In fase di query, il "ruolo" della dimensione data viene stabilito in base alla colonna dei fatti usata per eseguire il join delle tabelle. Ad esempio, quando si analizzano le vendite in base alla data dell'ordine, il join delle tabelle è correlato alla colonna delle date degli ordini di vendita del rivenditore.
In un modello semantico di Power BI, questa progettazione può essere imitata creando più relazioni tra due tabelle. Nell'esempio di Adventure Works, le tabelle relative alla data e alle vendite del rivenditore avrebbero tre relazioni.
Anche se questa progettazione è possibile, può esistere una sola relazione attiva tra due tabelle del modello semantico di Power BI. Tutte le relazioni rimanenti devono essere impostate come inattive. Avere una singola relazione attiva significa che esiste una propagazione del filtro predefinita da data a rivenditore. In questo caso, la relazione attiva viene impostata sul filtro più comune usato dai report, che in Adventure Works è la relazione di data dell'ordine.
L'unico modo per usare una relazione inattiva consiste nel definire un'espressione DAX che usa la funzione USERELATIONSHIP. In questo esempio, lo sviluppatore del modello deve creare misure per consentire l'analisi delle vendite del rivenditore in base alla data di spedizione e alla data di consegna. Questo lavoro può essere noioso, soprattutto quando la tabella del rivenditore definisce molte misure. Crea anche un riquadro dati ingombrato con una sovrabbondanza di misure. Vi sono anche altre limitazioni:
Per superare queste limitazioni, una tecnica di modellazione di Power BI comune consiste nel creare una tabella delle dimensioni per ogni istanza di ruolo. È possibile creare ogni tabella delle dimensioni come query di riferimento usando Power Query o una tabella calcolata usando DAX. Il modello può contenere una tabella, una Date
Ship Date
tabella e una Delivery Date
tabella, ognuna con una singola relazione e attiva con le rispettive colonne della tabella sales reseller.
Questo approccio di progettazione non richiede la definizione di più misure per diversi ruoli di data e consente di filtrare simultaneamente in base a ruoli di data diversi. Un prezzo minore da pagare con questo approccio di progettazione, tuttavia, è che ci sarà duplicazione della tabella delle dimensioni data con conseguente aumento delle dimensioni del modello. Poiché le tabelle delle dimensioni in genere archiviano meno righe rispetto alle tabelle dei fatti, raramente si tratta di un problema.
È consigliabile seguire le procedure di progettazione consigliate per la creazione di tabelle delle dimensioni del modello per ogni ruolo:
Year
colonna in tutte le tabelle delle date (i nomi di colonna sono univoci all'interno della tabella), non è autodescrittura per impostazione predefinita. Prendere in considerazione la ridenominazione delle colonne in ogni tabella del ruolo dimensione in modo che la Ship Date
tabella abbia una colonna annuale denominata Ship Year
e così via.Date
, che viene usata per filtrare molte tabelle dei fatti. Nel caso in cui questa tabella abbia, ad esempio, una relazione attiva con la colonna data ordine vendita rivenditore, valutare la possibilità di fornire una descrizione di tabella come Filters reseller sales by order date
.Per altre informazioni, vedere Linee guida per relazioni attive e inattive.
Una dimensione di tipo junk è utile quando vi sono molte dimensioni, costituite in particolare da pochi attributi (talvolta anche uno solo), e quando questi attributi hanno pochi valori. I candidati validi includono colonne relative allo stato dell'ordine o colonne demografiche dei clienti, ad esempio sesso o fascia d'età.
L'obiettivo di progettazione di una dimensione indesiderata consiste nel consolidare molte dimensioni di piccole dimensioni in una singola dimensione per ridurre le dimensioni di archiviazione del modello e ridurre anche il disordine del riquadro dati visualizzando un numero inferiore di tabelle del modello.
Una tabella delle dimensioni indesiderate è in genere il prodotto cartesiano di tutti i membri dell'attributo dimensione, con una colonna chiave surrogata per identificare in modo univoco ogni riga. È possibile creare la dimensione in un data warehouse oppure usando Power Query per creare una query che esegue full outer join di query e quindi aggiunge una chiave sostitutiva (colonna indice).
Questa query viene caricata nel modello come tabella delle dimensioni. È anche necessario unire questa query con la query dei fatti in modo che la colonna di indice venga caricata nel modello per supportare la creazione di una relazione di modello "uno-a-molti".
Una dimensione degenerata fa riferimento a un attributo della tabella dei fatti necessaria per il filtro. In Adventure Works, un valido esempio è rappresentato dal numero di ordine di vendita di un rivenditore. In questo caso, non ha senso creare una tabella indipendente costituita da una sola colonna perché aumenterebbe le dimensioni di archiviazione del modello e generava confusione nel riquadro Dati .
Nel modello semantico di Power BI può essere opportuno aggiungere la colonna numero ordine vendita alla tabella dei fatti per consentire il filtro o il raggruppamento in base al numero dell'ordine di vendita. Si tratta di un'eccezione alla regola introdotta in precedenza che non è consigliabile combinare i tipi di tabella (in genere, le tabelle del modello devono essere dimensioni o fatti).
Tuttavia, se la tabella vendite dei rivenditori Adventure Works include colonne numero ordine e numero di riga dell'ordine e sono necessari per filtrare, la creazione di una tabella delle dimensioni degenerata sarebbe una progettazione ottimale. Per altre informazioni, vedere Linee guida per relazioni uno-a-uno (Dimensioni degenere).
Una tabella dei fatti senza fatti non include colonne di misure. Contiene solo chiavi di dimensione.
Una tabella dei fatti senza fatti può archiviare le osservazioni definite dalle chiavi di dimensione. Ad esempio, in una determinata data e ora, un particolare cliente ha eseguito l'accesso al sito Web. È possibile definire una misura per contare le righe della tabella dei fatti senza fatti per eseguire l'analisi di quando e quanti clienti hanno eseguito l'accesso.
Un uso più interessante di una tabella dei fatti senza fatti consiste nell'archiviare le relazioni tra le dimensioni ed è un approccio di progettazione di modelli semantici di Power BI consigliato per definire relazioni tra dimensioni molti-a-molti. In una progettazione basata su relazioni di tipo molti-a-molti tra le dimensioni, la tabella dei fatti senza fatti è definita tabella di bridging.
Si consideri, ad esempio, il caso in cui i venditori possono essere assegnati a una o più aree di vendita. La tabella di bridging verrebbe progettata come una tabella dei fatti senza fatti costituita da due colonne: chiave del venditore e chiave dell'area. I valori duplicati possono essere archiviati in entrambe le colonne.
Questo approccio di progettazione basato su relazioni molti-a-molti è ben documentato e può essere ottenuto senza una tabella di bridging. Tuttavia, l'approccio della tabella di bridging è considerato ottimale quando si stabilisce una relazione tra due dimensioni. Per altre informazioni, vedere Linee guida per le relazioni molti-a-molti (Correlare due tabelle di tipo dimensione).
Per altre informazioni sulla progettazione dello schema star o sulla progettazione di modelli semantici di Power BI, vedere gli articoli seguenti:
Eventi
31 mar, 23 - 2 apr, 23
L'ultimo evento guidato dalla community di Microsoft Fabric, Power BI, SQL e intelligenza artificiale. Dal 31 marzo al 2 aprile 2025.
Iscriviti oggi stessoFormazione
Modulo
Progettazione di un modello semantico in Power BI - Training
Il processo di creazione di un complicato modello semantico in Power BI è semplice. Se i dati provengono da più di un sistema transazionale, è possibile che in poco tempo ci si trovi a dover lavorare con dozzine di tabelle. La definizione di un modello semantico di ottima qualità presuppone la semplificazione del disordine. Uno schema a stella è un modo per semplificare un modello semantico e in questo modulo se ne impareranno la terminologia e le modalità di implementazione. Si apprenderanno anche i motivi
Certificazione
Microsoft Certified: Power BI Data Analyst Associate - Certifications
Illustrare metodi e procedure consigliate in linea con i requisiti aziendali e tecnici per la modellazione, la visualizzazione e l'analisi dei dati con Microsoft Power BI.