Specifiche Tecniche piattaforma aggregazione dati quali-quantitativi Documento di progetto (Codice: A3P7)

Transcript

1 Piattaforma tecnologica di Monitoraggio Qualità Servizi Erogati Specifiche Tecniche piattaforma aggregazione dati quali-quantitativi Documento di progetto (Codice: A3P7) Riferimento Data 05 ottobre 2009 Destinatario Gianluca Vannuccini Comune di Firenze Presentata da Antonio Cavallari (Capo Progetto Altran) Lista di distribuzione per approvazione da Enti Collaudatori Nome Data Ente Pagina 1

2 Indice 1 Introduzione Scopo del documento Riferimenti Processo di acquisizione dei dati quantitativi Definizione dei dati da acquisire Struttura XSD per la definizione dei dati da acquisire Modalità di acquisizione dati Interfacce di acquisizione dei dati Tool di rilevazione dei dati quantitativi (import + inserimento manuale) Viste specifiche sui sistemi dell Ente (basi dati aggregate) Alimentazione tramite Web Service e XML Interfacciamento dei sistemi PEOPLE Processo di acquisizione dei dati qualitativi Processo di aggregazione dei dati quali-quantitativi Definizione dinamica delle trasformazioni tramite piattaforma Attivazione dei processi ETL Dati Quantitativi Attivazione dei processi ETL Dati Qualitativi Possibili sviluppi futuri della piattaforma Specifiche del DB contenente i dati aggregati di monitoraggio Checklist riassuntiva delle specifiche di aggregazione Precondizione: definizione e associazione delle variabili in anagrafe Precondizione: attivazione dell istanza di servizio e generazione della XSD Definizione di un CSV compliant con la struttura XSD Definizione di un XML compliant con la struttura XSD Definizione di una vista compliant con la struttura XSD Acquisizione dei dati qualitativi per indagini esterne...27 Pagina 2

3 1 Introduzione 1.1 Scopo del documento Il deliverable documentale A3P7 riguarda la definizione delle specifiche tecniche per la piattaforma di aggregazione dei dati quali-quantitativi per il monitoraggio dei servizi, comprensive delle specifiche del database contenente i dati aggregati di monitoraggio. La documentazione delle specifiche tecniche è propedeutica alla realizzazione del software che implementa il modulo logico per l aggregazione dei dati, responsabile della gestione dell acquisizione automatica dei dati quantitativi da sottosistemi dell Ente secondo un formato concordato. In tal modo, si intende regolamentare il processo di acquisizione dei dati dai vari sistemi informativi gestionali di back office degli Enti, che contengono dati sull erogazione dei servizi che sono utili al monitoraggio complessivo della qualità e quantità dei servizi erogati da un Ente, attraverso la definizione delle specifiche di aggregazione dei dati in termini di metodi esposti e strutture dati componenti. I dati raccolti, in forma automatica o manuale, dopo l eventuale conferma all inserimento nella piattaforma, sono aggregati attraverso un processo di elaborazione all interno del DB. A seconda degli schemi di dispiegamento, la base dati può contenere i dati di un solo Ente o, nel caso di installazione comune della piattaforma presso un Ente aggregante, i dati di più Enti afferenti la stessa installazione fisica. La modalità concordata durante le riunioni di progetto con gli Enti coinvolti prevede come fonte principale di alimentazione la presenza di viste materializzate contenenti i dati necessari per la piattaforma, conformemente con la definizione della struttura dati associata all istanza di servizio definita in anagrafe e formalizzata tramite file XSD. Ove necessario, rimane valida la possibilità di inviare alla piattaforma i dati per il popolamento delle istanze di servizio tramite Web Service, allegando il file XML di popolamento conforme alla struttura XSD derivante dalla definizione in anagrafe. 1.2 Riferimenti L individuazione delle user needs e dei requisiti, funzionali e non funzionali, che guidano la modellazione delle interfacce di comunicazione per l aggregazione dei dati derivano dall analisi e dalla condivisione dei documenti di seguito elencati: Capitolato Tecnico per la Realizzazione Piattaforma di Monitoraggio Qualità Servizi Erogati nell ambito del Progetto IQuEL; Allegato 4 Capitolato Tecnico Descrizione di dettaglio del sistema; Allegato 6 Capitolato Tecnico Requisiti di sistema; Deliverable A2P5 Documento di definizione di una architettura software di aggregazione di dati di monitoraggio quali-quantitativo Offerta Tecnica per Realizzazione Piattaforma di Monitoraggio Qualità Servizi Erogati nell ambito del Progetto IQuEL (Off_02 Soluzione proposta, Off_03 Risposta ai Requisiti di Sistema). In seguito alla proposta avanzata dal Comune di Firenze, in data 11 marzo 2009, e approvata dagli Enti IQuEL nella successiva riunione plenaria del 18 marzo, si è deciso di uniformare come interfaccia di alimentazione della piattaforma da parte dei sistemi degli Enti quella che prevede il ricorso a viste sui dati dei sistemi degli Enti, create nel rispetto delle strutture dati definite in Anagrafe. Ove possibile, pertanto, la forma principale di acquisizione automatica dei dati avviene a partire da tabelle di DB che raccolgono (in forma di viste) i dati provenienti dai sistemi informativi alimentanti dell Ente. Pagina 3

