Condividi tramite

Linee guida per relazioni uno-a-uno

  • Articolo

Questo articolo è destinato a un modellatore di dati che lavora con Power BI Desktop. Offre linee guida per l'uso di relazioni di modelli uno-a-uno. È possibile creare una relazione uno-a-uno quando entrambe le tabelle contengono ognuna una colonna di valori comuni e univoci.

Nota

Questo articolo non fornisce un'introduzione alle relazioni nei modelli. Se non si ha familiarità con le relazioni, le relative proprietà o le modalità di configurazione, è consigliabile leggere per prima cosa l'articolo Relazioni nei modelli in Power BI Desktop.

È anche importante avere una conoscenza di base della progettazione dello schema star. Per altre informazioni, vedere Informazioni su uno schema star e sull'importanza di questo schema per Power BI.

Esistono due scenari che prevedono relazioni uno-a-uno:

  • Le dimensioni degenerate: è possibile derivare una dimensione degenerata da una tabella dei fatti .

  • i dati di riga si estendono su tabelle: un'unica entità aziendale o soggetto viene caricata come due o più tabelle del modello, probabilmente perché i dati provengono da diversi archivi dati. Questo scenario può essere comune per le tabelle delle dimensioni . I dettagli master dei prodotti, ad esempio, possono essere archiviati in un sistema di vendita operativo e i dettagli supplementari dei prodotti possono essere archiviati in un'origine diversa.

    Tuttavia, è insolito correlare due tabelle dei fatti con una relazione uno-a-uno. Questo perché entrambe le tabelle dei fatti devono avere la stessa dimensionalità e granularità. Inoltre, ogni tabella dei fatti richiede colonne univoce per consentire la creazione della relazione del modello.

Dimensioni degenerate

Quando le colonne di una tabella dei fatti vengono usate per filtrare o raggruppare, è possibile valutarne la disponibilità in una tabella separata. In questo modo, si separano le colonne usate per filtrare o raggruppare le colonne usate per riepilogare le righe dei fatti. Questa separazione consente di:

  • Ridurre lo spazio di archiviazione.
  • Semplificare i calcoli del modello.
  • Contribuire a migliorare le prestazioni delle query.
  • Offrire agli autori di report un'esperienza del riquadro dati più intuitiva.

Si consideri una tabella di origine denominata Sales che archivia i dettagli di riferimento della riga degli ordini di vendita in due colonne.

Schema che mostra le righe della tabella della dimensione degenere delle vendite. La progettazione è descritta nel paragrafo seguente.

La colonna OrderNumber archivia il numero di ordine e la colonna OrderLineNumber archivia una sequenza di righe all'interno dell'ordine.

Nell'immagine seguente, si noti che le colonne relative al numero d'ordine e al numero di riga dell'ordine non sono state caricate nella tabella Sales. I valori sono stati invece usati per creare una chiave surrogata colonna denominata OrderLineNumberID. Il valore della chiave viene calcolato moltiplicando il numero di ordine per 1000 e aggiungendo quindi il numero di riga dell'ordine.

Diagramma che mostra due tabelle: Sales e Sales Order. Una relazione uno-a-uno è correlata alle colonne Order Line Number ID .

La tabella delle dimensioni Sales Order offre un'esperienza completa per gli autori di report con due colonne: Sales Order e Sales Order Line. Queste colonne specifiche supportano progetti di report che devono filtrare, raggruppare o approfondire tra ordini e righe di ordine.

Poiché la tabella Sales Order deriva dai dati delle vendite, deve essere presente esattamente lo stesso numero di righe in ogni tabella. Devono inoltre essere presenti valori corrispondenti tra ogni colonna OrderLineNumberID.

Estensione dei dati delle righe su più tabelle

Si consideri un esempio che include due tabelle delle dimensioni correlate uno a uno: Product e Product Category. Ogni tabella rappresenta i dati importati e dispone di una colonna SKU (unità di mantenimento delle scorte) che contiene valori univoci.

Di seguito è riportato un diagramma di modello parziale delle due tabelle.

