Modelo Relacional do Banco de Dados (DER)
Diagrama Entidade-Relacionamento e descrição detalhada das tabelas e seus relacionamentos no banco de dados da API Trace Point.
11. Diagrama Entidade-Relacionamento Visual
O diagrama abaixo ilustra as principais tabelas do banco de dados, suas colunas com respectivos tipos de dados, e os relacionamentos entre elas, fornecendo uma visão clara da estrutura de dados da aplicação. A explicação detalhada de cada tabela e relacionamento segue abaixo.
11.1. Detalhamento do Esquema do Banco de Dados
O banco de dados trace_point é projetado para gerenciar usuários, locais, eventos e os relacionamentos entre eles, como quais usuários visitaram quais locais e quais usuários estão inscritos em quais eventos. A seguir, uma descrição de cada tabela baseada no esquema fornecido.
Entidades Principais
Tabela: user (Usuário)
Armazena informações sobre os usuários da plataforma.
id(UUID, Chave Primária, Obrigatório, Padrão: Geração automática de UUID)name(VARCHAR(50), Obrigatório) - Nome completo do usuário.profile_pick(VARCHAR(60), Opcional) - URL para a foto de perfil.role(ENUMpublic.user_role_enum, Obrigatório, Padrão: 'visitor') - Papel do usuário (ex: 'admin', 'visitor', 'organizer').email(VARCHAR(40), Obrigatório, Único) - Email de login do usuário.password(VARCHAR(60), Obrigatório) - Senha do usuário (armazenada como hash).
Referenciada por: Tabela booking (via user_id), Tabela visited_places (via user_id).
Tabela: place (Local)
Representa os locais físicos cadastrados na aplicação.
id(UUID, Chave Primária, Obrigatório, Padrão: Geração automática de UUID)name(VARCHAR(40), Obrigatório) - Nome do local.type(ENUMpublic.place_type_enum, Obrigatório, Padrão: 'turistc') - Tipo do local (ex: 'cultural', 'restaurant').postal_code(VARCHAR(10), Obrigatório) - CEP do local.street(VARCHAR(30), Obrigatório) - Rua/Logradouro do local.number_house(VARCHAR(6), Obrigatório) - Número do endereço.complement(VARCHAR(100), Obrigatório) - Complemento do endereço.
Referenciada por: Tabela event (via place_id), Tabela visited_places (via place_id).
Tabela: event (Evento)
Descreve os eventos que ocorrerão e podem ser gerenciados pela plataforma.
id(UUID, Chave Primária, Obrigatório, Padrão: Geração automática de UUID)title(VARCHAR(40), Obrigatório) - Título do evento.event_date(TIMESTAMP without time zone, Obrigatório) - Data e hora do evento.description(VARCHAR(150), Obrigatório) - Descrição do evento.place_id(UUID, Chave Estrangeira paraplace.id, Opcional) - Identificador do local onde o evento ocorre. Pode ser NULO se um evento não tiver um local específico ou ainda não definido.
Referenciada por: Tabela booking (via event_id).
Tabelas de Relacionamento (Junção)
Tabela: booking (Reserva/Inscrição em Evento)
Implementa o relacionamento Muitos-para-Muitos entre Usuários (user) e Eventos (event).
event_id(UUID, Parte da Chave Primária, Obrigatório, Chave Estrangeira paraevent.id) - Identificador do evento. Ações em cascata: ON UPDATE CASCADE, ON DELETE CASCADE.user_id(UUID, Parte da Chave Primária, Obrigatório, Chave Estrangeira parauser.id) - Identificador do usuário.
A combinação de event_id e user_id é a chave primária, garantindo que um usuário só possa se inscrever uma vez em cada evento.
Tabela: visited_places (Locais Visitados)
Implementa o relacionamento Muitos-para-Muitos entre Usuários (user) e Locais (place), e armazena a data da visita.
user_id(UUID, Parte da Chave Primária, Obrigatório, Chave Estrangeira parauser.id) - Identificador do usuário. Ação em cascata: ON DELETE CASCADE.place_id(UUID, Parte da Chave Primária, Obrigatório, Chave Estrangeira paraplace.id) - Identificador do local. Ação em cascata: ON DELETE CASCADE.visit_date(TIMESTAMP without time zone, Obrigatório, Padrão:now()) - Data e hora em que a visita ocorreu.
A combinação de user_id e place_id é assumida como a chave primária para este relacionamento, indicando que um usuário só pode ter um registro de visita para um local específico nesta tabela; a visit_date armazena quando essa única visita registrada ocorreu. Para registrar múltiplas visitas de um mesmo usuário ao mesmo local em datas diferentes, a visit_date precisaria ser incluída na chave primária (formando uma PK composta por user_id, place_id, visit_date) ou a tabela visited_places deveria ter um identificador único próprio (como um campo id do tipo UUID).
Resumo dos Relacionamentos Principais
- Usuários ↔ Eventos (
booking): Muitos-para-Muitos. Um usuário pode participar de vários eventos, e um evento pode ter vários usuários participantes. - Usuários ↔ Locais (
visited_places): Muitos-para-Muitos com atributo (visit_date). Um usuário pode visitar vários locais, e um local pode ser visitado por vários usuários, registrando-se a data de cada visita (considerando a discussão sobre a chave primária devisited_placespara permitir múltiplos registros por par usuário-local). - Eventos ↔ Locais (
event.place_id): Muitos-para-Zero-ou-Um (lado do Local). Um evento pode opcionalmente estar associado a um único local (poisplace_idemeventé uma chave estrangeira que pode ser NULA). Múltiplos eventos diferentes podem estar associados ao mesmo local. Um local pode ter vários eventos associados a ele ou nenhum.