Comprendere lo schema star e l'importanza per Power BI

Questo articolo è destinato ai modelli di dati di Power BI Desktop. Descrive la progettazione dello schema star e la relativa rilevanza per lo sviluppo di modelli di dati di Power BI ottimizzati per prestazioni e usabilità.

Questo articolo non è destinato a fornire una discussione completa sulla progettazione dello schema star. Per altri dettagli, fare riferimento direttamente al contenuto pubblicato, ad esempio The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3rd edition, 2013) di Ralph Kimball e altri.

Panoramica dello schema Star

Lo schema Star è un approccio di modellazione maturo ampiamente adottato dai data warehouse relazionali. Richiede ai modeler di 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 o più colonne chiave, che fungono da identificatore univoco, e colonne descrittive.

Le tabelle dei fatti archiviano osservazioni o eventi e possono essere ordini di vendita, saldi azionari, tassi di cambio, temperature e così via. Una tabella dei fatti contiene colonne chiave della dimensione correlate alle tabelle delle dimensioni e alle colonne delle 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 chiave della dimensione Date e ProductKey. È facile comprendere che la tabella ha due dimensioni. La granularità, tuttavia, non può essere determinata senza considerare i valori chiave della dimensione. In questo esempio si consideri che i valori archiviati nella colonna Date 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 molto 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.

La 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 chiave univoca, ad esempio il codice Product Key, e colonne aggiuntive che descrivono le caratteristiche del prodotto, tra cui nome del prodotto, categoria, colore e 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 colonna ProductKey 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 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 di dati di Power BI ottimizzati con tabelle che rappresentano dati di fatti e dimensioni normalizzati. Tuttavia, esiste un'eccezione in cui una dimensione snowflake deve essere denormalizzata per produrre una singola tabella del modello.

Pertinenza dello schema a stella per i modelli di Power BI

La progettazione dello schema star e molti concetti correlati introdotti in questo articolo sono estremamente rilevanti per lo sviluppo di modelli di Power BI ottimizzati per prestazioni e usabilità.

Si consideri che ogni oggetto visivo del report di Power BI genera una query inviata al modello di Power BI (che il servizio Power BI chiama un modello semantico, noto in precedenza come set di dati). Queste query vengono usate per filtrare, raggruppare e riepilogare i dati del modello. Un modello ben progettato, quindi, è uno che fornisce tabelle per filtrare e raggruppare e tabelle per il riepilogo. Questo tipo di progettazione si adatta bene ai principi dello schema a stella:

• Le tabelle delle dimensioni supportano il filtro e il raggruppamento
• Le tabelle dei fatti supportano il riepilogo

Non esiste alcuna proprietà di tabella impostabile per configurare il tipo di tabella come dimensione o fatto. In realtà, il tipo viene determinato dalle relazioni del modello. Una relazione di modello stabilisce un percorso di propagazione del filtro tra due tabelle ed è la proprietà Cardinality della relazione che determina il tipo di tabella. Una cardinalità di relazione comune è uno-a-molti o il suo inverso molti-a-uno. Il lato "uno" è sempre una tabella di tipo dimensione mentre il lato "molti" è sempre una tabella di tipo fatto. Per altre informazioni sulle relazioni, vedere Relazioni tra modelli in Power BI Desktop.

Un modello ben strutturato deve includere tabelle che siano di tipo dimensione o di tipo fatto. Evitare di combinare i due tipi per una singola tabella. È inoltre consigliabile fare il possibile per fornire il giusto numero di tabelle con le giuste relazioni definite. È anche importante che le tabelle di tipo fatto carichino sempre dati con 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 aggiuntivi correlati alla progettazione dello schema star che può essere applicata a un modello di Power BI. Essi includono:

• Misure
• Chiavi surrogate
• Dimensioni snowflake
• Dimensioni con ruoli
• Dimensioni a modifica lenta
• Dimensioni indesiderate
• Dimensioni degenerate
• Tabelle dei fatti senza fatti

Misure

Nella progettazione dello schema star, una misura è una colonna della tabella dei fatti che archivia i valori da riepilogare.

In un modello di Power BI una misura ha una definizione diversa, ma simile. Si tratta di una formula scritta in DAX (Data Analysis Expressions) che ottiene il riepilogo. Le espressioni di misura spesso sfruttano funzioni di aggregazione DAX come SUM, MIN, MAX, AVERAGE e così via per produrre un risultato di valore scalare in fase di query (i valori non vengono mai archiviati nel modello). L'espressione di misura può variare da aggregazioni di colonne semplici a formule più sofisticate che eseguono l'override del contesto di filtro e/o della propagazione delle relazioni. Per altre informazioni, vedere l'articolo Nozioni di base su DAX in Power BI Desktop .

