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

Validazione localeGestione

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

GestioneETL

fruizione

locale

DM

locale

Sistema

fruizione

locale

Stazione 1

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

dati specifici di

stazione

SCSstaz

DBGP

Servizi di 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

Estrazione e

trasformazioneshapefile

Sistema

verticale

legacyDB legacy

DBGP

Servizi di 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

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

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.

37/47

Id istanza Id oggetto Data ini Data fin Altezza Uso prevalente

1 A T0 null 10 Commerciale

2 B T0 null 30 Residenziale

3 C T0 null 30 Residenziale

Tabella 2 - DBGS all'istante T1

La stazione, avendo inviato i propri dati alla provincia, all'istante T1 è perfettamente riallineata al database provinciale, riportato qui sotto.

Id istanza Id oggetto Data ini Data fin Data mod Altezza Uso prevalente

1001 A T0 null T1 10 Commerciale

1002 B T0 null T1 30 Residenziale

1003 C T0 null T1 30 Residenziale

Tabella 3 - DBGP all'istante T1

All'istante T2 l'oggetto A subisce una variazione di altezza (da 10 a 20) l'oggetto B viene cancellato e viene inserito l'oggetto D con altezza 10 e uso Residenziale; lo stato del database di stazione sarà quindi il seguente:

Id istanza Id oggetto Data ini Data fin Altezza Uso prevalente

1 A T0 T2 10 Commerciale

2 B T0 T2 30 Residenziale

3 C T0 null 30 Residenziale

4 A T2 null 20 Commerciale

5 D T2 null 10 Residenziale

Tabella 4 - DBGS all'istante T2

All'istante T3 la stazione decide di inviare l'aggiornamento in provincia, quindi dovrà notificare una cancellazione, un inserimento e un aggiornamento. Di seguito sono riportati, in forma tabellare, gli oggetti da inviare con la relativa azione:

Azione Id oggetto Data ini Data fin Altezza Uso prevalente

Modifica A T2 null 20 Commerciale

Cancellazione B T0 T2 30 Residenziale

Inserimento D T2 null 10 Residenziale

Tabella 5 - Aggiornamento inviato dal DBGS all'istante T3

Recepito l'aggiornamento il database provinciale conterrà le seguenti tuple:

Stazione Provincia conferimento

38/47

Id istanza Id oggetto Data ini Data fin Data mod Altezza Uso prevalente

1001 A T0 T2 T3 10 Commerciale

1002 B T0 T2 T3 30 Residenziale

1003 C T0 null T1 30 Residenziale

1051 A T2 null T3 20 Commerciale

1052 D T2 null T3 10 Residenziale

Tabella 6 - DBGP all'istante T3

Il caso precedente si riferisce al tipo di aggiornamento più semplice possibile; affrontiamo ora i possibili casi problematici.

Aggiornamento multiplo

Di seguito si vuole mostrare come gestire il caso in cui un oggetto subisca più di un aggiornamento nell'intervallo di tempo che intercorre tra l'invio di due aggiornamenti. Al tempo T4 l'oggetto D subisce una variazione di altezza (da 10 a 20) e al tempo T5 sempre l'oggetto D subisce un'ulteriore variazione di altezza (da 20 a 40) ; lo stato del database di stazione sarà quindi il seguente:

Id istanza Id oggetto Data ini Data fin Altezza Uso prevalente

1 A T0 T2 10 Commerciale

2 B T0 T2 30 Residenziale

3 C T0 null 30 Residenziale

4 A T2 null 20 Commerciale

5 D T2 T4 10 Residenziale

6 D T4 T5 20 Residenziale

7 D T5 null 40 Residenziale

Tabella 7 - DBGS all'istante T5

All'istante T6 la stazione decide di inviare l'aggiornamento in provincia, quindi dovrà notificare l'aggiornamento dell'oggetto D; in realtà l'oggetto D ha subito due modifiche ma si vuole inviare solo l'ultimo stato dell'oggetto. Di seguito sono riportati, in forma tabellare, gli oggetti da inviare con la relativa azione:

