Architetture per data integration

L’ordine di questa sezione è dubbio, forse andava ad inizio capitolo o forse no.

Si parte come abbiamo detto da una serie di schemi separati in vari db, con modelli diversi. Posso avere anche file csv etc. . . Bisogna quindi raccogliere le varie informazioni e integrarle in un’unico dataset. Si hanno più tecnciche:

• la tecnica del consolidamento dove si raccolgono vari dataset dalle varie sorgenti informative, li integro come visto precedentemente e infine salvo il risultato in un nuovo db, che sarà la mia nuova architettura dati
• la tecnica che prevede di rappresentare i vari schemi separati in modo che essi siano mantenuti inalterati, non memorizzando il risultato dell’integrazione, ma dando possibilità all’utente di scrivere query sui dati integrati. Si produce quindi un nuovo schema globale che comunica tramite un mediatore software per prendere le query. Questo è la vera e propria tecnica di virtual data integration

Nel capitolo si parla soprattutto di virtual data integration anche se spesso non specificato.

Il data integration è un è un’importante area di ricerca e business che ha lo scopo principale di consentire ad un utente un accesso uniforme a più fonti di dati autonome ed eterogenee, attraverso la presentazione di una visione unificata di questi dati. Trovare questa uniformità tra elementi eterogenei è complesso perché bisogna trovare differenze e somiglianze in ogni schema per potersi conformare. Bisogna quindi riconciliare tutte le eterogeneità di schema e di istanza.

Il vantaggio di architetture d’integrazione rispetto alle architetture federate è la capacità di gestire meglio le eterogeneità, soprattutto se complesse, a livello di schema. Inoltre i sistemi federati non possono gestire eterogeneità a livello di istanze a causa della qualità (accuratezza, incompletezza inconsistenza etc. . .) dei dati. D’altro canto nelle architetture federate si ha un livello di autonomia in poco più basso nel senso che nei modelli integrati si assume che si hanno sorgenti provenienti da chissà dove mentre nei sistemi federati i nodi sono scelti in modo più consapevole.

Si hanno due approcci principali alla data integration:

1. integrated read-only views (Mediation), dove si ha integrazione solo per lettura. I dati letti nei vari db restano quindi inva- riati. Questa soluzione a livello aziendale viene scartata in favore delle datawarehouse, avendo persistenza dei dati e profondità sto- rica maggiore (anche se perdo flessibilità nel momento in cui si rimuove una sorgente dati)
2. integrated read-write views (Mediation with update), dove si hanno anche gli update. È estensione dell’architettura di Mediation per supportare gli aggiornamenti in una vista integrata (dovendo poter accedere ai vari db anche in scrittura). Questa cosa è difficile e anche poco studiata in letteratura e quindi non la tratteremo. In questo caso si preferiscono i modelli federati

L’integrazione dei dati è il problema di combinare i dati che risiedono in diverse fonti e fornire all’utente una visione unificata di questi dati può quindi essere letteralmente definita come global virtual schema (GS).

Parto dai vari db coi vari modelli e schemi e creo un GS che ha un certo modello. Si hanno mapping tra i vari schemi e il GS e quindi l’utente può effettuare delle query passando per il GS e a runtime il GS capisce dove sono le informazioni richieste, converte il linguaggio di query in quello necessario per il db dove si trova l’informazione ed effettua la query (che viene eseguita localmente sul db). Sempre on the fly si risolvono i conflitti e viene restituito il risultato della query. Potrei avere anche integrazione pay as you go.

Si hanno quindi tre elementi fondamentali in un’architettura di integration:

1. il GS
2. le varie sorgenti
3. il mapping tra le sorgenti e il GS

Si hanno quindi due componenti fondamentali:

1. un mediator, che data una query la frammenta e la riscrive per poter lavorare con i vari schemi locali. Inoltre il mediator mette insieme i vari risultati, risolve i conflitti e risponde alla query
2. vari wrapper, che agganciano ogni schema locale delle sorgenti al GS, rappresentando la sorgente in uno schema compatibile con quello del GS. Essi ricevono query nel linguaggio del GS e rispondono di conseguenza