Documento Inquadramento Generale del Database Geografico Provinciale

Provincia Autonoma di Trento
Data Base Geografico della Provincia Autonoma di Trento
Inquadramento del sistema DBGP
Versione 1.0
16 aprile 2013
Emesso da: Segreteria SIAT

2/47
Revisioni
Data Rev Contenuto revisione Autore
16/04/2013 1.0 Stesura definitiva Segreteria SIAT
Sommario
1.0 AMBITO...................................................................................................................6
2.0 MACROREQUISITI....................................................................................................6
2.1 Fase “ad interim” del progetto ....................................................................................6
2.2 Aggiornamento da parte delle stazioni.........................................................................6
2.3 Stazioni con sistemi legacy .........................................................................................7
2.4 Storicità del DB centrale.............................................................................................7
2.5 Storicità dei DB locali .................................................................................................8
2.6 Validazione delle specifiche di contenuto concettuali.....................................................8
2.7 Gestione delle modifiche alle specifiche di contenuto concettuali....................................8
2.8 Separazione ambiente di gestione e di fruizione ...........................................................8
2.9 Utilizzo della piattaforma DB PostGRESQL/PostGIS .......................................................8
2.10 Riutilizzo degli strumenti GIS ESRI ..............................................................................8
2.11 Compatibilità software di stazione con strumenti GIS open source .................................9
2.12 Serializzazione delle validazioni centrali .......................................................................9
2.13 Gestione di uno “stato” del dato .................................................................................9
2.14 Competenza dell’aggiornamento .................................................................................9
2.15 DB centrale è “master”...............................................................................................9
2.16 Architettura estendibile a “comuni” o “comunità di valle” come aggiornatori (soggetti
esterni) ............................................................................................................................ 10
3.0 ARCHITETTURA ..................................................................................................... 10
3.1 Il GeoUML Catalogue e Validator............................................................................... 12
3.1.1 Il modello fisico prodotto dal Catalogue .............................................................. 13
3.1.2 L’evoluzione tecnologica del Validator ................................................................. 14
3.1.3 Prestazioni della validazione............................................................................... 14
3.2 Il database centrale di gestione ................................................................................ 15
3.2.1 popolamento .................................................................................................... 15
3.3 ETL ........................................................................................................................ 15
3.4 La validazione ......................................................................................................... 16
3.5 Il sistema di fruizione............................................................................................... 17
3.6 I sistemi locali ......................................................................................................... 19
3.6.1 Architettura di una generica stazione PAT sprovvista di sistema verticale ............... 19

3/47
3.6.2 Architettura di una stazione PAT con preesistente sistema verticale....................... 22
4.0 FLUSSI.................................................................................................................. 23
4.1 Aggiornamento da una stazione PAT sprovvista di base di dati strutturata.................... 23
4.1.1 Componenti necessari per l'invio di un aggiornamento da una stazione sprovvista di
base di dati strutturata ................................................................................................... 26
4.2 Aggiornamento da una stazione PAT con base di dati già strutturata............................ 27
4.2.1 Componenti necessari per l'invio di un aggiornamento da una stazione con base di
dati già strutturata ......................................................................................................... 28
4.3 Flusso di recepimento dell'aggiornamento nel database provinciale.............................. 29
4.3.1 Componenti necessari per il recepimento di un aggiornamento da parte del sistema
informativo provinciale ................................................................................................... 31
4.3.2 Componenti e flusso di simulazione di un aggiornamento ..................................... 32
5.0 FASE SPERIMENTALE ............................................................................................. 35
5.1 Considerazioni comuni ............................................................................................. 35
5.1.1 Validazione locale.............................................................................................. 35
5.1.2 Flag di pubblicazione........................................................................................ 35
5.1.3 Pubblicazione con richiesta esplicita della stazione ............................................... 36
5.1.4 Pubblicazione ultimo stadio oggetti..................................................................... 36
5.1.5 Peculiarità supporto tipi di dato.......................................................................... 41
5.1.6 Sintesi degli artefatti GeoUML ............................................................................ 41
5.2 Bacini Montani......................................................................................................... 42
5.2.1 Situazione attuale ............................................................................................. 42
5.2.2 Modello del database......................................................................................... 43
5.2.3 Storicizzazione.................................................................................................. 44
5.2.1 Pubblicazione.................................................................................................... 44
5.3 Agenzia Provinciale Risorse Idriche ed Energetiche..................................................... 45
5.3.1 Situazione attuale ............................................................................................. 45
5.3.2 Modello del database......................................................................................... 45
5.3.3 Relazioni entità esterne alla stazione .................................................................. 46
5.3.4 Attributi multivalore .......................................................................................... 46
5.3.5 Storicità ........................................................................................................... 47
5.3.6 Pubblicazione.................................................................................................... 47
5.3.7 Differenza tra schema fisico di validazione e schema fisico di gestione................... 47
Indice delle figure
Figura 1 - Macro architettura del sistema................................................................................ 10
Figura 2 - Elenco Stazioni principali ........................................................................................ 11

4/47
Figura 3 - Relazione tra GeoUML Catalogue e Validator............................................................ 12
Figura 4 - Datamart dipendenti.............................................................................................. 18
Figura 5 - Datamart indipendenti ........................................................................................... 18
Figura 6 - Modello ibrido ....................................................................................................... 18
Figura 7 - Eventuale sistema di fruizione locale ....................................................................... 19
Figura 8 - Sistema di stazione senza sistema verticale preesistente........................................... 21
Figura 9 - Sistema di stazione con sistema verticale preesistente .............................................. 22
Figura 11 - Flusso di aggiornamento ........................................................................................1
Figura 12 - Flusso per la simulazione di aggiornamento (caso di DB legacy).................................1
Figura 13 - Applicazione dell'aggiornamento sul DBGP ...............................................................1
Figura 14 - Il servizio di simulazione aggiornamento..................................................................1
Acronimi e terminologia
Data Product = termine introdotto dagli standard ISO 19100 per indicare una raccolta
organizzata e coerente di informazioni territoriali. Un Data Product può
essere ad esempio costituito da un insieme di file o da un database.
GeoUML = modello utilizzato per la definizione dello Schema Concettuale di una
Specifica di Contenuto
GeoUML Validator = (o Validator) strumento software che esegue il controllo di conformità
di un Dataset o DataBase rispetto a una Specifica (Schema
Concettuale) prodotta dal GeoUML Catalogue.
GeoUML Catalogue = (o Catalogue) strumento software che permette la definizione di una
Specifica di Contenuto e la definizione di parametri per la
generazione di schemi fisici basati sui modelli implementativi.
DBMS DataBase Management System
DBGP Data Base Geografico Provinciale
DBGS Data Base Geografico di Stazione
DM Data Mart
DWH Data Warehouse
ESF Extended Simple Feature
ETL Extract, Transform and Load
PAT Provincia Autonoma di Trento
SIAT Sistema Informativo Ambientale e Territoriale della Provincia di
Trento
SLA Service Level Agreement

5/47
Modello concettuale = v. Schema Concettuale o Specifica di Contenuto
Modello implementativo = insieme di regole che permettono di generare automaticamente uno
Schema e un Mapping Fisico da una Specifica Concettuale
Schema concettuale = componente strutturata di una Specifica di Contenuto.
Shapefile Flat = particolare modello implementativo basato su semplici shapefile.
L’attributo “flat” è per sottolineare la differenza con il modello
implementativo Shapefile Topologico.
Specifiche di Contenuto = costituisce una definizione dei contenuti che un Data Product deve
possedere per essere conforme alla specifica stessa. Questa a
definizione è composta da una parte strutturata (elementi informativi e
vincoli di integrità) e una parte non strutturata (elementi descrittivi).
Stazione SIAT = con il termine “Stazione” si intende propriamente una specifica
struttura organizzativa della Provincia Autonoma di Trento che afferisce
ad un Dipartimento. Nel contesto di questo documento estendiamo
leggermente il significato del termine considerando “Stazione SIAT” (o
semplicemente Stazione) un qualsiasi ufficio o altra unità organizzativa
che produce dati territoriali e che quindi è soggetto attivo nel sistema
DBTP; rientrano in questa definizione quindi anche “servizi” o “agenzie”
o altri organi strumentali della Provincia.

6/47
1.0 AMBITO
Il presente documento ha lo scopo di descrivere l’impostazione architetturale del sistema del
DataBase Geografico Provinciale (DBGP) inteso come sistema informativo cartografico complesso
che permette di conservare, gestire e rendere disponibile per la fruizione un ampio dataset di
informazioni spaziali, noto appunto come database topografico. L’esatto contenuto di tale banca
dati è specificato a livello concettuale da un modello formalizzato in GeoUML1
attraverso l’utilizzo
dell’applicazione detta “GeoUML Catalogue” che rispecchia ed estende quanto previsto dalle
corrispondenti specifiche nazionali.
Il lavoro di modellazione è stato svolto2
con il diretto coinvolgimento delle Stazioni SIAT attraverso
una metodologia partecipativa che ha previsto:
• incontri sui singoli temi (Idrografia, Uso del suolo, Pianificazione, Viabilità, …) a livello di
Gruppi di Lavoro “Dati”;
• incontri di approfondimento presso le singole Stazioni;
• raccolta commenti e osservazioni.
Ripetiamo qui questo aspetto metodologico per evidenziare che il DBGP nasce per contenere tutte
quelle informazioni prodotte dalle Stazioni che hanno una valenza trasversale ovvero che sono
state reputate utili per tutti e che quindi è necessario conservare e pubblicare in maniera
centralizzata.
Come vedremo meglio in seguito, i macro-requisiti, elencati nel capitolo 2.0, richiedono per la loro
soddisfazione un sistema complesso e distribuito, dove sono previsti componenti a livello periferico
(stazioni) e a livello centrale, con flussi informativi di gestione centripeti, e flussi di fruizione verso
la periferia.
Il sistema sarà quindi macroscopicamente separabile in due sottosistemi: quello di gestione e
quello di fruizione. Entrambi saranno oggetto di questo documento che prevederà anche la
trattazione di una fase di sperimentazione (cfr. § 5.0) limitatamente alla sola componente di
gestione del dato.
2.0 MACROREQUISITI
2.1 Fase “ad interim” del progetto
Il progetto DBGP per alcune caratteristiche di complessità intrinseche e a causa di situazioni
esterne e contingenti, verrà necessariamente avviato in produzione passando attraverso un fase
temporanea che potrà durare anche a lungo. E’ necessario prevedere quindi azioni specifiche per
la fase ad interim.
2.2 Aggiornamento da parte delle stazioni
Il contenuto del DBGP è suddivisibile in partizioni su cui la competenza dell’aggiornamento ricade
su una singola stazione. In alcuni, pochi, casi il partizionamento non è rigoroso e potrebbero
1
Cfr. SIAT_relazioneFinale_AllegatoB_PAT_2012-02-24__v1.0
2
Cfr. SIAT_relazioneFinale

