Provincia Autonoma di Trento
Data Base Geografico della Provincia Autonoma di Trento
Inquadramento del sistema DBGP
Versio...
2/47
Revisioni
Data Rev Contenuto revisione Autore
16/04/2013 1.0 Stesura definitiva Segreteria SIAT
Sommario
1.0 AMBITO.....
3/47
3.6.2 Architettura di una stazione PAT con preesistente sistema verticale....................... 22
4.0 FLUSSI..........
4/47
Figura 3 - Relazione tra GeoUML Catalogue e Validator............................................................ 12
...
5/47
Modello concettuale = v. Schema Concettuale o Specifica di Contenuto
Modello implementativo = insieme di regole che p...
6/47
1.0 AMBITO
Il presente documento ha lo scopo di descrivere l’impostazione architetturale del sistema del
DataBase Geo...
7/47
verificarsi competenze sovrapposte sulle medesime informazioni. Tali situazioni vanno intese come
eccezioni e sono da...
8/47
2.5 Storicità dei DB locali
La gestione della storicità dei DB locali può essere differente da stazione a stazione e ...
9/47
2.11 Compatibilità software di stazione con strumenti GIS open source
E’ importante che il sistema di stazione sia co...
10/47
2.16 Architettura estendibile a “comuni” o “comunità di valle” come
aggiornatori (soggetti esterni)
Alcune informazi...
11/47
In questa architettura in cui i dati si trovano replicati localmente e centralmente, il DBGP gioca il
ruolo di datab...
12/47
3.1 Il GeoUML Catalogue e Validator
Considerando il fatto che per la definizione delle specifiche di contenuto del D...
13/47
Oracle
PostGIS
o Multigeometria
Oracle
La componente software che produce questi modelli implementativi è realizzata...
14/47
Anche per il DB centrale, che è di fruizione, avremo un certo “gap”, ma sarà limitato in generale al
supporto della ...
15/47
3.2 Il database centrale di gestione
La struttura del database centrale potrà, in prima istanza, essere derivata dir...
16/47
e contenitori molto diversi in base al servizio da offrire, per cui soprattutto per il componente
indicato in Figura...
17/47
La validazione locale riguarda solo la porzione di dati gestita all’interno di una stazione e non
contempla le relaz...
18/47
Figura 4 - Datamart dipendenti
Nella Figura 5, invece, abbiamo un esempio di modello a “datamart indipendenti”, dove...
19/47
• non esiste un vero e proprio Data Warehouse centrale propriamente detto,
• ma esiste di fatto un unico DB operazio...
20/47
La prima fase da intraprendere per rendere operativo il flusso dati da e per una stazione PAT (e
più genericamente u...
21/47
permettere una validazione completa dei dati locali poiché sarebbero verificati tutti i vincoli
intraclasse i quali ...
22/47
Da notare che il DBGS è parte del DB locale di stazione14
: in altre parole lo schema dei dati
specifici di stazione...
23/47
occorre fare ragionamenti sulle istanze degli oggetti per poter inviare solamente quello che è
variato. Nel caso più...
24/47
hoc nella quale siano presenti tutti e solo i vincoli che coinvolgono le classi la cui gestione è
demandata alla sta...
25/47
Si ritiene necessario esplorare alcune possibili variazioni al flusso sopra illustrato al fine di
permettere l'invio...
26/47
4.1.1 COMPONENTI NECESSARI PER L'INVIO DI UN AGGIORNAMENTO DA UNA STAZIONE
SPROVVISTA DI BASE DI DATI STRUTTURATA
Pe...
27/47
traducendo i dati shapefile in operazioni di cancellazione, inserimento ed aggiornamento.
Effettuate le operazioni, ...
28/47
potrebbe essere necessario l'adozione di complessi componenti software (ETL ad-hoc e database
pro validazione ed esp...
29/47
• Definizione della struttura fisica della base di dati di stazione. A differenza della struttura
fisica di una staz...
30/47
poter valutare le relazioni con gli altri dati inseriti nel database. Se l'aggiornamento fosse inviato
sotto forma d...
31/47
4.3.1 COMPONENTI NECESSARI PER IL RECEPIMENTO DI UN AGGIORNAMENTO DA PARTE DEL
SISTEMA INFORMATIVO PROVINCIALE
Per r...
32/47
dalla provincia quindi variando il destinatario potrebbe essere necessario apportare delle
modifiche.
• Definizione ...
33/47
Il servizio di simulazione sarà invocato da una stazione la quale invierà il "delta" aggiornamento
(solo le modifich...
34/47
oggetti da modificare, inserire e cancellare. Propedeutica per l'applicazione dell'aggiornamento è la
presenza degli...
35/47
5.0 FASE SPERIMENTALE
Questo capitolo è dedicato alla descrizione di una fase intermedia di sperimentazione necessar...
36/47
- Storicizzazione particolare alla sua modifica (non va duplicato il record, ma va modificata la
data modifica per p...
Documento Inquadramento Generale del Database Geografico Provinciale
Documento Inquadramento Generale del Database Geografico Provinciale
Documento Inquadramento Generale del Database Geografico Provinciale
Documento Inquadramento Generale del Database Geografico Provinciale
Documento Inquadramento Generale del Database Geografico Provinciale
Documento Inquadramento Generale del Database Geografico Provinciale
Documento Inquadramento Generale del Database Geografico Provinciale
Documento Inquadramento Generale del Database Geografico Provinciale
Documento Inquadramento Generale del Database Geografico Provinciale
Documento Inquadramento Generale del Database Geografico Provinciale
Documento Inquadramento Generale del Database Geografico Provinciale
Upcoming SlideShare
Loading in …5
×

Documento Inquadramento Generale del Database Geografico Provinciale

470 views

Published on

Questo documento definisce il contesto del Database Geografico della Provincia Autonoma di Trento, indicando il modello di aggiornamento e la metodologia incentrata principalmente sull'uso della GeoUML Methodology portata avanti dalla conmpartecipazioendel CISIS e lo SpatialDB Group del Politecnico di Milano.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
470
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Documento Inquadramento Generale del Database Geografico Provinciale

  1. 1. 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. 2. 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. 3. 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. 4. 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. 5. 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. 6. 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. 7. 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. 8. 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. 9. 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. 10. 10/47 2.16 Architettura estendibile a “comuni” o “comunità di valle” come aggiornatori (soggetti esterni) Alcune informazioni previste nel DBGP sono generate presso attori esterni la Provincia come i Comuni o le Comunità di Valle. Ad esempio, la numerazione civica è un dato tipicamente gestito a livello locale. L’architettura del sistema dovrà facilmente poter essere estesa in tal senso, in termini di funzionalità e, soprattutto, per gli aspetti relativi alla sicurezza. 3.0 ARCHITETTURA L’architettura del sistema complessivamente è rappresentata dalla Figura 1; in questo schema ad alto livello si può notare da subito la separazione del sottosistema di gestione da quello di fruizione. Il collegamento è rappresentato dai processi di ETL che creano un flusso monodirezionale dal DB centrale di gestione (DBGP) verso i data mart (DM) di fruizione. Questi data mart rappresentano DB il cui modello dati e la natura tecnologica possono essere anche molto differenti: possiamo avere “ESRI file geodatabase” oppure Oracle Spatial o PostGIS. Saranno i requisiti dei servizi di fruizione che essi supportano a determinarne la tipologia, compresi i requisiti non funzionali che nell’ambito della fruizione sono molto importanti. DBGS1 DBGS2 DBGSn DBGP DM1 DM2 DMm Sistema “verticale” di stazione Sistema “verticale” di stazione Sistema “verticale” di stazione Validazione centrale ETL fruizione ETL gestione ValidazionelocaleGestione Fruizione Figura 1 - Macro architettura del sistema I database di stazione (DBGS) sono indicati con il loro sistema gestionale verticale corrispondente, anche se al momento sono soltanto 2 le stazioni che ne sono dotate: le restanti gestiscono dati non strutturati in veri e propri DBMS.
  11. 11. 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. 12. 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. 13. 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. 14. 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. 15. 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. 16. 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. 17. 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. 18. 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. 19. 19/47 • non esiste un vero e proprio Data Warehouse centrale propriamente detto, • ma esiste di fatto un unico DB operazionale (il DB centrale), che può essere assolvere anche alla funzione di DWH enterprise Siamo quindi molto vicini al modello dei datamart dipendenti perché importanti sono le caratteristiche di omogeneità che derivano dalla presenza di un DB centrale. A questo schema di riferimento si aggiunge anche la possibilità di creare dei datamart indipendenti derivati direttamente dai DB operazionali locali, con visibilità però più limitata. Si è verificata infatti la necessità di fare fruire i dati locali, intendendo in particolar modo quelli specifici di stazione, limitatamente agli uffici interni del Dipartimento a cui la Stazione appartiene. Lo schema architetturale di Figura 1 va quindi rivisto aggiungendo una sorta di Sistema di Fruizione dipartimentale, come mostrato in Figura 7. Nel caso più semplice il sistema di fruizione locale può collassare in una serie di viste predisposte direttamente sul DBGS ei servizi di fruizione coincidere con la possibilità di accedere direttamente alle viste stesse. Incrementando gradualmente la complessità del sistema, le viste possono essere esposte tramite servizi di rete, anziché essere accedute direttamente dagli utenti nel DB fino ad arrivare ad una vera e propria replica effettuata con ETL appositi. DBTS1 DBTP Sistema “verticale” di stazione Validazione centrale Gestione DBGS1 DBGP Sistema “verticale” di stazione ETL gestione Gestione ETL fruizione locale DM locale Sistema fruizione locale Stazione1 Figura 7 - Eventuale sistema di fruizione locale 3.6 I sistemi locali Prevediamo al momento due tipologie di sistemi locali: 1- Quello in cui i dati sono gestiti attualmente in maniera non strutturata, tipicamente su file system o su DB non enterprise e attraverso applicazioni GIS generiche. 2- Quello in cui i dati sono stati modellati in uno schema applicativo ad hoc ed essi sono fisicamente mantenuti in un DBMS dove sono gestiti attraverso applicativi specializzati (o applicativi GIS commerciali con funzionalità evolute). Questi sistemi locali sono collocati presso le stazioni SIAT le quali sono collegate con il sistema centrale e tra di loro in rete locale ad alta velocità. 3.6.1 ARCHITETTURA DI UNA GENERICA STAZIONE PAT SPROVVISTA DI SISTEMA VERTICALE Il seguente capitolo ha l'obbiettivo di definire l'architettura di una stazione PAT nella quale non è ad oggi presente una base dati strutturata, nella quale quindi non è necessario il recupero di un investimento pregresso relativo alla progettazione della base di dati.
  20. 20. 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. 21. 21/47 permettere una validazione completa dei dati locali poiché sarebbero verificati tutti i vincoli intraclasse i quali richiedono i dati presenti solo a livello provinciale. L'importatore potrebbe utilizzare come formato di input la struttura dati generata dal modello implementativo “Shape Flat” applicato al contenuto definito nella specifica provinciale; se così fosse l'importatore potrebbe essere riutilizzato in tutti i DBGS per importare i dati provenienti dai flussi provinciali. L’utilizzo di shape flat non è l’unica possibilità: si può attingere anche direttamente dal DB di stazione; la prima soluzione consentirebbe però di estendere la soluzione anche a situazioni in cui non fosse possibile introdurre un DB PostGIS (ad esempio i Comuni). Oltre all'applicativo di importazione sarà necessario sviluppare un ETL di esportazione che permetta di estrarre i dati da aggiornare (preferibilmente sotto forma di delta) da inviare al DBGP; anche questo componente potrebbe essere riutilizzato in ogni DBGS. Terminata la definizione della struttura del database devono essere caricati i dati nel DBGS. Le trasformazioni necessarie per effettuare il caricamento da shapefile utilizzati dalla stazione a tabelle del DBGS dovranno essere fatte una sola volta poiché successivamente verranno aggiornati direttamente nel database. Il processo di caricamento varia da stazione a stazione, per questo si suggerisce una ristrutturazione manuale o attraverso un ETL configurabile poiché si ritiene inutile lo sviluppo di un applicativo ad-hoc per un solo utilizzo. Terminata la fase di caricamento ogni stazione procederà all'invio di tutti i dati contenuti nel database (primo impianto) e dei successivi aggiornamenti (come delta di modifica); si ritiene di poter gestire il primo impianto come un qualsiasi aggiornamento fatto dalla stazione ma contenente la totalità dei dati. DBGS validazione SCS prov estrazione shapefileNuovo sistema verticale validazione datispecifici di stazione SCS staz DBGP Servizidi fruizione DB stazione Figura 8 - Sistema di stazione senza sistema verticale preesistente
  22. 22. 22/47 Da notare che il DBGS è parte del DB locale di stazione14 : in altre parole lo schema dei dati specifici di stazione costituisce un’estensione allo schema del nucleo (DBGS) il quale rispecchia una porzione del DBGP centrale. Sul DBGS sono definite delle viste su cui opererà il Validatore configurato con le stesse specifiche (file SCS) del DBGP centrale. Opzionalmente, e senza che questo abbia alcun impatto sulla qualità dei dati da conferire centralmente, potrà essere eseguita anche una validazione sui dati specifici di stazione. Se, infatti, lo schema dell’estensione verrà definito attraverso il GeoUML Editor, sarà possibile infatti ricavare un file SCS da utilizzare per configurare il Validatore allo stesso modo con cui si esegue la validazione delle classi da conferire al DBGP. 3.6.2 ARCHITETTURA DI UNA STAZIONE PAT CON PREESISTENTE SISTEMA VERTICALE validazione SCS prov Estrazionee trasformazione shapefile Sistema verticale legacy DB legacy DBGP Servizidi fruizione Figura 9 - Sistema di stazione con sistema verticale preesistente Nel caso di esistenza di un sistema verticale legacy di stazione, è impercorribile la strada del DB locale come estensione di un ritaglio della specifica del DBGP. Il DB locale non potrà essere modificato per cui occorre prevedere degli ETL che permettano l’estrazione dei dati per la validazione e altri per il conferimento al DB centrale. Nello schema di Figura 9 è mostrato un solo ETL per semplicità, ma la necessità di avere due versioni di estrattori nasce dalla constatazione che per la validazione locale non è necessaria la profondità storica (si valida l’attualità perché le specifiche concettuali descrivono solo lo stato attuale), mentre per l’aggiornamento del DBGP 14 Il servizio di database fornito alle stazioni prevede anche a fianco del DB di stazione anche la dotazione di uno “schema libero”; per eliminare ogni possibilità di equivoco, si precisa che questo schema libero non ha nulla a che vedere con la porzione di DB che contiene i dati specifici di stazione.
  23. 23. 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. 24. 24/47 hoc nella quale siano presenti tutti e solo i vincoli che coinvolgono le classi la cui gestione è demandata alla stazione. Il servizio di simulazione dovrà produrre una diagnostica utile alla stazione per valutare se le violazioni rilevate dalla validazione siano imputabili ad errori della stazione (in qual caso provvederà a bonificarli) o ad errori di competenza di altre stazioni. Sono state definite quali siano le principali fasi richieste per la produzione dell'aggiornamento e il successivo invio al DBGP; oltre alle fasi è necessario definire la frequenza e la modalità di invio degli aggiornamenti. L'invio può avvenire in modo manuale o automatico sia attraverso schedulazioni che attraverso la definizione di componenti che rilevano l'avvenuto aggiornamento. L'invio di aggiornamenti in modo automatico permette di evitare disallineamenti tra DBGS e DBGP evitando oneri di invio da parte dell'operatore locale; questo approccio però ha anche dei lati negativi. È necessario considerare che l'operatore della stazione, se l'aggiornamento avviene in modo automatico, inserisca solo gli aggiornamenti che è sicuramente in grado di validare entro l'inizio della procedura di invio. Questo potrebbe comportare la definizione di base dati parallele nelle quali definire gli aggiornamenti speditivi e/o di grande impatto che potrebbero richiedere un lungo lavoro di editing. La procedura di invio manuale dell'aggiornamento permetterebbe invece alle singole stazioni di gestire degli aggiornamenti speditivi e degli stati inconsistenti inviando gli aggiornamenti solo quando la base di dati fosse riportata in consistenza; questo eviterebbe la creazione di base dati parallele e perdita di informazioni. Con lo schema seguente si tenta di riassumere il flusso di invio di un aggiornamento da parte di una stazione priva di base dati strutturata: All'inizio del paragrafo si sono definiti dei requisiti necessari perché sia possibile gestire l'invio dell'aggiornamento; questi prerequisiti potrebbero non essere rispettati, rispettati solo in parte o raggiunti progressivamente. Sistema verticale o applicativo GIS di stazione DBGSAggiorna GeoUML Validator SC locale ETL - estrattore aggiornamento Shape di aggiornamento Produce Sistema informativo di stazione DBGP di simulazione Valida GeoUML Validator SC DBTP con vincoli ad-hoc per la stazione locale Report di simulazione Valida Tool di gestione dell'aggiornamento Applica Produce Figura 10 - Flusso di aggiornamento
  25. 25. 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. 26. 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. 27. 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. 28. 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. 29. 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. 30. 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. 31. 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. 32. 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. 33. 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. 34. 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. 35. 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. 36. 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.

×