Data integration: differenze tra le versioni

Versione delle 08:36, 26 lug 2018

Versione delle 14:06, 12 dic 2018

Riga 30:

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.

== CaratteristicheDescrizione ==

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

=== 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 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.