Architettura dei sistemi di database

2 Architettura dei sistemi di database 1 Introduzione Come si potrà ben capire, l architettura perfetta non esiste, così come non è sensato credere che esista una sola architettura in grado di risolvere qualsiasi tipo di problematica. L architettura perfetta è perciò quella che ci consentirà di risolvere il nostro problema nella maniera più efficiente e semplice possibile. Non sono molte le architetture che nel corso degli anni si sono avvicendate nel panorama dei database ma, soprattutto ultimamente, l orientamento generale si rivolge prevalentemente a tre di esse (single tier, two tier e three tier). L intera struttura è composta fondamentalmente dai dati presenti nel database e dall applicazione che a questi dati dovrà accedere, e possiamo essenzialmente dividere i servizi che vengono erogati o consumati in strati o livelli (anche detti layer oppure tier). 2 I livelli dei sistemi con database connessi 2.1 Livello presentazione (presentation tier) In questo strato sono inclusi tutti gli aspetti che riguardano l interfaccia utente e come i dati dovranno essere presentati a livello di formattazione e cose simili. Consideriamo, per esempio, come una somma di denaro o una data vengono rappresentate nelle diverse nazioni, le varie lettere accentate supportate dalle diverse lingue e così via. Si deve pensare anche al fatto che l utente non possa commettere errori nell immissione dei dati lasciando per esempio valori vuoti o inserendo stringhe di caratteri dove andrebbero numeri oppure valori numerici dove andrebbero date. 2.2 Livello business (business tier) Questo strato è anche conosciuto come l insieme delle regole di business. Un esempio di regola di business può essere che, durante una transazione bancaria, magari un prelievo, il sistema si colleghi al server dei certificati digitali per convalidare l identità di colui che sta effettuando la transazione. 2.3 Livello dati (data tier) In questo strato si parla esclusivamente di come, fisicamente, i dati vengono memorizzati e recuperati. In questa fase ci si deve preoccupare dell integrità dei dati (come non consentire prelievi 9

Parte I Progettazione di database da conti correnti in rosso), ma non ci dovremo interessare, per esempio, di come fare a essere sicuri dell identità digitale di colui che sta effettuando la transazione. Andiamo ad analizzare in dettaglio quali sono le architetture attualmente utilizzate per la gestione di questi livelli. 3 Tipologie architetturali 3.1 Single tier Il modello d architettura single tier (figura 2.1) è quello classico dei sistemi mainframe o minicomputer degli anni 70-80 (computer chiamati a quei tempi host ). In quel periodo non esistevano personal computer collegati al sistema host, ma solo terminali cosiddetti dumb ( stupidi ). In questa architettura non viene effettuato nessun controllo nel terminale (non si può parlare di client ) e tutte le elaborazioni, a qualunque livello esse si trovino, sono realizzate dalla macchina host. Il terminale riceve solamente le schermate contenenti i dati da visualizzare e ha la possibilità di inserirne di nuovi. Attualmente questa tipologia sta riprendendo vigore (anche se in forma leggermente diversa e molto più ricca di contenuti), in quanto molte soluzioni server consentono accessi remoti, (come una volta) ma con la ricchezza grafica e di presentazione tipica dei sistemi attuali a finestre. Figura 2.1 Esempio di sistema single tier 10

