Data integration: differenze tra le versioni

Versione delle 03:34, 17 apr 2023

Versione attuale delle 01:33, 16 mar 2025

(2 versioni intermedie di 2 utenti non mostrate)

Riga 8:

Problemi nella combinazione di fonti di dati eterogenee, spesso identificati come silos di informazioni, attraverso una singola interfaccia per ''[[query]]'' esistettero per diverso tempo.

Nei primi [[anni ottanta]] del [[XX secolo]] i tecnici informatici cominciarono a progettare sistemi per l'interoperabilità di basi di dati eterogenee.<ref>{{Cita news|autore= John Miles Smith |titolo= Multibase: integrating heterogeneous distributed database systems |anno=1982 |rivista=AFIPS '81 Proceedings of the May 4–7, 1981, national computer conference |pp= 487–499487-499 |url=https://dl.acm.org/citation.cfm?id=1500483}}</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 un'unica vista, affinché i dati diventino compatibili.<ref>{{Cita news|autore= [[Steven Ruggles]], J. David Hacker, and Matthew Sobek |titolo= Order out of Chaos: The Integrated Public Use Microdata Series |url= https://archive.org/details/sim_historical-methods_winter-1995_28_1/page/33 |anno=1995 |rivista=Historical Methods |volume=28 |pp= 33–3933-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>{{Cita news|autore= Jennifer Widom |titolo= Research problems in data warehousing |anno=1995 |rivista=CIKM '95 Proceedings of the fourth international conference on information and knowledge management |pp= 25–3025-30 |url=https://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 ''[[extract, transform, load]]'' (ETL) 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 20:

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.

Questo approccio rappresenta l'integrazione dei dati basata su ontologie.

D'altra parte, il problema di combinare i risultati di ricerca da archivi bioinformatici differenti richiede benchmarking delle somiglianze calcolato a partire da diverse fonti di dati su un unico criterio, per esempio il valore predittivo positivo. Ciò abilita le diverse fonti a un confronto diretto, e possono essere integrate anche quando la natura degli esperimenti è distinta.<ref>{{Cita pubblicazione|url=http://shubhrasankar.tripod.com/cgi-bin/combiningMultisourceIEEE.pdf |rivista=IEEE Transactions on Biomedical Engineering |titolo=Combining Multi-Source Information through Functional Annotation based Weighting: Gene Function Prediction in Yeast|autore=Shubhra S. Ray|volume= 56 |pp=229–236229-236 | pmid=19272921 |anno=2009|numero=2 | doi=10.1109/TBME.2008.2005955}}</ref>

A partire dal 2011 ci si è resi conto che i metodi di modellazione dei dati attuali stavano imprimendo l'isolamento dei dati in ogni architettura sotto forma di isole di dati disparati e silos di informazioni. Questo isolamento dei dati è un artefatto involontario della metodologia di modellazione dati che provoca lo sviluppo di modelli di dati dissimili. Modelli di dati dissimili, quando stoccati in basi di dati, formano basi di dati dissimili. Modelli avanzati di dati sono stati sviluppati per eliminare l'artefatto e per promuovere lo sviluppo di modelli di dati integrati.<ref>{{Cita news|autore= Michael Mireku Kwakye |titolo= A Practical Approach To Merging Multidimensional Data Models |anno=2011 |url=https://hdl.handle.net/10393/20457 }}</ref><ref>{{Cita web |url=http://www.iri.com/pdf/RapidAce-Brochure.pdf |titolo=Rapid Architectural Consolidation Engine&nbsp;– The enterprise solution for disparate data models. |anno=2011 |accesso=5 dicembre 2016 |urlarchivio=https://web.archive.org/web/20150924040201/http://www.iri.com/pdf/RapidAce-Brochure.pdf |dataarchivio=24 settembre 2015 |urlmorto=sì }}</ref>

Riga 31:

== Descrizione ==

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]]).

La ''data integration'' compare con sempre maggior frequenza, allo stesso modo in cui sta esplodendo il volume e la necessità di condividere i dati esistenti.<ref name="DataExplode">{{Cita news |autore=Frederick Lane |titolo=IDC: World Created 161 Billion Gigs of Data in 2006 |anno=2006 |url=http://www.toptechnews.com/story.xhtml?story_id=01300000E3D0&full_skip=1 |accesso=5 dicembre 2016 |dataarchivio=24 febbraio 2012 |urlarchivio=https://web.archive.org/web/20120224044826/http://www.toptechnews.com/story.xhtml?story_id=01300000E3D0&full_skip=1 |urlmorto=sì }}</ref>

Questa materia è diventata il centro di un ampio lavoro tecnico, e numerosi problemi aperti restano irrisolti.

Riga 55:

=== Definizioni ===

I sistemi di ''data integration'' sono formalmente definiti da una [[tripla (matematica)|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 le sorgenti e lo schema globale. 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.

Riga 70:

=== 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">{{Cita conferenza|autore=[[Jeffrey D. Ullman]] |articolo=Information Integration Using Logical Views |titolo=ICDT 1997 |anno=1997 |pp=19–4019-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 regola 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''" rappresenta un'importante proprietà delle ''query'' congiuntive. Una ''query'' <math>A</math> contiene un'altra ''query'' <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">{{Cita conferenza|autore=[[Alon Y. Halevy]] |articolo=Answering queries using views: A survey |titolo=The VLDB Journal |anno=2001 |pp=270–294270-294 |url=https://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.

Riga 118:

== Bibliografia ==

* {{Cita conferenza|autore=[[Maurizio Lenzerini]]|articolo=Data Integration: A Theoretical Perspective|titolo=Proceedings of the twenty-first ACM SIGMOD-SIGACT-SIGART symposium on Principles of database systems|conferenza=PODS 2002|anno=2002|pp=233–246233-246|città=Madison, Wisconsin, USA|url=http://www.dis.uniroma1.it/~lenzerin/homepagine/talks/TutorialPODS02.pdf|doi=10.1145/543613.543644|cid=Lenzerini, 2002}}

== Voci correlate ==