Your SlideShare is downloading. ×

Tesi garasi

236
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
236
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 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
  • 2. 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
  • 3. Sommario ABSTRACT 5 INTRODUZIONE 6 Scopo della tesi 6 I concetti fondamentali 6 L’architettura informatica della PA Italiana LE METODOLOGIE DI LAVORO 11 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 IL TOOL 31 34 Il CSI Piemonte: organizzazione, ruolo e architettura tecnologica 34 Le prime specifiche 36 3
  • 4. 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
  • 5. 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
  • 6. 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
  • 7. 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
  • 8. App 1 App 2 Indipendenza logica s. concettuale Indipendenza fisica DB Figura 1: Architettura a tre livelli 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. Soggetto paga Tributo Figura 2: Esempio di schema concettuale ER 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
  • 9. 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
  • 10. 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. D-E DEP Sales Production Company Department structure EMP-DATA DEP Man D-E EMP-DATA EMP-DATA Acq In ITEM ORD-DATA ITEM view EMPLOYEE In D-E ORD-DATA CITY Born CITY EMPL Born DEPART SELLER DEP EMPLOYEE Man SELLER Product Acq ITEM In Of CITY PURCH In ITEM DEPARTM Gest Lav. Head EMPLOYEE Of WARR PUR CITY Born CITY DEP EMPLOYEE EMP Born FLOOR ORDER In Prod. CLERK Acq CLERK ENGIN ENGINEER ITEM Type Of SELLER Man In ORD Head SELLER ITEM In ITEM abstraction FLOOR Of EMP Born Acq view ORDER EMP-DATA ITEM abstraction Man DEPART DEP Acq Product ITEM PURCH Loc WARR In ORD Loc.. DEP Of PUR Head Man EMP Born CITY WARE WARE integration Figura 3: Un esempio di repository aziendale. 10
  • 11. 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
  • 12. 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
  • 13. Administration1 Administration2 processes processes Internal application Internal DBs Internal application Exported services Exported data Exported services Internal DBs Exported data Basic services Transport 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
  • 14. 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
  • 15. 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
  • 16. 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 Finanziarie Servizi Umane Territorio e Popolazione Strumentali Produzione Relazioni Ambiente Salute ed Lavoro e Assistenza Sicurezza Sociale Sociale Istruzione Relazioni Sicurezza Sicurezza esterne Giustizia Cultura esterna interna Figura 6: La Classificazione IDC 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 SOCIALI ED ECONOMICI SERVIZI DIRETTI TRASP ORTI TRASPORTI CO MU NICAZI ON I 10/178 AZIENDE AG RICOLE AZIENDE INDUSTRALI PRO DU ZIONE 3/53 LAVO RO 9/112 BENI CULTURALI AM BIENTE 8/213 CU LTU RA 10/100 ISTRUZION E 3/134 AS SISTENZA 5/56 EDILI ZIA I ST RUZI ONE AM BIEN TE SERVIZIO SANITARIO SANITA' 6/155 CRIMINALITA ' SICUREZZA INTERNA SIC UREZZA 6/130 ATTIVITA' GIUR ID ICA GIUST IZI A 6/76 DIFESA 10/76 PREVIDEN ZA CA TASTO AFFARI ESTERI 4/36 RELAZIONI ESTERE IN ITALIA 6/53 RELAZIONI ITALIANE ALL' ESTERO 9/118 CERTIFIC AZIONI 4/121 3/66 RA PPRESENTANZE ENT TER RI TORIALI I SERVIZI CERT IFI CA- ASSIC URA ZIOSTATISTI CA SOCIALI E NE SOCIALE TERR IT ORIALI ZION E 3/75 6/95 D IPENDENTI FORM AZIONE RI SORSE U MAN E 37/336 BEN I IM MO BILI STRUM ENTI AUTOMEZZI RI SORSE STRU MEN TALI E I MMO BILIARI 2/89 3/59 2/65 3/182 3/30 TRA SFERI MENTO FOND I PU IBB LIC I A ENTI LO CA LI PER ENTI FISCO CAPITO LI DI SPESA DOGAN E RISORSE FINAN ZIAR IE 6/69 PROTO CO LLO 2/93 2/12 ORGANI C OLLEGIA LI 8/293 RIS ORSE D I SUPPORTO SERVIZI ECONOMICI LAVORO SERVIZI SOCIALI 9/118 SERVIZI GENERALI Figura 7: Schema del Repository PAC 16
  • 17. 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. Place Property Document Subject Individual Legal person 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
  • 18. 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
  • 19. 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
  • 20. 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
  • 21. Pubblica Pubblica Amministrazione Centrale Amministrazione Locale Schemi Gerarchie di Concettuali Schemi generalizz.: Repository degli Astratti -Soggetto -Documento -Luogo -Bene Schemi Concettuali Schemi Base della PAL Schemi Logici 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: a. Riconcettualizzazione degli schemi logici delle basi dati. 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
  • 22. 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
  • 23. 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
  • 24. Documento Luogo Soggetto E3 Bene Gerarchie di E2 Generalizzazione E1 Schema Logico …. E2 Schema Concettuale E1 E3 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
  • 25. Documento Luogo E3 Soggetto Bene Gerarchie di E2 Generalizzazione E1 Schema Concettuale E2 E1 E3 E2 E1 precedente Schema Concettuale E3 arricchito 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
  • 26. 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 Documento Luogo Soggetto E3 Bene Gerarchie di E2 Generalizzazione E1 E2 E2 E1 E3 E1 E1 Schemi Base PAC Schema Concettuale E2 E1 E3 E3 arricchito 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
  • 27. 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 Schema Logico con K3 ….. vincoli tra tabelle K2 Schema E2 E1 E3 E2 E1 Concettuale Schema E3 Concettuale 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 27
  • 28. 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
  • 29. Schema iniziale Schema concettuale Repository PAL Schema arricchito 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
  • 30. 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 ALk più vicino a VALi. 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
  • 31. 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
  • 32. 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
  • 33. 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
  • 34. 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
  • 35. 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 Tassonomia per materia BasiDati Tabelle Servizi Tassonomia per istituzione Componenti architetturali Campi Figura 15. Schema di InfoDir. 35
  • 36. 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
  • 37. 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
  • 38. 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
  • 39. Add Entity Add Generalization Add Relationship Add Attribute Infer 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
  • 40. Documento Luogo E3 Soggetto Bene Gerarchie di E2 Generalizzazione E1 Schema Logico di una base dati PAL Lista nascosta delle Lista E1 E1 delle entità E2 E2 entità con elementi E3 E3 generanti 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
  • 41. Documento Luogo E3 Soggetto E4 E2 Bene E1 E1 E2 Gerarchie di Generalizzazione Lista delle entità E3 E4.generaliz.E2.generaliz.E1 E4.generaliz.E2 Lista delle Generalizzazione 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
  • 42. 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. E1.relaz.E6 Lista delle relazioni E1.relaz.E3 tra entità PAC E3.relaz.E4 … E19.relaz.E14 Lista delle E4.generaliz.E2.generaliz.E1 E4.generaliz.E2 Generalizzazione E3 Lista delle Relazioni tra E4.relaz.E3 E3.relaz.E1 entità nella base dati PAL 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
  • 43. Lista nascosta delle E1 E2 entità con elementi E3 generanti E1 Lista entità del database att1 descr E2 attr2 descr attr3 descr PAL con i relativi attributi E3 attr4 descr 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
  • 44. 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 Lista delle relazioni Tab1.refer.Tab3 Tab3.refer.Tab4 tra entità PAC … Tab19.refer.Tab14 E1 Lista nascosta delle entità E2 con elementi generanti E3 Lista delle Relazioni tra entità nella base dati PAL E2.refer.E3 Tab2 Lista delle E3.refer.Tab2 .Tab1 tabelle esterne E2.refer.Tab2 E4 refer Tab1 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
  • 45. 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
  • 46. 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
  • 47. 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
  • 48. 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
  • 49. 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. Specifiche Versione iniziale Specifiche Sviluppo ad alto livello Versioni intermedie Validazione Versione finale 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
  • 50. 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
  • 51. 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 Nome Tabella Descrizione Tabella Nome Campo Descrizione Campo Figura 24. Schema della tabella con la struttura PAL. 51
  • 52. Per praticità viene mostrato un esempio. Base Dati: Personale Persone CodFis Cognom Nom Indirizz Telefon ….. ….. ….. ….. ….. ….. ….. ….. ….. ….. Due relazioni di una base dati PAL Matricole Matricola CodFisc ….. ….. ….. ….. Base Dati: Personale Schemi logici delle Persone (CodFisc, Cognome, Nome, Indirizzo, Telefono) relazioni di una base dati PAL Matricole (Matricola, CodFisc) Nome Descr. Nome Tabella Base Dati Tabella Descr. Nome Campo Campo Personale Persone ….. CodFisc ….. Rappresentazione degli Personale Persone ….. Cognome ….. schemi intensionali delle Personale Persone ….. Nome ….. Personale Persone ….. Indirizzo ….. Personale Persone ….. Telefono ….. Personale Matricole ….. Matricola ….. Personale Matricole ….. CodFisc ….. 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
  • 53. 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 Livello Nome della generalizzazione 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
  • 54. 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
  • 55. 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
  • 56. 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
  • 57. 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
  • 58. File Excel Database ACCESS Metaschemi DB PAL 6 Gerarchie Relazioni Entità PAC Vincoli DB1 PAL Vincoli DB4 PAL … Vincoli DBn PAL Funzione di riconcettualizzazione Schema DB1 completo Schema DBn completo Schema DB4 completo Schema DB2 parziale … Schema DB3 parziale 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
  • 59. 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
  • 60. 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 T abella li ke criterio DB = db_scelto OR Tab Descr l ike criterio Si Si Aggiungi in output: DB, T abella, TabDescr, No No End su Istanza Start su Istanza Campo like DB = db_scelto criterio OR C ampo Des cr lik e criterio Si Si Aggiungi in output: DB, T abella, TabDescr, Campo, CampoDescr No No End su Istanza 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
  • 61. La funzione di estrazione delle entità può essere riassunta nel seguente diagramma delle attività. Ricevi Nome DB da Riconcettualizzare Esegui la ricerca delle Entità con la Query Salva i risultati nella Tabella Temporanea Stampa su file di testo i 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
  • 62. 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
  • 63. Di seguito viene presentato il diagramma delle attività del passo in questione. * Per ogni Entità diversa presente nella Tabella Temporanea Leggi l'Entità dalla Tabella Temporanea Ricerca il Padre con * Cicla finchè si arriva alla radice della gerarchia la Query Stampa su file di testo la gerarchia dell'Entità 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
  • 64. RelazioniPAC.entityFrom in (SELECT EntitàSchemaPAL.nome FROM EntitàSchemaPAL.nome FROM EntitàSchemaPAL) and RelazioniPAC.entityTo in (SELECT 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
  • 65. * Per ogni Entità diversa presente nella Tabella Temporanea Leggi l'Entità dalla Tabella Temporanea Leggi i nomi dei campi abbinati all'Entità Stampa su file di testo del nome dell'Entità seguita da i nomi dei campi 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
  • 66. 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
  • 67. 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
  • 68. Tenta di aprire il file Excel con le referenze tra tabelle del DB Fallimento Successo Cerca referenze Entità-Entità con la Query apposita Cerca referenze Entità-Tabelle con la Query apposita Cerca referenze Tabelle-Entità con la Query apposita Scrive su file di testo le refenze trovate Scrive su file di testo le refenze trovate Scrive su file di testo le refenze trovate Scrive su file di testo le Tabelle Esterne Scrive su file di testo le 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 integrazioneastrazione 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
  • 69. 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
  • 70. 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
  • 71. 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’integrazioneastrazione 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
  • 72. Legge gli schemi concettuali in input IntegraAstrai Entità Scrive le Entità su file di testo Ricrea Gerarchie delle Entità trovate Scrive le Gerarche su file di testo Inserisci le Relazioni tra le Entità trovate Scrive le Relazioni su file di testo IntegraAstrai Attributi Scrive gli Attributi su file di testo IntegraAstrai Tabelle Esterne 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
  • 73. 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
  • 74. 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
  • 75. 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
  • 76. 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
  • 77. 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
  • 78. 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
  • 79. 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
  • 80. 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
  • 81. 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
  • 82. 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
  • 83. 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
  • 84. 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 %cartograf% T 2 T02_CARTOGRAFIA DI SERVIZIO T03_LIMITI TERRITORIALI DI COMPETENZA 3 TECNICO AMMINISTRATIVA 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 T 4 T09_ASL T10_AREE DI INTERESSE PER IMPATTO 3 AMBIENTALE %sanitaria%locale% %impatto%ambientale % T 4 T12_AREA SENSIBILE %area%sensibile% %limiti_amm% 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 T 4 T47_BACINO IDROGEOLOGICO T 4 T48_BACINO IDROGRAFICO PRINCIPALE %toponimo% %bacino%idrogeologic o% %bacino%idrografico % T 5 T54_POZZO %pozzo% T 5 T55_SORGENTE %sorgente% T 5 T56_PRESA presa T 4 T59_OPERA DI TRASPORTO T 5 T72_INSEDIAMENTO PRODUTTIVO T 4 T77_OPERA DI RECAPITO FINALE %opera%trasporto% %insediamento%prod uttivo% %opera%recapito%fin ale% 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
  • 85. 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 S01_SOGGETTO S01_SOGGETTO S01_SOGGETTO S01_SOGGETTO S01_SOGGETTO B01_BENE B01_BENE B01_BENE B01_BENE L01_LUOGO T01_TERRITORIO U01_URBANISTICA Nome della relazione relaziona relaziona relaziona relaziona relaziona relaziona relaziona Relaziona Relaziona Relaziona Relaziona Relaziona EntityTo B01_BENE L01_LUOGO T01_TERRITORIO U01_URBANISTICA D01_DOCUMENTO L01_LUOGO T01_TERRITORIO U01_URBANISTICA D01_DOCUMENTO D01_DOCUMENTO D01_DOCUMENTO D01_DOCUMENTO 85
  • 86. Reuse of a repository of conceptual schemas in a large scale project Carlo Batini1, Manuel F. Garasi2, Riccardo Grosso3 1 University of Milano Bicocca Via Bicocca degli Arcimboldi 8, 20126 Milano, Italy +39 02 64487826; batini@disco.unimib.it 2 Via Copernico 51 20094 Corsico, MI, Italy +39 02 4479828; manuelfrancesco.garasi@fastwebnet.it 3 CSI-Piemonte Corso Unione Sovietica 216, Torino, Italy + 39 011 3169253; riccardo.grosso@csi.it 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
  • 87. 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
  • 88. 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
  • 89. 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
  • 90. 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
  • 91. 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
  • 92. 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
  • 93. 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
  • 94. 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
  • 95. 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
  • 96. 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
  • 97. 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
  • 98. 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
  • 99. 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
  • 100. 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
  • 101. 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
  • 102. 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 AgentOriented 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
  • 103. 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