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

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

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

Introduzione a MySQL

Introduzione a MySQL Introduzione a MySQL Cinzia Cappiello Alessandro Raffio Politecnico di Milano Prima di iniziare qualche dettaglio su MySQL MySQL è un sistema di gestione di basi di dati relazionali (RDBMS) composto da

Dettagli

Database, SQL & MySQL. Dott. Paolo PAVAN Maggio 2002

Database, SQL & MySQL. Dott. Paolo PAVAN Maggio 2002 Database, SQL & MySQL Dott. Paolo PAVAN Maggio 2002 1 Struttura RDBMS MYSQL - RDBMS DATABASE TABELLE 2 Introduzione ai DATABASE Database Indica in genere un insieme di dati rivolti alla rappresentazione

Dettagli

Cross Software ltd Malta Pro.Sy.T Srl. Il gestionale come l'avete sempre sognato... Pag. 1

Cross Software ltd Malta Pro.Sy.T Srl. Il gestionale come l'avete sempre sognato... Pag. 1 Il gestionale come l'avete sempre sognato... Pag. 1 Le funzionalità di X-Cross La sofisticata tecnologia di CrossModel, oltre a permettere di lavorare in Internet come nel proprio ufficio e ad avere una

Dettagli

Le funzionalità di un DBMS

Le funzionalità di un DBMS Le funzionalità di un DBMS Sistemi Informativi L-A Home Page del corso: http://www-db.deis.unibo.it/courses/sil-a/ Versione elettronica: DBMS.pdf Sistemi Informativi L-A DBMS: principali funzionalità Le

Dettagli

Dal modello concettuale al modello logico

Dal modello concettuale al modello logico Dal modello concettuale al modello logico Traduzione dal modello Entita - Associazione al modello Relazionale Ciclo di sviluppo di una base di dati (da parte dell utente) Analisi dello scenario Modello

Dettagli

Import Dati Release 4.0

Import Dati Release 4.0 Piattaforma Applicativa Gestionale Import Dati Release 4.0 COPYRIGHT 2000-2005 by ZUCCHETTI S.p.A. Tutti i diritti sono riservati.questa pubblicazione contiene informazioni protette da copyright. Nessuna

Dettagli

Il Business Process Management: nuova via verso la competitività aziendale

Il Business Process Management: nuova via verso la competitività aziendale Il Business Process Management: nuova via verso la competitività Renata Bortolin Che cosa significa Business Process Management? In che cosa si distingue dal Business Process Reingeneering? Cosa ha a che

Dettagli

Applicazione: Share - Sistema per la gestione strutturata di documenti

Applicazione: Share - Sistema per la gestione strutturata di documenti Riusabilità del software - Catalogo delle applicazioni: Gestione Documentale Applicazione: Share - Sistema per la gestione strutturata di documenti Amministrazione: Regione Piemonte - Direzione Innovazione,

Dettagli

Sistemi Operativi. Interfaccia del File System FILE SYSTEM : INTERFACCIA. Concetto di File. Metodi di Accesso. Struttura delle Directory

Sistemi Operativi. Interfaccia del File System FILE SYSTEM : INTERFACCIA. Concetto di File. Metodi di Accesso. Struttura delle Directory FILE SYSTEM : INTERFACCIA 8.1 Interfaccia del File System Concetto di File Metodi di Accesso Struttura delle Directory Montaggio del File System Condivisione di File Protezione 8.2 Concetto di File File

Dettagli

Corso di Programmazione ad Oggetti

Corso di Programmazione ad Oggetti Corso di Programmazione ad Oggetti Introduzione alla programmazione ad oggetti a.a. 2008/2009 Claudio De Stefano 1 La programmazione modulare Un programma può essere visto come un insieme di moduli che

Dettagli

APPLICAZIONE WEB PER LA GESTIONE DELLE RICHIESTE DI ACQUISTO DEL MATERIALE INFORMATICO. Francesco Marchione e Dario Richichi

APPLICAZIONE WEB PER LA GESTIONE DELLE RICHIESTE DI ACQUISTO DEL MATERIALE INFORMATICO. Francesco Marchione e Dario Richichi APPLICAZIONE WEB PER LA GESTIONE DELLE RICHIESTE DI ACQUISTO DEL MATERIALE INFORMATICO Francesco Marchione e Dario Richichi Istituto Nazionale di Geofisica e Vulcanologia Sezione di Palermo Indice Introduzione...

Dettagli

Introduzione alla Programmazione ad Oggetti in C++

