Le dimensioni di analisi sono le componenti fondamentali per definire gli spazi analitici all’interno di un Data Warehouse. Analizziamo in dettaglio il loro design e la loro implementazione (parte 2)

1. Note di Data Warehouse e Business
Intelligence
Le Dimensioni di analisi (parte 2)
Le dimensioni di analisi sono le componenti
fondamentali per definire gli spazi analitici
all’interno di un Data Warehouse.
Analizziamo in dettaglio il loro design e la loro
implementazione.

2. Introduzione
• Nella puntata precedente, abbiamo affrontato l’argomento dal punto di vista logico/concettuale. I
concetti esposti erano necessari perché l’analisi, scusate il gioco di parole, delle dimensioni di
analisi, è un compito da non sottovalutare.
• In ambienti aziendali particolarmente complessi, dove lo stesso concetto dimensionale compare in
modi e valori diversi nei vari sistemi alimentanti, identificare correttamente tutti gli attributi che
fanno parte della stessa dimensione è, di per sé, un progetto nel progetto.
• Superata la fase di analisi, bisogna iniziare il design; l’aria rarefatta di alto livello che abbiamo
respirato nelle discussioni e negli incontri, e che abbiamo formalizzato in modo descrittivo in
qualche documento, deve ora affrontare la dura realtà delle “create table”. Come organizziamo
questi insiemi di attributi? Un’unica tabella o più tabelle? Qual è la chiave primaria?
• Per chi ha già lavorato sul campo, in progetti di Data Warehouse, le domande precedenti
equivalgono a prendere le seguenti decisioni: tabelle flat o snowflake, codici naturali o codici
artificiali.
• Risponderemo a queste domande, ma prima definiamo subito quale può essere la struttura
ottimale di una tabella dimensionale. Spostiamoci quindi dietro le quinte, sulla implementazione
fisica della dimensione di analisi.

3. La struttura della dimensione
• Una dimensione di analisi dovrebbe essere costituita fisicamente da un’unica tabella con le
seguenti componenti.
• Un unico campo primary key contenente un intero univoco senza significato, cioè una chiave
artificiale. Questo sarà il campo che sarà utilizzato come join con la tabella dei fatti.
• Uno o più campi che compongono la natural key della dimensione che sono la base per definire la
primary key.
• Tutti gli altri attributi descrittivi, sia indipendenti che associabili a una struttura gerarchica. Non
spaventarsi se il loro numero può diventare elevato.
• Una serie di campi tecnici per la gestione, se necessario, delle Slowly Changing Dimensions (SCD)
descritte nell’articolo precedente.
• Il nome della tabella dimensionale, se possibile, deve essere basata su una opportuna naming
convention . Basandosi sull’esempio già citato della fact-table delle vendite, il nome della
dimensione di analisi dei punti di vendita potrà essere DDW_COM_PDV_DIT, a indicare la tabella
dimensionale (DIT) dei punti di vendita (PDV) che fa parte dell’area comune (COM) del progetto di
Data warehouse. Vediamo ora di motivare perché deve essere un’unica tabella (flat) e perché deve
avere una chiave artificiale.

4. Struttura flat e struttura snowflake (1)
• Una dimensione strutturata flat, indica che è fisicamente un’unica e piatta tabella. Una
dimensione strutturata snowflake indica che sono fisicamente più tabelle, una per ogni livello
gerarchico.
• Quindi, con snowflaking si intende la normalizzazione della dimensione di analisi. La Figura 1
confronta visivamente le due strutture per la dimensione dei punti di vendita.

