Appendice B - Evoluzione dei modelli di elaborazione

Oggi si parla di database su architettura client/server e su Web, ma prima di arrivare a queste soluzioni quali erano i modelli di sistema informativo utilizzati?

L’evoluzione storica di tali sistemi ha visto infatti per molti anni concentrare la maggior parte delle risorse di calcolo intorno a diverse architetture di base. La prima, sia dal punto di vista temporale che da quello della rilevanza assunta, è l’architettura basata sui sistemi di calcolo centralizzati (architettura HOST).

Presentandosi per primo sugli scenari dell’elaborazione dei dati, l’HOST computer (mainframe o mini) ha per lunghi anni rappresentato l’unica soluzione possibile alle richieste di elaborazione automatica di dati. L’architettura HOST è basata sul concetto di mettere a disposizione un unico sistema di elaborazione ad un numero più o meno elevato di utenti i quali possono usare ogni applicazione presente sul computer centrale richiedendola da un terminale dumb (stupido), privo di capacità di calcolo ma in grado di inviare informazioni al computer e di visualizzare quelle ricevute.

Nella figura B.1 sono illustrati due modelli host-based. Si noti che l’applicazione sul mainframe e’ responsabile sia dell’interazione con l’utente che della gestione dei dati in ambiente multi-utente.

Ben presto è risultato evidente che questa strategia di sviluppo di un’applicazione era inefficiente, in quanto per ogni applicazione occorreva reinventare la stessa componente di gestione dei dati. Ci fu dunque un’evoluzione che portò a dividere l’applicazione in due parti: un front end, responsabile dell’interazione con l’utente, ed un back end, responsabile della gestione dei dati. Il back end è un DBMS che può essere usato con ogni nuovo front end, con una crescita della flessibilità del sistema, in quanto più front end diversi possono accedere allo stesso DBMS.

Come ogni cosa il modello host-based aveva vantaggi e svantaggi. Da una parte, poiché il sistema è centralizzato, l’amministrazione è fatta da persone affidabili che garantiscono la disponibilità dei dati agli utenti ed i backup di sicurezza; inoltre periferiche costose come unità a dischi, stampanti e modem, sono condivise tra diversi utenti.

D’altra parte, al crescere del numero di utenti del sistema, deve aumentare la potenza di calcolo del computer centralizzato; i sistemi operativi proprietary, le applicazioni, la memoria e i dischi costano, e più ce ne vogliono più si paga.

Il modello precedente cambiò definitivamente negli anni ’80, con l’introduzione dei personal e delle workstation. Il PC IBM con il DOS, il Macintosh di Apple e, più tardi, le workstation UNIX di HP e Sun cambiarono l’informatica aziendale distribuendola in più centri di elaborazione indipendenti e mettendo fine al controllo centralizzato del mainframe su tutti i dati dell’azienda.

I vantaggi introdotti da questo modello sono:

· le workstation ed i personal sono molto economici e facili da usare;

· possono essere personalizzati sulle esigenze dell’utente con un particolare sistema operativo e con le applicazioni più adatte;

· gli applicativi per PC (word processor, spreadsheet, DBMS e pacchetti di grafica) sono tanti e poco costosi; se non soddisfano i requisiti necessari possono essere personalizzati con semplici strumenti di sviluppo;

· i dati di una workstation sono personali e l’utente è responsabile della loro gestione e della loro protezione; non è più necessario un esperto e ben retribuito system manager.

D’altra parte, le informazioni aziendali, che una volta erano centralizzate, sono ora sparse in tutta l’azienda; i dati su un PC non sono immediatamente disponibili a chiunque, e questo può compromettere il guadagno nel rapporto costi/prestazioni con una caduta di produttività di gruppi di lavoro; inoltre gli utenti non possono più condividere risorse costose. La figura B.2 illustra questi problemi.

I problemi citati nei paragrafi precedenti hanno condotto al modello rete/file server.

Oggi chi usa un personal computer è probabilmente collegato ad una rete LAN (Local Area Network) con cui è possibile coniugare i vantaggi di un PC con la condivisione di dati e periferiche. La figura B.3 illustra questo modello. I dati sono conservati su un file server, cioè un nodo centrale accessibile a tutti gli utenti. In genere il file server è anche il punto centrale di condivisione di periferiche, code di stampa e modem.

Poiché il file server è un computer indipendente della rete, è opportuno che sia attrezzato di una grande quantità di memoria a disco.

