La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Sistemi Informativi A. A. 2009/10 Parte I Interoperabilità tra sorgenti informative.

Presentazioni simili


Presentazione sul tema: "Sistemi Informativi A. A. 2009/10 Parte I Interoperabilità tra sorgenti informative."— Transcript della presentazione:

1 Sistemi Informativi A. A. 2009/10 Parte I Interoperabilità tra sorgenti informative

2 I Database Distribuiti Scopo dei database: integrare i dati operazionali e fornire un accesso controllato ai dati Lo sviluppo delle reti di computer promuove una metodologia decentralizzata di lavoro La condivisione dei dati e lefficienza nel loro accesso dovrebbe essere migliorata dallo sviluppo di un DBMS distribuito che riflette questa struttura organizzativa I DBMS distribuiti dovrebbero aiutare a risolvere il problema delle isole di informazione Introduzione

3 I Database Distribuiti Database distribuito: una collezione logicamente correlata di dati condivisi DBMS distribuito: un sistema software che permette la gestione dei database distribuiti Un database distribuito consiste in un singolo database logico suddiviso in un numero di frammenti Ciascun sito è capace di processare indipendentemente le richieste degli utenti che coinvolgono i dati locali Applicazioni locali e applicazioni globali Concetti fondamentali

4 I Database Distribuiti Un DDBMS ha le seguenti caratteristiche: – È una collezione di dati condivisi logicamente correlati – I dati sono suddivisi in un certo numero di frammenti – I frammenti possono essere replicati – I frammenti e le repliche vengono allocati presso opportuni siti – I siti sono collegati da reti di comunicazione – I dati su ciascun sito sono sotto il controllo di un DBMS – Il DBMS su ciascun sito può gestire applicazioni locali autonomamente – Ciascun DBMS partecipa ad almeno unapplicazione globale Concetti fondamentali

5 I Database Distribuiti Una tipica architettura di DDBMS Concetti fondamentali

6 I Database Distribuiti Esempio: una banca Un DDBMS deve rendere la distribuzione trasparente (ovvero invisibile) allutente La trasparenza pone svariati problemi addizionali Trasparenza e autonomia appaiono essere due proprietà conflittuali Concetti fondamentali

7 I Database Distribuiti I DDBMS riflettono la natura organizzativa delle aziende – Molte organizzazioni sono naturalmente distribuite su diverse locazioni – Ad esempio, in una banca, i membri dello staff della filiale faranno le loro query locali ma il management può effettuare delle query globali – I dati possono essere memorizzati sul sito più vicino agli utenti – Un Amministratore globale ha la responsabilità dellintero sistema I DDBMS migliorano la disponibilità dei dati I DDBMS migliorano laffidabilità I DDBMS migliorano la perfomance Vantaggi

8 I Database Distribuiti I DDBMS abbattono i costi – Legge di Grosch: la potenza di calcolo cresce secondo il quadrato dei costi – Attualmente è generalmente riconosciuto che costa molto meno realizzare un sistema di piccoli computer che abbiano la potenza equivalente di un singolo grosso computer – Se gli utenti di un database sono geograficamente sparsi I DDBMS consentono una crescita modulare Integrazione – Integrazione di sistemi legacy – Nessun pacchetto può fornire oggi tutte le funzionalità necessarie oggi ad unorganizzazione I DDBMS consentono di rimanere competitivi Vantaggi

9 I Database Distribuiti Complessità – Un DBMS distribuito è inerentemente più complessi di un DBMS centralizzato – I dati possono essere replicati Costi Sicurezza Controllo dellintegrità più difficile Mancanza di standard Mancanza di esperienza Progettazione dei database più complessa Svantaggi

10 I Database Distribuiti Processing distribuito: un database centralizzato che può essere acceduto tramite una rete di computer Il sistema consiste di dati che sono fisicamente distributi attraverso un certo numero di siti della rete Distribuzione dei dati in presenza di un processing distribuito Architetture alternative: Processing distribuito

11 I Database Distribuiti Il processing distribuito è conosciuto anche come sistema multidatabase Architetture alternative: Processing distribuito

