Sistemi di databaserelazionali

-Introduzione...................................................................Evoluzione dei sistemi di database..........................................

Il modello relazionale........................................................Prospettiva storica.........................................................Concetti fondamentali.......................................................Elementi costitutivi........................................................

Progetto di database relazionali..............................................Introduzione................................................................Sviluppo concettuale........................................................Il Modello ER...............................................................Implementazione del modello relazionale.....................................

Architetture Client/Server....................................................Introduzione................................................................Architetture C/S ad 3 strati................................................

Proposta per un modello di sviluppo applicativo...............................Uso di convenzioni di denominazione.........................................Lavorazione in cascata o prototipale ciclica................................

Bibliografia.................................................................. 

IntroduzioneNon è superfluo ricordare che i sistemi di database sono statisviluppati per uno scopo che è essenzialmente quello disemplificare lo sviluppo di applicazioni che fanno uso intensivodi dati di tipo strutturato, cioè dati che hanno per natura unastruttura in qualche modo ripetitiva. Infatti, nel caso miglioreun sistema di database può eliminare intere fasi di sviluppo datoche fornisce una interfaccia semplice ed immediatamentefunzionante per la visualizzazione e la modifica dei dati in essocontenuti. In genere maggiore è la parte di elaborazione che siriesce a demandare al database, minore sarà il codice che ènecessario sviluppare. Esiste anche il rovescio della medaglia:funzionalità non richieste dal progetto iniziale possono ridurrele prestazioni del sistema senza ragione, e possono rendere ilsistema più difficile da capire. Di conseguenza è necessarioconsiderare attentamente quali funzionalità sono necessarie alleapplicazioni di destinazione, e come realizzare al meglio lecaratteristiche del sistema di database da proporre alprogrammatore.

Evoluzione dei sistemi di databaseI sistemi per la gestione delle informazioni sono evoluti neltempo attraverso tre grandi categorie.  data management strutture dati semplici ed operazioni semplici (database

relazionali)

object management strutture dati astratte ed operazioni relative (database adoggetti)

knowledge management sistemi di memorizzazione di informazioni e di regole nonstrutturate (intelligenza artificiale)

 In questo documento si porrà l’ attenzione soltanto sulla primadi esse, ed in particolare su un solo tipo di architettura che èquella relazionale. Come si vedrà in seguito tale architetturaabbina le caratteristiche di facilità d’ uso e potenza. Non è uncaso che tutti gli sviluppi futuri del data management, cioè l’object management partono invariabilmente da qui. Inoltre le nuovetecnologie di database ad oggetti nascono per risolvere specifichecategorie di problemi per i quali l’ architettura tradizionale èinsufficiente. Ciò non toglie perciò che la tradizionalearchitettura relazionale continui ad essere la migliore soluzioneper tutti quei casi di gestione di informazioni semplici, ossia

costituite essenzialmente, anche se non esclusivamente, da testo enumeri.Di seguito si descrivono tre modelli relazionali fondamentali,ciascuno dei dei quali è costituito dalla coppia di dato e schema,ove lo schema è un metadato che descrive la struttura dei dati,mentre il dato è lo scopo stesso del sistema.

Modello relazionale - RDBMSIl modello relazionale è il primo modello per importanza, a causadella sua diffusione. Inizialmente fu proposto da Codd nel 1970 esuccessivamente modificato da Date. Deve il suo successo allasemplicità, essendo costituito da una sola struttura dati, latabella, che contiene tipi di dati semplici (numeri, lettere, ecc.).Il linguaggio di manipolazione del database è costituito da pocheistruzioni, e non c’ è il bisogno che esso sia conosciuto dall’utente del database (QBE).

Modello relazionale esteso - ERDBMSLe limitazioni sul tipo di dato che il modello relazionale è ingrado di trattare hanno reso necessario lo sviluppo di alcuneestensioni, riunite sotto la definizione generica di modelloesteso relazionale. Si tratta essenzialmente del modellorelazionale ove si aggiunge la possibilità di memorizzare anchedati di tipo oggetto. E’ esclusa o molto ridotta la capacità dimanipolare gli oggetti memorizzati, come la capacità di fareconfronti, operazioni, ecc.

Modello ad oggetti - ODMSSono sistemi di database basati su un modello astratto dei dati,originato dal paradigma della programmazione ad oggetti nata conprodotti come Simula, SmallTalk e successivamente C++. Questilinguaggi di programmazione sono basati sul concetto di tipo di datiastratto, che è costituito da una interfaccia che definisce in modoesplicito una porzione pubblica ed una porzione privata all’interno di una struttura dati, detta oggetto. Questo tipo di datiastratto, detto classe, può incapsulare alcune parti della strutturadati privata dell’ oggetto tramite procedure pubbliche dettemetodi, ed espone la parte pubblica tramite delle variabili detteproprietà.

Il modello relazionale

Prospettiva storicaLa tecnologia dei database si è evoluta fin dall’ inizio nellosviluppo di applicazioni di gesitione aziendale, probabilmente acausa del fatto che lo sviluppo di simili applicazioni ha allespalle adeguati investimenti, ed ha la necessità di manipolaregrandi quantità di dati.La prima soluzione è stata quella dei file indicizzati. Questifile consentivano la memorizzazione su disco e la ricerca direcords di vario tipo. Le caratteristiche avanzate dei file adindici hanno nel tempo costituito le caratteristiche di base deisistemi di database relazionali. Esse sono_1. 1.    record di lunghezza fissa con campi di tipo differente all’interno

2. 2.    capacità di memorizzare su disco le informazioni, e dimanipolare quantità di dati più grandi della dimensione fisicadella memoria disponibile

3. 3.    indicizzazione di campi e gruppi di campi per la ricerca eselezione rapida di valori che soddisfano a condizioni fissatesul valore dei campi

4. 4.    blocco di file e record, per la gestione dell’ accessoconcorrente ai dati

Negli anni 70 fu sviluppato il primo sistema di database che usavaun modello gerarchico e distribuito dei dati, che otteneva lecaratteristiche dette prima insieme ad altre nuove:5. 5.    uso di identificatori di record e di campi di collegamentoin grado di realizzare l’ associazione tra dati all’ interno diuna rete di computer

6. 6.    apertura simultanea di più file indicizzati e collegati datrattare come singolo database

7. 7.    vincoli di protezione per consentire o no l’ accesso alleinformazioni

8. 8.    gestione delle transazioni al sicuro dai crash di sistema,controllo degli errori e della consistenza del database

Negli anno 80 fu sviluppato e messo in commercio il primo sistemadi database relazionale, che agguingeva altre caratteristiche:9. 9.    linguaggio di alto livello interno con la possibilità didefinire modificare e manipolare i dati, insieme a tool di altolivello per lo sviluppo di form, report ed altri elementi per iltrattamento delle informazioni

10. 10. indipendenza dai dati, ossia capacità del database dicambiare il modo di memorizzare i dati senza che si debbacambiare la logica delle applicazioni che li manipolano.