Diagramma che mostra un modello contenente due tabelle in cui i dati di riga si estendono su più tabelle. La progettazione è descritta nel paragrafo seguente.

La prima tabella è denominata Producte contiene tre colonne: Color, Producte SKU. La seconda tabella è denominata Product Categorye contiene due colonne: Category e SKU. Una relazione uno-a-uno collega le due colonne SKU. La relazione applica un filtro in entrambe le direzioni, come avviene sempre per le relazioni uno-a-uno.

Per descrivere il funzionamento della propagazione del filtro delle relazioni, l'immagine seguente rivela alcune righe di tabella. Tutti gli esempi in questo articolo si basano su questi dati.

Diagramma che mostra le tabelle Prodotto e Categoria prodotto e alcune righe di dati. I dettagli delle righe sono descritti nel paragrafo seguente.

I dettagli delle righe per le due tabelle sono descritti nell'elenco puntato seguente:

  • La tabella Product ha tre righe:
    • SKU CL-01, ProductT-shirt, ColorVerde
    • SKU CL-02, ProductJeans, ColorBlue
    • SKU AC-01, ProductCappello, ColorBlu
  • La tabella Product Category ha due righe:
    • SKU CL-01, CategoryAbbigliamento
    • SKU AC-01, CategoryAccessori

Si noti che la tabella Product Category non include una riga per lo SKU del prodotto CL-02. Le conseguenze della mancanza di questa riga verranno illustrate più avanti in questo articolo.

Nel riquadro dei dati , gli autori del report trovano i campi correlati al prodotto in due tabelle: Product e Product Category. Si vedrà ora cosa accade quando i campi di entrambe le tabelle vengono aggiunti a un oggetto visivo tabella. In questo esempio la colonna SKU viene originata dalla tabella Product.

Diagramma che mostra il riquadro Dati con due tabelle e un oggetto visivo tabella che include quattro colonne. Il valore Category per lo SKU prodotto CL-02 è BLANK.

Si noti che il valore Category per lo SKU del prodotto CL-02 è BLANK. Questo perché non esiste alcuna riga corrispondente nella tabella Product Category per questo prodotto.

Consigli

Se possibile, è consigliabile evitare di creare relazioni di modelli uno-a-uno quando i dati delle righe si estendono su più tabelle del modello. Ciò è dovuto al fatto che questa progettazione può:

  • Contribuire al riquadro Dati in modo disordinato, elencando più tabelle del necessario.
  • Rendere difficile per gli autori di report trovare i campi correlati, perché vengono distribuiti in più tabelle.
  • Limitare la possibilità di creare gerarchie, in quanto i relativi livelli devono essere basati su colonne della stessa tabella.
  • Genera risultati imprevisti quando non esiste una corrispondenza completa delle righe tra le tabelle.

I consigli specifici possono variare a seconda che la relazione uno-a-uno sia all'interno del gruppo di origine o tra gruppi di origine. Per ulteriori informazioni sulla valutazione delle relazioni, vedere Relazioni tra i modelli in Power BI Desktop.

Relazione uno-a-uno all'interno del gruppo di origine

Se tra le tabelle esiste una relazione uno-a-uno all'interno del gruppo di origine, è consigliabile consolidare i dati in un'unica tabella del modello. A tale scopo, è possibile unire le query di Power Query.

