EII: INTEGRAZIONE TRA DATI GEOREFERENZIATI E DI BUSINESS INTELLIGENCE PER LA PIATTAFORMA SPAGOBI

Transcript

1 Università degli Studi di Padova Facoltà di scienze matematiche, fisiche e naturali Tesi di Laurea Specialistica in Informatica EII: INTEGRAZIONE TRA DATI GEOREFERENZIATI E DI BUSINESS INTELLIGENCE PER LA PIATTAFORMA SPAGOBI Relatori: Ch.ma Prof.ssa Susi Dulli, Prof. Stefano Nativi Correlatore: Dott. Antonio Majori Laureando: Nicodemo Valerio Anno accademico 2006/2007

2 2 Sommario Oggigiorno le aziende che si distinguono per dimensioni e notevole volume d affari dispongono di vari strumenti di tipo informatico che permettono di migliorare l efficienza della gestione operativa e commerciale, in quanto permettono di realizzare applicazioni ad alto livello le cui funzionalità possono essere utilizzate dal personale che si occupa dell ambito analitico e dirigenziale. Due di questi elementi sono individuabili nei sistemi per la gestione delle informazioni geografiche e nel data warehouse, un enorme contenitore di dati, sul quale è possibile effettuare analisi di tipo statistico utile a fini gestionali. Spesso i dati contenuti in quest ultimo potrebbero essere georeferenziati, correlandoli a quelli presenti nei database spaziali, in modo tale da poter realizzare mappe territoriali integrate con dati di tipo statistico. Tale operazione non è spesso possibile a causa di un problema ricorrente in ambito informatico: la mancanza di interoperabilità tra le applicazioni che gestiscono le due differenti tipologie di dati, in quanto gestite da software di produttori diversi. Il lavoro effettuato in questa tesi ha avuto l obiettivo di analizzare tale problematica, in modo da individuare un metamodello di tipo generico che permetta di ovviare a tale inconveniente, valutando gli strumenti adatti a realizzare l integrazione dei dati e dimostrandone la fattibilità attraverso la realizzazione di un prototipo.

3 Indice Sommario Introduzione 4 1 Il problema dell integrazione L origine del problema Enterprise Resource Planning Enterprise Application Integration Enterprise Information Integration Le tecnologie coinvolte Data warehouse Formato di memorizzazione dei dati Costruzione e tipi di architettura Operazioni effettuabili Geographic Information System Evoluzione storica Situazione attuale e prospettive future L azienda promotrice del caso di studio Engineering Ingegneria Informatica SpagoBI L approccio di tipo open source

4 4 INDICE 4 Fase di analisi Analisi dei database spaziali Gli standard dell OGC PostGIS Oracle Spatial MySQL Spatial Extension ArcSDE e MapInfo Altri database spaziali Fase di progettazione Approccio progettuale Soluzione per il recupero dei dati spaziali Web Feature Service Geographic Markup Language Implementazione di un WFS Recupero dei dati di business intelligence extensible Markup Language Integrazione e visualizzazione dei dati Scalable Vector Graphics Realizzazione di un prototipo Il prototipo Strumenti utilizzati PHP Descrizione dell applicazione Conclusioni 91 A Installazione del database PostGIS 95 Bibliografia 102

5 Introduzione Al giorno d oggi si può affermare che la totalità delle aziende commerciali, industriali, della pubblica amministrazione, soprattutto quelle di grosse dimensioni, dispongono al loro interno da più di un decennio di un sistema informatico, utilizzato a fini operativi e gestionali. Nel corso degli anni all interno dei database di tale sistema si è accumulata una significativa mole di dati, che è possibile inglobare all interno di un enorme contenitore, il data warehouse. Questo rappresenta uno strumento che fornisce un valore aggiunto al patrimonio informativo aziendale, in quanto su di esso è possibile realizzare una serie di analisi che permettono di ricavare informazioni utili alla gestione operativa. Negli ultimi anni inoltre, grazie alla digitalizzazione delle mappe su supporto cartaceo e al rilevamento di nuovi dati da parte degli enti specializzati, è aumentata la disponibilità di dati geospaziali e delle applicazioni che ne possono usufruire. Le stesse aziende commerciali e la pubblica amministrazione hanno sfruttato tale opportunità, acquisendo informazioni geografiche che possono essere sfruttate a fini operativi, ad esempio per determinare la rete relativa alle consegne, in modo da minimizzare i costi e i tempi. Spesso però ciascun reparto operativo aziendale ha provveduto all acquisizione di tali dati in base ai propri obiettivi, magari aventi lo stesso contenuto informativo di quelli posseduti dagli altri, ma con codifiche differenti. Inoltre ciascun settore può aver provveduto all acquisto di un database spaziale apposito per la memorizzazione di tali dati il cui produttore è differente rispetto a quello degli altri. 5

