Sagra di Cimpello
Pro Loco Cimpello 1998


Ristrutturazione dello schema concettuale

Lo schema logico é stato ristrutturato compiendo le seguenti operazioni:
  1. sono stati rivisti i nomi degli attributi, rinominandone qualcuno per evitare accenti nei nomi degli stessi
  2. sono state accorpate le entitį ``Cassiere'', ``Cameriere'' e ``Vassoista'' in una sola entitį piś generale chiamata ``Volontario''
  3. l'attributo ``Asporto'', che avrebbe generato una selva di valori NULL nella entitį ``Ordine'', é stato rimosso da questa ed sono state create una nuova relazione e una nuova entitį, rispettivamente ``Asporto'' e ``Cliente''
  4. per questioni di efficienza sono stati aggiunti degli attributi entitį ``Piatto'' e ``Volontario'' che permettono di identificare univocamente gli oggetti di queste entitį senza utilizzare delle stringhe a lunghezza variabile come gli attributi ``Nome''
  5. all'entitą ``Piatto'' sono stati aggiunti due ulteriori attributi, ``Tipo'' e ``Ord'', per permettere una classificazione delle portate e, all'interno di questa classificazione, un ordinamento indispensabile per stampare corretamente su moduli prestampati
  6. l'attributo ``Ora'' é stato sostituito dall'attributo ``Tstamp'', ovvero TimeStamp, che permette una pił efficiente gestione del tempo che passa tra le operazioni svolte su un ordine.
Seguendo queste linee, č stata computa la ristrutturazione che ha portato allo schema qui sotto: uno schema concettuale č un formalismo grafico, mi dispiace
Se non fosse ben visibile, ecco la versione EPS e il sorgente xfig

Relazioni (nel senso del modello relazionale)

Visto che HTML ha delle ottime tabelle, ho preferito usare queste e ``rendere'' le chiavi esterne con dei link (veri e propri).
Sembra funzionare, nel senso che e` comprensibile...

Relazioni ``statiche''

...ovvero quelle relazioni che cambiano poco durante la vita della BD, tipicamente vengono aggiornate prima dell'uso effettivo della BD e non pił toccate in seguito.

Volontario
IDVolontario
CHAR(2)
Nome
VARCHAR(20)
Cognome
VARCHAR(20)
Servizio
CHAR(1)
DataDiNascita
DATA
Indirizzo
VARCHAR(30)

L'attributo IDVolontario č rappresentato da due caratteri (a scelta, ovvia proposta sono le iniziali di nome e cognome, con varianti in caso di duplicati).

L'attributo Servizio sarį codificato nel seguente modo:
Valore Significato
C Cassiere
A Cameriere
V Vassoista

Piatto
IDPiatto
CHAR(2)
NomePiatto
VARCHAR(12)
Descrizione
VARCHAR(30)
Tipo
CHAR(1)
Ord
INTEGER(3)
Prezzo
INTEGER(5)

Anche qui IDPiatto č a scelta, plausibilmente costituito dai primi due caratteri del nome del piatto con variazioni in presenza di duplicazioni.

L'attributo Tipo sarį codificato nel seguente modo:
Valore Significato
C Ordine da Cucina
B Ordine da BAR

A questa tabella puņ essere inoltre aggiunto tutta una serie di informazioni di ``abbellimento'' e cose varie (mi viene in mente un BLOB con l'immagine del piatto, il prezzo in Euro e cose simili...).

Relazioni ``dinamiche''

Sono gli ordini o le relazioni collegate agli ordini, relazioni che vengono costantemente aggiornate dal sistema e che sono in quantitą estremamente superiore alle precedenti.

Ordine
Nordine
INTEGER(5)
Data
DATA
Stato
CHAR(1)

L'attributo Nordine č da considerarsi un contatore in stile ``fattura'' degli ordini. É da notare che l'attributo Stato é stato aggiunto, non é presente nello schema concettuale ne in quello logico; l'attributo Stato é stato aggiunto per questioni di efficienza (evita di fare query multiple per conoscere lo stato in cui si trova un ordine) ed é stato codificato nella seguente maniera:
Valore Significato
I Inserito
ogni ordine inizialmente si trova in questo stato o in quello successivo
X Asporto
A Abilitato
E Evaso
D Cancellato
per eventuali cancellazioni offline in batch

É da notare, inoltre, che pur potendo le tre operazioni (inserimento, abilitazione, evasione) in teoria essere condotte indipendentemente, contemporaneamente e condurre quindi a uno stato non noto, le modifiche dello stato di un ordine vengono fatte sempre e solo con il ``pezzo di carta'' in mano (che é unico a meno di falsari... ;), quindi naturalmente in maniera mutuamente esclusiva.

Asporto
Nordine
INTEGER(5)
Data
DATA
Nome
VARCHAR(12)

É da notare che l'informazione sul nome (anche se di solito si scrive il cognome, o il soprannome ;) del cliente che richiede l'asporto é piś che sufficiente.

Tavolo
Nordine
INTEGER(5)
Data
DATA
Ntavolo
INTEGER(3)

É da notare come queste due ultime relazioni siano mutuamente esclusive (se un ordine é da asporto non ha un tavolo assegnato e viceversa).

Storia
Nordine
INTEGER(5)
Data
DATA
IDVolontario
CHAR(2)
Tstamp
TIMESTAMP

In questa relazione si tiene traccia dei tempi di ogni operazione (inizio di, veramente) compiuta sull'ordine e di chi l'ha compiuta.
Composizione
Nordine
INTEGER(5)
Data
DATA
IDPiatto
CHAR(6)
Qta
INTEGER(3)

Tavola dei volumi

In questa tabella vengono riassunte brevemente le relazioni, con delle informazioni aggiuntive sulla quantitą dei dati coinvolti.

Concetto Costrutto Volume
Volontario E 10-20
Piatto E 10-20
Ordine E 200-400 a serata
Asporto R 10-20 a serata
Tavolo R circa tanti quanto Ordine
Storia R circa il triplo di Ordine
Composizione R tante volte Ordine quanti sono i piatti come WC, a occhio circa la metį

Operazioni

Convenzioni

All'interno di questa sezione sono definite le seguenti convenzioni:

Simbolo Significato
E Entitį
R Relazione
I Operazione interattiva
B Operazione batch
L Operazione di lettura
G Operazione di controllo integritį referenziale
M Operazione di modifica
D Operazione di cancellazione
A Operazione di aggiunta
X Numero di tipologie di piatto (numero di portate differenti)

Ci sono ulteriori note da fare:

  1. visto che il web é stateless, molto probabilmente le operazioni dovranno essere eseguite piś volte per ottenere il risultato sperato.
  2. ho aggiunto il tipo di operazione ``G'' perchč MuSQL é un sistema SQL entry, quindi non contiene la gestione dell'integritį referenziale che deve essere aggiunta a livello di programma applicativo;
    quella ``G'' va quindi letta nel senso di operazione implicita in caso di DBMS con integritį referenziale, esplicita altrimenti;
    inoltre in caso di operazioni che prevedano G assieme ad altre operazioni, G stessa non verrį riportata;
  3. ho inserito solo le operazioni di inserimento, evitando di riportare quelle di modifica/cancellazione per la manipolazione di Ordine, Volontario e Piatto; la modifica é banale, basta sostituire all'operazione A rispettivamente le operazioni M e D;
    l'unica nota é che una cancellazione su Volontario e Piatto potrebbe lasciare la BD in uno stato inconsistente, ma questo ipotizzerebbe una volontį dolosa da parte di chi mantiene la BD e non puó accadere per normale uso da parte degli utenti.

Tavola delle Operazioni

Concetto Tipo Frequenza
Inserimento Ordine
(prevede anche la stampa)
I per ogni Ordine
Cancellazione Ordine I rara
Modifica Ordine I rara
Abilitazione Ordine I per quasi ogni Ordine
Evasione Ordine
(prevede la stampa dell'ordine con i tempi)
I per ogni Ordine
Inserimento Volontari I per ogni Volontario
(e solo ad inizio manifestazione)
Modifica Volontari I rarissima
Cancellazione Volontari I rarissima
(e comunque da effettuare a DB ``scarico'' per evitare incongruenze)
Inserimento Piatto
(e solo ad inizio manifestazione)
I per ogni Piatto
Modifica Piatto I rarissima
Cancellazione Piatto I rarissima
(e comunque da effettuare a DB `scarico'' per evitare incongruenze)
Calcolo totali serata I una volta a serata
Calcolo tempi medi e massimi B ogni 5/10 minuti