4 2 Processo di acquisizione dei dati quantitativi La presenza di diversi contesti territoriali negli Enti locali partecipanti al progetto, di dimensioni diverse (piccoli medi e grandi Comuni, aggregazioni di Enti, Province, etc.) e grado di informatizzazione eterogeneo, richiede da parte della piattaforma la massima flessibilità ed adattabilità nelle modalità di acquisizione dati e integrazione offerte. 2.1 Definizione dei dati da acquisire Il punto di partenza del processo di acquisizione dei dati quantitativi è ovviamente, date le caratteristiche di completa dinamicità delle strutture dati coinvolte, la definizione delle istanze di servizio effettuata attraverso l anagrafe dei servizi. Il concetto di base è quello di agevolare, anche attraverso funzionalità evolute di duplicazione/clonazione dei servizi, un processo di miglioramento continuo delle analisi nel tempo, consentendo di predisporre per le diverse istanze dello stesso servizio (ad esempio annuali) di volta in volta nuove variabili di interesse per l elaborazione degli indici statistici. Durante la creazione di un istanza, sino alla sua attivazione, è possibile associare al servizio le variabili che si andranno poi ad acquisire per determinare gli indicatori di interesse. Una variabile, secondo una nomenclatura condivisa con gli Enti, indica un dato semplice, ovvero una misura associata al servizio (e.g. il numero di ricorsi presentati nell anno di riferimento come dato di performance). In fase di creazione, inoltre, è possibile valorizzare il flag di abilitazione inserimento manuale (flag per consentire o meno il popolamento iniziale attraverso la modalità manuale). Si sottolinea comunque come, in conformità con il processo organizzativo definito dal Politecnico di Milano, indipendentemente dal valore del flag abilitazione_ins_manuale, che determina se il primo popolamento delle variabili deve avvenire tramite processi automatici (=false) o può avvenire in entrambe le modalità (flag=true), i dati inseriti devono comunque essere visualizzati e approvati dal redattore prima di essere inviati al processo di aggregazione. Tutti i sistemi di alimentazione automatica dai sistemi informativi dell Ente, inoltre, come previsto dal modello organizzativo, sono esclusivamente di tipo one-shoot all interno del periodo di riferimento della campagna di rilevazione (quelli che interessano e sono gestiti sono i dati complessivi per l intera durata della rilevazione). Una istanza di servizio (ovvero una rilevazione dei dati associati ad una classe di servizi, e.g. Asili Nido, per un intervallo temporale di riferimento, e.g. 2009), associata ad un solo Ente presente nell installazione della piattaforma, può assumere tre diversi stati: in lavorazione (possibilità di modificare gli attributi della rilevazione e le associazioni con le variabili in ingresso), attivo (rilevazione pronta per essere popolata o in fase di popolamento, manuale o automatico) o archiviato (dati acquisiti, elaborati e resi disponibili per i processi di aggregazione). L attivazione delle istanze di servizio genera automaticamente i file XSD per la validazione delle strutture dati ricevute dal modulo di acquisizione (viste su DB dell Ente, import da file CSV/XML, completamento manuale dei dati quantitativi, acquisizione XML tramite Web Service). Pagina 4

5 Non appena avviene un operazione di popolamento, manuale o automatico, viene impostato il flag di popolamento per la rilevazione (flag popolato posto a true dalla prima operazione di data entry). Da questo momento in poi, sono possibili solo correzioni manuali prima di procedere con l approvazione dei dati e l invio ai processi di elaborazione. Al termine dell acquisizione, contestualmente all approvazione, si setta il flag inviato per procedere con la convalida dei dati acquisiti e avviare il processo di aggregazione one-shoot Struttura XSD per la definizione dei dati da acquisire Contestualmente all attivazione di una nuova rilevazione, viene generata la struttura XSD posta come riferimento per la validazione dei dati acquisiti tramite le interfacce manuali e automatiche di acquisizione dati. Una XSD definisce il tipo di un documento XML in termini di vincoli: quali elementi ed attributi possono apparire, in quale relazione reciproca, quale tipo di dati può contenere, ed altro. Può essere usata anche con un programma di validazione, al fine di accertare a quale tipo appartiene un determinato documento XML. Più nel dettaglio, una XML Schema Definition (XSD) è un esempio concreto (instance) di schema XML scritto in linguaggio XML Schema. L'XML Schema è l'unico linguaggio di descrizione del contenuto di un file XML che abbia per ora raggiunto la validazione ufficiale del W3C. Come tutti i linguaggi di descrizione del contenuto XML, il suo scopo è delineare quali elementi sono permessi, quali tipi di dati sono ad essi associati e quale relazione gerarchica hanno fra loro gli elementi contenuti in un file XML. Ciò permette principalmente la validazione dei valori dati alle variabili in fase di popolamento della piattaforma (inserimento dei dati quantitativi), ovvero la verifica che gli elementi di popolamento siano in accordo con la descrizione in linguaggio XML Schema. L idea alla base dell implementazione effettuata è stata quella di definire in fase di analisi il formato dei dati più adatto, in base alle famiglie di variabili previste e alle caratteristiche dei sottosistemi informativi che forniscono i dati in oggetto, per modellare le variabili in ingresso a ogni servizio e le limitazioni sui valori assumibili. La registrazione dei servizi è accompagnato dall indicazione degli indicatori oggetto di analisi e dei descrittori associati al servizio, in grado di descrivere semanticamente le peculiarità associate alla rilevazione. A partire da tali descrittori, è possibile generare una struttura XSD che definisce i dati accettati dalla piattaforma. La possibilità di intervenire addirittura tramite GUI nella definizione del formato dei dati, e quindi nella definizione parametrica degli XSD, garantisce la massima flessibilità e scalabilità della soluzione. Si sottolinea come la generazione delle strutture di controllo sia totalmente automatica e dinamica. 2.2 Modalità di acquisizione dati Lo scenario complessivo di funzionamento dell intera piattaforma prevede due modalità di alimentazione dei dati da aggregare relativi al monitoraggio dei servizi erogati dall Ente, una automatica (alimentazione diretta dai sottosistemi dell Ente) e una manuale (inserimento dei dati quantitativi attraverso il tool messo a disposizione dalla piattaforma). Se un Ufficio ha un gestionale informatizzato delle pratiche, potrà fornire in modo automatizzato i dati quantitativi sulle pratiche espletate (numero, tipologia, data, numero di Pagina 5

6 pratiche gestite attraverso i diversi canali di erogazione del servizio, etc.) alla piattaforma di aggregazione dei dati di monitoraggio (secondo le specifiche richieste). Per tutti gli altri casi, il tool di rilevazione manuale dei dati quantitativi offre un interfaccia di imputazione che consente di inserire manualmente i dati nel sistema se non è disponibile il software gestionale da integrare, oppure si preferisce popolare manualmente i dati di interesse per il monitoraggio del servizio, o ancora si desidera intervenire per completare i dati acquisiti in modalità automatica. Effettuato il primo salvataggio durante l inserimento manuale, o dopo la prima acquisizione automatica, non sarà più possibile acquisire dati tramite la modalità automatica (sovrapposizione dei dati). Il tool offre la possibilità da parte degli operatori dell Ente di procedere con l inserimento, l importazione (formati CSV e XML) e la revisione dei dati (anche di quelli acquisiti automaticamente) tramite le funzionalità di gestione dei dati quantitativi rese disponibili dalla console di gestione. Dettagliando i processi per la raccolta automatizzata dei dati, il meccanismo di costruzione tramite anagrafe di quelle che sono le strutture dati in gioco, precedentemente descritto, richiedono una pre-aggregazione dei dati provenienti dai differenti sottosistemi al fine di comporre lo schema richiesto dalla definizione delle variabili in anagrafe. Le modalità individuate per inviare, in modalità atomica, i dati delle variabili associate ad un istanza prevedono come tecnica principale la visura da viste generalizzate sui dati dei sottosistemi (al fine di semplificare la comunicazione) e come meccanismo secondario l invio dei dati alla piattaforma tramite web service (al fine di garantire il massimo livello di disaccoppiamento tra i sistemi informativi coinvolti). Il meccanismo basato sulle viste, introdotto in fase di analisi di comune accordo con gli Enti coinvolti, definisce una modalità di integrazione basata sulla creazione di viste (statiche o materializzate) che presentano i dati acquisiti dai diversi sottosistemi in conformità con la definizione delle rilevazioni in anagrafe dei servizi. La piattaforma acquisirà tali dati, preferibilmente su avvio manuale (per avere la certezza della completezza dei dati e perché è comunque necessaria un approvazione manuale), eseguendo il mapping con le variabili associate all istanza di servizio relativa. Il meccanismo basato su web service prevede l invio da parte dell Ente di un file XML, compliant alla struttura XSD di validazione prodotta in seguito all attivazione del servizio in anagrafe, contenente tutti i dati di popolamento delle variabili associate all istanza. Nel caso in cui il dispiegamento della piattaforma preveda il deploy del modulo di aggregazione presso un Ente aggregante (quale ad esempio un Centro Servizi Territoriale o una Provincia), che ha la funzionalità di memorizzare le informazioni fornite da ciascun Ente locale, l acquisizione automatica dei dati prevede comunque l identificazione di una base dati aggregata accessibile dalla piattaforma (e.g. una vista separata per ogni Ente), che esponga i dati complessivi di interesse per la rilevazione, o la ricezione delle singole strutture dati XML (un file specifico, inviato tramite Web Service, per ogni Ente coinvolto nel monitoraggio). Per quanto riguarda la realizzazione del software che implementa le funzionalità di aggregazione dei dati, tale modulo (rif. Figura 1) è responsabile della gestione dell acquisizione automatica dei dati quali/quantitativi dai sottosistemi dell Ente, secondo un formato concordato. In tal modo, si intende regolamentare il processo di acquisizione dei dati dai vari sistemi informativi gestionali di back office degli Enti, che contengono dati sull erogazione dei servizi che sono utili al monitoraggio complessivo della qualità e quantità Pagina 6

