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

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "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

Progettaz. e sviluppo Data Base

Progettaz. e sviluppo Data Base Progettaz. e sviluppo Data Base! Introduzione ai Database! Tipologie di DB (gerarchici, reticolari, relazionali, oodb) Introduzione ai database Cos è un Database Cos e un Data Base Management System (DBMS)

Dettagli

Approfondimento: i sistemi di gestione delle basi di dati (DBMS)

Approfondimento: i sistemi di gestione delle basi di dati (DBMS) Approfondimento: i sistemi di gestione delle basi di dati (DBMS) Prerequisito essenziale della funzionalità delle basi di dati è il controllo e la fruibilità dell informazione in esse contenuta: a tale

Dettagli

INFORMATICA. Applicazioni WEB a tre livelli con approfondimento della loro manutenzione e memorizzazione dati e del DATABASE.

INFORMATICA. Applicazioni WEB a tre livelli con approfondimento della loro manutenzione e memorizzazione dati e del DATABASE. INFORMATICA Applicazioni WEB a tre livelli con approfondimento della loro manutenzione e memorizzazione dati e del DATABASE. APPLICAZIONI WEB L architettura di riferimento è quella ampiamente diffusa ed

Dettagli

INTRODUZIONE. Data Base Management Systems evoluzione tecniche gestione dati

INTRODUZIONE. Data Base Management Systems evoluzione tecniche gestione dati INTRODUZIONE Accesso ai dati tramite DBMS Livelli di astrazione Modello dei dati: schema / istanza / metadati Alcuni modelli dei dati Linguaggi per DBMS Architettura di base di un DBMS cesarini - BDSI

Dettagli

L ARCHIVIAZIONE E LA GESTIONE DATI ATTRAVERSO L INTERAZIONE TRA MICROSOFT ACCESS ED EXCEL 1 INTRODUZIONE

L ARCHIVIAZIONE E LA GESTIONE DATI ATTRAVERSO L INTERAZIONE TRA MICROSOFT ACCESS ED EXCEL 1 INTRODUZIONE Roccatello Ing. Eduard L ARCHIVIAZIONE E LA GESTIONE DATI ATTRAVERSO L INTERAZIONE TRA MICROSOFT ACCESS ED EXCEL 1 INTRODUZIONE Agenda Presentazione docente Definizione calendario Questionario pre corso

Dettagli

Informatica B. Contenuti. Introduzione alle Basi di Dati e ai DBMS. Introduzione a dati e basi dati DBMS Modello dei dati

Informatica B. Contenuti. Introduzione alle Basi di Dati e ai DBMS. Introduzione a dati e basi dati DBMS Modello dei dati Informatica B Introduzione alle Basi di Dati e ai DBMS Contenuti Introduzione a dati e basi dati DBMS Modello dei dati Informazioni e dati Dato: elemento semanticamente significativo (data, codice, ecc.),

Dettagli

Sistemi avanzati di gestione dei Sistemi Informativi

Sistemi avanzati di gestione dei Sistemi Informativi Esperti nella gestione dei sistemi informativi e tecnologie informatiche Sistemi avanzati di gestione dei Sistemi Informativi Docente: Email: Sito: Eduard Roccatello eduard@roccatello.it http://www.roccatello.it/teaching/gsi/

Dettagli

Organizzazione degli archivi

Organizzazione degli archivi COSA E UN DATA-BASE (DB)? è l insieme di dati relativo ad un sistema informativo COSA CARATTERIZZA UN DB? la struttura dei dati le relazioni fra i dati I REQUISITI DI UN DB SONO: la ridondanza minima i

Dettagli

Concetti fondamentali dei database database Cos'è un database Principali database

Concetti fondamentali dei database database Cos'è un database Principali database Concetti fondamentali dei database Nella vita di tutti i giorni si ha la necessità di gestire e manipolare dati. Le operazioni possono essere molteplici: ricerca, aggregazione con altri e riorganizzazione

Dettagli

Corso di Informatica Generale 1 IN1. Linguaggio SQL

Corso di Informatica Generale 1 IN1. Linguaggio SQL Università Roma Tre Facoltà di Scienze M.F.N. di Laurea in Matematica di Informatica Generale 1 Linguaggio SQL Marco (liverani@mat.uniroma3.it) Sommario Prima parte: le basi dati relazionali Basi di dati:

Dettagli

Uso delle basi di dati DBMS. Cos è un database. DataBase. Esempi di database

Uso delle basi di dati DBMS. Cos è un database. DataBase. Esempi di database Uso delle basi di dati Uso delle Basi di Dati Il modulo richiede che il candidato comprenda il concetto di base dati (database) e dimostri di possedere competenza nel suo utilizzo. Cosa è un database,

Dettagli

Al giorno d oggi, i sistemi per la gestione di database

Al giorno d oggi, i sistemi per la gestione di database Introduzione Al giorno d oggi, i sistemi per la gestione di database implementano un linguaggio standard chiamato SQL (Structured Query Language). Fra le altre cose, il linguaggio SQL consente di prelevare,

