CAPITOLO 2 - Dai DBMS agli ORDBMS: l'impiego di PostgreSQL per realizzare l'applicazione.

Transcript

1 - Dai DBMS agli ORDBMS: l'impiego di PostgreSQL per realizzare l'applicazione. Nell'introduzione abbiamo accennato brevemente a due tipologie di database: quelli relazionali e quelli ad oggetti. Dopo alcune considerazioni, siamo giunti alla conclusione che, per realizzare l'applicazione, nessuna delle due tipologie è quella più adatta allo scopo, poiché, sia le caratteristiche dell'una che dell'altra non sono sufficienti per implementare le funzionalità che l'applicazione deve fornire. Abbiamo quindi affermato che la soluzione ideale per costruire l'infrastruttura dell'applicazione è una tipologia di database che di fatto è un mix delle due, ovvero un database di tipo object-relational. Questa tipologia di database può essere considerata come l'ultima evoluzione nel campo dei sistemi per la gestione dei dati, poiché, di fatto, cerca di sfruttare al massimo le potenzialità dei due modelli alla sua base, ed è per ciò che, questa nuova tipologia, per certi versi, può essere considerata una tipologia ibrida. Ogni distinta tipologia di database, infatti, si basa concettualmente su un certo modello dei dati ben definito, mentre gli object-relational risultano essere una combinazione tra il modello relazionale ed il modello ad oggetti. Per comprendere al meglio le potenzialità offerte da questa tipologia di database, è senza dubbio utile conoscere i motivi che hanno portato alla loro nascita, cioè quali siano state le necessità contingenti che hanno determinato l'esigenza di dover creare questo nuovo tipo di database. A tal proposito facciamo quindi un piccolo passo indietro, cerchiamo, infatti, di vedere velocemente come si è svolta l'evoluzione dei sistemi di gestione di basi di dati fino ad oggi Tipologie ed evoluzione dei DBMS. Per prima cosa è necessario introdurre il concetto di modello dei dati, al quale, tra l'altro, abbiamo già fatto riferimento poche righe sopra. 32

2 Un modello dei dati è un insieme di concetti utilizzati per organizzare i dati di interesse e descriverne la struttura in modo che essa risulti comprensibile ad un elaboratore. Il modello dei dati è quindi la base sulla quale implementare le caratteristiche di un qualsiasi DBMS o, più precisamente, possiamo dire che ogni modello dei dati fornisce dei meccanismi di strutturazione che permettono di definire nuovi tipi, attraverso l'utilizzo di tipi elementari predefiniti e costruttori di tipo. Sempre seguendo il filo conduttore che ci lega all'obbiettivo di realizzare un'applicazione che permetta l'archiviazione e la ricerca di dati di tipo strutturato, dovrebbe risultare abbastanza chiaro che, lo scopo di questa trattazione teorica è quello di mettere in evidenza come un particolare modello di dati possa permettere o meno ad un sistema di gestione di basi di dati di gestire dati di tipo semistrutturato e multimediale, cioè non solo tipi elementari. I principali modelli dei dati sono quattro ed ognuno ha una natura ben distinta che permette di caratterizzare in modo univoco ogni DBMS che vi appartiene: Il modello gerarchico, basato sull'uso di strutture ad albero (e quindi gerarchiche, da cui il nome), definito durante la prima fase di sviluppo dei DBMS (anni Sessanta), ma tuttora ampiamente utilizzato. Il modello reticolare (detto anche modello CODASYL, dal comitato di standardizzazione che lo definì con precisione), basato sull'uso di grafi, sviluppato successivamente al modello gerarchico (inizio anni Settanta). Il modello relazionale dei dati, attualmente il più diffuso, permette di definire tipi per mezzo del costruttore relazione, che consente di organizzare i dati in insiemi di record a struttura fissa. Il modello a oggetti, sviluppato negli anni Ottanta come evoluzione del modello relazionale, che estende alle basi di dati il paradigma di programmazione a oggetti. 33

3 Quasi tutti i DBMS in commercio utilizzano uno di questi modelli dei dati, che vengono anche detti modelli logici, poiché, come è stato appena detto, le strutture utilizzate da questi modelli, pur essendo astratte, riflettono una particolare organizzazione: ad alberi, a grafi, a tabelle o a oggetti. Per l'utente finale di un'applicazione, basata sull'utilizzo di un database, non è comunque necessario conoscere il modello dei dati utilizzato per rappresentare e strutturare i medesimi nel database: l'utente finale interagisce con le funzionalità offerte dal DBMS mediante un'applicazione che, generalmente, presenta un'interfaccia, la quale rende completamente nascosto all'utilizzatore ciò che si trova sotto di essa. Per rendere meglio questo concetto è utile analizzare il modello stratificato riportato in figura 2.1: gli utenti non sono interessati a conoscere la rappresentazione logica o il tipo di memorizzazione fisica utilizzata dal DBMS per gestire i dati, ma solo ad utilizzare le funzionalità messe a disposizione dall'applicazione che si interfaccia al database. Se il DBMS riesce a mettere a disposizione le funzionalità necessarie affinché l'applicazione possa assolvere ai compiti per la quale è stata progettata, l'utente finale non ha il minimo interesse a conoscere con quale modalità il DBMS permetta l'esecuzione di certe funzionalità. 34

