Gestire più tabelle dei fatti in uno stesso dataset di Power BI (o modello Tabular di Analysis Services)

Un problema che mi capita sempre più spesso di dover affrontare coi clienti durante un progetto di Business Intelligence è quello di dover gestire più fact table in uno stesso modello d’analisi, che sia esso un modello Tabular in Analysis Services o un dataset di Power BI. Il dubbio del cliente è: come metto in relazione due (o più) tabelle dei fatti? Questa piccola guida nasce proprio per rispondere a questa diffusa domanda quindi, di seguito, andremo a presentare brevemente alcuni possibili metodi di risoluzione. I metodi di risoluzione sono tutti da applicare già in fase di disegno, e verranno elencati anche i relativi punti di forza e le debolezze riscontrati anche nell’esperienza personale.

Premetto subito che, per le soluzioni che darò di seguito, i due strumenti (modelli Tabular e dataset di Power BI) possono definirsi equivalenti fra loro, e d’ora in poi mi riferirò a loro semplicemente come modelli.

Il primo metodo che consiglio è la messa in relazione di due (o più) fatti tramite tutte le dimensioni che hanno in comune. In questo modo, sono le dimensioni che si occupano di filtrare i fatti secondo lo stesso perimetro d’analisi. Questo metodo permette ai modellatori di disegnare le tabelle in modo indipendente fra loro, scegliendo anche due granularità differenti, se necessarie: in questo caso, le tecnologie di SQL Server non introducono alcun errore di duplicazione delle misure, come invece faceva in passato altri competitor. Consiglio sempre questo metodo perché non obbliga un ridisegno delle tabelle nel modello. È scontato che possano esserci delle dimensioni legate ad uno solo dei due fatti.

Un secondo metodo che suggerisco è quello di modellare più fatti in un’unica tabella, accodando i record e prevedendo una colonna come scenario, ossia un attributo che identifichi quale fatto (evento di business) sia insito in ogni record. La difficoltà di questa soluzione è disegnare una tabella che possa comodamente ospitare differenti fatti, che presumibilmente saranno caratterizzati da differenti dettagli ed attributi. Spesso, infatti, capita che a plasmare la struttura della tabella sia il “principale” fra i fatti, e gli altri completino lo schema con valori riempitivi (dummy) per le colonne che, funzionalmente parlando, non li caratterizzano.

A differenza del metodo precedente, qui non si aggiungono righe alla tabella, ma bensì colonne. Infatti, la soluzione sta nel disegnare una tabella che modelli l’intero processo end-to-end, e non solo una parte di esso. Idealmente, leggendo le colonne della tabella da sinistra a destra, si dovrebbero attraversare tutte le fasi del processo. Questa soluzione è decisamente più complessa perché spinge a modellare i differenti fatti con la stessa identica cardinalità, in modo da riuscire ad appiattirli nella stessa tabella senza duplicazioni. Altrimenti, la duplicazione può essere accettata in SQL, ma dovrà poi essere gestita correttamente in DAX, effort aggiuntivo che solitamente si tende ad evitare.

Un metodo che non suggerisco – ma che può funzionare – è quello di prevedere più schemi a stella nello stesso modello. Come potete intuire, qui ovviamente si perde la relazione fra i fatti, ma la si sostituisce inserendo delle dimensioni degenerate che permettano di filtrare un fatto sulla base di un altro. Questo ultimo aspetto non è però affatto scontato; per questo motivo difficilmente consiglio questa soluzione. Inoltre, infrange la regola che in un modello debba esserci un unico schema; schemi indipendenti fra loro dovrebbero infatti stare in modelli differenti. Questo però va contro il vincolo odierno di poter collegare uno ed un solo modello al report (documento) di Power BI, vincolo che spesso gli utenti finali faticano ad accettare, trovando scomodo dover aprire più documenti per analizzare modelli funzionalmente in relazione fra loro.

Quello della bridge table è un metodo che presento sempre perché storicamente accettato, ma che sconsiglio per i suoi difetti, puramente tecnici. Precede la creazione di una tabella che associ le chiavi primarie delle due tabelle dei fatti; messa in relazione bidirezionale quindi coi due fatti, farà sì che un fatto filtri l’altro. Se implementato correttamente, il metodo funziona agli occhi dell’utente finale. Tecnicamente, però, non è una soluzione ottimale perché pesante dal punto di vista computazionale, e pecca anche di eleganza.

L’unica situazione in cui è accettabile creare una relazione diretta fra due tabelle dei fatti, è quella in cui esse siano in relazione 1:1 od 1:N fra loro. Questo è uno scenario raro – ma comunque possibile – e solitamente dipende più da come si è deciso di modellare i fatti, piuttosto che da come funziona il business. Anche qui come nella prima soluzione, le tecnologie di Microsoft SQL Server ci vengono in aiuto e fanno sì che non vi siano errori di duplicazione delle misure.

Per quella che è la mia esperienza ad oggi, questi sei sono i metodi di più diffuso utilizzo, ma è lecito pensare che possano esserci ben altre soluzioni a questo quesito. Non c’è una soluzione universalmente corretta: dipende sempre da cosa l’utente ha bisogno di fare e da come l’azienda è abituata a condurre le proprie analisi (presupposto che il metodo sia corretto). Per questo il mio consiglio è sempre lo stesso: parlare cogli utenti, capire come funziona il business e come loro lavorano, e condurre con quanta più precisione possibile l’analisi dei requisiti. Cambiare una soluzione in corso d’opera può essere costoso e coinvolgere anche i processi a monte, come ad esempio l’ETL.

di Thomas Tolio, pubblicato il 29 dicembre 2021