Il più grande contributo dato dal modello relazionale è statoquello di rendere più semplice da comprendere le strutture deidati rispetto anche ai sistemi di potenza inferiore. Questasemplicità è dovuta essenzialmente all’ introduzione di pochiconcetti come relazioni, query e transazioni, che hanno liberatoil programmatore dal lavoro riguardante i dettagli fisici dellamemorizzazione della informazioni, inclusi i problemi riguardantila gestione degli errori, la multiutenza, l’ organizzazione deidati. Molto importante è risultato anche il discreto grado distandardizzazione introdotto dall’ SQL, sia nella manipolazionedelle informazioni, che nei meccanismi di indipendenza dai datidelle applicazioni.Le 10 caratteristiche elencate di sopra costituiscono lecaratteristiche di massima di qualsiasi sistema di database.Naturalmente ciascun prodotto di questa categoria puòsingolarmante disporre di ulteriori funzionalità. Essi spazianoinfatti attraverso il vasto settore delle applicazioni gestionali,dalla semplice rubrica degli indirizzi fino al sistema ditransazioni su larga scala.

Concetti fondamentali

L’ architettura a tre livelli del modello relazionaleUn sistema di database è tipicamente costituito dai seguentilivelli costitutivi distinti: Interno tutto quello che riguarda l’ organizzazione interna dei

campi, record, indici, sistemi di accesso, codifica,lettura e scrittura dei dati sul corrispondente media didestinazione.

Concettuale

tutto ciò che riguarda il tipo dei campi e record, o lerelazioni tra di essi.

Esterno l’ interpretazione dei dati fornita dal’ applicazione cheli utilizza - che può presentare ulteriori vincoli per idati i tipi.

 Questo schema è noto come architettura a tre livelli di un sistemadi database. In alcuni casi qui o altrove è possibile trovareriferimenti ad una struttura semplificata che include solo duelivelli disitinti tra:

1. 1.    Fisico (interno) 2. 2.    Logico (concettuale ed esterno)L’ architettura a tre strati di un sistema di databaase haprofonde ripercussioni sul successivo argomento delle ArchitettureClient/Server.

Indipendenza dai datiUna caratteristica molto importante dei sistemi di database è l’indipendenza dai dati, che consente di modificare l’organizzazione di questi senza che tali modifiche disturbino ilfunzionamento dei programmi di manipolazione. In una architetturaa tre livelli questa indipendenza esiste sia al livello internoche concettuale.Indipendenza fisica-è l’ abilità di cambiare l’ organizzazione internadei dati (ad es. indici, formati) senza influire sui programmi dimanipolazione. Corrisponde all’ indipendenza sia sul piano fisicoche concettuale.Indipendenza logica-è l’abilità di modificare lo schema strutturaledei dati (ad es. aggiungere campi, relazioni), senza modificare leapplicazioni. Corrisponde ai livelli concettuale ed esterno.

Sistema di sicurezzaSi presenta spesso il problema di amministrare i livelli interno econcettuale di un sistema di database, e qualche volta anchequello esterno. Questo perché bisogna coordinare le modificheeffettuate dalle varie persone coinvolte nello sviluppo delsistema sia al livello fisico che logico. In genere questoproblema si risolve creando la figura di un amministratore didatabase, essenzialmente responsabile del mantenimento dellestrutture sia interne che esterne del sistema di database. Perestensione ci si rende conto che esistono essenzialmente trefigure di utenti del sistema di database:1. 1.    Amministratore: responsabile del livello fisico del sistemae coordinatore delle azioni di modifica in quell’ ambito

2. 2.    Programmatore: responsabile del livello esterno3. 3.    Utente finale: tutti coloro che fanno qualcosa di utiletramite gli strumenti creati dalle due figure precedenti

Elementi costitutivi

TabelleLa tabella è l’ ingrediente di base di qualsiasi sistema didatabase. Essa è costituita da righe (dette anche record o n-ple)e da colonne (dette anche campi o attributi). E’ quindi una

struttura dati rettangolare di tipo NxM senza particolari vincoliposti per le dimensioni di M o N, a parte quelli imposti dallapotenza del sistema hardware che ospita i dati. La differenzafondamentale tra M ed N esiste, però, ed è quella che la modificadel numero di colonne avviene piuttosto raramente ed è compitodell’ Amministratore del sistema di database, mentre il numero dirighe viene continuamente variato dagli utenti del sistema. E’evidente come la variazione del numero di colonne ha luogo nellostrato fisico e concettuale, mentre la variazione del numero dirighe ha luogo nello strato esterno.

Chiavi primarie e chiavi straniereUn sistema di database relazionale è quindi composto da un insiemedi tabelle. All’ interno di queste vengono definiti i campi (oattributi, n-ple), i quali sono destinati ad ospitare campi dinatura omogenea. All’ interno di un certo campo può esserecontenuto un solo tipo di dato. Per ottenere il risultato che ciponiamo, è quasi sempre necessario fare uso di più campi di tipodifferente. Ma la differenza fondamentale tra i vari campi non ènel tipo, che pure rappresenta già una grande differenza, ma nelruolo del campo. D’ altra parte è chiaro già dall’ espressione cheè stata usata: tipo, cioè attributo-ed un campo è di per sé unattributo del record, almeno secondo la terminologia usata sopra-eruolo, cioè compito svolto all’ interno non del record madell’insieme di tabelle che costituisce il sistema di databaserelazionale. Esistono tre ruoli possibili per un campo chepassiamo subito a precisare:1. 1.    ruolo banale, notabilmente quello di attributo2. 2.    chiave primaria, è un campo o un gruppo di campi il cuivalore deve essere unico tra le righe di una tabella

3. 3.    chiave straniera, è un campo o un gruppo di campi che assumeun valore scelto tra quelli contenuti in una tabella scelta inun particolare gruppo di tabelle dette tabelle entità.

Riassumendo il ruolo della chiave primaria sarà quello diidentificare univocamente tutte le righe di una tabella,stabilendo una corrispondenza biunivoca tra i valori assunti dallachiave primaria e le righe della tabella, mentre il ruolo dellachiave straniera è quello di ospitare valori ricevuti dalla chiaveprimaria di una qualche tabella. Va notato quindi che il modellorelazionale non consente righe duplicate all’ interno di unarelazione, ossia due record non possono essere identici in tutti iloro attributi. Inoltre ogni relazione ha una chiave primaria nelsenso stretto, costituita da tutti i campi della relazione. Questa

forma degenerata di chiave primaria non ha nessun tipo di utilità,per cui di seguito fisseremo l’ attenzione solo su chiavi primariesemplici, cioè costituite da uno, al massimo due campi di una datatabella.

