UNIVERSITÀ DEGLI STUDI DI TRIESTE

FACOLTÀ DI INGEGNERIA

Corso di Laurea Triennale in Ingegneria Informatica

Anno Accademico 2007/2008

Sviluppo di una applicazione web per la

gestione di fotografie digitali:
Il modulo di amministrazione

Laureando: Martina De Faveri

Relatore: Chiar.mo prof. Maurizio
FERMEGLIA

1
Sommario
1 Introduzione:...........................................................................................4
2 Obiettivi................................................................................................. ..6
3 Stato dell’arte........................................................................................ ..8
3.1 Struttura software preesistente.........................................................8
3.2 Sistemi fotografici presenti...............................................................8
3.2 Stato attuale della rete.....................................................................9
4 Requisiti del sistema.............................................................................11
5 Progettazione del database: progettazione concettuale.......................13
5.1 Entità e relazioni principali:.............................................................14
5.2 Estensione delle entità e relazioni: .................................................14
5.3 Generalizzazioni..............................................................................16
5.3.1 Generalizzazione utente...........................................................16
5.3.2 Generalizzazione foto................................................................16
5.3.3 Generalizzazione sconto...........................................................17
5.3.4 Generalizzazione listino............................................................18
5.4 Diagramma Entità-Relazioni con le generalizzazioni.......................19
5.5 Analisi delle entità...........................................................................20
5.6 Analisi delle relazioni.......................................................................25
5.7 Schema entità relazioni con i relativi attributi finale.......................31
6 Progettazione del database: progettazione logica.................................33
6.1 Valutazione dei costi.......................................................................34
6.2 Conversione delle generalizzazione ed eliminazione delle
ridondanze............................................................................................36
6.2.1 Generalizzazione Utente...........................................................36
6.2.2 Generalizzazione Foto...............................................................36
6.2.3 Generalizzazione Sconti............................................................37
6.2.4 Generalizzazione listino............................................................38
6.3 Eliminazione delle relazioni ridondanti............................................39
6.4 Eliminazione degli attributi composti..............................................40
7 Il database........................................................................................... ..41
7.1 Schema completo del database......................................................41
7.2 Le tabelle........................................................................................41

2
8 Interfaccia del progetto.........................................................................49
8.1 Installazione del sistema.................................................................49
8.2 Interfaccia principale.......................................................................49
8.3 Interfaccia di un sistema di stampa................................................50
9 Esempi di utilizzo..................................................................................52
9.1Creazione di un ordine.....................................................................52
9.2Creazione di un report di preventivo da un ordine già esistente:.....57
10 Interfaccia grafica: esempi di codice...................................................60
10.1Caricamento foto............................................................................ 60
11 Conclusioni..........................................................................................62
Appendice A ............................................................................................65
Appendice B.............................................................................................67
Bibliografia:..............................................................................................77
Contenuto CD.............................................................................. .............78

3
1 Introduzione:
Lo studio fotografico Fotomauro necessitava di riprogettare completamente tutto il
software che aveva, per la gestione degli ordini, dei clienti e della lavorazione delle
fotografie. In particolare mi sono occupata della parte di amministrazione, quindi
gestione anagrafiche e ordini in ingresso.

Il risultato di questo lavoro è la creazione del database di tutto il sistema di gestione

degli ordini e l’interfaccia che gli addetti del negozio utilizzeranno.

L’esigenza di creazione di questo tipo di software è dovuta alla mancanza sul

mercato di qualcosa che fosse marcatamente specializzato per la gestione degli ordini
di fotografie di uno studio fotografico. Inoltre il software che era già in uso
presentava grossi problemi di sicurezza e mancava completamente una
automatizzazione di tutto il processo dall’acquisizione delle foto alla consegna al
cliente. La necessità, inoltre, di offrire la possibilità di ricevere ordini via internet ha
implicato la riprogettazione del tutto in modo da creare anche questa caratteristica al
sistema.

Per sviluppare il tutto sono stati seguiti i seguenti passi:

 Definizione dei requisiti di tutto il sistema tramite incontro con il

committente del progetto

4
  Studio delle piattaforme SQL Server 2008 e Visual Studio 2008, in
particolare il linguaggio C#, Crystal report, necessarie per l’implementazione.
(Caratteristiche richieste dal committente)

 Studio della struttura del database creazione del diagramma ER

 Ristrutturazione del diagramma

 Creazione della struttura database in SQL con le relative store procedure

 Realizzazione dell’interfaccia associata

Il software utilizzato per creare il tutto è stato il seguente:

 Microsoft Windows Server 2008, richiesto dal committente perché presente

nel server acquistato

 VMWare Workstation: per utilizzare la macchina virtuale con il Windows

Server 2008 avente le impostazioni richieste dal sistema

 Microsoft Visual Studio 2008: per la realizzazione dell’interfaccia che

comunica con il database

 Microsoft SQL Server 2008: per la creazione del database

 Microsoft Visio: per la creazione di tutti i diagrammi presenti

5
2 Obiettivi
Gli obiettivi prefissati sono i seguenti. La realizzazione di un software che potesse
assolvere ai compiti di gestione dell’anagrafica e di gestione degli ordini in arrivo sia
tramite il canale classico del negozio, sia tramite la nuova del canale web. In
particolare gli obiettivi possono essere riassunti come segue:

 O1: Realizzazione del database: studio di tutte le caratteristiche

dell’implementazione dello stesso partendo dai requisiti che il sistema
necessita

 O2: Verifica delle caratteristiche del database: controllo delle tavole degli
accessi, ipotizzati, in modo da vedere in quali parti il database risulta
maggiormente utilizzato

 O3: Determinazione dell’interfaccia: studio di come l’interfaccia debba

essere sviluppata e dei dati che debbano essere accessibili tramite essa dalle
due strutture, quella amministrativa e quella presente sulla macchina. Infatti
c’è la necessità di creare anche un’interfaccia nella quale un operatore può
controllare la coda di stampa in una determinata macchina di stampa piuttosto
che eliminare qualche foto dalla coda

6
 O4: Controllo della funzionalità: verifica che tutti i requisiti siano stati
rispettati e che il software funzioni nel modo corretto

7
3 Stato dell’arte

3.1 Struttura software preesistente

Il software che attualmente è presente nei sistemi dello studio per la parte di
interfaccia è stata sviluppato interamente in Microsoft VB.NET 2005 mentre per
quello che riguarda il database è stato realizzato con Access 2000. Il software si
presentava creato solo per la gestione tramite un terminale presente vicino alla cassa
e non dava la possibilità di controllare gli ordini arrivati via web. La gestione dei vari
sistemi di stampa non era automatica ma prevedeva il prelevamento manuale da un
server interno al sistema delle foto. Inoltre la gestione degli ordini era completamente
manuale, prevedeva il controllo da parte dell’operatore se era necessario del
fotoritocco piuttosto l’avanzamento dell’ordine in fase di stampa. Inoltre non
presentava validazione degli utenti che utilizzavano la macchina, quindi tutte le
persone che vi accedevano avevano gli stessi diritti. Le foto nel sistema venivano
salvate in chiaro e chiunque raggiungeva la macchina poteva accederci, questo
implica un problema di sicurezza nel trattamento delle foto che risultano comunque
come dati personali sensibili dei clienti. Inoltre la parte di fatturazione e gestione
economica è già implementata in un sistema separato che non desiderano modificare.

