Modelo do Banco de Dados - edu-almeidaf/reservas-academicas GitHub Wiki

Modelo do Banco de Dados

1. Vídeo Explicativo

https://youtu.be/ryt-n5FjzaQ

2. Diagrama do Banco de Dados

O modelo de banco de dados foi projetado e normalizado para suportar as funcionalidades essenciais e os fluxos de processos do sistema Reservas Acadêmicas.

Domínios e Valores Restritos (Enums)

Para garantir a consistência e integridade dos dados, o banco de dados restringe os valores aceites em campos críticos através do tipo ENUM:

Campo Tabela Valores Permitidos Finalidade
profile users discente, docente, tecnico Define a hierarquia de acesso e as permissões de solicitação e aprovação.
status reservations pendente, deferido, indeferido, cancelado Controla o ciclo de vida da solicitação (toda nova reserva nasce como pendente).

3. Suporte aos Diagramas de Atividades

A modelagem do banco de dados foi estruturada especificamente para viabilizar as lógicas mapeadas nos diagramas de atividades do projeto:

Reserva Recorrente

Para suportar o fluxo de "Iniciar Nova Reserva Recorrente" (múltiplas datas e dias da semana), o banco separa a "Capa da Solicitação" dos seus "Horários":

  • Uma única requisição (com motivo, utilizador e recurso) é registada na tabela reservations.
  • Simultaneamente, todos os dias e horários selecionados geram múltiplos registos na tabela reservation_schedules, vinculados via reservation_id.

Isso permite agrupar dezenas de datas numa única solicitação, exigindo do aprovador apenas uma única ação de deferimento ou indeferimento.

Solicitação com Subdivisões e Orientador

O fluxo apresenta um desvio condicional onde os discentes são obrigados a "Selecionar um Responsável Orientador":

  • No banco de dados, isto é resolvido através da coluna advisor_id na tabela reservations, que atua como uma segunda chave estrangeira (FK) para a tabela users.
  • O campo é flexível (permite valores nulos no banco para atender a solicitações de docentes e técnicos), mas a obrigatoriedade de preenchimento para discentes é assegurada pelas regras de negócio no back-end (PHP).
  • A tabela pivot reservation_subdivision resolve a seleção de locais parciais, enquanto o cruzamento com reservation_schedules previne choque de horários simultâneos.

4. Atendimento aos Requisitos do Banco de Dados

O banco de dados garante o atendimento completo dos seguintes requisitos estipulados para o projeto:

  1. Autenticação: Gerenciada pela tabela users. A segurança é garantida armazenando a senha na coluna password_hash e impedindo a duplicidade de contas através da restrição UNIQUE no campo email.
  2. CRUD: O modelo permite as quatro operações básicas (Criação, Leitura, Atualização, Exclusão) nas entidades principais: Ambientes (resources), Subdivisões, Categorias e Reservas.
  3. Galeria de imagens (Relação 1xN): A tabela resource_images possui uma relação 1 para N com a tabela resources, permitindo atrelar diversas fotos a um mesmo ambiente/laboratório de forma independente.
  4. Relação NxN com Ajax: A tabela pivot reservation_subdivision resolve a cardinalidade N para N entre as reservas e as subdivisões. Na interface, requisições assíncronas via Ajax buscarão as subdivisões ativas de um recurso para que o solicitante as selecione dinamicamente.

5. Mapeamento de Tipos de Campos

Os atributos do banco refletirão os seguintes componentes nos formulários do sistema:

Campos de Entrada (Inputs)

  • text: users.name, reservations.motive, reservations.justification, resources.name.
  • email: users.email (com validação front-end e UNIQUE no banco).
  • password: users.password_hash (input do tipo password mascarado).
  • date / time: reservation_schedules.scheduled_date, reservation_schedules.start_time, e reservation_schedules.end_time.
  • file: resource_images.file_path (upload de arquivos de imagem do ambiente).

Campos de Seleção

  • select: Dropdowns para selecionar chaves estrangeiras, como a categoria do ambiente (resources.resource_category_id), a categoria da reserva (reservations.reservation_category_id), e o professor orientador (reservations.advisor_id, listando usuários com perfil docente).
  • checkbox: Opções múltiplas utilizadas na interface para a seleção associativa das partes de um ambiente (tabela pivot reservation_subdivision) e dias da semana recorrentes.
  • radio: Escolha única utilizada para o cadastro do perfil do usuário (users.profile), decisão do status de aprovação (reservations.status) e alternância de ativação de recursos (resources.active, subdivisions.active).

6. Padronização

O modelo obedece estritamente às convenções impostas no enunciado:

  • Nomenclatura (Tabelas e Colunas): Todos os termos estão em inglês. As tabelas estão no plural (users, resources) e as colunas seguem o padrão snake_case (password_hash, scheduled_date).
  • Tabelas Pivot: Nomeadas com os modelos no singular e em ordem alfabética (reservation_subdivision).
  • Chaves Primárias e Estrangeiras: As PKs são nomeadas exclusivamente como id. As FKs seguem a regra do nome da tabela referenciada no singular seguida de _id (ex: resource_id).

7. Uso de Inteligência Artificial

A estruturação desta etapa do projeto contou com o auxílio de ferramentas de IA para otimização de tempo e validação de boas práticas:

Ferramenta Finalidade Exemplo de Prompt Resultado Obtido
Gemini Conversão das regras de negócio em script DBML (Database Markup Language) para geração do diagrama. "Gere um código para o dbdiagram.io relacionando a tabela de reservas com uma tabela de cronogramas para suportar múltiplas datas, mantendo as chaves estrangeiras no padrão tabela_id." Geração ágil do script DBML respeitando as convenções de plural, snake_case e organização visual do diagrama Entidade-Relacionamento.