Emanuele Slusarz
1 line
14 KiB
HTML
Executable File
1 line
14 KiB
HTML
Executable File
<html><head><title>Specifica</title><style>body{text-align:justify;margin:2rem 5rem;font-family:Calibri,Helvetica,sans-serif;font-size:12pt}h1{text-align:center;color:#fff;background-color:#2e74b5;border-radius:5px;margin:1rem -2rem;padding:5px;font-size:200%;font-weight:700}h2{margin-bottom:1rem;font-size:200%;font-weight:700}h3{border-bottom:1px solid #000;margin-top:2rem;margin-bottom:1rem;font-size:140%;font-weight:400}p,li{margin-top:.5em;position:relative}ul li{padding-left:1em}ul,ol{margin-left:0;padding-left:0}ul{list-style-type:none}ol{margin-left:1em}ul ul{margin-left:.5em}blockquote{margin-top:.5rem;margin-left:0;font-size:110%;font-style:italic;font-weight:400}ul>li:before{content:"—";display:block;position:absolute;top:0;left:0}table{border-spacing:0;border-collapse:collapse;border:2px solid #000;width:100%}td,th{border:1px solid #000}.linetocompile{border-bottom:.5px solid gray;width:100%;line-height:2rem}.break{page-break-before:always}@media print{@page{size:210mm 297mm}body{margin:1cm}}</style><meta charset=UTF-8><body><h1>Corso di Laboratorio di Basi di Dati <br> <em>Progetti A.A. 2025/2026</em> - Specifica 1</h1><section class=specifica><h2>Progetto "Delivery"</h2><blockquote><p>Versione 1.0</blockquote><h3>Premessa</h3><p>I progetti di fine corso si ispirano sempre ad esigenze reali. La specifica informale del problema data nei paragrafi seguenti può essere, come in ogni caso reale, incompleta e, in alcuni punti, ambigua o contraddittoria. Lo studente dovrà quindi raffinare e disambiguare le specifiche mediante l'interazione con il committente. In alcuni casi allo studente sarà richiesto di valutare diverse possibili alternative, per poi sceglierne una in maniera motivata. Le motivazioni di tutte le scelte interpretative, progettuali e implementative andranno sempre chiaramente documentate nel progetto e verranno discusse in sede di esame.<p><em>Nota</em>: alcune delle funzionalità richieste dalla specifica potrebbero non essere realizzabili con singole query, ma richiedere l'uso di strumenti più avanzati messi a disposizione dal DBMS, come le procedure. In ogni caso, tali procedure avrebbero una o più query come parte principale. L'uso di queste caratteristiche avanzate aumenta notevolmente il valore di un progetto. Tuttavia, nel caso si decida di non utilizzarle nell'implementazione, è necessario comunque presentare lo pseudocodice corrispondente, e realizzare <em>completamente</em> le relative query.<h3>Specifiche</h3><section class=descrizione><p>Il database <em>Delivery</em> supporta una generica attività di ristorazione che offre servizio di consegna a domicilio.<p>L'attività disporrà di un <em>menu</em> composto da <em>prodotti</em> ognuno dotato almeno di un nome, una descrizione, un prezzo e, opzionalmente, una (o più) immagini. Internamente (cioè in modo non visibile ai clienti), ogni prodotto avrà anche associati un tempo di preparazione, una lista di ingredienti (con quantità) e opzionalmente la descrizione testuale della procedura di preparazione. Deve essere prevista anche la possibilità di scegliere tra differenti <em>caratteristiche</em> del prodotto, ognuna dotata di nome, descrizione (opzionale) e di differenza prezzo (rispetto al prezzo base del prodotto). Alcune caratteristiche potranno essere di <em>default</em> (quindi pre-selezionate). Infine,si potranno creare <em>gruppi di mutua esclusione</em> tra sottoinsiemi delle caratteristiche (in modo che solo una delle caratteristiche nel gruppo possa essere selezionata). <em>Esempio: il prodotto "caffè" potrebbe costare 1 euro, e avere come caratteristiche "senza zucchero" (-5 centesimi), "zuccherato" (default) e "molto zuccherato", raggruppate in un gruppo di mutua esclusione chiamato "zucchero", oltre a "con panna" (+50 centesimi) e "freddo" (+1 euro), liberamente selezionabili (non raggruppate).</em><p>I <em>clienti</em> potranno registrarsi liberamente nel sistema, ma si noti che i dati di un cliente dovranno necessariamente comprendere contatti telefonici e indirizzo, visto che parliamo di consegna a domicilio.<p>I clienti potranno selezionare uno o più prodotti dal menu, comprensivi di caratteristiche se presenti, creando un <em>ordine</em> a loro nome. L'utente potrà quindi confermare o annullare l'ordine. In caso di conferma, l'utente potrà anche selezionare un orario specifico per la consegna.<p>L'applicazione avrà anche altre due tipologie di utenti: il <em>proprietario</em>, che supponiamo pre-caricato nel sistema all'atto della sua installazione, e il <em>personale</em>. Il primo potrà monitorare gli ordini passati, in preparazione ed evasi, potrà comporre il menu inserendo o modificando tutte le informazioni inerenti i prodotti e potrà infine registrare membri del personale.<p>I membri del personale vedranno la lista degli ordini correnti, che potranno avere cinque stati: <em>inserito</em>, <em>in preparazione</em>, <em>pronto</em>, <em>in consegna</em> e <em>consegnato</em>. Il personale potrà cambiare lo stato dell'ordine in qualsiasi momento, ma solo seguendo l'ordine progressivo (non si potrà riportare un ordine in consegna nello stato di preparazione). Il sistema dovrà tener traccia dell'effettivo membro del personale che effettua ciascun cambio di stato su un ordine.<p><em>Grazie a Simone, Francesco e Stefano per aver ispirato questa specifica. Se è troppo complicata, prendetevela con loro</em> 😀</section><p>Ci sono indubbiamente svariati vincoli che possono essere applicati ai contenuti di questa base di dati. L'individuazione dei vincoli e la loro implementazione (con vincoli sulle tabelle, trigger o quantomeno definendo il codice e le query necessari ad effettuarne il controllo) costituiscono un requisito importante per lo sviluppo di un progetto realistico, e ne verrà tenuto conto durante la valutazione finale.<h3>Operazioni da realizzare</h3><p>Di seguito sono illustrate schematicamente le operazioni previste sulla base di dati, ciascuna da realizzare tramite una query (o, se necessario, tramite più query, <em>opzionalmente</em> racchiuse in una <em>stored procedure</em>). Ovviamente, ogni ulteriore raffinamento o arricchimento di queste specifiche aumenterà il valore del progetto.<section class=operazioni><ol><li>Generazione del menu (<em>lista dei prodotti con tutte le informazioni visibili al cliente, possibilmente anche le relative caratteristiche con la differenza di prezzo</em>).<li>Eliminazione di una caratteristica associata a un prodotto.<li>Inserimento di un prodotto in un ordine, comprensivo delle sue eventuali caratteristiche.<li>Calcolo del tempo stimato di consegna e del prezzo totale di un ordine (<em>suggerimento: potete provare a usare una sotto-query per calcolare la differenza cumulativa di prezzo derivante dalle caratteristiche selezionate e poi sommarla al prezzo base</em>).<li>Lista degli ordini non ancora messi in preparazione dopo più di un'ora dall'inserimento (<em>suggerimento: è quindi necessario prevedere degli opportuni timestamp da affiancare agli stati</em>).<li>Calcolo del tempo medio di consegna, cioè di passaggio tra lo stato <em>in consegna</em> in quello <em>consegnato</em>, per ciascun membro del personale addetto alla consegna (<em>supponiamo che chi consegna sia colui il quale imposta lo stato su consegnato</em>).<li>Classifica di gradimento dei prodotti (<em>quali prodotti compaiono più comunemente negli ordini?</em>).<li>Calcolo dell'incasso giornaliero.<li>Prospetto del consumo di ingredienti in un anno (<em>quantità di ciascun ingrediente consumata in un certo anno</em>).<li>Estrazione dei prodotti preferiti da un cliente (<em>cioè i prodotti più ordinati da quel cliente, magari escludendo a priori quelli ordinati solo un paio di volte...</em>).<li>Conteggio degli ordini attivi (non in stato <em>consegnato</em>) divisi per il loro stato di avanzamento.<li>Conteggio degli ordini smaltiti (consegnati) in uno specifico giorno.<li>Lista dei membri del personale che hanno lavorato a un particolare ordine.<li>Aggiornamento dello stato di un ordine.</ol></section><p>È possibile inserire procedure di gestione addizionali che si ritengano utili.</section><section class="indicazioni break"><h1>Indicazioni per lo Sviluppo del Progetto</h1><h3>Tecnologie da utilizzare</h3><p>Il DBMS da utilizzare per la realizzazione del progetto è MySQL. MariaDB è un'alternativa accettabile.<p><em>Opzionalmente</em>, il database realizzato potrà essere dotato di un'interfaccia scritta con un linguaggio di programmazione a scelta (Java o PHP) tramite la quale invocare le query richieste (fornendone gli eventuali parametri) e visualizzarne i risultati.<h3>Svolgimento e Documentazione del Progetto</h3><p>Le specifiche fornite potrebbero non risultare esaustive o completamente definite. Ogni funzionalità aggiunta o raffinata, anche tramite l'interazione con il committente, sarà adeguatamente valutata. Tutte le scelte progettuali vanno comunque discusse e motivate.<p>Il progetto dovrà essere svolto secondo le seguenti fasi:<ol><li><p>Formalizzazione ed analisi dei requisiti.</p><li><p>Progettazione concettuale tramite il modello Entità-Relazione.</p><li><p>Descrizione di tutti i vincoli non esprimibili nel modello ER.</p><li><p>Ristrutturazione ed ottimizzazione del modello ER.</p><li><p>Traduzione del modello ER nel corrispondente modello relazionale.</p><li><p>Implementazione effettiva del modello relazionale e di tutti i vincoli tramite SQL.</p><li><p>Implementazione delle query, procedure, funzioni, ecc. tramite SQL.</p></ol><p>Tutte le fasi appena descritte dovranno essere corredate da adeguata documentazione <strong>in formato elettronico</strong> che illustri quanto è stato realizzato e le scelte intraprese.<p>In particolare, dovranno essere necessariamente inclusi nella documentazione gli schemi ER risultanti dai passi (2) e (4), debitamente commentati, e il modello relazionale della base di dati ottenuto al passo (5), in cui siano messe in evidenza le chiavi delle varie tabelle e le relazioni tra queste ultime.<p>Il database finale, risultato dei passi (6) e (7), dovrà essere consegnato nella forma di un <em>script SQL</em> contenente la struttura del database (istruzioni CREATE, comprese eventuali procedure, funzioni e viste) e il codice delle query necessarie a realizzare le funzionalità richieste. <strong>Il codice di ciascuna query dovrà essere preceduto del suo numero identificativo e dal testo della sua definizione</strong>, come riportato nella presente specifica. <em>Opzionalmente</em>, lo script potrà comprendere anche dei dati di prova (istruzioni INSERT). <br> <em>Suggerimento</em>: potete usare le funzioni di esportazione presenti in tool come <em>phpMyAdmin</em>, <em>DBeaver</em> o <em>MySQL Workbench</em>, oppure direttamente il comando <em>mysqldump</em>, per esportare un <em>dump</em> del database contenente sia la struttura che i dati. Inoltre, per praticità, nella maggior parte dei casi potrete incorporare anche la definizione delle query nel dump del database, definendole come viste o stored procedures con nomi significativi come "Query_1", ecc.<p>A puro titolo esemplificativo, all'interno del repository dei progetti del corso è presente un documento-base, strutturato seguendo le indicazioni appena esposte, da cui è possibile derivare la propria documentazione.<p>Le parti della specifica marcate come <em>opzionali</em>, se omesse, non renderanno il progetto insufficiente ma non gli permetteranno comunque di raggiungere il massimo dei voti. Nel caso si decida di realizzarle, non sarà necessario che siano perfette o complete, ma che dimostrino chiaramente il vostro impegno nell'affrontare una tematica avanzata.<p>Nel caso di gruppi di lavoro composti da più componenti, <em>il contributo effettivo offerto da ciascun componente</em> alla realizzazione finale <strong>deve</strong> essere descritto nella documentazione (indicando, ad esempio, chi si è dedicato prevalentemente alla modellazione concettuale, chi ha realizzato il database con SQL, chi ha lavorato su ciascuna query, ecc.). In sede di esame, i responsabili potranno essere chiamati a riferire sugli aspetti loro delegati.<h3>Consegna del Progetto</h3><p>La <em>documentazione</em> e il <em>codice</em> del progetto descritti nella sezione precedente andranno consegnati, anche per email, <strong>almeno una settimana prima</strong> della data prevista per l'appello d'esame. <br> <em>Non verranno in alcun caso concesse proroghe a questo termine</em>, perchè concedere anche un giorno in più a uno studente vorrebbe dire svantaggiare tutti gli altri che hanno consegnato per tempo o hanno organizzato i loro impegni per farlo, e che avrebbero anch'essi sicuramente beneficiato di un po' di tempo aggiuntivo, quantomeno per migliorare o rifinire il proprio lavoro. <br> La consegna del progetto deve essere vista come un esame scritto: si svolge in un determinato giorno, poi viene corretto, e infine durante l'orale viene discusso. Il vantaggio del progetto è che può essere essere sviluppato nell'arco di molti mesi, tuttavia il termine della consegna resta perentorio.<p>In sede di esame saranno discussi eventuali problemi riscontrati nel progetto e potrà essere richiesta una dimostrazione del funzionamento di alcune query e/o dell'eventuale interfaccia realizzata (è quindi opportuno portare con sé un portatile con il progetto installato e funzionante).<h3>Valutazione del Progetto</h3><p>Nel valutare il progetto consegnato saranno prese in considerazione le seguenti caratteristiche:<ol><li><p>Rispetto delle specifiche e loro corretto raffinamento, ove necessario.</p><li><p>Correttezza e conformità alle specifiche dei modelli realizzati.</p><li><p>Correttezza tecnica dell'implementazione fisica del database (struttura, vincoli).</p><li><p>Correttezza tecnica delle query realizzate e loro aderenza alle funzionalità richieste.</p><li><p>Adeguatezza della documentazione.</p></ol><p>A questa valutazione si aggiungerà quella generale derivata dalla discussione del progetto in sede d'esame.<h3>Ulteriori Informazioni</h3><p>Questa specifica è disponibile nel repository del corso di Laboratorio di Basi di Dati, all'indirizzo https://github.com/LaboratorioBasiDiDati-Univaq/LBD_Project_Specifications. Ulteriori informazioni e chiarimenti sulle specifiche possono essere richiesti direttamente via email all'indirizzo giuseppe.dellapenna@univaq.it.<p>Si ricorda che i progetti vanno svolti in <em>piccoli</em> gruppi (due/tre persone è il numero consigliato). Eccezioni a questa regola andranno concordate direttamente col docente.</section> |