La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

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

Presentazioni simili


Presentazione sul tema: "© Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Facoltà Ingegneria Il Data Warehouse."— Transcript della presentazione:

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

2 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Presentazione Michele Riccio Laureato in Ingegneria Elettronica Lavoro da circa 6 anni come progettista di Data Warehouse

3 © Michele RiccioFacoltà Ingegneria - Lezioni sul 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

4 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Argomenti - 1° parte 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

5 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Argomenti - 2° parte Realizzazione lato Back-End –Processi ETL –Scelte di progetto –Esempi realizzativi

6 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Argomenti - 1° parte 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

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

9 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse I database Decisionali (Data Mart) Quale è landamento 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 lattuale tendenza rimane costante, cosa posso prevedere per il futuro ? Ad es.: Sulla base delle vendite dellanno passato cerco di prevedere quelle del prossimo trimestre.

10 Dal DW del Piano Telematico Calabria

11

12 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse OLAP On Line Analitical Processing : Analisi in linea ma con grandi moli di dati Interattive: Non è possibile formulare a priori le richieste dellutente Lutente deve poter vedere i dati sotto tanti punti di vista E fondamentale la profondità storica dei dati

13 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Esempio OLAP - Ingegneria

14 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Esempio OLAP - Voti a Ingegneria

15 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Storia del Datawarehousing Linformatica: 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Storia del Datawarehousing 1980: nasce il Personal Computer –lutente acquisisce una visione dei dati ed il programma di estrazione –permette di fare report senza interferire con i sistemi centralizzati lutente diviene padrone dei dati –li può manipolare, ridistribuire, ricombinare in altro modo 1990: definizione del concetto di OLAP

17 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Spider Web

18 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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 pianificare il business. Permette di ridurre i tempi e i costi necessari per prendere decisioni. Permette di conservare la storia completa dei processi aziendali.

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

21 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Dominio dei dati Fatturazione Marketing Call Center Dominio dei dati Traffico Visione utente degli operazionali - Azienda telefonica -

23 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Datawarehousing – Esempio - Azienda telefonica - Fatturazione Marketing Call Center Traffico Data Warehouse Operazionali: Aumento traffico per offerte commerciali Relazione fatturato-traffico Adesione offerte da Call Center Analisi OLAP:

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

25 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Cosè un Data Warehouse Def. Bill Inmon: Subject Oriented Integrated Non Volatile Time Variant Def. Bill Inmon: Subject Oriented Integrated Non Volatile Time Variant 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. 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.

26 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Riconciliazione Cleaning Storicizzazione Subject orientation Riconciliazione Cleaning Storicizzazione Subject orientation Progetto di un Data Warehouse DB2 ORACLE Altre Fonti Sorgenti Eterogenee Data Warehouse DB A partire dallanalisi dei processi aziendali e dei dati presenti nei sistemi già esistenti in azienda, vengono creati gli oggetti di business da inserire nel Data Warehouse. Datawarehousing: Metadati

27 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Problemi di integrazione OperazionaleData Warehouse Integrazione appl A m,f appl B x,y appl C 0,1 appl D maschio,femmina m,f codifica appl A cm appl B pollici appl C iarde appl D mm cm unità di misura

28 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Problemi di integrazione OperazionaleData Warehouse Integrazione appl A codice fiscale appl B partita IVA codice fiscale sorgenti multiple appl A key char(10) appl B key number(9,2) appl C key char(12) appl D key pic number(20) chiavi conflittuali ?

29 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Riconciliazione Cleaning Storicizzazione Subject orientation Riconciliazione Cleaning Storicizzazione Subject orientation Progetto di un Data Warehouse DB2 ORACLE Altre Fonti Sorgenti Eterogenee Data Warehouse DB A partire dallanalisi dei processi aziendali e dei dati presenti nei sistemi già esistenti in azienda, vengono creati gli oggetti di business da inserire nel Data Warehouse. Datawarehousing: Metadati

31 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Confronto anni Per generare questo grafico vengono prelevati dati da 101 DB differenti

33 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Orientato al soggetto - Compagnia di assicurazioni - OperazionaliData Mart Auto Vita Salute Cliente Polizza Premio Infortunio Denuncia ApplicazioniSoggetti

34 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Riconciliazione Cleaning Storicizzazione Subject orientation Riconciliazione Cleaning Storicizzazione Subject orientation Progetto di un Data Warehouse DB2 ORACLE Altre Fonti Sorgenti Eterogenee Data Warehouse DB A partire dallanalisi dei processi aziendali e dei dati presenti nei sistemi già esistenti in azienda, vengono creati gli oggetti di business da inserire nel Data Warehouse. Datawarehousing: Metadati

35 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Argomenti - 1° parte 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

37 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Schema operazionale

38 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Esempio query 1 n° attività svolte suddivise per ispettore e anno richiede sulloperazionale: –5 join –la scansione di 6 tabelle

39 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Join query 1

40 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse SQL query 1 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 ; n° attività svolte suddivise per ispettore e anno

41 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Esempio query 2 Km percorsi in missioni per area dellagenzia e tipo missione richiede: –5 join (diversi dai precedenti) –la scansione di 6 tabelle

42 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Join query 2 e 3

43 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse SQL query 2 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; km in missioni per area agenzia e tipo missione

44 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse SQL query 3 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; km in missioni per area agenzia e tipo missione a Gen 2003

