Progettazione e sviluppo di un applicativo web e della sua base di dati per l'organizzazione di ambienti di lavoro

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

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
I

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

II

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.
1

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.

2

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.

3

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.

4

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”.

5

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.
6

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
7

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
2

Private (caso tipico). La registrazione è su invito di un utente già iscritto.
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.

8

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.

9

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.

10

2.2. Progettazione concettuale

2.2.1. Glossario dei termini

TERMINE
Ambiente di lavoro
User

Fotografia
Oggetto

Company

DESCRIZIONE
Luogo preciso in cui vengono scattate le
fotografie
Inteso come subject, persona ad un certo
calcolatore provvista di credenziali
d’accesso
Scattata all’ambiente che si desidera
organizzare
Sono contenuti nelle fotografie, provvisti
di caratteristiche che permettono di
individuarli
Formate da più utenti che desiderano
condividere le fotografie

SINONIMI
Luogo

COLLEGAMENTI
Fotografia

User

Fotografia, Company,
Oggetto

Foto

Ambiente, User,
Company, Oggetto
User, Fotografia

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.

11

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


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.
12

Frasi relative agli 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



sono

e

.

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
-

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.

13

-

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

INSERIMENTO

AMBIENTE
AMBIENTE

OGGETTO
OGGETTO

PROPRIETÀ
O-U

PART - OF

PROPRIETÀ
O-C

PROPRIETÀ
U-F

USER
USER

LOCALIZ

FOTOGRAFIA
FOTOGRAFIA

ADMIN

COMPANY
COMPANY

PROPRIETÀ
F-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.
14

2.2.3.1. Raffinamento entità user e company

USER
USER

ATTIVO
ATTIVO

COMPANY
COMPANY

NON
NON
ATTIVO
ATTIVO

APERTA
APERTA

PRIVATA
PRIVATA

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

FOTOGRAFIA
FOTOGRAFIA
I-F

INSERIMENTO
INSERIMENTO

0-I

I-U
I-F

OGGETTO
OGGETTO

0-I

INSERIMENTO
INSERIMENTO

0-U

ULTIMO
ULTIMO

PASSATO
PASSATO

FOTOGRAFIA
FOTOGRAFIA

I-U

OGGETTO
OGGETTO

USER
USER

USER
USER

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.
15

2.2.3.3. Ulteriori entità e associazioni

PROPRIETÀ
O-C

OGGETTO
OGGETTO

AGGIUNTA

VALORE
VALORE

COMPANY
COMPANY

PARAMETRO
PARAMETRO

COMPL

DEFINIZIONE

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
I-F

INSERIMENTO
INSERIMENTO

0-I

I-U
LOCALIZ

0-U

ULTIMO
ULTIMO

PROPRIETÀ
U-F

PASSATO
PASSATO

AMBIENTE
AMBIENTE

PROPRIETÀ
F-C

FOTOGRAFIA
FOTOGRAFIA

ADMIN

OGGETTO
OGGETTO

USER
USER

PROPRIETÀ
O-U

PART - OF

NON
NON
ATTIVO
ATTIVO

ATTIVO
ATTIVO

PROPRIETÀ
O-C

COMPANY
COMPANY
DEFINIZIONE

AGGIUNTA

VALORE
VALORE

COMPL

PARAMETRO
PARAMETRO

APERTA
APERTA

PRIVATA
PRIVATA

Figura 5
16

2.2.5. Analisi delle entità
AMBIENTE
AmbienteID
Nome
Descrizione

Identificativo univoco assegnato ad ogni ambiente.*
Nome del luogo preciso in cui sono state scattate le foto.
Informazioni aggiuntive sull’ambiente.
Tabella 2

USER
Email
Nome
Cognome
Sesso
DataNascita
DataRegistrazione

Un email dell’utente.
Nome proprio dell’utente.
Cognome.
Sesso.
Data di nascita.
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
Descrizione
URL
Geotag
Num

Data in cui la foto è stata caricata sul server.
Descrizione per raccogliere informazioni aggiuntive sulla foto.
Percorso dei file immagine sul server.
Sono le coordinate GPS che indicano il punto dove la foto è stata scattata.
Numera le foto scattate nello stesso ambiente.
Tabella 6

