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
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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
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
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
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.
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.
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.