Studio di fattibilità per la realizzazione del sistema ... · Rapporto finale Schede di...

REGIONE LAZIOAssessorato Personale, Demanio

Patrimonio ed Informatica

Studio di fattibilità per la realizzazione del sistema informativo-statistico della regione lazio

Rapporto finale

Schede di informazione statistica

luglio 2002

SISTEMA STATISTICO REGIONALE

Regione Lazio

Direttore del progetto: Roberto De Vecchis Sistema Statistico Regionale

Archivio banche dati: Laura Baldini

Sistema Statistico Regionale

Paolo Risso e-Government

Ruggero Trenna

Dip.to Interventi socio-sanitari, educativi e per la qualita’ della vita

Università di Roma “La Sapienza”

Prof. Alberto Marchetti-Spaccamela, Prof. Silvio Salza, Prof. Giuseppe Santucci Dip.to di Informatica e Sistemistica

Paolo Giulio Franciosa

Dip.to di Statistica, Probabilità e Statistiche Applicate

iv

Introduzione

L’organizzazione di un moderno sistema informativo ha come presupposto una struttura

organizzativa scientifica con l’obiettivo di sistematizzare la conoscenza depositata nei diversi

uffici che attuano i processi operativi sia della regione che degli altri enti pubblici e privati che

svolgono attività a favore del cittadino.

Questa informazione, preziosa per un governo che sia caratterizzato da massima “efficienza,

efficacia, ed economicità”, è infatti diluito in molti e diffusi ambiti che spesso risultano di

difficile reperimento e comunque tra loro scoordinati.

Spesso questo clima di separazione comporta di fatto l’impossibilità di usufruire di preziose

informazioni da parte degli operatori. Così allo stesso modo risulta difficoltoso, in mancanza di

cruscotti informativi, orientare i “decisori pubblici” verso forme di valutazione delle decisioni

di investimento e nella verifica degli effetti da queste ottenute.

La direzione della Giunta regionale ne risulta spesso menomata, cosicché diviene necessario

ricorrere a faticose e anche costose ricerche, per ottenere le necessarie conoscenze.

Il progetto di studiare un moderno strumento che offra un “cruscotto informativo” diviene una

necessità, nella misura in cui si voglia consentire un governo che utilizzi le stesse metodologie

che da anni ormai adottano gli imprenditori nel governo delle loro imprese.

La stessa regione si è dotata di strumenti di controllo strategico e di controllo gestionale, per

la verifica degli interventi operativi, strumenti che si ritrovano e sono mutuati nelle conduzioni

aziendali private.

Ciò consentirebbe di conoscere la “soddisfazione degli utenti”, come ulteriore verifica della

bontà delle azioni intraprese dalle diverse aree di intervento pubblico, al pari del controllo che

effettuano gli imprenditori sulla soddisfazione riscontrata nei loro prodotti.

Queste esigenze, di cui la Regione Lazio si rende interprete, devono essere estese anche a tutti

gli altri enti pubblici che operano a favore del cittadino, su risorse pubbliche. Per divenire

concrete devono basarsi su due paradigmi: da un lato una moderna struttura di rete

informatica e dall’altro una corretta struttura “informativo-statistica”.

La rete di e-government, attualmente in fase organizzativa, si estende in ambito comunale,

provinciale, regionale, nazionale. Questa deve assicurare concretezza operativa alla necessità

del riordino della enorme mole di archivi esistenti, giacenti in modo spesso disordinato nelle

diverse strutture pubbliche regionali e/o degli altri enti locali e nazionali.

v

Questa “ricchezza” informativa deve quindi trovare un “contenitore” unico in grado di offrire

un valore aggiunto alla attività faticosa di chi desidera governare avendo in mente i

comportamenti virtuosi degli investitori privati.

L’obiettivo di questo studio condotto dall’Assessorato Personale, Informatica e Statistica,

attraverso il Sistema Statistico Regionale, si inquadra quindi nell’ottica di recupero e

valorizzazione delle diverse fonti informative esistenti per creare un pannello di governo che

possa facilitare scelte strategiche e consentire gestioni oculate e moderne delle risorse

disponibili a favore, sia dei cittadini, che dello sviluppo economico.

Rilevo che una Pubblica Amministrazione moderna costituisce un anello fondamentale

dell’intero sviluppo socio-economico del territorio. Una struttura pubblica all’altezza delle

aspettative quale fornitore di servizio nel moderno processo produttivo, diviene punto di forza

essenziale per lo sviluppo e l’elevazione del benessere generale.

Questo non solo dà certezza di aver bene operato, ma costituisce di per sé l’orgoglio civico di

chi come noi sente tutta intera la responsabilità di dover contribuire al bene delle popolazioni

amministrate.

On. Francesco Storace

vi

Presentazione

Il presente studio è realizzato nel piano operativo di ammodernamento dell’attività

amministrativa della Regione Lazio attraverso una duplice strategia: prendere atto dello stato

di arretratezza in cui versava il sistema informativo, ed operare con rapidità a colmare un gap

ormai sempre più profondo tra la società amministrata e l’arretratezza degli strumenti pubblici

per rispondere alle sfide dello sviluppo.

Sul versante della costruzione di una rete di e-government l’obiettivo è legare in un unico e

solidale schema di trasmissione informativa tutti gli enti pubblici della Regione Lazio così da

migliorare attraverso lo strumento informatico la potenzialità operativa e aumentando in tale

modo la produttività pubblica, non solo regionale, ma dell’intero sistema delle autonomie

locali.

Infatti il piano di”e-government”, oggi in fase di avanzata realizzazione, può costituire una

valida risposta al ritardo accumulato in questi anni di mancata introduzione delle tecnologie

informatiche nella Pubblica Amministrazione. Questi strumenti devono essere anche al servizio

del sistema statistico regionale per la diffusione dell’informazione.

Il piano di lavoro nella costruzione di sistemi informativi si identifica in due diverse fasi:

1. la prima fase della realizzazione di rete di e-government, consente di offrire all’utente

cittadino fin da subito, di accedere a servizi (on line) in modo da facilitare il suo rapporto con

la P.A. in termini di certificazione, ecc.;

2. la seconda, di medio periodo, permette l’interconnessione tra tutte le amministrazioni e

la condivisione informativa anche con altri soggetti quali famiglie ed imprese, attraverso la

realizzazione di un portale unico (one-stop shops).

Questa seconda fase coincide con la “rivoluzione culturale” che dovrà investire l’operatività

pubblica attraverso una struttura organizzativa che ne migliori l’efficacia nell’intervento

pubblico a favore del miglioramento della vita del cittadino e dell’aumento di competitività del

“sistema Paese” .

Sotto questo profilo la “statistica”rappresenta una funzione strategica, per lo sviluppo della

seconda fase di e-government, attraverso la possibilità dello scambio delle “informazioni” tra i

diversi soggetti coinvolti e non di semplici scambi di dati. Le “informazioni” infatti

provengono da una corretta organizzazione dei dati e metadati.

La statistica che per definizione costituisce la “scienza dello Stato” consente attraverso gli

strumenti metodologici che le sono propri, di avere attraverso una base di flussi informativi,

realizzata secondo un criterio organizzativo a rete nei “sistemi statistici” nazionali e locali, la

conoscenza dei fenomeni socio-economici. Inoltre una buona organizzazione statistica consente

vii

l’adozione di linguaggi standard per lo scambio tra tutti i soggetti interessati di “polis di

governo”, effettuate su dati (e metadati), così da assicurare l’adozione di politiche più

adeguate in termini di efficacia, efficienza ed economicità, e la loro verifica, attraverso la

misura della soddisfazione dell’utente (customer).

La Regione Lazio ha quindi attraverso il SISTAR-Lazio attuato la funzione operativa del

“Federalismo Statistico”così da consentire la partecipazione delle strutture statistiche

provinciali e comunali, identificando attraverso il “Piano Statistico Regionale” gli strumenti

più adeguati per l’uso di indicatori appropriati e condivisi da applicare alle metodologie di

programmazione pubblica.

Allo stato si osserva che nel quadro dell’organizzazione statistica esistente si evidenziano due

grandi aggregati informativi: le informazioni derivanti da indagini campionarie o dai

censimenti e quelle derivanti dall’attività amministrativa (giacimenti informativi

amministrativi). Questi giacimenti costituiscono un grande serbatoio di dati che possono

soddisfare esigenze informative a più basso costo rispetto ai primi, solo se questi sono

organizzati con criteri metodologici adeguati. Legare le informazione dei censimenti con gli

archivi amministrativi consente di abbassare i costi di produzione informativa, di ottenere

informazioni dinamiche territorializzate (Geographich Information System - G.I.S.) consente

inoltre di aggiornare e verificare lo stato degli archivi esistenti.

Sul versante della organizzazione statistica per l’e-government si è preso atto che a fronte di

giacimenti informativi di grande consistenza distribuiti in ogni “ufficio”operativo pubblico

l’informazione statistica ricavabile è a causa di una generale disattenzione “ di politica

dell’informazione” pressoché nulla; essa cioè, non fornisce alcun contributo alle esigenze

conoscitive per le scelte dell’intera pubblica amministrazione. Ciò induce spesso a ricorrere a

commissionare ricerche esterne, facendo lievitare i costi di produzione informativa, per

colmare i deficit informativi, che si generano a causa di questo non intervento organizzativo

nella struttura archivistica degli uffici operativi.

Una ricerca condotta dal Sistema Statistico Regionale aveva evidenziato già all’inizio del 2001

che giacimenti informativi esistenti in soli quattro assessorati della Regione Lazio erano

risultati oltre 400. Questi sono mal organizzati e le informazioni da essi ricavabili sono

pressoché nulle, né queste possono essere confrontabili e/o integrabili con quelle esistenti in

campo nazionale individuate nel Piano Statistico Nazionale.

Preso atto che questa realtà produce di fatto la perdita assoluta delle informazioni necessarie,

per consentire un miglioramento operativo, già all’inizio del 2001 si è avviata una riflessione

approfondita al fine di realizzare un nuovo modello operativo nella organizzazione statistica

della Regione.

viii

A questo scopo con l’ausilio del dipartimento informatica e sistemistica e del dipartimento di

statistica, dell’università “la Sapienza” il SISTAR-Lazio ha avviato lo studio sperimentale per

organizzare le potenzialità informative esprimibili attraverso gli archivi interni e il loro

collegamento con le altre strutture informative giacenti nel più generale sistema statistico

nazionale.

Il risultato dello studio che offriamo alla conoscenza di quanti sono interessati alla nostra

produzione statistica costituisce un patrimonio scientifico di altissimo interesse poiché per la

prima volta si è posto in modo concreto l’avvio di un vero processo di costruzione di quelle

banche dati (data warehouse) che pur espresse come obiettivi operativi in numerose leggi di

produzione nazionale e regionale rimanevano solo desideri comportamentali senza alcun

contributo che consentisse di tradurre quelle normative in azioni concrete.

La presente pubblicazione ha il pregio di segnalare i criteri che si dovranno adottare per

gestire dati di”business”e dei relativi livelli architetturali di Datawarehouse (DW).

E’ questo lo stadio necessario per affrontare con minori spese possibili l’introduzione di un

moderno sistema operativo che correlato al programma di e-government potrà realizzare

quella “rivoluzione” copernicana tanto attesa da una società civile che vive una realtà

tecnologica in forte evoluzione innovativa.

Il progetto di DW applicato ad un solo settore operativo quello del settore sociale, che

realizzeremo nell’attuazione del piano statistico regionale sarà la sfida verso il completamento

del più generale disegno di una moderna amministrazione che vuole porsi alla guida dello

sviluppo e del benessere della popolazione amministrata.

Ing. Giulio Gargano

Assessore al Personale,

Informatica e Statistica.

Sommario

Introduzione dell’On.Francesco Storace

Prefazione dell’Assessore Ing.Giulio Gargano

1 Sintesi.....................................................................................................................................ix

1.1 Introduzione.....................................................................................................................x

1.2 Descrizione del progetto..................................................................................................xi

1.3 Il Data warehouse .........................................................................................................xiii

1.4 Metadati........................................................................................................................xiii

1.5 Il cruscotto informativo.................................................................................................xiv

1.6 Data mining ..................................................................................................................xiv

1.7 Il piano di lavoro............................................................................................................xv

1.8 La struttura organizzativa e di supporto decisionale........................................................xv

2 Introduzione ............................................................................................................................1

2.1 Motivazioni e finalità .......................................................................................................1

2.2 Organizzazione in fasi dello studio...................................................................................2

2.2.1 Lo studio di fattibilità ...............................................................................................2

2.2.2 La realizzazione pilota..............................................................................................2

2.2.3 Progetto e realizzazione del sistema..........................................................................3

2.3 Contenuti della relazione..................................................................................................3

3 Il Data Warehouse ...................................................................................................................5

3.1 Problematiche generali .....................................................................................................5

3.2 Dati gestiti da un data warehouse .....................................................................................5

3.2.1 Dati di Business .......................................................................................................6

3.2.2 Metadati ...................................................................................................................7

3.3 Livelli architetturali di un DW .........................................................................................8

3.3.1 Architettura ad un livello ..........................................................................................9

3.3.2 Architettura a due livelli. ..........................................................................................9

3.3.3 Architettura a tre livelli. .........................................................................................11

3.4 Accesso ai dati di un DW...............................................................................................12

3.4.1 Interfaccia utente....................................................................................................13

3.4.2 Funzionalità di navigazione e metadati ...................................................................14

ii

4 Il sistema informativo statistico della Regione Lazio .............................................................18

4.1 Architettura generale proposta per il sistema ..................................................................18

4.2 Utenti e livelli di accesso ...............................................................................................20

4.3 Dati e metadati ...............................................................................................................21

4.4 Gli studi pilota e la loro attuazione .................................................................................22

5 Lo studio pilota......................................................................................................................23

5.1 L'assessorato delle politiche sociali ................................................................................23

5.2 Tipologia delle fonti informative....................................................................................24

5.3 L'analisi delle fonti informative......................................................................................25

6 Classificazione delle fonti ......................................................................................................26

6.1 Organizzazione dello schema dei metadati .....................................................................26

6.2 Criteri di classificazione delle fonti ................................................................................31

6.3 Tabelle descrittive delle Entità e delle Relazioni ............................................................32

6.3.1 Descrizione delle Entità..........................................................................................32

6.3.2 Descrizione delle Relazioni ....................................................................................35

7 Il prototipo.............................................................................................................................37

7.1 Descrizione del prototipo ...............................................................................................37

7.1.1 Ristrutturazione dello schema E-R..........................................................................38

7.1.2 Schema relazionale.................................................................................................39

7.2 Manuale utente ..............................................................................................................40

7.2.1 Prerequisiti per l’utilizzo dell’applicazione.............................................................40

7.2.2 Avvio, navigazione, gestione dei dati e ricerche .....................................................41

7.2.3 Sezione “Catalogo Sorgenti”..................................................................................42

7.2.4 Sezione “Gestione del Thesaurus”..........................................................................64

7.2.5 Sezione “Ricerche” ................................................................................................65

8 Proposta operativa .................................................................................................................73

8.1 Fase 1: Realizzazione del data warehouse di primo livello .............................................73

8.1.1 Attività 1.1 - Analisi ...............................................................................................73

8.1.2 Attività 1.2 - Progettazione (dati e metadati)...........................................................73

8.1.3 Attività 1.3 Realizzazione (metadati)......................................................................74

8.1.4 Attività 1.4 Realizzazione (dati) .............................................................................74

8.1.5 Attività 1.5 Sperimentazione ..................................................................................74

8.2 Fase 2: Realizzazione del data warehouse di secondo livello ..........................................74

8.2.1 Attività 2.1 Estensione dei requisiti ........................................................................74

8.2.2 Attività 2.2 Individuazione delle nuove tematiche di interesse ................................74

iii

8.2.3 Attività 2.3 Progettazione .......................................................................................75

8.2.4 Attività 2.4 Realizzazione (dati, metadati e data mart) ............................................75

8.3 Fase 3: Estensione del data warehouse di secondo livello ...............................................75

8.4 Riepilogo delle attività ...................................................................................................75

8.5 Gantt..............................................................................................................................79

8.6 Elenco dei deliverable ....................................................................................................80

8.7 Gruppo di lavoro............................................................................................................81

9 Appendice A: Elenco delle fonti informative analizzate .........................................................82

10 Allegato A : Il prototipo "Catalogo Sorgenti"...................................................................117

2 Introduzione

Il presente documento costituisce la relazione finale dell'attività svolta dal Dipartimento di

Informatica e Sistemistica dell'Università di Roma "La Sapienza" (DIS nel seguito) nell'ambito

dello Studio di fattibilità commissionato dalla Regione Lazio.

2.1 Motivazioni e finalità

La L.R n.14/99 sul decentramento amministrativo nel Lazio all’art.32 promuove l’attivazione

del Sistema Informativo-Statistico sia regionale che delle Amministrazioni locali in essa

operanti (SIARL). In particolare la L.R. n.14/99 afferma che la Regione Lazio dovrà utilizzare

tale sistema al fine di verificare e misurare l’efficacia delle proprie attività. Tale sistema dovrà

da un lato essere integrato con sorgenti informative preesistenti, dall’altro servire da supporto

per l’attività di enti esterni autorizzati ad accedere alle informazioni raccolte.

Il Sistema Informativo-Statistico Regionale si profila, quindi, come un vero e proprio data

warehouse, in cui dovranno confluire informazioni che rappresentano le grandezze di interesse

per le attività dei vari uffici della regione Lazio legate al territorio amministrato. Si può

realisticamente assumere che una grossa quantità di informazioni utili al conseguimento degli

obbietivi imposti dalla L.R. 14/99 siano detenute, sotto varie forme, nei sistemi informativi di

numerosi soggetti, sia pubblici che privati, distribuiti sul territorio regionale.

Il progetto è molto ambizioso e di notevole complessità, e presenta caratteristiche fortemente

innovative a livello nazionale. In tal senso si osserva che non si hanno attualmente nella

Pubblica Amministrazione esempi significativi di integrazione di sorgenti di dati così numerose

ed eterogenee. Inoltre, si profilano una serie di problemi per quanto riguarda la proprietà dei

dati, essendo le singole amministrazioni tipicamente riluttanti a cederli e a condividerne l’uso.

Questo tipo di difficoltà potrebbe tuttavia essere risolto in un contesto di reciprocità, cioè

concedendo a tali amministrazioni la possibilità di accedere al Sistema Informativo-Statistico

Regionale, ed anche a prelevare da esso dati integrati.

Tutti questi motivi suggeriscono una strategia di realizzazione graduale nel tempo del progetto.

Ciò consentirà di valutare in modo appropriato le scelte tecniche e i vantaggi per

l’amministrazione e per ridurre i costi complessivi di realizzazione, e di raffinare le strategie e

le tecniche in sede di realizzazione definitiva. Più precisamente si propone un’articolazione in

