DBGP

DBGP: DataBase Geografico della PAT

Cosa è? Come

funziona? Tramite

esempi semplici

ed immediati

Metafora

I dati gestiti localmente dalla Stazione A sono un semplice file Excel.Il db centrale, invece, corrisponde ad uno spreadsheet Google.

La Stazione A gestisce i suoi dati sul file Excel, strutturato in un certo modo.Ogni giorno, i dati del file Excel vengono condiviso con tutte le altre Stazioni in un foglio (sheet) dello spreadsheet Google; questo foglio, però, è strutturato in maniera leggermente diversa da Excel …

Questo è esempio banale e minimale!!

La Stazione deve gestire dati di “persone”.Il modello dati che la Stazione A ha in mente (per il suo gestionale) prevede una serie di attributi della persona.Questi attributi servono alla Stazione per il suo gestionale.Alcuni (solo alcuni) sono di interesse di altre Stazioni o sono previsti in specifiche nazionali o europee.

… idem come sopra: è un esempio banale e minimale!!

Questi sono invece gli attributi di interesse di altre Stazioni; alcuni di questi sono anche previsti in specifiche nazionali o europee.

Questi attributi sono previsti a livello di DBGP, cioè a livello di db centrale.

Per il “nome” non ci sono problemi: sia a livello locale che centralel’attributo ha le stesse caratteristiche (deve essere un semplice testo)

Anche per il “cognome” non ci sono problemi: anche qui, sia a livello localeche centrale, l’attributo ha le stesse caratteristiche (deve essere un semplice testo)

L’attributo “sesso” non è invece previsto a livello centrale: questo significa che l’attributo rimarrà solo nel database locale e non verrà importato nel db centrale.

Anche l’attributo “professione / tipo” non è previsto a livello centrale: questo significa che l’attributo rimarrà solo nel database locale e non verrà importato nel db centrale.

Idem come sopra: anche l’attributo “professione / note” non è previsto a livello centrale: questo significa che l’attributo rimarrà solo nel database locale e non verrà importato nel db centrale.

Per l’attributo “Comune” (di nascita) non ci sono problemi: anche qui, sia a livello locale che centrale, l’attributo ha le stesse caratteristiche (deve essere un semplice testo)

Per l’attributo “Provincia (o Paese)” (di nascita) ci sono differenze tra localee centrale: questo significa semplicemente che durante l’import da locale a centrale si farà una trasformazione, cioè si partirà dai valori del campo “Provincia (o Paese)” per derivare automaticamente il valore del campo “Nazione” nel db centrale.

Anche nel caso dell’attributo “Data di nascita” ci sono differenze tra locale e centrale: in questo caso durante l’import da locale a centrale si farà una trasformazione, cioè trasformerà il formato della data da “GG/MM/AA” a “AAAA-MM-GG”

In questo caso le differenze tra locale e centrale riguardano il fatto che a livello locale i dati sono su due campi: durante l’import da locale a centrale si farà anche qui una trasformazione, cioè si prenderanno i valori dei due campi “DUG” e “Via” del db locale e si popolerà il campo unico “Via” nel db centrale.

Idem come sopra: durante l’import da locale a centrale si farà anche qui una trasformazione, prendendo i valori dei due campi “Civico” e “Sub_esp” del db locale e si popolerà il campo unico “Numero civico” nel db centrale.

Per l’attributo “Città”, invece, non ci sono problemi: qui, sia a livello localeche centrale, l’attributo ha le stesse caratteristiche (deve essere un valore di una lista) e quindi occorrerà solo verificare che i valori siano gli stessi a livello locale e centrale.

Per l’attributo “Città”, idem, non ci sono problemi: qui, sia a livello locale che centrale, l’attributo prevede valori da una lista predefinita, e quindi occorrerà solo verificare che i valori siano gli stessi a livello locale e centrale.

gestire dati geografici su file SHP =

gestire dati alfanumerici su XLS

gestire dati (geografici) su (geo)db =

avere più ordine e meno costi

locale

come devo strutturare i miei dati?

locale centraleETL