Introduzione alla Programmazione ad Oggetti in C++ Introduzione alla Programmazione ad Oggetti in C++ Lezione 1 Cosa è la Programmazione Orientata agli Oggetti Metodologia per costruire prodotti software di grosse dimensioni che siano affidabili e facilmente

Dettagli

Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali

Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali Riusabilità del software - Catalogo delle applicazioni: Applicativo verticale Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali Amministrazione: Regione Piemonte - Direzione Innovazione,

Dettagli

Analisi dei requisiti e casi d uso

Analisi dei requisiti e casi d uso Analisi dei requisiti e casi d uso Indice 1 Introduzione 2 1.1 Terminologia........................... 2 2 Modello della Web Application 5 3 Struttura della web Application 6 4 Casi di utilizzo della Web

Dettagli

SISSI IN RETE. Quick Reference guide guida di riferimento rapido

SISSI IN RETE. Quick Reference guide guida di riferimento rapido SISSI IN RETE Quick Reference guide guida di riferimento rapido Indice generale Sissi in rete...3 Introduzione...3 Architettura Software...3 Installazione di SISSI in rete...3 Utilizzo di SISSI in Rete...4

Dettagli

Cicli in Visual Basic for Application. For contatore = inizio To fine istruzioni Next contatore

Cicli in Visual Basic for Application. For contatore = inizio To fine istruzioni Next contatore Cicli in Visual Basic for Application Le strutture del programma che ripetono l'esecuzione di una o più istruzioni sono chiamate Cicli. Alcune strutture per i cicli sono costruite in modo da venire eseguite

Dettagli

Introduzione ad Access

Introduzione ad Access Introduzione ad Access Luca Bortolussi Dipartimento di Matematica e Informatica Università degli studi di Trieste Access E un programma di gestione di database (DBMS) Access offre: un supporto transazionale

Dettagli

Progetto Didattico di Informatica Multimediale

Progetto Didattico di Informatica Multimediale Progetto Didattico di Informatica Multimediale VRAI - Vision, Robotics and Artificial Intelligence 20 aprile 2015 Rev. 18+ Introduzione Le videocamere di riconoscimento sono strumenti sempre più utilizzati

Dettagli

Come difendersi dai VIRUS

Come difendersi dai VIRUS Come difendersi dai VIRUS DEFINIZIONE Un virus è un programma, cioè una serie di istruzioni, scritte in un linguaggio di programmazione, in passato era di solito di basso livello*, mentre con l'avvento

Dettagli

Il ciclo di vita del software

Il ciclo di vita del software Il ciclo di vita del software Il ciclo di vita del software Definisce un modello per il software, dalla sua concezione iniziale fino al suo sviluppo completo, al suo rilascio, alla sua successiva evoluzione,

Dettagli

Sistemi di supporto alle decisioni Ing. Valerio Lacagnina

Sistemi di supporto alle decisioni Ing. Valerio Lacagnina Cosa è il DSS L elevato sviluppo dei personal computer, delle reti di calcolatori, dei sistemi database di grandi dimensioni, e la forte espansione di modelli basati sui calcolatori rappresentano gli sviluppi

Dettagli

SIASFi: il sistema ed il suo sviluppo

SIASFi: il sistema ed il suo sviluppo SIASFI: IL SISTEMA ED IL SUO SVILUPPO 187 SIASFi: il sistema ed il suo sviluppo Antonio Ronca Il progetto SIASFi nasce dall esperienza maturata da parte dell Archivio di Stato di Firenze nella gestione

Dettagli

Sempre attenti ad ogni dettaglio Bosch Intelligent Video Analysis

Sempre attenti ad ogni dettaglio Bosch Intelligent Video Analysis Sempre attenti ad ogni dettaglio Bosch Intelligent Video Analysis 2 Intervento immediato con Bosch Intelligent Video Analysis Indipendentemente da quante telecamere il sistema utilizza, la sorveglianza

Dettagli

FIRESHOP.NET. Gestione Utility & Configurazioni. Rev. 2014.3.1 www.firesoft.it

FIRESHOP.NET. Gestione Utility & Configurazioni. Rev. 2014.3.1 www.firesoft.it FIRESHOP.NET Gestione Utility & Configurazioni Rev. 2014.3.1 www.firesoft.it Sommario SOMMARIO Introduzione... 4 Impostare i dati della propria azienda... 5 Aggiornare il programma... 6 Controllare l integrità

Dettagli

Piattaforma Applicativa Gestionale. Import dati. Release 7.0

Piattaforma Applicativa Gestionale. Import dati. Release 7.0 Piattaforma Applicativa Gestionale Import dati Release 7.0 COPYRIGHT 2000-2012 by ZUCCHETTI S.p.A. Tutti i diritti sono riservati. Questa pubblicazione contiene informazioni protette da copyright. Nessuna

