Questão de Banco de Dados — Tópicos Mesclados de Outros Tipos e Modelos de Banco de Dados — FCC 2025

Banco de dados relacional × NoSQL: escolha pelo perfil dos dados

Gabarito: letra A. A solução mais adequada é usar um banco de dados relacional para a base de servidores públicos — que exige consistência transacional, integridade referencial e muitos relacionamentos — e um banco NoSQL orientado a documentos para os eventos de atendimento ao cidadão, que têm estrutura flexível, dinâmica e crescem rapidamente. Essa combinação aproveita o ponto forte de cada tecnologia: o relacional garante ACID e integridade; o NoSQL orientado a documentos oferece flexibilidade de esquema e escalabilidade horizontal.

A questão cobra o princípio fundamental da modelagem de dados: não existe um único modelo de banco de dados adequado para todos os cenários. Cada tecnologia foi desenhada para resolver problemas diferentes, e a escolha certa depende da natureza dos dados e das necessidades operacionais. Vamos entender isso a fundo.

O que é um banco de dados relacional?

O modelo relacional organiza os dados em tabelas (relações) com linhas e colunas, e estabelece relacionamentos entre elas por meio de chaves primárias e estrangeiras. Ele é fortemente baseado em esquema rígido: antes de inserir qualquer dado, é preciso definir a estrutura das tabelas, os tipos de cada coluna e as restrições de integridade. Essa rigidez é justamente o que garante a consistência transacional (propriedades ACID — Atomicidade, Consistência, Isolamento e Durabilidade) e a integridade referencial (regras que garantem que um registro referenciado por outro exista de fato).

Por isso, o relacional é a escolha natural para dados estruturados, com muitos relacionamentos e que exigem alta confiabilidade — exatamente o caso da base de servidores públicos: CPF, matrícula, cargo, vínculo a departamentos. Cada servidor pertence a um departamento, ocupa um cargo, tem um histórico de vínculos; essas relações precisam ser preservadas com rigor. Um erro de integridade aqui (por exemplo, um servidor vinculado a um departamento inexistente) seria inaceitável.

O que é um banco NoSQL orientado a documentos?

Os bancos NoSQL (Not Only SQL) surgiram para atender a cenários de grandes volumes de dados, muitas vezes semiestruturados ou não estruturados, que exigem alta disponibilidade e escalabilidade horizontal (adicionar mais servidores ao cluster). Eles abandonam o esquema rígido em favor de esquemas flexíveis ou dinâmicos: cada documento (geralmente em formato JSON) pode ter campos diferentes, sem a necessidade de definir previamente uma estrutura fixa.

O modelo orientado a documentos armazena coleções de documentos. Os documentos são semelhantes entre si, mas não precisam ser idênticos — é totalmente possível que tenham campos diferentes. Isso é perfeito para os eventos de atendimento ao cidadão: logs, interações, arquivos de mídia, registros que variam de departamento para departamento. A estrutura é dinâmica e cresce rapidamente; forçar isso em tabelas relacionais exigiria um esquema complexo, com muitas tabelas esparsas e junções caras, ou um esquema que precisaria ser alterado constantemente.

A distinção que decide a questão

A tabela abaixo resume o contraste entre os dois modelos, que é exatamente o critério que a banca explora:

A pegadinha da questão está em generalizar: a alternativa E afirma que NoSQL supera relacional em todos os cenários, o que é falso — para dados com muitos relacionamentos e exigência de integridade, o relacional é superior. A alternativa B tenta usar relacional para tudo, ignorando a necessidade de flexibilidade e escalabilidade dos eventos. A alternativa C inverte os papéis de forma absurda (relacional para eventos, CSV para servidores). A alternativa D também inverte: colunas NoSQL para servidores e relacional para eventos, quando o correto é o oposto.

A pegadinha da banca

Análise das alternativas

Alternativa A — ✅ Correta ⟵ GABARITO

Esta alternativa espelha exatamente o princípio da escolha adequada ao perfil dos dados. Para a base de servidores públicos, o banco relacional é o mais indicado porque garante consistência transacional (ACID) e integridade referencial, essenciais para dados com muitos relacionamentos (CPF, matrícula, cargo, vínculo a departamentos). Para os eventos de atendimento ao cidadão, o NoSQL orientado a documentos é o mais adequado porque oferece flexibilidade de esquema (documentos com campos variáveis) e escalabilidade horizontal, atendendo ao crescimento rápido e à estrutura dinâmica dos logs, interações e mídias. A alternativa acerta ao combinar as duas tecnologias, aproveitando o melhor de cada uma.

Alternativa B — ❌ Incorreta

A alternativa B propõe modelar ambos os conjuntos com banco relacional. Isso atenderia bem à base de servidores, mas seria inadequado para os eventos de atendimento: a estrutura flexível e dinâmica (logs, interações, mídias) não se encaixa bem em tabelas rígidas com esquema predefinido. Forçar esses dados em um modelo relacional exigiria um esquema complexo, com muitas tabelas esparsas e junções, além de dificultar a escalabilidade horizontal necessária para o alto volume de registros. O erro está em ignorar a necessidade de flexibilidade e escalabilidade dos eventos.

Alternativa C — ❌ Incorreta

A alternativa C inverte completamente os papéis: usa banco relacional para eventos (que precisam de flexibilidade) e armazena dados de servidores em arquivos CSV. Isso é duplamente errado: (1) eventos de atendimento, com estrutura dinâmica e alto volume, não se beneficiam do relacional rígido; (2) servidores públicos, que exigem consistência transacional e integridade referencial, não podem ser armazenados em arquivos CSV, que não oferecem controle de concorrência, transações ou integridade. A alternativa confunde o propósito de cada tecnologia e ainda sugere uma solução primitiva (CSV) para dados críticos.

Alternativa D — ❌ Incorreta

A alternativa D também inverte os papéis: usa NoSQL orientado a colunas para servidores e relacional para eventos. O erro é duplo: (1) servidores públicos, com muitos relacionamentos e exigência de integridade, precisam de um banco relacional, não de NoSQL orientado a colunas (que é mais adequado para análises de grandes volumes de dados, como em data warehouses); (2) eventos de atendimento, com estrutura flexível e dinâmica, não se beneficiam de um banco relacional rígido. A alternativa ainda afirma que logs exigem maior normalização e controle de transações — o oposto do que a prática recomenda: logs são tipicamente semiestruturados e de alto volume, favorecendo NoSQL.

Alternativa E — ❌ Incorreta

A alternativa E comete uma generalização indevida: afirma que NoSQL supera relacional em todos os cenários. Isso é falso. Para dados com muitos relacionamentos e exigência de consistência transacional e integridade referencial (como a base de servidores), o banco relacional é superior. NoSQL é excelente para flexibilidade, escalabilidade e dados semiestruturados, mas não é a melhor escolha universal. A alternativa ignora as características específicas de cada conjunto de dados, que é exatamente o que a questão pede para considerar.

Gabarito: letra A