Progettazione e realizzazione di un data warehouse in ambito ospedaliero

(1)

Università di Pisa

Dipartimento di Informatica

Corso di Laurea Magistrale in Informatica per l’economia e per l’azienda (Business Informatics)

TESI DI LAUREA

Progettazione e realizzazione di un data

warehouse in ambito ospedaliero

RELATORE:

Prof.ssa Giovanna ROSONE

CANDIDATO:

Matteo MARTONE

(2)

Sommario

Il presente lavoro di tesi illustra la realizzazione di uno strumento finalizzato a supportare la gestione dei beni materiali delle aziende sanitarie della regione Toscana.

A partire dai requisiti di analisi del cliente, viene progettato e realizzato un sistema di data warehouse e di business intelligence. Dopo aver presentato l’ambito in cui si è svolto il lavoro alla base di questa tesi, saranno esposte le fasi di analisi dei requisiti, di proget-tazione e realizzazione dei Data Mart e del Data Warehouse finale. Sono così descritte le fasi di estrazione, trasformazione e caricamento dei dati nei sistemi analitici progettati, per finire con la descrizione della reportistica creata.

(3)

Indice

1 INTRODUZIONE 5

1.1 Presentazione del problema . . . 5

1.2 Rassegna della letteratura . . . 6

1.3 Contenuto della tesi . . . 6

2 IL CASO DI STUDIO 8 2.1 Presentazione del caso . . . 8

2.1.1 Le aziende committenti . . . 8

2.1.2 L’azienda ospitante . . . 9

2.1.3 Ambito di riferimento . . . 11

2.2 Analisi dei processi aziendali . . . 12

2.2.1 Processo Inventario . . . 12

2.2.2 Processo Manutenzione Preventiva . . . 13

2.2.3 Processo Manutenzione Correttiva . . . 13

2.2.4 Processo Contratti . . . 14

(4)

3 ANALISI DEI REQUISITI E PROGETTAZIONE INIZIALE 15

3.1 Introduzione al Data Warehousing . . . 16

3.2 Processo Inventario . . . 18

3.2.1 Specifica dei requisiti . . . 19

3.2.2 Progettazione concettuale iniziale . . . 22

3.3 Processo Manutenzione Preventiva . . . 23

3.4 Processo Manutenzione Correttiva . . . 27

3.5 Processo Contratto . . . 32

3.6 Riepilogo delle dimensioni e delle misure . . . 38

3.7 Cambiamento delle dimensioni . . . 39

4 PROGETTAZIONE CONCETTUALE FINALE E LOGICA 41 4.1 Progettazione concettuale finale . . . 42

4.1.1 Processo Inventario . . . 42

4.1.2 Processo Manutenzione Preventiva . . . 43

4.1.3 Processo Manutenzione Correttiva . . . 45

(5)

4.1.5 Riepilogo dimensioni e misure . . . 49

4.2 Modellazione logica dei data mart . . . 51

4.3 Modellazione logica del data warehouse . . . 54

5 AMBIENTE E STRUMENTI DI SVILUPPO 55 5.1 Python e PyCharm . . . 55

5.2 PostgreSQL e EMS SQL Manager for PostgreSQL . . . 56

5.3 La suite Pentaho Community Edition . . . 58

5.3.1 Mondrian . . . 60

5.3.2 Saiku . . . 61

5.3.3 Community Dashboard Editor (CDE) . . . 62

6 ESTRAZIONE, TRASFORMAZIONE E CARICAMENTO (ETL) 64 6.1 Il processo ETL . . . 64

6.1.1 Area di staging . . . 66

6.2 Organizzazione del flusso ETL . . . 67

6.2.1 Estrazione . . . 67

6.2.2 Trasformazione . . . 68

6.2.3 Caricamento . . . 68

6.3 Gestione degli errori . . . 69

7 REALIZZAZIONE DELL’APPLICAZIONE DI BUSINESS INTELLI-GENCE 71 7.1 Introduzione OLAP . . . 71

(6)

7.2 Creazione dei cubi OLAP . . . 76

7.2.1 Schema Mondrian . . . 79

7.3 Interazione tra gli strumenti . . . 80

8 REPORTISTICA 82 8.1 Introduzione alla reportistica . . . 82

8.2 Report Inventario . . . 83

8.3 Report Manutenzione Preventiva . . . 86

8.4 Report Manutenzione Correttiva . . . 88

8.5 Report Contratti . . . 91

9 CONCLUSIONI 94

A Caso di Studio: Contratti 96

Bibliografia 104

(7)

Capitolo 1

INTRODUZIONE

1.1 Presentazione del problema

La disponibilità delle apparecchiature necessarie per fornire prestazioni sanitarie è un indicatore della qualità del servizio fornita dalle AUSL (Azienda Unità Sanitaria Locale) verso l’utenza. Per mantenere in buono stato le attrezzature è di fondamentale importanza la pianificazione e gestione degli eventi programmati e straordinari richiesti su di esse. Verificare l’andamento delle attività e analizzare le informazioni da esse generate disegna una base su cui lavorare per l’evoluzione della pianificazione sia in termini di efficacia, grazie ad una maggiore disponibilità d’uso, sia in termini di efficienza, in quanto si avranno minori costi di manutenzione. A causa dell’aumento dei volumi di attività e della quantità ingente di informazioni da amministrare, diventa indispensabile il supporto di un sistema informatico a sostegno dei processi decisionali e delle attività. Una soluzione a queste complicazioni viene offerta dalla Business Intelligence.

(8)

le affronta attraverso l’implementazione di un sistema che supporti la gestione dei beni materiali delle aziende sanitarie della regione Toscana grazie al:

• monitoraggio della vetustà e del posizionamento dei cespiti in uso all’interno delle aziende ospedaliere e AUSL toscane;

• monitoraggio delle attività dei contratti di manutenzione correttiva e preventiva.

1.2 Rassegna della letteratura

Per la progettazione e realizzazione del data warehouse è stato di supporto la consulta-zione del libro [AR17] in quanto concetti teorici e pratici sull’argomento sono correlati da indicazioni sulla presentazione formale di quanto progettato.

Per le procedure di ETL (Extract, Transform, Load) sono state seguite le indicazioni di Kimball e Caserta [CK04].

Per la realizzazione dell’applicazione di business intelligence sono stati di ausilio il si-to ufficiale di Pentaho [SUPE], la sua documentazione [PEDOC] ed il manuale di Saiku [Bar18].

1.3 Contenuto della tesi

La presente tesi ha l’obiettivo di esplicare il lavoro svolto per la progettazione e realizzazio-ne di un data warehouse e della relativa reportistica al firealizzazio-ne di creare un modello integrato a supporto delle decisioni aziendali. Di seguito viene presentata l’organizzazione della tesi indicando, per ogni capitolo, il proprio contenuto.

(9)

• Nel Capitolo 2 si descrive il caso di studio, presentando le aziende committenti, l’azienda ospitante, l’ambito di riferimento e descrivendo l’analisi dei processi del progetto.

• Nel Capitolo 3, dopo una breve introduzione sulle caratteristiche e sugli aspetti ar-chitetturali del processo di data warehousing, si presentano le prime fasi del processo di progettazione dei data mart ed il cambiamento delle dimensioni per ogni processo preso in considerazione.

• Nel Capitolo 4 vengono affrontare le ultime fasi relative al design dei data mart secondo il modello adottato. Sono quindi descritti per ogni processo la progettazione concettuale finale e la progettazione logica dei data mart e del data warehouse. • Nel Capitolo 5 sono descritti l’ambiente e gli strumenti open source di sviluppo

utilizzati nel processo di realizzazione del sistema di Business Intelligence.

• Nel Capitolo 6, dopo aver descritto il processo di ETL, vengono analizzate le fasi di estrazione, trasformazione e caricamento svolte nel progetto.

• Nel Capitolo 7 si passa alla realizzazione dell’applicazione di business intelligence. Vengono quindi descritti i sistemi OLAP e vengono presentati gli strumenti utilizzati per creare i cubi e la loro interazione.