Dettagli

Guida rapida all uso di ECM Titanium

Guida rapida all uso di ECM Titanium Guida rapida all uso di ECM Titanium Introduzione Questa guida contiene una spiegazione semplificata del funzionamento del software per Chiputilizzare al meglio il Tuning ECM Titanium ed include tutte

Dettagli

Manuale dell'utente di Symantec Backup Exec System Recovery Granular Restore Option

Manuale dell'utente di Symantec Backup Exec System Recovery Granular Restore Option Manuale dell'utente di Symantec Backup Exec System Recovery Granular Restore Option Manuale dell'utente di Symantec Backup Exec System Recovery Granular Restore Option Il software descritto nel presente

Dettagli

L evoluzione del software per l azienda moderna. Gestirsi / Capirsi / Migliorarsi

L evoluzione del software per l azienda moderna. Gestirsi / Capirsi / Migliorarsi IL GESTIONALE DEL FUTURO L evoluzione del software per l azienda moderna Gestirsi / Capirsi / Migliorarsi IL MERCATO ITALIANO L Italia è rappresentata da un numero elevato di piccole e medie aziende che

Dettagli

PROPOSTE SISTEMA DI CITIZEN RELATIONSHIP MANAGEMENT (CRM) REGIONALE

PROPOSTE SISTEMA DI CITIZEN RELATIONSHIP MANAGEMENT (CRM) REGIONALE PROPOSTE SISTEMA DI CITIZEN RELATIONSHIP MANAGEMENT (CRM) REGIONALE Versione 1.0 Via della Fisica 18/C Tel. 0971 476311 Fax 0971 476333 85100 POTENZA Via Castiglione,4 Tel. 051 7459619 Fax 051 7459619

Dettagli

I.Stat Guida utente Versione 1.7 Dicembre 2010

I.Stat Guida utente Versione 1.7 Dicembre 2010 I.Stat Guida utente Versione 1.7 Dicembre 2010 1 Sommario INTRODUZIONE 3 I concetti principali di I.Stat 4 Organizzazione dei dati 4 Ricerca 5 GUIDA UTENTE 6 Per iniziare 6 Selezione della lingua 7 Individuazione

Dettagli

Supporto alle decisioni e strategie commerciali/mercati/prodotti/forza vendita;

Supporto alle decisioni e strategie commerciali/mercati/prodotti/forza vendita; .netbin. è un potentissimo strumento SVILUPPATO DA GIEMME INFORMATICA di analisi dei dati con esposizione dei dati in forma numerica e grafica con un interfaccia visuale di facile utilizzo, organizzata

Dettagli

Analisi dei requisiti e casi d uso

Analisi dei requisiti e casi d uso Analisi dei requisiti e casi d uso Indice 1 Introduzione 2 1.1 Terminologia........................... 2 2 Modello del sistema 4 2.1 Requisiti hardware........................ 4 2.2 Requisiti software.........................

Dettagli

P a s q u a l e t t i V e r o n i c a

P a s q u a l e t t i V e r o n i c a PHP: OOP Pasqualetti Veronica Oggetti Possiamo pensare ad un oggetto come ad un tipo di dato più complesso e personalizzato, non esistente fra i tipi tradizionali di PHP, ma creato da noi. 2 Gli oggetti

Dettagli

ORACLE BUSINESS INTELLIGENCE STANDARD EDITION ONE A WORLD CLASS PERFORMANCE

ORACLE BUSINESS INTELLIGENCE STANDARD EDITION ONE A WORLD CLASS PERFORMANCE ORACLE BUSINESS INTELLIGENCE STANDARD EDITION ONE A WORLD CLASS PERFORMANCE Oracle Business Intelligence Standard Edition One è una soluzione BI completa, integrata destinata alle piccole e medie imprese.oracle

Dettagli

Documentazione Servizio SMS WEB. Versione 1.0

Documentazione Servizio SMS WEB. Versione 1.0 Documentazione Servizio SMS WEB Versione 1.0 1 Contenuti 1 INTRODUZIONE...5 1.1 MULTILANGUAGE...5 2 MESSAGGI...7 2.1 MESSAGGI...7 2.1.1 INVIO SINGOLO SMS...7 2.1.2 INVIO MULTIPLO SMS...9 2.1.3 INVIO MMS

Dettagli

Simplex Gestione Hotel

