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

Transcript

1 Aggregazione 151 Operazioni tipiche: Pivoting o rotating 152 1

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

3 155 Riassumendo Un cubo multidimensionale è incentrato su un fatto di interesse per il processo decisionale. Esso rappresenta un insieme di eventi, descritti quantitativamente da misure numeriche. Ogni asse del cubo rappresenta una possibile dimensione di analisi. Ciascuna dimensione può essere vista a più livelli di dettaglio individuati da attributi strutturati in gerarchie. Sull ipercubo sono definite una serie di operazioni di restrizione e di aggregazione dei dati 156 3

4 Il modello logico 157 Schemi dimensionali La modellazione dimensionale è una tecnica di progettazione logica dei dati nel data warehouse è orientata alla definizione di schemi relazionali di tipo dimensionale uno schema dimensionale (chiamato anche star schema o schema a stella) è composto da una tabella principale, chiamata tabella fatti un insieme di tabelle ausiliarie, chiamate tabelle dimensione 158 4

5 Esempio di schema dimensionale questo schema modella i dati delle vendite di prodotti in un certo numero di negozi nel corso del tempo memorizza i totali giornalieri delle vendite dei prodotti per negozio 159 Schema a stella prodotto Unità centrale rappresenta i fatti (0,N) (1,1) (0,N) supermercato (1,1) Vendita (1,1) (0,N) promozione (1,1) (0,N) tempo Diverse unità poste a raggiera intorno ai fatti rappresentano le dimensioni dell analisi 160 5

6 Ciascuna occorren za di vendita ha per identificatore i quattro codici: CodProd CodMarket CodPromo CodTempo Gli attributi non chiave sono Amm e Qta. Supermercato: CodMarket Nome Città Regi one Zona Dimens ioni Dispos izio ne Schema a stella (0,N) (1,1) Prodotto: CodProd Nome Categor ia Marca Peso Fornitore (0,N) (1,1) Vendita Amm Qta (1,1) (0,N) Tem po: CodTempo GiornoSett GiornoMes e GiornoAn no SettimanaMes e SettimanaAn no MeseAnn o (1,1) (0,N) Promozione: CodPromo Nome Tipo Percentua le FlagCo upo n DataInizi o DataFine Costo Agenzi a Ogni occorrenza di vendita è un dato aggregato 161 Schema a stella Nella dimensione del tempo sono presenti dati derivati e ridondanze. Le ridondanze servono per facilitare le operazioni di analisi dei dati. I fatti sono in forma normale di Boyce-Codd in quanto ogni attributo non chiave dipende funzionalmente dalla sua unica chiave. Le dimensioni sono in genere relazioni non normalizzate

7 Caratteristiche di uno schema dimensionale Una tabella dimensione memorizza i membri di una dimensione la chia ve primaria è semplice gli a ltri campi memorizzano gli attributi de lla dimensione gli a ttributi sono so litamente testua li, discre ti e descrittivi La tabella fatti memorizza le misure (fatti) di un processo la chia ve è composta da rife rimenti a lle chia vi di tabe lle dimensione gli altri campi rappresentano i fatti i fatti sono solitamente nume rici, continui e additivi 163 Tabelle dimensione Una tabella dimensione (dimension table) memorizza i membri di una dimensione rispetto alla quale è interessante analizzare un processo, nonché le descrizioni di tali membri ciascun record di una tabella dimensione descrive esattamente un membro della rispettiva dimensione ad esempio, ciascun record della tabella Time Dimension descrive un giorno(nell ambito dell intervallo temporale d i in te resse), men tre un reco rd d i Product Dimension descrive un prodotto in vendita nei negozi i campi (non chiave) di una tabella dimensione memorizzano gli attributi dei membri gli attributi sono le proprietà dei membri, che sono solitamente testuali, discrete e descrittive 164 7

8 Tabella fatti Una tabella fatti (fact table) memorizza le misure nume riche di un processo un fatto è u na m isu ra re la tiva a un p ro ces so ogni record della tabella fatti memorizza una tupla di misure (fatti) relativa a una combinazione dei membri, pre sa all inte rsezione di tutte le dimensioni Nell esempio il processo è la vendita di prodotti nei negozi i fatti sono l incasso in dollari (dollars_sold) la quantità venduta (units_sold) le spese sostenute a fronte della vendita (dollars_cost) la grana è il to ta le pe r prodo tto, ne gozio e gio rno 165 Tabella fatti (2) I campi della tabella fatti sono partizionati in due insiemi campi che formano la chiave (composta) sono riferimenti alle chiavi primarie delle tabelle dimensione s tabiliscono la grana della tabella fatti altri campi sono chiamati fatti sono solitamente valori numerici in un dominio continuo e additivi Una tabella fatti memorizza una funzione (in senso matematico) dalle dimensioni ai fatti ovvero, una funzione che associa a ciascun fatto un valore per ciascuna possibile combinazione dei membri de lle dimensioni 166 8

9 Additività dei fatti Un fatto è additivo se ha s enso s ommarlo rispetto a ogni possibile combinazione delle dimensioni da cui dipende nell esempio, l incasso in dollari è additivo perché ha senso calcolare la somma degli incassi per un certo intervallo di tempo, insieme di prodotti e insieme di negozi ad esempio, i n un mese, per una categoria di pro dotti e per i ne gozi in un area geografica l additività è una proprietà importante, perché le applicazioni del data warehouse devono solitamente combinare i fatti descritti da molti record di una tabella fatti il modo più comune di combinare un i nsieme di fatti è di sommarli (se questo ha senso) è possibile anche l uso di altre operazioni 167 Semi additività e non additività I fatti possono essere anche semi additivi se ha s enso s ommarli s olo rispetto ad alcune dimensioni ad esempio, il numero di pezzi in deposito di un prodotto è sommabile rispetto alle categorie di prodotto e ai magazzini, ma non rispetto al tempo non additivi se non ha s enso s ommarli può avere senso combinare fatti anche non completamente additivi mediante operazioni diverse dalla somma 168 9

