Sistemi Informativi A. A. 2009/10 Parte I Interoperabilità tra sorgenti informative.

Sistemi InformativiA. A. 2009/10

Parte IInteroperabilità tra sorgenti informative

I Database Distribuiti

• 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

Introduzione


• 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

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



• Una tipica architettura di DDBMS



• 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 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

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

Vantaggi


• 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

Svantaggi


• 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

Architetture alternative: Processing distribuito


• Il processing distribuito è conosciuto anche come sistema multidatabase

Architetture alternative: Processing distribuito


• 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

Architetture alternative: I DBMS paralleli


• Le tre principali architetture dei 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



• 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



• 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

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



• 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



• Processing distribuito

• Sistemi di Database Federati

• Sistemi Informativi Cooperativi

• Data Warehouse

Principali architetture distribuite


• 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

Sistemi di Database Federati


• Un sistema di database federati può essere il più facile da costruire quando il numero di DBMS coinvolti è basso


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



• Query associata alla problematica precedente



• 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

• Struttura di un Sistema Informativo Cooperativo

Funzionamento



Concessionario 1Cars(serialNo, model, color, autoTrans, cdPlayer, …)

Concessionario 2Autos(serial, model, color)

Options(serial, option)

Vista globaleAutosMed(serialNo, model, color, autoTrans, dealer)

Funzionamento



L’utente chiede al mediatore macchine rosse:SELECT serialNo, modelFROM autosMedWHERE color = ‘red’

Wrapper al Concessionario 1SELECT serialNo, modelFROM CarsWHERE color = ‘red’

Wrapper al Concessionario 2SELECT serial, modelFROM AutosWHERE color = ‘red’

Funzionamento



– 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

Funzionamento


• Template: query parametriche

Concessionario 1Cars(serialNo, model, color, autoTrans, cdPlayer)

MediatoreAutosMed(serialNo, model, color, autoTrans, dealer)

Template: automobili di un determinato coloreSELECT *FROM AutosMedWHERE color = ‘$C’;SELECT serialNo, model, color, autoTrans, ‘dealer1’FROM CarsWHERE color = ‘$C’;

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

Progettazione di un wrapper in un CIS - Template



– 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 AutosMedWHERE model = ‘$m’ AND color = ‘$C’;SELECT serialNo, model, color, autoTrans, ‘dealer1’FROM CarsWHERE model = ‘$m’ AND color = ‘$C’;

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


– Abbiamo il template sul colore

– Vogliamo trovare automobili di colore blu ma il cui modello è Focus

– Query al mediatore:SELECT *FROM AutosMedWHERE model = ‘blu’ AND model= ‘Focus’;




– 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 TempAutosWHERE model = ‘Focus’

– Le tuple di TempAutos sarebbero prodotte una alla volta e immediatamente filtrate

• Le operazioni di filtraggio possono avvenire anche sul Mediatore



• È 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


– 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, dealerFROM TempAutosWHERE model = ‘Focus’

Progettazione di un wrapper in un CIS – Altre operazioni sul wrapper



– 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.dealerFROM AutosMed A1, AutosMed A2WHERE A1.model = A2.model ANDA1.color = ‘red’ AND

A2.color = ‘red’ ANDA1.autoTrans = ‘no’ AND

A2.autoTrans = ‘yes’ ANDA1.dealer = A2.dealer;

– Consideriamo il wrapper relativo al Concessionario 1 e supponiamo che l’unico template utile sia quello sui colori




– 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.dealerFROM RedAutos A1, AutosMed A2WHERE A1.model = A2.model ANDA1.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.



• 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

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

Progettazione di un mediatore

L’integrazione di sorgenti informative eterogenee

• 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

Introduzione


• Le fasi che permettono di effettuare la riconciliazione dei dati

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

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

Introduzione


• 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

Ricognizione e normalizzazione degli schemi


• Trasformazioni lecite e illecite durante la fase di ricognizione e normalizzazione di una sorgente

Ricognizione e normalizzazione degli schemi


• 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

Il problema dell’integrazione


• Proprietà inter-schema

• È necessario utilizzare un unico formalismo

• Il formalismo prescelto dovrebbe essere quello che garantisce il maggior potere espressivo

Il problema dell’integrazione


• Il punto di vista rispetto al quale diversi gruppi di utenti vedono uno stesso concetto può differenziarsi notevolmente

• Esempio: assegnamento dei dipendenti ai dipartimenti

Il problema dell’integrazione – Diversità di prospettiva


• Rappresentare uno stesso concetto utilizzando combinazioni diverse dei costrutti

• Esempio: legame tra libri e case editrici

Il problema dell’integrazione – Equivalenza dei costrutti del modello


• Schemi differenti che modellano una stessa porzione del dominio applicativo racchiudono concetti diversi

• Esempio: associazione tra professori universitari e corsi

Il problema dell’integrazione – Incompatibilità delle specifiche

• Le assunzioni fatte in un certo momento potrebbero non essere più vere successivamente


• 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

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



• Comparabilità

– Gli schemi relativi all’assegnamento dei dipendenti ai dipartimenti sono tra loro comparabili

• Incompatibilità

– 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



• 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

Il problema dell’integrazione – Concetti correlati


• 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

Le fasi dell’integrazione


• 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

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

Le fasi dell’integrazione - Preintegrazione


• 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

Le fasi dell’integrazione – Comparazione degli schemi



– Conflitti sui nomi

• Esempi di sinonimie e omonimie




– Conflitti semantici

• Gli schemi relativi all’assegnamento dei dipendenti ai dipartimenti visti in precedenza sono in conflitto semantico

• Esempio ulteriore:




– 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’individuazione delle correlazioni richiede un’approfondita conoscenza della semantica degli elementi coinvolti



• 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

Le fasi dell’integrazione – Allineamento 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à

Le fasi dell’integrazione – Fusione e ristrutturazione degli schemi


– Due schemi equivalenti con un diverso livello di leggibilità

Le fasi dell’integrazione – Fusione e ristrutturazione degli schemi


• 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

Definizione delle corrispondenze


• Due mapping di tipo GAV nell’ambito di un sistema di ordini



• 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


Sistemi Informativi A. A. 2009/10 Parte I Interoperabilità tra sorgenti informative.

Documents

Transcript of Sistemi Informativi A. A. 2009/10 Parte I Interoperabilità tra sorgenti informative.