Snowflake o no snowflake, questo è il problema...

Si discute di come il modello relazionale basato sul snowflake schema non sia, in generale, lo schema più adatto a un DW, si riporta comunque un esempio per il quale lo snowflaking delle dimensioni è opportuno.

Quando si giunge alla modellazione logica di tipo relazionale per realizzare la visione multidimensionale dei dati in oggetto, lo schema di maggiore successo ed efficienza è generalmente rappresentato dallo star schema (schema a stella), in soldoni lo star schema (SC) propone una tabella centrale (tabella dei fatti - FT) che determina l'oggetto dello studio e fornisce le singole transazioni analizzabili (fatti)  e tante relazioni di appoggio, dette tabelle dimensionali  (DT) , quante sono gli "oggetti di business" di analisi.

Le caratteristiche principali delle tabelle sono:

- Le chiavi delle DT sono surrogati
- Ogni DT contiene, oltre alla chiave, un attributo per ciascun attributo dimensionale o non dimensionale della gerarchia corrispondente.
- La chiave della FT è composta dalle chiavi importate dalle varie DT.
- La FT contiene, oltre alla chiave, un attributo per ciascuna misura.

Il modello rappresenta la naturale visione dei dati per le attività di tipo analitico ed è particolarmente leggibile vista la presenza di uniche join tra le tabelle dei fatti e le dimensioni.
Dal punto di vista maggiormente orientato all'engine database la presenza di un unico livello di join e una corretta indicizzazione (di tipo bitmap index) delle foreign key della tabella dei fatti è generalmente garanzia di alte prestazioni nel querying.

Generalmente, appunto...

Vorrei analizzare quelli che sono stati indicati come alcuni limiti per il modello SC  e su questi fare qualche piccola considerazione :
-limite :  l'utilizzo dello SC aumenta la dimensione delle tabelle
-considerazione : rispetto a cosa ? ai sistemi OLTP o  ad altri modelli normalizzati OLAP ? spesso questo limite non viene specificato, o sopravvalutato, oggi grossi sistemi DW gestiscono centinaia o migliaia di gigabytes, personalmente non lo considererei come un reale limite (nel contesto di un certo tipo di progetto DW)
-limite : La Fact Table contiene tuple relative a diversi livelli di aggregazione
-considerazione : L'espressione artistica massima nel disegno di un SC passa proprio per la capacità di organizzare in modo chiaro tutta l'informazione necessaria all'analisi, la definizione di attributi gerarchici di una dimensione di analisi costruiti sulla decodifica di un campo indicizzato nella tabella dei fatti, rappresenta, a mio avviso, l'espressione massima di chiarezza nel disegno, non mi preoccupo di quali differenze sono ospitate nella stessa FT, ma della bassa complessità nella definizione degli attributi di analisi relativamente ai diversi dati aggregati presenti.
-limite : L’elevata dimensione della Fact Table incide sui tempi di accesso
-considerazione : Le FT sono sempre di elevata dimensione; l'attività di aggregazione, appunto, e l'uso sapiente dell'indicizzazione possono (in concerto con i potenti tools di oggi in grado di accedere in autonomia ad aggregazioni predefinite) risolvere qualunque tipologia di problema, inoltre, ripeto, le dimensioni di un DW non possono che essere spesso mostruose, è la costituzione di datamart aggregati che permette performance analitiche di valore.
Questo il breve elenco dei limiti principali che è possibile recuperare in diversi articoli, dal mio punto di vista è assente quello che rappresenta un vero, fastidioso limite.

Ossia: spesso le DT raggiungono notevoli dimensioni (pensiamo alla dimensione Cliente di una catena di supermercati, i singoli clienti potrebbero essere centinaia di migliaia o milioni), in questo caso lo SC può presentare qualche problema, soprattutto nel caso di dimensioni che hanno importanti attributi gerarchici a bassa cardinalità.

Facciamo un esempio :
Nella dimensione prodotto (formata da 300,000 records) sono presenti numerosissimi attributi (diciamo 100 campi di tipo descrittivo), da un punto di vista business, esiste in questa dimensione il concetto di Linea di prodotto che raggruppa una serie di articoli prodotto (che rappresentano la granularità minima e quindi il concetto di singolo prodotto), poniamo il caso che le linee prodotto siano 50 per i 300,000 articoli.

Cosa succede se il concetto di linea di prodotto è accompagnata da una serie di informazioni aggiuntive (ospitate per esempio da 20 campi nella dimensione) relative proprio alla linea di prodotto e non all'articolo ?

Beh,  la bassa cardinalità del tipo di prodotto causerebbe nella denormalizzazione un'impressionante ridondanza di dati e i 20 campi descrittivi relativi al tipo di prodotto contribuirebbero (oltre che alla ridondanza) ad un possibile massiccio aumento di dimensioni che potrebbe influire negativamente sulle prestazioni rispetto ad un rinormalizzazione snowflake (non preoccupiamoci delle dimensioni, ma delle prestazioni).

Quella descritta risulta a mi avviso l'unica situazione che rende utile la rinormalizzazione snowflake, molte altre situazioni riportate dalla letteratura sui presunti pregi dello snowflaking sono state risolte grazie a diverse notevoli features che molti motori db mettono a disposizione (come i recenti indici bitmap).

Privacy Policy