Documentazione Basi di dati

Transcript

1 Corso di Laurea in Ingegneria Informatica ed Elettronica 08/05/2017 Documentazione Basi di dati A CURA DI: Capece Biagio Pietro & Marino Alessandro MC-SOFT DOCENTE: Ing. Denis Ferraretti

2 Sommario Specifiche Progetto... Pagina 1 Introduzione... Pagina 1 Elenco specifiche e tipi di utenti... Pagina 1 Amministratore (o Cassiere)... Pagina 1 Cameriere... Pagina 1 Pizzaiolo... Pagina 1 Barista... Pagina 1 Progettazione del diagramma E-R... Pagina 2 Dettagli entità... Pagina 2 Elenco entità... Pagina 2 Utente_pizzeria... Pagina 2 Tavolo... Pagina 3 Fattura... Pagina 3 Ordine... Pagina 4 Pizza... Pagina 5 Bibita... Pagina 6 Aggiunta... Pagina 7 Ingrediente... Pagina 8 Osservazioni sulle entità Pizza, Bibita, Aggiunta e Ingrediente... Pagina 8 Descrizione delle associazioni... Pagina 9 Emettere... Pagina 9 Prendere (Utente_pizzeria - Ordine)... Pagina 9 Riferito al... Pagina 9 Coinvolgere... Pagina 9 Contenere (Ordine - Bibita)... Pagina 9 Contenere (Ordine - Pizza - Aggiunta)... Pagina 9 Farcire... Pagina 10 Creazione del modello E-R (Entity-Relationship)... Pagina 11 Traduzione del modello E-R in modello Relazionale... Pagina 12 Passo 1: Traduzione di tipi di entità... Pagina 12 Passo 2: Traduzione di tipi di entità deboli... Pagina 13 Passo 3: Traduzione di tipi di associazioni binarie di tipo 1 : 1... Pagina 13 Passo 4: Traduzione di tipi di associazioni binarie di tipo 1 : N... Pagina 13 Passo 5: Traduzione di tipi di associazioni binarie di tipo N : M... Pagina 14

3 Passo 6: Traduzione di attributi multivalore... Pagina 14 Passo 7: Traduzione dei tipi di associazioni N-arie... Pagina 15 Normalizzazione del modello Relazionale... Pagina 16 Cenni teorici... Pagina 16 Prima forma normale (1NF)... Pagina 16 Seconda forma normale (2NF)... Pagina 16 Terza forma normale (3NF)... Pagina 16 Processo di normalizzazione... Pagina 17 Schema relazionale completo in terza forma normale (3NF)... Pagina 18 Codice SQL (Structured Query Language)... Pagina 19 Interrogazioni SQL... Pagina 22 Interfaccia grafica... Pagina 25 Schermata di Login... Pagina 25 Schermata Amministratore (o Cassiere)... Pagina 25 Schermata Cameriere... Pagina 28 Schermata Pizzaiolo... Pagina 29 Schermata Barista... Pagina 29 Stampa della fattura finale... Pagina 30

4 Specifiche Progetto Introduzione Si vuole progettare un sistema informativo per la gestione di una pizzeria attraverso un applicazione per smartphones dotati di sistema operativo Android. Gli utenti di tale sistema sono: Cameriere, Pizzaiolo, Barista e Amministratore (o Cassiere). Tale sistema utilizza un interfaccia di accesso per la distinzione dei vari utenti e per motivi di sicurezza. Elenco specifiche e tipi di utenti Amministratore (o Cassiere) L amministratore (o Cassiere) è l utente che ha la possibilità di: Vedere i tavoli liberi/occupati in ogni momento; Visualizzare i dettagli degli ordini di ogni tavolo; Modificare eventualmente il prezzo totale dell ordine (motivo: sconto o altro); Stampare (mediante una stampante termica programmata appositamente da noi) la ricevuta dell avvenuto pagamento dell ordine; Aggiungere o rimuovere tavoli; Tenere conto delle entrate giornaliere e/o mensili o stampandole (mediante una stampante termica) con in aggiunta valori di minimo, massimo e medio oppure visualizzando un grafico a linee; Visualizzare una classifica giornaliera, mensile o totale dei camerieri in base al numero di ordini effettuati; Assumere o licenziare dipendenti (Stampando le credenziali per il login del nuovo utente); Cambiare il prezzo del coperto; Aggiungere, modificare o eliminare prodotti (pizze, aggiunte, ingredienti, bibite); Impostare la disponibilità di un prodotto; Utilizzare una funzione speciale per la rimozione di tutte le righe di tutte le tabelle ad eccezione della riga il cui username è admin (altrimenti nessuno potrà effettuare l accesso in futuro), questa operazione è eseguita mediante un codice che nel caso reale deve essere richiesto al produttore del software; Modificare la propria password; Visualizzare una classifica totale dei prodotti venduti; Visualizzare uno storico di tutte le fatture emesse in base ad un mese o ad un determinato giorno. Cameriere Il cameriere è l utente che ha la possibilità di: Effettuare ordini; Modificare la propria password. Pizzaiolo Il pizzaiolo è l utente che ha la possibilità di: Visualizzare le pizze da servire appartenenti agli ordini presi dai camerieri; Modificare la propria password. Barista Il barista è l utente che ha la possibilità di: Visualizzare le bibite da servire appartenenti agli ordini presi dai camerieri; Modificare la propria password. CAPECE BIAGIO PIETRO & MARINO ALESSANDRO 1