4 I problemi nascono quando, per nuove esigenze di utilizzo, si vogliono aumentare le funzionalità dell'applicazione e l'infrastruttura sottostante ad essa non lo permette. Ripensiamo all'esempio del commesso nel negozio di moda fatto nell'introduzione: se divenissero frequenti le richieste tipo quella fatta dal cliente nella circostanza descritta, cioè di vedere un'insieme di abiti partendo dall'immagine di un abito campione scelta come riferimento, sarebbe auspicabile che la direzione del negozio si adoperasse per inserire la funzionalità nel catalogo on-line, al fine di migliorare la qualità e l'efficienza dei servizi offerti nei propri negozi. Se però l'applicazione catalogo on-line si interfaccia ad un database basato su un modello dei dati che non permette l'implementazione di una simile funzionalità è un problema. Le soluzioni possibili a questa nuova necessità sono sostanzialmente due, ma, nelle condizioni operative ipotizzate, entrambe presentano comunque delle forti controindicazioni. La prima soluzione prevede di sostituire completamente l'applicazione con una nuova, che sia dotata da subito della funzionalità aggiuntiva richiesta; questo, però, comporta per l'azienda un investimento economico extra non preventivato, nonché dei problemi logistici dovuti alla migrazione dei dati dal vecchio al nuovo catalogo on-line. La seconda consiste nel non rendere disponibile la funzionalità richiesta, poiché l'infrastruttura sulla quale poggia l'applicazione catalogo on-line non ne consente l'aggiunta. Questo inevitabilmente renderà il negozio impreparato a recepire i nuovi scenari di mercato e ciò costituisce sicuramente una limitazione ai servizi offerti dall'azienda, ponendo così un freno al suo sviluppo. Da questa ipotetica situazione si può quindi evincere che l'adozione di applicativi basati su infrastrutture che non consento l'estensione delle proprie funzionalità è una scelta che generalmente ha quasi sempre delle ripercussioni negative. Detto ciò, è giusto sottolineare che i primi due tipi di database, quelli che utilizzano il modello gerarchico o reticolare, benché siano tuttora presenti in svariati applicativi, di fatto ormai concettualmente appartengono alla storia dell'informatica. La maggior parte dei database attualmente utilizzati oggi appartiene alla categoria dei database relazionali, per i quali sono già state accennate le potenzialità in sede di 35

5 introduzione. Anche quest'ultimi però, benché siano molto più versatili e performanti rispetto ai primi due, non offrono la possibilità di estendere le proprie funzionalità per la manipolazione di un qualsiasi nuovo tipo di dato. Cerchiamo quindi di capire fino a che punto può essere sufficiente l'utilizzo di un database relazionale e quando diventa invece necessario ricorrere ad un'altra tipologia. Con l'avvento del modello relazionale e dei sistemi di basi di dati fondati su tale modello, fu fatto un passo molto importante per l'evoluzione di questi sistemi, in particolare, il modello relazionale permise di superare una limitazione comune sia al modello gerarchico, sia al modello reticolare: entrambi non permettevano di realizzare efficacemente la proprietà di indipendenza dei dati, proprietà di fondamentale importanza per realizzare applicazioni facilmente portabili e dotate di funzionalità strutturalmente sempre più complesse. Il modello relazionale, in virtù di questa caratteristica, è anche detto modello basato su valori. Questo significa che i riferimenti fra i dati in relazioni diverse sono rappresentati per mezzo di valori dei domini che compaiono nelle tabelle che caratterizzano le relazioni stesse. Differentemente, nel modello gerarchico e reticolare, le corrispondenze fra i dati sono invece realizzate mediante riferimenti espliciti fatti attraverso dei puntatori presenti nei record che caratterizzano i dati contenuti nel database. Possiamo quindi riassumere dicendo che i database relazionali (RDBMS) hanno permesso la realizzazione efficace ed efficiente di applicazioni di tipo gestionale, caratterizzate principalmente da requisiti importanti quali la persistenza, la condivisione e l'affidabilità dei dati. Altre caratteristiche di rilievo per questo tipo di database sono sicuramente rappresentate dalla possibilità di implementare interrogazioni complesse, espresse mediante linguaggi dichiarativi come il SQL, e dalla possibilità di effettuare delle transazioni concorrenti sulla stessa base di dati. La necessità di un'ulteriore evoluzione, come abbiamo avuto modo di apprendere, nasce dal fatto che i RDBMS possono manipolare solo dati a struttura semplice, di tipo numerico/simbolico, e la rapida evoluzione tecnologica ha fatto emergere nuove esigenze applicative, per le quali la tecnologia relazionale è inadeguata, poiché, come è già stato detto a più riprese, la forte connotazione multimediale che 36

