1. UNIVERSITÀ DEGLI STUDI DI MILANO BICOCCA
FACOLTÀ DI SCIENZE MATEMATICHE FISICHE E NATURALI
Corso di Laurea Magistrale in Informatica
Tecniche di analisi del Repository delle
Basi dati della Pubblica Amministrazione
Relatore: Carlo Batini - Università Bicocca
Correlatore: Riccardo Grosso - CSI Piemonte
Controrelatore: Stefania Bandini - Università Bicocca
Tesi di Laurea di: Manuel Francesco Garasi
Matr. N: 062023
Anno Accademico 2004/2005

2. Ringraziamenti
Vorrei ringraziare il professor Carlo Batini e Riccardo Grosso per avermi supportato nel
periodo di stage e nella stesura di questa tesi, fornendomi le conoscenze con la
professionalità che li contraddistingue.
Un grosso ringraziamento lo dedico alla mia famiglia, che mi ha permesso di arrivare
fino a questo traguardo, e a Claudia per essermi stata sempre vicino.
2

3. Sommario
ABSTRACT
5
INTRODUZIONE
6
Scopo della tesi
6
I concetti fondamentali
6
L’architettura informatica della PA Italiana
LE METODOLOGIE DI LAVORO
11
14
La metodologia esatta per la PA Centrale
14
La metodologia approssimata per la PA Locale
18
Euristiche applicate
18
I passi metodologici per la riconcettualizzazione di schemi logici delle basi dati PAL
22
I passi metodologici per la creazione degli schemi astratti PAL
28
Confronto con altre metodologie
IL TOOL
31
34
Il CSI Piemonte: organizzazione, ruolo e architettura tecnologica
34
Le prime specifiche
36
3

4. La metodologia implementata per la PA Locale
37
La metodologia semplificata per la riconcettualizzazione
38
La metodologia semplificata per la creazione di schemi astratti
44
Il processo di sviluppo
48
Scelta della modalità di sviluppo
48
Scelte implementative
49
La conoscenza di base e la sua estrazione
51
Progettazione e implementazione delle componenti
58
Assemblaggio delle componenti
72
Testing
76
Evoluzioni
77
Nuove funzionalità
77
Nuovi formati per gli schemi grafici e per la rappresentazione interna
78
CONCLUSIONI
79
RIFERIMENTI
80
APPENDICE
82
Schemi intensionali ed estensionali della relazioni utilizzate
82
Le sei gerarchie di generalizzazione
82
Le relazioni tra entità PAC
85
Reuse of repository of conceptual schemas in a large scale project (Batini-Garasi-Grosso) 86
4

5. Abstract
Questa tesi descrive le scelte metodologiche e progettuali che hanno portato alla
produzione di un tool atto alla creazione di un repository di basi dati. La
metodologia seguita permette di riconcettualizzare un insieme di schemi logici al
fine di ottenere uno schema concettuale delle entità caratterizzanti, e
successivamente di ottenere uno schema piramidale rappresentante le relazioni
semantiche tra i vari concetti ad un certo livello di interesse.
Il tool è stato impiegato per la creazione di un repository di basi dati della
Pubblica Amministrazione Locale Piemontese; i concetti di repository e la
metodologia sono stati ripresi ed adattati partendo dallo studio di un repository
sulle basi dati della Pubblica Amministrazione Centrale condotto anni addietro.
L’utilizzo del tool permette la creazione in tempi molto brevi di uno schema
rappresentante i dati aziendali fornendo una visione esauriente ed integrata.
A seguito dell’interesse prodotto dal lavoro sono state effettuate ulteriori
sperimentazioni e test. Apportando delle modifiche alla base della conoscenza
del tool, è possibile svincolarsi dal contesto iniziale ed utilizzare lo strumento al
fine di supportare la comprensione delle conoscenze aziendali.
5

6. Introduzione
Scopo della tesi
Lo scopo della tesi è la descrizione delle fasi di sviluppo di un tool atto alla
creazione di repositories di base dati.
L’ambito su cui si è operato è la Pubblica Amministrazione, in particolare quella
Locale Piemontese. Il fine del lavoro è quello di studiare un repository di basi dati
della Pubblica Amministrazione Centrale, costruito anni addietro, per costruirne
uno specifico per quella Locale sfruttando le somiglianze delle strutture
amministrative.
Al fine di sviluppare il tool in una sua prima versione, si è analizzata una
metodologia esistente ed è stata implementata apponendo alcune euristiche.
L’ottenimento di un simile prodotto permette l’automazione di un lavoro manuale
intellettuale diminuendo drasticamente il tempo computazionale.
I concetti fondamentali
La risorsa principale di un sistema informativo sono i dati. La conoscenza e le
basi dati sono fondamentali per una azienda e vanno dunque preservati e
organizzati al meglio; in un periodo in cui sempre maggiori quantità di dati
vengono utilizzate dalle aziende, una corretta e funzionale organizzazione del
sistema organizzativo è fondamentale per la sua efficienza.
Una soluzione per tale problema è l’organizzazione dei dati mediante l’uso dei
repository; per la loro peculiarità di rappresentare informazioni con un certo livello
6

7. di dettaglio voluto, sono lo strumento ideale per avere un quadro completo delle
risorse dati e analizzare le relazioni intercorrenti tra di loro.
Un repository può essere considerato come una collezione di schemi concettuali
ognuno dei quali rappresenta uno specifico ambito di interesse del sistema
informativo aziendale.
Gli schemi concettuali utilizzano uno standard di rappresentazione fondato sul
modello Entity Relationship, che permette di mostrare molto efficacemente le
relazioni esistenti tra oggetti del sistema.
A differenza dei modelli logico/fisici, uno schema concettuale permette di
rappresentare la realtà assegnando ad ogni classe di oggetti del mondo reale un
nome identificativo; nello schema vengono anche rappresentati i legami
intercorrenti tra le varie classi di oggetti, chiamate relazioni, e le caratteristiche
eventuali di ognuno, detti attributi.
L’astrazione permessa dallo schema concettuale permette di distaccarsi dai livelli
fisici sottostanti caratterizzati da una rigidità legata al DBMS, favorendo
l’indipendenza fisica; ciò consente di modificare le strutture di memoria o i metodi
di accesso ai dati senza modificare lo schema concettuale globale.
A sua volta lo schema concettuale agevola l’indipendenza logica verso le
applicazioni, in modo tale da permettere la modifica dello schema stesso senza
modificare le preesistenti viste esterne.
7

8. App 1
App 2
Indipendenza logica
s. concettuale
Indipendenza fisica
DB
Figura 1: Architettura a tre livelli
L’esempio seguente mette in relazione due entità (cittadino e tributo)
associandole con la relazione pagamento; nel complesso lo schema risulta di
facile e rapida comprensione utilizzando un linguaggio vicino a quello naturale.
Soggetto
paga
Tributo
Figura 2: Esempio di schema concettuale ER
Oltre alla relazione esiste anche il costrutto di generalizzazione che permette di
creare oggetti che ereditano proprietà e relazioni di una classe padre.
Grazie a questa rappresentazione, lo schema concettuale descrive l’informazione
posseduta dai dati, di facile interpretazione sia per l’analista che per l’utente, ma
per essere tale deve rispettare le seguenti proprietà:
o Correttezza: le categorie del modello ER devono essere usate
coerentemente con la loro semantica (le loro definizioni).
o Completezza: tutte le specifiche devono essere rappresentate nello
schema.
8

9. o Pertinenza: non vi devono essere nello schema concetti non descritti nelle
specifiche.
o Leggibilità:
lo
schema
deve
rappresentare
i
requisiti
in
modo
comprensibile.
o Minimalità: non vi devono essere concetti che rappresentano gli stessi
requisiti.
Ogni schema concettuale rappresenta una basi dati specifica del complesso
insieme della conoscenza aziendale, per questo, l’utilizzo di un repository può
essere utile per creare ordine raggruppando ragionatamente gli schemi
concettuali.
Il repository permette di organizzare le varie informazioni, rappresentate dagli
schemi ER, in una maniera più o meno astratta a seconda del grado di
astrazione desiderato.
A tal fine, il repository utilizza i concetti di tre primitive utili per specifiche
operazioni.
o Astrazione: per poter avere una maggior chiarezza nella lettura dei dati è
necessario filtrare le informazioni meno importanti in modo da rendere la
lettura di uno schema più comprensibile e immediata. È possibile quindi
analizzare una struttura gerarchica dal livello di astrazione maggiore,
rappresentante
le
entità
fondamentali
dell’organigramma,
oppure
analizzare nel dettaglio una specifica realtà di interesse.
o Vista: in uno schema concettuale complesso è possibile focalizzare
l’attenzione su uno spaccato e studiarne indipendentemente la sua
struttura.
o Integrazione: per la costruzione di un repository è fondamentale l’unione di
più schemi concettuali eterogenei, questa operazione avviene fondendo
più schemi ER sovrapponendone i concetti comuni a entrambi gli schemi.
Utilizzando iterativamente queste tre tecniche è possibile costruire un repository
che, come è di facile intuizione, avrà una struttura piramidale data dall’utilizzo
9

10. contemporaneo delle tecniche di integrazione e l’astrazione che decimano il
numero di schemi per ogni livello crescente.
Nella pratica, si raccolgono degli schemi concettuali, rappresentanti le viste
eterogenee di specifiche parti della conoscenza, e si uniscono direttamente con
una operazione di integrazione-astrazione per favorire l’immediata creazione di
un unico prodotto di livello più astratto.
Nella figura seguente viene rappresentato un esempio concreto. Gli schemi
concettuali di tre settori aziendali (Produzione, Vendita, Magazzino)
sono
rappresentati nell’ultima riga e vengono integrati insieme in uno schema
concettuale che rappresenta la compagnia. Successivamente lo schema viene
sottoposto ad astrazioni successive togliendo di passo in passo le entità meno
significative in relazione al livello di astrazione corrente.
D-E
DEP
Sales
Production
Company
Department structure
EMP-DATA
DEP
Man
D-E
EMP-DATA
EMP-DATA
Acq
In
ITEM
ORD-DATA
ITEM
view
EMPLOYEE
In
D-E
ORD-DATA
CITY
Born
CITY
EMPL
Born
DEPART
SELLER
DEP
EMPLOYEE
Man
SELLER
Product
Acq
ITEM
In
Of
CITY
PURCH
In
ITEM
DEPARTM
Gest
Lav.
Head
EMPLOYEE
Of
WARR
PUR
CITY
Born
CITY
DEP
EMPLOYEE
EMP
Born
FLOOR
ORDER
In
Prod.
CLERK
Acq
CLERK ENGIN
ENGINEER
ITEM
Type
Of
SELLER
Man
In
ORD
Head
SELLER
ITEM
In
ITEM
abstraction
FLOOR
Of
EMP
Born
Acq
view
ORDER
EMP-DATA
ITEM
abstraction
Man
DEPART
DEP
Acq
Product
ITEM
PURCH
Loc
WARR
In
ORD
Loc..
DEP
Of
PUR
Head
Man
EMP
Born
CITY
WARE
WARE
integration
Figura 3: Un esempio di repository aziendale.
10

11. L’architettura informatica della PA Italiana
Il crescente livello tecnologico nel settore aziendale degli ultimi decenni ha
indotto molti governi, tra cui l’Italia, ad interessarsi all’informatizzazione
dell’apparato amministrativo per favorire il miglioramento dei servizi al cittadino e
alle imprese.
La ristrutturazione della Pubblica Amministrazione Italiana, avvenuta nei primi
anni novanta, ha portato ad un processo d’innovazione nei sistemi informativi in
cui si è vista la nascita dell’organismo preposto allo sviluppo dei sistemi
informativi pubblici, l’Autorità per l’Informatica nella Pubblica Amministrazione
(AIPA).
Il
compito
dell’AIPA
si
estende
su
tutta
la
struttura
della
Pubblica
Amministrazione italiana, che si compone di una parte Centrale e di una Locale
composta da agenzie specializzate nel territorio regionale, provinciale o
municipale di competenza.
La parte Centrale è suddivisa in Ministeri, quali il Ministero delle Entrate e il
Ministero degli Interni, e da varie agenzie, quali INPS, INAIL e Camere di
Commercio.
In principio, ogni dipartimento sviluppò un proprio sistema informatico non
orientato alla rete, in accordo con le vigenti tendenze informatiche, quindi isolato
dal resto degli altri organismi burocratici.
Questa grave, ma concepibile, mancanza si concretizzò in un sistema totalmente
non cooperativo con conoscenze decentralizzate che portò all’affioramento di
due problemi: l’inconsistenza dei dati, e la difficoltà nell’accesso.
L’inconsistenza è data dal fatto che ogni dipartimento possiede una copia
proprietaria dei dati di un iscritto e, in fase di aggiornamento, il processo non
avviene in maniera istantanea in tutti i dipartimenti; il soggetto richiedente deve
infatti fare domanda di aggiornamento ad ognuno dei dipartimenti, causando
molte volte incongruenza tra le fonti.
11