5 Progettazione del diagramma E-R Dettagli entità Una volta analizzate le specifiche del mini-mondo per il quale si vuole realizzare il database, passiamo all identificazione e descrizione delle singole entità e dei legami che intercorrono tra di loro denominate relazioni. Elenco entità Utente_pizzeria Tale entità rappresenta il generico utente che andrà a utilizzare il sistema che si sta progettando. Figura 1 Descrizione attributi Username: chiave primaria dell entità Utente_pizzeria che identifica univocamente un utente. Il valore di tale attributo viene generato mediante la combinazione dei campi nome e cognome con relativo controllo di omonimie. Caso particolare: esiste un valore particolare, ovvero admin, che rappresenta sempre il primo utente Amministratore (o Cassiere). Tale valore è sempre presente all interno della tabella. Password: identifica la password utilizzata dall utente nella fase di autenticazione. Il valore di tale attributo viene generato casualmente e memorizzato con un algoritmo di crittografia (funzione hash MD5) in fase di registrazione dell utente, successivamente potrà essere modificata da quest ultimo. Nome: identifica il nome dell utente con un massimo di 20 caratteri. Cognome: identifica il cognome dell utente con un massimo di 20 caratteri. Tipo: identifica il tipo di utente, ovvero: c per identificare il cameriere (valore di default); a per identificare il cassiere/amministratore ; p per identificare il pizzaiolo ; b per identificare il barista. Stato: identifica lo stato dell utente, ovvero se è stato licenziato o no. Può assumere due valori di tipo intero (0 o 1); di default assume valore 0 (non licenziato). N.B. Nessuno di questi attributi può assumere il valore NULL. CAPECE BIAGIO PIETRO & MARINO ALESSANDRO 2

6 Tavolo Tale entità rappresenta i tavoli all interno della pizzeria. Figura 2 Descrizione attributi Id_tavolo: chiave primaria dell entità tavolo che identifica univocamente un tavolo. Il valore di tale attributo viene assegnato dall utente Amministratore (o Cassiere). Numero_posti_occupati: identifica il numero di posti occupati dai clienti su quel tavolo. Stato: identifica lo stato del tavolo, ovvero se il tavolo può essere utilizzato o meno. Può assumere due valori di tipo intero (0 o 1); di default assume valore 0 (tavolo utilizzabile). N.B. Nessuno di questi attributi può assumere il valore NULL. Fattura Tale entità identifica le fatture emesse dall Amministratore (o Cassiere) per un determinato tavolo. Figura 3 Descrizione attributi Id_fattura: chiave primaria dell entità fattura che identifica univocamente una fattura emessa. Il valore di tale attributo è un intero che viene incrementato automaticamente dal sistema (valore AUTO_INCREMENT). Data: identifica la data di emissione della fattura; per motivi di sicurezza e sincronizzazione viene fornita dal server. Ora: identifica l ora di emissione della fattura; per motivi di sicurezza e sincronizzazione viene fornita dal server. Prezzo: identifica il prezzo totale della fattura. N.B. Nessuno di questi attributi può assumere il valore NULL. CAPECE BIAGIO PIETRO & MARINO ALESSANDRO 3

7 Ordine Tale entità rappresenta il generico ordine di un determinato tavolo. Figura 4 Descrizione attributi Id_ordine: chiave primaria dell entità Ordine che identifica univocamente un ordine. Il valore di tale attributo viene generato automaticamente mediante la combinazione dei campi data, ora e tavolo. Data: identifica la data in cui è stato effettuato l ordine; per motivi di sicurezza e sincronizzazione viene fornita dal server. Ora: identifica l ora in cui è stato effettuato l ordine; per motivi di sicurezza e sincronizzazione viene fornita dal server. Prezzo: identifica il prezzo totale dell ordine. Bis: indica se l ordine effettuato corrisponde a un bis. Può assumere due valori di tipo intero (0 o 1); di default assume valore 0 (non bis). Note: campo utilizzato dal cameriere per prendere nota di eventuali richieste da parte dei clienti per quell ordine. Servito_pizzeria: indica se le pizze di quell ordine sono state tutte servite. Può assumere due valori di tipo intero (0 o 1); di default assume valore 0 (non servito). Servito_bar: indica se le bibite di quell ordine sono state tutte servite. Può assumere due valori di tipo intero (0 o 1); di default assume valore 0 (non servito). N.B. Ad eccezione del campo Note, nessuno degli altri attributi può assumere il valore NULL. CAPECE BIAGIO PIETRO & MARINO ALESSANDRO 4

8 Pizza Tale entità rappresenta la descrizione di una pizza. Figura 5 Descrizione attributi Id_prodotto: chiave primaria dell entità Pizza che identifica univocamente una pizza. Il valore di tale attributo viene assegnato in fase di inserimento di una nuova pizza (max. 5 caratteri). Prodotto: identifica il nome della pizza (max. 11 caratteri per motivi legati alla stampa della ricevuta fiscale). Prezzo: identifica il prezzo della pizza. Disponibilita: indica se la pizza è disponibile o meno. Può assumere due valori di tipo intero (0 o 1); di default assume valore 0 (disponibile). Stato: indica se la pizza è presente o meno nel menù. Può assumere due valori di tipo intero (0 o 1); di default assume valore 0 (presente). N.B. Nessuno di questi attributi può assumere il valore NULL. CAPECE BIAGIO PIETRO & MARINO ALESSANDRO 5

