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.

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.

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…”.

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.

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.)

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.

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• ….

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.

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.

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– …

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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/