7 dei servizi erogati da un Ente, nonché attraverso l acquisizione di aggregazioni di dati relativi a indagini statistiche svolte autonomamente dall Ente attraverso suoi canali. La figura riassume le differenti possibilità per procedere all inserimento dei dati quali/quantitativi, evidenziando i flussi informativi in ingresso alla piattaforma in base all attore che inizia la comunicazione (la piattaforma, per il recupero dei dati dalle viste; l operatore, per l inserimento manuale; i sistemi informativi dell Ente, per l invio dei dati tramite web service). Per quanto riguarda il WS client, la generazione del client avviene a partire dal WSDL (fisso) consegnato all interno del deliverable software A3P13. In entrambe le modalità di acquisizione, il processo di caricamento dei dati nel sistema di elaborazione è di tipo one-shot, ovvero avviene in maniera discreta nel tempo con un operazione atomica di invio. I moduli di inserimento dati consentono di popolare con un inserimento automatico complessivo tutte le variabili associate a un servizio, o di intervenire manualmente sulle acquisizioni automatiche, ma complessivamente la conferma dell invio dei dati verso il processo di elaborazione è un attività atomica che avviene, su azione del responsabile della rilevazione dell Ente, non appena acquisiti tutti i dati di interesse e superati i check di validità e coerenza sui dati. Una volta confermato l inserimento dei dati nel DB della piattaforma (tasto INVIA), si avviano automaticamente le procedure di elaborazione dei dati per il caricamento nel DB aggregato, intervenendo nella definizione delle tabelle per l analisi dei dati. Figura 1: Processi di acquisizione e aggregazione dei dati quantitativi La Figura 2 dettaglia l approccio architetturale nell acquisizione dei dati quantitativi dalle diverse sorgenti dati (import da parte dell operatore autenticato di un file csv/xml dopo aver selezionato una rilevazione; invio tramite WS dell XML di popolamento di una rilevazione identificata da codice Ente e codice Rilevazione; acquisizione da vista dei dati di popolamento, identificati da codice Ente e codice del Servizio). Pagina 7

8 La piattaforma espone un interfaccia specifica per l acquisizione dei diversi dati, che effettua una pre-elaborazione al fine di ricondursi ad un unico caso di validazione di una struttura XML di popolamento verso una struttura XSD-light di riferimento per la specifica rilevazione. Mentre per i primi tre flussi la definizione della coppia <XML, XSD-light> è immediata, il caso del recupero dei dati da vista è più complesso, in quanto l Ente non è tenuto a specificare nella vista il codice della rilevazione di riferimento. Pertanto, un client JMS (specifico per ogni Ente di una piattaforma, in modo da disaccoppiare parametri di configurazione della vista ed eventuale scheduling) recuperi tutti i dati di una vista e li passa ad un adapter, che sviluppa una logica specifica che, a partire dall indicazione di ente e servizio, recupera tutte le istanze popolabili in automatico e per ognuna di esse produce un XML con tutte le variabili recuperabili dalla vista. Figura 2: Schema dei processi di acquisizione dati e validazione dei dati quantitativi Il controllo avviene con una versione rilassata della struttura XSD, usata per i controlli di validazione interni alla piattaforma per abilitare un popolamento parziale (non tutte le variabili sono acquisibili in automatico) e il mancato rispetto delle restrizioni (per consentire la correzione da parte dell operatore nella fase indispensabile di approvazione, anziché scartare il dato). Pagina 8

