Database distribuiti e Client/Server

Materie:	Appunti
Categoria:	Informatica
Voto:	2 (2)
Download:	139
Data:	24.05.2005
Numero di pagine:	10
Formato di file:	.doc (Microsoft Word)

ARCHITETTURE CLIENT/SERVER
Il Client/Server, che sta diventando il modello di riferimento per il networking e le applicazioni di database a qualunque livello, si contrappone come filosofia e come struttura al Mainframe.
Il Mainframe esegue tutte le operazioni sui dati e usa terminali “stupidi” come unità di visualizzazione e inserimento dati. Tutte le operazioni vengono svolte dal mainframe, mentre il terminale si limita ad effettuare fisicamente le operazioni di I/O.
Nel modello Client Server invece, il client può eseguire parte delle precedenti operazioni, quali la visualizzazione e la formattazione dei dati. Con questa “suddivisione” delle operazioni il Client ha un aumento di prestazioni, essendo sottoposto ad un carico di lavoro maggiore. Una soluzione Client Server offre un notevole risparmio economico ed inoltre si ha una maggior flessibilità nei confronti delle esigenze di mercato, soprattutto per quanto riguarda i prodotti software.
L’affermazione di questo modello è legata inoltre ad altri fattori quali:
• La disponibilità sul mercato di reti locali a basso costo
• La diffusione capillare di Internet
Il server non è più uno strumento in cui sono centralizzate le risorse, bensì è uno strumento cui demandare buona parte dell’elaborazione, ma non tutta. Inoltre in un sistema possono essere presenti più server che concorrono all’elaborazione.
Si parla di architettura Client Server tutte le volte che, in un sistema, un’entità offre un servizio, (il server), ed un’altra (il client) vi accede secondo una serie di regole, usufruendone. Un sistema informativo Client/Server rende oggi possibile una rappresentazione molto più diretta dei processi aziendali di quanto non consentissero sistemi basati su architetture esclusivamente centralizzate o distribuite. Dal punto di vista della progettazione e dello sviluppo delle applicazioni questa tendenza si traduce nella realizzazione di ambienti modulari, che separano il lato front end, per i sistemi client, da quello, o quelli, back end per i sistemi server. Sul lato client sono utilizzate interfacce grafiche e intuitive, ambienti di sviluppo orientati agli oggetti e guidati agli eventi; mentre sul lato server vengono utilizzati sistemi tecnologicamente raffinati, quali gestori di basi di dati, sistemi di accounting e gestione utenti. Esistono due modalità di gestire il software e i servizi sulle reti locali: sistemi client/server e sistemi peer to peer. Anche Internet offre un esempio di client/server.
SISTEMI CLIENT/SERVER
Un computer viene adibito a “server” mentre gli altri elaboratori vengono chiamati “client” e su ogni macchina viene installato un pezzo di software di sistema (NOS – network operating system) a seconda del ruolo che riveste. Il server in genere è una macchina potente dal punto di vista elaborativi (CPU) e molto dotata per quanto riguarda la memoria centrale e quella di massa.
La logica del client/server è quella di far risiedere sul server vari software (di sistemi e applicativi) e i dati, lasciando libera la memoria di massa dei client. Quando questi hanno necessità di utilizzare un’applicazione ne fanno richiesta al server che la attiverà. Il software richiesto potrà girare sul server utilizzandone la CPU, e il nodo client da questo punto di vista verrà usato quasi come un terminale. Un’altra modalità è invece quella di trasportare il software applicativo da usare sul client facendolo eseguire in locale, e usando il server solo come deposito software e di dati. L’estremizzazione di quest’idea è quella su cui si basa il network computer.
Spesso al server è collegata una stampante che può essere condivisa dai vari client in modo da centralizzare la funzione di stampa riducendo i costi. Quando il server viene usato esclusivamente per una di queste due funzioni prende il nome rispettivamente di “file server” e “print server”.
SISTEMI PEER – TO - PEER
Nei sistemi peer-to-peer ogni elaboratore della rete può essere contemporaneamente sia server sia client, cioè ogni elaboratore è in grado di vedere sia i dischi sia le altre risorse degli altri elaboratori. Ogni nodo può decidere quali risorse mettere a disposizione degli altri nodi.
ARCHITETTURA CLIENT-SERVER DI WWW
L’architettura di WWW è di tipo client-server: client “browser” e server. Il programma client funziona da interfaccia tra utente e server Web: cioè ne gestisce l’interazione. Il programma Server è preposto alla trasmissione dei dati in rete, cioè riceve le richieste di connessione e distribuisce i documenti dei vari utenti, tramite un client.
IL RUOLO DEI DBMS NELL’ARCHITETTURA CLIENT/SERVER
La gestione dei dati in un’architettura di tipo Client/Server assume un ruolo di grande rilievo e da questo punto di vista i DBMS relazionali basati sul linguaggio SQL rappresentano la risposta di mercato alle necessità dell’utente di disporre di servizi di accesso ai dati in rete. La separazione dei dati dall’applicazione, elemento essenziale dei sistemi per la gestione dei database, diviene nel Client/Server talmente forte da separare completamente i due ambienti e l’indipendenza dal sistema di gestione dati diviene così elevata nel momento in cui si affida ad un linguaggio comune di alto livello come SQL, per mascherare tutti i livelli sottostanti, sia hardware e software.
PROBLEMATICHE LEGATE AL CLIENT/SERVER
La crescente apertura dei sistemi informativi verso accessi remoti e verso modalità di interazione distribuita comporta qualche rischio, proprio per la protezione dei dati. Naturalmente la gestione dell’integrità logica dei dati non è una prerogativa esclusiva dei sistemi Client/Server.
BASI DI DATI DISTRIBUITE
Si tratta di basi di dati con informazioni costituenti una sola struttura logica ma fisicamente memorizzate su diversi elaboratori autonomi che collaborano tra loro tramite scambio di dati e messaggi. Sono nate per permettere la collaborazione tra diverse organizzazioni. Permette di realizzare i sistemi in modo modulare con divisione delle risorse e loro distribuzione geografica, cercando di migliorare le prestazioni degli utenti e garantendo maggiore affidabilità e sicurezza. Con la diffusione delle reti e delle architetture client/server, si sono sviluppate anche le basi di dati client/server, in grado di avere molti dei vantaggi di un’architettura distribuita senza subirne i problemi. Si tratta di avere una distribuzione dei dati ma con un controllo centralizzato. Le informazioni principali vengono memorizzate nel nodo server, mentre i dati sono memorizzati sui nodi client dove servono. In questo modo si ha ugualmente una distribuzione delle informazioni ma con un controllo centralizzato.
SICUREZZA NELLE BASI DI DATI
In basi di dati i parametri che si scontrano sempre sono: velocità e sicurezza. Un DBMS è disegnato per risolvere entrambe queste esigenze con efficienza, anche se spesso possono nascere incompatibilità. La gestione della sicurezza porta a un notevole incremento dalla complessità di un sistema di elaborazione dati riducendone l’efficienza in termini di tempi di risposta. Le problematiche della sicurezza possono essere viste sotto due aspetti principali: privatezza e integrità.
PRIVATEZZA
Il problema della privatezza dei dati contenuti in database è molto importante. È indispensabile garantire il corretto e veloce reperimento delle informazioni solo alle persone autorizzate impedendo l’accesso ad altri non autorizzati. Un intervento colposo riguarda un’azione effettuata erroneamente, ma non con l’intento di nuocere. Un intervento doloso è invece diretto all’appropriazione o alla distruzione di tutte o parte delle informazioni registrate dal sistema.

