Servizio noleggio biciclette città

Crafting a bike-sharing system

I’m tasked with designing a municipal bike-sharing system, which includes outlining the technical infrastructure, table normalization, and ensuring robust security measures.

Formulating the approach

I’m thinking through the technical infrastructure, database design, and security measures for the bike-sharing system, ensuring a structured and detailed solution with comprehensive data security.

Thought about bike rental system design per 5 secondi

Di seguito viene proposto un progetto complessivo (in forma discorsiva, ma strutturato), che affronta le varie richieste. Per maggiore chiarezza, l’elaborato è suddiviso nei punti indicati.

PARTE I

1. Progetto dell’infrastruttura tecnologica e informatica necessaria a gestire il servizio

1.a Infrastruttura di comunicazione

Scenario generale
Abbiamo diverse stazioni di noleggio/riconsegna dislocate sul territorio cittadino, ciascuna dotata di:

• Un lettore contactless (per la smartcard dell’utente).
• Circa 50 slot, ognuno con un lettore RFID integrato per leggere il tag della bicicletta.
• Un piccolo dispositivo “controller locale” (in genere un mini-PC/embedded board) che:
  • Gestisce i dati provenienti dai lettori RFID degli slot.
  • Comunica con il lettore contactless.
  • Invia e riceve dati dal sistema centrale.

Rete di comunicazione

• Collegamento dalla stazione al centro: le stazioni possono connettersi alla rete centrale tramite:
  1. Rete cablata (fibra/ADSL), dove possibile.
  2. Rete cellulare (4G/5G), nel caso in cui la connessione cablata non sia disponibile o economica; in molte città si opta per SIM dati su router industriali.
• Protocolli: a livello applicativo, potrebbe essere usato un protocollo sicuro come HTTPS o MQTT over TLS.
  • HTTPS per invocare API REST del sistema centrale (soluzione semplice e largamente diffusa).
  • MQTT (con TLS) per una comunicazione continua e leggera (utile se si vogliono ricevere notifiche in tempo reale sui cambi di stato).

In ogni stazione, quindi, il controller locale si occupa di:

1. Leggere i dati di noleggio/riconsegna (ID utente, ID bicicletta, timestamp).
2. Gestire i blocchi meccanici (apertura/chiusura).
3. Trasmettere in tempo reale le informazioni al server centrale.

Sicurezza e affidabilità

• Utilizzo di VPN o connessioni cifrate end-to-end (TLS) per garantire integrità e riservatezza dei dati.
• Backup di rete su più canali (ad esempio una doppia SIM su router industriale) per garantire continuità.

1.b Caratteristiche generali dei componenti hardware e software

1. Componenti a livello centrale

   • Server dell’applicazione (o cluster di server) che gestisce:
     • Il database principale (con i dati degli utenti, delle biciclette, degli slot, delle operazioni di noleggio/riconsegna, ecc.).
     • Il motore di tariffazione (calcolo costi, fatturazione).
     • Servizi web (API REST o pagina web + WebApp/portale).
   • Server di monitoraggio (potrebbe essere lo stesso o un modulo distinto) per mostrare in tempo reale:
     • Quante bici sono disponibili in ogni stazione.
     • Quanti slot liberi ci sono.
   • Server di autenticazione (potrebbe essere un modulo integrato o stand-alone) per la gestione delle credenziali degli utenti, l’autenticazione, l’autorizzazione a noleggiare.

2. Componenti a livello delle stazioni

   • Controller locale (hardware tipo mini-PC o embedded con sistema Linux o Windows Embedded).
   • Lettore contactless (supporto smartcard contactless standard, ad es. MIFARE).
   • Lettori RFID (uno per ciascuno slot, integrato nel blocco).
   • Unità di blocco meccanico (lucchetto controllato via segnale digitale).
   • Modulo di comunicazione (router cellulare industriale o gateway ethernet/fibra).

3. Software

   • A livello di stazione: un’applicazione/servizio che:
     1. Gestisce i dispositivi (lettori contactless, RFID, lucchetti).
     2. Comunica in tempo reale con il server centrale (via REST/MQTT).
   • A livello centrale:
     • Applicazione web-based (front-end + back-end).
     • Database relazionale (es. PostgreSQL o MySQL).
     • Modulo tariffazione e reportistica.

1.c Misure e apparati per assicurare la continuità del servizio

