Sviluppo Di Una Applicazione Web Per La Gestione Di Fotografie Digitali: Il Modulo Di Amministrazione

UNIVERSITÀ

DEGLI

FACOLTÀ

INGEGNERIA

DI

STUDI

DI

TRIESTE

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: Relatore: FERMEGLIA

Martina De Faveri Chiar.mo prof. Maurizio

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 ML370TG4

Switch NETGEAR 10/100/1000 16 porte

Switch NETGEAR 10/100 16 porte

Switch NETGEAR 10/100 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

UTENTE

ORDINA

LISTINO

FOTO

PROPRIETA’

FORMATO

TIPOLOGIA

MODALITA’ STAMPA

SCONTO

STAMPANTE

PREZZO

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 GALLERIA

LISTINO FOTO

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 GALLERIA POSSIEDE

PREPAGATA

TIPO

PAGA

UTENTE

ORDINA

LISTINO FOTO

LISTINO

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

Interattiva

1 volta l’anno

Nuova prepagata

Interattiva

1 volta al mese

Cancella prepagata

Interattiva

1 volta all’anno

prepagata Cancellazione tipologia prepagata

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

/ / /

UTENTE

FOTOGRAFO

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 Foto

Nome galleria 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 NE

UTENTE

SCONTO

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 GALLERIA

LISTINO FOTO

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.

FORMATI

CARATTERIS TICHE

RISOLUZIONI

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

NUOVA ANAGRAFICA

MODIFICA ANAGRAFICA

LISTINO

NUOVA PREPAGATA

ELIMINA PREPAGATA

NUOVO

MODIFICA

INSERIMENTO NOME UTENTE

ORDINI

NUOVO ORDINE

VISUALIZZA ORDINE

ELIMINA ORDINE

GALLERIA

PREVENTIVO

VISUALIZZA

MODIFICA

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