Modelo de Dados

O banco de dados do projeto está classificado como “item a ser definido” no documento de escopo. Esta seção será atualizada conforme a definição da tecnologia e modelagem.

Considerações Arquiteturais

A escolha do banco de dados é uma decisão crítica para o Promete, especialmente considerando a natureza do módulo de Relacionamento, que propõe um grafo de vínculos entre pessoas, organizações e territórios.

Desafios de Modelagem

Desafio	Descrição
Grafo de relacionamentos	Consultas que envolvem múltiplos níveis de vínculo (ex: “pessoas ligadas a organizações de um território que têm demandas sobre saúde”) exigem modelagem otimizada
Volume de dados	O sistema deve suportar dezenas de milhares de contatos com histórico completo de interações
Performance	Consultas complexas no grafo não podem comprometer o tempo de resposta da aplicação
Flexibilidade	Novos tipos de relacionamento e atributos devem poder ser adicionados sem reestruturação do banco

Abordagens Possíveis

Abordagem	Tecnologia	Prós	Contras
Relacional com otimização	PostgreSQL (via Supabase)	Maturidade, ecossistema, equipe familiarizada	Consultas de grafo complexas podem ser lentas
Banco de grafos dedicado	Neo4j, ArangoDB	Performance nativa para consultas de grafo	Complexidade adicional na stack, curva de aprendizado
Híbrido	PostgreSQL + extensão de grafos	Equilíbrio entre familiaridade e performance	Complexidade de manutenção

Recomenda-se que a definição do banco de dados considere benchmarks com o volume esperado de dados e os padrões de consulta mais frequentes do módulo de Relacionamento.

Arquitetura do Sistema

Stack Tecnológica

Integrações Externas

Requisitos Não Funcionais

Modelo de Dados

Modelo de Dados

Considerações Arquiteturais

Desafios de Modelagem

Abordagens Possíveis

​Modelo de Dados

​Considerações Arquiteturais

​Desafios de Modelagem

​Abordagens Possíveis

Modelo de Dados

Considerações Arquiteturais

Desafios de Modelagem

Abordagens Possíveis