10 Attributi e interrogazioni Gli a ttributi delle ta belle dimensione sono il principa le strumento pe r l inte rrogazione de l data warehouse gli attributi delle dimensioni vengono usati per s elezionare un s ottoins ieme dei dati di interesse vincolando il valore di uno o più attributi ad esempio, le vendite nel corso dell anno 2000 raggruppare i dati di interesse usando gli attributi come intestazioni della tabella risultato ad esempio, per mostrare le v endite per ciascuna categoria di prodotto in ciascun mese 169 Attributi e interrogazioni Dati restituiti dall interrogazione somma degli inc assi in dollari e delle quantità vendute per ciascuna categoria di prodotto in ciascun mese nel corso dell anno

11 Formato delle interrogazioni Le interrogazione assumono solitamente il seguente formato standard: select p.category, t.month, sum(f.dollars_sold), sum (f.items_sold) from sales_fact f, product p, time t where f.product_key = p.product_key and f.time_key = t.time_key and t.year = 2000 group by p.category, t.month 171 Formato delle interrogazioni

12 Drill down L operazione di drill down aggiunge dettaglio ai dati restituiti da una inte rrogazione il drill down avviene aggiungendo un nuovo attributo ne ll inte stazione di una inte rro gazione diminuisce la grana dell aggre gazione 173 Roll up L operazione di drill up riduce il dettaglio dei dati restituiti da una inte rrogazione il drill up avviene rimuovendo un attributo da ll inte stazione di una inte rro gazione aumenta la grana dell aggre gazione

13 Discussione Pe r il da ta wa rehouse, la mode lla zione dimensio nale presenta dei vantaggi rispetto alla modellazione tradizionale (ER-BC NF) adottata ne i sistemi ope razionali gli schemi dimensionali hanno una forma standardizzata e prevedibile è facilmente comprensibile e rende possibile la navigazione dei dati semplifica la sc rittura delle applicazioni ha una strategia di esec uzione efficiente gli schemi dimensionali hanno una struttura simmetrica rispe tto alle dimensioni la progettazione può essere effettuata in modo indipendente per ciascuna dimensione le interfacce utente e le strategie di esecuzione sono simmetriche 175 Vantaggi della modellazione dimensionale gli schemi dimensionali sono facilmente estendibili rispetto all introduzione di nuovi fatti rispetto all introduzione di nuovi attributi per le dimensioni rispetto all introduzione di nuove dimensioni supplementari se ogni record della tabella fatti dipende già funzionalmente dai membri della nuova dimensione si presta alla gestione e mate ria lizza zione di da ti aggregati sono state già sviluppate numerose tecniche per la descrizione di tipologie fondamenta li di fa tti e dimensioni

14 Riepilogando tipicamente, in un modello a stella i dati testuali sono contenuti nelle Dimension Tables, mentre quelli numerici sono contenuti nella Fact Table l organizzazione dei dati in fatti e dimensioni permette di dare una risposta veloce alle interrogazioni in quanto queste portano su Dimension Tables ridotte uno schema a stella semplice ha una sola Fact Table mentre uno schema complesso puo averne piu di una 177 Gli schemi: Schema a fiocco di neve (snowflaking) Il modello a fiocco di neve e un estensione del modello a stella nel quale una o più punte della stella si estendono Tutte le Dimension Tables in un modello a fiocco di neve sono normalizzate Per esempio, la tabella della dimensione PERIODO viene normalizzata in TRIMESTRE e in MESE

15 SnowFlake schema Un modello a fiocco di neve si usa quando le Dimension Tables devono essere normalizzate 179 Snowflaking Per snowflaking di una dimensione si intende una rappresentazione più normalizzata di una tabella dimensione, che e videnzia de lle ge ra rchie di attributi

16 Occupazione di memoria Stima de ll occupazione di memoria della base di dati dimensionale di esempio tempo 2 anni di 365 giorni, ovvero 730 giorni negozi 300 negozi prodotti prodotti fatti re la tivi a lle ve ndite ipotizziamo un livello di sparsità del 10% delle vendite giornaliere dei prodotti nei negozi ovvero, c he ogni negozio vende giornalmente diversi prodotti 730 x 300 x 3000 = record 181 Ev oluzione dello schema a stella, introdotta per strutturare gerarchicamente le dimensioni non nor malizzate. Snowflake Schema Fornitore Supermerc ato (1,1) (0,N) (0,N) (1,1) Prodotto (0,N) (1,1) Vendita (1,1) (1,1) (1,1) (0,N) (0,N) Categoria Promozione (0,N) Città (1,1) (0,N) Regione (1,1) (0,N) Giorno (1,1) (0,N) Mese (1,1) Tale schema rappresenta in modo esplicito le gerarchie, riducendo così le ridondanze e le anomalie (0,N) Zona (0,N) Anno

