Data integration: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
m →Storia |
m query messo in corsivo |
||
Riga 7:
==Storia==
Problemi nella combinazione di fonti di dati [[Eterogeneità|eterogenee]], spesso identificati come silos di informazioni, attraverso una singola interfaccia per ''[[query]]'' esistettero per diverso tempo.
Nei primi anni Ottanta, i tecnici informatici cominciarono a progettare sistemi per l'interoperabilità di basi di dati eterogenee.<ref>{{cite news | author= John Miles Smith | title= Multibase: integrating heterogeneous distributed database systems | year=1982 | journal=AFIPS '81 Proceedings of the May 4–7, 1981, national computer conference | pages= 487–499 |url=http://dl.acm.org/citation.cfm?id=1500483|display-authors=etal}}</ref>
Il primo sistema di integrazione dei dati guidato da metadati strutturati è stato progettato presso l'[[Università del Minnesota]] nel 1991 per Integrated Public Use Microdata Series (IPUMS). IPUMS impiegava un approccio in stile [[data warehouse]] che estrae, trasforma e carica i dati provenienti da sorgenti eterogenee in una unica vista, affinché i dati diventino compatibili..<ref>{{cite news | author= [[Steven Ruggles]], J. David Hacker, and Matthew Sobek | title= Order out of Chaos: The Integrated Public Use Microdata Series | year=1995 | journal=Historical Methods |volume=28 | pages= 33–39}}</ref>
Rendendo interoperabili centinaia di basi di dati relative alla popolazione, IPUMS ha dimostrato la praticabilità di integrazione di dati su larga scala. L'approccio data warehouse offre un'architettura fortemente accoppiata, perché i dati sono già fisicamente riconciliati in un unico archivio interrogabile, in modo che di solito richieda poco tempo risolvere le ''query''.<ref>{{cite news | author= Jennifer Widom | title= Research problems in data warehousing | year=1995 | journal=CIKM '95 Proceedings of the fourth international conference on information and knowledge management | pages= 25–30 | url=http://dl.acm.org/citation.cfm?id=221319}}</ref>
L'approccio data warehouse è meno realizzabile per insiemi di dati aggiornati frequentemente: ciò richiede la continua esecuzione del processo [[ETL|ETL (Ectract, Transform, Load)]] per la sincronizzazione. Difficoltà nascono anche nella costruzione di data warehouse quando si ha un'interfaccia di interrogazione solo su dati sintetizzati e non si ha accesso alla loro totalità.
Riga 17:
A partire dal 2009 l'andamento nella data integration ha l'accoppiamento tra dati fornendo un'interfaccia unificata per l'accesso ai dati in tempo reale attraverso uno schema intermedio, che consente alle informazioni di essere recuperate direttamente dalle basi di dati originali. Ciò è coerente con l'approccio [[SOA]], popolare in quel momento.
Questo approccio si basa sulla mappatura tra lo schema intermedio e gli schemi delle fonti originali, trasformando una ''query'' in ''query'' specializzate sugli schemi specifici delle sorgenti originali. Tali mappature possono essere definite in due modi: con una mappatura dalle entità dello schema intermedio alle entità delle fonti originali (approccio "Global As View" (GAV)), o una mappatura dalle entità dei sorgenti originali alle entità dello schema intermedio (approccio "Local As View" (LAV)). Il secondo approccio richiede inferenze più sofisticate per risolvere interrogazioni sullo schema intermedio, ma rende più facile aggiungere nuove fonti di dati a uno (stabile) schema intermedio.
A partire dal 2010 una parte del lavoro di ricerca sull'integrazione dei dati si occupa del problema dell'integrazione semantica. Questo problema non riguarda il modo di strutturare l'architettura di integrazione, bensì il modo di risolvere i conflitti di semantica tra sorgenti di dati eterogenee. Per esempio: se due società fondono i loro database, alcuni concetti e definizioni nei rispettivi schemi, tipo "guadagni", hanno inevitabilmente significati diversi. In un database potrebbe significare profitti in euro (espressi in numero decimale), mentre nell'altro potrebbe rappresentare il numero di vendite (espresse in numero intero). Una strategia comune per la risoluzione di tali problemi implica l'uso di [[Ontologia (informatica)|ontologie]] che definiscano esplicitamente i termini dello schema e quindi aiutino a risolvere i conflitti semantici.
Riga 32:
==Esempio==
Si consideri una [[applicazione web]] in cui un utente può richiedere una varietà di informazioni sulle città (come statistiche sulla criminalità, meteo, alberghi, demografia, ecc.). Tradizionalmente, le informazioni devono essere memorizzate in un unico database con un singolo schema. Ma ogni singola impresa avrebbe trovato difficile e costoso raccogliere informazioni con tale estensione. Anche se le risorse esistono per raccogliere dati, avrebbero duplicato i dati nei database criminologici, siti web meteorologici e dati di censimento esistenti.
Una soluzione di integrazione può affrontare questo problema considerando le risorse esterne come [[Vista materializzata|viste materializzate]] su uno [[schema virtuale mediato]], con conseguente "integrazione dei dati virtuale". Ciò significa che gli sviluppatori dell'applicazione costruiscano uno schema virtuale — lo ''schema mediato'' — per meglio modellare il tipo di risposte che i loro utenti desiderano. Successivamente, essi progettano [[wrapper]] o [[adapter]] per ogni sorgente di dati, come il database criminologico e il sito meteorologico. Questi adapter semplicemente trasformano i risultati delle ''query'' locali (quelli restituiti dai rispettivi siti o database) in una forma facilmente facilmente elaborata per la soluzione integrata. Quando un utente interroga lo schema mediato, la soluzione integrata trasforma la ''query'' in un'appropriata ''query'' sulle rispettive sorgenti di dati. Infine, il database virtuale raggruppa i risultati di quelle ''query'' nella risposta alla ''query'' dell'utente.
Questa soluzione offre il vantaggio di poter aggiungere nuove sorgenti semplicemente costruendo un adapter o un software di contatto apposito.
Riga 51:
===Definizioni===
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>. L'[[Ottimizzazione di query|elaborazione delle ''query'']] 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.
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''.
===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
In termini di integrazione dei dati, il "contenimento delle ''query''" rappresenta un'importante proprietà delle ''query'' congiuntive. Una ''query'' <math>A</math> contiene un'altra
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.
==Strumenti per Data Integration==
| |||