L’utilizzo dei Data WareHouse nasce con l’obiettivo di rendere l’informazione aziendale accessibile, consistente, affidabile e usabile per il supporto alle decisioni. La progettazione prevede varie fasi ma non esiste un modello progettuale standard. Per cui, a partire dal modello di Kimball, verrà proposto un possibile modello progettuale da poter seguire nelle fasi architetturali.
Architettura di un Data WareHouse
L’architettura base di un Data WareHouse (DW) mette insieme gli elementi illustrati in figura 1.
Figura 1 – Architettura Data WareHouse.
Le sorgenti dei dati possono essere i sistemi operazionali di un’organizzazione oppure delle sorgenti esterne come dati forniti da società. Il data mart è un sottoinsieme logico del DW e, come afferma Kimball, “Il Data WareHouse non è nulla più che l’unione dei data mart che lo costituiscono”. L’organizzazione di un Data WareHouse può essere dimensionale, realizzato cioè come unione di un insieme di data mart, inteso come insieme di schemi dimensionali. Da questa architettura generale, si arriverà a definire un modello che si possa seguire nelle varie fasi di progettazione di un DWH.
Possibili modelli di progettazione di un data mart
Da letteratura esistono vari approcci legati alla realizzazione di un Data WareHouse; in particolare, abbiamo:
- un approccio top-down, in cui dall’analisi dei bisogni dell’azienda si pianifica lo sviluppo del DWH;
- un approccio bottom-up, in cui il DWH viene costruito in modo incrementale, assemblando iterativamente più data mart.
Solitamente l’approccio consigliabile da seguire è il bottom-up di modo che sia più semplice da gestire e da seguire nelle sue varie fasi realizzative.
Il ciclo di vita di un DW proposto da Kimball [1] è rappresentato in figura 2.
Figura 2 – Business Dimensional Lifecycle.
Come si vede, il ciclo di vita di un DW prevede varie fasi. Il modello che verrà proposto in questo articolo si basa fondamentalmente su questo ciclo di vita, ma con la differenza di avere presente in più la progettazione concettuale.
Modello progettuale di un data mart
Illustriamo adesso il modello progettuale che seguiremo per la realizzazione di un data mart. I passi principali sono i seguenti:
- Analisi e riconciliazione delle sorgenti
- Analisi dei requisiti
- Progettazione concettuale
- Progettazione logica
- Progettazione dell’alimentazione
- Progettazione fisica
Figura 3 – Progettazione di un data mart.
La figura 3 illustra i passi fondamentali per la progettazione di un DWH che saranno dettagliati nei paragrafi successivi.
Analisi e riconciliazione delle sorgenti
Questa è la fase in cui il progettista, confrontandosi con gli esperti del dominio applicativo, acquisisce conoscenza delle sorgenti operazionali attraverso:
- ricognizione che consiste nell’esaminare gli schemi locali per comprendere il dominio;
- normalizzazione che consiste nel correggere gli schemi locali per poter modellare il dominio in maniera più accurata.
Queste operazioni devono essere ripetute per ogni schema qualora esistano più sorgenti. Dopo avere applicato la ricognizione e la normalizzazione, si ottengono degli schemi concettuali trasformati.
Figura 4 – Analisi e riconciliazione delle sorgenti.
Una volta ottenuti gli schemi concettuali trasformati, occorre effettuare l’integrazione degli schemi di modo da ottenere lo schema riconciliato.
Integrazione degli schemi
L’ integrazione di un insieme di sorgenti dati (basi di dati relazionali, file dati, sorgenti legacy) consiste nell’individuare le corrispondenze tra i concetti rappresentati negli schemi locali e nel risolvere i possibili conflitti, di modo da creare uno schema unico. L’operazione non deve però limitarsi solo a identificare le differenze di rappresentazione dei concetti comuni a più schemi, ma deve anche identificare l’insieme dei concetti distinti e memorizzati in schemi differenti che sono correlati tra loro mediante delle proprietà semantiche (proprietà interschema). L’operazione d’integrazione prevede tre fasi:
- la fase di comparazione degli schemi, per identificare i possibili conflitti tra i concetti presenti negli schemi. Possibili conflitti possono essere quelli di omonimia tra i nomi di entità presenti negli schemi, di sinonimia tra relazioni presenti in schemi diversi, e così via. (figura 5).
- la fase di allineamento degli schemi serve a risolvere i conflitti individuati al passo precedente e,, per risolverli, occorre applicare delle trasformazioni agli schemi sorgenti o a quello riconciliato temporaneamente definito. Tipiche trasformazioni sono la modifica dei nomi e dei tipi degli attributi, la modifica delle dipendenze funzionali, e così via. Non sempre i conflitti possono essere risolti, poiche’ derivano da inconsistenze di base del sistema informativo; in questo caso la soluzione deve essere discussa con gli utenti che dovranno fornire indicazioni su qual è la più fedele interpretazione del mondo reale.
- La fase di fusione degli schemi è quella in cui gli schemi vengono fusi in uno solo, in modo da formare uno schema riconciliato.
Figura 5 – Possibili conflitti tra concetti degli schemi riferiti alla fase di comparazione.
Analisi dei requisiti
In questa fase si ha l’obiettivo di raccogliere le esigenze di utilizzo del data mart, espresse dai suoi utenti finali. La fonte principale da cui attingere i requisiti sono i futuri utilizzatori del data mart (business users).
Progettazione concettuale
Per la modellazione concettuale viene introdotto come formalismo il Dimensional Fact Model (DFM) e la rappresentazione generata consiste in un insieme di schemi di fatto, in cui gli elementi di base modellati sono i fatti, le dimensioni, le misure, le gerarchie.
DFM: costrutti di base
Vediamo adesso gli elementi fondamentali che occorre modellare mediante DFM (figura 6).
Un fatto è un concetto di interesse e tipicamente modella un insieme di eventi che accadono nell’impresa (ad esempio: “vendite”, “spedizioni”,” acquisti”, …); è essenziale che un fatto abbia aspetti dinamici, ovvero evolva nel tempo.
Una misura è una proprietà numerica di un fatto e ne descrive un aspetto quantitativo di interesse per l’analisi (ad esempio, ogni “vendita” è misurata dal suo “incasso”).
Una dimensione è una proprietà con dominio finito di un fatto e ne descrive una coordinata di analisi (dimensioni tipiche per il fatto “vendite” sono “prodotto”, “negozio”, “data”).
Figura 6 – Costrutti base del DFM.
Con il termine generale attributi dimensionali si intendono le dimensioni e gli eventuali altri attributi. Una gerarchia è un albero direzionato i cui nodi sono attributi dimensionali e i cui archi modellano associazioni molti-a-uno tra coppie di attributi dimensionali. Essa racchiude una dimensione, posta alla radice dell’albero, e tutti gli attributi dimensionali che la descrivono (figura 7).
Figura 7 – Costrutti base del DFM.
I costrutti che abbiamo visto sono i costrutti base utilizzati per la modellazione ma ne esistono altri anche di avanzati che non verranno qui illustrati.
Passi della progettazione concettuale
La progettazione concettuale viene fatta a partire dal database riconciliato:
- Schemi E/R
- Schemi Relazionali
- Schemi XML
Il primo passo da compiere è definire i fatti e per ciascuno di essi bisogna:
- Costruire un albero degli attributi
- Fare Editing dell’albero degli attributi
- Definire le dimensioni
- Definire le misure
- Creare lo schema di fatto
Definizione di un fatto
Partendo da uno schema relazionale, un fatto corrisponde ad una relazione F.
Figura 8 – Modello E/R delle vendite.
Nell’esempio delle vendite viene scelto come fatto l’associazione VENDITA.
Costruzione dell’albero degli attributi
L’albero degli attributi è un albero in cui ogni vertice è un attributo dello schema sorgente. La sorgente corrisponde alla chiave primaria di F e, per ogni vertice, l’attributo corrispondente determina tutti gli attributi corrispondenti ai discendenti. Considerando il modello E/R di figura 8, il corrispondente albero degli attributi è rappresentato in figura 9.
Figura 9 – Albero degli attributi.
Editing dell’albero degli attributi
L’editing permette di manipolare l’albero per eliminare dei livelli di dettaglio non necessari con operazioni di potatura o di innesto.
Definizione delle dimensioni
Le dimensioni devono essere nell’albero degli attributi tra i vertici figli della radice. Nel nostro esempio, prodotto è una dimensione.
Definizione delle misure
Se tra le dimensioni ci sono tutti gli attributi che costituiscono un identificatore dell’entità fatto, allora le misure corrispondono ad attributi numerici che sono figli della radice dell’albero. Altrimenti, le misure devono essere definite applicando, ad attributi numerici dell’albero, funzioni di aggregazione (somma/media/massimo/minimo) che operano sulle istanze di F. Ecco alcuni esempi di misure:
- quantità venduta = SUM(VENDITA.quantità)
- incasso = SUM(VENDITA.quantità*VENDITA.prezzoUnitario)
- prezzo unitario = AVG(VENDITA.prezzoUnitario)
Creazione dello schema di fatto
L’albero degli attributi può ora essere tradotto in uno schema di fatto che include le dimensioni e le misure definite.
Figura 10 – Schema di fatto.
Progettazione logica
La fase di progettazione logica permette di definire lo schema logico del data mart a partire dallo schema concettuale, appoggiandosi a dei possibili modelli come il ROLAP e il MOLAP.
Il ROLAP (Relational On-Line Analytical Processing) utilizza il modello relazionale per la rappresentazione dei dati multidimensionali, mentre il MOLAP (Multidimensional On-Line Analytical Processing) memorizza i dati utilizzando delle strutture multidimensionali (p.e.: vettori multidimensionali). Quest’ultimo modello ha il problema della sparsità dei dati, e il loro utilizzo è anche frenato dalla mancanza di strutture dati standard.
I ROLAP permettono la modellazione mediante l’utilizzo degli schemi a stella, composti principalmente dalle dimension table e dalla fact table. La dimension table è un insieme di relazioni , ciascuna corrispondente ad una dimensione; la fact table è invece una relazione che importa le chiavi delle dimension table.
Lo snowflake è un altro possibile schema che riduce la denormalizzazione delle dimension table. La progettazione logica prevede infatti la scelta di uno degli schemi appena indicati per poi effettuare la traduzione dello schema concettuale in schema logico.
Progettazione dell’alimentazione
La progettazione dell’alimentazione prevede la definizione di procedure necessarie al caricamento all’interno del data mart dei dati provenienti dalle sorgenti operazionali.
La prima operazione è quella dell’estrazione dei dati dalle sorgenti e le possibili modalità di estrazione sono:
- statica in cui il livello riconciliato viene ricreato ex-novo;
- incrementale in cui vengono aggiunti solo i dati prodotti dal sistema operazionale nell’intervallo di tempo intercorso dall’ultimo caricamento.
Al termine del processo di estrazione, il risultato sarà dato dall’insieme dei record della sorgente modificati, aggiunti o cancellati rispetto alla precedente estrazione. Al termine di questa fase, i dati risiedono nella cosiddetta staging area.
L’altra operazione da fare è il caricamento dei dati dalla staging area e questa dipende:
- dalla tecnica utilizzata nella fase di estrazione;
- dal livello di storicizzazione del livello riconciliato.
Se l’estrazione è stata statica, allora ci sarà una riscrittura completa. Se l’estrazione è stata incrementale e il livello riconciliato non è storicizzato, allora verrrà memorizzata solo il tipo di operazione che ha determinato la variazione; altrimenti se il livello riconciliato è storicizzato, verrà memorizzata una coppia di marche temporali che indicano l’intervallo di validità.
Progettazione fisica
La progettazione fisica del data mart prevede la definizione del piano degli indici e dell’ insieme di parametri che nel loro complesso determinano lo schema fisico. Lo spazio su disco occupato da un database è suddiviso in:
- tablespace: suddivisione logica dei dati in unità che contengono informazioni uniformi;
- datafile: file contenente una parte delle informazioni di un tablespace;
- blocco dati: unità letta o scritta dal DBMS.
Questi elementi incidono sulle prestazioni e, come tali, è fondamentale definirne una corretta progettazione.
Conclusioni
Il modello proposto vuole essere una possibile guida in fase di progettazione di un Data WareHouse che dipende da dei data mart, dal momento che comunque non esiste un modello standard di riferimento.
Il modello proposto è semplicemente una estensione del modello di Kimball, che mancava della fase di progettazione concettuale, utile per definire lo schema dei fatti a partire dal modello di riferimento.
Riferimenti
[1] Kimball Group: Data Warehouse Training, Consulting, and Kimball University