12 I Database Distribuiti DBMS parallelo: un DBMS che opera su più processori e dischi e che è stato progettato per eseguire operazioni in parallelo I DBMS paralleli sono basati sulla premessa che un singolo processore non riesce a soddisfare le crescenti richieste di scalabilità, affidabilità e performance a basso costo I DBMS paralleli collegano più macchine piccole Un DBMS parallelo deve fornire una gestione delle risorse condivise Tre principali architetture: – Shared memory – Shared disk – Shared nothing Architetture alternative: I DBMS paralleli

13 I Database Distribuiti Le tre principali architetture dei DBMS paralleli Architetture alternative: I DBMS paralleli

14 I Database Distribuiti Larchitettura shared memory è unarchitettura fortemente accoppiata Essa è nota anche come multiprocessing simmetrico Larchitettura shared disk è unarchitettura debolmente accoppiata Larchitettura shared disk elimina il collo di bottiglia che normalmente si ha con larchitettura shared memory I sistemi shared disk sono spesso denominati cluster Larchitettura shared nothing è spesso nota come processing massivamente parallelo Questa architettura è più scalabile di unarchitettura shared memory La performance è ottima solo quando i dati richiesti vengono memorizzati localmente Architetture alternative: I DBMS paralleli

15 I Database Distribuiti Alcune volte la definizione shared nothing include i DBMS distribuiti La tecnologia parallela viene tipicamente utilizzata per database molto grossi Tutti i maggiori distributori di DBMS forniscono la versione parallela dei loro prodotti Architetture alternative: I DBMS paralleli

16 I Database Distribuiti In un sistema omogeneo tutti i siti utilizzano gli stessi DBMS I sistemi omogenei si possono progettare e gestire molto più facilmente rispetto ai sistemi eterogenei In un sistema eterogeneo possono operare diversi DBMS che non devono necessariamente essere basati sul medesimo modello dei dati I singoli siti hanno già implementato i loro database e lintegrazione viene effettuata successivamente Permettere un certo livello di trasparenza I dati possono essere richiesti da un altro sito Se lhardware è diverso ma i DBMS sono gli stessi la traduzione è immediata Se i DBMS sono differenti la traduzione è complicata e comporta il mapping delle strutture dati DDBMS omogenei ed eterogenei

17 I Database Distribuiti Necessità di costruire uno schema concettuale comune Eventuale presenza di eterogeneità semantiche Esempio: casa automobilistica Cars(serialNo, model, color, autoTrans, cdPlayer, …) Autos(serial, model, color) Options(serial, option) Nomi apparentemente equivalenti sono cambiati Differenze nel tipo di dati DDBMS omogenei ed eterogenei

18 I Database Distribuiti Differenze nei valori Differenze semantiche Valori mancanti Tipica soluzione: utilizzo dei gateway – Essa potrebbe non supportare la gestione delle transazioni anche per una coppia di sistemi – Essa mira solo alla traduzione di una query espressa in un linguaggio in una traduzione equivalente espressa in un altro linguaggio DDBMS omogenei ed eterogenei

19 I Database Distribuiti Processing distribuito Sistemi di Database Federati Sistemi Informativi Cooperativi Data Warehouse Principali architetture distribuite

20 I Database Distribuiti Consiste nellimplementare connessioni uno-a-uno tra tutte le coppie di database Se si hanno n database è necessario scrivere n x (n-1) pezzi di codice Sistemi di Database Federati

21 I Database Distribuiti Un sistema di database federati può essere il più facile da costruire quando il numero di DBMS coinvolti è basso Esempio: casa automobilistica NeededCars(model, color, autoTrans) Autos(serial, model, color) Options(serial, option) Il Concessionario 1 vuole interrogare il Concessionario 2 in remoto per conoscere quali sono le automobili di questultimo che soddisfano i requisiti specificati in NeededCars Sistemi di Database Federati

22 I Database Distribuiti Query associata alla problematica precedente Sistemi di Database Federati

23 I Database Distribuiti Se il Concessionario 1 vuole chiedere la stessa cosa al Concessionario 3 che usa lo schema: Cars(serialNo, model, color, autoTrans, …) La query sarebbe differente Sistemi di Database Federati

24 Sistemi Informativi Cooperativi Struttura di un Sistema Informativo Cooperativo Funzionamento

25 Sistemi Informativi Cooperativi Esempio: casa automobilistica Concessionario 1 Cars(serialNo, model, color, autoTrans, cdPlayer, …) Concessionario 2 Autos(serial, model, color) Options(serial, option) Vista globale AutosMed(serialNo, model, color, autoTrans, dealer) Funzionamento

