Facoltà Ingegneria Il Data Warehouse.

Facoltà Ingegneria Il Data Warehouse

Presentazione Michele Riccio Laureato in Ingegneria Elettronica
Lavoro da circa 6 anni come progettista di Data Warehouse

Argomenti Tre lezioni sul Data Warehouse con una esercitazione.
Obiettivi: chiarire cosa si intende per Data Warehouse quali sono le problematiche che si incontrano esempi di casi reali

Argomenti - 1° parte Caratteristiche del Data Warehouse Progettazione
Cos’è e a cosa serve un DW Problematiche fondamentali del DW Interrogazione del DW - OLAP Progettazione Architetture Metodologia di progetto Case study sulla Riconciliazione

Argomenti - 2° parte Realizzazione lato Back-End Processi ETL
Scelte di progetto Esempi realizzativi

Argomenti - 3° parte Il Data Warehouse lato Front-End
Modello multidimensionale Schemi concettuali multidimensionali - DFM Strutture dati per OLAP Esempi realizzativi Il ciclo di vita del Data Warehouse

I database gestionali (Operazionali)
Permettono di effettuare rapidi aggiornamenti. Contengono dati al dettaglio massimo. Di solito vi è un DB per ogni processo. Quindi i DB non sono integrati e coerenti tra loro. Spesso non hanno profondità storica. Non permettono di fare analisi statistiche, se non con interrogazioni complesse.

I database Decisionali (Data Mart)
Quale è l’andamento delle vendite per una determinata area geografica, in un certo periodo, per una data divisione aziendale? Posso confrontare le informazioni ottenute sopra, con quelle delle altre divisioni aziendali ? Se l’attuale tendenza rimane costante, cosa posso prevedere per il futuro ? Ad es.: Sulla base delle vendite dell’anno passato cerco di prevedere quelle del prossimo trimestre.

Dal DW del Piano Telematico Calabria

OLAP On Line Analitical Processing:
Analisi in linea ma con grandi moli di dati Interattive: Non è possibile formulare a priori le richieste dell’utente L’utente deve poter vedere i dati sotto tanti punti di vista E’ fondamentale la profondità storica dei dati

Esempio OLAP - Ingegneria

Esempio OLAP - Voti a Ingegneria

Storia del Datawarehousing
L’informatica: automatizzazione di processi lavorativi 1970: inizio Data Base, su Mainframe ed in batch (off-line) 1975: Data Base usati per transazioni on-line report sui dati descrivono lo stato delle attività aziendali

Storia del Datawarehousing
1980: nasce il Personal Computer l’utente acquisisce una visione dei dati ed il programma di estrazione permette di fare report senza interferire con i sistemi centralizzati l’utente diviene padrone dei dati li può manipolare, ridistribuire, ricombinare in altro modo 1990: definizione del concetto di OLAP

Spider Web

Spider Web Mancanza di credibilità dei dati:
non si sa a quando sono aggiornati sono estratti con algoritmi diversi e non noti possono avere diverse interpretazioni non si sa qual è la loro sorgente multipli livelli di estrazione Risultato: tanti dati ma poche informazioni

A cosa serve il Data Warehouse
Trasforma i dati in informazioni: li mette nel loro contesto. Permette di trasformare le informazioni in conoscenza. Permette di ridurre i tempi e i costi necessari per prendere decisioni. Permette di pianificare il business. Permette di conservare la storia completa dei processi aziendali.

Processi operativi e Processi decisionali
OLTP: On Line Transactional Processing Dati attuali Dati elementari Inserimento, cancellazione, lettura Spazi di occupazione contenuti Applicazioni precostituite Processi Operativi OLAP: On Line Analitical Processing Dati attuali e storici Dati elementari ed aggregati Aggregazioni, lettura Spazi di occupazione crescenti Report, analisi, navigazione Processi Decisionali

Argomenti - 1° parte Caratteristiche del Data Warehouse
Cos’è e a cosa serve un DW Problematiche fondamentali del DW Interrogazione del DW - OLAP Architetture Metodologia di progetto Case study sulla Riconciliazione

Visione utente degli operazionali
- Azienda telefonica - Dominio dei dati Fatturazione Dominio dei dati Marketing Dominio dei dati Traffico Dominio dei dati Call Center

Datawarehousing – Esempio
- Azienda telefonica - Operazionali: Analisi OLAP: Aumento traffico per offerte commerciali Fatturazione Data Warehouse Traffico Relazione fatturato-traffico Marketing Adesione offerte da Call Center Call Center

Situazione reale degli operazionali
Dominio dei dati Applicazione B Dominio dei dati Applicazione A Dominio dei dati Applicazione D Dominio dei dati Applicazione C

Cos’è un Data Warehouse
Def. Devlin: Un Data Warehouse è un singolo, completo e consistente archivio di dati, estratti da diverse sorgenti e resi disponibili agli utenti finali in una forma da questi comprensibile ed utilizzabile nel contesto del business. Def. Bill Inmon: Subject Oriented Integrated Non Volatile Time Variant

Progetto di un Data Warehouse
Datawarehousing: DB2 Riconciliazione Cleaning Storicizzazione Subject orientation ORACLE DB Altre Fonti Data Warehouse Sorgenti Eterogenee Metadati 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.