Simplex Gestione Hotel Simplex Gestione Hotel Revisione documento 01-2012 Questo documento contiene le istruzioni per l'utilizzo del software Simplex Gestione Hotel. E' consentita la riproduzione e la distribuzione da parte

Dettagli

CAPITOLO 3. Elementi fondamentali della struttura organizzativa

CAPITOLO 3. Elementi fondamentali della struttura organizzativa CAPITOLO 3 Elementi fondamentali della struttura organizzativa Agenda La struttura organizzativa Le esigenze informative Tipologia di strutture Struttura funzionale Struttura divisionale Struttura per

Dettagli

Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN)

Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN) Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN) System Overview di Mattia Bargellini 1 CAPITOLO 1 1.1 Introduzione Il seguente progetto intende estendere

Dettagli

Integrazione tra sistemi MES e ERP

Integrazione tra sistemi MES e ERP ALMA MATER STUDIORUM - UNIVERSITÀ DI BOLOGNA SEDE DI CESENA FACOLTÀ DI SCIENZE MATEMATICHE, FISICHE E NATURALI Corso di Laurea in Scienze e Tecnologie Informatiche Integrazione tra sistemi MES e ERP Relazione

Dettagli

MODELLO AD OGGETTI PER LE BASI DI DATI E ANALISI DI PRODOTTI COMMERCIALI. Luca Carnini. Tesina presentata per la discussione del diploma di laurea in

MODELLO AD OGGETTI PER LE BASI DI DATI E ANALISI DI PRODOTTI COMMERCIALI. Luca Carnini. Tesina presentata per la discussione del diploma di laurea in MODELLO AD OGGETTI PER LE BASI DI DATI E ANALISI DI PRODOTTI COMMERCIALI di Luca Carnini Tesina presentata per la discussione del diploma di laurea in Ingegneria informatica Politecnico di Milano sede

Dettagli

FileMaker Server 13. Pubblicazione Web personalizzata con PHP

FileMaker Server 13. Pubblicazione Web personalizzata con PHP FileMaker Server 13 Pubblicazione Web personalizzata con PHP 2007-2013 FileMaker, Inc. Tutti i diritti riservati. FileMaker, Inc. 5201 Patrick Henry Drive Santa Clara, California 95054 Stati Uniti FileMaker

Dettagli

BPEL: Business Process Execution Language

BPEL: Business Process Execution Language Ingegneria dei processi aziendali BPEL: Business Process Execution Language Ghilardi Dario 753708 Manenti Andrea 755454 Docente: Prof. Ernesto Damiani BPEL - definizione Business Process Execution Language

Dettagli

Il linguaggio SQL: transazioni

Il linguaggio SQL: transazioni Il linguaggio SQL: transazioni Sistemi Informativi T Versione elettronica: 4.8.SQL.transazioni.pdf Cos è una transazione? Una transazione è un unità logica di elaborazione che corrisponde a una serie di

Dettagli

PLM Software. Answers for industry. Siemens PLM Software

PLM Software. Answers for industry. Siemens PLM Software Siemens PLM Software Monitoraggio e reporting delle prestazioni di prodotti e programmi Sfruttare le funzionalità di reporting e analisi delle soluzioni PLM per gestire in modo più efficace i complessi

Dettagli

Corso SOL Gestione catalogo libro moderno 21-22 settembre 2009

Corso SOL Gestione catalogo libro moderno 21-22 settembre 2009 Corso SOL Gestione catalogo libro moderno 21-22 settembre 2009 Introduzione generale Autenticazione dell operatore https://sebina1.unife.it/sebinatest Al primo accesso ai servizi di Back Office, utilizzando

Dettagli

Il Sistema Operativo: il File System

Il Sistema Operativo: il File System Il Sistema Operativo: il File System Il File System è quella parte del S.O. che si occupa di gestire e strutturare le informazioni memorizzate su supporti permanenti (memoria secondaria) I file vengono

Dettagli

AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi

AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma Unified Process Prof. Agostino Poggi Unified Process Unified Software Development Process (USDP), comunemente chiamato

Dettagli

Quando A e B coincidono una coppia ordinata é determinata anche dalla loro posizione.

Quando A e B coincidono una coppia ordinata é determinata anche dalla loro posizione. Grafi ed Alberi Pag. /26 Grafi ed Alberi In questo capitolo richiameremo i principali concetti di due ADT che ricorreranno puntualmente nel corso della nostra trattazione: i grafi e gli alberi. Naturale

Dettagli

Relazione sul data warehouse e sul data mining

Relazione sul data warehouse e sul data mining Relazione sul data warehouse e sul data mining INTRODUZIONE Inquadrando il sistema informativo aziendale automatizzato come costituito dall insieme delle risorse messe a disposizione della tecnologia,