6 6 INDICE Ecco quindi lo scenario che si può riscontrare all interno di una azienda: ci si ritrova in possesso di un data warehouse contenente dati di business che viene sfruttato per analisi di tipo strategico e una serie di database spaziali eterogenei che contengono dati spaziali di alto dettaglio. Una situazione di questo tipo può essere sfruttata in modo da produrre ulteriori risorse informative, che possono essere utilizzate dal reparto che si occupa della gestione strategico/dirigenziale dell azienda. È possibile infatti integrare i dati spaziali contenuti nel database georeferenziandoli a quelli di business contenuti nel data warehouse, in modo da produrre applicazioni che permettano di visualizzare mappe geografiche arricchite di dati relativi all ambito commerciale. A questo punto vengono a galla i problemi, in quanto è necessario integrare dati contenuti in database di produttori diversi, all interno di un unica applicazione. Questo caso di studio è stato proposto da un azienda la cui attività principale è proprio quella di realizzare soluzioni che permettono l integrazione tra vari sistemi eterogenei, la Engineering Ingegneria Informatica. Uno degli aspetti caratterizzanti di tale società è la metodologia di sviluppo secondo il modello open source, la quale presenta vari vantaggi rispetto a quella effettuata tramite modalità proprietaria. Il lavoro illustrato in questa tesi ha avuto proprio lo scopo di individuare una soluzione a tale situazione, proponendo un metamodello che sia in grado di ovviare a tale problematica; questo ha come finalità la definizione di un modello generico che può essere utilizzato in maniera da permettere l integrazione di dati spaziali estraibili da database di tipo eterogeneo, in modo da integrarli ai dati di business intelligence contenuti nel data warehouse. A tale scopo sono stati analizzati vari strumenti software di tipo open source che possono essere utilizzati, valutandone il grado di adattabilità e la capacità di interfacciamento con applicazioni esterne; tali strumenti saranno utilizzati in modo da produrre un architettura standard che possa essere utilizzata nella maggior parte dei casi pratici che si possono presentare. Per dimostrare infine la fattibilità della soluzione proposta è stato realizzato un prototipo,

7 INDICE 7 consistente in una applicazione utilizzabile dall utente finale. Il programma permette la visualizzazione di una mappa interattiva prodotta grazie ai dati spaziali contenuti in un database PostGIS, integrata ai dati di business intelligence estratti da un data warehouse su database Postgresql. Nel primo capitolo viene illustrato il problema dell integrazione nell ambito informatico, esponendo la differenza tra Enterprise Application Organization e l Enterprise Information Integration. Nel secondo capitolo vengono illustrate le tecnologie oggetto del caso di studio, il data warehouse e i sistemi informatici per la gestione dei dati geografici. Nel terzo capitolo si fa una breve panoramica dell azienda promotrice e la piattaforma per la business intelligence SpagoBI (che dovrebbe utilizzare il modello proposto), illustrando la metodologia di sviluppo software adottata, quella di tipo open source. Nel quarto capitolo viene descritta la fase di analisi relativa ai database spaziali, durante la quale sono stati individuati attributi comuni, utili alla successiva fase di progettazione. Nel quinto capitolo si descrive l architettura finale e le componenti da cui è formata, evidenziando le scelte che hanno portato alla scelta delle stesse. Nel sesto capitolo viene proposta una realizzazione pratica di una possibile applicazione finale che effettua l integrazione dei dati, descrivendo gli strumenti utilizzati. L ultimo capitolo presenta le conclusioni del lavoro realizzato e i suoi possibili sviluppi futuri.