È importante comprendere che i modelli di Power BI supportano un secondo metodo per ottenere il riepilogo. Qualsiasi colonna, e in genere colonne numeriche, può essere riepilogata da un oggetto visivo report o Q&A. Queste colonne vengono definite misure implicite. Offrono una comodità per gli sviluppatori di modelli, come in molti casi non è necessario creare misure. Ad esempio, la colonna Sales Amount dei rivenditori Adventure Works può essere riepilogata in diversi modi (somma, conteggio, mediano, mediano, min, max e così via), senza la necessità di creare una misura per ogni tipo di aggregazione possibile.

Esistono tuttavia tre motivi interessanti per creare misure, anche per semplici riepiloghi a livello di colonna:

• Quando si sa che gli autori di report eseguiranno query sul modello usando MDX (Multidimensional Expressions), il modello deve includere misure esplicite. Le misure esplicite vengono definite tramite DAX. Questo approccio di progettazione è estremamente rilevante quando viene eseguita una query su un set di dati di Power BI tramite MDX, perché MDX non è in grado di ottenere il riepilogo dei valori di colonna. In particolare, MDX verrà usato durante l'esecuzione di Analizza 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 deve includere misure esplicite. Solo Progettazione query MDX supporta le aggregazioni server. Pertanto, se gli autori di report devono avere misure valutate da Power BI (anziché dal motore di report impaginato), devono usare progettazione query MDX.
• Quando è necessario assicurarsi che gli autori di report possano riepilogare solo 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, average e così via. In questo caso, il modeler può nascondere la colonna Unit Price e creare misure per tutte le funzioni di aggregazione appropriate.

Questo approccio di progettazione funziona bene per i report creati nella servizio Power BI e per Q&A. Tuttavia, le connessioni dinamiche di Power BI Desktop consentono agli autori di report di visualizzare i campi nascosti nel riquadro Campi , che può comportare l'aggirare questo approccio di progettazione.

Chiavi surrogate

Una chiave surrogata è un identificatore univoco aggiunto a una tabella per supportare la modellazione dello schema star. Per definizione, non è definito o archiviato nei dati di origine. In genere, le chiavi surrogate vengono aggiunte alle tabelle delle dimensioni del data warehouse relazionale per fornire un identificatore univoco per ogni riga della tabella delle dimensioni.

Le relazioni tra modelli 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 di tipo dimensione nel modello 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 facilmente questo requisito creando una colonna di indice di Power Query.

È necessario unire questa query con la query sul lato "molti", in modo da poter aggiungere anche la colonna di indice. Quando si caricano queste query nel modello, è quindi possibile creare una relazione uno-a-molti tra le tabelle del modello.

Dimensioni snowflake

Una dimensione snowflake è un set di tabelle normalizzate per una singola entità aziendale. Ad esempio, Adventure Works 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.

Se usi la tua immaginazione, puoi immaginare le tabelle normalizzate posizionate verso l'esterno dalla tabella dei fatti, formando un design snowflake.

In Power BI Desktop è possibile scegliere di simulare una progettazione di dimensioni snowflake (ad esempio perché i dati di origine lo fanno) o integrare (denormalizzare) le tabelle di origine in una singola tabella del modello. In genere, i vantaggi di una singola tabella del modello superano i vantaggi di più tabelle del modello. La decisione ottimale può dipendere dai volumi di dati e dai requisiti di usabilità per il modello.

Quando si sceglie di simulare una progettazione di dimensioni snowflake:

• Power BI carica più tabelle, meno efficienti dalle prospettive di archiviazione e prestazioni. Queste tabelle devono includere colonne per supportare le relazioni del modello e possono comportare dimensioni del modello maggiori.
• Sarà necessario attraversare catene di propagazione del filtro delle relazioni più lunghe, che probabilmente saranno meno efficienti rispetto ai filtri applicati a una singola tabella.
• Il riquadro Campi 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 si estende sulle tabelle.

Quando si sceglie di integrarsi in una singola tabella del modello, è anche possibile definire una gerarchia che includa la granularità più alta e più bassa 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 di dimensioni molto grandi.

Dimensioni a modifica lenta

Una dimensione a modifica lenta (SCD) è una dimensione che gestisce in modo appropriato il cambiamento dei membri della dimensione nel tempo. Si applica quando i valori delle entità aziendali cambiano nel tempo e in modo ad hoc. Un buon esempio di una dimensione a modifica lenta è una dimensione del cliente, in particolare le colonne dei dettagli dei contatti, ad esempio l'indirizzo di posta elettronica e il numero di telefono. Al contrario, alcune dimensioni vengono considerate rapidamente mutevoli quando un attributo di dimensione cambia spesso, ad esempio il prezzo di mercato di un titolo. L'approccio di progettazione comune in queste istanze consiste nell'archiviare rapidamente i valori degli attributi in una misura di 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 di tipo dimensione può essere di tipo 1 o di tipo 2 oppure supportare entrambi i tipi contemporaneamente per colonne diverse.