Un’applicazione che gira su una workstation legge e scrive sul file server; in molti casi interi file viaggiano sulla rete per servire le operazioni dei vari PC. Ad esempio, l’utente può avere un DBMS sul suo PC e, dopo averlo lanciato, può chiedere le informazioni che si trovano in un file sul file server, il quale invia tutto o in parte il file che le contiene e poi si disinteressa dell’applicazione che gira sul PC dell’utente. Alla fine l’utente salva il file sul file server.

Purtroppo il modello rete/file server è congenitamente incapace di servire adeguatamente applicazioni multi-utente a dati condivisi, come invece avviene su mainframe. Prima di tutto non consente la concorrenza (accesso simultaneo ad un singolo insieme di dati da più utenti) richiesta dalle applicazioni multi-user; questo perché il file server gestisce file, grossi insiemi di dati, e non permette ad un utente di usare un file che sia stato locked (bloccato) da un altro utente.

In altre parole, utenti che operano sullo stesso insieme di dati si scontrano e sono costretti ad attendere in linea. Inoltre, se molte workstation richiedono ed inviano file, la rete si satura rapidamente e la performance del sistema subisce un notevole peggioramento.

I problemi delle LAN hanno inoltre portato all’introduzione del modello client/server, chiamato anche elaborazione distribuita o elaborazione cooperativa, che coniuga i vantaggi della rete con le caratteristiche di accesso condiviso e alte performance tipiche del modello host-based (vedi figura B.4).

Il modello client/server è costituito da tre parti, ognuna con un compito specifico: un server back end che si occupa di gestire in modo efficiente un database tra più utenti che richiedono l’accesso concorrente, una parte client front end usata dall’utente per interagire con i dati, una rete e un software di comunicazione che costituiscono i veicoli che trasmettono i dati tra client e server. Un sistema client/server si basa su una corretta suddivisione di una applicazione in componenti client e componenti server. Il paradigma applicativo che ha costituito un riferimento in questo contesto è illustrato nella figura B.5.

E’ ovvio che suddividere logicamente un’applicazione in componenti funzionali rappresenta sempre un’operazione arbitraria, ma considerare l’applicazione come composta dai quattro moduli sopra evidenziati ha consentito un approccio molto più corretto alle problematiche client/server.

Analizziamo in dettaglio ogni singolo modulo per poter cogliere meglio le implicazioni connesse.

In questo modulo rientrano tutti i componenti applicativi che consentono all’utilizzatore del programma di interagire con esso per ottenere determinati risultati. La più semplice interfaccia pensabile per un modulo software è quella che consiste semplicemente nella possibilità del suo richiamo, tramite un idoneo meccanismo fornito dal sistema operativo, e nell’utilizzo dei risultati della sua esecuzione, come una stampa, una videata, un file archiviato su qualche supporto.

Ci aspettiamo ovviamente che un’applicazione moderna sia realizzata in ambiente grafico, in conformità a determinati standard e sia progettata per facilitare realmente il suo utilizzo da parte dell’utente finale. Una buona interfaccia deve addirittura essere in grado di far cogliere all’utente tutte le potenzialità del sistema che sta utilizzando al di là di quelle che sono le sue immediate necessità.

Le componenti applicative che fanno sì che l’esecuzione di un programma porti a determinati risultati rientrano in questa categoria. Può essere costituita da componenti di calcolo, di stampa, di elaborazione di un testo o di quanto altro realizza la funzione per la quale l’utente ha richiamato in esecuzione un determinato componente software.

L’identificazione di questa componente ha contribuito alla corretta definizione di una applicazione realizzata secondo il paradigma client/server. Si tratta di fatto di tutti quegli elementi che gestiscono in maniera corretta i dati forniti dall’utente al sistema o viceversa reperiti per la loro consultazione dai rapporti di archiviazione.

Fanno parte della logica di accesso ai dati tutte le procedure di controllo sui dati stessi, da una semplice validazione, come può essere quella su un valore minimo o massimo, a procedure di controllo della validità dei riferimenti tra i dati. Possono in certi casi esistere procedure complesse che producono operazioni in cascata a seguito di particolari eventi, come il calcolo di valori derivati dall’inserimento di una specifica tabella o la registrazione di valori di controllo quali l’identità dell’utente, la data e l’ora dell’operazione relativamente all’esecuzione di operazioni ritenute critiche.

In questo gruppo rientrano tutte le componenti che si occupano di archiviare e reperire i dati sui supporti di archiviazione del sistema. Queste operazioni sono normalmente svolte da un DBMS dovendo essere fornite garanzie di integrità fisica dei dati, possibilità di accesso concorrente, ottimizzazione dei tempi di lettura e scrittura e indipendenza nei confronti del sistema hardware utilizzato.

Alla luce di quanto detto risulta che la suddivisione ottimale dei componenti di un sistema client/server può risultare quella illustrata in figura B.6.

