Analisi di Metriche e Algoritmi per la Qualit`a dei Dati. Progettazione

UNIVERSITÀ DEGLI STUDI DI MILANO - BICOCCA
Dipartimento di Informatica Sistemistica e Comunicazione
Facoltà di Scienze Matematiche, Fisiche e Naturali
Corso di Laurea in Informatica
Analisi di Metriche e Algoritmi
per la Qualità dei Dati.
Progettazione e Realizzazione di un Framework
per l’Assessment della Qualità.
Supervisori:
Chiar.mo Prof. Carlo BATINI
Dott. Daniele BARONE
Relazione della prova finale di:
Carmine Carella
Matricola: 055465
Anno Accademico 2005-2006
Ai miei genitori
e alle mie sorelle Brunilde e Milena.
A Danilo, Maurizio e Marzio,
compagni di avventura di questi ultimi tre anni.
Ai miei cari ed eterni amici materani
Vittorio, Giuseppe, Angelo e Giuseppe.
A Valeria, per il suo aiuto e
per ogni momento condiviso con me.
Un ringraziamento particolare al Prof. Batini per avermi dato questa
opportunitá, al Dott. Barone per avermi pazientemente seguito ed aiutato
in questi mesi di stage.
Indice
1 Introduzione
1.1 L’importanza della Qualità dei Dati . . . . . . . . . . . . . .
1.2 Definizione di dato e sue proprietà . . . . . . . . . . . . . . .
1.3 Valutazione Quantitativa di Dato . . . . . . . . . . . . . . . .
5
5
8
9
2 Qualità dei Dati e Dimensione
2.1 Il Concetto di Qualità dei Dati . . . . . . . . .
2.2 Tipi di Dati . . . . . . . . . . . . . . . . . . . .
2.3 Il Concetto di Dimensione . . . . . . . . . . . .
2.3.1 Qualità nel Modello Concettuale . . . .
2.3.2 Qualità nella Rappresentazione dei Dati
2.3.3 Qualità dei Valori dei Dati . . . . . . .
2.4 TradeOffs tra Dimensioni . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
13
15
16
16
20
21
26
3 Analisi delle Metriche
3.1 Tabella Dimensioni - Metriche - Algoritmi .
3.2 Dimensioni della Qualità dei Dati: Metriche
3.2.1 Syntactic Accuracy . . . . . . . . . .
3.2.2 Semantic Accuracy . . . . . . . . . .
3.2.3 Duplication . . . . . . . . . . . . . .
3.2.4 Completeness . . . . . . . . . . . . .
3.2.5 Currency . . . . . . . . . . . . . . .
3.2.6 Volatility . . . . . . . . . . . . . . .
3.2.7 Timeliness . . . . . . . . . . . . . . .
3.2.8 Consistency . . . . . . . . . . . . . .
3.2.9 Concise Representation . . . . . . .
3.2.10 Relevancy . . . . . . . . . . . . . . .
3.2.11 Ease of manipulation . . . . . . . . .
3.2.12 Believability . . . . . . . . . . . . . .
3.2.13 Appropriate amount of data . . . . .
3.2.14 Accessibility . . . . . . . . . . . . . .
3.2.15 Objectivity . . . . . . . . . . . . . .
3.2.16 Reputation . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
27
29
30
32
34
35
36
37
39
39
40
41
41
41
42
42
43
43
44
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
INDICE
3.2.17
3.2.18
3.2.19
3.2.20
Security . . . . . . . . .
Ease of Understanding .
Variety of Data Sources
Usefulness . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
44
44
45
45
4 Realizzazione del Framework
4.1 Obiettivi . . . . . . . . . . . . . . . . . . . . . .
4.2 Strumenti Utilizzati . . . . . . . . . . . . . . .
4.3 Funzioni e Struttura . . . . . . . . . . . . . . .
4.3.1 Funzioni . . . . . . . . . . . . . . . . . .
4.3.2 Struttura . . . . . . . . . . . . . . . . .
4.4 Analisi Metriche Implementate nel Framework
4.4.1 Completezza . . . . . . . . . . . . . . .
4.4.2 Accuratezza Sintattica . . . . . . . . . .
4.4.3 Currency . . . . . . . . . . . . . . . . .
4.4.4 Consistenza . . . . . . . . . . . . . . . .
4.5 Localizzazione e Correzione di Errori . . . . . .
4.5.1 Il Framework: Attività di Localizzazione
.
.
.
.
.
.
.
.
.
.
.
e
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
Correzione
46
46
46
47
47
48
49
50
53
60
63
64
64
5 Caso di Studio
69
5.1 Descrizione del Caso di Studio . . . . . . . . . . . . . . . . . 70
5.2 Analisi dei Risultati . . . . . . . . . . . . . . . . . . . . . . . 71
A Descrizione del Metamodello
A.1 Descrizione dei Dati e Metadati . . . .
A.1.1 Dati-Metadati in Input . . . .
A.1.2 Dati-Metadati in Output . . .
A.2 XML . . . . . . . . . . . . . . . . . . .
A.2.1 Vantaggi Derivanti dall’Utilizzo
A.2.2 Cenni ad XML . . . . . . . . .
A.3 Metamodello del Framework . . . . . .
A.3.1 Metadati Misurazione . . . . .
A.3.2 Metadati Dimensione . . . . .
B Funzioni di Similarità
B.1 Principali Funzioni di Similarità
Bibliografia
. . . . .
. . . . .
. . . . .
. . . . .
di XML
. . . . .
. . . . .
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
79
81
81
82
82
82
83
84
84
86
91
. . . . . . . . . . . . . . . . 91
94
Capitolo 1
Introduzione
1.1
L’importanza della Qualità dei Dati
In molte organizzazioni la situazione del data asset, ovvero del patrimonio
informativo è critica per cause differenti. E’ fuori dubbio che il successo delle
aziende sia sempre più legato alla raccolta e all’ utilizzo di grandi quantità
di informazioni. Le decisioni a tutti i livelli sono guidate inevitabilmente
dai dati acquisiti da un numero sempre maggiore di fonti e fruiti attraverso
svariate tipologie di sistemi (datawarehouse, CRM, ERP) per i quali gli
investimenti rappresentano una quota significativa del budget aziendale.
Questa situazione critica porta a considerare la problematica della qualità dei dati (d’ora in avanti si utilizzerà l’acronimo DQ che indica
Data Quality) nei sistemi informativi.
La scarsa DQ, problema solo in parte percepito come affrontabile e gestibile, determina danni in termini di extra costi, mancati ricavi e demotivazione all’interno dell’azienda. La DQ è un aspetto che pochissime aziende
percepiscono determinante per i loro livelli di servizio, i loro ricavi e i loro
costi. Ai dati normalmente non viene assegnato alcun valore economico;
molte esperienze dimostrano però che una scarsa qualità dei dati ha degli
impatti economici sull’organizzazione.
Molto spesso l’insufficiente DQ viene confusa con un problema di scorretto funzionamento del software che gestisce i dati e molte aziende intervengono acquistando nuovi sistemi software. Il problema però è nei dati
veri e propri, quindi la soluzione potrebbe essere invece quella di definire ed
attuare una strategia di controllo della DQ. Ci si rende conto quando i dati
continuano ad essere inesatti anche con il nuovo sistema sofware.
Ma perchè la DQ è cosi importante? La risposta si può sintetizzare in
due punti essenziali, come detto in [2]:
• La scarsa DQ è pervasiva: Spieghiamo il concetto con un esempio.
Questo esempio tratto da [2] è, pur nella sua banalità, estremamente
significativo sul ruolo che una strategia per il controllo della DQ può
5
CAPITOLO 1. INTRODUZIONE
6
avere in una azienda. Le ripercussioni in termini di costi e di mancati
ricavi generate dalla scarsa attenzione ai dati possono essere veramente
gravi.
Ci rivolgiamo ad un’ agenzia turistica per organizzare un viaggio che
prevede l’utilizzo, una volta arrivati sul luogo di destinazione, di un’auto a noleggio per recarsi dall’aeroporto fino al luogo in cui abbiamo
deciso di trascorrere le nostre vacanze. Arrivati all’aeroporto, ci rechiamo presso lo sportello dell’azienda che deve fornirci l’auto e scopriamo
che la nostra auto non è disponibile e che, come sempre avviene nei
periodi di alta stagione, non ve ne sono altre disponibili prima delle
prossime 48 ore. Il motivo è che la prenotazione dell’auto non risulta
nel database. La persona preposta alla consegna delle auto non sa spiegarsi l’accaduto e telefona all’agenzia che aveva organizzato il viaggio
cercando informazioni sulla nostra prenotazione. Dopo vari minuti di
telefonata, l’agenzia si rende conto che per un errore, la prenotazione
dell’auto non era stata inserita nei dati del viaggio e che, quindi, l’azienda di noleggio auto, non poteva averla ricevuta. A questo punto
si scatena una serie di eventi:
1. Noi telefoniamo irritati all’agenzia.
2. La persona dell’agenzia che risponde è mortificata per l’accaduto
e promette che ci troverà un’altra auto nel giro di un’ora.
3. Inoltre, l’agenzia ci offre di pagare l’auto per scusarsi dello spiacevole accaduto.
4. Nonostante l’auto messa a disposizione gratuitamente, continuiamo ad essere seccati per quanto è successo e non esitiamo a
raccontare il tutto ad amici e conoscenti.
5. Decidiamo di non rivolgerci mai più a quella agenzia di viaggi.
Un banale errore di immissione dati in un database ha quindi determinato per l’agenzia:
1. Lo sconforto dell’impiegato.
2. Il costo da sostenere per pagare l’auto a noleggio che ci è stata
data gratuitamente.
3. La perdita sicura di un cliente.
4. Un numero imprecisato di mancati clienti (i nostri conoscenti
e amici ai quali abbiamo raccontato l’accaduto). Quindi, una
quantità imprecisata di mancati ricavi.
• La scarsa DQ è costosa: Il dato fornito dal Datawarehousing Institute [28] parla di una spesa, negli Stati Uniti, di 600 miliardi di dollari
CAPITOLO 1. INTRODUZIONE
7
all’anno determinata dalla non gestione dei dati. Introdurre in azienda processi di gestione della qualità dei dati viene percepito come un
costo che spesso scoraggia i decisori. Il motivo è che manca la percezione dei costi indotti dalla scarsa qualità dei dati. Molti di tali costi,
infatti, sono in qualche modo nascosti, nel senso che non sempre vengono associati alla insufficiente qualità dei dati: basti pensare al costo
di un depliant pubblicitario che verrà inviato ad un indirizzo inesatto
e che andrà, quindi, inevitabilmente perso. Oppure si pensi al tempo
che il personale addetto ad un Call Center impiega per discutere con
un cliente insoddisfatto. Gli esempi sono molteplici. E poi cosa più
importante, il costo di una decisione per l’azienda presa sulla base di
informazioni errate.
Altri motivi per cui la DQ è importante sono:
• La qualità dei dati degrada con il tempo: Oggi quasi tutti i dati
sono dinamici: indirizzi, numeri di telefono, professioni, indirizzi email, dati di mercato, giacenze di magazzino e cosı̀ via. Questo implica
che bisogna seguire l’alta frequenza di cambiamento per evitare che i
dati diventino obsoleti.
• La qualità dei dati può costituire un forte vantaggio competitivo: La scarsa qualità dei dati, come detto in precedenza, ha degli
impatti sull’economia dell’azienda, in particolare costi aggiuntivi che
hanno delle conseguenze nell’ambito delle decisioni di marketing.
Effetti della scarsa qualità dei dati
Noto che il problema del DQ esiste, abbiamo già detto che i suoi effetti non
sono da sottovalutare. Anche se abbiamo già citato alcune conseguenze che
l’insufficiente DQ può arrecare, riassumiamone le principali:
• Diminuizione della soddisfazione del cliente.
• Sostenimento di costi alti e superflui.
• Influenza sui processi decisionali: Implementare sistemi di data warehouse o data mining su dati di scarsa qualità è molto rischioso.
• Impossibilità di pianificare una strategia a lungo termine.
CAPITOLO 1. INTRODUZIONE
1.2
8
Definizione di dato e sue proprietà
I dati sono un insieme di fatti ovvero rappresentazioni di eventi appartenenti
al mondo reale; sono frutto di misurazioni e sono la materia prima per la
costruzione dell’informazione, infatti costituiscono l’input di un processo che
genera informazioni.
Il mondo reale viene rappresentato con un modello. Il modello è composto da
entità, che rappresentano i concetti equivalenti del mondo reale. Ogni entità
è caratterizzata da attributi. Ogni attributo ha un dominio dei possibili
valori. Si definisce un datum (data item) una tripla < e, a, v > dove v è il
valore selezionato dal dominio dell’attributo a per l’entità e. Data (in lingua
inglese) indica una qualsiasi collezione di data item. Una data rapresentation
è un insieme di regole per registrare le triple su un mezzo fisico. Il data
recording (record) è l’istanza fisica che rappresenta l’insieme di data item
secondo le regole della rappresentazione. I vantaggi di questa definizione
sono nella separazione tra l’attività di modellazione e di rappresentazione.
I dati hanno proprietà particolari che li distinguono dalle altre risorse e che
hanno un impatto sulla definizione di DQ.
Le proprietà sono:
1. Consumability e Depreciability: i dati non si consumano né si usurano.
2. Dipendenza dal Contesto: i dati hanno significato solo in un determinato contesto che è fondamentale per interpretarli e ricavare informazione.
3. Copyability: i dati possono essere copiati in modo economico, a differenza di altre risorse/prodotti per le quali il costo per fare una copia
è paragonabile al costo di produzione di un nuovo prodotto.
4. Costo di Ottenimento e Conservazione: è molto basso.
5. Fungibility: significa che un’unità di risorsa può essere scambiata con
un’altra, esempio i soldi godono di tale proprietà; i dati no.
6. Lag Time: quanto impiegano i dati ad essere trasmessi e rispecchiare
la realtà.
7. Shareability: i dati sono condivisibili.
8. Supply: Un organizzazione può facilmente rifornirsi di dati (a volte ne
hanno anche troppi).
CAPITOLO 1. INTRODUZIONE
1.3
9
Valutazione Quantitativa di Dato
L’analisi della DQ è vincolata all’analisi dei processi in cui i dati vengono
utilizzati; per migliorare la DQ, è necessario analizzare il processo di origine
e individuare le attività che introducono errori o influenzano la DQ. Inoltre
è necessario capire bene cosa significhi DQ e come essa viene valutata. Il
concetto di dato e di informazione sono correlati. Una valutazione quantitativa della qualità per entrambi, dipende dal contesto di utilizzo. Quindi la
DQ dipende dal progetto del sistema informativo e dal contesto di utilizzo.
In letteratura esistono diversi approcci per valutare i concetti di dato e
di informazione in modo quantitativo.
Due approcci per la valutazione quantitativa del concetto di informazione:
1. Il primo basato sulla communication theory di Shannon.
2. Il secondo basato sull’information economics.
Due approcci per la valutazione quantitativa del concetto di dato:
• Data Centric, legato alla struttura progettuale ed implementativa del
sistema informativo e dei database, considera concetti quali entità,
attributo e valore.
• Il secondo considera come il ruolo di un sistema informativo sia quello
di fornire una rappresentazione di un dominio applicativo (il sistema
mondo reale, Real World System) cosi come percepita dall’utente. Le
deficienze nella qualità sono dovute allora alla difformità tra la vista
del real world system che può essere inferita dal sistema informativo
che lo rappresenta e la vista che può essere ottenuta dall’osservazione
diretta.
Di seguito, viene proposto un modello astratto del ciclo di vita dei dati
per mettere in evidenza le attività che hanno maggiore impatto sui dati,
perchè come si è detto precedentemente per misurare e migliorare la DQ è
necessario agire sui processi o per dir meglio sulle attività di tali processi. Il
modello considera come attività centrale la memorizzazione dei dati ( Data
Storage ) e i sistemi vengono classificati in base al ruolo ricoperto da questa
attività.
Tre tipologie di sistemi:
1. Sistema d’Acquisizione. La Data Storage è l’obiettivo finale del sistema.
2. Sistema d’Utilizzazione. Il sistema accede a dati memorizzati precedentemente da qualche altro sistema.
3. Sistema Combinato. Il sistema memorizza ed utilizza i dati. Esistono
due sottocategorie:
CAPITOLO 1. INTRODUZIONE
10
Figura 1.1: Cause della scarsa DQ: mondo reale vs. sistema informativo
(a) Il sistema rigido (Store And Forward): in cui la fase di acquisizione e quella di utilizzo si devono obbligatoriamente alternare.
(b) Il sistema flessibile: in cui le due fasi possono susseguirsi senza rispettare pattern prestabiliti; i moderni sistemi informativi basati
su DBMS sono flessibili.
Le attività che manipolano i dati sono ripetitive quindi è preferibile parlare di cicli di acquisizione ed utilizzazione; i sistemi reali sono una combinazione di questi cicli. Le principali attività incluse nel ciclo di acquisizione
sono le seguenti:
• Definire la view dei dati: una view è composta dalle parti del mondo
reale che devono essere memorizzate. Devono essere specificate una o
più entità con gli attributi relativi.
• Implementazione: dopo aver definito gli elementi che devono essere
memorizzati, si devono tenere conto restrizioni e/o limitazioni imposte
dal mezzo di memorizzazione e dal DBMS. Viene definito lo schema
dei dati.
• Ottenere i valori: si acquisiscono i valori degli attributi delle singole
istanze delle entità definite.
CAPITOLO 1. INTRODUZIONE
11
Figura 1.2: Tipologie di sistemi
• Aggiornare record: i dati sono memorizzati in uno o più database. Il termine aggiornare include l’inserimento di un nuovo record,
cancellazione e modifica dei record esistenti.
Le principali attività incluse nel ciclo di utilizzo sono le seguenti:
• Definire una subview: tipicamente un processo di utilizzo userà solo
una piccola parte dei dati disponibili. Si definisce il sottoinsieme di
dati da utilizzare.
• Recupero: i dati precedente memorizzati vengono recuperati.
• Manipolazione: i dati recuperati vengono utilizzati come input in
un processo di trasformazione che deve generare come output i dati
soddisfacenti la richiesta di un utente.
• Presentazione risultati: i risultati devono essere presentati all’utente
finale con una rappresentazione appropriata che dipende da molti fattori: la natura del risultato, il mezzo di visualizzazione, e le preferenze
dell’utente.
• Utilizzo dei dati: l’utilizzatore del dato potrà giudicare la qualità dello
stesso.
Per migliorare la DQ bisogna però inserire le seguenti attività:
CAPITOLO 1. INTRODUZIONE
12
• Valutazione (Assessment): in questa fase si valuta la qualità dei dati
ottenuti. E’ necessario valutare le dimensioni legate ai valori dei dati:
consistenza, accuratezza, currency, e completezza che verranno approfondite nel capitolo successivo. Se i dati sono di qualità accettabile
sono memorizzati, altrimenti sono intraprese attività di miglioramento
della DQ.
• Analisi: in questa fase vengono individuate le ragioni della bassa
qualità dei dati riscontrata nella fase di valutazione.
• Correzione: in molti casi, i dati insoddisfacenti possono essere corretti
o migliorati.
• Scarto: se un dato giudicato di bassa qualità non può essere corretto,
dovrebbe essere scartato.
Da quanto esposto precedentemente si nota che la gestione della DQ è una
parte molto importante del processo di creazione e utilizzo dei dati; la qualità dei dati viene analizzata e l’analisi va condotta tramite quattro fasi:
definizione delle dimensioni di qualità, analisi dei dati, misurazione delle
dimensioni di qualità, miglioramento della qualità dei dati. Un concetto
fondamentale della DQ è quello di dimensione, che vedremo meglio nel capitolo 2. Un metodo standard, per esempio, per l’analisi delle dimensioni di
qualità è l’IP-MAP (Information Product Map) [11] e [12], un meccanismo
di data tracking, un modello grafico progettato per aiutare a comprendere, valutare e descrivere il modo in cui un’informazione viene assemblata.
IPMAP consente di visualizzare le fasi più importanti della lavorazione di
un prodotto informativo e di identificarne i percorsi critici in relazione alla
qualità. Sulla base di tale identificazione, azioni di miglioramento possono essere intraprese. Consente di identificare le unità informative (business
unit) e i limiti del sistema informativo/informatico (system boundaries). E’
basato su una notazione grafica, sulla considerazione di dato come prodotto,
sull’analisi dei processi e su passi metodologici. La costruzione e l’utilizzo
di IP-MAP si compone di cinque fasi:
• Catalogare i prodotti informativi.
• Identificare i prodotti informativi critici.
• Definire i requisiti di qualità per i prodotti informativi critici.
• Costruire l’IP-map e il repository di metadati.
• Valutare e migliorare la qualità del prodotto informativo.
Capitolo 2
Qualità dei Dati e
Dimensione
Abbiamo già parlato dell’importanza della DQ, delle cause e delle conseguenze di una scarsa qualità dei dati. In questo capitolo vedremo cosa significa
Data Quality e definiremo il concetto di dimensione, presentandone alcune
tra le più importanti.
2.1
Il Concetto di Qualità dei Dati
La Data Quality è un tema di ricerca in molti domini applicativi come
statistica, management e informatica. Nel 1960, gli statistici sono stati
i primi ad interessarsi ad alcuni problemi di DQ, proponendo una teoria
matematica per studiare la duplicazione dei dati statistici [3]. Negli anni 80
i primi passi furono mossi nel campo del management e poi solo agli inizi
degli anni 90 gli informatici iniziarono a considerare il problema di definire,
misurare e migliorare la qualità dei dati digitali, memorizzati nei database
e nei data warehouse. Nella DQ vengono affrontati diversi aspetti, illustrati
in figura 2.1, essi sono:
Le Dimensioni, la scelta di esse per misurare il livello di DQ è l’inizio
di ogni attività relativa alla DQ. Le dimensioni sono applicate in modo
differente in base al modello, alle tecniche, tools e frameworks.
I Modelli sono utilizzati nei database per rappresentare i dati e gli schemi
dei dati.
Le Tecniche corrispondono agli algoritmi, euristiche, conoscenze che
forniscono una soluzione allo specifico problema di DQ.
Le tecniche necessitano del supporto di tools, come ad esempio procedure automatizzate con interfacce grafiche che sollevano l’utente dal compito
di eseguire manualmente alcune tecniche. Quando un insieme di tools coordinati sono integrati per fornire un insieme di servizi di DQ, utiliziamo il
termine Frameworks.
13
CAPITOLO 2. QUALITÀ DEI DATI E DIMENSIONE
14
Infine, le Metodologie forniscono linee guida per la scelta, partendo da
tecniche e tools disponibili, dei processi di misurazione e miglioramento più
efficienti per uno specifico sistema informativo.
Figura 2.1: Principali aree di ricerca in DQ
E’ molto difficile dare una definizione di DQ, è un concetto molto complesso. Una prima, ma non completa definizione è quella che deriva dalla
constatazione che un qualsiasi database non è altro che una rappresentazione
di un qualche aspetto del mondo reale. In altre parole, un database modella
una realtà; il problema è fare in modo che la modellazione risulti, nel tempo,
il più fedele possibile. Quindi la DQ potrebbe essere considerata il livello di
rispondenza delle basi informative alle realtà modellate. Quando si pensa al
concetto di DQ, molto spesso si associa essa alla definizione di accuratezza
dei dati. Il fatto di associare la DQ ad una sola delle dimensioni di qualità,
l’accuratezza, è piuttosto normale visto che tale dimensione è quella che più
si avvicina alla definizione di qualità, nella sua accezione più generale. Ma
la DQ è più di un semplice problema di accuratezza. Per definire cos’è la
DQ non si può non considerare il concetto di dimensione di qualità, ma è
proprio questo concetto che caratterizza la definizione di DQ. Altre dimensioni oltre all’accuratezza, sono la completezza, la currency e la consistenza.
Introduciamole con un esempio, nei paragrafi successivi verranno definite
più precisamente. Consideriamo la relazione in tabella 2.1:
Dalla relazione, è possibile notare problemi di accuratezza: il title del movie
3 è Rman invece di Roman, Director del movie 1 e movie 2 sono scambiati
(Curtiz è director del movie 1 e Weir del movie 2). Problemi di completezza:
15
CAPITOLO 2. QUALITÀ DEI DATI E DIMENSIONE
ID
1
2
3
4
Title
Casablanca
Dead Poets Society
Rman Holiday
Sabrina
Director
Weir
Curtiz
Wylder
NULL
Year
1942
1989
1953
1964
#Remakes
3
0
0
0
LastRemakeYear
1940
NULL
NULL
1985
Tabella 2.1: Una relazione Movies con problemi di data quality
un valore mancante del director del movie 4 e un valore zero per l’attributo
#Remake sempre del movie 4. Considerando sempre il movie 4, vediamo
che un remake è stato fatto nel 1985, quindi il valore zero di #Remakes può
essere considerato un problema di currency, il remake non è stato ancora
registrato nel database. Infine, due problemi di consistenza: il primo per il
movie 1 dove il valore di LastRemakeYear non può essere minore di Year ; il
secondo per il movie 4 dove il valore di LastRemakeYear e #Remakes sono
inconsistenti, o #Remakes non è zero o LastRemakeYear è NULL.
Dall’esempio sopra riportato, è possibile dedurre che la Data Quality è un
concetto complesso e multi-dimensionale, alla propria definizione concorrono
differenti dimensioni di qualità. Le quattro dimensioni finora esposte sono
solo alcune di un grande insieme di dimensioni presente nella letteratura,
sono le più importanti ma ne esistono altre che si differenziano in base alla
struttura del dato (strutturato, semistrutturato, non strutturato) e al modo
di misurarle (misura qualitativa o quantitativa).
2.2
Tipi di Dati
L’esempio visto precedentemente, riguardava problemi di DQ di un tabella
relazionale, di un singolo database, ma la DQ si differenzia in base al tipo di
dato e sistema informativo presi in considerazione. Come detto nel capitolo
1, i dati sono rappresentazioni del mondo reale, in un formato che può essere
memorizzato, letto, elaborato da un software e comunicato tramite una rete.
Esistono, in letteratura, diverse proposte di classificazione dei dati, ma
prendiamo in considerazione quella che classifica i dati in base alla loro
struttura, esistono tre tipi di dati:
1. Strutturati: i dati strutturati sono quelli distinti in parti elementari, e
ciascuna di loro è rappresentata con un formato che può essere descritto da una grammatica. Le tabelle relazionali sono i dati strutturati
per eccellenza.
2. Semi strutturati: sono quei dati la cui struttura ha qualche grado di
flessibilità. XML è un linguaggio di markup utilizzato per rappresentare dati semi-strutturati. Questi dati non hanno una definizione
formale, ma alcune caratteristiche:
CAPITOLO 2. QUALITÀ DEI DATI E DIMENSIONE
16
(a) i dati possono avere campi non predefiniti in fase di progetto, ad
esempio, quando un file XML non ha uno schema XML o DTD
associato.
(b) lo stesso tipo di dato può essere rappresentato in modi diversi,
basti pensare al formato che una data può assumere e in quanti
modi può essere rappresentata.
3. Non strutturati: quando i dati sono espressi in linguaggio naturale
e non hanno una struttura specifica o un dominio di possibili valori
associato.
2.3
Il Concetto di Dimensione
Abbiamo parlato finora della DQ, accennando solo al concetto di dimensione.
Inoltre, abbiamo visto che le dimensioni concorrono alla definizione di DQ.
Approfondiamo in questo paragrafo il concetto di DQ, dal punto di vista
delle molte dimensioni ad essa associate.
Una Dimensione non è altro che un punto di vista da cui osservare e
valutare la qualità dei dati. Cattura uno specifico aspetto della DQ.
Le Dimensioni sono definite in modo qualitativo e le definizioni stesse
non forniscono alcun elemento per assegnare valori alle dimensioni, ovvero
misure quantitative, quindi una o più metriche devono essere associate alle
dimensioni come proprietà separate. Per ciascuna metrica, devono essere
forniti uno o più metodi di misura (o frameworks), costituiti da:
1. definizione della fonte su cui si fa la misura.
2. quali dati sono coinvolti.
3. strumento di misura.
4. la scala utilizzata per riportare il risultato.
Le dimensioni di qualità possono riferirsi allo schema o modello concettuale, alla rappresentazione dei dati e ai valori dei dati. Per ogni categoria
esiste un insieme di dimensioni, ce ne sono diversi ma presentiamo quello
tratto da [2] e mostrato in tabella 2.2.
2.3.1
Qualità nel Modello Concettuale
La qualità del modello concettuale è importante nella fase di progettazione
di un database, infatti sono un risultato della prima fase dello sviluppo di un
sistema informativo e errori concettuali nello schema hanno un forte impatto
sullo processo di sviluppo del sistema. Nel modello concettuale la qualità
è essenziale in quanto il modello rappresenta la porzione di mondo reale
catturata, e quindi è il contesto all’interno del quale valutare l’utilità del
CAPITOLO 2. QUALITÀ DEI DATI E DIMENSIONE
Categoria
Modello Concettuale
Rappresentazione dati
Valore dei dati
17
Dimensioni
Contenuto
Composizione
Copertura
Consistenza
Livello di dettaglio
Reazione al cambiamento
Appropriatezza
Flessibilità del formato
Interpretabilità
Abilità rappr. valori nulli
Portabilità
Uso efficiente memoria
Precisione del formato
Accuratezza
Currency
Completezza
Consistenza
Tabella 2.2: Insieme di Dimensioni e Categorie
dato. Le dimensioni legate al modello concettuale sono una misura della
qualità del processo di progettazione del database e di modellazione.
Contenuto
• Rilevanza: il modello deve fornire i dati rilevanti per l’applicazione.
Questa caratteristica pone in evidenza l’importanza della fase di raccolta dei requisisti, in quanto spesso gli utenti non sono in grado di
esprimere chiaramente quali dati sono interessanti e come verranno
utilizzati. Un aspetto da considerare è l’utilizzo di surrogati al posto
di dati desiderati e difficilmente ottenibili: questa pratica è giustificata solamente quando esistono delle correlazioni e dei modelli empirici
provati.
• Ottenibilità: i valori devono essere facilmente ottenibili. Questa caratteristica è legata alla precedente (nel caso in cui i dati non sono
disponibili è meglio utilizzare dei surrogati, piuttosto che non possedere nessun tipo di informazione) e sempre più spesso a problemi di
riservatezza e rispetto della privacy.
• Chiarezza della definizione: ogni termine nella definizione del modello
deve essere chiaramente definito. Le metodologie di progettazione dei
database pongono sempre in primo piano l’importanza del glossario
degli elementi del modello utilizzato.
Copertura
E’ definito come il grado con cui il modello comprende abbastanza dati per
soddisfare le necessità delle applicazioni, e non comprende dati in eccesso.
Idealmente il database dovrebbe contenere tutti e soli i dati necessari e niente
di più.
CAPITOLO 2. QUALITÀ DEI DATI E DIMENSIONE
18
• Comprensività: ogni dato necessario deve essere compreso nel modello. E’ necessario considerare tutti i possibili utenti e come le rispettive
necessità si sovrappongono; inoltre può essere necessario considerare, oltre alle applicazioni attuali, anche eventuali applicazioni future,
estendendo quindi lo scope del modello.
• Essenzialità: nessun dato non necessario deve essere compreso; infatti
dati non necessari distolgono dalla “cura adeguata” dei dati effettivamente necessari e aumentano i costi della gestione dei dati stessi.
Livello di Dettaglio
E’ la quantità di dati da includere e quanto precisi essi debbano essere.
• Granularità degli attributi: numero e copertura degli attributi utilizzati per rappresentare un singolo concetto. Ad esempio, per rappresentare il concetto di Indirizzo, in un’applicazione può essere sufficiente definire un solo attributo Address, mentre in un’altra è necessario
definire gli attributi Apartment, Street, State, Country. La granularità degli attributi deve essere progettata tenendo conto di differenti
trade-off: dettaglio vs. maggiori costi per ottenere e memorizzare i valori, possibilità di controlli di consistenza vs. minore flessibilità, maggiore applicabilità vs. la considerazione che troppi dettagli possono
“annoiare”l’utente.
• Precisione dei domini: è il livello di dettaglio nelle misure (o nello
schema di classificazione) che definiscono il dominio. In generale maggiore è il numero di valori nel dominio, maggiore è la precisione. Ad
esempio un dominio definito su un tipo enumerato con 20 valori è più
preciso dello stesso definito su 5 valori, cosı̀ come utilizzare i millimetri
per misurare l’altezza di una persona implica una precisione maggiore che utilizzare i centimetri. Ovviamente deve essere valutato se la
precisione è effettivamente necessaria ed utile (ad esempio in molte
applicazioni non serve conoscere l’altezza al millimetro; in altre addirittura può bastare un tipo enumerato a due valori: bassa, quando
l’altezza è minore/uguale di 160 cm ed alta).
Composizione
è la strutturazione interna della view. Si compone delle seguenti caratteristiche:
• Naturalezza: ogni elemento del modello deve avere una controparte “naturale”nel mondo reale. Questo spinge a limitare al minimo
l’utilizzo di attributi multifatto, viceversa il dominio di ogni attributo dovrebbe specificare l’informazione in modo naturale: domini
CAPITOLO 2. QUALITÀ DEI DATI E DIMENSIONE
19
non naturali spesso nascono dalla necessità di incorporare, per motivi
implementativi, informazioni secondarie nell’attributo.
• Identificabilità: ogni entità deve essere univocamente identificabile
rispetto alle altre (utilizzo della primary key).
• Omogeneità: i tipi delle entità dovrebbero essere definiti in modo da
minimizzare l’occorrenza di attributi non necessari/non applicabili.
Per promuovere l’omogeneità è utile ricorrere alle generalizzazioni (supertipi e sottotipi). Ad esempio in un database devono essere memorizzate informazioni sugli impiegati, che possono essere pagati mensilmente o giornalmente. Un modello potrebbe prevedere Employee =
<Name, Classification, MonthlySalary, DailySalary > ed in questo caso,
per ogni entità, uno degli ultimi due attributi è non applicabile (mancanza di omogeneità). Invece un modello che prevede: DailyEmployee
= <Name, Classification, DailySalary >, MonthlyEmployee = <Name, Classification, MonthlySalary > promuove l’omogeneità attraverso
l’uso del costrutto gen/spec.
• Ridondanza minima necessaria: la ridondanza deve essere sempre attentamente vagliata ed accuratamente giustificata, altrimenti va eliminata; questo perchè aumenta i costi e la gestione della sua coerenza
distoglie da dati maggiormente importanti.
Consistenza della Vista
• Consistenza semantica: il modello deve essere non ambiguo e consistente. Bisogna prestare attenzione ai cicli di relazioni 1:1 ed 1:N, cosı̀
come alla definizione dei vincoli di molteplicità nelle associazioni.
• Consistenza strutturale: i tipi delle entità e degli attributi devono
avere sempre la stessa struttura di base. Ad esempio tutte le date
devono essere in un formato comune, anche se sono attributi di entità diverse; la stessa considerazione vale per i nomi o le informazioni
toponomastiche.
Reazione al Cambiamento
Ognuna delle precedenti cinque dimensioni viene valutata rispetto all’insieme attuale delle applicazioni. Con il passare del tempo le necessità applicative si modificano, e di pari passo dovrebbe evolvere anche il modello dei
dati sottostante. Quest’ultima dimensione considera appunto la capacità del
modello di soddisfare le necessità in continua evoluzione.
• Robustezza: è la capacità del modello di sopportare cambiamenti nei
requisisti e/o nel mondo reale senza forti impatti sulla struttura di
base.
CAPITOLO 2. QUALITÀ DEI DATI E DIMENSIONE
20
• Flessibilità: è la capacità del modello di soddisfare nuove interrogazioni.
In conclusione, va notato che le quindici caratteristiche non sono indipendenti tra di loro, ma ci sono correlazioni positive (migliorare una caratteristica migliora anche l’altra) e negative (migliorare una peggiora l’altra)
tra di esse; solo per citare alcuni esempi, godono di correlazione positiva la
terna comprensività, granularità degli attributi e precisione del dominio, la
coppia ottenibilità e naturalezza, la tripla consistenza semantica, chiarezza
della definizione e identificabilità, la coppia essenzialità ed omogeneità, la
coppia robustezza e flessibilità. Godono di correlazione negativa la coppia
costo e rilevanza, la coppia rilevanza e naturalezza, la tripla comprensività,
ridondanza e precisione dei domini. Quanto detto rientra nel problema del
Trade Off tra dimensioni, che approfondiremo nei paragrafi successivi.
2.3.2
Qualità nella Rappresentazione dei Dati
La registrazione di un dato è composta da un formato e da una o più istanze
fisiche dei valori. Un formato è un mapping dal dominio ad un insieme di
simboli; sia V il dominio concettuale e S un insieme di rappresentazioni
simboliche, allora il formato è una funzione
θ:V→S
Questa qualità è quella riferita allo schema logico, che è alla base dell’implementazione di qualunque database. Le dimensioni legate al formato
sono:
• Appropriatezza: Un formato è più appropriato di un altro se è più
adatto a soddisfare le esigenze dell’utente. Dipende dall’utente e dal
mezzo utilizzato.
• Interpretabilità: Un buon formato aiuta l’utente ad interpretare i dati
correttamente. Ad esempio, si consideri un dato che ha un dominio di tipo categoria, e come differiscono, secondo l’interpretabilità,
il formato con valori (1,2,3) e quello con valori (insufficiente, buono,
ottimo).
• Precisione del Formato: Un formato è preciso se permette di distinguere elementi del dominio che devono essere distinti dall’utente. Questa
dimensione è importante, ad esempio, nel caso di valori numerici reali, e nel caso di etichette in cui la dimensione della stringa è limitata
(troncamenti non permettono di distinguere valori differenti).
• Flessibilità del Formato: è la facilità di cambiamento del data item in
corrispondenza al cambiamento delle esigenze dell’utente od al cambiamento della piattaforma di supporto alla memorizzazione del data
CAPITOLO 2. QUALITÀ DEI DATI E DIMENSIONE
21
item. Ad esempio, una rappresentazione di un data item anno a due
cifre è stata sufficiente fino a quando non si è raggiunto l’anno 2000.
• Capacità a Rappresentare Valori Nulli: è relativa all’insieme di rappresentazione e rappresenta il grado con cui è possibile distinguere gli
elementi di tale insieme rispetto alle esigenze dell’utente. Rappresentazioni precise devono anche garantire la possibilità di rappresentare
valori nulli. Ad esempio, si hanno diversi livelli di precisione a seconda
che i valori numerici siano rappresentati con un formato integer oppure
real.
• Uso Efficiente della Memoria Fisica: spieghiamo il concetto con un
esempio. Memorizzare due icone corrispondenti a maschio e femmina
è meno efficiente che memorizzare (0,1); questo esempio mostra anche
come alcuni requisiti possano essere in conflitto; infatti la memorizzazione di (0,1), pur essendo positiva per l’efficienza di memorizzazione,
inficia la interpretabilità. E’ dunque, in alcuni casi, necessario gestire
un tradeoffs tra le varie dimensioni.
L’efficienza nell’impiego dei supporti di memorizzazione è spesso in contrasto
con le altre dimensioni, in particolare con appropriatezza ed interpretabilità.
Per quanto riguarda un approfondimento degli aspetti di appropriatezza
ed interpretabilità, si possono considerare alcuni testi sulle problematiche
dell’Interazione Uomo-Computer (HCI Human-Computer Interaction) e di
Usabilità come [6] e [7].
L’unica dimensione legata alle istanze fisiche è la Consistenza del Formato, definita come l’assenza di conflitti tra il formato e l’istanza fisica.
2.3.3
Qualità dei Valori dei Dati
La definizione di metodi e tecniche per valutare e migliorare gli schemi concettuali e gli schemi logici in differenti domini applicativi è ancora una fertile
area di ricerca. La qualità dei valori dei dati, è l’area dove si è sperimentato
di più. Descriviamo in dettaglio quattro dimensioni di qualità dei valori, più
precisamente, l’accuratezza, la completezza, la currency e la consistenza.
Accuratezza
L’accuratezza è definita come la vicinanza tra un valore v e un valore v’,
considerato la corretta rappresentazione dell’evento del mondo reale che v
vuole rappresentare. Per esempio se il nome di una persona è John, il
valore v’ =John è corretto, invece il valore v =Jhn non è corretto. Esistono
due tipi di accuratezza chiamati rispettivamente, accuratezza sintattica e
accuratezza semantica.
L’accuratezza sintattica è la vicinanza di un valore v agli elementi del
corrispondente dominio di definizione D. Nell’accuratezza sintattica non si
CAPITOLO 2. QUALITÀ DEI DATI E DIMENSIONE
22
è interessati a confrontare v con il vero valore v’ ; piuttosto, si è interessati
a controllare se v è uno dei valori in D. Ad esempio, se v =Jack, anche se
v’ =John, v è considerato sintatticamente corretto e Jack è un valore ammissibile nel dominio dei nomi di persona. Nel capitolo 3 vengono approfonditi
i metodi per misurare l’accuratezza sintattica, ma diamo uno sguardo generale alle possibili misurazioni; si possono utilizzare delle funzioni di distanza
che valutano la distanza tra v e i valori in D, i vari tipi di funzioni sono
descritte in dettaglio nell’appendice. Consideriamo la tabella 2.1 introdotta
precedentemente che descrive una relazione Movies, il valore Rman Holiday
del Title del movie 3 è sintatticamente inaccurato, in quanto non corrisponde a nessun titolo di movie. Roman Holiday è il titolo di movie più vicino a
Rman Holiday.
L’accuratezza semantica è la vicinanza del valore v al vero valore v’.
Consideriamo nuovamente la relazione Movies mostrata in tabella 2.1. Lo
scambio di director per le tuple 1 e 2 è un esempio di errore di accuratezza
semantica. Per quanto riguarda la misurazione, mentre per l’accuratezza
sintattica è ragionevole utilizzare funzioni di confronto, per l’accuratezza
semantica è più accettabile un dominio come <corretto, non corretto> per
la sua misurazione. A differenza dell’accuratezza sintattica, la misurazione
di quella semantica di un valore v necessita che il vero valore di v sia noto.
L’accuratezza semantica è di solito più complessa da misurare.
L’accuratezza, in generale, può essere misurata a differenti livelli di granularità del modello dei dati, facendo riferimento al modello relazionale l’accuratezza può riguardare: i singoli valori di un attributo di una relazione,
il singolo attributo, la relazione e perfino l’intero database. Quando viene
considerata l’accuratezza di un insieme di valori, si può introdurre un tipo di
accuratezza chiamata Duplicazione. La Duplicazione si manifesta quando,
un’entità del mondo reale viene memorizzata due o più volte in una sorgente dati. Al momento del popolamento del database, se viene effettuato un
controllo di consistenza sulla chiave primaria il problema della duplicazione
è escluso a priori.
Completezza
Esistono tre tipi di completezza. La completezza dello schema è definita
come il grado con il quale i concetti e le loro proprietà sono presenti nello
schema. La completezza dell’ attributo è definita come una misura dei valori
mancanti per uno specifico attributo di una relazione. La completezza della
popolazione valuta i valori mancanti rispetto ad una popolazione di riferimento. Focalizziamoci su un particolare modello di dati, più precisamente
sul modello relazionale e vediamo cosa significa completezza in questo caso.
La completezza di una relazione può esser definita come il grado con il
quale la relazione rappresenta la corrispondente parte del mondo reale. Nel
modello relazionale, la completezza è definita in base a:
CAPITOLO 2. QUALITÀ DEI DATI E DIMENSIONE
23
1. la presenza/assenza e significato dei valori nulli.
2. la validità di una delle due assunzioni chiamate rispettivamente open
world assumption e closed world assumption
In un modello con valori nulli, la presenza di un valore nullo ha il significato generale di valore mancante, ma è importante capire perchè tale valore
non è presente. I significati che si possono dare sono:
• il valore non è presente perchè esiste nel mondo reale ma non è conosciuto.
• il valore non è presente perchè non esiste in generale.
• il valore non è presente perchè potrebbe esistere ma attualmente non
si è a conoscenza del fatto che esista oppure no.
Nei modelli logici come quello relazionale, ci sono due assunzioni per
la completezza dei dati di una istanza r di relazione. La closed world assumption (CWA) indica che solo i valori attualmente presenti in una tabella
relazionale r e nessun altro valore rappresentano i fatti veri del mondo reale.
Nella open world assumption (OWA) non possimo indicare ne la verità ne
la falsità dei fatti non rappresentati nelle tuple di r.
Dalle quattro possibili combinazioni, considerare/non considerare i valori
nulli e OWA/CWA vengono fuori due casi:
1. modello senza valori nulli che rispetta OWA.
2. modello con valori nulli che rispetta CWA.
Nel modello con valori nulli che rispetta CWA, la completezza può esser
definita considerando la granularità degli elementi del modello: valore, tupla,
attributo e relazione come mostrato in figura 2.2. E’ possibile definire:
• Completezza del Valore: rileva la presenza di valori nulli per alcuni
campi di una tupla.
• Completezza della Tupla: definita per una tupla, in base ai valori di
tutti i suoi campi.
• Completezza dell’Attributo: misura il numero di valori nulli di un
particolare attributo in una relazione.
• Completezza della Relazione: rileva la presenza di valori nulli in una
relazione.
CAPITOLO 2. QUALITÀ DEI DATI E DIMENSIONE
24
Figura 2.2: Completezza di differenti elementi del modello relazionale
Dimensioni Temporali: Currency, Timeliness e Volatility
La Currency riguarda quanto tempestivamente i dati sono aggiornati. Può
esser considerata una accuratezza temporale. Riprendendo l’esempio della
relazione Movies mostrata in tabella 2.1, si può notare che l’attributo #Remakes del movie 4 ha una bassa currency, in quanto un remake del movie
4 è stato fatto, ma questa informazine non risulta nell’aumento del valore
del numero di remake. Altro esempio è quello dell’indirizzo, se un indirizzo
di residenza di una persona è aggiornatso, quindi corrisponde all’indirizzo
dove attualmente vive, la currency è alta.
La Volatility riguarda la frequenza in base alla quale i dati cambiano nel
tempo. Per esempio, dati stabili come le date di nascita hanno volatilità
pari a zero, invece il numero di scorte di un magazzino ha un alto grado di
volatilità, in quanto cambia frequentemente.
La Timeliness esprime quanto è aggiornato il dato per il compito preso in considerazione. Esistono casi in cui i dati sono aggiornati, ma non
sono attualmente utili perchè in ritardo rispetto ad uno specifico utilizzo.
Per esempio, consideriamo la tabella degli orari dei corsi universitari, essa
può essere aggiornata con i valori più recenti, ma è possibile che non sia
disponibile in tempo, ad esempio dopo l’inizio dei corsi.
Consistenza
La dimensione consistenza rileva le violazioni di regole semantiche definite
su un insieme di dati. Con riferimento alla teoria del modello relazionale, i
vincoli di integrità sono un istanza di queste regole semantiche. Diamo una
panoramica dei vincoli di integrità del modello relazionale che permettono
di comprendere il concetto di consistenza.
I vincoli di integrità sono proprietà che devono essere soddisfatte da
tutte le istanze di uno schema di basi di dati. Sono normalmente definiti
CAPITOLO 2. QUALITÀ DEI DATI E DIMENSIONE
25
sugli schemi ma possono essere controllati su una singola istanza di uno
schema. Ogni vincolo può essere visto come un predicato che associa ad
ogni istanza, il valore vero o falso. Se il predicato assume il valore vero
diciamo che l’istanza soddisfa il vincolo. In generale ad uno schema di basi
di dati si associano un insieme di vincoli e si considerano corrette le istanze
che soddisfano tutti i vincoli.
Si possono distinguere due principali categorie di vincoli di integrità, in
base agli elementi di un database che sono coinvolti: vincoli intra-relazionali
e vincoli inter-relazionali. I vincoli intra-relazionali possono riguardare i
singoli attributi o più attributi di una singola relazione. Questi vincoli hanno
due casi particolari, vincolo di tupla: è un vincolo che può essere valutato su
ciascuna tupla indipendentemente dalle altre, e vincolo sui valori o vincolo
di dominio: che impone restrizioni sul dominio dell’attributo. I vincoli
inter-relazionali coinvolgono gli attributi di più relazioni.
I vincoli di integrità principali sono le Dipendenze.
• Dipendenza di chiave: è il più semplice tipo di dipendenza. Data una
istanza r di relazione con un insieme di attributi, per un sottoinsieme
K degli attributi una dipendenza di chiave è definita, se non ci sono
tuple di r che hanno gli stessi valori per il sottoinsieme K.
• Dipendenza di inclusione: detta anche vincolo referenziale, su un’istanza di relazione r dichiara che alcune colonne di r sono contenute
in altre colonne di r o in altre istanze relazionali s. Un vincolo di
chiave esterna è un esempio di dipendenza di inclusione.
• Dipendenza Funzionale: data un’istanza di relazione r, siano X e Y
due insiemi non vuoti di attributi in r. r soddisfa la dipendenza
funzionale
X→Y
se per ogni coppia di tuple t1 e t2 in r vale:
If t1.X =t2.X, then t1.Y =t2.Y
dove la notazione t1.X significa la proiezione delle tuple t1 sugli attributi in X.
CAPITOLO 2. QUALITÀ DEI DATI E DIMENSIONE
2.4
26
TradeOffs tra Dimensioni
Le dimensioni di qualità non sono indipendenti, ma correlate tra loro. Se
una dimensione viene considerata più importante delle altre per una specifica
applicazione, la scelta di favorire tale dimensione potrebbe avere conseguenze
negative per le altre. Stabilire i tradeoffs tra dimensioni è un problema da
non sottovalutare. Facciamo alcuni esempi.
Primo, tradeoffs tra timeliness e una tra le dimensioni accuratezza, completezza e consistenza. Avere dati accurati (o completi o consistenti) potrebbe richiedere tempo, avendo un effetto negativo sulla timeliness. Al
contrario, avere dati tempestivi potrebbe causare una bassa accuratezza (o
completezza o consistenza). Un esempio di questo caso, sono le applicazioni web. Considerando i vincoli di tempo che sono spesso molto stretti
per disponibilità di dati sul web, è possibile che tali dati abbiamo qualche
problema rispetto alle altre dimensioni di qualità. Per esempio, una lista
di corsi pubblicata su un sito web di un’università deve essere tempestiva,
sebbene potrebbe contenere errori di accuratezza o consistenza e alcuni campi potrebbero non essere presenti. Se consideriamo, invece, un’applicazione
di e-banking l’accuratezza, la consistenza e la completezza sono molto più
importanti della timeliness.
Un caso di tradeoffs interessante è quello tra consistenza e completezza. La domanda che ci si pone è la seguente: è meglio avere pochi dati
ma consistenti, o avere più dati ma inconsistenti ? In base al dominio applicativo la scelta cambia. Nel campo statistico, l’analisi dei dati richiede
una gran quantità di dati e l’approccio è favorire la completezza tollerando
l’inconsistenza o adottando tecniche per risolverla. Invece, se consideriamo
un’applicazione che calcola i salari degli impiegati di una compagnia è più
importante la consistenza della completezza.
Le dipendenze tra le dimensioni di DQ, sebbene non siano analizzate in
modo consistente nell’area di ricerca dell’information quality, rappresentano
un problema di importanza primaria. La conoscenza delle dipendenze può
aiutare gli analisti di DQ nel trovare errori e può essere utile per valutare
il livello di qualità di un insieme di dati. In [10] viene proposto un approccio data-driven per l’analisi delle dipendenze tra le dimensioni di qualità.
L’analytical framework proposto fornisce modelli di dipendenze e formule
analitiche basate sull’entropia di Shannon. Quest’ultima caratterizza ogni
modello e propone misure di correlazione tra le dimensioni. L’identificazione automatica di modelli di dipendenze per un particolare insieme di dati è
possibile grazie al framework implementato.
Capitolo 3
Analisi delle Metriche
Questo capitolo analizza le metriche presenti in letteratura, relative ad alcune dimensioni di DQ. Per alcune delle dimensioni esistenti viene fatta una
panoramica delle possibili metriche. Le dimensioni prese in considerazione
sono relative alla qualità dei dati, in quanto la valutazione e l’implementazione delle metriche è meno complessa delle dimensioni del modello concettuale
e della rappresentazione dei dati.
Per ogni dimensione viene fornito il Nome e la Definizione, i Tipi
di Dati : il tipo di dato (strutturato, semistrutturato, non strutturato) sul
quale è possibile valutare la dimensione. Per ogni metrica viene fornita la
Descrizione, il Tipo: se essa è diretta, ovvero calcolabile direttamente
sui dati strutturati (dati del database) o indiretta se necessita di altri dati/informazioni, Informazioni : se necessita di informazioni esterne ai dati
da valutare , ovvero di metadati, il Contesto: se può essere applicata su
qualunque contesto di dati (generale) oppure su contesti particolari (finanziario, scientifico, statistico, etc.) (particolare), la Granularità: il livello di
granularità sul quale può essere applicata (database, relazione, tupla, attributo, valore), la Scala dei Risultati : la scala sul quale vengono riportati
i risultati della metrica (intervallo [0, 1], insieme N+ , R+ , etc.).
Nel paragrafo 3.1, viene presentata una tabella che elenca per alcune dimensioni di qualità, la presenza o assenza di metriche e la relativa creazione
dell’algoritmo di implementazione. Spieghiamo il significato della tabella e
dei valori. Sono presenti tre colonne, il nome della dimensione, la metrica di valutazione e la creazione dell’algoritmo. Tralasciando il nome della
dimensione, la colonna metrica di valutazione vuole indicare per quella particolare dimensione l’esistenza (Presente) o la non esistenza (Assente) di
almeno una metrica nella letteratura presente o se non è presente un metodo di misura esplicito, almeno un’euristica o conoscenza che fornisca una
soluzione al problema di DQ. La colonna creazione algoritmo, vuole indicare la possibilità di creare un algoritmo, un implementazione delle metriche
esistenti, se appunto sono presenti (in base al relativo valore nella colonna
27
CAPITOLO 3. ANALISI DELLE METRICHE
28
metrica di valutazione). I valori di questa colonna non si basano su esperimenti reali e pratici, ma su valutazioni teoriche, nel senso che per quella
particolare metrica si è cercato di “farsi un’idea” di come implementarla con
gli strumenti a disposizione. Infatti, il valore Non Possibile indica che la
creazione non è possibile perchè non sono presenti metriche di valutazione,
il valore Possibile indica che la creazione è possibile perchè la metrica non
richiede particolari metodi di misura, come dati coinvolti non troppo particolari o strumenti di misura non troppo specifici e il valore Difficile indica
che la creazione è molto complessa in quanto la metrica richiede strumenti
particolari (tecniche di Intelligenza Artificiale, questionari su un insieme di
utenti) o informazioni aggiuntive non disponibili. Facciamo due esempi, il
primo di metrica presente e creazione algoritmo possibile, il secondo di metrica presente e creazione algoritmo difficile. Il primo esempio è relativo alla
dimensione duplication per la quale la metrica si basa sul calcolo del numero di duplicati (record duplicati), la metrica potrebbe essere implementata
con tecniche di record matching quindi la creazione dell’algoritmo è possibile. Il secondo esempio è relativo alla dimensione relevancy, ovvero al grado
con cui i dati sono adatti e utili per uno specifico scopo, la metrica si basa
sulla forma funzionale simple ratio con un rapporto tra i dati considerati
“pertinenti” e il numero totale di dati. La creazione dell’algoritmo è molto
difficile, in quanto prima di effettuare il semplice rapporto (il numero totale
di dati è facilmente calcolabile), l’algoritmo dovrebbe risolvere il vero problema: determinare il significato di “pertinente allo scopo” e successivamente
dividere i dati in base alla loro utilità rispetto all’obiettivo. Con algoritmi
tradizionali questo è molto difficile e si rendono utili, ad esempio tecniche di
intelligenza artificiale.
29
CAPITOLO 3. ANALISI DELLE METRICHE
3.1
Tabella Dimensioni - Metriche - Algoritmi
Nome Dimensione
Metrica di Valutazione
Creazione Algoritmo
Accessibility
Accuracy Syntactic
Accuracy Semantic
Appropriate amount of data
Believability
Completeness
Concise Representation
Consistency
Currency
Detail
Duplication
Ease of Manipulation
Objectivity
Relevancy
Reputation
Security
Timeliness
Ease of Understanding
Variety of Data Sources
Value-Added (Usefulness)
Volatility
Presente
Presente
Presente
Presente
Presente
Presente
Presente
Presente
Presente
Assente
Presente
Presente
Presente
Presente
Presente
Presente
Presente
Presente
Assente
Presente
Presente
Possibile
Possibile
Possibile
Difficile
Difficile
Possibile
Difficile
Possibile
Possibile
Non Possibile
Possibile
Difficile
Difficile
Difficile
Difficile
Possibile
Possibile
Difficile
Non Possibile
Difficile
Possibile
Tabella 3.1: Tabella Dimensioni-Metriche-Algoritmi
CAPITOLO 3. ANALISI DELLE METRICHE
3.2
30
Dimensioni della Qualità dei Dati: Metriche
Presentiamo di seguito, uno schema che mette in relazione il concetto di
dimensione, metrica e algoritmo con alcune particolarità per il concetto di
metrica.
Figura 3.1: Schema relazione tra dimensione, metrica e algoritmo
Approfondiamo i concetti dello schema:
• Dimensione: La dimensione, definita in modo preciso nel Capitolo 2,
è l’aspetto della qualità che si vuole analizzare e valutare.
• Metrica: La metrica è il metodo con il quale deve essere effettuata la
valutazione (quantitativa) della dimensione.
• Algoritmo: L’algoritmo è l’implementazione della metrica.
• Contesto di Utilizzo: Esistono metriche che possono essere utilizzate in contesti generali, su qualunque database senza informazioni
riguardanti il contesto di utilizzo; altre metriche invece dipendono dal
contesto d’uso; ad esempio, delle metriche possono essere applicate su
database che contengono qualunque tipo di dato, come quelle relative
alla completezza, altre invece sono legate ai dati contenuti nel database (finanziari, scientifici, etc.) perchè necessitano di informazioni sui
dati che provengono dal contesto, come nel caso della currency, che
necessita del metadato frequenza media di aggiornamento del dato; la
frequenza varia notevolmente in base al tipo di dato. La frequenza dei
CAPITOLO 3. ANALISI DELLE METRICHE
31
dati finanziari è molto più alta dei dati scientifici, basti pensare alle
quotazioni in borsa dei titoli azionari che variano minuto dopo minuto.
• Informazioni Aggiuntive: Alcune metriche per poter funzionare
hanno bisogno di informazioni in più rispetto ai soli valori del database. Alcuni esempi sono le lookup table ovvero tabelle che contengono
tutti i valori corretti di un determinato dominio (nomi, indirizzi, etc.),
oppure relazioni uguali a quelle che si sta analizzando, ma complete e
con valori accurati.
• Granularità: La granularità è il livello di dettaglio di applicazione
della metrica, ad esempio una metrica può essere applicata ad una
relazione, ad un attributo, ad una tupla o al singolo valore.
CAPITOLO 3. ANALISI DELLE METRICHE
3.2.1
32
Syntactic Accuracy
Nome
Definizione
Tipi di Dati
Syntactic Accuracy / Free of Error
Vicinanza tra il valore v con gli elementi del relativo dominio D
di definizione
Strutturati
Prima metrica
Descrizione
Tipo
Informazioni
Contesto
Granularità
Scala Risultati
Funzioni di Distanza : valutano la distanza tra v e i valori di D
Diretta
Necessita di lookup table
Generale
Valore
Insiemi N+ , R+
Alcune delle possibili funzioni di distanza sono:
• Distanza di edit
• Distanza pesata
• Soundex
• Distanza pesata basata sulle frequenze
Le funzioni di distanza vengono approfondite attraverso una panoramica di
quelle esistenti nell’Appendice B.
Seconda metrica
Descrizione
Tipo
Informazioni
Contesto
Granularità
Scala Risultati
Simple Ratio
Diretta
Necessita di lookup table
Generale
Basi di Dati, Relazioni, Attributi
Intervallo [0,1]
E’ definita come il rapporto tra il numero di valori accurati e il numero
di valori totali, sottratto a 1
CAPITOLO 3. ANALISI DELLE METRICHE
33
Terza metrica
Descrizione
Tipo
Informazioni
Contesto
Granularità
Scala Risultati
Metriche per gli errori di accuratezza che influiscono sul confronto
tra tuple
Indiretta
Necessita di lookup table
Generale
Tuple
Intervallo [0,1]
Il confronto è basato sulle tuple della sorgente dati sotto esame rispetto
alle tuple di un altra sorgente che si suppone contenga le stesse ma corrette
tuple. In questo processo gli errori di accuratezza dei valori degli attributi
possono non influenzare il confronto tra tuple oppure possono influenzarlo in
maniera tale da non permetterlo. Consideriamo alcune metriche in questo
contesto.
Consideriamo uno schema relazionale R costituito da K attributi e un’istanza r di relazione composta da N tuple. Sia yij = (i = 1..K, J = 1..N )
una variabile booleana definita in corrispondenza dei valori qij delle celle
tale che yij è uguale a zero se qij è sintatticamente accurato, altrimenti è
uguale a uno.
Per identificare se gli errori di accuratezza influenzano o meno il confronto di una tabella relazionale r con una tabella di riferimento r’ contenente
i valori corretti introduciamo una variabile booleana sj che è uguale a zero se la tupla tj corrisponde a una tupla in r’, altrimenti è uguale a uno.
Introduciamo tre metriche.
La prima metrica è chiamata weak accuracy error ed è definita come:
j=N
X
j=1
V
β((qj > 0) (sj = 0))
N
dove β(·) è una variabile booleanaPuguale a uno se la condizione in parentesi
j=N
è vera, altrimenti zero, e qj =
j=1 qij . Tale metrica considera il caso
in cui per una tupla tj si verificano errori di accuratezza (qj > 0) ma non
influenzano l’identificazione (sj = 0).
La seconda metrica è chiamata strong accuracy error ed è definita come:
j=N
X
j=1
V
β((qj > 0) (sj = 1))
N
dove β(.) è una variabile booleana
uguale a uno se la condizione in parentesi
Pj=N
è vera, altrimenti zero, e qj = j=1
qij . Tale metrica considera il caso in cui
per una tupla tj si verificano errori di accuratezza (qj > 0) che influenzano
l’identificazione (sj = 1).
CAPITOLO 3. ANALISI DELLE METRICHE
34
La terza metrica determina la percentuale di tuple accurate rispetto alla
tabella di riferimento. E’ definita come:
j=N
X β((qj = 0) V(sj = 0))
N
j=1
considerando la frazione di accurate (qj = 0) e corrispondenti (sj = 0) tuple.
3.2.2
Semantic Accuracy
Nome
Definizione
Tipi di Dati
Semantic Accuracy / Correctness
Vicinanza tra il valore v e il valore v’ semanticamente corretto
corrispondente a v
Strutturati
La semantic accuracy è più complessa da misurare rispetto alla syntactic
accuracy. La complessità deriva dal fatto che il corrispondente valore v’ di v
semanticamente corretto deve essere conosciuto. Le metriche per la semantic
accuracy utilizzano una scala di risultati del tipo <corretto, non corretto>
Prima metrica
Descrizione
Tipo
Informazioni
Contesto
Granularità
Scala Risultati
Sostituzione con syntactic accuracy
Indiretta
Necessita di lookup table
Generale
Valore
<corretto,non corretto>
Il problema di misurare la semantic accuracy viene sostituito molto spesso la misura della syntactic accuracy, soprattutto quando si conosce a priori
che il grado di errori dei valori presenti nella relazione è molto basso.
Seconda metrica
Descrizione
Tipo
Informazioni
Contesto
Granularità
Scala Risultati
Funzioni di Distanza
Indiretta
Necessita di lookup table
Generale
Valore
<corretto,non corretto>
Con le funzioni di distanza si valuta il valore di una cella della relazione
con il valore della cella corrispondente di un’altra relazione (o più di una
relazione) identica e considerata semanticamente corretta. Questo tipo di
metrica richiede la soluzione all’ object identification problem ovvero il problema di capire se due tuple si riferiscono alla stessa entità del mondo reale
CAPITOLO 3. ANALISI DELLE METRICHE
35
oppure no.
Per fare questo bisogna risolvere altri due sottoproblemi:
• Identificazione: le tuple in relazioni diverse di solito hanno identificatori diversi e si deve effettuare un confronto tra chiavi per mettere
in corrispondenza le stesse tuple in differenti relazioni.
• Strategia di Decisione: dopo che le tuple sono state collegate si
verifica che corrispondano alla stessa entità oppure no.
Terza metrica
Descrizione
Tipo
Informazioni
Contesto
Granularità
Scala Risultati
Simple Ratio
Diretta
Necessita di lookup table
Generale
Basi di Dati, Relazioni, Attributi
<corretto,non corretto>
Utilizzando la metrica per la misura della semantic accuracy sui singoli valori, si può calcolare un indice che esprima quanti valori sono semanticamente
corretti, rispetto al totale dei valori. Si effettua il rapporto tra il numero di
valori accurati rispetto al numero totale di valori, sottratto a 1.
3.2.3
Duplication
Nome
Definizione
Tipi di Dati
Duplication / Uniqueness Accuracy per insiemi di valori
Un entità del mondo reale è memorizzata due o più volte nella
base di dati
Strutturati
Metrica
Consideriamo l’ipotesi che sulla relazione non venga eseguito nel momento
del popolamento della tabella un controllo di consistenza sulla chiave primaria, nel caso contrario il problema della duplicazione non si verificherebbe.
Descrizione
Calcolo del numero di duplicati
Tipo
Diretta
Informazioni
Nessuna Informazione
Contesto
Generale
Granularità
Basi di Dati, Relazioni
Scala Risultati Insieme N+ oppure %
La metrica calcola il numero di duplicati presenti in una base di dati o
ancora meglio in una relazione, confrontando principalmente i valori della
chiave primaria che si suppone non siano consistenti.
CAPITOLO 3. ANALISI DELLE METRICHE
3.2.4
36
Completeness
Nome
Definizione
Tipi di Dati
Completeness
Grado in cui i valori previsti in uno schema sono presenti
nell’istanza dello schema
Strutturati e Semistrutturati
Prima metrica
Descrizione
Tipo
Informazioni
Contesto
Granularità
Scala Risultati
Modello Completezza
Reference Relation
Diretta
Necessita di una Reference Relation
Generale
Relazione
Intervallo [0,1]
Modello senza valori nulli con assunzione OWA
Introduciamo il concetto di Refence Relation; data una relazione r la reference relation di r detta ref (r) è la relazione contenente tutte le tuple che
soddisfano lo schema relazionale di r. Ad esempio se ho una relazione DIP
che rappresenta gli impiegati di uno specifico dipartimento e un particolare
impiegato non è presente come una tupla di DIP, la tupla in questione è presente in ref (DIP) e quindi le due relazioni differisco esattamente per quella
tupla. Molte volte la reference relation non è disponibile, è più probabile
che sia presente la sua cardinalità. In base a queste considerazioni la completezza di una relazione r è misurata con il rapporto tra il numero di tuple
attualmente presenti nella relazione r e il numero di tuple della reference
relation di r. In formula:
|r|
C(r) =
|ref (r)|
Seconda metrica
Descrizione
Tipo
Informazioni
Contesto
Granularità
Scala Risultati
Modello Completezza
Attribute Completeness - Simple Ratio
Diretta
Nessuna Informazione
Generale
Attributi
Intervallo [0,1] oppure %
Modello con valori nulli con assunzione CWA
La metrica misura la presenza di valori nulli per un particolare attributo
di una relazione. Si considera il rapporto tra il numero di tuple che hanno
per quell’attributo un valore nullo rispetto al numero totale di tuple presenti
nella relazione, sottratto a 1.
CAPITOLO 3. ANALISI DELLE METRICHE
37
Terza metrica
Descrizione
Tipo
Informazioni
Contesto
Granularità
Scala Risultati
Modello Completezza
Tuple completeness - Simple Ratio
Diretta
Nessuna Informazione
Generale
Tuple
Intervallo [0,1] oppure %
Modello con valori nulli con assunzione CWA
La metrica misura la presenza di valori nulli per una particolare tupla di
una relazione. Si considera il rapporto tra il numero di valori nulli presenti
nella tupla ovvero il numero di attributi con valori nulli per la tupla rispetto
al numero totale di attributi della tupla stessa, sottratto a 1.
Quarta metrica
Descrizione
Tipo
Informazioni
Contesto
Granularità
Scala Risultati
Modello Completezza
Relation completeness - Simple Ratio
Diretta
Nessuna Informazione
Generale
Relazione
Intervallo [0,1] oppure %
Modello con valori nulli con assunzione CWA
La metrica misura la presenza di valori nulli in una relazione. Si considera il rapporto tra il numero di valori nulli presenti nella relazione ovvero
il numero di celle con valori nulli rispetto al numero totale di celle della
relazione.
3.2.5
Currency
Nome
Definizione
Tipi di Dati
Currency
Grado di aggiornamento dei dati
Strutturati, Semistrutturati, non strutturati
Prima metrica
Descrizione
Tipo
Informazioni
Contesto
Granularità
Scala Risultati
Differenza rispetto al metadato
Diretta
Necessita del metadato / frequenza di aggiornamento
Particolare
Attributo, Valore
<current,not current>
La metrica si basa sulla disponibilità del metadato che corrisponde all’ultima
CAPITOLO 3. ANALISI DELLE METRICHE
38
volta in cui è stato aggiornato lo specifico dato, ovvero l’ultimo aggiornamento effettuato.
• Se la frequenza di aggiornamento è nota, la currency per tali valori è
calcolabile in maniera esatta.
• Se è nota la frequenza di aggiornamento media si può calcolare una
currency media considerando un certo grado di errore.
Seconda metrica
Descrizione
Tipo
Informazioni
Contesto
Granularità
Scala Risultati
Ritardo temporale
Diretta
Necessita del ritardo temporale
Particolare
Attributo, Valore
<current,not current>
La metrica calcola il ritardo temporale tra l’evento del mondo reale e la
sua registrazione nella base di dati; più precisamente è la differenza tra il
momento in cui i dati vengono memorizzati nel sistema e il momento in cui
i dati vengono modificati nel dominio reale. Ad esempio consideriamo le
dichiarazioni dei redditi e una base di dati che rappresenta le dichiarazioni;
se l’inserimento avviene 6 mesi dopo l’invio, allora la currency è uguale a 6.
Terza metrica
Descrizione
Tipo
Informazioni
Contesto
Granularità
Scala Risultati
Somma di Age e tempo presenza nella base di dati
Diretta
Informazioni temporali
Particolare
Attributo, Valore
<current,not current>
La metrica è definita come :
Currency = Age + (DeliveryT ime − InputT ime)
dove Age è la differenza tra l’istante in cui è stato prodotto il dato e l’istante
in cui è stato ricevuto ovvero quanto datato è il dato quando ricevuto,
DeliveryTime indica il tempo in cui il dato prodotto è rilasciato al cliente,
InputTime indica quando il dato è ottenuto. Quindi è la somma di Age
e (DeliveryTime - InputTime) che misura da quanto il dato è nel sistema
informativo.
CAPITOLO 3. ANALISI DELLE METRICHE
3.2.6
39
Volatility
Nome
Definizione
Tipi di Dati
Volatility
Frequenza con la quale i dati variano nel tempo
Strutturati, Semistrutturati, non strutturati
Ricordiamo che la volatility di un dato è una proprietà intriseca del dato stesso ed è indipendente dal tempo relativo di memorizzazione nella base
di dati.
Metrica
Descrizione
Tipo
Informazioni
Contesto
Granularità
Scala Risultati
Differenza tra aggiornamenti successivi
Diretta
Informazioni temporali
Particolare
Attributo, Valore
Intervallo [0,1]
La metrica propone la misura della volatility su una scala tra 0 e 1, dove 0 si riferisce ai dati non volatili ovvero che non cambiano nel tempo e 1 si
riferisce ai dati che sono in continuo cambiamento. Si utilizza una misura in
base al tempo, si calcola il tempo tra due aggiornamenti successivi e proprio
questo tempo è utilizzato per caratterizzare la volatility. Quindi è definita
come la lunghezza del periodo di tempo per il quale rimane valido; successivamente il valore dovrà essere normalizzato secondo una scala prefissata
per esprimere il valore nell’intervallo [0,1].
3.2.7
Timeliness
Nome
Definizione
Tipi di Dati
Timeliness
Grado con cui l’aggiornamento di un dato è appropriato per uno
specifico scopo
Strutturati, Semistrutturati, non strutturati
Metrica
Descrizione
Tipo
Informazioni
Contesto
Granularità
Scala Risultati
Forma Funzionale - Min or Max Operation (DQA)
Indiretta
Valutazioni di altre dimensioni
Particolare
Attributo, Valore
Intervallo [0,1]
La misura della dimensione Timeliness implica il compito di verificare se
i dati sono aggiornati, ma anche se sono disponibili, al tempo giusto per un
CAPITOLO 3. ANALISI DELLE METRICHE
40
certo compito o scopo. La metrica quindi deve, misurare la currency e controllare che i dati siano disponibili prima del periodo di utilizzo pianificato.
E’ definita come:
currency
max 0, 1 −
volatility
La scala dei risultati in output va da 0 a 1, dove 0 significa una timeliness
non buona invece 1 una buona timeliness. La metrica definisce la timeliness in funzione della currency e della volatility , esiste una dipendenza
tra queste ultime due dimensioni nella definizione sopra ovvero i dati che
sono altamente volatili devono essere aggiornati invece la currency è meno
importante per quei dati con una bassa volatilità.
Un’ esponente può essere utilizzato come fattore di precisione : se il valore di timeliness ottenuto attraverso la metrica sopra indicata viene elevato
ad un esponente maggiore di uno, significa che i dati perdono tempestività
velocemente (più l’esponente è alto, più il valore di timeliness aumenta); se
il valore di timeliness ottenuto viene elevato ad un esponente minore di uno,
significa che i dati perdono tempestività con un basso tasso di velocità (più
l’esponente è basso, più il valore di timeliness diminuisce).
3.2.8
Consistency
Nome
Definizione
Tipi di Dati
Consistency
Grado in cui i valori degli attributi di una istanza di uno schema
soddisfano l’insieme di regole semantiche definite sullo schema
Strutturati
Prima metrica
Descrizione
Tipo
Informazioni
Contesto
Granularità
Scala Risultati
Forma Funzionale - Simple Ratio (DQA)
Diretta
Vincoli di integrità
Particolare
Attributo
Intervallo [0,1]
La metrica misura la percentuale di violazioni di un vincolo o regola rispetto
al numero totale di controlli effettuati, sottratto a 1.
CAPITOLO 3. ANALISI DELLE METRICHE
41
Seconda metrica
Descrizione
Tipo
Informazioni
Contesto
Granularità
Scala Risultati
Conteggio violazioni
Diretta
Vincoli di integrità
Particolare
Tupla
Insieme N+
La metrica calcola il numero di record che non soddisfano i vincoli o le
regole definite su di essi.
3.2.9
Concise Representation
Nome
Definizione
Tipi di Dati
Concise representation
Grado con cui i dati sono rappresentati in modo conciso
Strutturati, Semistrutturati
Metrica
E’ possibile misurare questa dimensione con la forma funzionale, simple ratio
(DQA). La metrica misura il grado di concisione della rappresentazione di
un insieme di informazioni, ovvero la percentuale dei dati considerati concisi
rispetto al totale dei dati.
3.2.10
Relevancy
Nome
Definizione
Tipi di Dati
Relevancy
Grado in cui i dati sono adatti e utili per uno specifico scopo
Strutturati, Semistrutturati
Metrica
E’ possibile misurare questa dimensione con la forma funzionale, simple ratio
(DQA). La metrica misura la percentuale dei dati considerati pertinenti e
utili, rispetto al totale dei dati.
3.2.11
Ease of manipulation
Nome
Definizione
Tipi di Dati
Ease of manipulation
Grado in cui i dati sono facili da manovrare e da gestire e sono
adatti per differenti scopi
Strutturati, Semistrutturati
CAPITOLO 3. ANALISI DELLE METRICHE
42
Metrica
E’ possibile misurare questa dimensione con la forma funzionale, simple
ratio (DQA). La metrica misura la percentuale dei dati considerati facili da
manovrare rispetto alla totalità dei dati.
3.2.12
Believability
Nome
Definizione
Tipi di Dati
Believability
Grado con cui i dati sono considerati veri e credibili
Strutturati, Semistrutturati
Prima metrica
Una prima metrica è basata sulla forma funzionale, Min or Max Operation
(DQA). La dimensione può essere valutata in vari modi, ad esempio in base
ad un giudizio soggettivo, in base all’esperienza passata o in base ad uno
standard comunemente accettato. Una volta ottenute queste variabili, esse
vengono normalizzate tra 0 e 1 e il valore complessivo di believability è dato
dal valore minimo tra tutti quelli considerati.
Seconda metrica
Una seconda metrica è basata sulla forma funzionale, Weighted Average
(DQA). E’ adatta quando è possibile assegnare un determinato grado di
importanza ad ognuna delle variabili che concorrono alla misura complessiva
del valore di believability. Si effettua una media pesata dei valori delle
variabili.
3.2.13
Appropriate amount of data
Nome
Definizione
Tipi di Dati
Appropriate amount of data
Grado in cui la quantità dei dati è appropriata
Strutturati, Semistrutturati
Metrica
La metrica è basata sulla forma funzionale, Min or Max Operation (DQA).
Consiste nel considerare il minimo tra due valori frazionari: il numero di
unità presenti fratto il numero di unità necessarie e il numero di unità
necessarie fratto il numero di unità presenti.
CAPITOLO 3. ANALISI DELLE METRICHE
3.2.14
43
Accessibility
Nome
Definizione
Tipi di Dati
Accessibility
Grado della facilità di accesso ai dati o di ottenimento dei dati
Strutturati, Semistrutturati
Metrica
La metrica è basata sulla forma funzionale, Min or Max Operation (DQA).
Enfatizza l’aspetto temporale della dimensione, è definita come il massimo
tra due termini:
∆t(richiesta dato utente, consegna dato utente)
max 0, 1 −
∆t(richiesta dato utente, dati non utili)
0 e 1 meno l’intervallo di tempo tra la richiesta dell’utente e la consegna
del dato all’utente diviso l’intervallo di tempo tra la richiesta dell’utente
e il momento in cui i dati non sono più utili. E’ possibile utilizzare un
esponente come fattore di precisione: se il valore di accessibility ottenuto
attraverso la metrica sopra indicata viene elevato ad un esponente maggiore
di uno, significa che la facilità di ottenere i dati aumenta (più l’esponente
è alto, più il valore di accessibility aumenta); se il valore di accessibility
ottenuto viene elevato ad un esponente minore di uno, significa che che la
facilità di ottenere i dati diminuisce (più l’esponente è basso, più il valore di
accessibility diminuisce).
3.2.15
Objectivity
Nome
Definizione
Tipi di Dati
Objectivity
Grado in cui i dati sono imparziali e obiettivi
Strutturati, Semistrutturati
Metrica
E’ possibile valutare la dimensione objectivity effettuando un’indagine tra gli
utenti, sottoponendo loro un questionario. Tale questionario contiene alcune
voci che sono misurate con una scala che prevede 11 valori, dove 0 significa
“per niente” e 10 “completamente”. Le voci previste per la dimensione
objectivity sono:
• l’informazione in esame è stata raccolta in modo oggettivo;
• l’informazione in esame è basata sui fatti;
• l’informazione in esame è oggettiva;
• l’informazione in esame presenta un punto di vista imparziale.
CAPITOLO 3. ANALISI DELLE METRICHE
3.2.16
44
Reputation
Nome
Definizione
Tipi di Dati
Reputation
Grado in cui i dati sono considerati e giudicati in termini della
loro provenienza o contenuto
Strutturati, Semistrutturati
Metrica
E’ possibile valutare la dimensione objectivity effettuando un’indagine tra gli
utenti, sottoponendo loro un questionario. Tale questionario contiene alcune
voci che sono misurate con una scala che prevede 11 valori, dove 0 significa
“per niente” e 10 “completamente”. Le voci previste per la dimensione
objectivity sono:
• l’informazione in esame è stata raccolta in modo oggettivo;
• l’informazione in esame è basata sui fatti;
• l’informazione in esame è oggettiva;
• l’informazione in esame presenta un punto di vista imparziale.
3.2.17
Security
Nome
Definizione
Tipi di Dati
Security
Grado in cui l’accesso ai dati è appropriatamente limitato per
garantire la loro sicurezza
Strutturati, Semistrutturati
Metrica
Una possibile metrica per misurare la security di una base di dati valuta le
seguenti voci:
• livello di sicurezza (diritti di accesso) dello schema dei dati;
• livello di sicurezza (diritti di accesso) dei tipi di dati;
• presenza di limitazioni fisiche all’accesso sulla rete;
• capacità del data store di impedire accessi non autorizzati.
3.2.18
Ease of Understanding
Nome
Definizione
Tipi di Dati
Ease of Understanding
Grado in cui i dati sono chiari, senza ambiguità e facili da
comprendere
Strutturati, Semistrutturati
CAPITOLO 3. ANALISI DELLE METRICHE
45
Metrica
E’ possibile valutare la dimensione objectivity effettuando un’indagine tra gli
utenti, sottoponendo loro un questionario. Tale questionario contiene alcune
voci che sono misurate con una scala che prevede 11 valori, dove 0 significa
“per niente” e 10 “completamente”. Le voci previste per la dimensione
objectivity sono:
• l’informazione in esame è stata raccolta in modo oggettivo;
• l’informazione in esame è basata sui fatti;
• l’informazione in esame è oggettiva;
• l’informazione in esame presenta un punto di vista imparziale.
3.2.19
Variety of Data Sources
Nome
Definizione
Tipi di Dati
Variety of Data Sources
Grado in cui i dati sono disponibili da varie fonti diverse
Strutturati, Semistrutturati
Nessuna Metrica
3.2.20
Usefulness
Nome
Definizione
Tipi di Dati
Usefulness
Grado di utilità dell’informazione per gli utenti
Strutturati, Semistrutturati, Non Strutturati
Metrica
E’ possibile ricorrere al feedback degli utenti, sottoponendo loro sondaggi e
questionari.
Capitolo 4
Realizzazione del Framework
4.1
Obiettivi
Lo scopo del framework è quello di creare un ambiente software che permetta
l’assessment della qualità dei dati di uno specifico database. In letteratura [1], il numero di dimensioni di qualità è molto alto. Ne esistono tante,
che possono essere analizzate e valutate. Si differenziano in base al modo
con cui possono essere valutate, più precisamente la valutazione può essere qualitativa o quantitativa. Inoltre dipendono anche dal tipo di dato che
può essere strutturato, semistrutturato e non strutturato, come descritto nel
Capitolo 2.
Abbiamo focalizzato lo studio sulle dimensioni relative alla qualità dei
dati, valutabili in modo quantitativo e relative ai dati strutturati. In modo
particolare si è posta l’attenzione sulle quattro dimensioni più importanti
la cui valutazione quantitativa è possibile, grazie al numero consistente di
metriche presenti in letteratura, rispetto ad altre dimensioni. Infatti una
considerazione frutto dello studio delle metriche delle dimensioni di qualità
è che molte metriche sono esprimibili teoricamente ma nella pratica la loro
implementazione incontra molte difficoltà.
Le dimensioni prese in esame sono: la completezza, l’accuratezza sintattica, la currency (una delle tre dimensioni temporali) e la consistenza.
4.2
Strumenti Utilizzati
Il framework è stato realizzato utilizzando per la maggior parte tecnologie e
strumenti di sviluppo open source, in particolare, il linguaggio di programmazione Java [23] con l’ausilio di un’ambiente di sviluppo integrato (IDE)
quale Eclipse [20]; il Database management system (DBMS) relazionale
MySQL [19].
Inoltre, è stato utilizzato il linguaggio XML [21] per la gestione dei
metadati (vedi Appendice A) utilizzati dal framework.
46
CAPITOLO 4. REALIZZAZIONE DEL FRAMEWORK
47
Con il linguaggio Java è stato possibile utilizzare librerie esterne open
source che svolgono un ruolo importante, elenchiamole:
• Java Database Connectivity (JDBC) [24]: le API per la connessione indipendente ai database tra un programma in linguaggio Java e
una vasta gamma di database, tra cui MySQL. Forniscono API per
l’accesso tramite il linguaggio SQL. Nel framework è utilizzata per la
connessione al database MySQL e per tutti gli accessi e gestione dei
dati ricavati dal database.
• SimMetrics [25]: è una libreria Java open source per funzioni di similarità o distanza, ad esempio Levenshtein distance; tutte le funzioni forniscono un risultato compreso tra 0 e 1. Nel framework è utilizzata in
alcune metriche per fornire le funzioni di similarità utili all’assessment
della dimensione.
• JFreeChart [26]: è una libreria Java open source che fornisce classi
per lo sviluppo di diagrammi professionali; supporta molti tipi di diagrammi e di output tra cui componenti Swing, file immagine (PNG e
JPEG), file di grafica vettoriale (EPS, PDF e SVG). Nel framework
è utilizzata per la creazione di grafici a torta, per la visualizzazione
grafica dei risultati.
• BrowserLauncher2 [27]: è una libreria Java open source che facilita
l’apertura di un browser da un’applicazione Java, di solito il browser
di default dell’utente. Nel framework è utilizzata per la visualizzazione
dei report.
Oltre alla struttura base costituita dagli algoritmi utilizzati per la valutazione delle dimensioni, il framework offre una GUI (Graphic User Interface)
che si appoggia a SWT [22], un widget toolkit open source per Java di nuova
concezione che conferisce una straordinaria efficienza e rettività.
4.3
Funzioni e Struttura
In questo paragrafo forniamo una descrizione delle funzioni offerte e della
struttura, ovvero delle classi Java, del framework.
4.3.1
Funzioni
La prima funzione offerta è la connessione/disconnesione al/dal database sul quale deve essere effettuato l’assessment della qualità, in questo
momento sono supportati database MySQL, ma con le oppurtune classi sarà
possibile gestire database come Access o Oracle. Ad ogni database caricato
viene associato un documento XML, che chiamiamo metadati dimensione
(descritto nell’Appendice A) da cui si ricava un report parziale, tramite la
CAPITOLO 4. REALIZZAZIONE DEL FRAMEWORK
48
formattazione del documento XML con XSL, con il quale è possibile visualizzare le valutazioni man mano effettuate. Alla prima connessione di quel
particolare database viene chiesta la creazione del documento e la scelta del
path di sistema operativo in cui sarà creato, questo path viene memorizzato
in un file di log, associato ad una chiave composta da (user, password, host, port, namedatabase) in modo che ad una successiva connessione il path
viene recuperato da questo file.
Altre funzioni offerte sono, informazioni relative al database come
numero tabelle, attributi e tuple e informazioni relative alla singola
relazione come numero attributi, tuple e un dettaglio degli attributi che
specifica nome e tipo di dati memorizzati. Ancora un’altra funzione, è quella
che offre risultati grafici delle valutazioni per mezzo di grafici a torta.
Una ulteriore funzione, relativa al documento XML che chiamiamo metadati misurazione, detta gestione dei metadati misurazione (descritti
nell’Appendice A), permette la gestione dei dati relativi alla lookup table
per l’accuratezza sintattica, all’associazione tra relazioni per la consistenza e
la frequenza media di aggiornamento per la currency. Le operazioni possibili
sono il caricamento e la creazione del documento, ma soprattutto l’aggiunta
di nuovi metadati o l’aggiornamento di quelli esistenti.
Infine, la funzione per la creazione di report completi, che creano per
la dimensione scelta un documento XML formattato con XSL, in cui sono
memorizzate le valutazioni di tutti gli elementi del database (relazioni, attributi e tuple), relative a quel particolare istante; una funzione di help e una
funzione di visualizzazione per il report parziale e i metadati misurazione.
Ovviamente, sono presenti le funzioni per la valutazione delle dimensioni ai diversi livelli di granularità, che tratteremo in modo approfondito
nei paragrafi successivi.
4.3.2
Struttura
Il framework è organizzato in due livelli, un livello di front-end in cui è presente quello che vede l’utente, ovvero l’interfaccia grafica con la sua struttura
fatta di menu, bottoni, aree di visualizzazione testuale e grafiche e molto altro che permette di accedere in maniera intuitiva e facile alle funzionalità
offerte. A livello di back-end, è presente la struttura portante, quella che ha
il compito più difficile e che costituisce il framework vero e proprio, costituita dagli algoritmi e dai dati utilizzati da essi, ma anche dai metadati, che
sono descritti in modo approfondito nell’Appendice A. Nel seguito forniamo
una descrizione delle principali classi Java che compongono il framework:
• MainWindow.java: è una classe fondamentale e realizza la GUI principale del framework.
• JDBCApp.java: realizza la GUI per la connessione al database.
CAPITOLO 4. REALIZZAZIONE DEL FRAMEWORK
49
• AddMetadata.java: realizza la GUI per la creazione di nuovi metadati
lookup table o aggiornamento di quelli esistenti.
• AddMetadataCurrency.java: realizza la GUI per la creazione di nuovi
metadati frequenza media o aggiornamento di quelli esistenti.
• CreateMetadata.java: crea il documento xml per i metadati misurazione.
• CreateXmlInc.java: crea il documento xml per i metadati dimensione.
• OpenBrowser.java: realizza la funzione di apertura del browser di
default.
• SearchLutAtt.java: ricerca all’interno dei metadati misurazione, la
lookup table per l’attributo.
• SearchLutRel.java: ricerca all’interno dei metadati misurazione, la
lookup table per la relazione.
• SearchMetadatiCurrency.java: ricerca all’interno dei metadati misurazione, la frequenza media di aggiornamento.
• Completeness.java: classe per l’implementazione delle metriche della
dimensione completezza.
• Currency.java: classe per l’implementazione delle metriche della dimensione currency.
• FrequencySynAcc.java: classe per l’implementazione della metrica della dimensione accuratezza sintattica dell’attributo, basata sulla frequenza dei valori.
• SyntacticAccuracy.java: classe per l’implementazione della metrica
della dimensione accuratezza sintattica dell’attributo, basata sulla lookup table.
• ConfigRecordLinkage.java: classe per la creazione della GUI relativa
alla configurazione dell’accuratezza sintattica di tuple e relazione.
• RecordLinkage.java: classe per l’implementazione della metrica dell’accuratezza sintattica di tuple e relazione.
4.4
Analisi Metriche Implementate nel Framework
In questo paragrafo verranno esplorate le quattro dimensioni considerate nel
framework, più precisamente per ognuna, verranno analizzate le metriche
implementate tramite gli algoritmi, attraverso una descrizione dettagliata
dei passi computazionali.
CAPITOLO 4. REALIZZAZIONE DEL FRAMEWORK
50
Figura 4.1: GUI del framework.
4.4.1
Completezza
La dimensione completezza è calcolata nei seguenti livelli di granularità:
• Relazione
• Attributo
• Tupla
La metrica è basata sull’assunzione del modello a valori nulli e rispetta la
closed world assumption CWA, spiegata in dettaglio nel Capitolo 2. La
valutazione della completezza avviene utilizzando una delle tre forme funzionali [4] (Simple Ratio, Min or Max Operation, Weighted Average), più
precisamente la Simple Ratio.
L’algoritmo utilizzato nel framework si basa sulla combinazione del modello a valori nulli, dell’assunzione CWA e della forma simple ratio.
Simple Ratio
La simple ratio, ovvero il rapporto semplice misura il rapporto tra i risultati
desiderati e il numero totale di risultati (prima forma); tuttavia una forma migliore è il numero di risultati non desiderati diviso il numero totale,
CAPITOLO 4. REALIZZAZIONE DEL FRAMEWORK
51
sottratto a uno (seconda forma). Il simple ratio aderisce alla convenzione
che 1 rappresenta il risultato migliore e 0 quello peggiore.
Le due forme di simple ratio, risultati non desiderati e risulati desiderati,
danno le stesse informazioni ma nella pratica si preferisce un rapporto che
mostra i risultati positivi, quindi la seconda forma, poichè questa forma è
utile per confronti longitudinali che mostrano tendenze di miglioramento.
Molte metriche di qualità dei dati assumono questa forma come ad esempio le metriche per le dimensioni free-of-error, consistency e completeness.
Altre dimensioni possono essere valutate usando questa forma, come concise
representation, relevancy e easy of manipulation.
Per quanto riguarda la completezza, questa dimensione può essere vista
da diverse prospettive che implicano metriche diverse. Ad un livello di massima astrazione, si può definire il concetto di completezza dello schema che
esprime il grado con cui entità e attributi risultano presenti nello schema.
Al livello dei dati si può definire la completezza della colonna come funzione
dei valori mancanti in una colonna della tabella. Un terzo tipo di metrica
è chiamata completezza della popolazione. Se una colonna deve contenere
almeno un’occorrenza di tutti i 50 possibili stati (valori), per esempio, ma
contiene solo 43 stati, abbiamo che la popolazione è incompleta. Ciascuna
di queste tre metriche può essere misurata tramite il rapporto tra il numero
di oggetti incompleti e il numero totale e successivamente sottraendolo a
uno.
Completezza Attributo
Dopo aver selezionato l’attributo della relazione sul quale effettuare la misurazione, l’algoritmo inizia la ricerca dei valori nulli: inizializza a zero un
contatore, per ogni tupla della relazione controlla il corrispondente valore
dell’attributo, se risulta nullo, incrementa il contatore. Al termine della
ricerca il contatore conterrà il numero di valori nulli relativi all’attributo.
Successivamente viene applicato il simple ratio, riportandoci alla terminologia, i valori nulli rappresentano i risultati non desiderati, il numero di tuple
della relazione il totale dei risultati; viene effettuato il rapporto tra i valori
nulli e il numero di tuple e dopo sottratto a uno. Il risultato è un valore
compreso tra 0 e 1 che viene espresso in percentuale moltiplicandolo per 100.
Questo tipo di completezza è chiamata anche completezza verticale.
In formula:
Nvn
CA = 1 −
Nt
dove CA è la completezza dell’attributo, Nvn è il numero di valori nulli e Nt
è il numero di tuple.
CAPITOLO 4. REALIZZAZIONE DEL FRAMEWORK
52
Completezza Relazione
Effettuata la scelta della relazione, l’algoritmo anche in questo caso ricerca
i valori nulli, però riferendosi all’intera relazione, infatti per ogni attributo
viene conteggiato il numero di valori nulli e poi effettuata una somma totale
che rappresenta il numero di valori nulli dell’intera relazione. A questo punto
viene utilizzata la prima forma del simple ratio, il rapporto è tra i risultati
desiderati, numero valori non nulli (ricavato dalla differenza tra il totale dei
valori e il numero di nulli), e il totale dei risultati ovvero il numero massimo
di valori che una relazione potenzialmente può contenere che corrisponde
alla grandezza della relazione data dal prodotto tra il numero di attributi
per il numero di tuple.
Questo tipo di completezza è chiamata anche completezza orizzontale.
In formula:
Nvnn
CR =
N
dove CR è la completezza della relazione, Nvnn è il numero di valori non
nulli e N è il numero massimo di valori possibili per la relazione.
Completezza Tupla
L’algoritmo, scelta la relazione, restituisce per ogni tupla il valore di completezza con una singola misurazione. Vediamo come lavora in dettaglio.
Prendiamo in considerazione il caso di una singola tupla, visto che il calcolo
si ripete in modo uguale sulle altre; la completezza è misurata tramite la
seconda forma del simple ratio. Prima di tutto vengono analizzati i valori di
tutti i campi della tupla e calcolato il numero di valori nulli, dopo viene effettuato il rapporto tra questo numero e il totale di attributi della relazione,
il rapporto viene poi sottratto a uno.
Facciamo alcune considerazioni. La misurazione effettuata dall’algoritmo
può essere vista come una misura dell’informazione contenuta attualmente,
rispetto alla massima informazione che una tupla potenzialmente può contenere, questo implica che tutti i valori della tupla contribuiscono allo stesso
modo nel determinare il valore di completezza ovvero tutti gli attributi hanno lo stesso peso, questo è il nostro caso ma è possibile che gli attributi
abbiamo pesi differenti e contribuiscano in modo diverso al risultato finale,
questo perchè un valore nullo in un attributo è più importante che in un
altro.
In formula:
Nvn
CT = 1 −
Na
dove CT è la completezza della tupla, Nvn è il numero di valori nulli e Na
è il numero di attributi.
CAPITOLO 4. REALIZZAZIONE DEL FRAMEWORK
4.4.2
53
Accuratezza Sintattica
La dimensione accuratezza, come è possibile notare dalla letterarura presente, si divide in accuratezza semantica e accuratezza sintattica. L’accuratezza
semantica spesso non è direttamente valutabile in quanto necessità di un confronto diretto con il mondo reale. L’accuratezza sintattica al contrario è più
facilmente valutabile, anche se la sua valutazione non è proprio diretta, nel
senso che, riferendoci al modello relazione, il risultato non è ottenibile analizzando i soli valori della relazione ma necessità di informazioni aggiuntive
che assumono un ruolo importante nella valutazione, come vedremo in seguito nel dettaglio degli algoritmi. Si è cercato di trovare algoritmi in grado
di svincolare la valutazione da queste informazioni aggiuntive ma sono state
trovate poche soluzioni alternative, la consultazione di queste informazioni
durante il calcolo per alcune metriche è indispensabile.
Definiamo meglio il concetto, dalla definizione di accuratezza sintattica
si capisce come si rende necessaria la presenza di un dominio di definizione D
in modo da poter calcolare la vicinanza tra un valore v e gli elementi del corrispondente dominio D. Dal punto di vista implementativo, il dominio può
essere visto come una sorgente dati di riferimento che viene consultata durante la valutazione, chiameremo questo dominio, LookUp Table, in modo
da mettere in evidenza la sua implementazione tramite tabelle relazionali e
la sua funzione di consultazione (dall’inglese lookup, consultare).
Funzioni di Similarità
E’ noto che le metriche per l’accuratezza sintattica si basano sull’utilizzo di
funzioni di similarità che valutano la distanza tra un valore v e gli elementi del dominio. Esistono molte funzioni [13], ad esempio distanza di edit,
distanza pesata, soundex, distanza con peso basato sulla frequenza e molte
altre, approfondiremo le funzioni esistenti nell’Appendice B, in questo paragrafo ci concentremo su due in particolare che sono utilizzate negli algoritmi:
la Jaro e la Soundex.
• Jaro: Introduce una funzione di confronto tra stringhe che tiene conto
di inserimenti, cancellazioni e trasposizioni. L’algoritmo di Jaro cerca
il numero di caratteri comuni e il numero di caratteri trasposti nelle due
stringhe. Un carattere comune è un carattere che appare in entrambe
le stringhe con una distanza pari alla metà della lunghezza della stringa
più corta. Un carattere trasposto è un carattere comune che appare
in posizioni differenti. Come esempio consideriamo le stringhe Smith
e Simth, ci sono cinque caratteri comuni, due dei quali sono trasposti.
La scala di confronto tra le stringhe per Jaro è data da:
f (s1 , s2 ) =
Nc
lengthS1
+
Nc
lengthS2
3
Nt
+ 0.5 N
c
CAPITOLO 4. REALIZZAZIONE DEL FRAMEWORK
54
dove s1 e s2 sono stringhe di lunghezza lengthS1 e lengthS2 rispettivamente, Nc è il numero di caratteri comuni tra le due stringhe (dove
la distanza per caratteri comuni è la metà della lunghezza minima di
s1 e s2 e Nt è il numero di trasposizioni).
• Soundex: Lo scopo della funzione soundex è quello di raggruppare
nomi che hanno suoni simili. Produce un codice, detto codice soundex.
Per esempio il codice soundex di Hilbert e Heilbpr è simile. Un codice
soundex contiene di regola quattro caratteri. La prima lettera del nome
diventa il primo carattere del codice, i restanti tre caratteri sono dati
dall’ordine sequenziale del nome, consultando una tabella predefinita.
Per esempio il codice soundex di Hilbert e Heilbpr è H416. Una volta
che il limite di quattro caratteri è raggiunto, le restanti lettere vengono
ignorate.
La Dimensione Accuratezza Sintattica è calcolata nei seguenti livelli di
granularità:
• Relazione
• Attributo
• Tupla
Accuratezza Sintattica Attributo
Per l’accuratezza sintattica dell’attributo sono state implementate due metriche, la prima si basa sul concetto di lookup table e la seconda sul concetto
di frequenza dei valori.
Per quanto riguarda la prima metrica, si assume che esista la lookup
table relativa all’attributo che si vuole dare in input all’algoritmo. La lookup
table assume una forma particolare influenzata dalle tecnologie utilizzate per
implementare il framework, utilizzando MySQL essa è defnita come una relazione composta da due campi: un campo chiave numerico, e un campo
contenente i valori che rappresentano gli elementi del dominio. Un esempio
di lookup table relativa al dominio dei nomi può essere:
Chiave
1
2
3
4
5
Nome Persona
Luca
Marco
Paolo
Giacomo
John
Dopo queste informazioni preliminari, vediamo in dettaglio l’algoritmo.
La prima operazione che viene effettuata è quella di dividere i valori dell’
CAPITOLO 4. REALIZZAZIONE DEL FRAMEWORK
55
attributo accurati da quelli non accurati (secondo la prima analisi), che saranno poi sottoposti ad un ulteriore analisi; ogni valore v dell’attributo viene
confrontato con tutti i valori v’ della lookup table, se risulta v = v’ allora v
può considerarsi accurato in quanto presente nel dominio, se v non corrisponde a nessun v’ allora entra a far parte dell’insieme dei valori non accurati, da
analizzare nuovamente. Su questo insieme facciamo una considerazione, esso
contiene quei valori v che evidentemente dopo la prima analisi non risultano
nel dominio, tutto quello che si può fare e una seconda analisi di vicinanza
di questi v a quelli del dominio, con la speranza che il più vicino sia il valore
che v vuole rappresentare con l’eccezione che v ha al suo interno degli errori sintattici. Riprendendo la descrizione, viene inizializzato e incrementato
un contatore per i valori non accurati. A questo punto entra in gioco la
funzione di similarità Jaro, ogni valore non accurato viene confrontato con
tutti i valori della lookup table tramite la funzione, per ogni confronto viene
restituito un valore di similarità compreso tra 0 e 1, tra tutti viene preso
il massimo valore di similarità e contemporaneamente viene memorizzato il
valore della lookup table più vicino. Questo procedimento viene ripetuto
per ogni valore non accurato, come detto in precedenza. Ogni valore non
accurato avrà quindi associato un valore di similarità e il relativo valore del
dominio più vicino.
Questo è un primo risultato che l’algoritmo restituisce, ovvero un accuratezza sintattica relativa ad ogni valore dell’attributo. Un secondo risultato è
relativo all’accuratezza dell’attributo nel suo complesso che viene calcolato
con la seconda forma del simple ratio, il rapporto tra il totale di valori non
accurati e il numero di tuple della relazione, sottratto a uno.
La seconda metrica è basata sulla frequenza dei valori e svincola completamente la valutazione dalla presenza di una lookup table per l’attributo.
Tutto quello che viene fatto è un’analisi dei valori con l’utilizzo questa volta
di due funzioni di similarità. Il dominio di definizione Df viene costruito
dall’algoritmo; non è un dominio di possibili valori per l’attributo, come ad
esempio, il dominio dei nomi di persona, ma è un dominio di confronto, ovvero un insieme costruito dall’algoritmo e utilizzato per confrontare i valori.
Procediamo con la descrizione.
Si analizzano i valori dell’attributo e per ognuno si contano le occorrenze; si passa alla creazione del dominio Df: i valori con numero di occorrenze
maggiore o uguale a 2 entrano a far parte di Df, i valori con numero di
occorrenze pari a 1, vengono considerati valori a bassa frequenza che indichiamo con vlf (low frequency value) e vengono analizzati. Ogni vlf viene
confrontato con ogni elemento di Df tramite la funzione di similarità Jaro;
ogni operazione di confronto restituisce un risultato e tra tutti questi viene
preso il massimo che indichiamo con maxsv (max similatity value) e contemporaneamente il valore di Df più vicino che chiamiamo vcl (close value).
Si analizza maxsv e se risulta maggiore di una soglia posta a 0.8, vlf risulta
accurato sintatticamente e può esser considerato un valore di Df ammissibi-
CAPITOLO 4. REALIZZAZIONE DEL FRAMEWORK
56
le. Se invece maxsv è minore o uguale a 0.80, vlf viene analizzato tramite
la funzione di similarità Soundex che prende come secondo argomento vcl.
Facciamo una considerazione sui valori di soglia 2 e 0.8. Il valore 2 che
permette di creare il dominio Df, è stato scelto in quanto si è pensato al
fatto che un valore, presente come minimo due volte, può esser considerato
“corretto”, invece se presente una volta può darsi che sia un valore uguale
a quelli presenti ma con errori al suo interno oppure un valore “corretto”.
Il valore 0.8 è frutto di prove sperimentali sulla funzione di distanza Jaro.
Abbiamo notato che con similarità uguali o superiori a 0.8, due valori possono esser considerati simili con buona probabilità, invece con valori minori
di 0.8 si ha una scarsa probabilità.
La scelta della funzione soundex non è casuale, proprio per le sue caratteristiche di raggruppare nomi con suoni simili, a questo stadio della misurazione in cui abbiamo dopo una prima analisi dei valori considerati non
accurati ma con una piccola probabilità che essi siano dei valori del dominio
con almeno uno o più errori sintattici, permette di scoprire con un margine
di errore accettabile se due valori rappresentano o meno lo stesso oggetto
del mondo reale, nel caso dei nomi, ad esempio, permette di arrivare alla
conclusione che palo e paolo sono lo stesso nome di una persona con nome
proprio paolo e che palo è un nome con un evidente errore sintattico. Quindi, la funzione soundex permette di verificare se vlf è vcl a meno di qualche
errore di accuratezza, oppure se vlf non è vcl e quindi vlf è accurato ed
un valore ammissibile di Df. Al termine dell’applicazione di questa seconda
funzione si avrà un insieme di valori non sintatticamente corretti.
Infine si procede col determinare il valore dell’accuratezza sintattica dell’attributo tramite la seconda forma del simple ratio che effettua il rapporto
tra il numero di valori non accurati e il numero totale di valori, sottratto a
uno.
Accuratezza Sintattica Tuple
La misurazione dell’accuratezza sintattica a questo livello di dettaglio si
differenzia molto dal livello dell’attributo, la metrica implementata si ispira
in gran parte alla metodologia ISTAT per la qualità dei dati toponomastici
nella pubblica amministrazione.
Inizialmente, l’algoritmo era stato creato in modo da implementare in
una forma più semplice la descrizione riportata nella metodologia, ma ci si
è accorti che l’algoritmo era troppo legato al caso specifico dei dati toponomastici e quindi si è cercata una forma di astrazione migliore in modo da
poter applicare l’algoritmo a dati che rientravano in casi più generali. La
soluzione trovata prevede due fasi, una prima fase di configurazione della
misurazione e una seconda che coincide con la misurazione vera e propria.
L’algoritmo si ispira alla tecnica del Record Linkage.
Il problema del Record Linkage, conosciuto anche come record mat-
CAPITOLO 4. REALIZZAZIONE DEL FRAMEWORK
57
ching o meglio object identification problem, consiste nell’identificare se due
record o tuple che non corrispondono tra loro accuratamente, possono tuttavia riferirsi allo stesso oggetto del mondo reale.
Per fare questo e per capire se due record in due database sono tra loro
equivalenti, si deve definire una funzione che misura la distanza tra i due
record; un caso, che è quello adattato nel framework, è che il record con
cui fare il confronto si trovi in una sorgente dati (relazione) diversa, che si
suppone contenga le stesse tuple, ma corrette. La indicheremo sempre con
il nome lookup table.
Un tipico algoritmo di record linkage si sviluppa nei seguenti passi:
1. Normalizzazione dei formati: riorganizza i record e i valori secondo un
formato standard e comune;
2. Blocking con riduzione dello spazio di ricerca;
3. Scelta della formula di distanza;
4. Per un campione di record già accoppiati, calcola per ogni valore di
distanza la frequenza di matching e non matching;
5. Scelta, a partire dalla distribuzione di cui al punto 4 di due distanze
di soglia min e max.
Prima Fase: Configurazione della misurazione
Ispirandoci alla tecnica del record linkage, come detto in precedenza si rende necessaria una lookup table, di fondamentale importanza per effettuare
il confronto. Con riferimento all’algoritmo sopra riportato, questa fase potrebbe definirsi anche di normalizzazione dei formati.
Nella prima versione dell’algoritmo la lookup table doveva assolutamente assumere la forma di una relazione identica a quella da valutare e contenente
i valori corretti.
Una considerazione può essere fatta a questo punto. La parola identica
implica che la lookuptable oltre a contenere gli stessi valori, però corretti,
deve avere anche la stessa struttura ovvero lo stesso numero di attributi e
perfino nello stesso ordine. Per svincolare la valutazione dalle strutture delle relazioni si è resa necessaria questa fase di configurazione, in cui definire
sia per la relazione che per la lookup table, gli attributi che comporanno la
struttura, tutti o un sottoinsieme e anche l’ordine; in questo modo l’utente
non deve avere una lookup table identica ma simile e può adattare la struttura di una all’altra.
Facciamo un esempio, prendiamo in considerazione il caso degli indirizzi,
data la seguente relazione
CAPITOLO 4. REALIZZAZIONE DEL FRAMEWORK
ID
1
Tipo
Corso
Nome
Vittorio Emanuele
Città
Milano
58
Provincia
Mi
nel caso di lookup table identica, l’algoritmo per funzionare dovrebbe consultare una relazione come la seguente
Key
1
Dug
Corso
Name
Vittorio Emanuele
Comune
Milano
Provincia
Mi
notiamo che i vincoli per il corretto funzionamento sono: ugual numero
e stesso ordine di attributi. Il nome degli attributi è irrilevante. Altro vicolo
importante è che anche la chiave primaria delle relazioni deve essere la stessa
ovvero dello stesso tipo, ad esempio numerica (Integer), questo molto spesso
non è possibile.
Con la procedura di configurazione, la misurazione diventa più flessibile e
possono essere prese in considerazione diverse strutture di lookup table. Facciamo alcuni esempi
TipoNome
Corso Vittorio Emanuele
Città
Milano
Provincia
Mi
oppure
ID
3
Indirizzo
Corso Vittorio Emanuele Milano Mi
Inoltre, con la prima versione non era possibile scegliere un sottoinsieme
di attributi ma, bisognava considerare tutti gli attributi della relazione, inclusa la chiave primaria. Al contrario, con la seconda versione è possibile far
si che i campi che compongono la tupla non siano tutti, ma un sottoinsieme
scelto.
Seconda Fase: Misurazione
L’algoritmo, che è stato sviluppato per verificare il grado di vicinanza di una
tupla con la tupla corrispondente nella lookup table, si articola nei seguenti
passi:
1. si concatenano in un unico campo, dopo aver rimosso gli spazi vuoti,
tutti i valori degli attributi della tupla da valutare e si effettua la medesima operazione per la tupla della lookup table. La rimozione degli
spazi vuoti serve ad evitare eventuali problemi connessi ai differenti
formati di acquisizione delle informazioni in fase di inserimento, che
possono anche non prevedere la possibilità d’includere spazi;
2. si definisce una lunghezza prefissata, ad esempio 3, e si individuano
nella stringa (ottenuta al passo 1) della tupla della lookup table tutte
CAPITOLO 4. REALIZZAZIONE DEL FRAMEWORK
59
le sottostringhe di tale lunghezza costituite da sequenze consecutive
di caratteri. Tale operazione viene effettuata anche per la tupla da
valutare.
3. si pone pari a 0 uno specifico contatore. Si adotta un algoritmo di
tipo sequenziale. Si considera la prima delle sottostringhe (identificate al passo 2) della tupla della lookup table e la si confronta in
modo sequenziale con ciascuna delle sottostringhe della tupla da valutare. Ogni volta che si verifica l’uguaglianza delle sottostringhe si
incrementa di uno un contatore. La sequenza viene iterata per la seconda sottostringa della tupla della lookup table, fino a considerare
l’ultima sottostringa. Ad ogni iterazione viene aggiornato il valore del
contatore;
4. l’indicatore complessivo di accuratezza sintattica per la generica tupla
i è ottenuto come rapporto tra il valore del contatore, calcolato al
passo precedente, e il numero di sottostringhe della tupla della lookup
table identificate al passo (2).
Facciamo una considerazione sulla lunghezza delle sottostringhe, che nel
framework è uguale a 3. Ispirandosi alla metodologia ISTAT, questo valore
è uguale a quello utilizzato nella metodologia. Ma la lunghezza in questione è
quella ottimale nel caso di dati toponomastici, ricavata da una serie di analisi
empiriche. Nel nostro caso non è propriamente ottimale ma al contempo
non sottostima l’accuratezza effettiva (la definizione della lunghezza ottima
richiede uno studio lungo e approfondito), infatti in alcuni casi, vengono
assegnati punteggi elevati di accuratezza per alcune tuple, che superano il
100%; ma questo inconveniente è stato superato in fase di visualizzazione
e report dei risultati, considerando inaccurate le tuple con valori minori di
100%.
I passi precedentemente descritti vengono effettuati per ogni tupla della
relazione, che viene confrontata con ogni tupla della lookup table. Come
valore di accuratezza sintattica viene preso il massimo valore prodotto dalla
serie dei confronti e allo stesso tempo viene tenuta traccia della tupla della
lookup table che è più vicina. Al termine dell’esecuzione dell’algoritmo si
avrà un insieme di tuple sintatticamente accurate, con valore pari al 100%
e un insieme di tuple non accurate, dove ognuna avrà il proprio valore di
accuratezza e la relativa tupla della lookup table più vicina.
Accuratezza Sintattica Relazione
La valutazione dell’accuratezza sintattica a questo livello di granularità, è
identica alla misurazione per le tuple, con un calcolo aggiuntivo. La procedura per le tuple, abbiamo detto che restituisce un insieme di tuple non
accurate, si considera la cardinalità di tale insieme ovvero il numero di tuple
CAPITOLO 4. REALIZZAZIONE DEL FRAMEWORK
60
non accurate della relazione e lo si divide per il numero totale di tuple, sottraendo il tutto a uno. Quello appena descritto non è altro che la seconda
forma del simple ratio.
4.4.3
Currency
Ricordiamo la definizione di currency. Essa misura con quale tempestività i
dati sono aggiornati. La currency è una proprietà intrinseca di un dato.
Da uno studio della letteratura presente, è possibile notare che esistono
due metriche principali per valutare la dimensione. La prima si basa su metadati, dati che descrivono i dati veri e propri fornendo informazioni di tipo
temporale. La seconda metrica è basata su una relazione tra periodi temporali; quest’ultima è sicuramente molto più complessa, in quanto necessita
di molte informazioni temporali.
Concentriamoci sulla metrica basata sui metadati, in paritcolare sul last
update metadata che corrisponde all’ultima volta in cui lo specifico dato è
stato aggiornato. Una prima misura è il ritardo temporale tra l’evento del
mondo reale e la sua registrazione nel sistema informativo, molto complessa
e costosa in quanto spesso l’evento non è noto. Una seconda misura, più
semplice, è la differenza rispetto al last update metadata. In base al metadato
di ultimo aggiornamento è possibile distinguere due tipi di dati:
1. dati con periodicità di aggiornamento nota: per questi dati è nota
una data precisa di aggiornamento ed è quindi possibile calcolare la
currency in maniera esatta.
2. dati con periodicità di aggiornamento media: per questi dati è nota una
frequenza media di aggiornamento, ad esempio in giorni, e in questo
caso è possibile calcolare con errore una currency media.
Nel seguito considereremo, il secondo tipo di dati, in quanto per il primo tipo
conoscere l’esatta data di aggiornamento è molto difficile e per alcuni dati
impossibile, ad esempio per un campo indirizzi di una relazione impiegati
di un’azienda, che esprime l’indirizzo di residenza dell’i-esimo impiegato,
prevedere a priori l’esatta data in cui cambierà residenza e quindi indirizzo
è impossibile, invece si puo definire una frequenza media in base alla quale
gli indirizzi cambiano ogni 6 anni. La Dimensione Currency è calcolata al
solo livello di granularità:
• Attributo
Nell’implementazione delle metriche per la currency assumono un ruolo
importante i seguenti metadati:
1. last update metadata: implementato tramite un campo di tipo Timestamp in MySQL. Da una ricerca fatta sia sulle classi Java per
CAPITOLO 4. REALIZZAZIONE DEL FRAMEWORK
61
l’interfacciamento con i database e la gestione dei dati e metadati,
sia sulle istruzioni di MySQL, si è arrivati alla conclusione che l’unico
modo per creare, aggiornare e leggere il metadato relativo all’ultimo
aggiornamento di un valore è la presenza di un attributo di tipo Timestamp nella relazione del database MySQL. Infatti il Timestamp
di MySQL è un tipo di dato dedicato alla gestione delle date nel formato più completo e ha una caratteristica molto particolare: questo
tipo di dato è impiegato come una sorta di timbro temporale, nelle
applicazioni reali il contenuto del campo viene quasi sempre riempito
automaticamente con il valore dell’ “istante corrente”, ossia una data
completa di minuti e secondi che si riferisce ad:“adesso”, “ora”.
Questo permette di registrare un valore che fa riferimento al momento in cui è avvenuta la memorizzazione del record corrente oppure
un’aggiornamento del record stesso. Il valore del campo timestamp si
riferisce quindi alla tupla e dal punto di vista degli attributi questo
vuol dire che tutti hanno il medesimo valore timestamp e quindi lo
stesso last update. L’inconveniente è che se viene aggiornato il valore
di un attributo A per una tupla, il valore di timestamp cambierà e il
cambiamento si avrà anche per un altro attributo B della stessa tupla
sul quale però non sono state fatte modifiche sui valori.
2. metadato frequenza media aggiornamento: implementato registrando la coppia (nome attributo, valore frequenza media) nel documento xml, metadati misurazione.
Currency Attributo
Gli algoritmi realizzati restituiscono come output della misurazione un valore
che può essere current o not current, che esprime semplicemente se l’attributo su cui è stata effettuata la valutazione, può considerarsi aggiornato
oppure no.
Gli algoritmi implementano tre metriche, definite:
1. metrica basata su frequenza media metadati
2. metrica basata su frequenza media ricavata
3. metrica basata sull’ultimo aggiornamento
Un operazione comune ai tre algoritmi è la ricerca all’interno della relazione
di cui fa parte l’attributo sul quale valutare la currency, del campo di tipo
timestamp. Se quest’ultimo non è presente viene creato automaticamente
dall’algoritmo e i suoi valori aggiornati per ogni tupla all’istante corrente,
ovvero con la data e ora attuale; con l’evoluzione dei dati presenti nel database, quindi con le operazioni di modifica (inserimento, aggiornamento e
CAPITOLO 4. REALIZZAZIONE DEL FRAMEWORK
62
cancellazione) ai record della relazione, i valori del campo timestamp non saranno più tutti uguali, ma inizieranno a differenziarsi, assumendo dei valori
più adatti alla valutazione della currency.
Iniziamo con la descrizione della metrica basata su frequenza media
metadati. La prima operazione che viene effettuata è la ricerca dell’attributo timestamp, se trovato, vengono analizzati i suoi valori alla ricerca del
massimo che rappresenta l’ultimo aggiornamento dell’attributo. Successivamente viene effettuata una differenza tra il valore massimo e l’istante corrente in modo da determinare il periodo, in giorni, dell’ultimo aggiornamento
che indichiamo con period. Con una funzione di ricerca nel documento xml
metadati misurazione, viene estratta la frequenza media di aggiornamento
dell’attributo espressa in giorni che indichiamo con fm. A questo punto viene effettuato il confronto tra period e fm, se period è minore o uguale a fm
l’attributo può considerarsi current, invece se period è maggiore di fm l’attributo può considerarsi not current. Ad esempio, se fm=12 giorni, vuol dire
che l’attributo rimane current per 12 giorni, dopo i quali dovrebbe essere
aggiornato, quindi se controllando, risulta che non viene aggiornato da 13
giorni (period), è considerato not current; se invece risulta period 8 giorni,
ad esempio, è considerato current.
La metrica basata su frequenza media ricavata è simile alla precedente, con l’eccezione che il metadato relativo alla frequenza media di
aggiornamento non è memorizzato da nessuna parte, ma viene ricavato a
runtime con il seguente calcolo:
i valori del campo timestamp vengono ordinati utilizzando un algoritmo di
ordinamento, più precisamente il bubble sort. Successivamente viene effettuata una differenza a due a due in modo sequenziale in base all’ordinamento
stabilito, le differenze parziali vengono sommate tra loro. Al termine del ciclo di differenze viene effettuato il rapporto tra la somma e il numero totale
di valori del campo timestamp. Il quoziente esprime la frequenza media
dell’attributo. Ad esempio se per un attributo e-mail si hanno tre valori di
timestamp, già ordinati, ovvero:
...
e-mail
[email protected]
[email protected]
[email protected]
timestamp
31/12/2005
08/01/2006
20/01/2006
le differenze effettuate sono:
• (08/01/2006) − (31/12/2005) = 8 giorni
• (20/01/2006) − (08/01/2006) = 12 giorni
viene eseguita la somma 8 + 12 = 20 giorni, e successivamente il rapporto
20
3 = 6 giorni. Quindi la frequenza media di aggiornamento per l’attributo
e-mail è 6 giorni.
CAPITOLO 4. REALIZZAZIONE DEL FRAMEWORK
NumeroCorso
01
02
03
04
Docente
Rossi
Bianchi
Giorgi
Crispi
63
Corso
Chimica
Fisica
Analisi
Algoritmi
Tabella 4.1: Relazione corsi di studio.
NumeroEsame
01
02
03
04
Esame
Fisca
Chimica
Analisi
Algortmi
Data
24-09-2006
12-09-2006
05-09-2006
27-09-2006
Tabella 4.2: Relazione esami.
Infine, la metrica basata sull’ultimo aggiornamento consiste nell’effettuare una ricerca del massimo tra i valori del campo timestamp. Il
valore massimo rappresenta l’ultimo aggiornamento dell’attributo e viene
restituito dall’algoritmo come output.
4.4.4
Consistenza
La consistenza, tra le dimensioni analizzate, è quella per cui esiste un minor numero di metriche in letteratura. La valutazione della consistenza è
associata, spesso, al numero di violazioni di regole semantiche che nel modello relazionale si traduce con le violazioni dei vincoli di integrità. Nel
framework, viene implementata una metrica che riguarda la violazione dei
vincoli interrelazionali (vincoli su relazioni differenti), con il caso specifico
della violazione dei vincoli di integrità referenziale. La misura può essere
effettuata ad un livello di granularità che coincide con il livello dell’attributo, se si considera un singolo attributo, ma anche di tuple se vengono
presi in considerazione più attributi per mezzo della fase di configurazione.
Consideriamo il livello dell’attributo, l’idea è quella di confrontare i valori di
un attributo A con i valori di un altro attributo B che si suppone contenga
gli stessi valori di A, in quanto B rappresenta lo stesso concetto del mondo
reale di A. Ad esempio, consideriamo una relazione Corsi di studio e Esami
mostrate in tabella 4.1 e 4.2, rispettivamente. L’attributo Corso della relazione Corsi di studio e Esame della relazione Esami, dovrebbero contenere
gli stessi valori dal momento che rappresentano entrambi l’insieme dei corsi
di studio di una facoltà universitaria. Vediamo i passi eseguiti dall’algoritmo per raggiungere il risultato. Prima di tutto le relazioni vengono associate
l’una all’altra, inserendo le coordinate di connessione (user, password, host,
port, nomedatabase) della relazione non apparenente al database connesso,
CAPITOLO 4. REALIZZAZIONE DEL FRAMEWORK
64
nei metadati misurazione; dopo aver scelto l’attributo sia di una che dell’altra relazione, attraverso una finestra di configurazione come quella descritta
per l’accuratezza sintattica delle tuple e relazione, vengono confrontati i
valori degli attributi con lo stesso algoritmo dell’accuratezza delle tuple, ovvero per mezzo del record matching e visualizzati i valori incosistenti con
la relativa percentuale e valore corretto. Tornando all’esempio precedente,
supponendo sia connesso il database contenente la relazione Esami, ad essa
viene associata la relazione Corsi di studio e eseguito l’algoritmo sugli attributi Esame e Corso. Dopo l’esecuzione, i valori inconsistenti risulteranno
essere Fisca e Algortmi in quanto tra i valori dell’attributo Corso, non esiste
nessun corso che abbia questi due nomi e vengono forniti i valori più vicini
che nell’esempio sono Fisica e Algoritmi.
L’esempio riportato, è relativo ad attributi che non sono chiave (primaria
o esterna) delle relazioni. Se la valutazione viene effettuata tra due attributi
K e Kf di due relazioni A e B diverse (sulle quali è realizzato un vincolo di
integrità referenziale), che sono chiave primaria (K) di A e esterna (Kf) di
B, allora si sta valutando la consistenza sul vincolo di integrità referenziale,
caso particolare dei vincoli interrelazionali.
4.5
Localizzazione e Correzione di Errori
Nell’ambito delle attività e delle tecniche per la DQ, è presente un attività
in particolare, relativa alla localizzazione e correzione degli errori. Questa
attività si rende utile ogni volta che si ha un insieme di dati proveniente da
una fonte di cui non si è certi dell’affidabilità. Gli errori nei dati possono
essere espressi, l’abbiamo visto nel Capitolo 2, attraverso un gran numero di
dimensioni; per alcune sono state fornite delle metriche di valutazione, per
altre come la consistenza, sono stati presentati dei modelli formali che caratterizzano la dimensione. I metodi di localizzazione e correzione dipendono
dal tipo di dimensione che si vuole analizzare e valutare.
4.5.1
Il Framework: Attività di Localizzazione e Correzione
Il framework svolge principalmente un’attività di assessment della qualità,
la fase successiva alla valutazione corrisponde a quella di miglioramento
(improvement) attraverso la localizzazione e correzione degli errori che degradano la qualità dei dati. Il framework svolge un attività di localizzazione
e correzione degli errori per alcune dimensioni implementate, ovvero contemporaneamente alla misurazione vengono localizzati gli errori e le relative
correzioni; ad esempio nel misurare l’accuratezza sintattica dell’attributo,
viene restituito il valore di accuratezza in percentuale e allo stesso tempo
l’insieme di valori non accurati e i relativi valori del domino più vicini, con
i quali i valori inaccurati potrebbero essere corretti.
CAPITOLO 4. REALIZZAZIONE DEL FRAMEWORK
65
In particolare, vedremo in dettaglio il caso, (i) per l’accuratezza sintattica dell’attributo con la metrica basata sulla frequenza dei valori, (ii) per
l’accuratezza sintattica dell’attributo con la metrica che utilizza la lookup
table, (iii) per l’accuratezza sintattica delle tuple con la metrica che utilizza
la lookup table e (iv) per la consistenza. La correzione implementata è una
proposta di possibile miglioramento che viene visualizzata ma non eseguita
e quindi memorizzata. Nel seguito verranno descritte per ogni dimensione
le localizzazioni e le proposte di possibili correzioni attualmente presenti nel
framework.
Accuratezza Sintattica
Nella misurazione dell’ accuratezza sintattica dell’attributo con la metrica
basata sulla frequenza dei valori, per ogni valore dell’attributo con frequenza bassa (frequenza relativa minore di 2) che risulta non accurato, secondo
la prima metrica di similarità Jaro, viene proposto un valore del “dominio
ricavato” (insieme di valori dell’attributo con frequenza relativa maggiore o
uguale a 2) che è il più vicino, per la seconda funzione di similarità Soundex,
al valore inaccurato. Chiariamo con un esempio. Supponiamo di avere una
relazione Impiegati illustrata in tabella 4.3,
NumeroImpiegato
0100
0200
0300
0400
0500
0600
0700
Nome
Jack
Jack
Paolo
Paolo
Palo
Steve
Paolo
Cognome
Murphy
Bauer
Rossi
Bianchi
Bow
Barrow
Baggio
email
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
Tabella 4.3: Relazione Impiegati
eseguiamo l’algoritmo sull’attributo Nome, il “dominio ricavato” è illustrato
in tabella 4.4, ed è l’insieme dei valori di Nome il cui numero di occorrenze
è maggiore o uguale a 2 (frequenza relativa maggiore o uguale a 2), ed è
utilizzato per il confronto tramite le funzioni di similarità; è differente dal
dominio dell’attributo Nome, insieme dei nomi, valori possibili che l’attributo può assumere.
Dominio Ricavato
Jack
Paolo
Frequenza Relativa
2
3
Frequenza Assoluta
2/7
3/7
Tabella 4.4: Dominio Ricavato dell’Attributo Nome
CAPITOLO 4. REALIZZAZIONE DEL FRAMEWORK
66
I valori dell’attributo con frequenza bassa sono Palo e Steve, ma solo Palo
risulta avere problemi di accuratezza, invece Steve è un valore possibile del
dominio. Appurato il problema di qualità l’algoritmo suggerisce che il valore
del dominio più vicino a Palo è Paolo e quindi una possibile correzione può
essere apportata. Una snapshot generica del framework è mostrata in figura
5.2.
Figura 4.2: Accuratezza sintattica attributo, metrica frequenza valori.
Nella misurazione dell’ accuratezza sintattica dell’attributo con la metrica
basata sull’utilizzo della lookup table, per ogni valore dell’attributo che non
appartiene al dominio dei possibili valori, rappresentato dalla lookup table,
quindi con probabili errori di accuratezza viene effettuato un confronto con
gli elementi del domino, tramite la funzione di similarità Jaro, per ricavare
il valore di accuratezza e il valore del dominio più vicino. Una snapshot del
framework è mostrata in figura 5.3.
Figura 4.3: Accuratezza sintattica attributo, metrica lookup table.
Nella misurazione dell’ accuratezza sintattica delle tuple con la metrica basata sull’utilizzo della lookup table, ogni tupla viene confrontata con le tuple
CAPITOLO 4. REALIZZAZIONE DEL FRAMEWORK
67
della lookup table e per tutte quelle non accurate viene fornito il valore
di accuratezza e la relativa tupla corretta. Una snapshot del framework è
mostrata in figura 5.4.
Figura 4.4: Accuratezza sintattica tuple.
CAPITOLO 4. REALIZZAZIONE DEL FRAMEWORK
68
Consistenza
Ricordiamo che la dimensione consistenza implementata nel framework, verifica la violazione di vincoli interrelazionali effettuando un confronto tra
valori per definire quelli consistenti e inconsistenti. Ad esempio, su due
attributi di relazioni diverse che si suppone debbano contenere ugual valori, viene eseguito il confronto tra i valori dell’uno con i valori dell’altro
e determinato un insieme di valori che non corrispondono tra loro, e per
ognuno viene fornito il valore di consistenza e il valore corretto. Una snapshot del framework è mostrata in figura 5.5, che mostra la misurazione su
due attributi e-mail, contenenti in teoria gli stessi valori, di relazioni diverse, riscontrando un valore inconsistente, fornendo la valutazione e il valore
corretto.
Figura 4.5: Consistenza
Capitolo 5
Caso di Studio
In questo capitolo, descriviamo l’attività di testing effettuata sul framework.
Per fare questo abbiamo bisogno di un database di dimensioni tali da poter
testare in modo soddisfacente il lavoro, quindi con un numero di relazioni, attributi e tuple sufficientemente ampio per la verifica, che permetta di
valutare tutte le metriche implementate in modo da costituire un caso di
studio per il framework. E’ stato scelto come DBMS di appoggio per la
memorizzazione del database, il DBMS MySQL [19].
Premettiamo che cercare un database da testare, in rete o da altre fonti è un compito molto difficile, ovviamente parliamo di database reali e di
dimensioni non banali; è raro che vengano creati e popolati grandi database con il solo scopo di esser testati (è un lavoro inutile e dispendioso), i
database sono popolati con dati reali e non fittizzi, frutto di eventi del mondo reale e contenengono dati sensibili che non possono essere resi pubblici.
Inoltre per i pochi database che sono disponibili sorge un altro problema,
ovvero i dati presenti sono “puliti” e questo implica che essi debbano essere
“sporcati” per poter analizzare e rilevare problemi di qualità. Proprio per
questo, per la valutazione di alcune dimensioni, i dati sono stati modificati
o sono stati creati i metadati utili alla misurazione. In particolare, per la
completezza non si è resa necessaria alcuna modifica, al contrario per l’accuratezza sintattica, per la currency e la consistenza, per le quali si sono
rese necessarie attività di alterazione dei dati e creazione dei metadati. Nel
seguito, analizzeremo in dettaglio le singole misurazioni.
Lo scopo del test del framework, non è quello di analizzare la performance del programma. Non importa la determinazione della capacità del
programma di svolgere più o meno velocemente, quel particolare compito
per cui è stato progettato. L’obiettivo è la valutazione dei risultati restituiti dal framework relativi ad una base di dati, in modo da analizzare la
correttezza dell’output e il funzionamento degli algoritmi.
Dopo molte ricerche in rete, abbiamo trovato una base di dati, che verrà
descritta nel seguito.
69
CAPITOLO 5. CASO DI STUDIO
5.1
70
Descrizione del Caso di Studio
Il database utilizzato è stato recuperato dal sito web di Eclipse-BIRT (Business Intelligence Reporting Tools) [18]. Il database rappresenta una compagnia fittizia: Classic Models Inc., la quale acquista, direttamente dai fornitori, modelli da collezione di automobili, treni, autobus e navi, e li vende
ai distributori di tutto il mondo. Il database contiene tipici dati di business come quelli relativi ai clienti, gli ordini, il singolo ordine e prodotti.
Il database è fornito sotto i termini di licenza di Eclipse.org Software User
Agreement.
Vediamo in dettaglio come è costituito. Si compone di otto relazioni:
1. Offices: rappresenta gli uffici di Classic Models Inc. L’azienda ha
sette uffici sparsi su tutto il globo (San Francisco, Boston, NYC, Paris,
Tokyo, Sydney, London), con il suo quartier generale a San Francisco in
California. In base alla posizione geografica, ciascun ufficio è assegnato
ad un territorio di vendita (APAC, NA, EMEA or JAPAN).
2. Employees: rappresenta tutti gli impiegati, inclusi gli addetti alle vendite che hanno relazioni con i customers. L’azienda ha 23 impiegati:
6 dirigenti esecutivi e 17 addetti alle vendite. Questi ultimi sono assegnati a un numero preciso di clienti (distributori) nelle loro rispettive
aree geografiche di vendita. I nuovi addetti alle vendite (ancora in
tirocinio) non hanno clienti assegnati. Ciascun addetto alle vendite
ha relazioni con il manager delle vendite della sua area. I dirigenti
esecutivi sono: Presidente, VP Sales, VP Marketing, Sales Manager
(JAPAN, APAC), Sales Manager (EMEA), Sales Manager (NA).
3. Customers: rappresenta i clienti. Classic Models Inc. ha 122 clienti
in tutto il mondo.
4. Orders: rappresenta gli ordini effettuati dai clienti. I clienti ordinano e attendono la ricezione approssimativamente in 6-10 giorni. Una
volta effettuato l’ordine, viene spedito in 1-6 giorni (7-8 per il Giappone). C’è un totale di 326 ordini, che coprono l’arco di tempo dal
1/1/2003 al 6/1/2005. Gli ordini possono essere in uno dei seguenti
stati: In lavorazione (lo stato iniziale per tutti gli ordini), Spedito, Annullato (usato per indicare che il cliente ha effettuato l’annullamento
subito dopo l’ordine e tipicamente prima che sia spedito), Non gradito
(usato per indicare che il cliente ha ricevuto l’ordine ma non lo gradisce), Bloccato (usato per indicare che l’ordine non sarà spedito prima
del pagamento perché il limite di accreditamento del cliente è stato
oltrepassato). Circa il 93% degli ordini sono in stato di spedito.
5. Order Details: rappresenta i dettagli relativi agli ordini.
CAPITOLO 5. CASO DI STUDIO
71
6. Payments: rappresenta i pagamenti effettuati dai clienti. In media, i pagamenti vengono effettuati 2-3 settimane dopo la ricezione
dell’ordine.
7. Products: rappresenta i prodotti venduti dall’azienda, ovvero i modelli
in scala. Ci sono 110 modelli, acquistati da 13 fornitori. I modelli
sono classificati in 7 linee distinte di prodotti: Classic Cars, Vintage
Cars, Motorcycles, Trucks and Buses, Planes, Ships, Trains. Inoltre,
i modelli sono classificati in base alla loro scala di dimensione, ad
esempio 1:18 o 1:72.
8. Product Lines: rappresenta i dettagli di ognuna delle 7 linee di prodotti. A ciascuna è associata una descrizione testuale, una in formato
html e un’immagine.
Il database è costituito da 8 relazioni, 59 attributi e 3864 tuple. Lo schema
Entità Relazione del database è mostrato in figura 5.1.
5.2
Analisi dei Risultati
In questo paragrafo analizzeremo i risultati ottenuti dall’esecuzione del framework sul database presentato, descrivendo le alterazioni effettuate per
“sporcare” i dati e commentando i risultati ottenuti.
Nella valutazione della dimensione completezza non si sono rese necessarie modifiche dei dati presenti nel database. Osservando le relazioni, abbiamo preso in considerazione quelle con un numero sufficiente di valori nulli,
per poter eseguire la misurazione. Partiamo dalla valutazione della completezza dell’attributo, più precisamente di state appartenente alla relazione
customers. Il valore ottenuto corrisponde al 40% di completezza, questo
vuol dire che i valori completi (non nulli) sono presenti con una percentuale
del 40%, invece quelli non completi (nulli) con una percentuale del 60%. Per
verificare il risultato, applichiamo la formula:
Nvn
CA = 1 −
Nt
dove CA è la completezza dell’attributo, Nvn è il numero di valori nulli e Nt
è il numero di tuple; osservando i valori dell’attributo otteniamo Nvn = 73 e
Nt = 122 e effettuando il calcolo risulta 0.40, in percentuale 40%. Il calcolo
effettuato manualmente, mostra come la metrica implementata restituisca
un valore esatto di completezza; quanto riportato è solo uno dei molteplici
test effettuati, sono stati considerati altri attributi di diverse relazioni e il
framework ha riposto sempre con risultati coerenti.
Per la completezza della relazione, più precisamente di customers,
il valore ottenuto corrisponde al 12%, questo vuol dire che i valori completi
CAPITOLO 5. CASO DI STUDIO
Figura 5.1: Schema Entità-Relazione Classic Models Inc.
72
CAPITOLO 5. CASO DI STUDIO
73
(non nulli) sono presenti con una percentuale del 88%, invece quelli non
completi (nulli) con una percentuale del 12%; questo perchè nella metrica
viene utilizzata la prima forma del simple ratio. Per verificare il risultato,
applichiamo la formula:
Nvnn
CR =
N
dove CR è la completezza della relazione, Nvnn è il numero di valori non nulli
e N è il numero di valori possibili per la relazione; osservando direttamente
i valori otteniamo Nvn = 202 e N = 1586 e effettuando il calcolo risulta
0.12, in percentuale 12%. Il calcolo effettuato manualmente, mostra come
la metrica implementata restituisca un valore esatto di completezza; quanto
riportato è solo uno dei molteplici test effettuati, sono state considerate altre
relazioni e il framework ha restituito sempre risultati coerenti.
Per la completezza della tuple, più precisamente della relazione offices, il valore di completezza è calcolato per ogni tupla della relazione, tramite
la formula:
Nvn
CT = 1 −
Na
dove CT è la completezza della tupla, Nvn è il numero di valori nulli e Na è il
numero di attributi. Non verifichiamo manualmente tutti i calcoli effettuati
dal framework. Comunque viene restituito un valore di completezza che
esprime la percentuale di tuple complete e non complete, in particolare il
57% di tuple non complete e il 43% di tuple complete. La snapshot della
misurazione effettuata è mostrata in figura 5.2.
Descriviamo di seguito, la misurazione dell’accuratezza sintattica ad ogni
livello di granularità. Per questa dimensione sono state effettuate modifiche
dei dati. Per l’accuratezza sintattica dell’attributo tramite la metrica basata sulla frequenza dei valori è stata eseguita la misurazione
sull’attributo contactFirstName di customers. L’attributo in questione, ha
come dominio di valori, quello dei nomi di persona che nel nostro caso sono
i nomi dei clienti della compagnia; sono stati modificati alcuni nomi in modo da poter effettuare la misurazione. Vediamoli in dettaglio. Per i valori
Juri, Jean, Steve sono stati introdotti i seguenti errori: Jurri, Jan, Stve,
l’inserimento di una r in Juri, la cancellazione di una e in Jean e ancora
l’eliminazione di una e in Steve. Il framework, come ci si aspettava, ha restituito l’insieme dei valori inaccurati dell’attributo e gli elementi di questo
insieme sono proprio quelli in cui sono stati inseriti errori di accuratezza,
ovvero Jurri, Jan, Stve. La percentuale di accuratezza ottenuta è del 97%,
quindi solo il 3% di valori sono inaccurati, infatti la cardinalità dell’insieme di valori non accurati è molto piccola, pari a 3. Una snapshot della
misurazione descritta è mostrata in figura 5.3.
Per l’accuratezza sintattica dell’attributo tramite la metrica basata sulla lookup table è stato misurato l’attributo city della relazione
offices. Per eseguire la valutazione è stata creata un lookup table di valori
CAPITOLO 5. CASO DI STUDIO
Figura 5.2: Completezza Tuple Relazione offices
Figura 5.3: Accuratezza Attributo contactFirstName
74
CAPITOLO 5. CASO DI STUDIO
75
corretti e sono state inserite le sue coordinate nei metadati misurazione. La
lookup table rappresenta il dominio dei nomi di città e sono stati modificati
i valori San Francisco, New York, Tokyo in Sa Francisco, NY, Tokio contenenti errori sintattici. Dalla misurazione, come atteso, questi tre valori
risultano inaccurati e per ognuno viene fornita la percentuale di accuratezza
e il valore più vicino della lookup table, possibile valore corretto. L’accuratezza sintattica dell’attributo è, 57% di valori accurati e 43% di valori
inaccurati. La snapshot è mostrata in figura 5.4.
Figura 5.4: Accuratezza Attributo city
Per l’accuratezza sintattica delle tuple tramite la metrica basata sul record linkage è stata valutata sulla relazione employees. E’
stata creata la lookup table relativa (e inserite le coordinate nei metadati
misurazione) ed è stato inserito un errore nella tupla con chiave (employeeNumber ) 1619. Dalla misurazione è risultato che l’unica tupla inaccurata
è quella con chiave 1619, con un’accuratezza del 97%. L’accuratezza totale
delle tuple è 95% di tuple accurate e 5% di tuple non accurate. Questo
test, ha utilizzato una lookup table con una struttura uguale alla relazione
employees e sono stati selezionati tutti gli attributi della singola tupla, eccetto la chiave primaria. Questo stesso esempio è stato utilizzato anche per
l’accuratezza sintattica della relazione tramite la metrica basata
sul record linkage, ottenendo un valore del 5% di record non accurati
CAPITOLO 5. CASO DI STUDIO
76
e 95% di record accurati. Per quanto riguarda le tuple è stato effettuato
un altro test, con una lookup table avente struttura diversa e selezionando
un sottoinsieme (grazie alla fase di configurazione dell’algoritmo). In particolare, gli attributi selezionati sono lastName, firstName della relazione
employees e l’attributo FirstLastName della lookup table, contenente in un
unico campo le due informazioni nome e cognome dell’impiegato. I risultati
ottenuti sono 5% di tuple inaccurate e 95% di tuple accurate. Una snapshot
dell’accuratezza sintattica delle tuple è mostrata in figura 5.5, ed è relativa
al caso con lookup table uguale e con la selezione di tutti gli attributi.
Figura 5.5: Accuratezza Tuple Relazione employees
Vediamo i test effettuati per la dimensione currency. Come detto nel
Capitolo 4, sono state implementate tre metriche (sono state testate le due
più importanti), per ognuna si rende necessario il campo timestamp sulla
relazione da valutare, per questo è stata scelta la relazione offices e di questa l’attributo phone ed è stato inserito un campo timestamp con dei valori
utili alla misurazione. Per la metrica basata sulla frequenza media
metadati è stato inserito nei metadati misurazione, per l’attributo scelto,
il valore 14 giorni che rappresenta la frequenza media di aggiornamento.
I risultati ottenuti sono: ultimo aggiornamento dell’attributo 24 giorni fa,
dal confronto risulta not current, in quanto l’attributo phone deve essere
aggiornato ogni 14 giorni (ovvero rimane current per 14 giorni), ma l’ulti-
CAPITOLO 5. CASO DI STUDIO
77
mo aggiornamento risale a 24 giorni fa (rispetto alla data di misurazione),
quindi con dieci giorni di ritardo rispetto alla sua frequenza media. Per
la metrica basata sulla frequenza media ricavata, i risultati ottenuti sono: ultimo aggiornamento dell’attributo 24 giorni fa, frequenza media
ricavata 12 giorni, dal confronto risulta not current per le stesse considerazioni del caso precedente. Una snapshot, relativa alla metrica basata sulla
frequenza media metadata, è mostrata in figura 5.6.
Figura 5.6: Currency Attributo phone
CAPITOLO 5. CASO DI STUDIO
78
Infine per la consistenza, è stato effettuato un test per verificare le
violazioni ai vincoli di integrità referenziale tra la relazione products e la
relazione orderdetails sull’attributo chiave primaria productCode della prima e l’attributo chiave esterna productCode della seconda. Nei metadati
misurazione sono state inserite le coordinate della relazione orderdetails e
nella relazione products sono stati inseriti dei valori di chiave non presenti
nel productCode di orderdetails. I risultati ottenuti sono coerenti a quanto ipotizzato, visto che i valori di chiave di products, S18 3233 e S85 3212
vengono considerati violazione al vincolo di chiave esterna, in quanto presentano dei codici prodotti che non compaiono nella relazione orderdetails.
Una snapshot della valutazione è mostrata in figura 5.7.
Figura 5.7: Consistenza Attributo productCode
Appendice A
Descrizione del Metamodello
In quest’appendice verrà descritta la struttura del metamodello utilizzato
dal framework. Per maggior chiarezzza e per evitare possibili confusioni
tra i concetti chiariamo prima di tutto la differenza tra dato e metadato,
successivamente il concetto di metamodello.
I dati, come riportato nel Capitolo 1, sono utili alla rappresentazione
dei concetti del mondo reale e sono elementi di informazione costituiti da
simboli che debbono essere elaborati per fornire informazioni. Ad esempio
consideriamo un libro, oggetto del mondo reale, le stringhe il vecchio e il
mare e Ernest Hemingway sono dati che interpretati nel contesto di un
libro danno informazioni circa il titolo e l’autore del libro.
Un metadato è un termine che viene utilizzato in svariati contesti come
il web o l’information retrieval, ed è definito in molti modi diversi. Dalla
letteratura presente [8]:
• un metadato è un dato che descrive un altro dato, ad esempio il dato
12345 senza un contesto non ha significato, se invece viene associato
un nome (metadato) significativo come Codice Postale, 12345 assume
un significato preciso.
• un metadato è un informazione circa un dato.
• un metadato è un informazione circa un informazione.
Continuando con l’esempio del libro, consideriamo la scheda di una biblioteca, del libro il vecchio e il mare, supponiamo contenga i dati area 5, scaffale
2 che danno informazioni circa la posizione e in prestito che fornisce informazioni circa lo stato del libro. I dati della scheda appena descritti sono in
relazione con i dati del libro per il fatto che i primi sono metadati dei secondi, ovvero sono dati riguardanti i dati che si riferiscono al libro, e forniscono
informazioni sullo stato e la posizione del libro il vecchio e il mare di Ernest
Hemingway.
79
APPENDICE A. DESCRIZIONE DEL METAMODELLO
80
Chiariti i concetti di dato e metadato, vediamo il concetto di metamodello. Il metamodello, da noi definito, è inteso come modello di metadati.
Per spiegare meglio, facciamo un’analogia con il modello dei dati.
Un modello dei dati [14] è un insieme di concetti utilizzati per organizzare i dati di interesse e descriverne la struttura in modo che essa risulti
comprensibile ad un elaboratore. Nella progettazione di basi di dati vengono
utilizzati due modelli di dati, il modello concettuale e il modello logico.
• Modello Concettuale: Descrive i concetti del modo reale piuttosto che
i dati utili a rappresentarli. Esso viene utilizzato nella fase preliminare
del processo di progettazione di basi di dati, per analizzare nel modo
migliore la realtà di interesse, senza “contaminazioni” di tipo realizzativo. Il modello concettuale per eccellenza è il modello Entità-Relazioni
(E/R).
• Modello Logico: Le strutture utilizzate da questo modello, pur essendo
astratte, riflettono una particolare organizzazione (ad albero, a grafi,
a tabelle o a oggetti). Esistono molti modelli logici tra cui modello gerarchico, modello reticolare, modello a oggetti, ma il più diffuso
è il modello relazionale. I modelli logici sono disponibili sui DBMS
commerciali.
Quindi, i dati rappresentanti un concetto del mondo reale vengono rappresentati prima con un modello concettuale, con i costrutti del modello E/R
e successivamente organizzati con il modello logico, con il costruttore relazione del modello relazionale. La relazione permette di organizzare i dati in
insiemi di record a struttura fissa ed è rappresentata per mezzo di una tabella, le cui righe rappresentano specifici record e le cui colonne corrispondono
ai campi del record. I dati, dunque, vengono rappresentati e organizzati per
mezzo di modelli.
I metadati, sono comunque dei dati (su altri dati), e anch’essi possono
esser rappresentati e organizzati utilizzando modelli, più precisamente metamodelli. Il metamodello concettuale per i metadati può essere ancora il
modello E/R, invece il metamodello logico può essere un documento XML.
Infatti un documento XML ha una struttura gerarchica ad albero che segue il cosiddetto DOM (Document Object Model). I metadati assumono un
organizzazione gerarchica.
In conclusione il metamodello (modello dei metadati) utilizzato nel framework, si articola in modello E/R, come modello concettuale e XML, come
modello logico. I modelli utilizzati per i dati e i modelli per i metadati sono
mostrati in figura A.1.
Nei paragrafi successivi vengono descritti i dati e metadati utilizzati nel
framework, viene introdotto il linguaggio XML e descritto in dettaglio il
metamodello del framework.
APPENDICE A. DESCRIZIONE DEL METAMODELLO
81
Figura A.1: Modelli dei dati e metadati
A.1
Descrizione dei Dati e Metadati
Vedendo il framework come una blackbox, in modo da notare le relazioni
esistenti tra i dati e gli algoritmi, si possono distinguere flussi di dati in
input e in output.
A.1.1
Dati-Metadati in Input
I dati, sono quelli strutturati presenti nelle tabelle del database relazionale
a cui ci si connette, sono questi i dati su cui viene misurata la qualità. I metadati sono utilizzati nelle misurazioni di alcune dimensioni e costituiscono
informazioni aggiuntive che vengono consultate. Vediamoli meglio. Per la
dimensione accuratezza sintattica a livello degli attributi sono necessari dei
metadati per portare a termine la misurazione, più precisamente le coordinate per raggiungere la lookup table, composte dalle tipiche informazioni
di connessione ad un database MySQL, considerato che la lookup table è
una relazione gestita da questo DBMS. Per l’accuratezza sintattica di tuple
e relazioni sono necessarie le stesse informazioni aggiuntive. Infine, un ultimo metadato presente è relativo alla dimensione currency di un attributo e
consiste nel valore di frequenza media di aggiornamento, espressa in giorni.
A questi metadati dati ci riferiremo con il termine metadati misurazione.
APPENDICE A. DESCRIZIONE DEL METAMODELLO
82
Figura A.2: Dati e Metadati del Framework
A.1.2
Dati-Metadati in Output
Il principale dato in output del framework è il risultato della misurazione,
valore della dimensione di qualità misurata ad un certo livello di granularità. Ad esempio misurando la completezza di un attributo, otteniamo il
40% di completezza, questo valore è il dato in output. I metadati danno
informazioni aggiuntive sulla misurazione effettuata. Ad esempio, nel caso
della completezza dell’attributo, i metadati sono il nome dell’attributo, la
data della misurazione, la metrica utilizzata e il valore risultante. A questi
metadati dati ci riferiremo con il termine metadati dimensione.
A.2
XML
Per l’insieme di metadati descritti in precedenza, come già detto, si è deciso di utilizzare il modello logico dei documenti XML, per rappresentarli e
organizzarli. Vediamo quindi il linguaggio di marcatura descrittiva XML.
A.2.1
Vantaggi Derivanti dall’Utilizzo di XML
Un primo vantaggio deriva dall’obiettivo di XML, il quale per definizione è
un linguaggio di markup utilizzato per descrivere i dati. Questo vuol dire
APPENDICE A. DESCRIZIONE DEL METAMODELLO
83
che dati normalmente non strutturati con XML possono essere strutturati
e assumere una forma più rigorosa. XML è il linguaggio principale per
rappresentare dati semi-strutturati.
XML è un insieme di regole (linee guida o convenzioni) per formulare
dei file in formato testo che permettano di strutturare i dati. XML rende
facile la generazione di dati tramite un computer, la lettura dei dati e il
controllo sulla struttura in modo che non sia ambigua. XML è estensibile,
indipendente dalla piattaforma e supporta i parametri internazionali e locali.
Inoltre è pienamente compatibile con Unicode.
E’ un linguaggio nato per sostituire in futuro il noto HTML, quindi molto
utile allo scambio e alla fruibilità dei dati sul web. Concludendo, XML è
utile alla gestione dei dati sia in ambiente web sia in altri ambienti che non
riguardano la rete.
A.2.2
Cenni ad XML
L’XML, acronimo di eXtensible Markup Language, è un linguaggio di markup descrittivo creato e gestito dal World Wide Web Consortium (W3C).
È una semplificazione e adattamento dell’SGML, da cui è nato nel 1998, e
permette di definire la grammatica di diversi linguaggi specifici derivati.
Può esser considerato il naturale successore di HTML come linguaggio
per il web, in quanto più espressivo e flessibile, complicato ma con la qualità di apportare molto più aiuto agli sviluppatori nel proprio lavoro. Non
sostituisce HTML in quanto hanno differenti obiettivi: XML è utile per
descrivere i dati e progettato per l’interscambio di essi; HTML invece è utilizzato per la visualizzazione dei dati e si concentra sulle informazioni di
layout. I due linguaggi sono complementari in quanto XML rappresenta il
contenuto, l’insieme di dati e HTML gli aspetti di presentazione dei dati e
navigazione tra essi.
Un documento XML, è costruito per mezzo di tag che non sono predefiniti dal linguaggio, definirli è compito dell’autore del documento, che decide
quindi la struttura utilizzando la DTD.
Un documento è costituito da:
• un prologo (opzionale) composto da:
– una dichiarazione XML
– una DTD
• un’istanza di documento, contenente
– testo libero
– elementi delimitati da etichette
– attributi associati ad elementi
APPENDICE A. DESCRIZIONE DEL METAMODELLO
84
– entità
– sezioni CDATA
– istruzioni di processamento
– commenti
DTD Document Type Definition
DTD è il linguaggio che specifica le caratteristiche del tipo di documento
attraverso una serie di regole grammaticali. In particolare definisce l’insieme
degli elementi del documento XML, le relazioni gerarchiche tra gli elementi,
l’ordine di apparizione nel documento e quali elementi e quali attributi sono
opzionali o meno. Una DTD descrive la struttura di un documento XML.
Accesso ad un documento XML
Il linguaggio XML non comprende nessuna istruzione di elaborazione (neanche di visualizzazione), necessita di un applicazione che elabori il documento.
Per questo è accessibile da qualsiasi linguaggio di programmazione Web (sia
lato server che lato client) o meno. Il fatto che questi dati saranno accessibili,
in una semplice struttura, a qualsiasi tipo di applicazione, locale o remota,
fanno dell’XML uno standard che si caratterizza per la sua portabilità.
L’accesso ad una struttura XML può avvenire attraverso diversi sistemi, il
più comune ma rudimentale è lo sfruttamento del filesystem del server su
cui gira il motore del linguaggio in uso. Ogni linguaggio ha poi dei suoi
componenti di tipo ActiveX oppure delle classi native per l’accesso ad una
struttura XML: Microsoft, ad esempio, mette a disposizione di ASP e di
Visual Basic l’oggetto XMLDOM (acronimo di XML Document Object Model) mentre altri come Java e PHP hanno, rispettivamente, delle classi e dei
packages dedicati allo scopo.
A.3
Metamodello del Framework
Il framework utilizza un insieme di documenti XML per rappresentare, strutturare e gestire i metadati descritti nel paragrafo A.1. Vediamo i dettagli
dei documenti relativi ai metadati misurazione e metadati dimensione.
A.3.1
Metadati Misurazione
Iniziamo dal documento dei metadati misurazione, che rappresenta i dati
delle lookup table per l’accuratezza sintattica e delle frequenze medie di
aggiornamento per la currency.
Riportiamo la DTD del documento xml:
APPENDICE A. DESCRIZIONE DEL METAMODELLO
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ATTLIST
rel CDATA
att CDATA
>
85
DATABASE (RELAZIONE?,CURRENCY?)>
RELAZIONE ( NOMEREL, LOOKUPTABLE?, ATTRIBUTO?)>
NOMEREL (#PCDATA)>
ATTRIBUTO (NOMEATT, LOOKUPTABLE? )>
NOMEATT (#PCDATA)>
LOOKUPTABLE (USER, PSW, HOST, DB, NOMELUT)>
USER (#PCDATA)>
PSW ANY>
HOST (#PCDATA)>
DB (#PCDATA)>
NOMELUT (#PCDATA)>
CURRENCY (VALORE)>
VALORE (#PCDATA)>
CURRENCY
#IMPLIED
#IMPLIED
Consideriamo un’istanza del documento XML e descriviamone la struttura.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE DATABASE SYSTEM "metadati.dtd">
<DATABASE>
<RELAZIONE>
<NOMEREL>movies</NOMEREL>
<LOOKUPTABLE>
<USER>root</USER>
<PSW></PSW>
<HOST>localhost</HOST>
<DB>lookuptable</DB>
<NOMELUT>movies_lut</NOMELUT>
</LOOKUPTABLE>
<ATTRIBUTO>
<NOMEATT>title</NOMEATT>
<LOOKUPTABLE>
<USER>root</USER>
<PSW></PSW>
<HOST>localhost</HOST>
<DB>lookuptable</DB>
<NOMELUT>title_lut</NOMELUT>
</LOOKUPTABLE>
</ATTRIBUTO>
</RELAZIONE>
<CURRENCY att="#remake" rel="movies">
<VALORE>200</VALORE>
APPENDICE A. DESCRIZIONE DEL METAMODELLO
86
</CURRENCY>
</DATABASE>
Tralasciando la dichiarazione XML e il collegamento alla DTD, sono presenti degli elementi che cerchiamo di approfondire sulla base di un esempio
di utilizzo del framework. Supponiamo che tramite l’opportuna funzione sia
stato connesso un database che contiene la relazione movies, supponiamo
anche che nello stesso database o in un qualunque altro ci sia la lookup table, realizzata in MySQL, di tale relazione. Si vuole misurare l’accuratezza
sintattica della relazione o delle tuple, il ponte di collegamento tra movies
e la sua lookuptable è costituito dai dati presenti nel documento XML. Infatti dalla lettura del documento si nota che a movies è associata la lookup
table le cui coordinate MySQL per connettersi e recuperarla sono date dagli
elementi USER, PSW, HOST, DB, NOMELUT. Supponiamo ancora che la
relazione movies contenga un attributo title di cui si vuole calcolare l’accuratezza sintattica ed ha un dominio associato, la lookup table che rappresenta
il dominio è raggiungibile con i dati degli elementi USER, PSW, HOST,
DB, NOMELUT associati a title. Infine, supponiamo si voglia calcolare la
currency, con l’opportuna metrica, dell’attributo #remake sempre appartenente alla relazione movies, i dati presenti nell’elemento CURRENCY più
precisamente il contenuto di VALORE rappresenta la frequenza media di
aggiornamento, in giorni, ed esprime il fatto che i valori di #remake variano con una frequenza media di 200 giorni; questo dato è utilizzato nel
determinare il valore della currency.
I dati presenti nel documento XML, vengono recuperati, dopo una fase
di accesso e ricerca con opportune classi create ad hoc, ed utilizzati dagli
algoritmi che implementano le metriche.
A.3.2
Metadati Dimensione
Vediamo come sono descritti attraverso il modello concettuale e come sono
organizzati tramite il modello logico, i metadati dimensione.
Modello Concettuale
Quando si presenta il compito di rappresentare problematiche di data quality, precisamente dimensioni relative ai valori dei dati, i modelli dei dati
tradizionali non sono più sufficienti e bisogna quindi estenderli per adattarli
a questo scopo.
Per quanto riguarda i dati strutturati, i modelli che vengono estesi sono
il modello Entità Relazione per la fase concettuale e il modello Relazionale
per la fase logica. D’altra parte per i dati semistrutturati [9], si utilizza
un modello per associare valori di qualità a dati rappresentati in documenti
XML.
APPENDICE A. DESCRIZIONE DEL METAMODELLO
87
Il modello chiamato Data and Data Quality model (D2 Q) è utilizzato
nel contesto di un cooperative information system (CIS). In tali sistemi le
organizzaioni cooperanti hanno bisogno di scambiarsi dati ed è quindi importante essere attenti alla qualità di tali dati. Le organizzazioni possono
utilizzare il (D2 Q) model per certificare la qualità dei loro dati in termini
di accuratezza, consistenza, completezza e currency. Il modello è semistrutturato e permette a ciascuna organizzazione di esportare la qualità dei loro
dati con un certo grado di flessiblità. I valori delle dimensioni di qualità
possono essere associati ai vari elementi del modello dati, da un singolo valore a un intera sorgente dati. Le principali caratteristiche del (D2 Q) model
sono:
• Un classe di dati e uno schema di dati: sono introdotte per rappresentare il dominio dei dati del (D2 Q) model.
• Una classe di qualità e uno schema di qualità: corrispondono alla
porzione di qualità del (D2 Q) model.
• Una funzione di associazione della qualità: che si riferisce ai nodi del
grafo relativo allo schema di dati e ai nodi del grafo relativo alla qualità
dello schema.
Il (D2 Q) model può essere facilmente tradotto in un modello dati XML.
Questo è importante per il requisito di interoperabilità dei sistemi cooperanti.
Quello appena descritto è un modello generale per associare valori di
qualità ai dati semistrutturati, ritornando al nostro caso, si è utilizzato come
modello per lo schema concettuale, il modello Entità-Relazioni. Lo schema
è mostrato in figura A.3:
Modello Logico
La DTD del documento XML è:
<!ELEMENT DATABASE (NOMEDB , NUMTAB ,(COMPLETEZZA)+ ,(ACCURATEZZA)+,
(CURRENCY)+, (CONSISTENZA)+ )>
<!ELEMENT NOMEDB (#PCDATA)>
<!ELEMENT NUMTAB (#PCDATA)>
<!ELEMENT COMPLETEZZA (DATA, METRICA,(RELAZIONE|ATTRIBUTO|TUPLE),
VALORE?)>
<!ELEMENT TUPLE ((TUPLA)+)>
<!ATTLIST TUPLE nomerel CDATA #IMPLIED>
<!ELEMENT TUPLA (ID ,VALORE)>
<!ELEMENT ID (#PCDATA)>
<!ELEMENT VALORE (#PCDATA)>
<!ELEMENT DATA (#PCDATA)>
APPENDICE A. DESCRIZIONE DEL METAMODELLO
88
Figura A.3: Schema Entità-Relazione Metadati Dimensione
<!ELEMENT METRICA (#PCDATA)>
<!ELEMENT RELAZIONE (#PCDATA)>
<!ATTLIST RELAZIONE nomerel CDATA #IMPLIED>
<!ELEMENT ATTRIBUTO (#PCDATA)>
<!ATTLIST ATTRIBUTO nomerel CDATA #IMPLIED>
<!ELEMENT ACCURATEZZA (DATA, METRICA,(RELAZIONE|ATTRIBUTO|TUPLE),
VALORE?,LOOKUPTABLE?)>
<!ELEMENT LOOKUPTABLE EMPTY>
<!ATTLIST LOOKUPTABLE
user CDATA #IMPLIED
password CDATA #IMPLIED
host CDATA #IMPLIED
db CDATA #IMPLIED
nomelut CDATA #IMPLIED
>
<!ELEMENT CURRENCY (DATA,METRICA,ATTRIBUTO,VALORE)>
<!ELEMENT CONSISTENZA (DATA, METRICA,TUPLE,LOOKUPTABLE?)>
Consideriamo un’istanza non completa del documento XML, per motivi di
lunghezza e chiarezza del documento.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE DATABASE SYSTEM "reportParziale.dtd">
<DATABASE>
APPENDICE A. DESCRIZIONE DEL METAMODELLO
89
<NOMEDB>basi</NOMEDB>
<NUMTAB>5</NUMTAB>
Nella prima parte del documento ci sono dati relativi al nome del database
a cui il modello logico si riferisce e al numero di relazioni appartenenti ad
esso. I frammenti del documento successivi, riguardano possibili misurazioni che possono essere effettuate nel utilizzare il framework. Quindi diamo
degli esempi per ognuna delle quattro dimensioni analizzate: completezza,
accuratezza sintattica, currency e consistenza.
<COMPLETEZZA>
<DATA>Mercoledi 10 Gennaio 2007 19:14:20</DATA>
<METRICA>CWA null value</METRICA>
<RELAZIONE nomerel="movies">movies</RELAZIONE>
<VALORE>12 %</VALORE>
</COMPLETEZZA>
<COMPLETEZZA>
<DATA>Mercoledi 10 Gennaio 2007 19:14:45</DATA>
<METRICA>CWA null value</METRICA>
<ATTRIBUTO nomerel="movies">Director</ATTRIBUTO>
<VALORE>75 %</VALORE>
</COMPLETEZZA>
Misurando la completezza di una relazione, di un attributo o delle tuple
vengono creati degli elementi con dei dati che danno informazioni sulla data
di esecuzione della misurazione, sulla metrica utilizzata, sul livello di granularità (relazione, attributo, tuple), sul nome della relazione o attributo e
infine sul valore risultato della valutazione.
<ACCURATEZZA>
<DATA>Mercoledi 10 Gennaio 2007 19:22:03</DATA>
<METRICA>LookUp Table</METRICA>
<RELAZIONE nomerel="indirizzi">indirizzi</RELAZIONE>
<VALORE>39 %</VALORE>
<LOOKUPTABLE db="Lut" host="localhost" nomelut="indirizziset"
password="" user="root"/>
</ACCURATEZZA>
Per l’accuratezza sintattica, come è possibile notare, vengono memorizzati
gli stessi dati come nel caso della completezza, ma con l’aggiunta dei dati
relativi alla lookup table utilizzata per eseguire la misurazione.
<CURRENCY>
<DATA>Giovedi 11 Gennaio 2007
17:23:45</DATA>
APPENDICE A. DESCRIZIONE DEL METAMODELLO
90
<METRICA>FREQUENZA MEDIA METADATI</METRICA>
<ATTRIBUTO nomerel="indirizzi_currency">citta</ATTRIBUTO>
<VALORE>Not Current</VALORE>
</CURRENCY>
Nel caso della currency, essa è misurata solo sugli attributi, è presente un’informazione definita nell’attributo XML nomerel che lega l’attributo alla propria relazione. Sono presenti i dati relativi alla data, metrica, nome attributo
e valore misurazione.
<CONSISTENZA>
<DATA>Giovedi 11 Gennaio 2007 18:33:51</DATA>
<METRICA>Integrita referenziale</METRICA>
<TUPLE nomerel="esami">
<TUPLA>
<ID>sistemi informativi</ID>
<VALORE>88 %</VALORE>
</TUPLA>
<TUPLA>
<ID>algoritmi</ID>
<VALORE>100 %</VALORE>
</TUPLA>
<TUPLA>
<ID>basi di dati</ID>
<VALORE>55 %</VALORE>
</TUPLA>
</TUPLE>
<LOOKUPTABLE db="Lut" host="localhost" nomelut="esami_lut"
password="" user="root"/>
</CONSISTENZA>
Infine la parte del modello dedicata alla consistenza, memorizza per ogni
valore esaminato il corrispondente risultato, ad esempio il valore sistemi informativi di un ipotetico attributo corso dal confronto è risultato essere non
del tutto consistente con l’altro valore presente in un attributo corso di studio, e quindi siccome i due attributi dovrebbero avere le stesse informazioni
si nota un evidente problema di consistenza.
Appendice B
Funzioni di Similarità
B.1
Principali Funzioni di Similarità
Le funzioni di similarità, specialmente quelle relative al confronto tra stringhe, vengono elencate nel seguito. Vediamo le principali. Alcune, precisamante la Jaro e la Soundex sono state approfondite nel Capitolo 4, in quanto
utilizzate nel framework.
• Distanza di Edit: La distanza di edit tra due stringhe A e B è il numero minimo di modifiche per trasformare una stringa A in B o viceversa.
Per una modifica si intende l’inserimento, la cancellazione o la sostituzione di un carattere. A ciascuna di queste modifiche è assegnato
un costo. Per esempio, assumiamo che i costi di inserimento e cancellazione siano pari ad 1, la distanza di edit tra due stringhe Smith e
Sitch è 2, in quanto Smith è ottenuta inserendo m e cancellando c da
Sitch.
• Distanza di Hamming: La distanza di Hamming conta il numero di
discrepanze tra due numeri. Per esempio, il codice di Hamming tra
00185 e 00155 è 1.
• Smith-Waterman: L’algoritmo di Smith-Waterman, date due sequenze, utilizza la programmazione dimamica per trovare il più basso costo
per convertire una stringa in un’altra. I costi per i singoli inserimenti
e cancellazioni sono i parametri dell’algoritmo.
• n-grams, bi-grams, q-grams: La funzione di distanza n-grams forma
l’insieme di tutte le sottostringhe di lunghezza n perp
ciascuna
strinP
′ − f ′′ |
ga. La distanza tra le due stringhe è definita come:
|f
s
∀x s
dove fs′ e fs′′ sono il numero di occorrenze delle sottostringhe x nelle
due stringhe s′ e s′′ , rispettivamente. La funzione Bi-grams (n=2) è
largamente utilizzato e è efficacie, con minori errori tipografici.
91
92
APPENDICE B. FUNZIONI DI SIMILARITÀ
I q-grams posizionali sono ottenuti slittando di una finestra di lunghezza q i caratteri di una stringa s.
• TF-IDF: Il Token Frequency-Inverse Document Frequency (TF-IDF)
o cosine similarity per il confronto di stringhe simili nei documenti.
L’idea di base è assegnare un peso alto ai token che appaiono frequentemente in un documento (TF weight), e assegnare un peso basso ai
token che appaiono frequentemente in un intero insieme di documenti
(IDF weight). Per un termine i in un documento j il peso wi,j è:
wi,j = (tf i, j) × log(
N
)
dfi
dove tf i, j è il numero di occorrenze di i in j, dfi è il numero di
documenti contenenti i e N è il numero totale di documenti. La similarità tra due documenti è dopo calcolata con il coseno tra i loro
rispettivi vettori con i termini di peso. Più precisamente, essendo
V = {w1 , ..., wn } e U = {w1 , ..., wn } i vettori con i pesi, la similarità è:
V ·U
|V | · |U |
Per completezza d’informazione, riportiamo nuovamente anche la Jaro e la
Soundex:
• Jaro: Introduce una funzione di confronto tra stringhe che tiene conto
di inserimenti, cancellazioni e trasposizioni. L’algoritmo di Jaro cerca
il numero di caratteri comuni e il numero di caratteri trasposti nelle due
stringhe. Un carattere comune è un carattere che appare in entrambe
le stringhe con una distanza pari alla metà della lunghezza della stringa
più corta. Un carattere trasposto è un carattere comune che appare
in posizioni differenti. Come esempio consideriamo le stringhe Smith
e Simth, ci sono cinque caratteri comuni, due dei quali sono trasposti.
La scala di confronto tra le stringhe per Jaro è data da:
f (s1 , s2 ) =
Nc
lengthS1
+
Nc
lengthS2
Nt
+ 0.5 N
c
3
dove s1 e s2 sono stringhe di lunghezza lengthS1 e lengthS2 rispettivamente, Nc è il numero di caratteri comuni tra le due stringhe (dove
la distanza per caratteri comuni è la metà della lunghezza minima di
s1 e s2 e Nt è il numero di trasposizioni).
• Soundex: Lo scopo della funzione soundex è quello di raggruppare
nomi che hanno suoni simili. Produce un codice, detto codice soundex.
Per esempio il codice soundex di Hilbert e Heilbpr è simile. Un codice
soundex contiene di regola quattro caratteri. La prima lettera del nome
APPENDICE B. FUNZIONI DI SIMILARITÀ
93
diventa il primo carattere del codice, i restanti tre caratteri sono dati
dall’ordine sequenziale del nome, consultando una tabella predefinita.
Per esempio il codice soundex di Hilbert e Heilbpr è H416. Una volta
che il limite di quattro caratteri è raggiunto, le restanti lettere vengono
ignorate.
Bibliografia
[1] Carlo Batini, Monica Scannapieco. Data Quality: Concepts, Methodologies and Techniques. Springer, 2006.
[2] Thomas C. Redman. Data Quality For The Information Age. Artech
House, 1996.
[3] Fellegi I.P., Sunter A.B. A Theory for Record Linkage. Journal of the
American Statistical Association, vol. 64, 1969.
[4] Pipino L.L., Lee Y.W., Wang R.Y. Data Quality Assessment.
Communications of the ACM, vol.45, no.4, 2002.
[5] Wang R.Y., Strong D.M. Beyond Accuracy: What Data Quality Means
to Data Consumers. Journal of Management Information System, vol.12,
no.4, 1996.
[6] Nielsen J. Usability Engineering. Academic Press, 1993.
[7] Dix A., Finley J., Abowd G., Beale R. Human-Computer Interaction.
Second Edition. Prentice Hall, 1998.
[8] William R. Durrell. Data Administration: A Practical Guide to Data
Administration. McGraw-Hill, 1985
[9] Storey V., Wang R. Extending the ER Model to Represent Data Quality Requirements. Data quality (R. Wang, M. Ziad, and W. Lee, eds.),
Kluver Academic Publishers, 2001.
[10] F. De Amicis, D. Barone, C. Batini. An Analytical Framework To
Analyze Dependencies Among Data Quality Dimension. ICIQ - 11th
International Conference on Information Quality, November 2006.
[11] Shankaranarayan G.R., Wang R.Y., Ziad M. Modeling the Manufacture
of an Information Product with IP-MAP. Conference on Information
Quality. Massachussets Institute of Technology, 2000.
[12] Ballou D.P., Wang R.Y, Pazer H., Tayi G.K. Modeling Information Manufacturing Systems to determine Information Product Quality.
Management Science, vol.44, no.4, 1998.
94
BIBLIOGRAFIA
95
[13] G. Navarro. A Guided Tour of Approximate String Matching. ACM
Computing Surveys 31 (2001), 31-88.
[14] Atzeni P., Ceri S., Paraboschi S., Torlone R. Basi di dati: Modelli e
linguaggi di interrogazione. McGraw-Hill, 2002.
[15] Wand Y., Wang, R.Y. Anchoring data quality dimensions in ontological
foundations. Communication of ACM, vol. 39, no. 11, 1996.
[16] Wang R.Y. A Product Perspective on Total Data Quality Management.
Communication of the ACM, vol. 41, no. 2, 1998.
[17] Diane M. String, Yang W. Lee, Richard Y. Wang. Data Quality in
Contex. Communication of the ACM, vol. 40, no. 5, 1997.
[18] Eclipse Birt, http://www.eclipse.org/birt/phoenix/.
[19] MySQL, http://www.mysql.com/.
[20] Eclipse, http://www.eclipse.org/.
[21] XML, http://www.w3.org/XML/.
[22] SWT: The Standard Widget Toolkit, http://www.eclipse.org/swt/.
[23] Java, http://java.sun.com/.
[24] JDBC, http://java.sun.com/javase/technologies/database/index.jsp.
[25] SimMetrics, http://www.dcs.shef.ac.uk/ sam/stringmetrics.html.
[26] JFreeChart, http://www.jfree.org/jfreechart/.
[27] BrowserLauncher2, http://sourceforge.net/projects/browserlaunch2/.
[28] Data Warehousing Institute, http://www.dw-institute.com/.