Slide 1

1 Introduzione al data warehousing

Slide 2

2 In genere: abbondanza di dati ma anche abbondanza di ridondanza ed inconsistenza che non permette di utilizzare i dati in modo utile a fini decisionali DB4 Il problema DB1 DB3 DB2

Slide 3

3 Tipiche richieste a cui spesso difficile dare una risposta Qual il volume delle vendite per regione e categorie di prodotto durante lultimo anno? Come si correlano i prezzi delle azioni delle societ produttrici di hardware con i profitti trimestrali degli ultimi 10 anni? Quali sono stati i volumi di vendita dello scorso anno per regione e categoria di prodotto? In che modo i dividendi di aziende di hardware sono correlatiai porfitti trimestrali negli ultimi 10 anni? Quali ordini dovremmo soddisfare per massimizzare le entrate?

Slide 4

4 Possibili applicazioni gestione dei rischi analisi finanziaria programmi di marketing analisi statistica integrazione DB clienti integrazione relazioni clienti analisi temporale telecomunicazioni banking universit assicurazioni beni di consumo salute produzione contesti problematiche

Slide 5

5 Sistemi informatici: una classificazione Transaction processing systems: per i processi operativi Decision support systems: fortemente integrati, di supporto ai processi direzionali Richiedono operazioni non previste a priori Coinvolgono spesso grandi quantit di dati, anche storici e aggregati Coinvolgono dati provenienti da varie fonti operative, anche esterne

Slide 6

6 In sintesi... dati conoscenza utile allazienda sistemi di supporto alle decisioni (DSS) DSS: Tecnologia che supporta la dirigenza aziendale nel prendere decisioni tattico-strategiche in modo migliore e pi veloce

Slide 7

7 Perch i sistemi tradizionali non sono sufficienti? no dati storici sistemi eterogenei basse prestazioni DBMS non adeguati al supporto decisionale problemi di sicurezza

Slide 8

8 Sistemi tradizionali On-Line Transaction Processing (OLTP) Sistemi di data warehousing On-Line Analytical Processing (OLAP) Profondamente diversi Pi formalmente...

Slide 9

9 In dettaglio...

Slide 10

10 Evoluzione dei DSS Anni 60: rapporti batch difficile trovare ed analizzare i dati costo, ogni richiesta richiede un nuovo programma Anni 70: DSS basato su terminale non integrato con strumenti di automazione dufficio Anni 80: strumento dautomazione dufficio strumenti di interrogazione, fogli elettronici, interfacce grafiche accesso ai dati operazionali Anni 90: data warehousing, con strumenti integrati OLAP

Slide 11

11 I sistemi di data warehousing Il Data Warehousing si pu definire come il processo di integrazione di basi di dati indipendenti in un singolo repository (il data warehouse) dal quale gli utenti finali possano facilmente ed efficientemente eseguire query, generare report ed effettuare analisi

Slide 12

12 Client Warehouse Source Query & Analysis Integration Metadata I sistemi di data warehousing

Slide 13

13 Il data warehouse Collezione di dati che soddisfa le seguenti proprieta`: usata per il supporto alle decisioni orientata ai soggetti integrata: livello aziendale e non dipartimentale correlata alla variabile tempo: ampio orizzonte temporale con dati tipicamente aggregati: per effettuare stime fuori linea: dati aggiornati periodicamente

Slide 14

14 Il data warehouse Orientata ai soggetti: considera i dati di interesse ai soggetti dellorganizzazione e non quelli rilevanti ai processi organizzativi basi di dati operazionali dipartimentali: vendita, produzione, marketing data warehouse: prodotti, clienti, fornitori

Slide 15

15 Il data warehouse Integrata: i dati provengono da tutte le sorgenti informative il data warehouse rappresenta i dati in modo univoco, riconciliando le eterogeneita` delle diverse rappresentazioni: nomi struttura codifica rappresentazione multipla

Slide 16

16 Il data warehouse Correlata alla variabile tempo: presenza di dati storici per eseguire confronti, previsioni e per individuare tendenze Le basi di dati operazionali mantengono il valore corrente delle informazioni Lorizzonte temporale di interesse dellordine dei pochi mesi Nel data warehouse di interesse levoluzione storica delle informazioni Lorizzonte temporale di interesse dellordine degli anni

Slide 17

