DW-MasterOpenKnowTechDaDistribuire [modalità compatibilità]

Outline
Data quality: problemi e
soluzioni
Data quality:
L. Palopoli, F. Fassetti
Master OpenKnowTech
Aprile 2010
Richiami su ETL, integrazione e riconciliazione
Identificazione e fuzzy matching e tecniche di voting
Integrazione di sorgenti XML
Data cleaning:
Panoramica Problemi
Singola sorgente
Sorgenti Multiple
Metodologie
Tecniche
Querying inconsistent databases
27/04/2010
Data Quality
Data Quality
Assicurare la massima qualità dell’informazione
risultante da processi di integrazione in cui esistano
componenti di dati disponibili in più copie provenienti
da uno o più sistemi;
due sono i contesti di interesse:
3
Master OpenKnowTech
Individuare e correggere gli errori
potenzialmente presenti all’interno di collezioni
di informazioni (data cleaning)
ogni sorgente di dati ha la capacità di fornire, oltre ai dati veri
e propri, anche dei metadati che descrivano, in accordo ad
una o più metriche specifiche, la qualità dei dati forniti
(contesto con certificazione di qualità alla fonte) [cfr., Batini et
al.]
certificazione di qualità completamente a carico del sistema
che eroga il servizio informativo all’utente (sulla base di
opportuni algoritmi di selezione e filtering).
27/04/2010
2
Master OpenKnowTech
Panoramica Problemi
tali errori si ingenerano per i motivi più disparati (ad
esempio, errori nel data entry)
è in genere complesso riuscire ad individuarli e
correggerli appropriatamente
la problematica di ripulitura dei dati riguarda sia
ambiti in cui venga utilizzata una sola sorgente di
dati che quelli in cui esistano più sorgenti cui si
acceda attraverso sistemi di data warehousing o di
tipo cooperativo
27/04/2010
4
Master OpenKnowTech
Panoramica Problemi
Singola Sorgente
Problemi di qualità dei dati
Singola Sorgente
Schemi
27/04/2010
Istanze
Sorgenti Multiple
Schemi
Istanze
Schemi
Istanze
- mancanza di vincoli di integrità
- errori nel data entry
- errori di progettazione
Problemi:
Problemi:
- lessico
- unicità
- ridondanza
- integrità referenziale
- valori contradditori
-…
-…
27/04/2010
1
Panoramica Problemi
Panoramica Problemi
Sorgenti Multiple
Schemi
Istanze
- schemi e strutture eterogenei
- dati contradditori e inconsistenti
Problemi:
Problemi:
- conflitti di nome
- aggregazioni inconsistenti
- conflitti strutturali
- storicizzazioni inconsistenti
-…
-…
27/04/2010
27/04/2010
Situazione 1:
Problema di qualità
Livello Istanza
Problema di qualità
Livello Istanza
Problema di qualità
Livello Schema
La qualità dei dati di una sorgente
dipende da quanto strette siano
le regole che controllano
l’immissione di dati
Dati memorizzati in un file TXT
Singola Sorgente
Situazione 2:
nessun controllo sui dati
alta probabilità di dati scorretti o inconsistenti
27/04/2010
Problema di qualità
Livello Schema
27/04/2010
Singola Sorgente
Problema di qualità
Intero Sistema
Singola Sorgente
I problemi a livello delle istanze (sia
mono che multi-sorgente) sono relativi ad
errori e inconsistenze dei dati realmente
memorizzati nelle sorgenti. Sono questi ad
essere normalmente trattati con tecniche di
data-cleaning.
Problema di qualità
Singola Sorgente
27/04/2010
Panoramica Problemi
Considerazioni su un contesto multi-sorgente:
Dati memorizzati in un DB
possibilità di un insieme ricco di vincoli
probabilità molto minore di dati scorretti o
inconsistenti
27/04/2010
2
Singola Sorgente
Singola Sorgente
Situazione 3:
!
Insieme ben progettato di vincoli:
assenza di valori replicati
formati validi
valori all’interno di range definiti
…
Anche i sistemi di basi di dati
possono avere significativi
problemi di qualità dei dati sia a
livello di schemi che di istanze
27/04/2010
27/04/2010
Singola Sorgente
Cause di problemi a livello di schema:
Singola Sorgente
Cause di problemi a livello di istanze:
Progettazione non attenta degli schemi
Vincoli non definiti in maniera completa (per
es. per limitare il carico computazionale sul
DBMS)
27/04/2010
Gli errori a livello di schema e di istanza,
sono ancora suddivisibili in:
27/04/2010
Errori di data entry non controllabili attraverso
vincoli
27/04/2010
Singola Sorgente
singolo attributo
singolo record
tipo di record
intera sorgente
Singola Sorgente
Esempi di errori a livello di schema:
Ambito: attributo
Problema: valori illegali
Esempio: dataDiNascita=20-13-1970
Note: valore fuori dominio
27/04/2010
3
Singola Sorgente
Ambito: record
Singola Sorgente
Problema: violazione di dipendenze
Esempio: dataDiN = 20-03-1970, età = 30
Note: età ≠ currentData - dataDiN
Ambito: tipo di record
Problema: violazione di unicità
Esempio:
27/04/2010
Ambito: sorgente
Singola Sorgente
Esempi di errori a livello di istanze:
Ambito: attributo
Problema: violazione d’integrità referenziale
Esempio:
imp1=(nome=“Marco Rossi”, codDipart=“129”);
Note: dipartimento “129” inesistente
27/04/2010
Problema: valori mancanti
Esempio: dataDiNascita=?
Note: dato non definito
Problema: lessico
Esempio: città=“Malano”
Note: errore di digitazione
27/04/2010
Singola Sorgente
Problema: abbreviazioni o sigle
Esempio:
professione=“Dott. Agr.”
professione=“DB prog.”
Singola Sorgente
Ambito: attributo
Problema: valori multipli
Esempio:
Note: sigle criptiche
Problema: posizione dei valori
Esempio: nome=“Roma” città=“Marco Rossi”
27/04/2010
Note: unicità di cod violata
27/04/2010
Singola Sorgente
imp1=(cod=“12”, nome=“Marco Rossi”);
imp2=(cod=“12”, gnome=“Maria Bianchi”)
nome=“Marco Rossi, via XX settembre, 32 CS”
Note: Più dati associati ad un solo attributo
Problema: valori scorretti
Esempio: città=“Germania”
27/04/2010
4
Singola Sorgente
Ambito: record
Singola Sorgente
Problema: violazione di dipendenze
Esempio: città = Roma, prefisso = 02
Note: dati inconsistenti
Ambito: tipo di record
Problema: trasposizione di parole
Esempio:
27/04/2010
Problema: record duplicati
Esempio:
autore1=(“Leopardi”, “Recanati”, …);
autore2=(“Giacomo Leopardi”, “Recanati”, …)
Ambito: tipo di record
Problema: record contradditori
Esempio:
auto1=(modello=“Panda”, casa=“FIAT”);
auto2=(modello=“Panda”, casa=“Toyota”)
27/04/2010
Singola Sorgente
Ambito: sorgente
Singola Sorgente
Note: stesso record memorizzato più volte
27/04/2010
Note: errori tipici in campi a formato libero
27/04/2010
Singola Sorgente
autore1=(nome=“G. Leopardi”);
autore2=(nome=“Foscolo U.”)
Problema: riferimenti errati
Esempio:
Singola Sorgente
!
Il rilevamento e la correzione degli errori è
un’attività molto dispendiosa
Evitare l’insorgenza degli errori a monte:
persona=(nome=“Abele”, padre=“Noè”);
Note: Padre esistente ma errato
Attenta progettazione dello schema e dei
vincoli
Strumenti di immissione dati che minimizzano
gli errori di digitazione
27/04/2010
27/04/2010
5
Sorgenti Multiple
Oltre alle problematiche legate a
ognuna delle singole sorgenti si
aggiungono nuove problematiche
27/04/2010
Problemi principali:
!
Grande eterogeneità nei modelli, nella
struttura degli schemi e nelle istanze
Sorgenti Multiple
livello di schema
Livello di schema
conflitti sui nomi
conflitti di struttura
conflitti sui dati
27/04/2010
27/04/2010
Sorgenti Multiple
Livello di schema
livello di istanze
conflitti sui nomi
omonimie: stesso nome usato per oggetti
differenti
sinonimie: nomi diversi usati per lo stesso
oggetto
Ognuna delle sorgenti è progettata,
realizzata e messa in produzione,
indipendentemente dalle altre, con
tempi e modalità differenti
27/04/2010
Sorgenti Multiple
Sorgenti Multiple
Sorgenti Multiple
Livello di istanza
conflitti di struttura
differenti rappresentazioni dello stesso oggetto:
ad es., attributi vs tabelle
differenti tipi per lo stesso dato
differenti vincoli di integrità
…
record duplicati su più sorgenti
record contradditori tra più sorgenti
differenti valori per rappresentare dati
differenti interpretazioni di valori
ad es. diverse unità di misura (Euro vs Dollari)
27/04/2010
27/04/2010
6
Sorgenti Multiple
Sorgenti Multiple
Problematiche aggiuntive:
Esempio Riepilogativo:
Consumatore (Sorgente 1) Codice Soluzione
trovare i record che rappresentano la stessa
identità nel mondo reale
eliminare i duplicati
fondere i record
COD Nome
Via
Città
11
Maria Rossi
p.za XX settembre 2
Cosenza Calabria 871
Sesso
0
24
Mario Rossi
2 via XX settembre
CS Calabria
1
Cliente (Sorgente 2) Codice Soluzione
27/04/2010
Genere
Indirizzo
Telefono/Fax
Rossi
Marco
M
via Matteotti 23, Roma,
Lazio, 00100
016-236542
06-236599
493
Rossi
Mari E.
F
piazza XX settembre 2,
Cosenza Calabria, 87100
0984-88780
Outline
Possibile Soluzione: Consumatori
No
Cognome Nome
1
Rossi
Maria E.
2
Rossi
3
Rossi
Sesso
Città
F
piazza
XX settembre 2
Cosenza Calabria
Mario
M
piazza
XX settembre 2
Cosenza Calabria
Marco
M
via
Matteotti 23
Roma
CAP
Telefono
87100
0984-88780
00100
Via
Fax
87100
06-236599
CodNo
11
493
Panoramica Problemi
Singola sorgente
Sorgenti Multiple
Richiami su ETL, integrazione e riconciliazione
Identificazione e fuzzy matching e tecniche di voting
Integrazione di sorgenti XML
Data cleaning:
COD
24
06-236542
Lazio
Data quality:
Regione
Metodologie
Tecniche
Querying inconsistent databases
24
27/04/2010
27/04/2010
Analisi delle fonti
Spesso dall’analisi risultano errori e
inconsistenze
Punto cruciale: ottenere dati integrati,
consistenti e privi di errori
Necessaria la fase di riconciliazione,
quindi:
40
Integrazione:
41
Componente intensionale delle sorgenti
(schemi)
Pulizia e trasformazione:
Integrazione, pulizia e trasformazione
Master OpenKnowTech
Master OpenKnowTech
Riconciliazione
27/04/2010
Nome
24
27/04/2010
Sorgenti Multiple
CodNo Cognome
27/04/2010
Componente estensionale delle sorgenti
(dati)
Master OpenKnowTech
42
7
Fasi della Riconciliazione
Fase di “Analisi e Riconciliazione”
Sorgente 2
Sorgente 1
Schemi sorgenti
operazionali
Schemi sorgenti
operazionali
Campioni
dei dati
Analisi e
riconciliazione
Progettazione
Del Cleaning
Schema riconciliato
Mapping sorgenti
operazionali
Ricognizione e
Normalizzazione
Progettazione
della
trasformazione
Analisi e
riconciliazione
Master OpenKnowTech
Schema logico
(globale) riconciliato
e corrispondenze
43
Fase di “Analisi e Riconciliazione”
Schema logico
(locale)
Ricognizione e
Normalizzazione
Esame approfondito degli schemi
locali mirato alla comprensione del
dominio applicativo
Ricognizione e
Normalizzazione
Schema concettuale
(locale) trasformato
27/04/2010
Ricognizione e
Normalizzazione
Schema concettuale
(locale) trasformato
45
27/04/2010
Questa fase deve essere eseguita
anche in presenza di una sola
sorgente
In caso multi-sorgente deve
essere eseguita separatamente
per ogni sorgente
Non fa parte formalmente del
processo di integrazione
Master OpenKnowTech
Schema concettuale
(locale) trasformato
Confronto tra il progettista e gli
esperti del dominio per individuare
correlazioni tra i dati
Non si inseriscono nuovi concetti
ma si rendono espliciti quelli
ricavabili (per es. si definiscono
nuove dipendenze funzionali)
In questa fase si individuano
anche porzioni non utili al data
mart di interesse
Master OpenKnowTech
44
46
Integrazione
Riconciliazione e Normalizzazione
Schema logico
(locale)
Correzione degli schemi locali per
modellare accuratamente il
dominio applicativo
Master OpenKnowTech
Schema logico
(locale)
Master OpenKnowTech
Normalizzazione:
27/04/2010
27/04/2010
Definizione
corrispondenza
con le sorgenti
Fase di “Analisi e Riconciliazione”
Caso più complesso in cui è noto il
solo modello logico
Ricognizione:
Schema concettuale
(locale) trasformato
Schema concettuale
(locale) trasformato
Integrazione
degli schemi
Schema concettuale
(globale) riconciliato
Strumenti ETL
27/04/2010
Ricognizione e
Normalizzazione
Schema concettuale
(locale) trasformato
Schema concettuale
(globale) riconciliato
Schema riconciliato
Mapping sorgenti
operazionali
Procedure per
strumenti ETL
Schema riconciliato
Mapping sorgenti
operazionali
Metadati
Schema logico
(locale)
Schema logico
(locale)
Schema concettuale
(locale) trasformato
Integrazione
degli schemi
Nasce dalla presenza di fonti
di dati che modellano
porzioni non distinte e non
indipendenti del mondo reale
Passi:
Schema concettuale
(globale) riconciliato
47
27/04/2010
Individuazione delle
corrispondenze tra i concetti
Risoluzione dei conflitti
Creazione del mapping tra
schemi locali e schema
globale
Master OpenKnowTech
48
8
Integrazione
Integrazione
Principali problemi dell’integrazione:
Diversità di prospettiva
Principali problemi dell’integrazione:
Utenti diversi hanno punti di vista diversi dello
stesso concetto, in base alla loro funzione
Equivalenza dei costrutti
Stesso concetto rappresentato utilizzando
combinazioni diverse dei costrutti a disposizione
ISBN titolo
(0,1) partecipa (1,n)
Dipendente
a
Dipendente
(0,1)
27/04/2010
Progetto
assegnato
a
(1,1)
(1,n)
appartiene
a
(1,n)
Dipartimento
ISBN
Master OpenKnowTech
49
27/04/2010
Modelli della stessa porzione del dominio,
racchiudono concetti diversi, in contrasto tra loro
Spesso derivano da scelte progettuali errate
Master OpenKnowTech
Conflitto: in accordo al primo modello un
professore può tenere al più un corso, in
accordo al secondo deve tenerne almeno 2
Professore
Professore
Master OpenKnowTech
51
Integrazione
Principali
(0,1) insegna (1,1)
(2,n) insegna (1,1)
27/04/2010
Corso
Corso
Master OpenKnowTech
52
Integrazione
problemi dell’integrazione:
Incompatibilità
Principali problemi dell’integrazione:
delle specifiche
Concetti Comuni
È necessario definire il tipo di relazione
semantica tra concetti comuni modellati
diversamente in schemi distinti
Date due rappresentazioni, R1 e R2, di uno
stesso concetto, sono possibili 4 relazioni:
Altra
sorgente di questo tipo di
incompatibilità è l’evoluzione nel tempo.
Assunzioni valide in passato possono
non essere più vere
27/04/2010
50
Incompatibilità delle specifiche
Errata scelta dei nomi
Errata definizione dei tipi di dato
Errata definizione dei vincoli di integrità
27/04/2010
indirizzo
casa editrice
Principali problemi dell’integrazione:
casa
titolo editrice
Casa Editrice
Integrazione
Incompatibilità delle specifiche
(1,n)
Libro
Principali problemi dell’integrazione:
edito
da
Dipartimento
Integrazione
nome indirizzo
(1,1)
Libro
Master OpenKnowTech
53
27/04/2010
Identità
Equivalenza
Comparabilità
Incomparabilità
Master OpenKnowTech
54
9
Integrazione
Integrazione
Principali problemi dell’integrazione:
Concetti Comuni
Identità: R1 e R2 coincidono, vengono utilizzati
gli stessi costrutti senza errori
Equivalenza: R1 e R2 sono rappresentati
mediante costrutti diversi ma equivalenti e non
sussistono errori (di percezione o di specifica
Comparabilità: R1 e R2 non sono identici né
incompatibili, ma i modelli utilizzati non sono in
contrasto tra loro)
Incomparabilità: R1 e R2 sono in contrasto tra
loro a causa dell’incompatibilità delle specifiche
Principali problemi dell’integrazione:
Concetti Comuni
Equivalenza: esempio
ISBN titolo
nome indirizzo
(1,1)
Libro
ISBN
edito
da
(1,n)
casa
titolo editrice
Casa Editrice
indirizzo
casa editrice
Libro
27/04/2010
55
Master OpenKnowTech
Integrazione
Concetti Comuni
Principali problemi dell’integrazione:
Comparabilità: esempio
Concetti Comuni
Incomparabilità: esempio
Dipendente
(0,1) partecipa (1,n)
a
Dipendente
(0,1)
27/04/2010
Progetto
assegnato
a
(1,1)
(1,n)
appartiene
a
(1,n)
Dipartimento
Master OpenKnowTech
Professore
57
insegna (1,1)
Corso
Corso
58
Master OpenKnowTech
Principali problemi dell’integrazione:
Concetti Correlati
Equivalenza
CONFLITTO
titolo
ISBN
Incomparabilità
titolo
ISBN
27/04/2010
(2,n)
27/04/2010
Concetti Comuni
Comparabilità
(0,1) insegna (1,1)
Integrazione
Principali problemi dell’integrazione:
La realtà modellata da R1 nega la realtà modellata da
R2
Professore
Dipartimento
Integrazione
56
Master OpenKnowTech
Integrazione
Principali problemi dell’integrazione:
27/04/2010
Master OpenKnowTech
59
27/04/2010
A seguito dell’integrazione concetti diversi ma
correlati rientrano nello stesso schema,
generando nuove relazioni
Libro
(1,1)
edito
da
(1,n)
Casa Editrice
lavora
per
(1,n)
Libro
(1,n)
scritto (1,n)
da
Master OpenKnowTech
nome
indirizzo
(1,n)
Autore
nome
indirizzo
60
10
Fasi dell’integrazione
Fasi dell’integrazione
Per risolvere i problemi relativi all’integrazione
è richiesto un insieme di operazioni
complesse. La metodologia standard si basa
su 4 fasi:
Preintegrazione
Comparazione degli schemi
Allineamento degli schemi
Fusione e ristrutturazione degli schemi
27/04/2010
Master OpenKnowTech
61
Fasi dell’integrazione
Analisi delle sorgenti
Scelta delle porzioni di dati da integrare
Strategia di integrazione
Tecniche ennarie: processo di integrazione
coinvolge più di due schemi
contemporaneamente
Tecniche binarie: il processo di integrazione
considera solo coppie di schemi
(dette anche a scala, i nuovi schemi vengono
integrati al globale corrente)
27/04/2010
62
Master OpenKnowTech
Fasi dell’integrazione
Preintegrazione
Preintegrazione
Preintegrazione: Strategie
Tecniche ennarie:
Processo di integrazione
Ogni concetto viene analizzato una volta sola
Ogni concetto viene analizzato avendo tutte le
informazioni che lo caratterizzano
Binario
A scala
Tecniche binarie:
27/04/2010
Master OpenKnowTech
63
27/04/2010
27/04/2010
Iterativo
64
Tecniche binarie a scala:
Si inizia dalle sorgenti che costituiscono il
“cuore” del Sistema Informativo e la loro
integrazione sarà lo scheletro del Schema
Riconciliato
Nell’integrare gli schemi successivi si favorisce
lo schema parziale riconciliato che più si
conforma agli schemi sorgenti più importanti
Ennarie: vantaggiose quando la complessità del
problema è limitata
Master OpenKnowTech
Master OpenKnowTech
Preintegrazione
La scelta della strategia dipende dalla
complessità e dal numero degli schemi
A un passo
Fasi dell’integrazione
Preintegrazione: strategie
Bilanciato
Integrazione più semplice grazie al ridotto
numero di concetti coinvolti
Fasi dell’integrazione
Ennario
65
27/04/2010
Master OpenKnowTech
66
11
Fasi dell’integrazione
Fasi dell’integrazione
Comparazione degli schemi
Comparazione degli schemi: conflitti
Identificazione di correlazioni e conflitti tra i
concetti
Conoscenza approfondita delle fonti
Collaborazione con gli amministratori delle fonti
27/04/2010
67
Master OpenKnowTech
Fasi dell’integrazione
Acquirente
27/04/2010
(0,n)
fa
(1,1)
69
27/04/2010
27/04/2010
formato (1,1)
da
(1,n)
Piano
composto (1,1) Appartamento
da
Master OpenKnowTech
70
Allineamento degli schemi
Risoluzione dei conflitti
Conflitti di tipo: stesso concetto modellato con costrutti
diversi
Conflitti di dipendenza: dipendenze diverse tra gli stessi
concetti
Conflitti di chiave: chiavi diverse
Conflitti di comportamento: diverse politiche di
cancellazione/modifica
Master OpenKnowTech
(1,n) contiene (1,1)
Appartamento
Fasi dell’integrazione
Scelte diverse di modellazione di uno stesso concetto
Differenti vincoli di integrità
(1,n)
Edificio
Ordine
Conflitti strutturali
Uno stesso concetto è rappresentato a diversi
livelli di dettaglio
Edificio
Master OpenKnowTech
68
Credito
Comparazione degli schemi: conflitti
(0,n) contiene (1,1)
Attrezzatura
Conflitti semantici
Fasi dell’integrazione
Laboratorio
Comparazione degli schemi: conflitti
(0,n) detiene (1,1)
(0,n) possiede (1,1)
Attrezzatura
Master OpenKnowTech
Sinonimie: termini diversi per denotare uno
stesso concetto
Cliente
Dipartimento
27/04/2010
Conflitti sui nomi
Omonimie: stesso termine utilizzato per concetti
diversi
Fasi dell’integrazione
Comparazione degli schemi: conflitti
Conflitti sui nomi
Applicazione di trasformazione allo schema
sorgente o allo schema riconciliato corrente
71
27/04/2010
Cambio di nomi
Cambio di tipo
Modifica dipendenze
Modifica vincoli
Definizione del mapping
Master OpenKnowTech
72
12
Fasi dell’integrazione
Definizione delle corrispondenze
Fusione e ristrutturazione degli schemi
Schema concettuale
(globale) riconciliato
Definizione
corrispondenza
con le sorgenti
Completezza: nuove dipendenze risulteranno
visibili
Minimalità: eliminare le ridondanze tra i concetti
Leggibilità: migliorare l’organizzazione generale
Master OpenKnowTech
73
Definizione
corrispondenza
con le sorgenti
Schema logico
(globale) riconciliato
e corrispondenze
27/04/2010
Schema globale definito
indipendentemente dalle sorgenti
Schemi locali associati a viste sullo
schema globale
Traformazioni ETL più complesse
per capire i concetti degli schemi
sorgente coinvolti (query rewriting)
Facile estensione e manutenzione
L’aggiunta di una sorgente implica
solo la definizione della vista associata
Master OpenKnowTech
75
Strumenti ETL: Identificazione
27/04/2010
74
Data quality:
Panoramica Problemi
Singola sorgente
Sorgenti Multiple Richiami su ETL, integrazione e
riconciliazione
Identificazione, fuzzy matching e tecniche di voting
Integrazione di sorgenti XML
Data cleaning:
Metodologie
Tecniche
Querying inconsistent databases
27/04/2010
Numerosi
Molto eterogenei in architettura, struttura, modelli
Di tipo legacy, con una lunga vita operativa alle
spalle (spesso accompagnata da una scarsa
disponibilità di documentazione)
Master OpenKnowTech
Master OpenKnowTech
Master OpenKnowTech
76
Strumenti ETL: Identificazione
Come abbiamo sottolineato, la fase di
riconciliazione è fondamentale per una
corretta realizzazione del processo di
popolamento del DW
È, inoltre, una fase estremamente critica e
difficoltosa, laddove i sistemi operazionali
sorgente siano:
27/04/2010
lo schema globale è espresso in
termini degli schemi sorgente
A ogni concetto dello schema
globale è associata una vista sugli
schemi sorgente
Facili interrogazioni ETL per il
caricamento
L’inserimento di una nuova
sorgente implica la modifica della
definizione dei concetti
Outline
LAV (Local-As-View)
Schema logico
(globale) riconciliato
e corrispondenze
Definizione delle corrispondenze
Schema concettuale
(globale) riconciliato
GAV (Global-As-View)
Gli schemi allineati vengono fusi
Nuove trasformazioni sono necessarie per
migliorare lo schema riconciliato
27/04/2010
Analizzeremo un interessante problema
applicativo in cui sviluppare una tecnica di
riconciliazione, quello dell’eliminazione dei
record duplicati in cui le copie provengano da
più sorgenti di dati da riconciliare
Il problema deve essere affrontato in due fasi:
77
27/04/2010
Identificazione dei record duplicati
Riconciliazione vera e propria: costruzione di un
singolo record che rappresenti in maniera
appropriata tutti i duplicati recuperati e vada a far
parte del sistema target
Master OpenKnowTech
78
13
Strumenti ETL: Identificazione
Strumenti ETL: Identificazione
27/04/2010
Master OpenKnowTech
79
Caso I: È sufficiente applicare delle
operazioni di equi-join per individuare i
matching record ovvero operare per
ordinamento e verifica di record
adiacenti
Caso II: È necessario ricorrere a
tecniche più evolute come ad esempio
quelle di fuzzy matching che fanno uso
di join approssimate
27/04/2010
Esempio:
Distanza di editing (normalizzata) tra
stringhe:
81
27/04/2010
Esempio: similarità( “Mario Neri”, “Maro Nieri” ) =
1 - 2/10 = 0.8
Master OpenKnowTech
82
Strumenti ETL: Fuzzy Matching
Esempio: i record R1=(Mario, Neri, 29) e R2=(Maro, Nieri,
29) verrebbero identificati.
Master OpenKnowTech
Basato sul calcolo del grado di similarità
tra record
Due record Persona corrispondono ad uno stesso
individuo se i valori degli attributi nome, cognome
hanno similarità > 0.75 ed i valori dell’attributo età
sono identici
80
Valore numerico (spesso in [0,1])
Dipendente dall’applicazione
Identificazione dei matching record basata su
regole specificate in maniera dichiarativa o
implementate come funzioni definite
dall’utente
Esempio:
Master OpenKnowTech
Strumenti ETL: Fuzzy Matching
27/04/2010
Strumenti ETL: Fuzzy Matching
Master OpenKnowTech
Esiste una combinazione di attributi che
individua correttamente l’identità dei record
Tale combinazione non esiste
Strumenti ETL: Identificazione
27/04/2010
Il problema consiste nell’individuazione dei
matching records, cioè, di record che
rappresentano lo stesso oggetto del mondo
reale
Due casi:
Riferimento ad insieme di caratteristiche da
garantire: qualità dei dati
La classe dei problemi di qualità dei dati ha
diverse sfaccettature che si determinano nei
diversi contesti applicativi.
La corretta fusione di dati provenienti da
sorgenti diverse all’interno di viste integrate e
coerenti merita grande attenzione
83
attributi differenti possono contribuire con pesi
diversi a determinare il grado di similarità
per gli attributi di tipo stringa, spesso i più
rilevanti in pratica, è possibile utilizzare
tecniche basate su caratteri jolly, frequenze,
distanze di editing, similarità fonetiche e
dizionari
approcci più complessi fanno uso di metriche
speciali sviluppate area dell’information
retrieval
27/04/2010
Master OpenKnowTech
84
14
Strumenti ETL: Fuzzy Matching
Strumenti ETL: Fuzzy Matching
L’individuazione dei matching record è spesso
costosa da eseguire su grandi insiemi di dati
utile adottare tecniche multipass
27/04/2010
Master OpenKnowTech
85
Strumenti ETL: Esempio
27/04/2010
Utilizza un metodo di votazione con pesi per
ricostruire, in presenza di più copie di un dato tra
esse discordanti nei valori, un’immagine del dato
che sia la più affidabile in termini di qualità
La filosofia della tecnica è di tipo “attribute-wise”: il
record infine prodotto potrebbe non coincidere con
nessuno dei record originatisi dalle varie sorgenti
esterne, ma risultare dalla composizione delle
migliori coppie attributo-valore tra quelli prodotti
dalle sorgenti stesse
Master OpenKnowTech
87
La tecnica fa riferimento ad un concetto di affidabilità
delle sorgenti operazionali, codificata in un vettore di
affidabilità Af di n componenti, una per ognuna delle
sorgenti
0 <= Af[i] <= 1 denota l’affidabilità dell’i-esima sorgente
Inizialmente, tutte le componenti di AF vengono poste
uguali al valore 0,5
il vettore Af viene aggiornato man mano che si
analizzano i dati
27/04/2010
Master OpenKnowTech
88
L’algoritmo è costituito da due fasi:
Fase I: viene costruita una matrice di
affidabilità dei valori AV della stessa
dimensione della matrice QR, il cui generico
elemento AV(r,c) denoterà la probabilità che
il valore corretto per l’attributo c sia quello
presente, per quell’attributo, nel sistema
operazionale Sr
Fase II: calcolo del record risultato Res ed
aggiornamento del vettore Af
QR ha j righe (una per ognuno dei sistemi che hanno prodotto
una copia di R), e da k colonne, una per ognuna degli attributi
di R
Il generico elemento QR(r,c) riporterà il valore dell’attributo c
del record R per come questo è stato prodotto dal sistema Sr
Master OpenKnowTech
Assumiamo che i dati provengano da n sistemi
operazionali
La tecnica produce una copia di R in cui ad ogni
attributo è associato il valore presumibilmente più
corretto tra quelli restituiti dai sistemi operazionali in
cui R compare
27/04/2010
86
Strumenti ETL: Esempio
Sia R un certo record con attributi a1, a2, …, ak e
supponiamo che R venga identificato nei sistemi
operazionali S1,…, Sj, 1<=j<=n.
Si definisce una matrice QR come segue:
Master OpenKnowTech
Strumenti ETL: Esempio
27/04/2010
Strumenti ETL: Esempio
Tecnica di riconciliazione
Una tecnica alternativa si basa sull’uso di tabelle di
riferimento e grafi di relazione per identificare i record
Si basa sull’ipotesi che se due record si riferiscono alla
stessa identità è molto probabile che siano collegati
tra loro da numerose relazioni implicite nella base di
dati o siano collegati ad oggetti simili
Il database in questo caso viene visto come un grafo i
cui nodi corrispondono ai record e gli archi a relazioni
tra di essi
L’approccio utilizza quindi tecniche di analisi di grafi
per determinare l’insieme dei matching records
89
27/04/2010
Master OpenKnowTech
90
15
Strumenti ETL: Esempio
Strumenti ETL: Esempio
Fase I:
Calcolo di AV[r,c], 1<=r<=j, 1<=c<=k:
AV[r,c] = vote(r,c)*p+Af[r]*(1-p)
dove:
vote(r,c) è il numero di concordanze sulla colonna c del
valore QR[r,c], cioè, il numero di valori identici a QR[r,c]
che occorrono nella colonna c
p è un parametro che ha lo scopo di pesare il rilievo
relativo dato, nel calcolo di AV[r,c], alla componente di
voting (denotata da vote(r,c)) ed a quella determinata
dall’affidabilità percepita per i vari sistemi sorgente
(denotata da Af[r])
27/04/2010
91
Master OpenKnowTech
Strumenti ETL: Esempio
Esempio
Sorgenti S1, S2, S3
Affidabilità corrente: Af[1] = 0.7, Af[2] = 0.3, Af[3] = 0.5
Pesiamo egualmente il contributo in affidabilità e quello di
voto: p = 0.5
Supponiamo, infine, che la tabella QR sia la seguente
Sorgente
Nome
Età
S1
0.33 * 0.5 + 0.7 * 0.5 = 0.52
0.33 * 0.5 + 0.7 * 0.5 = 0.52
S2
0.66 * 0.5 + 0.3 * 0.5 = 0.48
0.33 * 0.5 + 0.3 * 0.5 = 0.32
S3
0.66 * 0.5 + 0.5 * 0.5 = 0.58
0.33 * 0.5 + 0.5 * 0.5 = 0.42
Master OpenKnowTech
93
27/04/2010
36
S3
Ivo
34
Master OpenKnowTech
92
Nella seconda fase viene innanzitutto calcolato il
record risultato res
Si utilizzando le matrici dei valori QR e delle
affidabilità AV
Il valore del generico attributo ac del record
risultato res sarà uguale a QR[r’,c], dove r’ è la riga
del valore massimo nella colonna c della matrice
AV
Nel caso compaiano, nella colonna c della matrice
AV, più occorrenze del valore massimo, si sceglierà
la prima delle righe in cui questo occorre quale riga
r’
27/04/2010
Nostro esempio: la Fase II restituirà il record
Master OpenKnowTech
94
Fase II.
Res=(NOME=Ivo, ETA’=35)
Notiamo che questo record risultato ha il suo primo
campo, il NOME, con un valore diverso da quello
prodotto dalla sorgente S1, quella più affidabile
poiché, in questo caso, è stata prevalente la
componente del voting su quella dell’affidabilità
assegnata ad ogni singola sorgente
Miglioramenti nell’affidabilità dei risultati prodotti
possono essere ottenuti utilizzando anche tabelle o
dizionari di riferimento per “pesare” con più
precisione la qualità dei dati restituiti.
Master OpenKnowTech
Ivo
Strumenti ETL: Esempio
Fase II.
35
S2
Fase II.
Strumenti ETL: Esempio
Età
Ivan
27/04/2010
Nome
S1
Strumenti ETL: Esempio
Calcoleremo la matrice AV, che risulterà
essere la seguente (in ogni entry è riportato il
calcolo eseguito, oltre che il suo valore):
27/04/2010
Sorgente
Si procede poi con l’aggiornamento dei valori di
affidabilità memorizzati nel vettore Af
Si consideri il generico elemento Af[r] del vettore. Il
suo valore viene aggiornato utilizzando la formula:
95
27/04/2010
Af[r] = Af[r] *q + (1- Avg1<=c<=k N(dist(Res.c,QR[r,c]))*(1-q)
dove:
Avg1<=c<=k denota la media aritmetica
dist(x,y) è la distanza, secondo una metrica opportuna, tra
i valori x ed y; (ad es., la distanza di editing nel caso di
domini di tipo stringa)
la funzione N(x) normalizza il suo parametro x (di tipo
numerico) ad un valore dell’intervallo [0,1]
Master OpenKnowTech
96
16
Strumenti ETL: Esempio
Affidabilità corrente
Outline
Fissiamo q a 0.8.
Le nuove affidabilità saranno:
N(dist(‘Ivan’,‘Ivo’))=0.5, N(dist(‘35’,‘35’))=0
Af[2] = 0.3 * 0.8 + (1 – (0 + 1/36) / 2) * 0.2 = 0.44
Af[1] = 0.7 * 0.8 + (1 – (0.5 + 0) / 2) * 0.2 = 0.71
N(dist(‘Ivo’,‘Ivo’))=0, N(dist(‘36’,‘35’))=1/36
Master OpenKnowTech
97
Il Web sta diventando l’infrastruttura principale per la
pubblicazione e lo scambio di informazioni
XML sta diventando uno standard per la
rappresentazione e lo scambio di informazioni sul Web
Querying inconsistent databases
27/04/2010
Master OpenKnowTech
98
Discutiamo un approccio di estrazione di
proprietà interschema:
Metodologie
Tecniche
Caratteristiche Generali
Motivazioni
Panoramica Problemi
Singola sorgente
Sorgenti Multiple
Richiami su ETL, integrazione e riconciliazione
Identificazione, fuzzy matching e tecniche di voting
Integrazione di sorgenti XML
Data cleaning:
Af[3] = 0.5 * 0.8 + (1 – (0 + 1/35) / 2) * 0.2 = 0.60
N(dist(‘Ivo’,‘Ivo’))=0, N(dist(‘34’,‘35’))=1/35
27/04/2010
Data quality:
Af[1] = 0.7, Af[2] = 0.3, Af[3] = 0.5
Il semplice utilizzo di XML non basta a risolvere i
problemi presenti in tale contesto applicativo
Specializzato per la manipolazione di documenti XML
Semi-automatico
Semantico
Leggero
Capace di consentire la scelta del livello di severità con cui
effettuare l’estrazione
L’eterogeneità dei dati scambiati via Web non riguarda
soltanto il loro formato ma anche la loro semantica
27/04/2010
Master OpenKnowTech
Caratteristiche Generali
All’inizio l’utente, in modo guidato,
specifica il livello di severità desiderato
I risultati, ottenuti in modo automatico,
devono essere validati dall’utente solo
ad attività completata
27/04/2010
Master OpenKnowTech
27/04/2010
Master OpenKnowTech
Caratteristiche Generali
L’approccio determina innanzitutto i vicinati degli
elementi e degli attributi relativi agli schemi XML
coinvolti
I vicinati vengono utilizzati per il calcolo di proprietà
interschema esistenti tra gli attributi e gli elementi degli
schemi XML coinvolti
L’approccio assume che a ciascun documento XML
sia associato uno schema XML
27/04/2010
Master OpenKnowTech
17
Nozioni Preliminari
Sia S uno schema XML; un x-component di S è un elemento o un
attributo di S
Sia S uno schema XML; l’insieme dei suoi x-component è
indicato con XCompSet(S)
Dato un x-component, per determinare i suoi vicinati, è
necessario calcolare il costo di connessione tra esso e ciascuno
degli altri x-component del medesimo schema XML
Costruzione dei vicinati degli
x-component
veryclose(xS, xT). riceve due x-components xS
e xT e restituisce true se:
Ciò richiede di determinare il livello di “vicinanza semantica” tra
due x-component
close(xS, xT). riceve due x-components xS e xT
e restituisce true se:
Per formalizzare tali idee, si utilizzano delle funzioni booleane
27/04/2010
Master OpenKnowTech
Costruzione dei vicinati degli
x-component
near(xS, xT). riceve due x-components xS e xT e
restituisce true se:
27/04/2010
veryclose(xS, xT) = true , oppure
close(xS, xT) = true
•
•
x1 = xS,
xn = xT,
near(x1, x2) and near(x2, x3) and … and near(xn-1, xn) è true
27/04/2010
Master OpenKnowTech
Master OpenKnowTech
Il costo di connessione CC(xS, xT) tra due x-component
xS e xT è pari a:
reachable(xS, xT). riceve due x-components xS e xT e
restituisce true se esiste una sequenza di xcomponent distinti x1, x2, …, xn, tale che
•
xT è un sotto-elemento complesso di xS , oppure
xT è un elemento e xS ha un attributo IDREF o IDREFS che si
riferisce
a xT
Costruzione dei vicinati degli
x-component
•
xS = xT, , oppure
xT è un attributo di xS , oppure
xT è un sotto-elemento semplice di xS
0 se veryclose(xS, xT) è true
1 se close(xS, xT) è true
minxi {CC(xS, xi) + CC(xi, xT)} se reachable(xS, xT) è true e
near(xS, xT) è false
+∞ se reachable(xS, xT) è false
Il j-esimo vicinato di un x-component xS è definito come:
ngh(xS, j) = { xT | xT є XCompSet(S), CC(xS,xT) ≤ j }
27/04/2010
Master OpenKnowTech
Estrazione delle proprietà
interschema
Un esempio
Consideriamo quattro tipi di proprietà interschema:
Sinonimia: indica che due concetti hanno lo stesso significato
Iponimia: indica che un concetto ha un significato più
specifico di un altro concetto
Overlapping: indica che due concetti condividono un insieme
significativo di proprietà
Omonimia: indica che due concetti, pur avendo lo stesso
nome, hanno un significato differente
ngh(subject, 0) = {subject, identifier, name, argument, duration, attended_by, teached_by}
ngh(subject, 1) = ngh(subject,0) U {project, title, description, students, level, date}
27/04/2010
Master OpenKnowTech
27/04/2010
Master OpenKnowTech
18
Fasi per l’estrazione delle
proprietà interschema
Confronto dei vicinati
Prima fase: confronto dei vicinati degli x-component
appartenenti a documenti XML differenti
Le possibili relazioni tra vicinati sono la
similarità, l'affinità e la generalizzazione
Seconda fase: derivazione delle coppie candidate in
base alle similarità derivate nella fase precedente
Terza fase: derivazione delle sinonimie, iponimie,
overlapping e omonimie in base ad un esame più
approfondito dei vicinati degli x-component candidati.
Dati due vicinati, si calcola un'opportuna
funzione obiettivo associata al maximum
weight matching relativo ad un grafo bipartito
BG al fine di individuare la relazione che
sussiste tra essi
Il grafo bipartito BG si ottiene a partire dagli xcomponent coinvolti nei vicinati
27/04/2010
Master OpenKnowTech
Confronto dei vicinati
27/04/2010
Master OpenKnowTech
Derivazione delle coppie candidate
Se ngh(x1j,v) risulta simile a ngh(x2k,v) allora la realtà
rappresentata da ngh(x1j,v) è sovrapponibile a quella
rappresentata da ngh(x2k,v)
Per derivare la relazione tra due x-component x1j ed
x2k appartenenti agli schemi XML S1 e S2 si esaminano
ngh(x1j,0) ed ngh(x2k,0)
Se ngh(x1j,v) risulta affine a ngh(x2k,v) allora la realtà
rappresentata da ngh(x1j,v) è correlata a quella
rappresentata da ngh(x2k,v)
Se ngh(x1j,0) ed ngh(x2k,0) risultano affini, è possibile concludere
che x1j e x2k si riferiscono ad un “contesto” analogo e,
presumibilmente, definiscono concetti affini.
(L’affinità è una proprietà più debole della similarità)
In tal caso, la coppia (x1j, x2k) viene marcata come
coppia candidata per una proprietà interschema
Se ngh(x1j,v) risulta più specifico di ngh(x2k,v) allora la
realtà rappresentata da ngh(x1j,v) è più ricca di quella
rappresentata da ngh(x2k,v)
27/04/2010
Master OpenKnowTech
Derivazione delle coppie candidate
Si osservi che ngh(x1j,0) e ngh(x2k,0) codificano un contesto
piuttosto limitato
Potrebbe essere necessario estrarre le proprietà con un livello di
sicurezza maggiore.
E' possibile introdurre un livello di severità: la coppia
(x1j, x2k) viene considerata candidata al livello di severità u
se ngh(x1j,v) è affine a ngh(x2k,v) ∀ 0 ≤ v ≤ u
Definiamo una funzione booleana candidate che riceve due xcomponent x1j e x2k ed un intero u e restituisce true se (x1j, x2k) è
una coppia candidata al livello di severità u, false altrimenti.
27/04/2010
Derivazione delle sinonimie,
iponimie, overlapping e omonimie
Si assuma che (x1j, x2k) sia una coppia candidata al
livello di severità u; per verificare se esiste una
proprietà interschema è necessario esaminare il loro
vicinato.
Esiste una sinonimia tra x1j e x2k al livello di severità u
se:
Master OpenKnowTech
candidate(x1j, x2k, u) è true
ngh(x1j,v) e ngh(x2k,v) sono simili ∀ 0 ≤ v ≤ u
x1j è detto iponimo di x2k al livello di severità u se:
27/04/2010
Master OpenKnowTech
27/04/2010
candidate(x1j, x2k, u) è true
ngh(x1j,0) è più specifico di ngh(x2k,0)
Master OpenKnowTech
19
Derivazione delle sinonimie,
iponimie, overlapping e omonimie
Esiste un overlapping tra x1j e x2k al livello di severità u
se:
Un esempio
candidate(x1j, x2k, u) è true
x1j e x2k non sono sinonimi
x1j non è iponimo di x2k
x2k non è iponimo di x1j
Esiste un'omonimia tra x1j e x2k al livello di severità u se:
candidate(x1j, x2k, u) è false
x1j e x2k hanno lo stesso nome
x1j e x2k sono entrambi elementi o entrambi attributi
Schema XML S1
27/04/2010
Master OpenKnowTech
Un esempio
27/04/2010
Un esempio
Consideriamo gli x-component student e PhDstudent. Per verificare se
rappresentano una coppia candidata al livello di severità 0 è necessario
confrontare ngh(student, 0) con ngh(PhDstudent, 0)
ngh(student, 0) e ngh(PhDstudent, 0) risultano affini, di conseguenza è
possibile concludere che student and PhDstudent rappresentano una
coppia candidata al livello di severità 0.
Per determinare il tipo di proprietà interschema è necessario esaminare
più in dettaglio i vicinati:
Schema XML S2
Master OpenKnowTech
Discussione
Master OpenKnowTech
Un approccio per l’estrazione di proprietà interschema
da sorgenti informative XML semi-automatico,
semantico e consente la scelta del livello di severità
con cui effettuare l’estrazione
Utilizzo dell’approccio in vari contesti applicativi:
integrazione di sorgenti informative, e-service,
elaborazione e l'ottimizzazione di query distribuite,
astrazione di sorgenti informative, il clustering di
sorgenti di dati, ecc.
Precisione sacrificata
Ottimo Recall
Ottima Precisione
Recall sacrificato
I risultati evidenziano la flessibilità dell’approccio
27/04/2010
È possibile concludere che PhDstudent è un iponimo di student al livello
di severità 0
27/04/2010
Livelli di severità alti:
ngh(student, 0) e ngh(PhDstudent, 0) non risultano simili
ngh(student, 0) non è più specifico di ngh(PhDstudent, 0)
ngh(PhDstudent, 0) è più specifico di ngh(student, 0)
Discussione
Livelli di severità bassi:
ngh(student,0) = {student, identifier, name, enrollment_year, attends}
ngh(PhDstudent,0) = {PhDstudent, identifier, name, advisor, enrollment_year,
thesis, research_interests, papers}
27/04/2010
Master OpenKnowTech
Master OpenKnowTech
27/04/2010
Master OpenKnowTech
20
Outline
Data quality:
Panoramica Problemi
Singola sorgente
Sorgenti Multiple
Richiami su ETL, integrazione e riconciliazione
Identificazione e fuzzy matching e tecniche di voting
Integrazione di sorgenti XML
Data cleaning:
Data Cleaning: Metodologie
Metodologie
Tecniche
Querying inconsistent databases
27/04/2010
Master OpenKnowTech
121
Metodologie
27/04/2010
Fasi fondamentali
Fasi fondamentali
Analisi dei dati
Trasformazione dei dati
Eliminazione/Correzione degli errori
Identificazione/Risoluzioni dei conflitti
I processi di pulizia dei dati si basano su
3 fasi principali:
27/04/2010
Fasi fondamentali
Più in dettaglio:
Analisi dei dati
Standardizzazione
Definizione delle regole di matching
Verifica
Trasformazione
Consolidamento delle correzioni
27/04/2010
Individuazione degli errori
Trasformazione appropriata che renda
possibile una loro correzione
Correzione degli errori
27/04/2010
Fasi fondamentali
Analisi dei dati
In genere comincia da piccoli campioni, e procede su
campioni via via più grandi.
Obiettivo
Tecniche
capire i dati grezzi nel senso di: individuare incompletezze e
invalidità; individuare codici, parole chiave e convenzioni;
capire la semantica delle relazioni tra record.
calcolo statistico su record e tabelle, inferenza di regole
associative e di dipendenze funzionali, decomposizione degli
attributi in elementi di livello atomico, …
Procedimenti
analisi per colonna, analisi per tabella, analisi incrociata, ecc.
27/04/2010
21
Fasi fondamentali
Fasi fondamentali
Standardizzazione
riorganizzare i dati in strutture
correggendo eventuali errori.
librerie e tavole di classificazione; aggiunta di
campi per migliorare il livello di informazione.
27/04/2010
Tecniche
Le fasi di analisi dei dati,
definizione delle regole di matching
e verifica debbono essere viste
come componenti di un ciclo che
andrà eseguito finché la fase di
verifica non avrà assicurato
l’appropriatezza
delle
scelte
effettuate.
Obiettivo
definire e calcolare la “distanza” tra due record,
individuare cluster di record, definire i mapping
tra gli schemi.
Fasi fondamentali
Verifica
mettere in collegamento gli schemi delle sorgenti
e i record che fanno riferimento ad uno stesso
oggetto del mondo reale
27/04/2010
Fasi fondamentali
Obiettivo
standard,
Tecniche
Definizione delle regole di matching
Obiettivo
verificare la correttezza e l’efficacia di
trasformazioni e mapping definiti; raffinare le
definizioni utilizzate;
Tecniche
esecuzioni “sample” su piccole porzioni di dati,
…
27/04/2010
27/04/2010
Fasi fondamentali
Fasi fondamentali
Analisi dei dati
Trasformazione
Standardizzazione
Definizione regole
di matching
Obiettivo
effettiva esecuzione delle procedure.
Verifica
No
Ok?
Si
Trasformazione
27/04/2010
Consolidamento
27/04/2010
22
Fasi fondamentali
Analisi dei dati
Consolidamento
Le informazioni codificate nello schema di una
base di dati o nei metadati a questo associati non
sono sufficienti perché si possa assicurare la
correttezza di un certo dato. Il problema è mitigato
nei contesti in cui sia stato definito un insieme
sufficientemente completo di vincoli di integrità che
possano agire a livello della sorgente oppure a
livello del wrapper associato a questa. In generale,
però, è necessario procedere con un’analisi
dettagliata delle istanze dei dati che la sorgente
produce in seguito ad un’interrogazione.
Obiettivo
valutare
i
dati
riorganizzati,
ottenendo
informazioni di vario genere (dati più recenti, dati
più frequenti, dati incompleti, ecc.); colmare le
lacune; notificare le correzioni alle sorgenti,
perché possano autonomamente decidere se
agire in merito
27/04/2010
27/04/2010
Analisi dei dati
Analisi dei dati
Data profiling
Data mining
Dizionari
Outlier detection
27/04/2010
Analisi dei dati
Data profiling – Esempi
Problema
Valori illeciti
27/04/2010
analisi delle istanze a livello di singolo
attributo, derivazione di informazioni circa il
tipo di dati, la loro lunghezza, il range,
l’unicità di valori, la presenza di valori nulli
ed i pattern tipici (ad esempio quello che
caratterizza i codici fiscali).
27/04/2010
Analisi dei dati
Data profiling
Metadati
Esempi
cardinalità
cardinalità sesso>2
max, min
Max e min fuori
dal range permesso
varianza
varianza superiore
a una data soglia
Data profiling - Esempi
Problema
Errori di battitura
Metadati
valori degli
attributi
Esempi
ordinamento sui valori
spesso porta valori scorretti
vicino a valori esatti
27/04/2010
23
Analisi dei dati
Analisi dei dati
Data profiling – Esempi
Problema
Data mining
Metadati
Esempi
valori di
default
Presenza di valori di default
potrebbe indicare mancanza
del valore reale
scoperta di caratterizzazioni dei valori
presenti nei database utili ai fini della
rilevazione della presenza di errori
Valori mancanti
27/04/2010
27/04/2010
Analisi dei dati
Data mining – Esempi
Dizionari – Esempi
27/04/2010
Dizionari
Una tecnica di rilevazione di errori
eventualmente presenti in dataset restituiti
da fonti esterne, semplice ma spesso molto
utile in pratica, consiste nell’utilizzo di
tabelle e dizionari di dominio contenenti
insiemi di valori di riferimento di particolari
domini di dati.
27/04/2010
Analisi dei dati
Analisi dei dati
una confidenza del 98% per una regola che
stabilisca che nel dataset il costo totale è
dato dalla quantità moltiplicato il costo
unitario, indica che il 2% dei record
presenta una potenziale situazione di errore
27/04/2010
tecniche di ricerca di associazioni e di sequenze
l’elenco dei codici di avviamento postale delle
varie località italiane: un confronto diretto tra un
valore di CAP restituito nel nostro dataset per
una certa località ed il valore corretto presente
all’interno della corrispondente tabella di
riferimento consentirà non solo di rilevare l’errore,
ma anche di correggerlo opportunamente
Analisi dei dati
Dizionari – Esempi
rilevazione e correzione di prefissi
risoluzione di sigle e abbreviazioni
27/04/2010
24
Outline
Data quality:
Panoramica Problemi
Singola sorgente
Sorgenti Multiple
un outlier è un valore che si
discosta, per le sue caratteristiche,
dalla popolazione di dati cui
appartiene
Metodologie
Tecniche : OUTLIER DETECTION
Querying inconsistent databases
27/04/2010
Master OpenKnowTech
145
Analisi dei dati
Outlier detection
Richiami su ETL, integrazione e riconciliazione
Identificazione e fuzzy matching e tecniche di voting
Integrazione di sorgenti XML
Data cleaning:
Analisi dei dati
Outlier detection
27/04/2010
Analisi dei dati
Outlier detection
approccio statistico
funzionamento:
principali approcci:
statistico
“distance-based”
limitazioni:
27/04/2010
richiede che venga specificata una distribuzione di
riferimento. Tuttavia nelle situazioni reali la
distribuzione dei dati non è spesso nota
27/04/2010
Analisi dei dati
assumendo che i dati rispettino una certa
distribuzione: gli outliers sono quegli oggetti che
soddisfano un test di discordanza, cioè che
maggiormente deviano dalla distribuzione ipotizzata
Analisi dei dati
Outlier detection
approccio “distance-based”
funzionamento:
limitazioni:
27/04/2010
dato un data set D su cui è definita una distanza e due
parametri, p e d, un oggetto o di D è un outlier se
almeno una frazione p degli oggetti di D si trova ad
una distanza maggiore o uguale a d da o
costo computazionale degli algoritmi elevato
Outlier detection
Esempio:
Nome
Lucia
Giuseppe
Franco
Marco
Pino
Altezza
1,65
1,80
1,75
1,95
2,50
Distribuzione normale
Altezza media: 1,70 m
27/04/2010
25
Analisi dei dati
Data cleaning: tecniche
Outlier detection
La tecnica illustrata finora funziona
bene per domini “regolari”, ma non su
domini a scarso grado di
strutturazione, come nel caso delle
stringhe
In questi casi, la tecnica deve essere
opportunamente rivista
Tabella Studenti
Esempio:
p=75%
d=8
D=Tabella Studenti
O1=(Luigi,10)
O3=(Francesco,12)
O2=(Rosa,250)
Nome
Età
Lucia
24
Giuseppe
22
Franco
23
Marco
24
Luigi
10
Francesco
12
Rosa
250
Pino
25
27/04/2010
27/04/2010
No
external information can be exploited
No
dictionary containing correct data is
available
Unsupervised
approach
No
entry is labeled as correct or as
anomalous
ID
Name
Height
o1
Joseph
170 cm
o2
Joseph
165 cm
o3
Joseph
180 cm
o4
Joseph
160 cm
o5
Jossep
h
178 cm
o6
Serge
157 cm
o7
Serge
268 cm
o8
Stepha
n
172 cm
o9
Woody
174 cm
An entry is likely to be correct
if it occurs many times in the
dataset
for example Joseph can be
assumed to be correct
The number of times an entry
occurs is said strength (σ) of
the entry,
for example, σ(Joseph) = 4
153
ID
Name
Height
o1
Joseph
170 cm
o2
Joseph
165 cm
o3
Joseph
180 cm
o4
Joseph
160 cm
o5
Jossep
h
178 cm
o6
Serge
o7
Serge
o8
o9
An entry, which occurs few
times, or which is very
distant from all the others, is
not always erroneous
154
ID
Name
Height
o1
Joseph
170 cm
o2
Joseph
165 cm
o3
Joseph
180 cm
o4
Joseph
160 cm
o5
Jossep
h
178 cm
157 cm
o6
Serge
157 cm
268 cm
o7
Serge
268 cm
Stepha
n
172 cm
o8
Stepha
n
172 cm
Woody
174 cm
o9
Woody
174 cm
for example, Woody
155
A neighbor of an entry is
said justification of the entry
for example, Joseph is a
justification of Josseph
Formally, a neighbor of an
entry e is an entry e’ whose
distance from e is greater
than 0 but lower than R
156
26
ID
Name
Height
o1
Joseph
170 cm
o2
Joseph
165 cm
o3
Joseph
180 cm
o4
Joseph
160 cm
o5
Jossep
h
178 cm
o6
Serge
157 cm
o7
Serge
268 cm
o8
Stepha
n
172 cm
o9
Woody
174 cm
OUTLIER DEFINITION
An anomalous entry is an
entry e that has a
justification with a strength
significantly larger than the
strenght of e
Trie,
or Prefix Tree, is a tree data
structure
All
the descendants of any node n have a
common prefix of the string associated with
n
The root is associated with the empty string
Each node stores the frequency of the string
associated with it
Formally:
e is outlier if it has a
neighbor e’ such that the
strength of e is at least ρ
times the strength of e’
157
Trie
Building: example
ID
Name
o1
Joseph
o2
Joseph
o3
Joseph
o4
Joseph
seph
o5
Jossep
h
1
o6
Serge
o7
Serge
o8
Stepha
n
o9
Woody
First
9
For
Woody
Jos
S
5
the data entry per increasing value
of strength,
1
erge
4
phase (populating a trie)
each data entry, store it in the trie
Order
3
eph
158
tephan
2
Call
1
them s1,…, sm
Second
phase (detecting outliers and
associated justification)
159
ρ R
DS
160
Levenshtein
Second
distance between two strings:
The minimum number of operations needed to transform
one string into the other
An operation is an insertion, deletion, or substitution of a
single character
It is at most the length of the longer string
Example:
Phase:
STOP INNER
SCAN
Si is returned
as anomlous
yes
Get an entry,
si
i: [1…m-1]
STOP INNER SCAN
Si is not marked
as anomlous
no
Get an entry,
sj
j: [m…i+1]
σ(si)<=ρ
)<=ρ σ (s
( sj ) ?
no
yes
dist(si,sj)<R?
Compute
dist(sj, sj)
161
Dist(“SATURDAY”, “SUNDAY”) = 3
Dist(“SUNDAY”, “MILK”)=6
S
A
T
U
R
D
A
Y
S
U
N
D
A
S
-
-
U
N
D
A
Y
M
I
L
K
-
-
i/d
i/d
su
b
su
b
su
b
su
b
i/d
i/d
su
b
Y
162
27
The
normalized Levenshtein distance
between two strings is the ratio between
the Levenshtein distance and the length
of the longer string
The
best algorithm known for computing
the Levensthein distance is a dynamicprogramming one, which builds a matrix
of size (l1+1)x(l2+1)
Example:
It
DistNorm(“SATURDAY”, “SUNDAY”) = 3/8
DistNorm(“SUNDAY”, “MILK”)=6/6
The
always ranges between 0 and 1
computational cost is O(l1l2)
163
164
First phase:
Cost of inserting a string s in the trie: O(|s|)
L = s∈DB | s |
Total cost: O(L)
L0 is the the sum of the lengths of the m distinct strings of DB
For
our scope, we are only interested in the
normalized Levenshtein distance if it is smaller
than R
Then, if the Levenshtein distance between two
strings is smaller than k=R |s|, where s is the
longest string
In this case, it suffices to compute a diagonal
stripe of width 2k+1 in the matrix
In this way, the algorithm can be run in O(kl)
time, where l is the length of the shortest string
∑
Sorting:
O(L0 log L0)
Second phase:
O(m2) distances
Total cost: O(R L02)
Total cost of the algorithm
O(L+L0 logL0+R L02) = O(R L2)
165
166
Data cleaning: tecniche
Authors
from DBLP database: 17,169 entries
Outlier
Justification
1
Kenneth T. Anderson (1)
Kenneth M. Anderson (5)
2
Hartmut Ehring (1)
Hartmut Ehrig (15)
3
Peter Fritzon (1)
Peter Fritzson (5)
4
Michael Halper (1)
Michael Haller (3)
5
Bernd Haman (1)
Bernd Hamann (4)
6
Michael Himsholt (2)
Michael Himsolt (5)
7
Shelby Pereia (1)
Shelby Pereira (3)
8
Jean-Francois Puget (2)
Jean-François Puget (8)
9
Mathias Weber (1)
Matthias Weber (4)
Queste tecniche si inseriscono in una
fase di pre-processing dei record,
prima cioè delle fasi di integrazione e
“identificazione/eliminazione” dei
duplicati.
167
27/04/2010
28
Tecniche
Tecniche
Problema:
determinare se due record, forniscono
informazioni relative alla stessa entità è
molto complesso
Il metodo standard di identificazione di
duplicati si basa sul confronto di un
record con tutti gli altri, ma questo
processo è molto lento, richiede:
N*(N-1)/2 dove N è il num di record
27/04/2010
27/04/2010
Tecniche
Tecniche
BSNM (Basic Sorted Neigbourhood Method)
data una collezione di due o più DB, questi
vengono concatenati in un’unica lista
sequenziale di N record.
a questa lista viene applicato l’algoritmo
BSNM
creare le chiavi;
ordinare i dati;
fondere i dati;
27/04/2010
Tecniche
L’algoritmo consta di 3 fasi:
Fase1: creare le chiavi
calcolare una chiave per ogni record nella
lista, estraendo campi o porzioni di campo
la scelta della chiave dipende dal contesto
specifico
l’efficienza del metodo dipende per larga
parte dalla scelta opportuna della chiave
27/04/2010
Tecniche
Fase2: ordinare i dati
27/04/2010
ordinare i record della lista usando la chiave
scelta nella fase1
27/04/2010
29
Tecniche
Tecniche
Fase3: fondere i record
1
Muovere una finestra di dimensione fissa
attraverso la lista sequenziale, limitando i
confronti per cercare record corrispondenti,
ai record all’interno della finestra
Se la finestra ha dimensione w ogni nuovo
record che entra nella finestra sarà
confrontato con i w-1 precedenti
27/04/2010
Tecniche
La Fase1 (creazione della chiave) costa
O(N)
La Fase2 (ordinamento) costa O(N·logN)
La Fase3 (confronto) costa O(w·N)
Tecniche
w è il parametro che stabilisce la
dimensione della finestra. Il suo valore
può variare da:
2: ogni record viene confrontato solo con il
precedente
N: ogni record viene confrontato con tutti gli
altri
w
Prossima
Finestra
w
27/04/2010
Tecniche
Le costanti che appaiono implicitamente
nel calcolo della complessità della Fase1
possono avere una rilevanza notevole, in
quanto estrarre una chiave da un record
può anche essere molto costoso
27/04/2010
Tecniche
Il primo caso comporta minima accuratezza
ma anche minimo costo.
Accuratezza: % di dati duplicati trovati
Costo Fase3 = O(N)
Il secondo caso comporta massima accuratezza ma anche massimo costo.
27/04/2010
w
w+1
Il costo sarà O(w·N)
Ad esempio, scegliendo w < log N il costo
diviene O(N·logN);.
27/04/2010
Finestra
Corrente
Accuratezza: % di dati duplicati trovati
Costo Fase3 = Costo Totale = O(N2)
27/04/2010
30
Tecniche
Tecniche
È necessaria allora, da parte
progettista, un’accurata scelta di w.
del
27/04/2010
27/04/2010
Tecniche
Tecniche
Esempio:
Un’altra componente molto delicata è la
scelta della chiave per la Fase 1, in
quanto da questa dipende l’efficienza
dell’intero processo. Infatti una chiave
dovrebbe avere un potere discriminante
sufficiente per identificare i record
candidati.
Persona:
Nome
Cognome
Salvatore
Stolfo
Indirizzo
Via Roma 13
Salvatore
Salvatore
Salvatore
Via Rooma 13
Via Roma 13
Via Roma 13
Stoffo
Scolfo
Storfo
CHIAVE
SALSTLVRM13
SALSTFVRM13
SALSCLVRM13
Nell’esempio, si è supposto che ci siano
più possibilità di errore sul cognome che
sul nome. E in particolare che sia più
facile sbagliare a capire le vocali che le
consonanti.
SALSTRVRM13
Il nome è più comune, quindi più facilmente
corretto
Chiave: Prime 3 consonanti del “nome” + prime 3 lettere del
“cognome” + consonanti “indirizzo” + num civico
27/04/2010
Tecniche
L’obiettivo è quello di ordinare l’intero
dataset utilizzando la chiave, in modo
che record equivalenti o molto simili,
capitino molto vicini.
La teoria di confronto utilizzata (e
codificata nella chiave)
dovrebbe
catturare anche errori basati sulla
fonetica delle parole.
27/04/2010
27/04/2010
Tecniche
Supponiamo che due persone abbiano
due cognomi che si pronunciano in modo
simile, ed esattamente lo stesso
indirizzo, possiamo dedurre che sono la
stessa persona.
27/04/2010
31
Tecniche
Tecniche
D’altro canto, supponiamo che due
studenti abbiano stessa matricola ma
indirizzo
completamente
diverso,
possiamo dedurre:
è la stessa persona che ha cambiato
indirizzo
c’è un errore su una delle due matricole
Quindi non è possibile stabilire regole di
confronto generali, ma queste regole
sono fortemente condizionate dal
dominio.
27/04/2010
27/04/2010
Tecniche
Esempio
Dati
Tecniche
di regola:
2 record r1, r2:
if r1.nome = r2.nome and
r1.cognome ≈ r2.cognome and
r1.indirizzo = r2.indirizzo
then
r1=r2
27/04/2010
si calcola se due campi differiscono
debolmente, valutando se una funzione
dist che tiene conto di errori tipografici e
di pronuncia supera o meno un valore
soglia; ovviamente si dovranno utilizzare
anche prove sperimentali.
27/04/2010
Tecniche
In generale una chiave singola non è
sufficiente a catturare tutti i record
equivalenti.
Se un errore è presente in una parte
rilevante della chiave, il record può
essere, dopo l’ordinamento, molto
lontano da uno ad esso equivalente.
27/04/2010
L’approccio più naturale è quello di definire
un formalismo che permetta all’utente di
stabilire regole.
Tecniche
Si possono pensare 2 tecniche:
aumentare w
questo comporta una notevole crescita della
complessità e rischia di non comportare
aumento di prestazioni
eseguire più run con chiavi diverse, usando
valori di w abbastanza piccoli
27/04/2010
32
Tecniche
Tecniche
Ogni run produce un insieme di coppie
equivalenti
A quest’insieme si applica la chiusura
transitiva
27/04/2010
Motivations
Panoramica Problemi
Singola sorgente
Sorgenti Multiple
Database Merging
Richiami su ETL, integrazione e riconciliazione
Identificazione e fuzzy matching e tecniche di voting
Integrazione di sorgenti XML
Data cleaning:
Querying inconsistent databases
Data quality:
se il record a è equivalente a un record b e
il record b è equivalente a un record c, il
record a deve essere equivalente al record
c.
27/04/2010
Outline
Chiusura Transitiva
Inconsistencies management
Expressiveness and Complexity
Special cases and Extensions
Metodologie
Tecniche
Other Techniques
Querying inconsistent databases
27/04/2010
Master OpenKnowTech
Conclusions
195
Schema integration
Integration System
The activity by which different input representation
data are merged into a unique global structure
describing the whole information set available for
the query process
Integration System
Typical problems:
World
Wide
Web
Digital Libraries
Scientific Databases
Personal
Databases
–Given: data sources S1, ..., Sk (DBMS, web sites, ...) and user
questions Q1,...,Qn that can be answered using the Si
–Find: the answers to Q1,...,Qn
Heterogeneous representation formats
Dynamic Sources
Vast collections
XML documents, OEM graphs, Structured data
33
Data Integration
Step 1 - Database Merging
The activity by which data are merged into a unique
global structure describing the whole information set
available for the query process
(there are no conflicts regarding attribute names)
• attribute domains are homogeneous
Entity identification problem
• each source provides a set of relations (or relational views)
• relation schemata possibly different but homogeneous
Data integration – typical problems
Integrating data,
data supposing that representation heterogeneity
has been previously solved:
Is customer_id in one database the same as customer_num in
another?
• integrity constraints defined for source and integrated DB’s
integrating data
possible presence of inconsistencies
Data values conflicts
managing inconsistencies
a weight attribute having values in kg and lbs
duplicate and inconsistent information
Repairing inconsistent databases
Querying inconsistent databases
Step1. Database Merging
( integrity constraint: Course →Prof )
Teaches( Course,
Course, Prof )
D1
D1
Although
Course
Prof
c1
John
c2
Mark
and
D2
Step 22- Managing Conflicts
are
Prof
Course
Prof
c1
John
c2
Frank
c1
c2
John
Mark
c2
Frank
Course
Prof
c1
John
c2
Mark
c2
Frank
union D1 ∪ D2 is inconsistent
(Course → Prof)
Course
D2
separately consistent their
Inconsistent db
D
possible presence of inconsistencies
Managing inconsistencies
Repairing inconsistent databases
Querying inconsistent databases
Approach
Define a logic framework for modeling both
•
Database integration
•
Inconsistencies managing
Different types of constraints:
•
Integrity constraints
•
Repair constraints
•
Priorized updates
Course
Prof
c1
c2
John
Mark
c2
Frank
D is transformed into
a consistent db by
inserting or deleting
tuples
Course
Prof
c1
c2
John
Mark
c2
Frank
Computing consistent answers
under three-valued semantics
D1 ∪ D2
- Does John teach c1 ?
yes
- Does John teach c2 ?
no
- Does Mark teach c1 ?
no
- Does Mark teach c2 ?
may be
Rep1
Rep2
Consistent Answer = maximal
set of atoms not violating the
constraints, satisfying the
query and matching its goal
Database Merging
The Problem
Integrating data (using merging operators)
Computing repairs
Given two relation R and S, we say that
• a tuple u of R is less informative than a tuple v of S (u
<<
v) if
u[A]= v[A] or u[A]= ⊥ ∀ attribute A
• R is less informative than S (R
∀u ∈ R ∃v ∈S s.t. u
D1
Course
Prof
c1
John
c2
Mark
c3
⊥
<<
<<
S) if
v
D2
<<
Course
Prof
c1
John
c2
Frank
c3
Mark
34
Database Merging
Properties of the Integration Operators
Given two relations R and S, a binary operator ◊ such that
attr(R ◊ S) = attr(R) ∪ attr(S)
R
S << R ◊ S
An integration Operator is said to be
is called merge operator.
operator
R << (R ◊ S) and S << (R ◊ S);
if for all R and S
Formalization
Input: D1 D2 ... Dn
lossless (Complete) ,
such that Di = { Ri,1... Ri,k}
Correct
if ∀ t ∈ (R ◊ S) ∃ t’ s.t. t’ ∈ R or t’ ∈ S and t’ <<t
Output: D= { Ti ... Tk}, where Tk= R1,k, ◊ ... ◊ Rn,k
Where ◊ is a merge operator
Integration operators: naïve approaches
Name
Office
Greg
R2
R1
City
Research NY
Greg
Smith
Admin
NY
Smith
Red
Sales
WA
Lan
∪+
R2
(union)
City
The Majority criteria preserves the information contained in the
majority of the knowledge bases.
BirthYear
1971
Sales
WA
1965
Sales
NY
1980
R2 (natural join)
R2
(outer join)
Name
Name
Greg
Greg
Office
Office
Research
Research
City
City
NY
NY
BirthYear
BirthYear
1971
1971
Smith
Admin
NY
⊥
⊥
Smith
Sales
WA
1965
1965
Red
Sales
WA
⊥
sales
NY
1980
Office
City
Greg
Research
NY
⊥
Greg
Research
NY
1971
Smith
Admin
NY
Smith
Sales
WA
Red
Sales
WA
⊥
Lan
sales
NY
1980
•complete
Office
Research NY
R
R11
Name
•correct
Name
R1
Merging by Majority(Lin & Mendelzon,1996)
BirthYear
<<
Lan
•correct,
• not complete
•complete
•correct
Merging by logic rules
Problems with merging operators
Complex and not intuitive semantics
Author
Title
Year
Author
Title
Year
Author
Title
Year
A
B
C1
A
B
C2
A
B
C1
C3
E
F
G
H
I
G
L
M
N
Bib2
Bib1
Author Title
Title Year Year
Author
AA
B B C1{C1,C2,C3}
EE
HH
LL
• Correct
• not Complet
integration process (business rules):
• all the merge operator defined in literature can be easilly
modelled by means of a logic program
• logic gives opportunity of defining more specific integration
techniques
• more intuitive and less complex specification
• merged relations ready for managing inconsistencies
F F
I I
G
G
G
G
M M
N
N
Bib
Logic approach
R1
R’1
R2
R’2
Rn
R’n
Not focused on user goal.
Advantages of using (stratified) logic rules to define the
Bib3
IP
Logic program+
1. Bag, set
2. List constructor
Computing
3. repairs
Choiceand consistent answer
Merging relations
35
Managing Inconsistent Databases
Managing Inconsistent Databases
A logic approach for managing inconsistent
Given a db D and a set of constraints IC, find the repairs of D
databases, i.e. databases violating some
or compute the answer of a query Q over D satisfying IC.
integrity constraints (IC) .
•
The technique is based on the rewriting of integrity
constraints into an extended disjunctive datalog
program DP.
Use of DP to
1. Compute repairs
Compute Repairs - minimal set of insert and delete
operation which makes D consistent,
•
Compute consistent answer - identify tuples which
satisfy the constraints and match the goal (without
modify the database).
2. Compute consistent answers
36