3.2 Sistemi fotografici presenti

I sistemi di stampa professionali, intesi come l’insieme degli apparati tecnologici
finalizzati alla realizzazione di stampe su carte fotografiche hanno un fortissimo

8
impatto su l’intero progetto da sviluppare. Infatti sono i sistemi che impongono i
maggiori vincoli, quali i sistemi operativi, la possibilità di comunicazione. Lo studio
fotografico dispone di tre principali sistemi di stampa:

- Frontier (Fujifilm): progettato per stampare i formati classici

- LPS2 (Noritsu): utilizzato come plotter e per stampe su carte particolari

- JOTA Album (Durst): per creare gli album libro

In questo modo i vari formati di stampa vengono divisi tra queste macchine una delle
quali, l’ultima è utilizzata in modo minore rispetto alle altre.

3.2 Stato attuale della rete

Lo studio fotografico presenta una ventina di periferiche di rete, collegate tra loro
tramite uno switch che rappresenta una tipica topologia a stella. I nodi che
compongono la rete che consentono un collegamento a piena banda, nodi gigabit,
vengono collegati direttamente a questo switch, mentre gli altri sono collegati su uno
switch, 10/100 Mb, a cascata. Tutti i nodi sono collegati a quest’ultimi sono riferiti a
macchinari che hanno poco traffico dati, come particolari stampanti, oppure terminali
poco utilizzati. Gli indirizzi dei nodi sono di tipo stati e pre assegnati di classe c. I
cablaggi sono tutti cavi UTP cat. 5E.

9
 Router
Server HP Switch
ML370TG4 NETGEAR
10/100/1000
16 porte

Switch Switch
NETGEAR
NETGEAR
10/100
10/100
16 porte
16 porte

Area periferiche di stampa

Figura 3.1: Schema di massima della rete dello studio fotografico

10
4 Requisiti del sistema
In questo capitolo si tratterà sommariamente quali sono i compiti di questo sistema
richiesti dal committente.

In prima cosa sono state definite le tipologie di interfacce a cui gli operatori dello
studio erano a contatto. Essenzialmente sono di due tipi, quella rivolta
all’amministrazione degli ordini e dei clienti e quella presente sul computer collegato
ad ogni macchina che permette la visualizzazione dello stato di stampa e degli ordini.
In primis il modulo di amministrazione avrà le seguenti funzionalità:

 Impostazione delle tipologie di carta disponibili per i vari formati e per i vari
sistemi di stampa: è possibile quando si inserisce un ordine la scelta del
formato, comprendente anche le varie tipologie di carta in modo da ottenere
pressoché la totalità dei formati disponibili nello studio.

 Definizione dei listini prezzo: modifica dei listini prezzo in modo da

adeguarsi nel tempo e all’aggiunta di nuovi formati di stampa.

 Definizioni delle classi di sconto: definire sia classi di sconto in base alla
persona, ad esempio se è un fotografo associato che abitualmente acquista
grandi quantità di foto, oppure in base all’acquisto di carte prepagate,
quest’ultime consentono di acquistare determinate quantità di un prefissato

11
 formato in modo da ottenere degli sconti, ogni cliente può avere più
prepagate in base alla tipologia di formati che normalmente stampa.

 Introduzione degli ordini nuovi in arrivo in negozio: inserimento degli ordini

pervenuti in negozio tramite una interfaccia.

 Visualizzazione degli ordini per utente: controllo degli ordini inseriti di un

determinato utente mediante l’inserimento dei dati di quest’ultimo

 Ottenimento preventivo: all’atto dell’esecuzione dell’ordine oppure di un

ordine già inserito è possibile visualizzarne il prezzo dell’intera operazione.

 Visualizzazione galleria: il fotografo ha una collezione di fotografie che ha

raggruppato in gallerie tematiche, o in base agli eventi, che propone ai clienti,
ad un prezzo maggiorato, perché sono di proprietà esclusiva del fotografo.
Per invogliare l’acquisto di queste foto c’è la possibilità di visionarle e
decidere quali acquistare.

12
5 Progettazione del database: progettazione concettuale

In questo capitolo si affronterà la creazione del database dal punto di vista

concettuale analizzandone le entità e le relazioni coinvolte, in modo da determinare
la struttura base. Si procederà nel seguente modo:

 Determinazione delle entità e relazioni principali

 Estensione dello schema scheletro base in modo da raffinare le entità e le

relazioni

 Ricerca di eventuali generalizzazioni

 Ottenimento dello schema entità relazioni finale

 Esamina delle entità

 Esamina delle relazioni

 Realizzazione dello schema con gli attributi

13
5.1 Entità e relazioni principali:

UTENTE ORDINA FOTO PROPRIETA’ TIPOLOGIA

Figura 5.1: Schema delle entità e relazioni principali

Nella figura 5.1 possiamo vedere le relazioni e le entità principali, le quali sottendo
al processo di registrazione di un nuovo ordine. Un utente chiede al servizio
fotografico di preparare determinate stampe, anche di diverse tipologie, di alcune
foto e in base alle proprietà di quest’ultime vengono gestite in modo diverso dal
personale e con macchinari diversi.

Tutti le entità sono tra loro indipendenti e le relazioni esistono solo quando c’è un
legame tra foto e tipologia e utente e foto.

5.2 Estensione delle entità e relazioni:

14
 POSSIEDE PREPAGATA TIPO

PAGA LISTINO

UTENTE ORDINA FOTO PROPRIETA’ FORMATO PREZZO

MODALITA’
TIPOLOGIA
STAMPA

SCONTO STAMPANTE

Figura 5.2: Schema delle entità e relazioni esteso

In questo schema (figura 5.2) si mette in evidenza le relazioni secondarie che

regolano il db. Come si può notare ogni utente appartiene ad una determinata
categoria la quale presenta una particolare tipologia di sconto, ad esempio grande
acquirente oppure fotografo associato. Dopo aver determinato a quale categoria di
utente, sia tramite i dati che tramite la prepagata eventualmente posseduta, si procede
all’ordine e alla determinazione del compenso spettante al fotografo dopo
l’elaborazione dell’ordine. Il metodo delle prepagate è stato introdotto per poter
agevolare gli ordini via internet e premiare con copie extra clienti che comprano
anticipatamente una grande quantità di copie di un determinato formato.
All’accettazione dell’ordine, dopo la verifica del pagamento o dell’eventuale acconto
dato in negozio, si procede con la catalogazione delle foto in modo da renderle
univocamente reperibili dalla tipologia di macchina che le dovrà elaborare. Potrebbe
essere necessario l’elaborazione della stessa immagine da parte di diverse macchine
perché essa venga riprodotta su supporti diversi. Ad ogni tipologia di formato, dalla
fototessera al più elaborato su cuscino, presenta un prezzo preciso, che solo
determinati sconti creati per ciascuna persona; oppure sconti grandi quantità