6 molte applicazioni stanno assumendo richiede a gran voce la possibilità di gestire dati di tipo strutturato. Questo scenario ha così suggerito l'introduzione nel mondo delle basi di dati di nozioni provenienti dal paradigma della programmazione orientata agli oggetti: da questa operazione sono nati i sistemi di gestione di basi di dati fondati sull'utilizzo del modello dei dati ad oggetti. La prima generazione di ODBMS (Object Data Base Management System) è composta dai linguaggi di programmazione a oggetti persistenti, che realizzano solo alcune caratteristiche delle basi di dati, senza supporto per l interrogazione, in modo quindi assai incompatibile con gli RDBMS. Gli ODBMS della seconda generazione realizzano invece un maggior numero di caratteristiche proprie delle basi di dati, e generalmente forniscono un supporto all interrogazione. Possiamo quindi schematizzare i database fondati sul modello ad oggetti come divisi in due tecnologie di ODBMS: gli OODBMS (Object-Oriented), una tecnologia rivoluzionaria rispetto a quella degli RDBMS, e gli ORDBMS (Object-Relational), una tecnologia di evoluzione rispetto a quella degli RDBMS. Considerando quanto detto fino ad ora, possiamo fare un'ulteriore passo in avanti affermando che una base di dati a oggetti è a tutti gli effetti una collezione di oggetti, dove ciascun oggetto ha un identificatore, uno stato, e un comportamento. L identificatore OID (Object Identifier) garantisce l individuazione in modo univoco dell oggetto, e permette di realizzare dei riferimenti tra gli oggetti stessi. Lo stato è l insieme dei valori assunti dalle proprietà dell oggetto ed è in generale un valore a struttura complessa. Il comportamento, infine, è descritto dall insieme dei metodi che possono essere applicati all oggetto. In questo contesto esula dai nostri interessi entrare ad analizzare in profondità con quali modalità opera un ODBMS, ma è senza dubbio importante evidenziare la caratteristica di questi sistemi di gestione dei dati per noi più importante: la possibilità di estendere i tipi di dati e di definire delle funzioni che operano su questi tipi. L'approccio object-oriented consente infatti l uso di tipi e valori complessi e permette di associare ad un singolo oggetto una struttura qualunque. Viceversa, nel modello relazionale, alcuni concetti devono essere rappresentati obbligatoriamente 37

7 tramite più relazioni. Il modello relazionale puro richiederebbe inesorabilmente l'utilizzo di più relazioni per la rappresentazione di un dato strutturato e questa è una chiara limitazione del modello quando la base di dati è chiamata a manipolare molti dati strutturati. Nei modelli ad oggetti invece la situazione è facilmente gestibile, poiché un oggetto è una coppia (OID,Valore), dove l'oid è un valore atomico definito dal sistema e trasparente all utente, mentre con Valore si può indicare un qualsiasi dato strutturato. Il valore assunto da una proprietà di un oggetto può essere quindi l OID di un altro oggetto, realizzando così un riferimento anche tra oggetti, che possono anche derivare da istanze di classi diverse, al pari di ciò che avviene nel modello relazionale, quando si collegano tuple istanziate da tabelle che rappresentano relazioni diverse. Tutto questo non deve far pensare che il modello ad oggetti abbia soppiantato il modello relazionale, poiché il modello relazionale, come abbiamo avuto modo di evidenziare, resta sempre quello più utilizzato, poiché le sue caratteristiche offrono tutt'oggi ampie garanzie di successo nella progettazione e nella realizzazione dei database. In particolare, la realizzazione di sistemi gestionali e contabili prevede quasi sempre l'utilizzo di un database relazionale ed in alcuni casi addirittura si riscontra tutt'oggi in tali settori la presenza di database gerarchici e reticolari. Questo è un chiaro indice del fatto che esistono ancora dei campi di applicazione che non necessitano di manipolare nuovi tipi di dati e, in mancanza di questa necessità, non emerge mai la volontà di un'ente o di un'azienda di sostituire il proprio sistema. Per quanto riguarda il modello ad oggetti lo possiamo invece considerare come un qualcosa in grado di sopperire alle mancanze del modello relazionale, mancanze che si manifestano in situazioni tipo quella nella quale ci troviamo adesso: gestire ed utilizzare dati di tipo strutturato. Nel complesso quindi possiamo individuare nella tecnologia ORDBMS quella più adatta ai nostri scopi. Come abbiamo già detto, un database di tipo ORDBMS mantiene tutta la potenza del modello relazionale e permette l'introduzione e la manipolazione di nuovi tipi di dati, caratteristica che rappresenta sicuramente un punto di forza del modello ad oggetti. 38

8 Non resta quindi che identificare un sistema di gestione di basi di dati appartenente alla categoria degli ORDBMS al quale poter interfacciare l'applicazione web. A tale riguardo la scelta è caduta su PostgreSQL: un ORDBMS open source di classe enterprise PostgreSQL, un ORDBMS open source di classe enterprise La storia di PostgreSQL, che si pronuncia postgre-es-chiu-el (SQL = "es chiu el"), parte nel lontano 1970 presso l'università della California, a Berkeley, dove iniziò lo sviluppo di un database relazionale chiamato Ingres. Alcuni anni dopo Ingres fu trasformato in un prodotto commerciale dalla società Relational Technologies, società che in seguito cambiò nome in Ingres Corporation, per poi essere successivamente acquisita dalla Computer Associates. Nel 1986, il capo progetto di Ingres, Michael Stonebraker, che alcuni anni prima aveva lasciato il team di sviluppo di Berkeley per seguire la commercializzazione del prodotto, decise di ritornare all'accademia per dare vita ad un nuovo progetto post-ingres. Il nuovo progetto aveva l'obbiettivo dichiarato di creare un prodotto che superasse gli evidenti limiti dei prodotti concorrenti dell'epoca. In particolare, puntava a fornire un supporto completo ai tipi di dati e la possibilità di definire nuovi tipi di dati (UDF, User Defined Types). Tutto ciò può essere riassunto dicendo che il team di sviluppo del nuovo progetto non fece altro che aggiungere delle caratteristiche object-oriented ad Ingres. Il nuovo progetto prese il nome di Postgres. Da segnalare che la base dei sorgenti di Ingres e di Postgres erano, e sono rimasti tutt'ora, ben distinti. Come il suo predecessore anche Postgres fu ben presto commercializzato, questa volta per opera di una compagnia chiamata Illustra Information Technologies (poi parte della Informix Corporation), costituita da Paula Hawthorn, membro originale del team di Ingres, e dal sempre presente Michael Stonebraker. A differenza del suo antenato, Postgres non fu sviluppato commercialmente con la stessa rapidità di Ingres, infatti, dal 1988, anno in cui venne rilasciato il primo prototipo funzionante, 39