5. Struttura flat e struttura snowflake (1)
• La scelta della struttura è un argomento, insieme a quello dell’utilizzo delle chiavi artificiali, che
genera sempre discussioni accese su cui è opportuno fare chiarezza.
• Il punto di partenza non deve essere il tecnicismo adottato o un dogmatismo tecnico: dobbiamo
sempre avere presenti due obiettivi fondamentali in un progetto di Data warehouse: la semplicità
e, soprattutto, le prestazioni. Gli utenti finali decreteranno il successo del progetto se, dal
momento del “click”, vedranno comparire i dati dopo pochi secondi.
• Lo snowflaking impedisce il raggiungimento di entrambi gli obiettivi. Vediamo il perché:
• Con lo snowflaking, lo schema si complica notevolmente dal punto di vista strutturale. La realtà
aziendale è sempre più complessa di quella presentata sui libri: provate a pensare a una
dimensione di analisi di punto di vendita, con 6 diverse strutture gerarchiche ognuna di
mediamente 5 livelli. Questo significa 31 tabelle da gestire, ognuna con i propri vincoli di integrità.
Con il flatting la tabella è unica.
• Con lo snowflaking, lo schema si complica notevolmente dal punto di vista visivo. Non
dimentichiamoci che tutti i tool di reportistica necessitano di una struttura di metadati su cui
costruire i report. Utenti particolarmente esperti potranno vederla e manipolarla personalmente.
Avere davanti agli occhi una unica struttura che contiene tutte le informazioni che servono è
diverso che vederne 31.

6. Struttura flat e struttura snowflake
• Con lo snowflaking non funzionano gli indici bitmap, che sono fondamentali per ottenere delle
elevate performance di accesso ai dati.
• Con lo snowflaking il numero di join, e quindi il numero di tabelle da mettere in relazione per
raggiungere le misure presenti nella fact table può essere estremamente elevato. Più join sono
presenti, più le prestazioni decadono; nel flatting, la join è sempre una sola: fact table con
dimension table sulla artificial key e indice bitmap. Nient’ altro.
• Con lo snowflaking è sicuramente vero che i valori dei campi di tutte le strutture gerarchiche e dei
loro attributi non sono duplicate (l’effetto della vecchia normalizzazione); in effetti il flatting
denormalizza, ma, a conti fatti, il risparmio di spazio è insignificante rispetto alla mole di dati delle
tabelle dei fatti.

7. Le chiavi artificiali (1)
• Inizialmente, parlando della struttura delle dimensioni, si è affermato che tutte le chiavi del Data
Warehouse siano chiavi numeriche prive di significato logico di business. Questo è un punto
importante. Dalla chiave numerica artificiale non si deve desumere nulla sul contenuto del record
corrispondente.
• L’utilizzo delle chiavi artificiali (con i suoi sinonimi: artificial key, surrogate key, technical key,
synthetic key,ecc.) è sempre stato un argomento oggetto di discussioni accese. Vediamo di
motivare questa scelta mostrando i problemi che possono sorgere nell’utilizzare le chiavi o codici
di produzione.
1. Prima o poi i sistemi esterni decideranno di riutilizzare codici già utilizzati in passato. La chiave
artificiale protegge il data warehouse dalle modifiche operazionali che avvengono nei sistemi
alimentanti.
2. Nel mondo economico l’acquisizione di aziende competitor è un processo abbastanza frequente.
Provate a pensare alle possibili implicazioni se un’azienda utilizza come codice cliente un numero
di 6 cifre, e l’azienda acquisita, di cui dobbiamo integrare la dimensione clienti utilizza un codice
alfanumerico di 12 cfre. Modificare una sola tabella dimensionale è ben diverso da modificare
tutte le tabelle dei fatti che hanno quel codice.

8. Le chiavi artificiali (2)
3. E’ richiesto di tenere tracce di un cambiamento di alcuni campi della dimensione cliente senza
modificare il codice di produzione. L’utilizzo delle chiavi artificiali permette questo con la gestione
delle SCD (Slowly Changing Dimension).
4. I codici operazionali sono spesso codici alfanumerici di parecchi bytes. Una chiave artificiale
numerica di poche cifre è sufficiente a coprire la cardinalità massima di una dimensione. Questo
implica tabelle dei fatti più piccole, indici delle tabelle dei fatti più piccoli e un numero maggiore di
righe per ogni blocco dati di database. Queste implicazioni significano un consistente incremento
delle performance di accesso ai dati.
5. La chiave artificiale permette di identificare le situazioni in cui non esiste un codice operazionale.
In ogni tabella dimensionale ci sarà sempre una riga (diciamo con chiave artificiale 0) associata al
codice “Non applicabile”. Pensate a una tabella delle vendite con presente il codice della
promozione: se non c’è una promozione in atto, invece di esserci un codice null (che prima o poi
darà sempre problemi nelle estrazioni) ci sarà una chiave numerica 0 con associato il codice
“Nessuna promozione presente” nella tabella dimensionale. Qualunque tool di reportistica
permetterà di selezionare facilmente queste situazioni.
• Riprendiamo ora il discorso sulla gestione dinamica delle dimensioni di analisi, cioè il trattamento
fisico delle Slowly Changing Dimension descritto nell’articolo del mese scorso.

