Maurício GasparySumário
Banco de Dados
Descrição
Esta seção visa fornecer uma breve introdução sobre o banco de dados escolhido para armazenar as informações manipuladas pela aplicação desenvolvida, assim como sua configuração e integrações no projeto.
Optou-se por utilizar o PostgreSQL como sistema de gerenciamento de banco de dados (SGBD) devido à sua escalabilidade, confiabilidade e suporte avançado a consultas SQL.
No projeto, o PostgreSQL é integrado ao backend desenvolvido em Python, onde as entidades são manipuladas por meio de repositórios, que realizam as operações de leitura, escrita e atualização diretamente no banco. Essa abordagem segue o padrão ORM (Object Relational Mapping), garantindo maior organização e segurança na manipulação dos dados.
Banco de dados escolhido (PostgreSQL)
A escolha de um banco de dados relacional possibilitou a estruturação das informações em tabelas relacionadas, assegurando integridade referencial e consistência nos dados.
O PostgreSQL oferece suporte a:
- Transações seguras, prevenindo inconsistências.
- Chaves primárias e estrangeiras para definir relacionamentos claros entre entidades.
- Índices para otimização de consultas complexas.
- Suporte a JSON, caso seja necessário armazenar dados semiestruturados.
Essa estrutura atende à necessidade do projeto de organizar, consultar e manter os dados de forma eficiente, especialmente em cenários com múltiplos usuários interagindo simultaneamente.
Diagrama do banco de dados
Abaixo está a representação visual do banco de dados, mostrando as entidades principais e como elas se relacionam:
![Diagrama do Banco de Dados] 
## Relacionamentos do Banco de Dados
Esta seção descreve como as tabelas do banco de dados estão conectadas, detalhando os relacionamentos entre as entidades principais.
---
### **1. Tabela `usuarios`**
- **Relacionamentos:**
- Relaciona-se com a tabela **iniciativas** através dos campos:
- `criado_por` → Identifica o usuário que **criou** a iniciativa.
- `editado_por` → Identifica o usuário que **editou** a iniciativa.
- `deletado_por` → Identifica o usuário que **deletou** a iniciativa.
- **Cardinalidade:**
- **Um usuário (0,1)** pode criar, editar ou deletar **muitas iniciativas**.
- Uma iniciativa **deve** ter pelo menos um usuário associado como criador.
---
### **2. Tabela `organizadores`**
- **Relacionamentos:**
- Está vinculada à tabela **iniciativas** por meio do campo `organizador_id`.
- Cada iniciativa está vinculada a **um único organizador**.
- **Cardinalidade:**
- **Um organizador (1)** pode estar relacionado a **muitas iniciativas (N)**.
---
### **3. Tabela `iniciativas`**
- **Relacionamentos principais:**
- **Com `organizadores`:**
- Cada iniciativa tem **um organizador responsável**, definido pelo campo `organizador_id`.
- **Com `usuarios`:**
- Relaciona-se aos usuários através dos campos de auditoria:
- `criado_por`, `editado_por`, `deletado_por`.
- **Com `iniciativa_horarios`:**
- Uma iniciativa pode ter **vários horários cadastrados**.
- Relacionamento 1:N (uma iniciativa para muitos registros de horários).
- **Com `tags`:**
- Relacionamento **muitos para muitos (N:N)** através da tabela intermediária `iniciativa_tag`.
---
### **4. Tabela `iniciativa_horarios`**
- **Relacionamentos:**
- Relaciona-se diretamente com a tabela **iniciativas** através do campo `iniciativa_id`.
- **Cardinalidade:**
- **Uma iniciativa (1)** pode ter **vários horários cadastrados (N)**.
- Cada horário pertence a **apenas uma iniciativa**.
---
### **5. Tabela `tags`**
- **Relacionamentos:**
- Conectada à tabela **iniciativas** através da tabela intermediária `iniciativa_tag`.
- **Cardinalidade:**
- **Uma tag (1)** pode estar associada a **várias iniciativas (N)**.
- **Uma iniciativa (1)** pode conter **várias tags (N)**.
- Este é um relacionamento clássico de **muitos para muitos (N:N)**.
---
### **6. Tabela `iniciativa_tag`** *(tabela intermediária)*
- **Função:**
- Faz a ligação entre `iniciativas` e `tags`.
- **Campos principais:**
- `iniciativa_id` → Referência para a tabela **iniciativas**.
- `tag_id` → Referência para a tabela **tags**.
- **Cardinalidade:**
- Cada registro associa **uma iniciativa** a **uma tag específica**.
---
### **7. Tabela `contatos`**
- **Relacionamentos:**
- **Não possui relacionamentos diretos** com outras tabelas no momento.
- É usada para armazenar mensagens enviadas pelos usuários, contendo:
- Nome
- E-mail
- Assunto
- Mensagem
- Data de envio (`enviado_em`)
---
## Resumo em formato de tabela
| Tabela | Relaciona-se com | Tipo de relacionamento |
|-------------------|--------------------------|------------------------|
| usuarios | iniciativas | 1:N (auditoria: criado, editado, deletado) |
| organizadores | iniciativas | 1:N |
| iniciativas | organizadores, usuarios, iniciativa_horarios, iniciativa_tag | Vários (1:N e N:N) |
| iniciativa_horarios | iniciativas | 1:N |
| tags | iniciativas (via iniciativa_tag) | N:N |
| iniciativa_tag | iniciativas, tags | Tabela intermediária |
| contatos | - | Isolada (sem relacionamento) |
---
## Representação geral dos relacionamentos
- **Usuários** gerenciam iniciativas (criando, editando, deletando).
- **Organizadores** estão vinculados a iniciativas como responsáveis principais.
- **Iniciativas** têm múltiplos horários e podem ser categorizadas por várias **tags**.
- **Tags** são gerenciadas através da tabela intermediária `iniciativa_tag`.
- **Contatos** servem como um repositório de mensagens enviadas, sem conexões diretas com outras entidades.