Relazioni tra dashboard

Le relazioni nelle dashboard consentono di modellare la logica di join tra i dataset nelle dashboard AI/BI, in modo da poter creare modelli di dati con più fatti e più granularità e misure riutilizzabili tra diversi dataset senza dover prima unire i dati in SQL. La relazione viene modellata una sola volta e quindi usata in ogni visualizzazione nel dashboard.

Quali problemi risolvono le relazioni?

Prima delle relazioni, un autore che voleva unire le metriche da più tabelle dei fatti (ad esempio, orders.revenue e shipments.cost), raggruppate in base all'area, doveva pre-unire entrambe le tabelle dei fatti alla dimensione dell'area e aggregare attentamente per evitare il fan-out, la duplicazione delle righe che si verifica quando un join moltiplica le righe anziché associarle uno a uno. Tale logica di join viveva in SQL, duplicata in ogni set di dati che lo richiedeva.

Con le relazioni, l'autore definisce il join una sola volta. Il motore di query decide cosa aggiungere in fase di esecuzione, in base ai campi nella visualizzazione. Non esiste alcun fan-out, conteggio doppio o SQL duplicato.

Come funzionano le relazioni tra dashboard?

È possibile definire una relazione tra due dataset del dashboard scegliendo un campo di collegamento in ciascuno di essi e impostando la cardinalità, ad esempio molti a uno da una tabella dei fatti a una tabella di dimensione. I set di dati correlati formano quindi un grafico attraversabile e il motore di query risolve i join necessari per ogni visualizzazione in fase di query, quindi i filtri e le misure passano attraverso i set di dati connessi senza pre-join dei dati in SQL.

Un modello può estendersi su diverse tabelle dei fatti che convergono su dimensioni condivise e una dimensione può ramificarsi ulteriormente in altre dimensioni. La figura 1 mostra un modello con tre tabelle dei fatti collegate tramite quattro dimensioni condivise, due delle quali si diramano ulteriormente di un livello.

Figura 1. Un modello relazionale del dashboard comprende più tabelle dei fatti collegate tramite dimensioni condivise, con alcune dimensioni normalizzate secondo uno schema a fiocco di neve di un ulteriore livello. Anche una dimensione innevata come Geography rimane raggiungibile da ogni tabella dei fatti connessa.

Per creare relazioni e misure tra set di dati, vedere Creare relazioni tra dashboard.

Quali modelli di dati sono supportati?

Le relazioni del dashboard eseguono join in fase di query tra tabelle in base alla cardinalità specificata della relazione. È possibile unire tabelle dei fatti tramite una dimensione conforme (una dimensione condivisa da più tabelle dei fatti), ma non direttamente tra loro tramite join di tipo molti-a-molti.

La tabella seguente descrive i modelli supportati e non supportati e come risolvere i modelli non supportati quando si verificano:

Come si risolvono percorsi di join ambigui e ciclici?

L'aliasing funziona perché ogni copia con alias di una tabella è un nodo distinto nel grafico, quindi ogni percorso di join conduce esattamente a una destinazione. I due modelli non supportati creano un tipo diverso di percorso duplicato e l'aliasing lo rimuove.

Un percorso di join ambiguo si verifica quando una tabella dei fatti può raggiungere la stessa dimensione attraverso più di un percorso. Ad esempio, Orders raggiunge Country sia attraverso Regions sia attraverso Customers, quindi una query che raggruppa gli ordini per paese ha due possibili join e nessun modo per scegliere tra i due. Per risolverlo, aliasare la dimensione una volta per ogni route, ad esempio Country (region) e Country (customer). Ogni percorso punta quindi alla rispettiva copia, perciò un campo come il paese del cliente corrisponde a un unico percorso.

Figura 2. Assegnare un alias alla dimensione condivisa fornisce a ogni percorso una destinazione specifica, così il percorso di join non è ambiguo.

Una relazione ciclica è un anello chiuso di join. Se Orders è unito a Regions, Regions è unito a Customers e Customers si ricollega a Orders, il ciclo non offre al motore di query alcun punto non ambiguo da cui iniziare o in cui fermarsi, quindi non può risolvere i join. Per risolvere il problema, assegna un alias a una tabella all’interno del ciclo in modo da spezzarlo e ottenere un unico percorso che il motore di query possa seguire dall’inizio alla fine. Nella figura 3, A, B e C rappresentano tre tabelle qualsiasi in un ciclo di questo tipo e A′ è l'alias che lo interrompe.

Figura 3. Assegnare un alias a una tabella nel ciclo spezza il ciclo in un unico percorso attraversabile.

