Resumo TI Banco de Dados: Evolução histórica de bancos de dados

A evolução histórica dos bancos de dados é um dos temas mais recorrentes em concursos de TI, especialmente em provas de analista de sistemas, auditor de TI e cargos de tecnologia em órgãos públicos federais. Entender como os modelos de armazenamento evoluíram — do sistema de arquivos ao banco distribuído em nuvem — é essencial para contextualizar as decisões arquiteturais que aparecem nas questões.

Neste resumo, você vai percorrer as principais gerações dos bancos de dados, compreender por que cada modelo surgiu, quais problemas resolveu e quais limitações deixou para o próximo ciclo tecnológico.

📁 Antes dos SGBDs: sistemas de arquivos e seus problemas

Antes do surgimento dos SGBDs, as aplicações gerenciavam dados diretamente por meio de sistemas de arquivos do sistema operacional. Cada aplicação mantinha seus próprios arquivos, sem camada intermediária de gerenciamento.

• Redundância e inconsistência: o mesmo dado era armazenado em múltiplos arquivos por aplicações diferentes, gerando cópias desatualizadas;
• Dificuldade de acesso: recuperar dados exigia programas específicos para cada consulta — não havia linguagem de consulta padronizada;
• Isolamento de dados: dados de uma aplicação não eram facilmente acessíveis por outra;
• Problemas de integridade: não havia mecanismo automático para garantir restrições como unicidade ou referências válidas entre arquivos;
• Ausência de controle de concorrência: múltiplos usuários acessando o mesmo arquivo simultaneamente podiam corromper os dados.

Esses problemas motivaram o desenvolvimento de sistemas dedicados ao gerenciamento de dados — os primeiros SGBDs.

🌳 Modelos Hierárquico e em Rede (anos 1960–1970)

Os primeiros SGBDs surgiram no final dos anos 1960, ainda fortemente acoplados ao hardware e ao sistema operacional.

• Modelo hierárquico (IBM IMS, 1968): dados organizados em árvores — cada registro filho tem exatamente um pai. Eficiente para estruturas previsíveis, mas inflexível para relacionamentos mais complexos;
• Modelo em rede (CODASYL, 1969): evolução do hierárquico — permite que um registro filho tenha múltiplos pais, formando um grafo. Mais expressivo, mas de navegação complexa e fortemente dependente de ponteiros físicos;
• Limitação comum: ambos os modelos exigiam que o programador conhecesse a estrutura física de armazenamento para escrever consultas — a independência de dados era praticamente inexistente.

🧮 O Modelo Relacional e a Revolução de Codd (1970)

Em 1970, Edgar Frank Codd publicou o artigo “A Relational Model of Data for Large Shared Data Banks”, propondo o modelo relacional — a maior ruptura na história dos bancos de dados.

• Fundamento matemático: dados organizados em relações (tabelas), baseadas na teoria dos conjuntos e na álgebra relacional;
• Independência de dados: separação entre a visão lógica dos dados e sua estrutura física de armazenamento;
• Linguagem declarativa: o usuário especifica o que quer, não como buscar — base para o SQL;
• 12 regras de Codd: conjunto de critérios que um SGBD deve satisfazer para ser considerado verdadeiramente relacional;
• SQL: padronizado pela ISO em 1987, tornou-se a linguagem universal de consulta e manipulação de dados relacionais.

O modelo relacional dominou o mercado por décadas e ainda é o modelo predominante em sistemas corporativos.

🏗️ Consolidação dos SGBDs Relacionais (anos 1980–1990)

A década de 1980 marcou a popularização dos SGBDs relacionais com produtos comerciais robustos:

• Oracle (1979/1980): primeiro SGBD relacional comercial com SQL;
• IBM DB2 (1983): SGBD relacional para mainframes IBM;
• Microsoft SQL Server (1989): entrada da Microsoft no mercado;
• PostgreSQL (1986/1996): projeto open source com foco em extensibilidade e conformidade com padrões;
• MySQL (1995): SGBD relacional open source amplamente adotado para aplicações web.