17 Resistere allo snowflaking Lo snowflak ing è solitamente svantaggioso vano per l occupazione di memoria ad esempio, supponiamo che la dimensione prodotto contenga record, di circa byte ciascuno occupando quindi 60MB di memoria primaria la tabella fatti contiene invece record, di circa 10 byte ciascuno occupando quindi 6.3GB di memoria primaria le tabelle fatti sono sempre molto più grandi delle tabe lle dimensione associate anche riducendo l occupazione di memoria della dimensione prodotto del 100%, l occupazione di memoria complessiva è ridotta di meno dell 1% può peggiorare de cisamente le prestazioni 183 SnowFlake schema Vantaggi del modello a fiocco di neve rispetto al modello a stella Miglioramento nelle prestazioni delle interrogazioni attraverso una minore occupazione di spazio dovuta all eliminazione di dati ridondanti l utilizzo, in occasione dei joins, di piccole tabelle normalizzate invece di grosse tabelle non normalizzate Svantaggi del modello a fiocco di neve rispetto al modello a stella Struttura più complessa Creazione e gestione di un maggior numero di tabelle Ma ggio re diffico ltà ne lla gestione de lle que rie s a causa di molteplici joins Maggiore difficoltà nel decidere quale tabella deve essere usata in una query

18 Costellazione di fatti In alcune situazioni vi potrebbero essere delle Tabelle dimensioni con differenze sostanziali nel numero di attributi e nel volume In questo caso non si puo utilizzare il modello a stella o quello a fiocco di neve per tutta la struttura: bisogna quindi ricorrere ad una combinazione dei due, detta anche modello misto 185 Costellazione di fatti Nel modello misto solo le grosse Dimension Tables vengono normalizzate

19 Modelli La decisione di quale modello utilizzare, e cioe a stella (Star Schema) a fiocco di neve (Snowflake Schema) misto (Mixed Schema) dipende quindi dalle caratteristiche dei dati e dai requisiti richiesti dall organizzazione che utilizzerà il Data Warehouse 187 Il modello dimensionale La progettazione dei dati in un data warehouse dimensionale è basata sulla modellazione dimensionale è resa coerente adottando l architettura del datawarehouse a bus

20 Elaborazione del modello dimensionale (Opzioni Di Memorizzazione) MOLAP: OLAP Multidimensionale usa un data store specializzato per contenere i dati e le aggregazioni ROLAP: OLAP Relazionale usa un DBMS relazionale standard per contenere i dati e le aggregazioni HOLAP: OLAP Hybrid mette assieme i due metodi (MOLAP+ROLAP) 189 Rolap e Molap Dietro queste sigle si nascondono i due principali approcci all implementazione dei DW con riferimento al modello logico usato per la rappresentazione dei dati Rolap : Relational OLAP Molap: Multidimentional OLAP

21 Rolap L idea di adottare tecnologie relazionali per la memorizzazione dei dati nel DW è ben motivata se si considerano l enorme lavoro svolto in letteratura sul modello relazionale, la diffusa esperienza aziendale sull utilizzo e l amministrazione di basi dati relazionali e l elevato livello di prestazioni e di flessibilità raggiunto dai DBMS relazionali 191 Rolap (2) Evidentemente, poiché il modello relazionale non include i Concetti di dimensione, misura e gerarchia si rende necessario Elaborare tipologie specifiche di schemi che permettano di traslare Il modello multidimensionale sui mattoni di base costituiti da Attributi, relazioni, vincoli di integrità. Questo ruolo è svolto Principalmente dal celebre star schema o schema a stella. Problemi: Prestazioni (costose operazioni di join) Denormalizzazione dei dati (possibili inconsistenze) Necessità di un middleware per l elaborazione OLAP. Tale middleware riceve a livello front end le interrogazioni olap e le traduce in SQL consultando i metadati e inviandole al sistema di back-end relazionale

22 Rolap (3) 193 Molap Molap si basa su un modello logico ad hoc sul quale i dati e le operazioni multidimensionali possono essere direttamente rappresentati. Nelle basi dati multidimensionali i dati vengono fisicamente memorizzati in vettori (array) e l accesso è di tipo posizionale. Vantaggi: Prestazioni Svantaggi: Modello logico non standard Difficoltà di modellazione dati memorizzati nel Modello relazionale

23 Accedere al datawarehouse Reportistica ed OLAP 195 Reportistica Approccio orientato agli utenti che hanno necessità di accedere ad intervalli di tempo definiti a informazioni strutturate pressochè invariabili. Un Report è definito da un interrogazione e da una presentazione. L interrogazione comporta in genere la selezione e l aggregazione di dati multidimensionali; la presentazione può essere in forma tabellare oppure grafica (istogramma, torta,..) può essere generato in maniera sincrona o asincrona

24 Reportistica (Esempi) 197 OLAP Principale modalità di fruizione delle informazioni su un datawarehouse. Permette agli utenti di costruire autonomamente una sessione di analisi complessa con una interfaccia semplice e intuitiva Una sessione olap consiste in un percorso di navigazione che riflette il procedimento di analisi di uno o più fatti di interesse sotto diversi aspetti e a diversi livelli di dettaglio. Questo percorso si concretizza in una sequenza di interrogazioni che spesso non vengono formulate direttamente, ma per differenza rispetto all interrogazione precedente Il risultato delle operazioni è di tipo multidimensionale e vengono generalmente presentati in forma tabellare, con intestazioni multiple e colori per evidenziare le diverse dimensioni

25 OLAP(2) Ogni passo della sessione di analisi è scandito dall applicaizone di un operatore OLAP che trasforma l interrogazione formulata in una nuova interrogazione Gli operatori sono: Roll-up Drill-down Slice and dice Pivoting Drill-down Drill-Through 199 Esempi interogazioni olap V-Mall grande magazzino virtuale che effettua vendite via catalogo e via telefono e internet. Una sessione OLAP consiste in pratica in un percorso di navigazione che riflette il procedimento di analisi di uno o più fatti di interesse sotto diversi aspetti e a diversi livelli di dettaglio

