Questão de Banco de Dados — Arquitetura de Banco de Dados — CESPE / CEBRASPE 2026
Banco de Dados›Arquitetura de Banco de Dados
Código
ce227877
Banca
CESPE / CEBRASPE
Órgão
SEFAZ-PR
Ano
2026
Nível
Médio
Cargo
Agente Fazendário Estadual - Função: Profissional de Tecnologia da Informação
Suponha que certa secretaria de fazenda necessite armazenar milhões de notas fiscais eletrônicas (NF-e) diariamente, e que esses documentos sejam gerados em formato XML ou JSON, com estrutura parcialmente flexível, mas com exigência de integridade transacional e rastreabilidade completa dos dados fiscais. Nesse caso, considerados os requisitos de alta volumetria, consistência dos dados e flexibilidade de esquema, a estratégia de arquitetura de dados mais adequada para esse cenário contempla a utilização de um banco de dados
Ado tipo chave-valor, que armazena o documento completo sob a chave de acesso, ainda que sem suporte à integridade fiscal e sem consultas estruturadas.
Borientado a documentos, com validação de estrutura apenas na leitura dos dados (schema-on-read).
Crelacional totalmente normalizado, com cada campo da NF-e armazenado em tabelas distintas, priorizando-se a integridade referencial em detrimento do desempenho.
Dde grafo, para mapear as relações entre emissores e destinatários e otimizar a detecção de fraudes.
Erelacional, com suporte a armazenamento de dados semiestruturados (JSON/XML) e índices, assegurando-se transações ACID para os campos críticos (como CNPJ, valor e data) e flexibilidade para o corpo do documento.
Revelar gabarito e comentário▾
GabaritoE — relacional, com suporte a armazenamento de dados semiestruturados (JSON/XML) e índices, assegurando-se transações ACID para os campos críticos (como CNPJ, valor e data) e flexibilidade para o corpo do documento.
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 para NF-e
Gabarito: letra E. O cenário exige alta volumetria, dados semiestruturados (XML/JSON), integridade transacional e rastreabilidade. A alternativa E — banco relacional com suporte a dados semiestruturados, índices e transações ACID nos campos críticos — atende a todos os requisitos. As demais opções falham por não garantir consistência (A, B, D) ou por sacrificar desempenho (C).
Requisito / Característica
Alternativa A (Chave-Valor)
Alternativa B (Orientado a Documentos)
Alternativa C (Relacional Totalmente Normalizado)
Alternativa D (Grafo)
Alternativa E (Relacional com JSON/XML)
Alta volumetria
Sim (alta escalabilidade)
Sim (alta escalabilidade)
Não (desempenho prejudicado por joins)
Não (não projetado para alto volume transacional)
Sim (com sharding/réplicas)
Flexibilidade de esquema (XML/JSON)
Sim (armazena documento completo)
Sim (schema-on-read)
Não (esquema rígido, totalmente normalizado)
Não (foco em relacionamentos)
Sim (tipos nativos JSON/XML)
Integridade transacional (ACID)
Não (sem suporte ACID forte)
Não (ACID fraco ou ausente)
Sim (prioriza integridade referencial)
Não (ACID não garantido)
Sim (ACID completo nos campos críticos)
Consultas estruturadas (filtros por valor)
Não (apenas por chave)
Sim (limitado, sem ACID)
Sim (mas com joins lentos)
Não (foco em relacionamentos)
Sim (com índices sobre JSON/XML)
Rastreabilidade fiscal
Não (sem consistência imediata)
Não (sem consistência imediata)
Sim (mas inviável na prática)
Não (não projetado para isso)
Sim (consistência imediata nos metadados)
Requisitos da NF-e
1Alta volumetria
2Dados semiestruturados (XML/JSON)
3Integridade transacional (ACID)
4Rastreabilidade
5Soluções
Relacional + JSON/XML
Índices nos campos críticos
Transações ACID
Escalabilidade (sharding/réplicas)
Chave-valor
Sem ACID
Sem consultas estruturadas
Documento (schema-on-read)
Sem ACID forte
Relacional totalmente normalizado
Desempenho inviável (joins)
Grafo
Sem ACID
Não é transacional
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
Bancos chave-valor armazenam documentos completos sob uma chave, sem suporte nativo a consultas estruturadas (ex.: filtros por valor). Embora ofereçam alta escalabilidade, não garantem ACID para campos críticos como CNPJ e valor, comprometendo a integridade fiscal exigida.
Alternativa B — ❌ Incorreta
Bancos orientados a documentos (ex.: MongoDB) aceitam esquemas flexíveis (schema-on-read), mas não oferecem transações ACID fortes para operações que envolvem múltiplos documentos ou atualizações concorrentes. A NF-e exige consistência imediata nos metadados fiscais, o que inviabiliza essa abordagem.
Alternativa C — ❌ Incorreta
Um banco relacional totalmente normalizado, com cada campo em tabelas separadas, prioriza integridade referencial, mas o desempenho seria severamente prejudicado por milhares de joins por consulta. A volumetria de milhões de NF-e/dia tornaria a operação inviável.
Alternativa D — ❌ Incorreta
Bancos de grafo são excelentes para analisar relacionamentos (ex.: detecção de fraudes), mas não são projetados para armazenamento transacional de alto volume com consultas simples de recuperação de documentos. A integridade ACID também não é garantida na maioria das implementações.
Alternativa E — ✅ Correta ⟵ GABARITO
Bancos relacionais modernos (ex.: PostgreSQL, Oracle) possuem tipos nativos de dados semiestruturados (JSON/XML), suporte a índices sobre campos desses documentos e transações ACID completas. Isso permite garantir consistência nos metadados fiscais (CNPJ, valor, data) enquanto mantém flexibilidade para o corpo variável da NF-e. A escalabilidade pode ser obtida via sharding ou réplicas.
NÃO CAIA NESSA!
A banca explora a falsa dicotomia entre NoSQL (flexibilidade) e relacional (rigidez). O candidato pode ser atraído pela alternativa B (documento) por aceitar XML/JSON, mas esquece que a integridade fiscal exige ACID — algo que bancos NoSQL tipicamente não garantem. A chave é perceber que o relacional com suporte a JSON/XML oferece o melhor dos dois mundos.
PEGA ESSA DICA!
Em concursos, quando o cenário menciona 'integridade transacional' e 'alta volumetria', pense em soluções híbridas: relacional com extensões NoSQL (como PostgreSQL com JSONB) ou bancos NewSQL. A alternativa E descreve exatamente essa combinação: "transações ACID para os campos críticos" e "flexibilidade para o corpo do documento".