9 al 1993, furono sviluppate solo quattro versioni di Postgres, per poi giungere anche in questo caso alla terminazione del progetto. Sebbene il progetto Postgres fosse ufficialmente abbandonato, la licenza BSD (Berkeley Software Distribution) dava comunque modo agli sviluppatori Open Source di ottenere una copia del software per poi migliorarlo a loro discrezione. Nel 1994 due studenti del Berkeley, Andrew Yu e Jolly Chen, aggiunsero a Postgres un interprete SQL, per rimpiazzare il vecchio linguaggio di interrogazione, QUEL, che risaliva ai tempi di Ingres. Il nuovo software venne quindi rilasciato sul web con il nome di Postgres95. Nel 1996 cambiò nome di nuovo: per evidenziare il supporto al linguaggio SQL, venne chiamato PostgreSQL. Il primo rilascio di PostgreSQL è stata la versione 6. Da allora ad occuparsi del progetto è una comunità di sviluppatori volontari provenienti da tutto il mondo che si coordina attraverso Internet. Alla versione 6 ne sono seguite altre, ognuna delle quali ha portato nuovi miglioramenti. Nel gennaio 2005 è stata rilasciata la versione 8. In questo lavoro di tesi verrà utilizzata la versione di PostgreSQL. Nel momento in cui sto scrivendo l'ultima versione rilasciata dal team di sviluppo è la PostgreSQL ha sicuramente beneficiato della sua lunga storia: è assolutamente realistico affermare che oggi PostgreSQL è uno dei più avanzati database server presenti in circolazione. Riassumiamo di seguito alcune delle principali caratteristiche che si possono trovare in una distribuzione standard di PostgreSQL: Object-Relational: in PostgreSQL ogni tabella definisce una classe. PostgreSQL implementa l'ereditarietà fra tabelle, o fra classi se si preferisce. Funzioni e operatori sono polimorfici. Conformità agli standards: la sintassi utilizzata da PostgreSQL adotta la maggior parte dello standard SQL92 e molte caratteristiche presenti in SQL99. Alcune differenze di sintassi che possono essere trovate in PostgreSQL rappresentano delle caratteristiche uniche dello stesso PostgreSQL. 40

10 Open Source: un team internazionale di sviluppatori si occupa di mantenere PostgreSQL. I membri del team vengono e vanno, ma i membri stabili hanno contribuito ad accrescere le potenzialità e le performance di PostgreSQL sino dal Un vantaggio della natura open source di PostgreSQL è che il talento e le conoscenze possono essere reclutati quando necessario. Il fatto che il team di sviluppo sia internazionale assicura che PostgreSQL è un prodotto che può essere utilizzato produttivamente in ogni linguaggio, non solo in inglese. Transaction Model: PostgreSQL protegge i dati e coordina gli accessi concorrenti multiutente attraverso le transazioni. Il Transaction Model utilizzato da PostgreSQL si basa sul modello MVCC (Multi-Version Concurrency Control). Tale modello provvede ad una migliore performance rispetto a quella riscontrabile in altri prodotti che coordinano la multiutenza attraverso i sistemi di bloccaggio a livello di tabella, di pagina o di riga. Integrità referenziale: PostgreSQL implementa completamente l'integrità referenziale supportando le relazioni tra chiavi esterne e primarie così come i triggers. Le Business Rules posso essere espresse all'interno del database piuttosto che contare su degli appositi strumenti esterni. Linguaggi procedurali multipli: triggers e altre procedure possono essere scritte in uno dei diversi linguaggi procedurali. Il codice lato server solitamente è scritto in PL/pgSQL, un linguaggio procedurale simile a Oracle PL/SQL. Il codice server-side può essere comunque sviluppato anche in Tcl, Perl e perfino in Bash, la shell open source Linux/Unix. Supporto multiplo per APIs lato client: PostgreSQL supporta lo sviluppo di applicazioni lato client in molti linguaggi. Ad esempio PostgreSQL può essere interfacciato da C, C++, Perl, PHP, Tcl/Tk e Python. 41

