tesi garasi
DESCRIPTION
TRANSCRIPT
UNIVERSITÀ DEGLI STUDI DI MILANO BICOCCA
FACOLTÀ DI SCIENZE MATEMATICHE FISICHE E NATURALI Corso di Laurea Magistrale in Informatica
Tecniche di analisi del Repository delle Basi dati della Pubblica Amministrazione
Relatore: Carlo Batini - Università Bicocca
Correlatore: Riccardo Grosso - CSI Piemonte
Controrelatore: Stefania Bandini - Università Bicocca
Tesi di Laurea di: Manuel Francesco Garasi
Matr. N: 062023
Anno Accademico 2004/2005
Ringraziamenti
Vorrei ringraziare il professor Carlo Batini e Riccardo Grosso per avermi supportato nel
periodo di stage e nella stesura di questa tesi, fornendomi le conoscenze con la
professionalità che li contraddistingue.
Un grosso ringraziamento lo dedico alla mia famiglia, che mi ha permesso di arrivare
fino a questo traguardo, e a Claudia per essermi stata sempre vicino.
2
Sommario
ABSTRACT 5
INTRODUZIONE 6
Scopo della tesi 6
I concetti fondamentali 6
L’architettura informatica della PA Italiana 11
LE METODOLOGIE DI LAVORO 14
La metodologia esatta per la PA Centrale 14
La metodologia approssimata per la PA Locale 18 Euristiche applicate 18 I passi metodologici per la riconcettualizzazione di schemi logici delle basi dati PAL 22 I passi metodologici per la creazione degli schemi astratti PAL 28
Confronto con altre metodologie 31
IL TOOL 34
Il CSI Piemonte: organizzazione, ruolo e architettura tecnologica 34
Le prime specifiche 36
3
La metodologia implementata per la PA Locale 37 La metodologia semplificata per la riconcettualizzazione 38 La metodologia semplificata per la creazione di schemi astratti 44
Il processo di sviluppo 48 Scelta della modalità di sviluppo 48 Scelte implementative 49 La conoscenza di base e la sua estrazione 51 Progettazione e implementazione delle componenti 58 Assemblaggio delle componenti 72 Testing 76
Evoluzioni 77 Nuove funzionalità 77 Nuovi formati per gli schemi grafici e per la rappresentazione interna 78
CONCLUSIONI 79
RIFERIMENTI 80
APPENDICE 82
Schemi intensionali ed estensionali della relazioni utilizzate 82 Le sei gerarchie di generalizzazione 82 Le relazioni tra entità PAC 85
Reuse of repository of conceptual schemas in a large scale project (Batini-Garasi-Grosso) 86
4
Abstract
Questa tesi descrive le scelte metodologiche e progettuali che hanno portato alla
produzione di un tool atto alla creazione di un repository di basi dati. La
metodologia seguita permette di riconcettualizzare un insieme di schemi logici al
fine di ottenere uno schema concettuale delle entità caratterizzanti, e
successivamente di ottenere uno schema piramidale rappresentante le relazioni
semantiche tra i vari concetti ad un certo livello di interesse.
Il tool è stato impiegato per la creazione di un repository di basi dati della
Pubblica Amministrazione Locale Piemontese; i concetti di repository e la
metodologia sono stati ripresi ed adattati partendo dallo studio di un repository
sulle basi dati della Pubblica Amministrazione Centrale condotto anni addietro.
L’utilizzo del tool permette la creazione in tempi molto brevi di uno schema
rappresentante i dati aziendali fornendo una visione esauriente ed integrata.
A seguito dell’interesse prodotto dal lavoro sono state effettuate ulteriori
sperimentazioni e test. Apportando delle modifiche alla base della conoscenza
del tool, è possibile svincolarsi dal contesto iniziale ed utilizzare lo strumento al
fine di supportare la comprensione delle conoscenze aziendali.
5
Introduzione
Scopo della tesi
Lo scopo della tesi è la descrizione delle fasi di sviluppo di un tool atto alla
creazione di repositories di base dati.
L’ambito su cui si è operato è la Pubblica Amministrazione, in particolare quella
Locale Piemontese. Il fine del lavoro è quello di studiare un repository di basi dati
della Pubblica Amministrazione Centrale, costruito anni addietro, per costruirne
uno specifico per quella Locale sfruttando le somiglianze delle strutture
amministrative.
Al fine di sviluppare il tool in una sua prima versione, si è analizzata una
metodologia esistente ed è stata implementata apponendo alcune euristiche.
L’ottenimento di un simile prodotto permette l’automazione di un lavoro manuale
intellettuale diminuendo drasticamente il tempo computazionale.
I concetti fondamentali
La risorsa principale di un sistema informativo sono i dati. La conoscenza e le
basi dati sono fondamentali per una azienda e vanno dunque preservati e
organizzati al meglio; in un periodo in cui sempre maggiori quantità di dati
vengono utilizzate dalle aziende, una corretta e funzionale organizzazione del
sistema organizzativo è fondamentale per la sua efficienza.
Una soluzione per tale problema è l’organizzazione dei dati mediante l’uso dei
repository; per la loro peculiarità di rappresentare informazioni con un certo livello
6
di dettaglio voluto, sono lo strumento ideale per avere un quadro completo delle
risorse dati e analizzare le relazioni intercorrenti tra di loro.
Un repository può essere considerato come una collezione di schemi concettuali
ognuno dei quali rappresenta uno specifico ambito di interesse del sistema
informativo aziendale.
Gli schemi concettuali utilizzano uno standard di rappresentazione fondato sul
modello Entity Relationship, che permette di mostrare molto efficacemente le
relazioni esistenti tra oggetti del sistema.
A differenza dei modelli logico/fisici, uno schema concettuale permette di
rappresentare la realtà assegnando ad ogni classe di oggetti del mondo reale un
nome identificativo; nello schema vengono anche rappresentati i legami
intercorrenti tra le varie classi di oggetti, chiamate relazioni, e le caratteristiche
eventuali di ognuno, detti attributi.
L’astrazione permessa dallo schema concettuale permette di distaccarsi dai livelli
fisici sottostanti caratterizzati da una rigidità legata al DBMS, favorendo
l’indipendenza fisica; ciò consente di modificare le strutture di memoria o i metodi
di accesso ai dati senza modificare lo schema concettuale globale.
A sua volta lo schema concettuale agevola l’indipendenza logica verso le
applicazioni, in modo tale da permettere la modifica dello schema stesso senza
modificare le preesistenti viste esterne.
7
Figura 1: Architettura a tre livelli
App 1 App 2
DB
s. concettuale
Indipendenza logica
Indipendenza fisica
L’esempio seguente mette in relazione due entità (cittadino e tributo)
associandole con la relazione pagamento; nel complesso lo schema risulta di
facile e rapida comprensione utilizzando un linguaggio vicino a quello naturale.
Figura 2: Esempio di schema concettuale ER
Soggetto Tributo paga
Oltre alla relazione esiste anche il costrutto di generalizzazione che permette di
creare oggetti che ereditano proprietà e relazioni di una classe padre.
Grazie a questa rappresentazione, lo schema concettuale descrive l’informazione
posseduta dai dati, di facile interpretazione sia per l’analista che per l’utente, ma
per essere tale deve rispettare le seguenti proprietà:
o Correttezza: le categorie del modello ER devono essere usate
coerentemente con la loro semantica (le loro definizioni).
o Completezza: tutte le specifiche devono essere rappresentate nello
schema.
8
o Pertinenza: non vi devono essere nello schema concetti non descritti nelle
specifiche.
o Leggibilità: lo schema deve rappresentare i requisiti in modo
comprensibile.
o Minimalità: non vi devono essere concetti che rappresentano gli stessi
requisiti.
Ogni schema concettuale rappresenta una basi dati specifica del complesso
insieme della conoscenza aziendale, per questo, l’utilizzo di un repository può
essere utile per creare ordine raggruppando ragionatamente gli schemi
concettuali.
Il repository permette di organizzare le varie informazioni, rappresentate dagli
schemi ER, in una maniera più o meno astratta a seconda del grado di
astrazione desiderato.
A tal fine, il repository utilizza i concetti di tre primitive utili per specifiche
operazioni.
o Astrazione: per poter avere una maggior chiarezza nella lettura dei dati è
necessario filtrare le informazioni meno importanti in modo da rendere la
lettura di uno schema più comprensibile e immediata. È possibile quindi
analizzare una struttura gerarchica dal livello di astrazione maggiore,
rappresentante le entità fondamentali dell’organigramma, oppure
analizzare nel dettaglio una specifica realtà di interesse.
o Vista: in uno schema concettuale complesso è possibile focalizzare
l’attenzione su uno spaccato e studiarne indipendentemente la sua
struttura.
o Integrazione: per la costruzione di un repository è fondamentale l’unione di
più schemi concettuali eterogenei, questa operazione avviene fondendo
più schemi ER sovrapponendone i concetti comuni a entrambi gli schemi.
Utilizzando iterativamente queste tre tecniche è possibile costruire un repository
che, come è di facile intuizione, avrà una struttura piramidale data dall’utilizzo
9
contemporaneo delle tecniche di integrazione e l’astrazione che decimano il
numero di schemi per ogni livello crescente.
Nella pratica, si raccolgono degli schemi concettuali, rappresentanti le viste
eterogenee di specifiche parti della conoscenza, e si uniscono direttamente con
una operazione di integrazione-astrazione per favorire l’immediata creazione di
un unico prodotto di livello più astratto.
Nella figura seguente viene rappresentato un esempio concreto. Gli schemi
concettuali di tre settori aziendali (Produzione, Vendita, Magazzino) sono
rappresentati nell’ultima riga e vengono integrati insieme in uno schema
concettuale che rappresenta la compagnia. Successivamente lo schema viene
sottoposto ad astrazioni successive togliendo di passo in passo le entità meno
significative in relazione al livello di astrazione corrente.
DEP EMPMan
CITY
Born
DEP EMP-DATAD-E
FLOOR
DEP EMPMan
In Head
CITY
BornITEM ORD
EMP
SELLER
PUR
WARE
Loc..In Of
Acq
ITEM ORD-DATA
EMP-DATA
In
Acq
ITEM
DEP EMPLOYEE
CLERK ENGIN
WARR
Prod.
Head
ITEM
DEP EMP-DATAD-E
Product
ITEM
DEPART EMPLOYEE
Product
Company SalesProduction
ITEM ORDER
DEPART EMPLOYEE CITY
SELLER
Man
PURCHIn Of
Acq
Born
Born
CITY
Born
ITEM
DEP D-E
In
EMP-DATA
ORD-DATA
ManAcq
CITY
Department structure
integration
view
view
abstraction
WARR
ITEM ORDER
FLOOR
DEPARTM EMPLOYEE CITY
SELLER
CLERK ENGINEER
GestLav.
PURCH
In
WARE
Loc
Man
In Of
Of
Head
Born
Type
ITEM ORD
EMPL
SELLER
PURIn Of
Acq
abstraction
DEP EMPMan
CITY
Born
DEP EMPMan
CITY
Born
DEP EMP-DATAD-E
FLOOR
DEP EMPMan
In HeadHead
CITY
BornITEM ORD
EMP
SELLER
PUR
WARE
Loc..In Of
Acq
ITEM ORD-DATA
EMP-DATA
In
Acq
ITEM
DEP EMPLOYEE
CLERK ENGIN
WARR
Prod.
Head
ITEM
DEP EMP-DATAD-E
Product
ITEM
DEPART EMPLOYEE
Product
Company SalesProduction
ITEM ORDER
DEPART EMPLOYEE CITY
SELLER
Man
PURCHIn Of
Acq
Born
Born
CITY
Born
ITEM
DEP D-E
In
EMP-DATA
ORD-DATA
ManAcq
CITY
Department structure
integration
view
view
abstraction
WARR
ITEM ORDER
FLOOR
DEPARTM EMPLOYEE CITY
SELLER
CLERK ENGINEER
GestLav.
PURCH
In
WARE
Loc
Man
In Of
Of
Head
Born
Type
ITEM ORD
EMPL
SELLER
PURIn Of
Acq
abstraction
Figura 3: Un esempio di repository aziendale.
10
L’architettura informatica della PA Italiana
Il crescente livello tecnologico nel settore aziendale degli ultimi decenni ha
indotto molti governi, tra cui l’Italia, ad interessarsi all’informatizzazione
dell’apparato amministrativo per favorire il miglioramento dei servizi al cittadino e
alle imprese.
La ristrutturazione della Pubblica Amministrazione Italiana, avvenuta nei primi
anni novanta, ha portato ad un processo d’innovazione nei sistemi informativi in
cui si è vista la nascita dell’organismo preposto allo sviluppo dei sistemi
informativi pubblici, l’Autorità per l’Informatica nella Pubblica Amministrazione
(AIPA).
Il compito dell’AIPA si estende su tutta la struttura della Pubblica
Amministrazione italiana, che si compone di una parte Centrale e di una Locale
composta da agenzie specializzate nel territorio regionale, provinciale o
municipale di competenza.
La parte Centrale è suddivisa in Ministeri, quali il Ministero delle Entrate e il
Ministero degli Interni, e da varie agenzie, quali INPS, INAIL e Camere di
Commercio.
In principio, ogni dipartimento sviluppò un proprio sistema informatico non
orientato alla rete, in accordo con le vigenti tendenze informatiche, quindi isolato
dal resto degli altri organismi burocratici.
Questa grave, ma concepibile, mancanza si concretizzò in un sistema totalmente
non cooperativo con conoscenze decentralizzate che portò all’affioramento di
due problemi: l’inconsistenza dei dati, e la difficoltà nell’accesso.
L’inconsistenza è data dal fatto che ogni dipartimento possiede una copia
proprietaria dei dati di un iscritto e, in fase di aggiornamento, il processo non
avviene in maniera istantanea in tutti i dipartimenti; il soggetto richiedente deve
infatti fare domanda di aggiornamento ad ognuno dei dipartimenti, causando
molte volte incongruenza tra le fonti.
11
Figura 4: Esempio di aggiornamento dati in un sistema non cooperativo
Una soluzione molto apprezzata per risolvere il problema si basa sulla creazione
di un’architettura che favorisca un approccio cooperativo tra dipartimenti. Questa
soluzione di BackOffice, nota come CIS (Cooperative Information System),
consente il libero scambio di servizi tra dipartimenti basandosi sul livello fisico
cooperativo di base.
La figura seguente mostra la connessione esistente tra le amministrazioni
collegate mediante una rete comune.
12
Basic services
Transport services
Administration1
processes
Internal DBs
Exported data
Internalapplication
Exported services
Administration2
processes
Internal DBs
Exported data
Internalapplication
Exported services
Basic services
Transport services
Administration1
processes
Internal DBs
Exported data
Internalapplication
Exported services
Administration2
processes
Internal DBs
Exported data
Internalapplication
Exported services
Figura 5: Architettura CIS
Basandosi su una tal struttura ciascuna amministrazione mette in condivisione
servizi e risorse verso le altre consociate; da qui nasce l’idea di raggruppare tutto
il materiale condiviso in un dominio fornendo delle interfacce per cooperare con
l’esterno.
Inoltre, per rendere possibile una sincronizzazione tra gli enti cooperanti, si
impone una standardizzazione di un set di parole, in cui ogni vocabolo non sia
ambiguo e si riferisca al medesimo concetto per tutte le amministrazioni facenti
parte dello schema di collaborazione.
L’utilizzo del repository è la soluzione ideale per i problemi finora accennati.
13
Le metodologie di lavoro
Il primo lavoro svolto per la costruzione di un repository della Pubblica
Amministrazione iniziò una decina di anni fa; l’attività aveva come scopo l’analisi
degli archivi dipartimentali della Pubblica Amministrazione Centrale al fine di
creare una piramide concettuale che riuniva le varie fonti di conoscenza.
Oggigiorno, allo scopo di creare un’architettura che permetta la collaborazione
tra la struttura Centrale e quella Locale, si è deciso di creare un repository sulla
parte PAL riutilizzando i risultati e le tecniche maturate dall’esperienza a seguito
del lavoro svolto sulla PAC.
Come è descritto in seguito, la nuova metodologia utilizza delle euristiche rispetto
a quella utilizzata nel primo lavoro; queste approssimazioni sono atte a diminuire
drasticamente il tempo di completamento e ridurre al minimo il numero di
persone coinvolte nell’opera.
La metodologia esatta per la PA Centrale
Lo scopo del primo lavoro eseguito sugli archivi della Pubblica Amministrazione
fu quello di riordinare l’enorme patrimonio informativo della parte centrale
analizzando ogni fonte di conoscenza di 21 delle più importanti amministrazioni
centrali italiane.
L’attività svolta ha seguito una precisa metodologia di lavoro composta da due
sessioni:
1. Rilevazione. In questa fase si sono raccolti tutti gli schemi logici dei
database delle amministrazioni esaminate e si sono convertiti in schemi
concettuali, basati su schemi ER, seguendo una procedura metodologica
di reverse engineering (vedere El Masri and Navate (2004)). Il risultato di
14
questa prima attività fu la creazione di 500 schemi concettuali di base
rappresentanti il contenuto delle basi dati delle amministrazioni esaminate,
con circa 5000 attributi e altrettante relazioni.
2. Aggregazione. La conoscenza fornita dai 500 schemi di base ottenuti al
passo precedente è praticamente ingestibile data la sua enorme ampiezza
di contenuti, si è dovuti ricorrere a delle tecniche di raggruppamento per
snellire il lavoro di piramidazione. Per questi motivi si è operato nei
seguenti modi:
a. Clusterizzazione. In questa sottofase si sono raggruppati gli schemi
di base a seconda alla loro natura omogenea e al contesto di cui
facevano parte. In questo compito si è fatto riferimento alla
classificazione Materia/Funzione proposta dalla IDC (International
Data Corporation), modificata in alcuni aspetti per corrispondere
meglio al contesto della Pubblica Amministrazione Italiana.
La moltitudine di schemi concettuali di base quindi è stata
partizionata in questi gruppi e, a tale scopo, si sono utilizzati dei
criteri di similitudine basati su distanze tali da creare 27 aree che
andavano a ricoprire tutto l’intero interesse della Pubblica
Amministrazione.
b. Integrazione-astrazione. Gli schemi contenuti in ogni cluster sono
stati integrati-astratti in modo tale da ottenere uno schema
rappresentativo dell’area amministrativa. In tal modo gli schemi
sono stati compressi in un'unica mappa concettuale che contiene le
entità più rappresentative del cluster per ottenere un insieme di
concetti con un giusto grado di dettaglio.
I 27 schemi concettuali così ottenuti sono stati posti al livello
successivo nella piramide del repository che si stava in tal modo
creando.
L’operazione di integrazione-astrazione è continuata ricorsivamente creando
15
schemi sempre più astratti che descrivevano la realtà fino a quel momento
considerata con un livello di dettaglio sempre più approssimato.
Nelle figure seguenti sono riportati lo schema IDC utilizzato come modello per la
creazione del repository e la piramide concettuale PAC derivata, in quest’ultima
sono rappresentati gli schemi concettuali dal penultimo livello dopo aver
integrato-astratto i cluster.
Pubblica Amministrazione
Risorse Servizi
Finanziarie Umane Strumentali Territorio e
AmbientePopolazione Produzione Relazioni
Salute ed
Assistenza
Sociale Lavoro e
SicurezzaSociale
Istruzione Cultura Giustizia Sicurezza
interna
Sicurezza
esterna Relazioni
esterne
Figura 6: La Classificazione IDC
TRA
SFER
IMEN
TO F
OND
I A
ENT
I LO
CALI
PE
R E
NTI P
UIB
BLI
CI
CAPI
TOLI
DI S
PESA
TRASPORTI COMUNICAZIONIPRODUZIONELAVOROCULTURAEDILI ZIA
AMBIENTEIST RUZI ONESANITA'SIC UREZZA GIUST IZIADIFESAAFFARI ESTERI
ASSIC URAZIO- NE SOCIALE
CERT IFICA- ZIONE
SERVIZI SOCIALI E TERRIT ORIALI
STATISTICARISORSE D I SUPPORTO
RISORSE FINANZIAR IE
RISORSE STRUMENTALI E IMMOBILIARI
RISORSE UMANE
PROT
OCO
LLO
OR
GAN
I COL
LEG
IALI
FISC
O
DOG
ANE
SCHEMA INTEGRATO DELLE BASI DI DATI DELLA PA DI 1° LIVELLO
SCHEMA INTEGRATO DELLE BASI DI DATI DELLA PA DI 2° LIVELLO
SCHEMA INTEGRATO DELLE BASI DI DATI DELLA PA DI 3° LIVELLO
RISORSE SERVIZI
SERVIZI GENERALI SERVIZI DIRETTISERVIZI SOCIALI ED ECONOMICI
STRU
MEN
TI
AUT
OM
EZZI
BEN
I IM
MO
BILI
DIP
END
ENTI
FORM
AZIO
NE
RAPP
RESE
NTA
NZE
ENTI
TER
RITO
RIAL
I
CERT
IFIC
AZIO
NI
CATA
STO
PREV
IDEN
ZA
REL
AZ
ION
I EST
ER
E IN
IT
ALI
A
RE
LA
ZIO
NI IT
AL
IAN
E A
LL' E
STE
RO
AT
TIV
ITA
' GIU
RID
ICA
CR
IMIN
AL
ITA
'
SIC
UR
EZZ
A IN
TE
RNA
ASSI
STE
NZ
A
SERV
IZIO
SA
NIT
AR
IO
IST
RUZ
ION
E
AM
BIE
NTE
BE
NI C
ULT
UR
ALI
LAV
OR
O
AZI
END
E A
GR
ICO
LE
AZIE
ND
E IN
DU
STR
AL
I
TRA
SPO
RTI
SERVIZI SOCIALI SERVIZI ECONOMICI
2/93
2/12 8/
293
6/69
3/18
23/
30
2/89
3/59
2/65
37/3
36
3/75
6/95
4/12
13/
66
9/11
8
4/36
6/53 10
/76 6/
76
6/13
0
5/56
6/15
5 3/13
4
8/21
3
10/1
00 9/11
8
3/53
9/11
2 10/1
78
Figura 7: Schema del Repository PAC
16
Il lavoro di astrazione ricorsivo porta alla creazione di uno schema vertice che
rappresenta, a livello più astratto, i concetti fondamentali del sistema informativo
della Pubblica Amministrazione Centrale.
Individual
Document
Legal person
Subject
Property
Place
Individual
Document
Legal person
Subject
Property
Place
Figura 8: Schema concettuale al vertice del Repository
Il contributo speso per la costruzione del repository PAC è stato molto salato in
termini di risorse lavoro.
Il solo lavoro di reverse engineering ha richiesto 200 mesi/persona per la
creazione di tutti gli schemi concettuali di base derivati dall’analisi di ogni base
dati di 21 amministrazioni statali. La costruzione di ogni schema astratto con il
meccanismo dell’integrazione-astrazione ha richiesto per ogni schema 2
settimane/persona, un rapido calcolo porta al totale di 24 mesi/persona per la
creazione di 55 schemi astratti.
Il lavoro effettuato sulla PAC ha suscitato interesse, ed ora tale attenzione si è
spostata sulla costruzione di un simile repository sulla parte locale della Pubblica
Amministrazione Piemontese, con la differenza della profonda riduzione delle
risorse umane coinvolte.
17
La metodologia approssimata per la PA Locale
Lo scopo perseguito durante il lavoro sulla parte Locale Piemontese della
Pubblica Amministrazione rimane analogo a quello della PAC; il fine resta
sempre l’ottenimento del Repository che descriva, a più livelli di dettaglio,
l’architettura concettuale dei dati all’interno della Pubblica Amministrazione.
La specifica più importante al nuovo lavoro è la riduzione netta dell’utilizzo delle
risorse umane.
A seguito di tale specifica non è dunque possibile riproporre il metodo di lavoro
effettuato anni prima sulla parte Centrale, in quanto molto dispendioso in termini
di risorse applicate. È necessario quindi riutilizzare i risultati ottenuti da tale
lavoro e riadattare le metodologie applicate.
Questa delicata richiesta esige il rianalisi delle metodologie di lavoro al fine di
trovare una possibile automazione o una semplificazione negli algoritmi utilizzati
precedentemente.
Euristiche applicate
L’accorgimento preso è ricaduto nell’utilizzo di supposizioni ed euristiche rispetto
alla metodologia utilizzata nel lavoro sulla parte centrale. Il riuso del repository
PAC è fondamentale, a seguito di tale lavoro si sono potuti definire delle linee
guida per la creazione di altrettanti repository su varie parti della Pubblica
Amministrazione.
Una prima supposizione può essere derivata dal fatto che le piramidi concettuali
della PAC e della PAL avranno sicuramente delle differenze date dalla natura
stessa delle amministrazioni, ma tali diversità si concentreranno in maggior
misura nella parte bassa, più vicina alla realtà di interesse e legata al mondo
amministrativo territoriale di competenza.
18
Secondo tale supposizione è possibile utilizzare la conoscenza contenuta nella
parte alta del Repository PAC per costruirne uno simile per la Pubblica
Amministrazione Locale.
È quindi ora possibile definire gli input per la costruzione del Repository PAL:
1. Il primo input essenziale sono gli schemi concettuali PAC.
I 500 schemi di base sono utili per avere traccia delle relazioni tra le entità,
mentre quelli astratti contengono della conoscenza per la costruzione
della piramide.
Riutilizzare la conoscenza degli schemi astratti del Repository PAC non è
comunque semplice data l’ampia varietà di concetti dei 50 schemi, è stato
quindi necessario trovare una forma di conoscenza più maneggevole. Si è
dunque estrapolato dai livelli più alti della piramide PAC una serie di
concetti fondamentali rappresentanti le gerarchie dei concetti contenuti nei
livelli più alti della piramide.
Partendo dal vertice si è applicata una visita top-down seguendo
l’evoluzione dei cinque concetti fondamentali della Pubblica
Amministrazione (vedi figura 8) nei livelli inferiori. Questa forma più densa
di conoscenza può essere rappresentata sottoforma di lista di concetti
gerarchicamente ordinati. Tale struttura prende il nome di “gerarchie di
generalizzazioni” e costituisce un importante input per la nuova
metodologia.
A titolo di esempio, nella figura seguente viene mostrata la gerarchia di
generalizzazione dell’entità Soggetto.
SOGGETTO
SOGGETTO FISICO - PERSONA FISICA
ASSISTITO
CANDIDATO
CONTRIBUENTE
APPARTENENTE CATASTO
CONDANNATO
IN ATTESA DI GIUDIZIO
19
DISOCCUPATO
ITALIANO
RESIDENTE ALL'ESTERO
LAVORATORE
AUTONOMO
DIPENDENTE
IMPRENDITORE
PENSIONATO
SEGNALATO
TOSSICODIPENDENTE
VOLONTARIO SOGGETTO GIURIDICO
IMPRESA
Figura 9: Gerarchia di Soggetto
2. Il secondo input riguarda ovviamente la conoscenza diretta del settore
Locale della Pubblica Amministrazione, senza il quale non sarebbe
sensato proseguire il lavoro.
Il CSI Piemonte, che gestisce l’area Piemontese della Pubblica
Amministrazione, dispone di circa 450 basi dati di 12 delle più importanti
amministrazioni Piemontesi in grado di coprire gran parte dell’intera area
regionale dei servizi al cittadino e alle imprese.
Con tale conoscenza posseduta sotto forma di schemi logici è possibile
ottenere schemi relazionali, tabelle, descrizioni di tabelle, attributi,
descrizione di attributi e vincoli di integrità referenziale tra tabelle.
20
Schemi
Logici
Schemi
Concettuali
Pubblica
Amministrazione
Locale
Pubblica Amministrazione Centrale
Gerarchie di generalizz.:
-Soggetto -Documento -Luogo -Bene
Schemi
Astratti
Schemi Base
Repository degli
Schemi Concettuali
della PAL
Figura 10: Input per la metodologia PAL
Di supporto agli input descritti è necessario affiancarsi della presenza della figura
di un esperto. Data l’automazione della metodologia che si basa su euristiche, è
necessaria una verifica tecnica che ha lo scopo di correggere gli schemi
concettuali prodotti e analizzare la struttura del repository creato alla fine del
lavoro.
Come nel caso PAC, la metodologia di lavoro si compone di 2 fasi principali:
Riconcettualizzazione degli schemi logici delle basi datia. . La conoscenza
fornita dal gestore della Pubblica Amministrazione Locale Piemontese è
sotto rappresentata sottoforma di schemi logici, poco manipolabili
concettualmente; è necessaria quindi una operazione di reverse
engineering che segua una metodologia specifica.
b. Integrazione-astrazione. Operazioni già descritte precedentemete atte alla
creazione del Repository. La clusterizzazione e la modalità di
accoppiamento degli schemi seguono un modello simile a quello proposto
dalla IDC (vedi Figura 6) ma fortemente specifico per la località territoriale.
21
I passi metodologici per la riconcettualizzazione di schemi logici delle basi dati PAL
Per ogni schema logico rappresentativo di un database della PAL è necessario
applicare una metodologia di reverse engineering al fine di ottenere una
completa serie di schemi concettuali di base, i quali poi verranno integrati e
astratti per l’ottenimento della piramide concettuale.
Tale metodica si compone di 4 passi, ognuno dei quali applica specificatamente
un algoritmo che utilizza dei dati in input per produrre uno schema risultato
parziale.
A seguito di tali passi operativi è presente il passo del Domain Expert Check in
cui la figura dell’espero analista è fondamentale per certificare la correttezza dei
risultati prodotti.
Passo 1. Estrazione delle entità
Input: Le quattro gerarchie di generalizzazione PAC
Input: Database PAL sottoforma di Schema Logico
Scopo di questa fase è ricercare tutte le entità correlate ad un database,
cioè estrapolare degli elementi di conoscenza da un archivio prescelto della
Pubblica Amministrazione Locale.
Per fare ciò è richiesto un algoritmo comparativo che lavori su ogni nome
delle entità nella lista delle gerarchie comparandolo con alcuni elementi
dello schema logico del database PAL, in particolare si necessita un
controllo sui nomi e descrizioni delle tabelle e sui nomi e descrizioni degli
attributi (campi).
Lo scopo dell’algoritmo comparativo è la generazione di un valore
sottoforma di un punto in uno spazio a 4 dimensioni secondo la seguente
uguaglianza:
P(concetto) = <#nomi_tabella, #descriz_tabella, #nome_attributo. #descriz_attributo>
22
dove ogni elemento # corrisponde al numero di elementi trovati che hanno
distanza con il concetto inferiore di un certa soglia prefissata.
Un concetto è selezionato se la somma degli elementi # supera un secondo
valore di soglia. In questo caso il concetto può essere classificato come
entità o come attributo a seconda della più stretta vicinanza ad uno di questi
due punti:
Pentità = <#nomi_tabella, #descriz_tabella, 0, 0>
Pattributo = <0, 0, #nome_attributo. #descriz_attributo>
Resta ora solo il fatto di associare gli attributi con le entità; questa scelta è
facilmente operabile abbinando gli attributi con le entità più vicine nello
spazio.
Infine, nello schema concettuale di output vengono inserite solo le entità,
con i relativi attributi, che hanno una frequenza di matching superiore di un
certo valore di soglia fissato.
Output: Schema Concettuale con entità indipendenti.
23
Gerarchie di
Generalizzazione
Schema Logico
E1
E2
E3
….
E1
E2 E3
Documento Luogo Soggetto Bene
Schema Concettuale
Figura 11: Estrazione delle entità
Passo 2. Aggiunta delle generalizzazioni
Input: Le quattro gerarchie di generalizzazione PAC
Input: Lo schema Concettuale parziale precedentemente ottenuto
Lo schema ottenuto nella Passo 1 viene arricchito con le generalizzazione
tra le entità. Per effettuare tale operazione si riprendono i nomi delle entità
selezionate nello schema concettuale e si ricercano nelle liste di
generalizzazione collegandole tra loro in modo opportuno.
Output: Schema Concettuale arricchito con le generalizzazioni.
24
Gerarchie di
Generalizzazione
E1
E2
E3
E1
E2 E3
Documento Luogo Soggetto Bene
Schema Concettuale
arricchito
E1
E2
E3
Schema Concettuale
precedente
Figura 11: Aggiunta delle generalizzazioni
Passo 3. Estrazione delle relazioni
Input: I 500 schemi Concettuali di base della PAC.
Input: Le quattro gerarchie di generalizzazione PAC.
Input: Lo schema Concettuale parziale precedentemente ottenuto.
Le relazioni tra le entità sono da ricercarsi tra tutti gli schemi concettuali di
base della PAC. Per questo lavoro è necessario utilizzare un algoritmo di
comparazione che selezioni tutte le coppie di entità dello schema
concettuale provvisorio che si relazionano in quelli PAC. Sono da
considerarsi valide le relazioni dirette (E1-E3) e quelle indirette passanti per
altre entità (E1-Ex-..En-..-Ey-E3).
Inoltre, a seguito dell’impiego di generalizzazioni, le entità figlie ereditano le
proprietà dai padri, tra cui le relazioni. Dunque, è altresì indispensabile
ricercare le relazioni eventuali anche con i predecessori delle entità e
attribuire a questi le relazioni trovate.
25
Il nome assegnato alla relazione tra due entità è quello maggiormente
frequente negli schemi base PAC, oppure in seconda ipotesi può essere
assegnato dalla figura dell’esperto di dominio.
Output: Schema Concettuale arricchito delle relazioni
Gerarchie di
GeneralizzazioneE1E2
E3 Documento Luogo Soggetto Bene
Schema Concettuale
arricchito
E1 E2
E3
E1 E2
E3 E1
E2
E3
Schemi Base PACE1 E1 E2 E3
Figura 12: Aggiunta delle relazioni
Passo 4. Controllo schema con i vincoli di integrità referenziale
Input: Lista dei vincoli tra tabelle nei database PAL
Input: Lo schema Concettuale parziale precedentemente ottenuto
In questa fase è necessario possedere una lista di vincoli tra tabelle sullo
schema logico del database della PAL considerato. Lo scopo di questa
parte di algoritmo è quella di migliorare la qualità dello schema concettuale
aggiungendo nuove entità e relazioni favorite dall’analisi dei vincoli
referenziali tra tabelle.
Analizzando ogni coppia di tabelle collegate, si cercano le eventuali entità
associate e si pongono le seguenti considerazioni:
o Se entrambe le tabelle della coppia non sono associate ad entità, si
passa all’analisi della coppia successiva senza effettuare operazioni.
26
o Se solo un nome tabella della coppia è associato ad una entità allora
l’altra tabella viene inserita nello schema concettuale creando una
nuova relazione.
o Se entrambi i nomi tabella sono associati ad entità si verifica
l’esistenza di una relazione, se non esiste la si crea.
Output: Schema Concettuale arricchito dei vincoli
Figura 13: Controllo schema con i vincoli referenziali
Passo 5. Verifica dell’esperto
Input: Lo schema Concettuale parziale precedentemente ottenuto
Ultima fase della metodologia di riconcettualizzazione degli schemi logici
delle basi dati della Pubblica Amministrazione Locale è la verifica della
correttezza dello schema Concettuale. Tale schema deriva dalla creazione
automatica derivante da una metodologia che fa uso di euristiche e dunque
potenzialmente affetto da errori e mancanze.
Il compito dell’esperto di dominio è la modifica dello schema concettuale
secondo il proprio volere dettato dalla propria esperienza. La modifica
K3
K2 …..
Schema
Concettuale
Schema Logico con
vincoli tra tabelle
Schema
Concettuale E1 E2
E3
E1 E2
E3
E1 E2
E3
27
contempla operazioni di aggiunta, cancellazione o correzione di concetti
espressi nello schema.
Output: Schema Concettuale finale
Molto frequentemente capita che lo schema finale e quello proposto
dall’automazione coincidono, questo fatto indica la correttezza, e dunque la
validità, della metodologia applicata.
I passi metodologici per la creazione degli schemi astratti PAL
La metodologia descritta fino a questo punto è utile solo alla creazione degli
schemi concettuali rappresentanti ogni base dati della conoscenza della Pubblica
Amministrazione Locale. Per ottenere il repository è necessario astrarre ed
integrare gli schemi finora prodotti in modo da ottenere una piramide di concetti.
I primi 3 passi della metodologia per la creazione degli schemi concettuali sono
effettuati con l’ausilio della conoscenza PAC e, in tal modo, possono essere
facilmente confrontati con gli schemi caratterizzanti il repository della Pubblica
Amministrazione Centrale.
A tale scopo, lo schema concettuale creato con la metodologia precedente può
essere separato in due parti:
o Schema iniziale. È l’insieme di entità con i rispettivi attributi, comprensivi
delle generazioni e delle relazioni, ottenute nei primi 3 passi della
metodologia PAL per la creazione degli schemi concettuali. La
conoscenza contenuta deriva dall’esperienza PAC applicata al campo
locale dell’Amministrazione.
o Schema arricchito. È lo schema concettuale ottenuto dal completo
svolgimento dei 5 passi della metodologia. Comprende della conoscenza,
come i vincoli tra tabelle ed elementi aggiunti dall’esperto, specifica del
campo locale della Pubblica Amministrazione.
28
Schema arricchito
Schema iniziale
Schema concettuale Repository PAL
Figura 14. Spaccatura dello schema concettuale e posizione delle parti.
Dopo tale classificazione, gli schemi arricchiti possono essere posizionati alle
base della piramide opportunamente raggruppati per genere di appartenenza.
Mentre gli schemi iniziali possono essere confrontati con la piramide PAC per
poter essere inseriti nella corretta posizione del repository PAL. Tale posizione
può essere determinata in base alla posizione delle entità presenti negli schemi
iniziali rispetto alle 4 generalizzazioni presenti nelle gerarchie di
generalizzazione.
La metodologia per la creazione degli schemi astratti lavora con i seguenti passi
successivi per ogni schema concettuale PAL prodotto:
Passo 1. Clusterizzazione dello schema arricchito.
Gli schemi concettuali ottenuti nella fase di riconcettualizzazione (schemi
arricchiti) vengono raggruppati in gruppi di omogenea natura.
In questo passo lo schema arricchito viene aggiunto ad un cluster. La
misura della vicinanza tra schemi può essere ottenuta dalla similarità dei
concetti presenti negli schemi di base clusterizzati nella base del repository
PAC.
Passo 2. Calcolo del livello di astrazione dello schema iniziale
In questa fase viene associato un valore di astrazione VALi allo schema
iniziale i tramite un algoritmo che segue la seguente sottoprocedura.
29
o Si divide lo schema in gruppi corrispondenti alle 4 gerarchie (bene,
soggetto, documento, luogo).
o Per ogni gruppo si calcola il corrispettivo valore di astrazione dato
dalla somma delle distanze dal livello massimo nella gerarchia in
proporzione al numero di concetti presenti nel gruppo.
o Il valore di astrazione VALi dello schema iniziale sarà la media
pesata dei 4 livelli di astrazioni calcoli sui gruppi.
Passo 3. Associazione dello schema iniziale ad un livello astratto
Similarmente, per ogni schema astratto della piramide PAC (vedi figura 7)
viene calcolato un valore di astrazione VACj con la sottoprocedura al passo
2 e, successivamente, si può associare un valore ALlivello al livello di
astrazione della piramide PAC ottenuto dalla media dei valori VACj
posizionati a tal livello.
Ora è possibile associare lo schema iniziale PAL al livello k astratto PAC
con valore AL più vicino a VAL . k i
Passo 4. Creazione dello schema astratto PAL
Per ogni schema astratto SCkj del livello k della piramide PAC prescelto nel
passo precedente si estraggono i concetti che appartengono anche allo
schema iniziale PAL e si aggiungono allo schema astratto SLkj nella
piramide PAL simmetrica a quella PAC.
Con il completamento di tali passi su tutti gli schemi concettuali PAL si ottiene il
completamento del repository della Pubblica Amministrazione Locale.
30
Confronto con altre metodologie
La letteratura a riguardo è molto vasta, l’interesse verso i repository delle basi
dati nutre molta curiosità anche in campi lontani dalla Pubblica Amministrazione.
L’interesse in materia si divide su due aspetti del mondo dei repository.
o Le primitive per l’organizzazione dei repository e le metodologie per la sua
produzione.
o Nuovi metodi per rappresentare la conoscenza del repository.
Mirbel (1997) propose un lavoro attinente al primo interesse. Usando un modello
descrittivo basato su parole e concetti, l’autore si prefissa lo scopo di ottenere
delle primitive di integrazione su schemi a oggetti al fine di ottenere come
risultato la creazione di schemi astratti. Tali funzioni sono molto simili a quelle
usate in questa tesi, ma Mirbel non ha dato prova di un’efficacia pratica su un
progetto di larghe dimensioni.
Nei lavori Castano, De Antonellis e Pernici (1998) e Castano e De Antonellis
(1997) si propongono dei criteri e delle tecniche per il confronto tra database. Le
tecniche consistono nell’estrazione di concetti e gerarchie di concetti da ogni
singolo database per il successivo confronto incrociato. La generazione dei
concetti è possibile grazie all’utilizzo di un dizionario semantico che abbina
elementi del database con concetti per vicinanza semantica. Perplessità si
manifestarono comunque al momento dell’effettiva applicazione nel campo della
Pubblica Amministrazione.
Il documento di Shoval, Danoch e Balabam (2004) punta all’affermazione del
concetto di schema astratto pacchettizzato. Il metodo di rappresentazione Entità-
Relazioni è nuovamente utilizzato e l’astrazione viene formalizzata tramite
raggruppamento di concetti; nei nuovi schemi astratti creati, le entità pacchetto
sostituiscono interi gruppi di entità e relazioni presenti negli schemi a più basso
livello.
31
In questo lavoro il concetto di astrazione è più curato ed espanso, e sicuramente
le primitive sono più potenti di quelle presenti nella metodologia utilizzata in
questa tesi, ma non viene minimamente accennata l’integrazione. L’unione
integrazione-astrazione permette maggiori vantaggi producendo una visione
riassuntiva dei livelli sottostanti, mentre l’uso dei pacchetti pone solo dei link a
delle realtà complesse.
Sulla parte della rappresentazione della conoscenza all’interno dei repository si
possono confrontare i seguenti documenti.
Nei lavori di Wang e Gasser (2002), Di Leo, Jacobs, Pand e De Loach (2002) e
Fanquhar, Fikes, Pratt e Rice (1995) si discute su allineamento e l’integrazione di
ontologie dove l’integrazione di concetti è ottenuta grazie a delle precise
terminologie standardizzate.
Nei documenti viene trattato l’uso di alcuni tool e servizi atti all’utilizzo delle
ontologie condivise su reti geografiche distribuite. Grazie a tali programmi è
possibile costruire nuove ontologie importando concetti da moduli archiviati in
librerie.
Interessante infine il lavoro di Pan, Cranfield e Carter (2003) incentrato su un
sistema multiagente basato su ontologie con lo scopo di ottenere una
comunicazione non ambigua tra agenti. Tale ontologia definisce termini e
vocaboli usati nei messaggi codificati spediti nella comunicazione. In questo
utilizzo un repository sarebbe necessario al fine di condividere e riutilizzare
ontologie.
La metodologia narrata in questa tesi ha dei forti punti di vantaggio rispetto ad
altri lavori. Tali aspetti possono essere elencati di seguito e si possono ritrovare
descritti in maggior dettaglio nelle varie sezioni di questo del documento.
o L’utilizzo combinato delle primitive di integrazione-astrazione adottate per
la costruzione del repository.
o L’attenzione alla fattibilità e al ridotto utilizzo di risorse.
32
o Il riuso.
o L’impiego concreto delle metodologie in una realtà di interesse in larga
scala mediante l’implementazione in un tool.
L’utilizzo di euristiche per la riduzione delle risorse può generare in alcuni casi
errori o mancanze negli schemi concettuali, ma tali approssimazioni portano
indiscutibili vantaggi pratici.
33
Il tool
A seguito della metodologia descritta nei capitoli precedenti l’obbiettivo prossimo
per concretizzare l’opera è l’implementazione.
Per testare al meglio il programma creato sono necessarie le conoscenze di
base delle Pubbliche Amministrazioni, Centrale e Locale; mentre per la prima è
possibile riutilizzare le informazioni dei lavori svolti anni addietro, per la parte
Locale è stato indispensabile l’appoggio di una entità esterna che manipolasse
tale conoscenza.
L’interesse nella creazione di un tool è stato colto da un ente privato che,
mettendo a disposizione la conoscenza di un esperto è stato in grado di seguire
l’autore di questa tesi nella scelta degli algoritmi implementativi che più si
avvicinassero alla metodologia di costruzione del repository.
Tale collaborazione ha avuto la durata di 6 mesi, alla fine dei quali è stata
consegnata una versione affidabile e completa del tool per la creazione di
repository.
Il CSI Piemonte: organizzazione, ruolo e architettura tecnologica
L’ente che ha posto interesse nel progetto è il Consorzio dei Sistemi Informativi
della regione Piemonte (CSI Piemonte). Tale azienda serve quasi centralmente
l’intero patrimonio della Pubblica Amministrazione Locale nella regione e negli
ultimi anni ha visto cresce la sua conoscenza nella gestione di circa 450 basi dati
di 12 delle più importanti amministrazioni locali.
La mole di dati a disposizione del CSI è molto vasta e può essere considerata
un’ottima base per l’estrazione della conoscenza necessaria ai passi
34
metodologici per la riconcettualizzazione degli schemi logici e per la creazione
degli schemi astratti.
Il consorzio con sede a Torino dispone di una conoscenza centralizzata
conservata nel proprio sistema informatico e visibile all’interno di tutta la intranet
aziendale.
Tale mole di dati è gestita da un sistema a lato server chiamato InfoDir, che ne
manipola e ne rende accessibile il contenuto su tutta la rete.
Per gli scopi preposti dal CSI, la conoscenza di InfoDir è popolata da strutture
dati chiamate Collezioni, contenenti un insieme di metadati riferiti ad una
particolare vista della Pubblica Amministrazione Piemontese. Ogni Collezione è
partizionata in 2 parti strettamente collegate tra di loro.
o I Servizi. Una serie di procedure destinata alle imprese e al cittadino che
sono messe a disposizione dagli enti della PAL.
o Le Basi Dati. Lo schema logico/fisico di tutte le basi dati delle 12
amministrazioni gestite dal CSI. Da tale conoscenza è possibile estrarre
informazioni utili quali i nomi dei database, i nomi e descrizioni delle
tabelle e i campi (attributi), e i vincoli di integrità referenziale esistenti tra
tabelle.
InfoDir
Collezioni
BasiDati Servizi
Tassonomia
per materia Tassonomia
per istituzione
Tabelle
Campi
Componenti architetturali
Figura 15. Schema di InfoDir.
35
Per lo svolgimento di una procedura possono essere necessarie più fonti dati,
dunque ad ogni Servizio può essere associato una o più Basi Dati, e
simmetricamente una Base Dati può essere associata a più Servizi.
I dati forniti da InfoDir possono essere visualizzati secondo delle tassonomie
create appositamente per degli scopi prefissati. Due di queste sono state
utilizzate nella sperimentazione del tool ed elencano la conoscenza della
Pubblica Amministrazione secondo le materie (o argomento) trattate dalle varie
sezioni, oppure per istituzione.
I dati PAL necessari alla metodologia possono essere estratti dal catalogo InfoDir
e importati da tool di modellazione e rappresentazione che formattano la
conoscenza e creano ad hoc dei file pronti ad essere importati nel tool obbiettivo
di questa tesi.
Le prime specifiche
Precedentemente alla progettazione del tool si sono definiti una serie di vincoli
che il programma dovrà garantire una volta terminato il processo di
implementazione.
In prima analisi si definirono una serie di vincoli atti alla creazione di un piccolo
tool ristretto alle funzionalità dettate dalla metodologia citata nei capitoli
precedenti. In base a tali direttive le funzioni che il tool doveva supportare erano
le seguenti.
o Produzione di una funzione che dato in input uno schema logico, produca
in output uno schema concettuale seguendo i 5 passi della metodologia di
riconcettualizzazione.
36
o Produzione di una funzione che dato in input n schemi concettuali,
produca in output uno schema concettuale secondo la metodologia
dell’integrazione-astrazione per la produzione di schemi astratti.
A seguito di una rapida e compiaciuta implementazione, a tali funzionalità se ne
sono poi aggiunte altre allo scopo di rendere più potente e funzionale il tool. Tali
migliorie sono descritte nelle sezioni successive.
La metodologia implementata per la PA Locale
Il processo di sviluppo prevede la creazione di una serie di funzioni atte ognuna
all’implementazione di un passo della metodologia. Tali funzioni vengono poi
richiamate da altri metodi di più alto livello che ne gestiscono la sequenza.
Allo scopo di realizzare nel più breve tempo possibile una versione del tool
stabile e completa si è deciso di porre delle approssimazioni alla metodologia
originale sui dati PAL. Tali euristiche risiedono negli algoritmi applicati in ogni
funzione, dunque non si è modificata la struttura metodologica delle operazioni
ma soltanto alcuni aspetti che in futuro potranno essere facilmente modificati
riscrivendo le funzioni interessate.
L’utilizzo di euristiche ha interessato sia la metodologia per la
riconcettualizzazione degli schemi logici, sia quella per l’integrazione-astrazione
per la creazione di schemi astratti.
37
La metodologia semplificata per la riconcettualizzazione
Una prima scelta attuata che diverge dalla metodologia PAL teorica è la non
creazione di un unico schema concettuale espanso di passo in passo.
Tale scelta è stata dettata dalla complessa costruzione di un modello che
rappresenta uno schema concettuale; l’utilizzo dei costrutti atti a contenere
informazioni sullo schema (quali entità, attributi, relazioni e vincoli) richiederebbe
poi l’ausilio di un tool specifico per la riproduzione di schemi grafici con
conseguente complicazione delle prime fasi di sviluppo.
A tale scopo, si è preferito creare un semplice output testuale specifico per ogni
passaggio che ne contenesse le informazioni raccolte. L’insieme di tali schemi
prodotti nei passi per la riconcettualizzazione forma un set di informazioni
indipendenti tra loro che possono essere analizzate singolarmente.
Inoltre si è deciso di snellire la procedura di estrazione delle entità e degli attributi
separando il processo in due passi distinti; tale scelta è derivata dalla notevole
complicazione dell’algoritmo di estrazione delle entità, il quale ha subito anche
una modifica completa nell’algoritmo di pesca dei concetti.
Le limitazioni apportate hanno sicuramente degradato il livello qualitativo del
prodotto finale in relazione con la metodologia originale PAL, ma ha garantito
una rapida produzione di una prima versione affidabile del tool.
38
Add Entity Add
Generalization Add
Relationship Add AttributeInfer
Constraints
Set di informazioni
Figura 16. Schema della metodologia di riconcettualizzazione dello schema logico di una base
dati PAL
Le nuove funzioni per la riconcettualizzazione di schemi logici seguono i seguenti
passi.
Passo 1. Add Entity (Estrazione delle entità)
Input: Le quattro gerarchie di generalizzazione PAC
Input: Struttura della Pubblica Amministrazione Locale
In questa prima fase di sviluppo si è deciso di utilizzare un metodo di
confronto più semplice per ritrovare i concetti all’interno di un database PAL.
Ogni entità all’interno delle quattro gerarchie ha abbinata una stringa che ne
identifica la sostanza. Tale stringa è utilizzata come criterio like per il
confronto rapido con gli elementi nello schema logico della base dati, tali
elementi di confronto sono i nomi e le descrizioni delle tabelle e dei campi.
Il confronto è basato su query SQL che hanno il vantaggio di produrre
risultati con una estrema velocità di elaborazione.
Se la funzione like di una entità restituisce almeno un confronto positivo su
un elemento dello schema logico, tale entità viene considerata
rappresentativa della base dati e viene passata in output.
Output: Lista delle entità abbinate alla base dati PAL
Output nascosto: Lista delle entità affiancate dall’elemento generante dello
schema logico
39
Gerarchie di
Generalizzazione E1
E2E3 Documento Luogo Soggetto Bene
Schema Logico di
una base dati PAL
Lista nascosta delle
entità con elementi
generanti
E1
E2
E3
E1
E2
E3
Lista
delle entità
Figura 17. Add Entity
Passo 2. Add Generalization (Aggiunta delle generalizzazioni)
Input: Le quattro gerarchie di generalizzazione PAC
Input: La lista delle entità precedentemente ottenuta
L’aggiunta delle generalizzazioni alle entità trovate viene effettuata
riutilizzando il listato di output del passo precedente. Ogni entità letta in tale
elenco viene ricercata nelle quattro gerarchie di generalizzazioni e risalendo
l’albero gerarchico si annotano tutte le entità padre incontrate.
Output: Lista con le gerarchie delle entità
40
Gerarchie di
Generalizzazione E1
E2E3
Documento Luogo Soggetto BeneE4
Lista delle entità
Lista delle
Generalizzazione
E4.generaliz.E2.generaliz.E1
E4.generaliz.E2
E3
E1
E2
E3
Figura 18. Add Generalization
Passo 3. Add Relationship (Estrazione delle relazioni)
Input: Elenco delle relazioni degli schemi concettuali di base PAC
Input: La lista delle gerarchie di entità ottenuta al passo precedente.
Per questa fase è necessario disporre di una lista di tutte le coppie di entità
che sono in relazione negli schemi concettuali PAC. È possibile ottenere
tale lista estraendo della conoscenza dal materiale informatico a
disposizione che incorpora il repository PAC.
Nelle prime fasi di sviluppo, a scopo di test, è stato utilizzato un ridotto
numero di relazioni tra entità estrapolate solamente dallo schema
concettuale al vertice della piramide. Tali relazioni mostrano solo i legami
tra le entità di più alto livello (vedi figura 8).
L’algoritmo utilizzato in questo passaggio prevede l’analisi delle relazioni
verificando l’esistenza di ogni entità della coppia nella lista delle gerarchie di
entità trovate nel database PAL. In caso positivo la relazione viene passata
in output conservando il nome della relazione PAC.
Il controllo su ogni entità delle gerarchie può creare ridondanza sulle
relazioni, in quanto può capitare che si associ la stessa relazione sia ad una
41
entità padre sia al figlio, ma per le prime fasi di sviluppo questo metodo ha
portato notevoli vantaggi in termini di tempo e di completezza del lavoro.
Output: Lista delle relazioni tra entità PAL.
Lista delle
Generalizzazione
E1.relaz.E6
E1.relaz.E3
E3.relaz.E4
…
E19.relaz.E14
Lista delle relazioni
tra entità PAC
E4.relaz.E3
E3.relaz.E1 Lista delle Relazioni tra
entità nella base dati PAL
E4.generaliz.E2.generaliz.E1
E4.generaliz.E2
E3
Figura 19. Add Relationship
Passo 4. Add Attributes (Aggiunta degli attributi)
Input: Lista delle entità affiancate dall’elemento generante dello schema
logico, prodotto nel passo 1
Semplicemente, in questo passo viene prodotta in output una lista ordinata
dei nomi delle entità con abbinati gli elementi dello schema logico definiti
come attributi. Un elemento può essere definito attributo se:
o è un nome di un campo dello schema logico ed è stato selezionato
dalla funzione like del passo 1.
o è un nome di un campo dello schema logico e la sua descrizione è
stata selezionata della funzione like del passo 1.
Si noti che vengono selezionati solo i nomi dei campi, tralasciando i nomi
delle tabelle e delle descrizioni.
Output: Lista delle entità con i relativi attributi
42
E1
E2
E3
Lista nascosta delle
entità con elementi
generanti
E1
att1 descr
E2
attr2 descr
attr3 descr
E3
attr4 descr
Lista entità del database
PAL con i relativi
attributi
Figura 20. Add Attributes.
Passo 5. Infer Constraints (Controllo schema con i vincoli di integrità
referenziale)
Input: Elenco dei vincoli tra tabelle nei database PAL
Input: Lista delle entità affiancate dall’elemento generante dello schema
logico, prodotto nel passo 1
Il passo corrente permette di migliorare le relazioni tra entità aggiungendo
quelle prodotte dai vincoli di integrità referenziale tra tabelle nello schema
logico. Per questo scopo è necessario possedere una conoscenza specifica
della base dati in analisi che contenga la lista dei vincoli di referenza tra i
nomi delle tabelle.
Accoppiando tale conoscenza con la lista delle entità abbinate alle tabelle
(ricavata dal secondo input) si effettuano i seguenti controlli:
o se entrambe le tabelle referenziate sono abbinate a delle entità allora
tali entità vengono referenziate in output.
o se solo una tabella è abbinata ad una entità allora tale entità viene
referenziata in output con la tabella non abbinata ad entità.
43
Le tabelle elencate in output che non sono abbinate ad entità vengono
considerate tabelle esterne.
Output: Lista delle referenze tra due entità
Output: Lista delle referenze tra una entità e una tabella esterna
Output: Lista delle tabelle esterne
Tab1.refer.Tab6
Tab1.refer.Tab3
Tab3.refer.Tab4
…
Tab19.refer.Tab14
Lista delle relazioni
tra entità PAC
E2.refer.E3
E3.refer.Tab2
E2.refer.Tab2
E4 refer Tab1
Lista delle
tabelle esterne
E1
E2
E3
Lista nascosta delle entità
con elementi generanti
Tab2
.Tab1
Lista delle Relazioni
tra entità nella
base dati PAL
Figura 21. Infer Constraints.
La metodologia semplificata per la creazione di schemi astratti
La metodologia presentata precedentemente ha lo scopo di creare per ogni
database PAL analizzato un set di liste di output, le quali rappresentano
singolarmente una caratteristica dello schema concettuale abbinato al database;
tale schema troverà posto alla base del repository della Pubblica
Amministrazione Locale.
44
La creazione degli schemi sovrastanti differisce dalla metodologia originale PAL,
introdotta nei primi capitoli, in quanto troppo complessa da implementare in un
ristretto periodo di tempo. Lo scopo alla base della presente tesi è la creazione
rapida di un tool che utilizzi il minor numero di risorse, e dunque si è preferito
optare per una metodologia più semplice, ma comunque efficace, con lo scopo di
portare a conclusione il progetto.
Tuttavia, in vista di futuri miglioramenti, la progettazione è stata fatta in modo
modulare con la possibilità di intervenire su alcuni aspetti implementativi per
migliorarne la qualità ed avvicinarsi alla metodologia originale PAL.
L’avanzamento nella creazione degli schemi astratti avviene in maniera graduale
e crescente dalla parte inferiore della piramide fino ad arrivare al vertice.
Differentemente, nella metodologia originale la creazione avveniva in modo
sparso, con la creazione a macchie di schemi concettuali astratti che ottenevano
la loro posizione all’interno della piramide seguendo come esempio la struttura di
quella PAC.
Nella fase di implementazione non si è seguita tale strada; come accennato in
precedenza, il CSI dispone di alcune tassonomie che generalizzano concetti PAL
legate alle basi dati in proprio possesso, queste tassonomie hanno il vantaggio di
rappresentare un repository PAL specifico della regione di competenza e
possono essere utilizzate come linee guida per l’integrazione-astrazione di
schemi concettuali. La struttura di tali tassonomie viene spiegata nei capitoli
successivi.
Secondo tali cambiamenti la metodologia applicata alla creazione di schemi
astratti diverge completamente da quella originale, ma riprende i concetti basilari
delle operazioni di integrazione e astrazione.
Con l’utilizzo di una tecnica di selezione dei concetti fondamentali si è potuto
fondere in un unico passo metodologico le operazioni di integrazione e
astrazione. Tale tecnica è mostrata di seguito:
45
Passo Unico. Integrazione e astrazione di schemi concettuali
Input: n Set di liste rappresentanti n schemi concettuali da integrare/astrarre
L’algoritmo per l’integrazione e l’astrazione è indivisibile. In un solo
passaggio la procedura seleziona gli elementi candidati a poter essere
rappresentati anche al livello gerarchico più alto, ed esclude tutti quelli non
fondamentali che possono rimanere nel livello di appartenenza per dare
consistenza allo strato stesso.
L’operazione può essere eseguita su n schemi concettuali, dove n è
maggiore o uguale a 1 e la scelta dei componenti da importare nel nuovo
schema astratto è dato dalla seguente regola:
o se n=1 vengono esportati tutti gli elementi. Ciò vuol dire che se si
opera solo su uno schema, verrà restituito uno schema astratto
identico al primo senza aver operato nessuna astrazione. In questo
caso l’intervento umano dell’esperto apporrebbe il giusto tasso di
astrazione modificando la costituzione dello schema.
Al solito, il nuovo schema astratto sarà rappresentato dal set di liste
che ne contengono le varie caratteristiche.
o se n>1 viene creato uno schema astratto con il seguente principio. Il
procedimento per la creazione opera sulle fonti concrete
rappresentative degli schemi concettuali da integrare/astrarre, cioè i
set di liste. A seconda della lista, si opera in modo diverso.
Esportazione delle entità.
Il componente fondamentale su cui si basa l’astrazione è l’entità,
si assumono come fondamentali quelle entità comuni a 2 o più
schemi, e tali entità verranno esportate nel nuovo schema.
Esportazione delle gerarchie
Le generalizzazioni tra entità vengono aggiunte eseguendo
nuovamente sullo schema astratto le operazioni eseguite nel
passo specifico nella riconcettualizzazione degli schemi logici
(Add Generalization).
Esportazione delle relazioni
46
Come per le generalizzazioni, si esegue sullo schema astratto la
stessa procedura utilizzata nella riconcettualizzazione degli
schemi logici (Add Relationship).
Esportazione degli attributi
L’aggiunta degli attributi invece segue lo stesso identico
procedimento delle entità. Per ogni entità esportata si
aggiungono i suoi attributi che sono comuni a 2 o più schemi.
Esportazione delle tabelle esterne
Le tabelle esterne vengono esportate con la medesima regola
della presenza in almeno 2 schemi da integrare/astrarre.
Esportazione delle relazioni di inferenza
Infine, si aggiungono le relazioni di inferenza date dai vicoli tra
tabelle, i collegamenti che verranno esportati devono avere la
peculiarità di collegare entità o tabelle già presenti nel nuovo
schema astratto ed essere presenti in almeno 2 schemi
concettuali da integrare/astrarre.
Output: 1 Set di liste con contenuti astratti
Figura 22. Integrazione-astrazione di 3 schemi concettuali.
47
Il processo di sviluppo
A fronte della definizione di una metodologia teorica da utilizzare e nella sua
corretta rivisitazione per l’atto pratico, si è potuti passare alla parte
implementativa.
Il primo obbiettivo perseguito è stato soddisfare le prime due specifiche richieste:
la creazione di uno schema concettuale e il processo di integrazione-astrazione.
Scelta della modalità di sviluppo
Il contratto lavorativo presso l’azienda convenzionata CSI Piemonte prevedeva
l’utilizzo di una forma di collaborazione di lavoro a distanza causata dalla
lontananza dell’autore della tesi con la sede operativa.
A tal fine è stato stabilito un piano lavorativo che comprendeva 4 giorni lavorativi
autonomi e 1 giorno lavorativo in sede a Torino. In tali giorni si è cercato di
analizzare costantemente l’operato autonomo dell’autore, valutando l’attività
svolta e pianificando quella futura; le giornate in sede hanno prodotto una serie di
colloqui molto fruttuosi, in cui le conoscenze pratiche e teoriche di un esperto e di
un apprendista si fondevano per produrre soluzioni teoriche e di
implementazione.
A seguito della scelta di questa forma di lavoro si è deciso di ottimizzare la
programmazione seguendo una metodologia di sviluppo definita “evolutiva” che
ottimizzasse il lavoro in base alle esigenze di tempo e luogo.
Tale tecnica prevede la collaborazione stretta tra il committente e il
programmatore per uno sviluppo rapido e preciso in base alle richieste
sottoposte. L’utilizzo della programmazione evolutiva ha il vantaggio di poter
iniziare l’opera di sviluppo anche nel caso in cui non siano state chiarite a pieno
le specifiche, o non si sono apprese completamente le nozioni inerenti al
contesto del progetto.
48
Quest’ultimo scenario descrive perfettamente la realtà accaduta, dove il team di
lavoro, composto dall’autore e dal referenze aziendale del CSI, ha dovuto
formalizzare una metodologia implementativa al fine di semplificare quella
originale PAL.
Grazie allo sviluppo evolutivo le fasi di specifica, sviluppo e validazione sono
frammischiate tra loro, partendo infatti da una specifica astratta si sviluppa un
primo prototipo che può poi essere raffinato.
Versione
iniziale
Versioni
intermedie
Versione
finale
Specifiche
ad alto livello
Specifiche
Sviluppo
Validazione
Figura 23. Flussi di lavoro nello sviluppo evolutivo.
La fase di sviluppo quindi ha visto svolgersi la fase di studio di nuove tecniche e
soluzioni nell’unica giornata di incontro in sede, dedicando gli altri giorni
all’implementazione per la creazione di versioni intermedie sempre più elaborate
che si avvicinassero sempre più al prodotto finale.
Scelte implementative
La prima fase di sviluppo del software ha visto come argomento centrale la scelta
dei mezzi implementativi; la decisione dei tools per la progettazione e
l’implementazione ha influito notevolmente sul processo di sviluppo software.
49
I candidati all’utilizzo ricadevano nell’insieme dei software di conoscenza
dell’autore e si è cercato di scegliere la soluzione che massimizzasse il rapporto
tra semplicità implementativa e potenza espressiva, in modo da ottenere un tool
efficace ed efficiente.
Il software richiesto si compone di due applicativi con delle particolari
caratteristiche.
o Un ambiente di sviluppo. Un tool di programmazione che permetta una
rapida scrittura del codice per la creazione di tool visuali, riutilizzando a
tale scopo componenti precompilati per la creazione di interfacce con
elementi grafici già noti agli utenti.
Una seconda caratteristica del software atta al rapido sviluppo è la
possibilità di esecuzione e di debug in modalità “step by step” delle
istruzioni, molto utile per l’analisi dell’eseguibile in caso di errori
logici/sintattici in un programma di medie dimensioni.
o Un DBMS. Era noto fin dalle prime fasi che il tool finale avrebbe dovuto
possedere una base di conoscenza non ristretta, immagazzinata in una
struttura per garantire la memorizzazione e la facilità d’utilizzo.
È chiaro che le operazioni più frequentemente utilizzate sulla conoscenza
siano le query per l’ottenimento di particolari selezioni sui dati, e non è di
fondamentale importanza disporre di uno strumento DBMS di elevate
potenzialità, in quanto il tool deve utilizzare un database locale effettuando
semplici operazioni.
A seguito di attente valutazioni la scelta delle applicazioni è ricaduta su Microsoft
Visual Basic 6 come ambiente di sviluppo e Microsoft Access come tool DBMS;
la scelta di tali applicativi è derivata dalla semplicità di utilizzo e dalle buone
conoscenze che l’autore ha in merito ai due software.
50
La conoscenza di base e la sua estrazione
Successivamente alla definizione di una metodologia implementativa e degli
applicativi di sviluppo si è passati alla fase di acquisizione della conoscenza di
base PAL.
Tale fonte, come accennato nella metodologia implementativa del capitolo
precedente, è estratta dal sistema informativo aziendale chiamato infoDir
mediante tool di formattazione di dati e importata nel contenitore di conoscenza
del tool.
La quasi totalità dei dati è immagazzinata in un database gestito dal DBMS
Access per essere facilmente manipolata per restituire al tool le informazioni
richieste.
Di seguito sono elencate le varie parti della conoscenza utilizzate come input per
i passi metodologici.
o Struttura della Pubblica Amministrazione Locale. Contiene la struttura di
tutti gli schemi logici di 450 basi dati di 12 delle più importanti
amministrazioni PAL e costituisce una fotografia dei metadati delle basi
dati censite.
Per ogni base dati si hanno a disposizione i nomi e le descrizioni delle
tavole e dei relativi campi, e si è cercato di rappresentare tale schema
logico in una tabella fisica.
Tale conoscenza è stata memorizzata direttamente nel database Access
in una tabella che avrà dunque la seguente struttura.
Nome base dati
PAL
Descrizione
Tabella
Descrizione
Campo Nome Tabella Nome Campo
Figura 24. Schema della tabella con la struttura PAL.
51
Per praticità viene mostrato un esempio.
…..…..…..….. …..
…..…..…..….. ….. TelefonIndirizzNomCognomCodFis
Due relazioni di una base
dati PAL
…..….. …..…..
CodFiscMatricola
Persone
Matricole
Base Dati: Personale
Schemi logici delle
relazioni di una base dati
PAL
Persone (CodFisc, Cognome, Nome, Indirizzo, Telefono)
Matricole (Matricola, CodFisc)
Base Dati: Personale
Nome Campo Descr.
Tabella
…..Telefono…..Persone Personale …..Indirizzo…..Persone Personale
…..Matricola…..Matricole Personale …..CodFisc…..Matricole Personale
…..Nome…..Persone Personale …..Cognome…..Persone Personale …..CodFisc…..Persone Personale
Descr.
CampoNome Tabella
Nome
Base Dati Rappresentazione degli
schemi intensionali delle
relazioni di una base dati
PAL
Figura 25. Esempio di rappresentazione di uno schema logico.
Il contenuto di tale tabella non può essere mostrato data la sua vastità nel
contenere circa 815000 istanze.
o Le sei gerarchie di generalizzazione. Nel catalogo metadati infoDir
l’aspetto concettuale della Pubblica Amministrazione è stato suddiviso in 6
domini, rispetto ai 4 descritti nelle metodologie; le differenze si
52
concentrano solamente nella creazione dei domini “Territorio” e
“Urbanistica” in aggiunta al dominio “Luogo” per migliorarne la
competenza territoriale; i nuovi domini, infatti, sono stati aggiunti dopo una
sperimentazione manuale effettuata sulla PAL e sono prettamente di
carattere locale.
A seguito di tale modifica, negli schemi concettuali verranno mostrate due
nuove generalizzazioni.
Tali gerarchie vengono memorizzate in una tabella della base dati. È stato
quindi necessario ricercare un metodo per rappresentare una gerarchia
sotto forma di schema intensionale ed estensionale. Questo è stato
permesso grazie all’introduzione di un campo livello che indica il grado
della generalizzazione nella gerarchia, che a sua volta è rappresentata da
un identificativo nel campo “Codice della gerarchia”.
Secondo tali disposizioni lo schema logico della tabella è il seguente.
Codice della
gerarchia
Nome della
generalizzazione Livello Criterio like
Figura 26. Schema della tabella contenente le gerarchie di generalizzazione.
Come descritto nei capitoli precedenti ogni generalizzazione può essere
associata ad una base dati mediante l’abbinamento con degli elementi
dello schema logico tramite stringhe di confronto (criteri like).
Di seguito vengono riportate le schematizzazioni delle 6 gerarchie di
generalizzazione, una completa visione della tabella è allegata in
appendice.
BENE
IMMOBILE
ABITAZIONE
53
FABBRICATO
TERRENO
MOBILE
AUTOMOBILE
ACQUEDOTTO
DEMANIO FERROVIARIO
DEMANIO STRADALE
DEMANIO ARTISTICO STORICO CULTURALE
MERCATO COMUNALE
MUSEI BIBLIOTECHE PINACOTECHE
DEMANIO NECESSARIO IDRICO
BENE PATRIMONIALE
DOCUMENTO
ATTO REGISTRO
DOCUMENTO LIQUIDATO
VERSAMENTO
VERSAMENTO CON DELEGA
LUOGO
LOCALITA
CIVICO
STRADA
VIA
PARTICELLA CATASTALE
PORZIONE
PRIMITIVA GRAFICA
RIFERIMENTO CATASTALE
SUPERFICIE AGRICOLA
UNITA IMMOBILIARE URBANA
SOGGETTO
SOGGETTO FISICO - PERSONA FISICA
ASSISTITO
CANDIDATO
CONTRIBUENTE
APPARTENENTE CATASTO
CONDANNATO
IN ATTESA DI GIUDIZIO
DISOCCUPATO
ITALIANO
RESIDENTE ALL'ESTERO
LAVORATORE
AUTONOMO
DIPENDENTE
IMPRENDITORE
54
PENSIONATO
SEGNALATO
STRANIERO
RICHIEDENTE CITTADINANZA
STUDENTE
TOSSICODIPENDENTE
VOLONTARIO
SOGGETTO GIURIDICO
IMPRESA
TERRITORIO
CARTOGRAFIA DI SERVIZIO
LIMITI TERRITORIALI DI COMPETENZA TECNICO AMMINISTRATIVA
REGIONE
PROVINCIA
COMUNITA MONTANA
COMUNE
ARPA
ASL
AREE DI INTERESSE PER IMPATTO AMBIENTALE
AREA SENSIBILE
DISCARICA
AREE DI INTERESSE URBANISTICO
ISOLATO
VIABILITA' STRADALE
AUTOSTRADA
STATALE
ALTIMETRIA
TOPONOMASTICA
TOPONIMO CTR
BACINO IDROGEOLOGICO
BACINO IDROGRAFICO PRINCIPALE
POZZO
SORGENTE
PRESA
OPERA DI TRASPORTO
INSEDIAMENTO PRODUTTIVO
OPERA DI RECAPITO FINALE
RESTITUZIONE
IMPIANTO DI SOLLEVAMENTO
MODULATORE
SFIORATORE
URBANISTICA
TERRITORIO
COMUNE
55
PRATICA
STRUMENTO
DESTINAZIONE
VINCOLO
PARAMETRO
Figura 27. Elenco completo delle 6 gerarchie di generalizzazione.
o Le relazioni PAC tra entità. Nel database Access sono anche contenute le
relazioni concettuali della PA centrale. Queste relazioni, dedotte dagli
schemi originali della PAC, permetto di correlare le entità delle gerarchie
di generalizzazione nella creazione degli schemi concettuali PAL.
A causa della relativa difficoltà di ottenere automaticamente tutte le
relazioni PAC, la prima versione del tool utilizza soltanto le relazioni tra le
entità al vertice delle 6 gerarchie delle generalizzazioni.
La struttura atta a contenere tali relazioni utilizza 3 campi di una tabella
Access che presenta il seguente schema logico.
Entità From Nome relazione Entità To
Figura 28. Schema della tabella con le relazioni tra entità PAC.
Il contenuto di tale tabella è allegato in appendice.
o I vincoli tra tabelle nei database PAL. L’attività di estrazione dei vincoli
inferenziali tra tabelle è relativamente complessa in quanto non gode di
una completa automazione. Questa situazione nasce dall’infattibilità di
esportare la completa serie di vincoli presenti in tutti i database della
Pubblica Amministrazione Locale; è necessario, infatti, compiere
l’operazione su ogni base dati, rendendo obbligatoria la presenza di una
persona che svolga manualmente l’operazione tediosa dell’analisi
completa di tutti i 450 schemi logici PAL.
56
Per la fase di progettazione sono stati prodotti 3 elenchi di vincoli
infratabellari analizzando i database “MonI”, “AAEP Gestionale” e
“SMRGAA”. Nella successiva fase di testing il numero di elenchi disponibili
è salito a 12.
È comunque controproducente impedire al tool di rappresentare
concettualmente un database in assenza di vincoli inferenziali; si è infatti
preferito rendere questa fase opzionale e svolgibile solo se attuabile.
A seguito di queste considerazioni, si è scelto di far risiedere questo tipo di
conoscenza al di fuori del database Access, scegliendo come altra forma
di memorizzazione un file Excel. Queste scelte derivano da fattori di
praticità, favorendo il lavoro dell’operatore umano nell’attività di
estrapolazione dei vincoli.
Ogni file Excel contiene le relazioni tra tabelle di un solo database PAL,
che darà così il nome al file rendendolo visibile al tool.
Tabella From “referenzia” Tabella To
Figura 29. Schema di un file Excel contenente i vincoli inferenziali tra tabelle di una base dati
PAL.
La figura precedente mette in evidenza delle somiglianze con la struttura
di memorizzazione delle relazioni tra entità, con la sola differenza del
campo verbo. In questo caso infatti si è preferito standardizzare la scelta
con la costante “referenzia”, ma è lasciata all’esperto la possibilità di
cambiare tale campo con una parola più appropriata.
Di seguito segue lo schema riassuntivo delle forme di input per la
riconcettualizzazione di uno schema logico di una base dati PAL.
57
File Excel
Vincoli DB1 PAL
Metaschemi DB PAL
6 Gerarchie
Relazioni Entità PAC Vincoli
DB4 PAL
Vincoli DBn PAL …
Schema DB1
completo
…
Funzione di riconcettualizzazione
Schema DB3
parziale
Schema DB4
completo
Schema DBn
completo
Schema DB2
parziale
Database ACCESS
Figura 30. Schema completo degli input per la riconcettualizzazione.
Progettazione e implementazione delle componenti
A seguito della formalizzazione della metodologia di implementazione e
dell’estrazione della conoscenza si è potuti passati alla fase di sviluppo. Si sono
prodotti, in fase incrementale, i 5 passi per la riconcettualizzazione di uno
schema logico di un database PAL, verificando l’effettiva efficacia del lavoro
svolto prima di passare allo step successivo.
Ogni passo metodologico è svolto da una serie di istruzioni impacchettate in una
funzione che prende il nome dalla fase metodologica. Di seguito vengono
descritte le 5 funzioni base che permettono la riconcettualizzazione, più quella di
integrazione e astrazione.
58
Aggiunta delle entità (addEntity)
Come specificato nella metodologia, al fine di estrarre le entità associate alla
base dati interessata, si confronta il criterio like abbinato ad ogni istanza delle 6
gerarchie di generalizzazione con il contenuto dei campi della tabella del
metaschema del database PAL.
La richiesta in questione trova soluzione nell’unione di due query; la prima
analizza i nomi e descrizioni dei nomi della tabelle, mentre la seconda confronta i
nomi e descrizioni dei campi.
Di seguito viene riportato il testo della query descritta.
SELECT
* into TabellaTemporanea FROM (
SELECT
Gerarchie.Nome AS Entità, MetaSchema.NomeTabella AS Tavola, MetaSchema.DescrizioneTabella AS TavDesc, null as Campo, null as CamDesc
FROM MetaSchema, Gerarchie
WHERE MetaSchema.NomeDataBase = database_scelto and (
(MetaSchema.NomeTabella like Gerarchie.Criterio) Or (MetaSchema.DescrizioneTabella like Gerarchie.Criterio)
) Union All SELECT
Gerarchie.Nome AS Entità, MetaSchema.NomeTabella AS Tavola, MetaSchema.DescrizioneTabella AS TavDesc, MetaSchema.NomeCampo AS Campo, MetaSchema.DescrizioneCampo AS CamDesc
FROM MetaSchema, Gerarchie
WHERE MetaSchema.NomeDataBase = database_scelto and (
(MetaSchema.NomeCampo like Gerarchie.Criterio) or (MetaSchema.DescrizioneCampo like Gerarchie.Criterio)
) );
59
Allo scopo di analizzare solo il range di dati che interessa il database in
questione, si filtra la tabella del metaschema completa della conoscenza PAL
con un opportuno utilizzo del “where” sql.
Dall’esecuzione della query riportata viene prodotta una tabella fondamentale per
il tool, la quale verrà riutilizzata anche per i successivi passi. Nella tabella
temporanea si affiancano le entità emerse con gli elementi generanti risultati
positivi al confronto like.
Volendo descrivere l’attività svolta dalla query è possibile utilizzare anche la
seguente rappresentazione flowchart.
Start su Istanza
DB =db_scelto
Tabella li ke criterioOR
Tab Descr l ike criterio
End su Istanza
No
Si
Aggiungi in output:DB, Tabella, TabDescr,
No
Si
Start su Istanza
DB =db_scelto
Campo likecriterio
ORC ampo Des cr lik e
criterio
End su Istanza
No
Si
Aggiungi in output:DB, Tabella, TabDescr,Campo, CampoDescr
No
Si
Figura 31. Flowchart rappresentante la Query SQL di AddEntity
La funzione procede con la stampa su un file di testo delle entità elencate nella
tabella temporanea prodotta dalla query precedente.
60
La funzione di estrazione delle entità può essere riassunta nel seguente
diagramma delle attività.
Ricevi Nome DB daRiconcettualizzare
Esegui la ricerca delleEntità con la Query
Salva i risultati nellaTabella Temporanea
Stampa su file di testoi nomi delle Entità
Figura 32. Activity Diagram della funzione AddEntity
Aggiunta delle generalizzazioni (addGeneralization)
Il passo successivo nella metodologia implementata ha il fine di rappresentare la
completa gerarchia superiore di ogni entità fino a mostrare il padre alla radice.
Partendo da una entità, presente nella lista prodotta al passo precedente, si
cerca la corrispondente nella lista delle gerarchie di generalizzazione e, attuando
un criterio di ricerca, ci si punta all’entità padre immediatamente superiore.
Tale criterio segue la seguente regola.
Un’entità a è gerarchicamente superiore ad una entità b se:
o a e b sono nella stessa gerarchia
o a ha un indice di posizione inferiore a quello di b, cioè è posizionata più in
alto nella lista gerarchica
o a ha un livello gerarchico inferiore a quello di b (l’entità radice ha livello 1)
Con tali clausole viene creato un insieme parziale A di tutte le entità superiori
all’entità considerata ma, al fine di selezionare solo l’entità padre a*
immediatamente superiore a b, è necessario aggiungere la seguente:
o a* deve avere l’indice di posizione massimo tra tutti quelli nell’insieme A.
61
Il criterio è stato tradotto nella seguente query sql annidata che permette la
selezione dell’entità cercata in un tempo molto breve.
SELECT
distinct(IstanzeSuperiori.Nome) FROM
( SELECT
Gerarchie.* FROM
Gerarchie, (SELECT Gerarchie.id, Gerarchie.cod, Gerarchie.livello FROM Gerarchie WHERE Gerarchie.nome = Entità_Selezionata ) as IstanzaEntità
WHERE Gerarchie.id < IstanzaEntità.id And Gerarchie.cod = IstanzaEntità.cod And Gerarchie.livello < IstanzaEntità.livello
) as IstanzeSuperiori WHERE
IstanzeSuperiori.id = ( SELECT
max(IstanzeSuperiori2.id) FROM (
SELECT Gerarchie.*
FROM Gerarchie, (SELECT Gerarchie.id, Gerarchie.cod, Gerarchie.livello FROM Gerarchie WHERE Gerarchie.nome = Entità_Selezionata ) as IstanzaEntità2
WHERE Gerarchie.id < IstanzaEntità2.id And Gerarchie.cod = IstanzaEntità2.cod And Gerarchie.livello < IstanzaEntità2.livello
) as IstanzeSuperiori2 ) ;
Al fine di ottenere la completa lista generazionale è necessario iterare il processo
di ricerca del padre fino al raggiungimento dell’entità radice.
Tale lista viene proposta in output come stringa nel seguente formato: EntitàRadice.generalizza.PrimoFiglio.generalizza.SecondoFiglio.generalizza…Nsimo
Figlio.generalizza.Entità_Selezionata
Con il passo di generalizzazione termina la fase di inserimento delle entità nello
schema concettuale, ora è dunque possibile archiviare in una tabella temporanea
tutti questi elementi in modo da riutilizzare questa conoscenza per i passi
successivi. Avere una lista semplice e maneggiabile di tutte le entità presenti
faciliterà il compito di cercare le relazioni tra di esse.
62
Di seguito viene presentato il diagramma delle attività del passo in questione.
Leggi l'Entità dallaTabella Temporanea
Ricerca il Padre conla Query
Stampa su file di testola gerarchia dell'Entità
* Per ogni Entità diversa presente nella Tabella Temporanea
* Cicla finchè si arriva alla radice della gerarchia
Figura 33. Activity Diagram della funzione AddGeneralization
Aggiunta delle relazioni (addRelation)
Lo schema finora composto è rappresentato soltanto da entità indipendenti, il cui
unico rapporto può essere una generalizzazione.
Nel passo corrente si cerca di aumentare l’informazione inserendo le relazioni tra
gli elementi presenti. Come descritto nella metodologia PAL, la conoscenza dei
primi passi deriva interamente dallo studio sulla parte centrale della Pubblica
Amministrazione; dunque si analizza la tabella delle relazioni tra le entità PAC al
fine di collegare le entità presenti nello schema concettuale PAL.
La funzione segue la seguente regola:
O una relazione PAC viene inserita unicamente se entrambe le entità
coinvolte sono presenti nello schema PAL.
La ricerca delle relazioni da inserire nello schema è eseguita molto rapidamente
dalla seguente query SQL.
SELECT RelazioniPAC.*
FROM RelazioniPAC
WHERE
63
RelazioniPAC.entityFrom in (SELECT EntitàSchemaPAL.nome FROM
EntitàSchemaPAL)
and
RelazioniPAC.entityTo in (SELECT EntitàSchemaPAL.nome FROM
EntitàSchemaPAL) ;
Ogni relazione trovata, viene stampata in output sottoforma di stringa testuale,
come nell’esempio seguente. entitàA.verboDiRelazione.entitàB
A causa della semplicità del passo funzionale viene tralasciata la
rappresentazione del diagramma delle attività.
Aggiunta degli attributi (addAttrib)
Il passo corrente aggiunge gli attributi significativi alle entità nello schema. Come
specificato in precedenza, si definisce attributo significativo un campo di una
tabella pescato nel primo passo della metodologia in assonanza con un criterio
like.
In tale occasione, gli elementi estratti dalla conoscenza PAL, sono stati archiviati
in una tabella di servizio al fine di favorire il passo in questione.
Nessuna query di filtraggio è infatti necessaria, l’unica operazione eseguita è la
visita della tabella temporanea per la scrittura in output degli attributi di ogni
entità.
Il diagramma delle attività proposto di seguito mostra l’operazione di stampa su
file di testo delle entità con i relativi attributi.
64
Leggi l'Entità dallaTabella Temporanea
Leggi i nomi dei campiabbinati all'Entità
Stampa su file ditesto del nome
dell'Entità seguita da inomi dei campi
* Per ogni Entità diversa presente nella Tabella Temporanea
Figura 34. Activity Diagram della funzione AddAttrib
Aggiunta dei vincoli di integrità referenziale (inferConstr)
Come descritto in precedenza, il passo di aggiunta dei vincoli è strettamente
legato al contesto della Pubblica Amministrazione Locale, in quanto si amplia la
consistenza dello schema concettuale solo con elementi legati al dominio
territoriale di competenza.
A causa dell’infattibilità di possedere in tempi brevi la lista dei vincoli tra tabelle
all’interno di ogni database PAL, il passo corrente è da considerarsi facoltativo;
nel seguito verranno mostrate le attività svolte dalla funzione che implementa il
passo logico della metodologia.
Il passo corrente cerca di relazionare elementi dello schema espandendo il
lavoro fatto dall’addRelationships con della conoscenza specifica della base dati.
Analizzando la lista di vincoli inferenziali tra le tabelle del database in
considerazione, si risale alle entità abbinate alle tabelle e si prendono in
considerazione solo i casi in cui sia presente almeno una entità nella coppia
relazionata. È di fondamentale supporto l’utilizzo della tabella temporanea,
prodotta nel primo punto della metodologia, nella quale sono contenuti gli
abbinamenti entità-tabelle.
Con descritto nella metodologia, il passo è stato implementativamente
decomposto in 3 blocchi sequenziali:
65
1. Si effettua la ricerca delle relazioni tra coppie di tabelle, entrambe
abbinate ad entità dello schema concettuale.
SELECT
TabellaTemporanea. Entità as EntitàFrom, VincoliDB.verbo as Verbo,
CopiaDiTabellaTemporanea.Entità as EntitàTo
FROM
(VincoliDB inner join TabellaTemporanea on VincoliDB.tableFrom=
TabellaTemporanea.tavola) inner join (select * from
TabellaTemporanea) as CopiaDiTabellaTemporanea on
VincoliDB.tableTo = CopiaDiTabellaTemporanea.tavola
GROUP BY
TabellaTemporanea.Entità, VincoliDB.verbo,
CopiaDiTabellaTemporanea.Entità;
2. Si effettua la ricerca delle relazioni tra coppie di tabelle, in cui la prima è
abbinata ad una entità e la seconda è considerata tabella esterna.
SELECT *
FROM (
SELECT
TabellaTemporanea.Entità AS EntitàFrom, VincoliDB.tableFrom
as TabellaFrom, VincoliDB.verbo AS Verbo,
CopiaDiTabellaTemporanea.Entità AS EntitàTo,
VincoliDB.tableTo as TabellaTo
FROM
(VincoliDB inner join TabellaTemporanea ON
VincoliDB.TableFrom = TabellaTemporanea.Tavola) left JOIN
(select * from TabellaTemporanea) AS
CopiaDiTabellaTemporanea ON VincoliDB.TableTo =
CopiaDiTabellaTemporanea.Tavola
GROUP BY
TabellaTemporanea.Entità, VincoliDB.tableFrom,
VincoliDB.verbo, CopiaDiTabellaTemporanea.Gerarchia,
VincoliDB.tableTo
) WHERE
TabellaFrom is null;
66
3. Si inverte il passo precedente, ricercando le relazioni tra tabelle in cui la
prima è considerata tabella esterna e la seconda è abbinata ad una entità.
SELECT *
FROM (
SELECT
TabellaTemporanea.Entità AS EntitàFrom, VincoliDB.tableFrom
as TabellaFrom, VincoliDB.verbo AS Verbo,
CopiaDiTabellaTemporanea.Entità AS EntitàTo,
VincoliDB.tableTo as TabellaTo
FROM
(VincoliDB left join TabellaTemporanea ON
VincoliDB.TableFrom = TabellaTemporanea.Tavola) inner JOIN
(select * from TabellaTemporanea) AS
CopiaDiTabellaTemporanea ON VincoliDB.TableTo =
CopiaDiTabellaTemporanea.Tavola
GROUP BY
TabellaTemporanea.Entità, VincoliDB.tableFrom,
VincoliDB.verbo, CopiaDiTabellaTemporanea.Gerarchia,
VincoliDB.tableTo
) WHERE
TabellaFrom is null;
Per ognuna delle tre precedenti fasi si stampa su file di testo la lista delle
referenze tra elementi; per mostrare se l’elemento è una entità o una tabella
viene introdotta una lettera accanto al nome dell’elemento.
Il file di testo conterrà perciò righe del seguente tipo:
EntitàFrom.E-referenzia-E.EntitàTo
EntitàFrom.E-referenzia-T.TabellaTo
TabellaFrom.T-referenzia-E.EntitàTo
Il diagramma delle attività riunisce le operazioni svolte nella funzione corrente.
67
Tenta di aprire il file Excelcon le referenze tra tabelle
del DB
Cerca referenzeEntità-Entità con la Query
apposita
Scrive su file di testole refenze trovate
Successo
Fallimento
Cerca referenzeEntità-Tabelle con la
Query apposita
Scrive su file di testole refenze trovate
Cerca referenzeTabelle-Entità con la
Query apposita
Scrive su file di testole refenze trovate
Scrive su file di testole Tabelle Esterne
Scrive su file di testole Tabelle Esterne
Figura 35. Activity Diagram della funzione InferConstraints
Integrazione e astrazione (integraAstrai)
Come descritto nella metodologia implementativa PAL, la funzione corrente
ricerca le somiglianze tra gli schemi in input per produrre uno schema output
formato soltanto da concetti fondamentali.
A causa della natura della rappresentazione degli schemi concettuali sono
necessarie una serie di sottofunzioni che svolgono il processo di integrazione-
astrazione sulla parte a loro assegnata.
La funzione corrente si avvantaggia dell’utilizzo di 4 sottofunzioni specifiche e
richiama 2 funzioni utilizzate nella riconcettualizzazione.
o Integrazione e astrazione delle entità
Questa sottofunzione analizza i file di testo degli schemi concettuali in
input, contenenti i nomi delle entità presenti in ciascun schema.
Tutti i nomi delle entità, raccolti per ogni file di testo, vengono memorizzati
in una lista (ListaEntità) e raggruppate per nome.
Vengono poi selezionate solo quelle che sono presenti almeno 2 volte.
Segue il testo della query SQL utilizzata a tale scopo.
68
SELECT
*
FROM
(
SELECT
Entità, count(Entità) as NumeroDiOccorrenze
FROM
ListaEntità
GROUP BY
Enità
) as EntitàConOccorrenze
WHERE
EntitàConOccorrenze.NumeroDiOccorrenze >1;
o Aggiunta delle gerarchie
Acquisendo in input la lista delle entità fondamentali dal passo
precedente, si completano le generalizzazioni riutilizzando la funzione
base.
o Aggiunta delle relazioni
Anche in questo caso, non è necessario creare una sottofunzione
specifica, si riutilizza la funzione base per la definizione di relazioni sulle
entità fondamentali.
o Integrazione e astrazione degli attributi
L’esportazione degli attributi fondamentali deve avvenire in conseguenza
del passo di integrazione-astrazione delle entità; gli attributi che devono
essere esportati, infatti, possono essere solo quelli associati ad entità che
sono presenti nel nuovo schema concettuale.
La scelta di questi elementi segue sempre la filosofia nel considerare
fondamentali, solo gli attributi presenti in almeno due schemi riferiti alla
stessa entità.
L’operazione di selezione avviene mediante la seguente query SQL.
69
SELECT
*
FROM
(
SELECT
Entità, Campo, CampoDescrizione, count(Campo) as
NumeroDiOccorrenze
FROM
ListaAttributi inner join ListaEntità on
ListaAttributi.Entità like ListaEntità.Entità
GROUP BY
Entità, Campo, CampoDescrizione
) as AttributiConOccorrenze
Where
AttributiConOccorrenze.NumeroDiOccorrenze >1
o Integrazione e astrazione delle tabelle esterne
La sottofunzione corrente ha un aspetto molto simile a quella utilizzata per
l’integrazione-astrazione delle entità, tanto da utilizzare parti di istruzioni e
lo scopo perseguito viene favorito da una query SQL modificata
all’occorrenza.
L’operazione compiuta consiste nell’inserire tutte le tabelle esterne, di ogni
schema in input, in una tabella unica chiamata ListaTabelleEsterne e
selezionare solo quelle che compaiono in un numero superiore a 1.
SELECT
*
FROM
(
SELECT
Tabella, count(Tabella) as NumeroDiOccorrenze
FROM
ListaTabelleEsterne
GROUP BY
Tabella
) as TabelleConOccorrenze
WHERE
70
TabelleConOccorrenze.NumeroDiOccorrenze >1;
o Integrazione e astrazione dei vincoli di integrità referenziale
Come nel passo di aggiunta dei vincoli di inferenza nella metodologia per
la riconcettualizzione, anche nel corrispondente passo per l’integrazione-
astrazione sono presenti le simili complicazioni implementative.
Il processo viene suddiviso in tre parti e vengono esportate solo le
referenze tra elementi (entità e tabelle esterne) già presenti nello schema
concettuale, esportati nei passi precedenti.
Il problema di maggior rilievo è stato poter selezionare le referenze comuni
in una query SQL; non sempre la coppia di elementi è presente con lo
stesso ordine, è possibile infatti trovare casi come il seguente: EntitàA.relaziona.TabellaB
TabellaB.relaziona.EntitàA
La referenza descritta è la medesima, ma senza nessun intervento
modificativo non è possibile associare le due relazioni in una query SQL.
La soluzione scelta ha introdotto una fase di preprocessing, in cui la lista
delle referenze, comprensiva di tutte quelle degli schemi in input, viene
ordinata in modo che l’elemento From (a sinistra) sia minore dell’elemento
To (a destra); è ovvio che la comparazione avviene su confronto di
rappresentazione numerica dei caratteri.
Terminata tale interfase si svolge una selezione delle referenze comuni ad
almeno due schemi in input.
A seguito della descrizione delle sottofasi di integrazione-astrazione è possibile
rappresentare la funzione padre mediante un diagramma delle attività.
71
Legge gli schemiconcettuali in input
IntegraAstrai Entità Scrive le Entità su file di testo
Ricrea Gerarchie delleEntità trovate Scrive le Gerarche su file di testo
Inserisci le Relazionitra le Entità trovate Scrive le Relazioni su file di testo
IntegraAstrai Attributi Scrive gli Attributi su file di testo
IntegraAstrai TabelleEsterne Scrive le Tabelle Esterne su file di testo
IntegraAstrai Vincoli Scrive i Vincoli su file di testo
Figura 36. Activity Diagram della funzione Integra-Astrai
Assemblaggio delle componenti
Terminata la fase di implementazione della funzioni base per la
riconcettualizzazione e per l’integrazione-astrazione, è stato possibile progettare
ed implementare funzioni di alto livello di più facile utilizzo, che richiamano le
funzioni base in una corretta sequenza logica.
Il tool è stato suddiviso in tre macroaree, abbinate a possibile funzioni utente.
o Riconcettualizzazione di uno schema logico di un database
o Integrazione-astrazione di schemi
o Creazione di un repository
Come è facile notare, le aree crescono linearmente di complessità richiamano
concetti dell’area precedente.
72
Figura 37. Screenshot della finestra principale del tool.
Riconcettualizzazione di uno schema logico
L’utente ha modo di poter scegliere un database da una lista elencante tutti gli
archivi di cui si è fornito uno schema logico, come descritto nella metodologia.
Il processo richiama in sequenza le 5 funzioni base per la creazione di uno
schema concettuale, mostrando per ognuna l’output prodotto.
Figura 38. Screenshot della finestra di Riconcettualizzazione
73
Integrazione e astrazione di Schemi
In quest’area è possibile richiamare schemi concettuali di base, prodotti nell’area
precedente, oppure schemi concettuali astratti ed avviare il processo di
creazione di uno schema concettuale astratto di output che richiama la funzione
di integrazione-astrazione di schemi.
Figura 39. Screenshot della finestra di integrazione-astrazione di Schemi Concettuali
Creazione di un repository
Nell’area di maggior rilievo, su cui si fonda principalmente la presente tesi, è data
capacità all’utente di selezionare uno schema piramidale rappresentante un
repository ed avviare il processo di creazione.
Tale operazione sfrutta massimamente il riuso del codice richiamando le funzioni
di riconcettualizzazione di uno schema logico e di integrazione-astrazione di
schemi concettuali.
74
Per l’analisi dell’albero del repository si è scelto di utilizzare una visita dell’albero
di tipo deapth-first post-order, raggiungendo direttamente i database alle base
della piramide e risalendo verso la radice integrando e astraendo.
Lo schema grafico del Repository che viene incrementalmente rappresentato può
essere esportato in formato xml e permette l’interazione con l’utente favorendo
l’analisi di ogni nodo.
Cliccando su un elemento del repository è possibile osservare lo schema
concettuale mediante un applicativo esterno (ERwin) che ne disegna la struttura.
Tale interoperabilità è stata resa possibile sviluppando una funzione che riunisce
gli output testuali rappresentativi di uno schema concettuale in un file SQL,
importabile in svariati tool di visualizzazione.
Figura 40. Screenshot della finestra di costruzione del Repository
75
Figura 41. Screenshot di uno schema grafico di uno Schema Concettuale rappresentato grazie
all’interoperabilità con il tool ERwin
Testing
A seguito della scelta della tipologia di sviluppo di tipo incrementale, il
programma è stato testato nel corso di ogni fase della sua crescita
implementativa. Durante ogni incontro in sede a Torino è stato analizzato
l’operato settimanale, verificando la corretta implementazione delle scelte
discusse negli incontri antecedenti e comprovando la qualità del prodotto in fase
intermedia.
Alla completa terminazione del tool è stato eseguito un alpha test completo su
tutte le funzionalità messe a disposizione agli utenti, annotando i commenti e le
migliorie eventualmente necessarie.
Tali suggerimenti sono stati in parte soddisfatti nella versione definitiva e in parte
sono stati classificati per le versioni future.
76
Un test fondamentale a cui si è sottoposto il tool è la compatibilità con alcune
versioni di sistemi Windows.
Sui computer in sede è installata la versione 2000 del sistema Microsoft
Windows, mentre l’autore ha eseguito le fasi di implementazione su una
macchina con sistema Microsoft Windows XP.
A seguito di tale contesto implementativo è stato necessario un porting del tool
su piattaforma 2000, con conseguente rifacimento delle operazioni di test.
L’operazione di porting ha implicato una fase di compilazione e di creazione di
pacchetti di installazione specifici per il sistema destinatario.
Evoluzioni
A seguito dell’interesse suscitato dalla realizzazione del programma sono state
pianificate delle operazioni di miglioramento con lo scopo di innalzare la qualità
del prodotto finale.
Il perfezionamento si sviluppa su due strade parallele: la puntualità dei contenuti
di uno schema concettuale e la migliore rappresentazione dello stesso.
Nuove funzionalità
Il tool segue una metodologia approssimativa, favorendo maggiormente la
concretezza di un prodotto finito e usabile piuttosto che la qualità dei risultati
prodotti.
A conclusione del periodo di stage, è ora possibile rivedere gli algoritmi utilizzati
e avvicinarli alla metodologia originale con un margine di tempo diverso e con
una esperienza già maturata.
Il lavoro non è di semplice fattura, in quanto è necessario ripercorrere le fasi di
progettazione e pianificare un codice che implementi una metodologia
77
relativamente complessa. In questo contesto, il punto cruciale è la manipolazione
di schemi ER che necessita di particolari tecniche di rappresentazione e
gestione.
Le migliorie implementative influiscono sui meccanismi di riconcettualizzazione,
dove si rinnovano le tecniche di estrazione delle entità, abbinate agli attributi, e di
generalizzazione. Secondariamente, con tali evoluzioni, si migliora altresì
l’integrazione-astrazione implementando i concetti di creazione degli schemi
astratti come descritto nella metodologia originale PAL.
Nuovi formati per gli schemi grafici e per la rappresentazione interna
Come descritto precedentemente, la rappresentazione non ottimale degli schemi
concettuali può favorire la bassa qualità degli algoritmi scelti. Un punto dunque
basilare di un piano evolutivo del tool è sicuramente la definizione di uno
standard per la rappresentazione degli schemi concettuali.
Un’idea concreta per il miglioramento consiste nel cessare l’utilizzo della forma di
rappresentazione di uno schema concettuale mediante file di testo, sostituendola
con strutture tabellari, in modo da memorizzare i dati provenienti dai passi di
riconcettualizzazione e integrazione-astrazione
La proposta prevedrebbe l’utilizzo di un database altamente normalizzato,
composto da tabelle semplici, correlate tra loro, in grado di contenere tutte le
informazione riguardanti le entità (con gli attributi), le gerarchie e le relazioni
presenti in ogni schema concettuale.
Tale scelta favorirebbe sia i meccanismi di riconcettualizzazione, sia quelli di
integrazione e astrazione.
78
Conclusioni
In questa tesi si è analizzato il processo di sviluppo per la realizzazione di un tool
atto alla creazione di un repository, in particolare, nel contesto della Pubblica
Amministrazione.
L’analisi delle metodologie, dei lavori svolti anni addietro, ha permesso di
acquisire i concetti riguardanti l’astrazione della basi dati e delle tecniche
impiegate nei lavori sulla Pubblica Amministrazione Centrale.
Tali lavori hanno permesso di definire una metodologia approssimativa per la
parte Locale della Amministrazione, trovando l’interesse di un ente privato
Piemontese che seguisse il processo implementativamente.
Lo scopo di realizzare un prodotto finito in breve tempo con la minimizzazione
delle risorse disponibili, ha portato alla creazione di un tool sperimentale in grado
di eseguire operazioni di riconcettualizzazione su schemi logici di basi dati e
integrazioni-astrazioni di schemi concettuali. Il riuso di queste funzioni ha
permesso l’utilizzo del tool su scala più ampia, permettendo la creazione di un
repository di basi dati.
Le peculiarità del prodotto finale riguardano la semplicità operativa e la possibilità
di ottenere una versione grafica dei singoli risultati prodotti, grazie
all’interoperabilità con applicativi grafici di disegno di schemi ER.
A seguito dell’interesse scaturito dalla realizzazione del prodotto, si prevede una
revisione dei meccanismi operativi al fine di migliorare l’efficacia avvicinandosi
maggiormente alla metodologia originale.
In conclusione, il lavoro svolto ha soddisfatto le aspettative richieste, fornendo un
tool efficiente e soddisfacentemente efficace che si adatta al contesto di sviluppo
e pone importanti basi per uno sviluppo futuro.
79
Riferimenti
1. Batini C., Garasi M.F., Grosso R. (2005) - Reuse of a repository of
conceptual schemas in a large scale project. - Advanced Topics in
Database Research -- Vol. 5, in print.
2. Batini C., Grosso R. (2005) - Design of repositories of conceptual
schemas in the small and in the large. - eGovernment Workshop ’05
(eGOV05), September 13 2005, Brunel University, West London UB8
3PH, UK
3. Cammarata M. (1994) - Pubblica amministrazione: incomincia il futuro? -
MCmicrocomputer n. 144
4. Castano S. & De Antonellis V. (1997). Semantic dictionary design for
database interoperability. 13th International Conference on Data
Engineering, University of Birmingham, Birmingham, U.K.
5. Castano S., De Antonellis V. & Pernici B. (1998). Conceptual Schema
analysis: techniques and applications. ACM Transactions on Data Base
Systems 23 (3).
6. DiLeo J., Jacobs T. & DeLoach V. (2002). Integrating Ontologies into
Multiagent Systems Engineering. Fourth International Bi-Conference
Workshop on Agent-Oriented Information Systems, Bologna, Italy.
7. Farquhar A., Fikes R.,Pratt W. & Rice J. (1995) - Collaborative Ontology
Construction for Information Integration - Knowledge Systems Laboratory
Department of Computer Science 95-63.
8. Mirbel I. (1997) Semantic integration of conceptual schemas, Data and
Knowledge Engineering, 21(2), 183-195.
9. Pan J., Cranefield S. & Carter D. (2003). International Conference on
Autonomous Agents. Proceedings of the second international joint
conference on Autonomous agents and multiagent systems, Melbourne,
Australia 632 – 638.
80
10. Shoval P., Danoch R. & Balabam M. (2004) Hierarchical entity-relationship
diagrams: the model, method of creation and experimental evaluation,
Requirements Engineering 9, 217-228.
11. J. Wang, L. Gasser, Mutual Online Ontology Alignment (2002) AAMAS
Workshop on Ontologies for Agent Systems.
81
Appendice
Schemi intensionali ed estensionali della relazioni utilizzate
Di seguito sono riportate le istanze di due tabelle utilizzate dal tool.
Le sei gerarchie di generalizzazione
Di seguito viene riportato il contenuto della tabella utilizzata dal tool contenente le
6 gerarchie di generalizzazione.
Descrizione dei campi:
o Cod. Codice della gerarchia, la lettera ne rappresenta l’iniziale.
B=Bene
S=Soggetto
D=Documento
L=Luogo
T=Territorio
U=Urbanistica
o Livello. Rappresenta il livello gerarchico nella generalizzazione. Per
ritrovare il padre di una generalizzazione è necessario risalire la tabella
verso l’alto fino ad incontrare una generalizzazione con livello inferiore.
o Nome. Contiene il nome della generalizzazione.
o Criterio. Contiene una stringa utilizzata nelle query per abbinare la
generalizzazione alla base dati PAL.
82
Cod Livello Nome Criterio B 1 B01_BENE %bene B 2 B03_IMMOBILE %ben%immobil% B 3 B04_ABITAZIONE %abitazion% B 3 B05_FABBRICATO %fabbricat% B 3 B06_TERRENO %terren% B 2 B07_MOBILE %ben%mobil% B 3 B10_AUTOMOBILE %automobil% B 3 B16_ACQUEDOTTO %acquedott% B 3 B19_DEMANIO FERROVIARIO %ferrov% B 3 B20_DEMANIO STRADALE %stradal% B 3 B21_DEMANIO ARTISTICO STORICO CULTURALE %artist% B 3 B22_MERCATO COMUNALE %mercat% B 3 B23_MUSEI BIBLIOTECHE PINACOTECHE %muse%bibl% B 3 B25_DEMANIO NECESSARIO IDRICO %idric% B 2 B28_BENE PATRIMONIALE %ben%patrimon% D 1 D01_DOCUMENTO %documento% D 2 D02_ATTO REGISTRO %registro%
%documento liquidato% D 2 D04_DOCUMENTO LIQUIDATO
D 2 D06_VERSAMENTO %versament% D 2 D08_VERSAMENTO CON DELEGA %delega% L 1 L01_LUOGO %luogo% L 2 L02_LOCALITA %localita% L 3 L02_CIVICO %num%civ% L 3 L02_STRADA %strada% L 3 L02_VIA via% L 2 L03_PARTICELLA CATASTALE %part%catast% L 2 L04_PORZIONE %porzione% L 2 L05_PRIMITIVA GRAFICA %primi% L 2 L06_RIFERIMENTO CATASTALE %catastale% L 2 L08_SUPERFICIE AGRICOLA %sup%agri% L 2 L09_UNITA IMMOBILIARE URBANA %uiu% S 1 S01_SOGGETTO %soggetto% S 2 S02_SOGGETTO FISICO - PERSONA FISICA %pers%fisic% S 3 S03_ASSISTITO %assistit% S 3 S04_CANDIDATO %candidat% S 3 S06_CONTRIBUENTE %contribuent% S 4 S07_APPARTENENTE CATASTO %del%catast% S 4 S11_CONDANNATO %condann% S 4 S13_IN ATTESA DI GIUDIZIO %giudizio% S 3 S14_DISOCCUPATO %disoccup% S 3 S17_ITALIANO %italian% S 4 S18_RESIDENTE ALL'ESTERO %residen%estero% S 3 S19_LAVORATORE %lavorator% S 4 S20_AUTONOMO %lavor%autonom% S 4 S21_DIPENDENTE %lavor%dipenden%
83
S 4 S23_IMPRENDITORE %imprenditor% S 3 S24_PENSIONATO %pensiona% S 3 S28_SEGNALATO %segnalat% S 3 S31_STRANIERO %stranier% S 4 S32_RICHIEDENTE CITTADINANZA %rich%cittadinanz% S 3 S34_STUDENTE %student% S 3 S38_TOSSICODIPENDENTE %tossicod% S 3 S39_VOLONTARIO %volon% S 2 S40_SOGGETTO GIURIDICO %sogg%giur% S 3 S41_IMPRESA %impres% T 1 T01_TERRITORIO %territorio% T 2 T02_CARTOGRAFIA DI SERVIZIO %cartograf%
T 3 T03_LIMITI TERRITORIALI DI COMPETENZA TECNICO AMMINISTRATIVA %limiti_amm%
T 4 T04_REGIONE %regione% T 4 T05_PROVINCIA %provincia% T 4 T06_COMUNITA MONTANA %comun%montan% T 4 T07_COMUNE %comune% T 4 T08_ARPA %arpa% T 4 T09_ASL %sanitaria%locale%
T 3 T10_AREE DI INTERESSE PER IMPATTO AMBIENTALE
%impatto%ambientale%
T 4 T12_AREA SENSIBILE %area%sensibile% T 4 T16_DISCARICA %discaric% T 3 T17_AREE DI INTERESSE URBANISTICO %urban% T 4 T19_ISOLATO %isolat% T 3 T20_VIABILITA' STRADALE %viabilit% T 4 T21_AUTOSTRADA %autostrada% T 4 T23_STATALE %strada%statale% T 3 T33_ALTIMETRIA %altimetria% T 3 T35_TOPONOMASTICA %toponomastic% T 4 T36_TOPONIMO CTR %toponimo%
%bacino%idrogeologico% T 4 T47_BACINO IDROGEOLOGICO %bacino%idrografico% T 4 T48_BACINO IDROGRAFICO PRINCIPALE
T 5 T54_POZZO %pozzo% T 5 T55_SORGENTE %sorgente% T 5 T56_PRESA presa T 4 T59_OPERA DI TRASPORTO %opera%trasporto%
%insediamento%produttivo% T 5 T72_INSEDIAMENTO PRODUTTIVO %opera%recapito%finale% T 4 T77_OPERA DI RECAPITO FINALE
T 5 T78_RESTITUZIONE %restituzione% T 5 T86_IMPIANTO DI SOLLEVAMENTO %solleva% T 5 T92_MODULATORE %modulatore% T 5 T93_SFIORATORE %sfioratore% U 1 U01_URBANISTICA %urban%
84
U 2 U03_TERRITORIO %territorio% U 2 U04_COMUNE %comune% U 2 U06_PRATICA %pratica% U 2 U07_STRUMENTO %strumento% U 2 U14_DESTINAZIONE %destinazione% U 2 U15_VINCOLO %vincolo% U 2 U18_PARAMETRO %parametro%
Le relazioni tra entità PAC
Come già specificato, la prima versione del tool utilizza le relazioni tra le entità
presenti al vertice della piramide PAC, con l’aggiunta dei nuovi domini “Territorio”
e “Urbanistica” specifici della competenza locale della Pubblica Amministrazione.
EntityFrom Nome della relazione EntityTo S01_SOGGETTO relaziona B01_BENE S01_SOGGETTO relaziona L01_LUOGO S01_SOGGETTO relaziona T01_TERRITORIO S01_SOGGETTO relaziona U01_URBANISTICA S01_SOGGETTO relaziona D01_DOCUMENTO B01_BENE relaziona L01_LUOGO B01_BENE relaziona T01_TERRITORIO B01_BENE Relaziona U01_URBANISTICA B01_BENE Relaziona D01_DOCUMENTO L01_LUOGO Relaziona D01_DOCUMENTO T01_TERRITORIO Relaziona D01_DOCUMENTO U01_URBANISTICA Relaziona D01_DOCUMENTO
85
Reuse of a repository of conceptual schemas in a large scale
project
Carlo Batini1, Manuel F. Garasi2 3, Riccardo Grosso
1 University of Milano Bicocca
Via Bicocca degli Arcimboldi 8, 20126 Milano, Italy +39 02 64487826; [email protected]
2 Via Copernico 51 20094 Corsico, MI, Italy
+39 02 4479828; [email protected]
3 CSI-Piemonte Corso Unione Sovietica 216, Torino, Italy + 39 011 3169253; [email protected]
ABSTRACT This chapter describes a methodology and a tool for the reuse of a repository of conceptual schemas. Large amounts of data are managed by organizations, with heterogeneous representations and meanings, Since data are a fundamental resource for organizations, a comprehensive and integrated view is needed for it. The concept of data repository fulfils these requirements, since it contains the description of all types of data produced, retrieved, and exchanged in an organization. Data descriptions should be organized in a repository to enable all the users of the information system to understand the meaning of data and the relationships among them. The methodology described in the chapter is applied in a project where an existing repository of conceptual schemas, representing information of interest for central public administration, is used in order to produce the corresponding repository of the administrations located in a region. Several heuristics are described and experiments are reported.
86
INTRODUCTION The goal of this chapter is to describe a methodology and a tool for the reuse of a repository of conceptual schemas. The methodology is applied in a large scale project related to the Italian Public Administration (PA); the goal of the project is to use the repository of conceptual schemas of the most relevant databases of the Italian central PA, developed several years ago, in order to build the corresponding repository of the local public administrations located in one of the 21 regions of Italy. Due to the limited amount of available resources, the methodology conceives and applies several approximate techniques, which allows for the rapid prototyping of the local repository. This is to be refined by domain expert, which results in a resource consumption one order of magnitude lower than by using a traditional process. We initially provide some details about the context in which the methodology has been investigated and developed. In all countries, in the past few years many projects have been set up, to effectively use information and communication technologies (ICT) to improve the quality of services for citizens, by gradually improving on the services which are provided by information systems and databases of their administrations. In the following section we focus in particular on the Italian experience. In the past, the lack of co-operation between the administrations led to the establishment of heterogeneous and isolated systems. As a result, two main problems have arisen, i.e. duplicated and inconsistent information and difficult data access. Moreover, the Government efficiency depends on the sharing of information between administrations, due to the fact that many of them are often involved in the same procedures, but they are using different, overlapped, and heterogeneous databases. Therefore, in the long term, a crucial aspect for the overall project is to design a cooperation architecture that allows both the central and the local administrations to share information, in order to provide services to citizens and businesses on the basis of the “one stop shop” paradigm. A crucial aspect of such cooperation architecture is the data architecture: data have to be interchanged with an interoperable format, all the administrations have to assign the same meaning to the same data, achieving database integration in the long term. The data base integration will provide for the spread of information within the government branches and will result in a more easily accessible working environment, in an increased quality of information management, and in an improved state-wide decision making process. The long term goal of data base integration has to be achieved in the complex organizational scenario of the Public Administration. The structure of the Public Administration (PA) in Italy consists of central and local agencies that together offer a suite of services designed to help citizens and businesses to fulfill their obligations towards the PA. Central PAs are of two types, Ministries such as Ministry of the Interiors and Ministry of Revenues, and other central Agencies such as Social Security Agency, Accident Insurance Agency and Chambers of Commerce. Main types of local Administrations correspond to Regions (21), Provinces (about 100) and Municipalities (about 8.000). The approach to cooperation among administrations followed in Italy to address this problem is based on the concept of Cooperative Information Systems (CIS), i.e., systems
87
capable of interacting by exchanging services with each other. The general cooperative architecture for the Nationwide CIS network of the Italian PA is shown in fig.1.
Fig. 1. The structure of the cooperative architecture
One of the first activities performed in the last decade, with the final goal of designing a suitable data architecture, has been the project of building an inventory of existing information systems operating within the central PA in Italy. The activity was performed on about 500 data bases, in which logical schemas through reverse engineering activities were translated into Entity Relationship schemas. In order to provide a structure to such a large amount of schemas, a methodology for building repositories of conceptual schemas, described in (Batini, Di Battista, and Santucci, 1993) was used. We describe briefly this methodology in the next section. In order to achieve cooperation among central and local administrations, it is necessary to design a data architecture that covers both types of administrations, and, consequently, a similar repository has to be developed for local administrations. For this reason, several regional administrations are now designing their own data architecture. The most advanced organizational context among local administrations in a region is when they are coordinated by a regional agency, that provides services to all or at least to the majority of them. This is the situation of the administrations of the Piedmont region, where such a central agency exists, CSI Piemonte. But also in such a fortunate context, only logical relational schemas are available as input to the process of the construction of the local repository. So, a methodology and tools are needed that let the approximate production of conceptual schemas be arranged in a repository. In this paper we describe this methodology and the experience we achieved so far in applying this to the context of the Piedmont Public Administrations.
88
The chapter is organized as follows. In section 2 we provide the background on primitives which are used to structure repositories in our approach, the original methodology for repository construction where only loose restrictions on resources existed, and we sketch the methodology for reuse, discussing related work at the end. In section 3 we describe in detail the methodology for reuse. Section 4 discusses future trends in the area of repository reuse. Section 5 concludes the chapter. BACKGROUND: HOW TO STRUCTURE AND BUILD A REPOSITORY OF SCHEMAS AND GUIDELINES ON ITS REUSE The structure of a repository of conceptual schemas A repository, in the context of the paper, can be defined as a set of conceptual schemas, each one describing all the information managed by an organisation area within the information system considered, organized in such a way as to highlight their conceptual relationships and common concepts. In particular, the repositories referenced in this paper use the Entity Relationship model to represent conceptual schemas. However, a simple collection of schemas does not display the relationships among schemas of different areas; the repository has to be organised in a more complex structure, through the use of suitable structuring primitives. The primitives used in our approach are: abstraction, view, and integration. Abstractions allow the description of the same reality at different refinement levels. This mechanism is fundamental for a data repository, since it helps the user to perceive a complex reality step by step, going from a more abstract level to a more detailed one (or vice versa). Views are descriptions of fragments of a schema. They allow users to focus their attention on the part of a complex reality of interest to them. Integration is the mechanism by which it is possible to build a global description of data managed by an organisation area starting from local schemas. By jointly using these structuring primitives we obtain a repository of schemas. Each column of the repository represents an organisation unit while each row stands for a different abstraction level. The left column contains the schemes resulting from the integration of all the other schemes belonging to the same row (views of the integrated schema). In fig. 2 we show an example of repository, where the Production, Sales, Department schemas are represented at different refinement levels respectively in the second, third and fourth column, while the Company schema in the first column is the result of their integration.
89
Fig. 2. An example of repository
In practice, when the repository is populated at the bottom level by hundreds of schemas, as in the cases that we will examine in the following section, it is unfeasible to manage the three structuring primitives, and the view primitive is sacrificed. Furthermore, the integration/abstraction structuring mechanism is iterated, producing a sparsely populated repository such as the one symbolically represented in fig. 3, where, for instance, schema S123 results from the integration/abstraction of schemas S1, S2, and S3.
Fig. 3. A fragment of repository The repository structure described previously has been adopted for representing the conceptual content of a wide amount of conceptual schemas related to the most relevant databases of Italian central PA in an integrated structure.
90
A methodology for building a Repository of schemas In order to build the whole repository, an initial methodology has been designed, it is described in detail in (Batini, Di Battista, and Santucci, 1993), (Batini, Castano, De Antonellis, Fugini and Pernici 1996) and is briefly described here. The methodology is made up of three steps. 1. Schema production – Starting from logical relational schemas or requirement collection activities, traditional methodologies for schema design have been used (e.g. see Batini, Ceri, and Navathe (1991)), that lead to the production of about 500 basic schemas, representing the information content of the most relevant databases used in the central public administration at the conceptual level. 2. Schema clustering - First, conceptual schemas representing the different organization areas are grouped in terms of homogeneous classes, corresponding to meaningful administrative areas of interest in central public administration; 27 different areas have been defined: examples of areas are social security, finance, cultural heritage, and education. As we said, at the bottom level of the repository we have about 500 schemas, corresponding to the logical schemas of the data bases of the 21 most relevant central PAs in Italy, with approximately 5.000 entities and a similar number of relationships. We denote in the following basic schemas the conceptual schemas defined at the bottom of the repository. 3. Iterative integration/abstraction - Each group of basic schemas is integrated and, at the same time, abstracted, resulting in a unique schema for each area, that populates the second level of the repository, resulting in 27 second level abstract schemas. In fig. 4 the different levels of the repository are represented, starting from the second level; for instance, the Internal security second level schema results from the integration/abstraction process, performed over 6 schemas corresponding to 130 concepts.
Fig. 4: The repository of schemas of central public administration
91
About 200 person months were needed to produce the 500 basic conceptual schemas of the repository in the schema production step, while about 24 person months were needed to produce the 55 abstract schemas of the upper part of the repository (approximately 2 weeks per schema, both for basic and for abstract schemas). In fig. 5 the schema at the top level of the repository is shown.
Fig. 5. The schema at the top level of the repository Assumptions and basic choices for a methodology for Repository reuse In the project related to the production of the repository for local PA, available resources were one order of magnitude lower. For this reason we were forced to reuse the Repository developed for the central PA, and adapt the methodology to the new context, by conceiving new heuristic techniques. To do so, as we will describe in detail in section 3, we propose a methodology for reuse in a different domain based on the following guidelines:
1. While basic schemas of the central PA repository and the local PA repository may probably differ, due to the different functions between central and local administrations, our first assumption holds that the similarity should be much higher between the abstract schemas of the central PA repository and the more relevant concepts of basic + abstract schemas of the local PA repository.
2. In order to reduce human intervention as much as possible, the methodology (its high level structure is shown in fig. 6) first performs an automatic activity, where several heuristics are applied, that use abstract knowledge of the central PA repository, producing a first draft version of the basic schemas. This version is then analyzed by the domain expert that may add or modify concepts, thus producing the final schema.
92
Fig. 6: The two steps of the reuse methodology Literature review The literature on the application of ICT technologies in eGovernment is vast, see (Mecella Batini, 2001) for an introductory discussion and a description of the Italian experience. Repositories of conceptual schemas are proposed in several application areas; see e.g. in biosciences the Taxonomic Database Working Group (2004). The literature on repositories of conceptual schemas can be organized in two different areas: a) primitives for repository organization and methodologies for repository production, and b) new knowledge representation models for repositories. Concerning primitives and methodologies, using a descriptive model based on words and concepts, Mirbel (1997) proposes primitives for integration of object oriented schemas that generate abstract concepts as a result of the integration process. As a consequence, the primitives of Mirbel (1997) are similar to ours, but no evidence is provided to prove the effectiveness of the approach on a large scale project. Castano, De Antonellis, and Pernici (1998) and Castano and De Antonellis (1998) propose criteria and techniques to support the establishment of a semantic dictionary for database interoperability, where similarity-based criteria are used to evaluate concept closeness and, consequently, to generate concept hierarchies. Experimentation of the techniques in the public administration domain is discussed. Shoval, Danoch and Balabam (2004) introduce the concept of conceptual schema package as an abstraction mechanism in the Entity Relationship model. Several effective techniques are proposed to group entities and relationships in packages such as dominance grouping, accumulation and abstraction absorbing. While the Shoval et al. package primitive is more powerful than our abstraction primitive, they do not address the integration issue. Perez et al. (2002) present a solution and methodology for reverse engineering of legacy databases using formal method-based techniques.
93
Concerning new knowledge representation models, repositories of ontologies are proposed in several papers. The alignment and integration of ontologies is investigated in (Wang and Gasser, 2002), (Di Leo, Jacobs, Pand, De Loach, 2002) (Fanquhar, Fikes, Pratt, and Rice, 1995) where information integration is enabled by having a precisely defined common terminology. A set of tools and services is proposed to support the process of achieving consensus on such commonly shared ontologies by geographically distributed groups. Users can quickly assemble a new ontology from a library of modules. In (Pan, Cranfield, and Carter, 2003) multi-agent systems rely on shared ontologies to enable unambiguous communication between agents. An ontology defines the terms or vocabularies used within encoded messages, using an agent communication language. In order for ontologies to be shared and reused, ontology repositories are needed. Slota et al. (2003) propose a repository of ontologies for public sector organizations. The repository is used in a system supporting organizational activity by formalizing, sharing and preserving operational experience and knowledge for future use. In our approach as regards to the above mentioned contributions the following aspects are new:
a) the abstraction/integration primitive adopted for structuring the repository; b) the attention devoted to feasibility aspects and resource constraints; c) the consequent heuristic methodology for reuse; d) the experiments conducted (reported in section 4) provide evidence of the
effectiveness of the approach. On the other hand, conceptual models are less powerful than ontology based models, while being more manageable in practical cases. A METHODOLOGY FOR REPOSITORY REUSE Knowledge available in the new domain In this section we describe in more detail the knowledge available for the design of the local PA repository and we describe the assumptions that have been made in the activity. A first relevant input available for the process is the central PA repository of schemas, made of basic and abstract schemas. A second input concerns local databases. The Piedmont local PA is centrally served by a unique consortium, CSI Piemonte, that created approximately 450 databases of 12 main local administrations in the last years, whose logical schemas are documented in terms of: relational database schemas, tables (approximately 17.000), textual descriptions of tables, referential integrity constraints defined among tables, attributes, definitions of attributes, primary keys. The basic sources of knowledge available for the production of the local PA repository, as results from the above discussion, are very rich, but characterized by two significant heterogeneities: the conceptual documentation concerns central administrations, while for local Piedmont administrations the prevalent documentation concerns logical schemas. A second relevant condition of our activity has concerned budget constraints; for the first year of the project we had only one person year available, which was less than one tenth
94
of the resources that were available for the construction of the central repository. So, in conceiving the methodology for the local PA repository production, we used heuristics and approximate reasoning, in order to reduce human intervention as much as possible. As a consequence of resource constraints and the assumption discussed in section 2.3, we decided to use in some steps of the methodology a more manageable knowledge base than the 500 central basic schemas + the 50 abstract schemas. Such schemas can be represented in terms of a much more dense conceptual structure, that corresponds to the four generalization hierarchies that have the entities defined in the schema of fig. 5 at their top level. At lower levels they have the concepts present in more refined abstract schemas and basic schemas, which was obtained applying the refinements top down along the integration/abstraction hierarchy. We show in fig. 7 a fragment of one of the hierarchies, the one referring to Subjects.
Fig. 7. A fragment of the Subject generalization hierarchy
So, as a further choice, we decided to use, besides the basic schemas and the abstract schemas, the four generalization hierarchies of Subject (Individual + Legal Person), Property, Document, Place. As a consequence of the above assumptions, constraints and choices, the inputs to the methodological process, shown in fig. 8, have been:
1. The central PA Repository of 550 basic + abstract schemas 2. The four central PA Generalization hierarchies 3. The logical schemas of the 450 local PA databases.
95
Fig. 8. Input knowledge for the production of the Repository of local conceptual schemas The methodology In this section we present the methodology for building the basic schemas (its extension to abstract schemas is briefly discussed in Section 4). The methodology is composed of five steps. Each step is described with a common documentation frame, providing the inputs to the step, the procedure, and in some cases, when relevant, the outputs of the step. An example is provided, related to a logical schema concerning grant monitoring of industrial business activities. Step 1. Extract entities Inputs: central PA generalization hierarchies, one local PA logical schema. Names of entities in hierarchies are compared with names and descriptions of each table, the set of names of the attributes and the descriptions of the attributes in the logical schema. The comparison function presently makes use of a simple distance function among the different strings. The entities and corresponding frequency of matching are sorted, and a threshold is fixed: all the entities with frequency over the threshold are selected, resulting in a first draft schema made only of entities. The output is a draft schema made up of disconnected entities. Step 2. Add generalizations Inputs: the draft schema obtained in the previous step and the four central PA generalization hierarchies. Visit the generalization hierarchies and add to the draft schema subset relationships present in hierarchies, defined among the entities in the draft schema.
96
Step 3. Extract relationships Inputs: the draft schema + all the basic schemas in the central PA repository Entities of the draft schema are pair wise compared with all the basic schemas in the central PA repository. For each pair of entities E1 and E2 several types of relationships are extracted by the basic schemas:
1. relationships defined exactly on E1 and E2; 2. relationships corresponding to chains of relationships defined among pairs E1-Ei;
Ei-Ei+1; …; Ei+j-E2; 3. relationships defined among entities E1* and E2* corresponding to ancestors of
E1 and E2 in the four generalization hierarchies; they are to be added due to the inheritance property of the generalization hierarchies.
Relationships collected in steps a and c are sorted according to the frequency of names. Here we have two possibilities:
a. The most frequent name is chosen as the name of the relationship b. The name is assigned by the domain expert.
Step 4. Check the schema with referential integrity constraints defined among logical tables Input: the draft schema + constraints defined in tables An integrity constraint between two tables T1 and T2, is an indication of the presence of a possible relationship between the entities corresponding to T1 and T2 in the ER schema For each referential integrity constraint defined among two tables T1 and T2 in the logical schema, it is controlled whether T1 and/or T2 have been already selected as entities in the draft schema, and in case they are not selected they are added as new entities. Furthermore, it is controlled whether a relationship is defined among the entities, and if not it is added. The type of relationship (e.g. one to many), in the present version of the methodology is chosen by the domain expert in step 5. Since particular cases of referential integrity constraints exist that do not give raise to ER relationships (e.g. key/foreing key relationships corresponding to IS-A hierarchies), all the ER relationships generated in this step are controlled by the domain expert. Step 5. Domain expert check of the draft schema and construction of the final schema Input: the draft schema In this step the schema produced by the semi automated process is examined by the knowledge domain expert that may add new concepts, cancel existing concepts, or else modify some concepts. Since step 5 is performed after the addition of relationships and entities resulting from referential integrity constraints, it may occur that too many concepts have been added, and the manual check of the domain expert leads to deleting some concepts. Sometimes new concepts are added, resulting in an enriched schema in which the kernel is the initial schema. Frequently schemas obtained after the integrity constraints check step and after the domain expert check step coincide. Output: the: final schema
97
We show in fig. 9 the schemas obtained as a result of the execution of steps 1 to 5 of the methodology in our case study. In this case, schemas obtained after the integrity constraints check step and after the domain expert check step coincide, consequently, are not distinguished in the figure.
Fig. 9. Schemas obtained after steps 1-5
Experiments and improvements We have experimented the above methodology in three different areas: businesses, health care, regional territory, and nine related fields. The total number of tables of the nine databases is approximately 550, corresponding to 3% of the total. We were interested in measuring two relevant qualities of the process:
1. the correctness of the conceptual schema with respect to the “true” one, i.e. the schema that could be obtained directly by the domain expert through a traditional analysis or else a reverse engineering activity. Correctness is measured with an approximate indirect metrics, corresponding to the percentage of new/deleted concepts in the schema produced by the expert at the end of step 5 with respect to concepts produced in the semi automatic steps 1-4.
2. the completeness of the conceptual schema with respect to the corresponding reengineered logical schema. Completeness is measured by the percentage of tables that are extracted in steps 1-5, in comparison with the total number of
98
tables, after excluding tables not carrying relevant information, such as redundant tables, tables of codes, etc.
Table 1 summarizes the main results of experiments. Concerning correctness, in general the schemas obtained after check with integrity constraints step, and after domain expert check step are very similar, i.e. domain experts tend to confirm and consider complete entities and relationships added in the previous step; the overall figure for the nine experiments results in more than 80% of concepts common to the two types of schemas. We see also that the add constraints step introduces approximately 30% of new concepts in comparison with the extract entities step. Consequently the joint application of the central PA knowledge and local PA knowledge shows to be effective. These are encouraging results, considering the highly heuristic nature of the methodology.
Table 1. Experiments results
Concerning completeness, in the first experiments of the methodology results have been less reassuring. On the average, only 50% of the tables are extracted. This value changes significantly in the different areas. Furthermore, as was to be expected, completeness decreases significantly when the referential integrity constraints are not documented or partially documented, resulting in lower quality (completeness) conceptual schemas. Apart from the quality of the documentation, another cause of reduced completeness is the static nature of generalization hierarchies used in step 1, and the unequal semantic richness in representing related top level concepts. For instance, in the initial Subject hierarchy, 20 concepts represent individuals, while only 3 represent legal persons. An improvement we have made concerns the incremental enrichment of the generalization hierarchies with new concepts, possibly generated in step 5. Such enriched hierarchies have been progressively reconciled and made similar to hierarchies characteristic of local administrations, resulting in a corresponding and more effective selection mechanism. We performed a new experiment, in which we used an enriched Subject hierarchy, with legal persons represented by 20 concepts, that resulted in an increment of tables extracted after the create entities step from 30% to 35%, and tables extracted after the add constraints step from 51% to 73 %. A final comment on resources. The amount of resources spent in the experiments has been on the whole 30 person/days, corresponding to 3 person/day per schema. About 30% of time has been spent in steps 1-4, and 60% of time has been spent in the manual check. So, the domain expert has been engaged for 2 days per schema; we have to add a fixed cost of a 3 days course to this variable cost. We may expect greater efficiency as long as the activity proceeds, and estimate in 1 person day the average final effort,
99
significantly lower than the 2-3 person/weeks needed for design of one schema in the central PA repository. The tool A prototype has been implemented, which results in a tool that can fully automate the first four steps of the reuse methodology, and can document the decisions of the domain expert made in the fifth step. The output of each step is represented as a text file that describes the schema both in an internal XML format and in a semi-natural language. The XML format can be provided to a design tool, e.g. Erwin, to produce a graphic schema; the semi natural language is used as a user friendly description of schemas. The prototype is presently implemented in Visual Basic 6.0 and uses an Access DBMS. We are currently moving to a Visual Basic .Net version, and Oracle DBMS. In fig. 10 we show an example of a screenshot produced by the tool, that shows the result of the execution of add entity step to a specific database.
Fig 10: A screenshot produced by the tool FUTURE TRENDS We are now analyzing lessons learned and we are improving on the methodology. First, we are extending the methodology to the production of abstract schemas in the repository. This step may effectively use the results of previous steps 1-5. In fact, the
100
initial schema obtained after steps 1-3 inherits high level abstract knowledge from the central PA Repository and basic knowledge from the local PA logical schemas, while the enriched schema obtained in steps 4-5 encapsulates basic knowledge from the local PA logical schemas. We may conjecture that the initial schema is a candidate for abstract schema for the upper levels of the local PA repository, while the enriched schema, being a more detailed description representing a logical schema, populates the basic level of the repository. So, we may conceive two possible strategies for the repository update step. In the first strategy, starting from the initial schema and the enriched schema we first complete the “local” repository of abstract schemas corresponding to the enriched schema; we then integrate the local repository with the actual one: it may occur that we have to update, due to similarities between concepts, the abstract schemas of the actual repository, or else add new schemas, autonomous in respect to the previous ones. In the second strategy the new repository is obtained through abstraction/integration activities on the actual local PA repository and the initial and refined schemas. The first strategy is probably more effective when the actual local PA repository and the new schema represent very different knowledge, while the second strategy has the advantage of natively using the structuring paradigm of the repository, the abstraction/integration operation. We are currently experimenting with the two strategies, and other possible strategies, such as building small homogeneous repositories and then integrating them to obtain a larger repository. We are also investigating new techniques that use more complex similarity measures in matching between generalization hierarchies and logical schemas. Furthermore, since some of the local PA schemas (and corresponding hierarchies) have been independently developed, especially in the regional territory area, we are using such schemas as training examples to tune semiautomatic steps of the methodology and similarity measures which have been adopted. CONCLUDING REMARKS In this chapter we have investigated methodologies for conceptual schema repository construction and reuse in complex organizations such as, in particular, Public Adminstrations. We have shown how accurate methodologies, which can be used when large amounts of resources are available, have to be modified into approximate methodologies when we want to reuse previous knowledge and when available resources are limited. We have compared the proposed approach with existing literature in the area, and we made several experiments that provide evidence of the effectiveness of the approach and of the incremental improvements that can be achieved. Endnote This work has been fully supported by CSI Piemonte and partially supported by the Italian MIUR FIRB Project MAIS.
101
REFERENCES
1. Batini C., Di Battista G. & Santucci G. (1993) - Structuring primitives for a dictionary of entity relationship data schemas - IEEE Transactions on Software Engineering 19(4).
2. Batini C., Castano S., De Antonellis V., Fugini M.G. & Pernici B. (1996) - Analysis of an Inventory of Information systems in the Public Administration - Requirements Engineeing, 47-62.
3. Batini C., Castano S. & Pernici B (1996) - Tutorial on Reuse Methodologies and Tools - Entity Relationships International Conference, Cottbus, Germany.
4. Batini C., Ceri S. & Navathe S.B. (1991) Logical data base design using the Entity Relationship model - Benjamin and Cummings/ Addison Wesley, Palo Alto, California, USA, 1991.
5. Mecella M. & Batini C. (2001) Enabling Italian E-Government through a Cooperative Architecture" in A.K. Elmagarmid, W.J. McIver Jr. (eds.): Special Issue on Digital Government. IEEE Computer, 34(2) 40-45.
6. Castano S. & De Antonellis V. (1997). Semantic dictionary design for database interoperability. 13th International Conference on Data Engineering, University of Birmingham, Birmingham, U.K.
7. Castano S., De Antonellis V. & Pernici B. (1998). Conceptual Schema analysis: techniques and applications. ACM Transactions on Data Base Systems 23 (3).
8. DiLeo J., Jacobs T. & DeLoach V. (2002). Integrating Ontologies into Multiagent Systems Engineering. Fourth International Bi-Conference Workshop on Agent-Oriented Information Systems, Bologna, Italy.
9. Farquhar A., Fikes R.,Pratt W. & Rice J. (1995) - Collaborative Ontology Construction for Information Integration - Knowledge Systems Laboratory Department of Computer Science 95-63.
10. Fonseca F., Davis C. & Camara G. (2003) – Bridging Ontologies and Conceptual schemas in Geographic Information systems. Geoinformatica 7(4) 355 – 378.
11. Mirbel I. (1997) Semantic integration of conceptual schemas, Data and Knowledge Engineering, 21(2), 183-195.
12. Pan J., Cranefield S. & Carter D. (2003). International Conference on Autonomous Agents. Proceedings of the second international joint conference on Autonomous agents and multiagent systems, Melbourne, Australia 632 – 638.
13. Perez J., Ramos I., Cubel J., Dominguez F., Boronat A. & Carsì J. (2002). Data reverse engineering of Legacy Databases to object oriented conceptual schemas - Electronic Notes in Theoretical Computer Science 74(4).
14. Shoval P., Danoch R. & Balabam M. (2004) Hierarchical entity-relationship diagrams: the model, method of creation and experimental evaluation, Requirements Engineering 9, 217-228.
15. Slota R., Majewska M., Dziewierz M., Krawczyk K., Laclavik M., Balogh Z., Hluchy L., Kitowski J. & Lambert S. (2003). Ontology Assisted Access to Document Repositories for Public Sector Organizations, PPAM, Czestochowa, Poland.
102
16. Taxonomic Databases Working Group on Biodiversity Informatics (2004), Taxonomic Databases Working Group Annual Meeting University of Canterbury, Christchurch, New Zealand.
17. J. Wang, L. Gasser, Mutual Online Ontology Alignment (2002) AAMAS Workshop on Ontologies for Agent Systems.
103