9 2.3 Interfacce di acquisizione dei dati Tool di rilevazione dei dati quantitativi (import + inserimento manuale) Questo componente della piattaforma permette a un utente interno dell Ente, correttamente autenticato e nel rispetto dei profili previsti (Operatore Data Entry o Amministratore per l Ente di riferimento), di inserire manualmente all interno del sistema, tramite compilazione di appositi form o import di dati, le variabili (quantità numeriche intere, valori booleani) relative ai servizi oggetto di monitoraggio. Attraverso la selezione dell istanza di servizio su cui si intende lavorare, il modulo di imputazione dei dati quantitativi consente quindi, in base allo stato di popolamento dell istanza, le seguenti principali attività: Inserimento manuale dei dati, con una User Experience appositamente studiata per guidare l inserimento dei valori richiesti dalla definizione dell istanza di servizio in anagrafe, da parte degli Enti sprovvisti di sistemi gestionali informatizzati per la raccolta dei dati lato back-end. Import dei dati in formato CSV (rif. paragrafo 6.1.3) o XML (rif. paragrafo 6.1.4), con struttura analoga a quella attesa dall anagrafe, da parte degli Enti sprovvisti di sistemi gestionali informatizzati per la raccolta dei dati lato back-end; se i dati non sono conformi alla validazione light tramite XSD sono scartati completamente. Modifica dei dati già inseriti (attraverso inserimento manuale, import o tramite le modalità di acquisizione automatica della piattaforma: Web Service e viste sui DB Ente), con interfaccia analoga a quella per l inserimento manuale e form già popolati parzialmente con i dati inseriti: o Sono possibili modifiche al fine di risolvere eventuali situazioni anomale: dati errati (e.g. che non rispettano le restrizioni), incongruenti (e.g. situazioni di warning) o incompleti; o Sono possibili modifiche anche in assenza di situazioni di errore (e.g. correzione manuale di alcuni dati). Invio dei dati alla piattaforma per avviare i processi di aggregazione (i dati, in qualunque modo siano stati inseriti, sono in lavorazione e quindi modificabili come sopra descritto fino all invio alla piattaforma). La rilevazione manuale dei dati quantitativi si attiene ad un workflow predefinito che risponde alle seguenti regole: o i dati acquisiti in maniera automatica sono sempre accessibili dal tool manuale, anche se perfettamente ammissibili, per consentire l approvazione dei dati inseriti ed eventuali correzioni manuali; o non è possibile procedere con l alimentazione automatica dopo che è stato inserito almeno un valore nella struttura dati che raccoglie le istanze di variabili per il servizio (flag popolamento posto a true ), in modo automatico o manuale; o In analogia alle modalità automatiche, la funzionalità di import da file è resa disponibile per le rilevazioni attive solo se vale la condizione (popolato==false), oltre al check sul fatto che sia impostato il flag abilitazione_ins_manuale==true Viste specifiche sui sistemi dell Ente (basi dati aggregate) Come precedentemente introdotto nel paragrafo generale 2.2, la modalità principale prescelta dagli Enti per la comunicazione automatica dei dati tra i sottosistemi interni e il modulo di aggregazione prevede un unico entry-point condiviso, che memorizza all interno di Pagina 9

10 un unica serie di viste tutte le variabili di ingresso necessarie per le diverse istanze di servizio, in conformità con la definizione modellata attraverso l anagrafe dei servizi. La condivisione dei dati provenienti dai diversi sottosistemi avviene, quindi, grazie a servizi di integrazione a livello di data layer, conformemente al paradigma EII. Il file XSD, generato dinamicamente all attivazione di una nuova istanza di servizio, ne descrive la composizione in termini di variabili (lista ordinata con indicazione del nome, del tipo di dato associato e delle restrizioni caratterizzanti), definendo pertanto quali dati acquisire e quali strutture dati sono accettate. A partire dalla struttura XSD, è possibile ricostruire per ogni istanza quali dati popolare automaticamente con le informazioni presenti nella vista. L idea è quella di raccogliere tutti i dati potenzialmente utili per l Ente in un unica struttura dati logica, da cui estrarre i dati di interesse per il singolo servizio andando a legare ad ogni Ente la propria vista corrispondente, che seleziona il sottoinsieme di dati necessari per popolare tutte le variabili associate alle sue istanze di servizio. I dati provenienti dai soli sottosistemi interni possono essere selezionati a partire da un unica base di dati generalizzata, ove presente, o accedendo direttamente alle strutture dati dei singoli sottosistemi. Nel caso di dati provenienti da domini esterni, ad esempio nel caso di dispiegamento presso un Centro Servizi Territoriale o di hosting di un Ente a favore di un altro, la comunicazione dei dati può avvenire secondo i formati di cooperazione applicativa ma l interazione con la piattaforma è comunque mediata attraverso una base di dati locale che raccoglie i dati dei diversi Enti che concorrono ad alimentare le viste per il popolamento delle strutture dati del sistema. In tal modo, si introduce anche per il meccanismo di alimentazione tramite viste un disaccoppiamento tra la piattaforma e i sistemi alimentanti, consentendo di impostare per ogni istanza di servizio di ogni Ente semplicemente la vista di riferimento per il popolamento automatico delle variabili. La soluzione proposta per la comunicazione dei dati delle viste dalle strutture dati al sistema IQuEL prevede l uso di un sistema di messaggistica che disaccoppi la vista alimentante dalla piattaforma IQuEL. La tecnologia JMS definisce delle interfacce di programmazione che consentono lo scambio di messaggi tra applicazioni distribuite in rete. Nel caso specifico, si usa l implementazione dell Application Server JBoss che consente una gestione trasparente delle comunicazioni. Altran prevede quindi la fornitura di un client (comunque dispiegato lato server), separato dall applicazione IQuEL per proteggerla da ritardi e errori nell accesso ai dati esterni, che sfruttando il sistema di messaggistica di JBoss invia i dati della vista al modulo di elaborazione. In questa configurazione, non è richiesto know-how specifico per la gestione della soluzione e si garantisce una maggiore robustezza e flessibilità. Dal punto di vista architetturale, l uso di un data source esterno introdurrebbe, infatti, un possibile punto di criticità all interno del sistema IQuEL: ad esempio, tra gli scenari possibili, una vista materializzata potrebbe recuperare i dati da DB collegati in DB-LINK, introducendo una serie di anomalie (errori di collegamento, timeout nel recupero dei dati) che, se non gestite perfettamente dalle stesse soluzioni di DB-LINK, potrebbero influire sulla stabilità della piattaforma. Per disaccoppiare il sistema IQuEL dai DB alimentanti, si prevede quindi l inserimento di un client JMS che, su attivazione del super user della piattaforma (con accesso da consolle all application server) tramite script.sh specifico per Ente, provvede ad interrogare la vista di alimentazione, recuperando i dati (tramite query sulla struttura prevista per la vista) e inviando ad un modulo dell application server (MDB) che riceve il messaggio JMS e, tramite adapter, effettua una ricerca su tutte le istanze di servizio dell Ente (attive e non popolate) inserendo i dati di popolamento delle variabili recuperate, ove associate al servizio. Pagina 10

