Data Warehouse - Progettazione

1. Data Warehouse - Progettazione Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

2. Fattori di rischio • Aspettative elevate degli utenti • Gli utenti vogliono che la data warehouse sia progettata in modo che vengano risolti i problemi aziendali • Qualità dei dati e dei processi OLTP di partenza • I dati delle sorgenti sono incompleti o inaffidabili perchè gli applicativi back-end non fanno tutti i controlli necessari. Spesso attributi non valorizzati. • Gestione «politica» del progetto • Collaborazioni con i detentori delle informazioni che vogliono partecipare alle scelte di progettazione e impongono le loro idee con forza • Accettazione del sistema da parte degli utenti finali Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

3. Progettazione • Approccio Top-Down • Abbandonato, troppo costoso • Tempo di realizzazione lungo • Analisi e progettazione complesse • Realizzazione di una data warehouse che fornisca una visione globale e completa dei dati aziendali • Approccio Bootm-Up • Realizzazione incrementale, aggiungendo data martdefiniti su settori aziendali specifici • Costo e tempo di consegna contenuti • Focalizzato separatamente su settori aziendali specifici • Una volta progettato un data mart si possono già avviare operazioni ETL e successivamente di analisi su quello specifico settore Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

4. Kimball Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

5. Kimball Nella progettazione di una Data Warehouse entrano in gioco diversi attori: • Hardwerista / sistemista (parte rossa) • Si occupa della scelta dei server, macchine, dischi, selezione del software da usare • Progettazione dell’architettura • DBA • Progettazione fisica • Alimentazione della DW • Creazione di trigger, procedure, job notturni per aggiornare le viste Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

6. Kimball • Sviluppatore software • Definizione report(BI) • Creazione interfacce • Sviluppo applicazioni ad hoc e non per gli utenti finali Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

7. Progettazione di Data Mart Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

8. Analisi dei requisiti • Analisi dei requisiti • Raccoglie le esigenze dei dati che dovranno essere soddisfatte dal data mart • Vincoli realizzativi (hardware e software) • Vengono definite le fonti delle informazioni (business users, amministratori del sistema informativo) • Il data mart prescelto è strategico per l’azienda alimentato da poche sorgenti (db) affidabili. • Requisiti applicativi • Descrizione degli eventi di interesse (fatti) • Caratterizzati da dimensioni descrittive e misure di interesse • Es: reclami, vendite, servizi,… Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

9. Analisi dei requisiti • Descrizione del carico di lavoro • Esame della reportistica aziendale • Interrogazioni espresse in linguaggio naturale • Es: numero di reclami per ciascun prodotto nell’ultimo mese • Requisiti strutturali • Periodicità dell’alimentazione • Spazio disponibile • Per i dati • Per strutture accessorie (indici, viste materializzate) • Tipo di architettura • Data Mart dipendenti o indipendenti • Numero di livelli (1, 2 , 3 visti prima) Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

10. Progettazione concettuale Il modello ER non è adatto, troppe tabelle, troppi join per costruire l’informazione. Usare il DFM (DimensionalFact Model): • Per uno specifico fatto (evento di interesse), definire: • Dimensioni • Misure • Gerarchie • Offre una documentazione di progetto utile sia per la revisione dei requisiti con gli utenti, sia a posteriori. Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

11. Progettazione concettuale Fatto: • Modella un insieme di eventi di interesse (vendite, spedizioni, reclami) • Evolve nel tempo Dimensione: • Descrive le coordinate di analisi di un fatto • È formata da numerosi attributi, tipicamente di tipo categorico • Es: ogni vendita è descritta dalla data di effettuazione, dal negozio e dal prodotto venduto. Misura: • Proprietà numerica di un fatto, spesso oggetto di operazioni di aggregazione (ad ogni vendita è associato un incasso) Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

12. Progettazione concettuale Gerarchia: Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

13. Progettazione concettuale La gerarchia rappresenta una relazione di generalizzazione tra un sottoinsieme di attributi di una dimensione. Dalla DFM è possibile generare il diagramma ER: Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

14. Progettazione concettuale Costrutti avanzati: • Gli attributi con il pallino sono utili per raggruppamenti • Quelli senza, sono solo descrittivi • Quelli «tagliati» sono opzionali Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

