Data integration: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
template citazione; rinomina/fix nomi parametri; converto template cite xxx -> cita xxx; parametri non usati su it.wiki |
m Bot: numeri di pagina nei template citazione |
||
| (50 versioni intermedie di 31 utenti non mostrate) | |||
Riga 1:
La [[locuzione]] '''
{{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>▼
== Storia ==▼
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]]).▼
[[File:DataWarehouse.png|thumb|right|Figura 1: Semplice diagramma di un data warehouse. Il processo [[Extract, transform, load|ETL]] estrae informazioni dai database sorgenti, le trasforma e le carica nel data warehouse.]]
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 IDC: World Created 161 Billion Gigs of Data in 2006}}</ref>▼
Questa materia è diventata il centro di un ampio lavoro tecnico, e numerosi problemi aperti restano irrisolti.▼
[[File:DataIntegration.png|thumb|right|Figura 2: Semplice diagramma di una soluzione di data-integration. Un progettista di sistema costruisce uno schema mediato attraverso cui gli utenti possono eseguire le query. Il database virtuale si interfaccia con i database sorgenti attraverso un [[wrapper]], se necessario.]]
Problemi nella combinazione di fonti di dati
▲==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
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
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=
L'approccio data warehouse è meno realizzabile per insiemi di dati aggiornati frequentemente: ciò richiede la continua esecuzione del processo ''[[
Questo problema sorge frequentemente quando si integrano diversi servizi di interrogazione commerciale quali viaggi o applicazioni web con pubblicità classificata.
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 [[
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.
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=
A partire dal 2011 ci si è resi
Un metodo di modellazione dei dati avanzato rimaneggia i modelli di dati aumentandoli con metadati strutturali, sotto forma di entità di dati standardizzate. Come risultato della riscrittura di modelli multipli di dati, l'insieme dei modelli di dati rimaneggiati condivide uno o più relazioni di omogeneità che riguardano i metadati strutturali ora comuni a questi modelli di dati. Le relazioni di omogeneità sono un tipo di relazione peer-to-peer tra entità, che legano le entità di dati dei modelli multipli standardizzati. I modelli di dati multipli che contengono la stessa entità di dati standard possono partecipare alla stessa relazione di omogeneità. Quando i modelli di dati integrati sono istanziati come banche dati e sono adeguatamente popolati da una serie comune di dati principali, questi database vengono integrati.
Dal 2011, gli approcci di maggiore interesse per la disciplina si sono rivolti maggiormente al [[
Dal 2013 gli approcci di tipo data lake sono arrivati al livello dei data hub.(Si vedano le popolarità dei tre termini di ricerca su Google Trends.<ref>{{Cita web|titolo=Hub Lake and Warehouse search trends|url=https://www.google.com/trends/explore#q=enterprise%20data%20warehouse%2C%20%22data%20hub%22%2C%20%22data%20lake%22&cmpt=q&tz=Etc%2FGMT%2B5}}</ref>
Questi approcci combinano dati non strutturati o diversi in un'unica posizione, ma non richiedono necessariamente uno schema relazionale principale, spesso complesso, per strutturare e definire tutti i dati contenuti.
==
▲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
▲Questa materia è diventata il centro di un ampio lavoro tecnico, e numerosi problemi aperti restano irrisolti.
=== 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
Questa soluzione offre il vantaggio di poter aggiungere nuove sorgenti semplicemente costruendo un adapter o un software di contatto apposito.
Riga 44 ⟶ 49:
I database rimaneggiati supportano vincoli di omogeneità in cui l'integrità referenziale può essere forzata tra database. Inoltre questi database rimodellati forniscono vie di accesso ai dati progettati con omogeneità di valori tra database.
== Teoria dell'integrazione dei dati ==
La teoria dell'integrazione dei dati costituisce un sottoinsieme della teoria delle basi di dati e formalizza i concetti di fondo del problema attraverso la [[logica del primo ordine]].
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>{{Cita web|url=
Le connessioni a particolari [[DBMS]] quali [[Oracle Database|Oracle]] o [[IBM DB2|DB2]] sono fornite dalle tecnologie a livello di implementazione, come [[JDBC]], e non sono studiate a livello teorico.
=== 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
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.
[[File:GAVLAV_ita.png|thumb|right|Figura 3: Illustrazione dello spazio delle tuple nelle mappature GAV e LAV.<ref name="refseven">{{Cita pubblicazione|autore=Christoph Koch |titolo=Data Integration against Multiple Evolving Autonomous Schemata |anno=2001 |url=http://www.csd.uoc.gr/~hy562/Papers/thesis_final.pdf |urlmorto=sì |urlarchivio=https://web.archive.org/web/20070926211342/http://www.csd.uoc.gr/~hy562/Papers/thesis_final.pdf |dataarchivio=26 settembre 2007 }}</ref> In GAV, il sistema è vincolato all'insieme di tuple mappate dai mediatori mentre l'insieme delle tuple esprimibili sulle sorgenti potrebbe essere più vasto e ricco. In LAV, il sistema è vincolato all'insieme delle tuple nelle sorgenti mentre l'insieme delle tuple esprimibili sullo schema globale può essere più vasto. Perciò, i sistemi LAV devono spesso gestire risposte incomplete.]]
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.
Riga 60 ⟶ 67:
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'' ===
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=
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=
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.
* Alteryx
* Analytics Canvas
*
*
* DataWatch
*[https://web.archive.org/web/20180828030206/https://www.datawerks.com/ dataWerks]
*
* elastic.io Integration Platform
* HiperFabric<ref>{{Cita web |url=http://www.hiperfabric.com/ |titolo=Copia archiviata |accesso=2 ottobre 2019 |urlarchivio=https://web.archive.org/web/20180320161957/http://hiperfabric.com/ |dataarchivio=20 marzo 2018 |urlmorto=sì }}</ref>
* Microsoft PowerQuery
* Lavastorm
* Informatica Platform<ref>{{cita
* Oracle Data Integration Services
* ParseKit (enigma.io)
* Paxata
*
* Red Hat JBoss Data Virtualization. Community project: teiid.
* [[Microsoft Azure|Azure]] Data Factory (ADF)
* [[SQL Server Integration Services|SQL Server Integration Services (SSIS)]]
*
* WinPure<ref>{{cita web|https://www.winpure.com|WinPure|lingua=en}}</ref>
== ''Data integration'' nella vita scientifica ==
Interrogativi scientifici su larga scala, come il riscaldamento globale, la diffusione di specie infestanti e l'esaurimento delle risorse richiedono sempre più la raccolta di dati eterogenei per la meta-analisi. Questo tipo di integrazione è particolarmente impegnativa per i dati ambientali ed ecologici, perché gli standard sui metadati non concordati e ci sono molti tipi diversi di dati prodotti in questi campi. Le iniziative della [[National Science Foundation]] come Datanet hanno lo scopo di facilitare agli scienziati l'integrazione dei dati, fornendo infrastrutture informatiche e impostazioni standard.
Le cinque iniziative Datanet finanziate sono:
Riga 103 ⟶ 112:
# Terra Populus, guidata da Steven Ruggles della [[University of Minnesota]];
La ''The Data Conservancy'' ha di recente esplorato la creazione di strutture globali di integrazione.
Il progetto OpenPHACTS, finanziato attraverso l'Iniziativa su Medicinali Innovativi dell'[[Unione
== Note ==
<references/>
== Bibliografia ==
▲* {{Cita conferenza|autore=[[Maurizio Lenzerini
== Voci correlate ==
* [[Base di dati]]
* [[Dato]]
{{Controllo di autorità}}
{{Portale|informatica}}
[[Categoria:Terminologia informatica]]
| |||