8 8 INDICE

9 Capitolo 1 IL PROBLEMA DELL INTEGRAZIONE In questo primo capitolo viene descritto il problema dell integrazione tra dati e applicazioni che spesso emerge in ambito informatico. Nel paragrafo 1.1 si illustra il processo storico che ha portato ai problemi legati all interoperabilità, nel paragrafo 1.2 si descrive l ERP, una soluzione adottata per la risoluzione del problema, nei paragrafi successivi 1.3 e 1.4 la differenza tra EAI e EII. 1.1 L origine del problema Il sistema informativo di un azienda è composto da un insieme di risorse e attività che devono essere coordinate insieme allo scopo di gestire il flusso di informazioni necessarie a gestire l azienda. A partire dal 1960 si sono resi disponibili strumenti di tipo informatico orientati allo svolgimento di un considerevole numero di operazioni di calcolo in tempi brevi su masse di dati di grosse dimensioni e supporti dedicati alla memorizzazione delle informazioni; inizialmente solo un limitato numero di imprese ha provveduto al loro acquisto al fine di ottimizzare il sistema informativo, dati gli alti costi dei dispositivi di elaborazione del tempo, i mainframe, dando così vita ai 9

10 10 CAPITOLO 1. IL PROBLEMA DELL INTEGRAZIONE primi sistemi informatici. Con il passare degli anni i costi relativi all hardware e al software sono diminuiti drasticamente, in maniera inversamente proporzionale alle prestazioni, che sono di gran lunga migliorate. Tale situazione ha fatto sì che oggigiorno la totalità delle aziende utilizzi risorse informatiche per la gestione delle proprie informazioni. Spesso, soprattutto nelle aziende con una scarsa cultura informatica, la scelta dell acquisto del software necessario alla gestione del singolo reparto avviene in base alle esigenze immediate dello stesso, senza valutare la possibilità di una eventuale necessità di condivisione dei dati con gli altri. La decisione è anche influenzata dai fornitori software, ciascuno dei quali propone dei software proprietari per la gestione di una singola funzione aziendale e non si preoccupano di illustrare gli eventuali svantaggi o conflitti derivanti dall installazione del proprio prodotto, focalizzandosi unicamente ad ottenere il massimo profitto derivante dalla vendita. Inconvenienti del genere sono causati anche da una mancanza di una fase di pianificazione relativa agli strumenti hardware e alle applicazioni da acquistare in base alle reali esigenze e alle future evoluzioni che si possono presentare, ma si orientano a trovare la soluzione che possa soddisfare in modo tempestivo i bisogni immediati. La mancanza di competenze tecniche gioca un ruolo determinante a favore dei venditori, tra i quali emerge come fattore determinante, al fine di incrementare le vendite, la maggior capacità di esporre i propri prodotti. Se il cliente non è in grado di comprendere i benefici reali che uno strumento può fornire tenderà ad acquistare il prodotto che gli verrà presentato in maniera migliore. Ci si ritrova, come conseguenza, nella situazione in cui ciascun settore aziendale possiede un proprio sistema informativo, formato da applicazioni fornite da produttori differenti che sono in grado di svolgere un determinato numero di funzioni, relative ad un ambito particolare. Gli inconvenienti che sorgono in tale ambiente si hanno nel momento in cui un dato settore necessita dei dati prodotti dal sistema informatico di un reparto differente. L ufficio che si occupa della gestione finanziaria può avere bisogno dei dati anagrafici dei suoi dipendenti al fine di organizzare i pagamenti, i

