Sistemi Informativi
A. A. 2009/10
Parte I
Interoperabilità tra sorgenti informative
I Database Distribuiti
Introduzione
•
Scopo dei database: integrare i dati operazionali e fornire un accesso controllato ai
dati
•
Lo sviluppo delle reti di computer promuove una metodologia decentralizzata di
lavoro
•
La condivisione dei dati e l’efficienza nel loro accesso dovrebbe essere migliorata
dallo sviluppo di un DBMS distribuito che riflette questa struttura organizzativa
•
I DBMS distribuiti dovrebbero aiutare a risolvere il problema delle isole di
informazione
I Database Distribuiti
Concetti fondamentali
•
Database distribuito: una collezione logicamente correlata di dati condivisi
•
DBMS distribuito: un sistema software che permette la gestione dei database
distribuiti
•
Un database distribuito consiste in un singolo database logico suddiviso in un numero
di frammenti
•
Ciascun sito è capace di processare indipendentemente le richieste degli utenti che
coinvolgono i dati locali
•
Applicazioni locali e applicazioni globali
I Database Distribuiti
Concetti fondamentali
•
Un DDBMS ha le seguenti caratteristiche:
–
È una collezione di dati condivisi logicamente correlati
–
I dati sono suddivisi in un certo numero di frammenti
–
I frammenti possono essere replicati
–
I frammenti e le repliche vengono allocati presso opportuni siti
–
I siti sono collegati da reti di comunicazione
–
I dati su ciascun sito sono sotto il controllo di un DBMS
–
Il DBMS su ciascun sito può gestire applicazioni locali autonomamente
–
Ciascun DBMS partecipa ad almeno un’applicazione globale
I Database Distribuiti
Concetti fondamentali
•
Una tipica architettura di DDBMS
I Database Distribuiti
Concetti fondamentali
•
Esempio: una banca
•
Un DDBMS deve rendere la distribuzione trasparente (ovvero invisibile) all’utente
•
La trasparenza pone svariati problemi addizionali
•
Trasparenza e autonomia appaiono essere due proprietà conflittuali
I Database Distribuiti
Vantaggi
•
I DDBMS riflettono la natura organizzativa delle aziende
–
Molte organizzazioni sono naturalmente distribuite su diverse locazioni
–
Ad esempio, in una banca, i membri dello staff della filiale faranno le loro query locali ma il
management può effettuare delle query globali
–
I dati possono essere memorizzati sul sito più vicino agli utenti
–
Un Amministratore globale ha la responsabilità dell’intero sistema
•
I DDBMS migliorano la disponibilità dei dati
•
I DDBMS migliorano l’affidabilità
•
I DDBMS migliorano la perfomance
I Database Distribuiti
Vantaggi
•
I DDBMS abbattono i costi
–
Legge di Grosch: la potenza di calcolo cresce secondo il quadrato dei costi
–
Attualmente è generalmente riconosciuto che costa molto meno realizzare un sistema di
piccoli computer che abbiano la potenza equivalente di un singolo grosso computer
–
Se gli utenti di un database sono geograficamente sparsi
•
I DDBMS consentono una crescita modulare
•
Integrazione
•
–
Integrazione di sistemi legacy
–
Nessun pacchetto può fornire oggi tutte le funzionalità necessarie oggi ad un’organizzazione
I DDBMS consentono di rimanere competitivi
I Database Distribuiti
Svantaggi
•
Complessità
–
Un DBMS distribuito è inerentemente più complessi di un DBMS centralizzato
–
I dati possono essere replicati
•
Costi
•
Sicurezza
•
Controllo dell’integrità più difficile
•
Mancanza di standard
•
Mancanza di esperienza
•
Progettazione dei database più complessa
I Database Distribuiti
Architetture alternative: Processing distribuito
•
Processing distribuito: un database centralizzato che può essere acceduto tramite
una rete di computer
•
Il sistema consiste di dati che sono fisicamente distributi attraverso un certo numero
di siti della rete
•
Distribuzione dei dati in presenza di un processing distribuito
I Database Distribuiti
Architetture alternative: Processing distribuito
•
Il processing distribuito è conosciuto anche come sistema multidatabase
I Database Distribuiti
Architetture alternative: I DBMS paralleli
•
DBMS parallelo: un DBMS che opera su più processori e dischi e che è stato
progettato per eseguire operazioni in parallelo
•
I DBMS paralleli sono basati sulla premessa che un singolo processore non riesce a
soddisfare le crescenti richieste di scalabilità, affidabilità e performance a basso costo
•
I DBMS paralleli collegano più macchine piccole
•
Un DBMS parallelo deve fornire una gestione delle risorse condivise
•
Tre principali architetture:
–
Shared memory
–
Shared disk
–
Shared nothing
I Database Distribuiti
Architetture alternative: I DBMS paralleli
•
Le tre principali architetture dei DBMS paralleli
I Database Distribuiti
Architetture alternative: I DBMS paralleli
•
L’architettura shared memory è un’architettura fortemente accoppiata
•
Essa è nota anche come multiprocessing simmetrico
•
L’architettura shared disk è un’architettura debolmente accoppiata
•
L’architettura shared disk elimina il collo di bottiglia che normalmente si ha con
l’architettura shared memory
•
I sistemi shared disk sono spesso denominati cluster
•
L’architettura shared nothing è spesso nota come processing massivamente parallelo
•
Questa architettura è più scalabile di un’architettura shared memory
•
La performance è ottima solo quando i dati richiesti vengono memorizzati localmente
I Database Distribuiti
Architetture alternative: I DBMS paralleli
•
Alcune volte la definizione shared nothing include i DBMS distribuiti
•
La tecnologia parallela viene tipicamente utilizzata per database molto grossi
•
Tutti i maggiori distributori di DBMS forniscono la versione parallela dei loro prodotti
I Database Distribuiti
DDBMS omogenei ed eterogenei
•
In un sistema omogeneo tutti i siti utilizzano gli stessi DBMS
•
I sistemi omogenei si possono progettare e gestire molto più facilmente rispetto ai
sistemi eterogenei
•
In un sistema eterogeneo possono operare diversi DBMS che non devono
necessariamente essere basati sul medesimo modello dei dati
•
I singoli siti hanno già implementato i loro database e l’integrazione viene effettuata
successivamente
•
Permettere un certo livello di trasparenza
•
I dati possono essere richiesti da un altro sito
•
Se l’hardware è diverso ma i DBMS sono gli stessi la traduzione è immediata
•
Se i DBMS sono differenti la traduzione è complicata e comporta il mapping delle
strutture dati
I Database Distribuiti
DDBMS omogenei ed eterogenei
•
Necessità di costruire uno schema concettuale comune
•
Eventuale presenza di eterogeneità semantiche
•
Esempio: casa automobilistica
Cars(serialNo, model, color, autoTrans, cdPlayer, …)
Autos(serial, model, color)
Options(serial, option)
•
Nomi apparentemente equivalenti sono cambiati
•
Differenze nel tipo di dati
I Database Distribuiti
DDBMS omogenei ed eterogenei
•
Differenze nei valori
•
Differenze semantiche
•
Valori mancanti
•
Tipica soluzione: utilizzo dei gateway
–
Essa potrebbe non supportare la gestione delle transazioni anche per una coppia di sistemi
–
Essa mira solo alla traduzione di una query espressa in un linguaggio in una traduzione
equivalente espressa in un altro linguaggio
I Database Distribuiti
Principali architetture distribuite
•
Processing distribuito
•
Sistemi di Database Federati
•
Sistemi Informativi Cooperativi
•
Data Warehouse
I Database Distribuiti
Sistemi di Database Federati
•
Consiste nell’implementare connessioni uno-a-uno tra tutte le coppie di database
•
Se si hanno n database è necessario scrivere n x (n-1) pezzi di codice
I Database Distribuiti
Sistemi di Database Federati
•
Un sistema di database federati può essere il più facile da costruire quando il numero
di DBMS coinvolti è basso
•
Esempio: casa automobilistica
NeededCars(model, color, autoTrans)
Autos(serial, model, color)
Options(serial, option)
•
Il Concessionario 1 vuole interrogare il Concessionario 2 in remoto per conoscere
quali sono le automobili di quest’ultimo che soddisfano i requisiti specificati in
NeededCars
I Database Distribuiti
Sistemi di Database Federati
•
Query associata alla problematica precedente
I Database Distribuiti
Sistemi di Database Federati
•
Se il Concessionario 1 vuole chiedere la stessa cosa al Concessionario 3 che usa lo
schema:
Cars(serialNo, model, color, autoTrans, …)
La query sarebbe differente
Sistemi Informativi Cooperativi
Funzionamento
•
Struttura di un Sistema Informativo Cooperativo
Sistemi Informativi Cooperativi
Funzionamento
•
Esempio: casa automobilistica
Concessionario 1
Cars(serialNo, model, color, autoTrans, cdPlayer, …)
Concessionario 2
Autos(serial, model, color)
Options(serial, option)
Vista globale
AutosMed(serialNo, model, color, autoTrans, dealer)
Sistemi Informativi Cooperativi
Funzionamento
•
Esempio: casa automobilistica
L’utente chiede al mediatore macchine rosse:
SELECT serialNo, model
FROM autosMed
WHERE color = ‘red’
Wrapper al Concessionario 1
SELECT serialNo, model
FROM Cars
WHERE color = ‘red’
Wrapper al Concessionario 2
SELECT serial, model
FROM Autos
WHERE color = ‘red’
Sistemi Informativi Cooperativi
Funzionamento
•
Esempio: casa automobilistica
–
Il mediatore costruisce l’unione dei due insiemi e restituisce il risultato all’utente
–
Si assume che il numero seriale sia una chiave universale
–
Vi sono diverse opzioni che un mediatore può utilizzare per rispondere ad una query
Sistemi Informativi Cooperativi
Progettazione di un wrapper in un CIS - Template
•
Template: query parametriche
Concessionario 1
Cars(serialNo, model, color, autoTrans, cdPlayer)
Mediatore
AutosMed(serialNo, model, color, autoTrans, dealer)
Template: automobili di un determinato colore
SELECT *
FROM AutosMed
WHERE color = ‘$C’;
SELECT serialNo, model, color, autoTrans, ‘dealer1’
FROM Cars
WHERE color = ‘$C’;
Sistemi Informativi Cooperativi
Progettazione di un wrapper in un CIS - Template
•
Il wrapper potrebbe avere un altro template che specifica solo il parametro $m che
rappresenta un modello
•
In generale, per gestire tutte le combinazioni che si possono ottenere con n attributi,
sarebbero necessari 2n template
•
Il numero di template potrebbe diventare enormemente grande
Sistemi Informativi Cooperativi
Progettazione di un wrapper in un CIS - Filtri
•
Esempio: casa automobilistica
–
Si supponga che ad un wrapper su un database di un concessionario di automobili sia stato
associato il template che consente di selezionare le automobili in base al colore
–
Supponiamo che al mediatore venga richiesto di individuare le automobili con un
determinato modello e un determinato colore
–
Template:
SELECT *
FROM AutosMed
WHERE model = ‘$m’ AND color = ‘$C’;
SELECT serialNo, model, color, autoTrans, ‘dealer1’
FROM Cars
WHERE model = ‘$m’ AND color = ‘$C’;
Sistemi Informativi Cooperativi
Progettazione di un wrapper in un CIS - Filtri
•
Approccio alternativo: il wrapper prima effettui l’esecuzione di alcuni template
generici e, successivamente, effettui un opportuno filtraggio per rispondere alle
query
•
Riuscire a comprendere se una query di un mediatore richieda un sottoinsieme di ciò
che viene restituito da qualche template sul wrapper è, in generale, un problema
difficile
•
Esempio: casa automobilistica
–
Abbiamo il template sul colore
–
Vogliamo trovare automobili di colore blu ma il cui modello è Focus
–
Query al mediatore:
SELECT *
FROM AutosMed
WHERE model = ‘blu’ AND model= ‘Focus’;
Sistemi Informativi Cooperativi
Progettazione di un wrapper in un CIS - Filtri
•
Esempio: casa automobilistica
–
Utilizzare il template del colore con $C = ‘blu’ per trovare tutte le automobili blu
–
Memorizzare il risultato in una relazione temporanea TempAutos(serialNo, model,
color, autoTrans, dealer)
–
Selezionare da TempAutos il modello ‘Focus’ e restituire il risultato, mediante la query:
SELECT *
FROM TempAutos
WHERE model = ‘Focus’
–
•
Le tuple di TempAutos sarebbero prodotte una alla volta e immediatamente filtrate
Le operazioni di filtraggio possono avvenire anche sul Mediatore
Sistemi Informativi Cooperativi
Progettazione di un wrapper in un CIS – Altre
operazioni sul wrapper
•
È possibile trasformare i dati sul wrapper secondo altre modalità
•
Le colonne possono essere opportunamente proiettate prima di trasmettere i dati al
mediatore
•
È possibile effettuare aggregazioni o join sul wrapper
•
Esempio: casa automobilistica
–
Il mediatore vuole conoscere le macchine blu Focus presenti nei vari concessionari, ma
vuole sapere soltanto il numero seriale, il concessionario e se hanno o meno il cambio
automatico
–
Query del wrapper su TempAutos:
SELECT serialNo, autoTrans, dealer
FROM TempAutos
WHERE model = ‘Focus’
Sistemi Informativi Cooperativi
Progettazione di un wrapper in un CIS – Altre
operazioni sul wrapper
•
Esempio: casa automobilistica
–
Si supponga che al mediatore venga chiesto di trovare i concessionari e i modelli tali che il
concessionario abbia due macchine rosse, dello stesso modello, una con e una senza il
cambio automatico. Si supponga, cioè, che il mediatore chieda al wrapper di rispondere alla
seguente query:
SELECT A1.model, A1.dealer
FROM AutosMed A1, AutosMed A2
WHERE A1.model = A2.model AND
A1.color = ‘red’ AND
A2.color = ‘red’ AND
A1.autoTrans = ‘no’ AND
A2.autoTrans = ‘yes’ AND
A1.dealer = A2.dealer;
–
Consideriamo il wrapper relativo al Concessionario 1 e supponiamo che l’unico template
utile sia quello sui colori
Sistemi Informativi Cooperativi
Progettazione di un wrapper in un CIS – Altre
operazioni sul wrapper
•
Esempio: casa automobilistica
–
Il wrapper, innanzitutto, applica il template sui colori ponendo $c = ‘rosso’ e ottiene la
relazione RedAutos(serialNo, model, color, autoTrans, dealer)
–
Successivamente pone in join RedAutos con se stessa ed esegue la relazione necessaria
secondo la query:
SELECT DISTINCT A1.model, A1.dealer
FROM RedAutos A1, AutosMed A2
WHERE A1.model = A2.model AND
A1.autoTrans = ‘no’ AND
A2.autoTrans = ‘yes;
–
In questo modo ottiene il risultato desiderato
–
Quest’ultima operazione potrebbe essere eseguita a livello di mediatore piuttosto che di
wrapper.
Sistemi Informativi Cooperativi
Progettazione di un mediatore
•
La progettazione di un mediatore consiste nella creazione di un database virtuale
unico
•
La generazione del database globale avviene mediante un’operazione denominata
integrazione
•
Correlazioni semantiche
•
Diverse sorgenti sono state progettate da diversi individui
•
Le sorgenti informative coinvolte possono risultare semanticamente eterogenee
•
Il processo di integrazione non è una semplice fusione
Sistemi Informativi Cooperativi
Progettazione di un mediatore
•
Il processo di integrazione può essere effettuato a due livelli:
–
A livello intensionale, per fondere gli schemi
–
A livello estensionale, per fondere i dati
•
Le sorgenti coinvolte in un processo di integrazione possono avere formati differenti
•
La vera difficoltà da affrontare è l’eterogeneità semantica dei dati
L’integrazione di sorgenti informative eterogenee
Introduzione
•
I dati in gioco in un DDBMS sono ricavati da un insieme di sorgenti eterogenee
•
Schema locale di una sorgente
•
Le varie sorgenti possono essere fortemente correlate o completamente
indipendenti
•
L’analisi delle fonti operazionali non è di per sé sufficiente
•
Dopo l’analisi risulta necessario un processo di riconciliazione che prevede
integrazione, pulizia e trasformazione
•
La fase di integrazione è incentrata sulla componente intensionale
•
Pulizia e trasformazione dei dati operano a livello estensionale
L’integrazione di sorgenti informative eterogenee
Introduzione
•
Le fasi che permettono di effettuare la riconciliazione dei dati
L’integrazione di sorgenti informative eterogenee
Introduzione
•
Il quadro generale per la fase di analisi e riconciliazione è abbastanza complesso
•
Passi progettuali che compongono la fase di analisi e riconciliazione di due sorgenti
L’integrazione di sorgenti informative eterogenee
Introduzione
•
Sebbene il collegamento dei dati sia realizzato a livello logico, l’utilizzo di formalismi
di livello concettuale è fortemente consigliato
•
Nel caso in cui si presentino situazioni più semplici sarà sufficiente eliminare le fasi
non richieste
•
Gli schemi concettuali delle sorgenti rappresentano senz’altro il risultato principale
dell’analisi
L’integrazione di sorgenti informative eterogenee
Ricognizione e normalizzazione degli schemi
•
Il progettista deve acquisire un’approfondita conoscenza delle sorgenti coinvolte
attraverso attività di:
–
Ricognizione
–
Normalizzazione
•
La fase di ricognizione e normalizzazione deve essere svolta anche qualora sia
presente una sola sorgente dati
•
Il progettista deve verificare la completezza degli schemi locali sforzandosi di
individuare eventuali correlazioni involontariamente omesse
•
Le trasformazioni apportate allo schema non devono introdurre nuovi concetti bensì
rendere espliciti tutti quelli ricavabili
L’integrazione di sorgenti informative eterogenee
Ricognizione e normalizzazione degli schemi
•
Trasformazioni lecite e illecite durante la fase di ricognizione e normalizzazione di una
sorgente
L’integrazione di sorgenti informative eterogenee
Il problema dell’integrazione
•
Questo problema è oggetto di studio da ormai 20 anni
•
Attualmente l’attività di ricerca è concentrata sull’automazione del processo di
integrazione
•
Essa consiste nell’individuazione delle corrispondenze tra concetti rappresentati negli
schemi locali e nella risoluzione dei conflitti evidenziati
•
Se le diverse sorgenti dati modellassero porzioni indipendenti e distinte del mondo
reale il problema dell’integrazione non sussisterebbe
•
In pratica ciò non avviene
•
Inoltre, il processo di informatizzazione di un sistema informativo è di tipo
incrementale ed evolutivo
•
A ciò si aggiungono errori di modellazione e di implementazione
L’integrazione di sorgenti informative eterogenee
Il problema dell’integrazione
•
Proprietà inter-schema
•
È necessario utilizzare un unico formalismo
•
Il formalismo prescelto dovrebbe essere quello che garantisce il maggior potere
espressivo
L’integrazione di sorgenti informative eterogenee
Il problema dell’integrazione – Diversità di
prospettiva
•
Il punto di vista rispetto al quale diversi gruppi di utenti vedono uno stesso concetto
può differenziarsi notevolmente
•
Esempio: assegnamento dei dipendenti ai dipartimenti
L’integrazione di sorgenti informative eterogenee
Il problema dell’integrazione – Equivalenza dei
costrutti del modello
•
Rappresentare uno stesso concetto utilizzando combinazioni diverse dei costrutti
•
Esempio: legame tra libri e case editrici
L’integrazione di sorgenti informative eterogenee
Il problema dell’integrazione – Incompatibilità delle
specifiche
•
Schemi differenti che modellano una stessa porzione del dominio applicativo
racchiudono concetti diversi
•
Esempio: associazione tra professori universitari e corsi
•
Le assunzioni fatte in un certo momento potrebbero non essere più vere
successivamente
L’integrazione di sorgenti informative eterogenee
Il problema dell’integrazione – Concetti comuni
•
Tipo di relazione semantica esistente tra concetti comuni
•
Quattro sono le possibili relazioni esistenti
•
Identità
•
Equivalenza
–
Definizione di Rissanen: due schemi sono equivalenti se le loro istanze possono essere
messe in corrispondenza uno-a-uno
–
L’equivalenza implica che a livello estensionale esistano sempre due insiemi di dati, diversi
ma equivalenti, che memorizzano le stesse informazioni
L’integrazione di sorgenti informative eterogenee
Il problema dell’integrazione – Concetti comuni
•
Equivalenza
–
Due istanze per gli schemi equivalenti relativi allo schema con i libri e le case editrici visto
precedentemente
L’integrazione di sorgenti informative eterogenee
Il problema dell’integrazione – Concetti comuni
•
Comparabilità
–
•
Incompatibilità
–
•
Gli schemi relativi all’assegnamento dei dipendenti ai dipartimenti sono tra loro comparabili
Gli schemi relativi all’associazione tra professori universitari e corsi visti precedentemente
sono tra loro incompatibili
Ad esclusione della situazione di identità tutti gli altri casi determinano dei conflitti
L’integrazione di sorgenti informative eterogenee
Il problema dell’integrazione – Concetti correlati
•
A seguito dell’integrazione molti concetti diversi ma correlati verranno a trovarsi
nello stesso schema dando vita a nuove relazioni che non erano percepibili in
precedenza
L’integrazione di sorgenti informative eterogenee
Le fasi dell’integrazione
•
Risolvere i problemi fin qui elencati richiede un complesso insieme di operazioni
•
I passi da effettuare possono essere così sintetizzati:
–
Preintegrazione
–
Comparazione degli schemi
–
Allineamento degli schemi
–
Fusione e ristrutturazione degli schemi
L’integrazione di sorgenti informative eterogenee
Le fasi dell’integrazione - Preintegrazione
•
Durante questa fase viene svolta l’analisi vera e propria delle sorgenti dati
•
Le principali decisioni da prendere riguardano:
–
Le porzioni degli schemi che dovranno essere integrate
–
La strategia dell’integrazione
L’integrazione di sorgenti informative eterogenee
Le fasi dell’integrazione - Preintegrazione
•
Le principali decisioni da prendere riguardano:
–
Tecniche ennarie e tecniche binarie
–
La maggior parte delle metodologie proposte in letteratura predilige l’approccio binario
–
Tecnica binaria a scala: consente di definire l’ordine di esame degli schemi da integrare
–
Il progettista dovrà verificare la qualità dei dati contenuti all’interno delle sorgenti
L’integrazione di sorgenti informative eterogenee
Le fasi dell’integrazione – Comparazione degli schemi
•
Analisi comparativa dei diversi schemi che mira a identificare le correlazioni e i
conflitti tra i concetti in essi espressi
•
Il progettista non può prescindere dal collaborare con gli amministratori e gli utenti
•
I tipi di conflitti ricadono nelle seguenti categorie:
–
Conflitti di eterogeneità
–
Conflitti sui nomi
•
Sinonimie e omonimie
•
Individuazione delle omonimie e individuazione delle sinonimie
•
Una corretta documentazione di questo tipo di conflitto si può ottenere mediante dizionari dati
L’integrazione di sorgenti informative eterogenee
Le fasi dell’integrazione – Comparazione degli schemi
•
I tipi di conflitti ricadono nelle seguenti categorie:
–
Conflitti sui nomi
•
Esempi di sinonimie e omonimie
L’integrazione di sorgenti informative eterogenee
Le fasi dell’integrazione – Comparazione degli schemi
•
I tipi di conflitti ricadono nelle seguenti categorie:
–
Conflitti semantici
•
Gli schemi relativi all’assegnamento dei dipendenti ai dipartimenti visti in precedenza sono in
conflitto semantico
•
Esempio ulteriore:
L’integrazione di sorgenti informative eterogenee
Le fasi dell’integrazione – Comparazione degli schemi
•
I tipi di conflitti ricadono nelle seguenti categorie:
–
Conflitti strutturali
•
Conflitti di tipo (le rappresentazioni per modellare il legame tra libri e case editrici viste in
precedenza)
•
Conflitti di dipendenza
•
Conflitti di chiave
•
Conflitti di comportamento
L’integrazione di sorgenti informative eterogenee
Le fasi dell’integrazione – Comparazione degli schemi
•
L’individuazione delle correlazioni richiede un’approfondita conoscenza della
semantica degli elementi coinvolti
L’integrazione di sorgenti informative eterogenee
Le fasi dell’integrazione – Allineamento degli schemi
•
Scopo di questa fase è la risoluzione dei conflitti evidenziatisi al passo precedente
•
Tipiche primitive di trasformazione riguardano il cambio dei nomi, la modifica delle
dipendenze funzionali, etc.
•
Non sempre i conflitti possono essere risolti (esempio: il conflitto relativo
all’associazione tra professori universitari e corsi visto in precedenza)
•
In caso di incertezza si preferiscono le trasformazioni che avvantaggiano gli schemi
ritenuti centrali
•
A cominciare da questa fase il progettista deve definire il mapping tra gli elementi
degli schemi sorgente e quelli dello schema riconciliato
L’integrazione di sorgenti informative eterogenee
Le fasi dell’integrazione – Fusione e ristrutturazione
degli schemi
•
Durante questa fase gli schemi allineati vengono fusi a formare un unico schema
riconciliato
•
Vengono sovrapposti i concetti comuni a cui saranno collegati tutti i rimanenti
concetti
•
Possono essere necessarie ulteriori trasformazioni per garantire le seguenti
proprietà:
–
Completezza
–
Minimalità
–
Leggibilità
L’integrazione di sorgenti informative eterogenee
Le fasi dell’integrazione – Fusione e ristrutturazione
degli schemi
–
Due schemi equivalenti con un diverso livello di leggibilità
L’integrazione di sorgenti informative eterogenee
Definizione delle corrispondenze
•
Il risultato dell’analisi prevede lo schema riconciliato e l’insieme delle corrispondenze
tra gli elementi presenti negli schemi sorgente e quelli dello schema riconciliato
•
Queste corrispondenze giocano un ruolo cruciale
•
Approccio GAV (Global-As-View): ad ogni concetto dello schema globale deve essere
associata una vista il cui significato è definito in base ai concetti che risiedono sugli
schemi sorgente
•
La modalità con cui vengono definite le corrispondenze incide sulla formulazione
delle interrogazioni utilizzate negli strumenti ETL per il caricamento dei dati
•
Con la soluzione GAV sarà sufficiente l’unfolding
•
La semplicità di formulazione delle interrogazioni viene pagata in termini di
estendibilità dello schema riconciliato
L’integrazione di sorgenti informative eterogenee
Definizione delle corrispondenze
•
Due mapping di tipo GAV nell’ambito di un sistema di ordini
L’integrazione di sorgenti informative eterogenee
Definizione delle corrispondenze
•
Approccio LAV (Local-As-View): lo schema globale è espresso indipendentemente
dalle sorgenti i cui concetti saranno definiti come viste sullo schema globale
•
Questa soluzione richiede trasformazioni più complesse indicate in generale con il
termine “query rewriting”
•
L’approccio LAV favorisce l’estensibilità dello schema riconciliato
