Database distribuiti: appunti di informatica

Materie:	Appunti
Categoria:	Informatica
Download:	287
Data:	15.06.2005
Numero di pagine:	8
Formato di file:	.doc (Microsoft Word)

DATABASE DISTRIBUITI E CLIENT SERVER

1. ARCHITETTURA CLIENT SERVER

Il Client/Server sta diventando il modello di riferimento del networking e delle applicazioni di database e si contrappone come filosofia e come struttura al Mainframe. Infatti nell’architettura del Mainframe è il Mainframe stesso a eseguire tutte le operazioni sui dati e usa dei terminali senza capacità propria di processazione come unità di visualizzazione e di inserimento dati. Quindi tutte le operazioni vengono eseguite dal Mainframe, mentre il terminale si limita ad effettuare fisicamente le operazioni I/O.
Nel modello Client/Server invece, il client può eseguire alcune delle operazioni che eseguiva il mainframe. Questa suddivisione delle operazioni porta ad un incremento delle prestazioni, essendo sottoposto ad un carico maggiore di lavoro.
La caratteristica del mainframe è quella di offrire garanzie per quanto riguarda la sicurezza dell’informazione e la stabilità del sistema.
Una soluzione Client/Server offre un notevole risparmio economico il quanto il costo dei terminali è simile a quello di un PC e un Server può facilmente essere realizzato su un qualsiasi PC.
L’affermazione di questo modello inoltre è dovuta dall’elevata disponibilità sul mercato di reti locali a basso costo.
Il Server non è più uno strumento in cui sono centralizzate le risorse, bensì è uno strumento a cui demandare buona parte dell’elaborazione ma non tutta. Inoltre in un sistema possono essere presenti più server che concorrono all’elaborazione pur trovandosi in nodi differenti della rete.
Lavorare in rete significa scambiare messaggi e dati da un nodo all’altro. Dal punto di vista dell’utente vuol dire sfruttare le capacità e le risorse (hardware e software) di altri nodi.
Si può quindi parlare di architettura Client/Server ogni qual volta un’entità offre un servizio (server) e un’altra (client) ne usufruisce secondo una serie di regole. Si viene cosi a creare una situazione in cui il carico di elaborazione risulta essere bilanciato tra client e server.
Dal punto di vista della progettazione e dello sviluppo delle applicazioni l’architettura Client/Server è realizzata in ambienti modulari che separano il lato front end, per i sistemi client, da quello back end, per i sistemi server.
Sul lato client sono utilizzate interfacce grafiche e ambienti di sviluppo orientati agli oggetti e esistono elevate possibilità di interazione tra i vari componenti in grado di soddisfare al meglio le esigenze operative dell’utente stesso, mentre sul lato server vengono utilizzati raffinati sistemi come i gestori di database e sistemi per la connessione a reti geografiche per la realizzazione di sistemi veloci ed affidabili nella condivisione di risorse comuni.
Esistono due modalità di gestione del software e dei servizio sulle reti locali: i sistemi Client/Server e i sistemi peer to peer. (anche Internet è un esempio di architettura Client/Server).

Sistemi Client/Server

Nei sistemi Client/Server un computer viene adibito a server mentre gli altri elaboratori vengono chiamati client. Il server è in genere una macchina dotata di CPU molto potente e che vanta sia una grande memoria di massa, che una grande memoria centrale. Su ogni macchina viene installato una parte del software si sistema a seconda del ruolo che riveste (client o server). L’organizzazione fisica dell’hardware non è vincolante, perciò possiamo trovare sistemi Client/Server con topologia a stella, ad anello, a bus.
La logica del Client/Server è quella di fare risiedere sul server vari software e i dati, lasciando libera la memoria di massa dei client. Quando questi hanno necessità di una risorsa ne fanno richiesta al server il quale a attiverà. La risorsa utilizzerà la CPU del server e il nodo client verrà praticamente usato come un terminale. Questo meccanismo è molto utilizzato in casi in cui vari utenti hanno bisogno di utilizzare la stessa risorsa.
Un’altra modalità invece consiste nel far eseguire in locale sul client il software applicativo trasportandolo su di esso. Il server viene perciò usato solo come deposito software e dati. Si tratta in pratica di avere come client dei PC che non possono lavorare indipendentemente dal punto di vista software, poiché tutti i programmi di cui hanno bisogno risiedono nel server. Quando il client comincia a lavorare, ed effettua qualche richiesta, il server provvede a scaricare sul client il software necessario, che viene poi usato in locale dal client.

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 dischi sia le altre risorse degli altri elaboratori. Ogni nodo può inoltre decidere quali risorse mettere a disposizione degli altri nodi decidendo in pratica che alcune stazioni siano usate principalmente come server e/o print server.

