Banco de Dados para o Concurso Dataprev — Parte II: metadados, modelagem dimensional, NoSQL, banco em memória, data lakes e Big Data na prova da FGV

Na Parte II do estudo de Banco de Dados para o concurso da Dataprev, o candidato precisa avançar para os temas mais modernos do edital: metadados, modelagem dimensional, bancos NoSQL, bancos em memória, data lakes e soluções para Big Data. Esses assuntos são muito importantes porque dialogam diretamente com ambientes corporativos de grande porte, como os que envolvem dados governamentais, previdenciários, sociais e analíticos.

A FGV costuma cobrar esses temas comparando tecnologias e arquiteturas. A banca pode perguntar, por exemplo, quando usar um banco relacional, quando usar NoSQL, qual é a finalidade de um data lake, qual é a diferença entre data warehouse e data lake ou qual tipo de banco NoSQL é mais adequado para determinado cenário. Por isso, o candidato precisa estudar com foco em diferenças, usos e limitações.

O primeiro conceito importante é o de metadados. De forma simples, metadados são dados sobre dados. Em bancos de dados, eles descrevem a estrutura, o significado, a origem, o formato e as regras associadas aos dados armazenados. Informações sobre tabelas, colunas, tipos de dados, restrições, índices, usuários e permissões são exemplos de metadados.

A FGV pode cobrar metadados em contexto de banco de dados, governança de dados, dicionário de dados ou catálogo de dados. Em uma organização que trabalha com grande volume de informações, como a Dataprev, os metadados são essenciais para localizar, compreender, integrar e controlar o uso dos dados.

Outro tema relevante é a modelagem dimensional, muito utilizada em ambientes analíticos, data warehouses e soluções de Business Intelligence. Diferentemente da modelagem relacional tradicional, que busca reduzir redundâncias e preservar a consistência transacional, a modelagem dimensional busca facilitar consultas analíticas e apoiar a tomada de decisão.

Na modelagem dimensional, temos principalmente tabelas fato e tabelas dimensão. A tabela fato armazena eventos mensuráveis do negócio, como pagamentos, atendimentos, requerimentos, acessos ou transações. Normalmente, ela contém medidas numéricas e chaves estrangeiras que apontam para dimensões.

As tabelas dimensão fornecem o contexto da análise. Elas respondem perguntas como quem, quando, onde, como e em qual categoria determinado fato ocorreu. Exemplos de dimensões incluem tempo, localidade, beneficiário, unidade, serviço, canal de atendimento e tipo de benefício.

Dois modelos muito cobrados são o esquema estrela e o esquema floco de neve. No esquema estrela, uma tabela fato central se conecta diretamente às tabelas dimensão. Esse modelo é mais simples e favorece consultas analíticas. No esquema floco de neve, as dimensões são normalizadas, criando estruturas mais detalhadas, mas também mais complexas.

A FGV pode afirmar, por exemplo, que o esquema estrela é típico de ambientes analíticos e possui dimensões geralmente desnormalizadas. Essa afirmação tende a estar correta. Por outro lado, se a banca disser que a modelagem dimensional é voltada prioritariamente para sistemas transacionais altamente normalizados, o candidato deve desconfiar.

O próximo tema é NoSQL. Bancos NoSQL são soluções que não seguem necessariamente o modelo relacional tradicional. Eles foram criados para cenários que exigem escalabilidade, flexibilidade de esquema, distribuição, alta disponibilidade e tratamento de dados semiestruturados ou não estruturados.

É importante entender que NoSQL não deve ser interpretado simplesmente como “sem SQL”. Em muitos contextos, a expressão é entendida como “Not Only SQL”, ou seja, “não apenas SQL”. Isso significa que o mundo dos bancos de dados vai além do modelo relacional, mas não necessariamente elimina completamente recursos de consulta ou estruturação.

Os principais tipos de bancos NoSQL são chave-valor, documentos, colunar e grafos. Bancos chave-valor armazenam pares formados por uma chave e um valor, sendo muito usados em cache, sessões e preferências. Bancos orientados a documentos armazenam estruturas como JSON ou BSON, sendo comuns em aplicações web e sistemas com esquema flexível.

Bancos colunares, ou de famílias de colunas, são usados em grandes volumes de dados distribuídos, logs e aplicações que exigem alta escrita e leitura escalável. Bancos de grafos, por sua vez, são indicados para representar relacionamentos complexos, como redes sociais, recomendações, rotas, dependências e detecção de fraudes.

