DIPARTIMENTO DI INFORMATICA
CORSO DI LAUREA MAGISTRALE IN DATA SCIENCE AND BUSINESS INFORMATICS
TESI DI LAUREA
ANALYSIS SERVICE TABULAR PER LO SVILUPPO
DI UNA SOLUZIONE DI BUSINESS INTELLIGENCE
Relatore:
Prof. Salvatore RINZIVILLO
Candidato: Gianfranco SALAMIDA
Tutor Aziendale: Dott. Francesco MORINI
RIASSUNTO
Il seguente lavoro di tesi descrive la realizzazione di una soluzione di Business Intelligence a supporto dei processi di Enterprise Budgeting e Planning per una importante società multinazionale nel settore della moda. Il problema che avverte il cliente è di non poter gestire, con il corrente Data Warehouse, grandi quantità di dati per fini di analisi e valutazione delle performance aziendali. L'obiettivo del caso di studio è di completare l'offerta al cliente con un layer di Business Intelligence che, sfruttando il motore Analysis Services Tabular di Microsoft e le potenzialità dei tool di reporting annessi, riesca a fornire uno strumento di analisi integrato più efficiente rispetto a quello normalmente utilizzato dalla società, in termini di prestazioni ed esecuzione query.
In particolare, è stato necessario modificare il "Multidimensional Data Model" dell’azienda “CCH Tagetik” ospitante, cuore del software “Corporate
Performance Management” offerto ai clienti, migrando dalla modellazione multidimensionale corrente in una modellazione alternativa introdotta nel 2012 da Microsoft definita tabulare.
Tale modello realizzato in versione tabulare sarà una semplificazione di quello originario a causa dell’alta complessità di progettazione, cosi da trarre le caratteristiche principali ed essenziali, utili per una prima fase di testing di verifica delle perfomance e scelta per l’assunzione futura di tale soluzione. Saranno presentate sia le problematiche di ordine generale riscontrati durante la fase di ETL con annesse soluzioni ed infine l’analisi e verifica delle
INDICE
1 INTRODUZIONE...5
1.1 PRESENTAZIONE DEL PROBLEMA ...5
1.2 RASSEGNA DELLA LETTERATURA ...6
1.3 CONTENUTO DELLA TESI ...7
2 BUSINESS INTELLIGENCE & DATA WAREHOUSING ...8
2.1 STORIA DELLA BI ...8
2.2 ARCHITETTURA DI UN SISTEMA DI BI ...11
2.3 DALLA BUSINESS ALLA FINANCE INTELLIGENCE E REALIZZAZIONE DI SOFTWARE CPM ...22
3 CASO DI STUDIO...25
3.1 AZIENDA OSPITANTE ...25
3.2 AMBIENTE E STRUMENTI DI SVILUPPO ...26
3.3 CONFIGURAZIONE HARDWARE & SOFTWARE ...27
3.4 SSAS TABULAR & MULTIDIMENSIONAL ...35
4 MULTIDIMENSIONAL DATA MODEL ...37
4.1 CORPORATE PERFORMANCE MANAGEMENT (TAGETIK 5) ...37
4.2 CORSO DI FORMAZIONE ...40
4.3 ARCHITETTURA DEL MODELLO DATA WAREHOUSE ...40
4.4 FATTO E DIMENSIONI ...43
4.5 STRUTTURE AGGREGATIVE ...60
4.6 RESTRIZIONI SULLE DIMENSIONI ...63
4.7 ETL PREDEFINITO ...66
4.8 TECNICHE DI MEMORIZZAZIONE DATI ...66
5 SQL SERVER ANALYSIS SERVICE TABULAR & MULTIDIMENSIONAL...67
5.1 DA PIATTAFORMA UDM A BISM ...67
5.2 BUSINESS INTELLIGENCE SEMANTIC MODEL ...69
5.3 LOGICA E PIANI DI BUSINESS QUERY ...71
5.4 ACCESSO, COMPRESSIONE, MEMORIZZAZIONE DEI DATI ...75
5.5 DATI AGGREGATI & DETTAGLIATI ...78
5.6 RELAZIONE TRA TABELLE ...79
5.7 GERARCHIE ...80
5.8 COMPONENTI AGGIUNTIVE ...81
5.9 RIEPILOGO ...83
6 ETL (EXTRACT, TRANSFORM, LOAD)...86
6.1 SORGENTE DATI ...86
6.2 TABELLA DEI FATTI ...88
6.4 GESTIONE DELLA DIMENSIONE TEMPORALE ...95
6.4.1 PROBLEMA ...95
6.4.2 IMPLEMENTAZIONE DELLA SOLUZIONE ...96
6.4.2.1 CLASSIFICAZIONE DEGLI IMPORTI ...102
6.4.2.2 CASI SPECIFICI DI CALCOLO ...102
6.4.2.3 CALCOLO DELL’IMPORTO PERIODICO ...105
6.5 GESTIONE DELLA LIMITAZIONE UTENTE ...108
6.5.1 PROBLEMA ...108
6.5.2 IMPLEMENTAZIONE DELLA SOLUZIONE ...109
6.6 GESTIONE DELLA VALUTA ...116
6.6.1 PROBLEMA ...116
6.6.2 IMPLEMENTAZIONE DELLA SOLUZIONE ...117
6.7 GESTIONE DELLE RELAZIONI MOLTI A MOLTI ...121
6.7.1 PROBLEMA ...121
6.7.2 IMPLEMENTAZIONE DELLA SOLUZIONE ...122
6.8 GESTIONE DELLE GERARCHIE ...130
6.8.1 PROBLEMA ...130
6.8.2 IMPLEMENTAZIONE DELLA SOLUZIONE ...132
7 CONFRONTO DELLE PERFORMANCE...135
7.1 ELABORAZIONE DEI MODELLI ...135
7.2 ANALISI DELLE PERFORMANCE ...139
8 CONCLUSIONI...150
9 ASPETTATIVE FUTURE...152
10 BIBLIOGRAFIA...154
1 INTRODUZIONE
1.1 PRESENTAZIONE DEL PROBLEMA
In un contesto aziendale risulta di fondamentale importanza la possibilità di analizzare grandi quantità di dati prodotti dai processi di business. Questo è proprio l’obiettivo che si prefigge la Business Intelligence (BI).
Il principale obiettivo dei sistemi di BI consiste nel fornire supporto durante i processi decisionali, raccogliendo le informazioni generate durante lo
svolgimento delle attività aziendali e mettendo a disposizione strumenti per l’analisi dei dati. Al giorno d’oggi molte aziende di consulenza offrono servizi per Analysis & Reporting clienti aziendali finali.
A causa dell’alta presenza di grandi mole di dati difficili da elaborare per l’estrazione di informazioni interessanti per le decisioni aziendali per una società multinazionale cliente nel settore della moda, nasce l’esigenza di risolvere tale inefficienza con l’inserimento di un layer di Business Intelligence soluzione e obiettivo del caso di studio della seguente tesi, offrendo maggior efficienza delle performance query eseguite sul modello.
L’obiettivo è quello di descrivere il lavoro da me svolto presso l’azienda “CCH Tagetik”, una società che si occupa da anni di consulenza per esigenze nell’area Finance. I clienti si affidano alla “Financial Performance Platform” per
automattizzare complessi processi di business che influiscono sui risultati finanziari, fornendo miglior soluzioni di Corporate Perfomance Management. L’obiettivo è la realizzare una soluzione capace di raccogliere ed organizzare i dati in modo più efficiente rispetto alla modellazione classica
multidimensionale utilizzata da anni dall’azienda, per fornire delle dashboards di reportistica, generabili tramite il calcolo dei KPIs, in tempi relativamente migliori mantenendo le medesime caratteristiche del modello corrente. In azienda “CCH Tagetik” è stato possibile raggiungere gli obiettivi con l’utilizzo di strumenti Business Intelligence, grazie alla presenza della
partnership con l’azienda Microsoft come SQL Server Analysis Service (SSAS) Multidimensional, SSAS Tabular, Excel con PivotTable in fase di
Reporting
e Analysis e infine SQL Server Profiler per analisi delle performance query finali.1.2 RASSEGNA DELLA LETTERATURA
Nella scrittura del seguente documento sono state consultate diverse fonti. Nello specifico, per gli argomenti riguardanti il software madre adottato dall’azienda e le relative tipologie e strutture dati trattati in ambito economico/ informatico, si è fatto riferimento al libro [Wolfram 06] “Corporate
Performance Management”.
Per la parte riguardante l’introduzione e l’analisi di un data warehouse e alcuni concetti essenziali di modellazione multidimensionale si è fatto riferimento al libro di [Albano 17] e [Ruggieri 17] “Decision Support Database Essentials”, e altre fonti quali “Dimensional Modeling: In a Business Intelligence
Environment” di [Ballard 06].
Per le informazioni generali dell’azienda committente e sulla struttura del modello multidimensionale correntemente utilizzato si è utilizzata la
documentazione interna presentata dalla azienda ospitante durante il periodo di formazione.
Per la parte riguardante l’implementazione, progettazione e analisi del modello tabulare si è fatto riferimento a [Russo 12] ai libri “Microsoft 2012 SSAS The BISM Tabular Model”, “Tabular Modeling in Microsoft SSAS”, The Definitive Guide to DAX: Business intelligence with Microsoft Excel, SQL Server
Analysis Services, and Power BI (Business Skills)”.
Ed infine, ulteriori riferimenti sulle tecniche implementative, documentate periodicamente, presenti sul sito <www.microsoft.com> per le problematiche riscontrate in fase di ETL di SSAS Tabular Model.
1.3 CONTENUTO DELLA TESI
Nella prima parte verrà fornita un’introduzione storica sulla BI e sarà descritta la struttura generica di un sistema Data Warehouse, comunemente utilizzati dalle aziende per analisi delle performance aziendali; successivamente si esaminerà l’infrastruttura hardware e gli strumenti software utilizzati per la realizzazione degli obiettivi; seguiti dall’analisi del modello "Multidimensional Data Model" dell’azienda Tagetik trattando l’intero caso di studio e
successivamente si descrivono i punti salienti dell’implementazione e sviluppo delle procedure di Estrazione, Trasformazione e Caricamento dei dati (ETL), applicate in fase di migrazione in modellazione tabulare, con relative
problematiche e annesse soluzioni di ordine generale riscontrate durante la fase di ETL. Infine verranno trattati gli step conclusivi ovvero la realizzazione ed elaborazione dei cubi per evidenziare le analisi delle performance finali del modello in termini di esecuzione query in fase di reporting ottenuti dalla nuova modellazione e i possibili sviluppi futuri.
2 BUSINESS INTELLIGENCE & DATA
WAREHOUSING
2.1 STORIA DELLA BI
Il termine Business Intelligence è stato introdotto per la prima volta nel 1868 da “Richard Millar Devens". Egli lo utilizzò per descrivere il modo con cui un banchiere, Sir “Henry Furnese", era riuscito ad avere successo nella propria carriera. Furnese riuscì a comprendere la situazione economica, politica e del mercato prima dei suoi concorrenti: attraverso l’Olanda, le Fiandre, la Francia e la Germania creò una perfetta organizzazione di business intelligence”, scrive Devens, pertanto ”le notizie...furono ricevute da lui per primo”. Furnese utilizzò le informazioni in suo possesso con fine fraudolento, passando quindi alla storia come banchiere corrotto. Quella appena proposta rappresenta una prima idea di raccolta di informazioni per la valutazione del business.
Per avere importanti sviluppi nel settore si dovette attendere fino alla metà del XX secolo, periodo in cui la tecnologia iniziò ad essere considerata di supporto alla BI. Nel 1958 l’informatico “Hans Peter Luhn” con un articolo descrisse “un sistema automatico...sviluppato per diffondere informazioni alle varie sezioni di un’organizzazione industriale, scientifica o di governo”.
Egli inoltre riportò la definizione di intelligenza presente sul dizionario di Websters come ”l’abilità di cogliere le interrelazioni tra fatti presentati in modo da guidare l’azione verso un obiettivo desiderato”. Quest’ultima definizione si avvicina molto a quella della BI: un modo per capire velocemente e
rapidamente grandi quantità di dati, così da poter intraprendere la miglior decisione possibile. Le ricerche di Luhn non fornirono solo argomentazioni teoriche, egli infatti sviluppò metodi che furono utilizzati nei primi sistemi analitici realizzati da IBM.
L’invenzione dell’hard disk da parte di IBM nel 1956 rappresentò una
rivoluzione per il salvataggio dei dati. Vennero introdotti i floppy disc, i laser disk ed altre tecnologie che permisero la produzione di una maggiore quantità di informazioni dato che vi era posto disponibile in cui salvarle. Questo ha portato alla creazione dei primi Database Management Systems (DBMS), rinominati genericamente anche Decision Support Systems (DSS). A partire dagli anni ’70 iniziarono a spuntare i primi sviluppatori di sistemi di BI, che realizzarono strumenti per la gestione e l’organizzazione dei dati. Tuttavia la tecnologia era nuova e difficile da utilizzare, inoltre a causa del suo elevato costo aveva un mercato ristretto alle grandi aziende.
Con l’introduzione dei DBMS le compagnie iniziarono a memorizzare i dati prodotti dalle attività di business in sorgenti operazionali. L’ultima fase per ottenere informazioni significative dai dati consiste nel fare il reporting degli stessi. Le applicazioni di business, tuttavia, producono dati che riguardano settori differenti, di conseguenza gli stessi vengono memorizzati in sorgenti differenti, ognuna delle quali è completamente separata dalle altre. Le
organizzazioni avevano però l’esigenza di eseguire report su un’unica versione dei dati, nasce quindi il problema dell’integrazione delle sorgenti.
Nei primi anni ’80 “Ralph Kimball” e “Bill Inmon” individuarono la soluzione nel Data Warehouse, struttura che memorizza i dati provenienti da sorgenti differenti. Nonostante gli approcci utilizzati fossero differenti, Kimball e Inmon avevano la stessa idea di base. Con il data warehouse le aziende furono in grado di memorizzare le informazioni prodotte dalle attività di business in un unico repository centralizzato. Grazie ad esso venne superata l’architettura a silos esistente in favore di una soluzione contenente dati integrati, non volatili, variabili nel tempo e orientati ai soggetti.
Il termine business intelligence iniziò a diffondersi su larga scala nei tardi anni ’90 e primi anni 2000, grazie all’inserimento nel mercato di nuovi fornitori di software. Durante questo periodo la BI aveva due funzioni: produzione di dati e reporting, organizzazione dei dati e presentazione. La tecnologia adottata
aveva però un problema principale, la complessità d’utilizzo. Molti dei progetti aziendali venivano ancora gestiti dal dipartimento IT, facendo emergere che gli utenti finali non erano ancora capaci di eseguire attività di BI in modo
indipendente. Gli strumenti esistenti erano stati pensati per gli esperti, ed era necessaria un’intensa formazione analitica per l’acquisizione delle conoscenze. Col passare degli anni iniziarono ad essere sviluppati tools anche per gli utenti meno tecnici, ma questo cambiamento avvenne lentamente. Questa fase di sviluppo venne anche chiamata BI 1.0.
L’inizio del XXI secolo rappresenta una svolta nel mondo della BI. Vengono sviluppate nuove tecnologie che introducono una maggiore semplicità d’utilizzo. I nuovi strumenti consentono l’elaborazione Real-Time, con i dati che vengono inseriti all’interno del Data Warehouse quando generati dalle attività di business, consentendo alle aziende di prendere decisioni con le più recenti informazioni a disposizione. Altre tecnologie permettevano un accesso self service ai sistemi agli utenti meno esperti, liberando i dipartimenti
dall’onere di gestione dei progetti. Durante questo periodo, soprannominato anche BI 2.0, ha contribuito fortemente la crescita esponenziale di Internet. Venne utilizzato un approccio maggiormente orientato al web ed ai browser, in contrapposizione agli strumenti proprietari che avevano caratterizzato la generazione precedente. La nascita dei social network quali Facebook, Twitter e dei Blog fornì agli utenti un nuovo modo per condividere idee ed opinioni. La crescente interconnessione del mondo imprenditoriale portò le compagnie ad avere la necessità di informazioni in tempo reale. Per mantenere il passo della concorrenza dovevano capire le opinioni e le esigenze dei consumatori. La BI non veniva più considerata come uno strumento aggiunto o un
vantaggio, ma stava diventando un obbligo per le imprese che volevano rimanere competitive ed appetibili su di un nuovo mercato orientato ai dati. Attualmente il periodo di grande innovazione e sviluppo degli anni 2000 si è trasformato in un intenso processo di raffinazione. Alcune delle caratteristiche che si vogliono migliorare sono la presentazione dei dati e l’ampliamento delle
opzioni di self service. Alcuni dei nuovi strumenti di visualizzazione si sono evoluti ed avvicinati agli utenti finali. L’obiettivo è fornire ad essi un potente strumento per l’accesso completo ai dati, così che possano esplorarli in modo autonomo, senza alcun tipo di formazione.
Gli sviluppi futuri in ambito BI sono orientati al cloud ed al settore del mobile. Grazie al cloud è possibile delocalizzare il software su Internet, riducendo il costo di archiviazione e rendendo l’accesso ai dati più facile e veloce (BI as-a-service). Altro aspetto di grande importanza è l’aumento delle piattaforme mobile, che consentono agli utenti di svolgere attività di BI in modo portabile, tramite smartphone, tablet o altri dispositivi (BI pervasiva).
2.2 ARCHITETTURA DI UN SISTEMA DI BI
In Figura 1.1 viene mostrata la generica architettura di un sistema di BI, con i suoi principali componenti:
• Sorgenti operazionali (organizzazione dati basati su tabelle e relazioni); • Processo ETL (Extract Transform and Load);
• Data Warehouse (dati di un'organizzazione, per analisi a fini decisionali); • Modello dei dati (tipologie di modellazione);
Figura 1.1: Architettura di un generico sistema di BI.
BISM è l’acronimo di Business Intelligence Semantic Model e rappresenta il modello con il quale verranno memorizzati i dati di un DW.
A seconda dell’ambiente e del software utilizzato, può variare l’architettura del sistema, tuttavia i componenti mostrati in Figura 1.1 sono quelli solitamente sempre presenti. Per ognuno di essi i vari fornitori di software mettono a disposizione strumenti che ne consentono la gestione. Nei seguenti paragrafi verrà fornita una descrizione per ogni componente.
SORGENTI OPERAZIONALI - Rappresentano il punto di partenza dell’intera architettura. All’interno di un’organizzazione sono presenti diverse sorgenti operazionali, ognuna delle quali memorizza informazioni appartenenti a contesti differenti. Questi sistemi hanno il principale scopo di fornire
supporto per l’esecuzione dei processi di business.
Le attività generate da questi sistemi sono dette transazioni e gli stessi prendono il nome di sistemi OLTP (Online Transaction Processing). Per facilitare l’esecuzione del business essi devono consentire differenti forme di interazione con il database, come inserimenti, aggiornamenti o cancellazioni. Durante ognuna di queste attività viene generata una transazione che il sistema avrà il compito di tenere memorizzata.
I sistemi OLTP sono adatti per l’esecuzione dei processi di business, ma non per la valutazione degli stessi. Le sorgenti sono infatti organizzate in modo completamente separato, ognuna con la propria tecnologia e contenente i dati del dominio applicativo trattato, per tale motivo è necessario passare ai sistemi analitici.
Tabella 1.2: Differenze tra sitemi OLPT e OLAP.
In Tabella 1.2 viene mostrato un confronto tra i sistemi OLTP e quelli OLAP. Quest’ultimi sono organizzati ed ottimizzati per effettuare l’analisi dei dati e forniscono strumenti per eseguire il reporting degli stessi.
Prima di poter arrivare a questi sistemi è necessario svolgere un ulteriore passo intermedio. I dati contenuti nei database operazionali hanno una granularità d’informazione di molto superiore rispetto a quella necessaria ai possessori del business per prendere le decisioni. In secondo luogo risulta essere necessario integrare le diverse sorgenti, in modo tale da consentire valutazioni sui dati integrati, quest’ultimo obiettivo principale dei sistemi di BI. Il processo che consente il passaggio dai sistemi OLTP a quelli analitici prende il nome di ETL (Extract, Transform Load).
OLTP (On-Line Transaction Processing) OLAP (On-Line Analytical Processing)
Sistemi per la gestione dei dati Sistemi per l’analisi dei dati Bassa complessità delle operazioni Permettono di eseguire operazioni non
previste nella progettazione del DB (sistemi di supporto alle decisioni)
Le operazioni coinvolgono una piccola quantità di dati
Operano su grosse moli di dati
Continuo aggiornamento dei dati I dati sono “statici” (usualmente si utilizzano dati storici)
Generalmente viene utilizzato lo “stato corrente” di un’applicazione
Operano su dati provenienti da più fonti eterogenee
Devono essere rispettate le proprietà ACID (atomicità, correttezza, isolamento, durabilità)
delle transazioni
Le proprietà ACID non sono rilevanti perché le operazioni sono di sola lettura
PROCESSO ETL - Tale processo rappresenta un passaggio fondamentale per la costruzione del Data Warehouse. All’interno di un’azienda sono presenti più sistemi che svolgono il ruolo di sorgente per il sistema di BI. Risulta quindi necessario effettuare l’estrazione dei dati da ognuno di essi, trasformarli in una forma che sia adatta per il DW, ed infine caricarli all’interno dello stesso. Questo processo è detto “Extract Transform and Load”. Esistono numerosi tools in commercio che consentono di eseguire tali operazioni, in ambito Microsoft lo strumento ETL messo a disposizione prende il nome di SQL Server Integration Services (SSIS) con una comoda interfaccia grafica o con semplici script in SQL Server. Esso è incluso con il DBMS SQL Server ed è in grado di gestire l’integrazione di differenti tipi di sorgenti, come DB Oracle, file di testo, XML, servizi Web e DB dello stesso SQL Server. Durante lo svolgimento di questo processo viene solitamente impiegata un’area intermedia, situata tra le sorgenti ed il DW, nella quale memorizzare i dati elaborati. Tale area prende il nome di “Staging” e può essere utilizzata anche per garantire un livello di fault-tollerance. Se, per esempio, fallisse la fase di trasformazione non sarebbe necessario eseguire nuovamente anche
l’estrazione in quanto i dati sono già stati riportati all’interno dell’area di staging. Ad eccezione di eventuali fallimenti durante la fase di ETL l’accesso a tale area deve essere effettuato esclusivamente per il caricamento dei dati all’interno del DW. Lo staging contiene infatti dati intermedi dell’elaborazione, per questo motivo se ne deve impedire l’accesso agli utenti finali. Di seguito verranno analizzate le quattro principali operazioni che costituiscono la fase di ETL riassunti nella seguente Figura 1.3.
ESTRAZIONE - Durante questa fase si effettua l’estrazione dei dati dalle sorgenti, per poi renderli disponibili per le successive elaborazioni. L’obiettivo principale del processo è quello di estrarre solamente i dati d’interesse con le minori risorse possibili. Come già anticipato il dettaglio delle informazioni presente in un database è molto maggiore rispetto a quelle necessarie per la valutazione del business, inoltre per garantire un certo livello di efficienza ed elevata interattività durante l’analisi è necessario estrarre solamente una ridotta parte delle informazioni. Tale operazione dovrebbe essere realizzata in modo tale da evitare delle ripercussioni negative sui sistemi in termini di performance o tempi di risposta. I tipi d’estrazione possibili sono i seguenti:
• Statica: vengono prelevati tutti i dati e rappresenta una fotografia delle informazioni contenute nelle sorgenti operazionali solitamente eseguita per il primo popolamento del DW;
• Incrementale: vengono estratti solamente i record che hanno subito modifiche dalla data di ultima estrazione. In questo caso è necessario mantenere informazioni sulla precedente estrazione, in modo tale da poter determinare quali record sono stati modificati. L’esecuzione può essere effettuata in modo immediato o ritardato.
PULITURA DATI - Rappresenta una fase intermedia del processo ETL. Essa gioca un ruolo molto importante in quanto ha l’obiettivo di aumentare la qualità dei dati. Durante questa fase vengono individuati tutti quei record che contengono dati “sporchi” e ne viene effettuata la correzione, così da garantire la consistenza delle sorgenti. I principali problemi che vengono riscontrati nei dati operazionali sono i seguenti:
• Dati duplicati; • Dati mancanti; • Dati errati;
TRASFORMAZIONE - Consiste nell’applicare usa serie appunto di trasformazioni ai dati, in modo tale da convertirli dal formato sorgente a quello destinazione. Le diverse sorgenti memorizzano informazioni in formato differente, di conseguenza per poter effettuare l’integrazione risulta necessario trasformare i dati in un formato uniforme. Le principali operazioni realizzate durante questa fase sono le seguenti:
• Conversione: le sorgenti relazionali potrebbero utilizzare formati differenti per la memorizzazione delle informazioni, è quindi necessaria un’operazione di conversione al fine di ottenere un formato uniforme;
• Integrazione: si effettua l’integrazione dei dati provenienti da sorgenti differenti;
• Aggregazione: i dati vengono aggregati ad un livello di dettaglio differente (solitamente su base mensile);
• Misure derivate: vengono calcolate nuove misure a partire da quelle già esistenti;
• Selezione: si seleziona un sottoinsieme dei campi contenuti nelle sorgenti, in modo tale da ridurre la quantità di dati da elaborare.
Caricamento - Rappresenta l’ultima fase del processo di ETL. I dati vengono caricati dal livello riconciliato, realizzato successivamente alla fase di
trasformazione, al DW finale.
Le modalità di caricamento sono principalmente due:
• Refresh/Full Process: Il DW viene ricaricato completamente. I vecchi dati vengono cancellati per lasciare spazio ai nuovi. Questa modalità viene solitamente utilizzata per effettuare il primo caricamento del DW;
• Update/Standard Process: Vengono caricati nel DW solamente quei dati che hanno subito una modifica dalla data dell’ultimo caricamento. I dati che
sono stati modificati non vengono cancellati o aggiornati, garantendo così la storicizzazione del DW.
Il principale obiettivo fondamentale di un sistema di BI è quello di consentire l’analisi dei dati ed il reporting degli stessi. Questi obiettivi portano alla definizione di una struttura dedicata ai DW. Come già anticipato, i sistemi operazionali vengono costruiti rispettando i criteri della normalizzazione, che garantiscono una maggior efficienza riducendo per esempio la ridondanza dei dati. Un database potrebbe avere tabelle con un numero elevato di relazioni. Di conseguenza la realizzazione di un report su un sistema di questo tipo potrebbe rallentare l’esecuzione della query dato l’elevato numero di join necessari per recuperare le informazioni. La struttura di un DW viene
appositamente progettata per evitare questo tipo di inconvenienti, riducendo i tempi di risposta ed incrementando le performance delle query per il reporting e l’analisi dei dati. Il modello con il quale viene costruito un DW prende il nome di modello multidimensionale.
MODELLO MULTIDIMENSIONALE
Il modello Entity-Relationship (ER) tradizionalmente utilizzato per la progettazione concettuale di database, non può essere adottato come fondamento per la realizzazione di DW. Tale modello non risulta adatto in quanto è di difficile comprensione agli utenti e non può essere navigato
efficacemente dai DBMS”. Esso descrive la struttura del dominio applicativo e le relative associazioni, ma non esprime concetti come la multidimensionalità o la gerarchia dei livelli di aggregazione. Per risolvere tali problematiche viene utilizzato un formalismo che prende il nome di “Dimensional Fact
Model” (DFM). Il DFM è un modello concettuale grafico, pensato appositamente per la modellazione multidimensionale, con l’obiettivo di: • Fornire pieno supporto alla progettazione concettuale;
• Rendere disponibile un ambiente nel quale effettuare query in modo intuitivo;
• Facilitare la comunicazione tra progettista ed utente finale;
• Costruire una piattaforma per la progettazione logica. Tale modello è infatti indipendente dal modello logico utilizzato.
Figura 1.4: Rappresentazione astratta di un cubo multidimensionale DFM
In Figura 1.4 viene mostrata la rappresentazione grafica di un cubo DFM. Esso consiste in un insieme di schemi di fatto, i cui elementi costitutivi sono i seguenti:
• Fatto: concetto di interesse per il processo decisionale che modella un insieme di eventi che si verificano all’interno della realtà aziendale. Ogni fatto è descritto da un insieme di misure ed esprime un’associazione molti a molti tra le dimensioni. Questa relazione è espressa da un “evento primario”, ovvero da un’occorrenza del fatto. Nei DFM viene rappresentato con un box rettangolare che ne specifica il nome e con all’interno le misure d’interesse;
• Misura: proprietà numerica di un fatto che descrive un aspetto quantitativo di interesse per l’analisi. Un fatto può anche non contenere alcuna misura, in questo caso si registra solamente il verificarsi dell’evento;
• Dimensione: proprietà, con dominio finito, che descrive una coordinata d’analisi di un fatto. Ogni fatto contiene generalmente più dimensioni che ne definiscono la granularità, ovvero l’evento di massimo dettaglio analizzabile. Nella Figura 1.4 le dimensioni sono prodotto, giorno e negozio per un esempio applicativo. L’informazione elementare è rappresentata dalle vendite di un prodotto effettuate in un negozio in un dato giorno;
• Attributo dimensionale: proprietà, con dominio finito, di una dimensione. Un prodotto può avere un fornitore ed un tipo. Le relazioni tra attributi dimensionali sono espresse dalle gerarchie;
• Gerarchia: albero direzionato in cui i nodi sono attributi dimensionali e gli archi rappresentano associazioni “Molti a Molti” tra coppie di attributi dimensionali. Una gerarchia include la dimensione, come radice dell’albero e tutti gli attributi che la descrivono. Essa definisce il modo in cui i dati
possono essere aggregati per fornire supporto durante il processo decisionale.
La struttura che meglio si adatta alla rappresentazione di dati
multidimensionali è il cubo. Tale modello utilizza le dimensioni come coordinate d’analisi, mentre ogni cella contiene le misure del fatto. Queste ultime registrano i valori delle misure per ogni occorrenza di un evento
primario. Ogni cubo che ha un numero di dimensioni superiore a tre prende il nome di ipercubo.
La modellazione multidimensionale contrasta con il formato relazionale utilizzato nelle sorgenti. Per rappresentare dati multidimensionali in database relazionali esistono due differenti schemi evidenziati in Figura 1.5:
• Star schema: la tabella dei fatti si trova al centro dello schema e le dimensioni sono collegate ad essa tramite relazioni di un solo livello;
• Snowflake schema: può contenere delle relazioni in cui una dimensione è collegata ad una tabella dei fatti per mezzo di una dimensione intermedia. Tale schema risulta similare alla forma normalizzata, pertanto saranno
richiesti un maggior numero di join per rispondere ad una query, rendendolo più lento e meno preferibile rispetto allo schema a stella. Ovviamente non sempre è possibile realizzare uno schema a stella senza operazioni di snowflake, tuttavia come “best practice" sarebbe preferibile evitare lo snowflake quando non è strettamente necessario.
Figura 1.5: Esempio di “Star” Schema e “Snowflake” Schema.
MODELLO ED ANALISI DEI DATI
Un DW svolge il ruolo di sorgente per l’analisi dei dati ed il reporting, di conseguenza opera più velocemente di un normale sistema relazionale. Esso tuttavia non risulta essere così veloce da soddisfare tutte le esigenze, perché rimane comunque un database relazionale. Per risolvere questo problema e garantire un ottimo rapporto tra velocità d’elaborazione e tempo di risposta alle query è necessario introdurre un ulteriore livello in un sistema di BI. Questo nuovo livello prende il nome di “modello dei dati”, contiene un modello basato su file o su memoria dei dati ed ha lo scopo di fornire risposte
veloci durante l’esecuzione delle query. La suite Microsoft, successivamente utilizzata nel nostro caso di studio offre due diverse modellazioni dei dati: • Formato multidimensionale con cubo OLAP: struttura che archivia i dati su
file caricandoli dal DW in un modello dimensionale. Tale struttura cerca di precalcolare le differenti combinazioni di dimensioni e fatti in modo tale da consentire un’elevata interattività, consentendo agli utenti di aggiungere o rimuovere attributi in base alle analisi necessarie. Questo modello mette a disposizione diverse operazioni come il “Roll-Up” o “Drill-Down”, grazie al quale è possibile navigare i dati da punti di vista differenti. Il processo d’analisi è anche detto “Online Analytical Processing” (OLAP), in quanto garantisce un elevato livello d’interattività agli utenti;
• Formato tabulare in memoria: questo secondo modello consiste nel caricare i record delle tabelle d’analisi in memoria, eseguendo la query direttamente su quest’ultima. Tale struttura risulta essere molto veloce dal punto di vista dei tempi di risposta, ma è richiesta anche un’elevata capacità di
memorizzazione che non sempre è disponibile.
I capitoli successivi verteranno proprio sul processo di migrazione da un modello standard multidimensionale OLAP ad un modello in formato tabulare. L’analisi dei dati rappresenta la parte “Front-End” di un sistema di BI. Rimanendo nel contesto di sviluppo Microsoft esistono differenti modalità con la quale analizzare le informazioni provenienti dal sistema. Una prima tecnica consiste nell’utilizzare lo strumento Excel, in esso è presente la possibilità di connettersi ad un cubo OLAP e di effettuare analisi libere, inserendo indicatori e informazioni descrittive a piacimento o variando il livello di dettaglio dell’analisi. La suite Performance Point, come parte dello strumento Microsoft SharePoint, consente di creare dashboard avanzate e garantisce ottime prestazioni se utilizzato in accoppiata con un cubo OLAP. Un altro tool molto importante è Microsoft SQL Server Reporting Services (SSRS), che consente la creazione avanzata di report a partire da diverse origini dati.
2.3 DALLA BUSINESS ALLA FINANCE INTELLIGENCE E REALIZZAZIONE DI SOFTWARE CPM
Come detto precedentemente, il termine “business intelligence" allude ad un campo molto ampio di attività, sistemi informativi aziendali e tecnologie informatiche finalizzate a supportare, automatizzare processi di misurazione, controllo e analisi dei risultati e delle performance aziendali e processi di decisione aziendale in condizioni variabili di incertezza il tutto integrato nel classico processo generale di "misurazione, analisi, decisione, azione”. Gli obiettivi e relativi sviluppi del caso di studio corrente, sono prettamente legati al contesto lavorativo riguardante nell’azienda ospitante.
Tra i diversi settori informatici ed economici ci focalizzeremo sul tema della “Finance Intelligence”, la combinazione tra la Business Intelligence e la finanza aziendale, settore che si occupa di analizzare gli investimenti
includendo la dinamica delle attività e delle passività nel tempo in condizioni di diversa incertezza e rischio. Quindi, la Finance Intelligence è un tipo
di business intelligence costituito dalle conoscenze e competenze acquisite dalla comprensione dei principi finanziari e contabili nel mondo del business. È emersa come una “best practice” e competenza fondamentale in molte organizzazioni che hanno portato a risultati finanziari migliori. Strumento per le aziende che può essere utilizzato sia per un approccio difensivo che
proattivo.
Le attività di analisi della Finance Intelligence difensiva proteggono
l’organizzazione identificando i comportamenti a rischio (il cliente che effettua grandi investimenti senza i fondi necessari per sostenerla) e le transazioni sospette (come quelle con i paesi o le organizzazioni della lista nera) prima che abbiano la possibilità di ferire l’azienda. Un approccio difensivo è importante, ma è solo una parte di una solida strategia di intelligence finanziaria.
proteggere i beni da rischi e frodi. Tale approccio comporta una visione unificata delle informazioni alla velocità degli eventi in tempo reale. Permette di intercettare segnali e tendenze deboli prima che diventino realtà.
Le attività di monitoraggio delle attività per i concorrenti e le tendenze del mercato sono in grado di sfruttare tutti i tipi di dati finanziari e flussi di notizie per il loro valore di intelligence. Estraendo e correlando automaticamente queste informazioni, altrimenti impossibili da analizzare manualmente, gli analisti possono scegliere se e come modificare le loro decisioni d'investimento o con chi fare affari con largo anticipo.
Aziende IT che supportano clienti per bisogni e tali necessità, svolgono attività come la creazione di un datamart finanziario strutturato utilizzabile come base d’integrazione con sistemi Data Warehouse aziendali e con strumenti di analisi dati per il reporting direzionale in progetti di Business Intelligence.
Attualmente, molte organizzazioni IT, come l’azienda ospitante, includono programmi di Finance Intelligence nel loro curriculum di sviluppo realizzando software di analisi per le performance aziendali chiamati genericamente CPM (Corporate Performance Management), o EPM (Enterprise Performance Management), BPM (Business Performance Management), SPM (Strategic Performance Management).
Utilizzando la definizione di Gartner, la gestione delle perfomance aziendali è: «l’insieme dei processi, metodologie, metriche e sistemi finalizzati a misurare e gestire le performance di un’organizzazione. Sono quindi comprese
le metodologie di Budgeting, Planning e Forecasting, Analisi di Profittabilità e Ottimizzazione, Dashboard e Scorecard, Consolidamento e Reporting
Civilistico, Gestionale e Finanziario».
Il CPM è l’area coinvolta nel monitoraggio e nella gestione delle performance di un’organizzazione, secondo gli indicatori definiti “Key Performance
Indicator” (KPI) quali ricavi, ritorno sull'investimento (ROI), costi generali e costi operativi.
per essere utilizzato a livello aziendale, spesso come complemento ai sistemi di business intelligence. Esso si compone di due parti: CPM operativa e CPM analitica. La prima risponde alle necessità tipiche dei manager del settore della finanza mentre la seconda è rivolta alle esigenze di analisi e reportistica di dirigenti che lavorano in tutti i livelli dell’organizzazione.
Tale software include funzioni di previsione, budgeting e pianificazione, metodologie di gestione consolidate, oltre a report per visualizzare e fornire informazioni aziendali. Un'interfaccia CPM solitamente visualizza cifre per gli indicatori chiave di performance in modo che i dipendenti possano tenere traccia delle prestazioni individuali e dei progetti in relazione agli obiettivi e alle strategie aziendali.
3 CASO DI STUDIO
3.1 AZIENDA OSPITANTE
CCH Tagetik viene fondata nel 1986 come una società di consulenza informatica con sede a Lucca. Con la crescita della società, il fondatore ha colto l’opportunità di modernizzare e semplificare i processi di business dell’area Finance a livello locale e globale. Nel 2005 viene lanciato il brand Tagetik e sin da allora è riconosciuta come una soluzione specializzata nella gestione integrata di Corporate Performance Management (CPM) e
Governance finanziaria tale da garantire consistenza e affidabilità dei dati secondo la logica della tracciabilità della partita doppia e del “financial closed-loop” (metodo per la tracciabilità delle operazioni finanziarie).
Grazie ai processi built-in è in grado di rispondere sia alla conformità sia alle problematiche più complesse (Governance and Risk Management).
È in grado di unificare tutti i processi CPM attraverso diverse funzionalità: • Core CPM Processes (budgeting, planning e forecasting, analisi di
profittabilità e ottimizzazione, dashboard e scorecard, consolidamento, reporting civilistico, gestionale e finanziario);
• Extended CPM Processes (analisi del credito e reporting, ICT performance management);
• Vertical CPM Processes (accounting regolatorio per il settore Telco o Energy, cash flow di commessa per il settore Construction & Engineering, vigilanza per il mondo finanziario).
Attualmente Tagetik entra a far parte di “Wolters Kluwer”, leader mondiale nel fornire soluzioni software, informazioni e servizi per il mondo dei
Adesso all’interno della Business Unit Wolters Kluwer Corporate Performance Solutions, l’azienda continuerà a focalizzarsi sullo sviluppo di soluzioni
innovative sempre per l’area Finance.
Data la partership con l’azienda Microsoft, i tool utilizzati nelle aree di sviluppo aziendali sono Excel, Word e PowerPoint per i modelli di input e report con connettori a Microsoft PowerBI, SharePoint, SQL Server,
Dynamics AX e NAV. Riepilogando, possiamo dire che, i principali settori di competenza dell’azienda sono la Business Intelligence & Data Warehouse per la progettazione e realizzazione di sistemi completi di BI nelle diverse aree aziendale prettamente finanziarie, mediante implementazione di piattaforme orientate alla gestione di grandi volumi di dati attraverso l’adozione delle migliori tecnologie di mercato Microsoft, con lo sviluppo della Corporate Performance Management per progetti di pianificazione strategica, di budgeting, reporting e analisi delle performance aziendali.
3.2 AMBIENTE E STRUMENTI DI SVILUPPO
Per la realizzazione del progetto si è resa necessaria un’apposita infrastruttura hardware e software interna all’azienda. Grazie alla partnership esistente tra l’azienda ospitante ed il cliente con la possibilità di utilizzare la stessa
configurazione hardware adottata in passato in altri progetti. La stessa strategia è stata applicata per la scelta dello strumento software, adottando la grande suite Microsoft. I motivi di tale scelta sono molteplici:
• l'area Finance si avvale di soluzioni usando gli strumenti Microsoft, quindi Tagetik ottimizza gli investimenti in tecnologie con tale partnership, restituendo un costo inferiore derivandone un valore finale maggiore. • Essendo altri progetti realizzati con strumenti Microsoft risulta più facile
• Sono semplificati gli sviluppi per i dipendenti dell’azienda, che potranno lavorare con strumenti di cui conoscono le funzionalità, garantendo una migliore qualità del servizio. Infine si forniscono agli utenti finali strumenti standard per la reportistica, in modo tale da rendere le analisi più veloci ed efficienti.
3.3 CONFIGURAZIONE HARDWARE & SOFTWARE
L’infrastruttura hardware utilizzata per il progetto è replicata per due differenti ambienti:
• Sviluppo: ambiente che contiene tutti i server per effettuare lo sviluppo dei progetti ed il testing. Ad esso accedono principalmente gli sviluppatori aziendali, ma possono accedere anche gli utenti finali per testare modifiche particolarmente critiche prima che vengano portate in produzione.
Periodicamente vengono mandati in esecuzione i sistemi di BI esistenti per effettuare l’allineamento dei dati rispetto all’ambiente di produzione. In questo ambiente viene anche mantenuto lo storico dei rilasci in modo tale da riportare i sistemi ad uno stato consistente in caso di errori;
• Produzione: contiene tutti i server che ospitano i sistemi attualmente utilizzati dall’azienda cliente. L’aggiornamento dei dati viene effettuato periodicamente, le attività vengono schedulate in precisi intervalli di tempo in modo tale da evitarne la sovrapposizione ed il conseguente rallentamento nell’esecuzione. Dato che questo ambiente viene utilizzato dagli utenti finali i dati hanno un’elevata criticità, pertanto è fondamentale garantirne sempre la consistenza.
Figura 1.6: Infrastruttura Hardware
In Figura 1.6 viene mostrata l’infrastruttura utilizzata per entrambi gli
ambienti. La connessione alla rete aziendale interna viene effettuata per mezzo di una VPN ad accesso remoto. Questo meccanismo consente agli utenti che lavorano da casa o in movimento di accedere ai server presenti in una rete privata utilizzando l’infrastruttura resa disponibile da una rete pubblica. L’organizzazione di quest’ultima è irrilevante, dal punto di vista logico è come se i dati venissero inviati su un collegamento privato dedicato. I server utilizzati per il progetto sono i seguenti:
• Active Directory Server: macchina che gestisce l’autenticazione degli utenti alla rete privata ed ai relativi server. Una volta che l’utente è autenticato può accedere alle risorse disponibili in rete. Vengono utilizzati due domini
differenti a seconda dell’ambiente a cui si accede. In questo modo è possibile separare non solo fisicamente ma anche logicamente i due ambienti;
• Database Server: macchina che gestisce le sorgenti relazionali di tutti i progetti con l’azienda cliente. Essa contiene i database dell’area di staging realizzati durante la fase di ETL ed i DW sulla quale vengono costruiti i cubi finali OLAP;
• ETL Server: gestisce tutti i flussi ETL dei progetti con l’azienda cliente. Sulla macchina i flussi vengono schedulati con modalità giornaliera e precisi intervalli temporali, sulla base delle esigenze progettuali e del momento della giornata nella quale i dati da caricare vengono resi disponibili. Tutte le
modifiche ad un flusso vengono svolte e testate in ambiente di sviluppo, pertanto affinché le sorgenti siano aggiornate è necessario effettuarne il deploy in produzione;
• OLAP Server: macchina che ospita il modello dei dati ottimizzato per l’analisi. Come nel caso dei server precedenti in esso sono contenuti tutti i progetti attivi con l’azienda cliente. Il server contiene due diverse istanze per l’analisi dei dati: multidimensionale (cubo OLAP) o tabulare. A seconda delle necessità è quindi possibile scegliere l’istanza più adatta, per il progetto in esame, a partire da un’analisi del modello multidimensionale è stata scelta la modellazione in istanza tabulare. Per effettuare le analisi gli utenti possono utilizzare gli strumenti che supportano la connessione all’istanza. Il software utilizzato dall’azienda cliente per la reportistica e per l’analisi è Microsoft Excel, che si integra nativamente con gli altri strumenti di proprietà Microsoft utilizzati nel progetto, con alcune componenti aggiuntive di proprietà Tagetik che permettono una maggiore personalizzazione dei report report aziendali a seconda delle esigenze del cliente;
• Terminal Server: macchina alla quale i dipendenti Tagetik si collegano in accesso remoto. Tale server viene utilizzato per l’amministrazione, la gestione e lo sviluppo di tutti i progetti con il cliente. Da esso, utilizzando SQL Server Management Studio (SSMS), è possibile connettersi agli altri server e svolgere le operazioni opportune;
• Web Server: macchina che ospita il software CPM realizzato per l’uso finale da parte del cliente per scopi aziendali.
Dal punto di vista software, sono stati adottati i seguenti tool Microsoft:
• SQL Server Management Studio (SSMS) - include l’accesso ed analisi su cubi di Analysis Service e tutti quegli strumenti che consentono di eseguire la fase di ETL tramite Script elaborati in SQL Server direttamente eseguiti tramite lettura delle sorgenti operazionali.
• Visual Studio - In generale utilizzato per la creazione del modello tabulare e multidimensionale in istanza di SQL Server Analysis Service.
• Excel & PowerBI - In fase di reporting per la definizione ed esecuzione query.
• SQL Server Profiler - Per analizzare le varie esecuzione query in fase di testing delle performance sul modello.
Successivamente sono fornite delle descrizioni maggiori delle componenti utilizzati all’interno del progetto.
Microsoft SQL Server
SQL Server è il DBMS relazionale prodotto da Microsoft e utilizzato per la realizzazione del processo di data warehousing e della piattaforma di business intelligence. L’edizione utilizzata per questa implementazione è la 2014, che, nella versione Enterprise, offre una serie di strumenti tra cui software di integrazione dati, analisi e reportistica avanzata.
Microsoft SQL Server Management Studio (SSMS)
Offre un ambiente per la gestione dei modelli di Data Mining e cubi OLAP già esistenti in un database Microsoft SQL Server Analysis Services. È possibile utilizzare Management Studio per connettersi a un database di Analysis Service in modo tale da poter eseguire e completare le seguenti attività:
• Elaborazione e sfogliare e gestire gli oggetti di Analysis Service, come cubi, dimensioni e modelli Mining.
• Creare estensioni di estrazione dati tramite linguaggio (DMX), espressioni multidimensionali (MDX) e query XML per analisi (XMLA).
• Creare script che modificano, creano o eliminano oggetti di Analysis Service. • Gestisci i database di Analysis Service.
Tale strumento comprende le seguenti diversi componenti:
• Registered Servers - Tale pannello mantiene le connessioni ai server che sono state utilizzate.
Attraverso ogni connessione è possibile controllare lo stato del server o gestire i suoi oggetti. Per ogni utente viene mantenuta una lista locale dei server alla quale si è connesso.
• Object Explorer - Componente che fornisce una vista ad albero di tutti i database contenuti all’interno di un server. L’albero è organizzato in forma gerarchica, di conseguenza espandendo ogni ramo è possibile scorrere la struttura logica del server. All’interno della stessa interfaccia è possibile connettersi a più server contemporaneamente, anche a quelli di tipo differente rispetto all’attuale connessione.
Le operazioni principali che consente di realizzare tale strumento sono la connessione, esecuzione ed arresto di un server, la creazione di un database e gestione delle relative tabelle.
• Query Editor - Tramite questo componente è possibile eseguire, sui database ai quali si è collegati, differenti tipi di query. Per default la nuova query che viene creata è di tipo relazionale, ma ne esistono di altri tipi, come DAX, MDX o XMLA. Per potere eseguire una nuova interrogazione è necessario connettersi al server e specificare il database che si vuole interrogare.
• Solution Explorer - Questo componente consente di organizzare le interrogazioni effettuate sui database sotto forma di progetti. Quando un nuovo progetto viene creato esso memorizza informazioni relative alle
connessioni ed alle query effettuate. In questo modo si organizza il lavoro svolto in progetti, con la possibilità di unire in un’unica soluzione quelli logicamente correlati.
Visual Studio - SQL Server Data Tools
È un moderno strumento di sviluppo, parte integrante della suite Visual Studio, per compilare database relazionali SQL Server, database Azure SQL, pacchetti di Integration Services, modelli di dati di Analysis Services e report di Reporting Services. Con SSDT è possibile progettare e distribuire qualsiasi tipo di contenuto SQL Server con la stessa facilità con la quale si sviluppa un'applicazione in Visual Studio.
• SQL Server Integration Services (SSIS) - È uno strumento professionale molto diffuso per l’integrazione, trasformazione e migrazione dei dati; consente di connettersi verso un elevato numero di sorgenti dati differenti e, per questo motivo, viene spesso impiegato nel processo di data warehousing, in particolare durante le fasi di ETL. Ciascun workflow generato può essere eseguito manualmente mediante l’esecuzione di funzioni e procedure o in maniera automatizzata sfruttando l’agent di SQL Server.
• SQL Server Analysis Services (SSAS)- È un servizio che viene usato per gestire dati memorizzati in un DW o data mart. La struttura usata per l’organizzazione dei dati è il cubo multidimensionale che effettua
aggregazioni e consente l’esecuzione, in modo efficiente, di report e query complesse. I sistemi analitici utilizzano solitamente le architetture Relational OLAP (ROLAP), Multidimensional OLAP (MOLAP) e Hybrid OLAP (HOLAP) per la memorizzazione dei dati multidimensionali.
Le tre architetture si differenziano per il modo in cui memorizzano i dati a livello foglia e precalcolano gli aggregati. In ROLAP non vengono
mantenuti dati precalcolati. Durante l’esecuzione delle query si effettua l’accesso ai dati della sorgente relazionale e si recuperano quelli d’interesse.
aggregazioni vengono mantenute in un cubo multidimensionale. In caso di memorizzazione in un cubo una certa quantità di dati dovrà essere duplicata. Con ROLAP non sarà necessario spazio addizionale per dati replicati.
Inoltre il calcolo delle aggregazioni può essere eseguito in modo rapido utilizzando viste indicizzate. Utilizzando MOLAP alcune aggregazioni vengono precalcolate e memorizzate in formato multidimensionale. Il sistema non dovrà impiegare altro tempo per calcolare tali aggregazioni. Inoltre in MOLAP il database ed il relativo motore sono ottimizzati per lavorare insieme, di conseguenza la risposta alle query sarà generalmente più veloce. HOLAP è un formato ibrido che combina le due architetture
descritte in precedenza. Le aggregazioni vengono memorizzate come in HOLAP, mentre le foglie vengono lasciate in formato relazionale. Il principale vantaggio di HOLAP è la non ridondanza del livello foglia. • SQL Server Reporting Services (SSRS)- È un software di reportistica che
consente di generare e distribuire report in maniera semplice e intuitiva a tutti gli utenti della rete aziendale. SQL Server Reporting Services si compone di un pannello di amministrazione e uno strumento per la
creazione e la modifica dei report. L’accesso al pannello di amministrazione avviene tramite interfaccia web mentre la generazione d e i report può avvenire per mezzo di un tool grafico, il Report Builder, o sfruttando l’editor testuale integrato in Visual Studio. Nella sezione amministrativa è possibile gestire le utenze e i livelli di sicurezza, basati sui ruoli; è possibile indicare quali utenti possono visionare un determinato report, il livello di dettaglio e impostare i permessi di lettura sul singolo record. In ogni caso, i report generati con Reporting Services sono perlopiù report statici; l’interazione da parte dell’utente finale è limitata all’applicazione di filtri e operazioni di ordinamento dati.
Excel e Power BI
Microsoft Excel è un software di calcolo prodotto da Microsoft che, fin da subito, ha riscosso un gran de successo sia in ambito aziendale che domestico. È attualmente il software di produttività più utilizzato dalle aziende ed è impiegato in un numero di settori sempre più crescente.
Tra la miriade di funzionalità a disposizione dell’utente finale, Excel consente di impostare una connessione dati verso un server Analysis Services; per mezzo di una semplice tabella pivot è quindi possibile esplorare i dati presenti all'interno di un Data Warehouse. A partire da essa l’utente finale è in grado di eseguire le classiche operazioni di pivoting, drill-down e roll-up, slice e dice sui dati del modello OLAP combinando in modo opportuno le misure con le dimensioni di analisi.
Power BI estende le funzionalità presenti in Excel fornendo un insieme di strumenti di analisi e condivisione dei dati in tempo reale e altamente
personalizzabili. Si tratta di un servizio innovativo che consente di pubblicare report all’interno dell’organizzazione unificando diverse origini dati in un’unica dashboard interattiva. È un approccio basato interamente su tecnologie cloud e, per questo motivo, molte aziende decidono di astenersi dal suo utilizzo per salvaguardare la privacy dei propri clienti.
SQL Server Profiler
È un software con interfaccia grafica per il monitoraggio di tracce SQL di un'istanza database o di Analysis Services. È possibile catturare e salvare i vari log sul lancio delle query in un file esterno. Utile per il monitoraggio e l’analisi di query che presentano maggior rallentamenti durante l’esecuzione.
3.4 SSAS TABULAR & MULTIDIMENSIONAL
Per molti anni Microsoft è stato leader di mercato nella tecnologia OLAP per analisi interattive e veloci di grandi quantità di dati. Tuttavia, negli ultimi cinque anni, sono entrati nuovi competitor nel mercato della Business Intelligence che hanno fornito strumenti con interfacce utente molto interattive e grafiche costruite su architetture “in-memory” e associative paradigmi in termini di selezione dei dati nell'analisi, che affrontano la semplicità di utilizzo e la rapida implementazione degli utenti aziendali. Questi strumenti sono diventati molto popolari e altamente concorrenziali per Microsoft specialmente nel segmento business di medie dimensioni.
Il modello multidimensionale, in passato, era l'unica soluzione per creare database multidimensionali, per soluzioni di BI Microsoft e tale software non è stato alterato molto da SQL Server 2005 a SQL Server 2016.
Nel 2012, come parte di SQL Server 2012, un nuovo prodotto chiamato modello Tabulare, viene aggiunto alla soluzione di SQL Server mirato per competere con i nuovi strumenti "in-memory" alternativi includendo diverse funzionalità con un approccio completamente nuovo della BI Analytics multidimensionale.
A partire da SSAS 2012 troviamo due prodotti e modulazioni differenti: • Il modello Tabular (In-Memory Cube). I modelli tabulari sono database in
memoria in Analysis Services. Utilizzando algoritmi di compressione all'avanguardia e l'elaborazione delle query multi-threaded, il motore Xvelocity offre un rapido accesso agli oggetti e ai dati del modello tabulare attraverso le applicazioni client di reporting quali Microsoft Excel e
Microsoft Power View.
• Il modello Multidimensionale (Cubo OLAP tradizionale). Questo modello è il cubo OLAP che già esiste da diversi anni. La tecnologia OLAP organizza dati di sintesi in strutture multidimensionali. Le aggregazioni sono
memorizzate nella struttura multidimensionale nelle cellule alle coordinate specificate dalle dimensioni.
Questi due modelli hanno lo stesso obiettivo, ovvero, fornire uno strato semantico in cima al Data Warehouse con funzionalità ad alte prestazioni che consentono, agli utenti finali, di effettuare reportig sui dati. In un primo impatto entrambe le tecnologie possono sembrar simili e facilmente intercambiali tra loro ma nella realtà pratica sono due prodotti altamente complessi e differenti. Essi possono coesistere sulla stessa macchina ma con strutture differenti.
4 MULTIDIMENSIONAL DATA MODEL
4.1 CORPORATE PERFORMANCE MANAGEMENT (TAGETIK 5) Per poter gestire e soddisfare le varie esigenze dei clienti, Tagetik, azienda globale nel mercato delle soluzioni software per il Performance Management, il Disclosure Management, la Financial Governance e la Business Intelligence, progetta una soluzione CPM (Corporare Perfomance Management)
completamente finanziaria per poter fronteggiare l’alta competitività in ambito IT chiamata “Tagetik 5”.
Il prodotto finale, offerto ad aziende cliente, è sottoposto periodicamente ad aggiornamenti a partire dal modello Data Warehouse, cuore del software, che per semplicità definiremo “Multidimensional Data Model”.
Tagetik versione 5, è una soluzione finanziaria per i propri clienti a doppio ingresso closed-loop, che unisce in un unico prodotto tutto il Corporate Performance Management, inclusi tutti i processi core, estesi, verticali e i processi di Financial Governance. Dispone di processi integrati e funzionalità estese che offrono alle aziende la possibilità di garantire la conformità,
utilizzano il medesimo database per diverse applicazioni.
Aiuta a massimizzare l’efficienza del processo e migliora sia la visibilità che la trasparenza dei dati. Offre i mezzi per sfruttare gli investimenti tecnologici esistenti. Supporta piattaforme multiple e architettura aperta fornendo al contempo interfacce dirette con i sistemi ERP più comunemente utilizzati e permette di gestire diversi tipi di prodotti e processi applicativi.
La struttura dati di un cliente viene connessa con il software CPM offrendo usabilità, mobilità, velocità e flessibilità durante l’utilizzo dello stesso da parte dei clienti. Gli utenti, utilizzatori finali, possono facilmente realizzare soluzioni aziendali e modelli previsionali di gestione delle prestazioni aziendali
Questo permette alle aziende cliente di ridurre il Total Cost of Ownership (TCO) grazie alla modernizzazione dei processi di budgeting e pianificazione, alla riduzione del numero dei giorni necessari per le chiusure mensili e il ciclo di consolidamento, all'accelerazione dei tempi di tutte le attività finanziarie e al “disclosure management”, nonché alla generazione estremamente semplice di report di gestione e analisi avanzate. CCH Tagetik offre una soluzione
unificata per il Corporate Performance Management, cloud e on-premise, ideata appositamente per l'area “Amministrazione, Finanza e Controllo”. “Gartner”, azienda leader mondiale nella ricerca e consulenza in materia dell’IT, spiega che i processi di base CPM sono:
• Budgeting, pianificazione e previsioni
• Modellazione e ottimizzazione della redditività • Consolidamento Finanziario
• Relazione finanziaria, statutaria e di gestione, con applicazioni come Dashboard e Scoreboard.
È significativo notare nella definizione di Gartner non sono inclusi processi CPM estesi come il Credit Reporting & Analysis, la gestione delle performance ICT o i processi CPM verticali chiave, come la disaggregazione normativa per i settori Energy & Telco, il flusso di cassa per progetto, per i settori di Edilizia e Ingegneria o la rendicontazione regolamentare per il settore dei servizi
finanziari. Tagetik 5 non solo fornisce i processi di base definiti da Gartner, ma i suoi sofisticati processi integrati coprono anche i processi CPM estesi e verticali. In più, lo strumento per l’estrazione, trasformazione e caricamento dei dati (ETL predefinito) consente di leggere i dati da qualsiasi fonte di dati, come i sistemi Enterprise Resource Planning (ERP). I dati possono essere caricati in Tagetik o esportati in un altro Database o file. La raccolta dati permette di gestire in modo distribuito i dati, nonché un processo di
approvazione e rifiuto. Il processo presente nel software, definito “Closing & Allocation”, ovvero l’insieme delle operazioni di chiusura e regolazioni
finanziarie, consente la gestione della chiusura periodica con regolazioni automatiche con un potente motore di allocazione. Il processo di chiusura finanziaria è completamente automatizzato, supportando l'analisi dei risultati dei sistemi ERP e di consolidamento, la correzione e l'adeguamento delle scritture contabili e la generazione di moduli finanziari, garantendo form finali accurati e riducendo i rischi ad errori.
Il processo di pianificazione del flusso di cassa, facilita la generazione del bilancio e la previsione dei flussi di cassa, gestendo le regole di pagamento in entrata e in uscita associate alle singole voci di bilancio utilizzando la logica contabile. I modelli integrati generano automaticamente previsioni accurate sulle attività e sui flussi di cassa.
Inoltre, il processo di consolidamento consente la selezione del metodo e dell'area di consolidamento, la conversione valutaria, l'elaborazione automatica delle rettifiche di consolidamento, il controllo diagnostico e la redazione delle note illustrative.
La soluzione web-based e la sua interfaccia user friendly consentono a tutti gli utenti di svolgere un ruolo attivo in ogni fase del processo. Offre infatti un ambiente tecnologico scalabile e facile da implementare, gestire e mantenere, aumentando l'affidabilità e la qualità dei dati.
Il software, definito come un’architettura aperta, include un database aperto per l’input e l’output da e verso diverse fonti di dati. È attuato in Java, basato su un’architettura “Service - Oriented”. La multipiattaforma uniforma gli ambienti tecnologici esistenti, supporta database e server applicativi ampiamente utilizzati, database relazionali e Data Warehouse leader nella memorizzazione dei dati. Ha un’unica piattaforma unificata, applicazione, database e interfaccia. La Graphical User Interface (GUI) include una ricca applicazione utente e garantisce un'interfaccia standard su tutti i browser; fornisce inoltre funzionalità grafiche avanzate grazie a HTML5 e Adobe Flex. Tutte le attività, compresa la raccolta dei dati, l'amministrazione del sistema e dell'applicazione, il consolidamento, ecc. possono essere eseguite utilizzando
un browser web ed è indipendente dalla piattaforma: può essere installato su tutti i principali database e server applicativi come ad esempio Oracle e MS SQL Server e gestito contemporaneamente da molti utenti in tutto il mondo. 4.2 CORSO DI FORMAZIONE
Per raggiungere gli obiettivi della tesi, è stato indispensabile partecipare ad un corso realizzato all’interno della struttura aziendale predisposto per futuri clienti utilizzatori del software CPM e per tirocinanti interni.
Tra i diversi programmi di formazione è stato utile partecipare al corso
“Foundation & Reporting” disponibile per tutti coloro che sono interessati ad avere specifiche nozioni sul modello Data Warehouse correntemente utilizzato per comprenderne al meglio l’architettura interna, tecniche utili e pratiche in fase di ETL e possibili template esecutivi di istanze in fase di Reporting. 4.3 ARCHITETTURA DEL MODELLO DATA WAREHOUSE
Il modello, contiene una repository centralizzata per la gestione degli utenti (futuri utilizzatori del software CPM) e dei ruoli ad una o più applicazioni. Il modello quindi permette l’utilizzo del software da parte di clienti differenti e ogni cliente, mediante l’utilizzo dello stesso, realizza soluzioni di Business Intelligence per specifiche istanze definite applicazioni Database o istanze applicative.
Il Repository centralizzato:
• Contiene Utenti e Ruoli (sia standard che personalizzati) che specificano i diritti “funzionali” di ogni Utente (funzionalità visibile e nascoste per ogni specifico utente).
• Mostra la connessione tra un utente, un database applicativo e il loro ruolo.
Ogni database applicativo:
• Può gestire tutti i processi integrati
• È una istanza multidimensionale specifica del sistema
• Include dimensioni del sistema e dimensioni personalizzate e dati del cliente.
Ogni database applicativo ha un set unico di dimensioni del sistema e dimensioni personalizzate che possono elaborare uno o diversi processi integrati. Ogni banca dati delle applicazioni è un piccolo set di dati che può rappresentare un’applicazione di bilancio o di consolidamento per un cliente. Tali applicazioni sono definite in modo distinto e separato, ad esempio
un’applicazione come quella di budgeting può avere processi di base, raccolta & reporting dei dati, ETL e Closing & Allocation integrati, mentre una applicazione di consolidamento può avere ETL e Consolidamento.
Inoltre, uno stesso processo può essere presente in diverse applicazioni. Ad esempio, il processo di raccolta dei dati può essere utilizzato sia in
un’applicazione di budgeting che di consolidamento, anche se logicamente strutturate con dimensioni e dati differenti.
Il "Multidimensional Data Model" struttura multidimensionale standard di fondamentale importanza per applicazioni cliente è definito da un insieme di elementi:
• Tabella dei fatti (collezione di dati da analizzare del processo di business) • Tabelle dimensionali (attributi descrittivi del processo di business)
• Misure (proprietà atomica dei fatti da analizzare a valori numerici) • Gerarchie (diversi livelli di aggregazione dei dati)
Ogni dimensione contiene elementi chiamati metadati: si tratta di informazioni strutturali del database da non confondere con i valori ovvero le informazioni finanziarie del cliente. Successivamente ogni valore è associabile ad una serie di metadati dimensionali.
In breve sono sintetizzate le caratteristiche principali:
• Tutte le dimensioni possono essere utilizzate per più applicazioni e possono contenere gli stessi o diversi set di elementi. Ciò dipende dal tipo di
dimensione e da come è stata progettata l'istanza applicativa per uno specifico cliente. Ad esempio, la dimensione “Scenario” caratteristica temporale di un dato è comune in tutte le applicazioni abilitate, mentre la dimensione “Centro di Costo”, ovvero l’unità contabile aziendale potrebbe non essere presente poiché un’azienda cliente può non essere interessata a tale analisi.
• All'interno di un’istanza, l'intersezione tra i metadati delle diverse dimensioni (i possibili incroci tra gli elementi delle dimensioni di una istanza applicativa) permette di identificare univocamente il campo di analisi dell’applicazione e l’indirizzo univoco che identifica il valore di un dato.
• È possibile gestire più processi aziendali nello stesso database applicativo. • Il cliente finale ha accesso al modello, creando una applicazione ad-hoc per i
suoi scopi di business mediante una interfaccia utente predefinita. Ogni utente (Amministratore o Collaboratore) sfrutta il modello per modificare, eliminare e visualizzare le informazioni attraverso le proprie applicazioni. Il numero di applicazioni, dimensioni e di Built-in Process dipendono dai requisiti e bisogni del cliente.
Nella successiva Tabella 1.7 si può evidenziare un elenco di importi finanziari che rappresentano l’informazione granulare ovvero di dettaglio massimo, ottenuti dall’intersezione delle varie dimensioni nel modello. Una volta definiti i parametri, i dati sono successivamente recuperati ed utilizzati per la
visualizzazione di report aziendali.
Ogni dato è identificato all'interno del sistema da un insieme di elementi dimensionali. In questo caso, il dato specifico nella riga evidenziata in Tabella 1.7 è identificato dal set di diverse dimensioni Scenario, Periodo, Entità, Conto che saranno descritte successivamente.
"
Figura 1.7: Dati estratti dall’intersezione tra tabella dei fatti e dimensioni.
4.4 FATTO E DIMENSIONI
Il Data Warehouse è costituito da sei dimensioni obbligatorie definite “Dimensioni del Sistema” e da cinque dimensioni facoltative dette
“Dimensioni Personalizzate”, applicate per rispondere a specifiche esigenze del cliente. L’utente finale, in fase di realizzazione dell'applicazione Database, è obbligato a definire ed a istanziare le dimensioni del sistema ma può decidere se utilizzare o meno le dimensioni personalizzate a seconda dei propri scopi di business, definendo se necessario le caratteristiche e il nome delle relative dimensioni personalizzate.
In fase di progettazione del "Multidimensional Data Model" sono state definite le seguenti dimensioni del sistema obbligatorie, riassunte in Tabella 1.8, per qualsiasi istanza cliente.
Tabella 1.8: Dimensioni del Sistema presenti nel "Multidimensional Data Model"
DIMENSIONE DESCRIZIONE
ENTITA’ Ente aziendale da analizzare (nome della società)
CONTO Conti finanziari e non finanziari appartenenti a specifiche Entità
SCENARIO Anno e contesto di analisi per l’immissione e la contabilizzazione dei vari importi finanziari PERIODO Il periodo di registrazione relativo ad un determinato Scenario.
CATEGORIA Permette di etichettare gli importi