Azione Id oggetto Data ini Data fin Altezza Uso prevalente

Modifica D T5 null 40 Residenziale

Tabella 8 - Aggiornamento inviato dal DBGS all'istante T6

Recepito l'aggiornamento il database provinciale conterrà le seguenti tuple:

Id istanza Id oggetto Data ini Data fin Data mod Altezza Uso prevalente

1001 A T0 T2 T3 10 Commerciale

1002 B T0 T2 T3 30 Residenziale

1003 C T0 null T1 30 Residenziale

1051 A T2 null T3 20 Commerciale

39/47

1052 D T2 T5 T6 10 Residenziale

1060 D T5 null T6 40 Residenziale

Tabella 9 - DBGP all'istante T6

Aggiornamento e cancellazione

Di seguito si vuole mostrare come gestire il caso in cui un oggetto subisca un aggiornamento e la cancellazione nell'intervallo di tempo che intercorre tra l'invio di due aggiornamenti. Al tempo T7 l'oggetto D subisce una variazione di altezza (da 40 a 50) e al tempo T8 sempre l'oggetto D viene cancellato ; lo stato del database di stazione sarà quindi il seguente:

Id istanza Id oggetto Data ini Data fin Altezza Uso prevalente

1 A T0 T2 10 Commerciale

2 B T0 T2 30 Residenziale

3 C T0 null 30 Residenziale

4 A T2 null 20 Commerciale

5 D T2 T4 10 Residenziale

6 D T4 T5 20 Residenziale

7 D T5 T7 40 Residenziale

8 D T7 T8 50 Residenziale

Tabella 10 - DBGS all'istante T8

All'istante T9 la stazione decide di inviare l'aggiornamento in provincia, quindi dovrebbe notificare l'aggiornamento e la cancellazione dell'oggetto D; ma poichè l'oggetto D è stato cancellato sarà notificato solo questa ultima variazione di stato. Di seguito sono riportati, in forma tabellare, gli oggetti da inviare con la relativa azione:

Azione Id oggetto Data ini Data fin Altezza Uso prevalente

Modifica D T5 T8 40 Residenziale

Tabella 11 - Aggiornamento inviato dal DBGS all'istante T9

Recepito l'aggiornamento il database provinciale conterrà le seguenti tuple:

Id istanza Id oggetto Data ini Data fin Data mod Altezza Uso prevalente

1001 A T0 T2 T3 10 Commerciale

1002 B T0 T2 T3 30 Residenziale

1003 C T0 null T1 30 Residenziale

1051 A T2 null T3 20 Commerciale

1052 D T2 T5 T6 10 Residenziale

1060 D T5 T8 T9 40 Residenziale

Tabella 12- DBGP all'istante T9

Inserimento ed aggiornamento

Di seguito si vuole mostrare come gestire il caso in cui si inserisca un nuovo oggetto e venga effettuato una modifica all'oggetto stesso nell'intervallo di tempo che intercorre tra l'invio di due

40/47

aggiornamenti. Al tempo T10 viene inserito l'oggetto E come edificio commerciale di altezza 15 e al tempo T11 subisce una variazione di uso (da Commerciale a Residenziale); lo stato del database di stazione sarà quindi il seguente:

Id istanza Id oggetto Data ini Data fin Altezza Uso prevalente

1 A T0 T2 10 Commerciale

2 B T0 T2 30 Residenziale

3 C T0 null 30 Residenziale

4 A T2 null 20 Commerciale

5 D T2 T4 10 Residenziale

6 D T4 T5 20 Residenziale

7 D T5 T7 40 Residenziale

8 D T7 T8 50 Residenziale

9 E T10 T11 15 Commerciale

10 E T11 null 15 Residenziale

Tabella 13 - DBGS all'istante T11

