Cibora — Progetto Basi di Dati

Corso: Basi di Dati · Autore: Giordano Davide · Tema: Food Delivery

Repository del progetto di basi di dati per il servizio Cibora: gestione ristoranti, utenti, ordini e rider. Include requisiti, modello concettuale/ER, progettazione logica, schema relazionale e script SQL (creazione e popolamento).

---

Indice

• Obiettivi
• Requisiti
  • Frasi di carattere generale
  • Utente
  • Borsellino
  • Ristorante
  • Rider
  • Prodotto
  • Ordine
• Glossario
• Business Rule
• Progettazione logica
  • Tavola dei volumi (estratto)
  • Tavola delle operazioni (estratto)
  • Ristrutturazione ER
• Schema relazionale
• Setup rapido (PostgreSQL)
• Dati di esempio
• Query di verifica
• Struttura del repository (suggerita)
• Note e assunzioni
• Licenza

---

Obiettivi

Progettare e implementare un database per un servizio di Food Delivery che gestisca ristoranti, prodotti, utenti, ordini, rider e interazioni (recensioni, messaggi, reclami).

Requisiti

Frasi di carattere generale

• Il sistema gestisce ristoranti, utenti, ordini e rider.
• All’ordine, viene scelto il rider libero con somma minima distanza(rider→ristorante) + distanza(ristorante→utente).
• Una volta al mese si aggiornano classifiche: rider più veloci, prodotti più popolari, ristoranti più recensiti positivamente, utenti che hanno speso di più.

Utente

• Registrazione con nome, email, password, telefono, indirizzo.
• Borsellino elettronico: ricariche e pagamenti.
• Premium opzionale con priorità sugli ordini.
• Codici sconto collezionabili; uno sconto applicabile per ordine.
• Storico ordini, reclami; messaggi a ristorante/rider post-consegna.
• Recensioni post-consegna (1–5 stelle + commento); possibilità di mancia.

Borsellino

• Mantiene un saldo aggiornato a ogni transazione (ricarica/pagamento).

Ristorante

• Nome, descrizione, indirizzo, costo spedizione, immagini, numero stelle (aggiornato settimanalmente), categorie dei prodotti.
• Alcuni ristoranti sono Top Partner (con data di inizio).
• Pubblicano una lista di prodotti.

Rider

• Identificati da codice, stato, posizione aggiornata.
• Classificati per mezzo di trasporto (bici, bici elettrica, monopattino, …); per monopattini si traccia autonomia km.
• Tracciate consegne, momenti di affidamento/recapito.

Prodotto

• Titolo, immagine, ingredienti, allergeni, prezzo, eventuale sconto.
• Appartengono a una o più liste (es. tematiche).

Ordine

• Annullabile finché non affidato a un rider; annullabile da utente o ristorante.
• Per tragitti ≥ 10 km: assegnazione a rider con bici elettrica.

Glossario

• Utente: cliente dell’app (relazioni con Ordine, Borsellino, Reclamo, Messaggi, Recensioni).
• Rider: fattorino (relazioni con Ordine, Messaggi, Recensioni).
• Ristorante: esercente (relazioni con Categoria, Prodotto, Ordine, Recensioni).
• Prodotto: piatto/portata; ha ingredienti e allergeni.
• Borsellino: portafoglio virtuale dell’utente.
• Menu/Lista: raggruppamenti di prodotti.

Business Rule

• Accesso/ordini: un utente non può ordinare senza prima ricaricare il borsellino; costo ordine ≤ saldo.
• Recensioni: consentite solo dopo la consegna; Stelle ∈ [1..5]; commento facoltativo.
• Premium: priorità sugli ordini; gestione rinnovo automatico/manuale.
• Annullamenti: permessi fino all’affidamento al rider (da utente o ristorante).
• Top Partner: obiettivi minimi (≥20 ordini, rating medio ≥4.5, % annullati ≤1.5%, % reclami ≤2.5%).
• Assegnazione rider: per distanza minima; se distanza totale ≥10 km → solo bici elettrica.
• Allergeni: ogni piatto elenca ingredienti/allergeni; filtro per allergeni lato utente.
• Mance: registrate e visibili nel profilo rider.
• Sicurezza: email di verifica; notifiche per transazioni; password cifrate.

Progettazione logica

Tavola dei volumi (estratto)