26 Sistemi Informativi Cooperativi Esempio: casa automobilistica Lutente chiede al mediatore macchine rosse: SELECT serialNo, model FROM autosMed WHERE color = red Wrapper al Concessionario 1 SELECT serialNo, model FROM Cars WHERE color = red Wrapper al Concessionario 2 SELECT serial, model FROM Autos WHERE color = red Funzionamento

27 Sistemi Informativi Cooperativi Esempio: casa automobilistica – Il mediatore costruisce lunione dei due insiemi e restituisce il risultato allutente – Si assume che il numero seriale sia una chiave universale – Vi sono diverse opzioni che un mediatore può utilizzare per rispondere ad una query Funzionamento

28 Sistemi Informativi Cooperativi Template: query parametriche Concessionario 1 Cars(serialNo, model, color, autoTrans, cdPlayer) Mediatore AutosMed(serialNo, model, color, autoTrans, dealer) Template: automobili di un determinato colore SELECT * FROM AutosMed WHERE color = $C; SELECT serialNo, model, color, autoTrans, dealer1 FROM Cars WHERE color = $C; Progettazione di un wrapper in un CIS - Template

29 Sistemi Informativi Cooperativi Il wrapper potrebbe avere un altro template che specifica solo il parametro $m che rappresenta un modello In generale, per gestire tutte le combinazioni che si possono ottenere con n attributi, sarebbero necessari 2 n template Il numero di template potrebbe diventare enormemente grande Progettazione di un wrapper in un CIS - Template

30 Sistemi Informativi Cooperativi Esempio: casa automobilistica – Si supponga che ad un wrapper su un database di un concessionario di automobili sia stato associato il template che consente di selezionare le automobili in base al colore – Supponiamo che al mediatore venga richiesto di individuare le automobili con un determinato modello e un determinato colore – Template: SELECT * FROM AutosMed WHERE model = $m AND color = $C; SELECT serialNo, model, color, autoTrans, dealer1 FROM Cars WHERE model = $m AND color = $C; Progettazione di un wrapper in un CIS - Filtri

31 Sistemi Informativi Cooperativi Approccio alternativo: il wrapper prima effettui lesecuzione di alcuni template generici e, successivamente, effettui un opportuno filtraggio per rispondere alle query Riuscire a comprendere se una query di un mediatore richieda un sottoinsieme di ciò che viene restituito da qualche template sul wrapper è, in generale, un problema difficile Esempio: casa automobilistica – Abbiamo il template sul colore – Vogliamo trovare automobili di colore blu ma il cui modello è Focus – Query al mediatore: SELECT * FROM AutosMed WHERE model = blu AND model= Focus; Progettazione di un wrapper in un CIS - Filtri

32 Sistemi Informativi Cooperativi Esempio: casa automobilistica – Utilizzare il template del colore con $C = blu per trovare tutte le automobili blu – Memorizzare il risultato in una relazione temporanea TempAutos(serialNo, model, color, autoTrans, dealer) – Selezionare da TempAutos il modello Focus e restituire il risultato, mediante la query: SELECT * FROM TempAutos WHERE model = Focus – Le tuple di TempAutos sarebbero prodotte una alla volta e immediatamente filtrate Le operazioni di filtraggio possono avvenire anche sul Mediatore Progettazione di un wrapper in un CIS - Filtri

33 Sistemi Informativi Cooperativi È possibile trasformare i dati sul wrapper secondo altre modalità Le colonne possono essere opportunamente proiettate prima di trasmettere i dati al mediatore È possibile effettuare aggregazioni o join sul wrapper Esempio: casa automobilistica – Il mediatore vuole conoscere le macchine blu Focus presenti nei vari concessionari, ma vuole sapere soltanto il numero seriale, il concessionario e se hanno o meno il cambio automatico – Query del wrapper su TempAutos : SELECT serialNo, autoTrans, dealer FROM TempAutos WHERE model = Focus Progettazione di un wrapper in un CIS – Altre operazioni sul wrapper