Dettagli

Vincoli di Integrità Approccio dichiarativo alla loro implementazione

Vincoli di Integrità Approccio dichiarativo alla loro implementazione Vincoli di Integrità Approccio dichiarativo alla loro implementazione Antonella Poggi Dipartimento di informatica e Sistemistica SAPIENZA Università di Roma Progetto di Applicazioni Software Anno accademico

Dettagli

TEORIA sulle BASI DI DATI

TEORIA sulle BASI DI DATI TEORIA sulle BASI DI DATI A cura del Prof. Enea Ferri Cos è un DATA BASE E un insieme di archivi legati tra loro da relazioni. Vengono memorizzati su memorie di massa come un unico insieme, e possono essere

Dettagli

Basi di Dati. Introduzione ai sistemi di basi di dati. K.Donno - Introduzione ai sistemi di basi di dati

Basi di Dati. Introduzione ai sistemi di basi di dati. K.Donno - Introduzione ai sistemi di basi di dati Basi di Dati Introduzione ai sistemi di basi di dati Introduzione ai sistemi di basi di dati Gestione dei Dati Una prospettiva storica File system verso DBSM Vantaggi di un DBMS Modelli dei dati Utenti

Dettagli

A. Bardine - Introduzione a PostgreSQL. PostgreSQL è un software relazionale e ad oggetti per la gestione di basi di dati

A. Bardine - Introduzione a PostgreSQL. PostgreSQL è un software relazionale e ad oggetti per la gestione di basi di dati Basi di dati PostgreSQL è un software relazionale e ad oggetti per la gestione di basi di dati PostgreSQL è Open-Source ed il suo sviluppo procede da 15 anni il suo codice sorgente è quindi disponibile

Dettagli

Informatica Documentale

Informatica Documentale Informatica Documentale Ivan Scagnetto (scagnett@dimi.uniud.it) Stanza 3, Nodo Sud Dipartimento di Matematica e Informatica Via delle Scienze, n. 206 33100 Udine Tel. 0432 558451 Ricevimento: giovedì,

Dettagli

Tool. Basi di Dati e Sistemi Informativi Prof. Marco Di Felice Dott.sa Sara Zuppiroli A.A. 2012-2013

Tool. Basi di Dati e Sistemi Informativi Prof. Marco Di Felice Dott.sa Sara Zuppiroli A.A. 2012-2013 Tool Basi di Dati e Sistemi Informativi Prof. Marco Di Felice Dott.sa Sara Zuppiroli A.A. 2012-2013 Basi di Dati e Sistemi Informativi () PostgreSQL A.A. 2012-2013 1 / 26 Gli strumenti che vedremo Basi

Dettagli

Cultura Tecnologica di Progetto

Cultura Tecnologica di Progetto Cultura Tecnologica di Progetto Politecnico di Milano Facoltà di Disegno Industriale - DATABASE - A.A. 2003-2004 2004 DataBase DB e DataBase Management System DBMS - I database sono archivi che costituiscono

Dettagli

L interfaccia a riga di comando di MySql

L interfaccia a riga di comando di MySql L interfaccia a riga di comando di MySql Una volta completata la procedura di installazione possiamo finalmente testare le funzionalità di MySQL. Sia che ci si trovi in ambiente Linux che Windows, l'interfaccia

Dettagli

Introduzione ai sistemi di basi di dati

Introduzione ai sistemi di basi di dati Basi di Dati Introduzione ai sistemi di basi di dati Alessandro.bardine@gmail.com alessandro.bardine@iet.unipi.it Introduzione ai sistemi di basi di dati Gestione dei Dati Una prospettiva storica File

Dettagli

Relazione Pinakes3 Analisi modello di business (BOZZA) di Valeriano Sandrucci 08/09/07

Relazione Pinakes3 Analisi modello di business (BOZZA) di Valeriano Sandrucci 08/09/07 Relazione Pinakes3 Analisi modello di business (BOZZA) di Valeriano Sandrucci 08/09/07 1. Introduzione...3 1.2. Application vs Tool... 3 2. Componenti logiche di un modello... 6 3. Ontologie e Semantic

Dettagli

Basi di dati. Introduzione a PostgreSQL. K.Donno - Introduzione a PostgreSQL

Basi di dati. Introduzione a PostgreSQL. K.Donno - Introduzione a PostgreSQL Basi di dati Introduzione a PostgreSQL Introduzione a PostgreSQL PostgreSQL è un software relazionale e ad oggetti per la gestione di basi di dati PostgreSQL è Open-Source ed il suo sviluppo procede da

Dettagli

Le Basi di dati: generalità. Unità di Apprendimento A1 1

Le Basi di dati: generalità. Unità di Apprendimento A1 1 Le Basi di dati: generalità Unità di Apprendimento A1 1 1 Cosa è una base di dati In ogni modello di organizzazione della vita dell uomo vengono trattate informazioni Una volta individuate e raccolte devono

Dettagli

DBMS (Data Base Management System)