26 Le gerarchie di V-mall 201 Gerarchie

27

28

29

30 Architettura generale per il datawarehouse 209 Data Warehousing Con il termine Data Warehousing si vuol indicare: un processo che include una serie di strumenti che vanno dal recupero e convalida dei dati alla pubblicazione dei risultati dell analisi un processo che integra basi di dati indipendenti in un singolo repository (detto data warehouse) dal quale gli utenti finali possano facilmente ed efficientemente eseguire query, generare report ed effettuare analisi

31 DW Al centro del processo il Datawarehouse (magazzino dei dati) è un contenitore (repository) di dati garante dei requisiti esposti. Un dw è una collezione di dati di supporto per il processo decisionale che presenta le seguenti caratteristiche: è orientata ai soggetti di interesse, è integrata e consistente; è rappresentativa dell evoluzione temporale, è non volatile. 211 DW Si incentra sui concetti di interesse per l azienda quali i clienti, i prodotti, gli ordini L accento sugli aspetti di integrazione e consistenza è importante perché il dw si appoggia a più fonti dati eterogenee: dati estratti da sistemi informativi aziendali o sorgenti dati esterne Deve mantenere la continuità temporale Riorganizza le informazioni esistenti non comporta mai l inserimento di nuove informazioni

32 Il sistema di datawarehousing A volte con il termine datawarehouse si intendono tutti i sistemi che implementano il processo datawarehousing. Il termine dw a volte denota l intero sistema anziché il solo contenitore dei dati di sintesi 213 Elementi distintivi del processo di datawarehousing Accessibilità a utenti con conoscenze limitate di informatica e di strutture dati Integrazione dei dati sulla base di un modello standard dell impresa Flessibilità di interrogazione per trarre il massimo vantaggio dal patrimonio informativo esistente Sintesi per permettere analisi mirate ed efficaci Rappresentazione multidimensionale per offrire all utente una visione intuitiva ed efficacemente manipolabile delle informazioni Correttezza e completezza dei dati integrati

33 Architettura generale per il data warehousing 215 Architettura per il data warehousing (Inmon)

34 Architettura per il data warehousing (Kimball) 217 Architettura ad 1 livello

35 Architettura ad 1 livello Obiettivo: minimizzazione dei dati memorizzati ottenuta eliminando le ridondanze Il dw è virtuale in quanto viene implementato come una vista sul db operazionale generata da un apposito middleware Non molto utilizzato nella pratica 219 Architettura a 2 livelli

36 Architettura a 2 livelli (data mart indipendenti) 221 Architettura a 2 livelli 1. Livello delle sorgenti: il DW utilizza fonti dati eterogenee: Da sistemi informativi, legacy db relazionali 2. Livello della Alimentazione: i dati memorizzati nelle sorgenti devono essere estratti e ripuliti per eliminare le inconsistenze e completare le eventuali parti mancanti, integrati per fondere sorgenti eterogenee secondo uno schema comune. I cosi detti strumenti ETL (Extraction, Transformation and loading) permettono di integrare schemi eterogenei nonché di estrarre, trasformare, ripulire, validare, filtrare e caricare i dati dalle sorgenti nel DW

37 Architettura a 2 livelli (3/3) 3. Livello del warehouse: le informazioni vengono raccolte in un singolo contenitore centralizzato logicamente il DW. Può essere direttamente consultato o usato come sorgente per costruire i datamart che ne costituiscono una parziale replica, orientati verso specifiche aree di impresa. Accanto al DW il contenitore dei metadati mantiene informazioni sulle sorgenti, sui meccanismi di accesso, sulle procedure di pulizia ed alimentazione, sugli schemi dei datamart, sugli utenti 4. Livello di analisi: Permette la consultazione efficiente e flessibile dei dati integrati ai fini di stesura di report, analisi e simulazione 223 Architettura a tre livelli

38 Architettura a tre livelli Introdotto il livello dei dati riconciliati detto anche operational data store che materializza i dati operazionali ottenuti a voalle del processo di integrazione e ripulitura dei dati sorgente: quindi dati integrati, consistenti, corretti, volatili, correnti e dettagliati Vantaggio : Crea un modello di dati comune per l intera azienda e separa le problematiche relative all estrazione e integrazione, da quelle relative al caricamento del dw Potrebbe essere una vista virtuale integrata nelle sorgenti operazionali 225 Elementi di un data warehouse

39 WorkFlow : dai Dati alle Informazioni, dalle Informazioni alla Conoscenza 227 Flusso delle informazioni

40 Piu in dettaglio Source systems 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)

41 Data staging Area di memorizzazione i dati sorgente vengono trasformati; tecnologia relazionale ma anche flat files; insieme di processi che: puliscono, trasformano, combinano, duplicano, archiviano e preparano i dati sorgente per essere usati nel DW. 231 Il Popolamento del Warehouse (esempio di tecnica)

42 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) 233 Presentation server Un DW rappresenta spesso l unione di più data mart Data mart: restrizione data warehouse ad un singolo processo o ad un gruppo di processi aziendali (es. Marketing)

43 End-user data access tools Client del DW, di facile utilizzo tools per interrogare, analizzare e presentare l informazione contenuta del DW a supporto di un particolare bisogno aziendale invio di specifiche richieste al presentation server in formato SQL 235 I Metadati (Repository) Informazioni sui dati: T utte le informazioni sulle operazioni che vengono eseguite per creare il data warehouse sono salvate in un oggetto chiamato Repository o Metadati. Il Repository permette di tenere aggiornati i datawarehouse