Problemi di integrazione
Operazionale Data Warehouse Integrazione codifica appl A m,f appl B x,y appl C 0,1 appl D maschio,femmina m,f unità di misura appl A cm appl B pollici appl C iarde appl D mm cm

Problemi di integrazione
Operazionale Data Warehouse Integrazione sorgenti multiple appl A codice fiscale appl B partita IVA codice fiscale ? chiavi conflittuali appl A key char(10) appl B key number(9,2) appl C key char(12) appl D key pic’ ’ number(20)

Integrazione Stessi dati, nomi differenti Dati differenti, stesso nome
Chiavi differenti per gli stessi dati Dati presenti in una sorgente ma non in altre Stesse informazioni presenti in più sorgenti, quale considerare ?

Storicizzazione Per poter analizzare i processi aziendali occorre conservare tutte le variazioni dei dati nel tempo anche su un archi temporali molto lunghi. I sistemi operazionali non hanno necessità di mantenere la storia dei dati, se non nel breve periodo. I dati vengono cancellati o sovrascritti

Confronto anni Per generare questo grafico vengono prelevati dati da 101 DB differenti

Orientato al soggetto - Compagnia di assicurazioni -
Operazionali Applicazioni Data Mart Soggetti Auto Cliente Vita Polizza Premio Salute Infortunio Denuncia

Caratteristiche di un DW
Centralizzazione e integrazione delle informazioni Storicizzazione e completezza Subject orientation: visione per argomento invece che per processo Metadati: forniscono il contesto dei dati Interfaccia utente per OLAP

Schema operazionale

Esempio query 1 n° attività svolte suddivise per ispettore e anno
richiede sull’operazionale: 5 join la scansione di 6 tabelle

Join query 1

n° attività svolte suddivise per ispettore e anno
SQL query 1 n° attività svolte suddivise per ispettore e anno Select t.anno, i.Codice, i.cognome, i.nome, Count(*) From Ispettori i , ruoli r , Scheda_mensile s , Calendario t , Missioni m , Attivita_per_missione a Where i.codice_persona=r.codice_persona And r.ruolo=s.ruolo And s.anno=t.anno And s.scheda_mensile=m.scheda_mensile And a.missione=m.missione Group by t.anno, i.Codice, i.cognome, i.nome ;

Esempio query 2 Km percorsi in missioni per area dell’agenzia e tipo missione richiede: 5 join (diversi dai precedenti) la scansione di 6 tabelle

Join query 2 e 3

SQL query 2 km in missioni per area agenzia e tipo missione
SELECT aa.area, aa.descrizione_area, t.descrizione as tipo_missione , SUM(m.km) tot_km FROM tipo_missione t , missioni m , ( SELECT DISTINCT ag.agenzia, a.area, a.descrizione as descrizione_area FROM agenzie ag, agenzia_in_zona az, zone z, Aree a WHERE ag.agenzia=az.agenzia And az.zona=z.zona And a.area=z.area_appartenenza ) aa WHERE m.tipo_missione=t.tipo_missione And m.agenzia=aa.agenzia GROUP BY aa.area, aa.descrizione_area, t.descrizione;

SQL query 3 km in missioni per area agenzia e tipo missione a Gen 2003
SELECT aa.area, aa.descrizione_area, t.descrizione as tipo_missione , SUM(m.km) tot_km FROM tipo_missione t, missioni m, (SELECT DISTINCT ag.agenzia, a.area, a.descrizione as descrizione_area FROM agenzie ag, agenzia_in_zona az, zone z, Aree a WHERE ag.agenzia=az.agenzia And az.zona=z.zona And a.area=z.area_appartenenza ) aa, scheda_mensile s , calendario t WHERE m.tipo_missione=t.tipo_missione And m.agenzia=aa.agenzia And m.scheda_mensile=s.scheda_mensile And s.anno=t.anno And s.mese=t.mese And t.anno=2003 And t.nome_mese='GENNAIO' GROUP BY aa.area, aa.descrizione_area, t.descrizione;

Riduzione del numero di tabelle
Query di analisi Impossibilità di prevedere le query richieste Alta complessità di calcolo delle query => Interattività Riduzione del numero di tabelle

OLAP On Line Analitical Processing:
Analisi in linea ma con grandi moli di dati Interattive: Non è possibile formulare a priori le richieste dell’utente L’utente deve poter vedere i dati sotto tanti punti di vista E’ fondamentale la profondità storica dei dati

Cesura tra dati operazionali e DW
Datawarehousing: DB2 Riconciliazione Cleaning Storicizzazione Subject orientation ORACLE DB Altre Fonti Data Warehouse Sorgenti Eterogenee Metadati E’ indispensabile disaccoppiare le esigenze operazionali da quelle decisionali. Effettuando una replica dei dati.

Il DW è popolato da fotografie dei dati operazionali => L’utente del DW non vede mai i dati operazionali in tempo reale Motivazioni: Non avrebbe senso modificare i dati operazionali I sistemi operazionali non vengono rallentati dalle query di analisi E’ possibile trasformare e riorganizzare i dati ai fini del DW

Conseguenze: Il DW andrà aggiornato periodicamente devo saper riconoscere uno stesso record in due fotografie diverse posso conservare le informazioni che vengono cancellate negli operazionali l’utente deve sapere a quando sono aggiornati i dati vengono a cadere le considerazioni sulla normalizzazione conseguenti alle scritture sui DB operazionali Rischi: Può innescarsi una duplicazione dei dati incontrollata

