Norme Generali
Il progetto fa parte della valutazione gobale del corso e come il test finale esso va necessariamente
completato prima della verbalizzazione dell'esame.
I gruppi dovranno essere composti da due/tre studenti e il progetto sarà assegnato in base al seguente
algoritmo:
Algoritmo di autoasseganzione del progetto.
1) Consideriamo l’alfabeto Inglese (26 lettere) con l’associazione dei numeri naturali all’ordine
alfabetico delle lettere.
(A=1,B=2,------ L=12, …….Z=26)
2) Considerare le sole lettere iniziali dei Cognomi degli appartenenti al gruppo.
3) Dividere la somma dei valori del punto 2) per TRE.
4) Il resto della divisione identifica il progetto secondo la seguente corrispondenza:
Resto 0 compito A;
resto 1 compito B;
resto 2 compito C.
Si vuole osservare che ogni progetto, partendo dalle specifiche (parziali) e parzialmente volutamente
ambigue, deve essere sviluppato secondo scelte progettuali diverse a discrezione degli studenti. La
relazione dovra' quindi necessariamente descrivere le assunzioni aggiuntive considerate in ogni
specifico progetto.
Il progetto è finalizzato a verificare la comprensione degli aspetti teorici del corso e la capacità di
reperire le informazioni di base necessarie a mettere in pratica tali aspetti. Non si richiede pertanto che
quanto realizzato abbia caratteristiche di completezza, specialmente per le richieste di natura
procedurale, ma, per lo meno, che si individui un percorso di soluzione per ciascuno dei requisiti
proposti.
Un progetto può essere svolto da un gruppo formato al massimo da tre studenti. Gruppi di più studenti
possono essere ammissibili ma debbono consultare il docente per la specificazione degli obbiettivi.
Ogni gruppo dovrà consegnare una sola relazione.
La data ultima di consegna dei progetti e' quella dell'ultimo esame di dicembre (per chi vuole
verbalizzare nella sessione invernale).
Chi verbalizzerà nella sessione di settembre, può consegnare il progetto nella data che verrà indicata.
Contestualmente alla relazione, dovrà essere consegnato un CD con oltre la relazione, tutti i file
necessari per l’installazione del db e quindi il file del dump del db musql, oppure lo script per la
creazione, lo script per il popolamento e la parte dell’applicazione in php.
Il db non deve avere nessuna password per il collegamento.
Il nome del db ed il nome della cartella lato server con gli script php deve essere lo stesso e sarà il
Cognome di uno studente del gruppo.
Devono essere fornite nel modo più chiaro possibile tutte le informazioni utili per l’utilizzo
dell’applicazione da parte del docente.
La relazione dovrà essere redatta secondo il seguente schema, ampliato secondo le necessità:
1. Le Specifiche
Considerazioni ed assunzioni che integrano il testo del progetto e ne chiariscano le ambiguità
2. Progettazione dello Schema Concettuale
2.1 Schema ER (Entità - Relationship).6
2.2 Elenco dei Vincoli non esprimibili mediante schema ER
2.3 Glossario delle Entità.
2.4 Glossario delle Relazioni
3. Specifica delle Operazioni
4. Progettazione Logica
4.1 Schema ER ristrutturato
4.2 Traduzione nel modello relazionale
4.3 Diagramma dello Schema Logico
4.4 Vincoli sullo Schema Logico
5. Realizzazione dell’Applicazione
5.1 L’implementazione tramite SQL
5.2 Creazione dei Trigger
5.3Creazione delle Stored Procedures
5.4 La realizzazione server side tramite php
6. Note Finali
Come utilizzare l’applicazione
Esempi di funzionalità
COMPITO A
Campionato mondiale di calcio
Per i prossimi campionati di calcio la federazione cinese intende realizzare un prodotto per la
registrazione dei dati tecnici di un incontro di calcio in real-time. I giornalisti sportivi accreditati
inseriscono durante l’incontro, dati su punizioni, passaggi, attacchi e amminizioni/espulsioni ( o di
quanto altro ritenete necessario) di entrambe le squadre. Il parallelismo e la concorrenza dei dati
richiedono l'uso di un modello dei dati relazionali e la progettazione di un database dedicato. Una
componente generale descriverà le squadre ed i giocatori dei diversi team, mentre una seconda
componente sarà utilizzata per uno specifico incontro.
Si tratterà quindi di modellare la nozione di campionato mondiale di calcio (fase finale) e di incontro,
inoltre sarà necessario implementarne i requisiti generali.
In un incontro saranno registrati i goal (e i cannonieri), i dati disciplinari (falli e corner fatti e subiti,
ammoniti ed espulsi, ed altro a scelta) ed alcune notizie tattiche (percentuali di gioco nei quadranti del
campo, tipologie diverse di attacco, etc.). Sarebbe di ausilio per i giornalisti, disporre di una
applicazione (a menu) che permettesse l'inserimento dei dati puntuali (evento e suoi partecipanti, per
es. goal e suo autore)per l'aggiornamento in tempo reale. Se ogni inserimento si basasse su una serie di
scelte dai menu corrispondenti, si minimizzerebbero i tempi d’inserimento e si garantirebbero dati
omogenei. A fine partita sarà possibile derivare l'insieme delle statistiche per le due squadre, per i
singoli giocatori (per es. insieme dei falli fatti o subiti, ecc).
L'applicazione deve:
(1) Garantire la contabilizzazione di ogni evento;
(2) Segnalare al Servizio Dati Generali (SDG) dati utili per le statistiche dell’incontro (risultato,
ammoniti, espulsi, e soprattutto siccome è in palio la coppa fair play se una squadra ha quattro
ammoniti riceverà un punto di penalizzazione, due punti oltre i cinque; + 2 in caso di zero ammoniti, +
1 in caso di un ammonito, 0 punti negli altri casi. );
3) Guidare la creazione del menu finale (o tra primo e secondo tempo) con la rassegna dei dati tecnici
(ad es. falli e ammoniti) e tattici (ad es. numero d’attacchi dal centro dalla destra o dalla sinistra) utili
per il giornalista che deve scrivere l’articolo.
4) Dare la possibilità di accesso al sistema ai soli giornalisti accreditati, i quali non possono accedere
alla componente SDG, ad uso solo dei membri accreditati della Fifa.
2.1 Componente Procedurale
La componente procedurale del progetto dovrà consentire le seguenti operazioni.
a) Gestione a video dell’interazione del giornalista sportivo per l'inserimento in tempo reale dei dati di
gioco;
b) Generazione del menu di sintesi tecnico-tattica al termine della partita;
c) Aggiornamento a fine partita della componente SDG ovvero della componente generale del
campionato con i dati sintetici (ad es. percentuali totali della partita) relativi all'incontro effettuato con
una successivo report (per ogni squadra) delle partite effettuate e dei dati accumulati durante il
campionato.
Ogni altra procedura viene ritenuto utile implementare, anche in base alle proprie assunzioni fatte in
fase di progetto.
Volume dei dati:
----------------
Giornalisti: 200
Squadre: 24
Membri Fifa: 40
Partite: 28
Calciatori per squadra: 21
Altri se necessario secondo considerazioni personali
Scrivere sulla base delle vostre assunzione la Tavola delle operazioni.
COMPITO B
Gestione Trattoria
-------------------Progettare e realizzare un sistema informatico per la gestione di una trattoria.
Il sistema dovrà supportare le attività di gestione del personale, della cucina, del servizio di
ristorazione.
Per la gestione dei dipendenti, si hanno 4 categorie: camerieri, chef, maitre, personale delle pulizie.
Ogni 10 giorni vengono stabiliti i turni lavorativi (divisi in pranzo, e cena). Un dipendente può
effettuare un turno solo al giorno e non può lavorare per più di 7 giorni ogni dieci. Ogni turno è
composto da un maitre, due chef, quattro camerieri ed un addetti alla pulizia. A fine mese viene erogato
la paga ad ognuno in base ai turni, ed alla paga orario relativa.
Per il controllo della cucina, sono necessari dati su: ingredienti, fornitori, piatti preparate nella trattoria,
e sulle bevande. Degli ingredienti interessa la data di acquisto, il costo, ed il fornitore. Ci sono sostanze
di ampio utilizzo (olio, sale, zucchero, etc.) che devono essere sempre presenti in un quantitativo che
superi una determinato minimo. Per gli alimenti più facilmente deperibili è necessario indicare la data
di scadenza. Ogni piatto cucinato fa uso di più componenti, in una quantità fissata, e la ricetta deve
essere memorizzare nella base dati. Le portate sono divise in antipasti, primi, secondi, contorni, dolci,
mentre le bibite sono divise in alcoliche ed analcoliche.
Degli alcolici interessa conoscere anche il fornitore. L’ acquisto di bevande o ingredienti, deve essere
accompagnato dall’ordine spedito al relativo venditore.
Per la gestione della trattoria: dati su: tavoli, ognuno con un proprio numero massimo di posti e dal
nome del cameriere associato. Si vogliono gestire le prenotazioni effettuate. Di una riserva interessa il
cliente, l'ora, la data, il numero di persone. Ad essa viene associato il tavolo (che sia quello “giusto”).
Se la trattoria è piena per quel turno (due turni a sera ed uno a pranzo) si deve gestire una lista di attesa.
Non si possono registrare prenotazioni oltre tre giorni data corrente.
Bisogna memorizzare gli ordini di ciascun tavolo, sulla base del menù, in cui compaiono le portate e le
bevande con il prezzo. Ogni ordinazione si compone di una o più bevande e di una più pietanze. Deve
essere possibile inserire o cancellare nuove voci in ogni ordine. Le ordinazioni possono essere in
preparazione,in attesa, ,oppure evase. Deve essere generato il conto alla richiesta del cliente. Effettuato
il pagamento, i dati relativi (numero ricevuta, forma pagamento, etc.)vengono registrati.
Tavola delle operazioni:
**Si assume che i clienti della trattoria abbiano effettuato una prenotazione (anche contestualmente al
loro ingresso)**
1. Determinazione dei turni di lavoro (una volta ogni dieci gg)
2. stipendi (ogni 10 gg)
3. Inserimento, Modifica, Eliminazione dati di un impiegato (1 volta al mese)
4. Invio di ordini ad un venditore (5 volte al giorno)
5. Inserimento, Modifica, Eliminazione dati dei fornitori (2 volta al mese)
6. Inserimento, Modifica, Eliminazione dati delle sostanze (1 volta al mese)
7. Inserimento, Modifica, Eliminazione dati delle bibite (3 volta al mese)
8. Inserimento, Modifica, Eliminazione dati dei piatti (1 volta al mese)
9. Allerta superamento minimo dispensa cibi di ampio utilizzo
10. Allerta sulla data di scadenza
11. Inserimento, Modifica, Eliminazione dati dei tavoli (2 volta al mese)
12. Verifica disponibilità tavoli (a seguito di desiderio di prenotazione) (100 volte al giorno)
13. Registra prenotazione (50 volte al giorno)
14. Inserisci in lista di attesa (10 volte al giorno)
15. Elimina da lista di attesa (10 volte al giorno)
16. Modifica menù (1 volta ogni 10 gg)
17. Memorizza, modifica ordine (50 volte al giorno)
18. Emetti il conto (50 volte al giorno)
19. Registra il pagamento (50 volte al giorno)
20. Visualizza gli incassi della giornata (1 volta al giorno)
Volume dei dati:
---------------Dipendenti: 20
Ingredienti: 150
Bevande: 20
Voci Menù: 37 (4 antipasti, 8 primi, 7 secondi, 4 contorni, 4 dolci, 10 bevande)
Tavoli: 25
Prenotazioni: 50
Ordinazioni: 50
Conti: 50
Altri se necessario secondo considerazioni personali
COMPITO C
Negozio on-line vendita libri anche digitali
Si deve progettare un negozio on-line di vendita libri di testo ed in formato digitale.
Ci sarà un proprietario del negozio virtuale che gestirà il rapporto con il reparto distribuzioni, con i
clienti, con i fornitori, con le case editrici.
La libreria virtuale consente la vendita di libri (Non esiste un magazzino di libri, a fronte di un ordine
di un utente registrato, i libri vanni ritirati dal fonitore e consegnati all’acquirente) e di un insieme di
libri digitali che non richiedono la consegna, ma possono essere "scaricati" dal negozio stesso (via rete)
(vengono acquistati dal gestore direttamente dalle case editrici).
L'applicazione deve:
Gestire gli utenti (cf, nome, cognome, indirizzo, e-mail, contatti telefonici, altro se ritenuto
necessario)
Gestire le case editrici (nome, città, indirizzo, p.iva, altro se ritenuto necessario)
Gestire i fornitori (campi da definire secondo le proprie assunzioni)
Possono esserci più fornitori per uno stesso libro, con prezzi diversi di consegna…il sistema fornirà
all’utente un unico prezzo di vendita che sarà quello più conveniente per il sito.
Garantire la contabilizzazione di ogni vendita (insieme dei prodotti e prezzi, fornitore, aquirente),
cioe' la produzione di un documento fiscale per ogni vendita avvenuta;
Segnalare al servizio di consegne i dettagli necessari al completamento della consegna (cioe' i
fornitori convolti, gli indirizzi di essi per il ritiro della merce e le quantità delle merci, tutti i dati
necessari per la consegna all’acquirente ),
Rendicontare la pubblicità effettuata per conto delle case editrici in modo automatico in funzione
delle pagine “visitate” dagli utenti.
Il servizio di consegne richiede al termine di una vendita un documento in cui tutta la merce da ritirare
e gli indirizzi dei vari fornitori e degli acquirenti siano specificati.
Il servizio marketing deve notificare mensilmente le pubblicità effettuate. Le pagine pubblicitarie
hanno un costo per l’editore proporzionale ai libri pubblicizzati, anche le pagine disponibili per il
download dei libri digitali contengono pubblicità delle case editrici stesse. Anche il numero di accessi
alle pagine (uno per ogni vendita di prodotti diretti) va registrata, infatti in proporzione al numero di
accessi si puo' ottenere uno sconto per l’editore.
Le informazioni da rappresentare ammettono le seguenti caratteristiche.
Ogni libro ammette un unico prezzo di vendita che dipende dalla casa editrice e dal fornitore che lo ha
disponibile, oltre a caratteristiche quali la descrizione, un codice, l’editore, l’autore, il genere, libri
simili consigliati.
I libri possono avere diverse case editrici, possono avere diversi fornitori ed un costo di spedizione che
dipende dal luogo di abitazione del cliente, e dal fornitore che ha il libro richiesto.
(ovvero lo stesso libro può costare diversamente se comprato a Palermo o a Napoli, oppure lo stesso
libro a Napoli può essere disponibile presso diverso fornitori, ed il sistema deve rendere visibile un
unico prezzo, quello più conveniente per il gestore del sito di vendita on-line).
Ogni vendita puo' contenere prodotti fisici e digitali.
I prodotti digitali vengono gestiti dal sito che utilizza la pagina di accesso (download) per la pubblicità
esclusiva della casa editrice che lo ha pubblicato.
Il sito gestisce la pubblicità dei libri con un prezzo per le case che dipende dallo spazio nella pagina
html dedicato alla stessa.
Ogni prodotto digitale garantisce un certo bonus pubblicitario che il sistema di e-commerce dovrebbe
gestire automaticamente quando si supera un tetto di accessi.
Componente procedurale
La componente procedurale del progetto dovra' consentire le seguenti operazioni.
I fornitore devono inserire i libri disponibili ed il prezzo di vendita, e possono cancellare i libri che
vendono ad altri (rispetto al gestore del sito). Non possono essere cancellati i libri venduti ma non
ancora ritirati dal personale che effettua le consegne per il sito.
Gli utenti devono poter navigare nel sito, selezionando i libri che desiderano acquistare, ed anche i libri
“simili”.
Generazione a video di un report complessivo fiscale di ogni vendita che includa i dati del cliente,
l'importo complessivo, i libri acquistati, la casa editrice, il fornitore.
Generazione del documento di consegne che stampi a video tutti i dettagli richiesti (fornitori, indirizzi,
merci, quantita', prezzi al fornitore) per le consegne di prodotti.
Generazione del report mensile delle pubblicita' effettuate. Tale report corrisponde
Per ogni casa editrice nella pagine pubblicitarie dove essa è presente.
Gestione della vendita dei libri digitali, con report ed alert nel caso di raggiungimento del bonus per la
casa editrice.
Gestione delle procedure che si dedurranno necessarie per l’applicazione.
Volume dei dati:
---------------Libri cartacei in vendita: 4000
Libri on-line: 8000
Case editrici: 20
Fornitori: 70
Altri se necessario secondo considerazioni personali
Tavola delle operazioni:
Visite al sito 2000 al giorno
Acquisti libri cartacei 100 al giorno
Download 200 al giorno
Altre se necessario secondo considerazioni personali