44 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 l ha creato, storia delle trasformazioni di un dato nel tempo, statistiche, dimensione tabelle, ecc Esempio metadati

45 Analisi dell Ipercubo Qualsiasi strumento di analisi basato su un warehouse risulta essere più completo, affidabile, certificato, infrastrutturale, veritiero: Analisi delle vendite A.B.C. Controllo di Gestione Reporting, Pivoting Balanced Scorecard C.R.M. Data Mining 239 Classi di tools

46 Il ciclo di vita dei sistemi di datawarehousing 241 Considerazioni I sistemi di data warehousing stanno acquisendo popolarità via via che aziende e imprese nei più disparati settori ne intuiscono i benefici Larga parte delle organizzazioni mancano della necessaria esperienza e capacità nell affrontare con successo le sfide implicite nei progetti di data warehousing La mancata adozione di un approccio metodologico minaccia la riuscita dei progetti di dw

47 Fattori di rischio Conosci il tuo nemico (stratega cinese di 4000 anni fa) Rischi legati alla gestione del progetto: Coinvolge trasversalmente tutti i livelli aziendali e porta con se importanti implicazioni politiche e organizzative La necessità di condivisione delle informazioni tra i reparti che viene vissuta con riluttanza dai responsabili aziendali Definizione dell ambito e delle finalità del sistema e alla sua sponsorizzazione (alcuni progetti vengono stroncati sul nascere dall incapacità di presentare una convincente valutazione dei costi e dei benefici) 243 Fattori di rischio (2) Rischi legati alle tecnologie: le tecnologie per la progettazione, l implementazione, l uso e il mantenimento dei sistemi di dw si stanno evolvendo rapidamente e l architettura proposta deve essere in grado di mantenere il passo. Tra i possibili problemi: scarsa scalabilità dell architettura in termini di dati e di utenti, assenza di estendibilità per accogliere le tecnologie, componenti e applicazioni, la gestione inefficace dell interscambio di meta-dati tra i diversi componenti

48 Fattori di rischio (3) Rischi legati ai dati e alla progettazione: Questi fattori di rischio dipendono dalla qualità dei dati del progetto realizzato. In particolare il rischio è quello di ottenere risultati di scarso valore a causa: Dell instabilità e inaffidabilità delle sorgenti Dell inaccurat a speci ficazione dei requisiti utente Dell incapacità di fornire un elevato valore aggiunto agli utenti e alla consegna dei primi prototipi, che mina la fiducia dell intero progetto 245 Fattori di rischio (4) Rischi legati all organizzazione: Incapacità di impegnare l utente finale in un reale interesse e sostegno per il progetto La difficoltà di trasformare radicalmente la cultura dell azienda per renderla conscia del valore dell informazione L impossibilità degli utenti di trarre vantaggio dai risultati ottenuti causa inerzia organizzativa

49 Fattori di rischio (5) Il rischio di ottenere un risultato insoddisfacente nei progetti di dw è molto alto proprio a causa delle elevatissime aspettative degli utenti Inoltre, larga parte delle responsabilità della riuscita del progetto ricade sulla qualità dei dati sorgente e sulla lungimiranza, disponibilità e dinamismo del personale dell azienda. 247 Qualità dei dati La qualità di un processo misura l aderenza agli obiettivi degli utenti Fattori che influenza la qualità dei dati: Accuratezza (conformità tra il valore memorizzato e quello reale) Attualità (il dato memorizzato non è obsoleto) Completezza (non mancano informazioni) Consistenza (la rappresentazione dei dati è uniforme) Disponibilità (i dati sono facilmente disponibili agli utenti) Tracciabilità (e possibile risalire alla fonte di ciascun dato) Chiarezza (i dati sono facilmente interpretabili)

50 Approccio Metodologico: Top- Down Top down: analizzare i bisogni globali dell azienda e pianificare lo sviluppo del dw per poi progettarlo e realizzarlo nella sua interezza Promette di ottenere ottimi risultati perché si basa su una visione globale dell obiettivo e garantisce in linea di principio di ottenere un dw consistente e ben integrato L esperienza ha dimostrato che:» Il preventivo di costi onerosi a fronte di lunghi tempi di realizzazione scoraggia la direzione a intraprendere l intero progetto» Affrontare contemporaneamente l analisi e la riconciliazione di tutte le sorgenti di interesse è un compito estremamente complesso» Riuscire a prevedere a priori tutte le esigenze aziendali è pressochè impossibile e il processo di analisi rischia di subilre una paralisi» Il fatto di non prevedere la consegna a breve termine di un prototipo non permette agli utenti di verificare l utilità e fa 249 scemare l interesse e la fiducia Approccio Metodologico: Bottom-up Il DW viene costruito in modo incrementale assemblando iterativamente più Data Mart, ciascuno dei quali incentrato ad un insieme di fatti collegati ad uno specifico settore aziendale di interesse per una certa categoria di utenti (es. data Mart magazzino, Marketing,..)

51 Approccio Metodologico: Bottom-up (2) Abbinando questo approccio a tecniche di prototipazione veloce si riducono notevolmente l intervallo di tempo ed il costo necessari affinchè la dirigenza aziendale possa avere un riscontro sull effettiva utilità del sistema in via di realizzazione, mantenendo così costantemente elevata l attenzione sul progetto. 251 Approccio Metodologico: Bottom-up (3) Questo approccio non è esente da rischi in quanto determina una visione parziale del dominio di interesse Per ottenere i migliori risultati è importante porre attenzione al primo data-mart da prototipare: deve essere quello che gioca il ruolo più strategico per l azienda e deve ricoprire un ruolo centrale e di riferimento per l intero DW cosicchè i successivi Data Mart possano essere agevolmente integrati Inoltre è consigliabile che il data mart prescelto si appoggi su fonti dati disponibili consistenti

