Amazon Quick Sight introduce le Multi-Dataset Relationships, una capability che cambia il modo di modellare i dati per la BI: invece di pre-appiattire tutte le tabelle in un unico dataset denormalizzato, si tengono le tabelle come dataset separati e si dichiarano le relazioni all’interno di un Quick Sight Topic. I join vengono poi eseguiti a runtime, solo quando un visual, un campo calcolato, un filtro o una domanda in linguaggio naturale richiede colonne da più dataset.
Il vantaggio non è estetico. Il modello a singolo dataset ha tre costi ricorrenti: preparazione a monte (bisogna decidere la forma dei join prima di conoscere tutte le domande), duplicazione delle misure quando si uniscono grani diversi, e proliferazione di dataset dedicati a ogni scenario. Il modello basato su relazioni affronta tutti e tre: si modella una volta, ogni tabella resta al suo grano nativo, e il motore porta dentro solo ciò che serve.
Due livelli da tenere distinti
La chiave è capire i due layer. Il livello fisico vive dentro un dataset: qui si uniscono tabelle con lo stesso grano tramite join, union, SQL e trasformazioni. Il livello logico vive nel Topic: ogni dataset è una tabella logica e le relazioni le tengono distinte, combinandole solo a runtime. Da notare un limite dell’attuale release: le relazioni usano semantica di inner join, quindi servono chiavi corrispondenti in entrambi i dataset perché una riga compaia.
Le best practice che contano
Le raccomandazioni sono classiche di dimensional modeling, applicate al nuovo strumento. Partire da uno star schema (una fact table centrale con le dimensioni attorno) resta il default consigliato; snowflake e galaxy/constellation servono per casi specifici. Sulle chiavi: usare surrogate key intere, verificare che i tipi dato combacino su entrambi i lati, rimuovere i null dalle colonne chiave (nell’inner join non fanno match) e validare l’integrità referenziale. Va gestito con attenzione anche il grano: dimensioni condivise tra più fact devono avere un grano conforme.
Un ultimo punto utile per chi punta sull’interfaccia conversazionale: arricchire i metadati — descrizioni dei campi, sinonimi (Revenue → Sales, Income), tipi semantici, istruzioni custom — migliora sensibilmente l’accuratezza del Q&A in linguaggio naturale. La regola pratica, secondo il framework di scelta proposto, è chiara: sotto le 5 tabelle con una sola fact conviene ancora il dataset pre-joinato; con più analisti che interrogano fact diverse, o con esplorazione via chat, meglio le relazioni multi-dataset.
In sintesi
- Le Multi-Dataset Relationships fanno join a runtime tra dataset separati, evitando l’appiattimento anticipato e la duplicazione delle misure.
- Distinguere il livello fisico (dentro il dataset) da quello logico (nel Topic); la release attuale supporta solo inner join.
- Star schema come default, chiavi surrogate pulite e metadati ricchi per un Q&A affidabile.
Fonte: Data modeling best practices for Amazon Quick Sight multi-dataset relationships — https://aws.amazon.com/blogs/machine-learning/data-modeling-best-practices-for-amazon-quick-sight-multi-dataset-relationships/
Hai qualcosa da aggiungere? Unisciti alla discussione.