Pular para o conteudo

Resumo TI Banco de Dados: Arquiteturas Centralizada, Cliente-Servidor e Distribuída

Onde o SGBD roda fisicamente, e como aplicações e usuários se conectam a ele, mudou radicalmente ao longo das décadas — do mainframe isolado à nuvem distribuída globalmente. Bancas de TI cobram essa evolução tanto pelo nome de cada arquitetura quanto pelas vantagens e desvantagens de cada modelo.

Neste resumo, você vai conhecer as arquiteturas centralizada, cliente-servidor (em suas variações de duas e três camadas) e distribuída, entendendo o problema que cada uma resolve e o que sacrifica em troca.

📲 Canal Oficial do Dicionário do Concurseiro no WhatsApp

Receba resumos, questões comentadas e novidades diretamente no seu celular!

👉 Acessar Canal no WhatsApp

💡 Conteúdo exclusivo para concurseiros. Totalmente gratuito!

🖥️ Arquitetura centralizada

Na arquitetura centralizada, todo o processamento — SGBD, aplicação e interface — roda em uma única máquina, tipicamente um mainframe ou servidor de grande porte. Os usuários acessam o sistema por terminais “burros” (sem capacidade de processamento própria), que apenas exibem o que o servidor central envia.

  • Vantagem: controle total e simplicidade administrativa — um único ponto para gerenciar segurança, backup e desempenho;
  • Desvantagem: ponto único de falha (se o servidor cai, ninguém trabalha) e limite de escalabilidade vertical (só dá para aumentar a capacidade da mesma máquina até certo ponto);
  • Uso atual: ainda presente em sistemas legados de grande porte, como aplicações bancárias rodando em mainframe (ver resumo sobre evolução histórica dos bancos de dados, sobre o IBM IMS).

🔌 Arquitetura cliente-servidor

Divide o processamento entre uma máquina cliente (que roda a interface e parte da lógica) e um servidor (que roda o SGBD e processa as consultas). É a arquitetura que popularizou os SGBDs relacionais comerciais a partir dos anos 1980-1990.

  • Duas camadas (2-tier): o cliente se conecta diretamente ao servidor de banco de dados, geralmente embutindo boa parte da lógica de negócio na própria aplicação cliente (chamado de “cliente pesado” ou fat client);
  • Três camadas (3-tier): insere uma camada intermediária de aplicação/negócio entre o cliente (agora mais leve, um thin client — muitas vezes um navegador) e o servidor de banco de dados. A lógica de negócio fica centralizada nessa camada do meio, não espalhada em cada cliente;
  • Vantagem do 3-tier sobre o 2-tier: facilita manutenção (a lógica de negócio muda num só lugar), melhora segurança (o cliente não acessa o banco diretamente) e escala melhor (a camada de aplicação pode ser replicada independentemente do banco).

🌐 Arquitetura distribuída

Um banco de dados distribuído tem seus dados fisicamente espalhados por múltiplos servidores (nós), possivelmente em locais geográficos diferentes, mas apresenta ao usuário a ilusão de um banco único e coeso — princípio conhecido como transparência de distribuição.

  • Fragmentação: os dados são divididos entre os nós, seja horizontalmente (linhas diferentes em nós diferentes) ou verticalmente (colunas diferentes em nós diferentes);
  • Replicação: cópias dos mesmos dados existem em múltiplos nós, aumentando disponibilidade e desempenho de leitura, ao custo de complexidade para manter consistência;
  • Transparência de distribuição: o usuário/aplicação não precisa saber em qual nó físico um dado está armazenado para consultá-lo — o sistema resolve isso internamente;
  • Desafios centrais: consistência entre réplicas, latência de rede entre nós, e o trade-off descrito pelo teorema CAP (ver resumo sobre evolução histórica dos bancos de dados) quando ocorre partição de rede.

⚖️ Comparando as três arquiteturas

  • Centralizada: processamento único; ponto único de falha; escalabilidade vertical apenas;
  • Cliente-servidor (2-tier): processamento dividido cliente/servidor; lógica de negócio no cliente; escalabilidade limitada pela camada de banco;
  • Cliente-servidor (3-tier): processamento dividido em três camadas; lógica de negócio centralizada no meio; escalabilidade horizontal da camada de aplicação;
  • Distribuída: dados espalhados por múltiplos nós; alta disponibilidade via replicação; escalabilidade horizontal também no armazenamento.

⚠️ Pegadinhas comuns

  • Cliente-servidor não é o mesmo que distribuído: cliente-servidor descreve a divisão de processamento entre máquinas de papéis diferentes; distribuído descreve os dados espalhados entre múltiplos nós, muitas vezes todos com papel de servidor;
  • 3-tier não elimina o servidor de banco: a camada de aplicação é adicional, não substitui o SGBD — ela fica entre o cliente e o banco, não no lugar do banco;
  • Replicação não é sinônimo de fragmentação: replicação copia os mesmos dados em vários nós; fragmentação divide dados diferentes entre nós — um banco distribuído pode usar as duas técnicas combinadas;
  • Arquitetura centralizada não desapareceu: continua sendo a escolha certa para cargas de trabalho que não precisam de escala horizontal e valorizam simplicidade operacional.

🎯 Dica Final para a Prova

Identifique a arquitetura pela pergunta “onde o processamento e os dados estão fisicamente?”: tudo numa máquina só é centralizada; dividido entre cliente e servidor (com ou sem camada de aplicação no meio) é cliente-servidor; dados espalhados por múltiplos nós, com transparência para o usuário, é distribuída. E lembre-se: 3-tier soma uma camada ao 2-tier, não troca uma pela outra.

✓ Agora que você conhece as arquiteturas físicas de um banco de dados, o próximo passo é entender os modelos de carga de trabalho que rodam sobre elas — OLTP, OLAP e HTAP — e por que cada um exige um tipo diferente de otimização.


📍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: Modelos OLTP, OLAP e HTAP


📚 A escolha entre centralizado, cliente-servidor e distribuído nunca é só técnica — é uma decisão sobre custo, disponibilidade e complexidade operacional. Entender essas trocas é entender por que sistemas diferentes fazem escolhas arquiteturais diferentes. Continue estudando!

Gostou deste conteúdo?

Favoritar

Comentários

Seja o primeiro a comentar.