Architettura dei sistemi di database Capitolo 2 Tabella 2.1 Caratteristiche dei sistemi single tier Vantaggi Il traffico di rete è molto ridotto in quanto vengono inviati solamente i comandi atti a far visualizzare sullo schermo del terminale le informazioni in arrivo. Altamente affidabile. Specialmente se si parla dei vecchi mainframe, il fatto d avere hardware dedicato faceva sì che funzionassero ininterrottamente per anni. L aggiornamento del software è estremamente facile. Risiedendo tutto nell host, basta aggiornarlo, e automaticamente l intero sistema sarà aggiornato non essendo necessario andare in ogni singola macchina. Svantaggi Costo del sistema host molto elevato. Dato che tutte le elaborazioni vengono svolte in un unico computer, questo deve essere adeguatamente carrozzato per fornire prestazioni adeguate. Proprio il possedere hardware dedicato limita la compatibilità del sistema e fa alzare i costi dell host. Il costo delle applicazioni tende a essere alto soprattutto se sono realizzate appositamente per specifici sistemi di elaborazione. 3.2 Two tier I sistemi two tier, anche detti client-server, nacquero intorno agli anni 90 e si sono evoluti fino ad assumere la forma attuale, dividendosi in due categorie distinte, a seconda se il fulcro del sistema sia il client (smart client) oppure il server (smart server). Smart client La versione smart client del modello client-server (figura 2.2) nacque quando il prezzo dei personal computer iniziò a scendere (cosa che tra l altro fu la principale ragione della diffusione del modello client-server), consentendo così di distribuire il più possibile il carico di lavoro, svolto fino ad allora esclusivamente dal server, tra i vari computer client. Solamente l accesso ai dati viene svolto dal server, mentre gli strati presentazione e business vengono eseguiti localmente dai client. Il problema più grande di questa soluzione client-server è il traffico di rete. Considerando che la logica di business viene svolta dal client, questo deve interrogare sempre il server per avere a disposizione i dati su cui prendere decisioni, generando così molti round-trip (sessioni di invio e ricezione dei dati tramite la rete) tra il client e il server. Spesso sono necessarie grosse porzioni di dati per svolgere elaborazioni e questo trasferimento causa la saturazione della capacità di trasferimento della rete, non solo per il client che ha effettuato la richiesta, ma anche per gli altri client che vorrebbero farne una. Figura 2.2 Esempio di sistema smart client 11

Parte I Progettazione di database Tabella 2.2 Caratteristiche dei sistemi smart client Vantaggi Il carico di lavoro è distribuito tra tutti i client (relativamente poco costosi). Se un utente ha bisogno di maggiore velocità, è sufficiente acquistare hardware più potente per quel client senza spendere denaro per potenziare un server del quale si userebbe solo una piccola parte in più. Utilizzare una macchina client veloce per l accesso ai dati vuol dire utilizzarla anche per fare altre cose, come scrittura di testi, elaborazione di fogli di calcolo, navigazione Internet e così via. Svantaggi Il traffico di rete è eccezionale e questa si può saturare molto velocemente. Le installazioni e gli aggiornamenti sono difficili da gestire. Le nuove versioni del software devono essere installate su più macchine contemporaneamente, cosa che non sempre è di facile realizzazione. Spesso l installazione di nuove versioni su vecchi client crea problemi di compatibilità. Ogni client richiede (spesso) l acquisto di una licenza sia per il sistema operativo sia per l accesso ai dati, e questo può far aumentare i costi. Smart server La versione smart server del modello client-server (figura 2.3) assomiglia molto all architettura single tier. Nasce anche questa dal presupposto che i computer costano sempre meno e hanno prestazioni sempre più elevate, ma cerca di trarre vantaggio dallo sfruttare questa potenza nel lato server. Il livello presentazione è la sola cosa gestita esclusivamente dal client al quale vengono inviate solo le informazioni di cui ha bisogno in quel momento, mentre sia la logica di business sia l accesso ai dati vengono eseguiti nel server. Figura 2.3 Esempio di sistema smart server Tabella 2.3 Caratteristiche dei sistemi smart server Vantaggi Certi aggiornamenti vengono fatti solo nel server. Dato che nella rete viaggiano solo le informazioni da visualizzare, il traffico è molto ridotto. Svantaggi Altri aggiornamenti, invece, richiedono comunque di intervenire sui singoli client rendendo problematica e noiosa questa procedura. Elaborazioni particolarmente pesanti effettuate da un utente influenzano le prestazioni di tutti gli altri. Solitamente raddoppiare la potenza del server costa molto più del doppio e costruire sistemi molto performanti può essere molto costoso. 12