15
5.3 Generalizzazioni

5.3.1 Generalizzazione utente

UTENTE

CLIENTE FOTOGRAFO

Figura 5.3: Schema della generalizzazione utente

Questa generalizzazione, riportata in figura 5.3, è dovuta alla possibilità di

introduzione delle fotografie sia da parte dell’utente che effettua l’ordine sia da parte
del fotografo proprietario del negozio, in modo da poter vendere anche foto di eventi
di particolare rilievo, quali la Bavisela o concerti importanti, realizzate dallo stesso.
Quest’ultime foto faranno parte di una serie di gallerie tematiche accessibili dai
clienti in negozio tramite terminale oppure tramite il web con una serie di
fotogallery, e potranno decidere quale formato desiderano e in quante copie,
procedendo all’acquisto nello stesso modo nel quale viene fatto qualora le foto
vengano caricate dagli stessi.

Questo tipo di generalizzazione è di tipo totale ed esclusiva infatti tutti gli utenti
posso essere divisi in queste due categorie la cui appartenenza ad una esclude
automaticamente la possibilità di essere nell’altra, e non esistono ulteriori categorie
nelle quali suddividere gli utenti.

5.3.2 Generalizzazione foto

16
 FOTO

GALLERIA FOTO UTENTE

Figura 5.4: Schema generalizzazione foto

Nella generalizzazione riportata nella figura 5.4, si può vedere come le foto sia di
due categorie distinte con proprietà ben diverse. Le foto possono essere di tipo
privato e correlate ad un preciso ordine, quelle inserite dall’utente in fase della
creazione della richiesta, oppure di tipo pubblico, visibili e acquistabili da tutti gli
utenti, che solitamente fanno parte di una raccolta creata dal gestore del negozio, che
raccoglie tutte le sue foto più rappresentative degli eventi che ha seguito.

La tipologia in cui rientra questa generalizzazione è quella delle totali ed esclusive,

infatti le foto che un cliente porta nello studio sono di proprietà dello stesso e quindi
non vengono pubblicate nelle gallerie pubbliche a meno che il fotografo non ne
acquisti i diritti (a questo punto diventano di proprietà del fotografo). Inoltre non
esistono ulteriori categorie in cui suddividere le immagini catalogate nel database, se
non le due sovra citate.

5.3.3 Generalizzazione sconto

SCONTO

PERSONALE FORMATO

17
 Figura 5.5 : Generalizzazione dell’entità sconto

Questa generalizzazione scaturisce dalla necessità di creare tipologie di sconto

diverse in base alla persona, esempio un fotografo affiliato oppure un cliente
affezionato. Inoltre vengono effettuati degli sconti se vengono comprati determinati
formati in grande quantità, quindi questi sconti non sono effettuati su tutti gli acquisti
di quella determinata persona, ma solo su quel determinato formato.

5.3.4 Generalizzazione listino

LISTINO

LISTINO
LISTINO FOTO
GALLERIA

Figura 5.6 : Generalizzazione dell’entità listino

Questa generalizzazione nasce dalla necessità di definire un prezzo diverso per una
foto appartenente ad una galleria creata dal fotografo, nella quale si debbono pagare
anche i diritti di utilizzo dell’immagine, da quelle caricate da un cliente, che non
necessitano di particolari sovrapprezzi.

18
5.4 Diagramma Entità-Relazioni con le generalizzazioni

19
 LISTINO
LISTINO FOTO
GALLERIA

POSSIEDE PREPAGATA TIPO

PAGA LISTINO

UTENTE ORDINA FOTO PROPRIETA’ FORMATO PREZZO

MODALITA’
STAMPA

CLIENTE FOTOGRAFO GALLERIA FOTO UTENTE

STAMPANTE

TIPOLOGIA

SCONTO

PERSONALE FORMATO

Figura 5.7: schema ER con le generalizzazioni

In questo schema, figura 5.7, si può vedere come interagiscono le generalizzazioni

con l’estensione dello schema entità relazioni precedentemente ampliato.

5.5 Analisi delle entità

Ora si procederà alla stesura delle caratteristiche di ciascuna entità, in modo da
terminare gli attributi di ciascuna.

20
Entità utente

UTENTE

ID Codice che identifica UNIVOCAMENTE il cliente

CHIAVE PRIMARIA

Anagrafica Questo attributo consente la registrazione delle

informazioni personali dell’utente.
ATTRIBUTO COMPOSTO: all’interno di esso troviamo
molti campi quali il nome, cognome, data di nascita,
luogo di nascita…

Anagrafica_Domicilio Questo attributo facoltativo consente di indicare un

indirizzo diverso per la spedizione della merce
ATTRIBUTO COMPOSTO

Registrazione_Utente Se l’anagrafica è stata controllata in modo da evitare la

spedizione incontrollata della merce

Identificativo_Utente Per la connessione tramite web identificativo nome utente

e password ATTRIBUTO COMPOSTO

Entità sconto personale

SCONTO PERSONALE

ID Codice che identifica univocamente la tipologia di sconto

personale

21
 CHIAVE PRIMARIA

Nome_Sconto Nome rappresentativo dello sconto

Sconto Percentuale di sconto

Descrizione Descrizione della tipologia di sconto con particolari

riguardardanti la loro attivazione

Entità sconto formato

SCONTO FORMATO

ID Codice che identifica univocamente la tipologia di sconto

sul particolate tipo di formato
CHIAVE PRIMARIA

Nome_Sconto Nome rappresentativo dello sconto

Sconto Percentuale di sconto

Descrizione Descrizione della tipologia di sconto in base alla quantità

di copie di un determinato formato, con eventuali
particolarità

Entità prepagata

PREPAGATA

ID Codice che identifica in maniera univoca la tipologia di

prepagata

Nome_Prepagata Nome rappresentativo della prepagata

Formato Formato alla quale è riferito la prepagata

Quantità Numero di foto disponibili, di un particolare formato con

22
 questa tipologia di prepagata

Prezzo Costo della carta prepagata

Entità Formato

FORMATO

ID Codice che identifica in maniera univoca la tipologia di

formato presente CHIAVE PRIMARIA

Nome_Formato Nome della tipologia di formato

Caratteristiche_Formato Attributo che identifica la tipologia di formato mediante

le sue caratteristiche, questo è un ATTRIBUTO
COMPOSTO che raccoglie l’altezza eccetera

Risoluzioni_Formato Raccoglie tutte le risoluzioni minime e massime ch ele

foto inviate devono avere per essere processate con quel
determinato formato. ATTRIBUTO COMPOSTO che
raccoglie altezze e larghezze, massime minime ed ottimali

Entità foto

FOTO

ID Attributo che identifica in modo univoco la foto caricata

nel sistema. CHIAVE PRIMARIA

Nome_Foto Il nome del file della foto

File Il caricamento della foto nel database

Entità Foto galleria

FOTO GALLERIA