45 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Query di analisi Impossibilità di prevedere le query richieste Alta complessità di calcolo delle query => Interattività Riduzione del numero di tabelle

46 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse OLAP On Line Analitical Processing: Analisi in linea ma con grandi moli di dati Interattive: Non è possibile formulare a priori le richieste dellutente Lutente deve poter vedere i dati sotto tanti punti di vista E fondamentale la profondità storica dei dati

47 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Riconciliazione Cleaning Storicizzazione Subject orientation Riconciliazione Cleaning Storicizzazione Subject orientation Cesura tra dati operazionali e DW DB2 ORACLE Altre Fonti Sorgenti Eterogenee Data Warehouse DB E indispensabile disaccoppiare le esigenze operazionali da quelle decisionali. Effettuando una replica dei dati. Datawarehousing: Metadati

48 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Cesura tra dati operazionali e DW Il DW è popolato da fotografie dei dati operazionali => Lutente 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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 –lutente 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Assenza di scritture in un DW In un sistema operazionale, lutente: –aggiorna i dati (update) –li cancella (delete) –li inserisce (insert) => Normalizzazione per evitare le anomalie di inserimento, cancellazione, aggiornamento.

51 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Assenza di scritture in un DW In un Data Mart, lutente non può effettuare alcuna scrittura. –I dati verranno aggiornati solo in batch –In periodi temporali in cui lutente non vi può accedere => Niente normalizzazione Invece le strutture dati dovranno essere ottimizzate per minimizzare i tempi di risposta allutente.

52 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Esempio - Analisi del fatturato Se assegno un valore a tutte le N dimensioni del Data Mart, individuo un punto a N dimensioni che contiene uno o più fatti. Gennaio 2000 USA Business Unit 05 66,755

53 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Drill Down/Roll Up Allinterno del fatto individuato, posso incrementare il dettaglio con cui esso viene visualizzato Gennaio 2000 Europa Italia 10 gennaio Gruppo BU 05

54 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Slice & Pivoting Tempo Area geografica Settore aziendale In un Data Mart contenente N dimensioni, posso fissarne una sola ed osservare la variazione del fatto dinteresse al variare delle altre

55 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Dice Dice: Seleziono un sottocubo in base ad un criterio che fa da filtro Slice Dice

56 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Drill Across Se ho più tabelle dei fatti che condividono alcune Dimensioni, le posso mettere in relazione tra loro

57 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Operazioni OLAP Drill down: diminuisce laggregazione 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 dinteresse 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Argomenti - 1° parte 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

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

60 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Architettura a due livelli Data Marts Sorgenti Estrazione Aggregazione Loading

61 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Problemi dellarchitettura a 2 livelli Per ogni Data Mart: –va rifatta lanalisi 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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 2Sorgente 1Sorgente 3

63 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Enterprise Data Warehouse Per aziende di complessità e dimensioni rilevanti Obiettivo: –Una visione univoca e centralizzata dellintera azienda => ununica struttura di Data Warehouse per lintera azienda

64 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Vantaggi livello Riconciliato descrizione unica e completa di tutta lazienda 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Riconciliazione Cleaning Storicizzazione Subject orientation Aggregazione Riconciliazione Cleaning Storicizzazione Subject orientation Aggregazione Progetto di un Data Warehouse a 2 livelli DB2 ORACLE Altre Fonti Sorgenti Eterogenee Data Warehouse (insieme di Data Mart) DB A partire dallanalisi dei processi aziendali e dei dati presenti nei sistemi già esistenti in azienda, vengono creati gli oggetti di business da inserire nel Data Warehouse. Datawarehousing: Metadati

66 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Riconciliazione Cleaning Storicizzazione Riconciliazione Cleaning Storicizzazione Progetto di un Data Warehouse a 3 livelli DB2 ORACLE Altre Fonti Sorgenti Eterogenee Primario del Data Warehouse BDW A partire dallanalisi dei processi aziendali e dei dati presenti nei sistemi già esistenti in azienda, vengono creati gli oggetti di business da inserire nel Data Warehouse. Datawarehousing: Metadati BIW Aggregazione Subject Orientation Aggregazione Subject Orientation Data Mart Livello riconciliato Livello derivato

67 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Qual è larchitettura migliore ? Larchitettura 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 lintera azienda

68 Architettura a tre livelli – caratteristiche A questo livello vi sono le applicazioni per il supporto alle decisioni BIG DW catalog Enterprise model Popolamento Staging BIW Business Information Guide BIW: Business Information Warehouse Business Data Warehouse

69 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Terminologia - Architettura

70 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Argomenti - 1° parte 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 allarchitettura a tre livelli e con qualche modifica anche a quella a due livelli.

71 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse DW per livelli di astrazione

73 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Progettazione del Data Warehouse Un DW si realizza sempre a segmenti, mai in una volta sola. Il primo segmento deve – contenere gli aspetti più significativi – ma non avere grosse difficoltà realizzative In seguito si estenderà il DW con altri aspetti E un procedimento iterativo

74 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Approccio a segmenti

75 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Progettazione del Data Warehouse Individuazione, analisi e riconciliazione delle sorgenti Definizione delle corrispondenze e delle trasformazioni tra sorgenti e Data Warehouse Analisi requisiti utente Scelta della granularità e della politica di refresh del DW Progettazione dei Data Mart Scelta dellinterfaccia utente e caratteristiche della reportistica

