Note di Data Warehouse e Business Intelligence - Le Dimensioni di analisi (parte 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.

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 della rivista Dev, 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 della rivista Dev (DDW). Vediamo ora di motivare perché deve essere un’unica tabella (flat) e perché deve avere una chiave artificiale.

Struttura flat e struttura snowflake

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.

Figura1

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

Le chiavi artificiali

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 !
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 precedentemente.

Slowly Changing Dimension (SCD)  di tipo 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. 

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

Slowly Changing Dimension (SCD)  di tipo 2

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. 

Figura 3

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.

• 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:

1. 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. 
2. 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.

Slowly Changing Dimension (SCD)  di tipo 3

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) 

Figura 4

 Descriviamo ora il processo indicato in figura:

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

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.

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.

Questo articolo può essere scaricato da Slideshare

Note di Data Warehouse e Business Intelligence - 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 è 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

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

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

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

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

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

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.
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.
Questo articolo in formato PowerPoint lo si può scaricare da SlideShare:
Le dimensioni di analisi

Riferimenti e altri link

[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/

Note di Data Warehouse e Business Intelligence: Il lato oscuro della qualità dei dati

Introduzione

Inutile dire che che il tema della qualità del dato è un argomento ampio e complesso. Su di esso sono stati scritti numerosi articoli e libri. Qualunque iniziativa di  Data Warehouse e Business Intelligence deve avere una componente di Data Quality nel suo gantt di progetto. (ma non è sempre così).

In questo mio articolo, vorrei porre l'attenzione su alcuni aspetti che spesso non emergono, e che costituiscono quello che mi piace definire "star-wars-icamente" il loro lato oscuro.

Ovviamente quanto esposto non è teorico, ma reale, basato su situazioni ed esperienze di vita progettuale.

Caricamento di dati errati

Avete implementato un buon sistema di controllo della qualità del dato. Avete impostato le regole, eseguite correttamente tutti i controlli e le righe con errori di varia natura non vengono inserite nell’Operational Data Store o nei  Data Mart, ma inserite in apposite tabelle di scarti. Siete convinti di avere fatto logicamente e tecnicamente un buon lavoro.

A questo punto mostrate il risultato dei vostri caricamenti all’utente finale e scoprite il primo lato oscuro della data quality: l’utente vuole caricare nei Data Mart anche i dati errati. E scopriamo che caricare dati errati è perfettamente logico se guardiamo la situazione dal punto di vista del business.

Supponiamo che stiamo caricando i dati di finanziamento di una società di credito del settore automotive (ma qualunque esempio in cui si tratta denaro può andare bene). Ogni contratto può valere migliaia di euro.

L’utente fa un discorso molto chiaro e semplice. Non vuole che per errori di un certo tipo, un contratto di migliaia di euro sparisca dal gran totale mensile dei finanziamenti. 

Se la data di nascita del cliente è nulla o sbagliata, se il contatore degli oggetti finanziati nel contratto è errato, se il marital status del cliente è errato, l’utente sa che comunque quelli sono soldi che sono stati incassati, vuole che vengano conteggiati e non li vuole perdere per motivi tecnici.

Lui giustamente ragiona in termini di business.

Questo esempio ci porta a riflettere che la realtà non è mai così matematicamente esatta, non possiamo più dividere i dati in modo salomonico in buoni e cattivi, ma dobbiamo considerare una realtà con varie sfumature. Una realtà in cui ci sono dati giusti, dati sbagliati e dati “praticamente giusti”.

Quali sono le implicazioni pratiche di queste considerazioni ?

Quando definiamo le strutture dati, dobbiamo tenere presente che possiamo avere vari livelli di errore e che i dati che appartengono ad  alcuni livelli sono da considerare esatti. Questo significa, per esmpio, che dobbiamo avere più tabelle di scarti, oppure avere sempre un indicatore del livello di errore per ogni record caricato. In questo modo agendo con delle opportune  “viste” possiamo raggruppare i dati giusti e “praticamente giusti” e caricarli sui Data mart.

Evitate la soluzione di annullare o non implemetare completamente il controllo: è comunque importante identificare questi record. Anche se vengono caricati regolarmente, sono comunque indice di qualche mal funzionamento dei sistemi alimentanti che deve comunque essere corretto.

Attenzione che ogni Data Mart può avere diverse motivazioni, e quindi la stessa regola non si applica a tutti i Data Mart presenti. 

Nell’esempio precedente, su un Data Mart delle vendite i dati con gli errori evidenziati vengono sicuramente considerati corretti. 

Ma in Data Mart di CRM, probabilmente avere records con la data di nascita del cliente o il  marital status nullo o errato ha profonde conseguenze sulle analisi che l’utente vuole fare. In questo caso quei dati saranno sicuramente da gastire in altro modo.

Creazione di dati inesistenti

Avete gestito il primo lato oscuro della data quality e avete caricato nei Data Mart anche i dati praticamente giusti. Mostrate nuovamente il risultato dei vostri caricamenti all’utente di business e scoprite il secondo lato oscuro della data quality: la necessità della creazione di dati inesistenti.

Per chiarire questa situazione, facciamo un esempio di un caso reale. Abbiamo caricato i flussi di alimentazione in Staging Area, abbiamo caricato o aggiornato le tabelle dimensionali e stiamo caricando la tabella dei fatti. 

Quasi sempre alcune tabelle dimensionali sono la diretta conseguenza delle classiche tabelle di look-up; cioè sono tabelle molto semplici, con codice e descrizione che diventano una tabella dimensionale. Su tale tabella l’utente finale filtrerà i dati con una applicazione di Business Intelligence per eseguire le sue analisi. 

In situazioni di questo tipo, un classico problema di controllo di qualità è il seguente: se nei dati arriva un codice prodotto nullo o che non è presente nella dimensione prodotto, come devo trattarlo ?

Molto spesso la risposta giunge dall’utente finale. Ci sono situazioni in cui è l’utente di business che definisce quale è il dominio di prodotti (o di altre dimensioni) della sua analisi. In altre parole richiede che il Data Mart finale contenga i solo i prodotti ben definiti; tutti gli altri, che pensa rappresentino una percentuale irrilevante per le sue analisi devono confluire in un generico ‘Altro’ o ‘Sconosciuto’.

Per fare questo viene quindi definito un codice o una chiave fittizia, il famoso ‘99999’ o ‘Altro’. L’utilizzo di questo codice “bidone” è molto diffuso e possiamo scoprire che quasi ogni tabella dimensionale avrà una chiave di questo tipo.  Il codice-bidone dà sicurezza: è una implementazione molto semplice di controllo di qualità che non genera mai scarti. Qualunque anomalia giunga, caricheremo sempre i fatti associati alle dimensione di analisi.

Il lato oscuro di questo controllo di qualità, che possiamo definire punto di non ritorno, si manifesta dopo qualche settimana o mese di caricamento in produzione. Avverrà questo.

Gli importi o le quantità associate al bidon-code cominciano ad aumentare. Se la qualità dei dati di input non è eccelsa, il bidon-code sarà il codice con gli importi o quantità più alte.

L’utente finale chiederà il perché, e chiederà di vedere come è composto. A questo punto la nosta risposta sarà negativa: non è più possibile scomporre il codice bidone nelle sue componenti.

Il motivo di questa situazione è dovuto a una definizione sbagliata. Il bidon-code ‘Altro’ non è un codice, ma una aggregazione di codici, e quando carichiamo i dati, dobbiamo sempre caricarli al massimo livello di dettaglio consentito dalle sorgenti alimentanti. In altre parole, il codice “Altro”  alza di un livello la struttura gerarchica della dimensione di analisi. Dobbiamo sempre trovare un modo per identificare univocamente questi dettagli e associarli al codice bidone.

Questo significa che dobbiamo prestare molta attenzione quando definiamo le dimensioni di analisi e le eventuali gerarchie embedded. 

In figura un esempio di tale situazione.

Conclusione

La qualità del dato è un argomento complesso da trattare.Bisogna affrontarlo subito, perchè risolvere dei problemi in seguito, spesso comporta pericolose modifiche strutturali ed elaborative.

E non dimentichiamo che la realtà dell'utente finale supera sempre la fantasia degli analisti.