ID Attributo che identifica in modo univoco la galleria a cui

23
 appartengono determinate foto. CHIAVE PRIMARIA

Nome_Galleria Il nome della galleria fotografica

Descrizione Descrizione sommaria della tipologia di galleria

fotografica

Data Data di inserimento della galleria fotografica

Entità listino foto

LISTINO FOTO

ID Attributo che identifica univocamente il prezzo applicato

ad un determinato articolo . CHIAVE PRIMARIA

Prezzo Costo dell’acquisto di questa tipologia di stampa

Entità listino galleria

LISTINO GALLERIA

ID Attributo che identifica univocamente il prezzo applicato

ad una determinata galleria . CHIAVE PRIMARIA

Prezzo Costo dell’acquisto di una stampa di questa determinata

galleria

24
Entità Stampante

STAMPANTE

ID Attributo che identifica in modo inequivocabile la

stampante . CHIAVE PRIMARIA

Nome Nome del macchinario di stampa

DNS Indirizzo della macchina

5.6 Analisi delle relazioni

Qui si procede con la descrizione delle relazioni che intercorrono nel database e delle
loro proprietà ed eventuali attributi.

Relazione ordina

ORDINA

Descrizione relazione Questa relazione lega gli utenti alle foto che decidono di
ordinare

Cardinalità MOLTI A MOLTI: Lega tutti gli utenti alle foto che
hanno ordinato

Attributi - Data ordine: si definisce così la data di creazione

dell’ordine
- Data consegna: viene definita dall’addetto
all’elaborazione dell’ordine in base alle
caratteristiche delle stampe da effettuare

Relazione possiede

POSSIEDE

25
Descrizione relazione Questa relazione lega gli utenti alle carte prepagate che
possono possedere, infatti un utente può avere molte
prepagate, una per formato, ed ad una tipologia di
prepagate possono corrispondere

Cardinalità MOLTI A MOLTI: in questo caso si legano i vari tipi di

prepagata ai vari utenti che le possiedono

Attributi - Credito residuo: definisce la quantità di credito

che la carta ancora ha al suo interno dopo i vari
ordini effettuati dai clienti

Relazione paga

PAGA

Descrizione relazione Questa relazione lega una determinata prepagata ad una

serie di foto appartenenti ad un formato ordinate da un
cliente

Cardinalità UNO A MOLTI: lega una prepagata ad alcune foto di un

determinato ordine

Attributi Non presenta attributi

Relazione tipo

TIPO

Descrizione relazione Questa relazione lega il formato alle varie prepagate che
si differenziano per la quantità di foto di quel determinato
formato che possono contenere. Esempio i diversi tagli di
ricarica

26
Cardinalità UNO A MOLTI: lega un formato con diverse prepagate

Attributi Non presenta attributi

Relazione proprietà

PROPRIETA’

Descrizione relazione Questa relazione lega ciascuna foto che si desidera

stampare

Cardinalità UNO A MOLTI: ogni foto può essere legata ai vari

formati in cui si desidera la stampa

Attributi - Copie: numero di copie che si vuole di quella foto

in quel determinato formato

Relazione modalità stampa

MODALITA’ STAMPA

Descrizione relazione Questa relazione lega un determinato formato ad una

determinata stampante

Cardinalità UNO A MOLTI: più formati possono essere stampati da

una stampante ben definita

Attributi Non presenta attributi

27
Relazione prezzo

PREZZO

Descrizione relazione Questa relazione lega un determinato formato al suo

prezzo

Cardinalità UNO A UNO: ciascun formato deve essere collegato ad

un determinato prezzo

Attributi Non presenta attributi

Relazione prezzo galleria

PREZZO GALLERIA

Descrizione relazione Questa relazione lega la galleria ad una determinato

prezzo presente nel listino

Cardinalità UNO A UNO: ciascuna galleria ha un determinato prezzo

in base al formato in cui si desidera la stampa

Attributi Non presenta attributi

28
29
30
5.7 Schema entità relazioni con i relativi attributi finale
Figura 5.8: Lo schema entità e relazioni finale

Nell’immagine sopra riportata possiamo vedere lo schema finale ricavato dall’analisi

concettuale dei requisiti del database. In questa fase si vedono ancora presenti delle

31
generalizzazioni che poi nella fase di progettazione logica si procederà ad eliminare
utilizzando diverse tecniche.

32
6 Progettazione del database: progettazione logica

In questa fase si parte dallo schema finale, entità relazioni, ottenuto dalla
progettazione logica e si procede con l’eliminazione di eventuali parti non
implementabili e la valutazione della funzionalità del database così realizzato. Verrà
seguito il seguente schema:

 Valutazione dei costi delle operazioni possibile nel database

 Eliminazione delle ridondanze presenti nel database

 Conversione delle generalizzazioni ed eliminazione delle ridondanze presenti

 Gestione degli attributi composti

Una volta analizzati i punti elencati precedentemente si otterrà lo schema definitivo

del database che può essere implementato in SQL Server.

33
6.1 Valutazione dei costi
Ogni singola operazione eseguita sul database ha una determinata frequenza di
ripetizione che influenza il grado di utilizzo di determinate funzioni piuttosto che
tabelle insistenti in un database. Grazie a questa analisi possiamo valutare quali sono
le funzioni più importanti.

Non tutte le operazioni che si possono ipotizzare su questo tipo di database non
debbono essere realizzabili dall’utente, infatti se quest’ultimo elimina informazioni
importanti è possibile che venga a crearsi la presenza di dati inconsistenti all’interno
del database oppure, nel peggiore dei casi, l’impossibilità di accedere ad alcuni dati
per perdita di integrità. Un esempio di una operazioni che non può essere effettuata
da un utente è, per esempio, l’eliminazione di un formato, anche se attualmente non
più presente in catalogo, perché tutti gli ordini creati in precedenza che possiedono
come formato foto tra quelle ordinate quest’ultimo, non sarà possibile ottenere per
esempio una copia della fattura oppure determinare il prezzo per quella foto. Anche il
listino prezzi diventerà inconsistente perché legato a formati foto non più esistenti.
Piuttosto di eliminare sarebbe meglio indicare come non utilizzato, magari mediante
una indicazione vero falso, in modo da non creare incongruenze.

Ciascuna operazione che si intende effettuare nel database può essere di diverse
tipologie quali: interattiva, se l’operazione deve essere eseguita direttamente
dall’utente, quali ad esempio inserimenti ed eliminazioni; batch, azioni che vengono
eseguite in automatico dal sistema senza la necessità che l’utente intervenga
direttamente.

Nella tabella sottostante vediamo indicate le varie operazioni che vengono eseguite
nel database, la loro tipologia e la frequenza ipotetica di esecuzione. Si vedrà come
queste rispettino la legge dell’80/20 cioè il 20% delle operazioni fatte su un database
sono quelle che coprono l’80% del totale delle operazioni. Questo deriva dal fatto
che ci sono alcune operazioni la cui esecuzione è molto rara perché poco utilizzate.

34
 OPERAZIONE TIPOLOGIA FREQUENZA