Tabelle entità e tabelle associazioneA seguito della distinsione tra chiavi primarie e straniere, letabelle si dividono tra tabelle entità e tabelle associazione. Letabelle entità rappresentano oggetti del mondo reale che vogliamocaratterizzare con dei campi o attributi. Ogni record dellatabella entità rappresenta dunque uno ed uno solo di questioggetti del mondo reale. Le tabelle associazione servono inveceper rappresentare le relazioni che intercorrono tra oggetti di tipodiverso contenuti nel sistema di database relazionale. Per quantodetto sopra essi sono contenuti in differenti tabelle entità. Perestensione, dunque, le tabelle associazione servono in qualchemodo a memorizzare la relazione esistente tra due oggetti diversi,contenuti nel nostro sistema.Bisogna dire però che non tutte le relazioni richiedono tabelleassociazione. Infatti è possibile e anzi capita molto di frequentedi realizzare relazioni aggiungendo una o più chiavi straniere inuna tabella entità. Tali relazioni uno ad uno ed uno a molti sonodette relazione dirette, per distinguerle da quelle indirette molti amolti che necessitano di una o più tabelle associazione, comevedremo più oltre.

Dominio dei valori ed Integrità referenzialeSe dal punto di vista teorico il concetto di relazione è unconcetto chiave per la teoria dei sistemi di database relazionale,dal punto di vista pratico quello di integrità referenziale ha lostesso tipo di importanza.Il motore del database, negli strati interno e concettuale,effettua dei controlli sui dati immessi all’ interno dei campi.Come abbiamo detto precedentemente lo spostamento di compiti dallostrato esterno verso strati via via più interni dell’ architetturaa tre livelli, semplifica il lavoro di sviluppo dei programmi,ossia lo scopo ultimo della nostra attività. Maggiore è laquantità dei controlli sui dati che spostiamo dall’ esternoall’interno, maggiore sarà la semplificazione che otteniamo. Duecompiti essenziali del nostro motore sono dunque i seguenti:1. 1.    verificare la correttezza delle chiavi straniere, e gestirele corrispondenti eccezzioni-controllo di integrità referenziale

2. 2.    verificare l’ appartenenza degli attributi ai corrispondentiinsieme di valori-controllo di validità

L’ integrità referenziale è un insieme di vincoli che vengonofissati sulle chiavi straniere: una chiave straniera contenuta inuna tabella deve ospitare solo i valori contenuti nellacorrispondente tabella entità. Tolgliendo questo vincolo ildatabase non è più relazionale, anche se resta un sistema di database.La validità dei dati corrisponde in ultima analisi alla validitàdel tipo, più la validità del valore assunto. Tanto per fare unesempio nel campo ‘data_nascita’ di un ufficio anagrafico non deveessere possibile inserire il valore ‘Giuseppe Aielli’, e, unavolta che ci si decide di inserire una data, non deve esserepossibile inserire ‘300 a.C.’, ma solo una data successiva ad es.a ‘01-01-1850’. E’ da notare come, se noi togliamo questo secondotipo di controllo dal nostro sistema di database, esso non è piùun sistema di database, essendo degenerato in un archivio puro esemplice, cioè un insieme di file ed indici.

NormalizzazioneBuona parte del lavoro di ricerca svolto negli anni 80 a propositodei sistemi di database relazionale fu svolto sul concetto dinormalizzazione relazionale. Come abbiamo visto nel caso precedenteun sistema di database relazionale può degenerare fino al ruolo disistema di file ed indici, semplicemente per nostra scelta oignoranza. Questo significa che un sistema di database relazionalenon è in grado da solo di svolgere il compito di ottimizzare il suofunzionamento più esterno. Un passo di importanza fondamentale dacompiere verso la creazione di un database relazionale è quindiquello di normalizzare il suo schema, cioè quello di ottenere lamigliore rappresentazione concettuale possibile dei dati, sotto forma ditabelle entità, associazioni e relazioni. L’ essenza dellanormalizzazione, che si vedrà in dettaglio più avanti, è quella didividere i dati contenuti in tabelle con tante colonne, in piùtabelle ciascuna con un numero di colonne inferiore. Questodiventa necessario quando troppe informazioni sono rappresentate in unasola tabella, quando la rappresentazione dei dati può portareconfusione, quando la stessa informazione è presente in più postidifferenti, oppure quando le informazioni sono male associate traloro. Si noti come ad esempio la duplicazione di una stessainformazione all’ interno di un sistema di database conduce comeconseguenza più immediata ad un potenziale conflitto tra le duefonti, ed ad uno spreco di spazio e di risorse. Per fortuna sonostate definite una serie di regole formali dette forme normali, col

lo scopo di eliminare problemi ed errori nella definizione delloschema. Tali forme normali, per la loro estrema importanza,saranno oggetto di trattazione successiva.

Proprietà delle tabelleIl modello relazionale deriva molta della sua semplicità da treproprietà delle tabelle:1. 1.    le tabelle sono insiemi nel senso matematico: le righe sonouniche e non sono ordinate

2. 2.    gli attributi non sono ordinati: si indicano col nome, ed ilnome deve essere unico all’ interno di una tabella

3. 3.    i valori assunti dai campi sono atomici: un campo non puòcontenere al suo interno un insieme (I forma normale).

Proprio a causa della matemeticità del modello relazionale è statapossibile la realizzazione di motori di database relazionali ingrado di assolvere in modo efficiente al compito di memorizzare edelaborare le informazioni. Questo ultimo compito viene poi svoltoin modo elegante dalla formulazione di un semplice linguaggio diinterrogazione, l’ SQL.

Accesso concorrente e recupero

IntroduzioneControllo dell’ accesso concorrente e recupero sono duecaratteristiche molto importanti per un sistema di databaserelazionale. Esse contribuiscono a mantenere l’ integrità logica efisica di un database, rispettivamente. Il recupero di un sistemadi database relazionale consiste nella capacità di ripristinareil funzionamento dopo un errore grave del sistema. Molte sono leragioni che possono condurre ad un crash di sistema, e non è ilcaso di analizzarle in questa sede. Preso atto di questaeventualità e del fatto che i sistemi di database relazionale sonoparticolarmente delicati a causa della loro natura estremamenteprecisa, è necessario attuare essenzialmente due politiche:1. 1.    backup dei dati sistematico ed affidabile2. 2.    uso delle transazioni, se supportate dal sistema.Sul primo rimedio niente da dire. Il secondo consiste nellacapacità del sistema di database relazionale di effettuare leoperazioni a blocchi. Per cui se non si riesce ad effettuare tuttoil blocco di operazioni, allora le operazioni saranno annullateper tutto il blocco corrente, ripristinando la situazioneesistente prima di effettuare la transazione.Il controllo di concorrenza, invece, si occupa della gestionedegli aggiornamenti e modifiche dei dati da parte di molti utenti

contemporaneamente, tramite il meccanismo del blocco dei dati. Nelcaso più semplice si tratta di porre un blocco esclusivo per ilnumero di record coinvolti da una certa operazione, da parte di uncerto utente: tutti gli altri utenti non saranno in grado dimodificare i record bloccati fino al termine di quella operazione.Esistono due tipi di blocco:        Fisico: avviene in modo esplicito a livello di record, dipagina o di tabella

       Logico: è definito da una espressione in una query chedefinisce un set di record da bloccare

