Data Warehouse

Nella piramide di Anthony per ora ci siamo occupati solo della parte operativa, parlando di basi di dati
relazionali e del modello relazionale, come interrogarlo con SQL, come creare un modello concettuale e
come trasformarlo in modello logico.
Adesso ci focalizziamo sui sistemi informativi decisionali (o direzionali), che supportano le altre due attività
della piramide di Anthony ovvero quello tattica e quella strategica. Con queste intendiamo tutte le attività
che non rientrano nel regime dell’organizzazione ma vengono scelte per guidare gli obiettivi
dell’organizzazione (apertura di una nuova sede, investimento su una tipologia di prodotto, gestione degli
ordini, delle vendite, dei salari ecc.).

I sistemi visti finora sono di tipo OLPT, ovvero On Line Transactional Processing, ovvero sistemi che
permettono di analizzare le transazioni. Per transazioni si intendono operazioni che si possono effettuare
nella nostra organizzazione e che possono essere salvate in una base di dati. Possono essere:
- Scambi di materiale tra l’organizzazione e l’esterno;
- Trasformazioni dei nostri beni, prodotti, risorse o materie prime che contribuiscono alla creazione
del prodotto o servizio;
- Spostamenti di oggetti fisici;
- Eventi registrati nell’organizzazione (emissione fattura, investimento in un prodotto).
Una transazione quindi mi modifica la mi base di dati e i sistemi di OLTP devono quindi essere in grado di
registrare velocemente tutte le transazioni poiché ne possono avvenire molte contemporaneamente. I
sistemi transazionali devono godere poi delle proprietà ACID per sostenere le transazioni:
- A = atomico: le operazioni che si verificano devono avere un inizio e una fine senza stati intermedi.
- C = consistente: lo stato del mio sistema dopo una transazione deve rimanere consistente, ovvero
aggiorno in modo opportuno tutti i record necessari in caso di aggiornamento di uno di questi.
- I = isolato: posso eseguire una transazione dopo l’altra, ma non devono impattare una con l’altra.
- D = durevole: lo stato di una transazione viene registrato e dura nel tempo in modo che posso
recuperare l’informazione.

I Data Warehouse non sono sistemi transazionali e riguardano le attività tattiche e strategiche. Non sono
OLTP ma sono sistemi OLAP (On Line Analitical Processing). Devono supportare una grande quantità di
informazioni anche storiche, non solo interne all’organizzazione ma anche esterne, in modo da essere
efficienti nel fornire le informazioni giuste agli operatori per prendere una decisione strategica giusta.
Il problema principale è quello di prendere decisioni complesse in un tempo limitato, facendo
interrogazioni che non sono prevedibili. Ogni volta le analisi e le decisioni sono diverse. Parliamo quindi in
questo ambito di Business Intelligence, ovvero strumenti che estrapolano informazioni da fonti diverse in
modo veloce ed efficace.

Inizialmente questo era possibile grazie all’esistenza di Report, ovvero documenti creati con una certa
cadenza che catturavano lo stato dell’organizzazione in qualche ambito in un determinato periodo di
tempo. La caratteristica è che hanno un formato prefissato e hanno scadenza regolare. Le limitazioni sono
nel fatto che i report includono dati statici, non modificabili, non aggiornabili se non con la creazione di un
nuovo report e, infine, il focus è solo interno all’organizzazione, non esterno.
Livello successivo è l’utilizzo di excel, che mi definisce analisi per ogni utente, eseguite al momento e quindi
più aggiornate rispetto ai report e sono più maneggiabili e modificabili. Le limitazioni le troviamo nella
difficoltà nell’estrarre informazioni dalle base di dati per poi salvarle nel foglio excel (poca efficienza).
Inoltre, i dati inseriti da ciascun utente potrebbero essere sbagliati e rilevare l’errore risulta poi molto
difficile.
L’ultimo livello sono proprio le DW, vere basi di dati organizzate per supportare le analisi da parte degli
utenti. Le DW contengono tutti e solo i dati di interesse per le analisi, integrano fonti diverse interne ed
esterne e mantengono i dati aggiornati.

Differenza tra DW e DB (database)