ScD di tipo 1

Un scD di tipo 1riflette 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 che archivia valori supplementari, ad esempio l'indirizzo di posta elettronica o il numero di telefono di un cliente. Quando un indirizzo di posta elettronica o un numero di telefono del cliente cambia, la tabella delle dimensioni aggiorna la riga del cliente con i nuovi valori. È come se il cliente avesse sempre queste informazioni di contatto.

Un aggiornamento non incrementale di una tabella di tipo dimensione del modello di Power BI ottiene il risultato di una scD di tipo 1. Aggiorna i dati della tabella per assicurarsi che vengano caricati i valori più recenti.

ScD di tipo 2

Un tipo 2scD 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 utilizzare una chiave surrogata 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 venditori a un'area di vendita. Quando un venditore riloca l'area, è necessario creare una nuova versione del venditore per garantire che i fatti cronologici rimangano associati all'area precedente. Per supportare un'analisi cronologica accurata delle vendite da parte del venditore, la tabella delle dimensioni deve archiviare le versioni dei venditori e le aree associate. La tabella deve includere anche valori di data di inizio e di fine per definire la validità dell'ora. Le versioni correnti possono definire una data di fine vuota (o 31/31/9999), che indica che la riga è la versione corrente. La tabella deve anche definire una chiave surrogata perché la chiave business (in questa istanza, ID dipendente) non sarà univoca.

È importante comprendere che quando i dati di origine non archivia le versioni, è necessario usare un sistema intermedio (ad esempio un data warehouse) per rilevare e archiviare le modifiche. Il processo di caricamento delle tabelle deve mantenere i dati esistenti e rilevare le modifiche. Quando viene rilevata una modifica, il processo di caricamento della tabella deve scadere per la versione corrente. Registra queste modifiche aggiornando il valore EndDate e inserendo una nuova versione con il valore StartDate che inizia dal valore EndDate precedente. Inoltre, i fatti correlati devono utilizzare una ricerca basata sul tempo per recuperare il valore della chiave della dimensione rilevante per la data dei fatti. Un modello di Power BI che usa Power Query non può produrre questo risultato. Tuttavia, può caricare dati da una tabella delle dimensioni di tipo 2 precaricata.

Il modello 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 versione specifica del venditore.

Per ottenere questo requisito, la tabella del tipo di dimensione del modello 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 della versione fornisca una descrizione non ambigua, ad esempio "Michael Blythe (15/12/2008-06/26/2019)" o "Michael Blythe (current)". È anche importante informare gli autori e i consumer dei report sulle nozioni di base di SCD Type 2 e su come ottenere progettazioni di report appropriate applicando filtri corretti.

È anche consigliabile includere una gerarchia che consente agli oggetti visivi di eseguire il drill-down al livello di versione.

Dimensioni con ruoli multipli

Una dimensione con ruoli è una dimensione in grado di filtrare i fatti correlati in modo diverso. In Adventure Works, ad esempio, la tabella delle dimensioni ha tre relazioni con i fatti di vendita del 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 dalla colonna dei fatti usata per unire le tabelle. Ad esempio, quando si analizzano le vendite in base alla data dell'ordine, il join di tabella è correlato alla colonna data ordine vendita rivenditore.

In un modello di Power BI, questa progettazione può essere imitata creando più relazioni tra due tabelle. Nell'esempio Adventure Works le tabelle di vendita di data e rivenditore avranno tre relazioni. Anche se questa progettazione è possibile, è importante comprendere che può esistere una sola relazione attiva tra due tabelle del modello di Power BI. Tutte le relazioni rimanenti devono essere impostate su inattive. La presenza di una singola relazione attiva significa che esiste una propagazione del filtro predefinita da data a vendite rivenditore. In questo caso, la relazione attiva viene impostata sul filtro più comune utilizzato 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 U edizione Standard RELATIONSHIP. In questo esempio, lo sviluppatore di modelli deve creare misure per abilitare l'analisi delle vendite dei rivenditori in base alla data di spedizione e alla data di consegna. Questo lavoro può essere noioso, soprattutto quando la tabella reseller definisce molte misure. Crea anche confusione nel riquadro Campi , con una sovrabbondanza di misure. Esistono anche altre limitazioni:

• Quando gli autori di report si basano sul riepilogo delle colonne, anziché definire 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 attiva tra le vendite di data e rivenditore, non è possibile filtrare simultaneamente le vendite dei rivenditori in base a diversi tipi di date. Ad esempio, non è possibile produrre un oggetto visivo che traccia le vendite della 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 di tipo dimensione per ogni istanza di ruolo. In genere, le tabelle delle dimensioni aggiuntive vengono create come tabelle calcolate usando DAX. Usando le tabelle calcolate, il modello può contenere una tabella Date , una tabella Ship Date e una tabella Delivery Date , ognuna con una relazione singola e attiva con le rispettive colonne della tabella sales reseller.

