Banco-de-Dados.md

@@ -156,4 +156,56 @@ OperationalKit.responsible_agent_id → Agent.id_agent.
 
 Agent (1) — (N) Team (líder e/ou membro)
 Team.leader_id → Agent.id_agent; Team.member_id → Agent.id_agent.
-(Para multi-membros por equipe, usar tabela de associação.)
+(Para multi-membros por equipe, usar tabela de associação.)
\ No newline at end of file
+
+# Documentação Complementar da Arquitetura de Dados
+
+# Escolha do PostgreSQL
+
+O PostgreSQL foi adotado como SGBD por ser uma solução open source, madura e estável, amplamente utilizada em ambientes corporativos e de missão crítica. Os principais fatores para a escolha foram:
+
+Confiabilidade e integridade transacional (ACID), fundamentais para preservar a cadeia de custódia dos dados judiciais e operacionais.
+
+Tipos de dados avançados (JSONB, arrays, enums) que se encaixam bem em atributos como descrições de materiais, metadados e ambientes de risco.
+
+Escalabilidade e extensões (como PostGIS, pgcrypto, unaccent) que permitem expandir a solução conforme novas necessidades (geolocalização, criptografia, buscas).
+
+Compatibilidade nativa com ferramentas ORM (Hibernate/JPA) e com ecossistema de containers (Docker/Kubernetes).
+
+# Escolha do DBeaver
+
+O DBeaver foi selecionado como ferramenta de cliente/gerenciamento de banco por ser multiplataforma, livre e compatível com PostgreSQL. Ele atende tanto desenvolvedores quanto analistas funcionais:
+
+Interface gráfica intuitiva para navegação, consultas SQL e modelagem de diagramas ER.
+
+Recursos de produtividade como geração de diagramas, importação/exportação de dados em diversos formatos, visualização de índices e constraints.
+
+Segurança: suporte a conexões com SSL/TLS e criptografia local de credenciais.
+
+Integração fluida com versionamento: permite executar scripts controlados pelo time diretamente do repositório.
+
+# Dockerização do Banco
+
+O banco foi containerizado via Docker Compose, garantindo reprodutibilidade do ambiente e simplificação do ciclo de vida (subida, atualização, destruição). Os principais pontos de configuração são:
+
+Persistência de dados via volumes Docker, para manter o estado entre execuções.
+
+Inicialização automatizada: scripts SQL/SH no diretório docker-entrypoint-initdb.d podem criar extensões, usuários e dados iniciais.
+
+Isolamento e rede interna: comunicação segura entre containers de aplicação e banco sem expor portas desnecessárias.
+
+Portabilidade: qualquer desenvolvedor pode subir o ambiente localmente ou em um servidor de teste com o mesmo arquivo Compose.
+
+# Integração com Hibernate (ORM)
+
+O Hibernate/JPA foi escolhido como camada ORM para reduzir o atrito entre o modelo relacional e a camada de objetos da aplicação Java:
+
+Mapeamento natural: o esquema reflete diretamente nas entidades do domínio (Operation, Target, Warrant, etc.), com relacionamentos 1:1 e 1:N respeitando as constraints (UNIQUE, FK).
+
+Portabilidade e abstração: queries podem ser escritas em JPQL ou Criteria API, mantendo o código desacoplado de SQL específico.
+
+Validação do schema: em produção, a aplicação é configurada para validar (ddl-auto=validate) a consistência entre modelo e banco.
+
+Escalabilidade: Hibernate permite configurações de lazy loading, cache de segundo nível e batching para lidar com grandes volumes de dados operacionais.
+
+Migrações controladas: uso de ferramentas como Flyway ou Liquibase integra com Hibernate, garantindo versionamento e controle de mudanças estruturais.
\ No newline at end of file