Dettagli

Data warehouse.stat Guida utente

Data warehouse.stat Guida utente Data warehouse.stat Guida utente Versione 3.0 Giugno 2013 1 Sommario INTRODUZIONE 3 I concetti principali 4 Organizzazione dei dati 4 Ricerca 5 Il browser 5 GUIDA UTENTE 6 Per iniziare 6 Selezione della

Dettagli

CA RC/Update for DB2 for z/os

CA RC/Update for DB2 for z/os SCHEDA PRODOTTO CA RC/Update for DB2 for z/os CA RC/Update for DB2 for z/os CA RC/Update for DB2 for z/os (CA RC/Update) è uno strumento di gestione di dati e oggetti DB2 che consente agli amministratori

Dettagli

GUIDA RAPIDA emagister-agora Edizione BASIC

GUIDA RAPIDA emagister-agora Edizione BASIC GUIDA RAPIDA emagister-agora Edizione BASIC Introduzione a emagister-agora Interfaccia di emagister-agora Configurazione dell offerta didattica Richieste d informazioni Gestione delle richieste d informazioni

Dettagli

HORIZON SQL CONFIGURAZIONE DI RETE

HORIZON SQL CONFIGURAZIONE DI RETE 1-1/9 HORIZON SQL CONFIGURAZIONE DI RETE 1 CARATTERISTICHE DI UN DATABASE SQL...1-2 Considerazioni generali... 1-2 Concetto di Server... 1-2 Concetto di Client... 1-2 Concetto di database SQL... 1-2 Vantaggi...

Dettagli

PHP: form, cookies, sessioni e. Pasqualetti Veronica

PHP: form, cookies, sessioni e. Pasqualetti Veronica PHP: form, cookies, sessioni e mysql Pasqualetti Veronica Form HTML: sintassi dei form 2 Un form HTML è una finestra contenente vari elementi di controllo che consentono al visitatore di inserire informazioni.

Dettagli

Il linguaggio SQL Basi di dati 1. Il linguaggio SQL. Angelo Montanari. Dipartimento di Matematica e Informatica Università di Udine

Il linguaggio SQL Basi di dati 1. Il linguaggio SQL. Angelo Montanari. Dipartimento di Matematica e Informatica Università di Udine Il linguaggio SQL Basi di dati 1 Il linguaggio SQL Angelo Montanari Dipartimento di Matematica e Informatica Università di Udine Il linguaggio SQL Basi di dati 2 Introduzione SQL (Structured Query Language)

Dettagli

DNS (Domain Name System) Gruppo Linux

DNS (Domain Name System) Gruppo Linux DNS (Domain Name System) Gruppo Linux Luca Sozio Matteo Giordano Vincenzo Sgaramella Enrico Palmerini DNS (Domain Name System) Ci sono due modi per identificare un host nella rete: - Attraverso un hostname

Dettagli

RedDot Content Management Server Content Management Server Non sottovalutate il potenziale della comunicazione online: usatela! RedDot CMS vi permette di... Implementare, gestire ed estendere progetti

Dettagli

Comandi filtro: sed. Se non si specificano azioni, sed stampa sullo standard output le linee in input, lasciandole inalterate.

Comandi filtro: sed. Se non si specificano azioni, sed stampa sullo standard output le linee in input, lasciandole inalterate. Comandi filtro: sed Il nome del comando sed sta per Stream EDitor e la sua funzione è quella di permettere di editare il testo passato da un comando ad un altro in una pipeline. Ciò è molto utile perché

Dettagli

Dati importati/esportati

Dati importati/esportati Dati importati/esportati Dati importati Al workspace MATLAB script Dati esportati file 1 File di testo (.txt) Spreadsheet Database Altro Elaborazione dati Grafici File di testo Relazioni Codice Database

Dettagli

Progetto VirtualCED Clustered

Progetto VirtualCED Clustered Progetto VirtualCED Clustered Un passo indietro Il progetto VirtualCED, descritto in un precedente articolo 1, è ormai stato implementato con successo. Riassumendo brevemente, si tratta di un progetto

Dettagli

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica A.A. 2007-08 CORSO DI INGEGNERIA DEL SOFTWARE Prof. Giulio Destri http://www.areasp.com (C) 2007 AreaSP for

Dettagli

GUIDA ALLE BEST PRACTICE PER MOBILE DEVICE MANAGEMENT E MOBILE SECURITY