12. Figura 4: Esempio di aggiornamento dati in un sistema non cooperativo
Una soluzione molto apprezzata per risolvere il problema si basa sulla creazione
di un’architettura che favorisca un approccio cooperativo tra dipartimenti. Questa
soluzione di BackOffice, nota come CIS (Cooperative Information System),
consente il libero scambio di servizi tra dipartimenti basandosi sul livello fisico
cooperativo di base.
La figura seguente mostra la connessione esistente tra le amministrazioni
collegate mediante una rete comune.
12

13. Administration1
Administration2
processes
processes
Internal
application
Internal DBs
Internal
application
Exported
services
Exported data
Exported
services
Internal DBs
Exported data
Basic services
Transport services
Figura 5: Architettura CIS
Basandosi su una tal struttura ciascuna amministrazione mette in condivisione
servizi e risorse verso le altre consociate; da qui nasce l’idea di raggruppare tutto
il materiale condiviso in un dominio fornendo delle interfacce per cooperare con
l’esterno.
Inoltre, per rendere possibile una sincronizzazione tra gli enti cooperanti, si
impone una standardizzazione di un set di parole, in cui ogni vocabolo non sia
ambiguo e si riferisca al medesimo concetto per tutte le amministrazioni facenti
parte dello schema di collaborazione.
L’utilizzo del repository è la soluzione ideale per i problemi finora accennati.
13

14. Le metodologie di lavoro
Il primo lavoro svolto per la costruzione di un repository della Pubblica
Amministrazione iniziò una decina di anni fa; l’attività aveva come scopo l’analisi
degli archivi dipartimentali della Pubblica Amministrazione Centrale al fine di
creare una piramide concettuale che riuniva le varie fonti di conoscenza.
Oggigiorno, allo scopo di creare un’architettura che permetta la collaborazione
tra la struttura Centrale e quella Locale, si è deciso di creare un repository sulla
parte PAL riutilizzando i risultati e le tecniche maturate dall’esperienza a seguito
del lavoro svolto sulla PAC.
Come è descritto in seguito, la nuova metodologia utilizza delle euristiche rispetto
a quella utilizzata nel primo lavoro; queste approssimazioni sono atte a diminuire
drasticamente il tempo di completamento e ridurre al minimo il numero di
persone coinvolte nell’opera.
La metodologia esatta per la PA Centrale
Lo scopo del primo lavoro eseguito sugli archivi della Pubblica Amministrazione
fu quello di riordinare l’enorme patrimonio informativo della parte centrale
analizzando ogni fonte di conoscenza di 21 delle più importanti amministrazioni
centrali italiane.
L’attività svolta ha seguito una precisa metodologia di lavoro composta da due
sessioni:
1. Rilevazione. In questa fase si sono raccolti tutti gli schemi logici dei
database delle amministrazioni esaminate e si sono convertiti in schemi
concettuali, basati su schemi ER, seguendo una procedura metodologica
di reverse engineering (vedere El Masri and Navate (2004)). Il risultato di
14

15. questa prima attività fu la creazione di 500 schemi concettuali di base
rappresentanti il contenuto delle basi dati delle amministrazioni esaminate,
con circa 5000 attributi e altrettante relazioni.
2. Aggregazione. La conoscenza fornita dai 500 schemi di base ottenuti al
passo precedente è praticamente ingestibile data la sua enorme ampiezza
di contenuti, si è dovuti ricorrere a delle tecniche di raggruppamento per
snellire il lavoro di piramidazione. Per questi motivi si è operato nei
seguenti modi:
a. Clusterizzazione. In questa sottofase si sono raggruppati gli schemi
di base a seconda alla loro natura omogenea e al contesto di cui
facevano parte. In questo compito si è fatto riferimento alla
classificazione Materia/Funzione proposta dalla IDC (International
Data Corporation), modificata in alcuni aspetti per corrispondere
meglio al contesto della Pubblica Amministrazione Italiana.
La moltitudine di schemi concettuali di base quindi è stata
partizionata in questi gruppi e, a tale scopo, si sono utilizzati dei
criteri di similitudine basati su distanze tali da creare 27 aree che
andavano a ricoprire tutto l’intero interesse della Pubblica
Amministrazione.
b. Integrazione-astrazione. Gli schemi contenuti in ogni cluster sono
stati integrati-astratti in modo tale da ottenere uno schema
rappresentativo dell’area amministrativa. In tal modo gli schemi
sono stati compressi in un'unica mappa concettuale che contiene le
entità più rappresentative del cluster per ottenere un insieme di
concetti con un giusto grado di dettaglio.
I 27 schemi concettuali così ottenuti sono stati posti al livello
successivo nella piramide del repository che si stava in tal modo
creando.
L’operazione di integrazione-astrazione è continuata ricorsivamente creando
15

16. schemi sempre più astratti che descrivevano la realtà fino a quel momento
considerata con un livello di dettaglio sempre più approssimato.
Nelle figure seguenti sono riportati lo schema IDC utilizzato come modello per la
creazione del repository e la piramide concettuale PAC derivata, in quest’ultima
sono rappresentati gli schemi concettuali dal penultimo livello dopo aver
integrato-astratto i cluster.
Pubblica Amministrazione
Risorse
Finanziarie
Servizi
Umane
Territorio e
Popolazione
Strumentali
Produzione
Relazioni
Ambiente
Salute ed
Lavoro e
Assistenza
Sicurezza
Sociale
Sociale
Istruzione
Relazioni
Sicurezza
Sicurezza
esterne
Giustizia
Cultura
esterna
interna
Figura 6: La Classificazione IDC
SCHEMA INTEGRATO DELLE BASI DI DATI DELLA PA DI 1° LIVELLO
SCHEMA INTEGRATO DELLE BASI DI DATI DELLA PA DI 2° LIVELLO
SCHEMA INTEGRATO DELLE BASI DI DATI DELLA PA DI 3° LIVELLO
RISORSE
SERVIZI
SERVIZI SOCIALI ED ECONOMICI
SERVIZI DIRETTI
TRASP ORTI
TRASPORTI
CO MU NICAZI ON I
10/178
AZIENDE AG RICOLE
AZIENDE INDUSTRALI
PRO DU ZIONE
3/53
LAVO RO
9/112
BENI CULTURALI
AM BIENTE
8/213
CU LTU RA
10/100
ISTRUZION E
3/134
AS SISTENZA
5/56
EDILI ZIA
I ST RUZI ONE AM BIEN TE
SERVIZIO SANITARIO
SANITA'
6/155
CRIMINALITA '
SICUREZZA INTERNA
SIC UREZZA
6/130
ATTIVITA' GIUR ID ICA
GIUST IZI A
6/76
DIFESA
10/76
PREVIDEN ZA
CA TASTO
AFFARI
ESTERI
4/36 RELAZIONI ESTERE IN ITALIA
6/53 RELAZIONI ITALIANE ALL' ESTERO
9/118
CERTIFIC AZIONI
4/121
3/66
RA PPRESENTANZE
ENT TER RI TORIALI
I
SERVIZI
CERT IFI CA- ASSIC URA ZIOSTATISTI CA SOCIALI E
NE SOCIALE
TERR IT ORIALI ZION E
3/75
6/95
D IPENDENTI
FORM AZIONE
RI SORSE
U MAN E
37/336
BEN I IM MO BILI
STRUM ENTI
AUTOMEZZI
RI SORSE
STRU MEN TALI E
I MMO BILIARI
2/89
3/59
2/65
3/182
3/30 TRA SFERI MENTO FOND I PU IBB LIC I
A ENTI LO CA LI PER ENTI
FISCO
CAPITO LI DI SPESA
DOGAN E
RISORSE
FINAN ZIAR IE
6/69
PROTO CO LLO
2/93
2/12 ORGANI C OLLEGIA LI
8/293
RIS ORSE D I
SUPPORTO
SERVIZI ECONOMICI
LAVORO
SERVIZI SOCIALI
9/118
SERVIZI GENERALI
Figura 7: Schema del Repository PAC
16

17. Il lavoro di astrazione ricorsivo porta alla creazione di uno schema vertice che
rappresenta, a livello più astratto, i concetti fondamentali del sistema informativo
della Pubblica Amministrazione Centrale.
Place
Property
Document
Subject
Individual
Legal person
Figura 8: Schema concettuale al vertice del Repository
Il contributo speso per la costruzione del repository PAC è stato molto salato in
termini di risorse lavoro.
Il solo lavoro di reverse engineering ha richiesto 200 mesi/persona per la
creazione di tutti gli schemi concettuali di base derivati dall’analisi di ogni base
dati di 21 amministrazioni statali. La costruzione di ogni schema astratto con il
meccanismo dell’integrazione-astrazione ha richiesto per ogni schema 2
settimane/persona, un rapido calcolo porta al totale di 24 mesi/persona per la
creazione di 55 schemi astratti.
Il lavoro effettuato sulla PAC ha suscitato interesse, ed ora tale attenzione si è
spostata sulla costruzione di un simile repository sulla parte locale della Pubblica
Amministrazione Piemontese, con la differenza della profonda riduzione delle
risorse umane coinvolte.
17

18. La metodologia approssimata per la PA Locale
Lo scopo perseguito durante il lavoro sulla parte Locale Piemontese della
Pubblica Amministrazione rimane analogo a quello della PAC; il fine resta
sempre l’ottenimento del Repository che descriva, a più livelli di dettaglio,
l’architettura concettuale dei dati all’interno della Pubblica Amministrazione.
La specifica più importante al nuovo lavoro è la riduzione netta dell’utilizzo delle
risorse umane.
A seguito di tale specifica non è dunque possibile riproporre il metodo di lavoro
effettuato anni prima sulla parte Centrale, in quanto molto dispendioso in termini
di risorse applicate. È necessario quindi riutilizzare i risultati ottenuti da tale
lavoro e riadattare le metodologie applicate.
Questa delicata richiesta esige il rianalisi delle metodologie di lavoro al fine di
trovare una possibile automazione o una semplificazione negli algoritmi utilizzati
precedentemente.
Euristiche applicate
L’accorgimento preso è ricaduto nell’utilizzo di supposizioni ed euristiche rispetto
alla metodologia utilizzata nel lavoro sulla parte centrale. Il riuso del repository
PAC è fondamentale, a seguito di tale lavoro si sono potuti definire delle linee
guida per la creazione di altrettanti repository su varie parti della Pubblica
Amministrazione.
Una prima supposizione può essere derivata dal fatto che le piramidi concettuali
della PAC e della PAL avranno sicuramente delle differenze date dalla natura
stessa delle amministrazioni, ma tali diversità si concentreranno in maggior
misura nella parte bassa, più vicina alla realtà di interesse e legata al mondo
amministrativo territoriale di competenza.
18

19. Secondo tale supposizione è possibile utilizzare la conoscenza contenuta nella
parte alta del Repository PAC per costruirne uno simile per la Pubblica
Amministrazione Locale.
È quindi ora possibile definire gli input per la costruzione del Repository PAL:
1. Il primo input essenziale sono gli schemi concettuali PAC.
I 500 schemi di base sono utili per avere traccia delle relazioni tra le entità,
mentre quelli astratti contengono della conoscenza per la costruzione
della piramide.
Riutilizzare la conoscenza degli schemi astratti del Repository PAC non è
comunque semplice data l’ampia varietà di concetti dei 50 schemi, è stato
quindi necessario trovare una forma di conoscenza più maneggevole. Si è
dunque estrapolato dai livelli più alti della piramide PAC una serie di
concetti fondamentali rappresentanti le gerarchie dei concetti contenuti nei
livelli più alti della piramide.
Partendo dal vertice si è applicata una visita top-down seguendo
l’evoluzione
dei
cinque
concetti
fondamentali
della
Pubblica
Amministrazione (vedi figura 8) nei livelli inferiori. Questa forma più densa
di conoscenza può essere rappresentata sottoforma di lista di concetti
gerarchicamente ordinati. Tale struttura prende il nome di “gerarchie di
generalizzazioni” e costituisce un importante input per la nuova
metodologia.
A titolo di esempio, nella figura seguente viene mostrata la gerarchia di
generalizzazione dell’entità Soggetto.
SOGGETTO
SOGGETTO FISICO - PERSONA FISICA
ASSISTITO
CANDIDATO
CONTRIBUENTE
APPARTENENTE CATASTO
CONDANNATO
IN ATTESA DI GIUDIZIO
19

20. DISOCCUPATO
ITALIANO
RESIDENTE ALL'ESTERO
LAVORATORE
AUTONOMO
DIPENDENTE
IMPRENDITORE
PENSIONATO
SEGNALATO
TOSSICODIPENDENTE
VOLONTARIO
SOGGETTO GIURIDICO
IMPRESA
Figura 9: Gerarchia di Soggetto
2. Il secondo input riguarda ovviamente la conoscenza diretta del settore
Locale della Pubblica Amministrazione, senza il quale non sarebbe
sensato proseguire il lavoro.
Il CSI Piemonte, che gestisce l’area Piemontese della Pubblica
Amministrazione, dispone di circa 450 basi dati di 12 delle più importanti
amministrazioni Piemontesi in grado di coprire gran parte dell’intera area
regionale dei servizi al cittadino e alle imprese.
Con tale conoscenza posseduta sotto forma di schemi logici è possibile
ottenere schemi relazionali, tabelle, descrizioni di tabelle, attributi,
descrizione di attributi e vincoli di integrità referenziale tra tabelle.
20