A FGV gosta de cobrar o tipo de banco NoSQL mais adequado a cada situação. Se a questão falar em relacionamento complexo entre entidades, o candidato deve pensar em grafo. Se falar em documentos JSON com estrutura flexível, deve pensar em banco orientado a documentos. Se falar em cache simples com chave e valor, a resposta tende a ser banco chave-valor.

Outro ponto relevante é a comparação entre bancos relacionais e NoSQL. Bancos relacionais têm esquema mais rígido, forte uso de SQL, tabelas, chaves e transações ACID. Bancos NoSQL costumam ter maior flexibilidade, possibilidade de escalabilidade horizontal e modelos de dados variados. No entanto, cuidado com generalizações: não é correto afirmar que todo banco NoSQL não possui consistência, transação ou linguagem de consulta.

Nesse contexto, aparecem também os conceitos de ACID e BASE. ACID está associado à confiabilidade transacional clássica: atomicidade, consistência, isolamento e durabilidade. BASE está relacionado a ambientes distribuídos que podem priorizar disponibilidade e consistência eventual. A FGV pode cobrar essa comparação em questões sobre bancos distribuídos e NoSQL.

O edital também menciona banco de dados em memória. Esse tipo de banco utiliza a memória principal como meio predominante de armazenamento e processamento, com objetivo de reduzir latência e aumentar desempenho. É comum em cenários de cache, sessões, filas, rankings, dados temporários, processamento em tempo real e aplicações de alta velocidade.

O candidato deve ter cuidado para não entender banco em memória como ausência total de persistência. Muitas soluções em memória possuem mecanismos de persistência, replicação e recuperação. O ponto central para a prova é entender que o uso intensivo da memória melhora o desempenho quando comparado ao acesso tradicional em disco.

Outro tema moderno é o data lake. Um data lake é um repositório capaz de armazenar grande volume de dados em seu formato bruto ou pouco transformado. Ele pode receber dados estruturados, semiestruturados e não estruturados, como tabelas, arquivos CSV, JSON, XML, logs, documentos, imagens e dados de sensores.

A diferença entre data lake e data warehouse é muito cobrada. O data warehouse trabalha com dados mais estruturados, tratados e preparados para análise gerencial. O data lake é mais flexível e pode armazenar dados brutos, permitindo exploração posterior por cientistas de dados, engenheiros de dados e analistas.

Uma distinção importante é entre schema-on-write e schema-on-read. No data warehouse, normalmente o esquema é definido antes da gravação dos dados, caracterizando o schema-on-write. No data lake, a estrutura pode ser aplicada no momento da leitura, caracterizando o schema-on-read. Essa diferença é excelente para prova da FGV.

Por fim, o edital menciona data lakes e soluções para Big Data. Big Data não significa apenas grande volume de dados. O conceito envolve os famosos Vs: volume, velocidade, variedade, veracidade e valor. A FGV pode cobrar esses elementos diretamente ou aplicá-los em uma situação envolvendo grandes bases de dados, dados em tempo real e múltiplos formatos.

Soluções para Big Data envolvem armazenamento distribuído, processamento distribuído, ingestão de dados, pipelines, processamento em lote, processamento em fluxo, tolerância a falhas e paralelismo. Ferramentas como Hadoop, Spark, Kafka, Hive, HBase, Cassandra e ambientes de nuvem podem aparecer associadas a esse universo, embora a prova costume focar mais no conceito do que na configuração específica das ferramentas.

Para o concurso da Dataprev, o candidato deve perceber que esses temas modernos têm forte relação com sistemas de grande escala. A Dataprev trabalha com tecnologia e informações relacionadas à Previdência, o que naturalmente envolve grandes volumes de dados, integração de sistemas, processamento analítico, segurança, disponibilidade e governança.

Na preparação para a FGV, a melhor estratégia é estudar por comparação. Relacional versus NoSQL. Data warehouse versus data lake. ACID versus BASE. Esquema estrela versus floco de neve. Banco em disco versus banco em memória. Dados estruturados versus semiestruturados e não estruturados.

Assim, a Parte II do conteúdo de Banco de Dados deve ser estudada com foco em aplicação prática. A FGV não quer apenas que o candidato saiba repetir conceitos; ela quer verificar se ele entende qual tecnologia resolve melhor determinado problema. Esse é o diferencial para ganhar pontos em questões de Banco de Dados no concurso da Dataprev.