OGGETTO
OggettoID
Nome
Colore
ClasseUtilità
Materiale
Descrizione

Identificativo univoco assegnato ad ogni oggetto.*
Nome dell’oggetto.
Colore principale dell’oggetto.**
Descrive in una parola l’utilità dell’oggetto.**
Materiale principale dell’oggetto.**
Informazioni sull’oggetto.
Tabella 7

17

COMPANY
CompanyID
Nome
DataCreazione
Descrizione

Identificativo univoco assegnato ad ogni company.*
Nome della company.
Data in cui è stata creata la company
Informazioni sulla company.
Tabella 8
APERTA
Nessun attributo.
Tabella 9
PRIVATA
Nessun attributo.
Tabella 10

INSERIMENTO
Data
Posizione

Data con precisione sui secondi. Rappresenta quando è avvenuto l’inserimento.
Rappresenta la posizione dell’oggetto nella fotografia. (Attributo composto).
Tabella 11
ULTIMO
Nessun attributo.
Tabella 12
PASSATO
Nessun attributo.
Tabella 13

PARAMETRO
Num
Nome
Descrizione
NumMaxValori

Numera i parametri di una stessa company.
Nome del parametro.
Informazioni aggiuntive.
Numero massimo dei valori che possono esser associati a quel parametro.
Tabella 14
VALORE

Num
Val

Numera i valori associati ad uno stesso parametro.
È 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.

18

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

19

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

20

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.

21

2.2.8. Schema E – R finale con attributi e cardinalità

X

Y
1, 1

Posizione

Data
1, 1

INSERIMENTO
INSERIMENTO
1, N

I-U

0, 1
0, N

PASSATO
PASSATO

1, 1

Cognome

PROPRIETÀ
U-F

Sesso

Nome

0, 1

Geotag
0, N

Descrizione

PART - OF

0, N

DataUltimaOperazione
PROPRIETÀ
O-C

1, 1

VALORE
VALORE

COMPANY
COMPANY

DEFINIZIONE

1, 1

PARAMETRO
PARAMETRO

COMPL

Num

Descrizione

0, N
DataCreazione
0, N

NumMaxValori

AGGIUNTA

Nome

0, N

NON
NON
ATTIVO
ATTIVO

ATTIVO
ATTIVO

1, N

0, N

DataCaricamento

Materiale
0, 1

ClasseUtilità

PROPRIETÀ
F-C

ADMIN

0, N

Descrizione

0, 1
FOTOGRAFIA
FOTOGRAFIA

DataNascita
DataRegistrazione

USER
USER

Email

PROPRIETÀ
O-U

OGGETTO
OGGETTO

0, 1
URL

Nome Colore
OggettoID

Num

1, N

1, N

0, N

ULTIMO
ULTIMO

0, N

1, 1
0-U

AMBIENTE
AMBIENTE

LOCALIZ

1, 1

0-I

AmbienteID Nome Descrizione
I-F

0, N

1, 1

CompanyID

Num

Val
Descrizione

Nome

APERTA
APERTA

PRIVATA
PRIVATA

Figura 6
22

2.3. Progettazione logica

2.3.1. Tavola dei volumi
ENTITY
Ambiente
User

Attivo

Non attivo
Fotografia
Oggetto
Company

Aperta

Privata
Inserimento

Ultimo

Passato
Parametro
Valore

VOLUME
22 000
25 000
24 000
1 000
110 000
2 000 000
3 200
200
3 000
2 190 000
2 000 000
190 000
1 900
1 110 000

RELATIONSHIP
Oggetto – Inserimento
Oggetto – Ultimo
Inserimento – Foto
Inserimento – User
Proprietà O – U
Proprietà O – C
Aggiunta
Completamento
Definizione
Proprietà U – F
Admin
Part – of
Proprietà F – C
Localizzazione

VOLUME
2 190 000
2 000 000
2 190 000
2 190 000
150 000
1 850 000
1 110 000
1 110 000
1 900
10 000
10 000
22 500
100 000
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.

23

2.3.2. Tavola delle operazioni
OPERAZIONI

TIPO

Ricerca dell’ultima posizione di un oggetto
Ricerca delle posizioni precedenti di un oggetto
Inserimento di un oggetto
Inserimento di una fotografia
Registrazione nuovo user
Registrazione nuova company
Trova gli utenti la cui data dell’ultima operazione risale a più di 6 mesi fa
e considerali non attivi

