progettazione e sviluppo di un applicativo web e della sua base di dati per l'organizzazione di...
TRANSCRIPT
Università degli Studi di Trieste
Dipartimento di Ingegneria e Architettura
Corso di Laurea Triennale in Ingegneria dell’Informazione
Curriculum Informatica
Progettazione e sviluppo di un applicativo web e
della sua base di dati per l'organizzazione di
ambienti di lavoro
Relatore: Chiar.mo Prof. Maurizio Fermeglia
Laureando: Stefano Dudine
Anno accademico 2012/2013
I
Indice
Introduzione ....................................................................................................................... 1
1. Analisi ............................................................................................................................. 3
1.1. Prime decisioni ......................................................................................................... 4
1.2. Obiettivi .................................................................................................................... 5
1.3. Tecnologie software utilizzate .................................................................................. 5
2. Documentazione del database ....................................................................................... 7
2.1. Raccolta dei requisiti ................................................................................................ 7
2.1.1. Descrizione .......................................................................................................................... 7
2.1.2. In dettaglio .......................................................................................................................... 9
2.1.3. Requisiti di carico .............................................................................................................. 10
2.2. Progettazione concettuale ...................................................................................... 11
2.2.1. Glossario dei termini ......................................................................................................... 11
2.2.2. Strutturazione dei requisiti ............................................................................................... 11
2.2.3. Schema scheletro .............................................................................................................. 14
2.2.4. Schema E – R finale ........................................................................................................... 16
2.2.5. Analisi delle entità ............................................................................................................ 17
2.2.6. Analisi delle associazioni e delle cardinalità ..................................................................... 19
2.2.7. Regole di business............................................................................................................. 21
2.2.8. Schema E – R finale con attributi e cardinalità ................................................................. 22
II
2.3. Progettazione logica ............................................................................................... 23
2.3.1. Tavola dei volumi .............................................................................................................. 23
2.3.2. Tavola delle operazioni ..................................................................................................... 24
2.3.3. Tavole degli accessi ........................................................................................................... 24
2.3.4. Analisi delle ridondanze .................................................................................................... 27
2.3.5. Eliminazione delle gerarchie ............................................................................................. 29
2.3.6. Partizionamento / accorpamento di concetti .................................................................. 29
2.3.7. Scelta degli identificatori primari ..................................................................................... 30
2.3.8. Normalizzazione................................................................................................................ 30
2.3.9. Schema E – R ristrutturato ................................................................................................ 31
2.3.10. Traduzione verso il relazionale – schema logico ............................................................ 32
2.4. Schema fisico ......................................................................................................... 33
2.5. Documentazione aggiuntiva ................................................................................... 34
2.5.1. Viste .................................................................................................................................. 34
2.5.2. Trigger ............................................................................................................................... 34
2.5.3. Sorgenti dei trigger e stored procedure ........................................................................... 36
3. Documentazione dell’applicazione ................................................................................ 40
3.1. Interfaccia .............................................................................................................. 40
3.2. Implementazione .................................................................................................... 43
3.2.1. Lato client ......................................................................................................................... 43
3.2.2. Lato server ........................................................................................................................ 48
4. Conclusioni ................................................................................................................... 51
Bibliografia ....................................................................................................................... 52
1
Introduzione
Il progetto consiste nel realizzare un’applicazione che aiuti l’organizzazione degli ambienti
di lavoro di un’azienda. I magazzini e i punti vendita in genere sono colmi di oggetti
sistemati su mensole e scaffali e cercare un oggetto in particolare, di cui si conoscono solo
determinate caratteristiche, può risultare complicato sia per il personale che per i clienti.
Sotto queste condizioni, l’applicazione ha lo scopo di velocizzare la ricerca.
In un secondo momento si è pensato che tale applicazione potrebbe esser utile non solo
ad un’azienda ma a qualsiasi organizzazione di persone che desideri condividere la
posizione di oggetti di interesse comune, anche in ambito non lavorativo.
È necessario che la persona che vuole registrare la posizione di un oggetto generico
fotografi l’ambiente in cui si trova e indichi la posizione dell’oggetto all’interno della
fotografia. Si potranno poi specificare delle caratteristiche che permetteranno di
individuarlo in una successiva ricerca. L’applicazione dovrà quindi consentire un
inserimento agevole di fotografie e oggetti e dovrà permettere la ricerca della loro
posizione con l’immissione da parte dell’utente di alcune parole chiave.
Si crede che un approccio di questo tipo al problema dell’organizzazione degli ambienti sia
innovativo. Attualmente è comune trovare un’organizzazione gerarchica dei magazzini: si
utilizza una sorta di schedario che indica in quale sezione si trova l’oggetto cercato (es.
edificio C, magazzino 5, scaffale 6, mensola B, sezione 9/F). L’idea di introdurre delle
fotografie per supportare la ricerca garantisce al personale un immediato impatto visivo,
consentendogli di individuare immediatamente l’oggetto anche se ancora non si trova sul
posto. Si mira quindi a sfruttare in maniera diversa la memoria sensoriale visiva a breve
termine delle persone, consentendo la percezione dello spazio, delle posizioni e dei colori
invece di una sequenza di numeri e lettere.
Si consideri che l’applicazione è stata interamente ideata dal candidato e tutto il lavoro
riguardante questo progetto è a suo carico.
2
Si presenta un riassunto dei seguenti quattro capitoli.
Il primo espone le possibili strade da seguire per la realizzazione del progetto, tenendo in
considerazione gli eventuali hardware a cui l’applicazione potrebbe esser destinata. Si
effettuano e si giustificano le scelte fatte e vengono evidenziati gli obiettivi della tesi. Il
capitolo si conclude con la rassegna delle tecnologie software utilizzate.
Il secondo contiene l’intera documentazione relativa al database. Essa comprende tutte le
fasi della progettazione. Nella parte finale del capitolo si trova la descrizione delle viste, di
alcuni trigger e stored procedure che verranno esposte all’applicazione.
La prima parte del terzo capitolo è dedicata alla presentazione dell’interfaccia grafica:
vengono mostrate e commentate alcune schermate e si spiega come devono essere
utilizzate dall’utente. La seconda parte è riservata all’implementazione dell’applicazione e
all’esposizione di alcuni frammenti del codice sorgente.
Il quarto e ultimo capitolo contiene la quantizzazione del lavoro svolto in termini di numero
di righe di codice scritte seguite da alcune considerazioni finali sul progetto.
3
1. Analisi
Per poter realizzare un progetto di questo tipo, la prima scelta da effettuare è la tecnologia
su cui sviluppare l’applicazione.
Si pensa che la resa migliore si avrebbe utilizzando dispositivi mobili, quali tablet o
smartphone, poiché la fase di inserimento sarebbe notevolmente agevolata. Si potrebbero
infatti scattare fotografie agli ambienti direttamente dalla fotocamera del dispositivo
(ancora meglio se in modalità panoramica) e aggiungere “al volo” un oggetto
semplicemente toccando un punto del touchscreen. Tuttavia l’applicazione potrebbe
essere fruibile anche da un computer qualsiasi, per l’inserimento si potrebbero usare
fotografie scattate in precedenza.
Non ci sarebbero invece grosse differenze per quanto riguarda la fase di ricerca. In
entrambi i casi si devono digitare (o eventualmente pronunciare) i valori dei parametri di
ricerca dell’oggetto voluto.
Poiché si mira a divulgare l’applicazione il più possibile si deve tener conto della diffusione
dei prodotti e dei sistemi operativi disponibili e quindi di quante volte il codice deve essere
per la maggior parte riscritto.
Un’altra scelta da effettuare immediatamente è dove memorizzare i dati delle fotografie,
oggetti, ambienti etc., di cui l’applicazione ha bisogno per funzionare. Le alternative sono
le seguenti:
- Ogni versione dell’applicazione che viene distribuita deve essere accompagnata da
una sua base di dati, la cui proprietà fisica è e rimane dell’organizzazione. In questo
modo l’accesso ai dati potrebbe avvenire attraverso una rete interna privata.
- I dati di tutte le organizzazioni sono conservati in un unico database centralizzato
che viene acceduto attraverso Internet.
4
1.1. Prime decisioni
Considerata la difficoltà, almeno in una fase di sviluppo iniziale, di dover scrivere la stessa
applicazione più di una volta per renderla compatibile con la maggior parte dei dispositivi,
si decide di cominciare con un’applicazione web, accessibile e fruibile da tutti attraverso
uno qualsiasi dei principali (più diffusi) browser web moderni. In un secondo momento si
può pensare di sviluppare applicazioni indipendenti, dedicate ai singoli dispositivi.
Per quanto riguarda la scelta di dove salvare i dati, si decide per un unico database
centrale.
Ciò comporta degli svantaggi, poiché bisognerà occuparsi di mantenere attiva una base di
dati di notevoli dimensioni, con tutti gli oneri di gestione che ne comporta. Inoltre le
organizzazioni che decidono di usufruire dell’applicazione devono fare un “atto di fede” nei
confronti dell’amministrazione del database: dovranno infatti fidarsi che i loro dati e
fotografie rimangano privati (se così desiderano) e in buone mani. Infine è richiesta una
costante connessione ad Internet, ma questo ad oggi non è un problema che spaventa più
di tanto.
I vantaggi che si ottengono sono superiori. Si deve pensare che affiancare un database
alla distribuzione dell’applicazione, e quindi la creazione di una rete interna, è quasi
sempre un impegno indesiderato per l’organizzazione. L’utilizzo dell’applicazione sarebbe
possibile solo quando si è sotto la copertura di tale rete e, cosa di gran lunga più
importante, si rinuncerebbe completamente al lato “social” dell’applicazione, che sarebbe
orientata solo all’azienda e non ad una persona qualsiasi.
5
1.2. Obiettivi
L’obiettivo principale è quello di creare un database di supporto all’applicazione web. Esso
deve essere ampiamente documentato in tutte le fasi della sua progettazione.
Poiché si vuole lasciare aperta la possibilità di creare applicazioni client ad hoc (una per
ogni sistema operativo) che andranno ad interagire con lo stesso database, particolare
importanza deve esser data alla conservazione dell’integrità dei dati.
Si deve prevedere che il database possa crescere rapidamente di dimensioni dal
momento che dovrà memorizzare i dati di tutte le organizzazioni. Si deve quindi eseguire
un’attenta analisi dei costi sulla base di dati di carico ipotetici e giustificare le scelte fatte
relativamente alla sua struttura.
L’obiettivo secondario è realizzare un prototipo dell’applicazione: si deve simulare la fase
di ricerca di un oggetto ad autenticazione del client già avvenuta.
1.3. Tecnologie software utilizzate
Viste le competenze acquisite dal candidato nel corso di database, il modello dei dati
scelto è quello relazionale, il motore database è “Microsoft SQL Server” e lo strumento di
configurazione e gestione utilizzato è “SQL Management Studio” (versioni 2008 R2).
L’accesso ai dati è previsto con “ADO.NET”, poiché fornisce un accesso ottimale quando
si utilizza Microsoft SQL Server ed è progettato per accessi disconnessi. Ciò è appropriato
perché il tipo di applicazione web che si vuole realizzare sarà di tipo “mordi e fuggi”,
ovvero chiederà i dati di cui ha bisogno in quel momento, il browser li elaborerà e
successivamente effettuerà una nuova richiesta asincrona. Mantenere aperta una
connessione in questo tipo di configurazione implicherebbe un inutile consumo di risorse.
L’ambiente di sviluppo utilizzato è “Microsoft Visual Studio 2012”.
6
Tra il “Visual Basic” e il “C#” si è preferito scegliere il secondo, poiché è il linguaggio
object-oriented che più somiglia come sintassi a “JAVA”, studiato nel corso di
programmazione.
Per quanto riguarda l’interfaccia utente, essa è suddivisa in tre livelli (o layer):
1 Il layer strutturale
Rappresenta lo scheletro della pagina web. I marcatori (o “tag”) che lo compongono
stabiliscono delle regole sulla sua struttura e danno già un indizio su come questa verrà
formattata e modificata a seguito di un azione dell’utente. Si decide di utilizzare l’”HTML5”
poiché mette a disposizione dei nuovi elementi pratici per interagire con fotografie, mappe
e geolocalizzazioni.
L’HTML5 però è ancora lontano da essere uno standard e per gli scopi prefissati, si dovrà
prestare attenzione a mantenere la compatibilità con tutti i browser di maggiore diffusione.
2 Il layer di presentazione
È composto dai fogli di stile (CSS) della pagina web che sono lo strumento fondamentale
per definire come un documento HTML deve essere visualizzato da un browser. Anche in
questo caso si utilizzeranno solamente quelle proprietà che sono supportate dai browser
in modo standard.
3 Il layer di interazione
È composto da tutti gli script che permettono ad un utente di interagire con la pagina web.
Si utilizza il linguaggio di scripting “JavaScript” e la libreria “jQuery” per la manipolazione
del “DOM”, per la gestione degli eventi, e la generazione delle HTTP Request.
Anche se si tratta di una tecnica per lo sviluppo di applicazioni web e non di una
tecnologia, sembra opportuno specificare in questo capitolo che si vuole utilizzare “Ajax”
per permettere una maggior interattività con l’utente.
Per lo scambio dei dati, almeno in un primo momento, non si utilizzerà l’XML bensì la
JSON poiché essa è concisa e conveniente per la programmazione orientata ad oggetti in
JavaScript. Tuttavia la notazione presenta dei limiti: è un formato testuale minimale tramite
il quale è possibile serializzare e deserializzare solo oggetti, stringhe, numeri, valori
booleani e null; per questo motivo si pensa che in futuro si adopererà l’XML.
7
2. Documentazione del database
2.1. Raccolta dei requisiti
In questa fase, che precede la progettazione, è necessario elencare e descrivere in
maniera approfondita i dati di interesse per l’applicativo. Si elencano in seguito le
operazioni principali effettuate da un utente e si fanno delle stime sulla loro frequenza.
2.1.1. Descrizione
Si vuole realizzare un database per un’applicazione web per l’organizzazione di ambienti
di lavoro. Con l’espressione ambienti di lavoro si intente qualsiasi luogo che si desidera
organizzare: un magazzino, un’officina, un ripiano etc.
È previsto che l’utente di questa applicazione scatti delle fotografie agli ambienti, le
carichi sul sito e registri delle informazioni sugli oggetti in esse contenuti (in particolare la
posizione) e in un secondo momento li ricerchi.
Non si spiega in questo capitolo come tali informazioni vengano inserite dall’utente (si
veda il capitolo 3.1.).
In fase di registrazione al sito, ogni user deve dichiarare nome, cognome, sesso, data di
nascita, email e password di accesso. Tuttavia, per motivi di sicurezza, le password non
sono salvate nel database.
Più utenti potrebbero voler condividere le stesse fotografie e oggetti, per questo motivo
possono unirsi a formare delle company. Tali fotografie e oggetti diventano di proprietà
della company e non più dell’utente. Un utente può quindi appartenere a nessuna, una o
8
più company. Solo gli utenti registrati ad una company possono vedere le fotografie e
gli oggetti che le appartengono e soltanto alcuni tra loro (gli amministratori) sono
autorizzati all’inserimento e alla modifica. Ogni company dovrà averne almeno un
amministratore.
Le company si dividono in due categorie:
1 Private (caso tipico). La registrazione è su invito di un utente già iscritto.
2 Aperte. Tutti gli utenti possono registrarsi.
Per ognuna di esse si devono conoscere gli utenti che ne fanno parte e i loro privilegi
d’accesso, un nome, la data di creazione ed eventualmente una descrizione testuale.
Per ogni fotografia caricata si desidera salvare la data di caricamento e il nome del posto
preciso in cui è stata scattata (es. magazzino n.3), l’utente o la company a cui
appartiene, gli oggetti che contiene, un’eventuale descrizione per permettere il
salvataggio di informazioni aggiuntive, l’url relativo dei file immagine sul server
(un’immagine sarà salvata sul server in più formati per accelerare i caricamenti delle
pagine web). Uno stesso luogo preciso può avere diverse fotografie (un magazzino
abbastanza grande o contenente più scaffali). Per futuri sviluppi dell’applicazione si
desidera memorizzare le coordinate “geotag” dell’immagine.
Per ogni oggetto si vogliono salvare le caratteristiche che serviranno a trovarlo.
Obbligatoriamente si vuole conoscere il nome, l’utente o la company a cui appartiene, la
foto in cui è e quelle in cui era inserito con relative date, posizioni e amministratori che
hanno fatto lo spostamento. Opzionalmente potrebbe esser specificato il colore, il
materiale, una descrizione e una classe di utilità. Futuri sviluppi dell’applicazione
prevedono che l’amministrazione di una company possa definire nuovi parametri di
ricerca (es. marca, modello, dimensioni etc.) e ogni parametro possa avere più di un
valore associato (es. in un magazzino di pezzi di ricambio per automobili potrebbe esser
utile specificare, per ogni pezzo, i modelli di automobile su cui si adatta).
Per quanto riguarda la posizione non si possono salvare le coordinate dell’oggetto perché
si avrebbe una dipendenza con le dimensioni dell’immagine. Per esigenze di spazio sul
server, le immagini potrebbero esser ridimensionate e si renderebbe quindi necessario
andare a modificare tutte le coordinate.
9
Si decide quindi di salvare i rapporti
e
. sono nell’angolo
superiore sinistro. Inoltre è previsto che più oggetti si trovino molto vicini tra loro o nello
stesso contenitore, in questi casi avranno la stessa posizione.
2.1.2. In dettaglio
Un oggetto o una fotografia appartengono a un utente o (esclusivo) a una company.
Un utente o una company che possiede una fotografia possiede anche gli oggetti inseriti al
suo interno. È una ridondanza che verrà analizzata nelle pagine seguenti.
Spostare un oggetto da una fotografia a un’altra e definire parametri di ricerca aggiuntivi
sono operazioni riservate alle company.
Se un utente o una company vengono cancellati, tutte le fotografie di loro proprietà
vengono cancellate.
Se una fotografia viene cancellata, tutti gli oggetti in essa contenuti devono essere
cancellati.
Se un oggetto viene cancellato tutti i suoi inserimenti vengono cancellati.
Un utente può inserire un oggetto in una fotografia solo se è di sua proprietà o se è
amministratore della company a cui essa appartiene.
Quando un amministratore abbandona una company, i suoi inserimenti rimangono ma non
sono più associabili a lui.
Se una company viene abbandonata da tutti gli utenti, essa viene cancellata.
Un utente che non effettua nessuna operazione da più di sei mesi è da considerarsi non
attivo.
10
2.1.3. Requisiti di carico
L’utente come prima operazione deve registrarsi al sito. Può poi cominciare a caricare
delle fotografie, inserire oggetti e creare delle company e fare delle ricerche. Poiché
l’applicazione è ancora in fase di sviluppo non sono disponibili delle medie sul numero di
operazioni effettuate al giorno da ogni utenza. Tuttavia si possono fare delle stime.
Si considera dapprima una company di dimensioni ridotte (5 user), per esempio una
piccola attività o una famiglia che desidera organizzare piccoli vani, scaffali o ripiani. Si
pensa che nei primi giorni di utilizzo il numero di caricamenti sarà elevato: nel primo mese
8 fotografie e 20 oggetti per fotografia. Dopo il primo mese i caricamenti scendono:
verranno modificati, cancellati o aggiunti al massimo 10 oggetti al mese e 1 foto ogni due.
Lo stesso vale per una company di grandi dimensioni (20 user) che potrebbe occuparsi
per esempio dell’organizzazione di un magazzino di pezzi di ricambio per automobili. Si
crede che nei primi 3 mesi vengano caricate 50 fotografie e 1000+ oggetti e nei mesi
successivi si effettuino modifiche a 4 foto e a 50 oggetti circa.
Per quanto riguarda le ricerche di un oggetto si pensa che un utente di una piccola
company effettui in media 6 ricerche al giorno mentre uno di una grande company ne
faccia 20.
Ottimisticamente per il primo anno di vita dell’applicazione, si supponga di dover gestire
informazioni per 25 000 user, considerando che il 10% di questi non fa parte di nessuna
company e che il 75% delle company siano di piccole dimensioni.
11
2.2. Progettazione concettuale
2.2.1. Glossario dei termini
TERMINE DESCRIZIONE SINONIMI COLLEGAMENTI
Ambiente di lavoro Luogo preciso in cui vengono scattate le
fotografie
Luogo Fotografia
User Inteso come subject, persona ad un certo
calcolatore provvista di credenziali
d’accesso
User Fotografia, Company,
Oggetto
Fotografia Scattata all’ambiente che si desidera
organizzare
Foto Ambiente, User,
Company, Oggetto
Oggetto Sono contenuti nelle fotografie, provvisti
di caratteristiche che permettono di
individuarli
User, Fotografia
Company Formate da più utenti che desiderano
condividere le fotografie
User, Fotografia,
Oggetto
Tabella 1
2.2.2. Strutturazione dei requisiti
Frasi di carattere generale
Si vuole realizzare un database per un’applicazione web per l’organizzazione di
ambienti di lavoro.
È previsto che l’utente di questa applicazione scatti delle fotografie agli ambienti,
le carichi sul sito e registri delle informazioni sugli oggetti in esse contenuti (in
particolare la posizione) e in un secondo momento li ricerchi.
12
Frasi relative agli ambienti
Con l’espressione ambienti di lavoro si intente qualsiasi luogo che si desidera
organizzare: un magazzino, un’officina, un ripiano etc.
Uno stesso luogo preciso può avere diverse fotografie (un magazzino abbastanza
grande o contenente più scaffali).
Frasi relative agli utenti
In fase di registrazione al sito, ogni user deve dichiarare nome, cognome, sesso,
data di nascita, email e password di accesso. Tuttavia, per motivi di sicurezza, le
password non sono salvate nel database (si veda il documento che descrive la
gestione delle credenziali).
Più utenti potrebbero voler condividere le stesse fotografie e oggetti, per questo
motivo possono unirsi a formare delle company. Tali fotografie e oggetti
diventano di proprietà della company e non più dell’utente. Un utente può quindi
appartenere a nessuna, una o più company. Solo gli utenti registrati ad una
company possono vedere le fotografie e gli oggetti che le appartengono e
soltanto alcuni tra loro (gli amministratori) sono autorizzati all’inserimento e alla
modifica.
Frasi relative alle fotografie
Più utenti potrebbero voler condividere le stesse fotografie e oggetti, per questo
motivo possono unirsi a formare delle company. Tali fotografie e oggetti
diventano di proprietà della company e non più dell’utente.
Per ogni fotografia caricata si desidera salvare la data di caricamento e il nome del
posto preciso in cui è stata scattata (es. magazzino n.3), l’utente o la company a
cui appartiene, gli oggetti che contiene, un’eventuale descrizione per permettere il
salvataggio di informazioni aggiuntive, l’url relativo dei file immagine sul server
(un’immagine sarà salvata sul server in più formati per accelerare i caricamenti
delle pagine web). Uno stesso luogo preciso può avere diverse fotografie (un
magazzino abbastanza grande o contenente più scaffali). Per futuri sviluppi
dell’applicazione si desidera memorizzare le coordinate “geotag” dell’immagine.
13
Frasi relative agli oggetti
Più utenti potrebbero voler condividere le stesse fotografie e oggetti, per questo
motivo possono unirsi a formare delle company. Tali fotografie e oggetti
diventano di proprietà della company e non più dell’utente.
Per ogni oggetto si vogliono salvare le caratteristiche che serviranno a trovarlo.
Obbligatoriamente si vuole conoscere il nome, l’utente o la company a cui
appartiene, la foto in cui è e quelle in cui era inserito con relative date, posizioni e
amministratori che hanno fatto lo spostamento. Opzionalmente potrebbe esser
specificato il colore, il materiale, una descrizione e una classe di utilità. Futuri
sviluppi dell’applicazione prevedono che l’amministrazione di una company possa
definire nuovi parametri di ricerca (es. marca, modello, dimensioni etc.) e ogni
parametro possa avere più di un valore associato (es. in un magazzino di pezzi di
ricambio per automobili potrebbe esser utile specificare, per ogni pezzo, i modelli di
automobile su cui si adatta).
Per quanto riguarda la posizione non si possono salvare le coordinate dell’oggetto
perché si avrebbe una dipendenza con le dimensioni dell’immagine. Per esigenze
di spazio sul server, le immagini potrebbero esser ridimensionate e si renderebbe
quindi necessario andare a modificare tutte le coordinate. Si decide quindi di
salvare i rapporti
e
.
sono nell’angolo superiore sinistro. Inoltre è previsto che più oggetti si
trovino molto vicini tra loro o nello stesso contenitore, in questi casi avranno la
stessa posizione.
Frasi relative alle company
- Più utenti potrebbero voler condividere le stesse fotografie e oggetti, per questo
motivo possono unirsi a formare delle company. Tali fotografie e oggetti
diventano di proprietà della company e non più dell’utente. Un utente può quindi
appartenere a nessuna, una o più company. Solo gli utenti registrati ad una
company possono vedere le fotografie e gli oggetti che le appartengono e
soltanto alcuni tra loro (gli amministratori) sono autorizzati all’inserimento e alla
modifica. Ogni company dovrà averne almeno un amministratore.
14
- Le company si dividono in due categorie:
1. Private (caso tipico). La registrazione è su invito di un utente già iscritto.
2. Aperte. Tutti gli utenti possono registrarsi.
Per ognuna di esse si devono conoscere gli utenti che ne fanno parte e i loro
privilegi d’accesso, un nome, la data di creazione ed eventualmente una
descrizione testuale.
2.2.3. Schema scheletro
FOTOGRAFIAFOTOGRAFIAUSERUSERUSER
COMPANYCOMPANYCOMPANY
OGGETTOOGGETTOPROPRIETÀ
O - U
PART - OF ADMIN
INSERIMENTO
PROPRIETÀ
F - C
LOCALIZAMBIENTEAMBIENTE
PROPRIETÀ
U - F
PROPRIETÀ
O - C
Figura 1
Si decide di utilizzare una strategia di progetto mista: si individuano i concetti principali, si
realizza uno schema scheletro e, partendo da questo, si procede per raffinamenti. Tale
strategia è simile all’inside-out, la differenza è che si parte da uno schema scheletro e non
da un unico concetto.
15
2.2.3.1. Raffinamento entità user e company
USERUSERUSER
ATTIVOATTIVONON
ATTIVO
NON
ATTIVO
COMPANYCOMPANYCOMPANY
APERTAAPERTA PRIVATAPRIVATA
Figura 2
Si individuano due generalizzazioni entrambe totali ed esclusive e ognuna con due
specializzazioni. Gli utenti si dividono tra attivi e non, le company tra aperte e private.
2.2.3.2. Raffinamento associazione inserimento
0 - I
FOTOGRAFIAFOTOGRAFIA
INSERIMENTOINSERIMENTO
USERUSERUSER
OGGETTOOGGETTO
I - U
I - F
0 - I
FOTOGRAFIAFOTOGRAFIA
INSERIMENTOINSERIMENTO
ULTIMOULTIMO PASSATOPASSATO
USERUSERUSEROGGETTOOGGETTO
0 - U
I - U
I - F
Figura 3
Si effettua la reificazione dell’associazione ternaria inserimento e la storicizzazione del
concetto. Verrà analizzato più avanti se sia conveniente farlo. Anche qui si viene a creare
una generalizzazione totale ed esclusiva con due specializzazioni: un inserimento può
essere l’ultimo avvenuto oppure può esser seguito da uno più recente. Da notare che se
esiste un inserimento passato deve necessariamente esistere un ultimo inserimento.
16
2.2.3.3. Ulteriori entità e associazioni
COMPANYCOMPANYCOMPANYOGGETTOOGGETTO
VALOREVALOREAGGIUNTA PARAMETROPARAMETROCOMPL DEFINIZIONE
PROPRIETÀ
O - C
Figura 4
Per dare la possibilità alle company di definire parametri di ricerca aggiuntivi per i propri
oggetti si aggiungono le entità parametro e valore e le relative associazioni.
2.2.4. Schema E – R finale
0 - I
FOTOGRAFIAFOTOGRAFIA
INSERIMENTOINSERIMENTO
ULTIMOULTIMO PASSATOPASSATO
USERUSERUSER
ATTIVOATTIVONON
ATTIVO
NON
ATTIVO
COMPANYCOMPANYCOMPANY
APERTAAPERTA PRIVATAPRIVATA
OGGETTOOGGETTOPROPRIETÀ
O - U
0 - U
VALOREVALOREAGGIUNTA PARAMETROPARAMETROCOMPL
DEFINIZIONE
PART - OF
ADMIN
I - U
I - F
PROPRIETÀ
F - C
LOCALIZ AMBIENTEAMBIENTE
PROPRIETÀ
O - C
PROPRIETÀ
U - F
Figura 5
17
2.2.5. Analisi delle entità
AMBIENTE
AmbienteID Identificativo univoco assegnato ad ogni ambiente.*
Nome Nome del luogo preciso in cui sono state scattate le foto.
Descrizione Informazioni aggiuntive sull’ambiente.
Tabella 2
USER
Email Un email dell’utente.
Nome Nome proprio dell’utente.
Cognome Cognome.
Sesso Sesso.
DataNascita Data di nascita.
DataRegistrazione Data in cui l’utente ha effettuato la registrazione.
Tabella 3
ATTIVO
DataUltimaOperazione Indica quando un utente ha effettuato la sua ultima operazione di un utente.
Tabella 4
NON ATTIVO
Nessun attributo.
Tabella 5
FOTOGRAFIA
DataCaricamento Data in cui la foto è stata caricata sul server.
Descrizione Descrizione per raccogliere informazioni aggiuntive sulla foto.
URL Percorso dei file immagine sul server.
Geotag Sono le coordinate GPS che indicano il punto dove la foto è stata scattata.
Num Numera le foto scattate nello stesso ambiente.
Tabella 6
OGGETTO
OggettoID Identificativo univoco assegnato ad ogni oggetto.*
Nome Nome dell’oggetto.
Colore Colore principale dell’oggetto.**
ClasseUtilità Descrive in una parola l’utilità dell’oggetto.**
Materiale Materiale principale dell’oggetto.**
Descrizione Informazioni sull’oggetto.
Tabella 7
18
COMPANY
CompanyID Identificativo univoco assegnato ad ogni company.*
Nome Nome della company.
DataCreazione Data in cui è stata creata la company
Descrizione Informazioni sulla company.
Tabella 8
APERTA
Nessun attributo.
Tabella 9
PRIVATA
Nessun attributo.
Tabella 10
INSERIMENTO
Data Data con precisione sui secondi. Rappresenta quando è avvenuto l’inserimento.
Posizione Rappresenta la posizione dell’oggetto nella fotografia. (Attributo composto).
Tabella 11
ULTIMO
Nessun attributo.
Tabella 12
PASSATO
Nessun attributo.
Tabella 13
PARAMETRO
Num Numera i parametri di una stessa company.
Nome Nome del parametro.
Descrizione Informazioni aggiuntive.
NumMaxValori Numero massimo dei valori che possono esser associati a quel parametro.
Tabella 14
VALORE
Num Numera i valori associati ad uno stesso parametro.
Val È una stringa che contiene il valore aggiunto all’oggetto.
Tabella 15
* I codici sono introdotti subito quando gli attributi non sono sufficienti per l’identificazione di un’istanza dell’entità o sono opzionali.
** Potrebbero esser considerati attributi multivalore e quindi formare delle entità a sé stanti, tuttavia si preferisce, almeno per il momento, mantenere l’applicazione semplice e snellire la fase di caricamento di un oggetto comune. Se poi un’azienda desidera specificare più valori per un parametro può farlo utilizzando la gestione di parametri aggiuntivi.
19
2.2.6. Analisi delle associazioni e delle cardinalità
OGGETTO – INSERIMENTO
Collega le entità oggetto e inserimento in modo da specificare quale sia l’oggetto inserito.
Cardinalità Uno a molti: un oggetto può avere molti inserimenti nel corso del tempo ma un
inserimento si riferisce a un solo oggetto.
Tabella 16
OGGETTO – ULTIMO INSERIMENTO
Collega le entità oggetto e ultimo inserimento in modo da specificare quale sia l’oggetto che deve
essere inserito.
Cardinalità Uno a uno: un oggetto deve avere un unico ultimo inserimento e un ultimo
inserimento deve riferirsi a un solo oggetto.
Tabella 17
INSERIMENTO – FOTOGRAFIA
Collega le entità inserimento e fotografia per specificare dove un oggetto è stato inserito.
Cardinalità Uno a molti: un inserimento deve riferirsi ad una sola fotografia mentre una
fotografia può avere più inserimenti
Tabella 18
INSERIMENTO – USER
Collega le entità inserimento e user. Precisa chi sia l’utente che ha effettuato l’inserimento.
Cardinalità Uno a molti: un inserimento può essere fatto da un utente solo, un utente può
effettuare più inserimenti.
Tabella 19
PROPRIETÀ OGGETTO – USER
Collega le entità oggetto e user. Precisa chi sia l’utente proprietario dell’oggetto.
Cardinalità Uno a molti: un oggetto può appartenere a un solo utente e un utente può essere
proprietario di più oggetti.
Tabella 20
PROPRIETÀ OGGETTO – COMPANY
Collega le entità oggetto e company. Precisa chi sia la company proprietaria dell’oggetto.
Cardinalità Uno a molti: un oggetto può appartenere a una sola company e una company può
essere proprietaria di più oggetti.
Tabella 21
AGGIUNTA
Collega le entità oggetto e valore. Specifica quali siano i valori aggiuntivi degli oggetti.
Cardinalità Uno a molti: ad un oggetto possono esser aggiunti molti valori ma un valore si
riferisce ad un solo oggetto.
Tabella 22
20
COMPLETAMENTO
Collega le entità valore e parametro. Serve per associare i parametri ai relativi valori.
Cardinalità Uno a molti: ad un parametro in generale possono esser associati diversi valori
(numero massimo specificato dall’attributo NumMaxValori dell’entità
parametro). Un valore invece corrisponde sempre ad un solo parametro.
Tabella 23
DEFINIZIONE
Collega le entità parametro e company. Specifica quale company abbia definito i parametri aggiuntivi
di ricerca.
Cardinalità Uno a molti: un parametro è definito da una sola company, una company può
definire più parametri.
Tabella 24
PROPRIETÀ USER – FOTOGRAFIA
Collega le entità user e fotografia. Precisa chi sia l’utente proprietario della fotografia.
Cardinalità Uno a molti: un utente può essere proprietario di più fotografie e una fotografia
può appartenere ad un solo utente.
Tabella 25
ADMIN
Collega le entità user e company. Specifica chi siano gli utenti di una company con il permesso di
modifica.
Cardinalità Molti a molti: un utente può esser amministratore di molte company e una
company può avere più di un amministratore.
Tabella 26
PART – OF
Collega le entità user e company. Specifica chi siano gli utenti di una company.
Cardinalità Molti a molti: un utente può far parte di molte company e una company può
esser composta da più utenti.
Tabella 27
PROPRIETÀ FOTOGRAFIA – COMPANY
Collega le entità fotografia e company. Precisa chi sia la company proprietaria della fotografia. Cardinalità Uno a molti: una fotografia può appartenere ad una sola company e un company
può essere proprietaria di più fotografie.
Tabella 28
LOCALIZZAZIONE
Collega le entità fotografia e ambiente. Specifica in quale ambiente sia stata scattata la fotografia.
Cardinalità Uno a molti: una fotografia può esser stata scattata solo in un posto mentre uno
stesso ambiente può avere diverse fotografie.
Tabella 29
21
2.2.7. Regole di business
1. Un oggetto o una fotografia devono appartenere a un utente o (esclusivo) a una
company.
2. Un utente o una company che possiede una fotografia deve possedere anche gli
oggetti inseriti al suo interno.
3. Un oggetto reinserito (spostato) deve appartenere ad una company.
4. Se un utente o una company vengono cancellati, tutte le fotografie di loro proprietà
devono essere cancellate.
5. Se una fotografia viene cancellata, tutti gli oggetti in essa contenuti devono essere
cancellati.
6. Se un oggetto viene cancellato tutti i suoi inserimenti devono esser cancellati
(cascade delete).
7. Un ambiente deve avere almeno una fotografia.
8. Un utente che inserisce un oggetto in una fotografia deve possederla oppure deve
essere amministratore della company a cui essa appartiene.
9. Quando un amministratore abbandona una company, i suoi inserimenti rimangono
ma non devono essere più associabili a lui.
10. Se una company viene abbandonata da tutti gli utenti deve esser cancellata.
11. La data di fine attività di un utente non attivo deve essere inferiore alla data del
sistema – 6 mesi.
12. Il numero massimo di valori aggiunti ad un oggetto relativi ad un parametro non
deve superare il numero specificato in NumMaxValori di quel parametro.
22
2.2.8. Schema E – R finale con attributi e cardinalità
0 - I
FOTOGRAFIAFOTOGRAFIA
INSERIMENTOINSERIMENTO
ULTIMOULTIMO PASSATOPASSATO
USERUSERUSER
ATTIVOATTIVONON
ATTIVO
NON
ATTIVO
COMPANYCOMPANYCOMPANY
APERTAAPERTA PRIVATAPRIVATA
OGGETTOOGGETTOPROPRIETÀ
O - U
0 - U
VALOREVALOREAGGIUNTA PARAMETROPARAMETROCOMPL
DEFINIZIONE
PART - OF
ADMIN
I - U
I - F
PROPRIETÀ
F - C
LOCALIZ AMBIENTEAMBIENTE
PROPRIETÀ
O - C
PROPRIETÀ
U - F
AmbienteID Nome Descrizione
NomeDataNascita
DataRegistrazione
Cognome Sesso
DataUltimaOperazione
URL DataCaricamento
Num
Geotag DescrizioneNome Colore
OggettoID
ClasseUtilità Materiale
Descrizione
Nome Descrizione
DataCreazione
CompanyID
Data
PosizioneX Y
Val
NumMaxValori
Descrizione
Num
Nome
1, 11
, N
1, 11
, 1
1, 1
0, 1
0, N
0, N
0, 1
0, N
0, 1
0, N
0, N
1, 1
1, 1
0, N
1, 1
0, N
0, N
0, 1
0, N
1, N
1, N
0, N
0, N
0, 1
1, 1
1, N
Num
Figura 6
23
2.3. Progettazione logica
2.3.1. Tavola dei volumi
ENTITY VOLUME RELATIONSHIP VOLUME
Ambiente 22 000 Oggetto – Inserimento 2 190 000
User 25 000 Oggetto – Ultimo 2 000 000
Attivo 24 000 Inserimento – Foto 2 190 000
Non attivo 1 000 Inserimento – User 2 190 000
Fotografia 110 000 Proprietà O – U 150 000
Oggetto 2 000 000 Proprietà O – C 1 850 000
Company 3 200 Aggiunta 1 110 000
Aperta 200 Completamento 1 110 000
Privata 3 000 Definizione 1 900
Inserimento 2 190 000 Proprietà U – F 10 000
Ultimo 2 000 000 Admin 10 000
Passato 190 000 Part – of 22 500
Parametro 1 900 Proprietà F – C 100 000
Valore 1 110 000 Localizzazione 110 000
Tabella 30
I numeri della Tabella 30 sono relativi al primo anno di utilizzo dell’applicazione. Per
ottenerli è stata fatta una media pesata tra company di piccole e grandi dimensioni
considerando che le prime sono il 75% del totale. Si ottiene così che una company è
composta in media da 7 utenti, ha 32 foto e 576 oggetti. Si pensa che ogni ambiente
conterrà circa 5 foto, che il 10% degli oggetti delle company verrà spostato dalla posizione
originale e che il 20% delle company aggiungerà 3 parametri di ricerca. Infine si considera
che le company aperte e private saranno in rapporto 1 : 15.
24
2.3.2. Tavola delle operazioni
OPERAZIONI TIPO FREQUENZA
Ricerca dell’ultima posizione di un oggetto I 3 / secondo
Ricerca delle posizioni precedenti di un oggetto I 2 / minuto
Inserimento di un oggetto I 4 / minuto
Inserimento di una fotografia I 13 / ora
Registrazione nuovo user I 3 / ora
Registrazione nuova company I 9 / giorno
Trova gli utenti la cui data dell’ultima operazione risale a più di 6 mesi fa
e considerali non attivi
B 1 / mese
Tabella 31
2.3.3. Tavole degli accessi
2.3.3.1. Operazione 1
Schema dell’operazione più frequente: ricerca dell’ultima posizione di un oggetto.
L’operazione interattiva si divide in più parti:
Richiesta:
1. Un utente che appartiene a una company specifica alcune caratteristiche
dell’oggetto che vuole cercare.
Risposta:
1. Tra gli oggetti della company ne vengono identificati uno o più con le
caratteristiche specificate. (1)
2. Si cercano le posizioni e le fotografie che contengono gli oggetti trovati. (2)
25
0 - I
FOTOGRAFIAFOTOGRAFIA
INSERIMENTOINSERIMENTO
ULTIMOULTIMO PASSATOPASSATO
USERUSERUSER
ATTIVOATTIVONON
ATTIVO
NON
ATTIVO
COMPANYCOMPANYCOMPANY
APERTAAPERTA PRIVATAPRIVATA
OGGETTOOGGETTOPROPRIETÀ
O - U
0 - U
VALOREVALOREAGGIUNTA PARAMETROPARAMETROCOMPL
DEFINIZIONE
PART - OF
ADMIN
I - U
I - F
PROPRIETÀ
F - C
LOCALIZ AMBIENTEAMBIENTE
PROPRIETÀ
O - C
PROPRIETÀ
U - F
AmbienteID Nome Descrizione
NomeDataNascita
DataRegistrazione
Cognome Sesso
DataUltimaOperazione
URL DataCaricamento
Num
Geotag DescrizioneNome Colore
OggettoID
ClasseUtilità Materiale
Descrizione
Nome Descrizione
DataCreazione
CompanyID
Data
PosizioneX Y
Val
NumMaxValori
Descrizione
Num
Nome
1, 1
1, N
1, 1
1, 1
1, 1
0, 1
0, N
0, N
0, 1
0, N
0, 1
0, N
0, N
1, 1
1, 1
0, N
1, 1
0, N
0, N
0, 1
0, N
1, N
1, N
0, N
0, N
0, 1
1, 1
1, N
Num
Figura 7
L’operazione è analoga se l’oggetto appartiene ad un utente e non ad una company oppure
se si ricercano lo posizioni precedenti di un oggetto.
RICERCA DELL’ULTIMA POSIZIONE DI UN OGGETTO
CONCETTO COSTRUTTO ACCESSI TIPO
Oggetto E 1 L
Proprietà C – O R 1 L
Company E 1 L
O – U R 1 L
Ultimo inserimento E 1 L
I – F R 1 L
Fotografia E 1 L
Aggiunta R 1+ L
Valore E 1+ L
Completamento R 1+ L
Tabella 32
(2)
(1)
(2)
(1)
26
(3)
(2)
(2)
(3)
2.3.3.2. Operazione 2
Schema dell’operazione: inserimento di un oggetto. L’operazione si divide in:
Trova tutte le fotografie della company e fanne scegliere una all’utente. (1)
Scrivi un nuovo oggetto (eventualmente con valori aggiuntivi). (2)
Scrivi un nuovo inserimento (eventualmente sposta l’inserimento precedente). (3)
0 - I
FOTOGRAFIAFOTOGRAFIA
INSERIMENTOINSERIMENTO
ULTIMOULTIMO PASSATOPASSATO
USERUSERUSER
ATTIVOATTIVONON
ATTIVO
NON
ATTIVO
COMPANYCOMPANYCOMPANY
APERTAAPERTA PRIVATAPRIVATA
OGGETTOOGGETTOPROPRIETÀ
O - U
0 - U
VALOREVALOREAGGIUNTA PARAMETROPARAMETROCOMPL
DEFINIZIONE
PART - OF
ADMIN
I - U
I - F
PROPRIETÀ
F - C
LOCALIZ AMBIENTEAMBIENTE
PROPRIETÀ
O - C
PROPRIETÀ
U - F
AmbienteID Nome Descrizione
NomeDataNascita
DataRegistrazione
Cognome Sesso
DataUltimaOperazione
URL DataCaricamento
Num
Geotag DescrizioneNome Colore
OggettoID
ClasseUtilità Materiale
Descrizione
Nome Descrizione
DataCreazione
CompanyID
Data
PosizioneX Y
Val
NumMaxValori
Descrizione
Num
Nome
1, 1
1, N
1, 1
1, 1
1, 1
0, 1
0, N
0, N
0, 1
0, N
0, 1
0, N
0, N
1, 1
1, 1
0, N
1, 1
0, N
0, N
0, 1
0, N
1, N
1, N
0, N
0, N
0, 1
1, 1
1, N
Num
Figura 8
L’operazione è analoga se per l’inserimento di un oggetto che appartiene ad un utente e
non ad una company.
(1)
(3)
(3)
27
INSERIMENTO DI UN OGGETTO
CONCETTO COSTRUTTO ACCESSI TIPO
Company E 1 L
Proprietà C – F R 1 L
Fotografia E 1 L
Oggetto E 1 S
Proprietà O – C R 1 S
O – U R 1 S
Ultimo inserimento E 1 S
I – F R 1 S
I – U R 1 S
Aggiunta R 1+ S
Valore E 1+ S
Completamento R 1+ S
O – I R 1 S
Inserimento Passato E 1 S
Tabella 33
Le frecce di colore blu sono state utilizzate per l’accesso in lettura e gli ovali rossi per
l’accesso in scrittura, il tratteggio indica un accesso che potrebbe avvenire.
Si noti che una qualsiasi di queste operazioni effettuate da un utente comporterà l’accesso
in scrittura all’entità user per l’aggiornamento della DataUltimaOperazione. Per semplicità
di trattazione tale accesso non è stato reiterato in ogni tabella.
2.3.4. Analisi delle ridondanze
Attributo derivabile:
URL di una fotografia. Per un’organizzazione efficiente del file system del server,
sarà composto da:
“/Pictures/CompanyID(oppureUserID)/
AmbienteID/FotografiaID/*.jpg”.
Associazioni derivabili dovute a cicli:
Un utente o una company che possiede una fotografia possiede anche gli oggetti
inseriti al suo interno.
1. “Proprietà O – U” derivabile da “Proprietà U – F”.
2. “Proprietà O – C” derivabile da “Proprietà F – C”.
28
N.B. L’associazione Completamento non crea nessuna ridondanza (essa infatti non
diventerà un vincolo di tipo chiave esterna bensì un’integrità referenziale gestita mediante
l’utilizzo di un trigger).
Si decide di mantenere la ridondanza di attributo come campo calcolato, ciò è giustificato
dal fatto che l’attributo URL è richiesto ad ogni accesso all’entità fotografia. Per quanto
riguarda invece le due associazioni derivabili si effettua un’analisi dei costi.
2.3.4.1. Analisi dei costi
OPERAZIONE 1 IN ASSENZA DI RIDONDANZA
CONCETTO COSTRUTTO ACCESSI TIPO
Oggetto E 1 L
O – U R 1 L
Ultimo inserimento E 1 L
I – F R 1 L
Fotografia E 1 L
Proprietà F – C R 1 L
Company E 1 L
Aggiunta R 1+ L
Valore E 1+ L
Completamento R 1+ L
Tabella 34
Confrontando il numero degli accessi della Tabella 32 con quelli della Tabella 34 si vede
che non cambiano. Si possono esaminare inoltre due file Access Database aggiuntivi:
“presenzaridondanza.accdb” e “assenzaridondanza.accdb”. Essi contengono
una simulazione di come sarebbe il database e la query per la ricerca di un oggetto
rispettivamente con e senza la ridondanza.
Infine osservando la Tabella 33 si nota che mantenendo la ridondanza l’inserimento di un
nuovo oggetto comporterebbe la scrittura dell’associazione “Proprietà O – C” (o “Proprietà
O – U” nel caso l’oggetto appartenga ad un utente e non ad una company) e ciò sarebbe
un onere inutile. Per questi motivi si decide di eliminare le associazioni “Proprietà O – C” e
“Proprietà O – U”.
29
2.3.5. Eliminazione delle gerarchie
Inserimento:
Si decide di mantenere separate le entità ultimo inserimento e inserimento passato.
Questa scelta è giustificata dal fatto che si accede all’entità ultimo inserimento
molto più frequentemente sia in lettura che in scrittura rispetto all’entità inserimento
passato. Se queste due entità fossero accorpate le operazione principali verrebbero
rallentate.
User e Company:
Poiché le entità figlie non sono mai accedute separatamente si sceglie di eliminarle,
gli attributi dell’utente attivo si aggregano all’entità user e ad entrambe le entità
padri si aggiunge un attributo che specifica a quale delle vecchie entità figlie
appartengano le loro occorrenze.
Adottando questa soluzione si crea però una ridondanza di attributo derivabile nell’entità
user: un utente non è attivo se la data dell’ultima operazione risale a più di 6 mesi prima.
Si decide di eliminare la ridondanza perché, verificando la tavola delle operazioni (Tabella
31), si nota che viene coinvolta solo un’operazione batch non molto frequente.
2.3.6. Partizionamento / accorpamento di concetti
Eliminazione di attributi composti: l’attributo composto Posizione delle entità ultimo
inserimento e inserimento passato viene eliminato e i suoi attributi semplici (X e Y)
vengono aggiunti direttamente alle entità.
Accorpamento di associazioni: si decide di accorpare l’associazione admin, che collega
le entità user e company, con l’associazione part – of. A quest’ultima viene aggiunto un
attributo per specificare se l’utente, che fa parte della company, abbia o meno i permessi
di amministratore.
30
2.3.7. Scelta degli identificatori primari
Si introducono dei codici per avere degli identificatori migliori sulle entità user, fotografia e
inserimento passato. Tenendo conto delle precedenti analisi, tale scelta si giustifica
osservando che queste entità sono accedute con frequenze molto elevate e hanno
bisogno quindi di identificatori efficaci (in questi casi un identificatore interno è preferibile
ad uno esterno che coinvolge più entità ed un identificatore numerico è preferibile ad uno
di tipo stringa). L’identificatore dell’entità ultimo inserimento è lo stesso dell’entità oggetto.
2.3.8. Normalizzazione
Tutte le tabelle sono in terza forma normale secondo Boyce – Codd tranne tre: user,
fotografia e inserimento passato. L’introduzione di codici (e nel caso della fotografia anche
il campo calcolato url) fa perdere loro la 3FN poiché le colonne non sono più indipendenti
tra loro; rimangono quindi in 2FN.
31
2.3.9. Schema E – R ristrutturato
ULTIMO
INSERIMENTO
ULTIMO
INSERIMENTO
INSERIMENTO
PASSATO
INSERIMENTO
PASSATO
OGGETTOOGGETTO VALOREVALORE
PARAMETROPARAMETRO
USERUSERUSER
FOTOGRAFIAFOTOGRAFIA
AMBIENTEAMBIENTE
COMPANYCOMPANYCOMPANY
0 - I
0 - U
I - U
U - U
PROPRIETÀ
U - F
AGGIUNTA
U - F
I - F
LOCALIZ
PROPRIETÀ
F - C
COMPL
DEFINIZIONE
PART - OF
1, 1
1, 11, 1
0, 1
0, N
0, N
0, N
1, N
1, N
0, N1, 1
0, N
1, 1
0, N 1, 1
0, N
1, 1
0, N
0, N
0, N
0, 1
1, 1
0, 1
0, N
1, 1
Data X Y
Data X Y
InsPassatoID
OggettoID Nome Colore
ClasseUtilitàMateriale
Descrizione
UtenteID
Nome
Val Num
DataUltimaOperazione
DataNascita
DataRegistrazione
Cognome
Sesso
AmbienteID
Nome
Descrizione
FotografiaID
GeotagDescrizione
URL
DataCaricamento
NumMaxValori
Descrizione
Nome
Num
Admin
Nome
Descrizione
DataCreazione
CompanyID
Aperta
0, 1
Figura 9
32
2.3.10. Traduzione verso il relazionale – schema logico
tblAmbiente
PK ambienteID
nome descrizione
tblCompany
PK companyID
nome datacreazione descrizione aperta
tblFotografia
PK fotografiaID
dataCaricamento geotag descrizione urlFK1 ambienteIDFK2 userIDFK3 companyID
tblValore
PK numParametroPK numValorePK,FK1 oggettoID
valore
tblOggetto
PK oggettoID
nome colore materiale utilità descrizione
tblUltimoInserimento
PK,FK1 oggettoID
data x yFK2 fotografiaIDFK3 userID
tblInserimentoPassato
PK insPassatoID
data x yFK1 oggettoIDFK2 fotografiaIDFK3 userID
tblUser
PK userID
nome cognome dataNascita sesso email dataRegistrazione dataUltimaOperazione
tblParametro
PK numParametroPK,FK1 companyID
nome numMaxValori descrizione
tblPartOf
PK,FK1 userIDPK,FK2 companyID
admin
Figura 10
33
2.4. Schema fisico
Figura 11
tblAmbienteambienteID
nome
descrizione
tblCompanycompanyID
nome
dataCreazione
descrizione
aperta
tblFotografiafotografiaID
dataCaricamento
geotag
descrizione
url
ambienteID
userID
companyID
tblInserimentoPassatoinsPassatoID
data
x
y
oggettoID
fotografiaID
userID
tblOggettooggettoID
nome
colore
materiale
utilita
descrizione
tblParametronumParametro
companyID
nome
numMaxValori
descrizione
tblUltimoInserimentooggettoID
data
x
y
fotografiaID
userID
tblUseruserID
nome
cognome
dataNascita
sesso
dataRegistrazione
dataUltimaOperazione
tblValoreoggettoID
numParametro
numValore
valore
tblPartOfuserID
companyID
admin
34
2.5. Documentazione aggiuntiva
2.5.1. Viste
Si espongono le viste dedicate atte a soddisfare le seguenti richieste:
1) User registrati al sito (vwUsers)
2) Company degli utenti (vwUsersCompanies)
3) Foto degli utenti (vwUsersPhotos)
4) Foto delle company (vwCompanysPhotos)
5) Parametri di ricerca aggiunti agli oggetti delle company (vwCompanysParameters)
6) Oggetti nelle fotografie (vwPhotosObjects)
7) Ultima posizione degli oggetti tra le fotografie (vwLastPosizions)
8) Posizioni precedenti degli oggetti tra le fotografie (vwPastPositions)
9) Oggetti degli user (vwUsersObjects)
10) Oggetti delle company (vwCompanysObjects)
2.5.2. Trigger
Si creano i seguenti trigger per evitare che si verifichino accidentalmente situazioni di
incoerenza dei dati:
trgAdminIns: Un utente che inserisce un oggetto in una fotografia deve possederla
oppure deve essere amministratore della company a cui essa appartiene.
trgByeAdmin: Si attiva quando un amministratore lascia una company. Se era l’ultimo
amministratore rimasto la company viene cancellata altrimenti tutti gli inserimenti effettuati
da lui non devono essere più associabili a lui.
trgDeletePhoto: Cancella un ambiente quando non ha più fotografie.
35
trgObjRemoved: Gli oggetti rimasti senza un ultimo inserimento vengono cancellati.
trgObjMoved: Un oggetto sportato deve appartenere ad una company.
trgParamValue, trgDeleteParam: Fanno rispettare il vincolo d’integrità tra i valori
aggiunti ad un oggetto di una company e i parametri di ricerca da essa definiti.
trgDeleteUser, trgHasPhoto: Se una fotografie non è di proprietà né di un utente né
di una company oppure sia di un utente che di una company allora viene cancellata.
trgURL: Ad ogni inserimento di nuova una fotografia, genera il nome del file che viene
salvato sul server.
2.5.2.1. Triggering graph
trgDeleteUsertrgDeleteUser
trgByeAdmintrgByeAdmin
trgDeletePhototrgDeletePhoto
trgObjRemovedtrgObjRemoved
trgObjMovedtrgObjMoved
trgParamValuetrgParamValue
trgAdminInstrgAdminIns
trgHasPhototrgHasPhoto
trgURLtrgURL
trgDeleteParamtrgDeleteParam
Figura 12
Come si nota dalla Figura 11 il grafo è aciclico, quindi il sistema è sicuramente terminante.
36
2.5.3. Sorgenti dei trigger e stored procedure
Vengono esposti e brevemente commentati i codici scritti in “T-SQL” per la definizione
delle stored procedure e dei trigger principali, tutti i codici restanti, compresi quelli per la
generazione delle tabelle e delle viste, sono consultabili separatamente.
2.5.3.1. trgHasPhoto
1 CREATE TRIGGER trgHasPhoto
2 ON tblFotografia
3 AFTER INSERT, UPDATE
4 AS
5 DECLARE MyCursor6 CURSOR FOR
6 SELECT fotografiaID, userID, companyID FROM inserted
7
8 OPEN MyCursor6
9 DECLARE @FotoID bigint
10 DECLARE @UID bigint
11 DECLARE @CID bigint
12
13 FETCH NEXT FROM MyCursor6 INTO @FotoID, @UID, @CID
14
15 WHILE @@FETCH_STATUS = 0
16 BEGIN
17
18 IF (@UID IS NULL AND @CID IS NULL) OR
19 (@UID IS NOT NULL AND @CID IS NOT NULL)
20 DELETE FROM tblFotografia
21 WHERE @FotoID = fotografiaID
22
23 FETCH NEXT FROM MyCursor6 INTO @FotoID, @UID, @CID
24 END
25 CLOSE MyCursor6
Trigger 1
Il trigger 1 viene eseguito dopo che un insieme di fotografie viene inserito o modificato
(riga 2 e 3). Si controlla che ogni fotografia (righe 13,15 e 23) abbia almeno un proprietario
(riga 18) e che non sia di proprietà di una company e di uno user contemporaneamente
(riga 19), creando un‘incoerenza dei dati.
37
2.5.3.2. trgAdminIns
1 CREATE TRIGGER trgAdminIns
2 ON tblUltimoInserimento
3 AFTER INSERT, UPDATE
4 AS
5 DECLARE MyCursor CURSOR FOR
6 SELECT oggettoID, fotografiaID, userID
7 FROM inserted
8 WHERE userID IS NOT NULL
9
10 OPEN MyCursor
11 DECLARE @OggettoID bigint
12 DECLARE @FotoID bigint
13 DECLARE @UID bigint
14
15 FETCH NEXT FROM MyCursor INTO @OggettoID, @FotoID, @UID
16
17 WHILE @@FETCH_STATUS = 0
18 BEGIN
19 DECLARE @UserProprFoto bigint
20 DECLARE @CompanyProprFoto bigint
21
22 SELECT @UserProprFoto = tblFotografia.userID,
23 @CompanyProprFoto = tblFotografia.companyID
24 FROM tblFotografia
25 WHERE @FotoID = tblFotografia.fotografiaID
26
27 IF (@UserProprFoto IS NULL OR @UID <> @UserProprFoto) AND
28 NOT EXISTS (
29 SELECT userID, companyID
30 FROM tblPartOf
31 WHERE @UID = userID
32 AND @CompanyProprFoto = companyID
33 AND tblPartOf.admin = 1 )
34 DELETE FROM tblUltimoInserimento
35 WHERE @OggettoID = tblUltimoInserimento.oggettoID
36
37 FETCH NEXT FROM MyCursor INTO @OggettoID, @FotoID, @UID
38 END
39 CLOSE MyCursor
Trigger 2
La parte più rilevante è tra le righe 22 e 35. L’inserimento viene annullato se il proprietario
della fotografia è diverso dall’utente che compie l’inserimento e se la company proprietaria
della fotografia non ha l‘utente che compie l’inserimento come amministratore. Si noti che
è necessario verificare in anticipo se l’utente proprietario della fotografia è NULL poiché si
rischia di confrontare @UID con il valore NULL che darebbe come risultato UKNOWN
invece di TRUE.
38
2.5.3.3. trgParamValue
1 CREATE TRIGGER trgParamValue
2 ON tblValore
3 AFTER INSERT, UPDATE
4 AS
5 DECLARE MyCursor5 CURSOR FOR
6 SELECT oggettoID, numParametro, numValore FROM inserted
7
8 OPEN MyCursor5
9 DECLARE @OggID bigint
10 DECLARE @Param int
11 DECLARE @NumVal int
12
13 FETCH NEXT FROM MyCursor5 INTO @OggID, @Param, @NumVal
14
15 WHILE @@FETCH_STATUS = 0
16 BEGIN
17 IF NOT EXISTS (
18 SELECT tblParametro.companyID, tblParametro.numParametro
19 FROM tblParametro, tblFotografia, tblUltimoInserimento
20 WHERE @OggID = tblUltimoInserimento.oggettoID
21 AND tblFotografia.fotografiaID = tblUltimoInserimento.fotografiaID
22 AND tblParametro.companyID = tblFotografia.companyID
23 AND @Param = tblParametro.numParametro
24 AND @NumVal <= tblParametro.numMaxValori )
25 DELETE FROM tblValore
26 WHERE @OggID = oggettoID
27 AND @Param = numParametro
28 AND @NumVal = numValore
29
30 FETCH NEXT FROM MyCursor5 INTO @OggID, @Param, @NumVal
31 END
32 CLOSE MyCursor5
Trigger 3
Questo trigger è molto importante perché contribuisce a far rispettare il vincolo d’integrità
tra la tblValore e la tblParametro. Una volta inserito il nuovo valore, si controlla che il
corrispondente parametro sia definito per la company proprietaria dell’oggetto (righe 18 –
24) e che il numero del valore assegnato sia inferiore o uguale al numero massimo di
valori permessi per quel parametro (riga 25). In caso contrario, il valore appena inserito
viene cancellato (righe 26 – 29).
39
2.5.3.4. wiliGetCompanies
1 Go
2 CREATE PROCEDURE dbo.wiliGetCompanies ( @userID BIGINT ) AS
3 SELECT vwUsersCompanies.companyID, companyNome,
4 numParametro, parametroNome, parametroDescrizione
5 FROM vwUsersCompanies
6 LEFT JOIN vwCompanysParameters ON
7 ( vwUsersCompanies.companyID = vwCompanysParameters.companyID )
8 WHERE userID = @userID
9 Go
SP 1
La SP 1, utilizzando una selezione di tipo “outer join”, consente all’applicazione che la
esegue di ricevere tutte le company di utente ed eventualmente i parametri di ricerca
aggiuntivi definiti dalla stesse.
2.5.3.5. wiliGetObjects
1 Go
2 CREATE PROCEDURE dbo.wiliGetObjects ( @isCompany BIT, @ID BIGINT ) AS
3 IF ( @isCompany = 1 )
4 SELECT nome, colore, materiale, utilita,
5 oggettoID, numParametro, valore,
6 oggettoDescrizione, x, y, url, fotografiaDescrizione
7 FROM vwCompanysObjects
8 WHERE companyID = @ID
9 ELSE
10 SELECT nome, colore, materiale, utilita,
11 oggettoDescrizione, x, y, url, fotografiaDescrizione
12 FROM vwUsersObjects
13 WHERE userID = @ID
14 Go
SP 2
Il primo parametro 2 è un flag che serve a specificare se il parametro seguente è un
identificativo di una company oppure di un utente. Nel primo caso vengono selezionati i
valori (compresi quelli aggiuntivi) di tutti gli oggetti della company con relative posizioni e
descrizione della fotografia in cui sono inseriti. Nel secondo caso viene fatta la stessa
operazione di selezione stavolta sugli oggetti dell’ utente e quindi senza valori aggiuntivi.
40
3. Documentazione dell’applicazione
3.1. Interfaccia
Immagine 1
Questa è la pagina per la ricerca di un oggetto. In alto a sinistra è presente una tendina
che consente all’utente di specificare in quale raccolta desidera effettuare la ricerca. Potrà
scegliere una delle company a cui è iscritto oppure la sua raccolta personale. Dopo aver
selezionato una company, compaiono (sotto le quattro già presenti) le textbox per inserire i
valori dei parametri di ricerca specifici di quella company. A questo punto l’utente può
inserire le caratteristiche dell’oggetto cercato, può digitare anche solo le prime lettere della
parola e la ricerca comincerà automaticamente non appena avrà finito di scrivere.
41
Immagine 2
Il risultato della ricerca compare sul lato destro della schermata. Qui sono visibili le
miniature della fotografie che contengono gli oggetti trovati e subito accanto sono elencate
le loro caratteristiche principali assieme a una descrizione.
È possibile scorrere i risultati ottenuti e cliccare su una riga in particolare. In questo modo
si ottiene un ingrandimento dell’immagine e si visualizza l’esatta posizione dell’oggetto che
viene indicata da uno spillo. Il risultato ottenuto è illustrato nell’Immagine 3.
Naturalmente è possibile ingrandire ancora l’immagine usando il touchpad o facendo un
pinch se si usa uno schermo touchscreen.
Nella parte inferiore della schermata sono disponibili le informazioni aggiuntive riguardanti
la fotografia e l’oggetto in questione.
Per tornare alla schermata precedente basta cliccare sull’ombra che la oscura oppure
cliccare sulla X in alto a destra.
42
Immagine 3
Si noti che il passaggio da una schermata all’altra non prevede il caricamento di una
nuova pagina web.
Si è scelto di usare questa tecnica in vista degli sviluppi futuri dell’applicazione. Infatti,
dopo aver curato la parte relativa all’inserimento di nuovi oggetti e fotografie, è previsto
che sia possibile interagire maggiormente con queste schermate, consentendo per
esempio di modificare le caratteristiche di un oggetto al volo, di muovere un oggetto
all’interno della stessa fotografia oppure di spostarlo in un’altra. Per effettuare questo tipo
di operazioni risulta molto comodo per l’utente che la pagina rimanga la stessa.
43
3.2. Implementazione
Il capitolo ha lo scopo di esporre il funzionamento interno del prototipo dell’applicazione.
Per semplicità di trattazione non verranno elencati tutti i sorgenti ma si è preferito
soffermarsi sui moduli principali.
Ciò detto, per la programmazione lato client sono descritte solamente alcune funzioni
JavaScript e viene mostrata una parte del foglio di stile. Per il lato server viene presentato
l’interfacciamento con le stored procedure mostrate nel capitolo 2.5.
I codici completi sono presentati alla commissione di prelaurea separatamente da questo
documento e sono disponibili nella cartella “/Source”.
3.2.1. Lato client
3.2.1.1. Caricamento della pagina
1 function loadPage() {
2 $.post("GetCompanies.aspx", "userID=" + userID,
3 function (data, status, jqXHR) {
4 console.log(data);
5 var companySelection = $("select#company");
6 companies = data;
7 for (var n = 0; n < data.length; n++) {
8 companySelection.append(
9 $('<option value="' + data[n].companyID + '">'
10 + data[n].companyName + '</option>'));
11 }
12 imgSmallLoading.remove();
13 });
14 loadResources();
15 $("select#company").change(appendParameters);
16 $("input.mainForm").on("input", counter);
17 resize();
18 }
Script 1
44
Lo Script 1 cerca di ricevere tutte le company di cui l’utente fa parte con i relativi parametri
di ricerca aggiuntivi. Una volta ottenute, la drop-down list viene popolata con i loro nomi
che saranno visibili e selezionabili dall’utente. Il valore assunto dalla lista dopo la
selezione corrisponde all’id della company (righe 3 – 11).
All’evento di selezione viene poi associata la funzione che modifica il DOM inserendo le
textbox che consentono all’utente di specificare le caratteristiche aggiuntive degli oggetti di
quella company (riga 15).
Infine all’evento input del form si associa la funzione che conta quanti millisecondi sono
passati dalla digitazione dell’ultima lettera (riga 16). Se passa più di mezzo secondo si
presuppone che l’utente abbia finito di scrivere e quindi viene processata la richiesta degli
oggetti con le caratteristiche specificate.
3.2.1.2. Request – Response
1 function processRequest() {
2 $.post("GetObj.aspx", "user=" + userID + "&" + $("#mainForm").serialize(),
3 function (data, status, jqXHR) {
4 console.log(data);
5 objects = data;
6 $("div#response > img#loading").remove();
7 if (data.length)
8 viewResponse();
9 else {
10 $("div#response").append(imgNotFound);
11 }
12 });
13 }
14
15 function viewResponse() {
16 $("div#response > table").replaceWith($("<table></table>"));
17 var table = $("div#response > table");
18 for (var n = 0; n < objects.length; n++) {
19 var tr = $('<tr data-rowNumber="' + n + '"><td><img src="'
20 + objects[n].picture.imagePath + 'small.jpg" />'
21 + '</td><td>' + generateDescription(n) + '</td></tr>');
22 tr.click(zoomImage);
23 table.append(tr);
24 }
25 }
Script 2
45
La funzione “processRequest” si occupa di serializzare e inviare i dati del form all’URL
“GetObj.aspx”.
Successivamente si assicura che la risposta contenga dei dati e in caso affermativo
chiama la “viewResponse” (righe 7 e 8). Quest’ultima per prima cosa cancella il risultato di
un’eventuale ricerca precedente (riga 16), riempie poi la tabella dei risultati con la
descrizione dei nuovi oggetti ottenuti e con le miniature delle fotografia in cui essi si
trovano (19 – 24).
Inoltre all’evento click su una riga della tabella viene associato lo zoom dell’immagine
corrispondente che viene portata in primo piano.
3.2.1.3. Sezione in primo piano
La funzione “fillNewSection” genera una sezione in primo piano oscurando il resto della
pagina. In alto a destra viene posizionata l’immagine di una X che se cliccata permette di
chiudere la sezione e di tornare alla pagina sottostante. Lo stesso risultato si ottiene
cliccando sull’ombra attorno alla sezione (righe 2 – 12).
Viene poi creato un elemento canvas per ospitare la fotografia e l’immagine di uno spillo
che serve ad indicare il punto in cui si trova l’oggetto cercato. Si ricorda che x e y sono dei
rapporti e quindi per ottenere le coordinate è necessario moltiplicarli rispettivamente per la
larghezza e l’altezza della fotografia (righe 21 – 22).
Si ha l’accortezza di ruotare lo spillo se questo si trova vicino al bordo superiore o destro
perché rischierebbe di uscire dalla parte visibile del canvas (riga 29).
Infine si aggiungono le descrizioni della fotografia e dell’oggetto in questione (33 – 37).
46
1 function fillNewSection(rowclicked) {
2 var divShadow = $('<div id="shadow" ></div>'),
3 divZoom = $('<div id="zoom" ></div>');
4 function removeSection() {
5 divZoom.remove();
6 divShadow.remove();
7 }
8 $("body").append(divShadow);
9 $("body").append(divZoom);
10 divZoom.append(imgEsc);
11 divShadow.click(removeSection);
12 imgEsc.click(removeSection);
13 imgZoom = new Image();
14 imgZoom.src = objects[rowclicked].picture.imagePath + "big.jpg";
15
16 var _C_ = { gc: null },
17 canvas = $('<canvas id="cnv" width="' + imgZoom.width
18 + '" height="' + imgZoom.height + '"></canvas>'),
19 pinH = imgZoom.height / 7,
20 pinW = pinH * (imgPinpont.width / imgPinpont.height),
21 x = objects[rowclicked].x * imgZoom.width,
22 y = objects[rowclicked].y * imgZoom.height;
23
24 divZoom.append(canvas);
25 _C_.gc = $("canvas#cnv")[0].getContext('2d');
26 imgZoom.addEventListener("load", function () {
27 _C_.gc.drawImage(this, 0, 0);
28 _C_.gc.translate(x, y);
29 _C_.gc.rotate(computeRotation(x, y, pinW, pinH, imgZoom.width, imgZoom.height));
30 _C_.gc.drawImage(imgPinpont, 0, -pinH, pinW, pinH);
31 }, false);
32
33 divZoom.append('<table><tbody><tr><td><em>Dettagli fotografia:</em></td>'
34 + '<td><em>Dettagli oggetto:</em></td></tr>'
35 + '<tr><td>' + objects[rowclicked].picture.description
36 + '</td><td>' + objects[rowclicked].description
37 + '</td></tr></tbody></table>');
38 resize();
39 }
Script 3
47
3.2.1.4. Stile risposta
1 div#response {
2 width: 700px;
3 overflow-y: auto;
4 }
5
6 div#response > table {
7 border-collapse: collapse;
8 cursor: pointer;
9 }
10
11 div#response td {
12 vertical-align: top;
13 width: 340px;
14 line-height: 30px;
15 }
16
17 div#response > table > tbody > tr > td {
18 border-bottom: 1px solid;
19 }
20
21 div#response > table > tbody > tr > td:nth-of-type(2n) {
22 width: 680px;
23 }
24
25 div#response > table > tbody > tr > td:nth-of-type(2n+1) {
26 width: 240px;
27 }
CSS 1
Viene riportata una parte del foglio di stile, in particolare le regole per la visualizzazione
della tabella che conterrà i risultati di una ricerca.
Si è scelto di non usare bordi per suddividere le celle (righe 6 – 9), si userà un solo bordo
per dividere un risultato da quello successivo (righe 17 – 19).
Le colonne dispari contengono le fotografie in miniatura e quelle pari i dettagli dell’oggetto,
la loro larghezza deve quindi essere diversa (righe 21 – 27).
48
3.2.2. Lato server
3.2.2.1. GetCompanies
1 DataTable companysParameters = new DataTable();
2 using (SqlConnection connection = new SqlConnection(connectionString))
3 using (SqlCommand sqlCmdCompanies = new SqlCommand("wiliGetCompanies", connection))
4 {
5 sqlCmdCompanies.CommandType = CommandType.StoredProcedure;
6 sqlCmdCompanies.Parameters.Add(new SqlParameter("@userID", SqlDbType.BigInt));
7 sqlCmdCompanies.Parameters["@userID"].Value = userID;
8 SqlDataAdapter sqlda = new SqlDataAdapter(sqlCmdCompanies);
9 sqlda.Fill(companysParameters);
10 }
11 List<Company> cList = new List<Company>();
12 Company lastCompany = null;
13 List<Parameter> pList = new List<Parameter>();
14 foreach (DataRow row in companysParameters.Rows)
15 {
16 long aCompanyID = Convert.ToInt64(row["companyID"]);
17 if (lastCompany == null || aCompanyID != lastCompany.companyID)
18 {
19 pList = new List<Parameter>();
20 lastCompany = new Company(aCompanyID, row["companyNome"].ToString(),
21 pList);
22 cList.Add(lastCompany);
23 }
24 try
25 {
26 Parameter aParam = new Parameter(Convert.ToInt32(row["numParametro"]),
27 row["parametroNome"].ToString(),
28 row["parametroDescrizione"].ToString());
29 pList.Add(aParam);
30 }
31 catch (InvalidCastException iexc) { }
32 catch (FormatException fexc) { }
33 catch (OverflowException oexc) { }
34 }
35 JavaScriptSerializer js = new JavaScriptSerializer();
36 String json = js.Serialize(cList);
37 Response.Clear();
38 Response.ContentType = "application/json; charset=utf-8";
39 Response.Write(json);
40 Response.End();
C# 1
49
Il codice riportato nella pagina precedente genera una risposta contenente le company di
un utente e i relativi parametri per la ricerca di un oggetto.
Inizialmente si apre una connessione con il database e si esegue la stored procedure
“wiliGetCompanies” già analizzata in dettaglio al capitolo 2.5.3.4. (righe 1 – 10).
Successivamente con i dati ottenuti, ora contenuti nella DataTable companysParameters,
viene costruita una lista di oggetti Company, ognuno contenente una lista di oggetti
Parameter (11 – 34).
La lista di Company infine viene serializzata e restituita nella risposta (35 – 40).
3.2.2.2. GetObjects
1 NameValueCollection nameValueColl = Request.Form;
2 DataTable objsTable = new DataTable();
3 using (SqlConnection connection = new SqlConnection(connectionString))
4 using (SqlCommand sqlCmdObj = new SqlCommand("wiliGetObjects", connection))
5 {
6 sqlCmdObj.CommandType = CommandType.StoredProcedure;
7 sqlCmdObj.Parameters.Add(new SqlParameter("@isCompany", SqlDbType.Bit));
8 sqlCmdObj.Parameters["@isCompany"].Value = !nameValueColl["company"].Equals("-1");
9 sqlCmdObj.Parameters.Add(new SqlParameter("@ID", SqlDbType.BigInt));
10 sqlCmdObj.Parameters["@ID"].Value =
11 (nameValueColl["company"].Equals("-1")) ? nameValueColl["user"]
12 : nameValueColl["company"];
13 SqlDataAdapter sqlda = new SqlDataAdapter(sqlCmdObj);
14 sqlda.Fill(objsTable);
15 }
C# 2
Questo codice serve per interrogare il database e ottenere tutti gli oggetti di un utente
oppure di una company specifica. A questo scopo viene aperta una connessione con il
database e viene eseguita la stored procedure “wiliGetObjects” (righe 3 – 12). Per la
descrizione di quest’ultima si veda il capitolo 2.5.3.5.
50
Si noti che l’id della company è uguale a “-1” solo nel caso in cui nessuna company è stata
selezionata dall’utente ed egli desidera effettuare la ricerca tra le sue fotografie personali.
In questo caso il numero passato come secondo parametro corrisponde all’user id.
Viceversa, se l’utente sceglie di effettuare una ricerca tra gli oggetti di una company allora
viene passato il company id (righe 11 – 12). Il risultato ottenuto grazie all’esecuzione della
“wiliGetObjects” viene salvato per il momento nell’oggetto DataTabe objsTable.
1 foreach (String item in nameValueColl)
2 {
3 if (nameValueColl[item].Length != 0
4 && !item.Equals("company") && !item.Equals("user"))
5 {
6 int i = 0;
7 if (!int.TryParse(item, out i))
8 {
9 String filter = item + " LIKE '" + nameValueColl[item] + "%'";
10 objsTable = objsTable.Select(filter).CopyToDataTable();
11 }
12 else
13 {
14 String filter = "numParametro = " + i + " AND "
15 + "valore LIKE '" + nameValueColl[item] + "%'";
16 objsTable = objsTable.Select("oggettoID IN ("
17 + objsIDs(objsTable.Select(filter)) + ")").CopyToDataTable();
18 }
19 }
20 }
C# 3
Nel codice qui riportato, viene creato un filtro utilizzando il contenuto del form compilato
dall’utente. Per ogni parametro del form si verifica se esso è uno dei parametri principali
(in questo caso è una stringa di lettere, es. “colore”) oppure uno dei parametri aggiuntivi
della company (è una stringa contenente il numero del parametro, es. “2”). Nei due casi si
genera una stringa SQL (filter) che utilizza l’informazione “parametro comincia con valore”
per restringere il campo dei risultati (riga 10 e 16).
51
4. Conclusioni
Entrambi gli obiettivi prefissati sono stati raggiunti.
1) Il database è stato completamente progettato e realizzato e particolare attenzione è
stata rivolta alla prevenzione di situazioni di incoerenza dei dati.
2) Un prototipo dell’applicazione web che si collega al database e consente la ricerca
di un oggetto è pronto e funzionante.
Per ottenere questo risultato, si è riusciti a rimanere entro le 1000 righe di codice, così
suddivise (è stato escluso dal conteggio il codice generato automaticamente):
- 340 righe di Transact-SQL per la creazione dei trigger e delle stored procedure.
- 216 righe tra codice HTML e regole CSS.
- 215 righe di codice JavaScript con 18 funzioni.
- 228 righe di codice C# con 6 classi.
Si è soddisfatti del lavoro svolto finora e delle competenze che il candidato ha dovuto
acquisire per raggiungere gli obiettivi di questa tesi. In futuro si intende continuare lo
sviluppo dell’applicazione web e portare a compimento l’intero progetto.
52
Bibliografia
- Pellegrino Principe, Apogeo, HTML5 CSS3 JavaScript (2012).
- Atzeni Paolo, McGraw-Hill, Basi di dati Modelli e linguaggi di interrogazione (2009).
- Fermeglia Maurizio, dispense del corso di basi di dati (http://studenti.di3.units.it).