9 Bibita Tale entità rappresenta la descrizione di una bibita. Figura 6 Descrizione attributi Id_prodotto: chiave primaria dell entità Bibita che identifica univocamente una bibita. Il valore di tale attributo viene assegnato in fase di inserimento di una nuova bibita (max. 5 caratteri). Prodotto: identifica il nome della bibita (max. 19 caratteri per motivi legati alla stampa della ricevuta fiscale). Prezzo: identifica il prezzo della bibita. Disponibilita: indica se la bibita è disponibile o meno. Può assumere due valori di tipo intero (0 o 1); di default assume valore 0 (disponibile). Stato: indica se la bibita è presente o meno nel menù. Può assumere due valori di tipo intero (0 o 1); di default assume valore 0 (presente). N.B. Nessuno di questi attributi può assumere il valore NULL. CAPECE BIAGIO PIETRO & MARINO ALESSANDRO 6

10 Aggiunta Tale entità rappresenta la descrizione di una aggiunta (ovvero un ulteriore ingrediente nella pizza richiesto dal cliente). Figura 7 Descrizione attributi Id_prodotto: chiave primaria dell entità Aggiunta che identifica univocamente un aggiunta. Il valore di tale attributo viene assegnato in fase di inserimento di una nuova aggiunta (max. 5 caratteri). Prodotto: identifica il nome dell aggiunta (max. 25 caratteri). Prezzo: identifica il prezzo dell aggiunta. Disponibilita: indica se l aggiunta è disponibile o meno. Può assumere due valori di tipo intero (0 o 1); di default assume valore 0 (disponibile). Stato: indica se l aggiunta è presente o meno nel menù. Può assumere due valori di tipo intero (0 o 1); di default assume valore 0 (presente). N.B. Nessuno di questi attributi può assumere il valore NULL. CAPECE BIAGIO PIETRO & MARINO ALESSANDRO 7

11 Ingrediente Tale entità rappresenta la descrizione di un ingrediente. Figura 8 Descrizione attributi Id_prodotto: chiave primaria dell entità Ingrediente che identifica univocamente un ingrediente. Il valore di tale attributo viene assegnato in fase di inserimento di un nuovo ingrediente (max. 5 caratteri). Prodotto: identifica il nome dell ingrediente (max. 25 caratteri). Prezzo: identifica il prezzo dell ingrediente. Per scelte progettuali e per eventuali implementazioni future si è deciso di inserire tale attributo e assegnargli il valore 0. Disponibilita: indica se l ingrediente è disponibile o meno. Può assumere due valori di tipo intero (0 o 1); di default assume valore 0 (disponibile). Stato: indica se l ingrediente è presente o meno nel menù. Può assumere due valori di tipo intero (0 o 1); di default assume valore 0 (presente). N.B. Nessuno di questi attributi può assumere il valore NULL. Osservazioni sulle entità Pizza, Bibita, Aggiunta e Ingrediente Come si evince dalla descrizione, gli attributi di tali entità sono uguali, perciò si poteva pensare di unificarle in un unica entità, aggiungendo un ulteriore campo per distinguerle. Però, per motivi legati all efficienza e affidabilità del sistema e per la stampa della ricevuta fiscale, è stata fatta la scelta di dividerle in 4 entità differenti. Inoltre è stata fatta la scelta di separare Ingrediente da Aggiunta poiché è possibile che un ingrediente non sia disponibile per farcire una pizza, e quindi è necessario non rendere disponibile tutte le pizze farcite con quell ingrediente, ma può essere utilizzato come aggiunta. Infine il campo Stato è stato aggiunto per consentire una cancellazione logica delle tuple delle tabelle per problemi legati all integrità referenziale; infatti eliminando un prodotto (pizza, bibita, aggiunta o ingrediente) si andrebbe a eliminare tutti gli ordini in cui compare quel prodotto, cosa che non vogliamo che accada in quanto si vuole tenere traccia di uno storico. CAPECE BIAGIO PIETRO & MARINO ALESSANDRO 8

12 Descrizione delle associazioni Una volta definite le entità che costituisco il mini-mondo considerato, passiamo alla definizione dei legami che stabiliscono un interazione tra le entità. Emettere Questa associazione ha cardinalità 1 : N (uno a molti). È la relazione che intercorre fra le entità Utente_pizzeria e Fattura. Un utente (Amministratore/Cassiere) può emettere più fatture ma una fattura può essere emessa da un solo utente; inoltre non possono esserci fatture che non sono state emesse da nessun utente, ciò significa che la partecipazione dell entità Fattura a Emettere è totale. Prendere (Utente_pizzeria - Ordine) Questa associazione ha cardinalità 1 : N (uno a molti). È la relazione che intercorre fra le entità Utente_pizzeria e Ordine. Un utente (cameriere) può prendere più ordini ma un ordine può essere preso da un solo utente; inoltre non possono esserci ordini che non sono state presi da nessun utente, ciò significa che la partecipazione dell entità Ordine a Prendere è totale. Riferito al Questa associazione ha cardinalità 1 : N (uno a molti). È la relazione che intercorre fra le entità Tavolo e Ordine. Su un tavolo possono essere presi più ordini ma un ordine coinvolge un solo tavolo; inoltre non possono esserci ordini che coinvolgono tavoli non presenti nella tabella Tavolo, ciò significa che la partecipazione dell entità Ordine a Riferito al è totale. Coinvolgere Questa associazione ha cardinalità 1 : N (uno a molti). È la relazione che intercorre fra le entità Fattura e Ordine. Un ordine può essere presente in una sola fattura, mentre una fattura può coinvolgere più ordini; inoltre non possono esserci fatture che non coinvolgono ordini, cosi come non ci possono essere ordini senza fattura, ciò significa che le partecipazioni delle entità Fattura e Ordine a Coinvolgere sono totali. Contenere (Ordine - Bibita) Questa associazione ha cardinalità N : M (molti a molti). È la relazione che intercorre fra le entità Ordine e Bibita. In un ordine possono essere prese più bibite e una bibita può essere ordinata in più ordini. Contenere (Ordine - Pizza - Aggiunta) Questa è un associazione ternaria che coinvolge le tre entità Ordine, Pizza e Aggiunta con cardinalità molti a molti. Figura 9 CAPECE BIAGIO PIETRO & MARINO ALESSANDRO 9

