Um modelo de banco de dados para um serviço de táxi

O que queremos alcançar com este modelo de banco de dados de cabine?

• Criar programações de motoristas
• Acompanhar a disponibilidade do motorista em tempo real
• Forneça aos motoristas uma lista de possíveis viagens
• Permitir que os motoristas selecionem uma viagem da lista
• Calcule as horas de trabalho e os ganhos dos motoristas
• Armazene várias estatísticas (por exemplo, porcentagem de viagens canceladas, pagamentos por motorista por mês etc.)

O que precisamos saber sobre empresas de táxi?

1. 
   Quando os motoristas funcionam?
   Na maioria das empresas de táxi, os motoristas têm horários predefinidos. Saberemos os horários exatos em que o motorista começa e termina um turno. Em alguns casos, os horários de início e término do turno não são definidos com antecedência. Por exemplo, membros de uma associação de táxi podem fazer login e começar a trabalhar quando quiserem. Eles também podem fazer logout e encerrar o turno quando quiserem. Nosso modelo deve ser capaz de suportar ambas as opções.
   
2. 
   Um motorista pode trabalhar em vários turnos no mesmo dia?
   Se o motorista for membro de uma associação de táxi, ele poderá trabalhar de manhã, ir para casa e trabalhar novamente na mesma noite. No entanto, em algumas áreas (como a cidade de Nova York), existem restrições legais sobre a duração do turno e/ou quantas horas os taxistas podem trabalhar por dia.
   
3. 
   3. Quem inicia uma viagem?
   Na maioria dos casos, o cliente entrará em contato com a central de atendimento do táxi e o despachante inserirá sua solicitação no sistema. Outro cenário ocorre quando o cliente pede um táxi diretamente (por meio de um aplicativo móvel, por exemplo) e não há nenhum funcionário do call center envolvido no processo. Uma terceira opção – que também dispensa o call center – ocorre quando um cliente pega um táxi na estação ou chama um na rua.
   

O modelo de dados

Seção 1:táxis, motoristas e turnos

Tudo começa com táxis e motoristas:precisamos de carros em uma empresa de táxi e precisamos de motoristas. (No futuro, provavelmente precisaremos ajustar nosso modelo para carros autônomos. Mas vamos ficar no presente por enquanto.)

Começaremos nossa exploração do modelo de dados com o driver tabela. Nesta tabela, incluiremos os atributos usuais como nome, sobrenome e data de nascimento. Também teremos alguns atributos bastante específicos para este modelo:

• driving_licence_number – Este é um número de identificação ou código alfanumérico normalmente encontrado em uma licença emitida pelo governo. Como esse ID é único no mundo real, também será único em nosso banco de dados. (Em algumas áreas, os motoristas de táxi devem ter um tipo especial de licença de operação para trabalhar; vamos supor que eles a tenham.)
• expiry_date – Esta é a data em que a carteira de motorista não é mais legalmente válida. Observe que não armazenaremos o histórico de licenças, então simplesmente substituiremos driving_licence_number e expiry_date com novos dados conforme necessário. Se quisermos armazenar históricos de licenças, precisaremos adicionar outra tabela ao nosso modelo.
• working – Este é um valor booleano que simplesmente liga e desliga conforme os drivers fazem login no sistema. Por padrão, definiremos esse atributo como "Sim" (valor 1) e o alteraremos para "Não" somente quando o driver não tiver mais permissão para fazer login no sistema.

• model_description – Este é um atributo de texto que mantém uma descrição especificada pela empresa de um determinado tipo de carro. Por exemplo, as empresas de táxi podem querer armazenar o número de passageiros que um carro pode transportar, o espaço do porta-malas e outros dados.
• license_plate – O número em uma placa (placa de matrícula do veículo ou placa de matrícula) define exclusivamente um carro, tanto para uma empresa quanto para fins governamentais. Obviamente, podemos precisar alterar as informações da placa se um carro for comprado ou vendido. Nesta tabela, armazenaremos apenas os veículos atuais da empresa; se precisarmos manter um histórico, podemos adicionar mais uma tabela ao nosso modelo.
• owner_id – Este atributo é uma referência ao driver tabela. É opcional porque só o usaremos quando o motorista for o proprietário do táxi. (Isso geralmente é o caso em associações de táxi).
• active – Este é um valor booleano que indica se a empresa ainda está usando um carro.

Seção 2:Passeios

Esta seção é composta por apenas duas tabelas, mas elas são o verdadeiro coração deste modelo.

No cab_ride tabela, armazenaremos um registro para cada viagem em potencial. Atualizaremos este registro de acordo com o que acontecer. Vamos ter uma visão geral rápida dos atributos:

• shift_id – Esta é uma referência ao shift tabela; ele nos fornece detalhes do motorista e do táxi para uma determinada viagem.
• ride_start_time e ride_end_time – Eles são atualizados quando os motoristas sinalizam que estão ocupados no momento (início da viagem) e, posteriormente, disponíveis novamente (final da viagem).
• address_starting_point e address_destination – Estes são os locais onde um passeio começa e termina. O motorista provavelmente pesquisará os dois locais para obter a navegação em seu tablet ou GPS, então provavelmente atualizaremos esses dois atributos.
• GPS_starting_point e GPS_destination – Estas são as coordenadas GPS dos locais de início e fim descritos acima. Esses valores são opcionais porque os atualizaremos somente quando tivermos dados.
• canceled – Este é um valor Sim/Não simples que nos informa se uma viagem foi cancelada. Já teremos um registro para essa viagem em nossa tabela, para que possamos marcar a viagem como cancelada.
• payment_type_id e price – Fornecem informações sobre o valor pago por uma corrida e a forma de pagamento utilizada pelo cliente.

• As viagens são canceladas, o que significa que nenhum dado será inserido nesses campos;
• Mesmo que tenhamos todos os dados eventualmente, não teremos todos quando o registro for inserido inicialmente. Atualizaremos cada registro várias vezes – no mínimo, atualizaremos quando a viagem começar e terminar (ou for cancelada).

• cab_ride_id e status_id – Essas são chaves estrangeiras relacionadas ao atributo id no ride table e o atributo id no status tabela (que abordaremos abaixo). Ambos são obrigatórios.
• status_time – Armazena a hora real em que o registro foi inserido. Também é obrigatório.
• cc_agent_id e shift_id – São referências ao empregado que inseriu uma atualização de status. Pode ser um despachante ou um motorista. Provavelmente o despachante irá inserir o status inicial e o motorista irá inserir todos os seguintes status.
• status_details – Este é um atributo de texto que pode ser usado para armazenar informações adicionais. Por exemplo, um expedidor pode usar esse atributo para registrar instruções especiais sobre uma viagem.

Tabelas não categorizadas

O cc_agent A tabela contém uma lista de agentes ou expedidores de call center que podem adicionar novos registros no cab_ride e cab_ride_status mesas.

No status dicionário, armazenaremos uma lista de todos os status possíveis que poderíamos atribuir a uma viagem. Alguns valores incluem “nova viagem” , “carona atribuída ao motorista” , “passeio iniciado” , “passeio encerrado” , ou “viagem cancelada” .

Payment_type é outra tabela de dicionário. Seu conteúdo é usado para atualizar o payment_type_id atributo no cab_ride tabela. Os valores comuns são “dinheiro” e "cartão de crédito" .

Como você melhoraria o modelo de dados de táxi?