© Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Facoltà Ingegneria Il Data...

© Michele Riccio Facoltà Ingegneria - Lezioni sul Data Warehouse

Facoltà Ingegneria

Il Data WarehouseIl Data Warehouse


Presentazione

• Michele Riccio

• Laureato in Ingegneria Elettronica

• Lavoro da circa 6 anni come progettista di Data Warehouse


Architettura a due livelli

Data Marts

Sorgenti

Estrazione

Aggregazione

Loading


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


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


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


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


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


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


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


DW per livelli di astrazione


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


Approccio a segmenti


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


Relazioni secondo Designer


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)


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


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.



• Enterprise Model:

E’ il modello concettuale di tutta la realtà che il Data Warehouse dovrà rappresentare.



• 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)



• 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



• 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


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


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


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


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)


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 ?



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



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



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


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


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


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


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


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


Seminario

Fine prima parteFine prima parte


Seminario

Seconda parteSeconda parte


Argomenti - 2° parte

• Realizzazione lato Back-End– Processi ETL

– Scelte di progetto

– Esempi realizzativi


DW per livelli di astrazione


Elaborazioni per un Data Warehouse

• ETL: Extraction, Trasformation, Loading

EstrazioneTrasform.

eCleaning

Inserimento

Aree di Staging


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:


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)


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


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


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


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 ?


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


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


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


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



• 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



EstrazioneTrasform.

eCleaning

Inserimento

Tabelle decodifica

Sostituzione chiavi


Separazione/concatenazione

1

T

1

1

1

T


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à:


Conversione

F(x)

x

T

1

1 F(y)

y


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


Arricchimento


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


Normalizzazione/Denormalizzazione

1

T

1

2

21

T

2

2


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)


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.


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


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


Approccio a Stati

Informazioni esplicite

to t1 t2 tn

Informazioni implicite

Trasf. 1 Trasf. n

Statoiniziale

Staton

Stato2

Stato1

Trasf. 2


Approccio ad Eventi

Informazioni esplicite

to t1 t2 tn

Informazioni implicite

Trasf. 1 Trasf. 2 Trasf. nStato

iniziale

Staton

Stato2

Stato1


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


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


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)


Rappresentazione sul DB

Action flag:Indica l’operazione che ha modificato il dato.A: insertC: updateD: delete

Si utilizza raramente


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



EstrazioneTrasform.

eCleaning

Inserimento


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


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


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:


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


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


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


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


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


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


EstrazioneTrasform.

eCleaning

Inserimento



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


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


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


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 !


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


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


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


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


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.


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.


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.


Passi caricamento 6NMS

Caricamento_6NMS.doc


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.


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);


Ciclo di vita

Preliminari:• Definizione obiettivi

– Scelta architettura– Individuazione Prima fase (Pilota)

• Definizione requisiti utente• Censimento basi dati aziendali• Definizione 1° versione Enterprise Model


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


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


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


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


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


Seminario

Fine seconda parteFine seconda parte

© Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Facoltà Ingegneria Il Data...

Documents

Transcript of © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Facoltà Ingegneria Il Data...