15. Progettazione concettuale Costrutti avanzati: • A volte conviene creare una gerarchia condivisa per limitare la dimensione della DW. Una telefonata ci sono sempre 2 attori in cui a ruolo si inverte (mittente – destinatario) Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

16. Progettazione concettuale Aggregazione Processo di calcolo del valore di misure a granularità meno fine di quella presente nello schema di fatto originale. • La riduzione del livello di dettaglio è ottenuta risalendo lungo la gerarchia(andando verso l’alto: ROOL UP) • es: group by negozio mese  group by città, mese o group by città • operazione inversa: DRILL DOWN: riduzione del livello della gerarchia o aggiunta di una nuova dimensione • es: group by città  group by città, mese • Operatori di aggregazione SUM, MIN, MAX, AVG, COUNT Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

17. Progettazione concettuale COUNT: Quadrimestre-Prodotto Aggregazione SUM: Sono risalito, - dettaglio, categoria-quadrimestre (ROOL UP) Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

18. Progettazione concettuale Aggregazione SUM: Anno-Tipo Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

19. Progettazione concettuale Aggregazione Categoria - Anno Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

20. Progettazione concettuale Aggregazione Per arrivare all’aggregazione «arancione» si poteva passare anche da quella «verde» (meno tuple rispetto alla tabella dei fatti) o da quella «viola». Queste aggregazioni sono TUTTE viste aggregate. Vengono fatti dei GROUP BY e delle SUM oppure delle PARTITION con OVER BY. Si poteva arrivare all’aggregazione «verde» dalla «viola» o dalla «arancione»???NO, mi manca il TIPO Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