Questo problema ha due aspetti:
• Occorre stabilire un regolamento di privatezza in cui il data base administrator determina quali utenti (soggetti) siano autorizzati ad accedere a quali dati (oggetti) e con quali operazioni (regole). Il data base administrator utilizza un sottoinsieme del linguaggio di definizione dei dati (DDL) per descrivere le leggi che devono proteggere le banche dati.
• Occorre controllare che questo regolamento venga rispettato, a ogni richiesta il DBMS verifica gli attributi del richiedente con le condizioni contenute nel regolamento.
INTEGRTITA’
L’insieme dei dati che formano un data base non sono statici, bensì dinamici ma le variazioni che subiscono nel tempo non devono compromettere la validità delle informazioni e la coerenza dei dati. L’integrità è minacciata ogni qualvolta si verificano interventi di modifica dei dati, in particolare se l’accesso ai dati è coerente.
L’integrità di un database presenta due aspetti: l’integrità logica e quella fisica.
• L’integrità logica consiste nella necessità di preservare la struttura logica della banca dati ovvero le relazioni esistenti fra i dati.
• L’integrità fisica invece consiste nel proteggere la banca dati da tutti i possibili danneggiamenti accidentali in modo da essere in grado in qualunque momento di effettuare una completa ricostruzione del database anche in caso di una totale distruzione.
INTEGRITA’ IN CASO DI MALFUNZIONAMENTI
Una delle tecniche spesso utilizzate per risolvere questo problema consiste nel suddividere le sessioni di lavoro in transazioni.
Il concetto di transazione è particolarmente importante. Una transazione è un’unità di lavoro, inizia (begin) con la base di dati che si trova in uno stato consistente e quando termina (commit) deve lasciarla in uno stato consistente. Una transazione può essere vista come un’azione indivisibile, anche se nella realtà è una sequenza di operazioni che interagiscono con il database.
Utilizzando questa tecnica, se tutte le operazioni che compongono la transazione terminano con successo (commit) le modifiche apportate al database vengono registrate in modo permanente, mentre se una delle operazioni fallisce (abort), lo stato del database ritorna ad essere all’inizio della transizione. Operando in questo modo vengono evitate le situazioni di inconsistenza, purtroppo non è certo che una transizione venga eseguita fino al suo corretto completamento: può verificarsi una chiusura anomala della transazione o l’intero sistema può andare in crash (cattivo funzionamento hardware o software che fa andare in errore l’intero sistema).
Per poter attivare delle procedure di ripristino è necessario avere delle copie di salvataggio dei dati; senza di esse è impossibile effettuare un recupero e la banca dati è irrimediabilmente perduta. Tali procedure vengono comunemente indicate con il nome di DISASTER RECOVERY.
Per comprendere la tecnica di gestione di tali situazioni anomale, è necessario suddividere le transazioni stesse in:
• Transazioni attive, ovvero in fase di esecuzione, che non hanno ancora raggiunto il punto in cui verranno completate;
• Transazioni completate, per le quali sono state eseguite tutte le operazioni elementari che potevano essere fonte di un abort.
Il punto di inizio e di fine di una transazione è detto punto di sincronizzazione e può essere immaginato come una cerniera tra una transazione e l’altra. In casi del genere, i DBMS utilizzano un protocollo rigorosamente a due fasi:
• Una transazione non può scrivere sul database fino a quando non abbia raggiunto lo stato di completo (commit point);
• Una transazione non può rilasciare alcun lock fino a quando non abbia terminato di scrivere nel database, quindi fino al raggiungimento dei commit point.
Il mezzo più comune per proteggersi dalla perdita di dati per cadute di sistema è il log. Il log è la storia di tutte le variazioni fatte al database e lo stato di tutte le transazioni. Il log può essere immaginato come un giornale che tiene memoria delle operazioni effettuate, registrando:
* L’avvio di ciascuna transizione;
* I valori vecchi e nuovi di ogni record che abbia subito variazioni e le transazioni che ve le ha apportate;
* Una segnalazione di commit o di abort a seconda del modo in cui ogni trasmissione si è conclusa.
Il backup è un procedimento che consente la creazione di copie d’archivio dell’intero database effettuate su nastri magnetici. Il backup viene effettuato a scadenze periodiche che variano a seconda del grado d’utilizzo del sistema e dell’importanza delle modifiche effettuate. Il backup, tuttavia, non è una procedura che consente di salvare tutti i dati, ma solo la versione aggiornata ad una data più o meno recente. Le imprese che necessitano di conservare tutti i dati elaborati hanno invece una doppia archiviazione.
In conclusione, operando sul database in maniera transazionale, le operazioni che consentono al DBMS di conseguire l’integrità fisica in caso di malfunzionamento sono:
* L’esecuzione periodica di una copia di salvataggio, o di backup, del database;
* La registrazione delle modifiche effettuate durante una transazione non solo sul database, ma anche su archivi temporanei che contengono la copia dei dati prima e dopo ciascuna operazione di modifica; esistono dei Journal che sono programmi batch che hanno modificato la base di dati.
* In caso di abort di una transazione, l’effettuazione di un processo di ripristino (roll back);
* L’effettuazione di un processo di aggiornamento o roll forward nel caso in cui un malfunzionamento abbia causato perdita dei dati.
ACCESSI CONCORRENTI
Vi sono situazioni nelle quali il susseguirsi di operazioni sul database da luogo a diverse forme di concorrenza.
LAST UPDATE: se due utenti possono accedere concorrentemente alla stessa tupla per modificarla, la prima modifica è persa; si supponga, infatti, che le due transazioni siano T1 e T2 e la tupla in oggetto sia X abbiamo
T1 legge X
T2 legge X
T1 aggiorna X
T2 aggiorna X
L’aggiornamento da parte di T2 è effettuato sulla base di X prima che questa tupla sia aggiornata da T1, per cui il primo aggiornamento va perso.
LETTURA SPORCA: si verifica quando una delle transazioni ha una fine anomale, per cui è necessario ripristinare il database nello stato in cui si trovava prima dell’esecuzione abortita: se un’altra transazione ha operato sui dati modificati, questi non sono validi. Infatti, se
T1 legge X
T1 modifica X
T2 legge X
T1 abortisce → ripristino di X
T2 modifica X
La modifica di T2 è apportata su un valore di X che non esiste più, in quanto T1 si considera come non eseguita.
Per gestire adeguatamente la concorrenza di accesso, è necessario procedere ad una serializzazione delle operazioni. La serializzazione delle operazioni consiste nella gestione delle medesime in modo tale da ricondurre un ambiente di multiutenza ad un ambiente di apparente monoutenza.
Il DBMS, dovendo controllare l’accesso concorrente alla base di dati, all’interno di una transazione il DBMS porrà dei lock (lucchetto) sui dati da modificare, e li rilascerà a fine transazione.
Il lock è un blocco temporaneo di un elemento dei database attraverso il quale il sistema ne impedisce l’accesso alle transazioni che ne facciano richiesta, qualora quest’elemento sia già in uso da parte di un’altra transazione. Un lock è un meccanismo che permette a una sola transazione per volta di modificare i dati.
Attraverso il lock il DBMS realizza un privilegio di accesso ad un singolo elemento, che può essere concesso o revocato a livello di transazione, del quale si tiene traccia su una lock table, che registrerà i lock concessi e gli unlock.
Vi sono due tipi di lock:
➢ Exclusíve lock o lock di scrittura: quando ad una transazione che ne faccia richiesta viene accordato un exclusive lock, nessun’altra transazione può ottenere l’accesso allo stesso elemento.
➢ Shared lock o lock di lettura: viene concesso alla sola transazione che ne faccia richiesta di scrivere sull’elemento, le altre transazioni possono solo leggere il suo contenuto.
Si ha un caso di deadlock quando una transazione T1 è in attesa di poter mettere in lock un elemento detenuto dalla transazione T2, che a sua volta ha richiesto un lock sull’elemento bloccato dalla T1.
Per ovviare al problema dei deadlock, è possibile attuare diverse strategie atte a gestire le transazioni in modo corretto.
La strategia più semplice prevede che ogni transazione richieda tutti i lock in una volta lasciando al lock manager di verificare quali lock rilasciare.
Un’altra tecnica (abort e restart) prevede che se una transazione richiede un lock su un elemento già bloccato una delle due transazioni verrà chiusa forzatamente (abort) e ripristinata in un secondo momento (restart).
Infine vi è la tecnica dello scheduling che consiste nell’assegnare alle transazioni un ordine tale che il risultato ottenuto corrisponda a quello che si avrebbe se non vi fossero altri accessi concorrenti.

1