tre fasi, descritte in dettaglio nella prossima sezione:

? ? studio di fattibilità,

? ? realizzazione pilota,

? ? progettazione e realizzazione del sistema.

2

2.2 Organizzazione in fasi dello studio

2.2.1 Lo studio di fattibilità

Questa fase ha come obbiettivi l’analisi del problema, l'analisi dello stato dell'arte, la

determinazione della strategia complessiva e la definizione dettagliata delle specifiche della

seconda fase. In particolare si intende individuare un settore delimitato su cui avviare, nella

seconda fase, una realizzazione pilota.

Gli ostacoli più rilevanti alla fruizione di informazioni distribuite in archivi di diversi enti

risiedono, oltre che nella semplice conoscenza dell’esistenza delle varie sorgenti informative,

nella accuratezza della descrizione del contenuto informativo delle sorgenti, sia dal punto di

vista semantico che dal punto di vista più strettamente tecnico.

Queste difficoltà possono essere superate solo attraverso la messa a punto di una metodologia

per la descrizione formale delle sorgenti informative, metodologia che, unitamente alla

individuazione di un' architettura di riferimento, costituisce l'obbiettivo principale dello studio

di fattibilità.

Per raggiungere tale risultato sarà necessario procedere ad un censimento delle sorgenti

informative, censimento che evidenzierà le inevitabili differenze nelle caratteristiche delle varie

fonti. Tali differenze riguardano sia le tipologie di sorgenti, sia le caratteristiche dei dati

contenuti.

La metodologia così individuata permetterà di raccogliere le caratteristiche delle sorgenti

informative necessarie per una loro classificazione. Tali caratteristiche saranno memorizzate in

una base di metadati, sulla quale verranno definite opportune interfacce di interrogazione e

navigazione.

I risultati di questa prima fase rappresentano il primo passo per la definizione dell’input da

fornire alle procedure automatiche di popolamento del data warehouse, da realizzare nella terza

fase del progetto.

Le metodologie descritte e le specifiche dell’interfaccia di navigazione verranno sperimentate

sul settore pilota durante la seconda fase.

2.2.2 La realizzazione pilota

Come specificato sopra, lo studio di fattibilità non prevede al suo interno un’attività di

prototipazione, ma piuttosto la sua specifica. Il prototipo sarà invece realizzato nella seconda

fase. La realizzazione pilota ha dunque come obbiettivo la convalida delle metodologie definite

nella prima fase e del corretto soddisfacimento dei requisiti utente. A tal fine, sarà necessario

individuare uno specifico settore di interesse. Tale settore deve godere di due caratteristiche:

3

significatività e rappresentatività. Con la prima intendiamo che in tale settore ricadano

meccanismi decisionali ed ambiti di azione politica che siano percepiti come significativi per

l’Amministrazione Regionale. La realizzazione pilota in tale settore deve pertanto poter

consentire una piena valutazione dell’efficacia, in termini di benefici pere l’Amministrazione,

dell’azione proposta. Con rappresentatività intendiamo invece la garanzia che nel processo di

realizzazione pilota siano effettivamente toccate tutte le problematiche che lo studio di

fattibilità ha individuato come centrali e critiche per la realizzazione definitiva del sistema,

quali ad esempio la varietà nella tipologia delle sorgenti informative e la ricchezza nella

struttura dei metadati.

2.2.3 Progetto e realizzazione del sistema

Questa terza ed ultima fase è ovviamente anche la più cospicua ed impegnativa, ed è articolata

su tre interventi:

? ? ingegnerizzazione del sistema pilota (interrogazione e navigazione nella base dei metadati);

? ? popolamento della base dei metadati su tutti i settori di interesse per la Regione Lazio;

? ? costruzione del data warehouse, con la realizzazione degli opportuni moduli di raccolta e

riconciliazione dei dati dalle sorgenti informative di interesse.

La realizzazione di questi tre interventi dovrà essere demandata a soggetti industriali, i quali

agiranno nell’ambito delle metodologie individuate e definite con dettaglio a livello di studio di

fattibilità.

Grazie ai risultati delle due fasi precedenti, ed all’esperienza in esse maturata, dovrebbero

esistere tutti i presupposti per una stima dei relativi costi e per una pianificazione e

programmazione di massima.

2.3 Contenuti della relazione

L'attività di ricerca condotta dal DIS ha portato al completamento delle due prime fasi, ovvero

lo studio di fattibilità e la implementazione del caso di studio pilota relativo alle politiche per il

Sociale. Inoltre, è stata effettuata una stima dei tempi e dei costi necessari alla realizzazione del

sistema informativo statistico relativo al settore Sociale.

La presente relazione descrive i risultati ottenuti, così esposti nel seguito:

? ? la sezione 2 contiene una introduzione alle problematiche relative ai Data Warehouse ed

alle relative possibili scelte architetturali;

4

? ? la sezione 3 descrive la proposta metologica per la realizzazione del Sistema

Informativo Statistico della regione Lazio, descrivendo l'architettura prescelta per la sua

attuazione, la pianificazione delle attività previste e le specifiche per lo studio pilota;

? ? la sezione 4 descrive lo studio pilota, mostrando le problematiche del settore Sociale e la

tipologia delle fonti informative coinvolte; l'elenco puntuale delle fonti

informativecensite è mostrato, invece, in appendice A;

? ? la sezione 5 mostra la struttura utilizzata per la classificazione delle fonti, descrivendo

nel dettaglio lo schema di una base di metadati, contenente tutte le informazioni

necessarie alla individuazione ed al reperimento dei dati di interesse;

? ? la sezione 6 descrive il prototipo realizzato per il caso pilota, fornendo un manuale di

utilizzo dello stesso;

? ? la sezione 7 mostra la stima dei tempi e dei costi previsti per la realizzazione del

Sistema Informativo Statistico relativo al settore Sociale.

5

3 Il Data Warehouse

3.1 Problematiche generali

Il data warehouse è la risposta più efficace all’esigenza di comprendere ed analizzare i fattori

chiave delle proprie attività produttive, siano esse di tipo imprenditoriale o di tipo

amministrativo. L’obbiettivo ultimo del data warehouse è, difatti, quello di ricavare un

vantaggio strategico dalle proprie informazioni, per poter valutare le scelte fatte in passato e

pianificare quelle future.

Il data warehouse è quindi orientato al supporto alle decisioni, ed è basato sul principio che i

dati presenti nei sistemi informativi di supporto alle attività di base della organizzazione

debbono essere profondamente trasformati per essere efficacemente utilizzati.

Come si vede, quindi l’idea di base di un data warehouse è molto semplice, e consiste

sostanzialmente nell’osservare come le esigenze dei processi decisionali siano profondamente

diverse dal semplice processo di gestione dei dati, e che sia quindi sbagliato tentare di

soddisfarle tutte con un unico ambiente.

I processi legati alla semplice gestione dei dati sono tipicamente transazionali e richiedono

lettura e/o modifica di pochi dati alla volta con tempi di risposta strettissimi. I processi

decisionali invece richiedono l’accesso a quantità di dati anche molto grandi per produrre

risultati sintetici e possono accettare tempi di risposta meno stretti (purchè ragionevoli). Inoltre,

mentre le attività legate alla gestione dei dati sono altamente ripetibili, le richieste dei processi

decisionali variano di volta in volta in funzione delle esigenze.

Una soluzione basata sul concetto di data warehouse affronta il problema in maniera radicale:

visto che i due tipi di processi hanno esigenze così diverse, conviene separare gli ambienti che

li supportano. Un data warehouse è, quindi, un ambiente separato in cui far convergere

(prelevandoli dagli ambienti di produzione) tutte le informazioni utili ai processi decisionali e

su cui costruire tutte le funzioni a supporto di tali processi.

3.2 Dati gestiti da un data warehouse

Per comprendere le possibili architetture concettuali utilizzate nella progettazione di un data

warehouse; risulta necessario premettere un'analisi delle tipologie di dati gestiti da un DW.

Ci sono molti tipi di dati memorizzati nei sistemi informatici. Alcuni sono particolarmente

appropriati per essere gestiti in un data warehouse, altri no. In questa sezione, dopo una

generale caratterizzazione dei dati, verrà identificato il tipico campo di azione di un DW.

6

Le coordinate utili per la classificazione dei dati sono tre:

1. Significato. I dati possono avere significato intrinseco o possono rappresentare qualche

altra cosa che, a sua volta, ha un suo proprio significato. Un esempio della prima

tipologia può essere un libro in formato elettronico, un esempio della seconda può

essere una tabella contenente, provincia per provincia, l'investimento complessivo

effettuato in un certo anno per il settore Sociale. I dati presenti nei sistemi informativi di

una impresa o di un ente amministrativo (business data) cadono quasi sempre nella

seconda categoria. Un caso particolare della prima categoria sono i metadati, che

rappresentano il significato dei dati stessi. Per la valenza particolare che quest'ultimo

tipo di dati riveste, tratteremo questo caso particolare come una terza tipologia di dati.

2. Struttura. I dati possono essere strutturati, essendo definiti in termini di campi collegati

o record e/o aggregati, oppure non strutturati, quando la struttura interna non è ben

definita.

3. Campo di Azione. I dati possono essere personali, o pubblici.

Un corretto campo di azione di un data warehouse dovrebbe comprendere allora dati di

business e metadati nella maggior parte pubblici, sia strutturati che non come mostrato in

Figura 1.

Figura 1 Dati gestiti da un data warehouse

3.2.1 Dati di Business

I dati di business sono necessari alla gestione dell'organizzazione stessa. Essi rappresentano sia

le attività che sono svolte dall’organizzazione sia gli oggetti del mondo reale con i quali

l’organizzazione è solita trattare. È possibile classificare i dati di business in tre distinte

categorie:

7

1. Real-Time Data. Rappresentano lo stato corrente delle attività svolte

dall'organizzazione, e ne consentono lo svolgimento. Sono i dati al più basso livello di

dettaglio nell’organizzazione e sono creati, manipolati e acceduti quasi esclusivamente

da sistemi operazionali o personali. Tali dati vengono gestiti tramite Data Base

Management System (DBMS), e sono oggetto delle usuali operazioni di inserimento,

ricerca, modifica e/o cancellazione.

2. Dati Derivati (Derived Data). Sono dati ottenuti dai dati real-time tramite un processo

di trasformazione. Possono esistere sia ad un elevato livello di dettaglio sia in forma

aggregata e, per la loro natura, rappresentano o informazioni puntuali raccolte in un

certo istante temporale o di tipo periodico, fornendo una visione storica dell' attività di

interesse. I dati derivati vengono acceduti esclusivamente in lettura da applicazioni di

supporto alle decisioni (DSS).

3. Dati Riconciliati (Reconcilied Data). Sono dati generati da un processo di

razionalizzazione ed integrazione dei dati real-time provenienti da molteplici sorgenti

dati. Sono, di fatto, un particolare caso di dati derivati, dove il processo di

manipolazione è più di tipo sintattico (risoluzione di omonimie, sinonimie, formato di

memorizzazione, ecc.) che di tipo semantico anche se la loro produzione, ha come

effetto collaterale la creazione ed il mantenimento di un insieme di dati storici. Nei

sistemi di supporto alle decisioni raramente i dati riconciliati sono esplicitamente

definiti, e dove esistono raramente sono fisicamente memorizzati. Il più delle volte,

infatti, sono soltanto il risultato logico di operazioni eseguite sui dati real-time. Come si

vedrà in seguito la costruzione di un livello di riconciliazione dei dati è il passo

fondamentale nella costruzione di un data warehouse proprio perchè l’importanza di tali

dati è stata per lungo tempo trascurata dalle imprese portando alla proliferazione di

inconsistenze tra dati operativi.

Relativamente alla struttura, appare evidente che la maggior parte dei dati di business è di tipo

strutturato; eventuali eccezioni, tipo diagrammi, documenti strategici, ecc., meritano di essere

considerati all'interno di un data warehose, ma solo a valle di una completa gestione dei dati

strutturati.

3.2.2 Metadati

Con l’aumentare della varietà dei dati usati e memorizzati in una impresa, e con l’aumentare dei

diversi usi che di tali dati è possibile fare, nasce la necessità di formalizzarne la descrizione e

l’uso, per assicurare che vengano utilizzati in maniera completa e consistente. I metadati ,

ovvero dati sui dati, soddisfano questa esigenza.

8

Come si può facilmente immaginare, i metadati giocano un ruolo fondamentale anche nel

campo del data warehousing. Infatti, affinchè un data warehouse sia acceduto e mantenuto in

maniera efficiente è necessario conoscere quali dati sono disponibili dove sono collocati, quali

procedure di trasformazione sono state effettuate, etc.

Una classificazione porta ad individuare tre tipologie di metadati:

1. Metadati di servizio, per la costruzione del sistema informativo, ovvero metadati

utilizzati per la creazione e gestione dei dati operazionali. L'origine di questi metadati è

antecedente alla creazione del data warehouse ma il loro ruolo in tale contesto è

essenziale in quanto contengono tutte le informazioni necessarie per l'integrazione e

riconciliazione dei dati;

2. Metadati di controllo, utilizzati dal DW per gestire il funzionamento del data

warehouse stesso. Questa tipologia di metadati realizza il collegamento tra i dati

operazionali e la struttura del DW;

3. Metadati per l'utente finale, pensati per aiutare l'utente del DW nella ricerca delle

informazioni di interesse attraverso l’enorme mole di dati disponibili. Alcuni di questi

metadati sono derivabili dai metadati di cui al punto 1 e 2, altri devono essere raccolti

ad-hoc. Da un punto di vista utente i metadati dovrebbero contenere:

a. l’origine dei dati (ricavabili dai metadati di servizio), in quanto l’utente del data

warehouse ha necessità di conoscere da quale sistema provengano i dati da lui

richiesti;

b. le sequenze di trasformazioni, poichè è fondamentale per un utente conoscere

quale trasformazione è stata applicata ai dati nel passaggio dall’ambiente

operativo al data warehouse;

c. i livelli di accesso, contenenti informazioni relative ai permessi di accesso

disponibili all’utente e a come sia possibile ottenere informazioni al momento

non disponibili;

d. informazioni temporali, che forniscono la data e l’ora dell’ultimo

aggiornamento effettuato e/o del periodo temporale coperto dai dati stessi;

Appare quindi evidente che i metadati rivestono un ruolo fondamentale nel successo di un

progetto di data warehouse.

3.3 Livelli architetturali di un DW

Le architetture concettuali di un DW si possono classificare in base al grado di

disaccoppiamento tra ambiente operazionale ed ambiente decisionale e, di conseguenza, in base

al livello di duplicazione dei dati.

9

3.3.1 Architettura ad un livello

In questo caso non è prevista alcuna ridondanza dei dati. I sistemi decisionali accedono

all’unica copia dei dati in concorrenza con i sistemi operazionali, con conseguente

degradazione delle prestazioni di entrambi (vedi Figura 2).

Il vantaggio è dato dalla minimizzazione del volume dei dati e dall’eliminazione dei problemi

di consistenza causati dalla duplicazione.

L’assenza di qualsiasi trasformazione dei dati operazionali ed in particolare l’assenza di

aggregazioni precalcolate contrasta in modo evidente con le esigenze dell’analisi decisionale.

Dati Operazionali

Operationalsystems Informational

systems

Figura 2 Architettura concettuale ad un livello

I DW con architettura ad un livello sono anche detti data warehouse virtuali, poichè il

disaccoppiamento dall’ambiente operazionale è gestito direttamente dalle applicazioni

decisionali senza il supporto di dati fisicamente organizzati secondo le esigenze dell’ambiente

informativo.

I DW virtuali hanno avuto un iniziale successo dovuto alla rapidità dei tempi di sviluppo. Allo

stato attuale vengono però privilegiate architetture più complesse che forniscono una risposta

più adeguata ai problemi dell’analisi decisionale. L'unico contesto in cui tale approccio ha

ancora una notevole validità è quello in cui la mole dei dati operazionali sia tale da scoraggiare

qualunque forma di duplicazione.

3.3.2 Architettura a due livelli.

In questo caso il disaccoppiamento del DW dai sistemi operazionali è realizzato tramite

l’aggiunta di un livello intermedio di dati replicati (vedi Figura 3).

L'architettura prevede quindi due livelli separati:

1. un livello di dati real-time, cui accedono i sistemi operazionali in lettura e scrittura;

10

2. un livello di dati derivati, cui accedono i sistemi decisionali tipicamente in lettura; in

tale livello sono presenti sia dati di dettaglio che dati aggregati, relativi a finestre

temporali di differenti dimensioni.

I dati derivati sono periodicamente arricchiti tramite processi di estrazione dai dati real-time.

L’integrazione di questi dati avviene contestualmente all’estrazione.

La replicazione dei dati elimina il problema della concorrenza tra sistemi decisionali e sistemi

operazionali; il prezzo pagato è il notevole aumento dello spazio di memorizzazione necessario.

Real-time data

Derived Data

Informational systems

Operationalsystems

Figura 3 Architettura concettuale a due livelli

Il buon grado di separazione tra ambiente decisionale e ambiente operazionale, uniti alla

semplicità architetturale, hanno determinato un’ampia diffusione di questa soluzione,

soprattutto nei casi in cui il processo di derivazione e di integrazione è meno complesso, cioè in

quelle organizzazioni caratterizzate dall’omogeneità dei sistemi operazionali e da un numero

limitato di piattaforme hardware e software.

Una grossa controindicazione a tale approccio è legata al fatto, non sempre compreso, che il

legame esistente tra dati real-time e dati derivati non è affatto lineare: ognuno dei due livelli è,

difatti, composto dall'unione di differenti insiemi di dati parzialmente sovrapposti e,

tipicamente, gli insiemi di dati presenti nei dati derivati provengono da più d'uno degli insiemi

presenti nei dati real-time (vedi Figura 4). Tutto questo produce una notevole complicazione nel

livello di gestione ed aggiornamento dei dati derivati, rendendone difficile la manutenzione.

11

Real-time data

Derived Data


Operationalsystems

Figura 4 Relazioni tra dati real-time e dati derivati È in tale contesto che nasce il concetto di data mart: un approccio in cui differenti dipartimenti

aziendali realizzano separatamente differenti sistemi per gestire le informazioni, realizzando, di

fatto, un'architettura a due livelli.

In sintesi, un'architettura a due livelli produce risultati utili per attività a breve termine ma non

affronta in modo rigoroso il problema della consistenza e dell'integrità dei dati ed è

strategicamente inefficiente per attività decisionali a medio e lungo termine.

3.3.3 Architettura a tre livelli.

L’architettura a tre livelli nasce dall’osservare che la trasformazione dei dati real-time in dati

derivati non richiede un solo passo come avviene nell’architettura a due livelli ma bensì due

passi che sono :

1. Riconciliazione dei dati provenienti dai diverse sorgenti dati

2. Derivazione dei dati richiesti dall’utente non dai dati real-time, ma dai dati riconciliati.

