Sistemi Informativi A. A

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

I Database Distribuiti
Introduzione 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 l’efficienza 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

Concetti fondamentali 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 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 un’applicazione globale

Concetti fondamentali Una tipica architettura di DDBMS

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

Vantaggi 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à dell’intero sistema I DDBMS migliorano la disponibilità dei dati I DDBMS migliorano l’affidabilità I DDBMS migliorano la perfomance

Vantaggi 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 un’organizzazione I DDBMS consentono di rimanere competitivi

Svantaggi Complessità Un DBMS distribuito è inerentemente più complessi di un DBMS centralizzato I dati possono essere replicati Costi Sicurezza Controllo dell’integrità più difficile Mancanza di standard Mancanza di esperienza Progettazione dei database più complessa

Architetture alternative: Processing distribuito 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 Il processing distribuito è conosciuto anche come sistema multidatabase

Architetture alternative: I DBMS paralleli 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 Le tre principali architetture dei DBMS paralleli

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

Architetture alternative: I DBMS paralleli 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

DDBMS omogenei ed eterogenei 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 l’integrazione viene effettuata successivamente Permettere un certo livello di trasparenza I dati possono essere richiesti da un altro sito Se l’hardware è 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 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 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

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

Sistemi di Database Federati Consiste nell’implementare 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 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 quest’ultimo che soddisfano i requisiti specificati in NeededCars

Sistemi di Database Federati Query associata alla problematica precedente

Sistemi di Database Federati 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 Informativi Cooperativi
Funzionamento Struttura di un Sistema Informativo Cooperativo

Funzionamento 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 Esempio: casa automobilistica L’utente chiede al mediatore macchine rosse: SELECT serialNo, model FROM autosMed WHERE color = ‘red’ Wrapper al Concessionario 1 FROM Cars Wrapper al Concessionario 2 SELECT serial, model FROM Autos

Funzionamento Esempio: casa automobilistica Il mediatore costruisce l’unione dei due insiemi e restituisce il risultato all’utente Si assume che il numero seriale sia una chiave universale Vi sono diverse opzioni che un mediatore può utilizzare per rispondere ad una query

Progettazione di un wrapper in un CIS - Template 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

Progettazione di un wrapper in un CIS - Template 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 2n template Il numero di template potrebbe diventare enormemente grande

Progettazione di un wrapper in un CIS - Filtri 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

Progettazione di un wrapper in un CIS - Filtri Approccio alternativo: il wrapper prima effettui l’esecuzione 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 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 – Altre operazioni sul wrapper È 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 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 l’unico template utile sia quello sui colori

Progettazione di un wrapper in un CIS – Altre operazioni sul wrapper 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 Quest’ultima operazione potrebbe essere eseguita a livello di mediatore piuttosto che di wrapper.

Progettazione di un mediatore La progettazione di un mediatore consiste nella creazione di un database virtuale unico La generazione del database globale avviene mediante un’operazione 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 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 è l’eterogeneità semantica dei dati

L’integrazione di sorgenti informative eterogenee
Introduzione 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 L’analisi delle fonti operazionali non è di per sé sufficiente Dopo l’analisi 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 Le fasi che permettono di effettuare la riconciliazione dei dati

Introduzione 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 Sebbene il collegamento dei dati sia realizzato a livello logico, l’utilizzo 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 senz’altro il risultato principale dell’analisi

Ricognizione e normalizzazione degli schemi Il progettista deve acquisire un’approfondita 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 Trasformazioni lecite e illecite durante la fase di ricognizione e normalizzazione di una sorgente

Il problema dell’integrazione Questo problema è oggetto di studio da ormai 20 anni Attualmente l’attività di ricerca è concentrata sull’automazione del processo di integrazione Essa consiste nell’individuazione 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 dell’integrazione 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 dell’integrazione Proprietà inter-schema È necessario utilizzare un unico formalismo Il formalismo prescelto dovrebbe essere quello che garantisce il maggior potere espressivo

Il problema dell’integrazione – Diversità di prospettiva 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 dell’integrazione – Equivalenza dei costrutti del modello Rappresentare uno stesso concetto utilizzando combinazioni diverse dei costrutti Esempio: legame tra libri e case editrici

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

Il problema dell’integrazione – Concetti comuni 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 L’equivalenza implica che a livello estensionale esistano sempre due insiemi di dati, diversi ma equivalenti, che memorizzano le stesse informazioni

Il problema dell’integrazione – Concetti comuni Equivalenza Due istanze per gli schemi equivalenti relativi allo schema con i libri e le case editrici visto precedentemente

Il problema dell’integrazione – Concetti comuni Comparabilità Gli schemi relativi all’assegnamento dei dipendenti ai dipartimenti sono tra loro comparabili Incompatibilità Gli schemi relativi all’associazione 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 dell’integrazione – Concetti correlati A seguito dell’integrazione molti concetti diversi ma correlati verranno a trovarsi nello stesso schema dando vita a nuove relazioni che non erano percepibili in precedenza

Le fasi dell’integrazione 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 dell’integrazione - Preintegrazione Durante questa fase viene svolta l’analisi vera e propria delle sorgenti dati Le principali decisioni da prendere riguardano: Le porzioni degli schemi che dovranno essere integrate La strategia dell’integrazione

Le fasi dell’integrazione - Preintegrazione Le principali decisioni da prendere riguardano: Tecniche ennarie e tecniche binarie La maggior parte delle metodologie proposte in letteratura predilige l’approccio binario Tecnica binaria a scala: consente di definire l’ordine di esame degli schemi da integrare Il progettista dovrà verificare la qualità dei dati contenuti all’interno delle sorgenti

Le fasi dell’integrazione – Comparazione degli schemi 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 dell’integrazione – Comparazione degli schemi I tipi di conflitti ricadono nelle seguenti categorie: Conflitti sui nomi Esempi di sinonimie e omonimie

Le fasi dell’integrazione – Comparazione degli schemi I tipi di conflitti ricadono nelle seguenti categorie: Conflitti semantici Gli schemi relativi all’assegnamento dei dipendenti ai dipartimenti visti in precedenza sono in conflitto semantico Esempio ulteriore:

Le fasi dell’integrazione – Comparazione degli schemi 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 Conflitti di chiave Conflitti di comportamento

Le fasi dell’integrazione – Comparazione degli schemi L’individuazione delle correlazioni richiede un’approfondita conoscenza della semantica degli elementi coinvolti

Le fasi dell’integrazione – Allineamento degli schemi 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 all’associazione 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 dell’integrazione – Fusione e ristrutturazione degli schemi 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 dell’integrazione – Fusione e ristrutturazione degli schemi Due schemi equivalenti con un diverso livello di leggibilità

Definizione delle corrispondenze Il risultato dell’analisi prevede lo schema riconciliato e l’insieme 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 l’unfolding La semplicità di formulazione delle interrogazioni viene pagata in termini di estendibilità dello schema riconciliato

Definizione delle corrispondenze Due mapping di tipo GAV nell’ambito di un sistema di ordini

Definizione delle corrispondenze 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” L’approccio LAV favorisce l’estensibilità dello schema riconciliato

Sistemi Informativi A. A

Presentazioni simili

Presentazione sul tema: "Sistemi Informativi A. A"— Transcript della presentazione:

Presentazioni simili

Sul progetto

Feed-back

Entrare

Autorizzarsi attraverso i social network:

Sistemi Informativi A. A

Presentazioni simili

Presentazione sul tema: "Sistemi Informativi A. A"— Transcript della presentazione:

Presentazioni simili

Sul progetto

Feed-back