Inserimento nuovo cliente Interattiva 1 volta al giorno

Modifica cliente Interattiva 1 volta ogni 6 mesi

Cancellazione cliente Interattiva 1 volta l’anno

Inserimento formato Interattiva 1 volta l’anno

Modifica formato Interattiva 1 volta l’anno

Inserimento listino Interattiva 4 volte l’anno

Modifica listino Interattiva 1 volta l’anno

Eliminazione voce listino Interattiva 4 volte l’anno

Nuovo ordine Interattiva 6 volte al giorno

Cancellazione ordine Interattiva 1 volta al mese

Inserimento foto Interattiva 20 volte al giorno

Cancellazione foto Interattiva 1 volta al mese

Inserimento galleria Interattiva 1 volta ogni 6 mesi

Cancellazione galleria Interattiva 1 volta all’anno

Inserimento tipologia Interattiva 1 volta all’anno

prepagata

Cancellazione tipologia Interattiva 1 volta l’anno

prepagata

Nuova prepagata Interattiva 1 volta al mese

Cancella prepagata Interattiva 1 volta all’anno

35
6.2 Conversione delle generalizzazione ed eliminazione delle ridondanze
Ora si procede con il raffinamento del diagramma in modo da eliminare le
generalizzazioni.

6.2.1 Generalizzazione Utente

Per questa generalizzazione si può tranquillamente eliminare introducendo un campo
che identifichi la differenza tra un utente cliente e il fotografo che inserisce le foto
nelle gallerie. Quindi con un campo chiamato ruolo si possono determinare le
possibilità di azione degli utenti registrati.

UTENTE

ID
Anagrafica /
Anagrafica Domicilio /
Registrazione utente
Identificazione utente /
Ruolo

CLIENTE FOTOGRAFO UTENTE

Figura 6.1: La generalizzazione prima e come viene risolta

6.2.2 Generalizzazione Foto

Questa generalizzazione viene eliminata introducendo una relazione tra l’entità foto e
l’entità galleria. In questo modo si crea una relazione 0 a 1 in modo che una foto può
oppure no appartenere ad una galleria, e ad una galleria possono appartenere diverse
foto.

36
 FOTO

GALLERIA FOTO UTENTE

Figura 6.2: Generalizzazione foto

FOTO APPARTIENE GALLERIA

ID ID
Nomefoto Nome galleria
Foto Descrizione
Data

Figura 6.3: Risoluzione della generalizzazione foto

6.2.3 Generalizzazione Sconti

Vengono create due entità una per lo sconto derivante da una rilevante quantità di un
determinato formato di foto, una per lo sconto per una determinata persona su tutti
gli acquisti che compie.

In questo modo si elimina la generalizzazione e vengono create due nuove relazioni,

una che lega l’utente con lo sconto personale, che può anche non esistere, un’altra
che lega il tipo di formato e una determinata prepagata.

37
 SCONTO

PERSONALE FORMATO

Figura 6.4: Generalizzazione sconto

AGEVOLAZIO
UTENTE SCONTO
NE

Figura 6.5: Relazione utente sconto

Percentuale
sconto

PREPAGATA SCONTO FORMATO

Figura 6.6: Relazione prepagata formato

6.2.4 Generalizzazione listino

Questa generalizzazione viene risolta lasciano nell’entità listino solo un prezzo il
quale poi in base al formato che verrà diviso in formato normale o galleria, quindi il
formato viene diviso in due il quale poi viene collegato alle rispettive foto. Inoltre il
prezzo della galleria non è soggetto a sconti in base alla quantità acquistata.

38
 LISTINO
LISTINO FOTO
GALLERIA

ID
Prezzo

LISTINO LISTINO

Figura 6.7: Trasformazione della generalizzazione listino

6.3 Eliminazione delle relazioni ridondanti

In primo luogo si è passati all’esaminare il caso qui sotto riportato nella figura 8:

POSSIEDE PREPAGATA

PAGA

UTENTE ORDINA FOTO

Figura 6.8: relazioni implicante l’azione di ordinazione di un nuovo quantitativo di

foto

Come possiamo vedere la relazione che lega l’utente a paga è ridondante perché già
l’utente è legato ad una determinata tipologia di prepagata la quale a sua volta è
legata ad una formato quindi ad alcune foto, oppure ad una. Quindi abbiamo al
trasformazione della ridondanza nel modo seguente:

39
 POSSIEDE PREPAGATA

PAGA

UTENTE ORDINA FOTO

Figura 6.9: ristrutturazione dello schema

6.4 Eliminazione degli attributi composti

Si è cercato di creare delle entità a loro stanti per gli attributi composti, per esempio
con la divisione tra l’anagrafica consueta, e la non obbligatoria del domicilio. In
questo modo si è evitato di appesantire la tabella ed evitare scritture inutili.

All’interno dell’entità utente comunque rimane la consueta anagrafica.

UTENTE SPEDIZIONE DOMICILIO

Figura 6.10: eliminazione dell’attributo composto anagrafica domicilio

Nello stesso modo per i formati le risoluzioni sono state messe in una entità diversa
in modo da evitare di sovraccaricare la tabella.

CARATTERIS
FORMATI RISOLUZIONI
TICHE

Figura 6.11: realizzazione dell’entità risoluzioni

40
7 Il database
In questo capitolo si tratterà dello schema finale del database e della sua struttura.
Inoltre si analizzeranno sommariamente le tabelle che lo compongono.

7.1 Schema completo del database

Lo schema completo si trova nell’appendice A per motivi di grandezza.

7.2 Le tabelle
Tabella anagrafica

41
 Figura 7.1: Tabella anagrafica

Questa tabella raccoglie i dati principali anagrafici del cliente, inoltre raccoglie le
credenziali di accesso tramite web. Con il campo stato si definisce la tipologia di
cliente e quindi lo sconto al quale avrebbe diritto.

Tabella Utenti domicilio

Figura 7.2: Tabella domicili

Questa tabella raccoglie i dati facoltativi su un eventuale recapito alternativo al quale

spedire la merce ordinata.

Tabella Utenti ruoli

Figura 7.3: Tabella utenti ruoli

Tabella di sponda utilizzata per definire le tipologie di ruolo che un utente ha per
esempio gli sconti fatti solo sulla persona e non anche sulla tipologia di formato
posseduto.

42
Tabella Ruoli

Figura 7.4: Tabella ruoli

Tabella che raccoglie il nome della tipologia di sconto e nella descrizione le sconto
ottenibile appartenendo a quella determinata categoria. Non solo posso essere
definite categorie per la velocizzazione del processo di elaborazione dell’ordine.

Tabella Provincia

Figura 7.5: Tabella Provincia

Utilizzata per semplificare l’immissione tramite una combo box della provincia
desiderata in modo da non doverla immettere tutte le volte a mano.

Tabella Stato

Figura 7.6: Tabella Stato

Utilizzata per semplificare l’immissione tramite una combo box degli stati desiderati.

43
Tabella foto

Figura 7.7: Tabella foto

