Modèle de données de transport intégré

Le transport intégré est quelque chose dont nous entendons souvent parler sur Internet ou dans les actualités. Bien que ce ne soit pas quelque chose de nouveau, c'est définitivement un processus continu, avec des changements constants mis en œuvre. Aujourd'hui, nous allons examiner un modèle de données qui pourrait gérer les informations sur les zones, les passagers et les billets.

Examinons directement notre modèle de données de transport intégré, en commençant par l'idée derrière tout cela.

Idée

L'intégration du transport est nécessaire pour maximiser son efficacité et, pour les clients, sa facilité d'utilisation. L'intégration est liée aux coûts mais aussi au temps, à l'accessibilité, au confort et à la sécurité. Cela vaut aussi bien pour les grandes villes que pour les plus petites. L'idée est d'utiliser l'infrastructure de transport existante et de l'optimiser pour de meilleurs résultats; cela peut signifier proposer de nouveaux horaires, notifications, lignes ou stations. Peut-être qu'il suffit d'avoir quelques informations pour décider d'attendre le bus, de louer un vélo ou simplement de marcher jusqu'à votre destination.

Expliquons cela à l'aide de deux exemples.

Dans le cas d'une grande ville, il existe généralement de nombreux moyens de transport différents :bus, taxis, tramways, chemins de fer, métro, etc. Cela peut conduire à de nombreuses entreprises privées différentes fournissant divers services de transport. Combiner ne serait-ce que quelques-uns de ces services profiterait certainement aux passagers et aux entreprises en réduisant les coûts, en augmentant l'efficacité et en offrant plus de service par billet.

Il existe également des avantages similaires pour une petite ville. Il n'y aura peut-être pas le même nombre d'options à combiner, mais elles pourraient être organisées pour atteindre une efficacité maximale.

Cet article se concentrera principalement sur les systèmes intégrés de billettique de transport. Nous n'aborderons pas tous les aspects de l'intégration et les différents types de transport; ce serait trop complexe.

Dans cet esprit, passons à notre modèle.

Modèle de données

Le modèle se compose de deux domaines :

Cities & companies
Tickets

Nous les décrirons dans l'ordre dans lequel ils sont répertoriés.

Villes et entreprises

Dans le premier domaine, nous stockerons toutes les tables nécessaires à la configuration des zones de transport dans les villes.

Le country table contient une liste UNIQUE de country_name valeurs. Ce tableau est utilisé uniquement comme référence dans la city table. Bien que nous puissions nous attendre à ce que notre modèle couvre le transport dans un seul pays, nous souhaitons avoir la possibilité d'inclure plusieurs pays. Pour chaque ville, nous stockerons la combinaison UNIQUE city_name – country_id .

Les petites villes n'auront probablement qu'une seule zone, tandis que les grandes villes auront plusieurs zones. Une liste de toutes les zones possibles est stockée dans la zone table. Pour chaque zone, nous stockerons son zone_name et une référence à la ville concernée. Cette paire forme la clé alternative de cette table.

Nous pouvons nous attendre à ce que notre système stocke des informations sur plusieurs sociétés de transport. Les entreprises émettront leurs propres billets, mais elles pourront également émettre des billets conjointement avec d'autres entreprises. Pour chaque company , nous stockerons la combinaison UNIQUE de company_name et le city_id où il se trouve. Toute information supplémentaire nécessaire peut être stockée dans les details textuels champ.

La dernière chose que nous devons définir est le mode de transport fourni par chaque entreprise. Certaines valeurs attendues sont "bus", "tram", "métro" et "chemin de fer". Pour chaque valeur du transport_form table, nous stockerons le form_name UNIQUE.

zone_id – Fait référence à la zone tableau et indique la zone où ce moyen de transport est fourni par cette entreprise.
company_id – Référence la company fournir ce service dans cette zone.
transport_form_id – Référence le transport_form tableau et indique le type de service fourni.
date_from et date_to – La période pendant laquelle ce service a été fourni par cette société. Notez que date_to peut contenir une valeur NULL si ce service est toujours disponible et/ou n'a pas de date d'expiration prévue.
details – Tous les autres détails, dans un format textuel non structuré.
is_active – Si ce service est actif (en cours) ou non. Il s'agit d'un simple interrupteur marche/arrêt que nous pouvons utiliser dans certains cas à la place de la date_from – date_to intervalle d'activité de service. La meilleure utilisation de cet attribut serait de simplifier les requêtes, c'est-à-dire en testant cette valeur au lieu de tester l'intervalle de dates et de "jouer" avec des valeurs NULL.