21. Pubblica
Pubblica Amministrazione Centrale
Amministrazione
Locale
Schemi
Gerarchie di
Concettuali
Schemi
generalizz.:
Repository degli
Astratti
-Soggetto
-Documento
-Luogo
-Bene
Schemi Concettuali
Schemi Base
della PAL
Schemi
Logici
Figura 10: Input per la metodologia PAL
Di supporto agli input descritti è necessario affiancarsi della presenza della figura
di un esperto. Data l’automazione della metodologia che si basa su euristiche, è
necessaria una verifica tecnica che ha lo scopo di correggere gli schemi
concettuali prodotti e analizzare la struttura del repository creato alla fine del
lavoro.
Come nel caso PAC, la metodologia di lavoro si compone di 2 fasi principali:
a. Riconcettualizzazione degli schemi logici delle basi dati. La conoscenza
fornita dal gestore della Pubblica Amministrazione Locale Piemontese è
sotto rappresentata sottoforma di schemi logici, poco manipolabili
concettualmente; è necessaria quindi una operazione di reverse
engineering che segua una metodologia specifica.
b. Integrazione-astrazione. Operazioni già descritte precedentemete atte alla
creazione
del
Repository.
La
clusterizzazione
e
la
modalità
di
accoppiamento degli schemi seguono un modello simile a quello proposto
dalla IDC (vedi Figura 6) ma fortemente specifico per la località territoriale.
21

22. I passi metodologici per la riconcettualizzazione di schemi logici delle
basi dati PAL
Per ogni schema logico rappresentativo di un database della PAL è necessario
applicare una metodologia di reverse engineering al fine di ottenere una
completa serie di schemi concettuali di base, i quali poi verranno integrati e
astratti per l’ottenimento della piramide concettuale.
Tale metodica si compone di 4 passi, ognuno dei quali applica specificatamente
un algoritmo che utilizza dei dati in input per produrre uno schema risultato
parziale.
A seguito di tali passi operativi è presente il passo del Domain Expert Check in
cui la figura dell’espero analista è fondamentale per certificare la correttezza dei
risultati prodotti.
Passo 1. Estrazione delle entità
Input: Le quattro gerarchie di generalizzazione PAC
Input: Database PAL sottoforma di Schema Logico
Scopo di questa fase è ricercare tutte le entità correlate ad un database,
cioè estrapolare degli elementi di conoscenza da un archivio prescelto della
Pubblica Amministrazione Locale.
Per fare ciò è richiesto un algoritmo comparativo che lavori su ogni nome
delle entità nella lista delle gerarchie comparandolo con alcuni elementi
dello schema logico del database PAL, in particolare si necessita un
controllo sui nomi e descrizioni delle tabelle e sui nomi e descrizioni degli
attributi (campi).
Lo scopo dell’algoritmo comparativo è la generazione di un valore
sottoforma di un punto in uno spazio a 4 dimensioni secondo la seguente
uguaglianza:
P(concetto) = <#nomi_tabella, #descriz_tabella, #nome_attributo. #descriz_attributo>
22

23. dove ogni elemento # corrisponde al numero di elementi trovati che hanno
distanza con il concetto inferiore di un certa soglia prefissata.
Un concetto è selezionato se la somma degli elementi # supera un secondo
valore di soglia. In questo caso il concetto può essere classificato come
entità o come attributo a seconda della più stretta vicinanza ad uno di questi
due punti:
Pentità = <#nomi_tabella, #descriz_tabella, 0, 0>
Pattributo = <0, 0, #nome_attributo. #descriz_attributo>
Resta ora solo il fatto di associare gli attributi con le entità; questa scelta è
facilmente operabile abbinando gli attributi con le entità più vicine nello
spazio.
Infine, nello schema concettuale di output vengono inserite solo le entità,
con i relativi attributi, che hanno una frequenza di matching superiore di un
certo valore di soglia fissato.
Output: Schema Concettuale con entità indipendenti.
23

24. Documento
Luogo
Soggetto
E3
Bene
Gerarchie di
E2
Generalizzazione
E1
Schema Logico
….
E2
Schema Concettuale
E1
E3
Figura 11: Estrazione delle entità
Passo 2. Aggiunta delle generalizzazioni
Input: Le quattro gerarchie di generalizzazione PAC
Input: Lo schema Concettuale parziale precedentemente ottenuto
Lo schema ottenuto nella Passo 1 viene arricchito con le generalizzazione
tra le entità. Per effettuare tale operazione si riprendono i nomi delle entità
selezionate nello schema concettuale e si ricercano nelle liste di
generalizzazione collegandole tra loro in modo opportuno.
Output: Schema Concettuale arricchito con le generalizzazioni.
24

25. Documento
Luogo
E3
Soggetto
Bene
Gerarchie di
E2
Generalizzazione
E1
Schema Concettuale
E2
E1
E3
E2
E1
precedente
Schema Concettuale
E3
arricchito
Figura 11: Aggiunta delle generalizzazioni
Passo 3. Estrazione delle relazioni
Input: I 500 schemi Concettuali di base della PAC.
Input: Le quattro gerarchie di generalizzazione PAC.
Input: Lo schema Concettuale parziale precedentemente ottenuto.
Le relazioni tra le entità sono da ricercarsi tra tutti gli schemi concettuali di
base della PAC. Per questo lavoro è necessario utilizzare un algoritmo di
comparazione che selezioni tutte le coppie di entità dello schema
concettuale provvisorio che si relazionano in quelli PAC. Sono da
considerarsi valide le relazioni dirette (E1-E3) e quelle indirette passanti per
altre entità (E1-Ex-..En-..-Ey-E3).
Inoltre, a seguito dell’impiego di generalizzazioni, le entità figlie ereditano le
proprietà dai padri, tra cui le relazioni. Dunque, è altresì indispensabile
ricercare le relazioni eventuali anche con i predecessori delle entità e
attribuire a questi le relazioni trovate.
25

26. Il nome assegnato alla relazione tra due entità è quello maggiormente
frequente negli schemi base PAC, oppure in seconda ipotesi può essere
assegnato dalla figura dell’esperto di dominio.
Output: Schema Concettuale arricchito delle relazioni
Documento
Luogo
Soggetto
E3
Bene
Gerarchie di
E2
Generalizzazione
E1
E2
E2
E1
E3
E1
E1
Schemi Base PAC
Schema Concettuale
E2
E1
E3
E3
arricchito
Figura 12: Aggiunta delle relazioni
Passo 4. Controllo schema con i vincoli di integrità referenziale
Input: Lista dei vincoli tra tabelle nei database PAL
Input: Lo schema Concettuale parziale precedentemente ottenuto
In questa fase è necessario possedere una lista di vincoli tra tabelle sullo
schema logico del database della PAL considerato. Lo scopo di questa
parte di algoritmo è quella di migliorare la qualità dello schema concettuale
aggiungendo nuove entità e relazioni favorite dall’analisi dei vincoli
referenziali tra tabelle.
Analizzando ogni coppia di tabelle collegate, si cercano le eventuali entità
associate e si pongono le seguenti considerazioni:
o Se entrambe le tabelle della coppia non sono associate ad entità, si
passa all’analisi della coppia successiva senza effettuare operazioni.
26

27. o Se solo un nome tabella della coppia è associato ad una entità allora
l’altra tabella viene inserita nello schema concettuale creando una
nuova relazione.
o Se entrambi i nomi tabella sono associati ad entità si verifica
l’esistenza di una relazione, se non esiste la si crea.
Output: Schema Concettuale arricchito dei vincoli
Schema Logico con
K3
…..
vincoli tra tabelle
K2
Schema
E2
E1
E3
E2
E1
Concettuale
Schema
E3
Concettuale
Figura 13: Controllo schema con i vincoli referenziali
Passo 5. Verifica dell’esperto
Input: Lo schema Concettuale parziale precedentemente ottenuto
Ultima fase della metodologia di riconcettualizzazione degli schemi logici
delle basi dati della Pubblica Amministrazione Locale è la verifica della
correttezza dello schema Concettuale. Tale schema deriva dalla creazione
automatica derivante da una metodologia che fa uso di euristiche e dunque
potenzialmente affetto da errori e mancanze.
Il compito dell’esperto di dominio è la modifica dello schema concettuale
secondo il proprio volere dettato dalla propria esperienza. La modifica
27

28. contempla operazioni di aggiunta, cancellazione o correzione di concetti
espressi nello schema.
Output: Schema Concettuale finale
Molto frequentemente capita che lo schema finale e quello proposto
dall’automazione coincidono, questo fatto indica la correttezza, e dunque la
validità, della metodologia applicata.
I passi metodologici per la creazione degli schemi astratti PAL
La metodologia descritta fino a questo punto è utile solo alla creazione degli
schemi concettuali rappresentanti ogni base dati della conoscenza della Pubblica
Amministrazione Locale. Per ottenere il repository è necessario astrarre ed
integrare gli schemi finora prodotti in modo da ottenere una piramide di concetti.
I primi 3 passi della metodologia per la creazione degli schemi concettuali sono
effettuati con l’ausilio della conoscenza PAC e, in tal modo, possono essere
facilmente confrontati con gli schemi caratterizzanti il repository della Pubblica
Amministrazione Centrale.
A tale scopo, lo schema concettuale creato con la metodologia precedente può
essere separato in due parti:
o Schema iniziale. È l’insieme di entità con i rispettivi attributi, comprensivi
delle generazioni e delle relazioni, ottenute nei primi 3 passi della
metodologia PAL per la creazione degli schemi concettuali. La
conoscenza contenuta deriva dall’esperienza PAC applicata al campo
locale dell’Amministrazione.
o Schema arricchito. È lo schema concettuale ottenuto dal completo
svolgimento dei 5 passi della metodologia. Comprende della conoscenza,
come i vincoli tra tabelle ed elementi aggiunti dall’esperto, specifica del
campo locale della Pubblica Amministrazione.
28

29. Schema iniziale
Schema concettuale
Repository PAL
Schema arricchito
Figura 14. Spaccatura dello schema concettuale e posizione delle parti.
Dopo tale classificazione, gli schemi arricchiti possono essere posizionati alle
base della piramide opportunamente raggruppati per genere di appartenenza.
Mentre gli schemi iniziali possono essere confrontati con la piramide PAC per
poter essere inseriti nella corretta posizione del repository PAL. Tale posizione
può essere determinata in base alla posizione delle entità presenti negli schemi
iniziali
rispetto
alle
4
generalizzazioni
presenti
nelle
gerarchie
di
generalizzazione.
La metodologia per la creazione degli schemi astratti lavora con i seguenti passi
successivi per ogni schema concettuale PAL prodotto:
Passo 1. Clusterizzazione dello schema arricchito.
Gli schemi concettuali ottenuti nella fase di riconcettualizzazione (schemi
arricchiti) vengono raggruppati in gruppi di omogenea natura.
In questo passo lo schema arricchito viene aggiunto ad un cluster. La
misura della vicinanza tra schemi può essere ottenuta dalla similarità dei
concetti presenti negli schemi di base clusterizzati nella base del repository
PAC.
Passo 2. Calcolo del livello di astrazione dello schema iniziale
In questa fase viene associato un valore di astrazione VALi allo schema
iniziale i tramite un algoritmo che segue la seguente sottoprocedura.
29

30. o Si divide lo schema in gruppi corrispondenti alle 4 gerarchie (bene,
soggetto, documento, luogo).
o Per ogni gruppo si calcola il corrispettivo valore di astrazione dato
dalla somma delle distanze dal livello massimo nella gerarchia in
proporzione al numero di concetti presenti nel gruppo.
o Il valore di astrazione VALi dello schema iniziale sarà la media
pesata dei 4 livelli di astrazioni calcoli sui gruppi.
Passo 3. Associazione dello schema iniziale ad un livello astratto
Similarmente, per ogni schema astratto della piramide PAC (vedi figura 7)
viene calcolato un valore di astrazione VACj con la sottoprocedura al passo
2 e, successivamente, si può associare un valore ALlivello al livello di
astrazione della piramide PAC ottenuto dalla media dei valori VACj
posizionati a tal livello.
Ora è possibile associare lo schema iniziale PAL al livello k astratto PAC
con valore ALk più vicino a VALi.
Passo 4. Creazione dello schema astratto PAL
Per ogni schema astratto SCkj del livello k della piramide PAC prescelto nel
passo precedente si estraggono i concetti che appartengono anche allo
schema iniziale PAL e si aggiungono allo schema astratto SLkj nella
piramide PAL simmetrica a quella PAC.
Con il completamento di tali passi su tutti gli schemi concettuali PAL si ottiene il
completamento del repository della Pubblica Amministrazione Locale.
30