1.3 Architettura Client/Server di WWW

L’architettura di WWW è di tipo Client/Server. Il programma client funziona da interfaccia tra utente finale e server Web e lavora collegandosi al server usando il protocollo HTTP per richiedere un documento identificato dal proprio URL e scaricandolo sulla propria macchina per poi leggere da un buffer i dati scaricati dai server interpretando i tag HTML che identificano lo stile di visualizzazione.
Il programma server è preposto alla trasmissione dei dati in rete, cioè riceve le richieste di connessione e distribuisce i documenti richiesti dai vari utenti, tramite un client.

1.4 Il ruolo dei DBMS nell’archittettura Client/Server

Nella gestione dei dati in un’architettura di tipo Client/Server assumono un ruolo di grande rilievo i DBMS relazionali basati sul linguaggio SQL che, grazie all’elevato livello di standardizzazione raggiunto, rappresentano la risposta di mercato alle necessità dell’utente di disporre di servizi di accesso ai dati in rete. In particolare con l’introduzione di questi sistemi, viene eliminata la necessità di riprogrammare la logica di accesso ai dati per ogni applicazione. Più precisamente, la separazione dei dati dall’applicazione diviene talmente forte da separare completamente i due ambienti Client/Server e l’utilizzo di un linguaggio ad alto livello come SQL consente di mascherare tutti i livelli sottostanti, sia hardware che software.

1.5 Problematiche legate al Client/Server

La crescente apertura dei sistemi informativi verso accessi remoti e verso modalità di interazione distribuita comporta dei rischi relativi alla protezione dei dati. Infatti la suddivisione in componenti di tipo client e di tipo server richiede un moderno database che possa gestire, oltre all’integrità fisica, anche l’integrità logica e semantica dei dati.

2. DATABASE DISTRIBUITI

Si tratta di database con informazioni che costituiscono una sola struttura logica ma che sono fisicamente memorizzate su diversi elaboratori autonomi che comunicano tra loro tramite scambio di dati e messaggi. La locazione fisica dei dati risulta essere trasparente all’utente e viene garantita l’esistenza e la correttezza dei dati.
Questi database sono nati per permettere la collaborazione tra diverse organizzazioni. Infatti permettono di realizzare i sistemi in modo modulare con divisione delle risorse e loro distribuzione geografica, cercando di migliorare le prestazioni degli utenti e garantendo affidabilità e sicurezza.
Con la diffusione delle reti e delle architetture Client/Server, sono nati anche i database Client/Server che sono in grado di avere molti vantaggi derivanti dall’architettura Client/Server, evitandone i difetti grazie ad una distribuzione dei dati con controllo centralizzato, dove le informazioni principali vengono salvate nel nodo server, mentre i dati sono memorizzati sui nodi client dove servono. Per poter accedere ai dati il client deve ugualmente fare richiesta al server, il quale verifica l’accettabilità della richiesta e individua il luogo dove i dati risiedono fisicamente. In questo modo si ha ugualmente una distribuzione dei dati ma con un controllo centralizzato migliorando così le prestazioni del sistema.

3. SICUREZZA NEI DATABASE

Le problematiche di sicurezza di un database sono legate alla velocità e sicurezza.
Un DBMS è disegnato per risolvere entrambe le esigenze, anche se spesso possono nascere delle incompatibilità. Infatti un controllo degli accessi può ledere in maniera significativa la necessità di avere tempi di risposta accettabili ed efficienti. Infatti la gestione della sicurezza porta ad un notevole incremento della complessità del sistema di elaborazione dati riducendo notevolmente l’efficienza in termini di tempi di risposta.
Le problematiche della sicurezza possono essere viste sotto due aspetti principali: privatezza e integrità.

3.1 Privatezza

