Le dimensioni di analisi sono le componenti fondamentali per definire gli spazi analitici all’interno di un Data Warehouse. L’obiettivo è quello di analizzare in dettaglio il loro design e la loro implementazione

1. Note di Data Warehouse
Le Dimensioni di analisi
Le dimensioni di analisi sono le componenti
fondamentali per definire gli spazi analitici
all’interno di un Data Warehouse. L’obiettivo di
questo articolo è quello di analizzare in dettaglio il
loro design e la loro implementazione.

2. Introduzione
• In ambito Data Warehouse e Business Intelligence, le dimensioni di analisi sono sicuramente un
asse portante del contenuto informativo. Su di esse state date, nel tempo, varie definizioni più o
meno tecniche. Inizierei con una definizione dal sapore vagamente “astronomico” tratta dal libro
di William Giovinazzo [1].
• In principio è la stella. I punti della stella sono le dimensioni, cioè le persone, i fatti e le cose
collegate al business. Le dimensioni sono le chiavi di accesso ai fatti contenuti nel nucleo centrale
della stella.
• Per meglio comprendere le dimensioni di analisi all’interno di un Data Warehouse, dobbiamo
pensare a una divisione strettamente dicotomica della realtà informativa. Da una parte i numeri,
dall’altra parte i nomi. Da una parte i valori quantitativi presenti nelle tabelle dei fatti, dall’altra
parte i valori qualitativi presenti nelle tabelle dimensionali. Non possono esistere disgiunti. Un
fatto, per esempio l’estrazione di 10.000 litri di petrolio, non ha alcuna valenza analitica se non è
correlato ad una sua dimensionalità che mi deve dire, al minimo, dove sono stati estratti i 10.000
litri, di che tipo di olio erano e quando sono stati estratti.
• I valori descrittivi che costituiscono le dimensioni di analisi, definiscono quindi le singole quantità
associate ai fatti, detti anche eventi transazionali. Altri esempi di tali valori sono il nome cliente, il
tipo di volo aereo, il codice e la descrizione di un prodotto di vendita, l’indirizzo del fornitore, ecc.
Quanto descritto ha una solida base concettuale nel dimensional model di cui si faranno alcuni
cenni nel prossimo paragrafo.

3. Il modello dimensionale (1)
• Il modello dimensionale è il risultato dell’applicazione di una tecnica di design che cerca di
rappresentare i dati in una forma intuitiva garantendo, al contempo, un accesso altamente
prestazionale. Tale disciplina, a differenza dei classici modelli entity-relationship tipici dei sistemi
OLTP, tende a ridurre al minimo il numero di join fra le varie tabelle organizzando i dati in una
tabella centrale, la fact table, collegata a un insieme di tabelle più piccole chiamate dimension
table. Lo schema così ottenuto si definisce star- schema e nei moderni Data Warehouse è la
struttura fondamentale per l’analisi dei dati.
• Non è scopo di questo articolo delineare le relazioni fra i due modelli e gli step necessari per
passare da un modello all’altro: per un approfondimento vi rimando alla lettura del Kimball [2].
• Sottolineo solamente i seguenti punti di forza del modello dimensionale:
– Attenersi scrupolosamente ai principi della modellazione dimensionale e organizzare sempre
il vostro mondo informativo in star-schema. Tutti i moderni tool di analisi e reportistica
(Business Objects, Oracle Business Intelligence, Cognos, Microstrategy, ecc. ) riconoscono e
trattano al meglio queste strutture.
– Cambiamenti e arricchimenti nelle necessità di analisi e nel contenuto dei dati sono
realizzabili in modo molto semplice, dal punto di vista strutturale, con in genere dei comandi
SQL del tipo “ALTER TABLE…”.

4. Il modello dimensionale (2)
• Ogni struttura aggregata che viene creata è a sua volta strutturata a star-schema. Se non si è
adottato il modello dimensionale, le funzionalità di rewrite degli statement SQL che permette agli
RDBMS come Oracle di accedere alle tabelle aggregate invece che alle tabelle di base, avranno
difficoltà a funzionare.
A questo punto abbiamo gli elementi introduttivi per entrare nel dettaglio delle dimensioni di analisi.
Faremo un semplice esempio relativo al mondo della grande distribuzione organizzata (GDO) che,
storicamente, è stato il primo a recepire e utilizzare le tecniche di Data Warehousing.