7/47
verificarsi competenze sovrapposte sulle medesime informazioni. Tali situazioni vanno intese come
eccezioni e sono da cercare da ricondurre allo scenario di competenza separata verificando
eventuali modifiche al modello.
2.3 Stazioni con sistemi legacy
Alcune stazioni (idrografia e agricoltura) sono già dotate di una base dati strutturata e di un
sistema verticale che consente la gestione dei propri dati ed eroga in generale tutte le funzionalità
necessarie alla stazione. Questi sistemi vanno preservati ed integrati nell’architettura del DBGP.
2.4 Storicità del DB centrale
Il DBGP deve mantenere la profondità storica degli oggetti che gestisce. In altre parole ogni
oggetto avrà un ben noto ciclo di vita che ne determinerà le regole di cessazione e di modifica. Ad
ogni modifica corrisponderà quindi un’istanza3
diversa dello stesso oggetto, istanze che
manterranno l’identità dell’oggetto originale, ma saranno caratterizzate da valori differenti degli
attributi, geometrici o alfanumerici che siano.
Lo schema concettuale del DBGP prevede la classe “Metadato di istanza” che contiene anche
attributi relativi al ciclo di vita dell’oggetto che dovrebbero essere sufficienti per una gestione
minimale della storicità.
90010102 DATAMOD data modifica Date
90010103 DATAINI data inizio validità Date
90010104 DATAFINE data fine validità [0..1] Date
Tabella 1 - I metadati di istanza relativi al ciclo di vita previsti dalla specifica concettuale
Si è definito il popolamento delle date sopra elencate in tal modo:
• DATAMOD - contiene la data di ultimo aggiornamento del dato. Per le istanze attive il
valore inserito corrisponde alla data in cui una stazione ha inviato gli aggiornamenti mentre
per le istanze storicizzate il valore corrisponde alla data in cui una stazione ha inviato un
aggiornamento che ha storicizzato l'istanza (andando a modificare la DATAFINE).
• DATAINI - contiene la data di inizio di validità dell'istanza. Questa data non deve essere
confusa con la data di inizio di validità dell'oggetto ma identifica la data dalla quale gli
attributi dell'oggetto assumono i valori indicati nella tupla
• DATAFINE - contiene la data di fine di validità dell'istanza, l'oggetto potrebbe ancora
esistere (con un nuova istanza la cui DATAINI è coincidente con la DATAFINE di questa
istanza). Nel caso in cui questa data non sia valorizzata implica che si tratta dell'stanza
attualmente valida
3
Nel seguito si useranno proprio questi termini “istanza” e “oggetto” per identificare rispettivamente lo
stadio di un’entità valido in un certo periodo temporale e l’entità stessa intesa come elemento individuale che
subisce delle modifiche nel tempo, ma che mantiene la capacità di essere identificato e riconosciuto come
quel determinato elemento.

8/47
2.5 Storicità dei DB locali
La gestione della storicità dei DB locali può essere differente da stazione a stazione e da quella del
DB centrale. Devono però essere esplicitate le regole di gestione richieste per la valorizzazione
delle date e per l'estrazione dell'aggiornamento; tali procedure potrebbero variare da stazione a
stazione.
2.6 Validazione delle specifiche di contenuto concettuali
E’ importante sia nella fase transitoria che in quella a regime che i dati possano essere validati
rispetto le specifiche di contenuto concettuali. La grande massa di dati che deve essere integrata
nel DBGP necessita infatti del processo di validazione se si vuole raggiungere il livello di qualità
elevato che implicano le relative specifiche. Il processo di validazione è essenziale anche in
aggiornamento per mantenere elevate le accuratezze tematica e posizionale degli oggetti gestiti.
2.7 Gestione delle modifiche alle specifiche di contenuto concettuali
La validazione deve essere legata il più possibile alle specifiche di contenuto concettuali perché è
scontato che esse si modifichino nel tempo: in altre parole, al variare delle specifiche occorre
evitare di dover modificare manualmente il codice che effettua la validazione. La modellazione
delle specifiche di contenuto concettuali è stata fatta attraverso il software GeoUML Catalogue che
ha dimostrato di essere uno strumento adatto alla formalizzazione, alla gestione delle variazioni nel
tempo e alla conversione finale nel modello fisico implementativo.
2.8 Separazione ambiente di gestione e di fruizione
I requisiti di performance, di affidabilità e di disponibilità delle funzioni di gestione e di fruizione
considerate assieme alla differente natura degli utilizzatori (intranet per le prime, internet per le
ultime) fanno sì che necessariamente si debbano prevedere due ambienti separati.
2.9 Utilizzo della piattaforma DB PostGRESQL/PostGIS
Benchmark prestazionali4
su funzionalità legate ai dati geografici hanno evidenziato come PostGIS
si comporti meglio rispetto Oracle. Queste considerazioni e altre legate al costo delle licenze in un
sistema che potenzialmente prevede il dispiegamento di molte istanze di DBMS, indirizzano alla
scelta di PostGRESQL/PostGIS come Spatial DBMS del sistema DBGP.
2.10 Riutilizzo degli strumenti GIS ESRI
Molte stazioni sono dotate di strumenti GIS della suite ESRI; è importante che esse continuino ad
utilizzare questo software per non sprecare gli investimenti già fatti in termini di licenze e
formazione degli operatori. Particolare attenzione deve essere posta su quello che può comportare
il mix di tecnologie: ad esempio, il DB PostGIS abbinato a strumenti desktop ESRI può richiedere
un livello di licenza superiore (da ArcMap ad ArcEditor).
4
Tale sperimentazione è stata fatta con i dati dell’idrologia, all’interno della Stazione Bacini Montani.

9/47
2.11 Compatibilità software di stazione con strumenti GIS open source
E’ importante che il sistema di stazione sia compatibile con strumenti GIS open source: il formati di
memorizzazione dei dati, ad esempio, non dovranno essere proprietari così come gli eventuali
protocolli dei servizi di rete.
2.12 Serializzazione delle validazioni centrali
Considerando la frequenza di aggiornamento plausibile del DBGP e il fatto che ogni dataset
conferito sarà elaborato in maniera asincrona, si ritiene che i processi di validazione centrale
possano essere elaborati sequenzialmente senza inficiare la funzionalità del sistema.
2.13 Gestione di uno “stato” del dato
Sia a livello locale che a livello centrale potrebbe essere necessario gestire il concetto di stato di un
dato.
Al livello locale lo stato di un dato è utile per consentire l’introduzione di dati che non sono ancora
da pubblicare, ma sono necessari alla stazione stessa.
A livello centrale lo stato assume un’altra accezione: l’esito della validazione per quel particolare
oggetto potrebbe essere riassunto in questa informazione.
Lo stato del dato, seppur ritenuto importante, non sarà oggetto della prima sperimentazione.
2.14 Competenza dell’aggiornamento
L’aggiornamento di ogni dato è di competenza di una singola stazione. Nel caso in cui si dovessero
rilevare dati con competenza di aggiornamento condivisa si dovranno esaminare caso per caso. Il
flusso in tali casi, se possibile5
, dovrebbe essere interpretato come esterno al DBGP; se così non
fosse si dovranno definire delle apposite procedure di controllo, riallineamento e segnalazione che
permettano un aggiornamento condiviso dei dati tra diverse stazioni.
2.15 DB centrale è “master”
La copia master dei dati, in linea di principio, risiede nel DBGP. È necessario evidenziare che i dati
presenti nel database provinciale rappresentano solo un sottoinsieme della somma dei dati
presenti in tutte le stazioni. Nelle stazioni sono infatti presenti degli attributi locali non inviati nel
database centrale, ma, soprattutto, possono essere presenti molte più istanze di variazione per
ogni oggetto presente nel database locale; questa disparità numerica è data dalle decisioni relative
all'invio degli aggiornamenti durante i quali, nel caso un oggetto subisca aggiornamenti multipli,
viene trasferita a livello centrale solo l'ultima istanza aggiornata.
5
Ad un dataset corrisponde di solito un solo proprietario o gestore; situazioni diverse comporterebbero delle
anomalie anche dal punto di vista organizzativo dell’Ente. E’ possibile però che emergano situazioni del
genere, ma esse molto probabilmente possono essere frutto di una modellazione dei dati non appropriata
dove oggetti differenti vengono ad esempio fatti ricadere nella medesima entità del modello o dove i flussi
informativi rispecchiano situazioni provvisorie.

10/47
2.16 Architettura estendibile a “comuni” o “comunità di valle” come
aggiornatori (soggetti esterni)
Alcune informazioni previste nel DBGP sono generate presso attori esterni la Provincia come i
Comuni o le Comunità di Valle. Ad esempio, la numerazione civica è un dato tipicamente gestito a
livello locale. L’architettura del sistema dovrà facilmente poter essere estesa in tal senso, in termini
di funzionalità e, soprattutto, per gli aspetti relativi alla sicurezza.
3.0 ARCHITETTURA
L’architettura del sistema complessivamente è rappresentata dalla Figura 1; in questo schema ad
alto livello si può notare da subito la separazione del sottosistema di gestione da quello di
fruizione. Il collegamento è rappresentato dai processi di ETL che creano un flusso
monodirezionale dal DB centrale di gestione (DBGP) verso i data mart (DM) di fruizione. Questi
data mart rappresentano DB il cui modello dati e la natura tecnologica possono essere anche molto
differenti: possiamo avere “ESRI file geodatabase” oppure Oracle Spatial o PostGIS. Saranno i
requisiti dei servizi di fruizione che essi supportano a determinarne la tipologia, compresi i requisiti
non funzionali che nell’ambito della fruizione sono molto importanti.
DBGS1 DBGS2 DBGSn
DBGP
DM1
DM2
DMm
Sistema
“verticale” di
stazione
Sistema
“verticale” di
stazione
Sistema
“verticale” di
stazione
Validazione
centrale
ETL fruizione
ETL gestione
ValidazionelocaleGestione
Fruizione
Figura 1 - Macro architettura del sistema
I database di stazione (DBGS) sono indicati con il loro sistema gestionale verticale corrispondente,
anche se al momento sono soltanto 2 le stazioni che ne sono dotate: le restanti gestiscono dati
non strutturati in veri e propri DBMS.

11/47
In questa architettura in cui i dati si trovano replicati localmente e centralmente, il DBGP gioca il
ruolo di database master, ovvero la versione ufficiale e validata dei dati è quella mantenuta
centralmente.
Elenchiamo per semplicità alcune delle Stazioni SIAT principali, inserite nella loro gerarchia di
Dipartimenti o Agenzie, di cui dovremo tener conto all’interno di questa analisi:
Figura 2 - Elenco Stazioni principali
* Stazione già dotata di un proprio sistema di gestione verticale.
** Ex-SUAP, Servizio Utilizzo Acque Pubbliche

12/47
3.1 Il GeoUML Catalogue e Validator
Considerando il fatto che per la definizione delle specifiche di contenuto del DBGP è stato utilizzato
il GeoUML Catalogue (o semplicemente Catalogue) e si ritiene che il componente collegato
GeoUML Validator (o semplicemente Validator) possa giocare un ruolo essenziale per il
miglioramento della qualità dei dati nella fase del loro assemblaggio in un unico database ed in
seguito durante la loro gestione, prima di passare alla descrizione dello schema architetturale di
Figura 1, occorre fare un breve premessa sulle caratteristiche di queste componenti.
Figura 3 - Relazione tra GeoUML Catalogue e Validator
Il Catalogue permette di formalizzare le specifiche concettuali di contenuto di un dataset
geografico codificandole opportunamente con l’utilizzo del linguaggio GeoUML. L’applicazione
consente di editare le specifiche, di consultarle, di produrre report leggibili dall’uomo ed infine di
esportare in un file XML (file SCS) tutto ciò che si è definito all’interno del catalogo (Data Product
Specification). Oltre ad esportare il file delle specifiche (il cui utilizzo principale, oltre alla
realizzazione dell’interscambio fra cataloghi, sarà descritto poco più avanti) il Catalogue consente
di ricavare il modello fisico per i dati modellati concettualmente, ovvero permette di creare il
database capace di ospitare i dati. Per la precisione, si può scegliere tra diverse tipologie di modelli
implementativi (MI):
• Modelli implementativi di trasferimento
o Shape flat;
o Shape topologico;
o ESF_GML6
• Modelli implementativi orientati al database
o Monogeometria;
6
ESF estende il modello Simple Feature essenzialmente aggiungendo il supporto ad alcune caratteristiche
3D; da qui il termine ESF_GML per indicare una codifica GML che supporti anche questa estensione.