Il tipo di blocco utile per una certa operazione dipende da questanel seguente modo:1. 1.    il blocco di una intera tabella è quello più efficiente dalpunto di vista computazionale, ma comporta la minoreflessibilità possibile, perchè solo un utente alla volta puòmodificare i dati contenuti nella tabella

2. 2.    il blocco di un singolo record è il meno efficace dal puntodi vista computazionale, ma il più flessibile per l’ uso

3. 3.    il blocco di una pagina rappresenta una scelta vantaggiosadal punto di vista computazionale, senza sacrificare quasi nulladella flessibilità del sistema, dal momento che i record sonoregistrati sul disco sotto forma di pagine fisiche costituite dapiù record alla volta.

Il blocco dei record può condurre a situazioni di errore, laddovedue o più utenti richiedano sistematicamente il blocco di un certorecord o di una certa pagina: l’ utente A potrebbe attendere che Brilasci una certa pagina e viceversa. Questa è detta situazione dideadlock.

TransazioniMolti sistemi di database relazionale implementano meccanismi ditransazione, che provvedono contemporaneamente al recupero ed alblocco delle informazioni. Il nome di transazione provieneprobabilmente dall’ esempio classico in letteratura che viene diseguito riproposto: bisogna trasferire una somma da un conto di uncerto cliente a quello di un certo fornitore-si tratta di unatransazione anche nel linguaggio bancario commerciale.In che modo il sistema di database realizza tale tipo dioperazione? Il sistema è in uno stato consistente all’ inizio edalla fine della operazione, il che vuol dire che i due statiiniziali e finali sono coerenti con la realtà dei fatti, anche sepuò esserci inconsistenza per brevi (ed invisibili) istantidurante l’operazione, per esempio quando il conto del cliente è

stato già addebitato e quello del fornitore non è stato ancoraaccreditato. Per chi pensa che la soluzione sia di eseguirecontemporaneamente le due operazioni bisogna tenere conto che inprimo luogo non è possibile eseguire due operazionicontemporaneamente sulla stessa macchina a causa della naturaessenzialmente seriale di questa, ed in secondo luogo, se anchefosse, non si avrebbe la garanzia che le operazioni venganoentrambe eseguite correttamente. La soluzione consiste quindi nelrendere le due operazioni una sola operazione logica, dettatransazione. La transazione sarà completata solo quando entrambe leoperazioni sono entrambe completate correttamente. In casocontrario sarà annullata l’ intera operazione. Le transazioni sonola migliore soluzione possibile al problema del controllo diaccesso e della coerenza dei dati, perché l’ utente finale nondeve avere a che fare con blocco, sblocco, backup ed altro. Nelcampo dei sistemi di database relazionale l’ uso delle transazioniporta solo dei benefici e non è soggetta a nessuna limitazione,senza contare che i meccanismi interni al motore che implementanole transazioni possono anche rendere più efficienti molteelaborazioni a causa della bufferizzazione delle operazioni cheviene effettuata durante un ciclo di transazioni.

Database distribuitiIl termine database distribuito viene usato di solito con varisignificati differenti. Noi intendiamo per database distribuito undatabase che abbia almeno le due seguenti caratteristiche:possibilità di accesso da remoto e capacità di gestire un unicodatabase suddiviso su più di una macchina.

Accesso remotoLa maggior parte dei sistemi di database supportano l’ accessoremoto. Ciò significa che l’ utente di un certo programma attingeo manipola dei dati che non risiedono sulla macchina che stàusando, ma su una macchina lontana che può trovarsi sulla suastessa rete locale o anche su una rete differente. Il tutto senzache l’ utente possa percepire questo fatto, cioè come si dice ingergo, ‘in modo trasparente’. In altre parole egli ‘vede’ datilocali o remoti esattamente nello stesso modo, perché il softwarerende ‘invisibile’ il processo di comunicazione che avviene con lamacchina lotana.Il meccanismo attraverso il quale un database riesce adimplementare questa funzionalità è molto semplice: solo unapiccola parte del sistema di database relazionale risiede con il

programma applicativo nella macchina dell’ utente, detta client.Questa porzione di applicazione è responsabile essenzialmentedella visualizzazione dei dati e della codifica di query dainviare alla macchina remota, detta server, che gli restituiscepoi i risultati sotto forma di record, sempre tramite la rete(locale o no) attraverso la quale aveva ricevuto le ‘richieste’.Esistono poi delle complicazioni addizionali dovute alla naturaeterogenea di alcune reti, in particolar modo per quello cheriguarda le reti basate su Internet. Attualmente una soluzione cheha preso molto piede consiste nell’ usare i meccanismi dicomunicazione intrinseci di Internet per effettuare il dialogodetto prima: il client invia le richieste tramite meccanismiinterni come il metodo POST o la posta elettronica (e-mail) ericeve le risposte direttamente in HTML dal server.

PartizionamentoSi definisce ‘database distribuito’ un insieme di database cheappaiono all’ utente come un unico database. Nel caso più semplicei database possono essere su di una unica macchina e possono ancheessere ridotti al numero di uno. In questo caso si parla direplicazione di database. Più in generale però si verifica il casoche i database risiedano su macchine differenti in quanto lacaratteristica principale del partizionamento consiste nel volerdistribuire il carico di lavoro tra differenti macchine server,con l’ evidente scopo di ottimizzare il processo complessivo. L’evidente condizione per realizzare efficientemente ilpartizionamento di un database è:1. 1.    che vi sia un partizionamento logico dei dati, cioè che lasuddivisione abbia senso dal punto di vista organizzativo primaancora che tecnico

2. 2.    che la necessità di comunicazione esistente tra le parti daseparare sia piccola o nulla

Mancare la prima condizione è un errore che porta confusione delloschema del database. A questo punto se anche vi fossero deibenefici dal punto di vista computazionale-comunicativosicuramente si avranno svantaggi nello sviluppo dei programmi.Invece mancare la seconda condizione significa che se anchemiglioriamo il processo dal punto di vista computazionale,sicuramente lo peggioriamo da quello della comunicazione, e quindinel complesso non apportiamo miglioramenti molto significativi.Dentro le condizioni dette prima il partizionamento di undatabase:

1. 1.    consente a ciascun reparto di organizzare in modo autonomole strutture dei dati ed i meccanismi relativi al loro impiego

2. 2.    consente ancora di effettuare query ed analisi su tutto ilcomplesso dei dati ed in modo trasparente, con la gli stessimeccanismi e con la stessa semplicità di un sistema di databasenon partizionato.

I database possono essere partizionati in una varietà di modi.Ricordiamo brevemente i principali:1. 1.    tabelle differenti in database differenti-partizionamentosemplice

