Modelo de banco de dados para o sistema de reservas de uma autoescola. Parte 1

Preciso projetar um modelo de dados para um sistema de reservas para uma escola de condução. A área de assunto parece bastante direta, mas as complexidades ainda estão envolvidas. Você precisa acompanhar todas as solicitações dos clientes e acompanhar os recursos (veículo, tempo e instrutor) consumidos durante as aulas.

Introdução

Gosto de usar uma abordagem orientada por domínio para projetar um modelo de dados. Isso me faz deixar de lado a obsessão por tecnologia e me concentrar principalmente em modelar a área de assunto que gira em torno de suas entidades associadas e relacionamentos entre si.

Requisitos em poucas palavras

Deixe-me primeiro colocar o requisito em inglês simples primeiro.

Preciso de um modelo de dados para uma escola de condução para permitir clientes para fazer reservas para aulas conectados. A escola de condução pode ter mais de um instrutor e mais de um veículo . O instrutor é designado para a aula mediante reserva. O sistema deve permitir que os clientes cancelem a(s) reserva(s) a qualquer momento antes do dia agendado. O veículo atribuído à aula também deve ser registrado se a aula ocorrer.

Entidades e relacionamentos envolvidos

Quando penso no assunto, as entidades que vêm primeiro à minha mente são, “Cliente” , “Instrutor” , “Aula de direção” , “Solicitação de reserva” e “Veículo” . Deixe-me começar com minha primeira tabela para este modelo, que é customer . É para armazenar dados mestre para clientes. Eu provavelmente precisaria de outra tabela para armazenar os detalhes do instrutor, mas em vez de criar uma tabela com o nome do instrutor, criarei uma tabela genérica chamada staff para detalhes da equipe e mantenha “Instrutor” como um cargo. Isso tornará meu modelo de dados extensível para atender também a outras áreas de serviço, como trabalho administrativo e jurídico, de uma escola de condução.

Considero "curso de condução" como um dos serviços, então crio outra tabela chamada service . Um serviço, “curso de condução” neste caso, pode ter várias aulas. Para lidar com esse requisito, certamente preciso de outra tabela mestra, a saber, lesson , e uma tabela de relacionamento, chamada service_lesson , para gerenciar muitos para muitos relacionamentos entre essas duas entidades mestres, ou seja, um serviço pode definitivamente ter várias lições, mas por outro lado, uma lição também pode fazer parte de mais de um serviço.

Ao submeter um pedido de reserva, é-lhe pedido que preencha os seus dados e preferências preliminares como o tipo de serviço que pretende, escolha da viatura e data de início. Os detalhes do cliente são armazenados na tabela de clientes. Posteriormente, uma solicitação é criada na request tabela e todas as preferências são armazenadas em relação à solicitação na mesma tabela. Existem determinados status associados a cada solicitação, como "enviar", "em andamento", "cancelar" e "concluído". Vou criar uma tabela de suporte para ela chamada request_status .

No momento da submissão do pedido, coloca-se a preferência por veículo, ou seja, tipo de veículo. No entanto, o veículo seria realmente atribuído a uma aula quando ela ocorrer. Portanto, mantenho vehicle_type_id como uma das colunas em request mesa por enquanto.

Quando uma solicitação é processada, são feitas reservas para cada aula da solicitação de serviço. Além disso, instrutores e veículos são atribuídos a cada aula com base na disponibilidade dos instrutores e nas preferências dos clientes por veículos. As aulas estão agendadas para datas futuras com status “Aberto”. Todos esses detalhes são capturados em outra tabela de transações chamada reservation . Eu destaquei todas as tabelas de transações com uma cor diferente de todas as tabelas mestras.

Uma tabela mestra, reservation_status , é criado para armazenar todos os valores possíveis para status de reserva como “aberto”, “em andamento”, “cancelar” e “concluído”.

Esse modelo permite que um cliente cancele uma aula individual, bem como a solicitação de serviço como um todo. Se o cliente cancelar a solicitação de serviço, todas as aulas restantes agendadas para o cliente serão canceladas na tabela de reservas.

Consulte o modelo de dados criado por mim usando o Vertabelo para obter detalhes no nível da coluna de todas essas tabelas. Alguns pontos sobre a criação de colunas:

Uma coluna de sinalização chamada is_active é adicionado a todas as tabelas mestras para permitir a exclusão reversível de registros. Por exemplo, se algum instrutor sair da escola, mudaremos a bandeira para "N" para tornar seu registro inativo.
Certas colunas como created_date , created_by , last_modified_date e last_modified_by são adicionados em todas as tabelas de transações para permitir uma trilha de auditoria para alterações nos registros. As tabelas de transações são destacadas em azul no modelo de dados criado no Vertabelo.
Você deve estar se perguntando qual é o address_id coluna na staff mesa é para. Eu coloquei esta coluna propositalmente na staff table para que eu possa estender meu modelo de dados para dar suporte a um processo automatizado para atribuir um instrutor a uma solicitação com base em sua localização. Por exemplo, suponha que na cidade de Nova York, uma solicitação de White Plains chegue. Meu sistema deve primeiro procurar um instrutor disponível na mesma vizinhança ou nas proximidades. Meu sistema nunca deve atribuir um instrutor hospedado em Manhattan, que fica a quase 80 quilômetros de distância do local do solicitante.

Recursos importantes deste modelo

Este modelo permite que os clientes façam solicitações de reserva de acordo com suas preferências de data de início e veículo.
Permite cancelar uma ou mais aulas do curso ou o curso inteiro.
Este modelo captura os detalhes do instrutor e do veículo para cada lição.
Este modelo é extensível para lidar com todos os serviços possíveis fornecidos por uma escola de condução.
Ele nos permite projetar cursos de treinamento e planejar aulas de forma eficaz.

Modelo de banco de dados

Aqui está o design do banco de dados para o nosso sistema de reservas. O modelo foi criado em Vertabelo para banco de dados Oracle, mas o mesmo design pode ser implementado para outros mecanismos de banco de dados sem alterações significativas.

Conclusão

Existem certas áreas de assunto que não abordamos neste artigo, como:

Podemos criar uma abordagem automatizada para alocar veículos e instrutores para as aulas?
Que tal faturar clientes? E se um cliente não quiser pagar pelo curso inteiro, mas por algumas aulas? Podemos disponibilizar essas aulas para ele?

Nosso modelo existente suporta esses recursos? A resposta é não. Eu provavelmente cobrirei essas áreas de assunto no meu próximo artigo.