Permette l’inserimento di una nuova foto, che essa sia di galleria o normale
permettendo di determinarne le caratteristiche e l’utente che l’ha inserita. La foto
viene poi caricata nel campo foto in modo che ne rimanga una copia sul database.

Tabella Gallerie

Figura 7.8.: Tabella gallerie

Tabella che riassume le caratteristiche principali della galleria con la relativa data di
creazione.

Tabella Ordini:

44
 Figura 7.9: Tabella ordini

In questa tabella viene definita la data d’ordine , quella di consegna e l’utente il quale
ha fatto l’ordine. Inoltre è stato indicato un eventuale numero per indicare
eventualmente una cronologia con altri ordini.

Tabella Ordini Foto

Figura 7.10: Tabella ordini foto

Questa tabella di sponda unisce un determinato ordine con una particolare foto la
quale può essere stampata con diversi formati, e quindi con il relativo formato. In
particolare si definiscono il numero di copie che si intendono effettuare.

Tabella Sconti

Figura 7.12: Tabella Sconti

Tabella che definisce le classi di sconto su un determinato formato.

45
Tabella Utenti Sconti

Figura 7.13: Tabella utenti sconti

Tabella di sponda creata per determinare uno sconto su un particolare formato per un
particolare cliente.

Tabella Formati

Figura 7.14: Tabella formati

Definisce i formati delle vari fotografie con le loro caratteristiche e la tipologia di

carta.

Tabella Formati Risoluzioni

Figura 7.15: Tabella Formati risoluzioni

46
Qui vengono indicate le specifiche particolari dei vari formati.

Tabella Prepagate Quantità

Figura 7.16: Tabella Prepagate Quantità

Tabella che definisce il riferimento di una determinata tipologia di prepagata ad un

utente in modo che se ne possa verificare dopo le operazioni il credito residuo.

Tabella Prepagate

Figura 7.17: Tabella Prepagate

Tabella che identifica e caratterizza ciascun tipo di prepagata.

Tabella Sistema Stampa

47
 Figura 7.18: Tabella Sistema stampa

Identifica ciascun sistema di stampa con i formati da lui supportati e ne caratterizza i

parametri principali di funzionamento.

Tabella Listino

Figura 7.19: Tabella Listino

La tabella consente la definizione dei vari prezzi di listino per ciascun tipo di
formato.

48
8 Interfaccia del progetto
In questo capitolo si prenderà in esame l’interfaccia utente del progetto.
Principalmente si analizzerà l’interfaccia principale, e di una interfaccia presente su
un pc alla quale è collegata una delle macchine stampanti.

8.1 Installazione del sistema

Questo progetto non prevede grossi problemi di installazione se non l’accortezza da
parte del sistemista che prevederà gli accessi di creare i giusti login con i reali diritti
per ciascuna tipologia di persona che avrà a che fare con il sistema. Infatti alcune
store procedure, in particolare quelle che prevedono la cancellazione di dati, devono
essere eseguite solo da personale che sia a conoscenza dei rischi che l’esecuzione di
un tale comando comporta. Per questo si necessita di una accurata gestione degli
accessi e dei permessi.

8.2 Interfaccia principale

Le funzionalità dell’interfaccia principale sono quelle dell’amministrazione delle
attività, che vanno dalla gestione dell’anagrafica alla introduzione di nuovi ordini che
vengono richiesti in negozio. Deve permettere l’accesso alle funzionalità più
importanti tralasciando al parte operativa ad altre interfacce poste vicino alle
macchine dedite alla stampa.

Principalmente le funzioni importanti che debbono essere implementate sono le

seguenti:

 Gestione dell’anagrafica

49
  Gestione degli ordini

 Gestione del listino

 Visualizzazione delle gallerie ai clienti

PAGINA INIZIALE

ANAGRAFICA LISTINO

NUOVA MODIFICA NUOVA ELIMINA

NUOVO MODIFICA
ANAGRAFICA ANAGRAFICA PREPAGATA PREPAGATA

INSERIMENTO
NOME UTENTE

ORDINI GALLERIA

VISUALIZZA VISUALIZZA MODIFICA

NUOVO ORDINE ELIMINA ORDINE PREVENTIVO
ORDINE

Figura 8.1: Schema delle funzioni principali dell’interfaccia

8.3 Interfaccia di un sistema di stampa

Questa interfaccia risulta meno articolata di quella principale, infatti presenta solo le
seguenti funzioni:

 Eliminazione di una foto dalla coda di stampa

 Controllo della coda di stampa

50
L’eliminazione della foto dalla coda di stampa implica la sua cancellazione dal
dataset il quale poi potrà essere letto da un’altra applicazione che permette la lettura
da parte della macchina stampante della coda di stampa.

La sua interfaccia risulterà essere la seguente:

Figura 8.2: Interfaccia grafica della stampante

51
9 Esempi di utilizzo
9.1Creazione di un ordine

Figura 9.1: Form di autenticazione

Per prima cosa l’operatore del negozio si trova di fronte alla necessità di inserire le
proprie credenziali le quali permettono l’assegnazione delle operazioni che è
possibile effettuare.

Qualora il login sia erroneo apparirà una finestra di errore come quella che segue

52
 Figura 9.2: Finestra di errore

Una volta tornati alla finestra di autenticazione si ha la possibilità di decidere se

continuare oppure abbandonare il programma.

Se il login ha successo apparirà la form principale la quale consente di selezionare

l’attività desiderata.

Se si vuole inserire una nuova anagrafica cliente basta procedere nel modo che
segue:

53
 Figura 9.3: Form principale modifica angrafica

Selezionando nuova anagrafica apparirà una schermata come segue:

54
 Figura 9.4: Form anagrafica

La form qui sopra riportata, fig. 9.4, è utilizzata per inserire i dati relativi al cliente.
Se quest’ultimo richiede la spedizione in un luogo diverso dalla residenza, necessaria
per la fatturazione, basta spuntare il relativo capo per permettere l’inserimento
dell’eventuale indirizzo alternativo.

Se l’utente è già registrato nel sistema non è necessario il passo sopradescritto quindi
si passa al punto successivo con l’inserimento dei dati del nuovo ordine. Se le foto
desiderate appartengono solo ad una galleria già esistente basta spuntare e si ottiene
la sparizione del tasto carica foto e si apre direttamente una form nella quale basta
selezionare la foto della galleria, la quantità e il formato e si può procedere con
l’acquisto.

55
 Figura 9.5: Inserimento nuovo ordine

Nel caso invece le foto siano dell’utente e si necessiti del caricamento basta premere
il pulsante relativo ed apparirà la form che segue, figura 9.6.

Figura 9.6: Caricamento immagini

56
Dopo l’inserimento del numero di copie e il formato desiderato premendo il pulsante
preventivo si otterrà il prezzo dell’ordine altrimenti si può procedere col caricamento
e con la definizione del metodo di pagamento con la finestra che segue, fig 9.7.

Figura 9.7: Selezione metodo di pagamento