5. La dimensione del punto di vendita (1)
• Iniziamo ad associare alla fact table delle vendite di un prodotto di consumo, DDW_DM0_SLS_FAT
la sua prima dimensione di analisi, cioè quella dei punti di vendita del prodotto. Per chi è
interessato, la Naming Convention applicata agli oggetti è stata descritta sul mio blog [3].
• Il nome della fact table indica in modo facilmente intuitivo, che questa struttura informativa è una
Fact table (FAT) delle vendite (SLS) che fa parte dei Data Mart di livello base (DM0) di un progetto
di Data warehouse (DDW).
• Basandosi sulla stessa tecnica, il nome della dimensione di analisi potrebbe essere
DDW_COM_CDI_POS_DIT, a indicare la tabella dimensionale (DIT) dei punti di vendita (POS) che fa
parte della sezione delle conformed dimension (CDI) dell’area comune (COM) del progetto di Data
Warehouse (DDW).
• Un fatto presente nel Data Mart delle vendite, per esempio la vendita di 5 prodotti, sarà associato
al luogo, cioè al punto di vendita, in cui sono state venduti. Sulla base delle analisi richieste dalla
reportistica e del contenuto del sistema che alimenterà questo tipo d’informazione, possiamo
ipotizzare che saranno utili i seguenti elementi descrittivi del punto vendita:
– Codice e descrizione del punto di vendita
– Superficie del punto di vendita in mq.
– Tipo del punto di vendita (per es. chiosco, negozio, libreria, ecc.)
– Posizione del punto di vendita (piazza, via, interno di centro commerciale, autogrill, ecc.)

6. La dimensione del punto di vendita (2)
– Codice del quartiere in cui è situato il punto di vendita
– Descrizione del quartiere in cui è situato il punto di vendita
– Tipo del quartiere (centro, periferia, ecc.)
– Città in cui è situato il punto di vendita
– Numero medio di abitanti della città in cui è situato il punto di vendita
– Regione in cui è situato il punto di vendita
– Locazione della regione (Nord, Centro,Sud, Isole)
– Nazione in cui è situato il punto di vendita
Questo elenco di caratteristiche relative a un punto di vendita è la nostra dimensione di analisi. È
ancora una definizione logica, non un’implementazione fisica. Non si deve vederla subito come una
tabella costituita da un certo numero di colonne: rimaniamo a livello logico per analizzare meglio tutti
gli aspetti che dovranno essere presi in considerazione al momento della progettazione fisica.

7. La dimensione data (1)
• Un’altra dimensione di analisi tipica (direi quasi obbligata) all’interno di un Data Warehouse è la
dimensione temporale. Difficilmente i fatti giungono disgiunti da qualche riferimento relativo al
momento in cui sono avvenuti. Una delle dimensioni temporali più utilizzate è quella con
granularità a livello giorno o mese. Una particolarità di questa dimensione è quella di non avere, in
genere, una alimentazione esterna, ma può essere quasi tutta alimentata con semplici statement
SQL. Vediamo solo alcuni dei attributi, numerosissimi, che conviene sempre inserire in questa
dimensione.
•
• Numero del giorno (da 1 a 31)
• Giorno nel formato annomesegiorno numerico (YYYYMMDD)
• Flag di ultimo giorno del mese
• Mese di appartenenza in formato numerico (da 1 a 12)
• Mese di appartenenza in formato testuale (da gennaio a dicembre)
• … altri formati del mese
• Trimestre di appartenenza in formato numerico (da 1 a 4)
• … altri formati del trimestre
• Anno di appartenenza in formato YYYY
• ….

8. La dimensione data (2)
• Non bisogna avere timore nell’aggiungere caratteristiche a questa dimensione. Mi
soffermo brevemente su due attributi in particolare, che, nel caso della vendita al
dettaglio, conviene sempre inserire:
•
• Tipo giorno. Quest’informazione può essere utile per indicare situazioni particolari come
scioperi nazionali, attentati, calamità che possono rappresentare un modo di inquinare i
dati nel caso in cui non sia possibile identificare questi giorni particolari nelle condizioni di
filtro.
• Giorno di corrispondenza dell’anno precedente. Quest’informazione è utile per i
raffronti con l’anno precedente. L’esempio tipico è la Pasqua che, di anno in anno, cade in
giorni diversi. Se si vogliono confrontare le vendite della settimana pasquale, si deve
poter confrontare la settimana pasquale corrente con la corrispondente settimana di
Pasqua dell’anno precedente.