2. 2.    la stessa tabella separata in due o più database con alcunerighe da una parte e le altre da un’ altra-partizionamentoorizzontale

3. 3.    la stessa tabella separata in due o più database con alcunecolonne da una parte e le altre dall’ altra-partizionamentoverticale

4. 4.    la stessa tabella in più copie sincronizzate su macchinedifferenti-replica.

Progetto di database relazionali

IntroduzioneNell’ ambito dello sviluppo di applicazioni basate su database, ilprogetto dello schema riveste una importanza particolarmentevitale. Infatti da una parte risulta chiaro che questo ènecessariamente il primo passo da compiere mentre dall’ altro ci sirende facilmente conto di due disastrose conseguenze:1. 1.    ogni errore compiuto nella fase di definizione dello schemaha ripercussioni sul funzionamento dell’ applicazione, ed ognimodifica dello schema ha la potenzialità di inficiarne ilfunzionamento

2. 2.    più ci si spinge avanti nel lavoro di sviluppo più lastruttura dati risulta essere inadeguata nel tempo a causa dell’accrescimento conoscitivo delle tematiche che si verifica dallaprima stesura dello schema in poi.

In questo capitolo vedremo come evitare il primo dei due problemi.Posto che il progetto accurato dello schema del database se nonrisolve del tutto almeno mitiga le conseguenze dette sopra, nonesiste però una soluzione a portata di mano per il secondo deidue. Nel capitolo intitolato ‘Proposta per un modello di sviluppoapplicativo’ si tenta di dare una possibile risposta a questoproblema.

Sviluppo concettualeRiguardo le tecniche di sviluppo e progettazione di un database,bisogna dire che la loro applicazione deve essere preceduta da unaattenta analisi della realtà che si vuole modellare. E’ necessarioevitare l’ errore molto comune che è quello di aver fretta dipassare alla fase di sviluppo dell’ applicazione. Successivamentevengono spiegate delle tecniche che servono per abbreviare ilpercorso di sviluppo di una applicazione basata su database. Lespiegazioni sono piuttosto sintetiche e sono intese come guida diriferimento rapido per lo sviluppatore.

Chiara determinazione della realtà da modellareLa prima cosa da fare è chiaramente quella di farsi raccontare daqualcuno che cosa bisogna ottenere dal software che si desiderasviluppare. In questa fase probabilmente è necessario affiancareil personale della realtà in questione. In altri casi è probabileche il software venga sviluppato da noi per noi stessi. Inciascuna delle due ipotesi è necessario soffermarsi a ragionare su

un concetto fondamentale: quasi sempre il nostro modo di lavorarenon è sufficientemente generale da poter essere trasformato inprogramma.Ciò significa che il nostro modo di lavorare è troppo personaleper poterlo proporre ad altri tramite il software che si intendescrivere, cosa che probabilmente determinerà l’ insuccesso delnostro software. D’ altra parte ricordatevi che buona parte delsoftware che si scrive non è per nulla necessario agli utenti cuiè destinato, ma solamente utile. Di conseguenza ricordatevi sempredi pensare le cose in generale e dall’ alto. In alternativa puòaccadere che la nostra sintesi della situazione sia unsottoinsieme di un problema più vasto e generale. Di conseguenzala nostra soluzione risulterà stretta, specie in un ambitomultiutente, ove le necessità ed il modo di pensare le soluzionivaria da individuo ad individuo.Non esiste naturalmente un metodo su come descrivere in modoadeguato un problema senza essere né troppo generici né troppovincolati da una soluzione stretta. Il buonsenso insegna cheessere il più possibile metodici e non trascurare nessun dettagliodurante l’ interazione col personale responsabile delladescrizione è un buon punto di partenza. Il resto lo farànaturalmente l’ esperienza. Successivamente alla descrizione ‘a parole’ della situazione diriferimento, è necessaria la scelta di un modello rappresentativoche consenta di modellare la realtà tramite un diagramma. Noioptiamo senza dubbio per il modello rappresentativo ER (entità-relazione).

Il Modello ERIl modello ER fu proposto da Chen 1976. Esso è al contempo moltosemplice e consente una rappresentazione espressiva delle realtàin esame. Inoltre, tramite un metodo assolutamente algoritmico èpossibile passare con semplici passaggi da questo modello a quellorelazionale descritto prima. In questa occasione bisogna citare ilfatto che esistono in commercio prodotti software per il disegnodei diagrammi ER e la corrispondente trasformazione nel modellorelazionale: ricordiamo Info Modeler, ER-Win, S-Designor, DBSee++e Code Painter. Gli ultimi due sono prodotti che per la lorocompletezza ricadono nella catagoria dei CASE (acronimo diComputer Aided Software Design).Il modello ER è costituito soltanto da tre elementi: entità, relazionied attributi. Questi elementi vengono disposti su un diagrammaseguendo questo criterio: le entità corrispondono ai nomi e

vengono raffigurate con dei rettangoli, le relazioni corrispondonoai verbi e si raffigurano con dei rombi (o con degli ellissi). Irettangoli ed i rombi vengono collegati con delle linee. Tanto perfare un esempio la locuzione “i miei clienti pagano le fatture” hauna traduzione nel diagramma ER in:   

i miei clienti pagano le fatture   Il metodo sotteso dall’ esempio precedente è piuttosto bruto, masemplice da capire e funzionale. Passiamo ora in rassegna lecaratteristiche essenziali degli elementi del diagramma ER: leentità sono gli elementi del modo reale, come le persone, lefatture o i prodotti. D’ altra parte ogni entità è costituita dauna serie di attributi. Ad esempio i clienti hanno gli attributidi Nome, Cognome, Indirizzo, Città ed altri ancora, mentre lefatture hanno come attributi il Numero, la Data o l’ Importo. E’importante capire che un attributo o un gruppo di attributicostituisce la chiave primaria di ogni entità. Non ripetiamo ilsignificato dei termini già discussi in precedenza, ma ricordiamosolo che la chiave primaria esiste sempre ed è unica in ciascunaentità. Si tratta di sceglierla tra gli attributi posti, oppure dicreare un nuovo attributo, tipicamente un codice identificativo. Una relazione, invece, è un legame di tipo logico che coinvolgedue o più entità. Le relazioni hanno un unico attributo esplicito,la cardinalità. In generale la cardinalità indica il numero dientità dell’ insieme A che può essere associato ad ogni elementodi un insieme B. Prestare sempre attenzione alla cardinalità diuna relazione che non è sempre semplice determinare. Ad esempio ilmatrimonio tra due individui, almeno nella società occidentale, hauna cardinalità 1:1, ma evidentemente può avere diversacardinalità altrove. Sono moltissime le ambiguità che possonopresentarsi nella decisione sulla cardinalità di una relazione.

Sfruttare il modello ER evitando di ragionare in termini dimodello relazionale durante la fase iniziale di sviluppoIn generale non bisogna perdere di vista cosa deve fare la nostraapplicazione a favore di come deve farlo. A questo scopo bisognaper prima cosa dedurre il diagramma ER completo in ogni sua partee poi bisogna soffermarsi a lungo nel perfezionamento dello schema

