Verso la metà degli anni 90 si è incominciato a sentir parlare di "Data Warehouse".
In quegl'anni si è cercato di studiare un sistema efficiente per fornire ai dirigenti aziendali uno strumento idoneo ad eseguire valutazioni sull'insieme dei dati archiviati nei vari databases presenti nelle aziende stesse.

L'obiettivo era senz'altro ambizioso: occorreva ideare un sistema di interrogazione di dati sufficientemente flessibile per essere utilizzato da chi non era un professionista del settore, ma anche sufficientemente potente da permettere elaborazioni complesse in tempi brevi.

I database relazionali rappresentavano la soluzione ideale per l'archiviazione delle informazioni ma erano spesso organizzati in maniera disomogenea nei vari dipartimenti creando non poche difficoltà al momento dell'aggregazione ad opera di chi, ad esempio, voleva confrontare i dati provenienti dal settore "vendite" con quelli del settore "produzione". A volte, per giunta, i databases venivano implementati con diversi strumenti (IBM Db2, Oracle, Informix, Sybase ) di diversi produttori aggiungendo il problema di coordinare team con specializzazioni diverse.

Una soluzione era quella di convogliare tutte queste fonti di informazione in un unico database, una sorta di magazzino centrale di dati approvvigionato periodicamente sul quale effettuare le interrogazioni: il Data-Warehouse (d'ora in avanti DWH).

Fu così, che a fronte dei tradizionali sistemi O.L.T.P. (On-Line Transactional Processing), sistemi per la gestione dati basati sulle transazioni, come i Relational Database Management Systems (RDBMS), videro la luce i primi O.L.A.P. (On-Line Analytical Processing), sistemi idonei alla gestione e all'interrogazione di detti DWH.

Per meglio comprenderne i concetti sarà meglio costruirci uno scenario di esempio.
Immaginiamo quindi la situazione di una ipotetica ditta di trasporti di prodotti agroalimentari: la "Ortofrutta Express". Mettendoci ora nei panni di un dirigente di tale azienda che voglia ottimizzare la logistica ci troveremo di fronte al problema di confrontare i dati della produzione nazionale con quelli del consumo. Inoltre ci può interessare focalizzare la nostra attenzione sui dati a differenti livelli di aggregazione, per comune piuttosto che per provincia o regione, per l'insieme dei prodotti oppure per solo alcuni di essi per mese o per quadrimestre e magari una combinazione di tutti questi fattori.

Tali analisi, nell'ottica di un RDBMS tradizionale, richiederebbe la preparazione di diverse views, una per ciascuna elaborazione richiesta sui dati a seconda dei parametri di aggregazione prescelti. A meno che noi, sempre nei panni del nostro dirigente, non abbiamo anche sufficienti competenze di programmazione, dovremo di volta in volta rivolgerci ad un tecnico per farci produrre i rapporti desiderati. Finalmente dopo anni di perdite di tempo decidiamo di investire nella realizzazione di un DWH nel quale far confluire i dati della produzione con quelli delle vendite per poi analizzarli con un sistema OLAP fra quelli offerti dal mercato.

Una volta acquisiti gli strumenti idonei occorrerà, come prescritto dalla "dottrina" dei DWH, progettare il nostro "Star Schema" (letteralmente "diagramma a stella"). Lo star-schema è lo schema delle tabelle e relative relazioni alla base del nostro DWH ed è così chiamato per la sua forma "a stella". Si tratta di un Entity-Relationship Diagram composto da una tabella centrale, detta "Fact-Table" che conterrà le informazioni chiave del nostro sistema (quantità prodotta, quantità venduta.), e diverse tabelle, dette "Dimension-Table" che conterranno i parametri che abbiamo già evidenziato precedentemente (tempo, luogo prodotto.), ciascuna collegata da almeno una relazione con la fact-table. Questo spiega il perché il DWH è spesso noto col nome di database "multidimensionale".

Le tabelle di dimensione ("dimension table") sono così chiamate perché in esse sono elencati l'insieme dei parametri che influenzano il dato vero e proprio. Nel nostro esempio le vendite o la produzione della merce varia in funzione di tempo, luogo e prodotto. Il criterio da tener presente nella progettazione di queste tabelle di dimensione è di denormalizzarle fortemente. Questo processo di denormalizzazione consentirà di effettuare rapide aggregazioni a seconda della "granularità" o del dettaglio richiesto; è ben noto, infatti, che malgrado la teoria degli RDBMS prescriva, con le sue forme normali, una forte normalizzazione, questo si scontra troppo spesso con la dura realtà delle scarse performance. Riassumendo possiamo considerare la frase seguente come "motto" dei DWH: "Ridondante ma veloce!" In particolare lo strumento OLAP permetterà di "scorrere" da un livello ad un altro (auspicabilmente) in tempo reale: tale processo prende il nome di "drilling" (dall'inglese "to drill" che significa perforare - andare più o meno a fondo .)

