Dimensioni condivise nella semantica di Tableau

Tabelle correlate e non correlate

Un ulteriore concetto chiave nelle tabelle condivise è la differenza tra tabelle correlate e non correlate.

Due tabelle sono considerate correlate quando sono collegate direttamente da una relazione definita. Le query tra tabelle correlate funzionano come previsto: il sistema utilizza il percorso definito per unirle.

Se due tabelle non sono completamente correlate, ovvero non hanno alcuna connessione diretta o condivisa, il sistema non è in grado di determinare come combinare i loro dati e la query avrà esito negativo.

In alcuni casi, le tabelle sono collegate solo tramite una dimensione condivisa. Se si eseguono query sui campi di entrambe le tabelle Fatto senza includere un campo della tabella condivisa e i campi non vengono aggregati, il sistema esegue un join incrociato. Ciò significa che ogni riga di una tabella dei fatti viene combinata con ogni riga dell'altra, poiché non esiste una chiave condivisa per allinearle.

Ad esempio, se Vendite e Marketing sono entrambi collegati a una tabella Prodotti condivisa e si esegue una query su [Vendite].[Quantità vendite] e [Marketing].[Spendere] senza [Prodotti].[Nome prodotto], il sistema combinerà semplicemente tutte le righe Vendite con tutte le righe Marketing.

Per evitare questo problema, la query deve includere un campo della tabella condivisa, ad esempio Prodotto o Data, che funge da chiave di join e fornisce un asse condiviso per raggruppare e aggregare i valori nei due fatti.

Le dimensioni condivise consentono di analizzare i dati di tabelle che altrimenti sarebbero isolate, ma solo se utilizzate correttamente all'interno della query.

Alberi Fatti e loro struttura

Un albero dei fatti è un gruppo di tabelle che appartengono alla stessa area aziendale e sono collegate tra loro. Di solito include una o più tabelle dei fatti insieme alle tabelle delle dimensioni.

Questa struttura non è solo un concetto di modellazione: è qualcosa che il sistema crea automaticamente quando si esegue una query. Gli alberi Fatto sono il modo in cui il livello semantico organizza internamente le tabelle per valutare correttamente le dimensioni condivise.

Nel diagramma di esempio sopra, Marketing è una tabella Fatto collegata alle tabelle condivise Prodotti e Date. Questo forma il suo albero dei fatti. Sales è un'altra tabella dei fatti che si collega alle stesse dimensioni condivise, formando un albero dei fatti separato. Questa struttura consente al sistema di capire in che modo ogni albero funziona in modo indipendente, abilitando comunque l'analisi incrociata degli alberi attraverso dimensioni condivise.

Gli alberi Fatto devono rimanere privi di cicli. I cicli introducono ambiguità: se il sistema può raggiungere la stessa tabella attraverso più di un percorso, potrebbe non sapere quale seguire o come applicare correttamente filtri e aggregazioni. Per questo motivo, la creazione di una nuova relazione che introduce un ciclo, ad esempio la connessione di Marketing direttamente alla sottocategoria (che è già raggiungibile tramite Prodotto), non è consentita.

In che modo le dimensioni condivise influiscono sulle query

Le dimensioni condivise non solo aiutano a strutturare il modello semantico, ma determinano anche il comportamento delle query in fase di esecuzione, garantendo risultati precisi e una logica coerente.

Si supponga di analizzare in che modo la Spesa di marketing è correlata alla Quantità di vendita. Queste due misure provengono da tabelle di fatto diverse: Marketing e Vendite. Da soli, non possono essere allineati in modo significativo perché non esiste un contesto condiviso in base al quale raggrupparli. Se si trascinano entrambi i campi in una query senza utilizzare un riferimento condiviso, il sistema non può trovare corrispondenze tra le righe e potrebbe restituire risultati fuorvianti o addirittura non riuscire.

Tuttavia, una volta introdotte due dimensioni condivise, ad esempio Prodotto e Data, la situazione cambia. Con queste opzioni è possibile chiedere: "Per ogni prodotto e mese, quanto abbiamo speso per il marketing e quante unità sono state vendute?"