I
I
I
I
I
I
B

FREQUENZA
3 / secondo
2 / minuto
4 / minuto
13 / ora
3 / ora
9 / giorno
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)

24

X
Data
1, 1

I-F

INSERIMENTO
INSERIMENTO
1, N

I-U

0, 1

0, N
PASSATO
PASSATO

(2)

1, 1

Cognome

URL
Sesso

ADMIN

PART - OF

0, N

NON
NON
ATTIVO
ATTIVO

1, N

ATTIVO
ATTIVO

(1)


DataCreazione
0, N

NumMaxValori

1, 1

VALORE
VALORE

Descrizione

0, N

PROPRIETÀ
O-C

AGGIUNTA

Nome

0, N

Materiale

0, 1

0, N

Descrizione

DataNascita
DataRegistrazione

0, N

Descrizione

PROPRIETÀ
F-C

DataCaricamento
Geotag
0, N

USER
USER

Email

PROPRIETÀ
O-U

OGGETTO
OGGETTO

0, 1
FOTOGRAFIA
FOTOGRAFIA

Nome

0, 1

ClasseUtilità

0, 1

PROPRIETÀ
U-F

Nome Colore
OggettoID

Num

1, N

1, N

0, N

ULTIMO
ULTIMO

0, N

1, 1
0-U

AMBIENTE
AMBIENTE

LOCALIZ

1, 1

0-I

(2)

Y
1, 1

Posizione

COMPANY
COMPANY

DEFINIZIONE

1, 1

PARAMETRO
PARAMETRO

COMPL

Num

0, N

1, 1

CompanyID

Num

Val

(1)

Descrizione

Nome

APERTA
APERTA

PRIVATA
PRIVATA

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.

CONCETTO
Oggetto
Proprietà C – O
Company
O–U
Ultimo inserimento
I–F
Fotografia
Aggiunta
Valore
Completamento

RICERCA DELL’ULTIMA POSIZIONE DI UN OGGETTO
COSTRUTTO
ACCESSI
E
1
L
R
1
L
E
1
L
R
1
L
E
1
L
R
1
L
E
1
L
R
E
R

1+
1+
1+

TIPO

L
L
L
Tabella 32

25

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)

X

Y
1, 1

Posizione

Data

0-I

1, 1

I-F

INSERIMENTO
INSERIMENTO

(3)

I-U

1, N

0, 1

0, N

(3)
PASSATO
PASSATO

(3)

1, 1

Cognome

PROPRIETÀ
U-F

Sesso

Nome

0, 1
OGGETTO
OGGETTO

Descrizione

(1)

PART - OF

Materiale
NON
NON
ATTIVO
ATTIVO

1, N

ATTIVO
ATTIVO

PROPRIETÀ
O-C

(2)

1, 1

VALORE
VALORE

DataCreazione
0, N

COMPANY
COMPANY

DEFINIZIONE

1, 1

PARAMETRO
PARAMETRO

COMPL

Num

Descrizione

0, N
NumMaxValori

AGGIUNTA

Nome

0, N

0, 1

0, N

Geotag
0, N

0, N

(2)
ClasseUtilità

PROPRIETÀ
F-C

DataCaricamento

ADMIN

0, N

Descrizione

0, 1
FOTOGRAFIA
FOTOGRAFIA

DataNascita
DataRegistrazione

USER
USER

Email

PROPRIETÀ
O-U

0, 1
URL

Nome Colore
OggettoID

Num

1, N

1, N

0, N

ULTIMO
ULTIMO

0, N

1, 1
0-U

AMBIENTE
AMBIENTE

LOCALIZ

1, 1

(3)

0, N

1, 1

CompanyID

Num

Val
Descrizione

Nome

APERTA
APERTA

PRIVATA
PRIVATA

Figura 8

L’operazione è analoga se per l’inserimento di un oggetto che appartiene ad un utente e
non ad una company.

26

CONCETTO
Company
Proprietà C – F
Fotografia
Oggetto
Proprietà O – C
O–U
Ultimo inserimento
I–F
I–U

E
R
E
E
R
R
E
R
R

Aggiunta
Valore
Completamento
O–I
Inserimento Passato