34 Sistemi Informativi Cooperativi Esempio: casa automobilistica – Si supponga che al mediatore venga chiesto di trovare i concessionari e i modelli tali che il concessionario abbia due macchine rosse, dello stesso modello, una con e una senza il cambio automatico. Si supponga, cioè, che il mediatore chieda al wrapper di rispondere alla seguente query: SELECT A1.model, A1.dealer FROM AutosMed A1, AutosMed A2 WHERE A1.model = A2.model AND A1.color = red AND A2.color = red AND A1.autoTrans = no AND A2.autoTrans = yes AND A1.dealer = A2.dealer; – Consideriamo il wrapper relativo al Concessionario 1 e supponiamo che lunico template utile sia quello sui colori Progettazione di un wrapper in un CIS – Altre operazioni sul wrapper

35 Sistemi Informativi Cooperativi Esempio: casa automobilistica – Il wrapper, innanzitutto, applica il template sui colori ponendo $c = rosso e ottiene la relazione RedAutos(serialNo, model, color, autoTrans, dealer) – Successivamente pone in join RedAutos con se stessa ed esegue la relazione necessaria secondo la query: SELECT DISTINCT A1.model, A1.dealer FROM RedAutos A1, AutosMed A2 WHERE A1.model = A2.model AND A1.autoTrans = no AND A2.autoTrans = yes; – In questo modo ottiene il risultato desiderato – Questultima operazione potrebbe essere eseguita a livello di mediatore piuttosto che di wrapper. Progettazione di un wrapper in un CIS – Altre operazioni sul wrapper

36 Sistemi Informativi Cooperativi La progettazione di un mediatore consiste nella creazione di un database virtuale unico La generazione del database globale avviene mediante unoperazione denominata integrazione Correlazioni semantiche Diverse sorgenti sono state progettate da diversi individui Le sorgenti informative coinvolte possono risultare semanticamente eterogenee Il processo di integrazione non è una semplice fusione Progettazione di un mediatore

37 Sistemi Informativi Cooperativi Il processo di integrazione può essere effettuato a due livelli: – A livello intensionale, per fondere gli schemi – A livello estensionale, per fondere i dati Le sorgenti coinvolte in un processo di integrazione possono avere formati differenti La vera difficoltà da affrontare è leterogeneità semantica dei dati Progettazione di un mediatore

38 Lintegrazione di sorgenti informative eterogenee I dati in gioco in un DDBMS sono ricavati da un insieme di sorgenti eterogenee Schema locale di una sorgente Le varie sorgenti possono essere fortemente correlate o completamente indipendenti Lanalisi delle fonti operazionali non è di per sé sufficiente Dopo lanalisi risulta necessario un processo di riconciliazione che prevede integrazione, pulizia e trasformazione La fase di integrazione è incentrata sulla componente intensionale Pulizia e trasformazione dei dati operano a livello estensionale Introduzione

39 Lintegrazione di sorgenti informative eterogenee Le fasi che permettono di effettuare la riconciliazione dei dati Introduzione

40 Lintegrazione di sorgenti informative eterogenee Il quadro generale per la fase di analisi e riconciliazione è abbastanza complesso Passi progettuali che compongono la fase di analisi e riconciliazione di due sorgenti Introduzione

41 Lintegrazione di sorgenti informative eterogenee Sebbene il collegamento dei dati sia realizzato a livello logico, lutilizzo di formalismi di livello concettuale è fortemente consigliato Nel caso in cui si presentino situazioni più semplici sarà sufficiente eliminare le fasi non richieste Gli schemi concettuali delle sorgenti rappresentano senzaltro il risultato principale dellanalisi Introduzione

42 Lintegrazione di sorgenti informative eterogenee Il progettista deve acquisire unapprofondita conoscenza delle sorgenti coinvolte attraverso attività di: – Ricognizione – Normalizzazione La fase di ricognizione e normalizzazione deve essere svolta anche qualora sia presente una sola sorgente dati Il progettista deve verificare la completezza degli schemi locali sforzandosi di individuare eventuali correlazioni involontariamente omesse Le trasformazioni apportate allo schema non devono introdurre nuovi concetti bensì rendere espliciti tutti quelli ricavabili Ricognizione e normalizzazione degli schemi

43 Lintegrazione di sorgenti informative eterogenee Trasformazioni lecite e illecite durante la fase di ricognizione e normalizzazione di una sorgente Ricognizione e normalizzazione degli schemi