31. Confronto con altre metodologie
La letteratura a riguardo è molto vasta, l’interesse verso i repository delle basi
dati nutre molta curiosità anche in campi lontani dalla Pubblica Amministrazione.
L’interesse in materia si divide su due aspetti del mondo dei repository.
o Le primitive per l’organizzazione dei repository e le metodologie per la sua
produzione.
o Nuovi metodi per rappresentare la conoscenza del repository.
Mirbel (1997) propose un lavoro attinente al primo interesse. Usando un modello
descrittivo basato su parole e concetti, l’autore si prefissa lo scopo di ottenere
delle primitive di integrazione su schemi a oggetti al fine di ottenere come
risultato la creazione di schemi astratti. Tali funzioni sono molto simili a quelle
usate in questa tesi, ma Mirbel non ha dato prova di un’efficacia pratica su un
progetto di larghe dimensioni.
Nei lavori Castano, De Antonellis e Pernici (1998) e Castano e De Antonellis
(1997) si propongono dei criteri e delle tecniche per il confronto tra database. Le
tecniche consistono nell’estrazione di concetti e gerarchie di concetti da ogni
singolo database per il successivo confronto incrociato. La generazione dei
concetti è possibile grazie all’utilizzo di un dizionario semantico che abbina
elementi del database con concetti per vicinanza semantica. Perplessità si
manifestarono comunque al momento dell’effettiva applicazione nel campo della
Pubblica Amministrazione.
Il documento di Shoval, Danoch e Balabam (2004) punta all’affermazione del
concetto di schema astratto pacchettizzato. Il metodo di rappresentazione EntitàRelazioni è nuovamente utilizzato e l’astrazione viene formalizzata tramite
raggruppamento di concetti; nei nuovi schemi astratti creati, le entità pacchetto
sostituiscono interi gruppi di entità e relazioni presenti negli schemi a più basso
livello.
31

32. In questo lavoro il concetto di astrazione è più curato ed espanso, e sicuramente
le primitive sono più potenti di quelle presenti nella metodologia utilizzata in
questa tesi, ma non viene minimamente accennata l’integrazione. L’unione
integrazione-astrazione permette maggiori vantaggi producendo una visione
riassuntiva dei livelli sottostanti, mentre l’uso dei pacchetti pone solo dei link a
delle realtà complesse.
Sulla parte della rappresentazione della conoscenza all’interno dei repository si
possono confrontare i seguenti documenti.
Nei lavori di Wang e Gasser (2002), Di Leo, Jacobs, Pand e De Loach (2002) e
Fanquhar, Fikes, Pratt e Rice (1995) si discute su allineamento e l’integrazione di
ontologie dove l’integrazione di concetti è ottenuta grazie a delle precise
terminologie standardizzate.
Nei documenti viene trattato l’uso di alcuni tool e servizi atti all’utilizzo delle
ontologie condivise su reti geografiche distribuite. Grazie a tali programmi è
possibile costruire nuove ontologie importando concetti da moduli archiviati in
librerie.
Interessante infine il lavoro di Pan, Cranfield e Carter (2003) incentrato su un
sistema multiagente basato su ontologie con lo scopo di ottenere una
comunicazione non ambigua tra agenti. Tale ontologia definisce termini e
vocaboli usati nei messaggi codificati spediti nella comunicazione. In questo
utilizzo un repository sarebbe necessario al fine di condividere e riutilizzare
ontologie.
La metodologia narrata in questa tesi ha dei forti punti di vantaggio rispetto ad
altri lavori. Tali aspetti possono essere elencati di seguito e si possono ritrovare
descritti in maggior dettaglio nelle varie sezioni di questo del documento.
o L’utilizzo combinato delle primitive di integrazione-astrazione adottate per
la costruzione del repository.
o L’attenzione alla fattibilità e al ridotto utilizzo di risorse.
32

33. o Il riuso.
o L’impiego concreto delle metodologie in una realtà di interesse in larga
scala mediante l’implementazione in un tool.
L’utilizzo di euristiche per la riduzione delle risorse può generare in alcuni casi
errori o mancanze negli schemi concettuali, ma tali approssimazioni portano
indiscutibili vantaggi pratici.
33

34. Il tool
A seguito della metodologia descritta nei capitoli precedenti l’obbiettivo prossimo
per concretizzare l’opera è l’implementazione.
Per testare al meglio il programma creato sono necessarie le conoscenze di
base delle Pubbliche Amministrazioni, Centrale e Locale; mentre per la prima è
possibile riutilizzare le informazioni dei lavori svolti anni addietro, per la parte
Locale è stato indispensabile l’appoggio di una entità esterna che manipolasse
tale conoscenza.
L’interesse nella creazione di un tool è stato colto da un ente privato che,
mettendo a disposizione la conoscenza di un esperto è stato in grado di seguire
l’autore di questa tesi nella scelta degli algoritmi implementativi che più si
avvicinassero alla metodologia di costruzione del repository.
Tale collaborazione ha avuto la durata di 6 mesi, alla fine dei quali è stata
consegnata una versione affidabile e completa del tool per la creazione di
repository.
Il CSI Piemonte: organizzazione, ruolo e architettura tecnologica
L’ente che ha posto interesse nel progetto è il Consorzio dei Sistemi Informativi
della regione Piemonte (CSI Piemonte). Tale azienda serve quasi centralmente
l’intero patrimonio della Pubblica Amministrazione Locale nella regione e negli
ultimi anni ha visto cresce la sua conoscenza nella gestione di circa 450 basi dati
di 12 delle più importanti amministrazioni locali.
La mole di dati a disposizione del CSI è molto vasta e può essere considerata
un’ottima base per l’estrazione della conoscenza necessaria ai passi
34

35. metodologici per la riconcettualizzazione degli schemi logici e per la creazione
degli schemi astratti.
Il consorzio con sede a Torino dispone di una conoscenza centralizzata
conservata nel proprio sistema informatico e visibile all’interno di tutta la intranet
aziendale.
Tale mole di dati è gestita da un sistema a lato server chiamato InfoDir, che ne
manipola e ne rende accessibile il contenuto su tutta la rete.
Per gli scopi preposti dal CSI, la conoscenza di InfoDir è popolata da strutture
dati chiamate Collezioni, contenenti un insieme di metadati riferiti ad una
particolare vista della Pubblica Amministrazione Piemontese. Ogni Collezione è
partizionata in 2 parti strettamente collegate tra di loro.
o I Servizi. Una serie di procedure destinata alle imprese e al cittadino che
sono messe a disposizione dagli enti della PAL.
o Le Basi Dati. Lo schema logico/fisico di tutte le basi dati delle 12
amministrazioni gestite dal CSI. Da tale conoscenza è possibile estrarre
informazioni utili quali i nomi dei database, i nomi e descrizioni delle
tabelle e i campi (attributi), e i vincoli di integrità referenziale esistenti tra
tabelle.
InfoDir
Collezioni
Tassonomia
per materia
BasiDati
Tabelle
Servizi
Tassonomia
per istituzione
Componenti architetturali
Campi
Figura 15. Schema di InfoDir.
35

36. Per lo svolgimento di una procedura possono essere necessarie più fonti dati,
dunque ad ogni Servizio può essere associato una o più Basi Dati, e
simmetricamente una Base Dati può essere associata a più Servizi.
I dati forniti da InfoDir possono essere visualizzati secondo delle tassonomie
create appositamente per degli scopi prefissati. Due di queste sono state
utilizzate nella sperimentazione del tool ed elencano la conoscenza della
Pubblica Amministrazione secondo le materie (o argomento) trattate dalle varie
sezioni, oppure per istituzione.
I dati PAL necessari alla metodologia possono essere estratti dal catalogo InfoDir
e importati da tool di modellazione e rappresentazione che formattano la
conoscenza e creano ad hoc dei file pronti ad essere importati nel tool obbiettivo
di questa tesi.
Le prime specifiche
Precedentemente alla progettazione del tool si sono definiti una serie di vincoli
che il programma dovrà garantire una volta terminato il processo di
implementazione.
In prima analisi si definirono una serie di vincoli atti alla creazione di un piccolo
tool ristretto alle funzionalità dettate dalla metodologia citata nei capitoli
precedenti. In base a tali direttive le funzioni che il tool doveva supportare erano
le seguenti.
o Produzione di una funzione che dato in input uno schema logico, produca
in output uno schema concettuale seguendo i 5 passi della metodologia di
riconcettualizzazione.
36

37. o Produzione di una funzione che dato in input n schemi concettuali,
produca in output uno schema concettuale secondo la metodologia
dell’integrazione-astrazione per la produzione di schemi astratti.
A seguito di una rapida e compiaciuta implementazione, a tali funzionalità se ne
sono poi aggiunte altre allo scopo di rendere più potente e funzionale il tool. Tali
migliorie sono descritte nelle sezioni successive.
La metodologia implementata per la PA Locale
Il processo di sviluppo prevede la creazione di una serie di funzioni atte ognuna
all’implementazione di un passo della metodologia. Tali funzioni vengono poi
richiamate da altri metodi di più alto livello che ne gestiscono la sequenza.
Allo scopo di realizzare nel più breve tempo possibile una versione del tool
stabile e completa si è deciso di porre delle approssimazioni alla metodologia
originale sui dati PAL. Tali euristiche risiedono negli algoritmi applicati in ogni
funzione, dunque non si è modificata la struttura metodologica delle operazioni
ma soltanto alcuni aspetti che in futuro potranno essere facilmente modificati
riscrivendo le funzioni interessate.
L’utilizzo
di
euristiche
ha
interessato
sia
la
metodologia
per
la
riconcettualizzazione degli schemi logici, sia quella per l’integrazione-astrazione
per la creazione di schemi astratti.
37

38. La metodologia semplificata per la riconcettualizzazione
Una prima scelta attuata che diverge dalla metodologia PAL teorica è la non
creazione di un unico schema concettuale espanso di passo in passo.
Tale scelta è stata dettata dalla complessa costruzione di un modello che
rappresenta uno schema concettuale; l’utilizzo dei costrutti atti a contenere
informazioni sullo schema (quali entità, attributi, relazioni e vincoli) richiederebbe
poi l’ausilio di un tool specifico per la riproduzione di schemi grafici con
conseguente complicazione delle prime fasi di sviluppo.
A tale scopo, si è preferito creare un semplice output testuale specifico per ogni
passaggio che ne contenesse le informazioni raccolte. L’insieme di tali schemi
prodotti nei passi per la riconcettualizzazione forma un set di informazioni
indipendenti tra loro che possono essere analizzate singolarmente.
Inoltre si è deciso di snellire la procedura di estrazione delle entità e degli attributi
separando il processo in due passi distinti; tale scelta è derivata dalla notevole
complicazione dell’algoritmo di estrazione delle entità, il quale ha subito anche
una modifica completa nell’algoritmo di pesca dei concetti.
Le limitazioni apportate hanno sicuramente degradato il livello qualitativo del
prodotto finale in relazione con la metodologia originale PAL, ma ha garantito
una rapida produzione di una prima versione affidabile del tool.
38

39. Add Entity
Add
Generalization
Add
Relationship
Add Attribute
Infer
Constraints
Set di informazioni
Figura 16. Schema della metodologia di riconcettualizzazione dello schema logico di una base
dati PAL
Le nuove funzioni per la riconcettualizzazione di schemi logici seguono i seguenti
passi.
Passo 1. Add Entity (Estrazione delle entità)
Input: Le quattro gerarchie di generalizzazione PAC
Input: Struttura della Pubblica Amministrazione Locale
In questa prima fase di sviluppo si è deciso di utilizzare un metodo di
confronto più semplice per ritrovare i concetti all’interno di un database PAL.
Ogni entità all’interno delle quattro gerarchie ha abbinata una stringa che ne
identifica la sostanza. Tale stringa è utilizzata come criterio like per il
confronto rapido con gli elementi nello schema logico della base dati, tali
elementi di confronto sono i nomi e le descrizioni delle tabelle e dei campi.
Il confronto è basato su query SQL che hanno il vantaggio di produrre
risultati con una estrema velocità di elaborazione.
Se la funzione like di una entità restituisce almeno un confronto positivo su
un
elemento
dello
schema
logico,
tale
entità
viene
considerata
rappresentativa della base dati e viene passata in output.
Output: Lista delle entità abbinate alla base dati PAL
Output nascosto: Lista delle entità affiancate dall’elemento generante dello
schema logico
39

40. Documento
Luogo
E3
Soggetto
Bene
Gerarchie di
E2
Generalizzazione
E1
Schema Logico di
una base dati PAL
Lista nascosta delle
Lista
E1
E1
delle entità
E2
E2
entità con elementi
E3
E3
generanti
Figura 17. Add Entity
Passo 2. Add Generalization (Aggiunta delle generalizzazioni)
Input: Le quattro gerarchie di generalizzazione PAC
Input: La lista delle entità precedentemente ottenuta
L’aggiunta delle generalizzazioni alle entità trovate viene effettuata
riutilizzando il listato di output del passo precedente. Ogni entità letta in tale
elenco viene ricercata nelle quattro gerarchie di generalizzazioni e risalendo
l’albero gerarchico si annotano tutte le entità padre incontrate.
Output: Lista con le gerarchie delle entità
40