21. Progettazione concettuale Operatori di aggregazione: • Distributivi • Sempre possibile il calcolo di aggregati da dati a livello di dettaglio maggiore (visti prima) • Esempi: SUM, MIN, MAX • Algebrici • Esempio AVG • Il calcolo di aggregati da dati a livello di dettaglio maggiore è possibile in presenza di misure aggiuntive di supporto (es: conteggio di elementi per il calcolo della media = # di elementi nel gruppo) Non si può calcolare la media a partire da una media che abbiamo già calcolato . Funziona solo se c’è bilanciamento: STESSO NUMERO DI RIGHE ( o voci ). Quindi per il passaggio da MEDIE PARZIALI a MEDIE TOTALI ho bisogno del COUNT. Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

22. Progettazione concettuale dettaglio ridotto ROLL UP Media diversa!! Se però mi fossi portato dietro il COUNT si sarebbe potuto fare: 2.17(3), 1.35(2) (2.17*3 + 1.35 * 2)/5 = 1.84 Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

23. Progettazione concettuale Schema di Fatto VUOTI • Registra il verificarsi o no di un evento • Utile per conteggio di eventi accaduti • Rappresentazione di eventi non accaduti (insieme di copertura) • Non sono presenti misure, se è presente un record nella tabella dei fatti, significa che quel certo utente ha frequentato quel corso in quel semestre. Frequenza Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

24. Progettazione concettuale Rappresentazione del tempo La variazione dei dati nel tempo è rappresentata esplicitamente dal verificarsi degli eventi. • Presenza di una dimensione temporale • Eventi memorizzati sotto forma di fatti Possono variare nel tempo anche il contenuto delle dimensioni (UPDATE di attributi descrittivi) • Variazione tipicamente più lenta • Es: dati anagrafici di un cliente, descrizione di un prodotto (UPDATE su db operazionali). E’ necessario prevedere esplicitamente nel modello come rappresentare questo tipo di variazione. Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

25. Progettazione concettuale Rappresentazione del tempo TIPO 1 Fotografia dell’istante attuale (la + semplice e + veloce) • Esegue la sovrascrittura del dato con il valore attuale • Proietta nel passato la situazione attuale Es: Il cliente Mario Rossi cambia stato civile dopo il matrimonio. Tutti i suoi acquisti sono attribuiti al cliente «sposato» (sia quelli passati che quelli futuri). Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

26. Progettazione concettuale Rappresentazione del tempo TIPO 2 Vesioning, eventi attribuiti alla situazione temporalmente corrispondente della dimensione. (Storicizzo MA non so quando inizia, parziale) • Per ogni variazione di stato della dimensione • Si crea una nuova istanza nella dimensione • I nuovi eventi (della tab. dei fatti) sono correlati alla nuova istanza (nuovo id) • Gli eventi sono partizionati in base alle variazioni degli attributi dimensionali. • Es: Il cliente Mario Rossi cambia stato civile dopo il matrimonio. I suoi acquisti nella tabella dei fatti saranno partizionati in acquisti da «celibe» e acquisti da «sposato» Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

27. Progettazione concettuale Rappresentazione del tempo TIPO 3 Storicizzazione completa. Campionamento in uno specifico istante di tempo. Più complessa. Più raffinata. • Richiede una gestione esplicita delle variazioni della dimensione nel tempo. • Modifica dello schema della dimensione • Introduzione di una coppia di timestamp che indicano l’intervallo di validità del dato (inizio e fine validità) • Introduzione di un attributo che consenta di identificare la sequenza di variazioni di una specifica istanza (master) • Ogni variazione di stato della dimensione richiede la definizione di una nuova isatanza Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

28. Progettazione concettuale Rappresentazione del tempo TIPO 3 • Es: Il cliente Mario Rossi cambia stato civile dopo il matrimonio. La prima istanza conclude il suo periodo di validità il giorno del matrimonio. La nuova istanza inizia la sua validità nello stesso giorno. Gli acquisti sono separati come nel caso precedente. Esiste un attributo che permette di ricostruire tutte le variazioni ascrivibili a Mario Rossi. (es: attributo «padre» il cui contenuto è l’ID della tupla al momento dello switch da nubile a sposato, si crea così una dimensione che punta a se stessa) es: YouTrend Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

29. Progettazione concettuale Velocizzo il reperimento delle informazioni. Evito join. Un unico predicato. Utilizzo indici che stanno in memoria (attr: padre). Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

30. Progettazione concettuale Carico di lavoro • Di Riferimento • Reportistica standard • Stime discusse con gli utenti • Reale • Difficile da stimare • Il numero di utenti e interrogazioni aumenta nel tempo • La tipologia di interrogazioni può variare nel tempo • Fase di tuning (perfezionamento) • Dopo l’avviamento del sistema • Monitoraggio del carico di lavoro Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

31. Progettazione concettuale Volume dei dati • Stima dello spazio necessario per il Data Mart • Per i dati • Per le strutture accessorie (indici, viste materializzate) • Si considerano • Numero di eventi di OGNI FATTO (Attenzione: Fatto = Data Mart NO!!) • Numero di valori distinti degli attributi nelle gerarchie (dominio di un attributo) • Lunghezza degli attributi • Dipende dall’intervallo temporale di memorizzazione dei dati. • Valutazione affetta dal problema della sparsità Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

32. Progettazione concettuale La sparsità si riduce al crescere del livello di aggregazione dei dati. Può ridurre l’affidabilità della stima della cardinalità degli aggregati. Es: invece di aggregare per trimestre aggrego per anno (quindi salgo nella gerarchia). Magari le vendite sono andate male solo in 5 mesi su 12. Nel complesso nell’anno 2011 viene un valore basso. Ma se vado a vedere a livello di trimestre sono state superiori del trimestre 2012 precedente. (SPARSITA’ dovuta all’aumentare dell’aggregazione) Dipende sempre cosa vogliamo analizzare, qual è l’obiettivo aziendale. Magari era di aumentare le vendite nel periodo invernale. Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

33. Progettazione Logica Si usa un modello relazionale chiamato ROLAP, dove gli inputs sono: • Schema di fatto concettuale • Carico di lavoro • Volume dei dati • Vincoli di sistema E gli outputs sono: • Schema logico relazionale Schema a stella Dimensioni: • Una tabella per OGNI dimensione • Chiave primaria generata artificialmente (surrogata) • Contiene tutti gli attributi della dimensione Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com

34. Progettazione Logica • Gerarchie non rappresentate esplicitamente • Gli attributi della tabella sono Francesco Pasturenzi http://www.pastuweb.com francesco.pasturenzi@gmail.com