Data integration: differenze tra le versioni

Contenuto cancellato Contenuto aggiunto
Strumenti per data integration
Riga 42:
Un database su uno schema è definito come un insieme di insiemi, uno per ogni relazione (in un database relazionale). Il database corrispondente allo schema di origine <math>S</math> dovrebbe comprendere l'insieme di insiemi di tuple per ogni sorgente eterogenea ed è chiamato ''database sorgente''. Si noti che questo singolo database di origine potrebbe in realtà rappresentare una collezione di database disconnessi. Il database corrispondente allo schema virtuale intermedio <math>G</math> è chiamato ''database globale''. Il database locale deve soddisfare la mappatura <math>M</math> rispetto al database sorgente. La legittimità di questa mappatura dipende dalla natura della corrispondenza tra <math>G</math> e <math>S</math>. Esistono due modelli popolari per modellare questa corrispondenza: ''Vista Globale'' o GAV e ''Vista Locale'' o LAV.
 
I sistemi GAV modellano il database globale come insieme di [[Vista (basi di dati)|viste]] su <math>S</math>. In questo caso <math>M</math> associa a ogni elemento di <math>G</math> una interrogazione su <math>S</math>. L'[[QueryOttimizzazione optimizerdi query|Queryelaborazione delle processingquery]] diventa un'operazione semplice grazie alle associazioni ben definite tra <math>G</math> e <math>S</math>. L'onere della complessità cade sull'implementazione del codice del mediatore in modo che istruisca il sistema di data integration nell'esatta maniera per recuperare elementi dai database sorgenti. Se si aggiungono altre fonti al sistema, può essere richiesto un grande impegno per aggiornare il mediatore, perciò l'approccio GAV sembra preferibile quando le sorgenti hanno una bassa probabilità di cambiare.
 
Nell'approccio GAV al sistema di data integration nell'esempio, il progettista dovrebbe prima sviluppare mediatori per ciascuna sorgente di informazioni cittadino e poi progettare lo schema globale attorno a questi mediatori. Per esempio, pensiamo se una delle fonti servisse un sito web meteorologico. Il progettista probabilmente aggiungerebbe allo schema globale un elemento corrispondente al meteo. Poi il grosso degli sforzi si concentra sulla scrittura dell'opportuno codice mediatore che trasformi predicati sul meteo in interrogazioni il sito meteorologico. Questo sforzo può diventare complesso se anche qualche altra sorgente ha affinità col meteo, perché il progettista potrebbe avere necessità di scrivere il codice per combinare correttamente i risultati dalle due fonti.