Un'altra caratteristica interessante è quella di poter effettuare il drilling su diverse "gerarchie" definite per la dimensione interessata. Prendendo il caso della dimensione "tempo" ad esempio, potremo scegliere di scorrere secondo il criterio "giorno della settimana (Lun, Mar, .) - settimana - mese - trimestre - anno" piuttosto che secondo il criterio "giorno dell'anno - settimana - mese - bimestre - trimestre - quadrimestre - semestre - anno" come descritto nella figura seguente.

Unico prerequisito sarà quello di aver preimpostato le opportune gerarchie: sarà ancora una volta il tool di OLAP a gestire l'elaborazione..

Per avere il nostro report, a questo punto, non dovremo far altro che selezionare il livello di dettaglio desiderato per ogni dimensione.

La "Fact table", di contro, è così chiamata perché contiene il dato fondamentale del nostro sistema.
Ciascun record sarà "posizionato nella nostra griglia multidimensionale" grazie alle chiavi esterne come sintetizzato dallo schema seguente.

Una variante dello "Star schema" è lo "Snowflake schema" ovvero il diagramma a "fiocco di neve".
Si tratta semplicemente di uno Star schema nel quale per particolari motivi si è scelto di normalizzare una dimensione. Nel nostro esempio potremo scegliere di realizzare una tabella di regioni in relazione uno-a-molti con una tabella di provincie a sua volta in relazione uno-a-molti con la tabella dei comuni. I motivi per optare per tale scelta sono strettamente legati alla realtà del sistema e non è possibile stabilire un criterio generico; va però ricordato che normalizzare significa introdurre relazioni con conseguente aumento di "join" durante l'interrogazione dei dati, cosa che può influenzare negativamente le prestazioni.

A questo punto non ci resta che passare all'azione e predisporre il "pozzo di dati" nel quale far confluire le nostre informazioni. Tale processo prende il nome di ETL: acronimo di "Extract Transform & Load".

Il primo passo consiste appunto nell'estrarre i dati dalle sorgenti disponibili:
i dati degli acquisti dal database del "dipartimento acquisti", magari passando da un "flat file" (file di testo formattato) i dati delle vendite mediante collegamento con l'ISTAT ecc. ecc...

Il secondo passo, quello più difficile, consiste nel trasformare i dati estratti per adattarli allo schema del nostro DWH. Questo è il processo più delicato sul quale si infrangono la maggior parte dei progetti di Data-Warehousing. E' infatti raro ricorrere ad un semplice "remapping" dei dati: spesso i diversi dipartimenti hanno progettato in maniera autonoma i loro databases, scegliendo magari diverse chiavi per rappresentare le medesime informazioni. Nella peggiore delle ipotesi invece i dati sono stati mappati in modi completamente diversi e necessitano quindi di un complesso processo di trasformazione che non sempre risulta possibile. Tanto per fare un esempio c'e chi avrà scelto come chiave primaria per le provincie la coppia di caratteri della sigla automobilistica mentre qualcun altro avrà preferito usare il codice numerico ISTAT..

L'ultimo passo è quello di effettuare il caricamento dei dati ottenuti dal precedente processo di trasformazione nel nostro DWH operazione, questa, che non dovrebbe presentare difficoltà particolari.

E' importante constatare che per la sua stessa natura un DWH non è mai aggiornato in tempo reale in quanto l'intero processo ETL richiede un certo tempo e va pianificato con cura. Non possiamo ad esempio effettuarlo al variare dei dati di origine pena la monopolizzazione del nostro Database Server da parte dello stesso processo ETL. A qual scopo avere un database perfettamente aggiornato se è inutilizzabile a causa della sua lentezza? Generalmente si sceglie la notte come momento ideale per il processo ETL consentendo quindi di operare su dati "freschi di giornata" ma talvolta il processo risulta talmente lungo da richiedere giorni costringendo a "schedularlo" con cadenza settimanale o mensile. Tutto ovviamente dipende dalla complessità del sistema.

Al giorno d'oggi, gli RDBMS presenti sul mercato, presentano tutti delle implementazioni volte a rendere più efficienti i DWH, come ad esempio le "Materialized Views" (delle specie di Query pre-eseguite e mantenute automaticamente aggiornate dall'engine), e diversi Vendors promuovono i loro tools per la modellazione dei Data Warehouse o per l'OLAP. Come sempre questi tools sono in continua evoluzione ma non possono da soli garantire la riuscita di un progetto di Data-Warehousing. Una buona analisi preceduta da una attenta valutazione delle criticità della disomogeneità dei sistemi da "mettere d'accordo" sono alla base di una corretta progettazione.

Buon Data-Warehousing a tutti!