Resumo TI Banco de Dados: Visão Geral de Ecossistemas Relacionais e Não Relacionais

Chegamos ao último resumo do bloco de fundamentos. Antes de mergulhar em modelagem, SQL, transações e tópicos avançados nos próximos blocos da trilha, vale consolidar o mapa geral: quais categorias de SGBD existem hoje, o que cada uma prioriza, e como elas se posicionam umas em relação às outras. Esse panorama é frequentemente cobrado em questões introdutórias de concursos de TI.

Neste resumo, você vai ver um retrato consolidado do ecossistema relacional e não relacional, amarrando os conceitos de evolução histórica, modelos de carga (OLTP/OLAP/HTAP) e arquiteturas já vistos nos resumos anteriores.

🧮 Ecossistema relacional

O ecossistema relacional nasceu da proposta de Codd (1970) e continua sendo a base da maioria dos sistemas corporativos. Sua força está na maturidade: décadas de otimização, ferramentas, padronização via SQL e forte garantia ACID.

• SGBDs relacionais tradicionais: Oracle, IBM DB2, Microsoft SQL Server — voltados a cargas corporativas críticas, com décadas de recursos de administração e tuning;
• SGBDs relacionais open source: PostgreSQL (extensível, forte em conformidade com padrões) e MySQL (simplicidade e ampla adoção em aplicações web);
• NewSQL: Google Spanner, CockroachDB, TiDB — relacionais com escalabilidade horizontal, mantendo SQL e ACID (ver resumo sobre evolução histórica dos bancos de dados);
• Ponto forte comum: integridade referencial, transações ACID robustas e um padrão de linguagem (SQL) amplamente dominado no mercado.

🌐 Ecossistema não relacional (NoSQL)

O ecossistema NoSQL surgiu para atender demandas de escala horizontal e flexibilidade de esquema que o modelo relacional tradicional não priorizava. Não é um modelo único, mas uma família de abordagens distintas:

• Documento: MongoDB, CouchDB — armazenam registros semiestruturados (tipicamente JSON/BSON), bons para dados com estrutura variável entre registros;
• Chave-valor: Redis, DynamoDB — acesso extremamente rápido por chave, ideais para cache e sessões;
• Coluna larga (wide-column): Cassandra, HBase — otimizados para escrita em massa e leitura de grandes volumes distribuídos;
• Grafo: Neo4j — otimizado para relacionamentos complexos e travessias (ex.: redes sociais, recomendação, detecção de fraude);
• Ponto forte comum: escalabilidade horizontal nativa e esquema flexível, geralmente trocando consistência forte por disponibilidade (teorema CAP).

🔀 Convergência: multimodelo e bancos gerenciados

A fronteira entre relacional e não relacional tem ficado menos rígida:

• Bancos relacionais incorporando recursos NoSQL: PostgreSQL e Oracle oferecem tipos de coluna JSON com indexação, aproximando-se do modelo documento sem abandonar SQL;
• Bancos multimodelo: ArangoDB suporta documento, grafo e chave-valor na mesma engine;
• DBaaS (Database as a Service): Amazon RDS, Google Cloud SQL, Azure SQL abstraem a administração de infraestrutura para bancos relacionais e não relacionais, com elasticidade e replicação gerenciadas pelo provedor de nuvem.

🧭 Como escolher entre os dois mundos

Não existe “melhor SGBD” em abstrato — existe o SGBD mais adequado à carga de trabalho e às garantias exigidas:

• Prefira relacional quando: a consistência transacional é crítica (financeiro, estoque, faturamento), o esquema é estável e bem conhecido, e há forte necessidade de integridade referencial;
• Prefira NoSQL quando: o volume e a velocidade de escrita são muito altos, o esquema muda com frequência, ou a escala horizontal é prioridade sobre consistência imediata;
• Considere HTAP ou multimodelo quando: a aplicação genuinamente precisa de múltiplos padrões de acesso sem manter sistemas totalmente separados (ver resumo anterior sobre OLTP, OLAP e HTAP).

⚠️ Pegadinhas comuns

• NoSQL não é “mais moderno” no sentido de “substituir” o relacional: são famílias com propósitos diferentes, coexistindo há décadas — não há uma hierarquia de evolução linear entre eles;
• Um SGBD relacional pode ser NewSQL sem deixar de ser relacional: NewSQL é uma evolução de escalabilidade sobre o modelo relacional, não uma categoria concorrente a ele;
• Multimodelo não é o mesmo que “um banco para cada modelo”: significa um único motor suportando múltiplos modelos de dados, não vários SGBDs distintos operando lado a lado;
• DBaaS é uma forma de entrega (nuvem gerenciada), não um modelo de dados: tanto bancos relacionais quanto não relacionais podem ser oferecidos como DBaaS.

🎯 Dica Final para a Prova

Diante de uma questão que pede para “escolher o SGBD adequado a um cenário”, identifique primeiro a prioridade central do cenário: consistência forte e transações críticas → relacional; escala horizontal e esquema variável → NoSQL (identificando o modelo específico pelo padrão de acesso descrito); ambos ao mesmo tempo, sem ETL → HTAP.

✓ Com isso, fechamos o bloco de fundamentos e arquitetura da informação. O próximo passo da trilha é entrar na modelagem de dados propriamente dita, começando pelo levantamento de requisitos — a etapa que antecede qualquer diagrama entidade-relacionamento.

📍Gostou do conteúdo? Deixe um comentário, compartilhe e continue acompanhando o Dicionário do Concurseiro para mais Resumos de TI – Banco de Dados. Aqui você encontra explicações claras, atualizadas e com foco total no que cai em prova!

👉 Leia também no Dicionário do Concurseiro: Resumo TI Banco de Dados: Levantamento de requisitos para modelagem

📚 Conhecer o mapa completo do ecossistema de bancos de dados é o que permite avaliar qualquer cenário de prova ou de projeto real com critério, em vez de aplicar uma solução única a todos os problemas. Continue estudando!