I Data Warehouse

I Data Warehouse: un'introduzione

Il termine Data Warehouse e' ormai entrato nel vocabolario di tutti i responsabili dei sistemi informativi ed in quello degli amministratori di basi dati(DBAs: DataBase Administrators). Ogni sistema informativo di discrete dimensioni contiene al suo interno un Data Warehouse o, almeno, ne applica alcune delle tecniche e gli strumenti.

Ma cos'e' un Data WareHouse (DWH)?
Il DWH e' una base dati che mantiene tutte le informazioni sulle attivita' dell'azienda e che viene utilizzata dal management per prendere decisioni strategiche.

Da dove provengono i dati del DWH?
Dai sistemi informativi dell'azienda. I dati vengono semplicemente raccolti ed inseriti nel data warehouse con programmi di caricamento. Quindi vengono acceduti con programmi di analisi dei dati o ribaltati su DB specializzati (Data Mart)

Chi ha inventato i DWH?
I sistemi EIS (Enterprise Information System), MIS (Management Information System), DSS (Decision Support System), OLAP (OnLine Analytical Processing), ... sono sempre esistiti. E lo stesso vale per la denormalizzazione, le time-series, l'analisi multimensionale, i VLDBMS (Very Large Database Management System), ... Non c'e' nulla di particolarmente nuovo o innovativo nei DWH.
W.H.Inmon e' tuttavia considerato il padre dei DWH. Infatti ne ha coniato il termine, ha scritto diversi libri, ha fatto un mucchio di conferenze e, beato lui, di soldi! Il suo merito e' soprattutto quello di aver raccolto in una concezione unica una serie di concetti e strumenti gia' noti e sfruttati in modo singolo.

Ma perche' tutte queste sigle?
Perche' gli americani ne vanno pazzi!! Ma anche perche' nello strano mondo dei DWH sono molto usate per nascondere cose in realta' piuttosto semplici e logiche. Quindi meglio farci l'abitudine da subito...

I sistemi adatti ad ospitare un DWH sono ora meno costosi, le tecniche per disegnarli/implementarli si sono ormai affinate, il mercato dei DWH si e' allargato ed ora anche aziende medie o piccole possono sfruttarne i vantaggi. Quindi la diffusione dei DWH e' sempre maggiore.

Per un informatico e' pertanto importante conoscere i principali elementi dei DWH poiche' se li conosci li ... implementi.
Per un commerciale e' invece importante conoscere i principali elementi dei DWH poiche' se li conosci li ... vendi!.

I capitoli che seguono possono sembrare a prima vista scritti da uno schizzofrenico. Infatti presentano piu' o meno le stesse cose da punti di vista diversi. In realta' questo e' normale per un DWH: si chiama analisi multidimensionale!

Disegno di un Data WareHouse

Le normali tecniche di disegno delle basi dati non sono applicabili nel disegno del DWH. Il DWH e' una base dati ma non una base dati operazionale (OLTP: OnLine Transaction Processing). Quindi vi sono parecchie differenze come riportato nel seguito:

I dati di un DWH sono caricati da sistemi operazionali esterni. Il disegno dei dati, delle loro origini e mappature sul DWH viene chiamato Meta Database.
Un DWH viene utilizzato in sola lettura. Normalizzare i dati non e' necessario, al contrario, denormalizzando si possono evitare join tra tabelle.
Spesso il disegno si riduce ad una sola tabella detta fact table su cui vengono eseguite le query. Se vi sono tabelle di corredo (eg. decodifica dati) le query vengono indicate con il termine star query. In ogni caso il numero delle fact table e' basso.
Un DataMart (DM) e' un sottoinsieme del DWH che contiene solo una visione dei dati utile ad una determinata applicazione verticale (o ad un gruppo di esse). Il DM puo' avere una struttura ed, eventualmente, adottare una tecnologia differente dal DWH.
Dal punto di vista di disegno concettuale i diagrammi ER (Entity Relationship) non sono molto adatti ai DWH. Spesso si preferiscono gli schemi a stella che mostrano le diverse dimensioni di analisi sulle fact table (e sono anche comprensibili all'utente).
Il tempo e' una dimensione fondamentale e spesso e' presente anche il futuro (con budget e forecast). Nel disegno va considerato attentamente.
I volumi sono sempre molto elevati e spesso gli accessi richiedono l'intera lettura di tabelle di notevoli dimensioni. Vanno adeguatamente sfruttate le piu' recenti tecniche HW/SW per rendere veloci gli accessi: dischi in RAID, controller specializzati per l'I/O, parallel query, ottimizzatori cost based, cash enormi, ... Il supporto delle diverse tecniche sono definite dai produttori di RDBMS come il supporto ai VLDBMS.
L'utilizzo di tabelle di aggregazione, query lanciate a tempo, tabelle con risultati parziali precostituite, ... sono tecniche da sfruttare pesantemente e senza preoccuparsi di ridondanze sui dati.
Il tipo di selezioni effettuate e la frequenza sono spesso difficili da definire. Per tanto il numero di indici e' spesso molto elevato per offrire buoni tempi di risposta in tutte le condizioni. Di frequente le aree per i temporanei e per gli indici sono notevolmente piu' ampie di quelle dei dati.
Se una specifica applicazione o uno specifico strumento richiedono una determinata struttura dati, indici, estrazioni, ... non si cerca di integrarla con il DWH ma si crea un DataMart ottimizzato per tale specifica esigenza. Il DataMart sara' popolato estraendo i dati di interesse dal DWH con le stesse tecniche adottate per popolare il DWH.

I DataWare House e lo spazio-tempo

Lo spazio ed il tempo sono due elementi importantissimi per i DWH.

Il tempo

Vengono eseguiti ad intervalli temporali prefissati i diversi caricamenti ed aggiornamenti di dati del DWH. Tali periodicita' diventano una caratteristica molto importante del DWH per i forti impatti tecnici ed organizzativi che comportano.
Il tempo e' una dimensione di analisi molto importante. Se su un sistema operazionale e' importante sapere qual e' fatturato, sul suo DWH sara' importante conoscere il fatturato ad una certa data o su una certa serie di date.
I tempi di caricamento/aggiornamento dei dati debbono essere limitati in modo da consentire aggiornamenti frequenti senza ridurre la fruibilita' del sistema.
I tempi di risposta delle applicazioni debbono essere i piu' ridotti possibile. E' vero che per altre applicazioni sarebbe accettabile che un report, che richiede una query complessa o che accede a milioni di dati, possa richiedere minuti o ore di elaborazione. Su un DWH tali tempi debbono essere drasticamente ridotti.
Il tempo di inserimento di nuove funzionalita'/dimensioni di analisi deve essere limitato in modo da riuscire a seguire in modo flessibile le nuove esigenze di analisi dati.

Lo spazio

Poiche' il DWH riporta tutti i dati dell'azienda le dimensioni sono elevate. Per gli spazi di un DWH spesso si parla di Terabyte.
Spesso vengono sottovalutati diversi spazi che sono comunque necessari: aree temporanee per il trasferimento/correzione/caricamento dati, aree per i sort (siano essere interne alle basi dati che sul sistema operativo), aree per indici e strutture di accesso ai dati (la valutazione per eccesso di 50% e 50% tipica degli operazionali non e' sufficiente).
Per ottimizzare le prestazioni spesso sono necessari compromessi con gli spazi. Un dataMart ottimizzato per gli accessi di una specifica applicazione richiede spazi ulteriori, un nuovo indice richiede spazio, ...

Lo spazio-tempo

Non c'e' bisogno di essere Einstein per capire che vi sono strette relazioni nell'universo dei Data Warehouse sulle dimensioni spazio-temporali! Per avere dei tempi di risposta per le applicazioni ed i tools che operano su enormi DWH si possono utilizzare tecniche di ricerche ad indice, pre-calcolo dei risultati, definizione di tabelle pre-aggregate, denormalizzazione spinta, ... Tutte queste tecniche richiedono ovviamente grandi quantita' di spazio!
Se si comprime si riduce lo spazio ma di converso si aumenta il tempo necessario per estrarre le informazioni: ancora un legame spazio-tempo.
Una verita' lapalissiana sulle relazioni spazio-temporali dei DWH: se si vogliono mantenere i dati per un tempo maggiore, c'e' bisogno di piu' spazio. C'e' un pericoloso corollario: se si vogliono mantenere i dati per un tempo indefinito, occorrera' uno spazio infinito!

DataWare House: vero o falso

Un DWH e':

In sola lettura: il DWH non viene utilizzato per transazioni on-line. I caricamenti avvengono periodicamente attingendo dai legacy, le attivita' svolte sul DWH sono di sola lettura
Completo: rappresenta tutte le attivita' strategiche dell'azienda.
Costoso: il costo non deve rappresentare un problema per il DWH. I suoi utenti sono lo staff dirigenziale, e' utilizzato per le scelte di strategia dell'azienda, rappresenta tutta l'azienda...
In continua evoluzione: le aziende variano continuamente linee di business, struttura, ... Il DWH deve essere in grado di seguire il continuo aggiornamento dell'azienda

Un DWH NON e':

Normalizzato: non serve normalizzare i dati ed e' inefficiente nelle ricerche
Aggiornato on-line: sono i sistemi informativi operativi che sono mantenuti in on-line. Il DWH viene aggiornato con procedure di allineamento a tempo (mensili, settimanali, giornaliere) attingendo i dati dalle diverse sorgenti.
ACIDo: un DWH non ha i requisiti stringenti di un OLTP sulle transazioni (il classico ACID). E' importante la coerenza logica dei dati ma i caricamenti generalmente possono essere rieseguiti e trattano i record in batch.

Stategia e tattica

Nell'arte della guerra, nel gioco degli scacchi e con i DWH sono importanti sia la strategia che la tattica. Non saprei dire se i DWH sono piu' vicini al gioco degli scacchi o ad una guerra. Certo che anche con i DWH si combattono molte battaglie!

Strategia:

Il DWH e' uno strumento strategico dell'azienda.
Il DWH deve essere appoggiato dal management dell'azienda.
Vi deve essere un capo progetto per il DWH con ampio mandato. Alcuni punti sono fondamentali per il capo progetto: acquisto HW/SW, definizione dei dati aziendali, definizione delle priorita' sui diversi progetti.
Il primo risultato da raggiungere assolutamente e' la definizione dei dati aziendali
Alcuni requisiti del DWH sono imprescindibili. Se l'utente non e' d'accordo bisogna far cambiare idea all'utente!
Il DWH non deve diventare un banale sistema di reportistica.

Tattica:

Il DWH deve fornire risposte in tempi brevi. I diversi progetti (eg. un Datamart sui dati di produzione, ...) debbono terminare il loro ciclo di sviluppo in pochi giorni o, al massimo, alcuni mesi.
Spesso conviene approcciare un DWH partendo da un Data Mart specifico
L'utilizzo di prototipi e di strumenti ad elevata produttivita' e' spesso una necessita'.
Il team di progetto e supporto del DWH deve essere flessibile e motivato
E' opportuno il coinvolgimento dei diversi rami e delle diverse funzioni aziendali. Tutti debbono sentirsi coinvolti nel progetto e portare informazioni.

Attivita' sui dati e strumenti

Le attivita' che si possono svolgere sui dati del dataware house sono molteplici. Quando si opera con basi dati di notevoli dimensioni e' tuttavia necessario utilizzare gli strumenti adeguati. I produttori di SW hanno gia' messo a disposizione parecchi programmi che coprono le diverse necessita' dei DWH. Attivita' tipiche:

DBMS: la scelta del DBMS e' strategica per il progetto DWH. Tutti gli attuali DBMS hanno introdotto funzionalita' che vanno incontro alle esigenze dei DWH. Una tra tutte: le dimensioni enormi del DB e delle tabelle in esso contenute.
Trasferimento/conversione/caricamento dati: gli strumenti di trasferimento, conversione e caricamento dei dati sono fondamentali. Spesso tali strumenti sono in grado di generare codice sorgente (eventualmente "personalizzabile") per le diverse esigenze di caricamento dati.
Quando si tratta di uno strumento integrato lo si definisce un ETL o un ETTL (Extraction, [Transport,] Transformation and Loading).
Data mining: strumenti che consentono ricerche puntuali sui dati per "scovare" anomalie, inefficienze, opportunita' commerciali, ...
Elaborazioni statistiche: il punto e' un po' generale tuttavia in diverse attivita' sono necessari strumenti statistici evoluti.
Report: sono necessari strumenti per la costruzione di report che possano essere utilizzati direttamente dagli utenti
Analisi multidimensionale: strumenti di analisi che consentono di "navigare" sui dati come se si trattasse di tabelle multidimensionali e sfruttano le semplici operazioni di "drill-down" e "drill-up"

Testo: Data Warehouse: un'introduzione
Data: 17 Luglio 1999
Versione: 1.0.5
Autore: mail@meo.bogliolo.name