17 Il data warehouse Dati aggregati: nellattivita` di analisi dei dati per il supporto alle decisioni: non interessa chi ma quanti non interessa un dato ma la somma, la media, il minimo, il massimo di un insieme di dati

Slide 18

18 Il data warehouse Fuori linea: base di dati operazionale: i dati venono acceduti, inseriti, modificati, cancellati pochi record alla volta data warehouse: operazioni di accesso e interrogazione diurne operazioni di caricamento e aggiornamento notturne che riguardano milioni di record

Slide 19

19 Il data warehouse Un DW rappresenta spesso lunione di pi data mart Data mart: restrizione data warehouse ad un singolo processo o ad un gruppo di processi aziendali (es. Marketing) DW Data mart #1 Data mart #2 Data mart #3 DW

Slide 20

20... una base di dati separata... Per tanti motivi non esiste ununica base di dati operazionale che contiene tutti i dati di interesse la base di dati deve essere integrata non tecnicamente possibile fare lintegrazione in linea i dati di interesse sarebbero comunque diversi devono essere mantenuti dati storici devono essere mantenuti dati aggregati lanalisi dei dati richiede per i dati organizzazioni speciali e metodi di accesso specifici degrado generale delle prestazioni senza la separazione

Slide 21

21 Architettura di riferimento

Slide 22

22 Caratteristiche architetturali irrinunciabili Separazione: lelaborazione analitica e quella transazionale devono essere il pi possibile separate Scalabilit: larchitettura hw e sw deve essere facilmente ridimensionabile Estendibilit: deve essere possibile accogliere nuove applicazioni e tecnologie Sicurezza: il controllo sugli accessi essenziale (dati strategici) Amministabilit: lattivit di amministrazione non deve essere troppo complessa

Slide 23

23 dw Back room Front room catalogo dei metadati acquisizionememorizzazione accesso Architettura di riferimento (a due livelli)

Slide 24

24 Dw virtuale acquisizionemiddleware accesso Architettura ad un livello Back room Front room catalogo dei metadati

Slide 25

25 Architettura a tre livelli dw Back room Front room catalogo dei metadati acquisizionememorizzazione accesso Dati riconciliati

Slide 26

26 Sistemi sorgente Ogni sorgente di informazioni aziendali Spesso rappresentate da dati operazionali: insieme di record la cui funzione quella di catturare le transazioni del sistema organizzativo tipico accesso OLTP uso di production keys (non vengono usate nel DW)

Slide 27

27 Dati riconciliati Integrazione dati sorgente simile ad integrazione schemi relazionali Risiedono su data staging area Area di memorizzazione i dati sorgente vengono trasformati tecnologia relazionale ma anche flat files

Slide 28

28 Data Warehouse Risiede su Presentation Server Componente che permette la memorizzazione e la gestione del data warehouse, secondo un approccio dimensionale Pu essere basato su: tecnologia relazionale (ROLAP) tecnologia multidimensionale (MOLAP)

Slide 29

29 End-user data access tools Client del DW, di facile utilizzo tools per interrogare, analizzare e presentare linformazione contenuta del DW a supporto di un particolare bisogno aziendale invio specifiche richieste al presentation server in formato SQL

Slide 30

30 I metadati = dati sui dati Link tra i DB operazionali e il DW ogni passo eseguito durante la costruzione del DW genera metadati che possono poi essere utilizzati dalle fasi successive Esempi: schema, data in cui un dato stato creato, quale tool lha creato, storia delle trasformazioni di un dato nel tempo, statistiche, dimensione tabelle, ecc. ecc.

Slide 31

31 Due ritmi diversi... Uso bimodale: 16-22 ore al giorno usati per attivit di interrogazione funzionalit front room 2-8 ore al giorno per caricamento, indicizzazione, controllo qualit e pubblicazione funzionalit back room

Slide 32

32 Servizi principali back room Processo ETL: Extraction,Transformation, Loading Extraction Estrazione dei dati dalle sorgenti informative operazionali Opzioni: tutti i dati / solo dati modificati (incrementale) Transformation Pulizia, per migliorare la qualit dei dati Trasformazione di formato, da formato sorgente a quello del DW Correlazione con oggetti provenienti da altre sorgenti Loading Caricamento (refresh o update) con aggiunta di informazioni temporali e generazione di dati aggregati

Slide 33

33 Servizi principali back room Il ruolo degli strumenti ETL quello di alimentare una sorgente dati singola, dettagliata, esauriente e di alta qualit che possa a sua volta alimentare il DW in caso di architettura a tre livelli questi strumenti alimentano il livello dei dati riconciliati la riconciliazione avviene quando il DW viene popolato la prima volta e periodicamente quando il DW viene aggiornato

Slide 34

34 Servizi principali front room Supporto di tool di accesso: tool che permettono allutente di accedere in modo intuitivo ed altamente espressivo ai dati contenuti nel DW: capacit di effettuare confronti presentazione dati avanzata risposte alla domanda: perche?

Slide 35

35 Tool di accesso Ad hoc permettono allutente di specificare le proprie query attraverso interfaccie user-friendly tools per la generazione di reportistica applicazioni avanzate applicazioni che permettono di applicare operazioni molto sofisticate al DW previsione DATA MINING...

Slide 36

36 Tool di accesso DBMS Traduzione in SQL Presentazione ODBC, JDBC Aggregate navigator

Slide 37

37 Progettazione di un data warehouse

Slide 38

38 Fattori di rischio Tipiche ragioni di fallimento dei progetti di data warehousing: Rischi legati alla gestione del progetto necessit di condivisione di informazione tra i reparti definizione dellambito e delle finalit del sistema Rischi legati alle tecnologie (rapida evoluzione) Rischi legati ai dati e alla progettazione qualit dei dati e del progetto realizzato Rischi legati allorganizzazione difficolt di trasformare la cultura aziendale, inerzia organizzativa

Slide 39

39 Metodologie di progettazione Approccio top-down + visione globale dellobiettivo + DW consistente e ben integrato costi onerosi e lunghi tempi di realizzazione (rischio di scoraggiare la direzione) complessit dellanalisi e riconciliazione contemporanea di tutte le sorgenti impossibilit di prevedere a priori nel dettaglio le esigenze delle diverse aree aziendali impossibilit di prevedere la consegna a breve termine di un prototipo

Slide 40

40 Metodologie di progettazione Approccio bottom-up il DW viene costruito in modo incrementale assemblando iterativamente pi data mart rischio: determina una visione parziale del dominio di interesse il primo data mart da prototipare deve essere quello che gioca il ruolo pi strategico per lazienda e deve ricoprire un ruolo centrale per lintero DW

Slide 41

41 Business Dimensional Lifecycle [Kimball] Pianificazione Definizione dei requisiti Attuazione Manutenzione Progetto dellarchitettura Selezione e installazione prodotti Modellazione dimensionale Specifica applicazioni Progettazione fisica Progetto dellalimentazione Sviluppo applicazioni Tecnologia Dati Applicazioni

Slide 42

42 La progettazione di un data mart Analisi e riconciliazione delle fonti dati input: schema delle sorgenti output: schema riconciliato Analisi dei requisiti input: schema riconciliato output: fatti, carico di lavoro preliminare Progettazione concettuale input: schema riconciliato, fatti, carico di lavoro preliminare ouput: schemi di fatto Raffinamento del carico di lavoro, validazione dello schema concettuale input: schemi di fatto, carico di lavoro preliminare ouput: carico di lavoro, schemi di fatto validati

Slide 43

43 La progettazione di un data mart Progettazione logica input: schema di fatto, modello logico target, carico di lavoro output: schema logico del data mart Progettazione dellalimentazione input: schemi delle sorgenti, schema riconciliato, schema logico del data mart output: procedure di alimentazione Progettazione fisica input: schema logico del data mart, DBMS target, carico di lavoro output: schema fisico del data mart

Slide 44

44 La progettazione di un data mart Aspetto chiave: basare la modellazione dei data mart sugli schemi operazionali uno schema concettuale di massima per il data mart pu essere derivato dal livello dei dati riconciliati per questo motivo la fase di analisi e riconciliazione delle fonti avviene prima della fase di analisi dei requisiti utente se queste due fasi sono invertite lo schema viene ricavato dalle specifiche utente e solo a posteriori si verifica che le informazioni richieste siano effettivamente disponibili nei database operazionali rischio di minare la fiducia del cliente verso il progettista

Slide 45

45 Analisi e riconciliazione delle fonti dati Metadati Analisi e riconciliazione Progettazione del cleaning Progettazione della trasformazione Strumenti ETL Schemi sorgenti operazionali Schema riconciliato, Mapping sorgenti operazionali Schema riconciliato, Mapping sorgenti operazionali Campioni dei dati Procedure per strumenti ETL

Slide 46

46 Analisi e riconciliazione delle fonti dati Metadati Ricognizione e normalizzazione Integrazione degli schemi Schema logico (locale) Schema concettuale (locale) riconciliato Schema logico (locale) Sorgente 1Sorgente 2 Ricognizione e normalizzazione Schema concettuale (locale) riconciliato Schema concettuale (globale) riconciliato Definizione corrispondenza con le sorgenti Schema concettuale (globale) riconciliato Schema logico (globale) riconciliato e corrispondenza

Slide 47

47 Analisi e riconciliazione delle fonti dati Ricognizione: Esame approfondito degli schemi locali mirato alla piena comprensione del dominio applicativo normalizzazione: correzione degli schemi locali per modellare in modo pi accurato il dominio applicativo (Fasi da svolgere anche se sorgente dati unica) integrazione: v. quanto detto su integrazione di schemi concettuali definizione delle corrispondenze: il risultato finale lo schema riconciliato in cui sono risolti i conflitti e linsieme delle corrispondenze tra gli elementi degli schemi sorgenti e quelli dello schema riconciliato

Slide 48

48 Le fasi della progettazione di un data mart Progettazione concettuale: fornisce una rappresentazione formale del contenuto informativo del data mart indipendente dal sistema che verr utilizzato per la sua implementazione progettazione logica: lo schema concettuale viene tradotto nel modello dei dati del sistema prescelto progettazione fisica: fase in cui vengono scelte le caratteristiche legate allo schema fisico del DW (indici, partizionamento) non la vediamo

Slide 49

49 Le fasi della progettazione di un data mart Schema riconciliato Requisiti utente PROGETTAZIONE CONCETTUALE PROGETTAZIONE LOGICA PROGETTAZIONE FISICA Schema di fatto Carico di lavoro valori dei dati modello logico Schema logico Carico di lavoro volume dei dati DBMS Schema fisico

Slide 50

50 Progettazione concettuale di un data warehouse

Slide 51

Analisi multidimensionale Lanalisi richiede normalmente dimensioni multiple: quanti items ho venduto per regione per mese per tipo di cliente? Dimensioni normalmente utilizzate per lanalisi: Tempo Prodotto Cliente Area geografica Dipartimento/settore

Slide 52

52 Progettazione concettuale modello entit-relazione si cerca di eliminare il pi possibile la ridondanza maggiore efficienza delle operazioni di aggiornamento schema simmetrico ci possono essere molti modi per connettere (mediante unoperazione di join) due tabelle la rappresentazione dipende dalla struttura dei dati OLTP

Slide 53

53 Un data warehouse si basa su un modello dei dati multidimensionale che rappresenta i dati sotto forma di data cube Un data cube permette di modellare e creare viste dei dati rispetto a molteplici dimensioni Modello dati multidimensionale Detto Star Schema Implementabile su un DB relazionale Consente volumi di dati molto grandi volumi dellordine di 100 gbytes forniscono tempi di risposta sotto i 10 sec Progettazione concettuale OLAP

Slide 54

54 Progettazione concettuale OLAP prodotto magazzino tempo vinoacquacoca cola mag apr feb set C B A 1512 1 42 10 9 25 2 7 11 23 3 Processo: vendite in una catena di supermercati

Slide 55

55 Progettazione concettuale prodotto magazzino tempo Il manager regionale esamina la vendita dei prodotti in tutti i periodi relativamente ai propri mercati Il manager di prodotto esamina la vendita di un prodotto in tutti i periodo e in tutti i mercati Il manager finanziario esamina la vendita dei prodotti in tutti i mercati relativamente al periodo corrente e quello precedente Il manager strategico si concentra su una categoria di prodotti, unarea regionale e un orizzonte temporale medio

Slide 56

56 Progettazione concettuale Ogni parametro puo` essere organizzato in una gerarchia che ne rappresenta i possibili livelli di aggregazione: negozio, citta`, provincia, regione giorno, mese, trimestre, anno OLAP

Slide 57

57 Progettazione concettuale Leliminazione della ridondanza non un obiettivo non si devono eseguire operazioni di aggiornamento schemi denormalizzati schemi asimmetrici un solo modo per connettere (mediante unoperazione di join) due tabelle minore numero dijoin maggiore efficienza la rappresentazione dipende dalla struttura dei dati OLAP

Slide 58

58 Concetti usati per definire un data cube Fatto un tema di interesse per lorganizzazione (vendite, spedizioni, acquisti) Misura una propriet di un fatto da analizzare (numero di unit vendute, prezzo unitario) Dimensione descrive una prospettiva lungo la quale unorganizzazione vuole mantenere i dati (prodotto, negozio, data)

Slide 59

59 Progettazione concettuale Utilizza modelli multidimensionali schemi di fatto ogni schema di fatto mette in evidenza le dimensioni (spigoli del cubo) le misure (contenuto di ogni cubetto) Fatti e dimensioni collegati attraverso associazioni uno-a-molti lo schema complessivo rappresenta una relazione molti-a-molti

Slide 60

60 Schemi di fatto VENDITA Unit Incasso cliente prodotto ora negozio fatto misure dimensioni

Slide 61

61 Le dimensioni Devono essere scelte solo le entit rilevanti per le analisi che si intendono effettuare Le dimensioni sono tipicamente caratterizzate da attributi: testuali discreti ma possono anche essere numeriche dimensione di un prodotto esiste sempre una dimensione temporale

Slide 62

62 Dimensioni: esempi Attivit: vendita in una catena di supermercati dimensioni: tempo, prodotti, magazzino Attivit: ordini dimensioni: tempo, prodotti, clienti, spedizioni Attivit: iscrizioni universitarie dimensioni: tempo, facolt, tipologia studenti Attivit : vendita automobili dimensioni: clienti, venditori, concorrenti, automobili, concessionarie

Slide 63

63 Le dimensioni Problema: come si pu identificare se un attributo numerico un fatto o un attributo di una dimensione? Se una misura che varia continuamente nel tempo fatto analisi costo di un prodotto nel tempo se una descrizione discreta di qualcosa che ragionevolmente costante attributo di una dimensione costo di un prodotto visto come informazione descrittiva

Slide 64

64 Le dimensioni Le dimensioni utilizzate sono spesso le stesse in vari contesti applicativi: tempo collocazione geografica organizzazione clienti il numero di attributi per ogni dimensione in genere molto elevato (anche nellordine del centinaio)

Slide 65

65 La dimensione tempo presente in ogni DW in quanto virtualmente ogni DW rappresenta una serie temporale Domanda: perch non campo di tipo DATE nella tabella dei fatti? Risposta: la dimensione tempo permette di descrivere il tempo in modi diversi da quelli che si possono desumere da un campo date in SQL (giorni lavorativi-vacanze, periodi fiscali, stagioni, ecc.)

Slide 66

66 La dimensione tempo Alcuni tipici attributi della dimensione tempo: tempo-k (pu essere un campo di tipo data in SQL) giorno-della-settimana n-giorno-nel-mese n-giorno-in-anno n-settimana-in-anno mese stagione periodo fiscale ...

Slide 67

67 I fatti I fatti hanno delle proporiet che sono dette misure Le propret dei fatti sono tipicamente: numeriche additive possono essere aggregati rispetto agli attributi delle dimensioni, utilizzando loperazione di addizione

Slide 68

68 Fatti e misure: esempi Attivit (fatti): vendite in una catena di supermercati misure: n. prodotti venduti, incassi, costi,... Attivit (fatti): ordini misure: n. spedizioni, n. clienti, importi,... Attivit (fatti): iscrizioni universitarie misure: n. studenti, Attivit (fatti): chiamate gestite da compagnia telefonica misure: costo, durata

Slide 69

69 Additivit delle misure Incasso, unit vendute: sono additive in quanto si possono aggregare sommando rispetto ad ogni dimensione: somma incassi/unit su tempo somma incassi/unit su prodotti somma incassi/unit su dipartimenti

Slide 70

70 Semiadditivit delle misure Numero clienti non una misura additiva: somma n. clienti su tempo OK somma n. clienti su dipartimenti OK MA: somma n. clienti su prodotto genera problemi si supponga che clienti che hanno comprato carne 20 clienti che hanno comprato pesce 30 il numero di clienti che hanno comprato carne o pesce un qualunque numero tra 30 e 50

Slide 71

71 Semiadditivit delle misure Il numero clienti una misura semiadditiva, poich pu essere sommata solo rispetto ad alcune dimensioni Soluzione: cambiare la granularit del database, portandola a livello singola transazione

Slide 72

72 Semiadditivit delle misure Tutte le misure che memorizzano una informazione statica, quali: bilanci finanziari misure di intensit (temperatura di una stanza) sono semiadditive rispetto al tempo ci che comunque si pu fare calcolare la media su un certo periodo di tempo

Slide 73

73 Non addittivit delle misure Le misure non additive sono misure che non possono essere sommate Esempi: misure: costo unitario e quantit nel contesto di un ordine dimensioni: clienti, spedizioni, tempo, i costi unitari non possono essere sommati se prima non sono moltiplicati per le rispettive quantit, quindi tali costi sono misure non additive

Slide 74

74 Schemi di fatto Unit Incasso NumClienti PrezzoUnitario (AVG) misure non additive VENDITA prodotto

Slide 75

75 Fatti anomali In alcuni contesti applicativi, puo` capitare di avere fatti senza misure fatti anomali in questo caso i fatti rappresentano semplicemente una relazione molti-a-molti, senza aggiungere alcuna nuova informazione Esempi: Attivita` principale: corsi universitari dimensioni: corsi, professori, studenti, tempo attivita` principale: assegnazione cure negli ospedali dimensioni: ospedali, dottori, diagnosi, tempo, pazienti, assistenti, procedure