• Gruppi di continuità (UPS) presso ogni stazione per evitare interruzioni dell’alimentazione agli slot e al controller.
• Alimentazione ridondata (se possibile) nei data center centrali, con generatori di emergenza.
• Ridondanza dell’infrastruttura server:
  • Virtualizzazione o containerizzazione (es. Docker + Kubernetes) per distribuire i carichi e minimizzare i tempi di down.
  • Replica dei database (master-slave o master-master) per garantire resilienza.
• Piano di Disaster Recovery con backup periodici dei dati su sito remoto.

2. Progetto della base di dati

Si propone un modello concettuale (E/R) e poi il modello logico (relazionale).

2.a Modello concettuale (E/R semplificato)

• ENTITÀ
  1. Utente
     • Attributi: ID_Utente, Nome, Cognome, Indirizzo, Email, NumCartaCredito, ProfiloTariffa, …
  2. Bicicletta
     • Attributi: ID_Bicicletta, Modello, Stato (es. “disponibile”, “in manutenzione”, “noleggiata”), …
  3. Stazione
     • Attributi: ID_Stazione, Nome, Indirizzo, CoordinateGPS, NumSlotTotale, NumSlotLiberi (questo può anche essere ricavato dalle relazioni con gli slot), …
  4. Slot
     • Attributi: ID_Slot, StatoSlot (es. “occupato”, “libero”), …
     • Relazione: ogni Slot appartiene a una Stazione.
  5. Noleggio (o Operazione di Noleggio/Riconsegna)
     • Attributi: ID_Noleggio, DataOraInizio, DataOraFine, Costo, …
     • Relazioni:
       • Noleggio associato a un Utente (chi ha noleggiato).
       • Noleggio associato a una Bicicletta.
       • Noleggio si avvia in una certa Stazione (stazione_prelievo) e termina in un’altra Stazione (stazione_restituzione).

Nota: A volte si può separare “Noleggio” e “Riconsegna” in due tabelle, ma spesso è più comodo un’unica tabella con DataOraInizio e DataOraFine.

2.b Modello logico (relazionale)

Di seguito uno schema possibile (campi semplificati):

TABELLA Utente (
  ID_Utente            INT PRIMARY KEY,
  Nome                 VARCHAR(50) NOT NULL,
  Cognome              VARCHAR(50) NOT NULL,
  Indirizzo            VARCHAR(100),
  Email                VARCHAR(100) UNIQUE,
  NumCartaCredito      VARCHAR(20),
  ProfiloTariffa       VARCHAR(20) -- es. standard, premium, etc.
  -- altri campi a piacere
);

TABELLA Stazione (
  ID_Stazione          INT PRIMARY KEY,
  Nome                 VARCHAR(50),
  Indirizzo            VARCHAR(100),
  Latitudine           DECIMAL(9,6),
  Longitudine          DECIMAL(9,6)
  -- si possono aggiungere altri campi (es: zone, quartiere, etc.)
);

TABELLA Slot (
  ID_Slot              INT PRIMARY KEY,
  ID_Stazione          INT NOT NULL,
  StatoSlot            VARCHAR(20)  -- "libero", "occupato", "guasto", ...
  -- vincolo di FK
  FOREIGN KEY (ID_Stazione) REFERENCES Stazione(ID_Stazione)
);

TABELLA Bicicletta (
  ID_Bicicletta        INT PRIMARY KEY,
  Modello              VARCHAR(50),
  Stato                VARCHAR(20)  -- "disponibile", "noleggiata", "manutenzione", ...
);

TABELLA Noleggio (
  ID_Noleggio          INT PRIMARY KEY,
  ID_Utente            INT NOT NULL,
  ID_Bicicletta        INT NOT NULL,
  StazionePrelievo     INT NOT NULL,
  StazioneRiconsegna   INT,           -- potrebbe essere NULL finché non riconsegnata
  DataOraInizio        DATETIME NOT NULL,
  DataOraFine          DATETIME,      -- potrebbe essere NULL finché non riconsegnata
  Costo                DECIMAL(6,2),
  -- vincoli di FK
  FOREIGN KEY (ID_Utente) REFERENCES Utente(ID_Utente),
  FOREIGN KEY (ID_Bicicletta) REFERENCES Bicicletta(ID_Bicicletta),
  FOREIGN KEY (StazionePrelievo) REFERENCES Stazione(ID_Stazione),
  FOREIGN KEY (StazioneRiconsegna) REFERENCES Stazione(ID_Stazione)
);