• Nel Capitolo 8 sono descritti e mostrati i report estrapolati dal sistema di business intelligence per gli utenti finali.

(10)

Capitolo 2

IL CASO DI STUDIO

Nel seguente capitolo, dopo aver presentato il caso di studio, le aziende committenti, l’azienda ospitante e l’ambito di riferimento del lavoro di tesi, si esplica l’analisi dei processi del progetto.

2.1 Presentazione del caso

Il caso aziendale oggetto del lavoro di tesi è relativo alla progettazione e realizzazione di un sistema che supporti le attività decisionali, direzionali e operative per le aziende del settore sanitario e per la Regione Toscana.

2.1.1 Le aziende committenti

Le 3 Aziende USL (AUSL) della Regione Toscana sono articolazioni territoriali del Servi-zio sanitario regionale e garantiscono l’omogeneità dell’assistenza nelle diverse aree della regione. Articolate in zone-distretti, provvedono alla gestione e programmazione delle

(11)

at-tività definite nei livelli uniformi ed essenziali di assistenza (LEA), comprese le prestazioni socio-sanitarie ad elevata integrazione sanitaria, le prestazioni sanitarie a rilevanza sociale e le attività di assistenza sociale delegate agli enti locali. I LEA rappresentano gli obiettivi minimi di tutela della salute che il Servizio Sanitario Nazionale deve garantire.

Le 3 Aziende USL sono state costituite il 1° gennaio 2016, una per ciascuna “Area Vasta”, accorpando le 12 precedenti.

• Azienda USL Toscana centro (Pistoia, Prato, Firenze, Empoli)

• Azienda USL Toscana nord ovest (Massa e Carrara, Lucca, Pisa, Livorno, Viareggio) • Azienda USL Toscana sud est (Siena, Arezzo, Grosseto)

Le 4 Aziende ospedaliere-universitarie (AOU) toscane integrano le funzioni di ricerca, formazione e assistenza svolte dalle Università e dal Servizio Sanitario Regionale, secondo i principi del decreto legislativo n° 517/1999. Le Aziende ospedaliere toscane costituite nel 1994, ovvero A.O. Careggi, A.O. Meyer, A.O. Pisana e A.O. Senese, si sono dotate di statuti che sanciscono la trasformazione nelle nuove Aziende Ospedaliere Universitarie. Con questo passaggio l’Università partecipa a pieno titolo al sistema sanitario regionale. Ogni Azienda USL è dotata di un’Azienda Ospedaliero-universitaria di riferimento mentre l’A.O. Meyer ha funzioni di riferimento per tutta la regione [OAST].

2.1.2 L’azienda ospitante

Il Consorzio Metis ha sede a Pisa e nasce nel 1997 dalla comune volontà di alcune AUSL della Toscana di condividere esperienze, know-how e modalità di gestione e manutenzione

(12)

per le prime Aziende USL socie, specializzandosi sempre più in questo settore. Il suo scopo è quello di erogare servizi, esclusivamente all’insieme dei Soci o nei confronti di un singolo Socio, di carattere Tecnico ed Amministrativo con particolare riferimento alla gestione delle Tecnologie Sanitarie, degli immobili e degli impianti, delle opere, delle reti informative e delle tecnologie informatiche, di supporto ai servizi di prevenzione e protezione. Il Consorzio Metis è quindi un soggetto strumentale ai propri soci. Questi sono:

• ASUR Marche

• Azienda Ospedaliero-Universitaria Careggi • Azienda Ospedaliero-Universitaria Meyer • Azienda Ospedaliero-Universitaria Parma • Azienda Ospedaliero-Universitaria Perugia • Azienda Ospedaliero-Universitaria Pisana • Azienda Ospedaliero-Universitaria Senese • Azienda USL Toscana Nord Ovest

• Azienda USL Toscana Centro • Azienda USL Toscana Sud Est • ESTAR Regione Toscana • Regione Toscana

(13)

Ha organi di indirizzo politico-amministrativo ovvero un amministratore unico, un comi-tato di garanzia, un’assemblea consortile e un sindaco revisore. Il suo organo sovrano è l’assemblea consortile. Hanno diritto di partecipare ad essa tutti i consorziati. Può essere convocata tanto in sede ordinaria che in sede straordinaria: per decisione dell’Ammini-stratore Unico; su richiesta, indirizzata all’Amminidell’Ammini-stratore Unico, di almeno un terzo dei consorziati nel loro insieme; su richiesta del Comitato di Garanzia [SCM].

2.1.3 Ambito di riferimento

La qualità del servizio fornita da una struttura sanitaria verso l’utente è imprescindibile dal garantire la disponibilità all’uso delle apparecchiature necessarie per fornire la prestazione sanitaria. L’attenzione alla obsolescenza, al buon funzionamento ed alla disponibilità di queste attrezzature è importante sia per poter garantire la continuità del proprio servizio agli utenti della struttura sanitaria e sia ai fini economici della gestione.

Per le apparecchiature sanitarie il monitoraggio ha assunto una particolare rilevanza in termini di razionalizzazione delle risorse e di riduzione dei costi generati. Un’adeguata distribuzione di tecnologie e attrezzature sul territorio, oltre a garantire a tutti i cittadini l’accesso alle prestazioni sanitarie, consente di evitare sprechi legati ad inutili ridondanze e di monitorare i costi di mantenimento sostenuti per le attrezzature. In questo modo si forniscono le basi per eventuali analisi finalizzate alla riduzione dei costi ed all’aumento dell’efficienza produttiva.

(14)

2.2 Analisi dei processi aziendali

Una volta ricevute le richieste da parte del committente è stata di fondamentale importan-za la fase di raccolta e studio dei requisiti. Per comprendere pienamente la natura della tematica e conoscere a fondo le esigenze di analisi più adatte all’azienda è stato molto importante interagire sia con i membri del team di lavoro che con i responsabili aziendali. Un altro aspetto fondamentale è stato studiare la base di dati operazionale cercando di capire la natura dei dati e se questi fossero compatibili con le richieste fatte. Questo è avvenuto grazie al confronto con gli esperti del database, chiarendo con loro dubbi e per-plessità, data la sua complessità e vastità.

Una volta terminata la fase di raccolta dei requisiti, insieme al team di lavoro, sono stati individuati i processi ritenuti più importanti:

• Processo Inventario

• Processo Manutenzione Preventiva • Processo Manutenzione Correttiva • Processo Contratti

2.2.1 Processo Inventario

Analizzando l’obiettivo del processo inventario è emerso, dallo studio, di fornire una fon-te di informazione aggiornata quotidianamenfon-te ed affidabile. Lo scopo dei responsabili, attraverso questo processo, è quello di monitorare annualmente la vetustà dei beni in fun-zione, il loro numero ed il loro posizionamento all’interno delle Aziende USL. In particolar

(15)

modo si deve tener conto, per ogni cespite, del suo modello, della ditta di produzione e della tipologia a cui appartiene.

2.2.2 Processo Manutenzione Preventiva

La manutenzione preventiva viene effettuata ciclicamente per prevenire un guasto. Sono molte le componenti soggette ad usura, e che quindi vanno monitorate, regolate o sosti-tuite nel tempo per evitare avarie. Una corretta gestione della manutenzione preventiva permette di evitare sprechi di denaro e di tempo.

L’obiettivo è quello di monitorare, per ogni cespite, il numero di interventi di questo tipo, la tempistica totale e media degli interventi, il numero di ore in cui l’apparecchio è stato inutilizzabile (in cui le manutenzioni preventive hanno scaturito il fermo della macchina) e l’uptime, ovvero la percentuale di tempo in cui la macchina è disponibile all’attività clinica per cui è prevista la destinazione d’uso.

2.2.3 Processo Manutenzione Correttiva

La manutenzione correttiva avviene quando l’intervento si rende necessario in seguito al manifestarsi di un guasto.

