Data integration: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
Bibliografia |
|||
Riga 36:
Applicando le teorie dà indicazione circa la fattibilità e la difficoltà di integrazione. Nonostante le sue teorie possano apparire astratte, esse godono di sufficiente generalità per adattarsi a tutti i sistemi di integrazione,<ref>{{cite web|url=http://link.springer.com/chapter/10.1007/3-540-46093-4_14 |title=A Model Theory for Generic Schema Management}}</ref> compresi quelli che includono relazionale nidificato o [[Database XML|basi di dati XML]]<ref>{{cite web|url=http://www.vldb.org/conf/2006/p67-fuxman.pdf |title=Nested Mappings: Schema Mapping Reloaded }}</ref> e quelli che trattano i database come programmi<ref>{{cite web|url=http://homepages.inf.ed.ac.uk/dts/pub/psi.pdf |title=The Common Framework Initiative for algebraic specification and development of software}}</ref>.
Le connessioni a particolari [[DBMS]] quali [[Oracle]] o [[DB2]] sono fornite dalle tecnologie a livello di implementazione, come [[JDBC]], e non sono studiate a livello teorico.
===Definitions===
I sistemi di data integration sono formalmente definiti da una [[tripla]] <math>\left \langle G,S,M\right \rangle</math> dove <math>G</math> è lo schema globale, <math>S</math> è l'insieme eterogeneo degli schemi sorgente, e <math>M</math> è la mappatura che associa query tra la sorgente e gli schemi globali. Entrambi <math>G</math> e <math>S</math> sono espresse in [[Linguaggio formale|linguaggio]] su alfabeti composti da simboli per ognuna delle rispettive [[Database relazionale|relazioni]]. La [[Predicato funzionale|mappatura]] <math>M</math> consiste di asserzioni tra query su <math>G</math> e query su <math>S</math>. Quando gli utenti pongono un'interrogazione sul sistema di data integration, essi pongono interrogazioni su <math>G</math> e la mappatura sostiene le connessioni tra gli elementi nello schema globale e negli schemi sorgenti.
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.
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.
==Data integration nella vita scientifica==
| |||