GUIDA ALLE BEST PRACTICE PER MOBILE DEVICE MANAGEMENT E MOBILE SECURITY GUIDA ALLE BEST PRACTICE PER MOBILE DEVICE MANAGEMENT E MOBILE SECURITY Con Kaspersky, adesso è possibile. www.kaspersky.it/business Be Ready for What's Next SOMMARIO Pagina 1. APERTI 24 ORE SU 24...2

Dettagli

DynDevice ECM. La Suite di applicazioni web per velocizzare, standardizzare e ottimizzare il flusso delle informazioni aziendali

DynDevice ECM. La Suite di applicazioni web per velocizzare, standardizzare e ottimizzare il flusso delle informazioni aziendali DynDevice ECM La Suite di applicazioni web per velocizzare, standardizzare e ottimizzare il flusso delle informazioni aziendali Presentazione DynDevice ECM Cos è DynDevice ICMS Le soluzioni di DynDevice

Dettagli

INFORMATIVA SUI COOKIE

INFORMATIVA SUI COOKIE INFORMATIVA SUI COOKIE I Cookie sono costituiti da porzioni di codice installate all'interno del browser che assistono il Titolare nell erogazione del servizio in base alle finalità descritte. Alcune delle

Dettagli

Agilent OpenLAB Chromatography Data System (CDS)

Agilent OpenLAB Chromatography Data System (CDS) Agilent OpenLAB Chromatography Data System (CDS) EZChrom Edition e ChemStation Edition Requisiti hardware e software Agilent Technologies Informazioni legali Agilent Technologies, Inc. 2013 Nessuna parte

Dettagli

Ottimizzazione della gestione del data center con Microsoft System Center

Ottimizzazione della gestione del data center con Microsoft System Center Ottimizzazione della gestione del data center con Microsoft System Center Declinazione di responsabilità e informazioni sul copyright Le informazioni contenute nel presente documento rappresentano le conoscenze

Dettagli

Introduzione al GIS (Geographic Information System)

Introduzione al GIS (Geographic Information System) Introduzione al GIS (Geographic Information System) Sommario 1. COS E IL GIS?... 3 2. CARATTERISTICHE DI UN GIS... 3 3. COMPONENTI DI UN GIS... 4 4. CONTENUTI DI UN GIS... 5 5. FASI OPERATIVE CARATTERIZZANTI

Dettagli

Le Reti Informatiche

Le Reti Informatiche Le Reti Informatiche modulo 10 Prof. Salvatore Rosta www.byteman.it s.rosta@byteman.it 1 Nomenclatura: 1 La rappresentazione di uno schema richiede una serie di abbreviazioni per i vari componenti. Seguiremo

Dettagli

LA MOLTIPLICAZIONE IN PRIMA ELEMENTARE

LA MOLTIPLICAZIONE IN PRIMA ELEMENTARE LA MOLTIPLICAZIONE IN PRIMA ELEMENTARE E bene presentarla confrontando tra loro varie tecniche: addizione ripetuta; prodotto combinatorio (schieramenti). Rispetto a quest'ultima tecnica, grande utilità

Dettagli

Progettazione di un DB....in breve

Progettazione di un DB....in breve Progettazione di un DB...in breve Cosa significa progettare un DB Definirne struttura,caratteristiche e contenuto. Per farlo è opportuno seguire delle metodologie che permettono di ottenere prodotti di

Dettagli

Dal punto di vista organizzativo sono possibili due soluzioni per il sistema di rete.

Dal punto di vista organizzativo sono possibili due soluzioni per il sistema di rete. Premessa. La traccia di questo anno integra richieste che possono essere ricondotte a due tipi di prove, informatica sistemi, senza lasciare spazio ad opzioni facoltative. Alcuni quesiti vanno oltre le

Dettagli

Copyright Università degli Studi di Torino, Progetto Atlante delle Professioni 2009 IT PROCESS EXPERT

Copyright Università degli Studi di Torino, Progetto Atlante delle Professioni 2009 IT PROCESS EXPERT IT PROCESS EXPERT 1. CARTA D IDENTITÀ... 2 2. CHE COSA FA... 3 3. DOVE LAVORA... 4 4. CONDIZIONI DI LAVORO... 5 5. COMPETENZE... 6 Quali competenze sono necessarie... 6 Conoscenze... 8 Abilità... 9 Comportamenti

Dettagli

UML: Class Diagram. Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it

UML: Class Diagram. Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it UML: Class Diagram Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania Class Diagram Forniscono una vista strutturale

Dettagli

Manuale Utente. S e m p l i c e m e n t e D a t i M i g l i o r i!

