Dipartimento di Informatica
Corso di Laurea Magistrale in Business Informatics
TESI DI LAUREA
Progettazione e sviluppo di un sistema di Business Intelligence per l’analisi dei tirocini in un contesto universitario
RELATORE
Prof. Dino Pedreschi CORRELATORE Dott.ssa Simona Arma CONTRORELATORE
Prof.ssa Maria Grazia Scutellà
CANDIDATO Nunzio Spontella
Bruciare sempre Spegnersi mai.
Le organizzazioni raccolgono dati per trarre informazioni, valutazioni e stime necessarie per pianificare e controllare le attività aziendali con efficacia. Con l’aumentare dei dati acquisiti dai sistemi gestionali le normali basi di dati non offrono soluzioni adeguate per la gestione e la storicizzazione di questi; il fenomeno del data warehousing nasce proprio dall’esigenza di gestire l’enorme accumulo di dati e dalla pressante richiesta di utilizzare attivamente questi dati nel business d’impresa per scopi che superino quelli, di routine, legati all’elaborazione giornalie-ra. Il dominio di utilità dei sistemi di data warehousing spazia dall’area sanitaria a quella commerciale sino ad arrivare alle Università. A fattore comune in tutti questi settori vi è la necessità di analizzare trend e benchmarking per la valutazione delle scelte strategiche così da ottenere dall’enorme quantità di dati immagazzinati nei database, informazioni di sintesi utili per il supporto alle decisioni.
L’obiettivo di questa tesi è quello di sviluppare e integrare in un Data Warehouse esistente quattro nuovi cubi nell’ambito dei tirocini formativi e curriculari. In questo modo si potranno estendere le misurazioni delle attività di didattica e di ricerca e permettere agli utenti finali di organizzare e svolgere al meglio le proprie attività istituzionali. Inoltre il monitoraggio dei processi di tirocinio, delle offerte formative, delle convenzioni Università-Aziende esterne e lo studio dei risultati dei questionari di valutazione degli studenti consentirà alla governance di Ateneo di prendere le decisioni strategicamente più rilevanti.
Indice
1 Introduzione ai sistemi DSS 1
1.1 Business Intelligence . . . 1
1.2 I sistemi di DSS . . . 3
1.3 Sistemi transazionali vs Sistemi analitici . . . 4
1.3.1 I punti chiavi di un sistema DSS . . . 6
1.3.2 Il progetto del database . . . 7
1.4 Il Data Warehouse . . . 7
1.4.1 Alimentazione del DWH . . . 9
1.4.2 Il processo di ETL . . . 9
1.4.3 Il processo di E-LT . . . 11
1.4.4 Architetture di un Data Warehouse . . . 12
1.4.5 Architettura a silos vs architettura warehouse bus . . . 14
1.4.6 Progettazione di un Data Warehouse . . . 14
1.4.7 Ottimizzazione di un Data Warehouse . . . 15
2 Il Modello Multidimensionale 18 2.1 Il modello multidimensionale concettuale . . . 18
2.1.1 Attributi e dimensioni . . . 19
2.1.2 Relazioni . . . 21
2.1.3 Gerarchie . . . 21
2.1.4 Fatti e misure . . . 22
2.3 Database relazionale vs Multidimensionale . . . 25
2.3.1 Il database relazionale come supporto al modello multidi-mensionale . . . 28
2.3.2 Star schema . . . 29
2.3.3 Snowflake schema . . . 30
3 Il progetto di tesi 31 3.1 L’azienda ospitante: Iconsulting . . . 31
3.2 Obiettivi di progetto . . . 32
3.3 Approccio metodologico . . . 33
3.4 Stack tecnologico . . . 34
3.4.1 Indyco . . . 35
3.4.2 Oracle . . . 37
3.5 Descrizione del progetto . . . 39
3.5.1 As-Is . . . 39
3.5.2 L’architettura To-Be . . . 40
3.5.3 Fasi di sviluppo del progetto . . . 41
4 Analisi 43 4.1 I cubi realizzati . . . 44
5 Design concettuale 46 5.1 Individuazione delle dimensioni conformi . . . 46
5.2 Modellazione concettuale dei Data Mart . . . 47
5.2.1 Tirocini Approvati . . . 47
5.2.2 Offerta dei Tirocini . . . 50
5.2.3 Convenzioni con le Aziende . . . 52
5.2.4 Questionari di valutazione . . . 53
6 Sviluppo 56 6.1 Architettura della soluzione . . . 56
6.2 Naming convention . . . 57
6.3 Sviluppo della Staging Area . . . 58
6.3.1 Sviluppo della fact table Tirocini Approvati . . . 63
6.3.2 Sviluppo della fact table Offerte dei Tirocini . . . 69
6.3.3 Sviluppo della fact table Convenzioni con le aziende . . . . 72
6.3.4 Sviluppo della fact table Questionari di Valutazione . . . . 73
6.4 Pulizia del dato . . . 77
6.5 Sviluppo del Data Mart . . . 78
6.6 Organizzazione dei flussi di esecuzione: I pacchetti . . . 79
7 Test 81 7.1 Test . . . 81
7.2 User Acceptance Test . . . 82
8 Sviluppi futuri e conclusioni 85 8.1 Sviluppi futuri . . . 85
1.1 Il processo di Business Intelligence . . . 1
1.2 Differenze tra OLTP e OLAP . . . 6
1.3 Il processo di ETL . . . 10
1.4 Il processo di E-LT . . . 11
2.1 Schema concettuale dei fatti con dimensioni e attributi dimensionali 20 2.2 Il cubo multidimensionale . . . 20
2.3 Schema concettuale dei fatti con attributi dimensionali e gerarchie 22 2.4 Schema concettuale dei fatti . . . 23
2.5 Esempi di operazioni tipiche su un modello multidimensionale . . 25
2.6 Esempio di tabella relazionale . . . 26
2.7 Esempio di array bidimensionale . . . 26
2.8 Esempio di star schema schema . . . 30
2.9 Esempio di snowflakes schema . . . 30
3.1 Be-Lean methodology . . . 33
3.2 Architettura To-Be del Data Warehouse . . . 41
5.1 Dimensioni conformi legate all’ambito dei tirocini . . . 47
5.2 Data Mart Tirocini Approvati . . . 48
5.3 Data Mart Offerte di Tirocinio . . . 50
5.4 Data Mart Convenzioni Aziende Tirocini . . . 52
6.1 Ambiente Architetturale . . . 57
6.2 Processo di caricamento e certificazione dei dati . . . 57
6.3 Struttura di Staging Area del flusso dei tirocini . . . 59
6.4 Flusso di importazione delle sorgenti - schema Tirocini . . . 60
6.5 Interfaccia di popolamento della tabella periodi tirocini (secondo step) . . . 65
6.6 Interfaccia di popolamento della tabella temporanea (terzo step) . 66 6.7 Interfaccia di popolamento della tabella temporanea (quarto step) 66 6.8 Interfaccia di popolamento della fact table Tirocini Approvati . . 67
6.9 Interfaccia di popolamento della tabella temporanea . . . 69
6.10 Interfaccia di popolamento della fact table Offerta dei Tirocini . . 71
6.11 Interfaccia di popolamento della fact table Convenzioni con le Aziende 72 6.12 Interfaccia di popolamento della fact table Questionari di Valutazione 74 6.13 Struttura di un questionario . . . 76
Introduzione ai sistemi DSS
In questo primo capitolo saranno affrontati i concetti fondamentali sui sistemi di supporto alle decisioni e della Business Intelligence con l’obiettivo di comprendere meglio il lavoro di tesi svolto. In particolare, si parlerà in maniera approfondita dei sistemi transazionali e delle differenze con i sistemi analitici; ci si soffermerà sul Data Warehouse e sulle possibili ottimizzazioni.
1.1
Business Intelligence
Si definisce la Business Intelligence come una serie di processi aziendali di trasformazione di dati e informazioni in conoscenza con lo scopo di produrre conoscenza in piani che orientano il processo decisionale ai vari livelli dell’organiz-zazione.
Figura 1.1: Il processo di Business Intelligence
1.1 Business Intelligence
metodi, processi, persone e strumenti che rendono possibile la raccolta regolare ed organizzata di dati attraverso elaborazioni, analisi o aggregazioni che ne permetto-no la trasformazione in informazioni, tale da costruire un supporto alle decisioni strategiche. Proprio i dati, sono il core delle attività ed essi, tipicamente ricevuti allo stato ‘grezzo’, vengono poi elaborati per la costruzione dell’informazione ed il conseguente utilizzo in azienda. Un sistema di BI deve possedere le seguenti caratteristiche:
• Facilità d’uso: presentare i dati in un formato che sia facile da leggere e da interpretare
• Velocità: possibilità di processare grandi volumi di dati con tempi di rispo-sta quasi irispo-stantanei grazie all’uso di tecniche di modellazione, memorizzazione e indicizzazione dei dati orientate all’analisi piuttosto che all’aggiornamento dei dati
• Integrazione: integrare tra loro dati provenienti da fonti differenti. Il processo di integrazione deve essere affidabile e testato, in modo che gli utenti possano fare affidamento sui dati presenti nel DW
• Storicizzazione: mantenere la storia dei cambiamenti subiti da certi attributi selezionati, per permettere analisi storiche
• Identificazione di trend e anomalie: gli strumenti devono facilitare l’i-dentificazione dei trend nei dati, ad esempio confrontando periodi e prodotti diversi, attraverso l’utilizzo di strumenti interattivi che permettano, ad esempio, di effettuare operazioni di aggregazione per ottenere un maggiore dettaglio (Drill-Down) oppure, a seconda delle esigenze un minor detta-glio (Roll-Up) dei dati. Questi concetti saranno affrontati in maniera più approfondita nel prossimo capitolo
• Simulazione scenari: in certi casi deve essere possibile impostare degli scenari e confrontarli poi con i valori reali
• Adattabilità nel tempo: capacità di affrontare e sfruttare le evoluzioni della realtà aziendale, dei sistemi operazionali e delle esigenze di analisi • Sicurezza: deve essere possibile l’accesso ai dati, che in molti casi includono
informazioni altamente riservate.
1.2
I sistemi di DSS
Negli ultimi anni i sistemi informativi aziendali hanno subito un radicale cambiamento, infatti, si è passati da una base di dati centralizzata a cui era demandato il compito di servire tutte le tipologie di attività (richieste dagli utenti finali) a un sistema che separa le attività di tipo operazionale o attività transazionali (vendite, spedizioni, immissione di ordini) dalle attività di analisi dei dati e di pianificazione.
Questa separazione è stata resa necessaria per diverse ragioni [Inm92]:
• Gli utenti dei sistemi tradizionali differiscono dagli utenti dei sistemi per l’analisi dei dati
• I tipi di elaborazioni effettuate sull’ambiente transazionale cambiano note-volmente da quelle di un ambiente di analisi
• Le tecnologie di supporto a queste due categorie di sistemi sono profonda-mente differenti
• La rappresentazione fisica delle informazioni è differente nei due ambienti operativi
A causa di queste e di molte altre ragioni, l’approccio moderno nella realizzazione di sistemi informativi è quello di realizzare sistemi distinti:
• Un sistema tradizionale di basi di dati OLTP(On-Line Transaction Proces-sing), dedicato alla gestione dei processi transazionali
• Un sistema per il supporto alle decisioni OLAP(On-Line Analytical Proces-sing), dedicato alla gestione dei processi di analisi dei dati
1.3 Sistemi transazionali vs Sistemi analitici
Nel prossimo paragrafo si approfondirà nel dettaglio cosa si intende quando si parla di queste due tipologie di processi.
1.3
Sistemi transazionali vs Sistemi analitici
I processi operazionali (OLTP), usando una metafora, sono quelli che fanno girare gli "ingranaggi" di un’organizzazione. Questi processi, infatti, governano la produzione e la gestione dei singoli dati aziendali provenienti dalle varie attività caratteristiche dell’impresa (vendite, spedizioni, ordini etc.) I relativi sistemi OLTP di supporto devono essere particolarmente efficienti nel processare queste transazioni. Possiamo definire un sistema operazionale (sistema transazionale o sistema OLTP) come [GR93]:
Un sistema in grado di facilitare ed automatizzare la costruzione di applicazioni, la loro esecuzione e l’amministrazione. Le applicazioni transazionali sono tipicamente costruite su una rete di diversi dispositivi e consistono principalmente di semplici operazioni di interrogazione ed aggiornamento, compiute su dati memorizzati all’interno di un database che ha il compito di modellare un generico sistema nella nostra realtà, mantenendo, al suo interno, una rappresentazione dello stato reale di questo sistema. Spesso questi sistemi sono fisicamente distribuiti su territori geografici distinti e coinvolgono tecnologie hardware e software eterogenee.
L’amministratore di un sistema OLTP deve inoltre garantire le performance del sistema ma anche un elevato grado di affidabilità. Quest’ultima è di fondamentale importanza per il sistema poiché se si ferma, l’intera impresa si arresta.
Caratteristiche salienti dei sistemi OLTP sono:
• L’accesso ai dati avviene sia in lettura che in scrittura. Infatti questi sistemi processano un gran numero di operazioni di interrogazione, inserimento, aggiornamento e cancellazione
• I dati sono orientati al tipo di applicazione
• Il formato dei dati non è uniforme lungo i vari sistemi. Questa è la diretta conseguenza dell’eterogeneità dei vari sistemi e applicazioni
• La storicizzazione dei dati è limitata ai soli dati recenti, come una fotografia istantanea dell’organizzazione
Usando la stessa metafora precedente, i processi analitici (OLAP) permettono agli utenti di guardare e controllare "come girano gli ingranaggi" di un’organizza-zione. Questi processi analitici fanno parte di una classe di sistemi denominata di Sistemi di supporto alle decisioni o Decision Support System (DSS). Una definizione più formale dice [PKB98]:
Un sistema di supporto alle decisioni è un sistema in grado di fornire chiare informazioni agli utenti, in modo che essi possano analizzare dettagliatamente una situazione e prendere facilmente le opportune decisioni sule azioni da intraprendere. In altre parole un sistema DSS è un sistema informativo dedicato a supportare i responsabili del business così da permettere decisioni più mirate, veloci ed efficaci. I sistemi DSS sono progettati per gestire enormi quantità di dati che provengono dai diversi sistemi OLTP presenti in azienda (Enterprise Resource Planner, Custo-mer Relationship Management, Supply Chain Management etc.) e da fonti esterne. Un requisito fondamentale di questi sistemi è la visione multidimensionale dei dati con la possibilità di cambiare rapidamente le prospettive di analisi e i livelli di dettagli, sfruttando la presenza di gerarchie. Le differenti prospettive di analisi dei dati vengono chiamate dimensioni del business.[Mic96]
Ad esempio, gli utenti di un sistema OLAP possono confrontare le vendite del-l’anno in corso con quelle deldel-l’anno precedente, verificare i trends delle vendite di un determinato prodotto, capire in quale città le vendite sono inferiori e attuare promozioni ad hoc, etc. Un sistema DSS deve quindi avere un unico obiettivo: contribuire ad incrementare le performance economiche di un’organizzazione for-nendo informazioni strategiche in modo semplice e veloce [Arb95][Adh96][Kad95]. Le principali differenze fra le applicazioni transazionali interattive che usano basi di dati (OLTP) e le applicazioni per il supporto alle decisioni che usano data warehouse (OLAP) sono riassunte in figura 1.2[ARDSD]:
1.3 Sistemi transazionali vs Sistemi analitici
Figura 1.2: Differenze tra OLTP e OLAP
1.3.1
I punti chiavi di un sistema DSS
Abbiamo visto che il termine DSS non indica un prodotto ma la strategia di memorizzare dati consolidati su un sistema informativo dedicato ad aiutare i responsabili di busines in tutta la gestione d’impresa. Vediamo ora quali sono i cinque termini chiave di questa strategia [Arb95]:
• Politica Significa determinare quali informazioni devono essere memoriz-zate nel nostro sistema, stabilire l’intervallo di aggiornamento di queste informazioni, stabilire regole di salvataggi e sicurezza dei dati.
• Trasformazione Prima del caricamento dei dati di livello base nel sistema, questi devono essere puliti e certificati in modo da rendere il valore del-l’informazione memorizzata significativamente rilevante per l’utente finale. Questa trasformazione può comportare la ristrutturazione, la ridefinizione, e il ricalcolo delle informazioni base.
• Memorizzazione Le sorgenti dei dati che popolano il DSS, come è stato detto poc’anzi, possono essere presenti in vari OLTP aziendali o in fonti esterne. I dati devono essere memorizzati in modo da massimizzare la flessibilità, la maneggevolezza e garantire l’accessibilità globale del sistema.
I dati memorizzati nel sistema DSS sono storici per natura e rappresentano le misure chiavi delle performance dell’impresa nel passato.
• Analisi I tipi di analisi che devono essere supportati sono la what if analysis (che cosa succede se..) e le computazioni su grandi volumi di dati. Queste analisi devono supportare un ambiente multiutente e devono fare uso di funzioni analitiche in grado di lavorare su dati storici e di produrre proiezione di dati. La tecnica più flessibile ed efficace per implementare questi tipi di analisi è sicuramente l’analisi multidimensionale di cui parleremo più approfonditamente nel capitolo successivo.
• Accesso E’ la capacità di vedere, selezionare e manipolare i dati disponibili attraveso alcuni desktop tools (query tools, strumenti di reportistica, fogli di calcolo) e mediante un’interfaccia grafica è possibile navigare facilmente tra queste operazioni.
1.3.2
Il progetto del database
La più grande differenza tra un sistema OLTP e un sistema DSS riguarda l’organizzazione dei dati all’interno del sistema . Molti dei miracoli ottenuti nelle performance dei sistemi transazionali sono dovuti al modello Entity-Relationship. Questo modello permette di eliminare la ridondanza dei dati, in modo da permet-tere ad una transazione, che debba cambiare un qualsiasi dato, di modificare il database in un solo punto. Questo modello però non è altrettanto efficace per i sistemi DSS, in quanto è di difficile comprensione per l’utente e non può essere na-vigato utilmente dal software del DSS. La soluzione è il modello multidimensionale che vedremo in dettaglio nel prossimo capitolo.
1.4
Il Data Warehouse
Un Data Warehouse (DWH) è una particolare base di dati analitica di supporto per il processo decisionale con le seguenti principali caratteristiche: [Kim96],
1.4 Il Data Warehouse
[KR02], [GR05]:1
1. Tempificata. I dati hanno un interesse storico e quindi contengono un’in-formazione sul tempo in cui si verificano certi eventi per consentire analisi di tendenza storicizzate.
2. Integrata I dati non provengono in genere da un’unica sorgente ma sono il risultato di un lungo e costoso processo di integrazione di dati eterogenei. Per esempio, una banca può raccogliere dati diversi sui clienti ai fini della gestione dei mutui, dei conti correnti, dei prestiti o delle azioni, ma essi vanno poi integrati ai fini delle l’analisi dei servizi offerti ai clienti.
3. Non-volatile I dati vengono usati interattivamente per operazioni di ricerca e non di modifica. Periodicamente ai dati disponibili se ne aggiungono di nuovi o si rimuovono quelli ritenuti obsoleti.
4. Organizzata per soggetti Nei sistemi transazionali i dati sono organizzati per eseguire le attività aziendali quotidiane, mentre nei sistemi direzionali i dati sono organizzati per memorizzare i dati per argomento, non per appli-cazioni e per analizzare dei soggetti di interesse che influenzano l’andamento complessivo dell’impresa. I soggetti aziendali differiscono da un’organizza-zione all’altra. Sono i soggetti critici per un’organizzaun’organizza-zione. Ad esempio, per un’azienda manifatturiera, queste includeranno vendite, spedizioni, resi e inventario.
5. Finalizzata ad analisi di supporto alle decisioni La funzione principale del data warehouse è per il supporto decisionale e pertanto deve essere specificatamente progettata per rispondere alle domande aziendali. I dati sono la realtà che un computer registra, archivia e tratta. Il livello più basso nella percezione della realtà è a volte indicato come "dati grezzi". Questi
1Il termine data warehouse (magazzino di dati) viene usato per analogia con il tradizionale
concetto di magazzino, nel quale vengono registrati i fatti provenienti da molte fonti correlate e/o non correlate tra di loro. Tale magazzino deve essere fisicamente indipendente dagli altri archivi, perché l’attività tipicamente molto pesante di interrogazione di un DSS non deve inficiare le prestazioni generali di un OLTP; inoltre, deve aggiornarsi solo nei momenti in cui le risorse di sistema sono meno utilizzate (ad esempio di notte) e deve essere interrogabile "liberamente"
dati sono di scarso beneficio a meno che non possano essere trasformati in informazioni e conoscenze utili. I dati devono essere condensati in un formato più informativo in modo tale che i manager (o più in generale i knowledge worker - dirigenti, manager e analisti) possano ottenere l’essenza dei dati sottostanti.
1.4.1
Alimentazione del DWH
Il Data Warehouse è solitamente diviso in sottoinsiemi logici chiamati Data Mart che hanno le stesse caratteristiche di un Data Warehouse, ma di solito più piccoli e si concentrano sui dati per un soggetto. Una definizione di questo termine dice [BA97]: Un Data Mart altro non è che un database analitico progettato per soddisfare le esigenze di una funzione di business (ad esempio vendite, marketing, finanze, etc.).
Il Data Mart quindi, nasce solitamente in maniera bottom-up per coprire specifiche aree di business e successivamente si integrano per formare il vero e proprio Data Warehouse. Un altro approccio è quello top-down in cui vi è prima la costruzione del DWH, poi l’aggregazione e l’esportazione dei sue dati verso i più specifici Data Mart.
1.4.2
Il processo di ETL
Il processo di ETL (Extraction, Transformation e Loading) è una espressione in lingua inglese che si riferisce al processo di estrazione dei dati dalle sorgenti informative, l’elaborazione e il consolidamento degli stessi attraverso opportune logiche e infine il caricamento all’interno del Data Warehouse. Queste operazioni vengono svolte all’interno di in un database, solitamente relazionale, collocabile, dal punto di vista funzionale, tra le sorgenti OLTP e il Data Warehouse chiamato Staging Area.Nella Staging Area viene creata la maggior parte del valore aggiunto del Data Warehouse [KRR98]: è infatti qui che vengono risolte tutte le problema-tiche di coerenza, qualità ed affidabilità dei dati.
1.4 Il Data Warehouse
Architettura ETL Tradizionale
Transform
Load
Extract
© Nunzio Spontella
Figura 1.3: Il processo di ETL
Nello specifico il processo di ETL comprende:
• Estrazione Allo start-up del sistema vengono estratti tutti i record in modalità full-refresh, mentre nelle fasi più evolute del ciclo di vita del sistema si può scegliere, a seconda delle esigenze, o l’estrazione incrementale (Incremental Update), che comporta solo l’estrazione dei dati che sono stati modificati o aggiunti rispetto all’ultima estrazione, oppure quella basata su eventi transazionali, cioè selezionando solo le tuple interessate da un certo tipo di transazioni.
• Trasformazione Una volta che i dati sono stati estratti e portati nella Staging Area si selezionano solo quelli che sono di interesse per il sistema, dopodiché possono essere implementati diversi tipi di trasformazione[KRR98] come:
– La normalizzazione dei dati eliminando i duplicati ed incongruenze – L’esecuzione di accoppiamenti (join) tra dati recuperati da differenti
tabelle
– La generazione di chiavi surrogate e/o naturali
– La creazione di indici o viste materializzate per rendere più efficiente il sistema rispetto alle query più utilizzate.
• Caricamento Infine i dati vengono caricati nel Data Warehouse, attraverso un processo che verrà automatizzato, definendo ad esempio dei programmi batch di caricamento o delle schedulazioni presenti nei tool di ETL.
Il Data Warehouse rappresenta quindi una sorgente di dati secondaria, popolata dai sistemi OLTP esistenti e da altre fonti dati esterne, che consistono, ad esempio in compagnia specializzate nella fornitura di dati di vario genere. Inoltre il processo di ETL effettua trasformazioni di dati riga per riga e questo può facilmente diventare un collo di bottiglia all’interno dell’intero processo di elaborazione dei dati. In più i dati devono essere spostati più volte (da sorgente a server ETL e da server ETL al target) con la conseguenza di avere minori prestazioni e costi più alti.
1.4.3
Il processo di E-LT
Il processo di E-LT è un’architettura di nuova generazione che esegue le stesse operazioni di un tradizionale processo di ETL a differenza che le trasformazioni dei dati non sono effettuate sul server dove è presente il tool di ELT.
Architettura E-LT di Nuova Generazione
Transform Transform
Extract Load
© Nunzio Spontella
Figura 1.4: Il processo di E-LT
1.4 Il Data Warehouse
estratti dalle sorgenti, caricati sul target ed è lì che poi avviene la fase di ela-borazione e trasformazione. Tutto questo si traduce in due notevoli vantaggi: prestazioni più elevate e minori costi.
In particolare in un processo di E-LT vi è un Focus su “Cosa” fare piuttosto che sul “Come” farlo (processo) infatti le elaborazioni potranno essere demandate su altri server e non necessariamente sulla staging area dove è presente il tool di ELT. Questo nuovo paradigma architetturale può essere molto utile nel caso di architetture cluster o nel caso di piattaforme Cloud cui demandare le operazioni di trasformazione ed elaborazione.
1.4.4
Architetture di un Data Warehouse
E’ possibile eseguire una classificazione delle architettura in base al numero dei livelli presentati, perciò, saranno presenti architetture ad uno, a due o a tre livelli.
L’architettura ad un livello
Questa architettura rappresenta l’approccio più semplice, caratterizzata dallo strato di middleware, uno strumento complesso che sostituisce gli strumenti ETL e gestisce l’interazione fra le sorgenti (ad esempio le basi di dati operazionali) e il Data Warehouse.
Il DWH quindi in questo caso è una sorta di database virtuale, ovvero costituito da viste che saranno costruite dallo strato d’elaborazione intermedio. Obiettivo di questa architettura è la minimizzazione dei dati memorizzati, ottenuta eliminando le ridondanze, implica però che transazioni analitiche e transazionali siano inoltrate sulla stessa base dati. Per eseguire l’elaborazione dei dati, dal punto di vista analitico, il middleware effettua interrogazioni sui dati operazionali. Sebbene possa essere una struttura accettabile nel caso in cui non si abbiano particolari esigenze d’analisi oggi è in disuso a causa delle prestazioni poco efficienti. Lo sviluppo di un sistema di Data Warehouse presenta alcune problematiche, tra cui vincoli di tipo tecnologico, difficili da superare quando la dimensione e la complessità del sistema divengono molto elevate.
L’architettura a due livelli
Una soluzione a questo problema è l’introduzione dei Data Mart, di cui si è parlato nel precedente paragrafo. Essi possono essere definiti come Data Warehouse relativi ad un soggetto specifico. Quest’ultima soluzione delinea un’architettura a due livelli dove il Data Warehouse svolge un ruolo superiore di contenitore centrale, mentre i Data Mart svolgono, ad un livello inferiore, la funzione di DWH locali in corrispondenza di determinate aree aziendali. In questo caso i Data Mart e il Data Warehouse rappresentano due livelli fisici separati e l’unione dei diversi Data Mart genera il Data Warehouse complessivo. I DM infatti possono essere utilizzati come veri e propri blocchi per una realizzazione incrementale del DWH facilitando notevolmente l’aspetto progettuale, inoltre essendo di dimensioni inferiori rispetto al DWH primario permettono di raggiungere prestazioni migliori. Questa struttura oltre ai vantaggi citati, offre una disponibilità continua d’informazione di prima qualità anche qualora, per motivi tecnici e organizzativi, sia temporaneamente precluso l’accesso alle sorgenti.
L’architettura a tre livelli
E’ una evoluzione di quella a due e si caratterizza per i già citati strumenti ETL e per un nuovo livello, il livello dei dati riconciliati (ODS – Operational Data Store), una sorta di magazzino di dati operazionali su cui è eseguita la reportistica operazionale e su cui, differentemente dal DWH, sono ammesse sia operazioni in lettura che in scrittura.
Il grande vantaggio di questa architettura è che la complessità dell’ETL è signi-ficatamente ridotta grazie a una separazione netta tra le problematiche legate all’estrazione e integrazione dei dati dalle sorgenti e quelle che riguardano l’alimen-tazione del DWH. Un altro punto di forza è la possibilità di eseguire la reportistica operativa su un livello di dati già puliti e integrati e non direttamente sui DB operazionali (con dati molto probabilmente sporchi e sbagliati). D’altro canto la presenza di un ulteriore livello dati crea la necessità di avere a disposizione grandi quantitativi di memoria, che oggi però presentano costi estremamente accessibili,
1.4 Il Data Warehouse
e l’introduzione di un’ulteriore ridondanza rispetto ai dati operazionali sorgente.
1.4.5
Architettura a silos vs architettura warehouse bus
In alcuni contesti i Data Mart sono alimentati direttamente dalle sorgenti. Questo approccio è detto a Data Mart indipendenti (o architettura a silos), che non dialogano fra loro e che costituiscono porzioni a sé stanti del Data Warehouse, sfavorendo l’integrazione dei diversi Data Mart. L’assenza di un DWH primario agevola notevolmente le fasi progettuali determinando però un complesso schema di accessi ai dati e un forte rischio di inconsistenza tra i DM, motivo per cui è sempre meno utilizzata. Generalmente è una struttura presente nelle aziende che non hanno affrontato la fase di progettazione in maniera organica, in cui quindi ogni area ha progettato il proprio Data Mart senza considerare le altre divisioni o funzioni. E’ovviamente una struttura destinata a crollare in cui la ridondanza dei dati porta all’inconsistenza del DWH.
I concetti cardine del business dovranno essere definiti in maniera condivisa da tutte le divisioni e saranno poi tali dimensioni conformi che permetteranno ai Data Mart di comunicare generando un’integrazione a livello logico.
E’ la conformità infatti ad assicurare che dati contenuti in diversi data mart, relativi a processi diversi, possano essere correlati e integrati nell’ambito dell’intero data warehouse e nel corso del tempo. In risposta a questa esigenza le porzioni logiche dei dati sono organizzate e rese conformi attraverso un’architettura denominata warehouse bus. Con questo approccio la visione globale del business non è progettata in partenza come un unico monolite ma prende forma in maniera incrementale man mano che i DM vengono progettati. In questi casi il DWH prende il nome di Enterprise Data Warehouse (EDW)
1.4.6
Progettazione di un Data Warehouse
Lo scopo di un data warehouse non è solo quello di archiviare i dati, ma piuttosto quello di facilitare la creazione di decisioni. Pertanto, il primo passo consiste nel progettare un data warehouse sulla base dei tipi rilevanti di analisi
di business. Inoltre un DWH deve essere progettato per fornire le informazioni necessarie per risolvere un problema aziendale. Se il problema è risolto, ci dovrebbe essere un guadagno economico per consentire un’analisi costi-benefici per il progetto di data warehousing. Come accade per i database, è diventato abbastanza comune dividere il processo di progettazione DW nelle seguenti quattro fasi:
1. Analisi dei requisiti: L’obiettivo è quello di produrre una descrizione dei processi aziendali, le attività tipiche di analisi delle informazioni con cui gli utenti sono coinvolti e le misure e le dimensioni di interesse. In genere, i requisiti in questa fase sono documentati in modo piuttosto informale 2. Progettazione concettuale: L’obiettivo è quello di produrre una
descri-zione formale dei dati da analizzare utilizzando un modello concettuale. Il Dimensional Fact Model (DFM) è il formalismo grafico usato per descrivere fatti, dimensioni, attributi e gerarchie. Il DFM è un concetto fon-damentale che è alle basi del Data Warehouse, per questo, sarà approfondito dettagliatamente nel prossimo capitolo
3. Progettazione logica: Lo scopo di questa fase è trasformare la progetta-zione concettuale in strutture logiche utilizzate per archiviare il DWH in un DBMS relazionale o in un Database multidimensionale
4. Progettazione fisica: L’obiettivo è definire le strutture dati necessarie per l’archiviazione delle tabelle del database create dalla progettazione logica. Il problema principale in questa fase è legato a quali indici e quali viste materializzate sono necessari per ottimizzare le prestazioni generali del sistema
1.4.7
Ottimizzazione di un Data Warehouse
In linea generale, i principi per massimizzare le performance di un dataware-house sono:
• Nel caso in cui debbano essere processati un gran numero di dati evitare l’aggregazione a run-time dei dati
1.4 Il Data Warehouse
• Le join per non inficiare sulle prestazioni devono coinvolgere il minor numero di tabelle possibile
• Le dimensioni fisiche delle tabelle non devono essere troppo elevate. [Micr94]
Pre-aggregazione dei dati
Solitamente, se è stata scelta una grana molto fine, i dati caricati nel DWH sono al minimo livello di dettaglio, perciò considerando la grossa mole di dati, con l’esecuzione di una query che richiede l’aggregazione si rischierebbe di incorrere in rallentamenti a run-time. Per evitare questa situazione, è possibile aggregare i fati in fase di caricamento. Il risultato sarà la creazione di varie fact table, dette Summary Table, contenenti dati a differenti livelli di aggregazione, la conseguenza negativa di questa strategia porta a un maggior utilizzo di spazio occupato, dovuto alla ridondanza dei dati e il tempo necessario per eseguire le pre-aggregazioni. Una soluzione ottimale consiste nel trovare un trade-off intelligente tra le performance della query, lo spazio occupato e il tempo di pre-aggregazione.
Indicizzazione e chiavi numeriche
Attraverso una corretta indicizzazione è possibile aumentare di gran lunga le prestazioni in lettura di una query. Ad esempio, per poter velocizzare le operazioni di join è consigliabile l’utilizzo di chiavi numeriche in quanto molto più prestanti rispetto alle chiavi testuali. Infatti in quest’ultima cosa durante le join verrà effettuato un controllo per ogni carattere alfabetico che hanno un range di valori di gran lunga maggiore rispetto ad un range numerico. Nel fare ciò bisogna stare attenti perché durante la fase di manutenzione degli indici creati è inevitabile non subire un rallentamento nel processo di aggiornamento dei dati.
Partizionamento
Con questa tecnica è possibile ridurre le dimensioni di alcune tabelle troppo grandi, suddividendole secondo diverse regole. Un esempio può essere quello di suddividere in 12 tabelle distinte i dati di vendita presi dalla tabella "Vendite
Mensili". Attraverso questo partizionamento si otterrebbero diversi vantaggi come un miglior tempo di risposta di una query; una accelerazione per le operazioni di backup e ricovery incrementale; la diminuzione del tempo per caricare i dati in tabelle indicizzate. Bisogna tener conto però anche dei problemi che sorgono a causa del partizionamento come l’aumento delle operazioni di join e union neces-sarie per accedere ai dati che provengono dalle divere sotto-tabelle e una maggiore difficoltà nella generazione delle query SQL sul set delle tabelle partizionate.
Capitolo 2
Il Modello Multidimensionale
In questo capitolo analizzeremo dettagliatamente i vari componenti del modello multidimensionale, descriveremo la tecnica di analisi multidimensionale e vedremo come sia possibile realizzare fisicamente il modello multidimensionale utilizzando due differenti tecnologie: il Database Relazionale e il Database Multidimensionale.
2.1
Il modello multidimensionale concettuale
Il concetto di multidimensionalità è di interesse centrale nel tema dei data warehouse. Le dimensione ha origine dalla metafora del cubo per la rappresentazio-ne dei dati multidimensionali, secondo questa metafora, gli eventi corrispondono a celle di un cubo i cui spigoli rappresentano le dimensioni di analisi. Un cubo quindi, avrà tante dimensioni quante sono le prospettive di analisi stabilite e ogni cella del cubo conterrà un valore per ciascuna misura. Ciascuna dimensione può essere vista a più livelli di dettaglio individuati da attributi strutturati in gerarchie.
Dunque, un cubo multidimensionale è incentrato su un fatto di interesse per il processo decisionale. La modellazione multidimensionale è la tecnica di proget-tazione logica più utilizzata per un sistema di supporto alle decisioni. Infatti, attraverso questa metodologia è possibile definire lo scopo del Data Warehouse o del Data Mart, ovvero decidere quali aree del business devono essere rappresentate e quali entità, invece, devono essere escluse [Mic96].
Come accennato nel precedente capitolo, per rappresentare a livello concettuale la struttura di un data warehouse con un formalismo grafico si usa il Dimensional Fact Model (DFM), appositamente concepito per supportare la fase di model-lazione concettuale in un progetto di Data Warehouse. Il DFM è estremamente intuitivo e può essere utilizzato anche da analisti e utenti non tecnici. É molto utile per realizzare una rappresentazione chiara ed esaustiva di concetti multidi-mensionali Può essere utilizzato dalle fasi iniziali del ciclo di vita DW, per ideare rapidamente un modello concettuale da condividere con i clienti.[GR09]
I processi decisionali aziendali riguardano fatti (es: vendite, acquisti, spedizioni) e di ognuno interessano in particolare i valori di alcune misure come il prezzo, quantità, percentuale di sconto etc. Queste misure possono essere interpretate soltanto se messe in relazione ad alcune dimensioni come il venditore, il prodotto venduto, la data, il luogo di vendita.
2.1.1
Attributi e dimensioni
Le dimensioni indicano la prospettiva con cui analizzare i business data. Attraverso le dimensioni, sarà quindi possibile visualizzare e studiare gli stessi tipi di dati ma con punti di vista differenti.[Mic96]
In generale una dimensione è caratterizzata da un insieme di attributi dimensio-nali raggruppati logicamente. Ad esempio, attributi interessanti per la dimensione Data potrebbero essere Giorno, Mese e Anno, mentre per la dimensione Negozio potrebbero essere Città, Provincia e Regione. Le dimensioni con attributi si rappresentano come mostrato in Figura 2.1 1, con l’accorgimento di non usare nomi uguali per attributi di dimensioni diverse. Una dimensione priva di attributi è detta degenere.
Sempre in riferimento al termine dimensione, ci si riferirà al fatto che organiz-zando i dati in base a differenti prospettive, questi potranno essere rappresentati mediante un cubo avente tante dimensioni quanto sono le prospettive d’analisi stabilite. Nello specifico, consideriamo un cubo organizzato lungo tre dimensioni:
1Tutte le figure inerenti il DFM sono prese dal libro Decision Support Databases Essentials
2.1 Il modello multidimensionale concettuale
Figura 2.1: Schema concettuale dei fatti con dimensioni e attributi dimensionali • Dimensione Prodotto
• Dimensione Luogo • Dimensione Tempo
Figura 2.2: Il cubo multidimensionale
In questo caso quindi avremo che ogni cella del cubo rappresenterà la quantità venduta di un determinato prodotto, in un determinato luogo, in una determinata data. Una dimensione quindi non è altro che una serie di valori unici, i quali sono la base per l’organizzazione dei dati analitici. I valori contenuti all’interno di una
dimensione sono chiamati elementi della dimensione, questi elementi fungono da coordinate per identificare le singole celle del cubo dei dati.
2.1.2
Relazioni
Nel modello multidimensionale, le relazioni vengono rappresentate mediante linee aventi come estremo una forbice con senso rivolto verso l’attributo che partecipa alla relazione con cardinalità multipla. Le relazioni possibili sono:
• Relazione uno a uno: corrisponde ad un elemento padre con un elemento figlio
• Relazione uno a molti: un elemento padre può corrispondere ad uno o più elemento figli
• Relazione molti a molti: un elemento figlio può avere uno o più genitori, e viceversa
2.1.3
Gerarchie
In presenza di attributi dimensionali, un aspetto interessante per modellare i dati ai fini analitici, sono le relazioni gerarchiche che intercorrono fra i propri attributi. Avremo quindi una relazione Uno-a-Molti tra coppie di attributi dimensionali. Utilizzando un esempio pratico, se consideriamo la dimensione Tempo, avremo che l’attribuo Mese sarà in gerarchia con Giorno, Trimestre, e Anno. L’attributo Anno sarà composta da più Trimestri che a loro volta saranno composti da più Mesi, e così via. Viceversa un Mese corrisponderà a un solo Trimestre ed esso apparterà ad un solo Anno.
Ogni arco della gerarchia modellerà una dipendenza funzionale tra due attributi. Ci possono essere dei casi particolari, come ad esempio la granularità Settimana, la quale solitamente può trovarsi tra due mesi e quindi non farà parte della gerarchia dove è presente il Mese.
2.1 Il modello multidimensionale concettuale
• Bilanciate (balanced ): quando si ha un numero predefinito di livelli e gli attributi sono tutti definiti. Ad esempio la gerarchia Month > Quarter > Year è bilanciata.
• Irregolari (ragged ): quando abbiamo che i valori di uno o più attributi possono essere indefiniti. Ad esempio una dimensione geografica con attributi Country, State e City sarà bilanciata per gli USA, mentre in Italia sarà
irregolare non esistendo il concetto di Stato Federale.
• Ricorsive (recursive): sarà nel caso in cui i livelli della gerarchia saranno variabili. Ad esempio, una dimensione Agent ci farà avere un agente di commercio, il quale potrà essere supervisor di altri agenti, ma lui stesso avrà un supervisor.
Figura 2.3: Schema concettuale dei fatti con attributi dimensionali e gerarchie
2.1.4
Fatti e misure
I fatti altro non sono che i dati reali di business, tipicamente rappresentano la performance o i fattori chiave di un business. Ogni singolo fatto può essere organizzato lungo una o più dimensioni. Inoltre un fatto è caratterizzato da un insieme di misure che sono attributi numerici inerenti il comportamento di un fenomeno aziendale e descrivono un aspetto quantitativo di interesse per l’analisi.
Esempi di misure, nel caso di fatti sulle vendite sono il prezzo del prodotto, la quantità venduta, il ricavo, etc.
Quando si modella un Data Mart la prima decisione fondamentale da prendere riguarda il significato del fatto, perché da questa scelta scaturiscono le misure che lo caratterizzano e le dimensioni di analisi. Questo problema è uno dei classici nella progettazione di Data Mart: Bisogna scegliere la giusta grana del fatto, poiché indica la precisione con cui le misurazioni sono prese. La granularità solitamente è al più basso livello possibile altrimenti si perdono informazioni. Come regola generale, è bene scegliere una grana fine, anche se aumenta il numero dei fatti da trattare.
A livello concettuale i fatti si modellano con un rettangolo diviso in due parti, che contengono il nome del fatto e l’elenco delle misure interessanti che ne descrivono aspetti quantitativi rilevanti per l’analisi. Le misure possono mancare quando interessa solo rappresentare il verificarsi dei fatti e nelle analisi contarli, oppure essere calcolate, cioè derivabili da altre misure. Le dimensioni si modellano con degli archi uscenti dal rettangolo che terminano con un cerchio, etichettato con il nome della dimensione.
Figura 2.4: Schema concettuale dei fatti
2.1.5
Indicatori chiave di prestazione - KPI
I dirigenti sono interessati ad analizzare i fatti per valutare l’andamento delle prestazioni aziendali sulla base di una serie di indicatori (indici, metriche) variabili quantitative calcolate con aggregazioni delle misure, che rappresentano
2.2 Operazioni del modello Multidimensionale
meglio la strategia e che possono dunque essere interpretati come critici per il successo attuale e futuro dell’impresa: valori soddisfacenti di tali indicatori indicano che la strategia è adeguatamente implementata. Per esempio, interessano gli scostamenti percentuali dagli obiettivi del totale delle vendite per trimestre e per prodotto.
In generale, per valutare le prestazioni aziendali non si usano solo indicatori di tipo economico-finanziario, ma anche di altro tipo (efficienza, qualità, servizio) detti indicatori chiave di prestazione (Key Performance Indicators, KPI) che rispondano al cosidetto requisito SMART (Specific, Measurable, Attainable, Relevant, Time bound).
2.2
Operazioni del modello Multidimensionale
Per la navigazione del cubo multidimensionale vi sono differenti operazioni OLAP che permettono di organizzare i dati di un cubo con diverse prospettive di analisi, ovvero con molte dimensioni. Le principali operazioni possono essere:• Slice e Dice: Permettono di selezionare e mostrare i dati del cubo. In particolare Slice se si estraggono sotto-cubi filtrando su una sola dimensione, Dice se il filtro è fatto su due o più dimensioni.
• Roll-up e Drill-Down: Queste due operazioni consentono di muoversi all’interno di una gerarchia, scegliendo il livello di aggregazione secondo il quale l’utente desidera visualizzare i dati. Nello specifico con l’operazione Roll-Upsi salirà verso un livello di dettaglio inferiore, visualizzando dati maggiormente aggregati (ad esempio da vendite settimanale a mensili) viceversa, con l’operazione di Drill-Down si otterranno dati maggiormente dettagliati (da raggruppamenti per Regioni ad una più specifica Provincia). • Pivoting: (detto anche rotate) consente di ottenere rappresentazioni al-ternative modificando rapidamente la vista dei dati, ruotando gli assi del cubo.
Figura 2.5: Esempi di operazioni tipiche su un modello multidimensionale
2.3
Database relazionale vs Multidimensionale
La filosofia su cui si basa il modello multidimensionale è quella di realizzare una corrispondenza biunivoca tra come le persone vedono i dati del loro business e come questi dati vengono memorizzati in un sistema informativo. Possiamo definire un database multidimensionale (MDB) come Un sistema software progettato espressamente per rendere la memorizzazione e il recupero di una grande mole di dati conveniente ed efficace.[Ken95] Attraverso questa tecnologia, la progettazione logica del database è praticamente inesistente, in quanto esiste una relazione uno-a-uno tra il modello multidimensionale e il disegno del database. Infatti, questo sistema software permette di definire gli stessi oggetti del modello multidimensionale: dimensioni, attributi, relazioni, gerarchie e fatti. La struttura fondamentale di memorizzazione di un database multidimensionale è l’ array. Vi sono diversi motivi per cui è stato scelto di implementare sistemi software di questo tipo. Infatti, se confrontiamo l’array con le tabelle relazionali, che rappresentano il metodo di memorizzazione della tecnologia concorrente, possiamo notare immediatamente alcune differenze.
2.3 Database relazionale vs Multidimensionale
In un database relazionale i dati vengono rappresentati sotto forma di tabelle che si collegano fra loro attraverso le chiavi. Le informazioni contenute in ogni tabella sono organizzate in records che corrispondono alle righe della tabella. Ogni record a sua volta è suddiviso in campi ovvero le colonne della tabella stessa. Un esempio di tabella relazionale è mostrato in figura 2.6.
Figura 2.6: Esempio di tabella relazionale
Si noti come la tabella contiene nove record, ciascuno dei quali è composto da tre campi : Smartphone, Drone e Tablet. Per rappresentare le stesse informazioni in un database multidimensionale si utilizzerà l’array bidimensionale visibile in figura 2.7. Come è possibile osservare dalla figura in alto, ci sono esattamente due
Figura 2.7: Esempio di array bidimensionale
dimensione formate da tre elementi ciascuna, questo è molto più difficile da notare su una tabella in un database relazionale, soprattutto al crescere delle dimensioni e/o degli elementi.
in righe e colonne, così da poterle maneggiare efficientemente. Consideriamo ad esempio un cubo di 3 dimensioni contenenti ciascuna 10 elementi. L’equivalente tabella relazionale conterrà 10x10x10= 1000 records. Se un utente vuole conoscere il valore di una determinata cella, il sistema relazionale dovrà scandire, nel caso peggiore, tutti i 1000 records, mentre il sistema multidimensionale cercherà soltanto lungo le 3 dimensioni per localizzare il dato. Tutto ciò si traduce nella scansione di un massimo di 30 elementi nel caso peggiore.
Tra i vantaggi di un database multidimensionale annoveriamo:
• Velocità con cui gli utenti possono eseguire un rapido cambio di prospettiva • Interattività con cui si possono aggiungere o rimuovere attributi.
L’inte-razione è altamente responsive e tramite le operazioni di OLAP, viste nel paragrafo precedente, fornisce immediati feedback
• Alto livello di organizzazione dei dati che permette una visualizzazione ed una manipolazione molto più logica per l’utente finale
• Supporto specializzato per le tabelle ricorsive
Il MDB presenta anche diversi limiti che talvolta portano a preferire un database relazionale. I limiti principali sono:
• La velocità con cui viene fatto il cambio di prospettiva ha un costo. Infatti, con l’aumentare delle dimensioni e i valori, il numero di computazioni che può essere precomputato diventa difficile da gestire e le misure per far fronte a questa limitazione fanno ridurre i benefici offerti dal cubo
• Con l’aumentare delle dimensioni e i valori il numero di computazioni che può essere precomputato diviene difficile da gestire e le misure per far fronte a questa limitazione fanno ridurre i benefici offerti dal cubo
• La sparsità è un grosso problema nel MDB in quanto la memorizzazione di un array sparso comporta un grande spreco di spazio dovuto alle molte celle vuote e una notevole riduzione delle performance
2.3 Database relazionale vs Multidimensionale
• I dati in un MDB sono accessibili tramite interfacce che sono spesso pro-prietarie. Di conseguenza l’abilità di scrivere query in questi ambienti è una skill non molto diffusa (ne è un esempio il linguaggio MDX 2)
2.3.1
Il database relazionale come supporto al modello
mul-tidimensionale
Nel paragrafo precedente si è visto come l’utilizzo di un database multidimen-sionale non comporta la necessità di definire un progetto logico della base di dati proprio perché sussiste una corrispondenza biunivoca col modello multidimensio-nale.
La situazione cambia drasticamente se si sceglie un sistema relazionale come sup-porto di memorizzazione. Infatti, in questo caso occorrerà utilizzare una tecnica di progettazione logica espressamente pensata per rappresentare nel miglior modo possibile strutture dati multidimensionali. Il risultato sarà uno schema relazionale composto da differenti tipi di tabelle che rappresentano gli oggetti caratteristici del modello multidimensionale.
Esistono differenti tipologie di tabelle che corrispondono ai vari oggetti del modello multidimensionale [Mic96]:
• Lookup Tables permettono di rappresentare gli attributi In queste tabelle è presente la chiave o l’identificatore di un elemento e la descrizione
• Fact Tables contengono i fatti del business e le chiavi esterne degli attributi che determinano la loro dimensionalità
• Bridge Tables queste tabelle sono necessarie nel caso di relazioni molti-a-molti, contengono le chiavi di due o più attributi in modo da rappresentare le relazioni esistenti tra questi
2MDX (MultiDimensional eXpressions) è un linguaggio usato nelle interrogazioni di tipo
OLAP per scorrere dimensionalmente il Cubo OLAP del Data Mart in un Data Warehouse. Sintatticamente somiglia al linguaggio SQL, ma ha una semantica diversa. In alcuni aspetti risulta essere verboso e ridondante, tuttavia è possibile omettere nelle espressioni regolari alcune parti significative.
Il processo di costruzione di queste tabelle parte dal modello multidimensionale e consente di realizzare uno schema normalizzato. Si comincia definendo delle lookup tables per ogni attributo del modello multidimensionale. Successivamente vengono stabiliti i campi di queste tabelle che generalmente consistono in una chiave e in una descrizione (opzionale).
Il passo successivo consiste nella costruzione delle Bridge Table, queste tabelle contengono al loro interno le combinazioni valide delle chiavi degli attributi che partecipano alla relazione. L’uso di queste tabelle è indispensabile nel caso di relazioni molti-a-molti, invece le relazioni uno-a-molti possono essere rappresentate direttamente all’interno della lookup table figlia, aggiungendo un campo contenente la chiave dell’attributo padre (foreign key). Questa tecnica permette anche di migliorare sensibilmente le performance riducendo il numero di join.
L’ultimo step consiste nella definizione di una fact table per ogni set di fatti aventi la stessa dimensionalità. La fact table avrà tante chiavi quante sono le dimensioni e tanti campi quanti sono i fatti associati a queste dimensioni. Il risultato di questo procedimento è uno schema normalizzato che rappresenta il modello multidimensionale di partenza. Questo schema sarà quindi costituito da una o più lookup tables per ogni dimensione, contenenti le informazioni relative ai vari attributi e da una o più fact tables.
2.3.2
Star schema
Lo schema a stella (star schema) è molto comune nelle applicazioni OLAP ed è costituito da una tabella centrale dei fatti, che contiene i dati relativi ai fatti da analizzare e una serie di tabelle delle dimensioni (una per ogni dimensione). Ciascuna delle tabelle delle dimensioni ha una chiave primaria a singolo attributo che ha una relazione uno-a-molti con una chiave esterna nella tabella dei fatti. La caratteristica di questo schema è di essere fortemente denormalizzato e di presentare, quindi, una grande ridondanza dei dati.
2.3 Database relazionale vs Multidimensionale
Figura 2.8: Esempio di star schema schema
2.3.3
Snowflake schema
Uno schema a snowflakes (fiocco di neve) è una variante dello schema a stella. La caratteristica principale di questo schema è quella di possedere una minore ridondanza dei dati e di conseguenza una maggior normalizzazione, ottenuta tramite una ulteriore suddivisione dei dati delle tabelle dimensionali in tabelle aggiuntive. Lo svantaggio di questa tecnica è che aumentando il numero di tabelle, per reperire un’informazione, aumenteranno anche il numero di join tra queste tabelle.
Il progetto di tesi
In questo capitolo dopo una breve introduzione sull’azienda che mi ha ospitato durante il periodo di tirocinio, fornirò una panoramica generale degli obiettivi del progetto, vedremo in dettaglio la metodologia progettuale, lo stack tecnologico utilizzato e una descrizione dei tools adottati. Successivamente si spiegherà quali data mart erano già presenti nel Data Warehouse e quali erano le loro criticità. E’ infine fornita una panoramica generale su come è stato sviluppato il progetto.
3.1
L’azienda ospitante: Iconsulting
Questa tesi è legata al progetto svolto durante il periodo in cui sono stato impegnato come stagista presso la società di consulenza iConsulting. Quest’azienda è specializzata in Data Warehousing (DW), Business Intelligence (BI), Location Intelligence (LI),Performance Managment (PM) e Big Data Analytics (BDA). L’azienda è nata come uno spin-off del laboratorio di Data Warehouse e Business Intelligence all’interno del CINECA (Consorzio di ricerca italiano, senza scopo di lucro), con la missione di fornire progetti e soluzioni di BI e PM definibili best in class. Grazie all’esperienza acquisita in oltre 300 progetti di successo, iConsulting supporta una moltitudine di aziende in progetti innovativi e di successo. Il know-how raccolto nel tempo permette di sviluppare prodotti e soluzioni ad hoc per ogni cliente, accelerando il tempo di implementazione.
3.2 Obiettivi di progetto
3.2
Obiettivi di progetto
Il mondo accademico è formato da un insieme di strutture e ambiti che hanno compiti, per loro natura, di tipo locale. Questo ha portato ad un isolamento dei vari organismi causando l’impossibilità di avere una visione globale che permetta una maggiore comprensione dei dati a disposizione dell’intero Ateneo; al fine di congiungere le informazioni frammentate secondo uno standard comune ed una visione unitaria, l’Università si è posta l’obiettivo di superare la conformazione a “silos” (di cui si è parlato nel capitolo 1) fornendo alle diverse aree uno strumento integrato a supporto delle decisioni anche grazie all’introduzione delle dimensioni conformi.
Nello specifico, l’obiettivo di questa tesi è quello di estendere gli ambiti gestiti nel Data Warehouse di Ateneo garantendo una copertura più ampia delle esigenze analitiche dell’Università al fine di consentire lo svolgimento di analisi nell’ambito della Ricerca e della Terza Missione e in particolare dei tirocini curriculari e for-mativi. Tale decisione permetterà di valorizzare il patrimonio informativo con una maggiore semplificazione e velocità nell’accesso delle diverse aree alle informazioni. Inoltre il cliente ha lamentato una perdita infinita di tempo per analizzare i dati sparpagliati tra le diverse sorgenti per questo sono stati standardizzati i processi di controllo, gestione e documentazione del processo informativo, mettendo a disposizione un’unica versione della verità.
Questo progetto è nato da diverse esigenze di analisi dell’ufficio Tirocini come la realizzazione di report inerenti il numero di tirocini attivati, l’analisi dei questio-nari di valutazione lato studente ed ente ospitante e un’analisi qualitativa ex post dei tirocini. Il monitoraggio dei processi di tirocinio, delle offerte formative, delle convenzioni Università-Aziende esterne e lo studio dei risultati dei questionari di valutazione degli studenti consentirà alla governance di Ateneo di prendere le decisioni strategicamente più rilevanti.
Figura 3.1: Be-Lean methodology
3.3
Approccio metodologico
Per lo sviluppo del progetto è stata adottata la metodologia progettuale ICONSULTING BE-LEAN che integra competenze tecnico-strategiche, piani di formazione degli utenti e supporto post implementazione fornendo una robusta strategia di implementazione di soluzioni di Data Warehouse. Questo modello segue una metodologia che si basa sull’opportunità di valutare l’andamento di un progetto durante il suo ciclo di vita, attraverso regolari release (o iterazioni). Ogni iterazione è focalizzata al raggiungimento di alcune milestone e nella produzione dei deliverable opportuni, nell’ottica di un progresso globale del sistema orientato al completamento della soluzione attraverso un processo controllato e disciplinato. Per questi motivi questa metodologia si può identificare come un approccio incrementale e iterativo (Figura 3.1) in cui ogni aspetto dello sviluppo, requisito, design, etc. viene continuamente rivisto per tutto il ciclo di vita. Il ciclo si comporrà delle seguenti fasi:
• Analisi: fase di analisi dei requisiti e delle funzionalità del sistema o della componente da sviluppare
• Progettazione: viene progettata la funzionalità precedentemente definita in fase di analisi, valutandone la complessità e gli impatti sull’intero sistema
3.4 Stack tecnologico
• Codifica: viene generato il codice che implementa le funzionalità, concordate in fase di analisi e progettate in fase progettuale
• Testing: si effettuano i test per valutare l’efficacia del sistema e per assicurarsi che l’informazione fornita sia consistente a quella desiderata • Rilascio: viene rilasciata la funzionalità all’utente, coinvolgendolo nel
pro-cesso di controllo ed utilizzo della stessa per cercare di individuare eventuali bug o inconsistenze, e risolvere prima possibile.
Elemento chiave caratterizzante la metodologia ICONSULTING è la sua natura incrementale e iterativa. Questo approccio è focalizzato a consentire al cliente di raggiungere tali obiettivi, massimizzando i fattori di successo e minimizzando i tempi necessari per creare valore. I vantaggi offerti da questa metodologia sono: • Centralità delle Persone e Interazioni: focus su obiettivi d’immediata riconoscibilità attraverso un processo d’analisi condiviso con l’utente finale lasciando comunque ampio spazio in tutte le fasi del progetto ad incontri con tutti gli attori vis-a-vis coinvolti nel progetto: Le persone e le interazioni sono infatti più importanti dei processi e degli strumenti ossia le relazioni e la comunicazione tra gli attori di un progetto sono la miglior risorsa del progetto stesso
• Approccio Adattativo: metodologia che facilita la risposta al cambiamen-to. Implementazione rapida basata su un approccio iterativo di realizzazione, sviluppo incrementale e rilascio di nuove release ad intervalli frequenti • Focus sul Valore: la metodologia impone di dare priorità in ogni momento
al rilascio, relativamente alle esigenze dell’utente finale, del maggior valore possibile
3.4
Stack tecnologico
Al fine di comprendere meglio la fase di sviluppo logico che sarà vista nel prossimo capitolo, questa paragrafo fornisce una spiegazione dettagliata dello stack
tecnologico comprendente tutti gli strumenti utilizzati durante il mio periodo di tirocinio.
3.4.1
Indyco
Indyco è un tool di progettazione concettuale sviluppato internamente da iConsulting che implementa una cultura ingegneristica che è ancora piuttosto nuova per molte aziende. Indyco è uno strumento C.A.S.E (Computer-Aided Software Engineering) che dà la possibilità di automatizzare compiti prima svolti manualmente e di controllarne con più precisione lo sviluppo. Questo porta a incremento della qualità dei progetti grazie a un’interfaccia grafica efficace. Il grande vantaggio legato all’utilizzo di Indyco è la possibilià di generare in automatico un nuovo DWH o di evolvere l’attuale (come nel caso di questo progetto), seguendo le regole validate da un modello ampiamente diffuso: il Dimensional Fact Model.
Lo strumento, inoltre, comprende diverse feature di Design e Data Governance che permettono di modellare il Data Warehouse, rispettando precise regole di progettazione. L’utilizzo di questo modello offre notevoli vantaggi infatti:
• Supporta efficacemente il progetto concettuale
• Permette di raffinare le specifiche dei requisiti attraverso un dialogo "visivo" tra chi progetta il DWH e gli utenti finali
• Produce un ambiente su cui formulare le interrogazioni dell’utente • Crea una piattaforma stabile da cui partire per la progettazione logica • E’ in grado di restituire in modo automatico una documentazione a posteriori
espressiva e non ambigua.
Indyco prevede una componente Explorer e una componente Builder, che saranno brevemente illustrate di seguito:
• Indyco Explorer consente di visualizzare il modello dei dati e di navigare all’interno di esso, mettendo in evidenza i collegamenti esistenti e
permet-3.4 Stack tecnologico
tendo di chiarire il significato dei dati stessi grazie all’accesso a un glossario dei dati, che ha il compito di apportare un valore aggiunto al modello, diffondendo la conoscenza riguardo molteplici elementi caratteristici del bu-siness, anche attraverso la possibilità di ricercare direttamente un significato, evidenziando rapidamente l’informazione di interesse.
• Indyco Builder è la parte dello strumento che permette di realizzare concretamente la modellazione concettuale, descrivendo graficamente e in-tuitivamente il business, seguendo le regole imposte dal formalismo del DFM. Una delle funzionalità risultate più utili ai fini del progetto è quella che permette l’operazione di reverse engineering di un Data Warehouse già esistente, a prescindere dal fatto che esso sia enterprise o scomposto in Data Mart.
Lo strumento, inoltre, valida autonomamente gli schemi disegnati, mettendo in evidenza eventuali criticità. Il modello concettuale, derivante dal con-tributo di informazioni eterogenee, può poi essere arricchito, traducendo il contenuto degli schemi in un vero e proprio business glossary completo e facilmente comprensibile, dove l’utente può reperire le informazioni che cerca. Inoltre, il Builder dà la possibilità di monitorare alcune metriche di perfor-mance del progetto, evidenziando il suo avanzamento, la sua completezza, la sua complessità e fornendo statistiche interessanti per identificare, oltre che i punti di forza, anche alcuni punti di debolezza su cui pianificare eventuali interventi migliorativi. L’ambiente di lavoro di Indyco Builder consente di fornire una visione globale del Data Warehouse, navigabile seguendo la sua disarticolazione in Data Mart. Esplorando i singoli Data Mart, poi, la visua-lizzazione si estende ai singoli elementi caratteristici di ogni area di business: i fatti e le gerarchie conformi. I fatti sono i fenomeni di analisi descritti secondo la definizione propria del DFM, mentre le gerarchie conformi sono degli alberi di attributi, ricorrenti nella definizione degli schemi, che vengono resi conformi proprio perché costituiscono elementi fondanti del business o del singolo Data Mart. Tali gerarchie, all’interno di Indyco, possono quindi
essere create una volta sola e poi essere riutilizzate semplicemente attraverso un drag and drop. Le connessioni che sussistono tra le diverse gerarchie e i singoli fatti rappresentati sono messe bene in risalto attraverso la consulta-zione della Bus Matrix, che fornisce in output informazioni fondamentali per comprendere da quali fatti viene analizzata ogni dimensione. Altro output interessante è costituito dalla Additivity Matrix, la quale, a seguito della corretta definizione delle misure, fornisce una visione globale di come le misure vengono aggregate per ogni fatto e su ogni dimensione. Tali output concorrono, dunque, alla produzione di una documentazione di progetto che Indyco è in grado di produrre automaticamente, al fine di illustrare in maniera esaustiva la struttura e il significato dei modelli realizzati.
3.4.2
Oracle
Oracle Database è uno tra i più famosi database management system (DBMS), ed ha costituito il physical layer di questo progetto, i tool ORACLE utilizzati sono stati due e di seguito è fornita una descrizione dettagliata di entrambi.
Oracle SQL Developer
SQL Developer è il tool grafico gratuito che gestisce le basi di dati di tipo relazionale e migliora la produttività, semplificando le attività di sviluppo del database. Con SQL Developer, è possibile sfogliare oggetti di database, eseguire istruzioni SQL, modificare ed eseguire il debug di istruzioni PL/SQL, manipolare ed esportare dati e visualizzare e creare report. Un utente di Oracle ha un nome utente e una password, e possiede tabelle, viste e tutte le risorse da lui create. Ogni utente può anche avere un ruolo che consiste in una serie di privilegi (Grant), esistono anche privilegi di sistema del DB, che consentono di eseguire particolari serie di comandi e privilegi di oggetti del DB. Una pecularietà di SQL Developer sono senz’altro la generazione delle statistiche, utilizzate dall’ottimizzatore per stimare quanta memoria è necessaria per eseguire un’istruzione SQL utilizzando un particolare piano di esecuzione. Un esempio di statistiche sono il numero di
3.4 Stack tecnologico
righe delle tabelle, numero di valori distinti (NDV) nella colonna, numero di NULL nella colonna, la distribuzione dei dati o statistiche degli indici.
Oracle Data Integrator - ODI
ODI è una piattaforma di integrazione dei dati basata su un’architettura di nuova generazione che utilizza il paradigma Extract Load and Transform (EL-T)per l’estrazione, il caricamento e la conseguente trasformazione dei dati aziendali, migliorando drasticamente le prestazioni e riducendo i costi di integrazione anche in presenza di sorgenti e target eterogenei.
L’utilizzo di questo strumento è stato il core fondamentale per la fase di sviluppo logico che vedremo nel prossimo capitolo, per questo verrà fornita una panoramica generale di come questo strumento gestisce il processo di ELT. ODI è diviso in tre grandi aree:
1. Topology: per definire l’ infrastruttura IT completa del sistema informativo. Include tutto, dai server agli schemi di dati.
2. Designer: è lo strumento che permette di implementare graficamente il caricamento dati e degli oggetti che provengono dal db (Tabelle, dati viste, sinonimi etc.) attraverso l’operazione di reverse engineering. Dopo aver importato gli oggetti dal nostro database, questi prenderanno il nome di modelli. I modelli importati rappresentano la struttura contenente tutti i metadati degli oggetti come nome dei campi e il tipo di dati.
Per poter effettuare operazioni di elaborazione e trasformazione di un mo-dello (ad esempio una tabella), sarà necessario creare un’ interfaccia questa infatti permette di mappare i dati che provengono da una tabella sorgente verso una tabella target. Con le interfacce è anche possibile applicare filtri che rappresentano la clausula WHERE del linguaggio SQL, eseguire operazioni di join tra più tabelle sorgenti, effettuare controlli di chiave ma anche stabi-lire le modalità di caricamento dei dati, ad esempio se in Full Refresh o in Incremental Update.
per-mettono di raggruppare più interfacce e procedure che svolgono determinate attività ma anche procedure scritte in PL/SQL o altri pacchetti. Ad esempio, grazie ai pacchetti è possibile schedulare ed eseguire il flusso contenente tutte le logiche che porta alla costruzione di una fact table ogni settimana piuttosto che ogni giorno.
3. Operator: permette di avere una visione di tutti i flussi ordinati cronolo-gicamente per data, mostrando tutti quelli eseguiti, terminati in errore o ancora in esecuzione.
3.5
Descrizione del progetto
3.5.1
As-Is
L’Università è a tutti gli effetti un’organizzazione complessa, in cui il processo decisionale si basa sulle valutazioni delle elaborazioni dei dati di business; dal punto di vista della gestione dei dati e delle relative necessità, l’Università non differisce da una qualsiasi altra azienda. Dirigenti e docenti, in qualità di responsabili di unità organizzative, sono chiamati a prendere decisioni strategiche rilevanti per le attività istituzionali.
Il Data Warehouse (As-Is) si presentava con 4 Data Mart quali: Didattica e Studente , Personale, Finanziaria, Programmazione Didattica.
La fase di analisi dell’esistente e di ricognizione dei dati ha costituito la base di partenza per conseguire una conoscenza soddisfacente dell’ambiente di intervento e del dominio applicativo dei dati da manipolare. Il primo passo è stato lo studio della documentazione disponibile, che è però risultata essere datata e quindi non del tutto soddisfacente ai fini del lavoro. Essa, dunque, è servita come traccia per definire alcune linee di intervento riguardo porzioni di dati rimaste invariate nel tempo e, di conseguenza, per comprendere meglio il loro significato. Tale attività è stata affiancata da una analisi approfondita della struttura dati presente attualmente.