Gestione dello stato degli Slot e delle Biciclette:

• Quando la bicicletta è parcheggiata in uno slot, quell’Slot risulta “occupato” e la Bicicletta risulta “disponibile” (ma fisicamente in quell’Slot). Talvolta si crea una tabella di associazione “SlotBiciclettaCorrente” oppure si aggiunge in “Slot” un riferimento alla Bicicletta (ID_Bicicletta) se è occupato.
• In fase di noleggio, la Bicicletta passa a stato “noleggiata”, e lo Slot si libera.

3. Progetto delle pagine web

Per semplicità, supponiamo di avere un portale con diverse sezioni. Le funzionalità richieste sono:

1. Mappa delle stazioni: all’accesso, si visualizza una mappa interattiva (Google Maps o altra libreria).

   • Cliccando su una stazione, appare un pop-up con:
     • Nome stazione
     • Numero di biciclette disponibili
     • Numero di slot liberi
   • Funzionalità: se la stazione ha biciclette disponibili, compare un’indicazione (“Biciclette disponibili: N”).

2. Visualizzare le biciclette attualmente in uso

   • Sezione riservata al gestore del sistema.
   • Una tabella che elenca:
     • ID_Bicicletta
     • ID_Utente attuale (o Nome e Cognome utente)
     • Stazione di prelievo
     • Ora di inizio noleggio

Esempio di codice (HTML + pseudo-PHP/SQL)

(a) Verifica disponibilità bici in una data stazione

<!-- pagina stazioni.html -->
<!DOCTYPE html>
<html>
<head>
  <title>Bike Sharing - Stazioni</title>
  <!-- include librerie JS per la mappa, CSS, etc. -->
</head>
<body>
  <h1>Elenco Stazioni</h1>
  <!-- Mappa interattiva, omessa per brevità -->
  <div id="mappa"></div>

  <!-- Elenco stazioni testuale, da generare dinamicamente -->
  <table>
    <tr>
      <th>Stazione</th>
      <th>Indirizzo</th>
      <th>Biciclette Disponibili</th>
      <th>Slot Liberi</th>
    </tr>
    <!-- Ciclo sulle stazioni -->
    <?php
    // Esempio di query per ottenere la disponibilità
    // SELECT s.ID_Stazione, s.Nome, s.Indirizzo,
    //   (SELECT COUNT(*) FROM Slot sl 
    //       WHERE sl.ID_Stazione = s.ID_Stazione 
    //         AND sl.ID_Bicicletta IS NOT NULL) AS bikeAvailable,
    //   (SELECT COUNT(*) FROM Slot sl 
    //       WHERE sl.ID_Stazione = s.ID_Stazione 
    //         AND sl.ID_Bicicletta IS NULL) AS slotFree
    // FROM Stazione s

    // Esempio di rendering
    while($row = fetch($result)) {
      echo "<tr>";
      echo "<td>{$row['Nome']}</td>";
      echo "<td>{$row['Indirizzo']}</td>";
      echo "<td>{$row['bikeAvailable']}</td>";
      echo "<td>{$row['slotFree']}</td>";
      echo "</tr>";
    }
    ?>
  </table>
</body>
</html>

(b) Biciclette in uso

<!-- pagina gestione.html -->
<!DOCTYPE html>
<html>
<head>
  <title>Gestione - Biciclette in uso</title>
</head>
<body>
  <h1>Biciclette Attualmente Noleggiate</h1>
  <table>
    <tr>
      <th>ID Bicicletta</th>
      <th>Utente</th>
      <th>Stazione Prelievo</th>
      <th>Data/Ora Inizio</th>
    </tr>
    <?php
    // Query esemplificativa:
    // SELECT b.ID_Bicicletta, u.Nome, u.Cognome, st.Nome AS NomeStazione, n.DataOraInizio
    // FROM Noleggio n
    // JOIN Bicicletta b ON n.ID_Bicicletta = b.ID_Bicicletta
    // JOIN Utente u ON n.ID_Utente = u.ID_Utente
    // JOIN Stazione st ON n.StazionePrelievo = st.ID_Stazione
    // WHERE n.DataOraFine IS NULL  (--> significa che il noleggio è in corso)

    while($row = fetch($result)) {
      echo "<tr>";
      echo "<td>{$row['ID_Bicicletta']}</td>";
      echo "<td>{$row['Nome']} {$row['Cognome']}</td>";
      echo "<td>{$row['NomeStazione']}</td>";
      echo "<td>{$row['DataOraInizio']}</td>";
      echo "</tr>";
    }
    ?>
  </table>