Manuale Utente. S e m p l i c e m e n t e D a t i M i g l i o r i! Manuale Utente S e m p l i c e m e n t e D a t i M i g l i o r i! INDICE INDICE... 3 INTRODUZIONE... 3 Riguardo questo manuale...3 Informazioni su VOLT 3 Destinatari 3 Software Richiesto 3 Novità su Volt...3

Dettagli

Talento LAB 4.1 - UTILIZZARE FTP (FILE TRANSFER PROTOCOL) L'UTILIZZO DI ALTRI SERVIZI INTERNET. In questa lezione imparerete a:

Talento LAB 4.1 - UTILIZZARE FTP (FILE TRANSFER PROTOCOL) L'UTILIZZO DI ALTRI SERVIZI INTERNET. In questa lezione imparerete a: Lab 4.1 Utilizzare FTP (File Tranfer Protocol) LAB 4.1 - UTILIZZARE FTP (FILE TRANSFER PROTOCOL) In questa lezione imparerete a: Utilizzare altri servizi Internet, Collegarsi al servizio Telnet, Accedere

Dettagli

Guida Dell di base all'acquisto dei server

Guida Dell di base all'acquisto dei server Guida Dell di base all'acquisto dei server Per le piccole aziende che dispongono di più computer è opportuno investire in un server che aiuti a garantire la sicurezza e l'organizzazione dei dati, consentendo

Dettagli

Business Intelligence

Business Intelligence aggregazione dati Business Intelligence analytic applications query d a t a w a r e h o u s e aggregazione budget sales inquiry data mining Decision Support Systems MIS ERP data management Data Modeling

Dettagli

RELAZIONE DI FINE TIROCINIO

RELAZIONE DI FINE TIROCINIO Dipartimento di Ingegneria Civile Laura Magistrale in Ingegneria Civile per la Protezione dai Rischi Naturali A.A. 2014-2015 RELAZIONE DI FINE TIROCINIO INTRODUZIONE ALL'USO DEL SOFTWARE GIS UDIG Tirocinante:

Dettagli

12.5 UDP (User Datagram Protocol)

12.5 UDP (User Datagram Protocol) CAPITOLO 12. SUITE DI PROTOCOLLI TCP/IP 88 12.5 UDP (User Datagram Protocol) L UDP (User Datagram Protocol) é uno dei due protocolli del livello di trasporto. Come l IP, é un protocollo inaffidabile, che

Dettagli

Oggetti Lezione 3. aspetti generali e definizione di classi I

Oggetti Lezione 3. aspetti generali e definizione di classi I Programmazione a Oggetti Lezione 3 Il linguaggio Java: aspetti generali e definizione di classi I Sommario Storia e Motivazioni Definizione di Classi Campi e Metodi Istanziazione di oggetti Introduzione

Dettagli

Boot Camp Guida di installazione e configurazione

Boot Camp Guida di installazione e configurazione Boot Camp Guida di installazione e configurazione Indice 3 Introduzione 4 Panoramica dell'installazione 4 Passo 1: Verificare la presenza di aggiornamenti 4 Passo 2: Per preparare il Mac per Windows 4

Dettagli

Calc è il programma per la gestione di fogli di calcolo della suite OpenOffice.org.

Calc è il programma per la gestione di fogli di calcolo della suite OpenOffice.org. Calc è il programma per la gestione di fogli di calcolo della suite OpenOffice.org. Nuovo documento Anteprima di stampa Annulla Galleria Apri Controllo ortografico Ripristina Sorgente dati Salva Controllo

Dettagli

12 famiglie e tipi di file (estensioni più comuni)

12 famiglie e tipi di file (estensioni più comuni) 12 famiglie e tipi di file (estensioni più comuni) Ogni file è caratterizzato da un proprio nome e da una estensione, in genere tre lettere precedute da un punto; ad esempio:.est Vi sono tuttavia anche

Dettagli

Il Concetto di Processo

