Data integration: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
Riga 41:
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>. [[Query optimizer|Query processing]] 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.
Line 51 ⟶ 49:
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.
===Elaborazione di query===
La teoria dell'elaborazione di query in un sistema di data integration systems è comunemente espressa utilizzando interrogazioni congiuntive [[Linguaggio di interrogazione|interrogazioni]] e [[Datalog]], un linguaggio di [[programmazione logica]] puramente dichiarativo.<ref name="reffive">{{cite conference | author=[[Jeffrey D. Ullman]] | title=Information Integration Using Logical Views | booktitle=ICDT 1997 | year=1997 | pages=19–40 | url=http://www-db.stanford.edu/pub/papers/integration-using-views.ps}}</ref> Si può liberamente pensare ad una [[query]] come una funzione logica applicata alle relazioni del database come "<math>f(A,B)</math> dove <math>A < B</math>". Se una tupla o insieme di tuple è sostituito nella regole e la soddisfa (cioè la rende vera), allora consideriamo quella tupla parte dell'insieme di risposte alla query. Mentre il linguaggi formali in stile [[Datalog]] esprimono queste query sinteticamente e senza ambiguità, anche le query [[SQL]] comuni contano come query congiuntive.
In termini di integrazione dei dati, il "contenimento delle query" raoppresenta un'importante proprietà delle query congiuntive. Una query <math>A</math> contiene un'altra quuery <math>B</math> (in simboli <math>A \supset B</math>) se i risultati di <math>B</math> sono un sottoinsieme dei risultati di <math>A</math> per ogni database. Le due query sono dette equivalenti se gli insiemi risultanti sono uguali per ogni database. Questo è importante perché in entrambi i sistemi GAV e LAV, un utente pone query congiuntive su uno schema virtuale rappresentato da un insieme di [[Vista (basi di dati)|viste]], o query congiuntive [[Vista materializzata |materializzate]]. L'integrazione si propone di riscrivere le query rappresentate dalle viste al fine di rendere i loro risultati equivalenti o al massimo contenuti nella richiesta del nostro utente. Ciò corrisponde al problema di rispondere a interrogazioni usando le viste.<ref name="refsix">{{cite conference | author=[[Alon Y. Halevy]] | title=Answering queries using views: A survey | booktitle=The VLDB Journal | year=2001 | pages=270–294 | url=http://www.cs.uwaterloo.ca/~david/cs740/answering-queries-using-views.pdf}}</ref>
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. Il sistema di integrazione deve eseguire una ricerca sullo spazio delle possibili query al fine di trovare la riscrittura migliore. La riscrittura risultante potrebbe non essere una query equivalente, ma massimamente contenuta, e le tuple restituite incomplete. {{Dal | 2009}} l'algoritmo MiniCon <ref name="refsix" /> è l'algoritmo capofila nella riscrittura di query per i sistemi di data integration LAV.
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.
==Data integration nella vita scientifica==
| |||