41. Documento
Luogo
E3
Soggetto
E4
E2
Bene
E1
E1
E2
Gerarchie di
Generalizzazione
Lista delle entità
E3
E4.generaliz.E2.generaliz.E1
E4.generaliz.E2
Lista delle
Generalizzazione
E3
Figura 18. Add Generalization
Passo 3. Add Relationship (Estrazione delle relazioni)
Input: Elenco delle relazioni degli schemi concettuali di base PAC
Input: La lista delle gerarchie di entità ottenuta al passo precedente.
Per questa fase è necessario disporre di una lista di tutte le coppie di entità
che sono in relazione negli schemi concettuali PAC. È possibile ottenere
tale lista estraendo della conoscenza dal materiale informatico a
disposizione che incorpora il repository PAC.
Nelle prime fasi di sviluppo, a scopo di test, è stato utilizzato un ridotto
numero di relazioni tra entità estrapolate solamente dallo schema
concettuale al vertice della piramide. Tali relazioni mostrano solo i legami
tra le entità di più alto livello (vedi figura 8).
L’algoritmo utilizzato in questo passaggio prevede l’analisi delle relazioni
verificando l’esistenza di ogni entità della coppia nella lista delle gerarchie di
entità trovate nel database PAL. In caso positivo la relazione viene passata
in output conservando il nome della relazione PAC.
Il controllo su ogni entità delle gerarchie può creare ridondanza sulle
relazioni, in quanto può capitare che si associ la stessa relazione sia ad una
41

42. entità padre sia al figlio, ma per le prime fasi di sviluppo questo metodo ha
portato notevoli vantaggi in termini di tempo e di completezza del lavoro.
Output: Lista delle relazioni tra entità PAL.
E1.relaz.E6
Lista delle relazioni
E1.relaz.E3
tra entità PAC
E3.relaz.E4
…
E19.relaz.E14
Lista delle
E4.generaliz.E2.generaliz.E1
E4.generaliz.E2
Generalizzazione
E3
Lista delle Relazioni tra
E4.relaz.E3
E3.relaz.E1
entità nella base dati PAL
Figura 19. Add Relationship
Passo 4. Add Attributes (Aggiunta degli attributi)
Input: Lista delle entità affiancate dall’elemento generante dello schema
logico, prodotto nel passo 1
Semplicemente, in questo passo viene prodotta in output una lista ordinata
dei nomi delle entità con abbinati gli elementi dello schema logico definiti
come attributi. Un elemento può essere definito attributo se:
o è un nome di un campo dello schema logico ed è stato selezionato
dalla funzione like del passo 1.
o è un nome di un campo dello schema logico e la sua descrizione è
stata selezionata della funzione like del passo 1.
Si noti che vengono selezionati solo i nomi dei campi, tralasciando i nomi
delle tabelle e delle descrizioni.
Output: Lista delle entità con i relativi attributi
42

43. Lista nascosta delle
E1
E2
entità con elementi
E3
generanti
E1
Lista entità del database
att1 descr
E2
attr2 descr
attr3 descr
PAL con i relativi
attributi
E3
attr4 descr
Figura 20. Add Attributes.
Passo 5. Infer Constraints (Controllo schema con i vincoli di integrità
referenziale)
Input: Elenco dei vincoli tra tabelle nei database PAL
Input: Lista delle entità affiancate dall’elemento generante dello schema
logico, prodotto nel passo 1
Il passo corrente permette di migliorare le relazioni tra entità aggiungendo
quelle prodotte dai vincoli di integrità referenziale tra tabelle nello schema
logico. Per questo scopo è necessario possedere una conoscenza specifica
della base dati in analisi che contenga la lista dei vincoli di referenza tra i
nomi delle tabelle.
Accoppiando tale conoscenza con la lista delle entità abbinate alle tabelle
(ricavata dal secondo input) si effettuano i seguenti controlli:
o se entrambe le tabelle referenziate sono abbinate a delle entità allora
tali entità vengono referenziate in output.
o se solo una tabella è abbinata ad una entità allora tale entità viene
referenziata in output con la tabella non abbinata ad entità.
43

44. Le tabelle elencate in output che non sono abbinate ad entità vengono
considerate tabelle esterne.
Output: Lista delle referenze tra due entità
Output: Lista delle referenze tra una entità e una tabella esterna
Output: Lista delle tabelle esterne
Tab1.refer.Tab6
Lista delle relazioni
Tab1.refer.Tab3
Tab3.refer.Tab4
tra entità PAC
…
Tab19.refer.Tab14
E1
Lista nascosta delle entità
E2
con elementi generanti
E3
Lista delle Relazioni
tra entità nella
base dati PAL
E2.refer.E3
Tab2
Lista delle
E3.refer.Tab2
.Tab1
tabelle esterne
E2.refer.Tab2
E4 refer Tab1
Figura 21. Infer Constraints.
La metodologia semplificata per la creazione di schemi astratti
La metodologia presentata precedentemente ha lo scopo di creare per ogni
database PAL analizzato un set di liste di output, le quali rappresentano
singolarmente una caratteristica dello schema concettuale abbinato al database;
tale
schema
troverà
posto
alla
base
del
repository
della
Pubblica
Amministrazione Locale.
44

45. La creazione degli schemi sovrastanti differisce dalla metodologia originale PAL,
introdotta nei primi capitoli, in quanto troppo complessa da implementare in un
ristretto periodo di tempo. Lo scopo alla base della presente tesi è la creazione
rapida di un tool che utilizzi il minor numero di risorse, e dunque si è preferito
optare per una metodologia più semplice, ma comunque efficace, con lo scopo di
portare a conclusione il progetto.
Tuttavia, in vista di futuri miglioramenti, la progettazione è stata fatta in modo
modulare con la possibilità di intervenire su alcuni aspetti implementativi per
migliorarne la qualità ed avvicinarsi alla metodologia originale PAL.
L’avanzamento nella creazione degli schemi astratti avviene in maniera graduale
e crescente dalla parte inferiore della piramide fino ad arrivare al vertice.
Differentemente, nella metodologia originale la creazione avveniva in modo
sparso, con la creazione a macchie di schemi concettuali astratti che ottenevano
la loro posizione all’interno della piramide seguendo come esempio la struttura di
quella PAC.
Nella fase di implementazione non si è seguita tale strada; come accennato in
precedenza, il CSI dispone di alcune tassonomie che generalizzano concetti PAL
legate alle basi dati in proprio possesso, queste tassonomie hanno il vantaggio di
rappresentare un repository PAL specifico della regione di competenza e
possono essere utilizzate come linee guida per l’integrazione-astrazione di
schemi concettuali. La struttura di tali tassonomie viene spiegata nei capitoli
successivi.
Secondo tali cambiamenti la metodologia applicata alla creazione di schemi
astratti diverge completamente da quella originale, ma riprende i concetti basilari
delle operazioni di integrazione e astrazione.
Con l’utilizzo di una tecnica di selezione dei concetti fondamentali si è potuto
fondere in un unico passo metodologico le operazioni di integrazione e
astrazione. Tale tecnica è mostrata di seguito:
45

46. Passo Unico. Integrazione e astrazione di schemi concettuali
Input: n Set di liste rappresentanti n schemi concettuali da integrare/astrarre
L’algoritmo per l’integrazione e l’astrazione è indivisibile. In un solo
passaggio la procedura seleziona gli elementi candidati a poter essere
rappresentati anche al livello gerarchico più alto, ed esclude tutti quelli non
fondamentali che possono rimanere nel livello di appartenenza per dare
consistenza allo strato stesso.
L’operazione può essere eseguita su n schemi concettuali, dove n è
maggiore o uguale a 1 e la scelta dei componenti da importare nel nuovo
schema astratto è dato dalla seguente regola:
o se n=1 vengono esportati tutti gli elementi. Ciò vuol dire che se si
opera solo su uno schema, verrà restituito uno schema astratto
identico al primo senza aver operato nessuna astrazione. In questo
caso l’intervento umano dell’esperto apporrebbe il giusto tasso di
astrazione modificando la costituzione dello schema.
Al solito, il nuovo schema astratto sarà rappresentato dal set di liste
che ne contengono le varie caratteristiche.
o se n>1 viene creato uno schema astratto con il seguente principio. Il
procedimento
per
la
creazione
opera
sulle
fonti
concrete
rappresentative degli schemi concettuali da integrare/astrarre, cioè i
set di liste. A seconda della lista, si opera in modo diverso.
Esportazione delle entità.
Il componente fondamentale su cui si basa l’astrazione è l’entità,
si assumono come fondamentali quelle entità comuni a 2 o più
schemi, e tali entità verranno esportate nel nuovo schema.
Esportazione delle gerarchie
Le generalizzazioni tra entità vengono aggiunte eseguendo
nuovamente sullo schema astratto le operazioni eseguite nel
passo specifico nella riconcettualizzazione degli schemi logici
(Add Generalization).
Esportazione delle relazioni
46

47. Come per le generalizzazioni, si esegue sullo schema astratto la
stessa procedura utilizzata nella riconcettualizzazione degli
schemi logici (Add Relationship).
Esportazione degli attributi
L’aggiunta degli attributi invece segue lo stesso identico
procedimento delle entità. Per ogni entità esportata si
aggiungono i suoi attributi che sono comuni a 2 o più schemi.
Esportazione delle tabelle esterne
Le tabelle esterne vengono esportate con la medesima regola
della presenza in almeno 2 schemi da integrare/astrarre.
Esportazione delle relazioni di inferenza
Infine, si aggiungono le relazioni di inferenza date dai vicoli tra
tabelle, i collegamenti che verranno esportati devono avere la
peculiarità di collegare entità o tabelle già presenti nel nuovo
schema astratto ed essere presenti in almeno 2 schemi
concettuali da integrare/astrarre.
Output: 1 Set di liste con contenuti astratti
Figura 22. Integrazione-astrazione di 3 schemi concettuali.
47

48. Il processo di sviluppo
A fronte della definizione di una metodologia teorica da utilizzare e nella sua
corretta rivisitazione per l’atto pratico, si è potuti passare alla parte
implementativa.
Il primo obbiettivo perseguito è stato soddisfare le prime due specifiche richieste:
la creazione di uno schema concettuale e il processo di integrazione-astrazione.
Scelta della modalità di sviluppo
Il contratto lavorativo presso l’azienda convenzionata CSI Piemonte prevedeva
l’utilizzo di una forma di collaborazione di lavoro a distanza causata dalla
lontananza dell’autore della tesi con la sede operativa.
A tal fine è stato stabilito un piano lavorativo che comprendeva 4 giorni lavorativi
autonomi e 1 giorno lavorativo in sede a Torino. In tali giorni si è cercato di
analizzare costantemente l’operato autonomo dell’autore, valutando l’attività
svolta e pianificando quella futura; le giornate in sede hanno prodotto una serie di
colloqui molto fruttuosi, in cui le conoscenze pratiche e teoriche di un esperto e di
un
apprendista
si
fondevano
per
produrre
soluzioni
teoriche
e
di
implementazione.
A seguito della scelta di questa forma di lavoro si è deciso di ottimizzare la
programmazione seguendo una metodologia di sviluppo definita “evolutiva” che
ottimizzasse il lavoro in base alle esigenze di tempo e luogo.
Tale tecnica prevede la collaborazione stretta tra il committente e il
programmatore per uno sviluppo rapido e preciso in base alle richieste
sottoposte. L’utilizzo della programmazione evolutiva ha il vantaggio di poter
iniziare l’opera di sviluppo anche nel caso in cui non siano state chiarite a pieno
le specifiche, o non si sono apprese completamente le nozioni inerenti al
contesto del progetto.
48

49. Quest’ultimo scenario descrive perfettamente la realtà accaduta, dove il team di
lavoro, composto dall’autore e dal referenze aziendale del CSI, ha dovuto
formalizzare una metodologia implementativa al fine di semplificare quella
originale PAL.
Grazie allo sviluppo evolutivo le fasi di specifica, sviluppo e validazione sono
frammischiate tra loro, partendo infatti da una specifica astratta si sviluppa un
primo prototipo che può poi essere raffinato.
Specifiche
Versione
iniziale
Specifiche
Sviluppo
ad alto livello
Versioni
intermedie
Validazione
Versione
finale
Figura 23. Flussi di lavoro nello sviluppo evolutivo.
La fase di sviluppo quindi ha visto svolgersi la fase di studio di nuove tecniche e
soluzioni nell’unica giornata di incontro in sede, dedicando gli altri giorni
all’implementazione per la creazione di versioni intermedie sempre più elaborate
che si avvicinassero sempre più al prodotto finale.
Scelte implementative
La prima fase di sviluppo del software ha visto come argomento centrale la scelta
dei mezzi implementativi; la decisione dei tools per la progettazione e
l’implementazione ha influito notevolmente sul processo di sviluppo software.
49

