Schema a stella vs schema a fiocco di neve: differenze e casi d’uso

Cos’è uno schema a fiocco di neve?

Uno schema a fiocco di neve è un altro modo di organizzare i dati. In questo schema, le tabelle delle dimensioni sono suddivise in sotto-dimensioni più piccole per mantenere i dati più ordinati e dettagliati — proprio come i fiocchi di neve in un grande lago. 

Schema a fiocco di neve. Immagine dell’autore.

Vediamo le caratteristiche chiave dello schema a fiocco di neve che lo differenziano dagli altri schemi:

• Tabelle delle dimensioni multilivello: Possiamo suddividere le tabelle delle dimensioni in tabelle più piccole e specifiche. Per esempio, se voglio tracciare le sedi dei negozi, invece di mettere tutti i dettagli in un’unica grande tabella, posso separare in tabelle per Paesi, Stati/Regioni e Città. In questo modo, ogni tabella contiene solo le informazioni necessarie, riducendo la ridondanza e migliorando l’organizzazione.
• Normalizzazione per l’efficienza di archiviazione: A differenza dello schema a stella, lo schema a fiocco di neve segue un design normalizzato, che evita la duplicazione dei dati. Per esempio, invece di ripetere una categoria di prodotto come Electronics per ogni prodotto, posso archiviare la categoria in una tabella separata e collegarla ai singoli prodotti.
• Idoneità per ambienti dati complessi: lo schema a fiocco di neve funziona al meglio in ambienti complessi perché usa tabelle multilivello per gestire relazioni intricate e strutture gerarchiche dei dati.

Comprendiamolo con un semplice diagramma a fiocco di neve. Al centro c’è la tabella dei fatti, che contiene dati misurabili. Si collega a tabelle delle dimensioni che descrivono i fatti, e queste tabelle si diramano ulteriormente in sotto-dimensioni, formando una struttura simile a un fiocco di neve. 

Per esempio, qui ho suddiviso la tabella Product in Manufacturer e Category e la tabella Customer in Transaction e Location :

Esempio di schema a fiocco di neve. Immagine dell’autore.

Ecco un esempio SQL che illustra uno schema a fiocco di neve in cui la tabella Product è ulteriormente normalizzata nelle tabelle Category e Manufacturer:

-- Fact table remains the same
CREATE TABLE Sales (
    Sales_ID INT PRIMARY KEY,
    Product_ID INT,
    Customer_ID INT,
    Date_ID INT,
    Sales_Amount DECIMAL(10, 2),
    FOREIGN KEY (Product_ID) REFERENCES Products(Product_ID),
    FOREIGN KEY (Customer_ID) REFERENCES Customers(Customer_ID),
    FOREIGN KEY (Date_ID) REFERENCES Dates(Date_ID)
);

-- Dimension table: Product
CREATE TABLE Product (
    Product_ID INT PRIMARY KEY,
    Product_Name VARCHAR(100),
    Category_ID INT,
    Manufacturer_ID INT,
    FOREIGN KEY (Category_ID) REFERENCES Category(Category_ID),
    FOREIGN KEY (Manufacturer_ID) REFERENCES Manufacturer(Manufacturer_ID)
);

-- Sub-dimension table: Category
CREATE TABLE Category (
    Category_ID INT PRIMARY KEY,
    Category_Name VARCHAR(50)
);

-- Sub-dimension table: Manufacturer
CREATE TABLE Manufacturer (
    Manufacturer_ID INT PRIMARY KEY,
    Manufacturer_Name VARCHAR(100)
);

La query seguente calcola le vendite totali per categoria di prodotto. Anche se comporta più join rispetto allo schema a stella, è più efficiente in termini di spazio:

SELECT cat.Category_Name, SUM(s.Sales_Amount) AS TotalSales
FROM Sales s
JOIN Product p ON s.Product_ID = p.Product_ID
JOIN Category cat ON p.Category_ID = cat.Category_ID
GROUP BY cat.Category_Name;

Vantaggi e limiti di uno schema a fiocco di neve

Come lo schema a stella, anche lo schema a fiocco di neve ha i suoi vantaggi. Vediamo quali sono:

• Meno ridondanza dei dati: La normalizzazione assicura che gli stessi dati non vengano archiviati più volte, riducendo la duplicazione.
• Archiviazione efficiente per dataset di grandi dimensioni: Questo schema risparmia spazio evitando dati ripetuti, rendendolo ideale per gestire grandi volumi di dati.

Tuttavia, nonostante i suoi vantaggi, ci sono anche alcuni limiti. Per esempio, le query possono essere più lente perché ci sono più join tra tabelle. Oltre a questo, la struttura multilivello è più impegnativa da progettare e mantenere rispetto a schemi più semplici come quello a stella. Quindi, scegliilo solo se hai un team di DBA esperto.

Ti consiglio di dare un’occhiata al corso Database Design se vuoi approfondire come strutturare i dati in modo efficiente per l’analisi. 

Usare un approccio ibrido

Nei progetti reali è comune usare entrambi i pattern in livelli diversi per combinare i punti di forza di entrambi gli approcci:

• Mantieni strutture più normalizzate (a fiocco di neve) nel livello di warehouse per coerenza e manutenzione semplificata
• Pubblica data mart a stella o viste denormalizzate per BI e reportistica

Questo consente ai team di bilanciare integrità e governance dei dati con un consumo analitico rapido e semplice.

Schema a stella vs schema a fiocco di neve

Sia gli schemi a stella che quelli a fiocco di neve sono ampiamente usati nel data warehousing, ma le loro caratteristiche uniche li rendono adatti a esigenze diverse. Vediamo come differiscono per struttura, prestazioni, requisiti di archiviazione e casi d’uso.

Struttura

In uno schema a stella, tutte le tabelle delle dimensioni si collegano direttamente a un’unica tabella dei fatti centrale. Ciò significa che tutti i tuoi dati di riferimento sono a un solo passo dai dati principali, rendendo il tutto facile da comprendere e usare.

In confronto, uno schema a fiocco di neve suddivide le tabelle delle dimensioni in sotto-dimensioni più piccole e specifiche. Per esempio, puoi avere tabelle separate per Paesi, Stati/Regioni e Città invece di un’unica tabella delle località. Anche se questo crea una struttura più ordinata e dettagliata, implica anche più collegamenti (o join) per accedere ai dati — uno dei motivi principali per cui lo schema a fiocco di neve è più complesso di quello a stella.

Prestazioni

In termini di velocità, gli schemi a stella sono spesso migliori. Poiché tutte le tabelle delle dimensioni si collegano direttamente alla tabella dei fatti, le query richiedono di solito meno join, con prestazioni più rapide. Supponiamo che tu voglia analizzare le vendite per regione — in questo caso, puoi usare lo schema a stella per recuperare i dati con elaborazione minima.

Al contrario, gli schemi a fiocco di neve sono spesso più lenti perché devi passare attraverso più tabelle per recuperare i dati. Ogni join aggiunge tempo di elaborazione, rendendo gli schemi a fiocco di neve meno efficienti per attività che richiedono risultati rapidi.

Il corso Joining Data in SQL è un’ottima introduzione per imparare a unire le tabelle, applicare la teoria degli insiemi relazionali e lavorare con le subquery.

Requisiti di archiviazione

Gli schemi a stella occupano più spazio di archiviazione perché memorizzano informazioni ridondanti nelle tabelle delle dimensioni. Ad esempio, se più prodotti appartengono alla stessa categoria, il nome della categoria si ripeterà per ogni prodotto, aumentando le esigenze di spazio.

Gli schemi a fiocco di neve, invece, normalizzano i dati per archiviare ogni informazione una sola volta. Per esempio, invece di ripetere i nomi delle categorie, questi sono archiviati in una tabella separata e collegati alla tabella dei prodotti tramite chiavi esterne. Questo design risparmia spazio, rendendolo ideale per dataset di grandi dimensioni.

Casi d’uso

Gli schemi a stella sono ideali per i sistemi di online analytical processing (OLAP), la reportistica e le attività di business intelligence. La loro semplicità li rende perfetti per scenari in cui contano velocità e facilità d’uso, come la creazione di dashboard rapidi o report di vendita.