52 Esempio Data Mart Ospedaliero DM 1: rilevazione e rendicontazione delle attività ospedaliere DM2: data mart per l area contabile DM3: Data Mart area epidemiologica DM4: Data Mart per la gestione del personale DM5: Data Mart per gli acquisti 253 Ciclo di vita per un sistema di DW

53 Fasi per la progettazione di un sistema di DW (1) 1. Definizione degli obiettivi e pianificazione: Studio di fattibilità orientato alla chiara individuazione degli obiettivi e dei confini del sistema, alla stima delle sue dimensioni, alla scelta dell approccio per la costruzione, alla valutazione dei costi e del valore aggiunto. Vengono inoltre affrontate questioni di tipo organizzativo attraverso l analisi dei rischi e delle aspettative e lo studio delle competenze del gruppo di lavoro. Viene così prodotto un piano di attuazione del progetto di dw che viene sottoposto per l approvazione alla direzione. 255 Fasi per la progettazione di un sistema di DW (2) 2 Progettazione della infrastruttura: Durante questa fase si analizzano e si comprano le possibili soluzioni architetturali valutando le tecnologie e gli strumenti disponibili, al fine di realizzare un progetto di massima dell intero sistema

54 Fasi per la progettazione di un sistema di DW (3) 3 Progettazione e sviluppo del Data Mart: Ciascuna iterazione di questa fase comporta la creazione di un nuovo Data Mart e di nuove applicazioni che vengono via via integrate nel sistema di DW 257 Il Business Dimensional Lifecycle

55 Il Business Dimensional Lifecycle (2) 259 La Rapid Warehousing Methodology

56 La Rapid Warehousing Methodology (2) 1. Accertamento: l obiettivo di questa fase è verificare che l azienda sia effettivamente pronta ad affrontare il progetto da un lato, determinarne i costi i rischi e i benefici dall altro 2. Requisiti: definizione dei requisiti e alla specifica delle applicazioni utente e consiste nella raccolta delle specifiche di analisi, di progetto e di architettura dell intero sistema 3. Progettazione: Attenzione centrata su un solo progetto per volta. Le specifiche di analisi vengono raffinate per generare il progetto logico e fisico dei dati e il progetto dell alimentazione; vengono inoltre selezionati gli strumenti di implementazione 4. Costruzione: il DW viene implementato e popolato con i dati estratti dalle sorgenti, le applicazioni di front-end vengono sviluppate e collaudate 5. Attuazione: Il sistema viene consegnato e avviato, dopo che gli utenti sono stati adeguatamente addestrati 6. Amministrazione e Manutenzione: Questa fase continua durante tutta la vita del sistema e prevede l estensione delle sue funzionalità, il ridimensionamento dell architettura per venire incontro ai nuovi fabbisogni, il controllo della qualità dei dati 7. Riesame: Ciascun sottoprogetto si accompagna a tre processi di riesame: uno a verifica dell implementazione, uno a seguito dell attuazione per verificare che il sistema sia stato ben accettato dall organizzazione, uno a valle dell intero processo per misurarne i benefici effettivi 261 Le 7 fasi di progettazione di un Data Mart Il punto focale di ciascuna interazione prevista durante lo sviluppo bottom-up di un DW è la costruzione di un singolo Data Mart processo reso complesso anche dal fatto che richiede tecniche di progettazione completamente diverse da quelle utilizzate per le tradizionali basi dati operazionali

57 Le 7 fasi di progettazione di un Data Mart 263 Vista funzionale sui flussi informativi scambiati durante le 7 fasi

58 Le 7 fasi di progettazione di un Data Mart Restano escluse le fasi di implementazione delle applicazioni utente che dipendono principalmente dagli specifici strumenti e linguaggi utilizzati (faremo degli esempi in MDX) 265 Analisi e riconciliazione delle fonti dati Definire e documentare lo schema del livello dei dati operazionali a partire dal quale verrà implementato il livello dei dati riconciliati Occorre quindi analizzare e comprendere gli schemi delle sorgenti disponibili (ricognizione) eventualmente trasformarli per portare alla luce correlazioni disponibili precedent emente non espresse (normalizzazione), determinare quali porzioni siano utili ai fini del processo decisionale nel settore aziendale cui il data mart è dedicato e infine valutare la qualità dei dati. Qualora le sorgenti siano più di una i loro schemi dovranno inoltre essere sottoposti ad una attività di omogeneizzazione e integrazione tesa ad individuare i tratti comuni e a sanare le eventuali inconsistenze. Gli utenti coinvolti sono il progettista, l amministratore di db, lo stakeolder del dominio applicativo. Per la mancanza di documentazione, tale fase può richiedere anche il 50% dei tempi dell intero progetto