fino a quando non si è sicuri di essere il più vicini possibilealla perfezione. In generale da un diagramma ER ben fatto discendeuno schema relazionale senza difetti. Uno schema relazionale senzadifetti rappresenta la parte pricipale di qualunque applicazione.Esso consente in primo luogo la stesura immediata del programmaapplicativo. In seconda istanza facilita migliorie ed estensionida fare in seguito sul programma stesso, oltre che sullo schemadei dati. Vediamo ora un algoritmo per la creazione dello schemarelazionale a partire dal diagramma ER.sviluppo del modello ER primitivo: 1. 1.    suddivisione del problema in domini2. 2.    individuazione delle entità3. 3.    individuazione delle relazioni4. 4.    definizione delle chiavi primarie e degli attributiprincipali.

Riguardo al primo argomento esso consiste nel suddividere unproblema complesso in più sottoproblemi di tipo semplice, daaffrontare separatamente. Per quello che riguarda il secondo edil terzo abbiamo già accennato un metodo che consiste nel trovaredai nostri appunti le entità individuando tutti i sostantivi, e lerelazioni tutti i verbi del nostro discorso. Naturalmente ènecessario individuare tutti quelli non pertinenti ed i sinonimi,ma alla fine il problema sarà quasi risolto. Volendo proseguirenella analogia gli aggettivi corrispondono agli attributiprincipali, mentre, per quello che riguarda le chiavi primarie ildiscorso è un po’ più complicato. Intanto sappiamo che la chiaveprimaria esiste di sicuro, ed è costituita dall’ unione di tuttigli attributi della nostra entità. A questo punto viene spontaneodi cercare la più piccola chiave primaria tra tutti gli attributidi una entità. Spesso è sufficiente un solo campo o due. Altrevolte è necessario creare un campo apposito, ad esempio il‘Codice’. In definitiva questa fase corrisponde nell’individuazione di un elemento diversificatore tra gli elementi chepartecipano alla nostra entità. Un esempio servirà per chiarire il tipo di percorso da fare. E’evidente come il ‘Cognome’ di un cliente non sia di per sésufficiente per essere primario. Anche l’ unione di ‘Cognome’ e‘Nome’ non basta. Si potrebbe pensare di aggiungere la data dinascita, e a questo punto si ha molta probabilità che la somma diquesti tre attributi identifichi in modo univoco una persona. Ineffetti però il ‘Codice_fiscale’ da solo, è già in grado direggere il ruolo di chiave primaria. In alcuni casi però potrebbenon essere utile come dato, il ‘Codice_fiscale’, oppure potrebbe

non essere sempre disponibile. In questo caso si potrebbefinalmente optare per un nuovo campo, ad esempio un ‘Contatore’che assegna un numero intero diverso per ogni cliente.

Completare il modello ER in ogni sua parte prima di passare allastesura del modello relazionaleNon basta disegnare il diagramma ER se poi non si adottano delleopportune iniziative di miglioria. Per questo è necessario passarealla: seconda fase: riesame del modello:        conversione di entità in attributi        conversione di attributi in entità        spostamento di attributi da una entità ad un’ altra        introduzione di nuove entità        introduzione di nuovi attributi        introduzione di nuove relazioniIn questo caso non è necessario seguire un ordine particolare. Lecategorie indicate sono categorie teoriche di intervento suldiagramma ER primitivo. Probabilmente sarà necessario effettuaresolo poche modifiche. In generale, però, il primo diagrammacreato dopo una certa analisi non è mai adeguato, di conseguenzaquesta fase è molto importante ed è strettamente collegata con ilsuccessivo argomento delle forme normali. Passiamo ora adanalizzare il contenuto di ciascuna categoria.La conversione di entità in attributi può avere luogo solo quandouna tabella degenera in soli due campi, con una chiave primaria ela sua descrizione. Facciamo un esempio: se in una tabellacontenente una anagrafe di persone si indicasse la città comechiave straniera di una tabella località, allora potrebbe esserepossibile trasferire il campo località dalla tabella omonima edeliminare la tabella località. E’ una questione di scelte, inquanto l’ eliminazione di una tabella e di una relazione ha ilbenefico risultato di semplificare lo schema. D’ altra parte puòcomportare il disagio di inserire anche il campo cap nell’anagrafe, mentre questo, essendo dipendente funzionalmente dallalocalità ha senso nella relativa tabella. A questo punto, nelsistema con due tabelle l’ inserimento del cap di una certalocalità ha luogo una volta sola, nella tabella località, mentrenell’ altro sistema ha luogo in tutte le righe ove si usa quellalocalità, col risultato di usare più spazio di quelloeffettivamente necessario, e col rischio di incoerenza dei dati.In questo caso se l’ unca informazione effettivamente necessaria èquella del nome della località è preferibile non usare la seconda

tabella, mentre se occorre anche il cap allora conviene usarnedue. Senza contare che nel futuro si potrebbe decidere di averebisogno anche di altre informazioni come il prefisso telefonico,il codice ISTAT o altro. Si tenga presente la regola genericasecondo cui ‘il piccolo stà nel grande’ è molto utile insituazioni come questa, per cui è probabilmente è meglio pensareda subito ‘in grande’ i nostri schemi. Un’ altra regola che misento di dare è che ‘non si usano mai abbastanza le relazioni’, equesto perché è molto più facile vedere in giro il più gravedifetto opposto.E’ molto semplice capire la situazione inversa che non poneproblemi di sorta. Ricorriamo al solito esempio: può presentarsila necessità di avere l’ informazione del numero civico, mentreabbiamo indicato un solo campo per l’ indirizzo. Si tenga presentequale grave ripercussione sul sistema nervoso può avere lanecessità di dividere un campo in più sottocampi, quando ormaisono stati già inseriti nel sistema molti record. Inoltre talenecessità può sorgere anche in modo imprevisto ad esempio perché ènecessario effettuare un collegamento con un database esterno. Sitenga presente in proposito il fatto che è molto più facileriunire dopo due campi che erano stati pensati separati, che nonl’ opposto. Naturalmente vale ancora il discorso di pensare ingrande che, come al solito, si dovrà bilanciare con la nostranecessità di avere uno schema semplice, cioè con il numero minimodi campi e di tabelle.Lo spostamento di un attributo è necessario in fase dinormalizzazione dello schema. Tale fase è analizzata in dettagliotra poco.L’ introduzione di nuove entità, relazioni ed attributi è qualcosache viene automatica. In ogni caso, dopo sarà necessarioriconsiderare lo schema per vedere se le introduzioni non rendanoinutili oggetti preesistenti o non si sovrappongano ad essi.Il procedimento indicato è dunque ciclico. Ripetendolosuccessivamente si dovrebbe giungere dopo qualche ciclo ad unasituazione di convergenza nella quale non ci sembra più necessariointervenire.A questo punto è possibile passare alla fase finale che consistenella: creazione dei vincoli di integrità referenziale e di dominiocome si è visto in precedenza l’ integrità dei dati si puògarantire fissando due tipi di vincolo, uno referenziale ed uno didominio. Il vincolo referenziale è necessario altrimenti, come