L’obiettivo è quello di monitorare, per ogni cespite, il numero di interventi di questo tipo, la tempistica totale e media di intervento, risposta e risoluzione, il numero di ore in cui l’apparecchio è stato inutilizzabile (in cui si è scaturito il fermo della macchina) e l’uptime, ovvero la percentuale di tempo in cui la macchina è disponibile all’attività clinica per cui è prevista la destinazione d’uso.

(16)

2.2.4 Processo Contratti

I contratti sono legati alle manutenzioni preventive e correttive. L’obiettivo, in questo caso, è verificare se le tempistiche, concordate per ogni contratto, sono state rispettate. Quindi sarà utile osservare il numero di interventi per ogni tipologia di verifica e il numero di volte in cui non si sono rispettate le tempistiche riportate sui contratti.

2.3 La sorgente dei dati

Il Consorzio Metis sviluppa l’applicativo At2.0 per la gestione di beni in uso alle AUSL. Ogni qualvolta un’azienda sanitaria acquisisca un nuovo bene o venga effettuata una qual-siasi tipologia di verifica su di esso, queste operazioni devono essere obbligatoriamente registrate all’interno di appositi sistemi. Poiché attualmente non tutte le AUSL toscane utilizzano l’applicativo At2.0, sono state predisposte delle procedure che recuperano le in-formazioni registrate con altri applicativi (alcuni di questi sviluppati dal Consorzio Metis, ma non solo) e li immagazzinano all’interno di specifici database.

Per ragioni di sicurezza l’accesso ai dati è consentito solo dalla sede del Consorzio e non al di fuori di essa.

Dallo studio di questi database, prima in ambiente di test e poi di produzione, è comin-ciato il lavoro di progettazione e realizzazione del data warehouse che verrà descritto nei capitoli successivi.

(17)

Capitolo 3

ANALISI DEI REQUISITI E

PROGETTAZIONE INIZIALE

Nel presente capitolo, dopo una breve introduzione sulle caratteristiche e aspetti archi-tetturali del processo di data warehousing, si presentano le prime fasi del processo di progettazione dei data mart ed il cambiamento delle dimensioni.

Le fasi descritte si riferiscono a quelle presenti nel modello proposto nel libro Decision Support Databases Essentials [AR17], modello seguito per lo sviluppo del caso di studio e per la stesura di questo documento. In tale modello si individuano cinque fasi:

• analisi dei requisiti;

• progettazione concettuale iniziale dei data mart guidata dall’analisi; • progettazione concettuale candidata guidata dai dati;

(18)

• progettazione logica dei data mart e del data warehouse.

Più specificamente nel capitolo sono descritte le fasi di “analisi dei requisiti” e “progetta-zione concettuale iniziale” di tutti i processi individuati.

3.1 Introduzione al Data Warehousing

La prima, e sicuramente più diffusa, definizione di data warehouse viene fornita da Wil-liam Inmon nel 1990: “un data warehouse è una raccolta di dati organizzata per soggetti, integrata, non volatile, e variabile nel tempo, di supporto ai processi decisionali” .

• Organizzata per soggetti: nel data warehouse i dati sono organizzati per analizzare dei soggetti di interesse che influenzano l’andamento complessivo dell’azienda. Que-sta caratteristica lo contraddistingue dal database operativo il quale memorizza i dati per applicazioni.

Un data mart è un database che ha le stesse caratteristiche di un data warehouse ma solitamente risulta essere più piccolo e si concentra sui dati di un singolo soggetto. Può essere un sottoinsieme di un data warehouse più generale.

• Integrata: una delle caratteristiche principali di un data warehouse è che i dati rac-colti in esso provengono dall’integrazione di dati di fonti eterogenee. L’integrazione avviene attraverso un processo di estrazione, trasformazione e caricamento (ETL) dei dati dalle sorgenti al data warehouse.

• Non volatile: la modalità di interrogazione di un data warehouse è mirata all’e-strazione e non alla modifica dei dati conservati. I dati si compattano nel tempo e

(19)

vengono periodicamente aggiornati con l’aggiunta dei dati più recenti.

• Variabile nel tempo: nei database operazionali vengono conservati solo i valori più recenti mentre il data warehouse, poiché è pensato per le analisi e per fornire supporto alle decisioni strategiche, necessita di un orizzonte temporale più ampio al fine di poter analizzare i cambiamenti nel tempo.

• Supporto alle decisioni: lo scopo principale del data warehouse è di supportare i processi decisionali intesi come capacità di rispondere rapidamente alle business questions.

La progettazione di un data warehouse può avvenire attraverso due approcci differenti: Data-driven o Analysis-driven.

L’approccio Data-driven, conosciuto anche come approccio top-down, è stato introdotto da Inmon. In questa tipologia di pianificazione si progetta inizialmente il data warehouse in base ai dati disponibili e successivamente i data mart vengono ricavati da esso.

L’approccio Analysis-driven, conosciuto anche come approccio bottom-up, è stato intro-dotto da Kimball. In questa tipologia di pianificazione si progettano prima i data mart in base alle analisi dei dati che gli utenti vogliono eseguire. I data mart sono poi integrati per creare il data warehouse.

Nel presente caso di studio si è scelto di utilizzare la seconda tipologia di approccio de-scritta, ovvero l’Analysis-driven.

Una volta definita la modalità con la quale si è deciso di affrontare il caso, e prima di procede con l’analisi dei requisiti, è utile introdurre concetti basilari per svolgere le fasi di progettazione.

(20)

• Fatto: concetto di interesse sul quale si incentra un processo decisionale. Modella eventi verificati all’interno della realtà aziendale. Solitamente è descritto da misure e dimensioni di analisi.

• Dimensione: proprietà che descrive una prospettiva d’analisi di un fatto. Ogni fat-to contiene generalmente più dimensioni che ne definiscono la granularità, ovvero l’evento di massimo dettaglio analizzabile.

• Misura: proprietà numerica che caratterizza un fatto. Descrive un aspetto quanti-tativo di interesse per l’analisi.

Una misura può essere di varie tipologie:

– Additiva: può essere aggregata con la funzione SUM per qualsiasi dimensione. – Semi additiva: se può essere sommata almeno per una dimensione, ma non per

tutte.

– Non additiva: se la funzione somma non si può effettuare per nessuna dimen-sione.

– Calcolata: quando la misura viene calcolata in base ad altre misure.

• Gerarchia: Una gerarchia fra gli attributi di una dimensione definisce delle relazioni fra i valori degli attributi ed è fondamentale per spostarsi tra i diversi livelli di sintesi.

3.2 Processo Inventario

(21)

3.2.1 Specifica dei requisiti

Dalla raccolta dei requisiti vengono derivate le dimensioni, le misure e le metriche per ogni requisito di analisi.

Requisiti Inventario N Requisito di analisi Dimensioni Misure Metriche

1 Numero di cespiti raggrup-pati per ditta in uno speci-fico centro di costo nell’anno 2018

Cespite (ditta), cdc, anno

Numero di cespiti

2 La vetustà media e la quan-tità di cespiti per una deter-minata classe , per tutti i re-parti di una certa Azienda USL negli anni 2017 e 2018

Cespite (classe), reparto, azienda, anno

Vetustà Numero di cespi-ti, vetustà media

Vengono mostrate nella tabella di seguito la descrizione del Fatto Inventario, le sue dimensioni e le sue misure preliminari.

Fatto Inventario Descrizione Dimensioni preliminari Misure preliminari Un fatto è l’informazione

an-nuale della vetustà di un singolo cespite

Azienda, anno, cdc, cespite, reparto

(22)

Si elencano di seguito le dimensioni con relativa descrizione e granularità.

Dimensioni

Nome Descrizione Granularità

Azienda Dimensione che identifica l’Azienda Ex-USL o l’AOU

La singola azienda Anno Dimensione temporale che

identifi-ca il verifiidentifi-carsi di un fatto

Annuale Cdc Dimensione che identifica il centro

di costo

Il singolo centro di costo

Cespite Dimensione che identifica il cespite Il singolo cespite Reparto Dimensione che identifica il reparto Il singolo reparto

Per ogni dimensione di seguito ne verranno esplicati gli attributi e la loro descrizione. Dimensione Azienda:

Azienda Attributo Descrizione

Codice azienda Il codice identificativo dell’azienda Denominazione azienda La denominazione dell’azienda

Dimensione Anno:

Anno Attributo Descrizione

(23)

Dimensione Cdc:

Cdc Attributo Descrizione

Codice cdc Il codice identificativo del centro di costo Denominazione cdc La denominazione del centro di costo

Dimensione Cespite:

Cespite Attributo Descrizione

Codice cespite Il codice identificativo del cespite Numero di cespite Il numero di cespite

Classe La classe a cui appartiene il cespite Ditta La ditta di appartenenza del cespite Modello Il modello del cespite

Dimensione Reparto:

Reparto Attributo Descrizione

Codice reparto Il codice identificativo del reparto Denominazione La denominazione del reparto

Di seguito sono descritte le gerarchie dimensionali, con gli attributi che le compongono e il tipo di gerarchia.

Gerarchie Dimensionali Dimensione Descrizione Tipo

Cespite Numero → Modello → Ditta Bilanciata Cespite Numero → Classe Bilanciata

(24)

Viene analizzata, infine, l’unica misura del fatto Vetustà e il suo tipo di aggregabilità. Misure Misure Descrizione Aggregabilità Calcolata Vetustà Età in anni di un singolo cespite

rile-vata al 31/12 di ogni anno o al giorno attuale dell’anno corrente

Non additiva No

3.2.2 Progettazione concettuale iniziale

A seguito della raccolta dei requisiti e della loro traduzione formale è possibile identificare requisiti specifici sul fatto, sulle misure associate e sulle dimensioni.

Attraverso il formalismo DFM (Dimensional Fact Model) è possibile esprimere e rappre-sentare graficamente una sintesi delle informazioni raccolte. Il modello ottenuto come risultato dall’analisi dei requisiti è presentato nella Figura 3.1.

(25)

3.3 Processo Manutenzione Preventiva

In questa sezione si descrivono la specifica dei requisiti e la modellazione concettuale iniziale del data mart Manutenzione Preventiva.

3.3.1 Specifica dei requisiti

Requisiti Manutenzione Preventiva N Requisito di analisi Dimensioni Misure Metriche 1 Numero di interventi, ore

di intervento totali e il tempo medio degli inter-venti nell’anno 2017 per classe, per ditta e per mo-dello dei cespiti di una determinata azienda Cespite (classe, ditta, modello), azienda, anno NInterventi, OreInterventi, MediaOreInter-vento Totale NInter-venti, Totale OreInterventi

2 Quante ore, per l’anno 2017, i cespiti, di un deter-minato centro di costo, so-no stati fermi a causa del-le manutenzioni preventi-ve, quante ore potevano es-sere disponibili e la percen-tuale di quanto sono stati effettivamente disponibili Cespite, cdc, an-no OreInterventiFM, OreTotali, Uptime Totale OreInter-ventiFM, totale OreTotali

(26)

Vengono mostrate nella tabella di seguito la descrizione del Fatto Manutenzione Preven-tiva, le sue dimensioni e le sue misure preliminari.

Fatto Manutenzione Preventiva Descrizione Dimensioni preliminari Misure preliminari Un fatto è l’informazione

sul-le manutenzioni preventive di un cespite in un determinato anno

Azienda, anno, cdc, cespite Ninterventi, OreInter-venti, OreInterventi-Fm, OreTotali

Dimensioni

Un anno Cdc Dimensione che identifica il centro

di costo

Cespite Dimensione che identifica il cespite Il singolo cespite

Per ogni dimensione di seguito ne verranno esplicati gli attributi e la loro descrizione. Dimensione Azienda:

(27)

Dimensione Anno:

Anno Un anno nella forma YYYY

Dimensione Cdc:

Dimensione Cespite:

(28)

Vengono infine analizzate le misure del fatto Manutenzione Preventiva ed i tipi di aggre-gabilità.

Misure Misure Descrizione Aggregabilità Calcolata Ninterventi Numero di interventi di

manuten-zione preventiva

Additiva No OreInterventi Numero di ore degli interventi di

manutenzione preventiva

Additiva No OreInterventiFM Numero di ore degli interventi

di manutenzione preventiva che hanno portato al fermo del cespite

Additiva No

OreTotali Numero di ore in cui il cespite poteva essere disponibile

Additiva No MediaOreIntervento Tempo medio degli

interven-ti, calcolato come rapporto tra OreInterventi e Ninterventi

Non additiva Sì

Uptime Percentuale che indica il tempo per cui una data apparecchia-tura risulta disponibile all’uso, calcolata come

(1 −OreInterventiF m

OreT otali ) ∗ 100

Non additiva Sì

3.3.2 Progettazione concettuale iniziale

In Figura 3.2 è mostrato il diagramma concettuale iniziale del fatto Manutenzione Pre-ventiva, risultato della modellazione dei requisiti raccolti.

(29)

Figura 3.2: Schema concettuale iniziale

3.4 Processo Manutenzione Correttiva

In questa sezione si descrivono la specifica dei requisiti e la modellazione concettuale iniziale del data mart Manutenzione Correttiva.

3.4.1 Specifica dei requisiti

(30)

Requisiti Manutenzione Correttiva N Requisito di analisi Dimensioni Misure Metriche 1 Numero di interventi, ore

di risposta, di risoluzione e di intervento totali e il tempo medio degli inter-venti nell’anno 2018 per numero, per ditta, per mo-dello e per classi di cespi-te ricespi-tenucespi-te a rischio in uno specifico centro di costo

Cespite (nume-ro, ditta, model-lo,classe), anno, cdc NInterventi, OreRisposta, OreRisoluzione, OreInterventi, MediaOreInter-vento Totale NInter-venti, Totale OreRisposta, Totale OreRiso-luzione, Totale OreInterventi

2 Le ore totali di fermo mac-china, le quantità di ore di disponibilità (possibili) e la percentuale di dispo-nibilità (effettiva) per ogni cespite di un’azienda, per l’anno 2017 Cespite, azien-da, anno OreInterventiFM, OreTotali, Uptime Totale OreInter-ventiFM, totale OreInterventi

Vengono mostrate nella tabella di seguito la descrizione del Fatto Manutenzione Correttiva, le sue dimensioni e le sue misure preliminari.

Fatto Manutenzione Correttiva Descrizione Dimensioni preliminari Misure preliminari Un fatto è l’informazione

sul-le manutenzioni correttive di un cespite in un determinato anno

Azienda, anno, cdc, cespite NInterventi, OreRi-sposta, OreRisolu-zione, OreInterven-ti, OreInterventiFM, OreTotali

(31)

Dimensioni

Annuale Cdc Dimensione che identifica il centro

di costo

Cespite Dimensione che identifica il cespite Il singolo cespite Per ogni dimensione di seguito ne verranno esplicati gli attributi e la loro descrizione. Dimensione Azienda:

Codice azienda Il codice identificativo dell’azienda Denominazione azienda La denominazione dell’azienda Dimensione Anno:

Anno Un anno nella forma YYYY Dimensione Cdc:

(32)

Dimensione Cespite:

Vengono analizzate, infine, le misure del fatto Manutenzione Correttiva, i loro tipi di aggregabilità e se sono misure calcolate oppure no.

(33)

Misure Misure Descrizione Aggregabilità Calcolata Ninterventi Numero di interventi di

manuten-zione correttiva

Additiva No OreRisposta Numero di ore di risposta di

manutenzione correttiva

Additiva No OreRisoluzione Numero di ore di risoluzione di

Additiva No OreInterventi Numero di ore degli interventi di

Additiva No OreInterventiFM Numero di ore degli interventi

di manutenzione correttiva che hanno portato al fermo del cespite

Additiva No

OreTotali Numero di ore in cui il cespite poteva essere disponibile

Additiva No MediaOreIntervento Tempo medio degli

interven-ti, calcolato come rapporto tra OreInterventi e Ninterventi

Non additiva Sì

Uptime Percentuale che indica il tempo per cui una data apparecchia-tura risulta disponibile all’uso, calcolata come