Il problema della privatezza dei dati in un database è molto importante. È infatti presumibile che non tutti gli utenti possano accedere a tutte le informazioni contenute nei database, ma solo a quelle di propria competenza. In ogni caso occorre garantire il corretto e veloce reperimento dei dati solo alle persone autorizzate impedendo l’accesso ad altri non autorizzati garantendo così la sicurezza per prevenire interventi illeciti – colposi o dolosi – che alterino i dati.
Un intervento colposo riguarda un’azione effettuata erroneamente, ma non con l’intento di nuocere, mentre uno doloso è diretto all’appropriazione o alla distruzione delle informazioni.
Questo problema ha due aspetti:
A) Occorre stabilire un regolamento di privatezza, in cui l’amministratore del database, determina quali utenti siano autorizzati ad accedere e con quali operazioni. L’amministratore utilizza i comandi DDL per descrivere le leggi di protezione.
Nella gestione delle autorizzazioni intervengono:
1) il soggetto ovvero l’identificativo dell’utente che richiede la transazione.
2) L’oggetto cioè l’elemento dei database sul quale si intende operare
3) Le regole ovvero le operazioni concesse.
B) Occorre controllare che questo regolamento venga rispettato. Ad ogni richiesta il DBMS deve verificare gli attributi dell’utente confrontandoli con le condizioni di regolamento. Nel caso in cui il DBMS decide di non soddisfare la richiesta dell’utente dato un tentativo di violazione delle regole, questo tentativo viene notificato all’amministratore e contemporaneamente possono essere applicate penali quali l’abort del programma, la disconnessione del terminale e l’eliminazione dell’utente dall’elenco degli autorizzati.

3.2 Integrità
L’insieme dei dati che costituiscono un database sono dinamici e le variazioni che subiscono nel tempo non devono compromettere l’integrità dei dati, un’integrità che risulta essere minacciata ogni qualvolta si verificano interventi di modifica dei dati. Il DBMS deve essere quindi in grado di garantire l’integrità dei dati. L’integrità di un database presenta due aspetti: integrità logica e fisica.
L’integrità logica consiste nella necessità di preservare la struttura logica del database, preservando le relazioni fra i dati.
L’integrità fisica consiste nel proteggere il database da tutti i possibili danni accidentali.

3.3 L’integrità fisica
Il collegamento degli utenti era effettuato da terminali e qualsiasi richiesta di dati o di calcolo effettuata dall’utente veniva presa in carico dal sistema centrale (tecnica transizionale)
Le tecniche transizionali venivano utilizzate per preservare l’integrità fisica dei dati poiché gli eventi che mettono a rischio tale integrità appartengono a due classi:
1) i malfunzionamenti hardware e software del sistema che ospita il database
2) l’accesso concorrente agli stessi dati in aggiornamento.
Una transazione è un’unità di lavoro che inizia (begin) con il database che si trova in uno stato consistente e finisce (commit) lasciando il database nel medesimo stato.
Un database si dice consistente quando tutti i vincoli di validità dei dati sono rispettati.
Una transazione può essere vista come un’azione indivisibile quando in realtà è una sequenza di operazioni che interagiscono col database.

3.3.1. Integrità in caso di malfunzionamento

Una delle tecniche spesso utilizzate per risolvere questo problema nel suddividere le sessioni di lavoro in transazioni. Utilizzando questa tecnica, se tutte le operazioni vengono effettuate correttamente, le modifiche vengono registrate permanentemente, mentre, se un’operazione fallisce (abort) lo stato del database viene ripristinato.
Operando in questo modo non si verificano situazioni di inconsistenza.
Purtroppo non c’è sicurezza di completamento della transazione a causa di problematiche quali chiusure anomale della transazione e crash di sistema.
In caso di danneggiamento fisico del database occorrono delle procedure in grado di riportare i dati ad una situazione consistente. Per poter attivare le procedure si ripristino occorrono copie dei dati. Queste procedure vengono generalmente chiamate col nome di DISASTER RECOVERY.
Per comprendere la tecnica di gestione di tali situazioni anomale è necessario suddividere le transazioni in due categorie:
Quelle attive, ovvero in fase di esecuzione e quelle completate.
I DBMS utilizzano un protocollo rigorosamente a due fasi, ovvero un algoritmo che sincronizza le transazioni in modo che:
una transazione non può scrivere sul database fino a quando non abbia raggiunto lo stato di completo.
Una transazione non può rilasciare alcun lock fino a quando non abbia terminato di scrivere nel database.

In caso di danno permanente alla memoria è lo stesso database ad andare distrutto. Il metodo più semplice per far fronte alla perdita totale dei patrimonio informativo è il backup, ovvero un procedimento che consente la creazione di copie d’archivio dell’intero database