Riprendiamo la progettazione e realizzazione di un applicativo per la gestione di una pizzeria o di un ristorante dopo aver analizzato, nel post precedente, i requisiti richiesti da questo programma.

Un primo schema concettuale semplificato (non ho inserito né attributi né cardinalità) è il seguente:

La denominazione delle relazioni (o per meglio dire associazioni) è stata ottenuto mettendo insieme i nomi delle entità ad esse collegate. Così la relazione “VOCI MENU” associa l’entità “MENU” con l’entità “VOCI”. In genere, per maggiore leggibilità dello schema, si preferisce inserire un verbo; nell’esempio precedente avremmo potuto denominare la relazione “COMPRENDERE” oppure “PREVEDERE”, perché così la relazione si sarebbe potuta leggere più facilmente in un senso o nell’altro: “un menu comprende più voci, una voce può essere compresa in più menu” oppure “un menu prevede più voci, una voce può essere prevista da più menu”. Tuttavia tale soluzione, quando (come in questo caso) si deve poi tradurre la relazione in tabella (si tratta di una relazione molti a molti), rischia di diventare poco “elegante”: che nome daremo alla tabella? “COMPRENSIONI”? “PREVISIONI”?

Restiamo sull’argomento “VOCI” del menu. Perché questo termine così generico? Dobbiamo pensare a come è strutturato un menu. Ci sono varie categorie di portate (antipasti – di carne o di pesce, primi e secondi – di carne o di pesce, dessert, ecc.) che nello schema sono state rappresentate con l’entità “CATEGORIE”. E poi c’è il nome della portata. Ad esempio, nella categoria “Primi” ci può essere la portata “Risotto agli asparagi”, ma in una pizzeria potrebbe comparire “Pizza Capricciosa” oppure “Pizza Margherita”. E quando il cliente ordina da bere? Anche le bevande sono voci che appaiono nel menu e quindi è preferibile utilizzare genericamente il termine “VOCI” per l’entità che dovrà contenere queste informazioni. Naturalmente ogni voce dovrà comprendere anche un attributo per il prezzo indicato nel menu. Non potrà mancare anche la voce “COPERTO” che è sempre prevista quando si va al ristorante o in pizzeria. Inoltre, poiché il prezzo potrebbe subire delle variazioni nel tempo, bisognerà prevedere una soluzione che consenta di attribuire alle voci degli ordini il prezzo di listino praticato in quel momento.

Una precisazione relativa all’entità “MENU”. Spesso i ristoranti mettono a disposizione dei clienti menu diversi. Ad esempio ci può essere un menu fisso oppure dei menu speciali per determinate ricorrenze (festività natalizie, pasquali, matrimoni, ecc.). Naturalmente ognuno di questi menu comprenderà delle portate specifiche e all’atto della comanda sarà possibile scegliere le voci di un particolare menu.

Esiste poi un’altra relazione tra l’entità “VOCI” e l’entità “INGREDIENTI”. Si tratta di una relazione “molti a molti”, in quanto ogni voce può prevedere uno o più ingredienti ed ogni ingrediente può far parte di più voci. Pertanto la relazione “INGREDIENTI VOCI” sarà trasformata in una entità (e quindi in una tabella) che assocerà i vari piatti ai relativi ingredienti.

Passando al personale possiamo notare che vi è una relazione che serve a mettere in collegamento ogni record dello stesso con la mansione ricoperta. Si tratta di una relazione “uno a molti”, poiché ad ogni dipendente che fa parte del personale sarà assegnata una sola mansione. Tuttavia, nella vita reale, ci può essere qualche dipendente che svolge, occasionalmente o in modo permanente, più mansioni. Scegliamo la soluzione che prevede l’assegnazione di un unico ruolo principale, il che non impedisce di compilare ordini anche da parte di personale che non ha la specifica mansione di cameriere.

L’entità “TAVOLI” è messa in relazione con l’entità “SALE”, dato che le specifiche di progetto prevedono che sia data la possibilità di distribuire su più sale i tavoli dell’attività. Si può ipotizzare che la presenza di un’unica sala si traduca nell’inserimento di una sola voce nella tabella “SALE” oppure che si possa suddividere l’unica sala in zone, ad esempio “ZONA PIZZERIA”, “ZONA RISTORANTE”, “ZONA BAR”, ecc.

Dobbiamo anche tener conto e gestire le prenotazioni, che saranno ricevute da qualcuno che fa parte dello staff, se non dallo stesso titolare. Nella prenotazione saranno presenti le informazioni riguardanti il nominativo di chi prenota, il giorno e l’orario indicativo di prenotazione, il numero di persone ed eventuali annotazioni relative a specifiche preferenze di menu, alla presenza di persone con particolari intolleranze, alla richiesta di piatti vegani o vegetariani, ecc.