Inserimento di un Ordine

l'inserimento di un ordine prevede anche la possibilitį che sia un ordine da asporto (con inserimento nella omonima relazione) ed inoltre aggiunge alla relazione Storia una tupla con le informazioni di inserimento.

Concetto Costrutto Tipo Accessi
Volontario E G 1
Piatto E L <=X
Ordine E A 1
Asporto R A 1 (se asporto)
Storia R A 1
Composizione R A <=X

Abilitazione di un Ordine

L'abilitazione di un ordine prevede il suo accesso e l'inserimento di informazioni nelle relazioni Tavolo e Storia.

Concetto Costrutto Tipo Accessi
Ordine E M
(modifico Stato)
1
Volontario E L 1
Storia R A 1
Tavolo R A 1

Evasione di un Ordine

L'evasione di un ordine prevede oltre ad un accesso alle informazioni dell'ordine anche la stampa completa di tutte le informazioni e l'inserimento di alcune di esse.

Concetto Costrutto Tipo Accessi
Ordine E M
(modifico Stato)
1
Volontario E G 1
Piatto E L <=X
Asporto R L 1 (se asporto)
Storia R A/L 1 append,
2 o 3 letture a seconda che sia asporto o meno
Composizione R L <=X
Tavolo R L 1

Inserimento Volontari

Concetto Costrutto Tipo Accessi
Volontario E A 1

Inserimento Piatto

Concetto Costrutto Tipo Accessi
Piatto E A 1

Calcolo totali serata

Concetto Costrutto Tipo Accessi
Ordine E L tutte le tuple
Composizione R L tutte le tuple

Calcolo tempi medi e massimi

Concetto Costrutto Tipo Accessi
Ordine E L tutte le tuple
Storia R L tutte le tuple

PF Prosegui ai cenni di progettazione fisica


2 3 5
LinuxSagra v1.0.0 (C) Marco Gaiarin 12:00:00 Ritorna al Menu