Diante de um Ministério Público Estadual que mantém grande volume de procedimentos em um banco de dados PostgreSQL, com consultas frequentes por número processual e junções entre tabelas por chaves estrangeiras, exigindo desempenho consistente e preservação da integridade relacional, o mecanismo que atende corretamente a exigência é
Acriar índices B-tree nas colunas do WHERE e do JOIN (incluindo Fks), mantendo PK/UK/FK.
Bremover a constraint de chave estrangeira para reduzir bloqueios em operações concorrentes.
Csubstituir a chave primária por campo textual desnormalizado, eliminando a estrutura relacional.
Dagregar periodicamente dados em tabela auxiliar para eliminar junções e reduzir custo de consultas.
Eusar índices hash em todas as colunas relacionais envolvidas em consultas e junções.
Revelar gabarito e comentário▾
GabaritoA — criar índices B-tree nas colunas do WHERE e do JOIN (incluindo Fks), mantendo PK/UK/FK.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Otimização de Consultas em PostgreSQL: Índices e Integridade Relacional
Gabarito: letra A. Para atender à exigência de desempenho consistente em consultas frequentes por número processual e junções entre tabelas por chaves estrangeiras, preservando a integridade relacional, a solução correta é criar índices B-tree nas colunas do WHERE e do JOIN (incluindo FKs), mantendo PK/UK/FK. Essa abordagem acelera a busca e a junção sem comprometer as restrições de integridade, que são fundamentais no modelo relacional.
O cenário descrito envolve um banco de dados relacional (PostgreSQL) com consultas frequentes por um campo específico (número processual) e junções entre tabelas por chaves estrangeiras. O objetivo é garantir desempenho consistente e preservar a integridade relacional. Para isso, é essencial entender o papel dos índices e das restrições de integridade.
O que são índices? Índices são estruturas de acesso auxiliares associadas a tabelas, utilizadas para agilizar a recuperação de registros em resposta a certas condições de pesquisa. Eles funcionam como um catálogo que aponta diretamente para as linhas que satisfazem um critério, evitando a varredura completa da tabela. No PostgreSQL, o tipo de índice padrão é o B-tree, que é eficiente para consultas por igualdade e por intervalo, sendo ideal para colunas usadas em cláusulas WHERE e em junções (JOIN).
Por que manter as restrições de integridade? As chaves primárias (PK), chaves únicas (UK) e chaves estrangeiras (FK) são restrições que garantem a consistência e a integridade dos dados. A PK identifica unicamente cada linha; a UK garante a unicidade de valores em uma coluna; e a FK assegura a integridade referencial, ou seja, que um valor em uma coluna de uma tabela deve existir como chave primária (ou candidata) na tabela referenciada. Remover essas restrições comprometeria a integridade relacional, permitindo dados inconsistentes.
Como funciona na prática? Suponha duas tabelas: procedimentos (com numero_processual como PK) e movimentacoes (com procedimento_id como FK referenciando procedimentos.numero_processual). Uma consulta frequente seria:
SELECT * FROM movimentacoes m JOIN procedimentos p ON m.procedimento_id = p.numero_processual WHERE p.numero_processual = '12345';
Sem índices, o PostgreSQL faria uma varredura sequencial em ambas as tabelas, o que é lento em grandes volumes. Criando um índice B-tree em procedimentos.numero_processual (que já é PK, então já tem índice) e em movimentacoes.procedimento_id (FK), a consulta usa os índices para localizar rapidamente as linhas correspondentes, melhorando o desempenho.
Distinção importante: Índices melhoram a performance de leitura, mas têm custos: pioram a performance de escrita (inserções, atualizações, deleções) e aumentam o consumo de espaço. Portanto, não se deve criar índices em todas as colunas indiscriminadamente, mas sim naquelas usadas em filtros e junções frequentes.
Pegadinha da banca: A banca explora a confusão entre otimização de desempenho e integridade relacional. Alternativas que propõem remover constraints ou desnormalizar dados podem até melhorar o desempenho em alguns casos, mas violam a integridade relacional, que é um requisito explícito do enunciado. A alternativa correta é a que concilia os dois: índices para desempenho e manutenção das constraints para integridade.
Guarde o critério decisivo: a solução deve atender simultaneamente a dois requisitos — desempenho consistente e preservação da integridade relacional. As alternativas que sacrificam um para obter o outro estão incorretas.
Critério
A (B-tree + manter PK/UK/FK)
B (remover FK)
C (desnormalizar PK)
D (tabela agregada)
E (hash em todas as colunas)
Preserva integridade relacional
✅ Sim
❌ Não
❌ Não
⚠️ Parcial (redundância)
✅ Sim
Adequado para JOINs frequentes
✅ Sim (B-tree otimiza junções)
⚠️ Melhora escrita, mas perde consistência
❌ Elimina junções, mas destrói modelo
⚠️ Só para consultas analíticas, não pontuais
❌ Hash não é ideal para junções
Custo de manutenção (escrita/espaço)
⚠️ Moderado (índices seletivos)
✅ Baixo (sem constraint)
✅ Baixo (sem estrutura relacional)
⚠️ Alto (processos periódicos)
❌ Alto (índices excessivos)
Atende aos 2 requisitos do enunciado
✅ Sim
❌ Não
❌ Não
❌ Não
❌ Não
Alternativa A — ✅ Correta ⟵ GABARITO
Criar índices B-tree nas colunas do WHERE e do JOIN (incluindo FKs), mantendo PK/UK/FK, atende perfeitamente à exigência. Os índices B-tree são o tipo padrão e mais eficiente para consultas por igualdade e junções, acelerando a localização dos registros. Manter as restrições de integridade (PK, UK, FK) preserva a consistência e a integridade relacional, que é um requisito do enunciado. Essa é a prática recomendada em bancos de dados relacionais.
Alternativa B — ❌ Incorreta
Remover a constraint de chave estrangeira para reduzir bloqueios em operações concorrentes é uma solução que compromete a integridade relacional. A FK é essencial para garantir que os dados referenciados existam, evitando inconsistências. Embora possa reduzir bloqueios em algumas operações, o custo de perder a integridade é inaceitável, pois o enunciado exige explicitamente a preservação da integridade relacional.
Alternativa C — ❌ Incorreta
Substituir a chave primária por campo textual desnormalizado, eliminando a estrutura relacional, é uma abordagem que destrói o modelo relacional. A PK é fundamental para identificar unicamente cada registro e para estabelecer relacionamentos. A desnormalização pode ser usada em cenários específicos de leitura intensa, mas não deve eliminar a estrutura relacional, pois isso viola a integridade e dificulta a manutenção dos dados.
Alternativa D — ❌ Incorreta
Agregar periodicamente dados em tabela auxiliar para eliminar junções e reduzir custo de consultas é uma técnica de sumarização (como em data warehouses), mas não é a solução adequada para o cenário descrito. O enunciado fala de consultas frequentes por número processual e junções entre tabelas, que são operações típicas de bancos transacionais (OLTP). Criar tabelas auxiliares agregadas pode até melhorar o desempenho de consultas analíticas, mas não elimina a necessidade de junções em consultas pontuais e pode introduzir redundância e inconsistência.
Alternativa E — ❌ Incorreta
Usar índices hash em todas as colunas relacionais envolvidas em consultas e junções não é a melhor prática. Índices hash são eficientes apenas para consultas por igualdade, não para junções por intervalo ou ordenação. Além disso, criar índices em todas as colunas relacionais é excessivo e pode degradar o desempenho de escrita e aumentar o consumo de espaço. O tipo de índice mais adequado para junções e consultas por igualdade em PostgreSQL é o B-tree, não o hash.
NÃO CAIA NESSA!
A banca tenta confundir o candidato oferecendo soluções que melhoram o desempenho às custas da integridade relacional (B, C) ou que são inadequadas para o cenário (D, E). A alternativa A é a única que equilibra desempenho e integridade, que são os dois requisitos explícitos do enunciado. Fique atento: quando a questão pede "desempenho consistente" e "preservação da integridade relacional", a resposta deve atender a ambos.
PEGA ESSA DICA!
Em questões sobre otimização de consultas, identifique os dois pilares: (1) índices para acelerar leituras e (2) constraints para garantir integridade. A alternativa que mantém ambos é a correta. Lembre-se: índices B-tree são o padrão para consultas por igualdade e junções; índices hash são específicos para igualdade e não são recomendados para junções.