• Utenti: ~3M
• Rider: 50k
• Ristoranti: 100k
• Ordini annui: 5M (con picchi giornalieri)

Tavola delle operazioni (estratto)

• Registrazioni utenti: 8k/giorno · Nuovi ordini: 500k/giorno
• Aggiornamento stato ordine: 500k/giorno · Recensioni ristoranti: 500k/giorno

Ristrutturazione ER

• Eliminazione ridondanze (es.: NumeroStelle derivato da recensioni; TempoConsegna calcolabile).
• Accorpamenti/generalizzazioni (es.: Veicolo come super-entità per bici/monopattino).
• Attributi composti/multivalore normalizzati (es.: Indirizzo, Allergeni).

Schema relazionale

Tabelle principali (selezione):

• Utente(Email, Nome, Cognome, …, Saldo, Telefono, RankUtente)
• Rider(Codice, Posizione, Stato, NumConsegne, Mancia, RankRider)
• Ordine(Data, Ora, Utente→Utente.Email, Rider→Rider.Codice, Stato, Prezzo, …)
• Ristorante(Nome, Via, Civico, CAP, Descrizione, CostoSpedizione, NumeroStelle, …)
• Prodotto(Nome, Prezzo, Immagine, Sconto, RankProdotto)
• MetodoPagamento(Iban, Satispay, CC, Paypal), Ricarica(Utente→Email, Iban→MetodoPagamento.Iban)
• Valutazione(Email→Utente.Email, Ristorante→PK(Ristorante), Stelle, Commento)
• Categorie e Categorizzazione, Menu, FotoRistorante
• ListaProdotti, ListaCibora, Allergeni, HaAllergeni
• Messaggio U/Ristorante, Messaggio U/Rider, RecensisceRider
• Veicolo, Guida

Gli script SQL completi (DDL & DML) sono riportati nella sezione Implementazione SQL del documento originale e possono essere portati in sql/schema.sql e sql/seed.sql nel repository.

Setup rapido (PostgreSQL)

Prerequisiti: PostgreSQL 13+ (o compatibile), psql o pgAdmin.

# 1) Creazione database
createdb cibora

# 2) Creazione schema (consigliato: salvare il DDL in sql/schema.sql)
psql -d cibora -f sql/schema.sql

# 3) Dati di esempio (facoltativo)
psql -d cibora -f sql/seed.sql

In pgAdmin4: apri Query Tool → incolla il contenuto di sql/schema.sql → esegui; poi ripeti con sql/seed.sql.

Dati di esempio

Il documento include INSERT per Prodotto, Utente, Rider, Ordine, Ristorante, MetodoPagamento, Ricarica, Menu, Categoria, Categorizzazione, FotoRistorante, Messaggi, Reclami, Valutazioni, Veicolo, Guida, Liste, Allergeni. Copiali in sql/seed.sql e lanciali dopo il DDL.

Query di verifica

-- Top 10 prodotti più venduti
SELECT lc.NomeP AS prodotto, COUNT(*) AS vendite
FROM ListaCibora lc
GROUP BY lc.NomeP
ORDER BY vendite DESC
LIMIT 10;

-- Rider con rating medio >= 4.5 (se tabella valutazioni rider presente)
-- SELECT Rider, AVG(Stelle) AS rating FROM RecensiceRider ...

-- Utenti premium che hanno speso di più
SELECT u.Email, SUM(o.Prezzo) AS spesa
FROM Utente u JOIN Ordine o ON o.Utente = u.Email
WHERE u.isPremium = TRUE
GROUP BY u.Email
ORDER BY spesa DESC
LIMIT 10;

Struttura del repository (suggerita)

.
├── sql/
│   ├── schema.sql     # DDL: tabelle, vincoli, FK
│   └── seed.sql       # DML: inserimenti di esempio
├── docs/
│   └── ProgettoBD.pdf # specifica originale
└── README.md

Note e assunzioni

• Target PostgreSQL (gli script sono stati verificati su pgAdmin4; adattare sintassi se si usa un RDBMS diverso).
• Alcuni estratti nel testo originale presentano incongruenze (es. nomi di colonne in chiavi primarie/esterne o refuso su Veicolo); allineare DDL e DML durante il porting.
• Le distanze e la scelta del rider sono demandate a logica applicativa (o viste/stored procedure dedicate).

Licenza

Scegli una licenza (es. MIT) oppure mantieni il repository privato fino alla valutazione.