DBMS (Data Base Management System) Cos'è un Database I database o banche dati o base dati sono collezioni di dati, tra loro correlati, utilizzati per rappresentare una porzione del mondo reale. Sono strutturati in modo tale da consentire

Dettagli

DEFINIZIONI FONDAMENTALI

DEFINIZIONI FONDAMENTALI Consorzio per la formazione e la ricerca in Ingegneria dell'informazione DEFINIZIONI FONDAMENTALI Per vincere ci vuole una buona partenza... Docente: Cesare Colombo CEFRIEL colombo@cefriel.it http://www.cefriel.it

Dettagli

Basi di Dati Uso di informazioni statistiche e partizionamento delle tabelle per incrementare le performances in PostgreSQL

Basi di Dati Uso di informazioni statistiche e partizionamento delle tabelle per incrementare le performances in PostgreSQL Basi di Dati Uso di informazioni statistiche e partizionamento delle tabelle per incrementare le performances in PostgreSQL di Matteo Bertini Email: matteo@naufraghi.net Web: http://www.slug.it/naufraghi/

Dettagli

Introduzione ai database I concetti fondamentali Database e DBMS Per comprendere appieno cos'è un Database e quali sono i vantaggi legati al suo impiego, soprattutto nel settore gestionale, è necessario

Dettagli

File e indici. Tecnologia delle BD: perché studiarla? Le basi di dati sono grandi e persistenti. DataBase Management System DBMS

File e indici. Tecnologia delle BD: perché studiarla? Le basi di dati sono grandi e persistenti. DataBase Management System DBMS 1 Tecnologia delle BD: perché studiarla? File e indici I DBMS offrono i loro servizi in modo "trasparente": per questo abbiamo potuto finora ignorare molti aspetti realizzativi abbiamo considerato il DBMS

Dettagli

SCHEDE DI INFORMATICA GLI ARCHIVI E LE BASI DI DATI

SCHEDE DI INFORMATICA GLI ARCHIVI E LE BASI DI DATI SCHEDE DI INFORMATICA GLI ARCHIVI E LE BASI DI DATI Il Database è una collezione di archivi di dati ben organizzati e ben strutturati, in modo che possano costituire una base di lavoro per utenti diversi

Dettagli

DBMS. Esempi di database. DataBase. Alcuni esempi di DBMS DBMS. (DataBase Management System)

