Modelagem Relacional
O TamoJunto é uma plataforma de eventos comunitários. Pessoas criam eventos, outras pessoas confirmam presença. Para armazenar essas informações, vamos usar um banco de dados relacional — especificamente, o PostgreSQL.
Um banco de dados relacional organiza informações em tabelas. Cada tabela representa uma entidade do domínio (um evento, um usuário, uma confirmação de presença). Cada linha da tabela é um registro (um evento específico, um usuário específico). E cada coluna é um atributo daquele registro.
Que tabelas o TamoJunto precisa agora? Duas:
events— os eventos da plataforma.users— as pessoas que criam e participam dos eventos.
A tabela events
Um evento no TamoJunto tem título, descrição, local, data, e uma capacidade máxima de participantes. Cada evento é criado por alguém — um organizador. E precisamos de um identificador único para cada registro.
| Coluna | Tipo | Descrição |
|---|---|---|
id | SERIAL | Identificador único, gerado automaticamente |
title | VARCHAR(200) | Título do evento |
description | TEXT | Descrição detalhada |
location | VARCHAR(200) | Local onde o evento acontece |
date | TIMESTAMP | Data e horário do evento |
capacity | INTEGER | Número máximo de participantes |
organizer_id | INTEGER | Quem criou o evento (referência à tabela users) |
created_at | TIMESTAMP | Quando o registro foi inserido no banco |
A coluna organizer_id é especial: ela não armazena o nome do organizador, mas
sim o id de um registro na tabela users. Isso é um foreign key (chave
estrangeira), e é a forma como bancos relacionais representam relações entre
tabelas. Mas calma — esse foreign key ainda não existe na primeira versão da
tabela. Ele será adicionado por uma segunda migration, depois que a tabela
users for criada.
A tabela users
Por enquanto, um usuário tem apenas nome e e-mail:
| Coluna | Tipo | Descrição |
|---|---|---|
id | SERIAL | Identificador único |
name | VARCHAR(100) | Nome do usuário |
email | VARCHAR(200) | E-mail (único por usuário) |
created_at | TIMESTAMP | Quando o registro foi criado |
A coluna email tem uma restrição de unicidade: dois usuários não podem ter o
mesmo e-mail. Isso é um constraint (restrição) — o banco de dados impede a
operação se alguém tentar violar essa regra.
Relacionamentos
A relação entre events e users é muitos para um (many-to-one): um
usuário pode organizar vários eventos, mas cada evento tem exatamente um
organizador. Essa relação é materializada pelo foreign key organizer_id na
tabela events, que aponta para id na tabela users.
Se você tentar inserir um evento com organizer_id = 99 e não existir nenhum
usuário com id = 99, o banco de dados rejeita a operação com um erro. Isso
mantém a integridade dos dados — todo evento sempre tem um organizador válido.