11 Tipi di dati unici: PostgreSQL fornisce una vasta varietà di tipi di dati. Oltre agli usuali tipi numerici, stringa e data è possibile trovare tipi geometrici, tipi booleani e tipi di dati progettati specificatamente per occuparsi di indirizzi di rete. Estensibilità: una delle più importanti caratteristiche di PostgreSQL è che può essere esteso. Se non può essere reperito un qualcosa del quale si ha bisogno è possibile aggiungerlo. Per esempio è possibile aggiungere nuovi tipi di dati, nuove funzioni, nuovi operatori ed anche nuove procedure e linguaggi lato client. In riguardo ci sono molti pacchetti disponibili su Internet. Per esempio, Refractions Research Inc. ha sviluppato un insieme di tipi di dati geografici (GIS). Da questo primo elenco di caratteristiche, dovrebbe essere immediato capire che non stiamo parlando di un prodotto simile agli altri database. Per quanto è stato possibile appurare fino ad ora è evidente che le enormi potenzialità di PostgreSQL derivano dal fatto che questo DBMS riesce a sfruttare in modo estremamente efficace ed efficiente la sua natura object-relational. Non è infatti operazione sempre semplice rendere compatibile il mondo SQL con quello della programmazione ad oggetti. I database basati solo ed esclusivamente sul modello relazionale richiedono che sia l'utente a prelevare e raggruppare le informazioni correlate utilizzando le query SQL. Questo contrasta con il modo in cui, sia le applicazioni, che gli utenti, utilizzano i dati, come ad esempio avviene in un linguaggio di alto livello con tipi di dati complessi, dove tutti i dati correlati operano come elementi completi, normalmente definiti da oggetti o record (in base al linguaggio). Per creare un sistema che operi nelle modalità più vicine possibili a quello che può essere definito il naturale utilizzo dei dati non è però sufficiente creare un'infrastruttura basata sul semplice mix di SQL e di programmazione ad oggetti. Convertire le informazioni, dal mondo SQL a quello della programmazione orientata agli oggetti, 42

12 presenta infatti delle difficoltà dovute principalmente al fatto che i due mondi utilizzano modelli di organizzazione dei dati molto differenti. L'industria chiama questo problema impedance mismatch (discrepanza di impedenza): mappare i dati da un modello all'altro può assorbire fino al 40% del tempo di sviluppo di un progetto. Un certo numero di soluzioni di mappatura, normalmente dette objectrelational mapping, possono risolvere il problema, ma tendono ad essere costose e ad avere delle controindicazioni: causando, ad esempio, scarse prestazioni oppure forzando tutti gli accessi ai dati ad aver luogo attraverso il solo linguaggio che supporta la mappatura stessa. PostgreSQL può invece risolvere molti di questi problemi direttamente nel database. Esso permette agli utenti di definire nuovi tipi basati sui normali tipi di dato SQL, permettendo così al database stesso di comprendere dati complessi. Per esempio, si può definire un indirizzo come un insieme di diverse stringhe di testo per rappresentare il numero civico, la città, ecc. Da qui in poi si possono creare facilmente tabelle che contengono tutti i campi necessari a memorizzare un indirizzo con una sola linea di codice. PostgreSQL, inoltre, permette l'ereditarietà dei tipi, uno dei principali concetti della programmazione orientata agli oggetti. Ad esempio, si può definire un tipo codice_postale, quindi creare un tipo cap (codice di avviamento postale) o un tipo us_zip_code (cap utilizzato in USA), basati su di esso. Gli indirizzi nel database potrebbero quindi accettare entrambi i tipi, e regole specifiche potrebbero validare i dati in entrambi i casi. Nelle prime versioni di PostgreSQL, implementare nuovi tipi richiedeva la scrittura di estensioni in C e la loro compilazione nel server dove era allocato il database. Dalla versione 7.4 è diventato molto più semplice creare ed usare tipi personalizzati attraverso il comando "CREATE DOMAIN". Abbiamo anche menzionato, fra le caratteristiche di PostgreSQL, la possibilità di rendere disponibili nel server nuove funzioni e nuovi operatori. La maggior parte dei sistemi RDBMS permette agli utenti di scrivere una procedura, ovvero un blocco di codice SQL che le altre istruzioni SQL possono richiamare. Comunque il SQL stesso rimane inadatto come linguaggio di programmazione, pertanto gli utenti 43

13 possono sperimentare grandi difficoltà nel costruire logiche complesse. Ancora peggio, il SQL stesso non supporta molti dei principali operatori di base dei linguaggi di programmazione, come le strutture di controllo di ciclo e condizionale. Pertanto, ogni venditore per aggiungere queste caratteristiche ha scritto le sue estensioni al linguaggio SQL, ed inoltre, queste estensioni, non sono quasi mai costruite per operare su piattaforme diverse di database. In PostgresSQL questo problema non sussiste, poiché i programmatori possono implementare la logica in uno dei molti linguaggi supportati. Il programmatore può inserire il codice sul server come funzioni, che rendono il codice riutilizzabile come stored procedure; così facendo, il codice SQL può richiamare funzioni scritte in altri linguaggi (come il C o il Perl). Non meno importante è la presenza di un linguaggio nativo chiamato PL/pgSQL, simile al linguaggio procedurale di Oracle PL/SQL, che offre particolari vantaggi nelle procedure che fanno un intensivo uso di query. Questo linguaggio sarà tra l'altro il linguaggio in cui verrà implementata la funzione di confronto tra gli istogrammi delle immagini. Queste caratteristiche fanno di PostgreSQL, probabilmente, il più avanzato sistema di gestione dei dati dal punto di vista della programmabilità. Utilizzare PostgreSQL può ridurre fortemente il tempo totale di programmazione di molti progetti, con i vantaggi suddetti che crescono con la complessità del progetto stesso. A questo punto non ci resta che iniziare ad utilizzare PostgreSQL e le sue potenzialità per creare un database che possa supportare le caratteristiche dell'applicazione web che deve essere realizzata. Nel prossimo paragrafo quindi ci dedicheremo ad analizzare gli aspetti di PostgreSQL utili alla definizione del database La strutturazione del database Da questo momento iniziamo ad affrontare in maniera dettagliata le scelte da intraprendere per strutturare il database, che dovrà essere progettato in modo tale da poter supportare le funzionalità richieste dall'applicazione web che deve essere 44