76 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Costrutti Entity-Relationship

77 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Costrutti E-R

78 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Relazioni secondo Designer

79 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Dal livello concettuale al logico

80 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Reverse Engineering - dal logico al concettuale -

81 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Metodologia di riconciliazione La riconciliazione frequentemente è fatta solo a livello logico o logico-fisico –questo comporta molti errori di progettazione e nellinterpretazione dei dati Secondo questa metodologia viene svolta a livello concettuale. Lintegrazione a livello logico e fisico diviene una conseguenza del livello concettuale.

82 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Metodologia di riconciliazione Enterprise Model: E il modello concettuale di tutta la realtà che il Data Warehouse dovrà rappresentare.

83 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Metodologia di riconciliazione Elaborazione prima versione Enterprise Model –basata su interviste Per ogni sorgente Reverse engineering: –Si ottiene il modello concettuale della sorgente –Il modello concettuale di ogni sorgente deve rappresentare una visione parziale dellintera realtà dinteresse –Si generalizza lEnterprise Model per tener conto della sorgente =>Enterprise Model complessivo (fino ad ora)

84 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Metodologia di riconciliazione Scelta sullEnterprise 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Metodologia di riconciliazione Il Conceptual Data Warehouse Model –è il modello concettuale dei dati che andranno inseriti nel DW –contiene inoltre il legame tra i concetti delle sorgenti e quelli del DW –è la traccia per le successive fasi di sviluppo Si ripete il processo di riconciliazione sui livelli di astrazione più bassi (logico e fisico) –con un dettaglio sempre maggiore –fino allimplementazione

86 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Reverse Engineering Dobbiamo acquisire: –Descrizione della sorgente e del suo funzionamento operazionale –Descrizione dei campi, della loro semantica, delle codifiche, dei valori ammissibili e del loro significato Produciamo lo schema logico della sorgente Elaboriamo lo schema concettuale sorgente: –basandoci sullEnterprise Model –o generalizzandolo lEnterprise Model generalizza sempre i concetti sorgente

87 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Costruzione Enterprise Model Reverse Engineering Reverse Engineering Reverse Engineering Reverse Engineering EM 0 CM S 1 SnSn S i+1 S2S2 S1S1 EM n-1 EM i+1 EM i EM 2 EM 1 EM n CM S n CM S i+1 CM S 2 dove: EM 0 Enterprise Model iniziale EM n Enterprise Model finale CM S i Modello concettuale sorgente i-ma S i Sorgente i-ma

88 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Costruzione Enterprise Model Reverse Engineering Reverse Engineering Reverse Engineering Reverse Engineering Sintesi e omogeneizzazione EM 0 S1S1 S2S2 S i +1 SnSn CM S 1 CM S 2 CM S i+1 CM S n EM 1 EM 2 EM i+1 EM finale EM n

89 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Documentazione per ogni sorgente Descrizione fisica Descrizione semantica Descrizione logica Modello concettuale (dal reverse engineering) Corrispondenze tra livello concettuale e logico Legami tra modello concettuale della sorgente ed Enterprise Model (rappresentati nel Conceptual DW Model)

90 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Esempio - Azienda commerciale DB ordini merci: –Clienti(cod_cli, CF, denom, indirizzo) –Ordini(num_ord, cod_cli, data) –Voci_ord(num_ord, cod_prod, nome, quant) DB fatturazione: –Clienti(cod_cli, CF, rag_soc, indirizzo) –Fatture(cod_fatt, num_ord, cod_cli, data, nn_giorni_pag, importo) data e indirizzo sono gli stessi ? denom=rag_soc ?

91 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Esempio - Azienda commerciale

92 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Esempio - Azienda commerciale

93 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Esempio - Azienda commerciale

94 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Vantaggi della riconciliazione concettuale Aver eseguito la riconciliazione sul livello concettuale ha permesso di: –individuare e risolvere meglio i problemi di integrazione –avere una rappresentazione unica di tutta la realtà dinteresse –sapere come i concetti usati dalle sorgenti si inquadrano nella realtà dinteresse –avere una documentazione più leggibile anche per usi futuri

95 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Riconciliazione e architettura Questa metodologia è valida anche con larchitettura 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Progettazione Livello Derivato Livello Riconciliato: –Si parte dai dati delle sorgenti (Source driven) Livello Derivato: –Si parte dalle richieste dellutente OLAP: Che tipo di analisi dovrà svolgere ? Qual è il soggetto dinteresse ? (Subject-oriented) => Approccio Client driven

97 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Quale fonte dati per Livello Derivato? Se 3 livelli sarà Livello Riconciliato –ma non è detto che siano presenti tutti i dati Se due livelli: –dobbiamo cercare i dati tra le sorgenti operazionali –ed eseguire la riconciliazione, senza realizzare fisicamente un livello riconciliato

98 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Livello Derivato vs Livello Riconciliato Fondamentale tener conto dellefficienza delle interrogazioni –esistono apposite strutture dati La granularità deve soddisfare le richieste attuali Il Front-End deve essere amichevole (nel Livello Riconciliato il Front-End non esiste) Requisiti del Livello Derivato opposti ai requisiti del Livello Riconciliato

99 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Argomenti - 1° parte 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Seminario Fine prima parte

101 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Seminario Seconda parte

