• Non ci sono risultati.

L’architettura del sistema integrato di acquisizione dati e gestione della rilevazione14

3.4 La base dati

3.4.1 La base di dati Sgr: struttura, popolamento e gestione

Per la gestione del Sistema di monitoraggio della rete di rilevazione è stata realizzata una base di dati Oracle versione 11g ospitata fisicamente in hosting, composta da oltre un centinaio di tabelle, circa cinquecento indici e vincoli di unicità e congruenza, oltre trecento Oracle store procedure e

function, decine di trigger per la generazione dei dati storicizzati e altrettante viste materializzate di ausilio per l’estrazione rapida dei dati.

Da un punto di vista concettuale è possibile suddividere il database di Sgr in categorie tematiche di dati gestiti e manutenuti nel corso dell'attività censuaria:

 i dati delle sezioni di censimento e degli itinerari di sezione;

 i dati provenienti da Lac (Liste Anagrafiche Comunali) di famiglie e convivenze;

 le sotto-coperture anagrafiche provenienti da Lifa (Liste ausiliarie famiglie anagrafiche) e da Rnc (Rilevazione dei numeri civici);

 i dati riguardanti gli indirizzi;  i dati inerenti gli edifici;

 i dati di gestione della rete di rilevazione;

 i dati di log e storicizzazione generati ed utilizzati dal sistema.

In ogni tabella è stato creato un vincolo chiave di unicità attraverso cui le strutture sono state messe in relazione tra loro e grazie al quale è stata garantita la congruenza e la consistenza dei dati.

Dovendo contenere grandi quantità di dati, sono stati inseriti nei punti di maggiore accesso alla base di dati una serie di indici per l'ottimizzazione, in termini di performance temporali, delle procedure di estrazione ed elaborazione dei dati utilizzate dalle applicazioni di acquisizione on line e dal Sistema di Gestione e monitoraggio della rete di Rilevazione.

Il popolamento della base di dati è stata un'attività complessa e lunga; i processi Oracle di caricamento si sono diversificati in base alla fase di lavorazione ed al tipo di dato trattato. Il primo elemento di difficoltà è stato dato dalla pluralità delle fonti a cui attingere per il popolamento delle tabelle: basi di dati Oracle, file tipo csv, file formato excel, ecc. Primaria è stata quindi anche l'attività di integrazione delle informazioni che ha coinvolto in sinergia le unità di competenza statistica ed informatica.

Con l'obiettivo di snellire la fase di controllo e minimizzare al massimo gli eventuali ricicli dei dati nella base di dati di produzione in hosting (eliminazione e successivo reinserimento), è stata realizzata una struttura di base dati interna Istat, posta come passo intermedio tra le varie fonti di acquisizione ed il sistema di produzione finale.

Data l’elevata numerosità dei dati in termini di occorrenze, le procedure previste per l'inserimento nelle strutture tabellari hanno avuto tempi di esecuzione non indifferenti, in particolar modo per i grandi comuni. Per agevolare la migrazione e trasformazione dei dati senza gravare troppo sulla rete informatica dell'Istituto, sono stati studiati ed implementati job Oracle con esecuzioni notturne asincrone direttamente sui server virtuali dedicati. In questa attività di preparazione della base di dati è stata importante la collaborazione con i sistemisti dello hosting che hanno supportato con continuità il gruppo Istat dedicato alla gestione ed al monitoraggio dei job Oracle nelle fasi di caricamento massivo, avvenuto principalmente nelle ore notturne della giornata.

Fondamentale e capillare è stata la doppia fase di controlli di congruenza e consistenza, sia a livello intermedio che conclusivo, sulla totalità della base di dati realizzata attraverso routine Oracle previste a fine caricamento (figura 3.4)