11 La responsabilità dell Ente (a causa del dover gestire l associazione del dato con i codici di Ente, Servizio e Variabile) è esclusivamente quella di predisporre una vista, compliant alla struttura IQuEL, che sia raggiungibile dal server dove risiede l applicativo. L Ente non realizza il client per l invio dei messaggi, che viene invece fornito e configurato da Altran come elemento interno alla piattaforma, sotto JBoss. E a tutti gli effetti un componente software del modulo di aggregazione, che agisce come intermediario tra le strutture dati dell Ente e quelle della Piattaforma. A livello di amministrazione sistemistica della piattaforma, è possibile predisporre per ogni Ente un client JMS specifico (personalizzando il file di configurazione per l acceso alla vista) che recupera i dati per conto del sistema IQuEL, disaccoppiandolo. Presso il sistema informativo dell Ente che gestisce la piattaforma, viene strutturata una vista (complessiva o distinta per ogni Ente) che contiene i dati di alimentazione, organizzata come modellato nella tabella seguente: Codice_ente Codice_servizio Codice_variabile Valore_variabile Data_riferimento_valori ENTE-0001 SRV-0001 A-UP-BO /12/2008 La chiave logica della vista è data dalla tupla {codice_ente, codice_servizio, codice_variabile} in modo da garantire la non sovrapposizione dei dati di popolamento, rendendo necessario per l Ente l aggiornamento dei dati prima di ogni invio. E possibile legare l esecuzione dello script di recupero dati ad un cron, per lo scheduling, ma viste le caratteristiche del popolamento (atomico per rilevazione) si ritiene la soluzione pericolosa e controproducente dal punto di vista organizzativo. Un attivazione manuale dello script consente la verifica preliminare dei dati di alimentazione, rendendo il processo pienamente efficiente e sicuro Alimentazione tramite Web Service e XML Come precedentemente introdotto nel paragrafo generale 2.2, la modalità alternativa messa a disposizione per l acquisizione automatica dei dati per popolare le variabili quantitative associate ai servizi prevede l uso del meccanismo dei web service, secondo una struttura standard dei metodi di comunicazione (WSDL di riferimento) che consente un agevole creazione dei client di invio dati presso i sistemi informativi degli Enti alimentanti (in tal modo, inviando il file XML come attachment, non è necessario un web service diverso per ogni istanza di servizio ma viene esposto un WS unico per tutta la piattaforma). La piattaforma quindi espone un servizio di alimentazione tramite apposito web service che riceve in ingresso un file XML, di cui un esempio viene descritto nel paragrafo 6.1.4, che rispetta il formato di validazione XSD (rif. paragrafo 6.1.2) associato all istanza di servizio impostata come parametro del web service. La struttura XML, se supera correttamente la validazione con la XSD associata, determina il popolamento delle variabili associate al servizio. E necessario garantire l atomicità dell operazione (un solo file XML contenente tutti i dati relativi al servizio) al fine di fornire un interfaccia comune, che agevola la creazione dei client da parte degli Enti, e soprattutto per gestire la validazione tramite XSD e trattare in modo unitario la possibile sovrapposizione degli interventi di popolamento automatico e manuale resi possibili dalla piattaforma finché l istanza di servizio risulta attiva. Pagina 11

12 2.3.4 Interfacciamento dei sistemi PEOPLE Gli Enti dovranno provvedere ad integrare i sistemi pre-esistenti per poter costruire la vista generalizzata o l XML di alimentazione da inviare tramite web service generalizzato, nel rispetto della struttura XSD di validazione generata dalla definizione del servizio in anagrafe, al fine di fornire i dati per il popolamento delle strutture dati della piattaforma. In particolare, in sede di attivazione di un servizio, quindi una volta che sono state congelate le definizioni delle variabili associate allo stesso, il sistema procede con la creazione di una struttura XSD che consentirà di definire, comunicare e validare il formato dei dati attesi per il popolamento delle variabili di ingresso. L Ente a questo punto dovrebbe realizzare i diversi adapter verso le strutture dati interne per fornire i dati memorizzati nei diversi sottosistemi per la composizione della vista o dell XML di popolamento, nel formato concordato per la piattaforma di monitoraggio. Al fine di minimizzare l impatto delle modifiche sui sistemi pre-esistenti da integrare e tenendo conto che attualmente alcuni Enti IQuEL hanno la piattaforma prodotta dal progetto PEOPLE, Altran Italia ha offerto come elemento migliorativo la realizzazione di un adapter (connettore, ovvero un estrattore di contenuti informativi ) da fornire agli Enti per prelevare agevolmente un sottoinsieme di dati da opportune viste definite sulle strutture dati del framework People. Nell organizzazione assunta dal progetto, l estrattore dei dati da People coincide con il datamart già sviluppato dal Comune di Firenze, non essendo possibile eseguire ulteriori estrazioni predefinite sul framework. Resta comunque di responsabilità dell Ente usufruire dei dati prelevati da People per la composizione della vista materializzata di data entry o per la composizione dell XML di popolamento, che deve tener conto della definizione del servizio operata in anagrafe dal responsabile della rilevazione e deve includere la presenza dei codici IQuEL di identificazione (di ente, tipologia del servizio e variabile a cui si riferisce il valore). Pagina 12

