Data integration: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
template citazione; rinomina/fix nomi parametri; converto template cite xxx -> cita xxx; elimino parametri vuoti; fix formato data |
m Bot: sintassi dei link e modifiche minori |
||
Riga 1:
'''Data integration''' si riferisce ai processi da attuare su dati provenienti da diverse sorgenti per fornire all'utente una visione unificata di quei dati.
{{Cita conferenza|autore=Maurizio Lenzerini |articolo=Data Integration: A Theoretical Perspective |titolo=PODS 2002 |anno=2002 |pp=233–246 |url=http://www.dis.uniroma1.it/~lenzerin/homepagine/talks/TutorialPODS02.pdf}}</ref>
Questo processo si rivela importante in molteplici situazioni, nell'ambito sia commerciale (si pensi a due imprese che debbano unire i loro [[Base di dati|database]]) sia scientifico (per esempio, combinare risultati da diversi archivi [[Bioinformatica|bioinformatici]]).
Riga 66:
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 [[
===Elaborazione di ''query''===
Riga 75:
Nei sistemi GAV, un progettista scrive il codice del mediatore per definire la riscrittura delle ''query''. Ogni elemento nella ''query'' dell'utente corrisponde a una regola di sostituzione proprio come ogni elemento nello schema globale corrisponde a una ''query'' sulla sorgente. L'elaborazione delle ''query'' espande semplicemente i sotto-obiettivi della ''query'' dell'utente secondo le regole specificate nel mediatore, perciò la ''query'' risultante è probabile che sia equivalente. Mentre il progettista fa la maggior parte del lavoro in anticipo, alcuni sistemi GAV come [http://www-db.stanford.edu/tsimmis/ Tsimmis] comportano la semplificazione del processo di descrizione del mediatore.
Nei sistemi LAV, le ''query'' vengono sottoposte a un processo più radicale di riscrittura perché non esiste alcun mediatore che allinei le ''query'' dell'utente con una semplice strategia di espansione.
In generale, la complessità di riscrittura delle ''query'' è [[NP-completo]].<ref name="refsix" /> Se lo spazio delle riscritture è relativamente piccolo questo non rappresenta un problema — anche per sistemi di integrazione con centinaia di sorgenti.
Riga 89:
* HiperFabric<ref>[http://www.hiperfabric.com]</ref>
* Lavastorm
* Informatica Platform
* Oracle Data Integration Services
* ParseKit (enigma.io)
| |||