Scaricare la presentazione
La presentazione è in caricamento. Aspetta per favore
1
Facoltà Ingegneria Il Data Warehouse
2
Presentazione Michele Riccio Laureato in Ingegneria Elettronica
Lavoro da circa 6 anni come progettista di Data Warehouse
3
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
4
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
5
Argomenti - 2° parte Realizzazione lato Back-End Processi ETL
Scelte di progetto Esempi realizzativi
6
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
7
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
8
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.
9
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.
10
Dal DW del Piano Telematico Calabria
11
Dal DW del Piano Telematico Calabria
12
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
13
Esempio OLAP - Ingegneria
14
Esempio OLAP - Voti a Ingegneria
15
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
16
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
17
Spider Web
18
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
19
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.
20
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
21
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
22
Visione utente degli operazionali
- Azienda telefonica - Dominio dei dati Fatturazione Dominio dei dati Marketing Dominio dei dati Traffico Dominio dei dati Call Center
23
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
24
Situazione reale degli operazionali
Dominio dei dati Applicazione B Dominio dei dati Applicazione A Dominio dei dati Applicazione D Dominio dei dati Applicazione C
25
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
26
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.
27
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
28
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)
29
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 ?
30
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.
31
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
32
Confronto anni Per generare questo grafico vengono prelevati dati da 101 DB differenti
33
Orientato al soggetto - Compagnia di assicurazioni -
Operazionali Applicazioni Data Mart Soggetti Auto Cliente Vita Polizza Premio Salute Infortunio Denuncia
34
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.
35
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
36
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
37
Schema operazionale
38
Esempio query 1 n° attività svolte suddivise per ispettore e anno
richiede sull’operazionale: 5 join la scansione di 6 tabelle
39
Join query 1
40
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 ;
41
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
42
Join query 2 e 3
43
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;
44
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;
45
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
46
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
47
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.
48
Cesura tra dati operazionali e DW
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
49
Cesura tra dati operazionali e 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
50
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.
51
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.
52
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.
53
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
54
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
55
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
56
Drill Across Se ho più tabelle dei fatti che condividono alcune Dimensioni, le posso mettere in relazione tra loro
57
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.
58
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
59
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
60
Architettura a due livelli
Data Marts Loading Aggregazione Estrazione Sorgenti
61
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
62
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
63
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
64
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
65
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.
66
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.
67
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
68
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
69
Terminologia - Architettura
70
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.
71
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
72
DW per livelli di astrazione
73
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
74
Approccio a segmenti
75
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
76
Costrutti Entity-Relationship
77
Costrutti E-R
78
Relazioni secondo Designer
79
Dal livello concettuale al logico
80
Reverse Engineering - dal logico al concettuale -
81
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.
82
Metodologia di riconciliazione
Enterprise Model: E’ il modello concettuale di tutta la realtà che il Data Warehouse dovrà rappresentare.
83
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)
84
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
85
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
86
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
87
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
88
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
89
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)
90
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 ?
91
Esempio - Azienda commerciale
92
Esempio - Azienda commerciale
93
Esempio - Azienda commerciale
94
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
95
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
96
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
97
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
98
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)
99
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
100
Seminario Fine prima parte
101
Seminario Seconda parte
102
Argomenti - 2° parte Realizzazione lato Back-End Processi ETL
Scelte di progetto Esempi realizzativi
103
DW per livelli di astrazione
104
Elaborazioni per un Data Warehouse
Estrazione Trasform. e Cleaning Inserimento Aree di Staging ETL: Extraction, Trasformation, Loading
105
Esempio di sorgente inaffidabile:
Cleaning Esempio di sorgente inaffidabile:
106
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)
107
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
108
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
109
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
110
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 ?
111
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
112
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
113
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
114
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, …
115
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
116
Trasformazioni - Chiavi surrogate
Estrazione Trasform. e Cleaning Inserimento Tabelle decodifica Sostituzione chiavi
117
Separazione/concatenazione
118
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 )
119
Conversione
120
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;
121
Arricchimento
122
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
123
Normalizzazione/Denormalizzazione
124
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)
125
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.
126
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
127
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
128
Approccio a Stati to t1 t2 tn Informazioni esplicite Stato iniziale
implicite Trasf. 1 Trasf. 2 Trasf. n
129
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
130
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
131
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
132
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)
133
Rappresentazione sul DB
Action flag: Indica l’operazione che ha modificato il dato. A: insert C: update D: delete Si utilizza raramente
134
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:
135
Elaborazioni per un Data Warehouse
Estrazione Trasform. e Cleaning Inserimento
136
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
137
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
138
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:
139
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
140
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
141
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
142
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
143
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
144
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
145
Elaborazioni per un Data Warehouse
Estrazione Trasform. e Cleaning Inserimento
146
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
147
Argomenti - 2° parte Realizzazione lato Back-End Processi ETL
Scelte di progetto Esempi realizzativi
148
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
149
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
150
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 !
151
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
152
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
153
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
154
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
155
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.
156
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.
157
Argomenti - 2° parte Realizzazione lato Back-End Processi ETL
Scelte di progetto Esempi realizzativi
158
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.
159
Passi caricamento 6NMS Caricamento_6NMS.doc
160
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 ‘”/’.
161
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 );
162
Ciclo di vita Preliminari: Definizione obiettivi
Scelta architettura Individuazione Prima fase (Pilota) Definizione requisiti utente Censimento basi dati aziendali Definizione 1° versione Enterprise Model
163
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
164
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
165
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
166
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
167
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
168
Seminario Fine seconda parte
169
Seminario Terza parte
170
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
171
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.
172
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.
173
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
174
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
175
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
176
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
177
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
178
La struttura Data Cube Tempo Prodotto Quant. venduta Incasso vendita
Negozio
179
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
180
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
181
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
182
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
183
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
184
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
185
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
186
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
187
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
188
Albero degli attributi
189
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
190
Albero degli attributi ristrutturato
191
Requisito utente: analisi delle vendite
DFM Vendite Requisito utente: analisi delle vendite Subject: Vendite
192
Albero degli attributi ristrutturato
193
Requisito utente: analisi afflusso clienti
DFM Clienti Requisito utente: analisi afflusso clienti Subject: Clienti
194
Requisito utente: analisi Vendite e Clienti
DFM Clienti-Vendite Requisito utente: analisi Vendite e Clienti Subject: Vendite n° clienti non è aggregabile sulla Dimensione Prodotto
195
Argomenti - 2° Lezione 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
196
definiscono la granularità
DFM Vendite Questi attributi definiscono la granularità
197
ROLAP - Star Schema Ha una struttura simmetrica con una tabella centrale dei fatti e alcune tabelle di dimensioni.
198
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
199
Tabella dei fatti Ogni record rappresenta un fatto elementare
Un campo per ogni misura del Fatto Chiave composta con le chiavi delle Dimensioni
200
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
201
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
202
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
203
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;
204
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à
205
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
206
Preaggregazione - Esempio
Se i prodotti sono molto numerosi e spesso si richiedono report che non dettagliano i prodotti
207
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.
208
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
209
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
210
Snowflake Schema F_- - -
211
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
212
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
213
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
214
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.
215
Dimensioni dinamiche - Esempio
216
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
217
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
218
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
219
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)
220
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)
221
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
222
Utilizzo Storicizzazione
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;
223
Utilizzo Storicizzazione
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;
224
Utilizzo Storicizzazione
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
225
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
226
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
227
Esempio con Bitmap
228
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);
229
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
230
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
231
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
232
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
233
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
234
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
235
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.
236
B.O. Designer - Visione del DB
237
Business Objects - Report
238
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
239
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
240
Schema concettuale Gioco del Lotto
ER_Lotto.doc
241
DFM Ricerca situazioni anomale
Il n° di giocate non è aggregabile in base alla Sorte
242
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.
243
DFM Ricerca giocate anomale
Il n° di giocate non è aggregabile in base alla Sorte
244
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
245
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
246
6NMS - DFM Insorgenze singole
247
6NMS - DFM Condizioni allarme
248
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 );
249
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
250
Seminario Fine terza parte
251
Seminario Fine
Presentazioni simili
© 2024 SlidePlayer.it Inc.
All rights reserved.