(1 −OreInterventiF m

OreT otali ) ∗ 100

(34)

3.4.2 Progettazione concettuale iniziale

In Figura 3.3 è mostrato il diagramma concettuale iniziale del fatto Manutenzione Pre-ventiva, risultato della modellazione dei requisiti raccolti.

3.5 Processo Contratto

In questa sezione si descrivono la specifica dei requisiti e la modellazione concettuale iniziale del data mart Contratto.

(35)

3.5.1 Specifica dei requisiti

Requisiti Contratto N Requisito di analisi Dimensioni Misure Metriche

1 Per tutti i cespiti e i rela-tivi contratti di una deter-minata azienda, mostra-re, per l’anno 2018, il nu-mero di interventi tota-li di manutenzione corret-tiva e il numero di vol-te in cui le vol-tempistiche contrattuali non sono sta-te rispettasta-te (sta-tempo FM, tempo risoluzione e tempo risposta) Cespite, azienda, contratto, anno NInterventiMC, NIn-terventiMC_FM, NInterventiMC_risol, NInterventiMC_risp Totale NInterven-tiMC,Totale NInter-ventiMC_FM,Totale NInterven-tiMC_risol,Totale NInterventiMC_risp

2 Per tutti i contratti rela-tivi ad un centro di costo, mostrare il numero totale di manutenzioni preventi-ve e il numero di volte in cui il tempo di intervento non è stato rispettato

Contratto, cdc, anno NInterventiMP, NIn-terventiMP_int Totale NInter-ventiMP, Totale NInterventiMP_int

(36)

Vengono mostrate nella tabella di seguito la descrizione del Fatto Contratto, le sue dimen-sioni e le sue misure preliminari.

Fatto Contratto Descrizione Dimensioni preliminari Misure preliminari Un fatto è l’informazione, per

cespite, contratto e anno, sul numero di manutenzioni pre-ventive e correttive effettua-te e sul numero di voleffettua-te che le tempistiche, previste da contratto, non sono state rispettate

Cespite, azienda, contratto, anno, cdc NInterventiMC, NIn-terventiMC_FM, NInterventiMC_risol, NInterventiMC_risp, NInterventiMP, NInterventiMP_int

Dimensioni

Annuale

Cespite Dimensione che identifica il cespite Il singolo cespite Cdc Dimensione che identifica il centro

di costo

Contratto Dimensione che identifica i contrat-ti

(37)

Per ogni dimensione di seguito ne verranno esplicati gli attributi e la loro descrizione.

Dimensione Azienda:

Dimensione Anno:

Anno Un anno nella forma YYYY

Dimensione Cespite:

(38)

Dimensione Cdc:

Dimensione Contratto:

Codice contratto Il codice identificativo del contratto Denominazione contratto La denominazione del contratto

(39)

Misure Misure Descrizione Aggregabilità Calcolata NInterventiMC Numero di interventi di

manuten-zione correttiva effettuati

Additiva No NInterventiMC_FM Numero di interventi di

manu-tenzione correttiva effettuati che non hanno rispettato il tempo di fermo macchina stabilito da contratto

Additiva No

NInterventiMC_risolNumero di interventi di manu-tenzione correttiva effettuati che non hanno rispettato il tempo di risoluzione stabilito da contratto

Additiva No

NInterventiMC_risp Numero di interventi di manu-tenzione correttiva effettuati che non hanno rispettato il tempo di risposta stabilito da contratto

Additiva No

NInterventiMP Numero di interventi di manuten-zione preventiva effettuati

Additiva No NInterventiMP_int Numero di interventi di

manu-tenzione preventiva effettuati che non hanno rispettato il tempo di intervento stabilito da contratto

Additiva No

3.5.2 Progettazione concettuale iniziale

In Figura A.1 è mostrato il diagramma concettuale iniziale del fatto Contratto, risultato della modellazione dei requisiti raccolti.

(40)

3.6 Riepilogo delle dimensioni e delle misure

Si mostrano le tabelle di riepilogo delle dimensioni e delle misure condivise tra i processi. Dimensioni

Dimensioni Inventario Manutenzione Preventiva Manutenzione Correttiva Contratto Cespite X X X X Anno X X X X Azienda X X X X Reparto X Cdc X X X X Contratto X

(41)

Misure Misure Inventario Manutenzione

Preventiva Manutenzione Correttiva Contratto Vetustà X OreInterventi X X OreInterventiFm X X OreRisposta X OreRisoluzione X OreTotali X X MediaOreIntervento X X Uptime X X NInterventiMC X X NInterventiMC_FM X NInterventiMC_risol X NInterventiMC_risp X NInterventiMP X X NInterventiMP_int X

3.7 Cambiamento delle dimensioni

Dopo vari confronti con i responsabili aziendali, si è stabilito in che modo trattare le dimensioni con attributi che potrebbero cambiare nel tempo.

Come descritto in [AR17], per trattare le dimensioni con attributi che possono cambiare nel tempo, esistono quattro strategie di cui le prime tre sono per le dimensioni che cambiano lentamente (“slowly changing dimensions”):

(42)

a differenza del tipo 2 e 3 non permette di storicizzare i cambiamenti;

• Tipo 2 - Conservazione della storia: se un attributo dimensionale cambia il suo valore, è necessario che sia il vecchio che il nuovo valore vengano conservati nel data mart. Viene quindi aggiunta una nuova riga alla tabella dimensionale, creando una nuova entità. Tutti i fatti accaduti prima della modifica continuano a far riferimento alla vecchia entità, mentre tutti i fatti successivi alla modifica faranno riferimento a quella nuova;

• Tipo 3 - Conservazione di una o più versioni della storia: se un attributo dimen-sionale cambia il suo valore, la struttura della dimensione viene estesa con attributi aggiuntivi per mantenere la cronologia di tracciamento con valori vecchi e nuovi. Inoltre viene aggiunto anche un altro attributo con la data della modifica;

• Tipo 4 - Dimensioni che cambiano frequentemente: per gli attributi con un’alta frequenza di cambiamento è preferibile creare due tabelle dimensionali contenenti, in una gli attributi che rimangono invariati e nell’altra gli attributi che variano frequentemente.

La scelta decisa per il caso di studio è quella di Tipo 1 - Perdita di dati. Una volta concluse le fasi di analisi dei requisiti e progettazione concettuale iniziale, e dopo aver deciso con i responsabili il trattamento delle dimensioni, si procede con la progettazione concettuale finale e la progettazione logica dei data mart e del data warehouse.

(43)

Capitolo 4

PROGETTAZIONE CONCETTUALE

FINALE E LOGICA

A seguito delle fasi realizzate nel precedente capitolo, “analisi e specifica dei requisiti” e “modellazione concettuale iniziale”, verranno affrontare le ultime fasi relative al design dei data mart secondo il modello adottato. Nello specifico vengono realizzati:

• la progettazione concettuale finale dei data mart, con lo scopo di ampliare gli schemi presentati nel precedente capitolo con altre informazioni rilevanti;

• la progettazione logica dei data mart, ovvero tradurre i modelli concettuali finali in modelli relazionali;

• la progettazione logica del data warehouse, attraverso l’integrazione dei data mart in un unico schema del data warehouse.

(44)

4.1 Progettazione concettuale finale

Dalla raccolta e specifica dei requisiti e modellazione concettuale iniziale si arriva alla progettazione concettuale finale dei data mart. Per implementare questa fase è stato utile analizzare ulteriori aspetti del sistema sorgente, data la sua complessità e vastità, per capire se era possibile estrapolare ulteriori informazioni, ritenute utili, dalle tabelle presenti. Mediante un confronto con i committenti e con il team di lavoro si è stabilita l’aggiunta di dimensioni che non erano state inizialmente incluse poiché non individuate dalla raccolta dei requisiti.

Allo scopo di permettere analisi a diversi livelli di dettaglio per ogni processo è stata aggiunta la dimensione Presidio, mentre la dimensione Reparto è stata inclusa nei Processi delle manutenzioni e dei contratti.

