This is an old version of this page. You can view the most recent version or browse the history.

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.