9. La dimensione tempo
• In alcuni casi la granularità dei fatti temporali è a livello inferiore al giorno, cioè scende al livello di
minuti o di secondi. Ovviamente è impensabile costruire una dimensione giorno con una riga per
ogni secondo (provate a calcolare quanti secondi ci sono in un anno).
• In questo caso è preferibile affiancare alla dimensione giorno una dimensione tempo che conterrà
solo una riga per ogni secondo (o minuto) di una giornata.
• Sarà molto utile per costruire delle gerarchie che raggruppano i minuti della giornata nelle fasce
orarie utilizzate dall’analisi.
• C’è da dire che l’ultima tendenza della modellazione dimensionale tende comunque a spostare
una data completa (full SQL date-time stamp) direttamente nella fact table, vista come se fosse un
tipo un po’ particolare di fatto: questo per rispondere in modo più efficiente al calcolo di intervalli
di tempo fra diversi record di fatti.

10. La dimensione cliente
• Questa dimensione di analisi è un’altra tipica dimensione presente in quasi tutti i Data Warehouse.
Nel caso del Data Warehouse esemplificato, la si potrebbe applicare solo ai possessori di una
Fidelity Card, di cui si hanno delle informazioni anagrafiche precise.
• Ma, al di là del caso specifico, questa dimensione può essere una di quelle più difficili da gestire.
Pensate quanti milioni di righe può contenere la dimensione cliente di una importante azienda
telefonica o di una Banca Internazionale.
• Le caratteristiche del cliente sono varie, e, in fase di analisi, dovranno essere identificate nel modo
più completo. Vediamo qualche esempio:
– Codice cliente
– Nome/cognome cliente
– Nazionalità
– Sesso
– Professione
– Indirizzo
– … altri tipi d’indirizzi
– Numero di telefono
– Indirizzo e-mail
– …

11. Dimensioni e tabelle dimensionali (1)
• Quando ho introdotto la dimensione dei punti di vendita, ho sottolineato il fatto che stavo
descrivendo una dimensione dal punto di vista logico e non fisico. Infatti, la dimensione di analisi,
nel senso logico del termine, si compone di due parti
– la tabella dimensionale
– la dimensione o struttura dimensionale
• Poiché questo concetto è spesso fonte di incomprensioni, cerchiamo di approfondirlo. L’elenco
degli attributi dei punti di vendita descritto in precedenza, è solamente un elenco. Esso è privo di
struttura, nel senso che non mostra le relazioni che ci sono fra gli attributi stessi.
• Gli attributi nazione, regione, città, quartiere e punto di vendita costituiscono una chiara gerarchia
topografica, relazionando in modo 1:N i vari livelli gerarchici: in una nazione ci sono N regioni, in
una regione ci sono N città, e così via.
• Gli attributi che sono parte di una struttura gerarchica vengono detti attributi di livello. Gli attributi
tipo quartiere e descrizione quartiere sono invece specifici del quartiere, cioè sono in relazione
1:1 con il codice quartiere.
• Conoscere queste relazioni fra gli attributi è importante, ecco perché alla vera tabella
dimensionale con i suoi attributi, che conterrà i dati, è affiancata una struttura dimensionale che,
utilizzando un particolare formalismo, tiene traccia delle relazioni fra gli attributi.

12. Dimensioni e tabelle dimensionali (2)
• Questa struttura, che in un DBMS come Oracle si chiama dimensione, è solo un oggetto di
metadati, esattamente come una constraint.
• Quando si crea una constraint di foreign key, si crea semplicemente un metadato che indica la
relazione fra due campi di due tabelle; la stessa cosa vale per le dimensioni: quando si crea una
dimensione si crea un metadato che mi descrive le dipendenze funzionali fra gli attributi della
tabella dimensionale.

13. Le Slowly Changing Dimension (SCD) (1)
• Finora abbiamo analizzato le dimensioni di analisi da un punto di vista logico, diciamo,
statico/strutturale. La realtà informativa che andiamo a progettare è sicuramente più dinamica,
nel senso che le cose cambiano e noi, in qualche modo, dobbiamo analizzare tali cambiamenti. O,
perlomeno, sapere che è un problema comunque da affrontare.
• Noi sappiamo che i Data Mart di un Data Warehouse tracciano una storia d’eventi. Una volta che
l’evento (il fatto) è avvenuto, esso rimane immutabile nel tempo.
• Se il cliente Rossi ha acquistato un’automobile da 10.000 euro il 9 novembre di due anni fa, il
prezzo di tale acquisto rimarrà lo stesso per tutti gli anni futuri. Un fatto è un fatto, e tale deve
rimanere.
• Le entità rappresentate nelle dimensioni di analisi, invece, si comportano diversamente: quasi
sempre cambiano nel tempo. La persona che ha acquistato quell’automobile da 10.000 euro, due
anni fa forse era uno studente, oggi è un impiegato, domani potrà essere un commerciante. Lo
stesso ragionamento vale per il suo stato civile, due anni fa era celibe, oggi forse è sposato.
• Ho fatto l’esempio della dimensione cliente perché storicamente è una delle più dinamiche, ma lo
stesso discorso si può applicare ai punti di vendita. I business manager possono decidere in
qualunque momento di modificare le strutture organizzative.
• Se una dimensione ha delle caratteristiche che cambiano nel tempo, allora prende il nome di
Slowly Changing Dimension (SCD), e questo comportamento ci impone di trovare un modo di
gestirla senza intaccare i fatti associati ad essa.