Architettura dei sistemi di database Capitolo 2 3.3 Three tier Il modello d architettura three tier (figura 2.4) è quello che oggigiorno sta andando per la maggiore. L idea alla base è di dividere tutti e tre gli strati dell applicazione in modelli logici completamente separati. I client sono responsabili solo delle problematiche relative all interfaccia utente (come nel modello smart server). Anche la logica di business e quella dei dati sono separate l una dall altra, con l aggiunta che questa separazione può essere anche fisica, in quanto non si è obbligati a utilizzare un unico server per entrambe, ma queste possono essere in esecuzione su server differenti. Questo comporta un elevato livello di scalabilità e stabilità, in quanto si può dividere il carico di lavoro in due o più server. Il sistema è molto più estensibile non essendo più monolitico, e di conseguenza di più facile manutenzione in quanto, essendo composto da piccoli pezzi di codice, si possono gestire ed eventualmente modificare solo le parti interessate dal problema. Figura 2.4 Esempio di sistema three tier Tabella 2.4 Caratteristiche dei sistemi three tier Vantaggi Certi aggiornamenti vengono fatti solo nel server. Dato che nella rete viaggiano solo le informazioni da visualizzare, il traffico è molto ridotto. È però possibile avere, separati su più server, la logica di business divisa dai dati, e quindi il traffico tra questi due sistemi può essere molto elevato. Si può programmare per componenti, il che facilita il riutilizzo del codice. Due server di media potenza costano meno di un server di grande potenza. Svantaggi Altri aggiornamenti, invece, richiedono comunque l intervento sui singoli client. Le prestazioni possono degradarsi a causa del passaggio delle informazioni tra i livelli business e dati dei vari server, specialmente se la comunicazione deve avvenire tramite un accesso a Internet. Usare componenti può introdurre problematiche riguardanti la sicurezza che bisogna tenere in considerazione. La probabilità che si guasti uno fra due server è superiore alla probabilità che si guasti un solo server. 13

Parte I Progettazione di database 4 Tipologia degli accessi ai database Ogni applicazione che opera in un database all interno, per esempio, di un azienda, ha bisogno di memorizzare con frequenza giornaliera informazioni vitali per la crescita del business aziendale. Questo fatto provoca un aumento delle dimensioni del database che solitamente ha un impatto negativo sulle prestazioni delle applicazioni stesse nell interrogazione dei dati, causando a volte anche un crash del sistema. A questo si deve aggiungere che, all interno di un azienda, spesso utenti differenti hanno bisogno di dati differenti. Possiamo dividere queste tipologie di utenti in due categorie. Coloro che accedono giornalmente ai dati aggiungendo, cancellando, modificando o recuperando singoli record o gruppi di record già esistenti. Utenti che lavorano con grosse quantità di dati prelevati dal database per generare stampe di riepilogo oppure per calcolare statistiche utili al fine di delineare le strategie aziendali. Queste due diverse tipologie di utenti utilizzano differenti modalità di accesso ai dati, chiamate OLTP (On-Line Transaction Processing) e OLAP (On-Line Analytical Processing). 4.1 OLTP (OnLine Transaction Processing) I sistemi OLTP sono progettati per consentire a molti utenti di accedere in maniera concorrente agli stessi dati per eseguire le elaborazioni di cui hanno bisogno. Come si evince dalla sigla, questi sistemi consentono l esecuzione di transazioni, la possibilità cioè di eseguire inserimenti, cancellazioni e aggiornamenti all interno delle tabelle del database. Le varie applicazioni accedono al database per consultare piccole porzioni dei dati aggiungendole, modificandole o cancellandole, eseguendo queste transazioni direttamente, tramite il server, oppure collegandosi in rete. Tipici sistemi OLTP sono quelli delle banche, dei sistemi di prenotazione aeronavali, delle vendite online e cose simili. Gli obiettivi di un sistema OLTP sono fondamentalmente questi: Processare dati coinvolti nelle transazioni Assicurare l integrità dei dati Avere un alto grado di efficienza Eliminare i dati ridondanti. 4.2 OLAP (OnLine Analytical Processing) I sistemi OLAP rientrano nella categoria dei sistemi di supporto alle decisioni aziendali. Lo scopo di questi sistemi è analizzare grosse quantità di dati generando riepiloghi e aggregazioni tra gli stessi in svariate maniere per aiutare chi poi, all interno dell azienda, dovrà prendere le decisioni strategiche per lo sviluppo della stessa. I sistemi OLAP non sottostanno alle regole classiche della teoria relazionale e focalizzano l attenzione quasi esclusivamente sulla velocità di recupero dei dati mediante le interrogazioni svolte in linguaggio SQL. Questi database sono anche chiamati database dimensionali e sono composti da rappresentazioni multidimensionali dei dati che ne facilitano l analisi e migliorano le 14

