| ... | ... | @@ -157,3 +157,55 @@ 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.)
|
|
|
|
|
|
|
|
# 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 |
