Questão de Banco de Dados — Banco de Dados Relacionais — FURB 2025
Banco de Dados›Banco de Dados Relacionais
Código
qg497169
Banca
FURB
Órgão
Prefeitura de Florianópolis - SC
Ano
2025
Nível
Superior
Cargo
Auditor Fiscal de Tributos Municipais - Tecnologia da Informação - 2º Dia
Em um sistema de banco de dados relacional, que gerencia uma tabela com milhões de registros, é necessário otimizar consultas em uma coluna textual (VARCHAR(100)) que armazena nomes de produtos. A consulta mais comum utiliza o padrão LIKE 'prefixo%' para buscar produtos que começam com um prefixo específico, como SELECT * FROM produtos WHERE nome_produto LIKE 'eletr%';. Além disso, a tabela possui alta cardinalidade (muitos valores distintos) e é frequentemente atualizada com inserções e alterações. Considerando os diferentes tipos de índices disponíveis e suas características, assinale a alternativa que apresenta o tipo de índice mais eficiente para otimizar essas consultas, levando em conta tanto a performance de leitura quanto o impacto em operações de escrita:
AÍndice B-tree
BÍndice full-text
CÍndice hash.
DÍndice bitmap.
EÍndice espacial.
Revelar gabarito e comentário▾
GabaritoA — Índice B-tree
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”.
Índices em Banco de Dados Relacionais
Gabarito: letra A (Índice B-tree). O índice B-tree é o mais adequado para consultas com LIKE 'prefixo%' porque suporta busca por intervalo (range scan), convertendo o padrão de prefixo em uma condição de comparação. Além disso, é eficiente em colunas de alta cardinalidade e lida bem com operações frequentes de inserção e alteração, ao contrário dos demais tipos.
A questão testa o conhecimento sobre os diferentes tipos de índices e suas aplicações práticas. A consulta WHERE nome_produto LIKE 'eletr%' é uma busca por prefixo, que pode ser implementada como uma varredura de intervalo em uma estrutura ordenada. Vamos analisar cada alternativa.
Alternativa A — ✅ Correta ⟵ GABARITO
O índice B-tree (árvore balanceada) mantém os dados ordenados, permitindo que o SGBD converta LIKE 'prefixo%' em uma condição de intervalo: nome_produto >= 'prefixo' AND nome_produto < 'prefixo' + 'x' (ou similar). Isso é chamado de range scan e é muito eficiente. A B-tree também é robusta para alta cardinalidade (muitos valores distintos) e suporta bem operações de escrita (inserção/atualização), pois mantém a árvore balanceada com custo logarítmico.
Alternativa B — ❌ Incorreta
O índice full-text é projetado para busca textual com stemming, palavras-chave e relevância (como em documentos). Para um simples LIKE 'prefixo%', ele é desnecessário e geralmente menos eficiente que a B-tree, além de consumir mais recursos e ter maior impacto em escritas.
Alternativa C — ❌ Incorreta
O índice hash é otimizado apenas para consultas de igualdade (=, IN). Ele não suporta buscas por intervalo ou LIKE com prefixo, pois a função hash não preserva a ordem dos valores. Portanto, para LIKE 'eletr%', o índice hash seria ignorado, resultando em varredura completa da tabela.
Alternativa D — ❌ Incorreta
O índice bitmap é eficiente para colunas com baixa cardinalidade (poucos valores distintos, como sexo, estado civil). Em uma coluna com alta cardinalidade (milhões de nomes de produtos), o bitmap se torna enorme e ineficiente, além de ter performance ruim em operações de escrita (bloqueio de linhas).
Alternativa E — ❌ Incorreta
O índice espacial (R-tree) é específico para dados geométricos/geográficos (coordenadas, polígonos). Não se aplica a dados textuais.
NÃO CAIA NESSA!
A banca pode tentar induzir ao erro sugerindo o índice hash (por associar "busca rápida" com hash) ou o full-text (por associar "texto" com busca textual). Mas a chave é lembrar que LIKE 'prefixo%' é uma busca por intervalo — só a B-tree atende esse requisito e ainda lida bem com alta cardinalidade e escritas frequentes.