102 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Argomenti - 2° parte Realizzazione lato Back-End –Processi ETL –Scelte di progetto –Esempi realizzativi

103 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse DW per livelli di astrazione

104 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Elaborazioni per un Data Warehouse ETL: Extraction, Trasformation, Loading Estrazione Trasform. e Cleaning Inserimento Aree di Staging

105 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Cleaning Esempio di sorgente inaffidabile:

106 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Tipologie di errori Duplicazione dei dati –molte varianti di un nome che indicano la stessa cosa –duplicazione della chiave (o dellintero record se non ci sono chiavi) –record con chiavi logiche differenti corrispondenti agli stessi oggetti reali Violazione di integrità referenziale (concettuale o logica)

107 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Tipologie di errori Dati incompleti o assenti Campi che concettualmente sono chiave a null Valori fuori dal dominio Violazione di vincoli complessi che riguardano più tabelle

108 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Trattamento del dato sporco Gettare Gettare, conservando statistiche su cosa si getta Conservare per sottoporre a correzione manuale Conservare per correggerlo con gli aggiornamenti successivi –le sorgenti hanno tempi diversi tra loro

109 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Cleaning Necessario: i dati sorgente sono sempre inaffidabili Difficoltoso: dipende dal contenuto dei dati e dal loro significato, non dallo schema Richiede una politica del dato sporco Evidenzia miglioramenti da fare sulloperazionale

110 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Problemi connessi al cleaning Uso delle strutture dati diverso da quello originariamente previsto Mismatching: da sorgenti diverse, quali dati si riferiscono allo stesso oggetto reale ?

111 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Trasformazioni Tipologie di trasformazioni: –Sostituzione chiavi –Separazione e Concatenazione –Conversione –Arricchimento –Normalizzazione e Denormalizzazione –Aggregazione –Storicizzazione Una trasformazione può appartenere a più tipologie Spesso i programmi effettuano le trasformazioni contemporaneamente al Cleaning

112 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Trasformazioni Requisito generale: Una qualsiasi variazione su una sorgente non deve necessitare di alcuna modifica sul DW e solo modifiche minime al software –esempio aggiunta di un record ad una tabella

113 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Trasformazioni - Esempio Acquisizione valute: –Supponiamo di avere più sorgenti con valori monetari –alcune hanno già fatto la conversione allEuro, 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à allEuro basterà: inserire un nuovo record o aggiornare un record esistente

114 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Trasformazioni - Chiavi surrogate Motivi: –la sorgente può riciclare le sue chiavi dopo un lungo periodo –unapplicazione gestionale può essere sostituita –due aziende si possono fondere, … Né su un DM né su un DW vanno mai, per nessun motivo, riutilizzate le chiavi delle sorgenti

115 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Trasformazioni - Chiavi surrogate I valori delle chiavi utilizzati nelle sorgenti vengono sostituiti con valori numerici interi generati. A questo scopo: –Saranno necessarie apposite tabelle di decodifica (chiave sorgente -> chiave DW) –nel processo di caricamento si dovrà prima: decodificare le chiavi sorgente o, se si tratta del primo ingresso, generare una nuova chiave DW In Oracle esistono le Sequence per generare valori numerici univoci

116 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Trasformazioni - Chiavi surrogate Estrazione Trasform. e Cleaning Inserimento Tabelle decodifica Sostituzione chiavi

117 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Separazione/concatenazione

118 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Trasformazioni - Esempi and ( instr(descrizione, 'SEMES',1,1)!=0 or instr(descrizione, 'SEM.',1,1)!=0 or instr(descrizione, 'SEM ',1,1)!=0 or instr(descrizione, 'SEM)',1,1)!=0 or (LENGTH(descrizione)- instr(descrizione, 'SEM',-1,1))=2 ) Esempio di Separazione: –Individuazione delle materie di esame che valgono mezza annualità:

119 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Conversione

120 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Trasformazioni - Esempi create or replace Function esame_sup (v integer) Return integer as begin if ((v>=18) or (v=7)) then return 1; else return 0; end if; end esame_sup; Esempio di conversione –Individuazione degli esami superati Le prove di lingua con esito positivo sono memorizzate dal CED La Sapienza con voto=7

121 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Arricchimento

122 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Arricchimento - varianti Singolo campo: –1 campo -->1 o più campi Multi campo: – più campi stesso record -->1 o più campi Multi record: –più campi di diversi record --> 1 o più campi Multi sorgente: –più campi di diverse sorgenti --> 1 o più campi

123 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Normalizzazione/Denormalizzazione

124 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Aggregazione Aggrega i dati a livello di record Li porta da un maggior livello di dettaglio ad uno minore => riduce la granularità Non usata per BDW Molto usata per BIW (Data Mart)

125 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Aggregazione - Esempio Aggregazione geografica: –Se lutente 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 lutente cambia le associazioni, basterà modificare un record della tabella.

126 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Storicizzazione dei dati Nei sistemi operazionali: –spesso la modifica comporta sovrascrittura –un record può essere cancellato fisicamente –anche se la sorgente tiene traccia delle modifiche lo farà su un tempo limitato Nel livello riconciliato del Data Warehouse: –si deve conservare la storia completa dei dati aziendali Nel Data Mart: –si svolgono analisi sulla storia dei dati

127 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Cosa succede nella realtà Vi è una transazione di business: –evento del mondo reale riguardante lazienda essa genera più modifiche ai dati –anche su più tabelle –le modifiche possono essere di tutti i tipi: cancellazione, aggiornamento, creazione di record

128 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Approccio a Stati Informazioni esplicite toto t1t1 t2t2 tntn Informazioni implicite Trasf. 1Trasf. n Stato iniziale Stato n Stato 2 Stato 1 Trasf. 2

129 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Approccio ad Eventi Informazioni esplicite toto t1t1 t2t2 tntn Informazioni implicite Trasf. 1Trasf. 2Trasf. n Stato iniziale Stato n Stato 2 Stato 1

130 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Confronto Eventi e Stati A stati: –E la forma più utilizzata –più intuitivo e corrispondente alle nostre esigenze –richiede maggior spazio di storage –è possibile la conversione in eventi confrontando coppie di stati adiacenti Ad eventi: –Usato soprattutto nei Log –occupa meno storage –la conversione è possibile ma costosa da calcolare

131 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Definizione dei dati e tempo Transienti: –modifiche dei record distruggono fisicamente il precedente contenuto dei dati –è la situazione tipica dei dati operazionali Periodici (storicizzati): –una volta che un dato è entrato nel DB, le informazioni che porta non possono essere modificate –struttura ad eventi o a stati Snapshot: –è una fotografia dei dati ad un certo istante –ma presi in modo completo e coerente

132 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Rappresentazione sul DB Singolo timestamp –la chiave sul DB è la chiave di business, più listante di inizio validità del dato –ideale per struttura ad eventi, inefficiente per quella a stati Doppio timestamp –alla chiave viene aggiunto un campo con listante di fine validità –per lo stato corrente useremo un valore speciale Null o meglio Data_futura Data_futura: Data convenzionale che indica che levento deve ancora avvenire (Es. 01/01/3000 ; 31/12/9999)

133 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Rappresentazione sul DB Action flag: Indica loperazione che ha modificato il dato. A: insert C: update D: delete Si utilizza raramente

134 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Esempio - Storicizzazione Supponiamo che il paese di Colleferro fino al 1/1/2000 sia in provincia di Roma e poi divenga provincia di Frosinone. Sorgente, tabella Anagrafica comuni: DW: Update

135 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Elaborazioni per un Data Warehouse Estrazione Trasform. e Cleaning Inserimento

136 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Estrazione dei dati Obiettivo: –loperazionale 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Modalità di Estrazione Estrazione statica: –Prendo una foto della sorgente ad un certo istante –Usata solo per il primo popolamento oppure –se la sorgente è completamente storicizzata e piccola

138 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Estrazione dei dati Estrazione incrementale: –Estraggo solo le variazioni avvenute nella sorgente. –Poi devo saper ricostruire i dati in modo valido. –Rispetto alla Statica è più efficiente (meno dati), ma più complessa da sviluppare. –ha molte varianti:

139 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Estrazione incrementale Cattura immediata: –Application assisted –Triggered capture (RDBMS sorgente) –Log capture: usa il Log del RDBMS per ricostruire i dati –sono le più efficaci, ma di difficile applicazione; infatti: I Log o non ci sono o sono in formato proprietario Gli operazionali mal sopportano modifiche e appesantimenti finalizzati al DW

140 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Estrazione incrementale Cattura differita –basata su timestamp della sorgente –basata su confronto (Delta):unestrazione statica viene confrontata con lestrazione 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Calcolo del Delta E la differenza tra due estrazioni statiche (fotografie) Deve cogliere le seguenti operazioni avvenute sulla sorgente: –Update –Insert –Delete Con alcuni RDBMS si può svolgere in SQL Oppure con appositi programmi di confronto tra file di testo

142 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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: select * from estraz_ precedente Minus select * from estraz_corrente Un Update sulla chiave equivale ad una Delete + una Insert

143 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Estrazione dei dati Motivazione: –ogni sorgente ha le sue caratteristiche tecnologiche –il tempo di vita dei dati nelle sorgenti è differente Ogni sorgente ha le sue modalità di estrazione Lestrazione di sorgenti diverse spesso si deve fare in momenti diversi

144 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Sincronizzazione sorgenti Uninformazione sul DW potrebbe essere formata da dati provenienti da più sorgenti. Saranno necessarie apposite tabelle di appoggio per sincronizzare le sorgenti relativamente a quellinformazione

145 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Estrazione Trasform. e Cleaning Inserimento Elaborazioni per un Data Warehouse

146 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Loading (Apply) Il metodo più generale è il: Constructive Merge –si parte sempre da unestrazione incrementale (es. Delta) –per ogni dato sullestrazione 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 listante di modifica con listante di estrazione

147 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Argomenti - 2° parte Realizzazione lato Back-End –Processi ETL –Scelte di progetto –Esempi realizzativi

148 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Granularità E il livello di dettaglio delle informazioni In un BDW è scelto in base: –dettaglio presente sulle sorgenti –alle interrogazioni che potrebbero servire oggi –alle interrogazioni che potrebbero servire in futuro Si cerca di scegliere il max –ma è molto costoso Va pianificata la crescita dei dati –e fatti dei compromessi

149 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Granularità In un BIW è scelta in base: –Ai requisiti utente attuali –in minima parte a quelli futuri –alla granularità del BDW Anche qui va pianificata la crescita

150 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Granularità - Esempio Traffico Telecomitalia: –2 chiamate al giorno per persona => 100 milioni di record al giorno –Se profondità storica 5 anni: 1800 gg x 100M =180G –almeno 100 byte per record => 18 Terabyte Non è fattibile !

151 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Scelta modalità di aggiornamento Le scelte per Estrazione e Inserimento sono strettamente correlate Entrambe dipendono da: –considerazioni politiche –considerazioni tecnologiche Periodicità dellaggiornamento: –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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Metadati Dati che descrivono i dati Si dividono in –Usage Metadata: metadati per lutente –Build-time metadata: metadati creati durante il progetto e lo sviluppo –Control metadata: metadati finalizzati allamministrazione del sistema

153 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Usage Metadata Devono indicare allutente: –quali informazioni trova –lorganizzazione 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Build-time metadata Documentano il contenuto del DW e le scelte fatte nella costruzione Sostanzialmente è la documentazione di progetto –Si ricordi che il DW si realizza a segmenti –Il progetto complessivo può richiedere diversi anni –Ci possono lavorare molte persone => E importante che la documentazione sia ordinata, aggiornata e comprensibile ai progettisti

155 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Control metadata Sono rivolti allamministratore del DW. Documentano le operazioni da svolgere o svolte. Per esempio: –Lesito delle elaborazioni. –I tempi di elaborazione e lo spazio occupato. –I punti critici del sistema. –Cosa fare in caso di problemi.

156 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Metadati - problemi Anche i metadati sono dinamici E molto importante tenerli aggiornati e storicizzati Purtroppo ciò è difficile, poiché di solito laggiornamento va fatto a mano. E molto difficile integrare i metadati con il resto del progetto.

157 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Argomenti - 2° parte Realizzazione lato Back-End –Processi ETL –Scelte di progetto –Esempi realizzativi

158 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Esempio realizzativo Progetto 6NMS: –Data Mart per gli allarmi di guasto delle centrali telefoniche. –Realizzato con unarchitettura a due livelli. –Ununica sorgente alimentante.

159 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Passi caricamento 6NMS Caricamento_6NMS.doc

160 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Esempio trasformazioni ALGORITMO controllo_MOI: Cerca nella stringa dingresso il testo UNKNOWN Cerca nella stringa dingresso il testo tra ptr-id= e /. Verifica il valore con i valori ritenuti accettabili nella tabella di decodifica. Cerca nella stringa dingresso il testo tra plmn-id= e /. Verifica il valore con i valori ritenuti accettabili nella tabella di decodifica.

161 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Tabelle di Decodifica 6NMS CREATE TABLE wsnv_dec_severita ( severita_nms NUMBER NOT NULL, severita_id NUMBER(8,0) NOT NULL, CONSTRAINT PK_WSNV_DEC_SEVERITA PRIMARY KEY SEVERITA_NMS );

162 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Ciclo di vita Preliminari: Definizione obiettivi –Scelta architettura –Individuazione Prima fase (Pilota) Definizione requisiti utente Censimento basi dati aziendali Definizione 1° versione Enterprise Model

163 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Ciclo di vita Fase n°: Analisi requisiti utente Scelta nuove sorgenti Reverse Engineering sorgenti Riconciliazione=>nuovo Enterprise Model eventuale ristrutturazione base dati Livello Riconciliato Mapping con le sorgenti Progettazione Data Mart Implementazione ETL e Data Mart Configurazione Front-End e/o report

164 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Ciclo di vita Attività di manutenzione: Schedulazione ETL Monitoraggio tempi e spazi occupati Manutenzione evolutiva: Configurazione Front-End e nuovi report Modifica Data Mart per nuova reportistica Modifica Data Mart per cambiamenti nelle sorgenti

165 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Prodotti commerciali per DW Prodotti per ETL –Data Stage di Ascential –Powermart di Informatica –Oracle Warehouse Builder –Data Integrator di Business Objects Prodotti per Data cleaning –Suite di Ascential Prodotti per il Front-End –Business Objects –Oracle Express (db Molap) –Oracle Discoverer Prodotti integrati –SAS

166 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Figure professionali Esperti dominio dati sorgente Progettista Data Warehouse (capo progetto) Analisti dei dati (con capacità di sintesi) Programmatori o esperti prodotto ETL DBA per Data Warehouse Esperto prodotto di Front-End Addetti alla reportistica Project manager

167 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Bibliografia W. H. Inmon. Building the Data Warehouse. J. Wiley & Sons, 1996 Barry Devlin. Data Warehouse, from architetture to implementation. Addison Wesley, 1997 R. Kimball. The Data Warehouse toolkit. J. Wiley & Sons, 1996 R. Kimball & al. The Data Warehouse lifecycle toolkit. J. Wiley & Sons, 1998 M.Golfarelli, S. Rizzi. Data Warehouse, Teoria e pratica della progettazione. McGraw-Hill, 2002

168 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Seminario Fine seconda parte

169 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Seminario Terza parte

170 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Operazioni OLAP Drill down: diminuisce laggregazione 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 dinteresse 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Fatti X Dimensioni 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 allinterno del cubo, contenente linformazione cercata. Tempo Area geografica Settore aziendale

173 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse I fatti Sono i fatti o gli eventi che permettono di comprendere landamento dellazienda. I fatti sono loggetto dellanalisi. Misure: grandezze che rappresentano i fatti misurandoli Le misure sono sempre numeriche. Esempi: numero di clienti, incasso, numero esami, voto esame, numero di fatture Esempi: Vendite, Esame universitario, Acquisti

174 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Le dimensioni Tutti i possibili criteri di selezione dei dati. 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. Esempi: Tempo, Luogo, Settore aziendale, Fascia di reddito

175 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Attributi e Gerarchie Gerarchie: Come è possibile aggregare le misure dei fatti sono lordine con cui possiamo navigare tra gli attributi delle Dimensioni per aggregare i fatti. Esempi: Mese, Anno, Città, Business Unit, Reddito tra 10 e 20 mila Attributi: Le grandezze che formano le Dimensioni Esempio: città->regione->nazione->continente Sono sempre grandezze discrete.

176 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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

177 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Modello Multidimensionale - Esempio In una catena di negozi il processo modellizzato (fatto) è tipicamente il Processo di Vendita. Dimensione Prodotto: Prodotto Marca Categoria Dimensione Tempo: Giorno Mese Anno Dimensione Negozio: Negozio Città Regione Fatto: Processo di Vendita Misura2: Incasso vendita Misura1: Quantità venduta Gerarchie

178 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse La struttura Data Cube Negozio Tempo Prodotto Quant. venduta Incasso vendita

179 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Modellazione concettuale gli E-R devono modellare una realtà dinteresse Adesso devo anche modellare cosa interessa allutente –cosa gli interessa analizzare –come organizzare le cose da vedere –con quali livelli di aggregazione =>Scelta Dimensioni e Gerarchie non banale

181 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Dimensional Fact Model - Esempio DFM: un formalismo grafico per la rappresentazione di uno schema multidimensionale.

183 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Sintesi Dimensional Fact Model Si parte dallE-R dei dati aziendali e dai Subject dinteresse per lutente –nel caso il Fatto dinteresse sia una relazione va trasformata in entità (Reificazione) Si costruisce lalbero degli attributi seguendo le relazioni molti a uno In base ai requisiti utente si ristruttura lalbero degli attributi

184 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Esempio - Schema E/R del DB Vendite Collocato Appartiene Gestito NegozioScontrino Fiscale Prodotto TipoCategoria Città Manager negozioindirizzodata numero scontrino prodotto dimensione costruttore tipo stato città categoria manager Vendita Emette (0,n) (1,n) (1,1) (1,n) (0,n) (1,1) (0,n) (1,n) (1,1) (1,n) quantità venduta prezzo unitario

185 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Esempio - Reificazione di vendita Collocato Appartiene Gestito Negozio TipoCategoria Città Manager negozioindirizzodata numero scontrino prodotto dimensione costruttore tipo stato città categoria manager Emette (0,n) (1,n) (1,1) (1,n) (0,n) (1,1) (0,n) (1,n) (1,1) (1,n) quantità venduta prezzo unitario Scontrino Fiscale Prodotto registra Vendita di prodotto (1,1)

186 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Algoritmo per DFM Identificazione dei Fatti e relative misure Per ogni fatto: identificazione del Fatto sullER Lentità 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Albero degli attributi

189 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Ristrutturazione dellalbero degli attributi Eliminare i nodi che non ci interessano Aggiungere nodi: –se da un nodo si possono calcolare altre informazioni dinteresse –allora genera dei figli identificare o generare le misure => Le dimensioni possibili saranno i figli della radice scegliere Dimensioni e granularità Identificare le gerarchie dinteresse

190 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Albero degli attributi ristrutturato

191 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse DFM Vendite Requisito utente: analisi delle vendite Subject: Vendite

192 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Albero degli attributi ristrutturato

193 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse DFM Clienti Requisito utente: analisi afflusso clienti Subject: Clienti

194 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse DFM Clienti-Vendite Requisito utente: analisi Vendite e Clienti Subject: Vendite n° clienti non è aggregabile sulla Dimensione Prodotto

195 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse DFM Vendite Questi attributi definiscono la granularità

197 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse ROLAP - Star Schema Ha una struttura simmetrica con una tabella centrale dei fatti e alcune tabelle di dimensioni.

198 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Tabelle delle Dimensioni Un campo per ogni attributo della Dimensione I valori di questi campi devono essere comprensibili agli utenti La chiave rappresenta lattributo al livello più basso della Gerarchia La chiave non è visibile agli utenti e sarà numerica

199 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Tabella dei fatti Ogni record rappresenta un fatto elementare Un campo per ogni misura del Fatto Chiave composta con le chiavi delle Dimensioni

200 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Più tabelle dei fatti Diverse tabelle dei fatti possono condividere alcune Dimensioni Incasso medio per cliente: ottenibile con un drill across

201 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Chiavi surrogate Le chiavi delle Dimensioni sempre: –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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Efficienza delle interrogazioni DB normalizzato: 13 tabelle 9 join Star schema: 4 tabelle 3 join Query: Incasso settimanale della categoria di prodotto alimentari suddivisa per stato Lo schema a stella permette di ridurre il numero di join richiesti dalle interrogazioni e guida lutente nella scelta di query sensate

203 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Efficienza delle interrogazioni 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; Incasso settimanale della categoria di prodotto alimentari suddivisa per stato

204 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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 lutente

206 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Preaggregazione - Esempio Se i prodotti sono molto numerosi e spesso si richiedono report che non dettagliano i prodotti

207 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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 dinterrogazione ho risparmiato un join con la tabella dei fatti.

208 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Dimensioni degeneri - Junk Dimension Se per una tabella dei fatti ho più dimensioni degeneri: –Creo ununica tabella dimensione per tutte le degeneri –con un campo per ogni dimensione –ed ununica 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Snowflake Schema F_- - -

211 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Dimensioni condivise Esempio: –Città di nascita e Città di residenza Sono due attributi dimensionali che condividono la stessa gerarchia, –con stessa granularità. Avrò ununica 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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 lutente può essere importante tener conto di questa variabilità. Le chiameremo: Dimensioni dinamiche

214 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Dimensioni dinamiche - Esempio Lutente vuole comparare le vendite dei negozi in funzione del Manager che li dirige. Ma i manager possono cambiare nel tempo. => Lutente otterrà dei report con significato diverso da quello atteso.

215 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Dimensioni dinamiche - Esempio

216 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Esempio NegozioManager ARossi BBianchi Situazione al 1/1/2001: NegozioManager ABianchi B CRossi Situazione al 1/1/2002: Fatti: NegozioDataIncasso A8/2/ B18/10/ A8/2/ B18/10/ C5/7/ Report al 31/12/2001: ManagerIncasso Rossi300 Bianchi100 Report al 31/12/2002: ManagerIncasso Rossi50 Bianchi600

217 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Dimensioni dinamiche Deve essere possibile interpretare le misure in funzione della storia Aggregare diversamente le misure La dinamicità può riguardare: –Lattributo in se stesso, per es. il nome del negozio --> raramente necessita di dimensione dinamica –la relazione tra due attributi, cioè larco della gerarchia, per es. il manager A volte in una stessa Dimensione attributi diversi vanno interpretati diversamente

218 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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 ununica situazione presente in un certo istante scelto dallutente Assenza di storia -Tipo 1- Ogni fatto viene interpretato in base allunica situazione attualmente presente Report diversi possono richiedere differenti interpretazioni di uno stesso attributo

219 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Dimensione con Verità storica Se per un attributo dimensionale è richiesta: –Esclusivamente la Verità storica Id_NegozioNomeManager 11ARossi 12BBianchi 156ABianchi 162CRossi Per ogni variante: genero un nuovo record dimensionale –con stesso identificativo sorgente (Nome) –ma diversa chiave surrogata (Id_negozio) Verità storica su Manager –Non ho bisogno di filtri particolari –E lo stesso Id_negozio a registrare la storia

220 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Storicizzazione completa Soluzione generale, ma molto costosa: Id_NegozioDalAlNomeManagerMaster 11 1/1/20011/1/2002 ARossi /1/20011/1/2002 BBianchi /1/20021/6/2003 ABianchi /1/2002Data_futura CRossi /6/2003Data_futura AABianchi11 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Utilizzo Storicizzazione Se soluzione generale: –Verità storica: nessun filtro particolare –Tempo a scelta: data_richiesta >= DAL and data_richiesta

222 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Utilizzo Storicizzazione Tempo a scelta - con soluzione generale : Select * From Negozio as Intestazione Where data_richiesta >= DAL and data_richiesta

223 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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

224 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Indici Bitmap Sono basati su stringhe di bit –per ogni record vi è una stringa sullindice –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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Esempio con Bitmap

228 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Esempio con Bitmap Dimensioni, B-Tree su Primary key: –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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Struttura logica MOLAP In memoria: un array ad n dimensioni ogni valore dellarray rappresenta un fatto (le misure) o una sua aggregazione Tempo Prodotto Negozio un cubo conserva tutti i fatti elementari e tutte le sue possibili aggregazioni in modo esplicito

230 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse MOLAP e ROLAP MOLAP: –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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Moduli di Business Object Designer: crea gli Universi, una vista dei dati semplificata per lutente. 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 delloggetto considerato. Business object: per la creazione dei report utilizzando gli oggetti già definiti nelluniverso.

236 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse B.O. Designer - Visione del DB

237 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Business Objects - Report

238 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Realizzazione del Front-end Report dinamici: permettono operazioni OLAP –richiedono allutente 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 –lutente può non avere nessuna conoscenza del prodotto

239 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Schema concettuale Gioco del Lotto ER_Lotto.doc

241 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse DFM Ricerca situazioni anomale Il n° di giocate non è aggregabile in base alla Sorte

242 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse DFM Ricerca giocate anomale Il n° di giocate non è aggregabile in base alla Sorte

244 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Stima spazio occupato - Situazioni Numero di record lanno: 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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 lanno*n° puntate per giocata pari a 35*10^6*104*3 = 1.1*10^10 record l'anno

246 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 6NMS - DFM Insorgenze singole

247 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 6NMS - DFM Condizioni allarme

248 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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_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 ); 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, descrizione VARCHAR2(80) 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, descrizione VARCHAR2(80) NOT NULL ); CREATE TABLE dm_severita( severita_id NUMBER(8,0) NOT NULL, descrizione VARCHAR2(80) NOT NULL );

249 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse 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 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Seminario Fine terza parte

251 © Michele RiccioFacoltà Ingegneria - Lezioni sul Data Warehouse Seminario Fine


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

Presentazioni simili


Annunci Google