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

1. Sistemi InformativiA. A. 2009/10Parte IInteroperabilità tra sorgenti informative

2. 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

3. 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

4. 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

5. I Database Distribuiti Concetti fondamentali • Una tipica architettura di DDBMS

6. 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

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

8. 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

9. 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

10. 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

11. I Database Distribuiti Architetture alternative: Processing distribuito • Il processing distribuito è conosciuto anche come sistema multidatabase

12. 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: • Sharedmemory • Shared disk • Sharednothing

13. I Database Distribuiti Architetture alternative: I DBMS paralleli • Le tre principali architetture dei DBMS paralleli

14. I Database Distribuiti Architetture alternative: I DBMS paralleli • L’architettura sharedmemory è 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 sharedmemory • I sistemi shared disk sono spesso denominati cluster • L’architettura sharednothing è spesso nota come processing massivamente parallelo • Questa architettura è più scalabile di un’architettura sharedmemory • La performance è ottima solo quando i dati richiesti vengono memorizzati localmente

15. I Database Distribuiti Architetture alternative: I DBMS paralleli • Alcune volte la definizione sharednothing 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

16. 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

17. 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

18. 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

19. I Database Distribuiti Principali architetture distribuite • Processing distribuito • Sistemi di Database Federati • Sistemi Informativi Cooperativi • Data Warehouse

20. 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 nx (n-1) pezzi di codice

21. 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

22. I Database Distribuiti Sistemi di Database Federati • Query associata alla problematica precedente

23. 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

24. Sistemi Informativi Cooperativi Funzionamento • Struttura di un Sistema Informativo Cooperativo

25. 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)

26. 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’

27. 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

28. 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’;

29. 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 2ntemplate • Il numero di template potrebbe diventare enormemente grande

30. 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’;

31. 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’;

32. 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

33. 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’

34. 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

35. 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.

36. 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

37. 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

38. 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

39. L’integrazione di sorgenti informative eterogenee Introduzione • Le fasi che permettono di effettuare la riconciliazione dei dati

40. 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

41. 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

42. 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

43. 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

44. 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

45. 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

46. 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

47. 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

48. 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

49. 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

50. 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