Il Dimensional Fact Model viene spesso presentato come un modello concettuale per la definizione di sistemi di data warehousing: durante la fase di analisi può essere efficacemente utilizzato per formalizzare i requisiti informativi che il sistema dovrà soddisfare, mentre nella fase di progettazione costituisce il principale input per il disegno del modello logico su cui si basa l’applicazione di Business Intelligence.
Lo stesso modello concettuale può essere implementato con diverse tecnologie: ROLAP, MOLAP, HOLAP, ecc. Anche nell’ambito di una medesima tecnologia non esiste una modalità unica di traduzione di un modello dimensionale in modello logico e spesso le scelte di disegno sono guidate da altri requisiti funzionali e non funzionali.
Di seguito vediamo un esempio di come sia possibile implementare, in ambiente relazionale, il modello dimensionale di analisi delle vendite già descritto.
Il modello logico di riferimento scelto è il classico star-schema: ogni schema di fatto viene implementato da una tabella dei fatti (fact table) in cui vengono rappresentate tutte le misure; alla fact table sono collegate tante tabelle dimensionali denormalizzate (dimension table) quante sono le gerarchie presenti nello schema di fatto.
Ogni dimension table rappresenta tutti i livelli di aggregazione della gerarchia; ogni livello è costituito dall’attributo dimensionale che lo identifica e da tutti gli attributi non dimensionali ad esso collegati. Generalmente ad ogni attributo corrisponde un campo della tabella.
Alle tabelle vengono inoltre aggiunti i campi tecnici quali chiavi surrogate, campi di audit (data di creazione, date di validità del record, ecc.) che non hanno una diretta corrispondenza con gli attributi e le misure del modello.
E’ buona regola definire i vincoli di chiave primaria su tutte le tabelle. Per le tabelle dimensionali la chiave naturale della tabella è costituita dal campo relativo alla dimensione della gerarchia e questa può essere utilizzata come primary key della tabella. Nel caso in cui sia stata inserita nella tabella una chiave surrogata, sarà questa a costituire la primary key; a seconda delle esigenze può essere comunque utile definire anche un vincolo di unicità sulla chiave naturale. Per le fact table generalmente la primary key è costituita dall’insieme dei campi (foreign key) che referenziano le dimensioni dello schema di fatto.
Per quanto riguarda i vincoli di integrità referenziale fra la fact table e le dimension table, pur essendo questi parte integrante del modello logico, la loro implementazione fisica può essere subordinata a considerazioni di natura prestazionale, fermo restando che l’integrità referenziale deve essere comunque garantita dal database e/o dalle procedure di alimentazione.
Gerarchia Territorio
La gerarchia Territorio viene implementata da un’unica tabella relazionale denormalizzata: ogni attributo (dimensionale e non) da origine ad un campo della tabella; inoltre è stato aggiunto il campo ID che svolge il ruolo di chiave surrogata. La chiave primaria (PK) della tabella è quindi costituita dal campo ID, mentre sul campo NEGOZIO, che implementa la dimensione della gerarchia e rappresenta quindi una chiave naturale (AK), viene imposto un ulteriore vincolo di unicità (UNIQUE).
Una possibile valorizzazione della tabella DIM_TERRITORIO è esemplificata nella tabella seguente.
| ID | NEGOZIO | INDIRIZZO | PROVINCIA | REGIONE | STATO |
|---|---|---|---|---|---|
| 1 | Roma Uno | Via del Corso | RM | Lazio | Italia |
| 2 | Milano | Via Orefici | MI | Lombardia | Italia |
| 3 | Roma Due | Viale Europa | RM | Lazio | Italia |
| 4 | Tutto a Poco | Via Roma | LT | Lazio | Italia |
| … | … | … | … | … | … |
Dall’esempio risultano evidenti le dipendenze fra i campi PROVINCIA, REGIONE e STATO che danno origine alle ridondanze tipiche delle strutture dati denormalizzate. Tali dipendenze presenti nel modello DFM non sono invece rappresentate nel modello relazionale.
Gerarchia Tempo
La tabella che implementa la gerarchia Tempo è composta da 4 campi: uno per ogni attributo; in questo caso il campo GIORNO (di tipo data), in qualità di chiave naturale, costituisce la chiave primaria della tabella.
Anche in questo caso sarebbe possibile affiancare alla chiave naturale della tabella una chiave surrogata come è stato fatto per la tabella DIM_TERRITORIO.
Gerarchia Prodotto
Vediamo ora un esempio di Slowly Changin Dimenson di tipo 2. Supponiamo che lo stesso prodotto possa essere fornito in momenti diversi da fornitori diversi. In questo caso la relazione uno-a-molti definita al livello concettuale fra gli attributi dimensionali Fornitore e Prodotto è verificata solo per determinati intervalli temporali (eventualmente collassati al livello di singolo giorno).
Il DFM non prevede uno specifico formalismo grafico per identificare le dipendenze funzionali dinamiche (cioè che evolvono nel tempo), tuttavia questo è un requisito che è fondamentale tracciare (es. con note o vincoli fuori schema) in quanto condiziona sia il modello logico/fisico implementante che le sue modalità di alimentazione.
Poiché nulla è immutabile nel tempo, in fase di definizione dei requisiti è importante selezionare quali siano gli elementi dinamici nelle gerarchie per cui sia di interesse tracciarne l’evoluzione nel tempo e quali siano i requisiti relativi all’analisi dinamica di tali gerarchie.
Nel nostro caso siamo interessati a poter analizzare le vendite di ciascun prodotto, confrontando le quotazioni del prezzo di acquisto e vendita al variare del fornitore nel tempo. Per tale tipo di analisi è necessario prevedere una tabella che consenta di rappresentare la dinamicità del legame fra prodotto e fornitore, senza rinunciare alla struttura denormalizzata che caratterizza uno star-schema; la soluzione scelta è quella denominata Slowly Changing Dimension di tipo 2 che prevede l’uso di una chiave surrogata (ID) e di una coppia di campi di tipo data (DATA_INIZIO_VALIDITA e DATA_FINE_VALIDITA) che identifichi l’intervallo di validità di ciascuna relazione.
Questo pattern implementativo prevede che uno stesso prodotto sia presente più volte in tabella, purché i periodi temporali definiti dalle due date di inizio e fine validità per ciascuna occorrenza non siano sovrapposti. In ciascuna occorrenza il medesimo prodotto può essere associato a un fornitore diverso; in un determinato istante temporale il prodotto viene fornito da uno e un solo fornitore.
In questo caso non è possibile definire una chiave naturale della tabella che garantisca tale condizione, tuttavia la coppia PRODOTTO e DATA_INIZIO_VALIDITA può essere usata per definire un vincolo UNIQUE in modo da garantire un ordinamento totale fra le diverse versioni del medesimo prodotto.
Una possibile valorizzazione della tabella DIM_PRODOTTO è esemplificata nella tabella seguente.
| ID | PRODOTTO | TIPO_PRODOTTO | FORNITORE | DATA_INIZIO_VALIDITA | DATA_FINE_VALIDITA |
|---|---|---|---|---|---|
| 1 | Prodotto X | Tipo 1 | Fornitore A | 10/2/2008 | 31/12/9999 |
| 2 | Prodotto Y | Tipo 1 | Fornitore A | 1/1/2008 | 31/12/2008 |
| 3 | Prodotto Y | Tipo 1 | Fornitore B | 1/1/2009 | 31/12/9999 |
| 4 | Prodotto Z | Tipo 2 | Fornitore B | 1/1/2008 | 20/2/2009 |
| … | … | … | … | … | … |
Il “Prodotto X” viene correntemente fornito dal “Fornitore A” a partire dal 10/2/2008: la data 31/12/9999 utilizzata come data di fine validità identifica la versione corrente delle informazioni relative al prodotto in questione.
Il “Prodotto Y” invece è stato fornito dal “Fornitore A” nel periodo compreso fra 1/1/2008 e il 31/12/2008; a partire dal 1/1/2009 viene invece fornito dal “Fornitore B”. Tale situazione è rappresentata dai due record identificati con ID 2 e 3.
StarSchema delle Vendite
La fact table che implementa lo schema di fatto relativo all’analisi delle vendite su riportato è costituita da due insiemi di campi: quelli relativi alle misure contenute nello schema di fatto e quelli che implementano le foreign key verso le tre dimension table; ciascuna foreign key referenzierà la primary key della rispettiva dimensione.
In particolare ID_TERRITORIO referenzia il campo ID della DIM_TERRITORIO, ID_TEMPO referenzia il campo GIORNO della DIM_TEMPO, e ID_PRODOTTO referenzia il campo ID della DIM_PRODOTTO. Le tre foreign key costituiscono congiuntamente la primary key della FACT_VENDITE.
Una possibile valorizzazione della tabella FACT_VENDITE è esemplificata nella tabella seguente.
| ID_TERRITORIO | ID_TEMPO | ID_PRODOTTO | QUANTITA_VENDUTA | PREZZO_VENDITA | PREZZO_ACQUISTO |
|---|---|---|---|---|---|
| 1 | 30/11/2008 | 2 | 10 | 100 | 70 |
| 1 | 10/1/2009 | 3 | 15 | 150 | 80 |
| 2 | 10/1/2009 | 1 | 1 | 120 | 60 |
| … | … | … | … | … | … |
Il negozio “Roma Uno” (ID_TERRITORIO = 1) ha effettuato due vendite del “Prodotto Y”: in data 30/11/2008 ha venduto una quantità 10 di tale prodotto che era stata acquistata dal “Fornitore A” (ID_PRODOTTO = 2), mentre in data 10/1/2009 ha venduto una quantità pari a 15 dello stesso prodotto rifornito questa volta da “Fornitore B” (ID_PRODOTTO = 3).
Complessivamente la quantità venduta di “Prodotto Y” è pari a 25 (10+15) mentre l’importo totale relativo ai prodotti acquistati dal “Fornitore A” (ID_PRODOTTO = 1 e ID_PRODOTTO = 2) è pari a 130 (60 + 70).