Gli schemi a fiocco di neve sono spesso usati per l’analisi finanziaria o i sistemi di customer relationship management (CRM). In questi casi sono più importanti l’organizzazione di gerarchie dettagliate e il risparmio di spazio che la velocità delle query.

Tabella di confronto

Ecco un rapido confronto tra schema a stella e schema a fiocco di neve per aiutarti a decidere quale si adatta meglio alle tue esigenze. Ho evidenziato le differenze principali in questa tabella, concentrandomi su struttura, prestazioni, archiviazione e casi d’uso:

Scegliere lo schema giusto

Quando usare uno schema a stella

Se il tuo obiettivo principale è organizzare i dati in modo semplice e rapido, lo schema a stella è perfetto. Ecco quando usarlo:

• Se stai costruendo un modello semantico per strumenti BI (ad esempio, Power BI) e vuoi un numero ridotto di tabelle e relazioni. Supporta filtri/raggruppamenti intuitivi e in genere offre buone prestazioni per le visualizzazioni interattive.
• Se vuoi eseguire query semplici come trovare le vendite totali per regione, usa uno schema a stella. Poiché tutte le tabelle delle dimensioni si collegano direttamente alla tabella dei fatti, eviti complessità inutili e ottieni risposte più rapidamente.
• Puoi usare uno schema a stella anche quando la velocità è la tua priorità. Riduce al minimo il numero di join tra tabelle, quindi le query sono più rapide. L’ho usato una volta per generare diversi report di vendita, risparmiando molto tempo rispetto ad altri design.
• Se il tuo dataset è piccolo o medio, la ridondanza dello schema a stella non sarà un problema. Anche con dati ripetuti, funziona bene senza sovraccaricare l’archiviazione.

Quando usare uno schema a fiocco di neve

Lo schema a fiocco di neve è più adatto a rappresentare gerarchie e dati di riferimento condivisi, soprattutto quando molti attributi di dimensione si ripetono su molte righe. Ecco quando puoi usarlo:

• Quando le tue dimensioni hanno gerarchie chiare (per esempio, Paese → Stato/Regione → Città) e vuoi modellare questi livelli in modo pulito come tabelle separate.​
• Se vuoi un controllo più rigoroso dei dati di riferimento condivisi (per esempio, elenchi standard come categorie, produttori o aree geografiche) per ridurre la duplicazione e mantenere coerenti le definizioni in tutto il warehouse.
• Puoi usare lo schema a fiocco di neve anche se i tuoi dati cambiano spesso, ad esempio aggiornando i nomi delle regioni. Mantiene aggiornamenti coerenti in tutti i dati correlati, riducendo errori e sforzi di manutenzione.
• Se la tua analisi coinvolge più livelli di dati, lo schema a fiocco di neve può aiutarti a organizzare e rappresentare queste relazioni in modo semplice.

Selezione dello schema nei data warehouse cloud

In molti moderni data warehouse cloud, lo storage è relativamente economico rispetto al compute. Ciò significa che il “maggiore spazio” dovuto alle dimensioni denormalizzate è spesso meno importante del costo di calcolo per scansione e join dei dati.

Quando scegli tra stella e fiocco di neve, considera il modello di pricing della tua piattaforma (compute vs storage), la concorrenza delle query e se puoi usare caching/vista materializzate per mantenere bassi i costi delle query.

Considerazioni finali

In questo blog ho trattato le differenze tra schema a stella e schema a fiocco di neve, i loro punti di forza e quando usare ciascuno. Spero che ora tu abbia un’idea chiara e suggerimenti pratici per il tuo lavoro! Se vuoi saperne di più, dai un’occhiata a queste risorse su DataCamp:

• Il corso Introduction to Data Modeling in Snowflake ti aiuterà a costruire le basi per lavorare con Snowflake. 
• Il corso Data Modeling in Power BI per organizzare e gestire i dati in Power BI.
• Il percorso di competenze Associate Data Engineer in  SQL per portare le tue abilità SQL al livello successivo.