Questo porta all’architettura di Figura 5. Il livello di riconciliazione richiede la comprensione di

come le differenti sorgenti dati siano tra loro correlate e quale sia il loro ruolo

nell’organizzazione.

12

Reconcilied data

Derived Data


Operationalsystems

Real-time Data

Figura 5 Architettura a tre livelli

Lo scopo del livello di riconciliazione è dunque quello di creare un modello dati che sia

comune a tutta l’organizzazione e che contenga tutte le possibili informazioni di possibile

interesse per gli utenti finali, oggi come nel futuro. Il processo di caricamento dei dati

provenienti dal livello operativo (real-time data) permetterà di eliminare da essi inconsistenze e

irregolarità e di integrarli tra loro in maniera razionale. Nessun nuovo data sarà creato a questo

livello, il valore aggiunto di tale processo sta nella riconciliazione stessa.

Il passo successivo sarà il popolamento del livello dei dati derivati, attraverso un processo di

trasformazione, combinazione ed aggregazione applicato non più ai dati operativi come

avveniva nell’architettura a due livelli, ma direttamente ai dati riconciliati. Tale processo sarà

ovviamente basato sulle esigenze degli utenti finali.

3.4 Accesso ai dati di un DW

Il processo che permette ad un utente di visualizzare e comprendere i dati conservati nel data

warehouse deve:

? ? Avere una interfaccia utente intuitiva e facile da usare;

? ? Avere la capacità di associare ai dati (collegati ad una definita espressione in ingresso)

un insieme di regole formali da utilizzare per selezionarli, manipolarli e trasformarli;

? ? Avere la capacità di conservare tali regole per ogni riutilizzo nel futuro;

? ? Provvedere un accesso a tali regole per usarle o modificarle;

13

? ? Provvedere a identificare un collegamento alle locazioni dei dati per il loro recupero;

? ? Avere la capacità di collegare ai dati prodotti il loro significato, definizione e utilizzo

(metadati);

? ? Avere l’abilità di rappresentare le informazioni richieste in vari modi da quelli testuali a

quelli grafici;

? ? Avere la capacità di passare le informazioni ad altri processi come posta elettronica,

programmi di grafica, etc;

? ? Avere la capacità di costruire e conservare delle procedure che usano varie funzionalità

offerte dal processo.

3.4.1 Interfaccia utente

L’insieme delle applicazioni che realizzano le funzionalità descritte precedentemente sono

raccolte dal punto di vista logico nella business information interface (BII). Nella struttura

logica del BII si distingue l’interfaccia utente, grazie alla quale vengono manipolate le

funzionalità offerte dal BII:

? ? Funzioni di associazione e definizione. Una varietà di tecniche basate sulla grafica, sul

in linguaggio naturale che traducono gli input costituiti da termini orientati alle

funzionalità della organizzazione in termini orientati ai dati e permettono di costruire su

questi delle interrogazioni e trasformazioni con degli strumenti amichevoli. Lo scopo è

di isolare il più possibile l’utente “dal punto di vista informatico” e permettergli di usare

quanto più possibile la terminologia a lui nota. Queste funzioni permettono anche

l’associazione tra dati restituiti e il loro significato.

? ? Funzioni di selezione e manipolazione. Generano comandi SQL o in altri linguaggi di

manipolazione sui dati che utilizzano condizioni di tipo WHERE e di ordinamento sui

dati. Vengono usate dalle funzioni di definizione e associazione.

? ? Funzioni di data management. Sono responsabili degli accessi ai dati che possono

risiedere nel data warehouse ma anche in data store personali. Per gestire tale

responsabilità il data management fornisce informazioni sulle versioni e le validità

correnti dei dati. Inoltre i dati vengono “preparati” per essere esportati verso altri

strumenti esterni. Il data management si basa sulle componenti dell’accesso ai dati per

cui i dati possono essere recuperati da ogni locazione fisica sotto ogni formato.

? ? Funzioni di struttura e presentazione. Trasformano i dati estratti in un formato

richiesto per l’uso. Tale formato varia da un semplice report testuale da stampare a

complessi grafici da vedere e manipolare direttamente.

14

? ? Funzioni di procedure management. Sono procedure che utilizzano le funzionalità

precedenti e che, una volta create, risiedono in una libreria per essere eventualmente

riutilizzate. Il contenuto di una procedura può essere una interrogazione su di una

singola base di dati o una complessa interrogazione distribuita, con relative analisi dei

dati di output e complesse formattazioni dei risultati. Certe procedure possono essere dei

trigger che scattano in determinate circostanze di natura eccezionale o periodicamente

ricorrenti. Ad esempio queste procedure-trigger possono distribuire dei report agli utenti

per avvisarli di situazioni anomale riscontrate nei dati oppure possono invocare

l’aggiornamento periodico dei dati di un utente. Ovviamente, l’uso di tali procedure

viene documentato nei metadati.

3.4.2 Funzionalità di navigazione e metadati

Abbiamo visto che il processo di trasformare i dati contenuti nel data warehouse in

informazione da visualizzare è compito del BII; per far ciò, ha bisogno di un secondo

componente, il business information guide (BIG), per accedere ed usare i metadati che

descrivono i dati nel contesto delle attività svolte dalla organizzazione.

Il BIG permette agli utenti di esplorare il significato dei dati, comprendere come sono usati o

come potrebbero essere usati ed, eventualmente, rilevare errori e discordanze da sottoporre

all’attenzione di coloro che li amministrano.

Vale la pena ricordare che molti degli insuccessi legati all’utilizzazione del data warehouse

sono dovuti alla mancanza di comprensione dei dati in esso contenuti.

I problemi fondamentali per comprendere l’importanza del BIG sono:

? ? più dati sono disponibili, più occorre tempo per trovare qualcosa di utile;

? ? più dati sono disponibili, meno, in percentuale, sono quelli che un qualsiasi utente può

comprendere.

Il BIG dovrebbe essere in grado di risolvere i seguenti quattro punti chiave per l’utilizzo di un

data warehouse:

1) cosa c’è nel data warehouse

2) come si usa quel che c’è

3) dov’è quel che c’è

4) come ottenere quello che c’è.

Possiamo suddividere l’uso del BIG in quattro aree:

Attività di business

Metadati richiesti:

15

1) Definizioni dei termini delle attività svolte dalla organizzazione e dei dati e funzioni

coinvolte. La terminologia, a volte, è composta da un gran numero di sinonimi e

omonimi. Questi metadati aiutano a chiarire come un termine può assumere diversi

significati nelle varie parti di una organizzazione oppure come diversi termini attraverso

la compagnia vogliano esprimere lo stesso concetto.

2) Definizioni dei processi, sotto-processi e loro relazioni.

3) Relazioni tra processi, termini delle attività svolte dalla organizzazione e termini

appartenenti ad altre aree. È ovvio che le aree principali di interrogazione del BIG

non sono nettamente separate, ad esempio una attività può essere capita non solo

attraverso i processi svolti ma anche con la comprensione dei dati prodotti per la quale

può essere necessario sapere a quale parte dell’organizzazione sono destinati quei dati

prodotti, ecc. I “cammini” tra due aree generalmente sono “percorribili” in entrambi i

versi.

Uso:

1) Indagare sul significato dei termini delle attività svolte dalla organizzazione, task e

processi;

2) Indagare su applicazioni e dati usati;

3) Indagare sul contesto in cui agiscono applicazioni o dati;

4) Aggiornare la terminologia.

Organizzazione

Descrive la struttura dell’organizzazione.

Metadati richiesti:

1) Definizioni sulle strutture dell’organizzazione e ruoli individuali.

2) Responsabilità all’interno dell’organizzazione per applicazioni e dati. Ad esempio

responsabilità per la distribuzione, la qualità e accesso ai dati.

Uso:

1) Inviare richieste a un responsabile. Ad esempio per richiedere il permesso di accesso a

dei dati o per avvisare di aver riscontrato incongruenze nei dati;

2) Indagare sulle responsabilità di applicazioni o qualità dei dati;

3) Aggiornare le responsabilità individuali.

Applicazioni

Documenta come il sistema informativo ha implementato nel corso degli anni le procedure

usate dalla organizzazione.

Metadati richiesti:

1) Definizioni delle applicazioni e procedure;

16

2) Definizioni di interrogazioni e report, e loro relazioni con applicazioni e processi;

3) Descrizioni del codice di interrogazioni e report. Per utenti più abili che vogliono

modificare o sfruttare queries o reports già esistenti;

4) Definizioni di interrogazioni, parametri e valori permessi. Descrive una specifica area di

funzioni che modificano interrogazioni parametriche. Il BIG dà la lista dei parametri e

valori permessi per la personalizzazione delle interrogazioni e dei report;

5) Descrizione dei dati prodotti o usati in interrogazioni e report.

Uso:

1) Ricerca di applicazioni esistenti. Per evitare di riscrivere applicazioni, o procedure già

esistenti. L’approccio a tali metadati è analogo a quello ai metadati dei termini ed

attività tipiche dalla organizzazione;

2) Scoprire che dati ed applicazioni sono collegati. Una completa comprensione delle

applicazioni è favorita dalla conoscenza dei dati che esse usano;

3) Usare le interrogazioni ed i report disponibili;

4) Supportare la personalizzazione di interrogazioni e report.

Dati

La parte dati include sia la descrizione ed il significato dei dati dal punto di vista del loro

significato all'interno della organizzazione sia dal punto di vista della loro struttura, ovvero il

tipo, il livello di aggregazione,ecc.

Metadati richiesti:

1) Descrizione delle entità principali, classificazione dei dati entro le aree delle attività

svolte dalla organizzazione;

2) Descrizione tecnica dei dati. Le entità astratte individuate nella fase precedente si

traducono in file, tabelle, viste ed altre strutture fisiche. Le informazioni reperibili

includono nomi e sinonimi, locazioni, modalità di accesso e dimensioni. Gli attributi

trovano la loro corrispondenza fisica in colonne di tabelle o campi di record con relative

tipologie, lunghezze dei campi e valori permessi;

3) Traduzioni di campi codificati. Sono le classiche tabelle di conversione o che

contengono la descrizione estesa corrispondente a codici e acronimi. Possono essere

considerati anche dei veri e propri dati del business in quanto possono essere

implementati fisicamente nei database e possono cambiare;

4) Regole di derivazione. Durante il popolamento del data warehouse subiscono una serie

di trasformazioni di cui si deve essere a conoscenza se si vogliono interpretare

correttamente i dati: ad esempio bisogna conoscere qual è il livello di aggregazione a

cui si riferiscono i dati, cioè se una vendita si riferisce alla somma delle vendite

17

giornaliere o settimanali o mensili ecc. Le regole di trasformazione possono essere

descritte testualmente o con l’esposizione più dettagliata di algoritmi e codici;

5) Stato di aggiornamento dei dati e scheduling. Le informazioni di scheduling descrivono

quanto spesso o quando vengono aggiornati i dati. Lo stato di aggiornamento dei dati

viene qui spesso rappresentato al livello di gruppi di dati, mentre per una informazione

più dettagliata a livello di record e campi bisogna far uso dei timestamp presenti nel data

warehouse;

6) Statistiche sulla utilizzazione dei dati. Utili soprattutto per l’amministratore che vede

come e quando sono usate le informazioni, può essere utile anche all’utente finale

occasionalmente quando definisce la scelta dei dati da visualizzare con nuove

interrogazioni .

7) Informazioni sulla attendibilità e/o qualità dei dati.

Uso:

1) Conoscere il significato dei dati. Si permette anche alle persone appartenenti ad diverse

aree di una organizzazione di attribuire un significato unico ai dati e usarli in maniera

non conflittuale, il che permette una migliore comunicazione fra diverse parti della

organizzazione;

2) Localizzazione dei dati. Si permette di rintracciare con facilità i dati ricercati e di ridurre

i costi associati alla generazione di dati cercando di vedere se questi sono già stati

estratti;

3) Decidere un appropriato uso dei dati;

4) Supportare lo sviluppo di nuove interrogazioni;

5) Dare un significato a campi codificati;

6) Supportare l’amministrazione del data warehouse. L’amministrazione potrebbe rendersi

conto che è inutile mantenere dati che non vengono più utilizzati;

7) Ottenere informazioni sulla qualità dei dati.

18

4 Il sistema informativo statistico della Regione Lazio

Come detto precedentemente, si prevede di utilizzare un approccio di tipo data warehouse, cioè

basato sulla acquisizione dei dati dalle diverse sorgenti informative, e sulla loro importazione

ed integrazione in un’unica base di dati. Questa via risulta più praticabile rispetto ad una

federazione di basi di dati eterogenee, di fatto preclusa dalle problematiche di accesso in tempo

reale a dati detenuti e gestiti da molteplici amministrazioni, che potrebbero essere riluttanti a

concedere l’accesso diretto ai proprio archivi.

Tuttavia, rispetto all’approccio tradizionale di data warehousing, ipotizzando che i dati

disponibili possano essere già aggregati a diversi livelli, si introducono nel processo di

integrazione e riconciliazione anche aspetti relativi alla omogeneizzazione dei differenti livelli

di aggregazione rispetto ad attributi temporali e/o spaziali, nonché un'analisi della loro

qualità.

L’architettura data warehouse, rispetto ad una federazione di basi di dati, consente di ottenere

una elevata affidabilità del sistema, ed una maggiore efficienza nella risposta ad interrogazioni.

Inoltre, a partire da un data warehouse, risultano semplificate le procedure necessarie ad

estrarre data mart, ad esempio sotto forma di viste materializzate, per particolari tipologie di

utenza. Naturalmente, dovendo gestire informazioni storicizzate e soggette ad evoluzione

temporale, sarà necessario predisporre opportuni moduli di importazione di dati che permettano

in maniera semi-automatica l’aggiornamento periodico del data warehouse e la sua

“storicizzazione”, arrivando a quella che viene tecnicamente definita una “base di dati

persistente”, in cui cioè è possibile risalire sia alle informazioni correnti, sia ai valori relativi ad

istanti precedenti.

4.1 Architettura generale proposta per il sistema

In figura 1 possiamo vedere una rappresentazione schematica dell’intero sistema con le

sottoparti che lo compongono. Le sorgenti dati possono essere sia esterne che interne,

provenienti da attori diversi e caratterizzate da diversa natura. L'architettura prevista

corrisponde a quella di una data warehouse a tre livelli e permette di distinguere quattro

componenti essenziali:

1. Acquisizione dati: raggruppa tutte le funzioni di acquisizione delle informazioni, in cui

eventuali discrepanze tra le varie sorgenti informative (dati operazionali) vengono

risolte con il fine ultimo di alimentare la base di dati principale con dati omogeneizzati,

sia rispetto al tipo che al livello di aggregazione;

19

2. Gestione dei dati: nel data warehouse vengono gestiti sia i dati (dati riconciliati) veri e

propri che la loro descrizione (metadati). I dati sono proprio le informazioni sul sociale

di cui .la regione ha bisogno: il numero di anziani per singola provincia o il reddito

medio dei pensionati, ecc. I metadati sono informazioni relative alla struttura dei dati

stessi, al sito di provenienza, alla loro organizzazione originaria, alla data dell' ultimo

aggiornamento, ecc.

3. Interrogazione da parte degli utenti: questo livello prevede una molteplicità di

meccanismi di interrogazione, meccanismi che tengono conto delle differenti necessità e

conoscenze degli utenti. In particolare si prevede la possibilità di:

a. effettuare interrogazioni dirette sui dati riconciliati (analisti del sistema

statistico);

b. interrogazioni su viste (utenti esterni);

c. creazione di dati derivati, a partire dai dati riconciliati (data mart) utilizzabili da

strumenti evoluti per effettuare l'analisi dei dati (utenti esperti).

MODULO DI ESTRAZIONE E

AGGREGAZIONE


AGGREGAZIONE

SORGENTE INFORMATIVA


AGGREGAZIONE

METADATI METADATI DI SERVIZIO

SCHEMA DATI C ONTROLLO ACCESSI E RISERVATEZZA

ACQUISIZIONE

GESTIONE DATI

VISTA UTENTE DATA MART TEMATICO

MODULO DI INTERROGAZIONE

MODULO DI

INTERROGAZIONE


DATA MART TEMATICO

MODULO DI INTERROGAZIO NE

MODULO DI

INTERROGAZIONE


INTERROGAZIONE

INTERNET / INTRANET

ACCESSO


AGGREGAZIONE


AGGREGAZIONE

MOD ULO DI ESTRAZIONE E

AGGREGAZIONE

INTERROGAZIONE

INTERNET / INTRANET

ACCESSO



Figura 1 - Architettura di riferimento

20

4. Accesso al sistema: l'accesso al sistema avviene tramite rete, basata su una connessione

di tipo Internet/Intranet. L'accesso può essere quindi garantito tramite un semplice

browser web (e.g., Internet Explorer o Netscape), evitando così tutte le problematiche di

distribuzione del software di accesso, ed ampliando così il potenziale bacino di utenza

del servizio

Integrati a vari livelli nell'architettura sono gli aspetti riguardanti il controllo degli accessi e le

garanzie di riservatezza dei dati, che rivestono un'importanza cruciale data la natura particolare

dell'applicazione, la molteplicità dei dati coinvolti, e l'accessibilità tramite rete da parte di

un'utenza eterogenea.

4.2 Utenti e livelli di accesso

Un'analisi dell'utenza porta alla individuazione di tre figure distinte:

1. Utenti esterni: utenti del territorio (in particolare gli enti locali, le società e le

associazioni operanti nel campo) possono essere particolarmente interessati ad una

efficace e tempestiva informazione sull’andamento dei bisogni di assistenza sociale, sia

per programmare interventi specifici sia per partecipare alla fornitura di servizi. Per la

stessa natura distribuita degli utenti la soluzione obbligata è quella di analisi pubblicate

su Internet o di semplici applicativi web che consentano analisi più mirate.

2. Decisori interni: coloro che all’interno della Regione devono prendere decisioni che

coinvolgono il fenomeno dell’assistenza sociale hanno necessità di ottenere rapidamente

informazioni sul fenomeno stesso e quindi richiedono dati aggiornati e strumenti

semplici che diano in modo chiaro e sintetico l’andamento del fenomeno negli specifici

settori di competenza. Essi hanno quindi bisogno di uno strumento che con semplicità

consenta la navigazione dei dati o la visualizzazione di indicatori significativi. Anche

tale dispositivo può essere basato su applicativi internet.

3. Analisti del Settore Statistico: i semplici strumenti di analisi e navigazione affidati ai

decisori interni rispondono a molte ma non a tutte le necessità informative. Risultano

quindi necessarie analisi più sofisticate, basate su modelli statistici complessi e che

coinvolgono in maniera non elementare molte variabili. Tali utenti devono quindi

disporre di applicativi statistici di elevata potenza che permettano le analisi necessarie.

Coerentemente, gli strumenti di distribuzione dei dati e delle informazioni saranno almeno tre:

uno per gli utenti esterni, di tipo molto semplice ed immediato, basato sul web, uno per la

consultazione e l’analisi dei dati da parte dei decisori interni, in grado di permettere semplici

21

analisi e navigazioni dei dati, anch’esso basato su servizi web, ed infine uno strumento di

analisi statistica avanzato a disposizione degli analisi del Sistema Statistico.

4.3 Dati e metadati

Come esposto precedentemente, per realizzare un data warehouse, in particolare se vogliamo

che esso possa essere arricchito da nuove sorgenti informative e ripopolato periodicamente, è

necessario produrre una descrizione formale della struttura e della semantica degli archivi di

riferimento. Queste informazioni prendono il nome di metadati.

I metadati descrivono, quindi, sia lo schema dei dati (metadati propriamente detti), sia altre

informazioni necessarie per realizzare le procedure d’integrazione e riconciliazione (metadati di

servizio).

È opportuno notare che già la sola raccolta e organizzazione dei metadati renderebbe agevoli

attività che attualmente vengono condotte con grande difficoltà. Infatti, osservando i metadati,

sarebbe possibile per un utente conoscere quali sono le sorgenti che contengono informazioni

attinenti l’argomento di studio, e, osservando i metadati ausiliari, valutare la potenziale utilità di

tali sorgenti.

La natura dei metadati è in parte dipendente dalla specifica sorgente informativa, in parte

dipende, invece, da quali sono le caratteristiche rilevanti per determinare l’utilità di una

sorgente. La struttura stessa dei metadati non è quindi determinabile a priori, ma solo dopo

un’attenta analisi delle tipologie di sorgenti informative da integrare.

In sintesi possiamo distinguere le seguenti tipologie di metadati:

? ? metadati statistici: l’insieme di regole e definizioni che descrivono il processo di

acquisizione e convalida al fine di rendere statisticamente significativi i dati, nonché le

informazioni che descrivono le caratteristiche organizzative della sorgente informativa;

? ? metadati semantici: l’insieme di informazioni atte a descrivere il significato delle

variabili statistiche anche a chi non ha conoscenze specifiche del fenomeno di interesse;

? ? metadati tecnici: le informazioni tecniche relative alla organizzazione e memorizzazione

fisica delle variabili e dei processi elaborativi associati.

Tali metadati saranno opportunamente organizzati e memorizzati nella base di dati e agli utenti

autorizzati ne sarà consentita l’interrogazione e la navigazione, al fine di acquisire conoscenza

diretta non solo sul contenuto del data warehouse, ma sulla struttura stessa delle sorgenti

informative. La navigazione avverrà attraverso un opportuno strumento di interfaccia, basato

sui protocolli web, che permetterà di interrogare la base dei metadati.

Oltre alla ricerca diretta tramite la combinazione di parole chiave e, ad esempio, alla

definizione di periodi temporali di interesse o di specifiche aggregazioni geografiche il sistema

22

dovrà prevedere un semplice thesaurus, utile per ricercare argomenti collegati (e.g., sinonimi).

Una proposta pratica per arricchire i metadati con questa struttura aggiuntiva è mostrata in

sezione 5.

Da notare che la realizzazione di questo strumento di ricerca basato sui metadati potrà avvenire

semplicemente a valle dell’attività di censimento delle sorgenti informative, ancor prima della

definizione dello schema del data warehouse e dell’inizio del suo popolamento, che si presume

sensibilmente più impegnativo e costoso.

4.4 Gli studi pilota e la loro attuazione

Una volta individuata un'architettura di riferimento, l'attività è proseguita individuando un

settore di interesse che potesse servire come studio pilota per le successive attività. Il settore

prescelto doveva essere, da un lato, sufficientemente articolato (i.e., ricchezza di tipologie di

fonti informative, di utenti, di meccanismi di accesso, ecc.) da portare alla corretta

individuazione delle problematiche generali da affrontare e, dall'altro, sufficientemente

circoscritto da essere dominabile nel contesto di uno studio di fattibilità. Un'analisi preliminare

ha portato alla individuazione di un insieme di possibili settori:

1) Turismo (Cultura/Sport/Spettacolo)

2) Agricoltura

3) Formazione professionale e scuola

4) Servizi sociali

Tra di essi, sulla base delle indicazioni fornite dalla Regione Lazio, è stato scelto il settore dei

servizi sociali.

Una ricognizione, non esaustiva, delle sorgenti informative afferenti a tale settore, ha permesso

di individuare una classificazione delle tipologie di fonti disponibili, delle problematiche

connesse alla estrazione e riconciliazione dei dati e delle metodologie da utilizzare.

Sulla base dei risultati ottenuti, è stata dettagliata e modificata l''ipotesi architetturale discussa

nella sezione 3.1, arricchendo in particolare la parte relativa ai metadati (vedi sezione 5).

Si è proceduto, poi, alla realizzazione di una base di dati dimostrativa, popolandola con i dati

estratti dal settore pilota (sezione 6).

23

5 Lo studio pilota

5.1 L'assessorato delle politiche sociali

La programmazione e gestione del sistema sociale è un’attività impegnativa e costosa, di

grande rilevanza e che richiede scelte coordinate fra i diversi livelli di intervento.

Una quantità ingente di risorse nazionali e locali viene destinata al supporto diretto e indiretto

delle fasce della popolazione più deboli dal punto di vista economico e sociale. Alla base

dell’elaborazione di tali politiche deve essere posto un sistema di conoscenze del settore che

abbia le caratteristiche della completezza, dell’attualità, della flessibilità e della coerenza con

gli obiettivi fissati.

Dal punto di vista del fabbisogno informativo, la programmazione delle politiche di intervento

sociale è, innanzitutto, conoscenza dei problemi: conoscenza che deve essere sia di tipo

quantitativo che qualitativo dei singoli fenomeni che delle correlazioni fra loro esistenti. Il

fenomeno sociale, per quanto “visibile” e discusso nelle sedi più disparate, si caratterizza per la

perdurante carenza di sistematiche informazioni qualitative/quantitative. Le statistiche

disponibili si riferiscono quasi esclusivamente a poche variabili legate a singoli aspetti

dell’assistenza sociale che, spesso, riescono a descrivere solo una parte del fenomeno

complessivo. Inoltre, la programmazione degli interventi nel territorio effettuata dalla regione e

dagli enti locali non risulta sempre coordinata e questo penalizza l'efficacia delle politiche di

intervento stesse. Infine, gli interventi programmati all’interno della regione devono tenere

conto della variabilità, all’interno del territorio regionale, della percentuale di incidenza di

specifiche categorie di popolazione e dei bisogni sociali connessi.

L’importanza di un sistema informativo sui bisogni sociali è quindi legato alla

razionalizzazione e all’ottimizzazione delle forme di intervento: l’ampliamento del campo di

osservazione del fenomeno a una molteplicità di forme di assistenza sociale (assistenza agli

anziani, alle famiglie, alle persone malate bisognose di assistenza domiciliare, ecc.) pone

problemi di coordinamento fra le diverse politiche di intervento per evitare il rischio di non

considerare o sottovalutare interventi a favore di specifiche problematiche di intervento.

Di non minore importanza è l’aspetto relativo alla progettazione di nuovi strumenti di

assistenza: la conoscenza quantitativa e qualitativa della realtà sociale permette di meglio

realizzare nuovi progetti di intervento sociale, indirizzati verso categorie della popolazione che

siano bisognose ma non beneficiarie degli attuali interventi. Il problema di un’approfondita

conoscenza del fenomeno sociale è inoltre importante nella programmazione di interventi di

tipo nuovo che non si limitano all’assistenza sociosanitaria e/o all’erogazione di contributi

24

economici diretti o indiretti. Infatti, esperienze significative ma ancora poco diffuse mostrano

che forme nuove di intervento possono avere notevoli benefici sia dal punto di vista sociale che

da quello sanitario con un costo economico ridotto; si fa riferimento, ad esempio, a forme di

assistenza domiciliare per persone anziane che vivono sole basata sull’utilizzo di comunicazioni

telefoniche e strumenti per il monitoraggio a distanza.

In conclusione l’approfondita conoscenza “qualitativa” e “quantitativa” del fenomeno sociale è

essenziale per orientare lo sviluppo in direzioni “sostenibili” in cui sia massimo il beneficio

ottenuto senza ulteriori discriminazioni dovute agli aspetti legati al territorio o ai diversi

bisogni. Infatti, conoscere il fenomeno dell’assistenza e misurare gli effetti delle azioni di

intervento, significa “avere in mente” il complesso schema di interazioni esistenti tra chi ha

bisogno e chi si attiva per offrire i beni e servizi necessari a soddisfare tale domanda.

5.2 Tipologia delle fonti informative

Dati utili alla analisi ed al supporto alle decisioni sono presenti, anche se non sempre

immediatamente fruibili, presso molti enti, fra cui la stessa Regione Lazio. Un elenco non

esaustivo delle possibili fonti comprende dati provenienti da:

? ? indagini sui bisogni sociali e sanitari che determinano le categorie della popolazione

bisognosa di aiuto condotte da enti e ministeri (Istat, Ministeri della Sanità , del Lavoro,

della Pubblica Istruzione, Inail, ecc.);

? ? elaborazioni sui bisogni finalizzate alla produzione di statistiche ufficiali, tipicamente

dell’Istat;

? ? monitoraggio degli interventi operati dai comuni e dalle province;

? ? monitoraggio di alcuni indicatori connessi alle problematiche del sociale: livello medio del

reddito, dell’età, ecc..

Alcune di questi flussi di dati nascono già come flussi statistici e sono di norma già aggregati su

periodi temporali più o meno lunghi, altri sono invece nati per altri scopi, e sono quindi dati di

dettaglio da cui bisogna estrarre mediante apposite procedure dati utilizzabili a fini statistici.

Rientrano in questo caso, per esempio, i dati prodotti dall’Amministrazione Regionale che

detiene informazioni sugli interventi finanziati, dati presenti in formato cartaceo perché

provenienti dal processo di autorizzazione e classificazione che la Regione deve svolgere.

Il processo di acquisizione ed integrazione di questi dati può risultare anche notevolmente

complesso, in particolare per i flussi di informazioni che non risiedono (in tutto o in parte) su

supporti elettronici. Pertanto, ogni flusso dati deve essere analizzato separatamente e generare

una specifica applicazione per il suo trattamento. Per maggiore complicazione bisogna dire che

alcuni flussi dati, proprio perché non direttamente prodotti dall’Ente, possono risulatare

25

estremamente volatili, potendo modificarsi senza preavviso in maniera anche sostanziale

oppure interrompendosi del tutto. Questo significa che la base dati atta ad accogliere questi dati

deve essere progettata con estrema attenzione e comunque sarà soggetta a frequenti progetti di

adeguamento.

5.3 L'analisi delle fonti informative

Sulla base di indicazioni fornite da dipendenti della Regione Lazio operanti nel settore Sociale

sono state analizzate e classificate le fonti informative più significative, privilegiando sia

l'interesse che tali fonti rivestivano per il settore in questione sia le caratteristiche di generalità

che tali fonti possedevano, al fine di rendere i risultati ottenuti fruibili in altri contesti. A tal

scopo, sono state incluse nell'analisi sorgenti informative appartenenti ad altri settori (e.g.,

Cultura); si è potuto così validare la correttezza dell'approccio seguito.

In particolare, sono state considerate le “Sorgenti SISTAN” e le “Sorgenti Amministrative”1.

Per quel che riguarda il primo tipo i metadati sono stati presi dal “Piano Statistico Nazionale

1998-2000”, dal “Piano Statistico Nazionale 2001-2003” e dai Cataloghi del SISTAN dell’anno

2000 e precedenti. Per quel che riguarda il secondo tipo, i metadati sono stati prelevati dal

censimento delle sorgenti informative della Regione Lazio (IRELA).

L'analisi delle fonti in questione ha portato alla definizione di uno schema per la gestione dei

metadati, descritto in sezione 5. In appendice A si riporta l'elenco, corredato dalle

caratteristiche essenziali (dati e metadati) di tutte le fonti analizzate.

1 Per “Sorgente Amministrativa” si intende una sorgente di informazione appartenente alla pubblica amministrazione della Regione Lazio che può essere disponibile in formato cartaceo o digitale all’interno di un determinato Ufficio.

26

6 Classificazione delle fonti

Come già detto, le sorgenti informative presentano delle inevitabili differenze, differenze che

riguardano sia le tipologie di sorgenti, sia le caratteristiche dei dati in esse contenuti.

Gli aspetti rispetto ai quali le sorgenti possono mostrare caratteristiche differenti riguardano,

non esaustivamente, i seguenti aspetti:

? ? tecnologie utilizzate nella realizzazione del sistema informativo,

? ? sicurezza/robustezza dei sistemi di archiviazione,

? ? modalità di reperimento dei dati durante il popolamento della sorgente,

? ? periodicità di aggiornamento dei dati,

? ? qualità/attendibilità dei dati,

? ? disponibilità alla diffusione dei dati,

? ? modalità di diffusione dei dati.

Dal punto di vista dei dati contenuti, potrebbero invece essere rilevate differenze rispetto a:

? ? unità di misura,

? ? livello di aggregazione temporale,

? ? livello di aggregazione spaziale,

? ? numerosità degli archivi, percentuale di valori non specificati o inattendibili, relazione

tra denominazione e semantica dei dati.

Le problematiche da affrontare e risolvere sono quelle enunciate in sezione 2, quando si è

evidenziato il ruolo cruciale che i metadati hanno nella struttura di un Data Warehouse.

La soluzione proposta, coerente con l'attuale stato dell'arte e con l'architettura mostrata in

sezione 3.1, si basa sull'idea di una gestione del sistema incentrata sui metadati. La struttura i

tali metadati è descritta nella sezione seguente, tramite uno schema Entità Relazione (ER nel

seguito).

6.1 Organizzazione dello schema dei metadati

La sintesi dello schema ER parte dalla considerazione che per un utente finale una sorgente

informativa:

? ? appartiene ad una certa tipologia (Sorgenti SISTAN, Sorgenti Amministrative)

? ? è corredata di una serie di informazioni che aiutano a capire gli argomenti trattati, il

periodo di riferimento, gli eventuali vincoli sull’accesso, etc.

27

? ? contiene informazioni attinte da una serie di entità che nel seguito saranno chiamate

“Unità di rilevazione”

? ? è disponibile su uno o più tipi di supporto (es.: cartaceo, digitale, etc.)

? ? contiene una serie di “Rappresentazioni” (ovvero di tavole, grafici etc.) che sintetizzano

le informazioni in essa contenute.

Per quello che riguarda le “Rappresentazioni” si può dire che:

? ? possono essere disponibili su file

? ? possono riportare “Attributi” (ovvero caratteristiche) riferiti ad entità che nel seguito

chiameremo “Unità di Analisi”

? ? le informazioni possono essere riportate in forma di “statistiche” (tassi, percentuali,

etc.)

Per facilitare le ricerche per chiave risulta utile definire un elenco di argomenti (thesaurus) che

possono essere associati alle rappresentazioni.

Si può inoltre aggiungere che:

? ? una sorgente può attingere informazioni da zero o più “Unità di rilevazione” mentre una

“Unità di rilevazione” può fornire informazioni per zero o più sorgenti;

? ? una sorgente può essere disponibile su uno o più supporti mentre un supporto può essere

associato a zero o più sorgenti;

? ? una sorgente può contenere zero o più rappresentazioni mentre una rappresentazione è

contenuta in una ed una sola sorgente;

? ? una rappresentazione può riportare zero o più statistiche mentre una statistica può essere

riportata in zero o più rappresentazioni;

? ? ad una rappresentazione possono essere associati zero o più attributi mentre un attributo

è associato ad una ed una sola rappresentazione

? ? una rappresentazione può essere associata ad una o più “Unità di analisi” mentre una

“Unità di analisi” può essere contemplata in zero o più rappresentazioni.

? ? Una rappresentazione può avere attinenza con zero o più voci del thesaurus mentre una

voce del thesaurus può essere associata a zero o più rappresentazioni

? ? Una rappresentazione può essere memorizzata in zero o più file mentre in un file sono

memorizzate una o più rappresentazioni.

Nella pagina successiva è riportato lo schema ER che descrive questa realtà. Per renderlo più

leggibile sono stati riportati solo gli attributi identificatori delle Entità. Per un elenco più

dettagliato degli attributi si rimanda alle tabelle descrittive di Entità e Relazioni .

28

Nome

(1,N)

(0,N)

(1,1)

(0,N)

(1,N)

(1,1)

(0,N)

(0,N)

Denominazione

ID

Sorgente

Sorgente

Ammin.

Sorgente

SISTAN

Unità di

rilevazione Argomento

Attributo

Rappresentazione

Origine Dati

Composizione.

Struttura

Attinenza

Nome

Nome

Nome

Supporto

Disponibilità

(0,N)

(0,N)

Riferimento

Unità di Analisi

(0,N)

(1,N)

Appartenenza

Statistica

(0,N)

Memorizzazione

Files

(0,N)

(0,N) (1,N)

URL

Nome

(1,N)

Tipo supporto

Note

29

L’Entità principale dello schema è la “Sorgente”, intesa come sorgente di informazioni. Ad

ogni “sorgente” è associato un codice identificativo univoco (ID) e una serie di attributi quali la

classe di appartenenza, il titolo, l’oggetto dell’analisi, il detentore, le coordinate del

responsabile, i vincoli sull’accessibilità, il minimo livello di aggregazione temporale, il minimo

livello di aggregazione geografico (sia per i dati divulgati che per quelli divulgabili), il periodo

di riferimento, la frequenza di acquisizione dei dati, la profondità dello storico ed il livello

qualitativo. Per poter rappresentare opportunamente la distinzione tra Sorgenti Amministrative

e Sorgenti SISTAN è stata introdotta una generalizzazione totale ed esclusiva2 dove le Entità

“Sorgente SISTAN” e “Sorgente Amministrativa” sono figlie dell’Entità “Sorgente”. Ad

ognuna di esse è associata una serie di attributi propri della particolare classe di sorgenti. In

particolare per le sorgenti SISTAN sono riportati il Piano Statistico Nazionale o il Catalogo

SISTAN di riferimento, il codice assegnato all’opera, l’area ed il settore d’interesse, il tipo di

copertura (totale, parziale o campionaria) e il tipo di sorgente (rilevazione, elaborazione o

studio progettuale). Per le sorgenti amministrative sono invece specificati il dipartimento, il

settore, l’ufficio e la norma di riferimento.

L’Entità “Unità di rilevazione” rappresenta l’insieme degli elementi da cui si acquisiscono le

informazioni riportate nelle sorgenti. “Unità di Rilevazione” è univocamente identificata

tramite l’attributo “Nome” ed è legata all’Entità “Sorgente” tramite la Relazione “Origine dati”.

Tale Relazione è dotata degli attributi “Numero di unità rilevate” e “Descrizione”. Una

“sorgente” è in relazione con zero o N “unità di rilevazione” mentre una “unità di rilevazione” è