Billets

Le sujet précédent n'était que la préparation de l'essentiel :les billets. Et c'est ce que ce domaine couvrira.

Nous avons défini des entreprises, des zones et des formes de transport, mais nous n'avons aucune disposition pour les passagers et les billets - le cœur de ce modèle. Nous supposerons qu'un billet peut être utilisé pour une ou plusieurs zones couvertes par une ou plusieurs entreprises.

Par conséquent, nous devons d'abord définir chaque ticket_type . Dans ce tableau, nous énumérerons tous les types de billets possibles vendus par les entreprises de notre base de données. Pour chaque type, nous stockerons les valeurs suivantes :

type_name – Un nom désignant UNIQUEMENT ce type.
valid_from et valid_to – La période pendant laquelle ce type de billet est (ou était) valide. Les deux champs acceptent la valeur NULL ; une valeur NULL signifie qu'il n'y a pas de date de début (ou de fin) de validité.
details – Tous les détails nécessaires, dans un format textuel non structuré.
recurring – Un indicateur indiquant si ce type de ticket est récurrent (par exemple, annuel, mensuel) ou non.
interval_month – Si le type de ticket est récurrent, cet attribut contiendra l'intervalle, en mois, de sa récurrence (par exemple, "1" pour un ticket mensuel, "12" pour un ticket annuel).

Nous sommes maintenant prêts à définir les zones couvertes par chaque type de ticket. Dans le service_included table, nous ne stockerons que la paire UNIQUE ticket_type_id – service_available_id . Ce dernier indiquera également la société et la zone où ce ticket peut être utilisé. Ce tableau nous permet de définir plusieurs zones par ticket; les zones peuvent appartenir à des sociétés différentes. Comme il s'agit de types de billets prédéfinis, chaque type de billet aura les zones définies ici (pas pour chaque passager individuel).

Nous ne stockerons pas trop de détails sur les passagers dans ce modèle. Pour chaque passenger , nous ne stockerons que leur first_name , last_name , address , et une référence à la ville où ils habitent. Toutes ces données seront affichées sur le ticket.

La dernière table de notre modèle est le ticket table. Nous ne nous concentrerons pas sur les billets à usage unique ici; nous nous occuperons plutôt des abonnements et des billets prépayés. Ces billets auront un solde, une date de validité ou les deux. Cela pourrait différer considérablement, en fonction de l'entreprise et de ses règles. Si quelques entreprises décident d'émettre un ticket, nous pourrions le soutenir dans ce tableau - nous connaîtrons tous les détails importants. Pour chaque billet, nous stockerons :

serial_number – Une désignation UNIQUE pour chaque billet. Il peut s'agir d'une combinaison de chiffres et de lettres.
ticket_type_id – Fait référence au type de ce ticket.
passenger_id – Fait référence au passager, le cas échéant, qui possède ce billet. Dans le cas d'un billet prépayé, il pourrait n'y avoir aucun propriétaire.
valid_from et valid_to – Désigne la période pendant laquelle ce billet est valide. Les valeurs NULL indiquent qu'il n'y a pas de limite inférieure ou supérieure.
credits – Les crédits (en valeur numérique) actuellement disponibles sur ce billet. S'il s'agit d'un billet prépayé, nous pouvons supposer que les passagers achèteront des crédits supplémentaires sur le billet. Si le billet est valable tout le mois (ou une autre période) sans limite d'utilisation, cette valeur peut être NULL.

Améliorations du modèle de données de transport intégré

Vous pouvez remarquer que ce modèle a été grandement simplifié. En effet, le transport intégré est tout simplement trop important pour être couvert dans un seul article. Je pense que certaines choses pourraient être modifiées dans ce modèle :

Les zones sont trop simplifiées ; nous devrions pouvoir les définir de manière plus dynamique.
Nous ne couvrons pas les lignes (par exemple, les lignes de bus). Et s'ils vont d'une zone à une autre, etc. ?
Nous ne stockons pas l'historique d'utilisation des tickets.
Il n'y a pas d'enregistrement pour les entreprises et les passagers.

Tout cela conduirait au fait que nous manquerions de données importantes et que nous ne pourrions pas faire d'analyse plus approfondie. Alors qu'est-ce que tu en penses? De quoi ce modèle a-t-il besoin ? Que voudriez-vous ajouter ou supprimer ? Partagez vos idées dans les commentaires.