Vamos construir mais alterações no modelo de dados, que criei em minha postagem anterior no blog, como ter uma abordagem automatizada para atribuir um instrutor e um veículo a uma aula, faturar aos clientes e rastreá-los.
Primeiro, preciso construir lógica no lado do aplicativo para atribuir um instrutor e um veículo às aulas antes que elas realmente ocorram. A principal coisa a garantir aqui é a disponibilidade, ou seja, um instrutor ou veículo pode ser atribuído a uma aula somente se ambos estiverem disponíveis no horário programado da aula.
Preciso construir duas tabelas separadas para acompanhar a ocupação dos instrutores e do veículo, respectivamente. Você pode estar se perguntando por que pretendo acompanhar a ocupação em vez da disponibilidade. A resposta é que, se rastrearmos a ocupação em vez da disponibilidade, não precisamos criar mais tabelas para armazenar a indisponibilidade de recursos devido a férias planejadas por instrutores ou algum serviço agendado para veículos. Em caso de indisponibilidade planejada, os registros são inseridos nas tabelas de ocupação de acordo.
Estou supondo aqui que instrutores e veículos estão disponíveis apenas durante o horário comercial, digamos, das 8h às 18h, em dias úteis definidos pela escola. Portanto, posso dizer que um instrutor está disponível em um horário especificado em um dia útil se não encontrar os detalhes de ocupação para o horário e dia especificados no
staff_occupancy tabela. A estrutura da tabela
staff_occupancy é o seguinte: 
Algumas variações podem ser colocadas conforme a necessidade. Por exemplo, deve haver um intervalo de pelo menos 15 minutos entre duas aulas subsequentes para um instrutor.
A estrutura da tabela vehicle_occupancy é o seguinte:
A alocação de instrutor e veículo é registrada na reservation tabela. Eu já tinha adicionado duas colunas, staff_id e vehicle_id , nesta tabela. Essas alocações, obviamente, acontecerão com base em sua disponibilidade.
Além disso, manterei reservation_id na staff_occupancy e vehicle_occupancy tabelas, para que em caso de cancelamento de uma aula, a ocupação relevante do pessoal e do veículo possa ser facilmente liberada. Mas manterei essas duas colunas como anuláveis pois a ocupação de instrutores e veículos não será necessariamente por reserva. E se um instrutor sair de licença? Ou um dos veículos vai para o centro de serviço por um dia?
Para permitir a exclusão reversível em tais cenários, adicionarei uma coluna chamada is_active em ambas as tabelas.
Faturamento
Para o requisito de faturamento, criarei uma tabela, chamada
invoice , para manter detalhes de faturamento, incluindo customer_id e reservation_id . Aqui, o faturamento deve ser feito para os clientes, mas com base nas lições realizadas para o cliente. Assim, precisamos do reservation_id coluna na tabela de faturas também, para que, a qualquer momento, seja possível obter um relatório sobre o faturamento detalhado com base em uma reserva para um cliente. Também criarei uma coluna, chamada invoice_status_id , na tabela para armazenar o status das faturas. 
Modelo de banco de dados
Aqui está a estrutura de banco de dados atualizada projetada em Vertabelo:
Conclusão
A essa altura você já deve ter começado a acreditar que a modelagem de dados para um sistema de reservas de uma autoescola é tão interessante e encantador quanto aprender a dirigir?
Sinta-se à vontade para postar suas dúvidas e sugestões sobre o artigo. Estou mais do que feliz em respondê-las e incorporar suas sugestões no meu próximo artigo.
