Questão de Banco de Dados — Documentos (MongoDB e CouchDB) — FCC 2025

Consultas em bancos NoSQL orientados a documentos: busca em arrays

Gabarito: letra A. Em um banco NoSQL orientado a documentos, a forma mais adequada e eficiente de recuperar documentos cujo array contenha um elemento que atenda a uma condição é utilizar um operador nativo de busca dentro de arrays, como o $elemMatch do MongoDB. Essa abordagem delega a filtragem ao motor do banco, que pode usar índices multichave para otimizar a consulta, em vez de trazer todos os documentos para a aplicação e filtrá-los manualmente.

O cenário descrito é típico de bancos de dados NoSQL orientados a documentos, como MongoDB e CouchDB. Nesses bancos, um documento JSON pode conter campos que são arrays, como o campo "irregularidades" do enunciado. A necessidade de encontrar documentos onde pelo menos um elemento do array atenda a uma condição (ser "grave") é uma operação comum e, para isso, os bancos de documentos oferecem operadores específicos.

No MongoDB, por exemplo, a consulta db.auditorias.find({ "irregularidades": { "$elemMatch": { "classificacao": "grave" } } }) resolve o problema de forma eficiente. O operador $elemMatch garante que a condição seja aplicada a cada elemento do array individualmente, e não ao array como um todo. Além disso, o MongoDB suporta índices multichave (multikey indexes), que indexam cada elemento de um array, permitindo que a busca por um valor dentro do array seja feita de forma rápida, sem a necessidade de uma varredura completa (collection scan).

A alternativa B, que propõe filtrar os documentos no código da aplicação, é ineficiente porque exige que todos os documentos sejam transferidos do banco para a aplicação, para só então serem processados. Isso gera um alto custo de rede e processamento, especialmente com grandes volumes de dados, como é o caso de auditorias fiscais. A abordagem correta é sempre delegar ao banco de dados o máximo de trabalho possível, utilizando seus recursos nativos de consulta e indexação.

A alternativa C, que sugere uma consulta por igualdade direta no campo "irregularidades", está incorreta porque o campo é um array, e não um valor escalar. Uma consulta de igualdade em um array no MongoDB, como { "irregularidades": "grave" }, na verdade busca documentos onde o array contenha exatamente o valor "grave" como um de seus elementos, mas isso só funciona se os elementos do array forem strings simples. No caso do enunciado, as irregularidades são objetos com um campo "classificacao", então a consulta de igualdade não funcionaria. Além disso, a afirmação de que "todos os resultados possíveis são automaticamente retornados" é vaga e não reflete a necessidade de uma condição específica.

A alternativa D menciona um "tripleindex", que não é um conceito padrão em bancos de dados NoSQL. O termo correto para indexar arrays no MongoDB é índice multichave (multikey index). A alternativa confunde conceitos e não apresenta uma solução viável.

A alternativa E propõe criar um modelo relacional dentro do banco NoSQL, com coleções separadas e junções. Isso vai contra a filosofia dos bancos de documentos, que recomendam o uso de documentos incorporados (embedded documents) para reduzir a necessidade de junções, como mencionado no material de apoio: "Documentos e matrizes incorporados reduzem a necessidade de junções caras". Forçar um modelo relacional em um banco NoSQL é uma prática inadequada e ineficiente.

A pegadinha desta questão está em confundir a abordagem correta de consulta em arrays com outras práticas, como filtrar na aplicação ou usar consultas de igualdade simples. A banca explora o conhecimento específico de operadores nativos de bancos de documentos, como o $elemMatch do MongoDB.

Alternativa A — ✅ Correta ⟵ GABARITO

Esta é a abordagem correta. Bancos de dados NoSQL orientados a documentos, como o MongoDB, possuem operadores nativos para busca dentro de arrays, como o $elemMatch. Esse operador permite especificar uma condição que deve ser satisfeita por pelo menos um elemento do array. Além disso, o uso de índices multichave otimiza a consulta, tornando-a eficiente mesmo com grandes volumes de dados. A alternativa descreve exatamente essa solução: "Utilizar uma consulta que aproveite um operador nativo do banco NoSQL para busca dentro de arrays".

Alternativa B — ❌ Incorreta

Filtrar os documentos no código da aplicação é ineficiente. Essa abordagem exige que todos os documentos sejam carregados do banco para a aplicação, para só então serem processados. Com um grande volume de dados, como em auditorias fiscais, isso resulta em alto consumo de rede, memória e processamento. A melhor prática é sempre delegar a filtragem ao banco de dados, que pode usar índices para otimizar a busca.

Alternativa C — ❌ Incorreta

Uma consulta de igualdade simples no campo "irregularidades" não é adequada. O campo é um array de objetos, e a consulta de igualdade { "irregularidades": "grave" } buscaria documentos onde o array contém exatamente a string "grave", o que não é o caso. Para buscar em arrays de objetos, é necessário usar operadores como $elemMatch. Além disso, a afirmação de que "todos os resultados possíveis são automaticamente retornados" é incorreta, pois a consulta precisa especificar a condição desejada.

Alternativa D — ❌ Incorreta

O termo "tripleindex" não é um conceito padrão em bancos de dados NoSQL. O conceito correto para indexar arrays no MongoDB é o índice multichave (multikey index), que indexa cada elemento do array. A alternativa confunde a terminologia e não apresenta uma solução viável para a consulta.

Alternativa E — ❌ Incorreta

Criar um modelo relacional dentro de um banco NoSQL, com coleções separadas e junções, é uma prática inadequada. A filosofia dos bancos de documentos é usar documentos incorporados para reduzir a necessidade de junções, como mencionado no material de apoio: "Documentos e matrizes incorporados reduzem a necessidade de junções caras". Forçar um modelo relacional vai contra essa filosofia e resulta em consultas menos eficientes.

Gabarito: letra A