Slide 76

76 Gerarchie Ciascuna dimensione spesso organizzata in una gerarchia che rappresenta i possibili livelli di aggregazione per i dati ogni livello della gerarchia rappresenta una relazione molti-a-uno giorno negozio prodotto cittprovinciaregionemesetrimestreannocategoriamarca

Slide 77

77 Esempio di DW con gerarchie store sType cityregion

Slide 78

78 Gerarchie Gli attributi della gerarchia vengono associati alle dimensioni a cui si riferiscono e chiaramente indicati gli attributi della dimensione devono essere associati al livello della gerarchia a cui si riferiscono

Slide 79

79 Schemi di fatto VENDITA Unit Incasso cliente prodotto ora negozio attributi descrittivi gerarchia professione et nome cognome indirizzo categoria descrizione colore modello indirizzo citt regione stato giorno settimana mese trimestre anno

Slide 80

80 Aggregazione In alcune situazioni, non si hanno vincoli su tutte le dimensioni ma solo per alcune Esempio: quale` il rapporto tra vendite effettuate nei week-end e vendite effettuate nei giorni lavorativi in ogni magazzino? Quale prodotto e` stato maggiormente venduto negli ultimi 3 mesi? Lesecuzione di queste interrogazioni e` molto costosa se viene effettuata sui dati di base Idea: precalcolare aggregati

Slide 81

81 Aggregazione Un aggregato e` un insieme di misure ottenute come sintesi di varie misure che caratterizzano i fatti di base una misura aggregata spesso associata a dimensioni aggregate utile considerare gli aggregati a livello concettuale per capire se lo schema di base permette il calcolo degli aggregati rientra nellanalisi del carico di lavoro

