Versione delle 12:46, 7 dic 2016 modifica Jaqen (discussione \| contributi) Burocrati, Amministratori 72 080 modifiche -F ← Differenza precedente		Versione delle 13:58, 7 dic 2016 modifica annulla Marcosartini (discussione \| contributi) 39 modifiche →‎Esempio Differenza successiva →
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. È in contrasto con i sistemi [[Extract, transform, load\|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 l'armonizzazione 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 l'architettura [[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 [[Sistema di base di dati federato\|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, l'insieme 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 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==

Data integration: differenze tra le versioni