Modelo de dados de transporte integrado

Transporte integrado é algo que ouvimos com frequência na internet ou nos noticiários. Embora não seja algo novo, é definitivamente um processo contínuo, com mudanças constantes sendo implementadas. Hoje, vamos dar uma olhada em um modelo de dados que pode lidar com informações de zona, passageiro e bilhete.

Vamos nos aprofundar em nosso modelo de dados de transporte integrado, começando com a ideia por trás de tudo.

Ideia

A integração do transporte é necessária para maximizar sua eficiência e, para os clientes, sua facilidade de uso. A integração está relacionada a custos, mas também a tempo, acessibilidade, conforto e segurança. Isso vale tanto para cidades maiores quanto para cidades menores. A ideia é aproveitar a infraestrutura de transporte existente e otimizá-la para obter melhores resultados; isso pode significar criar novos horários, notificações, linhas ou estações. Talvez apenas ter algumas informações seja suficiente para você decidir esperar o ônibus, alugar uma bicicleta ou simplesmente caminhar até o seu destino.

Vamos explicar isso usando dois exemplos.

No caso de uma grande cidade, geralmente há muitos meios de transporte disponíveis:ônibus, táxis, bondes, ferrovias, metrô, etc. Isso pode levar a que muitas empresas privadas forneçam vários serviços de transporte. A combinação de alguns desses serviços definitivamente beneficiaria passageiros e empresas ao reduzir custos, aumentar a eficiência e oferecer mais serviço por passagem.

Há também benefícios semelhantes para uma cidade menor. Pode não haver o mesmo número de opções para combinar, mas elas podem ser organizadas para alcançar a máxima eficiência.

Este artigo se concentrará principalmente em sistemas integrados de bilhética de transporte. Não nos concentraremos em todos os aspectos da integração e nos vários tipos de transporte; isso seria muito complexo.

Com isso em mente, vamos para o nosso modelo.

Modelo de dados

O modelo consiste em duas áreas temáticas:

Cities & companies
Tickets

Vamos descrevê-los na ordem em que estão listados.

Cidades e Empresas

Na primeira área de assunto, armazenaremos todas as tabelas necessárias para configurar as zonas de transporte nas cidades.

O country A tabela contém uma lista de country_name ÚNICO valores. Esta tabela é usada apenas como referência na city tabela. Embora possamos esperar que nosso modelo cubra o transporte em apenas um país, queremos ter a opção de incluir vários países. Para cada cidade, armazenaremos a combinação ÚNICA city_name – country_id .

Cidades menores provavelmente terão apenas uma zona, enquanto cidades maiores terão várias zonas. Uma lista de todas as zonas possíveis é armazenada na zone tabela. Para cada zona, armazenaremos seu zone_name e uma referência à cidade relevante. Este par forma a chave alternativa desta tabela.

Podemos esperar que nosso sistema armazene informações sobre várias empresas de transporte. As empresas emitirão seus próprios bilhetes, mas também poderão emitir bilhetes em conjunto com outras empresas. Para cada company , armazenaremos a combinação ÚNICA de company_name e o city_id Onde ele é localizado. Qualquer informação adicional necessária pode ser armazenada nos details textuais campo.

A última coisa que precisamos definir é a forma de transporte que cada empresa oferece. Alguns valores esperados são “ônibus”, “tram”, “underground” e “railway”. Para cada valor no transport_form table, armazenaremos o UNIQUE form_name.

zone_id – Referencia a zone tabela e indica a área onde este meio de transporte é fornecido por esta empresa.
company_id – Refere-se à company fornecendo este serviço nesta zona.
transport_form_id – Referencia o transport_form tabela e indica o tipo de serviço prestado.
date_from e date_to – O período durante o qual este serviço foi prestado por esta empresa. Observe que date_to pode conter um valor NULL se este serviço ainda estiver disponível e/ou não tiver data de expiração prevista.
details – Todos os outros detalhes, em formato textual não estruturado.
is_active – Se este serviço está ativo (em andamento) ou não. Esta é uma chave liga/desliga simples que podemos usar em alguns casos em vez do date_from – date_to intervalo de atividade de serviço. O melhor uso desse atributo seria simplificar as consultas, ou seja, testar esse valor em vez de testar o intervalo de datas e “jogar” com valores NULL.