INSERIMENTO DI UN OGGETTO
COSTRUTTO
ACCESSI
1
1
1
1
1
1
1
1
1

R
E
R
R
E

1+
1+
1+
1
1

TIPO
L
L
L
S
S
S
S
S
S
S
S
S
S
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”.
27

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

CONCETTO
Oggetto
O–U
Ultimo inserimento
I–F
Fotografia
Proprietà F – C
Company
Aggiunta
Valore
Completamento

OPERAZIONE 1 IN ASSENZA DI RIDONDANZA
COSTRUTTO
ACCESSI
E
1
R
1
E
1
R
1
E
1
R
1
E
1
R
E
R

1+
1+
1+

TIPO
L
L
L
L
L
L
L
L
L
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”.

28

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.
29

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.

30

2.3.9. Schema E – R ristrutturato

Data

1, 1
0-U

Y

X

U-F

ULTIMO
ULTIMO
INSERIMENTO
INSERIMENTO

1, 1

0, N

U-U

0, 1

Y

X

FotografiaID
1, 1

0-I

1, 1

0, N

1, 1

0, N

0, 1

I-F

INSERIMENTO
INSERIMENTO
PASSATO
PASSATO

URL
PROPRIETÀ
U-F

I-U

InsPassatoID

DataCaricamento

0, 1

FOTOGRAFIA
FOTOGRAFIA

PROPRIETÀ
F-C

0, 1

1, 1

Data

Geotag

Descrizione

OGGETTO
OGGETTO

1, N

Num

1, 1

AGGIUNTA

UtenteID
Nome

VALORE
VALORE

1, 1

Descrizione

DataRegistrazione Sesso

AMBIENTE
AMBIENTE

DataNascita

Cognome

OggettoID Nome Colore

AmbienteID

Email

USER
USER

Descrizione

0, N

0, N

Val

0, N

ClasseUtilità

0, N

Materiale

0, N

LOCALIZ

Nome


0, N

Nome

0, N

COMPL

1, N

CompanyID Descrizione
DataCreazione

PART - OF

Descrizione
NumMaxValori

Admin

PARAMETRO
PARAMETRO

Num

1, 1

Aperta
0, N

DEFINIZIONE

Nome

COMPANY
COMPANY

Figura 9
31

2.3.10. Traduzione verso il relazionale – schema logico

tblUltimoInserimento
PK,FK1

oggettoID

FK2
FK3

data
x
y
fotografiaID
userID

tblFotografia

tblInserimentoPassato
PK

FK1
FK2
FK3

tblOggetto
PK

oggettoID
nome
colore
materiale
utilità
descrizione

PK

data
x
y
oggettoID
fotografiaID
userID

tblValore
PK
PK
PK,FK1

numParametro
numValore
oggettoID
valore

fotografiaID

FK1
FK2
FK3

insPassatoID

dataCaricamento
geotag
descrizione
url
ambienteID
userID
companyID

tblAmbiente
PK

nome
descrizione

tblCompany

tblUser
PK

ambienteID

PK

userID

companyID
nome
datacreazione
descrizione
aperta

nome
cognome
dataNascita
sesso
email
dataRegistrazione
dataUltimaOperazione

tblParametro
PK
PK,FK1

numParametro
companyID
nome
numMaxValori
descrizione

tblPartOf
PK,FK1
PK,FK2

userID
companyID
admin

Figura 10
32

2.4. Schema fisico

tblUltimoInserimento
oggettoID
data
x
y
fotografiaID
userID

tblInserimentoPassato
insPassatoID
data
x
y

tblFotografia

oggettoID

tblAmbiente

fotografiaID

fotografiaID

ambienteID

userID

dataCaricamento

nome

geotag

descrizione

descrizione
url
ambienteID
userID
companyID

tblOggetto

tblValore

tblUser

oggettoID

oggettoID

userID

nome

numParametro

nome

colore

numValore

cognome

materiale

valore

dataNascita

utilita

tblParametro

companyID

nome

descrizione

numMaxValori

aperta

dataRegistrazione

companyID

dataCreazione

email

numParametro

nome

sesso

descrizione

tblCompany

descrizione

dataUltimaOperazione

tblPartOf
userID
companyID
admin

Figura 11
33

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.
34

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
trgURL
trgURL