Come funzionano le misure tra set di dati?

Quando le tabelle dei fatti condividono una dimensione conformata, è possibile definire una misura una sola volta a livello di modello e fare in modo che attinga a più di una tabella dei fatti. Il motore di query aggrega ogni tabella dei fatti in modo indipendente e combina i risultati nella dimensione condivisa, pertanto la misura rimane corretta indipendentemente dai campi aggiunti da un visualizzatore alla visualizzazione.

Ad esempio, con Orders, Shipmentse Returns uniti tramite dimensioni condivise, è possibile definire misure tra set di dati come queste a livello di modello:

Net Revenue      = SUM(Orders.revenue) - SUM(Returns.refund)
Fulfillment Rate = SUM(Shipments.units) / SUM(Orders.units)
Return Rate      = SUM(Returns.units) / SUM(Orders.units)

Ciascuna di queste utilizza contemporaneamente due tabelle di fatti, senza espansione delle righe o doppio conteggio. La figura 1 mostra le dimensioni condivise su cui si basa, in cui tre tabelle dei fatti corrispondono a quattro dimensioni conformi.

Perché l'ordine dei campi è importante

Il primo campo aggiunto imposta la radice, la tabella in cui viene risolto ogni altro campo. Da tale radice, tre tipi di campi si comportano in modo diverso:

Quindi, partendo da orders revenue, sono disponibili sia customer region sia shipments cost, ma non ship mode: una colonna grezza su Shipments, non raggiungibile perché Shipments non è la radice. Inizia invece da ship mode e la radice si inverte, quindi ora sono disponibili anche le colonne di Shipments.

In che modo le relazioni del dashboard vengono confrontate con le visualizzazioni delle metriche?

Entrambi possono modellare lo stesso grafico join, ma risolvono problemi diversi:

• Le visualizzazioni delle metriche sono a granularità fissa. È possibile eseguire query direttamente con SQL e sono adatti agli schemi star e snowflake.
• Le relazioni del dashboard sono a granularità dinamica. Consentono di combinare e associare campi e misure da qualsiasi tabella all'interno del grafico semantico, in modo che siano più adatti per la modellazione in più tabelle dei fatti.

Un grafico delle relazioni del dashboard può includere visualizzazioni delle metriche come nodi, con relazioni come archi che le connettono. La visualizzazione delle metriche gestisce la logica a granularità singola e le relazioni gestiscono il livello a più fatti nella parte superiore.

Se si inizia con una relazione dashboard e in un secondo momento è necessario lo stesso modello regolato e condiviso, è possibile alzarlo di livello a una visualizzazione delle metriche. Vedi le viste metriche di Unity Catalog e Esporta in una vista metrica di Unity Catalog. Per un confronto più ampio di tutte le opzioni di modellazione dei dati disponibili nei dashboard di intelligenza artificiale/BI, vedere Scegliere l'approccio corretto.

Qual è la differenza tra granularità fissa e granularità dinamica?

La granularità influisce sui campi che è possibile selezionare e sulla granularità in base alla quale sono espressi. Una visualizzazione delle metriche blocca una tabella a una granularità fissa, ad esempio a livello di cliente, mentre le relazioni sono dinamiche, in base ai campi usati nel dashboard, ad esempio a livello di cliente, ordine o spedizione.

La differenza scende alla radice. Una vista metrica incorpora la radice nella dimensione in fase di definizione: Customer è sempre la radice, quindi ogni query raggruppa per Customer e il selettore dei campi offre solo Customer come campo di raggruppamento, anche se continua comunque a prelevare le misure da qualsiasi tabella dei fatti connessa. Le relazioni del dashboard scelgono invece la radice per query: Orders o Shipments possono fungere da radice, a seconda del campo aggiunto per primo, quindi la selezione campi consente di raggruppare in base a una qualsiasi delle tabelle connesse anziché solo alla dimensione.

Figura 4. La radice è fissa in una visualizzazione delle metriche, ma scelta per ogni query in una relazione del dashboard.

Nonostante questa differenza, entrambi condividono lo stesso limite sottostante: non è comunque possibile raggruppare direttamente una misura della tabella dei fatti in base alla colonna di un'altra tabella dei fatti, perché i due si incontrano solo nella dimensione condivisa.

Perché le relazioni tra dashboard sono limitate a un dashboard?

Il supporto delle relazioni in Unity Catalog è in fase di sviluppo.

Risorse aggiuntive

• Creare relazioni tra dashboard
• Modellazione dei dati nei dashboard di intelligenza artificiale/BI
• Visualizzazioni delle metriche locali
• Visualizzazioni delle metriche del catalogo Unity