14 realizzata La memorizzazione delle immagini La prima situazione da analizzare riguarda la memorizzazione delle immagini. Risulta evidente, per quanto fino ad ora appurato, che l'applicazione web in questione deve essere in grado di fare sostanzialmente due cose: archiviare in modo permanente delle immagini e permettere di effettuare delle ricerche tra le immagini memorizzate mediante confronti. Abbiamo anche appreso, nel precedente capitolo, che di fatto, l'oggetto di tali confronti non sarà il codice sorgente dell'immagine, ma bensì il suo istogramma di colore, una struttura che permette la rappresentazione del contenuto cromatico di un'immagine. Se può essere lecito pensare, alla luce di quanto è stato fatto intendere fino a questo momento, che le immagini dovranno essere memorizzate nel database, è altrettanto legittimo effettuare un'attenta analisi sui risvolti che questa scelta potrebbe implicare e se questa sia effettivamente la scelta che rende l'applicazione più performante. Ciò non significa sconfessare quanto è stato fin qui sostenuto, ma effettuare un'analisi sulle possibili modalità con le quali procedere alla memorizzazione delle immagini è un atto doveroso, soprattutto se vengono prese in dovuta considerazione delle situazioni oggettive direttamente connesse alla natura ed allo sviluppo dell'applicazione web, cosa che intendiamo fare nell'immediato proseguo di questo paragrafo. Poiché questa considerazione potrebbe minare quella che fino ad ora poteva essere considerata una certezza, ovvero il fatto di archiviare le immagini tramite l'utilizzo del database per la memorizzazione del loro codice sorgente, cerchiamo di spiegare meglio in base a quali parametri viene rimesso in discussione questo fatto. Abbiamo detto nell'introduzione che i sistemi per la gestione dei dati offrono già, mediante l'utilizzo di campi di tipo BLOB e CLOB, la possibilità di memorizzare dati di tipo strutturato, come le immagini. Abbiamo inoltre messo in evidenza, proprio alla luce di ciò, che lo scopo primario di questa tesi di ricerca non deve essere individuato nella memorizzazione delle immagini in un database, bensì 45

15 nell'offrire la possibilità di confrontare queste immagini tramite un opportuno predicato da inserire in una dichiarazione SQL, dove, di fatto, si fa esplicitamente riferimento ad una struttura che qualifica un aspetto del contenuto delle immagini. In questo caso, come abbiamo avuto già modo di dire, faremo uso a tal fine dell'istogramma (o descrittore) di un'immagine. In conclusione, quindi, analizzare quelle che possono essere le varie strade percorribili per memorizzare in modo permanente le immagini, non deve essere considerato come una marcia indietro, anche se in tale analisi verranno contemplate soluzioni che non prevedono l'utilizzo attivo del database. Questo processo deve essere visto invece come un'azione ovvia, volta ad individuare la soluzione più performante per la creazione ed il funzionamento dell'applicazione. Da ora in avanti, nel proseguo della trattazione, daremo sempre per appurato che il cuore della ricerca di questo lavoro di tesi è localizzato nella memorizzazione nel database di una struttura ausiliaria che rappresenti il contenuto cromatico di un immagine, struttura che di fatto è a tutti gli effetti un dato di tipo strutturato e che verrà sempre utilizzata in ogni richiesta di confronto tra immagini. Compreso questo scenario, non deve essere quindi vista come una negazione di quanto argomentato fino ad ora, il fatto di analizzare la possibilità di memorizzare le immagini senza l'utilizzo attivo del database, se questa scelta dovesse poi rendere l'applicazione più performante. Prima di analizzare in dettaglio pro e contro delle singole soluzioni di memorizzazione delle immagini, è necessario puntualizzare due aspetti riguardo alle caratteristiche dell'applicazione, aspetti da tenere ben presenti, poiché abbiamo appena evidenziato che questi saranno influenti ai fini della scelta del sistema di memorizzazione da adottare. Il primo aspetto riguarda la mappatura delle immagini: è stato appurato, per motivi già noti, che ogni singola immagine inserita nel sistema deve essere mappata; questo comporta che per ogni immagine inserita nel sistema saranno fisicamente presenti due file, o comunque, due sorgenti binari distinti, ai quali ricondurre l'immagine originale e quella mappata. Il secondo aspetto riguarda invece le caratteristiche dell'interfaccia dell'applicazione: è previsto che l'applicazione consenta di raggruppare le immagini inserite in gallerie e che ad ogni 46

