Modello di dati di trasporto integrato

Il trasporto integrato è qualcosa di cui sentiamo spesso parlare su Internet o nei notiziari. Sebbene non sia qualcosa di nuovo, è sicuramente un processo in corso, con continui cambiamenti in corso di attuazione. Oggi daremo un'occhiata a un modello di dati in grado di gestire informazioni su zone, passeggeri e biglietti.

Analizziamo il nostro modello di dati di trasporto integrato, partendo dall'idea alla base di tutto.

Idea

L'integrazione del trasporto è necessaria per massimizzarne l'efficienza e, per i clienti, il suo facile utilizzo. L'integrazione è legata ai costi ma anche al tempo, all'accessibilità, al comfort e alla sicurezza. Questo vale sia per le città più grandi che per quelle più piccole. L'idea è di utilizzare l'infrastruttura di trasporto esistente e ottimizzarla per ottenere risultati migliori; questo potrebbe significare trovare nuovi orari, notifiche, linee o stazioni. Forse basta avere qualche informazione per decidere di aspettare l'autobus, noleggiare una bicicletta o semplicemente camminare fino a destinazione.

Spieghiamolo usando due esempi.

Nel caso di una grande città, di solito ci sono molti diversi mezzi di trasporto disponibili:autobus, taxi, tram, ferrovie, metropolitana, ecc. Ciò può portare a molte diverse società private che forniscono vari servizi di trasporto. La combinazione anche di solo alcuni di questi servizi andrebbe sicuramente a vantaggio dei passeggeri e delle compagnie riducendo i costi, aumentando l'efficienza e fornendo più servizi per biglietto.

Ci sono anche vantaggi simili per una città più piccola. Potrebbero non esserci lo stesso numero di opzioni da combinare, ma potrebbero essere organizzate per ottenere la massima efficienza.

Questo articolo si concentrerà principalmente sui sistemi integrati di biglietteria dei trasporti. Non ci concentreremo su tutti gli aspetti dell'integrazione e sulle varie tipologie di trasporto; sarebbe troppo complesso.

Con questo in mente, passiamo al nostro modello.

Modello di dati

Il modello si compone di due aree tematiche:

• Cities & companies
• Tickets

Li descriveremo nell'ordine in cui sono elencati.

Città e aziende

Nella prima area tematica, memorizzeremo tutte le tabelle necessarie per impostare le zone di trasporto nelle città.

Il country la tabella contiene un elenco di UNIQUE country_name valori. Questa tabella viene utilizzata solo come riferimento nella city tavolo. Sebbene possiamo aspettarci che il nostro modello copra il trasporto in un solo paese, vogliamo avere la possibilità di includere più paesi. Per ogni città, memorizzeremo la combinazione UNICA city_name – country_id .

Le città più piccole avranno probabilmente una sola zona, mentre le città più grandi avranno più zone. Nella zone tavolo. Per ogni zona, memorizzeremo il suo zone_name e un riferimento alla città di riferimento. Questa coppia costituisce la chiave alternativa di questa tabella.

Possiamo aspettarci che il nostro sistema memorizzerà informazioni su più compagnie di trasporto. Le società emetteranno i propri biglietti, ma potranno anche emettere biglietti insieme ad altre società. Per ogni company , memorizzeremo la combinazione UNICA di company_name e il city_id Dove si trova. Qualsiasi informazione aggiuntiva necessaria può essere memorizzata nei details testuali campo.

L'ultima cosa che dobbiamo definire è la forma di trasporto fornita da ciascuna azienda. Alcuni valori previsti sono "autobus", "tram", "metropolitana" e "ferrovia". Per ogni valore nel transport_form tabella, memorizzeremo il form_name UNICO.

• zone_id – Fa riferimento alla zone tabella e indica l'area in cui questa forma di trasporto è fornita da questa società.
• company_id – Fa riferimento all'company fornendo questo servizio in questa zona.
• transport_form_id – Fa riferimento al transport_form tabella e indica il tipo di servizio fornito.
• date_from e date_to – Il periodo durante il quale questo servizio è stato fornito da questa società. Nota che date_to può contenere un valore NULL se questo servizio è ancora disponibile e/o non ha una data di scadenza prevista.
• details – Tutti gli altri dettagli, in un formato testuale non strutturato.
• is_active – Se questo servizio è attivo (in corso) o meno. Questo è un semplice interruttore di accensione/spegnimento che possiamo usare in alcuni casi al posto del date_from – date_to intervallo di attività del servizio. Il miglior utilizzo di questo attributo sarebbe quello di semplificare le query, cioè testando questo valore invece di testare l'intervallo di date e "giocando" con valori NULL.