Assenza di scritture in un DW
In un sistema operazionale, l’utente: aggiorna i dati (update) li cancella (delete) li inserisce (insert) => Normalizzazione per evitare le anomalie di inserimento, cancellazione, aggiornamento.

Assenza di scritture in un DW
In un Data Mart, l’utente non può effettuare alcuna scrittura. I dati verranno aggiornati solo in batch In periodi temporali in cui l’utente non vi può accedere => Niente normalizzazione Invece le strutture dati dovranno essere ottimizzate per minimizzare i tempi di risposta all’utente.

Esempio - Analisi del fatturato
Gennaio 2000 Business Unit 05 66,755 USA Se assegno un valore a tutte le N dimensioni del Data Mart, individuo un punto a N dimensioni che contiene uno o più fatti.

Drill Down/Roll Up Gruppo Gennaio 2000 10 gennaio BU 05 Italia Europa All’interno del fatto individuato, posso incrementare il dettaglio con cui esso viene visualizzato

Slice & Pivoting Tempo Settore aziendale Area geografica In un Data Mart contenente N dimensioni, posso fissarne una sola ed osservare la variazione del fatto d’interesse al variare delle altre

Dice: Seleziono un sottocubo in base ad un criterio che fa da filtro
Slice Dice Dice: Seleziono un sottocubo in base ad un criterio che fa da filtro

Drill Across Se ho più tabelle dei fatti che condividono alcune Dimensioni, le posso mettere in relazione tra loro

Operazioni OLAP Drill down: diminuisce l’aggregazione dei dati introducendo un ulteriore livello di dettaglio. Roll up: aggrega un insieme di fatti diminuendone il livello di dettaglio. Slice: riduce il numero di dimensioni del cubo fissando un valore per una delle sue dimensioni. Dice: scelta di un sottoinsieme dei fatti d’interesse tramite un criterio che fa da filtro. Drill across: collegamento tra due o più cubi correlabili per calcolare indicatori formati da misure provenienti da cubi diversi.

Architettura ad un livello
Minimizzazione del volume di dati memorizzati Vantaggi Sviluppo rapido e costi ridotti Decision Support System Evita il problema della sincronizzazione dei dati ripetuti Dati Real-Time Esecuzione ripetuta della stessa query Svantaggi Mancanza di storicizzazione dei dati Contesa sui dati tra sistemi operazionali e sistemi decisionali Operational System Impossibilità di riorganizzare i dati per i sistemi decisionali

Architettura a due livelli
Data Marts Loading Aggregazione Estrazione Sorgenti

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 1 Primario Secondario 2 Front 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

Progetto di un Data Warehouse a 2 livelli
Datawarehousing: DB2 Riconciliazione Cleaning Storicizzazione Subject orientation Aggregazione ORACLE DB Altre Fonti Data Warehouse (insieme di Data Mart) Sorgenti Eterogenee Metadati 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.

Progetto di un Data Warehouse a 3 livelli
Datawarehousing: DB2 Livello riconciliato Livello derivato Riconciliazione Cleaning Storicizzazione Aggregazione Subject Orientation ORACLE BIW BDW Primario del Data Warehouse Altre Fonti Data Mart Sorgenti Eterogenee Metadati 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.

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

Architettura a tre livelli – caratteristiche
A questo livello vi sono le applicazioni per il supporto alle decisioni BIG Dati Derivati BIW Metadati BIW: Business Information Warehouse Business Information Guide Staging BIW Dati Riconciliati BDW DW catalog Popolamento Business Data Warehouse Dati Real-Time Enterprise model Sorgenti

Terminologia - Architettura

Argomenti - 1° parte Progettazione
Caratteristiche del Data Warehouse Cos’è e a cosa serve un DW Problematiche fondamentali del DW Interrogazione del DW - OLAP Progettazione Architetture Metodologia di progetto Case study sulla Riconciliazione Quel che diremo si applica all’architettura a tre livelli e con qualche modifica anche a quella a due livelli.

Modellazione dei dati Modello concettuale: descrive le informazioni e i loro legami per come sono nella realtà, indipendentemente dalla rappresentazione nella base dati Modello logico: rappresenta i dati e i loro legami in funzione della loro gestione in una base dati Modello fisico: rappresenta i dati secondo il formato con cui sono memorizzati su una base dati o altro

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

Costrutti Entity-Relationship

Costrutti E-R

Relazioni secondo Designer

Dal livello concettuale al logico

Reverse Engineering - dal logico al concettuale -

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
Sn S1 S2 Si+1 Reverse Engineering Reverse Engineering Reverse Engineering Reverse Engineering EM0 EM1 EM2 EMi EMi+1 EMn-1 EMn CM S1 CM S2 CM Si+1 CM Sn dove: Si Sorgente i-ma CM Si Modello concettuale sorgente i-ma EM0 Enterprise Model iniziale EMn Enterprise Model finale

Costruzione Enterprise Model
CM S1 Reverse Engineering Sintesi e omogeneizzazione EM1 CM S2 S1 Reverse Engineering EM2 EM finale CM Si+1 S2 Reverse Engineering EM0 EMi+1 Si+1 CM Sn Reverse Engineering Sn 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 ?

Esempio - Azienda commerciale

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 con l’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
Requisiti del Livello Derivato opposti ai requisiti del 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)

Argomenti - 1° parte Progettazione Architetture
Caratteristiche del Data Warehouse Cos’è e a cosa serve un DW Problematiche fondamentali del DW Interrogazione del DW - OLAP Progettazione Architetture Metodologia di progetto Case study sulla Riconciliazione

Seminario Fine prima parte

Seminario Seconda parte

DW per livelli di astrazione

Elaborazioni per un Data Warehouse
Estrazione Trasform. e Cleaning Inserimento Aree di Staging ETL: Extraction, Trasformation, Loading

Esempio di sorgente inaffidabile:
Cleaning 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
Né su un DM né su un DW vanno mai, per nessun motivo, riutilizzate le chiavi delle sorgenti Motivi: la sorgente può riciclare le sue chiavi dopo un lungo periodo un’applicazione gestionale può essere sostituita due aziende si possono fondere, …

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

Estrazione Trasform. e Cleaning Inserimento Tabelle decodifica Sostituzione chiavi

Separazione/concatenazione

Trasformazioni - Esempi
Esempio di Separazione: Individuazione delle materie di esame che valgono mezza annualità: 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 )

Conversione

Trasformazioni - Esempi
Esempio di conversione Individuazione degli esami superati Le prove di lingua con esito positivo sono memorizzate dal CED “La Sapienza” con voto=7 create or replace Function esame_sup (v integer) Return integer as begin if ((v>=18) or (v=7)) then return 1; else return 0; end if; end esame_sup;

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

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 to t1 t2 tn Informazioni esplicite Stato iniziale
implicite Trasf. 1 Trasf. 2 Trasf. n

Approccio ad Eventi to t1 t2 tn Informazioni esplicite Stato iniziale
Trasf. 1 Trasf. 2 Trasf. n to t1 t2 tn Informazioni implicite Stato 1 Stato 2 Stato n

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: insert C: update D: 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: Update DW:

Estrazione Trasform. e Cleaning 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_corrente Minus select * from estraz_ precedente per la Insert basta confrontare solo le chiavi Per Delete: Un Update sulla chiave equivale ad una Delete + una Insert

Estrazione dei dati Motivazione:
Ogni sorgente ha le sue modalità di estrazione L’estrazione di sorgenti diverse spesso si deve fare in momenti diversi Motivazione: ogni sorgente ha le sue caratteristiche tecnologiche il tempo di vita dei dati nelle sorgenti è differente

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

Estrazione Trasform. e Cleaning Inserimento

Loading (Apply) Constructive Merge Il metodo più generale è il:
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: => 18 Terabyte
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 ‘”/’.

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 parte

Seminario Terza parte

Operazioni OLAP Drill down: diminuisce l’aggregazione dei dati introducendo un ulteriore livello di dettaglio. Roll up: aggrega un insieme di fatti diminuendone il livello di dettaglio. Slice: riduce il numero di dimensioni del cubo fissando un valore per una delle sue dimensioni. Dice: scelta di un sottoinsieme dei fatti d’interesse tramite un criterio che fa da filtro. Drill across: collegamento tra due o più cubi correlabili per calcolare indicatori formati da misure provenienti da cubi diversi.

Fatti X Dimensioni Tempo Settore aziendale Area geografica Il contenuto del Data Mart può essere visto come un cubo ad N dimensioni, nel quale i vertici sono identificati dalle dimensioni, che individuano un punto all’interno del cubo, contenente l’informazione cercata.

I fatti Sono i fatti o gli eventi che permettono di comprendere l’andamento dell’azienda. I fatti sono l’oggetto dell’analisi. Esempi: Vendite, Esame universitario, Acquisti Misure: grandezze che rappresentano i fatti misurandoli Le misure sono sempre numeriche. Esempi: numero di clienti, incasso, numero esami, voto esame, numero di fatture

Le dimensioni Sono insiemi di grandezze con cui suddividere i fatti e scegliere come aggregarli. Tutti i possibili punti di vista da cui è possibile osservare i fatti. Tutti i possibili criteri di selezione dei dati. Esempi: Tempo, Luogo, Settore aziendale, Fascia di reddito

Attributi e Gerarchie Attributi: Le grandezze che formano le Dimensioni Sono sempre grandezze discrete. Esempi: Mese, Anno, Città, Business Unit, Reddito tra 10 e 20 mila Gerarchie: Come è possibile aggregare le misure dei fatti sono l’ordine con cui possiamo navigare tra gli attributi delle Dimensioni per aggregare i fatti. Esempio: città->regione->nazione->continente

Modello Multidimensionale
Fatto Processo di business da modellare Dimensione Rappresentazione delle proprietà dei fatti Gerarchie Aggregazione delle istanze dei fatti Misure Attributo quantitativo di un fatto

Modello Multidimensionale - Esempio
In una catena di negozi il processo modellizzato (fatto) è tipicamente il “Processo di Vendita”. Fatto: Processo di Vendita Dimensione Prodotto: Prodotto  Marca  Categoria Dimensione Negozio: Negozio  Città  Regione Dimensione Tempo: Giorno  Mese  Anno Gerarchie Misura1: Quantità venduta Misura2: Incasso vendita

La struttura Data Cube Tempo Prodotto Quant. venduta Incasso vendita
Negozio

Modellazione concettuale
gli E-R devono modellare una realtà d’interesse Adesso devo anche modellare cosa interessa all’utente cosa gli interessa analizzare come organizzare le cose da vedere con quali livelli di aggregazione =>Scelta Dimensioni e Gerarchie non banale

Dimensional Fact Model
È un modello di dati concettuale tramite il quale si possono rappresentare i concetti di fatto, dimensione e gerarchia, in maniera grafica ed indipendentemente dalla rappresentazione logica che si adotterà in fase di realizzazione

Dimensional Fact Model - Esempio
DFM: un formalismo grafico per la rappresentazione di uno schema multidimensionale. Attributo non dimensionale Fatto Mese Semestre Anno Negozio Città Regione Nazione Prodotto Tipo di Bene Analisi della Concorrenza Q.tà Venduta Investimenti Fatturato Indirizzo Gerarchie Attributo dimensionale Misure Dimensioni

Sintesi Dimensional Fact Model
Si parte dall’E-R dei dati aziendali e dai Subject d’interesse per l’utente nel caso il Fatto d’interesse sia una relazione va trasformata in entità (Reificazione) Si costruisce l’albero degli attributi seguendo le relazioni molti a uno In base ai requisiti utente si ristruttura l’albero degli attributi

Esempio - Schema E/R del DB Vendite
Collocato Appartiene Gestito Negozio Scontrino Fiscale Prodotto Tipo Categoria Città Manager negozio indirizzo data numero scontrino prodotto dimensione costruttore tipo stato città categoria manager Vendita Emette (0,n) (1,n) (1,1) quantità venduta prezzo unitario

Esempio - Reificazione di vendita
Appartiene Tipo Appartiene Categoria (0,n) (1,1) (1,n) (1,1) prodotto tipo categoria Prodotto dimensione costruttore (0,n) Città città di prodotto stato quantità venduta (1,1) (1,n) Vendita Collocato prezzo unitario (1,1) registra (1,n) (1,1) (1,1) Scontrino Fiscale Emette (0,n) (1,1) Negozio Gestito (1,n) Manager numero scontrino data negozio indirizzo manager

Algoritmo per DFM Identificazione dei Fatti e relative misure
Per ogni fatto: identificazione del Fatto sull’ER L’entità fatto diviene la radice di un albero gli attributi del fatto divengono nodi figli della radice le entità connesse direttamente con il fatto divengono figli della radice

Algoritmo per DFM ricorsivamente:
ogni nodo ha come figli i suoi attributi e le entità ad esso legate con relazione molti a 1 (o 1 a 1) una generalizzazione si deve vedere come una relazione 1 a 1

Albero degli attributi

Ristrutturazione dell’albero degli attributi
Eliminare i nodi che non ci interessano Aggiungere nodi: se da un nodo si possono calcolare altre informazioni d’interesse allora genera dei figli identificare o generare le misure => Le dimensioni possibili saranno i figli della radice scegliere Dimensioni e granularità Identificare le gerarchie d’interesse

Albero degli attributi ristrutturato

Requisito utente: analisi delle vendite
DFM Vendite Requisito utente: analisi delle vendite Subject: Vendite

Albero degli attributi ristrutturato

Requisito utente: analisi afflusso clienti
DFM Clienti Requisito utente: analisi afflusso clienti Subject: Clienti

Requisito utente: analisi Vendite e Clienti
DFM Clienti-Vendite Requisito utente: analisi Vendite e Clienti Subject: Vendite n° clienti non è aggregabile sulla Dimensione Prodotto

Argomenti - 2° Lezione Il Data Warehouse lato Front-End

definiscono la granularità
DFM Vendite Questi attributi definiscono la granularità

ROLAP - Star Schema Ha una struttura simmetrica con una tabella centrale dei fatti e alcune tabelle di dimensioni.

Tabelle delle Dimensioni
Un campo per ogni attributo della Dimensione I valori di questi campi devono essere comprensibili agli utenti La chiave rappresenta l’attributo al livello più basso della Gerarchia La chiave non è visibile agli utenti e sarà numerica

Tabella dei fatti Ogni record rappresenta un fatto elementare
Un campo per ogni misura del Fatto Chiave composta con le chiavi delle Dimensioni

Diverse tabelle dei fatti possono condividere alcune Dimensioni
Più tabelle dei fatti Incasso medio per cliente: ottenibile con un drill across Diverse tabelle dei fatti possono condividere alcune Dimensioni

Chiavi surrogate Le chiavi delle Dimensioni sempre: Motivazioni
numeriche intere non composte indipendenti dalla sorgente Motivazioni Mantenere i Data Mart indipendenti dalle ristrutturazioni delle sorgenti i join sono così più efficienti potrò modificare una Dimensione senza modificare la tabella dei fatti

Efficienza delle interrogazioni
Query: Incasso settimanale della categoria di prodotto “alimentari” suddivisa per stato DB normalizzato: 13 tabelle 9 join Star schema: 4 tabelle 3 join Lo schema a stella permette di ridurre il numero di join richiesti dalle interrogazioni e guida l’utente nella scelta di query sensate

Efficienza delle interrogazioni
Incasso settimanale della categoria di prodotto “alimentari” suddivisa per stato Select T.settimana, N.stato, sum(F.Incasso) From Tempo T, Negozio N, Prodotto P, Fatto F Where T.id_giorno=F.id_giorno And N.id_negozio=F.id_negozio And P.id_prodotto=F.id_prodotto And P.categoria='ALIMENTARI' Group by T.settimana, N.stato;

Molteplicità dei punti di vista
Il numero delle possibili aggregazioni dei fatti è : Produttoria del (numero di attributi +1) per ogni Dimensione 150 nel nostro esempio => Interattività

Ottimizzazione-Preaggregazione dei fatti
In caso di tabelle dei fatti molto numerose: Possibilità di creare tabelle dei fatti preaggregate Quali preaggregazioni scegliere ? Valutare: quali sono le query più frequentemente richieste tempi di elaborazione delle query se non preaggregate spazio disco utilizzato Trovare un compromesso tra spazio disco e tempi di attesa per l’utente

Preaggregazione - Esempio
Se i prodotti sono molto numerosi e spesso si richiedono report che non dettagliano i prodotti

Dimensioni degeneri Sono le dimensioni composte da un unico attributo.
esempio: lo Stato di una pratica In tal caso: Non conviene creare una apposita tabella dimensionale basterà un campo nella tabella dei fatti con il valore naturale => In fase d’interrogazione ho risparmiato un join con la tabella dei fatti.

Dimensioni degeneri - Junk Dimension
Se per una tabella dei fatti ho più dimensioni degeneri: Creo un’unica tabella dimensione per tutte le degeneri con un campo per ogni dimensione ed un’unica chiave surrogata. Dovrò generare un record per ogni possibile combinazione dei valori di tutte le dimensioni degeneri purchè le combinazioni non siano troppe! N.B.: Tra i campi della Junk Dimension non esiste alcuna relazione gerarchica

Fiocco di neve - Snowflake
Consiste in una parziale normalizzazione di alcune tabelle dimensione Va utilizzato solo in casi particolari: Una porzione notevole di gerarchia in comune tra più Dimensioni Una Dimensione che si divide in due rami gerarchici separati con molti attributi, e con cardinalità molto diversa. Si può abbinare alla preaggregazione

Snowflake Schema F_- - -

Dimensioni condivise Esempio:
Città di nascita e Città di residenza Sono due attributi dimensionali che condividono la stessa gerarchia, con stessa granularità. Avrò un’unica tabella dimensione condivisa invece di due tabelle dimensione distinte Nella tabella dei fatti avrò due campi distinti: Id_citta_nascita e Id_citta_residenza

Dimensioni condivise Se la tabella dimensione è condivisa da più tabelle dei fatti => Dimensione Conforme Utilizzare il più possibile dimensioni condivise e/o conformi. Se le Dimensioni condividono solo parte degli attributi => Snowflake ? a volte è meglio tenerle separate lo Snowflake complica la struttura e appesantisce le interrogazioni

Slowly changing Dimension
Finora abbiamo supposto che: le Dimensioni non varino nel tempo, siano statiche siano solo i Fatti a dipendere dal tempo. In realtà: Vi sono Dimensioni che variano nel tempo Anche se più lentamente dei Fatti, con minor frequenza Per l’utente può essere importante tener conto di questa variabilità. Le chiameremo: Dimensioni dinamiche

Dimensioni dinamiche - Esempio
L’utente vuole comparare le vendite dei negozi in funzione del Manager che li dirige. Ma i manager possono cambiare nel tempo. => L’utente otterrà dei report con significato diverso da quello atteso.

Dimensioni dinamiche - Esempio

Esempio Manager Incasso Rossi 300 Bianchi 100 Manager Incasso Rossi 50
Situazione al 1/1/2001: Fatti: Negozio Data Incasso A 8/2/2001 300 B 18/10/2001 100 8/2/2002 18/10/2002 C 5/7/2002 50 Negozio Manager A Rossi B Bianchi Report al 31/12/2001: Manager Incasso Rossi 300 Bianchi 100 Situazione al 1/1/2002: Negozio Manager A Bianchi B C Rossi Report al 31/12/2002: Manager Incasso Rossi 50 Bianchi 600

Dimensioni dinamiche Deve essere possibile interpretare le misure in funzione della storia <=> Aggregare diversamente le misure La dinamicità può riguardare: L’attributo in se stesso, per es. il nome del negozio --> raramente necessita di dimensione dinamica la relazione tra due attributi, cioè l’arco della gerarchia, per es. il manager A volte in una stessa Dimensione attributi diversi vanno interpretati diversamente

Come aggregare ? Vi sono però molteplici interpretazioni:
Verità storica -Tipo 2- Ogni fatto viene interpretato in base alla situazione presente nel momento in cui si è verificato Ieri per Oggi (Tempo a scelta) Ogni fatto viene interpretato in base ad un’unica situazione presente in un certo istante scelto dall’utente Assenza di storia -Tipo 1- Ogni fatto viene interpretato in base all’unica situazione attualmente presente Report diversi possono richiedere differenti interpretazioni di uno stesso attributo

Dimensione con Verità storica
Se per un attributo dimensionale è richiesta: Esclusivamente la Verità storica Verità storica su Manager Id_Negozio Nome Manager 11 A Rossi 12 B Bianchi 156 162 C Non ho bisogno di filtri particolari E’ lo stesso Id_negozio a registrare la storia Per ogni variante: genero un nuovo record dimensionale con stesso identificativo sorgente (Nome) ma diversa chiave surrogata (Id_negozio)