abbiamo visto salta tutto il modello relazionale: nel caso piùsemplice i campi della chiave straniera devono avere valori presisolo dall’ insieme dato dai valori presenti nella tabella entitàrappresentata, e questo in qualsiasi momento. Il vincolo didominio, invece, è opzionale ma non per questo meno importante, efa’ sì che un dato campo non possa assumere valori non logici peresso, come ad esempio età espresse con numeri negativi, date dinascita maggiori della data di oggi o valori nulli ove sianonecessari dei dati. In questa fase si può anche fare attenzione adaltre caratteristiche come il formato di visualizzazione o dimemorizzazione dei dati, che, pur non rappresentando dei vincoli,sono comunque della loro stessa natura in quanto agiscono allaradice del processo di sviluppo.

Implementazione del modello relazionaleIl modello realzionale è evidentemente basato sul concetto direlazione. Secondo la definizione la relazione è un qualunque sottoinsiemedel prodotto cartesiano di una lista di domini (insiemi). Un dominio non èaltro che un elenco di valori, mentre il prodotto cartesiano è l’elenco ottenuto da tutte le coppie che è possibile formare avendodue elenchi di valori. Dunque la relazione è qualcosa direttangolare con tanto di righe e colonne. In particolare larelazione può coincidere con la tabella di un qualunque database,così come la colonna o attributo coincide con il campo di unatabella. La forte matematicità del modello relazionale fa’ sì chesia stato possibile formalizzare una vera e propria algebra relazionaleche è alla base del linguaggio SQL e dei procedimenti di calcoloed ottimizzazione dei sistema di database relazionale. Il modellorelazionale è pertanto molto poco espressivo in considerazione delfatto che ogni tabella è considerata una realtà separata dallealtre e non esiste la possibilità di definire esplicitamente lesue relazioni con le altre tabelle. Una volta che si dispone deldiagramma ER è quasi automatica la sua conversione nel modellorelazionale:        per ogni entità si crea una tabella con la sua chiaveprimaria

       per ogni relazione binaria 1:n si crea la chiave stranieranella seconda tabella

       per ogni relazione m:n si crea la tabella associazione.E’ buona regola seguire anche alcune norme come le seguenticonvenzioni di denominazione degli oggetti:        far precedere il nome di una tabella dal prefisso tbl        far precedere il nome di una chiave dal prefisso Id

       disporre le chiavi, primarie o straniere che siano, comeprimi campi di una tabella, la primaria prima delle eventualistraniere

       a parte il prefisso chiamare una tabella con lo stesso nomedell’ entità; lo stesso dicasi per la corrispondente chiaveprimaria, se possibile

       per una chiave straniera usare lo stesso nome della chiaveprimaria che rappresenta

       usare il carattere AltoBasso senza usare spazi tra leparole sia per le tabelle che per i campi.

Se si seguono queste semplici regole si otterrà un modellorelazionale più espressivo del normale. Infatti ogni tabella cherappresenta entità avrà lo stesso nome della sua chiave primaria(a parte il prefisso). Ogni tabella mostrerà esplicitamente larelazione diretta ad un’ altra a causa del nome di quest’ ultima(a parte il prefisso) inserita tra i primi campi. Ogni tabellaassociazione conterrà almeno due chiavi straniere e nessuna chiaveprimaria.

Evitare sistemi di dati ridondanti-normalizzazione

Scelta del tipo di campoIl primo e più semplice modo di evitare ridondanza è la sceltaaccurata del tipo dei campi. In questa occasione vale la pena diricordare che, a differenza dai primi sitemi di database basatisui campi a lunghezza fissa, i moderni sistemi di databaserelazionale utilizzano solo lo spazio effettivamente usato per cuiad esempio, un campo località posto ad una dimensione di 50caratteri utilizza 50 byte di spazio nel caso peggiore e 0 bytenel migliore. Di conseguenza l’ uso di vincoli troppo restrittiviper le dimensioni dei campi di testo hanno un effetto modesto sulrisparmio di spazio, ma possono portare conseguenze spiacevoli perl’ utilizzatore. Non c’ è invece nessuna ragione per usare unnumero intero o peggio uno con la virgola se siamo sicuri di usarevalori compresi in un intervallo inferiore, come ad esempio da 0 a256. E’ sicuramente da evitare, infine, l’ errore di moltianalisti del passato che hanno memorizzato le date con 6 caratterinumerici, rendendo possibile quello che viene definito l’ ‘incubodell’ anno duemila’.

Forme normaliEsistono molte definizioni di normalizzazione. Per noi un database èin forma normale se ogni sottoinsieme di relazioni rispetta la terza forma normale. Letre forme normali sono le seguenti:

1. 1.    Prima forma normale-tipo di dato semplice in ogni campo2. 2.    Seconda forma normale-dipendenza funzionale e completa di unrecord dalla sua chiave primaria

3. 3.    Terza forma normale-dipendenza intransitiva del record dallachiave primaria.

Vediamo che cosa significano le forme normali.La prima forma normale impedisce in sostanza che un campo possacontenere una lista di valori. Bisogna notare che anche se imoderni sistemi di database relazionale non consentono di per séquesta possibilità, è possibile che l’ analista fantasioso decidadi creare un campo contenente ad esempio una stringa di 10indicatori tramite un campo di testo di lunghezza 10. In tale casoè necessario creare 10 campi separati.Per dipendenza funzionale si intende corrispondenza biunivoca trail record e la chiave primaria. In altre parole, stabilito ilvalore della chiave primaria, tutti gli altri campi sonoindividuati in modo unico da questo valore. Viceversa ad ognichiave primaria corrisponde sempre un solo record. La dipendenzacompleta indica il caso che tale dipendenza avviene tramite tuttii valori della chiave primaria, e non ad esempio, da unsottoinsieme di essa. Per altro verso ‘la chiave primaria è la piùpiccola’, o non contiene informazione non necessaria.Infine la dipendenza è non transitiva se non è possibiledeterminare il valore di quel campo ricorrendo ad una funzione oad altro artificio. In particolare il campo nazione in una tabellaanagrafica dipende in modo transitivo dal campo città di quellastessa tabella: una volta nota la città è nota anche la nazione.Per concludere ricordiamo che le forme normali dipendono una dall’altra: per essere in terza forma normale un certo database dovràavere tutte le sue tabelle anche in seconda forma normale, e cosìvia.Il procedimento appena indicato conduce alla realizzazione dischemi di database corretti ed efficienti. Le conseguenze positivedello sforzo affrontato in questa sede si avvertiranno durantetutto il corso dello sviluppo applicativo ed anche dopo. Potreteanche misurare la bontà del progetto come l’ inverso dellemodifiche che sarà necessario apportare in seguito allo schema,oppure al lavoro di sviluppo che si renderà necessario. Ilprogetto ottimo di un sistema porta anche altri benefici piùinvisibili, come ad esempio il fatto di creare tabelle di valoriche non erano esplicitamente richieste e che risultano in unamaggiore configurabilità dell’ applicativo finale, o in optionalcomunque utili per gli utilizzatori.