9. Slowly Changing Dimension (SCD) di tipo 1 (1)
• Come sappiamo, l’esigenza di questo tipo è molto semplice: all’utente finale non interessa il fatto
che è avvenuto un cambiamento La gestione dei cambiamenti di tipo 1 è quindi il semplice
overwrite degli attibuti gestiti secondo questa tecnica.
• Nella Figura 2 vediamo che successivi cambiamenti nella dimensione cliente non aumentano il
numero di record della tabella (come faranno gli SCD2) ma semplicemente aggiornano il valore
degli attributi.

10. Slowly Changing Dimension (SCD) di tipo 1 (2)
• Sull’utilizzo dei campi tecnici presenti in tabella, si darà una descrizione più dettagliata nel
prossimo paragrafo.
• Per applicare questa tecnica bisogna però essere certi che non si vuole tenere traccia dei
cambiamenti, e del fatto, non trascurabile, che se sono presenti delle strutture di aggregazione
che hanno già aggregato i dati a livello gerarchico superiore con i vecchi valori degli attributi,
queste strutture devono essere tutte ricalcolate per aggiornarsi al dato corrente.

11. Slowly Changing Dimension (SCD) di tipo 2 (1)
• La gestione dei cambiamenti negli attributi di una dimensione di tipo 2, ci permette di tracciare in
modo preciso ogni cambiamento nel momento stesso in cui avviene e di associarlo correttamente
ai fatti presenti nella fact table.
• Nella Figura 3 vediamo un esempio di come funziona il meccanismo SCD2, partendo da una
situazione iniziale e gestendo progressivamente due cambiamenti dimensionali di due attributi
della dimensione Cliente.

12. Slowly Changing Dimension (SCD) di tipo 2 (2)
• In essa possiamo notare la presenza di alcuni campi tecnici ( in rosso) che forniscono un notevole
valore aggiunto ai cambiamenti che avvengono nella dimensione Cliente: senza di essi, sarebbe
complicato, se non impossibile, identificare quale è la situazione corrente o quando è avvenuto il
cambiamento.
• Vediamoli in dettaglio, perché non possono mancare in un corretto design di ogni dimension table
che contiene attributi gestiti con la tecnica SCD2.
• Data (key) del cambiamento: deve essere espressa come chiave artificiale per permettere il join
con la dimensione tempo, ricca di attributi facilmente filtrabili.
• Inizio validità: Timestamp (cioè anno,mese,giorno,ore,minuti,secondi) iniziale del cambiamento
dimensionale.
• Fine validità: Timestamp (cioè anno,mese,giorno,ore,minuti,secondi) finale del cambiamento
dimensionale. Questa data e la precedente identificano il periodo di validità del cambiamento,
cioè di una certa composizione del valore degli attributi. Queste date non devoo mai essere nulle,
e devono essere inizializzate a una data fittizia del passato (per es. 1-gen-1800) e a una fittizia nel
futuro (per es. 31-dic-3000). Il processo di caricamento deve fare in modo che lo spazio temporale
sia suddiviso con continuità senza mai sovrapposizioni.

13. Slowly Changing Dimension (SCD) di tipo 2 (3)
• Causa del cambiamento: deve indicare il campo il cui valore ha subito un cambiamento. Se i campi
sono più di uno, poiché non è possibile inserire una relazione 1:N, si consiglia di indicare i nomi dei
campi separati da virgola. Alcuni designer associano una tabella con le righe di ogni cambiamento
e una chiave di gruppo come link con la dimensione: questo però complica notevolmente la
gestione della SCD.
• Flag di ultimo: è un banale flag 0/1 che indica quale è il record con l’ultima modifica, cioè quello
corrente.
• Ordinale del cambiamento: è solo un progressivo numerico. Può essere utile per identificare per
esempio, quali sono i clienti che non hanno mai avuto dei cambiamenti o quelli che variano di più.
• Descriviamo ora il processo indicato in tabella:
• Il sistema alimentante invia le informazioni di un nuovo cliente di nome Rossi.
• Il processo di caricamento inserisce una nuova riga a cui associa una nuova chiave artificiale (in
genere presa da una sequenza in continuo incremento) e inserisce i dati di Rossi con in più le
informazioni tecniche per la sua gestione.