Il Concetto di Processo Processi e Thread Il Concetto di Processo Il processo è un programma in esecuzione. È l unità di esecuzione all interno del S.O. Solitamente, l esecuzione di un processo è sequenziale (le istruzioni vengono

Dettagli

Organizzazione: teoria, progettazione e cambiamento

Organizzazione: teoria, progettazione e cambiamento Organizzazione: teoria, progettazione e cambiamento Edizione italiana a cura di G. Soda Capitolo 6 La progettazione della struttura organizzativa: specializzazione e coordinamento Jones, Organizzazione

Dettagli

Installazione LINUX 10.0

Installazione LINUX 10.0 Installazione LINUX 10.0 1 Principali passi Prima di iniziare con l'installazione è necessario entrare nel menu di configurazione del PC (F2 durante lo start-up) e selezionare nel menu di set-up il boot

Dettagli

Scuola Specializzazione Istruzione Superiore. Object Oriented Programming (OOP) Introduzione alla programmazione orientata agli oggetti

Scuola Specializzazione Istruzione Superiore. Object Oriented Programming (OOP) Introduzione alla programmazione orientata agli oggetti Scuola Specializzazione Istruzione Superiore Object Oriented Programming (OOP) Introduzione alla programmazione orientata agli oggetti Michele Batocchi ITC Vittorio Emanuele II Perugia A.S. 2007/2008 Introduzione

Dettagli

ALGEBRA: LEZIONI DAL 13 OTTOBRE AL 3 NOVEMBRE

ALGEBRA: LEZIONI DAL 13 OTTOBRE AL 3 NOVEMBRE ALGEBRA: LEZIONI DAL 13 OTTOBRE AL 3 NOVEMBRE 1 DIPENDENZA E INDIPENDENZA LINEARE Se ho alcuni vettori v 1, v 2,, v n in uno spazio vettoriale V, il sottospazio 1 W = v 1,, v n di V da loro generato è

Dettagli

Mobile Messaging SMS. Copyright 2015 VOLA S.p.A.

Mobile Messaging SMS. Copyright 2015 VOLA S.p.A. Mobile Messaging SMS Copyright 2015 VOLA S.p.A. INDICE Mobile Messaging SMS. 2 SMS e sistemi aziendali.. 2 Creare campagne di mobile marketing con i servizi Vola SMS.. 3 VOLASMS per inviare SMS da web..

Dettagli

Energy Data Management System (EDMS): la soluzione software per una gestione efficiente dell energia secondo lo standard ISO 50001

Energy Data Management System (EDMS): la soluzione software per una gestione efficiente dell energia secondo lo standard ISO 50001 Energy Data Management System (EDMS): la soluzione software per una gestione efficiente dell energia secondo lo standard ISO 50001 Oggi più che mai, le aziende italiane sentono la necessità di raccogliere,

Dettagli

Inidirizzi IP e Nomi di Dominio. Domain Name System. Spazio dei Nomi Piatto. Gestione dello Spazio dei Nomi

Inidirizzi IP e Nomi di Dominio. Domain Name System. Spazio dei Nomi Piatto. Gestione dello Spazio dei Nomi I semestre 03/04 Inidirizzi IP e Nomi di Dominio Domain Name System Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/professori/auletta/ Università degli studi di Salerno Laurea in Informatica

Dettagli

Business Process Management

Business Process Management Business Process Management Comprendere, gestire, organizzare e migliorare i processi di business Caso di studio a cura della dott. Danzi Francesca e della prof. Cecilia Rossignoli 1 Business process Un

Dettagli

Acronis Backup & Recovery 10 Server for Windows Acronis Backup & Recovery 10 Workstation

Acronis Backup & Recovery 10 Server for Windows Acronis Backup & Recovery 10 Workstation Acronis Backup & Recovery 10 Server for Windows Acronis Backup & Recovery 10 Workstation Guida introduttiva 1 Informazioni sul documento Questo documento descrive come installare e iniziare ad utilizzare

Dettagli

MANUALE Gest-L VERSIONE 3.2.3

MANUALE Gest-L VERSIONE 3.2.3 MANUALE Gest-L VERSIONE 3.2.3 Installazione GEST-L 4 Versione per Mac - Download da www.system-i.it 4 Versione per Mac - Download da Mac App Store 4 Versione per Windows 4 Prima apertura del programma

Dettagli

Gestione delle Architetture e dei Servizi IT con ADOit. Un Prodotto della Suite BOC Management Office

Gestione delle Architetture e dei Servizi IT con ADOit. Un Prodotto della Suite BOC Management Office Gestione delle Architetture e dei Servizi IT con ADOit Un Prodotto della Suite BOC Management Office Controllo Globale e Permanente delle Architetture IT Aziendali e dei Processi IT: IT-Governance Definire

Dettagli

La gestione documentale con il programma Filenet ed il suo utilizzo tramite la tecnologia.net. di Emanuele Mattei (emanuele.mattei[at]email.

La gestione documentale con il programma Filenet ed il suo utilizzo tramite la tecnologia.net. di Emanuele Mattei (emanuele.mattei[at]email. La gestione documentale con il programma Filenet ed il suo utilizzo tramite la tecnologia.net di Emanuele Mattei (emanuele.mattei[at]email.it) Introduzione In questa serie di articoli, vedremo come utilizzare

Dettagli