13 3 Processo di acquisizione dei dati qualitativi L acquisizione dei dati qualitativi è svolta interamente attraverso i servizi della piattaforma, consentendo l inserimento dei dati da parte del target individuato per il questionario pubblicato dall Ente: solo cittadini, solo operatori, cittadini e operatori, cittadini selezionati tramite codice di riconoscimento dell invito. Come già implementato per il prototipo e raffinato nel rilascio dei servizi di anagrafe e inserimento dei dati quantitativi, tra le funzionalità attivabili dagli operatori autenticati c è quella per il data entry delle risposte ai questionari acquisite dai cittadini tramite indagini telefoniche o questionari cartacei. Selezionando tra quelli disponibili il questionario per il quale si intendono inserire i dati, il sistema consente all operatore di inserire le risposte alle domande del questionario, presentate secondo la successione dettata nella creazione del questionario e influenzata dalla presenza di percorsi condizionati. Le domande gestite sono di diverse tipologie: semplici o strutturate (composte da qualificazioni, ovvero sottodomande ), a selezione singola o multipla, con gestione dell ordinamento, con risposte aperte. I tasti avanti e indietro consentono una navigazione a ritroso nelle risposte date, consentendo correzioni. Col tasto avanti, se non si è modificata la precondizione di qualche percorso condizionato, si ripercorre la precedente navigazione trovando impostate le domande precedentemente compilate. Al termine della rilevazione, l operatore memorizza le risposte inserite e il sistema rimostra la lista iniziale, rendendo possibile la compilazione di un nuovo questionario. I cittadini dell Ente possono accedere, singolarmente, ad ogni questionario pubblicato dall Ente per partecipare nel periodo di pubblicazione all indagine statistica. I cittadini vengono a conoscenza della URL logica del questionario tramite di partecipazione ricevuta dall Ente o accedendo al questionario dopo aver fruito online del servizio nella sezione online dei servizi al cittadino dell Ente. Per i questionari aperti a tutti i cittadini, accedendo all URL viene mostrato il messaggio introduttivo di partecipazione al sondaggio (comprensivo di tutte le dichiarazioni sul rispetto della privacy e sulle finalità della rilevazione statistica) con la possibilità di partecipare all indagine. Per i questionari che richiedono un invito di partecipazione, il concetto è analogo ma per iniziare a compilare il questionario è richiesto di inserire il codice di partecipazione, lo stesso per ogni utente invitato. Il cittadino compila quindi, di domanda in domanda, il questionario, secondo una successione dettata dalla configurazione del questionario e influenzata dalla presenza di percorsi condizionati. Al cittadino possono essere proposti diversi tipi di domande: semplici o strutturate (composte da qualificazioni, ovvero sottodomande ), a selezione singola o multipla, con gestione dell ordinamento, con risposte aperte. I tasti avanti e indietro consentono una navigazione a ritroso nelle risposte date, consentendo correzioni. Col tasto avanti, se non si è modificata la precondizione di qualche percorso condizionato, si ripercorre la precedente navigazione trovando impostate le domande precedentemente compilate. Al termine della rilevazione, è richiesta la corretta compilazione del captcha per procedere all invio delle proprie risposte. Dopo l invio, il sistema mostra il messaggio di ringraziamento collegato al questionario. Se il cittadino, all interno della stessa sessione di navigazione, tenta di riaccedere al questionario il sistema previene la possibilità di voto ripetuto e mostra un messaggio di errore specifico, inibendo l accesso alla compilazione del questionario. Le strutture dati sottostanti sono gestite direttamente dalla piattaforma. Pagina 13

14 In aggiunta a tale modalità, gli Enti hanno richiesto la possibilità di inserire dei dati qualitativi acquisiti attraverso indagini CATI. L alimentazione automatica non supporta il caricamento dei dati nella loro forma elementare (ovvero dove ogni sessione di popolamento del questionario è memorizzato in dettaglio attraverso i dati raccolti nelle tabelle storico_questionario e storico_risposta) ma esclusivamente i dati di riepilogo su consultazioni svolte attraverso altri strumenti rispetto alla piattaforma di monitoraggio (e.g. CATI o questionari cartacei), identificando il questionario tramite i codici identificativi dell Ente e del questionario. Il sistema supporta pertanto l acquisizione dei dati aggregati, complessivi per un questionario, andando a memorizzare direttamente i valori totali sul popolamento del questionario (ovvero, per ogni risposta a domande/qualificazioni, vanno acquisiti il numero e la percentuale di voti). Il caricamento dei dati sul questionario avviene comunque a livello di console di gestione, dove il questionario per l Ente interessato a caricare i dati acquisiti esternamente deve comunque essere stato precedentemente inserito. Una volta attivato il questionario, è possibile procedere con l import dei dati (caricati in formato XLS). Il sistema verifica che i dati in ingresso siano compliant con il questionario che si è selezionato per il popolamento e procede con la memorizzazione dei dati nell apposita struttura di aggregazione, estendendo le informazioni da file con quelle già presenti nella piattaforma. Il questionario viene quindi posto nel nuovo stato di elaborato, senza dare la possibilità di inserire ulteriori dati di popolamento. Pagina 14

15 4 Processo di aggregazione dei dati quali-quantitativi Una volta confermata l acquisizione dei dati, già validati in tutti i possibili path di popolamento mediante confronto con la struttura XSD di validazione/definizione associata alla singola istanza di servizio, una specifica procedura ETL provvede a rimuovere i dati dalle strutture dati operative per alimentare le rispettive strutture dati a supporto dell analisi, alimentando una struttura dati specializzata che consente di effettuare attività di analisi e reporting. Per supportare il pieno rispetto delle caratteristiche di dinamicità del servizio, offerte dall anagrafe, non è possibile procedere con la definizione di trasformazioni univoche per il calcolo degli indicatori di qualità. Come modellato nello schema in Figura 3, sarà un esperto statistico dell Ente a modellare le relazioni (elementari) tra variabili e indicatori, intermedi o complessivi, attraverso una specifica interfaccia di gestione del modulo di aggregazione. Le trasformazioni sono inserire come relazioni a livello di piattaforma, indipendentemente dalle istanze di servizio presenti. Selezionato un indicatore, l esperto statistico inserisce le trasformazioni (composizione di operazioni elementari) per valorizzarli a partire dalle variabili (o da combinazioni matematiche di variabili e altri indicatori derivati) o dalle percentuali di risposta alle domande dei questionari ad essi associate. La piattaforma, ricevendo i dati tramite il tool per l inserimento dei dati quali/quantitativi e dal modulo di aggregazione (per i dati provenienti dai sottosistemi dell Ente) le variabili d uso/performance e quelle sulla qualità progettata/erogata, provvede ad alimentare le strutture dati aggregate corrispondenti. Il modulo di aggregazione riceve dal tool per l inserimento dei dati qualitativi le risposte dei questionari, le aggrega (calcolo della media per ogni singola risposta) e ne deriva gli indicatori di customer satisfaction attraverso le regole di trasformazione definite. Infine, il modulo di aggregazione applica le trasformazioni definite per il calcolo degli indicatori derivati/complessivi. Pagina 15

