Come si potrà ben capire, non esiste un'architettura perfetta in assoluto, ma l'architettura perfetta sarà di volta in volta quella che permetterà di risolvere il problema preso in considerazione nella maniera più efficace e semplice possibile.
Tra le architetture che nel corso degli anni si sono avvicendate nel panorama dei database, tre sono le prevalenti: Single Tier, Two Tier, Three Tier. L'intera struttura è composta fondamentalmente dai dati presenti nel DB e dall'applicazione che a questi dati dovrà accedre. E' possibile pertanto dividere i servizi erogati in strati o livelli (detti lyer o tier):
- Presentation Tier: include tutti gli aspetti che riguardano l'interfaccia utente e come i dati dovranno essere presentati a livello di formattazione.
- Business Tier: strato conosciuto anche come l'insieme delle regole di business. Un esempio di regola potrebbe essere ad esempio il fatto 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.
- Data Tier: inerente a come i dati vengono fisicamente memorizzati e recuperati. In questa fase un problema importante sarà l'integrità dei dati.
2. Le Tipologie Architetturali sono principalmente:
- Il Single Tier: è il modello clessico dei sistemi mainframe degli anni '70-'80 (computer a quel tempo chiamati 'host'). Non viene effettuato nessun controllo nel terminale (non si può infatti parlare di 'client') e tutte le elaborazioni sono realizzate dalla macchina host a qualunque livello. Il terminale riceve solo le schermate contenente i dati da visualizzare e la possiblità di inserirne di nuovi. Si tratta di un'architettura che sta attualmente riprendendo vigore, anche se in una rielaborazione più ricca di contenuti. Il modello presenta, infatti, indubbi vantaggi: il traffico di rete è limitato, il sistema è altamente affidabile e l'aggiornamento del software è estremamente facile. Di contro, i costi sono molto elevati.
- Il Two Tier: anche detto client-server, è il modello che nacque quando il prezzo dei computer iniziò a scendere, consentendo di distribuire il più possibile tra i vari client il carico del lavoro svolto prima solo dal server. Infatti, l'accesso ai dati viene svolto esclusivamente dal server, mentre gli strati di presentazione e business vengono eseguiti localmente dai client, aumentando però il traffico di rete.
Con questo sistema a fronte di un carico di lavoro distribuito e una capacità di potenziare la velocità relativamente poco costosi si riscontrano alti costi di gestione.
- Il Three Tier: è il modello oggi più diffuso. L'idea di fondo è dividere tutti e tre gli strati dell'aplicazione in modelli logici separati. I client sono responsabili solo delle problematiche connesse con l'interfaccia utente e due server separati si occupano ripettivamente del livello di business e di quello dati.
Il sistema garantisce elevato livello di scalabilità e stabilità ed è facile da estendere e manutenere, ma le prestazioni possono degradarsi a causa del passaggio di informazioni tra i vari livelli separati, inoltre bisogna porre particolare attenzione alle problematiche inerenti la sicurezza.
3. Tipologia degli accessi ai DB
Solitamente ogni applicazione che opera all'interno di un DB aziendale necessita di memorizzare quotidianamente informazioni vitali per la crescita del business, provocando un aumento del DB con conseguente impatto negativo sulle prestazioni delle applicazioni stesse. Inoltre, all'interno di un'azienda spesso utenti differenti necessitano di dati differenti. E' possibile dividere queste tipologie di utenti in 2 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 DB per generare stampe di riepilogo o calcolare statistiche utili al fine di delineare le strategie aziendali.
- OLTP (On-Line Transaction Processing). Come si evince dalla sigla, questi sistemi consentono l'esecuzione di transazioni, ovvero la possibilità di eseguire inserimenti, cancellazioni e aggiornamente all'internodelle tabelle del DB. Si tratta dunque di sistemi progettati per consentire a molti utenti di accedere in maniera concorrente agli stessi dati per eseguire le elaborazioni di cui hanno bisogno.
Le varie applicazioni accedono al DB per consultare piccole porzioni di dati effettuando le volute transazioni (aggiunte, modifiche o cancellazioni di dati) direttamente tramite il server o collegandosi in rete. Tipici sistemi OLTP sono quelli della banche o dei sistemi di prenotazione voli online (che sarà capitato a tutti di effettuare).
Gli obiettivi di un sistema OLTP sono fondamentalmente:
- processare i dati coinvolti nelle transazioni;
- assicurare l'integrità dei dati;
- avere un alto grado di efficienza;
- eliminare i dati ridondanti.
- OLAP (On-Line Analytical Processing). Gli 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 agevolare chi poi, all'interno dell'azienda, dovrà prendere le decisioni strategiche per lo sviluppo della stessa.
Tali sistemi non sottostanno alle regole classiche della teoria relazionale ma focalizzano l'attenzione quasi esclusivamente sulla veocità di recupero dei dati mediante interrogazioni (query) svolte in linguaggio SQL. Questi DB sono anche chiamati database dimensionali e sono composti da rappresentazioni multidimensionali dei dati, realizzate effettuando fotografie di informazioni (ad es. quelle di un DB relazionale), che ne facilitano l'analisi e migliorano le prestazioni delle interrogazioni. Le dimensioni di questi cubi di dati rappresentano le varie categorie dei dati presenti nell'azineda, come linee di prodotto, distribuzioni geografiche e temporali. A tal proposito un Data Mart è un raccoglitore di dati specializzato su un particolare soggetto, ovvero contenente un'immagine dei dati che permetta di formulare strategie sulla base degli andamenti passati. Normalmente si colloca a valle di un Data Warehouse (archivio informatico contenete i dati di un'organizzazione, realizzato proprio al fine di produrre facilmente relazioni ed analisi) più globale del quale ne è, appunto, un estratto.
4. ESEMPIO: Quale sistema scegliere?
Formuliamo l'ipotesi dover realizzare il sistema informativo per una banca...
1) Una banca durante il normale orario di apertura svolge le tradizionali operazioni di deposito, prelievo e trasferimento fondi; durante l'orario di chiusura, invece, i clienti della banca possono accedere al proprio conto tramite Bancomat, Web o ancora attraverso acquisti mediante carta di credito. Per rispondere a queste esigenze utilizzeremo certamente il sistema OLTP proprio al fine di consentire un accesso multiplo alla stessa base di dati a qualsiasi ora del giorno e della notte.
2) All'interno della stessa, però, banca non ci sono solo clienti e operatori di sportello ma anche altre figure, come per esempio il promotore finanziario, che si occupano degli sviluppi futuri. Qusti ultimi hanno bisogno, invece, di guardare i dati sotto un altro punto di vista, elaborando grandi quantità di dati anche in periodi lontani nel tempo. Se questi utilizzassero lo stesso sistema degli utenti precedenti si potrebbe verificare un degrado delle prestazioni. Se, infatti, si volesse sapere quali sono le operazioni svolte da un dato utente negli ultimi 12 mesi, si dovrebbe interrogare il DB e con molta probabilità le informazioni necessarie si troverebbero sparse in decine di tabelle per tutto il DB. L'interrogazione dovrebbe navigare in tutte queste tabelle scorrendone tutte le righe ed eseguendo magari calcoli per generare totali e subtotali. Tutto questo appesantirebbe ovviamente il sistema OLTP in maniera notevole, ralentando anche quegli utenti che stanno agendo suelle stesse tabelle e che nulla hanno a che fare con il cliente che l'operatore finanziario sta analizzando.
Per questa ragione sarà necessario costruire parallelamente un differente sistema basato su uno schema OLAP.
Se, infatti le prestazioni hanno un ruolo importante, si deve necessariamente separare anche fisicamente i due sistemi ponendo i dati su DB differenti e nei casi più estremi su server differenti.
Nessun commento:
Posta un commento