Slide 82

82 Aggregazione un aggregato viene utilizzato per due motivi: efficienza impossibilita` di rappresentare gli stessi dati al livello di dettaglio Esempio: costi di promozione possono essere espressi a livello categoria e non a livello di singolo prodotto

Slide 83

83 Esempio vendite aggregati (livello 1) aggregati (livello 2) Categoria per prodotto per giorno Vendite mensili per prodotto per giorno Categoria per mese

Slide 84

84 Due problemi Quali dati aggregare? Come rappresentare i dati aggregati?

Slide 85

85 Quali dati aggregare? importante considerare: tipiche richieste aziendali distribuzione geografica, linee di prodotti, periodicit generazione reportistica per ogni dimensione, identificare gli attributi e le combinazioni di attributi che pu essere utile aggregare distribuzione statistica dei dati stimare la dimensione delle tabelle aggregate se la dimensione della tabella aggregata non riduce di molto la dimensione della tabella di partenza, forse non conviene aggregare aggregazioni non molto usate possono essere utili come punto di partenza per effettuare altre aggregazioni pi significative

Slide 86

86 Come e dove memorizzare i dati aggregati? Esistono due approcci di base: nuovi fatti vengono create nuove tabelle per i fatti e le dimensioni aggregate nuovi campi vengono aggiunti nuovi attributi nei fatti e nelle dimensioni vediamo solo il primo approccio

Slide 87

87 Nuove tabelle dei fatti Per ogni aggregato di interesse viene generato un nuovo fatto si generano nuove dimensioni derivate da quelle di base ma contenenti solo i dati di interesse per i fatti aggregati

Slide 88

88 Esempio VENDITA Unit Incasso cliente negozio professione et nome cognome indirizzo categoria indirizzo citt regione stato mese trimestre anno

Slide 89

89 Composizione degli schemi Lo schema risultante da ogni processo aziendale pu essere visto come lo schema associato ad uno specifico data mart problema: combinare i fatti e le dimensioni contenuti negli schemi associati a ciascun processo, cioe contenuti in ciascun data mart

Slide 90

90 Composizione degli schemi Gli schemi associati ai vari processi possono avere dimensioni a comune Una singola dimensione puo` essere usata in relazione a diversi fatti per potere passare dalle informazioni contenute in uno schema alle informazioni contenute in un altro (drill-across): le dimensioni con lo stesso nome devono avere lo stesso significato e contenere gli stessi attributi (o sottoinsiemi di attributi) dimensioni conformate Conseguenza: i vincoli su attributi delle dimensioni a comune devono restituire le stesse entit per ogni schema considerato