Biglietti

L'area tematica precedente era solo la preparazione per la cosa principale:i biglietti. Ed è ciò che tratterà questa area tematica.

Abbiamo definito società, zone e moduli di trasporto, ma non abbiamo alcuna disposizione per passeggeri e biglietti, il fulcro di questo modello. Assumiamo che un biglietto possa essere utilizzato per una o più zone coperte da una o più compagnie.

Pertanto, dobbiamo prima definire ogni ticket_type . In questa tabella elencheremo tutti i possibili tipi di biglietti venduti dalle compagnie nel nostro database. Per ogni tipo, memorizzeremo i seguenti valori:

• type_name – Un nome che denota ESCLUSIVAMENTE questo tipo.
• valid_from e valid_to – Il periodo in cui questo tipo di biglietto è (o era) valido. Entrambi i campi sono annullabili; un valore NULL significa che non c'è una data di inizio (o di fine) per quando questo era valido.
• details – Eventuali dettagli necessari, in formato testuale non strutturato.
• recurring – Un flag che indica se questo tipo di biglietto è ricorrente (ad es. annuale, mensile) o meno.
• interval_month – Se il tipo di biglietto è ricorrente, questo attributo conterrà l'intervallo, in mesi, di ricorrenza (es. “1” per un biglietto mensile, “12” per un biglietto annuale).

Ora siamo pronti per definire le zone coperte da ogni tipo di biglietto. Nel service_included tabella, memorizzeremo solo la coppia UNIQUE ticket_type_id – service_available_id . Quest'ultimo indicherà anche la compagnia e la zona in cui è possibile utilizzare questo biglietto. Questa tabella ci permette di definire più zone per biglietto; le zone potrebbero appartenere a società diverse. Poiché si tratta di tipi di biglietto predefiniti, ogni tipo di biglietto avrà le zone qui definite (non per ogni singolo passeggero).

Non memorizzeremo troppi dettagli sui passeggeri in questo modello. Per ogni passenger , memorizzeremo solo il loro first_name , last_name , address , e un riferimento alla città in cui vivono. Tutti questi dati verranno visualizzati sul biglietto.

L'ultima tabella del nostro modello è il ticket tavolo. Non ci concentreremo sui biglietti monouso qui; piuttosto, ci occuperemo noi di abbonamenti e biglietti prepagati. Questi biglietti avranno un saldo, una data di validità o entrambi. Questo potrebbe differire in modo significativo, in base all'azienda e alle sue regole. Se alcune aziende decidono di emettere un biglietto, potremmo supportarlo in questa tabella:conosceremo tutti i dettagli importanti. Per ogni biglietto memorizzeremo:

• serial_number – Una designazione UNICA per ogni biglietto. Potrebbe essere una combinazione di numeri e lettere.
• ticket_type_id – Fa riferimento al tipo di quel biglietto.
• passenger_id – Indica il passeggero, se presente, che possiede quel biglietto. In caso di biglietto prepagato, potrebbe non esserci proprietario.
• valid_from e valid_to – Indica il periodo durante il quale questo biglietto è valido. I valori NULL indicano che non esiste un limite inferiore o superiore.
• credits – I crediti (come valore numerico) attualmente disponibili su quel biglietto. Se si tratta di un biglietto prepagato, possiamo presumere che i passeggeri acquisteranno crediti aggiuntivi sul biglietto. Se il biglietto è valido per tutto il mese (o altro periodo) senza alcun limite di utilizzo, questo valore potrebbe essere NULL.

Miglioramenti al Modello Integrato dei Dati di Trasporto

Puoi notare che questo modello è stato notevolmente semplificato. Questo perché il trasporto integrato è semplicemente troppo grande per essere trattato in un articolo. Ci sono alcune cose che penso potrebbero essere cambiate in questo modello:

• Le zone sono troppo semplificate; dovremmo essere in grado di definirli in modo più dinamico.
• Non copriamo le linee (es. linee di autobus). E se passano da una zona all'altra, ecc.?
• Non memorizziamo la cronologia di utilizzo dei biglietti.
• Non c'è registrazione per compagnie e passeggeri.

Tutto ciò porterebbe al fatto che ci mancherebbero dati importanti e non potremmo effettuare analisi più approfondite. Allora, cosa ne pensate? Di cosa ha bisogno questo modello? Cosa vorresti aggiungere o rimuovere? Condividi le tue idee nei commenti.