13/47
Oracle
PostGIS
o Multigeometria
Oracle
La componente software che produce questi modelli implementativi è realizzata come plug-in del
modulo principale, per cui è possibile aggiungere altri modelli.
Il file SCS consente poi di configurare il GeoUML Validator affinché produca automaticamente tutte
le procedure software che consentono di effettuare le validazioni sui dati caricati in un modello
implementativo prodotto con le stesse specifiche. Anche la componente di lettura dei dati da un
particolare modello implementativo è realizzata all’interno del Validator come plug–in.
Si rimanda alla documentazione in linea7
per maggiori dettagli sul funzionamento di questi
componenti, mentre in Figura 3 è schematizzata a grandi linee la loro architettura.
Da sottolineare che l’output del Validator richiede una conoscenza del linguaggio GeoUML utilizzato
per la definizione dei vincoli e una piena comprensione del modello dati definito attraverso il
GeoUML Catalogue. Il software memorizza in un DB interno tutte le informazioni necessarie a
ricavare una qualsivoglia reportistica; vengono inoltre forniti alcuni strumenti esemplificativi per
generare report o comunque esplorare i risultati della validazione: uno di questi è costituito da un
plug-in del software GIS OpenJump8
e un altro è costituito da un paio di esempi di report
configurati in iReport9
.
3.1.1 IL MODELLO FISICO PRODOTTO DAL CATALOGUE
E’ importante sottolineare che il modello fisico prodotto dal GeoUML Catalogue è orientato alla
validazione e alla fruizione. Questo non significa che le DDL (Data Definition Language) o i
template degli shapefile o delle tabelle mdb (a seconda del modello implementativo scelto)
prodotti non possano essere utilizzate per la creazione di un DB di gestione, perché è proprio
questo l’obbiettivo che nel caso dei DBGS locali si vuole raggiungere; significa invece che occorre
aggiungere alcune strutture o modificare quelle prodotte dal Catalogue per ottenere alcune
caratteristiche necessarie o comode per un ambiente di gestione.
Le caratteristiche che comportano modifiche alle DDL sono in generale:
• Gestione della storicità;
• Semplificazione della gestione degli attributi multi-valore;
• Gestione delle geometrie derivate;
• Eccezioni sul supporto ai tipi di dato sia del DB sia degli strumenti di gestione10
(valori
booleani, nulli …)
• Gestione della pubblicazione (conferimento verso il DB centrale).
Possiamo quindi affermare che esisterà inevitabilmente un “gap” tra le DDL generate dal Catalogue
e le DDL che dovranno essere materialmente utilizzate per produrre il DB fisico di gestione, una
differenza che quindi dovrà essere gestita con particolare attenzione perché non legata
all’evoluzione del modello concettuale.
7
http://spatialdbgroup.polimi.it/documenti/
8
http://www.openjump.org/
9 http://community.jaspersoft.com/project/ireport-designer
10
Ad esempio, ArcGIS non gestisce il tipo boolean su PostGIS.

14/47
Anche per il DB centrale, che è di fruizione, avremo un certo “gap”, ma sarà limitato in generale al
supporto della storicità.
3.1.2 L’EVOLUZIONE TECNOLOGICA DEL VALIDATOR
Il GeoUML Validator è nato come applicativo stand alone le cui fasi di configurazione e validazione
devono essere invocate attraverso una GUI presentata ad un'utente. Essendo lo strumento
altamente interattivo ben si presta per effettuare delle validazioni locali alle stazioni, ma è
difficilmente integrabile in un workflow di simulazione o di aggiornamento.
Si è deciso quindi di eseguire delle modifiche al GeoUML Validator per permettere di richiamare
alcune funzionalità senza richiedere necessariamente la presenza di un operatore e al fine di poter
inserire il GeoUML Validator in un processo di valutazione automatica.
Lo sviluppo approvato mira a definire un insieme di interfacce e di beans Java che permettano di
invocare le funzionalità di validazione e di report in modo automatico al fine di integrare il GeoUML
Validator in un servizio web.
Il software risultante al termine dello sviluppo sarà rilasciato al CISIS/Politecnico (gestori del
progetto) in modo che le funzionalità sviluppate possano essere condivise con altre pubbliche
amministrazioni e che le evoluzioni/correzioni del software tengano conto dei nuovi sviluppi.
Il risultato del lavoro di sviluppo sarà una evoluzione del GeoUML Validator che sarà così invocabile
sia attraverso un'interfaccia grafica che con chiamate Java dirette.
Alcune funzionalità ritenute di valenza “una tantum”, quali l'importazione della specifica di
contenuto e la configurazione del GeoUML Validator, saranno accessibili solo attraverso l'interfaccia
grafica; mentre tutte le funzionalità di importazione, normalizzazione e validazione saranno gestibili
anche attraverso le interfacce Java. Attraverso quest'ultime sarà inoltre possibile modificare le
sorgenti dati relative da caricare, al database di caricamento e normalizzazione in modo da
permettere una maggior flessibilità in fase di validazione.
Altre configurazioni riguarderanno il numero di controlli concorrenti da effettuare (che sarà
modificabile anche a runtime) e la configurazione dei parametri metrici in modo che ogni stazione
possa eventualmente richiedere i propri parametri di validazione metrica.
3.1.3 PRESTAZIONI DELLA VALIDAZIONE
L'esecuzione del GeoUML Validator ha solitamente come collo di bottiglia la potenza del
processore; l'applicativo infatti esegue principalmente calcolo computazionale e tende a
sovraccaricare l'utilizzo della CPU prevalentemente sulla macchina su cui è installato il database di
normalizzazione (che può anche essere diversa da quella che esegue il GeoUML Validator).
In fase di dimensionamento dei sistemi sarà necessario considerare sempre questa criticità poiché
qualora si dovesse eseguire una validazione su una macchina nella quale sono presenti altri
processi in esecuzione potrebbero verificarsi dei forti rallentamenti o delle interruzioni, causa
mancanza di risorse, degli altri processi.
Si suggerisce quindi di dotarsi in una macchina dedicata all'esecuzione delle validazioni sulla quale
sarà installato il database di normalizzazione; questa macchina non ha necessità di virtualizzazioni
o recovery poiché si ritiene il processo di validazione come processo non business critical.

15/47
3.2 Il database centrale di gestione
La struttura del database centrale potrà, in prima istanza, essere derivata direttamente dal modello
implementativo PostGIS Monogeometria del GeouML Catalogue, utilizzando la specifica
provinciale definita in modo condiviso con le stazioni.
La struttura generata automaticamente deve essere considerata come target per la validazione11
quindi tutte le modifiche, le ottimizzazioni e le estensioni fatte devono sempre tener presente la
necessità di ricondursi alla struttura generata per sfruttare le potenzialità di validazione offerte dal
GeoUML Validator.
Prima di procedere alla modifica degli script DDL del DBGP è necessario identificare quali siano le
motivazioni che richiedono la modifica degli schemi; alcuni esempi:
1. creazione di uno schema rivolto alla gestione e non alla fruizione
2. storicizzazione dei dati
3. generazione per derivazione di alcune componenti geometriche12
4. requisiti imposti dai software di gestione e fruizione
5. performance e problematiche sistemistiche
L'elenco precedente potrebbe essere ulteriormente ampliato e ogni punto richiede una discussione
e una decisione che inevitabilmente influenzerà gli schemi e la gestione dei dati.
Effettuata la fase di modifica degli schemi, per ricondursi alla configurazione che abilita la
validazione, dovranno essere definite eventuali viste.
3.2.1 POPOLAMENTO
La prima fase da intraprendere per rendere operativo il flusso tra database provinciale e fornitori
esterni di dati (ad oggi solo stazioni PAT) è l'impianto della base dati DBGP.
Il popolamento iniziale della base di dati provinciale potrebbe essere ottenuto sfruttando le
componenti software per l'invio degli aggiornamenti incrementali; questa fase di conferimento dei
dati potrebbe infatti essere trattata come un invio, in un unica trance, di numerosi inserimenti.
Qualora si dovessero riscontrare problemi legati alla grande mole di dati o alla numerosità di errori
rilevati si studieranno soluzioni alternative da adottare per le solo fasi di adesione delle stazioni.
Terminata questa fase si dovrebbe avere un database completamente strutturato, il cui contenuto
è documentato dal GeoUML Catalogue, ma soprattutto su cui dovrebbe essere possibile validare la
conformità dei dati alla specifica tramite il GeoUML Validator.
3.3 ETL
Diverse componenti di ETL (Extract, Transform & Load) giocano un ruolo importante in tutto il
sistema. Infatti è necessario prevedere lo sviluppo sia di estrattori di dati dai database locali al fine
di alimentare il DBGP centrale e sia di ETL centrali per la generazione dei database per i servizi di
fruizione. Come vedremo meglio in seguito, i database di fruizione potrebbero avere strutture dati
11
Il GeoUML Validator è alimentato dal file SCS prodotto dal GeoUML Catalogue. Tale file, codificato in XML,
una volta processato dal Validator genera il codice che effettua la maggior parte delle validazioni implicate
dalle specifiche. Queste processi di validazione necessitano dei dati mantenuti nel formato fisico generato dal
Catalogue.
12
Ad esempio: la geometria dei fabbricati può essere ricavata dall’unione delle geometrie degli edifici.

16/47
e contenitori molto diversi in base al servizio da offrire, per cui soprattutto per il componente
indicato in Figura 1 come ETL fruizione occorrerà prevedere una tecnologia versatile che
permetta una grande varietà di trasformazioni e soprattutto per la componente geometrica delle
informazioni.
Per la componente di ETL gestione si possono prevedere degli strumenti che permettano di
estrarre dal DBGS parte o la totalità dei dati, con o senza storicizzazione; i database di provenienza
e destinazione ed anche lo schema dei dati estratti sono però in questo caso molto simili, per cui si
può pensare ad ambienti più legati alla scelta tecnologica per il database o anche a integrati al
componente Validator (che prevede già funzionalità di estrazione).
Gli aspetti relativi alla gestione degli aggiornamenti saranno illustrati in modo approfondito nel
seguito di questo documento nella sezione dedicata all'interscambio tra DBGP e database delle
stazioni.
Un ulteriore estrattore che potrebbe essere molto utile definire è quello che produce la struttura
ottenuta tramite il modello implementativo “Shape Flat” applicato al contenuto definito nel GeoUML
Catalogue; questo estrattore potrebbe permettere l'invio a enti fruitori (o anche alle stazioni) di
tutti o parte dei dati del DBGP. L'invio dei dati provinciali potrebbe permettere la creazione di un
database locale nel quale i dati ricevuti costituiscono una base validabile sui quali possono essere
inseriti e validati altri dati extra-specifica provinciale, ma di forte interesse locale.
Altre funzionalità di estrazione, non indicate però nello schema architetturale, sono necessarie ai
fini dell’applicazione al DB centrale di un aggiornamento proveniente da una stazione: infatti, come
vedremo meglio nel paragrafo 4.3.2, il processo di aggiornamento prevede una simulazione
effettuata su una copia del DBGP, o meglio, sulla copia dello stato attuale dei dati contenuti nel
DBGP. L'estrattore dovrà quindi generare una copia PostGIS dello stato attuale del contenuto del
DBGP, privo di storicizzazione, la quale sarà utilizzata per simulare l'applicazione di aggiornamenti
provenienti da una stazione.
3.4 La validazione
Tenendo in considerazione quanto premesso circa il componente GeoUML Validator, vediamo in
questo paragrafo alcune considerazioni generali sul processo di validazione e poi come si applicano
nel contesto dell’architettura proposta.
Il generico processo di validazione di un dataset si può scomporre in diverse fasi:
• Validazione intrinseca
o Validazione strutturale (esistenza delle classi, degli attributi …)
o Validazione relazioni e domini
o Validazione relazioni topologiche
o Validazione vincoli metrici (verifica lunghezza minima archi o area minima di poligoni
)
• Validazione reale
La validazione reale riguarda la verifica di vincoli che non sono inseriti nella specifica concettuale e
che possono essere quindi validati solo dall’uomo. Un esempio può essere quello della quota di una
sorgente: è ovvio che non esistono sorgenti sulle vette dei monti o in loro prossimità, ma è
impossibile codificare questa regola in maniera formale.
Tutti gli aspetti della validazione intrinseca, invece, sono coperti dalle funzionalità del GeoUML
Validator utilizzato in stretta sintonia con l’ambiente di definizione delle specifiche di contenuto.
Nello schema architetturale sono collocati due componenti di validazione: una locale ed una
centrale.