L’intersezione tra componenti client e componenti server indica la forte difficoltà esistente in un sistema reale a definire una netta distinzione tra le due classi di componenti. Risulta infatti estremamente complesso suddividere la logica di accesso ai dati dalla logica applicativa per molte delle applicazioni di un sistema reale. Normalmente è necessario che alcuni di questi componenti vengano replicati sia sul lato client che su quello server per poter garantire al tempo stesso integrità nei dati ed interfacce utenti efficaci.

Un caso significativo è quello tipico sui controlli di validità del singolo dato: sebbene debba essere sicuramente implementato un meccanismo che protegga il database dall’accettare valori incongruenti, è altrettanto vero che una buona interfaccia utente dovrà intercettare possibili errori di inserimento dati se non guidare l’utente verso l’inserimento di dati corretti. A questo scopo la logica di controllo dovrà essere parzialmente duplicata su vari componenti dell’applicazione. Ad evitare inconsistenze, i controlli sull’integrità del dato dovranno sempre essere implementati sul lato server; tuttavia una buona logica applicativa dovrà comprendere dei meccanismi per acquisire in maniera automatica e dinamica dal server le informazioni relative ai vincoli di integrità del dato stesso per poterli riprodurre in locale, possibilmente passando tali informazioni ai componenti di interfaccia progettati per guidare l’utente nella fase di immissione dei dati. Sebbene l’ultima parola in fatto di controlli spetti al server, sarebbe di fatto assurdo che nessun controllo fosse fatto a livello dell’applicazione client. Avremmo in questo caso un’elevata quantità di dati rifiutati durante le fasi di inserimento e modifica e di fatto caricheremmo l'utente dell'onere di conoscere tutti i vincoli definiti all’interno dello schema del database.

La suddivisione in componenti client e server illustrata si collega anche alla necessità di un moderno database di poter gestire vincoli di integrità logica sui dati oltre a quelli di integrità fisica.

I DBMS appositamente progettati, o comunque profondamente rivisti nel contesto di architetture client/server, vengono in certi casi definiti estesi proprio per sottolineare la presenza di meccanismi idonei a definire vincoli di integrità dei dati in essi archiviati.

Parte di questi meccanismi sono in realtà implementati anche nei database commerciali per sistemi centralizzati. In particolare la struttura stessa del sistema relazionale aveva portato i progettisti di questi prodotti, già nei primi anni del loro utilizzo, alla ricerca di meccanismi per mantenere integri i vincoli di riferimento tra le varie tabelle del database. Tuttavia non era apparso chiaro, o perlomeno rilevante che i vincoli di integrità referenziale sono solo una parte, seppure significativa, della classe più ampia dei vincoli di integrità logica dei dati. Tale visione era certamente condizionata da un approccio nello sviluppo dei sistemi informativi orientato più ai programmi che non ai dati, tipico del periodo antecedente all’uso dei DBMS. Questo modo di pensare è nato dalla mancata percezione della necessità di indipendenza tra il dato e l’applicazione e ha portato a considerare i vincoli di integrità sui dati come parte della logica applicativa, da implementare quindi come controlli da inserire in un programma. Le caratteristiche di distribuzione e maggiore flessibilità del sistema client/server fanno sì che un dato venga normalmente visto come patrimonio comune di molte applicazioni, rendendo di fatto impossibile un approccio di controllo sulla validità del dato stesso implementata su ogni singolo componente software. Si rendono quindi necessari meccanismi a livello di DBMS per la definizione a livello centralizzato, come parte integrante del dato, dei necessari vincoli di integrità logica.

Facendo riferimento alla definizione classica che definisce un’informazione come un dato integrato dalle conoscenze necessarie per interpretarlo, potremmo dire che i DBMS stessi sono più dei gestori di informazioni che gestori di dati.

Secondo lo schema già visto potremmo affermare che in un DBMS esteso esistono dei meccanismi che implementano l’approccio della figura B.7.

La logica di accesso ai dati, definita come componente chiave di un sistema client/server, coincide infatti con i meccanismi definiti per garantire l’integrità dei dati sui DBMS.

A questo livello, quindi, viene gestita l’integrità referenziale, cioè viene gestito l’insieme di regole utilizzate per assicurare che le relazioni tra i record delle tabelle correlate siano valide e non vengano eliminati o modificati per errore dati correlati; viene inoltre garantita l’integrità di dominio, cioè si controlla che i dati che si vogliono inserire nel database appartengano al loro dominio di definizione (cioè se appartengono ad un insieme specifico di valori, definito al momento della creazione delle tabelle del DB in cui devono essere inseriti). Infine vengono effettuati anche i controlli per garantire l’integrità di comportamento, argomento considerato di particolare interesse per i sistemi informativi moderni, connesso alla visione del dato come correlato a particolari regole di comportamento (ad esempio, nell’inserimento di un ordine è opportuno assicurarsi che la sua data non sia antecedente ad ordini precedentemente emessi).