trgAdminIns
trgAdminIns

trgObjRemoved
trgObjRemoved

trgDeleteUser
trgDeleteUser

trgByeAdmin
trgByeAdmin

trgHasPhoto
trgHasPhoto

trgDeletePhoto
trgDeletePhoto

trgDeleteParam
trgDeleteParam
trgParamValue
trgParamValue
trgObjMoved
trgObjMoved

Figura 12

Come si nota dalla Figura 11 il grafo è aciclico, quindi il sistema è sicuramente terminante.
35

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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

CREATE TRIGGER trgHasPhoto
ON tblFotografia
AFTER INSERT, UPDATE
AS
DECLARE MyCursor6 CURSOR FOR
SELECT fotografiaID, userID, companyID FROM inserted
OPEN MyCursor6
DECLARE @FotoID bigint
DECLARE @UID bigint
DECLARE @CID bigint
FETCH NEXT FROM MyCursor6 INTO @FotoID, @UID, @CID
WHILE @@FETCH_STATUS = 0
BEGIN
IF (@UID IS NULL AND @CID IS NULL) OR
(@UID IS NOT NULL AND @CID IS NOT NULL)
DELETE FROM tblFotografia
WHERE @FotoID = fotografiaID
FETCH NEXT FROM MyCursor6 INTO @FotoID, @UID, @CID
END
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.
36

2.5.3.2. trgAdminIns

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

CREATE TRIGGER trgAdminIns
ON tblUltimoInserimento
AS
DECLARE MyCursor CURSOR FOR
SELECT oggettoID, fotografiaID, userID
FROM inserted
WHERE userID IS NOT NULL
OPEN MyCursor
DECLARE @OggettoID bigint
DECLARE @FotoID bigint
DECLARE @UID bigint
FETCH NEXT FROM MyCursor INTO @OggettoID, @FotoID, @UID
BEGIN
DECLARE @UserProprFoto bigint
DECLARE @CompanyProprFoto bigint
SELECT @UserProprFoto = tblFotografia.userID,
@CompanyProprFoto = tblFotografia.companyID
FROM tblFotografia
WHERE @FotoID = tblFotografia.fotografiaID
IF (@UserProprFoto IS NULL OR @UID <> @UserProprFoto) AND
NOT EXISTS (
SELECT userID, companyID
FROM tblPartOf
WHERE @UID = userID
AND @CompanyProprFoto = companyID
AND tblPartOf.admin = 1 )
DELETE FROM tblUltimoInserimento
WHERE @OggettoID = tblUltimoInserimento.oggettoID
FETCH NEXT FROM MyCursor INTO @OggettoID, @FotoID, @UID
END
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.
37

2.5.3.3. trgParamValue

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

CREATE TRIGGER trgParamValue
ON tblValore
AS
DECLARE MyCursor5 CURSOR FOR
SELECT oggettoID, numParametro, numValore FROM inserted
OPEN MyCursor5
DECLARE @OggID bigint
DECLARE @Param int
DECLARE @NumVal int
FETCH NEXT FROM MyCursor5 INTO @OggID, @Param, @NumVal
BEGIN
IF NOT EXISTS (
SELECT tblParametro.companyID, tblParametro.numParametro
FROM tblParametro, tblFotografia, tblUltimoInserimento
WHERE @OggID = tblUltimoInserimento.oggettoID
AND tblFotografia.fotografiaID = tblUltimoInserimento.fotografiaID
AND tblParametro.companyID = tblFotografia.companyID
AND @Param = tblParametro.numParametro
AND @NumVal <= tblParametro.numMaxValori )
DELETE FROM tblValore
WHERE @OggID = oggettoID
AND @Param = numParametro
AND @NumVal = numValore
FETCH NEXT FROM MyCursor5 INTO @OggID, @Param, @NumVal
END
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).

38

2.5.3.4. wiliGetCompanies

1
2
3
4
5
6
7
8
9

Go
CREATE PROCEDURE dbo.wiliGetCompanies ( @userID BIGINT ) AS
SELECT vwUsersCompanies.companyID, companyNome,
numParametro, parametroNome, parametroDescrizione
FROM
vwUsersCompanies
LEFT JOIN vwCompanysParameters ON
( vwUsersCompanies.companyID = vwCompanysParameters.companyID )
WHERE userID = @userID
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
2
3
4
5
6
7
8
9
10
11
12
13
14

