Questão de Banco de Dados — Arquitetura de Banco de Dados — FUNDATEC 2025
Banco de Dados›Arquitetura de Banco de Dados
Código
qg484499
Banca
FUNDATEC
Órgão
UFRGS
Ano
2025
Nível
Médio
Cargo
Técnico em Tecnologia da Informação/Área: Sistemas de Informação
Uma empresa de e-commerce precisa escolher a arquitetura de banco de dados mais adequada para diferentes necessidades do seu sistema. Nesse sentido, analise os cenários abaixo:• Cenário I: Armazenar informações de produtos com atributos fixos (código, nome, preço, categoria) e garantir consistência transacional para operações de venda.• Cenário II: Gerenciar logs de navegação dos usuários, comentários de produtos e dados de sessão com estrutura variável e alta velocidade de inserção.Considerando as características dos dados estruturados, não estruturados e os modelos de dados disponíveis, qual seria a escolha mais apropriada para cada cenário descrito?
EI: MySQL (relacional) – II: MongoDB (documentos).
Revelar gabarito e comentário▾
GabaritoE — I: MySQL (relacional) – II: MongoDB (documentos).
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”.
Arquitetura de Banco de Dados: Relacional vs NoSQL
Gabarito: letra E. O Cenário I (produtos com atributos fixos e consistência transacional) exige um banco relacional – o MySQL é um exemplo clássico. Já o Cenário II (logs, comentários e sessão com estrutura variável e alta inserção) pede um banco de documentos, como o MongoDB. A alternativa E é a única que casa corretamente os dois cenários.
A banca testa a capacidade de associar o perfil dos dados ao modelo de banco mais adequado. Dados estruturados e transações atômicas pedem um SGBD relacional (ACID). Dados semiestruturados e alta velocidade de escrita favorecem bancos NoSQL do tipo documentos, que não exigem esquema rígido e escalam horizontalmente.
Cenário
Características
Modelo ideal
Exemplo
I – Produtos
Atributos fixos, consistência transacional
Relacional (tabelas, ACID)
MySQL, PostgreSQL
II – Logs, comentários, sessão
Estrutura variável, alta inserção
Documentos (JSON, schema flexível)
MongoDB, CouchDB
Banco de dados
1Relacional (ACID)
Atributos fixos
Consistência transacional
Ex.: MySQL, PostgreSQL
2Documentos (NoSQL)
Estrutura variável
Alta velocidade de inserção
Ex.: MongoDB, CouchDB
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
Inverte as escolhas: coloca MongoDB (documentos) no Cenário I, que precisa de relacional, e PostgreSQL (relacional) no Cenário II, que demanda documentos. Poderia até funcionar, mas não é a mais adequada.
Alternativa B — ❌ Incorreta
Cassandra (colunar) não é ideal para transações de venda com atributos fixos – seu modelo é mais voltado a big data e consistência eventual. Oracle (relacional) até poderia armazenar logs, mas não é a melhor opção para estrutura variável e alta velocidade de inserção.
Alternativa C — ❌ Incorreta
Redis (chave-valor) é um cache, não atende a consistência transacional de produtos. Cassandra (colunar) pode lidar com logs, mas o modelo de documentos é mais flexível para comentários e dados de sessão.
Alternativa D — ❌ Incorreta
Neo4j (grafos) é especializado em relacionamentos complexos, não em catálogo de produtos com atributos fixos. Redis (chave-valor) não oferece estrutura para documentos complexos como comentários e sessões.
Alternativa E — ✅ Correta ⟵ GABARITO
MySQL (relacional) garante consistência e esquema fixo para os dados de produto e vendas. MongoDB (documentos) acomoda a variabilidade dos logs e comentários com alta performance de escrita. É a combinação mais acertada.
PEGA ESSA DICA!
Na prova, associe “atributos fixos + transações” a banco relacional; “estrutura variável + alta inserção” a banco de documentos. Memorize os casos de uso típicos de cada modelo NoSQL.