44 Lintegrazione di sorgenti informative eterogenee Questo problema è oggetto di studio da ormai 20 anni Attualmente lattività di ricerca è concentrata sullautomazione del processo di integrazione Essa consiste nellindividuazione delle corrispondenze tra concetti rappresentati negli schemi locali e nella risoluzione dei conflitti evidenziati Se le diverse sorgenti dati modellassero porzioni indipendenti e distinte del mondo reale il problema dellintegrazione non sussisterebbe In pratica ciò non avviene Inoltre, il processo di informatizzazione di un sistema informativo è di tipo incrementale ed evolutivo A ciò si aggiungono errori di modellazione e di implementazione Il problema dellintegrazione

45 Lintegrazione di sorgenti informative eterogenee Proprietà inter-schema È necessario utilizzare un unico formalismo Il formalismo prescelto dovrebbe essere quello che garantisce il maggior potere espressivo Il problema dellintegrazione

46 Lintegrazione di sorgenti informative eterogenee Il punto di vista rispetto al quale diversi gruppi di utenti vedono uno stesso concetto può differenziarsi notevolmente Esempio: assegnamento dei dipendenti ai dipartimenti Il problema dellintegrazione – Diversità di prospettiva

47 Lintegrazione di sorgenti informative eterogenee Rappresentare uno stesso concetto utilizzando combinazioni diverse dei costrutti Esempio: legame tra libri e case editrici Il problema dellintegrazione – Equivalenza dei costrutti del modello

48 Lintegrazione di sorgenti informative eterogenee Schemi differenti che modellano una stessa porzione del dominio applicativo racchiudono concetti diversi Esempio: associazione tra professori universitari e corsi Il problema dellintegrazione – Incompatibilità delle specifiche Le assunzioni fatte in un certo momento potrebbero non essere più vere successivamente

49 Lintegrazione di sorgenti informative eterogenee Tipo di relazione semantica esistente tra concetti comuni Quattro sono le possibili relazioni esistenti Identità Equivalenza – Definizione di Rissanen: due schemi sono equivalenti se le loro istanze possono essere messe in corrispondenza uno-a-uno – Lequivalenza implica che a livello estensionale esistano sempre due insiemi di dati, diversi ma equivalenti, che memorizzano le stesse informazioni Il problema dellintegrazione – Concetti comuni

50 Lintegrazione di sorgenti informative eterogenee Equivalenza – Due istanze per gli schemi equivalenti relativi allo schema con i libri e le case editrici visto precedentemente Il problema dellintegrazione – Concetti comuni

51 Lintegrazione di sorgenti informative eterogenee Comparabilità – Gli schemi relativi allassegnamento dei dipendenti ai dipartimenti sono tra loro comparabili Incompatibilità – Gli schemi relativi allassociazione tra professori universitari e corsi visti precedentemente sono tra loro incompatibili Ad esclusione della situazione di identità tutti gli altri casi determinano dei conflitti Il problema dellintegrazione – Concetti comuni

52 Lintegrazione di sorgenti informative eterogenee A seguito dellintegrazione molti concetti diversi ma correlati verranno a trovarsi nello stesso schema dando vita a nuove relazioni che non erano percepibili in precedenza Il problema dellintegrazione – Concetti correlati

53 Lintegrazione di sorgenti informative eterogenee Risolvere i problemi fin qui elencati richiede un complesso insieme di operazioni I passi da effettuare possono essere così sintetizzati: – Preintegrazione – Comparazione degli schemi – Allineamento degli schemi – Fusione e ristrutturazione degli schemi Le fasi dellintegrazione

54 Lintegrazione di sorgenti informative eterogenee Durante questa fase viene svolta lanalisi vera e propria delle sorgenti dati Le principali decisioni da prendere riguardano: – Le porzioni degli schemi che dovranno essere integrate – La strategia dellintegrazione Le fasi dellintegrazione - Preintegrazione

55 Lintegrazione di sorgenti informative eterogenee Le principali decisioni da prendere riguardano: – Tecniche ennarie e tecniche binarie – La maggior parte delle metodologie proposte in letteratura predilige lapproccio binario – Tecnica binaria a scala: consente di definire lordine di esame degli schemi da integrare – Il progettista dovrà verificare la qualità dei dati contenuti allinterno delle sorgenti Le fasi dellintegrazione - Preintegrazione