50. I candidati all’utilizzo ricadevano nell’insieme dei software di conoscenza
dell’autore e si è cercato di scegliere la soluzione che massimizzasse il rapporto
tra semplicità implementativa e potenza espressiva, in modo da ottenere un tool
efficace ed efficiente.
Il software richiesto si compone di due applicativi con delle particolari
caratteristiche.
o Un ambiente di sviluppo. Un tool di programmazione che permetta una
rapida scrittura del codice per la creazione di tool visuali, riutilizzando a
tale scopo componenti precompilati per la creazione di interfacce con
elementi grafici già noti agli utenti.
Una seconda caratteristica del software atta al rapido sviluppo è la
possibilità di esecuzione e di debug in modalità “step by step” delle
istruzioni, molto utile per l’analisi dell’eseguibile in caso di errori
logici/sintattici in un programma di medie dimensioni.
o Un DBMS. Era noto fin dalle prime fasi che il tool finale avrebbe dovuto
possedere una base di conoscenza non ristretta, immagazzinata in una
struttura per garantire la memorizzazione e la facilità d’utilizzo.
È chiaro che le operazioni più frequentemente utilizzate sulla conoscenza
siano le query per l’ottenimento di particolari selezioni sui dati, e non è di
fondamentale importanza disporre di uno strumento DBMS di elevate
potenzialità, in quanto il tool deve utilizzare un database locale effettuando
semplici operazioni.
A seguito di attente valutazioni la scelta delle applicazioni è ricaduta su Microsoft
Visual Basic 6 come ambiente di sviluppo e Microsoft Access come tool DBMS;
la scelta di tali applicativi è derivata dalla semplicità di utilizzo e dalle buone
conoscenze che l’autore ha in merito ai due software.
50

51. La conoscenza di base e la sua estrazione
Successivamente alla definizione di una metodologia implementativa e degli
applicativi di sviluppo si è passati alla fase di acquisizione della conoscenza di
base PAL.
Tale fonte, come accennato nella metodologia implementativa del capitolo
precedente, è estratta dal sistema informativo aziendale chiamato infoDir
mediante tool di formattazione di dati e importata nel contenitore di conoscenza
del tool.
La quasi totalità dei dati è immagazzinata in un database gestito dal DBMS
Access per essere facilmente manipolata per restituire al tool le informazioni
richieste.
Di seguito sono elencate le varie parti della conoscenza utilizzate come input per
i passi metodologici.
o Struttura della Pubblica Amministrazione Locale. Contiene la struttura di
tutti gli schemi logici di 450 basi dati di 12 delle più importanti
amministrazioni PAL e costituisce una fotografia dei metadati delle basi
dati censite.
Per ogni base dati si hanno a disposizione i nomi e le descrizioni delle
tavole e dei relativi campi, e si è cercato di rappresentare tale schema
logico in una tabella fisica.
Tale conoscenza è stata memorizzata direttamente nel database Access
in una tabella che avrà dunque la seguente struttura.
Nome base dati
PAL
Nome Tabella
Descrizione
Tabella
Nome Campo
Descrizione
Campo
Figura 24. Schema della tabella con la struttura PAL.
51

52. Per praticità viene mostrato un esempio.
Base Dati: Personale
Persone
CodFis
Cognom
Nom
Indirizz
Telefon
…..
…..
…..
…..
…..
…..
…..
…..
…..
…..
Due relazioni di una base
dati PAL
Matricole
Matricola
CodFisc
…..
…..
…..
…..
Base Dati: Personale
Schemi logici delle
Persone (CodFisc, Cognome, Nome, Indirizzo, Telefono)
relazioni di una base dati
PAL
Matricole (Matricola, CodFisc)
Nome
Descr.
Nome Tabella
Base Dati
Tabella
Descr.
Nome Campo
Campo
Personale
Persone
…..
CodFisc
…..
Rappresentazione degli
Personale
Persone
…..
Cognome
…..
schemi intensionali delle
Personale
Persone
…..
Nome
…..
Personale
Persone
…..
Indirizzo
…..
Personale
Persone
…..
Telefono
…..
Personale
Matricole
…..
Matricola
…..
Personale
Matricole
…..
CodFisc
…..
relazioni di una base dati
PAL
Figura 25. Esempio di rappresentazione di uno schema logico.
Il contenuto di tale tabella non può essere mostrato data la sua vastità nel
contenere circa 815000 istanze.
o Le sei gerarchie di generalizzazione. Nel catalogo metadati infoDir
l’aspetto concettuale della Pubblica Amministrazione è stato suddiviso in 6
domini, rispetto ai 4 descritti nelle metodologie; le differenze si
52

53. concentrano solamente nella creazione dei domini “Territorio” e
“Urbanistica” in aggiunta al dominio “Luogo” per migliorarne la
competenza territoriale; i nuovi domini, infatti, sono stati aggiunti dopo una
sperimentazione manuale effettuata sulla PAL e sono prettamente di
carattere locale.
A seguito di tale modifica, negli schemi concettuali verranno mostrate due
nuove generalizzazioni.
Tali gerarchie vengono memorizzate in una tabella della base dati. È stato
quindi necessario ricercare un metodo per rappresentare una gerarchia
sotto forma di schema intensionale ed estensionale. Questo è stato
permesso grazie all’introduzione di un campo livello che indica il grado
della generalizzazione nella gerarchia, che a sua volta è rappresentata da
un identificativo nel campo “Codice della gerarchia”.
Secondo tali disposizioni lo schema logico della tabella è il seguente.
Codice della
gerarchia
Livello
Nome della
generalizzazione
Criterio like
Figura 26. Schema della tabella contenente le gerarchie di generalizzazione.
Come descritto nei capitoli precedenti ogni generalizzazione può essere
associata ad una base dati mediante l’abbinamento con degli elementi
dello schema logico tramite stringhe di confronto (criteri like).
Di seguito vengono riportate le schematizzazioni delle 6 gerarchie di
generalizzazione, una completa visione della tabella è allegata in
appendice.
BENE
IMMOBILE
ABITAZIONE
53

54. FABBRICATO
TERRENO
MOBILE
AUTOMOBILE
ACQUEDOTTO
DEMANIO FERROVIARIO
DEMANIO STRADALE
DEMANIO ARTISTICO STORICO CULTURALE
MERCATO COMUNALE
MUSEI BIBLIOTECHE PINACOTECHE
DEMANIO NECESSARIO IDRICO
BENE PATRIMONIALE
DOCUMENTO
ATTO REGISTRO
DOCUMENTO LIQUIDATO
VERSAMENTO
VERSAMENTO CON DELEGA
LUOGO
LOCALITA
CIVICO
STRADA
VIA
PARTICELLA CATASTALE
PORZIONE
PRIMITIVA GRAFICA
RIFERIMENTO CATASTALE
SUPERFICIE AGRICOLA
UNITA IMMOBILIARE URBANA
SOGGETTO
SOGGETTO FISICO - PERSONA FISICA
ASSISTITO
CANDIDATO
CONTRIBUENTE
APPARTENENTE CATASTO
CONDANNATO
IN ATTESA DI GIUDIZIO
DISOCCUPATO
ITALIANO
RESIDENTE ALL'ESTERO
LAVORATORE
AUTONOMO
DIPENDENTE
IMPRENDITORE
54

55. PENSIONATO
SEGNALATO
STRANIERO
RICHIEDENTE CITTADINANZA
STUDENTE
TOSSICODIPENDENTE
VOLONTARIO
SOGGETTO GIURIDICO
IMPRESA
TERRITORIO
CARTOGRAFIA DI SERVIZIO
LIMITI TERRITORIALI DI COMPETENZA TECNICO AMMINISTRATIVA
REGIONE
PROVINCIA
COMUNITA MONTANA
COMUNE
ARPA
ASL
AREE DI INTERESSE PER IMPATTO AMBIENTALE
AREA SENSIBILE
DISCARICA
AREE DI INTERESSE URBANISTICO
ISOLATO
VIABILITA' STRADALE
AUTOSTRADA
STATALE
ALTIMETRIA
TOPONOMASTICA
TOPONIMO CTR
BACINO IDROGEOLOGICO
BACINO IDROGRAFICO PRINCIPALE
POZZO
SORGENTE
PRESA
OPERA DI TRASPORTO
INSEDIAMENTO PRODUTTIVO
OPERA DI RECAPITO FINALE
RESTITUZIONE
IMPIANTO DI SOLLEVAMENTO
MODULATORE
SFIORATORE
URBANISTICA
TERRITORIO
COMUNE
55

56. PRATICA
STRUMENTO
DESTINAZIONE
VINCOLO
PARAMETRO
Figura 27. Elenco completo delle 6 gerarchie di generalizzazione.
o Le relazioni PAC tra entità. Nel database Access sono anche contenute le
relazioni concettuali della PA centrale. Queste relazioni, dedotte dagli
schemi originali della PAC, permetto di correlare le entità delle gerarchie
di generalizzazione nella creazione degli schemi concettuali PAL.
A causa della relativa difficoltà di ottenere automaticamente tutte le
relazioni PAC, la prima versione del tool utilizza soltanto le relazioni tra le
entità al vertice delle 6 gerarchie delle generalizzazioni.
La struttura atta a contenere tali relazioni utilizza 3 campi di una tabella
Access che presenta il seguente schema logico.
Entità From
Nome relazione
Entità To
Figura 28. Schema della tabella con le relazioni tra entità PAC.
Il contenuto di tale tabella è allegato in appendice.
o I vincoli tra tabelle nei database PAL. L’attività di estrazione dei vincoli
inferenziali tra tabelle è relativamente complessa in quanto non gode di
una completa automazione. Questa situazione nasce dall’infattibilità di
esportare la completa serie di vincoli presenti in tutti i database della
Pubblica
Amministrazione
Locale;
è
necessario,
infatti,
compiere
l’operazione su ogni base dati, rendendo obbligatoria la presenza di una
persona che svolga manualmente l’operazione tediosa dell’analisi
completa di tutti i 450 schemi logici PAL.
56

57. Per la fase di progettazione sono stati prodotti 3 elenchi di vincoli
infratabellari analizzando i database “MonI”, “AAEP Gestionale” e
“SMRGAA”. Nella successiva fase di testing il numero di elenchi disponibili
è salito a 12.
È comunque controproducente impedire al tool di rappresentare
concettualmente un database in assenza di vincoli inferenziali; si è infatti
preferito rendere questa fase opzionale e svolgibile solo se attuabile.
A seguito di queste considerazioni, si è scelto di far risiedere questo tipo di
conoscenza al di fuori del database Access, scegliendo come altra forma
di memorizzazione un file Excel. Queste scelte derivano da fattori di
praticità,
favorendo
il
lavoro
dell’operatore
umano
nell’attività
di
estrapolazione dei vincoli.
Ogni file Excel contiene le relazioni tra tabelle di un solo database PAL,
che darà così il nome al file rendendolo visibile al tool.
Tabella From
“referenzia”
Tabella To
Figura 29. Schema di un file Excel contenente i vincoli inferenziali tra tabelle di una base dati
PAL.
La figura precedente mette in evidenza delle somiglianze con la struttura
di memorizzazione delle relazioni tra entità, con la sola differenza del
campo verbo. In questo caso infatti si è preferito standardizzare la scelta
con la costante “referenzia”, ma è lasciata all’esperto la possibilità di
cambiare tale campo con una parola più appropriata.
Di seguito segue lo schema riassuntivo delle forme di input per la
riconcettualizzazione di uno schema logico di una base dati PAL.
57

58. File Excel
Database ACCESS
Metaschemi
DB PAL
6
Gerarchie
Relazioni
Entità PAC
Vincoli
DB1
PAL
Vincoli
DB4
PAL
…
Vincoli
DBn
PAL
Funzione di riconcettualizzazione
Schema
DB1
completo
Schema
DBn
completo
Schema
DB4
completo
Schema
DB2
parziale
…
Schema
DB3
parziale
Figura 30. Schema completo degli input per la riconcettualizzazione.
Progettazione e implementazione delle componenti
A seguito della formalizzazione della metodologia di implementazione e
dell’estrazione della conoscenza si è potuti passati alla fase di sviluppo. Si sono
prodotti, in fase incrementale, i 5 passi per la riconcettualizzazione di uno
schema logico di un database PAL, verificando l’effettiva efficacia del lavoro
svolto prima di passare allo step successivo.
Ogni passo metodologico è svolto da una serie di istruzioni impacchettate in una
funzione che prende il nome dalla fase metodologica. Di seguito vengono
descritte le 5 funzioni base che permettono la riconcettualizzazione, più quella di
integrazione e astrazione.
58