16 galleria si possa accedere per prendere visione delle singole immagini che essa contiene. Per motivi di layout è prassi comune delle applicazioni web presentare l'insieme delle immagini presenti in ogni galleria sotto forma di preview, realizzato mediante la creazione di un thumbnail per ogni immagine di dimensioni fissate. Inoltre è altresì previsto che l'applicazione fornisca all'utente la possibilità di visionare sia il thumbnail dell'immagine originale che quello dell'immagine mappata. Tutto ciò significa che per ogni immagine inserita nel sistema dovranno essere presenti non due, ma ben quattro sorgenti binari distinti: quello dell'immagine originale, quello dell'immagine mappata, quello del thumbnail dell'immagine originale e quello dell'immagine mappata. Infine è importante sottolineare che, affinché l'applicazione web possa visualizzare le immagini, originali o mappate, full size o thumbnail che siano, è sempre necessaria la presenza sul disco dei file che rappresentano l'immagini, ai quali deve sempre essere possibile far riferimento specificando il loro path fisico nell'attributo src del tag <img />. Fatte queste doverose considerazioni, possiamo passare all'analisi delle possibilità di memorizzazione, tenendo ben presente quanto appena detto, poiché, ripeto di nuovo, ciò influisce direttamente sulla scelta della modalità di memorizzazione che verrà fatta. Dall'analisi effettuata, esistono tre distinte possibilità per memorizzare in modo permanente un'immagine e renderla disponibile ad un'applicazione di tipo web: 1. Memorizzazione dell'immagine nel database in un campo di tipo BLOB. 2. Memorizzazione dell'immagine nel database utilizzando un campo di tipo OID. 3. Memorizzazione dell'immagine nel disco mediante l'utilizzo del filesystem, specificando un riferimento ad essa nel database tramite un campo testo. La prima soluzione prevede la definizione di un campo di tipo BLOB da utilizzare per memorizzare l'immagine. PostgreSQL offre a tale scopo il tipo BYTEA. Per 47

17 PostgreSQL un campo di tipo BYTEA è deputato alla memorizzazione di raw data. Con questa terminologia s'intendono classificare dei dati la cui struttura ed il cui significato non è compreso dal database. PostgreSQL, infatti, per gli altri tipi di dati, quali ad esempio INTEGER o CHARACTER, sa che i byte posti in una colonna dichiarata di tipo INTEGER sono supposti rappresentare un valore intero, sul quale effettuare tutte le operazioni del caso quando si manipola un intero. Diversamente, per un campo BYTEA, PostgreSQL non inferisce alcun significato ai dati: li considera solo come una collezione di bit senza preoccuparsi di cosa essi realmente rappresentino! Analizzando quindi questa possibilità sorge un primo problema dovuto alle modalità con cui PostgreSQL richiede l'inserimento dei dati in un campo di tipo BYTEA: la sintassi prevede un inserimento identico a quello utilizzato per la memorizzazione delle stringhe, ovvero la delimitazione dell'insieme di caratteri fra singoli apici. Il fatto poi che questi caratteri siano dei bit che rappresentano il contenuto di un documento di testo o di un immagine non è di interesse per il DBMS, ma se ne dovrà preoccupare l'applicazione che poi li utilizzerà! Questo significa che per memorizzare un immagine in un campo di questo tipo è assolutamente necessaria un'applicazione esterna che si preoccupi di estrarre dall'immagine il suo codice sorgente. Pur sapendo che questa operazione è comunque necessaria per ricavare l'istogramma dell'immagine, nel contesto dell'applicazione web, non è sicuramente la situazione più performante quella in cui non è immediatamente disponibile sotto forma di file il codice dell'immagine. Abbiamo messo in risalto, infatti, che per essere visualizzate da un browser le immagini devono essere fisicamente presenti sul disco. Inoltre è stato anche illustrato che per ogni immagine inserita, di fatto, l'applicazione deve gestire quattro immagini distinte, che devono essere sempre riconducibili ad altrettanti file distinti. Tutto ciò implica che l'eventuale scelta di memorizzare le immagini in un campo BYTEA comporta, in realtà, l'utilizzo di quattro campi distinti di questo tipo, uno per ogni immagine. A questo punto è immediato il prendere atto del fatto che l'applicazione sarebbe estremamente poco performante se, ad ogni richiesta di visualizzazione di un'immagine, dovesse essere costretta a richiedere l'intervento di 48

18 uno strumento esterno al database che, per prima cosa, deve interpretare i dati presenti nei campi BYTEA e, successivamente, andare a creare i file temporanei sul disco ai quali fare riferimento per la visualizzazione delle immagini nel browser. Come avremo modo di comprendere quando parleremo delle GD2, le librerie grafiche di PHP utilizzate per manipolare le immagini, ciò significherebbe che per visualizzare una galleria costituita, ad esempio, da 20 immagini, sarebbe necessaria la creazione di 80 immagini resource residenti in memoria principale, dalle quali creare in seguito 80 file temporanei sul disco. Inutile sottolineare che, implementare la visualizzazione tramite un'infrastruttura di questo tipo, genera un sovraccarico alla funzionalità dell'applicazione che non ha nessun vantaggio. In definitiva, quindi, questa soluzione non sembra essere quella più adatta, o meglio, il fatto di dover avere necessariamente, ai fini della visualizzazione, il codice dell'immagine in un file fisicamente residente sul disco fisso rende questa soluzione poco performante allo scopo. La seconda soluzione è quella che prevede l'utilizzo di un campo di tipo OID (Object Identifier). PostgreSQL è un ORDBMS, ed abbiamo già discusso del fatto che per ciò è assolutamente lecito vedere una relazione (tabella) come una classe, ed ogni riga (tupla) della tabella come l'istanza di tale tabella e quindi anche della classe; di conseguenza una riga può essere considerata di fatto un oggetto. In ragione di tutto questo ogni tabella prevedeva, fino alla versione 8.0 di PostgreSQL, un campo nascosto di tipo OID, nel quale era mantenuto un identificativo univoco di tale riga (oggetto); tale identificativo era univoco per tutto il database ed in futuro il team di sviluppo aveva previsto di renderlo unico per ogni singola tabella. Attualmente, invece, c'è stata un'inversione di tendenza, poiché l'attributo OID non viene più inserito di default nelle tabelle, ma solo se esplicitamente richiesto. Detto questo vediamo come tutto ciò potrebbe essere utilizzato per memorizzare un'immagine. PostgreSQL supporta l'utilizzo dei così detti large_objects. Un large_object è una collezione di bit che può superare la dimensione massima stabilita per un campo BYTEA, pari ad 1GB. Oltre a questo fatto, la principale differenza da 49