13 In questo modo in un ordine possono essere ordinate più pizze e ognuna di queste può contenere più aggiunte; inoltre una pizza/aggiunta può comparire in più ordini. Farcire Questa associazione ha cardinalità N : M (molti a molti). È la relazione che intercorre fra le entità Pizza e Ingrediente. Una pizza può essere farcita con più ingredienti e un ingrediente può essere usato in più pizze; inoltre non possono esserci pizze senza ingredienti, ciò significa che la partecipazione dell entità Pizza a Farcire è totale. CAPECE BIAGIO PIETRO & MARINO ALESSANDRO 10

14 Creazione del modello E-R (Entity-Relationship) Il modello E-R (Entity-Relationship) costituisce uno strumento per analizzare le caratteristiche di una realtà in modo indipendente dagli eventi che in essa accadono, cioè per costruire un modello concettuale dei dati indipendente dalle applicazioni. In base alle considerazioni fatte in precedenza sulle entità e relazioni che descrivono il minimondo, il modello E-R del database che vogliamo realizzare risulta essere il seguente: CAPECE BIAGIO PIETRO & MARINO ALESSANDRO 11

15 Traduzione del modello E-R in modello Relazionale La fase successiva della progettazione di una base di dati consiste nel passare dalla progettazione concettuale alla progettazione logica. Per passare al modello relazionale, quindi, si applica un semplice algoritmo che si basa sui seguenti passi: N.B. 1. Traduzione di tipi di entità; 2. Traduzione di tipi di entità deboli; 3. Traduzione dei tipi di associazioni binarie di tipo 1 : 1; 4. Traduzione dei tipi di associazioni binarie di tipo 1 : N; 5. Traduzione dei tipi di associazioni binarie di tipo N : M; 6. Traduzione di attributi multivalore; 7. Traduzione dei tipi di associazioni N-arie. Nella traduzione, gli attributi chiave primaria verranno evidenziati in grassetto e gli attributi chiave esterna in corsivo. Passo 1: Traduzione di tipi di entità Utente_pizzeria Tavolo Fattura Ordine Username Password Nome Cognome Tipo Stato Id_tavolo Numero_posti_occupati Stato Id_fattura Data Ora Prezzo Id_ordine Data Ora Prezzo Bis Note ServitoP ServitoB Pizza Id_prodotto Prodotto Prezzo Disponibilita Stato Bibita Id_prodotto Prodotto Prezzo Disponibilita Stato Aggiunta Id_prodotto Prodotto Prezzo Disponibilita Stato Ingrediente Id_prodotto Prodotto Prezzo Disponibilita Stato CAPECE BIAGIO PIETRO & MARINO ALESSANDRO 12

16 Passo 2: Traduzione di tipi di entità deboli Le entità deboli sono quelle entità prive di chiave propria; affinché l'entità debole possa essere univocamente identificata e completamente significativa è necessario che essa sia associata ad un altra entità che prende il nome di proprietario. Nel diagramma E-R realizzato non sono presenti entità deboli. Passo 3: Traduzione di tipi di associazioni binarie di tipo 1 : 1 Un associazione si dice di tipo uno a uno (si indica con 1 : 1) quando ogni istanza della prima entità si deve associare ad una sola istanza della seconda entità e viceversa. Nel modello concettuale questo tipo di associazione può essere tradotta in tre modi diversi: a. In un unica relazione che contiene gli attributi della prima e della seconda entità; questo è possibile solo se le relazioni hanno un vincolo di partecipazione totale; b. Inserire la chiave primaria di una delle due entità come attributo chiave esterna nell altra entità. In generale si preferisce collocare la chiave primaria dell entità con partecipazione totale alla relazione; c. In una nuova relazione con lo scopo di definire un riferimento incrociato tra le chiavi primarie delle due entità. Nel caso considerato non sono presenti tipi di associazioni binarie 1 : 1. Passo 4: Traduzione di tipi di associazioni binarie di tipo 1 : N Per tradurre un associazione binaria uno a molti (indicato con 1 : N) si procede individuando la relazione che rappresenta il tipo di entità partecipante lato-n e inserendo la chiave primaria di quest ultima come chiave esterna nella seconda entità. Utente_pizzeria Tavolo Fattura Ordine Username Password Nome Cognome Tipo Stato Id_tavolo Numero_posti_occupati Stato Id_fattura Data Ora Prezzo Username Id_ordine Data Ora Prezzo Bis Note ServitoP ServitoB Username Id_fattura Id_tavolo CAPECE BIAGIO PIETRO & MARINO ALESSANDRO 13