Slide 91

91 Fatti conformati Anche le misure devono essere conformati misure con lo stesso nome in fatti diversi hanno la stessa granularita` e le stesse unita` di misura stesso periodo temporale stesso riferimento geografico

Slide 92

92 Costellazione di fatti Schema risultante: costellazione di fatti

Slide 93

93 Progettazione logica di un data warehouse

Slide 94

94 Scelta sistema di gestione dei dati DBMS operazionale: in genere relazionale DBMS informativo: relazionale (Oracle 8/8i, RedBrick- Informix,) multidimensionale (Oracle Express Server)

Slide 95

95 DBMS relazionali Tecnologia consolidata molto efficienti su dati di dettaglio estesi in modo da permettere la materializzazione degli aggregati (Oracle 9i) performance scalabilit general-purposes

Slide 96

96 DBMS multidimensionali prodotto magazzino tempo vinoacquacoca cola mag apr feb set C B A 1512 1 42 10 9 25 2 7 11 23 3

Slide 97

97 DBMS multidimensionali Modello dei dati basato su hypercubi (vettori multidimensionali) precalcolo aggregazioni aumento prestazioni per le query utente ma sparsit (in genere meno del 20% delle celle contiene informazioni) no join no interfaccia SQL (API) --> no standard necessit sistema relazionale per dati dettaglio file molto grandi limitazioni a circa 10GB (problemi scalabilit) Per superare questi problemi: aggiunta capacit di navigare da un MDBMS ad un RDBMS

Slide 98

