Tesi garasi

1,139 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
1,139
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Tesi garasi

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×