Go
CREATE PROCEDURE dbo.wiliGetObjects ( @isCompany BIT, @ID BIGINT ) AS
IF ( @isCompany = 1 )
SELECT nome, colore, materiale, utilita,
oggettoID, numParametro, valore,
oggettoDescrizione, x, y, url, fotografiaDescrizione
FROM
vwCompanysObjects
WHERE
companyID = @ID
ELSE
SELECT nome, colore, materiale, utilita,
oggettoDescrizione, x, y, url, fotografiaDescrizione
FROM
vwUsersObjects
WHERE
userID = @ID
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.
39

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.
40

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.

41

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.

42

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

function loadPage() {
1
$.post("GetCompanies.aspx", "userID=" + userID,
2
function (data, status, jqXHR) {
3
console.log(data);
4
var companySelection = $("select#company");
5
companies = data;
6
for (var n = 0; n < data.length; n++) {
7
companySelection.append(
8
$('<option value="' + data[n].companyID + '">'
9
+ data[n].companyName + '</option>'));
10
}
11
imgSmallLoading.remove();
12
});
13
loadResources();
14
$("select#company").change(appendParameters);
15
$("input.mainForm").on("input", counter);
16
resize();
17
18 }

Script 1
43

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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

function processRequest() {
$.post("GetObj.aspx", "user=" + userID + "&" + $("#mainForm").serialize(),
function (data, status, jqXHR) {
console.log(data);
objects = data;
$("div#response > img#loading").remove();
if (data.length)
viewResponse();
else {
$("div#response").append(imgNotFound);
}
});
}
function viewResponse() {
$("div#response > table").replaceWith($("<table></table>"));
var table = $("div#response > table");
for (var n = 0; n < objects.length; n++) {
var tr = $('<tr data-rowNumber="' + n + '"><td><img src="'
+ objects[n].picture.imagePath + 'small.jpg" />'
+ '</td><td>' + generateDescription(n) + '</td></tr>');
tr.click(zoomImage);
table.append(tr);
}
}

Script 2
44

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).

45

1 function fillNewSection(rowclicked) {
var divShadow = $('<div id="shadow" ></div>'),
2
divZoom = $('<div id="zoom" ></div>');
3
function removeSection() {
4
divZoom.remove();
5
divShadow.remove();
6
}
7
$("body").append(divShadow);
8
$("body").append(divZoom);
9
divZoom.append(imgEsc);
10
divShadow.click(removeSection);
11
imgEsc.click(removeSection);
12
imgZoom = new Image();
13
imgZoom.src = objects[rowclicked].picture.imagePath + "big.jpg";
14
15
var _C_ = { gc: null },
16
canvas = $('<canvas id="cnv" width="' + imgZoom.width
17
+ '" height="' + imgZoom.height + '"></canvas>'),
18
pinH = imgZoom.height / 7,
19
pinW = pinH * (imgPinpont.width / imgPinpont.height),
20
x = objects[rowclicked].x * imgZoom.width,
21
y = objects[rowclicked].y * imgZoom.height;
22
23
divZoom.append(canvas);
24
_C_.gc = $("canvas#cnv")[0].getContext('2d');
25
imgZoom.addEventListener("load", function () {
26
_C_.gc.drawImage(this, 0, 0);
27
_C_.gc.translate(x, y);
28
_C_.gc.rotate(computeRotation(x, y, pinW, pinH, imgZoom.width, imgZoom.height));
29
_C_.gc.drawImage(imgPinpont, 0, -pinH, pinW, pinH);
30
}, false);
31
32
divZoom.append('<table><tbody><tr><td><em>Dettagli fotografia:</em></td>'
33
+ '<td><em>Dettagli oggetto:</em></td></tr>'
34
+ '<tr><td>' + objects[rowclicked].picture.description
35
+ '</td><td>' + objects[rowclicked].description
36
+ '</td></tr></tbody></table>');
37
resize();
38
39 }

Script 3

46

3.2.1.4. Stile risposta