Poiché Vendite e Marketing sono entrambi collegati a Prodotti e Date (tabelle condivise), il sistema può ora allineare correttamente entrambe le misure -- per prodotto, per mese -- e restituire risultati aggregati significativi:

Comportamento dei filtri

I filtri vengono applicati in modo da evitare di modificare i dati di tabelle non correlate.

• Quando si applica un filtro a un campo specifico dei fatti, ad esempio Tipo di marketing, viene filtrata solo la tabella dei fatti, non qualsiasi altro fatto o dimensione condivisa.
• Quando si applica un filtro a una dimensione condivisa, ad esempio Nome prodotto o Data, si applica a tutte le tabelle Fatto a essa collegate.

Questo comportamento impedisce ai filtri di rimuovere i record non correlati. Ad esempio, se si seleziona Online nel filtro Tipo di marketing, viene aggiornata solo la Spesa di marketing -- Quantità di vendita rimane invariata.

Gli alberi Fatto devono rimanere privi di cicli. I cicli introducono ambiguità: se il sistema può raggiungere la stessa tabella attraverso più di un percorso, potrebbe non sapere quale seguire o come applicare correttamente filtri e aggregazioni. Per questo motivo, la creazione di una nuova relazione che introduce un ciclo, ad esempio la connessione di Marketing direttamente alla sottocategoria (che è già raggiungibile tramite Prodotto), non è consentita.

Campi calcolati e contenimento dell'albero Fatto

I campi calcolati devono rispettare i confini dell'albero dei fatti. Se si crea un campo calcolato a livello di riga, ad esempio:

IF [Support].[Priorità] <= 1 THEN "High" ELSE "Low"

-- quel campo è valido finché rimane nello stesso albero dei fatti (supporto in questo caso). È possibile utilizzarlo per analizzare gli schemi o filtrare l'attività correlata all'assistenza in base a dimensioni come Cliente o Prodotto (se tali dimensioni sono condivise) e tutto si comporterà come previsto.

Tuttavia, se si tenta di creare un campo calcolato che si estende su più tabelle Fatto, ad esempio:

[Inventario].[Quantità] + [Vendite].[Quantità vendite]

-- la piattaforma genera un errore. Tenta di combinare i dati a livello di riga di due diversi alberi Fatto e il sistema non è in grado di risolvere un livello di dettaglio comune per quell'espressione. Ogni albero dei fatti ha la propria granularità indipendente e il proprio contesto di filtro.

Per ottenere calcoli incrociati validi, è necessario aggregare ogni fatto in modo indipendente e quindi combinare tali aggregazioni a livello di visualizzazione:

SUM([Inventory].[Quantity]) + SUM([Sales].[Sales Quantity])

Questa espressione è consentita perché entrambe le misure vengono aggregate prima di essere combinate e l'aggregazione è limitata al livello di prodotto o a qualsiasi dimensione si trovi nella visualizzazione.

Limitazioni delle dimensioni condivise e degli alberi Fatto

• Le tabelle Fatto devono rimanere disconnesse tra loro. Non possono essere uniti direttamente. Qualsiasi collegamento tra di loro deve avvenire solo tramite tabelle di dimensioni condivise.
• I campi calcolati a livello di riga, siano essi dimensioni o misure, devono essere completamente contenuti in un unico albero dei fatti.
• Non è possibile collegare una tabella condivisa a un'altra tabella condivisa e quindi a una tabella Fatto. In altre parole, nel percorso di connessione tra una tabella Fatto e le sue dimensioni può esistere una sola tabella condivisa. Ad esempio, se Prodotti è una tabella condivisa collegata a Date (un'altra tabella condivisa) e quindi entrambe si connettono a Vendite, questa struttura non è supportata.
• Quando si filtrano i campi di più alberi Fatto nella stessa query, tali filtri devono essere combinati utilizzando una condizione AND, non OR.