59 Analisi dei requisiti Vengono raccolti, filtrati e documentati i requisiti espressi dagli utenti con l obiettivo di delineare quali sono le informazioni di interesse da rappresentare in sintonia con gli obiettivi perseguiti. In uscita da questa fase vengono prodotte specifiche sui fatti da modellare e indicazioni preliminari sul carico di lavoro La scelta dei fatti è responsabilità dell utente finale guidato dal progettista sulla base della documentazione del livello riconciliato prodotta al passo precedente. Per ogni fatto occorre definire l intervallo di storicizzazione, ovvero quale arco temporale dovranno abbracciare gli eventi memorizzati 267 Progettazione concettuale La progettazione concettuale comporta l utilizzo dei requisiti utenti per disegnare a partire dallo schema riconciliato uno schema concettuale per il data mart. Il modello concettuale adottato è il dimensional fact model che prevede la creazione di uno schema di fatto per ciascun fatto di interesse evidenziato dall utente Uno schema di fatto è in grado di descrivere graficamente tutti i concetti del modello multidimensionale: Fatti, misure, dimensioni e gerarchie; è in grado di rappresentare accuratamente le diverse sfumature concettuali che caratterizzano gli scenari più complessi. L insieme degli schemi di fatto costituisce lo schema concettuale del Data M art

60 Raffinamento del carico di lavoro e validazione dello schema concettuale Raffinare io carico di lavoro formulando ciascuna interrogazione direttamente sullo schema concettuale. Ciò permette di verificare che tutte le interrogazioni previste siano effettivamente esprimibili e quindi in ultima analisi validare lo schema concettuale prodotto Determinazione del volume dei dati 269 Progettazione logica Scelta del modello logico di riferimento: Rolap, Molap Una volta definito lo scema logico di base secondo lo schema a stello, la tecnica che maggiormente impatta sulle prestazioni è la materializzazione delle viste

61 Progettazione fisica Il problema di maggior rilievo durante la progettazione fisica è la scelta degli indici da costruire per ottimizzare le prestazioni In questa fase occorre riferirsi ad uno specifico RDBMS Definire il carico di lavoro ed il volume dei dati 271 Progettazione dell alimentazione Vengono prese le decisioni con gli utenti e con gli amministratori del sistema informatico riguardo il processo dell alimentazione del livello riconciliato (se presente) del data Mart

62 Il quadro metodologico Approccio guidato dai dati: si progetta il data mart a partire da una dettagliata analisi delle sorgenti operazionali. In questo caso i requisiti utente impattano sul progetto guidando il progettista nella selezione delle porzioni di dati considerate rilevanti per il processo decisionale e determinando la loro strutturazione secondo il modello multidimensionale 273 Il quadro metodologico (1) Gli approcci guidati dai requisiti: iniziano determinato di requisiti informativi degli utenti del data mart. Il problema di come creare una mappatura di questi requisiti e le sorgenti dati disponibili viene affrontato solo in seguito attraverso l implementazione di procedure ETL adatte

63 Il quadro metodologico (2) Entrambi gli approcci sono validi e possono essere usati in parallelo per ottenere una progettazione ottimale. Le sorgenti dati vengono comunque esplorate per plasmare le gerarchie e al contempo i requisiti utente giocano un ruolo fondamentale nel restringere l area di interesse per l analisi e nella scelta di fatti, dimensioni e misure 275 Scenario 1: Approccio guidato dai dati Forte peso alla modellazione del Data Mart La fase di analisi e riconciliazione delle fonti dati viene fatta per prima Poi l analisi dei requisiti per disegnare lo schema concettuale senza perdere di vista la natura dei dati effettivamente disponibili P rerequisiti Deve essere disponibile preliminarmente oppure ottenibile in tempi brevi una conoscenza approfondita delle sorgenti dati da cui il Data Mart si alimenterà Gli schemi delle sorgenti devono mostrare un buon grado di normalizzazione La complessità degli schemi delle sorgenti non deve essere eccessiva L esperienza di progettazione ha mostrato che qualora applicabile, l approccio guidato dai dati risulta preferibile poiché permette di raggiungere i risultati prefissati in tempi contenuti

64 Scenario 2: Approccio guidato dai requisiti Fattore determinante sono i requisiti espressi dall utente Trasformare i requisiti in uno schema concettualefase molto delicata in quanto non si ha una conoscenza approfondita dei dati Ricavare manualmente tutti i legami tra il data Mart e le sorgenti dati operazionali E il più difficile da perseguire. Costituisce l unica alternativa nel caso in cui non sia fattibile costruire a priori un analisi approfondita delle sorgenti. 277 Scenario 3: Approccio Misto In medio stat virtus L analisi delle sorgenti e dei requisiti vengono svolte in parallelo: la prima porta a definire in modo formale i requisiti, la seconda conduce al disegno di livello riconciliato Questo approccio è consigliato quando l estensione e la complessità del livello riconciliato sono notevoli

65 La progettazione di un Data Mart I. Analisi e riconciliazione delle fonti dati input: schema delle sorgenti output: schema riconciliato II. Analisi dei requisiti input: schema riconciliato output: fatti, carico di lavoro preliminare III. Progettazione concettuale input: schema riconciliato, fatti, carico di lavoro preliminare output: schemi di fatto IV. Raffinamento del carico di lavoro, validazione dello schema concettuale input: schemi di fatto, carico di lavoro preliminare output: carico di lavoro, schemi di fatto validati 279 La progettazione di un Data Mart V. Progettazione logica input: schema di fatto, modello logico target, carico di lavoro output: schema logico del data mart VI. Progettazione dell alimentazione input: schemi delle sorgenti, schema riconciliato, schema logico del data mart output: procedure di alimentazione VII. Progettazione fisica input: schema logico del data mart, DBMS, target, carico di lavoro output: schema fisico del data mart

66 Le fasi della progettazione di un data mart (1) 281 Le fasi della progettazione di un data mart (2)

67 Le fasi della progettazione di un data mart (3) 283 Le fasi della progettazione di un data mart (4)

68 La progettazione del Data Mart 285 La progettazione del Data Mart