- Obiettivo: Il DW vuole identificare le problematiche, criticità e possibilità di crescita.
- Utenti: manager e dirigenti nel DW.
- Orizzonte temporale: dati storici (aggiornati) per prendere decisioni.
- Livello dettaglio: dati aggregati (es: mi interessa la media delle vendite di un mese).
- Accesso: operazioni solo in lettura

Il modello che utilizzerò per la creazione di DW è il modello multidimensionale, una struttura che permette
alla base di dati di semplificare le interrogazioni con l’obiettivo di supportare le analisi. Il modello che
utilizzo è l’Ipercubo in cui utilizzerò tre elementi: Dimensioni, Fatto, Misure.
Dimensioni corrispondono alle coordinate. L’incrocio delle coordinate corrisponde ad un elemento
dell’ipercubo che è il Fatto. Un’ipercubo è un insieme di elementi ed informazioni utili per la mia analisi (es:
vendite dell’organizzazione). L’analisi e quindi le dimensioni potrebbero corrispondere ad esempio ai
prodotti, al tempo e al negozio in cui ho effettuato le vendite. Le dimensioni possono essere n e devono
essere definite su valori discreti (devo poter dargli una coordinata) o devono essere discretizzate. Devono
inoltre essere organizzate in modo gerarchico e percorrendo la gerarchia avrò una relazione di dipendenza
funzionale. Ad esempio, avendo i prodotti, il tipo di prodotto e le categorie del tipo, avrò 1 prodotto per
ogni tipo, ma n tipi per ogni prodotto e in egual modo avrò 1 tipo per ogni categoria ma n categorie per
ogni tipo. Le misure, infine, sono un aspetto quantitativo relativo al fatto (nell’esempio il costo unitario del
prodotto o la quantità venduta i kg, litri ecc.).

Data Warehouse
Database che contiene dati sintetici, ovvero aggregati senza un livello di dettaglio finissimo, per catturare
solo l’informazione che serve per prendere le decisioni. Sono integrati e strutturati (secondo il modello
dell’ipercubo) ed è di interesse per il livello tattico e strategico dell’organizzazione.
Utilizzato per sistemi OLAP, sistemi che godono delle proprietà FASMI:
- F = fast, veloci: devo fare le mie interrogazioni in modo rapido (ma non nel tempo dei millisecondi);
- A = analitical: sono dati analitici, quindi sintetizzati con livelli di dettaglio basso, aggregazione dei
dati;
 - S = shared, condiviso: il data warehouse deve essere condiviso da utenti diversi, ma che possono
avere anche interessi diversi nell’accedere ai dati;
- M = multidimensional: perché si basa su un modello multidimensionale;
- I = integrated: perché i dati sono integrati da diverse sorgenti, resi poi consistenti tra di loro.

Architettura del data Warehouse