Se il credito della prepagata intestata al cliente risulti con credito inferiore a quello
necessario all’acquisto si prevede un messaggio d’errore e la possibilità di
selezionare il pagamento della differenza o in negozio o tramite l’acquisto di una
nuova prepagata.

9.2Creazione di un report di preventivo da un ordine già esistente:

57
 Figura 9.8: Finestra principale

Per prima cosa si apre la form principale, se è già stato autenticato l’utilizzatore del
programma, figura 1, nella quale troviamo la sottoscheda ordini. Da qui si procede
con la selezione di preventivo. Da qui si apre una finestra nella quale ci viene
richiesto di inserire il nome e cognome dell’utente da cercare, figura 9.8. Da qui se
non ci sono ambiguità di nome ci appaiono le date degli ordini, altrimenti una
finestra che ci fa scegliere quale dei due utenti.

Figura 9.9: Form di ricerca ordine

Selezionando una data precisa di ordine ci apparirà il preventivo in Crystal Report

corrispondente, figura 9.10.

58
Figura 9.10: Report del preventivo dell’ordine

59
10 Interfaccia grafica: esempi di codice

10.1Caricamento foto
Il codice che segue rappresenta una parte particolare del sistema quella del
caricamento delle foto. Infatti si tratta dell’interfacciamento con la store procedure di
riferimento e la trasformazione del file in una serie di byte, tramite la classe
filestream in modo da poterlo inserire in un campo varchar (MAX) ed essere salvato
nel database

Carica immagini (interfacciamento con la store procedure e connessione al

database)
public void CaricaImmagini(int IdUtente, int IDOrdine, Byte file,
string galleria, string copie, string nomefile, string IDFormato)
{
this.IdUtente=IdUtente;
this.file = file;
this.galleria = galleria;
this.IDOrdine = IDOrdine;
this.nomefile = nomefile;
this.IDFormato = IDFormato;
SqlConnection cn = new SqlConnection(connSQL);

SqlCommand cmd = cn.CreateCommand();

cmd.CommandText = "InserisciFoto";
cmd.Parameters.Add("@Id", SqlDbType.Int);

cn.Open();

cmd.Parameters["@IDUtente"].Value = IdUtente;

60
 cmd.Parameters("@IDOrdine").Value = IDOrdine;
cmd.Parameters("@Foto").Value = file;
cmd.Parameters("@IDGalleria").Value = galleria;
cmd.Parameters("@Copie").Value = copie;
cmd.Parameters("@NomeFile").Value = nomefile;
cmd.Parameters("@IDFormato").Value = IDFormato;
SqlDataAdapter da = new SqlDataAdapter();
da.SelectCommand = cmd;
cmd.ExecuteNonQuery();

cn.Close();
}

Carica immagini (creazione dei dati da passare poi alla store procedure)