Questo approccio di progettazione non richiede la definizione di più misure per ruoli di data diversi e consente il filtro simultaneo in base a ruoli di data diversi. Un prezzo minore da pagare, tuttavia, con questo approccio di progettazione è che ci sarà duplicazione della tabella delle dimensioni data con conseguente aumento delle dimensioni del modello. Poiché le tabelle di tipo dimensione in genere archiviano meno righe rispetto alle tabelle di tipo fatto, raramente si tratta di un problema.

Quando si creano tabelle di tipo dimensione del modello per ogni ruolo, osservare le procedure di progettazione consigliate seguenti:

• Assicurarsi che i nomi delle colonne siano autodescrittura. Anche se è possibile avere una colonna Year 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 tabella Ship Date abbia una colonna year denominata Ship Year e così via.
• Quando pertinente, assicurarsi che le descrizioni delle tabelle forniscano commenti e suggerimenti agli autori di report (tramite descrizioni comando del riquadro Campi ) 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 di tipo fatto. 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 "Filtra le vendite rivenditore per data ordine".

Per altre informazioni, vedere Linee guida sulle relazioni attive e inattive.

Dimensioni indesiderate

Una dimensione indesiderata è utile quando sono presenti molte dimensioni, soprattutto costituite da pochi attributi (ad esempio uno) e quando questi attributi hanno pochi valori. I candidati validi includono colonne relative allo stato dell'ordine o colonne demografiche dei clienti (sesso, fascia di età e così via).

L'obiettivo di progettazione di una dimensione indesiderata consiste nel consolidare molte dimensioni "piccole" in una singola dimensione per ridurre le dimensioni di archiviazione del modello e ridurre anche la confusione del riquadro Campi 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. La chiave surrogata fornisce un riferimento univoco a ogni riga della tabella. È possibile compilare la dimensione in un data warehouse o tramite Power Query per creare una query che esegue join di query full outer, quindi aggiunge una chiave surrogata (colonna di indice).

Questa query viene caricata nel modello come tabella di tipo dimensione. È anche necessario unire questa query con la query dei fatti, quindi la colonna di indice viene 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, il numero dell'ordine di vendita rivenditore è un buon esempio. In questo caso, non ha senso progettare un modello efficace per creare una tabella indipendente costituita da una sola colonna, perché aumenterebbe le dimensioni di archiviazione del modello e genera un disordine nel riquadro Campi .

Nel modello di Power BI può essere opportuno aggiungere la colonna numero ordine di vendita alla tabella di tipo fatto 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 tipi di tabella (in genere le tabelle del modello devono essere di tipo dimensione o di tipo fact).

Tuttavia, se la tabella delle vendite dei rivenditori Adventure Works include colonne numero ordine e numero di riga dell'ordine e sono necessari per filtrare, una tabella delle dimensioni degenerata sarebbe una buona progettazione. Per altre informazioni, vedere Linee guida per le relazioni uno-a-uno (Dimensioni degenerate).

Tabelle dei fatti senza fatti

Una tabella dei fatti senza fatti non include colonne di misura. Contiene solo chiavi di dimensione.

Una tabella dei fatti senza fatti potrebbe archiviare le osservazioni definite dalle chiavi delle dimensioni. Ad esempio, in una determinata data e ora, un determinato 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 effettuato l'accesso.

Un uso più interessante di una tabella dei fatti senza fatti consiste nell'archiviare le relazioni tra le dimensioni ed è l'approccio di progettazione del modello di Power BI che è consigliabile definire relazioni tra dimensioni molti-a-molti. In una progettazione di relazioni tra dimensioni molti-a-molti, la tabella dei fatti senza fatti viene definita tabella di bridging.

Si consideri ad esempio che i venditori possono essere assegnati a una o più aree di vendita. La tabella di bridging verrebbe progettata come 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 molti-a-molti è ben documentato e può essere ottenuto senza una tabella di bridging. Tuttavia, l'approccio alla tabella bridging viene considerato la procedura consigliata per la correlazione di 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 di Power BI, vedere gli articoli seguenti:

• Articolo di Wikipedia sulla modellazione dimensionale
• Creare e gestire le relazioni in Power BI Desktop
• Linee guida per le relazioni uno-a-uno
• Linee guida per le relazioni molti-a-molti
• Linee guida per le relazioni bidirezionali
• Linee guida sulle relazioni attive e inattive
• Domande? Contattare la community di Power BI
• inviare suggerimenti, Contribuire con idee per migliorare Power BI