14. Slowly Changing Dimension (SCD) di tipo 2 (4)
• Dopo qualche mese il sistema alimentante cambia le informazioni di Rossi per indicare che da
studente è diventato impiegato.
• Il processo di caricamento deve registrare il cambiamento, quindi crea una nuova chiave artificiale,
e inserisce una nuova riga per il cliente Rossi. Registra il giorno corrente come data di inizio
validità, e il campo (o i campi) che sono stati oggetto del cambiamento. Incrementa l’ordinale del
cambiamento e setta a 1 il flag di ultimo. Quindi deve modificare il record precedente di Rossi per
chiudere la sua data di fine validità a ieri e modificare il flag di ultimo a 0.
• A questo punto il processo proseguirà allo stesso modo per tutti i cambiamenti futuri. Come
possiamo vedere dalla situazione finale dei record, se dobbiamo estrarre tutti i finanziamenti
stipulati dal Signor Rossi, il vincolo Nome cliente = ‘Rossi’ estrarrà tutte le chiavi artificiali dalla
dimension table e li collegherà a tutti quelli presenti nella fact table. Se aggiungiamo però anche il
vincolo Stato civile = ‘celibe’, saranno estratti solo i fatti relativi al periodo in cui il Signor Rossi era
celibe.
• Questa capacità di associare i fatti alla particolare situazione anagrafica che è attiva in un certo
momento rende chiaro il motivo per cui la tecnica SCD2 è anche definita Partitioning History.

15. Slowly Changing Dimension (SCD) di tipo 3 (1)
• La gestione dei cambiamenti negli attributi di una dimensione di tipo 3, ci permette di
memorizzare due situazioni storiche, quella corrente e quella precedente al fine di permettere agli
analisti di fare confronti fra le due realtà.
• Nella Figura 4 vediamo un esempio di come funziona il meccanismo SCD3, notando subito l’
intervento strutturale necessario alla sua gestione: ogni attributo deve essere duplicato.
• Questo significa che la tabella dimensionale deve avere una colonna con il valore corrente e una
colonna con il valore precedente. (i campi tecnici non sono indicati ma sono ovviamente presenti)

16. Slowly Changing Dimension (SCD) di tipo 3 (2)
• Descriviamo ora il processo indicato in figura:
• Il sistema alimentante invia le informazioni di un nuovo cliente di nome Rossi. Il processo di
caricamento inserisce una nuova riga cui associa una chiave artificiale e inserisce i dati di Rossi
duplicando, nei campi di professione e stato civile precedente, gli stessi valori (oppure li lascia
nulli).
• Dopo qualche mese il sistema alimentante cambia le informazioni di Rossi per indicare che da
studente è diventato impiegato. Il processo di caricamento deve copiare il valore del campo
professione nel campo professione precedente e sovrascrivere il nuovo valore nel campo
professione.
• A questo punto il processo proseguirà con la coppia di sovrascritture per tutti i cambiamenti futuri
e per ogni attributo coinvolto.

17. Slowly Changing Dimension di tipo ibrido
• Nulla vieta di combinare le gestioni precedenti all’interno della stessa dimensione. Non
dimentichiamo, che il trattamento delle SCD è specifico del singolo attributo (consiglio di avere
sempre una tabella di metadati che conservi questa preziosa informazione).
• Ogni attributo sarà gestito in modo univoco, ma ogni attributo avrà le sue esigenze. Il lato negativo
delle scelte ibride è che sono particolarmente complesse da implementare, quindi conviene siano
motivate da forti esigenze di business.

18. Conclusioni
• Analizzare,implementare, testare e infine utilizzare le dimensioni di analisi non è un compito
semplice. Esse non sono, come alcuni tendono a pensare delle semplici tabelle anagrafiche.
• Sono oggetti che devono essere creati e alimentati avendo in mente una precisa missione:
permettere l’accesso ai dati con la massima precisione e la massima velocità.
• Utilizzare tabelle a struttura flat, associare chiavi artificiali come link con le tabelle dei fatti,
costruire indici bitmap e foreign key dai fatti alle dimensioni vi permetterà di raggiungere il vostro
obiettivo.