02. Arquitetura e estruturas internas de SGBDs

Entre uma instrução SQL e o resultado existe um conjunto de componentes que interpreta, planeja, busca páginas, usa memória e registra alterações. Entender esse caminho torna menos abstratas as decisões de desempenho e recuperação.

Com o modelo e a linguagem estabelecidos, passamos a cuidar do banco em funcionamento. A sequência liga governança, arquitetura interna, transações, desempenho, observabilidade, segurança, recuperação e soluções em memória. Este é o capítulo 2 de 8 da disciplina Administração de Bancos de Dados. A leitura retoma Administração de dados e bancos de dados e usa essa base para avançar. Depois, seguiremos para Transações: propriedades ACID e controle de concorrência.

O fio condutor

Banco de dados deve ser estudado como um sistema de decisões conectadas. O significado atribuído ao dado orienta o modelo; o modelo condiciona consultas e atualizações; o SGBD executa essas operações sob regras de segurança, concorrência, desempenho e recuperação. Quando uma dessas camadas muda, as demais podem ser afetadas.

Ao longo da leitura, acompanhe sempre quatro perguntas: qual problema está sendo resolvido, qual estrutura representa o problema, que garantia precisa ser preservada e qual custo acompanha a escolha. Esse roteiro ajuda a compreender os conceitos em vez de apenas memorizar nomes.

Por que existe um SGBD

Começamos por Por que existe um SGBD, pois essa base permite compreender as decisões apresentadas nas seções seguintes.

O SGBD é a coleção de programas que permite definir, construir, manipular e compartilhar bancos de dados. Ele nasceu do problema do processamento tradicional de arquivos: cada aplicação com seus próprios arquivos produz redundância não controlada e, quando uma cópia é atualizada e as outras não, inconsistência — além de embutir a estrutura dos dados no código de cada programa.

• O SGBD controla a redundância — não a elimina em absoluto: pode haver redundância controlada por desempenho.
• A autodescrição põe a definição dos dados no catálogo, uma única vez, em vez de dentro de cada programa.
• Outras vantagens: compartilhamento com acesso concorrente controlado, imposição de restrições de integridade, segurança, independência de dados, redução do tempo de desenvolvimento de novas aplicações e imposição de padrões de nomenclatura e documentação.
• Há casos em que não compensa: aplicações simples e estáveis, de usuário único, e sistemas embarcados ou de tempo real rígido, em que a sobrecarga do SGBD não se justifica.

Repare como Redundância controlada, Autodescrição, Quando não compensa participam da mesma decisão. Ao relacionar esses elementos, fica mais fácil prever o comportamento do banco e reconhecer os efeitos de cada escolha.

Arquiteturas de sistema

A seção anterior apresentou Por que existe um SGBD. Agora chegamos a Arquiteturas de sistema, que acrescenta a próxima peça do mesmo raciocínio.