14. Le Slowly Changing Dimension (SCD) (2)
• Gestirla significa che quando giunge il flusso di alimentazione della dimensione cliente, nel quale
ieri l’attributo professione era valorizzato a “studente” e oggi è valorizzato a “impiegato”, si deve
trovare un modo per trattare questo fatto basandoci sull’esigenze del cliente finale che utilizzerà la
reportistica di analisi. Le esigenze possibili ricadono quasi sempre in tre categorie, che
banalmente, sono storicamente indicate come Type 1, Type 2, e Type 3. Vediamole dal punto di
vista logico.
• SCD di tipo 1 (overwrite): l’esigenza di questo tipo è molto semplice. All’utente finale non
interessa il fatto che è avvenuto un cambiamento. Per lui fa fede la situazione che c’è adesso e
quindi vale anche per il passato.
• Un esempio di tale situazione è un cambiamento nella struttura organizzativa. Se il management
decide di suddividere una organizzazione territoriale da tre regioni in cinque regioni, è probabile
che ora le analisi dovranno essere basate sulla nuova organizzazione. L’esigenza quindi è quella di
sostituire o rimpiazzare la vecchia informazione con quella nuova. Bisogna prestare attenzione a
questa scelta: si deve essere consapevoli che la soluzione di tipo 1 modifica i fatti del passato
come se fossero correnti.
• Tornando all’esempio dell’acquisto dell’automobile da parte dello studente Rossi di due anni fa,
significa che se gestisco il cambiamento di tipo 1, lo studente Rossi oggi è un impiegato, e anche la
vendita di due anni fa risulterà fatta a un impiegato. Ho perso l’informazione che era studente. Il
vantaggio di questa soluzione è che è semplice e facilmente implementabile: in fondo si tratta di
rimpiazzare il vecchio valore con il nuovo.

15. Le Slowly Changing Dimension (SCD) (3)
• SCD di tipo 2 (partitioning history): con i cambiamenti di tipo 2 si cerca di risolvere i problemi
collegati alla soluzione di tipo 1.
• Se l’esigenza di business è quella di tenere traccia dei cambiamenti dimensionali di certi attributi,
la soluzione non può essere la sovrascrittura dei valori, ma bisogna trovare un modo per
storicizzarli. Significa partizionare la storia dei fatti in modo preciso e senza sovrapposizioni in
modo che la validità di un certo valore di un attributo sia circoscritta all’interno di un ben definito
intervallo temporale.
• Questo si può ottenere, aggiungendo una occorrenza specifica del cambiamento, da associare in
modo cronologico con i fatti corrispondenti. Il modo con cui tecnicamente possiamo ottenere
questo risultato lo vedremo nella seconda parte di questo articolo.
• Qui è sufficiente notare che mentre nel caso SCD di tipo 1 si ha sempre un’unica occorrenza
dimensionale associata per esempio al cliente Rossi, con le SCD di tipo 2 si avrà una occorrenza
diversa per tenere traccia di ogni cambiamento.

16. Le Slowly Changing Dimension (SCD) (4)
• SCD di tipo 3 (two alternate realities): i due casi appena visti, sembrano coprire la totalità delle
situazioni. O tengo traccia dei cambiamenti con il tipo 2, o considero solo la situazione corrente
con il tipo 1.
• La realtà economica sempre più competitiva, obbliga gli utenti e i manager a considerare
attentamente i dati prima di prendere delle decisioni. Questo fa sì che sempre più spesso sia
presente una nuova esigenza: poter confrontare diverse realtà prima di prendere la decisione
finale.
• In pratica l’utente vuole che nel momento che avviene un cambiamento ad un attributo
dimensionale, il vecchio valore non scompaia, ma rimanga attivo come seconda scelta. Le due
situazioni di business più comuni sono quelle relative a cambiamenti nelle strutture territoriali di
vendita e quelle relative a riassegnamenti merceologici fra articoli.
• Molto spesso gli utenti vogliono vedere l’andamento delle vendite di oggi basate sulla struttura
organizzativa di ieri. La soluzione di questo caso, che comunque vedremo in dettaglio, è quella di
aggiungere un altro attributo alla dimensione che memorizzi il vecchio valore assieme a quello
nuovo.