56 Lintegrazione di sorgenti informative eterogenee Analisi comparativa dei diversi schemi che mira a identificare le correlazioni e i conflitti tra i concetti in essi espressi Il progettista non può prescindere dal collaborare con gli amministratori e gli utenti I tipi di conflitti ricadono nelle seguenti categorie: – Conflitti di eterogeneità – Conflitti sui nomi Sinonimie e omonimie Individuazione delle omonimie e individuazione delle sinonimie Una corretta documentazione di questo tipo di conflitto si può ottenere mediante dizionari dati Le fasi dellintegrazione – Comparazione degli schemi

57 Lintegrazione di sorgenti informative eterogenee I tipi di conflitti ricadono nelle seguenti categorie: – Conflitti sui nomi Esempi di sinonimie e omonimie Le fasi dellintegrazione – Comparazione degli schemi

58 Lintegrazione di sorgenti informative eterogenee I tipi di conflitti ricadono nelle seguenti categorie: – Conflitti semantici Gli schemi relativi allassegnamento dei dipendenti ai dipartimenti visti in precedenza sono in conflitto semantico Esempio ulteriore: Le fasi dellintegrazione – Comparazione degli schemi

59 Lintegrazione di sorgenti informative eterogenee I tipi di conflitti ricadono nelle seguenti categorie: – Conflitti strutturali Conflitti di tipo (le rappresentazioni per modellare il legame tra libri e case editrici viste in precedenza) Conflitti di dipendenza Le fasi dellintegrazione – Comparazione degli schemi Conflitti di chiave Conflitti di comportamento

60 Lintegrazione di sorgenti informative eterogenee Lindividuazione delle correlazioni richiede unapprofondita conoscenza della semantica degli elementi coinvolti Le fasi dellintegrazione – Comparazione degli schemi

61 Lintegrazione di sorgenti informative eterogenee Scopo di questa fase è la risoluzione dei conflitti evidenziatisi al passo precedente Tipiche primitive di trasformazione riguardano il cambio dei nomi, la modifica delle dipendenze funzionali, etc. Non sempre i conflitti possono essere risolti (esempio: il conflitto relativo allassociazione tra professori universitari e corsi visto in precedenza) In caso di incertezza si preferiscono le trasformazioni che avvantaggiano gli schemi ritenuti centrali A cominciare da questa fase il progettista deve definire il mapping tra gli elementi degli schemi sorgente e quelli dello schema riconciliato Le fasi dellintegrazione – Allineamento degli schemi

62 Lintegrazione di sorgenti informative eterogenee Durante questa fase gli schemi allineati vengono fusi a formare un unico schema riconciliato Vengono sovrapposti i concetti comuni a cui saranno collegati tutti i rimanenti concetti Possono essere necessarie ulteriori trasformazioni per garantire le seguenti proprietà: – Completezza – Minimalità – Leggibilità Le fasi dellintegrazione – Fusione e ristrutturazione degli schemi

63 Lintegrazione di sorgenti informative eterogenee – Due schemi equivalenti con un diverso livello di leggibilità Le fasi dellintegrazione – Fusione e ristrutturazione degli schemi

64 Lintegrazione di sorgenti informative eterogenee Il risultato dellanalisi prevede lo schema riconciliato e linsieme delle corrispondenze tra gli elementi presenti negli schemi sorgente e quelli dello schema riconciliato Queste corrispondenze giocano un ruolo cruciale Approccio GAV (Global-As-View): ad ogni concetto dello schema globale deve essere associata una vista il cui significato è definito in base ai concetti che risiedono sugli schemi sorgente La modalità con cui vengono definite le corrispondenze incide sulla formulazione delle interrogazioni utilizzate negli strumenti ETL per il caricamento dei dati Con la soluzione GAV sarà sufficiente lunfolding La semplicità di formulazione delle interrogazioni viene pagata in termini di estendibilità dello schema riconciliato Definizione delle corrispondenze

65 Lintegrazione di sorgenti informative eterogenee Due mapping di tipo GAV nellambito di un sistema di ordini Definizione delle corrispondenze

66 Lintegrazione di sorgenti informative eterogenee Approccio LAV (Local-As-View): lo schema globale è espresso indipendentemente dalle sorgenti i cui concetti saranno definiti come viste sullo schema globale Questa soluzione richiede trasformazioni più complesse indicate in generale con il termine query rewriting Lapproccio LAV favorisce lestensibilità dello schema riconciliato Definizione delle corrispondenze


Scaricare ppt "Sistemi Informativi A. A. 2009/10 Parte I Interoperabilità tra sorgenti informative."

Presentazioni simili


Annunci Google