1 div#response {
width: 700px;
2
overflow-y: auto;
3
4 }
5
div#response > table {
6
border-collapse: collapse;
7
cursor: pointer;
8
}
9
10
div#response td {
11
vertical-align: top;
12
width: 340px;
13
line-height: 30px;
14
}
15
16
div#response > table > tbody > tr > td {
17
border-bottom: 1px solid;
18
}
19
20
div#response > table > tbody > tr > td:nth-of-type(2n) {
21
width: 680px;
22
}
23
24
div#response > table > tbody > tr > td:nth-of-type(2n+1) {
25
width: 240px;
26
}
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).

47

3.2.2. Lato server
3.2.2.1. GetCompanies

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

DataTable companysParameters = new DataTable();
using (SqlConnection connection = new SqlConnection(connectionString))
using (SqlCommand sqlCmdCompanies = new SqlCommand("wiliGetCompanies", connection))
{
sqlCmdCompanies.CommandType = CommandType.StoredProcedure;
sqlCmdCompanies.Parameters.Add(new SqlParameter("@userID", SqlDbType.BigInt));
sqlCmdCompanies.Parameters["@userID"].Value = userID;
SqlDataAdapter sqlda = new SqlDataAdapter(sqlCmdCompanies);
sqlda.Fill(companysParameters);
}
List<Company> cList = new List<Company>();
Company lastCompany = null;
List<Parameter> pList = new List<Parameter>();
foreach (DataRow row in companysParameters.Rows)
{
long aCompanyID = Convert.ToInt64(row["companyID"]);
if (lastCompany == null || aCompanyID != lastCompany.companyID)
{
pList = new List<Parameter>();
lastCompany = new Company(aCompanyID, row["companyNome"].ToString(),
pList);
cList.Add(lastCompany);
}
try
{
Parameter aParam = new Parameter(Convert.ToInt32(row["numParametro"]),
row["parametroNome"].ToString(),
row["parametroDescrizione"].ToString());
pList.Add(aParam);
}
catch (InvalidCastException iexc) { }
catch (FormatException fexc) { }
catch (OverflowException oexc) { }
}
JavaScriptSerializer js = new JavaScriptSerializer();
String json = js.Serialize(cList);
Response.Clear();
Response.ContentType = "application/json; charset=utf-8";
Response.Write(json);
Response.End();

C# 1

48

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
2
3
4
5
6
7
8
9
10
11
12
13
14
15

NameValueCollection nameValueColl = Request.Form;
DataTable objsTable = new DataTable();
using (SqlConnection connection = new SqlConnection(connectionString))
using (SqlCommand sqlCmdObj = new SqlCommand("wiliGetObjects", connection))
{
sqlCmdObj.CommandType = CommandType.StoredProcedure;
sqlCmdObj.Parameters.Add(new SqlParameter("@isCompany", SqlDbType.Bit));
sqlCmdObj.Parameters["@isCompany"].Value = !nameValueColl["company"].Equals("-1");
sqlCmdObj.Parameters.Add(new SqlParameter("@ID", SqlDbType.BigInt));
sqlCmdObj.Parameters["@ID"].Value =
(nameValueColl["company"].Equals("-1")) ? nameValueColl["user"]
: nameValueColl["company"];
SqlDataAdapter sqlda = new SqlDataAdapter(sqlCmdObj);
sqlda.Fill(objsTable);
}

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.

49

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 {
if (nameValueColl[item].Length != 0
3
&& !item.Equals("company") && !item.Equals("user"))
4
{
5
int i = 0;
6
if (!int.TryParse(item, out i))
7
{
8
String filter = item + " LIKE '" + nameValueColl[item] + "%'";
9
objsTable = objsTable.Select(filter).CopyToDataTable();
10
}
11
else
12
{
13
String filter = "numParametro = " + i + " AND "
14
+ "valore LIKE '" + nameValueColl[item] + "%'";
15
objsTable = objsTable.Select("oggettoID IN ("
16
+ objsIDs(objsTable.Select(filter)) + ")").CopyToDataTable();
17
}
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).

50

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.

51

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).

52

Progettazione e sviluppo di un applicativo web e della sua base di dati per l'organizzazione di ambienti di lavoro

More Related Content

Similar to Progettazione e sviluppo di un applicativo web e della sua base di dati per l'organizzazione di ambienti di lavoro (20)

Progettazione e sviluppo di un applicativo web e della sua base di dati per l'organizzazione di ambienti di lavoro