59. Aggiunta delle entità (addEntity)
Come specificato nella metodologia, al fine di estrarre le entità associate alla
base dati interessata, si confronta il criterio like abbinato ad ogni istanza delle 6
gerarchie di generalizzazione con il contenuto dei campi della tabella del
metaschema del database PAL.
La richiesta in questione trova soluzione nell’unione di due query; la prima
analizza i nomi e descrizioni dei nomi della tabelle, mentre la seconda confronta i
nomi e descrizioni dei campi.
Di seguito viene riportato il testo della query descritta.
SELECT
* into TabellaTemporanea
FROM
(
SELECT
Gerarchie.Nome AS Entità, MetaSchema.NomeTabella AS Tavola,
MetaSchema.DescrizioneTabella AS TavDesc, null as Campo, null as
CamDesc
FROM
MetaSchema, Gerarchie
WHERE
MetaSchema.NomeDataBase = database_scelto
and
(
(MetaSchema.NomeTabella like Gerarchie.Criterio)
Or
(MetaSchema.DescrizioneTabella like Gerarchie.Criterio)
)
Union All
SELECT
Gerarchie.Nome AS Entità, MetaSchema.NomeTabella AS Tavola,
MetaSchema.DescrizioneTabella AS TavDesc, MetaSchema.NomeCampo AS
Campo, MetaSchema.DescrizioneCampo AS CamDesc
FROM
MetaSchema, Gerarchie
WHERE
MetaSchema.NomeDataBase = database_scelto
and
(
(MetaSchema.NomeCampo like Gerarchie.Criterio)
or
(MetaSchema.DescrizioneCampo like Gerarchie.Criterio)
)
);
59

60. Allo scopo di analizzare solo il range di dati che interessa il database in
questione, si filtra la tabella del metaschema completa della conoscenza PAL
con un opportuno utilizzo del “where” sql.
Dall’esecuzione della query riportata viene prodotta una tabella fondamentale per
il tool, la quale verrà riutilizzata anche per i successivi passi. Nella tabella
temporanea si affiancano le entità emerse con gli elementi generanti risultati
positivi al confronto like.
Volendo descrivere l’attività svolta dalla query è possibile utilizzare anche la
seguente rappresentazione flowchart.
Start su Istanza
T abella li ke criterio
DB =
db_scelto
OR
Tab Descr l ike criterio
Si
Si
Aggiungi in output:
DB, T abella, TabDescr,
No
No
End su Istanza
Start su Istanza
Campo like
DB =
db_scelto
criterio
OR
C ampo Des cr lik e
criterio
Si
Si
Aggiungi in output:
DB, T abella, TabDescr,
Campo, CampoDescr
No
No
End su Istanza
Figura 31. Flowchart rappresentante la Query SQL di AddEntity
La funzione procede con la stampa su un file di testo delle entità elencate nella
tabella temporanea prodotta dalla query precedente.
60

61. La funzione di estrazione delle entità può essere riassunta nel seguente
diagramma delle attività.
Ricevi Nome DB da
Riconcettualizzare
Esegui la ricerca delle
Entità con la Query
Salva i risultati nella
Tabella Temporanea
Stampa su file di testo
i nomi delle Entità
Figura 32. Activity Diagram della funzione AddEntity
Aggiunta delle generalizzazioni (addGeneralization)
Il passo successivo nella metodologia implementata ha il fine di rappresentare la
completa gerarchia superiore di ogni entità fino a mostrare il padre alla radice.
Partendo da una entità, presente nella lista prodotta al passo precedente, si
cerca la corrispondente nella lista delle gerarchie di generalizzazione e, attuando
un criterio di ricerca, ci si punta all’entità padre immediatamente superiore.
Tale criterio segue la seguente regola.
Un’entità a è gerarchicamente superiore ad una entità b se:
o a e b sono nella stessa gerarchia
o a ha un indice di posizione inferiore a quello di b, cioè è posizionata più in
alto nella lista gerarchica
o a ha un livello gerarchico inferiore a quello di b (l’entità radice ha livello 1)
Con tali clausole viene creato un insieme parziale A di tutte le entità superiori
all’entità considerata ma, al fine di selezionare solo l’entità padre a*
immediatamente superiore a b, è necessario aggiungere la seguente:
o a* deve avere l’indice di posizione massimo tra tutti quelli nell’insieme A.
61

62. Il criterio è stato tradotto nella seguente query sql annidata che permette la
selezione dell’entità cercata in un tempo molto breve.
SELECT
distinct(IstanzeSuperiori.Nome)
FROM
(
SELECT
Gerarchie.*
FROM
Gerarchie, (SELECT Gerarchie.id, Gerarchie.cod, Gerarchie.livello FROM
Gerarchie WHERE Gerarchie.nome = Entità_Selezionata ) as IstanzaEntità
WHERE
Gerarchie.id < IstanzaEntità.id And Gerarchie.cod = IstanzaEntità.cod And
Gerarchie.livello < IstanzaEntità.livello
) as IstanzeSuperiori
WHERE
IstanzeSuperiori.id =
(
SELECT
max(IstanzeSuperiori2.id)
FROM
(
SELECT
Gerarchie.*
FROM
Gerarchie, (SELECT Gerarchie.id, Gerarchie.cod,
Gerarchie.livello FROM Gerarchie WHERE Gerarchie.nome =
Entità_Selezionata ) as IstanzaEntità2
WHERE
Gerarchie.id < IstanzaEntità2.id And Gerarchie.cod =
IstanzaEntità2.cod And Gerarchie.livello <
IstanzaEntità2.livello
) as IstanzeSuperiori2
) ;
Al fine di ottenere la completa lista generazionale è necessario iterare il processo
di ricerca del padre fino al raggiungimento dell’entità radice.
Tale lista viene proposta in output come stringa nel seguente formato:
EntitàRadice.generalizza.PrimoFiglio.generalizza.SecondoFiglio.generalizza…Nsimo
Figlio.generalizza.Entità_Selezionata
Con il passo di generalizzazione termina la fase di inserimento delle entità nello
schema concettuale, ora è dunque possibile archiviare in una tabella temporanea
tutti questi elementi in modo da riutilizzare questa conoscenza per i passi
successivi. Avere una lista semplice e maneggiabile di tutte le entità presenti
faciliterà il compito di cercare le relazioni tra di esse.
62

63. Di seguito viene presentato il diagramma delle attività del passo in questione.
* Per ogni Entità diversa presente nella Tabella Temporanea
Leggi l'Entità dalla
Tabella Temporanea
Ricerca il Padre con * Cicla finchè si arriva alla radice
della gerarchia
la Query
Stampa su file di testo
la gerarchia dell'Entità
Figura 33. Activity Diagram della funzione AddGeneralization
Aggiunta delle relazioni (addRelation)
Lo schema finora composto è rappresentato soltanto da entità indipendenti, il cui
unico rapporto può essere una generalizzazione.
Nel passo corrente si cerca di aumentare l’informazione inserendo le relazioni tra
gli elementi presenti. Come descritto nella metodologia PAL, la conoscenza dei
primi passi deriva interamente dallo studio sulla parte centrale della Pubblica
Amministrazione; dunque si analizza la tabella delle relazioni tra le entità PAC al
fine di collegare le entità presenti nello schema concettuale PAL.
La funzione segue la seguente regola:
O una relazione PAC viene inserita unicamente se entrambe le entità
coinvolte sono presenti nello schema PAL.
La ricerca delle relazioni da inserire nello schema è eseguita molto rapidamente
dalla seguente query SQL.
SELECT RelazioniPAC.*
FROM RelazioniPAC
WHERE
63

64. RelazioniPAC.entityFrom
in
(SELECT
EntitàSchemaPAL.nome
FROM
EntitàSchemaPAL.nome
FROM
EntitàSchemaPAL)
and
RelazioniPAC.entityTo
in
(SELECT
EntitàSchemaPAL) ;
Ogni relazione trovata, viene stampata in output sottoforma di stringa testuale,
come nell’esempio seguente.
entitàA.verboDiRelazione.entitàB
A
causa
della
semplicità
del
passo
funzionale
viene
tralasciata
la
rappresentazione del diagramma delle attività.
Aggiunta degli attributi (addAttrib)
Il passo corrente aggiunge gli attributi significativi alle entità nello schema. Come
specificato in precedenza, si definisce attributo significativo un campo di una
tabella pescato nel primo passo della metodologia in assonanza con un criterio
like.
In tale occasione, gli elementi estratti dalla conoscenza PAL, sono stati archiviati
in una tabella di servizio al fine di favorire il passo in questione.
Nessuna query di filtraggio è infatti necessaria, l’unica operazione eseguita è la
visita della tabella temporanea per la scrittura in output degli attributi di ogni
entità.
Il diagramma delle attività proposto di seguito mostra l’operazione di stampa su
file di testo delle entità con i relativi attributi.
64

65. * Per ogni Entità diversa presente nella Tabella Temporanea
Leggi l'Entità dalla
Tabella Temporanea
Leggi i nomi dei campi
abbinati all'Entità
Stampa su file di
testo del nome
dell'Entità seguita da i
nomi dei campi
Figura 34. Activity Diagram della funzione AddAttrib
Aggiunta dei vincoli di integrità referenziale (inferConstr)
Come descritto in precedenza, il passo di aggiunta dei vincoli è strettamente
legato al contesto della Pubblica Amministrazione Locale, in quanto si amplia la
consistenza dello schema concettuale solo con elementi legati al dominio
territoriale di competenza.
A causa dell’infattibilità di possedere in tempi brevi la lista dei vincoli tra tabelle
all’interno di ogni database PAL, il passo corrente è da considerarsi facoltativo;
nel seguito verranno mostrate le attività svolte dalla funzione che implementa il
passo logico della metodologia.
Il passo corrente cerca di relazionare elementi dello schema espandendo il
lavoro fatto dall’addRelationships con della conoscenza specifica della base dati.
Analizzando la lista di vincoli inferenziali tra le tabelle del database in
considerazione, si risale alle entità abbinate alle tabelle e si prendono in
considerazione solo i casi in cui sia presente almeno una entità nella coppia
relazionata. È di fondamentale supporto l’utilizzo della tabella temporanea,
prodotta nel primo punto della metodologia, nella quale sono contenuti gli
abbinamenti entità-tabelle.
Con descritto nella metodologia, il passo è stato implementativamente
decomposto in 3 blocchi sequenziali:
65

66. 1. Si effettua la ricerca delle relazioni tra coppie di tabelle, entrambe
abbinate ad entità dello schema concettuale.
SELECT
TabellaTemporanea. Entità as EntitàFrom, VincoliDB.verbo as Verbo,
CopiaDiTabellaTemporanea.Entità as EntitàTo
FROM
(VincoliDB inner join TabellaTemporanea on VincoliDB.tableFrom=
TabellaTemporanea.tavola) inner join (select * from
TabellaTemporanea) as CopiaDiTabellaTemporanea on
VincoliDB.tableTo = CopiaDiTabellaTemporanea.tavola
GROUP BY
TabellaTemporanea.Entità, VincoliDB.verbo,
CopiaDiTabellaTemporanea.Entità;
2. Si effettua la ricerca delle relazioni tra coppie di tabelle, in cui la prima è
abbinata ad una entità e la seconda è considerata tabella esterna.
SELECT *
FROM (
SELECT
TabellaTemporanea.Entità AS EntitàFrom, VincoliDB.tableFrom
as TabellaFrom, VincoliDB.verbo AS Verbo,
CopiaDiTabellaTemporanea.Entità AS EntitàTo,
VincoliDB.tableTo as TabellaTo
FROM
(VincoliDB inner join TabellaTemporanea ON
VincoliDB.TableFrom = TabellaTemporanea.Tavola) left JOIN
(select * from TabellaTemporanea) AS
CopiaDiTabellaTemporanea ON VincoliDB.TableTo =
CopiaDiTabellaTemporanea.Tavola
GROUP BY
TabellaTemporanea.Entità, VincoliDB.tableFrom,
VincoliDB.verbo, CopiaDiTabellaTemporanea.Gerarchia,
VincoliDB.tableTo
) WHERE
TabellaFrom is null;
66

67. 3. Si inverte il passo precedente, ricercando le relazioni tra tabelle in cui la
prima è considerata tabella esterna e la seconda è abbinata ad una entità.
SELECT *
FROM (
SELECT
TabellaTemporanea.Entità AS EntitàFrom, VincoliDB.tableFrom
as TabellaFrom, VincoliDB.verbo AS Verbo,
CopiaDiTabellaTemporanea.Entità AS EntitàTo,
VincoliDB.tableTo as TabellaTo
FROM
(VincoliDB left join TabellaTemporanea ON
VincoliDB.TableFrom = TabellaTemporanea.Tavola) inner JOIN
(select * from TabellaTemporanea) AS
CopiaDiTabellaTemporanea ON VincoliDB.TableTo =
CopiaDiTabellaTemporanea.Tavola
GROUP BY
TabellaTemporanea.Entità, VincoliDB.tableFrom,
VincoliDB.verbo, CopiaDiTabellaTemporanea.Gerarchia,
VincoliDB.tableTo
) WHERE
TabellaFrom is null;
Per ognuna delle tre precedenti fasi si stampa su file di testo la lista delle
referenze tra elementi; per mostrare se l’elemento è una entità o una tabella
viene introdotta una lettera accanto al nome dell’elemento.
Il file di testo conterrà perciò righe del seguente tipo:
EntitàFrom.E-referenzia-E.EntitàTo
EntitàFrom.E-referenzia-T.TabellaTo
TabellaFrom.T-referenzia-E.EntitàTo
Il diagramma delle attività riunisce le operazioni svolte nella funzione corrente.
67

