Data Warehouse-lo strumento più valido per il
supporto alle decisioni
Con questo articolo, iniziamo la trattazione di un progetto di data warehouse, in cui analizzeremo
la fase generica di progettazione, ed illustreremo i mezzi che SQL Server 7 mette a disposizione
per la realizzazione.
In un mercato molto competitivo, come quello odierno, è di notevole importanza prendere decisioni in
tempi brevi. Per migliorare i processi decisionali si devono analizzare tutti i dati disponibili dell’azienda per
essere in grado di analizzare dinamicamente il mercato, in modo da capirne i meccanismi e prevederne
gli andamenti. Per rendere di facile consultazione i dati di svariati sistemi operativi e provenienti da
differenti applicazioni realizzate per scopi diversi, si rende necessaria la realizzazione di un data
warehouse. Con il termine data warehouse si indica una raccolta di dati orientata ad argomenti, integrata,
varabile nel tempo e non volatile, che diventa la base da cui far partire le attività di supporto decisionale
ed analisi dei dati.
Caratteristiche
Generalmente in un’azienda la struttura dei dati è orientata ad ottimizzare i processi aziendali
(l’emissione di un nuovo ordine o di una fattura, il carico e lo scarico del magazzino ecc), mentre il data
warehouse è orientato ad un concetto aziendale (le vendite o gli acquisti) e contiene tutte le informazioni
correlate al concetto, raccolte da vari sistemi di elaborazione. Una delle caratteristiche di un data
warehouse è l’integrazione. Essa nasce dalla necessità di dare coerenza alle diverse rappresentazioni
dei dati provenienti da applicazioni progettate per scopi diversi. Ci troviamo quindi ad affrontare il
problema di rendere i diversi dati disponibili in azienda, accessibili ed omogenei in un unico ambiente, ma
questo pone alcune difficoltà analizziamone alcune:
• Gli attributi che si riferiscono allo stesso argomento possono essere definiti in modo diverso, ad
esempio il codice di un cliente può essere definito come una stringa oppure come un numero, quindi
bisogna scegliere il tipo più adatto e ricondurre tutti gli attributi codice allo stesso tipo.
• Applicazioni che usano sistemi diversi di grandezze in base alle quali vengono effettuati i calcoli, ad
esempio ci possiamo trovare di fronte al totale dell’ordine espresso in lire in un’applicazione ed espresso
in euro o in altre.
• Dati che provengono da sistemi operativi diversi (Unix, Windows) e da database di formato diverso
(Access, Db2, Oracle...) Per popolare un data warehouse il primo passo è quindi di ricondurre i dati ad un
unico formato passando attraverso il riepilogo, conversione e decodifica dei dati. Il processo di
trasformazione dei dati in un formato integrato e uniforme deve essere inoltre automatizzato, in modo da
poter essere eseguito periodicamente, con la frequenza necessaria per soddisfare i requisiti aziendali del
data warehouse. SQL Server 7 mette a disposizione un nuovo componente, Data Transformation
Services (DTS) che supporta molti tipi di trasformazioni, come: calcoli di nuovi valori da uno o più campi
di origine, scomposizione di un singolo campo in più colonne di destinazione, ed altro. Le definizioni delle
trasformazioni DTS possono essere memorizzate in diversi formati, e possono essere quindi richiamate
con la frequenza temporale voluta. Tramite il DTS è possibile importare, esportare e trasformare i dati da
e verso, fonti dati multipli utilizzando un’architettura basata su OLE DB ed in grado di interagire con i
driver ODBC esistenti per consentire l’accesso ad altre fonti relazionali. Si possono implementare logiche
complesse di trasformazione e convalida dei dati utilizzando un motore di scripting ActiveX (è supportato
VBScript e JavaScript). Tali script possono richiamare metodi da qualsiasi oggetto OLE per modificare o
convalidare il valore di una colonna. È inoltre possibile creare task per il trasferimento dei file tramite FTP
o per l’avvio di processi esterni. Approfondiremo i DTS nel prossimo articolo. Un data warehouse deve
inoltre essere non-volatile, l’utente finale non deve poter cambiare i dati in esso contenuti, poiché il data
warehouse viene usato per fare indagini e non per inserire o modificare operazioni. Nel data warehouse
non si deve andare a modificare l’indirizzo di un cliente, anche perché in tal caso si perderebbe ogni
riferimento storico al fatto che il cliente ha cambiato indirizzo. I dati vengono caricati solitamente in massa
con una certa periodicità ed in modalità batch, solitamente di sera, per non appesantire il sistema e
successivamente possono essere consultati dall’utente finale.
Una caratteristica importante di un data warehouse è la dipendenza dal tempo. In un database aziendale
le operazioni accessibili, di solito, sono quelle dell’ultimo anno, in un data warehouse l’intervallo
temporale si allarga fino ad arrivare a coprire più anni contemporaneamente. In ambiente gestionale, il
database contiene il valore corrente di un dato (ad esempio l’ultimo numero di telefono di un cliente) e
questo dato può essere modificato perdendo ogni riferimento al dato precedente, mentre in un data
warehouse i dati possono essere visti come delle foto istantanee (snapshot) fatte in determinati momenti,
perciò tengono conto anche della storia dei soggetti. In un sistema gestionale si può o meno fare
riferimento ad elementi temporali (giorno della settimana, anno, ora, ...), mentre in un data warehouse si
deve sempre fare riferimento a qualche elemento di tempo. I dati presenti in un data warehouse devono
essere consistenti. Questo significa che se due persone interrogano l’archivio in momenti diversi per
conoscere le vendite avvenute nel mese di Aprile, devono ottenere lo stesso risultato; inoltre se i dati di
un determinato periodo, per qualche motivo, non sono stati caricati completamente, l’utente che li
richiede deve essere avvisato dell’incompletezza dei dati. Da ciò si vede come risulti utile la figura del
responsabile della qualità dei dati pubblicati nel data warehouse, il quale deve rendere disponibili le
informazioni solo quando si hanno sufficienti requisiti di analisi.
Tipologie di data warehouse
Esistono due tipi fondamentali di data warehouse, ovvero i data warehouse aziendali e i data mart. I data
warehouse aziendali includono informazioni estese a tutta l’azienda. In genere sono composti da varie
aree di argomenti e soggetti, come i clienti, le vendite, gli acquisti e vengono utilizzati sia per decisioni
tattiche che strategiche. Un data warehouse aziendale può avere dimensioni che vanno dalle decine di
gigabyte a qualche terabyte di dati, e può essere molto costoso e oneroso a livello di tempi di sviluppo e
gestione. La filosofia che si sta percorrendo nel progetto di un data warehouse è quella di pensare a
grandi progetti partendo con piccole realizzazioni. Vengono così creati i Data Mart, specializzati per l’uso
in un solo settore dell’azienda che può essere ad esempio l’area marketing o l’area logistica, e che
contengono un sottoinsieme dei dati aziendali. A differenza dei data warehouse aziendali, i data mart
vengono in genere sviluppati “dal basso verso l’alto” dalle risorse del reparto per un’applicazione
specifica di supporto decisionale o per gruppi di utenti specifici. Le informazioni in un data mart possono
essere un sottoinsieme di un data warehouse aziendale, data mart dipendente, oppure più
frequentemente derivano direttamente dalle fonti dati operative, data mart indipendente. Entrambe le
strategie richiedono tempi di sviluppo molto lunghi ed hanno requisiti tecnologici simili. Mediamente per lo
sviluppo di un intero progetto di data warehouse si parla di tempi nell’ordine di grandezza dell’anno.
Ovviamente i primi livelli di sviluppo devono essere molto rapidi, per permettere di creare un valido mezzo
di comunicazione tra utente e sviluppatore.
I metadati
In un data warehouse i metadati, ovvero i dati sui dati, giocano un ruolo di primo piano, la possibilità di
condividere e riutilizzare i metadati riduce di molto il costo e la complessità di sviluppo nonché la gestione
e l’utilizzo dei DW. I metadati sono utili allo sviluppatore come prima documentazione della struttura del
data warehouse e dei processi di trasformazione che subiscono i dati, all’analista servono a capire come
sono stati ottenuti i dati salvati nel data warehouse e quindi a formulare in modo più preciso le sue
interrogazioni. Tipicamente i metadati tengono conto di:
- struttura dei dati,
- trasformazioni dei dati,
- sorgente dei dati,
- modello dei dati,
- routine utilizzate per accedere ai dati.
Molti prodotti di data warehousing includono un repository di metadati proprietario che non può essere
utilizzato da altri componenti del data warehouse. Microsoft SQL Server 7.0 fornisce il componente
Microsoft Repository, un database che memorizza informazioni descrittive sui componenti software e le
corrispondenti interrelazioni ed è composto da un Open Information Model (OIM) e da un gruppo di
interfacce COM pubblicate. I modelli OIM sono modelli di oggetti e sono sufficientemente flessibili da
supportare nuovi tipi di informazioni, ed hanno la caratteristica di adeguarsi alle esigenze di utenti o
produttori specifici. Sono già presenti alcuni modelli OIM per schemi di database, trasformazioni di dati e
OLAP. Sono inoltre previsti modelli per la replica, la pianificazione delle attività, e una directory
informativa che combina metadati tecnici e aziendali. Tutte queste informazioni, una volta rese accessibili
a tutti i tipi di utenza in modo esplicito, aiutano sia nelle ricerche ed analisi dei dati in archivio che nello
sviluppo delle applicazioni.
Progettazione del data warehouse
Prima di iniziare la progettazione del data warehouse si devono considerare alcuni aspetti importanti:
• la granularità cioè il livello di dettaglio dei dati salvati nel data warehouse. Più alto è il livello di dettaglio
e più bassa è la granularità e viceversa. La granularità è direttamente legata al volume di dati salvato e,
di conseguenza, alle prestazioni del sistema e alla necessità di risorse hardware. Ovviamente bisogna
scegliere il giusto livello di granularità per evitare di memorizzare informazioni che non verranno mai
prese in considerazione e per evitare di non registrare informazioni importanti.
• Il tempo di aggiornamento del DW, cioè il periodo che intercorre tra due successivi aggiornamenti dei
dati contenuti nel DW.
• Il partizionamento dei dati. Il partizionamento dei dati si ha quando i dati contenuti in una stessa
struttura logica vengono divisi in più di una unità fisica ed inoltre un dato appartiene ad una ed una sola
partizione. Nel data warehouse è importante stabilire come partizionare i dati in modo che ciascuna unità
fisica di dati possa essere manipolata indipendentemente dalle altre. Il partizionamento presenta alcuni
vantaggi: maggior facilità di creare indici, riorganizzare, recuperare i dati e monitorare le operazioni degli
utenti. La fase di sviluppo del processo di data warehousing inizia spesso dalla creazione di un modello
aziendale dimensionale che descrive i valori metrici e le dimensioni più importanti dell’area di argomenti
selezionata in base ai requisiti degli utenti. A differenza dei sistemi di elaborazione delle transazioni in
linea (OLTP) che organizzano i dati con metodologie di normalizzazione, i dati nel warehouse sono
organizzati in modo non normalizzato per migliorare le prestazioni
delle query se i dati sono memorizzati in un sistema di gestione di
database relazionale. Per meglio rappresentare un data warehouse
si possono usare lo schema a stella (Star Schema) Fig. 1 oppure lo
schema a fiocco di neve (Snowflake Schema) )
Fig. 2. Nello schema a stella una tabella di
“fatti” centrale (detta fact table) è collegata ad altre tabelle correlate di attributi, ovvero dimensioni
(dimension table). Soltanto la tabella dei fatti (TF) è legata con join multiple a tutte le altre tabelle mentre
le dimensioni sono collegate soltanto alla fact table. Nella TF
vengono registrate le misure di mercato cioè gli elementi
fondamentali di un’azienda che si vogliono analizzare, nel nostro
esempio (Fig. 1): il costo, il prezzo unitario e la quantità venduta di un
prodotto. Le tabelle delle dimensioni contengono le informazioni sulle
dimensioni di analisi e cioè sulle misure di aggregazione dei fatti, ad
esempio se il fatto è una vendita la dimensione può essere dove questa vendita è avvenuta. Al contrario
dei fatti la dinamica di questi elementi è molto rarefatta. In una dimensione possiamo trovare, ad
esempio, la completa definizione di un cliente, anche se presumibilmente non è significativo conoscere
tutti gli acquisti del signor Rossi, ma può essere significativo ripartire le vendite per sesso o area
geografica del cliente. La chiave primaria di una TF è composta da tutte le chiavi esterne che la legano
alle dimension table. Ogni record della TF è quindi individuato dai record delle dimensioni: uno per ogni
tabella dimensionale. Lo schema star introduce il concetto di multidimensionalità, si può pensare, infatti,
che ciascun record della TF si trova in un punto le cui coordinate, sono determinate da un elemento
preso da ciascuna dimensione. Un record della TF allora contiene le sue coordinate e le misure di
mercato riferite a quel punto. Ogni attributo della TF viene chiamato e si suddividono in: additivi,
semiadditivi e non additivi. I fatti additivi possono essere sommati lungo qualsiasi dimensione ottenendo
un risultato utile e significativo. I fatti semiadditivi invece sono additivi solo lungo alcune dimensioni e non
lungo altre, e quelli non additivi non sono additivi lungo nessuna dimensione. La TF può contenere molti
milioni di righe per cui si deve porre particolare attenzione alla sua progettazione specialmente nella
scelta degli indici e dei campi che vogliamo salvare, spesso le informazioni a cui si accede con maggiore
frequenza vengono preaggregate e riepilogate in modo da migliorare ulteriormente le prestazioni. La
chiave primaria di una dimensione è composta da un solo attributo (a differenza di quella di una TF che è
composita) che si ripete come chiave esterna nella TF. Nello schema a stella non è possibile mettere in
relazione, tra di loro, due dimensioni e di solito risulta privo di senso, poiché contengono argomenti
completamente diversi. Nella definizione delle dimensioni spesso non è chiaro se un suo attributo debba
considerarsi o meno un fatto, un metodo per scegliere il suo posto è di analizzare se questo attributo vari
rapidamente nel tempo, ma anche in questo caso la parola rapidamente non è ben definita, ad esempio il
prezzo di un prodotto è quasi sempre considerato un fatto anche se può rimanere costante per lunghi
periodi. Una variante della composizione star è lo Snowflake Schema in cui le dimensioni che
contengono molti elementi vengono raggruppati attraverso caratteristiche che sono loro comuni. Gli
elementi raggruppati vengono raccolti in altre tabelle e sono connesse alla dimensione attraverso una
chiave esterna. In Fig 2 possiamo osservare uno Snowflake Schema in cui la dimensione prodotto è
collegata tramite il campo IDClassificazione alla tabella delle Classificazioni. Non è semplice poter
stabilire a priori se conviene usare lo schema a stella oppure lo schema a fiocco di neve, certamente lo
schema a stella è più automatico da costruire, per cui si può partire da esso come base ed in un secondo
momento se i risultati non sono abbastanza soddisfacenti passare allo Snowflake e dividere la
dimensione che viene utilizzata più spesso in due tabelle più piccole. Sebbene gli schemi a stella e a
fiocco di neve siano considerati principalmente uno strumento per amministratori di database che
consentono di migliorare le prestazioni e semplificare la progettazione dei data warehouse, sono anche
una convenzione utile per rappresentare le informazioni del data warehouse in un modo più
comprensibile per gli utenti aziendali. Mediante questi schemi si ha un adeguamento dello schema
iniziale del database relazionale al modello multidimensionale che richiede, di solito, interventi di
programmazione molto impegnativi. Per la visualizzazione di dati multidimensionali, la soluzione ottimale
è la tecnologia OLAP, alla lettera “On Line Analytical Processing”.
Cos’è OLAP
La tecnologia OLAP fornisce gli strumenti per accedere, esplorare e analizzare dati multidimensionali in
un modo semplice e “naturale”. La parola chiave di OLAP è FASMI (Fast Analysis of Shared
Multidimensional Information). OLAP deve quindi permettere una Veloce Analisi e Condivisione di
Informazioni in formato multidimensionale:
• Veloce: le informazioni dovrebbero essere fornite all’utente ad una velocità pressoché costante; la
maggior parte delle query dovrebbero fornire risultati agli utenti in cinque secondi o meno mentre
pochissime devono rispondere in più di 20 secondi.
• Analisi: le applicazioni devono essere in grado di eseguire operazioni fondamentali di analisi numerica e
statistica dei dati, predefinite dallo sviluppatore dell’applicazione o personalizzate in base alle richieste
degli utenti.
• Condivisione: implementazione dei requisiti di sicurezza necessari per la condivisione di dati
potenzialmente riservati tra un vasto numero di utenti e la possibilità di gestire la concorrenza.
• Informazioni: è fondamentale essere in grado di accedere a tutti i dati e a tutte le informazioni
necessarie e significative per l’applicazione, indipendentemente dalla posizione dei dati e senza
limitazioni quantitative.
• Multidimensionale: è il requisito più importante, l’essenza delle applicazioni OLAP. I sistemi OLAP
forniscono, per definizione, una vista multidimensionale dei dati.
Gli schemi a stella o a fiocco di neve sono approssimazioni relazionali del modello di dati OLAP e
possono rappresentare un punto di partenza eccellente per la creazione del concetto chiave dell’OLAP, il
cubo multidimensionale. In un modello di dati OLAP, le informazioni vengono gestite concettualmente
come cubi, composti da categorie descrittive (dimensioni) e valori quantitativi (misure). Per l’esempio
precedente, le dimensioni del cubo saranno: Cliente, Deposito, Campagna DiVendita, Tempo e Prodotto,
che corrispondono alle dimensioni dello star schema e le misure saranno: il costo, il prezzo unitario e la
quantità venduta di un prodotto, che corrispondono ai fatti della TF. All’interno di ogni dimensione di un
modello di dati OLAP, i dati sono organizzati in una gerarchia che rappresenta i livelli di dettaglio dei dati.
Per esempio, nell’ambito della dimensione Tempo esisteranno i livelli: Giorno, Mese, Anno, GiornoDella
Settimana, NumeroSettimana, Stagione. Una determinata istanza del modello OLAP includerebbe i valori
specifici per ogni livello della gerarchia. Un utente dei dati OLAP si sposterà verso l’alto o il basso (Drill
UP, Drill Down) di tale gerarchia per visualizzare i vari livelli dei dati e scegliere il livello di dettaglio delle
informazioni desiderato. I cubi, le dimensioni, le gerarchie e le misure sono gli elementi essenziali
dell’esplorazione multidimensionale OLAP. Grazie a questo modello di descrizione e presentazione dei
dati, gli utenti hanno la possibilità di esplorare in modo semplice e intuitivo un set di dati complesso.
Conclusioni
Abbiamo introdotto il concetto di data warehouse, lo strumento necessario all’azienda per accedere in
maniera tempestiva a informazioni di sintesi e di analisi dei dati, prodotti dai diversi sistemi gestionali.