in relazione con zero o più “sorgenti”.

L’Entità “Supporto” rappresenta invece i supporti di memorizzazione dei dati contenuti nelle

sorgenti. Essa è collegata a “Sorgente” tramite la Relazione “Disponibilità”, che ha come unico

attributo “Tipo di disponibilità” (“totale” o “parziale”). Una “sorgente” è disponibile su uno o

più “supporti” mentre un “supporto” (o meglio un tipo di supporto) può essere utilizzato per

memorizzare una o più “sorgenti”.

L’Entità “Rappresentazione” comprende tutti gli elementi di presentazione dell’informazione

contenuti nelle sorgenti (tabelle, tavole, grafici, etc.). Per ogni “rappresentazione”, identificata

dal proprio nome ed, esternamente, dall’identificatore della “sorgente” cui appartiene, sono

indicati una serie di attributi quali il tipo di rappresentazione (tabella, istogramma… ), una breve

descrizione, la presenza di testo a corredo della descrizione stessa, il tipo di supporto sul quale è

disponibile ed il livello di tale disponibilità (parziale o totale). L’Entità “Rappresentazione” è

2 Per generalizzazione totale ed esclusiva si intende una generalizzazione in cui ogni membro dell’Entità padre è membro di una ed una sola Entità figlia.

30

collegata a “Sorgente” tramite la Relazione “Struttura”. Una “rappresentazione” è contenuta in

una ed una sola “sorgente” mentre una “sorgente” contiene zero o più “rappresentazioni”.

L’Entità “Unità di Analisi” rappresenta l’insieme degli elementi da cui derivano le informazioni

riportate nelle “rappresentazioni”. Tale Entità è identificata dall’attributo “Nome” e legata a

“Rappresentazione” tramite la Relazione “Riferimento”. Su tale Relazione è indicato l’attributo

“Specificazione” che consente di descrivere meglio le “unità di analisi” collegate ad una

determinata “rappresentazione”.

Per ognuna delle “rappresentazioni” sono specificati gli “attributi” considerati (ovvero le

caratteristiche delle “unità di analisi”), rappresentati nello schema ER dall’Entità “Attributo”.

Tale Entità è legata a “Rappresentazione” attraverso la Relazione “Composizione”. Un

“attributo” appartiene ad una sola “rappresentazione” mentre una “rappresentazione” può

riportare zero o più “attributi”. Per ognuno degli “attributi” è indicato il nome, che funge da

identificatore, il tipo (qualitativo sconnesso, qualitativo ordinabile, quantitativo), il dominio

(numerico, stringa, etc.), l’unità di misura ed un commento usato per fornire eventuali

informazioni aggiuntive sull’“attributo” stesso.

L’Entità “Statistica” rappresenta l’insieme degli elementi informativi che possono essere

presenti nelle “rappresentazioni”. “Statistica” è univocamente identificata dall’attributo

“Nome” che rappresenta la denominazione della “statistica” in oggetto (“Tasso”, “Percentuale”,

“Frequenza relativa”, etc.). “Statistica” è legata a “Rappresentazione” tramite la Relazione

molti-a-molti “Appartenenza”.

L’Entità "Files" rappresenta l’insieme dei file che contengono le “rappresentazioni” in formato

digitale. Un “file” è univocamente identificato dall’attributo “URL” (che specifica il nome e il

percorso completo da seguire per rintracciare il “file” su Internet). “Files” è legato a

“Rappresentazione” dalla relazione molti-a-molti “Memorizzazione” alla quale è associato

l’attributo “Note”. Tale attributo serve a fornire istruzioni per la consultazione della

“rappresentazione” all’interno del “file”. Ciò può tornare utile, ad esempio, nel caso in cui un

“file” contenga più “rappresentazioni” e non sia immediato trovare quella che interessa.

Infine l’Entità “Argomento” rappresenta l’insieme delle voci del Thesaurus utilizzate per

facilitare le ricerche sulla base di dati. Tale Entità è univocamente identificata dall’attributo

“Denominazione” ed è legata a “Rappresentazione” dalla relazione molti-a-molti “Attinenza”.

Su tale relazione è definito l’attributo “Livello”, che specifica se un particolare argomento sia

riferito all’intera “rappresentazione” o solo ad alcuni suoi “attributi”.

31

6.2 Criteri di classificazione delle fonti

La scelta di classificare le sorgenti informative tramite un argomento, come descritto nella

sezione precedente, rappresenta un valido ausilio per ricercare in modo agevole le sorgenti di

interesse. Volendo arricchire le potenzialità di tale scelta è possibile definire una relazione

riflessiva Associato_a per l’entità Argomento con un attributo tipo.

Denominazione

TipoAssociato_a

Argomento

figlio

padre

I rami di tale relazione sono etichettati “padre” e “figlio”. Ciò vuole indicare che un argomento

padre può “racchiudere” in sé un argomento figlio, che corrisponde ad un livello di astrazione

più basso. Tramite l'attributo tipo è possibile classificare il tipo di corrispondenza (e.g., più

generale/meno generale, contenimento geografico, contenimento amministrativo/procedurale,

ecc.) Si è scelto di rappresentare solo questo tipo di relazione tra argomenti perché di natura

abbastanza generale e di facile applicazione. Tramite tale classificazione è possibile, inoltre,

gestire omonimi, sinonimi e termini corrispondenti in altre lingue3. Si realizza in questo modo

un semplice thesaurus, utile per espandere/restringere le interrogazioni sui metadati.

3 In tale contesto i ruoli padre e figlio perdono il loro significato strettamente gerarchico e possono essere utilizzati per meglio classificare la relazione in oggetto; ad esempio, in un caso di sinonimia il ruolo padre può essere attribuito al termine più frequentemente usato.

32

6.3 Tabelle descrittive delle Entità e delle Relazioni

6.3.1 Descrizione delle Entità

Entità: “Sorgente”

Attributo Descrizione

ID Identificativo univoco della “sorgente”

CLASSE Classe di appartenenza della “sorgente” (SISTAN,

Amministrativa Regione Lazio)

TITOLO Titolo della “sorgente” di informazioni

OGGETTO Argomento trattato nella “sorgente”

DETENTORE Ente o persona in possesso dei dati

RESPONSABILE Persona di riferimento per la consultazione dei dati

TELEFONO RESPONSABILE Numero telefonico del Responsabile

E-MAIL RESPONSABILE Indirizzo E-mail del responsabile

ACCESSO AI DATI Tipo di accesso ai dati (libero, condizionato… )

VINCOLI SULL’ACCESSO Breve testo descrittivo delle eventuali restrizioni o modalità per

l'accesso ai dati

NUMERO DI UNITÀ DI

MISURA TEMPORALI PER

LA FREQUENZA DI

ACQUISIZIONE

Numero di unità di misura temporali. Usato per indicare la

frequenza di acquisizione dei dati

UNITÀ DI MISURA

TEMPORALI PER LA

FREQUENZA DI

ACQUISIZIONE

Unità di misura usata per indicare la frequenza di acquisizione

dei dati

INIZIO PERIODO DI

RIFERIMENTO

Data di inizio del periodo cui si riferiscono i dati

FINE PERIODO DI

RIFERIMENTO

Data di fine del periodo cui si riferiscono i dati

PROFONDITÀ DELLO

STORICO

Data a partire dalla quale si è iniziato ad effettuare il tipo di

studio riportato nella “sorgente”

MINIMO LIVELLO DI

AGGREGAZIONE

GEOGRAFICA DATI

Minimo livello di aggregazione geografica per i dati divulgati

33

DIVULGATI

MINIMO LIVELLO DI

AGGREGAZIONE

GEOGRAFICA DATI

DIVULGABILI

Minimo livello di aggregazione geografica per i dati divulgabili

QUALITÀ Indice di qualità della “sorgente” definito dal gestore del

catalogo.

NUMERO DI UNITÀ DI

MISURA TEMPORALE PER

IL MINIMO LIVELLO DI

AGGREGAZIONE

TEMPORALE

Numero di unità di misura temporali. Usato per indicare il

minimo livello di aggregazione temporale.

UNITÀ DI MISURA

TEMPORALE PER IL

MINIMO LIVELLO DI

AGGREGAZIONE

TEMPORALE

Unità di misura usata per designare il minimo livello di

aggregazione temporale

Entità: “Sorgente Amministrativa”


DIPARTIMENTO Dipartimento di appartenenza

SETTORE Settore di appartenenza

UFFICIO Ufficio di appartenenza

NORMA Norma regolante la procedura cui si riferisce la “sorgente

amministrativa” in questione

Entità: “Sorgente SISTAN”


PROVENIENZA Piano Statistico Nazionale o Catalogo SISTAN di riferimento

CODICE Codice alfanumerico assegnato agli studi dal SISTAN

AREA Area statistica di interesse secondo la classificazione SISTAN

SETTORE Particolare settore dell’area di interesse secondo la classificazione

SISTAN

TIPO DI SORGENTE Tipologia della sorgente informativa (Rilevazione, Elaborazione,

34

Studio Progettuale)

COPERTURA Tipo di rilevazione (totale, parziale, campionaria)

INIZIO PERIODO

EFFETTUAZIONE

Data di inizio del periodo di effettuazione dello studio

FINE PERIODO

EFFETTUAZIONE

Data di fine del periodo di effettuazione dello studio

Entità: “Unità di rilevazione”


NOME Nome dell’unità di rilevazione

Entità: “Rappresentazione”


NOME Nome o titolo della “rappresentazione”

TIPO Tipo di “rappresentazione” (tabella, grafico, tavola demografica,

testo… .)

DESCRIZIONE Descrizione della “rappresentazione”

Entità: “Attributo”


NOME Nome dell’“attributo”

TIPO Tipo di dato (quantitativo, qualitativo ordinabile, qualitativo

sconnesso)

DOMINIO Dominio di appartenenza dell’“attributo” (es.: numeri reali,

numeri interi, etc.)

UNITÀ DI MISURA Eventuale unità di misura dell’“attributo”

COMMENTO Eventuali informazioni aggiuntive sull'

“attributo”

Entità: “Files”


FILE URL del file

35

Entità: “Argomento”


DENOMINAZIONE Denominazione dell’“argomento” (es.: sociale, sanità)

Entità: “Supporto”


TIPO SUPPORTO Definizione del tipo di “supporto” (cartaceo, digitale etc.)

Entità: “Unità di analisi”


NOME Nome dell’“unità di analisi”

Entità: “Statistica”


NOME Nome della “statistica” riportata nella rappresentazione

6.3.2 Descrizione delle Relazioni

Relazione: “Attinenza”


LIVELLO Indica se l’“argomento” in questione ha attinenza con l’intera

“rappresentazione” (attinenza “generale”) o solo con alcuni

“attributi” (attinenza “parziale”)

Relazione: “Origine dati”


NUMERO UNITÀ RILEVATE Numero di “unità di analisi” sulle quali sono stati acquisiti i dati

tramite le “unità di rilevazione”

COMMENTO Testo descrittivo

36

Relazione: “Riferimento”


COMMENTO Caratteristiche dell'“unità di analisi” con riferimento alla

particolare “rappresentazione”

Relazione: “Appartenenza”


DESCRIZIONE Eventuali informazioni aggiuntive sulla “statistica” con

riferimento alla particolare “rappresentazione” (es.: procedura

utilizzata per ottenerla)

Relazione: “Disponibilità”


TIPO DI DISPONIBILITÀ Grado di disponibilità delle informazioni su un determinato tipo

di “supporto” (Totale o parziale).

Relazione: “Disponibilità Rappresentazione”


TIPO DI DISPONIBILITÀ Grado di disponibilità della “rappresentazione” su un determinato

tipo di “supporto” (Totale o parziale).

Relazione: “Memorizzazione”


NOTE Istruzioni per la consultazione della “rappresentazione”

all’interno del “file”

37

7 Il prototipo

7.1 Descrizione del prototipo

Nell’ambito dello studio di fattibilità oggetto di questo documento, è stata disegnata ed

implementata l’applicazione “Catalogo Sorgenti” descritta nel seguito. Tale applicazione si

basa sull’uso di una base di dati relazionale per la memorizzazione delle informazioni e su di

un’interfaccia grafica amichevole per l’accesso e la gestione dei metadati. Nella fase

preliminare della progettazione è stata effettuata un’accurata analisi di detti metadati e di alcune

delle sorgenti informative allo scopo di comprenderne meglio la natura e l’organizzazione e per

individuare un sotto-insieme rappresentativo da utilizzare per il popolamento della base di dati.

Tale popolamento ha consentito di verificare l’adeguatezza dello schema della base di dati e la

rispondenza dell’applicazione ai requisiti esplicitati dal committente. Si ricorda che, come

sotto-insieme di prova, sono state considerate le “Sorgenti SISTAN” e le “Sorgenti

Amministrative”4. Per quel che riguarda il primo tipo i metadati sono stati presi dal “Piano

Statistico Nazionale 1998-2000”, dal “Piano Statistico Nazionale 2001-2003” e dai Cataloghi

del SISTAN dell’anno 2000 e precedenti. Per quel che riguarda il secondo tipo, i metadati sono

stati prelevati dal censimento delle sorgenti informative della Regione Lazio (IRELA). Come

settori di test sono stati scelti “Sociale” e “Cultura, Turismo e Spettacolo”. Il prototipo è stato

disegnato in modo da permettere, ove possibile, di accedere tramite link ipertestuali ai dati

contenuti nelle suddette sorgenti.

Nella progettazione dello schema della base di dati si è cercato di trattare in modo uniforme

tutti i tipi di sorgente. Per questo motivo è stata definita un’astrazione quanto più generale

possibile del concetto di “Sorgente” individuando quegli attributi (metadati) applicabili a tutte

le tipologie di sorgenti. Sono stati poi individuati i metadati specifici per ogni tipo di sorgente.

Ciò ha permesso di sintetizzare uno strumento che da un lato fornisce un accesso uniforme ai

metadati (almeno ad un primo livello di astrazione) e dall’altro consente di gestire in modo

diversificato informazioni non applicabili a tutti i tipi di sorgente.

La sintesi del prototipo è partita dalla definizione di uno schema Entità Relazione, presentato in

sezione 5, che descrive il punto di vista del fruitore delle informazioni contenute nelle sorgenti.

Questo schema è stato poi modificato in modo che fosse direttamente traducibile in uno schema

4 Per “Sorgente Amministrativa” si intende una sorgente di informazione appartenente alla pubblica amministrazione della Regione Lazio che può essere disponibile in formato cartaceo o digitale all’interno di un determinato Ufficio.

38

relazionale da utilizzare come punto di partenza per la definizione delle tabelle della base di

dati.

Per l’accesso ai dati è stata progettata e realizzata un’interfaccia grafica che permette di

sfogliare i dati ed effettuare ricerche in modo intuitivo. L’ultima sezione della presente sezione

descrive l’utilizzo dell’applicazione.

7.1.1 Ristrutturazione dello schema E-R

Lo schema ER descritto in sezione 5 non è direttamente traducibile in uno schema relazionale a

causa della presenza della generalizzazione che distingue le “sorgenti” in “sorgenti SISTAN” e

“sorgenti Amministrative”. Si è scelto di tradurre la generalizzazione in due Relazioni

(“Specificazione Sorgente SISTAN” e “Specificazione Sorgente Amministrativa”) che legano

le entità figlie “Sorgente SISTAN” e “Sorgente amministrativa” all’entità padre “Sorgente”. Le

“sorgenti SISTAN” e le “sorgenti amministrative” sono identificate esternamente tramite l’ID

della “sorgente” cui sono collegate. Per ogni istanza di “Sorgente SISTAN” vi sarà una ed una

sola istanza di “Sorgente” e per ogni istanza di “Sorgente” vi saranno zero o una istanze di

“Sorgente SISTAN”. Un discorso analogo può essere fatto per “Sorgente amministrativa”.

Nella seguente illustrazione è riportata la trasformazione della parte di schema E-R interessata.

(1,1) (1,1)

(0,1) (0,1)

ID

Sorgente

Sorgente Ammin.

Sorgente SISTAN

ID

Sorgente

Sorgente Ammin.

Sorgente SISTAN

Specificazione Sorgente Amm.

Specificazione Sorgente SISTAN

Un’ ulteriore modifica allo schema E-R è stata apportata in seguito al riscontro di una non

uniformità nella rappresentazione delle informazioni relative ai tipi di supporto. Nel caso delle

“sorgenti SISTAN”, infatti, tale informazione è fornita a livello di “sorgente” o di

“rappresentazione” mentre per le “sorgenti amministrative” il dato è riportato solo a livello di

singola “rappresentazione”. Per questo motivo è stata introdotta un’ulteriore Relazione tra

“Rappresentazione” e “Supporto” chiamata “Disponibilità rappresentazione”. L’illustrazione

che segue raffigura questa nuova relazione.

39

7.1.2 Schema relazionale

Una descrizione dettagliata della traduzione dello schema ER ristrutturato nel modello

relazionale va oltre gli scopi del presente documento; si presenta, quindi, una sintetica

descrizione grafica delle tabelle relazionali utilizzate dal prototipo.

Sintesi dello Schema Relazionale

Per problemi di spazio non è riportata la tabella che rappresenta la Relazione tra

“Rappresentazione” e “Supporto”. Tale Relazione è rappresentata mediante la tabella

“DISPONIBILITÀ RAPPRESENTAZIONE” che presenta i medesimi attributi della tabella

“DISPONIBILITÀ” più l’attributo “Nome Rappresentazione”.

Le tabelle “Classe Sorgente” e “Unità di misura temporale” rappresentano delle liste di valori

predefinite ed estensibili, utilizzate per rendere univoco l’inserimento di dati rispettivamente

(1,N)

Rappresentazione

Supporto Disponibilità

rappresentazione

(0,N)

40

nel campo Classe della tabella Sorgente e nei campi relativi ad unità di misura temporali della

tabella Sorgente SISTAN.

Si noti che la Relazione “Memorizzazione” è stata rappresentata tramite la tabella “Files”

mentre l’Entità “Files” non ha un corrispettivo nello schema relazionale in quanto la sua

traduzione in una tabella con il solo attributo “URL” comporta solo aggravi nella gestione del

db senza fornire alcun vantaggio. Nel caso in cui si volessero associare altri attributi all’Entità

“Files” si potrà prendere in considerazione l’implementazione di una tabella a parte che

rappresenti l’Entità “Files”.

Una descrizione dettagliata degli attributi delle tabelle con i relativi tipi può essere reperita

lanciando l’applicazione “Catalogo Sorgenti” descritta nel successivo capitolo ed aprendo le

tabelle stesse in modalità “Visualizzazione Struttura”.

7.2 Manuale utente

“Catalogo Sorgenti” si propone come prototipo di uno strumento di consultazione di metadati

relativi a sorgenti di informazione accessibili alla Pubblica Amministrazione della Regione