Il DW è organizzato come tante basi di dati organizzate a loro volta in modo gerarchico. Il primo livello
gerarchico sono le sorgenti costituite dalle basi di dati operative ed eventuali report prodotti
dall’organizzazione e i big data, ovvero dati raccolti in log (file di testo di grandi dimensioni) che vanno a
raccogliere informazioni riguardo l’organizzazione (es: amazon salva tutte le operazioni degli utenti che
entrano nel suo sistema, sia iscritto che no, salva le pagine visitate e info su come ha navigato all’interno
della pagina, e vengono utilizzate per fare analisi come prodotti correlati tra di loro).
Tutti questi dati sono interni, poi ci sono anche fonti esterne che possono essere altre basi di dati, altri
report o altri big data.
Questi dati vengono successivamente trasformati per creare il modello multidimensionale, utilizzando
alcune tecniche chiamate ETL, che mi creano poi il mio data warehouse. Il DW è accompagnato poi da altre
basi di dati chiamate Data Mart, che sono liste, ovvero estrazioni di informazioni dal DW (sottoinsiemi), per
ridurre la sua dimensione. Riduzione fatta in diverse dimensioni, in base all’analisi, alla granularità o
aggregazione, o in base alla data temporale. DW + DM costituisce il secondo livello.
L’ETL può utilizzare una base di dati, chiamata Staging Area, in questo caso essa corrisponderà al secondo
livello mentre il DW + DM sarà il terzo livello.
Per l’estrazione delle informazioni dal DW ci sono gli strumenti di analisi tra cui: il motore OLAP o dei report
creati a partire dal DW o dai DM, stessa cosa per il motore OLAP. Motore OLAP interrogato attraverso le
query o attraverso dei data mining.
Processo ETL
Il processo ETL è il processo che permette di prendere i dati contenuti nelle sorgenti (molto disaggregati),
manipolarli e metterli nel modello multidimensionale. Avviene il tutto in 3 diverse fasi:
- E = Estrazione (extraction)  Quali dati di interesse estrarre e come effettuare l’estrazione.
L’estrazione può essere effettuata in maniera statica, ovvero prendo tutti i dati delle mie sorgenti
ogni volta che devo aggiornare il mio data warehouse, oppure in modo incrementale dove
considero solamente i dati modificati dall’ultimo aggiornamento.
L’analisi statica è più facile, non faccio nessuna distinzione e non devo scegliere i dati da analizzare
e come fare l’aggiornamento. Devo però considerare una grande quantità di dati e quindi risulta più
lunga e più costosa. L’analisi incrementale più veloce ed efficiente, ma più complessa da progettare
e realizzare.
- T = Trasformazione (Transformation)  In questa fase mi occupo dell’eterogeneità dei dati, mi
occupo del fatto che le sorgenti sono diverse ed utilizzano quindi dati diversi, e li rendo omogenei.
Varie sottofasi: Pulizia, in cui rilevo gli errori presenti nei dati e li elimino il più possibile, infatti se i
dati non sono corretti gli algoritmi daranno sempre un risultato non corretto. Se mi mancano dati
posso fare una media tra quelli prima e quelli dopo, correggo valori inammissibili per la base di dati
e correggo l’inconsistenza ovvero la relazione errata tra due dati, ad esempio l’errata relazione tra
CAP e città.
Nella riconciliazione trova le corrispondenze tra elementi di basi di dati diverse che si riferiscono
però allo stesso oggetto.
Infine, vi è la standardizzazione dei formati, ovvero scelgo tra la congiunzione o lo spezzamento dei
campi (la data la rappresento unica o separo giorno/mese/anno?), e scelgo il formato in modo da
avere i dati, provenienti da sorgenti diverse, omogenei (numero decimale rappresentato in qualche
base di dati con 3 cifre, in altre con 2, scelgo se uno o l’altra oppure in altro modo).
- L = Loading  Carico i dati nel data warehouse strutturandoli secondo il modello
multidimensionale. Li rielaboro in modo che rispondano alle caratteristiche scelte per il modello
multidimensionale.

Modello concettuale DW
La progettazione di un data warehouse come insieme di dati multi-dimensionali passa attraverso una
progettazione di tipo concettuale, logica e fisica. Relativamente al primo aspetto, esistono divesi modelli
concettuali per rappresentare i sistemi multidimensionali. Quello più utilizzato è il Dimensional Fact Model
(DFM).
Nel DFM, il fatto è rappresentato come un rettangolo contenente le misure corrispondenti.
Le dimensioni sono invece rappresentate come cerchi etichettati collegati al fatto stesso. Le dimensioni
possono essere semplici attributi del fatto oppure delle gerarchie, rappresentate come alberi che hanno come
radici le dimensioni di base. Alcuni attributi delle gerarchie possono essere opzionali e questo viene indicato
nel DFM tramite una barra sulla linea corrispondente all’attributo.
Nell’esempio seguente il fatto è rappresentato dalla vendita che ha come misure la quantità venduta, il
valore unitario e l’eventuale sconto corrispondente. Il fatto è determinato poi da quattro dimensioni: la
data in cui la vendita è stata effettuata, il luogo in cui si è verificato il fatto, il prodotto oggetto della vendita
e il cliente. Ad ognuna di queste dimensioni è associata una gerarchia, attraverso la quale è possibile
effettuare analisi più o meno dettagliate sui fatti registrati nel data warehouse. L’attributo età per il cliente
è opzionale.
Il Data Warehouse però non sarà composto da un solo ipercubo, ma da tanti ipercubi, ognuno in grado di
modellare le dimensioni relative ad un fatto di interesse per l’analisi. Per ognuno di questi ipercubi sarà
quindi modellato un DFM, con la definizione del fatto, delle misure, delle dimensioni e delle loro gerarchie.
Modelli logici
- MOLAP (Multidimensional OLAP) = Traduce il DFM in un DB multidimensionale con operazioni
multidimensionali. Ovvero, manteniamo il modello così come lo abbiamo rappresentato, da
modello concettuale multidimensionale a modello logico multidimensionale. Il vantaggio è che c’è
una perfetta aderenza con il modello concettuale e sfruttando le caratteristiche del modello
multidimensionale, le interrogazioni sono più efficienti.
Tra gli svantaggi troviamo che sono strumenti poco diffusi e non sono standardizzati. Inoltre, lo
spazio occupato rappresenta uno svantaggio poiché una buona parte di memoria viene occupata
anche se non utilizzata, in quanto alloco lo spazio per ogni combinazione possibile delle dimensioni.
- ROLAP (Relational OLAP) = Traduce il DFM con un modello relazionale e per le interrogazioni
utilizzo il motore SQL. Vantaggi e svantaggi speculari dal precedente, gli strumenti sono ben noti e
standard, più facile che in azienda ci siano competenze per poterlo utilizzare. Lo spazio occupato è
solo quello dei dati che effettivamente utilizzo.
Con questi due metodi posso trasformare il modello multidimensionale DFM in un modello logico
ROLAP:
Schema a stella utilizzo una tabella per rappresentare il fatto e una tabella per ogni dimensione.
All’interno delle tabelle avrò i dati non solo del livello gerarchico più vicino al fatto, ma anche tutte
le altre. Vantaggio dello schema a stella è che è uno schema molto semplice, riduco la difficoltà
delle interrogazioni che saranno un semplice join tra due tabelle. Lo svantaggio è che perdo tutte le
informazioni sulle gerarchie in quanto vengono tutte compresse in una tabella.
Schema a fiocco di neve, utilizzo una tabella per il fatto con le sue misure all’interno, ma utilizzo più
tabelle per rappresentare le dimensioni in base a quali sono le gerarchie che voglio mettere in
evidenza. Vantaggio è quindi che rimango più aderente al modello concettuale mantenendo
qualche gerarchia, ma è un modello meno efficiente in quanto sono più complesse le
interrogazioni. Tra gli svantaggi ho il fatto che le interrogazioni sono meno efficienti e non è
aderente al modello concettuale e devo quindi rielaborare il modello per renderlo un modello
relazionale.
 - HOLAP (Hybrid OLAP) = Utilizzo entrambe le soluzioni, sia modello relazionale sia modello
multidimensionale. Il primo viene utilizzato per i Data Warehouse, il secondo viene utilizzato per i
Data Mart. Il modello relazionale mi permette di ridurre il volume dell’aggregato di informazioni,
mentre il modello multidimensionale per i DM mi permette di avere comunque un volume
contenuto in quanto i DM sono già contenuti di principio, e a questi posso avere un’aderenza
completa tra modello concettuale e modello logico.

Operatori OLAP
Come interrogo il Data Warehouse? Quali sono gli operatori che posso utilizzare? Utilizzando il motore
OLAP proseguo in questo modo: per fare un’analisi, gli utenti formulano un’ipotesi e fanno
un’interrogazione applicando un operatore OLAP, ottenendo dei dati. Ritaglio i fatti sulla base di come
definisco le dimensioni. Dopo di che effettuo un raffinamento dei dati ottenuti, definisco come voglio
cambiare l’interrogazione e applico un altro operatore. Questo viene ripetuto continuamente fino a quando
non ottengo tutte le informazioni che mi servono. Gli operatori OLAP che posso applicare sono quattro e
agiscono tutti sulle dimensioni del modello multidimensionale:
- Drill Down: aumento il dettaglio (approfondisco, scavo), ovvero passo da un livello gerarchico più
astratto ad un altro più dettagliato.
- Roll Up: diminuisco il dettaglio e quindi aggrego su una dimensione.
- Slice: ritaglio una fetta dell’ipercubo fissando un valore per una specifica dimensione.
- Dice: definisce un intervallo di valori su più dimensioni.