19 quest'ultimo tipo risiede nel fatto che un large_object non viene memorizzato nel campo OID della tabella di competenza. Un large_object viene fisicamente memorizzato in una tabella di sistema chiamata pg_largeobject. Nella tabella di competenza viene quindi memorizzato l'oid assegnato alla riga della tabella pg_largeobject che effettivamente contiene il codice del large_object. PostgreSQL offre le funzioni lo_import('file_path'), lo_export(oid,'file_path') e lo_unlink(oid) che rispettivamente importano, esportano e cancellano un large_object dalla tabella interessata e quindi dal database stesso. Ovviamente, come spero possa essere già stato intuito, un large_object può essere un'immagine. Questa soluzione, se analizzata con attenzione, seppur in forma diversa, presenta i soliti problemi di quella precedente. L'unica differenza è dovuta al fatto che per rendere disponibili i file delle immagini sul disco, invece che richiedere l'intervento delle librerie GD2, verrebbero utilizzate le funzioni citate poche righe sopra atte alla manipolazione dei large_object. Inoltre, le soluzioni che prevedono un riferimento tramite OID, soffrono comunque di due problemi contingenti: uno relativo al backup e l'altro quando si tenta di utilizzare l'oid per identificare una riga al fine di una ricerca (SELECT). Nel primo caso il problema è dovuto al fatto che quando si effettua un restore dal backup di un database, il sistema è solito non riassegnare alle righe gli stessi OID (specificando sempre in fase di dump che debbano essere generati) e risulta quindi necessario, per mantenere la consistenza dei dati, prendere degli accorgimenti che non sono contemplati di default dalla funzione pg_dump di PostgreSQL. Nel secondo, invece, si deve considerare che un campo OID occupa 32 bit, ragion per cui solo nel caso in cui la PRIMARY KEY della relazione è veramente molto lunga può aver senso, in termini di prestazioni, effettuare delle ricerche utilizzando per riferimento l'oid delle righe. Tutto ciò, unito alla constatazione che in un certo senso gli OID sono stati deprecati dal team di sviluppo di PostgreSQL, invita a prendere atto del fatto che anche questa soluzione non è adatta allo sviluppo di un'applicazione di natura web. L'ultima soluzione è quella che prevede l'intervento del filesystem per memorizzare un'immagine. In pratica nella tabella preposta alla memorizzazione delle immagini 50

20 non viene memorizzato il suo codice sorgente, ma i riferimenti necessari ad individuarla sul disco, come il suo nome ed il suo path. Chi si occupa di memorizzare fisicamente l'immagine sul disco del server (non nel database), è il filesystem. Questo può essere effettuato mediante una chiamata ad una routine presente sul server, scritta ad esempio in PHP, oppure in C o in qualsiasi altro linguaggio che consenta questa operazione. Lo scenario che si prospetta è quindi il seguente: il sistema riceve una richiesta di upload di un'immagine e tramite il filesystem provvede alla sua memorizzazione nel disco fisso. In realtà, come già sappiamo, per ogni upload, le immagini memorizzate saranno quattro e non una sola. Conseguenza diretta di questo fatto è che la tabella preposta alla memorizzazione delle immagini dovrà essere strutturata in modo tale da mantenere i riferimenti ad ognuna di queste quattro immagini. Adottando questa soluzione vengono quindi eliminati i problemi di sovraccarico che sorgerebbero, per i motivi già esposti, in fase di visualizzazione di una galleria, qualora le immagini fossero memorizzate utilizzando una delle altre due soluzioni La memorizzazione dell'istogramma di colore. A questo punto, anche se sono state date in precedenza delle ampie spiegazioni in riguardo, potrebbe comunque sorgere una domanda spontanea: quale è il valore aggiunto, del quale risulta privo un normale Relational Data Base Management System, presente invece in PostgreSQL che consente di realizzare l'infrastruttura fino ad ora descritta? La risposta è nessuno, ma se questa trattazione è stata letta con attenzione, mi auguro che ciò non sia motivo di stupore! Sarebbe stato motivo di stupore se avessimo ipotizzato di sviluppare il criterio di confronto tra le immagini andando a confrontare i codici sorgenti delle stesse; in tal caso, a questo punto, sarebbe stato più che lecito pensare che qualcosa non funziona come dovrebbe, poichè non avrebbe avuto alcun senso utilizzare come oggetto del confronto i codici sorgenti delle immagini e strutturare il database in un modo tale da non avere i 51