L’implementazione di questi vincoli può avvenire sia sfruttando la sintassi standard SQL, che ha però il forte limite nella necessità di basarsi su definizioni espresse al momento della creazione delle strutture dati direttamente sulle colonne o nelle tabelle del database, sia con un approccio di tipo procedurale, che consente di realizzare moduli software direttamente all’interno del DBMS per effettuare operazioni di controllo su determinati eventi del sistema. Il meccanismo principale di gestione dell’integrità logica dei dati tramite la tecnica procedurale è quello del trigger, un insieme di istruzioni che vengono eseguite non ad una richiesta specifica dell’utente ma al determinarsi di particolari eventi.

Un sistema client/server può raggiungere prestazioni migliori di un sistema file server, perché sia l’applicazione client che il server di database collaborano a sostenere il carico di elaborazione di un’applicazione (da cui il termine "elaborazione distribuita").

Il server gestisce il database tra diversi client, mentre i client inviano, richiedono e analizzano i dati che ricevono dal server.

L’applicazione client lavora con piccoli insiemi specifici di dati, come ad esempio le righe di una tabella, e non con file, come avviene invece nel sistema file server.

Un server di database è intelligente, blocca e restituisce solo le righe che un client richiede, il che garantisce la concorrenza, minimizza il traffico di rete e migliora la performance.

I vantaggi maggiori derivano dal fatto che il client e il server girano su diversi computer e quindi i computer possono essere scelti con requisiti particolari per soddisfare al meglio le esigenze delle due componenti. Per esempio, è consigliabile usare processori potenti e grandi quantità di memoria, centrale o su disco, per il server, che così può conservare grandi quantità di dati e servire molti utenti. Invece si può usare un computer meno costoso, con poca memoria ed una CPU non tanto potente, ma un mouse ed eccellenti capacità grafiche, per applicazioni client.

Inoltre il sistema può rispondere con flessibilità agli inevitabili cambiamenti del software e dell’hardware. Infine le dimensioni del sistema possono essere modificate in corrispondenza a cambiamenti dei gruppi di lavoro, ad esempio aggiungendo nuove workstation per i nuovi assunti.

Ogni componente può essere specializzata per fare qualcosa nel modo migliore. Per esempio, nello sviluppo di un’applicazione client il programmatore può concentrarsi sulla presentazione e sull’analisi dei dati, mentre il server si occupa della loro gestione; in altre parole il programmatore non deve costruire un nuovo DBMS ogni volta che crea una nuova applicazione.

Nel passato l’unico modo per eseguire un’applicazione su un database multi-utente era quello di usare mainframe o mini costosi e potenti. Questo comportava terminali a carattere, un team di programmatori ben pagati per la messa a punto dell’applicazione ed un team di amministratori, anche loro ben pagati, per la manutenzione. Le spese iniziali e di manutenzione per questo sistema potevano essere astronomiche. In molti casi, un sistema client/server supporta un’applicazione da mainframe con costi molto ridotti, distribuendo la potenza di calcolo su molti computer economici collegati in rete. Anche lo sviluppo dell’applicazione è più semplice, grazie alle interfacce GUI (Graphical User Interface) e ai tool di sviluppo orientati agli oggetti.

Per quanto riguarda gli svantaggi, è da considerare che la riduzione di costi potrebbe non essere significativa nella realtà. Quando si preventivano i costi per un sistema bisogna tenere conto di molti fattori, e non solo delle spese per l’hardware: per esempio la produttività degli utenti, sia quelli che usano gli applicativi, sia quelli che sviluppano software, sia quelli che amministrano il sistema. Chi sviluppa software aumenterà la sua produttività grazie alle interfacce GUI ed ai tool CASE (Computer Aided Software Engineering) disponibili nel modello client/server, mentre gli utenti di applicativi e gli amministratori possono vedere diminuire la loro produttività. Infatti, l’affidabilità di un sistema client/server, fatto da un mix di componenti hardware e software sviluppate e gestite in modo indipendente, è intrinsecamente minore di quella di un mainframe o di un mini centralizzato. E poi, chi chiamare in caso di guasto? Il tempo di down dovuto alla "scarsa affidabilità" si traduce in una diminuzione di produttività degli utenti finali e degli amministratori.

Il segreto per realizzare davvero un risparmio sta nella scelta del tipo corretto di applicazioni che possono girare con successo su un sistema client server.