Indietro

ⓘ Data integration




Data integration
                                     

ⓘ Data integration

La locuzione data integration si riferisce ai processi da attuare su dati provenienti da diverse sorgenti informative per fornire allutente una visione unificata di quei dati.

                                     

1. Storia

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 linteroperabilità di basi di dati eterogenee. Il primo sistema di integrazione dei dati guidato da metadati strutturati è stato progettato presso lUniversità 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. Rendendo interoperabili centinaia di basi di dati relative alla popolazione, IPUMS ha dimostrato la praticabilità di integrazione di dati su larga scala. Lapproccio data warehouse offre unarchitettura 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.

Lapproccio 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 uninterfaccia di interrogazione solo su dati sintetizzati e non si ha accesso alla loro totalità. Questo problema sorge frequentemente quando si integrano diversi servizi di interrogazione commerciale quali viaggi o applicazioni web con pubblicità classificata.

A partire dal 2009 landamento nella data integration ha laccoppiamento tra dati fornendo uninterfaccia unificata per laccesso 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 lapproccio 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 sullintegrazione dei dati si occupa del problema dellintegrazione semantica. Questo problema non riguarda il modo di strutturare larchitettura 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 nellaltro potrebbe rappresentare il numero di vendite espresse in numero intero. Una strategia comune per la risoluzione di tali problemi implica luso di ontologie che definiscano esplicitamente i termini dello schema e quindi aiutino a risolvere i conflitti semantici. Questo approccio rappresenta lintegrazione dei dati basata su ontologie. Daltra 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.

A partire dal 2011 ci si è resi conto che i metodi di modellazione dei dati attuali stavano imprimendo lisolamento 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 lartefatto e per promuovere lo sviluppo di modelli di dati integrati. 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, linsieme 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 data hub rispetto ai data warehouse completamente strutturati tipicamente relazionali. 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. Questi approcci combinano dati non strutturati o diversi in ununica posizione, ma non richiedono necessariamente uno schema relazionale principale, spesso complesso, per strutturare e definire tutti i dati contenuti.

                                     

2. Descrizione

Questo processo si rivela importante in molteplici situazioni, nellambito sia commerciale si pensi a due imprese che debbano unire i loro database sia scientifico per esempio, combinare risultati da diversi archivi 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. Questa materia è diventata il centro di un ampio lavoro tecnico, e numerosi problemi aperti restano irrisolti.

                                     

2.1. Descrizione Esempio

Si consideri una applicazione web in cui un utente può richiedere una varietà di informazioni sulle città. 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 viste materializzate su uno schema virtuale mediato, con conseguente "integrazione dei dati virtuale". Ciò significa che gli sviluppatori dellapplicazione 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 elaborata per la soluzione integrata. Quando un utente interroga lo schema mediato, la soluzione integrata trasforma la query in unappropriata query sulle rispettive sorgenti di dati. Infine, il database virtuale raggruppa i risultati di quelle query nella risposta alla query dellutente.

Questa soluzione offre il vantaggio di poter aggiungere nuove sorgenti semplicemente costruendo un adapter o un software di contatto apposito. È in contrasto con i sistemi ETL o con una soluzione a unico database, che richiedono integrazione manuale del nuovo intero dataset nel sistema. La soluzione ETL virtuale influenza lo schema virtuale mediato per implementare larmonizzazione dei dati, per cui i dati sono copiati dalla sorgente designata come "principale" agli obiettivi definiti, campo per campo. La virtualizzazione dati avanzata è costruita anche sul concetto di modellazione orientata agli oggetti, al fine di costruire schemi virtuali mediati o archivi di metadati virtuali utilizzando larchitettura hub and spoke.

Ogni sorgente di dati è variegata e come tale non è progettata per sostenere unioni attendibili con altre sorgenti. Quindi la virtualizzazione dei dati, così come la federazione dei dati, dipende dalla omogeneità fortuita dei dati per supportare la combinazione di dati e informazioni da sorgenti di dati variegati. A causa di questa mancanza di omogeneità tra i dati, linsieme risultante potrebbe essere impreciso, incompleto o impossibile da validare.

Una soluzione è quella di rimaneggiare i database eterogenei per integrarli senza la necessità di ETL. I database rimaneggiati supportano vincoli di omogeneità in cui lintegrità referenziale può essere forzata tra database. Inoltre questi database rimodellati forniscono vie di accesso ai dati progettati con omogeneità di valori tra database.



                                     

3. Teoria dellintegrazione dei dati

La teoria dellintegrazione 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, compresi quelli che includono relazionale nidificato o basi di dati XML e quelli che trattano i database come programmi. 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.

                                     

3.1. Teoria dellintegrazione dei dati Definizioni

I sistemi di data integration sono formalmente definiti da una tripla ⟨ G, S, M ⟩ {\displaystyle \left\langle G,S,M\right\rangle } dove G {\displaystyle G} è lo schema globale, S {\displaystyle S} è linsieme eterogeneo degli schemi sorgente, e M {\displaystyle M} è la mappatura che associa query tra le sorgenti e lo schema globale. Entrambi G {\displaystyle G} e S {\displaystyle S} sono espresse in linguaggio su alfabeti composti da simboli per ognuna delle rispettive relazioni. La mappatura M {\displaystyle M} consiste di asserzioni tra query su G {\displaystyle G} e query su S {\displaystyle S}. Quando gli utenti pongono uninterrogazione sul sistema di data integration, essi pongono interrogazioni su G {\displaystyle G} 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 S {\displaystyle S} dovrebbe comprendere linsieme 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 G {\displaystyle G} è chiamato database globale. Il database locale deve soddisfare la mappatura M {\displaystyle M} rispetto al database sorgente. La legittimità di questa mappatura dipende dalla natura della corrispondenza tra G {\displaystyle G} e S {\displaystyle S}. 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 viste su S {\displaystyle S}. In questo caso M {\displaystyle M} associa a ogni elemento di G {\displaystyle G} una interrogazione su S {\displaystyle S}. Lelaborazione delle query diventa unoperazione semplice grazie alle associazioni ben definite tra G {\displaystyle G} e S {\displaystyle S}. Lonere della complessità cade sullimplementazione del codice del mediatore in modo che istruisca il sistema di data integration nellesatta 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ò lapproccio GAV sembra preferibile quando le sorgenti hanno una bassa probabilità di cambiare.

Nellapproccio GAV al sistema di data integration nellesempio, 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 dellopportuno 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 G {\displaystyle G}. In questo caso M {\displaystyle M} associa ad ogni elemento di S {\displaystyle S} una interrogazione su G {\displaystyle G}. Qui le esatte associazioni tra G {\displaystyle G} e S {\displaystyle S} non sono più ben definite. Come illustrato nella prossima sezione, lonere di scegliere come recuperare gli elementi dalle sorgenti ricade sullelaboratore 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ò lapproccio 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 dellesempio 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 o un 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 allelaboratore di query.

                                     

3.2. Teoria dellintegrazione dei dati Elaborazione di query

La teoria dellelaborazione di query in un sistema di data integration systems è comunemente espressa utilizzando interrogazioni congiuntive interrogazioni e Datalog, un linguaggio di programmazione logica puramente dichiarativo. Si può liberamente pensare ad una query come una funzione logica applicata alle relazioni del database come f A, B {\displaystyle fA,B} dove A < B {\displaystyle A