All'istante T12 la stazione decide di inviare l'aggiornamento in provincia, quindi dovrebbe notificare l'inserimento e l'aggiornamento dell'oggetto E; ma poichè l'oggetto E al tempo T9 (istante in cui è stato inviato l'ultimo aggiornamento) non era presente sarà notificato solo l'inserimento. Di seguito sono riportati, in forma tabellare, gli oggetti da inviare con la relativa azione:

Azione Id oggetto Data ini Data fin Altezza Uso prevalente

Modifica E T10 null 15 Residenziale

Tabella 14 - Aggiornamento inviato dal DBGS all'istante T12

Recepito l'aggiornamento il database provinciale conterrà le seguenti tuple:

Id istanza Id oggetto Data ini Data fin Data mod Altezza Uso prevalente

1001 A T0 T2 T3 10 Commerciale

1002 B T0 T2 T3 30 Residenziale

1003 C T0 null T1 30 Residenziale

1051 A T2 null T3 20 Commerciale

1052 D T2 T5 T6 10 Residenziale

1060 D T5 T8 T9 40 Residenziale

1071 E T10 null T12 15 Residenziale

Tabella 15- DBGP all'istante T12

Inserimento, aggiornamento e cancellazione

Di seguito si vuole mostrare come gestire il caso in cui si inserisca un nuovo oggetto, venga effettuato una modifica all'oggetto stesso ed infine venga cancellato dal database di stazione; il tutto nell'intervallo di tempo che intercorre tra l'invio di due aggiornamenti. Al tempo T13 viene inserito l'oggetto F come edificio commerciale di altezza 45 e al tempo T14 subisce una variazione

41/47

di altezza (da 45 a 65) e al tempo T15 viene eliminato dal database; lo stato del database di stazione sarà quindi il seguente:

Id istanza Id oggetto Data ini Data fin Altezza Uso prevalente

1 A T0 T2 10 Commerciale

2 B T0 T2 30 Residenziale

3 C T0 null 30 Residenziale

4 A T2 null 20 Commerciale

5 D T2 T4 10 Residenziale

6 D T4 T5 20 Residenziale

7 D T5 T7 40 Residenziale

8 D T7 T8 50 Residenziale

9 E T10 T11 15 Commerciale

10 E T11 null 15 Residenziale

11 F T13 T14 45 Commerciale

12 F T14 T15 65 Commerciale

Tabella 16 - DBGS all'istante T15

All'istante T16 la stazione decide di inviare l'aggiornamento in provincia, quindi dovrebbe notificare l'inserimento e l'aggiornamento e la cancellazione dell'oggetto E. L'oggetto E al tempo T15 non risulta essere attivo e al tempo T12 (istante in cui è stato inviato l'ultimo aggiornamento) non era presente nel database; quindi non è necessario inviare alcun update al database centrale.

5.1.5 PECULIARITÀ SUPPORTO TIPI DI DATO

Occorre una revisione della specifica per i tipi booleani, da sostituire con enumerati, a causa della non gestione da parte di ArcGIS. Questa revisione potrà essere applicata direttamente alla specifica centrale senza perdere di generalità ed evitando così la moltiplicazione delle specifiche.

5.1.6 SINTESI DEGLI ARTEFATTI GEOUML

Il lavoro di modellazione e revisione della modellazione a supporto della fase sperimentale produrrà i seguenti artefatti (SCS) mediante Catalogue:

1. SCS globale del DBGP (revisione dell’attuale per introdurre semplificazioni e modifiche richieste dalle stazioni.

2. SCS di stazione APRIE con vincoli trasversali (sia quelli che interessano gli oggetti di BM che altre stazioni non oggetto della sperimentazione) da utilizzare per la simulazione di validazione (ritaglio della SCS globale con mantenimento dei vincoli trasversali)

3. SCS di stazione BM con vincoli trasversali (sia quelli che interessano gli oggetti di APRIE che altre stazioni non oggetto della sperimentazione) da utilizzare per la simulazione di validazione (ritaglio della SCS globale con mantenimento dei vincoli trasversali).

4. SCS di stazione APRIE senza vincoli trasversali da utilizzare per la validazione locale. 5. SCS di stazione BM vincoli trasversali da utilizzare per la validazione locale.

Oltre ai file SCS, dovranno essere prodotte le DDL per creare gli schemi fisici dei DB. In particolare si dovranno definire in ambiente PostGIS:

42/47

1. La DDL globale, costituita dalle DDL prodotte dal Catalogue e da quelle prodotte manualmente per supportare le caratteristiche non integrabili nel modello concettuale.

2. La DDL del DB di stazione di APRIE. Questa DDL sarà ricavata direttamente dalle rispettive specifiche concettuali per cui sarà costituita da due componenti che dovranno essere ben distinte: la DDL prodotta dal Catalogue e la DDL di “personalizzazione” che introduce le specificità del modello di gestione.

3. DDL del DB di stazione BM. Per questo specifico caso, le DDL rispecchieranno esattamente l’attuale schema del DB legacy gestito in Oracle. Per la validazione e l’estrazione basterà poi definire opportune viste (in questa fase di analisi è stata verificata la reale fattibilità di queste viste sia in un porting di test su PostGIS dei dati contenuti in Oracle).

5.2 Bacini Montani

5.2.1 SITUAZIONE ATTUALE

Il servizio Bacini Montani gestisce l’idrografia. E’ stato oggetto di una sperimentazione che ha portato allo sviluppo di un’applicazione di gestione basata su Oracle (ModHydro). E’ stata proprio tale sperimentazione che ha condotto ad optare per l’implementazione PostGIS per tutti i DB del sistema DBGP/DBGS (come indicato nei requisiti generali del sistema), viste le ridotte performance sperimentate in ambiente Oracle. Di conseguenza anche il DB del’idrografia e la relativa applicazione di gestione dovranno essere modificati.

L’entità geografica principale è la tratta di corso d’acqua naturale o artificiale. Sono poi gestiti anche i bacini idrografici e i laghi.

Nella gestione del reticolo idrografico non sono trattati i nodi, seppure la connettività tra tratte sia garantita.

E’ implementata una gestione storica applicativa attraverso una tabella ausiliaria (*_S) associata alle entità principali che viene popolata con i record storicizzati, eliminati quindi dalla tabella degli oggetti “attuali”. Questa scelta implementativa è motivata soprattutto da considerazioni di performance, per alleggerire la cardinalità della tabella degli oggetti vigenti.

La codifica delle tratte è abbastanza complessa perché dovuta al retaggio della gestione non informatizzata. In particolare la chiave di una tratta è costituita secondo la seguente convenzione:

BAC SBAC1 SBAC2 ASTA TRONCO TRATTA SUB

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

A 3 Z 1 A 3 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1

BAC = Bacino idrografico

SBAC1 = Sottobacino di primo livello (concatenato a BAC rappresenta l’identificativo dell’entità)

SBAC2 = Sottobacino di secondo livello (concatenato a BAC e SBAC1 rappresenta l’identificativo dell’entità)

ASTA = Identificativo dell’asta (univoco all’interno del bacino)

TRONCO = Identificativo del tronco (all’interno dell’asta)

TRATTA = Identificativo della tratta (all’interno del tronco)

E’ quindi una codifica cosiddetta “parlante” che riporta implicitamente le informazioni di associazione coi bacini, le aste e il tronco di appartenenza. Gli ultimi 4 caratteri sono stati introdotti

43/47

per ovviare ad un passato errore di gestione dove non erano state rinumerate tratte spezzate da una confluenza e garantire quindi l’univocità della chiave.

L’applicazione di gestione è basata su ArcMap, ma comprende anche molto codice PL/SQL legato strettamente al DBMS.

5.2.2 MODELLO DEL DATABASE

L’entità fondamentale del sistema è la tratta di corso d’acqua che corrisponde all’elemento di mezzeria che corre da un nodo all’altro (anche se non gestiti esplicitamente).

Nelle specifiche del modello concettuale l’elemento principale invece è il tronco e la tratta è rappresentata invece da un attributo a tratti, o meglio da un insieme omogeneo di attributi a tratti.

Nel sistema dei BM il tronco non viene quindi gestito esplicitamente, ma ogni tratta è attribuita ad un tronco.

A livello concettuale c’è quindi corrispondenza tra i due modelli e si può mantenere l’attuale modello fisico del sistema dei BM e ricavare la geometria dei tronchi attraverso operatori geometrici del database (ST_LineMerge) e ricondurre in generale il modello fisico a quello derivante dalle specifiche concettuali attraverso opportune viste.

Un intervento utile, ma non strettamente necessario15 riguarda l’utilizzo del meccanismo attuale di codifica “parlante”. Essendo l’appartenenza ad un’asta codificata all’interno dell’identificativo, risulta impossibile riassegnare ad un’altra asta una tratta una volta che è stata creata. Questo ha portato, ad esempio, a trasferire il nome dell’asta a livello di tratta per poter gestire al meglio situazione del genere. Si suggerisce di mantenere comunque i vecchi identificativi (ad essi o a parte di essi sono associate informazioni cartacee) e di trasferire le informazioni ivi codificate in specifici attributi attraverso i quali implementare le relazioni con i bacini, sottobacini di primo e secondo livello, il tronco e l’asta; il meccanismo di generazione dell’identificativo può essere anche mantenuto per i nuovi inserimenti (se si vuole per mantenere l’omogeneità), ma si evidenzia che potrebbe essere fuorviante e portare a ricavare relazioni da porzioni di codice che invece non hanno più quel significato.

Per la fase di sperimentazione si è deciso di non applicare alcuna modifica al sistema di generazione e gestione degli identificativi; mantenendo quindi le limitazioni evidenziate durante la riunione con i bacini montani. Qualsiasi variazione del modello fisico della stazione è eventualmente demandata a fasi successive. Le geometrie delle aste possono essere ricostruite attraverso procedure automatiche sia nel DB centrale che in quello locale alla stazione.

Le enumerazioni utilizzate al momento si differenziano leggermente da quelle già inserite nel Catalogue (sono subentrate alcune nuove esigenze), che dovrà essere aggiornato in tal senso.

Le altre entità geografiche previste dal modello sono:

• Bacini idrografici • Laghi • Alvei

Per le prime due non ci sono differenze notevoli con l’implementazione fisica che deriva dal modello concettuale del Catalogue (a parte la gestione degli identificativi, come già detto); gli alvei non sono ancora entrati in gestione per cui non sussistono problemi. 15 In generale gli identificativi che veicolano altre informazioni oltre a giocare il ruolo di individuare univocamente un’entità sono da evitare perché destinati a non essere persistenti. Un esempio tipico è il codice ISTAT comunale che cambia nei rari, ma non pochi casi in cui un Comune passa da una Provincia ad un’altra od ad una nuova.

44/47

I nodi, che non sono gestiti, potranno essere ricostruiti nel DB centrale con la sola finalità di estrarre questa informazione per il conferimento al National Core (sarebbe chiaramente solo un espletamento di un formalità perché nessuna informazione importante è associata esplicitamente a queste entità dal gestore del dato).

5.2.3 STORICIZZAZIONE

La stazione ha implementato un meccanismo di storicizzazione per risolvere due casi d’uso emersi dai requisiti degli utenti:

• Ricostruire la rete idrica ad una certa data. • Consultare puntualmente la situazione precedente di una certa tratta.

Da notare che funzionalmente questi casi d’uso non hanno ancora una specifica implementazione nell’applicazione di gestione.

Il modello dati attuale prevede il trasferimento in una tabella storica di tutti i record delle entità geografiche che cessano la loro esistenza a causa di modifiche ai propri attributi o per la cessazione in vita dell’entità reale corrispondente; questa strategia di memorizzazione dello storico non crea alcun problema in fase di stesura della specifica concettuale poiché il GeoUML catalogue documenta uno snapshot dei dati e non la sua evoluzione storica.

Il GeoUML Validator utilizzato per la validazione dei soli dati attuali ignorerà tutte le tabelle contenenti i dati storici (poiché non documentate dal GeoUML catalogue).

Lo schema fisico progettato dalla stazione Bacini Montani contiene un'autorelazione sull'entità tratta introdotta per tener traccia dei legami "padri"-"figli" a seguito di operazioni di split o merge. Questo tipo di relazione associa più oggetti di tipo tratta, ma a differenza di una classica associazione tra oggetti (della stessa classe o di classe diverse) ad un certo istante di tempo questa relazione ha una profondità temporale. La relazione implementata associa sempre uno o più oggetti generati dalla cessazione di uno o più oggetti attivi in precedenza; questo implica che la validazione di tale tipo di associazione richiede l'esame di tutti i dati (attivi e storicizzati). Questa particolarità non permette l'inserimento dell'associazione nel GeoUML catalogue.

5.2.3.1 Cosa storicizzare

Altra considerazione importante è su quali tipi di modifiche applicare la storicizzazione: valutazioni sulla semplicità di implementazione ci portano a suggerire di non fare distinzioni e storicizzare sempre e comunque, qualsiasi attributo venga modificato. Non facciamo quindi distinzioni fra modifiche di attributi interni (specifici della stazione) o di attributi da trasferire nel DB centrale.

5.2.3.1 Corrispondenza tra storicità locale e centrale

Si propone di utilizzare la data della trasformazione come data fine o data inizio della feature e di far corrisponderle quindi ai relativi attributi del DB centrale. Nel modello del DB centrale abbiamo però anche una “data modifica”: essa può essere valorizzata con la data in cui viene applicato l’aggiornamento nel DB centrale.

5.2.1 PUBBLICAZIONE

Si propone di selezionare per il conferimento al DB centrale solamente l’ultimo stadio di ciascun oggetto, trascurando quelli che si sono eventualmente succeduti dall’ultimo conferimento a quello in corso.

45/47

In particolare per le cessazioni sarà inviata la tupla con la data fine nulla, mentre i record nati e morti all’interno di un intervallo di sincronizzazione non vengono conferiti.

Come risultato sul singolo oggetto si potrà avere un diversa profondità storica con la presenza di un numero differente di istanze (o stadi) nel DB centrale e in quello di stazione.

5.3 Agenzia Provinciale Risorse Idriche ed Energetiche

5.3.1 SITUAZIONE ATTUALE

APRIE gestisce le infrastrutture acquedottistiche provinciali; in particolare gestisce la rete di adduzione ed è in corso il passaggio di competenze per la gestione delle reti di distribuzione fino ad ora in carico ai Comuni.

I dati cartografici sono gestiti su shapefile attraverso strumenti ESRI (ArcGIS), mentre i dati alfanumerici sono conservati e mantenuti in un DB MS Access con una relativa applicazione (RISI) costituita essenzialmente da form per editare gli attributi delle entità. Il RISI consente di collegare fotografie oltre a informazioni semplici. L’aggancio delle informazioni alfanumeriche con gli oggetti GIS è fatto solo tramite codice, ma fondamentalmente i DB sono separati.

Le entità cartografiche in gestione sono:

• Tratti idrici • Nodi idrici • Aree di utenza

di cui solo le prime due sono state identificate di importanza trasversale e per le quali esistono delle entità corrispondenti previste dalle specifiche nazionali.

Altre entità gestite dal RISI (solo come anagrafica, senza geometria direttamente collegata) sono:

• Acquedotto (un codice a cui sono assegnati tutti gli elementi della rete e a cui corrisponde essenzialmente l’informazione del soggetto gestore)

• Soggetto gestore

Al momento APRIE gestisce le reti di adduzione dell’acqua, ma è in corso il conferimento da parte de Comuni delle reti di distribuzione che saranno quindi gestite dall’Agenzia.

APRIE ha confermato di aver appaltato la realizzazione di un nuovo gestionale che sostituirà il RISI per la gestione delle reti di 50 comuni della Provincia Autonoma di Trento; ad oggi la prima versione dell'applicativo avrà le seguenti limitazioni:

• la persistenza degli identificativi relativi a tratti e nodi idrici non è assicurata

• non viene mantenuta alcun dato storico

• non è assicurata alcuna ripartizione della rete su base comunale

Il nuovo applicativo permetterà il download dei dati tramite servizi WFS; tali servizi dovranno quindi essere utilizzati come sorgente dati per popolare il database locale della stazione.

5.3.2 MODELLO DEL DATABASE

Le aree di utenza possono entrare nel DB centrale e, visto che nelle specifiche nazionali non esistono entità corrispondenti, potranno essere modellate liberamente. La geometria di queste aree è costituita da poligoni multiparte in 3D. In questi casi si consiglia di inserire nel database un trigger, scatenato in fase di inserimento, che trasformi in multiparte la geometria proveniente dall’operazione di disegno: in questo modo si evitano possibili situazioni di errore nel caso un poligono semplice non sia accettato in una colonna geometrica dichiarata multiparte.

46/47

Le geometrie delle altre entità geografiche sono punti in 3D e curve semplici in 3D rispettivamente per nodi e tratti idrici. I nodi non possono essere isolati e la tratta è sempre chiusa tra due nodi.

I nodi della rete di adduzione sono di sette tipologie differenti:

• nodo di approvvigionamento: Da sorgente, • nodo di approvvigionamento: Da pozzo, • nodo di approvvigionamento: Da acqua superficiale. • serbatoi, • impianti di trattamento, • pompaggi, • prelievo (contatto fra acquedotti).

Queste sette tipologie di nodo hanno attributi differenti e sono gestiti al momento come se fossero classi distinte. Per ricondurre il modello fisico a quello derivante dal modello concettuale, basta definire queste sette classi come sottoclassi di una classe astratta dove far confluire gli attributi comuni (oltre alla geometria abbiamo soltanto il materiale).

Il nodo di approvvigionamento è collegato ad un corso d’acqua o ad un lago o ad una sorgente.

Per i nodi di distribuzione la situazione è simile, anche se le tipologie sono solamente tre:

• Pozzetti • Utenze • Punti di passaggio

Come dettaglio dell’implementazione fisica sarà necessario usare una sequence del database per attribuire un unico ID anche se utilizzato da 7 tabelle differenti. Considerando anche la rete di distribuzione arriviamo a 11 sottoclassi. Per rendere il modello più pulito si può introdurre due sottoclassi intermedie che rappresentano la macrotipologia di nodo: adduzione o distribuzione.

5.3.3 RELAZIONI ENTITÀ ESTERNE ALLA STAZIONE

Sorgente e nodo di captazione sono due classi differenti con geometrie di solito coincidenti. Anche il pozzo non è un nodo idrico, ma è una classe a parte collegata ad un nodo di captazione.

Le sorgenti sono di competenza del Servizio Geologico, ma alcune volte, proprio perché collegate ai nodi di captazione, vengono inserite provvisoriamente da APRIE. In pochissimi casi APRIE chiama sorgenti alcuni drenaggi che non sono vere e proprie sorgenti per i geologi; per risolvere questo unico problema si potrebbe inserire un nuovo valore del dominio enumerato della tipologia della classe sorgente (anche nel modello centrale) così si potrebbero distinguere le sorgenti di “drenaggio”.

Di fatto sono tre le entità convergenti sulla sorgente: la sorgente stessa, l’opera di captazione e la concessione. Il geologico dà il codice alla sorgente, le altre sono gestite da APRIE. La sorgente è un nodo idrico nel modello centrale (nel modello centrale gli attributi sono: materiale, stato, ubicazione, profondità).

5.3.4 ATTRIBUTI MULTIVALORE

La tipologia stessa di un nodo è multi valore; questo vale soprattutto per la distribuzione, ma anche per l’adduzione. E’ possibile, ad esempio, avere un nodo che sia contemporaneamente di captazione e di trattamento. Siccome l’attributo “tipologia” è quello che serve a distinguere le sottoclassi, si potrebbe gestire il caso in maniera più formalmente corretta creando delle sottoclassi non disgiunte. La complessità di gestione aumenterebbe molto per cui definiamo una tipologia prevalente e prevediamo gli attributi principali delle eventuali tipologie coincidenti (la situazione più complicata è la coincidenza di captazione-serbatoio-trattamento-connessione). Questi attributi

47/47

vanno definiti come opzionale perché devono essere nulli quando non c’è coincidenza tra sottoclassi. Se, ad esempio, se una captazione è anche serbatoio, allora diventa obbligatorio l’attributo volume.

5.3.5 STORICITÀ

Durante la sperimentazione si popolerà il database utilizzando i servizi WFS offerti dall'applicativo che sostituirà il RISI; tale applicativo, come detto in precedenza, non gestisce né la storicità né la persistenza degli identificativi quindi si è deciso di sovrascrivere tutti i dati ad ogni estrazione. Questa sovrascrittura implementerà un meccanismo base di storicizzazione che possiamo considerare totalmente allineato all'approccio della storicizzazione definito a livello centrale. Saranno definite infatti tre date (data inizio, data fine, data di aggiornamento) e ad ogni prelievo dati effettuato tramite WFS si valorizzerà la data di fine validità di tutti i dati già presenti nella base dati e si inseriranno i nuovi dati con la sola data di inizio validità valorizzata.

La data di aggiornamento è stata inserita per usi futuri poiché avrebbe la funzione di tener traccia dell'istante in cui si sono scaricati i dati dal WFS, ad oggi potrebbe non essere popolata o assumere lo stesso valore della data inizio. Questo approccio permette di ricostruire lo stato del database ad una certa data; ovviamente la ricostruzione ha un delta di incertezza poiché le modifiche avvengono nell'intervallo di tempo che intercorre tra due aggiornamenti e non nell'istante in cui avviene l'aggiornamento del database. Come si è detto l'applicativo non assicura la persistenza degli identificativi per questo gli identificativi degli oggetti saranno sempre ricalcolati tramite una “sequence” di DBMS al fine di essere sicuri del mantenimento dell'univocità.

L'approccio e la struttura di storicizzazione sopra definiti sono stati progettati per supportare degli aggiornamenti dall'applicativo che sostituirà il RISI, infatti qualora questo applicativo dovesse gestire la storicità del dato e la persistenza degli identificativi, la struttura fisica delle tabelle non subirà variazioni, ma si dovrà solo aggiornare il tool che permette di riversare nel database di stazione i dati prelevati dai WFS. La struttura di storicità è stata definita per essere pienamente compatibile ai dati dall'applicativo che sostituirà il RISI, ma si è cercato di definirla in modo che possa gestire agevolmente dati provenienti da altre fonti poiché l'applicativo gestirà i dati solo di una parte dei comuni della provincia

5.3.6 PUBBLICAZIONE

La modalità di pubblicazione ritenuta migliore è quella attivata volontariamente dalla Stazione. Potrà esserci ovviamente un invio di simulazione (su una macchina fisica dove sarà replicato il db centrale e lanciata la validazione).

Poi un invio vero e proprio per l’applicazione degli aggiornamenti al DB centrale.

5.3.7 DIFFERENZA TRA SCHEMA FISICO DI VALIDAZIONE E SCHEMA FISICO DI GESTIONE

Riassumendo la differenza tra schema fisico di gestione e schema fisico di validazione riguarda i seguenti punti:

• Storicità • Attributi multi valore (da evidenziare con analisi specifica) • Trigger per multiparte