11 1.2. ENTERPRISE RESOURCE PLANNING 11 quali sono memorizzati nell applicativo del reparto risorse umane. Gestire tale situazione non è semplice, si devono definire i metodi necessari a far comunicare le due applicazioni, gestire la differente codifica dei dati, in quanto ciascuna applicazione adotta il suo formato proprietario. 1.2 Enterprise Resource Planning Negli ultimi anni sono state proposte soluzioni atte a risolvere questo problema dell integrazione, inizialmente all interno delle aziende manifatturiere con l MRP ((Material Requirement Planning), per espandersi poi ai vari settori con l ERP (Enterprise Resource Planning). Questo rappresenta un sistema che mira ad integrare tutti i dati e i processi operazionali presenti all interno dell azienda, utilizzando una serie di strumenti hardware e software; viene realizzato un database centrale allo scopo di memorizzare i dati di ciascun modulo del sistema. L approccio realizzato consiste nel sostituire due o più applicazioni software, che necessitano di essere collegate al fine di fornire una funzionalità unica, in un singolo modulo. I vantaggi legati a una soluzione di questo tipo sono: la fornitura di un unica interfaccia per l accesso alle singole applicazioni; l eliminazione delle interfacce necessarie alla comunicazione tra le applicazioni; una minor necessità di manutenzione in quanto si deve visionare su un unico componente anziché su ciascun elemento da cui è composto; l archiviazione dei dati all interno di un unico database centralizzato. Tendenzialmente i produttori software implementano dei moduli ERP che soddisfano le esigenze di singoli settori: gestione risorse umane, pagamenti, ecc. Se un azienda necessita di più moduli provvede al loro acquisto, anche da fornitori differenti, in quanto possono comunicare tra di loro grazie ad una

12 12 CAPITOLO 1. IL PROBLEMA DELL INTEGRAZIONE interfaccia comune. Si procede poi ad una fase di customizzazione dei prodotti, che permette di configurarli in base alle specifiche funzioni ed esigenze aziendali. 1.3 Enterprise Application Integration I sistemi ERP hanno la finalità di ottimizzare la gestione operazionale, ossia di fornire gli strumenti che permettono di organizzare al meglio le attività con una scadenza a breve termine, come la gestione degli ordini, consegne, pagamenti, ecc. Questo avviene integrando le applicazioni di basso livello. Per migliorare la gestione manageriale è necessario invece lavorare con gli strumenti utilizzati dagli addetti al reparto analitico/finanziario: CRM (Customer Relationship Management), Supply Chain Management, Business Intelligence. Si parla quindi di EAI Enterprise Application Integration per indicare una architettura che permette di condividere dati e processi di business tra ciascuna delle applicazioni connesse all interno dell azienda. Gli scopi che si prefigge l EAI sono: integrazione dei dati: si deve assicurare che le informazioni all interno dei singoli sistemi componenti siano consistenti tra di loro; integrazione dei processi: si deve permettere il collegamento tra i processi di business attraverso l integrazione tra le varie applicazioni; indipendenza dai produttori: estrarre regole generali di business a partire dalle applicazioni, in modo da implementarle nel sistema EAI, permette di rimpiazzare un modulo con quello di un altro produttore senza la necessità di ridefinirle; interfaccia comune: un EAI deve presentare una interfaccia di accesso comune alle varie applicazioni da cui è formata, in modo da non costringere l utente finale ad utilizzare front-end di vario tipo. All interno di un EAI vengono implementati due tipi di sistemi:

13 1.3. ENTERPRISE APPLICATION INTEGRATION 13 mediation: un modulo di integrazione che notifica alle varie applicazioni il verificarsi di un cambiamento interno, in modo che ciascuna adatti il proprio stato alla nuova situazione; federation: l unica interfaccia che permette di interagire dall esterno con le applicazioni del sistema e fornire unicamente le informazioni di cui l utente necessita, senza che questi possa capire in che modo funzioni l elaborazione interna. Attualmente non è definita una infrastruttura standard per l EAI, gli addetti ai lavori stanno ancora studiando quale sia la soluzione migliore e gli standard da adottare. Finora i punti comuni ai quali sembrano aderire tutti sono: presenza di un unico broker centralizzato che gestisca gli aspetti riguardanti la sicurezza, gli accessi e la comunicazione. uso di un modello di dati indipendente basato sull uso di strutture standard; l XML (par ) sembra essere il candidato migliore per il raggiungimento di tale obiettivo. un componente che permetta far comunicare ciascuna applicazione con il broker centrale. un modello di sistema che permetta ai produttori di realizzare applicazioni che possano interfacciarsi in maniera standard. I progetti di EAI sono spesso caratterizzati da alti costi di gestione in quanto è necessario realizzare la personalizzazione e intergrazione delle singole applicazioni, lavoro che richiede l impiego di molto tempo e risorse. Per facilitare il tutto è importante l adozione di standard che descrivono come i sistemi informatici devono connettersi tra di loro, la rappresentazione dei dati, la modalità di correlazione tra i processi. Per implementare un nuovo EAI sarebbe così necessario scegliere gli standard adatti alla realizzazione del sistema più conforme alle esigenze aziendali; il numero di sviluppatori sarebbe inoltre maggiore poiché tutti coloro che conoscono gli standard da

14 14 CAPITOLO 1. IL PROBLEMA DELL INTEGRAZIONE adottare sarebbero in grado di realizzare le connessioni tra le applicazioni e non solo quelli delle case fornitrici dei singoli moduli. 1.4 Enterprise Information Integration Un altro tipo di integrazione all interno di un sistema in cui coesistono applicazioni tra loro indipendenti è l EII (Enterprise Information Integration). Si differenzia dall EAI in quanto opera ad un livello di complessità più basso; la prima è orientata a connettere applicazioni, la seconda invece mira a integrare i dati utilizzati da queste, implementando soluzioni che permettono di uniformare la modalità di accesso ai dati e il formato di rappresentazione delle informazioni. I software EII hanno la funzione di presentare una visione dei dati contenuti in un determinato momento nei sistemi OLTP (On Line Transactional Processing), in un formato che permette l analisi da parte dell utente, come report, fogli elettronici (spreadsheet), testi (word processor). La procedura per ottenere le informazioni finali prevede quattro fasi: 1. determinazione delle informazioni che devono essere recuperate (finanziarie, dati CRM, BI, ecc.). 2. individuazione delle fonti dati da cui estrarre le informazioni; tipicamente sono le sorgenti dei sistemi OLTP, ma anche il data warehouse (par. 2.1) può essere utilizzato come fonte dati. Infatti utilizzando i dati di quest ultimo si possono ottenere dati che presentano una visione storica, in quanto i sistemi OLTP contengono esclusivamente i dati attuali, mentre il data warehouse rappresenta il repository di tutte le informazioni che sono state memorizzate dall azienda. 3. creazione dei riferimenti alle informazioni dei sorgenti dati; 4. procedura di recupero delle informazioni tramite: query SQL, se le fonti dati sono database relazionali;

15 1.4. ENTERPRISE INFORMATION INTEGRATION 15 metodi proprietari, se le fonti dati sono i mainframe legacy; metodi standard per il recupero dei dati a partire da varie fonti dati, come chiamate ODBC, JDBC, OLEDB o metodi forniti per informazioni rappresentate in formato XML. Una volta recuperati i dati si procede a presentarli all utente, popolando l oggetto dedicato alla visualizzazione finale.

16 16 CAPITOLO 1. IL PROBLEMA DELL INTEGRAZIONE

17 Capitolo 2 LE TECNOLOGIE COINVOLTE In questo secondo capitolo vengono illustrate le due principali componenti tecnologie informatiche oggetto di studio. Nel paragrafo 2.1 è illustrato in cosa consiste un data warehouse, i benefici che può portare all azienda, il formato di memorizzazione dei dati (par ), le problematiche relative alla sua costruzione e i diversi tipi di architettura che lo caratterizzano (par ) e le operazioni di analisi che si possono effettuare (par ). Nel paragrafo 2.1 vengono poi descritti i sistemi informatici per la gestione delle informazioni geografiche, la loro evoluzione (par ), i problemi relativi alla mancanza di standard per la memorizzazione dei dati spaziali esistenti. Nel paragrafo viene descritta la situazione odierna e i servizi standard servono a gestire GIS eterogenei. 2.1 Data warehouse Oggigiorno nelle aziende commerciali, industriali, nella pubblica amministrazione si ha la necessità di gestire una significativa mole di dati, i quali permettono di generare informazione, l elemento fondamentale per l amministrazione dell azienda. 17

18 18 CAPITOLO 2. LE TECNOLOGIE COINVOLTE Le informazioni devono essere utilizzate in ciascuno dei livelli gestionali dell azienda, quello che differisce è la tempestività e il dettaglio con cui i dati devono essere forniti: a livello basso sono necessari dati ad alto dettaglio, reperibili in tempo reale. Nel magazzino di un supermercato si deve sapere giorno per giorno il quantitativo di merce presente, se le scorte sono insufficienti a colmare la domanda è necessario provvedere a procedere con il reperimento immediato dei prodotti mancanti. Ecco allora la necessità di avere database perfettamente in linea con la situazione reale, i quali rappresentano una fotografia dello stato attuale. Il sistema che gestisce tali tipi di dati è detto transazionale. Tuttavia i dirigenti dell azienda non hanno la necessità di sapere il quantitativo venduto di giorno in giorno, ma di disporre di un quadro generale della situazione, che disegni l andamento della gestione che si ha avuto nel periodo medio/lungo. Il manager vuole sapere, ad esempio, quali sono stati i prodotti più o meno venduti negli ultimi sei mesi, magari distinguendoli per zone di vendita o categorie di acquirenti, per poi decidere su quale linea organizzare la produzione nei successivi. Se i dirigenti di una casa discografica notano l ascesa della vendita della musica su internet rispetto alla tradizionale vendita del cd, sposteranno i loro investimenti sulla promozione del loro portale web, sull inserzione di banner pubblicitari all interno di siti esterni, mentre risparmieranno sulle risorse dedicate alla produzione del classico supporto fisico e alla sua distribuzione presso i punti vendita. Queste decisioni possono essere prese nel momento in cui si hanno le informazioni riassuntive, che permettono di avere una panoramica ad alto livello della gestione aziendale. Solitamente la produzione di tale visione viene effettuata sintetizzando e riassumendo tutti i dati di alto dettaglio utilizzati per la gestione a basso livello, creando indici e indicatori che possono essere interpretati facilmente. Disporre però dell andamento dell ultimo semestre al fine di stendere un piano previsionale per il futuro non è di certo utile se non lo si può confrontare con i dati riguardanti i mesi e periodi precedenti se non addirittura anni, per

19 2.1. DATA WAREHOUSE 19 questo sarebbe utile disporre anche dei dati aziendali accumulati a partire dalla nascita dell azienda. La soluzione ai problemi illustrati si ha adottando uno strumento assai utile, le cui potenzialità emergono parallelamente alla dimensione e all età dell azienda: il data warehouse. Questo può essere visto come una raccolta di dati di considerevoli dimensioni, la cui struttura dati è finalizzata ad effettuare interrogazioni su enormi quantità di informazioni, producendo risultatiche permettono di fornire un supporto ai processi decisionali. Le caratteristiche fondamentali del data warehouse sono: integrazione: i dati contenuti al suo interno sono il risultato di una serie di operazioni, consistenti nel recupero di dati registrati all interno di sistemi transazionali e legacy 1 dell azienda, spesso contenenti le stesse informazioni; queste sono però spesso codificate in maniera differente, in quanto gli applicativi che le gestiscono sono stati acquistati da produttori diversi e possono ulteriormente essere inconsistenti tra di loro. È necessario per cui, allo scopo di produrre un unico repository che contenga tali dati, effettuare un operazione di integrazione delle informazioni contenute nei vari sistemi, eventualmente alimentate da fonti esterne, che permettono di risolvere le inconsistenze rilevate, etichettando il tutto con metadati descrittivi, in modo da arricchire la base di conoscenza che si intende produrre. orientamento al soggetto: per quanto riguarda la struttura di archiviazione dei dati non ci si prefigge, al contrario dei sistemi transazionali, l obiettivo di minimizzare la ridondanza (tramite la normalizzazione) in modo da ridurre la quantità di memoria fisica utilizzata. Quest ul- 1 Sistemi hardware e software che continuano ad essere utilizzati perché il loro aggiornamento richiederebbe un costo troppo elevato rispetto alle migliori prestazioni che si otterrebbero con gli upgrade, oppure perché il loro rimpiazzo non sarebbe compatibile con altre applicazioni o altri software. In pratica si tratta di sistemi obsoleti, ma che hanno richiesto all origine un notevole investimento e che adesso si rivelano lenti ed incompatibili con i nuovi sistemi. [Cis07]

20 20 CAPITOLO 2. LE TECNOLOGIE COINVOLTE timo punto non viene preso in considerazione come fattore di limitazione nell implementazione di un data warehouse: lo spazio dedicato all immagazzinamento dei dati (e relativi costi) deve essere illimitato, in quanto è necessario implementare un sistema di notevoli dimensioni (le tabelle sono spesso denormalizzate), che però consente di effettuare in modo semplice ed efficiente interrogazioni da parte degli utenti finali; inoltre i dati non sono organizzati in maniera tale da rendere efficiente interrogazioni orientate alle transazioni, ma quelle orientate all analisi dei soggetti. dipendenza dal tempo e non volatilità: come citato in precedenza, per effettuare un analisi di tipo previsionale è di fondamentale importanza disporre, oltre che dei dati attuali, anche di dati storici. Per tale motivo il data warehouse è concepito come un archivio in sola lettura in cui non si effettuano cancellazioni delle informazioni passate, ma si conservano, in quanto hanno utilità come parametro di confronto e valutazione rispetto alla situazione attuale. Gli aggiornamenti e l allineamento dei dati avviene periodicamente, al contrario un sistema transazionale, in cui tale operazione si effettua costantemente, si sovrascrivono le informazioni non più valide, fornendo solo la visione della situazione attuale. Un problema legato al data warehouse riguarda la possibilità di effettuare analisi su dati che non siano stati aggiornati, fornendo una panoramica non coerente con la realtà. Descritte le caratteristiche principali, si intuisce che tale risorsa non è adottabile da una neo-azienda di recente formazione, in quanto manca la componente temporale, la storicità dei dati, ingrediente fondamentale per lo sfruttamento dell utilità di questo strumento. Non solo, i costi per la gestione dello stesso, in particolare il lavoro di integrazione dei dati contenuti in sistemi eterogenei e legacy, non sono certamente trascurabili. Per le aziende giovani è comunque utile la progettazione di un sistema informatico nell ottica di una futura possibilità di utilizzo del data warehouse.

21 2.1. DATA WAREHOUSE Formato di memorizzazione dei dati All interno di un data warehouse i dati sono organizzati e strutturati in tabelle che permettono di avere una visione multidimensionale dei soggetti su cui si vuole focalizzare l analisi, secondo un modello denominato Dimensional Fact Model. Un soggetto viene logicamente rappresentato da un ipercubo n-dimesionale, concepito come un elemento caratterizzato da n dimensioni; tipici esempi di soggetti sono gli acquisti e le vendite. Per dimensione si intende un aspetto che permette di caratterizzare un dato soggetto. Ad esempio, il soggetto vendita può essere definito dalle dimensioni prodotto, cliente, tempo, punto vendita, ecc.; le dimensioni costituiscono gli assi dell ipercubo. A loro volta le dimensioni presentano al loro interno degli attributi, che possono essere tra loro relazionati in base ad una gerarchia, ad esempio la dimensione tempo presenta la gerarchia di attributi anno, trimestre, mese, giorno, ora. Fissato un valore per ciascuna dimensione (es. prodotto= Pc desktop, tempo= Gennaio, mercato= Roma ) si individua univocamente una cella dell ipercubo (Figura 2.1); questa rappresenta un fatto a cui vengono associate una o più misure (es. quantità venduta). In fase di progettazione è determinante la scelta del grado di granularità delle misure che vengono utilizzate nei fatti. La granularità rappresenta il grado di dettaglio dei dati, più è alta più i dati sono meno dettagliati; quindi il grado di granularità minima riguarda i dati a livello operativo, ad esempio il quantitativo venduto in un dato punto vendita in un determinato giorno. Un livello basso di granularità può essere difficile da gestire, in quanto i dati che si vogliono visualizzare a seguito di un interrogazione sono dati di sintesi, che prevedono una granularità maggiore per la cui produzione è necessario sommare i dati al dettaglio (ad es. quantità giornaliere) al fine di ottenere il livello desiderato (ad es. quantità trimestrali). Progettare data mart con misure già aggregate è la soluzione spesso utilizzata al fine di evitare questo inconveniente; il requisito necessario per il raggiungimento di questo obiettivo