17/47
La validazione locale riguarda solo la porzione di dati gestita all’interno di una stazione e non
contempla le relazioni tra classi gestite da stazioni differenti. Questo passo è necessario per
minimizzare gli eventuali flussi di ritorno dal DB centrale ed è fatto quindi per aiutare a risolvere
tutti i problemi che possono essere affrontati internamente ad una stazione senza un confronto
con dati esterni.
La validazione centrale invece viene fatta “girare” sull’intero database, ovvero, sul database
risultante dall’applicazione dell’aggiornamento della stazione X sulla versione valida ed attuale del
DB centrale, cioè sul DB che si otterrebbe applicando l’aggiornamento richiesto. Vengono quindi
eseguiti controlli che interessano relazioni tra classi non contemplate nella validazione locale.
Un punto di forza della soluzione è sia il riuso dei componenti (è sempre il GeoUML Validator che
esegue le validazioni, alimentato da specifiche differenti) e sia la flessibilità dell’operazione di
validazione. Ad esempio, solo scegliendo la specifica apposita, sarà possibile lanciare
periodicamente anche una validazione totale, sullo stato attuale degli oggetti per verificare la
qualità complessiva13
dei dati presenti nel DBGP.
Ricordiamo che il DB fisico che ospita i dati non implementa direttamente i vincoli della specifica
per poter permettere comunque il caricamento dei dati; la validazione è fatta dinamicamente
attraverso delle procedure prodotte dal Validator.
Una buona prassi è inoltre quella di creare delle regole nelle specifiche anche quando si sa che
esistono eccezioni, proprio per evidenziare queste situazioni e certificarle come eccezioni. Ad
esempio, se sul territorio esistono rarissime situazioni che vedono la presenza di edifici su specchi
d’acqua (strutture su palafitte) è conveniente imporre il vincolo di “edificio non sovrapposto a
specchio d’acqua” e trovare evidenziate le strutture in questione tutte le volte che si fanno le
validazioni.
3.5 Il sistema di fruizione
Il sistema di fruizione è essenzialmente basato sul concetto di “Data Warehouse”, ovvero
sull’estrazione dei dati dal DB di gestione, la loro modellazione, ristrutturazione e replica in schemi
ottimizzati per la consultazione e l’analisi.
Alcune caratteristiche dei Data Warehouse veri e propri non sono applicabili in un contesto
geografico sia per la presenza di limitazioni tecnologiche del software infrastrutturale e sia per gli
obbiettivi che ci prefiggiamo: ad esempio, la gerarchia delle dimensioni di analisi non ha senso per
il tipo di uso che si deve fare dei dati del DB Geografico, così come il processo di armonizzazione è
inutile visto che i dati sono già armonizzati all’interno del DB gestionale.
Per inquadrare meglio dal punto di vista concettuale il modello di Data Warehouse a cui si rifà il
DBGP vediamo in Figura 4 qui sotto un classico modello a “data mart dipendenti”, ovvero derivanti
da un unico Data Warehouse centrale.
In questo modello i dati sono estratti da differenti database operazionali e poi convogliati in un
unico DWH dal quale poi si generano i differenti DM.
13
La presenza di un errore di validazione non comporta il non caricamento di un dato all’interno del DB; ad
esempio, possono essere accettate situazioni in cui alcuni attributi non sono ancora presenti, benché la
specifica lo richieda.

18/47
Figura 4 - Datamart dipendenti
Nella Figura 5, invece, abbiamo un esempio di modello a “datamart indipendenti”, dove i singoli
data mart derivano direttamente dai vari database operazionali senza l’ausilio di un DWH centrale.
Figura 5 - Datamart indipendenti
Ovviamente esiste anche una terza via, il modello ibrido rappresentato in Figura 6, in cui esiste sì
un DWH aziendale, ma dove è possibile anche alimentare direttamente i DM dai DB operazionali.
Figura 6 - Modello ibrido
La situazione della componente di fruizione del DBGP non aderisce direttamente a nessuno di
questi modelli:

19/47
• non esiste un vero e proprio Data Warehouse centrale propriamente detto,
• ma esiste di fatto un unico DB operazionale (il DB centrale), che può essere assolvere
anche alla funzione di DWH enterprise
Siamo quindi molto vicini al modello dei datamart dipendenti perché importanti sono le
caratteristiche di omogeneità che derivano dalla presenza di un DB centrale. A questo schema di
riferimento si aggiunge anche la possibilità di creare dei datamart indipendenti derivati
direttamente dai DB operazionali locali, con visibilità però più limitata. Si è verificata infatti la
necessità di fare fruire i dati locali, intendendo in particolar modo quelli specifici di stazione,
limitatamente agli uffici interni del Dipartimento a cui la Stazione appartiene.
Lo schema architetturale di Figura 1 va quindi rivisto aggiungendo una sorta di Sistema di
Fruizione dipartimentale, come mostrato in Figura 7.
Nel caso più semplice il sistema di fruizione locale può collassare in una serie di viste predisposte
direttamente sul DBGS ei servizi di fruizione coincidere con la possibilità di accedere direttamente
alle viste stesse. Incrementando gradualmente la complessità del sistema, le viste possono essere
esposte tramite servizi di rete, anziché essere accedute direttamente dagli utenti nel DB fino ad
arrivare ad una vera e propria replica effettuata con ETL appositi.
DBTS1
DBTP
Sistema
“verticale” di
stazione
Validazione
centrale
Gestione DBGS1
DBGP
Sistema
“verticale” di
stazione
ETL gestione
Gestione
ETL
fruizione
locale
DM
locale
Sistema
fruizione
locale
Stazione1
Figura 7 - Eventuale sistema di fruizione locale
3.6 I sistemi locali
Prevediamo al momento due tipologie di sistemi locali:
1- Quello in cui i dati sono gestiti attualmente in maniera non strutturata, tipicamente su file
system o su DB non enterprise e attraverso applicazioni GIS generiche.
2- Quello in cui i dati sono stati modellati in uno schema applicativo ad hoc ed essi sono
fisicamente mantenuti in un DBMS dove sono gestiti attraverso applicativi specializzati (o
applicativi GIS commerciali con funzionalità evolute).
Questi sistemi locali sono collocati presso le stazioni SIAT le quali sono collegate con il sistema
centrale e tra di loro in rete locale ad alta velocità.
3.6.1 ARCHITETTURA DI UNA GENERICA STAZIONE PAT SPROVVISTA DI SISTEMA VERTICALE
Il seguente capitolo ha l'obbiettivo di definire l'architettura di una stazione PAT nella quale non è
ad oggi presente una base dati strutturata, nella quale quindi non è necessario il recupero di un
investimento pregresso relativo alla progettazione della base di dati.

