Note di Data Warehouse e Business Intelligence - Le Dimensioni di analisi (parte 2)

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.

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

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.

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.

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.

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.

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.

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.


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


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


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

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


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


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


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

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.

Note di Data Warehouse e Business Intelligence - Le Dimensioni di analisi (parte 2)

Technology

Transcript of Note di Data Warehouse e Business Intelligence - Le Dimensioni di analisi (parte 2)