98 Sistemi ROLAP & MOLAP ROLAP: sistema di data warehouse in grado di supportare le interrogazioni tipiche (roll-up, drill-down,) presentation server relazionale Oracle 9i + Discoverer MOLAP: sistema di data warehouse in grado di supportare le interrogazioni tipiche (roll-up, drill-down,) presentation server multidimensionale Express Server DOLAP (Desktop OLAP): i dati vengono recuperati da un DW relazionale o multidimensionale e copiati localmente Business Objects

Slide 99

99 ROLAP & MOLAP Performance Query: MOLAP Caricamento: ROLAP Analisi: MOLAP Dimensione DW: ROLAP MOLAP: problema sparsit Flessibilit nello schema: ROLAP MOLAP: minor numero di dimensioni ammesse

Slide 100

100 Progettazione logica Durante questa fase, lo schema concettuale del DW viene tradotto in uno schema logico, implementabile sullo strumento scelto Il modello logico deve essere il pi possibile vicino al modello concettuale, anche se alcune variazioni possono essere rese necessarie dal particolare tool prescelto supponiamo che il sistema prescelto sia ROLAP

Slide 101

101 Impatto dellarchitettura sullo schema logico Architettura a due livelli: ogni tabella = una relazione architettura a un livello: ogni tabella = una vista nel seguito ipotizziamo architettura a due- tre livelli

Slide 102

102 Progettazione logica Modelli logici per data mart in ROLAP: modello a stella modello snowflake

Slide 103

103 Modello a stella Si interpretano fatti e dimensioni come entit del modello entit-relazione si mappa lo schema entit-relazione in uno schema relazionale fatti e dimensioni diventano tabelle a cui si aggiunge una chiave artificiale le tabelle delle dimensioni contengono tutti gli attributi per tutti i livelli della gerarchia poich le associazioni sono tutte uno-a- molti, si modellano con chiavi esterne

Slide 104

104 Chiavi Le chiavi aggiunte devono essere chiavi artificiali (numeriche, progressive) non sono le chiavi semantiche eventualmente utilizzate nella base di dati operazionale si ottimizzano le operazioni di join le chiavi semantiche possono essere comunque presenti come attributi comuni

Slide 105

105 Esempio di schema Vendite Codice orario Codice luogo Codice prodotto Codice cliente Unit Incasso Tempo Codice orario Ora Giorno Settimana Mese Trimestre Anno Luogo Codice luogo Negozio Indirizzo Codice Citt Citt Codice Regione Regione Codice Stato Stato Prodotto Codice prodotto Descrizione Colore Modello Codice categoria Categoria Cliente Codice cliente Nome Cognome Indirizzo Et Codice professione Professione

Slide 106

106 Esempio di instanza

Slide 107

107 Osservazioni sulla normalizzazione dello schema La tabella dei fatti completamente normalizzata le tabelle delle dimensioni possono non essere normalizzate, ma: la dimensione delle tabelle delle dimensioni in genere irrilevante rispetto alla dimensione della tabella dei fatti quindi, ogni sforzo per normalizzare queste tabelle ai fini del DW una perdita di tempo lo spazio guadagnato in genere meno dell1% dello spazio richiesto dallo schema complessivo la normalizzazione delle tabelle delle dimensioni pu ridurre la capacit di browsing (navigazione) dello schema (si veda oltre)

Slide 108

108 Schemi snowflake In presenza di gerarchie, una dimensione pu essere facilmente normalizzata introducendo una nuova relazione per ogni livello della schema snowflake Prodotto Codice prodotto Descrizione Colore Cod Modello Modello Codice modello Modello codice categoria Categoria Codice categoria categoria

Slide 109

