Analisi e sviluppo di un sistema collaborativo simultaneo per la modifica di ...
Progettazione e sviluppo di un applicativo web e della sua base di dati per l'organizzazione di ambienti di lavoro
1. 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
2. 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
3. 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
4. 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
5. 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
6. 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
7. 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
8. 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
9. 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
10. 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
11. 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
12. 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
13. 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
14. 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
15. 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.
12
16. 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
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
-
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.
13
17. -
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
18. 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
19. 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
20. 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
21. 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
22. 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
23. 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
24. 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
25. 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
26. 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
27. 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
28. X
Data
1, 1
AmbienteID Nome Descrizione
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)
DataUltimaOperazione
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
29. 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
AmbienteID Nome Descrizione
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
DataUltimaOperazione
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
30. 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
31. 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
32. 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
33. 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
34. 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
DataUltimaOperazione
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
35. 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
37. 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
38. 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
39. 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
40. 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
AFTER INSERT, UPDATE
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
WHILE @@FETCH_STATUS = 0
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
41. 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
AFTER INSERT, UPDATE
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
WHILE @@FETCH_STATUS = 0
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
42. 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
43. 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
44. 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
45. 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
46. 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
47. 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
48. 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
50. 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
52. 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
53. 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
54. 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
55. 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