16 Figura 3: Processo di elaborazione degli indicatori Il modulo A3P13 gestisce i processi per l acquisizione, la validazione, il controllo incrociato e l aggregazione dei dati contenenti le informazioni per il monitoraggio dei servizi. Il modulo riceve in ingresso i dati provenienti da diversi sottosistemi, interni ed esterni, coinvolti nel monitoraggio, esponendo delle interfacce di comunicazione standard e non proprietarie, essenzialmente tramite web services, view tra database e scambio di strutture dati XML. Come conseguenza del processo definito in Figura 3, il processo di elaborazione degli indicatori è gestito direttamente dai moduli software della piattaforma (A3P13), pertanto a differenza di un tradizionale sistema di DataWareHousing i processi di alimentazione delle strutture dati non possono essere gestiti direttamente dalle procedure ETL. Da qui derivano le necessità di gestire le operazioni di acquisizione dei dati dai sistemi dell Ente, tipiche dei processi ETL di Load Management nei sistemi di DWH, attraverso i moduli software della piattaforma come descritto nel capitolo precedente. La necessità di gestire la complessità dell acquisizione dei dati e delle prime trasformazioni richiede una validazione formale dei dati acquisiti per garantire la consistenza, svolgendo in maniera interattiva un servizio di Data Validation che agisce su tutti i dati in ingresso (inserimento manuale, import XML o CSV, XML via web service, prelievo dei dati da viste sui DB dell Ente). Le strutture dati in ingresso tramite web service sono validate grazie alle strutture XSD specifiche (relativamente all istanza di servizio e quindi all Ente) e quindi in base ai descrittori presenti nell anagrafe dei servizi per la rilevazione. Tale processo garantisce il maggior livello di flessibilità, al fine di minimizzare l effort di integrazione presso i sottosistemi aderenti, tramite le funzionalità di validazione applicata eseguendo un controllo con la struttura XSD del servizio da popolare, generata dinamicamente a partire dall anagrafe dei servizi. Pagina 16

17 I dati incompleti o errati, se la configurazione in anagrafe lo prevede, sono a disposizione degli operatori per il completamento con i dati non estraibili direttamente dai sottosistemi informativi o la correzione di quelli mal definiti. Il sistema definisce uno stato per ogni dato in ingresso, verificando la validità del valore inserito. In particolare, il valore associato ad una variabile determina lo stato OK se rispetta tipo e vincoli formali sui valori assumibili e se non esistono altri valori associati alla stessa variabile, se annuale, in altre istanze attive del servizio. Il valore associato ad una variabile determina lo stato KO se non rispetta il tipo di dato o i vincoli formali sui valori assumibili. Il valore associato ad una variabile determina lo stato WARNING se più istanze della variabile annuale, nello stesso anno di osservazione, assumono valori diversi per istanze di servizio dello stesso Ente. I dati correttamente validati, in maniera automatica dal processo di data validation o manualmente dall operatore attraverso il Tool di inserimento e gestione dei dati quantitativi, così come i dati qualitativi (già formalmente validati a livello di applicazione web) provenienti dai servizi di sondaggio, sono quindi direttamente aggregati in una struttura di aggregazione, rendendo disponibili le informazioni a utenti ed amministratori per consentire loro di effettuare attività di reporting.. I dati infatti, già parzialmente aggregati e privi di collisioni, sono raccolti direttamente in una struttura dati specifica per l analisi degli indicatori da parte dei sistemi di business intelligence, conformemente alle strutture dati descritte nel capitolo seguente. Per le risposte ai questionari, le procedure di aggregazione provvedono al calcolo della media (per le domande associate all indicatore di qualità complessiva) e a determinare la cardinalità di ogni singola risposta (% di frequenze delle diverse risposte alla domanda) Definizione dinamica delle trasformazioni tramite piattaforma La definizione degli indicatori semplici (definiti anche variabili o misure) consente di descrivere quali dati sono associati al servizio. Tali dati (inseriti dagli operatori attraverso i tool manuali, prelevati automaticamente dai sottosistemi o acquisiti dal tool per la gestione dei questionari) sono acquisiti dal modulo di aggregazione e forniscono delle informazioni oggettive e misurabili sul servizio. Esempi di indicatori semplici possono essere il numero di pratiche gestite presso uno sportello dell Ente, la durata media di una chiamata al contact center, il numero annuale di ore di apertura di uno sportello, le valutazioni degli utenti sulla qualità di un aspetto del servizio, etc. L interfaccia utente del modulo di aggregazione consente quindi di definire le trasformazioni da adottare per il calcolo degli indicatori derivati (a partire dalla combinazione matematica di più variabili ed, eventualmente, altri indicatori derivati) e degli indicatori complessivi (a partire dalla combinazione di variabili e indicatori derivati). Come definito congiuntamente con gli Enti, l indicatore complessivo di customer satisfaction è relativo alle sole valutazioni complessive espresse dai cittadini nelle diverse forme di consultazione. Viceversa, l indicatore complessivo calcolato è una valutazione di ciò che è progettato realizzata definendo trasformazioni che effettuano una ponderazione tra diversi indicatori (semplici o derivati) al fine di definire un livello di qualità progettata. Pagina 17

18 Tutte le trasformazioni sono realizzate dagli esperti statistici costruendo le regole di trasformazione attraverso formule elementari (e.g. l espressione IND_DER_1 = (Var_A + Var_B) / Var_C ), guidando l utente nella creazione di una formula matematica formalmente consistente. Le formule usate per il calcolo degli indicatori saranno anche condivise/validate dal lavoro degli esperti statistici degli Enti Attivazione dei processi ETL Dati Quantitativi I moduli della piattaforma non gestiscono il lancio diretto dei processi ETL: il processo ETL monitora tutte le istanze di servizio che sono (attive & inviate), provvedendo ad aggregare i dati corrispondenti e a modificare lo stato dell istanza di servizio in archiviato al termine del processo, memorizzando anche la data di calcolo dell indicatore. All atto dell archiviazione della rilevazione, le istanze delle variabili associate vanno storicizzate nella tabella di aggregazione DM_ISTANZE_VARIABILI (con chiave logica <cod_ente, cod_rilevazione, cod_variabile>). La struttura della tabella di destinazione è la seguente: c_ente c_servizio c_rilevazione nome_r descriz_r inizio_interv_ril fine_interv_ril macrostruttura c_variabile tipo_dato_v valore_v data_ultima_modifica_v unità_misura nome_v descriz_v tipol_v sottotipol_v. I dati elaborati sono rimossi dalle tabelle applicative istanza_variabile e variabile_servizio. Contestualmente all archiviazione, si procede con il calcolo dei valori degli indicatori associati, elaborando le trasformazioni definite in anagrafe. La memorizzazione della data di calcolo dell indicatore consente di creare, in seguito, dei report che mettano in risalto la dimensione temporale degli indicatori (con granularità data dalla frequenza di creazioni delle rilevazioni per la raccolta dei dati). In ogni caso, come sviluppo sulla reportistica di base richiesta dal progetto, la scelta è caduta su una visione gerarchica dei dati e sulla creazione di un cruscotto riassuntivo sulla qualità dei servizi; per un analisi temporale dei dati, infatti, non sono presenti neanche rilevazioni ripetute che consentano di analizzare tale dimensione. Per il raggiungimento degli obiettivi progettuali, si offrono quindi dei dashboard che consentono una visione complessiva della rilevazione, dal generale al particolare Attivazione dei processi ETL Dati Qualitativi Nel caso più generale, la console di gestione della piattaforma non gestisce il lancio diretto dei processi ETL (che avviene invece sugli import XLS dei dati già aggregati). All atto dell elaborazione dei dati ricevuti, il sistema richiama le funzionalità di calcolo delle istanze di indicatori associati al questionario, elaborando le trasformazioni definite in anagrafe. Per i questionari gestiti internamente alla piattaforma, l avvio ai processi di aggregazione e business intelligence è dato dall operatore che pone un questionario nello stato archiviato. I processi ETL sui dati qualitativi sono schedulati per monitorare la tabella questionario. Quando riscontrano un nuovo questionario nello stato archiviato, procedono con l aggregazione dei dati e il popolamento della tabella dm_questionario in modo trasparente per il modulo A3P1. Al termine del processo, il questionario è posto nello stato elaborato. Il processo ETL rimuove, inoltre, i dati dalle tabelle di storico. Pagina 18