109 Schemi snowflake Uno schema snowflake rende meno efficienti le operazioni di ricerca, anche se la tabella e` grande (+ join) e` conveniente utilizzare uno schema snowflake solo se questo approccio aumenta la leggibilita` dello schema e le prestazioni globali

Slide 110

110 Schemi aggregati Approccio A lo schema logico aggregato viene creato utilizzando le stesse regole utilizzate per lo schema di base lo schema di base e gli schemi aggregati dovranno essere alimentati dalle procedure ETL si aumenta il carico di lavoro della back room non si altera il carico di lavoro del presentation server

Slide 111

111 Schemi aggregati Approccio B lo schema aggregato viene creato in modo virtuale, come insieme di viste, eventualmente materializzate solo lo schema di base deve essere alimentato si aumenta il carico di lavoro del presentation server non si altera il carico di lavoro della back room (si semplificano le procedure di alimentazione)

Slide 112

112 Esempio Fatti: unit, incasso Dimensioni: prodotti, tempo si vogliono analizzare unit e incasso per categoria di prodotto CREATE VIEW vendite_per_cat(categoria,tempo_k,unit_cat,incasso_cat) AS SELECT categoria, tempo_k, SUM(unit),SUM(incasso) FROM Vendite,prodotti WHERE vendite.prodotto_k = prodotti.prodotto_k GROUP BY categoria, tempo_k

Slide 113

113 Vantaggi e svantaggi nelluso degli aggregati Svantaggi: Luso degli aggregati aumenta di molto la dimensione del DB (anche del 300%!) usare aggregazione nel caso in cui ogni aggregato sintetizza almeno 10-20 record di base Vantaggi: Miglioramento delle prestazioni possono essere utilizzati in modo trasparente allutente

Slide 114

114 Influenza aggregati sul codice SQL Se gli aggregati sono presenti, per poterli utilizzare bisogna ovviamente scrivere codice SQL opportuno partendo da una query sulle tabelle di base, le tabelle aggregate possono essere utilizzate sostituendole alle corrispondenti tabelle di base

Slide 115

115 Esempio query di base SELECT categoria, SUM(unit_cat) FROM vendite, prodotti, tempo WHERE vendite.prodotto-k = prodotti.prodotto-k AND vendite.tempo-k = tempo.tempo-k AND tempo.giorno = 1 Gennaio, 1996 GROUP BY categoria

Slide 116

116 Esempio query aggregata SELECT categoria, unit_cat FROM vendite-per-cat, tempo WHERE vendite-aggreg-per-cat.tempo-k = tempo.tempo-k AND tempo.giorno = 1 Gennaio, 1996

Slide 117

117 Influenza sul codice SQL Gli utenti finali e i tool di accesso devono generare codice differente in relazione che esistano o meno le tabelle agrgegate discontinuit delle applicazioni Soluzione: aggregate navigator

Slide 118

118 Aggregate navigator Livello software il cui obiettivo quello di intercettare le richieste SQL e tradurle utilizzando nel modo migliore le tabelle aggregate si scelgono le pi piccole le richieste SQL si assumono utilizzare le tabelle di base si rende trasparente luso degli aggregati allutente finale

Slide 119

119 Progettazione logica in Oracle 9i Oltre a creare una relazione per ogni tabella, possibile rappresentare esplicitamente le gerarchie, utilizzando il concetto di DIMENSIONE nuovo oggetto della base di dati possibilit di materializzare le query

Slide 120

120 Dimensioni in Oracle 9i Oggetti che permettono di descrivere gerarchie esistenti allinterno delle tabelle vengono utilizzate per: riscrivere le query suggerire la creazione di view materializzate non contengono nuovi dati ma specificano: gli attributi coinvolti nelle gerarchie (livelli) le gerarchie (anche >= 1 per una stessa tabella) dipendenze funzionali tra livelli ed altri attributi delle tabelle sottostanti

Slide 121

121 Dimensioni in Oracle 8i CREATE DIMENSION LEVEL IS. HIERARCHY ( CHILD OF ) ATTRIBUTE DETERMINES....

Slide 122

122 Esempio Unit Incasso NumClienti PrezzoUnitario (AVG) prodotto categoria descrizione colore modello VENDITA Prodotto_k Prodotto Modello Colore Descrizione Categoria Prodotti

Slide 123

123 Dimensioni in Oracle 8i CREATE DIMENSION Prodotti_D LEVEL prod_l IS Prodotti.prodotto LEVEL categ_l IS Prodotti. categoria HIERARCHY Prodotti_H ( prod_l CHILD OF categ_l) ATTRIBUTE prod_l DETERMINES descrizione ATTRIBUTE prod_l DETERMINES modello ATTRIBUTE prod_l DETERMINES colore;

Slide 124

124 View materializzate Materializzo la vista, cioe` la calcolo una sola volta, la memorizzo e la uso durante lesecuzione delle query Necessit di specificare: Politiche di caricamento Politiche di aggiornamento (refresh) Utilizzo/non utilizzo da parte dellaggregate navigator

Slide 125

125 View materializzate in Oracle 9i Caricamento: Immediate: allatto della definizione (default) Deferred: popolata alla successiva operazione di refresh (che deve essere completo)

Slide 126

126 View materializzate in Oracle 9i Refresh: Come: Fast: incrementale (molte restrizioni) Complete: totale Force: incrementale quando possibile, totale altrimenti Quando: On Commit: fast refresh al commit delle transazioni sulle tabelle di definizione della view (solo per join view e single-table view) On Demand: invocando specifiche procedure Start with Next .

Slide 127

127 View materializzate in Oracle 9i Query Rewrite: Enable: utilizzata dallaggregate navigator in fase di riscrittura delle query Disable: non utilizzata dallaggregate navigator in fase di riscrittura delle query

Slide 128

128 View materializzate in Oracle 9i CREATE MATERIALIZED VIEW nome BUILD REFRESH [ENABLE QUERY REWRITE] AS DROP MATERIALIZED VIEW nome ALTER MATERIALIZED VIEW...

Slide 129

129 View materializzate in Oracle 9i CREATE MATERIALIZED VIEW vendite_cat BUILD immediate REFRESH complete on commit ENABLE QUERY REWRITE AS SELECT categoria, tempo_k, SUM(unit),SUM(incasso) FROM Vendite,prodotti WHERE vendite.prodotto_k = prodotti.prodotto_k GROUP BY categoria, tempo_k

Slide 130

130 Interrogazione di un data warehouse

Slide 131

131 Tipologie Reportistica On-Line Analytical Processing Data mining

Slide 132

132 Reportistica Approccio orientato ad utenti che hanno necessit di accedere a intervalli di tempo predefiniti a informazioni strutturate in modo pressoch invariabile di questi rapporti nota a priori la forma un rapporto definito da uninterrogazione e da una presentazione linterrogazione comporta in genere la selezione e laggregazione di dati multidimensionali la presentazione pu essere in forma tabellare o grafica la reportistica non nata con il DW, ma ha acquisito con il DW benefici in termini di affidabilit e tempestivit dei risultati

Slide 133

133 OLAP: On-Line Analytical Processing Una visione multidimensionale, logica, dei dati Analisi interattiva dei dati Modellazione analitica: derivazione delle proporzioni, delle varianze, etc Aggregazioni per ogni sottoinsieme delle dimensioni Previsione, trend analysis, e statistical analysis Calcola e visualizza i dati in 2D o 3D crosstabs, charts, e grafi, con semplici operazioni di rotazione degli assi

Slide 134

134 OLAP su data cubes Prodotti Periodi di tempo Mercati Quantit Vendite

Slide 135

135 Progettazione concettuale prodotto magazzino tempo Il manager regionale esamina la vendita dei prodotti in tutti i periodi relativamente ai propri mercati Il manager di prodotto esamina la vendita di un prodotto in tutti i periodo e in tutti i mercati Il manager finanziario esamina la vendita dei prodotti in tutti i mercati relativamente al periodo corrente e quello precedente Il manager strategico si concentra su una categoria di prodotti, unarea regionale e un orizzonte temporale medio