DBMS. Esempi di database. DataBase. Alcuni esempi di DBMS DBMS. (DataBase Management System) (DataBase Management System) Sistemi di ges3one di basi di da3 Un Database Management System è un sistema software progettato per consentire la creazione e manipolazione efficiente di database (collezioni

Dettagli

Simonotti Graziano DATABASE

Simonotti Graziano DATABASE DATABASE 1 - Che cos'è un database? Il database è un archivio di dati, che può essere gestito con sistemi informatici oppure in modo manuale. 2 - Come si chiamano i programmi che gestiscono gli archivi?

Dettagli

Introduzione ad SQL. 1. Introduzione. 2. Gli operatori. 3. Istruzione SELECT. 4. Istruzione INSERT. 5. Istruzione UPDATE. 6.

Introduzione ad SQL. 1. Introduzione. 2. Gli operatori. 3. Istruzione SELECT. 4. Istruzione INSERT. 5. Istruzione UPDATE. 6. Introduzione ad SQL Guida a cura di Rio Chierego 1. Introduzione 2. Gli operatori 3. Istruzione SELECT 4. Istruzione INSERT 5. Istruzione UPDATE 6. Istruzione DELETE 7. Istruzione CREATE, ALTER e DROP

Dettagli

Introduzione alle Basi di Dati

Introduzione alle Basi di Dati 1 Introduzione alle Basi di Dati Massimo Paolucci (paolucci@dist.unige.it) DIST Università di Genova Sistema Azienda 2 Sistema organizzativo è costituito da una serie di risorse e di regole necessarie

Dettagli

Che cos è un DBMS? Capitolo 1. Perché usare un DBMS? DBMS. Descrizioni dei dati nei DBMS. Modelli di dati

Che cos è un DBMS? Capitolo 1. Perché usare un DBMS? DBMS. Descrizioni dei dati nei DBMS. Modelli di dati Che cos è un DBMS? Capitolo 1 Introduzione ai sistemi di basi di dati Una collezione integrata molto grande di dati Modella organizzazioni del mondo reale Entità (ad esempio studenti, corsi) Relazioni

Dettagli

SQL - Tipi di dato Il linguaggio SQL

SQL - Tipi di dato Il linguaggio SQL SQL - Tipi di dato Il linguaggio SQL I tipi di dato in SQL:1999 si suddividono in tipi predefiniti tipi strutturati tipi user-defined ci concentreremo sui tipi predefiniti i tipi predefiniti sono suddivisi

Dettagli

Il linguaggio SQL. Il linguaggio SQL. Il linguaggio SQL. SQL - Tipi di dato. SQL - Tipi di dato numerici. SQL - Tipi di dato numerici

Il linguaggio SQL. Il linguaggio SQL. Il linguaggio SQL. SQL - Tipi di dato. SQL - Tipi di dato numerici. SQL - Tipi di dato numerici Il linguaggio SQL Il linguaggio SQL il linguaggio SQL è un linguaggio per la definizione e la manipolazione dei dati, sviluppato originariamente presso il laboratorio IBM a San Jose (California) è diventato

Dettagli

Sistema di Gestione di Basi di Dati DataBase Management System DBMS

Sistema di Gestione di Basi di Dati DataBase Management System DBMS Base di dati (accezione generica) collezione di dati, utilizzati per rappresentare le informazioni di interesse per una o più applicazioni di una organizzazione (accezione specifica) collezione di dati

Dettagli

Basi di dati Il linguaggio SQL

Basi di dati Il linguaggio SQL Basi di dati Il linguaggio SQL teoria e pratica con Microsoft Access Riepilogando Nelle basi di dati esiste 1. una parte invariante nel tempo, lo schema, costituita dalle caratteristiche dei dati (nomi

Dettagli

Basi di dati Il linguaggio SQL

Basi di dati Il linguaggio SQL Riepilogando Basi di dati Il linguaggio SQL Nelle basi di dati esiste 1. una parte invariante nel tempo, lo schema, costituita dalle caratteristiche dei dati (nomi degli attributi, domini, 2. una parte

Dettagli

Vincoli di Integrità

Vincoli di Integrità Vincoli di Integrità Antonella Poggi Dipartimento di informatica e Sistemistica Sapienza Università di Roma Progetto di Applicazioni Software Anno accademico 2010-2011 Questi lucidi sono stati prodotti

Dettagli

Sviluppo di applicazioni web con il pattern Model-View-Controller. Gabriele Pellegrinetti

Sviluppo di applicazioni web con il pattern Model-View-Controller. Gabriele Pellegrinetti Sviluppo di applicazioni web con il pattern Model-View-Controller Gabriele Pellegrinetti 2 MVC: come funziona e quali sono vantaggi che derivano dal suo utilizzo? La grande diffusione della tecnologia

Dettagli

Telerilevamento e GIS Prof. Ing. Giuseppe Mussumeci

Telerilevamento e GIS Prof. Ing. Giuseppe Mussumeci Corso di Laurea Magistrale in Ingegneria per l Ambiente e il Territorio A.A. 2014-2015 Telerilevamento e GIS Prof. Ing. Giuseppe Mussumeci Strutture di dati: DB e DBMS DATO E INFORMAZIONE Dato: insieme

Dettagli

Impararlo è molto semplice, esistono manuali, o meglio mattoni, su SQL, ma qui verranno illustrati tutti i comandi più utilizzati... e utili.

Impararlo è molto semplice, esistono manuali, o meglio mattoni, su SQL, ma qui verranno illustrati tutti i comandi più utilizzati... e utili. Sql è un linguaggio standard che permette di operare con i database. Per database intendo uno qualsiasi e non il solito Access, ma anche Oracle, Microsoft SQL Server, Informix, DB2, Sybase... Sql sta per

Dettagli

RDBMS: panorama attuale. RDBMS: panorama attuale

RDBMS: panorama attuale. RDBMS: panorama attuale RDBMS: panorama attuale Gestiscono e manipolano dati semplici (tabellari) Hanno un linguaggio di interrogazione (SQL) semplice, dichiarativo e standard Tool consolidati per lo sviluppo di applicazioni

Dettagli

XML e Sistemi per la Gestione di Basi di Dati Relazionali

XML e Sistemi per la Gestione di Basi di Dati Relazionali Basi di Dati Distribuite a.a. 2004/2005 XML e Sistemi per la Gestione di Basi di Dati Relazionali Luca Noce - luxnox2000@yahoo.it Elisa Marino - marino_elisa@hotmail.com Obiettivi Necessità di conciliare

Dettagli

1. BASI DI DATI: GENERALITÀ

1. BASI DI DATI: GENERALITÀ 1. BASI DI DATI: GENERALITÀ BASE DI DATI (DATABASE, DB) Raccolta di informazioni o dati strutturati, correlati tra loro in modo da risultare fruibili in maniera ottimale. Una base di dati è usualmente

Dettagli

Progetto Logos - Documentazione -

Progetto Logos - Documentazione - Progetto Logos - Documentazione - Marco Benvegnù Gianluca Marcante Simone Sanavio Roberto De Franceschi PM) Corso di Basi di Dati Corso di Laurea in Ingegneria Informatica A.A. 2002/2003 Progetto Logos

Dettagli

Aspetti applicativi e tecnologia

Aspetti applicativi e tecnologia Aspetti applicativi e tecnologia Premessa Architetture usate per i database Le prime applicazioni erano definite monolitiche, cioè un unico computer (mainframe) gestiva sia le applicazioni che i dati,

Dettagli

Metodi per la Gestione dei Dati (lezioni di laboratorio)

Metodi per la Gestione dei Dati (lezioni di laboratorio) Università degli Studi di Modena e Reggio Emilia Facoltà di Scienze della Comunicazione e dell Economia Corso di Laurea in Comunicazione e Marketing Titolare del corso: ing. Stefano SETTI Lezioni di laboratorio

Dettagli

Informatica 2 Basi di dati

Informatica 2 Basi di dati Informatica 2 Basi di dati Prof. Giovanni Giuffrida e-mail: giovanni.giuffrida@dmi.unict.it DB - Introduzione 1 Recapiti Prof. Giuffrida Giovanni Email: giovanni.giuffrida@dmi.unict.it Info sul corso:

Dettagli

Il linguaggio SQL. I Sistemi di Gestione di Basi di Dati. Data Management Software

Il linguaggio SQL. I Sistemi di Gestione di Basi di Dati. Data Management Software DB2 Data Management Software Il linguaggio SQL I Sistemi di Gestione di Paolo Avallone Sr Consulting IT Specialist DB2, Data Management Marzo 2004 LEGGERE LE SEGUENTI ATTENZIONI Le informazioni contenute

Dettagli

ARCHIVI E LORO ORGANIZZAZIONI

ARCHIVI E LORO ORGANIZZAZIONI ARCHIVI E LORO ORGANIZZAZIONI Archivio: - insieme di registrazioni (record), ciascuna costituita da un insieme prefissato di informazioni elementari dette attributi (campi) - insieme di informazioni relative

Dettagli

Istituto Angioy Informatica BASI DI DATI. Prof. Ciaschetti

Istituto Angioy Informatica BASI DI DATI. Prof. Ciaschetti Istituto Angioy Informatica BASI DI DATI Prof. Ciaschetti Introduzione e prime definizioni Una Base di dati o Database è un archivio elettronico opportunamente organizzato per reperire in modo efficiente

Dettagli

Modelli relazionali. Esistono diversi modi di modellare un database. Il modello piu' usato al momento e' il modello relazionale

Modelli relazionali. Esistono diversi modi di modellare un database. Il modello piu' usato al momento e' il modello relazionale Cenni sui DATABASE Cos'e' un database Un database puo' essere definito come una collezione strutturata di record (dati) I dati sono memorizzati su un computer in modo opportuno e possono essere recuperati

Dettagli

MySQL Command Line Client: operazioni fondamentali

MySQL Command Line Client: operazioni fondamentali MySQL Command Line Client: operazioni fondamentali INTRODUZIONE Il RDBMS MySQL, oltre a fornire un applicazione che abbia un interfaccia user-friendly, ha a disposizione anche un altro client, che svolge

Dettagli

Corso di Informatica

Corso di Informatica Corso di Informatica Modulo T2 A2 Introduzione ai database 1 Prerequisiti Concetto di sistema File system Archivi File e record 2 1 Introduzione Nella gestione di una attività, ad esempio un azienda, la

Dettagli

Università Degli Studi Di Milano. PostgreSQL

Università Degli Studi Di Milano. PostgreSQL Università Degli Studi Di Milano PostgreSQL PgAdmin III è il tool visuale più completo per l'amministrazione del RDBMS e dei singoli database. A prima vista può lasciare un po' disorientati (specialmente

Dettagli

LABORATORIO di INFORMATICA

LABORATORIO di INFORMATICA Università degli Studi di Cagliari Corso di Laurea Magistrale in Ingegneria per l Ambiente ed il Territorio LABORATORIO di INFORMATICA A.A. 2010/2011 Prof. Giorgio Giacinto INTRODUZIONE AI SISTEMI DI BASI

Dettagli

I comandi del linguaggio DDL (Data Definition Language): CREATE E ALTER

I comandi del linguaggio DDL (Data Definition Language): CREATE E ALTER Caratteristiche generali del linguaggio SQL Il linguaggio SQL è il linguaggio usato per la gestione dei database relazionali, cioè dei database creati con un DBMS di tipo relazionale. Esso nacque nella

Dettagli

Il DBMS Oracle. Express Edition. Donatella Gubiani e Angelo Montanari

Il DBMS Oracle. Express Edition. Donatella Gubiani e Angelo Montanari Gubiani & Montanari Il DBMS Oracle 1 Il DBMS Oracle Express Edition Donatella Gubiani e Angelo Montanari Il DBMS Oracle Il DBMS Oracle Oracle 10g Express Edition Il DBMS Oracle (nelle sue versioni più

Dettagli

Sistemi Informativi e Basi di Dati

Sistemi Informativi e Basi di Dati Sistemi Informativi e Basi di Dati Laurea Specialistica in Tecnologie di Analisi degli Impatti Ecotossicologici Docente: Francesco Geri Dipartimento di Scienze Ambientali G. Sarfatti Via P.A. Mattioli

Dettagli

Object-Relational Mapping

Object-Relational Mapping Object-Relational Mapping Versione Preliminare Antonella Poggi Dipartimento di informatica e Sistemistica Sapienza Università di Roma Progetto di Applicazioni Software Anno accademico 2008-2009 Questi

Dettagli

Sistemi Informativi e WWW

Sistemi Informativi e WWW Premesse Sistemi Informativi e WWW WWW: introduce un nuovo paradigma di diffusione (per i fornitori) e acquisizione (per gli utilizzatori) delle informazioni, con facilità d uso, flessibilità ed economicità

Dettagli

Archivi e database. Lezione n. 7

Archivi e database. Lezione n. 7 Archivi e database Lezione n. 7 Dagli archivi ai database (1) I dati non sempre sono stati considerati dall informatica oggetto separato di studio e di analisi Nei primi tempi i dati erano parte integrante

Dettagli

Basi di Dati prof. Letizia Tanca

Basi di Dati prof. Letizia Tanca Basi di Dati prof. Letizia Tanca (lucidi tratti dal libro Atzeni-Ceri-Paraboschi-Torlone) AA 2003-04 Linguaggi di interrogazione commerciali per il Modello Relazionale dei Dati: SQL - il DDL Domini I domini

Dettagli

APPENDICE B Le Active Server Page

APPENDICE B Le Active Server Page APPENDICE B Le Active Server Page B.1 Introduzione ad ASP La programmazione web è nata con la Common Gateway Interface. L interfaccia CGI tuttavia presenta dei limiti: ad esempio anche per semplici elaborazioni

Dettagli

Sistemi Informativi Aziendali II

Sistemi Informativi Aziendali II Modulo 2 Sistemi Informativi Aziendali II 1 Corso Sistemi Informativi Aziendali II - Modulo 2 Modulo 2 La gestione delle informazioni strutturate nell impresa: La progettazione di un Data Base; Le informazioni

Dettagli

RenderCAD S.r.l. Formazione

RenderCAD S.r.l. Formazione Corso Descrizione La durata di questo corso è complessivamente di ore 150 di cui 85 ore di teoria, 35 ore di pratica e 30 ore di stage in azienda. Nel nostro territorio esiste una richiesta di tale figura,

Dettagli

Introduzione alle basi di dati. Gestione delle informazioni. Gestione delle informazioni. Sistema informatico

Introduzione alle basi di dati. Gestione delle informazioni. Gestione delle informazioni. Sistema informatico Introduzione alle basi di dati Introduzione alle basi di dati Gestione delle informazioni Base di dati Modello dei dati Indipendenza dei dati Accesso ai dati Vantaggi e svantaggi dei DBMS Gestione delle

Dettagli

I database relazionali (Access)

I database relazionali (Access) I database relazionali (Access) Filippo TROTTA 04/02/2013 1 Prof.Filippo TROTTA Definizioni Database Sistema di gestione di database (DBMS, Database Management System) Sistema di gestione di database relazionale

Dettagli

Lezione 1. Introduzione e Modellazione Concettuale

Lezione 1. Introduzione e Modellazione Concettuale Lezione 1 Introduzione e Modellazione Concettuale 1 Tipi di Database ed Applicazioni Database Numerici e Testuali Database Multimediali Geographic Information Systems (GIS) Data Warehouses Real-time and

Dettagli

Esercitazioni di Basi di Dati

Esercitazioni di Basi di Dati Esercitazioni di Basi di Dati A.A. 2008-09 Dispense del corso Utilizzo base di pgadmin III Lorenzo Sarti sarti@dii.unisi.it PgAdmin III PgAdmin III è un sistema di progettazione e gestione grafica di database

Dettagli

M070 - ESAME DI STATO DI ISTITUTO TECNICO INDUSTRIALE

M070 - ESAME DI STATO DI ISTITUTO TECNICO INDUSTRIALE A.S. 2002/2003 - SECONDA PROVA - ISTRUZIONE TECNICA M070 - ESAME DI STATO DI ISTITUTO TECNICO INDUSTRIALE Indirizzo: INFORMATICA progetto "Abacus" Tema di: INFORMATICA GENERALE E APPLICAZIONI TECNICO-SCIENTIFICHE

Dettagli

SQL SQL. Definizione dei dati. Domini. Esistono 6 domini elementari:

SQL SQL. Definizione dei dati. Domini. Esistono 6 domini elementari: SQL SQL (pronunciato anche come l inglese sequel: acronimo di Structured Query Language (linguaggio di interrogazione strutturato Linguaggio completo che presenta anche proprietà di: DDL (Data Definition

Dettagli

Domini elementari, 2. Basi di dati. Domini elementari, 4. Domini elementari, 3. Domini definiti dagli utenti. Domini elementari, 5

Domini elementari, 2. Basi di dati. Domini elementari, 4. Domini elementari, 3. Domini definiti dagli utenti. Domini elementari, 5 Domini elementari, Basi di dati Linguaggi di Interrogazione: SQL Prof.Angela Bonifati Bit Valori booleani (vero/falso), singoli o in sequenza (la sequenza può essere di lunghezza variabile) Sintassi: bit

Dettagli

Introduzione Ai Data Bases. Prof. Francesco Accarino IIS Altiero Spinelli Via Leopardi 132 Sesto San giovanni

Introduzione Ai Data Bases. Prof. Francesco Accarino IIS Altiero Spinelli Via Leopardi 132 Sesto San giovanni Introduzione Ai Data Bases Prof. Francesco Accarino IIS Altiero Spinelli Via Leopardi 132 Sesto San giovanni I Limiti Degli Archivi E Il Loro Superamento Le tecniche di gestione delle basi di dati nascono

Dettagli

Il linguaggio SQL. è di fatto lo standard tra i linguaggi per la gestione di data base relazionali.

Il linguaggio SQL. è di fatto lo standard tra i linguaggi per la gestione di data base relazionali. (Structured Query Language) : Il linguaggio è di fatto lo standard tra i linguaggi per la gestione di data base relazionali. prima versione IBM alla fine degli anni '70 per un prototipo di ricerca (System

Dettagli

Basi di dati SQL. Standardizzazione di SQL. Linguaggi di Interrogazione: SQL. Prof.Angela Bonifati

Basi di dati SQL. Standardizzazione di SQL. Linguaggi di Interrogazione: SQL. Prof.Angela Bonifati Basi di dati Linguaggi di Interrogazione: SQL Prof.Angela Bonifati 1 SQL Il nome stava per Structured Query Language Più che un semplice linguaggio di query: si compone di una parte DDL e di una DML DDL:

Dettagli

Laboratorio di Basi di Dati

Laboratorio di Basi di Dati Laboratorio di Basi di Dati Docente: Alberto Belussi Lezione 1 SQL SQL (Structured Query Language) è stato definito nel 1973 ed è oggi il linguaggio più diffuso per i DBMS relazionali. Sono stati proposti

Dettagli

Basi di Dati prof. Letizia Tanca lucidi ispirati al libro Atzeni-Ceri-Paraboschi-Torlone. SQL: il DDL

Basi di Dati prof. Letizia Tanca lucidi ispirati al libro Atzeni-Ceri-Paraboschi-Torlone. SQL: il DDL Basi di Dati prof. Letizia Tanca lucidi ispirati al libro Atzeni-Ceri-Paraboschi-Torlone SQL: il DDL Parti del linguaggio SQL Definizione di basi di dati (Data Definition Language DDL) Linguaggio per modificare

Dettagli

Organizzazione delle informazioni: Database

Organizzazione delle informazioni: Database Organizzazione delle informazioni: Database Laboratorio Informatico di base A.A. 2013/2014 Dipartimento di Scienze Aziendali e Giuridiche Università della Calabria Dott. Pierluigi Muoio (pierluigi.muoio@unical.it)

Dettagli

Lezione V. Aula Multimediale - sabato 29/03/2008

Lezione V. Aula Multimediale - sabato 29/03/2008 Lezione V Aula Multimediale - sabato 29/03/2008 LAB utilizzo di MS Access Definire gli archivi utilizzando le regole di derivazione e descrivere le caratteristiche di ciascun archivio ASSOCIAZIONE (1:1)

Dettagli

Database. Informatica 2014-2015 - Dott. Muzzioli Valerio. 1 di 1. Argomenti trattati: Nozioni di base: i database, i modelli di dati, DBMS

Database. Informatica 2014-2015 - Dott. Muzzioli Valerio. 1 di 1. Argomenti trattati: Nozioni di base: i database, i modelli di dati, DBMS Database Argomenti trattati: Nozioni di base: i database, i modelli di dati, DBMS Database relazionali: tabelle, campi, record; indici di taballa Chiavi primarie ed esterne Relazioni tra tabelle: definizione

Dettagli

Basi di dati. Gabriella Trucco gabriella.trucco@unimi.it

Basi di dati. Gabriella Trucco gabriella.trucco@unimi.it Basi di dati Gabriella Trucco gabriella.trucco@unimi.it Esempio Quando si pensa ad un database, generalmente si immagina una tabella contenente grandi quantità di informazioni, sulla quale è possibile

Dettagli

Basi di Dati e Microsoft Access

Basi di Dati e Microsoft Access Basi di Dati e Microsoft Access Lun: 16-18 e Mer: 14-17 Alessandro Padovani padoale@email.it Database: definizione Un database (DB) è una collezione di informazioni organizzata in gruppi, che consentono

Dettagli

Costruzione di Sit Web con PHP e MySQL. Lezione 7 - Esercitazione - Introduzione a MySQL: le tabelle, i tpi di dato, le query

Costruzione di Sit Web con PHP e MySQL. Lezione 7 - Esercitazione - Introduzione a MySQL: le tabelle, i tpi di dato, le query Costruzione di Sit Web con PHP e MySQL Lezione 7 - Esercitazione - Introduzione a MySQL: le tabelle, i tpi di dato, le query Esercitazione In questa lezione si farà insieme una seconda esercitazione che

Dettagli

La connessione php-mysql con MySQLi

La connessione php-mysql con MySQLi La connessione php-mysql con MySQLi Premessa Lo scenario che si intende alla base di questo capitolo è di disporre di un ambiente phpmysql rappresentato nel seguente schema: L'applicazione php viene eseguita

Dettagli

Algebra e calcolo relazionale. Ripasso. Le 7 Virtù del DBMS persistenza affidabilità volume condivisione riservatezza efficienza efficacia

Algebra e calcolo relazionale. Ripasso. Le 7 Virtù del DBMS persistenza affidabilità volume condivisione riservatezza efficienza efficacia Algebra e calcolo relazionale Ripasso Le 7 Virtù del DBMS persistenza affidabilità volume condivisione riservatezza efficienza efficacia I 4 Livelli di astrazione Le Tabelle Livello fisico (o interno)

Dettagli

Obiettivi d esame PHP Developer Fundamentals on MySQL Environment

Obiettivi d esame PHP Developer Fundamentals on MySQL Environment Obiettivi d esame PHP Developer Fundamentals on MySQL Environment 1.0 Ambiente di sviluppo 1.1 Web server e database MySQL Comprendere la definizione dei processi che si occupano di fornire i servizi web

Dettagli

ARCHIVI CLASSICI. Concetti di base

ARCHIVI CLASSICI. Concetti di base ARCHIVI CLASSICI Concetti di base Per svolgere una qualsiasi attività gestionale, amministrativa, o statistica è necessario utilizzare grandi quantità di dati e scegliere per essi una opportuna organizzazione,

Dettagli

Basi di dati. Il Linguaggio SQL. K. Donno - Il Linguaggio SQL

Basi di dati. Il Linguaggio SQL. K. Donno - Il Linguaggio SQL Basi di dati Il Linguaggio SQL Data Definition Language (DDL) Data Definition Language: insieme di istruzioni utilizzate per modificare la struttura della base di dati Ne fanno parte le istruzioni di inserimento,

Dettagli

Base Dati Introduzione

Base Dati Introduzione Università di Cassino Facoltà di Ingegneria Modulo di Alfabetizzazione Informatica Base Dati Introduzione Si ringrazia l ing. Francesco Colace dell Università di Salerno Gli archivi costituiscono una memoria

Dettagli

PostgreSQL, un database libero per la Pubblica Amministrazione Italiana

PostgreSQL, un database libero per la Pubblica Amministrazione Italiana PostgreSQL, un database libero per la Pubblica Amministrazione Italiana Gabriele Bartolini Comune di Prato Sistema Informativo Servizi di E-government e Open-Source Presidente ITPUG Italian PostgreSQL

Dettagli

I sinonimi in SQL Server

I sinonimi in SQL Server I sinonimi in SQL Server Di Gianluca Negrelli L'identificazione di un oggetto in SQL Server necessita sempre di un riferimento alla gerarchia che lo contiene. Al vertice della gerarchia si posiziona il

Dettagli

Database e Microsoft Access. Ing. Antonio Guadagno

Database e Microsoft Access. Ing. Antonio Guadagno Database e Microsoft Access Ing. Antonio Guadagno Database e Microsoft Access Un Database non è altro che un insieme di contenitori e di strumenti informatici che ci permette di gestire grossi quantitativi

Dettagli

Data Base. Prof. Filippo TROTTA

Data Base. Prof. Filippo TROTTA Data Base Definizione di DataBase Un Database può essere definito come un insieme di informazioni strettamente correlate, memorizzate su un supporto di memoria di massa, costituenti un tutt uno, che possono

Dettagli

Introduzione ai Sistemi di Gestione di Basi di Dati XML

Introduzione ai Sistemi di Gestione di Basi di Dati XML Introduzione ai Sistemi di Gestione di Basi di Dati Introduzione ai Sistemi di Gestione di Basi di Dati Obiettivi Memorizzare ed estrarre documenti da RDBMS. Trasformare dati tabellari in dati e viceversa.

Dettagli

Sistemi Informativi e Basi di Dati. Laurea Specialistica in Tecnologie di Analisi degli Impatti Ecotossicologici. Docente: Francesco Geri

Sistemi Informativi e Basi di Dati. Laurea Specialistica in Tecnologie di Analisi degli Impatti Ecotossicologici. Docente: Francesco Geri Sistemi Informativi e Basi di Dati Laurea Specialistica in Tecnologie di Analisi degli Impatti Ecotossicologici Docente: Francesco Geri Dipartimento di Scienze Ambientali G. Sarfatti Via P.A. Mattioli

Dettagli

corrispondente server Web (l applicazione server) viene inviata una richiesta, alla quale il server normalmente risponde inviando la pagina HTML che

corrispondente server Web (l applicazione server) viene inviata una richiesta, alla quale il server normalmente risponde inviando la pagina HTML che Prefazione In questo volume completiamo l esplorazione del linguaggio Java che abbiamo iniziato in Java Fondamenti di programmazione. I due testi fanno parte di un percorso didattico unitario, come testimoniano

Dettagli