Storicizzazione completa
Soluzione generale, ma molto costosa: Id_Negozio Dal Al Nome Manager Master 11 1/1/2001 1/1/2002 A Rossi 12 B Bianchi 156 1/6/2003 162 Data_futura C 180 AA Per ogni variante: genero un nuovo record dimensionale con diversa chiave surrogata (Id_negozio) Il campo Master indica qual’è la prima versione di quel oggetto (non la precedente)

Utilizzo Storicizzazione
Se soluzione generale: Verità storica: nessun filtro particolare Tempo a scelta: data_richiesta >= DAL and data_richiesta <AL: da usare come intestazione join (Intestazione.master=Dimensione.master ) join (Fatti.Id_**=Dimensione.Id_** ) raggruppo su Intestazione Assenza di storia: come Tempo a scelta ma Intestazione: AL=data_futura

Tempo a scelta - con soluzione generale : Select * From Negozio as Intestazione Where data_richiesta >= DAL and data_richiesta <AL; Select Intestazione.manager, sum(num_pezzi), sum(incasso) From Negozio, Intestazione, Fatto Where Intestazione.master=Negozio.master and Fatto.Id_negozio=Negozio.Id_negozio Group by Intestazione.manager;

Se soluzione generale: Tempo a scelta: Select Intestazione.manager, sum(num_pezzi), sum(incasso) From Negozio, Negozio as Intestazione, Fatto Where data_richiesta >= Intestazione.DAL and data_richiesta <Intestazione.AL and Intestazione.master=Negozio.master and Fatto.Id_negozio=Negozio.Id_negozio Group by Intestazione.manager;

Se soluzione generale: Assenza di storia: Select Intestazione.manager, sum(num_pezzi), sum(incasso) From Negozio, Negozio as Intestazione, Fatto Where Intestazione.AL=data_futura and Intestazione.master=Negozio.master and Fatto.Id_negozio=Negozio.Id_negozio Group by Intestazione.manager; N.B.: Vengono esclusi gli oggetti non più attivi. Esempio: un negozio chiuso 6 mesi fa, non avrà AL=data_futura

Indici Bitmap Sono basati su stringhe di bit
per ogni record vi è una stringa sull’indice ogni bit della stringa corrisponde ad un valore distinto del campo il bit indica se il campo ha quel valore Le stringhe vengono confrontate durante il full table scan Prestazioni per DM migliori un DM va quasi sempre in full table scan In Oracle dalla 7.3 (meglio 8.0) in poi

Quando usare i Bitmap Cardinalità: rapporto tra numero di valori distinti del campo e numero di record della tabella Sia per Fatti che Dimensioni si ha: Se cardinalità<=5%  Bitmap altrimenti B-tree Di solito sempre bitmap eccetto chiavi primarie

Esempio con Bitmap

Esempio con Bitmap Dimensioni, B-Tree su Primary key: Fatti:
Id_giorno, Id_prodotto, Id_negozio Fatti: Primary key, un B-Tree su: (Id_giorno, Id_negozio, Id_prodotto) Bitmap: Id_negozio Create Bitmap index IDB_Fatti_Negozio ON Fatti (Id_negozio); Bitmap: Id_prodotto Create Bitmap index IDB_Fatti_Prodotto ON Fatti (Id_prodotto);

Struttura logica MOLAP
Tempo Prodotto Negozio In memoria: un array ad n dimensioni ogni valore dell’array rappresenta un fatto (le misure) o una sua aggregazione un cubo conserva tutti i fatti elementari e tutte le sue possibili aggregazioni in modo esplicito

Struttura logica MOLAP
MOLAP: base dati multidimensionale E’ la traduzione diretta del modello multidimensionale Ogni produttore la implementa diversamente Le strutture dati sono: proprietarie del produttore molto legate allo specifico prodotto Non esistono standard

MOLAP - Esempio Supponiamo di realizzare un DM con tre dimensioni ed una misura: Tempo: Anno, Mese (5 anni e 60 mesi differenti) Prodotto: Prodotto, Categoria (100 prodotti, 5 categorie) Geografia: Città, Regione (50 città, 10 regioni) Avremo una matrice con: 50x100x60+50x5x60+50x1x60+ 50x100x5+50x5x5+50x1x5+ 50x100x1+50x5x1+50x1x1+ 10x100x60+10x5x60+10x1x60+ 10x100x5+10x5x5+10x1x5+ 10x100x1+10x5x1+10x1x1+ 1x10x60+1x5x60+1x1x60+ 1x10x5+1x5x5+1x1x5 +1x10x1+1x5x1+1x1x1 = valori =>Esplosione combinatoria

MOLAP - Sparsità Per molte delle combinazioni dei valori degli attributi dimensionali le misure non saranno valorizzate =>un DB multidimensionale è una matrice sparsa ciò aumenterebbe le dimensioni del DB riducendone le prestazioni Ogni produttore utilizza metodi diversi per evitare la sparsità dei dati

MOLAP e ROLAP MOLAP: ROLAP: prestazioni migliori
poco scalabile: a volte richiede volumi maggiori rigido: progetto molto vincolato e guidato richiede tool specifici ROLAP: molto scalabile non richiede tool specifici Lascia più libertà al progettista ha prestazioni inferiori