4.1.1 Processo Inventario

Il fatto Inventario, dopo l’aggiunta della nuova dimensione, si presenta nel seguente modo: Fatto Inventario Descrizione Dimensioni preliminari Misure preliminari Un fatto è l’informazione

an-nuale della vetustà di un singolo cespite

Azienda, anno, cdc, cespite, reparto, presidio

Vetustà

Di seguito viene riportata la nuova dimensione, con una breve analisi e la sua granularità. Dimensioni

(45)

Dimensione Presidio:

Presidio Attributo Descrizione

Codice presidio Il codice identificativo del presidio Denominazione presidio La denominazione del presidio

Il modello di progettazione concettuale finale è riportato in Figura 4.1

Figura 4.1: Schema concettuale finale

4.1.2 Processo Manutenzione Preventiva

Il fatto Manutenzione Preventiva, dopo l’aggiunta delle nuove dimensioni, si presenta nel seguente modo:

(46)

Fatto Manutenzione Preventiva Descrizione Dimensioni preliminari Misure preliminari Un fatto è l’informazione

sul-le manutenzioni preventive di un cespite in un determinato anno

Azienda, anno, cdc, cespite, reparto, presidio

NInterventi, OreInter-venti, OreInterventi-Fm, OreTotali

Di seguito vengono riportate le nuove dimensioni, con una breve analisi e la loro granula-rità.

Dimensioni

Presidio Dimensione che identifica il presidio Un presidio Reparto Dimensione che identifica il reparto Un reparto

Dimensione Reparto:

Codice reparto Il codice identificativo del reparto Denominazione reparto La denominazione del reparto

(47)

Il modello di progettazione concettuale finale è riportato in Figura 4.2

4.1.3 Processo Manutenzione Correttiva

Il fatto Manutenzione Correttiva, dopo l’aggiunta delle nuove dimensioni, si presenta nel seguente modo:

Fatto Manutenzione Correttiva Descrizione Dimensioni preliminari Misure preliminari Un fatto è l’informazione

sul-le manutenzioni correttive di un cespite in un determinato anno

Azienda, anno, cdc, cespite, presidio, reparto NInterventi, OreRi-sposta, OreRisolu-zione, OreInterven-ti, OreInterventiFM, OreTotali

(48)

Dimensioni

Dimensione Reparto:

(49)

4.1.4 Processo Contratto

Il fatto Contratto, dopo l’aggiunta delle nuove dimensioni, si presenta nel seguente modo: Fatto Contratto Descrizione Dimensioni preliminari Misure preliminari Un fatto è l’informazione, per

cespite, contratto e anno, sul numero di manutenzioni pre-ventive e correttive effettua-te e sul numero di voleffettua-te che le tempistiche, previste da contratto, non sono state rispettate

Cespite, azienda contratto, anno, cdc, presidio, reparto

NInterventiMC, NIn-terventiMC_FM, NInterventiMC_risol, NInterventiMC_risp, NInterventiMP, NInterventiMP_int

(50)

Dimensioni

Dimensione Reparto:

(51)

4.1.5 Riepilogo dimensioni e misure

In questa sezione si riporta il riepilogo delle dimensioni e delle misure condivise tra i processi, risultate dall’analisi finale.

(52)

Dimensioni Dimensioni Inventario Manutenzione

Preventiva Manutenzione Correttiva Contratto Cespite X X X X Anno X X X X Azienda X X X X Reparto X X X X Cdc X X X X Contratto X Presidio X X X X Misure Misure Inventario Manutenzione

Preventiva Manutenzione Correttiva Contratto Vetustà X OreInterventi X X OreInterventiFm X X OreRisposta X OreRisoluzione X OreTotali X X MediaOreIntervento X X Uptime X X NInterventiMC X X NInterventiMC_FM X NInterventiMC_risol X NInterventiMC_risp X NInterventiMP X X NInterventiMP_int X

(53)

4.2 Modellazione logica dei data mart

Terminata la fase di progettazione concettuale, si passa alla modellazione degli schemi logi-ci risultanti. Il modello concettuale di partenza non presenta grosse particolarità pertanto la realizzazione dello schema relazionale avviene come segue:

• il fatto è modellato con una tabella;

• ogni dimensione, esclusa Anno, è modellata con una tabella;

• la dimensione Anno, in quanto dimensione degenerata (non presenta attributi), si modella come attributo della tabella dei fatti;

• per ogni tabella dimensionale si crea una chiave surrogata, che è inserita nella tabella dei fatti come chiave esterna;

• le misure calcolate non sono riportate all’interno della tabella dei fatti in quan-to verranno calcolate successivamente tramite lo strumenquan-to utilizzaquan-to di Business Intelligence.

Nonostante sia possibile normalizzare alcune gerarchie dimensionali dividendo gli attributi in più tabelle e ottenendo un cosiddetto snowflake schema (schema a fiocco di neve), si sceglie di mantenere una ridondanza nei dati, velocizzando così le analisi sul datamart grazie ad un ridotto utilizzo di operazioni di join in fase di esecuzione. Gli star schema (schema a stella) ottenuti per ogni processo sono mostrati nelle Figure 4.5, 4.6, 4.7 e A.3.

(54)

Figura 4.5: Modellazione logica Inventario

(55)

Figura 4.7: Modellazione logica Manutenzione Correttiva

(56)

4.3 Modellazione logica del data warehouse

La modellazione logica finale del data warehouse è mostrata in Figura 4.9.

(57)

Capitolo 5

AMBIENTE E STRUMENTI DI

SVILUPPO

In questo capitolo sono riportati gli strumenti utilizzati nel processo di realizzazione del sistema di Business Intelligence. Tutti gli strumenti utilizzati per lo svolgimento di questo progetto sono open source.

5.1 Python e PyCharm

Come visibile dal sito ufficiale [SUPY] “Python is a programming language that lets you work quickly and integrate systems more effectively”. Python è, quindi, un linguaggio di programmazione ad alto livello che consente di lavorare velocemente e ha un forte supporto all’integrazione con altri linguaggi e programmi. Attualmente lo sviluppo di Python, gra-zie alla comunità internazionale di sviluppatori, viene gestito dall’organizzazione no-profit Python Software Foundation. Python è un linguaggio multi-paradigma che permette di sfruttare il paradigma object oriented, la programmazione strutturata e la programmazio-ne funzionale. Gli oggetti sono tipizzati ma il relativo controllo vieprogrammazio-ne effettuato a runtime,

(58)

consentendo ad una variabile di cambiare tipo lungo la sua storia. La sintassi è partico-larmente pulita e sintetica. Uno dei suoi punti di forza è il numero di librerie (standard o di terze parti) disponibili ed in continua crescita.

Secondo Python Developers Survey 2018 [PSD18] l’editor principale utilizzato per lo svi-luppo in Python è risultato essere PyCharm, un ambiente di svisvi-luppo integrato IDE (Inte-grated Development Environment) utilizzato nella programmazione di computer e svilup-pato dalla società JetBrains. Citando lo slogan del sito ufficiale di PyCharm [SUPC] “ALL THE PYTHON TOOLS IN ONE PLACE” è facile intuire che ciò che rende desiderabile PyCharm è la vastità di strumenti integrati in esso, come i PyCharm Development Tool che permettono di testare i propri script tramite una comoda Python console integrata. PyCharm fornisce anche un’analisi del codice, un debugger grafico, un tester unità inte-grato, integrazione con i sistemi di controllo versione (VCSes) e supporta lo sviluppo web con Django.

PyCharm è multipiattaforma, disponibile per Windows, macOS e Linux. La Community Edition è rilasciata con licenza Apache mentre la Professional Edition, che ha funzionalità extra, è rilasciata con licenza proprietaria.

5.2 PostgreSQL e EMS SQL Manager for PostgreSQL

PostgreSQL è un ORDBMS (Object Relational Database Management System). A dif-ferenza dei RDBMS (Relational Database Management System) supporta nativamente, negli schemi relazionali e nelle query, strutture e modelli object-oriented come oggetti, classi ed ereditarietà. PostgreSQL ha alle proprie spalle oltre 30 anni di sviluppo. Non si

(59)

distingue solo come database conforme a SQL ma anche per le seguenti moderne features: • Possibilità di query complesse;

• Chiavi esterne (foreign keys) per il collegamento di dati da due tabelle;

• Trigger che vengono attivati automaticamente in ingresso e controllano, confermano, modificano, eliminano o in alternativa inseriscono i dati di riferimento;

• Visualizzazioni aggiornabili; • Concetto di transazione completo;

• Multiversion Concurrency Control (MVCC) per eseguire in modo efficiente l’accesso simultaneo al database.

PostgreSQL si basa sul tipico modello client-server: il componente centrale del server, con il nome “postmaster”, gestisce tutti i file di database e tutte le connessioni stabilite con il server di database per la comunicazione (input e output). Un database può contenere uno o più Schemi. Uno Schema è una raccolta di tabelle. Può contenere anche viste, indici, sequenze, tipi di dati, operatori e funzioni. Gli Schemi sono analoghi alle directory del sistema operativo ad eccezione del fatto che gli Schemi non possono essere nidificati e non è possibile creare collegamenti simbolici che puntano ad un altro Schema o oggetto. A differenza dei database gli Schemi non sono rigidamente separati: un utente può accedere agli oggetti di qualsiasi Schema nel database a cui è connesso se ha i privilegi per farlo. Sono diversi i motivi per cui conviene usare gli Schemi:

(60)

• Organizzare gli oggetti del database in gruppi logici per renderli più gestibili. • Le applicazioni di terze parti possono essere inserite in schemi separati in modo che

non entrino in collisione con i nomi di altri oggetti.

Uno strumento per gestire PostgreSQL è EMS SQL Manager for PostgreSQL, tool ad alte prestazioni per l’amministrazione e lo sviluppo del database PostgreSQL. Funziona con tutte le versioni di PostgreSQL fino a quelle più recenti. La versione utilizzata è la versione open source ovvero quella Lite. A differenza di quella completa questa versione ha meno funzioni e permette la gestione contemporanea di al massimo 5 database.

5.3 La suite Pentaho Community Edition

Pentaho è una piattaforma di Business Intelligence (BI) creata nel 2004 e acquisita da Hitachi nel 2015. È stata fondata da un team di professionisti provenienti da aziende leader del settore con l’obiettivo di offrire un’alternativa open source alle piattaforme proprietarie già esistenti, proponendo diverse caratteristiche e benefici rispetto alle offerte commerciali. A tale scopo sono stati integrati, in un’unica piattaforma, i popolari progetti open source quali Kettle, Mondrian e Weka. La suite Pentaho è disponibile in due versioni: Community ed Enterprise. La differenza sostanziale è che la versione Enterprise, sotto versamento di una quota annuale da parte del cliente, ha strumenti aggiuntivi e supporto tecnico, caratteristiche non presenti nella versione Community. Pentaho Community Edition (da adesso in poi denominato Pentaho) mette a disposizione una collezione di strumenti che permettono di sviluppare soluzioni di Business Intelligence coprendo tutto il ciclo di vita

(61)

dei dati.

La suite di Pentaho BI ha una struttura modulare, visualizzabile in Figura 5.1.

Figura 5.1: Struttura Pentaho BI

Per ogni livello sono presenti dei programmi che possono essere qualificati in modi diversi. Tra le varie classificazioni è di notevole importanza quella riguardante la suddivisione in programmi server e desktop/client. I programmi server sono quelle applicazioni che rispondono alle richieste dei programmi desktop che, invece, possono essere installati su di un computer locale, ovvero ogni utente che volesse utilizzarli può averli sulla propria macchina.

Le applicazioni utilizzate in questo progetto sono le seguenti: • Pentaho BI Platform

(62)

• Community Dashboard Editor (CDE)

5.3.1 Mondrian

Mondrian è un motore ROLAP (in quanto memorizza esclusivamente la struttura dei dati, quindi le loro correlazioni, ma lascia i dati persistenti nella base di dati) scritto in Java e progettato per eseguire interrogazioni scritte nel linguaggio MDX (MultiDimensional eXpressions). Questo fa si che la lettura dei dati possa essere effettuata su molteplici database RDBMS (tra cui anche la base di dati PostegreSQL utilizzata in questo progetto) e la presentazione dei risultati in formato multidimensionale avviene attraverso API Java. Il sistema Mondrian presenta quattro livelli:

1. Presentation layer: determina ciò che l’utente finale vede sul proprio monitor e la modalità di interazione per effettuare nuove interrogazioni al sistema.

2. Dimensional layer: ha lo scopo di analizzare, validare ed eseguire query MDX. Una componente ulteriore permette all’applicazione di poter manipolare le interrogazioni SQL già definite evitando di dover generare nuove istruzioni MDX per ogni nuova richiesta di dati.

3. Star layer: è responsabile del mantenimento in memoria di un buffer che contiene i dati riferiti con più frequenza.

4. Storage layer: è un RDBMS.

Le componenti possono coesistere sulla stessa macchina oppure possono essere distribuite tra macchine distinte. Questo non vale per il dimensional layer e lo star layer perchè,

(63)

comprendendo il server Mondrian, devono essere mantenuti sulla stessa macchina. Lo storage layer invece potrebbe risiedere su un’altra macchina ed essere accessibile tramite una connessione remota JDBC.

Mondrian Schema

Gli schemi Mondrian sono rappresentati in file XML. Uno schema definisce un database multidimensionale. Esso contiene:

• un modello logico costituito da costrutti utilizzati per scrivere query in MDX: cubi, dimensioni, gerarchie, livelli e membri;

• un modello fisico ovvero la fonte dei dati che viene rappresentata attraverso il modello logico.

5.3.2 Saiku

Saiku è un plug-in che permette agli utenti di analizzare i dati aziendali, creare e condi-videre report. Oltre alla semplicità di utilizzo nella generazione delle analisi desiderate, ha un’interfaccia utente intuitiva e visivamente chiara ed incisiva. Saiku raccoglie le in-formazioni che dovranno essere visualizzate a video recuperando i file XML depositati nel repository. Consente di creare automaticamente query MDX trascinando misure e dimensioni di uno schema Mondrian, precedentemente definito, e possono svolgersi atti-vità come filtraggio, ordinamento e creazione di membri calcolati da altre misure. Saiku fornisce anche altri strumenti di cui tra i più importanti troviamo:

(64)

• drill through current query: esegue un drill down per tutti i valori degli attributi che fanno parte del cubo;

• visualizza MDX: mostra la query nella sintassi MDX che genera i valori riportati nella tabella visualizzata;

• esporta XLS, Esporta CSV ed Esporta PDF che creano rispettivamente un nuovo foglio di calcolo Excel, un file CSV o un file PDF contenenti i dati riportati sulla tabella di analisi;

• mostrare Totali e Subtotali per righe o per colonne • mostrare grafici dei risultati.

5.3.3 Community Dashboard Editor (CDE)

Community Dashboard Editor è un plug-in che consente di sviluppare, implementare e distribuire dashboard nella piattaforma Pentaho in modo rapido ed efficace. É uno stru-mento avanzato e completo che integra l’interfaccia utente con data sources e componenti personalizzati. Questo strumento si compone di tre prospettive:

• Layout Perspective: è possibile progettare il layout di dashboard da zero o utilizzare un modello CDE. Durante la definizione del layout è possibile applicare stili, aggiun-gere elementi HTML (testo o immagini) e aggiunaggiun-gere file di risorse (JS o CSS) o snippet.

(65)

• Components Perspective: aggiunge e configura diversi componenti che compongono la dashboard. Collegano gli elementi del layout con i data sources. Esistono tre tipi di componenti:

– Componenti visivi e dati: vengono visualizzati nella dashboard, tra cui caselle di testo, tabelle, grafici, selettori, visualizzazioni OLAP e report

– Parametri: rappresentano valori condivisi dai componenti. Sono essenziali per le interazioni tra i componenti