Lazio. L’applicazione permette inoltre di accedere, ove possibile, direttamente ai dati tramite

collegamenti di tipo URL (Uniform Resource Locator).

La tecnologia scelta per l’implementazione del prototipo è quella fornita da Microsoft Access.

Tale scelta non è in alcun modo vincolante per la realizzazione dell’applicazione che andrà in

esercizio in quanto operata unicamente per motivi di rapidità di prototipazione. La soluzione

più appropriata per un servizio di questo tipo è l’utilizzo di base di dati professionali (Oracle,

Informix, Sybase, etc.) in grado di gestire grandi moli di dati, elevati numeri di transazioni per

secondo e che permettono al contempo di realizzare servizi ad alta disponibilità (24 ore su 24,

365 giorni all’anno) con basse probabilità di arresto totale del servizio. Per quel che riguarda le

interfacce di accesso sembra invece appropriata l’adozione di soluzioni basate sull’uso del

Web.

Tutti gli elementi contenuti nel presente prototipo possono essere realizzati con le tecnologie

sopra descritte.

7.2.1 Prerequisiti per l’utilizzo dell’applicazione

“Catalogo Sorgenti” è stato realizzato con Microsoft Access 2000. Per poterlo utilizzare è

pertanto necessario disporre di tale programma. Si consiglia di utilizzare l’impostazione

“Caratteri Piccoli” nelle proprietà del desktop. Per cambiare tale impostazione è sufficiente

cliccare col pulsante destro in una zona vuota del desktop e selezionare “Proprietà” nel menu a

comparsa. Selezionare poi nella finestra “Proprietà – Schermo” il tab “Impostazioni” e cliccare

41

sul pulsante “Avanzate” in basso sulla destra. Scegliere nella combo-box “Dimensione

Caratteri” la voce “Caratteri Piccoli” e premere il pulsante “Ok”. Premere infine il pulsante

“Ok” nella finestra “Proprietà – Schermo”.

7.2.2 Avvio, navigazione, gestione dei dati e ricerche

“Catalogo Sorgenti” è fornito sotto forma di file “.mdb” (il formato standard di Microsoft

Access). Il nome di tale file è CatalogoSorgenti.mdb. Per aprire il database è sufficiente cliccare

due volte sull’icona del file. In Figura 6 è riportata la prima schermata che si presenta all’utente

quando avvia l’applicazione.

Figura 6 Menu principale

Come si può vedere dall’illustrazione, l’applicazione è organizzata in tre sezioni:

? ? Catalogo Sorgenti: questa sezione permette di “sfogliare” il catalogo e di visualizzare le

informazioni di dettaglio relative a ciascuna sorgente.

? ? Gestione Thesaurus: questa sezione permette al gestore del catalogo di definire un

thesaurus, ovvero un elenco di parole chiave o concetti che possono essere associati alle

“rappresentazioni” contenute nelle diverse sorgenti (si ricorda che per

“rappresentazione” si intende un qualunque oggetto che contenga informazioni sotto

forma di grafico, tabella, etc.).

? ? Ricerche: questa sezione permette all’utente di effettuare ricerche sul catalogo sorgenti

in base a differenti criteri.

42

Il pulsante “Chiudi” permette di uscire dall’applicazione.

Nel seguito è descritto il dettaglio delle sezioni sopra elencate.

7.2.3 Sezione “Catalogo Sorgenti”

Cliccando sul pulsante “Catalogo Sorgenti” del menu principale si accede ad una schermata

simile a quella riportata in Figura 7.

Figura 7 Schermata principale della sezione "Catalogo Sorgenti"

È opportuno illustrare la struttura di questa schermata perché tutte le finestre del prototipo qui

descritto sono basate sul medesimo schema. Nella parte in alto è possibile vedere l’intestazione

della finestra, che in questo caso riporta la scritta “Catalogo Sorgenti”. Nella regione che si

trova immediatamente sotto l’intestazione sono riportati i dati (o più precisamente i metadati).

Si ricorda che le finestre utilizzate in questa applicazione consentono di visualizzare il

43

contenuto delle tabelle di un database relazionale un record alla volta. A piè di pagina sono

collocati due gruppi di pulsanti: “Funzioni di Navigazione ed Aggiornamento” e “Informazioni

Correlate”. Il primo gruppo contiene le funzionalità che permettono di “sfogliare” il catalogo

delle sorgenti e di inserire nuove voci nel catalogo stesso. Il secondo consente di accedere ad

informazioni di dettaglio associate alla sorgente correntemente visualizzata. Il gruppo

“Funzioni di Navigazione ed Aggiornamento” è presente in quasi tutte le finestre

dell’applicazione mentre il gruppo “Informazioni Correlate” è presente solo nei casi in cui

esistano informazioni correlate cui accedere.

Il pulsante , presente in tutte le maschere dell’applicazione, permette di chiudere la

finestra.

La seguente tabella illustra il significato dei campi riportati nella schermata di Figura 7.

44

Campo Tipo di dato Descrizione

ID Numerico Identificativo numerico univoco assegnato

dall’applicazione ad una sorgente al

momento della creazione del relativo

record.

Classe di appartenenza Testo Indica la tipologia di sorgente (SISTAN,

Amministrativa Reg. Lazio). La lista delle

tipologie può essere estesa in una futura

implementazione.

Titolo Testo Titolo della sorgente

Oggetto Testo Testo illustrativo degli argomenti trattati

nella sorgente

Detentore Testo Ente o persona cui appartiene la sorgente

Responsabile Testo Nome della persona responsabile della

sorgente in questione (es.: la persona alla

quale ci si può rivolgere per accedere alla

sorgente)

Telefono Responsabile Testo Recapito telefonico del responsabile

E-mail Responsabile Testo Indirizzo di posta elettronica del

responsabile

Vincoli sull’accesso ai

dati

Testo Testo illustrativo delle eventuali restrizioni

sull’accesso ai dati.

Dati acquisiti ogni Attributo composto da

due campi: uno

numerico e uno di tipo

“Lista di valori” che

indica l’unità di misura

temporale.

Serve per indicare la frequenza di

acquisizione dei dati. Ad es. se i dati

vengono acquisiti ogni anno il campo

numerico avrà valore “1” e il campo

testuale sarà impostato ad “anno”.

Periodo di riferimento:

dal

data Inizio del periodo cui si riferiscono le

informazioni contenute nella sorgente.

Periodo di riferimento: al data Fine del periodo cui si riferiscono le

informazioni contenute nella sorgente.

Profondità dello storico data Data a partire dalla quale si è cominciato

45

ad effettuare la raccolta di informazioni del

tipo riportato nella sorgente in oggetto.

Minimo livello di

aggregazione geografica

per i dati divulgabili

{circoscrizione,

municipio, comune,

area metropolitana,

distretto, provincia,

regione, nazione}

Indica , a livello geografico, la granularità

più fine di presentazione delle

informazioni per quel che riguarda i dati

divulgabili.

Minimo livello di

aggregazione geografica

per i dati divulgati

{circoscrizione,

municipio, comune,

area metropolitana,

distretto, provincia,

regione, nazione}

Indica , a livello geografico, la granularità


informazioni per quel che riguarda i dati

divulgati.

Minimo livello di

aggregazione temporale

Attributo composto da

due campi: uno

numerico e uno di tipo

“Lista di valori” che

indica l’unità di misura

temporale.

Indica , a livello temporale, la granularità


informazioni.

Qualità {alta, media, bassa} Indice di qualità della sorgente.

Rappresenta il giudizio del gestore del

“Catalogo Sorgenti” sulla attendibilità

della sorgente in oggetto.

Di seguito è riportata la descrizione dettagliata delle funzionalità contenute nei due gruppi di

pulsanti.

Funzioni di Navigazione ed Aggiornamento

? ? Primo Record: va al primo record della tabella;

? ? Record Precedente: va al record precedente rispetto a quello correntemente visualizzato;

? ? Record Successivo: va al record successivo rispetto a quello correntemente visualizzato;

? ? Ultimo record: va all’ultimo record della tabella;

? ? Nuovo Record: crea un nuovo record vuoto nella tabella;

46

? ? Salva Record: salva le modifiche apportate ad un record;

? ? Elimina Record: elimina il record correntemente visualizzato.

Informazioni Correlate

? ? Tavole, Grafici, etc.: metadati relativi a rappresentazioni contenute nella sorgente

correntemente visualizzata;

? ? Supporti: informazioni relative ai tipi di supporto su cui è disponibile la sorgente


? ? Unità di Rilevazione: entità che hanno fornito le informazioni contenute nella sorgente


? ? Metadati Specifici: informazioni sulla sorgente correntemente visualizzata applicabili

solo alla tipologia cui essa appartiene (SISTAN, Amm. Regione Lazio)

Per quel che riguarda i Metadati Specifici è opportuno precisare che, se da un lato esistono

metadati applicabili in linea di principio a qualunque tipo di sorgente, ve ne sono degli altri che

hanno senso solo per una determinata categoria di sorgenti. Da ciò nasce l’esigenza di avere

una finestra comune a tutti i tipi di sorgenti (Catalogo Sorgenti) e finestre differenziate per

visualizzare i metadati specifici.

Ciascuno dei pulsanti del gruppo “Informazioni Correlate” apre una finestra contenente ulteriori

informazioni sulla sorgente correntemente visualizzata. Di seguito è riportata la descrizione di

tali finestre.

7.2.3.1 Tavole, Grafici, etc.

Cliccando sul pulsante “Tavole, Grafici, etc.” della finestra “Catalogo Sorgenti” si accede alla

finestra riportata in Figura 8.

47

Figura 8: Sottosezione “Rappresentazioni: Tavole, Grafici, etc”

Per “rappresentazione” si intende un qualunque modo di schematizzare e presentare delle

informazioni, sia esso una tavola, un grafico o altro. La finestra sopra riportata permette di

accedere alle informazioni relative alle rappresentazioni contenute nella sorgente correntemente

visualizzata nella finestra “Catalogo Sorgenti” 5. All’inizio dell’area di visualizzazione dei dati

sono riportati per comodità l’ID della sorgente e il titolo. Lo sfondo grigio di questi due campi

indica che non possono essere modificati all’interno di questa finestra. Nella seguente tabella

5 Per quel che riguarda il popolamento del db con i dati di test, il criterio utilizzato per le Sorgenti Amministrative è stato quello di considerare come “rappresentazioni” ciò che nelle schede IRELA è riportato sotto la voce “Unità di analisi”. Di fatto si ha una rappresentazione per ogni unità di analisi. Quindi, nel caso delle Sorgenti Amministrative, ogni rappresentazione ha lo stesso nome dell’unità di analisi cui si riferiscono le informazioni in essa riportate ed è dotata degli attributi elencati nelle schede IRELA per quella unità di analisi. Si noti che nelle schede IRELA gli attributi delle unità di analisi sono indicati con il nome di “Variabili”.

48

sono riportate le descrizioni dei campi contenuti nella finestra “Rappresentazioni: Tavole,

Grafici, etc.” di Figura 8.

Nome Tipo di dato Descrizione

Nome Testo Nome della rappresentazione

Tipo {Tabella, Grafico, Tavola

Demografica, Tavola, etc.}

Tipo di rappresentazione. Elenca i vari tipi

di rappresentazione che possono essere

riscontrati nelle sorgenti informative.

Note Testo Campo descrittivo della rappresentazione.

Può essere usato per meglio descrivere la

rappresentazione stessa.

Nota: è importante ribadire che per “Rappresentazioni” non si devono intendere solo tabelle del

tipo utilizzato nei database relazionali ma anche appartenenti ad altre tipologie (come ad

esempio le tabelle a doppia entrata) utilizzate in statistica o in altri campi.

Tralasciamo la descrizione del gruppo di pulsanti “Funzioni di navigazione ed aggiornamento”

in quanto identico a quello della finestra “Catalogo Sorgenti”. Di seguito è riportata la

descrizione dei pulsanti del gruppo “Informazioni Correlate”.

? ? Files: permette di accedere ad uno o più file contenenti la rappresentazione in oggetto.

Cliccando su questo pulsante si accede ad una finestra come quella riportata nella Figura

9.

49

Figura 9: Finestra “Files”

In essa sono riportati per comodità l’ID e il titolo della sorgente cui appartiene la

rappresentazione e il nome della rappresentazione stessa. Tali campi non sono editabili

in questa finestra. La tabella che segue illustra il significato degli altri campi.

Nome Tipo Descrizione

URL URL Link al file stesso. Cliccando su di esso si

accede al file vero e proprio, che può

risiedere sulla macchina locale o su una

qualunque altra macchina collegata tramite

web.

Istruzioni per la

consultazione

Memo Istruzioni aggiuntive per la consultazione del

file

Cliccando sul contenuto del campo “File” si accede direttamente alle informazioni, cioè a dati contenuti nella sorgente. Nel caso della schermata riportata in Figura 9 viene

50

aperto il file xls riportato in Figura 10.

Figura 10: Contenuto di una rappresentazione memorizzata in un file xls

? ? Voci Thesaurus: permette di aprire la finestra riportata in Figura 11. Questa maschera

permette di visualizzare le voci del thesaurus associate alla rappresentazione

correntemente visualizzata in “Rappresentazioni: Tavole, Grafici, etc.”. All’inizio

dell’area di visualizzazione dei dati sono riportati per comodità i campi “ID Sorgente”,

“Titolo” e “Rappresentazione”. Nella tabella che segue sono descritti i rimanenti campi.

Nome Tipo Descrizione

Argomento Lista di valori testuali. L’elenco di tali

valori è memorizzato in una tabella il

cui contenuto è accessibile e

modificabile all’interno della sezione

“Gestione Thesaurus”.

Concetti che possono essere

associati ad una

rappresentazione per

facilitare le ricerche tramite

parola-chiave.

Livello di

attinenza

{Attributo, Rappresentazione} Specifica se la voce del

thesaurus può essere associata

51

ad un singolo attributo

riportato nella

rappresentazione oppure

all’intera rappresentazione.

Figura 11: Voci Thesaurus associate

? ? Statistiche riportate: permette di visualizzare i tipi di statistiche riportate nella

rappresentazione. Cliccando su questo pulsante si apre la finestra di Figura 126.

6 Nel caso di sorgenti amministrative in genere non sono riportate statistiche. Per quel che riguarda le sorgenti SISTAN sono state indicate le tipologie di statistiche riportate nella rappresentazione. Ad esempio, nel caso di una distribuzione percentuale nel campo “Oggetto” della maschera “Statistica” è stata inserita la voce “Percentuale”

52

Figura 12: Statistiche riportate

All’inizio dell’area di visualizzazione dei dati sono riportati per comodità “ID

Sorgente”, “Titolo Sorgente” e “Nome Rappresentazione”. Nella tabella che segue sono

riportati i significati degli altri due campi.

Nome Tipo di Dato Descrizione

Oggetto {Frequenza assoluta,

Frequenza Relativa, Indice,

Numerosità, Percentuale,

Probabilità, Rapporto, Tasso,

etc.}

Indica il tipo di statistica

riportato nella

rappresentazione

Commento Testo Eventuale testo esplicativo.

53

Attributi: permette di visualizzare gli attributi della rappresentazione. Cliccando su questo pulsante si apre la finestra di Figura 137.

Figura 13: Attributi

All’inizio dell’area di visualizzazione dei dati sono riportati per comodità “ID Sorgente”,

“Titolo Sorgente” e “Nome Rappresentazione”. Nella tabella che segue sono riportati i

significati degli altri campi.


Nome Attributo Testo Nome dell’attributo così come

riportato nella rappresentazione

Tipo {Qualitativo sconnesso, Qualitativo

ordinabile, Quantitativo}

Indica la tipologia alla quale

appartiene l’attributo.

Dominio Testo Denominazione dell’insieme di

7 Per quel che riguarda il data entry, nel caso di Sorgenti SISTAN sono stai inseriti gli attributi riferiti alle unità di analisi (ad esempio per una distribuzione dei residenti per età e sesso sono state immesse le voci “età” e “sesso”) mentre nel caso di Sorgenti Amministrative sono state inserite, per ognuna delle unità di analisi, le voci riportate sotto la dicitura “Variabili”.

54

valori che può assumere

l’attributo (es.: numeri interi,

numeri reali, etc.).

Unità di misura Testo Utilizzato solo nei casi in cui

l’attributo sia di tipo

quantitativo ed esprima la

misura di una qualche

grandezza.

Commento Testo Eventuali informazioni

aggiuntive sull’attributo.

? ? Unità di Analisi: permette di accedere all’elenco delle entità cui si riferiscono le

informazioni riportate nella rappresentazione in questione. Si faccia attenzione che in

questo caso si deve intendere “entità” in senso generico e non nel contesto degli schemi

Entità Relazione. Cliccando su questo tasto si accede alla finestra riportata in Figura

148.

8 Per fare un esempio di come è stato effettuato il data entry in questa maschera, per una Sorgente SISTAN contenente una rappresentazione che riporta la distribuzione delle persone residenti per sesso ed età, nel campo “Unità di analisi” è stata inserita la voce “persona residente”. Nel caso delle Sorgenti Amministrative nel campo “Unità di analisi” è stato ripetuto il nome usato per la rappresentazione cui l’unità di analisi è associata.

55

? ?

Figura 14: Unità di analisi


“Titolo Sorgente” e “Nome Rappresentazione”. Nella tabella che segue sono riportati i


56


Unità di analisi Lista di valori. Se l’unità di analisi

che si intende indicare non compare

nella lista, è possibile aggiungerla

cliccando sul tasto “Aggiungi unità

di analisi”.

Denominazione dell’unità di

analisi

Descrizione Testo Testo esplicativo utilizzato nel

caso in cui sia necessario

fornire informazioni aggiuntive

oltre il nome dell’unità di

analisi.

Cliccando sul pulsante “Aggiungi unità di analisi” si apre una finestra come quella di

fig. 11

Figura 15: Finestra per l'inserimento di nuove unità di analisi

Tale finestra permette di aggiungere una nuova unità di analisi alla lista cliccando sul

pulsante “Nuovo Record”, scrivendo il nome nel campo “Nome Unità di analisi” e

salvando poi il record mediante pressione del pulsante “Salva Record”.

57

? ? Dettaglio supporti: permette di accedere alla finestra di Figura 16

Figura 16: dettaglio dei supporti relativi ad una rappresentazione

In questa schermata è possibile visualizzare le informazioni di dettaglio relative ai

supporti sui quali sono disponibili le rappresentazioni9.

All’inizio dell’area di visualizzazione dei dati sono riportati per comodità “ID Sorgente”

e “Nome Rappresentazione”. Nella tabella che segue sono riportati i significati degli

altri campi.

9 Il data-entry in questa maschera è stato effettuato secondo i seguenti criteri: nel caso delle “Sorgenti Amministrative” è stata indicata la tipologia di supporto riportata nella schede IRELA in corrispondenza della fase amministrativa cui la rappresentazione appartiene (si ricordi che quello che nelle schede IRELA è chiamato “Unità di analisi” è stato considerato nel data entry come corrispondente ad una rappresentazione con un’unica unità di analisi); nel caso delle “Sorgenti SISTAN” il dato relativo ai supporti è disponibile solo a livello di “Sorgente”, per cui non sono stati inseriti dati in questa maschera.