Architetture Client/Server

IntroduzionePer architettura Client/Server si intende la possibilità di legarele tematiche applicative inerenti quelli che abbiamo definito lostrato interno e concettuale di un sistema di database relazionalein una particolare macchina detta server, lasciando la parte dettaesterna sulla macchina dove opera l’ utente finale, detta pertantoclient. Questa architettura prevede di accumulare le risorseinformatiche più costose e delicate in una sola macchina e didistribuire il relativo servizio tramite una rete locale ogeografica. In tal modo anche macchine poco potenti potrannoeseguire operazioni complesse in tempi brevi. D’ altro canto ogniintervento migliorativo effettuato sul server sarà percepitoimmediatamente da ogni utente della rete. Questa architettura sicontrappone al concetto di condivisione dei file che prevede cheogni client abbia una copia del database in memoria nel momento dieseguire un’ operazione. Quest’ utlimo approccio, menosofisticato, prevede in tal modo un intenso traffico di rete ediviene di solito inattuabile con il crescere della dimensione deifile del database. Il grande vantaggio delle architettureClient/Server consiste infatti nell’ inviare al server solorichieste sotto forma di costrutti SQL. Il server restituisce asua volta solo i record necessari, rendendo minimo l’ utilizzodelle risorse di comunicazione. Riassumendo i principali vantaggidi una architettura Client/Server sono:        minore impiego di risorse di rete        maggiore velocità operativa        maggiore economicità con un opportuno numero di utenti        maggiore scalabilità, dato che si agisce direttamente esolo sul server.

Architetture C/S ad 3 stratiL’ architettura Client/Server rispecchia per molti versi quelloche abbiamo detto a proposito di architettura del modellorelazionale. Tradizionalmente la maggior parte delle applicazioniClient/Server vengono considerate come applicazioni a due strati. Idue strati in questione sono costituiti, come si immagina, dalprocesso eseguito sul server e da quello eseguito sul client.Questa suddivisione è evidente data la diversità fisica dellemacchine coinvolte. Non altrettanto evidente è per un progettistastabilire come porre la linea di demarcazione che decide dove una

certa elaborazione deva essere eseguita e perché. Nel seguito sicerca di dare una risposta a questa domanda.Una applicazione complessa non dispone solo dei servizi diinterfaccia e dei servizi di database. Come abbiamo già vistoanche per il modello relazionale esiste un terzo livello, cheabbiamo chiamato concettuale. Per comodità lo abbiamo riunito conquello interno nello strato fisico per fare distinsione dallostrato logico. L’ architettura Client/Server mantiene unastruttura a tre strati ma essi non coincidono di necessità conquelli visti precedentemente. Un esempio varrà a chiarire.Supponiamo di dover produrre un’ applicazione per la creazione dipreventivi per una grande organizzazione, e consideriamo lecaratteristiche richieste per tale applicazione:1. 1.    il codice di un articolo deve essere (unico) e composto da13 caratteri

2. 2.    la modifica del codice di un articolo deve ripercuotersiimmediatamente su tutti i preventivi che contengono quel codice,o deve essere impossibile

3. 3.    se un cliente è in debito oltre il fido previsto non deveessere possibile creare l’ ordine ma solo il preventivo

Per quanto visto finora i controlli al punto 1 e 2 sarannoeffettuati egregiamente dal database, in particolare per quelloche riguarda l’ aggiornamento in cascata dei record collegati adun certo codice, e pertanto saranno effettuati sul server nelprocesso database.Cosa dire dell’ ultimo punto? Esso riguarda essenzialmente unproblema di politica aziendale, pertanto è suscettibile dicambiare nel corso del tempo molto più di quanto non faranno adesempio le relazione all’ interno del sistema di database, puressendo un problema che resta molto vicino al database e alla suanatura di controllore. Per tale ragione questo nuovo tipo dicontrollo rappresenta uno strato intermedio tra client e server.Ciò non toglie che da qualche parte dovrà comunque essereeseguito. Abbiamo dunque il problema di decidere dove fareeseguire lo strato intermedio delle applicazioni Client/Server. Lostrato intermedio cui abbiamo accennato viene anche detto stratodegli oggetti LOBject da Line Of Business Object, definizione concui si intende sottolineare il fatto che essi includono tuttoquanto riguarda la linea di condotta di una certa applicazione.Riassumendo una architettura Client/Server è costituita daiseguenti tre strati: data Servizi di database

business Tutto quanto riguarda la lineadi condotta applicativa

user Interfaccia utenteResta il problema di stabilire la demarcazione non sempre faciletra data e business, oltre alla macchina che deve eseguire ilservizio business. Purtroppo non esistono, almeno per ora, delleregole matematiche che consentano di ottenere un risultato ottimo,come le regole di normalizzazione dei database viste finora. Soloil buon senso ci può aiutare a risolvere il problema. Inparticolare una regola destinata a durare nel tempo è molto probabile cheappartenga allo strato data, ma ciò è valido solo molto in generale:avete mai visto qualcuno con più di 150 anni di età, oppure piùalto di due metri? Se anche esistesse qualcuno così non per questola vostra applicazione avrebbe fallito il suo scopo. Più difficiledire dove debba essere eseguito un processo LOBject. Una regolaeuristica potrebe essere la seguente: se il processo deve compiereoperazioni complesse basandosi su pochi dati, esso è da eseguiresul client, altrimenti sul server. Infatti un processo che facciagrande uso della CPU non può essere eseguito su un server che deveessere usato solitamente da molti utenti, mentre un processo chefaccia uso intensivo dei dati ha la sua sede naturale proprio nelserver di database, ottimizzato allo scopo.Questa breve trattazione dei sistemi Client/Server intendeva solointrodurre i concetti essenziali e non esaurice il tema, è solointeressante far notare come vi sia un seme nel modellorelazionale a tre strati che porta direttamente al concetto diClient/Server.

BibliografiaR.G.G. Cattell, “Object data management”, Addison Wesley, 1994O.Bettelli, “Dati, relazioni e associazioni”, Apogeo, 1991J.D.Ullman, “Principles of database and knowledgebase systems”,Computer science press, 1988C.Batini, S.Ceri, S.Navathe, “Conceptual database design”,Benjamin Cummings, 1992F.Balena, “Automazione remota in VB4”, Computer programming, 63,Gennaio 1997Lorenzo Vandoni, “Pensare un database...”, DEV, 20, Gennaio 1997R.Dadda, “PDCA ed altri spunti...”, BIT, 104, Aprile 1995