17 Passo 5: Traduzione di tipi di associazioni binarie di tipo N : M Per tradurre un associazione binaria molti a molti (indicato con N : M) è necessario costruire una nuova relazione in cui inserire le chiavi primarie delle due entità come chiavi esterne e gli eventuali attributi appartenenti all associazione. Bibita Id_prodotto Prodotto Prezzo Disponibilita Stato Ordine_bibita Id_ordine_bibita Id_bibita Id_ordine Numero_pezzi Prezzo Ordine Id_ordine Data Ora Prezzo Bis Note ServitoP ServitoB Username Id_fattura Id_tavolo Pizza Id_prodotto Prodotto Prezzo Disponibilita Stato Pizza_ingrediente Id_pizza_ingrediente Id_pizza Id_ingrediente Ingrediente Id_prodotto Prodotto Prezzo Disponibilita Stato Passo 6: Traduzione di attributi multivalore In questa fase si passa alla traduzione degli attributi multivalore di ogni entità. Questo passo comporta la creazione di una nuova relazione per ogni attributo multivalore. Nel diagramma E-R realizzato non sono presenti entità con attributi multivalore. CAPECE BIAGIO PIETRO & MARINO ALESSANDRO 14

18 Passo 7: Traduzione dei tipi di associazioni N-arie L ultimo passo dell algoritmo si occupa dell analisi e conversione dei tipi di associazioni N-arie. In questo caso si costruisce una nuova relazione in cui verranno inserite le chiavi primarie delle entità coinvolte; tali campi verranno considerati come chiavi esterne. Nel caso considerato è presente un associazione ternaria tra Ordine, Pizza e Aggiunta. Ordine Id_ordine Data Ora Prezzo Bis Note ServitoP ServitoB Username Id_fattura Id_tavolo Ordine_pizza Pizza Id_ordine_pizza Id_pizza Id_ordine Numero_pezzi Prezzo Id_prodotto Prodotto Prezzo Disponibilita Stato Pizza_aggiunta Id_pizza_aggiunta Id_ordine_pizza Id_aggiunta Aggiunta Id_prodotto Prodotto Prezzo Disponibilita Stato CAPECE BIAGIO PIETRO & MARINO ALESSANDRO 15

19 Normalizzazione del modello Relazionale Cenni teorici La normalizzazione è un procedimento che ha lo scopo di eliminare la ridondanza ed eventuali incoerenze del database. Il processo di normalizzazione sottopone uno schema di relazione a una serie di test per certificare se soddisfa una data forma normale. Prima forma normale (1NF) Richiede che il dominio di un attributo comprenda valori atomici e che il valore di un qualsiasi attributo in una tupla sia un valore singolo del dominio, ovvero: Tutte le righe della tabella contengono lo stesso numero di colonne; Gli attributi rappresentano informazioni elementari; I valori che compaiono in una colonna sono dello stesso tipo, cioè appartengono allo stesso dominio; Ogni riga è diversa da tutte le altre, cioè non ce ne possono essere due con gli stessi valori nelle colonne; L ordine con il quale le righe compaiono nella tabella è irrilevante. N.B. La prima forma normale (1NF) è già parte integrante della definizione formale di relazione nel modello relazionale. Seconda forma normale (2NF) Uno schema relazionale è in seconda forma normale (2NF) quando è in prima forma normale (1NF) e tutti i suoi attributi non-chiave dipendono dall intera chiave, cioè non possiede attributi che dipendono soltanto da una parte della chiave. La seconda forma normale elimina la dipendenza parziale degli attributi dalla chiave e riguarda il caso di relazioni con chiavi composte, cioè formate da più attributi. Terza forma normale (3NF) Uno schema relazionale è in terza forma normale (3NF) quando è in seconda forma normale (2NF) e tutti i suoi attributi non-chiave dipendono direttamente dalla chiave, cioè non possiede attributi non-chiave che dipendono da altri attributi non-chiave. La terza forma normale elimina la dipendenza transitiva degli attributi dalla chiave. CAPECE BIAGIO PIETRO & MARINO ALESSANDRO 16

20 Processo di normalizzazione Ora si analizzeranno le varie chiavi e le varie dipendenze funzionali per cercare di ridurre lo schema relazionale precedentemente descritto in 2NF o 3NF. Esaminando la relazione Utente_pizzeria si nota che essa risulta essere già in seconda forma normale (2NF); infatti essendoci un solo attributo chiave (Username) tutti gli altri attributi dipendono funzionalmente da quest ultimo. Inoltre non essendovi dipendenze funzionali transitive, tale relazione risulta essere anche in terza forma normale (3NF). Lo stesso ragionamento lo si può applicare alle relazioni: Tavolo; Fattura; Ordine; Bibita; Pizza; Aggiunta; Ingrediente. Le relazioni Pizza_ingrediente e Pizza_aggiunta sono formate entrambe da un attributo chiave e due chiavi esterne, pertanto risultano essere in 3NF. Per quanto riguarda: Ordine_pizza; Ordine_bibita. tali entità presentano due attributi non-primi (ovvero non sono membri di alcuna chiave candidata) che dipendono funzionalmente, direttamente e completamente dalla chiave (rispettivamente da Id_ordine_pizza e Id_ordine_bibita ); quindi ne segue che le relazioni risultano essere in 3NF. CAPECE BIAGIO PIETRO & MARINO ALESSANDRO 17