19 4.1.4 Possibili sviluppi futuri della piattaforma Nella fase di analisi e progettazione della piattaforma di monitoraggio, si è privilegiato un approccio basato sul concetto di anagrafe dei servizi e generalità, prevedendo la possibilità di definire dinamicamente all interno della piattaforma non solo quali indicatori misurare per ogni servizio, ma anche quali sono le trasformazioni che legano un singolo indicatore alle variabili o alle percentuali di risposte alle domande che logicamente ne consentono il calcolo. Tali trasformazioni sono ottenibili attraverso la gestione di formule matematiche che fanno uso dei soli operatori di base (+, -, * e /) e che consentono di comporre le variabili o le risposte a questionari attivi presenti nella piattaforma. Il tutto in piena coerenza con l approccio organizzativo e la metodologia di progetto che impone che, rispetto a sistemi generici di BI, la piattaforma IQuEL offra un unico ambiente la definizione dell'anagrafe dei servizi e delle trasformazioni sui dati, connessi alla reportistica. Il sistema può naturalmente evolvere verso una soluzione in cui le formule non sono gestite esclusivamente attraverso la consolle di gestione della piattaforma ma direttamente a livello di strumenti di Business Intelligence, ad esempio definendo il calcolo degli indicatori direttamente sul cubo dei dati raccolti, usando Mondrian Cube Designer di Pentaho. In tal modo, si aumenta la complessità delle trasformazioni gestibili, consentendo delle elaborazioni statistiche (quali ad esempio prendere come riferimento la mediana anziché la media nell uso delle risposte ai questionari per calcolare indicatori qualitativi). Come conseguenza diretta, la gestione delle relazioni su Mondrian Cube Designer rallenta i vincoli sul rispetto della definizione dei servizi in anagrafe, consentendo ad un esperto statistico di costruire report o indicatori sui dati aggregati, a patto di rispettare la semantica del dato. Pagina 19

20 5 Specifiche del DB contenente i dati aggregati di monitoraggio Strutture dati contenenti i dati aggregati sui questionari Campo Descrizione Tabella origine Codice_ente Codice IQuEL dell Ente Ente Nome_ente Nome dell Ente Ente Codice_questionario Codice IQuEL del questionario Questionario Nome_questionario Nome del questionario Questionario Descrizione questionario Descrizione del questionario Questionario Data_inizio_pubblicazione Data di attivazione della rilevazione Questionario Data_fine_pubblicazione Data di conclusione della rilevazione Questionario Codice_servizio Codice IQuEL della tipologia di servizio eventualmente associata al questionario Servizio Codice_istanza_servizio Codice IQuEL dell istanza di servizio eventualmente associata al questionario Istanza_servizio Anno_riferimento Anno di riferimento del questionario Questionario Msg_introduzione Messaggio di introduzione del questionario Questionario Msg_ringraziamento Messaggio di ringraziamento del questionario Questionario Codice_domanda Codice IQuEL che identifica la domanda Domanda Codice_dom_precondizione Codice_risp_precondizione Codice IQuEL identificativo della domanda che condiziona la visualizzazione di quella corrente Codice IQuEL identificativo della risposta associata dalla domanda padre per determinare la visualizzazione della domanda corrente Percorso_condizionato Percorso_condizionato Testo_domanda Testo della domanda Domanda Ordine_domanda Identificativo della domanda Domanda Max_items_domanda Numero massimo di elementi selezionabili per la Domanda o domanda/qualificazione Qualificazione_domanda Tipo_domanda Tipologia della domanda (semplice, composta o con priorità) Domanda Codice_qualificazione Codice IQuEL identificativo della qualificazione (presente solo se la domanda è composta). Qualificazione_domanda Testo_qualificazione Testo della qualificazione Qualificazione_domanda Ordine_qualificazione Ordine della qualificazione all interno della domanda Qualificazione_domanda Codice_risposta Codice IQuEL identificativo della risposta Risposta Testo_risposta Testo della risposta Risposta Risposta_aperta Indica se la risposta è di tipo aperto Risposta Visibile Indica se la risposta è effettivamente selezionabile Risposta Priorita_risposta Ordine della risposta Storico_risposta Testo_risposta_aperta Valore inserito per la risposta aperta Storico_risposta Numero_risposte Calcolo del numero di occorrenze per ogni risposta Storico_risposta Percentuale_risposte Calcolo della percentuale di occorrenza di ogni risposta Storico_risposta Strutture dati contenenti i dati aggregati sulle istanze di variabili: Campo Codice_ente Codice_servizio Codice_rilevazione Nome_rilevazione Descrizione_rilevazione Inizio_rilevazione Fine_rilevazione Macrostruttura Descrizione Codice IQuEL identificativo dell Ente di riferimento Codice IQuEL identificativo della tipologia di servizio Codice IQuEL identificativo della rilevazione Nome mnemonico della rilevazione Campo con la descrizione Periodo di riferimento della rilevazione Periodo di riferimento della rilevazione Eventuale struttura di riferimento dell Ente Pagina 20