Hybrid OLAP HOLAP: tecnologia ibrida per ottenere i benefici sia del Molap che del Rolap. A seconda del produttore vi sono diverse interpretazioni, per esempio: Data Mart Molap per le combinazioni di attributi dimensionali che corrispondono alle query più richieste se richiesta una combinazione non presente, viene calcolata in linea accedendo a data base relazionali

Moduli di Business Object
Designer: crea gli Universi, una vista dei dati semplificata per l’utente. Con nomi degli oggetti a lui comprensibili e join preimpostati. Supervisor: per la gestione degli accessi con la possibilità di creare ruoli, utenti con diritti diversi a seconda dell’oggetto considerato. Business object: per la creazione dei report utilizzando gli oggetti già definiti nell’universo.

B.O. Designer - Visione del DB

Business Objects - Report

Realizzazione del Front-end
Report dinamici: permettono operazioni OLAP richiedono all’utente una conoscenza del prodotto di Front-End un utente evoluto si potrebbe preparare i report da solo Report statici: non permettono operazioni OLAP per ogni aggregazione diversa va previsto un apposito report molto limitanti l’utente può non avere nessuna conoscenza del prodotto

Schema concettuale Gioco del Lotto
ER_Lotto.doc

DFM Ricerca situazioni anomale
Il n° di giocate non è aggregabile in base alla Sorte

Analisi consentite Esempi di interrogazioni:
- Scelto un Concorso mostrare per ogni Ruota giocata il n° di puntate e il rapporto n° di vincite atomiche/n° puntate atomiche suddivise per sorte - Scelto un mese concorsuale ed una provincia, mostrare il rapporto posta vincente/posta per ogni comune e suddiviso per sorte Un'analisi non consentita: Mostrare per ogni provincia il numero di puntate le cui puntate atomiche sono tutte vincenti infatti vi sono solo dati preaggregati non vi è la singola puntata quindi non è possibile correlare una singola puntata con le sue puntate atomiche.

DFM Ricerca giocate anomale
Il n° di giocate non è aggregabile in base alla Sorte

Stima spazio occupato - Situazioni
Numero di record l’anno: Prodotto delle cardinalità degli attributi dimensionali di massimo dettaglio: n° Concorsi*n° Ricevitorie*n° Ruote*Sorti pari a 104*35*10^3*10*5 = 1.8*10^8 record l'anno Considerando ulteriori misure: il numero di record generati dalla struttura non varia ma aumenta lo spazio occupato da ogni record

Stima spazio occupato - Giocate
Per questa struttura di maggior dettaglio il numero di record generati sarà: Abbiamo quindi due ordini di grandezza in più rispetto alla struttura precedente n° giocate per concorso * n°Concorsi l’anno*n° puntate per giocata pari a 35*10^6*104*3 = 1.1*10^10 record l'anno

6NMS - DFM Insorgenze singole

6NMS - DFM Condizioni allarme

6NMS - Tabelle Data Mart CREATE TABLE dm_fact( inizio DATE NOT NULL
,specific_problems_id NUMBER(8,0) NOT NULL ,tipne_costr_id NUMBER(8,0) NOT NULL ,tecnica_rete_id NUMBER(8,0) NOT NULL ,ptr_id NUMBER(8,0) NOT NULL ,severita_id NUMBER(8,0) NOT NULL ,fine DATE NOT NULL ,durata NUMBER(10,0) NOT NULL ) PCTFREE 5 PCTUSED 40 INITRANS 1 MAXTRANS 255 STORAGE (INITIAL NEXT MINEXTENTS 1 MAXEXTENTS 121 PCTINCREASE 0) TABLESPACE DM; CREATE TABLE dm_specific_problems( specific_problems_id NUMBER(8,0) NOT NULL , descrizione VARCHAR2(80) NOT NULL ); CREATE TABLE dm_tecnica_rete( tecnica_rete_id NUMBER(8,0) NOT NULL CREATE TABLE dm_tipne_costr( tipne_costr_id NUMBER(8,0) NOT NULL , descrizione_tne VARCHAR2(80) NOT NULL , descrizione_costr VARCHAR2(80) NOT NULL ); CREATE TABLE dm_ptr( ptr_id NUMBER(8,0) NOT NULL CREATE TABLE dm_severita( severita_id NUMBER(8,0) NOT NULL CREATE TABLE dm_tempo( inizio DATE NOT NULL , anno VARCHAR2(4) NOT NULL , mese VARCHAR2(7) NOT NULL , giorno VARCHAR2(10) NOT NULL , ora VARCHAR2(13) NOT NULL );

Seminario Fine terza parte

Seminario Fine

Facoltà Ingegneria Il Data Warehouse.

Presentazioni simili

Presentazione sul tema: "Facoltà Ingegneria Il Data Warehouse."— Transcript della presentazione:

Presentazioni simili

Sul progetto

Feed-back

Entrare

Autorizzarsi attraverso i social network:

Facoltà Ingegneria Il Data Warehouse.

Presentazioni simili

Presentazione sul tema: "Facoltà Ingegneria Il Data Warehouse."— Transcript della presentazione:

Presentazioni simili

Sul progetto

Feed-back