58


Tipo Supporto {digitale, cartaceo} Indica il tipo di supporto sul

quale è disponibile la

rappresentazione.

Tipo Disponibilità {totale, parziale} Indica se la rappresentazione è

totalmente o parzialmente

disponibile su un certo tipo di

supporto.

7.2.3.2 Supporti

Ritornando alla finestra “Catalogo sorgenti” continuiamo la descrizione della sezione

“Informazioni correlate” descrivendo le funzionalità accessibili tramite il pulsante “Supporti”.

Cliccando su tale pulsante si accede alla finestra riportata in Figura 17.

Figura 17: Supporti di memorizzazione delle sorgenti

Come già detto sopra, nel caso delle sorgenti amministrative ( e talvolta anche per le sorgenti

SISTAN) le informazioni di dettaglio relative ai supporti sono disponibili a livello di singola

rappresentazione ed accessibili dalla finestra “Rappresentazioni: Tavole, Grafici, etc.”. Per quel

59

che riguarda la maschera di Figura 17, all’inizio dell’area di visualizzazione dei dati sono

riportati per comodità “ID Sorgente”, “Titolo Sorgente”. Nella tabella che segue sono riportati i



Tipo Supporto {digitale, cartaceo, etc.} Indica il tipo di supporto sul

quale è disponibile la sorgente.

Tipo Disponibilità {totale, parziale} Indica se la sorgente è

totalmente o parzialmente

disponibile su un certo tipo di

supporto.

7.2.3.3 Unità di Rilevazione

Per “Unità di rilevazione” si intendono le entità che forniscono le informazioni sulle unità di

analisi. Ad esempio un comune può fornire informazioni sulle biblioteche che si trovano sul suo

territorio. In questo caso il comune funge da unità di rilevazione. Cliccando sul pulsante “Unità

di Rilevazione” della maschera “Catalogo Sorgenti” si apre la finestra riportata in Figura 1810

10 Sia nelle schede IRELA che nelle schede del Piano Statistico Nazionale le unità di rilevazione sono esplicitamente indicate.

60

Figura 18: Unità di rilevazione


“Titolo Sorgente”. Nella tabella che segue sono riportati i significati degli altri campi.


Unità di Rilevazione Lista di valori. Se l’unità di

rilevazione che si intende indicare

non compare nella lista, è possibile

aggiungerla cliccando sul tasto

“Aggiungi unità di rilevazione”.

Denominazione dell’unità di

rilevazione

Note Testo Informazioni aggiuntive

sull’unità di rilevazione in

questione

Numero unità rilevate Numerico Numero di unità di rilevazione

dalle quali sono stati attinti i

dati

61

Cliccando sul pulsante “Aggiungi Unità di Rilevazione” si apre la finestra riportata in Figura

19.

Figura 19: Finestra per l'inserimento di nuove unità di rilevazione

Tale finestra permette di aggiungere una nuova unità di rilevazione alla lista cliccando sul

pulsante “Nuovo Record”, scrivendo il nome nel campo “Nome” e salvando poi il record

mediante pressione del pulsante “Salva Record”.

7.2.3.4 Metadati Specifici

Per “Metadati Specifici” si intendono quei metadati applicabili ad un certo tipo di sorgente

(SISTAN, Amm. Regione Lazio, etc.) ma non ad altri. Premendo questo pulsante della finestra

“Catalogo Sorgenti” compare una finestra il cui contenuto dipende dal tipo di sorgente in

questione. Nel caso di sorgenti SISTAN si apre la finestra di Figura 20 mentre nel caso di

sorgenti Amministrative della Regione Lazio compare la finestra di Figura 21. All’inizio delle

aree di visualizzazione dei dati sono riportati, in entrambe le finestre, “ID Sorgente” e “Titolo

Sorgente”.

Nota: le sorgenti amministrative della Regione Lazio fanno riferimento a procedure interne

della Pubblica Amministrazione e per questo sono associate ad un dipartimento, ad un settore e

ad un ufficio. Tra i metadati specifici delle sorgenti amministrative della Regione Lazio sono

riportate anche i riferimenti alle norme che regolano tali procedure.

Nella tabella che segue sono riportati i significati degli altri campi.

62

Metadati Specifici Sorgenti SISTAN


Provenienza Testo Piano Statistico Nazionale o

Catalogo SISTAN cui

appartiene la sorgente in

questione

Codice Testo Identificativo alfanumerico

univoco della sorgente

Tipo Sorgente {Rilevazione, Elaborazione, Studio

Progettuale}

Indica se i dati contenuti nella

sorgente sono frutto di una

rilevazione sul campo, di una

elaborazione di dati contenuti in

altre sorgenti o di uno studio

progettuale

Area Testo Area di appartenenza della

sorgente SISTAN

Settore Testo Settore di appartenenza della

sorgente SISTAN

Copertura {Totale, Campionaria, Parziale} Specifica il rapporto tra

l’universo dell’unità che

compongono il fenomeno

oggetto di studio e l’insieme

delle unità effettivamente

rilevate.

Periodo di effettuazione dal Data Inizio del periodo di

effettuazione

Periodo di effettuazione al Data Fine del periodo di

effettuazione

Nota: in alcuni casi sono state riscontrate delle difformità tra le denominazioni dei settori e

delle aree usate nel PSN e quelle usate nel catalogo SISTAN.

63

Metadati Specifici Sorgenti Amministrative della Regione Lazio


Dipartimento Testo Dipartimento di appartenenza

della sorgente amministrativa

Settore Testo Settore di appartenenza della

sorgente amministrativa

Ufficio Testo Ufficio di appartenenza della

sorgente amministrativa

Norma Testo Norma che regola la procedura

cui si riferisce la sorgente in

questione.

Figura 20 Metadati specifici delle Sorgenti SISTAN

64

Figura 21: Metadati Specifici Sorgenti Amministrative

7.2.4 Sezione “Gestione del Thesaurus”

Questa sezione è stata semplicemente abbozzata nel presente prototipo. In pratica è stato fornito

uno strumento per gestire un elenco di voci (o argomenti) che possono essere associate alle

rappresentazioni e che possono poi essere utilizzate come chiavi di ricerca (vedi sezione

“Ricerche”). In una futura implementazione sarebbe utile poter definire anche delle relazioni tra

gli argomenti dell’elenco. Ad esempio si potrebbe fornire la possibilità di indicare che un certo

concetto include un altro concetto. Si potrebbe poi fare in modo che quando un utente ricerca

tutte le sorgenti che contengono rappresentazioni collegate ad un certo argomento (ad esempio

“edilizia”) nella lista dei risultati fossero riportate anche tutte le sorgenti che contengono

rappresentazioni collegate ad argomenti inclusi in “edilizia” (es.: edilizia scolastica, edilizia

ospedaliera etc.).

Cliccando sul pulsante “Gestione Thesaurus” del Menu Principale sia accede alla finestra

riportata in Figura 22.

65

Figura 22: Gestione Thesaurus

Tramite i pulsanti collocati in basso nella finestra è possibile scorrere l’elenco degli argomenti e

aggiungere od eliminare elementi dalla lista.

7.2.5 Sezione “Ricerche”

Cliccando sul pulsante “Ricerche” del Menu Principale si accede alla sezione “Ricerche”. Tale

sezione presenta inizialmente un menu come quello riportato in Figura 23. I pulsanti di questo

menu permettono di accedere alle seguenti funzionalità:

? ? Search Engine Generale: permette di effettuare una ricerca in base al contenuto di uno

più campi della maschera Catalogo Sorgenti.

? ? Ricerca per Argomento: permette di effettuare ricerche in base a voci contenute nel

thesaurus e al periodo di riferimento della sorgente.

? ? Torna a menu principale: permette di tornare al Menu Principale.

66

Figura 23: Menu “Ricerche”

Esaminiamo ora una per una le funzionalità.

7.2.5.1 Search Engine Generale

Cliccando sul pulsante “Search Engine Generale” del menu “Ricerche” si accede alla finestra

riportata in Figura 24.

67

Figura 24: Search Engine

Come si può osservare tale maschera è molto simile alla maschera “Catalogo Sorgenti” eccetto

che per i bottoni in basso. Per default i campi sono impostati in modo tale che premendo il

pulsante “Cerca” si ottenga la lista completa delle sorgenti contenute nel catalogo. Per i campi

testuali il carattere jolly è “*” mentre per il campi numerici è “0”. Il comportamento della

Search Engine è il seguente:

? ? Campi di testo: cerca tutte le sorgenti per le quali il testo immesso in un determinato

campo della maschera “Search Engine” è contenuto come sottostringa nel

corrispondente campo della maschera “Catalogo Sorgenti”.

? ? Combo box (campi a scelta multipla all’interno di un insieme predeterminato di valori):

cerca tutte le sorgenti per le quali il testo immesso in un determinato campo della

maschera “Search Engine” è esattamente uguale al corrispondente campo della

maschera “Catalogo Sorgenti”.

? ? Campi numerici: cerca tutte le sorgenti per le quali il testo immesso in un determinato

campo della maschera “Search Engine” è esattamente uguale al corrispondente campo

della maschera “Catalogo Sorgenti”.

68

? ? Campi data: in questo caso il comportamento cambia a seconda del significato del

campo. Nel caso di “Periodo di riferimento dal” e “Periodo di riferimento al” vengono

selezionate tutte le sorgenti il cui periodo di riferimento presenta un overlapping

(sovrapposizione) anche di un solo giorno con quello indicato nella maschera “Search

Engine”. Per quel che riguarda la “Profondità dello storico” vengono selezionate tutte le

sorgenti che hanno una profondità dello storico almeno uguale a quella indicata nella

maschera di Search.

Nota: cliccando su un campo, questo viene resettato al valore di default.

Cliccando sul pulsante “Cerca” si ottengono i risultati della ricerca sotto forma di lista. La

corrispondente schermata è mostrata in Figura 25. Come si può vedere, per ciascuno dei

risultati sono riportati i campi ID, Classe, Titolo e Oggetto. La lista dei risultati può essere

scorsa usando la scroll bar sulla destra. Per visualizzare tutte le informazioni disponibili su una

determinata sorgente è sufficiente selezionarla nella finestra dei risultati (cliccando su di essa) e

premere il pulsante “Dettagli Sorgente”. In questo modo si aprirà la finestra “Catalogo

Sorgenti” che mostrerà i metadati associati alla sorgente selezionata (Figura 26).

7.2.5.2 Ricerche per Argomento

Cliccando sul pulsante “Ricerche per Argomento” del menu “Ricerche” si apre la finestra di

Figura 27. In tale finestra è possibile selezionare un argomento da una lista (ovvero una voce

del Thesaurus) ed un intervallo indicante il periodo di riferimento. Per quel che riguarda il

“Periodo di riferimento” il comportamento è identico a quello della Search Engine Generale,

ovvero vengono selezionate tutte le sorgenti il cui periodo di riferimento presenta un

overlapping (sovrapposizione) anche di un solo giorno con quello indicato nella maschera

“Ricerche per argomento”. Anche in questo caso i risultati sono presentati in forma di lista

riassuntiva (Figura 28) ed i dettagli relativi a ciascun risultato possono essere visualizzati

cliccando sul pulsante “Dettagli Sorgente”. Nel caso del risultato selezionato in Figura 28 il

dettaglio dei metadati ad esso relativi è visualizzato in Figura 29.

69

Figura 25: Risultati di una ricerca

70

Figura 26: Dettagli relativi ad un risultato della ricerca

71

Figura 27: Ricerche per argomento

Figura 28: Risultati ricerche per argomento

72

Figura 29: Dettagli relativi ad un risultato di una ricerca per argomento

73

8 Proposta operativa

L'ultima attività svolta nell'ambito dello studio di fattibilità è relativa alla individuazione di

piano di lavoro per la realizzazione di un sistema completo nonchè ad una stima dei tempi e dei

costi.

Si presenta, nel seguito, l'articolazione in fasi del piano di lavoro, articolazione che prevede tre

fasi, della durata complessiva di 30 mesi.

Le seguenti sezioni fanno riferimento alla terminologia introdotta nella sezione 2 ed alla

architettura individuata in sezione 3

8.1 Fase 1: Realizzazione del data warehouse di primo livello

La fase 1, della durata di 12 mesi, ha come obbietivo la progettazione e la realizzazione della

base dei metadati e del data warehouse di primo livello. Il data warehouse di primo livello sarà

popolato prevalentemente da dati estratti da fonti disponibili su supporti informatici.

8.1.1 Attività 1.1 - Analisi

La formalizzazione delle specifiche utente dovrà produrre, attraverso una stretta interazione con

il committente, una specifica formale delle indicazioni di massima presenti nella prima parte di

questo documento.

Obbietivi dell’analisi delle fonti informative sono:

? ? censire le sorgenti informative indicate dal committente;

? ? individuare le tipologie delle varie sorgenti informative che andranno ad alimentare il

data warehouse e, per ciascuna di queste, determinare quali sono le grandezze utili a

descriverle.

8.1.2 Attività 1.2 - Progettazione (dati e metadati)

La base dei metadati è la parte del sistema che contiene la descrizione delle sorgenti

informative presenti nel data warehouse, e permette l’interrogazione delle stesse L’utente dovrà

avere la possibilità di interrogare l’archivio dei metadati specificando criteri di selezione anche

basati su un thesaurus di argomenti.

Parallelamente alla progettazione della base di dati relativa ai metadati, si procederà alla

progettazione del data warehouse di primo livello ed alla progettazione delle procedure di

caricamento dei dati per le fonti individuate.

74

8.1.3 Attività 1.3 Realizzazione (metadati)

Prevede la realizzazione delle procedure per il caricamento nel data warehouse dei metadati che

descrivono le tipologie di sorgenti individuate nella attività 1.1, e l’effettivo popolamento della

base di dati relativa ai metadati, principalmente a partire da fonti disponibili su supporti

informatici. Contestualmente, gli argomenti coperti dalle fonti censite dovranno essere

organizzati in un thesaurus (come descritto nell'allegato B).

8.1.4 Attività 1.4 Realizzazione (dati)

Prevede la realizzazione delle procedure per il caricamento nel data warehouse dei dati estratti

dalle sorgenti individuate, e il popolamento del data warehouse di primo livello. Le fonti

selezionate saranno disponibili prevalentemente su supporti informatici.

8.1.5 Attività 1.5 Sperimentazione

Questa attività coinvolge direttamente le figure interne al committente. I sistemi realizzati

verranno sperimentati e collaudati congiuntamente dal realizzatore e dal committente. A valle

del collaudo verranno evidenziate eventuali inadeguatezze delle specifiche utente e dei requisiti

del sistema.

8.2 Fase 2: Realizzazione del data warehouse di secondo livello

La fase 2, della durata di 10 mesi, prevede il consolidamento delle specifiche del sistema ed il

completamento del data warehouse di primo livello. Verranno, quindi ripercorse le fasi di

analisi, progettazione e realizzazione, al fine di estendere le funzionalità del sistema.

8.2.1 Attività 2.1 Estensione dei requisiti

Alla luce delle considerazioni scaturite a valle della attività di sperimentazione e collaudo,

verranno riesaminate le specifiche del sistema realizzato nella fase 1, e saranno apportate le

conseguenti modifiche sia al sistema di gestione dei metadati, sia alle procedure relative al data

warehouse di primo livello. Tali modifiche saranno opportunamente integrate con quanto già

realizzato.

8.2.2 Attività 2.2 Individuazione delle nuove tematiche di interesse

Alla luce dei suggerimenti forniti dal committente, verranno individuate ulteriori aree tematiche

di interesse del committente, e le relative fonti informative. Si assume che una parte

considerevole delle fonti considerate nella seconda fase non sia disponibile su supporti

informatici.

75

Il censimento di tali fonti porterà naturalmente ad una estensione dei contenuti della base dei

metadati, nonché ad un eventuale arricchimento delle funzionalità di interrogazione previste.

8.2.3 Attività 2.3 Progettazione

Per le fonti individuate nell'attività 2.2 verranno progettate le procedure di caricamento del data

warehouse di primo livello, e in base alle tematiche definite nell'attività 2.2 saranno progettati i

data warehouse di secondo livello (data mart) e le relative interfacce, sia verso strumenti di

analisi, sia verso utenti finali.

8.2.4 Attività 2.4 Realizzazione (dati, metadati e data mart)

Prevede il caricamento di metadati e dati relativi alle fonti individuate nell'attività 2.2. Come

già indicato nell'attività 2.2, si assume che una parte considerevole di tali fonti possano non

essere disponibile su supporti informatici.

Verranno inoltre realizzate le interfacce previste verso i data mart.

8.3 Fase 3: Estensione del data warehouse di secondo livello

La fase 3 ricalca le attività 2.2, 2.3, e 2.4, portando ad un ulteriore arricchimento delle basi dei

dati e dei metadati a fronte della indicazione di ulteriori tematiche di interesse da parte del

committente.

8.4 Riepilogo delle attività

Si mostra, nel seguito, il riepilogo delle attività relativi alle tre fasi descritte nelle sezioni

precedenti, indicando una stima dell'impegno necessario per la loro attuazione (espressa in

giorni uomo) nonché una ipotesi di durata temporale delle stesse.

76

Riferimento Attività Impegno

(giorni*persona)

Durata

(mesi)

Fase 1: Realizzazione del data warehouse di primo livello

Formalizzazione delle specifiche utente 30 1.1

Analisi delle fonti informative 30 3

Progettazione della base di dati dei metadati e relativa

interfaccia utente 15

Progettazione del data warehouse di primo livello 25 1.2

Progettazione delle procedure di caricamento dei dati 20

2

Realizzazione dei moduli di caricamento e consultazione

dei metadati 30

1.3

Caricamento dei metadati 20

2

Realizzazione dei moduli di caricamento e consultazione

dei dati 20

1.4

Caricamento dei dati 100

2

1.5 Sperimentazione, messa a punto e collaudo 15 3

Totale fase 1 305 12

77

Fase 2: Realizzazione del data warehouse di secondo livello

Estensione dei requisiti e formalizzazione delle nuove

specifiche utente 5

2.1 Integrazione delle nuove specifiche nei sistemi realizzati

durante la fase 1. 20

2

Definizione delle ulteriori aree tematiche di interesse 15

2.2 Analisi delle ulteriori fonti informative per le aree

tematiche di interesse 15

2

Progettazione delle procedure di caricamento delle nuove

fonti 10

Progettazione dei data mart 50 2.3

Progettazione delle interfacce verso i data mart 20

2

Caricamento dei metadati delle nuove fonti 10

Realizzazione delle procedure di caricamento dei dati delle

nuove fonti 20

Caricamento dei dati delle nuove fonti 100