20/47
La prima fase da intraprendere per rendere operativo il flusso dati da e per una stazione PAT (e
più genericamente un attore fornitore di dati) è l'impianto del database locale alla stazione che di
seguito sarà chiamato DBGS (database geografico di stazione).
La struttura del database da definire varia da stazione a stazione poiché oltre ai dati obbligatori
(necessari per l'interscambio tra stazione e provincia) devono essere previste delle estensioni
necessarie a contenere e gestire i dati locali della stazione stessa.
Per la definizione di questa personalizzazione si suggerisce un approccio top down, quindi si
potrebbe ottenere la specifica di contenuto della stazione come estensione della specifica di
interscambio dati (che ad oggi si suppone coincida con la specifica della provincia). L'approccio top
down permette di concentrarsi sui contenuti della stazione in modo indipendente dalla loro
implementazione fisica inoltre permette l'inserimento di vincoli. La definizione di nuovi vincoli
potrebbe permettere alla stazione di controllare localmente delle proprietà che potrebbero non
essere presenti a livello centrale o potrebbero essere più stringenti di quelle definite centralmente,
questo arricchimento dei vincoli GeoUML è utile se si vuole utilizzarli per identificare delle situazioni
dubbie che potrebbero rappresentare degli errori.
Dopo la definizione dei contenuti aggiuntivi è necessario concentrarsi nella strutturazione fisica del
database per la quale si possono seguire due approcci:
1. Personalizzazione delle DDL come avvenuto per la definizione del DBGP
2. Estensione delle DDL già definite nel DBGP
Il primo approccio permette di far emergere le peculiarità di ogni singola stazione, ma è senza
dubbio un processo più oneroso sia in termini di tempo che economici poiché presuppone
un’analisi e degli attori che siano in grado di analizzare le diverse soluzioni proposte per poi
scegliere quella che ritengono migliore.
Il secondo approccio estende le scelte fatte centralmente in Provincia alle singole Stazioni, ma
permette di generare molto velocemente la base di dati e potenzialmente di riutilizzare tutti gli
strumenti sviluppati dalle Provincia anche localmente con un sensibile risparmio dei costi. Questo
approccio richiede di identificare le classi e le relative tabelle che saranno utilizzate dalla Stazione
e, solo per quelle tabelle, ereditare lo schema definito per il DBGP.
Considerando la metodologia partecipativa con cui sono state definite le specifiche di contenuto del
DB centrale, che ha visto il ruolo attivo ed il contributo di tutte stazioni, la soluzione
“estensione dello schema DBGP” è quella che sicuramente massimizza i vantaggi.
L'estensione richiederà la personalizzazione dello schema fisico inserendo i contenuti aggiuntivi
definiti nello schema concettuale. Questa operazione è abbastanza delicata poiché è manuale e
richiede un approccio bottom up; la struttura ottenuta e l'insieme di viste di validazione potranno
però essere verificate semplicemente eseguendo il controllo di conformità della struttura fornito dal
GeoUML Validator.
Le classi che non sono gestite localmente possono essere ignorate, quindi non saranno presenti
nello schema del database, o generate utilizzando i DDL generati dal GeoUML Catalogue. Questo
secondo approccio misto facilita le fasi di validazione e struttura i dati secondo un formato di
fruizione che risulta essere adeguato poiché i dati non saranno gestiti, ma solo fruiti localmente.
Al termine di questa fase sarà presente un database completamente strutturato, il cui contenuto è
documentato dal GeoUML Catalogue e validabile sia utilizzando la specifica locale che provinciale.
Se la base dati sarà generata per estensione del DBGP con le integrazioni delle strutture generate
dal GeoUML Catalogue si potrebbe sviluppare un componente che permetta di importare tutti i dati
presenti nel database provinciale e non gestiti localmente. Questo componente potrebbe

21/47
permettere una validazione completa dei dati locali poiché sarebbero verificati tutti i vincoli
intraclasse i quali richiedono i dati presenti solo a livello provinciale.
L'importatore potrebbe utilizzare come formato di input la struttura dati generata dal modello
implementativo “Shape Flat” applicato al contenuto definito nella specifica provinciale; se così
fosse l'importatore potrebbe essere riutilizzato in tutti i DBGS per importare i dati provenienti dai
flussi provinciali.
L’utilizzo di shape flat non è l’unica possibilità: si può attingere anche direttamente dal DB di
stazione; la prima soluzione consentirebbe però di estendere la soluzione anche a situazioni in cui
non fosse possibile introdurre un DB PostGIS (ad esempio i Comuni).
Oltre all'applicativo di importazione sarà necessario sviluppare un ETL di esportazione che
permetta di estrarre i dati da aggiornare (preferibilmente sotto forma di delta) da inviare al DBGP;
anche questo componente potrebbe essere riutilizzato in ogni DBGS.
Terminata la definizione della struttura del database devono essere caricati i dati nel DBGS. Le
trasformazioni necessarie per effettuare il caricamento da shapefile utilizzati dalla stazione a
tabelle del DBGS dovranno essere fatte una sola volta poiché successivamente verranno aggiornati
direttamente nel database. Il processo di caricamento varia da stazione a stazione, per questo si
suggerisce una ristrutturazione manuale o attraverso un ETL configurabile poiché si ritiene inutile
lo sviluppo di un applicativo ad-hoc per un solo utilizzo.
Terminata la fase di caricamento ogni stazione procederà all'invio di tutti i dati contenuti nel
database (primo impianto) e dei successivi aggiornamenti (come delta di modifica); si ritiene di
poter gestire il primo impianto come un qualsiasi aggiornamento fatto dalla stazione ma
contenente la totalità dei dati.
DBGS
validazione
SCS
prov
estrazione shapefileNuovo
sistema
verticale
validazione
datispecifici di
stazione
SCS
staz
DBGP
Servizidi fruizione
DB stazione
Figura 8 - Sistema di stazione senza sistema verticale preesistente

22/47
Da notare che il DBGS è parte del DB locale di stazione14
: in altre parole lo schema dei dati
specifici di stazione costituisce un’estensione allo schema del nucleo (DBGS) il quale rispecchia una
porzione del DBGP centrale.
Sul DBGS sono definite delle viste su cui opererà il Validatore configurato con le stesse specifiche
(file SCS) del DBGP centrale.
Opzionalmente, e senza che questo abbia alcun impatto sulla qualità dei dati da conferire
centralmente, potrà essere eseguita anche una validazione sui dati specifici di stazione. Se, infatti,
lo schema dell’estensione verrà definito attraverso il GeoUML Editor, sarà possibile infatti ricavare
un file SCS da utilizzare per configurare il Validatore allo stesso modo con cui si esegue la
validazione delle classi da conferire al DBGP.
3.6.2 ARCHITETTURA DI UNA STAZIONE PAT CON PREESISTENTE SISTEMA VERTICALE
validazione
SCS
prov
Estrazionee
trasformazione
shapefile
Sistema
verticale
legacy
DB legacy
DBGP
Servizidi fruizione
Figura 9 - Sistema di stazione con sistema verticale preesistente
Nel caso di esistenza di un sistema verticale legacy di stazione, è impercorribile la strada del DB
locale come estensione di un ritaglio della specifica del DBGP. Il DB locale non potrà essere
modificato per cui occorre prevedere degli ETL che permettano l’estrazione dei dati per la
validazione e altri per il conferimento al DB centrale. Nello schema di Figura 9 è mostrato un solo
ETL per semplicità, ma la necessità di avere due versioni di estrattori nasce dalla constatazione che
per la validazione locale non è necessaria la profondità storica (si valida l’attualità perché le
specifiche concettuali descrivono solo lo stato attuale), mentre per l’aggiornamento del DBGP
14
Il servizio di database fornito alle stazioni prevede anche a fianco del DB di stazione anche la
dotazione di uno “schema libero”; per eliminare ogni possibilità di equivoco, si precisa che questo
schema libero non ha nulla a che vedere con la porzione di DB che contiene i dati specifici di
stazione.

23/47
occorre fare ragionamenti sulle istanze degli oggetti per poter inviare solamente quello che è
variato. Nel caso più semplice, entrambe le tipologie di ETL possono essere implementate tramite
viste del DBMS sulle tabelle del DB legacy.
4.0 FLUSSI
4.1 Aggiornamento da una stazione PAT sprovvista di base di dati strutturata
Il seguente paragrafo ha l'obbiettivo di definire il flusso di operazioni da effettuare per allineare i
dati presenti sul DBGP a seguito di un aggiornamento applicato localmente sul DBGS.
Si suppone che l'aggiornamento venga applicato dall'operatore al DBGS utilizzando un sistema di
gestione da impiantare sul nuovo DB locale di stazione (nuovo sistema verticale di stazione);
ipotizziamo infatti che una volta definito lo schema del DB e caricati in esso i dati, sia possibile
sviluppare un sistema che ne permetta la gestione direttamente sul DB stesso.
Si suppone che l'aggiornamento rispetti determinati requisiti:
1. il nuovo sistema verticale sia in grado di applicare l'aggiornamento al DBGS gestendo
adeguatamente il paradigma di storicizzazione del dato prescelto;
2. la porzione di struttura dati atta a contenere i dati soggetti ad interscambio e aggiornabili
della stazione sia uguale o un estensione della struttura definita nel DBGP;
3. i dati coinvolti nell'aggiornamento siano solo ed unicamente quelli di proprietà esclusiva
della stazione
Se la stazione è provvista di una propria specifica di contenuto che descrive i dati dalla stazione,
sia quelli soggetti ad interscambio sia quelli di uso interno, si può utilizzare il GeoUML Validator per
effettuare una prima validazione utilizzando come sorgente dati il DBGS.
Questa validazione non è di stretto interesse provinciale, ma può essere molto utile alla stazione
stessa per analizzare la correttezza dell'aggiornamento inserito e lo stato di consistenza della
propria base dati locale.
L'aggiornamento deve essere poi estratto dal DBGS per essere trasferito al DBGP.
Questo procedimento può essere fatto attraverso un ETL, riutilizzabile in tutte le stazioni SIAT, il
quale effettuerà delle query sul DBGS ed estrarrà i dati, relativi al solo aggiornamento, nella
struttura dati di interscambio ottenuta applicando il modello implementativo “Shape Flat” alla
specifica di contenuto provinciale, oppure utilizzando i dati già presenti nel DBGS attraverso
opportune viste.
I dati estratti in formato shapefile possono essere validati con il GeoUML Validator che utilizzerà la
specifica provinciale per controllare la correttezza delle strutture dati e dei valori contenuti in ogni
singolo record degli shapefile. Durante questo processo di validazione, poiché si stanno
esaminando solo dei dati che rappresentano l'aggiornamento incrementale, non possono essere
effettuati controlli di vincoli GeoUML, di chiave primaria, chiave esterna o univocità poiché la
validazione è relativa al solo delta di aggiornamento.
La problematica potrebbe essere ovviata costruendo un servizio (remoto) che permetta una
validazione simulando il recepimento dell'aggiornamento da parte del DBGP e permetta di valutare
l'interazione tra l'aggiornamento proposto dalla singola stazione e i dati che risiedono nel DBGP.
Questo servizio potrebbe permettere alla singola stazione di valutare gli effetti e la ricaduta di un
aggiornamento sul DBGP.
Un servizio di simulazione di questo tipo potrebbe operare solo sui dati di interscambio e non sui
dati locali della singola stazione. La validazione dovrebbe essere fatta utilizzando una specifica ad

24/47
hoc nella quale siano presenti tutti e solo i vincoli che coinvolgono le classi la cui gestione è
demandata alla stazione. Il servizio di simulazione dovrà produrre una diagnostica utile alla
stazione per valutare se le violazioni rilevate dalla validazione siano imputabili ad errori della
stazione (in qual caso provvederà a bonificarli) o ad errori di competenza di altre stazioni.
Sono state definite quali siano le principali fasi richieste per la produzione dell'aggiornamento e il
successivo invio al DBGP; oltre alle fasi è necessario definire la frequenza e la modalità di invio
degli aggiornamenti. L'invio può avvenire in modo manuale o automatico sia attraverso
schedulazioni che attraverso la definizione di componenti che rilevano l'avvenuto aggiornamento.
L'invio di aggiornamenti in modo automatico permette di evitare disallineamenti tra DBGS e DBGP
evitando oneri di invio da parte dell'operatore locale; questo approccio però ha anche dei lati
negativi. È necessario considerare che l'operatore della stazione, se l'aggiornamento avviene in
modo automatico, inserisca solo gli aggiornamenti che è sicuramente in grado di validare entro
l'inizio della procedura di invio. Questo potrebbe comportare la definizione di base dati parallele
nelle quali definire gli aggiornamenti speditivi e/o di grande impatto che potrebbero richiedere un
lungo lavoro di editing.
La procedura di invio manuale dell'aggiornamento permetterebbe invece alle singole stazioni di
gestire degli aggiornamenti speditivi e degli stati inconsistenti inviando gli aggiornamenti solo
quando la base di dati fosse riportata in consistenza; questo eviterebbe la creazione di base dati
parallele e perdita di informazioni.
Con lo schema seguente si tenta di riassumere il flusso di invio di un aggiornamento da parte di
una stazione priva di base dati strutturata:
All'inizio del paragrafo si sono definiti dei requisiti necessari perché sia possibile gestire l'invio
dell'aggiornamento; questi prerequisiti potrebbero non essere rispettati, rispettati solo in parte o
raggiunti progressivamente.
Sistema verticale o
applicativo GIS
di stazione
DBGSAggiorna
GeoUML
Validator
SC locale
ETL - estrattore
aggiornamento
Shape di
aggiornamento
Produce
Sistema informativo di stazione
DBGP di
simulazione
Valida
GeoUML
Validator
SC DBTP con
vincoli ad-hoc
per la stazione
locale
Report di
simulazione
Valida
Tool di gestione
dell'aggiornamento
Applica
Produce
Figura 10 - Flusso di aggiornamento

25/47
Si ritiene necessario esplorare alcune possibili variazioni al flusso sopra illustrato al fine di
permettere l'invio degli aggiornamenti anche nel caso in cui non siano rispettati tutti i requisiti.
Il principale problema che ci si potrebbe trovare ad affrontare è un problema dipendente
dall'applicativo verticale utilizzato dalla singola stazione; potrebbe accadere che una stazione
utilizzi uno strumento che non sia in grado di storicizzare il dato o utilizzi una struttura dati
proprietaria diversa da quella definita per la gestione dei dati locali.
Nel caso in cui ci fosse un problema di storicizzazione del dato e l'applicativo non possa essere
modificato con tempi e costi accettabili, bisogna analizzare il problema cercando di capire se è
possibile definire un insieme di strumenti (software applicativi e/o trigger e viste a livello di
database) che siano in grado di intercettare gli aggiornamenti e di storicizzarli in modo totalmente
trasparente all'applicativo. Questo insieme di strumenti agirebbero come livello di accesso ai dati e
sarebbero posti tra l'applicativo e la base di dati locale; sfortunatamente questo livello non è
sempre realizzabile con costi e tempi accettabili.
Nel caso in cui la stazione non sia in grado di storicizzare i dati e/o riconoscere i dati aggiornati da
quelli invariati, l'invio dell'aggiornamento dovrà avvenire con un approccio diverso da quello sopra
descritto. Si dovrà infatti sacrificare l'invio del delta di aggiornamento sostituendolo con l'invio di
tutto il contenuto oggetto di interscambio tra il singolo DBGS e il DBGP. Questo approccio
comporta la perdita dello storico degli aggiornamenti anche sul lato provinciale.
Si è deciso che la gestione dello storico nel DBGP deve essere mantenuta ed è un vincolo che non
può essere rilassato; quindi sarà necessario imporre un minimo di gestione da parte del DBGS. Se
la stazione non è in grado di gestire lo storico deve almeno essere in grado di riconoscere gli
oggetti aggiornati (semplicemente aggiornando una data di ultima modifica); questo step minimale
permetterà di gestire lato DBGP la storicizzazione anche se non sarà gestita localmente.
Qualora l'applicativo utilizzato dalla stazione non sia in grado di raggiungere questo step minimale
si è supposto di gestire il riconoscimento dell'aggiornamento lato database definendo ed
implementando dei trigger che aggiornino le date di inizio, fine ed ultima modifica in modo
trasparente all'applicativo. Nel caso in cui il trigger fosse posizionato su tabelle che contengono
dati di interesse provinciale e anche dati di solo interesse locale potrebbe essere necessario
rilassare il paradigma di aggiornamento permettendo l'invio di aggiornamenti senza alcuna
variazione dei dati di interesse provinciale (poiché l'aggiornamento potrebbe riguardare solo dati di
interesse locale).
Nel caso in cui ci fosse una base di dati proprietaria, interna all'applicativo e/o non modificabile,
una possibile soluzione potrebbe essere quella di creare delle "meta strutture" intermedie che,
tramite un ETL, possano generare la struttura richiesta per la validazione e per l'estrazione
dell'aggiornamento. Questo approccio presuppone comunque la persistenza degli identificativi dei
dati gestiti dal sistema verticale.
Potrebbe infine accadere che il software non sia in grado di gestire la storicizzazione e lavori con
un modello dati interno non adattabile; in questo caso sarà necessario sviluppare un ETL che
possa generare la struttura per la validazione e per l'aggiornamento, il quale comprenderà la
totalità dei dati e non solo le modifiche sotto forma di delta.
L'ultima problematica da affrontare è la violazione del prerequisito di aggiornamento dei soli dati
con proprietà esclusiva; questa eventualità verrà analizzata nel paragrafo relativo
all'aggiornamento di oggetti condivisi poiché potrebbe richiedere una gestione ad-hoc dipendente
dal contesto.

26/47
4.1.1 COMPONENTI NECESSARI PER L'INVIO DI UN AGGIORNAMENTO DA UNA STAZIONE
SPROVVISTA DI BASE DI DATI STRUTTURATA
Per rendere possibile il flusso di invio di un aggiornamento tra una stazione sprovvista di base di
dati strutturata e il database provinciale, scenario riportato nel paragrafo precedente, è necessario
definire e/o realizzare i seguenti componenti:
• Definizione di una specifica concettuale che descrive i contenuti e le proprietà dei dati
gestiti dalla singola stazione. La specifica dovrà almeno contenere la descrizione del set
minimo di dati relativi all'interscambio; in aggiunta è auspicabile che vengano inseriti
(almeno a fine documentale) tutti gli attributi e gli oggetti utilizzati localmente dalla singola
stazione. Oltre ai contenuti della stazione devono essere anche inserite tutte le proprietà
relative ai dati in modo da rendere possibile la validazione permettendo l'identificazione di
errori o warning. L'operazione di definizione di una specifica concettuale locale è
dipendente dal contesto e deve essere ripetuta per ogni di stazione
• Definizione della struttura fisica della base di dati di stazione. A differenza della specifica di
contenuto che è definita a livello concettuale per definire la struttura fisica bisogna sempre
mediare tra livello concettuale, vincoli imposti dalla tecnologia, fruizione e gestione dei dati.
La base di partenza per la definizione della struttura fisica può essere lo script generato
attraverso il GeoUML Catalogue applicando il modello implementativo PostGIS
monogeometria alla specifica di contenuto provinciale. Si deve sempre tener presente che
gli script generati attraverso il GeoUML Catalogue sono studiati per la fruizione del dato e
non per la gestione, inoltre sono privi di un concetto di storicità. Può essere necessario
intervenire manualmente per destrutturare alcune componenti (come per esempio attributi
multivalori o datatype) in modo che sia possibile aumentarne la praticità di gestione e si
deve prevedere un meccanismo che permetta di mantenere la storicizzazione del dato. Si
dovrebbe prevedere inoltre un'insieme di viste e/o routine applicative che permettano di
produrre lo schema richiesto dal GeoUML Catalogue e utilizzato dal GeoUML Validator per
eseguire la validazione del set di dati. Un approccio consigliato, ma molto delicato è
l'utilizzo della derivazione per la generazione di determinati oggetti (come per esempio i
cassoni edilizi, la massima estensione degli edifici, i tracciati e le pertinenze dei toponimi).
La generazione per derivazione permette di diminuire l'onere di editing da parte della
singola stazione ma se generata attraverso algoritmi che utilizzano la tolleranza e/o non
riallineano i componenti al composto potrebbe essere controproducente poiché potrebbe
comportare oneri aggiuntivi alla stazione a cui verrebbe chiesto di risolvere errori di
tolleranza introdotti durante la derivazione. L'operazione di definizione della struttura fisica
è dipendente dal contesto e deve essere ripetuta per ogni di stazione.
• Realizzazione (presumibilmente una tantum per tutte le stazioni) di un ETL di estrazione
degli aggiornamenti effettuati localmente. L'estrattore da realizzare dovrebbe riuscire a
selezionare solo le feature aggiornate tra quelle presenti nel DBGS e ad estrarle in formato
shapefile per effettuare un aggiornamento. L'ETL da sviluppare dovrebbe prevedere tutte le
strutture gestite / definite nella specifica provinciale inoltre dovrebbe avere la possibilità di
attivare/disattivare l'estrazione di alcuni oggetti in modo che possa essere configurabile e
riutilizzabile in tutte le stazioni. Il riutilizzo del ETL è subordinato anche dal metodo di
storicizzazione adottato localmente che, se non omogeneo per tutte le stazioni, potrebbe
richiedere sviluppi ad-hoc per permettere l'estrazione dei dati da stazioni diverse. La
complessità di questo ETL è dipendente dalle decisioni relative a cosa e in che modo
storicizzare ed estrarre gli aggiornamenti dalla singola stazione.
• Realizzazione (una tantum per tutte le stazioni) di un tool che permetta di simulare
l'applicazione di un aggiornamento. Il tool dovrà come prima cosa creare una copia del solo
stato attuale del database provinciale e avrà l'onere di applicare gli aggiornamenti