21 Schema relazionale completo in terza forma normale (3NF) Utente_pizzeria Tavolo Fattura Ordine Username Password Nome Cognome Tipo Stato Id_tavolo Numero_posti_occupati Stato Id_fattura Data Ora Prezzo Username Id_ordine Data Ora Prezzo Bis Note ServitoP ServitoB Username Id_fattura Id_tavolo Ordine_bibita Bibita Pizza Id_ordine_bibita Id_bibita Id_ordine Numero_pezzi Prezzo Id_prodotto Prodotto Prezzo Disponibilita Stato Id_prodotto Prodotto Prezzo Disponibilita Stato Pizza_ingrediente Id_pizza_ingrediente Id_pizza Id_ingrediente Ingrediente Id_prodotto Prodotto Prezzo Disponibilita Stato Ordine_pizza Id_ordine_pizza Id_pizza Id_ordine Numero_pezzi Prezzo Pizza_aggiunta Id_pizza_aggiunta Id_ordine_pizza Id_aggiunta Aggiunta Id_prodotto Prodotto Prezzo Disponibilita Stato CAPECE BIAGIO PIETRO & MARINO ALESSANDRO 18

22 Codice SQL (Structured Query Language) Viene riportato il codice SQL (estrapolato da phpmyadmin) utilizzato per creare le tabelle che costituiscono la base di dati e i vincoli di integrità referenziale. Struttura della tabella `utente_pizzeria` CREATE TABLE IF NOT EXISTS `utente_pizzeria` ( `username` varchar(20) NOT NULL, `password` varchar(50) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL, `nome` varchar(20) NOT NULL, `cognome` varchar(20) NOT NULL, `tipo` varchar(2) NOT NULL DEFAULT 'c', `stato` int(1) NOT NULL DEFAULT '0', PRIMARY KEY (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; Struttura della tabella `tavolo` CREATE TABLE IF NOT EXISTS `tavolo` ( `id_tavolo` int(3) NOT NULL, `numero_posti_occupati` int(3) NOT NULL DEFAULT '0', `stato` int(1) NOT NULL DEFAULT '0', PRIMARY KEY (`id_tavolo`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; Struttura della tabella `ordine` CREATE TABLE IF NOT EXISTS `ordine` ( `id_ordine` varchar(17) NOT NULL, `data` date NOT NULL, `ora` time NOT NULL, `prezzo` double(8,2) NOT NULL, `bis` int(1) NOT NULL DEFAULT '0', `id_fattura` int(5) DEFAULT NULL, `note` longtext, `servitop` int(1) NOT NULL DEFAULT '0', `servitob` int(1) NOT NULL DEFAULT '0', `username` varchar(20) DEFAULT NULL, `id_tavolo` int(3) DEFAULT NULL, PRIMARY KEY (`id_ordine`), KEY `username` (`username`), KEY `id_tavolo` (`id_tavolo`), KEY `id_fattura` (`id_fattura`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; CAPECE BIAGIO PIETRO & MARINO ALESSANDRO 19

23 Struttura della tabella `fattura` CREATE TABLE IF NOT EXISTS `fattura` ( `id_fattura` int(5) NOT NULL AUTO_INCREMENT, `username` varchar(20) DEFAULT NULL, `data` date NOT NULL, `ora` time NOT NULL, `prezzo` double(8,2) NOT NULL, PRIMARY KEY (`id_fattura`), KEY `username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=13 ; Struttura della tabella `pizza` CREATE TABLE IF NOT EXISTS `pizza` ( `id_prodotto` varchar(5) NOT NULL, `prodotto` varchar(11) NOT NULL, `prezzo` double(8,2) NOT NULL, `disponibilita` int(1) NOT NULL DEFAULT '0', `stato` int(1) NOT NULL DEFAULT '0', PRIMARY KEY (`id_prodotto`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; Struttura della tabella `bibita` CREATE TABLE IF NOT EXISTS `bibita` ( `id_prodotto` varchar(5) NOT NULL, `prodotto` varchar(19) NOT NULL, `prezzo` double(8,2) NOT NULL, `disponibilita` int(1) NOT NULL DEFAULT '0', `stato` int(1) NOT NULL DEFAULT '0', PRIMARY KEY (`id_prodotto`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; Struttura della tabella `ingrediente` CREATE TABLE IF NOT EXISTS `ingrediente` ( `id_prodotto` varchar(5) NOT NULL, `prodotto` varchar(25) NOT NULL, `prezzo` double(8,2) NOT NULL DEFAULT '0.00', `disponibilita` int(1) NOT NULL DEFAULT '0', `stato` int(1) NOT NULL DEFAULT '0', PRIMARY KEY (`id_prodotto`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; CAPECE BIAGIO PIETRO & MARINO ALESSANDRO 20

24 Struttura della tabella `aggiunta` CREATE TABLE IF NOT EXISTS `aggiunta` ( `id_prodotto` varchar(5) NOT NULL, `prodotto` varchar(25) NOT NULL, `prezzo` double(8,2) NOT NULL, `disponibilita` int(1) NOT NULL DEFAULT '0', `stato` int(1) NOT NULL DEFAULT '0', PRIMARY KEY (`id_prodotto`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; Struttura della tabella `ordine_pizza` CREATE TABLE IF NOT EXISTS `ordine_pizza` ( `id_ordine_pizza` int(11) NOT NULL AUTO_INCREMENT, `id_pizza` varchar(5) DEFAULT NULL, `id_ordine` varchar(17) DEFAULT NULL, `numero_pezzi` int(3) NOT NULL DEFAULT '0', `prezzo` double(8,2) NOT NULL DEFAULT '0.00', PRIMARY KEY (`id_ordine_pizza`), KEY `id_ordine` (`id_ordine`), KEY `id_pizza` (`id_pizza`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=89 ; Struttura della tabella `pizza_aggiunta` CREATE TABLE IF NOT EXISTS `pizza_aggiunta` ( `id_pizza_aggiunta` int(11) NOT NULL AUTO_INCREMENT, `id_ordine_pizza` int(11) DEFAULT NULL, `id_aggiunta` varchar(5) DEFAULT NULL, PRIMARY KEY (`id_pizza_aggiunta`), KEY `id_aggiunta` (`id_aggiunta`), KEY `id_pizza` (`id_ordine_pizza`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=96 ; Struttura della tabella `pizza_ingrediente` CREATE TABLE IF NOT EXISTS `pizza_ingrediente` ( `id_pizza_ingrediente` int(11) NOT NULL AUTO_INCREMENT, `id_pizza` varchar(5) DEFAULT NULL, `id_ingrediente` varchar(5) DEFAULT NULL, PRIMARY KEY (`id_pizza_ingrediente`), KEY `id_ingrediente` (`id_ingrediente`), KEY `id_pizza` (`id_pizza`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=80 ; CAPECE BIAGIO PIETRO & MARINO ALESSANDRO 21

25 Struttura della tabella `ordine_bibita` CREATE TABLE IF NOT EXISTS `ordine_bibita` ( `id_ordine_bibita` int(11) NOT NULL AUTO_INCREMENT, `id_bibita` varchar(5) DEFAULT NULL, `id_ordine` varchar(17) DEFAULT NULL, `numero_pezzi` int(3) NOT NULL DEFAULT '0', `prezzo` double(8,2) NOT NULL DEFAULT '0.00', PRIMARY KEY (`id_ordine_bibita`), KEY `id_ordine` (`id_ordine`), KEY `id_bibita` (`id_bibita`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=64 ; Interrogazioni SQL Tra le tante interrogazioni utilizzate dall applicazione Android che si basa sul database precedentemente implementato vengono riportate quelle che, a nostro avviso, meritano un commento. 1. Selezionare tutti gli utenti il cui username è uguale al valore della variabile $username e la password è uguale al valore della variabile $password che non sono stati licenziati. SELECT * FROM utente_pizzeria WHERE BINARY username='$username' AND password='$password' AND stato=0 LIMIT 1; N.B. L aggiunta della parola chiave BINARY è dovuta al fatto che per motivi di sicurezza la codifica dei caratteri del campo password è di tipo latin1_bin. 2. Modificare la disponibilità (con il valore della variabile $disponibilita ) delle pizze che sono farcite con l ingrediente contenuto nella variabile $id_prodotto che non sono state cancellate (logicamente). UPDATE pizza AS T1 INNER JOIN pizza_ingrediente AS T2 ON T1.id_prodotto=T2.id_pizza WHERE T2.id_ingrediente='$id_prodotto' AND T1.stato=0 SET T1.disponibilita='$disponibilita'; 3. Selezionare, in maniera crescente, le entrate giornaliere (con il relativo giorno) effettuate nel mese il cui valore è uguale al contenuto della variabile $mese e il cui anno è uguale al contenuto della variabile $anno. SELECT data, SUM(prezzo) as prezzo FROM fattura WHERE MONTH(data)='$mese' AND YEAR(data)='$anno' GROUP BY data ORDER BY data ASC; CAPECE BIAGIO PIETRO & MARINO ALESSANDRO 22

26 4. Selezionare, in maniera decrescente, il nome dei camerieri in servizio (ovvero non licenziati) e il relativo numero di ordini presi nel mese il cui valore è uguale al contenuto della variabile $mese e il cui anno è uguale al contenuto della variabile $anno. SELECT T1.username,count(*) AS count FROM (ordine AS T1 JOIN utente_pizzeria AS T2 ON T1.username=T2.username) WHERE MONTH(T1.data)='$mese' AND YEAR(T1.data)='$anno' AND T2.stato=0 GROUP BY T1.username ORDER BY count DESC; 5. Selezionare tutti gli ingredienti (non cancellati logicamente) della pizza il cui valore è uguale al contenuto della variabile $id_prodotto. SELECT T2.id_prodotto, T2.prodotto FROM pizza_ingrediente AS T1 INNER JOIN ingrediente AS T2 ON T1.id_ingrediente=T2.id_prodotto WHERE T1.id_pizza='$id_prodotto' AND T2.stato=0; 6. Selezionare il prezzo massimo, minimo e medio di tutte le fatture emesse nel mese il cui valore è uguale al contenuto della variabile $mese e il cui anno è uguale al contenuto della variabile $anno. SELECT MIN(totale.prezzo) AS minimo, AVG(totale.prezzo) AS media, MAX(totale.prezzo) AS massimo FROM ( SELECT SUM(prezzo) as prezzo FROM fattura WHERE MONTH(data)='$mese' AND YEAR(data)='$anno' GROUP BY data) AS totale; 7. Selezionare il nome dei prodotti (non cancellati logicamente) con il relativo numero totale di pezzi venduti ordinati in maniera decrescente. SELECT T1.prodotto, SUM(T2.numero_pezzi) AS somma FROM ($tiporeparto AS T1 JOIN ordine_$tiporeparto AS T2 on T1.id_prodotto=T2.id_$tipoReparto) WHERE T1.stato=0 GROUP BY T1.prodotto ORDER BY somma DESC; N.B. la variabile $tiporeparto può assumere solo 2 valori costanti (definiti nel programma), ovvero: pizza o bibita. Questa scelta è stata fatta per evitare di ripetere la query più volte e quindi riutilizzare il codice sfruttando la nomenclatura delle tabelle e degli attributi. CAPECE BIAGIO PIETRO & MARINO ALESSANDRO 23

27 8. Inserire un nuovo ordine. INSERT INTO ordine (id_ordine, data, ora, prezzo, bis, id_fattura, note, servitop, servitob, username, id_tavolo) VALUES ( $id_ordine, $data, $ora, $prezzo, $bis, NULL, $note, 0, 0, $username, $id_tavolo ); N.B. Nell inserimento di un nuovo ordine, al valore dell attributo id_fattura viene assegnato NULL in quanto tale ordine non è stato ancora pagato e quindi non fa riferimento ad alcuna fattura. 9. Insieme di query utilizzate per resettare l intera base di dati (motivo: cambio gestione attività); ovviamente tale operazione è eseguita solamente dall amministratore utilizzando un particolare codice di conferma reso disponibile, su richiesta, dal produttore del software. DELETE FROM pizza_ingrediente; DELETE FROM pizza_aggiunta; DELETE FROM ordine_bibita; DELETE FROM ordine_pizza; DELETE FROM ingrediente; DELETE FROM aggiunta; DELETE FROM pizza; DELETE FROM bibita; DELETE FROM ordine; DELETE FROM fattura; DELETE FROM tavolo; DELETE FROM utente_pizzeria WHERE username!= 'admin'; ALTER TABLE ordine_pizza AUTO_INCREMENT = 1; ALTER TABLE ordine_bibita AUTO_INCREMENT = 1; ALTER TABLE pizza_aggiunta AUTO_INCREMENT = 1; ALTER TABLE pizza_ingrediente AUTO_INCREMENT = 1; ALTER TABLE fattura AUTO_INCREMENT = 1; N.B. È importante notare l ordine con cui vengono eseguite le query di cancellazione (DELETE), questo perché sussistono vincoli di integrità referenziale. Inoltre l unica tupla che non viene eliminata nella tabella utente_pizzeria è quella con username admin, ovvero l amministratore, questo perché dopo il reset completo del DB è necessario che rimanga un utente in grado di popolare la base di dati. Infine dopo la cancellazione si procede al reset dei campi di tipo AUTO_INCREMENT. CAPECE BIAGIO PIETRO & MARINO ALESSANDRO 24

28 Interfaccia grafica L applicazione è stata realizzata in Android e l interfaccia grafica è stata implementata in linguaggio XML. All avvio dell applicazione appare una schermata di login e successivamente, in funzione delle credenziali inserite, si presenta una schermata diversa per ogni tipo di utente. L interfaccia è stata pensata per rendere l applicazione intuitiva ed efficiente e per questo si è deciso di utilizzare una grafica semplice e minimale. Tuttavia, su richiesta, è possibile migliorarla aggiungendo (o modificando) altre funzionalità. Di seguito vengono riportati gli screenshot dell applicazione. Schermata di Login Schermata Amministratore (o Cassiere) Schermata Admin Schermata per la visualizzazione dei tavoli Anteprima scontrino CAPECE BIAGIO PIETRO & MARINO ALESSANDRO 25

29 Schermata per la modifica/aggiunta dei tavoli Schermata per la modifica/aggiunta delle pizza Schermata per la modifica/aggiunta delle aggiunte Schermata per la modifica/aggiunta delle bevande Schermata per la modifica/aggiunta degli ingredienti Schermata per la modifica/aggiunta dei dipendenti CAPECE BIAGIO PIETRO & MARINO ALESSANDRO 26

30 Schermata per la gestione della logistica generale Classifica dei dipendenti in base al numero di ordini presi Classifica delle pizze vendute Classifica delle bibite vendute Schermata per la visualizzazione delle fatture emesse Finestra di dialogo per la visualizzazione dei dettagli relativi ad un ordine completo CAPECE BIAGIO PIETRO & MARINO ALESSANDRO 27

31 Schermata Cameriere Schermata per prendere l ordine relativo alle pizze Schermata per prendere l ordine relativo alle bibite Anteprima dell ordine Schermata per la modifica della password CAPECE BIAGIO PIETRO & MARINO ALESSANDRO 28

32 Schermata Pizzaiolo Schermata Barista Schermata per la visualizzazione e gestione delle pizze ancora da servire Schermata per la visualizzazione e gestione delle bibite ancora da servire CAPECE BIAGIO PIETRO & MARINO ALESSANDRO 29

33 Stampa della fattura finale CAPECE BIAGIO PIETRO & MARINO ALESSANDRO 30