2.4

Realizzazione delle interfacce verso i data mart 10

4

Totale fase 2 275 10

78

Fase 3: Estensione del data warehouse di secondo livello

Definizione delle ulteriori aree tematiche di interesse 15

3.1 Analisi delle ulteriori fonti informative per le aree

tematiche di interesse 15

2

Progettazione delle procedure di caricamento delle nuove

fonti 10

Progettazione dei data mart 50 3.2

Progettazione delle interfacce verso i data mart 20

2

Caricamento dei metadati delle nuove fonti 10

Realizzazione delle procedure di caricamento dei dati delle

nuove fonti 20

Caricamento dei dati delle nuove fonti 100

3.3

Realizzazione delle interfacce verso i data mart 10

4

Totale fase 3 255 8

8.5 Gantt

Si mostra, nel seguito, il Gantt del progetto con la relativa indicazione dei vari deliverable, dettagliati nel

seguto. Per comodità espositiva si è assunto che il progetto inizi il 1/1/2002.

ID Task Name Start End Duration2003 2004

AugOctMar Sep NovJun JanJul Jun JulFebAug MayJan AprOct FebNovJan Mar MarSep MayDec

1 90d3/31/2002

1/1/20021.1.a Formalizzazione delle specifiche utente

2 90d3/31/2002

1/1/200211.b Analisi delle fonti informative

4 61d5/31/2002

4/1/2002

1.2.a Progettazione del data base dei metadati e relativa interfacciautente

5 61d5/31/2002

4/1/20021.2.b Progettazione del data warehouse di primo livello

6 61d5/31/2002

4/1/20021.2.c Progettazione delle procedure di caricamento dei dati

8 61d7/31/2002

6/1/2002

1.3.a Realizzazione dei moduli di caricamento e consultazione deimetadati

9 61d7/31/2002

6/1/20021.3.b Caricamento dei metadati

11 61d9/30/2002

8/1/20021.4.a Realizzazione dei moduli di caricamento e consultazione dei dati

12 61d9/30/2002

8/1/2002

1.4.b Caricamento dei dati

14 92d12/31/2002

10/1/20021.5 Sperimentazione, messa a punto e collaudo

15 59d2/28/2003

1/1/2003

2.1.a Estensione dei requisiti e formalizzazione delle nuove specificheutente

16 59d2/28/2003

1/1/2003

2.1.b Estensione dei requisiti e formalizzazione delle nuove specificheutente

17 61d4/30/2003

3/1/20032.2a Definizione delle ulteriori aree tematiche di interesse

18 61d4/30/2003

3/1/2003

2.2b Analisi delle ulteriori fonti informative per le aree tematiche diinteresse

19 61d6/30/2003

5/1/20032.3a Progettazione delle procedure di caricamento delle nuove fonti

20 61d6/30/2003

5/1/2003

2.3b Progettazione dei data mart

21 61d6/30/2003

5/1/20032.3c Progettazione delle interfacce verso i data mart

23 123d10/31/2003

7/1/20032.4a Caricamento dei metadati delle nuove fonti

24 123d10/31/2003

7/1/2003

2.4b Realizzazione delle procedure di caricamento dei dati delle nuovefonti

25 123d10/31/2003

7/1/20032.4c Caricamento dei dati delle nuove fonti

26 123d10/31/2003

7/1/20032.4d Realizzazione delle interfacce verso i data mart

3 0d3/31/2002

3/31/2002

D1 Specifiche utente e descrizione delle sorgenti informativeselezionate.

7 0d5/31/2002

5/31/2002

D2 Architettura del sistema (gestione dei metadati e datawarehouse)Descrizione delle procedure di caricamento dei dati per lefon

10 0d7/31/2002

7/31/2002

D3 Moduli di caricamento e interrogazione della base deimetadati.Documentazione del popolamento della base dei metadati.

13 0d10/1/2002

10/1/2002

D4 Moduli di caricamento e interrogazione del data warehouse di primolivello per le fonti selezionate. Documentazione del popolamento deldata base.

22 0d6/30/2003

6/30/2003

D6 Descrizione delle procedure di caricamento dei dati per le ulteriorifonti. Descrizione dei data mart e delle relative interfacce.

27 0d11/1/2003

11/1/2003

D7 Moduli di caricamento e interrogazione del data warehouse di primolivello per le ulteriori fonti.Documentazione del popolamento della basedei metadati.Documentazione del popolamento del data base.Moduli diinterfaccia per i data mar

2002

Apr AprFeb JunDecMay

28

29

30

32

31

33

61d12/31/2003

11/1/20033.1a Definizione delle ulteriori aree tematiche di interesse

61d12/31/2003

11/1/2003

3.1b Analisi delle ulteriori fonti informative per le aree tematiche diinteresse

59d2/28/2004

1/1/20043.2a Progettazione delle procedure di caricamento delle nuove fonti

59d2/28/2004

1/1/2004

3.2b Progettazione dei data mart

59d2/28/2004

1/1/20043.2c Progettazione delle interfacce verso i data mart

0d2/28/2004

2/28/2004

D8 Descrizione delle procedure di caricamento dei dati per le ulteriorifonti. Descrizione dei data mart e delle relative inter

34

35

36

37

38 0d6/30/2004

6/30/2004

D9 Moduli di caricamento e interrogazione del data warehouse di primolivello per le ulteriori fonti.Documentazione del popolamento della basedei metadati.Documentazione del popolamento del data base.Moduli diinterfaccia per i data mart

123d6/30/2004

2/29/20043.3a Caricamento dei metadati delle nuove fonti

123d6/30/2004

2/29/2004

3.3b Realizzazione delle procedure di caricamento dei dati delle nuovefonti

123d6/30/2004

2/29/20043.3c Caricamento dei dati delle nuove fonti

123d6/30/2004

2/29/20043.3d Realizzazione delle interfacce verso i data mart

80

8.6 Elenco dei deliverable

Deliv Tipo Descrizione Attività

D1 Rapporto Specifiche utente e descrizione delle sorgenti informative

selezionate. 1.1

D2 Rapporto

Architettura del sistema (gestione dei metadati e data warehouse)

Descrizione delle procedure di caricamento dei dati per le fonti

selezionate.

1.2

D3 Software e

documentazione

Moduli di caricamento e interrogazione della base dei metadati.

Documentazione del popolamento della base dei metadati. 1.3

D4 Software e

documentazione

Moduli di caricamento e interrogazione del data warehouse di

primo livello per le fonti selezionate. Documentazione del

popolamento della base di dati.

1.4

D5 Software e

documentazione

Integrazione nei sistemi realizzati nella fase 1 delle ulteriori

specifiche scaturite dalla attività di sperimentazione e collaudo 2.1

D6 Rapporto

Descrizione delle procedure di caricamento dei dati per le

ulteriori fonti. Descrizione dei data mart e delle relative

interfacce.

2.3

D7 Software e

documentazione


primo livello per le ulteriori fonti.

Documentazione del popolamento della base dei metadati.

Documentazione del popolamento della base di dati.

Moduli di interfaccia per i data mart

2.4

D8 Rapporto

Descrizione delle procedure di caricamento dei dati per le

ulteriori fonti.

Descrizione dei data mart e delle relative interfacce.

3.2

D9 Software e

documentazione


primo livello per le ulteriori fonti.

Documentazione del popolamento della base dei metadati.

Documentazione del popolamento della base di dati.

Moduli di interfaccia per i data mart

3.3

81

8.7 Gruppo di lavoro

Progetti di tale complessità necessitano di gruppi di lavoro ampi e strutturati ma soprattutto un

pesante coinvolgimento delle strutture decisionali della Regione coinvolte nel processo. Si ha così

bisogno delle seguenti figure:

? ? Responsabile di progetto

? ? Progettista delle basi dati e del data warehouse

? ? Progettista Statistico per la modellizzazione

? ? Le persone dell’Area Statistica nonché quelle del Settore Sociale coinvolte

nell’automazione nel ruolo di utenti; all’interno di esse si identifica il coordinatore degli

utenti

? ? Responsabile informatico della Regione Lazio

? ? Analisti e programmatori con competenze ed in numero variabile a seconda della fase di

progetto

Alcune di queste figure possono essere eventualmente riunite in un’unica persona, l’importante è

che i soggetti interessati della Regione Lazio siano coinvolti in maniera fattiva e rimangano

protagonisti della realizzazione dell’intero sistema.

82

9 Appendice A: Elenco delle fonti informative analizzate

Si riporta, nel seguito, l'elenco delle sorgenti informative analizzate. Il significato dei campi è

descritto nella sezione 5.1 e sintetizzato nella tabella mostrata in sezione 5.3.1 relativa agli attributi

dell'entità Sorgente.

ID 53

Classe Amm. Regione Lazio

Titolo Erogazione contributi per il restauro e la

disinfestazione dei beni librari di pregio Oggetto

Detentore Regione Lazio

Responsabile

Telefono responsabile

E-mail responsabile

Vincoli sull'accesso ai dati Consenso del responsabile

Dati acquisiti ogni

Periodo di riferimento 01/01/1999 - 31/12/1999

Profondità dello storico 01/01/1997

Minimo livello di aggregazione

geografica dei dati divulgati

comune


geografica dei dati divulgabili


temporale

Qualità alta

83

ID 56

Classe SISTAN

Titolo La presenza straniera in Italia:caratteristiche

demografiche Oggetto Permessi di soggiorno all'1.1.1999

Residenti stranieri all'1.1.1999 Nascite e matrimoni nel 1996

Detentore ISTAT

Responsabile


E-mail responsabile

Vincoli sull'accesso ai dati

Dati acquisiti ogni 1 anno





provincia




temporale

Qualità alta

84

ID 57

Classe SISTAN

Titolo Indagine statistico-epidemiologica sull'uso di

sostanze stupefacenti e psicotrope tra i giovani che

sostengono la visita di leva

Oggetto Indagine campionaria anonima su 34933 soggetti maschi

all'atto della visita di leva per uno studio di

prevalenza sul consumo di sostanze stupefacenti

associato ad un'analisi della condizione giovanile

sotto l'aspetto sociale-economico,demografico e

comportamentale.

Detentore Ministero della Difesa

Responsabile


E-mail responsabile


Dati acquisiti ogni occasionale





comune




temporale

Qualità alta

85

ID 58

Classe SISTAN

Titolo Attività delle strutture socio-riabilitative nel

settore tossicodipendenza

Oggetto Caratteristiche e attività delle strutture socio-

riabilitative che si occupano della cura e

riabilitazione dei soggetti con problemi di

tossicodipendenza, struttura del personale,

caratteristiche dell'utenza

Detentore Ministero della Sanità

Responsabile


E-mail responsabile







regione




temporale

Qualità alta

86

ID 59

Classe SISTAN

Titolo Utenza e attività delle strutture pubbliche e private

nel settore alcooldipendenza

Oggetto Caratteristiche e attività delle strutture pubbliche e

private che si occupano del trattamento e recupero dei

soggetti con problemi di alcoolismo, struttura del

personale, caratteristiche dell'utenza, trattamenti

erogati


Responsabile


E-mail responsabile







regione




temporale

Qualità alta

87

ID 60

Classe SISTAN

Titolo Trattamenti pensionistici

Oggetto

Detentore ISTAT

Responsabile


E-mail responsabile







provincia




temporale

Qualità alta

88

ID 61

Classe SISTAN

Titolo Le iniziative in campo socio-assistenziale dei Comuni

Oggetto

Detentore ISTAT

Responsabile


E-mail responsabile

Vincoli sull'accesso ai dati Consenso del detentore


Periodo di riferimento







temporale

Qualità alta

89

ID 62


Titolo Gestione anagrafe catalogatori di fondi librari

Oggetto Cultura, biblioteche, catalogatori


Responsabile


E-mail responsabile


Dati acquisiti ogni


Profondità dello storico






temporale

Qualità alta

90

ID 64


Titolo Gestione dell'anagrafe delle bibliotec

Oggetto Biblioteche, cultura, anagrafe


Responsabile


E-mail responsabile


Dati acquisiti ogni








temporale

Qualità alta

91

ID 65


Titolo Iscrizione all'albo degli istituti culturali di

interesse regionale

Oggetto Istituti culturali, cultura


Responsabile


E-mail responsabile


Dati acquisiti ogni








temporale

Qualità alta

92

ID 66


Titolo Valorizzazione dei beni storici e naturalistici della

Tuscia

Oggetto Cultura


Responsabile


E-mail responsabile


Dati acquisiti ogni








temporale

Qualità alta

93

ID 67


Titolo Gestione dell'albo regionale delle bande musicali

Oggetto Cultura, bande musicali


Responsabile


E-mail responsabile


Dati acquisiti ogni








temporale

Qualità alta

94

ID 70

Classe SISTAN

Titolo Sistema di indicatori socio-sanitari

Oggetto

Detentore ISTAT

Responsabile


E-mail responsabile







regione



regione


temporale

Qualità alta

95

ID 71

Classe SISTAN

Titolo Indicatori di integrazione sociale dei disabili

Oggetto

Detentore ISTAT

Responsabile


E-mail responsabile







regione



Azienda sanitaria locale


temporale

Qualità alta

96

ID 72

Classe SISTAN

Titolo Sistema informativo sull'handicap

Oggetto

Detentore ISTAT

Responsabile


E-mail responsabile







regione





temporale

Qualità alta

97

ID 74

Classe SISTAN

Titolo Presidi residenziali socio-assistenziali

Oggetto Assistenza sociale prestata da istituzioni pubbliche e

private mediante l'erogazione di servizi residenziali

socio-assistenziali

Detentore ISTAT

Responsabile


E-mail responsabile







regione



comune


temporale

Qualità alta

98

ID 75

Classe SISTAN

Titolo Interventi in campo socio-assistenziale dei comuni

Oggetto Analisi delle caratteristiche dei beneficiari di

servizi e caratteristiche dei servizi erogati

Detentore ISTAT

Responsabile


E-mail responsabile







regione



regione


temporale

Qualità alta

99

ID 78

Classe SISTAN

Titolo Utenza e attività dei servizi pubblici per la

tossicodipendenza (SERT)

Oggetto Numero e caratteristiche dei soggetti

tossicodipendenti utenti dei SERT,

trattamenti,struttura e attività del personale

preposto


Responsabile


E-mail responsabile







regione




temporale

Qualità alta

100

ID 79

Classe SISTAN

Titolo Attività delle strutture socio-riabilitative nel

settore della tossicodipendenza

Oggetto Caratteristiche organizzative ed attività delle

strutture socio-riabilitative, struttura del

personale, caratteristiche dell'utenza


Responsabile


E-mail responsabile











temporale

Qualità alta

101

ID 80

Classe SISTAN

Titolo Utenze e attività delle strutture pubbliche e private

nel settore alcoldipendenza

Oggetto Caratt.strutt. e attività delle strutt. pubbliche e

private, caratteristiche dell'utenza e trattamento


Responsabile


E-mail responsabile










temporale

Qualità alta

102

ID 81

Classe SISTAN

Titolo Indagine multiscopo sulle famiglie: i cittadini e

l'ambiente nelle grandi città

Oggetto

Detentore ISTAT

Responsabile


E-mail responsabile







regione




temporale

Qualità alta

103

ID 82

Classe SISTAN

Titolo Popolazione e movimento anagrafico dei comuni

Oggetto

Detentore ISTAT

Responsabile


E-mail responsabile







comune




temporale

Qualità alta

104

ID 83

Classe SISTAN

Titolo La situazione economica e finanziaria delle famiglie

in Europa

Oggetto

Detentore ISTAT

Responsabile


E-mail responsabile







nazione




temporale

Qualità alta

105

ID 84


Titolo Promozione del turismo sociale nel Lazio

Oggetto


Responsabile


E-mail responsabile


Dati acquisiti ogni








temporale

Qualità alta

106

ID 85


Titolo Vigilanza sulle importazioni temporanee di fondi

librari antichi e moderni

Oggetto Cultura Libri


Responsabile


E-mail responsabile


Dati acquisiti ogni








temporale

Qualità alta

107

ID 86


Titolo Vigilanza sulle esportazioni di fondi librari antichi

e moderni

Oggetto Cultura Libri


Responsabile


E-mail responsabile


Dati acquisiti ogni








temporale

Qualità alta

108

ID 87

Classe SISTAN

Titolo Censimento delle strutture socio-riabilitative

Oggetto Strutture socio-riabilitative (residenziali,

semiresidenziali, ambulatoriali)

Detentore Ministero dell'interno

Responsabile


E-mail responsabile







provincia



provincia


temporale

Qualità alta

109

ID 89

Classe SISTAN

Titolo Compendio delle statistiche ufficiali

dell'amministrazione dell'interno

Oggetto

Detentore Ministero dell'Interno

Responsabile


E-mail responsabile







regione



comune


temporale

Qualità alta

110

ID 91

Classe SISTAN

Titolo Annuario statistico

Oggetto Indicatori comparativi tra i comuni dei Castelli

Romani nel contesto nazionale.

Detentore Comune di Albano Laziale

Responsabile


E-mail responsabile







comune




temporale

Qualità alta

111

ID 92

Classe SISTAN

Titolo Roma e provincia attraverso la statistica

Oggetto

Detentore Camera di Commercio Industria Artigianato ed agr

Responsabile


E-mail responsabile







comune




temporale

Qualità alta

112

ID 93

Classe SISTAN

Titolo I consumi delle famiglie

Oggetto Condizioni di vita delle famiglie italiane in termini

di spesa, condizione abitativa, possesso dei beni

durevoli etc.

Detentore ISTAT

Responsabile


E-mail responsabile










temporale

Qualità

113

ID 94

Classe SISTAN

Titolo Famiglie, abitazioni e sicurezza dei cittadini

Oggetto

Detentore ISTAT

Responsabile


E-mail responsabile










temporale

Qualità alta

114

ID 96


Titolo Gestione anagrafe catalogatori di fondi librari

Oggetto


Responsabile


E-mail responsabile


Dati acquisiti ogni








temporale

Qualità alta

115

ID 97

Classe SISTAN

Titolo Problematiche ed iniziative inerenti la popolazione

anziana in Italia

Oggetto Strutture residenziali e non;Centri studio e/o

università; iniziative a favore degli anziani


Responsabile


E-mail responsabile







comune




temporale

Qualità alta

116

ID 98

Classe SISTAN

Titolo Censimento delle strutture di accoglienza per

extracomunitari

Oggetto Strutture di accoglienza per extracomunitari


Responsabile


E-mail responsabile







comune




temporale

Qualità alta

117

10 Allegato A : Il prototipo "Catalogo Sorgenti"

Parte integrante di questo documento è il software denominato "Catalogo Sorgenti" descritto nella

sezione 6. Tale software è incluso nel CD-Rom allegato.

Studio di fattibilità per la realizzazione del sistema ... · Rapporto finale Schede di...

Documents

Transcript of Studio di fattibilità per la realizzazione del sistema ... · Rapporto finale Schede di...