</body>
</html>

PARTE II

1. Report contenente le biciclette noleggiate da un utente, stazioni, durata e costi

Specifica: L’utente deve poter richiedere (o ricevere periodicamente) un report con:

• Elenco dei noleggi effettuati (ID bicicletta, stazione di prelievo, stazione di riconsegna).
• Durata di ogni noleggio (differenza DataOraFine - DataOraInizio).
• Costo sostenuto per ogni noleggio.
• Totale.

Struttura del report

Ad esempio, un file PDF/HTML inviato via mail:

Report noleggi - Utente Mario Rossi (ID_Utente=123)
---------------------------------------------------
1) Bicicletta: 25
   Stazione prelievo: StazioneCentro
   Stazione riconsegna: StazioneStadio
   Inizio: 2025-01-10 08:15  Fine: 2025-01-10 09:05
   Durata: 00:50
   Costo: 2,50 €

2) Bicicletta: 14
   ...
   Costo: ...
---------------------------------------------------
TOTALE speso: ...

Invio periodico automatico

• L’utente nel proprio profilo può impostare una frequenza di invio (es. settimanale, mensile).
• Soluzione: configurare un job/scheduler sul server (es. cron job) che:
  • Ogni X giorni/settimane esegue uno script.
  • Lo script legge gli utenti che hanno la periodicità impostata in quella data (es. “ogni lunedì”).
  • Genera il report (query e formattazione).
  • Invia una mail con il PDF allegato o un link per scaricarlo.

Motivazione: è una soluzione standard e robusta, perché:

• Centralizziamo la logica di invio su un server affidabile.
• Possiamo gestire facilmente il carico (gli invii avvengono in batch).
• L’utente non deve ricordarsi di richiedere manualmente il report.

2. Sviluppo in linguaggio SQL delle query

Sono richieste due query:

(a) Dato il codice di una bicicletta, elencare gli utenti che l’hanno utilizzata nel mese corrente

Supponiamo di voler estrarre: ID_Utente, Nome, Cognome. Usando la convenzione che MONTH(DataOraInizio) = MONTH(CURDATE()) indica il mese corrente e YEAR(DataOraInizio) = YEAR(CURDATE()) indica l’anno corrente.

SELECT DISTINCT u.ID_Utente, u.Nome, u.Cognome
FROM Noleggio n
JOIN Utente u ON n.ID_Utente = u.ID_Utente
WHERE n.ID_Bicicletta = :idBici
  AND MONTH(n.DataOraInizio) = MONTH(CURDATE())
  AND YEAR(n.DataOraInizio) = YEAR(CURDATE());

(Al posto di :idBici mettiamo il codice della bicicletta.)

(b) Mostrare la stazione presso la quale è stato effettuato il maggior numero di noleggi in un dato periodo

Definiamo il periodo con due parametri: :dataInizio, :dataFine. Vogliamo ID_Stazione o Nome, e il conteggio.

SELECT s.ID_Stazione, s.Nome, COUNT(*) as numeroNoleggi
FROM Noleggio n
JOIN Stazione s ON n.StazionePrelievo = s.ID_Stazione
WHERE n.DataOraInizio BETWEEN :dataInizio AND :dataFine
GROUP BY s.ID_Stazione, s.Nome
ORDER BY numeroNoleggi DESC
LIMIT 1;

In questo modo otteniamo la stazione con più noleggi nel periodo desiderato (tramite LIMIT 1).

PARTE III

Normalizzazione della tabella QUADRO

Abbiamo la relazione:

QUADRO(
  Cod_Quadro,
  Cod_Museo,
  Titolo_Quadro,
  Nome_Museo,
  Citta_Museo,
  Prezzo,
  DataInizioEsposizione,
  DataFineEsposizione
)

Verifica delle forme normali

1. 1FN (Prima forma normale)

   • Presumibilmente tutti i campi sono atomici (Cod_Quadro, Cod_Museo, Titolo_Quadro, …) → OK.

2. 2FN (Seconda forma normale)

   • Serve una PK. Si suppone che la PK sia (Cod_Quadro). A meno che si consideri la coppia (Cod_Quadro, Cod_Museo) come chiave, ma di solito il codice del quadro (univoco) basta.
   • Se la PK è “Cod_Quadro” da solo, non abbiamo dipendenze parziali (gli altri attributi dipendono tutti dal quadro). Quindi sembra a posto per la 2FN.