Slide 136

136 I nuovi tipi di query Dipendono dai tool di accesso influenzano limplementazione delle query Operazioni di base: drill-down/roll-up pivoting slicing dicing top-n

Slide 137

137 Operazioni tipiche Roll up: riassumi i dati, salendo nella gerarchia dei concetti per una dimensione o attraverso una riduzione di una dimensione il volume totale di vendite per categoria di prodotto e per regione per anno si rimuove per esempio la dimensione tempo Roll down or drill down: passa da un livello di dettaglio basso ad un livello di dettaglio alto, scendendo nella gerarchia o introducendo una nuova dimensione. per un particolare prodotto, trova le vendite dettagliate per ogni venditore e per ogni data

Slide 138

138 Operazioni tipiche (cont.) Slice and dice: select & project Loperazione di Slice esegue una selezione su una dimensione del cubo. Loperazione di Dice definisce un sottocubo eseguendo una selezione su due o pi dimensioni Vendite delle bevande nel West negli ultimi 6 mesi Pivot (rotate): riorienta il cubo Top-n: Esempio: determinare i 10 prodotti piu` venduti ad una certa data e in un certo magazzino, ordinati per vendite

Slide 139

139 Operazioni tipiche: Roll-Up Product Store Month Product Store Year Roll-up Drill-Down Product Region Year Roll-up Drill-Down

Slide 140

140 Operazioni tipiche: drill-down e roll-up Dipartimento IncassiUnit vendute Panificio Lit. 121000005088 Cibo surgelato Lit. 2300000015000 DipartimentoMarca Incassi Unit vendute Panificio Barilla 6000000 2600 Panificio Agnesi 6100000 2488 Cibo surgelato Findus 15000000 6500 Cibo surgelato Orogel 8000000 8500 down up

Slide 141

141 Operazioni tipiche: Slice and Dice Product Store Month Slice Product Store Month

Slide 142

142 Data mining Attivit orientata a scoprire informazioni nascoste nei dati le tecniche di data mining sono utilizzate da anni in applicazioni scientifiche specialistiche (ricerca geologica, medica, astronomica, metereologica, ) con il DW il data mining viene trasportato dallanalisi scientifica allanalisi commerciale (ricerche di mercato, segmentazione di mercato, analisi delle abitudini di acquisto, ) permette di analizzare automaticamente grosse quantit di dati tipologie di pattern estraibili con regole di data mining: regole associative, clustering, alberi di decisione, serie temporali

Slide 143

143 Impatto sul codice SQL Tipiche query OLAP richiedono molte aggregazioni 1995 1996 1997 Totale GEMI Totale 63 81144 10714538 35 223 110 388 75 176 SELECT SUM (vendite) FROM vendite S, Tempo T, Magazzini M WHERE S.TId = T.TId AND S.Mid = M.Mid GROUP BY T.anno, M.citta` SELECT SUM (vendite) FROM vendite S, Magazzini M WHERE S.MId = M.MId GROUP BY M.citta` SELECT SUM (vendite) FROM vendite S, Tempo T WHERE S.TId = T.TId GROUP BY T.anno

Slide 144

144 Impatto sul codice SQL In genere: fatti con k dimensioni 2 k query SQL aggregate Nuovo operatore SQL CUBE per calcolare tutte le possibili aggregazioni rispetto ad un insieme di attributi CUBE Pid, Mid, Tid BY SUM Vendite equivalente ad un insieme di query: SELECT SUM (vendite) FROM vendite S GROUP BY grouping list Presente in molti DBMS { } {PId} {MId}{TId} {PId, MId} {PId, TId}{MId, TId} {PId, MId,TId}

Slide 145

145 Impatto sul codice SQL Necessita` di determinare i primi n elementi rispetto ad un certo ordinamento Esempio: determinare i 10 prodotti piu` venduti in un certo magazzino, ordinati per entita` delle vendit Presente in molti DBMS

Slide 146

146 Operatori aggregati in Oracle 9i SQL viene esteso con nuovi operatori di aggregazione. Tra i vari operatori: ROLLUP CUBE RANK/TOP-N

Slide 147

147 Roll-up SELECT . GROUP BY ROLLUP (elenco colonne) calcola laggregato standard rispetto allelenco di colonne specificato calcola subtotali di livello pi alto, riducendo ad uno ad uno le colonne da aggregare, procedendo da destra a sinistra nella lista

Slide 148

148 Roll-up Esempio: SELECT citt, mese, prodotto, SUM(vendite) FROM Vendite v, Magazzini m, Tempo t, Prodotti p WHERE m.Magazzino_k = v.Magazzino_k AND p.Prodotto_k = v.Prodotto_k AND t.Tempo_k = v.Tempo_k GROUP BY ROLLUP(citt,mese,prodotto)

Slide 149

149 Roll-up Citt Mese Prodotto Vendite

Slide 150

150 Cube SELECT . GROUP BY CUBE (elenco colonne) calcola laggregato standard rispetto allelenco di colonne specificato e rispetto ad ogni sottoinsieme dellelenco specificato

Slide 151

151 Cube Esempio: SELECT citt, mese, prodotto, SUM(vendite) FROM Vendite v, Magazzini m, Tempo t, Prodotti p WHERE m.Magazzino_k = v.Magazzino_k AND p.Prodotto_k = v.Prodotto_k AND t.Tempo_k = v.Tempo_k GROUP BY CUBE(citt,mese,prodotto)

Slide 152

152 Cube Citt Mese Prodotto Vendite

Slide 153

153 Top-N SELECT A1,,An FROM (SELECT B1,,Bm, RANK() OVER(ORDER BY Ai ASC, ORDER BY Aj DESC) AS rank FROM WHERE... GROUP BY A1,,An) WHERE rank