27/47
traducendo i dati shapefile in operazioni di cancellazione, inserimento ed aggiornamento.
Effettuate le operazioni, in base al contenuto dell'aggiornamento, si otterrà una replica
dello stato attuale del database provinciale "post" aggiornamento.
• Definizione di una specifica per la validazione dell'aggiornamento. La specifica da definire,
come contenuto, è figlia della specifica provinciale ma le proprietà GeoUML da verificare
saranno solo un subset di quelle definite a livello centrale, in modo che la singola stazione
possa concentrarsi sull'identificazione degli errori relativi ai propri dati e non sia distratta da
violazioni relative a dati gestiti da altre stazioni. Questa attività è dipendente dalla stazione.
• Definizione di un report / realizzazione di un tool di report che permetta alla singola
stazione di identificare velocemente le segnalazioni più gravi che devono essere risolte con
priorità maggiore e / o che potrebbero portare la provincia a rifiutare l'aggiornamento; a tal
fine sarà necessario definire quali errori siano ritenuti sempre bloccanti per l'accettazione
dell'aggiornamento. Un ulteriore sviluppo potrebbe portare ad identificare velocemente
quali segnalazioni siano relative all'aggiornamento proposto e quali siano gli errori
precedentemente presenti sui dati o di competenza altrui. Questo processo di scrematura è
molto utile soprattutto nelle fasi iniziali dove gli aggiornamenti si occuperanno
principalmente della bonifica degli errori rilevati. Alla definizione del report / realizzazione di
un tool di report deve essere affiancata una formazione specifica per gli operatori di
stazione che li metta in grado di identificare gli oggetti su cui insistono le segnalazioni,
capirne la provenienza e la causa delle segnalazioni e decidere il metodo migliore per
risolverle.
4.2 Aggiornamento da una stazione PAT con base di dati già strutturata
Il seguente paragrafo ha l'obbiettivo di definire il flusso tra l'applicazione dell'aggiornamento e il
suo invio al DBGP nel caso in cui sia presente una stazione con una base dati già strutturata.
Gli approcci elencati nel paragrafo sottostante dovranno essere adottati se e solo se non sia
possibile modificare il sistema verticale e/o la base dati locale per ottenere i prerequisiti esplicitati
nel paragrafo precedente.
Nel caso in cui la tecnologia di memorizzazione dei dati fosse un database PostGIS la casistica
rientra sempre nella varianti esplicitate al paragrafo precedente.
Nel caso in cui i prerequisiti potessero essere rispettati, ma la tecnologia di memorizzazione dei
dati fosse diversa da un database PostGIS sarà necessario sviluppare un ETL ad-hoc che permetta
l'estrazione dei dati dalla struttura di memorizzazione adottata localmente e la successiva
importazione in un database PostGIS generato secondo il modello implementativo PostGIS
monogeometria. Questa trasformazione permetterà di validare i dati locali e gli aggiornamenti
attraverso il GeoUML Validator e di riutilizzare l'ETL di invio dell'aggiornamento al DBGP.
Qualora i prerequisiti elencati nel paragrafo precedente non fossero rispettati potrebbe essere
necessario sacrificare l'invio degli aggiornamenti come delta e potrebbe essere necessario definire
regole di trasformazione non banali da inserire nel ETL ad-hoc che permetta l'estrazione dei dati
dalla struttura di memorizzazione adottata localmente e la successiva importazione in un database
PostGIS pro validazione e invio aggiornamento.
Se ci si trova in quest'ultimo caso è sempre necessaria un'analisi costi/benefici tra l'adozione di
questi componenti architetturali e la ridefinizione della base dati e/o degli strumenti software della
singola stazione. Entrambe le soluzioni mostrano lati positivi e negativi poiché se è vero che
l'adozione di un'architettura standard di stazione diminuisce i costi e standardizza il flusso richiede
la modifica del modo di operare del personale e la formazione dello stesso per l'utilizzo della nuova
base dati e/o dei nuovi software di gestione. Se si volesse mantenere la gestione in modo corrente

28/47
potrebbe essere necessario l'adozione di complessi componenti software (ETL ad-hoc e database
pro validazione ed esportazione) che potrebbero aumentare la complessità del flusso di gestione
per l'invio di aggiornamento creando delle resistenze da parte degli operatori.
Con lo schema seguente si tenta di riassumere il flusso di invio di un aggiornamento da parte di
una stazione con base di dati strutturata.
4.2.1 COMPONENTI NECESSARI PER L'INVIO DI UN AGGIORNAMENTO DA UNA STAZIONE CON BASE
DI DATI GIÀ STRUTTURATA
Per rendere possibile il flusso di invio di aggiornamenti tra una stazione con base di dati già
strutturata e il database provinciale, scenario riportato nel paragrafo precedente, è necessario
definire e/o realizzare i seguenti componenti:
• Definizione di una specifica concettuale che descrive i contenuti e le proprietà dei dati
gestiti dalla singola stazione. Come per lo scenario della stazione sprovvista della base di
dati la specifica dovrà almeno contenere la descrizione del set minimo di dati relativi
all'interscambio; in aggiunta è auspicabile che vengano inseriti (almeno a fine
documentale) tutti gli attributi e gli oggetti nel database legacy. L'operazione di definizione
di una specifica concettuale locale è dipendente dal contesto e deve essere ripetuta per
ogni di stazione
Sistema verticale o
applicativo GIS
di stazione
DBGS
Aggiorna
GeoUML
validator
SC locale
ETL - estrattore
aggiornamento
Shape di
aggiornamento
Produce
Sistema informativo di stazione
DBGP di
simulazione
Valida
GeoUML
validator
SC DBTP con
vincoli ad-hoc
per la stazione
locale
Report di
simulazione
Valida
Tool di gestione
dell'aggiornamento
Applica
Produce
DBT
legacy
ETL - ad-hoc
Sistema informativo provinciale
Figura 11 - Flusso per la simulazione di aggiornamento (caso di DB legacy)