68. Tenta di aprire il file Excel
con le referenze tra tabelle
del DB
Fallimento
Successo
Cerca referenze
Entità-Entità con la Query
apposita
Cerca referenze
Entità-Tabelle con la
Query apposita
Cerca referenze
Tabelle-Entità con la
Query apposita
Scrive su file di testo
le refenze trovate
Scrive su file di testo
le refenze trovate
Scrive su file di testo
le refenze trovate
Scrive su file di testo
le Tabelle Esterne
Scrive su file di testo
le Tabelle Esterne
Figura 35. Activity Diagram della funzione InferConstraints
Integrazione e astrazione (integraAstrai)
Come descritto nella metodologia implementativa PAL, la funzione corrente
ricerca le somiglianze tra gli schemi in input per produrre uno schema output
formato soltanto da concetti fondamentali.
A causa della natura della rappresentazione degli schemi concettuali sono
necessarie una serie di sottofunzioni che svolgono il processo di integrazioneastrazione sulla parte a loro assegnata.
La funzione corrente si avvantaggia dell’utilizzo di 4 sottofunzioni specifiche e
richiama 2 funzioni utilizzate nella riconcettualizzazione.
o Integrazione e astrazione delle entità
Questa sottofunzione analizza i file di testo degli schemi concettuali in
input, contenenti i nomi delle entità presenti in ciascun schema.
Tutti i nomi delle entità, raccolti per ogni file di testo, vengono memorizzati
in una lista (ListaEntità) e raggruppate per nome.
Vengono poi selezionate solo quelle che sono presenti almeno 2 volte.
Segue il testo della query SQL utilizzata a tale scopo.
68

69. SELECT
*
FROM
(
SELECT
Entità, count(Entità) as NumeroDiOccorrenze
FROM
ListaEntità
GROUP BY
Enità
) as EntitàConOccorrenze
WHERE
EntitàConOccorrenze.NumeroDiOccorrenze >1;
o Aggiunta delle gerarchie
Acquisendo in input la lista delle entità fondamentali dal passo
precedente, si completano le generalizzazioni riutilizzando la funzione
base.
o Aggiunta delle relazioni
Anche in questo caso, non è necessario creare una sottofunzione
specifica, si riutilizza la funzione base per la definizione di relazioni sulle
entità fondamentali.
o Integrazione e astrazione degli attributi
L’esportazione degli attributi fondamentali deve avvenire in conseguenza
del passo di integrazione-astrazione delle entità; gli attributi che devono
essere esportati, infatti, possono essere solo quelli associati ad entità che
sono presenti nel nuovo schema concettuale.
La scelta di questi elementi segue sempre la filosofia nel considerare
fondamentali, solo gli attributi presenti in almeno due schemi riferiti alla
stessa entità.
L’operazione di selezione avviene mediante la seguente query SQL.
69

70. SELECT
*
FROM
(
SELECT
Entità, Campo, CampoDescrizione, count(Campo) as
NumeroDiOccorrenze
FROM
ListaAttributi inner join ListaEntità on
ListaAttributi.Entità like ListaEntità.Entità
GROUP BY
Entità, Campo, CampoDescrizione
) as AttributiConOccorrenze
Where
AttributiConOccorrenze.NumeroDiOccorrenze >1
o Integrazione e astrazione delle tabelle esterne
La sottofunzione corrente ha un aspetto molto simile a quella utilizzata per
l’integrazione-astrazione delle entità, tanto da utilizzare parti di istruzioni e
lo scopo perseguito viene favorito da una query SQL modificata
all’occorrenza.
L’operazione compiuta consiste nell’inserire tutte le tabelle esterne, di ogni
schema in input, in una tabella unica chiamata ListaTabelleEsterne e
selezionare solo quelle che compaiono in un numero superiore a 1.
SELECT
*
FROM
(
SELECT
Tabella, count(Tabella) as NumeroDiOccorrenze
FROM
ListaTabelleEsterne
GROUP BY
Tabella
) as TabelleConOccorrenze
WHERE
70

71. TabelleConOccorrenze.NumeroDiOccorrenze >1;
o Integrazione e astrazione dei vincoli di integrità referenziale
Come nel passo di aggiunta dei vincoli di inferenza nella metodologia per
la riconcettualizzione, anche nel corrispondente passo per l’integrazioneastrazione sono presenti le simili complicazioni implementative.
Il processo viene suddiviso in tre parti e vengono esportate solo le
referenze tra elementi (entità e tabelle esterne) già presenti nello schema
concettuale, esportati nei passi precedenti.
Il problema di maggior rilievo è stato poter selezionare le referenze comuni
in una query SQL; non sempre la coppia di elementi è presente con lo
stesso ordine, è possibile infatti trovare casi come il seguente:
EntitàA.relaziona.TabellaB
TabellaB.relaziona.EntitàA
La referenza descritta è la medesima, ma senza nessun intervento
modificativo non è possibile associare le due relazioni in una query SQL.
La soluzione scelta ha introdotto una fase di preprocessing, in cui la lista
delle referenze, comprensiva di tutte quelle degli schemi in input, viene
ordinata in modo che l’elemento From (a sinistra) sia minore dell’elemento
To (a destra); è ovvio che la comparazione avviene su confronto di
rappresentazione numerica dei caratteri.
Terminata tale interfase si svolge una selezione delle referenze comuni ad
almeno due schemi in input.
A seguito della descrizione delle sottofasi di integrazione-astrazione è possibile
rappresentare la funzione padre mediante un diagramma delle attività.
71

72. Legge gli schemi
concettuali in input
IntegraAstrai Entità
Scrive le Entità su file di testo
Ricrea Gerarchie delle
Entità trovate
Scrive le Gerarche su file di testo
Inserisci le Relazioni
tra le Entità trovate
Scrive le Relazioni su file di testo
IntegraAstrai Attributi
Scrive gli Attributi su file di testo
IntegraAstrai Tabelle
Esterne
Scrive le Tabelle Esterne su file di testo
IntegraAstrai Vincoli
Scrive i Vincoli su file di testo
Figura 36. Activity Diagram della funzione Integra-Astrai
Assemblaggio delle componenti
Terminata
la
fase
di
implementazione
della
funzioni
base
per
la
riconcettualizzazione e per l’integrazione-astrazione, è stato possibile progettare
ed implementare funzioni di alto livello di più facile utilizzo, che richiamano le
funzioni base in una corretta sequenza logica.
Il tool è stato suddiviso in tre macroaree, abbinate a possibile funzioni utente.
o Riconcettualizzazione di uno schema logico di un database
o Integrazione-astrazione di schemi
o Creazione di un repository
Come è facile notare, le aree crescono linearmente di complessità richiamano
concetti dell’area precedente.
72

73. Figura 37. Screenshot della finestra principale del tool.
Riconcettualizzazione di uno schema logico
L’utente ha modo di poter scegliere un database da una lista elencante tutti gli
archivi di cui si è fornito uno schema logico, come descritto nella metodologia.
Il processo richiama in sequenza le 5 funzioni base per la creazione di uno
schema concettuale, mostrando per ognuna l’output prodotto.
Figura 38. Screenshot della finestra di Riconcettualizzazione
73

74. Integrazione e astrazione di Schemi
In quest’area è possibile richiamare schemi concettuali di base, prodotti nell’area
precedente, oppure schemi concettuali astratti ed avviare il processo di
creazione di uno schema concettuale astratto di output che richiama la funzione
di integrazione-astrazione di schemi.
Figura 39. Screenshot della finestra di integrazione-astrazione di Schemi Concettuali
Creazione di un repository
Nell’area di maggior rilievo, su cui si fonda principalmente la presente tesi, è data
capacità all’utente di selezionare uno schema piramidale rappresentante un
repository ed avviare il processo di creazione.
Tale operazione sfrutta massimamente il riuso del codice richiamando le funzioni
di riconcettualizzazione di uno schema logico e di integrazione-astrazione di
schemi concettuali.
74

75. Per l’analisi dell’albero del repository si è scelto di utilizzare una visita dell’albero
di tipo deapth-first post-order, raggiungendo direttamente i database alle base
della piramide e risalendo verso la radice integrando e astraendo.
Lo schema grafico del Repository che viene incrementalmente rappresentato può
essere esportato in formato xml e permette l’interazione con l’utente favorendo
l’analisi di ogni nodo.
Cliccando su un elemento del repository è possibile osservare lo schema
concettuale mediante un applicativo esterno (ERwin) che ne disegna la struttura.
Tale interoperabilità è stata resa possibile sviluppando una funzione che riunisce
gli output testuali rappresentativi di uno schema concettuale in un file SQL,
importabile in svariati tool di visualizzazione.
Figura 40. Screenshot della finestra di costruzione del Repository
75

76. Figura 41. Screenshot di uno schema grafico di uno Schema Concettuale rappresentato grazie
all’interoperabilità con il tool ERwin
Testing
A seguito della scelta della tipologia di sviluppo di tipo incrementale, il
programma è stato testato nel corso di ogni fase della sua crescita
implementativa. Durante ogni incontro in sede a Torino è stato analizzato
l’operato settimanale, verificando la corretta implementazione delle scelte
discusse negli incontri antecedenti e comprovando la qualità del prodotto in fase
intermedia.
Alla completa terminazione del tool è stato eseguito un alpha test completo su
tutte le funzionalità messe a disposizione agli utenti, annotando i commenti e le
migliorie eventualmente necessarie.
Tali suggerimenti sono stati in parte soddisfatti nella versione definitiva e in parte
sono stati classificati per le versioni future.
76

77. Un test fondamentale a cui si è sottoposto il tool è la compatibilità con alcune
versioni di sistemi Windows.
Sui computer in sede è installata la versione 2000 del sistema Microsoft
Windows, mentre l’autore ha eseguito le fasi di implementazione su una
macchina con sistema Microsoft Windows XP.
A seguito di tale contesto implementativo è stato necessario un porting del tool
su piattaforma 2000, con conseguente rifacimento delle operazioni di test.
L’operazione di porting ha implicato una fase di compilazione e di creazione di
pacchetti di installazione specifici per il sistema destinatario.
Evoluzioni
A seguito dell’interesse suscitato dalla realizzazione del programma sono state
pianificate delle operazioni di miglioramento con lo scopo di innalzare la qualità
del prodotto finale.
Il perfezionamento si sviluppa su due strade parallele: la puntualità dei contenuti
di uno schema concettuale e la migliore rappresentazione dello stesso.
Nuove funzionalità
Il tool segue una metodologia approssimativa, favorendo maggiormente la
concretezza di un prodotto finito e usabile piuttosto che la qualità dei risultati
prodotti.
A conclusione del periodo di stage, è ora possibile rivedere gli algoritmi utilizzati
e avvicinarli alla metodologia originale con un margine di tempo diverso e con
una esperienza già maturata.
Il lavoro non è di semplice fattura, in quanto è necessario ripercorrere le fasi di
progettazione e pianificare un codice che implementi una metodologia
77

78. relativamente complessa. In questo contesto, il punto cruciale è la manipolazione
di schemi ER che necessita di particolari tecniche di rappresentazione e
gestione.
Le migliorie implementative influiscono sui meccanismi di riconcettualizzazione,
dove si rinnovano le tecniche di estrazione delle entità, abbinate agli attributi, e di
generalizzazione. Secondariamente, con tali evoluzioni, si migliora altresì
l’integrazione-astrazione implementando i concetti di creazione degli schemi
astratti come descritto nella metodologia originale PAL.
Nuovi formati per gli schemi grafici e per la rappresentazione interna
Come descritto precedentemente, la rappresentazione non ottimale degli schemi
concettuali può favorire la bassa qualità degli algoritmi scelti. Un punto dunque
basilare di un piano evolutivo del tool è sicuramente la definizione di uno
standard per la rappresentazione degli schemi concettuali.
Un’idea concreta per il miglioramento consiste nel cessare l’utilizzo della forma di
rappresentazione di uno schema concettuale mediante file di testo, sostituendola
con strutture tabellari, in modo da memorizzare i dati provenienti dai passi di
riconcettualizzazione e integrazione-astrazione
La proposta prevedrebbe l’utilizzo di un database altamente normalizzato,
composto da tabelle semplici, correlate tra loro, in grado di contenere tutte le
informazione riguardanti le entità (con gli attributi), le gerarchie e le relazioni
presenti in ogni schema concettuale.
Tale scelta favorirebbe sia i meccanismi di riconcettualizzazione, sia quelli di
integrazione e astrazione.
78