3. 3FN (Terza forma normale)

   • Verificare se ci sono dipendenze transitive. Per esempio, Nome_Museo e Citta_Museo dipendono da Cod_Museo, non da Cod_Quadro.
   • Quindi abbiamo una dipendenza: Cod_Museo → Nome_Museo, Citta_Museo.
   • Inoltre, Cod_Quadro → Prezzo, DataInizioEsposizione, DataFineEsposizione, (Cod_Museo?).
   • Questo vuol dire che “Nome_Museo, Citta_Museo” non dovrebbero stare nella tabella QUADRO, bensì in una tabella MUSEO.

Schema normalizzato

• Tabella QUADRO:

  QUADRO (
    Cod_Quadro PK,
    Cod_Museo FK,
    Titolo_Quadro,
    Prezzo,
    DataInizioEsposizione,
    DataFineEsposizione
  )
  

• Tabella MUSEO:

  MUSEO (
    Cod_Museo PK,
    Nome_Museo,
    Citta_Museo
  )
  

Motivazione

• Si evita la ridondanza di Nome_Museo e Citta_Museo in QUADRO.
• Se uno stesso museo ospita più quadri, Nome_Museo e Citta_Museo non vengono duplicati.
• Con questa divisione, siamo in 3FN: ogni attributo non chiave (Nome_Museo, Citta_Museo) dipende solo dalla chiave della rispettiva entità (Cod_Museo).

PARTE IV

Sicurezza, integrità e riservatezza dei sistemi informatici di rete

Nella gestione di un sistema informatico di rete, è fondamentale autenticare gli utenti in modo sicuro. Principali tecniche/protocolli:

1. Autenticazione basata su password

   • Vantaggi: semplice da implementare, ampiamente supportata.
   • Svantaggi: se le password sono deboli o non protette (in chiaro o con hashing debole), c’è rischio di compromissione.
   • Miglioramenti: salvataggio con hashing robusto (es. bcrypt, Argon2), password policy, ecc.

2. Autenticazione a due fattori (2FA)

   • Vantaggi: aggiunge un livello di sicurezza (token monouso, app OTP, SMS, ecc.).
   • Svantaggi: maggiore complessità per l’utente, necessità di un servizio per generare/verificare i token.

3. Certificati digitali (autenticazione basata su certificato)

   • Vantaggi: molto sicura (chiave privata localmente e certificato firmato da una CA).
   • Svantaggi: più complessa da distribuire/gestire per l’utente (smartcard, software di gestione certificati).

4. Single Sign-On (SSO) con protocolli quali OAuth2 / OpenID Connect / SAML

   • Vantaggi: l’utente si autentica una volta presso un Identity Provider e poi può accedere a più servizi. Migliore user experience.
   • Svantaggi: maggiore complessità architetturale, dipendenza dall’Identity Provider.

5. Sicurezza di trasporto (TLS/SSL)

   • Indispensabile per garantire la riservatezza dei dati scambiati (come credenziali, dati sensibili).

Considerazioni finali

• In un sistema di bike sharing con dati sensibili (numero di carta di credito, dati anagrafici), è auspicabile utilizzare almeno password sicure + TLS.
• Eventualmente, per gli operatori amministrativi, si può imporre 2FA.
• Per la parte di contatto con i device fisici (lettori contactless, RFID), è bene prevedere protocolli di crittografia e sistemi di sicurezza fisica (ad es. protezioni anti-manomissione dei lettori).

CONCLUSIONE

La soluzione proposta:

1. Descrive un’architettura distribuita con stazioni intelligenti e un server centrale.
2. Definisce un database relazionale che traccia utenti, biciclette, slot e noleggi.
3. Prevede pagine web (o app) per monitorare in tempo reale la disponibilità di biciclette e slot, e per la gestione del servizio da parte degli operatori.
4. Include meccanismi di reportistica automatica per gli utenti.
5. Garantisce sicurezza e continuità grazie a tecnologie standard di rete, protocolli sicuri e metodologie di backup e ridondanza.

È un progetto che può essere facilmente implementato con tecnologie moderne (REST API, database SQL, front-end JavaScript/HTML5, app mobile). L’importante è assicurare la scalabilità (in caso la città cresca e si aggiungano più stazioni) e la manutenibilità del sistema (aggiornamenti, nuove funzionalità, gestione guasti).