Data integration: differenze tra le versioni

Contenuto cancellato Contenuto aggiunto
Riga 47:
 
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.
 
In LAV, invece, il database sorgente è modellato come un insieme di viste <math>G</math>. In questo caso <math>M</math> associa ad ogni elemento di <math>S</math> una interrogazione su <math>G</math>. Qui le esatte associazioni tra <math>G</math> e <math>S</math> non sono più ben definite. Come illustrato nella prossima sezione, l'onere di scegliere come recuperare gli elementi dalle sorgenti ricade sull'elaboratore di query. Il beneficio della modellazione LAV è che nuove sorgenti possono essere aggiunte con molto meno dispendio di energie rispetto ad un sistema GAV, perciò l'approccio LAV dovrebbe essere preferito nei casi in cui lo schema intermedio sia meno stabile o più facilmente mutevole.
In un approccio LAV al sistema di data integration dell'esempio precedente, il progettista del sistema progetta lo schema globale e poi semplicemente inserisce gli schemi delle rispettive sorgenti di informazione delle città.
Consideriamo ancora che una delle fonti serva un sito web meteorologico: il progettista dovrebbe aggiungere allo schema globale elementi corrispondenti al meteo solo se non esistessero già. Poi i programmatori scriverebbero un [[Adapter pattern|adapter]] o un [[Wrapper|wrapper]] per il sito e aggiungerebbero una descrizione dello schema dei risultati del sito agli schemi sorgenti. La complessità di aggiungere nuove sorgenti si sposta dal progettista all'elaboratore di query.
 
==Data integration nella vita scientifica==