17. Le Minidimensioni (1)
• Il paragrafo precedente ha mostrato la necessità dinamiche di una dimensione di analisi,
rispondendo con tecniche diverse alle necessità degli utenti finali.
• Le SCD di tipo 2 però hanno un problema di gestione. Non è da sottovalutare la parola “slowly”.
• Le tecniche sopra esposte si adattano senza difficoltà a modifiche “lente”, cioè che avvengono in
modo molto diluito nel tempo. Una ristrutturazione gerarchica non si farà tutti i giorni, ma sarà
probabilmente annuale, o comunque abbastanza rara (non dimentichiamo che tali modiche
arrivano sul Data Warehouse, ma in genere hanno impatti notevoli anche sui sistemi alimentanti).
• La gestione della SCD di tipo 2 crea una nuova occorrenza al momento del cambiamento. Provate
a pensare cosa significa se:
– L’utente richiede di tenere traccia dei cambiamenti della dimensione cliente.
– Le modifiche avvengono molto frequentemente.
– Coinvolgono numerosi attributi in momenti diversi dell’orizzonte temporale.
– La dimensione cliente ha 100 milioni di occorrenze.
• Temo che la risposta sia una sola: la gestione SCD di tipo 2 diventerebbe un incubo. Per fortuna ci
vengono in aiuto le minidimensioni.

18. Le Minidimensioni (2)
• Il concetto che sta alla base delle minidimensioni è semplice (il vecchio dividi e conquista): bisogna
spezzare la dimensione principale, in questo caso quella cliente, in una o più dimensioni
secondarie.
• Il processo è il seguente. Si prende l’insieme degli attributi, si separano quelli statici (cioè quelli
che non possono cambiare come la data di nascita, il luogo di nascita, il sesso, ecc e quelli per cui o
non ha senso o non è richiesto di tracciare il cambiamento, come il numero di telefono, l’indirizzo,
ecc) da quelli dinamici.
• L’insieme degli attributi statici costituirà la vera dimensione cliente, l’insieme degli attributi
dinamici costituirà la minidimensione “Attributi demografici”.
• In questo modo la cardinalità della dimensione cliente rimarrà costante a 100 milioni di
occorrenze, mentre la cardinalità della minidimensione avrà il numero di tutte le combinazioni
correnti degli attributi che ne fanno parte.
• La minidimensione sarà a tutti gli effetti una vera dimensione di analisi, e i cambiamenti verranno
tracciati nella tabella dei fatti. A seconda del numero di combinazioni (che in genere è piccolo)
sarà prerogativa del Data Warehouse Architect decidere di spezzarla in più minidimensioni.

19. Le Dimensioni Degeneri (degenerate dimensions)
• Nella prima parte di questo articolo abbiamo diviso la realtà informativa in valori quantitativi (fatti)
e valori qualitativi (dimensioni).
• In fase di design quasi sempre è presente una categoria di informazioni che è difficile classificare
secondo quella modalità. In questa categoria rientrano il codice ordine, il codice fattura, il codice
della bolla di spedizione, il numero dello scontrino, insomma tutti i codici di documenti di
controllo di vario tipo.
• Il modo di trattare questi codici è quello di inserirli direttamente nelle fact table. Compariranno
dopo tutti i codici associati alle dimensioni e prima dei fatti numerici. Per questo motivo sono
dette dimensioni degeneri: non hanno una dimensionale associata perché privi di attributi.
• Il caso più classico è quello della fact table che contiene il dettaglio delle singole linee d’ordine o di
fattura. Il codice ordine e il numero di linea d’ordine sono dimensioni degeneri.

20. Conclusioni
• Questa prima parte dell’articolo si è focalizzata principalmente sugli aspetti semantici e logici delle
dimensioni di analisi.
• Le abbiamo analizzate sia dal punto di vista statico che dinamico. Siamo quindi pronti per entrare
nel design e nell’implementazione fisica dei concetti sopra esposti. Nel prossimo articolo
affronteremo quindi due argomenti che sono oggetto di guerre di religione e discussioni senza
fine:
– Chiavi artificiali contro chiavi naturali
– Dimensioni flat contro dimensioni snowflake
• Vedremo inoltre, con un caso reale, come implementare le Slowly Changing Dimension dei tre tipi
descritti.

21. Riferimenti
• [1] W.A.Giovinazzo – “Object-oriented Data Warehouse Design ”, Prentice Hall, 2000
• [2] R.Kimball – “The Data WarehouseLifecycle Toolkit ”, Wiley, 1998
• [3] Massimo Cenci Data Warehouse Blog http://massimocenci.blogspot.it/