private void CaricaImmagini_Load(object sender, EventArgs e, int

idutente, int idordine)
{
string ind = Path.Text;
this.idutente = idutente;
this.idordine = idordine;

for ( int i = 0; i < dataGridView1.Rows.Count; i++){

object cella = dataGridView1.Rows[i].Cells[0].Value;
string cella1 = Convert.ToString(cella);
string a = (ind + '\\' + cella1);
FileStream fs = new FileStream(a);
Byte[] temp = new Byte(fs.Length);
fs.Read(temp, 0, fs.Length);
fs.Close();
object cellaaa =
dataGridView1.Rows[i].Cells[1].Value;
string formato1 = Convert.ToString(cellaaa);
object cellabb =
dataGridView1.Rows[i].Cells[2].Value;
string copie1 = Convert.ToString(cellabb);
object cellacc =
dataGridView1.Rows[i].Cells[3].Value;
string galleria1 = Convert.ToString(cellacc);
CaricaImmagini(idutente, idordine, temp, galleria,
copie, cella1, IDFormato);

Tutti gli altri metodi dell’interfaccia grafica insistono soprattutto nella parte della
creazione delle connessioni con il database quindi ritengo superfluo descriverle una
per una.

61
11 Conclusioni
Gli obiettivi richiesti dal committente sono stati di massima raggiunti, infatti il
progetto rispecchia le caratteristiche da lui desiderate.

Raggiungimento degli obiettivi:

 Definizione dei requisiti di tutto il sistema tramite incontro con il

committente del progetto: raggiunto

 Studio delle piattaforme SQL Server 2008 e Visual Studio 2008, in

particolare il linguaggio C#, Crystal report, necessarie per l’implementazione.
(Caratteristiche richieste dal committente): raggiunto

 Studio della struttura del database creazione del diagramma ER: raggiunto

 Ristrutturazione del diagramma: raggiunto

 Creazione della struttura database in SQL con le relative store procedure:

raggiunto

 Realizzazione dell’interfaccia associata: raggiunto

62
Questo progetto però ancora non è stato testato nel reale sistema lavorativo, ma solo
tramite il software a mia disposizione. La fase successiva sarà infatti di riunirlo con
gli altri pezzi costruiti da altre persone in modo da vedere se l’intero sistema
funziona, eventualmente controllare che i requisiti nel tempo non siano variati.
Eventuali sviluppi futuri potrebbero essere l’integrazione con il sistema realizzato
con quello di fatturazione, che ad ora risulta separato e quindi necessita di un doppio
inserimento dei dati dei compensi ricavati dai vari ordini effettuati.

63
64
Appendice A

65
66
Appendice B
Store procedure create

Visualizzazione stati

ALTER PROCEDURE [dbo].[VisualizzaStati]

AS
BEGIN

SELECT IDStato, NomeStato FROM Tbl_Stato

END

Visualizzazione sconti
ALTER PROCEDURE [dbo].[VisualizzaSconti]
AS
BEGIN

SELECT IdSconti, Descrizione FROM Tbl_Sconti

END

Visualizzazione Ruoli
ALTER PROCEDURE [dbo].[VisualizzaRuoli]

AS
BEGIN

SELECT Id_Ruoli, Nome FROM Tbl_Ruoli

END

67
Visualizzazione Provincia
ALTER PROCEDURE [dbo].[VisualizzaProvincia]
AS
BEGIN

SELECT IDProvincia, NomeProvincia FROM Tbl_Provincia

END

Visualizzazione Prepagate
ALTER PROCEDURE [dbo].[VisualizzaPrepagate]

AS
BEGIN

SELECT Nome, ID FROM Tbl_Prepagate

END

Visualizzazione Ordini
ALTER PROCEDURE [dbo].[VisualizzaOrdini]
AS
BEGIN

SELECT IdOrdine, DataOra, IdUtente FROM Tbl_Ordine

END

Visualizzazione Listino
ALTER PROCEDURE [dbo].[VisualizzaListino]
AS

68
BEGIN
SELECT Tbl_Listino.IdFormato, Tbl_Listino.Prezzo, Tbl_Formati.Tipo FROM
Tbl_Listino,Tbl_Formati
WHERE Tbl_Formati.ID = Tbl_Listino.IdFormato
END

Visualizzazione Galleria
ALTER PROCEDURE [dbo].[VisualizzaGallerieNome]

AS
BEGIN

SELECT ID_Gallerie, Titolo FROM Tbl_Gallerie

END

Visualizzazione Foto
ALTER PROCEDURE [dbo].[VisualizzaFoto]
@IDUtente int

AS
BEGIN

SELECT Id_Foto, NomeFile, Foto FROM Tbl_Foto where IdUtente =

@IDUtente
END

Visualizzazione Formati
ALTER PROCEDURE [dbo].[VisualizzaFormati]
AS

69
BEGIN
SELECT ID, Tipo FROM Tbl_Formati
END

Visualizzazione Preventivo
ALTER PROCEDURE [dbo].[Report]
@Id as int
AS
BEGIN
SELECT Tbl_OrdiniFoto.IDFormato, Tbl_OrdiniFoto.Copie,
Tbl_Listino.Prezzo, Tbl_Formati.Tipo FROM Tbl_OrdiniFoto, Tbl_Listino,
Tbl_Formati
WHERE Tbl_OrdiniFoto.IDOrdine = @Id AND Tbl_Listino.IDFormato=
Tbl_OrdiniFoto.IDFormato AND Tbl_Formati.ID= Tbl_OrdiniFoto.IDFormato
END

Ottieni ID
ALTER PROCEDURE [dbo].[OttieniID]
@Cognome nvarchar (50),
@Nome nvarchar (50)

AS
BEGIN

SELECT ID FROM Tbl_Anagrafica WHERE Cognome = @Cognome and

Nome = @Nome
END

Inserimento nome utente

ALTER PROCEDURE [dbo].[NomeUtente]

70
 @NomeUtente nvarchar (50),
@Password nvarchar (50),
@ID int
AS
BEGIN

UPDATE Tbl_Anagrafica SET NomeUtente = @NomeUtente, [Password]=

@Password WHERE ID=@ID
END

Inserimento tipologia prepagata

ALTER PROCEDURE [dbo].[InserisciTipologiaPrepagata]
@Nome nvarchar (50),
@IDFormato int,
@Quantità int,
@Prezzo money

AS
BEGIN
Insert into Tbl_Prepagate (Nome, ID, Quantità, Prezzo)
values (@Nome, @IDFormato, @Quantità, @Prezzo)

END

Inserimento nuova prepagata

ALTER PROCEDURE [dbo].[InserisciPrepagata]
@IDUtente int,
@IDPrepagata int

71
AS
BEGIN
Declare @rimanenza as money
set @rimanenza = (Select Prezzo From Tbl_Prepagate Where ID =
@IDPrepagata)
Insert into Tbl_PrepagateQuantita (IDUtente, IDPrepagata, Rimanenza)
values (@IDUtente, @IDPrepagata, @rimanenza)

END

Inserimento nuovo ordine

ALTER PROCEDURE [dbo].[InserisciOrdine]
@IDUtente int,
@Numero int,
@DataConsegna datetime

AS
BEGIN
Declare @oracorrente as datetime
set @oracorrente= getdate ()
Insert into Tbl_Ordini (IdUtente, DataOra, Numero, ConsegnaEntroIl)
values (@IDUtente, @oracorrente, @Numero, @DataConsegna)

END

Inserimento listino
ALTER PROCEDURE [dbo].[InserisciListino]
@IDFormato int,

72
@Prezzo money,
@PrezzoGalleria money
AS
BEGIN

Insert into Tbl_Listino (IdFormato, Prezzo, PrezzoGalleria)

values (@IDFormato, @Prezzo, @PrezzoGalleria)
END

Inserimento nuova galleria

ALTER PROCEDURE [dbo].[InserisciGalleria]
@Titolo nvarchar (50),
@Descrizione nvarchar (200)

AS
BEGIN
Declare @oracorrente as datetime
set @oracorrente= getdate ()
Insert into Tbl_Galleria (Titolo, Data, Descrizione)
values (@Titolo, @oracorrente, @Descrizione)

END

Inserimento nuova foto

ALTER PROCEDURE [dbo].[InserisciFoto]
@IDUtente int,
@IDGalleria int = NULL,
@NomeFile nvarchar (50),

73
 @IDFormato int,
@Formato nvarchar (50),
@Foto varbinary (MAX),
@Copie int,
@IDOrdine int
AS
BEGIN

Declare @a int
Insert into Tbl_Foto (IdUtente, IdGalleria, NomeFile, Formato, Foto)
values (@IDUtente, @IDGalleria, @NomeFile, @Formato, @Foto)
set @a = @@IDENTITY -- per ritornare l'ultimo valore del contatore
Insert into Tbl_OrdiniFoto (IdOrdine, IdFoto, IdFormato, Copie)
values (@IDOrdine,@a, @IDFormato, @Copie)

END

Inserimento nuova anagrafica

ALTER PROCEDURE [dbo].[InsAnagrafica]
@Cognome nvarchar (50),
@Nome nvarchar (50),
@Data datetime,
@LuogoDiN nvarchar (50) = null,
@Sesso nvarchar (1),
@Email nvarchar (50),
@Telefono nvarchar (50),
@Via nvarchar (50),
@NumeroC int = null,

74
 @Citta nvarchar (50),
@Provincia nvarchar (2),
@CAP nvarchar (10) = null,
@Stato nvarchar (50) = null,
@Sconto nvarchar (50) = null
AS
BEGIN
Declare @s int
Declare @a int
set @s = (select IdSconti from tbl_Sconti where Descrizione = @Sconto) --
se c'è solo un valore in un solo campo

Insert into Tbl_Anagrafica (Cognome, Nome, DataDiNascita,

LuogoDiNascita, Sesso, Email, Telefono, Via, NumeroCivico, Città, Provincia, CAP,
Stato)
values (@Cognome, @Nome, @Data, @LuogoDiN, @Sesso,
@Email, @Telefono, @Via, @NumeroC, @Citta, @Provincia, @CAP, @Stato)
set @a = @@IDENTITY -- per ritornare l'ultimo valore del contatore
Insert into Tbl_UtentiSconti (IdUtente, IdSconto)
values (@a, @s)

END

Cancella anagrafica
ALTER PROCEDURE [dbo].[CancellaAnagrafica]
@ID int
AS
BEGIN

75
DELETE Tbl_Angrafica WHERE ID=@ID
END

76
Bibliografia:

[Marco Ferrero, 2008] Marco Ferrero SQL, Apogeo

[Nadia Bianchi, Alessandro Valli, 2002] c# reference, McGrawHill

[Autori Vari, 2007] SQL Server, Guida per l’amministratore di rete, Hoepli

[Sharp John, 2008] Microsoft Visual C# 2008 passo per passo, Mondadori
Informatica

[MSDN, 2009] http://msdn.microsoft.com/it-it/default.aspx (referenze per le classi)

[Maurizio Fermeglia, 2009]Dispense del professor Maurizio Fermeglia su Store

Procedure e stesura requisiti database

77
Contenuto CD

• Tesi.docx

• Tesi.pdf

• Presentazione.pptx

• Presentazione.pdf

• Cartella contenente interfaccia e database

78