Nessa fase, as propriedades ACID (Atomicidade, Consistência, Isolamento, Durabilidade) tornaram-se o padrão de confiabilidade esperado de qualquer SGBD sério.

🌐 O Movimento NoSQL (anos 2000)

Com a explosão da internet e do Big Data no início dos anos 2000, as limitações de escalabilidade horizontal dos SGBDs relacionais ficaram evidentes. Empresas como Google, Amazon e Facebook desenvolveram alternativas.

• NoSQL (“Not Only SQL”): categoria de SGBDs que abandona o modelo relacional em favor de modelos mais flexíveis — documento, chave-valor, coluna e grafo;
• Principais características: esquema flexível (schema-less), escalabilidade horizontal, alta disponibilidade, eventual consistency;
• Exemplos por modelo:
  • Documento: MongoDB, CouchDB;
  • Chave-valor: Redis, DynamoDB;
  • Coluna larga: Cassandra, HBase;
  • Grafo: Neo4j.
• Teorema CAP (Brewer, 2000): em sistemas distribuídos, é impossível garantir simultaneamente Consistência, Disponibilidade e tolerância a Partições — os sistemas NoSQL fazem concessões explícitas nesse triângulo.

⚡ NewSQL, Multimodelo e Bancos em Nuvem

A partir dos anos 2010, surgiram abordagens que tentam combinar o melhor dos dois mundos:

• NewSQL: SGBDs que mantêm as garantias ACID e o SQL, mas com arquitetura distribuída e escalabilidade horizontal. Exemplos: Google Spanner, CockroachDB, TiDB;
• Bancos multimodelo: suportam mais de um modelo de dados (relacional + documento + grafo) na mesma engine. Exemplo: ArangoDB, Oracle Database (com extensões JSON e grafo);
• Bancos em nuvem (DBaaS): Amazon RDS, Google Cloud SQL, Azure SQL — infraestrutura gerenciada, elasticidade automática e replicação nativa;
• Bancos serverless: Aurora Serverless, PlanetScale — capacidade elástica sem provisionamento fixo de instâncias.

A tendência atual é a coexistência de múltiplos modelos de armazenamento em uma mesma arquitetura de dados, escolhidos conforme o perfil de acesso e os requisitos de consistência de cada domínio.

⚠️ Pegadinhas comuns

• NoSQL não significa “sem SQL”: significa “Not Only SQL” — muitos bancos NoSQL suportam subconjuntos de SQL ou linguagens similares;
• O modelo relacional não foi criado pela IBM: foi proposto por E. F. Codd, pesquisador da IBM, mas o modelo é conceitual — não pertence à empresa;
• ACID não é exclusivo de bancos relacionais: alguns bancos NoSQL (como MongoDB a partir da v4) oferecem transações ACID;
• O modelo hierárquico não foi substituído totalmente: ainda é usado em sistemas legados, como o IBM IMS, presente em grandes mainframes bancários;
• NewSQL não é NoSQL: NewSQL mantém SQL e ACID; NoSQL normalmente abre mão de um ou dos dois.

🎯 Dica final para a prova

Em questões sobre evolução histórica, fique atento à linha do tempo: sistemas de arquivos → hierárquico/rede → relacional (Codd, 1970) → consolidação com SQL → NoSQL (2000s, Big Data) → NewSQL e nuvem. Bancas gostam de testar se o candidato sabe qual problema motivou cada transição.

Associe cada modelo ao seu caso de uso típico: relacional para consistência transacional, NoSQL para escala e flexibilidade de esquema, NewSQL para escala com garantias ACID. Essa lógica resolve a maioria das questões comparativas.

✅ Agora que você domina a evolução histórica dos bancos de dados, o próximo passo é entender as diferenças conceituais e práticas entre um SGBD e um sistema de arquivos convencional.

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

👉 Em breve no Dicionário do Concurseiro: Resumo TI Banco de Dados: SGBD versus sistema de arquivos

📘 Conhecer a história dos bancos de dados é entender por que as escolhas de hoje existem. Cada modelo surgiu para resolver um problema real — e dominar esse raciocínio é o que separa quem acerta das questões de quem erra. Continue estudando!