Le informazioni inerenti le sezioni di censimento, gli indirizzi, le Lac di famiglie e convivenze, gli edifici e tutto l’insieme di informazioni utili al sistema Sgr per il suo funzionamento, sono state tra le prime ad essere caricate all'interno delle base di dati con una operazione continua nel tempo. Un secondo ciclo di popolamento dati è stato effettuato a Censimento avviato, quindi parallelamente all’utilizzo già possibile, a cittadini e rilevatori, del sistema di acquisizione on line Qpop e di Sgr. Questa fase successiva di inserimento, trasformazione e controllo dei dati è stata molto delicata e più lenta della precedente attività informatica.

Per non interferire con i sistemi censuari già aperti agli utenti, le operazioni si sono concentrate nelle sole ore notturne della giornata e le verifiche di coerenza e consistenza dei dati non sono state effettuate solo a fine ciclo di caricamento, ma anche per ogni singolo dato migrato, mantenendo quindi la base dati sempre in condizioni di funzionamento ottimale e sicuro.

Il Sistema Sgr durante tutto il periodo di esercizio dell’applicazione web è stato continuativamente monitorato, manutenuto e aggiornato come è accaduto per la fase di revisione dei dati anagrafici, di indirizzo e sezioni di censimento, a fronte della seconda acquisizione della Lac, in cui si è proceduto a modificare ed integrare tutte le informazioni anagrafiche variate nel tempo rispetto al primo caricamento.

Figura 3.4 - Flusso dei controlli tramite Pl/Sql

  3.4.2 Amministrazione e tuning della base dati

Le attività di amministrazione e tuning della base dati Oracle si sono concentrate principalmente durante le fasi di caricamento, controllo e correzione dei dati censuari.

L’attività degli amministratori della base dati ha comportato, in particolare, la creazione di 10 utenze Oracle, sia di sviluppo che di esercizio, afferenti a più database localizzati nei vari server interni all’Istituto. Tale creazione è stata subordinata a preliminari operazioni di individuazione dei

server Linux più adatti per le esigenze di dimensionamento e delle istanze Oracle più appropriate per le condizioni di utilizzo delle utenze da creare.

La fase di acquisizione dei dati censuari, provenienti sia dai questionari compilati on line, sia da quelli cartacei preventivamente scansionati tramite processi di lettura ottica, ha comportato una costante attività di monitoraggio dell’effettiva funzionalità ed efficacia delle operazioni messe in atto per il caricamento dei dati stessi sulle varie tabelle; tale attività si è tradotta principalmente nello svolgere operazioni di controllo dei processi Oracle connessi all’esecuzione di job, funzioni e stored procedure.

Contestualmente alla fase di acquisizione e alla successiva fase di gestione dei dati, sono state effettuate continue operazioni di monitoraggio ed ottimizzazione degli spazi su disco, sia tramite controllo visivo attraverso i software di amministrazione delle basi dati a disposizione dell’Istituto, sia tramite la creazione di procedure e job Oracle progettati e sviluppati ad hoc. Frequenti sono stati i contatti con il gruppo dei sistemisti Linux per eventuali richieste di allargamento dei filesystem che ospitavano le varie utenze Oracle; contatti a cui spesso hanno fatto seguito operazioni di estensione e adattamento di tablespace Oracle laddove necessario, in funzione delle mutevoli esigenze di spazio derivanti dalle attività di correzione e controllo dei dati censuari.

Periodicamente sono state inoltre effettuate operazioni di import ed export delle utenze Oracle o di porzioni di esse, sia per la creazione di backup specifici non inquadrabili nell’ambito delle politiche standard di backup dell’Istituto, sia per la migrazione su istanze ritenute di volta in volta più efficienti e più adatte ad ospitare i dati censuari, a seguito di sopravvenute e modificate necessità di gestione, aggiornamento e futura diffusione dei dati stessi.

Occorre infine ricordare come per alcune delle suddette attività di amministrazione necessarie al corretto ed efficiente funzionamento dei database Oracle, con particolare riferimento a quelle legate al controllo dei processi Oracle di caricamento e correzione dei dati censuari, è stato fatto tesoro dell’esperienza acquisita durante lo svolgimento delle stesse attività effettuate nel corso della Rilevazione censuaria pilota del 2009.