Banco de Dados

Home	Escopo	Gerência	Processo	Design	Configuração	Arquitetura	Banco de Dados	Continuidade

Sumário

Modelo Entidade Relacionamento

Visão geral

Este esquema organiza operações (missões) do MPRS e toda a informação ligada a alvos (targets): endereço, mandados, materiais apreendidos, prisões/medidas (compliance), recuperações de bens, registros do MBA Digital, reuniões e kits operacionais, além de agentes e equipes. O Target é o hub central que ancora as evidências e atos a uma Operation.

Entidades e atributos

Operation

Função: Representa a missão/ação oficial. Campos-chave:

id_operation (PK), name, scheduled_date, description, status (Planning|In_Progress|Completed|Cancelled).

Metadados jurídico-institucionais: responsible_prosecutor_office, responsible_prosecutor, pic_number, judicial_process, judicial_body, judicial_authority.

Auditoria: created_at, updated_at. Índices: status, pic_number, judicial_process (aceleram consultas típicas por situação e processos).

Target

Função: Nó central: local/pessoa/objeto de interesse dentro de uma Operation. Campos-chave:

id_target (PK), id_operation (FK → Operation), id_address (FK → Address).

Identificação: name, type (MBA_Digital|Compliance|Recovery), cpf (quando pessoa).

Risco/ambiente: danger_level (Low|Medium|High|Critical), geolocation, environment_description, flags (has_animals, has_cameras, has_weapons).

Observações e auditoria: observations, created_at, updated_at. Índices: type, id_operation, danger_level (facilitam consultas operacionais).

Address

Função: Endereço principal do Target. Campos-chave:

id_address (PK), postal_code, number, complement, created_at, updated_at. Índices: postal_code (buscas por CEP).

Warrant

Função: Mandados vinculados ao Target. Campos-chave:

id_warrant (PK), id_target (FK → Target).

type (SearchAndSeizure|Arrest|AssetRecovery), issuance_date, issuing_judge, file_pdf, created_at, updated_at. Índices: type (filtragem por natureza do mandado).

SeizedMaterial

Função: Materiais/evidências apreendidos no contexto do Target. Campos-chave:

id_material (PK), id_target (FK → Target).

Auditoria: created_at, updated_at. Índices: type.

Recovery

Função: Recuperação/apreensão de bens patrimoniais ligados ao Target. Campos-chave:

id_recovery (PK), id_target (FK → Target, unique).

asset_type (Vehicle|RealEstate|Values|Documents), asset_description, estimated_value, asset_location, originating_process, created_at, updated_at. Observação: id_target com unique implica relação 1:1 (um Target tem, no máximo, um registro de Recovery).

Compliance

Função: Prisões/medidas cautelares relacionadas ao Target. Campos-chave:

id_compliance (PK), id_target (FK → Target, unique).

arrest_type (Preventive|Temporary|Execution), arrest_warrant, issuance_date, issuing_judge, arrest_observations, created_at, updated_at. Observação: id_target unique ⇒ relação 1:1.

MbaDigital

Função: Registro específico do núcleo MBA Digital referente ao Target. Campos-chave:

id_mba (PK), id_target (FK → Target, unique).

objective, seizure_materials, additional_info, created_at, updated_at. Observação: id_target unique ⇒ relação 1:1.

Meeting

Função: Reuniões/briefings de campo associados ao Target. Campos-chave:

id_meeting (PK), id_target (FK → Target), location, date, time, created_at, updated_at. Cardinalidade: 1:N (muitos Meetings por Target).

OperationalKit

Função: Kit/itens operacionais destinados a um Target e sob responsabilidade de um Agente. Campos-chave:

id_kit (PK), id_target (FK → Target), responsible_agent_id (FK → Agent), materials, created_at, updated_at. Cardinalidade: N:1 para Target (vários kits por Target) e N:1 para Agent (um agente pode responder por vários kits).

Agent

Função: Usuários operacionais (polícia, MP, técnico, suporte). Campos-chave:

id_agent (PK), name, email (unique), password_hash, role, institution, unit, id_number (RG), id_type (CPF|RG|ID_POLICIAL), cpf (unique), phone, access_level (Administrator|Operator|Viewer), created_at, updated_at. Índices: cpf, email. Segurança: senha armazenada em password_hash (boa prática para autenticação).

Team

Função: Grupos formais de atuação. Campos-chave:

id_team (PK), name, type (Prosecutor|Police|Technical|Support), leader_id (FK → Agent), member_id (FK → Agent), created_at, updated_at. Índices: type. Observação de modelagem: o par leader_id/member_id permite apenas um membro por registro. Para múltiplos membros por equipe, o recomendado é normalizar com uma tabela de associação TeamMember (id_team, id_agent, role_na_equipe).

Relacionamentos (cardinalidades e chaves)

Operation (1) — (N) Target Target.id_operation → Operation.id_operation.

Address (1) — (N) Target Target.id_address → Address.id_address.

Target (1) — (N) Warrant, SeizedMaterial, Meeting, OperationalKit Cada uma possui id_target como FK para Target.id_target.

Target (1) — (1) MbaDigital, Compliance, Recovery id_target unique em cada uma ⇒ 1:1 (no máximo um registro por Target em cada domínio).

Agent (1) — (N) OperationalKit 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.