I passaggi seguenti presentano una metodologia per consolidare e modellare i dati correlati uno a uno.

  1. Combinare le query: quando si combinano le due query, prestare attenzione alla completezza dei dati in ognuna. Se una query contiene un set di righe completo (come un elenco master), unire l'altra query. Impostare la trasformazione unione per usare un left outer join, ovvero il tipo di join predefinito. Questo tipo di join garantisce il mantenimento di tutte le righe della prima query e l'integrazione di queste con le righe corrispondenti della seconda query. Espandere tutte le colonne obbligatorie della seconda query nella prima query.

    Diagramma che mostra i dati consolidati in una singola tabella dimensione prodotto.

  2. Disabilitare il caricamento delle query: assicurarsi di disabilitare il caricamento della seconda query. In questo modo, il risultato non verrà caricato come tabella del modello. Questa configurazione riduce le dimensioni di archiviazione del modello di dati e semplifica l'includazione del riquadro Dati .

    Nel nostro esempio, gli autori di report trovano ora una singola tabella denominata nel riquadro dati . con tutti i campi relativi ai prodotti.

  3. Sostituire i valori mancanti: se la seconda query contiene righe non corrispondenti, i valori Null vengono visualizzati nelle colonne introdotte. Se appropriato, valutare la possibilità di sostituire i valori Null con un valore del token. La sostituzione dei valori mancanti è particolarmente importante nel caso in cui gli autori di report filtrino o raggruppino in base ai valori delle colonne, dato che negli oggetti visivi dei report potrebbero comparire valori vuoti.

    Nell'immagine seguente si noti che la categoria per lo SKU di prodotto CL-02 ora legge [Non definito]. Nella query, infatti, le categorie Null sono state sostituite con questo valore di testo di token.

    Diagramma che mostra il riquadro Dati per la tabella Prodotto. Mostra anche una tabella visiva con quattro colonne. Il valore categoria per lo SKU prodotto CL-02 è ora etichettato Non definito.

  4. Creare gerarchie: se esistono relazioni tra le colonne della tabella ora consolidata, prendere in considerazione la possibilità di creare gerarchie. In questo modo, gli autori di report potranno identificare rapidamente le opportunità di drill-down sugli oggetti visivi dei report.

    In questo esempio gli autori di report possono ora usare una gerarchia con due livelli: Category e Product.

    Diagramma che visualizza il riquadro Dati. La tabella Products include la gerarchia Products.

Anche se si preferisce mantenere tabelle separate per facilitare l'organizzazione dei campi, è comunque consigliabile eseguire il consolidamento in un'unica tabella. Organizzare i campi è ancora possibile, usando cartelle di visualizzazione.

Nell'esempio gli autori di report possono trovare il campo Category all'interno della cartella di visualizzazione Marketing.

Diagramma che mostra il riquadro Dati in cui il campo Categoria si trova all'interno di una cartella di visualizzazione denominata Marketing.

Se si decide comunque di definire relazioni uno-a-uno all'interno del gruppo di origine nel modello, verificare, quando possibile, assicurarsi che siano presenti righe corrispondenti nelle tabelle correlate. Poiché una relazione uno-a-uno all'interno del gruppo di origine viene valutata come relazione regolare, possono emergere problemi di integrità dei dati negli oggetti visivi dei report in forma di righe vuote. È possibile vedere un esempio di raggruppamento vuoto nel primo oggetto visivo tabella presentato in questo articolo.

Relazione uno-a-uno tra gruppi di origine

Quando esiste una gruppo tra origini relazione tra tabelle, non esiste una progettazione di modelli alternativa, a meno che non si pre-consolidano i dati nell'origine dati. Power BI valuterà la relazione di modello uno-a-uno come relazione limitata. Di conseguenza, prestare attenzione a assicurarsi che siano presenti righe corrispondenti nelle tabelle correlate, perché le righe senza corrispondenza vengono eliminate dai risultati della query.

Diagramma che mostra una relazione uno-a-uno tra gruppi di origine, ovvero una relazione limitata.

Si vedrà ora cosa accade quando a un oggetto visivo tabella vengono aggiunti campi da entrambe le tabelle ed esiste una relazione limitata tra le tabelle.

Diagramma che mostra due oggetti visivi di tabella, descritti nel paragrafo seguente.

La prima visualizzazione di tabella, che utilizza una relazione tra gruppi di fonti, visualizza solo due righe. Lo SKU del prodotto CL-02 non è presente perché nella tabella Product Category non è presente alcuna riga corrispondente. Basata su una singola tabella consolidata nel modello, la seconda visualizzazione a tabella visualizza tre righe.

Contenuto correlato

Per altre informazioni correlate a questo articolo, vedere le risorse seguenti: