© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Facoltà Ingegneria
Il Data WarehouseIl Data Warehouse
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Presentazione
• Michele Riccio
• Laureato in Ingegneria Elettronica
• Lavoro da circa 6 anni come progettista di Data Warehouse
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Architettura a due livelli
Data Marts
Sorgenti
Estrazione
Aggregazione
Loading
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Problemi dell’architettura a 2 livelli
• Per ogni Data Mart: – va rifatta l’analisi per la riconciliazione– vanno riscritti i programmi di trasformazione e
caricamento dei dati (ETL)– vanno parzialmente duplicati i dati
• La gestione dei dati non è centralizzata =>– possibile una duplicazione dei dati incontrollata– analoghi requisiti utente possono portare a più
Data Mart simili e ridondanti
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Architettura a tre livelli- Enterprise Data Warehouse -
Livello derivato
Livello riconciliato
Livello sorgente
Secondario 1
Front End 1Front End 1
Primario
Secondario 2
Front End 2Front End 2
Sorgente 2 Sorgente 1 Sorgente 3
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Enterprise Data Warehouse
• Per aziende di complessità e dimensioni rilevanti
• Obiettivo:– Una visione univoca e centralizzata
dell’intera azienda
=> un’unica struttura di Data Warehouse per l’intera azienda
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Vantaggi livello Riconciliato
• descrizione unica e completa di tutta l’azienda
• sorgente per i dati derivati affidabile• la Riconciliazione viene separata da Subject
orientation e Aggregazione• si riducono al minimo le modifiche sul Data
Warehouse per nuove sorgenti operazionali • processo ETL viene svolto una volta sola• Riconciliazione viene svolta una volta sola
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Riconciliazione
Cleaning
Storicizzazione
Subject orientation
Aggregazione
Riconciliazione
Cleaning
Storicizzazione
Subject orientation
Aggregazione
Progetto di un Data Warehouse a 2 livelli
DB2
ORACLE
Altre Fonti
Sorgenti Eterogenee
Data Warehouse
(insieme di Data Mart)
DB
A partire dall’analisi dei processi aziendali e dei dati presenti nei sistemi già esistenti in azienda, vengono
creati gli oggetti di business da inserire nel Data Warehouse.
Datawarehousing:
Metadati
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Riconciliazione
Cleaning
Storicizzazione
Riconciliazione
Cleaning
Storicizzazione
Progetto di un Data Warehouse a 3 livelli
DB2
ORACLE
Altre Fonti
Sorgenti Eterogenee
Primario del
Data Warehouse
BDW
A partire dall’analisi dei processi aziendali e dei dati presenti nei sistemi già esistenti in azienda, vengono
creati gli oggetti di business da inserire nel Data Warehouse.
Datawarehousing:
Metadati
BIWAggregazione
Subject Orientation
Aggregazione
Subject Orientation
Data Mart
Livello riconciliato
Livello derivato
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Qual è l’architettura migliore ?
• L’architettura migliore, in generale, non esiste
• Vanno valutati, caso per caso:– numero DM, presenti e futuri, e loro intersezioni– numero di sorgenti da riconciliare – complessità e tempi per creare un unico
modello aziendale– realizzabilità “politica” di un progetto
riguardante l’intera azienda
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
DW per livelli di astrazione
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Progettazione del Data Warehouse
• Un DW si realizza sempre a segmenti, mai in una volta sola.
• Il primo segmento deve– contenere gli aspetti più significativi– ma non avere grosse difficoltà realizzative
• In seguito si estenderà il DW con altri aspetti
• E’ un procedimento iterativo
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Approccio a segmenti
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Progettazione del Data Warehouse
• Individuazione, analisi e riconciliazione delle sorgenti
• Definizione delle corrispondenze e delle trasformazioni tra sorgenti e Data Warehouse
• Analisi requisiti utente• Scelta della granularità e della politica di
refresh del DW• Progettazione dei Data Mart• Scelta dell’interfaccia utente e
caratteristiche della reportistica
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Relazioni secondo Designer
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Dal livello concettuale al logico
Entità con chiave propria Tabella Entità con chiave esterna Tabella con chiave contenente la
chiave della entità identificante Relazione molti a molti Tabella con chiave composta dalle
chiavi delle entità coinvolte Relazione uno a molti La tabella rappresentante l’entità con
cardinalità massima 1 ingloba la chiave dell’altra entità tra i suoi attributi (oltre agli eventuali attributi della relazione)
Relazione uno a uno Come il caso precedente ma si può scegliere a quale tabella far rappresentare la relazione (facendo attenzione alle cardinalità minime pari a uno)
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Reverse Engineering- dal logico al concettuale -
Tabella la cui chiave non contienechiavi di altre tabelle
Entità
Tabella la cui chiave contiene chiavi dialtre tabelle
Entità con identificatoreesterno
Tabella la cui chiave è dataunicamente dalla concatenazione dichiavi di altre tabelle
Relazione (prob. con card.(1,N))
Vincolo di riferimento (cioè altrilegami tra campi di tabelle differenti)
Relazione
Se un campo di riferimento per una relazione è not nullcardinalità minima 1 altrimenti 0
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Metodologia di riconciliazione
• La riconciliazione frequentemente è fatta solo a livello logico o logico-fisico– questo comporta molti errori di progettazione
e nell’interpretazione dei dati
• Secondo questa metodologia viene svolta a livello concettuale.
• L’integrazione a livello logico e fisico diviene una conseguenza del livello concettuale.
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Metodologia di riconciliazione
• Enterprise Model:
E’ il modello concettuale di tutta la realtà che il Data Warehouse dovrà rappresentare.
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Metodologia di riconciliazione
• Elaborazione prima versione Enterprise Model– basata su interviste
• Per ogni sorgente Reverse engineering:– Si ottiene il modello concettuale della sorgente– Il modello concettuale di ogni sorgente deve
rappresentare una visione parziale dell’intera realtà d’interesse
– Si generalizza l’Enterprise Model per tener conto della sorgente
=>Enterprise Model complessivo (fino ad ora)
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Metodologia di riconciliazione
• Scelta sull’Enterprise model dei concetti che si vuole implementare nel DW
• Ricostruzione delle corrispondenze tra concetti delle sorgenti e DW
• Risultato finale: Conceptual Data Warehouse
Model
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Metodologia di riconciliazione
• Il Conceptual Data Warehouse Model– è il modello concettuale dei dati che
andranno inseriti nel DW– contiene inoltre il legame tra i concetti delle
sorgenti e quelli del DW– è la traccia per le successive fasi di sviluppo
• Si ripete il processo di riconciliazione sui livelli di astrazione più bassi (logico e fisico)– con un dettaglio sempre maggiore – fino all’implementazione
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Reverse Engineering
• Dobbiamo acquisire:– Descrizione della sorgente e del suo
funzionamento operazionale– Descrizione dei campi, della loro semantica, delle
codifiche, dei valori ammissibili e del loro significato
• Produciamo lo schema logico della sorgente• Elaboriamo lo schema concettuale sorgente:
– basandoci sull’Enterprise Model – o generalizzandolo
l’Enterprise Model generalizza sempre i concetti sorgente
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Costruzione Enterprise Model
ReverseEngineering
ReverseEngineering
ReverseEngineering
ReverseEngineering
EM0
CM S1
SnSi+1S2S1
EMn-1EMi+1EMiEM2EM1 EMn
CM Sn
CM Si+1CM S2
dove:
EM0 Enterprise Model iniziale EMn Enterprise Model finale
CM Si Modello concettuale sorgente i-ma Si Sorgente i-ma
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Costruzione Enterprise Model
ReverseEngineering
ReverseEngineering
ReverseEngineering
ReverseEngineering
Sintesi e
omogeneizzazioneEM0
S1
S2
Si+1
Sn
CM S1
CM S2
CM Si+1
CM Sn
EM1
EM2
EMi+
1
EM finale
EMn
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Documentazione per ogni sorgente
• Descrizione fisica• Descrizione semantica• Descrizione logica• Modello concettuale (dal reverse engineering)• Corrispondenze tra livello concettuale e
logico• Legami tra modello concettuale della
sorgente ed Enterprise Model (rappresentati nel Conceptual DW Model)
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Esempio - Azienda commerciale
• DB ordini merci:– Clienti(cod_cli, CF, denom, indirizzo)– Ordini(num_ord, cod_cli, data)– Voci_ord(num_ord, cod_prod, nome, quant)
• DB fatturazione:– Clienti(cod_cli, CF, rag_soc, indirizzo)– Fatture(cod_fatt, num_ord, cod_cli, data,
nn_giorni_pag, importo)
• data e indirizzo sono gli stessi ?• denom=rag_soc ?
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Esempio - Azienda commerciale
Cliente Ordine Prodottoesegue richiede(1,N) (1,N) (1,N)
Cod_clidenom CF
indirizzo num_ord quantdata
(1,1)
cod_prod nome
S1 - Sorgente DB Ordini
S2 - Sorgente DB Fatturazione
Cliente(1,N)
Cod_clirag_soc CF
indirizzo Cod_fatt num_ord data
(1,1)inviata a
nn_giorni_pag
importo
Fattura
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Esempio - Azienda commerciale
Ordineesegue richiede(0,N) (1,N) (0,N)
Cod_cliragione_sociale CF
indirizzo sede legale
ID_ord quantitàdata_ordine
(1,1)
Enterprise Model
indirizzo spedizione merce
(0,N)
ID_fatt importo data_emissione
(1,1)inviata a
data_scadenza
Cliente
Fattura(1,1)
fatturato da
(1,1)
ID_prod nome
Cod_prodProdotto
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Esempio - Azienda commerciale
Ordineesegue richiede(0,N) (1,N) (0,N)
Cod_cliragione_sociale CF
indirizzo sede legale
ID_ord quantitàdata_ordine
(1,1)
ID_prod nome
Conceptual DW Model
(0,N)
ID_fatt importo data_emissione
(1,1)inviata a
data_scadenza
Cliente
Fattura(1,1)
fatturato da
(1,1)indirizzo spedizione merce
S1.Cliente.indirizzo
S1.Cliente
S2.Cliente
S2.Cliente.rag_soc
S2.Fattura.data
S2.Fattura.data+S2.Fattura.nn_giorni_pag
S1.Ordine.data
?
Cod_prodProdotto
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Vantaggi della riconciliazione concettuale
• Aver eseguito la riconciliazione sul livello concettuale ha permesso di:– individuare e risolvere meglio i problemi di
integrazione– avere una rappresentazione unica di tutta la
realtà d’interesse– sapere come i concetti usati dalle sorgenti si
inquadrano nella realtà d’interesse– avere una documentazione più leggibile
anche per usi futuri
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Riconciliazione e architettura
Questa metodologia è valida anche conl’architettura a due livelli:
• Il Livello riconciliato non verrà materializzato come base dati
• rimane a livello concettuale• ma è comunque la base per le fasi
successive
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Progettazione Livello Derivato
• Livello Riconciliato:– Si parte dai dati delle sorgenti (Source
driven)
• Livello Derivato:– Si parte dalle richieste dell’utente OLAP:
• Che tipo di analisi dovrà svolgere ?• Qual è il soggetto d’interesse ? (Subject-oriented)
=> Approccio Client driven
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Quale fonte dati per Livello Derivato?
• Se 3 livelli sarà Livello Riconciliato– ma non è detto che siano presenti tutti i dati
• Se due livelli:– dobbiamo cercare i dati tra le sorgenti
operazionali– ed eseguire la riconciliazione, senza
realizzare fisicamente un livello riconciliato
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Livello Derivato vs Livello Riconciliato
• Fondamentale tener conto dell’efficienza delle interrogazioni– esistono apposite strutture dati
• La granularità deve soddisfare le richieste attuali
• Il Front-End deve essere amichevole(nel Livello Riconciliato il Front-End non
esiste)
Requisiti del Livello Derivato opposti ai requisiti del Livello Riconciliato
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Seminario
Fine prima parteFine prima parte
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Seminario
Seconda parteSeconda parte
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Argomenti - 2° parte
• Realizzazione lato Back-End– Processi ETL
– Scelte di progetto
– Esempi realizzativi
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
DW per livelli di astrazione
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Elaborazioni per un Data Warehouse
• ETL: Extraction, Trasformation, Loading
EstrazioneTrasform.
eCleaning
Inserimento
Aree di Staging
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Cleaning
rispetto a
valori nulli in matricola 7769 17001 recordmatricole non affidabili 9968 17001 recordvalori nulli o bianchi in docente 6540 17001 recordvalori distinti per docente 209 58 docenti realmente diversinumero medio di varianti per ognidocente reale
3,6
record con nome e cognome ematricola nulli
556 17001 record
record con nome o cognome nullo 584 17001 recordnomi contenenti '.' o spazi in eccesso 279 17001 recordrecord con anno accademico nullo 10140 17001 recordvalori distinti per anno accademico 19 4 anni accademici realmente
diversi
Esempio di sorgente inaffidabile:
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Tipologie di errori
• Duplicazione dei dati– molte varianti di un nome che indicano la stessa
cosa– duplicazione della chiave (o dell’intero record se
non ci sono chiavi)– record con chiavi logiche differenti corrispondenti
agli stessi oggetti reali
• Violazione di integrità referenziale (concettuale o logica)
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Tipologie di errori
• Dati incompleti o assenti
• Campi che concettualmente sono chiave a null
• Valori fuori dal dominio
• Violazione di vincoli complessi che riguardano
più tabelle
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Trattamento del “dato sporco”
• Gettare• Gettare, conservando statistiche su
cosa si getta• Conservare per sottoporre a correzione
manuale• Conservare per correggerlo con gli
aggiornamenti successivi– le sorgenti hanno tempi diversi tra loro
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Cleaning
• Necessario: i dati sorgente sono sempre inaffidabili
• Difficoltoso: dipende dal contenuto dei dati e dal loro significato, non dallo schema
• Richiede una politica del “dato sporco”
• Evidenzia miglioramenti da fare sull’operazionale
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Problemi connessi al cleaning
• Uso delle strutture dati diverso da quello originariamente previsto
• Mismatching: da sorgenti diverse, quali dati si riferiscono allo stesso oggetto reale ?
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Trasformazioni
• Tipologie di trasformazioni:– Sostituzione chiavi– Separazione e Concatenazione– Conversione– Arricchimento– Normalizzazione e Denormalizzazione– Aggregazione– Storicizzazione
• Una trasformazione può appartenere a più tipologie
• Spesso i programmi effettuano le trasformazioni contemporaneamente al Cleaning
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Trasformazioni
• Requisito generale:
• Una qualsiasi variazione su una sorgente non deve necessitare di alcuna modifica sul DW
• e solo modifiche minime al software – esempio aggiunta di un record ad una
tabella
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Trasformazioni - Esempio
• Acquisizione valute:– Supponiamo di avere più sorgenti con valori
monetari– alcune hanno già fatto la conversione all’Euro,
altre non ancora, altre rimarranno con la vecchia valuta.
– Il DW è tutto in Euro
• Converrà:– Creare una tabella del tipo:
(Sorgente, fino_al, fattore_di_conversione)
– Quando una sorgente passerà all’Euro basterà:• inserire un nuovo record• o aggiornare un record esistente
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Trasformazioni - Chiavi surrogate
• Motivi:– la sorgente può riciclare le sue chiavi dopo un
lungo periodo– un’applicazione gestionale può essere sostituita– due aziende si possono fondere, …
Né su un DM né su un DW vanno mai, per nessun motivo, riutilizzate le chiavi
delle sorgenti
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Trasformazioni - Chiavi surrogate
• I valori delle chiavi utilizzati nelle sorgenti vengono sostituiti con valori numerici interi generati.
• A questo scopo:– Saranno necessarie apposite tabelle di
decodifica (chiave sorgente -> chiave DW)– nel processo di caricamento si dovrà prima:
• decodificare le chiavi sorgente• o, se si tratta del primo ingresso, generare una
nuova chiave DW
In Oracle esistono le Sequence per generare valori numerici univoci
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Trasformazioni - Chiavi surrogate
EstrazioneTrasform.
eCleaning
Inserimento
Tabelle decodifica
Sostituzione chiavi
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Separazione/concatenazione
1
T
1
1
1
T
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Trasformazioni - Esempi
and (
instr(descrizione, 'SEMES',1,1)!=0 or instr(descrizione, 'SEM.',1,1)!=0 or instr(descrizione, 'SEM ',1,1)!=0 or instr(descrizione, 'SEM)',1,1)!=0 or (LENGTH(descrizione)-instr(descrizione, 'SEM',-1,1))=2
)
• Esempio di Separazione:– Individuazione delle materie di esame che
valgono mezza annualità:
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Conversione
F(x)
x
T
1
1 F(y)
y
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Trasformazioni - Esempi
create or replace Function esame_sup (v integer) Return integer as begin
if ((v>=18) or (v=7)) thenreturn 1;
elsereturn 0;
end if;
end esame_sup;
• Esempio di conversione– Individuazione degli esami superati
• Le prove di lingua con esito positivo sono memorizzate dal CED “La Sapienza” con voto=7
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Arricchimento
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Arricchimento - varianti
• Singolo campo:– 1 campo -->1 o più campi
• Multi campo:– più campi stesso record -->1 o più campi
• Multi record: – più campi di diversi record --> 1 o più campi
• Multi sorgente: – più campi di diverse sorgenti --> 1 o più
campi
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Normalizzazione/Denormalizzazione
1
T
1
2
21
T
2
2
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Aggregazione
• Aggrega i dati a livello di record• Li porta da un maggior livello di
dettaglio ad uno minore=> riduce la granularità
• Non usata per BDW• Molto usata per BIW (Data Mart)
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Aggregazione - Esempio
• Aggregazione geografica:– Se l’utente vuole vedere i dati aggregati
come Nord, Centro e Sud– mentre sulla sorgente sono regionali
– Converrà usare una tabella che indica quali regioni appartengono al Centro, ecc.
– In questo modo se l’utente cambia le associazioni, basterà modificare un record della tabella.
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Storicizzazione dei dati
• Nei sistemi operazionali:– spesso la modifica comporta sovrascrittura– un record può essere cancellato fisicamente– anche se la sorgente tiene traccia delle
modifiche lo farà su un tempo limitato
• Nel livello riconciliato del Data Warehouse:– si deve conservare la storia completa dei dati
aziendali
• Nel Data Mart:– si svolgono analisi sulla storia dei dati
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Cosa succede nella realtà
• Vi è una transazione di business:– evento del mondo reale riguardante
l’azienda
• essa genera più modifiche ai dati– anche su più tabelle– le modifiche possono essere di tutti i tipi:
cancellazione, aggiornamento, creazione di record
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Approccio a Stati
Informazioni esplicite
to t1 t2 tn
Informazioni implicite
Trasf. 1 Trasf. n
Statoiniziale
Staton
Stato2
Stato1
Trasf. 2
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Approccio ad Eventi
Informazioni esplicite
to t1 t2 tn
Informazioni implicite
Trasf. 1 Trasf. 2 Trasf. nStato
iniziale
Staton
Stato2
Stato1
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Confronto Eventi e Stati
• A stati:– E’ la forma più utilizzata– più intuitivo e corrispondente alle nostre
esigenze– richiede maggior spazio di storage– è possibile la conversione in eventi
confrontando coppie di stati adiacenti
• Ad eventi:– Usato soprattutto nei Log– occupa meno storage– la conversione è possibile ma costosa da
calcolare
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Definizione dei dati e tempo
• Transienti:– modifiche dei record distruggono
fisicamente il precedente contenuto dei dati– è la situazione tipica dei dati operazionali
• Periodici (storicizzati):– una volta che un dato è entrato nel DB, le
informazioni che porta non possono essere modificate
– struttura ad eventi o a stati
• Snapshot: – è una fotografia dei dati ad un certo istante– ma presi in modo completo e coerente
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Rappresentazione sul DB
• Singolo timestamp– la chiave sul DB è la chiave di business, più
l’istante di inizio validità del dato– ideale per struttura ad eventi, inefficiente per
quella a stati
• Doppio timestamp– alla chiave viene aggiunto un campo con
l’istante di fine validità– per lo stato corrente useremo un valore
speciale• Null o meglio Data_futura
Data_futura: Data convenzionale che indica che l’evento deve ancora avvenire (Es. 01/01/3000 ; 31/12/9999)
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Rappresentazione sul DB
Action flag:Indica l’operazione che ha modificato il dato.A: insertC: updateD: delete
Si utilizza raramente
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Esempio - Storicizzazione
• Supponiamo che il paese di Colleferro fino al 1/1/2000 sia in provincia di Roma e poi divenga provincia di Frosinone.
Sorgente, tabella Anagrafica comuni:
DW:
Nome_comune ProvinciaRoma RomaAnzio RomaColleferro Roma
Nome_comune ProvinciaRoma RomaAnzio RomaColleferro Frosinone
Update
ID_Comune Nome_Comune ID_Comune Dal Al ID_Provincia1 Roma 1 01/01/1945 Data_Futura Roma2 Colleferro 2 01/01/1945 01/01/2000 Roma3 Anzio 3 01/01/1945 Data_Futura Roma
2 01/01/2000 Data_Futura Frosinone
tabella: DEC_Comune tabella: Comune-Provincia
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Elaborazioni per un Data Warehouse
EstrazioneTrasform.
eCleaning
Inserimento
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Estrazione dei dati
• Obiettivo: – l’operazionale ha dati transienti– devo far sì che:
• tutti i record richiesti siano catturati• i record cancellati o aggiornati siano
catturati prima della loro scomparsa
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Modalità di Estrazione
• Estrazione statica:– Prendo una foto della sorgente ad un certo
istante– Usata solo per il primo popolamento oppure– se la sorgente è completamente storicizzata e
piccola
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Estrazione dei dati
• Estrazione incrementale:– Estraggo solo le variazioni avvenute nella
sorgente.– Poi devo saper ricostruire i dati in modo
valido.– Rispetto alla Statica è più efficiente (meno
dati), ma più complessa da sviluppare.– ha molte varianti:
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Estrazione incrementale
• Cattura immediata:– Application assisted– Triggered capture (RDBMS sorgente)– Log capture: usa il Log del RDBMS per
ricostruire i dati
– sono le più efficaci, ma di difficile applicazione; infatti:
• I Log o non ci sono o sono in formato proprietario• Gli operazionali mal sopportano modifiche e
appesantimenti finalizzati al DW
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Estrazione incrementale
• Cattura differita– basata su timestamp della sorgente– basata su confronto (Delta):un’estrazione statica
viene confrontata con l’estrazione precedente
• Viene eseguita in momenti predefiniti• Se i dati sono transienti può dare risultati
incompleti:– E’ fondamentale la relazione tra periodo di
aggiornamento del DW e tempo di vita di un dato sorgente
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Calcolo del Delta
• E’ la differenza tra due estrazioni statiche (fotografie)
• Deve cogliere le seguenti operazioni avvenute sulla sorgente:– Update– Insert– Delete
• Con alcuni RDBMS si può svolgere in SQL• Oppure con appositi programmi di confronto tra file
di testo
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Calcolo del Delta in SQL
• Per Insert e Update (su campi non chiave) :select * from estraz_correnteMinusselect * from estraz_ precedente– per la Insert basta confrontare solo le chiavi
• Per Delete:select * from estraz_ precedenteMinusselect * from estraz_corrente
• Un Update sulla chiave equivale ad una Delete + una Insert
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Estrazione dei dati
• Motivazione:– ogni sorgente ha le sue caratteristiche
tecnologiche– il tempo di vita dei dati nelle sorgenti è
differente
• Ogni sorgente ha le sue modalità di estrazione• L’estrazione di sorgenti diverse spesso si deve fare in momenti diversi
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Sincronizzazione sorgenti
• Un’informazione sul DW potrebbe essere formata da dati provenienti da più sorgenti.
• Saranno necessarie apposite tabelle di appoggio per sincronizzare le sorgenti relativamente a quell’informazione
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
EstrazioneTrasform.
eCleaning
Inserimento
Elaborazioni per un Data Warehouse
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Loading (Apply)
Il metodo più generale è il:
• Constructive Merge– si parte sempre da un’estrazione
incrementale (es. Delta)– per ogni dato sull’estrazione si cercano i
dati corrispondenti sul DW– si fanno degli aggiornamenti sul DW (update
e insert) per inserire i nuovi dati mantenendo la storia
• analogamente alla storicizzazione
– a volte è necessario approssimare l’istante di modifica con l’istante di estrazione
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Argomenti - 2° parte
• Realizzazione lato Back-End– Processi ETL
– Scelte di progetto
– Esempi realizzativi
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Granularità
• E’ il livello di dettaglio delle informazioni
• In un BDW è scelto in base:– dettaglio presente sulle sorgenti– alle interrogazioni che potrebbero servire oggi– alle interrogazioni che potrebbero servire in
futuro
• Si cerca di scegliere il max– ma è molto costoso
• Va pianificata la crescita dei dati– e fatti dei compromessi
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Granularità
• In un BIW è scelta in base:– Ai requisiti utente attuali– in minima parte a quelli futuri– alla granularità del BDW
• Anche qui va pianificata la crescita
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Granularità - Esempio
• Traffico Telecomitalia:– 2 chiamate al giorno per persona => 100 milioni di record al giorno– Se profondità storica 5 anni: 1800 gg x 100M =180G– almeno 100 byte per record
=> 18 Terabyte
• Non è fattibile !
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Scelta modalità di aggiornamento
• Le scelte per Estrazione e Inserimento sono strettamente correlate
• Entrambe dipendono da:– considerazioni “politiche”– considerazioni tecnologiche
• Periodicità dell’aggiornamento:– Determinato dal minimo periodo di vita dei
dati sorgente– Sono possibili differenti periodi di refresh tra
le sorgenti – Tiene conto del ritardo max con cui gli utenti
del BIW vogliono i dati aggiornati
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Metadati
• Dati che descrivono i dati
• Si dividono in – Usage Metadata: metadati per l’utente – Build-time metadata: metadati creati
durante il progetto e lo sviluppo– Control metadata: metadati finalizzati
all’amministrazione del sistema
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Usage Metadata
• Devono indicare all’utente:– quali informazioni trova– l’organizzazione delle informazioni
(Dimensioni, livelli di aggregazione, ecc)– significato e contesto delle
informazioni– i sinonimi usati per lo stesso concetto– a quando sono aggiornati i dati– stime dei tempi richiesti per le query
• Vanno visualizzati dal Front-End
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Build-time metadata
• Documentano il contenuto del DW e le scelte fatte nella costruzione
• Sostanzialmente è la documentazione di progetto– Si ricordi che il DW si realizza a segmenti– Il progetto complessivo può richiedere
diversi anni– Ci possono lavorare molte persone
=> E’ importante che la documentazione sia ordinata, aggiornata e comprensibile ai progettisti
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Control metadata
• Sono rivolti all’amministratore del DW.
• Documentano le operazioni da svolgere o svolte.
• Per esempio:– L’esito delle elaborazioni.– I tempi di elaborazione e lo spazio occupato.– I punti critici del sistema.– Cosa fare in caso di problemi.
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Metadati - problemi
• Anche i metadati sono dinamici• E’ molto importante tenerli aggiornati e
storicizzati
• Purtroppo ciò è difficile, poiché di solito l’aggiornamento va fatto a mano.
• E’ molto difficile integrare i metadati con il resto del progetto.
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Argomenti - 2° parte
• Realizzazione lato Back-End– Processi ETL
– Scelte di progetto
– Esempi realizzativi
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Esempio realizzativo
• Progetto 6NMS:– Data Mart per gli allarmi di guasto
delle centrali telefoniche.– Realizzato con un’architettura a due
livelli.– Un’unica sorgente alimentante.
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Passi caricamento 6NMS
Caricamento_6NMS.doc
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Esempio trasformazioni
• ALGORITMO controllo_MOI:
•Cerca nella stringa d’ingresso il testo ‘”UNKNOWN ”’
•Cerca nella stringa d’ingresso il testo tra ‘ptr-id=”’ e ‘”/’.
•Verifica il valore con i valori ritenuti accettabili nella tabella di decodifica.
•Cerca nella stringa d’ingresso il testo tra ‘plmn-id=”’ e ‘”/’.
•Verifica il valore con i valori ritenuti accettabili nella tabella di decodifica.
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Tabelle di Decodifica 6NMS
CREATE TABLE wsnv_dec_severita( severita_nms NUMBER NOT NULL, severita_id NUMBER(8,0) NOT NULL,CONSTRAINT PK_WSNV_DEC_SEVERITA PRIMARY KEY
SEVERITA_NMS);
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Ciclo di vita
Preliminari:• Definizione obiettivi
– Scelta architettura– Individuazione Prima fase (Pilota)
• Definizione requisiti utente• Censimento basi dati aziendali• Definizione 1° versione Enterprise Model
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Ciclo di vita
Fase n°:• Analisi requisiti utente• Scelta nuove sorgenti• Reverse Engineering sorgenti• Riconciliazione=>nuovo Enterprise Model• eventuale ristrutturazione base dati Livello
Riconciliato• Mapping con le sorgenti• Progettazione Data Mart• Implementazione ETL e Data Mart• Configurazione Front-End e/o report
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Ciclo di vita
Attività di manutenzione:• Schedulazione ETL• Monitoraggio tempi e spazi occupati
Manutenzione evolutiva:• Configurazione Front-End e nuovi report• Modifica Data Mart per nuova reportistica• Modifica Data Mart per cambiamenti nelle
sorgenti
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Prodotti commerciali per DW
• Prodotti per ETL– Data Stage di Ascential– Powermart di Informatica– Oracle Warehouse Builder– Data Integrator di Business Objects
• Prodotti per Data cleaning– Suite di Ascential
• Prodotti per il Front-End– Business Objects– Oracle Express (db Molap)– Oracle Discoverer
• Prodotti integrati– SAS
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Figure professionali
• Esperti dominio dati sorgente• Progettista Data Warehouse (capo
progetto)• Analisti dei dati (con capacità di sintesi)• Programmatori o esperti prodotto ETL• DBA per Data Warehouse• Esperto prodotto di Front-End• Addetti alla reportistica
• Project manager
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Bibliografia
• W. H. Inmon. Building the Data Warehouse. J. Wiley & Sons, 1996
• Barry Devlin. Data Warehouse, from architetture to implementation. Addison Wesley, 1997
• R. Kimball. The Data Warehouse toolkit. J. Wiley & Sons, 1996
• R. Kimball & al. The Data Warehouse lifecycle toolkit. J. Wiley & Sons, 1998
• M.Golfarelli, S. Rizzi. Data Warehouse, Teoria e pratica della progettazione. McGraw-Hill, 2002
© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse
Seminario
Fine seconda parteFine seconda parte