Per completezza, deve essere menzionata anche la misura relativa alla tabella SPART, descritta nel Capitolo 4.2, e creata appositamente per permettere all’utente di visua- lizzare report incrociati tra fatti e dimensioni non strettamente collegati.
Figura 6.21: Misura relativa a SPART
Come è possibile vedere in Figura 6.21, l’unica misura presente è il conteggio delle righe della struttura, definita di default solo per rendere la tabella un gruppo di misure e poter essere utilizzata da ponte tra le altre. A tale scopo, la misura evidenziata è stata nascosta all’utente, in quanto inutile ai fini delle analisi.
Nella figura seguente è visibile il risultato di un’interrogazione di esempio relativa alla fact Consumi, utilizzando le dimensioni Natura Consumi ed Emissione, quest’ultima non correlata alla misura.
Come si può vedere, il report è stato creato nella forma standard, inserendo il valore ’N.D.’ nell’attributo non correlato, a sottolineare la mancanza generica di informa- zione, situazione speculare a quella espressa nella Sezione6.8 nel caso di un attributo
collegato alla misura. Non è quindi possibile, da parte di un utente, capire visivamente la differenza tra la mancanza reale di informazione e le dimensioni non correlate alle misure. É però necessario istruire l’utilizzatore al fine di realizzare report sensati.
Infine, come già anticipato nel capitolo precedente, al completamento della fase di elaborazione del data cube, verranno eliminate le tabelle del data warehouse.
Capitolo 7
Conclusioni
La presente tesi, redatta conseguentemente ad un’esperienza di progetto formativo, ha avuto come oggetto la progettazione di un data warehouse inerente al controllo e alle analisi dei dati relativi ad un prodotto CRM, indirizzato ad un’azienda operante nel settore della vendita di energia elettrica e gas.
A differenza della maggior parte dei casi, per la costruzione del data warehouse in oggetto non è stato necessario integrare dati provenienti da più fonti, in quanto ne è stata utilizzata una unica, il prodotto RETI, anch’esso di proprietà dell’azienda dove è stato svolto il tirocinio.
In seguito alla fase di progettazione concettuale, in cui sono state espresse sintetica- mente le richieste del committente, si è proceduto alla progettazione logica, durante la quale sono state prese alcune decisioni strutturali che sono andate a completare quelle stabilite durante le fasi iniziali: è stato stabilito di dividere il fatto Billing in corpo e testata delle fatture e, conseguentemente, per far interagire le due strutture e permet- tere all’utente di eseguire report incrociati su misure e dimensioni diverse, si è optato per l’aggiunta di una tabella di appoggio, denominata SPART.
La successiva fase dell’ETL è stata gestita per scelta aziendale tramite query di estra- zione, trasformazione e caricamento dei dati in linguaggio SQL utilizzando SQL Server Management Studio, eliminando ogni tabella di staging e del data warehouse in seguito all’elaborazione finale del cubo, per ricrearle nuovamente al successivo aggiornamento. In seguito alle operazioni di creazione e modifica del data cube, gestite tramite il motore OLAP di Microsoft SQL Server Analysis Service (SSAS), è stato possibile eseguire le
analisi multidimensionali richieste in fase di progettazione concettuale, al fine di mo- strare le potenzialità della soluzione realizzata. Inoltre, per soddisfare compiutamente le richieste del cliente, le misure sono state integrate con query MDX, utilizzabili come misure standard, in quanto generate e gestite all’interno della struttura del cubo. Lo strumento di reportistica utilizzato per visualizzare le interrogazioni del committen- te è RETIBI, applicativo sviluppato dall’azienda presso cui è stato svolto il tirocinio, in grado di gestire l’aggiornamento calendarizzato del data warehouse e del data cube, oltre a generare grafici e report, di cui sono stati riportati degli esempi nel Capitolo 6. Ricapitolando, i punti critici del progetto sono sicuramente la fase di ETL eseguita tramite query SQL, che comprende il caricamento prima delle tabelle dei fatti e succes- sivamente delle dimensioni, l’eliminazione delle strutture di staging e data warehouse al termine delle operazioni sul cubo e la divisione tra le testate e le righe del corpo delle fatture in due fatti separati, ai quali è di primaria importanza trovare un’altra soluzione più corretta.
Per ciò che riguarda il primo punto preso in esame, l’ordine di caricamento dovrebbe essere invertito.
Nel secondo caso, una possibilità concreta di miglioramento potrebbe essere data dal- l’uso di strumenti più adeguati alla fase specificata, per esempio SQL Server Integration Services (SSIS), il quale permette di estrarre, elaborare e caricare dati da più fonti in più destinazioni tramite dei "pacchetti", tra i quali è presente anche quello relativo all’operazione di ricerca in tabella, utile al fine di evitare l’eliminazione delle strutture del data warehouse.
Una soluzione al terzo caso, invece, potrebbe essere copiare i valori delle misure delle testate sulle righe delle fatture relative, e, successivamente, creare delle misure ad hoc per evitare calcoli errati: si potrebbe pensare ad utilizzare la media dei valori delle testate, oppure a selezionarne valori distinti.
Per concludere, l’esperienza di tirocinio mi ha permesso di mettere in pratica le co- noscenze teoriche apprese, relative alle fasi di progettazione e creazione di un data warehouse e di confrontarmi e apprendere strumenti per l’implementazione di proce- dure di Estrazione, Trasformazione e Caricamento dei dati e per la costruzione di data
cube per l’analisi multidimensionale delle informazioni. Inoltre, mi ha permesso di ap- prendere nozioni anche in campo lavorativo: durante l’esperienza sono stata integrata all’interno di uno staff, che ha saputo insegnarmi le dinamiche aziendali e lavorative. Infine, essendo l’azienda in espansione nel campo della Business Intelligence, ho potu- to far crescere a mia volta il know-how aziendale, parallelamente ad una mia crescita personale e professionale.