Questão de Banco de Dados — Arquitetura de Banco de Dados — FGV 2026
Banco de Dados›Arquitetura de Banco de Dados
Código
fg133930
Banca
FGV
Órgão
TJ-RJ
Ano
2026
Nível
Superior
Cargo
Analista Judiciário - Tecnologia da Informação - Arquiteto de Dados
A empresa Ômega está criando um site de e-commerce para impulsionar suas vendas. O site precisa armazenar milhões de registros de pedidos e, para atender à regra de negócio, executar consultas rápidas com base em um identificador do cliente (ex.: CPF). De forma a atender às demandas do novo site de maneira mais adequada, a empresa Ômega fará uso da tecnologia de banco:
ANoSQL chave-valor;
Bde dados relacional;
Cde dados em grafos;
Dde dados em memória;
ENoSQL orientado a documentos.
Revelar gabarito e comentário▾
GabaritoB — de dados relacional;
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”.
Banco de dados para e-commerce: relacional x NoSQL
Gabarito: letra B. O banco de dados relacional é a tecnologia mais adequada para sistemas transacionais de e-commerce que exigem consultas rápidas por identificador (CPF) e consistência dos dados. Os SGBDs relacionais suportam índices, garantem as propriedades ACID (Atomicidade, Consistência, Isolamento, Durabilidade) e permitem consultas complexas com joins, características indispensáveis para milhões de registros de pedidos.
A banca testa o conhecimento sobre os tipos de bancos de dados e suas aplicações típicas. Embora bancos NoSQL sejam dimensionáveis horizontalmente, a necessidade de consultas exatas por CPF (chave candidata) e a integridade transacional tornam o modelo relacional a escolha madura e consolidada para esse cenário.
NoSQL chave-valor. Embora ofereça baixa latência para acessos por chave, esse modelo é mais adequado para cache ou sessões temporárias, não para consultas complexas e garantia de consistência forte exigida em pedidos de e-commerce. Além disso, a recuperação por CPF é pontual, mas o sistema precisa de mais operações (listar pedidos por data, calcular totais) que exigem flexibilidade relacional.
Alternativa B — ✅ Correta ⟵ GABARITO
Banco de dados relacional. Modelo maduro com suporte a índices, integridade referencial, consistência ACID e linguagem de consulta declarativa (SQL). Índices em CPF permitem buscas rápidas mesmo em milhões de registros. É o padrão para sistemas empresariais transacionais, como e-commerce.
Alternativa C — ❌ Incorreta
Banco de dados em grafos. Ideal para dados com muitos relacionamentos (redes sociais, recomendações), mas o cenário descrito não exige navegação por relacionamentos complexos. A consulta por CPF é mais simples e eficiente num modelo relacional.
Alternativa D — ❌ Incorreta
Banco de dados em memória. Extremamente rápido, porém volátil e caro para armazenamento persistente de milhões de registros. Seria usado como cache, não como base primária para pedidos. A perda de dados em caso de falha seria inaceitável para um e-commerce.
Alternativa E — ❌ Incorreta
NoSQL orientado a documentos. Adequado para dados semiestruturados e hierárquicos (ex.: catálogo de produtos), mas a necessidade de transações ACID e consultas por CPF é melhor atendida por modelo relacional. Documentos não oferecem integridade referencial nativa e são menos eficientes para operações de junção.
NÃO CAIA NESSA!
A banca pode tentar induzir a escolha de NoSQL (chave-valor ou documentos) argumentando grande volume de dados. Porém, milhões de registros não são problema para bancos relacionais modernos com índices bem projetados. A chave é o requisito de consulta rápida por CPF, que é exatamente o ponto forte de índices relacionais. Grave: em sistemas transacionais que exigem consistência, o modelo relacional continua sendo a primeira opção.