Quando un report impiega minuti per rispondere a una domanda semplice, il problema spesso non è il dashboard, ma il modo in cui sono organizzati i dati. Lo schema a stella è un modello per data warehouse che collega una tabella centrale di fatti a dimensioni descrittive, rendendo più semplici analisi, filtri e aggregazioni. Vediamo come funziona, come progettarlo, quali vantaggi offre e quando conviene preferirlo ad alternative più normalizzate.
Una struttura pensata per analisi rapide e leggibili
- Tabella dei fatti al centro, con eventi, misure e chiavi di collegamento.
- Tabelle delle dimensioni intorno, con dati descrittivi come prodotto, cliente, negozio e data.
- La granularità stabilisce che cosa rappresenta ogni riga e previene errori nei calcoli.
- Il modello è adatto a BI, report e dashboard che devono filtrare e aggregare grandi volumi.
- Rispetto al fiocco di neve, offre query più semplici ma può duplicare alcuni attributi.
La struttura che mette i fatti al centro
In un modello dimensionale, la tabella dei fatti raccoglie gli eventi che vogliamo misurare. Può contenere vendite, ordini, accessi a un sito, spedizioni, consumi energetici o ticket di assistenza. Intorno si trovano le dimensioni, cioè le informazioni che aiutano a leggere quei fatti, come tempo, prodotto, cliente e area geografica.
La forma ricorda una stella perché una tabella centrale è collegata direttamente a più tabelle laterali. Le dimensioni contengono soprattutto attributi testuali e categoriali, mentre la tabella dei fatti contiene chiavi esterne e misure numeriche, per esempio quantità, ricavi, costi o margini.
| Elemento | Contenuto | Domanda a cui risponde |
|---|---|---|
| Tabella dei fatti | Eventi, misure, chiavi | Quanto è stato venduto? |
| Dimensione prodotto | Nome, categoria, marca | Che cosa è stato venduto? |
| Dimensione cliente | Segmento, città, canale | A chi è stato venduto? |
| Dimensione data | Giorno, mese, trimestre, anno | Quando è avvenuta la vendita? |
La distinzione più importante non riguarda il numero di colonne, ma il significato di ogni riga. Se una riga rappresenta una singola riga d’ordine, non bisogna inserire nella stessa tabella anche dati aggregati per mese. Una granularità confusa produce totali duplicati, anche quando le relazioni sembrano corrette.
Come progettare il modello senza creare confusione
Io inizio sempre dal processo aziendale, non dalle tabelle già disponibili nei sistemi operativi. Prima chiarisco che cosa deve essere analizzato e con quale livello di dettaglio. Solo dopo scelgo colonne, chiavi e relazioni.
1. Definisci il processo e la granularità
Una frase precisa è già una buona base progettuale. Per esempio, “una riga per ogni prodotto presente in un ordine” è molto più utile di “tabella delle vendite”. Da questa scelta dipendono il numero di righe, il significato delle misure e il modo in cui verranno calcolati gli indicatori.
La granularità può essere giornaliera, transazionale, mensile o legata a uno snapshot. Per le vendite operative, una granularità transazionale offre maggiore dettaglio; per una fotografia giornaliera delle scorte, invece, ogni riga può rappresentare prodotto, magazzino e data.
2. Separa fatti, dimensioni e misure
Le misure descrivono ciò che può essere aggregato. Ricavi e quantità sono generalmente additivi, mentre una percentuale di margine non va sommata riga per riga. In quel caso è più sicuro conservare numeratore e denominatore, calcolando il rapporto nel livello semantico o nella query.
Le dimensioni devono contenere gli attributi usati per filtrare, raggruppare e navigare nei dati. Una dimensione prodotto può includere categoria, sottocategoria, marca e fascia di prezzo, anche se questi attributi sono ripetuti per più prodotti. Questa denormalizzazione controllata semplifica l’uso da parte degli analisti.
3. Usa chiavi coerenti e relazioni semplici
Ogni dimensione dovrebbe avere una chiave stabile, spesso una chiave surrogata numerica. La tabella dei fatti conserva quella chiave invece di dipendere direttamente dall’identificativo del sistema sorgente. Questo aiuta a gestire cambi di codice, fusioni di anagrafiche e versioni storiche.
La relazione più comune è uno-a-molti. Una riga della dimensione prodotto può essere collegata a molte righe della tabella dei fatti, ma ogni fatto dovrebbe puntare a una sola versione coerente del prodotto. Per questo preferisco relazioni chiare e unidirezionali, soprattutto nei modelli usati da strumenti di business intelligence.
Leggi anche: Relazione molti a molti - tabella ponte e query SQL
4. Trasforma i dati prima del livello analitico
Le sorgenti possono arrivare in formato CSV, JSON, XML, Excel o tramite API e database transazionali. Il formato di partenza non determina la forma finale del modello: durante i processi ETL o ELT i dati vengono puliti, uniformati e caricati in tabelle relazionali adatte all’analisi.
In questa fase conviene standardizzare date, valute, unità di misura e valori mancanti. Un ricavo espresso in euro in una fonte e in centesimi in un’altra può compromettere ogni dashboard. La qualità del modello dipende almeno quanto dalla qualità della trasformazione.
Un esempio concreto con vendite e prodotti
Immaginiamo un retailer che voglia analizzare ricavi e quantità vendute. La tabella centrale potrebbe chiamarsi fact_vendite e avere una riga per ogni prodotto presente in un ordine.
| Tabella | Colonne principali | Ruolo nell’analisi |
|---|---|---|
| fact_vendite | data_key, prodotto_key, cliente_key, negozio_key, quantità, ricavo | Misura gli eventi di vendita |
| dim_prodotto | prodotto_key, codice, nome, marca, categoria | Permette analisi per assortimento |
| dim_cliente | cliente_key, segmento, città, canale | Permette analisi per pubblico |
| dim_negozio | negozio_key, città, regione, formato | Confronta punti vendita e territori |
| dim_data | data_key, giorno, mese, trimestre, anno | Supporta filtri temporali e confronti |
Con questa struttura, una domanda come “quali categorie hanno generato più ricavi nel Nord Italia nel secondo trimestre?” richiede pochi collegamenti logici. Si filtra la dimensione geografica e quella temporale, si raggruppa per categoria e si somma la misura del ricavo.
Il punto delicato è evitare il doppio conteggio. Se un ordine contiene tre prodotti, il suo costo di spedizione non può essere copiato integralmente su tutte e tre le righe senza una regola di ripartizione. In casi simili bisogna decidere se conservare il costo a livello di ordine, distribuirlo per riga oppure creare una seconda tabella dei fatti con una granularità diversa.
Perché questo modello funziona bene nella business intelligence
Il vantaggio più evidente è la leggibilità. Un analista può riconoscere rapidamente la tabella dei fatti e le dimensioni disponibili, senza attraversare molte relazioni gerarchiche. Questo riduce gli errori nella costruzione di report e rende più facile spiegare il modello a chi non lavora ogni giorno con SQL.
Anche le query tendono a essere più dirette. Le dimensioni si collegano normalmente alla tabella centrale con un solo join, mentre i filtri vengono applicati su colonne descrittive già pronte. Nei motori analitici moderni, questa forma può favorire compressione, scansioni efficienti e tempi di risposta più prevedibili.
Non considero però il modello a stella una soluzione magica. Se le tabelle contengono dati duplicati, chiavi incoerenti o misure mal definite, la struttura rimane facile da leggere ma continua a produrre risultati sbagliati. Le prestazioni dipendono anche dal motore utilizzato, dai volumi, dagli indici, dal partizionamento e dalla qualità delle query.
Il modello si adatta bene a Power BI, Tableau, Looker e ad altri strumenti di analytics, soprattutto quando il livello semantico deve offrire metriche comprensibili agli utenti. Per volumi molto elevati può essere utile partizionare la tabella dei fatti per data e predisporre aggregazioni, ma questa è una scelta tecnica da valutare dopo aver definito correttamente la granularità.
Quando scegliere il fiocco di neve invece della stella
Il modello a fiocco di neve normalizza una parte delle dimensioni, dividendo per esempio la dimensione prodotto in tabelle separate per prodotto, marca e categoria. Si riduce la duplicazione, ma aumentano i collegamenti necessari per raggiungere l’informazione finale.
| Criterio | Modello a stella | Modello a fiocco di neve |
|---|---|---|
| Semplicità | Alta, struttura più intuitiva | Inferiore, più livelli relazionali |
| Ridondanza | Possibile nelle dimensioni | Generalmente più contenuta |
| Query BI | Più brevi e facili da governare | Più join e maggiore complessità |
| Manutenzione gerarchie | Rapida per modelli semplici | Utile per gerarchie molto articolate |
| Uso consigliato | Dashboard e data mart analitici | Gerarchie condivise e scenari con forte esigenza di normalizzazione |
La scelta non è sempre assoluta. In molti progetti il livello d’integrazione può essere più normalizzato, mentre il data mart destinato ai report viene pubblicato con dimensioni più piatte. Io preferisco questa soluzione ibrida quando servono sia governance dei dati sia un’esperienza semplice per chi costruisce analisi.
Se una categoria viene modificata raramente e il modello deve essere usato da molti analisti, la semplicità della stella spesso vale più dello spazio risparmiato. Se invece le gerarchie sono numerose, condivise e soggette ad aggiornamenti frequenti, una struttura più normalizzata può ridurre il lavoro di manutenzione.
Gli errori che compromettono il modello
La maggior parte dei problemi nasce da decisioni apparentemente piccole prese all’inizio del progetto. Prima di pubblicare il modello, controllo soprattutto questi punti:
- Granularità non dichiarata. Se non è chiaro che cosa rappresenta una riga, ogni misura può diventare ambigua.
- Dimensioni collegate tra loro. Un modello analitico con molte relazioni dimensione-dimensione è spesso più difficile da filtrare e mantenere.
- Misure già aggregate. Inserire totali mensili accanto a dati giornalieri può generare somme gonfiate.
- Uso diretto delle chiavi sorgente. I codici dei sistemi operativi possono cambiare e non gestiscono bene la storia.
- Date trattate come semplice testo. Senza una dimensione calendario si complicano confronti tra mesi, trimestri, festività e giorni lavorativi.
- Valori mancanti lasciati senza regola. Un prodotto o un cliente sconosciuto dovrebbe confluire in una chiave tecnica documentata, non sparire dai report.
Un altro errore frequente consiste nel modellare soltanto ciò che è già presente nel file sorgente. Il data warehouse dovrebbe riflettere le domande del business, non la comodità dell’estrazione. Prima definisco gli indicatori e il loro significato, poi verifico quali dati servono per calcolarli in modo affidabile.
La regola pratica per decidere se adottarlo
Se il tuo obiettivo è analizzare eventi attraverso tempo, prodotto, cliente, canale o territorio, partire da un modello a stella è spesso una scelta solida. Offre un compromesso efficace tra prestazioni, comprensibilità e facilità d’uso, soprattutto nei data mart destinati a report e dashboard.
Prima di adottarlo, verifica tre condizioni: una granularità esplicita, misure definite con formule condivise e dimensioni con chiavi e attributi affidabili. Se questi elementi sono presenti, la struttura può diventare una base ordinata per SQL, strumenti BI e modelli semantici, anche quando i dati originali provengono da file e sistemi molto diversi.
La forma conta, ma conta ancora di più il significato delle righe. Un modello semplice con regole chiare produce analisi migliori di una struttura sofisticata che nessuno riesce a interpretare.