Ingressos

A área de assunto anterior era apenas a preparação para o principal:ingressos. E é isso que esta área temática irá abordar.

Definimos empresas, zonas e formas de transporte, mas não temos previsão de passageiros e passagens – o núcleo desse modelo. Assumiremos que um bilhete pode ser usado para uma ou mais zonas cobertas por uma ou mais empresas.

Portanto, primeiro precisamos definir cada ticket_type . Nesta tabela, listaremos todos os tipos possíveis de ingressos vendidos pelas empresas em nosso banco de dados. Para cada tipo, armazenaremos os seguintes valores:

type_name – Um nome que denota EXCLUSIVAMENTE este tipo.
valid_from e valid_to – O período em que este tipo de bilhete é (ou era) válido. Ambos os campos são anuláveis; um valor NULL significa que não há data de início (ou término) para quando isso era válido.
details – Quaisquer detalhes necessários, em formato textual não estruturado.
recurring – Um sinalizador indicando se esse tipo de ingresso é recorrente (por exemplo, anual, mensal) ou não.
interval_month – Se o tipo de ticket for recorrente, este atributo conterá o intervalo, em meses, de quando ele se repete (por exemplo, “1” para um ticket mensal, “12” para um ticket anual).

Agora estamos prontos para definir as zonas cobertas por cada tipo de ticket. No service_included tabela, armazenaremos apenas o par UNIQUE ticket_type_id – service_available_id . Este último também indicará a empresa e a zona onde este bilhete pode ser usado. Esta tabela nos permite definir várias zonas por ticket; zonas podem pertencer a diferentes empresas. Uma vez que estes são tipos de bilhetes predefinidos, cada tipo de bilhete terá as zonas definidas aqui (não para cada passageiro individual).

Não armazenaremos muitos detalhes de passageiros neste modelo. Para cada passenger , armazenaremos apenas o first_name , last_name , address , e uma referência à cidade onde vivem. Todos esses dados serão exibidos no ticket.

A última tabela em nosso modelo é o ticket tabela. Não vamos nos concentrar em bilhetes de uso único aqui; em vez disso, lidaremos com assinaturas e bilhetes pré-pagos. Esses bilhetes terão um saldo, uma data de validade ou ambos. Isso pode diferir significativamente, com base na empresa e suas regras. Se algumas empresas decidirem emitir um bilhete, podemos apoiar isso nesta tabela - saberemos todos os detalhes importantes. Para cada bilhete, armazenaremos:

serial_number – Uma designação ÚNICA para cada bilhete. Pode ser uma combinação de números e letras.
ticket_type_id – Refere-se ao tipo desse ticket.
passenger_id – Refere-se ao passageiro, se houver, que possui esse bilhete. No caso de um bilhete pré-pago, não pode haver proprietário.
valid_from e valid_to – Indica o período durante o qual este bilhete é válido. Os valores NULL indicam que não há limite inferior ou superior.
credits – Os créditos (como valor numérico) atualmente disponíveis nesse bilhete. Se for um bilhete pré-pago, podemos supor que os passageiros comprarão créditos adicionais no bilhete. Se o bilhete for válido durante todo o mês (ou algum outro período de tempo) sem limites de uso, esse valor poderá ser NULL.

Melhorias no modelo de dados de transporte integrado

Você pode notar que este modelo foi bastante simplificado. Isso porque o transporte integrado é simplesmente grande demais para ser coberto em um artigo. Há algumas coisas que eu acho que poderiam ser alteradas neste modelo:

As zonas são muito simplificadas; devemos ser capazes de defini-los de forma mais dinâmica.
Não cobrimos linhas (por exemplo, linhas de ônibus). E se eles forem de uma zona para outra, etc.?
Não armazenamos o histórico de uso de ingressos.
Não há registro para empresas e passageiros.

Tudo isso levaria ao fato de que nos faltariam dados importantes e não poderíamos fazer uma análise mais profunda. Então, o que você acha? O que esse modelo precisa? O que você adicionaria ou removeria? Compartilhe suas ideias nos comentários.