Architettura dei sistemi di database Capitolo 2 prestazioni delle interrogazioni. Le dimensioni di questi cosiddetti cubi di dati rappresentano le varie categorie dei dati presenti nell azienda, come linee di prodotto, distribuzioni geografiche e temporali. 4.3 Scelta del sistema Per decidere quale dei due sistemi (OLTP o OLAP) scegliere, formuliamo l ipotesi di dover realizzare il sistema informativo di una banca. Utilizzo del sistema OLTP La banca, durante il normale orario di apertura, svolge le tradizionali operazioni di deposito e prelievo di fondi, trasferimento degli stessi tra conti differenti e altro. Durante l orario di chiusura gli utenti della banca possono accedere al proprio conto corrente sia dai tradizionali Bancomat, sia da casa mediante un accesso via Web che consente loro di effettuare, per esempio, bonifici o trading online o ancora pagamenti di acquisti mediante carta di credito o di debito. Questo è il classico scenario per l utilizzo di un sistema OLTP: consentire un accesso multiplo alla stessa base di dati a qualsiasi ora del giorno o della notte rende indispensabile la caratteristica che il sistema abbia elevate prestazioni. Utilizzo del sistema OLAP All interno della banca, non ci sono solo i clienti, ma anche figure come il promotore finanziario o altre professionalità che si occupano degli sviluppi futuri. Queste persone hanno bisogno, invece, di guardare i dati sotto un altro punto di vista, elaborandone grandi quantità anche in periodi lontani nel tempo. Se questi utilizzassero lo stesso sistema degli utenti precedenti, si potrebbe avere un degrado delle prestazioni. Questo accade, di solito, quando vengono eseguite interrogazioni su grosse quantità di dati. Se per esempio si volesse sapere quali sono le operazioni svolte da un determinato cliente nell arco degli ultimi dodici mesi, si dovrebbe interrogare il database per reperire le informazioni necessarie e, con molta probabilità, queste potrebbero essere sparse in decine di tabelle per tutto il database. L interrogazione dovrebbe navigare in tutte queste tabelle scorrendo tutte le righe di ogni tabella ed eseguire, magari, anche calcoli per generare totali e subtotali. Tutto questo appesantirebbe l intero sistema OLTP, rallentando anche quegli utenti che stanno agendo sulle stesse tabelle ma che nulla hanno a che fare con il cliente che il promotore sta analizzando. Per risolvere questo problema, è necessario isolare le informazioni che servono al promotore da quelle che servono al cliente, e questo si può realizzare mediante la costruzione di un differente sistema basato su uno schema OLAP. Spesso si dovrà realizzare un sistema OLTP per l esecuzione delle transazioni e un sistema OLAP per l analisi dei dati come supporto alle decisioni. Se le prestazioni hanno un ruolo importante, si deve necessariamente separare anche fisicamente i due sistemi, ponendo i dati su due database differenti e, nei casi più estremi, anche su server differenti. 15