Informazioni su uno schema a stella e sull'importanza di questo schema per Power BI

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à.

Panoramica dello schema a stella

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.

• Le tabelle delle dimensioni descrivono le entità aziendali, ovvero gli elementi modellati. Le entità possono essere prodotti, persone, luoghi e concetti, incluso il tempo stesso. La tabella più coerente presente in uno schema a stella è una tabella delle dimensioni di data. Una tabella delle dimensioni contiene una colonna chiave (o colonne) che funge da identificatore univoco e altre colonne. Altre colonne supportano il filtro e il raggruppamento dei dati.
• Le tabelle dei fatti archiviano osservazioni o eventi e possono essere ordini di vendita, saldi azionari, tassi di cambio, temperature e altro ancora. Una tabella dei fatti contiene colonne chiave di dimensione, correlate alle tabelle delle dimensioni, e colonne di misure numeriche. Le colonne chiave delle dimensioni determinano la dimensionalità di una tabella dei fatti, mentre i valori chiave delle dimensioni determinano la granularità di una tabella dei fatti. Si consideri, ad esempio, una tabella dei fatti progettata per archiviare le destinazioni di vendita con due colonne 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.

Normalizzazione e denormalizzazione

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.

Pertinenza dello schema star per i modelli semantici di Power BI

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:

• Le tabelle delle dimensioni consentono di filtrare e raggruppare.
• Le tabelle dei fatti consentono il riepilogo.

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:

• Misure
• Chiavi sostitutive
• Dimensioni a fiocco di neve
• Dimensioni con ruoli multipli
• Dimensioni a modifica lenta
• Dimensioni di tipo junk
• Dimensioni degeneri
• Tabelle dei fatti senza fatti

Misure

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.

• Le misure esplicite vengono create espressamente e si basano su una formula scritta in DATA Analysis Expressions (DAX) che ottiene il riepilogo. Le espressioni di misura usano spesso funzioni di aggregazione DAX come SUM, MINMAX, 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.
• Le misure implicite sono colonne che possono essere riepilogate da un oggetto visivo report o Q&A. Offrono una comodità per gli sviluppatori di modelli, come in molti casi non è necessario creare misure (esplicite). Ad esempio, la colonna vendite rivenditore 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.

Chiavi sostitutive

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.

Dimensioni a fiocco di neve

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, DimProductSubcategorye 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:

• Power BI carica più tabelle, il che è meno efficiente dal punto di vista dell'archiviazione e delle prestazioni. Le tabelle devono includere colonne per supportare le relazioni tra modelli e ciò può comportare un aumento delle dimensioni del modello.
• È necessario attraversare catene di propagazione del filtro delle relazioni più lunghe, che potrebbero risultare meno efficienti rispetto ai filtri applicati a una singola tabella.
• Il riquadro Dati presenta più tabelle modello agli autori di report, con un'esperienza meno intuitiva, soprattutto quando le tabelle delle dimensioni snowflake contengono solo una o due colonne.
• Non è possibile creare una gerarchia che comprende colonne di più tabelle.

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.

Dimensioni a modifica lenta

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.

Dimensione a modifica lenta di tipo 1

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.

Dimensione a modifica lenta di tipo 2

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.

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.

Dimensioni con ruoli multipli

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:

• Quando gli autori di report si basano sul riepilogo delle colonne anziché sulla definizione di misure, non possono ottenere il riepilogo per le relazioni inattive senza scrivere una misura a livello di report. Le misure a livello di report possono essere definite solo quando si creano report in Power BI Desktop.
• Con un solo percorso di relazione attivo tra le date e le vendite del rivenditore, non è possibile filtrare contemporaneamente le vendite del rivenditore in base a diversi tipi di date. Non è ad esempio possibile generare un oggetto visivo che traccia le vendite alla data dell'ordine in base alle vendite spedite.

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:

• Verificare che i nomi delle colonne siano autodescrittivi. Sebbene sia possibile avere una 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 Yeare così via.
• Quando pertinente, assicurarsi che le descrizioni delle tabelle forniscano feedback agli autori di report (tramite descrizioni comando del riquadro dati ) sulla configurazione della propagazione dei filtri. Questa chiarezza è importante quando il modello contiene una tabella denominata in modo generico, ad esempio 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.

Dimensioni di tipo junk

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".

Dimensioni degenerate

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).

Tabelle dei fatti senza fatti

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).

Contenuto correlato

Per altre informazioni sulla progettazione dello schema star o sulla progettazione di modelli semantici di Power BI, vedere gli articoli seguenti:

• Articolo di Wikipedia sulla modellazione dimensionale
• Relazioni nei modelli in Power BI Desktop
• Linee guida per relazioni uno-a-uno
• Linee guida per le relazioni molti-a-molti
• Linee guida per la relazione bidirezionale
• Linee guida per relazioni attive e inattive
• Modellazione dimensionale nel magazzino di Microsoft Fabric
• Domande? Provare a chiedere alla community dell'infrastruttura
• Suggerimenti? Contribuire alle idee per migliorare l'infrastruttura