– Script: pezzi di codice JavaScript che consentono di personalizzare l’aspetto e il comportamento degli altri componenti

• Data Source Perspective: consente di accedere ai vari tipi dati che si desidera utilizzare nella dashboard.

(66)

Capitolo 6

ESTRAZIONE, TRASFORMAZIONE

E CARICAMENTO (ETL)

In questo capitolo, dopo aver descritto brevemente il processo di estrazione, trasformazione e caricamento dei dati, ne verranno analizzate nel dettaglio le fasi svolte in questo progetto.

6.1 Il processo ETL

Il processo di ETL (Extract – Transform - Load) è considerato l’elemento fondamentale in un sistema di business intelligence poiché da esso dipende la qualità e l’uniformità dei dati all’interno del data warehouse. I tre sottoprocessi dell’ETL sono:

• Estrazione: i dati vengo estratti da una o differenti fonti. Esistono due tipolo-gie di estrazione: statica, che viene effettuata quando il data warehouse deve essere popolato per la prima volta e consiste concettualmente in una fotografia dei dati ope-razionali, e incrementale, usata per l’aggiornamento periodico del data warehouse, che cattura i cambiamenti avvenuti dall’ultima estrazione.

(67)

• Trasformazione: conversione dei dati dal formato operazionale sorgente a quello del data warehouse. Tipici esempi di trasformazioni sono conversione, normalizzazione, standardizzazione e correzione.

• Caricamento: i dati vengono caricati nel data warehouse. Esistono due differenti approcci: si parla di caricamento tramite Refresh nel caso in cui i dati vengono integralmente riscritti sostituendo i precedenti, o di caricamento tramite Update grazie al quale si rilevano e inseriscono, nel data warehouse, solo i cambiamenti avvenuti a partire dall’ultimo caricamento.

Quindi un sistema di ETL, progettato correttamente, estrae i dati dai sistemi di origine, rafforza la qualità e la standardizzazione dei dati, conforma i dati in modo che sorgenti differenti possono essere utilizzate insieme e infine fornisce i dati pronti per la presentazioni in modo che gli sviluppatori possano creare applicazioni e gli utenti finali possano prendere decisioni. Sebbene la creazione del sistema ETL sia un’attività di back room (non è visibile agli utenti finali), consuma facilmente il 70% delle risorse necessarie per l’implementazione e la manutenzione di un tipico data warehouse [CK04].

Il processo ETL può essere implementato attraverso diverse modalità che dipendono dalle analisi richieste e dalla complessità dei sistemi sorgenti: l’approccio utilizzato in questo progetto è quello a tre livelli (three-layer) mostrato in Figura 6.1.

(68)

Figura 6.1: Architettura three-layer

Questo approccio prevede il livello delle sorgenti dati, il livello dei dati intermedi e il livello del data warehouse, separando il processo di estrazione dei dati dalla base di dati operazionale e il processo di caricamento nel data warehouse.

Tutte le attività del processo sono state realizzate per mezzo di PostgreSQL integrato in script Python, grazie alla sua libreria psycopg. Questa libreria è “multi-thread” ovvero dà la possibilità allo sviluppatore di creare e distruggere simultaneamente cursori e connessioni; inoltre è possibile eseguire query PostgreSQL in parallelo.

6.1.1 Area di staging

La staging area è ampiamente utilizzata in quasi tutte le realizzazioni di data warehouse dal momento che offre dei vantaggi aggiuntivi non indifferenti:

• la possibilità, in caso di fallimento della procedura di ETL, di non ricominciare dall’inizio l’intera procedura ma soltanto dal punto in cui si è verificato il fallimento;

(69)

• la possibilità di verificare meglio, in fase di controllo del funzionamento della proce-dura, le diverse fasi del trattamento dei dati.

Nel data warehouse in esame si è fatto uso della staging area per eseguire trasformazioni sui dati e stabilizzare le procedure di ETL. Dovendo alcune trasformazioni essere realizzate in una sequenza ben precisa, per memorizzare i valori intermedi delle elaborazioni si è utilizzata una staging area realizzata tramite file temporanei.

6.2 Organizzazione del flusso ETL

Le procedure ETL sono organizzate in script Python con all’interno varie funzioni, ciascuna delle quali implementa una fase del processo: EXTRACT per l’estrazione dei dati dal sistema sorgente, TRANSFORM per la trasformazione e LOAD per il caricamento nelle tabelle dell’area permanente.

6.2.1 Estrazione

I dati necessari sono contenuti nelle tabelle di un’unica base dati ospitata dal sistema: per accedervi è stato creato un dblink dal sistema PostgreSQL in modo tale da poter creare un’unica connessione sia per la fase di estrazione che per il caricamento dei dati. Dati i tempi ridotti del sistema per effettuare questo tipo di operazione e la semplicità di implementazione, tra le differenti tipologie di estrazione si è scelta quella statica rispetto a quella incrementale. I dati, una volta estratti, vengo inseriti in apposite strutture Python, pronti per essere elaborati.

(70)

6.2.2 Trasformazione

La fase di trasformazione avviene attraverso apposite funzioni TRANSFORM. I dati, presenti nelle strutture dati, vengono modificati e caricati in file CSV temporanei. Le operazioni di trasformazione più comuni sono le seguenti:

• Sostituzione dei valori nulli: i codici di chiave esterna con valore null sono sostituiti con il valore 0;

• Concatenazione dei campi: alcuni attributi, nelle tabelle del data warehouse, sono originati dalla concatenazione di più campi di una tabella del database operazionale; • Conversione delle date: dalle date in formato datetime sono stati estrapolati solo gli

anni mediante apposite funzioni;

6.2.3 Caricamento

Il caricamento è eseguito prendendo il file CSV, generato dalla fasi di trasformazione, e tramite la funzione “copy_expert” i dati vengono caricati all’interno del data warehouse. Questo procedimento interessa sia le tabelle dimensionali che le tabelle dei fatti.

In questa fase non avviene nessuna trasformazione dei dati ma si valorizzano le chiavi sur-rogate ed alcuni campi di controllo. Le procedure di caricamento delle tabelle dimensionali vengono eseguite prima del caricamento delle tabelle dei fatti in quanto è necessario che il vincolo di integrità referenziale, tra la chiave primaria della tabella dimensionale e la chiave esterna della tabella dei fatti, sia rispettato.

(71)

• nel caso in cui il record sia già presente nella tabella dimensionale si verifica se i suoi attributi sono invariati. Se quest’ultima ipotesi è falsa vengono aggiornati tramite UPDATE;

• nel caso in cui il record non sia presente nella tabella dimensionale viene inserito nella dimensione tramite INSERT.

Il caricamento delle tabelle dei fatti viene eseguito tramite il Refresh con le istruzioni DELETE/INSERT. Il blocco DELETE elimina i record all’interno della tabella dei fatti; il blocco INSERT inserisce i record.

Aggiornamento del Data Warehouse

Le operazioni di aggiornamento sono implementate tramite il comando, nel sistema Linux, Crontab che consente la schedulazione di comandi. Crontab permette, quindi, un’ese-cuzione periodica. Nel caso di studio il flusso ETL è programmato per essere eseguito quotidianamente.

6.3 Gestione degli errori

Quando si esegue uno script Python si genera automaticamente un file di LOG per tenere traccia degli esiti e dei tempi di esecuzione. Nello specifico questo file contiene informazioni su:

• Nome del file Python eseguito

(72)

• In caso di errore è presente il numero della riga dove si è verificato, la sua tipologia e la sua descrizione

• In caso di aggiornamento delle dimensioni è presente il numero di record inseriti o aggiornati

Inoltre è stata predisposta una procedura automatica di invio e-mail con le informazioni sulla riuscita delle procedure programmate. Nella e-mail, inoltre, vi sono il tempo di durata in secondi, la data inizio, la data fine e la segnalazione di eventuali errori. Qualora vengano aggiornate le dimensioni compare anche il nome della dimensione e i cambiamenti avvenuti. Un esempio del corpo della e-mail è raffigurato in Figura 6.2.