29/47
• Definizione della struttura fisica della base di dati di stazione. A differenza della struttura
fisica di una stazione sprovvista della base di dati, in questo caso si potrebbero utilizzare gli
script generati dal GeoUML catalogue poichè potrebbe non interessare mantenere una
storicizzazione (in quanto sarebbe sufficiente riconoscere gli update). La struttura da
adottare comporta una riflessione poichè deve mediare tra le esigenze di validazione, i
requisiti/limitazioni tecnologiche e l'onere implementativo richiesto dallo sviluppo del ETL
per il popolamento di tale struttura.
• Definizione e realizzazione di un ETL di riempimento. Deve essere progettato e realizzato
un tool che colmi il gap tra il "DBT legacy" e il "DBGS". È importante non sottovalutare
l'analisi di questo componente il cui compito non è solo quello di leggere da una sorgente e
scrivere in una destinazione ma si deve occupare del mantenimento degli identificativi,
della consistenza geometrica tra feature in associazione che possono subire manipolazioni e
derivazioni, della selezione del solo stato attuale in modo consistente e di permettere il
riconoscimento e la selezione dell'aggiornamento.
• Realizzazione di un ETL di estrazione degli aggiornamenti effettuati localmente. Si suppone
si possa riutilizzare l'estrattore sviluppato per le stazioni prive di base di dati strutturata.
• Realizzazione di un tool che permetta di simulare l'applicazione di un aggiornamento. Si
suppone si possa riutilizzare il tool sviluppato per le stazioni prive di base di dati
strutturata.
• Definizione di una specifica per la validazione dell'aggiornamento. È necessario affrontare le
problematiche analoghe a quelle per le stazioni prive di base di dati strutturate.
• Definizione di un report / realizzazione di un tool di report che permetta alla singola
stazione di identificare velocemente all'interno delle segnalazioni rilevate dal GeoUML
validator quali siano relative all'aggiornamento proposto e quali siano precedentemente
presenti sui dati o di competenza altrui. Queste problematiche sono analoghe a quelle per
le stazioni prive di base di dati strutturata; in aggiunta qui c'è anche un'ulteriore onere sia a
livello concettuale che livello implementativo. Per rendere il report davvero efficace ed
utilizzabile dagli operatori che operano sulla base di dati legacy si dovrebbe definire un
"mapping inverso" a quello utilizzato dall'ETL di trasformazione tra DBT legacy e DBGS.
Questo permetterebbe agli utenti di identificare le segnalazioni sugli oggetti gestiti dal DBT
legacy; purtroppo questo mapping potrebbe non essere definibile poichè alcune
trasformazioni non sono invertibili. Un esempio di criticità di questo tipo è quando si rileva
una segnalazione su un oggetto ottenuto per derivazione, è necessario ricondurre la
segnalazione sull'oggetto/i componenti che generano l'errore; in concreto se si volesse
ottenere la massima estensione degli edifici per derivazione delle unità volumetriche e si
rilevasse un errore di connessione sulla massima estensione di un edificio bisognerebbe
esaminare quale delle unità volumetriche generi l'errore e ricondurre la segnalazione a
quest'ultimo.
4.3 Flusso di recepimento dell'aggiornamento nel database provinciale
Il seguente paragrafo ha l'obbiettivo di definire in quale modo il sistema informativo provinciale
possa recepire gli aggiornamenti provenienti dalle stazioni periferiche.
Ogni aggiornamento che deve essere applicato alla base di dati provinciale deve essere sottoposto
ad un processo di validazione e valutazione al cui termine dovrà essere deciso se l'aggiornamento
sarà rifiutato o approvato.
Nel caso in cui l'aggiornamento sia inviato sotto forma di delta di variazione, l'utilizzo del GeoUML
Validator sui dati del solo aggiornamento è utile solo a testare la struttura dei dati in input senza

30/47
poter valutare le relazioni con gli altri dati inseriti nel database. Se l'aggiornamento fosse inviato
sotto forma di copia dello stato attuale di tutta la banca dati locale il GeoUML Validator potrebbe
testare le proprietà interne al set di dati ma non le relazioni con gli altri dati inseriti nel DBGP.
Per testare a pieno l'impatto di un aggiornamento sulla banca dati provinciale deve essere creato
un ambiente di valutazione che simuli l'applicazione dell'aggiornamento al DBGP e ne valuti gli
effetti prima di operare l'aggiornamento vero e proprio.
Questo ambiente dovrebbe replicare il DBGP nel solo stato attuale (eliminando tutti i dati
storicizzati) e attraverso una componente software, da sviluppare, applicare l'aggiornamento
proveniente dalle singole stazioni.
Il componente di applicazione dell'aggiornamento dovrebbe essere in grado di leggere gli shapefile
provenienti dalle stazioni periferiche e trasformarli in operazioni SQL di INSERT, UPDATE e
DELETE. Nel caso in cui l'aggiornamento sia inviato sotto forma di delta il componente si limiterà
ad applicare le modifiche alle sole istanze di dati che hanno subito variazioni; se invece
l'aggiornamento viene inviato come copia dello stato attuale di tutta la banca dati locale il
componente software sostituirà il contenuto delle tabelle interessate con i dati inviati.
Applicato l'aggiornamento sull'ambiente di valutazione questo database potrà essere utilizzato
come sorgente dati per il GeoUML Validator il quale testerà tutte le proprietà, le relazioni e i vincoli
su tutta la base dati.
Al termine della validazione si dovrà decidere se la decisione di applicare l'aggiornamento richieda
una valutazione da parte di un operatore o possa essere presa in modo automatico; in questo
ultimo caso si devono definire delle apposite funzioni che siano in grado di decidere quali e quanti
errori provochino il rifiuto dell'aggiornamento.
Un ulteriore aspetto da approfondire e definire è relativo a quali metadati di istanza e qualità
debbano essere prodotti per generare delle segnalazioni di anomalie che potrebbero essere salvate
nel DBGP e/o inviate alle stazioni periferiche.
Questi metadati di qualità sono fondamentali per tenere traccia dei problemi riscontrati in modo
che possano essere risolti attraverso successivi invii di aggiornamenti.
Qualora l'aggiornamento venga rigettato è necessario prevedere un meccanismo di segnalazione
alla stazione periferica; la segnalazione dovrà contenere gli errori rilevati e quali correzioni sono
necessarie per permettere l'applicazione dell'aggiornamento.
Viceversa se l'aggiornamento fosse applicabile si dovrà sviluppare una variante del componente di
applicazione dell'aggiornamento utilizzato precedentemente il quale applichi l'aggiornamento
storicizzando i dati e inserisca i metadati e le anomalie generati durante la fase di validazione.

31/47
4.3.1 COMPONENTI NECESSARI PER IL RECEPIMENTO DI UN AGGIORNAMENTO DA PARTE DEL
SISTEMA INFORMATIVO PROVINCIALE
Per rendere possibile il flusso di recepimento di aggiornamenti dal lato provinciale, scenario
riportato nel paragrafo precedente, è necessario definire e/o realizzare i seguenti componenti:
• Realizzazione di un tool che permetta di simulare l'applicazione di un aggiornamento. Il tool
dovrà come prima cosa creare una copia del solo stato attuale del database provinciale e
avrà l'onere di applicare gli aggiornamenti traducendo i dati shape in operazioni di
cancellazione, inserimento ed aggiornamento. Il tool di cui si sta parlando è lo stesso che è
sfruttato per simulare l'aggiornamento lato stazione.
• Definizione di un report / realizzazione di un tool di report che permetta di identificare
velocemente tra errori rilevati dal GeoUML Validator quali errori siano relativi
all'aggiornamento richiesto e quali siano gli errori precedentemente presenti sui dati;
questa realizzazione può essere un raffinamento dei tool/report realizzati per le stazioni. Si
presume che sia un raffinamento poiché il report non sarà esaminato dalla stazione ma
Shape di
aggiornamento
DBGP di
simulazione
Valida
GeoUML
validator
SC DBTP i soli
vincoli ad-hoc
per la stazione
locale
Report di
simulazione
Tool di gestione
dell'aggiornamento
Applica
Metadati di
istanza e qualità
Processo di valutazione
Aggiornamento rifiutato!
Segnalazione a stazione
Aggiornamento approvato
Tool di applicazione
dell'aggiornamento
DBGP
Applicazione dell'aggiornamento
Inserimento anomalie e metadati
Storicizzazione
Segnalazione di
aggiornamento
Figura 12 - Applicazione dell'aggiornamento sul DBGP

32/47
dalla provincia quindi variando il destinatario potrebbe essere necessario apportare delle
modifiche.
• Definizione dei metadati di istanza e di qualità che si vogliono produrre. Definito cosa può
essere interessante memorizzare bisogna implementare un tool che permetta la
generazione di metadati di istanza partendo dal database di reportistica del validatore. Il
tool potrebbe creare un'insieme di strutture opportunamente "associate" all'update che
potranno essere inserite come metadati di istanza nel DBGP. Queste informazioni sono utili
sia in fase di valutazione dell'update sia alle singole stazioni che possono visualizzare quali
inconsistenze insistono sul database provinciale dando così precedenza alle correzioni.
• Definizione del processo di valutazione. In prima battuta bisogna definire quali violazioni ed
errori non rendono accettabile un aggiornamento. Durante la fase di sperimentazione il
processo di valutazione deve essere manuale poiché, almeno in prima battuta, si ritiene
molto complesso definire dei parametri di valutazione che guidino un algoritmo automatico
di valutazione. Si propone di posticipare ogni valutazione sulla fattibilità, costi e tempi di
sviluppo di un tool di valutazione automatica solo dopo aver testato manualmente la bontà
degli indici di accettabilità che dovranno essere definiti e raffinati durante la fase di
sperimentazione.
Realizzazione di un tool di applicazione di un aggiornamento. Il tool è un'evoluzione dello
strumento di simulazione dell'aggiornamento infatti lavorerà sullo stesso schema. La differenza è
nelle operazioni che dovrà effettuare poiché non dovrà operare delle sostituzioni di dati, ma dovrà
occuparsi di storicizzare il dato vecchio ed inserire quello nuovo. Oltre alla storicizzazione dovrà
anche farsi carico di inserire i metadati di istanza e di qualità, i quali non sono gestiti dal tool di
simulazione.
4.3.2 COMPONENTI E FLUSSO DI SIMULAZIONE DI UN AGGIORNAMENTO
La realizzazione di un servizio di simulazione è una delle componenti fondamentali per permettere
alle singole stazioni, ed in futuro ad altri attori quali i Comuni, di poter testare l'effetto di un
aggiornamento proposto. Il servizio di simulazione sarà percepito dalle singole stazioni come una
black box a cui saranno inviati gli aggiornamenti sotto forma di shapefile e restituirà un insieme di
report e di metadati di istanza e qualità. L'input del servizio è definito come insieme di shapefile
poiché si vuole definire un servizio che possa essere in futuro riutilizzabile anche da enti esterni
alla Provincia; per la fase di sperimentazione riguardante le sole stazioni si può applicare una
semplificazione sostituendo gli shapefile con delle query dirette sui database di stazione evitando
lo sviluppo di un ETL per la produzione e l'importazione degli shapefile di aggiornamento.

33/47
Il servizio di simulazione sarà invocato da una stazione la quale invierà il "delta" aggiornamento
(solo le modifiche intercorse dall’ultimo aggiornamento); l'interfaccia del servizio di simulazione
sarà oggetto di definizione da parte di Informatica Trentina, ma si presume possa essere un
servizio web invocabile remotamente tramite un protocollo standard come SOAP (Simple Object
Access Protocol).
La prima fase del servizio di simulazione è la creazione del database di simulazione che contiene
solo parte dei dati del DBGP. La selezione dei dati avviene sia verticalmente che orizzontalmente
poiché nel database di simulazione saranno inseriti solo i dati di interesse della stazione privi della
storicizzazione. Per ottenere questa selezione si potrebbero definire delle viste sul DBGP che
permettano di selezionare lo stato attuale degli oggetti scartando le istanze storiche. Definite le
viste per tutte le classi della specifica il servizio di simulazione dovrà selezionare, effettuando delle
SELECT sul DBGP e delle INSERT sul database di simulazione, i soli oggetti di interesse della
stazione e quelli ad essi connessi.
È fondamentale definire quali siano gli oggetti da selezionare per ogni stazione: in prima battuta
questo insieme è dato da tutti gli oggetti di uso esclusivo della stazione sommati a tutti gli oggetti
correlati, attraverso vincoli GeoUML, ai dati di stazione. Un'analisi più specifica dovrà essere fatta
per i vincoli che controllano la copertura del suolo poiché in questo caso si dovrebbero riscrivere
e/o indebolire alcuni vincoli per ridurre al minimo il contenuto dei dati correlati. La definizione di
questo insieme può variare nel tempo poiché è plausibile che la specifica del DBGP possa subire
evoluzioni sia in termini di contenuti sia di vincoli GeoUML; per far fronte a questa esigenza di
adattamento ai cambiamenti delle specifiche si ritiene necessario realizzare un servizio di
simulazione che sia configurabile.
Al termine del caricamento il servizio di simulazione deve controllare la correttezza dei dati di
aggiornamento ed applicare le modifiche richieste dalla stazione. Il controllo della correttezza è
necessario per proseguire con le fasi successive; questo controllo consiste nella ricerca degli
Shape di
aggiornamento
DBGP di
simulazione
GeoUML
validator
SC di
validazione
Report di
simulazione
Servizio di
simulazione
Metadati di
istanza e qualità
Fase 1
Fase 2
DBF DBN DB report
Generatore
report e metadati
Fase 4
Fase 3
Figura 13 - Il servizio di simulazione aggiornamento