69 Analisi e riconciliazione delle fonti dati 287 Analisi e riconciliazione delle fonti dati Sorgenti eterogenee: Per tecnologia tecnologia utilizzate (DBMS, fogli elettronici, file system). Per modello modello attraverso il quale rappresentare la realtà (modello relazionale, modello ad oggetti, flat file). Per semantica semantica che esprimono i fatti da modellare o dominio applicativo. Schema locale di una sorgente: esprime lo schema concettuale che descrive la semantica dei dati immagazzinati, indipendentemente dal modello e dalla tecnologia utilizzata. Generalmente viene modellato attraverso linguaggi formali o semiformali (UML, E/R, etc.) L attenzione è posta sulla rappresentazione del dominio applicativo che è ugualmente possibile utilizzando una base dati relazionale, un foglio elettronico, un semplice file: nel primo caso lo schema è codificato dall insieme di relazioni e dei vincoli che le collegano, nel secondo dai legami tra le diverse celle del foglio, infine nel terzo lo schema è 288 ricavabile utilizzando il tracciato record del file. 69

70 Analisi e riconciliazione delle fonti dati (2) Le varie sorgenti operazionali possono essere fortemente correlate o completamente indipendenti e i domini che descrivono possono essre disgiunti oppure sovrapposti. Compito primario del progettista durante la fase di analisi delle fonti dati è acquisire una conoscenza quanto più possibile approfondita che gli consenta di individuare i concetti rilevanti ai fini del DW e le sorgenti dati più adatte ad alimentarlo. 289 Analisi e riconciliazione delle fonti dati (3) L analisi delle fonti dati non è di per se sufficiente a creare i presupposti per le fasi successive di progettazionein quanto essa nella maggior parte dei casi evidenzierà un insieme di inconsistenze ed errori che devono forzatamente essere risolti prima di procedere oltre. Uno dei principi fondanti del DW è il concetto di DATO INTEGRATO che permette di derivare informazioni consistenti e prive di errori. Il raggiungimento di questo ambizioso risultato necessita di un processo di riconciliazione che comporta integrazione, pulizia e trasformazione dei dati e può richiedere un elevato dispendio di tempo e di risorse

71 Analisi e riconciliazione È la fase più complessa di un progetto di DW L analisi delle fonti dati deve condurre l analista alla scelta dei fatti rilevanti al DW e alla individuazione delle sorgenti più adatte ad alimentarlo. Il principio base di un progetto di DW è il concetto di dato integrato che permette di avere informazioni coerenti, consistenti e prive di errori. Il dato integrato è il risultato del processo di riconciliazione riconciliazione: Integrazione (consistenza e semantica corretta) Pulizia e trasformazione (coinvolgono i dati veri e propri derivati dall integrazione) 291 Analisi e riconciliazione Le 3 fasi per la progettazione del livello riconciliato a partire Dal livello operazionale

72 Analisi e riconciliazione Il processo di analisi e riconciliazione riceve in ingresso gli schemi delle sorgenti e produce un insieme di meta dati che modellano lo schema riconciliato e le corrispondenze (mapping) tra gli elementi di quest ultimo e quelli del sistema operazionale. Utilizzando le informazioni contenute nei metadati e ricorrendo alle sorgenti operazionali per valutare la qualità delle sorgenti informative attraverso i due rimanenti processsi vengono progettate le procedure ETL che saranno utilizzate per alimentare il DW 293 Il modello architetturale a 3 livelli

73 Passi progettuali per la fase 295 Ricognizione e normalizzazione degli schemi Ricognizione, che consiste in un esame approfondito degli schemi locali mirato alla piena comprensione del dominio applicativo; Normalizzazione, il cui obiettivo è correggere gli schemi locali al fine di modellare in modo più accurato il dominio applicativo (il termine normalizzazione viene usato per rappresentare il processo che porta ad arricchire lo schema locale di dipendenze funzionali precedentemente non rappresentate) La fase di ricognizione e normalizzazione deve essere svolta anche qualora sia presente una sola sorgente dati

74 Ricognizione e normalizzazione degli schemi (2) Durante questa fase di analisi, il progettista deve verificare la completezza degli schemi locali sforzandosi di individuare eventuali correlazioni involontariamente omesse. Esempi tipici sono l esplicitazione di dipendenze funzionali precedentemente tralasciate e l individuazione di nuove associazioni tra le entità Queste operazioni possono portare ad una trasformazione dello schema locale al fine di conform arlo alle peculiari esigenze del DW Il progettista deve anche individuare eventuali porzioni degli schemi non utili al data mart.ad esempio nel data mart delle vendite, non sono interessanti le informazioni di carattere amministrativo o relative ai costi di gestione del negozio Ricognizione e normalizzazione degli schemi(3) Le trasformazioni apportate allo schema non devono introdurre nuovi concetti ma rendere espliciti tutti quelli ricavabili dai dati memorizzati nelle sorgenti operazionali

75 Esempio: prodotti di una azienda 299 Esempio: prodotti di una azienda (2) La prima trasformazione è lecita poiché la dipendenza funzionale codiceprod->codicecategoria è vera anche se non rappresentata nello schema sorgente e la cardinalità della associazione appartiene a è verificabile analizzando i dati della sorgente La seconda trasformazione non è lecita poiché sebbene possa esistere una suddivisione in sottocategorie, la sorgente operazionale non contiene le informazioni necessarie per estrarla. Volendo comunque evidenziarla nel data-mart si dovrà indiviudare la sorgente dati contenente le informazioni necessarie e procedere conseguentemente all integrazione