Arriviamo così all’entità “ORDINI” o comande che dir si voglia: essa viene associata ai dati provenienti da diverse entità. Dall’entità “TAVOLI”, con l’indicazione del tavolo assegnato ai clienti; dall’entità “VOCI”, che grazie alla relazione “VOCI ORDINI” consente di creare l’elenco di piatti e bevande scelte, ognuna delle quali tiene traccia del cameriere (o altro soggetto) che ha inserito la voce stessa, nonche delle eventuali variazioni in aggiunta o sottrazione, apportate alle singole voci; tali modifiche saranno possibili tramite il collegamento con l’entità “INGREDIENTI”. Così, ad esempio, il cameriere “Rossi” nell’ordine con codice “1234” al tavolo “7” potrà inserire una “Pizza Margherita” con aggiunta di “Burrata” e sottrazione di “Pomodoro”. Sarà inoltre possibile indicare nella comanda l’eventuale prenotazione precedentemente effettuata e presente nell’entità “PRENOTAZIONI”.

Con questa breve descrizione dello schema concettuale del nostro database può dirsi conclusa la fase preliminare di progettazione, che naturalmente, in seguito, potrà subire delle variazioni. Dallo schema concettuale (che ribadisco ho semplificato, omettendo l’indicazione degli attributi e delle cardinalità in entità e relazioni) si passa poi alla relativa traduzione in schema logico. Ho scelto di realizzare quest’ultimo direttamente in MS Access e conto di pubblicarlo già con il terzo post. Perciò “rimanete sintonizzati”. Osservazioni e suggerimenti su questo progetto sono sempre graditi!

Diverso tempo fa mi ero riproposto di creare un’applicazione Access che consentisse di gestire una pizzeria o un ristorante, o entrambi ovviamente, e direi che è giunto il momento di dare attuazione a questo progetto.

Vediamo innanzitutto di analizzare il problema ed individuare quali caratteristiche dovrà avere questo programma. Da qui in avanti non parlerò più di pizzeria/ristorante ma mi limiterò ad utilizzare genericamente il termine “attività”. Ebbene, la nostra attività prevede un locale suddiviso in una o più sale (che a volte hanno delle denominazioni particolari), all’interno delle quali si trovano diversi tavoli, numerati progressivamente, ognuno dei quali dispone di uno o più posti a sedere. La configurazione di questi tavoli può variare nel tempo, nel senso che un tavolo può essere allungato o accorciato per far fronte a situazioni particolari quali ad esempio un gruppo numeroso di clienti che vuole festaggiare congiuntamente un evento. Ma potrebbe anche trattarsi di una riorganizzazione generale del locale, che determini una rivalutazione del numero dei tavoli e relativi posti a sedere. Pertanto il nostro programma ne dovrà tener conto.

L’attività impiega diverso personale, suddiviso per mansione: camerieri, cuochi, pizzaioli, personale di segreteria, ecc. Per l’attività in sala si dovrà tener conto di quale cameriere ha preso l’ordine dei clienti di un certo tavolo. Quest’ordine poi povrà essere integrato da eventuali variazioni, dovute a richieste pervenute successivamente nel corso del servizio e tali variazioni potranno essere apportate anche da camerieri diversi rispetto a quello dell’ordine iniziale.

Per quanto riguarda il lato cucina, si potrà prevedere anche l’indicazione del cuoco (o cuochi) e/o pizzaiolo (o pizzaioli) che ha seguito l’ordine. Una soluzione alternativa potrebbe essere quella di tener traccia semplicemente del personale in servizio al momento degli ordini, tenendo conto dell’orario di inizio e fine servizio di ognuno.

L’attività disporrà di un menu suddiviso nelle tipologie carne, pesce, pizze e bar, dove saranno indicati i vari piatti ognuno dei quali avrà un nome ed un elenco di ingredienti principali. Al momento dell’ordine il cliente potrà anche scegliere di fare delle aggiunte o sottrazioni agli ingredienti di un certo piatto o di una certa pizza. Nell’ordine dovrà essere indicato sia il giorno che l’ora di creazione e di trasmissione alle cucine; sarà proprio quest’ultima a determinare l’ordine di esecuzione delle varie portate. Sarà possibile visualizzare per tipologia l’elenco dei piatti da preparare con i relativi ingredienti, per ottimizzare l’organizzazione in cucina del lavoro da svolgere dall’equipe in servizio.

Per completare il programma sarà utile anche poter gestire le prenotazioni, magari con un diagramma di gantt che visualizzi la disponibilità dei tavoli nel tempo.

Mi piacerebbe anche creare un applicazione per smartphone, collegata al database principale, con cui il personale di sala andrebbe a ricevere gli ordini dei clienti.

Bene. Restate collegati perché nel prossimo post pubblicherò lo schema concettuale del database, spiegadone le soluzioni adottate. A presto!