34/47
oggetti da modificare, inserire e cancellare. Propedeutica per l'applicazione dell'aggiornamento è la
presenza degli oggetti che devono subire aggiornamenti o cancellazioni e l'assenza degli oggetti
che devono subire inserimenti poiché, se non fossero presenti gli identificativi che devono subire
un aggiornamento o una cancellazione e/o fossero presenti gli identificativi che devono essere
inseriti, saremmo di fronte ad uno stato di disallineamento tra DBGP e DBGS o un errore nella
produzione dell'aggiornamento.
La seconda fase è relativa alla selezione della specifica da utilizzare per la validazione dei dati di
simulazione nella quale saranno definite le soli classi di interesse della stazione e quelle ad esse
correlate. Si suppone di avere a disposizione un pool di specifiche, una per stazione, ognuna già
importata in un database Apache Derby nel formato richiesto dal Validator e di copiare il database
da utilizzare nella cartella del Validator. Sovrascrivere il database interno piuttosto che rieseguire
ogni volta la configurazione del Validator ha diversi vantaggi; come prima cosa è un processo più
rapido, ma soprattutto permette di ridurre al minimo gli errori. Supponiamo infatti che avvenga
una scrittura errata o inconsistente che comprometta il corretto funzionamento del database
interno; tale evento potrebbe essere causato da un baco del software o da uno spegnimento
improvviso della macchina. Nel caso precedente se si adotta la strategia di importare ogni volta la
specifica di validazione si potrebbe bloccare tutto il processo di simulazione, viceversa se si
sovrascrive il database interno si potrà proseguire con la validazione delle successive simulazioni.
La terza fase è relativa alla validazione vera e propria nella quale il GeoUML Validator sarà avviato
come servizio utilizzando un'apposita interfaccia Java che permetta di avviare le singole fasi di
importazione, normalizzazione e validazione. Il GeoUML Validator utilizzerà il DBGP di simulazione
come sorgente dati e due database PostGIS, uno di caricamento (DBF) e uno di normalizzazione
(DBN). Questi database interni saranno riutilizzati per ogni validazione poiché lo schema delle
tabelle sarà generato di volta in volta dal GeoUML Validator. In termini di dimensioni i due
database conterranno gli stessi dati del DBGP di simulazione, quindi la loro dimensione sarà
determinata dal contenuto della specifica di simulazione. Il risultato della validazione sarà la
creazione di un database di reportistica, ad oggi basato su Apache Derby, nel quale saranno
contenute tutte le informazioni relative alle segnalazioni rilevate durate la fase di validazione.
La quarta e ultima fase consentirà di produrre i report di validazione e i metadati di istanza
attraverso un componente da sviluppare. Questo componente avrà un grado di complessità
variabile in base alle funzionalità che si vuole fornire. Il generatore dei report e dei metadati
utilizzerà la struttura del database di reportistica, descritta in modo dettagliato nel documento
"Guida all’uso del GeoUML Validator"; potrebbe inoltre utilizzare anche i dati contenuti nel
database di simulazione e/o gli shapefile di aggiornamento. La funzionalità minima è la
generazione automatica del report utilizzando i template di jasper report (iReport) allegati al
Validator e la creazione di tutti i metadati di istanza e qualità secondo la struttura che deve ancora
essere definita ed inserita nella specifica.
Questo step minimale permetterebbe di ridurre i costi di sviluppo, ma lascerebbe all'operatore
l'onere di interpretare quali segnalazioni siano dipendenti dall'aggiornamento proposto e quali, pur
essendo riportate, sono estranee all'aggiornamento poiché causate da precedenti consegne. Lo
step minimale inoltre causerebbe l'aggiornamento nel DBGP di tutti i metadati di istanza di tutti le
istanze oggetto di validazione e non solo quelli oggetto di aggiornamento. Questo comportamento
può essere ovviato sviluppando un generatore di report e di metadati che sia in grado di filtrare le
violazioni selezionando solo quelle che coinvolgono le istanze aggiornate; questo algoritmo, a
prima vista molto semplice, può essere complicato e richiede un approfondimento.
Per la fase di sperimentazione si è deciso di definire quali errori bloccano un aggiornamento; a
seguito di questa definizione si procederà ad implementare un template di report sintetico al fine di
evidenziare all'utente la presenza di errori bloccanti

35/47
5.0 FASE SPERIMENTALE
Questo capitolo è dedicato alla descrizione di una fase intermedia di sperimentazione necessaria
per avviare gradualmente l’intero sistema consentendo così di apportare eventuali correzioni e
raffinare alcune scelte in corso d’opera.
Questa fase interesserà solo le Stazioni SIAT dei Bacini Montani (BM) e del servizio gestione
Risorse Idriche ed Energetiche dell’omonima Agenzia Provinciale (APRIE o ex-SUAP, Servizio
Utilizzazione Acque Pubbliche). La scelta è dovuta a diversi fattori, tra cui la recente
sperimentazione dei BM che ha sviluppato un sistema di gestione verticale basato su Oracle e il
fatto che i domini delle due stazioni sono attinenti e hanno punti di contatto.
5.1 Considerazioni comuni
Riassumiamo in questo paragrafo alcune considerazioni comuni alle due Stazioni.
5.1.1 VALIDAZIONE LOCALE
Ogni stazione sarà dotata di una funzionalità di validazione locale che sarà effettuata attraverso la
verifica delle specifiche locali.
In generale saranno definite delle viste sul modello fisico locale che esporranno il modello fisico di
validazione (quello prodotto dal GeoUML calogue). Da queste viste il GeoUML Validator, installato
localmente nella sua tradizionale configurazione desktop, preleverà i dati per trasferirli nel suo DBF
prima e nel DBN poi ed eseguire tutti i processi di validazione.
Per evitare di gravare eccessivamente sui servizi di database dell’infrastruttura tecnologica centrale
e considerando che gli SLA di questo servizio sono eccessivi ed inadeguati per un processo che
vede il DB PostGIS utilizzato non per conservare informazioni, ma più come componente
procedurale, si consiglia di configurare una workstation fisica locale alla Stazione dove effettuare
tale validazione.
Su questa workstation sarà quindi installato sia il Validator che il PostGIS utilizzato dal Validator
per il processo; essa dovrà inoltre essere configurata in rete con il DB locale e dovrà consentire al
Validator di accedere alle viste di validazione.
Queste ultime sono definite in modo da eliminare la profondità storica (sempre presente nello
schema fisico), ma potranno eseguire filtri anche su altre caratteristiche del dato (vedi ad esempio
il flag di pubblicazione spiegato oltre).
La specifica concettuale utilizzata per la validazione locale sarà quella del DB centrale,
limitatamente alla classi gestite dalla Stazione. Per evitare la proliferazione delle specifiche, è
possibile utilizzare direttamente la specifica centrale con l’effetto aggiuntivo che saranno segnalate
ovviamente come mancanti tutte le classi non gestite dalla Stazione.
La validazione locale potrà anche essere fatta con la specifica completa del DB locale, ovvero
quella che modella anche le informazioni peculiari della Stazione e non trasferite centralmente.
5.1.2 FLAG DI PUBBLICAZIONE
E’ possibile prevedere a livello di implementazione fisica locale la presenza di un flag (e la sua
corretta gestione applicativa) su ogni classe da conferire al DB centrale. Quando questo flag sarà
settato a “vero” l’oggetto corrispondente deve essere considerato come completato e pronto per
essere conferito al DBGP. I requisiti di gestione di questo flag sono:
- Irreversibilità del cambiamento di stato

36/47
- Storicizzazione particolare alla sua modifica (non va duplicato il record, ma va modificata la
data modifica per poterlo estrarre per il conferimento).
La gestione del flag di pubblicazione, se da una parte rende più flessibile il modo di lavorare di una
Stazione (è possibile pubblicare solo gli oggetti esplicitamente marcati pubblicabili e si possono
inserire oggetti non ancora completamente verificati senza rischiare di farli arrivare al DB centrale),
dall’altra porta parecchia complessità. Per fare un esempio, sarebbe opportuno che l’applicazione
di gestione offrisse funzionalità di verifica e di evidenziazione di quanti e quali sono gli oggetti in
bozza per non rischiare di non pubblicare dati definitivi, ma di cui ci si è scordati di modificare il
flag.
Per la fase sperimentale e considerando che sarà possibile inserirlo in futuro come estensione del
modello e delle funzionalità gestionali, si propone quindi di NON IMPLEMENTARE il flag di
pubblicazione,
5.1.3 PUBBLICAZIONE CON RICHIESTA ESPLICITA DELLA STAZIONE
Si prevede che l'invio degli aggiornamenti da una stazione al database provinciale avvenga
attraverso un'azione esplicita e non in modo automatico come ipotizzato inizialmente.
Ogni stazione dovrà quindi essere dotata di un "cruscotto" di comandi che permetta di eseguire
l'invio del dato attraverso un bottone. La procedura di invio, se non sono presenti altre richieste di
aggiornamento da parte della stessa stazione, reperirà le variazioni locali (inserimenti, modifiche e
cancellazioni) e le invierà al sistema di gestione degli aggiornamenti della provincia.
Il sistema di gestione degli aggiornamenti provinciale simulerà lo stato finale del DBGP applicando
ad una copia dello stato attuale del database provinciale gli aggiornamenti e, dopo aver eseguito la
validazione tramite il GeoUML validator, sottoporrà i risultati della validazione alla provincia che
dovrà approvare o rigettare l'aggiornamento.
Il "cruscotto" per l'invio dell'aggiornamento dovrà inoltre essere dotato della funzionalità di
simulazione, la quale segue la stessa procedura dell'aggiornamento ma invia i report di validazione
alla sola stazione e senza richiedere alcuna approvazione della provincia.
5.1.4 PUBBLICAZIONE ULTIMO STADIO OGGETTI
La procedura di aggiornamento provvederà ad inviare solo e tutti gli oggetti hanno subito un
qualsiasi tipo di aggiornamento. Verranno quindi inviate tutte le istanze degli oggetti inseriti,
aggiornati e cancellati.
La regola precedentemente enunciata che definisce l'invio dell'aggiornamento non è sufficiente a
definire che cosa inviare poiché è necessario stabilire come comportarsi qualora un oggetto
subisca più di una variazione nel lasso intercorso tra due aggiornamenti; in un caso come questo si
è deciso di inviare solo l'ultimo stadio degli oggetti.
Di seguito fatto un esempio di invio degli aggiornamenti che prenda in considerazione anche i casi
"dubbi" al fine di fornire una regola di gestione per chiarificare l'affermazione precedente.
Una stazione all' istante T1 decide di inviare i propri dati (prima adesione) database provinciale,
nel database della stazione sono presenti solo gli oggetti A,B e C tutti creati all'istante T0.
Tutti gli oggetti del database rappresentano degli edifici e hanno due attributi (altezza e uso
prevalente) entrambi condivisi con la base di dati provinciale.
Le tabelle che esemplificano i dati hanno l’intestazione azzurra per quelli presenti sul DB di
stazione e verde quelli del DB centrale provinciale. In giallo sono rappresentati i dati trasmessi per
il conferimento.

Documento Inquadramento Generale del Database Geografico Provinciale

Documento Inquadramento Generale del Database Geografico Provinciale

Recommended

Recommended

More Related Content

What's hot

What's hot (16)

Viewers also liked

Viewers also liked (11)

Similar to Documento Inquadramento Generale del Database Geografico Provinciale

Similar to Documento Inquadramento Generale del Database Geografico Provinciale (20)

More from PAT

More from PAT (6)

Recently uploaded

Recently uploaded (6)

Documento Inquadramento Generale del Database Geografico Provinciale